Daniel Pietzsch

Recently, I upgraded NZ Walks Info to Rails 3 and Ruby 1.9.3. In order to run this new setup successfully, I needed to upgrade the Ruby version on the server. I chose ruby-build and the rbenv Ruby Version Manager to do so and would like to share some simple instructions that worked for me.

The Setup

I am running the site on a Linode server running Ubuntu Linux 10.04. Here’s the software I use:

• Ruby 1.8.7: installed system-wide using apt-get, located in /usr/lib/ruby
• Apache2
• Passenger 3

Ruby was going to be upgraded to version 1.9.3 while the other parts stayed the same. However, Passenger 3 needed to be reinstalled to work with the new version of Ruby installed via rbenv.

Installing Ruby 1.9.3 on Ubuntu 10.04 using rbenv

I found this Gist by Ben Woodward with instructions on how to install rbenv system-wide. I figured, when installing it like this I would less likely run into permission problems.

Here’s the essential part of the Gist, adjusted to install Ruby 1.9.3:

# Install rbenv
git clone git://github.com/sstephenson/rbenv.git /usr/local/rbenv

# Add rbenv to the path:
echo '# rbenv setup' > /etc/profile.d/rbenv.sh
echo 'export RBENV_ROOT=/usr/local/rbenv' >> /etc/profile.d/rbenv.sh
echo 'export PATH="$RBENV_ROOT/bin:$PATH"' >> /etc/profile.d/rbenv.sh
echo 'eval "$(rbenv init -)"' >> /etc/profile.d/rbenv.sh

chmod +x /etc/profile.d/rbenv.sh
source /etc/profile.d/rbenv.sh

# Install ruby-build:
pushd /tmp
  git clone git://github.com/sstephenson/ruby-build.git
  cd ruby-build
  ./install.sh
popd

# Install Ruby 1.9.3-p0:
rbenv install 1.9.3-p0
rbenv global 1.9.3-p0

# Rehash:
rbenv rehash

Confirming that I am running the new version:

ruby -v
# ruby 1.9.3p0 (2011-10-30 revision 33570) [i686-linux]

Updating Passenger

Now I needed to update Passenger to work with the new version of Ruby. All there was to do was to install the passenger gem, following the instructions on their website:

gem install passenger

passenger-install-apache2-module

At the end of the installation, I got the configuration lines to paste into the Apache2 config file. I replaced my old settings with these updated ones:

LoadModule passenger_module /usr/local/rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/passenger-3.0.11/ext/apache2/mod_passenger.so
PassengerRoot /usr/local/rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/passenger-3.0.11
PassengerRuby /usr/local/rbenv/versions/1.9.3-p0/bin/ruby

Bundler

The only thing that was missing to be able to deploy my Rails 3/Ruby 1.9 version of my app was to install Bundler:

gem install bundler

Done

This was all that needed to be done to upgrade the Ruby version on my Linux/Ubuntu system using rbenv. I hope these instructions will help someone else, too.

Pow has just been released by 37signals:

Knock Out Rails & Rack Apps Like a Superhero.
Pow is a zero-config Rack server for Mac OS X. Have it serving your apps locally in under a minute.

Usually, there’s no configuration needed at all, but in order to get my old Rails 2.3.x apps running, I needed to “rackup” all of these. Following the Rails Guides instructions, I had to create a config.ru file with the following contents:

# RAILS_ROOT/config.ru
require "config/environment"

use Rails::Rack::LogTailer
use Rails::Rack::Static
run ActionController::Dispatcher.new

Then I was good to go.
Unless…

When I tried to symlink the app in the ~/.pow directory - as described on the pow homepage - I got the following error:

~/.pow $ ln -s /path/to/myapp
ln: ./: File exists

But that was easy. I just had to add the name of the symlink explicitly:

~/.pow $ ln -s /path/to/myapp myapp

Now, I was really up and running with my Rails 2.3.x apps and pow. Bye bye Passenger.

(Be sure to have a look at the documentation. It’s the best source code documentation I’ve ever seen.)

We have been lucky. We weren’t in Christchurch when the 6.3 earthquake hit just before 1pm on Tuesday, Feb. 22nd 2011. We were hiking through the mountains near Glenorchy/Queenstown (approx. 400km away to the south-west).
A hut warden was present on this track and he told us on Wednesday morning what has happened. He also offered us to make one call via radio (there’s no cell-phone coverage in NZ’s mountains). The connection was short, but we managed to reach our neighbours to ask if they are ok and if their and our houses are still standing.
Everything was ok, and so we went ahead with the normal plan and continued walking for the next couple of days.

