programmierung - 28.3.2011 - 11.5.2011

App Engine Go Overview. Ehrlich gesagt fänd ich es ja spannender wenn Google mal vom veralteten Python 2.5 wegkäme. Aber nunja, statt Python 2.7 oder einer JVM Sprache kann man jetzt mit Go die AppEngine programmieren. Gleichzeitig haben sich aber Preise und Bedingungen geändert, wär also wohl besser erstmal zu gucken ob es sich überhaupt lohnt. Go kann man nämlich auch genauso gut auf seinem eigenen Root Server benutzen ...

bconstantin / django_polymorphic. Warum finde ich das erst jetzt? Das ist eine sehr nette Sache für Django-Projekte mit vererbten Modellen - sobald man Zugriffe auf eine gemeinsame Modell-Klasse macht, erhält man bei Django nur Instanzen der gemeinsamen Modell-Klasse - bei Django-Polymorphic aber erhält man Instanzen der konkreten Unterklassen. Im Prinzip wird der ORM dadurch mehr zu einer Objekt-Datenbank. Dürfte allerdings etwas zulasten der Performance gehen, da mehr SQL-Abfragen erzeugt werden.

Mixing it up: when F# meets C#. Da man ja nie in einem abgeschlossenen Raum programmiert, sind die Verbindungen zwischen Sprachen recht wichtig - und besonders auf Plattformen wie .NET und JVM. Die Abbildungen von F# Datentypen auf C# Datentypen und die Nutzung dieser sieht recht interessant aus. C# Daten von F# nutzen ist ja trivial, aber umgekehrt gibt es schon einige Besonderheiten. Eine Ähnliche Situation gibt es ja auch bei Scala und Java.

birkenfeld / karnickel. Ziemlich schräges Teil: Makros auf AST Level für Python. Allerdings in einer Form, die dann doch eher an C Makros erinnert - also einfache Expression-Makros (und recht stark limitierte Block-Makros). Vor allem fängt man sich all die bösen Probleme eines solchen unhygienischen Makrosystems ein - wie zum Beispiel Namenskonflikte zwischen makro-lokalen Variablen und äußeren Variablen. Ist auch eher einfach nur der Beweis das es geht und was man mit dem in Python mitgelieferten AST Modul machen kann.

dyoo/moby-scheme. Noch eine interessante Sache für Android: ein PLT Scheme (also Racket) Dialekt und eine passende Toolchain um aus Racket Advanced Student Language + World Primitives (ASL ist ein schon recht weit gehender Scheme-Dialekt in Racket und die World Primitives sind für reaktives Programmieren in Scheme) erstellte Anwendungen in JavaScript laufen zu lassen und diese dann zu Androit-Anwendungen zu bündeln. Also Programmierung von Android-Handys in einem reaktiven Scheme-Dialekt. Oder noch kürzer: Klammern für Android.

icylisper.in - jark. Hmm, wieder eine von vielen Lösungen für Clojure, die ein vereinfachtes Deployment von Clojure-Scripten ermöglicht, komplett mit persistenter VM und #! Unterstützung. Irgendwie werden das ein bischen viele in letzter Zeit.

Pygame Subset for Android. Huch - es gibt ein PyGame subset für Android. Nutzung ist etwas hakelig, weil es keine IDE gibt - man muss die Files auf der SD Karte (hmm - ein Nexus S hat keine SD Karte, wo landet das dort?) ablegen und anderweitig editieren.

android-scripting - Scripting Layer for Android brings scripting languages to Android.. Interessantes Projekt mit dem man diverse Scriptsprachen auf Android-Telefonen laufen lassen kann. Unterstützung für Shell, Python, Perl, Ruby, Lua, TCL und JavaScript sind schon dabei. Für mich ist natürlich besonders Python interessant. Vor allem weil die API von Android verfügbar gemacht wird - man kann also direkt mit den Sachen interaktiv oder gescripted rumspielen.

Scala 2.9.0 RC3 | The Scala Programming Language. Hmm, speziell die parallel collections klingen interessant - sozusagen map/reduce für Multicore auf lokale Datenstrukturen.

jQuery: » jQuery 1.6 Released. Apropos jQuery - neue Version ist raus. Diese .attr vs. .prop Änderung finde ich persönlich irgendwie ungut - sie könnte mich an ein paar Stellen beißen, wo ich direkt mit Input-Feldern arbeite (diverser Widget-Code in einer recht heftigen Django-Anwendung). Schön natürlich, dass es schneller wird - schneller ist fast immer gut.

