Netbeans 8.1 und git 1.7.9.5

Wenn ich ein neues Projekt in Netbeans anlege und das dann mit git verwalten möchte, patzt Netbeans, wenn die git-Daten in einem anderen Verzeichnis untergebracht werden sollen als dem Stammverzeichnis des Projekts.

Woran das liegt, habe ich noch nicht herausgefunden. Aber zum Glück gibt es einen einfachen Workaround:

1) Projekt in Netbeans anlegen im Verzeichnis /code/projekte/dasNeueProjekt

2) Git-Verzeichnis im Dateimanager anlegen /repos/projekte/dasNeueProjekt

3) Auf der Shell im Projekt-Verzeichnis den Befehl git init --separate-git-dir /repos/projekte/dasNeueProjekt benutzen.

Netbeans “bemerkt”, dass das Projekt unter Versionsverwaltung steht und das git-Plugin läßt sich ganz wie erwartet benutzen.

Veröffentlicht unter Allgemein | Kommentare deaktiviert für Netbeans 8.1 und git 1.7.9.5

MVC als EVA

kurz

Das Design-Pattern Model-View-Controller, kurz MVC, kann man sich als objektorientierte Ausprägung des allgemeinen Ablaufs von Eingabe, Verarbeitung und Ausgabe, kurz EVA, denken. Model bedeutet Verarbeitung, View Ausgabe und Controller Eingabe. Der Controller ist vom Model(-Interface) abhängig und der View beobachtet das Model.

Motivation
———

Ich arbeite gerade an einem Projekt, bei dem ein GUI im Spiel sein wird und natürlich auch Unit-Tests. Die Frage der klugen Aufteilung der Aufgaben stellt sich immer, und im Internet findet sich nur wenig wirklich hilfreiches und verständliches zum Thema MVC.

Beispiel für ein Model: Calcer
——————————

Nehmen wir als Beispiel ein taschenrechnerartiges Dings, genannt Calcer. Ein Calcer-Objekt bekommt als Eingabe zwei ganze Zahlen a und b. Ein Calcer habe eine Methode “calc”, die die Verarbeitung besorgt und vier Methoden, die unterschiedliche Ergebnisse aus a und b geben: getMul, getDiv, getAdd, getSub für Multiplikation, Division, Addition und Subtraktion.

Nebenbei: Wie das Modell, Calcer, seine Aufgabe erledigt, das interessiert hier nicht. Vielleicht googlet es, vielleicht implementiert es eigene Arithmetik-Routinen, vielleicht und wahrscheinlich benutzt es Möglichkeiten der zugrundeliegenden Programmiersprache. Man nennt das “Kapselung”.

Calcer ist ein Beispiel für ein Modell. Es nimmt Eingaben entgegen, aber “wer” die Eingaben macht, woher diese Eingaben kommen, das spielt keine Rolle. Man kann auch sagen: Calcer, das Modell, ist von den Eingaben unabhängig. Das ist gut und gewollt: So kann ich das immer dasselbe Modell benutzen, auch wenn ich unterschiedliche Eingabe-Arten benutze.

Und Calcer ist von Ausgaben unabhängig. Ein Calcer stellt Ergebnisse zur Verfügung. Ob diese Ergebnisse abgerufen werden, das “interessiert” einen Calcer nicht. Die Ergebnisse sind da. Basta.

Beispiele für Eingabe-Arten
—————————

Wenn ein Mensch einen Calcer benutzen möchte, dann wird das entweder mit einem GUI geschehen, oder mittels einer Konsole, beispielsweise der bash. Der Einfachheit halber und ohne Beschränkung der Allgemeinheit soll das reichen.

Für jede gewünschte Eingabe-Art werde ich eine eigene Klasse erschaffen. Hier also einen ConsoleController und einen GuiController. Der ConsoleController wird wohl die eingetippten Daten lesen und weitergeben, nachdem der User “Return” gedrückt hat. Der GuiController könnte zwei Felder haben, für jede Zahl eins und dann noch einen Button, der die Berechnung anstößt.

