Archiv der Kategorie: Development

PHP: The Right Way

Die Programmiersprache PHP und das Ökosystem um die Sprache herum haben im Laufe der Jahre (PHP gilt sicherlich noch als relativ junge Programmiersprache, hat aber vor kurzem bereits seinen 20. Geburtstag gefeiert) zahlreiche und tiefgreifende Veränderungen durchgemacht. Dementsprechend widersprüchliche und veraltete Informationen finden sich rund um PHP im Internet, in Tutorials und Einsteiger-Literatur.

Die Seite »PHP: The Right Way« möchte die Situation etwas verbessern und bietet eine Zusammenfassung einiger wichtiger Werkzeuge und Verfahren in und rund um PHP mit vielen weiterführenden Links. Die Seite ist sicherlich nichts für Programmier-Neulinge geeignet, aber für alle, die entweder ihre PHP-Kenntnisse noch einmal auf den neuesten Stand bringen wollen oder als Erfahrene Entwickler ins Thema einsteigen wollen bzw. müssen.

Die Seite ist nicht nur auf Englisch verfügbar; es sind auch einige Übersetzungen, auch eine deutschsprachige, verlinkt.

Bleibt zu hoffen, dass die Seite auch in Zukunft fleißig aktuell gehalten wird.

Vom Umgang mit der Zeit

Bei kaum einem Thema kann man als Software-Entwickler so vieles falsch machen wie beim Umgang mit Zeit- und Datumsangaben. In seinem Blog hat Noah Sussman mal so einige Annahmen gesammelt, von denen Entwickler in Bezug auf Zeitangaben gerne ausgehen – die aber definitiv falsch sind. Das ist unterhaltsam und überraschend lehrreich.

Noah Sussman: Falsehoods programmers believe about time

7 Useful Git Tips for Beginners

Auch wenn es vor allem (Berufs-)Anfänger nicht einsehen wollen: Wer als Software-Entwickler nicht wenigstens irgendeine Art von Quellcode-Verwaltung verwendet, ist lebensmüde.

Bei Six Revisions gibt es einen schönen Beitrag »7 Useful Git Tips for Beginners«, der (wie der Titel bereits sagt) nützliche Hinweise und Links zu zahlreichen weiterführenden Ressourcen zum Einstieg in die Quellcode-Verwaltung mit git enthält. Nicht nur für VCS-Neulinge interessant, sondern auch für alle, die vielleicht auf git umsteigen wollen.

Howto: Dokumentation mit Markdown schreiben in Netbeans

Wer direkt in seiner Entwicklungsumgebung auch Dokumentationen und Readmes bearbeitet, wird sich schnell Wege überlegen, um Überschriften, Aufzählungen und Sonstiges hervorzuheben bzw. zu formatierten. Mit Markdown gibt es ein weit verbreitetes und sehr einfaches System, das sich dafür hervorragend eignet. Leider bietet Netbeans von Haus aus keine besondere Unterstützung für dieses Format.

Der Entwickler Florian Reiss hat sich dieses Problems angenommen und bietet ein entsprechendes Netbeans-Plugin auf github an.

Wer sich mit git auskennt, kann also das Projekt klonen und am besten in der eigenen Netbeans-Installation übersetzen und anschließend das erstellte Paket installieren. Alle anderen klicken auf der Github-Seite am besten auf Download ZIP, entpacken das heruntergeladene Archiv und installieren das Plugin, das sich im Unterverzeichnis nbm befindet und flow-netbeans-markdown.nbm heißt. Dazu öffnet man den Plugin-Manager (Tools / Plugins), wechselt auf den Reiter Downloaded, klickt auf Add Plugins…, wählt die oben genannte NBM-Datei aus und klickt anschließend auf Install. Nach einem Neustart ist das Plugin aktiv.

Über den Plugin-Manager kann das heruntergeladene Modul installiert werden
Über den Plugin-Manager kann das heruntergeladene Modul installiert werden

Das Plugin bietet nicht nur Syntax-Highlighting für die Markdown-Syntax, sondern kann auch direkt HTML-Dateien erzeugen und unterstützt zahlreiche Erweiterungen zur Standard-Markdown-Syntax. In den Plugin-Einstellungen (Preferences / Miscellaneous / Markdown) lassen sich die Extensions einschalten und ein Grundgerüst editieren, das bei der HTML-Generierung verwendet wird. Hier ist es etwa möglich, CSS zu notieren oder eine CSS-Datei (die allerdings dann jeweils von Hand zu kopieren ist) zu referenzieren.

