Many people turned up their noses on the new 2015 Macbook specs. My first reaction was "skip", after reading the specs and trying the keyboard. Now, I'm loving it.

Looking for a new machine

The timing for the 2015 Macbook model was as right as it gets. My Macbook Air was almost written off, and I was looking for a new machine. Using a MacBook Pro at work, I was about to buy a beefy machine of that kind for myself. Enter the introduction of the new Macbook. Size and screen seemed tempting. But as a developer, can you deal with that rather slow CPU, a new kind of keyboard and a touchpad sans mechanical click?

Trying it out

In order to find out, I tried one in the Apple Store Hamburg Jungfernstieg. What a gorgeous little thing it was! Such a slim body. So lightweight. A brilliant 12" screen. Next, I tried the keyboard, and my sentiment flipped to the opposite. I could not really write on the keyboard. I missed keys, I pressed the wrong keys, I wasn't even able to touch type three consecutive words correctly. In my mind, I marked the 2015 Macbook as unsuitable for me.

Grieving about it

Yet, I could not get the compact form factor and the screen out of my mind. So I read reviews to find out if the new keyboard was something you could get used to. And indeed, reviewers had the same feeling as I did. The keys of the new keyboard have a lot less travelling distance while being pressed, so it takes some getting used to. But it's all fine after some weeks, they said.

Getting one

So, I put all my prejudice aside, and ordered one. Could this little beauty work for me?

The keyboard

Most important, the keyboard is great. It took a week or so to get used to it, but now I like it even better than the old Apple keyboard. In fact, keys on the old keyboard feel all wobbly and inaccurate once you get used to the new thing. After trying the keyboard for the first time, I thought "No way they can put this in their Pro line machines!". Now I'm thinking "I hope they'll put this in ALL of their machines!". That said, there is still room for improvement. I think Apple could increase key travel distance just a little bit on their thicker Macbook models. But the precision and larger surface area of the keys just feel great.

The trackpad

I did not even realize that there is no mechanical click. Force touch seems nice, but I'm rarely using it. No big deal compared to the previous trackpad.

The CPU

Performance is ok with the new Macbook. I have the 1,3 GHz version, and it's faster than my 2012 Macbook Air. That being said, I rarely had performance problems with my Macbook Air. I'm using the machine for software development, photo editing (Lightroom) and general tasks like web browsing, document editing etc. No issues so far.

The screen

What a gorgeous little screen! Finally retina resolution in a compact portable MacBook! Mirroring is visible, but negligible. You can even use it outside in good weather, as long as you keep in the shadows.

The battery

I only use the Macbook for a couple of hours each day, and I need to charge like every 3 days. Sounds legit. Charging works way faster than in my previous Macbook Air, but maybe that is because the battery was worn out.

The lack of Magsafe

I can live with it. On my desk, there's no danger of pulling the little thing off. Anywhere else I use it, I don't plug it in. Really, I thought this was a bummer, but until now, no big deal.

The lack of ports

I bought both the USB-C-to-USB-A adapter, AND the USB-C-to-USB-A/HDMI/USB-C adapter, throwing another 120 EUR or so at Apple. I don't even have use for HDMI, but I need to be able to plug in a hard drive and charge the machine at the same time, simple as that.

You have to know, I'm a hardcore laptop only user. I don't have any external screens, keyboards, mice or anything. Just the laptop, and I have everything I need to work. I once even gave a talk about it, although it is a bit outdated.

The lack of ports or card readers may seem disturbing at first, but I think it's a good thing. On the road, you rarely plug in anything but your headphones. And at home: Imaging plugging in just one port, just the one little thing, and being done with the stuff that most people have on their desks:

• power
• keyboard
• mouse
• external screen

It does not get more practical than this. If you are using an external screen, it can probably serve as an USB hub, too. This means no bigger mess on you desk than usual.

Conclusion

I don't regret buying the 2015 Macbook model. It really is a great little machine. You may want to wait for the next upgrade, which will probably provide a more capable CPU and bigger RAM. If you don't need a beefy CPU, you'll be just fine.

If you want to re-evaluate a computed property on a schedule, you need to depend that property on a property that changes over time. Turns out that creating such a property is fairly simple. This function triggers a change every second:

currentTimeMetronome: function() {
  var interval = 1000;
  Ember.run.later(this, function() {
    this.notifyPropertyChange('currentTimePulse');
    this.currentTimeMetronome();
  }, interval);
}.on('init'),

