Das Blog-Netzwerk der Staatsbibliothek zu Berlin – Beiträge für Forschung und Kultur

Werkstattgespräch zu den Kalligrafischen Druckschriften Hermann Zapfs am 7.6.

Wissenswerkstatt
Kalligrafische Druckschriften Hermann Zapfs – von “Virtuosa” bis “Zapfino”
Werkstattgespräch mit Dr. Nikolaus Weichselbaumer, Johannes Gutenberg-Universität Mainz

Dienstag, 7. Juni
18.15 Uhr
Konferenzraum 4, Haus Unter den Linden (Eingang über Dorotheenstraße 27)
Treffpunkt in der Eingangshalle (Rotunde)

Eintritt frei, Anmeldung erbeten

 

Hermann Zapf (1918-2015) war einer der einflussreichsten Kalligrafen, Buch- und Schriftgestalter des 20. Jahrhunderts. Sein Werk überspannt mehr als sieben Jahrzehnte, in denen er für alle Schrifttechnologien der Druckgeschichte gearbeitet hat – vom Bleisatz bis zur modernen Font-Datei. Eine zentrale Rolle in diesem Oeuvre nehmen kalligrafische Schriften ein, die für Gestalter durch ihre ausladenden und unregelmäßigen Formen eine besondere Herausforderung darstellen. Der Vortrag stellt Zapfs wichtigste kalligrafische Schriftentwürfe in die Traditionslinien der Typographiegeschichte und rekonstruiert auf Basis erhaltener Entwurfszeichnungen und ergänzender Quellen Zapfs Arbeitstechniken. Besondere Aufmerksamkeit liegt auf der Bedeutung von Technologie für die Formgebung von Schriften.

Eine Veranstaltung aus der Reihe “Die Materialität von Schriftlichkeit

Prima zum Imprimatur: Publikationsberatung für Promovierende

Nicht zuletzt die mehr als 100 strukturierten Graduiertenprogramme, die das Portal Doctoral Programs in Berlin verzeichnet, machen die Hauptstadt mit ihren vier großen Universitäten und zahllosen Forschungseinrichtungen zu einem beliebten Pflaster für Promotionswillige. Da aber der Weg zum Doktorhut nicht selten schmerzhaft hart gepflastert ist – bekanntlich geht es ja immer nur per aspera ad astra – , sind informationspraktische “Blasenpflaster” auch in den Graduiertenschulen und -kollegs gerne willkommen. Und in genau dieser Absicht hat die Staatsbibliothek zu Berlin bereits vor einiger Zeit in ihrer Wissenswerkstatt ein zielgruppenspezifisches Veranstaltungsformat zum wissenschaftlichen Publizieren für Promovierende entwickelt oder – um im Bild zu bleiben – zusammengeschustert. Dieses möchte dazu beitragen, drückende Hemmschuhe aufzuschnüren und Sie möglichst leichtfüßig auf die letzte Etappe zur Erlangung Ihres akademischen Ritterschlags zu schicken. Denn erst mit der fristgerechten Veröffentlichung der Dissertationsschrift – darin sind sich die Promotionsordnungen aller Fakultäten einig – hat das Promotionsverfahren seinen formalen Endpunkt erreicht. Schließlich muss sich Ihre eigenständige Forschungsleistung, um überhaupt als solche gelten zu können, nicht nur in der Disputation – mithin im Kreuzverhör einer universitätsinternen Fachöffentlichkeit – behaupten, sondern später auch im Säurebad von Wissenschaftsdiskurs und Plagiatserkennungssoftware bestehen.

Konkret versuchen wir im Rahmen unseres quartalsweise angebotenen zweiteiligen Workshops Publish or Perish!? Wissenschaftliches Publizieren für Promovierende, Ihnen einige Tipps zur strategischen Wahl des für Sie „richtigen“ Publikationsorts zu geben – sei dieser nun möglichst reputationsförderlichen oder vielleicht besonders kostengünstig –, den Paragraphendschungel des Verlagsvertragsrechts zu lichten, juristische Fragen bei der Nutzung von Bildern zu klären und Ihnen die Akquise von Druckkostenzuschüssen zu erleichtern. Mit Blick auf den gegenwärtigen Strukturwandel der Wissenschaftskommunikation und die daraus resultierende Vervielfachung neuer Publikationsformen zielt Publish or Perish!? zugleich darauf, die Felder von Open Access, Forschungsdatenmanagement und (alternativer) Bibliometrie zumindest in groben Zügen zu kartieren.

