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 ...


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:


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!


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:

CMS added image

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:


But my wife uses this one for iOS:


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:

Fill out my online form.

Filed under: rss, 2015, blog, rs | View Comments

Kill your index.php

29 Jan 2014

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":

CMS added image

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.


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).


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.










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


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.





Get off your high horse

What is spaghetti code anyway?




A typical example written in PHP would look like this:

Why all templating sucks



You, the reader, December 2011


  • The output of dynamic content







It's all spaghetti code



You, the reader, 2 minutes later, December 2011




Iain Dooley, December 2011


The holy grail: Template Animation



Iain Dooley, December 2011


Traditional templating separation


A proposed, new way of separating concerns







What are the advantages?














Dramatic reduction of technical debt on any project and any platform
















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





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:


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.




















Subscribe via RSS

Building software in the real world - the Working Software blog
