java

Forge - Slightly Magic. Für Magic-Einsteiger wie mich echt praktische Software. Man kann Decks zusammenstellen, fertige Decks benutzen, randomisierte Decks bekommen - und diese dann gegen eine AI spielen. Die AI soll nicht die stärkste sein, aber hey, ich bin da auch weit von entfernt. Das ganze ist Java und läuft tatsächlich auf Windows, OSX und Linux gleichermaßen. Nett um auch mal sein eigenes Deck einem Testflug zu unterziehen, besonders wenn man keine Magic-Spieler in der Nähe hat (oder die keine Lust haben die eigene kranke Kreation zu testen). Oh, und Open Source ist es auch.

heuermh/leap-motion-processing. Sehr interessant, weil ich damit mit meinem LeapMotion Controller mit Processing spielen kann - der Overhead damit was zustande zu bekommen ist deutlich niedriger als auf native Programme zu gehen. Ausserdem ist es Plattform-übergreifend.

mrzl/LeapMotionP5. Und noch eine Processing Library für Leap Motion. Die hier scheint etwas vollständiger zu sein, mit Gestures und so. Auch mal angucken.

Getting Started with Android Studio | Android Developers. Oh, Google sieht das Licht und bietet eine Alternative zu Eclipse als IDE für Android-Programmierung an. Und dann ausgerechnet IntelliJ, mit dem ich sowieso schon arbeite. Nett!

Java 3D Engine | Learn Java Programming in 3D. Sieht sehr interessant aus, vor allem weil es eine enge Integration in eine IDE (BlueJ) mit Fokus auf Programmieren lernen hat. Und mittlerweile kann man daraus auch direkt Android Applikationen generieren und damit zum Beispiel eigene Spiele oder Spielereien bauen.

Pyjnius: Accessing Java classes from Python | Txzone. Sehr interessantes Seitenprojekt von Kivy - damit kann man recht einfach Java-Klassen in Python integrieren und benutzen, ohne auf Jython wechseln zu müssen. Es basiert auf Cython und JNI und integriert sich so direkt in das native Python. So langsam wird Kivy wirklich zu einer Alternative für die Android Entwicklung die ich mir mal genauer angucken sollte.

commonsguy/cwac-anddown. Noch eine Markdown-Implementierung - diese benutzt intern sundown und JNI und das NDK um unter Android eine schnelle Implementierung von Markdown zu haben. Hat bei mir problemlos funktioniert mit dem Nexus.

Arduino - MacOSX. Was mich an Arduino fasziniert: die einfache Oberfläche der IDE (die einfach ein erweitertes Processing ist) und der Haufen an verrückten Projekten rundherum, wie zum Beispiel Digispark, einem Mini-Board das zwar weniger kann, aber dafür winzig ist und direkt vom USB Port betrieben wird. Da kann man ja wirklich mal zum Beispiel über Füllstandsmesser für Blumenbewässerung oder ähnliches nachdenken. Bei den Preisen für das Mini-Board wird das direkt realistisch.

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.

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.

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.

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.

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.

[[[New App]] Impressive: AIDE Is An IDE That Lets You Write And Compile Android Apps On Your Android Device, Begs For The Yo Dawg Treatment](http://www.androidpolice.com/2012/03/06/android-gets-a-native-ide-lets-you-write-android-apps-on-your-android-tablet-is-begging-for-the-yo-dawg-treatment/). Android-Entwicklung auf Android-Geräten (vorzugsweise Tablets). Das ist ja sowas von meta.

FAQ - Kotlin - Confluence. Die Drölfundfünfzigste Java-Killer-Sprache für die JVM, die hier auch gleich Scala attackiert (das übliche Argument "Scala ist zu kompliziert", welches auf den ersten Blick auch durchaus stimmt - Scala hat wenige zentrale Basisfeatures, die durch die Standardlibrary und die gute DSL Möglichkeit die eigentliche Sprache an der Oberfläche für den Programmierer dann mit vielen Features versorgt). Bleibt die Frage, was daraus wird, aber da JetBrains dahinter steht, wird sie zumindestens eine gute IDE haben (JetBrains baut IntelliJ und andere JVM IDEs, unter anderem auch PyCharm und mit AppCode die einzige derzeitige OSX Objective-C Alternative zu XCode). Und hey, wer seine Sprache nach einer Insel vor St. Petersburg benennt, hat schon mal einen Wohlwollensvorsprung bei mir.

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.

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.

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.

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).

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.

