sebi680

Wir arbeiten hauptsächlich noch mit SVN, was wir aber meist nicht direkt beeinflussen können, da wir meistens als Projektteams beim Kunden vor Ort arbeiten und dort solche Entscheidungen schon getroffen sind. Bei internen Projekten setzen wir dagegen fast nur Git oder Mercurial ein. Ich persönlich sehe aber weiterhin nicht DEN großen Vorteil von verteilten Versionsverwaltungstools. @Goose: Zum Thema "lokale Branches zum Testen" gibt es bei Git das Konzept der 'Stashes', evtl. könnte das was für dich sein. Das Eclipse Git Plugin 'EGit' zickt bei mir an dieser Stelle aber ziemlich rum, sodass ich sicherheitshalber immer die Kommandozeile benutze, auch wenn ich davon nicht der größte Fan bin.

Das sieht doch schon einmal sehr ordentlich aus Zu Übungszwecken solltest du aber wie gesagt auch noch die Lösung mit dem "Comparable" Interface schreiben. Eine Lösung für dein Problem wäre eine einfache Fabrikmethode. Du könntest ein String Array mit den Namen übergeben und dir eine Collection von Mitarbeiter Objekten zurückliefern lassen. Aber der Gedankengang, sich unnötig wiederholende und/oder sehr aufwändige Objekterzeugung auszulagern kommt den meisten Leuten (mich eingeschlossen), erst sehr viel später. Design Patterns, zu denen oben genannte Fabrikmethode auch gehört, sind übrigens ein gutes "Fortgeschrittenen"-Thema, wenn man an der Schwelle von "Ich kann Programmcode tippen" zu "Ich will schönen, robusten, wiederverwendbaren und leicht erweiterbaren Programmcode tippen können" steht. Auch zu diesem Thema gibt es ein Buch aus der "... von Kopf bis Fuß" Reihe. Sollte dir also der Stil gefallen (sehr lustig und unterhaltsam, für manche Leute aber auch unseriös), wäre das evtl. ein Buch, das du in einem halben oder einem Jahr mal anschauen könntest.

Für Anfänger ist das meiner Meinung nach kein gutes Buch Es ist eher ein Nachschlagewerk, aber zum Lernen geht es zum Einen teilweise deutlich zu tief in für Neulinge total unnötige Detailtiefen und ist zum Anderen auch sehr trocken geschrieben. Kann Anfängern nur immer wieder "Java von Kopf bis Fuß" empfehlen. Ich selbst habe Java vor knapp 2,5 Jahren mit der Inseln gelernt (eher lernen müssen ) und habe dann recht spät eben dieses Java von Kopf bis Fuß gelesen...du kannst dir nicht vorstellen, wie ich mich geärgert habe, dass mir am Anfang niemand dieses Buch empfohlen hat Auf die Gefahr hin, dass es dich eher verwirrt, als zu helfen, versuche ich hier mal schnell stichpunktartig alles Notwendige zusammenzufassen. - In Java kann man nur von einer Klasse erben (Class Abc extends Def), aber beliebig viele Interfaces implementieren (Class Abc implements Interface1, Interface2, Interface3, ....) - Interfaces sind VOLLSTÄNDIG abstrakte Klassen, die nur Methodendeklarationen, aber keinen Rumpf/Inhalt enthalten - Das Interface "Comparable" enthält die Methode "compareTo", die aber keinerlei Logik enthält - Durch die Implementierung eines Interfaces, ist die Klasse gezwungen (das ist ein sehr entscheidender Punkt), alle Methoden des Interfaces zu implementieren/selbst auszuprogrammieren - Wenn eine Klasse ein Interface implementiert, dann haben Objekte dieser Klasse gleichzeitig auch den Typ dieses Interfaces. Hat man z.B. "Class Auto implements FahrbaresVehikel", dann ist jedes Objekt der Auto Klasse vom Typ Auto, aber AUCH vom Typ "FahrbaresVehikel" - Dies führt dazu, dass man als Parameter (oder Rückgabewert) Interfacetypen angeben kann - Die besagte "sort" Methode aus Collections erwartet als Parameter eine Collection (egal ob Liste, Set, ...) von Objekten vom Typ "Comparable" (das wie erwähnt ein Interface ist) - Hier sind also ALLE Objekte zulässig, die das Interface Comparable implementieren, ob das eine JDK Klasse wie String oder Integer ist, oder eine von dir programmierte Klasse wie Mitarbeiter oder Hund oder Apfel ist vollkommen egal - Diese "sort" Methode weiß, dass alle diese Klassen die Methode "compareTo" Methode enthalten (da sie aufgrund der Implementierung von Comparable dazu gezwungen sind, diese zu implementieren) und kann dann die Elemente entsprechend dieser Methode sortieren Ich hoffe, dass du jetzt nicht mehr verwirrt bist als vorher^^

