Matt.Tarbit.org

A blog for every occasion

Two entertaining cultural phenomena which arrived in my RSS reader one after the other:

• Ice cream people
• Laser portraits

That is all...

...no wait, stop the press! Linked to from Laser Portraits is the fantastic Sexy People.

0 comments

JavaScript line numbering for code samples

Whoopsie! While poking around on this site the other night I was horrified to discover it was pretty badly b0rked in IE. Not quite sure how I managed to miss that, but hopefully I've put it right now.

As bad luck would have it, one of the things that was broken was a javascript line-numbering function that I'd posted here previously. Best make amends with a corrected version for any readers I've lead astray, eh?

So where previously we had:

function codeLineNumbering() {
    $$('pre.code code').each(function(code){
        var count = code.innerHTML.split("\n").length - 1;
        var lines = $A($R(1,count)).join("\n");
        code.insert({before:'<pre class="line"><code>'+lines+'</code></pre>'});
    });
}

We now have:

function codeLineNumbering() {
    $$('pre.code code').each(function(code){
        var nodes = code.childNodes;
        var count = 1;
        var lines = [];
        for (var i=0; i < nodes.length; i++) {
            if (nodes[i].nodeType != 3) continue;
            var matches = nodes[i].nodeValue.match(/[\r\n]/g);
            if (matches) count += matches.length;
        }
        for (var i=1; i < count; i++) { lines.push(i); }
        code.up().insert({before:'<pre class="line"><code>'+lines.join("\n")+'</code></pre>'});
    });
}

The crux of the issue was that innerHTML seems to behave slightly differently in IE. Other browsers give you a faithful recreation of what's present in the document source, while IE gives you it's reconstituted whitespace-insensitive version.

In the old version of the code I was simply splitting innerHTML on newlines and counting how many lines I had in the resultant array. But with IE's interpretation of innerHTML that doesn't work so well since the odd newline may have been ditched or smooshed into its neighbour.

As a workaround, the substitute function uses the child nodes of the syntax-highlighted section of the document instead, which seem to be more faithful to the original source. I iterate through these looking for plain text nodes, and counting up how many newlines or carriage returns are present in each.

As a caveat I should say that I believe some of this behaviour is dependent on what your doctype and white-space CSS property are set to. Also, the code above makes the assumption that newlines will only be present in root text nodes and not nested within child elements. That's a safe assumption given the method of syntax highlighting I'm using, but it may not be for you.

Tsk, the perils of coding in public.

0 comments

A minor morsel

I haven't posted in ages, so I might as well use this to break radio silence. It's a solution to this little programming brain teaser from Dustin Diaz. I don't think it's as much of a puzzle as he seemed think, given by the responses in the comments and how long it took me, but regardless:

var listA = ['a', 'b', 'c', 'c', 'd', 'e', 'e', 'e', 'e', 'e', 'f', 'e', 'f', 'e', 'f', 'a', 'a', 'a', 'f', 'f', 'f'];
var listB = [];

var count = 0;

listA.forEach(function(val,key,arr){
    var matchPrev = (val == arr[key - 1]);
    var matchNext = (val == arr[key + 1]);

    count = matchPrev ? count+1 : 0;

    if (count == 2) {
        val = '<span>' + val;
    }
    if (count >= 2 && !matchNext) {
        val += '</span>';
    }

    listB.push(val);
});

console.log(listB.join(' '));

As some of the commenters' solutions show, it can be done in a one-line regular expression, but I was sticking to the "rules" implicit in the original post.

0 comments

Prototype, jQuery and the toggling of hidden elements

Just wanted to share a couple of little Prototype niggles. In general I'm pro-Prototype because it feels like it's a closer fit to the typical ways of working that you see in non-library-using Javascript. JQuery, on the other hand, has chaining and acts on elements using the same interfaces regardless of whether there are one or many. From the dabbling I've done, it seems like that gets you into the odd head-twisting situation, but I've yet to embark on a big project with jQuery, so judgement is reserved for now.

