//dennisbloete

Ein kurzes Fragespiel zwischendurch, weil ich in letzter Zeit mehrmals drüber gestolpert bin und gern mal mehrere Meinungen dazu hören würde: In welcher Sprache programmiert ihr? Alles straight english oder habt ihr Projekte, in denen ihr mit deutschen Begriffen arbeitet?

Ich selbst verwende nur englisch, habe in letzter Zeit aber wie gesagt ab und zu gesehen, dass Leute auch durchaus deutsch benutzen, was man natürlich auch logisch begründen kann: Liegt dem Projekt eine komplizierte Domain zu Grunde, so lassen sich Fachlichkeiten besser und eindeutiger in der Sprache beschreiben, die man auch mit dem Kunden verwendet. Ein weiterer Unterschied liegt in der Formulierung der Testfälle/Spezifikationen: Zumindest mir geht es so, dass sich die Anforderungen in deutsch besser beschreiben lassen, als in englisch – klar, ein unnötiger Abstraktionsschritt weniger.

Wie haltet ihr das und was sind eure Gründe dafür? Bei mir ist es bisher vielmehr ein rein ästhetischer Grund, warum ich vom Sprachmix abgesehen habe und mich würde gern mal eure Meinung dazu interessieren.

Technorati Tags: Programmierung, Sprache

Da ich mir eben selbst die Mühe gemacht habe, aus den einzelnen Spezifikationen Migrations für Länder (ISO3166), Sprachen (ISO639) und Zeitzonen (TimeZone Database) zu erstellen, dachte ich es könnte wahrscheinlich für den ein oder anderen nützlich sein. Ist zwar relativ schnell gemacht (RegExps to the rescue), aber so schön ist so eine Arbeit dann ja doch nicht – hier also das Ergebnis als Archiv: Rails-Migrations for Countries (ISO3166), Languages (ISO639) and Timezones.

Technorati Tags: Rails, Migrations, Timezones, Languages, Countries

Test-first ist für Feiglinge und sooo 2000 – wer was auf sich hält switcht spätestens nach diesem Artikel und springt auf den EDD-Bandwagon. EDD – alles klar?

Exception Driven Development

No code is faster than no code – was für die Applikation gilt, lässt sich auch 1A auf Tests und Spezifikationen anwenden, daher hier Credo Nr. 1:

No test is faster than no test.

Damit erübrigen sich auch die ganzen Diskussionen um langsame Tests durch zu viele Fixtures oder das ganze Mock/Stub-Geraffel. Test less!

Wer von sich überzeugt ist, deployed ohne Testsuite – no coverage is the new black. Ich weiss, das klingt fremd und sehr wagemutig – aber kein Ding, denn du musst diesen Weg nicht alleine gehen. Es gibt Hilfe, denn selbst die Besten machen Fehler – Exception Notifier to the rescue.

Spätestens wenn eine Anwendung in Produktion läuft, zahlen sich die Vorteile von EDD dank des Plugins voll aus: Du musst nicht mehr nach den Fehlern suchen, sie kommen zu dir – per E-Mail! Jede geworfene Exception erreicht dich per E-Mail und liefert dir detaillierte Informationen über den Fehler, so dass du ganz bequem das Error-Backlog aus deinem Postfach heraus abarbeiten kannst.

Klingt heftig und dabei ist hier noch nicht einmal Schluß – treiben wir es auf die Spitze…

Soon to be released: Mister EDD

Um euch allen den Einstieg in EDD zu erleichtern, schnüre ich aktuell ein feines Rails-Plugin zusammen, dass euch am Anfang etwas unter die Arme greift und Rails-like sehr opinionated zur Sache geht: Bei der Installation wird zunächst als Dependency das Exception Notifier Plugin installiert (sofern du es nach dem letzten Abschnitt nicht schon selbst eingebunden hast).

Next Step: Test- und Spec-Verzeichnisse werden gelöscht, wenn schon, denn schon… you cant be any geek off the street, gotta be handy with the steel if you know what I mean, earn your keep!

Zu guter letzt werden noch die Rails- und RSpec-Generatoren überschrieben, so dass in Zukunft keine störenden Tests mehr generiert werden  (danke für den Hinweis, Jan).

Denkt mal drüber nach

Vor einiger Zeit habe ich mal eine kleine Liste von Rails-Alternative zusammengestellt und mir dieses Wochenende die Zeit genommen, mich mal genauer umzusehen. Durch einen Artikel auf Ruby Inside bin ich auf Waves gestoßen, welches den Anspruch hat, “the next-generation framework” zu werden. Ob dem nun wirklich so ist sei mal dahingestellt, Fakt ist aber, dass sich aktuell etwas bewegt und rechts und links von Rails interessante neue Alternativen entstehen.

Die Kernbestreben dabei sind immer, thread-safe und leichtgewichtiger als Rails zu sein – womöglich auch noch ohne unnötige Abhängigkeiten wie beispielsweise bei der Wahl des ORM-Layers oder der Templating-Engine einzuführen. Da ich in letzter Zeit immer mehr darüber gelesen habe, stand es nun mal an, mir Merb genauer anzugucken. Dazu hier ein paar Gedanken und Verweise auf weitere Quellen dazu.

diesen Eintrag lesen »