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. :/

Früher mal dachte ich, dass das ja in den Universitäten sein muss. Schließlich ist da alles auf einem fleck. Forscher und Lehrer und Schüler.

Optimale Bedingungen eigentlich - nur dass dort an der Lehre überhaupt nicht geforscht wurde. Schließlich war das ja nur ein Anhängsel das Zeit kostet. Kein Forschungsgebiet.

In der Schule natürlich sowieso nicht und danach?

Im Beruf?

Ich bin natürlich mein eigenes Forschungssubjekt, weil ich weiter lerne und das beobachte. Und für mich selber ist es natürlich so dass ich ständig mit Innovationen habe, durch meine Möglichkeit das Netz zu verwenden.

Aber ab und an trifft man auf etwas großartiges. In einem Interview von John Udell bin ich auf die Khan Academy gestoßen.

Das ist ein Mensch der seine Erfüllung darin findet dass er kurze Videos (~10 Minuten lang) aufnimmt in denen er eine Sache - ein Konzept aus Mathematik, Physik, Chemie, Finanzen und vielen weiteren Themen.

Und die sind gut!

Ausserdem hat er eine Software online gestellt die ein sehr spannendes Konzept verfolgt: Wissen ist dort als Graph aufgestellt - von einfachster Addition bis zu relativ komplexen Themen. (Aber viel weniger als als Video verfügbar ist).

Der Clou: Man fängt bei einfacher Addition an und kriegt die nächst-Schwierigeren Aufgaben erst wenn man 10 Aufgaben aus einem Wissensgebiet erfolgreich direkt hintereinander gelöst hat.

Dazu gibt es jeweils den ganzen Lösungsweg plus einen Link auf das dazugehörige Video wenn man es noch mal im Detail braucht.

Das führt dazu dass Kinder gerade bei Mathe ihre Lücken auffüllen können die sie irgendwo im Verständnis haben. Und das finde ich Großartig - denn das ist eines der größten Probleme von Großgruppen-Lernen. Wenn ein Thema vorbei ist, dann ist es vorbei - egal ob man es verstanden hat oder nicht.

Verdammt schade dass es noch soo lange dauern wird bis solche Konzepte auch in der "Offiziellen" Lehre angekommen sind.

Klima-Veränderung ist ein schwer zugängliches Thema.

Aber auch Sau-Wichtig. Und daher finde ich es grandios was James Balog für eine Arbeit gemacht hat um den Gletscher-Rückzug zu dokumentieren. Mit knapp 30 Zeitraffer-Kammeras macht er über Jahre Hinweg jede Stunde ein Bild von vielen Gletschern und daraus dann einen Film.

Wow.

• Gibts bei TED als Video
• Oder auf der Homepage des Projekts
• Mein Lieblingsvideo dort bisher

:) Einer meiner Lieblingspodcasts hat es jetzt auf die 100. Ausgabe gebracht.

Und da muss ich doch mal gratulieren. Vor allem weil ich bei der Quiz-Show über Programmiersprachen und deren Verbreitung absolut herzhaft gelacht habe. :-)

Hörenswert! Immer wieder großartige Interviews mit Machern von Open Source Projekten.

