Am Rande notiert ...

myabc/markdownj muss ich mir mal angucken, denn JMD ist irgendwie doch etwas buggy und der Developer macht damit nichts mehr. Das hier ist ein Port der originalen Perl-Sourcen, benutzt also massiv Regular Expressions, aber das sollte bei meiner Programmstruktur von UniversalBrain nicht wirklich große Probleme machen, denn ich cache ja den HTML Output. Vielleicht verhält es sich ja besser als JMD. Wobei natürlich die Frage ist, ob es vernünftig als Library eingebunden werden kann.

mitotic/otrace. Interessanter alternativer Python Debugger der auf das Debugging und Tracing von multithreading Anwendungen ausgelegt ist. Dabei geht es also weniger um das sequentielle steppen durch den Python Code sondern mehr darum, eine sich dynamisch durch Threads verändernde Umgebung zu analysieren (da ist der normale Python Debugger ja doch etwas sperrig).

cletus/jmd. Da PegDown nicht auf Android läuft, weil der zugrundeliegende Parser gerne eine dynamische Parserklasse generieren will, was da nicht erlaubt ist, mal das hier angucken. Soll auch recht vollständig sein, basiert auf dem Markdown# Projekt für C#.

mitmel/SimpleContentProvider. Sieht aus wie ein einfacher ORM der automatisch einen Android Content Provider generiert. Dadurch wird das Erstellen deutlich schlanker im Code.

sattvik/neko. Auch mal vorgemerkt für später, Clojure für die Programmierung von Android Anwendungen mit ein paar Bindings für die Android APIs. Wobei da natürlich die Frage ist, ob die das Startup-Problem in den Griff bekommen haben, oder ob das immer noch den Einsatz von Clojure limitiert.

ActionBarSherlock – Home. For later use: damit kann man die ActionBar auch auf älteren Android Versionen im Code benutzen, es wird automatisch ein Backport benutzt wenn keine native ActionBar verfügbar ist.

sirthias/pegdown. Interessante Markdown-Implementierung in Java, basierend auf einem echten Parser und nicht den sonst oft so üblichen Adhoc-Parsern oder Regex-Sammlungen. Könnte ein interessanter Startpunkt für mich sein, zumal es auch als Idea Projekt daher kommt und ich es daher recht leicht integrieren können müsste.

n8han/giter8. Und noch ein praktisches Tool, diesmal nicht zwingend Scala-bezogen, aber sehr praktisch: auf github abgelegte Templates werden benutzt um Projektstrukturen anzulegen. Es gibt da dann auch ein Template für Android-Projekte die Scala verwenden.

Getting started · jberkel/android-plugin Wiki. Und hier das zentrale Element zur Scala-Programmierung für Android. Damit werden diverse sbt Befehle zur Verfügung gestellt, die sich um die Android-Integration und Delivery kümmern.

mpeltonen/sbt-idea. Hmm, interessant – ein sbt Plugin mit dem man Idea Projektstrukturen generiert. Damit kann man dann an den Stellen wo man die IDE benutzen will sie auf das gleiche Projekt loslassen. Zum Beispiel für die Remote-Debug-Einbindung ist die IDE dann doch recht nett.

Android-Programmierung mit Scala. Etwas gestelzte Sprache, aber dafür brauchbarer Inhalt. Der Artikel gibt einen netten Überblick darüber, was man gewinnt wenn man Scala für die Android-Programmierung einsetzt. Ich muss mir das ganze auch noch mal genauer angucken, denn die Tipperei bei Java geht mir manchmal dann doch ein wenig auf den Keks. Ausserdem klingt ein Workflow aus sbt und normalem Editor deutlich schlanker als die diversen Java IDE Umgebungen. Und einige Sprachfeatures von Scala schreien geradezu danach im Android Umfeld eingesetzt zu werden (vor allem Traits).

OrmLite – Lightweight Object Relational Mapping ORM Java Package. Mal genauer angucken, ein ORM der auch in Android benutzbar ist. Die nackte Programmierung von SQLite mit SQLiteDatabaseHelper macht mir irgendwie nicht so richtig viel Spaß. Das ist mir dann doch etwas zu low-level.

