Legislaturperiode

Mit dem Buch bist du schon sehr gut unterwegs, auch wenn das Buch mehr C#-lastig ist. Das war auch meine Lektüre zu diesem Thema und wird auch von vielen empfohlen. Im Buch wird das Dependency Injection Muster erläutert. Beim Dependency Injection werden Abhängigkeiten in die Klasse reingereicht. Man schreibt also z.B. nicht
public Class PersonRepository implements IRepository { private final IDatabase database; public PersonRepository { this.database = new Database(); } ... } sondern
public Class PersonRepository implements IRepository { private final IDatabase database; public PersonRepository(IDatabase database) { this.database = database; } ... } Man kehrt also die Abhängigkeiten um, indem die Klasse gar nicht die konkrete Implementierung der Abhängigkeiten kennt, sondern nur gegen Interfaces arbeitet und die konkrete Implementierung reinreicht. Man spricht dabei auch vom Dependency-Inversion-Prinzip und das macht das Testen der PersonRepository-Klasse viel einfacher, weil man jetzt in diesem Fall tatsächlich die Datenbank mocken kann. In der richtigen Anwendung reicht man vielleicht die Klasse MySqlDatabase rein und im Test MockedDatabase, die nichts anderes tut, als Textausgaben auf der Konsole zu machen, die der Unittest dann testet. Andere Tests wiederrum testen die MySqlDatabase-Klasse, indem sie schauen, dass z.B. die richtigen Tabellen angelegt worden sind. Fürs Dependency Injection Muster gibt es auch diverse Frameworks (sog. IoC Container (IoC = Inversion of control)), die einem das Leben erleichtern. Mit Hilfe eines Bootstraping-Verfahrens wird dann beim Starten der Anwendung die Abhängigkeiten der einzelnen Klassen aufgelöst und das Framework instanziiert und initialisiert die Klassen mit allen ihren Abhängigkeiten. Die Java-Welt ist nicht so ganz meine Welt, daher kenne ich mich dort mit den Frameworks nicht so gut aus, aber dort gibt es ja z.B. Spring, Pico Container oder Guice.  

Du rufst im Test aber gleich mehrere Methoden aus einem Modul/einer Klasse auf. Das ist kein Unittest. Unittests testen eine Methode und nicht die gesamte Klasse und das ist das Problem bei deiner Architektur. Du kannst gar nicht eine Methode einzeln testen, sondern nur im Bündel. Das Problem ist, dass deine Database-Klasse zu viel macht. Sie ist sowohl das Repository als auch die Datenbank-Verbindung. Dein Test läuft so ab:
Erstelle eine neue Datenbank-Datei Erstelle eine neue Tabelle Füge Daten in die Tabelle ein Wenn jetzt der Unittest fehlschlägt, kannst du nicht sagen wo genau dieser Fehler liegt. Du musst also den Unittest debuggen. Das mag bei deinem Projekt noch funktionieren aber bei komplexen Projekten ist das die Hölle, weil die Tests sehr zeitintensiv und instabil werden. Du musst also das Repository von der Datenbank trennen. Dafür gibt es das sog. Unit of Work-Pattern. Schaue dir an wie O/R-Mapper wie z.B. Nibernate funktionieren. Die implementieren das Unit of Work-Pattern. Das Unit of Work-Objekt registriert neue Geschäftsobjekte und bei einem Commit() werden sie dann in die Datenbank geschrieben. Bei O/R-Mappern schreibt man auch keine SQL-Statements selber. Sie werden über das Framework generiert.
Ja, das meine ich. 
Wie willst du aber die Datenbank-Verbindung mocken? Du hast keine Möglichkeit, diese von außerhalb zu ändern. Also bist du davon abhängig. Du müsstest also die Klasse ableiten und alle Methoden neu implementieren. Das ist viel zu viel Arbeit. Auch ist deine Database-Klasse sowohl die Datenbank-Verbindung als auch das Repository. Angenommen, du willst jetzt nicht nur eine Tabelle mit Deutsch/Englisch-Wörter implementieren, sondern noch eine Tabelle mit Benutzerdaten. Also z.B. wie viele Wörter die Benutzer richtig erraten haben, etc. Wie willst du das jetzt hier einbauen? Willst du die Database-Klasse um weitere Methoden erweitern? Dann kommt eine neue Tabelle und noch eine und noch eine ... Dann hast du irgendwann eine Klasse mit über 100.000 Zeilen und damit ein unwartbares Biest. Viel spaß beim Mocken.