stanlemon.net : jgrowl. unbedingt mal angucken, denn unsere handgestrickten Notifications sind einfach nicht so schick und stabil. jGrowl macht da einen deutlich netteren Eindruck, und als jQuery Plugin sollte es auch mit unserer jQuery Codebase nicht kollidieren.

PyPy Status Blog: PyPy 1.5 Released: Catching Up. Yay! PyPy ist jetzt auf dem Stand von CPython 2.7! Und wieder mal ein paar zusätzliche Performanceverbesserungen. Ausserdem ist das Interface für CPython Erweiterungsmodule (also welche die eben nicht in Python geschrieben sind) verbessert, erste Erfolge sind Tkinter und IDLE.

spock - The Chicken Scheme wiki. Wem Dylan auf JavaScript nicht passt, wie wäre es mit Scheme? Interessant hieran ist die Verbindung zu Chicken Scheme - chicken scheme ist eine der interessanteren Scheme-Implementierungen der letzten Zeit die sich speziell der Integration in normale Systemumgebungen widmet (FFI und einfaches Linken mit C-Libs), von daher lässt das auch ein bischen was von Spock in Bezug auf JavaScript erwarten. Und die dokumentierten Funktionen schauen auch schon recht gut aus - nicht einfach nur eine Spielzeugimplementierung, sondern scheinbar schon eine Menge von Funktionalität.

turbolent/ralph. Und wem dann unter Flusspferd das JavaScript zu blöd wird, der kann ja einfach Ralph installieren und hat dann ein Dylan-ähnliches Lisp, das seine Funktionsdefinitionen nach JavaScript compiliert. Warum auch immer man das wollen würde, vielleicht einfach nur weil es geht.

Flusspferd - CommonJS platform | Javascript bindings for C++. Für diejenigen, die mal mit JavaScript ganz ausserhalb der Client-Welt spielen wollen ist Flusspferd vielleicht interessant. Das ist eine REPL für JavaScript und diverse JavaScript-Bibliotheken (die sich an CommonJS orientieren).

PDP-11 emulator. In JavaScript. Führt Unix System 6 aus. Ja, so richtig so mit Plattenzugriff und all den bekannten Programmen von damals. Weil es noch nicht genug seltsame Sachen gibt.

Nochmal iPhone Location Daten

Nur nochmal zu der Antwort von Apple zu den Bewegungsprofil-Vorwürfen und warum Apple Recht hat, aber trotzdem ein Problem besteht (aber eines, das deutlich kleiner ist als das dramatisierte Problem in der Presse).

Apple produziert mit - anonym gesammelten, bisher gibt es da auch keine Anzeichen, dass es nicht anonym wäre - Positionsdaten der iPhones mit aktiviertem GPS eine Datenbank, in der Positionen von Netzen gespeichert werden. Netze sind hierbei Funktürme für GSM, 3G und WLANs die das iPhone zu dem Zeitpunkt sieht. Das ist allerdings nicht das, was in dieser Datenbank gespeichert wird, von der alle Reden. Das ist nur die Grundlage, auf der etwas aufgebaut wird, was dann in der Datenbank landet.

Die an Apple gesendeten Daten werden intern gemittelt und daraus für die von diversen iPhones gemeldeten Netze ein "Zentrum" ermittelt (denn die genaue Position von WLAN Routern oder Funktürmen kriegt man ja nicht einfach so geliefert - die muss erst irgendwie ermittelt werden). Diese Daten werden in einer großen Datenbank bei Apple gespeichert. Die Positionsdaten beziehen sich also auf das Zentrum von Funkidentifikationen. Die Originalen Positionsdaten sind nur Basismaterial für die ermittelten Positionsdaten.

Das iPhone kann jetzt über die sichtbaren Funkidentifikationen und deren Positionsinformationen und eine über die Sendestärke gewichtete Mittelung der Daten eine ungefähre Position ermitteln - dazu ist aber Internet Zugriff notwendig. Und Zugriff über Internet auf die Datenbank bei Apple. Daher lädt das iPhone die Informationen zu Funkidentifikationen herunter und cached diese lokal. Aber natürlich nicht die ganze Datenbank - das wäre zu viel. Sondern eben ein nach Algorithmen ermittelter relevanter Ausschnitt. Das jetzt ist die Datenbank auf dem iPhone.

