Whiz-zarD

Ähm, eine Anwendung soll eine Datei lesen und eine Datei schreiben und beide befinden sich dann im selben Ordner, wie die Anwendung. Wozu dann ein WebClient? Was hast du denn überhaupt vor? Wozu die beiden Schleifen?

Ein paar Ansätze hatte ich hier schon mal erwähnt. z.B. das Üben von DDD, indem z.B. die Schule bzw. der Lehrer als Kunde auftritt oder auch das Üben von TDD mit sog. Code-Katas. Selbst ich treffe mich ab und zu mit ein paar anderen Entwicklern und bearbeiten eine Kata (über eine Meetup-Gruppe). Man kann da sehr viel von den anderen Entwicklern lernen, weil man andere Sichtweisen und Entwicklungsstile kennenlernt. Wenn man gewisse Regeln definiert, dann hat auch jeder mal die Tastatur vor der Nase und nicht nur die dominanten, die eh alles viel besser können. Auch habe ich hier gelesen, dass ein Azubi OOP beigebracht bekommt, indem er in einer WinForms-Anwendung einen Button zum Springen bringt. Was ist denn das für eine Lernmethode? Wieso eine WinForms-Anwendung? Wenn überhaupt, dann sollte man mit einer Konsolenanwendung anfangen, da bei einer Anwendung mit einer grafischen Oberfläche schon zu viel Magie passiert, die im verborgenen bleibt. Um OOP zu lernen braucht man auch keine grafische Oberfläche. Dann sollte man den Azubis erklären, was (abstrakte) Klassen, Interfaces, Generics, etc. sind und dann auch mal ein bisschen unter die Haube schauen und zeigen, wie z.B. eine Liste funktioniert anstatt sich nur mit Arrays zu befassen. Im selben Atemzug kann man vielleicht auch noch erklären, was eine Referenz bzw. ein Zeiger ist. Vielleicht auch die Problematik mit Geldbeträgen erklären, da ich das Gefühl habe, dass selbst vielen Firmen diese Problematik nicht bewusst ist. Letztes Jahr gabs dazu auf der Developer Week in Nürnberg einen Vortrag dazu und dieser Vortrag war sehr gut besucht und viele waren doch sehr erstaunt. Auch sollte man was sinnvolles entwickeln und keine hüpfenden Buttons. In meiner Assistenten-Ausbildung hatten wir im zweiten Semester zur Übung u.a. einen Sudoku-Löser entwickelt. Dafür hatten wir eine Woche zeit. Zum Testen gab uns der Dozent einen Satz an Unittests, die der Löser bestehen musste. Darüber hinaus gab es noch einen zweiten Satz an Unittests, der erst bei der Abgabe zum Einsatz kam. Der beinhaltete "komplexere" Testszenarien. Das zielte eben halt darauf ab, dass wir uns selbst noch Gedanken machen sollten und selbst Unittests ausdenken und auch untereinander austauschen sollten. Entwickelt wurde dann im Pair-Programming und bei der Abgabe wurden dann Fragen zu unserem Code gestellt, um herauszufinden, ob beide tatsächlich den Code verstanden haben oder ob einer nur den Vortänzer macht und den anderen hinterher schleift. Auch benutzte die Schule ein Analyse-Tool, um herauszufinden, ob vielleicht nicht zwei oder mehrere Gruppen den selben Code abgeliefert haben. Der Code wurde dann in einer Quellcodeverwaltung gepflegt. Wie wäre es auch mit einer größeren Projektarbeit bzw. eine Art Hackerspace? Das könnte man sogar mit den FISIs verbinden. Wie wäre es auch, wenn man einen Gastredner in die Schule holt, der einen kleinen Vortrag zu einem bestimmten Thema hält? Erst neulich habe ich ein 3 Stunden Vortrag zu Microservice in Verbindung mit RabbitMQ angeschaut. Man muss ja das Thema nicht gleich verstehen und es muss nicht gleich sofort eine Klausur darüber geschrieben werden aber es hilft schon, wenn man schon von bestimmten Themen was gehört hat, damit man im Bilde ist, was es sonst noch so für Technologien gibt. Das Ganze kann auch freiwillig sein. Da gibt es eigentlich so viele Ideen, wie man den Berufsschulunterricht gestalten könnte aber das größte Problem ist wohl, dass die Lehrer sich selbst damit überhaupt nicht auskennen. Was ich hier manches mal lese, habe ich das Gefühl, dass sie selbst nicht einmal wissen, wovon sie eigentlich reden und nur ein altes Lehrbuch stur abarbeiten. Man müsste wohl erst mal die Lehrer stetig fortbilden, damit sie auch im Bilde sind, was in der Wirtschaft wirklich abläuft bzw. Lehrer so ausbilden, sodass sie ihr Fach auch selbst verstehen. Ich habe ja auch nichts dagegen, wenn die Azubis auch etwas BWL lernen aber ich finde, dass hier einfach die Priorität zu hoch liegt und die eigentliche Arbeit als FIAE/FISI zu kurz kommt. Ja, ich weiß, eigentlich soll der praktische Teil in den Firmen stattfinden aber die Firmen haben oft gar nicht die Möglichkeit die Azubis optimal auszubilden, da sie oft nicht das Know-How besitzen, um einen Azubi ausgiebig zu schulen. Ich finde, Berufsschulen könnten hier echt was bewirken, um einen Blick über den Firmen-Tellerrand zu wagen aber dafür muss das Personal - sprich die Lehrer - fachkundig sein. Wenn man OOP erklären möchte, dann sollte man nicht mit hüpfenden Buttons kommen.

