... ist vorbei.

Puah war das anstrengend.

Aber auch  Produktiv.

Vor allem war überraschenderweise die Location der Kommunikation total zuträglich - ich hatte zuerst befürchtet das  der Club mit seiner leicht verratzten und düsteren Atmosphäre das ganze eher unproduktiv gestalten könnte.

Es war aber genau das Gegenteil der Fall. Innen waren die Gespräche relativ strukturiert - obwohl sich 25 Leute gegenüber saßen. Und dadurch das es recht Eng und nicht soo schön und vor allem auch nicht soo gut belüftet war, wollten alle in schöner Regelmäßigkeit nach draußen auf die Straße zur Pause gehen.

Und diese Pausen waren gut! Die Gespräche wurden Befruchtet, neue andere Themen konnten zwanglos angeschnitten werden - oder man konnte auch einfach nur abschalten.

Alles in Allem: Gut. :-)

Schwieriges Thema. Die ganze Kommunikation findet ja schon fast ausschließlich online statt - da denkt man ja das Transparenz überhaupt kein Problem ist.

Tja... denkste.

Das Problem ist nämlich ein ganz anderes: Die Flut der Inhalte erschlägt jeden, der auch nur ansatzweise versucht das neben einem normalen Arbeitstag alles zu bewältigen.

Ugh.

Überraschung. Es braucht also doch noch mehr Energie um die Informationsflut übersichtlich zu machen.