Dazu wird von Apple scheinbar nicht nur das an Netzen runtergeladen was das iPhone gerade sieht, sondern wohl auch Nachbarnetze - macht nur Sinn, da der Benutzer sich ja öfter mal bewegt und man damit die Daten von Nachbarnetzen brauchen wird (potentiell - das iPhon weiss ja nicht voraus wohin ich gehe). Vermutlich wird also das iPhone sagen "ich sehe Netze A, B, C" und die Datenbank liefert dann "hier sind die Netze A-M aus dem Großraum in dem du dich befindest". Das iPhone nimmt dann X% von A, Y% von B und Z% von C als Basis und errechnet daraus eine grobe Position und sagt "hier bin ich". Wenn es sich dann in die Sichtbarkeit von Netz D bewegt, ist dessen Position schon bekannt und das iPhone kann die Positionsberechnung ohne Download direkt vornehmen.

Zusätzlich scheint das iPhone eine zeitliche Historie dieser Downloads zu speichern - vermutlich hat der Entwickler angenommen, wenn der Benutzer da schon mal war, ist die Chance hoch, dass er da wieder hin will. Dabei hält das iPhone wohl ein Jahr an diesen Daten parat. Die Behauptung von Apple, die Dauer der Speicherung sei ein Bug, ist sicherlich eher eine Beschönigung - vermutlich hat da einfach ein Entwickler sich eine Dauer ausgedacht und benutzt, ohne sich darüber Gedanken zu machen wieviel wirklich sinnvoll wäre - schließlich waren das ja keine besonderen Daten nach seinem Verständnis. Nur technische Caches für Downloads die er sowieso macht, wenn der Benutzer nach seiner Position fragt.

Was bedeutet das jetzt für den Benutzer? Die Daten geben in den Koordinaten nicht wieder, wo er war - sie geben nur wieder, wo die Funkidentifikationen sind, in deren Nähe er ungefähr mal war. Und da es auch Nachbarnetze enthält, ist das wirklich sehr ungefähr. Natürlich lässt sich dadurch ein grobes räumliches Profil des Benutzers ableiten - z.B. habe ich in meinen Daten durchaus sehen können, dass ich in Amsterdam, in Frankfurt und in Berlin war.

Aber z.B. bedeutet es auch im Umkehrschluss, dass nur die ungefähren Regionen drin sind, wenn man dort auch Netzempfang hatte, mit Downloadmöglichkeiten. Ich war in Kopenhagen - dort habe ich auch über das Hotel Netzzugang gehabt, also sind davon Spuren. In Malmö und zum Jahreswechsel in Russland hatte ich keinen Netzzugang - also zwar GSM, aber eben keinen Internetzugang - und daher konnte das iPhone auf diese Lokationsdaten nicht zugreifen und keine Funkidentifikationen mit Positionen runterladen. Daher fehlen diese Daten auch komplett in meinem iPhone und es gibt keine Spuren von Malmö, Ekaterinburg oder Nischni Tagil (ähnliches dürfte gelten wenn man den Flugzeugmodus aktiviert hat oder einfach WLAN und mobile Daten ausschaltet).

Desweiteren dürften die Räume größer werden wenn man in mehr ländliche Regionen kommt - wenige WLANs, also hauptsächlich GSM Zellen und diese mit größerer Sendereichweite und weiter gestreut. Wenn man da eine Zelle mit den Nachbarn speichert, ist das schon ein ziemlich großer Raum, der abgedeckt ist. In Großstädten hingegen dürften die abgedeckte Fläche deutlich kleiner sein, einfach weil WLANs deutlich kleinere Reichweiten haben und von denen dort mehr da sind. Und Funkzellen dort auch in der Regel kleiner sind (allein schon weil eine Zelle nur endlich viele User abdecken kann, aber die Dichte der User in Städten größer ist).

Interessant ist das ganze besonders für Programmierer: denkt ihr bei eurer Programmierung darüber nach, was sich z.B. aus gecachten Daten ableiten lässt? Nehmt mal als Überlegungsgrundlage mal an, jemand hat Zugriff auf euren DNS Cache - den ja jedes System intern hat, einfach um DNS-Abfragen zu reduzieren. Was könnte diese eigentlich technisch doch völlig harmlose Information über euch als Bild produzieren? Es sind diese kleinen Fallen über die man als Programmierer gerne stolpert. Eigentlich ist es ja harmlos - Hilfsdaten, die man aus dem Netz holt sind der Anfang. Wegwerfen nach der Nutzung - naja, wenn sie wieder gebraucht werden, dann macht es Sinn die häufigsten parat zu haben, oder? Und genau dann rennt man in solche Probleme wie sie Apple derzeit hat.

