Hi, I'm Benedikt Deicke, and I'm a freelance web and software developer. I'm mainly building user focused web applications using Ruby on Rails and JavaScript. Additionally I'm currently studying for my master's degree and enjoying photography in my spare time. Feel free to get in touch with me, I'm available for hire!

June 24th, 2010
Multitouch Inspector for iPad

During the last couple weeks I’ve been playing around with the iPad and Mobile Safari. I built a little tool to familiarize myself with the Multitouch JavaScript API provided by Mobile Safari as well as web applications for the iPad in general. I named the result Multitouch Inspector because that’s what it does: Inspect the TouchEvents fired by the JavaScript API. ;-) Today I decided to rewrite the tool to drop the dependency on Prototype.js and I published it on GitHub.

Using Multitouch Events from JavaScript

There are four events that are related to touch: TouchStart, TouchMove, TouchEnd and TouchCancel. I’m not sure about what situation would trigger TouchCancel so I decided to skip it for now. Working with the touch events is straight forward:

   1  document.addEventListener('touchstart', function(event) {
   2    /* Do whatever you'd like to do with the event */
   3  }, false);

Of course you can add the listener to any element just like you would with Click or MouseOver events. The function gets passed an object of type TouchEvent. There are several properties on this object, but the most interesting ones are touches, changedTouches and targetTouches. They all are of type TouchList and contain several Touch objects. The touches property lists all touches currently on the screen. The changedTouches list contains the touches that changed and caused the event to fire. The touches in the targetTouches list are those that are currently within the target element.

Every Touch has an identifier property as well as pageX and pageY properties. As you might have guessed already, the pageX and pageY properties include the touch’s position on the screen. The identifier property provides an unique integer for this touch. It stays the the same for this touch as long it is on the screen. This is particularly useful as removing one finger will trigger a TouchEnd event that implies that all fingers were removed, immediately followed by a TouchStart event including the remaining fingers. Luckily the identifier property stays the same for those fingers that weren’t removed from the screen.

Offline Application Caching

In order to use the application without having an active internet connection or simply while the development server isn’t running I’m using HTML5 Offline Application Caching. It works by defining a manifest file and referencing it in the html-tag:

   1  <!DOCTYPE html>
   2  <html manifest="application.manifest">

The manifest file itself looks like this and defines what files are required to view the application while offline:

   1  CACHE MANIFEST
   2  
   3  # c94640e9114e05f16e189605e5b65ba2357117712c949cae92cc29bc1bbd3c47
   4  /images/background.png
   5  /images/icon.png
   6  /index.html
   7  /javascripts/application.js
   8  /stylesheets/application.css

You might wonder about the random string at the top. As the browser will reload everything when it can’t find one file in it’s cache, I’m using this string to force a reload during development. I built a small Sinatra app (see the listing below this paragraph) that generates the manifest and resets this string for every request. As a result, the browser reloads everything while online but falls back to the cached files when offline.

   1  require 'sinatra'
   2  require 'digest/sha2'
   3  require 'pathname'
   4  
   5  # ...
   6  
   7  get '/application.manifest' do
   8    content_type 'text/cache-manifest'
   9  
  10    manifest = "CACHE MANIFEST\n\n"
  11    manifest << "# " << Digest::SHA2.hexdigest(Time.now.to_s + Time.now.usec.to_s) << "\n"
  12  
  13    root = Pathname.new(settings.public)
  14    Pathname.glob(File.join(root, "**", "*")).each do |p|
  15      manifest << "/" << p.relative_path_from(root) << "\n" if p.file?
  16    end
  17  
  18    manifest
  19  end

Issues

There are some issues that I couldn’t resolve while building the application. The startup image will only work while in portrait orientation and its dimension has to be exactly 1004×768. Currently there isn’t a way to define a startup image for horizontal orientation.

While the tracking of the touches works on the iPhone (with iOS 4.0) as well for some reason it isn’t possible to press the buttons in the toolbar. At the moment I have no explanation for this rather strange behavior, but I might take another look at it in the future.

Screenshot & Demo

Now that you have some insights on the internals of the application, here’s a screenshot as well as a link on it to a demo:

Fork it on GitHub

I published the source code on GitHub. Feel free to fork it!

Further reading

  1. Safari Web Content Guide: Handling Events
  2. Making an iPad HTML5 App & making it really fast
Posted by benedikt – Filed in Articles, Javascript
0 comments

August 8th, 2008
HowTo: Phusion Passenger aka mod_rails for Apache

Yesterday I decided to give Phusion Passenger aka mod_rails a try and installed it. It was dead simple to set it up and to deploy rails applications with it. I’m now using it for several “small” applications, for which the whole overhead of setting up a cluster of mongrels and a proxy doesn’t seem to be adequate. I’ll give you a short summary on how to install mod_rails for apache2 on Debian Etch.

