Whiz-zarD

Jop. Genau so. Deine beiden Systeme verbinden sich mit RabbitMQ und tauschen darüber ihre Nachrichten aus. System A schickt eine Nachricht an RabbitMQ und System B nimmt dann die Nachricht entgegen und umgekehrt. Der Vorteil ist nun, dass die Systeme nichts voneinander wissen müssen und die Anzahl der Systeme könnten nun auch unendlich sein. Kann sein, dass du noch ein weiteres System hat, was grundsätzlich alle Nachrichten empfangen soll, z.B. fürs Logging, fürs Monitoring oder für ein Event Store. Es gibt nun auch mehrere Lösungsansätze. Je nach dem, wie groß die vom System A erstellte Datensatz ist, kann mich sich nun überlegen, den Datensatz als Nachricht zu verschicken. Ich habe aber schon Systeme gesehen, die legen den Datensatz auf einem Dateisystem oder in eine Datenbank ab und schicken als Nachricht, dass eine neuer Datensatz vorhanden sei und wo er liegt, um somit den Netzwerktraffic gering zu halten. Für C# gibt es sogar noch EasyNetQ, was die Nutzung von RabbitMQ erleichtert.

Schaue dir mal RabbitMQ an. Das ist genau das, das du haben willst.

Dann müsst ihr halt einen pdf-Viewer auf eurer Webseite einbinden und halt keine Speicher-Funktion anbieten. http://mozilla.github.io/pdf.js/

Da ist doch sowieso irrelevant. Selbst wenn man im Browser das Speichern blockieren könnte, befindet sich die Datei im Temp-Verzeichnis und kann von dort aus kopiert werden. Irgendwo muss die Datei ja auf dem Client liegen. Wieso wollt ihr das überhaupt verhindern? Welchen Mehrwert habt ihr davon?

https://downloadcenter.intel.com/product/90590/Intel-H110-Chipset

Nein, hat es nicht, da der Three-Way-Handshake für den Aufbau und Abbau einer TCP-Verbindung verwendet wird. Hier geht es aber um die Datenübertragung während einer TCP-Verbindung. Da die TCP-Verbindung in deiner Aufgabe schon steht, wurde der Three-Way-Handshake schon gemacht.

Nicht nur das. Mit dem Android SDK, wären sie im "Low-Level"-Bereich unterwegs. Sprich, sie hätten die OpenGL ES-Befehle selbst ausführen müssen. Dies ist zwar interessant, wenn man die Funktionsweise einer Grafik-API verstehen möchte aber dies würde dazu führen, dass man den Gaming-Bereich nie erreichen würde, weil man in der ganzen Ausbildung nur mit der Computergrafik beschäftigt wäre. z.B. mit der Linearen Algebra, Rendergleichung, Beleuchtungsmodellen, Reflexion, Rendering-Pipeline, Transformationen, Interpolationen, Triangulierung, Tessellation und dann fehlt noch der gigantische Teil der Physik. In meiner Assistentenausbildung zum Medieninformatiker haben wir in der Computergrafikübung drei Spiele mit C und OpenGL entwickelt: Pong (2D), Pac-Man (2D) und Sokoban (3D) und das war schon recht aufwendig, weil wir u.a. selbst Datenstrukturen für die Levels in Pac-Man und Sokuban überlegen mussten und wie daraus Grafiken werden oder selbst berechnen mussten, wie der Ball in Pong an den Wänden abprallt. Das alles nimmt dir aber Unity 3D schon ab. Unity 3D ist nichts weiter als eine weitere Abstraktionsschicht über dem Android SDK, was eine Activity mit einem OpenGL ES-Fenster, dem Game-Loop und noch viele weitere Funktionen bereitstellt (Physikberechnung, Beleuchtung, etc.). Du brauchst dich also z.B. nicht mehr darum zu kümmern, wie jetzt nun die Implementierung eines Algorithmus aussieht, der ein Rechteck rotieren lässt, wie ein Kreis gezeichnet wird oder wie ein Objekt fällt. Du kannst dir ja mal dies durchlesen, was du alles mit dem Android SDK machen müsstest, nur um ein Dreieck zu zeichnen und das ist nur ein 2D-Objekt ohne Textur. Hast du echt Lust darauf, das alles zu entwickeln? Das Android SDK ist in erster Linie nicht dafür gedacht Spiele zu entwickeln, sondern gewöhnliche Apps, die eine androidtypische GUI haben. Betrachte das Android SDK wie WinForms, WPF oder Qt. Keiner würde auf die Idee kommen, damit ein 3D-Spiel entwickeln zu wollen.

