development

A friend got in touch recently to ask for help on making a career change into web development. They were involved in technology some fifteen years ago—more than me in a lot of ways—but appreciated that things had changed almost beyond recognition, so they would at least need to upskill and were worrying if they should concentrate on retraining and getting an academic qualification. In effect, they were giving themselves maybe twelve months of spare time to become at least savvy enough for an entry-level job in the industry, and wanted to know if I could advise them.

I didn't initially see how I could possibly help them. After all, in terms of web development I'm almost completely self-taught, and a lot of that has been through processes of osmosis and curiosity rather than through any particular grand plan. Also, my career has been one of sideways motion first—DPhil student to L^AT_EX compositor to journals e-publisher to web and CMS developer—and any upwards motion very much later, so it's not as though there was a clear path set down from the start that I could advise on.

In a flash, an idea came to me: if I were reconstructing myself as a web developer—all over again, but this time doing it systematically and with a timetable like twelve months in mind—how would I go about that? How might I build myself, all over again, in the space of twelve months? That's not to say that I'm a perfect developer, by any stretch of the imagination; but I'm a developer of a sort I recognize from the inside out, so it might help me offer advice more coherently. Anyway, I started writing... and writing... and writing.

When I finished, I had a lot of ideas, but I hoped that they weren't too prescriptive.I wanted it to be more flexible than edicts of "do it my way": my friend could pick and choose what they liked, and almost any result might be of more value than that of the effort put in. Much later, it's occurred to me that this list might be useful to (or at least worthy of comments by) other people. So if you're not sure how to get into the industry, or if you need a different perspective on it, then have a look at the notes below and see if any of it helps you.

• READ: Hacker News is a reasonable starting point these days. Make it your homepage if you've no better suggestions. It's like the Digg bit of Y Combinator: HN is what happens when geeks meet venture capitalists meet project managers, in a shared discussion space. That sounds like it could be a disaster, but it helps to surface a lot of blog writing where VCs think about tech and geeks think about scratching other people's itches. There's sometimes talk in the comments about programming careers and the industry, and the list of news items tends to bring to the surface lots of new technology and even people's work in progress (more illuminating, as you learn about e.g. how people do hosting these days, or deployment.)
• READ: Stack Overflow. It's probably the future of online documentation and problem-solving. Consider getting involved and helping out with replies.
• READ: Wired, Techcrunch, 37signals, UXMovement, Coding Horror, Diveintomark. Avoid: Slashdot and The Register; these days they're repositories of of churnalism, contrariness, well-actually and tinfoil hats.
• ATTEND: any local meetups for techies you can find. I run the Oxford Geek Nights. These things get organised in the weirdest places, though, so you might find one near you. Check on Upcoming and Lanyrd.
• ATTEND: OpenTech 2011. It's cheap as chips—a fiver for entry—and you get to peek at lots of not-for-profit and similarly exciting projects. Interesting 2011; maybe Future Of Web Apps if you can afford it. The last one gets a bit speculative at times, but they're all weathervanes for the industry and what's, well, interesting.
• FIND: an itch to scratch. Once you've begun to dip into the industry, you've really got to have something you want to do to keep going. Unless you're really able to go through book after book, just doing the exercises. (Besides, a lot of the following is quite hard to find in books.) Something you're currently having to do that's really repetitive, that a simple website or program could help you with. Maybe you could build a "single-serving" site like caniturniton.com, for you to be able to check on your phone when you're out and about. Have something in mind that you will actively want to play with and it'll keep you involved.
• RESEARCH: about how things like the cloud work. EC2, S3. Alternatives from e.g. Rackspace. VM hosting from e.g. Bytemark. Google App Engine. All their APIs: at least know that they exist. Look at new technologies. PHP is still going strong but for security development REALLY needs to happen within a framework. Ruby (on Rails) and Python (Django) are "sexy" and they work. Look at the MVC-ness of these new frameworks. Get a feel for why they're like that. Have a look at AOP (kind of event driven programming) and other non-MVC paradigms. CMSes are freeware these days: Drupal and Joomla are robust products capable of much complexity; Wordpress simpler but more popular. Know that they're out there and what sort of stuff they can do. MySQL still powers the web, but look at NoSQL alternatives like CouchDB if you get a chance.
• RESEARCH: Dive into HTML5 is a great resource for information about the new generation of web standards. CSS3 is going crazy, with a whole demoscene of pointless, Flash-less content; it'll settle down soon but it's all still exciting. Javascript, along with jQuery, is finally a respectable programming language. VCS has turned into DVCS, with the onset of git and mercurial. Use one of these for your own projects as a rule: I like git, but pick whichever. There are great, free online references for all of this especially the Pro Git book.
• JOIN: Twitter, Delicious (despite the fact that it might not be around forever), LinkedIn, Github, maybe Bitbucket. Use Delicious extensively: look ahead to paid alternatives like Pinboard; pipe specific tags (e.g. "fortwitter") to your Twitter account using Twitterfeed. Do the same with LinkedIn, but don't have services automatically retweeting; consider what your audience wants. Get yourself a presence online in a way you might find slightly aggressive at first, as you've got a lot of ground to cover quickly.
• PLAY: Find a language you like and start to play with it. My personal favourite is Python, even though I do mostly PHP these days. Python is OO, but has a very loose feel to it (google for "duck typing") and, on top of a nice syntax and style, it employs concepts of code aesthetics rather than strict right or wrong choices.
• BUILD: Write lots of code. Lots and lots. Wonder how things work in a language. Try example coding. Fork someone else's project on github and tinker with it. There's so much code out there for free these days that you should be able to find something to play with.
• POLISH: pick some of these recommendations off Stack Overflow and consider reading them. I'd say The Pragmatic Programmer and Mythical Man Month are good "cultural" tomes. Others are up to you. I'd recommend my book, but in all honesty diveintopython.org blows everyone else's writing on the subject out of the water. If you've still got some spare time, read the wikipedia entries on principles like Agile, XP, Scrum, Kanban etc. so you can work in those environments if you're asked to.

