Category Archives: django

For the past couple of months I’ve been working on a number of Ruby on Rails projects with some talented and experienced developers.  After years of working in the Django world on various projects, Rails is an interesting contrast.

My perspective on developing webapps has changed greatly since working with Rails. This is both due to technical differences as well as differences in the business goals of the projects I’ve worked on.

The rails community has embraced speed of delivering finished apps to an unprecedented level. Using the Heroku stack and add-on services it’s easy to build a fairly complete application by selecting a series of services you need and installing some carefully selected ruby gems. That gets you 90% to a workable project in a lot of cases. The last 10% is adding in the business logic and custom models and views.  Seeing this app development though the selection and configuration of 3rd party services and software was eye opening.

By embracing 3rd party services for things like logging, errors, email sending, and databases you are relieved of a significant amount of infrastructure and configuration setup time. Having a deployment process that ‘just works’ with a git push removes the need for writing custom scripts in Fabric, and Chef/Puppet recipes – so long as you’re willing to accept the higher costs for hosting.

The Python community, even though it’s supported on Heroku seems to have missed the boat on this a little.

I wanted to see how the speed of development could be tweaked for Django projects by making a couple changes especially on the early setup and bootstraping of new projects.

The Python community actually has some tools that make creating projects from scratch even better than I expected.

Cookie Cutter is an awesome tool for development teams that are creating new projects. You get to define a starting point that includes your favorite libraries and is organized the way you like. If you create lots of new projects from scratch then cookie cutter will save you a bunch of time. Rails bootstraps you with their preferred gems which gives developers a good starting point though it also includes things you might not like. Django developers need to invest in a bit of time to develop their own templates 

Embracing class based views – For a long time I was a hold out. Functional views are easy to understand and require less looking up of documentation to see what things need to be called or overridden in order to do what you want.  Class based views however eliminate a lot of the common patterns you would be writing over and over again in a common app. Using the class based views in Django feels a lot more like rails to me, and once you grasp it they will save you development time.

Use and love libraries. The variety of Ruby gems available is shocking. Even things like collecting in static files for something like jquery can save you some time. In Rails you can include jquery-rails gem and then include the js file in your template. two lines added to your project and everything is hooked up. The Django community hasn’t taken the same approach – adding jquery to a django project requires downloading the files from jquery.com yourself and putting them in the right folder before adding it to your template.  It may not seem like much but it makes a difference.

Rails and Django are interesting to contrast. They’re similar enough and yet have taken different approaches to solve the same problems. Beyond the technical differences the community differences are fascinating.

There’s a lot of people out there who have their favorite technologies and there are few more passionate debates than the issue of using HTML5 or native development for mobile apps.

It’s still early days for HTML5 on a mobile platform, the technologies are still maturing and so there are fewer libraries out there for doing things like writing games or interfacing with the hardware. Due to the nature of HTML and interpreted Javascript, performance will never match that of a native app, but with a fast enough phone and a good performing renderer performance issues will eventually not be issues at all.

Native development allows apps to build on the look and feel that users are used to on their devices. Usability should therefore be better on a native app because buttons will be using standard (tested) sizes and provide feedback that the user expects. Because native apps are compiled and optimized for the hardware they naturally have a performance advantage over HTML.

Personally I prefer to use native stuff whenever possible. But sometimes it is just far easier to hook into a web server to deliver some dynamic content in which case it can be simpler just to display it in it’s HTML form.

The current feature I’m working on is to add a commenting system to a bunch of my apps. Using the django commenting app and jquery mobile I was able to get a pretty good web based commenting system in place in a few hours. Translating that to a native form in Objective-C would have taken much longer. So I’m just going to throw up a web rendering widget in the app to load the webpage.

I see the lines blurring over the next few years in this way. HTML is catching up to native in a lot of ways but native will always have some natural advantages and is also improving. Any new hardware features will first be accessible to native APIs before they are wrapped up by webkit and exposed for use in HTML. And differing platforms will always result in HTML5 apps that have to things like “if iPhone then …”. The main benefit for HTML5 then is centralizing to servers that can be quickly updated with bug fixes and that people have HTML/JS/CSS skillsets and want to work on mobile apps.

Right now is simply too early to jump into a pure HTML5 mobile app for anything serious though. As seen by the HTML5 based Facebook App which is terribly slow on both iOS and Android and got bad user reviews as a result of those performance woes. A native Facebook app is in the works to address those shortcomings. But I would predict that it won’t be until iPhone 7 comes out that HTML5 will be able to compete from a user experience perspective with native apps.

I was playing around with Twitter Bootstrap yesterday and managed to very easily migrate my App Control website over to use it as a way to clean up the UI and get it looking a little more consistent.

It provides some nice looking default looks and easy to use css classes to apply. It’s hard to imaging doing another site without using something like twitter bootstrap as a starting point.

Something I’ve found recently is just how difficult creating a great UI can be. The finishing touches on making things line up just right or animate fade ins and dropdowns is surprisingly difficult when taking into account all the various browsers out there.

Twitter bootstrap gives you something professional looking by default and is a fantastic starting point for future customization. If you have a web project I would encourage you to look at it.

Recently I’ve been building out my iPhone App server to provide a business dashboard with all the relevant services and numbers that I care about available at a glance. It avoids me having to sign in and out of many different sites to get the information and makes it easier to push things together – for example charting both Admob and iAd data on the same graph.

Thankfully the web is becoming more programmable every week and these things are becoming easier to put together quickly.

This is a chart I built last night to display the downloads and updates across all my apps for the past 31 days:

You can see the jumps in downloads that correspond to when I released updates to iTunes.

With these sorts of things I’m finding that there is a tipping point. If the custom page I have created is only 90% as good as going to the original source then I’ll just opt to login there but once it becomes as good as or better than that you’ll quickly forget about the 10 different logins you needed to get all those numbers.

Being in charge of it is even better. I use iAd and Admob for advertising and can pull those numbers in and compare them appropriately. On the same page I display data from Apple, Google, Linkshare, as well as numbers I collect myself such as traffic, link clicks and ad impressions. I only have to login to iTunes Connect to release new Apps.

I will continue open sourcing the components for this system over the next few weeks.

One of the ways to make money on the itunes store is to sign up for the itunes affiliate program. Linkshare runs the program in the USA and they will give you a 5% commission on all sales that you refer. It works through cookie based tracking that is valid for 72 hours… Meaning that if you follow one of my links (even to a free download) and then buy something 2 days later then I get credited for the referral and make a few cents.

Linkshare links currently make up about 15% of the revenue in my app business. It’s an extra little bit of money that takes very little effort to add to the bottom line.

I’m building up my back end platform for reporting on all the various numbers I get for the business and putting them in one place. This past friday I got an email about the new web services REST api for Linkshare which I can use to generate various reports. It took just a couple hours to put together a django app that can download the month to date numbers and store them in the database for reporting.

There might be a handful of people out there interested in using this sort of thing so I put the code up on github.

LinkShare_336x280