Autor: ihbrune

1991-1996: Studium der Naturwissenschaftlichen Informatik an der Universität Bielefeld. Abschluss mit der Diplomarbeit zum Thema 'Analyse von ein- und mehrdimensionalen Zeitreihen mit der Karhunen-Loève- und Wavelet Transformation' || 1996-1997: Wissenschaftlicher Mitarbeiter am Lehrstuhl Prof. A. Knoll in der Technischen Fakultät der Universität Bielefeld im Projekt 'LANeCo: Local Area Net Configuration' || 1998- 2018: Tätigkeit im BIS - Bielefelder Informationssystem an der Universität Bielefeld || Seit Oktober 2018: Leitung der Abteilung Informationssysteme und Prozessunterstützung im BITS

Das eKVV erreicht sein 3. Betriebsjahrzehnt

ihbrune

In den BIS News habe ich diesen kurzen Post über das 20. Betriebsjahr des eKVVs eingestellt. Man hätte mehr schreiben können, aber es gab in der Vergangenheit auch schon umfangreichere Texte zu anderen, runden Geburtstagen (10 Jahre Projekt BIS) oder inhaltlichen Meilensteinen (die 2.000.000ste Prüfungsleistung im System). Irgendwann fängt man sich zu wiederholen 😅

Baukräne an der Universität Bielefeld

Und wenn der 20. Geburtstag mitten eine Zeit fällt, in der sich so viel bewegt – der Start des Medizin-Studiengang rückt näher und damit vielfältige Veränderungen im Grundsystem – ist das eher ein Anlass nach vorne zu blicken, als zurück.

Trotzdem … wenn ein technisches System allmählich ein Alter erreicht, in dem man als Mensch endgültig als Erwachsene*r gilt, ist das bemerkenswert, um so mehr wenn die Perspektive nach heutigen Stand ohne Deadline für eine Ablösung oder ein Nachfolgesystem ist.

Am Ende der langen Geschichte des BIS (bis Ende 2016) findet sich ein Abschnitt zur technologischen Zukunftsfähigkeit des Gesamtsystems. Das dort gesagte gilt für mich auch weiterhin: Die Nutzung von Java als Grundtechnologie gibt uns die Handlungsoptionen und das große, lebendige Ökosystem, welches wir für Weiterentwicklungen brauchen. Auch große Überarbeitung wie die aufwändige Umstellung der Oberflächen auf das aktuelle Corporate Design und die damit endlich erfolgende Einführung einer responsiven Darstellung lassen sich bewältigen, die hohen Kosten (in Form von Personalressourcen) entstehen eher durch die Komplexität und den Umfang der BIS Anwendungen und weniger durch die eingesetzte Grundtechnologie.

Im Moment spricht daher nichts dagegen, dass das eKVV in 10 Jahren weiterhin das zentrale System für die Lehrplanung an der Universität Bielefeld ist. Die sich dann mit einem Medizinstudiengang im Vollausbau, vielen neuen Gebäuden und vielleicht auch durch die Nachwirkungen der Corona-Online-Zeit sehr verändert haben wird.

PS.

Beim Schreiben des BIS News Posts habe ich den alten Screenshot des eKVVs aus dem Jahr 2003 herausgesucht:

Screenshot des eKVVs aus dem Jahr 2003

Und irgendwie gefällt mir die Buntheit 😌 und die Läuferin, die wir damals in den Verlauf gesetzt haben. Vielleicht auch einfach nur weil weil der Kontrast zu heutigen Seiten einfach so groß ist.

PPS.

Wer mehr über zur Entstehung des eKVVs lesen möchte: In der Geschichte des Bielefelder Informationssystems bis zum Jahr 2016 findet sich eine Beschreibung.

Endlich: Emacs unter ChromeOS 😆

ihbrune
Screenshot ChromeOS mit Linux Anwendungen

Das ist ein Screenshot aufgefertigt auf dem ChromeBook, das gestern ankam. Das erste Modell hier im Haus, auf dem sich Crostini ausführen läßt. Damit hat ChromeOS Linux Container erhalten und so die Option Tools wie git oder eben Emacs nativ auszuführen. Und Google Drive lässt sich einfach mounten. Sehr schick 😊

Java APIs in Android: Der Rechtsstreit ist entschieden

ihbrune

Die Auseinandersetzungen zwischen Oracle und Google um Google’s Nutzung von Java APIs in Android sind offenbar vorbei: Das Oberste Gericht der USA hat entschieden, dass diese Nutzung unter den Fair Use fällt. Neben IT und Tech Seiten wie Heise und The Verge haben auch SPIEGEL und FAZ direkt darüber berichtet. Das Urteil ist spannend zu lesen:

Fast 11 Jahre vor Gericht

