stefan.macke

Da muss ich persönlich leider komplett widersprechen ;-) Fortschrittsbalken sind absoluter Schrott. Aber wichtig ist (leider) nicht, was wir Forennutzer dazu meinen, sondern nur, was deine IHK haben will. Wenn du also explizit die Forderung nach dem Fortschrittsbalken vorliegen hast, dann halte dich daran! Alles andere wäre doch total unsinnig, weil du quasi einen Punktabzug selbst verursachst. Auch zu den Seitenzahlen und sonstigem "Schnickschack" habe ich eine recht eindeutige Meinung: Völlig unnötig! Aber auch diese Meinung ist irrelevant, wenn deine Vorgaben diese Inhalte fordern. Zuletzt: Du kannst dich natürlich "trauen" und die Präsentation komplett anders gestalten als gefordert. Ich glaube, dass es da draußen auch viele "moderne" Prüfer gibt, die diesen alten Quatsch auch nicht (mehr) toll finden. Aber bei einer so wichtigen Prüfungsleistung kann ich natürlich keine allgemeine Empfehlung dafür aussprechen, die "Regeln" zu brechen...

Na klar, warum nicht! Ist doch ein super relevantes Thema für die Abschlussprüfung! Du kannst mir gerne deine MP3-Datei schicken und ich baue das Intro ein und lade die Datei hoch.

Ich sehe schon, wir kommen nicht zusammen. Aber trotzdem muss ich ein paar Kommentare loswerden. Es geht hier nicht nur um diese kleinen Firmen. Eine wirtschaftliche Betrachtung seiner Arbeit erwarte ich von jedem Anwendungsentwickler. Das krasse Gegenteil wäre nämlich der Tod für jedes Business: "Komm, wir programmieren einfach unser eigenes ORM. Microsoft hat unseren ganz speziellen Fall leider nicht im EF abgedeckt." "Was, dafür soll ich ein simples Excel-Makro verwenden, das in 15 Minuten zusammengeklickt ist? Nein, ich entwickle eine coole GUI in C# mit Office-Integration! Dauert max. 2 Wochen!" Und nichts anderes ist die Kosten-/Amortisationsrechnung in den Projektdokus. Die Prüflinge sollen sich bewusst werden, dass ihre Arbeit und ihre Entscheidungen das Unternehmen Geld kosten. Wenn deinem Chef die Aussage "Geht schneller. Lohnt sich!" reicht, ist das ok. Mit vernünftiger Begründung hat das aber wenig zu tun. Wenn das "kleine Azubiprojekt" sich erst nach fünf Jahren amortisiert, sieht die Welt vielleicht schon ganz anders aus. Das stimmt. Dann wären es aber leider auch keine 100% geworden Da ich die Arbeit betreut habe: Ja, das war ihr klar. Und ich hoffe, dass andere Unternehmen das auch vermitteln. Ich vermittle diese Inhalte meinen Azubis zwar, könnte aber in der Praxis (!) durchaus damit leben, wenn sie es nicht wüssten. Denn die genannten Optimierungen sind für 99% des Tagesgeschäfts nicht relevant. Bei einer Liste mit 100 Elementen interessiert sich niemand für die Nanosekunde weniger Laufzeit. Und irgendetwas muss ja auch noch für das Studium übrig bleiben. Seltsam, dass du noch nicht die O(n)-Notation gefordert hast Das sehe ich genauso. Ich lasse in meiner Programmiereinführung auch immer eine verkettete Liste programmieren. Die Frage nach der Praxisrelevanz habe ich allerdings schon oben beantwortet. Das "genauso gut" stelle ich mal zur Diskussion. Meiner Meinung nach ist der Fokus auf die OOP beim DDD schon deutlich zu spüren. Aber selbstverständlich gibt es ein paar grundlegende Konzepte, die auch mit anderen Paradigmen umgesetzt werden können. Da bin ich völlig dabei. Ich fände es auch klasse, wenn moderne Inhalte in der Berufsschule gelehrt würden. Daran können wir aber leider wenig ändern. Ich hoffe, dass sich viele Azubis, die diesen Thread lesen, ein Beispiel daran nehmen und auf eigene Faust neue Sachen ausprobieren. Ich glaube nicht, dass hier jemand sagt, dass diese Inhalte nicht gelehrt werden sollen. In der Praxis ist das nur leider sehr selten der Fall. Und zwar in der Schule wie in den Betrieben. Ich selbst lehre beides - sowohl im Unternehmen, als auch in meinen Vorlesungen. Eine andere Sache ist, diese Inhalte als allgemeingültig vorauszusetzen und in einer bundesweit einheitlichen Abschlussprüfung (ja, sorry Baden-Württemberg) abzufragen. Da bist du meiner Meinung nach wohl etwas in deiner Welt gefangen. Schau dich mal in anderen Branchen (Versicherung, Bank, Automobil, öffentlicher Sektor usw.) um. Da wirst du ohne Pflichtenheft nicht weit kommen. Und Scrum ist auch bei Weitem noch nicht so etabliert wie man meinen könnte. Ich selbst habe jedes Jahr wieder Studierende aus großen und kleinen Unternehmen, die weder Scrum, XP, Unit-Tests oder DDD je gehört haben. Das ist ein Problem des Dozenten. In einem vernünftigen Unterricht wird "ganz unten" angefangen. So kenne ich das auch aus Berufsschulen, Vorlesungen und der Ausbildung. Aber es ist in der Praxis wohl leider alles vertreten, was man sich vorstellen kann. Hehe Der kaufmännische Anteil stört dich offensichtlich wirklich. Ich weiß aber gar nicht genau warum. Hast du so schlechte Erfahrungen mit ausgelernten FIAEs gemacht? Konnten die alle nur rechnen und nicht programmieren? Ich fasse nochmal zusammen: Es gibt gute und schlechte Berufsschulen, Ausbilder/innen, Unternehmen, Studiengänge. Manche Azubis können schnell lernen, andere langsamer. Mancher findet die wirtschaftlichen Aspekte wichtig, mancher nicht. Solange die Voraussetzungen des Berufs so sind wie sie sind, können wir nur unser Bestes tun, um die Azubis auf die Prüfung vorzubereiten. Immerhin ist vor Kurzem eine Umfrage zur Neuausrichtung der IT-Berufe gestartet worden. Und wenn die Mühlen der Bürokratie schnell mahlen, können wir uns vielleicht schon zu 2025 auf einen eher technischen FIAE freuen. Bis dahin lasse ich meine Azubis weiterhin eine Amortisationsrechnung durchführen