Wenn du Spaß an der Entwicklung hast und das Thema völlig frei wählbar ist, warum solltest du dann zu einem anderen Thema präsentieren? Was ist der Sinn dahinter? Du kannst dir ein beliebiges Thema aussuchen und wählst absichtlich etwas, worauf du eigentlich gar nicht so viel Lust hast!? Da würde ich sagen: Thema verfehlt.
Zu den von dir genannten Punkten kannst du sicherlich locker 8 Minuten füllen. Das ist ja nichts! Bastel mal ein paar Folien und übe deine Präsentation. Du wirst sehen, wie schnell die Zeit vergeht.

@Eratum Zu deinem OffTopic: Ich fand das Buch Datenfresser von Constanze Kurz und Frank Rieger ganz passend.

Mahlzeit!
Ich hab's aus zweierlei Gründen wieder gelöscht.
Ich fand es langweilig. Als jemand, der sich hauptberuflich mit der Auswertung und Verknüpfung von Daten beschäftigt finde ich es gelinde gesagt "bedenklich", was sich mit diesen Unmengen an Bewegungsprofilen anstellen lässt. Am besten noch per SSO-Facebook Login. Es sollte meiner Meinung nach viel mehr "Awareness" dafür geschaffen werden, was mit gar nicht mal so komplizierter Mathematik an Dingen bzgl. der Verknüpfung und Auswertung von Daten möglich ist. Und dass das immer eine Wahl "Bequemlichkeit vs. Datenhoheit/Privatsphäre" ist. Ein anderes, für Laien eher greifbares Beispiel sind die Vorschläge bei Amazon. "Ja, das ist doch bequem!" - Aber: Für welchen Preis?
Wir IT-ler, Mathematiker und Naturwissenschaftler im Allgemeinen sind da imho besonders in der Pflicht, aufzuklären und zu unterstützen.
Nicht einfach zu verteufeln, schließlich hat das Spiel vermutlich so viele Kids vor die Tür gebracht wie selten ein "Spiel" vorher. Aber ein reflektierter Umgang mit den Daten, die jeder so vor sich hin produziert, liegt mir persönlich schon irgendwie am Herzen.
Gruß, Goulasz  

Wichtig ist, dass du dort das machen kannst/sollst, was du gerne machen möchtest, also dass der Job fachlich zu deinem Profil und deinen Wünschen passt und möglichst die Arbeitskollegen und Vorgesetzten auch noch menschlich, so dass du dich in einer Firma wohl fühlst.
Dafür braucht man nicht unbedingt die erwähnten Goodies. Stellt man diese so heraus, dann sieht es oftmals um das Miteinander nicht so gut aus und dies soll dadurch dann überspielt werden.
Ich habe gerade gesehen, dass du dich dort um einen Ausbildungsplatz bewirbst (dachte eigentlich, es geht um einen Job). Aber auch dabei ist es halt wichtig, dass du in einem Bereich lernst, der dir selber auch Spass macht und du nicht tagein tagaus irgend etwas machen sollst, das dir gar keinen Spass macht. Genauso ist es auch wichtig, dass sich um deine Ausbildung bzw. um dich gekümmert wird.
Es gibt Firmen, die setzen noch immer alte Clients ein. Entweder, da sie die Kosten und den Aufwand für eine Migration scheuen, oder aber, da bestimmte Spezialsoftware vielleicht nicht auf aktuellen Windows-Versionen lauffähig ist, oder es Probleme damit gibt, oder sie auch eine alte Serverversion einsetzen, die die neuen Clients gar nicht unterstützt.
Diesbezüglich würde ich auf jeden Fall noch einmal nachhaken, falls es zum Vorstellungsgespräch kommt. Könnte natürlich auch einfach nur eine alte Vorlage gewesen sein, die nicht aktualisiert wurde.