nathanmarz/cascalog - mal näher beobachten, eine Verheiratung von Clojure und Hadoop zur einfacheren Auswertung großer Datenbestände. Das Interessante an Cascalog: es greift Ideen aus Datalog auf und bildet in Clojure eine Abfragesprache für Hadoop Datenbestände.

Enterprise Java Development Tools | SpringSource. Muss ich mir mal genauer angucken, weils letztens um J2EE und EJB Alternativen ging, und das ja nun eine der bekannteren Alternativen ist.

Threads sind ein Hammer, aber nicht jedes Problem ist ein Nagel

Wer mal herzhaft lachen will: Node JS and Server side Java Script. Da meckert jemand aus dem Java-Lager darüber, das Node.JS ja nun wirklich nicht ernstzunehmen sei und produziert doch selber gleich das beste Beispiel, warum sowas wie Node.JS (und viele andere Alternativen für Serverprogrammierung) existieren - denn der Java Code wird mit jedem Schritt länger und länger. Und selbst nach mehreren Iterationen für ein in Node.JS (oder z.B. mit gevent in Python) ziemlich simpel zu realisierendes Beispiel werden in den ersten Kommentaren gleich ein paar Fehler und Lücken im Java Code angesprochen.

Versteht mich nicht falsch - Java hat eine Menge von guten Lösungen für Programmierung mit multiplen Threads in der Standard-Library. Warscheinlich von allen derzeit verfügbaren Sprachen die größte Auswahl an Möglichkeiten mit multiplen Threads zu programmieren. Aber wie so oft im Leben: Threads sind nicht die Antwort auf alle Fragen der Parallelisierung. Besonders wenn es in die Richtung von hoher Request-Last geht, ist die Einschätzung in den Kommentaren das 20K Threads schon sehr hoch sind lächerlich - erzählt das mal den Programmierern von Eve Online, in der jedes Schiff in derem virtuellen Universum als Microthread modelliert wird.

Java ist als Plattform sehr interessant, eben weil es viele Low-Level-Libraries mitliefert mit denen man sehr interessante Sachen machen kann - und die hilfreich sind um vernünftige Highlevel-Konstrukte darauf aufzubauen. Zum Beispiel im Zusammenspiel mit Sprachen wie Clojure oder Scala wird dem Threadmonster einiges an Schrecken genommen. Aber manchmal ist die Antwort eben nicht der Thread, sondern asynchroner IO (sowohl bei Festplattenzugriffen und Netzwerkzugriffen) und die intensive Nutzung von Coroutinen oder Continuations.

Auch das Unverständnis der Java-Programmierer auf den Ansatz das Multi-Core Problem einfach mit mehreren parallelen Prozessen und Message-Passing zwischen diesen zu lösen ist in 2011 ziemlich seltsam - denn schließlich waren 2009 und 2010 die Revival-Jahre für Erlang (nicht vergessen, die Sprache existiert schon sehr viel länger) und gerade die zentrale Idee von Erlang ist ja das Netz- und CPU-übergreifende Message-Passing als Standard zu setzen um eine sehr einfache Parallelisierbarkeit und Skalierbarkeit zu bekommen.