Wie schon so oft muss ich leider wieder dagegen halten: Kaufmännische Inhalte sind Kernbestandteil der Ausbildung zum Fachinformatiker für Anwendungsentwicklung (und auch aller anderen IT-Berufe). Auch wenn viele Forenteilnehmer das (warum auch immer) nicht wahrhaben wollen. Ob die Gewichtung sinnvoll ist, darüber lässt sich sicherlich streiten. Welche Aussagekraft fehlt dir denn hier? Die Botschaft ist: Das Projekt amortisiert sich nach einiger Zeit und führt langfristig zu einer Kosteneinsparung im Unternehmen. Das ist doch genau die richtige Aussage, wenn die Entwicklerin in Zukunft noch ein Gehalt erwartet. Da hast du völlig recht. Ich hätte am liebsten auch zu jedem technischen Detail etwas gelesen, aber da die Abschlussarbeit (bei unserer IHK) auf 15 Seiten beschränkt ist, war dafür leider kein Platz. In einer Bachelor- oder Masterarbeit kann man sich bestimmt intensiv mit solchen Inhalten auseinandersetzen, aber für die Projektdoku muss man einfach Abstriche machen und eine sinnvolle Auwahl der Themen treffen. Dein gelungener Rant über die schlechte Ausbildung der Anwendungsentwickler ist ansonsten nett zu lesen. Allerdings ist die Berufsschule sehrwohl dafür da, die Prüflinge auf die Prüfung vorzubereiten. Clean Code mit DDD und Tests wird dann hoffentlich in den Ausbildungsunternehmen vermittelt. Dort findet der Praxisteil der Ausbildung statt. Dass Berufsschulen im Adaptieren neuer Konzepte nicht die schnellsten sind, ist sicherlich ein Problem. Aber auf der anderen Seite müssen die Schulen auch einer Vielzahl an Schülern mit unterschiedlichem Vorwissen Grundlagen der Programmierung beibringen. Und da kann es halt ein paar Wochen dauern, bis for und if durchgekaut sind. Dass die Azubis dafür u.a. Struktogramme oder Pseudocode lernen, liegt hauptsächlich daran, dass es nicht die eine Programmiersprache gibt, die alle Azubis können müssen und die dann in der Prüfung abgefragt wird. Aber das haben wir an anderer Stelle schon ausgiebig diskutiert. Insgesamt solltest du deine Anforderungen an die Berufsschulausbildung vielleicht etwas zurückfahren. Man sollte von einer Ausbildung nicht die gleichen Inhalte erwarten, wie von einem Studium. Wobei auch bei letzterem in den meisten Fällen DDD und Unit-Tests sicherlich kein Lehrinhalt sind. Dort wird doch teilweise noch länger der alte Kram durchgekaut. Aber das möchte ich jetzt nicht weiter vertiefen Ich halte es auch für sehr schwierig, Lerninhalte an aktuelle Entwicklungen in der IT anzupassen. Nehmen wir mal DDD als Beispiel: Das Konzept ist schon relativ alt (Eric Evans Buch ist von 2003), aber richtig Fahrt aufgenommen hat es erst in den letzten Jahren durch Microservices usw. Wer hätte das vorhersehen und vor 5 Jahren einen entsprechenden Lehrplan aufstellen können, der heute zeitgemäß ist? Und wer sagt überhaupt, dass DDD die "richtige" Art zu programmieren ist? Was ist mit den tausenden anderen Konzepten und Ideen der Softwareentwicklung? Würdest du bei einem Automobilzulieferer C-Code nach DDD entwickeln? Huch, C kennt ja nichtmal Objektorientierung! Da muss dann wohl doch eine andere Lösung her. Ich habe ein wenig den Eindruck, dass du deine eigenen Erfahrungen und Qualitätsstandards auf alle anderen Entwickler überträgst. Doch da die Programmiersprachen, Anforderungen, Paradigmen usw. da draußen so unterschiedlich sind, geht das leider nicht. Ein (ernstgemeinter) Ratschlag: Frag deine IHK, ob sie noch Prüfer braucht! Mit deinem Engagement bist du in der Rolle genau richtig. Dann bekommst du aber auch mal einen Einblick in die Realität vieler Betriebe da draußen und entschärfst deine Meinung vielleicht etwas. Clean Code ist ein super Konzept. Genau wie Unit-Tests und Pair Programming. Aber wenn du dich da draußen mal umschaust, wirst du feststellen, dass nur ein Bruchteil der Unternehmen diese Ideen tatsächlich umsetzt. Mir fällt es jedenfalls nicht schwer, nachzuvollziehen, warum die Objektorientierung immer noch das vorherrschende Paradigma in der IHK-Prüfung ist (und sicherlich auch in normalen IT-Studiengängen). Man setzt halt auf bewährte grundlegende Konzepte. Die konkrete Ausgestaltung und Ausschmückung mit Frameworks, Architekturideen, Sprachfeatures usw. obliegt dann den Ausbildungsbetrieben, die passend zu ihrer Sprache und Branche die Inhalte auswählen. Und auch da wird nicht immer der neuste Kram eingesetzt, sondern sehr oft auch uralte Sprachen und Frameworks. Denn das Update auf v2.0 oder den Rewrite in Haskell bezahlt den Unternehmen leider meistens kein Kunde...