Das in Klammern der "sort" Methode (aus der Klasse Collections) sind die Parameter. Diese Methode ist "überladen", d.h. es gibt mehrere "Versionen" dieser Methode mit einer unterschiedlichen Anzahl an Parametern (man spricht auch von Methodenüberladung, wenn zwar die Anzahl der Parameter gleich ist, sich aber deren Typ unterscheidet). So kannst du also entscheiden, ob dieser "sort" Methode nur deine Liste übergibst (und die sort Methode sortiert die Elemente dann nach ihrer natürlichen Ordnung) oder du gibst der Methode eine Liste mit und zusätzlich ein "Comparator" Objekt und sagst damit quasi der "sort" Methode "sortiere mir alle Elemente dieser Liste nach den Regeln, die ich im Comparator definiert habe!". Wie ExAzubi es auch sagte, bietet es sich bei dir durchaus an, eine Mitarbeiter Klasse zu erstellen und in dieser "Comparable" zu implementieren (bist du mit Interfaces und dem Substitutionsprinzip oder Polymorphismus vertraut?). Allerdings arbeitet man ja oft genug mit fremden Klassen, die man nicht mehr verändern kann, sodass du in diesen Klassen, dann nicht Comparable implementieren kannst. In solchen Fällen, oder wie in deinem Fall, wenn man eigentlich ohne eigenständige Klasse leben kann, bietet es sich an, das Ganze mit einem "Comparator" Objekt zu lösen. Ebenso benötigt man generell einen Comparator, wenn man die gleichen Objekte mehrmals auf verschiedene Arten sortieren möchte...vielleicht möchtest du eine Liste von Äpfeln, die nach ihrer Sorte sortiert sind, zusätzlich aber eine weitere Liste, bei denen sie nach Größe/Gewicht/Preis/etc. sortiert sind. Ich denke es wäre gut, wenn du es auf beide Arten mal ausprogrammierst.

Hey Na die Grundsätze hast du ja auf jeden Fall schon einmal verstanden, gut Es gibt in Java hauptsächlich zwei Möglichkeiten, Elemente in einer Collection zu sortieren, zum Einen über "die natürliche Ordnung" (Methode "compareTo" aus dem Comparable Interface) und zum anderen über einen externen "Comparator", wie du ja anscheinend auch schon weißt. Generelle Unterscheidung: - Bei "compareTo" (Interface Comparable) vergleicht sich immer ein Objekt selbst mit einem anderen - Bei "compare" (Interface Comparator) vergleicht ein drittes, außenstehendes Objekt zwei andere Objekte Die Klasse "Collections" bietet nun zum Sortieren zum einen die Methode "sort(Collection coll)" an, die dann alle Elemente über ihre natürliche Ordnung sortiert und zum Anderen die Methode "sort(Collection coll, Comparator comp)". Dieser Methode kannst du also einen Comparator mitgeben, um die Strings nach deinen Vorgaben zu sortieren und nicht nach deren natürlicher (in diesem Fall alphabetischer Ordnung). Da du erst Java lernst, weiß ich nicht, inwiefern du schon mit anonymen inneren Klassen und Generics vertraut bist. Das sind zwei Konzepte, die du für die "Musterlösung" wohl benötigst. Ich möchte dir jetzt nicht einfach die Lösung hinschreiben, da dann der Lerneffekt nicht so groß ist. Vielleicht kannst du ja mit meinen Hinweisen schon ein bisschen weiterkommen, ansonsten kannst du ja gerne noch mehr Fragen stellen.

