Archiv der Kategorie: Entwicklung

Mein Beruf und mein Hobby überlappt sich: Die Entwicklung von Software für Computer.

Das Ende des Internets, wie wir es kennen

Wieder ein guter Beitrag im politischen Feuilleton des DLF, diesmal zur Umgestaltung des Internet, wie sie gerade mal wieder mit Aufhebung der Netzneutralität und EU Leistungsschutzgesetz betrieben wird.

Als Blogger betrifft mich das auch, Links auf andere Beiträge wie dieser könnten kostenpflichtig werden. Hoffentlich gibt es das Internet, so wie ich es schätze, noch lange.

Wikileaks, Piratenpartei und die wilden Onlinejahre sind vorbei. Stattdessen diskutieren wir über Upload Filter und die Datenschutzgrundverordnung. Dafür gebe es gute Gründe, aber die Regulierung habe auch ihren Preis, meint der Informatiker Enno Park.

Quelle: Zeitenwende – Das Ende des Internets, wie wir es kennen

Digitaler Nachlass

Der Bundesgerichtshof beschäftigt sich heute mit der Frage, ob Angehörige einen Facebook-Account erben können. Eltern wollten auf den Facebook-Account ihrer verstorbenen Tochter zugreifen, um deren Tod besser aufklären zu können. Facebook hatte das aus vermeintlichen Datenschutzgründen verweigert.

Zuvor hatten zwei Vorinstanzen unterschiedlich entschieden, zuletzt das  Kammergericht in Berlin hatte Facebook recht gegeben und den Eltern keinen Zugriff gewährt. Mit diesem Urteil war ich nicht einverstanden: Wenn ein Erbe Zugriff auf den materiellen Teil hat und dabei auch zum Beispiel auf die Geheimnisse eines Tagebuchs, so muss dies IMHO in gleicher Weise auch für den digitalen Nachlass gelten. Ein Testament kann den Schutz dieser Daten ja auch regeln und den Eltern, wenn gewünscht, den Zugriff verwehren.

Aber vielleicht zeigt ja dies generell das Problem der sozialen Netzwerke: Ich erstelle auf Facebook in meinem Account ein Bild meiner selbst mit umfangreichen Daten, aber wem gehören diese Daten dann? Mir oder Facebook? Das ist schon zu Lebzeiten ein Problem, erst recht nach dem Ableben. Aus diesem Grund habe ich keinen Account mehr und führe statt dessen diesen Blog, da ist die Sache klar, wo die Daten liegen und wem sie gehören. Aber auch der Lösch-Button ist bei facebook nicht so leicht zugänglich, und wo Kopien diese Daten herumgeistern weiß man ja seit der Affaire um Cambridge Analytica auch nicht mehr so genau.

Welche Fragen sich ergeben, und was man schon zu Lebzeiten tun kann, beleuchtet ein ausführlicher Beitrag im DLF:

https://www.deutschlandfunk.de/digitaler-nachlass-wenn-tote-auf-facebook-sind.724.de.html?dram:article_id=420871

 

Telefon-Links mit Grav

Meine Begeisterung für das flat-file CMS Grav steigt stetig. In einem Twig-Template habe ich gerade relativ leicht tel: links generiert:
<a href="tel:+49{{ person.telefon|regex_replace(['/[^0-9]/', '/^0/'], ['', '']) }}">{{ person.telefon }}</a>

In einem Template werden in einer for-Schleife Adressen ausgegeben. Da es alles deutsche Telefonnummern sind, kann ich sie leicht mit Ersetzungen mit regulären Ausdrücken auf das gewünschte Zielformat +4989123456 bringen. Die Telefonnummer ist im obigen Ausdruck in person.telefon gespeichert, in einem Format wie 089-123456. Sie wird zweimal verwendet, einmal im Klartext des Links, einmal verändert im href-Attribut.

Da Twig regex-Ersetzung nicht von Haus aus mitbringt, muss die php-Funktion durchgereicht werden. Meine Annahme, das habe Grav bestimmt schon gemacht, war richtig: mit regex_replace ist ein entsprechender Twig-Filter definiert. Der macht alles mit zwei Ersetzungen: Alle Nicht-Ziffern werden entfernt, die führende 0 wird entfernt. Das tel:+49 wird statisch davor gesetzt.

Nach vielen Erfahrungen mit TYPO3 und contao ist Grav für mich eine Offenbarung, da ich hier flexibel im Code arbeiten kann, aber nicht auf niedrigste php-Ebenen gehen muss. Und dies bei der Aufbereitung von Inhalten genauso wie bei der Gestaltung mit Themes. So, wie es eines Entwicklers würdig ist 🙂

Software ist Natur

Eine Meinung, der ich mich anschließen kann. Wir profitieren von Open Source mehr als von proprietärem Code. Und wenn Computer immer mehr für und sogar über Menschen entscheiden, ist es überaus wichtig, dass die Algorithmen nachprüfbar und verifizierbar sind.

Zu den natürlichen Ressourcen sind mit Anwendungen und Programmen technische hinzugekommen. Ähnlich wie Trinkwasser und Saatgut müssten auch Software-Codes in öffentlicher Hand sein, erklärt der Philosoph Matthias Gronemeyer.

DLF: Software-Codes und Algorithmen müssen öffentlich sein

Algorithmen visualisieren