Having said that, here's one instance where jQuery comes out on top. Showing & hiding of elements is a pretty common JS/DOM task and you're probably familiar with an issue where hidden elements need an inline style of style="display:none;" to allow them to be shown again. This is because the un-hiding is done by setting the display property of the element to an empty string, thereby allowing the element to re-inherit it's default style. If the styling is done via CSS instead (.hide { display:none; }) then the styling is further up the inheritance chain so the element always inherits from here instead and can't be unhidden.

Prototype has the most basic show/hide implementation and makes no attempt at a work around. Its documentation even makes specific reference to the issue: "Element.show cannot display elements hidden via CSS stylesheets. Note that this is not a Prototype limitation but a consequence of how the CSS display property works".

Here's the implementation (from version 1.6; current at time of writing):

Element.Methods = {
    hide: function(element) {
        $(element).style.display = 'none';
        return element;
    },
    show: function(element) {
        $(element).style.display = '';
        return element;
    }
}

But that's not the end of the story. JQuery does manage a workaround, and an effective one at that. When failing to show a hidden element it adds a temporary, unadorned element of the appropriate type to the document and checks what its display property is set to by default. Finally, if all else fails it resorts to "block".

Here's a version of the jQuery methods, ported for use with Prototype (the originals begin at line 2890 in jquery-1.2.3.js):

Element.addMethods({
    show: function(elem){
        elem.style.display = elem.oldDisplay || '';
        if (elem.getStyle('display') == 'none') {
            var test = document.createElement(elem.tagName);
            $(document.body).insert({bottom: test});
            elem.style.display = test.getStyle('display');
            if (elem.style.display == 'none')
                elem.style.display = 'block';
            test.remove();
        }
        return elem;
    },
    hide: function(elem){
        elem.oldDisplay = elem.oldDisplay || elem.getStyle('display');
        elem.setStyle({display: 'none'});
        return elem;
    }
});

Much nicer. I'm not sure what the guiding philosophy is for what gets included and what's left out of the big JS libraries. It seems like something like this should be in there as an easy fix to a common problem. I would think that the identity of the libraries lies more in their syntax and aesthetics than their capabilities, so there's little to lose from liberal cross-pollenation.

0 comments

A new dimension in film-making

I haven't read too deeply into this, but I've seen a couple of signs lately that the movie industry might be looking to make money out of 3D (as in 3D glasses, and not specifically CGI). Disney's re-releasing the Toy Story films in 3D, Pixar is planning on releasing all it's films in 3D starting next year, and James Cameron has been doing some serious research into it for his closely-guarded upcoming blockbuster "Avatar". I wonder if this is something they're banking on to differentiate the big-screen experience from the DVD market. A return to the days when a trip to the cinema was a big event.

Not that home entertainment necessarily has to miss out, there's also the question of whether the videogame industry might be quick to make a similar move. Apparently BoomBlox (the upcoming EA / Steven Speilberg collaboration for the Wii) is to feature a head-tracking 3D mode as an easter egg. See Johnny Lee's presentation at TED for a recent demo of this technique.

2 comments

I've been reading: Pro Django: Web Development Done Right

Disclaimer: I don't actually own a paper copy of this, I'm just in the process of working through it online at djangobook.com. But while I'm at it I just wanted to jot down a few thoughts that are fresh in my mind.

I'd looked at django briefly a while back but had been slightly put off by the templating mini-language along with a few other minor quibbles. Lately though, I've been feeling the need to give it a second look. After getting some practical experience with Rails, and seeing the backlash against it play out, I've been catching recurring glimpses of django waiting in the wings and rehearsing lines for its role as understudy.

I had planned on ordering the book in the near future but just started in on the online version out of impatience. Unfortunately, it's turned out to be a relatively disappointing experience. The djangobook website looked like a pretty promising venture when it appeared. Chapters would be posted as they were written, and comments were enabled on a per-paragraph basis, setting many eyeballs to work as cheaply labouring editors and technical reviewers.