Ja, ein Entwickler bestimmt nicht, wann sich etwas amortisiert hat, oder sich irgendwann etwas lohnt. Er sagt nur, wie komplex die Umsetzung ist und wie lange es dauert. Die Entscheidung der Wirtschaftlichkeit passiert an einer anderen Stelle. Der Entwickler kann mehrere Alternativen aufzählen aber entscheiden, was umgesetzt wird, macht ein anderer. Und hier sehe ich das größte Problem vieler Softwarefirmen: Es wird kein Wert auf Weiterbildung gesetzt. Ich habe es inzwischen schon in so manchen Firmen erlebt, dass man veraltete Techniken einsetzt, weil man sie schon immer eingesetzt hat und neumodischer Schnick-Schnack sowieso Teufelszeug ist und die Firmen verlieren dann den Anschluss, weil die Kunden sich nicht mehr mit einer augenkrebserzeugenden WinForms- oder Java-Desktop-Anwendung zufrieden geben, sondern eine Webanwendung haben wollen, die auch auf Tablets läuft. Keiner möchte eine Software neu programmieren aber wenn man die Software nicht pflegt und einem ständigen Refactoring unterzieht, wird das aber irgendwann passieren. Irgendwann ist auch eine Code-Basis von anno 2000 veraltet und nicht mehr wirtschaftlich, wenn man sie nicht laufend verbessert und erneuert. Fürs Refactoring wird aber oft kein Budget freigegeben, weil der Kunde davon nichts hat. Solche Diskussionen führe ich gefühlt jeden Tag und irgendwann häufen sich die Beschwerden der Kunden, dass die Software fehleranfällig oder langsam ist und die Entscheidungen werden häufig von Leuten getroffen, die es eigentlich hätte besser wissen müssen. Microservices sind derzeit auch so ein Thema: Die wurden nicht eingeführt, weil man es für Hip und Cool fand, sondern sie zwingen einem nach dem SOA-Paradigma zu arbeiten. Das klassische SOA hat einfach nicht funktioniert auch wenn die Idee gut war und heute immer noch ist. Auch bieten die Microservices einen Vorteil, den du als Nachteil genannt hast: Man ist von der Programmiersprache unabhängig. Es ist egal, ob Service A mit Java, Service B mit C# und Service C mit Cobol entwickelt wurde. Man hat die Möglichkeit, eine geeignete Sprache für die Aufgaben zu suchen. In der Praxis wird das zwar selten vorkommen aber die Möglichkeit besteht. Ich habe früher Industrie-Anlagen programmiert. Nein, sie werden nicht alle 3 Jahre gewechselt aber es handelt sich hier auch nicht um eine Standard-Software. Die Software wird pro Anlage geschrieben und angepasst. Somit läuft pro Anlage eine komplett individuelle Software, die über mehrere Wochen optimiert wird. Der Umgang ist ein völlig anderer, als bei einer Standard-Software aber auch hier bleibt die Zeit nicht stehen. Es werden immer neue Techniken entwickelt. IoT und Big Data wird auch in der Industrie immer wichtiger. Das war vor 15 Jahren noch Utopia. Ich arbeite derzeit bei einer Firma, die eine Software für Banken entwickelt. Banken galten immer als sehr konservativ und intern arbeiten sie wie eine Behörde. Da gibt es dann pro Jahr zwei oder drei Zeitfenster, von wenigen Wochen, in der neue Softwareversionen ausgerollt werden dürfen und selbst bei solchen Kunden erleben wir derzeit ein Umdenken. Das Wort "Cloud" durfte man vor einigen Jahren noch nicht mal in den Mund nehmen. Heute ziehen viele Kunden es schon in Erwägung, ihre Daten in die Cloud zu schieben. Von einem Kunden weiß ich, dass sie schon ihre Daten in eine Cloud outsourcen. Auch haben wir schon von dem einen oder anderen erfahren, dass sie ihre eigens entwickelte Desktop-Lösung gegen eine Microservice-Lösung austauschen wollen und wozu das Ganze? Weil die Banken immer schneller reagieren müssen. Nicht, weil der Markt so schnelllebig ist, sondern weil immer mehr Anforderungen, seitens der Regierung oder der EZB, an die Banken gestellt werden, die sie dazu zwingen, schneller zu handeln. Dazu gehören auch die o.g. Excel-Makros, die nun gegen eine revisionssichere Software-Lösung ausgetauscht werden müssen. Das selbe Problem sehe ich auch in der Automobilbranche, wenn sie tatsächlich autonome Fahrzeuge auf den Markt bringen wollen. Softwarefehler müssen schnell erkannt und behoben werden. Wollen sie denn bei jedem Fehler eine Rückruf-Aktion starten, die die Fahrer dazu zwingt, in die Werkstatt fahren zu müssen? Da müssen noch geeignete Softwareverteilungsmechanismen gefunden werden. Da ap­pel­lie­re ich einfach an den gesunden Menschenverstand. Ich habe selbst schon von Informatikkaufmännern Fehlentscheidungen gesehen, die echt nicht mehr feierlich waren und Jobs gekostet haben, was eigentlich nicht nötig getan hätte. Die Frage ist ja auch, lag es am Entwickler oder an den schwammig formulierten Anforderungen. Das Thema diskutiere ich auch gefühlt jeden Tag. Wenn einem Entwickler nicht klar ist, was er da eigentlich macht und wieso, dann ist es eher ein Anzeichen dafür, dass die Anforderungen nicht klar sind und das wiederum ist ein Anzeichen, dass nicht genügend kommuniziert wurde. Viele Firmen arbeiten immer noch nach dem Wasserfall-Modell, obwohl man schon seit 15 Jahren predigt, dass das Wasserfall-Modell in der IT-Branche nun mal nicht funktioniert.

