Boehrsi.de - Blog

Während ich aktuell mal wieder in der Android-Welt unterwegs bin (leider noch mit Java, aber mein nächstes Projekt wird Kotlin) fällt mir mal wieder auf wie wichtig es ist bei Plattformen, Frameworks und auch Programmiersprachen am Ball zu bleiben. Seit dem letzten Update meines aktuellen Projekts ist einige Zeit vergangen und es gibt einfach unfassbar viel nachzuholen. Auf der einen Seite ist dies schön, denn ich habe nun neue Möglichkeiten, auf der anderen steigt die Menge an Änderungen langsam in unangenehme Bereiche (Stichwort: Regressions).

Das Internet bietet viele Möglichkeiten und vor allem als Softwareentwickler ist es die Basis die eigene Software zu verteilen und eine breitere Masse zu erreichen. Dies ist sehr positiv, aber es gibt auch diverse Schattenseiten in diesem konkreten Bereich, die ich heute einfach mal ansprechen möchte.
Mir geht es vor allem um die Art und Weise wie mit Software und Apps umgegangen wird, wenn mal etwas nicht funktioniert. Dabei sollte man vor allem im Hinterkopf behalten, dass man die meiste Software in diesem Bereich gratis bekommt und genau auf diese möchte ich speziell auch eingehen. Hier bekommen Nutzer also kostenlos Software, die ihnen hilft, sie unterhält oder was auch immer für einen Zweck hat und der jeweilige Nutzer entdeckt ein Problem.

Heute gibt es mal wieder neue Geschichten aus der Welt der Softwareentwicklung. Denn am Wochenende war ich mal wieder fleißig und wollte Googles Bitte nach einem Update meiner Android App FileSize nachkommen. Selbige ist aktuell meine einzige gelistete PlayStore App open_in_new und es wurde mal wieder Zeit die Target-Android-Version anzupassen.
Im Rahmen dieser Aktualisierung dachte ich es wäre eine gute Idee Abhängigkeiten zu aktualisieren, Gradle open_in_new einem Update zu unterziehen und diverse kleinere Aufräumarbeiten durchzuführen. Außerdem wollte ich einen seit langem existierenden Bug beheben und ein neues Feature einbauen. Hier und dort gab es bei diesem Plan natürlich Probleme, doch das eigentliche Problem, welches auch Thema dieses Beitrags ist, ist Vergangenheits-Daniel und im Ernst der nervt mich wirklich.

Vor einiger Zeit nahm ich mir die eine oder andere Stunde, um mal in die Programmiersprache Go open_in_new hineinzuschauen. Ergebnis war ein kleiner Web-Service, welcher in meinem Blog als Counter im Hintergrund lief. Der Dienst sammelte dabei keine großen Daten, sondern versuchte zu erfassen wie oft einzelne Unterseiten geöffnet wurden, sowie die gesamte Anzahl der täglichen Besucher zu erfassen. Im Prinzip eine sehr simple Statistik, welche die für mich wichtigen Informationen beinhaltet: Besucher pro Tag und beliebte Artikel für meine Top 10 Beiträge.
Go lieferte dabei eine interessante Basis, da es im Gegensatz zu Java, Kotlin open_in_new und Dart open_in_new teilweise andere Ansätze verfolgt. So war ich in der Lage mit nur sehr wenigen Abhängigkeiten die genannten Funktionen umzusetzen, musste allerdings einiges selber schreiben, was ich bei den genannten anderen Sprachen direkt in Form von vorhandenen Features nutzen konnte. Die initiale Umgewöhnung war zwar nicht einfach, aber ich fühlte mich trotz dessen schnell performant, nachdem die ich die grundlegende leichtgewichtige Idee der Sprache verstanden hatte.

• Go Website open_in_new