Eine andere Art ist eine Anfrage/ Nachricht die mittels Netzwerk an einen Server gestellt wird. Da wechseln Details, aber das Prinzip bleibt.

Beispiele für Ausgabe-Arten
—————————

Siehe oben “Beispiele für Eingabe-Arten”. Wer ein GUI benutzt, der möchte dort auch das Ergebnis sehen, entsprechendes gilt für die Konsolieros. Und genau wie oben wird es entsprechende unterschiedliche Klassen geben. Ein ConsoleView wird immer wieder vier Zeilen ausgeben, eine für jedes Ergebnis. Ein GuiView könnte vier Felder enthalten, deren Inhalt nach der Verarbeitung erneuert wird.

Konzept getrennt, Realisierung vereint
————————————–

Gleichgültig, ob mit Konsole oder Fenster gearbeitet wird: Der Mensch vor der Maschine merkt nicht, dass intern unterschiedliche Klassen werkeln, eine, die Eingaben entgegen nimmt, eine andere die verarbeitet, eine dritte, die Ausgaben macht. Er benutzt einen Calcer und freut sich über die Ergebnisse.

Wer kennt wen?
————–

Oben habe ich herausgestellt, dass das Model, Calcer, von Eingaben und Ausgaben unabhängig ist. Es “kennt” weder die Eingabe- noch die Ausgabe-Klassen. Aber irgendwelche Abhängigkeiten müssen bestehen, denn sonst ist keine Zusammenarbeit möglich. Also: Wer kennt wen?
Die Eingabe, sprich der Controller, kennt das Model. Denn der Controller “füttert” das Model mit Daten und “bedient” es, leitet User-Wünsche an das Model weiter. Und das ist auch schon alles.

Und – häh?!?! – wie kommen die Ergebnisse der Verarbeitung in die Ausgabe? Gute Frage, junger Padawan, Du hast gestellt. Einfach die Antwort ist: Observer-Pattern.

Fazit
—–

Im Internet finden sich andere Herangehensweisen an MVC. Mich überzeugt der dargestellte Ansatz wegen minimaler Kopplung und klarer Aufgabentrennung. Offene Fragen bleiben. Wer regelt das Zusammenspiel von Model, View und Controller? Oft ist die Antwort: Der Controller. Aber man kann sich auch ein viertes Element denken, etwa in der Art des Mediator-Patterns. Wer “sorgt” sich um die Validierung der Eingabe? Das Model? Der Controller? Vielleicht ein viertes. Wie kann der Controller eine Meldung an den User machen? Muss er das? Mach’ es halt clever. Aber nicht zu clever.

Veröffentlicht unter Allgemein | Kommentare deaktiviert für MVC als EVA

Frage kennen, Antwort verstehen

In der Philosophologie ist es so, dass es leichter fällt eine Antwort zu verstehen, wenn man die Frage kennt. Wenn man nur mit der Antwort konfrontiert wird, dann erscheint die oft bizzar.

Objektorientierte Programmierung und Objektorientierte Analyse und Design scheinen machen Menschen unnötig, kompliziert, neumodisches Zeugs. “Objektorientiert” ist eine Anwort. Die Frage lautet “Wie bohre ich mir bei der Entwicklung von Software möglichst wenig ins Knie?”.

Veröffentlicht unter Allgemein | Kommentare deaktiviert für Frage kennen, Antwort verstehen

Zettel, Stift, Journal

Um eine Idee zu skizzieren brauche ich Zettel und Stift. Beides trage ich immer bei mir, in der hinteren Hosentasche. Am Ende des Tages übertrage ich die Skizzen in ein gebundenes Journal.

