Boehrsi.de - Blog

Falls ihr ein GitHub Projekt betreibt und dieses einfach in Szene setzen wollt, solltet ihr euch GitHub Pages mal näher ansehen. Den Dienst gibt es schon recht lange, nur ich kam bis dato nicht in die Verlegenheit ihn wirklich zu kennen. GitHub Pages ermöglicht euch direkt in eurem Git und unter direkter Bereitstellung einer passenden Domain, die Erstellung einer Homepage für das Projekt. Dabei könnt ihr selber Dinge schreiben und entwickeln oder z.B. wie ich die README.md importieren und eines der vorhandenen Template-Designs wählen. Heraus kommt die Präsentationsseite open_in_new für mein kleines Tool Resizy. Meiner Meinung nach ist dies eine wirklich gute Möglichkeit um Projekte oder auch Personen / Organisationen zu präsentieren und gleichzeitig den Aufwand für den Nutzer möglichst gering zu halten. Wie sieht es bei euch aus, habt ihr diesen Dienst schon einmal genutzt und was haltet ihr allgemein davon?

Caching ist wichtig und erspart unnötiges Laden von Inhalten. Will man dies serverseitig tun wirft man, durch Einträge in die Apache Config oder .htaccess Datei, diverse Dateiformate in eine Liste und lässt diese für einen definierten Zeitraum cachen. Doch was ist wenn sich tatsächlich Inhalte ändern und man diese direkt ausliefern will. Vor allem an CSS oder andere statische Dateien denke ich dabei. Auch Bilder sind ein beliebtes Beispiel. Diese Inhalte sollen definitiv nicht jedes Mal frisch an den Nutzer gesendet werden, aber gerade bei Updates der Homepage oder neuen Inhalten möchte man selbige natürlich auch sofort sehen. Auch beim Entwickeln ist dies hilfreich, wobei man dort in diversen Browsern das Caching auch komplett deaktivieren kann. Lange Rede, kurzer Sinn, ich nutze nun einen sehr einfach Ansatz, wie er von Stefan Hayden open_in_new beschrieben wird und im unteren Teil der News von mir noch einmal erläutert wird.

Dieses Mal gibt es tatsächlich eine Frage bei der Weekly Coding Question. Denn der grundsätzliche Gedanke alles selber zu machen ist manchmal gut, da man einiges lernen kann, doch häufig geht das auch nach hinten los. Denn oft macht man sich mehr Arbeit und gleichzeitig ist das Endprodukt bei weitem nicht so gut wie man es von vorhandenen oder etablierten Lösungen kennt. Mir persönlich ist dies im Coding- und Protokollbereich erst vor wenigen Tagen wieder aufgefallen. Denn ich arbeite gerade an einer etwas umfangreicheren Serverlösung im Java Bereich und brauche dementsprechend eindeutige Responses, die die Clients entsprechend verarbeiten können. Dies gilt natürlich auch für Fehlermeldungen. Während ich nun Basisklassen für die Serverantworten erstellte, baute ich auch Antwort-Codes und -Nachrichten ein. Dies sah im ersten Moment sehr sinnvoll aus, doch im zweiten ist dies mehr oder weniger Schwachsinn. Ich arbeite mit JSON Objekten auf HTTP und habe somit alle Error-Codes die ich brauche und die Nachrichten kann ich ohnehin entsprechend definieren. Bewegt sich die Antwort im 2xx Bereich ist alles gut und ansonsten schmeiße ich einen passenden 4xx oder ähnliches und ergänze den Grund des Fehlers. Somit kommt der Client nicht durcheinander und weiß früh ob ein Request erfolgreich war. So offensichtlich wie diese Lösung ist, so verwunderlich ist es, dass man immer wieder selbst versucht Dinge zu implementieren, die es bereits gibt und mit denen man mitunter täglich arbeitet. Ich frage mich wie ich mich in diesem Bereich “bessern kann”, denn an zu wenig grundsätzlichem Wissen liegt es ja nicht. Habt ihr manchmal ähnliche Probleme oder vielleicht sogar Vorschläge wie man dagegen vorgehen kann?