Du kannst es so oft schreiben, wie du willst und trotzdem wird es nicht richtiger. Mag sein, dass es Bestandteil der Ausbildung ist (was ich auch durchaus für angemessen halt), es sollte aber kein Kernbestandteil sein und genau das meine ich, dass die Prioritäten falsch gesetzt werden. Die Softwareentwicklung ist schon ein sehr komplexes Thema und ich finde FIAEler sollten dann nicht noch zusätzlich ein halber Kaufmann werden, denn dafür gibt es schon die Informatikkaufmänner. Viel mehr sollte man sich hier auf den technischen Aspekt konzentrieren und genau das passiert auch in der Wirtschaft, wie ich z.B. schon mit SCRUM angesprochen habe. Mag sein, dass es viele kleine Firmen gibt, wo ein Entwickler dies benötigt aber nur aufgrund solcher Firmen den kaufmännischen Teil als ein Kernbestand der Ausbildung zu machen, halte ich schlichtweg für falsch. Ja, Wow ... Und für diese Erkenntnis braucht man drei Seiten? Es ist bekannt, dass eine Automatisierung schneller ist, als eine manuelle Abarbeitung und somit kostengünstiger. Das kann ich auch in einem Satz formulieren und brauche keine drei Seiten. Und wenn man den kaufmännischen Aspekt weglassen würde, wären bei der 100% Abschlussarbeit dafür 3 Seiten platz gewesen. Für mich sind Datenstrukturen ein Teil der Grundlagen und diese werden konsequent ignoriert. Stattdessen versucht man wohl in den drei Jahren auch den letzen Deppen beizubringen, dass es keine if-Schleifen gibt. Den Azubis wird doch keine Grundlagen beigebracht. Vielfach habe ich schon gesehen, dass z.B. Geldbeträge als eine Fließkommazahl dargestellt werden. Das ist eine Todsünde! In der 100% Abschlussarbeit wird zwar richtigerweise decimal als Datentyp genommen aber ob dies dem Azubi klar war, lässt sich aus der Dokumentation nicht ableiten. Auch werden oft Arraylisten verwendet, obwohl fleißig neue Elemente rangehängt werden. Dass so etwas inperformant ist und dafür eine verkettete Listen genommen werden sollte, weiß keiner. Die Grundlagen sind also mehr, als nur die Syntax. Zu den Grundlagen gehört auch der Verständnis der bekannten Datenstrukturen und so ein Verständnis ist Programmiersprachenunabhängig. Eine verkettete Liste funktioniert unter C genauso wie unter C# oder Java. Mit dem Unterschied, dass man sie in C erst mal selbst implementieren muss, während man in C# die List<T> und in Java die LinkedList<T> verwenden kann. DDD ist nicht auf Objektorientierung beschränkt. Genauso gut lässt sich DDD auf prozeduraler oder funktionaler Programmierung anwenden. Und genau das meine ich ja mit "Defizite" und "Ein Blick über den Tellerrand". Nicht jede Firma verwendet DDD, TDD oder klassische Unit-Tests aber eine Berufsschule sollte sich deswegen nicht verschließen, sondern sollte den Azubis so etwas zeigen und auch üben. In meiner Ausbildung als Mechatroniker hatten wir so einen ähnlichen Fall. Ich hatte meiner Klasse zwei Mitschüler, die in ihrer Firma nicht mit SPS-Programmierung, Pneumatik oder Hydraulik in Kontakt kamen. Den Part hat dann die Schule übernommen und genau so sollte es auch bei der Softwareentwicklung sein. Einfach zu sagen: "Gibt es nicht, weil nicht alle Firmen dies einsetzen!" ist falsch. DDD und TDD sind Konzepte, die sich in den letzten Jahren sehr bewährt haben. Warum sollte man den Azubis dies nicht beibringen wollen? Der Weisheit letzter Schluss ist das mit Sicherheit noch lange nicht. Sicherlich sind auch irgendwann diese Konzepte überholt und gegen andere ausgetauscht aber wir leben im Jetzt und Jetzt haben sie eine große Bedeutung. Vor 15 Jahren hatten Pflichten- und Lastenhefte noch eine große Bedeutung. Heute schon lange nicht mehr und dennoch tut die IHK so, als wäre dies DAS Prinzip, was auf Ewigkeit bestand hält. Ich habe ja nichts dagegen, dass den Azubis die Objektorientierung beigebracht wird aber man zäumt das Pferd oft von Hinten auf. Ich höre oder lese oft folgendes: "So, jetzt lernen wir Objektorientierung! Startet dafür jetzt alle Visual Studio und öffnet ein neues WinForms-Projekt" ... Das ist schon ein Zeichen für mich, dass man nichts über Objektorientierung lernt sondern nur mit der IDE rumspielt, wenn man schon so hoch in der Abstraktion anfängt. Dass im Hintergrund eine Endlosschleife läuft, die dafür sorgt, dass die grafische Oberfläche immer neu gezeichnet wird und die Events auslöst, wird nicht mal erwähnt. Gern genommen wird auch die allseits beliebte Entwicklung eines Taschenrechners. Aus meiner Sicht für ein Anfänger viel zu kompliziert, wenn man auch die Rechenregel "Punkt- vor Strichrechnung" und Klammersetzung einhalten möchte, denn da sind Konzepte wie z.B. die Polnische Notation oder Binäre Bäume sehr hilfreich. Auch wird dann hier das Konzept der Vererbung benötigt. Für mich sind also schon die angeblich grundlegenden Konzepte falsch gewählt. "Grundlagen" heißt offenbar, dass man die Hälfte verschweigt und den Rest dann nur noch überfliegt. Man muss bedenken, dass man hier Softwareentwickler ausbilden möchte und nicht Tante Emma mal im groben zeigen möchte, wie man programmiert. Daher sollte man den Azubis auch ein Grundverständnis vermitteln, was eigentlich wirklich passiert und wenn man das alles mal berücksichtigt, dann merkt man, dass da überhaupt kein Platz für einen kaufmännischen Teil ist und wenn man endlich diese Erkenntnis erlangt hat, dann ist man wohl endlich auf dem richtigen Weg. Ja, ich beziehe mich nur auf den FIAEler, da die Softwareentwicklung nun mal mein Hauptberuf ist. Zu den FISIs muss ich aber auch sagen, dass ich es für falsch halte, dass die FIAEler und die FISIs sehr häufig die selben Kurse in der Berufsschule haben. Beide sollten zwar Grundlagen in der Programmierung, der Shellskripte, den Datenbanken und der Netzwerktechnik haben aber dann sollten sich schon die Wege trennen. Ein FISI wird nicht großartig irgendeine Software mit Java und einer grafischen Oberfläche, die Daten in Echtzeit auswertet, schreiben und das habe ich bis jetzt noch in keiner Firma gesehen, dass dies erwartet wird. Genauso wird ein FIAEler kaum ein Windows- oder Linux Server mit Active Directory, Firewall, Proxy, DNS, DMZ und sonstigem Kram aufsetzen. Es ist zwar Nett, wenn ein FISI mehr über Softwareentwicklung und ein FIAEler mehr über die Server-Administration weiß aber das ist kein KO-Kriterium, wenn man es nicht weiß.

