Whiz-zarD

Mmh, okay. Ich bin eher davon ausgegangen, dass er den string noch weiter analysieren wollte.

Das kann man vielleicht mit einem FISI machen, aber bei einem FIAE würde ich das nicht unbedingt tun. Auf unsere Software würde ich ihn nicht gleich loslassen. Schon gar nicht, wenn er nur wenig bis gar keine Programmierkenntnisse hat. Das wird ihn nur versauen, weil die Software echt gruselig entwickelt wurde und so gegen alle best practices verstößt, die man sich so vorstellen kann. Ich bin zwar kein Ausbilder aber bei einem FIAEler würde ich tatsächlich erst mal mit etwas spielerischem Anfangen, wie z.B. ein Sudoku-Löser oder ein Taschenrechner (ein guter Taschenrechner ist gar nicht mal so simpel) oder ein paar Coding-Katas und ihm dabei auch ein paar grundlegende Dinge beibringen, wie z.B. Variablentypen und die Probleme bei Fließkomma-Operationen und wie man ein Geldbetrag abbilden sollte, dann Design Patterns, Unittests etc. und erst dann, wenn er es so einigermaßen drauf hat, kann man ihn ja mal ein paar leichte Aufgaben aus dem Tagesgeschäft geben und ihn dann weiter betreuen.

Dein Code ist schon recht komplex. Ein Problem hierbei ist schon, dass NewLine-Steuerkommando Systemabhängig ist. Unter Windows \r\n ist standardmäßig und unter Linux ist der Standard \n. Das lässt sich aber konfigurieren. Das .Net-Framework bietet hierzu die Enviroment.NewLine Konstante, die das aktuelle Newline-Kommando zurückliefert. Ich würde im ersten Schritt alle Text-Steuerkommandos entfernen: s = Regex.Replace(s, @"\t|\n|\r", " "); Dann würde ich den String in ein Array aufteilen: var array1 = s.Split(new[] { ' ' }, StringSplitOptions.RemoveEmptyEntries); Dann würde ich die beiden relevanten Ergebnisse extrahieren: var s2 = s1.Skip(Array.FindIndex(s1, x => x.ToLower() == "blato:") + 1).Take(2); und zum Schluss würde ich dann die Ergebnisse in ein String joinen: var result = string.Join(" ", s2); Und schon hat man mit vier Zeilen Code das Ergebnis und das ohne großartig reguläre Ausdrücke zu benutzen. Ich versuche sowieso reguläre Ausdrücke zu meiden, weil diese eh keine Sau versteht. Der gesamte Code: s = Regex.Replace(s, @"\t|\n|\r", " "); var s1 = s.Split(new[] { ' ' }, StringSplitOptions.RemoveEmptyEntries); var s2 = s1.Skip(Array.FindIndex(s1, x => x.ToLower() == "blato:") + 1).Take(2); var result = string.Join(" ", s2); Ist jetzt von der Variablenbenennung beschissen, aber ich hoffe, du kannst damit was anfangen.

Klingt nach einem anderen Fehler. Die Funktion date_create_from_format() gibt dir ein Objekt zurück und kein String. Offenbar behandelst du irgendwo das Objekt als String und dann kommt es zur dieser Fehlermeldung. Bei der Ausgabe muss du die Format()-Funktion aus dem DateTime-Objekt benutzen. z.B. echo $datum->format('Y-m-d H:i:s')

PDF-Dateien kann man auch so ohne weiteres nicht auslesen. Das ist ein recht komplexes Dateiformat mit einer eigenen Syntax zur Textgestaltung. Hier ist eine recht gute Übersicht, was die das Format funktioniert. Daher würde ich dir schon raten, eine Bibliothek dafür zu nehmen. Wir selbst erstellen nur Listen als PDF-Datei aber dafür verwenden wir List&Label von Combit. Das Tool ist aber nicht kostenlos. Ansonsten hast du ja schon einige Biblitoheken genannt, die du verwenden könntest. Etwas eigenes zu schreiben halte ich für zu fehleranfällig.

