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.
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 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.
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/.
“Why Ruby?” - RubyConf X Keynote (by David Heinemeier Hansson)
Great talk. Good points and entertaining.
More inspiring Instapaper development insights…
(Source: marco)
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.
Nice tip in the latest Heroku newsletter: “Use Git Tags to Manage Versions”.
I use Git tags to manage the version numbers of my Rails apps. Every time a new version is ready, I tag the current commit like this1:
git tag -a v2.3 -m "adding version tag v2.3"
My environment.rb file defines a constant to hold this information (in this case “v2.3”):
APP_VERSION = `git describe --always` unless defined? APP_VERSION
This constant simply contains the output of Git describe2. Now I can use it anywhere in my app where I would like to display the version number.
You are using semantic versioning, right? ↩
The backticks execute a shell command. Here’s more information: http://gist.github.com/4069 ↩
This nice little Ruby library/gem/plugin is a great helper when you need to execute long running tasks from the terminal.
As the name suggests, it displays the progress of the task and even gives you an ETA for when it thinks it will be done.
Check their examples:
% irb --simple-prompt -r progressbar
>> pbar = ProgressBar.new("test", 100)
=> (ProgressBar: 0/100)
>> 100.times {sleep(0.1); pbar.inc}; pbar.finish
test: 100% |oooooooooooooooooooooooooooooooooooooooo| Time: 00:00:10
=> nil
>> pbar = ProgressBar.new("test", 100)
=> (ProgressBar: 0/100)
>> (1..100).each{|x| sleep(0.1); pbar.set(x)}; pbar.finish
test: 67% |oooooooooooooooooooooooooo | ETA: 00:00:03
I used it a lot for rake tasks that convert/import/export tons of data.
What I’m looking at on Wikipedia, right now.
In the context of computing, a polyglot is a computer program or script written in a valid form of multiple programming languages, which performs the same operations or output independently of the programming language used to compile or interpret it.
Here’s more from this article:
The two most commonly used techniques for constructing a polyglot program are to make liberal use of languages which use different characters for comments and to redefine various tokens as others in different languages.
Weird stuff. Check out the example of the article to see such a “thing”.
Support all browsers to some degree – focus first on the latest and greatest browsers, and then go back and make sure that older browsers look and work reasonably well.
This reflects precisely my approach to creating a website/webapp. I love the new features of CSS3 so much, because they enable me - as a developer - to create a decent UI without having to mess around in Photoshop or write tedious, non-semantic markup just to create good looking buttons, rounded corners etc. The design is implemented quicker, is flexible and the site loads faster, too.
The idea here is to begin with a nice, well-styled presentation that looks good in even archaic browsers like IE6. This is a good thing because even visitors using crappy browsers will be able to read and interact with your content. But instead of stopping there, progressive enhancement says, “let’s provide some additional features for people using better browsers.” After all, people using awesome browsers like Firefox, Safari, and Opera want the best experience possible from the Web. Progressive enhancement says, “let’s give it to them, but only after the less-capable crowd has been taken care of first.”
Unfortunately, when you have a lot of IE users and want to present your site in the best possible way, you have to bite the bullet and create all those buttons and rounded corners in Photoshop.
But I think the ‘progressive enhancement’ method is the best thing you can do. You can offer the best possible visual experience for those who use the latest and most advanced browsers at relative low costs. And for those who use older browsers - well, they probably do not care that much about having the best possible experience on the web anyway.
Altogether, the article is a good read and also provides practical information on the new CSS3 techniques - some of which you might not have heard of yet.
Less important is more important!?
I had to smile when I wrote this. :-)
