hanna ist ein Template für das Ruby-Dokumentationstool RDoc. Es weist im Gegensatz zum Standard-Template Darkfish (welches ihr z.B. auf der RDoc-Website bewundern könnt) eine sehr angenehm lesbare HTML-Ausgabe auf und enthält zudem eine Suchfunktion für Methodennamen. Eine beispielhaft mit hanna generierte Dokumentation findet ihr etwa im Dokumentationsteil der Website meines Automations-Projekts und es leidet auch nicht an einigen Problemen wie Darkfish, welches zum Beispiel nicht mit mehrzeiligen Methodendefinitionszeilen (solche können mit der Direktive call-seq erzeugt werden) umgehen kann. In diesem Blogpost möchte ich mich damit befassen, wie man hanna dazu bringen kann, die Ruby-Quellen zu dokumentieren, sodass man nicht immer an Webseiten wie ruby-doc.org (welches oft nicht aktuell ist) oder rdoc.info (welchem hin und wieder einige Teile insbesondere der Stdlib fehlen) gebunden ist. Außerdem werden wir nicht umhin kommen, dasselbe auch für installierte Gems zu tun.
Packt eure TAR Archive! Haut alles rein was Ihr finden könnt. Fleiß, Schweiß und all eure Gems. Die Reise nach Jerusalem geht weiter und das nächste Ziel lautet Gemcutter.
Das Ding kostet innerhalb der Betaphase noch 65$. Open Source Lizenzen gibt es wohl kostenlos. Bedeutet: jemand der ein OpenSource Projekt damit entwickelt, braucht nichts zu bezahlen.
Mit Selenium und Ruby ist es relativ einfach, funktionale Tests für Webseiten zu erstellen bzw. ausführen zu lassen. Ich stand vor der Entscheidung, entweder Watir oder Selenium für Testzwecke zu verwenden. Den Ausschlag für Selenium gab eindeutig die Selenium IDE. Mit diesem Firefox Plugin lassen sich sehr komfortabel und zügig Abläufe im Browser aufzeichnen und in diversen Formaten exportieren. Da auch Ruby zu diesen Formaten gehört war die Entscheidung schnell getroffen.
Vor ungefähr 2 Jahren habe ich in einem ominösen Sommerloch Beitrag gezeigt wie man recht einfach iTunes unter MacOSX mit Hilfe von Ruby fernsteuern kann. Seit dem ist es von meiner Seite recht ruhig geworden in der Ruby-Mine. Das lag vor allem an einem veränderten beruflichen Umfeld und einem massiven Mangel an Freizeit ;-)
Zumindest für den Augenblick scheint es so, als hätte ich diesen Zustand hinter mir gelassen und hoffe das ich zukünftig wieder vermehrt mit Ruby zu tun habe und entsprechend hier auch Beiträge schreibe.
Nun aber zurück zum eigentlichen Thema. Aus unerklärlichen Gründen konnte ich mich nicht mehr daran erinnern, jemals so etwas gemacht zu haben. Und nun wollte ich plötzlich mein iTunes auf meinem Mac auslesen (auf was für Ideen man manchmal kommt :-)). Vor diesem Problem stand ich nun und wusste nicht wie ich anfangen sollte. Von “damals” war mir noch der Begriff “RubyCocoa” im Hinterkopf geblieben. Ist das noch up2date? Von Daniel bekam ich dann noch Macruby vor die Füße geworfen. “Das kann doch nicht so schwer sein” dachte ich mir.
MacRuby hat nach dem Release 0.4 einiges über den Haufen geschmissen und baut nun auf der LLVM statt auf YARV auf. Seither gilt: selbst kompilieren ist Pflicht, nervig und vor allem lang (wer mal die LLVM von Hand kompiliert hat, weiss wovon ich spreche).
Seit neustem dürfen Snow Leopard-Besitzer ihren Prozessor wieder schonen, denn Claudio Poli bietet unter http://macruby.icoretech.org/ seit neustem nightly builds mit Installer an.
Mit dem heutigen Release 2.2.2 wollte ich mal alle Leute auf Phusion Passenger aufmerksam machen (sofern es noch welche gibt, die Phusion nicht kennen).
Bei Phusion Passenger handelt es sich um ein Modul für Apache und Nginx, welches es spielend einfach gestaltet, eine Rack Applikation (jajaja, nicht nur Rails!) auf einem Server zum Laufen zu bekommen. Das Projekt selbst existiert seit etwa einem Jahr und in dieser Zeit ist eine Menge passiert. Ursprünglich waren die Köpfe hinter Phusion Passenger für die Ruby Enterprise Edition verantwortlich. Auf diesem aufbauend, entwickelten sie ein Modul, dass sich in den Apache einbinden lies und mit wenigen Konfigurationszeilen (5 wenn ich mich recht entsinne) eine Rack Applikation zum rennen brachte. Beeindruckend finde ich noch heute das Installationsskript, welches in seiner Professionalität mir so bisher in keinem anderen Projekt aus der Ruby Szene bisher untergekommen ist. Nach dem die Monate ins Land gingen (und Phusion Passenger sich verbreitete) wurde vor einigen Wochen die Unterstützung von Nginx bekanntgegeben. Der Weg dahin war mit einem (als Rant verstandenen) Blog Eintrag und einer Präsentation und anschließend einer kleinen Spende Richtung Phusion geflastert. Engine Yard spielt auch an dieser Stelle (wie in letzter Zeit fast überall in der Ruby Welt) ein gewisses Stück mit. Verschwörung?
Und ich spreche hier nicht von diesen Dingern auf die man drauftritt und dann BOOOOMMMM. Ich meine viel eher die kommerziellen und nicht kommerziellen Bergwerkeinrichtungen, welche sich zum Ziel gesetzt haben, die Innereien von Ruby aus den Tiefen der Erde (aka Untertage) herauszuholen.
Rake ist ein unheimliches praktisches Tool, keine Frage. Aber es ist auch an die Rakefile gebunden - gibt es im aktuellen Verzeichnis keine, mag auch Rake nicht. Da schafft Sake Abhilfe - System-wide Rake. Einfach per gem install sake installieren, und man kann loslegen.
Sake verwendet eine globale Rakefile, und kann überall Tasks aus dieser ausführen. Eignet sich also herrlich zum Automatisieren von diversen Tasks die wir so erledigen müssen. Ich habe z.b. einen Sake-Task der mir alle Repositories im aktuellen Verzeichnis auf den aktuellsten Stand bringt - egal ob Subversion, Git, Mercurial, oder was da sonst noch so herumfleucht. Oder einen Task um ein Subversion-Repository in ein Git-Repository zu verwandeln.
Installieren von einem Sake-Task ist dabei denkbar einfach. Als Quelle geht jede Rakefile, oder auch Tasks die im Internet liegen. Wenn man z.b. den Repository-Update-Task installieren wollen, geben wir sake -i http://github.com/eventualbuddha/sake-git/tree/master/git.rake?raw=true ein - kurze Zeit später informiert uns Sake dass der Task installiert ist, und wir ihn per sake scm:update aufrufen können. Optional nimmt -i nach der Rakefile auch eine Liste mit Tasks entgegen, die installiert werden sollen. Sake beschränkt sich dann auf diese (plus deren Abhängigkeiten).
UPDATE: gitify ist jetzt Teil von sake-git, das auf GitHub zu finden ist.
cheatcheat ist ein Tool das uns Cheatsheets auf die Kommandozeile holt. Nach dem installieren (gem install cheat) können wir uns z.b. zu Git ein Cheatsheet anzeigen lassen: cheat git. cheat holt das Sheet von Err the Blog's Cheatsheet Wiki und zeigt es uns an. Dabei wird das Cheatsheet lokal gespeichert, damit es nicht jedes mal neu geladen werden muss. Wenn man den Parameter --new angibt, leert cheat seine Caches, wodurch wir sicherstellen können das wir immer die aktuellsten Cheatsheets zur Verfügung haben. Hilfe zu cheat selber bekommt man indem man cheat cheat eingibt.
ruby-prof ist ein Ruby-Profiler. Er ist nicht nur deutlich schneller als profile aus der Standardlibrary, sondern unterstützt u.a. auch rekursive Aufrufe, kann mehrere Threads gleichzeitig analysieren, und Call-Graph-Profile erzeugen.
'Ruby Tuesday' soll eine wöchentliche Serie über ein Ruby-Tool oder eine Ruby-Library werden, die vielleicht noch nicht so bekannt sind. Jeder Artikel soll den Sinn und Zweck des Tools oder der Library kurz erläutern, und eine Installationshilfe (sofern notwendig) und eine kurze Gebrauchsanleitung liefern.
Vorschläge für Tools oder Libraries werden natürlich gern entgegengenommen, entweder in den Kommentaren oder per eMail.
Wenn ihr selber einen Artikel beisteuern wollt, seit ihr natürlich herzlich eingeladen, dazu mir bitte einfach eine eMail schicken.
ruby-debug ist ein Ruby Debugger. In Zeiten von Unit Tests mag ein Debugger vielleicht schon wie ein Anachronismus wirken, aber manchmal helfen auch die besten Testfälle nichts, und man muss in die Eingeweide einer Applikation oder Library tauchen.
Distributed Version Control Systems (DVCS) haben im letzen Jahr einiges an Aufmerksamkeit bekommen. Glaubt man Linus Torvalds, dann sind Subversion-User Idioten und Git das einzige DVCS Wert verwendet zu werden. Grund genug sich das mal genauer anzuschauen - und wenn es nur geschieht um nicht zu den von Torvalds erwähnten Subversion-Idioten zu gehören.
Könnte mir mal einer verraten wo Apple den gem_server unter Mac OS X 10.5 versteckt hat? Soll man jetzt noch mal extra die Installation erneuern nur weil sie dieses Kommando exklusiv in der Servervariante verbaut haben? Hallo??!! Da hab ich mich so sehr auf eine ordentliche Ruby Installation gefreut und dann wieder so ein Schwachsinn… :-(
Lösung (2007-11-29 15:44 Uhr):
Wie soeben erfahren (siehe Kommentare), ist bei Mac OS X 10.5 standardmäßig Rubygems 0.9.4 installiert. Wenn man per:
und anschließend:
sudo update_rubygemsdie Kommandozeile füttert, erreicht man den gem_server anschließend via:
gem serverPrima! Vielen Dank soweit.
Aktualisierung (2007-11-29 17:03 Uhr):
Und seit der Version 0.8.5 reicht sogar das folgende Kommando:
Notiz an mich selber: Lieber Daniel informier dich bitte besser über die neuen Möglichkeiten von den Tools die du ständig aktualisierst. seufz
Ein kleines Ruby-Script soll aktiven phpBB-Neutzern dabei helfen, schnell und einfach über Neuigkeiten informiert zu werden. Eine Lösung von murphy speziell für Thunderbird und MacOS.
Es gibt nun ein OneClickInstaller Equivalent für den Mac. Sehr interessant für Leute die Ruby weder über das 1 bis 2 GB große Apple Developer Kit oder per DarwinPort installieren wollen.