programmierung - 12.2.2010 - 12.5.2010

sethtrain's beget - oder alternativ zu leiningen-war könnte man auch dieses Basisprojekt benutzen und einfach anpassen. Da werden auch gleich die Google AppEngine Tools als Dependency geholt.

Marak's JSLINQ at master - GitHub - nette kleine JavaScript Bibliothek, die eine Query-Sprache für JSON Daten bietet. Orientiert sich an LINQ von Microsoft, hat aber derzeit nur einfache Queries implementiert. Trotzdem vielleicht ganz interessant um JavaScript Code flexibler und besser lesbar zu gestalten, wenn mit größeren JSON Datenmengen gearbeitet wird.

parsedatetime - sehr praktische Library, die "normale" Datumsangaben (leider nur in Englisch soweit ich sehe) in Python datetime Objekte umsetzt.

PyPy Status Blog: Running wxPython on top of pypy - PyPy macht wirklich riesen Schritte in Richtung brauchbar. Schneller als CPython ist es schon in einigen Fällen und jetzt laufen auch größere C-Erweiterungen wie wxPython. Cool.

Zoolander - eine kleine Python-Library, mit der man Python als DSL für die Erzeugung von CSS benutzen kann. Klingt erstmal unsinnig, aber wenn man CSS dynamisch produzieren will oder muss, und das ganze dann in ein Webframework einbettet, kann es ganz praktisch sein.

The Brads – How to Alienate a Fanbase - falls jemand eine kurze Zusammenfassung braucht, wofür Adobe steht.

Thoughts on Flash - wird natürlich wieder von allen Apple-Gegnern als Blabla hingestellt, aber nunja - die Gründe sind schlüssig. Und sorry, aber es ist wirklich so: Flash stinkt.

django-pagination - muss ich mir mal genauer angucken, sieht interessant aus. Pagination ist zwar nicht wirklich schwierig, aber lästig jedesmal selber zu bauen - und die bordeigenen Mittel von Django sind nicht immer optimal dafür (besonders bei großen Datenmengen).

Henry's EuLisp - da hat jemand EuLisp wiederbelebt und die Sourcen zusammengetragen, sowie die Spezifikation. Mindestens historisch interessant, denn EuLisp war eine der Standardbemühungen für ein moderneres Lisp mit recht guten objektorientierter Unterstützung. Aber auch die Implementierung selber hat einige interessante Features.

jcotton - Animationen und Grafiken mit JavaScript und Canvas bauen. Sieht ganz interessant aus.

XML in Postgres – The Game Changer « Flex and Specs() - ich sollte wirklich mal mehr die neuen PostgreSQL Features angucken. Speziell weil die XML-Unterstützung in PostgreSQL einige der Vorteile von dokumentenorientierten Datenbanken auf die relationale Welt rüberbringen, ohne dass man dazu extra Middleware braucht.

Archives of the Caml Mailing list: O'Caml for DOS - weil ich gerade mal wieder drüber gestolpert bin. Wow, 96, das ist lange her. Wieso wird OCaml eigentlich immer als so moderne Sprache aufgeführt? Ist doch auch schon 14 Jahre alt ... (und die Sprache auf der OCaml aufsetzt - Caml Light - ist noch älter)

Daring Fireball: New iPhone Developer Agreement Bans the Use of Adobe's Flash-to-iPhone Compiler - tja, natürlich hat Apple das Recht die Bedingungen selber zu setzen. Und ich hab das Recht, die Programmierung für das iPhone jetzt völlig uninteressant zu finden - sorry, aber solche Low-Level-Programmiersprachen tu ich mir nicht mehr an.

django-ajax-filtered-fields - muss ich mir mal näher angucken, das könnte im Admin ganz interessant sein bei größeren Mengen an Sätzen in Relationen.

My experience with using MongoDB for great science. - NoSQL ist halt in vielen Fällen Spielwiese für Leute die mal ausprobieren wie Datenbanken eigentlich funktionieren. Bei vielen dieser Projekte frag ich schon was die eigentlich geritten hat als sie das gebaut haben. Ich bau dann doch lieber auf soliden und erprobten Werkzeugen wie PostgreSQL und SQLite auf. Und wenn eine NoSQL-Datenbank, dann besser eine, die schon längere Zeit produktiv in größeren Installationen im Einsatz ist. Cassandra kommt einem da in den Sinn zum Beispiel.

