Nichts nicht gleich false

Meine Güte, Konstruktionen wie diese gehen mir sowas von auf den Wecker:

select_options.insert(0, [blank_message, ""]) if include_none || (this.nil? && include_none != false)

include_none nicht gleich false!! Das ist ja schon dreimal verneint, oder wie? Ich mag nicht dreimal um die Ecke denken!

Code Metrics

Hochinteressant! Netter Hinweis in Jeff Atwoods Blog Coding Horror auf spartanisches Programmieren:

Spartan programming is a programming discipline by which the programmer tries to minimize use of various elements of the programming language which may contribute to complexity. The main motivation of the discipline is that terser programs are easier to understand, and therefore tend to be more correct.

Genau! Gute Idee!

Ruby hat heute Geburtstag und wird 15!

Um das gleich mal festzuhalten, Ruby wird heute, am 24. Februar 2008, 15! Habe ich hier: Ruby Turns 15 and Other Important Stuff - O'Reilly FYI gelesen:

David Flanagan, author of many books including most recently The Ruby Programming Language
observed that this month marks Ruby’s 15th birthday. David
confirmed with Yukihiro “Matz” Matsumoto–creator of
Ruby and David’s coauthor on the aforementioned book–that,
indeed, Ruby was conceptualized and named on Feb. 24, 1993. Mark your
calendars.

Zum 10. Geburtstag gratulierte David A. Black: [ANN] Happy Birthday, Ruby, and an announcement....

Today, February 24, 2003, is Ruby's 10th birthday.** Happy Birthday,Ruby! And congratz to Matz!

Und selbst in einem Kalenderblatt des bayerischen Rundfunks vom 24.02.2005 geht es um Ruby, das war dann wohl anlässlich des 12. Geburtstags.

XML People

In einem wunderbaren Artikel - XML People - beschreibt Tim Bray die Personen, die mit der ursprünglichen Entwicklung von XML zu tun hatten. Hat mich sehr fasziniert, wie er die Menschen hinter der Technologie lebendig werden lässt, ihr Aussehen, ihre Persönlichkeit, ihre Rolle und ihren Beitrag charakterisiert. Was mich wirklich neugierig machte und ich anfing Bilder von Ihnen im Internet zu suchen. Hier das Ergebnis, die Begründer und Erfinder von XML, jeweils kurz wie Tim Bray sie charakterisiert, und dazu ein Bild.

"Ted · Theodore Holm Nelson looks like Peter O’Toole, with a personal style similarly extravagant."




"TimBL - Tim Berners-Lee is thin, pale, and twitchy, a well-bred British baby-boomer who circumlocutes and temporizes and gets to the point slowly."




"Charles · Charles F. Goldfarb is a Jew from New York who got a Harvard law degree and went to work for IBM.Charles, fiftyish now, is dark, burly, balding, bearded, Californian. (...) He wears Western-style string ties, talks energetically with a lot of hand movement and still a New York rasp."




"Yuri · Yuri Rubinsky died in early 1996 (suddenly, of a heart attack) before our story really got started,...Yuri, a Canadian of Russian descent; was born in Beirut, Lebanon (a place we’ll hear from again) and, and while his family was Gentile as far as he knew, looked like a caricature of a mid-European Jewish intellectual."




"Jon · Jon Bosak is a writer who escaped into high tech from the inspiring but stingy publishing world; not the first by any means.(...) Jon, another boomer, is shortish, and looks like the child that might have been born to John Lennon and a Kennedy."




"James · James Clark is a computer programmer. (...) His ancestors made enough money that he, a GenXer, doesn’t really have to work. He is our story’s second Englishman, but is less polished and much more direct than TimBL."




"Tim · This is me, a fortysomething Canadian raised mostly in Beirut (there it is again). (...) I’m average size, average weight, fair, largely bald, with a vaguely Mennonite look caused by wearing a beard sans mustache, and speak average toneless mid-North-American."




"Eve · Eve Maler, a Honolulu-born boomer now in suburban New England, toiled for years, like Jon, in the techdoc mines. (...) Eve is buxom, curly-haired, full of smiles. Some people foolishly conclude that she is a technical lightweight and usually end up exposing their foolishness in public."




"Michael · C. Michael Sperberg-McQueen has a name that is unusually long by any standard...Michael, about 8 feet tall, correspondingly broad-shouldered, and with a bit of middle-aged spread...He is at all times in strict conformance with the dress code of the Midwestern academic: tweeds, checks, scarf, cloth cap."




