Boehrsi.de - Blog

Über Coding Guidelines schreibe ich in letzter Zeit häufiger, da sie wichtig sind und hin und wieder auch mal das eine oder andere Ärgernis mit sich bringen. Doch alles in allem sollte man sich, wenn auch selbst definiert, an eine Art von Coding Guidelines halten. Dabei wäre es natürlich ideal, wenn man nicht alleine gemäß den gewählten Regeln schreibt, vor allem wenn man mit anderen zusammenarbeitet oder sogar ein Open Source Projekt betreibt oder unterstützt. Auf der Arbeit wurde ich auf die Google Java Style Guidelines hingewiesen, die angenehm kompakt und übersichtlich sind. Ich persönlich werde mir selbige mal umfangreich zu Gemüte führen und könnte mir vorstellen, dass sie dem einen oder anderen von euch auch helfen könnten.

Meine letzte News zum Thema Android Studio hatte den Release von Android Studio 2.0 - Beta 2 zum Thema und seitdem ist mal wieder einiges geschehen. In der Beta 3 gab es vor allem Bugfixes und wenig neues. Beta 4 änderte die Art und Weise wie man die Instant Run Einstellungen festlegt (von Projektebene zu einer globalen Einstellung) und diverse Verbesserungen im Bereich Instant Run wurden vorgenommen. Auch die Betas 5 und 6 hatten als Hauptthema Instant Run und die Verbesserung dieser Funktion, wobei letztere Beta auch einige konkrete Verbesserungen bietet. So sind nun multiple Prozesse wieder nutzbar, wenn auch ohne die Instant Run Optimierungen und Probleme mit dem Ausführen der App via IDE, falls die App im Hintergrund war, wurden aus der Welt geschafft. Der aktuelle Release 2.1 - Preview 1 ist zwar laut laut den Entwicklern ein Minor Release, bringt aber Android N Support, unterstützt den neuen Jack Compiler und bietet auch die bereits erwähnten neuen Java 8 Funktionen. Auch der Emulator wird mit diesem Release weiter optimiert und kann mit der Android N Preview genutzt werden. Einige Einschränkungen gibt es leider, denn Instant Run kann leider noch nicht mit Jack genutzt werden, ebenso wie diverse anderen Tools die auf .class Dateien arbeiten. Außerdem sind einige Debugging Funktion in Verbindung mit Android N aktuell nicht verfügbar.

Dieses Mal gibt es eher ein Meta Thema, denn es geht nicht direkt um die Programmierung von Software. Ich habe aktuell das Problem, dass ich ein laufendes Projekt habe, welches ich gerne umfangreich aktualisieren würde und damit auch schon begonnen habe. Zusätzlich habe ich ein kleineres Projekt, welches ich gerne beginnen würde. An dritter Stelle steht ein weiteres, größeres Projekt, welches ich auch nicht komplett alleine umsetzen werden (Server - Client Struktur und einer der verfügbaren Clients wird von einem Kollegen / Kumpel entwickelt). Doch bekanntlich hat der Tag nur 24 Stunden, davon arbeitet man die eine oder andere und am Wochenende gibt es ja auch immer mehr zu tun als einem lieb ist. Deswegen nutze ich meistens die späten Abendstunden, nachdem ich eine Runde mit meinen Kumpels gezockt habe, um die Entwicklung zumindest etwas voran zu bringen. Doch wie priorisiere ich die internen Projekte? Rein nach Lust gehen ist keine gute Idee, denn dann würde ich wohl niemals mit einem konkreten Projekt fertig werden. Deswegen die Frage an euch da draußen, ob ihr für euch persönlich Prioritäten bei euren Projekten setzt und wenn ja wie. Ich denke aktuell es ist sehr gut das ich ein Projekt habe, bei welchem ich nicht alleine bin. Dadurch hat man doch noch etwas mehr Motivation und kommt hoffentlich kontinuierlicher voran. Trotz diesem Fakt sollten die anderen Projekte natürlich nicht vergessen werden. Irgendwie eine Zwickmühle für die ich das perfekte Vorgehen noch nicht gefunden habe.

Der Mobile Developer’s Guide To The Galaxy ist in Version 16 erschienen. Dieses kleine Buch bringt euch einen breiten Einblick in die Welt der Entwicklung, des Entwurfs und des Designs von Apps und mobilen Anwendungen. Im Prinzip also alles was auf Smartphones und Konsorten unterwegs ist. Dabei eignet es sich hervorragend, um einfach mal über den Tellerrand zu schauen und sich zu informieren. Neben dem was es auf der eigenen Plattform so neues gibt, lernt man auch viele allgemeine Dinge und erfährt was bei der Konkurrenz so geht. Vielleicht kommt der eine oder andere neue Blickwinkel dazu und zu lernen gibt es auf jeden Fall einiges. Diverse Autoren haben gemeinsam an diesem Werk geschrieben und machen es so zu einem sehr vielseitigen Buch. Ich kannte es bereits aus meiner Studienzeit und finde es somit umso lustiger, dass ich nun in der Firma als Entwickler gelandet bin, welche diesen Guide erstellt und veröffentlicht. Falls ihr Interesse habt freut euch, der Guide ist kostenlos über diverse Wege verfügbar, wobei der einfachste wohl der PDF Download direkt von der unten verlinkten Homepage ist. Ich selber habe mir natürlich ein analoges und gedrucktes Exemplar geholt.

