A (fond) farewell to Zend Framework

I’ve been a Zend Framework user for a while. I’ve been using PHP long enough to appreciate the benefits of a good framework, and developed a number of sophisticated applications using ZF, to have grown a certain fondness for it. Although it has a reputation for being difficult to get into, being slow and being overly complicated – not undeserved accusations, if we’re being honest – there is something quite appealing about it. Well, was, for me at least. ZF 1.11 looks like the last version of the framework I will be using.

Why? The simple answer is ZF 2.0. Having been busily built over the past couple of years one way or another, a number of betas have been released and it looks likely to me that an initial release is a few months away. At this point I need to make a decision about my future use of the framework, and I don’t particularly like what I see.

Let’s be quite honest about one thing up-front: I cannot claim to have done any substantial amount of work in ZF 2.0. The criticisms within are all personal opinion based on little more than the most itinerant tinkering.

That said, I actually don’t feel like much of what I’m about to say is unfair, for one simple reason: I have tried to like ZF 2.0. There are of course other PHP frameworks, and I don’t really need to name them, and many of them are initially much nicer to get started on than ZF. Despite all that, I got quite happy with ZF1, and indeed approached ZF2 with the idea that it would take a similar amount of effort to learn to like it. I have attempted to apply that effort. I have failed.

Much of what I think is wrong with ZF2 you can quite obviously see in the ZendSkeleton example application. Now, of course, the example applications for most things are pretty poor: every JS framework has a To-do app, and things are generally chosen to show off the best features of the framework in their most flattering light. That’s actually the first thing that hits me about the skeleton application: it’s deathly, deathly dull, but there’s a pile of code needed to get you to that point. The sheer amount of boilerplate needed to get much further than ‘Hello World’ is incredible, and of truly Java-like proportions.

Generally, I like my frameworks opinionated. I like having a culture, or an ethos, which come through as a set of guiding principles for the developers of both applications using the framework, and the framework itself. And ZF certainly is and was opinionated. I suppose at this point, I find that my opinions differ with theirs too much, and that’s an issue.

The first opinion I would cite is the use of dependency injection. Now, I get DI, truly I do. I even like the idea of it. I can see how it would be useful, and how it could add a heap of value to a project. But there is “useful feature” and then there is “koolaid”, and DI in ZF2 is alarmingly close to the latter. As a case in point, just take a peek at the module config for the skeleton app.

The comment at the top of the file first sent shivers down my spine – “Injecting the plugin broker for controller plugins into the action controller for use by all controllers that extend it” – it’s the kind of enterprise buzzword bingo that again, sorry people, sounds just like a Java app.

And as you progress through what is supposed to be just a bit of config for a simple application, wading past the router config and various pieces of view configuration, you’ll see the thing which just turned me right off – ‘Zend\View\Helper\Doctype’. Seriously? A fragment of view code to manage the doctype? As if this is something you can just change at runtime? “Oh yeah, we built it in HTML5, but I can just downgrade to HTML4 by switch….” sorry, no. Doctype is totally fundamental to the templates you’ve written. This is so far from application config it’s not funny.

Other stuff I can’t abide: the default file tree. Did you think application/controllers/IndexController.php was bad enough? Now you have module/Application/src/Application/Controller/IndexController.php. I do get the reason for this, but again enforced modularisation – ZF1 supported modules too without forcing it.

I know how observers might respond to this: it’s a skeleton app. It’s supposed to be showing a set of best practice, you can cut corners and make things simpler. Except, this isn’t true: there’s already a whole load of corners cut. Just look in the layout; there’s a pile of code at the top of the template. Isn’t the view supposed to be where the code lives?! I would have most of that crap in my Bootstrap.php as-was, I can’t believe people are advocating throwing that in the layout template now (and I’m sure they’re not). But there it is, cluttering up the layout, when it really should be refactored somewhere else.

This is the issue. The skeleton app does a whole heap of things just to do nothing except chuck Twitter bootstrap on screen. I am, of course, willing to be shown how all this up-front investment will pay off in the end – but right now, I really do not see it. The more I look, the more I see things which will just require more and more code to get working – a constant investment throughout the life of a project, without any obvious pay-back for it later. As a rule of thumb, whenever I’ve used a framework before, the skeleton always looks pretty good, but a production app gets entirely more complex and hairy. Things don’t improve, generally, at best they stay as-bad. I would worry that a ZF2 app would just explode into a sea of classes entirely unnavigable by a junior programmer, held together by a DI system so abstract they would have little chance of properly comprehending it.

This is really sad. ZF1 had a number of shortcomings which I thought ZF2 looked on track to tackle – and, in all probability, has tackled. The REST controllers in ZF1 were complete bobbins, and ZF2 looks like it has that right. The Db layer in ZF1 was actually quite good, but ZF2 looks to have improved on it. PHP namespaces are of course ugly as sin and ZF2 embraces them, but they make sense and I could potentially learn to love them. But my gosh, just look at the quickstart. Remember, this is the “get up and running as fast as possible” guide for people who already know the language and just want to get cracking.

