Hi all,

I’m sorry to announce that we’ve spotted a slight problem with the Mac App store version of Neu 1.0.3 - only two of the preference panels load successfully.

This problem doesn’t affect the version of Neu that you download from here, so if you’ve bought Neu directly from us, you can safely update.

However, if you’ve bought from the Mac App store, we’d ask you to hold of updating until we can work out what’s going on and submit a fix.

If it’s too late and you’ve already updated, Neu should continue to work ok, you simply won’t be able to adjust certain preferences. Which is obviously not ideal, so we’ll get a fix out to you as soon as we possibly can.

I’m happy to announce that Neu version 1.0.3 is now available, both from this website and the Mac App store.

Version 1.0.3 is a bug-fix release, containing the following minor improvements:

• Remove/add buttons update state correctly in templates and keywords preferences
• Fixed window resizing
• Improved communication with the Finder to work out what folder the user wants to create items in.
• Improved text of “Add License…” menu item and file dialog (This change does not apply to the Mac App store version of Neu, which does not have an “Add License…” menu item).

To find out more, or give Neu a spin, please see the main Neu homepage.

Things have been a little quiet around here lately, as we’ve been tied up with quite a bit of contracting work.

However, we’re happy to say that some updates to our own applications are also on the way. Both Neu 1.0.3 and Ambientweet 1.0 have now been submitted to Apple for release to the Mac App store.

Beta releases of both of these can also be found on our Beta Software page.

With Ambientweet, we needed to decide on a pricing policy as part of the submission.

Eventually Ambientweet will be sufficiently feature-rich to justify charging for it, but for now it is quite simple, so we’ve decided to make it the initial version free on the Mac App store! If you download it there when it becomes available, you should be able to get subsequent 1.x updates free as well.

When we change over to charging for it, we’ll probably create a new “Pro” version of the application which you have to buy. At that point we may well also introduce some sort of “Lite” version which contains advertising.

I was going to post something about NSConference 2011 anyway, because I agree with the general consensus - that it was bloody brilliant.

Danny Greg’s post has spurred me into action though, because I sort of agree with him, and sort of disagree!

It is certainly true, as Danny said, that it was great to add some more non-programming perspective to an already excellent conference format.

Having some entrepreneurial input was great, as so many of us are dipping our toes in the indie waters. I found both Kevin Hoctor and Ken Aspeslagh’s talks reassuring, inspiring and challenging in equal measure. They managed to pull off a rare trick - talking to developers about business in a way that made the developers want to listen.

And as Danny pointed out, having some more design/interaction sessions was also fantastic. There were lots of great speakers on this topic (including those like Matt Gemmell who’ve spoken in previous years), but Cathy Shive and Aral Balkan were my favourite sessions.

Where I slightly disagree with Danny is in the idea that need for good design is a change that’s just been happening “for a while”. The implication being that whilst it didn’t happen yesterday, it’s happened in the last few years.

The fact is, the need for good design has always been there, and good design has always been evident in the truly good software. Apple have known this all along. I tweeted to Aral about the fact that I thought he was a fan of Don Norman based on the content of his session (he is). The session’s title was a big hint, come to think of it (if you haven’t read The Design Of Everyday Things, do so!). Don was already in my mind though, as a lot of what Cathy said in her talk the day before also made me think of him. The reason I know about Don Norman at all was that he was knocking around at one of the early WWDCs that I went to, in about 1995. That was because Apple had just hired him (it didn’t stop them having a good many design related disasters over the subsequent years, but in theory at least, they’ve always known the value of good design!).

I believe that the best programmers, like the best graphic artists, the best engineers, the best musicians and authors and scientists, have an ability to transcend technique. They may be brilliant technicians in their chosen field, but they also have the ability to strip away all that skill and get to the essence of what’s important- which is why that Antoine de Saint-Exupéry quote is so relevant.

They have an aesthetic appreciation for function, as well as form, and they can whittle away at a design until all it is clean, and elegant, and entirely user centred. This manifests itself in software as something that does the what the user wants - intuitively, delightfully, effortlessly.

I believe that this ability, this particular sort of focus and clarity of thought, is inter-disciplinary, or perhaps cross-disciplinary, or, to put it in nerd terms, it’s orthogonal to the other stuff.

I also believe that having this ability is what we mean when we say “designer”. You can be an average artist, programmer, entrepreneur, and also a great designer. Or you can be a prodigy in your chosen field, and a piss-poor designer. I’d hazard to say that I don’t think you can be truly great at whatever it is you do unless you have both the technical chops and that focus on design.

