Donnerstag, 18. Dezember 2008

Eine Lanze für HAML

Was ist denn nun so besonders an Ruby? Ist das nicht nur eine weitere Scriptsprache? Was soll der ganze Hype, und wann ist er wieder vorbei? Diese Frage stellen zum Beispiel Java-Entwickler gerne, und wärmen anschließend gleich mal wieder die Vorurteile der C/C++ Entwickler gegenüber Java Ende der 1990er Jahre auf. Ohne es zu wissen, nehme ich an.

Nun, Ruby ist tatsächlich nur eine Scriptsprache; sogar Python (als zweite ernstzunehmende moderne Scriptsprache in der Unix-Welt) macht mehr Zugeständnisse an Performance-Vorbehalte der Entwickler und Entscheider aus dem Compiler-Lager. Aber wer Ruby sagt, meint heute größtenteils Ruby on Rails (auch wenn im Schatten von RoR ein ganzer Garten anderer Ruby-basierter Frameworks gewachsen ist: ich weiß erstmal von Ramaze, CampingMerb und Hobo, ohne sie wirklich ausprobiert zu haben). Und das Markenzeichen von RoR ist die extrem kurze Entwicklungszeit für Applikationen. (Jaja, neben DRY, Convention over Configuration und anderen Schlagworten.)

Aber RoR-Applikationen haben trotzdem einen Pferdefuß: Irgendwann schlägt die Stunde der Views, und die bauen aus HTML-Templates und -Schnippseln Seiten und Seitenfragmente für den Browser zusammen. Das Werkzeug der Wahl ist normalerweise ERb, was, ganz in der Tradition der JSPs, Code in HTML einbettet. Das Resultat ist oftmals unübersichtlich, und die generierten HTML-Seiten sind nur so gut wie die Templates. Darstellungsprobleme im Browser? Ein Tag verschluckt? Schachtelung der XHTML-Elemente falsch?

Wer kennt das nicht? Nun, wer HAML verwendet.

HAML ist (wieder mal) eine neue Template-Sprache. Ähnlich Python, welches Entwickler zwingt, nicht nur sauberen, sondern schönen Code zu schreiben (in dem Sinne in dem die äußere Form des Quelltextes seine logische Struktur widerspiegelt), zwingt HAML den Designer, nicht nur saubere, sondern schöne Views zu bauen. Das Beispiel von der HAML-Frontseite läßt leider nur erahnen, was möglich ist:

Aus
<table>
<tr>
<th>Name</th>
<th>eMail</th>
</tr>
<% @adressen.each do |addr| %>
<tr>
<td><%= h(addr.name) %></td>
<td><%= h(addr.email) %></td>
</tr>
<% end %>
</table>
wird in HAML
%table
  %tr
    %th Name
    %th eMail
      - @adressen.each do |addr|
  %tr
    %td= h(addr.name)
    %td= h(addr.email)
Ist ja dann schon ein Stück kürzer. Aber das Beispiel ist ja auch recht kurz. Was passiert jetzt, wenn die Zeilen abwechselnde Stile verwenden sollen?
<table>
<% style="odd" %>
<% 10.range.each do |num| >
<tr class="<%=style%>">
<td>line <%=num%</td>
</tr>
<% style = (style == "odd" ? "even" : "odd") %>
<% end >
</table>

wird hier einfach zu
%table
  - 10.range.each do |num|
    %tr{:class=>"#{cycle('odd','even'}"}
      %td
        line
        = num

[Update](Danke an neuholger für die Vereinfachung!)[/Update]

Ist doch irgendwie... einfach zu lesen, oder? Die Ersparnis in Zeilen ist bei diesem einfachen Beispiel noch nicht so beeindruckend (6 Zeilen zu 9 Zeilen), kann bei umfangreicheren Views aber schnell wachsen. Und vor allem geht eben nie die Zuordnung einer Zeile zu einem logischen Block verloren.

Zudem generiert HAML immer sauber formatiertes HTML: Auch Partials, die ja ihrerseits "ganz links" anfangen, bringen das System nicht aus dem Tritt. Und zuletzt gibt's als Zugabe zu HAML noch dessen CSS-Seite, SASS. Aber das ist wieder eine eigene Geschichte...

