January 25th, 2016 by Eddie Sullivan
December 8th, 2015 by Eddie Sullivan
Designing an API is an art and a science. Many intelligent people have failed. Those who succeed do so by keeping in view the main goal of an API: to annoy the hell out of developers.
My brothers and sisters, to honor that noble-ish pursuit we gather together to enumerate (see what I did there) the Seven Deadly Annoyances of API design. I never thought I’d write a listicle, but at least it has an erudite religious reference in the title.
First, a couple rules: We’re talking about successful, working APIs here. So things like “it doesn’t work” or “it opens a massive security hole” don’t count as annoyances. Don’t take the word “deadly” literally. And APIs that no one uses are not qualified. No, failed APIs are not annoying, just bad. Here we discuss just the minor things. The minor, hair-pulling, keyboard-smashing, Urban-Dictionary-quoting annoyances we all know and despise.
Many of the examples come from Android, because that’s who most recently has the pleasure of annoying me, but I don’t mean to pick on them. They have no monopoly on these sins.
Annoyance the first – trsnss
Yes, name-ification of things is hard. Still, common sense could go a long way. You gotta hand it to the Unix folks for their heroic efforts to save a keystroke – why say dupe when we can save that valuable E and say dup?
Number two is related:
December 1st, 2015 by Eddie Sullivan
When someone asks me what type of development I do, I say “all types.” Sometimes they nod and move on because they’re just making conversation. Others will probe deeper and ask about programming languages. I say “all of them.” That is clearly hyperbole, but in a very real sense, I mean it. Or rather, I mean the opposite.
What language do I develop in? None of them. You might as well ask, “In what language did Plato philosophize?” Well, he spoke and wrote in ancient Greek, but his ideas make just as much sense to those of us who don’t know a word of Greek. The ideas are universal; the language is the medium to communicate those ideas. Likewise, programming concepts are universal and the programming language is the (often clunky) means to communicate – to fellow developers and to the machine.
And yet… And yet, it’s not so simple, is it?
November 4th, 2015 by Eddie Sullivan
Chorderator for iPhone and iPad
The Guitarator suite of apps continues to grow. Today I’m excited to announce the availability of Chorderator for iPhone and iPad
. It contains all the same functionality of the Android version
, but now for iOS devices!
- Look up any chord, any tuning.
- Listen to any chord shape.
- Save chords into Lead Sheets for easy reference.
- Share chords and Lead Sheets with your friends.
Purchase Chorderator in the App Store:
February 12th, 2013 by Eddie Sullivan
Ever since the PC version of Guitarator Toolbox came out several years ago, folks have been asking me when there would be a Mac version available. Well, it’s been a while, but I think will be worth the wait. I’m proud to announce that Guitarator Toolbox is now available for purchase in the Mac App Store!
Thanks to those who tried the Beta version and gave me valuable feedback.
This version is for Mac only and requires at least OS X version 10.7 (Lion).
What is Guitarator Toolbox?
It is a desktop application, originally written for PC, but NOW available for Mac, with the following features:
- Look up how to play any chord you can think of in any tuning for your guitar, bass, or other stringed fretted instrument.
- Look up how to play lots of different scales.
- Perform a “reverse chord lookup” where you pick the frets and it tells you the name of the chord.
- NEW: Metronome.
- NEW: Chromatic Tuner.
Visit the Guitarator Toolbox in the Mac App Store
July 22nd, 2011 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!
May 17th, 2011 by Eddie Sullivan
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.
May 10th, 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!
May 3rd, 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
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.
April 22nd, 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.
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.
Apple 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?