I read a couple of the first chapters as they arrived and then left it alone until now, with all chapters accounted for and the finished book finally published. I don't know what happened in the interim, presumably comments were made, some were taken into account, and the odd revision was made to the text on the basis of these. From the dates on the comments that remain, it appears that any from prior to the release of the physical book have now been cleared out leaving a blank slate alongside the finalised copy.

This is where things start to disappoint for me. The book was released late last year, and in the intervening months a respectable new crop of comments has sprouted up throughout. Unfortunately, a hefty portion of these are pointing out easily avoidable errors. Scan through the text online and wherever you find a paragraph with upwards of 4-5 comments, you'll find a legitimate complaint. There are simple typos and stylistic issues. There are problems with the over-arching structure of the book. And then there are installation showstoppers where instructions aren't working in a given environment and readers have had to Google for fixes.

Where clarity is lacking or mistakes have been made in the text the comments are invaluable. Comments that aren't available in the printed book. The book whose copy had already been finalised. The book which is already on sale.

Ok, books are published with errors. Ok, the authors are developers and not professional writers. They're just trying to take some time out of their already busy work lives for a healthy stint of product evangelization. There are excuses that can be made. But it seems to me that there is some confusion as to the distinction between the frozen in time print edition and this living breathing web edition.

Is it done now? Are we going to see further updates? Are their political issue issues because the publisher doesn't want to impair book sales with a web version that's a superior product? (Although it already seems to be by virtue of the comments alone). Where there are legitimate complaints in the comments it seems like the majority would be fairly quick and easy to fix. So what's the situation? The waters are muddied further by the presence on the website of an errata page. Presumably it's targeted at readers of the print edition but, again, without a formal statement clarifying the distinction we're left to guess.

Aside from the print/web divide there are also issues with the structure of the book in general. It doesn't feel like much thought has gone into the examples used. We start out building pages which format the time, then we build a database centered on books, then we populate one table only to try out the admin interface using another, next we create a search form for a (still empty) table before skipping off to do a contact form...

When you're trying to follow along at home it's just a little too scatter-brained for my liking. Either do a tutorial, or go with a reference, but don't sit on the fence. And either way, if you're giving code examples please try to avoid them being reliant on things that you could've easily walked us through in earlier chapters. If I can't type something in and try it out there and then it disrupts the flow of my reading and has me skimming ahead for the next example I can use.

I think the Pragmatic Programmer's AWDwR has faults of its own, but the structure of the first half of that book is good demonstration of what I'm talking about. It steps you through the majority of what you need to know using an online book store metaphor and maintaining consistency throughout, even adding in a bit of meta-story about the client-developer relationship during production. It may sound like hand-holding, but that kind of attention to detail really makes for smooth learning as you step through the code example-by-example.

The other alternative, of course, is to get out of my way and give me a reference so I can put the pieces together myself. And yes, before you mention it, I know about the documentation at djangoproject.com. Maybe that will be a better fit for me in the long run, it's just a shame to see such issues with the chosen ambassador for what's obviously a pretty cool technology.

0 comments

Bigger isn't always better

After the end of an incredible year for triple-A console titles we now find ourselves in a post-Christmas lull. There's a sour taste in our mouths from the few hopefuls who closed out the year with a rush to market in search of easy xmas dollahs (pointing no fingers). So what can be done to sweeten our palate? Well I don't know about you, but I'm seeing more and more promise in the lands of the portable, the web-based and the independent.

Let me enumerate the ways. First, three games I've played:

• Professor Layton and the Curious Village

  

  Ghibli-esque DS puzzle adventure in which Professor Layton and his boy apprentice solve the problems of the curious villagers and unravel their mysteries through a series of varied and perfectly-pitched puzzles. This thing is an instant classic, very charming and totally engaging throughout. It's also masterfully paced with each tiny piece of exposition being carefully interleaved between slices of puzzling gameplay and exploration.

  My only gripe would be that it's a shame when they set games up with sequels and franchising in mind at the start. Obviously it's a perfect fit, and it's nice to know there's more on its way, but the quality can only diminish when there's a built in formula. Hopefully this one will hold up a bit better where lesser games (Pheonix Wright?) might begin to wilt.

• ForumWarz

  

  NSFW web-based game in the form of an internet mirror-world parodying the worst of net archetypes and bad behaviour. Mechanically, gameplay takes the form of a turn-based combat RPG with character classes of Camwhore, Emo & Troll. But the outer shell feels like something new, with combat wearing the guise of forum flamewars, and NPC interaction performed via in-game IM. Its closest relative is probably Kingdom of Loathing and it sometimes brings to mind parody tabletop RPGs like Greg Costikyan's Paranoia, but the slick interface and clever matching of medium and message create something fresh. Andy Baio has just done an interview with lead developer Robin Ward.

• N+

  

  Physics-y platformer with a mean difficulty curve, previously found success online as a flash game, now ported to XBLA. It's been tarted up with additional content, multiplayer and a built-in level editor. Incredibly addictive and incredibly difficult in equal measure, it didn't take long for me to rack up the "Practice Makes Perfect" achievement for dying 1000 times. Everything about it tells you that it was made by good, honest, indie gamers. From the old school die-and-try-again play ethic to the minimal anti-glitz look and feel. One more go?

Followed by three I can only admire from afar:

• Fez

  A sprinkling of Paper Mario's dimension-twisting mixed into a smattering of Cave Story's engrishly narrated pixel-art. The 2D platformer gains a 3rd dimension when you rotate a level, only to be flattened back down into 2 dimensions when the spinning stops. Best to watch a video to understand the head-scratching gameplay potential that enables. Also has siblings in Echochrome and Crush.

• Braid

  Painterly platformer due to arrive on XBLA sometime soon. I don't know much about this one yet but the graphics look lovely and I understand there's some time-rewinding action involved a-la Prince of Persia: Sands of Time.

• AudioSurf

  Everyone seems to be talking about this one at the moment, which only makes me more eager to try it (PC only). By the looks of it, it's a block-matching puzzle set on a Wipeout-style race track with the twist being that the tracks are generated by music you play from your collection. I have to say I'm a little skeptical of this one. Vib Ribbin on the Playstation had a similar option and it was never as satisfying as the default tracks.

0 comments

I've been playing: Mass Effect (Xbox 360)

Dear oh dear. It seems to me that we're in a strange predicament at the moment. The sheer budget, visual polish and hollywood-ification of a lot of next-gen output is throwing our good/bad detectors off kilter. There's something very wrong when a game like Mass Effect sneaks into the metacritic charts alongside 90 percenters like Bioshock, The Orange Box, CoD4 and even Halo 3. Let's not beat about the bush, Mass Effect is a terrible game.

Fantastic character design, yes. Decent voice acting, yes. Pretty good writing, yes. Nice cut-scene cinematography, yes. Those things would be wonderful if this was an animated movie, but games are meant to be played, not watched. Apparently people are so blinded by the glossy visuals that they're unable to call it for what it is.

Mass Effect has the most uninspired level design I've ever seen. Most of the environments are barely designed at all. Locations look ok at first glance, but take a look at the overhead map and you'll be lucky to find yourself in anything more elaborate than a giant rectangular box room or on a snaking road taking you directly from A-to-B.

Combat would be passable if your enemies weren't often so tiny on screen that they're obscured by your equally tiny targeting reticle. So much for "the whites of their eyes". At one point, frustrated with repeated insta-kills, I went into the options and set the combat difficulty to easy, only to find the one-hit kills still in effect. Mini-games played to open item containers can barely call themselves games at all. And the over-plentiful items plundered from within are a selection of boring weapons, dull armor, or worthless upgrades. None of which have any appreciable effect on your character's handling or combat performance.

