pr0gg3r

Firebase Cloud Massaging ist was du suchst. 

Da mit der Zeit immer mehr funktionale Elemente in C# eingeflossen sind, habe ich mich interessehalber mit Erlang, Haskell und F# beschäftigt. Das "dümpelte" so ein Jahr vor sich hin. Als ich die Möglichkeit bekam, in einem Elixir Projekt mitzuarbeiten, habe ich dann aus Neugier zugeschlagen. Mit meinen Vorkenntnissen habe ich ca. eine Woche benötigt, bis ich meine ersten produktiven Commit erstellt habe. Am Anfang sicherlich nichts Weltbewegendes, aber man kann mit Elixir relativ schnell Fahrt aufnehmen.
In Erlang/Elixir ist die funktionale Programmierung ein Mittel zum Zweck. Wichtiger ist es den Supervision Tree zu verstehen; zu verstehen, wie Prozesse miteinander interagieren. Es gibt hilfreiche Abstraktionen wie den GenServer und den Supervisor, der die Kommunikation zwischen den Prozessen ein wenig "normiert".

Ein guter Einstieg ist das Phoenix Framework, welches die Möglichkeiten der Sprache  ziemlich ausnutzt. Man muss am Anfang nicht alles verstehen. Die Dokumentation ist vorbildlich, und man kann aus fast allen Punkten direkt in den Code springen.

Erst einmal hat Git mit der IDE nichts zu tun. Viele IDEs beinhalten zwar auch einen Git-Client, aber du kannst das auch per Kommandozeile nutzen, was ich erst einmal empfehlen würde, damit du verstehst wie das ganze funktioniert. Wenn du auf einen Button in einem Git-Client klickst, weißt du quasi nicht, was da im Hintergrund tatsächlich passiert. 
Einfach gesagt funktioniert es so, dass du Änderungen am Code erst commitest (git commit), dann sind deine Änderungen im lokalen Branch eingereicht. Damit die auch auf den Git-Server gelangen, pusht du die lokalen Commits auf den Server hoch (git push). Wenn du dich nun an einen anderen Rechner setzt, kann du die Änderungen herunterladen (git pull) und weiter dran arbeiten.
Zu Empfehlen ist auch immer eine "Git Strategie". Davon gibt es mehrere, häufig verwendet man sogenannte Feature-Branches. Das heißt, jedes Feature (oder Bugfix) bekommt einen eigenen Branch, den du auch auf den Server pushen kannst. Nun gibt es mehrere Branches die du zusammenfügen (mergen) kannst, zum Beispiel Feature/X in den Masterbranch mergen. Meist schützt man den Masterbranch auch, so dass niemand ohne Review in den Masterbranch mergen kann. Wenn es Konflikte zwischen den Branches gibt (z.B. eine Datei wurde in zwei Branches verändert), müssen die Konflikte erst aufgelöst werden.
Nicht ganz. Durch einen gemeinsamen Ordner hast du zwar die Dateien auf mehrere Rechner verteilt, aber du hast eben keine Versionsverwaltung, weil es logischerweise nur eine Version gibt. Der Vorteil an Git liegt eben darin, dass du viele Branches hast und dadurch jeder Entwickler unabhängig von den anderen in seinem Branch entwickeln kann, also ohne sich gegenseitig zu beeinträchtigen.
Meiner Meinung gehören Git-Grundlagen zu den Grundlagen, die jeder Entwickler heutzutage beherrschen sollte. Ich selber verwende es inzwischen auch für private Projekte, auch wenn ich da alleine entwickle.
/Edit: Eine "richtige" Versionsverwaltung hast du eigentlich erst, wenn du Continuous Integration (CI) betreibst. Hier wird nach dem Mergen in Master (oder bei getaggten Commits) die Software auf einem Server komplett zusammengebaut und erhält dadurch natürlich auch eine neue Version. Wenn man das auf die Palme bringt, kann man Software so gleichzeitig auch verteilen (Continuous Delivery, CD), zum Beispiel auf einem Server deployen oder in einen Appstore ausliefern.

