Geiler Titel eh? Trotzdem das Ergebnis gut replizierbarer wissenschaftlicher Forschung. Hach die Ironie.

Hier gibt es dazu einen sehr schönen Artikel. (via fefe)

Darauf bin ich heute gestoßen.

Interessant.

Was mir durch den Kopf geht: Schade, What goes around comes around, wie geht es mit Liquid bei den Piraten weiter? Wie geht es bei dem Projekt weiter wenn die haupt-Triebfeder nicht mehr treibt?

Mal nachdenken.

Diese ganze Terror-Panik-Mache geht mir sowas von auf den Geist - das ich in Diskussionen dazu schon immer ganz ungemütlich werde.

Und immer fallen mir dann die entscheidenden Argumente dazu nicht ein - zum Beispiel zu so einem Security-Theater wie gerade am hier am Bahnhof, wo irgend ein Arsch eine Tüte hat stehen lassen und für Stunden der ganze U-Bahnhof gesperrt war und alle U-Bahnen weiträumig umgeleitet / gesperrt wurden.

Grah!

Da kann ich mich doch nur einem Blogpost von Bruce Schneier anschließen:

I am not afraid of terrorism, and I want you to stop being afraid on my behalf. Please start scaling back the official government war on terror. Please replace it with a smaller, more focused anti-terrorist police effort in keeping with the rule of law. Please stop overreacting. I understand that it will not be possible to stop all terrorist acts. I accept that. I am not afraid.

Jawoll!

Bitte anschließen - und das Video dazu kucken.

Bei den Gorleben Protesten kriegt man ja inzwischen doch eine ganze menge gute Informationen - sogar manchmal über die großen Medien. Und man interessiert sich auch mal ein wenig zu dem Thema.

Sehr gut gefallen hat mir dabei diese Quarks & Co Sendung die ich hier auch wärmstens weiterempfehlen möchte.

Vor allem war mir überhaupt nicht klar WIE groß die Katastrophe in der Asse derzeit eigentlich ist.

Anschaubefehl.

Ein paar Gedankenanstöße:

• Wenn es eine Stelle gibt an der so gegen sämtliche Regeln des Verstandes und der Sicherheit verstoßen wurde
• Dann gibt es in der Nähe von dieser Stelle noch mehr ähnliche Probleme
• Eines davon zum Beispiel das AKW Biblis. Die Techniker dort wollen es nicht mehr Reparieren da sie dann "... mit einem Bein im Gefängnis ständen...".
• Jetzt bitte genau nachdenken wie viele dieser Problemfälle immer noch vor uns Geheim gehalten werden.

grusel

Update: Wer noch nicht genug gegruselt ist, dem empfehle ich diesen Podcast mit Sebastian Pflugbeil der sich als Atomphysiker mal den Reaktor in Tschernobyl sehr genau angeschaut hat (er ist dort gewesen!).

1. Die Castoren sind (durch die Strahlung?) 120 grad heiß wenn sie geliefert werden, Eier die man darauf wirft verkohlen sofort. :-)
2. Die Castoren müssen erst mal 30 Jahre auskühlen bevor sie überhaupt in einer Salzmine endgelagert werden können
3. Diese 30 Jahre stehen sie in einer Blechhalle nicht weit von Gorleben und strahlen da (hoffentlich nicht) vor sich hin
4. Bevor sie in Gorleben eingelagert werden können müssen sie noch in kleinere Behälter 'Pollux' genannt umgefüllt werden
5. Die Technologie dafür gibt es noch gar nicht
6. Gorleben als Endlager ist noch gar nicht genehmigt

Krass. via

Grade dachte ich mir ich mache mal wieder zum Spaß etwas an einem Open Source Projekt, checke es aus und will es mal bauen um etwas im Code herum zu lesen - und das erste was mir passiert ist das der Build-Prozess einfach irgendwann verstirbt.

Nach einiger Debugging Zeit stellt sich dann heraus das das selbstgestrickte build-system (eine Sammlung von Shell-Scripten) halt nicht mit spaces im Pfad zu den Sourcen klarkommt.

Gnarf! Wieso macht man sowas in Shell? Muss das sein?

Ok, aber es gibt ja workarounds, und die kenne ich ja auch und die lassen sich ja auch relativ einfach einbauen. ABER: Nicht mal die Abhängigkeiten ([pkg-config] in diesem Fall) baut mit spaces im Pfad.

ARGH!

