Archiv vom Juni 2007

Rails-Konferenz 2007

Vom 25. Juni 2007

Konferenzen sind eine feine Sache. Erst recht, wenn es um Rails geht. Dieses Jahr war ich mal wieder auf der Rails-Konferenz zu besuch und es hat sich wirklich gelohnt. Es gab, wie letztes Jahr auch, eine Reihe sehr guter Vorträge und man konnte sich auch gut mit anderen Entwicklern austauschen. An dieser Stelle ein sehr großes Lob an das Organisationsteam der Konferenz, das durchweg sehr gute Arbeit geleistet hat.

Ok, aber fangen wir am Anfang an. Glücklicherweise hab ich am Donnerstag vor der Konferenz auch Urlaub bekommen um die ganzen Vorbereitungen zu erledigen. Für viel Freude hat natürlich mal wieder die Bahn gesorgt. Eigentlich wollte ich mir die Fahrkarte (Treuchtlingen – Frankfurt, hin und zurück) im Internet kaufen. Dort gibt es Frühbucherrabat und so bin ich für die Fahrkarte auf ca. 55 € (statt ca. 100 €) gekommen. Allerdings hat man ja als Zivi auch gewisse Privilegien und dazu gehören auch vergünstigte Fahrpreise bei der Bahn. Also geht man zum nächsten Schalter und probiert dort, eine Karte zu kaufen. Der nächste Schalter ist in Nördlingen, dachte ich zumindest. “Wegen Geschäftsaufgabe geschlossen”... ok, super. Also weiter zum nächsten Schalter, nach Donauwörth. Dort gab es dann auch eine Karte mit Zivirabat, aber halt ohne Frühbucherrabat und so hat mich die Fahrkarte 68 € gekostet.

Alle Vorbereitungen fertig, los gehts. Abfahrt Freitag 3:00 Uhr früh, mit dem Auto nach Treuchtlingen, dort 4:17 Uhr mit dem Zug weiter. Allerdings hab ich dank einer hartnäckigen Mücke nur 2 Std. gedöst und nicht richtig geschlafen. Naja, ging dennoch recht gut, vor allem wenn man während der Zugfahrt programmieren kann oder eben ein gutes Buch von Terry Pratchett dabei hat. Interessant wurde es dann in Frankfurt selbst: mit einem Stadtplan von Google Maps 3 km durch die Innenstadt gelatscht. Leider berücksichtigt Google Maps die Hausnummern nicht genau und deshalb musste ich mich die letzte halbe Stunde durchfragen.

Letzten Endes bin ich dann doch irgendwie bei der Konferenz angekommen. Witzig war dieses Jahr, dass vor den Vortragssaal ein PHP- und ein Java-Magazin (Sponsoren) ihre Stände aufgebaut haben. Ausgerechnet auf einer Rails-Konferenz, dort wo die Leute sind, die von diesen Sprachen ehr die Nase voll haben. Allerdings kam dadurch garantiert bei dem einen oder anderen etwas Nostalgie auf, zumindest bei mir.

Die Vorträge waren eigentlich alle recht gut. Bei ein hatte ich jedoch das Gefühl, dass es zu sehr Vortrag und zu wenig Stimmung war. Sowas läst sich aber immer leicht sagen, wenn man nicht selbst da vorne steht und ich will den Leuten dass dort keines Falls vorwerfen. Es gehört eine Menge dazu, sowas erst mal zu machen.

Den Anfang machte die Keynote über REST, wobei ich nach wie vor nicht behaupten kann, dass ich den Kern verstanden hab. Für große Unternehmensstrukturen, ok, aber für kleine Webseiten… weiß nicht so recht.

“Prosa, Lyrik, Ruby und Rails” war ein recht netter Vortrag. Hat vor allem untermauert, dass lesbarer Quelltext die Kosten senkt und die Produktivität steigert. Sehr interessant fand ich “Caching in Rails”. Ich kannte zwar schon etwas aus diversen Rails Büchern, aber die Erfahrungsberichte in dem Vortrag werde ich mir zu Herzen nehmen (z.B. nur einen Domainnamen verwenden).

Richtig cool wurde es dann am Nachmittag. “Offline arbeiten? Leben und wirken wie im letzten Jahrtausend” hat (zumindest Subjektiv) einen sehr guten Überblick über Joyent Slingshot, einem Framework, um Railsanwendungen auch offline betreiben zu können. Für mich ist die Lehre aus diesem Vortrag, dass ich solche Projekte erst mal noch nicht probieren werde. Wie hat es Jens-Christian Fischer so schön genannt: “proof of concept”. Der Vortrag über “Ferret”, ein Plugin für die Volltextsuche war ebenfalls sehr informativ. Zudem plane ich, dieses Plugin in der kommenden ZGR-Seite zu verwenden und da ist es sehr praktisch zu wissen, dass man einen Index-Server für mehrere Rails-Dispatcher braucht. Es wurde jedoch noch besser, denn bei “GoogleMaps Anwendungen mit Ruby on Rails” kam bei mir richtig die Lust auf, sowas sofort zu bauen. Plugins wie GeoKit machen sowas echt einfach und zu dem kann man dadurch für die ZGR-Seite einen echten Mehrwert rausarbeiten.

