Ausbildungs FIAE Themen

[Chiyoko]

Hallo liebes Forum,

nachdem ich seit ein paar Monaten hier aktiv mitwirke, erstelle ich nun mal ein Thread in eigener Sache.

Heute mal die andere Seite der Ausbildung :P.

Ich bin fachlicher Ausbilder in meinem Unternehmen (An unserem Firmensitz sind > 2000 Mitarbeiter) . Unsere Ausbildung läuft wie folgt ab:

Im ersten Lehrjahr gibt es überwiegend Schulungen + Übungswochen.

Ab dem zweiten Lehrjahr werden die Azubis in Abteilungen gesetzt und arbeiten dort, mit Unterstützung durch einen dedizierten Betreuer, teilweise oder komplett produktiv an Themen der Abteilungen mit.

Nun zu meiner Frage: Mir geht es speziell um das erste Lehrjahr (FIAE) und die Inhalte.

Hinzu kommen 2 Wochen bei einem externen Dienstleister, der unseren Azubis noch Windows Server, Domäne, Exchange-Server und TMG beibringt.

Die + Zeiten sind Übungstage.

Fehlt euch etwas in der Liste? Kommt etwas zu kurz? Können wir etwas raus nehmen?

Die FIAEler lernen bei uns, wie unschwer erkennbar in Richtung Java.

Danke für eure Rückmeldungen.

 

Bearbeitet 15. März 2017 von Chiyoko

[allesweg]

Ich kann mir unter "Windows Client" und "Windows Server" nicht wirklich etwas vorstellen.

Was genau die FIAE-relevanten Inhalte von "Domäne" und "Exchange" sein können, ist mir auch unklar.

Je nach Reihenfolge könnte man einzelne Themen verschmelzen. (Java, snv, maven, ...)

[Chiyoko]

vor 13 Minuten schrieb allesweg:

Was genau die FIAE-relevanten Inhalte von "Domäne" und "Exchange" sein können, ist mir auch unklar.

FIAE relevant? Kaum etwas. IHK-Prüfungs relevant? Sehr wohl. Ich denke es schadet nicht, auch als Anwendungsentwickler zu wissen, was eine Domäne ist, wie diese funktioniert und was diese ominösen DCs sind  

Die Windows Client und Windows Server Schulungen sind sehr nah an den MOCs gehalten.

Bearbeitet 15. März 2017 von Chiyoko

[Tician]

Die andere Seite der Ausbildung zu hören ist immer spannend

Ich (Azubi FISI) programmiere zwar nur in C# und das auch nur Laienhaft, aber da habe ich auch schon Domänenabfragen gemacht. Also für die Domäne lässt sich einiges programmieren, aber dazu sollte man auch wissen was es ist und was man da tut und was ein DC ist.

Und wie Chi sagte gehört das zum Wissen eines Informatikers (meine Meinung).

UML klingt schonmal gut aber was ist mit Struktogrammen? Die gehören meine ich auch dazu, allerdings kann es natürlich sein das die nur in der Schule vermittelt werden. Ansonsten sehe ich jetzt nichts was fehlen würde.

So ein Plan ist wirklich super, aber ich als Azubi würde mir ~5 Gleitzeit-Tage wünschen ohne festes Thema wo nochmal auf mich eingegangen wird. Ein Azubi versteht vielleicht nach 1 Tag das Websecurity nicht oder ein anderer hatte mal nen schlechten Tag und hat in den Grundlagen nicht aufgepasst oder war krank. Zeit um sich nochmal mit dem auseinander zu setzen und vielleicht nochmal selbst einzulesen (in anderen Worten zu hören) was man nicht verstanden hat.

Bearbeitet 15. März 2017 von Tician

[Chiyoko]

vor 8 Minuten schrieb Tician:

aber was ist mit Struktogrammen?

Sind Teil der Programmiergrundlagen Schulung

vor 8 Minuten schrieb Tician:

aber ich als Azubi würde mir ~5 Gleitzeit-Tage wünschen ohne festes Thema wo nochmal auf mich eingegangen wird.

Keine Sorge, die Liste ist nicht als "Schlag auf Schlag" zu verstehen. Pufferzeiten sind immer drin. Es wird sich auch die Zeit genommen, ggf. zu zweit mit dem Azubi den Stoff nochmal aufzuarbeiten. Zwischen Java grundlagen und Advanced liegen im Normalfall z.B. 2 oder mehr Wochen.

