Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Cloud-Native

Data & Machine Learning

Generative KI

IT-Security

Produktentwicklung

Weitere Leistungen...

Leistungen

Arbeitsweise

Referenzen

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Kultur & Karriere Podcast

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

Alle Standorte

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Senior Software Engineer

Informatik Aktuell

Java

Softwareentwicklung

Java und die Fußangeln in der Programmiersprache

Auch in Java, einer Sprache, die sehr auf einfach zu verstehende Programme ausgelegt ist, gibt es Überraschungen, die teilweise zur stunden- oder tagelangem Debugging führen können. Lest hier, was man dagegen tun kann.

<p>Pride Month ist vielleicht eine kommerzielle Werbewüste, aber trotzdem bietet es mir den Anlass, diesen Blog-Eintrag zu schreiben. Anders als meine normalerweise sehr technischen Blogeinträge ist dieser persönlich und geht um mich.</p><p>Hi, mein Name ist Elisabeth Schulz. Wie einige meiner Leser vielleicht wissen, bin ich transgender. Ich wurde unter einem anderen Namen geboren und habe eine Geschlechtsidentität, die von derjenigen abweicht, die mir bei meiner Geburt zugewiesen wurde. In diesem Blogeintrag möchte ich mich kurz dazu äußern, wie meine Arbeit bei codecentric durch diese Tatsache beeinflusst wurde, welche Konsequenzen das Ganze hatte und wie ich heute damit umgehe.</p><p>Was dieser Text natürlich nicht ist und auch gar nicht sein kann, ist die letztendliche Antwort auf alle Themen, die Trans-Menschen betreffen. Er ist das weder im Bezug auf codecentric noch zu anderen Themen. Er gibt nur meine persönlichen Erfahrungen und Eindrücke wieder, nicht mehr, aber auch nicht weniger.</p><p><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/3bun9FXRAmstiuzgcVcA" alt="Meme: Transition Timeline / How it started" /></p><h2>Arriving @ codecentric</h2><p>Als ich mich Ende 2018 endgültig zur <a href="https://queer-lexikon.net/2017/06/08/transition/" target="_blank">Transition</a>  entschloss, war mir klar, dass dies auch Einfluss auf meine berufliche Tätigkeit haben würde. Mein damaliger Arbeitgeber war zwar nicht aktiv ablehnend, aber mit Unterstützung und Verständnis habe ich trotzdem nicht gerechnet. Eher damit, gegen unterschwellige Wände zu laufen und auf Hindernisse zu stoßen. Deshalb suchte ich gezielt nach LGBTQIA+-freundlichen Arbeitgebern. Hier hatte die codecentric AG in einigen Gesprächen einen guten Ruf.</p><p>Also habe ich mich bei codecentric ganz klassisch mit Anschreiben und Lebenslauf beworben. Anfangs versuchte ich, mir erst einmal nicht zu sehr in die Karten schauen zu lassen. Alles ging also seinen normalen Weg, bis auf eine Kleinigkeit: Ich habe im Vorstellungsgespräch schon vorsichtig angefragt, wie denn die Einstellung zu Diversity & Inclusion ist. Daraufhin wurde mir gesagt, dass das schon eines der Ziele der Firma ist, und auf die (damals noch nicht so verbreitete) <a href="https://www.charta-der-vielfalt.de/" target="_blank">Charta der Vielfalt</a>  verwiesen, die die Firma zu diesem Zeitpunkt gerade im Inbegriff war, zu unterzeichen. Ich entschied mich auch deshalb, diese Chance zu nutzen, und wurde angenommen.</p><h3>Der Blick von innen</h3><p>Einmal in der Firma angekommen, war das Ergebnis erst einmal etwas ernüchternd. Es gab zwar einen Slack-Kanal zum Thema, aber die meisten Kolleg*innen waren doch eher „freundlich desinteressiert” – aber zumindest nicht passiv ablehnend, wie in meiner vorherigen Firma. Für eine IT-Beratung war allerdings die Frauenquote sehr gut. Andererseits gab es aber auch nur eine Damentoilette gegen drei Herrentoiletten, was eine gewisse „in Architektur gegossene Erwartungshaltung” spiegelt. Erst einmal also gemischte Gefühle, und daher auch eine gewisse Vorsicht.</p><p>Diese anfängliche Unsicherheit legte sich recht bald, auch als ich ins Gespräch mit meinem direkten Unit-Leiter kam. Er nahm mich sofort ernst und ich glaube, er vermutete auch sehr schnell, dass bei mir etwas „im Busch” war. Menschlich und dienstlich klappte es sehr gut, aber ich habe mich trotzdem entschlossen, die Probezeit abzuwarten. Nicht, weil ich von Problemen ausging – einfach nur, weil die Chance nicht 0 war, und ich sowieso noch andere Themen angehen musste (eine eigene Wohnung finden, …).</p><h2>Coming out @ codecentric</h2><p>Ende 2019 war es dann soweit: Ich hatte alles vorbereitet und musste im Grunde nur noch „den Hebel umlegen”. In meinem Kopf spukten die ganzen Ängste herum, mit denen sich viele Trans-Menschen an diesem Punkt herumplagen: Schaffe ich es, mein Leben nochmal um 180° zu drehen? Mache ich gerade einen Fehler? Wird mich der Schritt meine Karriere kosten?</p><h3>Die Vorbereitung</h3><p>Zum Glück gibt es bei codencentric eine Institution, die sich um das Wohlergehen der Mitarbeiter*innen kümmert: das <a href="https://www.codecentric.de/wissen/publikation/ist-ein-feelgood-manager" target="_blank">Feelgood-Management</a> . Ich bin in Solingen, in den Headquarters und am Sitz des Feelgood Managers, tätig, sitze also sozusagen an der Quelle. Also machte ich einen Termin mit Nick, Leiter des Feelgood Managements. Das war kurzfristig möglich, also wartete ich, bis er im Konferenzraum angekommen war, und eröffnete das Gespräch mit einem einfachen Satz: „Nick, ich bin trans und werde zukünftig weiblich präsentieren. Wie mache ich das, so dass die Firma damit gut klar kommt?”</p><p>Das war dann vielleicht im Rückblick nicht die geschickteste Eröffnung für so ein Gespräch, denn Nick ist als Feelgood Manager zwar einiges gewöhnt, aber das war bisher wirklich noch nicht vorgekommen. Ich war buchstäblich die Erste. Sobald dieser Paukenschlag aber verhallt war, ging das Gespräch sehr positiv weiter. Es ging im Folgenden nur noch darum, wie die Firma mich in dieser Wandlung begleiten konnte, und wie man die nötigen Schritte am geschicktesten durchführen würde. Aber natürlich auch, was das für Kolleg*innen und mich bedeuten würde. Eine der wichtigen Fragen war schließlich, wie ich die Nachricht an meine damals um die 500 Kolleg*innen weitergeben konnte.</p><p>Nun gibt es bei codecentric eine schöne Tradition: die „Personal Introduction”. Ein kurzer Artikel in unserem internen Blog, in dem sich jede Person, die bei codecentric neu anfängt, kurz vorstellt: Wer bin ich, was mache ich bei codecentric, was mache ich abseits der Arbeit so. Eine Art kleiner Eisbrecher, der es dem Rookie möglich macht, mit Kolleg*innen ins Gespräch zu kommen. Nun würde ich eine „Personal Re-Introduction” verfassen, um alle gleichermaßen auf den neuen Stand zu bringen.</p><h3>Die Reaktion</h3><p>Genau das habe ich auch getan und die Reaktion war kurz gesagt überwältigend. Der Vorstand gratulierte mir innerhalb weniger Minuten per Kommentar, dutzende Kolleg*innen sprachen ihre Unterstützung aus. Ich war erleichtert ohne Ende, vor allem, weil ich auch auf anderen Kanälen keine einzige negative Reaktion bekam.</p><p>Nur eine einzige Anekdote möchte ich doch zum Besten geben: Am folgenden Tag, noch immer halb schwebend vor Erleichterung, wagte ich es dann das erste Mal, weiblich präsentierend zur Arbeit zu fahren: Kleid, Lippenstift, Makeup, Strumpfhose. Ich wusste zwar noch nicht, dass weniger oft mehr ist, aber ich war mit Feuereifer dabei und traf einen Kollegen in der Kaffeeküche. Er sah mich an. Einmal. Zweimal. Mein Herz sackte in die Strumpfhose, und ich wartete. Dann meinte er: „Öfter mal was anderes, huh?” Ich nickte nur und ging dann schnell an meinen Platz. Hatte ich mich doch geirrt? Nein! Der Kollege hatte nur schlicht den Artikel nicht mitbekommen und kam kurz darauf zu meinem Platz, um sich zu entschuldigen.</p><p>Sicher, es gab einige Rückfragen, damit hatte ich gerechnet. Einige Gespräche in der Kaffeeküche oder auf dem Sofa, wo die üblichen Fragen kamen: Seit wann ist dir das klar? Wie fühlt sich das an? Was hast du vor jetzt zu tun? Alles im Grunde höflich und ohne allzu sehr ins Detail zu gehen. Hin und wieder musste ich eine Grenze setzen, wo es zu persönlich wurde, aber viel seltener, als ich befürchtete. Und ansonsten? Meine neue E-Mail-Adresse hatte ich innerhalb von Stunden, und genauso neue Zugänge zu unseren internen Systemen. Die einzige Stelle, an der mein <a href="https://queer-lexikon.net/2019/12/23/deadname/" target="_blank">Deadname</a>  gezwungenermaßen noch stand, war meine Lohnabrechnung – denn der Staat ist um ein Vielfaches komplizierter und alles, aber nicht entgegenkommend.</p><h2>Working @ codecentric</h2><p>Wie wirkt sich also meine Identität auf meine Arbeit aus? Zum Glück gar nicht, würde ich sagen. Code ist es tatsächlich relativ egal, wie die Person aussieht, die ihn schreibt. Auch die Physiologie macht keinen entscheidenden Unterschied.</p><p>Was allerdings einen Unterschied macht, ist, wie mit mir umgegangen wird. Eine meiner größten Sorgen war, dass Kunden eventuell nicht mehr mit mir arbeiten wollten, oder die Eingaben, die ich machte, mehr infrage stellen würden, als das vorher der Fall war. Klar würde niemand offen sagen, dass meine Identität der Grund dafür wäre, aber ausschließen konnte es trotzdem niemand.</p><p>Zum Glück ist das bisher niemals vorgekommen. Der Kunde, bei dem ich im Einsatz war, als ich mich zum Coming-out entschied, reagierte im Gegenteil ganz hervorragend – will sagen: Er hat mir eine neue E-Mail-Addresse gegeben und meinen neuen Namen übernommen. Mehr hatte ich gar nicht erwartet. Und dieses Muster setzt sich in der überwiegenden Mehrheit der Fälle auch fort. Schwere Vorfälle gab es nie, im Gegenteil. Ich habe seitdem begonnen, auch verstärkt als Schulende und Vortragende zu arbeiten, und auch dort eigentlich nur Gutes erlebt.</p><p>Natürlich gibt es nicht ausschließlich nur so tolle Kunden. Es gibt auch Momente, in denen ich mit den Zähnen knirsche – wenn beispielsweise jemandem betont immer wieder „Er” herausrutscht, sobald nicht mehr mit mir, sondern über mich gesprochen wird. Auch das gibt es leider und ich habe mich entschieden, das Ganze aktuell nicht zu thematisieren. Den einen oder anderen verdeckten Seitenhieb habe ich auch abbekommen, sicher. Das passierte aber nie auf einem Level, dass ich wirklich verletzt gewesen wäre. Offene Aggression oder Einschüchterung hätte ich auch nicht hingenommen, sondern an meinen Unit-Leiter gemeldet und dann wäre die Sache sehr schnell vorbei gewesen.</p><h2>Proud @ codecentric</h2><p>Wie kann das sein? Eine Trans-Geschichte, die nicht mit Leid, Ablehnung und großen Problemen gespickt ist? Ist trans nicht gleichbedeutend mit Pariah? Und nicht ein Kindheitstrauma wurde erwähnt! Das mag nach einigen Darstellungen fast schon wie eine absolute Ausnahme wirken. Tatsächlich aber ist mein Leben heute um so viel besser, als es an jedem anderen Punkt meiner Geschichte war. Ich kann morgens aufwachen und habe nicht das Gefühl, vor dem Frühstück schon einen Halbmarathon gelaufen zu sein. Ich kann leben, ich kann lachen und ich kann mich in meinem Körper wohl fühlen auf eine Art, die jemand, der es immer getan hat, vielleicht nur schwer nachvollziehen kann. <a href="https://genderdysphoria.fyi/gdb" target="_blank">Dysphoria</a>  war wie ein Rücksack, den ich mein ganzes Leben mit mir herumgeschleppt hatte und nun endlich ablegen konnte.</p><p>Klar, ich könnte hier von meiner Kindheit erzählen und was es für „Zeichen” gegeben hat. Ausbreiten, wieso es so lange gedauert hat, bis ich zu mir stehen konnte. Aber wem würde das helfen? Mir nicht, und ich glaube, den meisten Leser*innen auch nicht.</p><p>Die Firma steht auf meiner Seite, da bin ich mir sicher. Meine Kolleg*innen schätzen meine Arbeit, mein Unit-Leiter geht mit mir wie mit allen anderen Mitarbeiter*innen um. Gelegentliche kleine Probleme gehören mit dazu, aber in Summe könnte ich mir einen besseren Arbeitgeber nicht wünschen.</p><p>Was bleibt also am Abschluss zu sagen? Ich bin trans – und das ist auch gut so. Und wenn ich meine Leser*innen kurz persönlich ansprechen darf: Wenn du auch trans bist, dann glaub mir – es lässt sich so leben. Es gibt Orte, wo du sein kannst, wo du akzeptiert wirst und für dich selbst geschätzt wirst. Habe den Mut, zu dir zu stehen. Ich drücke euch die Daumen, Geschwister.</p>