Zusammenfassungen der verschiedenen Etappen dieser Auseinandersetzung zwischen den beiden IT Giganten lassen sich an verschiedenen Stellen im Netz finden, für mich verbindet sich die Anfangsphase noch mit intensiven Diskussionen darüber beim schon lange eingestellten Google+. Dort haben sich naturgemäß die eher Google-freundlichen Diskutanten eingefunden, aber die Frage ob Google sich unrechtmäßig der kreativen Leistung anderer bedient hat, oder ob Oracle mit seinem Versuch Programmierschnittstellen nachträglich als urheberrechtlich geschützte Werke zu interpretieren die Softwarewelt aus ihren gewohnten Angeln hebt, war heiß umstritten. Ich war da eher auf der Seite, die Oracles Klagen strikt ablehnte. Die folgende Karikatur aus dieser Zeit zu den Organisationsstrukturen verschiedener IT Unternehmen ist mir daher direkt wieder eingefallen:

Humoristische Organisationscharts verschiedenen US IT Unternehmen: Apple, Google, Microsoft, Oracle, Facebook, Amazon
Comic von Manu Cornet

Interessante Auszüge aus dem Urteil

Das Urteil kann man hier als PDF vom Heise Verlag abrufen. Es ist durchaus lesenswert und auch ohne umfangreiche juristische Kenntnis durchaus verständlich. Ein paar Abschnitte habe ich mir rauskopiert:

‚To decide no more than is necessary to resolve this case, the Court assumes for argument’s sake that the copied lines can be copyrighted, and focuses on whether Google’s use of those lines was a “fair use.”

Das oberste Gericht hat also die für die IT Welt – insbesondere auch die Open Source Community – wesentliche Frage ob eine API überhaupt ganz grundsätzlich ein Urheberrecht haben kann, nicht entschieden. Und da hatte Oracle in früheren Instanzen einen Etappensieg errungen. Auch wenn die Oracles Niederlage nun vielleicht einen abschreckenden Effekt hat, grundsätzlich ist damit zumindest in den USA wohl mit weiteren Verfahren zu rechnen, in denen API-Nutzungen Anlass zu Gerichtsverfahren geben. Und nicht jede Beklagte ist so mächtig und wohlhabend wie Google.

‚Computer programs differ to some extent from many other copyrightable works because computer programs always serve a functional purpose.‘

Das Gericht hat sich aber Gedanken dazu gemacht, in wie weit das Urheberrecht eigentlich auf Software angewendet werden kann.

‚As a result, this code is different from many other types of code, such as the code that actually instructs the computer to execute a task. As part of an interface, the copied lines are inherently bound together with uncopyrightable ideas (the overall organization of the API) and the creation of new creative expression (the code independently written by Google). Unlike many other computer programs, the value of the copied lines is in significant part derived from the investment of users (here computer programmers) who have learned the API’s system.‚

Hier macht das Gericht zum ersten, aber nicht zum letzten Mal, einen interessanten Punkt: Eine API – zumindest die, um die es hier konkret geht – gewinnt dadurch an Wert, dass Programmierer*innen sie erlernen und dafür Zeit investieren. Damit wird die Wertgenerierung nicht mehr allein den Erschaffer*innen zugebilligt, sondern jede Java Entwickler*in, die diese APIs gelernt hat, vergrößert durch ihr Investment den Wert der Sprache.

‚Google copied only what was needed to allow programmers to work in a different computing environment without discarding a portion of a familiar programming language.‘

Auch hier wird wieder der Verweis auf das existierende Knowhow von Entwickler*innen gemacht und das es Googles Vorgehensweise diesen ermöglicht habe ihr Wissen nun in einem weiteren Umfeld zu nutzen. Dieses Wissen also wertvoller wurde.

‚Google copied approximately 11,500 lines of declaring code from the API, which amounts to virtually all the declaring code needed to call up hundreds of different tasks. Those 11,500 lines, however, are only 0.4 percent of the entire API at issue, which consists of 2.86 million total lines. In considering “the amount and substantiality of the portion used” in this case, the 11,500 lines of code should be viewed as one small part of the considerably greater whole. As part of an interface, the copied lines of code are inextricably bound to other lines of code that are accessed by programmers. Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment.‘

Und noch einmal der Verweis auf die Möglichkeit für Entwickler*innen ihr Knowhow in einer neuen Umgebung zu nutzen. Verbunden mit der Entlastung von Google, die eine vergleichsbare API oder gleich eine ganze Programmiersprache auch leicht hätten selbst entwickeln können (was sie in späteren Jahre mit Dart und Go taten).

‚The fourth statutory factor focuses upon the “effect” of the copying in the “market for or value of the copyrighted work.” §107(4). Here the record showed that Google’s new smartphone platform is not a market substitute for Java SE. The record also showed that Java SE’s copyright holder would benefit from the reimplementation of its interface into a different market‚