In den Markdown-Einstellungen kann das HTML-Template bearbeitet werden
In den Markdown-Einstellungen kann das HTML-Template bearbeitet werden

Die Syntax von Markdown ist recht simpel und ist darauf ausgelegt, dass auch die Plain-Text-Version eines Dokumentes noch gut gelesen werden kann. Einfache Basis-Elemente sind Überschriften, Zitatblöcke und Listen:

Eine ausführliche Beschreibung von Markdown findet man hier, eine Beschreibung der Erweiterungen hier. Mit Hilfe von pandoc ist es sogar möglich, Markdown-Dateien nach ePub, PDF, LaTeX und andere Formate zu konvertieren.

Über das Kontextmenü einer MD-Datei kann eine HTML-Version generiert werden
Über das Kontextmenü einer MD-Datei kann eine HTML-Version generiert werden

Kleiner Tipp noch zum Schluss: Im Gegensatz zu Programmcode ist es natürlich empfehlenswert, bei Markdown-Dateien den Zeilenumbruch im Editor einzuschalten. Das geht von Haus aus in Netbeans nur global, was auf Dauer zu umständlich ist. Auch hier schafft ein Plugin Abhilfe: Toggle Line Wrap heißt es und kann direkt über den Plugin-Manager installiert werden. Es richtet rechts unten in der Statusleiste eine kleine Schaltfläche ein, mit der der Umbruch (nur) für die aktuelle Datei umgeschaltet werden kann.

Howto: Einrichtung eines PHP-Projektes mit Subversion und FTP-Synchronisation in Netbeans

Ein PHP-Projekt in Netbeans einzurichten ist nicht sonderlich schwer; man braucht lediglich ein Projektverzeichnis anzugeben und kann loslegen. Ein wenig komplizierter wird es, wenn das Netbeans-Projekt sich in bestimmte Workflows einbinden muss, etwa dann, wenn im Team entwickelt wird (Stichwort Versionsverwaltung) oder der Code mit einem entfernten Server abgeglichen werden soll. Glücklicherweise bietet Netbeans einige Hilfsmittel, die dem Entwickler das Leben leichter machen.

Dieser Artikel zeigt die exemplarische Einrichtung eines PHP-Projektes in Netbeans, das folgende Voraussetzungen erfüllt:

  • Das Projekt wird lokal abgelegt und ist von hier aus auch lauffähig, weil eine lokale Web-Server-Umgebung vorhanden ist
  • Der Quellcode befindet sich unter Subversion-Verwaltung, was in diesem Szenario das gemeinsame Arbeiten mit mehreren Entwicklern (mit jeweils eigener lokaler Arbeitskopie) ermöglicht
  • Der lauffähige Code wird per FTP mit der produktiven Web-Server-Umgebung abgeglichen; der Abgleich erfolgt manuell (auf Wunsch können Änderungen auch automatisch übertragen werden)

Die lokale Umgebung wird also für die Entwicklung und das Testen genutzt. Änderungen werden in die Quellcode-Verwaltung übertragen. Zum Abschluss einer Teil-Entwicklung wird der aktuelle Projektstand mit dem produktiven Web-Server abgeglichen. Dieses Setup eignet sich sowohl für kleinere Teams (größere würden sicherlich den Upload auf das Produktivsystem reglementieren) als auch den einzelnen Entwickler, der an einer Website arbeitet.

Wir gehen davon aus, dass zunächst ein leeres Subversion-Repository vorhanden ist, also auch noch die üblichen Verzeichnisse tags, branches und trunk angelegt werden müssen. In Netbeans muss gegebenenfalls noch das Subversion-Plugin über den integrierten Plugin-Manager installiert werden, sofern das noch nicht geschehen ist.

Zunächst legen wir in Netbeans über den Menüpunkt Datei / Neues Projekt ein neues Projekt an und wählen als Vorlage PHP Application. Im nächsten Schritt vergeben wir einen passenden Projektnamen, wählen das lokale Webserver-Wurzelverzeichnis aus, wählen die gewünschte PHP-Version und Zeichenkodierung.

