Whiz-zarD

SELECT Kunde.*, Maschine.MaschineID, Laufzeit.Stunden FROM Kunde INNER JOIN Maschine ON Maschine.KundeID = Kunde.KundeID INNER JOIN MaschinenTyp ON MaschinenTyp.MaschineTypID = Maschine.MaschineTypID INNER JOIN ( SELECT Laufzeit.MaschineID, SUM(Laufzeit.Stunden) AS Stunden FROM Laufzeit INNER JOIN Maschine ON Maschine.MaschineID = Laufzeit.MaschineID WHERE Laufzeit.Datum > Maschine.DatumLetzteWartung GROUP BY Laufzeit.MaschineID ) Laufzeit ON Laufzeit.MaschineID = Maschine.MaschineID WHERE Laufzeit.Stunden + 100 > MaschinenTyp.WartungsintervallInStunden

Für mich sieht es sogar so aus, dass die zweite Schleife falsch ist und jetzt deine Lösung richtig ist. Die zweite Schleife macht ja keinen Sinn. Sie durchläuft ja nun die Spalten der Zeilen aber das ist nicht nötig, da die Spalten über einen Index angesprochen werden. Du könntest aber die Zeilen: kopierezeile(liste, fehler, i, aktuellezeilefehlerarray) aktuellezeilefehlerarray++ in: kopierezeile(liste, fehler, i, aktuellezeilefehlerarray++) ändern. Das hat den selben Effekt, da das Doppel-Plus eine Post-Inkrement-Operation ist. D.h. es wird nach dem Abrufen des Wertes dieser inkrementiert.

Klar, mein Hobby ist auch Dokumente für Fake-Projekte schreiben...

Wenn es eine Neu-Entwicklung ist, muss es ja einen Grund geben, wieso die Anwendung neu entwickelt wurde und das ist dein Ist-Zustand.

Hä? Du schreibst deine Projekt-Dokumentation nicht während deiner Abschlussarbeit, sondern davor? Nur zur Info: Das ist Betrug...

Es gibt da kein Richtig oder Falsch. Junior und Senior sind keine offiziellen Berufsbezeichnungen und somit auch keine standardisierte Begriffe und jede Firma definiert es anders. Daher kann Gulp.de noch so viel darüber schreiben. Es ist und bleibt eine Entscheidung der Firma.

