Whiz-zarD

Mit den Kacheln würde ich ganz vorsichtig sein. Am besten überhaupt nicht mehr benutzen. SUBDOMAIN TAKEOVER : Microsoft verliert Kontrolle über Windows-Kacheln

Soll also quasi eine Linie zwischen den beiden Punkten gezogen werden? Können die Felder auch diagonal erreicht werden oder nur horizontal und vertikal? Wenn sie auch diagonal erreicht werden können, dann schaue dir den Bresenham-Algorithmus an. Dieser wurde eigentlich entwickelt, um eine Linie auf dem Bildschirm zu zeichnen aber den könnte man auch hierfür verwenden.

Einfach mal den Chef fragen.

Die Schreibweise FROM TABLE1, TABLE2 WHERE TABLE1.Id = TABLE2.Id ist eine alte Schreibweise, die durch die Joins abgelöst wurde. Der Query Optimizer des DBMS baut daraus ein Join, weil Joins performanter sind. Durch die Joins sollte zudem erreicht werden, dass die Verbindung zwischen den Tabellen von der Where-Klausel getrennt wird. Somit steht in der Where-Klausel nur das drinnen, wonach wirklich gefiltert werden soll, während in der From-Klausel die Daten zusammengesetzt werden. Ein Right Join kommt in der Praxis auch recht selten vor. Meist verwendet man entweder ein Left oder ein Inner Join, weil dadurch die Queries einfacher zu lesen sind und eher dem entsprechen, wie Menschen denken.

Zum anderen fehlt noch die Erbung der Kfz-Klasse.

Wieso if-then-else? Die Berechnung steht doch in der Aufgabe. Das ist nur nur ein abtippen.

Der Code ist auch genug Dokumentation. Nur in dem Code steckt die Wahrheit. Separate Dokumentationen können lügen.

Du hättest dich als C#-Entwickler auch als Junior Java-Entwickler bewerben können. C# und Java sind vom Grundkonzept nicht sehr verschieden.

Ich hab mir es mal mit dem AutoMapper angeschaut. Das Problem ist wohl, dass die Properties Key und Value im KeyValuePair nicht gesetzt werden können. Sprich, sie besitzen nur einen Getter und keinen Setter. AutoMapper kann daher die Properties wohl nicht setzen. Außerdem würdest du mit deiner Idee kein Dictionary<Guid, PriceValue> bekommen, sondern List<KeyValuePair<Guid, PriceValue>> Das ist was anderes.

Wieso verwendest du AutoMapper dafür? Du kannst auch ganz einfach die ToDictionary()-Methode von LINQ verwenden. var dict = priceValues.ToDictionary( keySelector: x => x.CurrencyId, elementSelector: x => x ); Oder habe ich da was falsch verstanden?

Es gibt nun mal nicht für alles einen vorgefertigten Lösungsweg. Die sind aber essentiell für die Lösung. z.B. ist überhaupt nicht klar, ob die Paletten gedreht oder sogar gestapelt werden können oder ob auch die Last im LKW verteilt werden muss, also z.B. ob schwere Paletten unten liegen und dann leichtere Paletten oben drauf? Davon war bis jetzt nie die Rede und erfordert mehr als hier bekannt war, denn es muss nicht nur ausgerechnet werden, welche Paletten nun dazu führen, dass die Ladung optimal verteilt werden, sondern es müssen ja noch die Positionen der einzelnen Paletten bestimmt werden, wo sie sich dann im LKW befinden. Ich denke auch nicht, dass es hier einen einfachen Rechenweg gibt, sondern hier muss man wohl mit Kombinatorik ran. Sprich, man muss alle Kombinationen durchspielen und überprüfen, was die beste Kombination ist. Ich würde also die Liste der Paletten nehmen und mir die erste Palette schnappen und über ein Interationsverfahren alle Kombinationen mit allen anderen Paletten raussuchen, die die Fläche des LKWs bzw. das Volumen des LKWs, sofern Paletten stapelbar sind, nicht überschreiten, denn das sind die Kandidaten, die in den LKW reinpassen könnten. Nun muss man mit der Liste der Kombinationen rumspielen und schauen, welche der Kombinationen tatsächlich in den LKW passen. Dafür muss dann die Länge, Breite und sofern Stapelbar die Höhe berücksichtigen. Hier steckt der meiste Gehirnschmalz drinnen. Wenn man dann mögliche LKW-Beladungen gefunden hat, wählt man die mit der größten Fläche bzw. mit dem größten Volumen und streicht diese Paletten aus der Gesamtliste und fängt von Vorne an.

