We build innovative web based applications

I've heard mentioned a few times recently how "RSS is dead" during interviews/articles with prominent bloggers.

We can not let RSS die!

RSS is too awesome!

Since Google Reader shut down, there have been a number of RSS readers and apps that have rushed to fill the void, but they're all completely shithouse compared with Google Reader and/or they cost money.

All, that is, except for one shining beacon of light in the darkness ...

TINY TINY RSS READER

The only problem is that it looks so daunting to everyone except developers but before we address that little issue, here's what's great about it:

• It's self hosted: your RSS reader will never go away again and if you don't want to pay for it you can install it on an existing server, or just a spare PC at home if you want (although you'd need to forward a port on your router so you can access it from the mobile app). Even if you don't have a spare server to put it on it will take up virtually no resources so you can get a minimal VPS hosting account somewhere that will be cheap as chips.
• It supports multiple users: get together with a couple of pals and split the cost of hosting your own TTRSS instance.
• It has a great mobile app: the official Android client UI is simple just like Reader, and the workflow for managing your feeds and articles is super simple. There's also a number of alternative apps provided by the community for both Android and iOS. Take your pick!
• You can add it as a feed reader in Firefox and Chrome: so you can easily subscribe to new blogs as you browse
• It's got a tonne of features: you can categorise your feeds, star articles and do lots of little tweaks to get it working just how you like it

Sound good?

Let's see how to get started using Tiny Tiny RSS.

Step 1: Setup a TTRSS server

The first thing you need to do is setup your own Tiny Tiny RSS server. Here is the installation guide:

http://tt-rss.org/redmine/projects/tt-rss/wiki/InstallationNotes

If you're not a developer, or systems administrator, you might find that document really daunting, or you may just not have the time to learn how to do it.

In that case, you can take advantage of the fact that the good folks at Bitnami have setup an "appliance" for TTRSS!

https://bitnami.com/stack/tiny-tiny-rss/cloud

So they've done all the hard work for you.

Step 2: Setup your user account and add feeds

As per the TTRSS installation instructions, login with the default credentials then go to preferences in the top right to add a new non-admin user:

You will login using your non-admin username/password when you download the mobile app later.

You can then add TTRSS as a feed reader in Firefox and you can do the same in Google Chrome (and probably other browsers).

You can import your feeds using OPML format if you want. I didn't bother, I just went and subscribed to a bunch of sites I liked. I rotate my feeds pretty frequently anyway based on how much I like the content, and continually update/add new ones.

Step 3: Grab the mobile app for your platform of choice

I use the official Android client and I love it:

http://tt-rss.org/redmine/projects/tt-rss-android/wiki/

But my wife uses this one for iOS:

https://itunes.apple.com/au/app/tiny-reader-rss/id689519762?mt=8

There are a few others out there, so you can try them to see what you like or what works best for you.

Google READER is dead, RSS is alive and well

I love RSS so much. Subscribing to a million email newsletters is way less efficient. I want to subscribe to an RSS feed to get a feel for someone's blog before I subscribe to their email list. Even then, I'm way more likely to unsubscribe from emails than I am from RSS. My inbox is sacred, my RSS feed is way less cluttered.

If you read the above and it all sounds like too much work, I have a deal for you:

I will setup your Tiny Tiny RSS service on Bitnami and take you through how to use it for just AUD$49. Just fill out the form below to get started:

Although not all PHP frameworks are "Rails clones", the history of modern PHP frameworks really begins with the rise in popularity of Ruby on Rails.

Until Rails started to gain serious mindshare amongst developers and market share amongst consulting clients, no-one was really talking about using MVC patterns in PHP applications.

If you look at the list of frameworks on http://www.phpframeworks.com/ (which is pretty old) you find that PRADO was the only framework that was released before Rails became popular (it was released about the same time as Rails), and one of the only ones that doesn't cite Rails specifically as an inspiration[1].

Most importantly, Rails brought a term into the web vernacular in a big way and that was "MVC".

Even though Java's Spring MVC framework was released well before Rails You can see that the release of Rails had an impact on the popularity of people looking for "spring mvc":

The appeal of index.php

The core idea of a web developmernt framework is to improve developer productivity by:

• Automating or simplifying repetitive tasks, making them both faster and less error prone
• Making it easier for multiple developers to collaborate on the same project

Every PHP framework I've ever come across includes in it the main "entry point" for the application, usually called index.php or something similar.

The PHP framework zeitgeist was very heavily influenced by the Rails MVC and ORM models and implementing this without a central "application entry point" seems clunky.

You don't want to "spoil the illusion" that we're working in a purely object orientated environment by exposing the developer to some procedural application entry point (this could well be Java's influence, which took the C language's "main" function and hid it from the developer altogether).

I know this in part because I fell victim to the same thinking.

"Projects which were, according to the collective wisdom of the time, terribly written "spaghetti code" were in fact the easiest to understand, fix and modify."

I had been working on some framework-like ideas and when Rails was released a lot of these ideas were included in my own framework called RocketSled.

The first versions of RocketSled were a hideous, monolithic beast that never gained any traction with anyone except me.

Following the development of a few larger web applications I started to re-think how I wanted to structure my code.

One of the biggest realisations I had was that making PHP application structures more "standardised" was not succeeding in creating something on which it was easier for a range of different developers to collaborate.

The more I started working with other people's code, maintaining existing projects, fixing problems on websites that had been abandoned by other developers and working with frameworks I had not written myself, I realised that the more cleverly written an application was, the higher the barrier of entry for me to understand it so I could fix bugs or make changes.

Projects which were, according to the collective wisdom of the time, terribly written "spaghetti code" were in fact the easiest to understand, fix and modify.

Around the same time, I started lurking in #stackvm on freenode and looking at the way James Halliday (aka Substack) and Peteris Krumins were writing their software using "very small modules" and began thinking about how I could strip everything away from RocketSled and what a truly minimalist PHP "framework" would look like.

Here's a rough bullet list of what I wanted to achieve:

• I wanted a framework that did almost nothing: no templating, no URL structure, minimal routing, no package management; all this stuff should be the job of "userland" packages so you can pick and choose what you wish to use easily at any time in a project's lifecycle
• Whatever it did do, should be completely optional. You should be able to override whatever default behaviour is provided "out of the box" as and when it becomes convenient to do so; if some feature of the framework stops being a help and starts being a hindrance, you should just be able to leave it behind and do something else
• You should be able to hack things together however you want in order to get the job done (arguably one of the core philosophies of PHP as a language)
• I wanted to have a system for installing little modules (similar to Node's npm)
• I wanted to make use of the __autoload feature (PHPs strongest feature IMHO[2])
• I wanted to make it simple to use the huge body of PHP code already written, without having to modify it to fit in with the framework
• I didn't want the code that I wrote to be tied to any framework

I had already banished the concept of using a templating engine in favour of Template Animation so any benefits that existing frameworks had to offer around structuring views or providing a "separation of concerns" between business and display logic were a non-issue.

As I toyed around with this concept I started writing the first versions of the newly stripped back RocketSled, and a package manager called RocketPack which would install code from git repositories and manage dependencies.

Source code management: the thorn in my side

I wanted to be able to install the framework code and leave it completely unmodified, then have all my code, configuration etc. happen in "userland" packages which would have their own source control repositories (I use git but whichever SCM tool you use the principle is the same).

This inevitably lead to all sorts of directory scanning to find configuration files and various code location configuration options so that I didn't have to alter the RocketSled code once it was installed.

In order to resolve this issue, I started coming up with a directory schema and configuration "injection" system, but I couldn't seem to come up with anything that just didn't feel like a rehashing of the same old "directory structure dictatorships" common to every other PHP framework in existence.

Nothing I came up with truly addressed my goals of having something that was essentially invisible, essentially meaningless and essentially not a framework.

"Once you take away package management, templating and routing (all of which I wanted to be the responsibility of interchangeable userland packages) what does a framework really do anyway?"

Before Rails, there really wasn't a way to write web applications in Ruby. Before Django, there really wasn't a way to write web applications in Python.

That's when I realised that what others had been saying for so long is true: that PHP is a framework.

Why was I so hell bent on having an "index.php" as part of a PHP framework rather than as part of the application code for the project I was building? Why did my "framework" have to provide the main application entry point?

Rails and Django only did for Ruby and Python what PHP had already done for itself, but the structure of those frameworks made the PHP community jealous. Everything looked so well organised and clearly documented. PHP raced to catch up; raced to be as MVC as Rails.

When I examined the applications we'd built with this new version of RocketSled the config files that were contained within each package were just arbitrarily formatted PHP files, and I'm a huge fan of PHP as a configuration language in PHP projects (rather than having configs written in JSON or YAML or XML or whatever). The configuration files were all pretty minimal, and were just chunks of "procedural" code to define constants or include required files (such as autoloaders for other packages).

Whilst I was trying to come up with some clever way to prevent the developer from ever having to touch the YUCKY and PROCEDURAL index.php file with a weird concoction of directory schemas and configuration injection points and directory scanning, I could much more easily just create tools that did some stuff that I found repetitive and define a simple way to use them from any application (ie. from an "index.php" not under the control of the "framework" itself).

Once you take away package management, templating and routing (all of which I wanted to be the responsibility of interchangeable userland packages) what does a framework really do anyway[3]?

So I refactored RocketSled into what it is today: a non-framework tool for managing your autoloading class paths in a way that's completely override-able by anyone who chooses to use it and that doesn't interfere with the way that any other class loaders you might wish to use already work.

Unfettered by the shackles of my "index.php" rewriting RocketPack to be a standalone package management tool for git repositories became a triviality.

I then came up with a basic "boilerplate" for using RocketSled with RocketPack and put that into it's own repository at https://github.com/iaindooley/RocketSledBoilerPlate.

The key here is that RocketSled and RocketPack themselves are completely independent of the methodology used in RocketSledBoilerPlate. You could come up with your own RocketSledBoilerPlate. I can change my mind later on pretty easily: none of the code I've written has any dependency on this way of doing things.

If I want to use a PHP package that already exists, I just have to include the autoloader/bootstrap file provided by that package. I don't have to worry about changing that package to fit in with my framework at all.

The workflow we follow now is:

1. Clone the boilerplate
2. Create a new repository using these files
3. Modify the code as required

One could argue that I have broken my original rule of "not modifying the framework" code, but the code contained within the RocketSledBoilerPlate project is so minimal that I don't really see this as an issue.

[1] Symfony is another but you can find empirically that there was a big influence on Symfony from the rise in popularity of Rails [take me back to where I was]

[2] I'm obviously not the only one who thinks so, either. Check out this fantastic article from the team behind Propel: http://propelorm.org/blog/2011/03/21/the-end-of-autoloading.html [take me back to where I was]

[3] I think there is a common move towards this non-monolithic style of framework. For examples, check out this post by Fabien Potencier on what Symfony2 is: http://fabien.potencier.org/article/49/what-is-symfony2 and this fantastic talk by Kenneth Reitz "Flasky Goodness (or why Django Sucks)" http://www.youtube.com/watch?v=U2frH932U1g [take me back to where I was]

This is a response to Rand Fishkin's blog post "24 things I know now that I wish I knew then" which is itself a response to Rae Hoffman's "Entrepreneurial Lessons: 48 Things I Know Now That I Wish I Knew Then"

1. "Premature optimisation" applies to nearly everything (automation, scale, others?). The famous Paul Graham adage "Do things that don't cale" is the same advice as "premature optimisation is the root of all evil". Think about it.
2. No one cares what you do - they will all forget your embarrassing marketing gaffs or shitty 1st version of your software. Ship and self-promote fearlessly. You'll learn along the way how you should actually do it.
3. Your business will take at least 5 years to do anything interesting.
4. Don't pay attention to the tech press (and MOST OF ALL the "valuations and funding" press)
5. You don't have to move as fast as you think you do (this is a lift from Mike McDermot, CEO Freshbooks from this post)
6. Play life like a game of chess: look at the situation as it is now and ignore what you had planned up until this point (I learned this one by playing lots of games of chess simultaneously to the point that I was unable to remember individual game plans so I had to assess each board as it lay - very powerful stuff)
7. Value your family and your friendships - celebrate what's amazing every day in your life and use it to give you perspective (and help keep you from the "deferred living" trap)
8. Not everyone gets rich in their early 20s and you won't feel any less fantastic if you manage to "succeed" at any time in your life.
9. VC funding works in a really specific set of circumstances and results in acqui-hires most of the time: it's NOT like being given money.
10. You don't need funding yet.
11. Your first business should not be a heavy technical investment even if you are a coder.
12. Become profitable at anything that doesn't take up all your time, rinse, repeat.
13. Don't invest in product, invest in outcomes.
14. Don't write your own software, even if you're a coder, unless you want to go down the VC/YC acqui-hire route.
15. The only thing that matters in a new business is sales. All activity should stem from that: marketing, customer service, development.
16. The market is huge, and you can compete. There isn't only one dry cleaner in New York.
17. First mover advantage is almost always bullshit.
18. Frugality creates opportunity. Just because you're planning on being rich, doesn't mean you can spend like you already are.

There has been spirited debate on Hacker News this morning following Jeff Atwood's post "Please don't learn to code".

Let me start by saying that fundamentally I agree with Jeff - the whole "everyone must code" and comparing creating software with literacy and numeracy meme is pretty ridiculous. I don't begrudge anyone their right to a hobby, though so if the Mayor of N.Y is keen to learn to code, good on him.

I would like to add a word into this debate, though, and that word is automation. Computers are fantastic communication tools and that is one of the primary purposes for which they are used today.

They are also fantastic tools for automation, and I think this is where the shift to GUIs really left a lot of the utility that existed in early computing behind. Yes, I realise that GUI platforms generally have automation tools associated with them but automating a GUI task is kind of less precise and, in my opinion, a little more confusing that automating command line tasks.

I think that every man, woman and child who uses a computer should be taught the concepts and basics behind using their computer for automating tasks.

There are a plethora of options for educating people in this area and I don't think that [INSERT PROGRAMMING LANGUAGE HERE] is the best place to start.

In fact I'll even go so far as to say that I think every man, woman and child who uses a computer should learn about the command line as well (I realise that the utility of the command line varies by operating system but I wouldn't be averse to a Linux/UNIX variant being used as an educational tool - the concepts are all the same no matter where you go).

From there, people can go on to coding if they wish, or they can improve their productivity at work through automation, or they can create a script to manage their photos or music, or whatever they want. Once people get a taste of automation, they really start to go hog wild with it so the computer is their proverbial oyster.

So in conclusion I'd just like to say that yes, I agree with Jeff that the "everyone should code" meme is bullshit, but I also agree with the notion that everyone should learn to do more with their computer than just passively use software, and that we should call it automation, not coding.

This is an unpaid and unsolicited editorial piece. I don't have any affiliate links or agreements with Andrew, I'm just a very happy member of Mixergy Premium, and I see this as a way of providing value for my own audience.

If you're not already familiar with it, Mixergy.com is a website where Andrew Warner interviews successful business people to learn and share the secrets to their success.

Since the interviews are free and life isn't, Andrew monetises the site in 2 ways:

1. At the start of each free interview he has 3 paid advertorial announcements
2. He sells a premium subscription service that gives you access to special content

Plenty of people listen to the free interviews, but let's look at why you should go with Mixergy Premium.

The difference between the free interviews and the premium content

Although the free interviews actually quite often contain specific tactical and strategic advice, they are largely focused on a narrative discussion of each interview subject's journey.

Whilst you quite often pick up a gem and generally gain a "business mindset" almost osmotically by simply listening to enough interviews, the free interviews do not have a strong focus on providing instantly actionable steps to improve your business.

In contrast, the courses you gain access to as part of your Mixergy Premium subscription are each an entire hour with a singular focus. Examples of some course topics are:

• Profitable ad buying
• Effective outsourcing
• Copywriting
• PR
• Customer acquisition

The list goes on. All the courses are taught by people who have successfully applied the material in their own businesses.

It should also be noted that with a premium subscription you also get access to all the back catalog of interviews Andrew has ever done on the site (they only stay free for 7 days) so for example if you wanted to see this interview with Kevin Hale from Wufoo, you'd have to go premium.

Is it good value?

In order to determine if Mixergy Premium is good value, you first have to look at the cost and then your return on investment. Fortunately, Mixergy Premium only costs $200 for the year.

Yes, that's right, $200 for one year.

So here are a list of ways you can get a return to cover your investment:

• Drink 6 fewer cups of coffee each month
• Drink 1 less six pack of beer each month
• Don't super size every 3rd takeout meal
• Drink tap water instead of bottled water 6 days a month
• Ask someone in the street for $2 each day. If only 27% of people say yes you'll have made your money back (that's about one person every 4th day)
• Walk your neighbour's dog for $5/week
• Mow your neighbour's lawn for $10/fortnight
• Send 2 fewer text messages per day

