Andre Lewis on Tech

Charles Quinn sent me this link, and I immediately installed it: git_remote_branch. It provides nice shortcuts for dealing with remote branches. Examples:

$ grb create branch_name [origin_server]

Create a new local branch as well as a corresponding remote branch based on the branch you currently have checked out. Track the new remote branch. Checkout the new branch.

$ grb publish branch_name [origin_server]

Publish an existing local branch to the remote server. Set up the local branch to track the new remote branch.

And an additional nice touch: grb "prints all commands it runs on your behalf in red, so you eventually learn them." Nice! The link again: git_remote_branch.

A quick tip: you're using script/runner in production (likely invoked via cron for a periodic background task), you probably are not seeing logging output in your production.log. Why? In production mode, the Rails logger doesn't auto-flush. As far as I can tell, the logging output is simply lost.

An easy solution that worked for me: adding a Rails.logger.flush to my script/runner call in cron.

Before:

*/1 * * * * deploy PATH_TO_APP/script/runner -e production 'MyClass.do_it'

After:

*/1 * * * * deploy PATH_TO_APP/script/runner -e production 'MyClass.do_it; Rails.logger.flush'

Bonus tip: to capture any other output from the cron task, use this:

*/1 * * * * deploy PATH_TO_APP/script/runner -e production 'MyClass.do_it; Rails.logger.flush' >> PATH_TO_APP/log/my.log 2>&1

Happy logging!

I just wrote up some tips for contributing patches to Geokit. Pretty applicable to any open source project. If I had to condense it to just one word, that word would definitely be tests :-)

Also some specifics on running tests for the gem and the plugin there.

More on this soon. All I can say for now is:

Ruby 1.8.6:

Completed in 3368ms (View: 2256, DB: 8) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]
Completed in 3668ms (View: 2420, DB: 8) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]
Completed in 3312ms (View: 1964, DB: 12) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]
Completed in 3296ms (View: 1896, DB: 8) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]

Ruby 1.9.1

Completed in 989ms (View: 593, DB: 7) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]
Completed in 1035ms (View: 591, DB: 6) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]
Completed in 1055ms (View: 588, DB: 7) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]
Completed in 985ms (View: 592, DB: 7) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]

With Ruby 1.9 out there and all the multibyte string goodness it brings, it's a good time to think about your character encodings. Here are a few pointers on getting everything synched up.

1. MySQL encoding.

How to check it: I use Sequel Pro ... just click on a table name for the metadata:

How to change it if it's wrong:

I had a bunch of UTF content living in a latin1 table (MySQL calls it ISO-5589-1 latin1). To fix this, export your database and re- import as UTF Details are here, but the gist of it is:

mysqldump -uUSER -pPASSWORD --default-character-set=latin1 DB_NAME | sed 's/latin1/utf8/' > temp.sql 
mysql -uUSER -pPASSWORD DBNAME  < temp.sql

Why not just run the conversions in-place (ALTER TABLE table_XXX CONVERT TO CHARACTER SET utf8 COLLATE utf8_ci;)? That's a different operation -- CONVERT TO CHARACTER SET is appropriate when your content and your DB's encoding already match, and you want to convert it to another encoding. If you have a mismatch in content and encoding, the export/import trick is just what you need. Discussion on additional techniques are here.

2. The charset defined in your HTML headers

How to check it: use curl

~ $ curl -I http://hotspotr.com
HTTP/1.1 302 Found
...
Content-Type: text/html; charset=utf-8

Rails uses utf-8 by default, so unless you've consciously changed it you should be good.

3. The charset specified in your HTML metatags.

How to check it: just view your source and look for something along the lines of <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />. Yes, this is different from the charset in the headers. Mine didn't match on one site. Fortunately, browsers pretty much ignore the metatags in favor of the value given in the header. Still, if you've got a mismatch, it's trivial to fix.

How to fix: open up your application.html.erb and make the change.

4. Your database.yml

Just make sure you have the line encoding: utf8 in your database configuration blocks in database.yml.

5. One more thing to look at...

if you're doing static html caching, then Apache (or whatever web server you're using) probably controls the charset when it serves up the cached page. Make sure it's setting the right charset. More details here

Cool. The newly released RubyGems 1.3.2 has plugins, one of which is graphs. Here is my graph for my Ruby 1.8:

And here is my graph for Ruby 1.9:

Geokit

• Adding GeoPluginGeocoder for IP geocoding (thanks github/xjunior)
• Ruby 1.9.1 compatibility and Unicode fixes (thanks github/Nielsomat)
• thanks other githubbers who fixed bugs/submitted patches