Die Diskussion, warum euer Browsercache Pornobildchen enthält (weil ihr z.B. mit Outlook eure Mails lest und eine Spammail geöffnet habt und bei euch Bilderanzeige aktiviert war - keine abwegige Situation!), wenn eure Frau die dort findet, könnte schon recht interessant werden. Den Daten sieht man eben nicht mehr an, warum sie dort gelandet sind, wo sie gelandet sind.

Wie im Titel gesagt: ich beziehe mich hier auf die Antwort von Apple und habe das nur mit meinen eigenen Daten gegengeprüft. Meine eigenen Daten passen zu den Informationen aus der Stellungnahme von Apple und diese Stellungnahme selber ist auch schlüssig - sowohl die Inhalte als auch die Angabe der Nutzung passen durchaus. Ich sehe also keinen Grund, warum ich der Stellungnahme misstrauen sollte.

Die Antwort von Apple, dass das iPhone kein Bewegungsprofil des Benutzers festhält, ist also korrekt - es speichert eben nur Informationen für eine Positionsbestimmung als Alternative zum GPS. Gleichzeitig ist das aber zumindestens ein Profil des Aufenthaltes in Großräumen. Kritik ist also durchaus angebracht. Sollte aber meiner Meinung nach intelligenter als "Apple speichert die Positionen des Benutzers im letzten Jahr" sein, denn das ist schlicht falsch.

Aber wie Apple in der Einleitung der Antwort ja sagt: das sind technische Zusammenhänge, die eben komplizierter sind als einfach nur "speichert Apple ein Bewegungsprofil Ja/Nein". Und unsere Presse hat mit Fragen, auf die eine Antwort mehr als zwei Sätze enthält, massive Probleme. "Apple speichert Daten aus denen sich die Anwesenheit in Großräumen ableiten lässt" klingt auch nicht so toll und griffig als Überschrift.

Leider kann aber gerade diese sehr unpräzise Berichterstattung dazu führen, dass die Probleme erst entstehen - wenn ich weiß, dass die Daten nur Regionen abdecken in denen ich mal war, aber nicht präzise Punkte meines Aufenthalts, ist die Erklärung, warum meine Daten aus Frankfurt auch das Rotlichtviertel umfassen (ist halt Nähe Bahnhof) deutlich leichter als wenn ich davon ausgehen muss, das sind alles Orte wo ich war.

Apple muss (und wird ja auch nach eigener Erklärung) da nachbessern - denn ein Jahr an Daten zu cachen ist Quatsch. Auch die Daten zu sichern ist Unsinn, die können einfach neu runtergeladen werden wenn sie fehlen. Genauso braucht man die Daten nicht speichern, wenn alle Lokationsdienste global abgeschaltet sind. Vielleicht wäre es auch generell interessant da einen Schalter "Pseudo-GPS Ja/Nein" oder so anzulegen, mit dem diese Art der Positionsermittlung abgeschaltet werden kann - dann muss der Benutzer eben warten, bis die GPS Satelliten eingebucht sind. Genauso wie man meiner Meinung nach die anonymisierte Datensammlung zu WLAN und Funktürmen abschaltbar machen sollte.

Meines Erachtens sollte kein Cache ohne eine Kontrollfunktion für diesen Cache (so wie man den Browsercache ja auch leeren kann) existieren. Denn eines muss klar sein: durch die generelle Notwendigkeit der Verknüpfung von Zugriffszeitpunkt und geladenen Daten (denn nur so kann ein Cache mit zeitlich begrenzter Zwischenspeicherung funktionieren) liefert jede Art von Cache eine Art von Benutzerprofil. Und das sollte vom Benutzer zumindest rudimentär (im Sinne von Löschen) kontrollierbar sein. Caches grundsätzlich mit einer Leeren-Funktion und einem UI dafür anzulegen sollte genauso eine best-practice werden wie die verschlüsselte Speicherung von Passwörtern auf Servern (hallo Sony!).