Die Liste oben ist nur eine Sammlung. "was wird geschult". Es gibt natürlich noch einen richtigen Schulungsplan mit Terminen etc. Den möchte ich nur nicht veröffentlichen, da dort auch personen- und Unternehmensbezogene Daten enthalten sind.

Bearbeitet 15. März 2017 von Chiyoko

[jk86]

Find ich gut!

Ist die Ausbildung denn Schritt für Schritt, also erst Java Grundlagen, dann Java Advanced etc.?

Ich persönlich fand es hilfreich, erst die OOP-Basics zu verstehen und dann Klassen- und Objektdiagramme zu schreiben, aus denen man dann den Java-Code ableitet. Das ist relativ fail-safe. So haben wir es in der Berufsschule gemacht, allerdings erst nach ein paar Wochen HTML, CSS, PHP und Wasserfallmodell. Da macht es imho Sinn, sich den Ausbildungsplan der BS anzuschauen und darauf zeitlich und inhaltlich abzustimmen. Mein Unternehmen hat mich jetzt in einen CCNA-Kurs gesetzt - super spannend, nehm ich gerne mit - aber zeitlich gesehen finde ich es etwas ineffektiv, da ich den ganzen Netzwerkteil in der Berufsschule später nochmal machen werde. Vorlernen schadet nicht, aber in der Ausbildung hat man soviel Stoff zu lernen, dass ein Thema nochmals von der Pike auf zu lernen imho vermieden werden sollte.

[Chiyoko]

vor 22 Minuten schrieb jk86:

Ist die Ausbildung denn Schritt für Schritt, also erst Java Grundlagen, dann Java Advanced etc.?

Hi,

natürlich  Es beginnt mit Programmiergrundlagen, geht dann zu UML und OO über und anschließend Java Grundlagen, danach Advanced.

Folgend sind dann die JEE-Themen und Webservices etc.

Die Berufsschule bei uns lehrt C im ersten Jahr. Mir persönlich fällt es schwer, mich nach der BS zu richten. Es sit schon teilweise stark abhängig vom Lehrer in welchem Umfang, und vor allem wie verständlich etwas erklärt wird.

Lieber habe ich Themen doppelt besprochen, als nur einmal und dann aber nicht richtig verstanden  

[MartinSt]

Bei uns hat sich weiterhin (für Azubis und Studenten) bewährt, dass diese an möglichst vielen Projektbesprechungen teilnehmen.
Auch wenn sie dabei vieles fachlich nicht komplett verstehen können, sollen sie lernen, wie Entwickler denken.

Das "Bauchgefühl" des erfahrenen Entwicklers lernt man leider aus keinem Buch und an keiner Schule.

 

Gruß Martin

[Whiz-zarD]

vor 19 Stunden schrieb Chiyoko:

natürlich  Es beginnt mit Programmiergrundlagen, geht dann zu UML und OO über und anschließend Java Grundlagen, danach Advanced.

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.

[Chiyoko]

Hallo Whiz-zard,

UML finde ich persönlich schon wichtig. einmal wegen der IHK-Prüfung und andererseits auch, weil so etwas Augenmerk auf Konzeption und Planung gelegt wird. Es ist sozusagen ein Hilfsmittel, Azubis dazu zu bringen, nicht einfach "drauf los" zu programmieren.

Call by Value und Call by Reference sind teile der Java-Schulungen.

Für die Datenstrukturen haben wir eine gesonderte Schulung

 

Bis hierhin schon einmal danke für die Rückmeldungen. Bisher sehe ich noch keine großen Lücken bei uns. Das freut mich  

[arlegermi]

Auf Alternativen / Ergänzungen zu OO geht ihr nicht ein? Gerade die JVM (für euch als Java-Shop) hat doch schöne Beispiele für Sprachen, die nicht (nur) OO sind (Scala, Clojure, Groovy, ...).

[stefan.macke]

vor einer Stunde schrieb Whiz-zarD:

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.

Da muss ich widersprechen. Für die IHK-Prüfung sind mind. 5 UML-Diagrammtypen (Use-Cases, Aktivität, Zustand, Klassen, Sequenz) absolut relevant, da sie in den letzten Jahren fast immer abgefragt wurden.