Es wird ein Zeitplan auf Stundenebene erwartet und das spricht gegen die agile Entwicklung. Diese Zeitangaben ist auch eine einzige Mogelpackung, denn wer kontrolliert es und wer kann sich daran halten?

TDD heißt nicht gleich, dass Agil gearbeitet wird. Agile Softwareentwicklung ist noch was anderes. Schaut man sich das "Agile Manifesto" an, so findet man folgende Leitsätze (kopiert aus Wikipedia): Menschen und Interaktionen stehen über Prozessen und Werkzeugen Funktionierende Software steht über einer umfassenden Dokumentation Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung Reagieren auf Veränderung steht über dem Befolgen eines Plans Und das widerspricht so allem, was die IHK von der Abschlussprüfung erwartet. Aber gut, da rege ich mich schon seit über 10 Jahren auf. Als ich damals meine Mechatroniker-Ausbildung absolviert hatte, musste ich sogar noch auf die Uhrzeit genau angeben, was ich mache ... Da ist es schon ein großer Fortschritt, dass man nur noch die Stunden angeben muss. Kanban muss aber auch nicht unbedingt agil sein. wenn z.B. bei Kanban nicht mit dem Kunden geredet wird, sondern stur die Aufgaben von "Bereit" bis "Fertig" abgearbeitet werden, haben wir hier ebenfalls ein Wasserfallmodell.

Eine kleine Anekdote aus meinem Berufsleben: In der Software, an der ich arbeite, wurde damals in der Designphase (das war weit vor meiner Zeit) einen gravierenden Fehler gemacht und zwar hat man die Geschäftsobjekte direkt mit der Persistenzschicht verdrahtet. D.h. um ein Geschäftsobjekt erzeugen zu können, brauchst du zwingend eine Datenbankverbindung. Bei so einer Architektur im nachhinein Unittests zu schreiben ist unmöglich, da man anfangen müsste, die Datenbank zu mocken. Desweiteren wurde der Fehler gemacht, Geschäftslogik in die UI zu verlegen, weil das so schön einfach ist. Unter Visual Studio einfach ein Doppelklick auf dem Button im Designer und los gehts ... Schreibe aber mal dafür einen Unittest. Viel Spaß. Mit TDD umgeht man diese ganzen Probleme, weil man schon vornherein gezwungen wird, den Code so zu schreiben, sodass er auch Testbar ist. Ein weiteres Problem ist, wenn man die Unittests danach schreibt, dass man eigentlich nur noch die Schnittstellen nach außen testet und das reicht oft für ein Test nicht aus. Man sieht dann zwar, dass sich ein Ergebnis ändert hat, aber wo der neue Wert herkommt, sieht man nicht. Bei TDD geht es also darum, testbaren Code zu schreiben. Unittests Teste deine Klassen und die Methoden. Informiere dich mal über den Begriff "Testpyramide". Manuelle Tests gilt es zu vermeiden, weil die sehr zeitaufwendig sind und Zeit ist Geld. Hier in der Firma besteht der Regressionstest hauptsächlich aus manuellen Tests (die gründe stehen weiter oben) und der Test wird pro Major-Release mit 200 - 300 PT veranschlagt. Das ist enorm. Bei uns steht die Testpyramide auch auf dem Kopf und das ist das Worst-Case-Szenario. Manuelle Tests sind eigentlich nur noch UI-Tests und die testen nur noch den Workflow. Also dass z.B. wenn man auf Button X klickt auch Dialog Y auftaucht und dass Eingabefehler abgefangen wird aber auch diese Tests lassen sich automatisieren. Da gibt es genug Tools. Tests sollten immer durchgeführt werden, bevor es zum Kunden geht. Ansonsten hast du eine Bananen-Software: Reift beim Kunden. Aber ich persönlich sehe viele Probleme bei der Abschlussprüfung, wie die IHK es sich vorstellt. Das sind veraltete Methoden, die man heute nicht mehr anwenden sollte. Heutzutage versucht man den Kunden mit in die Entwicklung zu integrieren, sodass er für Fragen und Antworten bereitsteht und so kann man auch viel schneller auf Anpassungen reagieren (sprich agil arbeiten).