Dein Text klingt aber nicht so wirklich danach, als sei alles super. Sorry aber das, was ich von dir in diesem Forum gesehen habe, war keine objektorientierte Programmierung. Nur weil man eine objektorientierte Sprache verwendet, heißt es noch lange nicht, dass man auch Objektorientierung anwendet und Struktogramme braucht man im Alltag auch gar nicht. Struktogramme sind auch nicht einfacher zu lesen, als Code. Von daher kann man es auch gleich weglassen. Nicht nur das. Auch die Ausbildung gehört für mich komplett überarbeitet. Das ist echt schon abenteuerlich, was ich hier so über die Abschlussarbeiten- und Prüfungen lese. Die Azubis lernen veraltete und überholte Methoden, nur um die Prüfung bestehen zu können. Vieles, was sie in der Berufsschule lernen, können sie auch gleich nach der Abschlussprüfung wieder vergessen, weil es entweder in der Praxis gar nicht mehr angewendet wird oder so selten, sodass man sowieso erst mal einen Blick auf Google oder Wikipedia werfen muss. Meiner Meinung nach, setzt man auch die Prioritäten komplett falsch. Anstatt den Azubis drei Jahre lang Pseudo-Code und UML-Diagramme einzutrichtern, sollte man - vor allem den Anwendungsentwicklern - mehr sauberen Code beibringen aber offenbar ist selbst das in der Abschlussprüfung zu viel verlangt. Die offiziellen Lösungen der Programmieraufgaben in der Abschlussarbeit ist so ein schlechtgeschriebener Code, dass man davon Pickel bekommt, wenn man nur ihn ansieht. Von gravierenden Fehlern ganz zu schweigen. Was das Abschlussprojekt angeht, bin ich auch kein Freund vom Pflichten- und Lastenheft, was aber offenbar vielfach von der IHK gefordert wird. Das sind auch Fragmente aus einer alten Zeit. Ich habe inzwischen schon viele Projekte gesehen, wo ein Pflichten- und Lastenheft geschrieben wurde (ich habe auch schon sowas das eine oder andere Mal geschrieben) und ständig sind solche Projekte in die Hose gegangen, weil sich die Anforderungen ändern können oder gewisse Dinge sowohl vom Kunden als auch vom Entwickler nicht vollständig durchleuchtet worden waren. Beliebt sind auch Fehlinterpretationen. Sowohl Kunde als auch Entwickler schreiben den selben Wortlaut und dennoch reden sie einander vorbei. Viel wichtiger ist es, mit den Kunden ständig im Kontakt zu bleiben, damit man schnell auf Änderungen reagieren kann. Auch sollte man den Kunden immer mit dem Status informieren und ihm auch den derzeitigen Zwischenstand ungeschönt präsentieren und ihn nicht vor vollendeten Tatsachen stellen, wie es mit dem Pflichten- und Lastenheft der Fall wäre. Wenn man feste Termine mit den Kunden arrangiert, dann braucht man auch kein Lasten- und Pflichtenheft. Änderungswünsche können dann formlos festgehalten und im nächsten Meeting präsentiert werden. Ob und wann sich eine Entwicklung amortisiert hat, ist auch gar nicht die Aufgabe eines Entwicklers. Der Entwickler soll nur analysieren, wie aufwendig eine Implementierung ist. Mehr nicht. Auch lässt sich das als Entwickler oft gar nicht so einfach herausfinden, wie es um die Amortisierung steht. Dies ist nur bei In-House-Lösungen möglich. Wenn man eine Software für einen externen Kunden einführt, muss der Kunde diese Analyse vornehmen, weil der Entwickler kein Einblick in die Interna des Kundens hat. Auch eine Ist-Analyse ist hier gar nicht möglich, wenn der Kunde davon nicht redet. Wer in einem echten SCRUM-Team arbeitet, wird von solchen Analyse-Kram sogar ferngehalten. Nicht weil man den Entwickler dumm halten möchte, sondern weil jeder seine Kernkompetenzen besitzt und die Kernkompetenz eines Entwicklers ist die Softwareentwicklung und nicht das Ausloten der Wirtschaftlichkeit. Als Beispiel nehme ich mal diese Abschlussarbeit, die mit 100% bewertet wurde. Die Abschnitte "Projektkosten" und "Amortisationsdauer" lesen sich wie ein Standardtext, den man in jeder Abschlussarbeit reinknallen könnte. Diese Texte haben überhaupt keine Aussagekraft. Viel wichtiger wären doch technische Aspekte. In einem Nebensatz wird erwähnt, dass die Daten historisiert abgelegt werden sollen. Da werde ich als Entwickler doch sehr hellhörig, weil die Historisierung gar nicht trivial ist. Schon gar nicht in einer relationalen Datenbank. Da hätte ich schon ein Kapitel erwartet, dass sich mit diesem Thema auseinandersetzt. Was passiert z.B. wenn eine Spalte in einer Tabelle hinzukommt? Ich will ja nicht, dass die Azubis z.B. die Data Vault-Modellierung bis ins Detail verstehen und auch anwenden können aber wenn man schon so ein Thema anreißt, dann erwarte ich auch, dass man sich damit beschäftigt. Sei es auch nur, dass man die Risiken aufzählt. Meiner Meinung nach müsste das gesamte System reformiert werden. Wer nach drei Jahren immer noch nicht verstanden hat, dass es keine if-Schleifen gibt, wird das nie verstehen. Ich finde, eine Berufsschule sollte dafür sein, um das in Firmen angelernte Wissen zu vertiefen und zu erweitern. z.B. mal ein Blick auf Datenstrukturen werfen, um ein Gespür zu bekommen, welche wann geeigneter ist. Der Unterschied zwischen einer verketteten Liste und einer Arrayliste ist wohl offenbar nur sehr wenigen bekannt oder dass in Java und C# Arrays als assoziative Arrays missbraucht werden, indem man den gesuchten Index als Konstante ablegt. Anstatt sinnlose Amortisierungsrechnungen aufzustellen, sollte man vielleicht mit den Azubis DDD üben (z.B. die Schule als Kunde) oder mit Hilfe von Coding Dojos sauberen Code oder TDD in Verbindung mit Continuous Testing üben. Auch wäre ein Blick auf funktionale Programmiersprachen nicht verkehrt, weil diese Sprachen immer mehr in kommen sind. Nicht weil sie trendige Hipster verwenden, sondern weil einfach gewisse Probleme, die man aus der Objektorientierung kennt, dort nicht existieren und daher für viele Aufgaben besser geeignet sind, als objektorientierte Sprachen. TL;DR: Gerade die IT-Welt ist so extrem wandelbar. Da ist es einfach nicht klug, einen Ausbildungsrahmenplan bis in alle Ewigkeit in Stein zumeißeln. Auch die Berufsschule und die IHK müssen hier wandelbar sein und Trends erkennen. Kein Azubi hat etwas davon, drei Jahre irgendeinen Quatsch zu lernen, was Prüfungsrelevant ist aber später keine Anwendung mehr findet. Eine Berufsschule sollte dafür da sein, ein Azubi auf den Berufsalltag vorzubereiten nicht nur für die Prüfung. Sie ist dafür da, Defizite, die in den Ausbildungsstätten vorkommen können, aufzuarbeiten und den Azubis ein Blick über den Tellerrand zu ermöglichen.

