Chicken Scratches: Developing ideas on developing.

Introducing the Chorderator Android App

February 12th, 2013 by Eddie Sullivan

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!

1 Comment - Track comments by RSS

Eddie’s Django Tip #4: Stay Up to Date

July 22nd, 2011 by Eddie Sullivan

The Persistence of Memory

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.


Leave a comment - Track comments by RSS

Eddie’s Django Tip #3: Don’t Mix Your Media

May 17th, 2011 by Eddie Sullivan

Don’t mix user-uploaded content with site-specific content with Django admin content.

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.


2 Comments - Track comments by RSS

Eddie’s Django Tip #2: Don’t Get Trapped

May 10th, 2011 by Eddie Sullivan

This is the second in my series that I am calling “Eddie’s Practices” for Django, in which I present tips and tricks that I have gleaned over the years of working with the Django web application framework. If you haven’t seen Eddie’s Django Tip #1: Choose Names Carefully, why not take a look at it now?

Today’s tip is:

Don’t Get Trapped in the Django Universe

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


1 Comment - Track comments by RSS

Django: Eddie’s Practices #1: Choose Names Carefully

May 3rd, 2011 by Eddie Sullivan

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.

django-logo-positiveAs 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.

3 Comments - Track comments by RSS

The Dangers of Knowing Too Much

April 22nd, 2011 by Eddie Sullivan

Lady GagaApple recently announced that they will be offering a “Music in the Cloud” service, whereby users can upload their music library to a server and access it from anywhere with an internet connection.

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?


Leave a comment - Track comments by RSS

How NOT to Hire an Engineer

April 15th, 2011 by Eddie Sullivan

iPhonesThe Wall Street Journal recently published an online article headlined Mobile App Talent Pool Is Shallow. In this article, Joe Light discusses the problem that a lot of Smartphone app companies think they have: they believe there are not enough engineers with experience developing software for mobile applications.

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.


3 Comments - Track comments by RSS

Introducing Play Scopa: a new Scopa card game site

September 28th, 2010 by Eddie Sullivan

card-logo I have previously written about the Scopa game I developed for Facebook. Well, I became frustrated with the technical limitations of the Facebook canvas platform, and decided to move it off of Facebook onto its own site. So now you can practice your Italian and learn a new card game at You can still log in with your Facebook account, though.

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!

3 Comments - Track comments by RSS

Dev Ideas Episode 1: Haxe: What Makes It Cool

April 1st, 2010 by Eddie Sullivan

Dev Ideas Episode 1: Haxe: What Makes It Cool I’m very excited to tell you about Dev Ideas, a new video and slide presentation series where I will be drawing on my decade-plus of industry experience to discuss cutting edge concepts in the field of software development. For the first few episodes, I’ll be addressing some of the lesser known programming languages and techniques. This is a very exciting time to be in software, as new languages and paradigms are emerging and ideas that were previously limited to academics and research projects are now becoming mainstream.

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

1 Comment - Track comments by RSS

New version of PayPal on Python

February 6th, 2010 by Eddie Sullivan

I’ve published version 0.6 of my Python implementation of the PayPal NVP interface. You can download PayPal on Python here.

The recent changes include:

  • Fixed handling of dates. You can now use a Python 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.

Leave a comment - Track comments by RSS