Wieder einmal ein Paradefall von "Bildung ist Ländersache" Bei mir waren es 15 Seiten Doku + "unbegrenzt" Anhang.

Finde 65% für diese Doku auch vollkommen ungerechtfertigt. - Inhaltlich ist alles drin, was von der IHK gefordert ist - Der Aufbau und dein Vorgehen sind logisch und transparent - Grafiken, Textformatierung und Schreibweise sind gut Das ist für mich mindestens 2er Bereich, sehr komisch. Hatte der Prüfungsausschuss vielleicht die (berechtigte) Annahme, dass du etwas kopiert hast? Gabs in deiner Firma vor dir einen Azubi, der ein sehr ähnliches Abschlussprojekt hat? Oder hast du vielleicht von jemand anderem etwas abgekupfert?

Bei mir steht auf dem genehmigten Projektantrag "Bitte das Programm zur Live Demo bei der Präsentation mitbringen". Soll ich jetzt im Anschluss an die 15-minütige Präsentation dann nochmal live mein Programm zeigen, oder soll diese Vorstellung schon ein Teil dieser Präsentation sein? Hab leider hier im Forum keinen ähnlichen Fall finden können. Ansonsten muss ich halt nochmal bei IHK anrufen.

Nein, also die Containerhierarchie dient in erster Linie nur zur Anordnung der einzelnen Komponenten und ist in nötig, da sich eben komplexe Layouts selten mit einem einzigen LayoutManager und damit mit einem einzigen JPanel, umsetzen lassen. Dennoch kann man entweder auf alle Kindkomponenten/Container eines Elements zugreifen, oder aber auch den Parent Container, also das umhüllende JPanel, eines Elements erfragen. Direkte Vererbung von Eigenschaften findet aber nicht statt. Bei größeren Projekten und Oberflächen solltest du aber Vererbung nutzen, um deinen Code übersichtlicher zu gestalten, indem du ihn auf mehrere kleinere Klassen aufteilst. Z.B. wenn du eine Art Übersicht hast, kannst du eine Klasse "UebersichtPanel" erstellen, die von JPanel erbt und den kompletten Code für dieses einzelne Panel eben in die dedizierte Klasse auslagern. Du kannst/solltest für jeden größeren Container (normale Panels oder aber auch das Menü oder die Toolbar) am besten eine eigene Klasse erstellen. In deiner "Hauptklasse" für die Oberfläche setzt du dann lediglich alles zusammen. Aber das alles musst du jetzt nicht direkt am Anfang so umsetzen, ich erwähne es lediglich, dass es nicht zu Missverständnissen kommt, weil ich es oben verneint habe, dass die Panels untereinander Eigenschaften vererben. In deinem Fall kannst du ja direkt die GUI planen, da keine komplexe Geschäftslogik dahintersteckt. Und ja, du kannst z.B. einem Button sagen, dass er, wenn er geklickt wird etwas auf der Konsole ausgeben lassen soll oder aber auch den Wert eines Textfeldes ändern soll. Du kannst aber z.B. auch für jeden Buchstaben, der in ein Textfeld getippt wird, eine Aktion auslösen. Arbeite wirklich am besten das Tutorial durch, das ich dir verlinkt habe. Auch wenn da bestimmt eine Menge drin steht, was du für dein Programm nicht brauchst, ist so ein genereller erster Überblick viel wert. edit: Auch wenns nicht sehr originell ist, aber ich habe unsren Azubis hier im ersten Lehrjahr vor kurzem auch die Aufgabe gegeben, einen Taschenrechner mit den vier Grundrechenarten unter Verwendung eines GridBagLayouts zu programmieren. Ich finde diese Übung ganz gut, da sie mehrere Aspekte der Oberflächenprogrammierung abdeckt: - Man muss die Oberfläche konzipieren und umsetzen - Wenn man einen Button klickt, muss die entsprechende Zahl in das Textfeld geschrieben werden - Wenn man auf einen Button mit einem Rechensymbol klickt, muss der derzeitige Inhalt des Textfeldes in einer Variable gespeichert und das Feld geleert werden - Anschließend gibt man die zweite Zahl ein - Bei Klick auf "=" wird der Inhalt des Textfeldes in einer 2. Variable gespeichert und je nach geklicktem Rechenzeichen werden dann die beiden Variablen verrechnet und das Ergebnis wieder in das Textfeld geschrieben