What is bad about it? Well, 12.2.2 is the start of the “you’ve already installed it – let’s get coding” section. First item on the todo list? “Create your module”. This involves downloaded the skeleton, copying bits over, and being told all is well. 12.2.3, update the class map for the autoloader, using the correct namespace, ensuring configuration is enabled and being lenient with the autoloading (let’s both you and me pretend we understood what on earth this section was trying to achieve).

12.2.4, create a controller. Oh my god, I don’t want to know what Zend\Stdlib\Dispatchable is there for, or why I might pick a REST controller because the quick start doesn’t cover REST. But no fear, we have a basic controller, it looks like this:

namespace\Controller;

use Zend\Mvc\Controller\ActionController,
    Zend\View\Model\ViewModel;

class HelloController extends ActionController
 {
   public function worldAction()
     {
        $message = $this->getRequest()->query()->get('message', 'foo');
        return new ViewModel(array('message' => $message));
     }
  }

Unfortunately this reminds me again – I hate to use the J-word – of all the geek Java jokes. Boilerplate object-this and method-other-thing-another-method-that().

I so want to be interested in ZF2, but it’s about as far up the corporate enterprise architecture-astronaut ladder as I have ever seen PHP climb. And honestly, if I wanted to program Java, I’d use Java. And then I’d download Play or Scala and actually enjoy it. But for PHP, no. So, adieu, ZF. It has been nice knowing you.

“Dart” out in the open – what’s it all about?

This morning was the big “Dart language” unveil – the Dart websites are up at http://dartlang.org and http://dart.googlecode.com. And already many seasoned Javascripters have the knives out. I’m surprised for a couple of reasons: the first, this isn’t quite as big a deal as many people thought it would be (me included), both in terms of the scope of the system and the distance to Javascript. Second, the system isn’t quite as finished as many predicted: this isn’t going to be usable for a little while.

That all aside, let’s look at the highlights:

It’s classicly classful

Javascript has a prototypical object system. That means that instead of having classes that define what objects should look like, you simply create an object, make it look how you want it to look, and then use that as a template for all future members of that “class”. This is deeply confusing to many people who have come from languages like C#, Java, C++, Python (etc. – i.e., practically all of them) where you do things the classical way. The Dart designers have more or less thrown out the prototypical system, and a standard class-based system is available, with some degree of optional typing.

And in fact, it seems more or less mandatory: they’ve used main() as the code entry point again, and like in Java, for anything non-trivial you’re basically going to have to write a class which implements that function.

I’m not yet sure whether this is a great thing or not – mostly, I’m ambivalent – but lots and lots of people have written their own “quacks like a class” system on top of Javascript, including Doug Crockford. Javascript is flexible enough to represent this, so the Dart-to-Javascript compilation bits will work, but obviously it’s not going to interact well with Javascript libraries that take a different view of classes or inheritance. This is probably not a problem; Perl has a number of different ways of implementing objects and there doesn’t generally seem to be much trouble with it.

Wider standard library set

Javascript has been let down by its standard library set in many ways. First, there really aren’t many data types available: you have an associative array, you have a non-associative array, and that’s about it. Objects are more or less associative arrays. But also, there aren’t other APIs to do useful things in the primary heartland of Javascript, the browser. The answer to all this, of course, has been the rather well designed Javascript library projects that have sprung into being: the JQuery, Mootools and YUIs of this world. And there are many of them, and the competition is fierce, and the end results are actually very good.

Dart goes a slightly different way with this. The library sets that come with Dart do a lot more than Javascript is capable of. There are lots more basic types, and many basic behaviours (interfaces) that describe in what context you can use such data – for example, any type that implements ‘Iterable’ can be used in a loop. It’s pretty great that this is all standard. Sadly, the DOM library makes a re-appearance, which is a bit of a shame because it’s literally one of the suckiest APIs ever invented, but on the flip side it does mean that the likes of JQuery could be ported to Dart easily.

Sugar for asynchronicity

Javascript, particularly when used in the browser, is deeply asynchronous. Unfortunately, the language itself doesn’t have an awful lot of support for that. You can pass functions around as first-class objects, so a lot of APIs are designed with function call-backs to execute “later on”. This leads to a kind of “macaroni code” where roughly procedural code (“Do this, then do that, then do this other thing”) is broken up over many functions just so it can be passed around like this. Dart gives the programmer a little bit of help here by implementing Promises.

In Dart, the Promise is an interface which looks an awful lot like a thread in many ways. The key sugar here is that the language still has the callbacks, but you can chain them together with then() instead of embedding them each within itself. You can also check on how they’re doing, cancel them if you like, and other stuff – again, nothing that Javascript doesn’t have, but slightly more elegant. Combined with the class system, it also means the end of ‘var $this = this’ and other such scoping hacks.

Message passing

This is probably more important than the Promises interface. Dart has message passing built-in, like many suspected. And, it looks nice and simple: you have ports, and you can either receive messages from them or send messages to them. The receivers are basically event-driven in the same way a click handler would be. Seeing the value here is difficult in some ways: it will be interesting to see how the balance is struck, because if you are designing a class you could either make an API which creates Promises, or send/receive messages – the net effect is roughly the same. You probably don’t want to implement both, but which system you use is up to you. The message passing interface is slightly more decoupled; but it’s probably easier to abuse in the longer term.