Hast du auf dem Server alle Fehlermeldungen aktiviert? Vielleicht tritt dort ein Fehler auf und du siehst es nur nicht. Aber noch ein Hinweis: Vermeide SELECT *, denn das gibt zu viele Informationen zurück und kann auch zu Problemen führen, wenn man weitere Tabellen gejoint hat, die wiederum Spalten besitzen, die den selben Namen haben. Gib immer explizit an, welche Spalten du haben willst. In diesem Fall hast du sogar zwei Tabellen gejoint, also gibt dir die Abfrage die Spalten von drei Tabellen zurück. Je nach Anzahl der Recordsets kann es durchaus zu Performanceproblemen kommen.

Unittests im Nachhinein zu entwickeln klappt meist auch nicht, da der Code dann der Code nicht testbar ist. TDD ist zwar anstrengend aber es ist durchaus hilfreich, denn TDD führt dich nicht in die Versuchung, den Code irgendwie hinzuhacken. Der Code bleibt dann immer testbar. Wenn man die Unittests erst hinterher schreiben will, hat man dann oft ein Code, der nur sehr schwer testbar ist. Dann testet man nur die Schnittstellen nach außen. Wenn aber dann ein Fehler auftauchen sollte, ist man da erst mal mit dem Suchen beschäftigt, wo der Fehler überhaupt herkommt und je nach Komplexität kann es sehr Zeitaufwendig sein. Ich kenne es auch eigener Erfahrung, dass man die Entwicklungskosten gerne niedrig halten möchte und daher gerne auf Unittests verzichtet werden, weil Unittests Geld kosten und von Unittests hat der Kunde nichts aber das Geld, was man hier investiert, spart man später bei der Pflege des Codes. Ich selber arbeite an einem unwartbaren Monstrum, wo die Entwickler an vielen Stellen im Code sich nicht rantrauen, weil sie nicht wissen, welche Seiteneffekte entstehen könnten, wenn sie was am Code ändern sollten. Der Analyseaufwand steigt somit ins unermessliche. Wenn aber schon vornherein dafür gesorgt wurde, dass vernünftige Unittests geschrieben worden sind, kann man bei Änderungen sehr schnell herausfinden, ob noch alles so läuft, wie vorher. Zeitdruck herrscht immer, denn Zeit ist Geld. Geld, was der Kunde nicht ausgeben will und ich weiß, dass es schwer sein kann, den Chef davon zu überzeugen, aber das ist einfach eine Milchmädchenrechnung, wenn man meint, dass man beim Sparen an Unittests grundsätzlich Geld spart, nur weil das Produkt schneller zum Kunden kommt. Die ganzen Bugs, die der Kunde meldet und der enorme Zeitanstieg bei der Beseitigung der Bugs oder bei der Implementierung von Weiterentwicklungen, sieht oft der Chef nicht. Also muss man ihn dies vor Augen führen, welche Folgekosten so etwas hat.

Das hast du so gut wie in jedem Beruf und dennoch spricht man nicht gerade von einem "kaufmännischen Teil". Ein Kaufmann ist schon ein bisschen mehr, als Kosten- und Nutzen abzuwiegen.

Such dir was aus und du hast deine Antwort... Also ist man sich eigentlich gar nicht im Klaren, was ein Anwendungsentwickler ist? Ich selber habe eine schulische Ausbildung zum "Assitent für Medieninformatik" und vor 16 Jahren eine Mechatroniker-Ausbildung absolviert und in beiden Berufen habe ich nichts über einen Kaufmann gelernt,

Was muss man denn als FIAEler für einen kaufmännischen Teil lernen? Was hat ein Entwickler mit einem Kaufmann zu tun? Außerdem das e-book vom Rheinwerk Verlag würde ich nicht unbedingt empfehlen. Es ist komplett veraltet und die Programmierbeispiele sind oft abschreckende Beispiele, wie man es nicht machen sollte.

