perdian

Ich habe (immer noch) keine Ahnung, was du uns mit diesem Satz sagen möchtest. Formulier dein Problem bitte so, dass man versteht was du möchtest und das ganze nicht zur Raterunde verkommt.

Aktienhandel.

Infos worüber? Wenn du Hilfe haben möchtest muss du deutlich präziser werden!

Was du machen möchtest ist komplett entgegen jeglicher objektorientierter Ansätze und wirkt deshalb auch unnatürlich und schwierig für dich. Was musst du machen? Die Zwei-Minuten-Lösung gibt es da leider nicht - du solltest dich intensiv mit dem Konzept OO im Allgemeinen und Java im Speziellen beschäftigen und wirst, wenn du das ganze verstanden hast, automatisch zu deiner Lösung kommen.

Der Vergleich hinkt gewaltig. C und moderne Sprache (wie z.B. Java aber auch C# oder andere) lassen sich nicht 1:1 vergleichen. Genauso wenig wie Äpfel und Birnen. Was hauptsächlich Tatsache geschuldet ist, dass reines C deutlich weniger komplex ist als Java. Man muss sich nicht mit Objektorientierung beschäftigen sondern kann ein Makroassemblerkommando an das nächste schreiben. Ja, man sieht schneller Erfolge und glaubt schneller zu einem Ergebnis zu kommen, wirklich besser lernt man das ganze aber nicht - im Gegenteil. Der Maßstab darf eben nicht sein "Wann kann ich ein lauffähiges Programm schreiben" sondern "wann kann ich ein sinnvolles und gut strukturiertes Programm schreiben".

Ich schließe mich einem meiner Vorredner an: "Was ist schon normal?". Es gibt nicht den optimalen Ablauf, wie eine Ausbildung auszusehen hat. Ich habe schon Leute gesehen, denen sehr genau und sehr detailiert Detailwissen vermittelt wurde, die sich dann aber beschwert haben, weil sie keinerlei Möglichkeiten hatten auch selbst aktiv zu werden und sich damit zu beschäftigen, was sie selbst gerade für wichtig hielten. So hat da jeder eine anderen Meinung darüber, was richtig ist. In deiner konkreten Situation gibt es aber eine ganz einfache - erste - Möglichkeit: Sprich mit dem/den Verantwortlichen bei dir im Unternehmen über deine Meinung. Erläutere ihnen, dass du der Meinung bist deine Ausbildung könnte besser verlaufen und leg ihnen dar, an was für Bespielen (die du hier ja auch aufgezeigt hast) du das festmachst. Im Idealfalle erkennt dein Gegenüber "Stimmt, da sollte/könnte etwas anders laufen" und die Welt ist in Ordnung. Wenn nicht kannst du immer noch überlegen, wie deine Reaktion darauf ist aber Schritt 1 sollte sein erstmal auf das Problem aufmerksam zu machen.

Das mag in der Theorie so sein, aber in der Praxis stellt sich das ein wenig anders dar. Ich würde jemanden, der frisch von der Uni kommt und noch in keinem (Software-)Projekt gearbeitet hat, nicht als Fachkraft im Sinne von "wir suchen Fachkräfte" bezeichnen. Das sind Juniors, die sich erst noch die Hände schmutzig machen und lernen müssen auch in der Realität klarzukommen. Oftmals - nicht immer - sind das aber nicht die Leute, die man haben möchte. Das kommt auf die gegebene Situation und die ausgeschriebene Stelle an. Wenn es darum geht eine eCommerce Prozesskette abzubilden, ich jemanden mit eCommerce Erfahrung suche und es bewirbt sich jemand, der seine Diplomarbeit in Compilerbau geschrieben hat und seitdem nur als wissenschaftlicher Assistent gearbeitet hat ist er für mich für die bei mir ausgeschriebene Stelle nicht qualifiziert. Punkt. Dagegen kann jemand komplett ohne "richtigen" Abschluss, der aber schon jahrelang in dem Bereich unterwegs ist, die Tücken und Fallstricke kennt genau der richtige sein. Laut deiner Definition wäre es keine Fachkraft - für mich aber genau die Fachkraft, die ich gerade suche. Ich habe mehr als einmal Leute gesehen, die eine ganze Reihe Projektmanagementkurse belegt hatten und dann in der Umsetzung des ganzen mehr als kläglich gescheitert sind. Laut Theorie ausgebildete Fachkraft. Laut Praxis nicht brauchbar. Da ist es mir ziemlich egal, wenn jemand sagt "Ja, aber wir haben X Leute mit Nachweis Y für Tätigkeit Z, die auf Jobsuche sind". Wenn sie den Job dann aber nicht adäquat machen können bringt mir das alles nichts.

Ne, nicht wirklich - auch wenn es in der Beschreibung durchaus Überschneidungen gibt. Ich habe selbst schon erlebt, dass die Geschäftsführung einfach nur Profile an Zeitarbeitsfirmen rausgegeben hat mit dem Kommentar "Wir haben da jetzt keine Zeit für, liefert uns da mal was passendes".

Nein, nicht wirklich. Gerade zu Beginn lässt sich der gesamte OO-relevante Teil doch wunderbar "herausmocken". Du erklräst den Anfängern, dass sie eine Klasse erstellen sollen, die eine Main-Methode enthält. Damit können sie anfangen und das Programm starten. Wieso es eine Klasse geben muss und wieso die Einstiegsmethode gerade die Signatur "public void main(String[] args)" haben muss kannst du wunderbar erklären als "Da gehen wir später drauf ein, für den Moment braucht ihr einfach nur zu wissen, dass es das geben muss und so heissen muss". Da sehe ich überhaupt kein Dilemma.

Ist das so? Ich habe vom Elektro- und Metallbereich nicht wirklich Ahnung, aber bei allem, was ich sehe sind Angebote von Zeitarbeitsfirmen im IT-Bereich sehr selten. Ich erinnere mich nicht daran, bei meinen Suchen (oder zwischendurch, wenn ich mal einfach aus Interesse nachgesehen habe was auf dem Markt so los ist) überhaupt eine Zeitarbeitsfirma aufgetaucht ist. Aber selbst wenn: Was ist so schlimm daran für eine Zeitarbeitsfirma zu arbeiten? Das ist korrekt. Versuch mal einen guten Javaentwickler zu finden, der nicht beim Thema "dynamische Proxies der Virtual Machine" schon fragend aussteigt bzw. wirklich Ahnung davon hat, wie man ein Softareprodukt strukturiert. Die Frage ist eben immer: Was bezeichnet man genau als Fachkraft? Nur einen entsprechenden Abschluss in der Tasche zu haben reicht da IMO nicht aus. Das dürfte von Firma zu Firma ganz unterschiedliche Gründe haben. Ein Grund, der mir immer wieder selbst aufgefallen ist: Zeit. Es bewerben sich (natürlich je nach Firma, Region und anderen Feinheiten) eine Menge Leute auf eine ausgeschriebene Stelle, die eigentlich nicht wirklich qualifiziert dafür sind. Warum das so ist steht auf einem anderen Blatt und ist jetzt nicht das Thema, aber es ist dann für einen Arbeitgeber natürlich aufwändig die Spreu vom Weizen zu trennen. Teil des Jobs, natürlich - aber wenn man das outsourcen kann und diese Arbeit auf die Zeitarbeitsfirmen abwälzen kann... wem soll man das verübeln? Von besseren Konditionen bzgl. Kündigungsrecht etc. mal ganz zu schweigen.

Das bedeutet aber noch lange nicht, dass jeder Programmieranfänger bei PHP landet. Es könnte auch einfach ein Zeugnis dafür sein, dass die Leute, die bei PHP landen bzw. damit anfangen sich überhaupt nicht wirklich damit beschäftigen wollten und/oder die Komplexität derartig falsch einschätzen, dass man sobald es nicht mehr weitergeht sofort nach Hilfe schreit anstatt erst einmal zu überlegen: Was sind die Grundlagen, die ich mir aneignen sollte und die es zu verstehen gilt. Die theoretischen Grundlagen aber sind vollkommen sprachunabhängig. Dann solltest du dir mal den Markt ein wenig genauer ansehen. Ein nicht unerheblicher Teil von Programmierung findet momentan serverseitig statt. Das kann die klassische serverseitige Skriptsprache sein, die "nur" Webseiten erzeugt, geht aber oft weit darüber hinaus. GUIs (das, was du beschreibst) ist nur ein Teilbereich. Sich darauf zu beschränken und nur das als "richtige" Programmierung zu beschreiben ist eine sehr engsirnige Betrachtung der Realität.

Amen! +1

Kurz und knapp: Ja! Das hängt von der JDBC Treiberimplementierung ab. Es gibt Implementierungen, die versuchen im finalize Block Ressourcen zu schließen, andere (z.B. Oracle) tun dies nicht. Dazu kommt aber das Problem, dass von der VM nicht sichergestellt wird, dass finalizer überhaupt aufgerufen werden! Das bedeutet um sicher zu gehen, dass die Ressourcen korrekt geschlossen werden muss du dies manuell tun.

Das stimmt - wobei der Fokus klar auf dem ergänzen sein sollte. Wer meint mit dem "von Kopf bis Fuß" Buch hinterher das Thema zu können liegt falsch. Das ganze ist (wirklich!) gut dafür einen anderen Blick auf das Thema zu bekommen und es auchmal "von der Seite" zu sehen, aber wer meint nach dem ausschließlichen Lesen dieser Lektüre fit im Thema zu sein, der täuscht sich meiner Meinung nach gewaltig. Dann stelle ich mir aber auch wieder die Frage: Lohnt es sich für den Themenneuling dann überhaupt damit anzufangen, wenn es für die praktische Arbeit sowieso noch ein "ordentliches" Buch hinterher sein muss, damit man die Inhalte wirklich versteht und verinnerlicht? Geschmackssache, das muss jeder für sich selbst herausfinden, aber ich denke wer wirklich etwas lernen will, dem ist nur mit dem Buch alleine nicht geholfen.

Ansichtssache. Ich habe sie in zwei anderen Bereichen gelesen und bin eher enttäuscht. Das ganze kommt hier und da viel zu spielerisch herüber und anstatt ein bisschen mehr Tiefgang hier und da wird man mit irgendwelchen platten Witzen und scheinbaren Erfahrungen zugeworfen. Mag für den absoluten Anfang ganz gut sein, aber wenn man aus dem Sandkasten heraus möchte halte ich das schon nicht mehr für wirklich sinnvoll.

Eine Datenbank halte ich da für ziemlichen Overhead, da das ganze auch immer für verschiedene Deployment-Szenarien kopiert und installiert werden muss. Ich habe für die "Vokabeln" immer eine ganz klar definierte Properties-Datei, die als Master dient (nehmen wir hier als Beispiel de_DE). Alle Änderungen werden erstmal nur in der Masterdatei vorgenommen, erst anschließend werden alle Sprachen nachgezogen. So kann ich sicher sein, dass wenn sizeof(en_US) < sizeof(de_DE) ist noch Dinge nachgezogen werden müssen. Bei umfassenderen Änderungen kann man auch mit einem kleinen Skript die Properties einzeln durchlaufen und fehlende/überflüssige Einträge finden. Professionelle Übersetzer kommen auch direkt damit klar, denen liefert man dann die Master-Properties Datei und erhält direkt die lokalisierte Zielversion. Was Kundenanpassungen angeht gibt es verschiedene Möglichkeiten - entweder ein Superset von allen möglichen Vokabeln, die bei den Kunden im Einsatz sind, was solange funktioniert wie eine Vokabel nicht bei zwei unterschiedlichen Kunden im Einsatz ist. Die Lösung dafür wäre eine eigene "Kundensprache", die nur die Änderungen für einen speziellen Kunden definiert, also z.B. "de_DE_firmaA".

Ich bin kein Anwalt - aber: Ich denke kündigen kannst du immer. Nur die Frist wirst du wahrscheinlich so ansetzen müssen, dass sie erst vom Zeitpunkt deiner Wiederanstellung losläuft. Ansonsten würde ich einfach mal mit dem Chef drüber sprechen und ihm das genauso darlegen - er wird es sicherlich auch zu begrüßen wissen, wenn er zeitlich genüg bescheid weiß und daher früh genug mit dem (Um)planen beginnen kann.

Es war wie immer auf der A40 - man stand im Stau. Diesmal zwar zu Fuß aber man stand im Stau (zumindest in Essen *g*). Ist ja wohl jetzt auch so angedacht, dass sich das ganze im zweijährlichen Rhytmus wiederholen soll.

Nein. Sonst wären hier schon Antworten gepostet worden. Threadpushing bringt dich einer brauchbaren Antwort keinen Millimeter näher also lass das bitte.

*lol* Das ist ja wie im Bericht eines rheinische Kabarettisten: Sie: Wir haben einen neuen Wagen! Er: Was denn für einen? Sie: Na so einen roten!

Naja das Problem ist nicht auf das Abschlussprojekt einer IT-Ausbildung beschränkt. Im Hochschulbereich wird auch immer gerne die Diplom- bzw. Bachelorarbeit als Referenz angegeben, bzw. man achtet darauf, was für ein Thema und welche Note dort bearbeitet/erreicht wurde. Und genauso wie bei FI ist es hier auch - in der Praxis hat man mit dem, was man in der Abschlussarbeit gemacht hat auch selten etwas zu tun. Gemacht wird es trotzdem immer wieder. Das soll das ganze nicht als weniger fragwürdig dastehen lassen, allerdings hat sich das ganze über viele Jahre eingebürgert und es dürfte sehr schwierig werden dagegen anzukommen. Was wäre die Alternative? Klare Zustimmung. Ich befürchte nur, das wird einen "interessanten" Effekt haben. Zu meiner Berufsschulzeit sollten wir bei einer Aufgabe im Wirtschaftsunterricht die erste Ableitung einer Funktion bilden. Was glaubst du, was das plötzlich einen Aufstand gab? Unter Informatikern! Wie man es wagen könnte solche höchst mathematischen Kenntnisse zu fordern, wo wir doch eine IT-Ausbildung machten und kein Studium der Mathematik. Keine erfundene Geschichte, erlebte Praxis. Meine Prognose: Ein nicht geringer Teil aller IT-Azubis wollen überhaupt nichts mit den anspruchsvolleren Themen (zu denen sicherlich auch ein gesunder mathematischer Unterbau gehört) zu tun haben. Entweder weil man sich so larifari durch die Ausbildung "durchwurschteln" möchte oder weil man es schlicht und ergreifend nicht kann und auch nicht die Energie aufbringen möchte es sich anzueignen. Als Ergebnis würde sich in dem von dir beschriebenen Falle wahrscheinlich die Meinung durchsetzen "Eine IT-Ausbildung ist viel zu schwierig und theoretisch". Folgen daraus: Weniger Azubis, weniger "Durchdringung" am Arbeitsmarkt, schlechteres Standing, und so weiter. Versteh mich nicht falsch, ich wäre sehr stark für deinen Vorschlag einfach mehr von den Azubis zu verlangen - auch abseits vom Tellerrand - aber als Realist befürchte ich der Schuss würde nach hinten losgehen.

Ein Kommentar, den man jedes Jahr aufs neue hört. Erstaunlich. Nobody is perfect. Vielleicht ist es auch nur falsch bei dir angekommen?! Und selbst wenn: Was schlägst du dann vor? Dass nur jemand eine Prüfung abnehmen darf, der vorher bewiesen hat in jedem (auch noch so kleinen Teilgebiet) absolut sicher zu sein? Dann stell dich schonmal darauf ein, dass sehr sehr wenige Prüfer übrig bleiben sollen. Bin ja mal gespannt, wer dann die ganze Arbeit macht. Siehe oben. Dein Posting wimmelt übrigens auch von Fehlern - ziehe ich deshalb Rückschlüsse auf deine Vorbereitung oder denke mir "mein Gott, wie peinlich ist der denn, dass er sowas hier schreibt"? Das behauptest du. Ich kenne genügend Beispiele, die zeigen, dass es sehr wohl innerhalb der Zeit möglich ist. Welche nachprüfbaren Beweise hast du denn für die Verallgemeinerung?

Die Hibernate Reference Documentation.

Probier mal die Schlüsselspalten in ein Eigenes Objekt, das mit @Embeddable annotiert ist auszulagern und nur dieses Objekt als @Id zu übergeben (siehe auch Hibernate Doku).