It’s all sugar

I think this is the thing which surprises me most about Dart: it’s actually pretty close to Coffeescript, but with a more Javscript-like syntax. And that’s why I can see this being successful: you can turn it into standard Javascript, but it gives us a lot of the bells and whistles that programmers have been crying out for. Classes have getters and setters like C#, strings can have variables that interpolate within them, you can write really lightweight functions in a new => syntax, and classes can have built-in factories – just to name a few of the highlights.

There are some extras, like the ability to reference needed CSS, which point to a slightly grander future where Dart scripts are rolled up with their related resources into something more easily distributable. And maybe this is the point: the unveiling of Dart was not really a beginning itself, but the beginning of a beginning. They’ve designed the language to attempt to grow with your application: you can start small and simple, but as your application grows you can add more to it (like types and interfaces) to make it more structured and, hopefully, safer to run. And in the same sense, Dart itself is going to grow over time as well.

 

Is package management failing Fedora users?

(For those looking for an rpm rant, sorry, this isn’t it….!)

Currently there’s a ticket in front of FESCo asking whether or not alternative dependency solvers should be allowed in Fedora’s default install. For those who don’t know, the dependency solver is the algorithm which picks the set of packages to install/remove when a user requests something. So, for example, if the user asks for Firefox to be installed, the “depsolver” is the thing which figures out which other packages Firefox needs in order to work. On occasion, there is more than one possible solution – an obvious example often being language packs; applications usually need at least one language installed, but they don’t care which.

I don’t particularly have much skin in this particular game; but what I would note is that I find it particularly bizarre that this task is delegated to an algorithm. What we’re saying, basically, is that the configuration of a given installation is chosen by a bit of software. So long as the various package requirements – which could be library versions, files, or something entirely synthetic – are all met, the configuration is “valid”. Of course, that doesn’t necessarily mean it works – it may be totally untested by anyone else, and things get particularly grizzly if you’re doing something “fun”. Such fun includes:

  • deploying “multi-arch” packages. Maybe you want a 32-bit browser plugin on your 64-bit PC, for example;
  • installing third-party packages. Maybe it’s RPM Fusion, maybe it’s an ISV – but where-ever it’s from, it’s another set of variables the depsolvers looks at;
  • installing your own packages. See above.

The package management system doesn’t have a concept of “OS” and “other stuff”. Being able to override such a concept would be a feature; not having it is not a feature however.

Now, fans of package management frequently tout the many benefits, and they are indeed multiple. It makes it easy to install new software and be reasonably sure it works (it may need a lot of configuration, though). Splitting stuff up into a thousand different bits makes security updates more straightforward (at least, in theory – see later). But in general, to conflate all these issues is a bit of a mistake: there are other forms of installation system which provide these benefits as well.

So, what’s wrong with this? We’ve already seen that the choice of depsolver can potentially make or break the system, or at least lead to configurations which were not intended by the packagers, but to some extent that could be solved by tightening the specification/package dependencies, so that the “right choice” is obvious and algorithm-independent. But, there are other issues.

It’s difficult to estimate the number of Fedora users, but the statistics wiki page makes a reasonable effort. And looking at that, we can see that about 28 million installs of almost 34 million (that are connecting for software updates) are currently using unsupported releases of Fedora. That’s over 80% of installs using a release which is no longer supported.

This of course has security implications, because these users are no longer getting security updates. No matter how fancy the package management, these people are all on their own. And unfortunately, the package management tools are not much use here: effectively, unless you use the installer in one of its guises, the procedure is difficult and potentially error prone.

You’re also out of luck with third-party repos: the package manager doesn’t insulate them from each other, so mixing is frowned upon. It may work, it may not. You may be able to upgrade, you may not. It may alter core functionality like your video driver, and you might be able to downgrade if it failed, but let’s hope it didn’t manually fiddle with things.

In the meantime, we’re also failing to deal adequately with many types of software. The Firefox update process causes enough problems with the current setup; Google’s Chromium on the other hand appears to be almost entirely impervious to being packaged in a Fedora-acceptable way. Web applications also don’t work well; Javascript libraries don’t fit well/at all into the concept of libraries a la rpm, so there’s loads of duplication.

There’s probably an awful lot more that can be written on this topic, and of course package management right now, for the most part, works pretty well. But I worry that it’s a concept which has pretty much had its day.

Speculation on Google’s “Dart”

Just yesterday people jumped on the biographies and abstract for a talk at goto: the Keynote is Google’s first public information on Dart, a “structured programming language for the world-wide web”. Beyond knowing a couple of the engineers involved – which allows a certain amount of inference to take place – there’s also some speculation that Dart is what this “Future of Javascript” email referred to as “Dash” (this seems entirely possible: a dash language already exists; Google already used ‘Dart’ for an advertising product but have since stopped using that name, potentially to make way for the language).

I thought it would be interesting to have a look at some of the details of this new language. One thing seems quite certain: Google’s Javascript engine, V8, is going to target this, because it’s going to target client-side application programming to begin with. V8 is, of course, very popular – it’s in Chrome, it’s in Node.js, it’s going to be put in Qt. However, it hasn’t really been a brilliantly standalone project (witness the problems getting Chromium into Fedora, as an example) and the addition of Dart will almost certainly make this worse.

