arlegermi

Auch das ist von IHK zu IHK unterschiedlich. Ich habe direkt nach der mündlichen Prüfung mein endgültiges Zeugnis in der Hand gehabt mit Stempel, Unterschrift und allem.

Bei so wenig Elementen kann man auch ein wenig Performanz gegen Lesbarkeit tauschen. Man kann das ganze in einem Aufruf schreiben: var distinct = liste.GroupBy(p => new { p.Vorname, p.Nachname, p.Geburtsdatum }) .Select(g => g.First()); Du gruppierst erst nach den Attributen, die für dich die Eindeutigkeit ausmachen und nimmst dann immer das erste Element der Gruppe. (Eine Gruppe ist im Prinzip nichts anderes als ein Dictionary mit mehr als einem Wert pro Schlüssel.) Was bei dir im Augenblick gar nicht berücksichtigt wird (ich weiß nicht, ob das für deinen Fall relevant ist), ist, welcher Personendatensatz genommen wird. Wenn du bspw. immer die Person mit dem höchsten Wert haben wolltest, könntest du das da oben leicht entsprechend anpassen: var distinct = liste.GroupBy(p => new { p.Vorname, p.Nachname, p.Geburtsdatum }) .Select(g => g.OrderByDescending(p => p.Wert).First()).ToList(); Zu deinem Code: Die Liste toRemove wird nirgends genutzt - weg damit. Dein tmpResults musst du nicht mit dynamic deklarieren - du kannst einfach in der Schleife mit var arbeiten, wie du es an anderen Stellen auch schon machst. Zudem finde ich deine Logik rund um das .Remove sehr anfällig für Fehler. Ich würde mich eigentlich immer davor hüten, den Schleifenzähler (i) innerhalb der Schleife zu manipulieren - das mag hier gut gehen, andere verwirrt's aber. Noch dazu manipulierst du die Liste, über die du gerade iterierst. Das geht mit einer for-Schleife zwar (mit einer foreach nicht!), macht die Sache aber auch nicht gerade übersichtlicher. Im Allgemeinen würde ich etwas, wo ich mehrere Listen brauche, die aber irgendwie alles das gleiche enthalten und die ich dann irgendwie miteinander verschneiden muss, mindestens in eine eigene Methode auslagern, die ich dann vernünftig benenne (in deinem Fall sowas wie SelectDistinctPersons(IEnumerable<Person> persons)) viel eher aber noch versuchen, das ganze so zu programmieren, dass es völlig offensichtlich ist, was du da tust. Das kannst du auf verschiedenen Wegen erreichen - einen hat dir @Whiz-zarD gezeigt, ich finde meinen auch nicht verkehrt (den obersten mit dem DistinctBy).

Ok, wenn du nichts externes nutzen darfst... Von wievielen Elementen in der Liste reden wir hier und wie oft musst du die filtern? Darf man dir Tipps zu deinem Code geben oder möchtest du im Augenblick nichts hören? Kann ich verstehen, wenn's dich jetzt nicht mehr juckt, aber man könnte da noch ein bißchen was dran drehen

Das denke ich auch. Und da du dich für IPMA doch auch regelmäßig (4 Jahre?) rezertifizieren musst, bringt es dir im Augenblick wahrscheinlich nicht viel. Wenn du Zeit und Lust dazu hast, mach's. Wenn nicht (und so klingst du), dann lass es sein. Ich glaube nicht, dass dir dieses Zertifikat viel helfen würde.

Das würde ich an deiner Stelle nicht denken. Es gibt immer Unternehmen, denen die Azubis entweder abspringen, oder die tatsächlich einfach keinen geeigneten gefunden haben (weil zu klein, nicht bekannt genug, ...). So war's bei mir auch - ich habe meine Bewerbungen auch erst im Juni des Jahres rausgeschickt (aus anderen Gründen) und hatte zum 01.09. eine Stelle. Du sollst natürlich nicht auf Teufel komm raus irgendwas annehmen, wo du dich nicht wohl fühlst, aber versuchen solltest du es auf jeden Fall noch. Manchmal hat man eben doch Glück Wenn du Bedenken hast, was deine Bewerbungsunterlagen angeht, dann stell' die doch mal hier im Forum rein und hör dir an, was so an Verbesserungsvorschlägen kommt.