Soweit so gut, schon viel nette Sachen gelernt, aber zum Schluss hin wurde es noch besser. Ich freu mich schon richtig drauf, wenn “Rails Conditions” veröffentlicht wird. Das ist ein Plugin für Rails, um die Verarbeitungslogik einfacher abzubilden bzw. zu schreiben. Hab sowas früher selbst mal probiert, aber das ist in keiner Weise so schön und simpel geworden, wie Rails Conditions. Hut ab vor Norman Timmler, der damit meiner Meinung nach wirklich was geschafft hat.

Alles in allem war die Konferenz wirklich das Geld wert. Am Schluss gab es noch ein wenig zum Aufräumen, aber im Gegensatz zu letztem Jahr waren die Boxen sehr viel leichter, es gab also nicht so viel zu schleppen. Leider war es nach der Konferenz nicht mehr so schön, wie letztes Jahr, da sehr viele schon recht früh weg mussten. Hab mich dann letzten Endes 2 Std. bevor mein Zug gefahren (22:18) ist auf dem Weg gemacht und hab mir noch eine Stunde den Bahnhof zu Gemüte geführt. Irgend wie sehen alle Bahnhöfe in Großstädten gleich aus…

Alles in allem bin ich Samstag ca. 3 Uhr ins Bett gefallen. 25 Stunden ohne Schlaf sind zwar hart, aber waren es dafür durchaus wert.

Abgelegt in: Programmieren | Kommentare ansehen und hinterlassen (3)

Options for Rubys to_yaml method…

Vom 20. Juni 2007

... and how to waste two days. This post is meant for all developers having the same kind of problem (searching for options of the to_yaml method) and because of that it’s written in English.

While programming on the Simple Localization plugin for Ruby on Rails, a mail exchange with Roman Gonzalez produced a nice idea: if a user accesses a key of the language file (a file containing YAML code) and that key does not exist it should be automatically added to the language file.

So far so good. Loading YAML is easy:

YAML.load_file ...

And saving YAML isn’t hard as well:

File.open(target_file, 'wb') do |file|
  YAML.dump data, file
end

However trying to change the way the data is converted to YAML… is a waste of time.

Why care? Well, because the language files of the plugin are written by hand and therefore it is important to keep the YAML code as clean as possible. Let’s demonstrate this. Here is a snippet of the German language file:

dates:
  abbr_monthnames: [Jan, Feb, Mär, Apr, Mai, Jun, Jul, Aug, Sep, Oct, Nov, Dez]

After loading it to Ruby and dumping it as YAML again it looks like this:

---
dates:
  abbr_monthnames: 
  - Jan
  - Feb
  - "M\xC3\xA4r" 
  - Apr
  - Mai
  - Jun
  - Jul
  - Aug
  - Sep
  - Oct
  - Nov
  - Dez

I wouldn’t say it screws up the language file, the YAML emitter (the thing constructing the YAML code) does every thing right (the YAML code is working). However the keys are not ordered and you can not be sure to find a key where you left it, after new YAML code is saved to a language file. Special characters (like German “umlauts”) are escaped because the generated YAML code is encoded in plain old ASCII. Most readers will also notice that the generated YAML code does not use inline collections (eg. [a, b, c, ...]) and does everything in usual ordinary sequences (- a\n- b\n- c). The final new part added by the emitter is the document separator (---).

Please, don’t get me wrong. There’s all right with the data stored in the YAML code, only the presentation isn’t as clear as it could be. The Simple Localization plugin heavily depends on hand written YAML files (as a place to store the localization information) and I decided to use YAML for this because it’s a very powerful and more important a simple way to write information. It makes writing the language files almost painless, sometimes even fun. This is a very important part of the plugin if not the core itself. But all the things that happen to the YAML file when it’s loaded and saved back makes it very annoying to work with the language files.

So, what do to? Usually Ruby libraries offer all kinds of options to manipulate their behavior. A short look at Rubys core docs for the to_yaml method looks promising: to_yaml( opts = {} ). So there’s an opts parameter, probably a hash witch makes it possible to alter the way the YAML code is generated. A few searches later the documentation of the yaml4r project shows the desired information: The Options Hash.

Nice, every thing we need. At least until you try it out. Options are fine but they are useless if they don’t change anything. I tried to specify the options to every YAML object that is involved in generating YAML code. A bit later I found a mail at least mentioning this:

Q3.

The following options are defined in ‘yaml/constants.rb’:

:Indent => 2, :UseHeader => false, :UseVersion => false, :Version => ‘1.0’, :SortKeys => false, :AnchorFormat => ‘id%03d’, :ExplicitTypes => false, :WidthType => ‘absolute’, :BestWidth => 80, :UseBlock => false, :UseFold => false, :Encoding => :None These options are intended to be used witch Object#to_yaml(), YAML::Stream.new(), and YAML::Store.new(). But all except :Indent, :SortKeys, :ExplicitTypes and :UseBlock are not available when I tried on Ruby 1.8.2.