Erst einmal hat Git mit der IDE nichts zu tun. Viele IDEs beinhalten zwar auch einen Git-Client, aber du kannst das auch per Kommandozeile nutzen, was ich erst einmal empfehlen würde, damit du verstehst wie das ganze funktioniert. Wenn du auf einen Button in einem Git-Client klickst, weißt du quasi nicht, was da im Hintergrund tatsächlich passiert. 
Einfach gesagt funktioniert es so, dass du Änderungen am Code erst commitest (git commit), dann sind deine Änderungen im lokalen Branch eingereicht. Damit die auch auf den Git-Server gelangen, pusht du die lokalen Commits auf den Server hoch (git push). Wenn du dich nun an einen anderen Rechner setzt, kann du die Änderungen herunterladen (git pull) und weiter dran arbeiten.
Zu Empfehlen ist auch immer eine "Git Strategie". Davon gibt es mehrere, häufig verwendet man sogenannte Feature-Branches. Das heißt, jedes Feature (oder Bugfix) bekommt einen eigenen Branch, den du auch auf den Server pushen kannst. Nun gibt es mehrere Branches die du zusammenfügen (mergen) kannst, zum Beispiel Feature/X in den Masterbranch mergen. Meist schützt man den Masterbranch auch, so dass niemand ohne Review in den Masterbranch mergen kann. Wenn es Konflikte zwischen den Branches gibt (z.B. eine Datei wurde in zwei Branches verändert), müssen die Konflikte erst aufgelöst werden.
Nicht ganz. Durch einen gemeinsamen Ordner hast du zwar die Dateien auf mehrere Rechner verteilt, aber du hast eben keine Versionsverwaltung, weil es logischerweise nur eine Version gibt. Der Vorteil an Git liegt eben darin, dass du viele Branches hast und dadurch jeder Entwickler unabhängig von den anderen in seinem Branch entwickeln kann, also ohne sich gegenseitig zu beeinträchtigen.
Meiner Meinung gehören Git-Grundlagen zu den Grundlagen, die jeder Entwickler heutzutage beherrschen sollte. Ich selber verwende es inzwischen auch für private Projekte, auch wenn ich da alleine entwickle.
/Edit: Eine "richtige" Versionsverwaltung hast du eigentlich erst, wenn du Continuous Integration (CI) betreibst. Hier wird nach dem Mergen in Master (oder bei getaggten Commits) die Software auf einem Server komplett zusammengebaut und erhält dadurch natürlich auch eine neue Version. Wenn man das auf die Palme bringt, kann man Software so gleichzeitig auch verteilen (Continuous Delivery, CD), zum Beispiel auf einem Server deployen oder in einen Appstore ausliefern.

Es wird immer die Präsens verwendet.
Auch Präsens: "Zur Pflege der neuen Daten wird ein [...] Programm erstellt."
Kein "ist worden" / "folgte" / "wurde", sondern Präsens:
Im Anschluss wird... / Anschließend wird... / Folgend wird... Darauf folgt... Nach XYZ wird... Es wird... Es folgt... ...  

Mein Rat: belass es dabei, dass du die Prüfung bestanden hast. Warum? Bei mir was es ähnlich, die schriftlichen Prüfungen super, mündliche Prüfung versemmelt, warum auch immer (habe verkürzt, Prüfer waren mürrisch warum man überhaupt verkürzen kann, das ist nur mehr Arbeit für sie blabla. Es haben alle, die verkürzt haben, ne schlechte Note bekommen). Aber seis drum: interessiert jetzt auch keinen mehr.
Hier im Forum beschweren sich immer wieder welche über die mündl. Prüfung und wollen Einspruch erheben / vor Gericht gehen / was auch immer. Ich denke mal, das Einzige was passieren könnte wäre die Prüfung ein halbes Jahr später zu wiederholen, ggf. mit den gleichen Prüfern. Na dann viel Spaß! Bietet eher mehr Nachteile als Vorteile. 

Das von @Tiangou genannte Beispiel ist genau das, was ich meine:
Der Junior geht bis 40k, der Senior bis ca. 60k, mit Verantwortung on top vielleicht 70k oder 80k. Der Junior kann höchstwahrscheinlich Dienst nach Vorschrift machen, sich auf seine Programmierung konzentrieren und Fehler seien im verziehen. Er muss nicht halb so viele Weiterbildungen machen, kaum bis keine Freizeit investieren und hat zudem deutlich weniger Stress, weniger Kundenkontakt und keinerlei Verantwortung.

Und für all das, was der Senior oder gar Projektleiter mehr leisten muss, bekommt dieser dann 50% mehr? 100% mehr leisten für 50% mehr Brutto? Ja, es bestätigt mich: Ein grottiger Deal!
Noch grottiger wird er, wenn man sich diesen im Nettobetrag anschaut:
Netto bei 40k = ~25k
Netto bei 60k = ~35k (+ ~40%)
Netto bei 80k = ~45k (+ ~80%)
Genau das ist das eklatante Probleme mit Seniorstellen hierzulande. Ich kann mir nicht vorstellen, dass dies in den USA oder der Schweiz z.B. ähnlich gehandhabt wird. Und dann wundert man sich, dass die Eliten der Welt nicht zu uns nach Deutschland kommen.

Lustigerweise kann ich das mit meinen Erfahrungen bestätigen. Ich bin zwar kein vollkommener Tölpel in der Programmierung, aber es gab gewiss einige in meiner Berufsschulklasse, die es besser konnten als ich. Der eine hat schon über 20 Jahre programmiert (kam aus dem Ausland) und konnte echt wunderhafte Dinge mit seiner Programmierung anstellen. In der Abschlussprüfung hat er aber nur insgesamt mit einer 3 abgeschlossen, in der Projektarbeit sogar mit einer 4 - er hat sich viel zu sehr nur aufs Programmieren konzentriert und auch seine Dokumentation nur darauf ausgerichtet. Das soll natürlich nicht heißen, dass jeder der gut programmieren kann, den Rest nicht so drauf hat, sondern, wie @D-eath schon gesagt hat, die Ausbildung nicht nur um das Coden geht.

Am besten verwendet man das MVC-Pattern. Entweder selber schreiben, wobei man hier umfassende Kenntnisse in der objektorientierten Programmierung benötigt oder eben ein vorhandenes Framework wie Z.B. Laravel (gerade sehr "in"), Codeigniter oder CakePHP verwendet, wobei man auch hier OOP-Kenntnisse vorausgesetzt werden. 

Guten Morgen zusammen,
mein Beitrag ist zwar schon etwas länger her, aber ich möchte nun doch ein kurzes Feedback geben, wie sich die Sache bei mir weiterentwickelt hat. Auch weil ich diese Diskussion hier sehr hilfreich fand um mir ein wenig klar zu werden, was ich mir überhaupt für meine Zukunft vorstelle.
Ich werde Anfang nächsten Jahres eine neue Stelle als Product Owner bei einem IT-Beratungsunternehmen antreten. Das heißt, ich werde in Kundenprojekten dafür zuständig sein, Anforderungen zu analysieren, die Software zu konzeptionieren, Sprints zu planen und kommunikativ zwischen Stakeholder und Entwicklungsteam zu vermitteln. Eine ziemlich anspruchsvolle Aufgabe, auf die ich mich wirklich sehr freue.
Es handelt sich um eine mittelständische Beratung mit regionalen Kunden und die Reisezeiten sind wohl recht unproblematisch. Rahmenbedingungen sind gut, mein neuer Vorgesetzter sehr sympathisch, das Team kenne ich noch nicht, habe aber insgesamt ein gutes Gefühl.
Ich bin sehr gespannt, was da auf mich zukommt, glaube aber, hier eine Position gefunden zu haben, in der ich meine Kompetenzen gut einbringen kann und die viel Abwechslung bietet.
Ich berichte gern noch einmal, wenn ich ein paar Monate in dem neuen Job gearbeitet habe.
Einen lieben Gruß,
MacBeth1337

Da ich seit Jahren sehr viel im Webbereich tätig bin, kann ich dir sagen was gesucht wird und wo Bedarf besteht.
Ja, es gibt genug Bedarf im Webbereich. Jedoch muss man differenzieren. Machst du eher Design? Du bist jedoch kein gelernter Designer (und man sieht den Unterschied zwischen amateurhaften um professionellen Design). Du schreibst, dass du Erfahrungen mit HTML und CSS hast. Es wird jedoch schwer, dass jemand ein fertiges Design hat, das du anschließend umsetzen sollst. Es sei denn, du entwickelst mit einem Designer zusammen. Dann geht es weiter: Webseiten werden dynamisch gemacht, also zumindest solltest du noch Erfahrung darin haben, z.B. in PHP o.ä. oder zumindest in einem CMS wie Wordpress, Drupal, etc. oder einem Framework wie CakePHP, Codeigniter, Django oder sogar JavaEE und Springboot. Ein weiterer Trend geht in Richtung Angular und React ggf. auch Vue.js. Auch NodeJS-Backend (schau dir mal den MEAN-Stack an). Dann brauchst du wiederum Knowhow Datenbanken, Serveranwendungen usw. Und da hört wohl "der Spaß" ohne IT-Ausbildung für dich irgendwo auf, denn sich das alles selber beizubringen bedeutet jahrelangen Aufwand. Es geht auch nicht nur darum, die Grundlagen zu beherrschen. Wenn du bezahlt werden möchtest, brauchst du tiefgehende Kenntnisse. Niemand bezahlt dich für schlechte Codequalität, für die du länger brauchst, als ein Profi der schneller besseren Code schreibt. Ich möchte dir nicht zu nahe treten: es ist möglich. Aber es ist viel Arbeit und du solltest zumindest in einem Bereich Profi sein. Jedoch reicht dafür HTML und CSS nicht aus.
Man sollte auch nicht vergessen: trotz dass extremer Bedarf an IT-Fachkräften besteht, ist die Zeit für Quereinsteiger nicht mehr so gut wie noch vor 10 Jahren. Das heißt, eine Ausbildung oder ein Studium sind kein verkehrter Weg.

