Menschen mit Passion haben nicht nur eine Aufgabe, sondern stehen auch für diese ein, lehnen sich manchmal weit aus dem Fenster. Aus Überzeugung. Meinungsstark, mit klaren Positionen – gerne auch kontrovers. Das unterscheidet sie von den PR-Fatzkes aka Arschkriechern mit weichgespülten Lull-Statements und den Marketing-Mäuschen mit den totlangweiligen Facebook-Status über irgendwelche bescheuerten Messeauftritte.

Passion, das ist nicht der naive Enthusiasmus, den ein Volontär heute mitbringt, weil er besonders viele Twitter-Tools kennt oder einen Facebook-Account hat und auch gerne nutzt. Der aus Mashable-Artikeln zitieren kann und gerne von Transparenz, Authentizität, Echtzeit und anderem Hipster-Scheiß erzählt. Der immer vorne mit dabei ist, wenn wieder mal BETA-Invites für irgendwelche coolen Web-Services verteilt werden. Genau diese Tool-Fixiertheit führt Kommunikatoren in die Frustration, macht müde.

Social Tools are for Fools.

Texte ins Netz stellen kann jeder. Bloggen nicht.

Es ist kein Zufall, dass die ganzen Positivbeispiele da oben (fast) alle Blogs zum Gegenstand haben. Denn anders als auf Facebook (Werbefläche) und Twitter (Networking/Curating) ist es in Blogs möglich, sein Produkt, seine Marke voll und ganz auszuleben. Nicht selten ist ein Blog selbst das Produkt. Ohne Limitation in Form von Zeichenbegrenzug, Usability-Bugs und unerwünschter Werbung für irgendwelche Möbelhaus-Gewinnspiele. Dafür mit redaktionellen Inhalten.

Das Blog ist die ureigene Spielwiese, dort hat nur einer das Sagen und es ist nicht Mark Zuckerberg. Gute Blogs vermitteln Persönlichkeit. Das Blog ist die Arena, in der Passion voll und ganz zur Geltung kommt. In Gestalt richtig geiler Postings, die gerne von der Zielgruppe verlinkt werden.

Es braucht leidenschaftliche Menschen, um Social Media Projekte zum Erfolg zu führen. Weil nur Leidenschaft den ständigen Willen, sich zu verbessern, mehr Wissen zu erlangen, mehr Menschen für sich zu gewinnen, mit sich bringt. Unbändige Neugierde inklusive.

Danke, liebe (Quelle).

Neulich wurde ich angehauen:

Es sei „unschön“, wenn man statt

echo new publicAbstractFactoryImplementationSuperGeilesFormEndTag(void string args[]);

einfach das schreibt, was man möchte:

</form>

Liebe Softwarepäpste und Enterprisearschitekten. Hier kommt meine Philosophie:

• Ich bin faul.
• Die Maschine soll für mich arbeiten.
• Und sie soll das möglichst schnell tun, ohne viel Ressourcen zu beanspruchen.
• Andere Menschen mit weniger Erfahrung sollen das, was ich entwickelt habe, Verstehen und weiterentwickeln können.

Aber nein, so geht das doch nicht. Was wir brauchen, sind möglichst komplizierte Strukturen und Muster, die überhaupt niemand mehr ausser der Autor selbst checkt, damits softwarearchitektonisch schön ist und die Wartbarkeit erhöht wird.

Und wenn man dann genug Singletons mit der Abstract Factory instanziiert hat, welche die Facade durch den Proxy decoraten, damit der Mediator den Observer nicht beim visiten des Mementos dependency-injected, dann kann das Data Access Object mit dem Plugin via Null Object Flyweight durch das Composite iterieren und das emitten, was man eigentlich ursprünglich wollte:

Hello World.

Grässlich. Und dann wird mit einer „höheren Schulbildung“ geprahlt; einer Bildung, wo einem das Hirni dermassen durchgemantscht und verdreht wird, dass man am Schluss überhaupt nicht mehr weiss, wie man einen simplen Text ausgibt, weil man ja erst eine abstrakte Factory braucht, die man dann in einer Implementation per Dependency-Injection instanziieren kann, damit man sie dann durch alle DAO und SOA-Layer rauf und runter über tausend Schnittstellen via XML schicken kann, damit am Ende… Ääh, was wollten wir eigentlich?

