Journal tags: coding

My role at Clearleft is something along the lines of being a technical director. I’m not entirely sure what that means, but it seems to be a way of being involved in front-end development, without necessarily writing much actual code. That’s probably for the best. My colleagues Mark, Graham, and Charlotte are far more efficient at doing that. In return, I do my best to support them and make sure that they’ve got whatever they need (in terms of resources, time, and space) to get on with their work.

I’m continuously impressed not only by the quality of their output on client projects, but also by their output on the side.

Mark is working a project called Fractal. It’s a tool for creating component libraries, something he has written about before. The next steps involve getting the code to version 1.0 and completing the documentation. Then you’ll be hearing a lot more about this. The tricky thing right now is fitting it in around client work. It’s going to be very exciting though—everyone who has been beta-testing Fractal has had very kind words to say. It’s quite an impressive piece of work, especially considering that it’s the work of one person.

Graham is continuing on his crazily-ambitious project to recreate the classic NES game Legend Of Zelda using web technology. His documentation of his process is practically a book:

1. Introduction,
2. The Game Loop,
3. Drawing to the Screen,
4. Handling User Input,
5. Scaling the Canvas,
6. Animation — Part 1,
7. Levels & Collision — part 1, and most recently
8. Levels — part 2.

It’s simultaneously a project that involves the past—retro gaming—and the future—playing with the latest additions to JavaScript in modern browsers (something that feeds directly back into client work).

Charlotte has been speaking up a storm. She spoke at the Up Front conference in Manchester about component libraries:

The process of building a pattern library or any kind of modular design system requires a different approach to delivering a set of finished pages. Even when the final deliverable is a pattern library, we often still have to design pages for approval. When everyone is so used to working with pages, it can be difficult to adopt a new way of thinking—particularly for those who are not designers and developers.

This talk will look at how we can help everyone in the team adopt pattern thinking. This includes anyone with a decision to make—not just designers and developers. Everyone in the team can start building a shared vocabulary and attempt to make the challenge of naming things a little easier.

Then she spoke at Dot York about her learning process:

As a web developer, I’m learning all the time. I need to know how to make my code work, but more importantly, I want to understand why my code works. I’ve learnt most of what I know from people sharing what they know and I love that I can now do the same. In my talk I want to share my highlights and frustrations of continuous learning, my experiences of working with a mentor and fitting it into my first year at Clearleft.

She’ll also be speaking at Beyond Tellerrand in Berlin later this year. Oh, and she’s also now a co-organiser of the brilliant Codebar events that happen every Tuesday here in Brighton.

Altogether that’s an impressive amount of output from Clearleft’s developers. And all of that doesn’t include the client work that Mark, Graham, and Charlotte are doing. They inspire me!

When I’m grilling outside, I cook on a gas barbecue. There are quite a few people who would take issue with this. Charcoal is clearly better, they claim. And they’re right. But the thing is, I can fire up my gas barbecue quickly and just get down to cooking.

When I’m programming on the server, I code in PHP. There are quite a few people who would take issue with this. Any other language is clearly better, they claim. And they’re right. But the thing is, I can fire up my text editor quickly and just get down to coding.

I’ve just a written a post over on the Clearleft blog about the way we’re currently nailing down some front-end design principles.

I’m a big fan of design principles for many reasons, not least of which is they way they can help to quickly resolve debates and arguments. They become a kind of higher authority to appeal to, taking opinion and ego out of the equation.

They can also lead to specific design patterns. This is something I’ve talked about in the past: the goals of a project inform its principles, which in turn inform the patterns that are used.

In the case of front-end design principles, they are informed by some higher-level goals. As I wrote on the Clearleft blog, some of those goals are user-centric, and some are developer-centric:

The user-centric goals include:

• performance,
• accessibility, and
• device-agnosticism.

While the developer-centric goals include:

• maintainability,
• readability, and
• modularity.

In turn, the final patterns produced—the actual markup and CSS and JavaScript—should be influenced by the resulting principles: the code should be maintainable, readable, and modular. So at the same time as we were figuring out high-level principles, we are also defining an in-house coding style.

Now here’s the thing about coding style: while it should ideally be informed by your design principles, there’s another factor that overrides everything else—what coding style is preferred by the developers who will be inheriting your code?

When it comes to things like tabs vs. spaces, or indentation, or naming variables, what matters is not which style you use, but that everyone is using the same style.

So, for example, I favour tabs over spaces. And I don’t tend to camelCase variable names in JavaScript. And I don’t like indenting my markup (I make judicious use of new lines instead). But I’m in the minority. I could try to force my style on everyone else at work but that wouldn’t be very productive. It’s far more important that everyone settles on the same style—any style—than it is for a coding style to be “correct.” The only “correct” coding style is the one that everyone is agreeing to use.

Mind you, people who write JavaScript functions with the opening curly brace on a new line are just plain wrong.

Back in April, I wrote:

I’ve been thinking about maybe putting together a podcast — just an RSS feed — that points to interesting inspirational talks, sort of like Jon’s Found Sounds podcasts but for spoken word instead of music.

Well, as soon as I started trying to do that I discovered that, contrary to what Tim Bray says, creating an RSS feed by hand is a pain in the ass. So I decided that I would automate the task of creating an RSS feed complete with enclosures. Then I realised that if this was going to be useful to me, it might well be useful to other people looking to create podcasts of found sounds. So I made a website:

Huffduffer

The term Huff-Duff derives from the abbreviation HF/DF. It refers to a technique, widely employed during World War II, to triangulate the position of radio transmissions. I thought that was a suitable term to revive for the practice of finding interesting MP3 files on the web.