Da ich seit Jahren sehr viel im Webbereich tätig bin, kann ich dir sagen was gesucht wird und wo Bedarf besteht.
Ja, es gibt genug Bedarf im Webbereich. Jedoch muss man differenzieren. Machst du eher Design? Du bist jedoch kein gelernter Designer (und man sieht den Unterschied zwischen amateurhaften um professionellen Design). Du schreibst, dass du Erfahrungen mit HTML und CSS hast. Es wird jedoch schwer, dass jemand ein fertiges Design hat, das du anschließend umsetzen sollst. Es sei denn, du entwickelst mit einem Designer zusammen. Dann geht es weiter: Webseiten werden dynamisch gemacht, also zumindest solltest du noch Erfahrung darin haben, z.B. in PHP o.ä. oder zumindest in einem CMS wie Wordpress, Drupal, etc. oder einem Framework wie CakePHP, Codeigniter, Django oder sogar JavaEE und Springboot. Ein weiterer Trend geht in Richtung Angular und React ggf. auch Vue.js. Auch NodeJS-Backend (schau dir mal den MEAN-Stack an). Dann brauchst du wiederum Knowhow Datenbanken, Serveranwendungen usw. Und da hört wohl "der Spaß" ohne IT-Ausbildung für dich irgendwo auf, denn sich das alles selber beizubringen bedeutet jahrelangen Aufwand. Es geht auch nicht nur darum, die Grundlagen zu beherrschen. Wenn du bezahlt werden möchtest, brauchst du tiefgehende Kenntnisse. Niemand bezahlt dich für schlechte Codequalität, für die du länger brauchst, als ein Profi der schneller besseren Code schreibt. Ich möchte dir nicht zu nahe treten: es ist möglich. Aber es ist viel Arbeit und du solltest zumindest in einem Bereich Profi sein. Jedoch reicht dafür HTML und CSS nicht aus.
Man sollte auch nicht vergessen: trotz dass extremer Bedarf an IT-Fachkräften besteht, ist die Zeit für Quereinsteiger nicht mehr so gut wie noch vor 10 Jahren. Das heißt, eine Ausbildung oder ein Studium sind kein verkehrter Weg.

Erst einmal, ist eine Ausbildungsvergütung kein Gehalt, es soll also nicht allen möglichen Luxus erlauben sondern eine Art Gegenleistung zusätzlich(!) zu der Ausbildung sein, wobei manche ja nicht mal mehr dankbar sind eine Ausbildung zu erhalten. 
Zweitens sind Ausbildungsjahre keine Herrenjahre, eine fundierte Ausbildung sollte im Vordergrund stehen und nicht die Vergütung. Sprich: Wenn ein Betrieb super ausbildet, die Vergütung aber nicht allzu hoch ist, ist das dennoch mehr wert, als wenn die Vergütung hoch ist aber sich nicht um den Azubi gekümmert wird.
Drittens halte ich es für eine ganz schlechte Idee, seinen Ausbildungsbetrieb zu verklagen. Alleine die Idee "ich will die Stelle um die dann zu verklagen" halte ich für ziemlich abartig.
Viertens ist es keine Ausbeutung, sondern ein Geben und Nehmen im gegenseitigen Einverständnis: Ausbildung und Vergütung gegen Arbeitskraft.
Fünftens halte ich 450€/500€/550€ nicht für allzu wenig Vergütung. Bei mir in der Berufsschule gab es sicher welche mit 300€ und in anderen Ausbildungsberufen gibts deutlich weniger, in anderen deutlich mehr. Es handelt sich bei den mehr oder weniger offiziellen Angaben auch immer um Durchschnittswerte, es heißt also nicht, dass jeder die sechs- oder siebenhunderteuroirgendwas bekommt.
Sechstens ist eine Ausbildungsvergütung auch verhandlungssache. Wenn der Betrieb einen unbedingt haben möchte, kann man sicher auch ein wenig mehr verlangen. Ansonsten hat man halt Pech und er nimmt jemand anderen. Aber ich würde da auch nicht meine Ausbildung aufs Spiel setzen, denn dann steht man ganz schnell ohne Ausbildung dar.
Siebtens: Sorgen um viel oder wenig Gehalt kann man sich auch erst nach der Ausbildung machen. In der Ausbildung ist man aber nicht bei "Wünsch dir was".

