Fossil: Fossil Home Page - der Autor von SQLite, meinem bevorzugten Werkzeug für alles was Daten lokal speichern muss, hat auch ein eigenes verteiltes Versionierungssystem (ala Mercurial oder Git) gebaut. Und es hat gleich noch ein integriertes, verteiltes Wiki und ein integriertes, verteiltes Bugtracking mit dabei. Das ganze basiert natürlich auf SQLite als Backend zur Speicherung der Daten und hat einige interessante Eigenschaften. Durchaus mal wert anzugucken, zumal seine Installation nahezu perfekt ist: einfach ein fertiges Executable in den Pfad kopieren, das wars schon. Yep, Versionierung, Wiki, Bugtracking, CGI für Weboberfläche - alles in einem einzigen Executable. Kompakt ist es auch noch. Beeindruckend.
programmierung - 28.2.2010 - 30.5.2010
ikiwiki - und weil ich gerade mal wieder bei bare-bones Projekten bin: ikiwiki könnte recht interessant sein, es nennt sich selber "Wiki Compiler". Im Prinzip einfach ein Haufen Wiki-Seiten in Textfiles, verwaltet mit einem Versionierungssystem und einem Tool, welches automatisch statisches HTML produziert. Dazu noch eine Reihe von Plugins, mit denen man diverse Erweiterungen vornehmen kann (unter anderem erlaubt es Markdown und auch reStructured Text als Wikisprache und hat Blogging Plugins).
daemon 1.0 - der erste der üblichen Verdächtigen für Unix-Daemonen mit Python.
pyquery: a jquery-like library for python - unbedingt mal angucken, denn das ist etwas das mich schon die ganze Zeit nervt, die Libraries zum Zugriff auf XML-Daten in Python sind etwas primitiv. Und jQuery mag ich sehr, dessen Zugriffsmuster find ich einfach ausgesprochen praktikabel.
python-daemon 1.5.5 - und der zweite der üblichen Verdächtigen (der hier ist schon fast sowas wie offiziell, zumindestens orientiert er sich an einem PEP) zum Schreiben von Unix-Daemonen mit Python.
Spring Python - keine Ahnung was es wert ist, ich hab bisher Spring unter Java nicht benutzt (naja, benutze ja Java sowieso eigentlich nie, höchstens mal die JVM), aber man liest ne Menge positive Kommentare über Spring. Hier hat jemand die Ideen nach Python übertragen - gibt sogar ein Buch darüber. Ich weiss allerdings nicht, ob ein Framework für eine bondage-and-discipline Sprache sich so gut auf eine hoch-dynamische Sprache wie Python portiert. Könnte man sich in einer ruhigen Stunde aber mal angucken.
Turkmenbashi 1.0.0 - eine Library um Unix-Daemonen zu schreiben. Bringt ein paar mehr Features mit als die anderen üblichen Verdächtigen (daemon und python-daemon).
Clojure - datatypes - was mir an Clojure so gefällt: pragmatische und kompakte Lösungen für typische Probleme in der Programmierung. Clojure 1.2 wird die Möglichkeit einführen, bessere Beschreibungen von Datenstrukturen mit darauf definierten Funktionalitäten zu haben. Und zwar keine Monsterkonstruktion wie CLOS oder andere Lisp-OO-Erweiterungen, sondern recht schlanke Konstrukte die auch wieder gut auf die Hostumgebungen (JVM und CLR) passen. Schaut schon ganz interessant aus. Der Nachteil von all den Veränderungen in Clojure: Bücher sind schneller veraltet als sie gedruckt werden können ...
Rubinius : Use Ruby™ - bin zwar nicht der große Ruby-Fan, aber von Rubinius (Ruby-in-mostly-Ruby) ist als 1.0 Version raus. Und die verschiedenen Projekte, Ruby auf eine größtenteils in Ruby gebaute Plattform mit LLVM unten drunter zu bringen, macht mich immer noch neidisch. Ich hätte sowas gerne für Python ... (ja, ich kenne Unladen Swallow und PyPy - aber beide sind noch meilenweit von einer ernstzunehmenden Version entfernt, leider)
Street View: Google belauschte offene WLANs - genau da steckt ja das Problem mit Streetview. Nicht in den reinen Fotos. Sondern in dem gesamten Programm - die Integration verschiedenster Sachen in einem großangelegtem Scan. Die Kombination mit den ganzen Datenbanken, die Google schon hat. Die Zusammenführung verschiedenster Informationsquellen, rein aus der Geek-Sicht als "boah, ey, watt haben wir da an Klamotten, jetzt holen wir doch mal alles raus was geht". Oder anders formuliert: überlegt euch einfach mal, die Autos würden nicht Google gehören, sondern dem Staat. Und das Programm, die Datenbanken und die Informationssammelwut wäre nicht ein Unternehmen in Amerika, sondern eben unser Staat. Würde euch die Ansammlung von Informationen und Daten dann genauso gefallen wie Streetview? Wärs der Staat, gäbe es wenigstens den Anschein einer demokratischen Kontrolle dieser gigantischen Datenbank.
alienscience's leiningen-war - interessantes Plugin für Leiningen, das Build-Tool in und für Clojure. Liefert Kommandos die schnell und unkompliziert .war Files erzeugen, die z.B. für Deployment auf die Google App Engine genutzt werden können.
hiredman's lein-gae - Dokumentation im Prinzip nicht existent, aber es liefert ja auch nur ein einfaches Kommando, welches einem die war-Struktur für ein Google AppEngine Projekt vorbereitet und das project.clj anpasst. Eine weitere Möglichkeit, mit Clojure Programme für die AppEngine zu bauen.
Licenser's lein-search - und ein kleines Plugin, das die Suche nach Modulen und deren Versionen auf die (Leiningen) Kommandozeile holt.
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.