Herewith a list of the software that made an impression on me in 2009.

Expression Engine

I built my first two sites using Expression Engine this year, one for the Cumberland Chamber and one for the Downtown Courtenay BIA.  EE’s niche, in my view, is to make working with custom data types easy.  However, in most other ways it just felt too opinionated and difficult to customize (e.g. the related_entries features).  After building so many WordPress sites, though, the EE 1.x admin experience felt seriously unpolished.  Media handling, for example, paled in comparison. I look forward to trying EE 2 when the opportunity arises but until then count me underwhelmed.

Solr

The most pleasant surprise of 2009 was Solr, a fantastic search platform derived from the Apache Lucene project.  I used it to index and search a 40,000-product database and it was incredibly gratifying.  Despite my distinct lack of Java skills, the documentation was clear and the deployment was remarkably painless.  Even better, Solr replaced an unholy MySQL SELECT statement including four subqueries with one straightforward config file.

HTML 4

Not technically software, but it deserves to be mentioned.  Where possible I’ve abandoned XHTML and all its craziness and built sites using HTML 4 Strict.  I don’t need namespaces or mime-type headaches.  Straight-up HTML is just fine by me.

I bought a three-year-old MacBook Pro from a friend, my first Mac since an Apple II.  It was kind of fun so I ended buying a 27″ iMac a month later.  It’s a lot of fun.  The Unix roots of OS X paved the way for the next two items.

Git and GitHub

After letting too many Ruby projects rot away in private SVN repositories I finally moved most of them over to my GitHub account.  The main reason it took so long was the Git learning curve, especially for a Windows-user like me.  Once I moved the code over, however, I was truly impressed. The fork-and-pull mindset that GitHub enables so well is fantastic. My once-neglected plugins and gems have gotten a new lease on life since others started improving them.

GitHub activity for the Ruby Holidays Gem.

rsync

Finally, one of my best workflow improvements was also the simplest: rsync.  Before I would deploy using SVN exports via bash scripts or straight up FTP.  But my new Mac finally made rsync an option.  For simple deployments it just can’t be beat.

Here’s me deploying an update to a WordPress theme.

rsync -rvzt --executability --exclude=.DS_Store
   /Users/Alex/Sites/client/www/wp-content/themes/client/
   dialect@dialect.ca:/home/dialect/staging/wp-content/themes/client/

All in all it’s been a good and productive year.

What tools did you enjoy in 2009?

I certainly sympathize with print designers.  Their clients all want to get on the web and print designers must feel they either need to step up or lose the work.  Unfortunately, the results are rarely pretty.

The number one difficulty is perfectly summed up by the factor[e] post:

Unlike with print, you are designing for a page whose size you don’t know.

So true, and I think this really trips out a lot of print designers.  They assume footers will be anchored to the bottom of the viewport, or don’t consider what happens at the edges of the main content.  (In fairness, even experienced web developers struggle with this).  They also miss out on the interactive elements like hover states and transitions, and generally design sites that don’t feel natural on the web.

I think there are only two sensible options here.  Either print designers should stop and immerse themselves in the web before trying to put together any more sites, or they should stick to what they’ve already mastered.

As he aptly writes

coding a website introduces inherent realities which a Photoshop document cannot account for. As a result, I’ve found myself (and I’m sure many of you can say the same) dialing down my designs somewhat to allow for a more realistic and attainable end result.

I partially agree with his point.

I can’t count the number of times that I’ve opened one of Nik’s Illustrator files and gone “gack! How am I meant to implement that?” However, that is immediately (or eventually) followed by me thinking a little creatively, drawing out some DIVs in pencil, looking up the state of some CSS property, and then implementing what he specified. If he’d felt constrained by code (or by my abilities) the project would have suffered and I wouldn’t have learned anything.

However, Nik’s designs are also better because he does understand code. Understanding that fonts can be replaced easily in headlines but not in body copy means that our sites will load quickly. Understanding which mouse events fire means our sites feel responsive. Understanding the different methods of implementing full-bleed background images mean that our sites stay sane at different resolutions.

Compromise

The middle ground seems like the only healthy way to go here.

Designers should understand the medium as best they can, which includes learning some code. They should do this so they understand the possibilities afforded by the web, not just its limitations.

Coders should understand design as best they can, learning to love grids and caring about colour profiles. We should do this so we can see the big picture on a project, not just the database connection and form validation.

More importantly, designers and coders should collaborate. We’re all trying to meet the same goals, we just have different tools.

This has been discussed a few places, notably A List Apart’s article on dashes and typography, but they all end by saying that hyphenation and word spacing isn’t very well supported by browsers.

The Test

There are quite a few spacing and hyphenation options available in HTML. I just looked at the ones that I was hoping to use.

