I registered “Made by Kiwi” as a company name in 2009. I never really loved it, but finding a good name can be hard, and back then we didn’t have all the options for domain name TLDs that we do today. I really wanted a .com, and wanted to find a name that I could get as a .com.

I never really ended up using this site very much. I thought I would end up maintaining my portfolio and showing the work that I did here, but I always stayed busy and turned out to not really need to do much here.

Throughout my career I continued to work building software and apps mostly on my own. I’ve wanted to have a new name for a while. I wanted something simple, and more personal.

I ended up choosing the “.studio” domain TLD, with the simplicity of just my first name. So, my new website is now simply zef.studio and I renamed my LLC to “Zef Limited”.

On my new website I’m mostly posting personal projects and things that I find interesting that are unrelated to software development. However I do have a small portfolio of my iOS development career posted.

I’ve still never really fulfilled the dream of publishing very much of my own software, but I am taking some steps to work on that and would still like to produce and publish some apps of my own. I’m also still doing some app development work for clients on a freelance basis.

My Rails Rumble app this year is meant to be the beginning of a bigger project that I’ve been thinking about for some time.

I didn’t choose this idea because I thought it was a particularly good match for the Rumble, but because I really wanted to get it going.

The Idea

Creating chord sheets in a word processor really sucks:

• It is difficult to correctly position chords, therefore:
• It is very slow, you can’t place chords in real time.
• You can’t transpose songs easily.

I am attempting to make the process of creating, editing, and using lead sheets much more natural, intuitive, and easy.

The App

mysongnotebook.com is up and running! Well, crawling might be a better term, but the important thing is that it now exists.

Here’s what you can do right now:

• Import existing chord sheets from a format like this
• Reposition chords by dragging them around
• Edit and add lyrics
• Construct new (basic) chords from a chord creation palette
• Add more chords to a song

The application is plain, buggy, and almost unusable unless you know what the bugs are. Most of the issues right now are easy fixes, but are things that I either didn’t have time to address, or that I broke in haste during the last hour of the competition.

I’m eager to fix the existing bugs and want make the app at least minimally usable soon.

I have a lot of new feature ideas that I really like and want to start working, but I don’t want to get into those now.

The Experience

This year was quite a challenge for me in a number of ways.

Technically, it was filled with some new experiences and difficulties. My project last year was basically all stuff I’d done before or know how to do — it was just a matter of putting the pieces together. This year was much different. I was doing things I’ve never done before and the creation process was a big learning experience for me.

It was my first time using CoffeeScript and Underscore.js, both of which I really enjoyed. I also made a last-minute decision to use Backbone.js — released just two days before the Rumble began — which drove me to write my CoffeeScript in a much more organized fashion than I have in the past.

Almost all my time was spent writing CoffeeScript. I used haml-js for templating JS views.

I feel some disappointment with how far I got. I recognize a lot of places where I could have made better decisions in how I used my time. I spent too much time dealing with implementation roadblocks or details where I should have changed my approach or made it work in a different way.

Another challenge was that I was not in a good work environment. I am living in an apartment in Beirut, Lebanon with some family for a few months and I don’t have an office here. Working from the dinner table in a shared space is not good for productivity. The internet in Lebanon is infamously bad — worse than many third-world countries — and I had some connection problems at various times. I also had to go to a restaurant with internet for the start of the competition because we didn’t have electricity.

Overall I am extremely pleased that I used the Rails Rumble as an excuse to get this thing started!

As we are quickly approaching the 2010 Rails Rumble I thought it appropriate to finally post my (4 minute) timelapse video from the Rumble last year.

Last year I built Tiptorial.net. Here’s a 2 minute video showing what it does.

At the time I was working in front of a 24" Dell Display with my 15" MacBook Pro to the left. I ran a script that took a screenshot of each monitor and a picture with my iSight each minute.

If you’re doing the Rails Rumble this year, consider recording it. It’s a fun experience to look back on!

For some reason the iSight shot failed a number of times, so the missing frames have been replaced with black.

Thanks for watching!

I was recently asked how I deal with problems that come up between development and production environments, so here’s my answer. This article refers to apps that are currently deployed, not to deploying an app for the first time.

First, one of the best things you can do to make the deployment process easier is to automate it using Capistrano. I’m not going to get into the details of setting it up, but Capistrano takes the busywork out of deployment and other common server tasks. It also allows you to quickly and easily rollback changes when needed.

Backups

I’m sure you already have a fully automated, redundant, offsite backup system (you are backing up your database, right?). But especially before deployments, make sure that you have a fresh backup, and a good way to restore if things go wrong.

Be a good web citizen

Update the server at times of lower traffic and put up a maintenance page while the site is down, so anyone on the site during that time knows what’s going on. Depending on the audience and traffic level, you might warn users of the planned downtime beforehand.

Check your dependencies

Make sure that any dependencies within the application — gems, rails, ruby version — are the same. The easiest way to do this is to “freeze” the gems into the application’s vendor directory. Rails checks for frozen dependencies first, and if it doesn’t find them, it will fall back on whatever is installed at the system-level.

Freeze gems with rake gems:unpack and freeze rails itself with rake rails:freeze:gems

Environment configuration

Check any environment-specific variables — especially paths to executables — that may not be the same on the production server. Anything that could be different should go in the respective config/environments/(development or production).rb file instead of config/environment.rb, which is loaded for all environments.

Common causes of path problems are any non-ruby libraries that are in use, such as ImageMagick (used by Paperclip), the Sphinx search engine (used by Thinking Sphinx), and many more.

Setup a Staging environment

Rails makes it pretty easy to run different environments. Setting up a staging environment is the best way to be completely sure that you’re not going to break production.

If you are using Capistrano and Passenger, here are some detailed instructions for setting up and deploying to multiple environments.

Here’s a two minute demo of the first version of my Rails Rumble application, tiptorial.net.

I’d love to know what you think.