Programming and journalism

I was struck recently by the parallels between journalism and programming. I've written a few articles for different publications over the years and learned a bit from the editors of journals about what they wanted the copy to look like. Certain things stuck out as being either similar, or lessons that developers could learn from journalists:

House Style

Every publication has it's house style. Tabloid newspapers use short, declarative sentences, limited vocabulary, and lots of emotive language. Academic journals all prefer their text to be in the third person. Orthography varies too, the house style always defines layout, fonts etc.

Similarly, a development team/organisation often has a requirement for the following:

• bracing style
• naming conventions
• comments / inline documentation

In environments that lack a house style document, I've sometimes written one up by querying the preferred style with the existing team. It makes code easier to read and more consistent.

Editorial requirements

This is more something that should be, than something that is. Code review often tends to be neglected, mainly because project timescales are often tight. For reasons why that is the case, see Frederick Brooks' "The Mythical Man Month". If you follow Brooks' advice of having one person integrating code, they're effectively doing the job that a publication editor/subeditor does - checking that content is formatted correctly, readable, fits with house style and so on, to make a consistent product.

Specialisms and research

Everyone has their specialities. I specialise in Assistive/Care oriented Technology, identity management, web services and a few other less well defined things. I speak Java, Perl, PHP, Javascript, and to a lesser extent Ruby.

But like a journalist called upon to write outside their speciality with good research disciplines and care a developer can do a decent job outside their immediate speciality, or learn a new one rapidly. The economics correspondent can do a decent job of reporting political stories, and the server developer can make a decent job of web development if needed.

Any others?

I'm sure there must be other parallels. I'll update this post if I think of any.

What makes a maintenance programmer

I love maintenance programming. This makes me a freak among developers. If you look at the job adverts, they're all full of 'greenfield development', 'the chance to define direction' and similar phrases. Original development is interesting and fun, but there's a lot to be said for the Sherlock Holmes experience of bug fixing someone else's code. You have to put yourself in their position, learn from their coding style how they're likely to have approached a problem, keep track of complex code pathways to remember where you are. It's extremely tiring because the concentration demands are high, but it's a fascinating challenge.

It's always useful to be good at, and interested in something most other people hate. Anyone got any really ropey legacy applications they want maintaining?

Eclipse juno, getting rid of mylyn

This morning I've done about 60 minutes work. The other 120 minutes was spent watching the 'busy' pointer, waiting for eclipse to do.....something.

Experience tells me it's something mylyn related. Unfortunately Juno comes with mylyn, and it's not easy to remove.

Or is it?

Preferences->Java->editor->content assist->advanced.

Deselect anything marked 'task oriented', and replace it with the non task-oriented version.

Now go into your eclipse plugins folder and remove anything to do with mylyn.

Hurray! My IDE works again :-)

A simple solution to the plague of automated sales calls

The last few years, the problem of automated sales calls, both those that connect you to a salesperson, and lately the much worse ones that play an automated message, has got out of hand. There is a very simple solution - it does require legislation, and a little technical implementation, but it exists:

Step one:

legislate cold calling as an offence, particularly calls with a recorded message. 1000 GBP per offence strikes me as a nice sized penalty. Place the onus on the caller to prove that the recipient has opted in to their mailing list.

"But", I hear you protest, "we have legislation to prosecute cold callers already and it never gets enforced. The caller just withholds their number or provides a bogus one".

That's where step two comes in:

introduce an offence - routing a call where caller ID isn't presented. Large penalties on the telecoms companies for failing to provide accurate caller ID information on every call. Domestic subscribers don't see this, but multi-line commercial phone connections include the facility to set up the caller ID. The subscriber chooses what caller ID to present to public view. That's why you get calls from "12340 000000" etc.

There are a few possible objections:

"It's important to allow subscribers to withhold their number to protect their privacy" - ok, so if a domestic subscriber requests to withhold their number, present a separate number that won't connect to them, but is nevertheless registered with their phone company to their name.

"Sometimes we don't have the caller ID information" - the telecoms companies always have an origin of the call - otherwise, how would they know who to bill? It's a fairly trivial software problem to present it. If it's a call coming in from outside their network (like an international call), they can present a number for the telecoms company routing the call. We'd soon get to know who the spammers were, and start blocking them. If XYZ telecom is the origin of 90% of my spam phone calls, I'm going to block it whether any of my friends use it or not, then suggest to them that they move providers.

"It's too technically complex" - not true, see above.

"It's too expensive" - really not true, see above.



A year or two of that, and we'd soon see an end to

"You may be entitled to a refund on your PPI payments....."

Freeswitch WTF?

Freeswitch is apparently 'very NAT friendly'.