Java-Programmierer erinnern mich immer wieder an die Cobol-Programmierer meiner Anfangszeit, die in jeder Sprache und jeder Programmierweise ganz gezielt die Sachen rauspickten und kritisierten, die in Cobol eben anders (und manchmal sogar vielleicht etwas einfacher) gelöst waren - aber dann gnadenlos auf die Schnauze fielen wenn sie damit reale Probleme ausserhalb der Cobol-Komfortzone lösen mussten.

Das Beste von Java ist die JVM und damit eine Plattform die gerade die Multiparadigmen und -sprachen Ansätze möglich machen mit denen man dann für Probleme die Werkzeuge einsetzen kann, die ihnen angemessen sind. Und selbst dann ist manchmal die Antwort trotzdem Node.JS oder ein anderer kleiner, schlanker, asynchroner Server. Denn selbst mit einer großen Sammlung verschiedenster Hämmer wird man sich für die Schraube trotzdem einen Schraubendreher holen.

IKVM.NET Home Page liefert eine Java VM in .NET - man soll damit sogar so verrückte Sachen machen können, wie z.B. Scala 2.8 auf .NET laufen zu lassen.

Kilim - beim Stöbern in den Orc Dokumentationen drüber gestolpert, eine microthread-Lib für Java.

Oracle cooks up free and premium JVMs - und Oracle beginnt mit dem Versuch des Cash-in auf Java. Wenn es klappt, könnte Java bald in ähnlicher Situation wie .NET sein: die freien Implementierungen hängen hinter dem Umfang der kommerziellen hinterher. Was das für alternative Sprachen auf der JVM bedeutet, muss sich erst zeigen - aber sicherlich wird es für einige Probleme sorgen. Allerdings ist die JVM-Welt groß genug und mit genügend Alternativen ausgestattet, und Oracle ist nicht Microsoft. Von daher könnte das ganze auch bloß wieder ein Sturm im Wasserglas sein und allenfalls die typischen Oracle-Opfer betreffen.

Links

rfc1437 | Content-type: matter-transport/sentient-life-form - Tendenzen stark in Richtung "wegschmeissen mit Archiv und neu anfangen" mit leichten Optionen zu "wegschmeissen, statisches Archiv und vielleicht einen Teil in die neue Plattform schaufeln wenn ich Zeit finde". Der Link zeigt wo ich im Moment rumspiele. Wordpress mit ein paar kleinen Plugins und einer nginx caching Front.

Bitrot

Hat mich jetzt auch voll erwischt. Meine alte Blog-Software wird wohl nicht unverändert überleben können. Alte Python-Version (2.3), altes (sehr altes) Django (0.91), alter PsycoPG Treiber (1.0), altes PostgreSQL (7.4) und das alles auf einer alten Debian (eine wilde Mischung verschiedenster Versionen mit Backports und eigenen Programmen und mehreren gescheiterten Upgrade-Versuchen). Argh.

Tja, ich schwanke noch zwischen "umprogrammieren" und "wegschmeißen". Letzteres hätte den Charme, dass ich den ganzen Müll nicht mehr mit mir rumschleppe. Und ehrlich, so viel interessantes hat sich auf meinem Blog eh nie abgespielt. Vielleicht kann ich ja vorher einen wget Mirror anlegen und mir den ganzen Kram irgendwo statisch hinkippen, so als Archiv.

Neuschreiben hat natürlich auch eine Menge Charme, aber die tausenden von alten Einträgen (über 4000 Artikel und über 4000 Links, dazu fast 200 Bilder) aus 8 Jahren (erster Eintrag am 3.11.2002) bloggen zu konvertieren klingt nicht wie Spaß. Und vermutlich sind tausende der Links eh völlig veraltet und hinfällig.

Keine Ahnung was ich mache, vielleicht versuch ich erstmal die Metaeule auf die neue Kiste zu bringen, da hab ich ja "nur" das Problem, dass es PHP4 nicht mehr im Ubuntu Repository für die 10.04 gibt und ich daher die Eule zwangsweise auf PHP5 bringen muss (und das mit Code der auf Wordpress 1.5 aufbaut - ich muss wirklich bekloppt sein).

