thereisnospace

Als Hinweis wird angegeben:
1Gbyte = 1024³ Byte

Der Umrechnungsfaktor von MByte auf GByte ist nicht 1000, sondern 1024 (2 ^ 10 = 1024). Das soll dir der Hinweis sagen.
 
So wie ich das sehe, ist deine Lösung korrekt, du hast nur bei der Umrechnung von MB auf GB, den Faktor 1000 genommen.

http://www.rechnungswesen-portal.de/Fachinfo/Firmenwagen-Fahrtenbuch/Lohnabrechnung-bei-Dienstwagen-die-1-Regel.html

Bist du im Außendienst? Welche Region?
1900 brutto ist schon sehr mager. Dann noch mit Firmenwagen. Mit normalen Mittelklassewagen kommt man da bei ~1200 netto raus.

Hast du ihn denn auch gefragt warum es entspannter ist?
Vielleicht gehts ihm darum, dass er seine Kurse selbst wählen kann, geht er das Studium vielleicht lockerer an? Vielleicht findet er toll nicht in einer Berufsschule rumhocken zu müssen, vielleicht war sein Ausbildungsbetrieb schlecht. Vielleicht macht der Altersunterschied schon etwas aus, man ist immerhin reifer, sieht Dinge nicht mehr ganz so eng...
Wenn man Einzelschicksale ins Spiel bringt muss man etwas ausführlicher werden, sonst folgt so eine Antwort:
Ich kenne einen, der hat in seinem Studium nur gechillt. Sein Kommilitone hat das ganze ernster genommen.
Beide haben das Studium gleichzeitig abgeschlossen - einer von beiden hatte direkt nach Abschluss eine gute Stelle im Konzern und hat sich ein Haus gebaut. Der andere ist Entwickler in einer kleinen Softwarebude.
Was genau eigentlich? ' Wie gesagt, die meisten Auszubildenen wohnen noch bei ihren Eltern, kriegen regelmäßig ihr Geld, haben keinen Prüfungsstress (außer einmalig in der Endprüfung) und müssen nicht neben ihrer Ausbildung noch 20 Stunden arbeiten gehen, um zu leben ' - Das ist keine Bewertung sondern einfach Tatsache. Ich hab zwar nicht mehr bei meinen Eltern gewohnt, aber sonst passt das schon. Die Feierabende waren nicht groß anders als sie es heute sind, hätte ich da noch zu einem Nebenjob gehen müssen wäre es doch ein klar anderer Aufwand der für die Ausbildung aufgebracht werden müsste.
Sorry, aber hast du Uhus ganzen Post gelesen? Da wird recht gut aufgeführt was im Studium so passieren kann. Und du fischst dir einen Abschnitt am Ende raus und sagst, das ist falsch?^^
Die größte Gefahr für den Azubi ist der Ausbildungsbetrieb, wenn man Pech hat landet in einer Ausbeuterbude und muss sich erstmal damit rumschlagen. Aber sonst ist doch alles recht klar abgesteckt. Im Ausbildungsbetrieb wird gearbeitet und gelernt, in der Berufsschule ist eh das meiste easy... nur zu den Prüfungen wird es dann mal brenzlig und man muss richtig lernen, aber diese Situation haben Studenten doch viel öfter.
Um das mit dem Nebenjob nochmal aufzugreifen: sowohl die beiden aus meinem Beispiel oben als auch alle anderen Studenten die ich persönlich kenne, haben oder hatten während des Studiums einen Nebenjob. Bei Studenten von denen ich so mal von Kollegen oder so höre 'mein Bruder studiert jetzt auch..', fällt mir nur einer ein der ohne Nebenjob zurecht kommt - da hilft die Mama finanziell.
Vielleicht siehst du auch nur 'dass es Azubis so leicht haben und Studenten schwer' zu eng. Wenn die Ausbildung der Maßstab ist, liegt das Studium einfach drüber. Das wertet die Ausbildung nicht ab, es ist aber einfacher als das Studium. Oder anders formuliert. 'Die Ausbildung ist schon anspruchsvoll, das Studium aber noch mehr [...wenn man es ernst nimmt, ...wenn man zu dem Großteil gehört der sich mit Nebenjobs rumschlafen will, ...was auch immer es noch für Einschränkungen gibt um das nicht zu allgemein zu fassen]'

Hallo Zusammen.
Will mich hier mal wieder kurz melden, die letzten drei Jahre gingen doch recht schnell vorbei
Ich Habe den Schritt gewagt -> Reguläre Ausbildung angefangen in 08/2014, bei nem relativ kleinen aber feinen IT-Systemhaus.
Umschulung übers Amt oder so -> Keine Chance (Wortlaut von denen: Sie können gerne eine neue Ausbildung machen, aber das ist dann Ihr reines Privatvergnügen)
Finanziell ist die Zeit natürlich hart aber ansonsten habe ich den Schritt bisher noch nicht bereut.
Dieses Jahr gibts dann die Abschlussprüfung. Sollte kein Problem sein, wenn einem nur was vernünftiges als Abschlussprojekt einfallen würde -.-
Berufsschule und Neues lernen war für mich jetzt absolut kein Problem, mit minimalem Lernaufwand immer Note 1-2. Auch im praktischen Teil in der Firma, bzw. beim Kunden habe ich soweit keine Probleme. Kann also jedem der vielleicht in ner ähnlichen Situation ist nur empfehlen den Schritt zu machen.
Und thx an alle hier. Ihr habt definitiv zu meiner Entscheidung beigetragen
 
