Blog

Auf codinghorror.com habe ich neulich einen interessanten Artikel gelesen, der sich mit der generellen Frage beschäftigt, ab wann man ein Experte ist, ab wann man dazulernt und warum Praxiserfahrung wichtig ist.

[...]Contrary to what you might believe, merely doing your job every day doesn't qualify as real practice. Going to meetings isn't practicing your people skills, and replying to mail isn't practicing your typing. You have to set aside some time once in a while and do focused practice in order to get better at something. I know a lot of great engineers -- that's one of the best perks of working at Amazon -- and if you watch them closely, you'll see that they practice constantly. As good as they are, they still practice. They have all sorts of ways of doing it, and this essay will cover a few of them.[...]

Von täglicher Routine wird man nicht besser. Erst wenn man sich Zeit für neues nimmt, an seine Grenzen stößt und genau dort weitermacht wo man scheitert, wird man besser. Jeff Atwood hat eine interessante Liste mit Tipps zusammengetragen, von denen ich ein paar für sehr wichtig halte und deshalb - zusammen mit einigen Tipps von mir - hier noch einmal aufführe.

Such dir einen Helden

Schau dir auf Wikipedia die Pioniere der Informatik an und such dir einen davon raus. Folge allen Links und lese über ihn. Finde heraus, mit was sich dein Held beschäftigt (hat) und versuche seine Lösungswege zu verstehen.

Lese fremden Code

Lies täglich 20 Minuten lang Code von anderen Programmierern. Wenn du keinen Code von Arbeitskollegen oder Freunden bekommen kannst, such dir ein Open-Source-Projekt das dir gefällt und arbeite dich in den Code ein. (Beispielsweise Firefox, RubyOnRails, Django, Subversion, o.ä.) Anfangs scheint es so, als wäre der Code in einem Leben nicht zu überschauen, doch mit der Zeit findet man Muster, versteht die Zusammenhänge, erkennt wie Probleme gelöst wurden und lernt Techniken und Architekturen kennen. Auch erkennt man auf diese Weise, was guten Programmcode ausmacht.

Lasse andere deinen Code lesen

Such dir eine Person, die deinen Code lesen will und lasse diese deinen Code bewerten. Gute- sowie schlechte Programmteile müssen hervorgehoben werden, nur so lernt man dazu. Ein "Ja, ist ganz nett" bringt niemanden weiter.

Nutze deine Programme besser

Mach eine Liste mit deinen 10 meistgenutzten Tools und lese für eine Stunde das Hanbruch/Dokumentaton/ManPage eines zufällig ausgewählten Programms. Versuche in dieser Stunde neues über dieses Programm herauszufinden und Arbeitsabläufe zu beschleunigen. Beispielsweise Shortcuts, Features von denen du noch nichts gehört hast oder Konfigurationseinstellungen, die die Bedienung einfacher machen.

Programmiere!

Theorie schön und gut, aber ohne richtige Programmiererfahung wird man nicht weit kommen. Der Beste Weg dafür ist es einfach zu tun. Probiere neue Technologien aus, schaue dir unterschiedliche Frameworks an und hacke was das zeug hält!

Wer ist der Beste?

Suche und arbeite zusammen im Team an Projekten. Finde heraus, was es bedeutet, der beste und der schlechteste Programmierer zu sein. So kannst du herausfinden, wie du besser werden kannst.

Code-Pflege

Lerne fremden Programmcode, den du nicht geschrieben hast zu warten. Am Besten funktioniert das, in dem man ein verwaistes Projekt wieder auferstehen lässt (fork) oder Fehler behebt (bug-fixing). So lernt man, was es ausmacht, wartbaren Code zu schreiben.

Lerne verschiedene Programmiersprachen

Such dir eine Programmiersprache heraus, die komplett andere Konzepte und Strategien verfolgt, welche du bis jetzt noch nie genutzt hast oder welche dir bis jetzt noch nie bewusst waren.

Für weitere Tipps und Kritik steht die Kommentarfunktion und die Anmerkungen am Linken Rand bereit :)

Letzten Winter bin ich auf das Projekt Gutenberg gestoßen und fand es eine wirklich tolle Idee. Wer es nicht kennt: Bücher deren Autoren bereits seit längerem gestorben sind, gelten als Allgemeingut und dürfen frei verwendet werden. Um dieses Allgemeingut zu gewährleisten hat sich das Gutenberg-Projekt zur Aufgabe gemacht, diese Bücher und Texte zu digitalisieren und allen in offenen Formaten zum freien Download bereitzustellen.

