This closes an important gap to testing in a real browser (like with Selenium) and now gives us much more confidence in our tests - we now not only know that our models and controllers integrate, but we also know that they work with our views. That had been an unpleasant problem for a while. All our tests were passing but we still had way too many problems with invalid links and forms submiting to the wrong action. No more.

Webrat provides a sort of DSL (everything is a DSL nowaday isn’t it? ) for interacting with all the HTML elements you would find in a HTML document like links, checkboxes, radio buttons, text fields, selects and submit buttons. A test case might look like this:

Webrat now fetches the start page of the application, parses it and follows the first link labelled with “Sign Up”, gets the corresponding page, parses the form, fills in the values and submits it. Whenever a response comes back with anything else than a 200 (or 302, in which case that redirection is followed automatically) or an element on the page can’t be found, Webrat complains with an error and you know there’s probably something wrong in your view.

In Order to get this working with Story Runner I have wrapped most calls into When calls, for example:

And now my Story looks like this:

I’m not sure yet if it makes sense to release those wrappers as a plugin, we’ll see. After all it’s just a few lines of trivial code.

By the way, Webrat is hosted on awesome github, so after using it for 30 minutes (seriously) I forked my own version and added support for the Rails date helpers (selects_date Date.today, :from => 'signup_date' instead of selects 'December', :from => 'signup_date_2i'; selects '2008', :from => 'signup_date_1i'; selects '01', :from => 'signup_date_3i') and Emails (e.g. clicking the activation link in a signup email). (Bryan Helmkamp, if you read this: Why haven’t you pulled this (and in fact any other fork) into the main line yet?)

All in all the experience has been fantastic. Webrat is on all my Rails projects now. The only - conceptual - problem so far is that I can’t use it to test AJAX. But that’s the topic of another post. And there’s a fork on github that experiments with celerity, which can do AJAX and everything.

Ich kann arbeiten wo wo ich will.

Ich kann arbeiten mit wem ich will.

Ich kann arbeiten woran ich will.

Ich kann mir meine Kunden aussuchen.

Ich kann arbeiten womit ich will.

Ich kann arbeiten wie ich will.

Ich kann mir mein Büro aussuchen und einrichten wie ich will.

Ich kann mir aussuchen, wieviel Geld ich verdienen will.

Ich lerne jeden Tag mehr dazu, weil ich nicht nur Programmierer, sondern gleichzeitig noch Projektmanager, Geschäftsführer, Administrator, Sales-Fuzzi und sonstwas bin.

Um das mal zusammenzufassen: ich habe die freiheit zu tun was ich will. Und wenn ich irgendwann mal keine Lust mehr habe kann ich mich immer noch anstellen lassen. Oder nach Hawaii gehen. Darum.

(Hab ich noch was vergessen? Kommentare…)

It’s just a short period of time but we’ll try to get the most out off it. We got in contact with the local ruby user group, starting off with a couple of beers on sunday and hopefully exchanging some great wisdom. Maybe we can also initiate a speaker exchange with the berlin ruby user group.

Thanks to shortcut who have been kind enough to let us stay at their office for the week, we are mighty excited to get a glimpse on their work culture. And in the evenings and weekends we will surely check out the vicinity of Oslo.

I’m sure this will be cool work holidays If anyone in Oslo wants to meet us just send an email. We’ll also be posting some photos once we’re there.

Während der Planung der ersten Iteration haben wir zusammen mit dem Kunden User Stories geschrieben, um sie anschließend direkt in den RSpec Story Runner zu werfen, also As a User I want to upload my photo So that everyone can see my smiley face. Da unsere Kunden deutsch sprechen war das Meeting und dementsprechend auch die Stories auf deutsch, also Als Benutzer will ich mein Foto hochladen können damit alle mein tolles Grinsegesicht sehen können. Damit der Story Runner damit umgehen konnte mussten wir ihm eine neue Sprache beibringen. So geht’s:

In diesem Ticket gibt’s einen Patch für den Story Runner, womit die Schlüsselwörter in den plain text stories konfiguriert werden können. (Wer wie ich mit Kommandozeilenpatchen nicht klar kommt, TextMate hat ein schönes Diff Bundle mit dem man den Patch auf einen RSpec (z.B. 1.1.4) checkout anwenden kann).

Die Konfiguration kann dann einfach in der stories/helper.rb landen:

Was diesem Patch allerdings noch fehlt ist die Übersetzung der zu jeder plain text gehörenden steps. Man füge einfach noch folgendes Snippet mit ein:

Und schon kann man seine Stories auf deutsch schreiben (sorry das Beispiel ist irgendwie grauenhaft sinnlos, es ist schon spät):

Und dann in den zugehörigen steps:

Ach ja, one more thing: Um im Story Runner so eine Art setup/teardown zu haben, einfach noch ein wenig Code in den helper:

Here are some things that change in rails you shold be aware of.
If you are using custom callbacks for you rails observer you now have to tell rails about these callbacks first. Simply add a define_callbacks :your_callback, :your_other_callback in models with custom callbacks.

The call to register custom template handlers in the enviroment has changed from ActionView::Base.register_template_handler to ActionView::Template.register_template_handler. With a custom handler you can output pdfs for example.

Consequently the ActionController::MissingTempalte Error was moved to ActionView::MissingTemplate.

With the new Caching in place the config call changed from fragment_cache_store to cache_store to reflect the new unified caching infrastructure.

If you have included the Observable mixin in one of your ActiveRecord models, like we did before we learned to harness the power of ActiveRecord::Observer, it’s time to abandon these because the changed method overwrites the new changed of ActivRecords dirty tracking. So if your stack trace look similar to this…

.. it’s Observable overwriting the ActiveRecord changed method.

What also comes with dirty tracking is, that a save call does nothing unless someting really changed. Although this is the desired behavior, it might break logic where you rely on the old behavior, e.g. when you just want to update the time stamps of an object in the database. You can tell the object with attr_name_will_change! that an attribute should be written to the database.

Another ActiveRecord change we found is that :dependent => true isn’t supported anymore although I don’t remember a deprecation warning. Just use :dependent => :nullfiy|:delete|:destroy.

But now let’s come to some nice stuff we discovered.

ActiveRecord now complains with a stack level to deep if you have circular dependency behaviors defined, eg. User has_one :profile, :dependent => :destroy and Profile belogs_to :user, :dependent => :destroy. Such logic can just be the result of isolated late night coding, so an error is the desired behavior in my opinion.

Let’s get back to the aforementioned changed method. Because it returns an array of changed field names, it is a good way to fire after save actions only if a specific field changed. For our autoki application it is a good way to fire some image processing task only if the auto picture changed.

At the end comes the real nasty stuff. Rails 2.1 really wrecks havoc under the plugins we are using. As you might guess the most have to do with caching.

While the fragement_cache_test plugins error uninitialized constant ActionController::Caching::Fragments::MemoryStore can be fixed relatively easy by changing the base class for the TestStoreclass in frament_cache_test.rb to ActiveSupport::Cache::MemoryStore and the calls to reset have do be changed to clear the timed_fragment_cache plugin and the extended_fragment_cache are rendered useless until updated, which we don’t expect to happen, so we put together the local_cache_plugin as a resplacement for both.

Will_paginate requires an update from git, and it will play nice again. It resides on github now and can be installed with script/install git://github.com/mislav/will_paginate.git thanks to the install script git support.

The paginated search plugin for ferret will require an update too, because of the changes in will_paginate. But it’s still maintained so just grap the new code from the opensoul blog.

So that’s all for now. (Wow this post got big)

We aren’t finish yet so we will post more while we find other noteworthy changes.

|----------------------------------------------------|
| id | name                | is_company | is_project |
|----------------------------------------------------|
| 1  | google              | 1          | 0          |
| 2  | world domination    | 0          | 1          |
|----------------------------------------------------|

In my rails app I created two ActiveRecord models: Company and Project and set the table name for both to organizations:

Now the real problem was his: when I did a Company.find :all I got all the companies and all the projects, so I had to do this instead: Company.find :all, :conditions => {:is_company => true} - throughout the project, and whenever I forgot the condition somewhere all the projects showed up in the wrong place. So what I needed was a generic solution.

To make a longer story short I played with scope_out defining a projects scope on the Company model, so I could at least do Company.find_all_companies and didn’t have to specify the conditions over and over again - but that still wasn’t DRY at all. One morning short after waking up (the time I usually have the best ideas) it dawned on me how simple the solution actually is:

I added a scope around all find and count calls of my model and now I can just do whatever find operations I want and don’t have to think about scopes and tables ever again. Sweet object encapsulation.

The exec summary: you can declaratively add permissions to your (ActiveRecord) models for creating, viewing, updating and destroying them. A set of before filters automagically checks all incoming requests on your restful controllers for the permission and grants or denies access based on the permissions declared on the respective model.

How to install

Now with Rails 2.1 out all you have to do is script/plugin install git://github.com/langalex/totally-restful-authorization.git.

How to use

Include he PermissionCheck Module into the controllers you want to be checked or simply into the ApplicationController to secure your entire application.