Tja. Die müssen wir dann wohl erbringen. Aber Spaß machen tut es bisher noch nicht. :-(

 Das Protokoll gibts immerhin.

Nur wie kriegt man das Zusammengefasst?

Ich nehm jedenfalls mit, dass der sehr viele Piraten aus verschiedenen Ländern anwesend waren. Super.

Und wir haben immerhin schöne Wünsche / Empfehlungen formuliert. Auch super.

Das Wichtigste war aber das sich die Leite aus den verschiedenen Landesverbänden wirklich Person zu Person unterhalten haben - und nicht immer nur Elektronisch kommunizieren.

Yay!

So, jetzt kurz ganz intensiv hinschauen - so sagen wir mal für 10 Sekunden.

Und, schon gesehen was es ist?

Ok, nochmal 10 Sekunden.

Jetzt?

Na, will ich es mal auflösen. Das ist ein Programm das in der von mir schon beschriebenen Veranstaltung  Fortgeschrittene Techniken funktionaler Programmierung auf einer Folie erscheint.

Jep, als teil der Vorlesung für so sagen wir mal... 2 Minuten.

Aber jetzt zum Problem: Dieses Programm versteht man nicht! Schon gar nicht wenn man kein Opal kann - aber auch mit Opal-Kenntnissen hat man keine Chance.

Was für ein Schwachsinn diese ganzen Funktionssymbole sind.  Als würden Programmiersprachen heute noch mit einer eigenen Tastatur kommen. Vor allem aber haben sie ein Problem: Man muss den ganzen Kontext was sie Bedeuten komplett mitschleppen - was uns Menschen viel schwerer fällt als einfach ein Wort zu lesen das sagt worum es geht.

Jep.

Wer zweifelt, mag doch bitte das Programmfragment erklären.

q.e.d.

Schon lange hab ich mich gefragt, wieso eigentlich mich dieser eine Punkt an Python so sehr stört:

Jede Methode eines Objektes erhält als ersten Parameter eine Referenz auf das aufrufende Objekt.

Bisher konnte ich den Finger nie darauf legen konnte, wieso mir das eigentlich so auf den Keks geht. Bisher dachte ich immer das es mich stört, weil man schwieriger aus normalen Funktionen Methoden zu machen, beim Refactorn, aber so wirklich passt das nicht. Also dachte ich, vielleicht gewöhne ich mich ja irgendwann daran. Dem war aber nicht so.

Bei den Vorbereitungen zum Java-Kurs ist mir jetzt durch einen Hinweis von  Robert der eigentliche Grund Aufgefallen.

Folgendes war der Auslöser: Wir haben uns gerade darüber unterhalten wie wir den Studenten im Java-Kurs erklären, wie sie this in Java verstehen sollen.

Naja, von der technischen Seite ist das klar - die Methoden sind im Klassenobjekt implementiert und die Methode braucht aber einen Weg um an die Daten zum gegenwärtigen Instanz-Objekt zu gelangen. Also wird dieses Instanz-Objekt als verstecktes erstes Argument übergeben, das immer den namen this trägt.

Soweit so klar.

Das Mentale Bild das man von diesem Systems hat, ist aber eigentlich anders: Darin gehören die Methoden zum Instanz-Objekt und "leben" auch darin - damit ist dann auch klar, wieso eine Instanz-Methode zugriff auf die Daten des Objekts hat und wieso zum Beispiel eine Klassen-Methode das nicht kann - sie lebt einfach im falschen Objekt.

Der Knackpunkt: this ist eigentlich ein Workaround (aber ein notwendiger) der zeigt wie diese Abstraktion implementiert wurde, der aber auch erlaubt eindeutig zu spezifizieren welchen Namensraum man jetzt meint. Jetzt möchte man aber die Implementierung möglichst von der Benutzung abstrahieren, damit man gut auf dieser Abstrakteren Ebene arbeiten kann und diese nicht ständig verlässt. Daher macht es viel Sinn diese Implementierung so transparent zu machen wie nur irgend möglich.

In Python dagegen ist das anders. Hier wird ganz Explizit immer self als erster Parameter geschrieben. Der Effekt? Ständig wird man daran erinnert das die Abstraktion eigentlich nicht so ist wie man sich das denkt und es tatsächlich alles anders implementiert ist in Python. Das Problem? Man erhält durch diesen Abstraktionsbruch keinen Vorteil - ja, alles ist expliziter, aber es bricht auch ständig mit der Abstraktionsschicht auf der man Arbeitet. Details der Implementierung "bluten" über dieses "Loch" in den ganzen Code den man schreibt.

Und saubere, klar getrennte Abstraktions-Ebenen sind einfach wichtiger als einfachste Implementierung - speziell für einen Sprachdesigner.

(zu  Mother Earth von Within Temptation)

 Diese Folien habe ich gestern gefunden.

Das Thema finde ich schon spannend - immerhin wird doch einiges angesprochen, das ich mal wieder auffrischen könnte. Monaden, und effiziente implementierungen von Sequenzen und Maps würden mich vor allem interessieren.

Aber leider kranken die Folien unter einem ganz spezifischen Problem: Sie strotzen nur so vor Begeisterung über die tollen typographischen Möglichkeiten von  Tex.

:-(

Besonders bezeichnend finde ich  Vorlesung 3.2. Ich meine, es ist ja schön, das man mit Tech Programme auf solch mathematische Art und Weise schreiben kann.

Aber wer bitte soll das Lesen? Und wieso wohl hat sich APL nicht durchgesetzt?

Im GCC gibt es auch  eine Erweiterung die den tertiären Operator erweitert (test) ? ifTrueValue : ifFalseValue so dass man den mitleren Operanden weglassen kann um bei dieser Form zu landen aValue ?: ifValueEvaluatedToFalse . Das ist für sich gesehen nun jetzt erst einmal blöde - andersherum ergibt sich daraus die schöne Möglichkeit einen "Oder" Operator zu haben.

Das heißt: Muss man dieses Beispiel

void getImportantValue() {
    return somethingWhichGeneratesAStringOrNull();
}

erweitern, dass es nie null zurückgibt, sondern stattdessen immer mindestens einen leeren String, geht jetzt einfacher. Klassisch würde man das so machen müssen:

void getImportantValue() {
    char *value =  somethingWhichGeneratesAString();
    if (value) return value;
    else return "";
}

Oder eben kürzer mit der Erweiterung:

void getImportantValue() {
    return somethingWhichGeneratesAString() ?: "";
}

Ist diese Vereinfachung beim Schreiben die größere Komplexität beim Lesen wert? Immerhin wird fast kein C-Coder dieses Konstrukt kennen und daher zuerst einmal überrascht sein wird.

Vielleicht sollte man es dann also in ein Macro packen, das diese Funktion über den Namen dokumentiert, etwa

#define IF_NULL_USE ?:

Dann kann man aber eigentlich auch schon wieder ein Makro bauen das das explizit macht. So zum Beispiel:

#define IF_NULL_USE(testedValue, alternativeValue) (testedValue) ?: alternativeValue;

Oder man definiert sowas gleich als Funktion.

Und das ist genau das Problem dass diese Konstrukte, ob in Opal oder in C, immer haben. Es ist ja schön das man sowas machen kann - aber es dokumentiert sich selbst ganz beschissen. Und man schreibt den Code nun mal für andere Menschen - nicht für das Satzsystem. Also muss man doch eine Funktion oder ein Makro definieren, damit sich dieser Trick selbst dokumentiert - und dann kann man an der einen Stelle auch gleich ein if hinschreiben.

(Zu  Rachel's Song von Vangelis)

Meine Bekannte  Katrin hat sich eine  Zeitschaltuhr zugelegt. Nun ja, da denkt man, diese Dinger gibts ja schon lange, kann ja alles nicht so schwer sein.

:-D

Nach längerer Zeit hat Sie herausgefunden wie der Funktioniert - zu zweit haben wir ihn dann mal im Detail angeschaut.

Schonmal vorweg: Meinen Respekt. Was die alles Falsch gemacht haben, muss man wirklich absichtlich machen, sonst geht das einfach nicht.

Hier erstmal ein Bild

Vielleicht das gute Vorne weg: Es ist klar eine Durchgangssteckdose, wo man was einsteckt ist schon mal einfach.

Nein, mehr positives fällt mir dazu nicht ein. Sorry.

Kommen wir mal zu den Details. Es ist eine Zeitschaltuhr. Völlig unbedarft erwartet man also erst einmal eine Uhr, die schaltet. Und wenn man das Bild betrachtet, dann ist das ja auch schon mal vertraut. Da sind Zahlen und die sind im Kreis angeordnet.

Ach ja, schalten... Das war schon die erste Schwierigkeit - wie schaltet man das gute Stück? Man muss die Schalter (der schwarze Kranz um das "Ziffernblatt" hoch oder herunterdrücken um den Strom zu schalten.

Interessanterweise gibt es auf dem guten Stück aber keinerlei Hinweis welche Stellung ein entspricht! Soweit ich das beurteilen kann scheint aber "herausgezogen" ein zu bedeuten. Sehr intuitiv.

Ach ja, und dann gibt es noch einen roten Schalter auf der Seite. Den haben wir auch nicht verstanden. Jetzt bei der Recherche hier zum Schreiben bin ich auf der Seite von Conrad-Elektronik fündig geworden. Offenbar ist das ein Master-Schalter der die Zeitschaltuhr völlig übergeht. Ist der UNBESCHRIFTETE Schalter also in der falschen Position, funktioniert sowieso gar nix.

Aber falls er zufällig richtig ist ist es trotzdem noch kompliziert - denn welcher der etwa 120 Schalter in dem Aussenring ist für welche Zeit zuständig? Beim Versuch das herauszufinden stößt man schnell darauf das man den äusseren Ring mit den Zahlen - das "Ziffernblatt" sozusagen - drehen kann.

Praktisch. So kann man zum Feststehenden Uhrzeiger die passende Uhrzeit einstellen.

Ich stelle mir das so vor: Damit man nicht völlig verzweifelt, wird man vermutlich die Uhr so einstellen, dass 0/24 Uhr oben ist, und dann stellt man sich einen Wecker, damit man die Uhr zum richtigen Zeitpunkt einsteckt, damit die Uhrzeit die er dann anzeigt zur Tageszeit passt. Und vielleicht betreibt man es vorher dann noch ein paar Stunden damit der Zeiger auf eine passende Stelle zeigt und man nicht um Mitternacht zum Zeitschaltuhr einstecken aufstehen muss.

Sehr komfortabel.

Ach ja, ausserdem stellt man ungefähr zu diesem Zeitpunkt fest, das die Beschriftung auf dem Ziffernblatt in die falsche Richtung ist. Nicht wie bei einer Uhr, nein, nein - natürlich anders herum. Auch wenn einem der Pfeil auf der "Zeiger"-Scheibe eine normale Richtung vorgaukeln möchte. Ach ja, natürlich macht der schon Sinn - denn den "Ziffernblatt"-Ring kann man nämlich ohne große Kraft nur in diese Richtung drehen. Oder soll - damit das einstellen der Uhrzeit noch "leichter" fällt vielleicht?

Der "Zeiger" jedenfalls bewegt sich genau in die andere Richtung.

Fassen wir also mal Zusammen:

• Schalten? An schwarzen Stiften, so etwa 10 min pro Stift, was ein und was aus bedeutet muss man aber durch trial und Error bestimmen
• Es gibt einen unbeschrifteten Schalter, der den ganzen Mechanismus ausser Kraft setzt - Was ein und was aus bedeutet muss man ausprobieren.
• Man dreht nicht die Scheibe mit dem Pfeil darauf, sondern den Ring aussen herum auf dem die Zahlen stehen.
• Damit stellt man die Uhrzeit zu dem feststehenden "Uhrzeiger" ein. Man stellt also nicht den "Uhrzeiger" sondern das "Ziffernblatt"
• Das "Ziffernblatt" ist in die falsche Richtung beschriftet

Eine tolle Uhr ist dass. Ich meine, man hat wirklich das Gefühl das der Konstruktör entweder noch nie eine Uhr in der Hand gehabt hat und daher etwas völlig neues erfinden musste, oder aber das er sich absichtlich überlegt hat, wie er seine Benutzer noch ein bisschen mehr quälen kann.

Wirklich faszinierend.

Da hab ich doch tatsächlich meinen ersten Kommentar zu einem Blog-Eintrag erhalten. Per mail von  Felix!.

:)

Ja, ich muss noch an der Technik hier schrauben. Wird gemacht. Versprochen.

Hier zum Kommentar:

Richtig verstanden hat man erst wenn man es erklären kann. Das bedeutet aber auch, dass deine Erklärung nicht zu einem vollständigen Verständnis deiner Zuhörer_innen führen kann.

So hab ich diesen Satz noch gar nicht gesehen - aber das steckt da drinnen und ist absolut korrekt.

Allerdings...

Das bedeutet natürlich nicht, dass man sich weniger bemühen sollte auch schon bei der Erklärung eines Konzeptes so viel wie möglich erreichen zu wollen.

... muss man es trotzdem versuchen. Ein Kurs ist ja immer von ganz unterschiedlichen Menschen belegt, die jeder auf einem anderen Level sind.

Das Problem als Vortragender ist da natürlich das ich nicht individuell auf die einzelnen Zuhörer eingehen kann - um das Beispiel zu wählen das ihm am Meisten erklärt.

Das bedeutet aber natürlich auch, das damit jeder aus einem Vortrag etwas anderes mitnimmt. Ein perfekt strukturierter Vortrag gibt damit jedem der ihn hört genau das mit, was er benötigt um weiterzumachen und bietet bei erneutem hören weitere Inspiration.

Ok, das schafft man wohl nicht - aber das Ziel, das man das Material so präsentiert, das der Anfänger einen Einstieg hat, und der der etwas weiter ist, mehr mitnehmen kann - das hab ich schon.

... war alles was ich noch sagen konnte, nachdem mir mein Vater ein (!!) Korn des  Szechuanpfeffers gegeben hatte, die meine Verwandte Renate aus China mitgebracht hat.

Was die Wikipedia als "scharf-prickelnde Geschmack, der ein Gefühl der Taubheit auf Lippen und Zunge bewirkt" beschreibt ist in wirklichkeit ein intensives prickeln des ganzen Mundes, als stünde der ganze Rachen unter Strom!

Und das eine viertel-Stunde lang.

Dabei ist der Pfeffer eigentlich nicht scharf - man hat nur einen völlig betäubten Mund - der Geschmack ist wirklich nur als "volle Dröhnung" zu beschreiben.

Genau genommen, bin ich immer noch etwas high...

:) Cooles Zeug.

Nur wie man damit Würzen soll ist mir noch schleierhaft.

Es heißt ja, das man etwas erst wirklich verstanden hat, wenn man es einem anderen Menschen beigebracht hat.

Nun, mir stellt sich mal wieder die Frage, im Rahmen des  Javakurses der Freitagsrunde an der TU-Berlin:

Wie erklärt man Objektorientierung wirklich gut?

Verschiedene Kräfte zerren da an mir:

• Der Vortrag muss in eine Stunde passen
• Die Sprache anhand der es erklärt werden muss ist Java
• Die Studenten haben noch nie eine Programmiersprache gesehen
  • oder vorher eine Funktionale Sprache gelernt, die sie nicht verstanden haben

Was mir am meisten am Herzen liegt sagt Kent Beck in  Smalltalk best Practice Patterns einfach wunderschön:

Objects model the world through behavior and state. Behavior is the dynamic, active, computational part of the model. State is what is left after behavior is done, how the model is represented before, after, and during a computation.

Of the two, behavior is the more important to get right. The primacy of behavior is one of the odd truths of objects, odd because it flies in the face of so much accumulated experience. Back in the bad old days you wanted to get the representation right as quickly as possible, because every change to the representation bred changes in many different computations.

Objects (done right) change all that. No longer is your system a slave of its representation. Because objects can hide their representation behind a wall of messages, you are free to change representation and only affect one object.

Nur leider können die Studenten mit dem Vergleich in die alten Tage nix anfangen, denn sie haben ja gerade keine Erfahrung warum die alten Tage schlecht waren.

Immerhin der erste Satz ist brauchbar - und ich werde ihn tunlichst einbringen. Damit ist das Problem doch schon mal zumindest kleiner geworden.

Denkfutter bis zum nächsten mal...

Weiß ich nicht, aber ich weiß, was für Folgen es hat.

Wenn man ohne Tests entwickelt, dann hat man beim Schreiben von z.B. einer Klasse immer den vollen Zugriff auf das gesamte System - und es ist ständig verlockend, nur eben dieses andere Subsystem aufzurufen oder es in die klasse als Instanzvariable einzubinden. Da man kein Korrektiv hat, sind die Folgen dieser Handlungen fast unsichtbar. Die Abhängigkeiten im System nehmen immer weiter zu - und die Architetkur immer weiter ab. :/

Als Testgetriebener Entwickler muss man sich, um den Code in einer Testsuite überhaupt laufen lassen zu können maximal vom Rest des Systems abkapseln. Das bedeutet das man sich bei jeder Abhängigkeit die man dazu nimmt genau überlegt, ob man sie wirklich braucht, ob man sie erreichen kann, indem man einen Parameter übergibt, oder indem man ein Protokoll einführt das die Kommunikation dieser zweier Systembestandteile klärt. Immer macht man sich über die Grenzen der Komponente Gedanken und wie die Kommunikation darüber hinaus abläuft.

Man macht eben nicht einfach nur einen Konstruktorparameter über den dann als globale Variable alles zugänglich ist - den man im Test aber niemals instanziiert bekommt.

Diese Tatsache macht für mich einen der größten Unterschiede zwischen Testgetrieben entwickeltem Code und sonstigem Code aus.

Es ist unglaublich schwierig (auf anhieb) Code zu schreiben der Wiederbenutzbar ist und wenig Abhängigkeiten besitzt - wenn man Code testgetrieben entwickelt bekommt man aber unheimlich viel davon umsonst.

Alleine deswegen darf es heute eigentlich keine Ausrede mehr Geben ohne Tests zu entwickeln.

 Fodert Dieter Gorny, Cheff des Bundesverbands der Musikindustrie. Klar.

Spannend finde ich aber das er vorgibt, aus der letztlich erschienen Brennerstudie wäre ersichtlich das sich illegale Downloads um die Hälfte reduziert haben.

Nämlich von 600 Millionen auf 300 Millionen.

Da würde ich doch schon mal gerne die Studie sehen, Herr Bundesverband. Und was da genau gefragt wurde. "Wie viele illegale Downloads haben sie im letzten Jahr gemacht?" oder "Sind sie sich im klaren darüber das das herunterladen von Musik aus dem Internet illegal ist?" und direkt danach "Wie viele Musikstücke haben sie im letzten Jahr heruntergeladen?"

Vielleicht taugt die Studie ja auch und die Leute sind dazu übergegangen Fernsehserien etc. herunter zu laden. Jedenfalls weiß ich nichts darüber das sich die verbrauchte Bandbreite oder der Anteil der P2P-Dienste an der Gesamtbandbreite irgendwie verringert hätte.

Wirklich schade, das man in der Politik nicht seine Quellen offen legen muss, wie in der Forschung. :-/

Transparenz ist doch was feines.

... sind eine schöne Sache. Wenn man sie denn hinkriegt.

Da wäre zuerst der einfache Fall: Was macht man um eine Wiki-Seite zu erzeugen und zu laden?

Well, hier ist wie es geht:

#!/usr/bin/env python

import unittest

from trac.wiki.model import WikiPage
from trac.test import EnvironmentStub

class PluginTests(unittest.TestCase):

    def test_can_save_and_load_wiki_page(self):
        env = EnvironmentStub()
        page = WikiPage(env, "Foo", None)
        page.text = "barfoo"
        page.save("fnord", "bar", "localhost")
        
        self.assertEquals("barfoo", WikiPage(env, "Foo", None).text)

Soweit nicht soo schwer. Vor allem sehr schick, das das EnvironmentStub() einem die ganze Arbeit abnimmt um das Trac-Environment UnitTest fähig zu machen. Ein Call und alles ist da - inklusive einer in-memory Sqlite Datenbank.

Nice.

Der eigentliche Hammer ist dann aber, wenn man ein Plugin bauen will das von anderen Plugins abhängt. Das ist nämlich deutlich komplizierter.

Da ergibt sich nämlich das Problem, das man plötzlich das Component-System von Trac verstehen muss, damit man überhaupt auf die Klassen und ExtensionPoints eines anderen Plugins aufbauen kann.

Für uns um Beispiel das TracTags-Plugin. Dieser Blog basiert auf diesen Tags. Blog-Posts werden durch einen speziellen Tag ("blog") zu einem Blog-Post, Kategorien sind nur Tags und überhaupt funktioniert alles nur über Tags. Tags sind cool.

Aber, man muss das Plugin erst einmal schwer zur Zusammenarbeit überreden - denn, es benötigt ein Datenbankupgrade damit es überhaupt funktioniert.

Und überhaupt ist die Datenbank am Anfang total leer. :/

Um es gleich zu verraten: Die Lösung lag darin, das man dem Environment einerseits sagen muss, das man gerne Standard-Daten hätte und andererseits, welche Plugins es alles aktivieren soll. Nicht schwer. Nur nicht offensichtlich. :(

#!/usr/bin/env python

import unittest

from trac.wiki.model import WikiPage
from trac.test import Mock, EnvironmentStub, MockPerm

from tractags.api import TagSystem

from tractags.model import TagModelProvider

class PostFinderTest(unittest.TestCase):
    
    def setUp(self):
        self.env = EnvironmentStub(default_data=True, enable=["tractags.*", 'trac.*'])
        self.env.upgrade()        
        self.env.db.commit()

    
    def test_can_save_and_load_wiki_page(self):
        page = WikiPage(self.env, "Foo", None)
        page.text = "barfoo"
        page.save("fnord", "bar", "localhost")
        
        self.assertEquals("barfoo", WikiPage(self.env, "Foo", None).text)

                        
    def test_can_add_tags_and_retrieve_tagged_pages(self):
        from trac.web.href import Href
        page = WikiPage(self.env, "Foo", None)
        page.text = "barfoo"
        tag_system = TagSystem(self.env)
        req = Mock(perm=MockPerm(), args={}, href=Href('/'))
        tag_system.add_tags(req, page.resource, ["blog"])
        page.save("fnord", "bar", "localhost")
        
        self.assertEquals("barfoo", WikiPage(self.env, "Foo", None).text)
        
        blog_resources = [i for i in tag_system.query(req, "blog")]
        self.assertEquals(1, len(blog_resources))

Mei war das eine Arbeit die ganzen Objekte zusammen zu suchen die man für test_can_add_tags_and_retrieve_tagged_pages() benötigt.

Well, ein start ist gemacht, aus dem wir jetzt einen Page-Loader refactor-n (-ieren?) werden.

Yay!

Dafür bin ich nämlich viel zu betrunken.

Schließlich hat die Friedrich Ebert Stiftung heute den Wein bezahlt, den ich abgegriffen habe, während ich meine Freundin von einer Veranstaltung dort abgeholt habe.

Das Essen war auch nicht soo toll.

Naja, immerhin der Rotwein.

Ach ja, die Veranstaltung hieß: "Außen vor oder mittendrin? Gesellschaftliche Partizipation und Anerkennung erwerbsloser Menschen". An sich spannend, aber die Teilnehmer haben eigentlich alle nur immer die gleichen bekannten Stereotypen von sich gegeben. Wirklich gut fand ich (neben meinem Vater :) dann vor allem  Frauke Hehl die mal wirklich gesagt hat was sache ist: Das alle Arbeit haben ist einfach inzwischen eine Illusion der wir uns nicht mehr hingeben dürfen.

Recht hat sie.

So, und jetzt gute Nacht.

Das Spannendste an der Piratenpartei sind die, die dabei mitmachen.

Zum Beispiel RKA. Mir ist ein Rätsel, wie er die ganzen Dinge, die er tut, in seine Zeit einsortiert.

• Bei der Piratenpartei ist er aktiv - bald sogar im Vorstand.
• Beim AK-Vorrat ist er aktiv - er hat dort z.B. die Abgabe des Schriftstücks (120 Ordner) für die Klage gegen die Vorratsdatenspeicherung mit vorbereitet
• Privat gründet er noch diverse Firmen mit
• Studiert nebenbei noch Wirtschaftsrecht
• Weiß von allen Dingen, wo man sie bekommen kann
• Hat einen grandiosen Überblick, wo im Internet welche Startups gerade was machen

Einfach beeindruckend.

dass Betreiber von Geschäften so überwachungsgeil macht?

Zum Beispiel  dieser Eigentümer einer Diskothek. Der erstellt über jeden seiner Besucher ein komplettes Persönlichkeitsprofil, inclusive wann sie bei welcher Bedienung wie viel von welchen Getränken gekauft haben. Und natürlich von wann bis wann sie anwesend waren, woher sie kommen, welche Telefonnummer sie haben, etc.

Das Geilste: die Überwachten Club-Gänger werden dargestellt, als fänden sie das ganz toll. Schließlich müssen sie als Mitglied keinen Eintritt bezahlen und erhalten Zutritt zum Buffet.

Diese Daten werden ewig aufgezeichnet - die Bilder der Überwachungskamera 'nur' mindestens ein halbes Jahr auf dem Privatrechner des Eigentümers.

"Die wollen das doch genau so!" hört man den Betreiber quasi schreien.

Und was wenn er Windows benutzt und jemand bei ihm in das Rechnernetzwerk einbricht und die Daten alle stiehlt?

p.s.: Haben wir da jetzt nicht  ein Grundrecht auf Datenintegrität?

"You can only connect the dots looking backwards, never looking forward." -- Steve Jobs

Sagt er  hier.

Geiler Vortrag.

Über meinem Schreibtisch hängt schon seit zwei Jahren ein Zettel. Darauf habe ich damals geschrieben:

Eine Revolution: Computer Zwei Ideen: Grundeinkommen, Zinskatastrophe

Das würde ich heute anders formulieren: Zwei Revolutionen, eine Idee

1. Die Computerrevolution
2. Die Arbeitsrevolution

Die zweite ist sichtbarer und erzeugt (scheinbar) mehr Probleme, da sie immer mehr Menschen arbeitslos macht. Dabei ist sie mit er der ersten Verknüpft. Immer mehr Tätigkeiten können durch Computer- und Maschineneinsatz dem Menschen abgenommen werden und uns allen steht damit mehr Freizeit zur Verfügung (ok, abgesehen von den Informatikern, die das alles am Laufen halten müssen). Das bedeutet letztlich, das mit fortschreitender Technik immer weniger Arbeit notwendig und immer mehr Arbeit freiwillig wird. Und das muss sich in unserer Gesellschaftsordnung früher oder später wieder spiegeln. Durchdenkt man das, wird natürlich auch schnell klar, das Geld als Druckmittel um Arbeit zu erzwingen damit ein reichlich merkwürdiges Konzept ist, denn tatsächlich ist die Arbeit ja unsinnig oder zumindest unnötig. Lösungsansätze:  Bedingungsloses Grundeinkommen (Wikipedia),  Netzwerk Grundeinkommen,  Deutsche Abteilung?

Die erste Revolution ist viel unsichtbarer - Computer durchdringen immer mehr Gebiete unseres Altags und algorithmisieren sie. Das bedeutet, das implizite Regelungen damit Explizit werden und wir uns plötzlich Gedanken über diese Details machen müssen.

Zum Beispiel: Heute sind Verkehrsregeln eine Konvention an die man sich hält. Sollten Autos irgendwann mit Autopiloten fahren, kann man nicht mehr einen Schwerverletzten auch über Rote Ampeln ins Krankenhaus fahren - ein Automat würde die Verkehrsregeln stur einhalten. Oder Verfahrensregeln in Verwaltungen. Wo heute etwas Charme vielleicht genügt unsinnige Regeln aufzuweichen, kann man sich einem Computer gegenüber noch so anstrengen. Man muss den Regeln doch genügen.

Das sind aber alles noch harmlose Beispiele. Wo früher die Komplettüberwachung alle Kommunikation völlig ausgeschlossen war, ist es heute Routine das  alle Verkehrsdaten aufgezeichnet werden.

Daher ist es notwendig, das diejenigen die diese Probleme verstehen (Informatiker?) dieses Wissen und ihre Erfahrung in den politischen Prozess einbringen.

Das darf auf keinen Fall in den Strukturen einer bestehenden Partei versickern und ist auch überhaupt nicht geeignet in die Farbenlehre der bestehenden Parteien eingeordnet zu werden - denn die Probleme haben (erstmal) überhaupt nichts mit den bisherigen politischen Richtungen zu tun.

Ich bin daher der Meinung das die Gründung der  Piratenpartei der richtige Schritt war.

Davon abstrahiert ist es aber Wichtig, das jeder der diese Probleme versteht mit seinen Mitteln an ihrer Lösung beteiligt - ich habe dafür mein Engagement im  Berliner Landesverbands gewählt und kann es natürlich nur jedem ans Herz legen. :)

<Schleichwerbung>Wir treffen uns jeden Mittwoch 18:00 Uhr in der C-Base. (Rungestraße 20, 2. HH - 10179 Berlin)</Schleichwerbung>

Zur Zinskatastrophe sage ich später mehr.

Ob Ikea wohl bald pleite geht?

So jedenfalls  malt Freitag die Zukunft in der jeder Zuhause einen 3D-Drucker stehen hat, der fast beliebige Altagsgegenstände (inklusive Elektronik) herstellen kann.

Klingt gut nicht?

Naja, bis man sich klar wird, das die angestrebte Selbstreproduktion dieser Geräte natürlich bedeutet das sie ihre Einzelteile selbst herstellen können. Zusammenschrauben muss sie immer noch der Mensch der ehrfürchtig vor dem Gerät sitzt.

Spannend finde ich das aber schon. Im Dunstkreis des CCC ist schon länger davon zu hören, das die (wieder) immer mehr zunehmenden Hardware-Hacker jetzt auch Rapid-Prototyping Maschinen selber bauen können. Und das für so etwa 200-3000 € - je nach Anspruch und Bastelkenntnis.

An den Durchbruch der Produktionsmittel Zuhause glaub ich zwar noch nicht - aber wenn man doch mal mit Aliens kommunizieren will, dann ist heute immer noch die Idee, Selbstreproduzierende Satelliten loszuschicken die beste. Die könnten dann nämlich mit möglichst viel lokalem Speicher die Kunde über unsere Kultur quasi in einem gigantischen "Turnschuhnetz" in fremde Sternensysteme bringen - und umgekehrt.

Da wäre eine erste sich selbst reproduzierende Maschine natürlich schon ein ganz guter Start...

Spannende Wikipedia-Artikel über die ich beim Schreiben gestolpert bin:  Alternative Biochemien (engl),  Exopolitik (engl),  Pansperma (engl)

 Gab es bei Heise zum Thema Filesharing.

Vertreten sind die Gegner und Befürworter von Filesharing.

Inklusive Jan Huwald - das freut mich natürlich als Pirat.

:)

 Torrentfreak schrieb heute über  eine Studie der  Wiggin LLP  Wiggin LLP.

In der graphisch anspruchsvollen Studie stellt die Firma fest (unklar ist mir noch, wer sie Bezahlt hat) das das eingeschränkte Angebot einer der wichtigsten Gründe ist wieso Leute zu Piraten werden.

Ahem.

Na gut, ich finde es ja richtig wenn sich die Entertainement Industrie endlich auf ihren Hosenboden setzt und alle Inhalte (ja, auch die Alten) im Netz verkauft.

ABER

Ich vermisse hier ein ganz wesentliches Argument: Filesharing machen zuallererst die Leute die Zeit haben, aber wenig Geld. Diese Leute (Jugendliche & Studenten z.B.) waren und sind aber ein ganz wesentlicher Markt für die Entertainment Branche.

Davon abgesehen bin ich als Pirat natürlich noch der festen Überzeugung, das unser Land mehr freie Kultur braucht und auch bekommen wird.

Dazu aber später mehr.

(zu  Return to Innocence von Enigma)

Es ist wirklich erstaunlich wie viel schwieriger es ist saubere Programme zu schreiben wenn mehr Leute an der Konstruktion beteiligt sind.

Nehmen wir zum Beispiel drei Leute. Einer hat vorher viel C++ progirammiert. Ganz selbstverständlich ist für ihn das Paradigma geworden, das man Accessoren -getVar und Mutatoren -setVar:aValue nennt.

Und schon mischt sich im System der Namens-Salat. Und das ist noch keine große Sache. Von sich aus besteht keinerlei Einheitlichkeit, wie wer seine Variablen und Funktionen nennt. Wie z.B. heißt eine Klassenmethode zum erstellen eines Objekts? -classname:instanceVarName with:anotherInstanceVarname oder -intentionWithNamedThing:aTypeDescription withAnotherNamedThing:aTypeDescription

Wie geht man mit Prefixen um? Was will man mit Instanzvariablen tun? Wann verwendet man (sinnvollerweise Accessoren und wann direkten Zugriff auf Variablen?

Die Summe dieser kleinen Entscheidungen macht so viel von der ( olfaktorischen?) Sauberheit eines Programms aus, das man sich (eigentlich) nicht leisten kann sie dem Zufall zu überlassen.

Aber der Overhead das alles vorher festzulegen oder auch nur zu kommunizieren ist gewaltig. Vor allem wenn man weder Refaktoring-Werkzeuge hat die einem die Änderungen erleichtern, noch Unit-Tests die einem die Änderungen absichern, noch Reviews / Pair-Programming die einen zu der Entscheidung helfen was geändert werden soll.

Was tun?

Erleichterung finde ich in der Tatsache, das tatsächlich viele kleinen Entscheidungen kaum oder keine Rolle spielen. Wo die Klammern gesetzt werden, oder wie weit eingerückt wird ist egal. Man überließt diese Unterschiede einfach.

Dazu kommt die Aussage aus dem  Big Ball of Mud Paper: Ein Dreckball mag besser sein als gar keine Software.

Ist Sauberkeit also doch überschätzt?

Nachdem ich ja schon vor ein paar Tagen? über das  FullBlogPlugin gesprochen habe, hab ich es jetzt endlich mal ausprobiert.

Schick. Deutlich schicker als das was ich jetzt hab.

Ok, der Editor ist irgendwie überladener als was ich jetzt im  TracBlogPlugin, und man hat immer Seitennahmen anstatt einem Datum plus einem Seitennahmen...

Mal schauen was mir noch so alles auffällt.

Muss ich nur noch herausfinden wie ich meine Posts migrieren kann. :)

Da gibt es eine grandiose englische Comedy-Serie  The IT Crowd bei der man sich nur totlachen kann.

Nun, da dachte sich SAT 1 wohl, hey, das können wir doch alles wörtlich ins Deutsche übersetzten und dem deutschen Fernsehpublikum verkaufen.

Nun, überraschenderweise hat sich gezeigt, das der Wortwitz der die Serie ganz wesentlich trägt bei dieser Übersetzung fast vollständig verloren geht.

DOH.

 Hier kann man sich selber überzeugen.

p.s.: Die Tiefe der Misere kann man ja schon am Titel erkennen. Der Wurde nämlich von "Die Jungs mit der Maus" in "Die Jungs an der Maus" geändert um auch noch die letzte Mehrdeutigkeit zu entfernen...

Armes deutsches Fernsehen.

Aus dem Buildscript  imageFromFolder.sh des MOKit Releases.

Da ich so etwas schon oft gelesen habe, habe ich mich endlich mal dafür interessiert wieso zum Teufel so viele Programmierer das so machen. Könnte ja sein, hab ich mir gedacht, das es einfach so kranke sh implementierungen gibt, dass man das so machen muss damit das wirklich auf allen Systemen läuft.

Nun, ein guter Hacker im CCC den ich darauf mal ansprach antwortete darauf mit dem Klassiker: "Die machen das doch nur alle weil sie das Manual nie gelesen haben!" :-) Gut,  les ich mal nach...

Ok, also das Beispiel mal etwas detaillierter betrachtet:

hdiutil create # and then a lot of parameters

if [ "z$?" != "z0" ] ; then
    echo "Error creating image ($?)."
    exit 1
fi

Das hätte man doch in jedem fall auch so machen können:

hdiutil create # and then a lot of parameters

if [ 0 -ne $? ] ; then
    echo "Error creating image ($?)."
    exit 1
fi

Und das fängt den Sinn des Tests auch gleich viel besser ein.

Dann hätte man natürlich auch noch eine der Kurzformen wählen können, sowas wie

hdiutil create mumble mumble \
    || echo "Error creating image ($?)." ; exit 1

Das ich persönlich fast noch etwas klarer finde - erst recht wenn man es in eine Funktion error_exit oder etwas ähnlichem verpackt

error_exit ( )
{
    local exit_value=$?
    echo $1 "($exit_value)"
    exit $exit_value
}

hdiutil create mumble mumble \
    || error_exit "Error creating image." 

Überraschenderweise ist das nämlich gar kein Problem so etwas in der Shell zu machen. Macht sich nur offenbar kaum jemand die Mühe das "fine" manual mal zu lesen.

Oder zumindest so scheint es mir im Moment.