So, wie ich das verstanden habe, will er das auch machen. Seine Frage ist wohl nur, ob und wie er es verkauft bekommen kann, irgendwas in Richtung "Medizin" zu machen, obwohl sein Arbeitgeber im Bereich "Musik" tätig ist.

Selbst dann nicht mal wirklich. Sie sollten über Interfaces kommunizieren.

Sowas ist schlechter Programmierstil, da du hier HTML und JavaScript miteinander vermischst. Auf der Webseite von Fancybox ist doch ein Beispiel, wie das funktioniert. (Die "Inline"-Beispiele) Was genau ist denn dein Problem? Wieso kannst du es denn nicht so umsetzen, wie im Beispiel?

Hallo, Ich persönlich würde auch die Finger von lassen, denn offenbar ist der Belegschaft nicht klar, welche Probleme herrschen. Wenn schon die Entwicklungsabteilung nicht mosert, dann ist da irgendwas im Busch. Da würde ich mich fragen, ob überhaupt das Know-how da ist, um geine neue Softwaregeneration einzuleiten? Wenn der Wille und das Know-how fehlt, dann bringt es auch nichts als Geschäftsführer auf den Tisch zu hauen, denn man stößt auf taube Ohren und dann wird das Schiff erst recht untergehen.

Das tatsächliche Einfügen ist weniger das Problem, wobei hier die Festplatte der Flaschenhals ist, wenn es sich nicht um eine In-Memory-Datenbank handelt. Das eigentliche Problem wird gerne viel vielen Übersehen: Das Parsen. Es ist zwar für uns nur ein String, aber für ein DBMS harte Arbeit. Das Statement muss geparst werden, damit das DBMS weiß was der Nutzer überhaupt will. Danach wird ein Ablaufplan erstellt, wie man das Statement am performantesten abarbeiten kann. Dabei werden dann u.a. Statistiken der Tabellen und Indizes gelesen und dann wird der Plan abgearbeitet. Bis es zu er tatsächlichen Abarbeitung kommt, wird sehr viel Zeit verbraten und jetzt stelle dir mal vor, das muss das DBMS bei jedem der Tausend Insert-Befehle ausführen. Da wird Tausend Mal immer das selbe gemacht. Gängige DBMS-Systeme können dieses Problem ein wenig kompensieren, indem sie ein Query-Cache implementiert haben, mit dem überprüft werden kann, ob die Query, die gerade geparst werden soll, nicht schon vorher geparst wurde. Das klappt mal mehr, mal weniger gut. Man sollte sich also im Klaren sein, dass ein DBMS auch kein Hexenwerk ist und nicht alles in Echtzeit schafft. Man sollte sich schon damit befassen, wie ein DBMS arbeitet und was man vermeiden sollte. Ein DBMS würde ich auch nicht selbstentwickeln. Erst mal fehlt mir dazu einfach das nötige Know-How und zweitens wozu auch? Es haben sich schon sehr viele andere den Kopf darüber zerbrochen. Ich habe schon Firmen erlebt, die meinten, sie wären Schlauer als Oracle und haben Datenbank-Funktionalität nachprogrammiert. Haben Zehntausende Euro verbraten und was kam raus? Eine instabile Lösung, die jegliche Form von Weiterentwicklung ausbremste.