Und wenn das nicht reicht, dann schreibt man halt einfach ein eigenes Kommandozeilen-Tool, was genau die Ergebnisse zurückliefert, die man braucht. dir und tree sind ja auch nichts anderes.

Warum nicht gleich im Designer festlegen? Dennoch ist das eine Frickelei und sollte auch so nicht umgesetzt werden. In ein WinForms-Projekt sollte keine Logik hinterlegt werden. Eigentlich sollte grundsätzlich in kein ausführbares Projekt Logik hinterlegt werden, weil es die Wiederverwendbarkeit erschwert.

Das ist nicht nur sinnvoller, sondern es sollte auch so gemacht werden: Walkthrough: Creating a Windows Service Application in the Component Designer

Das denke ich auch. Das Bundes-/Landesdatenschutzgesetz regelt die Erhebung und Verarbeitung von personenbezogenen Daten und nicht die Einrichtung der IT-Infrastruktur.

Auf Wikipedia stehen dafür gleich mehrere Ansätze. Sofern es keine Säulen im Labyrinth gibt und die Länge des Weges egal ist, gibt es einen einfachen Algorithmus: Immer nach Rechts gehen.

Das hat man von Bäckern mit Mehlallergie oder von Friseuren mit einer Ammoniak-Allergie, in den 90ern, auch behauptet. Und wo ist denn jetzt nun dein Problem? Was möchtest du von der Community? Sollen sie dir helfen oder nicht? Wenn sie dir helfen soll, dann muss man sich auch mal mit der Community beschäftigen und auch mal die Fragen beantworten aber irgendwie redest du nur um den heißen Brei herum anstatt mit konkreten Antworten zu kommen. z.B. warum du dich für die IT entschieden hast? Du machst eine Umschulung also hast du was davor gemacht aber wieso jetzt die IT? Hattest du schon vorher mit der Softwareentwicklung Kontakt? Wo hast du denn deine Schwierigkeiten? Wenn die Community dir aber nicht helfen soll, wieso hast du diesen Thread überhaupt eröffnet? Möchtest du nur Durchhalteparolen hören? Ob du jetzt die einzige bist, die Schwierigkeiten bei der Prüfung hatte oder nicht, ist auch vollkommen irrelevant, denn es geht um dich und nicht um die anderen! Anstatt also immer wieder Ausreden parat zu haben, um nicht die Fragen beantworten zu müssen, wäre es hilfreicher, wenn du mal konkrete Beispiele nennst, wo du Schwierigkeiten hast. Nur so kann man Defizite aus der Welt schaffen. Was bringt es dir, nächstes Jahr ein Plan zu machen? Was versprichst du dir dadurch? Was soll der Plan überhaupt aufzeigen?