First, install the passenger gem using RubyGems (if you don’t have Ruby and RubyGems running on your server, install them first – of course):

   1  gem install passenger

Afterwards, run the passenger apache2 module installer using this command:

   1  passenger-install-apache2-module

It’ll check for the required software to install the module, compile it and copy it to the correct folders. If some software is missing install it using aptitude (ie. aptitude install g++ if you’re missing the GNU C++ Compiler).

Next, create two new files in the /etc/apache2/mods-available directory. One called mod_rails.load:

   1  LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.0.2/ext/apache2/mod_passenger.so

... and the other one called mod_rails.conf:

   1  PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.0.2
   2  PassengerRuby /usr/bin/ruby1.8

Now you can enable the module using a2enmod and restart apache.

   1  a2enmod mod_rails
   2  apache2ctl restart

That’s it! Now simply deploy your rails application, just make sure apache’s document root is pointing to your applications public folder. Passenger will automatically detect your rails application and start up processes as needed. You can check it’s status and stats using the passenger-status and passenger-memory-stats commands. For more details on mod_rails, take a look at it’s documentation.

Posted by benedikt – Filed in Articles, Linux, Ruby, Ruby on Rails
0 comments

August 4th, 2008
My day-to-day resources on Ruby and Rails

News

I try to keep up with Ruby and Ruby on Rails, even if I’m not working with one of them at the moment. These are the three feeds helping me to get the latest news:

PlanetRubyOnRails.com, not to be mixed up with PlanetRubyOnRails.org, is a simple feed aggregator with a set of quite informative blogs. Including the official Riding Rails Blog, Ruby Inside, and InfoQ. Unfortunately it doesn’t provide an RSS-Feed anymore, but thanks to Feed43 it’s easy to build one on your own.

Every Wednesday Gregg Pollack and Jason Seifer of Rails Envy publish their Rails Envy Podcast, covering last week’s most important topics in the Ruby and Rails community. They’re giving a short summary for every topic, together with a link in their shownotes and usually are fooling around. The podcast’s length is usually between 10 to 15 minutes.

RubyOnRails-Ug Planet

Just like PlanetRubyOnRails, the planet of the german ruby on rails usergroup is a feed aggregator, except it includes blogs of members of the german Ruby on Rails community. (Yes, mine too …) Its far from being as active as the international one, but usually includes interesting posts.

Documentation

When I’m working on Ruby and Ruby on Rails code, I use there resources to quickly look up documentation:

Ruby-Doc.org provides the documentation for both Ruby’s Core and Stdlib. The documentation is in the default RDoc format, so I usually end up hitting [Strg]+[F] and using my browsers search function to quickly get to the relevant sections.

api.rubyonrails.com

What Ruby-Doc.org is for ruby, api.rubyonrails.com is for rails. It’s the standard rails documentation in the default RDoc format. As with Ruby-Doc.org I use my browsers search to quickly find what I’m looking for.

Rails-Doc.org is a quite new site providing the full rails documentation. Unlike the default API documentation site (see above) it also includes documentation of older rails versions. Additionally it has a nice search engine, and adds the ability to post notes. There are other sites providing similar functionality for the rails documentation, but somehow Rails-Doc.org just feels right and I’m using more and more.

Gem Server

Did you know the fabulous RubyGem-Tools provide a server including the documentation for all your installed gems? Simple run gem server on the console, fire up your browser and navigate to http://localhost:8808. Okay, it’s just the standard RDoc documentation for each gem, without any fancy search or anything … but who cares if you’re somewhere in the middle of nowhere with no internet connection? :-)

Other

Last but definitely not least, are the RailsCasts by Ryan Bates. Every Monday he publishes a approx. 5 to 10 minute screencast on a variety of topics related to rails development. If you haven’t seen one of them yet, don’t hesitate any longer. Ryan’s explanations are concise and based on practical examples.

What are your resources on Ruby / Rails? Which blogs are you reading to stay up-to-date? Which documentation are you using? I’m interested in your comments (there are way to few anyways … ;-))!

Update (Aug 15.)

Nodeta, creators of Rails-Doc.org, released APIdock yesterday. APIdock extends the Rails-Doc.org concept to multiple projects. Currently Rails, Ruby and RSpec are included.

Posted by benedikt – Filed in Articles, Ruby, Ruby on Rails
0 comments

April 10th, 2008
Using RSpactor with Linux

