Text

· · to read

I just found myself wishing that I hadn’t deleted some dead code, because I wanted to use the same technique I’d used earlier. Now, if someone else had been in my position, and refused to delete it, because they wanted to be able to look at it later, I would have suggested that they learn to use their version control system better. So what did I need to learn to do? That’s right: learn git better.

After googling, I found that with the -p flag, git log can be made to show patches. I ran git log -p admin.py, since I knew which file used to contain the code I wanted to look at. It brought up all the changes made to that file, including when I created it, in my pager. I searched for get_urls, because I wanted to find where I had set up a custom admin view in django. It came right up! I copied it and pasted it back into the file. Problem solved.

Text

· · to read

I’ve always had the type of job where I’m given a set of responsibilities and some tasks. Many of these tasks are things that have a quick-and-dirty way of doing it, and could be expanded to just about anything.

Clients haven’t always been the best at communicating which tasks are most important. Often, I don’t think they know which are most important.

Sometimes, I have a hard time focusing. That’s why I’m trying a new strategy.

I’m going to try doing many of the tasks in a quick-and-dirty way and see what my clients ask me to improve. Just like a blogger or a twitterer might put out a bunch of posts, and if they get positive feedback, try doing similar posts to engage and expand their audience, I’m going to try doing a bunch of little projects to see what I get the most positive feedback from.

Now, like a blog/twitter audience, clients can be fickle, and lose interest in something they seemed really interested in, so I have to always be adjusting to demand, just like a successful blogger.

The information that helped gel this idea was in a marketing video by Giles Bowkett where he introduced the concept of Test-Driven Decision Making. That’s the concept I’m using here.

Text

· · to read

Note: After letting this sink in, and participating on the Year Of Hustle forums, I think I was just making excuses. When I’ve had success “prototyping”, I was doing it with the intent to ship. I could have released my idea and repurposed it later. I think shipping is the habit I should be trying to form, and that it will help me hone my skills better than prototyping without the intent to ship (i. e. dabbling).

Some ideas just aren’t ready to be shipped out. They need more time to germinate. Ideas that aren’t ready to be shipped, though, are often ready to be prototyped.

I had one idea where the plans for building it felt complete, but I wasn’t sure what my goal would be with the released product. I wanted to do more than impress people with pretty graphics. A few weeks later, while I wasn’t thinking about the idea, I thought of a goal, and while I was trying to think of a way to achieve the goal, I realized my idea would be a great way to achieve it. I also came up with another feature for it, that I think will help it stand out.

It would be nice if I’d already prototyped it, and had it sitting in a private repo on GitHub. There was nothing stopping me, except I was hung up on making things I could show people. If, at the time I knew what I wanted to write, I’d shipped other smaller things recently, I might not have run into this stumbling block.

this is Roy... Roy the killbot by Don Solo

I’m not sure whether it’s shipping that makes prototyping work, or the other way around, but I think developers ought to have a steady diet of both.

Text

· · to read