Zettel in der Hosentasche werden schnell unansehnlich oder zerfetzt. Um dem entgegen zu wirken nutze ich (Alt-)Papier, gefaltet wie ein PocketMod. Das bringt Stabilität und Ordnung. Anders als beim PocketMod lasse ich die Mini-Seiten unbeschriftet. Es bietet sich an, Altpapier wiederzuverwenden, weil man bei der PocketMod-Faltung sowieso nur eine Seite des A4-Blattes nutzt. Neben den Skizzen finden auch Termine und Einkaufslisten Platz.

Einen passenden Stift zu finden, ist nicht einfach, denn die meisten sind zu lang. Ein Kuli ist entweder unbequem oder zerbricht. Ein Bleistift ist keine schlechte Wahl, weil die Länge anpassbar ist und er immer funktioniert. Aber die Kohlestriche verschwinden mal schneller, mal langsamer. Im Moment nutze ich Nachfüllmienen für Stabilo Easy Start.

Kladde: A5, blanko oder kariert, 96 Blatt oder ähnliches. Die Seiten sind nummeriert, meistens eigenhändig.

In der Kladde gibt es Einträge, deren Umfang wächst, Beispiele Inhaltsverzeichnis, Glossar und Literaturliste. Das bekomme ich mit einer gängigen Datenstruktur in den Griff: der verketteten Liste. Im Inhaltsverzeichnis steht die erste Seite des Eintrags. Am Ende des Eintrags steht ein Verweis auf die Fortsetzungsseite. Auf der Fortsetzungsseite steht wieder der Titel der Eintrags mit dem Zusatz “(Forts.)”. Beispiel: Glossar auf Seite 5, Fortsetzung auf Seite 15, dann verweist S. 5 auf S. 15, Seite 15 hat den Titel “Glossar (Fort.)” und wird nicht im Inhaltsverzeichnis gelistet.

So hilft Informatik im Alltag. Was ist hier das Ei und was die Henne?

Veröffentlicht unter Allgemein | Kommentare deaktiviert für Zettel, Stift, Journal

Wortfindung und Störung

Für die einen bedeutet der Wortteil “Test”, dass es sich um etwas vorläufiges handelt, das schnell wieder gelöscht werden kann. Testdatenbank, Testklasse, Testfunktion, nach dem Motto “Mal eben ‘was ausprobieren”. In meiner heilen Java-Welt steht “Test” als Abkürzung für JUnit-Test. Der stellt sicher, dass das jeweilige Objekt so funktioniert, wie ich das geplant habe. Und solange es eine Klasse gibt sollte die zugehörende Test-Klasse bestehen.

Blöd, wenn dann jemand meine Klassen und Programme löscht, weil “Stand doch ‘Test’ drauf”. Zum Glück gibt es git :-))) Ich nenne meine Unit-Tests in der Notes-Welt nun “Beweis”. Klingt wichtig ;) Und vermeidet Irritationen.

Ein ganzer Zweig in der philosophischen Diskussion dreht sich um dieses Thema. Ein guter Einstiegspunkt dazu ist Frege’s Aufsatz über Sinn und Bedeutung.

Veröffentlicht unter Allgemein | Kommentare deaktiviert für Wortfindung und Störung

Hase-Igel-Algorithmus

Mein Chef bat mich, Endlosschleifen zu vermeiden, die in einem alten Programm gelegentlich auftauchen, wenn die Daten “unsauber” eingegeben wurden. Die zugrundeliegende Datenstruktur ist eine einfach verkettete Liste.

Im folgenden skizziere ich einen Weg, das zu ermöglichen.

 

 

 

 

Veröffentlicht unter Allgemein | Kommentare deaktiviert für Hase-Igel-Algorithmus

Workshop bei ITWU