In der letzten Zeit gab es wirklich viele Android Studio Updates, zumindest wenn man die Canary Builds nutzt. Über die Versionen 5 und 6 schrieb ich zuletzt, nun sind wir bereits bei Beta 2. Dazwischen gab es die Alphas bzw. Canary Builds 7 bis 9. In diesen wurde neben dem allgemeinen Update auf IntelliJ IDEA 15.0.3, diverse Fehlerbehebungen durchgeführt. Vor allem auf Instant Run, Multi-Dexing und allgemein langsame Builds wurde geachtet. Leider gab es in diesen Builds etwas mehr Probleme, als in den vorherigen Versionen. Dies liegt vor allem an den Optimierungen im Bereich Instant Run, da hier ziemlich komplexe Dinge durchgeführt werden und diese noch nicht so funktionieren wie man es sich wünscht. Teilweise wurden deswegen einige Funktionen wieder deaktiviert. Die Beta 1 wurde komplett übersprungen, da auf den letzten Metern ein Blocker gefunden wurde und nun befinden wir uns auf der aktuellen Version Beta 2. In dieser wurde an der Performance geschraubt und der Support für komplexe Code Generierung (z.B. durch Dependency Injection open_in_new via Dagger 2 open_in_new) wurde wieder stabilisiert. Denn gerade in diesem Bereich gab es in den vorherigen Versionen, wie ich leider selber feststellen musste, diverse Instabilitäten. Instant Run soll nun wieder stabiler laufen und auch diverse Probleme mit Addons wurden behoben. Als Hinweis wird angegeben, dass zuvor via Debug installierte Apps einmalig deinstalliert werden sollten, um Probleme mit Instant Run zu vermeiden. Falls ihr übrigens immer mit realen Geräten arbeitet, kann ich nur empfehlen mal wieder einen Blick auf den Emulator zu werfen, dieser ist verdammt schnell geworden und kann nun wesentlich mehr. Weitere und detailliertere Infos gibt es in den Related Links. Im unteren Teil der News habe ich noch ein Youtube Video eingebunden, dieses gibt einen schnellen Einblick in Android Studio 2.0.

Coding ist ein wichtiges Thema in meinem Blog. Denn sowohl beruflich, wie auch privat, beschäftige ich mich mit Software-Entwicklung. Dabei habe ich verschiedenste Interessen in diesem Bereich und teile diese gerne mit euch, egal ob es um Linux Server oder Raspberry Pis und dazugehörige Shell Scripte geht oder aber um Java, Android und Web-Entwicklung. Da ich erschreckender Weise bis dato keiner direkte Kategorie für diesen Zweck hatte, habe ich dies nun nachgeholt. Ich bin alle alten News grob durchgegangen und habe sie, falls dies passend war, direkt in die neue Kategorie eingeordnet. Vor allem aber neue Beiträge werden dort von nun an landen, was Interessierten die Suche nach spezifischem Content im Blog einfacher machen sollte.

Eine neue Weekly Coding Question ist da und dieses mal soll es um neue Techniken gehen, die einfach so gut erscheinen, dass man sich direkt einen Einsatzzweck suchen will. Mir ist in diesem Kontext ReactiveX über den Weg gelaufen. Falls euch ReactiveX nichts sagt, im Prinzip ist es eine Möglichkeit, um mit diversen Sprachen asynchrone Programmierung auf eine optimierte und nachvollziehbare Art durchzuführen. Dabei wird das bekannte Observer Pattern open_in_new angepasst und mit Ansätzen des Iterator Pattern open_in_new und einigen Dingen aus der Funktionalen-Programmierung open_in_new kombiniert. Heraus kommen sogenannte Streams, welche Überwacht werden können und je nach Event reagiert das Programm. Dabei wir nicht das eigentliche Programm nicht geblockt und auch während der weiteren Event-Verarbeitung, in eigenen Threads, kann auf weitere Ereignisse reagiert werden. Die Rückmeldung erfolgt erst nach Bearbeitung des eigentlichen Ereignisses. Klingt grundsätzlich gar nicht so “neu”, doch wenn man sich das ganze ansieht und die Technik + Umsetzung versteht, bekommt man finde ich Lust es direkt zu nutzen. Vor allem wenn man die Möglichkeit der Manipulation der Streams selbst konkreter betrachtet. Ich werde es auf jeden Fall für mein kleines Bildbearbeitungs-Tool Resizy nutzen, denn es arbeitet auf vielen Bildern und durch eine quasi Parallelisierung dieser Aufgabe, kann alles massiv beschleunigt werden. Außerdem bietet sich dies bei einem solchen Programm an, da die Bearbeitung eines einzelnen Bildes unabhängig von allen anderen Bildern ist und es somit nicht zu Problemen kommen kann. Doch auch weitere Einsatzzwecke sind denkbar, vor allem weil ReactiveX unter anderem mit Java, Scala, C#, C++, Clojure, JavaScript, Python, Groovy und JRuby genutzt werden kann. Was sagt ihr zu diesem Ansatz und kanntet ihr ihn schon oder habt ihn sogar schon eingesetzt?