Und auch in der Praxis sehe ich nicht, dass die UML "versagt" hat. Wenn sie nicht zur Modellierung verwendet wird (worüber man in Zeiten von TDD streiten kann), so ist sie doch der allgemein akzeptierte Standard, wenn es um die Dokumentation geht. Wir verwenden z.B. regelmäßig Klassen-, Verteilungs- und Komponentendiagramme, um die Architektur von Anwendungen zu dokumentieren. Und eine gewisse Modellierungsphase vor der Entwicklung empfinde ich auch als äußerst hilfreich. Gerade um Azubis vor der Programmierung die geplanten Schichten (oder wie auch immer die Architektur aussieht) näherzubringen.

[Whiz-zarD]

vor einer Stunde schrieb stefan.macke:

Da muss ich widersprechen. Für die IHK-Prüfung sind mind. 5 UML-Diagrammtypen (Use-Cases, Aktivität, Zustand, Klassen, Sequenz) absolut relevant, da sie in den letzten Jahren fast immer abgefragt wurden.

Und der Rest?

vor einer Stunde schrieb stefan.macke:

Wir verwenden z.B. regelmäßig Klassen-, Verteilungs- und Komponentendiagramme, um die Architektur von Anwendungen zu dokumentieren. Und eine gewisse Modellierungsphase vor der Entwicklung empfinde ich auch als äußerst hilfreich. Gerade um Azubis vor der Programmierung die geplanten Schichten (oder wie auch immer die Architektur aussieht) näherzubringen.

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.
 

[Rienne]

vor 17 Stunden schrieb Whiz-zarD:

Du schränkst aber aber auch schon den Verwendungszweck von UML ein und zwar nur für die Dokumentation.

Das stimmt nicht doch gar nicht. @stefan.macke schreibt eindeutig, dass es auch für die Modellierung vor der Entwicklung genutzt wird. Lediglich, wenn selbst das wegfallen würde, hätte UML auch noch zur Dokumentation seine Daseinsberechtigung.

vor 17 Stunden schrieb Whiz-zarD:

Wenn ich mir hier einige Diagramme anschaue, die man in der Vergangenheit gezeichnet hat, denke ich mir "Wtf?".

Was aber vermutlich auch daran liegt, dass derjenige, der diese angefertigt hat, vermutlich letzten Endes selber UML gar nicht vernünftig verstanden hat.

vor 17 Stunden schrieb Whiz-zarD:

Komplexe Abläufe sind in den Diagrammen nur sehr schwer zu verstehen.

Das soll für mein Verständnis ein UML-Diagramm auch erst einmal gar nicht. UML dient imo vor allem der Visualisierung von Abläufen und Zusammenhängen und auch nicht alles muss dann später zu 100% mit dem erzeugten Code übereinstimmen.

Ein Use-Case-Diagramm zeigt beispielsweise auf einfachste Weise auf, was eine Anwendung von außen betrachtet tun soll und ist auch ohne viel Wissen von UML für Laien (i.d.R. der Kunde) zu verstehen und kann damit als Konzeptions- und Diskussionsgrundlage dienen.

vor 17 Stunden schrieb Whiz-zarD:

Das nächste ist, dass sich daraus kein Code generieren lässt.

Das habe ich anders in Erinnerung. Es gibt sogar Firmen, die damit ihr Geld verdienen Software zu entwickeln, die genau das bewerkstelligt. Und aus Klassendiagrammen habe ich während meiner Ausbildung in der Schule definitiv auch schon Code generiert.

Wenn es hier um die Diskussion geht, was alles überflüssig wäre zu lernen während der Ausbildung, ist UML sicherlich nicht das, was an erster Stelle steht (da sind PAP und Struktogramme sicherlich weiter vorne). Es zu lernen ist jedoch durchaus berechtigt und sollte auch nicht unter den Tisch gekehrt werden.

Es geht bei der IHK-Ausbildung auch nicht darum die neuesten state of the art Techniken zu beherrschen (die zum Teil übrigens schneller wieder im Erdboden verschwinden, als dass sie aufgetaucht sind), sondern darum eine Grundlage für strukturierte und saubere Entwicklung zu bieten.

Du hast deine Meinung zu UML, andere und vor allem die IHK, die nunmal das Sagen bei der Ausbildung hat, haben eine andere.