So, what else do we know?

Compiles to Javascript

It seems likely that the language will, at least in a proper subset, compile into Javascript – a lot like Coffeescript does. Personally, I cannot stand Coffeescript for the same reasons I really don’t like python, but there is some obvious win to this approach: you get backwards compatibility with existing systems and, usually, a method of interacting with existing code and libraries.

I suppose the first question is, how different to Javascript will it be? It will almost certainly be object-oriented, but that need not imply prototypical inheritance – it could be the Javascript compiler will do some fancy trick with object to make things appear more classical. Coffee does this to a large extent too, and I think we’ll see a similar approach. I doubt much of Coffee’s syntax would be copied – it’s almost Perl-like in its terseness sometimes – but I think there will be a similar approach to the object model.

There will be other differences. Javascript is relatively typeless, I suspect Dart will have types of some sort at least optionally. The scoping rules will probably be a bit different as well – the “let” keyword has never caught on wildly, but some level of block scoping (as an example) would be an obvious improvement.

Not just a language

I think it’s relatively clear from the “Dash” discussion that this isn’t just going to be a language: templating and possibly even MVC will be available alongside, some how. I expect to see some interesting things here, actually – there might not be much impact on the language (although a way of embedding HTML templates might be handled specially) but I think it will be closely aligned to these key tools. The Javascript world has been doing some interesting stuff – see Backbone.js and Knockout.js as two obvious examples – but it will be really interesting to see how much “platform” is put into Dart.

There is a worry here, of course, that it’s too restrictive. Knockout is actually a great example: it’s MVVM architecture, not MVC, and for a lot of jobs I’ve actually been really, really impressed with it. It’s simple, straightforward, but most of all productive. It would be a shame if you can’t do something similar in Dart, but I would bet you can. Binding data onto a web page is so fundamental, so basic, that I really think there will be some interesting stuff there.

Binary Dart?

I’m not really sure about this, but I’ll chuck it out there anyway: clearly, writing Dart in a text editor is going to be fine. However, I also expect that there would be alternative delivery mechanisms. Right now, people use tools like Closure to “compile” Javascript into a more compact representation. Clearly, if you’re starting with a new language, you could specify a binary format right from the start. This would also sit beside NaCl/Pepper quite nicely, and allow multiple resources to be included into a project without having to have multiple file downloads into the browser.

Google are going to be focussed on deployment of large, highly-interactive apps, I think – so although the small page enhancement stuff would still be on the table, really I think Dart is going to be about writing GMail and Google Docs. In that context, being able to wrap up everything into a nice deployment package makes a whole heap of sense.

A month to wait?

Sadly, I don’t think we’re going to know too much more before goto;. I had a look around the V8 source, there aren’t really many clues in there to what’s coming. If they’re offering a compile-to-Javascript option, that might be the only thing released at first – so Dart would effectively be a standalone compiler only to begin with, growing features to target specific engines later on.

The quality of Fedora releases

Scott James Remnant blogged his ideas about how to improve the quality of Ubuntu releases recently, triggering some discussion at LWN about the topic. I offered some opinions about Ubuntu which are not terribly interesting because I don’t get to use it often; however, I did also write about Fedora based on the last couple months’ experience of Fedora 15 & 16.

Before I get to that, at roughly the same time, Doug Ledford was posting his thoughts about the “critical path” process – essentially, saying it was broken. I’m pretty sure he will find vociferous agreement with his views, based on previous feedback, but not (alas) from me.

I made a number of claims about Fedora in the LWN comments, that it is essentially unusable for anyone non-expert. I stand by this: if you use Fedora, and care about things continuing to work on an ongoing basis, you have to be entirely au fait with:

  • upgrading your distribution every six months;
  • rolling back an update (including config) when (not if) things break;
  • knowing how to distinguish which part of the stack is broken (and oh boy, this isn’t easy).

People complain about Windows “rotting” over time and getting slower, and slower. Fedora is worse than this: it works great until you get an update which blows out something critical. At that point it stops working: maybe you stop receiving updates, maybe you can’t boot it, maybe you can’t log in. I haven’t had a release yet, that I can recall, that something crucial wasn’t broken.

Of course, in Fedora, we have the critpath process, which is supposed to stop this kind of thing. And this is what Doug is complaining about, because the process which puts roadblocks in the way of updates to crucial packages naturally gets in the way of “fixes”.

This is where I depart with Doug, I suspect. I have sympathy for his situation, particularly in F16. But the point of critpath is that it does cause pain.

The issue with critpath isn’t that it gets in the way; it’s that it highlights release problems. When major issues turn up in critical packages and get through to release, it hurts – it cannot be fixed quickly. And here’s my point of disagreement: we shouldn’t allow more direct fix releases just to avoid the pain, we should address the root cause of the problem – the release of bad code.

(Interlude: as a point of order, it should probably be made clear that the specific issue Doug is facing is a lack of karma on a specific release branch with a package which, although critical, is not necessarily widely used. That’s an obvious bummer, and I’m not sure is terribly instructive about the process as a whole because of that).