kiorky/spynner. Wow, das klingt echt interessant - ein programmatischer (also ohne Oberfläche) Webbrowser auf Basis von QtWebkit als Python-Erweiterung. Der Vorteil? Dadurch, dass eine vollständige Web-Engine drunter steckt, kann man eben alle Features des Webbrowsers nutzen - zum Beispiel eben auch client-side JavaScript und all die anderen Sachen, die in Webanwendungen verwendet werden. Das könnte für automatisierte Tests von Webanwendungen sehr interessant sein - oder für das Scrapen von komplexeren Webseiten.

IgniteInteractiveStudio/SLSharp. Nett - GLSL Shader in C# programmieren, der IL-Code wird dann automatisch auf die GPU geladen. High-Performance-Computing anyone?

IronScheme. Interessant - ein Scheme für .NET. Und im Gegensatz zu einigen toten Projekten die ich gefunden habe, scheint hier auch noch was zu passieren. Ok, ich selber tendiere warscheinlich eher zu IronPython, F# oder wenn es Lisp sein soll, Clojure für .NET (davon gibts mitlerweile auch recht aktuelle binäre Pakete zum Ausprobieren, leider wohl derzeit nur Windows, jedenfalls spuckt es unter Mono Fehler aus).

F Sharp Programming - Wikibooks, open books for an open world. Scheint eine ganz nette Grundübersicht über F# zu sein - also besonders für die, die nicht schon Vorbelastung (z.B. von OCAML) mitbringen.

Home - Redline Smalltalk - Smalltalk for the Java Virtual Machine.. Noch nicht sehr weit, aber könnte irgendwann mal interessant werden - und als alter Smalltalk-Fan muss ich da natürlich ein Blogmark setzen.

The plan for mods : The Word of Notch. So sollten andere Spieleschmieden auch mit Mods umgehen. Nicht die Leute, die auf deinem Game aufbauen verklagen, sondern sie offen aufnehmen. Notch gibt gleich den ganzen Source dafür raus an Mod-Entwickler.

tvon / python-wordpress. Und um Posts und Bilder in Wordpress zu kriegen, könnte ich hiermit arbeiten - eine Python Library, die diverse Wordpress Funktionen zur Verfügung stellt. Allerdings gibts die in verschiedenen Versionen, in verschiedenem Zustand der Nicht-Pflege, muss ich also mal drübergehen und gucken ob alles so läuft wie ich es will.

