Saheeda

Hallo, ich arbeite gerade an einer Anwendung (A), welche Daten von anderen passwortgeschützten Anwendungen (B1, B2) abruft und aufbereitet. Mein Problem: Wie speichere ich die Passwörter? Mit Hash/Salt in der Datenbank ablegen geht nicht, da ich sie zur Authentifizierung von A gegenüber B1 und B2 im Klartext benötige. Passwörter im Klartext in der Datenbank speichern verbietet sich von selbst. Ein anderer Weg wären Konfigurationsparameter, womit ich aber Flexibilität verliere. Kommt jetzt noch eine dritte oder vierte Anwendung hinzu, muss ich weitere zusätzliche Konfigurationsparameter definieren. Gibts noch bessere Ideen, damit umzugehen?

@RipperFox Nein, ich hatte bis eben noch nie was davon gehört. Ich habe aber auch generell mit Unix sehr wenig zu tun.

Es stellt sich natürlich erstmal die Frage, warum man einen Code x-fach an verschiedenen Stellen einfügen muss und ob sich das nicht mit Templates lösen lässt. Wenn Templates o.ä. keine Alternative sind: Quellcode ist am Ende auch einfach nur Text. Schreib dir n kleines Programm, was den Inhalt einer Datei in einen String liest, manipuliert und wieder zurück in die Datei schreibt. Und das Programm lässt du dann über deinen Quellcode laufen. Ich hab sowas ähnlich vor ner Weile mal für n Java-Projekt gemacht. Es ist etwas Bastelarbeit und fummelig, aber es geht. Edit: Oder du bastelst dir n Regex, um ne bestimmte Position in den Dateien zu suchen und machst damit im Projekt suchen/ersetzen.

Hi, es wären in meinen Augen sinnvoller, sich auf ein Projekt zu konzentrieren und dieses auch abzuschließen. Das dürfte auch für künftige Projekte eine deutlich bessere Startposition bringen. Ich persönlich würde in kein Projekt investieren, dass eher geringe Chancen hat, ansatzweise fertig zu werden. Und: sucht euch vielleicht erstmal kleinere Projekte und versucht nicht gleich mit großen etablierten Produkten zu konkurrieren (ich schiele da auf euren Messenger).

Ich würde mein Thema nicht danach aussuchen, ob es besonders oder 08/15 ist, sondern ob ich damit die notwendige fachliche Tiefe erreiche und es auch sauber in der gesetzten Zeit bewältigen kann. Lieber ein 08/15-Projekt ordentlich über die Bühne gebracht, als irgendwas total Abgefahrenes, was am Ende in die Hose geht.

Kannst du nicht einfach n Beispiel aus einem privaten Projekt nehmen? Wenn das im Rahmen des Vorstellungsgespräch bewertet werden soll, gehe ich von wenigen hundert Zeilen Code aus, dass lässt sich auch aus nem kleinen eigenen "Spielprojekt" nehmen.

Aber mach nicht den Fehler, die Stichpunkt genauso stichpunktartig abzuarbeiten. (Stefan Macke erwähnte mal in einem seiner Podcasts, dass er als Prüfer vermehrt genau das sieht: Dokumentationen, in denen seine Hinweise so kurz wie möglich "beantwortet" wurden.)

Pseudocode. Im Code schreiben bin ich geübt, das geht mir einfach von der Hand (wenn die grobe Idee erstmal steht). Bei PAP oder Struktogramm muss ich überlegen, wie genau die "Syntax" dafür ist, um mir nicht dadurch Fehlerquellen einzubauen.