Allerdings legt es gerade die erst kürzlich angesprochene neue Unübersichtlichkeit des wissenschaftlichen Publikationsmarkts nahe, mit einer Öffnung dieses Veranstaltungsformats zu experimentieren, zumal die Staatsbibliothek zu Berlin bei der Konzeption innovativer Beratungsangebote ohnehin im Netzwerk Informationskompetenz Berlin/Brandenburg mit zahlreichen anderen wissenschaftlichen Bibliotheken kooperiert. Im Rahmen dieser regionalen Zusammenarbeit haben wir daher das Programm von Publish or Perish!? in selbstständige Module gesplittet, um den Aspekt der Literaturverwaltung erweitert und mit unseren Berliner Partnerbibliotheken an der Freien, Technischen und Humboldt-Universität vereinbart, die inhaltliche Verantwortung für die einzelnen Veranstaltungen zu verteilen – und zwar in Abhängigkeit der Kompetenzschwerpunkte der jeweiligen Einrichtung. Klar, dass beispielsweise der Beitrag zum Forschungsdatenmanagement insofern geradezu zwingend von den Universitätsbibliotheken der Technischen Universität sowie der Humboldt-Universität zu leisten ist, haben doch beide Einrichtungen nicht nur vielfältige Beratungsservices (HU | TU) in diesem Bereich aufgebaut, sondern darüber hinaus auch technische Infrastrukturen – darunter institutionelle Forschungsdatenrepositorien sowie entsprechende disziplinäre Angebote für die historische Linguistik oder die Akustikwissenschaften.

Um dem gemeinsamen Vorhaben einen angemessenen Rahmen zu geben und der rasant zunehmenden Bedeutung von digitalen Informationsinfrastrukturen für den Forschungsprozess gerecht zu werden, eröffnet Prof. Dr. Reinhard Förtsch, IT-Direktor des auf den Feldern von eResearch und Open Science dynamisch agierenden Deutschen Archäologischen Instituts, die Veranstaltungsreihe mit dem Keynote-Vortrag Dissertation als empfohlene Insellösung? Individualismus versus Infrastruktur.

Seien Sie also recht herzlich eingeladen, zwischen 15. Juni und 11. Juli an der insgesamt sechsteiligen Veranstaltungsreihe für Promovierende Lost in Dissertation? Von der Literaturverwaltung bis zur Publikation teilzunehmen – ganz gleich, ob durchgängig oder gezielt zu einzelnen Terminen. In jedem Fall aber freuen wir uns schon auf Sie und hoffen, dass Ihre Dissertation mit Hilfe unserer bibliothekarischen List von einer Last zur reinen Lust werden wird.

Microservices, Widerstandsfähigkeit

Widerstandfähigkeit eines Microservices Systems in Bezug auf Serviceausfälle oder Netzwerklatenz war ein wichtiger Aspekt, welchen wir in unserem Microservices Projekt eingehend untersuchen wollten. Daher freue ich mich dieses Thema und unsere Erfahrungen in unserer Blogserie etwas eingehender beleuchten zu können.

Widerstandsfähig bezieht sich hierbei auf die Client Anwendung, welche die einzelnen nachgelagerten Microservices verwendet. Dieser Begriff meint dabei, dass die Client Anwendung auch im Fall von Netzwerk- bzw. Serviceausfällen nicht blockiert und immer noch durch den Anwender verwendet werden kann. Blockieren kann die Anwendung zum Beispiel, wenn diese einen Microservice verwendet, welcher sehr viel Zeit benötigt, um eine Antwort im Netzwerk bereit zu stellen. Warum dieser Microservice nicht schnell genug antwortet, spielt bei dieser Betrachtung keine Rolle. Die Client Anwendung wartet solange bis entweder die Antwort eintrifft oder aber ein zuvor definierter Timeout einen Fehler erzeugt. Eine hohe Wartezeit einer Anfrage kann bei starker Verwendung der Client Anwendung dazu führen, dass immer mehr Anfragen der Nutzer das System immer stärker blockieren. Ein Blockieren der Client Anwendung kann aber auch durch eine Überlastung des Netzwerks ausgelöst werden. Die Client Anwendung fühlt sich in solchen Fällen für den Nutzer träge und langsam an. Im Falle von Webanwendungen verlässt der Nutzer in der Regel dann sehr schnell die Seite.

 

Als Lösung für solche Situationen bietet der Netflix OSS das Projekt Hystrix, als sogenannte „Circuit Breaker“ Bibliothek, an. Ein „Circuit Breaker“ ist eine Sicherung, welche ausgelöst wird, sobald gewisse Umstände eintreten. Hystrix bietet darüber hinaus viele zusätzliche Funktionalitäten:

 

  • kapselt ein Kommando und bietet synchrone und asynchrone Ausführung,
  • löst nach definiertem Timeout die Sicherung aus,
  • führt jedes Kommando in einem definierten Thread Pool aus,
  • auslösen der Sicherung bei zu hoher Fehlerrate eines Kommandos,
  • ermöglicht die Ausführung eines Fallbacks im Fehlerfall,
  • erzeugt Performance Metriken,
  • ermöglicht die Nutzung eines Caches.

 

Alle diese Funktionalitäten stehen zur Verfügung, sobald ein in der Client Anwendung ausgeführtes Kommando in ein “HystrixCommand” überführt wird. Meiner Meinung nach ist es wichtig, den nachfolgend abgebildeten Ablauf der Ausführung eines Hystrix Kommandos zu verstehen.