Sehe ich genauso. Es ist egal, ob man jetzt Xamarin.Android oder das Android SDK nimmt. Der Unterschied ist da nicht besonders groß. Die Methoden und Klassen sind da weitgehend gleich. Entscheidend ist, dass man versteht, wie Android tickt. Ein Umschwenken auf Java ist dann nicht mehr ganz so tragisch, wenn man unbedingt mit Java entwickeln möchte.

Sollen denn noch Android-Apps gebaut werden? Sofern ihr Android-Apps noch bastelt, werdet ihr wohl C# und Xamarin verwenden und der Vorteil von Xamarin ist halt, dass ihr Apps schreiben könnt, die nicht nur auf Android laufen, sondern auch unter Windows und iOS. Im Spielebereich wird dann wohl Unity verwendet und unter Unity verwendet man ebenfalls C#. Da ist es schon Sinnvoll Java zu streichen und komplett auf C# zu setzen. So kann man Einarbeitungszeit einsparen und die Zeit in den relevanten Themen stecken. Von daher denke ich mal, passt das schon recht gut. Es sollte halt klar sein, dass eine Ausbildung oder Umschulung die Softwareentwicklung nicht vollumfänglich erfassen kann, denn dafür ist das Gebiet einfach zu groß und daher muss man eben Abstriche im Kauf nehmen.

Nein... MD5 ist keine Hashfunktion für Passwörter und sollte dafür auch nicht verwendet werden.