Dass so eine Erdölraffinerie* ordentlich Speicher frisst, liegt auf der Hand. Und warten können’s nur solche, die auch so eine Hochbildung haben. Die OOP-Sekte.

Kein Wunder fühlen sich Enterprise-Senior-Supermega-OOP-Engineering-Technical-Softwarearchitekts gleich angepisst, wenn man ihr lange und mühsam erlerntes Hoheitsgebiet mit schnellen, schlanken, praktischen und gut funktionierenden Quickwins erschiesst. Die wollen ihren „Marktwert“ erhalten.

Nein. So will ich nicht enden. Entwurfsmuster als Inspiration ja, aber schlichte Ansätze als „unschön“ bezeichnen, nur weil’s halt grad nicht in ein Enterprise-Pattern passt: FFFUUUU.

* Erdölraffinerie (engl. Gas factory)
Unnötig komplexe Systementwürfe für relativ simple Probleme werden abwertend als Erdölraffinerien bezeichnet.

(Wikipedia: Anti-Patterns)

Ausprobieren!

Ich habe gerade die Vorteile, die Git & Github bieten, hautnah erfahren!

Hoh, da ist etwas tolles auf Github: node-search-engine. Ein auf node.js basierter Webcrawler, der das Internet durchsucht (asynchron und parallel, yay) und in einer CouchDB speichert.

*geifer* – gleich ausprobieren!

Ich mache also einen „Fork“.

Was passiert da: Das Repository node-search-engine, welches dem Benutzer kurokikaze gehört, wird unter meinen Account als eigenständiges Repository kopiert.

Jetzt gehörst du mir. Und ich kann dich klonen und drücken wie es mir beliebt.

Uuh, da läuft noch was nicht. Eine binäre Library funktioniert unter Mac OS X nicht, ein Syntaxfehler, und ein Funktionsname hat sich geändert.

So. Ich glaube jetzt läufts! Gleich committen und auf Github übertragen.

Hmm. Ich habe wohl gerade ein paar Bugs gefixt. Das Projekt liegt seit April 2010 brach – vielleicht freut sich der Entwickler ja über meine Verbesserungen.

Ich schicke ihm eine Pull-Anfrage:

Das heisst soviel wie: „Hey schau mal, ich habe da eine Verbesserung für dein Projekt – wenn es dir gefällt, kannst du diese Änderungen übernehmen!“

2 Minuten später:

Noch ein bisschen später:

Er ist dankbar und hat meine Verbesserungen gleich übernommen! YAY

Ist ja ein tolles Konzept! Jeder hat sein Repository. Jeder kann es kopieren. Es braucht keine Berechtigungen, kein „Hauptentwicklungszweig“. Was toll ist, wird geforkt, und wenn die Änderung passt, wird sie übernommen. Wenn nicht, existiert einfach ein Fork, eine Variante der Software eigenständig weiter.

Schläft die Entwicklung ein, finden sich sicher Entwickler um einen populären Fork, die ihn weiterentwickeln. Die Macht ist quasi nicht mehr bei den Entwicklern oder bei einer Firma, sondern bei der Software selbst. Die Firma mag Konkurs gehen, die Software lebt weiter. Der beste Fork gewinnt.

Erst durch Github wird das Opensource-Prinzip wirklich gelebt.

http://github.com/

Upgrades für Dezibert: Ein Graph.

Echtzeitstatistiken mit einem Canvas-Element, welches sekündlich mit Daten gefüttert wird. Und wenn‘s dann zu laut wird, und der Finger sich hebt – dann hebt auch der Graf dank einer CSS3-Transition seinen Finger:

Ich hatte ja vor kurzem smoothiecharts.org entdeckt, und da hat‘s mich einfach gejuckt, sowas für den Geräuschpegel unserer Arduino-Installation zu machen.

Nur war das nicht so einfach. Die Ethernet-Schnittstelle von Arduino ist alles andere als stabil. Maximal 4 Sockets, Verbindungen, die nicht sauber getrennt werden, Bugs im Firmwarecode… Es wurde einige male spät am Abend, und ich habe etliche Möglichkeiten durchprobiert. Die Schnittstelle stürzte nach ca. 1h immer wieder ab.