mfg Simon
 
 

@Xlarge, vielen Dank für dein Feedback nach so langer Zeit! Es ist immer schön zu sehen, was dann am Ende aus dem TE geworden ist und vielleicht motiviert dieser Beitrag noch mehr Leute mit dem Interesse an einer Umschulung doch den Weg der Ausbildung zu gehen.
Alles Gute für deine Prüfung und bei Fragen einfach hier im Forum melden!

Danke für alle Kommentare und hilfen.
Thema abgeschlossen. Neuer Vertrag. 45% Gehaltserhöhung + weitere Gehaltserhöhung nach 1 Jahr um (9%).
Dazu 15 Gehälter im Jahr.
War irgendwie doch leichter als gedacht, bereue gerade nur, nicht noch höher angesetzt zu haben

Glückwunsch^^

Naja, ich verlange ja nicht von jedem Prüfling, mich zu belustigen. Ich möchte nur - gerade bei der Präsentation - darauf hinarbeiten, dass sich das alte Klischee von langweiligen Folien mit Ladebalken und CI endlich verändert! Du sprichst es schon an: Auf Konferenzen trägt heute niemand mehr so vor! Also warum lernen die Azubis so einen Mist!? Wo wird in Unternehmen mit Ladebalken gearbeitet? Habe ich (!) noch nie gesehen. Das scheint also auch nur für die Prüfung "gestellt" zu sein...
Ich bin in der vorteilhaften Position, dass ich seit meiner Bewerbung für die Ausbildung keine Bewerbung mehr schreiben musste. Aber ich sitze auf der Gegenseite und lese Bewerbungen. Und in beiden Fällen würde ich persönlich dafür plädieren, sich - analog zur Projektpräsentation - von der "grauen Masse" abzuheben. Und da war die Github-Idee tatsächlich ernst gemeint. Bei mir (natürlich kann ich nicht für andere sprechen) würde das sehr gut ankommen. Und wenn ich mich selbst bewerben würde, sähe dieses Dokument sicherlich auch nicht so aus wie die Anschreiben, die hier im Forum häufig diskutiert werden.
Seit meiner eigenen IHK-Präsentation 2006 habe ich alle Präsentationen so gehalten. Inkl. meiner eigenen Masterarbeit. Ich lebe diesen Stil also selbst und mache auch keine Abstriche bei Prüfungsleistungen. Ich würde sogar soweit gehen zu sagen, dass ich mich inzwischen schämen würde, wenn ich Textfolien präsentieren müsste. Das ist im beruflichen Kontext (interne Präsentationen vor Chefs usw.) genauso wie auf Konferenzen usw. Und dass dieser Stil auch bei IHK-Prüfungen sehr gut (im Sinne von 100%) ankommt, zeigen die Beispiele auf meiner Website. Sie enthalten zwar keine Star-Wars-Referenzen, aber ich würde mich nicht scheuen, solche einzubauen, wenn sie sinnvoll (!) sind. Wie ich schon schrieb: Es geht nicht um eine Belustigung, sondern um die Unterstützung der fachlichen Inhalte!
Da gebe ich dir recht. Aber es gibt ja auch viele gute Azubis, die sehr gut präsentieren können, und die ihre Folien schon von sich aus spannend gestalten. Und die möchte ich in ihrer (guten) Wahl unterstützen. Und alle anderen möchte ich zumindest anregen, mal darüber nachzudenken, ob es nicht auch anders geht.
 Genau mein Reden!
Korrekt, die Präsi ist nicht 90 Minuten lang. Aber aus eigener Erfahrung kann ich dir sagen, dass du dich definitiv um die Aufmerksamkeit der Prüfer sorgen solltest. Nach 8 Stunden Präsentationseinheitsbrei an einem vollen Prüfungstag geht die Aufmerksamkeit ganz sicher deutlich nach unten. Denn die Prüfer sind ja auch nur Menschen.

Ich behaupte, hier fehlt gerade einiges an Kontext.
Um Präsentationen halten zu üben sollten wir auch mal eine Präsentation über ein Hobby oder ähnliches halten.
Wenn das Thema eher locker ist, ist sowas kein Problem. Aber man hält ja eher keine wichtige Präsentation über ein IT-Projekt und setzt Bilder von Joda auf die Folien.
Kaum Text ist ok. Du sollst präsentieren und nicht vorlesen. Lustige Bildchen, siehe oben. Manchmal passt es auch, wenn man es als Sprecher rüberbringen kann - in einer Prüfung würde ich das aber nicht ausprobieren.

Denk nichtmal dran soetwas zu tun.

Das sehe ich nicht so. Ein Buch beantwortet dir keine Fragen.
Sorry, aber leider kann ich nicht nachvollziehen, wie du aus dem Auslesen einer CSV-Datei einen solchen Elefanten machst.
Gerade am Anfang der Programmierung ist es normal, dass man keinen 100% Clean Code schreibt und alle möglichen Softwarepatterns versteht und anwendet.