Computed properties can depend on the currentTimePulse to get re-evaluated every second:

currentTime: function() {
  var date = new Date();
  return date.toString();
}.property('currentTimePulse'),

The trick is to use Ember.run.later here. It receives 3 arguments, the last being the time (in ms) to postpone running the function in the 2nd argument. The first argument is the context the function should be run in.

You can apply the same pattern to functions, for example to poll APIs for new data:

App.IndexRoute = Ember.Route.extend({
  model: function() {
    var interval = 1000 * 60;
    Ember.run.later(this, function() {
      this.model().then(function(json) {
        this.controller.set('model', json);
      }.bind(this));
    }, interval);

    return Ember.$.getJSON('https://api.github.com/repos/emberjs/ember.js/commits');
  },
});

Check out this JSbin if you want to see a running demo:
Demo: http://emberjs.jsbin.com/xoriq/6
Code: http://emberjs.jsbin.com/xoriq/6/edit?js,output

UPDATE: Reader Dhruv Parmar pointed me to an article by Richard Livsey that shows how to "install" a clock inside your Ember app that is then injected into controllers, routes and the like. If you need a clock in multiple places, this is definitely the way to go. The downside of Richard's solution is using setTimeout(), which can be less efficient than Ember.run.later.

Few people are aware of the fact that openssl can encrypt files, and fewer can memoize the right command line arguments. This is why I added these two zsh functions to my ~/.zshrc:

encrypt () { openssl des3 -in $1 -out $1.encrypted }
decrypt () { FILENAME=$(echo $1|sed -e 's/\.encrypted$//g'); openssl des3 -d -in $1 -out $FILENAME }

Now encryption is just a matter of running encrypt secret.txt. Decryption assumes the file has an .encrypted suffix, so you run it like decrypt secret.txt.encrypted. Finally, encryption as easy as pie! :)

It's actually fairly easy to wrap any JavaScript object using Ember.Object. You just have to make sure that all manipulations to the wrapped object are going through the wrapper, e.g. using object.set(attribute, value) instead of object[attribute] = value.

So, how about wrapping localStorage, so you can bind to its properties from other objects? Here's an example:

Ember Starter Kit

You can find the Source Code in the JavaScript tab. In essence, the wrapper uses the unknownProperty and setUnknownProperty methods to sync the Ember.Object's attributes with the ones of the native object. That's pretty much all there is to it.

If you have trouble finding the templates, they are in the HTML tab.

Here's a Gist if you prefer to view it that way.

In order to install, you need to clone the repository, run make and copy the reptyr binary to some directory in your $PATH. Typical usage works like this:

• Start a long running process, e.g. top
• Background the process with CTRL-Z
• Resume the process in the background: bg
• Display your running background jobs with jobs -l, this should look like this:
  • [1]+ 4711 Stopped (signal) top
  • (The -l in jobs -l makes sure you'll get the PID)
• Disown the jobs from the current parent with disown top. After that, jobs will not show the job any more, but ps -a will.
• Start your terminal multiplexer of choice, e.g. tmux
• Reattach to the backgrounded process: reptyr 4711
• Detach your terminal multiplexer (e.g. CTRL-A D) and close ssh
• Reconnect ssh, attach to your multiplexer (e.g. tmux attach), rejoice!

I think reptyr is the perfect companion for tmux and should be installed on every Linux box, just like tmux.

Turning on History API in Ember is just the matter of switching an attribute. But on the backend side, your server does not know that incoming paths are meant to be interpreted by your Ember app, not by the server. In larger deploys with a load balancer, you can setup rules to redirect API traffic (e.g. paths containing /api/…) to the backend server, and other traffic to the asset server. But if you're using a smaller setup, like a Heroku deployed app, it's easier to fix right in the Rails app with the Rack::Rewrite gem, as long as you namespace your API. Here's how to do it:

First, add these two gems to your Gemfile and run bundle after that:

gem 'rails_12factor', group: :production # static file serving on Heroku
gem 'rack-rewrite' # for the actual rewriting

Then, add the following section to your config/application.rb:

config.middleware.insert_before(Rack::Runtime, Rack::Rewrite) do
  index_file = Rails.root.join('public', 'index.html').to_s
  send_file(/.*/, index_file, if: ->(rack_env) {
    rack_env['PATH_INFO'] !~ /^\/api.*$/
  })
end

This will direct all /api/… to the backend, all other paths are served by your Ember app in the index.html file. Static files will still be served, though, no matter the path.

This means that your JS app must be contained in the public folder of your Rails app. If you are using a build tool like Ember App Kit, this is easy to achieve:

grunt dist && rsync -av --delete dist/ ../backend/public

Run this from your JS app's folder, with ../backend/public being the path to your Rails app's public folder.

I hope you found this useful. :)