Kommt drauf an. Dependency Injection ist zwar ein schönes Mittel, um konkrete Abhängigkeiten zu entkoppeln aber die Abhängigkeiten bleiben bestehen, wenn auch nur in Form eines Interfaces. Dependency Injection kann somit auch schnell zur Pest werden, wenn man die Klassen nicht klein genug hält und man plötzlich 10 oder mehr Abhängigkeiten über den Konstruktor in die Klasse reinwirft. Dann muss man wieder 10 oder mehr Klassen mocken, bevor man die eigentliche Klasse testen kann. Das minimiert nicht den Testaufwand. Um dieses Symptom zu bekämpfen, wurden dann IoC-Container entwickelt, die dann über ein Bootstrapping die Abhängigkeiten der Klassen auflöst und wie von Geisterhand die Objekte instanziiert. Meiner Meinung nach löst dies aber nicht das Problem, sondern man verlagert es nur an eine andere Stelle und bläht sein Code mit Infrastruktur auf. Zusätzlich können auch Fehler im Bootstrapping auftauchen und plötzlich werden dann die falschen Abhängigkeiten in eine Klasse injiziert. Also muss man auch das Bootstrapping testen. Unter Umständen kann es dann auch soweit kommen, dass man den Code nicht mehr lesen kann, da man nicht mehr weiß, welche Implementierung gerade wo verwendet wird. Meiner Meinung nach, benötigen wir ein anderes Verständnis über die Softwareentwicklung aber ich denke, das würde jetzt hier zu weit führen. tl;dr: Dependency Injection, ja ist ein gutes Mittel aber das Drumherum muss auch stimmen, um die Vorteile genießen zu können. @dnyc: Versuche doch, einen Ausbildungsplatz zu bekommen. Bei deiner vorherigen Ausbildung als IT-Kaufmann kann ich mir vorstellen, dass du auch die Ausbildung verkürzen kannst. Ich denke mal, dass es in der heutigen Zeit Quereinsteiger doch sehr schwer haben. PHP ist auch keine allzu moderne Sprache mehr und inzwischen auch schon etwas verpönt, sodass man auch kaum Chancen hat, eine Firma zu finden, die bereit sind, einen Quereinsteiger in der PHP-Entwicklung einzustellen. Also Frontend-Entwickler mit Angular oder React hat man derzeit wohl bessere Chancen. Allerdings sehe ich heute nur noch eine Chance als Praktikant in die Branche reinzukommen, wenn man nicht eine Ausbildung oder ein Studium anstrebt. Besonders Startups suchen häufig Praktikanten. Bei Facebook und Co. wird aber nicht ausschließlich PHP verwendet. PHP wird überwiegend für die Logik verwendet und ist mehr historisch begründet, weil Zuckerberg damals mit PHP angefangen hat. Inzwischen mussten sie aber vieles tun, damit es überhaupt performant bleibt, indem sie z.B. ein Compiler gebaut haben, der den PHP-Code in Maschinensprache übersetzt. Auch das JavaScript-Framework React stammt von Facebook. Die Klassische Entwicklung mit PHP hat nämlich den Nachteil, dass das Erstellen des HTML-Dokumentes auf dem Server geschieht. Wenn jetzt nun eine Million Nutzer eine klassische PHP-Webseite aufrufen, müssen die Server eine Million HTML-Dokumente erzeugen, die wohlmöglich zu 95% immer gleich aussehen (Header, Footer, ...). Das ist sehr rechenintensiv. Da kommen dann Angular oder React ins Spiel und verlagern die Erstellung der HTML-Dokumente auf den Client (der Browser), da der Client eh die Leistung dafür hat. Auf diese Weise entlastet man den Server enorm. Der Server sendet also nur noch die reinen Daten zum Client und der Client generiert aus diesen Daten die Ansicht. Ein weiterer Vorteil ist nun, dass Angular oder React nicht die Webseite jedes Mal neu generieren, sondern im DOM einfach nur die Elemente austauschen. So bekommt man das Gefühl, dass es sich nicht um eine Webseite handelt, sondern um eine App. Das Prinzip nennt sich dann auch Single-Page-Application.

Natürlich kann er das. Da wird keinem die Tür zugeschlagen, da es nun mal Gründe haben kann, eine Ausbildung abzubrechen. Er kann entweder versuchen, einen neuen Betrieb zu finden oder er schreibt die Prüfung als Externer. Allerdings ist dies mit Kosten und Mühen verbunden. Als Externer muss man allerdings vorweisen können, dass man das 1 1/2 fache der Ausbildungszeit auch in diesem Beruf gearbeitet hat (§45 Abs.2 BBiG). Sprich, bei 3 Jahren Ausbildungszeit wären es 4 1/2 Jahre Berufserfahrung. Da frage ich mich schon, wieso man sich sowas antut, wenn man schon in einem Ausbildungsverhältnis war und kurz vor Ende das Handtuch schmeißt, um wieder neu anzufangen? Alles in allem würde ich aber mit der zuständigen Stelle (sprich Handelskammer) sprechen, da ich nicht weiß, in wie weit man die schon geleisteten Ausbildungsjahre anrechnen kann, wenn ein neuer Betrieb gesucht wird. Das Facharbeiterzeugnis bekommst du erst, wenn du die Ausbildung erfolgreich abgeschlossen hast.

Und wieso du gekündigt hast, anstatt die Ausbildung zu beenden.