Meine ersten Programme in Delphi, wenn ich daran denke, schaudert es mir. Aber ich habe es auf die Beine gestellt bekommen. Auch wenn ich von OOP noch nie gehört habe und die Logik in die Forms geklatscht habe.
Wenn man aber das Interesse und die Leidenschaft mitbringt, werden aus diesen anfänglich hässlichen Programmen, immer bessere. Vielleicht fängt man dann an das MVC-Pattern anzuwenden oder beschäftigt sich mit Polymorphie und Kapselung. Du überflutest Tician hier mit Begriffen und Techniken, die einige erfahrene Programmierer in meiner Firma nicht mal zu hören bekommen haben. Sei doch nicht so streng mit jemanden der gerade am Anfang steht.
 

Despektierliche Fragen:
Deine Kinder sind kein Hinderungsgrund für einen 8h (und mehr) Tag? Sie sind (auch bei Krankheit oder dem klassischen "ich habe mir auf dem Schulhof das Knie aufgeschlagen" versorgt)? Hast du schon mal über ein vorbereitendes Praktikum nachgedacht? Warum erst 2018 und nicht jetzt gleich durchstarten?

Ich habe dich so verstanden, dass genau diese Alternativen in meinem Antrag fehlen.
 
Es kommt doch jetzt im Fett geschriebenen deutlich zur Geltung, welche Möglichkeiten es gibt und warum ich das eine und nicht das andere benutzen möchte.
 
 
lt. IHK Handreichung zur Durchführung der Projektarbeit (Quelle: IHK Handreichung)
"Für die Genehmigung muss der Umfang der einzelnen Abläufe klar erkennbar sein. Die Einzelheiten/Besonderheiten der Problemstellung bzw. -lösung sollten besonders im Antrag herausgearbeitet werden"
Hier ist ja der Umfang erkennbar und Einzelheiten (bspw. finanzielles Kontingent)
 
Oder wie meinst du das?
 
 
Ich bin nach wie vor für weiteres Feedback dankbar