Erstmal Glückwunsch dazu! Nur jetzt schon als Tipp: Kümmer dich jedes Jahr um dein Gehalt - warte nicht darauf, dass dein Chef dir von sich aus eine Erhöhung gibt.

Naja, der Standard-Wurf wäre ein DistinctBy: public static IEnumerable<TSource> DistinctBy<TSource, TKey>(this IEnumerable<TSource> source, Func<TSource, TKey> keySelector) { if(source == null) { throw new ArgumentNullException(nameof(source)); } var distinctSet = new HashSet<TKey>(); foreach(var element in source) { if(distinctSet.Add(keySelector(element))) { yield return element; } } } Das sähe für deinen Fall dann vom Aufrufen so aus: var distinct = liste.DistinctBy(p => new {p.Vorname, p.Nachname, p.Geburtsdatum}); Es gibt einige Libraries, die sowas enthalten, z.B. MoreLINQ. Musst du wissen, ob du für so eine Sache gleich 'ne ganze Library reinholen willst oder nicht einfach eine eigene Extension-Methode schreibst. Wenn man das ganz extrem sauber machen möchte, teilt man das noch in zwei Methoden auf: public static IEnumerable<TSource> DistinctBy<TSource, TKey>(this IEnumerable<TSource> source, Func<TSource, TKey> keySelector) { if(source == null) { throw new ArgumentNullException(nameof(source)); } return DistinctByImpl(source, keySelector); } private static IEnumerable<TSource> DistinctByImpl<TSource, TKey>(IEnumerable<TSource> source, Func<TSource, TKey> keySelector) { var distinctSet = new HashSet<TKey>(); foreach (var element in source) { if (distinctSet.Add(keySelector(element))) { yield return element; } } } Hat dann den Vorteil, dass die ArgumentNullException nicht erst geschmissen wird, wenn man wirklich über die Menge iteriert, sondern direkt an der Stelle, wo man die Methode aufruft (macht das Debuggen einfacher).

So wie du's vorhast, halte ich es immer für sinnvoll. Einfach offensiv mit solchen Dingen umgehen - wenn etwas nicht geklappt hat, dann ist das halt so. Ich hätte es an deiner Stelle dennoch auch in der Dokumentation erwähnt, einfach der Vollständigkeit halber. Kannst du jetzt nicht mehr ändern, also musst du damit souverän umgehen. Zum Fachgespräch: Kann sein, dass deine IHK das wirklich so strikt handhabt mit der 5/10-Trennung. War bei mir nicht der Fall, da kam man eben von einer Frage auf die nächste und das setzte sich dann die 15 Minuten fort. Dein Projekt wird sicher Ausgangspunkt der Fragenreihe sein und es macht auf jeden Fall Sinn, sich mit den Punkten, die dir da einfallen, auseinanderzusetzen, damit man ordentlich antworten kann.

Nein, du musst in deiner Präsentation nicht alles, was du (hoffentlich) in der Dokumentation schon beschrieben hast, unterbringen. Es bietet sich an, die "langweiligen" / "trivialen" Themen kurz abzuhandeln (ein Stichpunkt vllt., kommt drauf an) und sich auf die interessanten und schön zu präsentierenden Gesichtspunkte des Projekts zu konzentrieren. Du hast ja schließlich auch nur 15 Minuten Zeit - da kannst du gar nicht alles behandeln.

Grundsätzlich stimme ich dir zu, dass man für eine reine Android-App erstmal auch Java/Kotlin in Betracht ziehen sollte. Auf der anderen Seite macht Xamarin durchaus Sinn, wenn C# die Sprache der Firma ist. Dann ist es den Mehraufwand, den Xamarin mit sich bringt u.U. durchaus wert. Denn in Android Studio und eine neue Sprache steigt man auch nicht an einem Vormittag ein. Und mit Xamarin.Forms musst du auch nicht einmal mehr die Oberfläche getrennt entwickeln. Für einfache Apps ist das durchaus ausreichend und man kann mit etwas Übung auch komplexere UIs entwickeln. @Tician Xamarin von Grund auf anzufangen, sprich ohne vorgenerierten Code würde ich gerade einem Anfänger nicht empfehlen. Da ist sehr viel zeremonieller Code dabei, der "halt so sein muss". Die Gerüste, die man in Visual Studio hingestellt bekommt, sind schon gut so - das ist wie bei Windows Forms oder einer WPF-App. Da bekommt man ja auch ein Gerüst gestellt, das man dann füllt. So musst du dir das mit den Apps auch vorstellen. Ich finde ja die Einführung bei Microsoft eigentlich ganz gut: Hello, Android