Only after we came back on Saturday, we realized the degree of destruction this earthquake caused. It was terrible to see all the pictures.

We drove home on Sunday only to grab a few things and then leave again. We didn’t feel safe in our house on the hill, although it wasn’t looking bad on the outside. The inside was a bit of a mess, but we expected things to be worse.

At first, we spent two nights on a campground in western Christchurch, before my company organised flights for us to Auckland. We ended up staying there for almost 3 weeks in an unfurnished flat. It was not exactly comfortable, but still more comfortable than being in Christchurch, having no running water and sometimes no power. No shaking was a big bonus, too.

We returned last Sunday. Wednesday evening I went out with my GF1 to take some pictures of the visible damage in Sumner, the suburb we live in.
I need to say that most buildings are looking ok and that you don’t see lots of obvious major damage everywhere. But you certainly won’t overlook it, either.

Recovering after the earthquake: The time on the Sumner clocktower is the one when the earthquake happend. Just before 1 PM.

You see quite a few of these Port-a-loos in the street. Water was not available first (it is restored now), and the sewage system is still not running properly again.

Sumner Church had some considerable damage after the quake in September, and the Febuary one made it worse.

Water tank: before running water was restored, you had to get water from one of these tanks.

A huge rock came down from the cliff in the background.

The Cornershop Bistro. Awesome restaurant where we spent a lovely evening not long ago.

“The Ruptured Duck” restaurant was heavily damaged after the September quake and this one now put it over the edge. It was still standing after the quake, but got demolished now.

Brick buildings are often hit worst.

Some properties are now a bit too close to the edge.

Where’s the roof?

You can see all the pictures in my Flickr set “Earthquake damage in Sumner”.

Programming is not a craft « DanNorth.net

An absolute must-read!

(via Instapaper)

jkleske:

Behind the TEDTalk 2010 – video by mssng peces (via altnytterfarlig)

When I am creating a new feature for an app, I sometimes realize halfway through that the way I am building it, is not the proper way to do so. Or the specification changes. Or there was a misunderstanding. Or there’s an unexpected bug that needs to be fixed and go onto the production server as soon as possible.
Then, when you did all development on the main branch (we use Git, so that’s the master branch in that case), undoing things and/or doing a quick deployment can get very inconvenient. You can’t just deploy a quick bug fix, because all other half-finished features and fixes would have to be deployed, too. You can’t easily revert the existing commits for that feature, especially if the commits are mixed with all the other commits of unrelated features.

A good way to get rid of this problem is to create a local feature branch every time you want to work on a new feature. That branch doesn’t need to be pushed to the remote repository on the server. It’s just for you.
Then, all development for that feature happens in this branch exclusively. For every new feature a new branch is created. After a feature has been implemented completely, merge it back to the master branch (or whatever branch is appropriate). With Git, that’s super easy:

# create a new branch new_feature based on master and switch to it
git checkout -b new_feature master

# when you're done, merge it back
git checkout master
git merge new_feature

# when you are sure everything is working properly
# and no further work needs to be done for this feature,
# you can delete the feature branch again:
git branch -d new_feature

Too often I thought, “I won’t need an extra feature branch for that”. But all it takes is one simple Git command to create one (and it’s probably equally simple in other modern DVCSes). It will make your life easier when coding new features.

Bonus tip

If you decide you want to discard all the development on a particular branch, except for one or two commits, you can cherry pick these commits from the discarded branch:

# say, you have a commit 'bd42c4e7' you would like to keep
# switch to the branch you want to copy the commit to
git checkout master

# copy it
git cherry-pick bd42c4e7

Update: there’s a nice post on the Giant Robots blog which I like to recommend for further reading: Streamline your git workflow with aliases.

Mental Models (Jakob Nielsen’s Alertbox)

Have you ever asked yourself this question? Have you ever given computer support via phone? Have you ever wondered why “normal” people do not understand the simplest most obvious things when it comes to software? I know I did!
This article will give you some explanations.

Here’s part of the explanation for the question above:

The reason is that many users have never formed an accurate model of how the “type-in boxes” on their screen function. When they type stuff into a box, they sometimes get where they want to go. What to type where and exactly how each type-in box functions, however, are often beyond their ken.

maniacalrage:

Here’s the frustrating thing about Tumblr: If you ignore all the downtime, errors, server outages and all that annoying stuff, which took sites down for nearly two full days recently and still continues to crop up regularly—if you somehow ignore all of that—simple things still don’t work properly, like the queue.

Sad but true. I have the same problems with the queue. It’s frustrating.

onethingwell:

Yahoo! are shutting down del.icio.us, ending their careless stewardship of a once-great service.

If you’re still using the bookmarking service, I recommend jumping ship to Pinboard. It will happily import all your del.icio.us bookmarks, and works very much like del.icio.us used to, minus the social aspects.

That’s exactly what I am going to do. I was never really happy with delicious, apart from the fact that I have my bookmarks with me wherever I have an internet connection. Pinboard looks promising and I have looked at it several times now, but never switched (probably due to lazyness and delicious somehow “doing the job”). I guess now’s the right time to finally do it.

Mix and Mash winner entries. On TV. :-)

I couldn’t believe my eyes when the winners of the 2010 Mix and Mash competition were announced last Friday on Twitter. I read my name for the price of the “Best Visitor Experience using DOC Data” and the “Supreme Mashup” categories (the “Supreme Mashup” is the highest price).
This is more than I have hoped for and a great honour.

The Mix and Mash competition is about creating useful and beautiful mashups and remixes with open data from New Zealand institutions.

My entry is a website to find information about all NZ walking/tramping/hiking tracks: http://nzwalksinfo.co.nz/.

Motivation

The minute I saw that the Department of Conservation made available all the geo data of their walking tracks and huts, I knew I wanted to build a website with this data.

The main idea of the site is to get relevant information on walking tracks in a very visual way. While there are lots of tramping websites already (including the excellent website of the DOC itself), I always found it quite tedious to get to some important information quickly - if it was provided at all.

Here are some of the questions I ask myself quite often and that I think are tedious to answer with existing sites:

• What tracks are available near my current location or a location I’m interested in visiting?
• Will it be stressful with a lot of ups and downs?
• Will I only walk through forest or will I have some nice views along the way?

While I haven’t answered all of these question to my full satisfaction, yet, I think this first version is a very good starting point.
The elevation profile for example was a top priority for me, because it’s so important in my opinion. But yet I can’t find this information most of the time. The DOC makes some elevation profiles available, but only for very few tracks and then you have to get a brochure from a DOC office or download the PDF file.

Future development

Of course, I wanted to do more for this entry, but I ran out of time. I think the site is useful already (eh… obviously ;-)), but it can become a lot more useful in the future while sticking to a simple, uncluttered user interface.
I have lots of ideas and I hope I can implement them in the months to come. Winning the competition definitely is plenty of fuel for my motivation.

Mix and Mash is great

I love the idea behind the competition and I think all entries show that it’s a brilliant idea for NZ institutions to make their data available freely. I think it is a great success. Please check out all the other exciting entries on the Mix and Mash website.

Thank you for this awesome competition. It makes the internet better.

“Why Ruby?” - RubyConf X Keynote (by David Heinemeier Hansson)

Great talk. Good points and entertaining.

Ryan Singer - Software and User Interface Design

Spot-on!

More inspiring Instapaper development insights…

Great update for one of my favorite iPad apps, including a new feature I have been waiting for (length & progress indicators). But what really strikes me with this update and blog post, is to see how much thought goes into Instapaper’s features and Marco’s attention to detail.
Just look at the section about the new automatic dark mode preference:

You can now have Instapaper automatically use dark mode at night and normal (light) mode during the day.

But how, exactly, do you define “night”? There’s no API access to the iPhone’s ambient light sensor, so I can’t just enable dark mode in dark rooms.

And I can’t just define hour boundaries, because 8 PM in December is much darker than 8 PM in June.

And I can’t just look at hours and the date, because 5 PM in December is much darker in Alaska than in Costa Rica.

So I used with the most reliable method I could think of: sunset times in your location. Yes, Instapaper is now location-aware, but only for this feature.

I love this.
For example, he could have presented that slot-machine-ish control to the user to set the time range when it’s dark. He didn’t and I think that’s awesome, because it makes it almost effortless for the user to use the feature. And it’s very clever.

During the weekend of October 16th and 18th, I participated in the Rails Rumble 2010 coding competition. The exercise was to build a web app from scratch in 48 hours using Ruby and Rails.
Our team consisted of 3 people: Tim, Falk and myself.
The app we produced: Pianrra - An online keyboard with recording and playback functionality.

It was a rather spontaneous decision to participate. Falk and I joined Tim - who had registered ealier - only one week before the competition started. Then the planning and prototyping started.
The main reason we participated was to have fun, build something interesting and get smarter (although a little fame and a prize wouldn’t have bothered us, either). That’s also the reason why we chose to implement this particular idea of an online keyboard. It was the most unusual, risky, and exciting idea of all the ones we discussed in the week before the Rumble.