Leider interpretiert jede IHK bzw. jeder Prüfungsausschuss die Vorgaben anders. Daher würde ich mich nicht auf deinen Ratgeber verlassen, sondern bei deiner IHK nachfragen. Häufig gibt es ein Merkblatt, auf dem steht, welche Zielgruppe deine Präsentation haben soll/darf. Bei uns ist z.B. immer der Prüfungsausschuss die Zielgruppe und auf "simulierte Kunden" wird verzichtet (das wirkt doch immer sehr konstruiert). Andere IHKen geben aber explizit die Auwahl z.B. zwischen "Abteilungsleiter", "Kunden", "Kollegen" usw. vor. Halte dich an das, was deine IHK von dir verlangt und gestalte die Präsentation dann zielgruppengerecht (z.B. beim Abteilungsleiter die internen Kosten mit rein, beim Kunden nur die externen). Zu Beginn deiner Präsentation sagst du dann ganz deutlich, an wen sich der Vortrag richtet, damit die Prüfer mit diesem Hintergrund deine Leistung bewerten. Das Gleiche gilt für die Inhalte der Präsentation: Hier ist z.B. bei uns gerade eine komplette Zusammenfassung der Projekts mit allen Phasen und Artefakten wichtig, da nicht alle Prüfer die Doku gelesen haben (ist zeitlich gar nicht machbar). Wenn deine IHK das anders haben will, halte dich daran. Aber auch das bekommst du nur heraus, wenn du nachfragst (oder auf der Website der IHK danach suchst). Scheu dich auch nicht davor, bei deiner IHK anzurufen, wenn du online keine Infos findest. Dafür sind die Damen und Herren da!