EmberJS mit Rails

EmberJS

• Opinionated JS Framework
• Wird verwendet von:
  • Yahoo
  • Netflix
  • Travis CI
  • Zendesk
  • Bustle
  • NBC News
  • Runtastic
  • Code School
  • Discourse
  • Ghost
  • Living Social
  • Vine.co
  • Harvest
  • Nest (gekauft von Google)
  • ...
  • Beispiel:
• Viele unabhängige Unternehmen, die mit Ember Apps schon heute Geld verdienen
• Qualität für den Produktionseinsatz bewiesen
• Weiterentwicklung sichergestellt, Ökosystem vorhanden

EmberJS

• Framework für Single Page Apps
• Aus einem Guss
• Convention over Configuration
• Man findet sich schnell zurecht
• Aus einem Guss
• In Ember sind zig Probleme, die einem als Entwickler begegnen, schon gelöst, z.B. Routing (State), Datei-Organisation, asynchroner Datenaustausch mit Assoziationen etc.
• Relativ groß
• Framework lock-in
  
• Verwendet eigene Getter/Setter
  • Unschöner als POJOs (object.get('attribute') vs. object.attribute)
  • Man bekommt dafür tolle Features und alles ist rock solid
  • Schneller und oft stabiler als Angular (das watcher/notifier verwendet)
  • Man kann alles mit Ember.Object wrappen, z.B. LocalStorage

EmberJS vs. Angular

• EmberJS:
  • "A framework"
• Angular:
  • "A framework to build frameworks"
  • "Angular isn't a framework; it's an HTML compiler"

Angular

• Klein (der Code selbst, Abhängigkeiten)
• Weniger Konventionen
• Macht weniger als Ember
• Viele Wege
• Google hat bis jetzt keine User-facing-App mit Angular entwickelt
• Angular 2.0 wird ein kompletter Rewrite, Kompatibilität mit aktuellen Anwendungen unbekannt
• Supportet Google nach Erscheinen von v2.0 noch 1.0, obwohl sie es selbst nicht nutzen?

Wie geht Ember?

Router

• State
• URL kopieren, Tab zu, URL pasten, alles wie vorher
• Sorgt dafür, dass Models verfügbar sind
• Unterstützt History-API ("/foo" anstatt "/#/foo")

Template

• Handlebars
• Wie Rails Views
• Schnurrbart-Platzhalter

Component

• Eigene HTML-Tags (naja, Web Components)
• Logik geschrieben in JS
• Viele vorgefertigte, z.B. für Formularelemente, Links…
• Können geerbt (angepasst) werden

Model

• Repräsentieren Daten
• POJOs, Ember.Objects, Ember Data…

Controller

• View-Controller (wie iOS, nicht wie Rails)
• Repräsentieren Daten, die nur für den View gebraucht werden
  • z.B. PostController#hasComments
• Repräsentieren nicht-persistente Daten, z.B. Panel expand/collapsed-Status

View

• Setzen DOM-Events in semantische Events um
• Z.B. Element in Viewport -> Formulardaten nachladen
• So selten wie weiße Raben

EmberJS mit Rails

• Datenaustausch mit JSON-Backend
• Backend-Seite: rails-api + active_model_serializers
• Frontend-Seite:
  • $.getJSON
  • Ember Data
• Token Based Authentication (z.B JWT)

Ember Data

• Definiert Models
• Austausch mit JSON-API
  • 
  • 
• Finding
• Persisting
• Metadata (z.B. Pagination)
• Für Dev/Test:
  • FixtureAdapter
  • Toll, aber hat Macken
• Real Thing: ActiveModelAdapter
• Anmerkung von Manuel Wiedenmann: Wenn man erst mal ohne Backend entwickeln will (zu empfehlen), der Fixture-Adapter aber Bugs hat, dann ist der Local Storage Adapter sehr zu empfehlen.

Build-Prozess

• Concat, Minify, develepment/production versions, cache busting…
• Backend und Frontend in einer App oder getrennt?
• Getrennt hat Vorteile:
  • UI-Entwickler brauchen keine Ruby/Rails-Installation
  • Entwicklung mit FixtureAdapter, Local Storage Adapter, API-Stub oder API-Staging-Server
