Posts Tagged ‘django’

From Idea To Business In Three Days Using Minimum Viable Product

Wednesday, May 19th, 2010

I have been reading a lot of Steve Blank articles at the moment and I was really looking for an opportunity to experiment with his idea of Minimum Viable Product, so we invented an internal project to work on over a long weekend. What could we achieve in just three days and how would the process work? It was a pretty crazy experience and this is a quick overview of what we did and how we did it.

You can see the final product here: http://hosting.djangofoo.com/ not bad for three days work!

The idea

We are a Django shop and find it hard to get simple hosting for clients. What we needed was a simple point and click solution for people with no technical knowledge at all, so that is what we built.

Planning

The first step was the planning phase which took an hour and we did this one week before we started the project. Each person in the team was assigned an area of responsibility and the planning was around the high level design, features, investigating the technology and the existing competition. Then for the next few days we all did some thinking about our areas and let the ideas distil in our sub conscious.

Day 1: High level structure

Day 1 Design. The first iteration of the design has all the elements and a global design but the messaging hierarchy does not flow, it appears too jumbled.

The first day started at a crazy pace as the enthusiasm was at its highest. We had a quick briefing session in the morning and then we all set off to our assigned tasks. We had documented the high level features in advance so we all knew which tasks were our responsibility.

We were a three person team, spilt into three areas:

  • Liza (an incredible designer) worked on the brand and the global styles of the interface
  • Davo (super coder) worked on solving the huge technical problems of how to set up the server, permissions, limited file space, writing bash scripts to create accounts
  • Me, I designed the data model, bootstrapped the project, wrote the models and set about coding the application

We communicated mostly by IM even though we were all in the same office, this helped us keep focused and keep our concentration.

Defining the features, proposition, wireframe and setting up the server, bootstrapping the code base, code snippets

By the end of day one we had completed:

  • A rough interface and brand
  • Wireframed all the pages
  • A feature list assigned with priorities
  • High level marketing messages
  • The skeleton code structure
  • The data model
  • Server set up and configuration
  • The ability for users to change Django version
  • A basic auth systems for users to sign up and login

Day 2: The detail

Day 2: A more polished design with better message hierarchy. There is a real visual style that can be carried across the rest of the site.

The day started with the same amount of energy and we spent the first part of the day validating the logic we had come up with on day one.

We also made some changes to the data model based on the design decisions we have made whilst coding. It felt like more of a details day, there were lots of questions that came up and lots of small issues needed to be addressed.

A large part of the day was spent working on the visual style and making sure that the right messages and visual cues were delivered to the user.

By the end of the day we had completed:

  • A more polished design, visual identity and brand
  • All the text pages content
  • All the user login pages, recover passwords etc
  • The content and elements for the logged in user pages
  • The ability for users to sign up and create their hosting environment, logins, FTP passwords etc
  • Bash scripts to create new users and folders
  • The base HTML and CSS styles
  • Mod WSGI reload when changes are made to the source code

Day 3: The launch

Caption here

In true MVP style we have not yet implemented the payment system, we merely get an email if someone attempts to pay.

Throughout the project we decided that we wanted to be the “easiest Django hosting in the world” so this totally guided our decision making. For every feature we asked ourselves if that will help to make the app the easiest Django hosting in the world. I think the project was defined by what we did not include rather than what we included.

By the end of the day we had completed:

  • All the HTML and CSS for all the pages
  • Integration into PayPal
  • Admin functions
  • Manage.py tool
  • View live logs
  • Security patches

Lessons learned

I think the main lessons learned were actually nothing new but they re-affirmed a few things:

  • Be ruthless with your features if it is not essential then move it to the wishlist
  • If a feature is taking more than about 2 hours then find another way or abandon that feature
  • A framework is a must, you do not have time to reinvent the wheel
  • Small team (ideally two developers and one designer)
  • It is very important for someone to co-ordinate the project
  • Don’t worry about not meeting all your users needs you can always add things later
  • Think of clever ways to get feedback and save time. When we looked at our tasks and times we thought payment integration would take quite a while so we skipped it and simply have an email alert if someone tries to upgrade

One of the biggest lessons I learned was to build your decision making around your core proposition, for us it was “The easiest Django hosting in the world’s”, anything that did not fit into this philosophy was removed, even at the cost of alienating more advanced users. Be bold and focus on your core customers don’t worry about being the solution for everyone. We knew from early on that people who wanted a high level of customisation and were advanced users would not want to use our service, that is ok we are not building a service for them.

Django Developers and Coders

Wednesday, March 10th, 2010

If you are a Django developer check out Django Foo, I have been writing some posts on there recently with the rest of my team.

Everytime we solve a problem that is not well documented we post our solutions on there. It has started to become a really good resource for the community.

New Blog Django Foo

Thursday, January 14th, 2010

Just a very quick post to say that my senior developer has just started his long overdue blog: http://www.djangofoo.com.

The site is going to highlight the issues we come across and solve everyday, as with any framework (even the great ones like Django!) there are hacks, workarounds and things to improve.

Check it out, hopefully I will be writing some guest posts on there as well.

PHP To Django – Lessons From Our Migration

Wednesday, March 11th, 2009

I have been a PHP programmer for a long time, it was the first web scripting language I learnt, and I have built some very cool apps, and it has served me well over the years.

However running a team who code in PHP has a lot of drawbacks:

  • No de facto framework
  • No coding standards
  • Relatively slow benchmarks