[stefan.macke]

vor 19 Stunden schrieb Whiz-zarD:

Und der Rest?

...wurde bislang noch nicht abgefragt. Was aber auch ok ist. Wer braucht denn schon wirklich ein Timing-Diagramm?

vor 19 Stunden schrieb Whiz-zarD:

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.

Wie beschrieben setze ich die UML sehrwohl für die Modellierung ein. Allerdings nicht im Detail - also Klassen mit Attributen und allem Schnickschnack - sondern insb. für die Architekturplanung. Das detaillierte Klassendesign oder Abläufe, die man mit einem Sequenzdiagramm modellieren könnte, ergeben sich bei Anwendung von TDD erst bei der Entwicklung.

Nichtsdestotrotz gibt es viele gute Werkzeuge (z.B. den Enterprise Architect), die Roundtrip-Engineering beherrschen und Code zu Modell und Modell zu Code wandeln können. Dadurch wird die Aktualisierung der Modelle ein Kinderspiel.

vor 19 Stunden schrieb Whiz-zarD:

Man erkennt nicht, ob der Ersteller der Diagramme das Problem komplett verstanden hat.

Genau wie bei Code

vor 19 Stunden schrieb Whiz-zarD:

Komplexe Abläufe sind in den Diagrammen nur sehr schwer zu verstehen.

Das kommt auf den Grad der Abstraktion an. UML hat nicht den Anspruch, die Details perfekt abzubilden. Das kann Code tatsächlich besser. Dafür kannst du in deinen Diagrammen die Sicht und den Grad der Detaillierung frei wählen und komplexe Abläufe auf ihren Kern herunterbrechen. Von daher sehe ich die UML gerade bei komplexen Abläufen als äußerst hilfreich an.

vor 19 Stunden schrieb Whiz-zarD:

Das nächste ist, dass sich daraus kein Code generieren lässt. So kann der spätere Code vom Diagramm abweichen.

Siehe oben. Das geht sehrwohl. Allerdings sollte nicht der Anspruch sein, "fertigen" Code zu generieren, sondern z.B. Klassenrümpfe oder Pakete. Das spart dann tatsächlich sogar Zeit, wenn man mit dem Modell beginnt.

vor 19 Stunden schrieb Whiz-zarD:

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.

Da wir auch mehrere selbst entwickelte DSLs im Einsatz haben, kann ich nur zustimmen: für die Codegenerierung optimal! Aber für die Dokumentation und grobe Modellierung würde ich trotzdem ein grafisches Werkzeug wie die UML vorziehen.

[etreu]

Mir fehlen noch ein paar Blicke auf andere Betriebssysteme (Linux, Unix, Mac) und Netzwerkgrundlagen und "Internetprotokolle" (HTTP/SPDY, REST, ...).

Ansonsten wäre vielleicht für euch noch Applicationserver und JSF im Detail interessant.

[Rabber]

Ich persönlich finde es wichtig, dass man nicht nur in einem Technologie-Umfeld etwas lernt, sondern auch die anderen Bereiche zumindest mal "gemacht hat". Wenn der Fokus auf Java liegt, trotzdem z.B. C/C++, C#, PHP, Pythone oder etwas anderes zu lernen. Nicht sonderlich intensiv, aber zumindest grundlegend, damit man das große Ganze und Zusammenhänge und Konzepte besser verstehen lernt.

Ansonsten steht schon viel Gutes in Deinem Plan drin.
Ist die Frage, in wie weit man so viel in so kurzer Zeit (1 Jahr) wirklich lernen kann.

[KeeperOfCoffee]

Ich stelle hier persönlich einfach mal die Effizienz solcher Übungstage in Frage. Wissenschaftlich gesehen, vergessen wir schon nach einer Woche fast über 50% der Dinge die wir gelernt haben, sofern wir nicht Gelerntes wiederholen. Es reicht sogar schon der Weg zur Kaffeemaschine + Zubereitung aus um bis zu 25% des gerade Gelernten wieder zu vergessen. Es nützt wenig zu sagen: "ja wir haben euch das doch vor einem Jahr am 10. Übungstag beigebracht, also könnt ihrs doch jetzt auch".