Wenn ich mir das Diagramm anschaue, kommt es mir sowieso an dieser Stelle falsch vor. Ich vermute mal, dass get(k) einfach nur die Filiale aus der Liste holen soll aber nach dem Diagramm erhöht die get()-Methode die Gehälter. Also anstatt: public void erhoeheGehaltMitarbeiter(double x) { var i = meineFilialen.Size(); for(var k = 0; k <= i; k++) { var filiale = meineFilialen.get(k); var meineMitarbeiter = filiale.getMeineMitarbeiter(); var z = meineMitarbeiter.Size(); for(var j = 0; j <= z - 1; j++) { // ... } } } steht dort einfach nur: public void erhoeheGehaltMitarbeiter(double x) { var i = meineFilialen.Size(); for(var k = 0; k <= i; k++) { meineFilialen.get(k); } } Und die get()-Methode erhöht dann das Gehalt, was aber nicht klappen kann, da die Methode x gar nicht kennt. get() müsste also einen Rückgabewert zur Zentrale zurückgeben.

Ja, Size() holt die Größe der Liste, um damit die Austrittsbedingung der for-schleife zu definieren. Heutzutage würde man das aber mit einer foreach-Schleife lösen.

Was verstehst du denn dort nicht? Das ist eine Schleife, die über die Fillialen läuft. Innerhalb dieser Schleife gibt es eine weitere Schleife, die alle Mitarbeiter durchläuft und bei allen Mitarbeitern, die nicht Fillialleiter sind, wird das Gehalt erhöht.

Stimmt. Hab die Klassen per Copy/Paste in Notepad++ erstellt. Also ohne IDE.

Es ist halt dafür dar, um für Datentypen unterschiedlicher Art einen Eingangspunkt zu ermöglichen. z.B. einer formatierten Ausgabe von Strings: Console.WriteLine("Hallo {0}, ich bin {1} Jahre alt.", "Welt", 42); // Ausgabe: // Hallo Welt, ich bin 42 Jahre alt. "Welt" ist ein String (Objekt) und 42 ein Integer (Wertetyp). Damit die WriteLine()-Methode mit den unterschiedlichen Datentypen umgehen kann, nimmt sie ein object-Array entgegen (man sieht das Array nicht, wegen dem params-Schlüsselwort). D.h. die 42 wird in ein object konvertiert (boxing). Die Methode nimmt sich dies sogar zum Vorteil, da object die ToString()-Methode besitzt und die 42 kann direkt in ein String umgewandelt werden, da es ja nun ein object ist.

Inzwischen schreibt man auch nicht mehr: Square square = new Square(...); sondern: var square = new Square(...); und überlasst den Kompiler den Rest. Die Angabe, um welchen konkreten Datentypen es sich handelt, ist nur eine doppelte Information, da wir mit new Square(...) schon den Datentyp kennen.

Die abstrakte Klasse hat zwar keine Funktionalität, dennoch bräuchte ich neben dem Interface eine abstrakte Klasse, die die Color-Eigenschaft besitzt. Ohne diese abstrakte Klasse müsste ich weiterhin in den konkreten Klassen (Square und Circle) die Eigenschaft implementieren. Mit der abstrakten Klasse habe die Color-Eigenschaft nur ein mal implementiert und spare somit Code und potenzielle Fehlerquellen.

Das Thema hat absolut nichts mit Boxing und Unboxing zu tun, denn Boxing und Unboxing ist was anderes. Boxing und Unboxing wird verwendet, um Wertetypen (integer, double, ...) in Objekte zu wandeln (boxing) und von Objekten wieder zurück in Wertetypen (unboxing). Beispiel für Boxing: int i = 123; object o = i; // boxing Beispiel für Unboxing: o = 123; i = (int)o; // unboxing So etwas wird verwendet, wenn man z.B. eine Liste mit unterschiedlichen Datentypen hat: var list = new List<object>(); In diese Liste kann dann alles reingeschrieben werden. Sei es z.B. Strings oder Integers. Das Thema, was @redstav anspricht, ist "Vererbung" und Vererbung ist die Haupteigenschaft der Objektorientierung. Abstrakte Klassen können nicht instanziert werden. Sie können nur vererbt werden, wie in dem Beispiel. Mit abstrakten Klassen können nämlich Grundgerüste geschaffen werden, die dann mit den Subklassen verfeinert werden können. Das Grundgerüst garantiert uns, dass die Subklassen die Eigenschaften und Methoden der abstrakten Klasse besitzt. Dein Beispiel finde ich aber nicht so toll, da es die abstrakten Klassen schlecht veranschaulicht. Ich versuche es mal mit einem anderen Beispiel: Angenommen wir wollen geometrische Figuren auf dem Bildschirm malen. Wir haben ein Quadrat und ein Kreis und wollen sie als Klassen abbilden. Beide Figuren sollen später mit einer Farbe ausgefüllt werden und sollen eine Methode besitzen, die dafür sorgt, dass die Figur auf dem Bildschirm gemalt wird. Fangen wir naiv an: public class Square { public double Width { get; } public Color Color { get; } public Square(double width, Color color) { this.Width = width; this.Color = color; } public void Paint() { // Malt Quadrat auf den Bildschirm } } public class Circle { public double Radius { get; } public Color Color {get; set;} public Square(double radius, Color color) { this.Radius = radius; this.Color = color; } public void Paint() { // Malt Kreis auf den Bildschirm } } Nun haben wir zwei tolle Klassen. Nun kommt die Vererbung ins Spiel: Wir sehen, dass der Aufbau beider Klassen dort recht identisch ist. Also können wir eine Grundgerüst - also eine abstrakte Klasse - bauen: public abstract class Shape { public Color Color {get; set;} public Square(Color color) { this.Color = color; } public abstract void Paint(); } public class Square : Shape { public double Width { get; } public Square(double width, Color color) : base(color) { this.Width = width; } public override void Paint() { // Malt Quadrat auf den Bildschirm } } public class Circle : Shape { public double Radius { get; } public Circle(double radius, Color color) : base(color) { this.Radius = radius; } public override void Paint() { // Malt Kreis auf den Bildschirm } } Square und Circle besitzen nun durch die Vererbung die Eigenschaften von Shape. Mit der abstrakten Paint()-Methode geben wir dann noch zusätzlich an, dass die Methode zwar in den Subklassen zur Verfügung steht aber die konkrete Implementierung in den Klassen Geschehen muss. So wird dann garantiert, dass alle Klassen, die von Shape erben, auch die Paint()-Methode besitzen. Dies ist jetzt nämlich vom Vorteil, denn wir wollen ja geometrische Figuren auf dem Bildschirm zeichnen. Derjenige, der jetzt dafür sorgt, dass die Figur auf dem Bildschirm gezeichnet wird, muss nämlich nicht wissen, ob es nun ein Quadrat oder Kreis ist, sondern muss nur wissen, dass sie vom Typ Shape sind: public class Screen { public void Paint(Shape shape) { shape.Paint(); } } Screen screen = new Screen(); Square square = new Square(12.5, Color.RED); Cirlce circle = new Circle(10, Color.BLUE); screen.Paint(square); screen.Paint(circle); Die Paint()-Methode in der Screen-Klasse muss also nicht den konkreten Datentyp (Square oder Circle) wissen (ansonsten müssen wir jeden Typ eine eigene Methode schreiben), sondern muss nur wissen, dass die Klasse vom Typ Shape sein muss, um die Paint-Methode aufrufen zu können. In den Klassen Square und Circle erkennt man auch, dass beide zwar vom Typ Shape sind aber beide haben unterschiedliche Eigenschaften. Einmal Width (Square) und Radius (Circle). Das sind Eigenschaften, die zwar die konkreten Klassen kennen aber Shape nicht: Shape s1 = new Square(10, Color.BLUE); Console.WriteLine(s1.Width); // funktioniert nicht, da wir angebenen haben, dass s1 ein Shape-Objekt ist und Shape Width nicht kennt. Square s2 = s1; Console.WriteLine(s2.Width); // funktioniert, da s1 ja ein Square ist und wir sagen, dass s2 ein Square ist.

Und welches ominöse Tool für "Big Data" habt ihr installiert?

Was ist eigentlich genau die Aufgabe?

Das hat doch aber absolut nichts mit Big Data zu tun... Big Data sind unstrukturierte Datenmassen aus unterschiedlichen Quellsystemen. Eine (No)-SQL-Datenbank kann nur eine von vielen Quellsystemen sein. Es kann aber auch die Bilder einer Überwachungskamera ein Quellsystem sein oder die Werte eines Sensors oder Log-Dateien, etc. All diese Daten werden in einem Cluster gespeichert und können dort verknüpft werden.

Wieso will man dafür das Rad neuerfinden? Wenn es nur maximal 10 Benutzer sind, dann kann man auch Confluence kostenlos benutzen.

Wie wäre es einfach mit einer Gruppe in einem der unzähligen Messenger? Wenn einer was schreibt, bekommen dies auch alle mit.

Wann benötigt man dann die komplette Infrastruktur des Unternehmens, um irgendwas vorab zu testen? Für gewöhnlich testet man immer im kleinen Stil und wenn man es für gut empfunden hat, kann man es sich überlegen, dies auch im Unternehmen einzuführen. Niemand würde auf die Idee kommen an produktiven Systemen rumzuschrauben und zu experimentieren, sondern immer in einer kleinen Testumgebungen. Kein Arbeitgeber würde dir eine komplette Kopie der IT-Infrastruktur zum Test zur Verfügung stellen.

Ich würde mal behaupten, dass man privat viel mehr Mittel zur Verfügung hat, als beruflich, da beruflich es um die Wirtschaftlichkeit geht. Da hat man nun mal nicht 4 Tage Zeit, um sich mal ein neues Framework oder eine neuen Webserver anzuschauen. Wenn es ein Problem gibt, dann muss es schnell gelöst werden und nicht schön. Also verwendet man die alten Paradigmen und Techniken weiter, weil die jeder kennt und zur Routine gehören. Da können die Paradigmen und Techniken auch ruhig veraltet und schlecht seien aber so hat man es dann immer gemacht und so versteht es auch jeder. Privat hat man aber die Zeit, mal andere Wege für ein Problem auszuprobieren. Wer sich also privat nicht weiterbildet, wird schnell zu den Entwicklern gehören, die den Anschluss verpasst haben.

Man setzt doch keine Pattern ein, damit man hinterher sagen kann, dass man Patterns benutzt hat. Man setzt Patterns ein, weil man sie für ein bestimmtes Problem als nützlich erachtet hat und man stößt mit der Zeit auf die Patterns, wenn man nach Lösungen für bestimmte Probleme sucht. Niemand setzt sich hin und lernt ein Buch über Design Patterns auswendig. Es ist aber evtl. hilfreich sich ein Buch zu kaufen und mal darin zu stöbern.

DSPs sind eigentlich dazu gedacht, das Signal zu verarbeiten. z.B. Frequenzfilterung, Implemtierung von Effekten (Echo, Hall, ...) oder Spracherkennung. Bei Techniken wie z.B. EAX oder A3D wurden DSPs in den Soundchip integriert aber aufgrund der Tatsache, dass sowas heutzutage CPU-seitig erledigt werden kann und es auch noch kaum standisierte Schnittstellen gibt, um Hardware-DSPs anzusprechen, bestehen Soundchips heutzutage überwiegend noch noch aus einem D/A-Wandler für die Ausgänge und ein A/D-Wandler für die Eingänge. Siehe dazu auch den AC'97- oder HD Audio-Standard von Intel.

Heutzutage macht der Soundchip aber nichts mehr großartiges. Er koordiniert nur noch die Ein- und Ausgänge. Sowas, wie damals EAX oder A3D, macht heute die CPU und nicht mehr ein separater Teil des Soundchips. DirectSound wurde inzwischen auch schon aus DirectX rausgeworfen und gegen XAudio 2 ausgetauscht. XAudio 2 stellt programierbare DSPs bereit, die aber auf dem CPU ausgeführt werden. Das ist nur noch eine Sache des verbauten D/A-Wandlers. Ja, auf den teuren Soundkarten wird ein besserer D/A-Wandler verbaut, als bei Onboard-Chips, wer aber seinen Rechner per HDMI/Optical an einen Verstärker/A/V-Receiver anschließt, wird keinen besseren Klang haben, nur weil eine teure Soundkarte im Rechner werkelt, weil das Audiosignal 1:1 weitergeleitet wird. Und der Software-Equalizer, den man häufig findet? Berechnet die CPU und bei Onboard-Chips hat sie das schon immer getan. Damals war die CPU um die 20% nur mit dem Audiokram von Onboard-Chips ausgelastet und man sollte eine Soundkarte kaufen, um die CPU zu entlasten. Das fält heutzutage alles weg. Das ist eigentlich schon immer mit Boardmitteln möglich gewesen. Ich spreche da aus Erfahrung. Es gibt sehr viele Spieler, die einen USB-Kopfhörer nehmen, weil der Bass dort noch intensiver ist. Razor bringt doch jetzt auch Bluetooth-In-Ear-Kopfhörer für Gaming auf den Markt. Da Spielt der Soundchip auch keine Rolle.

https://www.govdata.de/ http://opendata.cern.ch/ Aber sicher, dass du nicht "Big Data" einfach mit "große relationale Datenbank" gleichsetzt?