Das wollte ich auch gerade fragen. Man macht ja nicht ohne Grund eine Umschulung zum Anwendungsentwickler.

Wenn man nicht direkt mit der Hardware kommuniziert: Gar nicht. Das ist wohl wieder dieses typische "Hauptsache irgendwas auswendig lernen, was irgendwas mit IT zu tun hat." Kann mir aber einer sagen, was LF4, etc. bedeutet?

C# hat in erster Linie nichts mit .Net zu tun. C# ist eine ECMA- und ISO-Standardisierte Sprache. .NET ist eine Entwicklungsplattform, die aus mehreren Komponenten besteht. z.B. WinForms, WPF, ASP.NET, ADO.NET, LINQ, Entity Framework, Common Language Runtime (CLR) etc. Die neue Compiler-Plattform Roslyn, von Microsoft, kompiliert den C# Code in CIL Code, der wiederrum von der CLR ausgeführt werden kann. Die CLR ist quasi so was ähnliches, wie die Java Virtual Machine. Als Alternative für .NET gibt es Mono und findet man überwiegend in der Linux-Welt, da die .NET-Welt ursprünglich nur auf Windows angesiedelt war. Inzwischen ist das .NET-Framework auch Open Source und mit .NET Core wird eine Plattformunabhängige Version entwickelt, die sowohl auf Windows, als auch auf Linux arbeitet. Der Grund, warum C# fast immer mit .NET in Verbindung gebracht wird, ist halt daher geschuldet, dass die C#-Entwicklung hauptsächlich in der Windows-Welt stattfindet und eben das .NET-Framework als Unterbau verwendet wird. Es kann aber jeder sein eigenen Unterbau bauen, wie es ja mit Mono gemacht wurde. C# kann man auch nicht mit C oder C++ vergleichen, da die Unterschiede sehr stark sind. Höchstens die Syntax kann man ein wenig miteinander vergleichen, da Microsoft sich an C/C++ orientiert hat. Objective-C ist eine Sprache von Apple, die sich aber sehr stark an der Sprache Smalltalk orientiert und sich ebenfalls von C# sehr unterscheidet. Objective-C wird hauptsächlich in der iOS-App-Entwicklung verwendet. Swift ist ebenfalls eine Programmiersprache von Apple und ist eine Alternative zu Objective-C. Die Bedeutung von Multithreading ist auch in allen Sprachen gleich. Objektorientierte Sprachen haben aber aufgrund ihrer Eigenschaft, viele Schwierigkeiten, Multithreading leicht umzusetzen. (Seiteneffekte, Deadlocks, etc.) Darum gewinnen funktionale Sprachen immer mehr an Bedeutung, da dort diese Schwierigkeiten gar nicht existieren, da jeder Wert immutable - d.h. unveränderbar - ist. Da gibt es keine Seiteneffekte. Nur, weil viele Sprachen ein C in einem Namen haben, heißt es noch lange nicht, dass es Untermengen von C sind. Es sind lediglich Sprachen, die Konzepte von C übernommen haben aber eigene Konzepte drumherumgebaut haben, die sich sehr stark voneinander unterscheiden.

