Wir sind eine zertifizierte B Corporation.

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

Kultur & Karriere Podcast

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.

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

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

IT Consultant & Software Engineer

IT-Consultant

Informatik Aktuell

Python

Data Science

Python – Static Duck-Typing

Python erfreut sich schon seit längerem einer enormen Beliebtheit und hat durch den vermehrten Einsatz im Bereich des Data Science und Engineering einen weiteren Sprung in der Verbreitung geschafft. 

<p>In diesem Artikel erläutern wir unsere IIoT-Lösung zur autonomen, deklarativen Pflanzenzucht. Dieser Artikel ist der zweite in unserer Reihe zu IIoT. Der <a href="https://blog.codecentric.de/en/2020/11/iiot-product-development-lessons-from-past-projects/">erste Artikel</a>  befasste sich mit allgemeinen Fragen und Problemstellungen zum Thema. Pflanzen zu züchten stellt einzigartige Anforderungen an Hardware, Software und die Steuerungslogik. Dies führt auch zu einzigartigen Lösungen. Unsere IIoT-Lösung ist Hardware-agnostisch, erlaubt Reparaturen und Updates in Produktion ohne Stopp und kann kosten- und zeiteffizient auf andere Anforderungen umgerüstet werden. Die Lösung ist dabei nicht auf die Pflanzenzucht beschränkt.</p><p>Vor über 100 Jahren löste das Auto das Pferd als Transportmittel ab. Durch die Mechanisierung des Transportes war der Weg für dessen Elektrifizierung und schließlich Automatisierung geebnet. Dies gipfelt im autonomen Verhalten von Autos, Mähdreschern und Flugzeugen. Ein Pferd zu automatisieren ist schwer, bei einem Automobil ist dies leichter. Auch hier bietet sich zusätzliches Potential zur Automatisierung.</p><h2>Die Landwirtschaft der Zukunft</h2><p>Ähnliches möchten wir mit unseren Kunden für das Züchten von Pflanzen ermöglichen. Felder und Bauern lassen sich schwerlich automatisieren, doch durch den Übergang zu mechanisierten und elektrisierten Anbausystemen ist dieser Weg leicht. Gleichzeitig lässt sich dadurch die Hürde des optimalen „Rezeptes“ angehen, also einer Abfolge von Instruktionen, wann die Pflanze auszusäen, zu bewässern und zu ernten ist. Ideale Wachstumsbedingungen können eingestellt werden und am Ende wählt der Agrarökonom lediglich ein Rezept für eine Pflanze. Dadurch erhält er ein sauberes, sicheres, reproduzierbares Lebensmittel, das auf dem Weltmarkt konkurrieren kann. Seine Arbeit wird vereinfacht auf die Auswahl der Saaten, die Überwachung der Geräte und die Vermarktung seiner Ernte. Alles wird lückenlos automatisiert protokolliert und belegt damit die Qualität und Sicherheit der produzierten Waren. Vor allem im Feld medizinischer Pflanzen ist solch eine lückenlose Überwachung relevant für geeignete Zertifizierung.</p><p>Pflanzen sind lebendig, sie wachsen, blühen und sterben. Sie benötigen u. a. Wasser, Nährstoffe, Wärme, Licht und wechselnde Luft. Sie sind vergleichsweise träge gegenüber Veränderungen ihrer Umwelt. So hat ein Lichtimpuls von wenigen Sekunden hoher Helligkeit nur geringen Einfluss auf die Pflanze. Um höchstmöglichen Ertrag zu erhalten, eignet sich die aeroponische Anbauweise, d. h. die Wurzeln stecken nicht in Erde, sondern befinden sich in Luft und werden mit Nährlösung bedampft. Dadurch werden sowohl Erde als auch Wasser gespart. Allerdings benötigen die Pflanzen mindestens alle fünf Minuten Wasser, da sie sonst regelrecht ersticken. Somit muss unser System zwingend in der Lage sein, die Pflanzen innerhalb von fünf Minuten zu „gießen“.</p><p>Fällt das System länger als fünf Minuten aus, so stirbt also die Pflanze. Dadurch kann ein mehrwöchiger Produktionslauf komplett verloren gehen. Anders als bei einem klassischen IIoT-Projekt, bei dem zum Beispiel eine Produktionsstraße automatisiert wird, ist ein kurzzeitiger Ausfall während der Aufzucht der Pflanze durchaus vergleichbar mit einem Totalschaden. Bei einer klassischen Produktionsstraße hingegen lässt sich häufig problemlos der Betrieb nach einer Störung wieder aufnehmen. Das Zeitfenster für eine Störung bei der Bewässerung der Pflanzen beträgt jedoch maximal die oben genannten fünf Minuten. Daher muss unser System in der Lage sein automatisch, schnell und sicher wieder produktiv zu werden. Das System muss ausfallende Geräte überstehen und flexibel darauf reagieren. Fest einprogrammierte Abfolgen wie in einer normalen speicherprogrammierbaren Steuerung (SPS) würden uns hier einschränken. Dies unterscheidet unser System natürlich deutlich von klassischen SPS-Systemen. Folgend gehen wir auf diese Unterschiede im Detail ein.</p><h2>Der Pflanzen-Thermomix und seine Rezepte</h2><p>Es ergibt sich, dass wir ein flexibles System benötigen. Ein ebenso agiler Entwicklungs- und Prototypisierungsprozess erleichtert es uns, dieses System von Grund auf zu entwerfen. Zusammen mit den Vorgaben unseres Kunden ergeben sich dadurch mehrere Randbedingungen. Zunächst war ein Revolution Pi (RevPi) mit digitalen und analogen Ein- und Ausgängen sowie Modbus- und Ethernetschnittstellen zur Gerätesteuerung vorgegeben. Der RevPi ist ein Industrie-zertifizierter Computer basierend auf dem als Open Source verfügbaren Raspberry Pi Compute Model. Als zentrale Steuereinheit kann er frei programmiert und via USB oder Ethernetschnittstellen gesteuert werden. Wir haben dafür Python genutzt, da wir so schnell verschiedene Prototypen entwickeln und testen konnten. Da keine auf Millisekunden genaue Steuerung benötigt wurde, reichte die Ausführungsgeschwindigkeit auch aus. Die Lösung lässt sich bei Bedarf nach C++, Rust u. a. portieren. In unserem Use Case war die Entwicklungsgeschwindigkeit wichtig und die die Ausführungsgeschwindigkeit mit Python ausreichend.</p><p>Unsere Lösung ist gut vergleichbar mit einem Thermomix für Pflanzen. Wir wählen ein Rezept in einer Weboberfläche aus, bspw. „Feinblättriger Basilikum“, befüllen das Gerät mit den „Zutaten“, also Setzlingen, Wasser und Nährstoffen. Das Gerät startet und nach ein paar Wochen öffnet sich die Tür der Mikroplantage mit den fertig gezüchteten Pflanzen. In der Zwischenzeit bietet uns ein Dashboard Überblicke über das Pflanzenwachstum und den Zustand der Mikroplantage. Die Nutzung und Umrüstung der Anlage benötigt keinen Techniker oder weiteres spezielles Personal und vereinfacht den Betrieb drastisch.</p><p>Das Rezept zeichnet sich durch einen deklarativen Ansatz aus, d. h. auf einer Zeitachse sind Aktionen angegeben, wie bspw. „Schalte Licht an“, „Heize auf 35°C“ oder „Bedampfe mit 10g Wasser“. Dabei ist es unwichtig für das Rezept, wer der Hersteller der konkreten Hardware ist. Wichtig ist lediglich, dass die Mikroplantage innerhalb der Spezifikation auf 35°C aufgeheizt. Vergleichbare Hardware verschiedener Anbieter kann mit wenig Aufwand ausgetauscht werden. Das Rezept kann leicht generiert und verändert werden. Es beinhaltet die Business-Logik. Jede*r Benutzer*in kann das Rezept geeignet anpassen und auf einer Mikroplantage starten. Ein*e Techniker*in ist nicht nötig. Das Rezept kann vor Start validiert werden, sodass unmögliche oder zerstörerische Abläufe nicht in Produktion kommen.</p><p>Damit unterscheidet sich unser System von einer traditionellen SPS, da statt aufwendig fest einprogrammierter Abfolgen ein dynamisches Verhalten umgesetzt wird. Dieser Ansatz ist zwar komplexer und potenziell fehleranfälliger, aber gleichzeitig flexibler gegenüber Änderungen der Umgebung und Anforderung. Das Rezept und die benutzte Hardware können in Produktion verändert werden. Das verringert die Ausfallzeiten und macht unsere Lösung wertvoller für Kunden mit breit gefächerten Anwendungsgebieten, da die Umrüstung der Mikroplantage einfach ist. Im Falle eines Ausfalls ist die Mikroplantage in der Lage, das Rezept nahtlos fortzuführen. Selbst bei einem Ausfall des RevPi ist ein Austausch dieser sowie Wiederaufnahme der Produktion innerhalb von fünf Minuten möglich. So bringt die mit der Flexibilität einhergehende Komplexität direkten Mehrwert und potentielle Fehler werden systematisch und kategorisch abgefedert. Fehler werden protokolliert und können durch Updates auch im laufenden Betrieb vollständig behoben werden. Diese Resilienz ist elementar für die maximal fünf Minuten Ausfallzeit, damit die Pflanzen überleben.</p><h2>Die Software des Pflanzen-Thermomix</h2><p>Softwareseitig besteht unsere Architektur aus drei wesentlichen Komponenten: der Engine, den Regelkreisläufen und den Gerätetreibern. Die Engine kümmert sich um Zeit und fordert Regelkreisläufe auf, die Instruktionen aus dem Rezept zu verarbeiten. Die Engine sieht also nicht die Hardware, sondern lediglich Instruktionen, während die Regelkreisläufe das Rezept nicht sehen. Die Regelkreisläufe werden damit beauftragt, diese Instruktionen umzusetzen, bspw. „Heize auf 35°C“. Sie implementieren die Logik zur Umsetzung, bspw., „Heize über Treiber A, bis Treiber B 35°C anzeigt“. Die Gerätetreiber sind Schnittstellen, die Regelkreisläufe interagieren nicht direkt mit der Hardware. Dadurch sind die Regelkreisläufe in der Lage, verschiedene Hardwareversionen, -hersteller und -szenarien zu bedienen. Fällt der eben genannte Treiber B aus, der die Temperatur misst, so kann nahtlos Treiber C einspringen. Sowohl Treiber B als auch C sind Temperatursensoren, aber Treiber C nutzt einen einfacheren Sensor an einer anderen Position in der Mikroplantage. Daher muss Treiber C anders behandelt werden, was im Regelkreislauf beschrieben ist.</p><p>Ein Regelkreislauf kann dabei unterschiedlich eng mit einer Hardwarekombination gekoppelt sein und lässt sich austauschen, ohne das Rezept anpassen zu müssen. Wenn bspw. ein Hersteller eine Feedbackschleife in der Hardware implementiert und ein anderer nicht, so kann dies im entsprechenden Regelkreislauf gesondert implementiert werden. Bieten beide Hersteller die gleiche Funktionalität, aber sprechen ein anderes Protokoll oder nutzen andere Adressen, werden lediglich andere Gerätetreiber benötigt. Ändert sich von einer Version auf die nächste nur eine Adresse bei gleicher Funktionalität, muss nur die Konfiguration im Treiber angepasst werden. Erst die Gerätetreiber interagieren direkt mit der Hardware. Sie beinhalten die Protokolle und erhalten „SOLL“- und „MESS“-Befehle. Die Gerätetreiber fungieren damit als Hardware Abstraction Layer. Gemeinsamkeiten unter den Treibern können dabei geteilt werden, was die Implementierung neuer Treiber stark beschleunigt.</p><h2>Modulares System</h2><p>Diese Dreiteilung ermöglicht uns eine Separierung von Business-Logik, dem Rezept, sowie der eigentlichen Hardware in den Gerätetreibern. Alles ist flexibel austauschbar, ohne dass andere Elemente angepasst werden müssen. Die Komponenten interagieren über abstrahierte Schnittstellen, sodass auch hier ein Austausch von Komponenten reibungslos abläuft. Diese vorgegebenen Schnittstellen vereinheitlichen die Kommunikation, was uns einen Zugewinn an Flexibilität und Geschwindigkeit bei der Produktentwicklung ermöglicht. Dieses Gesamtpaket stellt die geforderte hohe Verfügbarkeit und Resilienz sicher.</p><p>Die hohe Flexibilität ermöglicht uns, problemlos unsere Lösung auf andere Use Cases und Business-Logiken umzustellen. Im Idealfall muss nur das Rezept angepasst werden, im Extremfall die Business-Logik in den Regelkreisläufen und die Gerätetreiber, während die Architektur, Kommunikation, Resilienzmechanismen und Überwachungssysteme unangetastet funktional bleiben.</p><p>All dies macht unsere Lösung interessant für neuartige Anwendungsfelder, in denen die Anforderungen und Hürden noch nicht bekannt sind. Statt wochen- und monatelang über Anforderungen, Architekturen und ähnliches zu diskutieren, können wir zügig einen Proof of Concept umsetzen und testen. Dadurch kann in Test- und Produktionsumgebungen hypothesengetrieben gearbeitet werden. Anforderungen können so zielgenau getestet und gelöst werden. Sollte sich eine Komponente als unzureichend erweisen, kann sie problemlos ausgetauscht werden, ohne zurück ans Reißbrett zu müssen. Zusammen mit unserem Ansatz sind wir hardware-agnostisch und können eine kosten- und zeiteffiziente Lösung anbieten.</p><h2>Fazit</h2><p><a href="https://media.graphassets.com/pAVsk1hNRJeOs7oaaep3"><img loading="lazy" width="1024" height="576" src="https://media.graphassets.com/pAVsk1hNRJeOs7oaaep3" alt="Kräuter wachsen als Beispiel-Pflanzen sehr gut in unserem Prototyp." /><figcaption>Erfolgreicher Kräutergarten.</figcaption></a> </p><p>In diesem zweiten Blogpost unserer Reihe zu IIoT haben wir aufgezeigt, wie das automatisierte Züchten von Pflanzen die Standardlösungen von IIoT in Frage stellt. Kurze und schnelle Feedback- und Entwicklungszyklen beeinflussen die Hardwarewahl, Programmiersprache und Softwarearchitektur. Gleichzeitig gewinnt unser System an Flexibilität und ist damit für breite Anwendungszwecke geeignet. In den folgenden Artikeln gehen wir näher auf die Details unserer technischen Implementierung und Architektur ein.</p>

