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.
Weiterlesen…
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.
Weiterlesen…
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.
Weiterlesen…
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.
Weiterlesen…
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.
Weiterlesen…
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.