Entwickler. Berater. Intergalaktischer Weltraumheld. DJ. Und Blogger. Ha! Veranstaltet Workshops rund um die Entwicklung von Web-Anwendungen und ist auch sonst für jeden Schabernack zu haben. Siehe mans.de.

Go To Admin Logout

Tumblr, Markdown Pro, Do & Pony

Tumblr ändern ihre Nutzungsbedingungen und versionieren sie über GitHub, wo man in aller Ruhe die Diffs unter die Lupe nehmen kann. Sollte ab sofort jedes Unternehmen so machen.

Markdown Pro ist vielleicht nicht der hübscheste Markdown-fokussierte Texteditor, den es gibt, aber er ist nach wie vor mein Favorit. iA Writer und Byword sind toll und schick und überhaupt, aber sie haben so ihre kleinen Macken, die mich immer wieder nerven (allen voran werden beide immer träger, je größer ihre Fenster werden.)

Do (kurze Namen FTW) ist ein weiteres Tool, das die automatisierte Einrichtung und Wartung von Servern vereinfachen soll. Es sieht ein bisschen verrückt aus und beschreibt sich selbst als “a fun mix of capistrano, rake, thor and brew”. Uh, okay.

Pony ist ein kleines Gem, das Mails verschickt und dazu eine ähnliche Syntax bietet wie die berühmt-berüchtigte mail-Funktion aus PHP. In der einen oder anderen Situation kann so etwas ganz nützlich sein.

Ich schreibe und poste diesen Eintrag übrigens im Zug in Richtung München. Haha, die Zukunft ist heute usw.!

"Wir haben die unten stehende Nachricht nicht bekommen."

Scott Watermasysk echauffiert sich über die unheilige Praxis, Mails mit einer no-reply@...-Absender-Adresse an User und Kunden zu verschicken:

NEVER, EVER, EVER, NEVER SEND A CUSTOMER AN EMAIL SHE CANNOT REPLY TO.

Why miss the opportunity to engage with your (would be) customer? Why make them jump through even a single hoop to contact you?

Als ich vor wenigen Wochen auf eine Mail vom Amazon.de-Support antwortete, die ganz klar eine typische Ticketsystem-Mailadresse als Absender- und Antwortadresse und ganz sicher keine Bitte um Nicht-Beantwortung enthielt, erreichte mich wenige Sekunden später die folgende hübsche Nachricht:

Leider hat der Kundenservice Ihre unten stehende Nachricht nicht bekommen.

Warum tun sich viele Unternehmen nur so schwer mit dem E-Mail-Kontakt zum Kunden?

.ruby-version, GitHub, Mocktra, Humongous, Mutant Testing & jQuery

A Common .ruby-version File For Ruby Projects: Fletcher Nichol schlägt .ruby-version vor, um eine Art Baseline-Kompatibilität zwischen RVM, rbenv und (meinem) rbfu herzustellen. Habe ich kurzerhand in rbfu eingebaut, und RVM kann es auch schon.

Ruby Patterns from GitHub's Codebase: Zach Holman erzählt mal wieder ein bisschen aus dem GitHub-Nähkästchen. Meine persönlich Überraschung: “Document Everything”. Ich bin sicherlich nicht der größte Autor von Dokumentation, den es jemals gab, hust, hust, aber dieser in der Ruby-Welt so stark vertretene Anspruch, so zu programmieren, dass es keiner Dokumentation bedarf, hat mir noch nie geschmeckt. Insofern: +1.

Mocktra: “A webmock DSL using sinatra.” Mit Sinatra kleine Webmock-Apps bauen, gegen die dann die eigenen Tests laufen können. Praktisch, wenn man gegen APIs entwickelt. Auch immer einen Blick wert: VCR.

Humongous: “A standalone Mongo Browser for Ruby, using HTML5. Just run and forget.” Praktisch zum Rumgraben in einer MongoDB-Datenbank.

Mutation Testing With Mutant: “Mutant is a mutation tester. It modifies your code and runs your tests to make sure they fail. The idea is that if code can be changed and your tests don’t notice, either that code isn’t being covered or it doesn’t do anything.”