Hast du dir das hier schonmal angeguckt? Ansonsten würde ich dir dazu raten, dich erstmal mit Xamarin, bzw. Android selber auseinanderzusetzen. Das ist halt eine ganz andere Plattform als Windows, da ist ein wenig Einarbeitung notwendig.

Auch wenn's fies klingt: Aber wenn deine Existenz von der Prüfung abhängt, dann kann man finde ich schon erwarten, dass du die auch bestehst. Die FI-Prüfungen haben einen Bestehensschnitt von 90+% - es ist wahrhaftig nicht so, dass da nur die besten durchkommen. Als jemand, der die Prüfung bestanden hat, bin ich dagegen, "Augen zuzudrücken", weil das meinen Abschluss ebenfalls abwertet und zu dem Problem beiträgt, dass eine Ausbildung gegenüber einem Studienabschluss nicht ernstgenommen wird.

Ich glaube es ging darum, dass die WBH eine private Hochschule ist und Hagen eine öffentliche / staatliche. Ob das jetzt ein Pluspunkt ist, sei mal dahingestellt.

Ein "Anhang" wird "angehängt". Also ja: Zusammen mit der Dokumentation abgeben.

Supported werden sowohl WinForms als auch WPF noch ein wenig (zuletzt prominent das High-DPI Upgrade in .NET 4.7(?)). Neuentwicklung fließt so gut wie ausschließlich nach UWP. Interessant ist die Ankündigung, sowohl WinForms als auch WPF nach .NET Core 3 zu porten, bzw. lauffähig zu bekommen. Beides ist also nicht wirklich tot und gerade WinForms hat noch massig Legacy-Anwendungen, die auf die nächsten Jahre hin existieren werden, gepflegt und erweitert werden müssen. WPF ist in meinen Augen nie so wirklich abgehoben, ist allerdings für reine Desktop-Neuentwicklungen schon zu empfehlen. Einem Neuling würde ich aber eher von WPF abraten, da es meiner Erfahrung nach schnell sehr komplex wird mit Themen, die man als Einsteiger nicht so leicht durchdringt (XAML bspw. finde ich stellenweise extrem umständlich - wenn auch sehr mächtig). Ich halte es für völlig ok, die Grundlagen anhand von WinForms zu lernen und dann später mit einem vernünftigen Fundament an WPF ranzugehen. Worauf man bei WinForms darauf achten sollte, ist, dass man sich nicht dazu verleiten lässt, Oberfläche und Logik komplett miteinander zu vermengen, wozu einen das Framework zuweilen schon mal verleitet.

Was genau aus der SO-Antwort verstehst du denn nicht? Da steht doch, wie man eine Text-Datei einliest und die Befehle daraus dann ausführt.

Ich habe meinen Vertrag damals ~2 Monate vor der mündlichen Prüfung unterschrieben. Dass ich übernommen werde, war eigentlich von Anfang an klar, mündlich zugesagt wurde es mir ca. 3 oder 4 Monate vor der mündl. Prüfung. Vier Wochen finde ich schon ziemlich knapp - da würde ich auch langsam anfangen, einen konkreten Termin zu forcieren. Am Ende läuft's sonst darauf hinaus, dass du dich gehetzt fühlst, den Vertrag zu unterschreiben, weil du keine andere Option hast. Ich würde also mal zu deinem Chef gehen und einen konkreten Termin vereinbaren, an dem ihr über deinen Vertrag redet (möglichst diese oder nächste Woche). In dem Termin macht ihr dann auch aus, wann der Vertrag dir vorgelegt wird zur Unterschrift (idealerweise auch das nächste Woche).

Wenn man nach "eval PowerShell" sucht, kommt man auf sowas: https://stackoverflow.com/questions/4836703/powershell-how-to-evaluate-a-string-read-from-a-file Das sollte als Start nützlich sein.