Not all of this will be of use to everyone; some of it might even be of use to no-one; but I wanted to put it out there for other people to see, should it help them in any small way. And while I'm not interested in holy wars particularly: "is Slashdot not still worth reading these days?" for example. Instead, I'd love to know how you personally would rebuild your career persona from scratch, given twelve months.

Why not blog about how you might go about rebuilding yourself over a year, and post a link in the comments?

Developing Drupal in a development--test--production environment has a lot of advantages. Each developer's work is sandboxed, staging is straightforward, and deployment to live the stuff of Capistrano scripts---especially if you unite the entire ecosystem of separate environments with version control.

However, it can lead to confusion over precisely where your browser's currently pointing at: at best, this can be comical; at worst, it can result in either loss of live content or the logjamming of a staged site with content intended for live. Suddenly a staging environment is out of action until that content can be exported to the live site.

Enter devwatermark β-0.1, a D5 module intended to watermark any non-live sites with a little right-hand banner overlay. When first enabled---you can do this on your live site---it inserts no such banner. However, as you add live domains to its configuration, it begins to work out when it's not on a live site and tags your browser window with the "DEVELOPMENT" banner. Like watermarking your printouts with "DRAFT", or maybe like dogearing a page in a book. If your site has to respond to multiple domains---and if the content is the same then you should really serve up 301s instead---then you can add those extra domains to the configuration as required.

Having devwatermark enabled on live means that when you bring a live database down to a staging site to test the next round of updates, the change in domain will make devwatermark automatically show its banner image. You know instantly when you're in a development---and hence content-volatile---environment. That means that you can also watermark staging sites as non-development too: by adding them to devwatermark's configuration you can confirm to the developers that here's a database environment that they can't wipe and start again.

As I mention above, it's currently only available for Drupal 5, and your theme has to respect hook_footer (most do out of the box.) But please feel free to download it and give it a try.

EditInline was first discussed here. It's a Drupal module that provides your site with handy editing links, inline with each node title, which rather than taking you to a separate editing page use a lightbox overlay on the current page to provide an inline editing interface.

It's currently in alpha but available under GPL on the Torchbox public subversion repository. I've recently prepared another alpha subversion release, so if you want to have a look at EditInline ɑ-0.2 then feel free to download and let me know what you think.

(The main improvement from ɑ-0.1 is a dedicated form workflow for editing inline, which results in submission of the form leading to the lightbox overlay being automatically closed. Future releases should include CSS hooks into the lightbox content and other usability improvements.)

It's heartwarming, really encouraging to see that Drupal 7 is undergoing a usability review. Drupal's a massively functional CMS, but all the functionality in the world won't help you when the average (for which read: can't write HTML, let alone PHP) CMS user can't discover it. There's a common misconception that usability is the finishing touches you add to an application if you've got time, the icing on the cake; but if your application lays any claim to maturity then its usability is the cake, and all that functionality you were so proud of is, without usability, just eggs and flour.

One of the main usability improvements suggested by the usability team---and largely shouted down by the technical team---is the ability to edit inline on the page: that is, to log in as an admin, then have any bit of the page "active", so that if you click on it then it becomes an edit box with the text inside. Flickr does this especially well, letting you edit title and description on photo pages and lists of photos by just clicking on the apparently uneditable text. But Flickr has the advantage that there's very little form on top of its content: it's a delivery mechanism for the raw metadata about photos, and the photo itself.

The other end of the spectrum---which complex CMS sites have every right to sit on---is a rich and complicated mapping between the storage of a node's content in the database and the eventual display of it in the browser. take a page from a recent Torchbox project at random, how would you expect areas of this page from the Joseph Rowntree Foundation's website to behave when you clicked on them? If you have to hardcode print statements in your PHP templates, what do you print? How do you get editing inline to work? What happens when content is brought in from other, related nodes, and mixed in with the other content before display.

