Cloud-Native

Data & KI

Produktentwicklung

Resilienz & IT-Security

Leistungen

Arbeitsweise

Projekte

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

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

International contact

Alle Standorte

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

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

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://media.graphassets.com/Y99ewArQevMPJ4k9L9lg" 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://media.graphassets.com/dUUD2F9TBub4uiJpJT9z"><img width="3840" height="1040" src="https://media.graphassets.com/dUUD2F9TBub4uiJpJT9z" 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://media.graphassets.com/euiJkoW5RhiOdyVkOpd4"><img loading="lazy" width="3840" height="1612" src="https://media.graphassets.com/euiJkoW5RhiOdyVkOpd4" 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://media.graphassets.com/00Ne8BLGTE2rkr5BlAk5"><img loading="lazy" width="2275" height="1360" src="https://media.graphassets.com/00Ne8BLGTE2rkr5BlAk5" 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://media.graphassets.com/BhKsNUrPTqS0HDCts4BN"><img loading="lazy" width="3633" height="982" src="https://media.graphassets.com/BhKsNUrPTqS0HDCts4BN" 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://media.graphassets.com/ELANKE0TlGzVWzMLxbYF"><img loading="lazy" width="1172" height="754" src="https://media.graphassets.com/ELANKE0TlGzVWzMLxbYF" 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://media.graphassets.com/lLRrJmhRGmaLpS0GCaKr"><img width="250" height="74" src="https://media.graphassets.com/lLRrJmhRGmaLpS0GCaKr" 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://media.graphassets.com/0IRpAynvR3mMx7oFFCnk"><img loading="lazy" width="250" height="128" src="https://media.graphassets.com/0IRpAynvR3mMx7oFFCnk" 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://media.graphassets.com/GQVPnPi1TU6RHCAyt0nM"><img loading="lazy" width="250" height="121" src="https://media.graphassets.com/GQVPnPi1TU6RHCAyt0nM" 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

Sprich mich an

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

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!

BLOG

codecentric Blog

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.

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.

Ich habe die \nDatenschutzbestimmungen\n und die Einwilligung in die Datenverarbeitung gelesen und stimme diesen zu.*

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.

Kontakt

Absenden

Java und die Fußangeln in der Programmiersprache

Aus dem Inhalt:

Sprich mich an

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

codecentric Blog

Events – codecentric mittendrin

Der Softwerker

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten