Spracherkennung als Programmierwerkzeug

Für Endanwender ist diese Vision Gene Roddenberrys beinahe Realität: Mit natürlicher Sprache mit dem Rechner kommunizieren. Die Arbeit eines Programmierers nur über Sprachsteuerung zu erledigen ist noch lange nicht Mainstream, entgegen der Erwartung aber alles andere als unmöglich.

Eindrucksvoll belegt dies ein Vortrag von Tavis Rudd. Tavis hatte so schwere RSI-Symptome, dass er sich aus Emacs, Python und einer kommerziellen Software für Spracherkennung ein System zusammengebastelt hat, mit dem er letztlich schneller arbeiten konnte als gesund mit Tastatur. Dieser Vortrag ist definitiv sehenswert.

In die gleiche Richtung arbeiten auch andere, Heise Open berichtet über ein Werkzeug, dem man unter anderem reguläre Ausdrücke natürlichsprachlich diktieren kann.

Wir leben in der Tat in interessanten Zeiten.


Willkommen, boris! Endlich eine brauchbare REPL für PHP

In vielen Sprachen ist die Entwicklung ohne eine REPL — eine
Read-Eval-Print-Loop
— nicht vorstellbar. Schnell eine Funktion testen, einen regulären
Ausdruck prüfen oder anderen Code kurz ausführen – in einer REPL
schnell und unkompliziert erledigt.

PHP musste bisher ohne auskommen. Der interaktive Modus von PHP
(php -i) ist kein echter Kandidat für solche Arbeiten, zu
anfällig für Fehler im zu testenden Code. Dieser Zustand ging dem
Entwickler Chris ‚Chippie‘ Corbyn, durch die Transition seiner Firma
von PHP zu Ruby auf den Geschmack gekommen, so auf die Nerven, dass er
tätig werden musste: Willkommen boris. Boris
ist erstaunlich robust. Das Werkzeug möchte man bereits nach kurzer
Einsatzzeit nicht mehr missen, und stellt sich die Frage, wie man
bisher ohne entwickeln konnte.

Die github Seite des Projektes enthält alle Informationen, die man benötigt, um boris zu installieren.

Emacs Nutzer können zusätzlich über MELPA das Paket
php-boris‘ installieren — damit steht boris als comint Buffer im
Editor zur Verfügung.


git gutter: git diff im Editor

Heute stelle ich wieder einen nützlichen Helfer für den Entwickleralltag vor: git-gutter. Für den immer beliebteren Editor Sublime Text 2 entwickelt, zeigt das Plugin die Änderungen der editierten Datei durch Symbole an der Seite an. So sieht man auf einen Blick, welche Zeilen hinzugefügt, gelöscht oder verändert wurden.

git-gutter für Emacs

git-gutter wurde auch für vim und Emacs implementiert. Das Bild zeigt git-gutter im Emacs in Aktion.


Ein ASA Paper über org-mode als LP und RR Umgebung

Die American Statistical Association hat in ihrem Onlinejournal Journal of Statistical Software ein Paper von Eric Schulte et. al. (.pdf) veröffentlicht, dass, anschaulicher als es mir in diesem Blog bisher gelungen ist, erläutert, was org-mode zu einer so faszinierenden Entwicklungsumgebung macht. Das Paper ist, wie sicher bereits vermutet, in englisch verfasst.

Ungeduldige Leser springen gleich zu Seite 13 und sehen sich die Beispiele direkt an; wer sich den nötigen Hintergrund aus den Beispielen nicht erschliessen kann oder möchte, liest Abschnitt 3 ab Seite 6. Wer wissen möchte, was eine solche Entwicklung motiviert hat, liest vielleicht am besten das ganze Dokument ab Seite 1.

🙂

Die Akronyme:

  • LP: Literate Programming
  • RR: Reproducible Research

Weiterlesen


Linting javascript: lintnode

Was ist lintnode?

JSLint ist ein tolles Werkzeug, um javascript-Code auf korrekte Syntax und die Einhaltung von Konventionen zu prüfen. Mit lintnode steht ein node.js Server zur Verfügung, der die Nutzung von JSLint stark vereinfacht.