Hi, wie gut ist dein Englisch? Du wirst vermutlich jeden Tag zumindest schriftlich damit zu tun haben. Ansonsten: Frag doch mal deinen Mann. Wenn er bei derselben Behörde arbeitet, kann er ja ungefähr einschätzen, wo deine Schwächen liegen (in Bezug auf den Tätigkeitsbereich der FISIs in dieser Behörde= und auf welchem Stand du im Vergleich zu anderen Azubis bist. Mit Microsoft Office wirst du vermutlich wenn überhaupt dann nur peripher zu tun haben, zu viel Zeit würde ich darin nicht versenken. Stress dich nicht. Eine Ausbildung ist zum Lernen da. Ich wünsche dir ganz viel Erfolg.

@Julian-B90 Die Vorgaben "meiner" IHK (Dresden) waren ähnlich denen deiner. Da hier im Forum oft die Punkte Ist-Analyse und Soll-Konzept mit aufgeführt werden, hatte ich dies mit aufgenommen und mein Antrag wurde auch im ersten Anlauf akzeptiert. Irgendwo ist es auch logisch: Du musst in deinem Antrag irgendwie darlegen/plausibel machen, warum und mit welchem Ziel das Projekt durchgeführt wird. Ob du das jetzt explizit "Ist-Analyse" nennst oder anderweitig im Text beschreibst, macht ja inhaltlich keinen großen Unterschied. (Wenn die jeweilige IHK so einen Punkt explizit fordert ist es natürlich schlau, das auch dort aufzuführen!).

Hm, also ich würde hier glaube nur noch ein paar Sachen ändern: das hier umformulieren das hier streichen, Bezug zur Firma einbauen und Rechtschreibung/Grammatik prüfen lassen. Ansonsten weiß ich nicht, wo hier zu viel Pathos sein soll. Ich lese Motivation, Begeisterung und Liebe zur Technik - genau das ist doch die Grundvoraussetzung für eine Anstellung, egal ob Azubi oder Facharbeiter. Bei einem angehenden Azubi würde ich ehrlich gesagt auch darüber hinweg sehen, dass das Berufsbild vielleicht noch nicht zu 100% zur Realität passt. Darüber informieren ja - aber die konkrete Praxis sieht doch am Ende eh anders aus. Ich denke, bei uns würdest du ne Einladung zum Vorstellungsgespräch erhalten.

Inhaltlich finde ich den Punkt gar nicht so schlecht, nur an der Formulierung müsste man arbeiten. Was ich daraus lese: Der TO hat gemerkt, dass die Ausbildung die falsche Entscheidung war. Statt jetzt aber mittendrin abzubrechen hat er (oder sie) sich gesagt "Arschbacken zusammenkneifen und durch". Genau das ist doch die Skepsis bei krummen Lebensläufen: "Wird derjenige es diesmal durchziehen?", "Wird sich die Investition in die Ausbildung rentieren?". Ich stimme Maniska aber insofern zu: Weniger Mimimi. Erzähl, was du gemacht hast, womit du dich beschäftigst, was dich begeistert. Wenn du n Mini-ITX zusammengeschraubt hast, erzähl das. Wenns dir Spaß macht, an irgendwelchen technischen/logischen Problemen zu schrauben, erzähl das. Wenn du dir (rudimentäre) Skript-Kenntnisse angeeignet hast, erzähl das. Von Excel würde ich glaube erst anfangen, wenn mir sonst nichts Besseres einfällt.

Ich hatte damals keine. Mein Chef grinste mich bei der Frage an und meinte nur "Wir hatten 3 Jahre Zeit, uns kennen zu lernen, ich denke, das passt."

Im 1. Lehrjahr haben wir vor allem Übungsaufgaben gemacht, um das erkennen/analysieren von Problemen und deren Zerteilung zu üben. Die Programmieraufgaben gingen mehr in Richtung "Entwirf einen Algorithmus für Problem xy" oder "Implementiere Algorithmus xy". Gegen Ende des 1. Lehrjahrs wurden wir in die firmeneigenen Frameworks eingearbeitet. Das fing bei "Bau ne einfache Bücherverwaltung" an und wurde mit der Zeit immer komplexer (Vernünftiges Fehlerhandling, externe APIs/Urls abfragen, Benachrichtigungen erzeugen, etc.) Im 2. Lehrjahr wurden wir stückchenweise in reale Projekte integriert (aufgrund der Projektgrößen waren dies nur Teilmodule). Die Aufgaben waren quer beet: XLS auslesen und importieren, Datenbankmigration, GUI nach Vorgaben umsetzen. Im 3. hatte ich die erste eigene (kleine) Anwendung (von Datenbank bis hin zu GUI und Kommunikation mit nem anderen System war da fast alles drin). Mein Ausbilder stand mir währenddessen noch bei der Konzeption/größeren technischen Problemen zur Seite. Gelernt habe ich primär Java und n bisschen JavaScript.

Ich geh noch n Schritt weiter: Wer den Code schreibt, muss ihn (bzw die Anwendung) auch dokumentieren. Wenn ich von unseren Projekten ausgehe, steckt im Code oft viel implizites Wissen. Doku ist nicht nur "was" macht der Code (das sehe ich), sondern vor allem "warum". Es geht um den größeren Zusammenhang, Querverweise auf ähnliche Konstruktionen (und den Unterschied dazu), Querverweise aufs Konzept oder andere Quellen, Hinweise zur Benutzung, etc.