Proud @ codecentric 🏳️‍⚧️

<p>Serverless computing promises to provide easily scalable applications and provide a straightforward programming model that allows developers to focus on features instead of technological details. In this blog post, we develop a simple sample application. We implement it and deploy it as a serverless GCP Cloud Function. We hope this tutorial helps you move beyond the “Hello World” stage. The most relevant parts are highlighted in this article. You can fetch the <a href="https://github.com/Norwae/dead-mans-switch" target="_blank">entire project</a>  from GitHub.</p><p>Our project is a “dead man’s switch as a service.” In essence, its job is to perform an action by default. The action is defined but is prevented by “checking in” at regular intervals. For example, consider a safety switch that stops a saw blade once the operator releases it. A lot of potential actions that could be triggered in this way come to mind, such as sending emails. For this blog, we limit ourselves to performing an HTTP POST against an arbitrary URL, with a user-specified entity.</p><h2>First things first: Setting up the Google Cloud project</h2><p>Before we can dive in too deeply, we need to take care of some setup. The GCP groups resources into projects, and we need to create just such a project before we can continue. The setup is shown below: <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/gQCyNxZPTZGhooCHyu9u"><img width="3840" height="1040" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/gQCyNxZPTZGhooCHyu9u" alt="GCP Project Setup" /></a> </p><p>With the project itself in place, we can start adding functionality to it. Since we want to be able to interact with the world, we need an HTTP interface. Fortunately, Google makes things easy for us here – Cloud Function can be bound to an http trigger out of the box, without any further configuration. So we select “Cloud Functions” from the resource list. We create a new function and perform some setup. Specifically, we change the runtime to go and reduce the allocated memory to 128 Mb, which is still plenty. Additionally, we deploy the function in the eu-west-1 datacenter (in the “More” tab).<a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/LoCaQPYkS7m2fDRjsDM5"><img loading="lazy" width="3840" height="1612" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/LoCaQPYkS7m2fDRjsDM5" alt="serverless GCP function settings" /></a> </p><h2>Handlin’ the HTTP</h2><p>With this setup, we can actually call our function for the first time. Under the “Triggers” tab, we can extract the invocation URL. If we visited it, we would see a “Hello World” message. Since we intend to change this, we move to implement our logic instead.</p><p></p><p>With this snippet, we drafted a simple API to create, query, and delete triggers. Additionally, we defined a way to assert liveness. All the functions we reference right now can safely be implemented to just write an arbitrary response – for the moment, just having confidence the routing works as expected is sufficient.</p><p>For larger-scale serverless GCP services, it may be worthwhile investigating more elaborate frameworks such as <a href="https://github.com/gobuffalo/buffalo" target="_blank">buffalo</a> . For this tutorial, we avoid the additional complexity. Since the HTTP trigger expects a handler with the same signature as a http.HandleFunc, pretty much any framework that does not fundamentally alter this convention should work with no major adaptation.</p><p>So we upload our sourcecode (with stub implementations of the missing functions and encounter – an error. Several errors, in fact. The first error is relatively easy to fix – we renamed our entry point to HandleHTTP and need to let the Cloud Function runtime know. The second error requires some further thought: Google Cloud Functions require <a href="https://github.com/golang/go/wiki/Modules" target="_blank">modular go</a> . As soon as we declare our dependencies in go.mod, the build succeeds.</p><p></p><h2>With just a little persistence</h2><p>Since we want to actually be able to interact with the service, some means of persistence is required. Cloud Functions themselves need to be stateless – we cannot use a local fs or memory. We need some kind of database. Since we are already inside the Google Cloud, we might just use its capabilities. So we consider what is on offer – an SQL database would certainly do the job. BigTable would, too, but we really just need a simple document store. So we choose <a href="https://cloud.google.com/datastore/docs" target="_blank">FireStore in Datastore mode</a> . It is simple to use, well-integrated and made for key lookups.</p><p></p><p>With this simple bit of initialization, the platform will take care of all the connection and authentication logic for us. However, we still need to configure the datastore itself. For this task, we return to the Google Cloud console and select “Datastore” in the “Storage” category. After confirming we indeed want Firebase to be in datastore mode, we are good to go.<a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/0J7Tl3NlQHqZ8IkSCSCQ"><img loading="lazy" width="2275" height="1360" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/0J7Tl3NlQHqZ8IkSCSCQ" alt="Datastore settings" /></a> </p><h2>Taking care of business</h2><p>With all the prelude now taken care of, we can finally implement our business logic. We replace the stub endpoint handlers with actual business code</p><p></p><p>With this logic in place, we are nearly done – but testing our API reveals a small detail that makes our life somewhat harder: the redirect in createTrigger does not send us to the newly-created entity. Instead, we are greeted with a Google login page. Looking a little closer at our invocation URL solves the mystery: our create URL looked something like this: https://europe-west1-dead-mans-trigger-123456.cloudfunctions.net<b>/api-server</b>/triggers. Note the bold part – the name of our function was encoded as part of our path. While the Cloud Function framework stripped this prefix out, our redirect did not know about it and took the caller right out of our context. We need to determine an invocation base URL.</p><p></p><h2>Fire in the hole</h2><p>With our API now up and running (try it out!), we turn our focus to actually having the switch fire if they are not checked in. Now some background work needs to be done. We need to find expired triggers, execute their HTTP Post calls, and remove them from our datastore. We need a cron job.</p><p>Fortunately, the Cloud Scheduler (found in the “Tools” section of the GCP console) offers just that. We could just create a scheduler, have it invoke our Cloud Function via HTTP, and call it a day. However, in this tutorial, we instead opt to do something a little more general – we create a Pub/Sub topic, and subscribe a second background function to it. <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/4vJEhJ89SFe9Wc8j3UAw"><img loading="lazy" width="3633" height="982" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/4vJEhJ89SFe9Wc8j3UAw" alt="second background function" /></a>  This additional level of indirection would allow us to have different consumers all run on the same schedule.</p><p>With the Pub/Sub mechanism set up, all that remains is subscribing a function to it. Since each Cloud Function has exactly one trigger, we cannot reuse our API server. Instead we set up a second function and configure it to listen to the Pub/Sub topic. This function does not have a HTTP interface. Thus, it can’t be called by anyone except for our timer topic. <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/VGL5Oj7TR2FpEJ9qDMTw"><img loading="lazy" width="1172" height="754" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/VGL5Oj7TR2FpEJ9qDMTw" alt="setting up a second function" /></a> </p><p>With all infrastructure in place, we can implement the last bit of logic and enjoy our fancy new dead man’s trigger service.</p><p></p><h2>Conclusion</h2><p>Hopefully, this tutorial has helped you understand the easy and beautiful programming model of the serverless GCP Cloud Functions. The tight integration of Google’s offer allows very rapid development of functionality, with a strong focus on producing scalable solutions. We have aimed to guide you a step past the very basics, and hope to have highlighted some “gotcha” moments.</p><p>Do you develop a serverless GCP application? We would love to hear about your own experiences with the platform in the comments.</p>

Serverless GCP functions – Look Ma, no servers!

<p>Any mobile application should be able to handle offline situations gracefully. After all, we have all felt the frustration you experience when the E on your phone goes to a G, or that dreaded X. Yet for many application, access to some database is critical. Firebase is an offline-capable general-purpose database for mobile applications. What this means is that even if you lose internet access, the app will still work correctly, unlike one written in a more traditional client/server model. Instead of directly replicating your data to the backend, your local copy of the database will be modified. Once connectivity returns, firebase consolidates your local copy with the cloud. In this firebase tutorial, we build a small app to showcase how to use this database in a simplified real-world scenario.</p><p>Our example application is a simple time tracking tool for remote workers. An example would be a carpenter or other craftsmen. These workers need to document their time, but are often faced with shaky or non-existing internet access. We want to implement a mobile app that allows these workers to go on and off duty at the press of a button. Usually, an easy solution to this might be a REST client/server architecture, this fails in offline scenarios. Instead, we devise a schema to store the data using firebase. Firebase offers a very solid, offline capable database that can be used when connectivity is a scarce resource.</p><h2>Key Firebase features</h2><p>Firebase structures itself as a tree of collections and documents. A collection contains documents, and a document can contain fields and collections. We can read, write and edit documents by their path. The structure is always strictly alternating – a document always has collection children, and a collection always has document children.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/rBXl90XNQhmLbUj4XypI"><img width="250" height="74" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/rBXl90XNQhmLbUj4XypI" alt="Illustration of a firebase document path" /></a> </p><p>For each element in a firebase database, you can define access control rules. These rules define who can see and alter what parts of the database. The firebase server enforces these rules. Rules can allow reads, modifications or adding new documents to a collection. The rules can depend on request data (such as the user ID), the current contents of the document, and even make queries to other parts of the database.</p><p>Finally, it is possible to subscribe to documents and collections in firebase. A subscription means that an application will be notified on every change of that resource. If you subscribe to a collection, you will be notified of new or changed document. Similarly, if you subscribe to a document the subscription notifies you about any changes to its fields.</p><p>These three key features allow us to design our firebase tutorial application. There are more features including deep analytics and management functions. They are not part of this tutorial.</p><h2>The big idea</h2><p>With these three key features, we are ready to design our firebase tutorial app. Each user will receive a subtree of the overall database to store their data. The worker can not act outside this subtree at all. Inside this subtree, they have some degree of access. Inside the tree, we will collect Booking objects. Each such object defines one time-tracking related event – such as beginning or ending a work period. Such events are write-once. They can be appended to a collection, but never deleted or altered. This means we do not need to handle potential update conflicts – every object eventually ends up in a consolidated collection.</p><p>Some users may have multiple devices – so we cannot assume to know the full truth. The data model may change even after the application has loaded and feels in control. Thus, we place the subscription function in the center of our architecture. We subscribe to the booking collection, and display it to the user. Any changes we make will take the form of additional bookings. They are added to the model – which triggers a notification on the subscription. Thus, the UI always represents the most current view of the overall collection.</p><p>Since this article is a firebase tutorial focusing on mobile applications, we do not elaborate on the server-side processing a real application would probably include. If you are familiar with NoSQL databases, you are probably not going to find it challenging to imagine how to generate monthly reports, apply legal break requirements and so on.</p><h2>Data model</h2><p>We decided to do an event-based data model to leverage the offline capabilities of firebase. For the purpose of our firebase tutorial, we define three entities.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/quHi8kgRLCvZntDUIOC9"><img loading="lazy" width="250" height="128" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/quHi8kgRLCvZntDUIOC9" alt="Data model" /></a> </p><p>This model ties three entities together in a subtree of the firebase firestore. The user object itself stores user configuration (such as the current company context). It serves as the user preferences. The bookings collection aggregates all bookings. It allows reads and inserts, but blocks updates. The memberships collection permits user reads, but neither inserts nor modifications – otherwise the user would be able to add itself to any company. A privileged server component manages this collection instead.</p><p>When the application starts, it initializes the firebase firestore, and subscribes to the user document itself, and the two component collections. As soon as these resources have been loaded, the application receives notifications that data is available. It can then start to display that data to the user.</p><p></p><p>Our whole approach focuses on subscriptions. Each subscription is functionally an event source – so a listener-based solution offers itself. We perform all our processing and updates in the form of listeners on an event. Potentially these listeners can emit events of their own. Any change to the data model produces an event cascade that ultimately reaches the UI. We have a simple, well-understood mechanism which (as a side benefit) does not require blocking queries or asynchronous loading.</p><p></p><p>We can easily apply this pattern to all aspects of the application. The same mechanism powers the user switching their selected company, new events becoming available from another device, and even new companies becoming available for booking.</p><h2>Firebase Security Rules</h2><p>In our data model, we laid out some restrictions that the application user needs to obey.</p><ul><li>Every user may freely read and write their user document (/users/{uid})</li><li>They may add bookings to their booking collection (/users/{uid}/bookings), and read it.</li><li>They may read their company memberships (/users/{uid}/memberships), but not alter them.</li></ul><p>Firebase offers a comprehensive security rule language. It is relatively straightforward to express these rights and constraints in this language:</p><p></p><p>Since the database enforces these constraints, we can freely utilize the data on the client – even if a person tried to falsify their local copy of the database, their updates would be rejected.</p><p>For developing and flight-testing security rules, the simulation environment provided as part of the firebase admin interface is invaluable. It allows to simulate different access attempts, and gives feedback which rules caused the attempt to succeed or fail respectively. You can find it in the firebase admin console, under the “database” heading.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/uDZIsDMzRmSM4l7gkH1X"><img loading="lazy" width="250" height="121" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/uDZIsDMzRmSM4l7gkH1X" alt="Firebase console example" /></a> </p><h2>Tying our firebase tutorial together</h2><p>To conclude our firebase tutorial, we briefly touch some other points that need to be addressed. The data model is well and good from a technical point of view. It is, however, not user-friendly. A user probably does not want to deal with individual start and end events. They want to know if the system has correctly identified them as having started working at 08:11 and finished at 17:09. Fortunately, this is relatively easy to accomplish in our event-driven model.</p><p></p><p>As we tacitly assumed in the <a href="#security-rules">security rules</a>  section, each user has their own identity when interacting with firebase. Firebase supports a number of providers, such as Google, Apple, and Facebook. Take a look at the <a href="https://firebase.google.com/docs/auth" target="_blank">list of supported providers</a> , and pick one that works for your project. For this firebase tutorial, we limit ourselves to email/password, but a full app will likely want to support the platform providers at the very least.</p><p>A fully-functional version of the example app can be found on <a href="https://github.com/Norwae/Trakka" target="_blank">github</a> . Please take a look and tell us what you think.</p><p>Do you have any experience to share? Please comment and let us know.</p>

Firebase tutorial by example – building a mobile application

Rust for Java developers

# Overview

Mobile applications frequently authenticate their backend calls via JWT. These tokens are frequently used in conjunction with OIDC to authenticate a user. Sometimes, particularly in high-assurance scenarios, it can be preferable to authenticate both a user and a device. This article describes a JWT-based scheme that produces user and device authentication without abandoning the JWT transfer format. 

In particular, we provide a blueprint implementation of both client—and server-side code that achieves the goal of secure identification of both user and client devices, preventing potentially unauthorized spread of credentials by insecure or compromised client devices.  

Our approach leverages the secure enclave (StrongBox) keychain implemented in recent Android operating systems. It offers tamperproof storage of cryptographic material, with even the device owner unable to extract private keys. We can also require the operating system to require user authentication before signing operations. 

# Background

Our use case is an application that allows collaborating groups to access shared resources with elaborate security requirements. The application includes end-to-end encrypted chat, secure file sharing, and server-agnostic state changes. Due to the high sensitivity of shared content (financial and reputational risks), we need to prevent simple attacks (such as replay attacks) and attempts of key theft on compromised client devices.

Onboarding and device verification are not part of this document. We assume that operating system integrity is maintained (i.e., no rooted devices) to establish a trusted path towards the StrongBox module. StrongBox and its  HSM protect the key material even on a compromised device. However, deep compromises can potentially still introduce problems, such as misuse of accessibility features in order to fake user interactions.

JWTs are an industry standard for exchanging authentication information. They consist of base-64 encoded JSON documents. Our scheme exclusively uses ECDSA-signed JWTs instead of the more common RSA and HMAC-based signature algorithms. The backend system exposes a REST interface and transmits the token using the usual mechanism (an Authorization header with the Bearer-Scheme).   
  
Elliptic curve cryptography is a variant of the discrete logarithm problem with several attractive properties for a signature scheme. It features short key sizes and has withstood the test of time for both mathematical and computational attacks. 

EC cryptography is well-established and available for all current operating systems and development platforms. It is one of the signature schemes supported by StrongBox. 

# Protocol

In our scheme, we utilize several standard JWT claims to identify the user, the device, and other required metadata to authenticate a client request. These are:

## Header claims
* alg: Must be "ES256"
* typ: Must be "JWT"

## Body claims

* sub - the standard subject claim. This claim contains the opaque user ID. Our application uses version 4 UUIDs to ensure that user IDs are distinct and not discoverable by iteration.  
* iss: The "issuer" of the token is the device that performed the signature (also identified by a UUID). Although this claim is frequently understood to refer to a service URL, in our case, it identifies the second factor (the authorized device)
* aud: Identifies the service to authenticate against
* iat, exp: All tokens must declare both an issuing timestamp and expiry. Used in conjunction with jti to prevent replay attacks (see below)
* jti: The token identifier serves as a replay protection mechanism. Each token is single-use and "burned" afterward. 

The server side imposes some constraints on top of the (client-controlled) claims. 
It ensures that iat within the interval of -5 to .1 seconds of the current server time.
It ensures that exp is within the interval of -.1 to 5 seconds of current server time
It matches the audience against a configured list of acceptable audiences
It looks up a public key established for the iss/sub combination, and validates the signature against this key.

## Serverside Implementation

As previously stated, signup and onboarding are out of scope for this document. For our example implementation, we assume a relational database backend comes preloaded with the following table:

```SQL
CREATE TABLE devices (
   user_id UUID NOT NULL REFERENCES users(id),
   device_id UUID NOT NULL,
   public_key BYTEA NOT NULL,
   PRIMARY KEY (user_id, device_id)
)
```
In addition we maintain the following auxiliary table:

```SQL
CREATE TABLE burn_record (
  user_id UUID NOT NULL REFERENCES users(id),
  jti TEXT NOT NULL, 
  expiry TIMESTAMP NOT NULL,
  PRIMARY KEY (user_id, jti)
)
```
Our server is implemented in Rust and utilizes the Axum framework as an HTTP server. Access checking and authorization are implemented in middleware, where protected routes (which are all but a handful of liveness/metrics endpoints) require the injection of an AuthorizedUser structure. 

```rust
#[derive(Debug, Copy, Clone, Deserialize, Serialize, FromSql, ToSql, PartialEq, Eq, Hash)]
#[postgres(transparent)]
pub struct DeviceId(Uuid);
#[derive(Debug, Copy, Clone, Deserialize, Serialize, FromSql, ToSql, PartialEq, Eq, Hash)]
#[postgres(transparent)]
pub struct UserId(Uuid);

pub struct AuthenticatedUser {
    pub user_id: UserId,
    pub device_id: DeviceId,
}
```

Several potential storage mechanisms are supported, but in this document, we refer only to the relational DB storage introduced earlier. 

```rust
pub trait KeyStorage {
    /** Retrieve the signing key for the specified user/device combo. Treat
    the arguments as attacker-controlled (n.b. how they are not wrapped in an
    `AuthenticatedUser`!). Implementors should perform the following steps in order:
    
    * Burn the token, reporting JTIAlreadyBurned if this user has already used the JTI
    * Look up the user/device combinations key, returning UserDeviceNotFound if required
    * Perform any implementation-dependant checks (such as user-locking) if supported
    * Return the key
    
    */
    fn burn_token_and_load_key(&self, token: String, user_id: UserId, device_id: DeviceId)
        -> impl Future<Output = Result<Vec<u8>, KeyLoadError>>;
}
```
With this abstraction, we can implement access checking as follows: 

```rust
impl<KL: KeyStorage + Send + Sync> FromRequestParts<KL> for AuthenticatedUser {
    type Rejection = StatusCode;

    fn from_request_parts(
        parts: &mut Parts,
        state: &KL,
    ) -> impl Future<Output=Result<Self, Self::Rejection>> {
        let auth = parts.headers.get("authorization");
        async move {
            let auth = extract_token_from_header_value(auth)?;

            let (user_id, device_id, jti) =
                extract_user_from_unverified_token(&auth)?;
            let loaded_key = state
                .burn_token_and_load_key(jti, user_id, device_id)
                .await?;
            let authenticated = validate_bearer_token_with_key(&auth, &loaded_key)?;

            Ok(authenticated)
        }
    }
}

/* Interface with the axum header representation, and extract the bearer token - stripping the prefix and rejecting authentication if anything goes wrong */
fn extract_token_from_header_value(auth: Option<&HeaderValue>) -> Result<String, AuthenticationError> {
    let auth = auth.ok_or(AuthenticationError::Unauthenticated)?;
    let auth = auth
        .to_str()?
        .trim();
    let auth = auth
        .strip_prefix("Bearer ")
        .or_else(|| auth.strip_suffix("bearer "))
        .ok_or(AuthenticationError::Unauthenticated)?;
    Ok(auth.to_string())
}

/**
Perform an unvalidated(!) parse of the token to extract iss and sub - the
result of this parse is potentially attacker-controlled and must not be
relied upon for anything but key lookup.

Returns a tuple of (user_id, device_id, jti)
*/
fn extract_user_from_unverified_token(
    auth: &str,
) -> Result<(UserId, DeviceId, String), AuthenticationError> {
    const DUMMY_KEY_FROM_UNVALIDATED_PARSE: &'static [u8] = &[];
    if auth == "" {
        return Err(AuthenticationError::Unauthenticated)?;
    }

    let mut extract_unvalidated = Validation::new(Algorithm::ES256);
    extract_unvalidated.insecure_disable_signature_validation();
    extract_unvalidated.validate_aud = false;
    extract_unvalidated.validate_exp = false;

    let pre_verification_token =
        jsonwebtoken::decode::<Claims>(auth, &DecodingKey::from_ec_der(DUMMY_KEY_FROM_UNVALIDATED_PARSE), &extract_unvalidated)?;

    Ok((UserId(Uuid::parse_str(&pre_verification_token.claims.sub)?),
        DeviceId(Uuid::parse_str(&pre_verification_token.claims.iss)?), 
        pre_verification_token.claims.jti))
}

/** Validate the bearer token against the loaded key */
fn validate_bearer_token_with_key(
    jwt: &str,
    key: &[u8],
) -> Result<AuthenticatedUser, AuthenticationError> {
    let mut extract_verified = Validation::new(Algorithm::ES256);
    extract_verified.validate_nbf = true;
    extract_verified.set_audience(&CONFIG.acceptable_audiences);
    let decoding_key = DecodingKey::from_ec_pem(&key);
    let decoding_key = decoding_key?;
    let token = jsonwebtoken::decode::<Claims>(
        &jwt,
        &decoding_key,
        &extract_verified,
    )?;

    verify_timestamp_contraints(&token)?;

    Ok(AuthenticatedUser {
        user_id: UserId(Uuid::parse_str(&token.claims.sub)?),
        device_id: DeviceId(Uuid::parse_str(&token.claims.iss)?),
    })
}
```
For completeness' sake, we use the following SQL commands to implement KeyStorage (slightly simplified):

```rust
impl KeyStorage for Client {
    fn burn_token_and_load_key(&self, token: String, user_id: UserId, device_id: DeviceId) -> impl Future<Output=Result<Vec<u8>, KeyLoadError>> {
      async move {
            load_keys(self, token, user_id, device_id).await
        }
    }
}

async fn load_keys(client: &Client, token: String,  user_id: UserId, device_id: DeviceId) -> Result<Vec<u8>, KeyLoadError> {
    let burn = client.execute("INSERT INTO burn_record (user_id, jti, expiry) VALUES ($1, $2, now() + INTERVAL 2 DAYS)", &[&user_id, &token]).await
    let Ok(burn_count) = burn else { return Err(KeyLoadError::JTIAlreadyBurned) };
    if burn_count != 1 {
        return Err(KeyLoadError::JTIAlreadyBurned);
    }
    let row = client.query_opt("SELECT public_key FROM devices WHERE user_id = $1 AND device_id = $2", &[&user_id, &device_id]).await;
    let Some(row) = row else { return Err(KeyLoadError::UserDeviceNotFound) };
    let key_material = row.map(|r|r.get("public_key"));
    Ok(key_material)
}
```
## Clientside implementation

For client authentication, we have selected the fusionauth-jwt library (https://github.com/FusionAuth/fusionauth-jwt). This library allows an implementation of the Signer interface, which we use to interact with the StrongBox secure enclave. 

The Android Keystore API leverages the java standard library, and is easy to interact with. Therefore, the implementation required for fusionauth is not complex:
```kotlin
class SecureEnclaveSigner(val keyAlias: String) : Signer {
    override fun getAlgorithm(): Algorithm {
        return Algorithm.ES256
    }

    override fun sign(payload: String): ByteArray {
        val data = payload.toByteArray(StandardCharsets.UTF_8)
        val ks: KeyStore = KeyStore.getInstance("AndroidKeyStore").apply {
            load(null)
        }
        val entry = ks.getEntry(keyAlias, null) as KeyStore.PrivateKeyEntry;
        val derEncoded = Signature.getInstance("SHA256withECDSA").run {
            initSign(entry.privateKey)
            update(data)
            sign()


        }
        return ECDSASignature(derEncoded).derDecode(algorithm)
    }
}
```
Due to this easy integration, we can fallback to the standard java APIs for signing, resulting in very ergonomic and easily-audited code. 

We also include a simplified version of our signing key generator here for easy reference. This omits significant infrastructure code you would usually expect but showcases the general usage.

```kotlin
object SigningKeyGenerator {

    fun newKey(keyAlias: String, requireBiometrics: Boolean): PublicKey {
        val authRequirement = if (requireBiometrics) {
            AUTH_BIOMETRIC_STRONG
        } else {
            AUTH_DEVICE_CREDENTIAL
        }
        val keyPairGenerator = KeyPairGenerator.getInstance(
                KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore");
        keyPairGenerator.initialize(
            KeyGenParameterSpec.Builder(keyAlias, KeyProperties.PURPOSE_SIGN)
            .setAlgorithmParameterSpec(ECGenParameterSpec("secp256r1"))
            .setDigests(KeyProperties.DIGEST_SHA256,
                KeyProperties.DIGEST_SHA384,
                KeyProperties.DIGEST_SHA512)
            .setUserAuthenticationRequired(true)
            .setUserAuthenticationParameters(0, authRequirement)
            .setIsStrongBoxBacked(true)
            .build());
        val keyPair = keyPairGenerator.generateKeyPair();

        return keyPair.public!!
    }
}
```

# Further work
While this article only deals with the Android enclave implementation, similar facilities exist in iOS, and future work could easily achieve similar results using the primitives available on Apple devices. This work hasn't been relevant to our use case, but it is very probably possible with relatively little effort. 

Similarly, smartcard/dongle implementations or using PC TPM features were outside the scope of our project but could probably be implemented.

Some features (such as token burning) could be omitted in lesser-assurance situations. 

As with any security-relevant solution, further research, independent validation, and public scrutiny are essential, which is part of what motivates this article.

Self-issued JWT for mobile client authentication

We all grow older. It is simply inevitable. As the saying goes, The only way to not grow old is to die young. Recently, I've completed my 20th year in the development industry. Through academia, consulting, and a stint in product development, I've learned some lessons once and many repeatedly. I'll try and put the most important of them to digital paper here, and I hope you'll be informed (or at least entertained) by them.

# Nothing beats getting your hands dirty.

First and foremost, software development straddles the divide between art, science, and craft. Everyone will emphasize different parts of this chord, but all three tones will ring when you code. Personally, I think each of the three aspects is of almost equal value.   

Each of these three pillars shares one commonality, though: It requires engagement and practice to become good at each of them. You can read a math textbook and know all the theorems - but unless you work out a few proofs yourself, you'll lack the mindset and thinking patterns to apply the lesson. You can watch a hundred tutorials on woodworking, and they will not help you much as your hand clumsily reaches for a knife and digs the blade into the wrong kind of wood for your project.

Coding is no different. That is why I don't particularly like low-code or visual code tools: They remove the hard part too early. That sounds like a grognard's lament at today's youth, but even in my youth, there were attempts at WYSIWYG editors and fancy UML executors. They did not help me. 

Implementing a connection pool by hand (knowing full well it wouldn't ever be as good as the thing a global community had built) helped me. Reading the specs on Java byte code and crafting a class file from first principles on a hex editor helped me. Understanding how AWS elastic beanstalk provisions more primitive AWS resources for its PAAS solution helped me. 

Once you have the skill, by all means, use the tools available to your heart's content. But always remember that the most essential tool is your own knowledge. And, quite honestly, hitting enough rocks on the side of the paved road makes you appreciate the convenience of the road more - especially since now you know why it is the way it is. Frequently, the context of a technology is as important, if not more so, as its features. 

# Learn by teaching

While in university, I made what might have been one of the best choices of my life: I became a tutor for younger students. I thought it would be an easy enough job: Recount material that was still fresh in my mind and get paid for it. 

I did not account for the sheer wickedness of the student's problems. They challenged my understanding in ways I hadn't thought possible, let alone expected to encounter. Things that seemed self-evident were put under a microscope and examined in detail. 

It's the same principle that makes rubber duck debugging work as well as it does: When you force yourself to abandon the things you take for granted, to go every step of the way instead of skipping the "obvious stuff," you sharpen your focus. 

Occasionally, the student beats the master. Something you teach is entirely wrong. I remember reviewing a junior developer's code that seemed horribly sloppy with resources - opening files repeatedly instead of carefully managing their lifetimes. I could have just rejected their pull request and required them to implement my envisioned sharing scheme. I walked over to their desk (this was the Halcyon pre-COVID days) and opened a conversation. 

They were unconvinced and asked for proof that it was as impactful as I claimed. So I set up a small test to benchmark things, proceeded to run it - and found literally no benefit to the lifecycle scheme. If anything, it performed worse. So I dug in my heels and tried to find out what was happening. As it turned out, the kernel was smarter than me, kept the memory map alive, and turned the re-open into an NOP. 

# Everyone is doing their best(!)

Believe it or not, everyone is doing their best. Or at least, that is the working assumption I've come to take on any given day until proven otherwise. That obstructive penny-pincher in your client's purchasing department who doesn't sign off on the tool you desperately need? They are doing their best because the budget for this year has already run out, and it's not even September yet. That product owner who insists things are done in a farcically complex way that makes no sense at all? They are also doing their best since that is what legal wrote down as "non-negotiables."

Technical skill is essential, but it's only part of the job. The other part is knowing and dealing with people. This is the part I sometimes struggle with the most, to be honest. But it is still essential. Knowing whom to talk to and whom to leave alone. Where to spend your limited social capital and how to enable everyone to do their best is not just a management skill - it is a person skill. 

So, while venting is occasionally cathartic and makes you feel heard, remember that anyone you meet is fighting their own battle. They're doing their best, just like you. 

# Hardware is (almost) never the problem

Your mobile phone has thousands of times the processing power that took the Apollo missions to the moon—just a fact. Of course, we blow it on animated emojis and to serve deceptive ads, but it is there. 

Similarly, three decades ago, even the smallest VM we run our backends on would have been close to a mainframe. So when we hit performance bottlenecks, the answer can certainly be "scale up" or "scale wider" if that is cheap. Money trumps efficiency. But when money becomes an issue, since we can't just make the customer buy new phones, it's time to break out the pliers and dig in.

Algorithms beat silicon, and processes beat algorithms. If something is hard, try to find a different way. Don't bash your head against an NP-complete rucksack problem if you can ask the customer to rank their delivery priorities. Don't do diffractive ray-tracing math to display an overlay on your mobile app. 

The Apollo rockets didn't land on the moon on autopilot - the compute wasn't there. Think of processing power as a budget constraint, and you're on your way.

# Trust but verify

A test suite is an extremely revealing thing. Few things illustrate the development team's unconscious fears as much as what they chose to spend time verifying. Take the business-critical, multi-million euro application I recently was tasked with maintaining. Highly complex code, much business logic. It was virtually untested. But what struck me as the worst part was not how little code the team wrote tests for  - but the tests they wrote. 

There was a class called `ListTest`. It primarily served to verify the correct operation of `java.util.ArrayList`. Similar tests were present for a lot of the libraries the team used. The team seemed to think their code was trustworthy, and the library code needed intense scrutiny. 

Trust, but verify. Trust that libraries do their jobs correctly (at least until you find actual bugs). Regardless, give their source code a glance or two as you begin using them. Immerse yourself and figure out the "vibe" of their team; understand how they speak the language. Chances are, they expect you to speak a similar dialect. 

Trust your teammates to do a good job - but not unthinkingly. Insist on code reviews and knowledge sharing. I don't want to invoke the metaphorical bus here. It'll help both of you out, and you might learn something in the act. That goes double for more experienced developers than you - not only are you given a chance to look at someone's work who had more practice than you. When you find weaknesses and questionable tradeoffs, talk to your coworker. More often than you think, they'll be open to a dialogue. Heck, give them a chance to learn by teaching. Don't short-change either of you on these chances.

# It's okay to be greedy 

Generally, greed is not good, no matter what Gordon Gekko wants you to believe. Greed is destructive, often short-sighted and alienating. But in some very niche, very peculiar circumstances, it is not only valid. It is, in fact, vital. The key is to be greedy for the right things: For cultivation of yourself instead of instant gratification. 

## Be greedy for understanding

Say you face a technical issue in one of your projects. The precise nature does not matter as much as it has you stumped. The deadline is approaching, and you know ChatGPT is just... over there. A click away. Your company policy may or may not allow you to use it, but you know if you copied and pasted your code, it'd spit out something resembling a solution.

You could be quick here and do your job without really doing it. You might even go home a few minutes early. That would be greedy in one way. But you could also be greedy in a smarter way. Greed is selfish. Being greedy, you may also put the project lower on your list of priorities. Instead, invest in yourself by digging your heels in and going all the way to understand and solve the issue. 

And the funny part is that this kind of greed does bring dividends. You will not only be less likely to trip over this problem again and waste an afternoon debugging the same problem you had before. You will also learn and solidify your grasp of the technology of your choice. Learn what works in which way, what warts lurk behind unintuitive designs, and maybe most importantly, you'll build confidence in your ability. After all, you did it yourself, not a sum aggregate of the average ability displayed on GitHub.

## Be greedy to reach the mountain

Envision where you want to be early. Do you want to be the chief architect for your company? Do you want to have a "lead developer" credit for a major open-source project? Or do you want the comfort of earning a six-figure salary and indulging occasionally without giving the price much thought? Do you want to retire by 55 on your savings? Is this only your day job, and is poetry your true passion? All these goals are equally okay, provided you actively choose them. But all of them are similarly unlikely to fall into your lap. You'll have to chase them.

And all too often, we have these goals as vexing, distant things that we don't seriously work towards. There's always another year and something more important "right now." A mountain on the horizon that is, at the same time, tempting and seemingly unreachable.  

A few years ago, I hiked along the Great Glen Trail. From one end of the Scottish highlands to the other. And I saw Loch Ness as a distant glimmer on the horizon - then stood on the southern shore. And eventually, I passed Inverness' city limits on the northern shores. How did I do that? One step at a time. 

Take one step at a time, and be mindful of how all your small choices add up. Be bold and greedy; take one step after another, and you will go farther than you expect. Will you reach your mountain? Not necessarily. But unless you start on the road, you most certainly won't.

# Conclusions

So, where is the silver bullet that'll make you a better dev? Not here, I'm afraid. It won't be anywhere - because, like any craft, you learn something new every day. It's been 20 years, and I learned a lot. Imagine what I'll have learned when I'm 64.

20 years of coding

Contact Us | Fragen an Mitarbeiter

Sprich mich an

Möchtest du dich mit mir zu Java's Fußangeln austauschen?

BLOG

codecentric Blog

Auf unserem Blog findest du viele Artikel zu Tech-Themen von unseren Mitarbeitenden. Vielleicht ist auch hier ein Thema für dich dabei. Schau gerne mal rein!

WISSENS-HUB

Events – codecentric mittendrin

Community

Kultur

Der Softwerker

Hier gibt's noch mehr spannende Infos von uns für euch

Java und die Fußangeln in der Programmiersprache | codecentric AG

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Java und die Fußangeln in der Programmiersprache

Aus dem Inhalt:

Hier gibt's noch mehr spannende Infos von uns für euch

codecentric Blog

Events – codecentric mittendrin

Der Softwerker

Jetzt für unseren Newsletter anmelden