Boehrsi.de - Blog

Nachdem gestern bereits die erste News zur FOSDEM 2019 erschien, mit der Einleitung und der Zusammenfassung des ersten Tages, geht es heute mit dem zweiten Tag weiter. Ebenfalls thematisieren möchte ich meinen Gesamteindruck vom Event und dem ganzen Drumherum. Denn die FOSDEM ist keine Konferenz wie z.B. die Droidcon und entsprechend läuft hier vieles anders ab. Falls ihr übrigens sehen wollt was es so gab, folgt einfach den Related Links, dort ist das Video Archiv verlinkt.
Der Sonntag war geprägt vom Thema Real Time Communications, was wohl unter anderem meiner aktuellen Arbeit geschuldet ist. Zusätzlich hielten Kollegen von mir einen Talk in diesem Raum, welcher das Thema Break the Messaging Silos with COI open_in_new hatte. In diesem ging es um das Thema Chat Over IMAP und auch von mir aktuell entwickelte Software war Thema in diesem. Dazu gibt es in den nächsten Wochen noch mehr Informationen. Weiter ging es mit Talks zum Thema WebRTC open_in_new, Matrix open_in_new und XMPP open_in_new. Diese verschiedenen Plattformen / Protokolle sind alle für die Kommunikation über das Internet nutzbar, was sowohl für reines Chatten gilt, wie auch für Voice- und Video-Chats. Es war interessant zu sehen was die jeweiligen Techniken mittlerweile können und wo Unterschiede, bzw. Ähnlichkeiten liegen.

Vor etwas mehr als einer Woche hatte ich die Chance meine erste FOSDEM zu besuchen und es war ein wirklich interessantes und spannendes Event, wenn auch sehr anstrengend. Am Freitag vor der FOSDEM kam ich zusammen mit diversen Kollegen in Brüssel an und wir bezogen unser Hotel. Am Samstag starteten wir sehr früh, denn auf der FOSDEM ist immer sehr viel los und möchte man sich sicher sein einen Talk hören zu können, so sollte man ca. 30 Minuten vorher beim entsprechenden Raum sein. Zusätzlich sollte man mit größeren Menschenmengen kein Problem haben, denn das Event ist sehr gut besucht und entsprechend auch die öffentlichen Verkehrsmittel Drumherum.
Der erste Tag stand bei mir dann interessanterweise überwiegend unter dem Stern Go open_in_new. Go hat als moderne Programmiersprache sehr viele praktische Funktionen und Konzepte, sodass ich nun überlege sie für die Serverentwicklung zu nutzen. Ganze vier Talks schaute ich mir zu Go an. Zwischendurch gab es dann noch Java open_in_new mit Docker open_in_new, ein bisschen was zu Nextcloud open_in_new und wie Open Source Contributions bei Mozilla open_in_new ablaufen. Insgesamt waren es sieben Talks, die alle in die Kategorie über den Tellerrand schauen fielen. Solltet auch ihr euch etwas anschauen wollen, folgt einfach den Related Links, dort ist das FOSDEM Video-Archiv hinterlegt.

Es wird mal wieder Zeit für eine I’m a Coder News und heute ist das Thema die Architektur einer Software. Einer der Themenbereich in denen ich in den letzten Jahren wohl am meisten gelernt habe, allem voran auf der Arbeit, aber auch im privaten von eigenen Projekten. Der Aufbau der Architektur mag nach Arbeitsaufwand aussehen, aber selbiger lohnt sich meiner Meinung nach immer.
Selbst bei kleinen App gibt es immer mal wieder Momente in denen man Dinge erweitern oder ändern will und hat man eine stabile Basis geschaffen, also eine gute Grundarchitektur erstellt, geht dies um ein vielfaches leichter als bei einem großen Klumpen Software. Ebenfalls praktisch ist eine gute Architektur im Bereich Dokumentation, denn gerade bei privaten Projekten bleibt die Doku oft auf der Strecke und nach ein paar Monaten versteht man den eigenen Code nicht mehr. Hat man hier aber mit einem verständlichen Entwicklungskonzept gearbeitet, findet man viel schneller wieder in existierenden Code hinein.

Am letzten Samstag erwähnte ich bereits die Teilnahme von einigen Freunden und mir am Rainbow Six Siege Turnier der Rocket Beans. Nun möchte ich zum einen das VOD erwähnen, welches auf Youtube online ist und im unteren Teil der News eingebunden wurde. Zum anderen möchte ich aber auch den Ausgang des Turniers ansprechen. Denn wir konnten uns im Finale in einem Best of Three mit 2 zu 0 gegen das Team DACHschaden durchsetzen.
Somit haben wir das Community Turnier tatsächlich gewonnen, obwohl wir eher erwartet hätten in der ersten Runde direkt rauszufliegen. Dadurch freut man sich natürlich umso mehr. Aber egal wie es ausgegangen wäre, das Turnier war ein wirklich gutes Event, für welches ich mich noch einmal bei den Rocket Beans bedanken möchte. Ich hoffe es werden noch weitere Events dieser Art folgen, denn die Rainbow Six Community und die Rocket Beans passen durchaus gut zusammen. An dieser Stelle auch noch einmal ein GG an alle weiteren Teilnehmer.

Die letzten Tage waren anstrengend und ich war viel unterwegs, was der Hauptgrund ist warum es relativ wenig Neues gab, obwohl ich einiges auf Halde habe. Doch eine Kleinigkeit muss ich noch schnell loswerden, denn in ca. einer Stunde könnt ihr bei den Rocket Beans unser Finalspiel im Rainbow Six Community-Turnier sehen.
Falls ihr heute Abend also nicht feiert, bzw. allgemein noch nichts vor habt und Rainbow Six Siege mögt, schaut doch mal rein. Das Finale wird als Best of Three gespielt, also müssen zwei von drei Maps gewonnen werden. Übertragen wird das Ganze auf Twitch open_in_new und Youtube open_in_new. Alles weitere dazu findet ihr in den Related Links.

An dieser Stelle eine Kleinigkeit in eigener Sache, denn diesen Samstag (27.10), so ab ca. 15 Uhr gibt es bei den Rocket Beans ein kleines Rainbow Six Siege Turnier. Bei diesem werde ich mit einigen Freunden ebenfalls ein Team stellen. Wir spielen schon länger zusammen, allerdings nicht als Clan oder ähnliches, sondern eher Just for Fun mit Ambitionen. Unter diesem Stern steht auch das ganze Turnier, also kein Pro-League Niveau oder ähnliches, aber vielleicht trotzdem ganz unterhaltsam.
Falls ihr am Samstag also noch nichts vor habt und gerne die eine oder andere Runde Rainbow Six Siege sehen wollt, schaut doch mal bei den Rocket Beans vorbei. Vielleicht schaffen wir es ja sogar das eine oder andere Match zu gewinnen. Acht Teams nehmen Teil und es wird ein Single-Elimination Turnier werden. Dementsprechend kann es auch sehr schnell gehen mit dem Ausscheiden. Vor allem da zu Beginn nur im Best of 1 Modus gespielt wird, also eine Map zum gewinnen / verlieren reicht.
Ich freue mich sehr auf das Event, egal wie es ausgeht und freue mich weiterhin darüber das auch bei den Rocket Beans Rainbow Six Siege Anklang findet. In der Zwischenzeit ist ein Blick auf das weitere Rocket Beans Programm sicherlich auch nicht das falscheste was man machen kann. Entsprechende Links gibt es im unteren Teil der News.

