I’ve been messing with Padrino a bit over the past couple of weeks. There are several smallish apps that I’ve thought that Rails was a little bit of overkill for. However, what I didn’t realize that I was missing was the Asset Pipeline. It’s terribly useful, especially if you tend to mix technologies together in the same app. Once you get into the habit of using it, it gets hard to go without.

I decided to see if I could implement Sprockets directly into Padrino. It turned out to be fairly easy to do, especially since there was already a padrino-sprockets gem out there. Once I figured out the proper way to put everything together, it worked perfectly.

Here is a very quick walkthrough of how to set it up with a brand new Padrino app. Let’s create a basic Padrino application. I’ve basically picked my usual defaults, but it doesn’t matter too much which you use. The bonus is that any of the rendering and templates gems will be available for Sprockets already.

1
2

padrino g project something -t cucumber -s jquery -e slim -c compass -e slim
cd something

Add the following to your Gemfile. This will add the padrino-sprockets gem as well as the handlers for Coffeescript. That part’s optional, but given the Coffeescript love in Rails 3.1 and above, you’ll probably want it.

1
2
3
4
5
6
7

# Use Sprockets
gem 'padrino-sprockets', :require => 'padrino/sprockets'

# Use Coffeescript
gem 'coffee-script'
# rack-coffee shouldn't be needed
# gem 'rack-coffee', :require => 'rack/coffee'

Run bundler and make sure all the gems are installed.

1

bundle install

Now let’s move all of the stuff in public to app/assets instead. The default stylesheets and javascripts are fine defaults.

1
2
3

mkdir -p app/assets
mv public/* app/assets/
rm app/assets/favicon.ico

Replace app/assets/javascripts/application.js with the following. This is basically the default rails application.js file, and just automatically includes all other files in this directory. Putting the jquery and jquery-ujs files isn’t necessary, but putting them explicitly in the file makes sure that they show up before everything else.

1
2
3
4
5
6
7
8
9

// This is a manifest file that'll be compiled into including all the files listed below.
// Add new JavaScript/Coffee code in separate files in this directory and they'll automatically
// be included in the compiled file accessible from http://example.com/assets/application.js
// It's not advisable to add code directly here, but if you do, it'll appear at the bottom of the
// the compiled file.
//
//= require jquery
//= require jquery-ujs
//= require_tree .

And do the same for app/assets/stylesheets/application.css

1
2
3
4
5
6
7

/*
 * This is a manifest file that'll automatically include all the stylesheets available in this directory
 * and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
 * the top of the compiled file, but it's generally better to create a new file per style scope.
 *= require_self
 *= require_tree .
*/

The last thing we need to do is put the sprockets init code into app/app.rb config block. This just includes sprockets and padrino-sprockets and starts it up.

1
2
3
4

# Sprockets support
require 'sprockets'
register Padrino::Sprockets
sprockets

Now if you startup the server, you should be able to hit http://site/assets/application.js and http://site/assets/application.css, you should get the proper results.

The only issue I’ve found is that there is no easy way to override the directories for where stylesheets and javascripts are stored. This basically makes stylesheet_link_tag and javascript_include_tag useless. Instead, you’ll have to hardcode the following into the head section of your application layout.

1
2

<link href="/assets/application.css" media="screen" rel="stylesheet" type="text/css" />
<script src="/assets/application.js" type="text/javascript"></script>

(Note: I actually started writing this over a week ago. I can probably rewrite some of it at this point, but I’m going to keep it written with the feel that I just got the phone a day or two ago.)

Before I became an iPhone user in early 2008, I was rocking the Treo for years. From the first day that I fixed a client’s problem via email while out to dinner, I was hooked on the idea of a Smartphone. This is obviously not a great thing for everyone, but in my particular line of work, it was indispensable. Not that the Treo was very smart.

The iPhone 1

The iPhone 1 was an amazing device, even in it’s terribly locked up state. This was the dark ages of no apps. If you wanted to do anything outside of the 10 standard applications on the phone, you had to jailbreak it, and install apps via Cydia. Being technical, this wasn’t a huge deal to me, but it was still pretty amazing when the App Store was released.

I work for myself, from home. There are a lot of positives about this fact… I have no commute, I have a lot of flexibility in my schedule, and the coffee is a lot better. But, it does have negatives as well. For instance, it could literally be days between the times that I leave the house. Since my job is software engineering, it also means I spend 8-10 hours a day at my desk, sitting in the chair, slowly shortening my lifespan.

My New Home

I’ve actually heard about the standing desk movement for a long time now, but never really gave it a lot of serious consideration. That’s partially due to be younger, I guess. Indestructible. But I’ve kind of made this my year to start considering some changes in my lifestyle – and sitting all day isn’t something I really need to be doing. I like my job, but I don’t really like that aspect of it.

When I reinstalled my system w/ Lion a few weeks back, I decided to start using Pow! as my “web server” of choice. I’ve been spending a lot more time in Rails over the past few months because of my day job and wasn’t really relying on my Apache/PHP installation as much. I delegated Apache off to port 8080 while Pow took port 80 over because it was just too convenient.