Many UI decisions are simply mind-boggling. Your team's health is represented by 3 small red bars in the lower left of your screen. If a team mate is damaged, but regenerating, their bar turns green. So red is sometimes good, sometimes bad, and green is... what, exactly? Good luck figuring it out at a glance.

The colour contrariness is also carried through to the inventory screen where you can compare your currently equipped items against those you've picked up. Here, the compared item's statistics are shown as green if identical, red if worse and yellowy green if better. But there's no grading of these colours, so an item that's slightly worse in one area, but much better in another shows up as having one stark bright red bar and one barely perceptible yellowy green bar.

The ineptitudes pervade almost every aspect of this game, and I stumbled across a blog post a while back that did a fantastic job of dissecting each horrible misstep in turn but I'm having trouble digging it back up. So for now, I'll have to leave you with the above cautionary morsels and hope you see fit to take the mainstream reviews with a generous hunk of rock salt.

1 comment

Extending BlueCloth with Pygments

I just spent a fun couple of days tinkering with the engine of this site and have finally emerged bruised, tired and slathered in axle grease.

I started out just adding syntax highlighting but ended up adding page caching (to offset the performance hit of parsing code), and upgrading to Rails 2 (to get at a couple of caching related niceties). So due to all the change there may be the odd unresolved issue here or there that I've missed. Just drop me a comment if you spot anything poking out at an awkward angle.

I figured I'd inaugurate my code highlighting with a little write-up of how I ended up doing it. I originally planned to use Ultraviolet, but found it way too slow and a bit verbose in the CSS-naming department among other things. I also looked at various JS highlighters, but couldn't find one to suit, and decided it's a fairly resource intensive task to be off-loading onto the client anyway. Then I finally came back around to what I'd been looking at originally, which was the excellent Python library, Pygments. I was put off at first by it not being ruby-native, and wondered if I'd need something like RuPy to bridge the gap. In the end I decided it'd be acceptable to do a system call out to the pygmentize command line interface:

class BlueCloth

  def escape_shell_arg(str)
    "'%s'" % str.gsub("'","'\\\\''")
  end

  def transform_code_blocks(str, rs)
    @log.debug " Transforming code blocks"

    str.gsub(CodeBlockRegexp) {|block|
      code,rest = $1,$2

      # Remove the syntax line and extract the language from it
      regx = /(?:[ ]{4}|\t)+@@(.*)\n+/
      lang = code.slice!(regx).slice(regx,1)
      # Call out to pygmentize to markup the code for highlighting
      code = `echo #{escape_shell_arg(code)} | pygmentize -f html -l #{escape_shell_arg(lang)}`
      # Remove the extraneous wrapper markup that we don't need
      code.sub!(/<div class="highlight"><pre>(.*)<\/pre><\/div>/m, '\1')

      # Generate the codeblock
      %{\n\n<pre class="code"><code>%s\n</code></pre>\n\n%s} % [ outdent(code).rstrip, rest ]
    }
  end

end

As you can probably see, I'm using BlueCloth to format my posts, so I'm over-riding the method it calls to deal with indented code blocks. Doesn't provide any more graceful hooks unfortunately. I've also added an @@language line inspired by an article at Warpspire so that Pygments doesn't have to play the language guessing game. In fact, if you're using a JS highlighter and that's all you need, you can get away with something like this:

class BlueCloth

  alias old_transform_code_blocks transform_code_blocks

  def transform_code_blocks(str, rs)
    str = old_transform_code_blocks(str, rs)
    str.gsub!(/<code>@@(.*)\n+/, '<code class="\1">')
    return str
  end

end

Aliasing the existing handler method to another name so that we can write a wrapper for it rather than over-writing it completely.