Es würde mehr Sinn machen, wenn man wirklich Techniken lehrt, die die Personen später einsetzen werden. Ansonsten wäre der Größte Teil dieses Plans ineffizient und verschenkte Zeit. Dies hängt natürlich auch davon ab, ob sich die Azubis privat fortbilden. Ich glaube man setzt ziemlich viel Hoffnung darin, so viel Wissen in so kurzer Zeit zu vermitteln, wird aber letzten Endes enttäuscht sein, weil es einfach nicht möglich sein wird alle Aspekte zu vermitteln.

Am Ende könnte es die Azubis vlt sogar überfordern oder anders negativ beeinträchtigen. Manchmal ist halt weniger mehr.

Bearbeitet 21. März 2017 von KeeperOfCoffee

[Chiyoko]

Puhh, ich war im Urlaub und antworte daher sehr spät. Auf die UML-Diskussion gehe ich jetzt mal nicht ein. Sie ist und bleibt Bestandteil der Ausbildung

 

Am ‎16‎.‎03‎.‎2017 um 10:23 schrieb arlegermi:

Auf Alternativen / Ergänzungen zu OO geht ihr nicht ein? Gerade die JVM (für euch als Java-Shop) hat doch schöne Beispiele für Sprachen, die nicht (nur) OO sind (Scala, Clojure, Groovy, ...).

 

Am ‎20‎.‎03‎.‎2017 um 16:54 schrieb Errraddicator:

Wenn der Fokus auf Java liegt, trotzdem z.B. C/C++, C#, PHP, Pythone oder etwas anderes zu lernen. Nicht sonderlich intensiv, aber zumindest grundlegend, damit man das große Ganze und Zusammenhänge und Konzepte besser verstehen lernt.

In die Richtung passiert im Unternehmen wirklich momentan nichts. In der Berufsschule kommen Dinge wie: C++, C#, Java und Php dran. Reicht das als "reinschnuppern", oder bist du der Meinung, man sollte intensiver darauf eingehen? Gerade C++ ist das gesamte erste Berufsschuljahr.

Am ‎20‎.‎03‎.‎2017 um 11:30 schrieb etreu:

Mir fehlen noch ein paar Blicke auf andere Betriebssysteme (Linux, Unix, Mac) und Netzwerkgrundlagen und "Internetprotokolle" (HTTP/SPDY, REST, ...).

Ansonsten wäre vielleicht für euch noch Applicationserver und JSF im Detail interessant.

Linux schauen wir momentan nicht an. Ich hadere da mit mir selbst etwas. Als Anwender komme ich relativ wenig mit Linux in Kontakt (für die Verwaltung der Server haben wir eine Abteilung mit genügend fähigen Systemintegratoren ), als dass sich ein Ausflug in die Richtung lohnt. Im Unternehmen setzen wir sehr stark auf Windows. Netzwerkgrundlagen Schulung gibt es, schimpft sich oben Netzwerkschulung.

Application Server wird bei JEE-Backend mit besprochen und JSF in der JEE-Frontend Schulung. Wie sehr sollte das deiner Meinung nach ins Detail gehen?

vor 21 Stunden schrieb KeeperOfCoffee:

Ich stelle hier persönlich einfach mal die Effizienz solcher Übungstage in Frage. Wissenschaftlich gesehen, vergessen wir schon nach einer Woche fast über 50% der Dinge die wir gelernt haben, sofern wir nicht Gelerntes wiederholen

An dieser Stelle ein klares Jain. Prinzipiell gebe ich dir Recht, dass wir sehr viel in der kurzen Zeitspanne von einem Jahr machen. Die Übungstage nach den Schulungen dienen dazu, es etwas weiter als ins Kurzzeitgedächtnis zu bringen. Spätere Schulungen bauen teilweise auf dem Wissen auf, und festigen so nochmal das Gelernte (Java Grundlagen -> Java Advanced -> JEE Backend -> JEE Frontend). Ab dem zweiten Jahr sind die Azubis dann in den Abteilungen und arbeiten an Projekten (teilweise wie gesagt sogar produktiven Projekten). Auch hier wird nicht erwartet, dass sie alles aus dem ersten Jahr, was irgendwann in einer Schulung war, können. Hier wird auch bereitwilig Stoff nochmal wiederholt und schließlich mit der Praxis nochmals gefestigt. Ich denke das funktioniert sehr gut so.

Bearbeitet 22. März 2017 von Chiyoko