Aggregating coding blogs
Matt Bentley from arne-mertz.de
Today, Matt Bentley writes for us about terse names in our Code. Matt was born in 1978 and never recovered from the ordeal. He has lived a long and interesting […]
The post Terseness: how little, is too much? appeared first on .
Derek Jones from The Shape of Code
One of the folk truisms of the compiler/source code analysis business is that error paths are short, i.e., when an error situation is detected (such as failing to open a file), few statements are executed before the functions returns.
Having repeated this truism for many decades, figure 2 from the paper APEx: Automated Inference of Error Specifications for C APIs jumped off the page at me; thanks to Yuan Kang, I now have a copy of the data.
The plots below (code+data) show two representations of the non-error/error path lengths (measured in statements within individual functions of libc; counting starts at a library call that could return an error value). The upper plot shows statement sequence lengths for error/non-error paths, and the lower is a kernel density plot of the error/non-error sequence lengths.
Another truism is that people tend to write positive tests, i.e., tests that do not involve error handling (some evidence).
Code coverage measurements (e.g., number of statements or branches that are executed by a test suite) often show the pattern seen in the plot below (code+data; thanks to the authors of the paper Code Coverage for Suite Evaluation by Developers for making the data available). The data was obtained by measuring the coverage of 1,043 Java programs executing their associated test suite (circles denote program size). Lines are fitted regression models for different sized programs.
If people are preferentially writing positive tests, test suites with low coverage would be expected to execute a greater percentage of statements than branches (an if-statement has two branches, taken/not-taken), i.e., the behavior seen in the plot above (grey line shows equal statement/branch coverage). Once the low hanging fruit is tested (i.e., the longer, non-error, cases), tests have to be written for the shorter, more likely to be error handling, cases.
The plot would also be explained by typical execution paths favoring longer basic blocks, but I don’t have any data that could show this one way or another.
Paul Grenyer from Paul Grenyer
Paul Grenyer from Paul Grenyer
Allan Kelly from Allan Kelly Associates
Starting a new project? A new product? Have a team transitioning to “Agile†(aka Scrum) and wanting to get ready?
Why not try a Sprint Zero? – Why not indeed.
Sprint Zero is a way to get everything ready to start work, to buy the tools you need, set up your databases, perhaps do some architecture review, tell the rest of the organization about what you are doing, maybe write some requirements, get some additional training, etc. etc.
Sprint Zero doesn’t need to happen in a time box, you can take all the time you need, after all, you haven’t become “agile†yet, Sprint Zero will make you Agile.
Good idea?
Please don’t.
Sprint Zero is a get-out-of-jail-free card that pushes really change down the road a little bit further.
The truth is: there is work to do.
Just start “sprintingâ€. Schedule an iteration to start tomorrow and get going. Do what you plan for the next week, then review and plan again.
Doing anything else delays the change and potentially reduces motivation.
If you want to call your first iteration Zero then fine; you can call it Zero, or One, or Two, or 57 or even -1 if you want, I don’t care. Give it a number and make sure the next iteration adds one to that number.
All those things I just listed – and more – that you need to do to “get started†are themselves work that needs doing. Why not write them on a card and schedule them like you would any other piece of work in an iteration?
If you haven’t worked out what those things are then No problem, try and schedule some real work. When you find you don’t have something (a database instance for example) simply write out a card, schedule it, do it. The things you need to do to “get ready†are actually things you need to do to build something you do want.
My big worry with Sprint Zero (apart from it injecting unnecessary delay and loss of change momentum) is that it makes work. You may think you need to do something in advance and you might be right. But, then again, you might be wrong. You might do something – like install a database – when you could quite easily postpone that work for a few weeks or even skip it entirely.
Similarly some say “How can we start work until we know what we need to do? – we need to gather requirements, write some stories….â€
But again: determining what needs doing, requirements gathering, is itself work to be done.
If it is not clear what needs to be done on day-1 then the first thing to do is to do some work to find out what needs to be done. The initial work may well be requirements discover and story writing with only a little bit of product building.
Speculative, early, requirements gathering, may actually increase the amount of work to do because you capture all the things people think you need to do. Once you start to put the product together you may not need those things but once they are listed as part of the work to do – and especially if they have been promised to someone – then not doing them can be problematic.
Anyway, having written this blog I now wonder if I should have bothered. Now I look about a lot of other people have made similar points already. As I have been writing this post I thought I should find a definition of Sprint Zero, so I did a search. Interestingly, most of the articles that came up on page 1 of Google are also critical of Sprint Zero for similar reasons to myself. So maybe Sprint Zero is an idea whose time has already come and gone.
The post Sprint Zero appeared first on Allan Kelly Associates.
Matthew Butler from arne-mertz.de
This week’s guest post is by Matthew Butler, who shows us some insights about how the relationship between complexity and performance can be less than obvious in multiple ways. Matthew […]
The post Complexity Theory, Relativity and The Theory of Everything appeared first on .
Derek Jones from The Shape of Code
The idea of proving programs correct, like mathematical proofs, is appealing, but is based on an incorrect assumption often made by non-mathematicians, e.g., mathematical proofs are fault free. In practice, mathematicians make mistakes and create proofs that contain serious errors; those of us who are taught mathematical techniques, but are not mathematicians, only get to see the good stuff that has been checked over many years.
An appreciation that published proofs contain mistakes is starting to grow, but Magnificent mistakes in mathematics is an odd choice for a book title on the topic. Quotes from De Millo’s article on “Social Processes and Proofs of Theorems and Programs” now appear regularly; On proof and progress in mathematics is worth a read.
Are there patterns to the faults that appear in claimed mathematical proofs?
A surprisingly common approach, used by mathematicians to avoid faults in their proofs, is to state theorems without giving a formal proof (giving an informal one is given instead). There are plenty of mathematicians who don’t think proofs are a big part of mathematics (various papers from the linked-to book are available as pdfs).
Next time you encounter an advocate of proving programs correct using mathematics, ask them what they think about the uncertainty about claimed mathematical proofs and all the mistakes that have been found in published proofs.
baron m. from thus spake a.k.
Andy Balaam from Andy Balaam's Blog
If, like me, you are this person:
You may want to fix the stupid :slightly_smiling_face: messages you receive from Slack via the IRC gateway. Obviously, I’d prefer they went away entirely, but it’s still better to see a character than being spammed with colon abominations all over the place.
You’ll need the Python emoji package, and a HexChat plugin like this:
# Replace all the horrible :slightly_smiling_face: rubbish that Slack inserts
# into horrible Unicode emoji symbols.
# Author: Andy Balaam
# License: CC0 https://creativecommons.org/publicdomain/zero/1.0/
# Requires https://pypi.python.org/pypi/emoji - I used 0.4.5
# I manually copied the emoji dir into:
# /home/andrebal/.local/lib/python2.7/site-packages
import emoji
import hexchat
__module_name__ = "slack-emojis"
__module_version__ = "1.0"
__module_description__ = "Translate emojis from Slack with colons into emojis"
print "Loading slack-emojis"
chmsg = "Channel Message"
prmsg = "Private Message to Dialog"
def preprint(words, word_eol, userdata):
txt = word_eol[1]
replaced = emoji.emojize(txt, use_aliases=True)
if replaced != txt:
hexchat.emit_print(
userdata["msgtype"],
words[0],
replaced.encode('utf-8'),
)
return hexchat.EAT_HEXCHAT
else:
return hexchat.EAT_NONE
hexchat.hook_print(chmsg, preprint, {"msgtype": chmsg})
hexchat.hook_print(prmsg, preprint, {"msgtype": prmsg})
According to the page linked above, Slack are retiring the IRC gateway, which will make me very unhappy.
Update: added support for private messages too.
Patrick Mintram from arne-mertz.de
Today, Patrick Mintram presents us with a guest post about design patterns in real life applications. Patrick has been in and around engineering for about 9 years, the last 3 […]
The post Design Patterns in Real Life appeared first on .