Ich kann sehr gut nachvollziehen, wie es dir geht. Ich habe eine ähnliche Entwicklung hinter mir und bin immer mehr dabei, mich von der reinen Softwareentwicklung hin zu Produkt-, Innovation- und Projektmanagement zu bewegen.
Du hast ja auch konkrete Ideen, was du dir für die Zukunft vorstellen kannst. Gleichzeitig hast du eine Arbeitsstelle. Ich würde an deiner Stelle einfach mal bei deinem Vorgesetzten ein Gespräch suchen und einfach ehrlich und direkt deine Situation schildern. Dir gefällt ja die Firma und vermutlich werden sie dir deinen Wünschen entgegen kommen können und dir Möglichkeiten bieten, deinen Zielen näher zu kommen.
Ansonsten, gerade wenn du in Richtung Management möchtest, wäre ja auch ein Master (z.B. MBA) eine Option.
Ich finde es sehr gut, wenn jemand seine Stärken und Schwächen erkennt. Dadurch wirst du sicher etwas finden, das zu deinen Stärken und Interessen passt.

Als Webentwickler würde es am meisten Sinn machen, wenn du eine Webseite abrufbar hast. Zusätzlich den Quellcode auf einem Git-Repo. Dann kannst du ja alles zeigen. 

Echt jetzt?

@monolith das ist ja genau das, was ich meine und ich mach mir da auch sicher keinen Stress. Aber viele Stellenausschreibungen werfen nur so mit Buzzwords und "state of the art"-Themen um sich und vermitteln da einen Stellenwert, der für diese Thematiken total unangebracht ist. Da wollen Firmen dann Leute, die Ahnung von Scrum haben, aber wenn man sie fragt, wie sie das bei sich handhaben, kommt dann raus, dass Product Owner und Scrum Master eine Person sind und das "Entwicklerteam" aus zwei Personen besteht o.ä..

Ich würde dazu raten, von jedem Aufgabentyp eine, maximal zwei Aufgaben zu wählen und zu üben. Es bringt nichts, z.B. zum NATting 10 Aufgaben zu machen. Man muss es verstehen und das kriegt man mit ein bis zwei Aufgaben hin. Dasselbe gilt für UML. Man kann ein oder zwei Aufgaben machen und lernt dabei das meiste. Wenn man dann noch 10 weitere Aufgaben macht, hat man keine Lerneffekte mehr.
Also würde ich nicht empfehlen, alle Prüfungen ab 20xx zu lernen, sondern Aufgabentypen zu sammeln. Und dabei nicht unbedingt die leichtesten Aufgaben, sonst ist man nicht tief genug in der Materie drin bzw. hat zu viel Lücke (man denkt: "ist doch easy" und dann kommt eine Aufgabe dran, die noch mehr Wissen erfordert).
Wichtig ist, dass man ein Verständnis für die Themen entwickelt. Wenn man z.B. SQL versteht, dann kann man jede Aufgabe lösen. Wenn man 10 oder 100 SQL-Aufgaben auswendig lernt, hat man an der Prüfung ein Problem, da dort die 101 dran kommt.
Noch etwas: viel hilft nicht immer viel. Es kommt darauf an, dass man effektiv lernt. Natürlich kann man alle Prüfungen durcharbeiten, dann hat man bei der dritten aber bereits das aus der ersten vergessen. Deshalb ist es besser, heute z.B. SQL-Aufgaben zu machen und sich lieber dafür Zeit zu nehmen. Und morgen wird dann SQL wiederholt und zusätzlich Routing dran genommen. Und am dritten Tag dann Routing wiederholen, die SQL-Aufgaben bei denen man sich schwer tat und ein neues Thema. So wird man immer fitter mit allen Themen und auch die Verknüpfungen im Gehirn bilden sich erst durch Wiederholungen. Irgendwann kannst du jede x-beliebige Prüfung durchblättern und die Aufgaben durchlesen und weißt bei jeder Aufgabe: "ah, so muss ich das machen, hier ein Join, da ein ein Group By"). Und so sollte es auch an der Prüfung sein: Aufgabe lesen, verstehen, lösen. Wenn du dann auf diesem Level bist, kann sie nur super gut werden! Viel Erfolg  