There have been a variety of other solutions proposed. AutoQA is something I have a huge amount of time for, and in particular would help reduce the incidence of obvious brown paper bag bugs. It’s not a solution itself, though. Equally, there will always be stuff which evades testing – hardware support in device drivers being an obvious case in point.

I am extremely jealous, though, of the quality Debian achieves, and I say this as a Fedora user. It’s stable, it’s easily upgradable from release to release, and generally the use:surprise ratio is reassuringly high. To a large extent, I think they illustrate that the specific processes don’t really matter a huge amount: what matters is actually getting to a point where maintainers don’t release bad packages often. And to me, that is the point of critpath: to encourage packages of sufficient quality that the pain is generally avoided. Simply short-cutting the process doesn’t encourage that; it just encourages more of the same in Fedora.

Who can program?

Over the past couple of weeks, I’ve been pondering the above question for a number of different reasons. For people who really study programming, like I attempt to, there are a number of claims/myths/legends/tales that are commonly held about people who cut code for a living, such as:

  1. some programmers, the “alphas”, are as much as ten times more efficient than the common programmer;
  2. there are people who “get” computers, and those who don’t. Cooper splits these into “humans” and “homo logicus”. Those who don’t grok computers are destined to never be able to program;
  3. there are people who are paid to cut code, and who simply can’t – they rely on auto-complete IDEs, cut’n’paste library code, etc.;

For the purposes of this post, I’ll separate between these different concepts: the “goats” (people who cannot code, at all), the “sheep” (people who code, perhaps professionally, but poorly) and the alphas. Sheep and alphas are collectively referred to as coders.

Saeed Dehnadi’s PhD homepage cropped up recently, on Hacker News I think, and mentions some tests which have had varying degrees of success in differentiating between goats and coders. Somewhat surprisingly, it’s claimed that it’s possible to administer tests to people before they have been taught to code and yet still determine whether or not they will be able to code. The tests are disturbingly simplistic, but although they involve (pseudo-)code, they’re actually designed to determine the mental models people apply to the problem, and in particularly whether people apply a consistent model.