Wobei man aber sagen muss, dass bei den heutigen Mehrkern-Prozessoren wirklich mehrere Dinge gleichzeitig abgearbeitet werden können. Multi-Threading muss auch nicht immer was mit Geschwindigkeit zu tun haben. Wenn du in C# einen Timer startest, dann läuft der Timer im einem separaten Thread, da ansonsten die gesamte Anwendung durch den Timer blockiert wäre, da der Timer eine Endlosschleife ist. Ein anderes Beispiel ist eine Statusanzeige. Hier läuft die Logik in einem separaten Thread als die Statusanzeige und die Logik füttert die Anzeige mit Statusinformationen, die dann angezeigt werden. Unter Android läuft sogar per Standard die komplette Benutzeroberfläche in einem separaten Thread, damit die Logik die Oberfläche nicht blockiert. Du kannst ja gerne mal ein Test machen: Erstelle eine neue WinForms-Anwendung, packe dort einen Button rauf und im Click-Event schreibst du private void button1_Click(object sender, EventArgs e) { while(true) { } } Nach dem klicken auf den Button kannst du dann das Fenster nicht mehr verschieben und auch nicht mehr mit dem Schließen-Button schließen, weil der Fokus nun auf der Endlosschleife liegt und die Oberfläche reagiert nicht mehr. Jetzt verschieben wir die Endlosschleife in einen separaten Thread: private void button1_Click(object sender, EventArgs e) { new Thread(Execute).Start(); } private void Execute() { while(true) {} } Und siehe da: Selbst nach dem Klick auf den Button, kann man die Oberfläche verschieben und mit dem Schließen-Button schließen. Die Endlosschleife läuft nun in einem anderen Thread und blockiert nicht mehr die Oberfläche.

Da die Datei nun gelöscht wurde, weiß ich nicht, was drinnensteht aber ich weiß, dass es ein Word-Dokument war. Falls du den Firmen auch ein Word-Dokument schicken solltest, dann schauen sich die Firmen die Bewerbung erst gar nicht an, sondern landet gleich direkt in die Ablage P.

Leider Nein. Das ist auch ein großes Problem bei uns. Die sog. Testpyramide steht bei uns auf dem Kopf. Sehe ich ähnlich. Kommentare können dennoch manchmal hilfreich sein aber sie sollten knapp sein. Es muss aber dennoch kommuniziert werden, dass Feature XYZ neu hinzugekommen ist. Das Beispiel mit der CSV-Bibliothek kommt nicht von irgendwo. Das Problem haben wir tatsächlich. Bei uns im Code schlummern mehrere Klassen, die generisch CSV-Dateien generiert und das alles nur, weil Entwickler A nicht mit Entwickler B spricht und Entwickler A nicht wusste, dass Entwickler B sowas schon mal gebaut hat (davon abgesehen, dass man per NuGet sowieso schon zig Bibilotheken holen könnte...)

Und genau das führt immer zum Chaos. Ich kenne es selber aus der Firma, wo ich arbeite. Es ist eine Qual nach Funktionalitäten zu suchen, weil es keine technische Dokumentation gibt. Also wird dann z.B. zum fünften Mal eine Bibliothek geschrieben, die eine CSV-Datei erzeugt. Ein kleiner Kommentar, der irgendwo angibt, dass Klasse X CSV-Dateien erstellt, hätte da nichts gebracht, weil man nicht weiß, wo sich Klasse X befindet. In unserem kleinen Team haben wir angefangen, eine technische Dokumentation zu schreiben und es klappt. Jeder weiß, wo er nach Informationen suchen kann, wenn er eine Funktionalität benötigt. Dokumentationen kann man sich auch aus den Kommentaren generieren lassen, wenn die Kommentare brauchbar sind. Dafür gibt es ja z.B. Sand Castle oder Doxygen.