"Lauren · Lauren Wood is a New Zealander whose adult life has been in Australia andGermany. (...) Lauren is smallish, slenderish, dark-haired, pale-skinned, large-eyed, and speaks with an Auckland lilt that can veer into complete opacity on
words with a strong “O”, such as “word” and “cold”. She is cheerful, patient, and very good company. (...) We were married in November 1996, just after XML was unleashed on the world."




"Jean · Jean Paoli is a citizen of France but really Lebanese, a typical Levantine ethnic cocktail: dark, burly, hirsute, chubby-faced."




"Phil · Phil Karlton died in 1997 (in an Italian auto accident while on vacation), so only takes a brief turn on this stage. (...) Phil was an ugly bald whiskery sweet man, with lots of rough edges and an
apparently-perfect 20-year marriage that, I think, intimidated many whose
relationships are more mundane and compromise-laden."

Heise Full Content News Feed mit Yahoo Pipes

Problem? Der Newsfeed von Heise heise online News enthält lediglich die Titel der News, aber keinerlei Newsinhalt. Wie könnte man sich einen Newsfeed basteln, der Titel und gesamten Inhalt der News liefert?

Ich hatte Yahoo Pipes schon fast wieder vergessen, was können die nochmal?

Like Unix pipes, simple commands can be combined together to create output that meets your needs:

• combine many feeds into one, then sort, filter and translate it.
• geocode your favorite feeds and browse the items on an interactive map.
• power widgets/badges on your web site.
• grab the output of any Pipes as RSS, JSON, KML, and other formats.

Sounds good? Learn more....

Und ob das gut klingt! Es hat dann zwar nicht gleich auf Anhieb ganz so wunderbar funktioniert, letztendlich aber doch:

• RSS Feed: http://pipes.yahoo.com/pipes/pipe.run?_id=a2e958a7f509f5c094a81c142aad9edc&_render=rss
• Pipe Info: http://pipes.yahoo.com/pipes/pipe.info?_id=a2e958a7f509f5c094a81c142aad9edc
• Pipe Source: http://pipes.yahoo.com/pipes/pipe.edit?_id=a2e958a7f509f5c094a81c142aad9edc

Wie funktionierts? Eigentlich recht übersichtlich:

• "Fetch Feed" Modul holt den vorhandenen Heise Newsfeed (er wird in eine interne Struktur von "Items" geparsed, auf die man dann z.B. mit item.summary oder item.title Zugriff hat)
• "Truncate" entnimmt nur die ersten 10 Einträge
• "Loop" ruft für jeden Eintrag
• "Fetch Page" auf, die Seite des Newsbeitrags selber wird geholt und durch Angabe eines Von- und Bis-Strings der Nachrichtentext herausgeschnitten
• der Ausschnitt wird im Item (item.content) abgelegt
• "Rename" benennt item.content.content dann noch in "description" um. (Für RSS Feeds muss das "description" heißen)
• "Pipe Output" gibt das Ergebnis aus

Fazit? Irgendwie schon faszinierend. Und dafür dass man das mit einem graphischen Tool im Webbrowser zusammenklickt/schiebt/konfiguriert (kann man da Programmieren dazu sagen? Immerhin ist eine Loop dabei?), kann man scheinbar doch ganz faszinierende Funktionalitäten kreieren. Und wenn man sich überlegt, dass es mehr solcher Tools im Internet gibt, siehe z.B. sowas wie Dapper: The Data Mapper (kann auch Webseiten parsen) und dass man die mit einem Tool wie Yahoo Pipes ja alle irgendwie zusammenbinden kann ohne lokal auch nur irgendetwas installieren zu müssen, ja, das ist schon faszinierend.

Irgendwer noch andere Ideen, was man mit Yahoo Pipes probieren könnte?

Javascript wiederentdeckt!

Im Prinzip hatte ich mich ja vor Jahren schon mal kurz mit Javascript beschäftigt, es dann aber auch wieder für Jahre vergessen, weil es keinen rechten Anlass für mich gab es zu verwenden, und ja, natürlich gab es zwischenzeitlich AJAX, und das hätte Anlass genug sein können, sich wieder damit zu beschäftigen, aber nein, auch da nicht, ich weiß gar nicht recht, was mich jetzt eigentlich animiert hat...