Doch die erste Frage die ich mir gestellt hatte war: Wer bezahlt die aufwändige Digitalisierung? Schnell bin ich über librarything.de auf pgdp.net gestoßen (Project Gutenberg Distributed Proovereaders). Hier helfen hinderte von freiwilligen beim manuellen Korrekturlesen und Einscannen der Bücher.

Der Vorgang ist recht simpel: Eine Person scannt alle Seiten eines Buches (welches als "Allgemeingut" gilt) mit einem normalen Scanner ein und jagt diese Bilder durch eine OCR-Software. Natürlich erkennt die Software nicht alles hundertprozentig und die Formatierung geht auch verloren. Gerade bei Frakturschrift wird viel falsch erkannt und muss manuell korrigiert werden. Auch Dinge wie Seitenzahlen oder Schmutz der als "Wort" erkannt wurde müssen entfernt werden, oder Überschriften müssen als solche gekennzeichnet werden. Diesen Job übernehmen die freiwilligen Helfer in mehreren Etappen. Die erste Durchsicht behebt nur die groben Fehler und kümmert sich garnicht um die Formatierung. Die zweite und dritte Durchsicht macht den Feinschliff und korrigiert evtl. vergessene Erkennungsfehler u.ä. Das fertige "Produkt" wird dann in PDF, TXT und andere Ausgabeformate transformiert und an das Projekt Gutenberg übergeben, welche dann für die Publikation und den Download sorgen.

Weltweit werden im Schnitt 200 Bücher pro Monat auf diese Weise digitalisiert. Eine beachtliche Leistung! Ich habe bereits 130 Seiten bei gaga.net (dem deutschen Ableger) korrigiert und dann bei pgdp.net weitergemacht. Der Grund dafür war die etwas merkwürdige Lizenzierung bei Gaga. Hier werden die Rechte teilweise auf spiegel.de übertragen. Beim amerikanischen Orginal landen alle korrigierten Bücher direkt bei gutenberg.

Mir hat es bis jetzt viel Spaß gemacht, ab und an ein paar Seiten zu korrigieren. Die Frakturschrift ist sehr gewöhnungsbedürftig, aber nach ein paar Seiten klappt das ganz gut. Vor allem ist es interessant, Texte zu lesen, die man sonst nie gelesen hätte. Da kommt man oft in Versuchung, immer weiter zu machen :) Für mich ein ideales Mittel, um mal für ein paar Minuten abzuschalten und zudem was für die Allgemeinheit zu tun.

Mitmachen kann jeder der Lust hat. Das Korrigieren läuft über den Browser und kann von überall (einigermaßen großer Bildschirm vorausgesetzt) gemacht werden. Anfangs darf man sich allerdings nur Bücher heraussuchen, die in Stufe P1 (erste Korrektur-Instanz) stehen, später darf man auch das Formatieren und die Korrektur der Korrektur übernehmen.

Ich bin schon seit vielen Jahren auf der Suche nach einer Möglichkeit, GUIs mit einem grafischen Editor zu erstellen und trotzdem nicht von einer IDE abhängig zu sein. Ich wünschte mir ein Tool, mit dem ich die GUI erstellen könnte und als "Output" eine (XML)-Beschreibung der erstellten Oberfläche erhalten würde.

AWT/Swing in Java war mir schon immer zuwieder (mit und ohne GUI-Builder). Der (live) generierte Java-Code ist meist dermaßen hässlich und nachträglich unwartbar, so dass ich meist wieder selbst Hand angelegt habe und die GUI-Elemente selbst plaziert habe. Dass es hier noch keine vernünftige Lösung gibt, wundert mich immer wieder.

Vor kurzem bin ich auf Ruby-Gnome2 gestoßen, was meine Erwartungen mehr als erfüllt hat: Mit dem general purpose GUI Builder GLADE erstellt man die GUI und speichert diese als Projekt ab. Das abgespeicherte Projekt besteht aus einer einzelnen XML-Datei, in der die komplette GUI inkl. "signals" (Event-/ActionListener für die Java-Programmierer) definiert sind. Diese XML-Datei lässt sich nun mit der GladeXML-Lib in Ruby mit wenigen Zeilen Code einlesen und ausführen. Auf Signale/Events kann man mühelos mit simplen Methoden zugreifen.

Wer mir nicht glaubt, hier eine kleine Demonstration: Zuerst wird mit GLADE die Oberfläche erstellt.

