Whiz-zarD

Vielleicht solltest du weniger Boulevardpresse lesen und dich mal wirklich mit jemanden unterhalten, der Bürgergeld bekommt... 🙄 https://www.br.de/nachrichten/wirtschaft/buergergeld-oder-mindestlohn-lohnt-es-sich-zu-arbeiten-ein-faktenfuchs,TqqyLHl

Anstatt immer das Schreckgespenst "Entlassungswelle" zu erwähnen, sollte man vielleicht mal die Angestelltenanzahl im IT-Sektor mal vor und nach der Pandemie anschauen. Gerade in Amerika, wo man viel mehr mit Hire-and-Fire zu tun hat, wurden während der Pandemie extrem viele eingestellt, die man jetzt entweder ausssiebt oder in der Menge nicht mehr benötigt. Da wurden dann man eben 5.000+ neue Mitarbeiter eingestellt, obwohl man nur 500 brauchte, etc. Und nein, das was wir hierzulande sehen, sind nicht die Hire-and-Fire-Auswirkungen aus USA. Das, was wir hier sehen ist ein anderer Aspekt, der zwar auch in der USA zutrifft aber nicht so bedeutsam für die Entlassungswelle ist: Die angespannte Lage auf dem Kapitalmarkt. Große Projekte werden um ein paar Jahre nach hinten verschoben, weil die Investionsbereitschaft gesunken ist. Das bedeutet aber nicht, dass IT-Fachkräfte nicht mehr benötigt werden, denn aufgeschoben ist nicht aufgehoben. Das merke ich bei uns. Unsere Kunden haben größere Projekte um zwei bis drei Jahre nach hinten verschoben, weil sie entweder damit beschäftigt sind, ihr eigenes Geschäft zu stabilisieren oder gerade selber Probleme haben an günstige Gelder zu kommen. Dass mit der Dotcom-Blase zu vergleichen halte ich auch für absoluten Blödsinn, denn damals sind die Firmen pleite gegangen, weil sie den Erwartungen der Investoren nicht erfüllten und die Investoren sich aus diesem Bereich zurückzogen. Heute zögern die Investoren, weil allgemein die Zeiten etwas unsicher sind. Auch arbeiten heute viel mehr Menschen in der IT als zu der Zeit der Dotcom-Blase. Heute haben doch ein großteil aller Firmen eine eigene IT-Abteilung und wenn man sich nicht nur die großen Konzerne anschaut, dann sieht man auch ein ganz anderes Bild, nämlich, dass Fachkräfte gesucht werden, wie blöde.

Wir waren schon immer recht flexibel, was Home Office anging. Vor der Pandemie hatten wir aber halt keine bzw. wenig Möglichkeiten gehabt, von zu Hause an einem Meeting teilzunehmen, sodass wir trotzdem immer ins Büro gefahren sind. Seit der Pandemie sind wir jetzt zu 99% im Home Office. Ich bin nur noch sehr selten im Büro. Vielleicht 4 oder 5 mal im Jahr. Zu Hause sind wir inzwischen auch besser ausgestattet als im Büro. Ob das aber wirklich die Zukunft ist, weiß ich nicht. Im Allgemeinen wollen zwar viele weiter vom zu Hause arbeiten aber ich denke, dass wir Menschen noch nicht so weit sind. Dabei rede ich noch nicht mal von irgendwelchen Tools (die sind zwar auch noch grauenvoll aber das ist ein anderes Thema), sondern es fehlt das zwischenmenschliche. Früher im Büro hat das auch nicht gestört, wenn man sich mal 15 Minuten (oder länger) im Smalltalk verquatscht hat. In Online-Meetings ist das für viele plötzlich eine Zumutung überhaupt Smalltalk zu halten. Benachrichtigungen im Chat werden dann deaktiviert, weil man sie nicht lesen möchte, obwohl es eigentlich nichts anderes ist, wie früher, wenn man im Büro das eigene Team etwas gefragt hatte und von Smalltalk im Chat fühlt sich gleich jeder genervt. Gerade aber Smalltalk ist wichtig für die Teambildung. Bei so einer Blockade ist es auch gerade für neu Angestellte sehr schwierig, sich überhaupt zurecht zu finden. Was mir auch aufgefallen ist, dass der Ton bei uns rauer wurde. Ob es aber am massiven Anstieg der Arbeit oder am Home Office liegt, kann ich aber nicht sagen. Bei all den Punkten kann ich schon verstehen, wieso man möchte, dass die Angestellten wieder ins Büro kommen sollen. Als Angestellter darf man es nicht immer als Kontrolle verstehen. Ich denke aber, dass diejenigen, die wollen, dass die Angestellten wieder ins Büro kommen sollen, es auch gut begründen müssen, damit es eben nicht zu diesem Unmut kommt.