Grundlegende PHP-Projekteinstellungen
Grundlegende PHP-Projekteinstellungen

Der folgende Dialog ist ein wenig komplizierter. Unter Run As wählen wir den Punkt Remote Website (FTP, SFTP) aus, da wir mit einem entfernten Server abgleichen möchten, obwohl ja bereits das lokale Projekt (in der eigenen Server-Umgebung) lauffähig ist. Als Project URL geben wir nun aber nicht die Einstiegsadresse auf dem Produktivsystem an, sondern die Adresse des lokalen Web-Servers, also etwa »http://localhost/« – wer sich mit seiner Hosts-Datei auskennt, kann natürlich auch (wie im Beispiel dargestellt) einen klangvolleren Namen hierfür vergeben.

Laufzeiteinstellungen
Laufzeiteinstellungen

Nun müssen wir eine Remote Connection einrichten: Hierfür klicken wir auf Manage und dann Add. Wir vergeben einen Namen für die einzurichtende Verbindung und wählen den Verbindungstyp; je nach Server FTP oder das abgesicherte SFTP. Nach Klick auf OK bearbeiten wir die Verbindungseinstellungen: Dazu gehören der Host-Name des FTP-Servers sowie Benutzername und Kennwort und das Initial Directory, das für die Datei-Übertragungen das Startverzeichnis darstellt. Die Datei- und Verzeichnisstruktur des PHP-Projektes wird 1:1 in dieses Verzeichnis auf dem FTP-Server übertragen, es ist also wichtig, dass hier der passende Pfad eingetragen wird. Die Einstellungen für Timeout und Keep-Alive können in aller Regel auf den Standardwerten bleiben. Mit Test Connection kann überprüft werden, ob die FTP-Einstellungen funktionieren.

FTP-Verbindung konfigurieren
FTP-Verbindung konfigurieren

Ist diese Remote Connection eingerichtet, landen wir wieder im Projekt-Assistenten. Dort haben wir noch die Möglichkeit, einen Upload-Pfad einzugeben. Dieser ergibt zusammen mit dem Basis-Pfad aus den FTP-Einstellungen das tatsächliche Projekt-Wurzelverzeichnis auf dem FTP-Server. Zur Kontrolle wird der zusammengesetzte Pfad in diesem Dialogfenster noch einmal ausgegeben.

Unter dem Punkt Upload Files wählen wir Manually aus, denn wir wollen erst am Ende eines Entwicklungsschrittes das gesamte Ergebnis auf das Produktivsystem übertragen und nicht bereits während der Entwicklung einen (möglicherweise aktuell nicht lauffähigen) Zwischenstand. Wenn es besser in den Arbeitsfluss passt, kann auch aus den Einstellungen On Save (beim Speichern einer bzw. bei Änderung einer Datei) oder On Run (beim »Ausführen« des Projektes über den entsprechenden Menüpunkt in der Entwicklungsumgebung) gewählt werden.

Im letzten Schritt des Assistenten können noch PHP-Frameworks ausgewählt werden, die allerdings noch separat installiert und konfiguriert werden müssen. Ob die Frameworks benötigt werden, hängt vom jeweiligen Projekt ab; in unserem Beispiel verwenden wir keines der angebotenen Frameworks und beenden den Assistenten.

Nun haben wir schon einmal ein Projekt eingerichtet, dass sowohl lokal lauffähig ist als auch mit einer Produktivumgebung synchronisiert werden kann. Wir testen das ganze, indem wir eine simple Datei »index.php« anlegen und auf Run klicken – im nächsten Augenblick sollte sich, wenn alles korrekt konfiguriert worden ist, ein Web-Browser öffnen und über den lokalen Web-Server die gerade angelegte Seite darstellen. Sollte das nicht funktionieren, müssen noch einmal die angegebenen Pfade in den Projekteinstellungen überprüft werden.

Nun fehlt noch die Subversion-Einrichtung. Dafür wählen wir im Menü Team / Subversion / Ins Repositorium importieren aus und konfigurieren im folgenden Dialog das Server-Profil. Wir geben hier die Repository-URL sowie unsere Authentifizierungsdaten ein. Je nach Subversion-Server gibt es hier recht unterschiedliche Möglichkeiten – daher kann an dieser Stelle keine allgemeine Anleitung erfolgen. Im nächsten Schritt wird das zu verwendende Unterverzeichnis des Repositoriums ausgewählt. Da wir von einem bisher leeren Repository ausgehen, legen wir ein neues Verzeichnis »trunk« an und wählen dieses als Ziel aus. Anschließend wird der aktuelle Projekt-Stand committed, also in das Repositorium übertragen.