In a conversation outside the sessions (that I was loitering on the edge of!), Aral and Cathy were both talking about the fact that programmers have a tendency to confuse the ability to draw with the ability to design. Cathy (I think) was also saying that many programmers have that design ability - and that it manifests itself in other ways, like designing nice APIs. That we tend not to give ourselves the credit that we deserve, and also tend not to recognise how we can transfer these skills.

I think that’s true - many programmers are too hard on themselves when it comes to design - but there is also a converse truth. In my experience, many programmers are actually piss-poor at designing APIs! The same thing that makes them bad at designing user interfaces actually makes them bad at designing code too. They overcomplicate, or they over-focus. They fail to see the cheesy wood texture for the b-trees. They are actually not good designers.

I’m generalising of course, but I do actually think that this is a character trait that’s quite common in programmers, and whilst we’re being generous about ourselves in other ways, we also have to recognise the fact that many otherwise good programmers can’t design. They do lots of things that are absolutely essential, but they can’t, and shouldn’t, be responsible for the design!

An appreciation for design is critical to making good iPhone apps. It’s also critical to making good frameworks. Or good chairs. It is therefore essential that we are aware of the importance of design. It doesn’t mean that we’re all going to suddenly become designers - some of us will have to settle for being really good programmers who work with really good designers.

It does mean that it’s really great to have such excellent design related sessions at NSConference!

Recently I’ve started some contracting work with a new client, and rather impressively they have a coding standard. This is most definitely a good thing.

However, this standard, like most, includes some stuff relating to text formatting, and it happens to be different from the way I like to do it.

I tend to agree with Sutter and Alexandrescu on this sort of thing. In paragraph 1 of item 0 of their C++ Coding Standards book, they say:

“Issues that are really just personal taste and don’t affect the correctness or readability don’t belong in a coding standard. Any professional programmer can easily read and write code that is formatted a little differently than they’re used to.”

They go on to say that you should try to use consistent formatting within a project, because jumping between styles is jarring. I agree in principle, but in practise, I’d go a little bit further than them. People are different. Experienced programmers can read code in pretty much any format. Experienced programmers also have years (or decades) of muscle memory which means that with the best will in the world, they’re likely to slip and use the formatting that they’re used to.

My advice would be - use common sense, and be forgiving. This cuts both ways of course. Whenever I’m working with other people’s code I try to adopt the style that seems to be prevalent in it. When I was younger I would dive in and reformat files - these days I just try to live with it. Having said that, when I write any substantial amount of new code, I’m not thinking about where to put the brackets, so I slip up and use my own style sometimes. What can I say? Live with it.

Thinking about all of this reminded me of something I’ve often thought. How bloody ridiculous is it that we’re still storing source code as plain text?

I don’t care if we input it as text, or view it as text - both are quite natural ways of expressing code (though things like Prograph prove that they are by no means the only way).

The thing I find annoying is that because we still store it as plain text, we can still get into arguments about whitespace, formatting etc, which is just ridiculous in this day and age.

If we stored it as structured text (eg xml), or some sort of binary format like a parsed syntax tree, then code editors would be free to present it to us for editing using our own formatting preferences, safe in the knowledge that it would be stored in a formatting-neutral way, so the next person coming along could view and edit using their preferences.

Of course, in theory we can do this now even with plain text source files, but in practise we can’t because everyone is so used to being able to open the text in any old editor and see exactly what they inputted, down to the last space or tab character. Which leads to polite disagreements about the position of curly brackets, etc, especially when one person accidentally changes what another person had done. Archaic or what?

And that’s not even to mention the obvious inefficiencies of parsing the bloody stuff every single time… we’re stuck in the 70s!

There are partial solutions to the formatting problem. For example, you can set up git hooks to reformat source files (using things like astyle) automatically when you grab them, and before you commit them. If I was running a coding shop that employed multiple people, that’s what I would do, as it would kill these sorts of arguments stone dead.

That sort of thing only works though if everyone buys into it. Automatic formatters tend not to pass the Turing test (!), so sometimes they get things wrong. If you’re running an automatic formatter on your machine alone, everyone else may not even realise it - and you will be perceived as an arrogant and ruthless re-formatter of everyone else’s code!

Anyway, I’m off - got lots of spaces to remove from my method declarations…