No kidding. I've spent most of today trying to stop it from binding to the outside of the firewall and allowing anyone and everyone to try and authenticate, filling my logfiles with shite.

-nonat -nonatmap - doesn't appear to work, on windows at least. Nor does any combination of them.

commenting out every instance of

<param name="ext-rtp-ip" value="auto-nat"/>
<param name="ext-sip-ip" value="auto-nat"/>

doesn't work

<param name="ext-rtp-ip" value="192.168.255.255"/>
<param name="ext-sip-ip" value="192.168.255.255"/>

doesn't work.

At the moment, I just want to use this thing internally as a test switch. I'm spending a *lot* of time trying to lock down the default config, instead of debugging my code. This is not good, and inside a private network it should not be necessary.

Addendum:

I raised the question (extremely politely) on the freeswitch users mailing list, and got this response from one of the projects senior members:

"It has NOTHING at all to do with the ext-sip-ip and ext-rtp-ip settings, If

you don't want outside access then block it at your nat/firewall."

That's all - no "Hi", no sign off, just that. Rude, aggressive, shouty and unhelpful.

I'm using Asterisk now. Ho hum.

A very short introduction to software testing

1. Introduction

This is intended as a very short introduction to testing, for programming novices and beginner developers without a lot of formal training. Skilled developers will find much to criticise here because I've necessarily simplified things a lot, but they're not the target audience.

2. Why do we test?

We test because bugs are inevitable. Software is complex. Very complex. The number of variables involved in any non-trivial program rapidly becomes impossible to keep a track of, and as soon as you can't conceptualise your entire program mentally throughout it's run cycle, things are going to slip through the cracks.

We test because we don't want those bugs to cause problems.

We also test because we don't want bugs to slow the development cycle down: if you do no testing at all, when the code goes for UAT (see 'types of testing'), the user finds shedloads of bugs, writes them up and you fix them. But that takes a lot more time than you finding most of the bugs as you go along. Plus you look like a pillock if your code is really buggy.


2. Ways of testing

Basic 'try it through the UI' - assuming your code has a UI, just run through it the way the user would. To make sure you're trying every pathway, you need to produce use cases. These are the different ways in which the program will be used: for example, a typical use case for using a 'user profile edit' component might be:

Select user
Click edit
Change 1 or more details
Click save

Don't forget about the 'change your mind' scenarios like:

Select user
Click edit
Change your mind and click cancel.


Automated testing - this is the preferred way of doing things. Most languages have a preferred test framework (jUnit in Java, Test::More in Perl etc). There are advantages and disadvantages to automated testing:

Pros:

• you only have to write the test once
• changes to code can be easily checked for knock on effects elsewhere
• during slow periods in a project, writing tests is a productive use of time
• automated tools exist to identify which parts of your code are tested and which aren't

Cons:

• the test suite is more code to maintain
• Writing a test case usually takes longer than testing the UI, when under time pressure it can be easier just to test the UI
• Creating and maintaining test data can be a pain - databases usually need to be 'mocked', as do network services, which is extra overhead.
• Some thought needs to go into designing your test suite if you don't want to end up with tons of cut and paste code, this takes time.

Generally, I find that automated testing results in better, more reliable code and fewer bugs reaching regression testing (see below) but does often take up more time. In a project where the user / project management wants the moon on a stick, yesterday if not sooner, it can be difficult to find time to build proper test suites. This is one of the many reasons why projects run that way tend to result in low quality code (note to project managers - setting short deadlines is not an effective way of getting the most out of a development team. Go read 'The Mythical Man Month'. Do it now).

3. Types of testing

Smoke - literally 'switch it on, does it catch fire'. Compile the code, run it, see if any exceptions are thrown.

Unit - testing the component you've been working on.

Integration - test the integration of the component with the rest of the software suite, make sure that you haven't buggered anything elsewhere in the suite by this set of changes.

Functional - test the functionality of the program. Specifically, test the functionality you have been working on in this development cycle.

Regression - test everything, to make sure that the whole suite works.

UAT - user acceptance testing: performed by the customer/consumer to ensure that they are satisfied with the product.


4. Test Driven Development

TDD is a way of producing very high quality code in a mature development environment. Under TDD, the tests are developed first, from the design documentation. The functional code is then written to fulfil the tests. That way, you're absolutely certain that your code matches the design.


5. Conclusion

Structured formal testing is a vital part of professional development, and testing skills are an integral part of what makes a good developer. Good code testing skills will make a huge difference to the quality of your code.

Threads and AsyncTasks - a quick note

Today I discovered that very long running network operations completely bugger your android UI thread if run in AsyncTasks, and really need to be pushed out to a proper java thread.

Hopefully that will solve the UI crashing during data refresh.