Wenn du genauso viel Zeit in Bewerbungen investieren würdest wie in "Themen die du interessant findest" hättest du wohl schon einen Haufen Bewerbungsgespräche.
Ernsthaft...eine Ausbildung ist da um Wissen zu vermitteln. Kein AG kann dir garantieren Techniken einzusetzen "die du interessant findest". Genaugenommen wird es deinem Chef egal sein, Hauptsache das Produkt x ist zum dd.MM.yyyy brauchbar.
Es ist schön wenn du mal später mit was arbeitest, was dir Spaß macht, so sollte es im Idealfall sein, aber du machst ne Ausbildung ...
Du sollst alles lernen was für diesen Beruf erstmal relevant ist, egal ob es dich interessiert oder nicht. Die meisten Ausbilder sind froh Leute zu haben, die sich für das Zeug interessieren, welches in der Firma angewandt wird. Vermeintliche "Alleswisser" die alles ewig lange in Frage stellen, sind da oft nicht gern gesehen. 
Wenn Ausbilder deine Bewerbung sehen, denken sie sich wahrscheinlich oft "aha schön, dass ihn das interessiert ... machen wir aber leider nicht". Mal ganz davon abgesehen: Gehe nicht davon aus, als Azubi gleich an/mit den spannendsten Themen zu arbeiten. Das erste Jahr bekommst du in der AE erstmal kleinere Aufgaben und guckst anderen über die Schulter. Das Tempo wird dann je nach deiner Eignung angezogen.
Und zum Schluss: Du schindest mehr Eindruck, wenn du dich über die Technik die der AG einsetzt informierst, als random irgendwas zu lernen. Ein AG ist 10x mehr happy wenn du dich über sein Zeug und den Techniken die dahinter stecken informierst, als über etwas was du auf heise gelesen hast. 

Etwas interessant finden und darauf hinzuarbeiten,, die entsprechende Technik einmal produktiv einzusetzen später ist aber ein himmelweiter Unterschied. Du findest vielleicht auch Musik von $Interpret interessant, oder $Computerspiel. Deshalb muss es aber lange nicht relevant sein für die Ausbildung. Genauso kann es auch sein, dass du es total uninteressant findest, wenn du das Prinzip dahinter verstanden hast.
Es werden auch längst nicht alle Firmen parallelisierte Prozesse oder Nebenläufigkeit unbedingt in ihren Programmen verwenden. Es lohnt halt oftmals einfach nicht, diesen Zusatzaufwand (man braucht z.B. zusätzliche Schnittstellen und Sicherungsmechanismen, um die Datenintegrität sicherzustellen, damit nicht bereits berechnete Werte einfach wieder überschrieben werden von anderen parallel laufenden Prozessen, man braucht eine Speicherverwaltung, usw.)
Bei kleinen Klitschen kann man manchmal sogar froh sein, wenn überhaupt richtig objektorientiert programmiert wird, und man keinen Spaghetticode schreiben soll, oder man unsaubere Programmierung (Mißbrauch von Klassen z.B.) beigebracht bekommt.
Zudem lernt man erst einmal die Grundlagen der Programmierung und steigt nicht direkt mit Sonderfällen damit ein, die komplexer zu programmieren sind.
Meist steigt man auch nicht einmal direkt mit objektorientierter Programmierung ein, sondern erst einmal mit den Grundlagen wie if-Abfragen, Schleifen, Datentypen, Variablen, globalen Variablen, Funktionen usw. und geht dann über ins objektorientierte Programmieren mit Klassen und Methoden usw. Die Parallelisierung würde dann also erst danach kommen.
Parallelisierung hat Nachteile, wenn Ergebnisse auf den Rückgabewert des vorherigen Prozesses warten müssen, so dass sich lange nicht alles auch sinnvoll parallelisieren lässt.
Was bringt es dir, wenn Prozess 1 auf CPU 1 läuft, Prozess 2 gestartet wird, jedoch auf den Rückgabewert von Prozess 1 warten muss, um loslaufen zu können? Da kann es genausogut auch nach Ablauf des Prozesses 1 auf CPU 1 weiterberechnet werden.
Das Gleiche dürfte auch für Nebenläufigkeit gelten.
Kann man ein Programm SINNVOLL in mehrere Threads zerlegen, bringt der Overhead keinen wirklichen Vorteil in der Laufzeit, oder kann man dadurch viel Zeit sparen (jede Menge kleine Jobs, die unabhängig voneinander laufen können)?