Andreas Wolff recently released RSpactor, a (up to now) command line tool similar to autotest. Nevertheless it differs from autotest in two points. First it’s focused on RSpec and secondly it’s using Mac OS’ FSEvents to monitor file changes. According to this it only runs on Mac OS. To get it running on Linux you’ll have to change RSpactor’s Listener class to use Linux’ equivalent to FSEvents called inotify. Luckily there’s a gem called RInotify which introduces a simple class to access the inotify events within ruby. I rewrote the Listeners class yesterday to get it running on my Linux notebook:

   1  # inotify_listener.rb
   2  
   3  class Listener
   4  
   5    def initialize(&block)
   6      require 'rinotify'
   7      begin
   8        @spec_run_time = Time.now
   9        @watching      = {}
  10  
  11        notify = RInotify.new
  12        Dir.glob(File.join(Dir.pwd, '**')).each do |dir|
  13          watch_desc = notify.add_watch(dir, RInotify::MODIFY | RInotify::CREATE | RInotify::DELETE)
  14          @watching[watch_desc] = dir
  15        end
  16  
  17        while true do
  18          changed_files = []
  19          notify.each_event do |event|
  20            changed_files << build_path_from_event(event)
  21          end
  22          changed_files.uniq!
  23          unless changed_files.empty?
  24            @spec_run_time = Time.now
  25            yield changed_files
  26          end
  27          sleep(5)
  28        end
  29      rescue Interrupt
  30        @watching.each_key { |key| notify.rm_watch(key) }
  31      end
  32    end
  33  
  34    def build_path_from_event(event)
  35      File.join(@watching[event.watch_descriptor], event.name || '')
  36    end
  37  
  38  end

To get it running you simply have to install the RInotify gem and change one line in bin/rspactor:

   1  # from
   2  require File.join(File.dirname(__FILE__), '..', 'lib', 'listener')
   3  # to
   4  require File.join(File.dirname(__FILE__), '..', 'lib', 'inotify_listener')

That’s it! RSpactor should be running on Linux now and consuming much less CPU than autotest.

(You might also want to change the system()-call in lib/resulting.rb as it’s currently using growl to notify you about the test results.)

Posted by benedikt – Filed in Agile Development, Articles, Linux, Ruby, Ruby on Rails
0 comments

March 29th, 2008
Easy SSH authentication with keychain

Typing SSH passwords again and again can be a real pain. For example: Lately I started to use Capistrano to deploy my rails applications. If I want to set up the maintenance-page on the server I’ll type cap deploy:web:disable which of course prompts me for the SSH password. Then I want to deploy my application with cap deploy and again will be prompted for the password. Finally I have to cap deploy:web:enable to remove the maintenance page which – as mindful readers might have guessed already – prompts for the password. This was just one reason for me to set up SSH authentication keys. At first I was a little worried that setting it up might be a bit complicated. Luckily I was disabused. If you want to switch to key based authentication too follow these simple steps:

Key generation

The first thing you need is – of course – a pair of keys: your private key and the associated public key. To generate both fire up our favorite shell (for me it’s bash) and type:

   1  ssh-keygen

This will generate both keys and ask you where to store it. Usually the default would be something like ~/.ssh/id_rsa. Simply accept the default by pressing return. Next you’ll have to enter a password for your key and confirm it. Afterwards you’ve to tell the server to accept your key on authentication. Do so by uploading the public key to the server.

   1  scp ~/.ssh/id_rsa.pub yourserver.com:~/.ssh/authenticated_keys2

If you want to add multiple keys, be sure to append it to the authenticated_keys2 file and don’t overwrite it.

First login

That’s all you have to do to switch to key based SSH authentication. Try to log in as usual by typing:

   1  ssh yourserver.com

This will prompt you for your key’s password and log you in to your server afterwards. “But wait! I’m still having to type my password every time I want to log in!” you shout, and you’re right – up to now. What you need to do is running ssh-agent, adding your key and typing your password. ssh-agent will then ask for the password and store it until you shut it down. You’ll have to do this everytime you open up a new shell or put the commands into your i.e. ~/.bash_profile. Quite comfortable but we can do better.

Keychain

There is a nice little tool called keychain that will smooth the process a little for you. It’s originally developed by the Gentoo people but it’s available on other linux distributions (as well as Mac OS X), too. Simply install it by typing your system’s equivalent to

   1  # Gentoo
   2  emerge keychain
   3  # Debian
   4  aptitude install keychain

and it’ll be available in no time. To set it up you need to put these two lines in our ~/.bash_profile:

   1  keychain ~/.ssh/id_rsa
   2  source ~/.keychain/$HOSTNAME-sh

That’s it. The first time you open up a shell keychain will start ssh-agent, prompt you for your keys password and remember the running ssh-agent for all new shells. On your next SSH authentication no more password typing is required. Wasn’t complicated at all, was it?

Update: Thanks to Michael for pointing out that the public key file is named id_rsa.pub instead of id_rsa. Fixed it.

Posted by benedikt – Filed in Articles, Linux
1 comment