[Hier gehts zur 100-sten Show http://twit.tv/floss100]

Das ist ein steinalter Vortrag von Alistair Cockburn (gesprochen Co-Burn) in dem er darlegt wieso er findet das das eine sehr gute Sichtweise auf Softwareprojekte ist.

Der Vortrag ist schon 10 Jahre alt - und trotzdem finde ich ihn sehr Aktuell.

Lesenswert!

a = b = list()
a = a + ['foo']
print b # => []

a = b = list()
a += ['foo']
print b # => ['foo']

Doh. Wie kann das sein? Kommt man von C ist das erst mal sehr verblüffend - und auch die meisten anderen Programmiersprachen die ich kenne verwenden a += b als equivalent für a = a + b.

Well, nicht so Python. Weil da gab es offenbar mal Programmierer die fanden dass man Code der mit Matrizen rechnet lieber mit Operatoren schreiben möchte weil sich das besser ließt. Natürlich nicht mit den normalen operatoren wie */+-, weil, da kann man ja den empfänger nicht in place modifizieren, und wie jeder weiß sind Matrizen ja so groß dass die dann nicht mehr in den Ram passen.

Also haben sie die = operatoren in Python so spezifiziert, dass sie ihre left-hand-variable in place modifizieren wenn diese mutable sind.

:-(

Das höchste Ziel in der Physik ist alle Kräfte durch eine Formel auszudrücken bzw. sie in Beziehung zueinander zu setzen. Maxwell zum Beispiel gelang das für elektrische und magnetische Felder - und dafür ist er noch heute berühmt.

In der Software-Entwicklung gibt es so etwas bisher nicht. Klar, es gibt Daumenregeln, so wie:

• Keep it DRY
• Keep your Methods Small **
• Work SOLID
• Obay the Law of Demeter
• und so weiter…

Aber, und das ist der wichtige Teil: diese Daumenregeln sind keine Unifikation die die verschiedenen Probleme beim Programmieren abwägen und in Beziehung setzen.

Daher finde ich Jim Weirichs Vortrag The Building Blocks of Modularity sehr spannend - denn da stellt er den Ansatz der Connascence vor (ab Folie 35).

Das ist letztlich eine Klassifizierung welche Art von Abhängigkeit man sich durch welche Programmiertechnik einfängt - und damit kann man 'normales' Refactoring anwenden um von problematischeren Connascence's (?) zu weniger problematischen zu kommen.

Ach ja, ursprünglich kommt das aus dem Buch What every Programmer should know about Object Oriented Design. Davon kann man aber Getrost nur noch den dritten Teil lesen (über Connascence) - der rest ist nach 15 Jahren einfach veraltet. :)

** Niemand sagt das so gut wie Kent Beck: "Lots of little pieces - Good code invariably has small methods and small objects. Only by factoring the system into many small pieces of state and function can you hope to satisfy the “once and only once” rule. I get lots of resistance to this idea, especially from experienced developers, but no one thing I do to systems provides as much help as breaking it into more pieces."

Klassenobjekte sind special - daher hat man im boddy einer klasse keinen Zugriff auf das klassenobjekt.

Weil, self ist ja auch nicht automatisch und man muss es in Methoden immer als explizites Argument hinschreiben, und so etwas gibt es ja bei Klassen nicht, denn das sind ja keine Methoden und daher kann man halt das Klassenobjekt nicht referenzieren im body.

Doh.

Und das nervt natürlich total bei der meta-programmierung.

Hier mal ein Beispiel von etwas SQL-Alchemy Code wo mir das wieder aufgefallen ist:

class Poll(Base):
    proposal = relation(proposal.Proposal, backref=backref('polls', cascade='all',
                           lazy=False, order_by=Poll.begin_time.desc()))

Das geht nicht, weil ich auf Poll nicht zugreifen kann und damit nicht auf andere attribute der Klasse. Der Workaround den SQLAlchemy dafür macht ist das man einen String hineinreicht und die den dann aufwendig parsen. Total gar nicht toll.

:-(

Eine Sache die mich bei Python immer wieder ärgert ist die Tatsache dass Standardwerte für Methodenargumente zur Parsezeit festgelegt werden anstatt zur Aufrufzeit.

Das ist total doof, denn dadurch teilen sich alle aufrufe der Funktion den gleichen default-wert - was zwar schön schnell sein mag, aber trotzdem in fast allen Fällen nur bei nicht veränderbaren Objekten (so wie Integer und Strings) Sinn ergibt.

So führt das dazu dass man in Python eine ganze Menge Workarounds braucht um mit default-argumenten zu arbeiten.

Das wichtigste dabei ist der default typ None. Das ist der workaround für alle mutable-objekte, da man die in fast keinem Fall zwischen verschiedenen Methodenaufrufen teilen möchte. So sieht das aus:

def end_poll(self, end_time=None):
    if end_time is None:
        end_time = datetime.utcnow()
    # work with end_time...

Der Punkt hier ist dass man datetime.utcnow() nicht in das standard Argument hineinschreiben kann, da man sonst bei jedem Aufruf der Methode den gleichen Wert hätte: Die Parsezeit. Nicht sonderlich nützlich.

Das hat zur Folge dass man:

• aus der Signatur nicht sehen was das Standardargument ist (utc/gmt oder vielleicht ewas ganz anderes?). Immerhin gibt es inzwischen immer mehr IDEs die diese Signatur beim aufrufen für autocompletion nutzen oder sie wenigstens anzeigen können.
• Man beim verwenden von Standardargumenten immer überlegen muss ob man dieses Argument jetzt in die Methodendefinition oder in den Body aufnehmen muss.
• für jedes Standardargument noch mal zwei extra Zeilen braucht. Das nervt vor allem deswegen weil man sich mit den standard Argumenten ja Zeilen sparen möchte. Das heißt die Kosten für Standard-Argumente steigen und man benutzt sie seltener.
• die default argumente noch mal separat dokumentieren muss, da ein dokumentations-extraktions-Werkzeug ja den Code nicht sieht, der das tatsächliche Standardargument setzt. Und natürlich hat man dann noch mal DRY verletzt da die Information jetzt zwei mal da steht.
• richtig fiese Bugs kriegt, weil viele Leute diese Probleme nicht kennen oder sie ab und an vergessen und mal ein list(), dict() oder set() als Standardwert nehmen was dan für viel Freude beim Debuggen sorgt.

Also, know your Python und vorsicht mit Standardargumenten!

Vielleicht kriegen wir ja irgendwann von unserem BDFL ein from __future__ import runtime_standard_argument_evaluation.