Das Thema wurde in diesen beiden Threads schonmal (an-)diskutiert: Aber ein paar zusätzliche Tipps kann ich wohl beisteuern (sehr entwicklerlastig): http://dotnetrocks.com/ https://devchat.tv/ruby-rogues http://developeronfire.com https://www.greaterthancode.com http://www.codenewbie.org https://www.functionalgeekery.com http://www.hanselminutes.com http://www.se-radio.net/ https://joecolantonio.com/testtalks/ https://thewebplatform.libsyn.com/

Sehr gerne. Kennt sich jemand damit aus?

Nein, auf dem Zettel steht nur bestanden oder nicht. Die Ergebnisse, die der Ausschuss mitteilen könnte, sind noch vorläufig, solange die IHK sie nicht offiziell bestätigt hat. Daher geben viele Ausschüsse die einzelnen Noten nicht heraus. Man kann aber einfach höflich fragen und bekommt dann vielleicht eine unverbindliche (!) Aussage.

Na klar, gerne! Sofern du nicht irgendwelche Bildrechte damit verletzt...

Danke sehr. Das freut mich!

Aber immer doch! Hast du ein Thema im Hinterkopf?

Gerne! Ich schaue mal, was mir noch so einfällt, falls sich hier keine konkreten Themenvorschäge ergeben.

Also manchmal frage ich mich, was die Prüflinge eigentlich so von uns Prüfern denken. Glaubt ihr wirklich, jemand würde euch wegen eines fehlenden Strichs 25% der Punkte nicht geben? Das kann ich mir nicht vorstellen. Ich kann jetzt nicht für alle Ausschüsse sprechen, aber ein wenig Menschlichkeit sollte da noch vorhanden sein Mal im Ernst: Wenn eindeutig erkennbar ist, welche Aufgabe nicht bearbeitet wurde, z.B. durch Eintragen der Nummer auf dem Deckblatt, Streichen der Aufgabe oder einfach Nichtbearbeiten derselben, wird euch niemand einen Strick daraus drehen und stumpf die letzte - komplett bearbeitete - Aufgabe streichen. Was leider durchaus vorkommt (habe ich schon selbst mehrfach gesehen), ist, dass der Prüfling alle (!) Aufgaben teilweise bearbeitet und keine eindeutig streicht. Dann muss leider der Standardfall mit dem letzten Handlungsschritt greifen. Das kann man dann aber wirklich nicht dem Prüfer anlasten. Denn ein wenig Formalismus sollte man auch den Prüflingen durchaus zutrauen dürfen. Und die Anweisungen bzgl. der Streichung sind sicherlich deutlich genug zu erkennen.

Spannendes Thema! Leider kann ich damit nicht dienen. Krankenversicherung und Cloud passt (aktuell) nicht so ganz zusammen Aber vielleicht haben wir hier ja noch ein paar andere Forenteilnehmer, die berichten können. Ich würde auch die Technik übernehmen, falls jemand drüber schnacken (und nicht schreiben) will!