Abbildung .1: Netflix, Hystrix Command Fflow Chart, Web URL: https://github.com/Netflix/Hystrix/wiki/How-it-Works [Stand 2016-05-25]

Abbildung .1: Netflix, Hystrix Command Flow Chart, Web URL: https://github.com/Netflix/Hystrix/wiki/How-it-Works [Stand 2016-05-25]

Die detaillierte Beschreibung des Ablaufs finden Sie hier. Der Grund, warum ich diese Abbildung hier aufgeführt habe ist, dass diese sehr schön zeigt, dass Hystrix nicht nur ein reiner Ciruit Breaker ist. Wie zu erkennen ist, bietet Hystrix ein definiertes Verfahren zur Absicherung eines Netzwerkkommandos. Es besteht mit Hilfe der Hystrix Metriken die Möglichkeit sehr einfach und bequem Antwortzeiten auszuwerten. Durch die Integration konnten wir in unserem Projekt die Antwortzeiten eines Fedora4 Content Repository Servers, eines EMC S3 Object Storage Servers und des lokalen Dateisystems vergleichen. Die Hystrix Metriken konnten wir sehr einfach mittels des Hystrix Dashboards visualisieren und in Echtzeit auswerten. So kann auch in produktiven Umgebungen die Reaktions- bzw. Widerstandsfähigkeit einzelner Systeme optimal bewertet werden. Dies ersetzt natürlich keine umfassende Monitoringlösung, bietet aber die Möglichkeit, die Auslastung einzelner Systeme schnell zu erkennen und richtig zu behandeln.

 

Die Integration

Die Integration von Hystrix ist, wie auch bei den anderen “Platform Services” Komponenten, einmal mittels der nativen Netflix Bibliothek oder aber auch über das Spring Cloud Projekt möglich. In unserem Projekt haben wir beide Möglichkeiten erfolgreich durchgeführt.Spring Cloud bietet eine sehr einfache und leichte Integration via Annotation:

 

Beispiel:

@HystrixCommand(commandKey = “DMS->EMCS3:findObjectContent”, groupKey = “DMS->EMCS3”)

 

Hierbei wird lediglich der Name des Kommandos und des Threadpools definiert. Es ist über die Zusatzbibliothek hystrix-javanica zusätzlich möglich, alle Konfigurationswerte direkt in der Annotation aufzuführen. Wir haben uns allerdings dazu entschieden, die Konfiguration in der zentralen „application.properties“ Datei durchzuführen.

 

Im Bereich der nativen Netflix Bibliothek ist die Integration ebenfalls sehr leicht. Nach dem Einbinden der Abhängigkeiten hystrix-core und hystrix-metrics-event-stream kann die Integration durchgeführt werden. Die Klasse, mit welcher ein Kommando im Netzwerk ausgeführt wird, muss lediglich die Klasse HystrixCommand erweitern und die Methode run() implementieren. Die Konfiguration erfolgt über die Datei “eureka-client.properties”.

Bei einigen Standardwerten der Konfiguration mussten wir Anpassungen vornehmen, da Hystrix die Sicherung für unseren Anwendungsfall zu schnell ausgelöst hat. Dies ist uns bei Belastungstests mit dem Werkzeug JMeter aufgefallen. Letztendlich konnten wir mit folgenden Einstellungen ein sehr gutes Antwortverhalten bei einer stark belasteten Komponente erzeugen:

 

hystrix.command.default.execution.isolation.strategy=THREAD

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=120000

hystrix.command.default.execution.isolation.thread.maxConcurrentRequests=1024

hystrix.command.default.fallback.isolation.thread.maxConcurrentRequests=1024

hystrix.threadpool.default.coreSize=1024

hystrix.threadpool.default.maxQueueSize=1024

hystrix.threadpool.default.keepAliveTimeMinutes=2

hystrix.threadpool.default.queueSizeRejectionThreshold=15

hystrix.threadpool.default.metrics.rollingStats.numBuckets=12

hystrix.threadpool.default.metrics.rollingStats.timeInMilliseconds=1440  

 

Sich diese Konfigurationswerte genau zu betrachten und diese festzulegen, ist ein wichtiger Schritt bei der Integration von Hystrix. Allerdings muss natürlich jeder selbst entscheiden, welche Werte für welches Kommando sinnvoll sind.

 

Fazit

Die Integration ist, wie bereits bei den anderen “Platform Services” des Netflix OSS, nicht sehr aufwendig. Dieses Werkzeug, finde ich persönlich, wegen der vielen zusätzlichen Funktionalitäten sehr interessant und nützlich. Es bietet eine standardisierte Lösung, um ein Netzwerkkommando gesichert auszuführen, ein Fallback zur Verfügung zu stellen, einen Cache zu nutzen und Performancemesswerte zu erzeugen. In Zukunft werde ich für mich persönlich daher immer bewerten, ob nicht die Verwendung dieser Bibliothek bei jeglichen Netzwerkzugriffen eines Projektes sinnvoll ist.