Den meisten Spaß beim (Wieder-)Einstieg machte letztlich der Javascript-Papst Douglas Crockford mit Artikeln wie JavaScript: The Wrrrld's Most Misunderstood Programming Language. Ein fast schon legendärer "und überhaupt"- und "wie alles kam"-Artikel. Im Yahoo! User Interface Blog gibt es auch ein paar Videos einiger seiner Vorträge wie z.B. Video: JavaScript oder Video: Advanced JavaScript (und dort kann man jeweils noch die gezeigten Folien als Powerpoint-Dateien herunterladen). Und viel mehr muss man erstmal auch gar nicht wissen.

Das einzige Buch zu Javascript, das Crockford überhaupt nur empfehlen kann, ist übrigens JavaScript. The Definitive Guide von David Flanagan, und der wiederum hat auch letztens The Ruby Programming Language (ziemlich eins der ersten Ruby-Bücher überhaupt, von matz persönlich) überarbeitet und erweitert und aktualisiert für Ruby 1.9. Kann erst vorbestellt werden, kommt Anfang 2008. Und die Illustrationen sind von "why the lucky stiff"!

Supple Design / "Geschmeidiges" Design

Wunderschöne Sätze in dem Buch von Eric Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software gefunden. In Kapitel 10 geht es um "Supple Design". Und was heißt "supple" überhaupt? Aha, LEO D-E Ergebnisse für "supple": geschmeidig, gefügig, biegsam!

Eine frei übersetzte Kostprobe:

Der eigentliche Zweck von Software? Einem ganz bestimmten Zweck für Benutzer zu dienen. Doch zunächst einmal muss Software Programmierern dienen. Insbesonders, wenn es um Refactoring geht. Im Verlauf der Entwicklung eines Programms wird jedes seiner Teile irgendwann neu geschrieben, die Teile werden neu strukuriert, neu angeordnet, "Domain Objects" werden integriert, umgestaltet, mit vorhandenen verbunden oder wieder auseinandergenommen. Auch noch nach Jahren wird der Code geändert und erweitert. Menschen müssen an diesem Gebilde arbeiten. Frägt sich nur, ob sie das auch wollen?

Wenn etwas kompliziertere Software kein gutes Design hat, wird es nämlich unendlich schwierig sie umzubauen, Elemente neu zu kombinieren, ein "Refactoring" durchzuführen. Wenn ein Entwickler nicht mit gutem Gefühl die Auswirkungen einer Änderung einigermaßen abschätzen kann, wird er eine Funktionalität einfach nochmal programmieren, und so entsteht "Duplication". Sie entsteht auch, wenn ein Design zu große Blöcke enthält, zu monolithisch ist. Zwar kann man Klassen und Methoden mit dem Ziel besserer Wiederverwendbarkeit feiner aufbrechen, aber dann wird es oft schwierig zu verstehen, was all die kleinen Teile machen.

Eine Software ohne klares Design mögen sich Entwickler kaum anschauen, geschweige denn mögen sie Änderungen an dem Schlamassel vornehmen, die womöglich Fehler an anderer Stelle durch kaum durchschaubare Abhängigkeiten verursachen. Abgesehen von sehr, sehr kleinen Systemen verhindert diese Zerbrechlichkeit, dass Software ein bestimmtes Maß an Funktionalität überschreiten kann, sie verhindert Refactoring und schrittweise Verbesserungen.

Ein Projekt, das in seinem Verlauf Fahrt aufnehmen und Schwung entwickeln, und nicht unter seinem eigenen Gewicht zusammenbrechen soll, setzt voraus: Ein Design, mit dem es Freude macht zu arbeiten, ein Design, das zu Änderungen einlädt. Ein geschmeidiges Design.

Ja! Wunderbar! Geschmeidig muss es sein!

DesignStaminaHypothesis

In einem Blogbeitrag von Martin Fowler zu MF Bliki: DesignStaminaHypothesis folgende schöne Graphik gesehen:

die ich so oder ähnlich auch schon hie und da an die ein oder andere Tafel gemalt hatte. Meine Erklärung in etwa:

Wenn man am Anfang huddelt (wie schreibt man huddelt? hudelt?) kann man zwar schneller etwas vorweisen, später rächt sich dies allerdings, die Kurve wird immer flacher, d.h. für jedes bisschen mehr Funktionalität muss man immer mehr Zeit (und Energie) aufwenden: Die blaue Kurve. Im Extremfall erreicht die Kurve früher oder später eine waagrechte Asymptote, d.h. egal wie viel Zeit man investiert, man erreicht keine substantiellen Verbesserungen mehr. Stillstand auf hohem Niveau: Zwei Fehler beseitigt, dafür zwei neue verursacht.

Die andere Vorgehensweise wäre, zunächst Grundlagen zu legen, Architekturfragen zu klären, "ordentlich" vorgehen, usw.., d.h. dass man am Anfang erstmal sehr wenig sieht, später aber immer schneller mehr Ergebnisse produzieren kann: Siehe die rote Kurve.

Irgendwo mittendrin schneiden sich die Kurven, bis zu diesem Zeitpunkt kommt man letztendlich mit der blauen Kurve besser weg, ab da allerdings klar mit der roten.

Wie drückt das Martin Fowler aus?

Design activities certainly do take up time and effort, but they payoff because they make it easier to evolve the software into the future. You can save short-term time by neglecting design, but this accumulates TechnicalDebt which will slow your productivity later. Putting effort into to the design of your software improves the stamina of your project, allowing you to go faster for longer.

Was eigentlich nicht vorkommt ist, dass sich der Prozess linear verhält: So wie man beispielsweise einen Graben gräbt. Halber Tag = 5 Meter, 5 Tage = 50 Meter.

Einem EDV-Profi mag das klar sein, einem EDV-Laien nicht unbedingt. Der würde sich vielleicht folgende Gedanken machen und Fragen stellen:

Blaue Kurve: Sie waren doch letztens schon so weit, und jetzt soll es doch noch so lange dauern? Sie waren doch letztens schon fast fertig?
Rote Kurve: Na, wie läufts? Oh, man sieht quasi noch gar nichts? Oder fast gar nichts? Wie wollen Sie da bis nächste Woche/Monat/Freitag/xxx fertig werden?

Und was Stamina auf Deutsch heißt, könnte man auch mal eruieren...

Big Ball of Mud / 7

Na, ein kleines Zitat aus Big Ball of Mud geht noch, oder? Ist auch ganz kurz:

Das rituelle Zurschaustellen von "Cleverness" verbessert oft den Rang in der Programmierer-"Hackordnung" eher als handwerkliche Merkmale wie Einfachheit oder Klarheit. Und so gedeiht das, was glorifiziert wird.

Alles klar?

Meine erste C# Windows Applikation!

Weiß nicht, wie ich da heute draufgekommen bin, vielleicht weil hier so lustig stand:

Lernen Sie, wie Visual Studio Express Editions Ihnen helfen können, Spaß bringende, coole Projekte zu erstellen, die Sie auf Ihrem Windows Desktopclient ausführen können.

Ja, ja, "Ihnen helfen können"! Wie war das: Da wird Ihnen geholfen? Aber das macht einen schon ein wenig heiß: "Spaß bringend", "coole Projekte".... Also, runtergeladen, installiert, gestartet, und dann noch in der Hilfe das gefunden: "How to: Build a C# Application in 60 Seconds", und schon war das Windows Forms Hello World fertig:

private void button1_Click(object sender, EventArgs e)
{
   label1.Text = "Hello, World!";
}
Supercool, oder?

Big Ball of Mud / 6

Nachtrag zu Big Ball of Mud / 5: Lt. eines englischen Muttersprachlers ist "the most complicated system that can possibly work" sowas wie "das komplizierteste System, das gerade noch funktioniert", was auch irgendwie Sinn macht.

Und gleich weiter, die nächsten schönen Zitate:

Solche Programme können eine persönliche Festung werden, die zwar selbst der Autor kaum noch verstehen kann, jeder andere aber noch viel, viel weniger. Und sobald simple Reparaturen am Programm Tagesbeschäftigungen werden, verwandelt sich das Programm in einen Sumpf. Es wird für das Management zunehmend schwierig vorherzusagen, wie lange diese Reparaturen eigentlich dauern sollten. Dinge, die simpel zu bewerkstelligen sein sollten, ähneln eher einem nicht enden wollenden Schützengrabengefecht. Alle müssen sich in dieses absurde Tempo fügen. Manche finden sogar Gefallen daran, verstecken sich in ihren gemütlichen Höhlen, und machen ihre "Zwei-Zeilen-pro-Tag"-Reparaturen.