Whatever, you get the picture. This is a slightly facetious list but the point is: where is the fucking risk?!

To top it all off, Andrew offers a 100% no questions asked money back guarantee. So the short answer is that there is no risk.

Okay it's inexpensive but is the advice valuable

Yes.

Here is my Mixergy 101 course list:

1. Juan Martitegui's business blueprint
2. Brian Kaldenberg's customer acquisition
3. Dane Maxwell's copywriting
4. Derek Halpern's advanced lead generation

There are a crapload of other courses and more niche content but as a basis to help you get some value immediately, those are the first 4 I would listen to, and in that order.

I can personally report that, using nothing more than the strategies and tactics presented in those courses, I found a niche, conducted an ad campaign, built a landing page with copy that converted, got my first lead and signed up a customer.

And you know how I pitched them? I just laid out all the info from those courses and said "This is what I can do for your business".

What are you still doing here!? Go and sign up for Mixergy Premium now!

Sorry if this is a little "off topic" for this blog but I was really inspired by this recent (and wildly successful) experiment by Louis C.K in independent release of artist work.

My father, Nick Dooley has been performing as a street musician for a long time and this seemed very similar in concept to street performance, or "busking" as it's called.

I saw a lot of talk in the blogosphere in the following days/weeks after Louis released his video encouraging other independent artists to do the same, but also a lot of speculation that this is only a way for people who are already famous to successfully release work.

