Whiz-zarD

Und wie lief es?

So einer wie dich, wird keiner nehmen wollen. Sorry aber das ist so. Du blickst nicht über den Tellerrand und bist auch recht naiv. Das IT-Handbuch vom Rheinwerk Verlag kratzt lediglich nur an der Oberfläche und bietet und beinhaltet bei weitem nicht alles, was man als Entwickler oder Systemintegrator benötigt. Es bietet also nur ein Rundumblick, was es da so gibt. Da habe ich einige Bücher zu einem bestimmten Thema hier stehen, die schon so dick sind, wie das IT-Handbuch selbst.

Lass mich raten: Blinder Hass gepaart mit Ahnungslosigkeit... Gerade C# ist eine der schönsten objektorientierte Sprachen, die man derzeit in der Wirtschaft findet. Java hinkt da meilenweit hinterher. Wie man PHP vorziehen kann, ist mir auch ein Rätsel. Da man immer mehr zu single-page-applikationen geht, wird die Verbreitung von PHP auch immer weniger. C++ wirst du in der Wirtschaft auch immer weniger sehen, da man die Sprache fast ausschließlich nur noch für hardwarenahe Entwicklung verwendet.

Wie man ein Link in HTML setzt, findest du nicht selbst heraus? Eine Quelle, wo du es finden kannst: https://www.w3schools.com