Probably bears repeating that the first option isn't the speediest thing in the world, and might be best avoided unless you're prepared to implement some sort of caching. I should also mention that I finished putting this in place and then immediately found mention elsewhere of CodeRay, which is a self-professed "fast" Ruby-native highlighter. I haven't tried it out yet but it looks fairly young and recommends Pygments itself right there on the front page anyway. Worth a look though.

Oh, one last thing. I've used javascript (and Prototype) for my line-numbering so it doesn't get in the way in the source and stays out of CSS-unfriendly formats like RSS:

function codeLineNumbering() {
    $$('pre.code code').each(function(code){
        var count = code.innerHTML.split("\n").length - 1;
        var lines = $A($R(1,count)).join("\n");
        code.insert({before:'<pre class="line"><code>'+lines+'</code></pre>'});
    });
}

Short and sweet!

Update: Seems I was a little hasty with that line numbering function, here's a version that should also work in IE.

2 comments

I've been playing: Bioshock (Xbox 360)

I put off getting this after downloading the demo from live and having a bad experience with it. If I remember correctly, they'd added a security camera into a room in the demo where there isn't one in the final game, presumably to show off some of the extra interactions it brings. Unfortunately the room it was added to was largely lit in red making it hard to spot its field of vision. Consequently I found myself overwhelmed by multiple splicers and security bots at once, which is not something which suits my style of play. But what I found on making my way deeper into the game proper was that getting overwhelmed is all part of the fun.

What Bioshock introduces into the standard FPS recipe is a twist on the usual combat model. My normal approach would be to edge through levels an inch at a time picking off enemies one by one, safe in the knowledge that nothing is going to creep up behind me. In Rapture that's not quite so effective. Enemies crawl out of walls, wander the corridors, and will think nothing of chasing you from room to room. The environments tend to be broad and intertwined rather than long and linear, and the route you take through them is rarely enforced.

But the most colour is added by the variety of ways in which any problem can be attacked. For any one entity in rapture there are a multitude of ways of dealing with it and turning it to your advantage (in contrast to the average FPS where there are things to kill and things to pick up, and not much more to speak of). It's dizzying just to list what's on offer:

• Enemies which attack only when provoked, or which can be made to attack each other, or which can be made to protect you.
• Weapons which can be upgraded and which take several types of ammo, some of which can be made by collecting materials.
• "Plasmids" which are effectively magical powers which add even more complexity to the interactions.
• "Tonics" which are effectively skills or physical enhancements.
• Security cameras, bots and turrets all of which can be hacked to protect you or destroyed for pick-ups.
• Vending machines and health stations which can also be hacked for price reductions or destroyed for pick-ups.
• The hacking itself which is performed via a pipe-mania style puzzle game but which can be circumvented with auto-hack tools or bought out.
• Researching enemies by taking their photograph for various bonuses.
• Environmental hazards like oil which can be set on fire and water which can be electrified.

If you multiply everything together to find the number of available combinations implicit in that list you'll find that it yields a pretty impressive realm of possibility. Which leads to the fun in being overwhelmed which I mentioned earlier, sparking some of these interactions and standing back to see what happens can be pretty entertaining.

There are some odd bugs and some iffy UI decisions, and there's the failure of nerve in the final portion of the game that's been discussed elsewhere. But take the web of interactions I've talked about above and add to this some beautiful graphics, a great storyline, fantastic voice acting (spoilers) and you end up with a really great game, deservedly topping the metacritic charts. There's also enough tiny little fun scripted moments and bits modelled into the environment to show that the development team were enjoying themselves too. Something which always puts the cherry on the cake for me.

0 comments

Colophonic Irrigation

In the interests of transparency, and because I've been a sucker for them ever since I first stumbled across one in the back of an Oreilly book, I've added a colophon to my about page.

It's also largely due to Mr. Willison putting the idea in my head this morning. He even advocates stuff when he's not intending too, the poor fellow!

2 comments