Wie wäre es denn, wenn du dich dort bewirbst und im Bewerbungsgespräch nach dem Gehalt fragst? Bzw. du wirst dabei wahrscheinlich selbst nach deinen Gehaltsvorstellungen gefragt. Du kannst die Gehaltsvorstellungen auch bei der Bewerbung angeben (falls gefordert).
Das ist jetzt nicht der einfache Weg, aber woher sollen wir denn wissen, welches Gehalt welche Firmen in welcher Position zahlen?
50k sind als Fisi realistisch, kommt aber auch immer drauf an in welchem Bereich, in welcher Stadt, bei nem großen oder kleinen Unternehmen. Am besten schaust du, dass du dich auf etwas spezialisieren und fortbilden kannst. Dann sollten die 50k eigentlich drin sein (vielleicht nicht sofort, aber du kommst diesen einen Schritt näher). 

Die Schwierigkeit bei Android ist nicht die Sprache, sondern die Architektur. Wenn ihr für Android in C# programmiert, dann nehme ich an, dass ihr Xamarin verwendet. Auch hierbei musst du dich an die Androidarchitekur einarbeiten und ein Wechsel zu Java (oder besser noch: Kotlin) wird dann einfach sein. Also lass dich am besten einfach mal überraschen, das wird alles gar nicht so schlimm, wie du es dir im Moment vorstellst. 

Richtig strenge Unternehmen wie Du sie beschreibst, kenne ich bis dato nicht. Selbst in den großen und anspruchsvollen Unternehmen, mit denen ich zu tun hatte, sind private Plaudereien und Surfereien Alltag. Warum auch nicht? Wer glaubt, dass man einen geistig anspruchsvollen Job wie die IT acht Stunden am Tag ausüben kann, der belügt sich selbst. Wenn ein Entwickler oder Admin am Tag effektiv fünf bis sechs Stunden arbeitet, kommt das einer Vollauslastung gleich. Von daher finde ich das etwas strange, was Du beschreibst. So kenne ich die IT jedenfalls nicht.
Dazu muss ich allerdings sagen, dass zu lockere Unternehmen auch nix sind. Das sind häufig diejenigen, welche technologisch den Anschluss verlieren, etwaige Trends und Entwicklungen verpennen und dementsprechend auch Du als Mitarbeiter auf Dauer nicht konkurrenzfähig bleibst. Das mag OK sein, solange Du vor Ort bleibst. Willst oder musst Du aber wechseln, kommt Dich das teuer zu stehen, weil Du dann mit anderen Bewerben kaum mithalten kannst. Deswegen sind Unternehmen, welche das Ganze zu locker angehen lassen auch nichts. Nicht in der IT, welche sich alle 5-10 Jahre drastisch wandelt. Da muss man am Ball bleiben.
Deswegen finde ich Deinen Plan genau richtig. Mache das Ganze 1 - 2 Jahre und suche Dir anschließend etwas passendes. Solange kannst Du einiges an Erfahrung mitnehmen. Derart straff organisierte Unternehmen sind tolle Schulen, bei denen Du Dinge lernst, welche Du woanders gar nicht oder nur in der vielfachen Zeit lernen würdest. Das ist für Dich, als Fachkraft, und Deinen Marktwert sehr wertvoll.

Warum? Ich bin per se kein Freund von Hire&Fire, aber an Leuten festzuhalten die ungeeignet sind, ist wirklich für beide Parteien eine unnötig grosse Belastung. Schon ein Blick auf Maslow zeigt, dass "Anerkennung und Wertschätzung (Erfolg)" noch vor "Selbstverwirklichung" kommt. Und wenn jemand ungeeignet ist, dann kannst du ihn nicht ehrlich für seine Arbeit anerkennen und wertschätzen und das merken die MA und fühlen sich jeden Tag unwohl und wird sich auf die Gesundheit auswirken.
Ergo, wenn es objektiv der falsche Job für die Person ist, dann ist es falsch so einen richtigen Schritt zu vermeiden.
(P.S.: Ja, ich weiss, dass das deutsche Arbeitsrecht leider andere Massstäbe setzt und es sehr mühsam ist bei Kündigungen - aber das ist eher eine juristische Umsetzungsfrage. Und oftmals hilft ja auch schon ein ehrliches Gespräch mit dem MA.)