Zu 1) Klingt danach, als gäbe es ein Drop-Down-Menü, in der die Nutzer aufgelistet werden. Zu 2) Die Datenbank soll selber erstellt werden. Siehe den anderen Thread vom TE: Zu 3) Das Wort "Verlinkung" verwendet nur der TE. In der Aufgabenstellung steht, dass es Links geben soll, die zu einer weiteren Webseite führt. Zu 4) Da fehlt wohl noch ein ` am Ende der Query. Ich muss aber auch sagen, dass so eine Aufgabe für jemanden, der eine Ausbildung anfangen möchte, einfach zu viel ist. So etwas stellt man vielleicht Junior Entwickler, um deren Wissen zu überprüfen aber keinen potenziellen Anwärter für eine Ausbildung. Entweder hat der Betrieb kein Plan oder die suchen wirklich eine billige Arbeitskraft.

An welches Gerät willst du den stick überhaupt anstecken?

Eher, dass auf Teufelkommraus unbedingt alles eine grafische Oberfläche haben muss und in der sich alles abspielt und den Azubis OOP gar nicht beibringt.

Hier mal ein Zitat aus Wikipedia (https://de.wikipedia.org/wiki/Aggregation_(Informatik)): Bei einer Aggregation können die Objekte auch ohne die Aggregation leben. Dies wäre z.B. beim "Dependency Injection" der Fall, wenn wir die Abhängigkeiten in eine Klasse reinreichen: public class Ehe { Person Mann; Person Frau; public Ehe(Person mann, Person frau) { this.Mann = mann; this.Frau = frau; } } Es müssen also zuerst die Personen erzeugt werden, bevor wir die Ehe erzeugen können. Die Personen können also ohne die Ehe leben. Bei einer Komposition hingegen könnte ein Objekt nicht alleine leben, was ein anderes Objekt erzeugt hat. Es ist dann also so, dass in einem Objekt (z.B. Haus) ein weiteres Objekt (z.B. Stockwerk) erzeugt wird und wenn das Haus-Objekt löscht wird, werden auch die Stockwerk-Objekte gelöscht. Beispiel public class Haus { private Stockwerk erdgeschoss; public Haus() { this.erdgeschoss = new Stockwerk(); } }

Ist zwar schön und gut und trotzdem wird keine Firma jemanden einstellen, der nur Erfahrung mit RPG hat, wenn sie einen Java-Entwickler suchen, weil dieser erst mal in Java geschult werden muss. Kannst ja mal @MarcoDrost fragen, wie viele Java-Entwickler er an die Firmen vermittelt hat. Mit Sicherheit werden das nur sehr wenige gewesen sein, wenn überhaupt. Das Werkzeug sollte man also schon beherrschen, wenn man sich anderweitig bewirbt.

Noch mal: Wozu braucht man Mocks? Mocks sind nichts weiter als ein Hilfskonstrukt und ein eher Zeichen, dass mit der Softwarearchitektur irgendwas nicht stimmt. Wenn man Mocks benötigt, hat man Abhängigkeiten. Sei es auch nur Abhängigkeiten zu Interfaces. Die Abhängigkeit ist aber da. Ohne ein Objekt, was ein bestimmtes Interface implementiert, kann ein anderes Objekt nicht leben. Die Frage ich aber, sind diese Abhängigkeiten überhaupt notwendig? Die reale Welt zeigt es doch deutlich: Nein. Als Beispiel hast doch der Blinker genannt. Wozu brauche ich dann nun ein Pseudo-Auto mit einem Pseudo-Motor, wenn ich nur den Blinker testen will? Stell dir eine Werkbank vor und auf dieser Werkbank liegt ein Blinker. Aus welchen Bauteilen besteht ein Blinker? Aus einem Blink-Relais, aus Kabeln und einem Leuchtmittel. Ich kann den Blinker also in seine Einzelteile zerlegen und einzeln testen. Ans Blink-Relais lege ich eine Spannung an und prüfe, ob das Relais auf und zu geht. Dem Leuchtmittel lege ich auch eine Spannung an und prüfe, ob sie leuchtet. Dann verbinde ich beide Teile mit einem Kabel (unsere Komposition) und lege wieder eine Spannung ans Relais an und siehe: Das Leuchtmittel blinkt. Wunderbar! Blinker getestet. Nächstes Bauteil... Das mache ich solange, bis ich alle Bauteile eines Autos getestet habe und kann nun die Teile ins Auto stecken und das Auto testen (wieder eine Komposition). Man sieht also, dass ein Mock-Objekt gar nicht von Nöten ist. Das Testen von Kompositionen wären dann die Integrationstests und das Testen einzelner, elementarer Bauteile wären unsere Unittests. Und hier noch mal zum Thema Inversion of Control und Dependecy Injection: Wann wird das mal wirklich benötigt? Beispiel Auto: Wenn ich sowieso nur ein Auto baue und das immer mit den selben Komponenten, wozu brauche ich dann Dependency Injection? Dependency Injection wird doch häufig nur des SOLID wegens implementiert aber oftmals wird das gar nicht benötigt. Man bläht also seine Anwendung nur unnötig auf. Dependecy Injection wird doch häufig nur verwendet, um tatsächlich Mock-Objekte in sein zu testendes Objekt stecken zu können aber überträgt man dies in die reale Welt, kommt doch was völlig absurdes raus: Man spricht immer davon, dass Softwareentwicklung ein Handwerk sei also wieso seinen Code nicht so entwickeln und testen, wie ein Handwerker seine Arbeit verrichtet? Ein Kfz-Mechatroniker braucht doch auch kein Motor aus Pappmaché, wenn er den Blinker testen will. Die Austauschbarkeit wird also nur häufig nur des Testen-Willens vorgeschoben. Im Produktionscode ist aber die Austauschbarkeit gar nicht gefordert. Vielleicht hat man nur eine Art von Blinkern. Man baut also in den Produktionscode ein Hilfskonstrukt nur für den Test ein. Für mich persönlich klingt das einfach völlig absurd. Dependency Injection bzw. Inversion of Control lässt sich auch durch Kompositionen realiseren, indem ich ein Interface und eine abstrakte Klasse für die Komposition erschaffe und für meine unterschiedlichen Konfigurationen in Klassen auslagere. Beispiel: public interface IKomposition { void TuEtwas(); } public abstract class KompositionBase : IKomposition { protected IAbhängigkeitA AbhängigkeitA { get; private set; } protected IAbhängigkeitB AbhängigkeitB { get; private set; } public KompositionBase(IAbhängigkeitA abhängigkeitA, IAbhängigkeitB abhängigkeitB) { this.AbhängigkeitA = abhängigkeitA; this.AbhängigkeitB = AbhängigkeitB; } public abstract void TuEtwas(); } public class KompositionA : KompositionBase { public KompositionA() : base(new AbhängigkeitA1Impl(), new AbhängigkeitB1Impl()) { } public override void TuEtwas() { /// Code } } public class KompositionB : KompositionBase { public KompositionB() : base(new AbhängigkeitA2Impl(), new AbhängigkeitB2Impl()) { } public override void TuEtwas() { /// Code } } Also kann ich doch die Klassen AbhängigkeitA1Impl, AbhängigkeitA2Impl, AbhängigkeitB1Impl und AbhängigkeitB2Impl einzeln testen und dann im Integrationstest KompositionA und KompositionB. Und siehe da, ich brauche nicht mal ein DI-Framework oder Mock-Objekte. Ein DI-Framework macht wirklich nur dann Sinn, wenn ich Kompositionen(!) über eine Konfiguration zusammenstecken möchte. Beispielsweise ich habe mehrere Kunden und Kunde A möchte, dass die Logs in die Datenbank geschrieben werden und Kunde B Logs in eine Datei oder Kunde A verwendet MSSQL und Kunde B OracleDB und ich möchte nicht für den Kunden ein eigenes Kompilat ausliefern. Diese Art von Konfiguration wird aber in vielen Fällen im Code gar nicht benötigt. Wer z.B. eine App ausliefert, die bei allen Kunden sowieso gleich funktioniert, braucht so etwas eigentlich gar nicht. Dann gehörst du leider zu den Personen der Ignoranten, die nicht mal neue Wege ausprobieren und ihre Erfahrungen teilen. Sorry. Leider besteht die Softwarentwicklung hauptsächlich nur aus Versuch-und-Irrtum und es geht darum, immer wieder neue Wege zu finden, wie man sich die Arbeit erleichtern kann. Gäbe es z.B. Robert C. Martin und andere, die das Clean Code voranbringen, nicht, würde man heute immer noch seitenlangen Spaghetti-Code in Excel und Access schreiben und lehren. Auch ein Softwareentwickler sollte sich weiterbilden und schauen, ob seine es inzwischen nicht andere Wege gibt, wie man Software entwickelt. Solche Sturköpfe habe ich auch in der Firma, wo ich arbeite und was produzieren sie? Unwartbaren und unleserlichen Spaghetti-Code, der in Regions und Kommentar-Blöcken geclustert wird und dann steht man dort vor einer 15.000 zeiligen Klasse, wo ReSharper schon schlapp macht, diese zu analysieren.

Der Thread kann auch geschlossen werden, da sie hier nicht mehr aktiv ist.

Das ist das sog. Inversion of Control bzw. das Dependecy Injection. Beides sind aber im Grunde nur Patterns, um Klassen zu strukturieren. Allerdings birgt dieses Pattern weitere Probleme, weil man Mock-Objekte benötigt, um solche Klassen testen zu können, da eine Klasse die Funktionalität einer anderen Klasse aufruft. Inzwischen bin ich bei einem Punkt angelangt, wo ich von Dependecy Injection wieder weggehe und den Code in einen funktionalen- und integralen-Teil zerlege und die Integration die Funktionen zusammenstöpselt. Ich bin da zwar noch dabei Erfahrungen zu sammeln, weil das echt ein Umdenken erfordert aber so fühlt sich Objektorientierung irgendwie richtiger an. Man braucht einfach keine großen Dependency Injection- und Mocking-Frameworks, um überleben zu können, sondern einfach nur die Sprachfeatures. Wenn ich einen Blinker testen will, wozu brauche ich da ein Pseudomotor? Baust du auch ein Motor aus Pappmaché, um einen Blinker zu testen? Nein. Du testest die Glühlampe und dann das Blinker-Relais. Und genau das ist doch das Problem vom Dependecy Injection: Teile, die ich gar nicht testen will, muss ich erst mal nachbauen, weil trotzdem die Funktionalität benötigt wird.

Ich mag UML zwar überhaupt nicht und habe mich schon seit Jahren nicht mehr damit befasst aber ich denke, dass die Komposition will eher darauf hinaus, wie die Objektorientierung tatsächlich mal gedacht war und nicht, wie sie gelebt wird. Oft sieht man ja folgendes Konstrukt: public Class A { public void Foo(int i) { int x = i * 3; B b = new B(); b.Bar(x); } } Es sind aber drei Dinge, die in der Methode Foo() stattfinden: Berechnung von x Instanzierung von B der Aufruf von Bar() Dies verstößt aber eigentlich gegen die Definition der Objektorientierung von Alan Kay. Aus meiner Sicht kommt dann hier die Komposition ins Spiel. Die Komposition würde die einzelnen Logikschritte teilen und sie stattdessen in eine Komposition zusammenführen: public class Komposition { private A a; private B b; ... public void DoSomething(int i) { b.Bar(a.Foo(i)); } } public class A { public int Foo(int i) { return i * 3; } } public class B { public void Bar(int x) { ... } } Bei der Analogie des Menschens könnte die Komposition so aussehen: public class Mensch { private Herz herz; private Aorta aorta; ... public PumpeBlutInDieAorta() { this.aorta.Blut = this.Herz.PumpeBlut(); } } Somit wird deutlich, dass der Mensch ein Herz braucht. Ohne die Aorta oder ohne das Herz gäbe es eine NullReferenceException. Der Mensch wäre also nicht lebensfähig. Das Herz oder die Aorta lassen sich aber einzeln instanziieren und gezielt testen. So kann man ja auch im wirklichen Leben einem Menschen das Herz entfernen und per elektrische Impulse zum Schlagen bringen. Übertragen auf die Softwareentwicklung wären die elektrischen Impulse der Unittest. Wir schicken ein Signal ins Herz rein und erwarten eine Antwort. Wenn man diese Art- und Weise der Entwicklung durchzieht, braucht man fürs Testen nicht mal Mock-Objekte oder Dependency Injection, weil man die Anwendung in einen Integralen-, und Logik-Teil trennen würde. Den Logik-Teil kann man dann sehr leicht mit Unittests testen und der Integrale-Teil wäre ein Teil des Integrationstests. So ist also denkbar, dass das Herz auch nur eine Komposition ist und aus weiteren Teilen besteht, die dann wiederrum einzeln getestet werden können. Die Aggregation war für mich immer ein optionaler Teil, der auch fehlen kann. Bei der Analogie eines Menschens würde mir da spontan nur die Haare einfallen, die wachsen: public class Mensch { IList<Haar> haare; ... public void LasseHaareWachsen() { foreach(Haar haar in this.haare) haar.Wachse(); } } Somit kann der Mensch keine Haare haben aber der Mensch würde trotzdem leben.

Was zum Geier? Das using hat hier überhaupt nichts zu suchen ... Das using ist für das IDisposable-Interface und dieses Interface dient fürs Aufräumen vom Speicher von unmanaged Code. Wenn du das Haus nur innerhalb eines Blockes haben willst, dann setze es doch ein ein Block: { var house = new House( new List<Room> { new Room(windowCount: 1), new Room(windowCount: 3) { Name = "dining" } }); house.Garage = garage; Console.WriteLine("house in a using statement"); Console.WriteLine(house.ToString()); Console.WriteLine("leaving using statement"); } @ Topic: Eine Aggregation assoziiert "ein Besitz". z.B. ein Forum besitzt Mitglieder. Das Forum kann aber auch ohne Mitglieder bestehen. Oder eine Garage besitzt ein Fahrzeug. Die Garage besteht aber auch, wenn kein Fahrzeug drinnensteht. Eine Komposition assoziert "ein Teil". z.B. das Herz ist ein Teil des Menschens. Ohne ein Herz kann ein Mensch nicht leben. Oder ein Raum ist ein Teil eines Gebäudes. Ohne ein Raum existiert auch kein Gebäude.

Ich hab ein Netzteil mit 1,5A Ausgangsseitig. Besser wäre aber 2A oder mehr. Ich hab das Problem, wenn ich mal eine Festplatte ranhänge, dann startet der Raspberry neu, weil das Netzteil beim Anfahren der Festplatte in die Knie geht. Kann aber auch vielleicht daran liegen, dass das Netzteil schlecht verarbeitet ist und die verbauten Kondensatoren nichts taugen.

Der einzige, der nicht rechnen kann, bist du.

Dein Fehler ist wohl, dass du entweder nicht richtig schreiben oder lesen kannst.;) Also nochmal: Ich habe zwei Kredite: Kredit 1 Nomineller Betrag: 77.000 € Abtrag 272,21 € Tilgungsrate: 1% Kredit 2 Nomineller Betrag: 50.000 € Abtrag: 188,77 Tilgungsrate: 1% Also eine Gesamtsumme von 127.000 €. Die Summe beider Abträge beträgt 460,98 €. Bei Kredit 1 habe ich die Möglichkeit jährlich eine Sondertilgung von max. 5% des nominellen Betrags zu leisten. Im klartext ich kann ein mal im Jahr 3.850 € bezahlen (77.000 * 0,05 = 3.850 €). Ich habe vor (und bin auch gut dabei) jedes Jahr die Sondertilgung in Anspruch zu nehmen. Die Laufzeit beträgt 15 Jahre. D.h. 3.850 * 15 = 57.750 €. Also in diesen 15 Jahren habe ich im Idealfall 57.750 € an Sondertilgungen bezahlt. Während dieser Zeit tilge ich aber jeden Monat weiterhin den Kredit, sodass nach diesen 15 Jahren die Summe sehr geschrumpft sein wird. Ich habe gerade den Zins- und Tilgungsplan nicht im Kopf aber ich meine mich zu erinnern, dass dann der Kredit vollständig abbezahlt sein wird. Dann bleibt der KfW-Kredit. Diesen betrachte ich aber erst mal zweitrangig. Die Investitionsbank steht eh auf Rang 2 und steht unter behördlicher Regulation.

Wenn, du es nicht kapierst, dann kann ich auch nichts für ... Natürlich ist das niedrig. Mein Finanzberater hat auch dazu geraten, erst mal mit 1% Tilgung anzufangen und später auf 1,5% aufzustocken, was ich auch noch vorhabe und außerdem die Sondertilgung in Anspruch nehmen. Dann wird von den 77.000 € nach 15 Jahren nicht mehr viel übrig bleiben. Den KfW-Kredit betrachte ich erst mal zweitrangig. Einen Abtrag muss ich so oder so bezahlen. Entweder an die Bank oder an den Vermieter und derzeit bezahle ich deutlich weniger als an einen Vermieter und ich sehe nicht, wieso das plötzlich anders sein sollte. Selbst nach 15 Jahren sehe ich das noch nicht so und ja, die Wohnung liegt auch demografisch sehr gut und hat auch in den letzten Jahren an Wert gewonnen.

Das sind 5% von der Summe des Kredites. Also 5% von 77.000 € macht 3.850 €. Also kann ich jährlich einmal 3.850 € an die ING-Diba bezahlen. (weitere Sondertilgungen sind mit Gebühren verbunden) Ich habe noch mal nachgeschaut. Ich bezahle an die ING-Diba 272,21 € und an die KfW 188,77 €. Macht zusammen 460,98 €. Dann noch das 191,00 € Wohngeld an die Verwaltung. Dann liege ich bei 651,98 €. Mit Strom, Internet, Telefon, etc. liege ich bei 850 €. Wie du auf die 900 € allein nur für den Kredit kommst ist mir ein Rätsel.

Es ist eine 65m² 2-Zimmer Wohnung mit Tiefgarage. (110.000 € für die Wohnung; 17.000 € für die Tiefgarage). Für ein Kind ist die Wohung zu klein das stimmt aber für zwei Personen ist sie sehr gut geeignet, da sie sehr gut geschnitten ist und selbst wenn ich die Wohnung mal vermieten sollte, dann trägt sich die Wohnung von alleine. Die Sondertilgung liegt bei 5%. Nicht 50% Die Laufzeit der Kondition vom ING-Diba-Kredit liegt bei 15 Jahren. Der KfW-Kredit läuft 20 Jahre. Das heißt aber nicht, dass man nach 15 Jahren den Kredit abbezahlt haben muss, sondern dann werden die Konditionen neu verhandelt.

Heutzutage muss man den Kredit eh teilen. Keine Bank gewährt dir ein Kredit über die vollständige Summe. Du wirst also ein Kredit der KfW und ein Kredit deiner Bank bekommen müssen. Ich habe für meine Wohnung 127.000 € bezahlt. Das macht 50.000 € von der KfW und 77.000 € von der ING-Diba. Die Tilgungsrate bei der ING-Diba liegt bei 1%. Theoretisch hast du recht, dass man dafür sehr lange zahlen muss. Aber man hat heute Standardmäßig die Option einer 5%igen Sondertilgung pro Jahr. Ich lege also pro Monat etwas Geld bei Seite, sodass ich am Ende des Jahres die Sondertilgung in Anspruch nehmen kann. Somit ist das Geld im Laufe des Jahres erst mal nicht weg und ich kann es auch für ungeplante größere Unkosten verwenden. Der ING-Diba-Kredit ist mir erst mal wichtiger, da sie im ersten Rang im Grundbuch stehen. Mit Hilfe der Sondertilgung versuche ich erst diesen Kredit zu tilgen und laut Zins- und Tilgungsplan wäre dies auch in 15 Jahren durch. Dann bleibt nur noch der KfW-Kredit. Man muss also nicht bei 3% anfangen. Man muss nur wissen, wie man das Geld verteilt. Ich liege jetzt schon mit beiden Krediten unter einer Monatsmiete. Mit allen Nebenkosten (Kredite, Hausgeld, Strom, Wasser, ...) liege ich bei 850 €. Eine Kaltmiete liegt in diesem Haus bei ca. 750 €.

Ich wohne im speckgürtel von Hamburg und verdiene unter 50k und bin alleinverdiener und kann mir locker eine Eigentumswohnung leisten und am Ende des Monats ist noch genug Geld übrig.

Und der Rest? Du schränkst aber aber auch schon den Verwendungszweck von UML ein und zwar nur für die Dokumentation. UML sollte aber auch für die Modellierung nützlich sein und da ist die Schwierigkeit von UML. UML ist für die Modellierung ungeeignet. Man erkennt nicht, ob der Ersteller der Diagramme das Problem komplett verstanden hat. Komplexe Abläufe sind in den Diagrammen nur sehr schwer zu verstehen. Wenn ich mir hier einige Diagramme anschaue, die man in der Vergangenheit gezeichnet hat, denke ich mir "Wtf?". Da kann ich mir auch gleich den Code anschauen. Viel schlauer wird man aus den Diagrammen auch nicht. Das nächste ist, dass sich daraus kein Code generieren lässt. So kann der spätere Code vom Diagramm abweichen. Für sowas sind DSL-Ansätze sinnvoller. Darum verwendet man UML eigentlich nur noch aus Dokumentationsgründen und nicht für die Entwicklung und in diesem Punkt hat UML einfach versagt.

Und warum dann nicht einfach eine Plattform verwenden? Gerade im IT-Bereich ist z.B. Pluralsight eine sehr gute Anlaufstelle und da ist eigentlich für jeden etwas bei. Sei es das Management, der Product Owner, der UI-Designer, Softwarearchitekt, Administrator, Entwickler, etc. und die Kosten sind überschaubar. Man muss ja nicht gleich zu einem zwei-wöchigen Seminar hinrennen, der unfassbar viel Geld schluckt und man nicht weiß, ob dieser was bringt. Ich finde, im ersten Schritt sollte man mal von neuen Dingen gehört haben, um sie vielleicht mal zu testen und wenn man es für sinnvoll erachtet, das neuerlernte Wissen anzuwenden, kann man ja mal weiterschauen, ob dann eine tiefergehende Schulung mit einem Trainer sinnvoll ist. So kommt man viel eher zu einer Entscheidung, als wenn ich aus heiterem Himmel zum Chef renne und sage, dass ich eine Weiterbildung will.

UML ist aus meiner Sicht einfach nicht wirklich wichtig. DIe Praxis zeigt deutlich, dass UML versagt hat. Kaum keiner verwendet diese Diagramme und selbst die IHK kennt wohl die Unterschiede einzelner Diagramme nicht. Daher wäre es wohl besser, nur das absolut nötigste zu lehren, damit sie die Prüfung bestehen, damit mehr Zeit für andere Dinge bleiben. Viel wichtiger finde ich das tiefgründige Wissen. Angefangen mit einfachen Datentypen und warum z.B. Fließkommazahlen für Geldbeträge ungeeignet sind. Dann Zeiger bzw. Referenzen (Call by Value, Call by Reference) und dann Datenstrukturen, z.B. Stapelspeicher, Mengen, Listen, Bäume, etc.