In response to many requests, I have created an Android App version of my popular Chorderator guitar chord lookup tool. This is a quick app that lets you look up any guitar chord you can think up, in any tuning. Many tunings come preprogrammed, including guitar standard, dropped D, mandolin,bass guitar, and banjo. Or you can add your own custom tunings. You can listen to each chord shape.

And NEW to the Android App, you can batch up a collection of chords into “Chord Sheets.” So, for example, if you’re learning a song you can save all the chords for that song into a sheet, which you can share by email or text message.

The App is completely free while it is in its Beta stage. Eventually there will be a free version and a pay version. For now, why not head on over to the Google Play Store and give it a download!

By some measures, Django is still shiny and new. Originally created in 2003, it’s newer than my car. A house built that year would be considered pretty much fresh from the oven. A baby born in ’03 would be just entering sixth grade now. But by Internet time, it’s been around practically forever. Especially because Django has been under constant development for that whole time.

The fundamental concepts and philosophy of Django have not changed much, but there have been significant features added and modifications made to the way many components work. This is especially noticeable to those of us who have been using it since its early beta days. While I didn’t agree with every change as it was made (auto-escaping in templates, for example), in general Django has clearly been getting steadily better.

New ways of doing old things

Often I find that the fine developers of Django have added an “official” way of doing something that I was doing on my own. Although, of course, since they’re not me and they don’t consult me before implementing their feature, it usually works in a slightly different way. And example of this is the static files module. I had set up a very similar system on my own. For existing projects, I decided to stick with my original setup, but for new ones, it makes sense to use the officially supported version. That way I get the benefit of community based support, and when future developers come along it will look more familiar to them.

But be aware of breaking changes

Newer is often better, but not always. Things can change from release to release in such a way that your existing code will break. For example, in release 1.2, support for Python 2.3 was dropped. Always be sure to check the release notes for the new version and any intermediate versions before performing a Django upgrade. (Obviously, this is good practice for any library you depend on, but when talking about the central framework of your entire site, it takes on additional importance.) Perform the upgrade on your development server first to work out any kinks. And always try to run the same versions on your development machine as on your production machine.

Don’t be a bandwagon jumper

Just because something is new and trendy doesn’t necessarily mean it’s right for you and your project. If your existing approaches are working and don’t pose a security risk, there is often no point in switching to a newer approach. See my above reference to the static files module. Switching my existing projects over to it would just introduce the risk of new bugs, for little gain. Likewise, if your site is running fine in an “older” version of Django and you don’t need new features, think twice about upgrading. This is a judgment call that you will have to make on a project-by-project basis.

It is often worthwhile to upgrade a project that doesn’t necessarily need it in order to keep that project on the same level as your new projects. It makes development and deployment easy if everything is running the same version. So the needs of one application can lead to a decision to upgrade several others. This can be good practice, just be sure to perform a full suite of regression tests after the upgrades.

This is a simple one, but I have seen projects where this was not followed, and the result was a real mess. so please, please, please do not mix your media!

There are (at least) three types of content that we can think of as “media” in a Django project: There is the Django admin media – the CSS files, images, and JavaScript that come with Django itself for use in the admin interface. Then there is your own static media that you use to style your site. And finally, there is user-uploaded content – things like profile pictures and so on. I recently took over a project where all three were in the same directory. I nearly wept.

In case it’s not obvious:

• Django media stays with Django. Wherever you have Django installed, be it as a Python Egg, checked out from Subversion, or as part of your OS’s packaging system, keep it there. Use your web server’s configuration to map a URL to that path (taking appropriate security measures, of course). And set the ADMIN_MEDIA_PREFIX setting.

• Your static media belongs in version control, probably with the rest of your source code. Depending on your work flow, you may want a separate system for the raw Photoshop or Gimp image files and the final web-ready images. I have an /img-src/ directory and a /static/images/ directory in every project, for example. The important thing is that they are separate from other media types, version controlled, and updated when the rest of the code is updated. Important note: Do not use Django’s MEDIA_ROOT and MEDIA_URL settings for this. These settings are for user-uploaded content. Django’s documentation is a little unclear on this point.

• User-uploaded content stays separate. As always, use caution in what you let your users upload to your server. Validate the files if possible. Create your own file names; that is, don’t let the uploading user choose the server-side name of the file. Limit the upload size. And of course I don’t need to tell you not to run your FastCGI process as root, right? Right? (Believe it or not, the project I recently took over was set up like that, so I guess I do need to say it.)

Just as in real life, it’s important to pay attention to where you put stuff. A place for every file, and every file in its place.

Today’s tip is:

Don’t Get Trapped in the Django Universe