Wie gesagt, du musst den Namespace in der XAML-Datei anpassen. Aus der XAML-Datei wird ja Code generiert, der eben diese InitializeComponent()-Methode beinhaltet. Dieser Code liegt dann aber im falschen Namespace, wenn du die Datei nicht anpasst und kann daher nicht gefunden werden.

Ich würde mal vermuten, du hast zu einem späteren Zeitpunkt den Namespace angepasst. Dann findet er die automatisch generierte Datei nicht mehr. Du musst den Namespace auch in er XAML-Datei anpassen.

Exakt, weil es noch nie eine hohe Anforderungsqualität oder Zuverlässigkeit gab aber die Prozesse so ausgelegt waren, dass die sie hoch waren. Ergo: Die Qualität der Projektplanung wurde vernachlässigt, weil sich niemand dafür wirklich verantwortlich gefühlt hat bzw. niemand so recht wusste, wie man diese Probleme in den Griff bekommt. Personen, die sich dann z.B. Anforderungsmanager nannten, wurden dann diesen Stellen nicht gerecht und die Lösung der Probleme heißt "Transparenz". Exakt. Ich könnte über eine nette Anekdote hier im Unternehmen berichten, wenn ich dürfte aber ja, Fehler im Fundament können auch im agilen Umfeld entstehen, wenn man einfach drauf losporgrammiert. Genau dieses Prinzip hat aber auch massive Nachteile. Es ist vielleicht schön und toll, dass du dich mit dokumentenbasierten Datenbanken auskennst aber wie sieht es allgemein im Unternehmen aus? Schließlich muss die Software gepflegt werden und das klappt nur, wenn genug Know-How im Unternehmen existiert bzw. von Außen über Neueinstellungen eingebracht werden kann. D.h. selbst bei Microservices sollte man tunlichst einen Wildwuchs an Technologien vermeiden und sich auf bestimmte Kern-Technologien verständigen. Mag sein, dass bei einem Problem eine dokumentenbasierte Datenbanken besser wäre aber wenn es keinen im Unternehmen gibt, die sie pflegen kann, ist sie dann keine gute Wahl. Es gibt auch noch genug On-Premise-Lösungen auf dem Markt und da sind Microservices in der Regel keine gute Wahl.

Das hat aber nichts mit Cloud an sich zu tun. Das kann ich auch lokal mit Containern machen. Früher wurden dafür auch fertige VMs bereitgestellt, die heute aber durch Container verdrängt worden sind. Ich persönlich hatte damals eine Linux VM mit einem Apache Webserver und einer MySQL-Datenbank, die ich dann einfach hochgefahren habe. Klar, mit Clouddiensten geht es heute schneller aber sie macht nichts möglich, was damals nicht ging.

Hat es diese Rollen wirklich jemals gegeben, außer auf dem Papier? Ich würde sagen, nein. Ansonsten gäbe es ja keinen Grund, Agil zu arbeiten, wenn die Qualität der Anforderungen hoch ist und die Termin- und Kapazitätsplanung funktionieren würde. Ich denke aber mal jeder Entwickler kennt die schlechtbeschriebenen Anforderungen oder die zu knappen Deadlines. Agile Softwareentwicklung ist ja nicht durch ein Management entstanden, sondern von Entwicklern selber. XP entstand ja dadurch, dass ein Projekt (eine interne Buchhaltungssoftware) stillstand und man dann zusammen mit den Facharbeitern gearbeitet hat. Neben einem Entwickler saß auch ein Facharbeiter, der die Anwendung später bedienen sollte. Die Entwickler waren also im ständigen Austausch mit den Benutzern und bekamen sofort Feedback. Sowas nannte man früher Terminalserver.

