Funfare1337

Ich habe bisher Branche und Frameworks gewechselt, nur der Programmiersprache bin ich aktuell treu geblieben (PHP bzw Webentwicklung).
Gelernt habe ich im Energiebereich, dann zu einem kleinen laden mit eigenem CMS für Kommunen gewechselt, dann eine Druckerei und nun bei der Polizei.
Frameworks dann von Zend Framework 1, über selbstgebastelten Kram hin zu Inder-Code, das habe ich selbst zu Laravel transferiert und dem Framework bin ich beim letzten Wechsel treu geblieben.
Die konkrete Branche oder das Framework waren für mich nie so krass der Wechselgrund bzw Auswahlgrund einer Firma.
Branchenwissen kann man sich wieder aneignen. Und war für mich jetzt auch noch nicht so systemrelevant. Ich bin ja nicht der Verantwortliche für den fachlichen Kram. Dafür gibts Product Owner, Fachlichkeit oder wie man es auch immer nennen möchte. Die ganzen Fachbegriffe die eingesetzt werden lernt man irgendwann, auch wie das ganze System tickt. Andererseits war der Blick "von außen", als jemand der noch gar keine Ahnung von dem Thema hat, auch sehr hilfreich. Dann überdenkt man auch mal Sachen, die man schon lange so macht oder halt einfach so akzeptiert hat. Man ist die ersten Monate im normalfall eh nicht produktiv bzw halt gewinnbringend. Man muss das Team, die Technologie, das ganze System, die fachlichen Anforderungen und Begriffe etc lernen, das alles dauert seine Zeit. Und ich bin mir sicher, selbst wenn ich in der gleichen Branche nen anderen Job anfangen würde, müsste ich trotzdem fast alles neu Lernen. Keine Firma tickt genauso wie die andere, es gibt andere Prozesse, Anforderungen, Wünsche und evtl. sogar gleiche Begriffe mit unterschiedlicher Bedeutung, also lernen muss man so oder so.
Bei Frameworks bin ich auch entspannt. Der Wechsel ist nicht so gravierend, klar muss man lernen wie das neue Framework funktioniert. Aber im Kern sind die meisten doch recht ähnlich. Es sind andere Begriffe, manchmal etwas andere Konzepte, aber trotzdem doch ähnlich. Das gilt ja sogar für Programmiersprachen. Kann man Objektorientierung, also hat man verstanden was man da warum wie tut, kann man das auf so ziemliche jede Programmiersprache übertragen. Die Konzepte, Pattern etc. sind die gleichen, die sind abstrakter als die konkrete Programmiersprache. Man muss sich halt neue Syntax und Namen merken (mal mehr mal weniger, Wechsel von C# zu Java ist ähnlicher als C# zu Python, aber ich persönlich mag den Syntax von Python aber absolut nicht)
Was ich gelernt habe in den letzten Jahren, ist viel wichtiger das man ins Team und zu der Arbeitsweise des Teams passt. Ich will sowas wie Versionsverwaltung, Tests, CI/CD und Zeugs außenrum und nicht jeden kleinscheiß per Hand machen müssen. Auch brauche ich einen gewissen Grad an Freiheit, auch mal selbst eine Idee umzusetzen oder mal was auszuprobieren, dass auch fehlschlagen kann. Genauso könnte ich nicht strikt nach Wasserfall programmieren.
Wie gearbeitet wird, wie die Stellung bzw Wertschätzung abläuft und wie man sich selbst entwickeln kann, ist für mich viel wichtiger als welche Branche oder Framework. Lernen musste eh am Anfang wieder viel, da ist auch sowas kein Problem.

In etwa. Es kommt halt sehr auf den Betrieb an. Ab einem gewissen Umsatz lohnt sich sicherlich ein gewisses Level an Redundanz. Wenn 1000 Mitarbeiter einen Tag lang nicht arbeiten können, geht das schon sehr ins Geld. Andererseits kannst du auch als 10-Personen-Firma schon in Probleme kommen, wenn 2h das Internet ausfällt, jenachdem was man halt macht als Firma. Es gibt immer darum: Was ist an Ausfall / Wiederherstellungszeit verkraftbar und was ist man bereit zur Sicherung dazu auszugeben. 
 
Sinnvoll ist immer so ne gewagte Aussage. Es kommt halt darauf an wogegen man sich absichern möchte. Von der Konfiguration und Wartung ist aber ein Multi-WAN Router einfacher als mehrere Router. VPN-Verbindungen kannst du auch entsprechend konfigurieren. OpenVPN zum Beispiel unterstützt mehrere Server, ist einer nicht (mehr) verfügbar, wird auf den nächsten gewechselt. Also kann man da dann Haupt- und Backupverbindung angeben und die Verbindung wird wieder automatisch hergestellt.

Das wichtigste bei sowas ist immer: Gegen was willst du dich absichern? Wie viel Ausfallzeit wird tolieriert? Was darfs kosten.
Theoretisch kannst du jeden SPoF eleminieren, das wird aber ein riesen Aufwand, dafür dass es vllt mal einen Ausfall alle 2 Jahre gibt.

2. ISP als Backup zu haben ist der einfachste Weg, die meisten Router können auch Multi-WAN, also dass du mehrere Internetverbindungen anstecken kannst. Dann kannst du dort Balancing/Backup etc konfigurieren. Wenn die Leitungen zu den ISPs aber nebeneinander verlaufen, bringts dir auch nix wenn dann die Leitung angebaggert wird. Alternativ geht natürlich auch ein LTE-Backup. Es gibt auch Bonding, dabei wird auf mehreren Leitungen das gleiche Signal geschickt, damit eine Leitung auch ausfallen kann. Es gibt auch SameIP Lösungen, damit du auch beim Leitungswechsel öffentlich noch erreichbar bist (glaube über VPNs gelöst).
Jetzt gehts aber mit dem Router weiter. Du hast zwar zwei ISPs, aber wenn der Router ausfällt, steht trotzdem die Produktion. Also z.B. passendes, fertig konfiguriertes Ersatzgerät vorhalten, dann ist die Ausfallzeit sehr gering, oder ein HA-Cluster mit mehreren Routern bilden. Dann springt der BackupRouter sofort ein, wenn etwas ausfällt. Kostet allerdings wieder mehr Geld und Zeit.
Und so geht es weiter, Core-Switch, USV, Stromversorgung (bringt nix wenn alles auf einer Sicherung läuft etc)., das kannst du praktisch bis ins unendliche treiben.
Einfach mal zu sagen "wir brauchen Hochverfügbarkeit" ist leicht, aber es wird oft nicht bedacht was für Kosten und Aufwand dahinter steckt. Ihr solltet lieber erstmal klären, was an Ausfall verkraftbar ist und dann wie viel die entsprechende Umsetzung kostet.

Hi,
ich denke hier muss unterschieden werden in Grundlagenwissen und spezifisches Wissen, außerdem wie sehr sich der Bereich ändert.
Netzwerkgrundlagen, IPv4, IPv6 etc gibts seit Jahrzehnten und wird es auch noch Jahrzehnte geben, da sind die Grundlagen weiterhin wichtig. Je tiefer man aber in das Gebiet reingeht, desto schneller kann das Wissen aber altern und unbrauchbar werden. Unbrauchbar im Sinne für die tägliche Praxis und unter der Voraussetzung man bleibt nicht auf einem Stand stehen, sondern folgt der Technik. Wer möchte denn jetzt noch FastEthernet und Hubs betreiben, oder wer kommt ohne STP aus oder was weiß ich was es da noch alles gibt.
Ich komm eher aus der Programmierschiene, daher weiß ich es für den Bereich besser. Ich bin Webentwickler und programmiere mit PHP, als Framework nutze ich Laravel. Natürlich ändern sich die Design-Patterns nicht so schnell (Grundlagenwissen), aber z.B. bringt Laravel alle 12 Monate eine neue Major-Version raus. Dadurch wird das alte Wissen nicht sofort unnütz, aber man muss sich neue Sachen beibringen und kann altes vergessen, was jetzt eleganter und einfacher umgesetzt werden kann. Auch laufen PHP-Versionen aus, die man aus dem Kopf bekommen kann, dort sind ebenfalls neue Möglichkeiten die man lernen muss bzw. alte Sachen die entfernt wurden.
Pauschal kann man finde ich daher nicht sagen, wann welches Wissen unnötig wird oder alt ist, es gibt Bereiche die halten ewig und manche wandeln sich gefühlt wöchentlich.
Du hast gemeint PCs funktionieren noch so wie vor 50 Jahren, völlig korrekt, reicht um zu verstehen wie das funktioniert. Sollst du jetzt aber neue PCs kaufen, bringen dir die Hardwarespezifikationen von vor 50 Jahren absolut garnix. Du musst wissen was sind die Prozessoren / Mainboards / RAM-Riegel der letzten paar Jahre die eingesetzt werden können, oder wenn nicht Produktspezifisch wenigstens von den Anforderungen. Man baut ja jetzt schließlich keinen 25Mhz, 32MB RAM -Rechner mehr.
Server funktionieren auch noch so wie früher, aber früher wurde auch einfach die BareMetalMaschine betrachtet. Dann ging es mehr in die Virtualisierung, mittlerweile ist Cloud und Container ein riesen Thema. Das heißt nicht, dass man alles alte sofort vergessen muss, aber man muss sich auch mit den neuen Themen beschäftigen um zu wissen wie man sich selbst und seine Firma verbessern kann.

Das ist so nicht korrekt. Du musst hier im letzten Schritt von der tatsächlich verbrauchten Leistung ausgehen, nicht von der Maximalleistung vom Netzteil. Also PC verbraucht 220W, Wirkungsgrad ist 95,5% -> tatsächlicher Verbrauch liegt dann definitiv unter 334 Watt

Ja und Nein. Dies gilt jetzt erstmal nur für das Netzwerk in einem Unternehmen: Für alle Mitarbeiter / Beschäftigten wird eine UserCAL benötigt, alternativ für jedes Gerät welches auf einen Windows Server zugreift. Dabei ist auch dein Fall 1 und Fall 2 identisch, denn alle greifen direkt oder indirekt auf einen MS-Server zu (MS SQL, AD). Dabei ist es einfach egal ob das über einen Apache geht oder nicht, weil auch die indirekten Zugriffe zählen.
Für öffentliche Websites sieht das allerdings etwas anders aus, für dieses Szenario gibt es die Excternal Connector License. Die ist dafür da, Zugriffe zu Lizensieren die nicht von Mitarbeitern des Unternehmens stammen. Damit sind dann alle Zugriffe von Extern auf einen Server abgedeckt.
 
Edit: Windows Server brauchen für den Zugriff untereinander übrigens keine CAL, die dürfen fröhlich miteinander Kommunizieren, bei MS geht es expliziert nur um Divices (Alles außer Windows Server) und/oder User (=Mensch, dabei ist es egal ob 5 Personen einen AD-Account haben oder 5 Personen 30 Accounts fröhlich wechseln, oder gar kein AD besteht)
 
 

Ich nutze diese hier https://github.com/lcobucci/jwt
Auf jwt.io findest du auch eine Übersicht über alle möglichen JTW-Libs, diese unterstützt aber fast alles von den JWT funktionen.
Notifications, also zumindest One-Way, sind ja auch kein Problem mit Laravel. Passport oder Sanctum brauchst du dafür nicht wirklich, ich habe das irgendwann mal einfach mit einem eigenen Auth Provider gelöst, der das JWT ausgelesen und entsprechend den User eingeloggt hat.
Du kannst dich auch noch weiter umschauen nach anderen Sprachen/Framework, aber von den Anforderungen her kommt so ziemlich alles in Frage. Daher mein Rat, nutz das womit du dich auskennst. Sonst machst du nur in anderen Bereichen die typischen Anfängerfehler die dir später auf die Füße fallen werden.

Auch im öffentlichen Dienst gibt es wirtschaftliche Gesichtspunkte.
Wenn ein Projekt täglich 1h Arbeitszeit einspart weil etwas automatisiert wurde, rentiert sich ein Projekt nach 35 Arbeitstagen und sorgt auch dafür, dass Geld (im Sinne von Personalkosten) gespart wird (mal ganz einfach gerechnet, aber da gibts ja auch noch andere Kosten/Nutzen). Genauso kann es ja mit Lizensierung, Strom, Platz etc. aussehen.

Brille habe ich auch. Sehtest ging auch nur darum, dass ich alles auf einem Bildschirm entsprechend lesen kann. BMI ist nicht vorgegeben, solang der aber <40 ist sollte das auch nicht so ne große Rolle spielen.
Wie gesagt, die Voraussetzung ist, dass du wahrscheinlich bis zur Pension arbeiten kannst. Wenn du nicht gerade jetzt schon 10 Risikofaktoren / schwere Vorerkrankungen  hast, sollte das nicht so das Problem werden.

Brille habe ich auch. Sehtest ging auch nur darum, dass ich alles auf einem Bildschirm entsprechend lesen kann. BMI ist nicht vorgegeben, solang der aber <40 ist sollte das auch nicht so ne große Rolle spielen.
Wie gesagt, die Voraussetzung ist, dass du wahrscheinlich bis zur Pension arbeiten kannst. Wenn du nicht gerade jetzt schon 10 Risikofaktoren / schwere Vorerkrankungen  hast, sollte das nicht so das Problem werden.

Auch mit Asthma sollte bei dir nicht so viel dagegen sprechen. Nachdem du kein Polizeivollzugsbeamter wirst sondern Verwaltungsbeamter sind die medizinischen Voraussetzungen wesentlich geringer.
Bei mir steht aktuell auch die Verbeamtung an (Polizei Bayern). Daher kann ich zumindest sagen wie es bei mir lief.
Ich musste zum polizeiärztlichen Dienst, dort waren das dann allgemeine Untersuchen (Sehtest, Hörtest, allgmeine körperliche Untersuchung, Bluttest, EKG).
Der Arzt muss dann eine Einschätzung abgeben, nur wenn es da sehr wahrscheinlich ist, dass du vor Eintritt des Pensionsalters dienstunfähig werden wirst, bist du nicht geeignnet. Das sollte nur mit Asthma ja eigentlich kein Thema sein. Auch damit solltest du ja bis 67 arbeiten können. Final kann das aber nur der Arzt sagen.
 
Zumindest in Bayern sind all diese Stellen mit einer Verbeamtung verbunden. Ich glaube nicht, dass man das anders lösen kann. Stellen sind beim Staat eh schon eine schwierige und nervige Sache, da kannste kaum was schieben. Aber versuch wenn möglich die Verbeamtung zu nutzen. Hat große Vorteile, aber zur not kommst du da auch einfach wieder raus.

Füge beim Aufbau der DB-Verbindung mal folgende Zeile ein (variablennamen natürlich noch anpassen), dann solltest du eine Fehlermeldung bekommen wenn etwas schief läuft:
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);  