The Basics of jQuery: schöne high-level Einführung in jQuery. Wird vielen von euch sicherlich nicht einmal ein müdes Gähnen entlocken, aber genau eine solche Anleitung hatte mir immer gefehlt, habe ich doch bisher nicht ansatzweise so viel mit Javascript und jQuery gemacht, wie ich hätte sollen.

"hello heroku world"

heroku

Evan Weaver hat sich Autobench gekrallt und damit die Performance (in diesem Fall: Requests pro Sekunde bei steigender Concurrency) verschiedener Web-App-Frameworks auf Heroku durchgemessen. So ein Test sagt natürlich nicht viel über ihre tatsächliche Laufzeitperformance aus; stattdessen muss man die von Evan ermittelten Ergebnisse als hartes Oberlimit von dem verstehen, was Heroku in Kombination mit dem jeweiligen Framework liefern kann. Ganz besonders interessant dabei:

As the number of dynos increases, the best per-dyno response rate declines from 2500 to below 1000. This suggests that there is a non-linear bottleneck in the routing layer. There also appears to be a per-app routing limit around 12,000 rps that no number of dynos can overcome (data not shown). For point of reference, 12,000 rps is the same velocity as the entire Netflix API.

Die Ergebnisse von Sinatra decken sich ziemlich genau mit dem, was ich selber neulich aus Spaß gemessen hatte. Mein “Hello World” erreichte in etwa ~1500 req/s; mit etwas Code dahinter, der u.A. Daten mit MongoDB austauscht und per HAML Seiten rendert, waren es “nur” noch knapp unter 150 req/s (ohne zwischengeschaltetes Rack::Cache. Mit dem neuen Caching-Setup in 0.1.1 ist die Performance natürlich wieder deutlich höher, aber dazu bald mehr.)

"because a tablet is different than a smart phone"

Achtung, das Folgende tut weh:

While Apple popularized multi-touch interfaces on its iPhone and then iPad, one thing that company simply didn't get right is how it adapted iOS for larger screen devices. On a phone, it's easy to tap any area of the screen while using just a single hand. But on the iPad, some software-based navigation buttons are in the top left corner of the screen, while others are in the bottom area, making navigation more difficult. It's like Apple simply took the iPhone screen and made it bigger. Because that's exactly what they did.

Windows 8 benefits from the maturity of time. Instead of taking the Windows Phone interface and exploding it onto a larger screen device, Microsoft really thought about how people would hold these devices and interact with the software. Windows 8 devices are thus oriented in landscape mode, not portrait, because a tablet is different than a smart phone. And the navigation is consistent, logical, and usable, with edge UIs sitting right where the user's fingers naturally fall. They're not random, or different from app to app.

Ob Paul Thurrott jemals in seinem Leben tatsächlich ein iPhone und iPad in den Händen gehalten hat? Vor meinem inneren Auge sehe ich schon wieder Windows-Fans euphorisch jubeln; creepy, diese Leute. (Aber Hauptsache, Apple-Nutzer sind alle markenhörige Schafe, mm-hmm, ja.)

Markdown, Sublime Text Workflow, Brick Force und noch mehr Schnitzel!

The Markdown Mindset ist ein netter Text darüber, warum Markdown so toll ist. Was unter anderem auch erklären sollte, warum ich in Schnitzelpress komplett auf Markdown setze.

Sublime Text Workflow That Beats Coda and Espresso: ein Rundum-Beispiel, wie man mit aktuell angesagten Tools (u.A. das erst neulich im Detail angepriesene Sublime Text 2) einen Entwicklungs-Workflow ausetzen kann. (Your mileage may vary usw. - danke Carlo für den Link.)

Brick Force: riecht ein bisschen nach Free-to-Play-Micropayment-Ripoff, aber hey, ein unheiliger Zwitter aus Minecraft und einem Ballerspiel kann nicht schlecht sein.

Schnitzel des Tages:

Introducing SchnitzelPress