Lotus Notes ist ein Software-Paket mit langer Tradition. Ein Ergebnis davon ist, dass man sehr viele Möglichkeiten hat, eine Notes-Anwendung zu erstellen. Zu viele für einen Notes-Noob wie mich. Klar – ich kann programmieren. Aber das ist mehr als nur Quelltext einzutippen. Eine wesentliche Frage ist, wie man ein Projekt am cleversten umsetzt. Und genau da setzte der Workshop bei der ITWU GmbH an.

Eine Programmierer-Weisheit pfeifen die Spatzen vo den Dächern: Wiederhole Dich nicht. Früher habe ich nicht verstanden, wie das effektiv in Notes realisiert werden kann, weil ich gedanklich vor einem Dickicht stand: Multi-Options-Paralyse. Heute bin ich schlauer :-)

Auch für ein Projekt in Notes bietet es sich an, Objekt-Orientierte Analyse und Design durchzuführen. Das Objektmodell kann in LotusScript umgesetzt werden. Wohlgemerkt: Noch sind keine Notes-Dokumente und -Masken im Spiel. In der Business-Logik kommen diese Elemente nicht vor.

Notes-Dokumente kommen erst dann zum tragen, wenn es darum geht, die Daten der Business-Objekte zu speichern. Jedes Business-Objekt hat/ nutzt ein Notes-Dokument, um seine Daten persistent zu machen. Wesentlich ist Kapselung, anschaulich: Business-Klasse A nutzt Business-Klasse B. Beide nutzen Notes-Dokumente als Speicher. Aber NIE darf ein A-Objekt das Notes-Dokument eines B-Objekts nutzen.

Notes-Masken kommen nur als GUI-Elemente für Obacht! Business-Objekte ins Spiel. Die Masken arbeiten nie mit Notes-Dokumenten. So kommt man zu einer “sauberen” Trennung von Datenmodell und dessen Visualisierung. Leider ist es leicht, das falsch zu machen, weil man im Dickicht erkennt, dass Masken und Dokumente zusammengehören.

Ich denke mir das so: Das Objektmodell beschreibt, was wo wie erledigt wird. Speicherung und Visualisierung sind davon unabhängig. In meiner heilen Java-Welt nutze ich vielleicht Hibernate und Eclipses SWT. Und in Notes eben Dokumente und Masken.

Schön, dass auch andere der Meinung sind, dass nur ein fauler Programmierer ein guter ist. Passt zu meinem Credo: Einfach ist besser.

 

Veröffentlicht unter Allgemein | Verschlagwortet mit , | Kommentare deaktiviert für Workshop bei ITWU

DSL ohne antlr

Die Sache mit DSL und XML und wie ich meine Arbeit automatisieren kann, fesselt mich noch immer. Ich habe mich an zwei Sachverhalte erinnert:

1) Es gibt im Standard-Java eine Klasse StringTokenizer. Die leistet in Ansätzen das, was ein Lexer kann. Die api-Doku führte mich zum StreamTokenizer, der etwas leistungsfähiger und flexibler ist.
2) Es gibt ein Entwurfsmuster mit Namen “Interpreter“.

Nun bestimme ich, dass meine DSL so ist, dass das erste Wort in einer Zeile ein Kommando-Name ist und der Rest der Zeile sind die Parameter für das Kommando. Ich brauche also etwas, das jede Zeile passend interpretiert, also das Kommando am Anfang erkennt und daraufhin einen passenden Interpreter findet, dem dann überlassen wird, wie weiter zu verfahren ist.

Java’s StringTokenizer zerlegt jede Zeile. Mein InterpreterBuilder erzeugt mittels Reflection-API einen passenden Interpreter, beispielsweise einen FileExistsPInterpreter wenn die Zeile mit “FileExistsP” beginnt oder einen UnknownCommandInterpreter, wenn kein passender Interpreter gefunden wird. Der Interpreter liest dann – wieder mit Hilfe des StringTokenizer – den Rest der Zeile, bereitet diesen Rest als Parameter für ein FileExistsP-Objekt auf, erzeugt das Objekt und ruft dessen execute-Methode auf.