Die Lösung des Problems ist dieser Dreizeiler:

Heisst soviel wie: „Solange du verbunden bist, trenne die Verbindung!“.
3 Zeilen Code, und der Sauhund läuft stabil. Endlich.

Netter Nebeneffekt: Ich kann aus den gesammelten Daten auch schöne RRD-Diagrämmli erstellen:


Das war der Geräuschpegel von gestern. Um 6:30 kam die Putzfrau mit dem lauten Staubsauger. „Ob das ein Alkoholtest sei, wenn ich beim Dezibert ins Mikrofon blase…“ – Nein, das Teil misst nur die Lautstärke. Unruhe am Morgen, Mittag… Und grosse Diskussionen um 17:30.

Interessant, was so scheinbar harmlose Daten wie „Lautstärke über die Zeit“ plötzlich aussagen können…

Links:
Der Graph von Dezibert
RRD-Diagramm der letzten 12h (stündlich aktualisiert)

…für Datenreisende.

Was: Jediritter Infopad. Reiseführer durch die Galaxis. Personal Messenger Pad.
Wie: Zugriff auf das globale Datennetz
Wann: Immer dabei bei wichtigen Missionen

Kennt ihr die? Diese Geräte, die Helden begleiten. In allen Filmen mit viel Raumschiff und Reisen durch’s Universum. Sie werden eingesetzt als Kommunikationsmittel, Notizblock, allwissendes Mobilterminal, Sonderbare-Steine-Analysegerät und scheinen niemals Strom zu verbrauchen.

Und wisst ihr was? So. Was. Gibts. Wirklich. !

Es heisst „Kindle„, kommt von Amazon, und war ursprünglich dazu gedacht, Bücher zu lesen.

Der Clou ist aber: Mit dabei ist, als „Experimental Feature“, ein vollwertiger Webkit-Browser mit Javascript Unterstützung.

Da ein Webbrowser alleine aber noch nicht sonderlich nützlich ist, gibt es gratis Internet dazu.
Und zwar weltweit. Ohne Abogebühr.

Jaaa, da staunst Du, he? Wusste ich nämlich auch nicht. Wissen die wenigsten… Weil das weltweite gratis Internet über 3G ist ein „nettes Nebenprodukt“…

Und wie lange der Akku wohl hält? Ein paar Stunden? Tage? Wochen? Ja genau. Ein paar Wochen. Da staunst Du grad nochmals, gell?

Warum das so ist: Das Display hat weder eine störende Hintergrundbeleuchtung, noch Pixel. Das Zauberwort heisst „E Ink“ – elektronische Tinte. Braucht nur Strom beim „Umblättern“.

Suchbild; finde den Pixel:

im Gegensatz zu euren tollen iPhones, die nach zwei Minuten schon „Akku! Akku! Akku!“ schreien, kann man dieses schicke Gerät zu recht als Mobile bezeichnen. Damit kann ich locker 2 Wochen irgendwo in die Türkei in die Flugferien und damit auf Wettersites zugreifen.

Hach – dieses Gerät versprüht mit seinem Monochrom-Display so einen Analog-Charme. Ich mag so unscheinbar altertümlich daherkommende Sachen, die aber hochwertigen futuristischen Schnickschnack eingebaut haben.

„Yes, it’s a Macintosh“ war der erste Gedanke, der mir durch den Kopf schoss.

(hier gefunden)

What I call “the miserable programmer paradox” states the following:

“A good programmer will spend most of his time doing work that he hates, using tools and technologies that he also hates.”

This is a paradox in the sense that it’s a counterintuitive result; you’d expect that the bad programmers would spend their time with crappy technologies, while the excellent programmers would spend their time with super-awesome technologies. Right?

[mehr…]

Nightly hacking. Und zwar:

Es gibt soo viele Seiten, wo man sich nicht über eine verschlüsselte Verbindung anmeldet.
Tja, was tun, damit das Passwort nicht unverschlüsselt übertragen wird und in die Nase eines Netzwerkschnüfflers gerät?

Wir brauchen ein Taschentuch. Und wickeln das Passwort dort drin ein.