Ich war mit den anderen Blog-Engines nicht zufrieden und habe schlussendlich aus Verzweiflung meine eigene geschrieben. Sie heißt SchnitzelPress, ist toll, und ist jetzt in der total aufregend klingenden Version 0.1.0 verfügbar. Details auf schnitzelpress.org; eine eher für Hacker und Entwickler ausgelegte Installationsanleitung gibt es hier. (Ja, Dokumentation für normale Leute kommt auch noch.)

SchnitzelPress, jetzt auch auf Ruby 1.8.7

Ruby 1.8.7 ist alter Käse, und eigentlich sollte man für 1.9.2 und aufwärts entwickeln. Trotzdem habe ich mir gerade die Arbeit gemacht, SchnitzelPress kompatibel mit Ruby 1.8.7 zu machen. Warum?

Produktiv werden so gut wie alle SchnitzelPress-Blogs unter Ruby 1.9.2+ laufen, denn SchnitzelPress ist in erster Linie für den Einsatz auf Heroku konzipiert, wo Ruby 1.9 zum Einsatz kommt. Wer einen eigenen Server betreibt, auf dem er SchnitzelPress hosten will, der bekommt auch Ruby 1.9 installiert. Für den Produktiveinsatz ist eine Kompatibilität mit 1.8.7 also unnötig.

Es geht viel mehr um die Installationsprozedur. SchnitzelPress ist keine Bibliothek für Entwickler, es ist eine Blog-Engine. Ich kann mir nicht erlauben, davon auszugehen, dass jeder User, der ein SchnitzelPress-Blog aufsetzen will, auch Entwickler ist. Deswegen ist eines der Ziele, die ich mit SchnitzelPress verfolge, die Installation und Einrichtung eines Blogs unter allen gängigen Betriebssystemen so einfach wie möglich zu machen, allen voran natürlich Mac OS X und Windows. (Linux-User kommen schon irgendwie klar.)

Würde ich Ruby 1.9 voraussetzen, müsste sich der User dieses erst einmal installieren. Dafür müsste er (am Beispiel von OS X):

  1. Xcode installieren
  2. rbfu, rbenv oder RVM installieren
  3. Ruby 1.9.2+ kompilieren (u.U. über ruby-build)

Für einen Entwickler mögen diese Punkte trivial erscheinen, aber sie für das Einrichten eines kleinen Blogs vorauszusetzen, ist natürlich Overkill. Dazu kommt, dass SchnitzelPress Ruby 1.9 bisher nur wegen der neuen Hash-Syntax benötigt hat. Nur wegen dieser Hash-Syntax jeden potenziellen Nutzer durch die oben erwähnten Schritte durchzujagen, wäre ziemlich dumm.

OS X wird (auch in der aktuellen Version 10.7) nach wie vor mit Ruby 1.8.7 ausgeliefert. Hier ist es also das Ziel, SchnitzelPress so zu gestalten, dass man mit eben dieser vorinstallierten Ruby-Version das Gem installieren, ein Blog erstellen und dieses auf Heroku schieben kann. (Für den letzten Punkt wird natürlich git benötigt. Ich bin mir aktuell nicht sicher, ob OS X 10.7 damit ausgeliefert wird; zur Not wird da aber der Heroku Toolbelt aushelfen, das Ding muss ich mir aber erst noch näher anschauen.)

Unter Windows wird die Sache noch spannender, denn es wird komplett ohne Ruby ausgeliefert. Hey, es ist Windows! Hier hängt alles am bereits erwähnten Heroku Toolbelt. Windows-User werden damit wahrscheinlich nicht so schnell ihr SchnitzelPress-Blog lokal zum Laufen bekommen, aber sie werden zumindest eines einrichten und auf Heroku pushen können, und das ist schon einmal ein guter Anfang.

(Über meinen “Platform as a Service”-Fetisch bloggte ich bereits in Regenbögen und Einhörner.)

Gemfury, Mozilla Persona, transparente Noise-PNGs