Während der Software Entwicklung lernt man viel, teils in Bezug auf neue Programmiersprachen und ähnliches und teils allgemeine Dinge. Zu letzteren zähle ich so etwas wie: “Keine IDE Updates kurz vor einem Release”, nicht “einfach so Libraries aktualisieren” und “das sollte einfach so funktionieren” ist meistens nicht wahr. Die Liste geht noch weiter, quasi unendlich lang, doch worum es mir geht ist diese Lesson Learned auch anzuwenden.
Wir wissen diese Dinge, doch wir vergessen, wir sind im Stress und missachten eigentlich klare Abläufe und dadurch machen wir Fehler. Ich selber habe erst vor kurzem auf meinem privaten System ein Update von IntelliJ Idea 18.1 auf 19.2 gemacht, ohne auch nur eine Sekunde über aktuelle Projekte nachzudenken. Dies wurde natürlich prompt damit quittiert, dass das Projekt nicht mehr baute und ich erstmal das Projekt und die IDE debuggen musste, statt ein neues Feature zu entwickeln.
Um Lessons Learned anwenden zu können muss man sich erst einmal an sie erinnern, somit hilft es im ersten Schritt sie aufzuschreiben. Egal ob in einem Wiki oder auf einem Post-It am Monitor, man sollte den für sich persönlich richtigen Platz finden. Denn hier geht es vor allem um Sichtbarkeit im Alltag. Im nächsten Schritt versuche ich aktuell meine Aufzeichnungen zu bestimmten Kontexten von Zeit zu Zeit erneut zu betrachten, denn was hilft die beste Dokumentation, wenn man sie nicht liest. Um die entsprechenden Dinge dann final anwenden zu können bleibt eigentlich nur der gesunde Menschenverstand. Nicht überstürzt handeln, Backups erstellen, erst prüfen ob z.B. mit Updates Probleme bekannt sind und ähnliches kann helfen Probleme zu vermeiden. Auch Automatisierung in Form von Skripten oder ähnlichem kann hier und da vor Fehlern schützen. Generell fasse ich für mich die Abläufe in Document (z.B. Wiki), Repeat (regelmäßig erneut lesen), Apply (denken und anschließend handeln) und Protect (Skripte, Berechtigungen restriktiv setzen) zusammen.
Mich würden eure Lesson Learned im Bereich der IT interessieren und ich würde mich freuen einige in den Kommentaren finden zu können, denn wir alle lernen nicht aus.

Solltet ihr euch für die Entwicklung von Apps oder generell Software für mobile Plattformen interessieren, könnte der Herbst vielleicht etwas Interessantes für euch bereithalten. Denn der Mobile DevGuide soll, sofern alles wie geplant läuft, im Herbst in einer neuen Version erscheinen (via Twitter open_in_new) und euch einen rundum Einblick zum Thema Mobile Development geben. Vor allem falls ihr neu in diesem Bereich seid oder falls ihr mal etwas neues ausprobieren wollt, dürfte dieser große Überblick vielleicht hilfreich für euch sein. Das Ganze wird wieder kostenlos zur Verfügung stehen und vermutlich sowohl online, wie auch als Print-Version erscheinen.
Ich freue mich auch dieses Jahr wieder bei der Entstehung des Guides zu helfen und kann euch nur empfehlen einen Blick hinein zu werfen, sobald die neue Version erscheint. In der Zwischenzeit könnt ihr die letzte Ausgabe in den Related Links finden, ebenso wie weitere Informationen zum Projekt, den Autoren und Möglichkeiten selbst involviert zu werden. Falls ihr Fragen habt meldet euch einfach direkt in den Kommentaren.

• Mobile DevGuide Website open_in_new
• Mobile DevGuide auf Twitter open_in_new

Niemand weiß alles und deswegen ist es in der Softwareentwicklung meiner Meinung nach sehr wichtig eine aktive Community zu haben. In einer solchen kann man sich bezüglich der genutzten Sprache, Frameworks und ähnlichen Dingen austauschen. Denn auch wenn es Dokumentationen gibt, die erklären wie man performant eine Sprache nutzt oder wie man in einem Framework konkrete Use-Cases umsetzen kann, so gibt es zu viele unterschiedliche Aufgaben, als das alles dokumentiert sein könnte.
Community-Portale wie Stack Overflow open_in_new, Gitter open_in_new oder auch öffentliche Slack oder RocketChat Channels bieten hier eine Möglichkeit sich asynchron oder synchron auszutauschen und sich gegenseitig zu helfen. Vor allem Stack Overflow dürfte fast jedem Entwickler ein Begriff sein, denn z.B. im Android Bereich findet man quasi alles was man braucht dort.