Der Server generiert ein Taschentuch. In diesem Fall eine Zufallszahl:

$_SESSION['challenge'] = sha1(mt_rand(0, 1000000) . mktime());

Das schicken wir an den Browser. Sieht dann so aus:

Das Chrüsimüsi bei „Server challenge“ ist unser Taschentuch. Das Verfahren heisst nämlich „Challenge-Response„.

Jetzt tippe ich mein Passwort ein. Vor dem Absenden wird mein Passwort zusammen mit dem Taschentuch verchrügelet und erst dann an den Server geschickt:

var sha1 = hex_sha1(passval + challenge);

Das da unten; ja genau da wo es heisst: „[password] =>“ – dort ist mein Passwort im Taschentuch drin. Dieses Gstellaasch wird an den Server geschickt.

Dort angekommen, macht der Server das gleiche. Er wickelt das Passwort aus der Datenbank in das gleiche Taschentuch ein und vergleicht sein Ergebnis mit dem vom Browser erhaltenen:

if (sha1($db_password . $_SESSION['challenge']) == $_POST['password']) 
{
	echo 'Logged in. <a href="">Reload</a>';
	session_destroy(); //wichtig, neues Taschentuch generieren #replay-attacks
}

Sind die beiden Ergebnisse identisch, war das Passwort richtig.

Sicherheitsmassnahme

Für den Fall, dass ich in meinem Browser aus Versehen kein Javascript aktiviert habe, und das Passwort nicht per Taschentuch durch’s Netzwerk reisen würde, sondern im Klartext, stelle ich das Passwortfeld als Platzhalter dar, welcher dann durch ein Eingabefeld ersetzt wird, wenn Javascript aktiviert ist.

Damit kann ich gar nicht erst ein Passwort eintippen…

So. Die Taschentuch-einwickel-Funktion (aka SHA1) habe ich hier gefunden.
Ausprobieren könnt ihr’s da: http://scratchbook.ch/js_challenge-response/
Den Code gibt’s auf Github: https://github.com/claudehohl/js_challenge-response/blob/master/index.php

Hab‘ endlich begriffen, was der Sinn von „try-catch“-Konstrukten ist.

iWillFail();
 
iAmClean();

Wenn es tschätteret bei der iWillFail()-Funktion, dann kommt ein Fehler, das Programm stürzt ab. Mir egal, dachte ich früher; wenn ein Fehler passiert, dann passiert eben ein Fehler – ob ich den jetzt noch Abfange ist doch egal… Es brätscht so oder so.

Nun – nicht ganz 🙂

Bei obigem Code rumplet es, ja. Und das Programm stürzt ab, genau.
iAmClean() wird nicht mehr ausgeführt.

try {
	iWillFail();
} catch(e) {}
 
iAmClean();

Hier wird das iWillFail() abgefangen. Es brätscht. „Hmm, dehaut“, sagt sich das Programm und läuft weiter…
iAmClean() wird ausgeführt.

😉

Nützlich bei externen Programmen wie z.B. Tracking-Skripts, wo man nie genau weiss, ob die gut laufen oder nicht. Falls nicht, läuft wenigstens der Rest weiter und es reisst nicht gleich das ganze Programm in den Abgrund…

Kunde möchte eine voraussichtlich stark frequentierte Seite mit Typo3 bei sich hosten. 
Erwartet werden 5000 Benutzer gleichzeitig – die geschätzt alle 10 Sekunden klicken. Ergibt 500 Requests/s. Wir sollen die Architektur vorschlagen.

Mein Metier. Nach einer zweiwöchigen Evaluation kristallisierte sich Nginx mit FastCGI als Webserver heraus, weil der FastCGI Anfragen cachen kann und somit auf eine tolle Geschwindigkeit kommt.

Das Problem ist nicht der Cache an sich. Das Problem ist, wie Nginx damit umgeht, wenn der Cache verfällt.

Der Cache hat ein Ablaufdatum, eine Time-To-Live, TTL. Läuft diese ab, muss das HTML vom Backend neu geholt werden. Und wenn der Cache bei 500 gleichzeitigen Anfragen pro Sekunde abläuft, muss das HTML 500 mal gleichzeitig vom Backend geholt werden. Schönä!

[mehr…]