Angabe des zu verwendenden Subversion-Repositoriums
Angabe des zu verwendenden Subversion-Repositoriums

Hiermit ist die Projekteinrichtung abgeschlossen. Änderungen können von nun an sehr bequem über die integrierten Subversion-Funktionen überprüft und auf dem Quellcode-Server übertragen werden. Möchte man etwa sehen, welche Dateien sich geändert haben, reicht es aus, im Projekte-Panel auf einen beliebigen Ordner (es kann auch das gesamte Projekt gewählt werden) zu klicken und Subversion / Änderungen zeigen auszuwählen. Es öffnet sich ein neues Panel, aus dem heraus die wichtigsten Subversion-Aufgaben ausgeführt werden können. Per Doppelklick auf einen Dateieintrag erhält man eine grafische Übersicht der erfolgten Änderungen und eine Historienansicht.

Sollen nun Änderungen per FTP auf das Produktivsystem übertragen werden, kann nun auf einem ähnlichen Weg eine Synchronisation mit dem FTP-Server erfolgen: Wieder wird das Projekt- oder ein bestimmtes Unterverzeichnis ausgewählt und im Kontextmenü Synchronize angeklickt. Bevor Netbeans nun irgendwelche Dateien überschreibt, zeigt es noch eine Zusammenfassung der Schritte an, die es auszuführen gedenkt, so dass es immer noch die Möglichkeit gibt, den Vorgang zu modifizieren oder abzubrechen. Wer mag, kann diese Zusammenfassung auch komplett ausschalten, aber zumindest eine grobe Kontrolle ist in der Regel ratsam. Wer direkt »auf dem FTP-Server« entwickeln möchte, kann in der Run Configuration des Netbeans-Projektes auch auf einen automatischen Upload On Save umschalten. Hierbei wird jede Dateiänderung (die auch etwa durch Subversion-Aktionen bedingt sein kann) direkt übertragen. Ob das für ein Produktivsystem empfehlenswert ist, hängt letzten Endes auch vom Entwicklungsstand und der Größe des Projektes bzw. der Anzahl der Entwickler ab.

Howto: To-Do-Listen in Netbeans

Mit dem Action Items-Panel bietet die Entwicklungsumgebung Netbeans eine einfache, aber effektive Möglichkeit, ausstehende Aufgaben, die im bearbeiteten Quellcode anfallen, zu markieren und mit Notizen zu versehen.

Dazu werden innerhalb des Quelltextes einfach Kommentare mit bestimmten Stichworten eingeleitet, denen jeweils eine kurze Beschreibung des Punktes folgt, etwa so:

// TODO Fehlerbehandlung vervollständigen

Wird nun über den Menüpunkt Window / Action Items das entsprechende Fenster geöffnet, werden die vorhandenen Punkte übersichtlich aufgelistet. Das Fenster bietet am linken Rand relativ umfangreiche Filtermöglichkeiten: so kann nicht nur gewählt werden, ob Einträge aus der aktuell geöffneten Datei, aus dem gesamten Projekt oder allen geöffneten Projekten angezeigt werden sollen, sondern es können auch beliebige Filter definiert werden, die nur bestimmte Stichworte berücksichtigen. Auch die Stichworte, die überhaupt als Action Item interpretiert werden sollen, können vom Anwender selbst definiert werden.

Natürlich stellt diese Art von To-Do-Listen keinen Ersatz für ein Bug-Tracking- oder Ticket-System dar, aber gerade für temporäre Erinnerungen (beispielsweise beim Entwicklen eines Prototypen / Grundgerüstes, das innerhalb weniger Tage mit »Leben« gefüllt werden soll) ist es ein schönes Hilfsmittel.

Das »Action Items«-Panel mit To-Do-Eintrag
Das »Action Items«-Panel mit To-Do-Eintrag

Howto: Lokale Historie unter Netbeans verwenden

