Boehrsi.de - Blog

Bereits seit Anfang der Woche ist die neue Boehrsi.de Version online. Dieses Mal gibt es einige UI Änderungen und gleichzeitig wurde einiges im Backend getan. Beginnen möchte ich mit den offensichtlichen Dingen. Allem voran sind hier die neuen Material Design Icons zu erwähnen. Diese werden von Google zur Verfügung gestellt und werden nun in den News, Projekten und auch in meinem Kontaktbild verwendet. Sie sind schlicht, ansprechend und vermitteln gut wofür sie stehen. Weiterhin wurden diverse Unterseiten überarbeitet. Darunter fällt die Übersicht der Sammlungen, die Detailansicht von Projekten und Downloads, sowie die Bugtracker-Ansicht. Außerdem wurden auf ca. 40% aller Unterseiten kleinere Änderungen durchgeführt, die sich zum Teil auf die Konsistenz des Designs und zum Teil auf die Darstellung in der mobilen Version positiv auswirken. Die News haben nun Quellen-Informationen für genutzte Bilder und die Related Links werden platzsparender angezeigt. Für mich selbst habe ich meinen Admin-Bereich erweitert, was auch für euch Vorteile bringen wird, denn dadurch kann ich besser und fehlerfreier arbeiten. Das wichtigste kommt zum Schluss, denn Boehrsi.de ist durch die Nutzung von Lets Encrypt open_in_new als CA nun via HTTPS sicher erreichbar. Die Seite wurde umfangreich getestet, hat ein globales A- SSL Rating open_in_new und nahezu alle Seiten sollten Inhalten, auch von externen Quellen, nur noch über verschlüsselte Kanäle laden. Zur Pflicht habe ich dies aber noch nicht gemacht, da ich nach meinem internen Test, nun erst einmal einen längeren offenen Beta Test machen möchte. Alles in allem bin ich zufrieden und hatte echt Spaß daran mal wieder etwas umfangreicher an meiner Homepage zu arbeiten. Falls ihr Feedback habt oder Probleme entdeckt, nur raus damit, meldet euch einfach in den Kommentaren.

Das Thema der ersten Weekly Coding Question ist Webentwicklung mal anders. Dabei beziehe ich mich wie gewohnt auf mich selbst, soll heißen “anders” ist definiert durch das was ich bis dato gemacht habe. Meine Entwicklung, auf Webseiten bezogen, lief bis dato via HTML und CSS im Frontend und PHP und MySQL im Backend (via Apache Webserver und Linux als OS), kurz gesagt also der altbekannte LAMP open_in_new Stack. Doch es gibt bekanntlich mehr, viel mehr. Doch was schaut man sich an, was wird sich in der Zukunft durchsetzen oder hat sich vielleicht schon durchgesetzt?

Ich habe bereits einige Male über Lets Encrypt berichtet und es natürlich direkt zum Start der offenen Beta selber ausprobiert. Falls ihr nicht wisst worum es geht, Lets Encrypt ist eine CA open_in_new für SSL Zertifikate open_in_new und stellt diese kostenlos aus. Hinter Lets Encrypt stehen große Unternehmen wie Mozilla und Cisco, welche das Ziel haben das Internet sicherer zu machen. Mit dem nächsten Update meiner Homepage kommt neben verschiedenen UI und Backend Verbesserungen, auch eine komplette HTTPS Unterstützung. Komplett heißt in diesem Fall, dass ich sowohl interne wie auch externe Quellen nur via HTTPS anspreche. Bei meinen Tests gab es dabei keine Probleme und ich nutze meine Seite, in der Developer Version, bereits seit einiger Zeit nur via HTTPS. Wie bereits erwähnt wird aber auch im Bereich der sichtbaren Änderungen hier und dort etwas getan. Zusätzlich gibt es größere Änderungen im Backend und einige Fehler wurden behoben. Ich plane das Update noch dieses Jahr auszurollen.

Für meine Homepage nutzt ich bekanntlich PHP, dies ist mit der Zeit so gewachsen und eigentlich läuft soweit auch alles. Doch es gibt immer wieder Dinge die ich optimiere, bzw. welche nicht zu 100 Prozent so laufen wie ich es gerne hätte. Dazu gehört z.B. die Extraktion von Teilen eines Strings. Grundsätzlich ist da natürlich substr() open_in_new dein Freund, doch nur solange das Encoding mitspielt. Denn UTF-8 Zeichen können Multi-Byte Inhalte sein und dadurch ergeben sich interessante Probleme. Denn Umlaute werden, wenn man Pech hat und sie genau über die Grenze eines substr() Aufrufes hinweg gehen, fehlerhaft verarbeitet. Dies kann zu Anzeigeproblemen oder größeren Fehlern führen. Aus diesem Grund empfehle ich dringend mb_substr() open_in_new zu nutzen, was das Multi-Byte Äquivalent zur normalen substr() Funktion ist. UTF-8 nicht zu nutzen ist nebenbei keine Alternative, denn es führt an diversen Stellen zu mindestens genauso vielen Problemen (Stichwort: Emoticons). Es gibt übrigens noch weitere mb_ Funktionen open_in_new, welche man sich definitiv auch mal ansehen sollte.

Wer einen Server hat und auf diesem ein GIT betreibt, der hat mit GitList die Möglichkeit über den Browser diverse Inhalte ansehen zu können. Ich rede dabei nicht von aufwendiger Verwaltung, sondern von einem reinen Viewer. Ich wollte genau dies, um auch online die Commits und Branches einsehen zu können. Ich arbeite zwar alleine an meinem Code, doch selbst dafür ist diese Funktion praktisch. Einzige Anforderung die ich hatte war ein geringer Konfigurationsaufwand und vor allem wenige Abhängigkeiten. Denn ich habe ein relativ komplexes Setup auf meinem Server und möchte dies nicht durch eher unwichtige Dinge negativ beeinflussen. Hier ist GitList sehr praktisch, denn es ist ein reines PHP basiertes Interface, mit wenigen Einstellungen über eine Config in Form einer .ini Datei. Anschließend fehlt nur noch der Upload und die entsprechenden Rechte müssen gesetzt sein. Dabei sollte der Web-User auf den Root-Ordner der Repositories zugreifen dürfen und auch PHP muss die Ausführung dort erlaubt werden (open_basedir open_in_new). Auf der GitList Homepage gibt es ein paar weitere Tipps bei Problemen open_in_new, diese werden z.B. über Änderungen an der htaccess File open_in_new behoben. Bei mir läuft alles gut, abgesehen vom Graphen der für die Commits erstellt wird. Dieser funktioniert bei mir nur für den Master Branch korrekt und ich hoffe dort gibt es noch einen Fix. Allgemein läuft aber alles gut und ich kann einen Test damit nur empfehlen.

Ich programmiere auf der Arbeit und ich programmiere zu Hause. Dabei nutze ich Java für Android, PHP für die Homepage und diverse weitere Sprachen. Dazu die nötigen Tools, IDEs, Toolchains und was es nicht noch alles gibt. Außerdem schaue ich mir gerne neue Techniken an. Egal ob komplett neue Sprachen, Architekturmuster oder allgemeine Entwicklungsansätze. Doch es gibt unglaublich viel in diesem Bereich und man hat ja leider nur begrenzt Zeit. Aus diesem Grund muss man sich oft entscheiden. Diese Entscheidungen, die Wege zu diesen und vielleicht auch die eine oder andere Diskussion, die ich eigentlich mit mir selber führen würde, möchte ich gerne mit euch teilen. Dabei wird es nicht wie in den meisten News ein Problem mit einer Lösung oder eine reine Info geben, sondern meine Gedankengänge und meine Ideen. Nicht unbedingt abschließende Entscheidungen, sondern eher Ansätze und Möglichkeiten solltet ihr von News dieser Reihe erwarten. Ich persönlich erhoffe mir den einen oder anderen Kommentar und neue Ansichten zu Themen die ich interessant finde. Denn genau diese Gespräche in den Kommentaren sind für mich der Lohn den ich bekomme, wenn ich diesen Blog betreibe. Ich plane einmal pro Woche, zum Wochenende hin einen Beitrag zu veröffentlichen. Ca. fünf Themen habe ich bereits, falls ihr Vorschläge habt bin ich wie gewohnt aber auch offen für diese.