Das sieht doch schonmal besser aus, als du vermutlich denkst 😊
Was mir auf die Schnelle aufgefallen ist (habe zwar länger kein PHP mehr gemacht, aber sollte nichts ausmachen):
Du arbeitest mit Klassen, das ist schonmal sehr gut! Wieso sind die dann im Verzeichnis "Interfaces"? Klassen und Interfaces sind ein Unterschied Du könntest einen Autoloader verwenden, damit fallen dann deine ganzen Includes weg Deine Methodennamen haben am Anfang einen Großbuchstaben. Ein ungeschriebenes Gesetzt ist, dass man nur Klassennamen groß schreibt und Methodennamen klein, damit es übersichtlicher ist Die kommentierst zu viel. Beim __constructor() muss z.B. nicht dran stehen, dass es der Constructor ist oder beim Logout, dass es der Logout ist. Meistens macht man es so, dass man nur die Stellen kommentiert, deren Sinn sich nicht erschließt, wenn etwas z.B. bewusst anders programmiert wurde, als man es eig. machen würde. Was der Code an sich macht, sollte man von ihm ablesen können, dabei helfen gut benannte Variablennamen. Du kannst dir auch mal Javadoc anschauen, für PHP gibt es sicher was ähnliches. Für die Datenbankgeschichten benutzt du zwar mysqli, aber du könntest das noch besser machen, indem du ORM verwendest Du trennst nicht Logik von Design. Du hast im Verzeichnis "session" jede menge echos. Das möchte man eigentlich vermeiden indem man entweder eine Template-Engine verwendet oder gleich noch besser, eine MVC-Architektur. Deine Datenbank hast du in SQL-Queries definiert und zwar alles in einzelnen Dateien. Mach lieber eine Datei, das ist für andere dann besser für den Import. Außerdem fehlen da die Relationen zwischen den Datenbanken (Stichwörter: Foreign Key, Constraint) Du hast kein Logging implementiert Die UI ist jetzt nicht das schönste, was ich je gesehen habe, aber es geht ja gerade um PHP (ansonsten wären mir Themen wie Responsive usw. wichtig) Fazit:
Der Code ist weniger schlimm, als der von vielen PHP-Anfängern (inkl. mir damals!) und du scheinst zu wissen, was du machst. Ich denke sogar, damit kann man eine Junior-Stelle finden, denn das was mir z.B. aufgefallen ist, wirst du dann eh auf der Arbeit relativ schnell lernen. Ansonsten, versuche dich mit den Themen die ich oben geschrieben habe auseinander zu setzen, dann bist du auf einem ganz guten Weg. Weiterhin viel Erfolg!

Jau, der Code sieht bedeutend besser aus als erwartet.
Ich schreibe mal alles runter was mir so durch den Kopf geht, einiges davon ist nur meine Meinung, die Stellen sollte ich jetzt aber gekennzeichnet haben:
https://www.php-fig.org/psr/psr-2/ Das ist der Quasi-Standard wie man seinen PHP-Code formatieren sollte. https://getcomposer.org Ist der Quasi-Standard um fremde Libraries in dein Projekt einzubinden, gibt dir auch gleich einen PSR-Autoloader. Kannst du aber erst einmal hinten anstellen, es gibt wichtigeres mit dem du dich noch vorher auseinander setzen solltest. Wichtig: Du beendest deine PHP-Dateien mit "?>", das solltest du auf keinen Fall tun weil du dann ausversehen am Ende ein Whitespace oder ähnliches schreiben könntest. Das wäre dann aber eine Ausgabe und könnte zum "headers already sent"-Fehler führen Prepared Statements zu verwenden ist besser als Werte zu Escapen (+ https://php-de.github.io/jumpto/sql-injection/)  Destruktoren brauchst du nur sehr sehr selten. So Dinge wie Variablen unsetten oder die Verbindung zur Datenbank trennen musst du nicht explizit tun, die Variablen räumt der Garbage Collector (brauchst du dir nicht merken) alleine weg sobald sie in dem jeweiligen Scope nicht mehr gebraucht werden und die Verbindung zur Datenbank wird am Ende des Lifecycles für den Request ebenfalls automatisch getrennt. Teilweise baust du innerhalb des Konstruktors die Verbindung zur Datenbank auf, manchmal nutzt du "global" um auf eine bestehende Verbindung zuzugreifen. Beide Wege sind nicht gut Bau stattdessen die Verbindung zu Beginn der Verarbeitung auf und reiche diese Verbindung über den Konstruktor in die Objekte rein. [1] Manche Variablen sind ungünstig benannt, z.B. $this->m_oSqlCon m = mysql o = objekt schätze ich, regt zumindest zu sehr zum Nachdenken über den Namen an $this->dbConnection sagt das gleiche aus, ist aber einfacher zu lesen ist auch noch gültig wenn man von MySQL auf PostgreSQL wechselt Geschmackssache: Bei den Klassennamen finde ich das "C"-Präfix unnötig, Klassen sind ja eher der Standard, für mich macht es mehr Sinn die Sonderfälle wie Interfaces und Abstrakte Klassen zu kennzeichnen und auch dann nenne ich die eher z.B. "ValidatorInterface" als "IValidator" Anstatt "die('abc failed')" nutze Exceptions throw new Exception('abc failed'); Exceptions lassen sich an anderer Stelle wieder auffangen, dann kannst du dort auf diesen Fehler reagieren Falls du die Exception nicht fängst, bekommst du eine Aussagekräftigere Fehlermeldung inkl. Datei- und Zeilenangabe für den Fehler Wie schon angesprochen, für PHP gibt es auch solche Doc-Blöcke [2] Bei den IDEs PHPStorm und Netbeans werden die automatisch ergänzt wenn du über der Funktion "/**" tippst und Enter drückst Nicht nur, dient das der Dokumentation und Übersicht was was ist, was was macht und was was (:p) zurück gibt oder wirft ... Die IDEs wissen dann auch mit was für Klassen du da teilweise arbeitest und können Autocomplete-Vorschläge machen während du den Methoden-Aufruf tippst und dir Hinweise zu den erwarteten Parametern geben. Du arbeitest viel mit Konstanten (Top!) Wenn du die innerhalb von Klassen definierst, gibst du ihnen einen Kontext Innerhalb von der definierenden, oder erbenden, Klasse kannst du über "self::KONSTANTE" auf sie zugreifen, außerhalb der Klasse kannst du "Klassenname::KONSTANTE" nutzen. Dein Code könnte an manchen Stellen kürzer sein Nur zur Info: PDO ist besser als mysqli bedeutend komfortablere API unterstützt noch weitere Datenbanksysteme neben MySQL und MariaDB Verzeichnisnamen session -> Views gfx -> images interfaces -> classes (ist auch nicht ideal, machts aber erstmal verständlicher) In den Views musst du nicht jede Ausgabe per echo erledigen [3] Du kannst zwischendurch den PHP-Kontext verlassen um Ausgaben zu generieren Manche IDEs können das HTML nicht erkennen wenn es per echo ausgegeben wird, wenn du größere Blöcke HTML schreibst, ist das Highlighting aber praktisch Du kannst die Kurzform von echo nutz: "<?= $var ?>" [1]
[2]
[3]
 
 
 