Ich glaube, das stellt man sich als Außenstehender häufig komplexer vor, als es wirklich ist. Das alltägliche Problemlösen besteht zu einem großen Teil darin, das vorhandene zu lesen und zu entdecken, wo's schiefläuft. Das kann mitunter mal ausarten und zu richtiger Detektivarbeit verkommen, häufig ist's aber recht eindeutig. Zum Beispiel habe ich gerade ein Ticket reinbekommen, dass bei uns in der Software Pfade nicht richtig manipuliert werden - anstatt bspw. das "c:\" (also den Laufwerksteil) komplett abzuschneiden, wird nur das "c" entfernt, was dann an einer anderen Stelle natürlich zu Problemen führt. Das lässt sich total einfach nachvollziehen und die Stelle, wo das passiert, ist auch klar. Ich werde jetzt also heute vormittag einfach an der Stelle dieses Verhalten korrigieren. Das hat nichts mit komplexen Algorithmen oder Systemarchitekturen zu tun - im Endeffekt ist es nur das richtige Abzählen von Zeichen. Und ich würde behaupten, dass das den Großteil der Arbeit eines "normalen" Entwicklers ausmacht. Selbstverständlich gibt's auch die größeren Probleme und bei Neuentwicklungen ist auch schon etwas mehr Können gefordert, damit es zukunftssicher ist - aber das kommt einfach mit der Zeit und macht dann (zumindest mir) auch richtig Spaß. Auch wenn man manchmal nach ein, zwei Monaten draufguckt und sich fragt, wer denn jetzt die blöde Idee da hatte (und man sich dann schämt, weil man's selber war ).

@Byteschubser hat erstmal recht, dass das von IHK zu IHK unterschiedlich ist. "Meine" IHK hat das so gemacht, dass ich die Note der Dokumentation erst mit der Note der Präsentation und des Fachgesprächs bekommen habe.

46k p.a. ist mit einem Jahr BE doch schon echt ordentlich. Im öD wird bei EG9 die Luft langsam dünn als Nicht-Studierter, das hilft dir auch die Erfahrung irgendwann nur noch bedingt. Im Sinne einer Karriereplanung wäre also der Wechsel in meinen Augen auf jeden Fall sinnvoll. Allein auch die Tatsache, dass Gehaltssteigerung und Entfristung "zufällig" erst nach dem neuen Angebot kamen, würde mir persönlich übel aufstoßen. Das bedeutet, dass die Möglichkeit da war, man aber versucht hat, den Preis zu drücken.

@Mr Crowley: Sobald das Projekt intern beschlossen ist, ist es ein "gültiges" Projekt für die Abschlussarbeit. Im Normalfall wird kein Unternehmen ein Projekt genehmigen, das nur Geld kostet, aber keinen Mehrwert bietet. Woraus dieser Mehrwert besteht, kann sich von Fall zu Fall unterscheiden (erhöhte Produktivität, gesteigerte Kundenzufriedenheit, geringere Fehlerquote, ...).

Bei mir war's so, dass ich die Dokumentation an sich alleine geschrieben habe (weil ich auch tiefer im Thema war als mein Betreuer) und sie am Ende zur Durchsicht meinem Betreuer und einem Kollegen gegeben habe, die dann Anmerkungen (zum Großteil stilistisch) gegeben haben. Murks hätte mich mein Betreuer auch nicht abgeben lassen. Vielleicht ist der Betreuer des TE aber auch einfach nicht so erfahren, was die IHK Prüfung angeht und konnte schlecht einschätzen, was eigentlich gefordert wird. In dem Fall sollte man dem TE raten, sich mit seinem Betreuer hinzusetzen und dafür zu sorgen, dass das dem nächsten Azubi nicht nochmal passiert.

Das kommt auf die IHK (und das Projekt) an. Ich muss auch @M Kreis zustimmen: Punkt 3 wirkt auf mich so, als würdest du Dinge wie die Verkabelung (in orange) als genauso wichtig erachten wie das übergreifende Konzept, bzw. die Probleme, die du lösen möchtest. Das ist ein Wust aus Zahlen, trivialen Informationen und Klick-Beschreibungen, der in einer Dokumentation an sich nichts zu suchen hat in der Form. Ich sage mal nichts zu einer Note, aber eine 1 oder 2 ist das in meinen Augen nicht.

Ich meine, dass das mit dem Arbeiten nach der Schule so ist, dass wenn du weniger als 8 (Zeit-)Stunden Schule hast, du theoretisch noch im Büro aufkreuzen müsstest, wenn dein Arbeitgeber das fordert. Das gilt aber meine ich auch nur, wenn du dann noch mehr als 'ne halbe Stunde arbeiten müsstest, sobald du im Büro angekommen bist.