In meinen Augen ist es eines der unscheinbarsten, aber ein überaus sinnvolles Feature, das Netbeans von Hause aus mitbringt: die lokale Historie. Mit ihr lassen sich Änderungen an bearbeiteten Dateien auch dann zurückverfolgen, wenn man kein ausgewachsenes System für die Versionsverwaltung einsetzt.

Natürlich sollte man bei jedem wichtigen Projekt (wenn es sich also nicht nur um eine Spielerei handelt) eine solche Versionsverwaltung einsetzen, erst recht dann, wenn man im Team an einem Projekt arbeitet. Aber auch dann kann die lokale Historie immer noch sinnvoll eingesetzt werden, etwa wenn es darum geht, Änderungen »auf dem Weg zum Commit« nachzuvollziehen bzw. in diesem Stadium Änderungen ganz oder teilweise rückgängig zu machen.

Die lokale Historie ist in Netbeans eine Standardfunktion, die nicht extra eingeschaltet werden muss. In der Standardeinstellung werden lokale Änderungen dreißig Tage lang aufbewahrt. Diese Zeitspanne kann geändert werden; wer mag, kann die Funktion auch vollständig deaktivieren. Die Einstellungen werden unter Options / Miscellaneous / Versioning / History vorgenommen.

Ist die lokale Historie aktiv, kann jederzeit für eine geöffnete Datei in die Historien-Ansicht gewechselt werden. Zum Umschalten zwischen Quellcode und zugehöriger Historie befinden sich direkt über dem Dateifenster die Schaltflächen Source und History. Die Historie zeigt eine Liste aller vorhandenen Zwischenstände der Datei mit dem Zeitpunkt der Erstellung. (Wer zusätzlich eine ausgewachsene Versionsverwaltung benutzt, wird feststellen, dass die Historie Dateiversionen aus beiden Systemen auflistet!) Per Klick erhält man eine grafische Übersicht der gemachten Änderungen zur Vorgängerversion oder zur aktuell gespeicherten Version der Datei. Alle Änderungen werden farblich markiert und gegenübergestellt. Es ist nun möglich, mit wenigen Klicks entweder einzelne Unterschiede von einer Version in die andere zu übernehmen oder einen bestimmten Versionsstand vollständig wiederherzustellen.

Das ganze entspricht also im Prinzip dem gleichen, was einem die Revisionshistorie einer »großen« Versionsverwaltung bietet – und das immerhin ohne jeglichen Einrichtungsaufwand.

Lokale Historie mit grafischer Darstellung der Unterschiede
Lokale Historie mit grafischer Darstellung der Unterschiede

Howto: Kompilieren und Installieren von NinjaIDE unter MacOS

NinjaIDE ist eine freie Entwicklungsumgebung für Python, die wir hier schon kurz vorgestellt haben. Für Windows und Linux existieren fertige Binärpakete, dort ist NinjaIDE also schnell und einfach eingerichtet. Unter MacOS sieht es leider anders aus. Hier erhält man lediglich die Software-Quellen und muss selbst kompilieren. Da NinjaIDE mit PyQt entwickelt wird, kommen Qt und PyQt als Abhängigkeiten noch dazu. Diese Anleitung beschreibt kurz, wie sich NinjaIDE unter MacOS (hier: Lion; für Mountain Lion sollten die Schritte identisch sein) bauen und installieren lässt.

Abhängigkeiten

Zunächst werden die benötigten Abhängigkeiten heruntergeladen. Kurzer Hinweis: Da die Software durchaus öfter aktualisiert wird, können die Versionsangaben in dieser Anleitung leicht von den aktuellsten Versionen abweichen.

Die benötigten Abhängigkeiten sind:

Qt4 (nicht Version 5!) von der Qt-Projektseite: http://qt-project.org/downloads

Hierbei handelt es sich um einen einfachen Installer, der das eigentliche Qt-Toolkit einrichtet. Das ist entsprechend schnell erledigt.

Bei Riverbank Computing lädt man sich nun die Sourcen für SIP und PyQt herunter:

sip-4.14.7.tar.gz von hier
PyQt-mac-gpl-4.10.2.tar.gz von hier

Beide Dateien werden wie üblich per Doppelklick entpackt. Anschließend muss das Terminal genutzt werden. (Von wegen, Mac-User hätten das nicht nötig!) Zunächst wechseln wir in das SIP-Verzeichnis und kompilieren und installieren es mit Hilfe folgender Befehle:

Das gleiche Spiel erfolgt nun mit PyQt: erst in das entsprechende Verzeichnis wechseln und die Build-Vorgang bzw. die Installation durchführen mit:

Der Vorgang dauert eine ganze Weile, man kann sich also in der Zeit getrost einen Kaffee machen.

NinjaIDE

Auf der Website des Projektes kann das Source-Paket für MacOS heruntergeladen werden. Anschließend wird es entpackt und ähnlich erstellt wie die Abhängikeiten. Wir wechseln also im Terminal in das Source-Verzeichnis und kompilieren die IDE wie folgt:

Launcher erstellen

NinjaIDE kann zunächst nur von der Shell (/usr/local/bin/ninja-ide) aus gestartet werden. Das Installationsscript beinhaltet zwar »py2app«, mit dem ein Launcher erstellt werden können sollte, das scheint aber nicht zu funktionieren (wahrscheinlich würden andernfalls auch fertige Binärpakete für den Mac angeboten werden).

Wir erstellen uns also einen einfachen Launcher mit Hilfe von Platypus, das kostenlos von der zugehörigen Projekt-Website heruntergeladen werden kann. Nach dem Start von Platypus wird das auszuführende Script /usr/local/bin/ninja-ide ausgewählt, der Script Type auf Python gestellt, ein Icon (das findet sich direkt im Source-Ordner von NinjaIDE) ausgesucht sowie wenige weitere Optionen eingestellt. Das Ergebnis sollte etwa wie folgt aussehen, wobei die Angaben zum Identifier und Autor anhand der persönlichen Benutzerkennung vorbelegt werden.

Platypus
Platypus

Mit Klick auf Create kann der gewünschte Launcher erstellt werden und beispielsweise im Application-Verzeichnis abgelegt werden.

Ninja IDE Mac
Das Ergebnis: Ninja IDE auf dem Mac

Coding Fonts

Kaum ein anderes Werkzeug ist für einen Software-Entwickler von so zentraler Bedeutung und gleichzeitig häufig so vernachlässigt wie der verwendete Coding Font. Oft genug wird einfach der voreingestellte Font verwendet, bessere Alternativen werden nicht geprüft. Dabei ist die Auswahl an guten Coding Fonts groß genug.

Die Klassiker: Courier (New) und Monaco

Courier hat seine Ursprünge bereits in den Fünfzigerjahren und findet sich spätestens seit den Achtzigern in der einen oder anderen Variante praktisch auf jedem Computer-System, anfangs als Bitmap-Font, später als bildschirmoptimierter Outline. Bei dieser Verbreitung ist es kein Wunder, dass man auch heute noch sehr häufig auf Courier stößt, obwohl – wie es Gerrit van Aaken ausdrückt – es rein ästhetisch betrachtet kaum Gründe gibt, die für den Einsatz der Courier sprechen.

Courier New
Courier New

Mac-User hatten neben der Courier schon seit ewigen Zeiten eine (bessere) Alternative: die Monaco. Das etwas eigenwillige Schriftbild ist durchaus »typisch« für den Mac und war dort für lange Zeit der Coding Font schlechthin.

Monaco
Monaco

Die neuen Standards: Consolas und Menlo

Weil sich in Sachen Font-Rendering und Display-Qualität und -Auflösung in den letzten zehn Jahren sehr viel getan hat, sind sowohl Microsoft als auch Apple mit der Zeit gegangen und statten ihre Systeme seit einigen Versionen u. a. auch mit neuen Monospace-Fonts aus, die ihre Vorgänger als Standardfonts ablösen sollen.

Unter Windows ist das Consolas, der an einigen Stellen etwas kantig wirkt; unter MacOS ist es der deutlich rundere Menlo, der auf dem weiter unten besprochenen Vera Sans Mono basiert, mit Ausnahme weniger Glyphen fast identisch ist und von Apple etwa in Xcode als neuer Default gesetzt ist.

Consolas
Consolas

Underrated Underdogs: Vera Sans Mono / DéjaVu Sans Mono