Eher weniger. Es entstand aus mehreren Richtungen aber keiner davon hatte irgendwas mit Agile Softwareentwicklung zu tun gehabt. Microservices sind keine neuartige Erfindung. Microservices ist nur eine feingrunalare Serviceorientierte Architektur (SOA). SOA ist sogar älter als das Agile Manifesto und so agil sind Microservices nun auch nicht, weil man ganz schnell in eine Service-Hölle (distributed big ball of mud) kommen kann, wenn nur jeder das macht, was er will. Es ist also eine hohe Kommunikation und auch Disziplin von Nöten und sollten auch von kleineren Unternehmen vermieden werden, weil der Aufwand nicht zu unterschätzen ist. Bei Microservices ging es viel mehr darum, die Software rubuster gegen Veränderungen zu entwickeln. Es stand also mehr das Aufbrechen der Zuständigkeiten im Vordergrund. Man hatte mehr die Unix-Philosophie im Kopf: „Mache nur eine Sache und mache sie gut.“ Aufgrund der vielen Nachteile der Microservices, etabiliert sich immer mehr die Architektur des Modularen Monolithen. Monolithen sind ja per se erstmal nichts schlimmes und lassen sich auch agil entwickeln. Das Problem ist aber oft die Zuständigkeiten, wenn es innerhalb eines Monolithen keine klare Trennung der Fachlichkeit gibt und genau das versuchen Modulare Monolithen in den Griff zu bekommen. Microservices haben sich also eher durchgesetzt, weil der Begriff "Monolith" verbrannt war, durch die millionenfache Legacy Produkte und Microservices dann als der Heilbringer verkauft wurde.

Hat das wirklich der Professor vorgegeben? 🤨

k thx bye.

k thx bye.

Hast du es schon mal mit ChatGPT versucht?

gelöscht.

Das macht planen() auch nicht, sondern gibt den konkreten Typ zurück aber macht einen Upcast auf seine Elternklasse. Darum ist planen() ja auch abstrakt und muss konkret in den Klassen Buerobau und Wohnbau implementiert werden und deswegen gibt es im Klassendiagram auch den Pfeil auf die Klassen Buerogebaeude/Wohngebaeude.

Und warum nicht? Genau da passiert doch, was du schreibst: Es wird planen() aufgerufen, die uns eine Instanz von einem Gebäude zurückgibt.

Davon gehe ich auch aus. Deswegen schrieb ich ja, dass der Code schon Sinn macht, wenn das die bauen()-Methode sein soll.

Es wird auch keine abstrakte Klasse instanziiert, sondern planen() hat als Rückgabetyp Gebaeude. Allerdings werde ich aus diesem Klassendiagram nicht schlau. z.B. ist Buerobau ja von Buerogebaeude strukturell abhängig. Das bedeutet, dass Buerobau eine Instanzvariable von Buerogebaeude haben muss. Ich denke aber eher, dass hier eine allgemeine Abhängigkeit gemeint ist, weil bauen() und planen() jeweils eine Instanz von Typ Gebaeude zurückgeben und daher die Linie gestrichelt sein müsste (darum hasse ich Klassendiagramme). Darum ist planen() auch abstrakt, weil planen() eine konkrete Instanz vom Typ Gebaeude (Buerogebaeude, Wohngebaeude) erstellt. wenn dann der Code: die Methode bauen() sein soll, dann macht der Code durchaus Sinn.

Das ist aber auch von der Sprache abhängig. z.B. in Python gibt es solche Konzepte, wie private oder protected gar nicht. Da ist alles public. Es gibt nur die naming convention, dass private Variablen mit einem unterstrich anfangen sollten. Das ist aber auch nur ein "Bitte ändere diesen Wert nicht!".

Das Gesamtprojekt vielleicht aber nicht, warum z.B. nun der Test 5 Stunden gedauert hat und nicht 3. Und selbst der Kunde weiß, dass es nur ungefähre Angaben sind, die sich verschieben können. Das ist ja auch einer der Gründe, wieso Agile Softwareenttwicklung (bin FIAE-Ausbilder) überhaupt entstanden ist. Exakte Aufwandsschätzung funktionieren nun mal nicht und in vielen Fällen ist eine Aufwandsschätzung auch sehr kontraproduktiv aber ist ein anderes Thema. Exakt aber das wird in vielen Fällen anders gesehen. Auch hier in diesem Forum sehen dies viele anders. Unzählige Male wurde schon darauf hingewiesen, dass man bei dem Projektantrag darauf achten soll, dass es exakt 40/80 Stunden sind und später auch in der Dokumentation exakt 40/80 Stunden rauskommen sollen.