Ich hoffe die Überschrift klingt nicht zu reißerisch, denn allgemein ist JavaScript natürlich eine feine Sache. Dies gilt obwohl es von Werbenden und Virenverbreitern gerne mal unnötig verwendet wird. Unabhängig davon kann man mit JavaScript extrem interessante Sachen machen. Angefangen im Browser des Users und bis hin auf die Server-Ebene, durch Ansätze wie z.B. den MEAN Stack open_in_new. Ich selber hatte in den letzten Tagen häufiger das Vergnügen und konnte mit relativ wenig Aufwand einiges erreichen. Konkret angewendet habe ich AngularJS open_in_new, welches ja noch einmal einiges anders macht als “normales” JavaScript. Doch egal welche “Art” von JavaScript ich einsetzte und egal wie schnell man einiges erreichen kann, ich werde nicht richtig warm mit dieser Sprache. Ich finde den gesamten Aufbau irgendwie manchmal etwas sehr unklar, auch wenn er teilweise einfacher ist als man es von z.B. Java kennt. Ich denke mein Problem hier sind meine Wurzeln im Java Bereich, welche quasi meine gesamte Programmiererfahrung geprägt haben. Aber ich werde weiterhin versuchen JavaScript immer mal wieder eine Chance zu geben. In diesem Kontext interessiert mich sehr wie es bei euch aussieht, habt ihr JS genutzt oder nutzt ihr es noch und was ist eure allgemeine Meinung zu dieser Sprache?

Libraries gibt es viele, sogar sehr viele. Diverse klingen extrem interessant und hilfreich. Doch wie gut sind sie, wie stabil und verlässlich funktionieren sie und sollte man sie in produktiven Apps verwenden? Diese Frage stelle ich mir aktuell immer mal wieder, vor allem da ich mich zur Zeit aktiv bezüglich neuen Android Libraries umschaue. Teilweise für konkrete Anwendungsfälle und teilweise einfach weil sie interessant klingen. Mir fällt es dabei, abseits von den großen und bekannten Libraries, allerdings sehr schwer zu entscheiden was gut ist und was nicht. Natürlich kann ich selber in den Quellcode schauen, denn ich bin meistens auf GitHub unterwegs. Dafür fehlt allerdings meistens die Zeit und manchmal auch das Wissen. Was also tun wenn man über eine gute Idee stolpert, aber nicht weiß wie gut sie implementiert und durchdacht ist? Ich selbst teste dann meistens etwas und schaue grundlegend in den Code, doch das kostet besagte Zeit. Habt ihr bessere Ansätze oder Ideen bezüglich diesem Thema? Ich würde mich über Kommentare freuen.

FileSize ist eines meiner ersten richtigen Android Projekt und wird aktuell weiterhin gepflegt. Ich arbeite zur Zeit an einer generalüberholten Version. Diese ändert extrem viele Dinge im Kern der App und macht sie dadurch stabiler und schneller. Außerdem setzte ich auf neuere Android GUI Komponenten (Stichwort: RecyclerView anstatt ListView). Dadurch wirkt die UI wesentlich klarer strukturiert und verschiedene Animationen verdeutlichen den Ablauf der App. Diverse Toasts werden durch Snackbars ersetzt und diverse Fehler werden behoben. Mit diesem Teil des Updates bin ich nun so gut wie fertig. Was bedeutet das ich mich den wirklichen Features für den Nutzer zuwenden kann. Dabei plane ich die Suche nach bestimmten Dateitypen zu implementieren und eine Mehrfachauswahl für Dateien soll eingebunden werden. Ob dies alle Features sind oder ob ich selbige noch abändere wird sich zeigen. Fakt ist das ich das Update relativ bald veröffentlichen will und dementsprechend irgendwann einen Feature Freeze brauche und einen Test beginnen kann. Sofern alles nach Plan läuft wird es das Update Ende Mai geben, dann mit allen genannten Funktionen und vielleicht noch etwas mehr. Weitere Informationen zu diesem kleinen Projekt von mir gibt es in den Related Links.