• Mit Sprockets
  • Rails Asset Pipeline
  • Rake Pipeline
• Mit Grunt
  • Ember App Kit
  • Brunch etc.
• Mit Broccoli
  • ember-cli
  • Neuer offizieller Weg
  • Ergänzung für Grunt, kein Ersatz

Deployment

• Separate Apps empfehlenswert
• API-Namespace (z.B. "/api/v1")
  • 
  • 
• Load Balancer:
  • Alles mit "/api" auf die Backend-Server
  • Alles andere auf den Static Assets Host
  • Bei History-API: Alles ohne API im Pfad, das keine statische Datei ist, auf die index.html auf dem Static Assets Host
• Einfaches Deployment mit Heroku
  • gem 'rails_12factor', group: :production
  • dist bauen
  • ins public-Verzeichnis vom Backen syncen
  • rsync -av --delete dist/ ../backend/public
  • backend deployen
  • Nachteil: Backend-Prozess wird neu gestartet

Entwicklungsprozess

• Frontend-getrieben
• Fangt nicht mit der API an!
  • Die API passt nicht zum Frontend
  • Das Frontend passt nicht zum Product Owner und damit auch nicht zum Backend
• Erst mal nur Frontend machen
• Daten mit POJOs oder Ember.Objects repräsentieren
• Dann FixtureAdapter
• SO LANGE WIE MÖGLICH OHNE API/BACKEND !!!
• Nochmal: NICHT MIT DER API ANFANGEN!
• Dann API-Anbindung

SEO/Crawling

• Yahoo kann Ember (ein bisschen)
• Dünne HTML-Schicht zwischen JSON und Crawler (z.B. Discourse)
• Mit PhantomJS HTML generieren
• Externe Services
• NBCNews, Bustle etc. zeigen, dass es geht

Fazit

• Ember ist toll und ausgereift
• Ember Data ist ok bis gut, aber besser als alles andere
• Rails nur als API vereinfacht den Backend-Part enorm
  • Anzahl Gems/Plugins… (Prozessgröße)
  • Code-Komplexität
• Frontend-first erzeugt schnelleres Feedback
• Komplexer Frontend-Code sauberer als bei vielen Rails-Apps

This introduction to strace by Chad Fowler finally persuaded me to check out this little UNIX tool. I made several attempts in the past, but each time I attached it to a running process, I just saw, well, gibberish. And as no one else on my teams in the last years was fluent with strace, I kind of gave it up each time. But by reading that post, I learned that this gibberish is not that hard to read after all. In fact, it's pretty much straight forward and contains so much useful information that is hard to obtain otherwise. I can only guess how many times this knowledge would have helped me in the past.

Related: Introduction to lsof, a great companion to strace.

In the Rails world, we are holding up the DRY principle high. One outcome of this is that people do put stuff that has to be done for many applications into gems, to be reused. Authentication is such a case, as you need authenticaton for nearly every web application you write. And devise seems to be the most mature and poplular solution in this regard. Yet I decided to roll my own authentication for my latest project. Why?

Well, first of all, I am trying to get rid of all external dependencies, wherever possible. In my last project, we used 161 (!!!) gems. It was not a crazily complex project, just a regular, larger web application. But each and every gem has to be added to the load path, slowing down each and every require statement throughout the application. The led to server startup times of 15 seconds and above, depending on the machine. To make things worse, this time was needed for every launch of the Rails console, for every single isolated test you would run. That is just too much wrench in the works for me, so I absolutely wanted to avoid this in my new project. So, no dependency if I do not absolutely need it.

The next point, however, is simple "graspability". We all know source code is read far more often than written, so it should be easy for fellow developers to grasp what is going on. And although I like the devise source code, it is harder to grasp than code in your own application. First of all, people have to run bundle open devise to take look at the source. This is not really hard, but it is another obstacle. Next, the devise code is far more abstract than your own code. You can name your user model User, but you could also name it ChemistryTeacher. The same is true for your Controllers. Devise can handle that, which is great! But this flexibility comes at a price, and that is the brainpower needed to understand how the code works. This problem becomes worse, as soon as you want to change some of the behaviour. Instead of just writing or adjusting the tests and implementing your code, you must go to great lengths to to find out how to hook into the existing gem code from your application. And the result? Not very satisfying. Some of the behaviour is defined in the gem, some in your application. Scattered in two places. Making graspability even harder.