Hast du keine Idee, was dir im Alltag evtl. helfen könnte? Ich selber entwickle derzeit z.B. ein Tool, um mein Girokonto besser analysieren zu können. Da ich in deiner CV lese, dass du einen Taschenrechner entwickelt hast, kannst du dir ja mal überlegen, wie man einen Taschenrechner richtig entwickelt. Ein Taschenrechner ist gar nicht so einfach und bei weitem nicht klein. (Stichwörter sind Shunting-Yard-Algorithmus und polnische Notation) Wenn ich einen Bewerber vor mir hätte, der in seiner CV schreibt, er hätte einen Taschenrechner programmiert, den würde ich darüber ausquetschen. Wissen über O/R-Mapper ist nie verkehrt. In der .Net-Welt gibt es z.B. das Entity Framework Core und in der Java-Welt Hibernate. Falls du dich damit nicht auskennst, kannst du dich damit auch beschäftigen. Auch sowas wie Microservices sind derzeit sehr gefragt. Dafür werden dann Message Broker verwendet, wie z.B. RabbitMQ. Da du ja auch Erfahrung mit JavaScript hast, kannst du dir auch für den Frontend-Bereich Angular oder React anschauen.

Sich da noch großartig zu erkundigen, ob seine Noten stimmen, halte ich auch für seltsam. Im Zweifel einfach ablehnen. Wozu sich da die Mühe machen? Er hat doch schon im Vorstellungsgespräch bewiesen, dass er nicht euren Anforderungen genügt. Wozu dann noch zusätzlich nachtreten? Falls ihr aber dennoch Interesse an ihn habt, einfach zu einem Probearbeitstag einladen.

Mein Beileid. Ich habe auch viel mit PL/SQL zu tun und das ist keine Sprache, die man sich freiwillig antun möchte.

Dies kann grundsätzlich passieren. Auch in einer Ausbildung oder in einem Studium. Ein guter Entwickler reflektiert immer seine Aufgaben und bildet sich weiter und überlegt, was er nächstes Mal besser machen könnte. Man sollte nicht Kommentare schreiben, nur des Kommentar wegen. Es gibt gute und schlechte Kommentare. Vor allem Inline-Kommentare, also Kommentare, die innerhalb eines Codeblockes stehen, sind sehr tückisch. Im Idealfall liest sich der Code wie ein Prosatext und benötigt kann keine Inline-Kommentare. Wenn welche benötigt werden, sollten Inline-Kommentare eher das "wieso?" und "warum?" erklären und nicht das "was?", denn das besagt schon der Code. Das ist von Sprache zu Sprache unterschiedlich und man sollte sich an das halten, was die Sprache an Richtlinien vorgibt. Hier unterscheidet sich z.B. Python von C#, da in C# Methoden mit einem Großbuchstaben anfangen. Ich persönlich sehe da auch keine Probleme. Eigentlich kann man sich da wenig falsches aneignen. Wie gesagt, ein guter Entwickler sollte in der Lage sein, sein eigenes Können zu reflektieren und durch stetiges Weiterbilden sein Können verbessern. Darf man sich dann nicht mehr für ein Themengebiet interessieren und Erfahrungen sammeln, weil man vielleicht vor hat, eine Ausbildung anzufangen? Willst du einem Kind das Basteln eines Ferngesteuerten Autos verbieten nur weil es in 10 Jahren vielleicht eine Kfz-Mechatroniker-Ausbildung machen wird? Wenn das so ist, dann müsste man ja auch Veranstaltungen, wie z.B. Jugend Hackt einstellen, weil die Kinder vielleicht Entwickler werden wollen ...