Oder ich versuch die Installation einer gammelalten Debian mit den damals eingesetzten Paketen - die Kiste läuft eh nicht in der Front, sondern hinter anderen Maschinen, das Hack-Risiko ist an der Stelle ja dann doch eher gering. Die Metaeule hat natürlich auch ein paar Tausend Beiträge im Archiv (nur 8291, ist ja fast nix), aber wenn ich die alte Software weiter am Laufen halten kann (Security-Patches sind da einige im Laufe der Zeit reingelaufen, von daher kann die eigentlich ruhig weiter vor sich hin wurschteln), bräuchte ich die ja nicht zwingend anpacken.

Irgendwie war das mit dem Internet auch so eine richtig blöde Idee ...

Twisted Orchestration Language in Launchpad - und jemand hat die Orc-Kombinatoren nach Python portiert, unter Benutzung von Twisted. Allerdings finde ich persönlich Twisted eher eklig zu programmieren, aber wers mag ...

Kilim - beim Stöbern in den Orc Dokumentationen drüber gestolpert, eine microthread-Lib für Java.

Orc Language - bisher nichts davon gelesen, aber sieht recht interessant aus. Kern ist Cor, eine funktionale Sprache ohne Seiteneffekte und darauf aufbauend dann Orc, die zur Orchestrierung von Services in verteilten Systemen dient. Das ganze in einer recht ansprechenden, kompakten Syntax auf der JVM. Könnte man sich durchaus mal als Alternative zu Scala und Clojure angucken, Java wird dabei als externer Service integriert, dadurch können recht einfach verteilte Systeme gebaut werden, bei denen Teile eben in Java implementiert sind. Erinnert in vielen Punkten stark an die Ideen von Erlang (generell von einem verteilten System ausgehen, aber trotzdem Teile lokal aus Performancegründen halten), wobei ich die Syntax deutlich angenehmer finde. Und mit der JVM eine deutlich weiter verbreitete VM als bei Erlangs BEAM.

Interactive Fabrication » Beautiful Modeler - wow, das ist ausgesprochen cool.

Tornado Web Server Documentation - muss mir doch mal Tornado näher angucken. Hab jetzt für ein Nebenprojekt einen Webservice mit web.py gebaut, was erschreckend simpel (und schmutzig) ging. Tornado baut auf einem sehr ähnlichen Konzept auf, schmeisst Django-ähnliche Templates in den Mix und bietet gleich noch einen guten asynchronen Server und Unterstützung für asynchrone sockets und http requests. Könnte gerade für Webservices eine gute Alternative sein, die wenig Resourcen braucht.

Fat Cat Software - iPhoto Library Manager - da ich so blöd war ein Photobuch auf einem anderen Mac als üblich zu machen (naja, der übliche war halt ständig belegt), muss ich mir jetzt wohl das hier mal angucken um zu schauen ob ich meine Bücher zusammenmergen kann auf eine einzelne Maschine. Schon blöd, dass Apple bei iPhoto keinerlei Merge-Funktion anbietet. Gerade mit einem Notebook und einem Desktop hat man ja doch recht schnell getrennte Libraries. Würde Lightroom Bücherdruck unterstützen wär ich ja eh schon längst weg von iPhoto. Alles irgendwie nicht so ganz befriedigend.

The V4Z80P – A Z80 Based Laptop @ Retroleum - da baut einer nicht nur seinen eigenen Computer mit eigenem System, es ist auch noch gleich ein Laptop. Oder sowas ähnliches jedenfalls.