In order to test whether or not this would work for the millions of independent artists out there I thought I'd put up a landing page for my Dad with some tracks for download and a PayPal button to see what happened.

So without further ado, I give you Nick Dooley's Virtual Guitar Case

I'd love to hear what you think - feel free to email me on iain@workingsoftware.com.au

PS: I also registered the domain http://www.mp3busking.com/ - if you think this is a good idea and you'd like to have your own work listed on a publicly available directory let me know and I'll put something together.

Templating is a real hot button in the web development community. The only other topic I can think of more prone to sanctimony and religous flame wars is quality control and testing.

The high horses that people usually get on are that all too familiar TLA MVC (Model/View/Controller) architecture and "separation of presentation and business logic".

The poor pedestrians upon which they look down are those who have written "spaghetti code" - templates where presentation logic, markup, business logic, database access configuration and whatever else you might imagine are mixed up in the same file.

Well, I've got some news for you: you're all wrong.

What is spaghetti code anyway?

Spaghetti code is a really old term dating back to the days of goto statements and the transition from unstructured to structured programming languages.

There's not really one true definition and it's meaning has evolved over time but the common thread is that it refers to code where things are mixed together that shouldn't be, the result being difficult to understand if you didn't write the application (and sometimes even if you did).

In the world of web development, the term most often refers to the inclusion of both business and presentation logic in the same file as your HTML (and javascript and css or whatever else you have on your page).

