This past Saturday I attended BarCamp Toronto 4, the “un-official un-launch” to Toronto Tech Week. It was easily my best BarCamp experience yet. Here’s a quick summary of what I picked up:

Start-ups should consider web hosting from the world’s largest bookseller

Paul Dowman from GigPark led a discussion on the Amazon EC2 grid hosting platform, touching on both technical details and what the service ultimately means to small businesses. EC2’s ability to arbitrarily scale your application up to X servers at an affordable hourly rate is incredible, letting you do neat stuff like simulate a high-load situation on your application for mere dollars. EC2 customers can also pull/push data from Amazon’s S3 file service at no additional cost, which is another significant selling point.

The crowd happened to have a couple of other EC2 customers in attendance, and so far their experiences have been positive. It’s worth nothing that Media Temple and Joyent also offer similar services.

Darcs is the natural evolution of source control

Darcs is like Subversion, but with one significant change – every checked out copy is its own repository. You can check out from the main branch, log changes against your local repository offline, and when you’re good and ready, submit a patch back to the project maintainer straight from the command line. You can also fork the project then and there, with a repository ready to distribute immediately – your choice.

Darcs’ self-replicating properties could seriously affect the state of open source distribution. No more single points of failure; less dead projects. All it needs now is some screencasts, a book, and perhaps most importantly, a champion.

Update: James King has put up his Darcs presentation notes

Side note: Rack, a minimal Ruby web framework, is being distributed/maintained using Darcs.

The Facebook Platform could change the web

Facebook is huge: they serve 40 billion page views per month, it’s growing at a rate of 3% per week, and Toronto alone has over 500k registered users. The recently announced Facebook Platform enables developers to create externally hosted applications that are accessed from inside Facebook itself. It’s exciting, scary, and full of possibilities. It could very well change the web.

I’m not an expert on the platform, but since I first started hacking on it Friday night, I’ve had this feeling that we’re in the midst of something big, and I’ve had this overwhelming urge to talk about it. So, in a move that’s totally out of character, I decided to start an open discussion on the Facebook Platform.

It turns out I wasn’t alone. The group quickly approached our room’s 50-person capacity, and we glossed over everything from technical details, security and privacy issues, monetization, and more. A couple of developers already have projects lined up. Domain names have been registered. It’s exciting stuff, and we’ve only seen the tip of the iceberg.

See also: Pictures tagged with BarCampTTW via Flickr

I happened to read The Great Pyramid of Agile over at Worse Than Failure the other day. Despite feeling slightly misled when I learned that agile development isn’t, in fact, a giant pyramid scheme, I did stumble on a pretty fair criticism of the whole agile trend. It’s a shame though – the pyramid scheme angle might have made for a more interesting article.

I’ve been calling myself an agile developer for a little while now. No, I don’t subscribe to any of the much publicized (and well monetized) methodologies that exist today. To me, “being agile” simply means creating a sustainable development environment that makes it easy to adapt your application to change. I guess I’m referring to “agile” in the original sense of the word:

agile

adjective:
   1. Characterized by quickness, lightness, and ease of movement; nimble.
   2. Mentally quick or alert: an agile mind

When you make the effort to create such an environment, change becomes tolerable, and so prototyping and iterative development tend to just “happen”. They’re one of many pleasant side-effects of being agile: shorter release cycles, less coder defensiveness, ability to incorporate feedback quickly, and so on.

Now whether you’re working on the latest web application or a 15-year enterprise monster, I believe that every good programmer is agile on some level. When you write code in anticipation of change, even inside a small piece of a larger puzzle, you’ve made some effort to make your code agile. When you write unit tests that help you discover and debug errors faster, when you use source control, or even a code-completing editor – these are all steps towards becoming agile.

I guess what I’m trying to say is that agile development isn’t about SCRUM, XP, trade conferences or selling books. It’s about being smart about development. It’s about being agile according to the dictionary meaning of the word.

This past Friday and Saturday I attended DrupalCampToronto, a BarCamp-style gathering of Drupal enthusiasts here in Toronto. Now, I’m not really a Drupal guy, but now that I’m developing professionally in PHP, I thought it’d be a great opportunity to learn about and discuss one of the more popular open source PHP projects and CMS frameworks.