What options are available in Ruby 1.8.2 and 1.8.3?

Most of these constants are now singleton methods in Ruby. I need to update documentation and remove the constants from yaml/constants.rb.

Ok, fired up irb and searched everything YAML-like for singelton methods. No go. Nothing there, too.

After more than a day searching for the YAML options enough was enough. I started to read the source files in Rubys yaml directory. A bit of reading later I found out that Ruby uses the Syck library as a backend for it’s YAML support. Syck grew out of the pure Ruby YAML library used before the days YAML was added to Rubys core. Some files in the yaml directory are nothing else than old unused files left there for backward compatibility. The main work is done by the pure C Syck library and a wrapper used to talk to Ruby.

Now I hoped that the pure Ruby Interface just uses an outdated way to pass the options to the Syck objects. However analyzing Ruby and C code for a few hours (I’ve never written a C extension for Ruby) only brought this:

The wrapper around the Syck objects does not pass the options at all. It just stores them in an instance variable and leaves them there.

I ended up in the ext/syck/rubyext.c source file of the current Ruby trunk in the syck_emitter_reset function (YAML::Syck::Emitter#initialize in Ruby). It does get the options but does not use them to set options to the Syck emitter object. A list of supported options can be found in the syck_new_emitter function in ext/syck/emitter.c.

Since the Syck functions can only be accessed via C code this could only be fixed in C. Maybe I’ll create a patch for Ruby to fix this but this will not solve my problems with the Simple Localization plugin (at least not in time). Maybe Ruby Inline can help here but for now I’ll focus on other features still on the plugins todo list.

I just wrote all this down to spare others from searching for this for to long. Please notice that I’m not experience in reading C extensions for Ruby and therefore I may have missed a thing or two. If there is a way for this to work I’ve overlooked please let me know.

At the end I still like Ruby and YAML. Rubys support for YAML is pretty impressive neverless. Because of Rubys and YAMLs powerful natures the little details can just get very tricky sometimes…

Abgelegt in: Programmieren, Projekte | Kommentare ansehen und hinterlassen (7)

Firefox und seine “Dynamischen Lesezeichen”

Vom 11. Juni 2007

Dieses Feature von Firefox hat mich die letzten 2 Stunden gekostet. Ok, mindestens eine ¾ Stunde ist auf die immer mal wieder zusammenbrechende Internetverbindung gegangen, aber das ist eine andere Geschichte.

Jedenfalls hat mich vor ein paar Stunden mal wieder ein französischer Entwickler wegen dem Simple Localization Projekt angeschrieben. Bei dem Gespräch hat er auch erwähnt, dass der Newsfeed des Projekts nicht gehen würde. Geschockt hab ich gleich mal ein paar Validatoren über den armen Feed drüber prügeln lassen. Dabei kam immer nur ein raus: alles ok. Einer hat noch einen falschen Content-Type header angemerkt (application/xml statt application/atom+xml), aber das war schnell korrigiert. Hab den Feed schnell mit Opera getestet und da hat auch alles hingehauen. Später sind wir drauf gekommen, dass er Firefoxs “Dynamische Lesezeichen” verwendet. Habs getestet und siehe da, bei mir kam auch nur ein “leeres” Lesezeichen.

Persönlich stehe ich ja nicht so auf Firefox- oder Opera-Fehler. Leider sind die zu selten und deshalb bei weitem nicht so gut dokumentiert wie die vom IE 5 oder 6. Hab mich dennoch durch das weite Netz gequält… mit einer Verbindung, die alle 5 Minuten für 5 weitere Minuten tot war.

Irgend wann waren mir dann die 2 minütigen Ladezeiten für eine Website zu doof und so hab ich angefangen, die Fehlerursache auf lokalen Servern selbst zu jagen. Hab mir nen anderen funktionierenden Atom 1.0 Newsfeed geschnappt und jedes Element verglichen und rumprobiert.

Irgend wann bin ich drauf gekommen, dass der fehlerhafte Newsfeed seine Einträge nicht mit einem Link zur Website des Elements (also des Blogeintrags oder des Kommentars) versieht. Um genau zu sein das link Element mit dem rel="alternate" Attribut. Dieses Element enthält die Adresse der Website, die einem den Eintrag des Newsfeeds anzeigt.

Die dynamischen Lesezeichen in Firefox brauchen ja ein Ziel, das aufgerufen wird, sobald man auf das Lesezeichen klickt. Der fehlerhafte Newsfeed hat so ein Ziel nicht definiert, also hat Firefox die Einträge nicht angezeigt. Im nachhinein irgend wie logisch… hat mich dennoch viel Zeit gekostet. Man lernt eben nie aus.

Abgelegt in: Programmieren, Browser | Kommentare ansehen und hinterlassen (2)

Projekte

Simple Localization
Ein einfaches, aber macht- volles Übersetzungsplugin für Ruby on Rails.
Table Navigation
Ein jQuery Plugin um per Tastatur schnell durch Tabellen zu navigieren.

Über was ich schreibe…

Newsfeeds

Kommentare