Ich entwickle gerne Software, sowohl professionell, wie auch privat, doch manchmal gibt es einfach unschöne Aufgaben, nervige Bugs oder andere Situationen auf die man lieber verzichten würde. Die Top 5 der nervigsten Dinge beim Programmieren - für mich persönlich - möchte ich heute im Rahmen einer weiteren I’m a coder News vorstellen.
Unklare / nicht durchdachte Aufgabenstellung: Egal in welchem Kontext, immer mal wieder stolpert man über nicht fertig gedachte Ideen und Ansätze. Daraus resultiert dann oft eine Änderung der eigentlichen Aufgabe, noch während man initial dabei ist. Dadurch ändern sich auch gerne grundlegende Dinge, sodass ordentlich Hirnschmalz benötigt wird, um entsprechende Anpassungen zu machen ohne komplett neu beginnen zu müssen. Solche Dinge kann man durch ordentliche Planung einschränken, aber leider niemals komplett ausschließen. Gerade im privaten Bereich empfehle ich in diesem Kontext alles zu notieren und ein paar Tage reifen zu lassen, denn wenn man blind drauflos schreibt, landet man häufig in besagter Situation.
Trial and Error Bugfixing: Ein Bug wird entdeckt und die Jagd nach Ursache und Lösung geht los. Auf dem Weg zu Lösung gibt es einige Zwischenschritte und manchmal hat man das Pech einen nicht reproduzierbaren und entsprechend auch nicht wirklich lösbaren Bug zu finden. Dabei kann man dann nur herumprobieren, um sich an eine Lösung anzunähern. Ebenso sieht es aus wenn man zwar genau weiß wo das Problem ist, aber eine klare Lösung nicht erkennbar oder gar möglich ist. Somit kann man auch hier nur via Trial and Error Ansatz versuchen das Problem zu lösen. Am frustriertesten finde ich dabei die Menge an Zeit die man investiert ohne Fortschritte zu machen und ohne Code zu erstellten. Meistens kommt man trotzdem zu einer Lösung und alles ist wieder gut, es gibt allerdings definitiv dankbarere Aufgaben. Wirklich tun kann man gegen diese Art von Problemen leider auch nichts, denn diese Art von Bugs kommt bei der Entwicklung einfach auch vor.

Der letzte I’m a coder Beitrag ist schon länger her, was nicht zwangsweise daran liegt das es nicht neues in diesem Bereich bei mir gibt, sondern eher daran das die Beiträge in anderen Sammlungen einsortiert werden. Doch wie ich auch immer, ich habe mal wieder etwas allgemeines, was gut in diese Sammlung passt.
Zuletzt kam ich durch die Droidcon auf das heutige Thema. Es geht um die Aktualisierung von Third-Party-Libraries, welche man in seinen Programmen, Tools oder Apps nutzt. Denn häufig hat man kleine praktische Bibliotheken, die einem Arbeit abnehmen und Funktionen verlässlich und schnell zur Verfügung stellen, ohne dass man das Rad andauernd neu erfinden muss. Ob man dabei alle Nase lang Fremdbibliotheken nutzt oder lieber alles selber schreibt, kommt auf das Projekt und die generelle Einstellung an. Das man bereits eingebundene Libraries aber aktualisieren sollte, sofern man welche nutzt, ist denke ich klar.
Doch warum fällt dies so schwer? Never Change a Running System, denn es funktioniert alles, ist häufig ein guter Grund. Auch häufig ist das fehlende Bewusstsein für diese Bibliotheken, denn wenn alles funktioniert schaut man oft gar nicht mehr nach diesen Inhalten und eventuell verfügbaren Updates. Damit einher gehen dann natürlich diverse Probleme, wie z.B. Abstürze. Unter Android sind häufig Plattformupdates ein guter Grund für ein Update von Libraries, denn oft gibt es nach größeren Systemänderungen Probleme. Doch häufig entdeckt man diese Probleme erst nach längerer Zeit und nach einigen unzufriedenen Nutzern. Reaktiv reagieren ist eben nur eine Notlösung und sollte nicht der permanente Zustand sein.

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.

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.