Create a package for Android for Kivy. Ich glaub ich muss mir Kivy nochmal genauer angucken. Sie arbeiten jetzt mit Python for Android, einer eigenen Python-Distribution die einen angepassten Interpreter für Android mitbringt und eine Koppelung über Cython, NDK und JNI an die Android-SDK. Damit kann man also richtige APKs produzieren, die ganz normal auf den Devices installiert werden können – aber alles was die Anwendung selber ausmacht in Python schreiben. Bleibt natürlich die Frage wie schnell das dann läuft – Python wird ja nunmal interpretiert. Aber interessant für Tools wäre es allemal, zumal man Kivy Anwendungen auch mehr oder weniger direkt unter Desktopsystemen laufen lassen kann.

Plop: Low-overhead profiling for Python. Das muss ich mir mal genauer angucken, könnte sehr interessant für die Server in der Firma sein, besonders der geringe Profiling-Overhead von nur 2% klingt spannend. Und die Visualisierung ist definitiv eine der besseren bei Profilern für Python.

Custom Drawn Interface/Android – Lazarus wiki. Hah, es gibt auch für Freepascal und Lazarus (die FP IDE mit Delphi-Einschlag) einiges zur Programmierung von Android Apps. Ist alles wohl noch etwas wackelig und hackig, aber macht Fortschritte. Die Idee ist ganz witzig – eine minimale Java-App mit minimaler Activity und dann über JNI die Integration von Pascal Code. Die Idee ist dort wieder die LCL – also die GUI Library von Lazarus – weiternutzen zu können, so dass man systemübergreifend programmieren kann. Und man kann dann auch den eingebauten GUI Builder benutzen.

Basic4android Basic for Android – Rapid Application Development. Heh, nett, eine Art Visual Basic für Android. Leider nur für Windows. Schade.

Android – Processing. Oh, das ist interessant. Die neueste Processing 2.0 Alpha können auch direkt Android unterstützen – und zwar richtig simpel, einfach eine Processing App schreiben, umstellen auf Android und mit „Run on device“ das ganze aufs Device bringen und dort starten. So für die typischen kleinen Hacks klingt das richtig interessant, besonders wenn man mit Grafik rumspielen will (das ist ja der Fokus von Processing).

necessitas / Home / necessitas. Hmm, klingt ganz interessant – eine QT Version für Android inklusive einer IDE zur Programmierung von Apps. Vielleicht guck ich mir das dann auch mal an, wenn mein Nexus da ist.

Ymacs — An Emacs-like editor for the Web. Was der Titel sagt. Emacs bootet jetzt auch im Browser. Einen brauchbaren Editor gibts für Emacs aber immer noch nicht.

OscarGodson/EpicEditor. Das klingt interessant – ein Editor fürs Web der nicht einfach HTML produziert, sondern Markdown. Könnte für einige Projekte interessant werden.

Repo.js. Darüber hab ich die Source-Highlighter gefunden – ein kleines jQuery Plugin, welches auf einfache Weise ein github Repository in eine Webseite einbettet. Ganz praktisch, wenn man seine Projekte in eigenen Webseiten einbinden will und nicht die ganze Website an github abtreten will.

isagalaev/highlight.js. Gerade drüber gestolpert, kleiner Source Highlighter in JavaScript der mit einer Sprachheuristik arbeitet und so keine expliziten Angaben der zu färbenden Sprache braucht – er versucht einfach alle Sprachen durch und nimmt die mit den meisten erkannten syntaktischen Elementen. Mit jQuery VanGogh gibt es dafür auch noch ein jQuery Plugin.

ErlPort – Erlang port protocol for Python. Ein etwas anderer Ansatz für verteilte Kommunikation ist dieses Modul bei dem einfach die Erlang-Bordmittel für Kommunikation (Ports und Terms) implementiert werden. Damit kann man Systeme bauen die je nach Bedarf Python oder Erlang als Implementierungssprache verwenden.

Hurricane. Klingt interessant, ist ein verteiltes Messaging System das mit verschiedensten Sprachen arbeitet und damit Integration von verschiedenen Systemen biete. Unter anderem dabei is Python mit WSGI und Ruby mit Rails, wodurch z.B. ein verteiltes System auf Basis von Rails und Django denkbar ist. Zusätzlich gibt es noch einen Prozessmanager, mit dem die Prozesse selber nur Standard-IO machen können müssen und dann direkt von Hurricane gemanaged werden. Könnte ich mir gut für das eine oder andere Projekt in der Firma vorstellen.

SQLite4: The Design Of SQLite4. Das klingt sehr interessant. Besonders der erste Absatz in „2.0 Overview“, in dem er ein wenig darauf rumreitet, dass SQLite3 weiter unterstützt wird und beide Versionen parallel verfügbar bleiben. Und natürlich dann die diversen Änderungen, die SQLite4 gegenüber der anderen Version haben wird, wie zum Beispiel die deutlich bessere Kapselung der Engine in einem eigenen Objekt. Dadurch ist es durchaus möglich mehrere Datenbanken gleichzeitig offen zu haben, ohne großes jonglieren. Und was mich besonders freut: alle Berechnungen in Decimal Math und nicht mehr double oder float. Sorry, aber double (und schon gar nicht float) hat irgendwas in einer Datenbank zu suchen, ausser vielleicht als Datentyp für seltene Sonderfälle. Auch sonst einige nette Sachen drin, zum Beispiel covering indexes und natürlich die standardmäßig verfügbaren foreign key constraints.

Jarvis. Da bastelt jemand an sowas wie Light Table für Python (Light Table hat auch Python Support versprochen, aber bisher gibts da nur eine Preview für Clojure). Sieht ganz interessant aus und bringt endlich mal wieder frischen Wind in interaktive Umgebungen für Programmiersprachen.

Remote Debugging – Real Software Documentation. Davon sollten sich andere Systeme ein paar Scheiben abschneiden. Bei meinem Spielprojekt hatte ich in der neuesten Version ein Problem unter Linux. Meine Entwicklungsumgebung ist aber OSX. Da läuft alles tadellos. Also was tun? Nunja, gute Gelegenheit sich mal den Remote-Debugger anzugucken. Und der ist wirklich trivial. Ein Linux hochfahren (ich benutze dazu Vagrant auf meinem OSX Rechner), das Remote Debugger Stub rüberkopiere, ausführen, minimal konfigurieren und loslegen. Direkt aus der OSX IDE den kompilierten Code auf die Remote Umgebung übertragen und starten, direkt mit Breakpoints und Variablenwatch und solchen Sachen. Eben all das, was ich auch mit OSX lokal hätte. Im Prinzip gibt es nahezu keinen Unterschied, ausser das halt das Programm im Linux läuft. Warum ist das bei so vielen anderen Umgebungen so viel komplizierter? Ich werd wohl langsam alt, ich hab einfach keine Geduld für umständliche Umgebungen mehr.

..Nowhere... hat eine Reihe von freien Klassen und Plugins für RealBasic, unter anderem eine für einen syntaxfärbenden Editor und Listboxen mit beliebigem Zelleninhalt.

The Opa blog: Announcing Opa 1.0. Opa erzeugt jetzt keinen Native Code fürs eigene Backend mehr, sondern erzeugt JavaScript für Node.js Integration. Klingt durchaus interessant, durch die Integration von Node.js könnte da auf Dauer auch Zugriff auf die dort verfügbaren Libaries Einzug halten (wobei man dann natürlich die garantierten Eigenschaften von Opa verliert). Und zusätzlich sind jetzt auch die Chancen höher, dass man einen geeigneten Hoster findet bzw. das Selbsthosting könnte dadurch auch angenehmer werden.

Make runfcgi fail when database connection is open before fork. Das ist eine Sache nach der ich schon ewige Zeiten jage, zuletzt in ein paar ziemlich wichtigen Projekten. Flup arbeitet so, dass es die WSGI-Anwendung erst initialisiert und mit dieser initialisierten WSGI Anwendung dann die Forks für die Worker macht. Dummerweise gibt es bei uns aber Datenbankzugriffe wärend der Anwendungsinitialisierung – dadurch hat der Basisprozess schon eine offene Datenbankverbindung, jeder Fork kopiert diese Daten. Aber der Socket der Verbindung geht natürlich nicht mit – der neue Prozess denkt nur er wäre verbunden, ist es aber nicht. Zugriffe von denen neuen Prozessen fallen dann mit einer Exception raus. Man kann im verlinkten Patch auch gut den raise auf die Exception einfach durch connection.connection = None ersetzen. Dann wird einfach die Verbindung die sowieso defekt ist weggeworfen und in neuen Prozessen immer eine neue Verbindung aufgebaut. Damit haben wir zumindestens in einem Produktionsumfeld (mit psycopg2) das ganze beheben können und sind guten Mutes, dass es auch bei der Umgebung  mit pyodbc helfen wird.