zwischen $_POST['ansprechpartner'] und $kdnr fehlt ein komma, deshalb der syntax error
außerdem verwechsle nicht das mysqli bindParam mit dem PDO bindparam: https://www.php.net/manual/de/pdostatement.bindparam.php

Die länge brauchst du im normalfall nicht, der Parameter ist optional
Der Typ ist auch optional und per default string, da würde ich aber empfehlen abweichende Typen entsprechend zu berücksichtigen. Ansonsten ja, so musst du jeden Parameter übergeben. Da auch gleich der Tipp, statt Fragezeichen kannst du auch named Parameter verwenden. Das macht das wesentlich übersichtlicher
 
<?php /* Execute a prepared statement by binding PHP variables */ $calories = 150; $colour = 'red'; $sth = $dbh->prepare('SELECT name, colour, calories FROM fruit WHERE calories < :calories AND colour = :colour'); $sth->bindParam(':calories', $calories, PDO::PARAM_INT); $sth->bindParam(':colour', $colour, PDO::PARAM_STR, 12); $sth->execute(); ?> Fax solltest du übrigens nicht als INT speichern bzw übergeben, das wäre Fehlerhaft wegen der führenden 0 bzw + zeichen (+491235, 03012345 etc)

Vergess den Arbeitgeber, wenn du eine Wahl hast. Lieber auf andere Stellen hoffen bzw. beim aktuellen Arbeitgeber weiterarbeiten. Wenn das alles keine Option ist, akzeptieren, weiterbewerben und im Idealfall während der Probezeit abhauen.
Wenn du denen schon nach dem Vorstellungsgespräch nicht trauen kannst, wie soll dann eine weiter Zusammenarbeit funktionieren? Mach nen weiten Bogen um solche Arbeitgeber

