Liebe Entwickler,
nach unserem Vorschlag der Änderungen zu den Coding Guidelines, habe ich nun die angebrachten Punkte eingearbeitet. Ihr findet im Anhang das neue Dokument. Wenn es eurerseits keine Einwände gibt, werde ich dieses an den Kitodo Vorstand zur Absegnung schicken. Ab diesem Zeitpunkt werden wir nach den neuen Guidelines entwickeln.
Rückmeldungen bitte bis zum 11.01.2017.
Liebe Grüße
Kathrin Huber
Kathrin Huber
Digitale Bibliothek
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
Abteilung IT, Referat 2.1
01054 Dresden
Besucheradresse: Zellescher Weg 18, 01069 Dresden
Tel.: +49 351 4677 242 | Fax: +49 351 4677 711
E-Mail: kathrin.huber(a)slub-dresden.de
www.slub-dresden.de<http://www.slub-dresden.de/> <mailto:jens.bemme@slub-dresden.de> | www.kitodo.org/
Liebe Entwickler Kollegen,
zum Start in unser Refactoring möchten wir den bestehenden Code gern mittels eines Formatters an die Coding Guidlines anpassen.
Wir haben dafür die Coding Guidlines noch einmal genauer unter die Lupe genommen und möchten euch ein paar kleine Änderungen vorschlagen.
Wir hätten dazu gern ein Feedback von euch und würden bei einer mehrheitlichen Zustimmung bereits mit aktualisierten Coding Guidlines arbeiten, in dem Vertrauen darauf, dass diese daraufhin auch von der Mitgliederversammlung angenommen werden.
Hier unsere Änderungsvorschläge:
Die Zeile:
"Der Quellcode muss kompatibel zum Java6-Standard sein."
ändern in:
"Der Quellcode muss kompatibel zum Java7-Standard sein."
Erklärung:
Java 7 ist mittlerweile etabliert genug, dass es von den meisten Systemen unterstützt wird. Wir möchten auch die Vorteile dieser Version nutzen.
-------------------------------
Hinzufügen des Absatzes:
"Der Quellcode muss mit dem mitgelieferten Codeformatter formatiert sein"
Erklärung:
Das Nutzen verschiedener Codeformatter führt in manchen Fällen zu einer Vielzahl von Änderungen in der commit history. Im schlimmsten Fall werden Dateien commited, die keine funktionalen Änderungen haben, aber vom Entwickler formatiert wurden und wegen abweichender Zeilenumbrüche als Änderung eingehen.
Insbesondere das Reviewen von Code wird dadurch deutlich erschwert.
---------------------------------
Die Zeile:
"Exceptions (error) müssen immer aufgefangen und geeignet behandelt, mindestens aber im Log registriert werden. Letzteres gilt auch für unkritische Programmfehler (warning) und Hinweise (notice)."
ändern in:
"Exeptions (error) müssen immer geeignet behandelt werden und gegebenenfalls bis zu der Stelle durchgereicht werden, an der dies möglich ist. Sie müssen immer im Log registriert werden. Letzteres gilt auch für unkritische Programmfehler (warning) und Hinweise (notice)."
Erklärung:
Errors sollten nur gefangen werden, wenn sie entsprechend behandelt werden können. An jeder Stelle jeden beliebigen Fehler zu fangen führt im schlimmsten Fall dazu, dass Methoden fehlerfrei durchlaufen, ohne aber das zu tun, was sie versprechen. Stattdessen sollten Fehler an aufrufende Methoden kommuniziert werden, damit diese entsprechende Schritte einleiten können (z.B. erneutes aufrufen, eventuell mit abweichenden Parametern, oder Ausgabe im Frontend "fehlerhafte Eingabe")
---------------------------
Die Zeile:
"Jede Klasse, jede Methode und jede Klassenvariable ist im phpDoc- bzw. JavaDoc -Standard zu dokumentieren. Zusätzlich sollte im Quellcode ausführlich von Zeilenkommentaren zur Dokumentation Gebrauch gemacht werden."
ändern in:
"Jede Klasse, jede öffentliche Methode und jede Klassenvariable ist im phpDoc- bzw. JavaDoc-Standard zu dokumentieren. Der Quellcode sollte durch sprechende Bezeichnungen und kleine Methoden weitestgehend selbsterklärend sein. Zur Erläuterung von Funktionalität sollte im Quellcode von Zeilenkommentaren Gebrauch gemacht werden."
Erklärung:
Die übermäßige Verwendung von Kommentaren führt erfahrungsgemäß leider dazu, dass Quellcode geändert wird, die Kommentare aber nicht, so dass Kommentar und tatsächliche Funktion voneinander abweichen. Im schlimmsten Fall ist dies nicht offensichtlich und ein Fehlverhalten des Codes wird angenommen oder nicht bemerkt.
Es ist anzustreben, dass Javacode durch geeignete Variablen- und Methodennamen weitestgehend selbsterklärend ist und auf Zeilenkommentare verzichtet werden kann.
--------------------------------------
Die Zeile:
"Die Zeichenkodierung ist generell UTF8, Zeilenumbrüche werden im Unix-Format kodiert, Einrückungen erfolgen mit Tabs. Jede Datei ist mit einem Zeilenumbruch abzuschließen."
ändern in:
"Die Zeichenkodierung ist generell UTF8, Zeilenumbrüche werden im Unix-Format kodiert, Einrückungen erfolgen mit Leerzeichen (4 Leerzeichen pro Einrückung). Jede Datei ist mit einem Zeilenumbruch abzuschließen."
Erklärung:
Der überwiegende Teil des Codes wird mit Spaces eingerückt. Nur neuere Codeteile sind mit Tabs eingerückt, da die letzten Coding Guidelines dies vorschrieben.
Verschiedene Text Editoren oder IDE's können eine verschiedene Anzahl von Leerzeichen pro Tab konfigurieren. Damit kann der Source Code unleserlich werden und ist vor allem nicht einheitlich.
------------------------------------------
Die Zeile:
"Für Schleifen sollten Java5-Konstrukte für typsichere Listen benutzt werden."
ändern in:
"Für Schleifen sollten Konstrukte für typsichere Listen benutzt werden."
Erklärung:
Das diese Konstrukte für typsichere Listen mit Java-5 eingeführt wurden kann man als Randnotiz stehen lassen, können aber in den Guidelines selber zur Verwirrung führen. Da der Code Java-7 kompatibel werden soll, sollte es selbstverständlich sein, auch die bis dato verfügbaren effizientesten Mittel und Wege, die Java-7 bietet zu nutzen.
Im Anhang findet ihr die angepassten Coding Guidelines, wie sie zur Abstimmung an die Mitgliederversammlung gehen würden.
Liebe Grüße
Kathrin Huber
Kathrin Huber
Digitale Bibliothek
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
Abteilung IT, Referat 2.1
01054 Dresden
Besucheradresse: Zellescher Weg 18, 01069 Dresden
Tel.: +49 351 4677 242 | Fax: +49 351 4677 711
E-Mail: kathrin.huber(a)slub-dresden.de
www.slub-dresden.de<http://www.slub-dresden.de/> <mailto:jens.bemme@slub-dresden.de> | www.kitodo.org/
Liebe Entwickler,
im Rahmen unseres Refactorings, werden wir viel Funktionalität in Maven Module auslagern.
Dafür haben wir nun Vorgaben erarbeitet, die für jede Modulentwicklung gelten.
Ihr findet diese im GitHub Wiki<https://github.com/kitodo/kitodo-production/wiki/Structure-of-modules>.
Liebe Grüße
Kathrin Huber
Kathrin Huber
Digitale Bibliothek
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
Abteilung IT, Referat 2.1
01054 Dresden
Besucheradresse: Zellescher Weg 18, 01069 Dresden
Tel.: +49 351 4677 242 | Fax: +49 351 4677 711
E-Mail: kathrin.huber(a)slub-dresden.de
www.slub-dresden.de<http://www.slub-dresden.de/> <mailto:jens.bemme@slub-dresden.de> | www.kitodo.org/
Liebe Entwickler,
aufgrund des gestarteten DFG Projektes zur Weiterentwicklung von
Kitodo.Production und damit eingehend auch Neuanstellungen von
Entwicklern aber auch um neuen Community Entwicklern eine Handreichung
über die Entwicklung im Kitodo.Production Community Projekt zu geben,
habe ich einmal die wichtigsten Punkte zusammen gefasst und ins GitHub
basierende Wiki unter
https://github.com/kitodo/kitodo-production/wiki/Hinweise-f%C3%BCr-Entwickl…
gestellt. Fragen und Kommentare entweder über die Liste oder direkt an
mich. Die Bearbeitung direkt im GitHub Wiki ist auch möglich, jedoch
sollten fundamentale Änderungen bitte vorher abgesprochen werden.
Vielen Dank und viele Grüße
Henning Gerhardt
--
Henning Gerhardt
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
Abt. Informationstechnologie (IT), Ref. Digitale Bibliothek
01054 Dresden
Besucheradresse: Zellescher Weg 18, 01069 Dresden
Tel.: +49 351 4677 227 | Fax: +49 351 4677 711
E-Mail: henning.gerhardt(a)slub-dresden.de
www.slub-dresden.de
Liebe Kitodo Entwickler,
für das bevorstehende Refactoring im Rahmen des DFG Projektes gibt es
noch eine Änderung, die die Basis dafür sein wird: Die Umstellung des
bisherigen Bauprozess von ant mit seiner beliebigen Struktur auf einen
Maven basierenden Bauprozess und der entsprechend typischen Struktur
eines Maven Projektes.
Die dafür notwendigen Anpassungen finden aktuell in einem
eigenständigen Branch [1] statt und werden nach Abschluss der Arbeiten
in den master Branch von Kitodo.Production integriert.
Viele Grüße
Henning Gerhardt
[1] https://github.com/Basti890/kitodo-production/tree/maven_structure
Liebe Kitodo Entwickler,
sicher wartet ihr schon gespannt auf das Ergebnis unserer Codeanalysen und die Entscheidung, wie es mit Kitodo weiter gehen soll.
Ich freue mich euch mitteilen zu können, dass wir zu einer Entscheidung kommen konnten.
Unter Berücksichtigung aller Vor- und Nachteile sind wir zu dem Schluss gekommen, dass ein Refactoring im Rahmen der innerhalb des Projekts zur Verfügung stehenden Ressourcen den größten Mehrwert bietet.
Wie sind wir dabei vorgegangen?
Nach mehreren Ansätzen aus verschiedenen Richtungen (Systemarchitektur erstellen, Technologieanalysen, Anforderungsanalyse...) haben wir entschieden, dass wir erst nach einem tatsächlichen Refactoring wirklich abschätzen können, welche Variante geeigneter ist.
Die Herausarbeitung ausgewählter Module aus dem bestehenden Code erwies sich als durchaus machbar. Manche Teile müssen so oder so neu gebaut werden, da erschien der Overhead einer Neuimplementierung unverhältnismäßig gegenüber der Herauslösung der Funktionalität in eigene Module. Die teilweise schlechte Codequalität lässt sich durch Refactoring beheben und beeinflusst nicht die Modularisierung.
Der Funktionsumfang von Kitodo muss von außen (nicht aus dem Code heraus) bestimmt werden. Wir gehen nun den Weg von einer vollumfänglichen Anwendung einzelne Funktionalitäten herauszuarbeiten und nicht gebrauchte Stücke zu entfernen. Die Gefahr Funktionalität unbewusst "auszubauen" (oder beim Neubau zu vergessen) besteht damit so oder so, ist im Falle eines Refactorings aber deutlich geringer.
Uns erschien die Tatsache einer sich entwickelnden Anwendung, die aber von Anfang an jegliche Funktionalität bietet, in Anbetracht der begrenzten Projektzeit, als sichererer Weg im Vergleich zu einem Neubau, der im schlimmsten Fall am Ende der zwei Jahre noch nicht den vollen Funktionsumfang besitzt.
Es wird nun in Zukunft, insbesondere in den nächsten Monaten, zu einigen grundlegenden Änderungen im Code kommen.
Wir werden euch über den Fortschritt auf dem Laufenden halten.
Liebe Grüße
Kathrin Huber
Kathrin Huber
Digitale Bibliothek
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
Abteilung IT, Referat 2.1
01054 Dresden
Besucheradresse: Zellescher Weg 18, 01069 Dresden
Tel.: +49 351 4677 242 | Fax: +49 351 4677 711
E-Mail: kathrin.huber(a)slub-dresden.de
www.slub-dresden.de<http://www.slub-dresden.de/> <mailto:jens.bemme@slub-dresden.de> | www.kitodo.org/
Liebe Kitodo Entwickler,
durch den Start des DFG Projektes zur Weiterentwicklung von
Kitodo.Production ergeben sich Änderungen in der Branch-Struktur in GitHub.
Diese Änderungen werden in gleicher Form in den 3 GIT Repos
- Kitodo.Production [1]
- Kitodo.UGH [2]
- Kitodo.ContentServer [3]
erfolgen. Der Plan sieht vor, dass die Weiterentwicklung im Rahmes des
DFG Projektes im "master" Branch erfolgt. Im neuen Branch "2.x" wird die
kommende Version 2.0.0 und die darauf basierenden Versionen der
jeweiligen Teilprojekte von Kitodo.Production/UGH/ContentServer erfolgen.
Diese Änderung wird in den nächsten Tagen stattfinden. Ich werde vorher
die noch offenen Pull-Requests, die in beiden Branches Verwendung finden
noch vorher mergen.
Zukünftig ist darauf zu achten, dass die Pull-Requests gegen die jeweils
korrekte Entwicklung gestellt werden.
Viele Grüße
Henning Gerhardt
[1] https://github.com/kitodo/kitodo-production
[2] https://github.com/kitodo/kitodo-ugh
[3] https://github.com/kitodo/kitodo-contentserver
--
Henning Gerhardt
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
Abt. Informationstechnologie (IT), Ref. Digitale Bibliothek
01054 Dresden
Besucheradresse: Zellescher Weg 18, 01069 Dresden
Tel.: +49 351 4677 227 | Fax: +49 351 4677 711
E-Mail: henning.gerhardt(a)slub-dresden.de
www.slub-dresden.de
Liebe Kolleginnen und Kollegen,
vielen Dank für das große Interesse und die zahlreichen Anmeldungen zum Kitodo-Workshop am kommenden Donnerstag! Mit über 30 Teilnehmerinnen und Teilnehmern werden wir zwar etwas zusammenrücken müssen, dafür aber auch auf einen umso größeren Erfahrungs- und Ideenschatz zurückgreifen können. In diesem Sinne auch ein besonderer Dank an alle Teilnehmer, die sich bereiterklärt haben, ihre Entwicklungswünsche, Anregungen oder Erfahrungen in Form von Impulsreferaten einzubringen. Daraus ergibt sich ein vielseitiges Programm, das wir grob in drei Themenblöcke gegliedert haben:
13:00 Uhr - Begrüßung, Einführung
Themenblock Infrastruktur/Datenmanagement
13:10 Uhr - Kitodo-Anbindung an Aleph/SISIS-Katalogsysteme (Michael Voss, Bibliothek der Humboldt-Universität)
13:35 Uhr - Generische Datenschnittstellen für Kitodo (Jens Lazarus, Universitätsbibliothek Leipzig)
14:00 Uhr - Fedora als Content Repository für Kitodo (Sebastian Meyer, SLUB Dresden)
14:25 Uhr - Pause
Themenblock OCR/OLR
14:40 Uhr - Das OCR-D-Projekt und die mögliche Rolle von Kitodo (Kay-Michael Würzner, Berlin-Brandenburgische Akademie der Wissenschaften)
15:05 Uhr - OCR und Strukturerkennung mit docWorks und Kitodo (Daniel Lanz, Content Conversion Specialists GmbH)
15:30 Uhr - Anbindung des OCR-Postkorrektur-Tools PoCoTo an Kitodo (Florian Fink, Centrum für Informations- und Sprachverarbeitung, LMU München)
15:55 Uhr - Pause
Themenblock Medientypologische Erweiterung
16:10 Uhr - Wünsche zu Workflow und Erschließung (Andreas Schlüter, Herzogin Anna Amalia Bibliothek Weimar)
16:35 Uhr - Handschriften und Audio/Video (Jens Lazarus, Universitätsbibliothek Leipzig)
17:00 Uhr - Fotos und Karten (André Hohmann, SLUB Dresden)
Die Vorträge sollen dabei die jeweiligen Zeitslots nicht vollständig ausfüllen, sondern mehr der Einführung und Anregung für eine anschließende, offene Diskussion dienen. Das Ziel des Workshops ist es schließlich, möglichst viele Perspektiven kennenzulernen und eine gemeinsame Idee davon zu entwickeln, welche Rolle(n) Kitodo in Zukunft spielen soll und welche - vor allem technischen - Anforderungen damit einhergehen.
Die Ergebnisse des Workshops wird das Projektteam im Anschluss auswerten und natürlich auch all denjenigen zugänglich machen, die am Donnerstag nicht selbst teilnehmen können.
Die Veranstaltung findet im Talleyrand-Zimmer [1] in der Zentralbibliothek im Zelleschen Weg 18 statt.
Ich wünsche allen Teilnehmerinnen und Teilnehmern eine gute Anreise und freue mich, Sie am Donnerstag in Dresden begrüßen zu dürfen!
Viele Grüße
Sebastian Meyer
[1] 3d.slub-dresden.de/viewer?p=3&l=3263
--
Sebastian Meyer
Stabsstelle Digitale Bibliothek
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
Abteilung IT, Referat Digitale Bibliothek
01054 Dresden
Besucheradresse: Zellescher Weg 18
Tel.: +49 351 4677 206 | Fax: +49 351 4677 711
E-Mail: sebastian.meyer(a)slub-dresden.de<mailto:sebastian.meyer@slub-dresden.de>
http://www.slub-dresden.de<http://www.slub-dresden.de/>
Liebe Kolleginnen und Kollegen,
wie Sie wissen, beginnt dieser Tage das DFG-Projekt zur Konsolidierung und Weiterentwicklung von Kitodo.Production. An der SLUB konnten - wenn auch mit leichter Verzögerung - alle Personalstellen zum 1.10. mit vielversprechenden neuen Kolleginnen und Kollegen besetzt werden, gleiches gilt für die Nordakademie Elmshorn. Und auch die Partner in Hamburg und Berlin halten verabredungsgemäß bereits Ausschau nach geeignetem Projektpersonal.
Wie schon auf der Mitgliederversammlung und zu anderen Gelegenheiten erwähnt, möchten wir die Zukunft von Kitodo.Production so transparent wie möglich gestalten und deshalb auch Ihre Wünsche und Anregungen hören. Zwar müssen wir natürlich in erster Linie den von der DFG bewilligten Projektplan erfüllen (zu dem Sie im Vorfeld der Beantragung bereits beitragen konnten), aber dieser lässt uns stellenweise Freiheiten, die wir gerne gemeinsam mit Ihnen gestalten möchten.
Wir möchten Sie deshalb gerne am 13.10. ab 13 Uhr an die SLUB nach Dresden einladen, um mit uns gemeinsam darüber zu diskutieren, wie Sie sich die Architektur von Kitodo in Zukunft vorstellen. Der Fokus soll auf der Workflowgestaltung und dem Zusammenspiel mit anderen Services und Tools liegen.
Von den Kitodo-AnwenderInnen möchten wir deshalb gerne wissen, wie Sie Kitodo.Production in Ihren Digitalisierungsworkflow eingebettet haben. Welche Schnittstellen zu anderen Systemen wie etwa Katalogen oder OCR nutzen bzw. vermissen Sie? Wo mussten Sie Zugeständnisse an Kitodo.Production machen, obwohl Sie den Workflow eigentlich gerne anders organisiert hätten? Welche Funktionalitäten fehlen Ihnen vielleicht generell noch - egal ob in Kitodo oder als Tool eines Drittanbieters? Und welche Medienarten bearbeiten Sie aktuell in Kitodo und welche guten/schlechten Erfahrungen haben Sie damit gemacht?
Von den Anbietern von Services und Tools erhoffen wir uns dagegen Hinweise und Anregungen, wie Sie sich die Anbindung Ihrer Dienste an Kitodo wünschen würden. Welche Schnittstellen und Austauschformate erwarten Sie von Kitodo und welche bieten Sie im Gegenzug an? Wie könnte eine Integration etwaiger Benutzeroberflächen aussehen? Wäre ein zentrales Single-Sign-On für Sie relevant oder von Interesse? Gibt es andere Steuerungsaufgaben, die Kitodo wahrnehmen könnte oder sollte?
Diese und andere Fragen möchten wir gerne gemeinsam diskutieren und Ihre Anregungen sammeln. In der Folge wird das Projektteam dieses Feedback auswerten und soweit möglich in den Entwicklungsplan einfließen lassen. Auch wenn wir sicher nicht alle Anregungen in den ohnehin bereits sehr ambitionierten Projektplan aufnehmen können, möchten wir doch zumindest sicherstellen, dass wir uns die Möglichkeiten offenhalten, diesen Hinweisen später noch zu folgen.
Diese Mail dient erst einmal als Vorankündigung, damit Sie sich den Termin 13.10. notieren und freihalten können. Ein Vorschlag zur Tagesordnung und dem zeitlichen Ablauf wird noch innerhalb des Projektteams abgestimmt und geht Ihnen dann zu. Ich würde mich freuen, wenn Sie mir mitteilen könnten, ob und mit wie vielen Personen Sie teilnehmen werden, damit ich die Räumlichkeiten entsprechend planen kann.
Viele Grüße
Sebastian Meyer
--
Sebastian Meyer
Stabsstelle Digitale Bibliothek
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
Abteilung IT, Referat Digitale Bibliothek
01054 Dresden
Besucheradresse: Zellescher Weg 18
Tel.: +49 351 4677 206 | Fax: +49 351 4677 711
E-Mail: sebastian.meyer(a)slub-dresden.de<mailto:sebastian.meyer@slub-dresden.de>
http://www.slub-dresden.de<http://www.slub-dresden.de/>