My friend Andrew Hyde recently launched a really cool service for freelancers called pick.im (pronounced (pick ’em). Here’s what it looks like in Mobile Safari on the iPad:

It searches based on three things: location, type of service, and budget. Yet one of them doesn’t show up in the form: the location. The location is auto-detected using either HTML 5 or the ip address. If it gets the location wrong, it can be changed on the results page.

What I noticed is that people can try out the site without ever pulling up the keyboard. The only reasons to pull up the keyboard are to change the location, to contact a freelancer, or to sign up to be listed as a freelancer. Many won’t start using the site until at least the second time they visit it, so the first time they visit the site, it will be without ever using the keyboard.

When I use my iPad, I like being able to accomplish many tasks without using a keyboard. Subtle changes to a design are sometimes needed for this to work in practice. Pick.im could show the guessed location before searching, but it doesn’t. If pick.im guessed Denver when I was in Boulder before searching, I might correct it, even though I would get reasonable results with Denver selected, due to its proximity to Boulder.

While I really dig the minimalistic design of pick.im‘s search, that’s not all there is to it. Andrew has big plans for it, including helping freelancers spend less time dealing with things like billing and accounting, and more time doing the kind of work they enjoy. For that, the interface will need to be more complex, but by the time people see that, they’ll have already started using it.

It’s nice to hear about new businesses starting up right here in my town. Boulder has a lot of exciting startups right now, and the summer hasn’t even started.

Text

· · to read

I added a new feature to grem: if you’re somewhere in your ~/github directory, you can simply type “grem” and the program will use launchy to open an appropriate page on GitHub in the default browser.

For example:

This is handy, because often I’m in someone’s repo and I wonder what else they worked on. All I have to do now is go up a directory or a few, and run “grem” with no arguments, and I’m there!

I chose to make it go to a repo, rather than a directory in the tree, when I’m in a subdirectory of a repo, for simplicity’s sake. This way, I don’t have to worry about when a directory has been added to a local copy of a repo but not the github repo.

What do you think? Is this command-line tool useful? Do you think my directory structure makes sense? Are there any other ways you can think of that I can take advantage of having a system for organizing my copies of repositories?

Text

· · to read

Meet grem. Short for gremlin, grem is a tool for managing local copies of github repos. Grem is also my first gem. It was remarkably easy to create a gem with newgem and push it to gemcutter.

gremlin (from Inti on flickr)

Right now, all grem does is clone a repository to a default directory. To try it out, run

sudo gem install grem

…and then:

grem benatkin grem

…and grem will clone my grem repo to ~/github/benatkin/grem, creating directories as needed.

I got this idea from a comment on my earlier post, Organizing github repos, by KevBurnsJr, where he suggested making a bash script for cloning repos into my directory structure. I decided to take it a step further by making a gem, and adding more features later.

By the way, standardizing on ~/github/username/reponame has worked wonders for me. It’s lowered the friction for downloading repos, looking at them, and coming back to them later. This script should lower the friction even more.

Speaking of lowering friction, with Heroku‘s help, I deployed a mini-app. Check it out at http://last7.heroku.com/ (github).

Text

· · to read

Earlier this afternoon I was explaining to a designer I just met why I want to work on some projects that probably won’t make any money, but might get buzz. I said that I want to market myself. I felt it sounded cheesy, so I elaborated.

It came out like this. It sounded even cheesier, but rung true for me:

“Sure, I’d like to make money, and be able to buy a house someday, and nowadays you have to be rich to buy a house, but life is short, and I want to hang out with interesting people, and work on interesting projects.”

I now understand why so many artists take a long path toward making money. Or don’t get around to it at all.

Text

· · to read

When I hear someone talk about how nice it would be to have a companion iPhone or Android app to a website, I want to know why. There are two reasons, and I think that one is more valid than the other:

  1. They want to provide the customer with a better user experience.
  2. They think that if the user has their app installed they’ll be more likely to use their product. Thus, it’s a marketing channel.

I don’t think reason #2 holds up to scrutiny. First, I have 5 pages of iPhone apps, but two of them, Tweetie and Dan Bricklin’s Note Taker, account for more than 90% of my app usage. Many of them I haven’t touched since installing. Second, after the initial flurry of installing and trying out apps, I rarely install a new app because I don’t need more apps that I don’t use.

Now, I’m not a typical user, but I’m inclined to think that most casual iPhone users either don’t install many apps, don’t use many of their apps, or both.

Another angle, though, is that to me, it sounds kind of arrogant to think that just because you have your app on someone’s phone they’re likely to use it. That’s like the marketer who thinks that if they get a nice commercial on TV, sales will roll in, even if the product isn’t remarkable. I think what Seth Godin says in Purple Cow is right: you have to be remarkable to be noticed. I don’t think you’ll be noticed just because your icon is on peoples’ iPhones.

I think some people are attached to this idea, though, so much so that they’ll argue to project managers or developers that it will provide a better user experience, and express doubt over the ability of alternatives, like HTML 5 mobile sites, to provide a good user experience.