Sorry, aber dann hat er keine Ahnung. Ein Code sollte im Idealfall wie ein Prosatext zu lesen sein. Wenn man dann anfängt Kommentare schreiben zu müssen, um den Code zu erklären, dann macht man was falsch. Zu mal, solche Kommentare irgendwann lügen, da der Code angepasst wird aber nicht der Kommentar. Ein Kommentar sollte, wenn überhaupt, das "Wieso" erklären und nicht das "Was". Das "Was" erzählt schon der Code. Und was ist an den Code nicht verständlich? Es ist eine simple Überprüfung, wann zwei Person-Objekte als gleich zu betrachten sind. Dafür wird ein Hashwert und eine Equals()-Methode benötigt. Der Hashwert ist im Grunde nichts weiter, als eine Zahl, die das Objekt repräsentiert. Es ist quasi eine Performanceoptimierung. Bei meinem Comparer gibt es aber noch einen Fehler. Die GetHashCode()-Methode berücksichtigt auch den Wert und daher funktioniert es nicht. Die XOR-Verknüpfung von Wert muss raus. public class PersonComparer : IEqualityComparer<Person> { public bool Equals(Person x, Person y) { if (x == null || y == null) return false; return x.Vorname == y.Vorname && x.Nachname == y.Nachname && x.Geburtsdatum == y.Geburtsdatum; } public int GetHashCode(Person obj) { return obj.Vorname.GetHashCode() ^ obj.Nachname.GetHashCode() ^ obj.Geburtsdatum.GetHashCode(); } } Intern verwendet Distinct() eine Art HashSet, die aber speziell für LINQ entwickelt wurde. Distinct() vergleicht die Werte über einen Comparer. Wenn man keinen Comparer verwendet, wird intern ein DefaultComparer verwendet. Wie dieser genau arbeitet, weiß ich allerdings auch nicht. Nicht desto Trotz, lässt sich nun ein eigenen Comparer implementieren. GetHashCode() ermittelt aus dem Objekt eine Zahl. Dazu gibt es etliche Artikel, wie die Methode zu implementieren ist. Die Empfehlung ist, von den jeweiligen Properties den Hashwert ermitteln (die Methode befindet sich am Objekt selber) und diese dann mit einem XOR zu verknüpfen. Damit bekommt man einen eindeutigen Hashwert. Das HashSet kann dann daraufhin sehr performant ermitteln, ob beide Objekte gleich sind, da er er nur zwei Zahlen miteinander vergleichen muss. Zusätzlich gibt es noch die Equals()-Methode, die eine weitere Überprüfung darstellt, falls dann doch zwei Hashwerte gleich sind. Du könntest auch einfach bei GetHashCode() eine 0 zurückgeben. Dann ist der Hashwert immer 0 und bei jedem Objektvergleich würde die Equals()-Methode ziehen. Diese Variante kann aber ggf. zu einer schlechten Performance führen. public int GetHashCode(Person obj) { return 0; } Dann macht der Code genau das, was du willst und du brauchst kein Boilercode, wo du zig Listen, mehre LINQ-Ausdrücke erstellst.

Wofür macht man denn ein Vorschlag, wenn du selbst einen Frickelcode zusammenschustert, den kein Schwein versteht? Schreib doch ein Comparer, wie ich schon vorgeschlagen habe. Mehr brauchst du nicht und schon gar nicht tausend Listen, die dir den Speicher zumüllen. Wenn man schon Kommentare schreiben muss, um den Code zu erklären, dann macht man in der Regel schon fast falsch.

Es wird kein Array erzeugt, sondern ein anonymer Datentyp, der nur innerhalb der Methode verwendet werden kann. Und ja, wenn in Person weitere Methoden sind (wovon ich aber abraten würde), könnte er sie nicht aufrufen, ohne erstmal aus dem anonymen Datentyp eine Person zu instanziieren.

In Distinct kann man auch einen Comparer mitgeben: var listDis = liste.Distinct(new PersonComparer()).ToList(); public class PersonComparer : IEqualityComparer<Person> { public bool Equals(Person x, Person y) { if (x == null || y == null) return false; return x.Vorname == y.Vorname && x.Nachname == y.Nachname && x.Geburtsdatum == y.Geburtsdatum; } public int GetHashCode(Person obj) { return obj.Vorname.GetHashCode() ^ obj.Nachname.GetHashCode() ^ obj.Geburtsdatum.GetHashCode() ^ obj.Wert.GetHashCode(); } }

Die Abschlussprüfung dient dazu, dass du beweisen sollst, dass du die berufliche Handlungsfähigkeit erlangt hast. Sprich, ob du die fachliche Qualifikation besitzt, den Beruf auszuführen. Eine Präsentation im Sinne einer Produktvermarktung, wird nicht zeigen können, ob du die berufliche Handlungsfähigkeit erlangt hast. Du sollst also präsentieren, was du gemacht hast und sollst nicht das fertige Produkt vorstellen.