Backing Up Flickr. Weil ich grade drüber gestolpet bin (ich suche nach Wegen um Flickr-Uploads automatisch auch in die Mediathek von Wordpress zu schieben, vorzugsweise vom Server aus, ohne dass ich immer nur manuell aktiv werden muss. Dazu müsste ich eigentlich das hier mit Wordpress-Funktionen verheiraten (es ist ein Python-Script, welches Flickr Bilder in Verzeichnisse sichert). Die Backup-Funktionalität tuts übrigens. Vielleicht auch garnicht so eine blöde Idee, einfach ab und an mal seinen Flickr-Account zu sichern ...

Jess, the Rule Engine for the Java Platform. Falls man mal eine Rules-Engine für Java braucht, Jess basiert in den Ideen auf dem Kern von CLIPS, welches ja nun schon seit einiger Zeit existiert (so Mitte der 80er), integriert aber eben in die Java-Welt. Eine Alternative wäre da auch noch Hamurabi, einer in Scala geschriebenen Rules-Engine die mit einer integrierten DSL mit Scala-Sprachmitteln aufwartet.

Evolutie test. Evolutionärer Algorithmus in JavaScript mit Visualisierung in processing.js - gestartet wird mit einem zufälligen String, die Evolutionsfunktion ist die Edit-Distanz zum Zielstring und die Evolution ist halt das was dabei passiert - die Visualisierung zeigt die Streuung und die Konvergenz zum eingegebenen Zielstring.

Re: Factor: Mail with GUI. Schön zu sehen wie ein allgemeinerer Ansatz für GUIs den Code schön kompakt macht - das ganze erinnert mich sehr stark an CLIM von der Struktur.

Re: Factor: XKCD. Wer einen Eindruck in eine der verrückteren Sprachen haben will - John Benediktssons Blog hat eine Menge an Beispielschnipseln in Factor, die üblicherweise direkt in der Factor REPL benutzt werden können (oder überschaubare Vokabularerweiterungen erstellen). Mich beeindruckt immer wieder die Kompaktheit von Factor-Code. Johns Code hat auch den Vorteil, das ich in der Regel gut verstehen kann, was da passiert - Slavas Code zum Beispiel ist da oft deutlich idiomatischer und dadurch kryptischer für mich. Liegt aber sicherlich auch daran, dass Slava in der Regel über Internas der Sprache schreibt, während John einfach kleine Spielereien beschreibt.

Akka Project. Und das hatte ich definitiv schon mal auf dem alten Blog, aber egal, im Fernsehen wird auch dauernd alles wiederholt. Und bei Akka hat sich ein Haufen getan in der letzten Zeit und es etabliert sich immer mehr als die zukünftige Plattform für ausfalltolerante Systeme auf der JVM. Viele Parallelitäten in den Ideen mit Erlang, aber eben mit der JVM-typischen breiteren Plattform (gibt einfach kaum was wofür es nicht irgendeine Klassenbibliothek für Java gibt und damit auch für Scala). Sehr interessant: Akka bringt eine Implementierung von Software Transactional Memory für die Java-Plattform.

Programming Scala. Hatte ich glaub ich schon mal, aber egal: das zweite online frei verfügbare Buch über Scala, über das ich heute gestolpert bin. Kann man ja auch gegenlesen mit dem anderen, ist aber auf ähnlichem Sprach-Stand (also vor 2.8).

ScalaQuery. Ja, Scala-Day heute. Eine der Sachen die mir bisher fehlten war eine gute Integration von Datenbanken, die von den DSL-Features und der Typsicherheit von Scala auch Gebrauch macht. Also nicht einfach nur per JDBC SQL durch die Gegend schicken, sondern sowas wie LINQ, nur eben für Scala. Das hier sieht schon recht nett aus.

Programming in Scala, First Edition. Und weil ich gerade Scala habe: die erste Auflage von Programming in Scala ist jetzt frei im Web verfügbar. Natürlich fehlt einiges das mit der aktuellen Scala-Version reingekommen ist (speziell die Container-Libraries sind ja doch anders in 2.8), aber um in die Sprache reinzulesen ist das trotzdem sicherlich ein guter Startpunkt.

Scala IDE for Eclipse. Hmm, so langsam scheinen die Werkzeuge sich dort zu entwickeln. Ich habe ja grundsätzlich nichts gegen Kommandozeilen und bin auf denen viel mehr zu Hause als in IDEs, aber für die allgemeine Akzeptanz von Sprachen sind IDEs dann doch recht praktisch. Und Scala ist immer noch eine der interessanteren Sprachen im JVM Umfeld, auch wenn es in der letzten Zeit recht ruhig darum geworden ist.

agronholm / jython-swingutils. Noch keine Idee was ich damit machen könnte, aber falls mal die Java-Welt interessant ist, könnte das als GUI Bibliothek interessant werden (Swing für Jython).

Code rant: Message Queue Shootout!. Kein echter Shootout und nur eine unvollständige Auswahl an Messagequeues. Aber trotzdem was interessantes als Ergebnis: wenn man Knoten hat, die schon eigene Persistenz und Transaktionslösungen haben, zwischen denen man nur maximal schnell Nachrichten schicken will - es gibt dann nichts besseres als ZeroMQ. Es ist - bedingt durch seine Architektur - schlichtweg die schnellste Lösung. Und wir reden hier von wirklich drastischen Unterschieden.

NOSQL Databases. Sehr gute Übersicht über alle möglichen verfügbaren NoSQL-Datenbanken. Guter Startpunkt wenn man sich über die verfügbaren Systeme und deren Ausrichtung und Implementierung infomieren will.

visionmedia/asset. Nachdem ich schon pip (für Python Module) und jip (für Java-Libraries) hatte, hier ein analoges Werkzeug für JavaScript Bibliotheken. Also zur automatischen Installation von JavaScript-Libraries in node.js Projektverzeichnisse von der Kommandozeile aus.

jRumble | A jQuery Plugin That Rumbles Elements. Das neue Blink-Tag! (okok, gibt durchaus sinnvolle Anwendungen, z.B. wenn man ein Element auf der Webseite kurz anzeigen lassen will, dass dort was passiert ist - analog zu hüpfenden Icons im OSX Dock).

Python Package Index : pip 1.0. Der Vollständigkeit halber hier geblogmarkt, auch wenn pip für mich mitlerweile eh fester Bestandteil der Python Infrastruktur ist. Aber vielleicht hat der eine oder andere ja noch nicht mit pip rumgespielt, dann ist jetzt wohl der richtige Zeitpunkt gekommen. Man sollte es meiner Meinung nach immer zusammen mit virtualenv benutzen, denn dann kann man einfach für jedes Projekt genau die passenden Abhängigkeiten installieren und sauber von anderen Projekten trennen.

sunng87/jip. Im Moment mache ich nicht so viel mit Jython, aber jip klingt sehr praktisch: es ist ein Analog zu pip, aber für Java-Libraries. Also ein einfaches Kommandotool, welches die notwendigen Jar-Files runterlädt und an den richtigen Ort packt. Integriert mit virtualenv. Für mich deutlich angenehmer als zum Beispiel mit Maven oder ähnlichen Java-üblichen Infrastrukturtools rumzumachen.

Exploring Beautiful Languages: A quick look at APL. Einfach weil mich APL immer begeistert hat. Auch wenn ich nach eigenen Erfahrungen damit nie in die Verlegenheit geraten will, ein APL Programm warten zu müssen - für mich ist APL das Musterbeispiel für write-only Sprachen.

How I learned to stop worrying and write my own ORM. Ein bischen Hintergrundinformation warum Dapper entwickelt wurde und welche Problemfälle es löst - im Prinzip wird es dort eingesetzt, wo bisher aus Performancegründen direkte SQL Zugriffe über Linq "getunnelt" benutzt wurden, weil Linq2Sql dort ineffizient ist.

dapper-dot-net - Simple SQL object mapper for SQL Server. Könnte eventuell ja ganz interessant auf der Arbeit sein. C# bietet ja auch Linq an, aber nach deren Messungen scheint Dapper deutlich auf Performance getrimmt zu sein.

philikon / python-weave client ist fast noch interessanter als das andere Tool: eine Python-Bibliothek zum Zugriff auf Mozilla Sync. Damit könnte ich mir diverse kleine Tools bauen, die Links automatisch in Bookmarks einmischen oder aus dem Sync rausholen und in andere Bookmarkdateien reinwandern lassen. Oder wie wäre es mit einem Cronjob, der aus den Bookmarks aus einer speziellen Gruppe Links rausnimmt und automatisch ins Weblog postet? Lauter lustige Spielereien sind möglich ...

philikon / weaveclient-chromium. Noch nicht ausprobiert, es ist eine Chrome-Erweiterung die Mozilla Sync in Chrome und Chromium integriert. Damit könnte man endlich die Bookmarks zwischen Chrome und Firefox austauschen ohne über XMarks gehen zu müssen. Wenn jetzt noch jemand diese Extension auch für Safari baut, wäre ich glücklich - die Tatsache, dass ich zwischen den Browsern nicht vernünftig syncen kann, sondern jeder sein eigenes Süppchen kocht, ist hochgradig nervig. Mozilla Sync ist frei zur Nutzung und dahinter steht ein Laden, dem ich in dem Bereich deutlich mehr traue als allen anderen.

Pipe ist ein Modul mit infix-Syntax für verkettete Funktionsaufrufe über potentiell lazy streams (intern sind das Generatoren). Im Gegensatz zu stream (hatte ich hier schon mal) ist es ohne Unterstützung von Parallelität, also einfach nur syntaktischer Zucker. Mir gefällt allerdings der von stream besser (also der Zucker) und die Parallelität von stream ist auch interessanter als nur eine etwas andere Syntax zu liefern.

markrendle/Simple.Data - GitHub. Sollte ich mir mal angucken, sieht ganz interessant aus - ein ORM für .NET.

Basho: An Introduction to Riak. Müsste ich mir auch mal genauer angucken, hat eine recht saubere und einfache Architektur und alle Knoten im System sind gleichwertig (das ist ähnlich zu Cassandra). Das ganze ist hier in Erlang geschrieben, aber interessant ist die MapReduce-Schnittstelle: Funktionen können als JavaScript Code reingeliefert werden und die Kommunikation geht über ein simples JSON Interface.

HBase vs Cassandra: why we moved « Dominic Williams. Nicht ganz uninteressanter Blog-Post, der einen Vergleich von Hadoop/HBase mit Cassandra wagt und die verschiedenen Schwerpunkte herauszuarbeiten versucht. Sein Fazit: HBase ist mehr für Warehousing, Cassandra mehr für Transaction-Processing. Allein dadurch wäre sowas wie Brix noch viel interessanter, wenn es diese beiden Aspekte wirklich vereinen kann.