Mir persönlich gefällt, dass das Gericht den positiven Einfluss von Android auf das ganze Java Ökosystem hier honoriert. Schon bei den ersten Diskussionen gab es diesen Punkt, wenn es Oracle wirklich darum gegangen wäre Java zu pushen, dann hätten sie direkt mit Google zusammenarbeiten können. Und offenbar ist im Laufe der Jahre das Argument von Oracle verloren gegangen, wonach Google mit Android das ‚florierende‘ Ökosystem von Java ME Handys vernichtet habe.

Die Entwickler*innen als eigene Partei

Abgesehen von der eigentlichen Urheberrechtsfrage, die vermutlich in anderen Gerichtsverfahren – vielleicht nicht nur in den USA – entschieden wird, finde ich den Aspekt, das wir als Entwickler*innen eine wesentliche Rolle in solchen Erwägungen spielen, sehr spannend:

Wenn wir uns auf eine Sprache / API / Technologie einlassen kostet uns dies Zeit und vielleicht auch Geld und eine Technologie kann sich kaum durchsetzen ohne eine entsprechende Menge von Menschen, die sich damit gut auskennen. Und unsere Interessen sind dabei durchaus anders als die der potentiellen Urheberrechtsinhaber*innen: Für uns ist es attraktiv die Wahl zu haben, zwischen Werkzeugen und zwischen Implementierungen einer API, und jedes neue Feld, in dem wir unsere Kompetenz einsetzen können, ist zunächst einmal gut für uns und den Wert unseres Wissens.

Man wird sehen, ob dieser Aspekt auch in zukünftigen Gerichtsverfahren eine Rolle spielen wird.

Die Blockchain und das Osterei

ihbrune

Wenn die Ostereier in diesem Jahr ungefärbt waren, dann hat man vielleicht ein neues Logo darauf entdecken können, das Logo von respeggt. Damit werden Eier gekennzeichnet, die ohne das Töten von männlichen Küken bei der Zucht der Legehennen auskommen. Dieser Abschnitt aus der respeggt-Webseite sagt dazu:

Das respeggt-Siegel steht für das Versprechen: „Ohne Kükentöten“. Dank einer lückenlosen Prüfung der Lieferkette wird garantiert, dass nur Produkte das Siegel tragen, die die Forderung „Ohne Kükentöten“ erfüllen.

An dem respeggt-Siegel erkennt der Verbraucher sofort, dass es sich um Eier handelt, in deren gesamter Lieferkette die Grundsätze des respeggt-Versprechens eingehalten werden. Die Nutzung einer Blockchain-Technologie stellt sicher, dass jedes Ei, das das respeggt-Siegel trägt, lückenlos verfolgt und auf das Einhalten des respeggt-Versprechens verifiziert wird.

Das hört sich sowohl in ethischer wie auch in technologischer Hinsicht interessant an. Aber wie funktioniert das?

Ei im Eierbecher

Was ist die Aufgabe

Die respeggt-Group ist selbst kein Eierproduzent, sie hat das Qualitätssiegel entwickelt und betreibt das System zur Sicherung dieser Qualität. Damit das Siegel glaubwürdig ist müssen dabei mindestens diese Dinge beleg- und nachvollziehbar sein und zwar lückenlos:

  1. Von welchem Legehennenbetrieb kommt das mit dem Siegel gekennzeichnete Ei
  2. Von welcher Henne wurde das Ei dort gelegt
  3. In welchem Aufzuchtbetrieb wurde die Henne großgezogen
  4. Woher kam das Ei, aus dem die Henne geschlüpft ist
  5. Wie wurde in der Brüterei mit den männlichen Küken der Eier umgegangen, die zusammen mit dem Ei, aus dem die Henne geschlüpft ist, bebrütet wurden. Diese Frage ist das eigentliche Fundament des Qualitätssiegels

Bis das respeggt-Ei in die Handelsketten und zum Endkunden kommt sind also schon auf mehreren Ebenen Unternehmen mit unterschiedlichen Aufgaben beteiligt, und in jedem dieser Unternehmen und auch bei den Transporten von Hühnern und Eiern zwischen ihnen gibt es Potentiale für Fehler oder gar absichtliche Verstöße gegen die Richtlinien.

Das Supply Chain Monitoring System für so eine Produktions- und Lieferkette ist schon eine komplexe Aufgabe, um das Vertrauen der Verbraucher*innen zu gewinnen muss aber auch plausibel gemacht werden, dass die Dokumentationen dazu vollständig und fälschungssicher sind.

Was kann die Blockchain dazu tun

Für die Blockchain Technologie, die mit dem Aufstieg von Kryptowährungen wie Bitcoin Bekanntheit erlangte, werden schon lange weitere Einsatzfelder diskutiert. Genauer gesagt muss es dabei nicht unbedingt eine Blockchain sein, sondern generell eine Distributed-Ledger-Technologie, was man als verteiltes Kassenbuch übersetzen kann, und Blockchain ist dabei das heute am weitesten verbreitete Verfahren.