Hallo zusammen, um den Fachinformatiker-Blog mit etwas mehr Leben zu füllen, würde ich gerne wissen, welche Themen euch interessieren. Womit können wir euch am besten helfen? Eher technische Themen oder Tipps zur Prüfungsvorbereitung? Lieber Projektdokumentation oder Fachgespräch? Besser Blog-Beiträge oder Podcast-Episoden? Oder, oder, oder... Ich freue mich über euer Feedback! Schreibt mir gerne eure Wunschthemen oder Vorschläge für deren Gestaltung! Und auch Kritik an den bisherigen Blog- und Podcastinhalten nehme ich gerne an. Dadurch könnten wir im nächsten Jahr diese Seite mit noch mehr relevanten Inhalten für alle Azubis und Prüflinge da draußen füllen. Viele Grüße! Stefan

Diese Woche beenden wir das ISO/OSI-Modell mit den Schichten 5 bis 7: Sitzungs-, Darstellungs- und Anwendungsschicht. Fachinformatiker-Podcast #7: Das ISO/OSI-Modell (Teil 4) (Länge ca. 35 Minuten, Größe ca. 12 MB) Sitzungsschicht (Session Layer) Wie wird eine dauerhafte Kommunikation von Netzwerkteilnehmern aus unterschiedlichen Anfragen und Antworten (Dialog) ermöglicht? Einheit: Daten Zusätzliche Informationen: Zuordnung von Anfragen und Antworten zueinander, Wiederaufsetzpunkte bei Ausfall der Kommunikation Hardware: siehe Anwendungsschicht Protokolle: RPC, siehe Anwendungsschicht Darstellungsschicht (Presentation Layer) Wie können Daten unabhängig von der konkreten Repräsentation auf den beteiligten Systemen verständlich ausgetauscht werden? Einheit: Daten Zusätzliche Informationen: Syntax der Daten, Encoding, Verschlüsselung, Kompression Hardware: siehe Anwendungsschicht Protokolle: ASN.1, siehe Anwendungsschicht Anwendungsschicht (Application Layer) Wie können anwendungsspezifische Daten und Befehle ein- und ausgegeben werden? Einheit: Daten Zusätzliche Informationen: Semantik der Daten Hardware: Gateway, Load Balancer, Proxy, Firewall Protokolle: HTTP, FTP, SMTP Alle bisherigen und auch die zukünftigen Episoden des Podcasts bekommst du über den RSS-Feed auch im Podcatcher deiner Wahl: http://fiae.link/FIPodcastRSS Hast du Ideen für Themen weiterer Podcast-Episoden? Dann schreib gerne einen Kommentar!

Aber genau so ist es. Schau mal in die Berufsverordnung. Da siehst du folgenden Teil zum Abschlussprojekt eines FISIs: Programmierung ist da nicht angesagt. Das machen die Anwendungsentwickler/innen!

Für alle, die nicht suchen wollen: LF 1: Der Betrieb und sein Umfeld LF 2: Geschäftsprozesse und betriebliche Organisation LF 3: Informationsquellen und Arbeitsmethoden LF 4: Einfache IT-Systeme LF 5: Fachliches Englisch LF 6: Entwickeln und Bereitstellen von Anwendungssystemen LF 7: Vernetzte IT-Systeme LF 8: Markt- und Kundenbeziehungen LF 9: Öffentliche Netze, Dienste LF 10: Betreuen von IT-Systemen LF 11: Rechnungswesen und Controlling Das zeigt übrigens sehr gut, dass der Fachinformatiker ein kaufmännischer Beruf ist (was an anderer Stelle immer mal wieder in Frage gestellt wird). Mind. 5 der obigen Lernfelder haben nichts mit IT zu tun, sondern mit "Wirtschaft"

Das sind die sog. "Lernfelder" in der Berufsschule. Hier kannst du sie dir anschauen: http://www.kmk.org/fileadmin/Dateien/pdf/Bildung/BeruflicheBildung/rlp/Fachinformatiker97-04-25.pdf

Naja, hexadezimal im Kopf rechnen zu können macht noch keinen guten ITler aus. Wo braucht man das in der Praxis!? Zum Einstieg empfehle ich das Handbuch für Fachinformatiker von Sascha Kersken. Das gibt eine gute Übersicht über allerlei IT-Kram Und es enthält auch einige Beispielaufgaben zu jedem Kapitel, um das Verständnis zu prüfen.