Das ist schon richtig. Das Ding ist nur, dass du als (z.B.) Webentwickler damit nichts zu tun haben wirst. Die gesamte Parallelisierung wird dir vom Server / Framework abgenommen. Klar, du startest mal einen neuen Thread oder Task und lässt den parallel laufen - mit der zugrundeliegenden Technik hast du aber nichts zu schaffen. Korrekten (!) multithreaded Code zu schreiben, ist schwierig und aufwendig zu testen. Daher verlässt man sich normalerweise auf die Arbeit von Experten, die einem eine zugängliche API bereitstellen (in der .NET-Welt sind das bspw. async/await, Task.Run oder Thread.Start - und selbst da kann man genug verkehrt machen, wenn man nicht aufpasst).
Ich würde dir auch empfehlen, solche Sachen aus der Bewerbung rauszulassen. Im besten Fall nimmt dein Gegenüber das nicht für bare Münze und denkt sich seinen Teil, im schlimmsten Fall hält man dich für naiv und eine Buzzword-Schleuder.

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.

Was machst Du Dir es so unnötig schwer?
Wenn in der Anzeige eine Telefonnummer aufgeführt ist, solltest Du diese anrufen und Deine Situation schildern. Das zeugt von einer guten Problemlösungskompetenz.

Ich würde es mit reinnehmen. Alles, was dich von anderen Azubibewerbern positiv abhebt, kann doch nur zu deinem Vorteil sein. Damit zeigst du dein Interesse am Beruf!
Es sollte nur nicht so rüberkommen, als ob du schon alles weißt und die Ausbildung gar nicht mehr brauchst. Das sehen viele Ausbilder nämlich nicht so gerne.
Und auf Fragen im Vorstellungsgespräch würde ich mich auch vorbereiten. Kommt ja nicht alle Tage vor, dass man einen so engagierten Kandidaten hat. Und wenn du auf einen ebenso motivierten Ausbilder triffst, kennt der die angegebenen Podcasts auch

Hallo Community,
(Das sieht mir wie die Pressestelle aus der Webpräsens aus, unter Impressum)
Die Ausgangslage des TE bezieht sich ja nicht auf eine Stellenanzeige und das Problem definiert sich mit dem Abschluss eines Vertrags. Gerade mit Initiativbewerbungen kann man Jobs "außer der Reihe" suchen. Hier bietet es sich vielleicht an, den jeweiligen Ansprechpartner im Standort ausfindig zu machen und direkt anzuschreiben. Gerade die etwas persönlichere Bewerbung ist doch unter Umständen das Erfolgskonzept. So zum Beispiel schickt man die Bewerbung an den Standortausbilder (falls dort ausgebildet wird) und der leitet die an den zentralen Personaler weiter (Hoffentlich dann mit dem Kommentar "Den will ich!"). Diese "info@$unternehmen"-Adressen sind oft nur die Pressestellen bei Initiativbewerbungen. Und wenn die Zentrale aus intern dann mehrere Bewerbungen mit diesen "Den will ich!"- Kommentaren bekommt, war diese Arbeit doch nicht unnötig.
Grüße
Micha

Ich finde auch den Wildwuchs an Berufsbezeichnungen teilweise sehr abschreckend:
(Junior-/Senior-)Software-Developer, (Junior-/Senior-)Software-Engeneer etc. pp.

Warum kann man sich nicht auf eine einheitliche Berufsbezeichnung oder zumindest einheitliche Kriterien für die Verwendung der verschiedenen Bezeichnungen einigen?
Ab wann ist man z.B. Junior-Software-Developer ab wann Senior-Software-Developer? Hängt das vom Lebensalter oder der Berufserfahrung ab?

Fragen über Frage!

Da wundert es mich nicht, wenn Firmen sich darüber beklagen, keine passenden Leute zu finden, wenn sie teilweise selber nicht einmal zu wissen scheinen was sie suchen oder die Anforderungen völlig realitästfremd sind. Stichwort: 18 Jahre, Ausbildung mit 1,0 abgeschlossen und 5 Jahre Berufserfahrung! Okay, ein wenig überspitzt, aber im Grunde weiß wohl jeder, was ich meine :floet:

Um es noch etwas zu überspitzen: Im Grunde verlangt die Wirtschaft, dass du mit 25 deinen abgeschlossenen Master hast und bereits 3 Jahre Berufserfahrung aufweisen kannst. Kinder bzw. Kinderwunsch sollte dabei sowieso keinesfalls vorhanden sein und die Gehaltsvorstellungen sollten auch unter 3k/Monat liegen. ^^