Author: Matt

the web 1.0 was defined by static html pages and simple cgi scripts.  Web 2.0 was marked by improvements in CSS and HTML capabilities, as well as growing influence of Javascript especially with AJAX to make things a bit more interactive.

The next significant shift in the development of websites is moving a lot more of the page layout and generation to the client side and implemented in javascript.  The web server won’t be generating full pages anymore, only snippets and raw JSON for CRUD operations.

Web 3.0 is enabled through several MVC frameworks such as Backbone.js which encourage application logic to be moved client side to the browser and the server serves up the raw data and persists anything required to the cloud.  These next gen websites give the developer a more clear line between UI code vs server side persistance.

It makes sense to move control of the HTML layout and rendering over to Javascript because that’s what it was designed to do.  Adding a template language and renderer on the server side only to further manipulate the DOM client side is a bit of a duplication of responsibility.

The learning curve for this change is a bit steep.  Check out ToDoMVC for a review of the javacript libraries/frameworks available.

There are few arguments with programmers that can elicit such passionate hatred as a debate about measuring a programmer’s performance by tracking the number of lines of code they write per day.

There are far too many variables at play which can affect a programmers ability to type code – how well they understand the problem, the language being used, familiarity with libraries, and distractions in the workplace.  Because of these extra variables it becomes unfair to compare LOC productivity between programmers or between projects.

However I do believe it has merit as a personal metric.

I am a believer in mastery through practice.  You deliberately practice a musical instrument by playing the same song over and over until the performance is good.  You learn your multiplication tables by practicing on 1000’s of example problems in primary school.  You master Jujitsu by repeatedly doing the same throws over and over until they become instinct.

For mastery to occur the practice must be deliberate and focused on improvement.  You wouldn’t get better at playing piano if you just mash keys – no matter how many hours you did it for.

Software programming is a skill like these others which takes experience to become proficient with.  For the vast majority of programmers I’ve met proficiency comes naturally through years of 9-5 coding.  I’m not happy with that level of performance for myself.

Measuring yourself in terms of time to code a solution to a given problem is a valuable metric to have to identify what areas you need to focus on.

For example if you took a standard example such as implement a merge sort algorithm – and tested yourself on that over time and against different languages you would be able to measure a meaningful change in your programming performance.

You might first find that you don’t know the algorithm well enough to type it out off the top of your head and turn to Google for a description of it (a detour that takes valuable time).  If it’s a new language you may find points that the syntax throw you back to a book.  Over time if you continued to learn you could reduce the time it takes to type out a solution.

It’s not that typing out merge sort once per week is going to be code that you would even want to keep.  Just like you don’t record your drum practice and post it up in an album on iTunes.  The point is to identify places in your process for improvement by asking could I have typed out this code better or faster if I was more familiar with the syntax, or knew of some extra libs to use that would cut down on lines of code.

Then once you’ve perfected that song (algorithm) move onto something new.  Practice it until there is no room for improvement in your time to solve or code quality.

I believe that practice like this should improve your personal day to day Lines of Code Per Day metric to be 2x to 5x what it would have been without the deliberate practice.

This year myself and a friend have taken up the challenge of releasing a new iPhone/iPad game every 2 weeks to hopefully have 20-25 finished games by the end of the year.

The strategy is to build upon 3 different game platforms for all the games.  Each game will add one new feature to the platform and completely replace all the art assets to create a unique and fun game.

The first game was submitted to Apple last week.  It was an update to the first game I did for iPhone called UFO Invader.  It will form the base platform for the next 8-10 games.  The second game, called Air Barons, was finished up and submitted to Apple last night.  The next game is an 8-bit styled space fighter and will add tile-mapped levels and designed coin/power-up layouts to the platform.

The goal of this challenge is 4 fold:

1. Learn how to create better and better games through fast iteration of the entire process – design, art, programming,  and marketing
2. Reduce the risk of focusing on one big game by producing many games that each may resonate with different players
3. Start generating a small cash flow quickly that will grow with each game release
4. Build out a network of games to cross promote each other

It is not going to be easy to do working just in the evenings and weekends but 2013 is the year to do it!

I’ll be blogging about the work I’m doing here on this site as I go.

Celery is something that I kept hearing about but took me a while to wrap my head around.  Why is it important? What is it good for?

With a couple of big Django websites under my belt it has become more obvious where something like Celery fits and why it’s useful.

The first thing you need to know is what problem Celery solves for you.  It allows you to do things asynchronously so that you can perform longer running tasks in the background and quickly return a page to website visitors.  It also provides a means for running and scheduling tasks that might have before been managed by crontab.

It is good for things that could result in long wait times like sending emails.  In the case where the code to send an email could potentially timeout if the mail server is down then putting the send email code into a view function could result in a long frustrating wait for the user.

The biggest issue with cron is that in a multi-server environment it is difficult to manage what is going to run where, and balance your resources.  It’s also a bit of a pain to deploy changes to the schedule without pushing configuration files to your servers.  You lose control over any load balancing and it becomes difficult to manually kick off processes.

Celery also provides some neat methods for delaying code to run in the future.  For example, lets say you want to send an email to users who haven’t logged in to your website in the last 7 days to remind them of your awesome service.  To optimize it further you’d like the email to be sent at a time of day when there’s a good chance they’re sitting at their computer (the same time of day as their last login).  Using a cron job you’d have a script that queried the database for all users who met the criteria and then send out all those emails at once – and run it every few minutes.  The risk there is that an error in the DB query could result in spamming a lot of people with the wrong email.

Using Celery it’s possible to schedule the code to send the email 7 days into the future.  The task code will be much simpler – check that the conditions are still valid and send just one email to the one user.  It also scales up nicer – since it’s only going to query the DB when there is a likely chance that it actually will have some work to do.

Setting up Celery takes a bit of work.  Actually,  getting it to work is relatively easy,  deploying it to production is a bit more involved since it requires a bunch of other tools you may not be using yet.

There are two celery tasks that need to be demonized – the Celery workers and the Celery beat (for scheduled tasks).  Celery tasks are queued up by either the celerybeat program or from scheduling them in your app.  The queue that all these are persisted into is some sort of message queue service or database.  It can be RabbitMQ, Amazon SQS, Redit, Mongo, or a Django DB.  Workers listen to the queue for things to do and pick up work when they can.

Demonizing the workers and celerybeat can be done with Supervisord.  It simply makes sure that if the programs crash they get restarted, and that they continually run in the background.

Monitoring what tasks are in the queue, what is running, and the results of past tasks is through an app called Flower.

Ensuring that everything stays up and running can be handled by Monit.

Once the infrastructure is in place having Celery really does simplify a lot of the code you write.  Simpler code make me happy.