Wieso sollte man dich töten wollen?
Softwareentwicklung ist nun mal ein Reifeprozess. Niemand liest nur ein Buch und kann gleich wunderbar sauberen Code schreiben. Mein Code sah zum Anfang auch mies aus und selbst Robert C. Martin, der das Buch "Clean Code" geschrieben hat, sagt von sich aus, dass er nicht die Weisheit mit Löffeln gefressen hat und es auch bei seinen Code-Beispielen sicherlich noch Verbesserungspotenzial gibt aber nur durch Ausprobieren lernt man. 
Du hast schon richtig erkannt, dass man fürs Einlesen der Datei eine eigene Klasse benötigt. Allerdings gehört die Logik nicht in den Konstruktor. Der Konstruktor dient zur Initialisierung der Klasse. Der Name der Klasse sollte auch die Aufgabe widerspiegeln, was die Klasse tut. "DateiEinlesen" ist vielleicht gut, aber geht es vielleicht noch konkreter? Ich weiß, dass es eine CSV-Datei ist. Vielleicht eher CsvReader?  Wobei dieser Name auch wieder sehr allgemein ist. In der CSV-Datei steckt ja eine Tabelle. Welche Daten besitzt die Tabelle? Vielleicht kann man der Tabelle einen Namen geben. Eine CSV-Datei ist ja eine Art der Serialisierung. Das Verfahrung um so eine Tabelle in ein Objekt zu überführen, nennt man auch Deserialiserung. Das kann man ja erst mal im Hinterkopf behalten.
Zuerst würde ich mir aber erst mal eine geeignete Datenstruktur überlegen. In der CSV-Datei stecken ja Daten. Ich nehme jetzt mal als Beispiel, dass die CSV-Datei Daten zu Personen beinhaltet:
Name;Vorname;Geschlecht;Alter Doe;John;Maennlich;38 Also würde ich erst mal eine Klasse für diese Daten erstellen:
public class Person {     public string Name { get; set; }     public string Vorname { get; set; }     public Geschlecht Geschlecht { get; set; }     public int Alter { get; set; } } public enum Geschlecht {     Maennlich     , Weiblich } Nun könnte ich mich darum kümmern, eine(!) Datei einzulesen. Ich habe eine Datenstruktur und ich weiß, dass ich eine CSV-Datei deserialisieren muss. Also könnte man die Klasse z.B. PersonCsvDeserializer nennen. In dieser Klasse soll es eine Methode geben, die Deserialize() heißt. Ich verzichte hier jetzt erst mal bewusst auf ein Interface, weil ich denke, dass es für dich bis hier hin schon kompliziert genug ist. Das Interface werde ich später noch mal erklären. Erst mal kümmern wir uns darum, was wir alles brauchen, um eine Datei zu deserialisieren. 
Was muss die Klasse PersonCsvDeserializer alles wissen, um eine CSV-Datei deserialisieren zu können? Man könnte vielleicht im ersten Schritt auf die Idee kommen, dass die Klasse den Pfad und Dateinamen benötigt. Mit den Informationen aus dem letzten Absatz könnte ein erster Entwurf so aussehen: 
public class PersonCsvDeserializer {     public IEnumerable<Person> Deserialize(string fileName)     {       // ...     } } Als Rückgabewert habe ich IEnumerable<Person> gewählt, weil IEnumerable<T> ein sehr allgemeines Interface ist und einen Enumerator (auf deutsch: Aufzählung; in anderen Sprachen auch Iterator genannt) zur Verfügung stellt, mit dem wir über die Daten iterieren können (mit der foreach-Schleife). Sowohl IList<T>, ICollection<T>, IDictionary<T>, Array und weitere Klassen implementieren dieses Interface und mehr als über die Daten iterieren wollen wir nicht. Wenn wir später damit mehr machen wollen, können wir es leicht mit Linq in eine Collection, List, Array oder auch in ein Dictionary umwandeln. Die Deserialize()-Methode soll also eine Aufzählung von Personen zurückliefern.
Normalerweise macht man es anders, aber aus einfachheit behaupte ich mal frech, dass die erste Zeile in der CSV-Datei immer ein Header besitzt. In der Implementierung überspringe ich den Header per Linq mit der Skip()-Methode. Die Deserialize()-Methode soll also folgendes machen:
Die Datei lesen Durch die Datenzeilen iterieren Pro Datenzeile ein Person-Objekt erstellen Die Person-Objekte als Aufzählung zurückliefern Der erste Entwurf könnte daher folgendermaßen aussehen:
public class PersonCsvDeserializer {     public IEnumerable<Person> Deserialize(string fileName)     {         IList<Person> result = new List<Person>();         foreach (string line in File.ReadAllLines(fileName).Skip(1))         {             string[] elements = line.Split(';');             result.Add(new Person             {                 Name = elements[0],                 Vorname = elements[1],                 Geschlecht = (Geschlecht)Enum.Parse(typeof(Geschlecht), elements[2]),                 Alter = Convert.ToInt32(elements[3])             });         }         return result;     } } Die Methode macht zwar was sie soll, aber ist sie wirklich übersichtlich? Nicht wirklich. Wir haben hier mehrere Ebenen miteinander vermischt. Wir können also mit dem Refactoring anfangen. z.B. das
File.ReadAllLines(fileName).Skip(1) Wofür ist das genau gut? Wenn man den gesamten Kontext kennt, weiß man es zwar aber eigentlich liegt der Code-Abschnitt eine Ebene Tiefer. Es hantiert mit Dateien und hat mit der eigentlichen Aufgabe der Deserialiserung wenig zu tun. Also sollte man diesen Teil in eine separate Methode packen:
private IEnumerable<string> ReadDataFromFile(string fileName) {     return File.ReadAllLines(fileName).Skip(1); } Somit wandert das Skip(1) in eine tiefere Ebene und interessiert uns in der Deserialize()-Methode nicht mehr. Als nächstes fällt aber auf, dass wir ein String mit Split() in ein Array teilen und aus diesem Array dann die einzelnen Personendaten herausfischen. Diesen Vorgang nennt man auch Parsing. Also könnten wir diesen Teil auch in eine Methode auslagern:
private Person Parse(string serializedData) {     string[] elements = serializedData.Split(';');     return new Person     {         Name = elements[0],         Vorname = elements[1],         Geschlecht = (Geschlecht)Enum.Parse(typeof(Geschlecht), elements[2]),         Alter = Convert.ToInt32(elements[3])     }; } Unsere Klasse sieht dann bis jetzt folgendermaßen aus: 
public class PersonCsvDeserializer {     public IEnumerable<Person> Deserialize(string fileName)     {         IList<Person> result = new List<Person>();         foreach (string serializedData in ReadDataFromFile(fileName))         {             Person person = this.Parse(serializedData);             result.Add(person);         }         return result;     }     private IEnumerable<string> ReadDataFromFile(string fileName)     {         return File.ReadAllLines(fileName).Skip(1);     }     private Person Parse(string serializedData)     {         string[] elements = serializedData.Split(';');         return new Person         {             Name = elements[0],             Vorname = elements[1],             Geschlecht = (Geschlecht)Enum.Parse(typeof(Geschlecht), elements[2]),             Alter = Convert.ToInt32(elements[3])         };     } } Nun ist Deserialize() doch recht gut lesbar. Wir lesen die Daten aus der Datei, parsen die Daten und erhalten ein Person-Objekt, welches wir dann in eine Liste packen und zum Schluss geben wir die Liste zurück.
Es gäbe hier noch weiteres Verbesserungspotenzial aber ich belasse es erst mal hierbei. Ein paar Hinweise gebe ich aber noch:
Fehler-Handling? Was passiert, wenn z.B. die Datei nicht existiert? Ist das erzeugte Objekt List<Person> wirklich eine gute Wahl? Angenommen, wir haben es mit einer riesigen CSV-Datei (mehrere Gigabytes) zu tun, die größer ist, als unser Arbeitsspeicher. Hier schmeiße ich mal das "yield return"-Schlüsselwort in den Raum. Auch ist das indexierte Zugreifen auf das Array in der Methode Parse() nicht wirklich glücklich gelöst. Was passiert nämlich, wenn mal eine Spalte in der Datei hinzukommt? Dann muss man ja auch den Code anpassen. Das will man aber eigentlich gar nicht. Zu diskutieren wäre auch, ob die Variable fileName nicht doch besser eine Instanzvariable sein sollte, die per Konstruktor reingereicht wird. Es fällt ja auf, dass die Methoden Deserialize() und ReadDataFromFile() den Dateinamen benötigen. Also stellt fileName ja eine gewisse Abhängigkeit dar, die die Klasse benötigt, um arbeiten zu können.  Als Überlegung kannst du ja selber mal schauen, wie man mit solchen Situation umgehst.
Um später im Hauptpgramm alle Personen zu iterieren könntest du nun folgendes schreiben:
static void Main(string[] args) {     string sourcePath = Environment.GetFolderPath(Environment.SpecialFolder.Desktop) + "\\blabla";     IEnumerable<string> fileNames = Directory.GetFiles(rootPath, "*.csv");     PersonCsvDeserializer deserializer = new PersonCsvDeserializer();     foreach(string fileName in fileNames)     {         IEnumerable<Person> persons = deserializer.Deserialize(fileName);         foreach (Person person in persons)         {             // ...         }     } } Nach dem selben Prinzip, wie bei der PersonCsvDeserializer-Klasse kannst du ja mal überlegen, wie man nun diesen Code refactoren an.
Ab hier wird es noch etwas technischer und tiefgreifender. Ich möchte dir noch zwei Techniken zeigen, die du aber erst mal nicht umsetzen brauchst.
"Inversion of Control" und "Dependeny Injection"
In der Klasse PersonCsvDeserializer fällt auf, dass die Klasse von einer Datei abhängig ist aber die Daten können vielleicht aus einer Datenbank kommen oder wir schreiben die CSV-Daten direkt in eine grafische Oberfläche. Möchte man jetzt für jeden Anwendungsfall eine eigene Klasse schreiben? Eigentlich nicht. Die Abhängigkeit zur Datei muss also aufgelöst werden. Das .Net-Framework bietet ja die abstrakte Klasse TextReader, die so ziemlich alles darstellen kann. Ein Reader, der eine Datei liest oder aus einem TCP-Stream oder aus einer Datenbank, etc. Anstatt also den Dateinamen reinzureichen, könnte man auch ein TextReader reinreichen.
Hier mal ein Beispiel, wie so eine Klasse aussehen könnte:
public class PersonCsvDeserializer {     private TextReader reader;     private bool isHeaderSkipped;     public PersonCsvDeserializer(TextReader reader)     {         this.reader = reader;     }     public IEnumerable<Person> Deserialize()     {         string serializedData;         while ((serializedData = this.ReadNextData()) != null)         {             Person person = this.Parse(serializedData);             yield return person;         }     }     private string ReadNextData()     {         string serializedData = this.reader.ReadLine();         if (!this.isHeaderSkipped)         {             this.isHeaderSkipped = true;             return this.ReadNextData();         }         return serializedData;     }     private Person Parse(string serializedData)     {         string[] elements = serializedData.Split(';');         return new Person         {             Name = elements[0],             Vorname = elements[1],             Geschlecht = (Geschlecht)Enum.Parse(typeof(Geschlecht), elements[2]),             Alter = Convert.ToInt32(elements[3])         };     } } Die Main-Methode sieht dann so aus:
static void Main(string[] args) {     string sourcePath = Environment.GetFolderPath(Environment.SpecialFolder.Desktop) + "\\blabla";     IEnumerable<string> fileNames = Directory.GetFiles(rootPath, "*.csv");          foreach(string fileName in fileNames)     {         using (TextReader reader = File.OpenText(fileName))         {             PersonCsvDeserializer deserializer = new PersonCsvDeserializer(reader);                          IEnumerable<Person> persons = deserializer.Deserialize();             foreach (Person person in persons)             {                 // ...             }         }       } } Zugegeben, in diesem Beispiel ist die Klasse PersonCsvDeserializer etwas komplizierter geworden aber es ist jetzt egal, woher die Daten stammen, solange wir ein TextReader in den Konstruktor schieben. Das reinrechen der Abhängigkeit in den Konstruktor nennt sich auch "Dependeny Injection". In diesem Beispiel habe ich auch das yield return verwendet. Da wir jetzt nur noch maximal den Speicher für ein Person-Objekt verbrauchen, könnte die Klasse eigentlich nun unendlich viele Daten deserialisieren. Ein Problem stellt aber immer noch die Indexierung des Arrays dar aber das überlasse ich jetzt dir.
Das Interface
Das letzte, was ich noch schreiben wollte, wäre ein geeignetes Interface für den Deserializer. Wollen wir jetzt mehrere Deserializer schreiben oder einen Deserializer als Abhängigkeit in eine Klasse reinreichen, ist ein Interface geeignet, damit es später egal ist, um welchen Deserializer es sich handelt. Man könnte sich ja auch vorstellen, dass die Daten nicht in einer CSV-Datei stecken, sondern in einer XML-Datei. Dafür wäre folgendes Interface recht nützlich
public interface IDeserializer<T> {     IEnumerable<T> Deserialize(); } Mit diesem Interface könnten wir sogar das hässliche using im Hauptprogramm wieder loswerden. Ich finde, das using stört im Lesefluss. Wir haben ja jetzt eine Klasse, die CSV-Daten aus unterschiedlichsten Quellen von Personen deserialisieren kann. Was hindert uns nun daran, einen weiteren Deserializer zu bauen, der aus Dateien deserialisiert? Beispiel:
public class PersonCsvFileDeserializer : IDeserializer<Person> {     private string fileName;     public PersonCsvFileDeserializer(string fileName)      {         this.fileName = fileName;     }     public IEnumerable<Person> Deserialize()     {         using (TextReader reader = File.OpenText(fileName))         {             PersonCsvDeserializer deserializer = new PersonCsvDeserializer(reader);             return deserializer.Deserialize();         }     } } Das using wurde nach PersonCsvFileDeserializer und somit eine ebene tiefer verschoben. Wenn du Dependecy Injection verstanden hast, dann würde dir auffallen, dass die Zeile 
PersonCsvDeserializer deserializer = new PersonCsvDeserializer(reader); eigentlich böse ist, da es eine Abhängigkeit darstellt, die wiederum in den Konstruktor gehört. Ich habe sie aber erst mal hier drinnengelassen, weil das sonst wieder bedeuten würde, dass das using wieder ins Hauptprogramm rein müsste. Eigentlich müsste man sich eine Fabrik-Methode ausdenken, die den PersonCsvFileDeserializer zusammenbaut. Die habe ich hier aber weggelassen. Die kannst du dir ja ausdenken.
Das Hauptprogramm würde dann so aussehen:
static void Main(string[] args) {     string sourcePath = Environment.GetFolderPath(Environment.SpecialFolder.Desktop) + "\\blabla";     IEnumerable<string> fileNames = Directory.GetFiles(rootPath, "*.csv");          foreach(string fileName in fileNames)     {         PersonCsvFileDeserializer deserializer = new PersonCsvFileDeserializer(fileName);                      IEnumerable<Person> persons = deserializer.Deserialize();         foreach (Person person in persons)         {             // ...         }      } } Das wäre doch schon wieder ein Schritt übersichtlicher. 
Wie du also siehst, haben wir allein nur für das Einlesen von den CSV-Dateien drei Klassen:
Person PersonCsvDeserializer PersonCsvFileDeserializer und ein Interface:
IDeserializer<T> geschrieben. Man braucht also kein mega großes Projekt, um mehrere Klassen zu schreiben. Es reicht auch schon was ganz einfaches. Man sollte sich immer bewusst machen, dass Klassen immer nur eine Aufgabe machen sollten und Methoden Teilaspekte dieser Aufgabe sind und sie sollten auch nicht mehr machen, als eine Sache. Es macht auch nichts, wenn man zum Anfang Spagetticode schreibt und diesen später nach und nach einem Refactoring unterzieht. Niemand ist perfekt und niemand schreibt perfekten Code. Man fängt also immer erst mal an und arbeitet sich Schritt für Schritt an eine geeignete und saubere Lösung. Selbst meine Lösung ist mit Sicherheit nicht perfekt und ich habe auch nicht die Weisheit mit Löffeln gefressen. Wenn du mein Beitrag richtig verfolgt haben solltest, hast du vielleicht auch gemerkt, dass ich erst mal eine Lösung geschrieben habe und sie dann nach und nach verfeinert und verbessert habe. Das Wissen kommt erst mit Erfahrung und Erfahrung sammelt man nur, indem man es ausprobiert und darüber mit anderen diskutiert. Also trau dich.
So, das reicht auch fürs erste. Ich denke, das ist erst mal genug Input.
 

Die *.pdb-Datei erzeugt keine Datei. Sie dient lediglich dazu, mehr Debug-Informationen zu bekommen. Beispiel:
static void Main(string[] args) { try { throw new NullReferenceException(); } catch (Exception e) { Console.WriteLine(e); } finally { Console.ReadKey(); } } Wenn ich jetzt das Programm ausführe, erhalte ich folgende Nachricht in der Konsole:
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt. bei ConsoleApplication3.Program.Main(String[] args) in d:\dokumente\visual studio 2015\Projects\ConsoleApplication3\ConsoleApplication3\Program.cs:Zeile 16. Ich kann also sehen, dass die Exception in Zeile 16 in der Datei Program.cs geworfen wurde und die Zeile ist folgende:
throw new NullReferenceException(); Auch sollte man die Meldung der Exception verstehen. Die obere Zeile ist die Art der Exception mit einer optionalen Nachricht. Der Teil:
bei ConsoleApplication3.Program.Main(String[] args) Sagt, wo die Exception ausgelöst wurde und der Teil:
in d:\dokumente\visual studio 2015\Projects\ConsoleApplication3\ConsoleApplication3\Program.cs:Zeile 16. Ist der Stacktrace. Der Stacktrace kann noch deutlich länger werden, je nach dem wie viele Ebenen der Code absteigt und wieder raufklettern muss, um die Exception zu fangen.
Wenn ich jetzt aber die *.pdb-Datei lösche und das Programm starte, erhalte ich nur folgende Meldung:
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt. bei ConsoleApplication3.Program.Main(String[] args) Ich sehe also nicht mehr, wo die Exception geworfen wurde, sondern lediglich nur noch die Methode, wo sie ausgelöst wird.
Für dich ist also erst mal der Stacktrace wichtig, um zu wissen, wo überhaupt die Exception aufgetreten ist. Das spart auch schon vieles an Rätselraten. Wenn man die Stelle dann kennt, kann man sich überlegen, was eigentlich passiert ist. Ohne den Stacktrace zu kennen, wird das Debugging sehr schwer.

Das hängt sehr stark vom Unternehmen ab. Eine Pauschalantwort ist denke ich schwer möglich.
Grundsätzlich ist es aber so, dass ein Studium mit Sicherheit nicht schadet. Es mag den Ein oder Anderen Abteilungsleister ohne Studium geben, aber diese dürften klar in der Unterzahl sein. Aber auch das hängt vom jeweiligen Unternehmen ab.
Da wären wir dann übrigens bei der eigentlich relevanten Frage:
Möchtest Du den Posten als solches (egal in welchem Unternehmen), oder den Posten genau in Deinem Unternehmen?
Abhängig davon muss man - wie ich finde - unterschiedlich an die Sache heran gehen.

Hm... Ehrlich gesagt bin ich mir nicht sicher, ob Du Dir im Klaren bist, was IT als Beruf bedeutet.
Mit Programme bedienen und Kollegen den PC aufbauen hat das - abseits des 1st und 2nd Level Supports - nur wenig zu tun.
Als FIAE programmierst / entwickelst oder pflegst Du Individualsoftware. D.h. hier ist Coden angesagt.
Als FISI gehst Du hin und setzt Server auf, verwaltest Domänen, Netzwerke, SAN, etc. pp.
Projektmanagement hast Du ausgeschlossen.
Wenn man bedenkt, dass Du bereits 1, 2 Stufen auf der Karriereleiter geklettert bist, klingt das für mich nur so semi ausgegoren um ehrlich zu sein. Sowohl als FIAE wie auch als FISI würdest Du wieder klein anfangen. Gehalts- und Verantwortungsmäßig. Selbst als Studierter Informatiker. Von der Durststrecke während Ausbildung und/oder Studium ganz zu schweigen.
...
Ich kann und möchte Dir das nicht ausreden, aber ich würde versuchen, es hinzukriegen, dass Du es mit Deinem jetzigen Beruf vereinbaren kannst. Dann hättest Du eine Fallback-Lösung, falls die IT doch nich das Wahre für Dich sein sollte.
Kannst Du versuchen, Dir das Programm oder Aufsetzen von Servern im Eigenstudium beizubringen? Hast Du im Betrieb die Möglichkeit, sowas zu machen? Oder im privaten Umfeld?
...
Ganz davon ab: Was verdienst Du zur Zeit und wo möchtest Du finanziell einmal stehen?
Ist auch ein nicht ganz unwesentlicher Faktor, wenn man sich mit Ü30 neu orientieren möchte.

Hi Marc,
ganz generell:
Die ein oder andere Formulierung ist schon sehr Standard.
Klingt viel nach "schreibt man so" und wenig "nach Dir".
Hinzu kommen viele Füllwörter und dass Du Schwerpunkte falsch setzt.
Aber ich schreibe Dir gleich ne PN.
Da kann ich mehr ins Detail gehen, wie hier im Fred.

Exakt, wir lernen es, weswegen die Ausssage hier auch nichts zu suchen hat, das ich es nicht anwenden kann ist mein Problem
Du beziehst dich nur auf FIAE'ler, aber was denkst du erwartet man programmiertechnisch von einem FISI wie mir später?
Kein Lehrer und auch keine Schule ist perfekt, man muss sich anpassen und wenn ich etwas nicht verstehe frage ich meinen Ausbilder oder belese mich in Büchern oder über google.

Wie schon so oft muss ich leider wieder dagegen halten: Kaufmännische Inhalte sind Kernbestandteil der Ausbildung zum Fachinformatiker für Anwendungsentwicklung (und auch aller anderen IT-Berufe). Auch wenn viele Forenteilnehmer das (warum auch immer) nicht wahrhaben wollen. Ob die Gewichtung sinnvoll ist, darüber lässt sich sicherlich streiten.
Welche Aussagekraft fehlt dir denn hier? Die Botschaft ist: Das Projekt amortisiert sich nach einiger Zeit und führt langfristig zu einer Kosteneinsparung im Unternehmen. Das ist doch genau die richtige Aussage, wenn die Entwicklerin in Zukunft noch ein Gehalt erwartet.
Da hast du völlig recht. Ich hätte am liebsten auch zu jedem technischen Detail etwas gelesen, aber da die Abschlussarbeit (bei unserer IHK) auf 15 Seiten beschränkt ist, war dafür leider kein Platz. In einer Bachelor- oder Masterarbeit kann man sich bestimmt intensiv mit solchen Inhalten auseinandersetzen, aber für die Projektdoku muss man einfach Abstriche machen und eine sinnvolle Auwahl der Themen treffen.
 
Dein gelungener Rant über die schlechte Ausbildung der Anwendungsentwickler ist ansonsten nett zu lesen. Allerdings ist die Berufsschule sehrwohl dafür da, die Prüflinge auf die Prüfung vorzubereiten. Clean Code mit DDD und Tests wird dann hoffentlich in den Ausbildungsunternehmen vermittelt. Dort findet der Praxisteil der Ausbildung statt.
Dass Berufsschulen im Adaptieren neuer Konzepte nicht die schnellsten sind, ist sicherlich ein Problem. Aber auf der anderen Seite müssen die Schulen auch einer Vielzahl an Schülern mit unterschiedlichem Vorwissen Grundlagen der Programmierung beibringen. Und da kann es halt ein paar Wochen dauern, bis for und if durchgekaut sind. Dass die Azubis dafür u.a. Struktogramme oder Pseudocode lernen, liegt hauptsächlich daran, dass es nicht die eine Programmiersprache gibt, die alle Azubis können müssen und die dann in der Prüfung abgefragt wird. Aber das haben wir an anderer Stelle schon ausgiebig diskutiert.
Insgesamt solltest du deine Anforderungen an die Berufsschulausbildung vielleicht etwas zurückfahren. Man sollte von einer Ausbildung nicht die gleichen Inhalte erwarten, wie von einem Studium. Wobei auch bei letzterem in den meisten Fällen DDD und Unit-Tests sicherlich kein Lehrinhalt sind. Dort wird doch teilweise noch länger der alte Kram durchgekaut. Aber das möchte ich jetzt nicht weiter vertiefen
Ich halte es auch für sehr schwierig, Lerninhalte an aktuelle Entwicklungen in der IT anzupassen. Nehmen wir mal DDD als Beispiel: Das Konzept ist schon relativ alt (Eric Evans Buch ist von 2003), aber richtig Fahrt aufgenommen hat es erst in den letzten Jahren durch Microservices usw. Wer hätte das vorhersehen und vor 5 Jahren einen entsprechenden Lehrplan aufstellen können, der heute zeitgemäß ist? Und wer sagt überhaupt, dass DDD die "richtige" Art zu programmieren ist? Was ist mit den tausenden anderen Konzepten und Ideen der Softwareentwicklung? Würdest du bei einem Automobilzulieferer C-Code nach DDD entwickeln? Huch, C kennt ja nichtmal Objektorientierung! Da muss dann wohl doch eine andere Lösung her.
Ich habe ein wenig den Eindruck, dass du deine eigenen Erfahrungen und Qualitätsstandards auf alle anderen Entwickler überträgst. Doch da die Programmiersprachen, Anforderungen, Paradigmen usw. da draußen so unterschiedlich sind, geht das leider nicht. Ein (ernstgemeinter) Ratschlag: Frag deine IHK, ob sie noch Prüfer braucht! Mit deinem Engagement bist du in der Rolle genau richtig. Dann bekommst du aber auch mal einen Einblick in die Realität vieler Betriebe da draußen und entschärfst deine Meinung vielleicht etwas. Clean Code ist ein super Konzept. Genau wie Unit-Tests und Pair Programming. Aber wenn du dich da draußen mal umschaust, wirst du feststellen, dass nur ein Bruchteil der Unternehmen diese Ideen tatsächlich umsetzt.
Mir fällt es jedenfalls nicht schwer, nachzuvollziehen, warum die Objektorientierung immer noch das vorherrschende Paradigma in der IHK-Prüfung ist (und sicherlich auch in normalen IT-Studiengängen). Man setzt halt auf bewährte grundlegende Konzepte. Die konkrete Ausgestaltung und Ausschmückung mit Frameworks, Architekturideen, Sprachfeatures usw. obliegt dann den Ausbildungsbetrieben, die passend zu ihrer Sprache und Branche die Inhalte auswählen. Und auch da wird nicht immer der neuste Kram eingesetzt, sondern sehr oft auch uralte Sprachen und Frameworks. Denn das Update auf v2.0 oder den Rewrite in Haskell bezahlt den Unternehmen leider meistens kein Kunde...

Klasse Beitrag Whiz-zarD, dem ich größtenteils erfahrungsgemäß (welches sich auf ca. 2,5 Jahre Berufsausbildung beschränkt) zustimmen kann.

Schon am Anfang hatte ich mit meinem Ausbilder ein Gespräch über den Rahmenlehrplan, wo er mir auch schnell mitgeteilt hat, dass er seit Jahren mit dem Bundesministerium für Bildung im Gespräch steht und versucht denen mitzuteilen, dass die Ausbildungsordnung einfach veraltet und nicht mehr zeitgemäß ist. Da ich selbst im öffentlichen Dienst arbeite, weiß ich aber wie lang sich solche Prozesse ziehen können, bis letztendlich etwas verändert wird.
Berufsschultechnisch denke ich mit gemischten Gefühlen zurück. Wir hatten durchaus einige Lehrer, die es drauf hatten. Einer davon saß schon seit längerer Zeit im Prüfungssausschuss und hat uns optimal auf die Prüfungen vorbereitet und trotzdem hilfreichen und guten Unterricht gemacht.
Wenn man dann aber in Netzwerktechnik hingesetzt wird und gesagt wird "Öffnet mal Wireshark und analysiert die Pakete" ohne wirkliche Aufgabe ist es auch nicht zielführend.
Grundsätzlich lässt sich aber als Anwendungsentwickler sagen, dass die im Berufsschulunterricht vermittelten Programmiertechniken nicht den heutigen Standard entsprechen und erst recht nicht sauberer Programmierung. Uns wurde zwar das Mehrschichtenmodell oder UML-Diagramme beigebracht, aber dann wurde im nächsten Zug in die View Programmierlogik eingehakt. Das ist durchaus verbesserungswürdig.

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.

Ich glaube da wurden die Begriffe Datensicherheit und Datenschutz von Tician durcheinandergebracht.

Ich glaube da wurden die Begriffe Datensicherheit und Datenschutz von Tician durcheinandergebracht.