twitter's gizzard - könnte mal interessant werden, ein Framework zur Verteilung und Replikation von Daten über verschiedenste Backends. Gizzard kümmert sich ausschließlich um das Sharding und die Replication, der Datestore selber wird davon losgelöst behandelt, ist daher für verschiedenste Szenarien interessant.

Writing a non-relational Django backend - Django nonrel / NoSQL blog - All buttons pressed - bin ja nicht so der Fan von NoSQL (meiner Meinung nach spiegeln viele NoSQL-Ansätze eher das Unverständnis von relationalen Datenbanken wieder als tatsächliche Mängel oder Schwächen der relationalen Datenbanken), aber wenn schon NoSQL, dann doch am liebsten über den Django-ORM, denn den kann ich ganz gut leiden. Und hier wird gezeigt, wie man mit relativ geringem Aufwand einen Django-ORM-Wrapper für NoSQL-Datenbanken bauen kann.

Perfection kills » What’s wrong with extending the DOM - weil ich immer wieder mal mit Kollegen diskutiere warum JQuery besser als Prototype: Prototype benutzt massiv die Erweiterung von Prototypen, wärend JQuery fast alles an seinem eigenen JQuery Objekt aufhängt und daher viel kooperativer im Zusammenspiel mit anderem JavaScript ist.

Oracle Announces Latest Release of Oracle® Berkeley DB - Berkeley DB hat jetzt ein auf SQLite aufbauendes SQL API. Kompatibilität auf Sourcecode-Ebene mit SQLite, Programmierer können also - wenn sie den deutlich instabileren und anfälligeren Storage von Berkeley DB bevorzugen und gerne mal ihre Datenbanken reparieren wollen - wechseln. Sorry, Oracle, aber das ist affig. BDB ist eigentlich nur noch für die interessant, die gezwungenermaßen damit arbeiten müssen - wer heute noch auf BDB wechseln will, müsste mit dem Nagelbeutel gepudert sein. Wenn ich sowieso gegen das SQLite API programmiere, dann nehme ich lieber gleich das richtige Tool. Ja, klar, SQLite hat einige Engpässe wenn man mit mehreren Prozessen parallel zugreifen will. Aber ich verrate Oracle hier mal ein kleines Geheimnis: SQLite hat einen so toleranten SQL Parser, weil man dann damit problemlos Source schreiben kann, dessen SQL sowohl gegen SQLite als auch gegen PostgreSQL funktioniert. Wenn man also an die Grenzen von SQLite stößt - einfach auf PostgreSQL wechseln und gut ist.

NLTK Home (Natural Language Toolkit) - und wenn es etwas leistungsfähiger und flexibler werden soll, das hier ist sozusagen der Bauchladen für Parser. Fokus liegt auf der Analyse natürlicher Sprachen, daher auch so Sachen wie Stemmer (Stammfindung für Wortformen) enthalten. Könnte aber für einfache eingebettete Sprachen dann doch eher Overkill sein.

Python Package Index : Esrapy 0.5 - ein Parser und Lexer Toolkit komplett in Python. Könnte später mal interessant werden in einigen Projekten, zumindestens für kleinere Konfigurationssprachen.

Building Skills in Python - Online-Buch über Python für Programmierer, die einfach die Sprache noch nicht kennen. Sieht sehr gut gemacht aus, auf den ersten Blick.

Bottle: Python Web Framework - super-simples Python-Web-Framework das als ein einzelnes Python-File daherkommt. Keine Abhängigkeiten außer von der Standardbibliothek. Kein integrierter ORM, aber dafür sehr schlank und vielleicht gerade für Projekte interessant bei denen man eh keine Datenbank braucht oder will (oder das Dateisystem als Datenbank benutzt).

clojure-python - interessantes Projekt das die Interoperabilität zwischen Jython und Clojure vereinfachen will und auf einen ähnlichen Level heben will, wie sie zwischen Clojure und Java schon ist. Besonders interessant für mich, weil es mir dann erlauben würde, stärker auf Clojure als Alternative zu setzen - Jython ist schon geplanter Baustein der Werkzeugkiste, hat aber einige Performance-Probleme die Clojure durch direktere Java-Integration nicht hat. Ausserdem schreib ich lieber kompakten Lisp-Code als geschwätziges Java ...