Im Android Studio Bereich gehe ich aktuell gemäß der Neu ist immer besser Regel vor. Soll heißen ich nutze die jeweils aktuelle Preview Version. Vor einiger Zeit benötigte ich dies für verschiedene neue und für mich wichtige Funktionen. Seitdem bin ich einfach dabei geblieben, weil das ganze eigentlich recht stabil und bis jetzt ohne große Probleme läuft. Der neuste Release ist der Release Candidate für die Version 2.1 von Android Studio. Dieser deckt sich quasi komplett mit der Version 2.0, bietet aber die Möglichkeit mit der Android N Preview genutzt zu werden. Neben einigen behobenen Fehlern aus den letzten Alpha und Beta Veröffentlichungen der Version 2.1, gibt es im aktuellen Release noch einige Instant Run Performance Verbesserungen. Ansonsten hat sich nicht viel getan und ich persönlich konnte auch keine Probleme feststellen

Nach diversen Alphas und Betas, ist vor wenigen Tagen die finale Version 2.0 von Android Studio erschienen. Diese enthält diverse Neuerungen. Eine der wichtigsten dürfte Instant Run sein. Dieses Feature bringt euch, wie schon öfters angesprochen, diverse Geschwindigkeitsvorteile beim bauen eurer Apps. Das dürfte sehr viele Nutzer freuen, denn die Wartezeit bis die App auf euer Gerät deployed werden kann ist immer wieder extrem störend. Ein weiteres extrem gutes Feature ist der komplett neue Emulator. Dieser ist schneller und zwar wesentlich. Ich würde fast schon sagen man kann ihn nun fast wie ein normales Gerät nutzen, wobei dies natürlich nur mit Einschränkungen gilt. Denn neben der reinen Geschwindigkeit, gibt es einfach Dinge für die man ein richtiges Smartphone braucht. Weiterhin gibt es nun die Cloud Test Lab Integration und mittels der App Indexing Code Generation soll euch Arbeit erspart werden, sofern ihr vorhabt eure App in die globale Suche eures Smartphones zu integrieren. Solltet ihr im Bereich Android-Spiele unterwegs sein, dürfte euch der GPU Debugger helfen, auch wenn er aktuell noch als Preview vorliegt. Abschließend bringt diese Version den Sprung auf IntelliJ Version 15.

Falls ihr mit JPA (Java Persistence API open_in_new) in euren Java Projekten arbeitet, dürfte der JPA Diagram Editor für euch interessant sein. Er ermöglicht die Visualisierung und Manipulation von Beziehungen und dem Aufbau eurer Entities. Ich brauche ihn für mein aktuelles Java Server Projekt, allerdings auch nur zur Visualisierung. Denn die eigentlichen Entities, die Beziehungen und was es sonst noch alles in diesem Bereich gibt, mache ich doch lieber selber. Schließlich spielt Spring dort auch eine Rolle und ich möchte die spezifischen Annotations nutzen, anstatt automatisch generierte, welche vielleicht nicht immer passen. Doch nun zum eigentlichen Thema, der Nutzung des JPA Diagram Editors mit der aktuellen Eclipse Version (Mars). Denn dies geht, zumindest für die GUI Komponente und die Visualisierung, nicht wenn man es einfach über die Software-Verwaltung installiert. Denn das Plugin und die Libraries dahinter sind aktuell noch in der Entwicklung. Nach längerer Suche habe ich im Eclipse Forum open_in_new aber eine Lösung entdeckt. Der Bug open_in_new allgemein ist übrigens bekannt und wird auch schon bearbeitet. Im unteren Teil findet ihr die kurze Anleitung zur Lösung des Problems.

Vor einiger Zeit hatte ich es bereits erwähnt, nun habe ich während meines Urlaubs endlich die ersten Schritte gewagt. Denn nach ersten Erfahrungen mit Spring Boot und Java Servern auf der Arbeit, habe ich nun ein größeres privates Projekt gestartet. Was es konkret wird kann ich aktuell leider noch nicht sagen, aber zumindest welche Techniken, Software-Grundlagen und Frameworks ich nutze, kann ich schon einmal vorstellen. Dieses Projekt ist auch der Grund warum ich aktuell etwas weniger News schreibe als sonst, da es doch die eine oder andere Stunde meiner Freizeit frisst.