Und natürlich haben die ein Autohell buildsystem an das ich nun wirklich nicht ranfassen will. :-(

Wie sollen wir als Softwareentwickler eigentlich irgendwann zu dem Punkt kommen wo unsere Software auch nur so etwas einfaches wie Pfade korrekt verarbeitet - also mit Leezreichen, Umlauten und Sonderzeichen (jep '/' ist auch gemeint) - wenn nicht mal unsere Eigenen Build-Tools und Shell-Sprachen damit verlässlich klar kommen? Also die Basis auf die einfach immer wieder zurückgegriffen wird?

Unglaublich.

Die Ruby Welt verwendet Blöcke (Closures) liebend gerne für alles mögliche. Zum Beispiel als Builder-Methapher um Baumstrukturen (XML, GUI's, HTML, Tests) in der Sprache hinzuschreiben und dann nur noch in die Target-Sprache zu rendern.

Das sieht in Tests zum Beispiel so aus:

describe "something" do

  it "should do fnord" do
    someObject.should be_fnordy
  end

end

Der Trick dabei ist das alles von do bis end jeweils ein Block ist der von der Methode describe oder it dann in eine UnitTest Klassenstruktur eingehängt wird um dann später als 'ganz normale' unit tests ausgeführt zu werden.

Jetzt wo Objective-C auch Blöcke unterstützt (ok, die können natürlich weniger als das Ruby Equivalent) müsste das eigenltich auch gehen - und siehe da mit Cedar gibt es auch schon einen ersten Versuch RSpec in Objective-C nachzubauen.

Well und daher habe ich mir mal angeschaut wie weit man denn kommt wenn man in Objective-C einen Block in eine Instanz-Methode umwandeln will.

Gleich vorneweg - das Typ-System von Objective-C macht mir hier einen kleinen Strich durch die Rechnung - ich habe es nicht geschafft einen Block nicht direkt als Funktions-pointer verwenden.

Aber mit etwas Umweg geht es doch.

Der Trick ist das Blöcke auch id's sein können, d.h. man kann sie bequem in ein NSMutableDictionary packen.

Also brauche ich auf meiner Klasse nur ein Dictionary, speichere die Blöcke darin mit dem Namen der Methode ab und baue mir einen generischen Dispatcher-IMP der den Selector (zweites unsichtbares Argument jeder Objective-C Methode) verwendet um den Block aus aus dem Dictionary zu ziehen und führe ihn dann einfach aus.

[source:/open-source/adding-blocks-as-methods/trunk/AttachBlocksAsMethods.m So sieht dass dann aus]

Sowas wünsche ich mir auch mal für andere Programmiersprachen. Eine ständig aktuelle Hitliste der schönsten Testsuiten von Open Source software.

Sowas hier - aber systematisch und crowdsourced immer aktuell.

Hach, man kann träumen. :-)

Klarträumen ist etwas das ich gerne lernen möchte und das mich derzeit beschäftigt. Erste Resultate habe ich schon - denn nach Jahren in denen ich mich vielleicht an einen Traum pro halbes Jahr erinnern konnte, erinnere ich mich jetzt an ein bis drei Träume pro nacht.

Stattlich. :-)

Sehr gut funktioniert für mich dass ich vor dem Schlafengehen via iPhone noch ein zwei YouTube Videos zu Klarträumen sehe um mich a) fortzubilden und b) mein Gehirn mit Klarträumen zu beschäftigen um die Warscheinlichkeit zu erhöhen dass ich mich an Träume erinnere (und später dass ich in einem Traum merke dass ich träume).

Eine super Einführung finde ich nach wie vor Reece Jones 2, 3, aber auch andere Videos von ihm sind interessant (gleiten allerdings recht schnell in viel zu esoterische Gefilde ab für meinen Geschmack).

Abends (und morgens bevor ich noch einmal zum Träumen einschlafe) verwende ich momentan zur Beschäftigung mit meinem Träumen die Videos von Lucidipedia die zwar etwa länglich, dafür aber gut verständlich und sehr Detailreich gute Tips zum Träumen geben. Besonders gefallen mir daran die vielen Beispiele die er gibt und die Art wie er sie erklärt.

Noch ein paar Webseiten:

• Wikipedia
• Wikibook
• Lucidipedia
• Lucidity Institute

Aber auch eine einfache YouTube Suche bringt erstaunlich viele Ergebnisse.

Well, I just finished some major reworking of that jQuery plugin, so now it has [browser:/open-source/jquery-edit-in-place/trunk/spec/unit/spec.js a real testsuite] and conforms to the jQuery Plugin Guidelines and doesn't pollute the core prototypes (of String) anymore.

There are a few new features, most prominent the ability to define a class to apply for the hover effect (so you can style the hover in css instead of having to hand in the colors directly and more control over the way errors are presented so it is easier to embed into bigger applications.

So enjoy the demo and the download while they are hot, and keep a bookmark to the project homepage. :)

Stuff I'd like to note:

• JSpec rocks, writing tests with it is a breeze. The DOM Testrunner they have could use some work though to become even more usefull
• Writing the tests with no dom insertion is a great technique to get a fast testsuite where you can almost guarantee that it has no test-ordering issues.
• jQuery allows you to almost completely drive the interaction with the editor as a user would, making it almost like an acceptance test (and with very little dependency on the internal working of the editor.
• Refactoring JavaScript Code is hard if you don't have a testsuite. My Advice: Break it down into smaller bits. I found it incredibly hard to refactor larger pieces of the code, as not having a testsuite means there's no way you know what still works. :/