Danke für die Hinweise! Na klar, die "sicheren" Verbindungen sind absolut relevant. Und mit Telnet habe ich mich derbe vertan. Das muss natürlich 23 sein! Nein, mehr kommt zu Schicht 4 nicht (also keine Retransmissions, OSPF usw.). Nur noch nächste Woche die letzten drei Schichten. Aber wenn du magst, lade ich gerne zu einer gemeinsamen Aufnahme deiner Themen ein! Die sind mir als Anwendungsentwickler so ganz allein nämlich zu FISI-lastig Die CRE-Episode kenne ich schon, aber den RfC-Podcast abonniere ich direkt mal. Danke für den Tipp.

Wir machen mehrere Projekte mit JavaEE. Spring ist eine Alternative zu EE. Die "reinen" EE-Standards, die häufig verwendet werden, sind wohl JPA als ORM (z.B. mittels Hibernate), JSF für das Frontend (z.B. mit PrimeFaces), JAX-RS für REST (z.B. Jersey) und CDI um alles zu verdrahten (mittels @Inject usw.). Aber das schöne an Java EE ist ja die große Auswahl (ich glaube es sind 32) an Spezifikationen, die aufeinander abgestimmt sind. Du kannst also z.B. auch JAXB für XML einsetzen oder JTA für Transaktionen, wenn du sie brauchst. Mit Version 7 sind einige wichtige Technologien ergänzt worden. Und die Schwergewichtigkeit der alten Versionen ist aufgelöst. Java EE 7 ist schon wirklich einfach und braucht wenig Code.

Welche Kosten kalkulierst du denn überhaupt? Eure internen Projektkosten, die dem Kunden in Rechnung gestellt werden? Dafür ist egal, ob der Kunde sich einen Server angeschafft hat. Und falls ihr ihn im Auftrag des Kunden angeschafft habt, rechnest du den ganzen Server mit rein (denn den muss er euch ja bezahlen). Ob und wie der Kunde ihn dann abschreibt, ist für deine Projektkosten irrelevant. Falls du eine Amortisationsrechnung für den Kunden erstellst (warum auch immer das deine Aufgabe sein sollte), gehört die AfA natürlich mit dazu,

Grundsätzlich solltest du dich als Prüfling mit der rechtlichen Lage bzgl. der Nutzung von Logos usw. auseinandersetzen. Aber ich vermute, dass kein Prüfer dir einen Punkt abziehen wird, wenn du nicht hinter jedes "Microsoft" im Text ein "(r)" schreibst (was ich tatsächlich schon so gesehen habe). Ich finde das für den Lesefluss eher nervig. Und in der Präsentation sieht das auch sehr seltsam aus. Ich würde mich als Prüfer dadurch sogar aufgefordert sehen, Fragen zum Thema Markenrecht zu stellen! Ich will nicht sagen, dass das Thema unwichtig ist. Die Präsentation ist allerdings nicht öffentlich und du verdienst kein Geld damit. Also sollten sich die rechtlichen Konsequenzen stark im Rahmen halten. Aber egal wie du dich entscheidest: Die Prüfer könnten dir im einen wie im anderen Fall Fragen dazu stellen. Also bereite dich entsprechend vor.

Diese Woche habe ich nur eine einzige Schicht geschafft: Die Transportschicht. Aber die hat es in sich! Fachinformatiker-Podcast #6: Das ISO/OSI-Modell (Teil 3) (Länge ca. 35 Minuten, Größe ca. 12 MB) Sicherungsschicht (Data Link Layer) Wie kommen auch große Datenmengen vollständig und in der korrekten Reihenfolge beim richtigen Dienst des Empfängers an? Einheit: Segment bzw. Datagramm Zusätzliche Informationen: Ports, Ende-zu-Ende-Kommunikation möglich Hardware: Firewall, siehe Anwendungsschicht Protokolle: TCP, UDP Sonstiges Three-Way-Handshake: SYN - SYN/ACK - ACK Wichtige Protokolle und Ports: Telnet (20), FTP (21), SSH (22), SMTP (25), HTTP (80), POP3 (110), IMAP (143), SMB (137-139), HTTPS (443), Doom (666) ;-) Alle bisherigen und auch die zukünftigen Episoden des Podcasts bekommst du über den RSS-Feed auch im Podcatcher deiner Wahl: http://fiae.link/FIPodcastRSS