stefan.macke

Mitglieder
  • Gesamte Inhalte

    774
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    34

stefan.macke hat zuletzt am 23. Januar gewonnen

stefan.macke hat die beliebtesten Inhalte erstellt!

4 Benutzer folgen diesem Benutzer

Über stefan.macke

  • Rang
    Reg.-Benutzer

Contact Methods

  • Website URL
    http://fachinformatiker-anwendungsentwicklung.net/

Profile Information

  • Ort
    Deutschland
  1. Ich habe mir vor einigen Monaten einen Fujitsu ScanSnap ix500 gekauft. 400 Euro, aber das Ding ballert super schnell alles durch, was es so gibt. Kassenbons, doppelseitige Dokumente. Und alles sofort inkl. OCR. Den kann ich definitv empfehlen, wenn du einen Berg Dokumente abzuarbeiten hast.
  2. Aus eigener Erfahrung kann ich sagen, dass immer versucht wird, viele Punkte für die Prüflinge rauszuholen. Wenn du nicht völligen Unsinn schreibst, wirst du auch Punkte bekommen. Nicht umsonst steht fast unter jeder Musterlösung "andere Antworten möglich".
  3. Es gibt eigentlich keine "Pflichtinhalte" in den Projektdokus. Wenn für dein Projekt eine Kundendoku nicht sinnvoll ist, dann erstellst du keine. Irgendeine Form der Dolumentation wird aber erwartet (siehe Bewertungsmatrizen der IHKen). Also "Wir dokumentieren in unserem Betrieb nicht" ist keine Ausrede Sicherlich steigt die Chance auf eine gute Note, wenn gewisse Inhalte in der Projektdoku enthalten sind. Eine Kunden-/Benutzerdoku zähle ich durchaus dazu. Aber sie muss halt auch zum Projekt passen und darf keinen Selbstzweck darstellen. In deinem konkreten Fall würde ich mal hinterfragen, warum euer Kunde keine Doku von euch bekommt! Ist das Produkt selbsterklärend? War er bei der Entwicklung beteiligt? Das sind Gründe, die gegen eine Kundendoku sprechen, die ich dann an deren Stelle in deiner Projektdoku erwarten würde. Bei einer Entwicklung für einen Kunden erwarte ich entweder eine Doku oder eine vernünftige Begründung, warum diese nicht erstellt wurde.
  4. Das kann ich nur absolut unterstreichen! Die Vorlagen und Beispieldokus sind nicht dazu gedacht, sie 1-zu-1 abzuschreiben oder ohne Nachdenken ihre Struktur zu übernehmen! Sie dienen als Hilfe und Anregung, aber der Aufbau und natürlich die Inhalte sind immer an das eigene Projekt anzupassen! Kapitel, die nicht sinnvoll sind, gehören gestrichen und Inhalte, die fehlen, müssen natürlich ergänzt werden. Ansonsten kann die Doku wie jede andere Quelle auch zitiert werden. Allerdings bitte mit Beschreibung, was zitiert wurde, und nicht einfach die Doku ins Quellenverzeichnis packen. Das kann dann ja alles und nichts bedeuten.
  5. Passwörter sollten gesalzen und gehasht werden (in der Reihenfolge). Das Salz steht einfach als individueller Wert für jeden Benutzer im Klartext in einer separaten Spalte in der Benutzertabelle. Gehasht wird dann z.B. Salz + Passwort, gerne auch mit Trennzeichen dazwischen. Das Salz dient nicht der Sicherheit des Passwortes und kann daher im Klartext vorliegen. Vielmehr soll das Salz verhindern, dass Benutzer mit gleichen Passwörtern einfach identifiziert werden können. Da das individuelle Salz vor dem Hashen zum eigentlichen Passwort hinzugefügt wird, sind auch bei identischen Passwörtern die zu hashenden Strings unterschiedlich. In der Datenbank ist somit nicht mehr ersichtlich, wenn mehrere Benutzer die gleichen Passwörter verwenden (was bedeuten würde, dass mehrere Accounts kompromittiert werden können, wenn ein einziges Passwort geknackt wird). Der Wert des Salzes kann beim Anlegen eines Benutzers zufällig generiert werden. Er muss dann aber natürlich in der DB gespeichert (und danach nicht mehr verändert) werden, da er jedes Mal beim Prüfen der Benutzerdaten verwendet werden muss, um das übergebene Passwort zu salzen und danach zu hashen.
  6. Ich würde alles, was du beschreibst, in einem gemeinsamen Unterkapitel zur Nutzwertanalyse erwarten. Ob du es nun vor oder nach der eigentlichen Nutzwertanalyse (also der Tabelle) schreibst, ist mehr oder weniger egal. Zusätzliche Kapitel würde ich dafür aber nicht extra einführen. Du wirst ja kaum mehrere Seiten damit füllen. Und allein die Tatsache, dass du an all diese Informationen denkst, unterscheidet dich schon von anderen Prüflingen ;-) Allerdings würde ich mir noch einmal Gedanken über die Benennung, also die Überschrift des Kapitels machen. Einfach nur "Nutzwertanalyse" finde ich wenig aussagekräftig. Wichtiger wäre doch, warum du die Nutzwertanalyse überhaupt erstellst. Sie hat ja keinen Selbstzweck. Ein besserer Titel wäre also so etwas wie "Anbieterauswahl" oder "Vergleich der Softwarelösungen".
  7. Uhhh. Da überträgt aber jemand seine Erfahrungen aus dem Alltag gefährlich auf die Allgemeinheit. UML ist weder veraltet noch praxisfern. Im Gegenteil: Es ist der Industriestandard für den modellbasierten Softwareentwurf und die Dokumentation. Natürlich braucht man UML nicht, wenn man einfach drauflos programmiert und eh nichts dokumentiert Und Softwareentwicklern zu empfehlen, SQL nicht zu lernen, weil es ORMs gibt, halte ich schlichtweg für völlig falsch. ORMs sind kein Allheilmittel und haben ihre ganz eigenen Probleme (z.B. N+1). Entwickler, die SQL nicht beherrschen, sind meiner Meinung nach keine richtigen Entwickler. Das wäre so als wüsste der KFZ-Mechaniker nicht, wie eine Bremse funktioniert, weil es ja ABS gibt. Von den Pseudocodeaufgaben mag man halten, was man will. Aber es ist immer wieder erstaunlich, wie viele "Anwendungsentwickler" keine for-Schleife auf die Reihe bekommen. Da helfen dann auch keine "modernen" Ansätze mehr. Ich halte es jedenfalls für ansolut richtig, gerade diese absoluten Grundlagen der Programmierung abzufragen. Denn sie werden von allen Programmiersprachen angeboten und müssen allen Prüflingen bekannt sein. Nur weil ich z.B. heute eher Map/Filter/Reduce verwende (vorausgesetzt meine Sprache erlaubt es mir), heißt das ja nicht, dass ich Schleifen oder if-Abfragen nicht mehr verstehen muss. Das sehe ich analog zu ORM und SQL. Also kurz zusammengefasst: Mit pauschalen Aussagen wie "X braucht doch niemand mehr" wäre ich sehr vorsichtig. Was ich letztens noch in einem Artikel gelesen habe: die Entwicklerin der Software für die Voyager-Sonde (die seit den 1960ern immer noch weiterentwickelt wird) wäre froh über "moderne" Konzepte wie switch/case
  8. Ich würde den kostbaren Platz in deiner Doku besser für die Dinge nutzen, die deine fachlichen Fähigkeiten unter Beweis stellen. Klickorgien mit 15 Seiten Screenshots sind keine ausreichende Projektarbeit. Du musst dein methodisches Vorgehen zeigen, deine Entscheidungen begründen, die Wirtschaftlichkeit berechnen, das System mit üblichen Diagrammen dokumentieren, Anbieter vergleichen, Tests durchführen usw. Es gibt so viele spannende Inhalte, die du in der Doku unterbringen kannst. Bitte spar dir die "Installationsanleitungen" bzw. reduziere sie auf ein Minimum. Ich vergleiche das mal mit einem Anwendungsentwickler: Wenn der mir auf 3 Seiten detailliert eine for-Schleife beschreibt, weiß ich, dass das Projekt kaum Substanz hat. Für die Projektdoku sind z.B. eher die architekturellen Entscheidungen interessant, also das große Ganze. Die trivialen Details kleiner Algorithmen haben in einer Doku meiner Meinung nach nichts verloren. Um es wieder in deinen Kontext zu setzen: Anstatt detailliert zu zeigen, wie du einen Installationswhizard durchklickst, solltest du lieber schreiben, warum du diesen überhaupt nutzt. Wieso wurde dieses Tool überhaupt ausgewählt? Welche Vor- und Nachteile hat es? Welche Alternativen wurden aus welchen Gründen ausgeschlossen? Was soll ich als Prüfer bewerten, wenn du mir eine "Klickorgie" zeigst? Dass du gut auf "Ok" klicken kannst? Das kann bereits ein Azubi im 1. Lehrjahr ohne Nachzudenken. Nach 3 Jahren Ausbildung solltest du darüber hinaus sein und stattdessen Entscheidungen auf höherem Niveau treffen können. Zu deinem konkreten Beispiel: Welche Rollen gibt es überhaupt in deiner Software? Warum wird ein "Operator" angelegt? Welche Rechte muss/darf er haben? Welches grundlegende Authentifizierungs- und Autorisierungskonzept wird verwendet und warum? Wird das Tool an einen Verzeichnisdienst angebunden und warum (nicht)?
  9. Als kleine Ergänzung, warum das so ist: http://stackoverflow.com/questions/590747/using-regular-expressions-to-parse-html-why-not
  10. Um die NWA aber sinnvoll nutzen zu können, sollte diese Subjektivität möglichst eliminiert werden. Daher ist die Angabe der Werteskala und die Begründung für die vergebene Punktzahl so wichtig. Bei Skalen von 1 bis 100 kann fast nur eine rein subjektive Bewertung erfolgen. Wie beschrieben: Wie soll der Unterschied zwischen 75 und 76 Punkten glaubhaft begründet werden? Kleinere Skalen, die für jeden Wert genau festlegen, wann er zu vergeben ist, sind objektiv(er) einsetzbar. Beispiel: Kriterium "Dokumentation des Produkts" -> 0 Punkte: Keine Doku vorhanden, 1 Punkt: Englische Doku vorhanden, 2 Punkte: Deutsche Doku vorhanden, 3 Punkte: Deutsche Doku mit lauffähigen Beispielanwendungen vorhanden. Diese Bewertung kann von jedem Mitarbeiter vorgenommen werden, ohne großen Interpretationsspielraum. Natürlich ist es ein bestimmter Aufwand, für jedes Kriterium so eine Skala vorzubereiten. Aber genau das würde ich von einem Prüfling im Rahmen seiner Projektarbeit erwarten. Ansonsten kann man sich die NWA auch sparen und sich wahllos irgendwelche "Nutzwertkoeffizienten" ausdenken.
  11. Eine Gewichtung brauchst du, wenn es halt etwas zu gewichten gibt. In deinem ersten Beispiel sind alle Kriterien gleich wichtig. Für den unwahrscheinlichen Fall, dass das wirklich so ist, brauchst du keine Gewichtung. Was du unabhängig von der Gewichtung aber unbedingt noch einbauen solltest, ist eine Erklärung der zu vergebenden Punkte. Die Skala ist schon sehr krass: 0-50 Punkte. Was heißt das? Warum bekommt man z.B. 47 und nicht 48 Punkte? Wer bewertet das? Wie wird das überhaupt bewertet? Und durch die unterschiedlichen Skalen der Kriterien hast du eigentlich eine versteckte Gewichtung. Denn bei Kriterium 4 sind ja mehr als doppelt so viele Punkte möglich wie bei 1. Alles etwas seltsam. Mein allgemeines Feedback: Werteumfang deutlich reduzieren (z.B. 0-3); erklären, was die Werte bedeuten (z.B. 0 nicht vorhanden, 1 schlecht, 2 mittelmäßig, 3 hervorragend); Gewichtung einführen (es gibt immer Kriterien, die wichtiger sind als andere); erläutern, wer die Bewertung durchführt und wie sie auf die Werte kommen.
  12. Bei Arbeiten im Format DIN A4 wäre ein größerer Zeilenabstand, z.B. 1,5 Zeilen, angebracht, damit das Auge beim Lesen leichter die nächste Zeile findet. Ich kann mir aber nicht vorstellen, dass deine IHK keine Vorgaben dazu macht. Eine Schriftgröße ohne Zeilenabstand vorzugeben ist doch sinnlos, wenn man einheitliche und vergleichbare Dokumentationen haben möchte. Frag doch bitte bei deiner IHK nach, bevor du einfach frei entscheidest und vielleicht etwas übersehen hast. Nur das wird dir die Sicherheit geben, alles richtig zu machen.
  13. Verwende die Stundensätze deines Unternehmens, die dir eure Buchhaltung nennen kann. Selbst berechnen ist nicht sinnvoll, da du sicherlich irgendetwas vergisst oder falsch machst. Und das führt nur zu Fragen im Fachgespräch
  14. Einfach nur um von Einzelschicksalen wieder auf den allgemeinen Arbeitsmarkt zurückzukommen: der Fachinformatiker gehört seit Neustem zu den 10 beliebtesten Ausbildungsberufen bei männlichen Azubis. Von einer Abnahme der Nachfrage - bei Betrieben und Bewerbern - kann also wahrlich nicht die Rede sein. https://www.bibb.de/de/pressemitteilung_60513.php
  15. Wir setzen in der Ausbildung auch eine wenig verbreitete Sprache ein: Natural. Sie ist ähnlich zu Cobol. Damit verdient unser Unternehmen sein Geld, also müssen auch die Azubis die Sprache lernen. Aber als Ausbilder achte ich darauf, dass sie zusätzlich mindestens eine "moderne" Sprache wie Java oder C# lernen. Sowohl die Konzepte der Objektorientierung als auch andere Plattformen wie das Web sollten meiner Meinung nach in der Ausbildung heutzutage vermittelt werden. Ich habe also nichts gegen eine Ausbildung auf RPG, wenn zusätzlich auch moderne Inhalte berücksichtigt werden. Man kann als Unternehmen evtl. nicht nur das ausbilden, was für das Tagesgeschäft nötig ist, sondern muss auch darüber hinaus Inhalte anbieten. Darauf würde ich bei der Wahl des Ausbildungsplatzes achten.