I can appreciate both sides to this story of user experience versus technical practicality, although it's not sufficient to expect the usability team to discard the idea merely because there's no correspondence between page content and database content: that's only an argument for why Drupal doesn't currently have edit-on-page. The usability project is moving forwards rapidly, and while there's clearly a tension between usability for the CMS user and feasible technical limitations---usability for the developer, if you like---it will need to be resolved soon for this marvellous work, and a great opportunity, not to end up wasted. And resolving that conflict will involve some sort of compromise, for both sides.

One possible compromise would be to offer edit links, when Drupal can spot a sort-of 1-to-1 correspondence between a fragment of page content and the node that supports it. Page templates and views---specifically hook_preprocess_node and hook_views_pre_render---know full well that what they're processing is a node. And they generally know what field the node title will be in. So let Drupal rewrite the title, to add an "edit inline" link. If anyone clicks on this link, then pop the node-edit form up in a lightbox for editing.

Here's some screenshots of what I've been working on, in an attempt to get people interested (click for bigger.) Firstly, here's what the anonymous site visitor sees:

Next, here's what happens when a user has just logged in. Note that the brilliant Admin menu module kicks in, giving the user a black navigation bar across the top. But, more pertinently, each node title also now has an "[edit inline]" link beside it:

If the logged-in user clicks on one of these new links, then our edit-inline module kicks in and, using the equally brilliant Drupal Thickbox wrapper module, provides a stripped-down version of the node-edit page in a Thickbox overlay, both speeding up node editing using AJAX calls and also letting the user cancel the node-edit procedure and return to the webpage they were on quickly:

To reiterate, you don't have to be on a node's page to edit it. All that matters is that the title of the node you want to edit passes through onee of the supported pre-render hooks. Currently, clicking on save/preview/cancel takes you elsewhere rather than being trapped within the Thickbox, and we're also wrestling with getting CSS and Javascript into the Thickbox overlay to support the nattier bits of node editing, but it's functional and, I hope, gives you some idea of how it would all work given a few more hours of bashing away at keyboards.

Anyway, there it is. A possible compromise. I've mentioned it in a comment on the d7ux blog but I fear I might have been eaten by a spamtrap. If anyone's interested in the project then email me, jp.stacey, either at gmail.com or torchbox.com, and say hello.

Steve compares “graceful degradation” with “progressive enhancement.” Mostly he takes issue (rightly) with the rhetorical spin that the former applies to the idea of building a website. But I think you can compare them with each other as if they were two different types of crowbar instead: two ways of prising open the task in hand.

What I like most about progressive enhancement is that it gives me a way of tackling the age-old problem of turning a design for a client into a workable, accessible page without going completely mental. Before, if I saw a dropdown on the designs without a submit button or some such, I’d think, well, the HTML won’t have a submit button either, so I need to build the Javascript at the same time and get it all to work at once. This led me into all sorts of tangles—each one on its own easy to extricate myself from—and at the end of it I would have a form that would work or look right without every layer of technology in place.

But if you’re thinking progressively at the back of your mind all the time, you can start with an unstyled, unscripted form that works, and then use subtle styling to get exactly where you want to be. Some onloaded Javascript can give you a body.js class with which to hide unwanted submit buttons. At the end, if nothing else, the form still submits when Javascript is turns off, and it looks OK because you checked at the outset.

Progressive enhancement, ironically for the amount of work it implies, actually places the least stress (and maintenance workload) on the developer, and makes them learn a thing or two about layering and modularity at the same time. And as Steve points out, in this model there is no degradation: just the near-hotswapping of a range of technologies on top of a sturdy markup language that has been around in various forms for over a decade.

Assaf writes about, among other things, REST as a simplifier of development against an existing system:

REST plays the same role as open source and open APIs: It eliminates tooling and vendoring as artificial barriers to adoption.

Interestingly, a corollary to this was brought up at Barcamp Brighton this weekend. During Gareth Rushgrove’s talk about REST and Nabaztag, a chap whose name I’ve again forgotten (although I’m sure someone like Fatty will enlighten me) pointed out that much of the push of SOAP is coming from the vendors, because the vendors make their money from selling tools, and REST development needs very few tools, most of which are free.

Undoubtedly there’s a set of problems that REST finds hard, but this truism is extended by SOAP vendors to the hard-to-prove (but also hard-to-contradict) claim that it’s a larger set, or a set more pertinent to enterprise solutions, than the set which SOAP finds hard. It convinces the consumers, because intelligent data mining and storage has always been a difficult problem, and a simple solution like REST feels like underkill for the job in hand. They let you confuse libre and gratis, the vendors point out (I see them sitting on the consumer’s shoulders with tridents at this point): so where’s the hidden cost of this free lunch?

(hat tip to Simon Willison)