One of Django’s strengths is its “batteries included” approach. It provides for free many of the features you would normally have to write from scratch or cobble together from disparate sources. Some examples are the authentication system, the administrative interface, and the templating system. These are wonderfully useful, and they often work together in ways that separately developed libraries can not. However, not every part of Django will fit your needs all the time. Choices were made in the design of Django, and those aren’t always the same choices you would have made.

Fortunately, another strength of Django is its modularity. It is very easy to unplug one of its built-in features and plug in your own or someone else’s. I’ll go through some of the Django features that you may want to consider replacing or eliminating.

The important point I want to emphasize is that there is nothing unclean or dangerous about doing this. It’s your site, you’re the boss of Django, and you should only use the parts of it that you need. I think the creators of Django would agree with me.

The Templating System

There is nothing sacred about the Django templating system, and no reason you have to use it in your application. In fact, the more I use Django templates, the more I appreciate the power and flexibility of Cheetah, and so in most of my recent projects I have used Cheetah for my templates. You do lose out on some of the generic templates and template tags that Django provides, but these are easily replaced, especially because Cheetah allows calling arbitrary Python functions from within a template. As a solo developer, I find this power very convenient.

If there is interest, I will be happy to share some of the functions and code I have developed to make it easier to use Cheetah within Django.

The Authentication System

Django makes it very easy to replace or change the built-in authentication/authorization system. You might want to do this if you already have a system in place: for example, if you use HTTP authentication via Apache. Likewise if you want to do something wacky like authentication by IP address within an intranet. Or maybe you have a completely public site with no need for authentication at all.

The simplest way to customize your authentication is to provide a custom Authentication Backend. But you could go so far as to completely replace or eliminate the django.contrib.auth app. Just be aware that the Django admin site relies on django.contrib.auth.

The Object-Relational Mapping (ORM)

Django’s high-level Model and QuerySet interface is great for abstracting away the details of database operations, so it is rare that you need to write raw SQL. So much so, in fact, that you can write a complicated application without even knowing SQL. This is a bad idea, however.

Learn SQL, learn what Django is doing behind the scenes with your queries, and don’t be afraid to use raw SQL when it is appropriate. There are some things you just can’t do with Django’s ORM: for example, any operation that involves reading and updating a field atomically. Other operations are just much faster if you can do them raw. A good rule of thumb is that if you are performing queries or updates inside a Python loop, investigate switching it to SQL. One big query is generally much faster than a bunch of smaller queries.

The Database Itself

Yes! Despite what you may have heard, it is possible to create a web application without a database! In fact, for a recent site I developed I did just that. I use Django in a very bare-bones way: Django provides URL parsing and dispatching, a logical source code layout, the handling of HTTP requests and responses, and some utility functions, but that’s it. Apache takes care of authentication, Cheetah handles my templates, and I store user data in a JSON formatted text file. With no database, there is no need for an admin site – I can edit the text files directly in the file system. There are valid reasons for all these decisions, and for this project they fit my needs perfectly. It’s still a “Django-powered” site, but only in a very limited sense.

Django Itself

This should go without saying, but for many new developers it needs to be said. A web application does not need a web framework. Blasphemy, I know. But CGI has been around since 1993. Django was created in 2003, and didn’t go public for a while after that. So we had ten good years of dynamic web pages before Django even was a glimmer. If you’ve never done it before, I recommend making at least one pure CGI (or FastCGI) app, so you can better know and understand what Django is doing behind the scenes. It’s not magic or mystical or even that difficult. Just as driving a stick-shift makes you a better driver even on an automatic, knowing the details of web protocols will make you a better web developer.

Then when you go back to Django you will appreciate all that it is doing for you, as well as realizing that the Django way is not the only way.

Why “Eddie’s Practices?”

Django has become one of the more popular web frameworks out there. I have been lucky enough to have worked with it for many years, starting in its early beta stages. I’ve used it to create many web applications on my own, and I’ve worked on many apps that were originally created by others.

As in most development environments, there are certain common issues that pop up again and again. Over the years, through trial and error, talking to other developers, and a lot of hard thinking, I’ve come up with some general approaches to many of these issues.

I have gotten a great response to my previous posts about Django, so I decided to create a new series of posts, dealing with these tips and techniques. I wouldn’t have the hubris to call these “best practices,” because that would imply that my way is best for all developers. So I’ll just go with “Eddie’s Practices.” These are things that work for me, things I wish people had told me when I was starting out. I hope they work for you, too. Mileage may vary, as they say.

Tip #1: Think hard about what to name your project and your app.

We’ll start with a basic one, but one that seems to come up over and over. When you get started with Django, you create a “project,” and then within that project you create an “app.” You need to come up with names for both of them. This may seem a trivial point – surely an app by any other name would be just as enterprisy. But it can affect your future development in unexpected ways.