Links (1) hat man die übliche Toolbox, die alle Komponenten enthält, die man für eine grafische Oberfläche braucht. Das "Designfenster" (5) in dem die GUI erstellt wrid, verhält sich genauso wie jedes andere Fenster. So kann man seine Oberfläche direkt live testen. Im Eigenschaften-Fenster lassen sich zu jeder platzierten Komponente Einstellungen wie Ausrichtung oder Beschriftung vornehmen (2). Unter dem Reiter "Packing" (3) lässt sich das Layout bestimmen. Unter "Signale" (4) lassen sich Events definieren und diesen Namen geben.

Hat man die Oberfläche soweit fertig, speichert man das Projekt ab. Als Resultat erhält man zwei Dateien. Eine projektname.glade und eine projektname.gladep. Die erste enthält die Beschreibung der GUI, und sieht ungefähr so aus (Ausschnitt!):

<glade-interface>
<widget class="GtkWindow" id="w1">
  <property name="visible">True</property>
  <property name="title" translatable="yes">Beispiel</property>
  <property name="type">GTK_WINDOW_TOPLEVEL</property>
  <property name="window_position">GTK_WIN_POS_NONE</property>
  <property name="modal">False</property>
...

Diese Datei lässt sich nun mit wenigen Zeilen Code in einer Ruby-Applikation einbinden. Wem das noch zu viel Arbeit ist, kann auch das Skript "ruby-glade-create-template" verwenden, um sich ein lauffähiges Grundgerüst zu generieren. Der so generierte Code sieht ungefähr so aus:

require 'libglade2'

class SampleGlade
  include GetText
  attr :glade
  
  def initialize(path_or_data, root = nil, domain = nil, localedir = nil, flag = GladeXML::FILE)
    bindtextdomain(domain, localedir, nil, "UTF-8")
    @glade = GladeXML.new(path_or_data, root, domain, localedir, flag) {|handler| method(handler)}
    
  end
  
  def on_button1_clicked(widget)
    puts "on_button1_clicked() is not implemented yet."
  end
end

if __FILE__ == $0
  SampleGlade.new("sample.glade", nil, "Sample App")
  Gtk.main
end

Das so erstellte GUI-Programm ist direkt unter Windows und Linux lauffähig (GTK, Ruby und die Ruby-Gnome2-Lib vorausgesetzt). Genau so stelle ich mir Oberflächenprogrammierung vor! Sauber, einfach, Plattformunabhängig und komplett vom restlichen Code getrennt.

Toll wäre es nun, wenn sich jemand die Mühe machen würde und GladeXML in Java und Swing nachbilden würde. So könnte man ein und die selbe GUI in einem Java-Programm und in einem Ruby-Programm nutzen!

Der Fernsehr ist eines der primitivsten Geräte die es zu kaufen gibt. Er besteht aus einem Schalter für an/aus und zwei Knöpfen: "Vor" und "Zurück". Das einzige was man mit diesem Kasten machen kann, ist die vorgefertigte Suppe passiv zu konsumieren oder zum nächsten Sender zu wechseln. Nur dumm, dass auf allen Sendern das selbe(?) läuft.

Vielleicht bin ich auch schon viel zu verwöhnt vom Internet, wo ich selbst entscheiden kann was ich wann wie und von wem konsumieren kann und auch aktiv mit dem Ersteller in Kontakt treten kann. (Ja, ich bin ein Web 2.0 Junky)

Seit ca. 5 Jahren schaue ich kein TV mehr und bin immer erstaunt, was für Müll spurlos an mir vorbeirauscht. Das ist mir erst neulich wieder bewusst geworden, als sich ein paar Kommilitonen über "Germany's next Topmodel" unterhalten haben und ganz erstaunt waren, dass ich nicht wusste wer Heidi Klumm ist.

Ich stille meinen Medien-Konsum fast ausschließlich durch das Internet. Meine Lieblings-Serien lade ich mir herunter (Ja, ich zahle auch GEZ!) oder kaufe mir die Staffel(n) bei eBay. Für den daily input schaue ich Vidcasts (revision3.com), den Rest erledigt alles digg.com, golem.de, spiegel.de und mein Feed-Reader.

Ich bin gespannt, wie lange sich dieses Medium noch halten wird.

Mein Bruder hatte sich vor ca. einer Woche Metal Gear Solid 4 für die PS3 gekauft und ich muss sagen, ich hab noch nie so ein grandioses Spiel gesehen und gespielt. Die Grafik ist einfach umwerfend. Man kommt sich vor, als würde man in einem Film mitspielen und die Handlung beeinflussen. Wie auch die vorherigen MetalGear-Teile gibt es auch in diesem Teil so viele Details und Gimmicks das man hier wirklich von Perfektion reden kann.