My last point of criticism is bloat. Devise is very powerful, and certainly offers stuff I do not need. I just want session management and password reset. Yet the code for all the other stuff devise has to offer is loaded into memory when I require the gem. While this is negligible for a single gem, memory consumption becomes insanely high for each Rails process when you are using 161 gems.

Luckily, Rails 3.1 was out when I started on the new project, and this version introduced the has_secure_password method in ActiveModel. When I saw this in Ryan Bates Railscast, it immediately clicked. For me, that is the least common denominator, the one thing that is the same for each and every application. I do not need a gem to define my controllers, because I will want to change their behaviour anyway, at some point of time. But what has_secure_password does, that is the one thing I will need anywhere.

So I just ditched every authentication gem out there and just went to write my own authenticaton. The process was smooth and easy, and in about a day of purely test driven development, I had a nice and easy to grasp authentication process inside my own application, with password recovery and everything else I need. And as soon as I or anyone else on the team wants to change the logic, she or he can just open their test and app folders and go for it. So in my opinion, it is absolutely worth trying.

So, what is your experience with authentication in Rails apps? Ever tried to roll your own? Would you do so in your next project?

So in order to create the scopes for all the classes, I created the following module, which is included in all the classes needing the scope:

# app/models/shared/customer.rb
module Shared
  module Customer
    extend ActiveSupport::Concern

    included do
      scope :for_customer, ->(customer) do
        where(:customer_id => customer.to_i)
      end
    end
  end
end

# app/models/user.rb
class User < ActiveRecord::Base
  include Shared::Customer
end

This scope helps already, but in the end I want to do the following in my controllers:

@users = customer.users.all
@user = customer.users.find(params[:id])
@user = customer.users.new(params[:user])

So for each model including the shared customer module, I need to create a scope like that:

# app/models/customer.rb
class Customer
  def users
    User.for_customer(id)
  end
end

That seemed like to much work for me. I mean, we are using Ruby, and I do not want to do boring routing stuff. So I created the following magic which frees me of the task to create this association method by hand for nearly each and every model:

# app/models/shared/customer.rb
module Shared
  module Customer
    extend ActiveSupport::Concern

    included do |base|
      scope :for_customer, ->(customer) do
        where(:customer_id => customer.to_i)
      end

      Customer.class_eval <<-EOS
        def #{base.tableize}
          #{base}.for_customer(id)
        end
      EOS
    end
  end
end

No more routine work, wheeeee! One might think. But of course, this code is causing problems. First of all, the load order matters now. If we log into rails console and try calling the users method on a customer object, we will be out of luck. This is because the Customer class by itself does not know that there might be another class putting code into the Customer class at some later point of time. And requiring all the classes by hand would make a mockery of the whole automation idea, plus it does not look very clean. This is not a problem in the production and test environment, because all the models get loaded there. But it will definitely fall on your feet while you are developing stuff, trust me.

The other problem is readability: How the heck is someone reading the Customer class supposed to know where the association comes from? And if she/he finds out after 2 hours, do not be surprised if she/he shouts death threats in your direction. So in the end I abandoned the whole idea, and settled for something else. I just created a new concern for the customer class, taking care of the associations.

# app/models/customer/associations.rb
class Customer
  module Associations
    extend ActiveSupport::Concern

    module ClassMethods
      def associate_with(*item_names)
        item_names.each do |item_name|
          method = -> { item_name.to_s.classify.constantize.for_customer(id) }
          define_method(item_name, method)
        end
      end
      private :associate_with
    end

    included do
      associate_with :users, :pizzas, :schnitzels
    end
  end
end

# app/models/customer.rb
class Customer
  include Associations
end

As you can see in the snippet, I still have to add each class that needs to be associated with Customer to the associate_with macro. But I can live with that. It's the best solution I could find, finally. Adding a word to the macro ain't too hard, and you can easily find the source of the association.

Plus, this code looks very clean to me. Classes should not know too much of each other, they may share data internally, but they ought to have a well defined interface externally. So a class walking over to another class, modifying its interface, that's just not very clean.

Conclusion:

Use metaprogramming to free yourself from routine programming tasks and to create clean and concise code. But don't be too clever, and always think about the readability of your code. Because, remember, kids: Code is read much more often than it is written.

Conclusion 2:

Discussing stuff with other developers (Lee in this case) will make you a better programmer, in the end. Heck, it's the reason why I'm bloggind this!