Big Ball of Mud / 5

Systeme werden rasch komplizierter, allerdings nur bis zu einem gewissen Punkt:

Die Antriebskräfte für die Evolution solcher System sind bisweilen pervers. So wie es einfacher ist geschwätzig zu sein, als präzise, ist es leichter komplexe Systeme zu schaffen als einfache. Dafür begabte Programmierer können Komplexität schneller schaffen als ihre Kollegen, und schneller als sie sie dokumentieren und erklären können. Und so wie eine Armee ihren Logistikzug abhängt, steigert sich die Komplexität bis zu dem Punkt, wo dieselben Programmierer gerade nicht mehr damit klar kommen.

Dies wird manchmal auch als "Peter Prinzip" der Programmierung bezeichnet. Komplexität steigert sich schnell bis zu einem Grad, an dem Programmierer gerade nicht mehr damit zurecht kommen. An diesem Punkt geraten Komplexität und unsere Fähigkeiten in ein ungutes Gleichgewicht. Der Blitzkrieg verwandelt sich in eine Niederlage. Wir schufen das komplizierte System, das gerade noch funktionieren kann.

Mann, da ist noch viel verbesserungswürdig! Wie sagt man auf gut Deutsch: Das komplizierteste System, das "can possibly work". Das womöglich funktionieren könnte?

Big Ball of Mud / 4

Und noch etwas aus dem Big Ball of Mud-"Pattern":

Und letztendlich unterscheiden sich Programmierer in ihren Fähigkeiten und ihrem Engagement für Architektur. Leider wurde Programmarchitektur so lange gering geschätzt, dass viele Programmierer den Big Ball of Mud als Normalfall ansehen. Manche Programmierer sind auch besonders begabt sich in diesen Sümpfen zurecht zu finden und andere durch sie zu führen. Irgendwann kann die Symbiose zwischen Programmarchitektur und Fähigkeiten das Wesen einer Organisation selber verändern, und Sumpfführer wertvoller als Programmarchitekten werden. Undurchschaubarer Code kann dann sogar einen echten Wettbewerbsvorteil für die bringen, die sich in dem Kladeradatsch noch zurecht finden. In einem Land ohne Grenzsteine, ohne Markierungen werden solche Führer überlebenswichtig.

Big Ball of Mud / 3

Ich hatte ja hier und hier schon ein paar Übersetzungsversuche von "Big Ball of Mud" probiert. Wie wäre es andererseits mit

• "Riesenklumpatsch" (steckt Klumpen und Matsch zugleich drin), vielleicht auch verwegen gesteigert als "Gigantischer Riesenklumpatsch"?!
• Oder vielleicht "Riesenschlamassel" (da hätten wir Schlamm und Masse drin)?
  
• Gigantischer Riesenschlamassel?
  
• Vielleicht noch Code dazu? Codeklumpatsch?
• Riesencodeklumpatsch?
• Finaler Codeschlamassel?
• Gigantischer Riesencodeschlamassel?
• Riesenklumpatsch an Code?
• Riesenklumpatsch matschigen Codes?
  

Big Ball of Mud / 2

Was gibts noch Schönes im Artikel Big Ball of Mud? Wie sollte man Big Ball of Mud jetzt übersetzen? "Großer Klumpen Matsch" oder "Riesenklumpen Matsch"?

Wie schaut nun der matschige Code für einen Programmierer an der Front, der sich damit beschäftigen muss, aus? Datenstrukturen sind sehr willkürlich gewählt, oder so gut wie nicht vorhanden. Alles hat mit allem zu tun. Jeder Teil des Programms "spricht" irgendwie mit jedem anderen. Wichtige Zustandsdaten sind ausnahmslos global. Manche könnten dies als eine Art "Blackboard"-Ansatz betrachten, aber es gleicht mehr einem Wühltisch an undifferenzierten und wahllosen Zustandsarten. Wo Zustandsinformationen einigermaßen örtlich abgegrenzt sind, werden sie hemmungslos über byzantinische Hintertüren ausgetauscht, und unterminieren so die eigentliche Struktur des Systems.