Zur Zeit arbeite ich mich vermehrt in Javascript ein, dort auch in die Visialisierungs-Bibliothek D3 von Mike Bostock. Der Informatiker hat lange für die New York Times aufwendige interaktive Grafiken erstellt, daraus ist diese Bibliothek entstanden. Eine tolle Funktionalität, die aber auch verstanden sein will.

Dabei bin ich über eine sehr schöne Seite gestolpert, wo Bostock an Beispielen für die Visualisierung von Algorithmen zeigt, dass die Qualität der Algorithmen dadurch in vielen Fällen gesteigert werden kann. Schon als Student habe ich ähnlich Demos programmiert, ich errinnere mich noch an einen Bubble- und Quicksort in Assembler auf einem Commodore PET 2001, der direkt auf dem Bildschirmspeicher arbeitet und so die Buchstaben sortierte. Spassig. In Perfektion macht dies allerdings Bostock:

https://bost.ocks.org/mike/algorithms/

Chrome unterstützt ES6 Module

Wer wie ich als Java-Entwickler in die Javascript-Welt eintaucht, vermisst eine vernünftige Gliederung in Module und die Definition von Abhängigkeiten dazwischen. In der alten Javascript-Welt wurden dafür viele Mechanismen geschaffen, deren Gebrauch für den Neuling verwirrend ist. 

Mit EcmaScript 6 (auch EcmaScript 2015) ist eine Definition von Modulen und imports bzw.  exports mit sauberen Sprachmitteln möglich. Ein Beispiel:

<!DOCTYPE html>
<html>
    <head>
        <title>ES6 Module</title>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <script type="module">
            import {getGreeting} from "./js/greeting.js";
            
            document.getElementById("content").textContent = getGreeting();
        </script>
    </head>
    <body>
        <div id="content">placeholder for content</div>
    </body>
</html>
import * as my from "./mylib.js";

export function getGreeting() {
        return my.addMy("Hello World!");
}
export function addMy(str) {
    return "My " + str;
}

Die gute Nachricht: Moderne Browser wie Chrome (ab Version 61 ohne Flags), Firefox, Safari und Edge (Edge und Firefox allerdings hinter Flags) unterstützen das bereits ohne Zusatzmittel wie Transpiler etc.:

https://medium.com/dev-channel/es6-modules-in-chrome-canary-m60-ba588dfb8ab7

https://caniuse.com/#feat=es6-module

In EcmaScript 6 (synonym ES6 und EcmaScript 2015) sind aber noch viele andere gute Features und syntaktische Erleichterungen enthalten:

http://es6-features.org

JavaScript ist damit eine richtig erwachsene Sprache und wird damit Java immer ähnlicher 😉

PostgreSQL character varying maximum length

Gerade habe ich in einem Projekt eine legacy Datenbank nach Postgres importiert, und bin dabei sie zu analysieren und umzubauen. Dabei sind die Längenangaben bei Feldern vom Typ character varying immer interessant. Hierbei kann man eine Maximallänge des Feldes in Zeichen angeben. Bei vorgegebenen Daten ist die Ausnutzung dieser Länge interessant, also die Frage, wie lang ist die maximal abgespeicherte Zeichenlänge in jedem Feld.

Eine Idee ist dies mit einer PL/pgSQL-Function zu berechnen, nach etwas Tüfteln habe ich sie hingebracht:

CREATE OR REPLACE FUNCTION public.character_varying_length()
  RETURNS TABLE(table_name varchar, column_name varchar, character_maximum_length integer, actual_maximum_length integer) AS $func$
DECLARE
   tbl information_schema.columns.table_name%TYPE;
   col information_schema.columns.column_name%TYPE;
   width information_schema.columns.character_maximum_length%TYPE;
BEGIN
   FOR tbl, col, width IN
      SELECT c.table_name, c.column_name, c.character_maximum_length
      FROM   information_schema.columns c
      WHERE  c.table_schema = 'public' and c.data_type = 'character varying'
      order by c.table_name, c.ordinal_position
   LOOP
      RETURN QUERY EXECUTE format('SELECT %L::varchar, %L::varchar, %s::integer, max(length(%I)) from %I', tbl, col, width, col, tbl);
   END LOOP;
END
$func$  LANGUAGE plpgsql;

Aufgerufen wird dies mit

select * from character_varying_length()

und liefert dann 4 Spalten für alle character varying felder im Schema public:

Screenshot Abfrage

Ergebnis der Abfrage der Funktion

Diese Funktion funktioniert in jeder Postgres-Datenbank, einfach deklarieren und aufrufen wie oben.

Everything a Java Developer Should Know about the JavaScript Landscape

Als altgedienter Java-Programmierer ist mir die schnelle Evolution im Bereich HTML5, CSS3, Single Page Anwendung und Javascript oft suspekt. Was heute noch angesagt ist, ist morgen schon old school. Mit Entwicklung in Apache Wicket, mit dem ich gerne arbeite, bin ich ja auch ein Vertreter des alten serverzentrierten Ansatzes. Trotzdem bleibe ich am Ball und schaue mir die neuen Tendenzen und Hypes an.

Geertjan Wielenga hat auf der JAX London eine gute Präsentation zum Thema gehalten. Auch wenn ich nicht alle seine Tipps sofort akzeptiere (bei Tipp 8 und 9 kriege ich Gänsehaut) oder für richtig halte, sind seine Überlegungen und Empfehlungen sehr wertvoll.