Private Gem-Server bei Gemfury: wer Gems entwickelt, die nicht für die Öffentlichkeit bestimmt sind, sollte sie nicht auf rubygems.org hochladen, sondern auf einen privaten Gem-Server. Wer so etwas nicht selber einrichten kann oder will, findet hier eine alternative Lösung.

Aus BrowserID wird Mozilla Persona: na, da bin ich ja schon mal gespannt. BrowserID ist das Identity Provisioning-Schema von Mozilla und gar nicht mal doof, zumindest nicht so doof wie OpenID, hust. _(SchnitzelPress benutzt BrowserID übrigens für den Admin-Login. Dazu bald mehr.)

Transparente Noise-PNGs bei noisepng.com: wahnsinnig hilfreiches Tool, das im Gegensatz zu vielen anderen seiner Zunft transparente Noise-PNGs generiert. Von denen eines jetzt auch auf diesem Blog (und bald allen anderen SchnitzelPress-Blogs) zum Einsatz kommt.

Video des Tages, weil YouTube-Embeds in SchnitzelPress so viel Spaß machen:

Sublime Text 2

Sublime Text 2 in Aktion, woohoo!

Jetzt ist es auch für mich an der Zeit, etwas Werbung für Sublime Text 2 zu machen. (Alle vim-Jünger halten sich nun bitte einmal die Augen zu und denken an Regenbögen und Einhörner. Oder was auch immer.)

Sublime Text 2 ist ein (noch relativ) neuer Texteditor für Programmierer, der zur Zeit auf eine ähnliche Art gefeiert und geliebt wird wie TextMate, als TextMate noch neu und cool war und tatsächlich weiterentwickelt wurde. (Kommt mir nicht mit TextMate 2. Was für ein Witz.)

Was macht Sublime Text 2 so toll?

  • Alles, was man von einem guten Code-Editor erwarten würde: solides Syntax Highlighting, Plugins, mächtige Suchfunktionen und all der Kram. Und zwar out of the box.
  • Er ist schnell. Verdammt schnell.
  • Man kann so ziemlich jede Facette des Editors auf die eigenen Bedürfnisse anpassen.
  • Kompatibilität mit den meisten TextMate-Bundles.
  • Aufteilbare Fenster und eine optionale Code-Minimap zur Übersicht.
  • Optionaler vim-like-Modus für alle, die darauf stehen.
  • Er wird aktiv weiterentwickelt; die Dev-Builds sind sehr stabil, alle paar Tage erscheint ein neuer.
  • Es gibt ihn für OS X, Linux und Windows.

Super. Wie lege ich mit Sublime Text 2 los?

  • Die aktuelle Beta gibt es hier, die Dev-Builds hier. Ich kann letztere wirklich sehr empfehlen. Sie sind stabil, und alle paar Tage darf man sich über tolle neue Features freuen.
  • Plugins müssen in der Regel von Hand installiert werden. Wer es etwas komfortabler mag, sollte sich Package Control installieren, ein Plugin, das die Installation anderer Plugins, Themes und so weiter stark vereinfacht.
  • Wer das Standard-UI-Design nicht mag, sollte sich das Soda Theme installieren, das es in einer hellen und einer dunklen Variante gibt.

Die Konfiguration des Editors läuft aktuell über Textdateien, ein entsprechendes UI ist in Arbeit. (Für alle zwei von euch, die das interessieren könnte, hier meine Preferences.sublime-settings.)

Selbstverständlich gibt es heute schon einen ganzen Berg an Plugins; eine gute Übersicht findet ihr hier.

Sublime Text 2 ist Shareware und kostet $59; es gibt jedoch keinerlei Einschränkungen, man wird lediglich gefühlt einmal am Tag durch eine kleine Dialogbox an den noch ausstehenden Kauf erinnert.

Update: aufmerksamen Lesern ist an dem oben gezeigten Screenshot aufgefallen, dass ich Sublime Text 2 selber noch nicht gekauft hatte. Hätte ich natürlich schon längst tun sollen; wenn man schon selber Werbung für so ein Tool macht, hat man es wohl genug evaluiert. :D

BAM, gekauft!