Variablen- und Funktionsnamen sind nicht informativ, oder sogar irreführend. Funktionen selber machen ausgiebigen Gebrauch von globalen Variablen, und von langen Listen mäßig definierter Parameter. Die Funktionen selber sind lang und verwickelt, und machen verschiedenste Dinge, die nichts miteinander zu tun haben. Der Programmablauf ist schwer zu verstehen und schwierig nachzuvollziehen. Die Absicht des Programmierers ist so gut wie nicht zu erkennen. Der Code ist schlichtweg unlesbar, und grenzt an Unentzifferbarkeit. Der Code zeigt alle Anzeichen fortwährender Patche verschiedenster Programmierer, von denen keiner so recht die Konsequenzen seiner Änderungen abschätzen konnte. Haben wir eigentlich schon Programmdokumentation erwähnt? Welche Dokumentation?

Großer Matschklumpen? Riesenmatschklumpen?

Big Ball of Mud

Hatte ich vor Jahren schon mal gelesen, dann wieder vergessen, und jetzt zu passender Gelegenheit wieder auf diesen wunderbaren Artikel über das verbreitete "architectural pattern" "Big Ball of Mud" gestoßen. Ich versuche mal, ein paar Sätze ansatzhalber auf Deutsch zu übersetzen:

Ein "Großer Haufen Matsch" ist ein willkürlich strukturierter, ausufernder, schludriger, notdürftig mit Tesa und Maschendraht zusammengehaltener Dschungel von Spaghetti Code. Wir haben ihn alle schon gesehen. Diese Systeme zeigen offensichtliche Merkmale von unkontrolliertem Wildwuchs und ständigem Herumgeflicke. Weit entfernte Teile des Systems teilen sich zügellos Daten, meistens so weitgehend, dass fast alle wichtigen Daten global oder dupliziert sind. Eine übergreifende Struktur des Systems wurde womöglich nie definiert. Falls schon, ist sie bis zur Unkenntlichkeit erodiert. Programmierer mit einem Fitzelchen Gespür für Programmarchitektur gehen diesen Schlammlöchern tunlichst aus dem Weg. Nur die, die sich keinerlei Gedanken über Architektur machen, oder sich vielleicht eingerichtet haben mit der Tag für Tag gleichen Tretmühle des Stopfens immer neuer Löcher in diesen rissigen Dämmen, sind zufrieden damit an solchen Systemen zu arbeiten.

Ruby: "dynamic hash-tree"

Beim Stöbern auf RubyForge: Snippet Library entdeckt: dynamic hash-tree, der

...stores objects in a tree structure, creating nodes automatically when needed.

Wenn man jetzt meint, dass das eine Menge Code wäre..., weit gefehlt! (Wie war das? The best code is no code at all, und das zweitbeste so wenig Code wie möglich?):

class Node < Hash
 attr_accessor :value

 def method_missing(key)
   self[key]==nil ? self[key]=Node.new : self[key]
 end
end

tree = Node.new

tree.branch.leaf.value = 'Hello World!'
tree.branch1.leaf.value = 'Hallo Hallo!'

tree                      # => {:branch=>{:leaf=>{}}, :branch1=>{:leaf=>{}}}
tree.branch.leaf.value    # => "Hello World!"
tree.branch1.leaf.value   # => "Hallo Hallo!"

Irgendwie magisch! Node erbt von Hash. Wird ein Node (tree = Node.new) mit einer unbekannten Methode aufgerufen (tree.branch), wird diese einfach in dem Node, d.h. dem Hash, es ist so einfach, dass ich es gar nicht gescheit ausdrücken kann....letztendlich entstehen mit dem method_missing - Trick in sich geschachtelte Hashes. Echt erstaunlich!

Reduzieren, beim Kochen und beim Programmieren

Jeff Atwood schrieb letztens einen wunderbaren Blogeintrag, Coding Horror: The Best Code is No Code At All:

"It's painful for most software developers to acknowledge this, because they love code so much, but the best code is no code at all. Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it. If you can't get away with no code, the next best thing is to start with brevity."

Gefällt mir: Der beste Code ist überhaupt kein Code. Und wenn's wirklich nicht anders geht, erstmal mit wenig Code anfangen. Und warum dann nicht auch vorhandenen Code verkürzen, reduzieren, warum:

Range("J8").Select
ActiveCell.FormulaR1C1 = "=NOW()"
Range("J8").Select
Selection.Copy
Range("N8").Select
Selection.PasteSpecial Paste:=xlPasteValues, Operation:=xlNone, SkipBlanks _
:=False, Transpose:=False
Range("J8").Select
Application.CutCopyMode = False
Selection.ClearContents