[Update](Apropos CSS: Damit das Beispiel von oben auch wirklich funktioniert, braucht man natürlich das passende CSS dafür -- wie jenes aus neuholgers Kommentar.)[/Update]

Zum Schluß: Wer jetzt unsicher ist, muß die Katze nicht im Sack kaufen. Hamton Catlin hat netterweise The Lab gebaut, in dem man HAML und SASS online ausprobieren kann. Viel Spaß!


[Update] Updates vom 9.8.2011: Vereinfachung von neuholger eingebaut (Danke!). Zudem scheint es das HAML/SASS Lab nicht mehr zu geben, und die offiziellen Seiten von HAML und SASS sind umgezogen. [/Update]

Samstag, 6. Dezember 2008

Subversion-Repositories nach Git migrieren

Nachdem man sich entschlossen hat, mit Git zu arbeiten, steht man vor einem weiteren Problem: Was macht man jetzt mit den alten Subversion-Repositories? Natürlich kann man weiter Subversion verwenden, es ist schließlich kein schlechtes System. Aber warum sich mit zwei parallel zu pflegenden Systemen herumschlagen?

Auf Simplistic Complexity gibt's eine sehr schöne Kurzanleitung, die im Wesentlichen aus drei Schritten besteht:
  1. Anlegen einer Textdatei für das User-Mapping
  2. Importieren des SVN-Repositories in Git
  3. Exportieren des importierten Repositories auf den Git-Server
Das sieht dann auf der Shell so aus (die Datei usermapping.txt enthält die Zuordnung von SVN-Namen zu git-eMail-Adressen in der Form "svnid = Git User <gituser@email.com>", eine Zuordnung pro Zeile):

mkdir myproject
cd myproject
git svn init http://myserver/svn/myproject/trunk/ --no-metadata
git config svn.authorsfile usermapping.txt
git svn fetch
git clone --bare .git ../myproject.git

Das in myproject ausgecheckte Subversion-Git-Gemenge kann man jetzt bedenkenlos löschen; das blitzblanke myproject.git wird auf den Git-Server expediert und kann von da aus verwendet werden.

Im Blog wird noch der eine oder andere Haken diskutiert, hauptsächlich, weil Git jedes Commit einem User zuordnet, einige Subversion-Repositories aber keinen User haben, dem der erste Commit zugeordnet ist. Nun, das war bei mir glücklicherweise nicht der Fall, und der Transfer meiner Source-Repositories von Subversion zu Git war bisher schmerzlos und schnell.

Letzter Hinweis, bevor jetzt jeder losstürzt und sein Subversion pensioniert: Es gibt auf der Windows-Plattform immer noch keinen Git-Client, vielmehr muß Cygwin mit dem Paket git-core (und möglichst noch git-gui) verwendet werden.

Montag, 1. Dezember 2008

Switch! Mac für Windows-Nutzer

Gelegentlich wird man als Mac-Benutzer ja gefragt, warum mal kein Windows verwendet. Das ist für mich eine schwierige Frage, denn es gibt eigentlich keinen rationalen Grund, weshalb ich einen Mac haben wollte. Ich wollte ihn, weil ich die Nase voll hatte vom allgemeinen am-Computer-rumschrauben, den ganzen kleinen Ärgerlichkeiten, denen man sich aussetzt, wenn man einen PC benutzt. Das gibt's natürlich auch beim Mac (nur eben anders), und so driften diese Diskussionen sehr schnell in Glaubensfragen ab. Fakt ist: Wer einen Mac hat (und mag), will kein Windows mehr; mehr kann man dazu nicht sagen.

Und manchmal wird man gefragt, worauf man sich einstellen muß, wenn man denn tatsächlich seinen Windows-PC gegen einen Mac tauscht. Hier kann man dann ernsthafte Antworten geben.