Das beschriebene Verfahren liegt in diesem tar-gz-Archiv mit falschem Dateinamen, damit WordPress nicht meckert. Es ist ein gepacktes Eclipse-Projekt, die enthaltene jar-Datei muss im Build Path liegen. Startpunkt ist de.aysx.mpfinterpreter.Main. Das wird mit einem Dateinamen aufgerufen, beispielweise so, das die beiliegende Datei “einProgramm.dsl” aufgerufen wird.
NB FileExistsP ist auf das Minimum reduziert: Einen Befehlsnamen und der unabdingbare Parameter. FileCreatedTodayP hat noch “filename=” im Aufruf. Das ist ein Rest vom vorhergehenden und wird überflüssig, wenn das hier beschriebene Verfahren komplett ausformuliert ist.

There is more than one way to do it.

Veröffentlicht unter Allgemein | Kommentare deaktiviert für DSL ohne antlr

DSL statt XML

Das Verfahren in “XML als CodeP” ist toll. Aber es hat einen grossen Nachteil: Das XML wird komplizierter, je umfangreicher die Funktionen sind. Geht das eleganter, ausdrucksstärker, ohne diese vielen spitzen Klammern und “void” und “object” und “dieses ganze Zeugs”P

Es wäre prima, wenn es nur eine Textdatei wie diese hier braucht. Sie zeigt ohne überflüssigen Schnickschnack auf, welcher Befehl mit welchem Parameter aufzurufen ist. Das ist vieeeel übersichtlicher als das XML. Was ist zu tun?

Ich schreibe eine Grammatik für antlr3 und zwar diese hier. antlr erzeugt daraus Java-Klassen. Eine davon, der Parser, hat eine Main-Methoden und bekommt beim Aufruf den Dateinamen der Textdatei. Fertig.

Fertig? Noch lange nicht. Denn so, wie ich es hier zeige, fehlen die Implementierungen, Fehlerbehandlung, Konfigurationen etcpp. Aber das Prinzip sollte deutlich geworden sein: Ich erstelle eine “domain specific language”.

Nachteil? Für jeden neuen Befehl muss ich die Grammatik erweitern und mit antlr den Lexer und Parser neu zusammensetzen. Ist es das wert?

Veröffentlicht unter Allgemein | Kommentare deaktiviert für DSL statt XML

XML als CodeP

Wie bemerke ich, dass die ausserordentlich wichtige Datei xyz nicht vorhanden ist? Wie bemerke ich, dass eine andere Datei ABC heute nicht neu erzeugt wurde? Wie bemerke ich, dass sich ein Wert in einer SQL-Datenbank ändert? Diese und ähnlich Fragen stellen sich immer wieder.

SCOM könnte hier Antworten geben und die Aufgabe fiele daher in den Beritt der Kollegen von der Systemtruppe. Aber mein Chef möchte kurze Wege: Hausinterne Programme erzeugen und verändern Dateien. Also kümmert sich das Programmier-Team um deren Überwachung.

Skizze
Meine Idee dazu ist die: Ich schaffe eine Java-Klasse, die prüfen kann, ob eine Datei existiert. Für n Prüfungen jeweils unterschiedlicher Dateien instanziiere ich diese Klasse n mal mit jeweils unterschiedlichen Parametern. Ich schaffe eine weitere Java-Klasse, die prüfen kann, ob das Erzeugungsdatum einer Datei passt. Für n Prüfungen … s.o. Und ich schreibe eine weitere Java-Klasse für die Prüfung in Zusammenhang mit einer SQL-Datenbank.
Allgemein formuliert: Jede Prüfung wird in einer getrennten Java-Klasse abgebildet.

