Wireless preferrred networks on OSX

I've had a frustrating issue with a MacBook Air running OSX 10.7.5.  Having closed the lid and travelled from work to home I' d open the machine and wait for it to find the wireless network.  All to no avail - a dialogue box pops up saying "None of your preferred networks could be found" and presenting me with a list of detected networks including my home, preferred network.

Browsing through the airport documentation I eventually found the solution:

airport prefs JoinMode=Preferred JoinModeFallback=KeepLooking

Now, rather than prompting, the laptop just keeps searching for one of my preferred networks.  I'd apparently been on the threshold of some timeout: the laptop now picks up my home network with no problem.  

We're doing Agile, right?

Agile Software Development has taken off big time: it appears on every one's CV, you can do M.Sc's in it, all the cool guys are into Agile. And we're doing it too.

No.

Agile cover a multitude of methodologies but I'll stick to one of the first formalisations: Extreme Programming or XP. This made a number of trade offs: you don't have to do A because you're doing B which will cover the same ground. The obvious side effect is that if you're not doing B you're in trouble.

Let's look at some concrete examples. Programmers like to program so the release from large scale up front design is often welcomed. Up front design is used in waterfall development to ensure that the group know what they're all trying to build an that the final product has a suitable architecture for the task at hand. So how does XP (or any other Agile approach) handle this?

DRY

Don't Repeat Yourself. If you see a piece of duplicate functionality, factor it out. This provides a retrospective design to your software. But wait, changing software is dangerous so you'll need

Comprehensive Test Suite

With good test coverage there's little risk involved in modifying code and if you do something stupid there's always your buddy to fall back on.

Pair Programming

Let some one else look at the code you're writing. They'll pick up mistakes you've made, point you at other bits of the system that look similar and be some else to fix the bugs whilst you're on holiday.

The important thing to notice is that all the pieces are entwined. If you don't refactor the code you'll end up with spaghetti code because you didn't do big up front design. If you don't have comprehensive test suites your refactoring will break things. If you don't pair program or code review then, in the absence of design documentation how does the system architecture get communicated?

Agile development is a high discipline approach to software development. It forgoes some of the safety nets of traditional software development and instead utilises other practices in an attempt to improve development efficiency. If you ignore the replacement practices you've no longer got a safety net and you're just hacking at code till it sort of works.

Org-mode and Microsoft Word

One of my less enjoyable tasks is to produce a weekly status report following a particular look. This then gets emailed off and compiled with others. Unsurprisingly the format has to be Microsoft Word and no one ever gets the use of format styles correct.

Editing the pro-forma always has me cursing: delete one character too many and fonts change, bullets appear or disappear, all the usual joys of Word.

Emacs, and more specifically org-mode to the rescue. Org has had the ability to export in several formats (typically LaTeX and HTML) for quite some time but now boasts support for OpenDocument format too.

So my status reports are now written using Emacs with a line setting org-export-odt-styles-file to point at a hand handcrafted OpenDocument template file. That sorts out the presentation aspects of the final document. C-c C-e o exports my text to OpenDocument then open that in LibreOffice and save as Microsoft Word format. The conversion from ODT to docx format can be automated: soffice --headless --convert-to docx myfilename.

I wouldn't say that I actually enjoy writing my status reports now, but at least it's considerably less painful, I can just get on with writing information and not with fighting the tools.

The power of scripting

Interesting problem last night: I wanted to find out how far it was
between a bunch of places. I had the location post codes buried away
in a stack of form letters in pdf form. So convert those to text,
open in emacs and extract the post codes. I couldn't get multi-line
replace-regexp to work, re-builder successfully highlighted the
line but replace-regexp failed to match the same regex. Oh well, I
just want to hack this out so keyboard macros did the job.

A quick google later and I came up with the static maps API
so threw the post codes at that to get back a JSON object with all the
distances. Then using json.el in ielm, convert that to a lisp
structure, pick that apart to extract the relevant fields and run my
calculations over that, plotting the results using R in org-mode.

We have some fantastic tools at our disposal: this is a fun game.

So, back to the multi-line regex that fails. I've got an input file in
the form:

a
1
b

a
2
b

and want to match the paragraph a..b Using re-builder I can construct
a regex that matches:

"a\\(.*
?\\)*?*b"

But using that regex in replace-regex results in no matches.
Digging in to this it turns out that, because I'm using replace-regexp
interactively the escaping rules are slightly different: I only need a
single backslash before the brackets.

When is a solution good enough? The keyboard macro approach did the
job quickly and easily. I then spent longer trying to debug the
multi-line regexp than it would have taken me to solve the original
problem by hand. But I learnt something in the process so surely that
is time well invested. Besides it was fun!

On inheriting a code base

I've recently been given access to a new code base.  It represents a
reasonably successful product but there's something not quite right.
I spent a while browsing through the code trying to get a feel
of things.  The problem is that the code is adequate rather than
elegant. 

There's a fair amount of code duplication.  Not out and out cut and
paste (though there's a bit of that too), but similar functionality
acting on different variables or calling with slightly different
parameters.  It's all things that could be factored out but haven't
been.

Then there's the code style.  It's all incredibly defensive with lots
of checks for null values which are dutifully logged then the
application proceeds on its merry way.  So who's to know that
something went wrong?

Comments - well no not really. There's almost a complete absence of
comments, nothing to explain the "why" of what's going on.
So what's the reason for this?  The team who wrote the code are a
bright bunch and they've been doing this stuff for a while.  There's a
lot of  the other trappings of good code development --- unit tests,
continuous integration servers --- but the raw stuff of our craft,
the code, just isn't up to scratch.

I asked about code reviews.  They're on the list of things to set up
when the team have the time.  Unsurprisingly there's never time as
more features are requested.  And anyway who wants to go into a two
hour meeting to have their code picked apart by some smart alec who
thinks they can do better.

So what needs to be done to change this?  The goal must be to make the
developers proud of their code, happy to show it to all and sundry and
keen to receive feedback so that they can improve it. But at the
moment every one is sitting in their own cubical, beavering away on
the latest task passed down by the management. 

So here's what we're going to try:

- Pick a file that typifies the problem and set the team a challenge.
  What's the most elegant way we could write this code?
- Discuss what we mean by "elegant".  Obtain team agreement that these
  are our values.
- Institute light weight buddy code reviews of all check ins

A side thought: why is it that code reviewers always pick out the
negative?  There are a lot of studies singing the praises of positive
enforcement so why don't we try to praise the good bits rather than
pick holes in the bad?