Zuerst gilt: Wenn man mit seinem System zufrieden ist, sei es Windows, Linux oder Mac, sollte man dabei bleiben. Ein anderes System bedeuted immer Umstellung und Zusatzkosten, angefangen bei neuer Hardware bis hin zu neuer Software.

Noch dabei? Gut. Dann ist der nächste Schritt, sich zu überlegen, was man mit dem Computer eigentlich machen will. Ist die Antwort "Computerspiele", sollte man überlegen, ob man nicht mit einem Windows-PC oder einer modernen Spielkonsole besser dran ist.

Weiter geht's: Welche Applikationen werden im Moment unter Windows verwendet? Die Klassiker sind Microsoft Office, Outlook und der Explorer, jeweils mit den offenen Alternativen OpenOffice, Thunderbird und Firefox. Diese Applikationen bereiten keine Probleme: Entweder gibt es sie direkt für MacOS X, oder man nimmt die Alternativen von Apple: iWork, Mail.app, Adressbuch und Safari. (Bei Apple gibt's unter dem Titel "Ja zum Mac" eine Liste der wichtigsten Fragen.) Dann gibt's noch Adium als Messenger (falls einem iChat nicht zusagt), und mit dem Mac-Skype-Client ist die letzte Kommunikationslücke geschlossen.

Damit sind die Allgemeinplätze abgedeckt. Bei der Suche nach den Applikationen, um die man sich bei einer Windows-Installation ständig kümmert, stößt man auch auf Windows-Spezialisten wie Antivirus-Programme, Firewalls, Skinning- und Tweaking-Tools oder ähnliches. Analoge Programme für den Mac sind rar und selten nützlich, also verzichtet man besser darauf. Aber was ist mit der Photo-Tool X oder dem Audio-Programm Y? Hier empfiehlt sich die Suche nach inhaltlich analogen Programmen auf Versiontracker.

Den größten Teil der alltäglich benötigten Applikationen sollte man jetzt bereits abgedeckt haben. Für die unter uns, die ihren Mac als Alternative zu einem Linux-System zur Softwareentwicklung einsetzen wollen, suchen jetzt vielleicht noch ein PHP, ein Ruby, ein Tomcat oder einen Apache. Die gute Nachricht: Es gibt eine ganze Menge der Unix-Tools bereits an Bord von MacOS X, und auch Java 6 gibt's endlich für den Mac. Die schlechte Nachricht: Apple ist nicht gerade ständig am Aktualisieren dieser Pakete. Doch Hilfe ist nicht fern: MacPorts bietet ein an die BSD Ports angelehntes System zur Installation von Software. Dazu muß auf dem Mac allerdings ein MacOS X Entwicklungssystem installiert sein. Kein Problem, liegt ja jedem Rechner bei.

Und, noch eine lebenswichtige Applikation, die es leider nur für Windows gibt? Mit Parallels Desktop oder VMWare Fusion bekommt man die letzten Renitenten auf den Mac-Desktop, auch, wenn man früher oder später feststellt, daß man darauf verzichten kann. Auf diese Weise muß man nicht einmal auf Applikationen wie Microsofts Visual Studio oder IBMs Telelogic Synergy verzichten, die man ansonsten nicht auf den Mac bekommt. Und für das Windows-Spiel zwischendurch gibt's Bootcamp - allerdings braucht man dafür eine Windows-Lizenz.

Hat man seinen Mac einmal konfiguriert, kann er locker mit Windows und Linux mithalten - auf einer Maschine. Nur sollte man sich mit dem Gedanken vertraut machen, bei Problemen nicht zum Nachbarn gehen zu können. Neben einem ständigen Backup per mitgelieferten Time Machine hat es sich bewährt, auf eine bootfähige Platte eine bootfähige Kopie des eigenen Systems vorzuhalten. Dazu braucht man eine Firewire-Platte (davon können alle Macs booten), sowie entweder Carbon Copy Cloner oder Superduper!. Wofür man sich entscheidet, ist letztlich Geschmackssache (und natürlich eine Frage, was für einen selbst besser funktioniert).

So. Den Mac bekommt man dann im Apple Store, oder beim Apple-Händler um die Ecke. Viel Spaß!