Ein Hinweis: Ein Insert-Befehl pro Datensatz ist extrem inperformant. Bei 10 Datensätzen ist es noch kein Problem, aber wenn es über 1.000 sind, dann kann es schon einige Zeit dauern, bis alles in die Tabelle geladen wurde. Das ist auch einer der Gründe, warum sich Microsofts O/R-Mapper Entity Framework sich nie richtig durchsetzen konnte, denn dort wurde tatsächlich jeder Insert einzeln ausgeführt. Inzwischen hat Microsoft das Entity Framework komplett neu entwickelt, um diese Fehler zu korrigieren. Je nach dem wie groß das Projekt wird, würde ich ein O/R-Mapper empfehlen, der das dann übernimmt. Dann erzeugt man per Java-Code lediglich nur eine Liste von den Geschäftsobjekten aus der CSV-Datei (Deserialisierung) und sagt dann dem O/R-Mapper, er solle die Liste in die Datenbank einspielen. In Java dominiert der O/R-Mapper Hibernate. Selber SQL-Statements generieren würde ich eigentlich nicht, da man dann sich abhängig von der Datenbank macht und vielleicht möchte man sie irgendwann wechseln. Jede Datenbank hat so seine Eigenheiten und ein O/R-Mapper kapselt diese Eigenheiten, sodass man sich darüber kaum Gedanken mehr machen muss. Aber ich weiß nicht, was du vorhast oder welchen Wissensstand du besitzt aber wenn für dich der O/R-Mapper zu viel Overhead bedeutet, dann generiere doch einfach per Code ein Insert-Statement und schicke es zur Datenbank. Eine CSV-Datei auslesen ist ja nicht schwer.

Was verstehst du denn unter "Konventionen"? Eine Konvention ist ja eine Vereinbarung. Darunter versteht man in der Softwareentwicklung eher sowas wie Namensgebung, Einrückungen, etc. Es gibt zwar empfohlende Konventionen aber das kann sich auch von Firma zu Firma unterscheiden. Keiner muss sich daran halten. Das, was du wohl meinst, sind wohl so etwas wie Design Patterns. Zum Thema Design Patterns kann man noch das gleichnamige Buch von Erich Gamma erwähnen, was eigentlich so zur Pflichtlektüre gehört. Ich kenne das Buch "Code Complete" nicht aber ich denke, das meiste, was man dort findet, findet man auch im Buch "Clean Code". Zumindest liest sich die Agenda sehr ähnlich. Man darf auch nicht vergessen, dass Robert C. Martin als einer Erfinder des Begriffs "SOLID" gilt, was die Welt der objektorientierten Programmierung der letzten 10 Jahren sehr geprägt hat. Ansonsten könnte man noch Begriffe wie Test-driven Development (TDD) und Design-driven Design (DDD) in den Ring werfen. Dazu gibt es dann auch noch haufenweise Bücher aber das sind Praktiken, die man Anwenden kann, wenn man schon mehr Erfahrungen gesammelt hat.

In Japan gilt eigentlich per Gesetz die 40-Stunden-Woche. Einigen Unternehmen ist es auch gestattet, dies auf 44 Stunden auszuweiten. Darunter zählen z.B. Einzelhandelsgeschäfte oder Kinos. Das Bild des Arbeitswütigen Japaners stammt aus den 80ern und noch in die 90er hinein. Damals gabs Todesfälle wegen Überarbeitung aber dies wurde von denen gar nicht verlangt. 1997 hat man dann die 40-Stunden-Woche per Gesetz verabschiedet um der Arbeitswut Einhalt zu gebieten und so viel ist von der Arbeitswut auch gar nicht mehr übrig. Sie ist zwar immer noch recht hoch, aber inzwischen wollen die Japaner auch mehr Zeit für sich und ihrer Familie haben. Viele Firmen bieten sogar inzwischen eine 4-Tages-Woche an. Auch sind die Japaner sehr sozial eingestellt. So übernehmen viele Firmen auch inzwischen die Kita-Kosten, geben einen Mietzuschuss oder bezahlen Kindergeld. Davon können wir hier nur Träumen. Auch wenn man eine sehr lange Zeit Krank ist, bekommt man oft sein Gehalt sechs Monate ausgezahlt. Hier sind es nur 6 Wochen. Danach gibt es hier nur das Geld der Krankenkasse. Es bleiben also nichts weiter als Klischees übrig.