Da gehts in meinen Augen einfach um das Hauptproblem für Einsteiger: Es geht teilweise zu schnell in für einen Anfänger uninteressante Detailtiefen. Die Insel ist eher ein Nachschlagewerk, als ein Lehrbuch für Einsteiger. Arbeite am besten einfach mal das offizielle Tutorial von Oracle zu dem Thema durch: Trail: Creating a GUI With JFC/Swing (The Javaâ„¢ Tutorials) Bei gezielten Fragen kann dir Google oder der Thread hier bestimmt helfen Da ich in den letzten 1,5 Jahren aber kaum noch was in Swing gemacht habe und seit einem 3/4 Jahr recht exzessiv JavaFX programmiere, sind meine Swing Kenntnisse allerdings mittlerweile auch etwas eingerostet

Am Anfang ist es wirklich nicht einfach, gut strukturierten und "schönen" Code zu schreiben und auch nach mehreren Jahren Programmieren schaut man sich noch oft genug wenige Wochen alten Code an und denkt sich, dass man das anders doch hätte schöner lösen können Ohne viel praktische Erfahrung ist eine "verbindliche" Vorplanung ohnehin noch wesentlich schwerer, da du ja bereits im Vorfeld die Lösung zu Problemen wissen musst, von denen du bei deinem derzeitigen Wissensstand noch nicht einmal weißt, dass es sie überhaupt geben wird Generell ist es eine sehr gute Idee, deine Oberfläche, alle Dialoge und Masken vorher auf Papier zu skizzieren. Gerade bei großen und komplexen Masken kommst du bei Swing nicht um das berüchtigte "GridBagLayout" herum und insbesondere bei diesem erspart einem ausreichende Vorplanung Zeit und Frust bei der Programmierung. Es gibt ja zum Glück genügend Tutorials für alles, was mit Java zu tun hat im Internet, sodass grundsätzliche Einsteigertutorials über Oberflächenprogrammierung mit Java leicht zu finden sind. (und falls du mit "dickes java-buch inkl. kapitel über swing" die Java Insel meinst, würde ich dir zunächst davon abraten). Wichtig zu verstehen ist erstmal das generelle Konzept: - Du hast ein Fenster in der Form eines JFrames oder JDialogs - Als "benutzbare Fläche" hast du in diesem Fenster ein JPanel - In dieses JPanel kannst du dann direkt Oberflächenkomponenten wie Buttons oder Textfelder platzieren oder aber weitere JPanels, die ihrerseits z.B. Buttons oder wieder andere Panel haben. - Jedem einzelnen Panel kannst du dann einen LayoutManager wie "BorderLayout" oder "GridLayout" zuweisen. Dieses Layout bestimmt, wie dieses Panel alle Komponenten (also sowohl Buttons, als auch andere Container/Panel) in sich anordnet. => Große Anwendungen haben oft eine große Hierarchie von ineinander verschachtelten JPanels, die unterschiedliche LayoutManager haben und ihre Komponenten dementsprechend anordnen. Wenn du dieses Konzept verstanden hast, hast du den Einstieg eigentlich schon geschafft. Deine konkrete Idee lässt sich nun auf mehrere Arten umsetzen: - Du könntest eine zeilenweise aufgebaute Übersicht (GridLayout oder GridBagLayout) aufbauen, zu Beginn jeder Zeile mit einem JLabel die Partie anzeigen und rechts daneben in einem JTextfield den Tipp aufnehmen. - Du könntest allerdings auch eine JTable verwenden, wobei die, sobald es über die Standardnutzung hinausgeht, für Anfänger ziemlich kompliziert wird Ich hoffe, ich konnte dir den Einstieg ein wenig vereinfachen. Steck auf jeden Fall nicht den Kopf in den Sand, auch wenn man am Anfang bei Swing sich schon oft denkt "ich will doch nur, dass das so und so aussieht". Evtl. wäre Mantisse, der GUI Builder von NetBeans auch eine gute Idee, aber erst, wenn du die Grundlagen komplett verstanden hast.