Seitdem die freie Schriftfamilie Bitstream Vera vor etwa zehn Jahren veröffentlicht worden ist, ist die nichtproportionale Variante mein absoluter Favorit, auch wenn ich den Eindruck habe, dass sie noch immer nicht sonderlich bekannt ist. Vera Sans Mono bietet ein klares und ruhiges Erscheinungsbild und ist auf die Bildschirmdarstellung optimiert. Das Derivat DéjaVu besitzt das gleiche Erscheinungsbild, aber einen größeren Zeichenvorrat. Der neue Apple-Standard-Font Menlo ist ebenfalls aus Vera Sans Mono entstanden.

DéjaVu Sans Mono
DéjaVu Sans Mono

Kostenloses vom Profi: Adobe Source Code Pro

Der Schriften-Profi Adobe bietet seit September des letzten Jahres mit Source Code Pro ebenfalls einen sehr ordentlichen und dazu kostenlosen Font an, der sich hervorragend für die Quellcode-Bearbeitung eignet.

Source Code Pro Medium
Source Code Pro Medium

Noch mehr Auswahl: Ubuntu Mono, Droid Sans Mono

Neben diesen Schriften gibt es noch einige Alternativen, von denen zumindest Ubuntu Mono und Droid Sans Mono genannt werden sollten. Die erstgenannte gehört zu denjenigen, die Canonical für sein eigenes Betriebssystem Ubuntu entwickelt hat. Der Font erinnert ebenfalls an Vera, besitzt jedoch einige Feinheiten, die sich davon abheben.

Ubuntu Mono
Ubuntu Mono

Droid Sans Mono wurde von Google für Android entworfen und ist frei verfügbar. Er bietet ebenfalls eine hervorragende Lesbarkeit am Bildschirm.

Droid Sans Mono
Droid Sans Mono

Anmerkung: Alle Abbildungen sind unter Ubuntu erstellt worden. Die Font-Darstellung kann je nach verwendetem Betriebssystem und den gesetzten Einstellungen variieren.

Mono: wohin geht die Reise?

Mono, die Open-Source-Implementierung von Microsofts .net-Plattform, war ein tolles Versprechen an Linux-Entwickler: Eine mächtige Software-Plattform, eine breite Unterstützung unterschiedlicher Programmiersprachen und nicht zuletzt die Möglichkeit, Anwendungen plattformunabhängig zu entwickeln.

Lediglich drohende Patentforderungen von Seiten Microsofts schienen der Verwendung im Wege zu stehen, Microsoft aber frühzeitig ein „Community Promise“ abgegeben, von solchen Forderungen abzusehen. Neben der Mono-Plattform hat das Team um Miguel de Icaza mit MonoDevelop noch eine großartige Entwicklungsumgebung angeboten.

Und auch wenn nicht alle Vorbehalte verschwunden sind, so wurde Mono doch in alle großen Distributionen integriert, und es entstanden einige interessante Software-Projekte auf Mono-Basis.

Mittlerweile scheinen keine Software-Patente, sondern eine andere Entwicklung für Linux-Entwickler bedrohlicher zu sein: Miguel de Icaza als der Kopf hinter dem ganzen Projekt und sein Unternehmen Xamarin, das sich um die Weiterentwicklung kümmert, haben sich von Linux – und scheinbar vom OpenSource-Gedanken – verabschiedet.

Miguel de Icaza selbst verwendet Linux schon seit Monaten überhaupt nicht mehr; Xamarin setzt stattdessen voll auf Apple-Systeme, insbesondere auf den boomenden Mobile-Markt. Und so wird die aus MonoDevelop hervorgegangene Entwicklungsumgebung Xamarin Studio (noch?) nicht für Linux angeboten, vom Vorgänger gibt es für die Linux-Distributionen teilweise nur noch vollkommen veraltete Versionen. Eine brauchbare »Community-Lizenz« für OpenSource- oder Freeware-Projekte gibt es auch nicht, mittlerweile aber wenigstens eine kostenlose und dafür stark eingeschränkte Version.

Und so ist durchaus fraglich, ob wenigstens die Mono-Laufzeitumgebung (die ja unter einer freien Lizenz steht) noch eine Zukunft unter Linux hat, und welchen Wert diese noch besitzt, wenn keine aktiv weiterentwickelte IDE existiert. Man kann Xamarin nicht vorwerfen, dass sie den gewählten Weg gehen. Für die OpenSource-Szene ist es leider kein guter Weg. Angesichts der ungewissen Zukunft würde ich für ein neues Projekt jedenfalls nicht auf Mono setzen.