Using the service is pretty straightforward. First of all, you have to sign up. No, I haven’t implemented OpenID support. Sorry. I hope to get around to it at some stage.

Secondly, you find MP3 files out there on the web. Using either a bookmarklet, or a form on the site itself, you “huffduff” the file: give it a title, description, and tags.

That’s pretty much it. People can subscribe to your podcast and you can subscribe to other people’s podcasts. You can also subscribe to a podcast of files with a certain tag or a combination of files from a particular person with a particular tag. Basically, if there’s a page for it on the site, there’s probably a corresponding podcast you can subscribe to.

So if you’ve ever fancied curating your own podcast, head on over to huffduffer.com and sign up for an account. If you’re interested in the kind of audio I find interesting, you can subscribe to my podcast.

By its nature, this will never be a popular, mass-market site. But, as is the case with most things built to scratch a particular itch, I hope it will turn out to be useful for some other people. If other people do end up using the site, that will open some opportunities for bubbling up some interesting stuff: popular MP3s, popular tags, recommendations of files from users who share similar interests with you.

I had quite a lot of fun building Huffduffer. It’s been a while since I’ve done any back-end programming so I used this as an opportunity to get intimate with the whole MVC idea. I thought about building the site in Django or Ruby on Rails, but in the end I decided to stick with PHP. I investigated some of the PHP frameworks out there and, while they all had parts that I liked, I decided to roll my own code …my own framework, really.

On the front end, the site is built in HTML5. I did this partly for the heck of it, and partly to show that HTML5 is not some future technology but something that you can use right now. The validator by Henri Sivonen proved invaluable.

The visual design of the site is very minimal, as most of my sites tend to be. On the plus side, this means the site is lean and fast-loading. On the minus side, it’s monochrome to point of boredom. But I spent quite a while crafting the typography just the way I want it in the belief that, if you’re going to concentrate on one aspect of visual design, the typography is probably the best place to start.

I’ll be iterating on Huffduffer over time. It’ll be interesting to see how the site gets used (if at all) and react accordingly.

Check it for yourself and see if it’s something you might like to use. If you have any questions, comments, or suggestions about the site, feel free to chime in on Get Satisfaction.

Upcoming.org has rolled out some changes. The visual design has been tweaked, particularly on the events pages.

The colours and typography are looking very good indeed. The change to the way attendees are listed inline doesn’t work quite as well. I’m not the only one who thinks so. But instead of just bitching about it like me, others have provided mockups as part of their constructive criticism.

While this latest update is one of the biggest changes that has been rolled out on the site, it certainly isn’t the first. In fact, Upcoming seems to be in a constant state of gradual change and improvement.

There’s a lot of talk these days about iterative design, but Upcoming is one of the few places where I’ve noticed it in action. The design has been improving gradually and almost imperceptibly. Did anyone notice when the top banner changed from being a solid colour to a gradient? I wish now that I had taken screenshots of Upcoming every few weeks. They would make for an interesting time-lapse movie.

The Yahooiness of Upcoming is beginning to make itself felt. You can now migrate your Flickr buddy icon over to Upcoming. Also, if you tag photos on Flickr with “upcoming:event={event id}”, they will show up on the corresponding event page. Then there’s the maps integration.

Both Upcoming and Flickr are now making use of Yahoo maps. The Flickr map exploration page is, like so many things on Flickr, a real time-sink. It’s fun browsing photos with the added context of location.

But — and it’s a big but — Yahoo’s mapping data for Europe is particularly poor. So don’t expect too much detail when you’re browsing holiday snapshots from Brighton. I blame crown copyright myself (though I do wonder how Google has managed to get such detailed data).

As part of this latest iteration, Flickr are moving away from using tags for geocoding:

As a bonus there will be no more need for the unsightly “geotagged/geo:lat/geo:long” tags cluttering up your photos - we’ll offer an automated way to remove them all once the development community has had a chance to make the necessary changes to their code.

I’m not sure that’s such a good idea. There’s nothing wrong with using visible geographical co-ordinates. I’d prefer to keep my meta-data visible, thank you very much.

Back in March, during South by Southwest, Tantek asked me if I’d like to sit in on his microformats panel alongside Chris Messina and Norm! The audio recording of the panel is now available through the conference podcast.

I’ve taken the liberty of having the recording transcribed (using castingWords.com) and I’ve posted a tidied up version of the transcript to the articles section: Microformats: Evolving the Web. You can listen along through the articles RSS feed which doubles up as a podcast.

I’ve also posted the transcript on the microformats wiki so that others can edit it if they catch any glaring mistakes in the transcription.

During the panel I talked about Adactio Austin, a fairly trivial use of microformats but one that I’ve been building upon. I’d like to provide some cut’n’paste JavaScript that would allow people to get some added value from using microformats. Supposing you have a bunch of locations marked up in hCard with geotags, you could drop in a script and have a map appear showing those locations.

Perhaps the geotagging won’t even be necessary. Google added a geocoder to their mapping API two weeks ago. The UK, alas, is not yet supported (probably because the Post Office won’t let go of its monopoly that easily… Postman Pat, your money-grabbing days are numbered).

Unfortunately, Google Maps isn’t very suited to the cut’n’paste idea: you have to register a different API key for each domain where you want to use the mapping API.

The Yahoo maps API is less draconian about registration but its lack of detailed UK maps makes it a non-starter for me.

Maybe I should step away from maps and concentrate on events instead. It probably wouldn’t be too hard too write a script to create a calendar based on any hCalendar data found in a document. Perhaps I’ll investigate the calendar widget from Yahoo.

Ultimately I’d like to create something like Chris’s Mapendar idea. If only there were enough hours in the day.