hugoduncan's clj-ssh at master - GitHub - ziemlich interessante Bibliothek, die ssh-Zugriff in Clojure-Scripten ermöglicht. Zum Beispiel für Serverautomation sehr interessant. Benutzt Jsch, eine Java-native ssh-Bibliothek (also kein Umweg über shell-pipes oder ähnliches).

Scala: Post-Functional, Post-Modern, or Just Perl++? - interessanter Post der einige der Punkte aufgreift die mich auch bei der Betrachtung von Scala stören. Ich mag besonders die Bezeichnung als Perl++, denn das ist genau der Eindruck der sich mir aufdrängt immer wenn ich in Scala tiefer einstiege. Auch Perl hat mich immer fasziniert, aber spätestens als ich größere Projekte damit gebaut habe und die advanced Features von Perl intensiver benutzt habe, kamen mir dann doch so einige Zweifel über die Wartbarkeit des Ergebnisses - ganz besonders unter dem Aspekt die Arbeit einem meiner Kollegen zu übergeben für die weitere Betreuung. Damals habe ich den Wechsel zu Python durchgezogen, weil es mir viele der Features in einem wesentlich saubereren Sprachkonzept geboten hat. Ich glaube das könnte auch erklären warum ich mit Scala einfach nicht warm werde, auch wenn vieles davon mich fasziniert.

digg's lazyboy at master - GitHub - weil key-value-datastores im Moment total der Hype sind (und weil sie wirklich für manche Sachen praktischer sind als klassische Datenbanken), werd ich mir wohl Cassandra angucken. Einfach weil es nach Berichten im Web die besten Skalierungsmöglichkeiten bietet. Und weil es in einigen großen Websites im Einsatz ist - speziell zum Beispiel bei Digg (das ich als Site zwar doof finde, aber hey, die haben ordentlich traffic und laufen relativ stabil) mit lazyboy als Python-Anbindung.

17.6. multiprocessing - viel besser als externe module für Prozess-Kommunikation sind die seit Python 2.6 mitgelieferten Tools in multiprocessing.

rfc1437 / lazypy / source — bitbucket.org - und noch ein Projekt von mir (wieder) online. Lazypy ist eine kleine Bibliothek die lazy evaluation und futures (thread und process basiert) für Python verfügbar macht. Sehr praktisch für die einfache Programmierung von Nebenläufigkeit. Ok, man kann alles auch von Hand machen, aber ich mag halt den etwas funktionaleren Ansatz lieber. Ist eigentlich aus 2004, aber ich habs mal modernisiert (die prozess-basierten Futures zur Umgehung des GIL) und neu hochgeladen.

Semanchuk.com - Python IPC Modules - inter-prozess-Kommunikation mit Python.

A simple web application in Clojure using ring and enlive « LShift Ltd. - und hier ein kleines Beispiel, wie man mit ring und Clojure dann tatsächlich arbeitet. Sieht ganz interessant aus, könnte für mich besonders für Webservices in Clojure interessant sein.

Dynamic Web Development with Seaside - wer mal mit Seaside loslegen will, findet hier vielleicht den Ansatz dazu. Freies Online-Buch (gibts auch als kostenpflichtiges PDF oder print-on-demand über Lulu) über ein ziemlich beeindruckendes Web-Framework für Smalltalk. Und da es mitlerweile auch mit GNU Smalltalk läuft, ist auch der Betrieb als headless Server auf einer eigenen Root-Kiste kein großes Problem mehr.

Heroku | Ruby Cloud Platform as a Service - auch ganz interessant: ein Ruby-Service der einfaches Website-Hosting in Ruby in einer Cloud-Struktur ermöglicht. Im Prinzip sowas wie Google App Engine, nur eben mit Ruby. Der Ansatz ist ganz interessant, man generiert eine Basis-App und holt sich die dann mit Git auf den eigenen Rechner, ändert und aktualisiert mit Git. Es gibt diverse Addons und Plugins die man nutzen kann, Rails wird natürlich auch unterstützt. Und da man seine App als normale Ruby-App lokal behält, ist man auch relativ unabhängig vom Anbieter und kann notfalls auf selbsthosting umsteigen.

