Was denkst du, welchem Prinzip sollte man folgen beim erstellen einer neuen  App oder Software. Warum sollte man den entsprechenden Weg und warum?

In meinem letzten Job als Lead Flutter App Entwickler sind wir dem Prinzip "Clean Architecture" gefolgt. Wir waren am Anfang 5 Entwickler, die nur die App entwickelt haben. Wir hatten Zeit eine gute Architecture aufzusetzen und anschließend dem Prinzip zu folgen. 

Jetzt, wo ich Shiftly24 entwickle, folge ich dem KISS Prinzip. 
### KISS= Keep it simple stupid

![Design ohne Titel (16).png](https://api.tech-blog.info/uploads/in-post-images/19b6f291ddba9454c95c8b3b7260bb47140c753e.png)

Da ich alles allein entwickle, also das Frontend, Backend und die Mobile-App, kann ich mir zeitlich nicht erlauben eine aufwendige Architektur aufzusetzen. So lange du vernünftigen Code schreibst, die Errors sauber abfängst, funktioniert eine Software auch ohne aufwendige Architektur.

Was meinst du? 

Was ist besser, folgen dem KISS oder dem Clean-Architecture Prinzip

KISS oder Clean Architecture 

Ich war arbeitssuchend, etwas erschrocken über den Markt für App-Entwickler. Ich ging zu meiner Sachbearbeiterin bei der Agentur für Arbeit und erzählte ihr von meiner Herausforderung einen neuen Job als Flutter Entwickler zu bekommen. Sie schlug mir vor eine Weiterbildung zu machen, um mich weiter zu qualifizieren. Gesagt, getan... Ich habe mir ein Coding-Bootcamp names **Spiced Academy** herausgesucht und beworben. Ich hatte ein Gespräch und einen kleinen Online-Test. Alles keine echte Herausforderung. 
Als ich die Zusage hatte, habe ich alles mit meiner Sachbearbeiterin abgesprochen und den Gutschein bekommen. Die Formalitäten gingen ziemlich reibungslos, aber nur die.

![Photobasedads-Squarepng.jpeg](https://api.tech-blog.info/uploads/in-post-images/9ef9406b2789e185189187665522e8983782f5c2.jpeg)

Dann kam plötzlich die Email, die Email die mir mitteilte, dass mein Starttermin abgesagt und um 10 Tage nach hinten verschoben wird. Gründe wurden mir nicht mitgeteilt. Ich dachte mir nur, kann ja mal passieren. 🤷🏼‍♂️ Doch dann, auch dieser Termin wurde 3 Tage vorher abgesagt. 
Da ich bereits in dem Slack-Channel eingeladen wurde, habe ich dort einfach mal in einen Channel geschrieben, ob es auch jemanden so erging und es hatte sich jemand gemeldet. Die Person meinte, dass es bei Ihr das 3. Mal in Folge ist, dass Ihr Termin abgesagt wurde. Das war mir zu viel, wer konnte mir garantieren, dass es nicht wieder geschieht. Mir wurde angeboten, dass ich in Hamburg bei "Neue Fische" online teilnehmen kann, doch ich wollte hier in Berlin an einem Campus mich versuchen. Ich wollte einfach mal wieder raus unter Menschen kommen. Ich wollte neue Leute kennenlernen und meinen Trott verlassen. 

![2dnyeSMt_400x400.jpg](https://api.tech-blog.info/uploads/in-post-images/da3635e13d84cee75123230cedadc95db7f4d855.jpg)

Also, was nun? Die Thematik Coding-Bootcamp vergessen, abhaken und so weiter machen? Mir wurde dann das Coding-Bootcamp Ironhack empfohlen. Ich habe mich mit denen in Verbindung gesetzt, Ihr angebot gecheckt und was soll ich sagen, am Ende ging alles ziemlich schnell. Nun sind die ersten 3 Wochen des Bootcamps vorbei, ich habe viele coole neue Leute kennengelernt und versuche das Beste, diese Challenge zu meistern.

Meine ersten Erfahrungen mit Coding Bootcamps in Berlin

Coding Bootcamps - Erste Erfahrungen

Es war Sommer 2020, ich arbeitete für ein Fintech-Startup als Collection-Advisor und habe nebenbei Jura studiert. Ich hatte damals das Ziel, endlich einen Uni-Abschluss zu erreichen. 
In meiner Freizeit habe ich weiter Chinesisch gelernt. 2014 hatte ich angefangen Chinesisch zu lernen und war auch ein Jahr an der Universität für Außenhandel und Wirtschaft in Peking. 

Ich hatte die Idee, eine Sprachapp zu entwickeln, um Chinesen zu helfen Deutsch zu lernen. Eine einfache Idee, doch es würde schon daran scheitern, dass ich nicht wusste, woher man eine App bekommen sollte. Woher nehmen, wenn nicht stählen. 

Also googelte ich: "Wie programmiert man eine App" und kam auf dieses video: https://www.youtube.com/watch?v=lpPan81PkQ8index=3

![startupteen.png](https://api.tech-blog.info/uploads/in-post-images/cb3fd2d9e6c0314e96251661285b9508d93e1d0b.png)
Ich habe mir das Video angeschaut und dachte: "Das bekomme ich hin!" Doch der start war alles andere als leicht. Ich habe alles installiert, dass allein war herausfordernd. Man benötigt mehrere Tools, die es zu installieren gilt. Doch irgendwann war es geschafft, flutter doctor sprang auf grün. Als ich dann das erste mal die Demo-App laufen ließ, wurde mein "Laptop" mit nur 4 GB RAM und keine Lüftung so heiß, dass ich angst hatte, dass es schmelzen könnte. Natürlich war der Laptop so überfordert, dass sich nicht wirklich was auf dem Bildschirm bewegte. Doch ich war begeistert, denn theoretisch funktioniert es. Nur der Laptop war nicht stark genug. Also ging ich los mir einen neunen Laptop kaufen, einen mit 8 GB RAM und eine Lüftung, denn mein eigentlicher Laptop ist wirklich geschmolzen. Er hat sich so verbogen, dass man ihn nicht mehr zuklappen konnte. 🤷🏼‍♂️



Mit der Frage "Wie programmiert man eine App" startete für 4 Jahren meine Reise als Software-Entwickler

Wie programmiert man eine App

Inmitten eines scheinbar gewöhnlichen Entwicklungstages stieß ich auf ein Hindernis, das meine Geduld und mein technisches Know-how auf die Probe stellte. Die Konsole warf mir unerwartet die Fehlermeldung "413 Request Entity Too Large" entgegen, eine Rückmeldung, die aus heiterem Himmel kam, besonders da ich zuvor keine Schwierigkeiten mit CORS (Cross-Origin Resource Sharing) in dieser Hinsicht hatte. Meine Verzweiflung wuchs, während ich jede erdenkliche Lösung ausprobierte: Ich passte die Multer-Bibliothek im Backend an, indem ich die Dateigrößenbeschränkung auf 5 x 1024 x 1024 Bytes erhöhte, und erweiterte sogar die Serverkapazitäten, in der Hoffnung, das Problem zu beheben. Doch nichts schien zu funktionieren.

In meiner Ratlosigkeit wandte ich mich an ChatGPT und Gemini, zwei Quellen, von denen ich mir erhoffte, sie könnten Licht ins Dunkel bringen. Doch trotz ihrer sonst so verlässlichen Hilfe fand ich keine zufriedenstellende Lösung für mein Problem.. 

m Bemühen, den Knoten zu durchschlagen, stieß ich auf einen Stackoverflow-Thread, der sich mit genau dieser Problematik auseinandersetzte. Es war ein Moment des Innehaltens und der Reflexion, unterstützt durch den kollektiven Geist der Entwicklergemeinschaft, der auf dieser Plattform zusammenkommt.

Stackoverflow: https://stackoverflow.com/questions/18121227/how-to-avoid-request-entity-too-large-413-error

![WhatsApp Image 2024-03-05 at 12.56.15.jpeg](https://api.tech-blog.info/uploads/in-post-images/c04d39136a3d1a30da672bef0fbd2dba8df74ebc.jpeg)

Die Lösung, so einfach sie letztendlich war, entging mir bis zu dem Moment, als ich auf die Bedeutung der Direktive client_max_body_size im Kontext des Nginx-Servers aufmerksam wurde. Standardmäßig auf 1MB gesetzt – eine Tatsache, die nirgendwo explizit erwähnt wurde – stellte diese Einstellung das unsichtbare Hindernis dar, das mich bis dahin aufgehalten hatte. Die Einführung der Zeile client_max_body_size 5m; in die Nginx-Konfiguration war der Schlüssel, der das Problem endlich löste.

Es war einer dieser Momente, die einen daran erinnern, warum die Arbeit als Fullstack-Entwickler sowohl herausfordernd als auch ungemein bereichernd sein kann. Die Lösung eines Problems, das zunächst unüberwindbar schien, erforderte nichts weiter als einen scharfen Blick für die Details und die Bereitschaft, auch die kleinsten Konfigurationsaspekte nicht zu übersehen. Dieses Erlebnis war eine wertvolle Erinnerung daran, dass die Antworten manchmal in den unauffälligsten Einstellungen verborgen liegen und dass der Austausch mit der Entwicklergemeinschaft oft den entscheidenden Hinweis liefern kann. Es war ein typischer Tag im Leben eines Fullstack-Entwicklers – voller Überraschungen, Lernmomente und letztendlich der Zufriedenheit, eine störrische Herausforderung gemeistert zu haben.


413 Request Entity Too Large - Error beim Upload eines Images

413 Request Entity Too Large Error

Ich hatte ein Problem mit dem SMTP & Port 587 und habe nicht verstanden, was genau das Problem ist. Es ging um Nodemailer, warum er auf Localhost reibungslos funktioniert hat aber nicht in Production. Sicher, der ein oder andere weiß sofort, wo das Problem ist 🤷🏼‍♂️ doch ich war ratlos. Ich hatte den Port 587 ausgewählt, alles eingestellt und den Port auf dem Server in der Firewall freigegeben. Doch es funktionierte nicht, permanent ein Time out. Also, was macht man, man fragt ChatGPT und Gemini. 

Mir ist aufgefallen, dass ich mittlerweile als Entwickler immer den einfachen Weg gehe, statt an der Herausforderung zu wachsen. Ein Freund meinte mal: "Alle sind wie Junkies, nutzen beim kleinsten Problemchen ChatGPT, statt eigenständig die Probleme zu lösen und werden von der KI abhängig." Mittlerweile verstehe ich die Aussage. Mir gehts genauso, ich bin wie ein Junkie, statt mir das Problem genau anzuschauen, zu durchdringen und daraus eine Lösung abzuleiten, frage ich die KI. Es ist einfach, praktisch und schnell. Und ehrlich gesagt, ist sie unglaublich hilfreich, Tipfehler zu finden. Doch für die großen Herausforderungen?

Mein Problem war recht einfach, doch die KI kam nicht drauf. Der SMTP & Port 587 war vom Server Provider gesperrt worden und wollte einfach ein paar Informationen über meine Software, um den Port freizugeben. Doch auf die simple Antwort den Anbieter zu fragen, darauf kam die KI nicht. 

![WhatsApp Image 2024-03-05 at 13.15.43.jpeg](https://api.tech-blog.info/uploads/in-post-images/09bdda38312b9a1b3593221e49f6425225368cf9.jpeg)

https://stackoverflow.com/questions/45336080/nodemailer-error-connection-timeout

Es war Stackoverflow, einfach mal lesen, was andere gemacht haben, wo schnell die Antwort kam: Manchmal muss der Anbieter den Port freischalten. Werden wir alle Junkies mit der KI? Was denkst du?

KI vs eigenständige kreative Lösung beim Problem mit dem SMTP & Port 587

KI vs eigenständige kreative Lösung


#### Oktober 2023:
 In Bens Kopf schwirrt eine Idee: Eine Software, die die Schichtplanung revolutioniert. Motiviert von dieser Vision trommelt er ein kleines Team zusammen: Stephan, ein talentierter App-Entwickler, sowie Spezialisten für Backend und DevOps. Ben selbst übernimmt die Rolle des Managers.

**Erste Herausforderungen:** Doch schon bald nach dem Start muss das Team Rückschläge verkraften. Die Backend- und DevOps-Spezialisten verlassen das Projekt, was eine große Lücke hinterlässt.

Ungebändigter Wille: Stephan aber lässt sich nicht entmutigen. Er erklärt sich bereit, die gesamte Programmierung selbst zu übernehmen. Mit Feuereifer stürzt er sich in die Welt von React.js, Node.js und JavaScript.


### Erste Erfolge:
 Im Dezember 2023 ist es soweit: Die erste Version der Software steht auf dem Server. Doch die Freude währt nur kurz. Gravierende Sicherheitsprobleme und unsauberer Code trüben den Erfolg.

KI-Unterstützung und neues Wissen: Mit Hilfe von ChatGPT und einem Kurs über Next.js und Node.js kämpft Stephan sich weiter voran. Er lernt, wie man professionelle Software entwickelt, die den Anforderungen der Praxis gerecht wird.

Neustart: Mit dem neuen Wissen im Gepäck wird das Projekt komplett neu aufgerollt. Die Software wird von Grund auf neu programmiert, parallel dazu schreitet die Gründung der Shiftly24 UG voran.

![mmexport1709375428899.jpg](https://api.tech-blog.info/uploads/in-post-images/3b77c8688daf00dc7103d3b24f2f70f29c2b951f.jpg)

Höhen und Tiefen: Die Reise ist geprägt von Höhen und Tiefen, von Rückschlägen und Lernmomenten. Doch Stephan und sein Team geben nicht auf. Sie glauben fest an ihre Vision und entwickeln eine Software, die die Schichtplanung revolutionieren wird.


### Shiftly24 heute:
 Die Shiftly24 UG ist ein junges, dynamisches Unternehmen mit einem klaren Ziel: Die beste Software für Schichtplanung auf dem Markt zu entwickeln. Mit innovativer Technologie und unbändigem Willen ist Shiftly24 auf dem besten Weg, diese Vision zu verwirklichen.

Schlagworte: #Shiftplanung #Software #StartUp #Gründung #Vision #Teamwork #KI #Innovation #Erfolg

Von der zündenden Idee zur fertigen Software: Der Weg von Shiftly24

Artikel