Oracle cooks up free and premium JVMs - und Oracle beginnt mit dem Versuch des Cash-in auf Java. Wenn es klappt, könnte Java bald in ähnlicher Situation wie .NET sein: die freien Implementierungen hängen hinter dem Umfang der kommerziellen hinterher. Was das für alternative Sprachen auf der JVM bedeutet, muss sich erst zeigen - aber sicherlich wird es für einige Probleme sorgen. Allerdings ist die JVM-Welt groß genug und mit genügend Alternativen ausgestattet, und Oracle ist nicht Microsoft. Von daher könnte das ganze auch bloß wieder ein Sturm im Wasserglas sein und allenfalls die typischen Oracle-Opfer betreffen.

Kunsthalle Bielefeld: Der Westfälische Expressionismus - ich glaub ich hab tatsächlich mal einen Grund nach Bielefeld zu fahren.

Mediathek für Mac OS X - muss ich mir mal angucken. Schliesslich ist ja die Archivierung dank dämlicher Privatsenderhansel (und Politikern, die sich zu deren Erfüllungsgehilfen gemacht haben) heutzutage Sache der Zuschauer.

Panasonic DMC-GF2 Preview: 1. Introduction: Digital Photography Review - ich hasse dich, Panasonic. Jetzt will ich das niedliche kleine GF2+14mm Kit haben. Menno. Erst Apple mit dem MacBook Air und jetzt Panasonic, alle wollen nur mein Geld.

Eventlet Networking Library - muss ich mir mal näher angucken, das monkey-Patching von Standardbibliotheken um diese trivial in einer asynchronen Umgebung zu nutzen sieht sehr interessant aus.

lambdaj - bringt Java anonyme Funktionen und higher-order-Funktionen (naja, zumindestens Annäherungen an diese) bei.

JEmacs - the Java/Scheme-based Emacs - nur so for future curiosity geblogmarkt.

About Greenfoot - eine grafische Programmierumgebung für Spiele und anderes interaktives in Java. Von den BlueJ Machern.

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.

maven-jython-plugin - Maven Jython Plugin - hmm, der Jython-Support für Maven ist ziemlich veraltet - das Artifact geht nur gegen 2.2.1 und auch das Plugin geht nur auf 2.2.1. Da fehlt dringend wohl ein bischen Updaten.

fastutil - manchmal sicherlich ganz praktisch, Collections für Java die auf primitiven Typen aufsetzen und diese Collections dann platz- und performance-effizient implementieren. Also z.B. sowas wie ein Array von Bytes. Oder ein Map von Strings auf Booleans. Die Library hat so etwas über 1000 Kombinationen parat ...

Java Image Processing - Blurring for Beginners - Tausend und ein Weg wie man ein Bild unscharf bekommt (was durchaus praktische Anlässe haben kann) mit Java Code als Beispielen.

Nailgun: Insanely Fast Java - wenn der JVM Start zu lange dauert kann Nailgun mit einer persistenten JVM helfen. Die läuft einfach weiter und kriegt gesagt was sie machen soll. Sollte dementsprechend auch mit Scala und Clojure helfen, gerade wenn man kleine Tools damit bauen will, die nicht jedesmal eine neue JVM starten sollen.

ProGuard - hilft beim runtertrimmen von standalone jars. Wobei das allerdings nicht so einfach mit Clojure oder Scala standalone jars ist, da gehört schon etwas Fummeln dazu scheinbar.

SQLiteJDBC - noch ein JDBC Treiber für SQLite

SQLiteJDBC - weil ich ein SQLite Fan bin (wenns zu komplex für simple Textfiles ist, ist SQLite die nächsthöhere Stufe), und weil ich mit Scala und Clojure rumspiele, könnte ich das hier mal brauchen.

neo4j open source nosql graph database - die vorhin genannte Graphen-Datenbank für Java. Sieht recht interessant aus für die Situationen, in denen relationale Datenbanken zu starr und unflexibel sind.

Maven - Guide to using proxies - weil ich es gerade brauchte, denn Leiningen (Build-Tool für Clojure) setzt auf Maven auf. Leider muss das in einem XML-File geändert werden, damit ist es nicht so leicht zu automatisieren. Ich muss mir dafür mal was brauchbares für Linux einfallen lassen, das bei Setting-Änderungen automatisch diverse Configs umschiesst.