Wie erzeuge ich die Prüfungs-Objekte?
Wenn ich die Objekte jeweils mit dem new-Operator erzeuge, dann handel ich mir einen Nachteil ein: Jedes Mal, wenn eine neue Prüfung dazu kommt, muss ich den Code verändern, der die Objekte erzeugt. Das ist ein No-Brainer und zieht Verwaltungsaufwand nach sich: Dokumentation, Versionsverwaltung, Deployment. Mir ist es lieber, den Code unberührt zu lassen und nur eine Konfiguration zu ändern.

Gibt es eine andere Möglichkeit, die Objekte zu erzeugen? Ja.
Java macht es möglich, ein Objekt in XML-Form abzubilden. Und der umgekehrte Weg, man bemerke die Symmetrie, ist auch gangbar: Wenn ein entsprechender XML-Text vorhanden ist, dann kann daraus ein Objekt erzeugt werden. Wenn ich den XML-Text verändere, dann verändere ich das potentielle Objekt. So kann ich n unterschiedliche XML-Texte erzeugen, die sich jeweils beispielsweise nur um einen Pfadnamen der zu prüfenden Datei unterscheiden. Das ist prima, weil es eine Konfiguration ist.

Ein Weg, den ich nicht gehe: Es gibt eine Liste mit Dateinamen, für die geprüft werden soll, ob die entsprechenden Dateien vorhanden sind, und ein Programm A liest diese Liste und führt die Prüfungen durch. Es gibt eine weitere Liste mit Dateinamen für die Datumsprüfung und ein Programm B, das diese Liste liest und entsprechende Antworten gibt. Und so weiter für alle geforderten Prüf-Typen.
Dieser Ansatz ist nicht komfortabel, weil ich mit mehr als einer Konfigurationsdatei hantieren muss. Mein Ansatz erlaubt mir eine einzelne Datei, die die Prüfungen steuert.

Code
… ohne Drumherum, damit die Idee deutlich wird.

Command ist sehr allgemein.

FileExistsP war der Ausgangspunkt der Überlegungen.

FileCreatedTodayP ist so ähnlich wie FileExistsP

FileCommand gibt es, weil bestimmter Code sich wiederholt.

CommandList ist die Klammer, die die Commands zusammenhält. Ich brauche so aus der XML-Datei nur ein Objekt zu lesen, weil die darin enthaltenen Objekte ebenfalls erzeugt werden.

Main startet die Prüfungen, die in einer Datei konfiguriert sind.

Hier ist ein Beispiel für eine solche XML-Datei.

Decoder zeigt mir, wie die XML-Darstellung eines Objekts ist.
Nur für den Fall, dass ich das nicht im Kopf ausrechnen kann ;)

Eine Jar-Datei inklusive Quelltext gibt es hier.

Die Prüfung in Zusammenhang mit der SQL-Datenbank habe ich nicht ausformuliert. Fleissarbeit. Werde ich vermutlich implementieren, wenn die Handarbeit mich bei der täglichen Arbeit ausreichend nervt.

Das Thema “Zeitplanung der Ausführung” könnte interessant werden. Vielleicht will ich nicht jede Prüfung bei jedem Programmdurchlauf ausführen. Die oben genannten Prüfungen führe ich jeden Morgen aus und nur einmal am Tag. Den Zustand eines SQL-Datensatzes möchte ich vielleicht im 5-Minuten-Takt prüfen. Es wird nie langweilig.

An die Stelle des System.out.println wird etwas anders treten: Email schreiben, Eintrag in Logdatei schreiben oder ähnliches. Konfigurierbar, natürlich! Und natürlich reicht ein Ausdruck auf der Console nicht als Fehlerbehandlung.

Hier erledigt der Code in XML-Form Überwachungsaufgaben. Aber das ist nicht wesentlich. Jede Programmierung kann so abgebildet werden. Und es wird auch gemacht, Beispiel ant, das mich auf die Idee gebracht hat.

Warum das “P” im Namen? Weil ein P ein bisschen aussieht wie ?.

Veröffentlicht unter Allgemein | Kommentare deaktiviert für XML als CodeP