Second, declare permissions on your model using the built in domain specific language.

That’s it. From now on all requests will be checked against your model permissions and be blocked if the authorization fails. For more details see the README and the unit tests. (Btw. if anyone has a good idea on how to replace the controller tests with RSpec specs, i.e. get controller specs working in a plugin please tell me)

Zuerst schauen wir uns mal an welche Werkzeuge MySQL von Hause aus mitbringt, um beim Erstellen von sinnvollen Indizes zu helfen.

Mit EXPLAIN vor einem SELECT in der MySQL Shell lässt sich erst einmal herausfinden, wie einzelne Abfragen ausgeführt werden. So lassen sich gut Informationen über verwendete und fehlende Indizes sammeln. Das Ergebnis von EXPLAIN wird standardmäßig als Tabelle ausgegeben. Hier kurz was die Angaben bedeuten. Die Spalte table gibt den Namen der abgefragten Tabelle an. Unter type steht die Art des Lesezugriffs. Steht dort ALL wird ein Table Scan durchgeführt. Unter possible_keys stehen die Namen der verfügbaren Indizes. Die Spalte key enthält die bei der Abfrage verwendeten Index. Es kann nur ein Index verwendet werden. Unter extra stehen die Einschränkungen nach denen die Zeilen ausgewählt werden. Steht unter type ALL, aber in den Bedingungen ‘using where’ fehlt mit Sicherheit ein geeigneter Index. Ein Grund, warum selbst ein vorhandener Index nicht verwendet wird, ist, dass die WHERE-Bedingung zu weit gefasst ist. Unter diesen Umständen ist die Verwendung eines Indizes aufwendiger als ein Table Scan. Ein gutes Beispiel für eine zu weit gefasst Abfrage ist, alle Frauen aus einer Nutzertabelle zu laden, da etwa die Hälfte aller Nutzer Frauen sind, ist der Aufwand für den Einsatz von Indizes viel zu groß und wird daher von MySQL ausgeschlossen. Als Richtwert gilt, wenn 20% oder weniger Zeilen durch eine Bedingung erfasst werden ist der Einsatz eines Indexes sinnvoll. Oder anders herum gesagt, ein Index sollte eine gute Selektivität besitzen. Mit EXPLAIN tablename lässt sich herausfinden, welche Spalten einer Tabelle bereits mit einem Index versehen sind.

Aber nicht nur die Selektivität eines Index ist entscheidend, denn jeder Index kommt zu dem Preis, dass er bei einer Änderung der Tabelle mit geändert werden muss und so INSERTS, UPDATES und DELETES länger dauern. Also ist auch darauf zu achten wie viele Spalten der Index umfasst und wie lang die Schlüssel sind. Darum ist es gut ersteinmal zu ermitteln, welche Abfragen am meisten von einem Index profitieren würden. Um diese im Live-Betrieb zu ermitteln ist der Loggingmechanismus von MySQL ein praktisches Werkzeug. Das Logging lässt sich in der Konfigurationsdatei my.cnf (bei *nix Systemen in /etc/mysql/ zu finden) des Servers einrichten. Um Abfragen, die besonders lange dauern, mitzuloggen, muss dies mit log_slow_queries = /var/log/mysql/mysql-slow.log aktiviert werden. Mit dem Parameter long_query_time = 2 kann in Sekunden angegeben werden, ab welcher Ausführungsdauer eine Abfrage mitgelogged wird. Um Abfragen ins Log zu schreiben die keinen Index verwenden kann log-queries-not-using-indexes in die Konfigurationsdatein eingetragen werden. Vorsicht, diese Einstellung kann ordentlich viel Output erzeugen.

Dass waren jetzt die einfachen Bordmittel, die dabei helfen können, sinnvolle Indizes zu vergeben. Das Letzte Wort zu Indices ist damit aber noch nicht gesprochen, denn beim Locking, womit sich der nächste Post befasst, spielen sie auch eine wichtige Rolle.

We use this on autoki which sends a lot of email (thanks to our social feed plugin ).

Recently we got errors from the mailserver complaining about too many concurrent connections. This did not only cause emails not being delivered and our users getting an error page, it also caused long running transactions in the database: if you send an email within an after_create hook in a model this happens inside of the database transaction. That means that if you have a 60s timeout on your mail server you end up with database transactions taking 60s to finish (or being rolled back in this case) which essentially locks up your tables after a short period of time.

Now that we are sending our emails from a queue one at a time, the mailserver is happy and our database transactions are again as short as they should be.

You can get the sources at github.