For example, say you want to create a website for playing poker. Not a very far-fetched idea – there are a couple sites like that out there. So you check the Django getting started guide, and run the command to create the project:

~/src>django-admin.py startproject poker

Fair enough. It makes sense to call your poker project poker. But now, you need to create an app as well. What do you call that? Well, we can’t use poker, as the following shows:

~/src/poker>python manage.py startapp poker
Error: You cannot create an app with the same name ('poker') as your project.

Hmm, you think. Maybe I can be clever! So you decide to name the app “game.” That way, you can refer to it as poker.game. Brilliant! It’s a poker game!

Not so fast.

Oh sure, it seems fine for a while. You come up with a clever marketing strategy, you launch it at zoombidingle.net, you advertise it, you even start to get some users. After a while, you decide business is going well enough that you want to expand. Poker’s great and all, but what people are really clamoring for these days is dominoes. The wave of domino-mania that is sweeping the nation is unprecedented. You don’t want to miss out on your piece of the domino-pie, so you decide to create a Dominoes app.

As a smart business person, you see it makes sense to leverage your existing user base and just add on to Zoombidingle. You can even let your users use their existing virtual poker chips to buy into the domino tournament. Fine: cd into your project directory and start typing:

~/src/poker>python manage.py startapp ...

Now you’re stuck.

It obviously makes sense to call the new app something like “dominoes,” but you have a nightmarish vision of having to type poker.dominoes all over your code. Besides sounding vaguely obscene (“I don’t even know ‘er!”), it doesn’t accurately describe the code’s hierarchy. Add to that, you still have poker.game, but isn’t dominoes a game, too?

So you rename things. You change your project name from poker to games. (You don’t go with zoombidingle because you don’t want to link the marketing decision of the site name with the codebase.) You change your old app name from game to poker. You do a bunch of grepping through the code base, hoping you catch every reference to those names, and hoping you don’t forget which poker is which and don’t confuse game with games. You update your web server configuration to point to the new directories. You deal with the errors Subversion always seems to give when you rename a directory, and voila! You have a new project hierarchy, and you can happily create your dominoes app and go on your merry way.

Ok, so is it a huge deal to have to rename things? Maybe not, but it’s two or three hours of your time you could be using to write fresh code or catch up on Glee. It just makes sense to pick the right name in the first place.

And I know I’m not the only one who has run into this issue. I have taken over a development project where the “project” was called (let’s say) fooblygoop, which was the name of the website. They apparently were not feeling very creative, so the “app” got named fooblygoop.fooblygoopapp. Bleah!

So now we come to a general rule of thumb. Eddie’s Practice #1:

Think specific for the app name, think general for the project name.

The important thing to remember is that you may end up using the app in another project, and you may end up adding more apps to the current project. In fact, in my experience, this almost always happens. Even when you don’t anticipate reuse, you’ll often be surprised later to find yourself recycling an old app.

For the poker example, poker would have worked as the app name, or maybe something even more specific, like holdem if your site is a Texas Hold’em site. Then you could even market the app as a standalone plugin for third-party web sites.

For the project name, think about how you might possible expand the project in the future. games is nice and general. Or even funstuff if you’re feeling whimsical.

Yes, this is a simple tip, but one that is well worth keeping in mind. It could save you a few hours and a few aspirins.

Stay tuned for more of these tips. They’ll get more in depth and technical as they go along. And please let me know in the comment section if you find this helpful or you have anything you want to add.

My first thought was, “So what?” but then I read that Google is also working on a similar service, and in fact the two companies were in a race to see who could launch it first. So apparently two of the smartest companies out there think this is a good idea. Given Apple’s recent track record, I’m going to guess it’s a good bet.

While I believe them that it’s a good idea, I will never use it, and I would never have thought of it. Why not? Because I don’t need it. I have my ten-dollar-a-month Dreamhost account on which I host this website and a bunch of others. My account was granted unlimited storage for life to make up for some billing mix-up a couple years back, so all I need is rsync, ssh, and a couple Perl scripts and I can have the same functionality without the privacy concerns of using Apple or Google’s service. If I want a slick streaming web interface, well that’s easy with some Django-based magic and an open-source Flash media player – I can even customize its source code! So why would anyone need a third-party music streaming service?

What’s that? You mean not everybody knows Perl? Not everybody manages web apps for a living? Not everybody cares about privacy?

Don’t Be Too Smart

Well, clearly I’m not the target audience for this idea. But that’s a problem, and if you’re reading this blog it’s probably a problem for you, too. I’m not saying we all need to compete with Google or Apple, or that we have the resources. I’m saying we – and by we I mean the developer community, those who would rather read Slashdot than People – are missing out on opportunities. We casually dismiss the People-readers because they type LOL after every sentence, because they use the word “password” as their password, because they don’t know how to right-click their mouse, because they shell out $2.50 for a 30-second ring-tone when they could easily jailbreak their phone and customize their rings to their hearts’ content. In other words, we dismiss them because they are not like us. They are not stupid: many of them are successful CEOs, professors, architects, and so on, but their areas of expertise are not in information technology. But guess what? There are a lot of them and they spend a lot of money!