Eine Distribute-Ledger-Technologie hat dabei mehrere interessante Eigenschaften, hier sind es wohl diese beiden, die wesentlich sind:

  • Das ‚Kassenbuch‘ ist kryptografisch so abgesichert, das nachträgliche Änderungen nicht möglich sind, zumindest nicht ohne das sie auffallen. Die Blöcke in der Blockkette verweisen dazu aufeinander und bilden so eine Kette, die nicht unterbrochen werden kann
  • Bei einem echten verteilten Kassenbuch gibt keinen zentralen Akteur, der uneingeschränkt über das Kassenbuch bestimmt, es sich mehrere Akteure notwendig, um den nächsten Dokumentationsabschnitt (= Block) zu bestätigen und damit unveränderlich zu machen. Allerdings ist mir beim respeggt-System nicht klar, ob das Sinn macht bzw. so umgesetzt wurde

Diese Eigenschaften sind etwa in der Bildungslandschaft die Grundlage für Überlegungen über eine Blockchain fälschungssichere und allgemein zugängliche Dokumentationen von Abschlüssen bzw. Bildungszertifikaten aufzubauen, die je nach Nutzungsweise auch ohne zentrale Datenhaltung auskommen könnte. Dabei müssen ’nur‘ noch ein paar Hürden überwunden werden, etwa die, das nicht komplette Zeugnisse in die Blockchain aufgenommen werden können: Die personenbezogenen Daten darin würden sich nie mehr daraus entfernen lassen, was sich nicht mit der DSGVO vereinbaren lässt. Hier könnte mit Dokumentenhashes gearbeitet werden, über die sich dann Dokumente, die von Absolvent*innen präsentiert werden, validieren lassen.

Eine andere Idee – und hier kommen wir denke ich dem Einsatzszenario bei den respeggt-Eiern schon näher – ist das hier beschriebene Verfahren für Diamanten Herkunftsnachweise zu realisieren. Und so den Nachweis zu führen, dass es sich nicht um sogenannte Blutdiamanten handelt. Ob dieses Verfahren inzwischen tatsächlich eingeführt und genutzt wird habe ich leider nicht herausgefunden, aber das liegt vielleicht in der Natur der Sache:

Während die Bitcoin Blockchain vom Prinzip her öffentlich sein muss, würden sich die am Diamantenhandel beteiligten Parteien wohl eher nicht völlig frei in die Karten schauen lassen. Hier wird die Blockchain dann zu einem internen Werkzeug für Unternehmen, die sich nicht völlig (oder überhaupt nicht) vertrauen können, aber damit eine gegenseitige Kontrollmöglichkeit erhalten könnten ohne eine zentralisierte Struktur.

Leider habe ich auch zur respeggt-Blockchain keine konkreteren Angaben im Netz finden können, die inhaltlich über den oben zitierten Satz hinausgehen. Es gibt nur von Telefonica dieses Paper (PDF), welches im Kontext des Internet of Things die Anbindung von respeggt-Infrastrukturen beschreibt. Vielleicht speisen verschiedene Gerätschaften wie die Drucker, die das Siegel auf die Eier drucken, ihre Daten so gleich in die Blockchain ein? Leider ist auch nicht klar wer genau wie tief in die Blockchain schauen kann und was genau da alles drin steht. Als Endkunde kann man nur hier seinen Eiercode online prüfen.

Trotzdem ist das für mich eines der bisher noch wenigen Beispiele, in denen die Blockchain Technologie jenseits von Bitcoin ganz direkt nutzbar geworden ist.

Hafnium im Gartenshop

ihbrune

Die wahlweise Hafnium oder ProxyLogon genannte Gruppe von Sicherheitslücken in Microsofts Exchange Servern dominierte in den letzten Wochen die IT Sicherheitsthemen. Und selbst wenn IT Profis wie die Kollegen in der Uni die Lücken schnell geschlossen haben kann einen das Thema betreffen. Daran erinnert diese Mail eines Webshops, bei dem ich vor Jahren mal etwas bestellt habe, und die gestern eintraf:

Screenhot einer Mail mit der Information darüber, dass der Exchange Server eines Webshops gehackt wurde

Nicht alle Admins von Exchange Servern waren schnell genug um den direkt nach Bekanntwerden der Lücke einsetzenden, massenhaften Scans nach verwundbaren Servern zuvor zu kommen. Vermutlich gibt es 10.000e von Systemen, die schon mit Webshells oder anderen Hintertüren ausgestattet wurden (Nachtrag: manche offenbar auch gleich mehrfach). Und ein reines Patchen der Exchange Lücken beseitigt diese Zugänge dann nicht mehr.

Die DSGVO zwingt nun die Betreiber zumindest im europäischen Raum dazu ihre Kund*innen über solche Vorfälle zu informieren. Und ich würde wetten, dass das nicht die letzte entsprechende Mail war, die ich bekommen werde. Natürlich nur, wenn gehackte Betreiber sich gesetzeskonform verhalten bzw. überhaupt entdecken, dass sie gehackt wurden.