The first thing to do, is to check whether the module you're looking at should be split up into several classes. Those classes don't necessarily have to inherit from ActiveRecord::Base, they might as well be regular Ruby classes. For example, if you are doing a lot of radius calculations in your Search model, you might as well add a new Radius class that does all the hard calculation work for you and can be tested in isolation.

But if you think that all the methods and macros belong into one class, you can still use modules to modularize different concerns into their own files. Doing this is easy, since we have ActiveSupport::Concern in Rails 3.

Example:

# app/models/user/authentication.rb
class User
  module Authentication
    extend ActiveSupport::Concern

    included do
      has_secure_password
    end

    def create_password_reset_token
      token = SecureRandom.base64.tr('+/=lIO0', 'zomglol')
      self.update_attribute(:password_reset_token, token)
    end
  end
end

# app/models/user.rb
class User < ActiveRecord::Base
  include Authentication
  include Validations
  # ...
end

As you can see, we have put all authentication related methods into their own module, so this module encapsulates the authentication concern.

A little explaination: Extending the module with ActiveSupport::Concern enables the magic that makes writing modules so much easier. The first aspect of this is the included block, that will be run in the context of the class including the module. So it is perfect for validations or acts_as_something style macros. You can even pass in the base class (class including the module) if you use the inlcuded do |base| syntax instead, if you need to.

The create_password_reset_token method gets included into the base class, as ususal. But if you want to include class methods as well as instance methods, you can create a separate module for the ClassMethods inside the Authentication module. You would have to call it ClassMethods, so that ActiveSupport::Concern can find it and do the right thing. The ClassMethods module will be extended into the base class, which means that these methods will act as if you wrote them with def self.method_name.

So what are the hard parts? Of course it is naming things, and deciding where to put stuff. First, I created a folder called user_extensions to hold my concerns for the User class. I did not particularly like this, because I wanted to apply the same conventions that are valid in gems, which is the folder should have the same name as the class. Then I moved on to naming the folder the same as the class file and adding the _extension suffix to each of the module files, until realizing that this is useless. Even if there is a name clash, like an Authentication class somewhere else, our module will be picked up first, because it lives in the namespace of the User class. The downside of this is that you have to address the other Authentication class (if it exists and you need to use it in the User class) with ::Authentication, but I can live with that, as it is a rare case. So no more name clutter, just the stuff that is important.

Your test names and folder structure should mimic the ones of the tested classes and concerns. So I have separate unit tests for each of the concerns. Test class names mimic the ones of the classes, so the User::AuthenticationTest tests the behaviour of the User::Authentication module. And of course the test is placed in test/unit/user/authentication_test.rb.

By the way, at the moment I am the only developer on my current project, so I enjoy the occasional developer chat. The above evolved after talking to Thorsten, Lee and Mathias. Thanks for your opinions, guys!

curl -O http://files.rubyforge.vm.bytemark.co.uk/ruby-debug19/linecache19-0.5.13.gem
curl -O http://files.rubyforge.vm.bytemark.co.uk/ruby-debug19/ruby-debug-base19-0.11.26.gem
gem install {linecache19-0.5.13.gem,ruby-debug-base19-0.11.26.gem} \
  -- --with-ruby-include=$rvm_path/src/`rvm current | sed 's/@.*//'`

Or, if you do vendor your gems with bundler, use the following:

curl http://files.rubyforge.vm.bytemark.co.uk/ruby-debug19/linecache19-0.5.13.gem \
  > vendor/cache/linecache19-0.5.13.gem
curl http://files.rubyforge.vm.bytemark.co.uk/ruby-debug19/ruby-debug-base19-0.11.26.gem \
  > vendor/cache/ruby-debug-base19-0.11.26.gem
bundle config build.ruby-debug-base19 \
  --with-ruby-include=$rvm_path/src/`rvm current | sed 's/@.*//'`

You can also find this as a gist.

You will see that the presentation is actually a website. It was done using ShowOff and works best in fullscreen capable browsers like Google Chrome. The source code of the presentation can also be inspected on Github.

In order to explain my reasons, I have assembled a list that compares the possibilities of native iPhone development using Objective-C with web development.

Just counting the yes and nos, there is no clear winner. Of course, this list is 100% objective and complete. If you have anything to add, against all expectations and common sense, please leave a comment.

Update: This blog post by 37signals sums up my feelings about Apple pretty well.