IIoT mal anders: Rezepte für den Pflanzen-Thermomix

<p>In this article we explain our IIoT solution for autonomous, declarative plant growing. This article is the second in our series on IIoT. The <a href="https://blog.codecentric.de/en/2020/11/iiot-product-development-lessons-from-past-projects/">first article</a>  dealt with general questions and problems about IIoT. Growing plants offers unique requirements for hardware, software, and control logic. This also leads to unique solutions. Our IIoT solution is hardware-agnostic, allows for repairs and updates in production without interruption, and can be converted to other use cases in a cost- and time-efficient way. The solution is not limited to plant growing.</p><p>More than a hundred years ago, the car superseded the horse as the main means of transport. This mechanisation of transport paved the way for its electrification and eventual automation, culminating in the autonomous behaviour of cars, harvesters, and aeroplanes. Automating a horse is hard, automating an automobile is easier. Here, too, there is additional potential for automation.</p><h2>The agriculture of the future</h2><p>We want to enable something similar with our customers for growing plants. Fields and farmers are difficult to automate, but the transition to mechanised and electrified farming systems makes this path easy. At the same time, it allows the obstacle of the optimal “recipe” to be addressed, i. e. a sequence of instructions on when to plant, irrigate, and harvest the crop. Ideal growing conditions can be set and in the end the agricultural economist simply chooses a recipe for a plant. This gives him a clean, safe, reproducible food product that can compete on the world market. His work is simplified to selecting seeds, monitoring equipment and marketing his harvest. Everything is recorded in a completely automated way, proving the quality and safety of the goods produced. Especially in the field of medicinal plants, such seamless monitoring is relevant for appropriate certification.</p><p>Plants are alive, they grow, blossom, and die. They need water, nutrients, warmth, light, and changing air, among other things. They are comparatively inert to changes in their environment. A light impulse of a few seconds of high brightness has only little influence on the plant. In order to obtain the highest possible yield, the aeroponic cultivation method is suitable, i. e., the roots are not covered in soil, but are in air and steamed with nutrient solution. This saves both soil and water. However, the plants need water at least every five minutes, otherwise they literally suffocate. Thus, our system must be able to “water” the plants within five minutes.</p><p>So if the system fails for more than five minutes, the plant dies. This means that a production run lasting several weeks can be completely lost. Unlike in a classic IIoT project, in which, for example, a production line is automated, a short-term failure during the cultivation of plants can be a total loss. With a classic production line, on the other hand, operation can often be resumed without any problems after a malfunction. However, the time window for a malfunction during the irrigation of the plants is at most the five minutes mentioned above. Therefore, our system must be able to automatically, quickly, and safely become productive again. The system must be able to withstand and react flexibly to failed equipment. Fixed programmed sequences like in a normal PLC would limit us here. Of course, this clearly distinguishes our system from classic PLC systems. In the following, we will go into these differences in detail.</p><h2>The plant thermomix and its recipes</h2><p>It turns out that we need a flexible system. An equally agile development and prototyping process simplifies it for us to design this system from scratch. Together with our client’s specifications, this results in several constraints. First, a Revolution Pi (RevPi) with digital and analogue inputs and outputs as well as Modbus and Ethernet interfaces for device control was specified. The RevPi is an industry-certified computer based on the open-source Raspberry Pi Compute Model. As the main control unit, it can be freely programmed and controlled via USB or Ethernet interfaces. We used Python for this because it allowed us to quickly develop and test different prototypes. Since we did not need control with millisecond precision, the execution speed was sufficient. If necessary, the solution can be ported to C++, Rust, and others. In our use case, however, the development speed was important and the execution speed with Python sufficient.</p><p>Our solution is comparable to a thermomix for plants. We select a recipe in a web interface, for example “basil”, fill the device with the “ingredients”, i. e. seedlings, water, and nutrients. The device starts and after a few weeks the door of the micro-plantation opens with the ready-grown plants. In the meantime, a dashboard gives us an overview of the plant growth and the condition of the micro-plantation. The use and conversion of the unit does not require a technician or other special staff and drastically simplifies the operation.</p><p>The recipe is characterised by a declarative approach, i. e. actions are specified on a time axis, such as “switch on light”, “heat to 35°C” or “spray 10 g of water”. It is unimportant for the recipe who the manufacturer of the specific hardware is. The only important thing is that the micro-plantation heats up to 35°C within the specification. Comparable hardware from different suppliers can be exchanged with little effort. The recipe can be easily generated and modified. The recipe contains the business logic. Any user can customise the recipe and start it on a micro-plantation. A technician is not necessary. The recipe can be validated before starting, so that impossible or destructive processes do not go into production.</p><p>This distinguishes our system from a traditional PLC, since dynamic behaviour is implemented instead of hard-coded sequences. This approach is more complex and potentially more error-prone, but at the same time more flexible to changes in the environment and requirement. The recipe and the hardware used can be changed in production. This reduces downtime and makes our solution more valuable to customers for a wide range of applications as it is easy to retool the micro-plantation. In the event of a failure, the micro-plantation is able to continue the recipe seamlessly. Even if the RevPi fails, it can be replaced and production resumed within five minutes. Thus, the complexity that comes with flexibility brings direct added value and potential errors are systematically and categorically mitigated. Errors are logged and can be completely eliminated through updates, even during operation. This resilience is elementary for the maximum five-minute downtime so that the plants survive.</p><h2>The software of the plant thermomix</h2><p>On the software side, our architecture consists of three main components: the engine, the circuits, and the device drivers. The engine takes care of time and asks circuits to process the instructions from the recipe. The engine does not see the hardware, but only instructions, while the circuits do not see the recipe. The circuits are tasked with implementing these instructions, e. g. “heat to 35°C”. They contain the logic for the implementation, e. g., “heat via driver A until driver B indicates 35°C”. The device drivers implement interfaces, providing an abstraction, so the circuits do not interact directly with the hardware. This means that the circuits are able to operate different hardware versions, manufacturers, and scenarios. If the aforementioned driver B, which measures the temperature, fails, driver C can seamlessly step in. Both drivers B and C are temperature sensors, but driver C uses a simpler sensor at a different position in the micro-plantation. Therefore, driver C must be treated differently, which is described in the circuit.</p><p>A circuit can be differently coupled with a hardware combination and can be exchanged without having to adapt the recipe. For example, if one manufacturer implements a feedback loop in the hardware and another does not, this can be implemented separately in the corresponding circuit. If both manufacturers offer the same functionality but speak a different protocol or use different addresses, only different device drivers are required. If only one address changes from one version to the next with the same functionality, only the configuration in the driver must be adapted. Only the device drivers interact directly with the hardware. They contain the protocols and receive “SET” and “GET” commands. The device drivers thus function as a hardware abstraction layer. Similarities among the drivers can be shared, which greatly accelerates the implementation of new drivers.</p><p>These three components allow us to separate business logic, the recipe, and the actual hardware in the device drivers. Everything can be exchanged flexibly without having to adapt other elements. The components interact via abstracted interfaces, so that an exchange of components is as smoothly possible. These predefined interfaces standardise communication, which allows us to gain flexibility and speed in product development. This package as a whole ensures the required high availability and resilience.</p><p>The high flexibility enables us to easily adapt our solution to other use cases and business logic. Ideally, only the recipe needs to be adapted, in extreme cases the business logic in the circuits and the device drivers, while the architecture, communication, resilience mechanisms and monitoring systems remain functional.</p><p>All this makes our solution interesting for novel fields of application where the requirements and hurdles are not yet known. Instead of spending weeks and months discussing requirements, architectures and the like, we can quickly implement and test our proof-of-concept. This allows hypothesis-driven work in test and production environments. Requirements can thus be tested and solved precisely. If a component proves to be insufficient, it can easily be replaced without having to go back to the drawing board. Together with our approach, we are hardware-agnostic and can offer a cost- and time-efficient solution.</p><h2>Conclusion</h2><p><a href="https://media.graphassets.com/33UUv5q2SpqIHraoncTI"><img loading="lazy" width="1024" height="576" src="https://media.graphassets.com/33UUv5q2SpqIHraoncTI" alt="Herbs are growing as test plants in our prototype." /><figcaption>A successful herb garden.</figcaption></a> </p><p>In this second blog post of our series on IIoT, we have shown how automated plant growing challenges the standard solutions of IIoT. Short and fast feedback and development cycles influence the hardware choice, programming language, and software architecture. At the same time, our system gains flexibility and is thus suitable for a broad range of use cases. In the following articles, we will go into more detail about our technical implementation and architecture.</p>

A different flavour of IIoT: Recipes for the plant thermomix

Contact Us | Fragen an Mitarbeiter

Sprich mich an

Möchtest du dich über den "pythonic way" des Duck Typings 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

Softwareentwicklung

Kultur

Der Softwerker

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

Python – Static Duck-Typing | 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.

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.

Absenden

Python – Static Duck-Typing

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