Obwohl ich aktuell eigentlich viel im Coding Bereich zu sagen hätte, komme ich zurzeit leider nicht wirklich dazu umfangreiche I’m a coder Beiträge zu erstellen. Doch heute nehme ich mir, bei entspannten 32°, einfach mal wieder etwas Zeit.
Thema ist heute die Erstellung von Grafiken und Diagrammen zur Erklärung von Konzepten oder Abläufen innerhalb von Software. Denn wer kenn es nicht, man hat Software entwickelt, verschiedene Konzepte und Ansätze angewendet und dann vergehen einige Monate und vieles gerät in Vergessenheit oder aber ein neues Teammitglied möchte eingearbeitet werden. Bei mir trifft aktuell beides zu, denn bei meinen privaten Projekten vergesse ich durch häufige Kontextwechsel gerne Dinge und auf der Arbeit versuche ich gerade neue Kollegen in mein aktuelles Projekt einzubinden.

Durch meine Besuche in der Flutter Welt bin ich in der letzten Zeit offener für neue Sprachen, neue Ansätze und Versuche selbige bei meinen aktuellen Projekten einzusetzen. Entsprechend baue ich gerade ein kleines privates Projekt in Flutter und sammle dabei Ideen für eine Tutorial / How To Reihe zu Flutter und der Entwicklung mit Googles Cross-Platform Framework.
Doch nicht nur Dart, was die Basis von Flutter ist, ist aktuell ein Thema für mich. Auch Go ist ein sehr wichtiges Thema für mich, denn ich schreibe gerne Microservices. Entweder für meinen Blog oder für andere Projekte die ich noch plane oder bereits umsetze. Und für diese Art von Projekten ist Go extrem praktisch. Ideen habe ich viele, Zeit leider eher wenig.
Doch durch einige lange Wochenenden hatte ich in den letzten Wochen etwas Zeit, mir vor allem Go mal etwas näher anzusehen und war sehr angetan. Denn vieles von dem was ich plane kann Go, teilweise von Haus aus und ohne zusätzliche externe Abhängigkeiten. Ein Umstand der kein Muss ist, aber durchaus praktisch sein kann. Alles in allem freue ich mich auf jeden Fall die Zeit investiert zu haben, denn insgesamt bin ich glaube ich auf längere Sicht schneller und kann bessere Software schreiben, als ich mit Java umsetzen könnte.

• Flutter Website open_in_new
• Dart Website open_in_new
• Go Website open_in_new
• Kotlin Website open_in_new

Egal wie gut ein neuer Editor oder eine neue IDE ist, neue Shortcuts sind immer problematisch. Denn eben diese machen die meisten Programmierwerkzeuge erst wirklich performant in der täglichen Nutzung. Doch meistens unterscheiden sie sich in den verschiedenen Tools und können so für die eine oder andere Verwirrung sorgen.
Ich habe bekanntlich vor kurzem angefangen VSCode zu nutzen und interessiere mich entsprechend für die dort genutzten Shortcuts. Selbige unterscheiden sich wie erwartet teils stark von IntelliJ Idea, bzw. Android Studio. Aus diesem Grund freue ich mich sehr das es einen übersichtlichen Cheat Sheet gibt, welchen ich für ebenfalls interessierte in den Related Links hinterlegt habe. Es ist darüber hinaus natürlich auch möglich Shortcuts in den Einstellungen zu ändern, dies ist mir persönlich aber meist zu aufwendig.
Was allerdings sehr spannend ist, ist die Möglichkeit komplette Keymaps aus dem Marketplace einzubinden. Dies geht direkt in VSCode oder aber über die Marketplace Website (siehe Related Links). Ein extrem praktisches Feature, da man sich den Editor entsprechend der eigenen Gewohnheiten anpassen kann.

• VSCode Website open_in_new
• VSCode Shortcut Cheat Sheet open_in_new
• VSCode Marketplace (Keymaps Kategorie) open_in_new