The way I’ve always done my PHP development was just dump my projects in subdirectories of the Apache web root (/Library/WebServer/Documents) and leave it at that. Most of my URLs would look something like: http://localhost:8080/some-project.

Today I was luck enough to come across this post in Assaf Arkin’s Lab Notes site: Using Pow with your Node.js project. Long story short is that it uses the fact that config.ru is actually a Ruby script and uses it to make a little proxy to connect to whatever node.js server/daemon that you happen to be running. It still requires you to start it up, but it’s pretty convenient to have it with the same URL scheme and port 80-ness of the rest of your projects.

I immediately decided to see if I could modify it to:

• Work on my port 8080 Apache install and
• Get it to automatically work with my subdirectory scheme.

First, I dropped an .rvmrc into my PHP project’s directory so I had a php specific gemset.

1
2

rvm_install_on_use_flag=1
rvm --create use 1.9.2@php

Then, I installed rack into that gemset.

gem install rack

I copied in my modified config.ru (which, incidentally has the path some-project hardcoded at the moment – I’ll clean it up later.)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

require "net/http"

class ProxyApp
  def call(env)
    begin
      request = Rack::Request.new(env)
      headers = {}
      env.each do |key, value|
        if key =~ /^http_(.*)/i
          headers[$1] = value
        end
      end
      http = Net::HTTP.new("localhost", 8080)
      http.start do |http|
        response = http.send_request(request.request_method, '/some-project' + request.fullpath, request.body.read, headers)
        [response.code, response.to_hash, [response.body]]
      end
    rescue Errno::ECONNREFUSED
      [500, {}, ["Server is down, try $ sudo apachectl start"]]
    end
  end
end
run ProxyApp.new

And lastly, symlinked my directory into my ~/.pow dir. Since I use powify, I just did a powify create to basically do the same thing.

Pointed my browser to http://some-project.dev and voila! I don’t see any visible slowdowns related to the proxy, and it works really nicely. It’s a keeper!

Wonderworks in Myrtle Beach is one of the neatest buildings I’ve seen in awhile. Basically a building constructed to look like it fell upside down on top of another one. The light was perfect, so I propped my arm on a handrail and grabbed a 2+2 stop HDR.

I think I’m starting to finally get an eye for where HDR really works. You really start to see where pictures that look great in your head that would never actually turn out if you took the picture. I think this falls into that category.

A couple of weeks ago, I stumbled on the Octopress project. It’s essentially a cleaned up framework around the Jekyll blogging “engine” that Github Pages uses (an my site). It gives it a clean HTML 5 template, some nice plugins, etc. Since it’s essentially just a pretty version of Jekyll, I knew that it would be possible to swtich with minimal work and saved it for when I was on vacation and looking for little personal projects to work on.

Switching was fairly simple. The only thing that really required work was porting over my post_filter code from my Jekyll fork. Basically, I added a bunch of hooks to Jekyll to allow me to run plugins before and after rendering, and after a page was written to the disk. Hooking into that allows me to do things like auto-post items to my archive blog, and send out bitly links to Twitter when something is posted.

Luckily, I’ve learned a lot about ruby since I wrote that stuff, and was now competent to do it with monkey patching the jekyll gem instead of having to keep a fork – which made it really clean. Once that was there, my other plugins started working immediately.

Since Octopress is just Jekyll under the hood, all of my other things worked without any intervention. My email-to-post script works, as well as my automatic Dropbox publishing stuff that I setup.

In fact, the only thing I had to fix was some formatting for a few posts that have code or gists embedded in them. I’m happy with my decision – now to just blog a little more and maybe customize the template a little bit.

Taken w/ Instagram

Taken w/ Instagram

The last piece of my new camera kit arrived today and I was eager to try it out. The AGL 3080 GPS Unit is a small device designed for geotagging your photos. When you’re head out on a photo walk, you flip it on, throw it in your bag and go about your business. When you get home and dump your pictures, you use special software to link the timestamps on the photos with the GPS “trail” of information and the photos are magically tagged precisely with where they were taken.

To do this magical feat, I use Jeffrey Friedl’s Geoencoding Plugin for Lightroom. However, this makes the process even more difficult. The reason for this is that the plugin wants the data in GPX format, which is XML based, and the AGL 3080 logs all of it’s data in NMEA format.

Luckily, there is a great command line utility called GPSBabel that will convert the files from a whole bunch of different formats into a whole bunch of other formats. As a bonus, GPSBabel is in Homebrew, so it was stupid easy to install.

So, this got me to thinking – it would be really sweet if I could plugin in the AGL, have it pull the files off automatically, convert them to GPX format, and unmount the device. I knew that it was all possible to do that in a shell script.

But, what would be really cool is if I could get it to it all automatically as soon as the AGL is plugged in. Even though I never used Folder Actions before, I had a vague idea that it was possible to fire a script or Automator workflow when a directory changes.

This was enough information for me to at least get started.

Taken w/ Instagram