Wer in der Android-Welt unterwegs ist dürfte bereits über Kotlin gestolpert sein, die neue moderne Sprache von JetBrains open_in_new (IntelliJ und Android Studio Entwickler). Die Sprache kompiliert zu JVM kompatiblen Code und wird offiziell von Google unterstützt. Aufgrund der Herkunft ist natürlich auch Android Studio in der Lage Kotlin Code zu erstellen und zu kompilieren.
Ich persönlich habe mir die Sprache etwas angeschaut und auf der Arbeit einer Kotlin Teaching Session beigewohnt. Die Sprache ist interessant, hat wirklich gute Konzepte und dürfte Boilerplate Code teilweise massiv minimieren. Doch es ist und bleibt eine neue Sprache, die gelernt und vor allem verstanden werden will. Für mich würde Java Programmierung an anderer Stelle weiterhin Pflicht sein (in Projekten abseits von Android), sodass ich diverse Kontextwechsel kompensieren müsste.
Weiterlesen…
Related Links
Eine App sollte keine Crashes produzieren. Diese Aussage ist denke ich für jeden erfassbar und verständlich. Um dies zu erreichen programmiert man natürlich sicher und effektiv. Doch hin und wieder kommt dann doch ein Crash rein und man muss ihn fixen. Doch reicht ein Guard um Crashes / Bugs wirklich zu beheben? Von Zeit zu Zeit sicherlich, doch dies hängt natürlich von der Situation ab und oft ist selbige durchaus komplexer und bedarf etwas mehr Zuwendung. Mit Guard ist in diesem Kontext z.B. ein null Check gemeint, welcher einen Code-Block vor Ausführung schützt.
Weiterlesen…
Die erste I’m a Coder News in diesem Jahr steht an. Thema ist dieses Mal zukunftsorientierte und abstrahierte Programmierung. Ich komme auf das Thema, weil ich zum einen in meinem eigenen Code, wie auch hin und wieder auf der Arbeit, über Dinge stolpere die optimierter sein könnten. Dabei geht es nicht darum eine foreach Schleife statt einer for Schleife zu nutzen. Es geht darum Dinge so zu entwickeln, dass man sie wiederverwenden kann und Code-Duplizierung vermeidet.
Weiterlesen…
Wie der Titel schon sagt geht es heute um PHP. Eine meiner frühen Sprachen, welche ich aktuell noch für Kundenprojekte einsetze und privat im Blog nutze. Begonnen hat alles mit besagtem Blog und Anfang 2008 weitete ich meine PHP Nutzung auf selbständige Kundenprojekte aus. In diesem Rahmen brachte ich mir die Sprache quasi komplett selbst bei. Anders als bei meinem vorherigen Beitrag zum Thema Java. Dies führt natürlich zu einer anderen Herangehensweise, was das Erlernen und das Einsetzen der Sprache angeht. Ich habe viel mit PHP geschrieben, vor allem um 2010 herum. Der Blog, Kundenprojekte, Clan-Websites und diverse andere Dinge setzte ich um und PHP macht mir durchaus Spaß. Ich setzte meistens weniger auf die objektorientierten Komponenten, da PHP für mich meistens lediglich den Datenbank <-> PHP <-> HTML Flow abdeckte und somit nur Mittel zum Zweck war. Gerade bei komplexeren Dingen war Objektorientierung aber durchaus ein Thema. Innerhalb der letzten fünf Jahre wurde es immer ruhiger was PHP angeht, lediglich der große Backend Rewrite meines Blogs und wenige große Kundenprojekte wurden noch mit PHP umgesetzt. Der Blog ist aktuell im Umbau und wird dann zum Großteil ebenfalls auf PHP verzichten. Denn durch Java und vor allem meinen Fokus auf Android, haben sich meine Prioritäten hier stark geändert. PHP ist meiner Meinung nach weiterhin sinnvoll für verschiedene Bereiche, allerdings bin ich in selbigen nicht mehr wirklich unterwegs. Somit vermute ich, dass bis auf einige Ausnahmen PHP zumindest bei mir aussterben wird. Wie sieht das bei euch aus, nutzt ihr PHP noch?
Meine I’m a coder News erfreuen sich recht großer Beliebtheit im Blog, nur komme ich leider mit den Themen nicht hinterher. Ich bin mittlerweile 10 Wochen hinter dem Zeitplan. Bis dato habe ich versucht einfach aufzufüllen, doch leider schaffe ich es nicht die geplante Anzahl an News zu schreiben. Deswegen ändere ich mein Vorgehen ab jetzt etwas. Von nun an versuche ich weiterhin möglichst oft zu schreiben, allerdings nicht mehr gebunden an irgendwelche Kalenderwochen. Dementsprechend ändert sich auch der Aufbau des Titels ein wenig, denn ich versuche ab jetzt das Thema des Beitrags dort direkt mit zu erfassen. Aber das sollte generell egal sein, denn ihr findet weiterhin alle Beiträge in der entsprechenden Newssammlung. Die Umstellung bedeutet im Umkehrschluss natürlich auch, falls Themen und Zeit vorhanden sind, dass mehrere Beiträge pro Woche möglich sind.
Das Rad neu erfinden, ist heute Thema meiner I’m a Coder News. Denn auch wenn man selbiges eigentlich nicht tun sollte und auch nicht will, so passiert es trotzdem häufiger als man denkt. Manchmal einfach aus dem Entwickler-Flow heraus und manchmal da man bestimmte Dinge auch einfach nicht kennt. Denn für vieles gibt es gute und mächtige Libraries, doch man kann niemals alle von ihnen kennen. Aus diesem Grund sollte man vor Grundsatzentscheidungen bei Implementierungen, sich erst einmal schlau machen ob nicht vielleicht stabile und gute Bibliotheken vorhanden sind. Auf der anderen Seite bin ich der Meinung, dass wenn man selber guten Code schreiben kann, ist auch dies nicht verwerflich. Eine Ausnahme ist hier meistens Code der auf Sicherheitsfunktionen bezogen ist, denn hier sollte man sich immer an die Standards halten. Tut man dies nicht, kann dies zu großen Problemen führen. Auch wenn selbiges ebenfalls bei etablierten Implementation passieren kann, ist dort zumindest das Risiko meistens geringer. Ich selber erwische mich von Zeit zu Zeit dabei die genannten Tipps selbst nicht zu beachten, versuche aber mich zu bessern. Vor allem wenn man seinen eigenen alten Code verwendet, ohne ihn noch einmal einem Review zu unterziehen, kann man sich gut selbst in die Falle manövrieren. Also immer über den Tellerrand schauen, seine eigenen Code-Snippets nicht als fehlerfrei ansehen und den guten alten gesunden Menschenverstand auch beim Programmieren nutzen, dann ist man auf einem guten Weg.
Heute gibt es mal wieder eine I’m a Coder News. Das Thema ist simpel, nämlich der Wechsel zwischen verschiedenen Programmiersprachen nach längerer Zeit. Zum einen ist dies interessant und bringt Abwechslung in den Entwickleralltag. Auf der anderen Seite ist es manchmal dermaßen verwirrend, dass man ausflippen könnte. Mein aktuelles Beispiel ist Java und PHP. Ich schreibe viel Code in Java und bin dementsprechend sehr an die Eigenheiten gewöhnt. Seit einiger Zeit habe ich aber mal wieder mehr Berührungen mit PHP und dies war am Anfang wirklich wieder eine große Umstellung. Stichwort ist hier die Syntax, so versuchte ich in PHP Klassen Methoden mit “Objekt.Methode” aufzurufen und habe sage und schreibe 10 Minuten gebraucht, um zu verstehen das “Objekt->Methode” vielleicht sinnvoller wäre. Dinge die mir seit Jahren geläufig sind, haben sich in meinem Kopf teilweise vermischt und vor allem auch Dinge wie “public, private und protected” und die entsprechenden Unterschiede in Java und PHP, haben mir zu schaffen gemacht. Man kommt schnell wieder rein, es ist etwas wir Fahrrad fahren, aber ein paar Mal legt man sich schon hin. Alles in allem läuft es bei mir wieder rund mit beiden Sprachen, aber mir zeigt dies etwas. Entweder man sollte kontinuierlich Sprachen immer mal wieder nutzen oder sie komplett und endgültig verwerfen. Wirklich lange Pausen sind nicht zielführend und eher verwirrend. Was sagt ihr zum Thema und hattet ihr bereits ähnliches Problematiken?
Ich programmiere gerne und dabei möchte ich halbwegs vielseitig sein. Allerdings ist es natürlich nicht ganz so einfach, einen Mittelweg zwischen großer Vielseitigkeit und dem wirklichen Beherrschen einer Programmiersprache zu finden. Deswegen werde ich in den nächsten I’m a Coder Beiträgen etwas auf die Sprachen eingehen, die ich mir zumindest teilweise angeeignet habe und erklären warum ich dies tat. Dabei werden einige Erklärung sinnvoll und andere eher trivial sein, denn gerade meine ersten Sprachen waren eher zufällig gewählt. Heute fange ich direkt mit Java an, allerdings mit dem initialen Einstieg und z.B. nicht mit meiner Android-Entwicklung, denn dies lernte ich gezwungenermaßen in der Schule.
Weiterlesen…
Es ist mal wieder Zeit für eine kleine I’m a Coder News. Heute möchte ich ein wenig über die Möglichkeiten sprechen wie man seine Objekte verwaltet, wenn diese mehrere Repräsentationen haben können. Damit meine ich z.B. eine Datenbank-Version, ein POJO und eine JSON Repräsentation. Solche Dinge geschehen wenn man Server Interaktionen und innerhalb z.B. einer Android App eine Persistenz implementiert. Denn man erhält Daten vom Server, wandelt diese in Java Objekte um, arbeitet mit diesen und später speichert man sie für die persistente Nutzung. Dabei nutzt man meistens Libraries, um den Overhead zu reduzieren. Nun stellt sich die Frage ob man ein Java Objekt für all diese Zustände (z.B. Incoming Server Object, Model, Database Object) hat, dieses entsprechend mehr oder weniger befüllt und die Daten zentralisiert konvertiert. Alternativ kann man für jeden Zustand ein Java-Objekt bauen und diese unabhängig voneinander befüllen lassen. Im letzteren Fall wird dann meistens via Factories oder ähnlichem die Konvertierung in die anderen Objekttypen durchgeführt. Während die erste Lösung den Vorteil hat weniger Objekte zu haben und zentrale Stellen für die Verwaltung bereitstellt, bietet die zweite Lösung immer eine adäquate Darstellung, man weiß auf welcher Ebene man arbeitet und man spart unter Umständen Speicher. Ich finde beides ist durchaus vertretbar und hängt stark von der Situation ab. So würde ich bei kleineren Projekten, die vielleicht auch nicht mit sehr großen Datenmengen auf einmal arbeiten müssen, zur ersten Lösung tendieren. Sobald man aber wirklich unterschiedliche Daten erhält und z.B. Integers vom Server und Booleans in der Datenbank auf ein Level bringen muss, würde ich eher Richtung Lösung zwei gehen. Sobald man dann noch sehr große Mengen von Objekten hat, würde ich die zweite Lösung noch stärker bevorzugen. Da man immer nur die Art von Objekt, mit den minimal nötigen Inhalten, zur Verfügung stellt und unnötigen Overhead vermeidet. Doch das ist nur meine persönliche Meinung und ist wie gesagt sehr stark von der Situation abhängig. Hatte ihr schon einmal derartige Entscheidungen zu treffen und wenn ja, wie fielen diese aus?
Heute gibt es mal wieder eine I’m a Coder News und diese ist außer der Reihe auch in der Kategorie Fail zu finden. Denn auf der einen Seite ist es vielleicht hilfreich was ich schreibe, doch das eigentliche Problem ist definitiv eher ein Fail. Es geht heute darum, zu prüfen was Skripte tun und zu hinterfragen wofür sie gedacht sind, anstatt sie blindlings auszuführen. Hintergrund ist eine Erfahrung am gestrigen Tage, mit nicht mehr funktionierenden SSH Keys und geänderten GIT Einstellungen. In dieser Situation landete ich nach Testläufen für Skripte, welche eigentlich in Docker Containern laufen sollen und dementsprechend andere Abläufe verfolgen. Dazu gehörte ein spezielles Handling für SSH Keys, welches auf meiner lokalen Maschine allerdings unpraktische Ergebnisse zu Tage führte. So wurde mein privater SSH Key durch eine leere Datei ersetzt und einige GIT Global Config Werte wurden überschrieben. Letzteres ist offensichtlich kein Problem, denn man kann diese Werte wieder ändern. Ein verlorener SSH Private Key hingegen kann unschöne Arbeit bedeuten. Aufgrund von Backups konnte ich diesen Prozess umgehen, aber diese hat man nicht immer und alles in allem sollte man einfach nicht in eine derartige Situation geraten. Soll heißen, auch bei Skripten die man selber geschrieben hat, vor dem Ausführen drüber nachdenken was die Skripte tun und für welche Umgebungen sie gedacht sind. Denn eigentlich logische Abläufe auf einem CI System open_in_new, können lokal für Chaos sorgen. Vor allem wenn man einen Docker Container, der ja eher temporär sein kann, mit einem normalen produktiv Desktop-System vergleicht. Am Ende war nun alles halb so schlimm, aber dennoch unnötig und etwas was man vermeiden sollte.