Wow ok, das hätte ich nicht gedacht. Naja dann dürfen sie sich aber auch nicht beschweren, wenn es jeder auf 70 Stunden faked.

Naja ab wann ist es denn eine "Zeitüberschreitung"? Dass jeder genau 70 Stunden braucht, ist ja wohl Utopie. Ich habe in Wahrheit 73 oder 74 Stunden benötigt, kann ich das so reinschreiben, oder gibt das evtl. schon Abzug?

Na klar, nichts bereitet mir größere Freude Es ist eben so, dass der Schreibstil bei einigen Leuten doch viel auf den Charakter schließen lässt und ich mag einfach keine Leute, die ihre Meinung immer als die einzig richtige akzeptieren und bei jedem Thema meinen, die Weisheit mit Löffeln gefressen zu haben. Und ich kenne genug Personaler und keiner von denen mag wischiwaschi Aussagen. Viele Personaler schließen von Bewerbungsformulieren auf das Auftreten und das Selbstbewusstsein des Bewerbers und gerade bei Stellen, bei denen man viel Kundenkontakt hat, erwarten die Personaler im Anschreiben überzeugende Formulieren, die Klartext sprechen und suggerieren, dass sich der potenzielle Mitarbeiter auch vor Kunden gut und kompetent verkaufen kann. Wenn du dich vor den Kunden stellst und sagst "Vielleicht könnten wir das so machen", dann wirkt das einfach unsicher und lässt den Kunden an deiner Qualifikation zweifeln. Ich selbst habe zu wenige Erfahrungen, das sind wie gesagt Aussagen und Meinungen von befreundeten Personalern.

Und ich dachte, dass du nur in den Programmierforen so von oben herab und in einem äußerst abwertenden "Ich weiß als einziger die richtige Lösung" - Stil schreibst, aber weit gefehlt Dass du das dann noch mit einem Rat beendest, den finalen Satz mit "Vielleicht" zu beginnen, setzt dem Ganzen noch die Krone auf. In einer Bewerbung kommen unselbstbewusste larifari Formulieren mit "vielleicht", "eventuell" oder "womöglich" nie gut an. @Abaddon: In der letzten Fassung finde ich deine Bewerbung sehr gelungen, drück dir die Daumen =)

Hab dir per PN mal die Beschreibung meines Projekts geschickt.