Und das Beste: Man kann das Spiel auch über das Internet spielen. Doch dazu braucht man allerdings einen Login, und hier wurden wir geschockt:

Um einen Zugang zu bekommen öffnet sich auf der PS3 der integrierte WebBrowser mit einem Formular. Nach Auswahl der Sprache gelangt man zu einem etwas längerem Formular. Mein Bruder tippte sich die Finger wund, aber das war ok, schließlich wollten wir im Internet spielen. (Ja, man kann auch eine USB-Tastatur anschließen, aber auf die Idee sind wir erst später gekommen). Wieso wir eine KONAMI-ID und eine GAME-ID brauchten war und nicht klar, wir vermuteten schon, dass man hier evtl. die Seriennummer des Spiels eintippen musste. Am Ende des Formulars gab es zwei Buttons: "Weiter" und "Start". Leider war der "Start"-Button mit dem ersten Formular verlinkt, also nochmal alles in mühevoller Kleinarbeit ausfüllen. Nach einem Klick auf "Weiter" bekamen wir eine ziemlich lange Liste mit Hinweisen, was alles falsch ausgefüllt wurde. Nach ca. 5 weiteren Submit-Versuchen waren alle Fehler verschwunden, aber es passierte nichts! Keine Fehlermeldung, kein weiteres Formular, nichts.

Da wir offentlichtlich in einer Sackgasse gelandet waren, haben wir es nochmal am PC versucht, allerdings ging es hier ebenso nicht mehr weiter. Nach etwas Recherche fanden wir hunderte von anderen die das selbe Problem hatten. Es gibt bereits mehrere "Tutorials" um dieses Formular erfolgreich auszufüllen, die aber alle nicht funktionierten.

Hier frage ich mich, wie sowas passieren konnte? Das Spiel ist nahezu makellos und es stecken Jahre an Entwicklungs- und Denkzeit darin, und dann blockiert ein dermaßen bescheuertes Registrierungsformular das halbe Spiel.

Da ich in letzter Zeit wieder mehr mit JavaScript arbeite, habe ich mich (mal wieder) nach einer schlanken und dennoch starken IDE für die Sprache umgeschaut. Fündig wurde ich auf der Mozilla-Seite. Das Programm heißt Spket IDE und basiert auf Tiny Eclipse, einer abgespeckten Version der Eclipse-Umgebung.

Die IDE hat die von Eclipse bekannten Shortcuts und fühlt sich ziemlich ähnlich an, auch wenn einige Funktionen fehlen. Der Outline-Browser zeigt ähnlich wie in anderen Sprachen einen Baum der Klassen/Objekte und Funktionen an. Der Editor macht einen automatischen Syntax-Check und warnt vor Fehlern.

Ein weiteres Programm das bei der Erstellung von JavaScript-Code nicht fehlen sollte ist SpiderMonkey. Dies ist die JavaScript Engine die in Firefox und einigen anderen Anwendungen eingebettet wurde. SpiderMonkey (im Ubuntu-Universum unter spidermonkey-bin zu finden) kann entweder als interaktive Shell (mit dem Befehl "js") genutzt werden oder zu Ausführung eines Scripts (js -f scriptname.js). Da JavaScript im Browser eigentlich keine Ausgabe hat, bietet der Interpreter einige Zusatzfunktionen wie print() oder load() um mit der Console zu Kommunizieren bzw. andere JavaScript-Dateien nachzuladen (was man im klassischen Sinne über einen HTML-Tag macht).

Mit diesem Interpreter kann man nun wunderbar (automatisch) UnitTests durchführen, ohne den Browser zu starten und sich das Ergebnis in Firebug, der JavaScript Fehlerconsole oder eingebettet im HTML anzuschauen. Ein tolles Framework hierzu ist JSUnit, welches schon Optionen für den Betrieb mit SpiderMonkey bereitstellt.

Das musste endlich mal gemacht werden. Seit ein paar Wochen lief mein Mailserver nicht mehr ganz rund und der ganze Spam-Rotz landete mit all den anderen Mails in der Inbox ohne markiert zu werden. Das waren pro Tag ca. 350-400 Mails.