Die Frage ist ja, wer sind die Teilnehmer? Der Kurs richtet sich ja an blutige Anfänger. Sie wissen es nicht besser und dann kommt einer, der Wirtschaftsingenieurswesen studiert hat und erzählt einem was vom Pferd. Ich glaube auch nicht, dass der Kurs sich noch großartig angepasst wird. Der Typ scheint enormes Vertrauen in sich zu haben, denn mit Selbstlob geizt er nicht. Im Neudeutsch würde ich sagen, dass er ganz schön auf die Kacke haut. Ich habe nichts gegen Vereinfachung. Ich erwarte ja nicht, dass er auf die Gefahren von Fließkommawerten eingeht und warum man diese nicht für Geldbeträge nutzen sollte (zumindest nicht double und float; dafür gibt es in C# decimal) aber allein schon in diesen einem Video merkt man, dass er oft keine Ahnung hat, wovon er da eigentlich redet. Dann wird seine Sprechweise unsicher. Er macht Pausen und versucht das Thema schnell mit einem Halbsatz zu beenden. Kommentare sind immer so eine Sache. Ich garantiere dir, dass auch mit Kommentare das Tamagochi-Projekt zum Chaos geworden wäre. Es liegt nicht immer an den fehlenden Kommentaren, sondern an der Dokumentation. Kommentare helfen nicht, wenn man nicht weiß, wo man suchen muss. Mit Kommentaren bin ich auch immer sehr sparsam. Ich mache sie nur dort, wo ich es für nötig halte. Triviale Getter- und Setter bekommen keine Kommentare. Auch die Kommentare für Methoden sollten meiner Meinung sehr sparsam sein. Maximal zwei bis drei Sätze. Kommentare für Methoden sollten auch nie den Algorithmus erklären, denn irgendwann kommt der Zeitpunkt, wo man den Algorithmus anpassen muss und dann vergisst man mit Sicherheit den Kommentar anzupassen und schon laufen Kommentar und Implementierung auseinander. Viel wichtiger als Kommentare ist die Kommunikation und die Dokumentation.

Eine Ergänzung: Außerdem fehlt Generics komplett. Ich habe mir mal das Video "Einführung in Datentypen und was du in diesem Kapitel lernst" angeschaut. Der erzählt viel Stuss. Man merkt, dass er nur Halbwissen verfügt. z.B. weiß er nicht, dass Variablen nur in einem Sichtbarkeitsbereich haben und er meint, dass Variablen so lange im Speicher bleiben, bis wir sie löschen. Das ist falsch. Variablen mit einem primitiven (integrierten) Wertetyp verlieren ihre Gültigkeit, wenn der Programmfluss ihre Sichtbarkeit verliert. Variablen mit Klasseninstanzen räumt der Garbage Collector weg, wenn der Programmfluss ihre Sichtbarkeit verliert. Auch behauptet er, ein Integer-Wert könnte man nicht mit einem double-Wert addieren. Das ist falsch. Natürlich geht das. Das Resultat ist dann ein double-Wert. Der Unterschied zwischen double und float ist für ihn auch nur die Speichergröße. Auf die Genauigkeit geht er gar nicht ein. Nee, der Kurs ist selbst für 20 € noch zu teuer. Der Originalpreis von 95 € ist Wucher.

Ich persönlich würde vom udemy-kurs die Finger von lassen. Ich habe noch nie einen Einleitungstext mit so vielen Zeichensetzungs- und Grammatikfehlern gesehen. Auch ist er Autor wohl von sich selbst sehr überzeugt, obwohl er nicht mal ein softwareeentwickler ist, sondern sich das wohl alles selbst beigebracht hat. Außerdem macht er falsche Versprechungen, da er behauptet, dass man nach seinem Kurs Spiele in Unity entwickelt könnte aber er geht gar nicht auf Unity ein. Nee, das klingt für mich doch ein wenig unseriös.

Der berühmte Taschenrechner... Nein, ich halte die Entwicklung eines Taschenrechners nicht sinnvoll für einen Anfänger, denn so trivial ist sowas gar nicht. Meist handeln solche Beispiele nur von pseudo-taschenrechnern, die nur kettenaufgaben lösen können. Also nichts, was man im Alltag gebrauchen könnte. Das hinterlässt ein unzufriedenes Gefühl. Wenn dann noch eine grafische Oberfläche ins Spiel kommt, wird es dann ganz schlimm. Dann wird die Oberfläche mit der Berechnungslogik vermischt und dann bringt man es den Anfänger absichtlich falsch bei. Um einen richtigen Taschenrechner bauen zu können, braucht man schon ein bisschen mehr Wissen und das hat ein Anfänger noch nicht.

Das kommt mir sehr wenig vor. In einer Windows-Domäne kann man die Signatur direkt im AD hinterlegen und Outlook holt sie automatisch. Ich finde ganze Tutorials, die einem erklären, wie man es umsetzt. Das sind weniger als 10 Schritte und die sind sogar recht simpel. Dafür braucht man vielleicht ein Tag und dann läuft es.

Natürlich gibt es auch hier Diskussionsspielraum, ansonsten dürften viele Betriebe gar nicht ausbilden. Als Beispiel nenne ich meine Mechatroniker-Ausbildung. Einige Schulkollegen aus meiner damaligen Berufsschulklasse hatten in Firmen eine Mechatroniker-Ausbildung gemacht, die gar nicht die Möglichkeiten hatten, den Ausbildungsrahmenplan vollumfänglich einzuhalten. So ist im Ausbilungsrahmenplan z.B. von "Installieren und Testen von Hard- und Softwarekomponenten" die Rede aber sowas gibt es in Firmen nicht, die z.B. Kettensägen mit Verbrennungsmotoren bauen. Solche Firmen haben dann Wartungsverträge mit IT-Firmen. Die Azubis dürfen dann nicht mal in die Nähe der Server.

Das ist jetzt eine persönliche Vorliebe von mir, aber ich würde empfehlen, mit der Sprache C# anzufangen. Die Community Editon von Visual Studio ist ja kostenlos erhältlich und bietet alles, was man eigentlich so braucht. Java wäre auch möglich aber ich halte die Entwicklungsumgebungen nicht ganz für anfängertauglich. Ich hab das Buch zwar nicht gelesen, aber das Inhaltsverzeichnis und die Leseprobe lesen sich ganz vielversprechend und daher würde ich folgendes Buch empfehlen: Schrödinger programmiert C# Mit 750 Seiten ist es schon ein großer Brocken aber dadrinnen befinden sich sehr viele farbige Bilder und recht wenig Text auf den Seiten. Das lockert vielleicht das Lesen ein wenig auf. Einige werden wohl die Sprache Python empfehlen, weil sie sehr anfängerfreundlich sein soll aber ich muss gestehen, dass ich mit dieser Sprache bis jetzt kaum etwas gemacht habe und auch keine Literatur dafür empfehlen kann. Bücher, wie Clean Code würde ich auch noch keinen Anfänger in die Hand drücken wollen. Das würde ich erst machen, wenn die Person auch schon gewisse Erfahrungen gesammelt hat, auf die man aufbauen kann.