I put together a test page and, with the the help of Tom Hammarberg, Jeremy Latham and Clint Lalonde, collected some screenshots of the results.

Here’s how everything should look.

The Results

Non-breaking space     Š

Prohibits the browser breaking to a new line

The verdict: Perfect

Soft hyphen ­ ­

Suggests a hyphenation point to the browser.

The verdict: Perfect

Zero-width space ​ ​

Provides a breakpoint to the browser without showing a visible space.

The verdict: Good, with a caveat

The Caveat

Can you guess which browser we’re going to discuss?

Right, Internet Explorer 6.

IE 6 suprised me and handled soft hyphens beautifully. Things got a little messier with thin spaces, hair spaces and zero-width spaces.

Some fonts, like Palatino Linotype, include glyphs for each type of space and hyphen. Others, like Arial, Verdana and Times New Roman, do not.

In all the browsers I tested, the browsers didn’t care whether or not the glyphs were defined, they were able to render the spaces and hyphens anyway.

If IE 6 couldn’t find the glyph, it displays everyone’s favourite square: □.

Are They Usable?

Soft hyphens work perfectly with the standard set of web-safe fonts in every browser.

If you’ve decided to drop support for IE 6, you’re good with any space or hyphenation glyphs.

But, if you’re supporting IE 6 and still want the refined text flow available with spacing and hyphenation, you’ll have to choose a font that includes those glyphs.

Your web-safe choices are:

• Arial Unicode, Arial Unicode MS
• Lucida Sans, Lucida Grande
• Palatino, Palatino Linotype

To check if the font you’re targeting supports fancy spaces and hyphens, open up Character Map on Windows and search for either space or hyphen. Mac users will have to wait til my new iMac arrives for instructions.

In Conclusion

I think you have to be a “special” kind of person to care about these things, but that’s me and I know the site we’re building now will look at least 2% better because of this experiment.

If you use a browser that I haven’t included, send a screenshot to alex [at] dunae.ca and I’ll add it to the gallery.

At the time I was experimenting with Rails, so I released a few plugins, including one that became pretty popular.  Since then, I’ve released a few more odds and ends, notably a few WordPress plugins and Premailer, a tool that helps build email newsletters.

My motivation was pretty clear in the beginning–the web had been good to me, and I wanted to do my part for other developers. But I’ve often wondered if there were other benefits to releasing code, and what they could be.

Here’s a brief of summary of what I’ve found.

Economic benefits of giving away code

After two years of giving code away for free, my bank balance hasn’t changed much.  I’ve made money in three different ways: selling sponsorship, being hired to write plugins, and receiving donations.

First up: sponsorship.  Campaign Monitor has paid to sponsor Premailer since its inception.  I approached them and offered them exclusive placement.  I felt it would be good value to them (since the site is used exclusively by people designing HTML email) and I liked them as a company.

Next: code for hire.  I’ve received quite a few enquiries about modifying my code for specific purposes, as well as requests to write plugins from scratch.  That’s how the MailChimp Shopify plugin came about.  About 15% of those requests came to fruition.

Finally, donations.  I’ve never put up a ‘donate now’ button, so the few I’ve received are from people who actually emailed me and asked for my PayPal account.  Those emails always feel very nice.

All told, I’ve made $5,000 or $6,000 giving away code.

Promotional benefits of giving away code

The promotional benefits have been a little thinner than I would have guessed.  With each release I’ve gotten some nice announcement posts (see here and here) and a little upswell in traffic, but none of that has lead to an enduring client relationship.  I put this down to the fact that the people using my code are my peers (sometimes known as competitors, I prefer peers) who don’t necessarily need to hire a web developer.

Educational benefits of giving away code

Releasing code to other developers has made me a better programmer.  When I build a web site I’m in complete control of the environment, including what libraries are installed and what character encodings are used.  Public code gets scrutinized and tested in many different environments and has helped me learn what it takes to make something portable. I’ve also learned from the bug reports and contributions of other programmers.

Finally, writing and releasing code is my preferred way to learn.  Long after my initial flirtation with Ruby on Rails, I keep up my limited Ruby skills by maintaining code that I’ve released.

All in all, giving away code has been a good experience.  I don’t think it’s possible to reconcile the hours of labour to the intangible benefits of education, but I do feel that giving the code away has been very beneficial.

My usual workflow is this:

1. Turn on the guides in the source Illustrator file and do a little reconnaissance
2. Write a page’s markup in a static HTML file
3. Position and size all the content elements
4. Position and size the type
5. Add any dynamic behaviours
6. Add all the colours, backgrounds, icons, etc…

In an effort to do a little professional development, I finally decided to recreate the Illustrator guides in my HTML file using a PNG file mixed with a sliver of JavaScript.

Here’s my working file before:

And here it is after pressing ‘g’ to toggle the grid view:

You can see a live demo right here.

This simple addition cutout countless rounds of revisions and has actually made my job a lot easier. The code to accomplish this is nice and straightforward, and easy to strip out when you go live.

In my CSS file, I declare the grid styles that will appear when the body has the debug class.

/* the main grid */
.debug #container { background-image: url("grid.png"); background-repeat: repeat; }
 
/* light box for base elements */
.debug #header, .debug #viewer, .debug #footer {
	background-color: #d9d9d9;
	opacity: .8;
}
 
/* dark box for overlayed elements */
.debug #header .nav, .debug h1, .debug #footer .section {
	background-color: #b9b9b9;
	opacity: .8;
}

The JavaScript simply listens for someone to press g and then toggles the debug class on the body element. (N.B. I’m using jQuery in this example.)

$(document).ready(function () {
	$(document).bind('keypress', function (e) {
		if (e.which === 103) {
			$('body').toggleClass('debug');
		}
	});
});

Of course, you can see all this on the demo page.

Incidentally, as I was drafting this post New York Times designer Khoi Vinh announced his nifty Basic Maths WordPress theme, which has this exact same feature. Needless to say, I think he’s brilliant.

To figure out what sort of dimensions we were dealing with, and whether the images were primarily horizontal, vertical or square, I put together this little script.

This is a Windows batch file that outputs the dimensions and aspect ratio of all the images in a directory as a CSV file. It uses ImageMagick’s identify tool.

@ECHO OFF
ECHO file, w, h, aspect > aspects.txt
FOR /f %%a IN ('dir /b *.jpg') DO ( 
  identify -format "%%f, %%w, %%h, %%[fx:w/h]" %%a >> aspects.txt & ECHO %%a 
)

Stoyan and Nicole are Yahoo! employees, and Smush.it was moved under the Yahoo! banner fairly soon after its launch.  I was pleased to see that move.  Long before Google-hosted jQuery and Closure, Yahoo! was making high-quality tools available to web developers (YUI library, YUI Compressor) for free.  They integrated Smush.it with YSlow and put up a basic web interface.

Since then, Yahoo! has moved Smush.it fairly often, and I’ve been playing cat-and-mouse with them, changing the API endpoint URL in my plugin to try to match their changes. This has been in response to a bunch of support requests from my users in the forums, and many more by email.

For a while I felt indignant. The service worked–in fact it was being used by YSlow every day–and if they would just stop moving things around then my unauthorized access to their API would work just fine. Stoyan had complimented me on the plugin, which I took as tacit approval.  The load from WP Smush.it users must have been minimal.

I’ve come around a bit since then.  I freely acknowledge that I don’t know what it takes to keep a service like Smush.it up and running. If they don’t want my plugin using Smush.it, that’s there prerogative.  My gripe now is about communication.

When I developed the plugin there was a public API, and over the course of a few months the endpoint URL kept changing without any word from Yahoo!  I kept trying to catch up, thinking that they were just in flux and that a stable service was just around the corner.

So, here’s the “ask” (as they say in business): I’d like to know if Yahoo! intends to make Smush.it available for API access sometime in the near future (I finally found out that it is temporarily unavailable).  One way or the other I need to figure out what to do with this plugin.  I’m happy either way.

Dan wrote:

Remember when blogs were more casual and conversational? Before a post’s purpose was to grab search engine clicks or to promise “99 Answers to Your Problem That We’re Telling You You’re Having”. Yeah. I’d like to get back to that here.

I never had a blog back in those days, but I was sure reading them, and I do remember what it was like.  It was weird and it was good.

Lloyd’s contribution was a comment about the WordPress.com stats he monitors.  He said that he cares most about how much people communicate each day using the software he helps develop, not about how many users sign up, or how many pay for upgrades.  (Turns out he’s said this more than once).

These two seemingly-unrelated comments were the catalyst to start this blog.

Part of the blog will be about web development, specifically sharing back some of the techniques I’ve picked up over fifteen(!) years of building web sites.  And part of the blog will be about intellectual development, namely the various articles and such that I find thought-provoking and enlightening.

My hunch is that amateur intellectualism and code don’t mix too well, but there’s only one way to find out.

Like others in the so-called good-food movement, Allen, who is 60, asserts that our industrial food system is depleting soil, poisoning water, gobbling fossil fuels and stuffing us with bad calories. Like others, he advocates eating locally grown food. But to Allen, local doesn’t mean a rolling pasture or even a suburban garden: it means 14 greenhouses crammed onto two acres in a working-class neighborhood on Milwaukee’s northwest side, less than half a mile from the city’s largest public-housing project.

Street Farmer
– Elizabeth Royte, New York Times Magazine, July 5, 2009