If at first you don't succeed, call it version 1.0

Tag Archives: language

Depending how you look at it, my interview with RainBird was either non-existent featuring, at best, an informal chat; or it was a gruelling 5 year affair where I had to prove myself by working my way up the ranks of a totally different company. Either way it wasn’t your standard technical interview.

I’ve written on the subject of interviews before, but that was for an established company hiring a developer. At a startup you’re hiring a manager/secretary/handyman who can also code and do a million other things that need to be done, which is a very tall order. I’m not entirely sure how you’d go about doing that without knowing that person and seeing, first hand, what that person was capable of over a prolonged period of time.

This approach to hiring means you can dispense with the incredibly narrow (and often counterproductive) fallacy that you must hire someone with X years experience in technology Y1, because that’s what you use. RainBird needs developers who can code in Node.js, AngularJS, plus a smattering of C++ and Prolog. If we’re charitable I have 1 months worth of industry C++ experience… from over 15 years ago.

Despite that seeming handicap I like to think I have a good understanding of a number of programming languages, including Javascript, a good grasp of architecting systems, the ability to manage a team, a broad set of organisational skills and the ability to build furniture that means, regardless of the technology being used, the longer term benefit I bring to the company by far and away beats the incredibly short term drawback of me having to get up to speed with some new stuff.

1 And don’t get me started on the whole “must be a self starter; must work well by themselves or as part of a team; must have excellent communication skills”; what does that even mean? You’d be unlikely to hire a lazy illiterate who didn’t play well with others for something as simple as a job at McDonalds, let alone put them into a development role – please, for the love of God, stop putting this crap into job specs.

During the last nor(DEV): we tried something a little different: a Question Time style panel where the ‘audience’ asked a panel of guests a series of contentious questions. These were then debated by both the panel and the audience. While the questions may have been pre-prepared the debate that followed was not, which resulted in some interesting discussion.

One of the questions that interested me the most was regarding PHP and its status as an ‘Enterprise’ level language. With my recent experience with PHP I’ve found my attitudes to it have changed drastically. This has resulted in, for me, a startling conclusion.

Historically I’ve been a Java developer. While we know Java is an enterprise language (it says so on the tin), I didn’t start out that way. While I’ve dabbled in Ada (university) and C++ (early graphics programming for fun) my first commercial programming was done in Perl and TCL. I may have been at a large enterprise, but, by my own definition, I come from a Script Kiddie background. Perhaps I’m a little more open to scripting languages than others.

That said, I’ve always felt that scripting languages have somehow been less than ‘proper‘ languages like Java. Still, right tool for the job and all that, and given I’m not getting away from PHP anytime soon1 I decided to look at exactly why PHP wasn’t as ‘good’ as Java.

It’s not Object Oriented

Having done OO for a large part of my programming life I find it hard to use anything that doesn’t support objects. I suspect this is more a failing of the developer than functional programming, however, it’s a moot point as PHP is a fully OO language, I just needed to RTFM.

It’s not got a proper IDE

Around 1 or 2KLoc2 I find I’ve now got more objects than I can remember the interfaces for, which results in lots of bouncing between files to refresh my memory. This can get problematic when it breaks my train of thought. I’ve tried a number of editors and found Sublime Text was OK, but it wasn’t Eclipse. Thankfully I found PHPStorm, a proper IDE for PHP that works on a Mac. It shares a number of features with Eclipse (including being as buggy as hell) and has massively improved life when writing PHP. It costs money, but the investment is well worth it if you’re doing anything more than dabbling in PHP.

You can’t test it easily

Actually, there’s PHPUnit which I now prefer to JUnit. OK, so unit testing the code that actually renders your web pages isn’t so easy, but if you’ve got proper separation of responsibilities there should be minimal code before it hands everything off to your fully tested backend code.

It lacks ‘modern’ features

Such as…
PHP can handle closures so it’s actually more feature rich than Java in some respects. The way PHP handles method overloading is convoluted to say the least, but method overloading isn’t exactly modern and I suspect it stems from the way that PHP handles varargs (something else Java only got recently).

The code is hard to read

Yes, a lot of PHP is hard to read (go look at the WordPress codebase) but I don’t think PHP is to blame here. I spent the longest time trying to bludgeon PHP into looking like Java when I should have been bludgeoning my brain into thinking the PHP way – something I’ve finally done.

I think this last point is key when it comes to the problems with PHP. The barriers to entry with PHP are very low as you can throw together a usable web app with a UI very quickly, even as a novice developer. The result is a lot of bad PHP out there in the wild which lacks the design, testing and layout that us ‘proper’ developers would use with our ‘grownup’ languages. I’ll freely admit that some of that bad PHP belongs to me. Having matured as a PHP developer I’m hoping my next application will see me being a ‘grownup’ PHP developer.

This is a similar conclusion that that nor(DEV): panel came to. The question isn’t “is PHP3 an enterprise language?“, it’s “are your developers enterprise level developers?“.

1My hosting provider, while nice and cheap, are rather limited on what I can run, thus PHP for my personal projects.

A personal bugbear of mine is developers not being able to write clear, effective logging. This seemingly trivial task appears to cause a great number of developers no end of problems, and yet it shouldn’t necessarily be that hard. Why is it then, that when I go to interrogate a log file I have to trawl though kilobytes (or worse) of meaningless rubbish to determine that:

That’s a real error message from a system I work on, and that’s all it had to say about the matter. I despair.

There’s a few basic things you can consider that will make you logging a lot more effective.

Use the appropriate log level

Fatal should be reserved for when an application, or a thread, is about to be terminated in a fashion that really isn’t expected. Errors should indicate something recoverable [at an application level] that’s gone wrong that wasn’t expected. The vast majority of fatal and error log messages are really warnings, that is messages indicating that an error has occurred but we’ve been able to carry on. Any occurrences of a fatal or error level message in your logs should have attendant bug reports with either code or configuration fixes to remove those errors. Informational messages should relate to things that people will care about day-to-day, or as additional log output for an initial higher level log output. Everything else is a debug message and will generally be turned off in production systems.

Provide the right level of information

Logs are text, are often large (I’m looking at 2 production log files that are in excess of 12Mb) and are often going to be parsed with simple tools. If I use grep ERROR *.log I should be able to see each error, and enough information about that error to give me a high level overview of what is happening. More diagnostic information can follow the initial error at lower logging levels. There should be enough information following the error that someone reading the log file with default production settings can diagnose the issue, but not so much that they’re drowning in log lines.

Format the messages correctly

Be mindful that when you concatenate strings you may need spaces and other delimiters between output. When you split your output over multiple lines those lines may not be seen on an initial parse of the file. Also, be mindful of how values are going to be displayed. With Java the default toString method on an object isn’t the most useful of outputs in a log file. In contrast, some objects are verbose in the extreme and may break the formatting of your error message by spewing a multiline string onto your single line error message.

Some real world examples

I regularly check our production log files for a number of reasons and find myself facing such doozies as:

The kicker here is that this could be one of a number of errors. If I see this twice in a log file I have no way of knowing if it’s the same error twice, or two different errors. The error message is badly formatted with the information [hundreds of lines of it] on the next line. Sadly I see this more than a couple of times a day and, as it’s a third party bit of code that’s responsible, theres’ not much I can do about it.

126 occurrences in todays log files. This needs to be a debug message and an error output if it fails to establish or close the email transport connection. Ironically enough, as I was digging into the code to fix this I discovered that when it does go wrong it reports the error 3 times in 3 different places, resulting in 3 error lines in the logs. Worse still 2 of these lines only state “Error sending email” with no other information other than a stack trace from the exception. That’s three slightly different stack traces, two useless error lines and one useful error line for 1 error which could easily add 15 minutes to the diagnosis time while the developer tries to work out what’s going on.

Well over 1000 occurrences today alone! My grepfu is reasonable so it I altered it to show the line after that. Turns that someone is trying something nasty with some of our search URLs, but that wasn’t immediately obvious from the error, instead I was resorting to the stack trace. Not only could the error be improved, but we can also downgrade this to a warning. Looking at the code this is only going to happen in two cases: either someone has put a bug in the code, in which case we’ll see thousands of identical warnings and do something about it; someone is trying something nasty when we’d see hundreds of variations on the warning which we can investigate and then improve or ignore depending on the outcome of the investigation. Bug raised to fix both the handling of dodgy URLs and the logging level.

I’m sure I could dig out loads more and thats just with a cursory glance of the files. Logging is an important diagnostic tool, but it’s only as good as you make it.

I’ve started using BDD scenarios for most things now as I find the Given/When/Then syntax great for focusing on the problem and generating questions. What I have found though is that often the questions need to be written down somewhere to ask the relevant person. Correlating the questions and the scenarios can be a pain so I’ve started putting them inline into my scenario text using a ?? notation. The format is simple:

?? on it’s own: denotes an outstanding question about the preceding text.

word??: denotes a question about the preceding word.

?option/option?: denotes uncertainty about which option should be used.

?question?: denotes a question being asked.

This syntax can actually be used to write the original scenario:

Given ??When ??Then ?? should ??

An example of this usage might be:

Given a user on a web?? formWhen the user ?enters/selects? ?should we be thinking about how the provides the data? their D.O.B.Then the form should ??

A discussion, which could be via email or some other means than face to face, can than be had to resolve the questions using just the scenario files and the annotations to the scenarios. You could even go one step further and use something like Gollum to track the changes to the scenarios.

Share this:

As part of Kevlin Henney‘s presentation at Sync Conf he showed a technique of visualising your code using Wordle. In a nutshell you strip the comments from your code (lumping it into one giant file in the process), pop it into Wordle and see what drops out. The theory behind this process is that, once you get past the scaffolding of the programming language, the language of the domain should become apparent. The results are very interesting.

I know there’s problems with our main code base. I work on it daily and the entire team knows about the issues at a near visceral level, but finding ways to express and visualise the problems can be hard. Today I discovered I work in a domain of java.lang.String and null. Not great for an OO language. Even the language scaffolding told a story. The relative size of the import keyword to the class keyword show we’ve got a lot of dependency issues.

More surprising was the result from our newer code base. Here the language of the domain started to show through, but it coloured by the unit tests which I’d forgotten to remove. On the plus side @Test features highly, as does final. Tomorrow I’ll generate a few more Wordles without the test code and use it to spark some discussion on our new architecture in our retrospective.