A typical example written in PHP would look like this:

Why all templating sucks

This is where folks will start to get technical about why their code isn't spaghetti code.

Oh no! Not me because I use (Django|Rails|Haskell|Node.js|Symfony|CakePHP|Tornado|Plone) and the superior templating language (Django Template|ERB|Mustache|PHP|TAL|Smarty) doesn't allow business logic in templates and enforces a separation of concerns

You, the reader, December 2011

The problem is that in every single one of these circumstances, the templating engine has 2 primary responsibilities:

• The fragmentification and inclusion of common interface assets (to avoid duplication and maintaining the same code in multiple files) - eg. headers, footers, sidebars and the like
• The output of dynamic content

The output of dynamic content requires logic (if/else, loops being about the bare minimum).

The creators of templating languages have, to varying degress, availed themselves of a false dichotomy, namely that there exists "presentation" logic and "business" logic, the former of which belongs in templates and the latter of which has absolutely no place in templates and must be banished immediately.

I say false dichotomy because this is an arbitrary separation - a choice made by the person who created the templating engine and is completely subjective.

Even Mustache, which boasts to be "logic-less templates" is guilty of having some logic in their templates. After all, if I have a construct that performs logic, even if that logic doesn't look like logic, isn't it still logic? To take the demo on their home page:

See that last line that says "#empty"? In the demo you modify some JSON and render the template and it suggests "Try setting empty to true". Low and behold IF you set empty to TRUE, THEN the paragraph tag indicating that the list is empty is rendered. However IF you set empty to FALSE, THEN the paragraph tag indicating that the list is empty is not rendered.

So basically I call bullshit on Mustache being "logic-less". It may have the most ruthless attitude to excluding "business" logic (whatever the hell that is) from the templates but there's logic in there, to be sure, even if they're trying really really hard to make it look like there isn't.

It's all spaghetti code

So I'd like to proffer that all templating languages produce spaghetti code.

Surely not, because that Mustache template was heaps easier to read than the PHP example you gave at the beginning of this article

You, the reader, 2 minutes later, December 2011

Well let me hit you with this: although there are varying degrees of entanglement and obfuscation, and certainly one person might write more readable, maintainable spaghetti code than another person, that doesn't change the fact that it's still spaghetti.

I would like to formalise a new and more ruthless definition of spaghetti code:

As soon as I'm looking at more than one programming or markup language in the same file, I'm looking at spaghetti code.

Iain Dooley, December 2011

This issue was been popularly addressed in JavaScript for quite some time. The first time I recall seeing the concept of banishing things like onclick attributes from markup was when I first read about the Behaviour.js library and the whole thing just seemed incredibly sensible to me. Why is it that we still accept the equivalent in our server side templating engines?