inessential.com: On switching away from Core Data - scary read. Wirklich - klar, ORMs sind nett. Und praktisch. Aber irgendwie erschreckt es mich, wenn Programmierer wie Brent Simmons (der NetNewswire Guy) so offen demonstrieren, dass sie eigentlich keinen Plan haben was sie da tun. Nur weil man einen ORM benutzt durch Listen von Objekten wandern und einzelne Objekte bearbeiten und sich dann über miese Performance wundern? Und erst am Ende der Optimiersessions mal die Frage stellen, ob eine ORDB tatsächlich der richtige Weg ist? Hallo, gehts noch? Sobald Massendaten im Einsatz sind, steht automatisch die Frage nach Massendatenbehandlung im Raum und wenn der ORM da keine brauchbaren Abstraktionen liefert, dann fliegt er raus ... (ein Grund warum ich den Django-ORM mag, er kooperiert gut mit handgedengeltem SQL und bietet per Introspection eine Menge Hilfsmittel um auch diese eigenen SQLs möglichst Modell-abstrakt zu erstellen). Für mich liegt jedenfalls der verlinkte Post auf einem ähnlichen Level wie Guido van Rossums "wofür benutzt man denn eigentlich Continuations, ich kapier das nicht".

Johnny Cache v0.1 documentation - unbedingt mit einem Projekt in der Firma mal ausprobieren, denn das Modell ist ziemlich heftig und ich könnte damit ein paar der Probleme elegant lösen für die ich derzeit Sonderlösungen habe. Ist auch ziemlich ähnlich zu meinem ersten Ansatz für dieses Problem (allerdings habe ich die grössten Performance-Probleme jetzt durch redundante Datenhaltung und automatische Updates an Objekten ebenfalls recht elegant gelöst).

Kotka : Projects : Clojure : VimClojure - und wer wie ich ein VIM-Fan ist, wird sich vielleicht über diese Clojure-Einbettung freuen. Viele der Features kommen schon deutlich an die Leistungsklasse von IDEs wie Netbeans oder Eclipse heran. (obwohl die Clojure-Plugins für Eclipse und Netbeans auch eine sehr gute Figur machen).

LinuxTuples - ein Tuple-Space Server für Linux, in C geschrieben, aber mit Python-API. Sollte ich mir mal näher angucken, könnte interessant für verteilte Apps sein. Wobei ich ja lieber eine python-lokale Implementation auf Basis von Standard-Prozess-Kommunikationsmitteln hätte, um vernünftiger mit multiprocessing in Python arbeiten zu können. Gerade für einfache Tools oder Webapps wäre es einfacher manche Sachen direkt vom dort zu forken und dann über TupleSpaces zu kommunizieren. Aber dafür immer gleich einen extra Server zu starten, das ist es irgendwie auch nicht.

mmcgrana's ring at master - GitHub - nette kleine Lib auf dem Level von Python WSGI. Also absolut minimale HTTP-Bindings für Clojure mit der Möglichkeit das ganze über eine ganze Reihe von verschiedenen Techniken dann zu betreiben. Besonders interessant für die Fälle, wo man eben nicht in das Korsett eines fertigen Frameworks wie Compojure gesteckt werden möchte.

PiCloud | Cloud Computing. Simplified. - sehr interessanter Dienst: triviales verteilen von Python-Code (mit Zugriff auf C/C++ Bibliotheken für Numbercrunching und anderes, z.B. auch Bildbearbeitung, sogar eigene C/C++ Bibliotheken sind möglich) auf ein vom Anbieter gemanagetes EC2-Grid. Der Programmierer schreibt nur noch seinen Python-Code, testet lokal, wenn alles mit kleinen Sets gut läuft, Basisdaten hochladen, import, Funktionsaufruf und warten bis die Ergebnisse da sind - bezahlt wird nach Benutzungszeit. Durchaus mal im Auge behalten, falls mal größere Datenmengen durchzuwühlen sind - sowas kann durchaus günstiger sein als sich die nötigen Ressourcen selber bereitzuhalten.