wenn man das aktuelle Datum/Uhrzeit auch so in eine Zelle von Excel schreiben kann:

range("n8")=now()

Reduzieren wäre dann auch kein Selbstzweck, sondern würde echten Mehrwert bringen: Code lesbarer, verständlicher, übersichtlicher, klarer, fehlerfreier machen.

Und was bedeutet jetzt Reduzieren beim Kochen?

"Flüssigkeit, die während des Kochens entstanden ist, wird reduziert, in dem man sie in einem offenen Topf bis auf einen gewünschten Rest verkochen läßt. Dies konzentriert den Geschmack der verbleibenden Brühe oder Soße."

Na also, warum ist Reduzieren beim Programmieren so wichtig? Weil es hinterher einfach besser schmeckt!

Ruby, creating classes dynamically

Eine Klasse "Klass" mit einer Methode "meth" würde man ja normalerweise so definieren und instanzieren:

class Klass
  def meth
    "soso"
  end
end

Klass.new.meth       # => "soso"

Angenommen, man hätte den Inhalt der Klasse als String vorliegen, könnte man das Gleiche so machen:

s = <<eos
  def meth()
    "soso"
  end
eos

Klass = Class.new()    # neue leere Klasse erzeugen und der Konstante "Klass" zuweisen
Klass.class_eval s      # "Evaluate" String (mit der Methodendefinition) im Kontext der Klasse

Klass.new.meth         # => "soso"

Angenommen, man hätte auch den Namen, den die Klasse erhalten soll, als String vorliegen, so:

s = <<eos
  def meth()
    "soso"
  end
eos

Kernel.const_set("Klass", Class.new())
Klass.class_eval s

Klass.new.meth         # => "soso"

Angenommen, der Name, den die Klasse erhalten soll, wäre auch in dem String mit dem Inhalt der Klasse als Konstante definiert:

s = <<eos
  NAME = 'Klass'         # <= so soll die Klasse später mal heißen
  def meth(); 'soso'; end
eos

c = Class.new
c.class_eval s
Kernel.const_set(c::NAME, c)

Klass.new.meth          # => "soso"

Schon erstaunlich, oder?

Design Challenges

Ich bin schon mal über das online verfügbare Kapitel 5 aus dem Buch Code Complete 2nd Edition von Steve McConnel gestolpert (siehe Managing Complexity). Heute fiel mir folgende Liste an "Design Challenges" aus dem gleichen Kapitel auf:

• Design is a wicked problem
  Wicked scheint sowas wie "teuflisch" zu heißen, also: Design ist ein teuflisches Problem. Warum? Man muss das Problem oft erst gelöst haben, um klar zu erkennen, was das Problem eigentlich ist. In der Regel muss man ein Problem zunächst lösen, um es klar definieren zu können, und dann erneut "lösen", indem man eine funktionsfähige Lösung schafft.
• Design is a sloppy process
  Das Endergebnis mag ordentlich und organisiert sein, der Weg dahin ist es nicht. Der Weg dahin ist voll von Fehlern, Missverständnissen und Irrwegen, was auch völlig ok ist. Design lebt von Fehlern, die dazu beitragen das Design zu verbessern.
  
• Design is about Tradeoffs and Priorities
  Abwägen, Kompromisse finden, Prioritäten setzen. Irgendwas bleibt immer auf der Strecke.
  
• Design Involves Restrictions
  Anything goes? Nein, eher Möglichkeiten einschränken.
  
• Design Is Nondeterministic
  Das Endergebnis ist nicht festgelegt. Man kann auf vielen verschiedenen Wegen ans Ziel kommen.
  
• Design Is a Heuristic Process
  Designtechniken, die wiederholbar ein vorhersehbares Ergebnis erzielen? Gibt es nicht. Eher eine Frage von Faustformeln, Versuch und Irrtum. Kein Werkzeug ist für alles geeignet.
  
• Design Is Emergent
  Ein Design "entspringt nicht fertig aus irgendjemandes Kopf", sondern entsteht graduell beim Entwickeln der Lösung, durch Design Reviews, Diskussionen, Erfahrungen beim Programmieren selber, usw..
  

Ja, hochinteressant, oder? Vielleicht sollte man sich das Buch anschaffen...