Einbindung in Emacs

Besonders schön ist die Einbindung von lintnode in Emacs gelöst; mit flymake-jslint.el wird eine Javascriptdatei kontinuierlich während des Tippens geprüft; etwaige Fehler in Cursornähe werden durch warnende Hervorhebung des betroffenen Codes angezeigt und in der Modeline erläutert.

Die Konfiguration in der .emacs Datei kann z.B. so aussehen:

;; jslint laden, flymake unterstützung laden
(add-to-list 'load-path "~/.emacs.d/src/lintnode")
(require 'flymake-jslint)
(require 'flymake-cursor)

;; Pfad zum jslint executable
(setq lintnode-location "~/.emacs.d/src/lintnode")

;; jslint konfigurieren
(setq lintnode-jslint-excludes (list 'nomen 'plusplus 'onevar 'eqeqeq
                                     'laxbreak 'undef 'strict))
(setq lintnode-jslint-includes (list 'node 'sloppy))

(setq lintnode-jslint-set "maxlen:100")

;; den lintnode server automatisch starten,
;; wenn eine js Datei geöffnet wird
(setq lintnode-autostart t)
(add-hook 'js-mode-hook
          (lambda ()
            (lintnode-hook)))
(add-hook 'js3-mode-hook
          (lambda ()
            (lintnode-hook)))

Im Einsatz sieht das ganze dann etwa so aus:

http://www.joocom.de/blog/wp-content/uploads/wpid-emacs_lintnode.png


ditaa: Ein Bild sagt mehr als 1000 Worte…

Was ist ditaa?

ditaa erzeugt aus ascii art Diagrammen Bitmapgraphiken; es unterstützt eine ausreichende Anzahl an Gestaltungsmöglichkeiten, um es zur Dokumentation in Softwareprojekten einsetzen zu können, und etwa Klassen- oder Ablaufdiagramme direkt im Code als Kommentare einzubetten. Die Information ist dort verfügbar, wo sie benötigt wird, wenn sie benötigt wird; und doch sieht sie, wenn es darauf ankommt – in der generierten HTML oder PDF Dokumentation – gut aus.

Ein Beispiel: tangling einer org-mode-Datei

Das folgende Diagramm veranschaulicht den Prozess, aus einer org-mode Quelldatei eine zsh-Konfiguration zu erstellen, und die möglichen Interaktionswege der generierten Dateien (in vereinfachter Form).

                                                               /---------------+
                                                               | ~/.zshrc      |          
                                                               |               +-=-------
                                                      /------->|               |         |
                                                      |        |               |         |
                                                      |        |               |         |
/----------------+              /----------------+    |        |               |         |
| Quelltext      |              | emacs          |    |        | cDB6      {d} |         |
| zshrc.org      |              | org babel      |    |        +---------------+         |
|                +------------->|                +----+                                  |
|                |              |                |    |        /---------------+         |
|                |              |                |    |        | ~/.zsh.d/lib/ |         |
| cYEL      {d}  |              |            {tr}|    |        |     git_alias |         |
+----------------+              +----------------+    +------->|               |<*=-    |
                                                      |        |               |    |    |
                                                      |        |               |    |    |
                                                      |        | cDB0      {d} |    |    |
                                                      |        +---------------+    |    |
                                                      |                             |    |
                                                      |        /---------------+    |    |
                                                      |        | ~/.zsh.d/     |----/    |
                                                      |        |     host_1    |         |
      ------->  input/output                          |        |               |         |
      -=----->  sources                               ------->|               |         |
      -=----*>  might source                                   |               |<--------/
                                                               | cDB4      {d} |  
                                                               +---------------+ 

http://www.joocom.de/blog/wp-content/uploads/wpid-ditaa_example6.png

Fazit

ditaa verarbeitet aktuell mehr Eingaben, als auf der sourceforge-Seite dokumentiert sind. Ein erweitertes Beispiel, mit interaktivem Webservice zur Erstellung von Diagrammen ist unter ditaa.org zu finden.

org-mode, der Emacs Modus, unterstützt ditaa nativ und Emacs bringt mit artist-mode eine für die Erstellung von Diagrammen äußerst hilfreiche Umgebung mit; ditaa selbst stellt mit der -h Option den html-Modus zur Verfügung, der in html-Dateien eingebette Diagramme (<pre class="textdiagram">...</pre>) durch img-Tags auf die generierten Bitmaps ersetzt.

Sicherlich gibt es einfache Wege, ditaa zu verwirren, hie‘ und da wird man viel überlegen müssen, wie man das Diagramm in ASCII nun aufbauen muss, damit die graphische Ausgabe die gewünschte Bedeutung transportiert.

Trotzdem ist ditaa ein wertvolles Werkzeug, dass ich in meiner Werkzeugkiste nicht mehr missen möchte.


Ein Beispiel für Literate Programming mit Emacs org-mode

Einführung

org-mode wird als das schweizer Taschenmesser des Editors Emacs beschrieben. Das ist in der Tat eine gute Beschreibung. Mit org-mode lassen sich Projekte und Aufgaben planen, Bücher verfassen, Musik komponieren, Weblogs führen, Webseiten veröffentlichen, Zeiten erfassen, statistische Berichte dynamisch verfassen, und noch einiges mehr.

Eine der für Softwareentwickler interessanten Möglichkeiten, ist die weitgehend sprachagnostische „Literate Programming“ Unterstützung, die ich an einem kurzen, einfachen Beispiel eines Shell-Programms im Folgenden vorstelle.

Das von Donald E. Knuth propagierte literate Programming besteht in erster Linie aus das Programm erklärender Prosa, in die der Programmtext eingebettet wird. Dabei können über Referenzen (Namen von Codeblöcken) an anderer Stelle eingeführte Konzepte eingebunden werden und so die Reihenfolge der Dokumentation vom zu generierenden Code entkoppelt werden.

Das Generieren der Dokumentation wird als „weave“ bezeichnet, das Generieren des Code als „tangle“.

Der nächste Abschnitt entspricht der aus dem literate programmierten Kleinstwerkzeug erzeugten Dokumentation. Im Abschnitt danach betrachten wir das Endprodukt, das Shellprogramm, sowie den org-mode-Code, der dieses Dokument erzeugt.

Das Beispiel: Prozentual gefülltestes Blockgerät bestimmen

Wir konstruieren hier ein Shell-Programm, das von den aktuell eingebundenen Blockgeräten den Mountpunkt des prozentual gefülltestem ausgibt.

Das Vorgehen ist denkbar simpel: Wir benutzen klassische Unixwerkzeuge in einer Aufrufpipeline.

Das Beispiel ist direkt übernommen, aber übersetzt und deutlich ausgeweitet. Das Original ist in der org-mode Dokumentation zu finden.

Alle eingehängten Geräte bestimmen

Wir bestimmen erst einmal alle aktuell eingebundenen Geräte. Sicherlich könnten mir dazu mount nutzen und dann mit einiger Magie über die Ausgabe iterieren. Einfacher ist es jedoch, df zu bemühen ((mount-info)), da dessen Ausgabe bereits alle Informationen enthält, die wir benötigen.

Beachte die Leerzeile am Ende des Codeblocks: Sie ist nötig, um im generierten („tangled“) Code eine neue Zeile hinter dem Backslash zu erhalten. Ich denke das ist ein Bug in der aktuellen org-mode Version, der mit padline Behandlung bei noweb-Dereferenzierung zu tun hat. Edit: In org-mode Versionen/Releases ab heute (23.01.2012) ist das Leerzeilenproblem bei dieser Art von tangling über Unterbäume behoben; Eric Schulte hat, auf das Problem aufmerksam gemacht, im Handumdrehen eine Lösung eingecheckt.

1: df  (mount-info)
2: 

Die Kopfzeile entfernen

Die Ausgabe von df beginnt mit einer informativen Kopfzeile, die die einzelnen Spalten der Ausgabe benennt. Wir schneiden sie mit sed weg ((cut-head)).

3: | sed '1d'  (cut-head)
4: 

Die Ausgabe sortieren

Wir extrahieren die uns interessierenden Informationen – Prozentualer Füllungsgrad und Einhängepunkt – mittels awk ((extract-info)), so dass wir Zeilen der Form „Füllung-in-Prozent Einhängepunkt“ erhalten. Das Ergebnis können wir mit sort numerisch aufsteigend sortieren ((sort)).

5: | awk '{print $5 " " $6}' (extract-info)
6: | sort -n  (sort)
7: 

Den Einhängepunkt bestimmen

Da wir in der Pipeline aktuell alle eingehängten Geräte, aufsteigend nach ihrem prozentualem Füllungsgrad sortiert vorliegen haben, gestaltet sich der Rest der Aufgabe recht einfach: Wir extrahieren die letzte Zeile mittels tail -n 1 ((trim)) und nutzen ein weiteres Mal awk, um die Spalte der Zeile zu extrahieren die uns interessiert: Den Einhängepunkt ((final)).

 8: | tail -n 1  (trim)
 9: | awk '{print $2}' (final)
10: 

Das generierte Shell-Programm

1: #!/bin/sh
2: 
3: df  
4: | sed '1d'  
5: | awk '{print $5 " " $6}' 
6: | sort -n  
7: | tail -n 1  
8: | awk '{print $2}'
9: 

Der org-mode Code

#+POSTID: 411
#+DATE: [2011-12-09 Fri 11:29]
#+OPTIONS: toc:nil num:nil todo:nil pri:nil tags:nil ^:nil TeX:nil
#+CATEGORY: Geeks!
#+TAGS: Emacs, literate programming, org-mode
#+DESCRIPTION:
#+TITLE: Ein Beispiel für Literate Programming mit Emacs =org-mode=
#+EXPORT_EXCLUDE_TAGS: ignoreExport

* Einführung
[[http://orgmode.org][=org-mode=]] wird als das schweizer Taschenmesser des Editors Emacs
beschrieben. Das ist in der Tat eine gute Beschreibung. Mit =org-mode=
lassen sich Projekte und Aufgaben planen, Bücher verfassen, Musik
komponieren, Weblogs führen, Webseiten veröffentlichen, Zeiten
erfassen, statistische Berichte dynamisch verfassen, und noch einiges
mehr.

Eine der für Softwareentwickler interessanten Möglichkeiten, ist
die weitgehend sprachagnostische  "Literate Programming"
Unterstützung, die ich an einem kurzen, einfachen Beispiel eines
Shell-Programms im Folgenden vorstelle. 

Das von Donald E. Knuth propagierte literate Programming besteht in
erster Linie aus das Programm erklärender Prosa, in die der
Programmtext eingebettet wird. Dabei können über Referenzen (Namen von
Codeblöcken) an anderer Stelle eingeführte Konzepte eingebunden werden
und so die Reihenfolge der Dokumentation vom zu generierenden Code
entkoppelt werden.

Das Generieren der Dokumentation wird als "weave" bezeichnet, das
Generieren des Code als "tangle".

Der nächste Abschnitt entspricht der aus dem literate programmierten
Kleinstwerkzeug erzeugten Dokumentation. Im Abschnitt danach
betrachten wir das Endprodukt, das Shellprogramm, sowie den
org-mode-Code, der dieses Dokument erzeugt. 

* Das Beispiel: Prozentual gefülltestes Blockgerät bestimmen
:PROPERTIES:
:noweb-ref: fullest-disk
:END:
Wir konstruieren hier ein Shell-Programm, das von den aktuell
eingebundenen Blockgeräten den Mountpunkt des prozentual gefülltestem
ausgibt.

Das Vorgehen ist denkbar simpel: Wir benutzen klassische Unixwerkzeuge
in einer Aufrufpipeline.

Das Beispiel ist direkt übernommen, aber übersetzt und deutlich
ausgeweitet. Das Original ist in der =org-mode= [[http://orgmode.org/org.html#noweb-ref][Dokumentation zu
finden]].

** Alle eingehängten Geräte bestimmen
Wir bestimmen erst einmal alle aktuell eingebundenen Geräte. Sicherlich
könnten mir dazu =mount= nutzen und dann mit einiger Magie über die
Ausgabe iterieren. Einfacher ist es jedoch, =df= zu bemühen ([[(mount-info)]]), da dessen
Ausgabe bereits alle Informationen enthält, die wir benötigen.

Beachte die Leerzeile am Ende des Codeblocks: Sie ist nötig, um im
generierten ("tangled") Code eine neue Zeile hinter dem Backslash zu
erhalten. Ich denke das ist ein Bug in der aktuellen =org-mode=
Version, der mit =padline= Behandlung bei =noweb=-Dereferenzierung zu
tun hat.
#+begin_src sh -n
 df  (mount-info)

#+end_src

** Die Kopfzeile entfernen
Die Ausgabe von =df= beginnt mit einer informativen Kopfzeile, die die
einzelnen Spalten der Ausgabe benennt. Wir schneiden sie mit =sed=
weg ([[(cut-head)]]).

#+begin_src sh +n
 | sed '1d'  (cut-head)

#+end_src

** Die Ausgabe sortieren
Wir extrahieren die uns interessierenden Informationen -- Prozentualer
Füllungsgrad und Einhängepunkt -- mittels =awk= ([[(extract-info)]]), so dass wir Zeilen der
Form "Füllung-in-Prozent  Einhängepunkt" erhalten. Das Ergebnis können wir
mit =sort= numerisch aufsteigend sortieren ([[(sort)]]).

#+begin_src sh +n
 | awk '{print $5 " " $6}' (extract-info)
 | sort -n  (sort)

#+end_src

** Den Einhängepunkt bestimmen
Da wir in der Pipeline aktuell alle eingehängten Geräte, aufsteigend nach
ihrem prozentualem Füllungsgrad sortiert vorliegen haben, gestaltet
sich der Rest der Aufgabe recht einfach: Wir extrahieren die letzte
Zeile mittels =tail -n 1= ([[(trim)]]) und nutzen ein weiteres Mal =awk=, um die
Spalte der Zeile zu extrahieren die uns interessiert: Den
Einhängepunkt ([[(final)]]).
#+begin_src sh +n
 | tail -n 1  (trim)
 | awk '{print $2}' (final)

#+end_src

* Das generierte Shell-Programm

#+begin_src sh -r -n :tangle no :noweb yes :shebang #!/bin/sh
    #!/bin/sh

    <<fullest-disk>>
#+end_src

* Der =org-mode= Code
#+INCLUDE: test_sh_tabgle.org example

* Programm erstellen /oder/ tangle                            :ignoreExport:
  :PROPERTIES:
  :comments: no
  :ID:       579cc2c8-2c45-4e28-acaf-2863986e37eb
  :END:

Dieser Abschnitt wird bei der Generierung der Dokumentation
("weaving") nicht berücksichtigt. Er sorgt aber durch den folgenden
Codeblock, bzw. dessen Header, zur Zusammenführung des oben erklärten
und geschriebenen Code.

- =:tangle yes= sorgt dafür, dass der Block beim Generieren des Code
  berücksichtigt wird
- =:noweb yes= sorgt dafür, dass NoWeb Referenzen aufgelöst werden.
  Da der =org-mode=-Teilbaum "Prozentual gefülltestes..." in seinem
  ~PROPERTIES~-Drawer =:noweb-ref: fullest-disk= gesetzt hat, führt
  das Auflösen der Referenz hier zum Konkatenieren aller Codeblöcke
  dieses Teilbaumes, und damit zu unserem vollständigen Programm.
- =:shebang #!/bin/sh= lässt =org-mode= die generierte Datei mit der
  angegebenen Zeile beginnen und das executable-Bit setzen.

#+begin_src sh -r  :tangle yes :noweb tangle :shebang #!/bin/sh
    <<fullest-disk>>
#+end_src

#+results:

#  LocalWords:  Kleinstwerkzeug gefülltestes Unixwerkzeuge
#  LocalWords:  Aufrufpipeline