The Rails Rumble is a great exercise in collaboration - especially when you work with a team as distributed as ours. Tim and Falk were working from two different cities in Germany while I was hacking away in New Zealand.
Here are some of my insights.

Plan ahead

You can plan a lot of your project beforehand. This is crucial. When all of the planning is done before the competion, you can fully concentrate on the implementation during the 48 hours.
You aren’t allowed to produce any production ready code or graphics, but there is still plenty you can do. Here are some suggestions of what to think about:

• What app are you going to produce?
• What technologies/plugins are you going to use?
• How’s the user interface going to look like? Create Sketches!
• How are your users going to interact with the site? What’s the workflow?
• What is your database model going to look like?
• What name do you give your product?

Everything you can plan in advance, should be. Unfortunately we didn’t have the time to do so and decided a lot of things during the competition. So there is definitely much room for improvement next time.

Write it down

When you plan all this stuff, write it down! Use a tool of your choice where your team can collaborate easily. This is especially important if you’re not sitting in the same room during the competition.
We used Basecamp to do so and I think it helped a lot. Writing it down helped to clarify the vision for the project (‘What exactly are we going to build?’) and helped to agree on the technologies we are going to use. It definitely eliminated most (if not all) of the existing misunderstandings among the team members.

Additionally, create a list of to-dos and assign each of them to a specific person. It helped us to stay focused, agree on features and - this might seem obvious, but really isn’t - everybody knows what everybody else is doing. (Again, this is especially important if you only collaborate online).

For me, in order for a project to be successful, good communication is essential. And writing down goals, tools, features, to-dos etc. was and is an important part.

UI is important

Rails Rumble confirmed to me again, that the UI is the most important part of the software. What are all your amazing features worth when almost nobody can figure out how to use them? Right. Not much.
I won’t say that it was that bad in our case, but we certainly had quite a number of confused users. We made quite a few quick decisions during the competition (especially towards the end) and these obviously weren’t the best. We also struggled with finishing on time and so certain features and improvements didn’t make it. Additionally we also had to deal with more or less unexpected browser and OS incompatibilities. If we had planned beforehand, this would have been less of on issue.

So: get your UI, workflow and copywriting right!
There’s a lot of competition during Rails Rumble and people simply don’t have the time and/or energy to figure stuff out for every app. I know this from myself: I looked at every of the other 179 apps, and when something wasn’t clear to me, didn’t work etc. I just moved on to the next one.

Conclusion

Altogether it was great fun. Sometimes stressful and exhausting, but still fun. We learned a lot and successfully delivered a working application. I am really looking forward to next year’s edition.

Check out our app Pianrra. (You might need these instructions.)

Miscellaneous Notes

• Working in two very different time zones (GMT+1 and GMT+13) is awesome. You can work around the clock.
• Janrain Engage authentication worked beautifully. It saved us lots of time.
• I used Basecamp for the first time. Loved it. There was no learning curve and it’s very intuitive.
• We kept in touch via Skype’s group chat and conference calls.
• Splitting the project into two sprints worked very well.

Sven’s comment and question after giving his opinion to my GF2 quote post:

And: you need a comment system, Daniel ;-)! Reblogging seems a bit heavy for leaving comments to me.

Doesn’t toto with karakuri look tempting to you?

toto and karakuri do look interesting but not really tempting at the moment. It’s just gives me more stuff to fiddle around with. While I like that, it just prevents me from focusing on the actual purpose of a blog. Tumblr just feels right for me.

Concerning comments, I think this post (not mine) sums it up nicely:

The reblog function allows some sort of commentary but also puts a cost on the commenter. I can reblog somebody’s comment, but my response now goes on my tumblelog with all the other things I put there. If I have something valuable to add, I will add it. If all I have is something stupid ([…]) I won’t bother leaving a comment. It is sort of like a comment—but I have to have it on my tumbelog for everybody to read. By increasing the cost of leaving a comment, reblogging eliminates comments left by people who know they are stupid.

However, I agree that it sometimes is a bit heavy to reblog for a comment. But if you follow me on tumblr, you can leave a reply via the dashboard, which will then show up in the notes.

Initial thoughts on the GF2 announcement — Satellite — Craig Mod

That’s pretty much what I am after as well. I think a Leica M9 is an incredible sexy and capable camera (without ever having used one) and the only full-frame camera I’d be interested in. But financially it’s just so out of reach.

I pretty much agree with his first impressions of the recently announced GF2. I think I will still rather get a GF1 for a lower price instead. The new features of the GF2 are just not compelling enough. And getting the latest and greatest is just a waste of money anyway.