Ja, das Buch ist zu empfehlen und eines der Pflichtlektüre, wenn es um Clean Code geht. Es ist aber ein Irrglaube, wenn du denkst, dass Clean Code gleichzeitig auch eine bessere Performance bietet. Clean Code ist einfacher zu lesen und zu warten aber das hat nichts mit Performance zu tun. Um Performance würde ich mir auch erst mal keine Gedanken machen, sondern es geht erst mal darum, sein Code sauberzuhalten. Wie Einrückungen gemacht werden ist Geschmackssache und auch von Sprache zu Sprache unterschiedlich. Java und C# haben eine nahezu identische Syntax und dennoch sind die empfohlenden Namenskonventionen von Klassen/Methoden unterschiedlich. Während in z.B. Java empfohlen wird, eine Methode so zu schreiben: public void method() { // mach was } Wird sie in C# so empfohlen: public void Method() { // mach was } Und Python definiert die Blöcke nicht mit geschweiften Klammern, sondern mit Tabs. Da wird man also gezwungen, sauer einzurücken. Man muss aber auch darauf achten, dass hier Java gemeint ist, denn in der C#-Welt wird dies ebenfalls nicht empfohlen. In der C#-Welt ist es üblich, dass Interfaces mit einem großen I anfangen und für den eigentlichen Namen nimmt man ein Adjektiv (z.B. IDisposable) oder ein Nomen (z.B. IList). In C# endet auch die konkrete Implementierung nicht mit Imp oder Impl. Das braucht man auch nicht, da schon durch das große I erkennbar ist, was ein Interface und was eine Klasse ist. (z.B. die Klasse List implementiert das Interface IList).

Warum nicht? Ob ich jetzt mehrere Threads auf einer Maschine oder mehrere Prozesse auf mehreren Maschinen starte, spielt für die Parallelität keine Rolle. Fakt ist, es wird parallel etwas verarbeitet.

Anstatt einen Monolithen zu bauen wird heutzutage die Microservice-Architektur bevorzugt. Man startet also nicht einzelne Threads, sondern ganze Prozesse, die untereinander mit einem Messagebroker kommunizieren. Die Microservice-Architektur lässt sich auch einfacher skalieren, da die Microservices auf unterschiedliche Server gehostet werden können und für jeden Microservice kann dann eine geeignete Persistenzschicht gewählt werden. Weil das vielfach einfach nicht nötig tut und over-engineering wäre. So lange es auch auf andere Wege funktioniert, die einfacher zu händeln sind, würde ich nicht auf eine Parallisierung setzen. Nicht überall ist eine Parallisierung schneller, da eine Parallisierung auch mehr Overhead bedeutet. In einigen Fällen ist eine Parallisierung sogar auch langsamer als eine sequentielle Abarbeitung. Besonders wenn die Threads miteinander kommunizieren und aufeinander warten müssen.

Nicht immer ist eine Parallelisierung sinnvoll. Eine Parallelisierung ist nur dann sinnvoll, wenn man auch wirklich eine Berechnung parallelisieren kann und diese auch von der Parallelisierung profitiert. Etwas zu parallelisieren, nur damit die Berechnung 2 Sekunden dauert, anstatt 5, ist einfach unnütz. Du wirst selbst heute noch sehr wenig mit Parallisierung zu tun haben. Eher mit Nebenläufigkeiten, um Daten asychron zu berechnen/zu laden. Parallelisierung wird oftmals erst zum Thema, wenn es Performanceprobleme gibt. Ehrlich gesagt, würde ich mich schon freuen, wenn ich sogar von Entwicklern mit mehrjähriger Erfahrung kein Spaghetticode mehr ansehen muss. Es ist einfach traurig, dass selbst viele Freiberufler und Consulting Agenturen noch nie etwas von Clean Code oder SOLID gehört haben. Aber zum Thema: Warum sollte man es nicht erwähnen, dass man sich mit Themen wie Nebenläufigkeit schon mal auseinandergesetzt hat? Man erwartet ja kaum in Vorstellungsgesprächen, dass er alles ins Detail kennt. Selbst die Stichworte, die der TE aufgeschrieben hat, ist mehr als so manch ein Diplominformatiker weiß. Beim Vorstellungsgespräch kann man ja mit offenen Karten spielen und sagen, dass man sich bis jetzt nur in der Theorie damit auseinandergesetzt hat. Wenn ich einen Azubi einstellen würde, würde ich es auch nicht mal verlangen, dass er weiß wie man so etwas programmiert.