Das sieht doch schonmal besser aus, als du vermutlich denkst 😊
Was mir auf die Schnelle aufgefallen ist (habe zwar länger kein PHP mehr gemacht, aber sollte nichts ausmachen):
Du arbeitest mit Klassen, das ist schonmal sehr gut! Wieso sind die dann im Verzeichnis "Interfaces"? Klassen und Interfaces sind ein Unterschied Du könntest einen Autoloader verwenden, damit fallen dann deine ganzen Includes weg Deine Methodennamen haben am Anfang einen Großbuchstaben. Ein ungeschriebenes Gesetzt ist, dass man nur Klassennamen groß schreibt und Methodennamen klein, damit es übersichtlicher ist Die kommentierst zu viel. Beim __constructor() muss z.B. nicht dran stehen, dass es der Constructor ist oder beim Logout, dass es der Logout ist. Meistens macht man es so, dass man nur die Stellen kommentiert, deren Sinn sich nicht erschließt, wenn etwas z.B. bewusst anders programmiert wurde, als man es eig. machen würde. Was der Code an sich macht, sollte man von ihm ablesen können, dabei helfen gut benannte Variablennamen. Du kannst dir auch mal Javadoc anschauen, für PHP gibt es sicher was ähnliches. Für die Datenbankgeschichten benutzt du zwar mysqli, aber du könntest das noch besser machen, indem du ORM verwendest Du trennst nicht Logik von Design. Du hast im Verzeichnis "session" jede menge echos. Das möchte man eigentlich vermeiden indem man entweder eine Template-Engine verwendet oder gleich noch besser, eine MVC-Architektur. Deine Datenbank hast du in SQL-Queries definiert und zwar alles in einzelnen Dateien. Mach lieber eine Datei, das ist für andere dann besser für den Import. Außerdem fehlen da die Relationen zwischen den Datenbanken (Stichwörter: Foreign Key, Constraint) Du hast kein Logging implementiert Die UI ist jetzt nicht das schönste, was ich je gesehen habe, aber es geht ja gerade um PHP (ansonsten wären mir Themen wie Responsive usw. wichtig) Fazit:
Der Code ist weniger schlimm, als der von vielen PHP-Anfängern (inkl. mir damals!) und du scheinst zu wissen, was du machst. Ich denke sogar, damit kann man eine Junior-Stelle finden, denn das was mir z.B. aufgefallen ist, wirst du dann eh auf der Arbeit relativ schnell lernen. Ansonsten, versuche dich mit den Themen die ich oben geschrieben habe auseinander zu setzen, dann bist du auf einem ganz guten Weg. Weiterhin viel Erfolg!