Nun hab ich Spamassassin wieder vernünftig eingerichtet und bei dieser Gelegenheit gleich das Subject der Spam-Mails etwas angepasst. Die Zahl gibt jetzt an, wieviel Spam wirklich in der Mail steckt. Ab einem Wert von von 2 landet die Mail automatisch per Procmail im Trash, der einmal am Tag geleert wird. Also Vorsicht, wer mir eine HTML-Mail mit leerem Betreff und ein paar einschlägigen Schlüsselwörtern schickt geht Gefahr im Müll zu landen :-)

Die Option lässt sich übrigends in der Datei /etc/spamassassin/local.cf einstellen. Dazu einfach folgende Optionen setzen:

rewrite_header Subject [*** SPAM _SCORE_ ***]
report_safe 0

Die Variable SCORE steht für den den Spam-Score, der von Spamassassin berechnet wird, um zu erkennen ob es sich um Spam handelt oder nicht. report_safe muss auf 0 stehen, damit der neue Betreff gesetzt werden kann.

Altanwendungen zu betreuen ist oft nicht einfach, bei Webanwendungen wird es meist noch umständlicher und niemand macht es gerne. Wenn man beispielsweise die Blogsoftware wechselt, auf ein CMS-System wechselt oder gar die neue Version selbst programmiert hat, stimmen die alten URLs nicht mehr. Das ist besonders ärgerlich, wenn die alte Seite viele Backlinks hatte, die nach dem Umzug nicht mehr funktionieren.

Ein Beispiel: In der alten Anwendung sahen die URLs so aus: http://example.com/blog/index.php?id=123. In der neuen Software sieht die URL, die zum gleichen Content führt, anders aus: http://example.com/123-meine-neue-webseite.

Was also tun? Es hinnehmen? Das alte System parallel weiterlaufen lassen, nur damit die Links noch stimmen? Zu umständlich. Aktuelle Webserver bieten die Möglichkeit an, URLs mit Hife von mod_rewrite intern umzuschreiben. Dieses Feature wird meistens dafür verwendet um die URLs einfacher, verständlicher und "sicherer" zu machen.

Diese Funktionalität kann man auch dafür verwenden um das Altsystem zu "faken". Hier eine Lösung in Lighttpd für das obige Beispiel (Voraussetzung hierfür ist natürlich, das die neue Blogsoftware die Seite nur anhand der ID auswählt und nicht zusätzlich am Seitennamen):

url.rewrite-once(
    "/blog/index\.php\?id=([0-9]+)." => "/$1-old-url")

Alles was in der Form /blog/index.php?id=xxx am Webserver eintrifft wird auf das neue URL-Schema umgeformt. So erhält man seine alten URLs weiter am Leben, ohne das sie weiter existieren müssen.

Was aber tun wenn man keine Verknüpfung zwischen alter und neuer URL herstellen kann? Dies passiert beispielsweise dann, wenn man im neuen System die Seite nicht anhand der ID sondern anhand des Seitennamens auswählt (/blog/meine-neue-webseite z.B.). Hier führt kein Weg an einem kleinen Hilfsscript vorbei das die fehlende Verbindung wieder herstellt. Im obrigen Beispiel müssten wir eine Beziehung zwischen der ID und des Seitennamens herstellen. Ein einfaches PHP-Script könnt so aussehen:

$row = $sql->query(
    "SELECT url_name FROM entries WHERE id=?",
    $_GET['id']);
header("LOCATION: /blog/".$row->url_name);

Das kleine Script sucht den Seitennamen anhand der ID raus und leitet dann an diese weiter. Die Regel für mod_rewrite würde dann so aussehen:

url.rewrite-once(
    "/blog/index\.php\?id=([0-9]+)." => "/legacy.php?id=$1")

Hat die neue Seite den Content der alten Seite nicht mehr, kann man diese Technik auch dazu nutzen um die alten URLs auf eine Übersichtsseite oder eine spezielle "existiert nicht mehr"-Seite umzuleiten.

(Bild von @t.)

Im Laufe meines Studiums habe ich einige Vorgehensmodelle zur Softwareentwicklung kennengelernt. Besonders ausführlich wurde das Wasserfallmodell behandelt. Wer es (noch) nicht kennt: Der Softwareentwicklungsprozess ist in 5 Phasen eingeteilt, welche linear durchlaufen werden. Zuerst wird die Software geplant, sprich ein Lasten und Pflichtenheft erstellt welches beschreibt was die Software können muss. Daraus wird der Entwurf der Software (meist mit UML) erstellt. Dieser Entwurf wird in Software umgesetzt und anschließend getestet. Am Ende wird die Software ausgeliefert, Installiert und gewartet. Die einzelnen Phasen sind wie bei einem Wasserfall angeordnet und strikt getrennt. Wenn bei der Implementierung Designfehler entdeckt werden wird wieder bis zur Entwurfsphase gesprungen, der Fehler behoben und dann wieder die Kette nach unten geklettert.

