Archive for June, 2009

File Uploads in Firefox 3.5

Saturday, June 27th, 2009

Apparently, improved developer control of browser-native file uploads, something I wishlisted back in 2007, is going to be available in the upcoming Firefox 3.5.

RSS: Error-prone

Wednesday, June 24th, 2009

I subscribe to only about a dozen RSS or Atom feeds, but more than half of them suffer from one problem or another.

  • Intermittently dumping a dozen duplicate posts.
  • Dumping a dozen duplicate posts on every refresh.
  • Duplicating the most recent post on every refresh.
  • Double-escaping HTML entities, so I see “, ”, … and such like in post names.
  • XML syntax errors causing total feed outage until some improperly encoded post drops off the feed.
  • <pre> code snippets that have lost their formatting.
  • And, of course, the occasional snippet of HTML that doesn't work as intended when removed from the context of the original HTML document and embedded in RSS.

I often have to search for Pipes to get a useful feed, which is a consequence of the way RSS specifies only a data format, not an obligation on producers, an architectural flaw I've discussed before.

But quite aside from this, it seems that a significant proportion of feeds aren't implemented properly.

Obviously we can blame developers for bugs, but the design of RSS may well be a contributing factor. The process of encapsulating HTML fragments in XML is not as straightforward as it looks. The requirement for a unique ID for each post at first glance does not look onerous. But does the ID correspond to the specific version of a post? Or does it correspond to the current version, however it may have changed since it was first published?

RSS may be useful, but it should also just work, and it doesn't. Developers and standardistas alike should start thinking why.

Sample Code for Employers

Wednesday, June 10th, 2009

If you are looking for a job programming, you need to demonstrate to a potential employer that more than anything else, you will be profitable. In terms of programming, profitable code is robust, is produced quickly, is readable, understandable and maintainable by the rest of the team, and depending on the job you're applying for, may have to be secure or efficient too.

As an employer I consider it vital to see a sample of a developer's code before employing them – it's the most reliable way of assessing how competent a candidate. The standard of code I've encountered from candidates over the past few weeks was generally weak. If you want to stand out, you may be interested in a few tips. I've tried to put these in order of importance.

  1. Submit only your own code If you worked on the code with anyone else, it's worthless to me.
  2. Submit your best code If you have more than one project, submit the best. I'm liable to judge you on the worst. The most recent code you've written is normally the best, assuming your programming skills have improved over time.
  3. Make it easy to run the code I can't run most of the code I receive. Maybe it runs, but generally it's not clear how I get it running (web applications are generally hard to run). I am interested most in the code itself, not seeing the program run, but it's a big bonus if I can run it. So why not include an INSTALL file documenting the process. For web applications, you could include database dumps with sample data, or swap your application onto SQLite and include the database file. But an even easier way is just to get it hosted somewhere and send a link.
  4. Submit code that does something interesting A lot of code is either boilerplate or performs very common tasks. For example, a web application that takes input from a user, puts it into a database, retrieves data from a database, and outputs it into a page is the most simple web application it's possible to write. It's covered step-by-step in any web programming textbook. If that's all the application does, it had better be pretty dazzlingly tidy code. But I prefer to see code that is outside the scope of textbooks.
  5. Use plenty of third-party libraries The more libraries I see neatly integrated into your software, the more efficient you look as a programmer. There can be reasons to re-invent the wheel in practice, such as to overcome license restrictions, but when you're submitting sample code to employers it makes you look inefficient. Moreover when I see code draw on more and more appropriate libraries (or web APIs, or data sets) it also means that you know what's available and you're thinking about how to combine them creatively. (Incidentally, if you bundle third-party code with the source you supply, put it in a directory called "lib" or something so that I can see to ignore it.)
  6. Write good HTML. I'm less tolerant of bad HTML than a web browser is. I'm not going to pass or fail you purely for HTML that's not standards compliant because it's enormously widespread, relatively low-impact, and fairly easy to teach – but you're applying for a job writing software that outputs in a well-defined language. It comes across better if you're actually outputting in that language, and not some misinterpretation of it. It begs the question, would you do that for any other data format or protocol? Anyway, bad HTML breeds bugs.

If you can't find code that meets the above criteria, why not write something especially? It's possible you could write something in a weekend that can improve your job prospects significantly.

But if you're not employed at the moment, and you're looking for a job as a programmer, you should be constantly either writing code or reading articles on the web about writing code. Employers can teach you skills on the job, but it costs money to do this, and that's money that won't be going into your salary.