rfc1437 / django-standalone / overview — bitbucket.org - da ich immer mal wieder auf bitbucket, github oder google code verweise, hier mal der Verweis auf ein eigenes kleines Paket das ich selber auf bitbucket jetzt habe: django-standalone. Entstanden weil ich für kleine Scripte und Tools immer mal wieder einen ORM brauchen könnte, aber ich dafür möglichst wenig Umstand haben will - nicht ein ganzes Django-Projekt aufsetzen, sondern einfach ein paar Modelle in meinem Script definieren und per Parameter die DB initialisieren und danach benutzen. Möglichst auch mit sqlite3. Mit der Lib hier geht das ganz wunderbar und ich kann mal wieder eines meiner Dauerprojekte - "schreibe einen simplen ORM für simple Scripte selber" - von der ToDo-Liste streichen.

dajaxproject.com - easy to use ajax library for django - sollte ich mir vielleicht mal angucken, das aktuelle Projekt wird unter Umständen recht viel Ajax benutzen und wenn man den Anteil JavaScript reduzieren kann wär das ja durchaus erstrebenswert.

Squeryl — Introduction - das müsste ich auch mal angucken, denn von den bisherigen Persistenz-Layern für Scala war ich nicht so begeistert. Und gerade für erste Experimente will ich eigentlich nicht gleich eine Webanwendung mit Lift bauen, sondern vielleicht einfach nur mal ein paar Tools die ich bisher anders gelöst habe mit Scala neu schreiben.

IronPython 2.0 and Jython 2.5 performance compared to Python 2.5 - word of warning: sowohl Jython als auch IronPython sind in vielen Situationen deutlich (und ich mein deutlich deutlich) langsamer als CPython. Der Overhead wird bei Jython bei sehr großen Datenstrukturen irgendwann besser als bei CPython, aber für normalen Einsatz siehts nicht so richtig toll aus.

IronPython hammers CPython when not mutating class attributes - weitere Informationen zu dem Performanceproblem. Hier bezogen auf IronPython - scheinbar sind Klassenvariablen unter Umständen problematisch, da darüber sich die Klassen selber ändern und dadurch Just-in-Time-Compiler Informationen verworfen werden müssen (wegen der recht statischen Struktur der VM sowohl bei der JVM als auch bei der CLI warscheinlich sehr ähnliches Problem), wodurch der JIT-Compiler dann alles neu durchnudeln muss und damit nicht nur Performance-Vorteile verloren gehen, sondern potentiell sogar kontraproduktiv sein können.

bpython interpreter - unbedingt mal in der Firma mit spielen, zu Hause machte diese alternative Python-Shell einen echt guten Eindruck. In einigen Punkten besser als ipython und das ist schon sehr gut (aber meiner Meinung nach zu sehr auf eigene Features ausgerichtet und weg von der Python-Philosophie, wärend bpython mehr pythonisch wirkt)

DreamPie: The Python shell you've always dreamed about! - eine weitere interessante alternative Python-Shell, diese hier als GTK Fenster. Das öffnet ganz neue Möglichkeiten, wie z.B. echte Popups als kleine grafische Fenster und direkter grafischer Output. Allerdings ist py-gtk für OS X noch eher wackelig (wie alles GTK-Zeugs derzeit, ist halt noch Alpha) und eigentlich habe ich lieber ähnliche Umgebungen unter OS X und Linux.

ZODB - a native object database for Python — ZODB v3.9.0 documentation - weil ichs immer wieder vergesse: die ZODB gibts auch standalone, ohne das Monster Zope oben drüber. Und bei direktem Zugriff von Python bietet ZODB einige sehr interessante Features. Immer noch eine der am weitesten ausgebauten echten Objekt-Datenbanken für Python (aber leider immer noch keine allgemeine Query-Language auf die Datenbank zur effizienteren Behandlung von Objektmengen).

django-piston - muss ich mir auch mal näher angucken, es soll gerade den Bau von Web-APIs mit Django erleichtern. Und einige meiner Firmenprojekte könnten davon profitieren.

Murky - netter kleiner GUI-Client für Mercurial für OS X. Sieht schon ganz brauchbar aus, man kann recht leicht sich durch die Historie eines Projektes navigieren, sich Differenzen anzeigen lassen etc. - geht natürlich auch alles mit der Shell, aber manchmal ist es schlicht simpler mit einerm GUI zu arbeiten.

Front Range Pythoneering: Realizing Jython 2.5 - da stehts weiter unten drin. Jython hat ein GIL als witziges Easteregg im future Modul (das mit dem zukünftige Sprachfeatures als "Beta" verfügbar gemacht werden). Also kein GIL, sondern nur ein Joke. Hätte mich auch anders stark verdutzt.