Wer googlen muss, ist kein echter ITler.

Der Code ist nicht kompilierfähig, da die Variable cruisefuelgtog nicht deklariert wurde.

Ganz ehrlich? Ich würde das Thema WPF und besonders MVVM weglassen, denn ich denke, dass es wenig Sinn macht, damit zu arbeiten, wie es gedacht war, da die Grundlagen der (objektorientierten) Programmierung eindeutig fehlen. Ich brauche mir da nur den Code der Konsolenanwendung sehen und sehe da sehr viele Probleme. Z.B. das eher nach struktureller Programmierung vorgegangen wurde, anstatt objektorientiert. Im MVVM zu erklären, müsste man wohl damit anfangen, was überhaupt Klassen sind. Wenn es nicht unbedingt eine grafische Oberfläche sein soll, würde ich sie auch lassen, da eben gewisse Kenntnisse Voraussetzungen sind, um überhaupt zu verstehen, was man da eigentlich macht. Wenn es aber eine grafische Oberfläche haben soll, würde ich mal die Benutzersteuerelementen in den raum werfen.

Dann soll der Chef mit offenen Karten spielen, anstatt so einen Bullshit zu reden. Letzen Endes ist es immer noch die Entscheidung von @DieMstar, ob er/sie dort bleiben möchte, oder nicht. Ein Chef hat das zu akzeptieren und man hält keine Mitarbeiter, wenn man denen eine Waffe vor die Brust hält. Schließlich kann man auch ein ruhiges Gespräch führen und sagen, was Sache ist, wenn der Chef tatsächlich bedacht war, ein Ausbildungsvertrag anzubieten. Und du würdest sie dann anbrüllen, dass sie auf dem Stuhl sitzenbleiben soll? Dein Beispiel hinkt nämlich komplett. Wenn sie fragen würde, ob ich auch was vom Imbiss haben möchte, dann weiß sie nämlich nicht, dass ich was koche und ich kann sie darauf hinweisen und brülle sie nicht an, dass sie gefälligst auf dem Stuhl zu sitzen hat. Sehe ich genauso. Überstunden sind eine Ausnahme und nicht die Regel. In den meisten Arbeitsverträgen kann ein Chef zwar Überstunden verordnen aber auch nur wenn es wirklich nicht anders geht und es darf kein Dauerzustand sein. Wenn es ein Dauerzustand ist, dann wird hier eindeutig misswirtschaft betrieben, indem man die Mitarbeiter absichtlich verschleißt, weil die Mitarbeiter das Spiel ja mitspielen.

Kann ich bestätigen. Noch schlimmer sieht es eigentlich nur noch in der Spielebranche aus, wo keine Azubis ausgebildet werden, sondern noch eine Stufe runtergeht und Praktikanten sucht, die ein Pflichtpraktikum absolvieren müssen. Die muss man erst gar nicht bezahlen.

Da fragt man sich, wieso man für so einen Chef arbeitet?

Davon gehe ich auch sehr stark aus. Wenn man nach vorhandenen Kenntnissen fragt, ist eine Sache, aber schon gezielt nach Programmiersprachen und Frameworks nachzufragen und einen potenziellen Kandidaten gleich zwei Tage antanzen zu lassen, klingt nicht gerade so, als wollen sie jemanden ausbilden, sondern einfach eine billige Arbeitskraft unter dem Deckmantel einer Ausbildung.