To be honest, I still don’t get the one-button mouse thing. I figure since I have five fingers, why can’t my mouse have five buttons? In fact, give me a mouse for each hand for a total of ten buttons. Or better yet, give me 101 buttons and a CLI, and remove that silly pointer thing. Still, I guess there’s a pretty successful product out there with only one button.

But Don’t Be Dumb

So when it comes to thinking up product ideas, we have to “dumb-down” our thinking a little bit. But how far? There’s clearly a danger of going too far. My 92-year-old grandmother, as sharp as she is, doesn’t know Perl, but neither is she about to go buy cloud-based music. Instead, let’s fall back on every consumer-based marketer’s go-to group: Lady Gaga fans, by which I mean 14-year-old girls. (Yes, I’m sure there are plenty of 14-year-old girls who are amazing programmers, but how many of them also listen to Lady Gaga?) I’m talking about the people who don’t know Perl and don’t ever want to learn Perl, but can text-message at the speed of light. They want their music, they want it now, and they only want to have to press one button to get it.

So what’s the take-away? Listen to Bad Romance more? Hang out with teenagers? No, we don’t need to torture ourselves. But let’s try to step away from our little world of command line prompts and Hypersnoot Transport Protocols and see what the paying consumer really wants – simplicity, pretty colors, and a good beat that you can dance to.

A software developer reading that article may jump at the perceived opportunity: Hey, I better learn iOS, or Android, or Windows Phone 7, or something! A recruiter reading that article may experience a feeling of dismay: Crap, there’s nobody who can do what we need doing! They would both be wrong.

Rather than a real paucity of qualified engineers, what the article really highlights is a fundamental flaw in the way many companies hire engineers. Instead of focusing on “Engineers Who Can Write Software for Smartphones,” they should be seeking engineers who can write good software, period.

If you know how to program and do it well, the platform is irrelevant. Likewise, a poor programmer who claims eight years experience on the iPhone is still a poor programmer. I would rather hire the good programmer who has never programmed for a mobile device than a “mobile app expert” who can’t program his way out of a paper bag.

If you don’t believe this is a real problem, take a few moments to peruse Dice.com or Craig’s List, and notice all the job listings looking for “8 years exp in ObscuroSoft version 2.5, knwlge of Arcaniastro X desirable.” These types of ultra-specific requirements can in fact backfire. A developer who has spent eight years memorizing the exact names and parameters to every function in some esoteric API has wasted eight good years that could have been spent learning new programming paradigms or analysis techniques.

The one possible exception I can think of is for a contract of less than three months, when you have one specific bug or change that needs addressing, and your normal developer is temporarily unavailable. Even then, three month contracts rarely stay as three month contracts. New issues crop up and customer demands change. So this is an even rarer instance than it may seem.

Remember, you’re hiring a person, not a technology. I believe that’s a good general rule in all hiring: you want really smart dedicated fun people on your team, and should never just hire the person with the most direct experience in a narrow discipline that you need for that moment. Priorities always shift, and a specialist is useless in weeks.

If you’ve never heard of Scopa, it’s a fun Italian card game for two or more people. You can play with one of two gorgeous Italian decks of cards or a standard American deck with the face cards removed. There is a section on the site where you can learn how to play Scopa as well. You can practice by playing against the computer, and the game also has a “beginner” level where the computer will give you hints about what moves you can make next.

For my technical audience, the site is implemented in Python and Django on the back end. The game play is completely handled in HTML and JavaScript, using the Comet technology for real-time player-to-player communication. The back end server is my custom-built Sully Server (soon to be released as open-source).

Enjoy, and go play Scopa!

In today’s first episode of Dev Ideas, I delve into the Haxe programming language. Haxe’s main claim to fame is as a free open-source alternative to the Flash development environment, but it is really a multiplatform language and toolkit. In addition to Flash .swf files, Haxe can target JavaScript, NekoVM, PHP, or C++ source code, making it possible to use the same language for all phases of a project. Haxe also gives you access to advanced language features like closures, type inference, and algebraic types. Come join me as I give a quick (23 minute) overview of what makes Haxe interesting and worth learning.

Watch the presentation now

The recent changes include:

• Fixed handling of dates. You can now use a Python datetime.date object anywhere the API calls for a date.
• Implemented recurring payments.
• Implemented Fraud Management Filters.
• Implement reference transactions.
• Changed the license from the Affero Public License to the GPL.

Enjoy! And, as usual, please feel free to contact me with any questions or issues.