Getting pull requests from for your open-source project on github? The official instructions are here: http://github.com/guides/pull-requests

Since I don't like typing, I automated the process in a very simple Ruby script: http://gist.github.com/64519

What it does for you

1. adds the remote repo
2. checks out the remote repo as a local branch
3. pulls from the remote master or specific commit you provided
4. switches back to master
5. (with your confirmation) merges the just-checked out branch
6. (with your confirmation) deletes your just-checked out branch

To use

• put the contents of the gist into ~/mergefrom.rb (or anywhere in your path)
• make sure it's executable
• (inside a git repo): mergefrom git://github.com/foo/bar.git

I pushed Geokit Gem 1.2.1 this weekend, with some minor bug fixes, the inclusion of nautical miles (in addition to miles & KM), and reverse geocoding (Google geocoder only).

Thanks to everyone on github who made updates and sent me pull requests. The reverse geocoding is from FloWi.

Geokit gets some love!

• Gem released: Geokit is now separated into a Gem (geokit-gem) and a Rails plugin (geokit-rails). You can use the gem separately. The plugin requires the gem.
• Rails 2.2.2 compatible: the plugin is all updated for Rails 2.2.2
• Many bug fixes/updates:
  • Improved Geocoder.us support -- respects authentication, and can geocode city names or zipcodes alone
  • cross-meridian finds work correctly with bounds conditions
  • fixed a problem with columns with "distance" in their name
  • added Geonames geocoder
  • the gem and plugin are now hosted at Github. The overall site is still athttp://geokit.rubyforge.org

Geokit makes it easy to build location-based apps. It provides geocoding, location finders, and distance calculation in an easy-to-use API.

Sinatra is really fun to work with. It's small and fast. It doesn't make many assumptions. If something goes wrong, it's pretty easy to go into the source and figure out what is going on.

There were a couple projects I wanted to take for a spin: Sinatra, Datamapper, HAML, and SASS. I decided to roll them all up into one proof-of-concept project. I don't go into a lot of depth on each, just enough to know that I can get it all up and running.

Also, since I'm running Passenger on some production boxes now, I wanted to deploy my Sinatra/Datamapper app through Passenger's Rack support.

Continue reading "Building a simple Sinatra/DataMapper/HAML/SASS + Passenger app"»

Hotspotr, my community-driven hotspot finder, is a finalist in the Industry Standard Innovation 100 Awards in the Lifestyle category. It's up against some stiff competition from well-known sites. Help us out by voting for Hotspotr!

From the Industry Standard:

We're now at the voting stage, which is also decided by the community. The more votes you get, the more likely you'll become a winner in one of the ten categories. Voting will run from now (August 4th) through October 3, 2008.

Go here to vote for Hotspotr: http://www.thestandard.com/awards/tis100/show_category/5741

Heading up this afternoon. This year looks great, lots of sessions and BOFs look interesting, and of course it's great catching up with folks from all over. I'll be at the Advanced Rails Recipes Book Signing Friday during lunch rubbing elbows with the other Recipe authors -- stop by and say hi!

Passenger, AKA mod_rails

There are a number of posts (one, two) out there on getting Phusion's Passenger up and running on OSX (Leopard). I decided to give it a go, and was pleased to discover several things:

1. Despite reports to the contrary, Passenger installed just fine with Leopard's built-in Apache (I'm running Apache 2.2.8).
2. Setup is very easy, as advertised.
3. My default doc root(~/Sites) is works exactly as it did before. I do some HTML and PHP work there, so it was key that it continue to work properly.

Since the install process itself is quite easy, I wanted to offer a few tips for utilizing Passenger in a typical dev environment -- i.e., what you need after you get your first Passenger-powered Rails app up and running.

Your Brain on Passenger

As you know, script/server starts your Rails app on a specific port. If you bounce around between a number of applications at any one time, you're probably used to either starting them on different ports, or control-c'ing your current mongrel, cd'ing to another app's directory, and script/server'ing again. This familiar pattern changes when you're running passenger. All your apps are available at any one time, as long as you have your vhosts configured.

If you're like me, you usually hit your currently running Rails app on http://localhost:3000. That also changes when you're running Passenger. Instead, you'll hit a unique URL for each app, which you've configured in /etc/hosts to just go to 127.0.0.1

Setting up a new app

I set up a lot of Rails apps in my dev environment. With Passenger, in exchange for the on-demand convenience of accessing any of your apps any time, there are a few additional setup steps to take whenever you introduce a new app into your dev environment.