Irgend wie konnte ich mich mit diesem Modell nie richtig anfreunden und habe auch nie wirklich geglaubt das ein solches Konzept erfolgreich angewandt werden kann. In dem Buch Ship it! von Richardson und Gwaltney bin ich hier auf meine lang ersehnte Bestätigung gestoßen:

Ein Vorgehensmodell, das Sie vermeiden sollten, ist das berüchtigte Wasserfallmodell. Es wurde in fortschrittlicheren Entwicklerkreisen allgemein verworfen, trotzdem ist es erstaunlich, in wie vielen Unternehmen es immer noch angewendet wird. [...] Ahnungslose Manager, die in Zeitpläne vernarrt sind, sind schon seit vielen Jahren Anhänger dieses Vorgehensmodells.

Als pragmatische Alternative zu den eingerosteten Vorgehensweisen stellt das Buch das von Thomas und Hunt entwickelte Tracer Bullet Development (TBD) vor. Ziel ist es hier, die Anwendung so schnell wie nur möglich lauffähig/ausführbar zu machen. Anfangs wird die Anwendung in Bereiche eingeteilt und Schnittstellen spezifiziert. Die einzelnen Klassen mit Methoden werden als stubs angelegt und geben bestenfalls statische dummy-Werte zurück. Wenn dieses Grundgerüst steht, werden die einzelnen Methoden ausprogrammiert und mit der Zeit verfollständigt.

Ein interessantes Konzept wird auch bei den Schnittstellen angewendet: Alle Schnittstellen kommunizieren über das Netzwerk, auch wenn beide Teile auf einem Prozessor laufen. Das hat den Vorteil, das eine Loose Kopplung erzwungen wird und die Software am Ende viel besser skaliert werden kann.

Doch eines hat dieses Konzept mit dem Wasserfallmodell gemeinsam. Es geht davon aus, das das Konzept der Software entgültig ist und das von Anfang an feststeht wie die Software am Ende auszusehen hat. Es ist zwar viel leichtgewichtiger als die "großen", aber nicht so Agil wie XP und Co. Martin Fowler unterscheidet hier zwischen geplantem und wachsendem Design.

Ich denke es kommt immer darauf an, was für Software man entwickelt. Wenn es eine Neuimplementierung einer alten Steuersoftware ist, spricht eigentlich nichts gegen TBD, doch wenn beim umzusetzenden Programm ganz neue Technologien verwendet werden, Features implementiert werden sollen die es zuvor noch nicht gegeben hat und anfangs noch garnicht klar ist, wie das Endergebnis aussehen soll (oder der Kunde nicht weiß was er will), sind agilere Vorgehensweisen angebrachter.

Der (jetzt nicht mehr ganz) King of the Internet Zed Shaw fordert mehr Hass für das Internet. Schluss mit den braven Protokollen die jeden Schrott zulassen und Servern die alles akzeptieren müssen. Weg mit den Mailservern die jede Spammail mit einem höflichen HELO entgegennehmen. Jeder der in irgend einer Weise Müll von sich gibt wird gnadenlos in die Fresse geschlagen und für alle Ewigkeit gebrandmarkt.

Auf savingtheinternetwithhate.com beschreibt er sein neues Vorhaben Utu mit recht eindeutigen Worten.

The Internet needs more hate. Much more. We’re overrun by morons, assholes, griefers, spammers, porn peddlers, Nazi dictators, little Napoleons, and arbitrary censors who only behave in their socially deficient manner because they know you can’t do anything about it. [...]

In den Griff kriegen will er das durch ein neues Protokoll das einer sicheren Benutzeridentifizierung, einem Bewertungsschema und einem Bestrafungsmechanismus zugrunde liegt. ("[...] The Internet needs identity, reputation, and retribution. [...]").

Nun frage ich euch: Was haltet ihr davon? Soll das Internet mehr einem digitalen Abbild der realen Welt gleichen ("[...] In the real world you would tell them to screw off personally. You’d call the police. You’d move to the other side of the room and tell all your friends to ignore them. You’d punch them in the face for the things they said about you and your family. [...]") oder kann das Internet nur dann weiter bestehen, wenn jeder gleichberechtigt behandelt wird egal was er anstellt und jeder tun und lassen kann was er will?