Man muss das immer relativ betrachten. Programmcode kann man in der Regel verständlicher schreiben, als Stored Procedures, weil sie nun mal sehr viele Restriktionen haben. Die Frage ist: "Was ist wichtiger? Lesbarer Code oder bessere Performance?" Ist es wirklich wichtig, dass der Nutzer schnellstmöglich eine Antwort erhält? Oder kann er auch mal ein paar Sekunden warten? An der Software, an der ich arbeite, wurden ebenfalls sehr viele Kennzahlberechnungen als Stored Procedure abgelegt. Die Folge ist, dass sie sehr komplex sind und sie kaum einer noch versteht. Das Debugging ist extrem schwierig. Es wurden Tablefunctions verwendet, die wie gesagt, nicht mit dem Debugger debugged werden können. Da ist man wieder dabei, nach alter Väter Sitte, Ausgaben auf der Konsole zu machen, um zu sehen, was passiert. Ich bin der Meinung, man sollte erst mal mit einem lesbaren und verständlichen Code anfangen und erst dann, wenn die Performance zwickt, sollte man sich über die Performance unterhalten.

Sehe ich persönlich nicht so. Stored Procedures haben zwar den Vorteil, dass sie von der Datenbank auf Fehler überprüft werden aber man verschiebt nur die Logik, die sonst im Programmcode steht, in die Datenbank und das kann je nach Szenario Probleme bereiten. Wenn man anfängt, für jeden Kleinkram eine Stored Procedure zu schreiben, müllt man die Datenbank damit zu. Zumal die Verwaltung von Stored Procedures eh sehr schlecht ist. Ein anderes Problem ist, wenn die Stored Procedure mehrere Werte oder sogar ganze Tabellen zurückliefern soll. Tabellen als Rückgabewert ist z.B. in MySQL sowieso nicht möglich. Bei Oracle gibt es die sog. Tablefunctions aber die haben einen sehr großen Programmier-Overhead und lassen sich auch nicht debuggen.

Dann musst du eh fragen. Aus Erfahrung sind solche Frameworks eh nicht dokumentiert und du musst dich selbst dort einarbeiten.

Da wirst du sowieso nicht drumherumkommen. Kann ja auch sein, dass sie einen O/R-Mapper verwenden, wie z.B. Entity Framework. Es ist für mich sowieso erstaunlich, wie viele Firmen heutzutage immer noch mit stumpfen SQL-Abfragen direkt auf die Datenbank gehen und daraus immer manuell selbst die Datenobjekte erzeugen, anstatt ein O/R-Mapper zu verwenden.

Ich kenne mich mit Visual Basic auch nicht aus, da ich mit C# arbeite. (Keine Ahnung, wie man heutzutage eh auf die Idee kommt, mit Visual Basic zu arbeiten) aber offenbar handhabt Visual Basic die Events ein bisschen anders. Es steht wohl direkt in der Methoden-Signatur. Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click End Sub

Ja, wenn du diese Methode dem Klick-Event zugewiesen hast.

Was ist aber, wenn du nicht weißt, was aufgerufen werden soll? Das Problem hast du ja bei den Events, wenn du eine grafische Oberfläche entwickelst. Für jedes Element einer grafischen Oberfläche gibt es ja zig Events. Beispiel wäre ein ja Klick auf ein Button. Woher soll der Button jetzt nun wissen, was passieren soll? Das programmierst du nun mit Hilfe eines Delegates und weist dem Delegate eine Methode zu. button1.Click += Button1_Click; // ... private void Button1_Click(object sender, EventArgs e) { // Code } Nun weiß der Button, dass er die Methode Button1_Click() aufrufen soll, wenn das Click-Event ausgelöst wurde. Ohne den Delegates müsstest du eine Ableitung vom Button schreiben und dort Methoden überschreiben. Das würde dazu führen, dass du für jedes Element auf der Oberfläche eine Ableitung benötigst.