aber zu Software Architektur Modellen findet man deutlich weniger.
Das ist nicht ganz richtig... Man findet schon durchaus einiges, auch etwas was man in vielen Bereichen wiederverwenden kann. Es ist aber auch so, dass man im Bereich Enterprise Software viel mehr findet. Das ist wohl einfach etwas, womit sich sehr viele Entwickler beschäftigen, und wo es schon ziemlich viele etablierte/dokumentierte Architekturen gibt. Die meisten anderen Bereiche sind schon viel spezieller. Wenn du z.B. ein spezialisiertes CAD System schreiben musst, ist das vermutlich ein Thema, das nicht Millionen von Entwicklern interessiert, da findet man viel weniger. Aber ein bisschen was findet man schon.
Mich haben solche Fragen vor allem im Studium auch sehr stark beschäftigt. Und die Antwort ist wohl einfach Erfahrung, möglichst viel davon. Man kann oft auch einfacher sagen, warum eine Software schlecht ist, als warum sie gut ist.
Ich bin C++ Entwickler, da findet man noch weniger vorgefertige Architekturen. Ich schau z.B. gern öfter mal Videos von der cppcon und ähnlichen Veranstaltungen (wobei ich da mittlerweile auch wenig neues entdecken kann). Da finde ich sicher nicht DIE Idee, wie ich eine bestimmte Software angehe. Aber viele kleine Ideen, wie man etwas verbessern oder eleganter lösen könnte. Und das kann sich durchaus zu einem Gesamtbild zusammensetzen.
Honda hat wohl ein ähnliches Problem:
Das dürfte in nächster Zeit noch häufger auffallen.
Du hattest explizit das 13er XPS aussen vor genommen. Hat das keine Probleme mit der Wärmeentwicklung?
Ich nutze beruflich den XPS 15 und bin sehr zufrieden damit.
Bzgl. Linux für Entwickler, ich schätze die Kritik kommt jetzt ehr in Bezug auf .NET/Windows Entwicklung. Allgemein kann ich das nicht bestätigen. Ich war auch schon in Unternehmen die fast ausschließlich Linux Systeme für ihre Entwickler zur Verfügung stellten und damit sehr gute Erfahrungen gemacht haben. Alles eine Frage der Angewohnheit.
Es ist zum Teil auf jeden Fall eine Frage der Gewohnheit...
Ich habe im Studium jahrelang Linux als Hauptsystem verwendet (auf dem Laptop) und in einer Linux-Firma gearbeitet.
Zur Zeit habe ich das als Zweitsystem drauf, benutze das aber kaum. Und ich bin hauptsächlich C++ Entwickler, privat und beruflich.
Man sollte sich die Frage stellen, ob und warum man unbedingt auf Linux auf dem Arbeitsplatzsystem umsteigen will.
Wenn man die ganzen ideologischen Gründe usw. weglässt... Ich komme damit gut zurecht und mag das System auch. Es ist offen und flexibel und man kann mit Bordmitteln vieles anstellen, was unter Windows so ohne weiteres nicht gehen würde, und wofür man etwas zusätzliches bräuchte.
Warum benutze ich das trotzdem kaum?
- Ich mag VS
- Ich spiele auch öfter mal
- Ich verwende immer wieder auch etliche andere Programme, die es unter Linux nicht (oder nicht in der entsprechenden Qualität) gibt
- Und: eigentlich will ich meist gar nichts mit dem System machen. Linux zwingt oder verleitet mich zumindest sehr oft dazu, mich intensiver mit irgendwas zu beschäftigen, und etwas zu basteln. Das ist super, wenn man das will. Das war genau das, was ich im Studium wollte. Aber seitdem haben sich meine Interessen spezialisiert und verlagert, deswegen habe ich da kaum noch Lust drauf.
D.h. für mich lohnt sich das nicht, und Windows tut einfach unauffällig seinen Dienst und mehr brauche ich zur Zeit auch nicht.
MacOs würde für mich sowieso auf keinen Fall in Frage kommen.
Ich weiß, dumme Frage
Ähm... Ja?
Was genau ist die Frage? Du kannst z.B. völlig trivial eine jar erstellen, die man per Doppelklick starten kann. Wenn das deine Frage beantwortet. Gibts seit Java 1.1.
Und man findet auch problemlos Tools, die das in eine exe verpacken können, wenn einem das lieber ist.
Und davon abgesehen - Java hat hauptsächlich ganz andere Anwendungsgebiete, als etwas, wo man eine "ausführbare Assembly" braucht.
Ich weiß es nicht, ich will es eigenltich auch nicht raten. Gehe aber nicht davon aus.
Was mir erstmal auffällt, ist dass der Artikel überhaupt keinen guten Eindruck macht. Und was ich eigentlich sagen wollte, grad im Java Umfeld gibt es in den letzten Jahren durchaus einige Probleme. Die Frage, ob Java nicht ausstirbt, habe ich in den letzten paar Jahren schon sehr oft gehört.
wenn im Hintergrund sind die Compiler-Typen von Java auch nichts anderes, als bei C# (vermute ich zumindest)
Nein... Ich bin hauptsächlich C++ Entwickler und ziemlich Performance-fixiert, habe aber auch ein größeres Java-Unterprojekt (wegen Lucene, ist aber sehr viel darauf aufgebaut). Und die fehlenden Wertetypen in Java sind ein Riesenproblem, da kann auch der "Compiler" nichts optimieren.
@gfoidl: ich muss mich ehrlich wundern, dass der Compiler dass nicht sowieso optimieren kann. Gibt es konkrete Gründe, die das verhindern?
Ich finde auch, dass der Begriff "Big Data" viel zu allgemein ist.
Um mal ein Beispiel zu nennen, das wahrscheinlich in eine etwas andere Richtung geht, als das, woran du denkst.
Wir beschäftigen uns mit CAD Daten und Geometrien. Wir reden jetzt selber nicht von Big Data, und da wird die Komplexität nicht in Petabytes gemessen, aber die Anforderungen gehen durchaus in die gleiche Richtung. Die Verarbeitung und Auswertung ist komplex, kann z.B. bei einem Kunden durchaus Wochen dauern. Das ist auch nichts, wo wir einfach so beliebig viel Hardware bekommen, das ist es dem Kunden meist auch nicht wert, muss sich alles in Grenzen halten.
Optimieren wir seit Jahren und Jahrzehnten dran. Es werden immer mehr Daten und Anforderungen, die Hardware und vor allem der Code wird immer schneller, hält sich also mehr oder weniger die Waage (wir sind besser dran als vor Jahren).
Wir arbeiten hauptsächlich mit C++, also nichts Scala oder Python. Und keins der Bücher über "Big Data" würde uns weiterhelfen.
Also, was man in der Industrie alles braucht, kann sehr sehr unterschiedlich ausfallen.
Ich möchte mal zwei Punkte aus eigener Erfahrung anbringen.
- Was mich hier seinerzeit weitergebracht hatte, waren tatsächlich Designpatterns. Ich hatte Delphi programmiert, OOP "verstanden", aber den Nutzen nicht erkannt, deswegen zu 90% prozedural programmiert. Erst als ich das Design Patterns Buch von der GoF gelesen habe, habe ich mir öfter gedacht, cool, so hätte ich das auch machen können. Und dann hätte das auch plötzlich Sinn ergeben, von vornherein Klassen zu haben, und nicht Listen von Structs.
- Du schreibst, dass das was du findest, sich nicht direkt auf dein Problem anwenden lässt. Das ist zwar sehr oft richtig, und du musst vor allem lernen zu abstrahieren. Aber auch hier habe ich die Erfahrung gemacht, dass man für erstaunlich viele Probleme tatsächlich fertige Lösungen findet, evtl. muss man dafür nur umdenken und seinen Code umstrukturieren. Nur als Beispiel, ich hatte an etwas gebastelt, bei dem ich Undo/Redo haben wollte und hätt nie gedacht, dass ich dafür etwas finde, ist doch etwas sehr spezielles, wie das bei mir aufgebaut ist (Google war damals noch fast ein Geheimtipp, so leicht ist man nicht an Informationen gekommen). Ich war dann recht erstaunt, dass es dafür ganz einfache Patterns gibt, die auch bei mir problemlos funktioniert hätten.
sprich ich bin mir nicht sicher, ob ich irgendwelche "speziellen" Methoden anwenden soll, wie Factory Method, Dependency Injection o.Ä. .. also wann es Sinn macht bestimmte Konzepte zu implementieren...
Ich finde, das sind in dem Sinne nicht-funktionale Anforderungen. Also, eigentlich hätte ich sie schon als funktionale Anforderungen eingestuft, aber es geht aus der Spezifikation einfach nicht hervor. Von dem her kann man das so interpretieren, dass das völlig egal ist, so lange die dargestellte Funktionalität erfüllt ist.
Aber in einem richtigen System würde es von vielen weiteren Faktoren abhängen. Wir haben bei uns z.B. auch ein recht zentrales "Pipeline" System. Das ist zwar wahrscheinlich ziemlich anders, als das was von dir gefordert ist, dürfte aber prinzipiell auch eine gewisse Ähnlichkeit aufweisen.
Und sehr vieles ergibt sich da eben aus den Anforderungen und der Umgebung. Wir arbeiten z.B. mit C++, d.h. da geht man schon mal oft anders vor, als in C# oder Java, z.B. bei der Frage nach der Factory. Und das ist bei uns schon eine wichtige Frage, die mit vielen anderen Faktoren zusammenhängt.
Auch wie die Pipeline auszuführen ist, geht aus deinem Diagramm nicht hervor. Das ist bei uns z.B. auch eine ganze Menge Code, der sich in den letzten Jahren massiv weiterentwickelt hat, und wo wir viel gelernt haben. Oder wie der Datenaustausch zwischen den Knoten ausschaut.
Da kommen in einer richtigen Software einfach noch sehr viel mehr Fragen auf, die die Designentscheidungen dann massiv beeinflußen.