Hallo zusammen, bin gerade am Schreiben meiner Doku und bin jetzt bei der Hälfte der "Realisierung" bei 13 Seiten angelangt, Projektabschluss/Abnahme/Fazit/Ausblick/blabla habe ich noch vor mir. Kurzum, es wird wohl mindestens 5 Seiten zu lang werden. Das Problem an der Sache ist, dass mein Projekt doch in einem recht speziellen Umfeld stattfindet und ich somit die Einleitung und das Projektumfeld ziemlich ausführlich gestalten MUSS, da ansonsten weder die Notwendigkeit für mein Projekt, noch seine Relevanz deutlich werden. Wenn ich hier kürzen würde, würde die Wahrscheinlichkeit, dass man mein Projekt nicht verstehen oder zumindest nicht richtig einordnen kann, sehr groß sein. Ich hab den Bewertungsbogen der Prüfer hier, beim ersten Bewertungspunkt geht es um "Projektziele und Teilaufgaben, Umfeld und Schnittstellen". So, jetzt meine Frage, müssen diese Inhalte zwingend in der eigentlichen Doku sein, oder können sie auch in der Anlage sein? Oder werden die Anlagen einfach als eine Art Zusatzinfo betrachtet und alle bewertungsrelevanten Punkte MÜSSEN direkt in der Doku sein? Ich würde bei mir nämlich gerne die Punkte "Technisches Umfeld" und "Technologieentscheidungen" komplett in die Anlagen ausgliedern, da diese insgesamt 3-5 Seiten umfassen, die ich aber wirklich nicht kürzen kann. Und noch eine Frage...wie streng wird denn bei zu großem Umfang abgewertet? Und auch ab welchem Ausmaß von zu großem Umfang? Wenn ab 2, 3 Seiten zu viel bis zu 5% abgewertet wird, muss ich halt zwingend irgendwas ändern, wenns aber ab 5-10 Seiten zu viel eher 2, 3 %-Punkte sind, dann würde ich es wohl einfach in Kauf nehmen.

Wow das Klassendiagramm sieht ja sehr schick aus, mit welchem Programm hast du das denn erstellt?

Na das weiß man aber auch so, so oft wie das schon drankam Fehlte ja nur "Erläutern Sie den Unterschied zwischen Datenschutz und Datensicherheit"^^

Nachdem ich die Prüfung seit letztem Mittwoch hinter mir habe, muss ich denen zustimmen, die meinen, dass man das Handbuch im Endeffekt garnicht so oft benutzt. Ich bin FIAE und habe das Handbuch nur bei einer Frage benötigt und zwar im GH2 Teil bei der Frage nach den Vorteilen von SAN ggü. NAS. Auch wenn es natürlich erstmal als großer Nachteil erscheint, wenn das Handbuch jetzt abgeschafft wird, wird dem Handbuch im Vorfeld doch immer zu viel Bedeutung zugemessen. Vorallem da man in den letzten Jahren bei den Theoriefragen in den Prüfungen den Eindruck haben mussten, dass gezielt Fragen gestellt werden, zu denen keine Antwort im Tabellenbuch steht.

Eine Berufsschullehrerin von uns war im 6-köpfigen Prüfungsausschuss und hat uns mitgeteilt, dass niemand durchgefallen ist. IHK möchte ich jetzt nicht nennen, da die Ergebnisse ja eigentlich nicht vorzeitig publiziert werden dürfen.

Bei uns ist von über 30 Leuten niemand durchgefallen laut unserer Lehrerin =) Wenn man bedenkt, dass mindestens die Hälfte der Leute direkt nach der Prüfung ums Bestehen gezittert hat, scheint es schon zu sein, dass sich die Leute immer zu sehr verrückt machen.

Und zwei mal die 5?^^ Ich hab da 1,8,9 - 2,6,7 - 3,4,5 Und zumindest beim tertiären Sektor bin ich mir ziemlich sicher, dass das so stimmt.

Sind bis auf eine Ausnahme genau meine Lösungen. Habe lediglich bei Aufgabe 7 Antwort 4 geraten, aber es haben hier ja schon einige 3 als richtige Antwort ausgegeben. Sind denn einige dieser Antworten mittlerweile als falsch "entlarvt" worden? Habe nicht alle Seiten durchgelesen.

Hoffen wirs mal =) Gibts denn hier vielleicht einige Leute, die nach ihrer IHK Prüfung Einsicht in ihre Prüfung hatten und sagen können wie kulant die IHK Vorgaben und auch die Prüfer in der Regel sind? Gerade auch bei UML Diagrammen oder SQL Statements...je nach Auslegung kann man da für eine fast richtige Lösung fast alle Punkte geben oder argumentieren, dass der Kerninhalt fehlt oder dass es einfach falsch ist.