Da widersprichst du dich aber: Wenn es keine Punktlandung gibt, dann möchtest du eine Erklärung dafür haben. Ergo: Damit keine Erklärung erforderlich ist und somit auch ggf. keine unangenehmen Fragen entstehen, werden es die Azubis aber so hindrehen, dass es eine Punktlandung wird. Diese Diskussion gab's hier auch schon öfters im Forum, dass man doch bitte darauf achten soll, dass am Ende des Tages die exakten x Stunden in der Dokumentation stehen. Das mag vielleicht von IHK zu IHK oder von Prüfer zu Prüfer anders sein aber leider sieht so die gängige Praxis aus.

Naja, man wird es immer so hinstellen, dass das Projekt die bessere Lösung sei, egal wie gut oder schlecht andere Lösungen sind, denn es braucht eine Rechtfertigung, das Projekt auszuführen.

Ist zwar alles schön und gut aber die IHK geht genau genommen zu weit, denn in der Ausbildungsordnung steht ein Zeitrahmen von "höchstens x Stunden" und nicht "exakt x Stunden". Das ist ein kleiner aber feiner Unterschied. Das Projekt darf einfach nicht länger dauern, als die x Stunden aber es darf weniger sein. Eigentlich bedarf es hier überhaupt keine Rechtfertigung, wieso man für Schritt a zwei Stunden länger gebraucht hat, denn der Teufel steckt nun mal im Detail. Das ist das, was mich auch sehr sauer aufstößt an der ganzen Geschichte, denn eigentlich geht es nur darum, dass der Azubi einen gewissen Zeitrahmen einschätzen kann, sodass es im wirtschaftlichen Rahmen bleibt und nicht, dass er eine Punktlandung hinlegen soll, denn das wird sowieso nicht funktionieren. Damit es dann zu keinen Fragen kommt, wird die Dokumentation dann so hingebogen, dass alles Tutti war und der Plan exakt so aufging, wie man ihn vorhergesagt hat. Da frage ich mich, ob das wirklich der Sinn und Zweck der Dokumentation ist, dass der Azubi lernt, wie man die Prüfer erfolgreich belügen kann? Das gleiche gilt sogar für die Wirtschaftlichkeitsbetrachtung, denn meines Erachtens muss dies während oder vor des Projektantrags geschehen und nicht während des Projektes, denn man wird es sowieso so hindrehen, dass das Projekt am wirtschaftlichsten sei. Wenn es sich z.B. herausstellt, dass es schon fertige Lösungen gibt, die viel günstiger wären, wäre das Projekt schon nach wenigen Stunden beendet.

Es ist halt die Frage, wie man sich von der SQL-Datenbank abhängig machen möchte, denn nicht jede Datenbank hat die gleiche Funktionalität. Für EF Core gibt es ja diverse Provider, die schon für die jeweilige Datenbank das korrekte SQL generieren. Da braucht man sich dann weniger Gedanken drum machen. Man erkauft sich aber dann diese Flexibiltät mit dem Problem, dass du geschildert hast, denn das was du machst, ist schon der gängige Weg. Allerdings hat Microsoft das Problem inzwischen auch erkannt und hat dafür seit EF Core 7.0 eine Lösung parat, denn mit EF Core 7.0 wurde die ExecuteUpdate()-Methode eingeführt. Ich hab sie aber noch nicht verwenden können. Kannst ja mal schauen, ob dies was für dich ist und ob dies überhaupt schon mit SQLite funktioniert, denn wie jedes Feature in EF Core ist es davon abhängig, wie weit der jeweilige Provider die Features implementiert hat. https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-7.0/whatsnew#executeupdate-and-executedelete-bulk-updates Ansonsten gibt es auch seit EF Core 7.0 die ExecuteSql()-Methode. https://learn.microsoft.com/en-us/ef/core/querying/sql-queries#executing-non-querying-sql Diese Methode ist aber mit Vorsicht zu genießen, weil dadurch kann man die Flexibilität verlieren, die EF Core bietet. Wenn alle Stricke reißen sollen, muss man dann selber eine SqlConnection aufbauen und das Update selbst ausführen.

Vielleicht solltest du dir mal die Dokumentation von GetDictionaries() genauer durchlesen. GetDictionaries() hat ein Parameter, womit du alle Unterordner einbeziehen kannst. https://learn.microsoft.com/en-us/dotnet/api/system.io.directoryinfo.getdirectories?view=net-7.0