1. create your rails project as usual
2. add a new vhost. I configure mine in /private/etc/apache2/extra/http-vhosts.conf
3. add the host in /etc/hosts
4. restart apache: sudo apachectl restart

Here's a vhosts example with two apps I'm running locally. You can set up as many apps as you want this way:

  <VirtualHost *:80>
    DocumentRoot "/Users/andre/projects/rails/hotspotr/public"
    ServerName dev.hotspotr.com
    ErrorLog "/Users/andre/projects/rails/hotspotr/log/error.log"
  </VirtualHost>

  <VirtualHost *:80>
    DocumentRoot "/Users/andre/projects/rails/shapewiki/public"
    ServerName dev.shapewiki.com
    ErrorLog "/Users/andre/projects/rails/shapewiki/log/error.log"
  </VirtualHost>

Two things to note here:

1. The ErrorLog line is optional. If you don't include it, the error output for this app will go to /private/var/log/apache2/error.log. Not that that's bad, but you're probably not used to looking for Rails logs there.
2. I decided to go with the convention of dev.[PRODUCTION_URL].com. You can use anything here, as long as it matches up with an entry in /etc/hosts (see below)

And here's an example /etc/hosts addition to match the two virtual hosts above:

  127.0.0.1       dev.hotspotr.com
  127.0.0.1       dev.shapewiki.com

That's it! Go to (for example) http://dev.hotspotr.com, and you're hitting you local development app. There is nothing to start and stop. The first request for any app you hit will take a moment. Subsequent requests will feel quite snappy.

Let's Set up some Aliases to Make it all Flow

Here are the aliases I added to my .bashrc file to give me quick access to everything I needed for a new, Passenger-centric workflow in my development environment:

# Use this in any RAILS_ROOT dir. That restart.txt file tells mod_rails to restart this app.
# You'll want to do this when (for example) you install a new plugin.
alias restart_rails='touch tmp/restart.txt'

# By default, your app's error log now goes here. Unless you configure your apps otherwise, 
# it's helpful to have an alias to take you to your error log quickly.
alias apache_logs='cd /private/var/log/apache2/'

# You'll be adding to your vhosts configuration everytime you introduce a new Rails app. 
# Might as well make it a shortcut
alias vhosts='sudo vi /private/etc/apache2/extra/httpd-vhosts.conf'

# Dito with hosts
alias hosts='sudo vi /etc/hosts'

# You'll need to restart apache whenever you make a change to vhosts. 
# You can also click System Preference->Sharing->Web Sharing, but this is quicker.
alias apache_restart='sudo apachectl restart'

A small thing, but it impacts every moment spent with code: the speed of the as-you-type file lookup/open. On Netbeans, Control-Shift-O takes several seconds (up to 6 seconds in my experience) with large projects.

In contrast, Aptanta's, equivalent Apple-Shift-R is instantaneous -- it behaves like a direct link from thought to file. It also helps that the default keyboard shortcut rolls off nicely with one hand.

So here's my NetBeans enhancement request for faster go-to file.

Highgroove's Scout is live! Scout is our server monitoring and reporting application. If you didn't have the opportunity to test-drive it during the beta period, you can now sign up for any of the plans. Why? Three reasons, based on my own Scout usage over the last few months:

• Scout makes you look smart: if something goes wrong with a client's app, I generally know about it before they call me. So I get to be very proactive. In one case I was able to fix a crashed server before the client even realized anything was wrong.

• Scout helps you build better apps: I had some memory-sucking CSV handling in one of my applications ... but it only happened under certain circumstances in production. With Scout, I was able to correlate the mongrel memory spikes with user activity and zero in on the problem. The result: mongrel instances that don't spike to 200MB, and a better experience for users.

• Scout helps you sleep better: uncertainty is a stressor, and the more apps you have out there the more things you have to be uncertain about. Just knowing that I'll get an email notification if something goes astray helps my peace of mind a lot. Which means my mind is clear to ... design and build more apps!

Ready to learn more? Here's Derek's official launch post. Or cut to the chase and hit the Scout signup page!

Hotspotr -- my community-driven WiFi hotspot site -- announced a content-providing partnership with LightPole today. You can read the press release over at http://lightpole.net/press/index.html.

Hotspotr lists over 8,000 user-contributed WiFi hotspots. LightPole provides a mobile client you can use to browse Hotspotr from your mobile phone using an interactive, maps-based interface:

You can download the LightPole mobile client for free from the Hotspotr homepage.

Separately, Hotspotr is also taking advantage of the Google Maps streetview functionality. For locations where streetview is available, you will have the option to browse the 3-d streetview imagery:

See an example at the Dolores Park Cafe in San Francisco.