Was kann man tun?

Bei der Gelegenheit die Erinnerung an den schönen Have i been pwned? Dienst:

https://haveibeenpwned.com/

Der benachrichtigt einen, wenn mit der eigenen Mailadresse verknüpfte Kontodaten irgendwo im (Dark)Web auftauchen, oft auch verbunden mit der Information von welchem Dienst diese Daten gestohlen wurden. Ich habe in den letzten Jahren schon mehrere entsprechende Meldungen bekommen und zum Glück hatte ich bei den jeweiligen Diensten schon individuelle, nur für den jeweiligen Dienst geltende Passworte verwendet, so dass mit den gestohlenen Zugangsdaten nicht noch weitere Konten von mir missbraucht werden konnten.

Was zum nächsten Tipp führt: Heute ist die Verwendung eines Passwortmanagers unumgänglich um

  • sehr sichere (also lange und komplett zufällige) und
  • für jeden Dienst einzigartige

Logindaten zu verwenden. Wer sich dabei nicht auf die in heutigen Webbrowsern eingebauten Passwortmanager verlassen möchte, der findet hier einen aktuellen Überblick.

Wie lang darf eigentlich ein class-Attribut sein?

ihbrune

Ich arbeite nicht erst seit gestern mit HTML, aber diese Frage habe ich mir nie gestellt. Der aktuelle Security Now Podcast (Folge #810) mit seiner Beschreibung der interessanten ‘Prime+Probe 1, JavaScript 0: Overcoming Browser-based Side-Channel Defenses’ Forschungsarbeit hat mich erst darauf gebracht: Darin geht es um einen Ansatz um Nutzer*innen im Webbrowser ganz ohne Javascript zu tracken und der trickreiche Ansatz um mal wieder Cache Timings als Seitenkanal zu nutzen verwendet – Achtung! – 2 Millionen Zeichen lange Klassennamen. Zitat:

CSS Prime+Probe Implementation. Figure 3 shows a code snippet implementing CSS Prime+Probe, using CSS Attribute Selectors to perform the attack. Specifically, Line 9 defines a div with a very long class name (two million characters).

Kann das sein? Warum sollte die HTML Spezifikation derart lange Namen erlauben? Hätte ich vorher darüber nachgedacht wäre mein Tipp vermutlich bei 1024 oder maximal 32.768 Zeichen gelandet. Das sollte auch für sehr sprechende und exzessive Anwendungen von CSS Klassennamen ausreichen, wie sie z. B. die BEM Vorgehensweise nahelegt.

HTML Code mit sehr langem class-Attribut

Aber die Antwort, warum die Spezifikation solche langen Namen erlaubt, scheint einfach zu sein: Sie macht hier überhaupt keine Vorgabe! Demnach setzen nur die konkreten HTML Implementierungen der Webbrowser Grenzen, schon um zu verhindern, dass solche absurden Inhalte den Speicher zum überlaufen bringen. Aber wenn es solche Grenzen gibt, dann liegen sie offenbar weit jenseits dessen, was sich ‘vernünftig’ anfühlt.

Ob die Browserhersteller angesichts solcher Tricksereien nun anfangen engere Begrenzungen zu definieren? In regulären Webanwendungen sind jedenfalls kaum Anwendungen vorstellbar, die mehr als 1024 Zeichen für Klassennamen verwenden. Oder?

Flutter: Das neue Java

ihbrune

Gerade wurde Flutter 2 veröffentlicht und es gibt einiges zu berichten aus der Flutter Welt. Wenn man sich die Keynote der Flutter Engage anschaut hat mich aber insbesondere der Teil, der die verschiedenen neuen Zielplattformen vorstellt, irgendwie an das Java Marketing vor mehr als 20 Jahren erinnert: 

Write once, run anywhere

So war der Slogan, den SUN 1995 prägte, um das Versprechen auszudrücken mit einem Programm viele Plattformen bedienen zu können. Was sich auf der Serverseite letztlich verwirklicht hat. Aber auf der Clientseite dann doch nicht. Zwar gibt es bis heute Java Desktop Anwendungen, aber so richtig schön und zum jeweiligen Betriebssystemumfeld passend waren die fast nie. Wenn es Android nicht gäbe und die auf Java basierenden für Android Apps, dann würde man sich heute kaum an Java als Frontend Sprache erinnern. Und an Dinge wie Applets möchte man sich auch gar nicht mehr erinnern 😬

Flutter überall 

War Flutter bisher für die Android und iOS Crossplattformentwicklung geeignet kommt nun die Webplattform aus der Beta heraus und weitere Plattformen sind auch bereits bespielbar, wenn auch noch nicht völlig stabil:

Was hier noch fehlt sind eingebettete Systeme wie das von Toyota vorgestellte Infotainmentsystem in ihren Fahrzeugen.

Ob sich Flutter hier wirklich überall durchsetzen wird? Interessant ist auf jeden Fall die Unterstützung von den Ubuntu Linux Machern von Canonical, die sich hier sicher erhoffen die ewige Lücke zu den für Windows und MacOS erhältlichen Programmen schließen zu können.

Perspektiven

Für jemanden, der bisher eher aus der Webentwicklung kommt, wirft Flutter 2 die Frage auf ob hier ein Werkzeug entsteht, mit dem man ähnlich ubiquitär nutzbare Produkte entwickeln kann, wie mit einer responsiven Webseite. 

Dazu aber noch Funktionen erhält, die sich in einer App leichter entwickeln lassen. Und mit dem man in die App Stores kommen kann. Und mit dart eine moderne Programmiersprache als Unterbau bekommt, die nun auch Dinge wie null safety verspricht.

Oder muss man befürchten, dass Google dieses Vorhaben wie so viele andere Dienste und Projekte einstampft? Da sich inzwischen auf andere Firmen – selbst Microsoft – beteiligen und Google selbst wesentliche Apps wie Google Pay damit realisiert scheint diese Gefahr im Moment gering.

Ich bin jedenfalls gespannt welches Bild sich vielleicht in 10 Jahren zeigt und ob Flutter gegenüber den Javascript-basierten Cross Plattform Lösungen die Nase vorne haben wird.

Begeisterung für die Typographie

ihbrune

Gibt bei man Google ‚Typographie‘ ein erhält man heute diese Definition:

  1. Kunst der Gestaltung von Druck-Erzeugnissen nach ästhetischen Gesichtspunkten; Buchdruckerkunst
  2. typografische Gestaltung (eines Druck-Erzeugnisses)

Druck-Erzeugnisse? 🔣

Dabei spielt Typographie für Webseiten und Apps eine wichtige Rolle, selbst wenn man sich für das Thema nicht ganz so begeistern kann wie Oliver Schöndorfer von Zeichenschatz in der 83. Folge des programmier.bar Podcasts.

Schriftartenbeispiele von Google Fonts

Für mich eine unbedingt hörenswerte Folge, die einem als Entwickler*in wesentliche Begriffe und Konzepte von Schriftarten beibringt und das auch noch mit einer ansteckenden Begeisterung (trotz der Wiener Mundart 😏). Und einer seiner Punkte ist für mich besonders überzeugend: In einer App oder responsive Webseite bleibt oft nur noch die Typographie um sich von anderen Angeboten abzusetzen und Wiedererkennungswerte zu schaffen.

Was man im Podcast alles lernt 🔣

  • Was sind Display text, Body text und Functional text? Und nach welchen Kriterien wählt man dafür geeignete Fonts?
  • Wann ist die Frage wie gut unterscheidbar Zeichen wie Il1, ec oder agq in einem bestimmten Font sind wichtig?
  • Warum lohnt es sich auch mal jenseits von Google Fonts nach Schriftarten suchen? Oder wenn doch Google Fonts, dann vielleicht mal die Sortierung umzudrehen und nach den weniger populären Fonts schauen?
  • Was hat es mit Zwiebelfischen und Schusterjungen auf sich?
  • Was sind variable fonts und was macht sie so cool? Diese Frage kann sich auch hier beantworten: v-fonts.com/
  • Und was hat Oliver gegen Open Sans? Und hat dazu sogar ein Video in seinem YouTube Channel (unbedingt bis zum Ende sehen)?
  • Und noch einige mehr…

Für mich war der Podcast gut investierte Zeit 🔣

Update | Mit der Spiegelreflexkamera in die Cloud: Mein Fotoworkflow mit Eyefi Karte, Smartphone und Photos

ihbrune

Vor fast vier Jahren habe ich in dem Blogpost ‚Mit der Spiegelreflexkamera in die Cloud: Mein Fotoworkflow mit Eye-Fi Karte, Smartphone und Google+‚ meinen damaligen Workflow zum Umgang mit den Fotos beschrieben, die ich mit der Spiegelreflexkamera mache. Der Originaltext ist unten noch einmal angehängt, hier gibt es dazu ein kleines Update, was sich in der Zwischenzeit geändert hat – und was nicht:

Google+ ist heute Google Fotos

Weiterhin landen meine Fotos bei Google, nur das die Fotofunktion schon 2015 aus Google+ ausgegliedert und seit dem im spezialisierten Produkt Google Photos gelandet ist. Google Photos hat den Umgang mit den 100.000+ Fotos, die ich dort abgelegt habe, auf ein Level gehoben, welches noch vor wenigen Jahren kaum vorstellbar war:

Auf jedem Gerät, welches eine halbwegs brauchbare Internetverbindung hat, stehen mir meine Bilder der letzten ca. 20 Jahre in Sekunden zur Verfügung. Und selbst Suchen, die ich nie durch entsprechende Alben oder Fotobeschriftungen antizipiert habe, lassen sich meist schnell über die immer leistungsfähigere Bilderkennung durchführen.

Es ist schon Jahre her, seit ich das letzte Mal Fotos direkt vom Smartphone auf einen PC übertragen haben, heute läuft alles über Google Photos. Tatsächlich habe ich in diesem Moment wohl kein vollständiges Backup meiner Fotos zu Hause.

Weniger Bilder mit der Systemkamera, mehr mit dem Smartphone

Der Umgang mit Fotos, die nicht bereits auf dem Smartphone entstanden sind, ist in den letzten Jahren – zumindest wenn man die Anzahl der gemachten Fotos vergleicht – weniger wichtig geworden: Seit ich mir das Nexus 6P Ende 2015 zugelegt habe waren die Bilder, die vom Smartphone kamen, in vielen Fällen besser bzw. gefälliger als das, was die Systemkamera produzierte:

In diesem Album wird eine Reihe von Dämmerungsbildern des Nexus 6P mit Fotos der Sony Kamera verglichen. Man kann hier über die Farbtreue diskutieren, aber die meisten BetrachterInnen würde vermutlich die Bilder des Smartphones bevorzugen. Seit ich auf das Pixel 2 umgestiegen bin ist die Leistungsfähigkeit der Smartphonekamera noch weiter gestiegen.

 

Eyefi ist heute Keenai

Meine alte Eyefi Karte wird inzwischen nicht mehr richtig auf der Softwareseite unterstützt, und sie war auch nur 4 GB groß. Beim Neukauf einer Karte war ich zunächst verblüfft über die Stolpersteine, die einem bei der Inbetriebnahme dieses über Amazon als neu vertriebenen Produkts begegnen:

Alle – wirklich alle – Links, die man auf der Packung findet, landen auf nicht mehr funktionierenden Seiten. Es scheint, also sei die http://www.eyefi.com/ heute wenig mehr als ein Platzhalter für einige Werbebotschaften, aber ansonsten komplett von jeder Funktion entkleidet.

Sucht man dann im Play Store nach ‚eyefi‘ findet man keine einzige App, die auf den ersten Blick so aussieht, als sei sie eine offizielle App zu der Karte. Allerdings stellt sich dann der erste Treffer – die Keenai App –  tatsächlich als die richtige heraus. Und etwas googlen bringt einen dann zu dieser Meldung, die den Übergang von Eyefi auf Keenai erläutert.

Ist man so weit gekommen geht die Inbetriebnahme der neuen Karte über das Smartphone nichts mehr im Weg, im Gegensatz zum früheren Modell ist kein PC mehr notwendig. Die Registrierung in der Keenai Cloud habe ich dann direkt abgeschaltet, da mir die Funktionen keinen Nutzen bietet. Gefühlt geht die Übertragung der Fotos mit dem neuen Karte schneller, allerdings fällt das bei mir mit dem Wechsel auf das Pixel 2 zusammen.

Der Blogpost von Anfang 2014

Mit dem Start von Google+ und der genialen Möglichkeit quasi unbegrenzt viele Bilder in der Google Cloud abzulegen hat sich mein Umgang mit den selbst geschossenen Bildern komplett umgestellt: Das wichtigste Ziel ist es jetzt alle Bilder möglichst schnell zu Google+ zu schicken, denn das ist der Ort, an dem ich heute nahezu ausschließlich auf meine Bilder zugreife.

Bei den Bildern, die ich mit dem Smartphone mache, ist das geschenkt: Einfach die Option für die Automatische Sicherung aktivieren und der Rest geht – wie versprochen – automatisch. Bei den Bildern von meiner Spiegelreflexkamera bzw. neuerdings meiner Systemkamera geht es aber erst einmal nicht ganz so direkt. Den Workflow, den ich dabei für mich gefunden habe, möchte ich hier einmal beschreiben:

Man wird bequem

Der zunächst naheliegendste Weg wäre es die Bilder von der Kamera – wie früher auch – auf den PC zu kopieren und von dort zu Google+. Aber zum einen gibt es die automatische Google+ Foto Synchronisation für Windows PCs erst seit Mitte Dezember letzten Jahres. Zum anderen ist es erstaunlich, wie lästig einem das Hantieren mit Kabeln werden kann, wenn die ganze andere Kommunikation zwischen den Geräten erst einmal über das Netz bzw. die Cloud funktioniert. Auch ist das keine Lösung für den manchmal dringlichen Wunsch ein irgendwo im Wald gemachtes Foto gleich mit dem Rest der Welt auf Instagram oder Google+ teilen zu wollen.

Die Lösung: Eye-Fi

Meine Lösung für alle diese Bedarfe: Die Eye-Fi WiFi-SD-Karte. Diese Karten bauen ein eigenes WLAN auf, sobald sie mit Strom versorgt sind, und das Smartphone kann über eine vom Hersteller mitgelieferte App eine Verbindung aufbauen. Über diese Verbindung werden die Bilder direkt übertragen und liegen dann auf dem Smartphone, (fast) so wie die direkt mit dem Phone gemachten Bilder.

Als zusätzlichen Bonus kann die Smartphone App die Bilder noch mit GPS Tags versehen, sofern man der App gestattet entsprechende Daten zu sammeln und die Uhren von Phone und Kamera synchron sind. Es reicht also auch eine ganz ‘dumme’ Kamera zu verwenden, ohne eigene WiFi- und GPS-Funktion.

Mein Workflow von A-Z

Und so sieht dann mein Workflow ganz konkret aus:

  1. Mit der Kamera werden viele tolle Bilder geschossen.
  2. Entweder schon während des Shootings oder auch erst später, falls das Smartphone gerade nicht in Reichweite sein sollte, werden die Bilder übertragen und von der App mit GPS Tags versehen.
  3. Die Bilder landen dabei in einem Ordner, der nicht von der automatischen Sicherung der G+ App erfasst wird. Das scheint sich nicht ändern zu lassen, gibt mir aber eine Gelegenheit eine Sichtung durchzuführen und die Bilder gleich zu verwerfen, die unbrauchbar sind. Auch könnte ich nun schon die ersten Bilder bearbeiten und online stellen. Meine Bildbearbeitung hat sich heute fast komplett auf das Smartphone verlagert. [UPDATE: Mit der heutigen Version der Google+ App kann man auch andere Ordner auf dem Smartphone automatisch hochladen lassen. Ich habe aber bisher meinen manuellen Workflow beibehalten.]
  4. Danach verschiebe ich die verbliebenden Bilder in den Ordner, in dem die Smartphone Kamera ihre Bilder speichert. Ich nutze dazu Quickpic, die Foto App, die es bisher immer auf meine Android Smartphones geschafft hat.
  5. Die Bilder werden dann zu Google+ hochgeladen, sobald ich wieder ein WLAN erreicht habe.
    Nach dem Hochladen sortiere ich einige Bilder über die Google+ Fotos App – die sich in den letzten Monaten unglaublich gemacht hat – in bestimmte Ordner, so dass auch die Organisation der Bilder gleich über das Smartphone erfolgt.
  6. Alle paar Monate mache ich schließlich ein komplettes Backup der Bilder von meinem Smartphone. Das ist heute das einzige Mal, dass ich einen normalen PC verwende. Auch dabei habe ich es mir angewöhnt kein Kabel mehr zu verwenden, ich hole mir die Bilder per WLAN mit der AirDroid App.

Für mich ist das im Moment ein nahezu optimaler Ablauf.

Die Nutzung der Eye-Fi Karte war für mich auch beim gerade erfolgten Neukauf einer Kamera ein Argument dafür auf teure Zusatzfunktionen wie integriertes WiFi und GPS zu verzichten.

Die ZKI veröffentlichen ihre Prozesslandkarte für Campusmanagement

ihbrune

Von den ZKI – Zentren für Kommunikation und Informationsverarbeitung e. V. – gibt es schon seit einiger Zeit ein interessantes Dokument, welche den Versuch unternimmt eine geschlossene Landkarte für die Prozesse aufzustellen, die beim Thema Campusmanagement bzw. Campus Management Systeme relevant sind. Jetzt kann man die letzte Version hier herunterladen:

https://www.zki.de/zki-nachrichten/einzelbeitrag/1746/

Das ZKI beschreibt die Ziele und den Anwendungsbereich des Dokuments dabei so:

Ein Hauptziel der ZKI-CM-Prozesslandkarte ist es, die Reflektion, Optimierung und Weiterentwicklung der hochschuleigenen Prozesse im Kontext von Campus-Management zu unterstützen. Sie soll dabei helfen, dass komplexe Zusammenspiel von Haupt-, Teil- und Unterprozessen so weit zu reduzieren, dass das Auffinden und Ausführen von Prozessen möglich wird, ohne den Blick auf die gegenseitigen Abhängigkeiten zu verlieren. Das vorliegende Dokument ist dabei so angelegt, dass es von jeder Hochschule an die eigenen Rahmenbedingungen, Anforderungen und Hochschulabläufe angepasst werden kann.

Insgesamt macht der Text einen sehr guten Eindruck, auch wenn sich im Detail idealisierte Prozessvorstellungen finden lassen, die im realen Betrieb einer Hochschule nur schwer durchzuhalten sein werden.

Steht eine Hochschule vor der Auswahl eines Campus Management Systems kann die Prozesslandkarte mit ihrer weit gefassten Definition des Student Life Cycle ebenfalls eine Hilfe sein, auch wenn es bei der Bewertung eines konkreten Produkts weniger darauf ankommt bei möglichst vielen Stationen des Life Cycles ein Häkchen setzen zu können, als darum Aspekte wie die innere Integration, die Offenheit und die Durchgängigkeit des Datenmodells zu bewerten.