The holy grail: Template Animation

So long as I'm updating the definition of spaghetti code, I might as well coin a new term while I'm at it:

Template animation: the practice of using static HTML files as a resource from within your application to be manipulated via the DOM to generate dynamic output.

Iain Dooley, December 2011

Instead of splitting up the task of templating in the following, arbitrary fashion:

We can create a non-arbitrary, completely objective separation where the view/template layer truly contains no logic what so ever:

When I first had this idea, it was because David Grinton and I had actually created a little PHP script for doing Django style template inheritance in XML.

It was a very short mental walk to realise that, with a system in place that was responsible solely for fragmentification of documents and re-use of common assets capable of returning head-to-foot complete HTML files, all the backend programmer has to do is load the file and manipulate it using the DOM to output the required response.

Whilst the impetus for this was the fact that we'd created a tool for fragmentification of XML documents, it really doesn't matter what the frontend developer uses.

Even Dreamweaver is capable of allowing a frontend developer to re-use common view components and it has no impact what-so-ever on the application layer so long as the server side developer is presented with a complete document to work with.

I created a little proof of concept which you can see in this class file just done using raw DOM functions in PHP.

Since DOM manipulation totally sucks I went looking for a jQuery port to PHP and found phpQuery and queryTemplates by the same author (neither of which appear to be being actively maintained), as well as HTML::Zoom for Perl on CPAN.

What are the advantages?

Dramatically simpler resourcing and training (in-house or outsourced teams)

The single biggest advantage here is simplicity of resourcing and separation of skills. To illustrate this let's look at a counter example.

Recently, Luke Wroblewski posted his notes from the "Design for Continuous Deployment" presentation by Randy Hunt from Etsy. From the article:

The company has 140 people working on the product (design & engineering) and they are all pushing production code between 50-60 times a day.

In the section entitled "How do you do it?" the two key points are:

• Everyone at Etsy has a development environment on their machine. All the designers have local environments to do design work on GUIs.
• Quick start guides and packages are created for designers to bring them up to speed on how the process works.

This is emblematic of the problem in traditional templating engines/development frameworks, and it's fine if you have a design and engineering department, a profitable business and time for designers to get "up to speed on how the process works" by reading guides and packages (as well as the time to develop those resources in the first place) but ultimately this is not a solution for smaller, scrappier teams with less time and money on their hands.

The fact that Etsy even had to discuss this as a feat of engineering achievement shows just how big of a problem it is, and changing the way we approach templating solves this problem completely.

By defining an application first as a series of static, clickable HTML mockups and then passing these off to developers who "animate" them, you obviate the need for designers to be exposed to things like local development environments or logic of any kind.

You also create non-blocking workflows between designers and developers. Nothing a developer can do will ever break what the designer is working on. The designer will never have to wait for a piece of backend code to be written in order to design a new feature or refine an existing one.

Certain strategies can be used such as not changing ids and classes so that these "hooks" remain constant and you break the application less when changing it, but regardless of this, a breakage due to a change in the markup is solely a coder's problem. It's something that automated testing or even basic user acceptance testing will isolate quickly and which one person (ie. the developer) can fix on their own without the need for costly communication between the people working on the front and the backend.

I'll stake my reputation (whatever that's worth) on the fact that any "brittleness" introduced on the developer's side of the equation as a result of having to target specific pieces of markup can a) be reduced to an extent by not changing classes and ids too frequently and b) will be far less costly than the traditional headfuck involved with designers having to have a local copy of the entire application running in order to iterate on your application's interfaces.

Even as a single person on a project you'll find it easier to iterate and easier to find someone else to work on it if you want to at some point.

Dramatic reduction of technical debt on any project and any platform

Technical debt manifests itself most frequently in the inability to iterate quickly and keep your product current. This reduces your ability to compete and thusly your effectiveness as a business.

This approach to templating basically eradicates the biggest source of technical debt: having your interface tied inextricably to your codebase.

It is a simple fact of programming on the web that HTML(4/5/X whatever), CSS and JavaScript are present in every technology stack.

By prototyping your entire application in static HTML, CSS and JavaScript, you isolate the most valuable part of your application (the feature set and user experience) from the means with which it is implemented (or "animated").

The beauty of this approach is really that it doesn't matter at all what you use on the backend: or even that you are consistent, or that you start with the same approach you continue on with later, or that everyone uses the same coding standards or whatever.

If you're not happy with the code that's driving your application, just pick up and go somewhere else. I'm not saying this is free mind you, but it would be a hell of a lot easier to take a complete, static HTML prototype that was written with a PHP backend using Template Animation and reimplement it whatever-the-hell-language-is-trendy-these-days (or what language is easiest to find talented developers to work on). In other words: you can stick your language wars, I don't give a shit what it's written in so long as it works like this in the browser.

Not only does Template Animation release you from the long term bonds of your technical choices in backend technology, but it shortens the lifecycle of iterations in your product and makes it quicker, cheaper and easier to change the user experience because you can iterate in your static mockup without having to "re-templatify" - that is re-add a bunch of template tags/logic or re-fragment your templates.

Even things like modernising and progressively enhancing your "Web 1.0 application" to be some wonder of modern engineering, single page application with hash bangs out the whazoo would be far simpler when your HTML templates are completely independent of the codebase used to animate them.

Okay smarty pants, but some logic is always required in templates LOL!!!1

In considering the implications of building an application using this method I came up with a few hypothetical scenarios to test the waters and I've narrowed the type of "logic" that you still need in templates to 2 things:

1. Conditionally printing some value to the screen (eg. a form error or different menu items depending on whether the user is logged in or not)
2. Conditionally including some structural element (eg. a sidebar when logged in or a shopping cart if you've added items to it)

The solutions, however, are trivial and require no logic to be present in your templates.

In the first case, you simply include everything in the markup that might need to be there, and the programmer removes whatever is not necessary:

In the second case, the designer/HTML/template guy simply implements two versions of the template and the developer loads whichever is appropriate:

In that second example of course, we've got a bunch of duplicate markup, but that's not our problem. That is the job of whatever system you're using to fragmentify your templates and re-use common assets. Hell, designers don't even have to use the same tools as each other in order for this to work, let alone having to use the same tools as the developers.

What about haml/markdown/{insert markup abstraction technology}

The longer I work as a programmer the less I care for abstractions. This goes, too, for ActiveRecord as an ORM strategy (although that's a subject for a different post) - Joel Spolsky summed up the Law of Leaky Abstractions years ago and I think that's still relevant today.

But if you really want to use some abstraction on the front end that means you have to type less markup or write less JavaScript, be my guest! Just make sure that by the time I'm working with the templates and adding in my logic to them, they're head-to-foot complete HTML documents with no crap in them.

Just the same as our Fragmentify script runs in PHP and allows the HTML guy to iterate on fragmented templates, so too could a simple HAML or Markdown parser allow an HTML guy to iterate with a minimal locally installed environment. Whatever. I don't care. It's all HTML, CSS and JavaScript in the end, the only thing that Template Animation advocates is that the technological barrier between the frontend and the backend is never crossed - that our templates are truly logic-less and that I never have to try and find a freelance designer that is also familiar with Django.

If you've read this far, please don't hesitate to follow Working Software on Twitter, become a fan of Working Software on Facebook and subscribe to this blog via RSS. You can also enter your email address below and I'll send you an email when we update the blog.

Just a quick note to let everyone know about a new website deployment that we're very proud to have been a part of deploying:

http://www.energyforopportunity.org/

Energy for Opportunity is an organisation that focuses on skills and training for building sustainable power generation capacity in remote 3rd world communities.

Working Software supplied Django development services to get the website up and running, and helped with deployment and choosing a web host.

Congratulations to all the team at EFO - we're really impressed by the work they're doing and wish them all the best for the future.

I've been working with the Basecamp API to plugin our IRC bot that we use for time tracking and I'm astounded to learn that escaping single and/or double quotes for XPath queries in PHP does not have a well documented, best practices solution.

In fact, it seems as though this is not peculiar to PHP. I took a look around and found this excellent article by "Kushal" (s/he doesn't have his full name on his blog):

http://kushalm.com/the-perils-of-xpath-expressions-specifically-escaping-quotes

I've produced a PHP solution for the general escaping/concatenation problem:

https://gist.github.com/1155973

Anyone got a better/more elegant solution? I'm always a big fan of code golf :)

I just watched another fantastic TED talk video that Will Franco (a.k.a FlyWheel) over at Jive Systems linked me to a couple of weeks ago.

The video focuses primarily on changing from the "carrot and stick" model of management and incentives and into a "ROWE" (Results Only Work Environment) model for creative, 21st century tasks.

He frames the problem as being one of tasks that involve creativity vs. those that only require "mechanical" skills using a series of experiments done with the Candle Problem.

More specifically, that when 2 different versions of the same problem - one requiring the participant to overcome the problem of "functional fixedness" creatively and the other not - traditional extrinsic motivators either do not work or do work respectively.

About halfway through the talk, however, Pink states that software development is one of the things that can be pretty easily outsourced, and that's where I would disagree.

This reminds me of the famous section of the Mythical Man Month by Frederick P. Brooks, Jr.:

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication between them. This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming

This ties in closely with what Dan Pink is saying, but in quite a subtle way. What both Brooks and Pink are describing is a "purely mechanical" task vs. one which requires thought, creativity and communication.

The challenge in building software is that it takes a software engineer to know the difference.

Whilst it's simple for anyone to change the Candle Problem from one that requires creative output to one that doesn't, the process of "removing creativity" from the requirements of developing software is a software engineering task, and one that requires immense amounts of creativity.

In fact, the task of partitioning tasks on a project, particularly for a very early stage prototype, is often so much work that whoever might be doing the work would have been able to do the task faster themselves (and been more motivated to do it a better job of it!)

So think next time you are, or someone you know is, wanting to outsource software development: who's doing the creative tasks?