Vergess den Arbeitgeber, wenn du eine Wahl hast. Lieber auf andere Stellen hoffen bzw. beim aktuellen Arbeitgeber weiterarbeiten. Wenn das alles keine Option ist, akzeptieren, weiterbewerben und im Idealfall während der Probezeit abhauen.
Wenn du denen schon nach dem Vorstellungsgespräch nicht trauen kannst, wie soll dann eine weiter Zusammenarbeit funktionieren? Mach nen weiten Bogen um solche Arbeitgeber

Vergess den Arbeitgeber, wenn du eine Wahl hast. Lieber auf andere Stellen hoffen bzw. beim aktuellen Arbeitgeber weiterarbeiten. Wenn das alles keine Option ist, akzeptieren, weiterbewerben und im Idealfall während der Probezeit abhauen.
Wenn du denen schon nach dem Vorstellungsgespräch nicht trauen kannst, wie soll dann eine weiter Zusammenarbeit funktionieren? Mach nen weiten Bogen um solche Arbeitgeber

Die beiden Punkte widersprechen sich doch schon. Wie willst du im Projekt eine Entscheidung treffen, wenn schon alles feststeht.
Du sollst in dem Projekt eine Lösung für ein Problem finden und darfst das dann noch umsetzen, der Fokus liegt aber in WARUM und WIE wird das ganze gemacht.
Ich würde die ganze Migrationsgeschichte rausstreichen und mich auf die Backup-Lösung konzentrieren. Das ist ein gutes Thema für das Projekt. Die Migration und co kann ja schon vorher geschehen bzw in einem Testsystem wird die neue Backup-Lösung evaluiert. Ansonsten hast du ein sehr sehr breites Projekt, gehst aber nicht in die Tiefe