I've been playing: Fahrenheit (Xbox)

A rough diamond that I missed out on the first time around, given a second lease of life by the Xbox Originals download service on the 360.

It's a right little charmer filled with fun little bits of innovation and some obvious loving care from the developers. The driving plot doesn't take itself too seriously (although yes, it gets downright silly in places, throwing in every supernatural plot device it can think of), and the incredibly simple control scheme gets out of the way of the gameplay allowing it to be fairly freeform and unformulaic. It even makes a little bit of headway into the idealistic territory of "interactive cinema" that the developers were obviously striving towards.

There are definitely aspects that don't work so well; the much-maligned QTE sequences, the always terrible semi-fixed cameras, and the afore-mentioned farcical plot twists. But for every silly mistake there's a wonderful success. Not least of which is the ability to play multiple characters off against each other, and the mental state health bar which has you caring for your characters' well-being.

There's also a couple of firsts for gaming maturity by my reckoning: first non-camp gay character? first non-puerile (though slightly gratuitous) nudity?

I could go on about all of the above way more than would be seemly, but for now let's just finish by saying that Fahrenheit is a super fun game that you should have no hesitation in trying. My curiosity is piqued for Quantic Dream's upcoming Heavy Rain now, even if the teaser did sport the uncanniest valley I've ever seen.

p.s. I totally didn't realise it at the time, but it looks like I may have subconsciously stolen my blog's colour scheme from the old-style xbox boxes. Oops?

1 comment

Deploying Web Frameworks

There was a lot of chitter-chatter this last week about the new web frameworks and the situation with regard to their performance and ease of deployment in shared hosting environments:

• A Dreamhost employee bemoans the lack of support for shared hosting in Rails.
• David Heinemeier Hansson responds with his standard "scratch your own itch" riposte.
• Alex Payne chips in with the view that shared hosts are toy environments anyway.
• James Bennett points out that this is indicative of a broader issue which also affects Django and the like.
• GNU VInce adds some particulars about Django's deployment situation. He also hints at the problem of game-changing technologies making it difficult for n00bs to climb aboard.

I've been waiting for a while for the hype to die down so we could have a sensible conversation about all of this. It seems to me that the vast majority of the Rails naysaying has been hinged on a misguided comparison between it and PHP, and complaints about it's performance. There's clearly an issue there, but the issue doesn't seem to me to be with Rails in particular. The "it's hard" and "it's slow" complaints both seem to be missing the fact that Rails, Django et al are solving a much larger problem than PHP.

The new web-development technologies are insta-frameworks, they come with all your professionalism and all your infrastructure in place from the outset. And the necessary baggage of memory overhead and complexity come along for the ride. The old familiars that we've been used to; PHP, Perl and the like come from the direction of shell-scripting-land where the most common case is the most basic. There are 100 hello worlds for every 1 webapp with all mod-cons. In contrast, the new web frameworks have the giants of Java-land in their sights. They say: we expect you to use url-rewriting, ORM, granular caching, TDD, asset servers etc. They'll make it as easy as humanly possible to do so, but as part of the bargain they'll expect you to step up and fulfill your side of the contract as a modern web professional.

And therein lies the crux of the problem I think. The new web frameworks shine a harsh critical light on the yawning gap between how we all started out and where we all should be. It seems like the majority of "I tried it, I didn't like it" stories are from people who burnt their tongue on the first taste and realised their skills weren't up to it. And the cries of "deployment! performance!" are from those who are aghast that they should understand anything about the servers and environments their apps are running in.

When a framework solves all the problems you were familiar with, it's humbling to find that the problems you're left with are those you know the least about.

Yes, there's more to it than that and there is the odd complaint that's valid and well considered. There's certainly room for improvement, but these technologies are very, very young. If we can just support new ideas, give them a little breathing room, help investigate the new bottlenecks and understand that no technology can be all things to all men, then we might just see some progress.

0 comments