Frameworks Rock

I personally love frameworks, who wants to code boring CRUD (create, update, delete) statements, build yet another admin, or yet another news management feature. Like all good programmers I am inherently lazy and hate to code the same thing over and over again.

PHP lacks a really good unifying framework, there is no de facto framework; Ruby has Rails, Python has Django, PHP has … CakePHP, Symfony, Zend Framework and Code Ignitor.

I have used all of the mainstream PHP frameworks:

  • CakePHP – I like the syntax, but the docs are poor and performance is a real problem
  • Symfony – I could not get my head around the workflow and it is very slow
  • Zend Framework – does not seem like a framework to me, more a collection of libraries
  • Code Ignitor – is the best of a bad bunch, and personally my favourite for PHP

These frameworks all compete with each other, instead of all working together to help build one PHP framework to rule them all.

Learning Curve

People love PHP because it is easy to pick up and get going with, you can write your first PHP script very quickly, and have something working in an afternoon. This works for good and evil, as there are so many people out there who code PHP who actually do not understand what they are doing. There is nothing inherently wrong with this, but this tends to mean that PHP has less coding standards.

On the other hand, getting Python to work is not as easy for a new developer and deploying a python site is even worse. Also as Python is a OO language it seems scarier to most new developers. I love Python as it just fits with my philosophy and I love the way that it FORCES you to write beautiful code.

Why Django

As I mentioned that as a PHP shop we have already looked at all the mainstream PHP frameworks and none of them in my opinion are good enough.

I had a look at Ruby on Rails, but the publicity and hype around it, coupled with the reported scaling issues made my wary.

My friend and fellow CTO Ben Philips over at Playfire, suggested that I check out Django. I had a read of the documentation and I was seriously impressed with the feature set. It was not the easiest learning curve there are a lot of pages to read on the site to get you up to speed.

I also started listening to the excellent podcast, this week in django, and I fell in love with the philosophy and elegance of Django.

Installing Django

Installing Django on my Macbook Pro was not an easy task, it took me a whole evening to get up and running; I had to tweak the MySQL python library and I needed to install XCode developer tools to get the Django built in webserver to work. This was not a good start for me!

Our First App

I did persevere through the installation and I was glad I did, the Django API is very elegant and for simple tasks very easy to pick up. I did have some issues managing images, but the Python Imaging Library helped me there. Also I had to get my head around the middleware stack, and the templating language. After a day or so I was ready to build my first app.

I wanted to really try something in a real working environment, so I decided to build the Oracle Acquisition App in Django. In less than two days the app was built including LDAP requests to the corporate directory, and SSO authentication into the Oracle unified sign on.

What I Liked

I loved the loose coupling of URLs, the encapsulation in models, lazy SQL queries, well defined code layout, adherence to DRY principles, admin out of the box and the powerful template language.

What I Disliked

Importing functions into the models and views was tiresome, the sometimes cryptic error message, no SQL query logging and lack of hooks for the admin (which had since been rectified).

The Future

Overall I love Django and I cannot imagine going back to PHP, the next step is for me to sell Django into the Company. It will take some effort of the part of the developers who cannot code in Python, but most good programmers can pick Python up very quickly.

There will need to be a migration process, but I will be slowly migrating all of our systems and future projects over to Django and will be recuiting a specialist Django developer soon. If you are a superb Django developer who is looking for a job in London (and you know a bit of PHP), then have a read of this post.

We’re Hiring – Trying a Different Approach To Finding Excellent People

Tuesday, March 10th, 2009

In the past we have used job boards and recruitment consultants to find the best people to work here at Busara. Sometimes this approach works and sometimes it does not, but one thing is for certain, this approach is going to be a long and very painfully slow process.

So this time I am going to try something different, I am going to advertise here on my blog for the ideal person to join the team. I am also going to add the job listing on some of the more niche sites like Djangogigs.com.

About the role – PHP & Django

We are looking for a superb PHP and Django developer with a passion for all things digital. Your role will be to manage the day to day running of projects and report directly to the CTO. The role will be a mixture of programming (60%) and project management (40%). The role is client facing at times, and will involve direct client contact to help them achieve their vision. It also involves a high degree of autonomy, and the ability to work with and code with an existing development team.

Here is a link to the person and job description. If you are interested please email me at cv at madebybusara dot com (no agencies please, we do not use them).

You can see our work and philosophy on our website: www.madebybusara.com.

Interview process

The interview process is very informal and friendly, and we are looking for the right person as much as the right skill set:

  1. Send in your CV and portfolio of work
  2. We will find the ones we think are best and create a short list
  3. We will invite you in to our office for an informal chat, nothing heavy, we just want to get to know you and see if you fit in with our culture
  4. If we think you are the one for us, we will invite you back to meet the team and they might ask you a few questions
  5. If the team think you are the chosen one we will give you a call with a job offer the same day

About Busara

Busara is a global design and technology agency based in Clapham, south London, and Perth Australia. We have a vibrant, creative, hectic office full of energy and buzz. We work some of the biggest consumer and technology brands in the world, and are always pushing our solutions and ourselves. We are very collaborate with both designers and developers working very closely with lots of joint work and brainstorming. We have plans to open another international office within two years.

Here are some pictures of the office:

Busara Office Busara Team

Here is a video of our Christmas party last year, which was so much fun!