Was gibt es schöneres als einen kleinen Rant open_in_new zum Wochenende, eigentlich vieles ich weiß, aber das muss leider mal raus. Denn immer wieder gibt es die obligatorischen Diskussionen bezüglich IntelliJ IDEA vs. Eclipse und dort natürlich die felsenfesten Meinung, der jeweiligen Nutzer. Das ist an sich eigentlich okay, doch teilweise auch extrem nervig. Denn ich selber war jemand der quasi alles in Eclipse gemacht hat. Angefangen vom puren Java, über Android, Web, bis hin zum Schreiben meiner Masterarbeit in LaTex. Nun nutze ich seit einiger Zeit privat und auf der Arbeit Android Studio und bin extrem zufrieden damit. Android Studio basiert auf dem Konkurrenten IntelliJ und macht vieles gut und ich würde sagen auch besser als Eclipse. Doch trotz diesen Gründen muss ich immer wieder rotieren, wenn ich irgendwo lese oder höre wie total unfähig Eclipse ist und das IntelliJ alles unendlich viel besser macht.

Heute vor einer Woche gab es wieder ein größeres Update im Bereich der Android Studio 2.0 Preview Versionen. Diese laufen aktuell bereits ziemlich stabil und werden bei mir im produktiv Einsatz genutzt. Ich persönlich konnte dabei keine gravierenden Probleme feststellen. Etwas instabil sind dort eher die neuen Gradle + Gradle Plugin Versionen, welche manchmal Probleme beim bauen machen. Doch wie auch immer, zurück zum Update, welches diverse Optimierungen im Instant Run Bereich brachte. Sofern ein direkter Hot Swap nicht möglich ist, ist nun auch der Cold Swap, also eigentlich ein komplett neues Deployment, optimiert wurden. Dabei werden inkrementelle Builds ausgeliefert und somit nach Möglichkeit nur die Änderungen angewendet. Umso neuer dabei die Android Version, umso optimierter kann das ganze geschehen. Dazu gibt es aber mehr auf der Android Tools Project Site open_in_new. Die zweite große Baustelle bei diesem Update war Lint, welches nun wesentlich besser mit “Unused Resources” und der Entfernung von diesen umgehen kann. Zusätzlich wurden die Prüfungen für inkompatible API Calls verbessert und einige weitere neue Checks eingebaut. Abschließend wurde in diesem Update noch am Data binding, den experimentellen Test Artifacts und der Code completion gearbeitet. Ein durchaus großes Update, welches hier und dort wohl auch ein paar Probleme einführte. Diese werden in Version 6, welche heute veröffentlicht wurde, angegangen. Version 6 ist somit ein reiner Bug fix Release. Sobald ich meine nervige Erkältung hinter mir habe, werde ich die neue Version natürlich auch wieder ausgiebig testen und falls nötig über eventuelle Probleme berichten.

Mit ein wenig Verspätung erscheint heute die zweite Coding Question (ich sollte mir vielleicht den Zusatz “Weekly” noch einmal durch den Kopf gehen lassen). Aber wie auch immer, hier nun mein zweiter Beitrag zu Dingen, die mich im Coding Bereich beschäftigten. Dieses Mal geht es um CSS und um genauer zu sein, um Präprozessoren für Cascading Style Sheets. Was diese machen ist recht einfach, sie ermöglichen euch CSS Code hoffentlich besser und schneller zu schreiben. Dabei bekommt ihr neue Möglichkeiten, erweitert die “Sprache” also quasi und bekommt am Ende trotzdem normalen und überall nutzbaren CSS Code. Dies geschieht durch die Verarbeitung durch z.B. Sass oder less, was meinem Empfinden nach die größten Präprozessoren im CSS Bereich sind. Nun nutze ich CSS für meine Homepage und dies wird sich in der nächsten Zeit wohl auch nicht ändern. Also stelle ich mir die Frage, wie ich die Erstellung meines CSS Codes optimieren kann.