Yeti programming language - sollte ich mir mal angucken, ein ML für die JVM. Scala bietet natürlich vieles davon ebenfalls und hat sicherlich im Moment deutlich mehr Drive. Aber ML fand ich schon immer recht interessant, weil die Sprache recht kompakt ist - und mit JVM-Anbindung gibt es die ganzen Java-Bibliotheken zum Rumspielen sozusagen gratis dazu. Wobei Yeti wirklich nur eine ML-style Sprache ist, nicht wirklich ML (deutliche Unterschiede in der Syntax).

Hudson CI - da ich mich verstärkt mit JVM Sprachen beschäftige, wäre sowas durchaus interessant. Eine Continuous Integration Plattform in und für Java (und auch für andere Zwecke nutzbar). Interessant vor allem die leichte Installation - einfach nur ein .war das man startet oder in einen Container wirft und dann über das Webinterface konfiguriert. Continuous Integration hilft gewaltig beim Deploy, gerade wenn man seine Projekte sauber mit Unit-Tests aufbaut. Manuelles Durchlaufen der Testsuite entfällt dann weitestgehend, da der CI Server das übernimmt und zum Beispiel automatisch sauber durchlaufende Builds als Beta deployen kann oder z.B. funktionierende Snapshots (im Sinne der Testfälle funktionierend) als Downloads bereitstellen kann.

Play framework - ein recht interessantes Framework für Java im Stile von Django oder Rails. In der Dev-Version 1.1 unterstützt es auch Scala für die Viewfunktionen, was dann wieder ganz interessant ist, denn egal wie nett das Framework ist, ich werd mir nicht Java roh antun.

NetBeans support for Google App Engine - der Titel sagt schon alles. Netbeans gefällt mir übrigens relativ gut. Sieht zwar absolut arm aus (nicht sonderlich gut in Cocoa eingepasst - Eclipse macht da einen deutlich besseren optischen Eindruck), aber im Gegensatz zu den Alternative scheinen die Plugins recht gut zu funktionieren (Eclipse produziert komische Fehler, IntelliJ muss man erst die richtige Version vom Plugin für die richtige Version der IDE jagen gehen). Und das Clojure-Plugin von Netbeans scheint bis jetzt das netteste zu sein - die REPL ist echt gut.

:: Clojure and Markdown (and Javascript and Java and...) - interessanter Post, weil hier der Vorteil der gemischten Sprachen auf der JVM voll ausgespielt wird. Anstelle einen Markdown-Parser für Clojure zu schreiben, wird einfach einer in JavaScript über Rhino (JS in Java) benutzt. Womit dann auch sichergestellt ist, das sowohl Web-Client als auch Blog-Server die gleiche Implementierung von Markdown benutzen können.

for post in leo.blog():: Django-Jython 1.0.0 released! - für ein Projekt auf der Arbeit nicht unwichtig: Django-Jython hat fertig. Und mit dabei der Oracle-Client, den wir in dem Projekt auch dringend brauchen würden. Nett.

avodonosov's abcl-idea - da ich gerade mit IntelliJ spiele (und den Plugins für Scala und Clojure dafür), hier gibts auch ein Plugin zur Integration von Common Lisp in Idea. Sogar mit der Möglichkeit Erweiterungen für Idea in Common Lisp zu schreiben (und einer eigenen Repl dafür zu haben). Müsste ich mal ausprobieren.

(Field) - beim Schockwellenreiter gefunden und jau, das Teil sieht sehr interessant aus. Processing auf Steroiden? Jedenfalls deutlich offener was die Programmiersprachen angeht. Muss ich definitiv mal genauer angucken, denn einfache grafische Oberflächen ala Processing sind das was mir z.B. für Processing oder Abcl noch fehlen.