Linux hat auf für mich als Windowsnutzer einen Vorteil, eine gute Scripting Umgebung und das seit langer Zeit. Die Shell ist mächtig, die Syntax brauchbar und man kann quasi alles automatisieren was man möchte. Doch nur weil man ein Script schreibt und dieses vielleicht auch funktioniert, heißt dies nicht das es sicher oder fehlerfrei ist. Deswegen empfehlen sich Tools zum überprüfen des Codes, doch dies vernachlässige ich zumindest oft bei Shell-Scripten. Denn ich schreibe sie häufig direkt in nano open_in_new oder aber in Notepad++ open_in_new, wenn ich von einem Windows System aus Remote arbeite. Doch da kam mir ein guter Tipp eines Arbeitskollegen zu Hilfe, denn dieser empfahl mir ShellCheck. Ein simples online Tool, welches übersichtlich und schnell Fehler aufzeigt und bei Bedarf auch lokal installiert werden kann. Dabei wird nicht nur auf Fehler hingewiesen, auch Verbesserungsvorschläge werden gegeben. Ich habe basierend darauf einiges optimiert und kann nur sagen es funktioniert super. Allerdings sollte man alle “automatischen” Tools mit Vorsicht genießen und ihnen nicht komplett blind vertrauen. Im Zweifel lieber einmal zu viel testen und sich schlau machen, als einmal zu wenig.

Wer Software entwickelt verbringt die eine oder Minute mit dem Warten auf die Durchführung des Build Prozesses. Dies ist nun mal so und schnellere Wege sind meistens sehr teuer und häufig nicht zu 100 Prozent wie man sie gerne hätte. Doch nun hat Google angekündigt, dass Android Studio 2.0 eine Instant Run Funktion bekommt. Soll heißen, ihr ändert Code oder Ressourcen und nach wenigen Sekunden sind die Änderungen auf eurem Gerät. Kein langes Warten und keine komplette Neuinstallation ist mehr nötig. Natürlich gibt es hier und dort Ausnahmen und aktuell ist gerade mal die erste Preview Version, mit nur einem Teil der späteren Möglichkeiten verfügbar, aber das ganze klingt auf jeden Fall sehr gut. Ich werde die Tage mal in die Preview rein schauen und freue mich bereits auf die fertige Version.

Neben den Coding Guidelines sollte man auch auf ein konsistentes Design achten. Denn auch wenn vielleicht nicht alles was in den gegebenen Regelwerken beschrieben ist auf die eigene App angewendet werden kann, so gibt es diverse Dinge die man zumindest etwas beachten sollte. Abstände, die Größe von Objekten, Farbkompositionen und bestimmte Usability Tipps sollte man deswegen gelesen und nach Möglichkeit auch verstanden haben. So nutze ich gerade die Tipps zu Metrics & Keylines open_in_new, um eine meiner alten Apps aufzupolieren. Sie sieht dadurch wesentlich besser aus und wird auch bald im Store präsentiert, bzw. hier im Blog erwähnt. Ihr könnt euch dann ja selber ein Bild machen. Allgemein kann ich nur empfehlen sich die Dinge, die von Google zu Material Design als Informationen zur Verfügung gestellt werden, zumindest grundlegend anzusehen. Sie sind in englisch verfasst, mit diversen Bildern zu Erklärung versehen und dürften vielen Problemen und Fragen im Bereich Design entgegenwirken.

Also Android Entwickler ist es durchaus interessant das Android Studio 1.5 veröffentlicht wurde. Dabei sollt es egal sein ob man professionell oder nur als Hobby Android Apps entwickelt, denn aktuelle und verbesserte Software gefällt uns doch allen. Android Studio 1.5 bringt diverse neue Lint Checks, z.B. für Android TV, Android Auto und verschiedene unsichere Funktionen. Innerhalb von XML Dateien können CustomViews nun mit ihrem kurzen Namen (ohne Package usw.) via Autovervollständigung genutzt werden und der Memory Monitor wurde optimiert. Einige weitere neue Features wurden eingefügt (Deep Link und App Link Support, Support für weitere VectorDrawables) und wie gewohnt diverse Bugs behoben. Weitere Informationen findet ihr in den Related Links.