October's Theme is
Programmers who remember to consider the business impact of their decisions are worth their weight in gold. Steve McConnel
Code Complete 2 (http://www.meetup.com/Londonjavacommunity/events/mhtml:%7BCC2EED15-4DA8-4A53-8B53-E3EED5C6CFA8%7Dmid:/00017004/!x-usc:http:/www.cc2e.com/)
When writing code it is the decisions that we make that really matter. What we type is secondary, the result of those decisions. When reading code what we are really interested in is seeing what decisions were made. What choices were made? Were they the right choices?
Each module is then designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing. David Parnas
On the Criteria To Be Used in Decomposing Systems into Modules (http://www.meetup.com/Londonjavacommunity/events/mhtml:%7BCC2EED15-4DA8-4A53-8B53-E3EED5C6CFA8%7Dmid:/00017004/!x-usc:http:/sunnyday.mit.edu/16.355/parnas-criteria.html)
Sometimes the author will want to hide their decisions from us. This is the goal of encapsulation in Object Oriented design. This can make the code harder to read, but can also make it more interesting. When reading the code we are like detectives who can see the means but must work to uncover the motive.
Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it. Joel Spolsky
Hard-assed Bug Fixin' (http://www.meetup.com/Londonjavacommunity/events/mhtml:%7BCC2EED15-4DA8-4A53-8B53-E3EED5C6CFA8%7Dmid:/00017004/!x-usc:http:/www.joelonsoftware.com/articles/fog0000000014.html)
In the hard commercial world the hardest decisions are about what we won't do. The economic reality is that resources are scarce. How can we tell the difference between avoiding wasteful gold plating and accruing technical debt for which we will pay dearly in the long term? I hope you decide to join us on Wednesday 12th October. We've taken on board the advice from last month and hope to keep making it better.
October's Coding Challenge is
21 Lines of Python
One of the key decisions we take when starting is a project is choosing the programming language. Surprisingly, many developers never choose to make this decision. Instead they just use the same one every time. To help us consider the consequences of our language choice we're gong to look at a spelling corrector written in just 21 lines of python. (http://norvig.com/spell-correct.html)
import re, collections def words(text): return re.findall('[a-z]+', text.lower()) def train(features): model = collections.defaultdict(lambda: 1) for f in features: model[f] += 1 return model NWORDS = train(words(file('big.txt').read())) alphabet = 'abcdefghijklmnopqrstuvwxyz' def edits1(word): splits = [(word[:i], word[i:]) for i in range(len(word) + 1)] deletes = [a + b[1:] for a, b in splits if b] transposes = [a + b + b + b[2:] for a, b in splits if len(b)>1] replaces = [a + c + b[1:] for a, b in splits for c in alphabet if b] inserts = [a + c + b for a, b in splits for c in alphabet] return set(deletes + transposes + replaces + inserts) def known_edits2(word): return set(e2 for e1 in edits1(word) for e2 in edits1(e1) if e2 in NWORDS) def known(words): return set(w for w in words if w in NWORDS) def correct(word): candidates = known([word]) or known(edits1(word)) or known_edits2(word) or [word] return max(candidates, key=NWORDS.get)
The code defines the function correct, which takes a word as input and returns a likely correction of that word. For example:
>>> correct('speling') 'spelling' >>> correct('korrecter') 'corrector' How many lines are needed to achieve the same in Java? We'd like to see as many versions in as many languages as possible, so that we can look at the differences. Does another language make it smaller, faster, more memory efficient or easier to comprehend? If you'd like to submit a translation please have it with us by Friday 9th October.