I have to say, I remain a little bit sceptical about all of that. It reminds me of a question a lecturer once asked our class, while working on set theory: “Why to people refer to ‘∀’ as ‘upside down A’, and refer to ‘∃’ as ‘backwards E’? They’re both simply rotated π radians”. I remember thinking to myself that he obviously had little clue how the human mind approached novelty – and in particular attempt to label things with a communicable tag. “`A’ transformed with a π radians rotation about the centre point” not having quite the same ring about it. But maybe there was a point in there, somewhere, about finding single consistent models that can be re-applied.

It’s really tempting to think about this in terms of tests. This is, after all, one of the reasons vendor certification programmes came into life: to reassure employers of whatever description that the person they’re hiring to do a task with a specific product really is able to do what they say they are able to. And it does work, kind of, after a fashion. If what you need is within the narrow scope of the studies of the certification, you can be generally assured that the person does at least know the theory. However, for programming, this is a bit different – frankly, there is no such thing as “narrow scope” when you’re talking about cutting code. Some people, like Paul Graham, go as far as to say questions like “how do you pick good programmers if you’re not a programmer?” are basically unanswerable (mistake 6 in his classic list of 18 mistakes that start-ups make).

It’s also difficult to talk about how you can tell the difference between sheep and alphas (let’s pretend, for a moment, that there is no spectrum in between there – that’s probably not true, but it might be a somewhat valid simplification). How many people read Reg Braithwaite’s discussion of using FizzBuzz during interviews and didn’t recognise the picture he paints? Let me repeat here his main thesis:

“199 out of 200 applicants for every programming job can’t write code at all. I repeat: they can’t write any code whatsoever.”

He refers back to another classic, Joel Spolsky’s thoughts on the hiring process from back in 2005. So, what are all these people doing applying for jobs that they are effectively incapable of doing, and how many of these people actually end up being hired and contributing to the sheep pool? It’s difficult to know exactly why they are applying, but part of the reason has got to be the modern tools available to programmers: both the editing environments, the IDEs, and the documentation and programming resources available. Some coders will have no idea about the types of tool I’m talking about, having never used the likes of IntelliSense and visual designers.

Let me give you a clue. Take a long hard look at this abomination. Just to be really clear about what’s going on there, they have a tool which can effectively write code based on semantic guessing – the words you’ve written, the types of the variables involved, the context of the code, that kind of thing. This is like a builder using a brick-laying machine to build a house without the need of any intervening thought about such trifles as “how strong should this wall be?”, “am I putting this wall in the right place?” and even “what if I need to later put a door in here?”. Simplifying the coding process is an admirable goal, and in fact has been an ongoing process since we wrote the first assemblers to translate mnemonic instructions into machine code. However, the ideal has always been to raise the level of abstraction to the height at which it makes sense to solve the problem at hand. You don’t want to write an entire database system in assembler, it’s not really a high level enough language. But you may want to dip into assembler in specific parts. Sometimes, it will hide the details of what’s going on underneath from the programmer, and occasionally that will annoy the programmer. In general, you do not what to be writing large pieces of code where you actually have no idea of what’s going on – an alpha would never, ever stand for that; a sheep, on the other hand, would.

Jeff Atwood has another collection of thoughts on his 2007 post about coders who can’t code. The conclusion he reaches is relatively natural, based on his references and the above: you ask people to actually write some code. Amazingly, surprisingly, gob-smackingly, this still isn’t happening – even today. I could name, but won’t, places which are hiring programmers based on not much else but their claimed experiences. I know people who’ve been through such processes, and have seen such myself. Do you need to ask a question of each candidate, make them do something original? No, of course not – you could even simply ask for a sample of code and take it on trust that they wrote it. My experience on the hiring end is that it’s actually quite easy to tell whether someone wrote a piece of code or not, and the most telling piece of information is not the code itself, but the problem it solves – seeing the type of code that a candidate thought was appropriate to display actually says an awful lot about their tastes and sensibilities.

If I was doing this again right now, what would I do? Probably about the same as I did last time: ask people who turn up to do some simple tests. It’s shocking how often people with an otherwise interesting CV just totally bomb even the most simple request, but it’s nothing much more than a filter. Trying to determine higher-level skills is actually fundamentally more difficult, because the more skill you’re attempting to detect the more parochial your test necessarily becomes, to the point where you’re filtering out people who simply don’t have the exact same background / knowledge set as yourself. Much more important is the capacity to learn and apply problem-solving techniques – part of me thinks that asking them to write code in a language they’ve never seen before might be an interesting test, but it would be fantastically difficult to pitch it at the right level.

I’m going to end with a link to a discussion on StackExchange about how to detect a passionate programmer. I’m not sure I agree with much more than about 50% of it, but there are a lot of ideas in there for predictors of programming expertise. Interestingly, there are even some companies out there who claim to be able to help out in the hiring process to clear out goats and sheep. I have a lot of sympathy for people like Eric Smith who are rolling their own tests to attempt to judge skill. I have to say, though: it really shouldn’t be this hard.

Short thoughts on the riots.

Last night, we decided to order pizza – we don’t do it often, it’s lazy but sort of a treat. However, out of the three local well-known places, only one was open: the other two had shut down early. Now, we don’t live in London per se, but Croydon (where there were major fires and a member of the public was shot just a night ago) is only a few miles east, and Clapham a few miles north. Sutton, the local town, had some windows broken by youths, but to be honest this isn’t exactly exceptional behaviour in Sutton.

What happened when the pizza came was slightly surreal. The delivery guy was very nice, but asked me to wait at the door until he left. Why? Because there was a group of three kids just down the road, and basically, he was afraid of them. Just to be clear, most people buy using their cards these days, so this guy wouldn’t be carrying much money and didn’t have any other pizza on his bike. He wanted to make sure that if something did happen, there would be someone watching. After he left, I did begin to wonder whether this pizza chain really did make the right decision to stay open. I don’t think he was actually in much danger, but to work in an environment where you believe yourself to be in danger is probably just as bad.

So what’s going on here? I think this has been a long time coming, if we’re very honest. Anti-social behaviour has been a significant political issue for the last fifteen years, and you only need to look back to the student fees marches just last year to see people rioting in London in pretty much the same way. The difference, of course, was that under the flag of another cause, people assumed that this wasn’t a more general problem.

No-one really knows why this is happening. This isn’t a sudden thing, this has been years in the making, and the cause or causes are probably no longer determinable. My personal favourite reason is education: I don’t think this country has ever had an education system which hasn’t failed a significant minority of the young, but in years gone by those failed by the system have been able to get jobs in factories and other places which had a wage that could support a family. Those jobs don’t exist in the same way any more, and they certainly don’t pay a living wage.

What is disturbing, though, is what comes out of the mouths of these people when you listen to them being interviewed. I’ve heard a variety of interviews with people across the country who’ve been rioting, and the message is basically the same no matter who they are. They hate the police (the “Feds”), but this is just a proxy for authority of any sort. They don’t care who gets hurt, they don’t identify with any particular societal structure except for maybe their own gang, and they see an easy opportunity to gain at low risk of getting caught.

This actually reminds me of various pieces of stories from Jon Ronson’s “The Psychopath Test”. I’m certainly not diagnosing these people with antisocial personality disorder, but good lord they certainly display many of the traits. You just need to look down Hare’s list and they tick practically every box at least once over – the main thing that they’re not doing that a real psychopath would do is the lying and manipulation to cover their tracks. Right now, many of these kids don’t feel the need to even cover their faces from the cameras which they know are there.

The radio told me this morning that three men had been run over, attempting to protect their neighbourhood. Many people have come out on the streets, the anti-rioters, the wonderful Riot Wombles, and it’s tremendously sad that rioters are not just attacking buildings and cars but also now their fellow man. I expect a number of commentators to draw immediate parallels with Grand Theft Auto, which had already been linked to these troubles by people who believe games influence real life. I think all it demonstrates is the lack of imagination the rioters have. They’re like a kind of Commercial Zombie, roaming the streets for TVs instead of brains, destroying everything in their way. They don’t know how to deal with people personally, all they can do is imitate and emulate others, whether it’s video game characters, movie characters, hip-hop stars, whoever. I don’t wish to dehumanise them, but they just seem to be incapable of rational thought, they just play out TV stories because they don’t seem to know any other way.

OpenOffice.org ⇢ Apache

Many words have been expended on this situation. I don’t have an awful lot to add about the project side of things: I think it’s immensely sad that OpenOffice.org is being forked again (this is much more clearly a fork than LibreOffice was), but fundamentally all actors within the free software world are autonomous and have free will. Such is life.

(this is a deeply opinionated blog post. feel free to skip it, take it with a grain of salt, whatever.)

A lot of people are talking about this as mainly a license issue, with one commentator spelling it out: “It will be interesting to see, after the first wild set of commentary flies, which project – and which license – that various developers and corporations alike choose to actively support” (the juxtaposition of the opinion and the title of the blog is especially delicious). After all, it’s easy to see this as a license show-down: given the same code base, and two different licensing strategies, which will succeed? Sadly, it’s not really a race LibreOffice can “win”: if that project is more successful, well, they had a head-start, didn’t they.

I don’t think much of this is really relevant. I’m not sure IBM care too much about who develops the code, and I don’t think an LGPL’d code base would fundamentally stop them from shipping a proprietary product if that is what they wanted to do (it makes it harder, of course). I actually think this is all about OpenDocument Format, which is a subject virtually no-one has raised.

If you look at the OASIS TC, you can see it’s pretty obviously dominated by Oracle (was: Sun) and IBM. There are a few representatives of various other companies and open-source projects, but fundamentally this is a closed shop with a pay-to-play rule which means you have to pony up to join. The v1.2 spec – which has been used by OpenOffice.org since 2008 – has only just managed to crawl out as a committee specification, incredibly late. What this means for OpenDocument v1.2 documents as read/written by OpenOffice.org 3.0, who knows. But with Oracle fading into the sunset (sorry), large chunks like OpenFormula finally done, maybe v1.3 will actually show up on time.

So here’s where this really matters. ODF is nothing if not a stick with which to beat that other vendor. And having a large say in ODF is not really anything unless you have implementations around, and until now, OpenOffice.org has not only been a leading ODF implementation, but effectively the reference implementation of ODF. This is what IBM really want control of: this is why they’re so involved in the TC, and this is the reason for the sudden outburst of passion for OpenOffice.org (all in my opinion, obviously). They almost cannot allow LibreOffice to obtain the de facto mantle of “reference implementation”: ODF as a standard is supposed to follow implementation, and obviously IBM (and most of the rest of the TC, for that matter) have no skin in the LO game. Worse, I don’t think they want LO adding and changing features  in ways which necessarily touch ODF: imagine if it had been LO only who had released ODF1.2 support in 2008. This is a very real risk – there are still critical features missing from ODF (want CMYK support do you?!) and control of the TC alone means precious little without the reference implementation.

Is this going to be a bad thing overall? My suspicion is that this isn’t going to be a terribly short-lived fork; I think IBM’s decision to move OpenOffice.org to Apache (well, Oracle’s, but we know whose advice they were following) is going to have a long term impact. It’s already pretty easy to see how the divisiveness has taken hold:

  • the AOOo project has recently discovered that OpenOffice.org used to solicit donations, and don’t sound amazingly thrilled about how it was set up. It’s quite intriguing to watch people like Rob Weir claim that the community has moved to Apache, when the people at Apache seem to have little idea about how OOo operated, where money came from, who spent it, etc. It’s a sad day when bystanders to your project (such as myself) appear to know more than the project leaders. (If someone on the Apache list could also let them know that the SPI holds c. $20k on their behalf, that might be a good idea – they don’t seem to have figured that at the time of writing). Anyway, the likelihood of you bring able to donate to one non-profit which supports both projects (as you can right now) seems to be diminishing fast.
  • there’s been a lot of talk about AOOo code somehow making its way into LO. I strongly suspect this isn’t going to happen that much either: I think these projects are going to diverge must faster than people realise. LO has already moved ahead and dumped a lot of old code; by the time AOOo actually gets off the ground this will be even more so. When AOOo arrives, what core features is it going to get early on? I imagine IBM will make various “donations” – they’ve already talked about accessibility, pivot tables, file format stuff. Some of that may get pulled in, other bits (like pivot tables) is probably going to be too different. After that… I think there will be some work to integrate AOOo with other Apache projects, like POI, and Apache people are quite happy using Java. I don’t think LibreOffice will want much/any of that. It’s going to take non-IBM AOOo hackers time to get up to speed enough with the core to make interesting changes, LO will be years down the road at that point.

There’s enough momentum behind AOOo that means it’s not going away any time soon. I rather suspect there isn’t enough momentum to reach “IBM escape velocity”, and sans some rather large contributions that LO is unwilling to take (which is quite possible – even for potentially desirable stuff like the Symphony UI changes) it’s difficult to see the project making the same strides LO has. More likely, there will be various “quick wins” early in the project but not much else.

It would be interesting to see someone write a full history of StarOffice from the very beginning. It has always been a project full of potential, and one particularly important to the Linux desktop even though its main userbase is on Windows, but it’s also a particularly political project in terms of what it attempts to achieve. As such it has been turned into something of a football.

I voted in the Fedora 2011 elections

This has been an interesting election. I’ve talked about previous ones before, and to be honest this one has felt a little bit of a let-down. I do wish that there were more candidates on offer: while this isn’t a criticism of the quality of people standing, I think they tend to represent a relatively narrow set of Fedora developers and users.

Anyhow, I’ve voted. I’m not going to disclose who I voted for or why, but here are the guiding principles I used:

  1. I have voted in preference of those who answered the questionnaires and turned up to town hall IRC. Even where I’ve disagreed with a candidate’s stance, I have voted in preference of them over those who didn’t answer questions at all. I have much sympathy for those like Nicu who have expressed similar concerns, and I congratulate those candidates who participated fully.
  2. I have zero-voted those candidates who have encouraged supporters to game the voting system. I don’t mind tactical voting as a personal decision, but I draw the line at strategic voting. To quote Wikipedia, if this became common place then “the tactical voters would have a significant advantage over the rest of the electorate”. I wish to discourage this behaviour by explicitly tactically voting against those who encourage it. ‘Nuff said.
  3. I (would) have down-voted candidates whose advertising was too obnoxious. The time to canvass for support is before the elections. I don’t particularly want to hear the “recommendations” of representatives of certain sub-projects/supporters of certain candidates during the elections. I believe each candidate should have equal opportunity before the electorate; c.f. remarks at 1) about turning up to town hall / answering the questionnaires.
  4. I have voted up those candidates who expressed a positive vision of Fedora, particularly those who mentioned the social constructs of the project as well as the technical.
  5. I have voted up those candidates whose positive vision of Fedora particularly fits with my own :-)

I think the period over F16 and F17 is going to be crucial for Fedora. We’re just at the start of hitting the road with Gnome 3, and the developments that are coming in 3.2 are tremendously exciting. Without excluding KDE and the other desktops, Fedora is going to be delivering an incredibly smooth and – dare I say it – designed experience to the end user, and clear leadership in this regard is going to be imperative. The people sitting on FESCo and the Project Board will be more important than ever, so clearly having the right people there is paramount.

Developing a “Fedora Welcome SIG”

This is a follow-up post to my previous one.

I was really pleased with the feedback on my idea for Fedora Greeters, from both established Fedora community members and not. Equally, I got feedback offline as well – and I should make it clear right now that I’m more than happy to receive such communication; the amount of trepidation shown by some I think just highlights some of the problems.

One thing which is really interesting is that much of the feedback wasn’t of the form, “Yeah, I agree, [this thing] sucks and really needs to be improved”. People decided to give me, instead, their own story – you can see a couple of them in the comments of my blog. Of course, these are just anecdotes and must be treated carefully, but I thought it was extremely interesting that people approached the issue in a manner more like, “Well, this was my experience..”

This has convinced me that a SIG in this area is, at the very least, worth of some investigation and work. So, I’ve started a wiki page properly for this, and set up an IRC channel at #fedora-welcome. I need to migrate the previous stuff I wrote, but I’ll get on that today. What I would love is for those who expressed interest in this work to contribute their ideas and experiences.

I think what’s particularly important is to work on actual problems first: what are the things which new users find tough? Seasoned members of the Fedora community, which I kind of count myself in, are probably those that would find this the most difficult to comprehend, simply because we’re furthest away from the experience of the problem.

Some of these problems are undoubtedly technical: I’ve seen a number of people totally fail to setup dual-boot systems (either with Windows or just another distro) a number of times, and it’s one of those things that is actually tough for a new user to fix once it has gone wrong. Sadly, though, it’s going to be really tough to talk about some of these things with any kind of data, though: at least initially, I suspect the SIG is going to have to work anecdotally because we really don’t have the information about what goes wrong for people (either technically, socially, or otherwise).

Part of me also wonders if part of being a welcoming community is having the ability and the resources to say goodbye to people: or, at least, see you soon. What data the community has right now – via smolt, package updates, that kind of thing – is about how people use Fedora right now. We have very little information about why people don’t use Fedora after trying it – what made them leave? What went wrong? This information is all key to a Welcome SIG, though, because really there are two classes of users we need to address:

  1. those who came into the community, struggled, but stayed with it;
  2. those who came into the community, struggled, and left.

I actually think those distinctions are as important, if not more important, than whether or not someone was a power-user on another O/S or a complete IT newcomer. While the Welcome SIG absolutely needs to address the needs of those in category 1), I think for it to be truly successful we have to address the group in category 2) – either bringing them back, or helping prevent them leaving in the first place.

One last thought. A couple of people asked about whether we were trying to help people who might be users, or those who might also contribute. But one commenter on my previous post, Dave S, said: “Any tool that eases the trip through the learning curve nightmare helps transform a newb into an evangelist”. I think that actually spells out the motivation in one simple, powerful statement: this SIG isn’t about getting people into Fedora and making it easier for them to use. It’s about turning that first impression into a positive experience, and have the people who come into contact with Fedora take away nothing but enthusiasm and good vibes. Even if Fedora isn’t for them, let’s make them feel positive enough that they can still recommend it to friends. And I think that’s quite a high bar to set.