I’d estimate roughly 100 people attended the ad-hoc conference, spanning 4 rooms at the University of Toronto’s Bahen centre. I attended mostly introductory sessions: a general Drupal overview, an event-site building tutorial, an introduction to module development, and so forth. The event’s highlight, for me at least, was James Walker’s technology-agnostic talk on OpenID – an in-depth continuation of a shorter demonstration he gave at DemoCamp13 last month.

As a beginner I found the Drupal material a little tough to digest, and by Saturday’s end (and a week of fooling around with a local Drupal installation) I couldn’t consider myself among the converts. I did however meet some interesting folk, had two fantastic meals, and picked up a killer event t-shirt – a recipe for success if there ever was one. Thanks to the organizers for a great job.

See also: DrupalCampToronto on Technorati.

If there’s one distinct argument I keep hearing against the use of JavaScript frameworks like Protoype, it’s that their large file sizes trump any perceived improvement in developer productivity. The naysayers may have a point: the latest version of prototype.js (without script.aculo.us) now weighs in at an unsightly 93kb. In terms of both page loading times and total bandwidth considerations, that’s more than some may be willing to swallow.

The thing is, if you’re willing to invest a few hours you can overcome the file size issue. What follows is a list of compression techniques and alternate libraries for making it happen. And don’t worry, you’ll earn the time back.

Whitespace minification

Just as it sounds, whitespace minification is the technique of removing all comments and whitespace from your JavaScript files. For heavily commented or indented code, the benefits can be surprising. The downside is that Prototype will essentially become unreadable, but you can always keep an unaltered version handy during development.

There are a number of tools out there to get the job done, but they all do the same thing, so you might as well use JSMin.

Running JSMin on prototype.js yields a final file size of roughly 71kb. That’s a significant improvement (~76% of its original size) for very little work, but still might be too large for some.

Code compression

JavaScript code compression involves re-writing code to be as concise as possible. This usually involves removing whitespace and comments, reducing variable and function names, and some form of encoding or ASCII compression. A pretty simple web-based tool for doing this is Dean Edward’s packer.

Seems simple enough, but most compressors require that JavaScript code have semi-colon delimited lines, which Prototype doesn’t have. A couple of folks have taken on the task of adding semi-colons to Prototype, and have begun distributing an unofficial version in various compressed forms , getting file sizes below 20kb, and even lower when paired with gzip compression (see below). Unfortunately these aren’t official releases, so you may have to wait longer for updates, plus they’re unsupported.

GZip compression w/ mod_deflate

If you’re not familiar with this technique, here’s a quick summary. Your clients’ browsers tell your server that they support gzip compressed files as part of their HTTP request headers. Your web server returns in kind with a smaller, compressed version of the content that is downloaded, decompressed and finally interpreted by the browser.

Dynamically compressing outbound files can mean an increased load on your server, but this can be avoided by compressing your JavaScript files ahead of time. Even if you don’t, the load is pretty marginal. Known browser incompatibilities can also be handled easily with the right set of rules. The upside over other compression techniques is that your JavaScript is still human-readable from your browser.

By enabling mod_deflate on Apache 2.x, I was able to reduce prototype.js 1.5.1 to roughly 23kb – about 25% of its original size. Similar modules are available for most web servers.

Alternate libraries

If you’ve decided that file size trumps all, and you’d rather not do the leg work on your own, then there’s a couple of alternate JavaScript libraries that provide slimmer versions out of the box.

JQuery is distributed with a compressed version that weighs in at 19kb. The uncompressed version is 55kb. Prototype users will find the syntax fairly similar.

Another library is mootools, a fork of Prototype that’s also distributed in compressed form. Their website also lets you pick and choose the components you need, which may result in a significantly smaller library file.

I’ve been fooling around with why’s Hackety Hack, an easy-to-use coding playground aimed at getting kids (and adults) into programming again. It accomplishes this with an embedded Ruby interpreter, a colorful easy-to-use interface, and a brilliant plain-English tutorial that focuses on getting kids up and running without wasting time on unnecessary language details. For example, here’s Hackety Hack’s explanation of Ruby’s object methods:

Commands are owned by the thing on the left-side of the dot.

This is the kind of app I wish existed back when I was a geeky 13 year old struggling to understand some book on QBasic I’d borrowed from my uncle, the family’s IT guy. Hats off to why for putting it together, and here’s hoping school computer programs take notice.

See also: why’s (poignant) guide to ruby