Sooo, jetzt ist sie da. Die diesjährige EuRuKo. Diesmal in Barcelona. Da sich Daniel ja (wenn auch nicht ganz absichtlich) woanders vergnügt, gibts Live-Berichte diesmal von mir - wie immer unter dem Link.
Wie? Schon Freitags? Die EuRuKo hat noch nicht angefangen, aber dennoch gibts schonmal Nachrichten in Kürze: Es wird dies Jahr einen Livestream geben. Probierts einfach morgen um 9:30 mal hier: Citilab Barcelona
Wie gewohnt hat Matz mal wieder Probleme: Letztes Jahr war sein Gepäck in Oslo, diesmal in London. Seinen Stromadapter hat er auch noch vergessen, daher ist die Präsentation ein bisschen mit der heissen Nadel gestrickt. Dafür hat Matz jetzt ein iPhone und findet es toll - nur leider fühlt er sich beim entwickeln etwas unfrei.
Als Einstieg brachte Matz erstmal eine kleine Rede über die Unterschiede zwischen Japan, USA und Europa. Japan sei uniform, in Amerika rennen lauter verschiedene Leute rum, die aber alle Englisch sprechen und in Europa sei selbst das nicht mehr gegeben.
Dieses Jahr wirds nostalgisch: Matz geht allerlei Entwicklungen in der Computerindustrie von anno dazumal bis heute durch: massiv schnellere Rechner, massiv billigere Rechner, Handheld-Rechner. Auf der Softwareseite gibt es ähnliche Probleme: Software muss billiger, schneller, schneller zu bauen werden und gleichzeitig komplexere Probleme lösen. Leider gilt für Menschen Moores Law nicht. Daher müssen wir die Performancegewinne der Computer nutzen um Entwicklungsumgebungen angenehmer zu machen.
Matz ist z.B. der Meinung, das dynamische Typisierung, Garbage Collection und dynamischer Dispatch Produktivitätsvorteile bringen, die die Rechenkosten aufwiegen.
Produktivitätsvorteile stammen aber nicht nur aus solchen harten Features, sondern auch aus den "weichen" Teilen des Produkts: Matz sieht zum Beispiel APIs als eigene Sprache, als Zutaten und Guidelines für Lösungen und damit ebenso wichtig wie die Syntax einer Sprache. Auch dienen APIs als Inspiration für Entwickler.
Das wichtigste Prinzip des API-Designs und damit auch das der Ruby-API formuliert er als: "Cut off the burden from developers", niemand wolle APIs, die so komplex wie das Problem sind.
"Evolving APIs" scheinen sein Steckenpferd zu sein (daher ist es nicht verwunderlich, dass mit Ruby19 schon wieder ein ganzer Satz Methoden hinzugekommen ist) und Namen sind ein wichtiger Teil davon.
Auf dem Weg zu einem besseren Ruby sieht Matz vor allem ein Problem - Resourcen - und bringt als Beispiele Java und JavaScript. Beide galten lange Zeit als horrende langsam, bis sich eine entsprechende Masse für die Performance aufkam.
Ein schnelleres Ruby sei also einfach eine Frage der Manpower, die darin investiert wird. Ruby auf mehreren Cores sei aber immernoch ein Problem: der Interpreter besitzt auch in 1.9 noch ein GIL und es sei extrem schwer, den Interpreter threadsafe zu gestalten. Es habe bereits einige Versuche gegeben, aber noch keinen Erfolg.
Als dritten Punkt sei Ruby for Clouds, allerdings sieht er Ruby dort bereits angekommen.
Als Fazit verbleibt Uncle Sam: We need you for Ruby - und zwar nicht nur als Bibliotheksentwickler, sondern auch als Core-Entwickler.
Sprachen seien als Entwicklung interessant: man ist nicht so in Eile, muss sich aber dennoch immer bewegen. Dafür leben sie länger als Applikationen.
Stephan ist den Rubyforen-Membern wahrscheinlich eher als Zehnbambusgarten bekannt und redet gleich über Testautomatisierung.
Stephans Interesse liegt vor allem beim Testen von großen Systemen und baut zu dem Zwecke ein großes Framework. Ruby ist seiner Meinung nach bereit für den Enterprise-Einsatz.
Risiko oder nicht ist eine Frage des Kontexts: was verliert man, wenn eine bestimmte Sache eintritt? Was ist die Arbeitsumgebung? Was sind meine Eindrücke, was sagt die Erfahrung?
Fehlern wird in Projekten gerne aus dem Weg gegangen, der Fehlerfall wird selten untersucht und trainiert. Die beste Möglichkeit, sich auf Fehler vorzubereiten, sei diese Fälle immer und immer wieder durchzugehen und zwar bevorzugt in einer realitätsnahen Umgebung. Der wichtigste Part: diese Umgebung sollte dennoch
Mangels eines besseren Namens heisst Stephans Framework momentan ATFW und möchte eine Shell für Testing anbieten, nicht jedoch eine Testbibliothek. Es folgt eine Vorstellung dieses Frameworks, die sich hier schlecht zusammenfassen lässt. Wartet auf die Folien und Videos ;).
Tja, hier muss ich mich leider entschuldigen, ich habe den Talk nicht gesehen.
Hier das gleiche Problem.
Wie es sich für so einen Vortrag gehört, gibt es als allererstes einen kleinen Videoschnipsel über die Kunst des richtigen Essens.
Chef ist ein Tool, um Serversetups zu beschreiben und zu testen. Dazu stellt es (wie könnte es anders sein) eine DSL bereit, um alle Details eines Servers zu beschreiben. Chef benutzt dazu einen zentralen Server, der an allen Clients recipes (ähnlich Capistrano-Recipies) ausliefern kann.
Als Demo gibts die Erstellung einer neuen Amazon EC2-Instanz.
Phillip ist XING-Mitarbeiter und dieses Jahr für den Motivationstalk zuständig. Programmierer sollen sich mehr als Handwerker verstehen und stolz darauf sein. Wie bei allen Motivationsreden: schaut euch später den Stream an. Könnte allerdings etwas problematisch sein, da das Mikro immer ausfällt ;).
Heute ist keiner da, die Party gestern nacht war wohl etwas heftig.
DataObjects ist der abstrakte Datenbankadapter mit dem DataMapper tickt. Wieso ein weiterer Low-Level-Adapter? Natürlich löst DO das typische Problem mit inkonsistenten APIs verschiedener Datenbanken, aber zu großen Teilen in nativem Code. Das betrifft vor allem die typischen Probleme, die normalerweise in High-Level-Layern gelöst werden, z.B Typecasting.
Ein großes Feature von DataObjects sind "shared specs", eine Möglichkeit, über verschiedene Datenbanktreiber zu testen, ob sie gewisse generell definierte Features korrekt implementieren.
DataMapper gibt es inzwischen für OS X, Linux und Windows, auf der Datenbankseite werden vor allem SQLite, MySQL und Postgres unterstützt. Momentan werden Entwickler gesucht, um Transaktionen und Prepared Statements zu verbessern. Darüber hinaus würde das Team gerne DO auch als Backend für ActiveRecord etablieren. Selbstverständlich will man auch weitere Datenbanken unterstützen. JRuby-Support in Arbeit und braucht natürlich auch Mitarbeiter.
Adhearsion ist ein Framework zum empfangen und aufbauen von Telefonanrufen. Die Entwickler sehen Open Source als Möglichkeit, kreative und unübliche Telefonieapplikationen zu erstellen. Als Basis verwenden sie Asterisk.
Adhearsion teilt sich zwar einige Bibliotheken mit Rails, ist aber unabhängig davon. JRuby-Support wird groß geschrieben, weil die Entwickler JRuby als essentiell für Enterprise-Applications sehen. Adhearson ist sehr konkurrent gebaut und nutzt dazu das Aktoren-Modell.
Als Beispielseite ist Twitter Votereport zu nennen, die während der amerikanischen Präsidentenwahl 2008 die Möglichkeit gab, Probleme im Wahlablauf zu melden - per Mail, Tweet und Anruf.
Das Framework bietet einen Rails-ähnlichen Generator. Es hat ein Komponenten-Konzept und ein System zum abarbeiten von Events. Adhearson unterstützt auch automatisches laden von Models aus einer Rails-Umgebung. Die Projekt-Webseite bietet eine Sandbox zum Testen an. Der Rest der Präsentation besteht aus einer Demo.
Adam Blum stellt ein Framework vor, mit dem sich native Anwendungen für verschiedene mobile Clients in HTML und Ruby schreiben lassen. Die wird vor allem dadurch interessant, da sich native Applikationen als das besser Geschäftsmodell herausgestellt haben.
Als Basis arbeitet Rhodes immer mit synchronisierten Daten, der Programmierer arbeitet mit den Daten nur lokal. Dadurch, dass die Applikationen nativ sind, lassen sich natürlich alle Features der Platform nutzen:Kamer, GPS, SMS, etc.
Der Kern von Rhodes besteht aus einem Mikroframework zum bauen der Apps. Dazu enthält er die erste mobile Ruby-Implementierung, die auf so gut wie allen mobilen Plattformen läuft. Eine weitere Komponente von Rhodes ist RhoSync, ein in Rails geschriebener Sync-Server, der als Endpunkt für die Datensynchronisierung funktioniert.
Dazu trickst Rhodes natürlich ein bisschen: Die Basisapplikation implementiert einen Webserver, den der Browser des Telefons anzeigt.
Hier bricht dann auch mein Bericht ab, da ich mich leider verfrüht ins Hackerleben und dann in den Flieger verabschieden wollte/musste. Eine Info verbleibt: die EuRuKo 2010 findet in Krakau, Polen statt. Ich freu mich drauf.
Kommentar schreiben
Kommentare
Liest sich wie ein gelungenes Event. Wie war die Organisation dieses Jahr? Die Vorbereitungen sahen ja sehr vielversprechend aus..
Spanisch-locker, aber nicht chaotisch. Das Citilab ist eine sehr professionelle Location, die Spanier haben sich echt Mühe gegeben. Nur die Meet & Greets abends waren nicht richtig durchgeplant. Ansonsten sehr nett und herzlich.