Als Anfänger? Weder noch. Nimm Konsolenanwendungen. Weder WinForms noch WPF wird man dir in der Schule richtig beibringen. Letzen Endes ist dies nur die Oberfläche. Wenn du die Logik strikt von der Oberfläche trennst, ist es hinterher fast egal, ob du nun WinForms, WPF, ASP.NET oder ein JavaScript-Framework ala Angular oder React nimmst. Um aber ein Gefühl für die Programmierung zu bekommen, wäre eine Konsolenanwendung angebrachter, da Oberflächen sehr viel Magic aufweisen, die gerade Anfänger noch nicht verstehen, wieso das alles so funktioniert.

Wieso ein "krasser" Taschenrechner? Ich rede auch nur von Grundrechenarten. Wenn du aber mehr als zwei Zahlen miteinander verrechnen möchtest, kommst du mit einfachen switch- und if-Anweisungen nicht mehr weit. Zumal weiterhin einen schlechten Programmierstil gefördert wird.

Um einen Taschenrechner sinnvoll zu programmieren bedarf es etwas mehr, als nur ein paar Switch-Cases. Im Grunde genommen sind Switch-Cases hier sogar der falsche Ansatz. Wenn man es richtig macht, braucht man diese nämlich gar nicht. Ich habe mir dazu schon etliche Videotutorials angeschaut und eins ist schlechter als das andere. Es fördert einen sehr schlechten Programmierstil. In einigen Videos verhaspelt sich der Sprecher sogar, weil er sich in einem Code nicht mehr zurechtfindet. In all den Tutorials werden sich auch keine Gedanken gemacht, wie ein Taschenrechner eigentlich funktioniert. Es werden auch z.B. nicht die Probleme erörtert, die die gängige Infix-Schreibweise von mathematischen Termen mitsichbringen (Operatorreihenfolge bzw. Punkt-vor-Strichrechnung) und wie man das Problem umgehen kann (via Prä- und Postfix-Schreibweise; Auch (umgekehrte) polnische Notation genannt). Dementsprechend wird auch nicht der Shunting-Yard-Algorithmus erwähnt, der nämlich einen mathematischen Term, der in der Infix-Schreibweise vorliegt, in eine Postfix-Schreibweise überführt. Mit der Postfix-Schreibweise lässt sich dann einen binären Baum aufbauen, den man traversieren und auswerten kann. Also nein, ich halte weiterhin einen Taschenrechner für eine sehr schlechte Programmierübung für einen Anfänger. Wenn es darum geht, If-Verzweigungen zu lernen, dann reicht auch das FizzBuzz-Spiel. Als Anfänger möchte man doch schnell positive Ergebnisse sehen. Wenn man aber dann mehrere Tage oder sogar Wochen an einen Taschenrechner rumbastelt, der immer meint, dass 1 + 2 * 3 gleich 9 ergibt und nicht 7, dann ist das schon frustrierend. Ein anderes Problem ist nicht unbedingt der Taschenrechner selber, sondern dass man mit einer grafischen Oberfläche anfängt. Ich finde, ein Anfänger sollte mit einem Kommandozeilenprogamm beginnen, um ein Gefühl für die Sprache zu entwickeln. Grafische Oberflächen sind häufig eine Black Box und besitzen viel Magie (besonders bei C#) und ein Anfänger versteht noch nicht wie diese grafischen Oberflächen überhaupt funktionieren. Er implementiert ein paar Events aber er weiß gar nicht, wie und wer diese Events überhaupt auslöst. Er verwendet also Techniken, die er nicht versteht. Wenn er jetzt selber in einem Kommandozeilenprogramm ein oder zwei Events selber gebaut hat, dann bekommt er ein besseres Gefühl dafür, wer die Events in grafischen Oberflächen auslöst.