Crow T. Robot

Hätte ich's doch geschrieben... Ooops.... Danke für die Hinweise, das mit dem Zeitraum habe ich tatsächlich noch nicht drin. Aber das hätte auch nichts gemacht, denn zusätzlich muss noch ein Formblatt über das durchgeführte Projekt ausgefüllt werden, in dem das explizit mit drinsteht.

(Sorry, falsch geklickt...)

Es ist auch keine bestimmte Formulierung vorgeschrieben- Du musst lediglich versichern, dass du das Projekt selbständig und ohne fremde Hilfe angefertigt hast. Nicht mehr und nicht weniger. Und dabei bloss nicht Datum und Unterschrift vergessen.

Auf den ersten Blick scheinen das Skript und die SQL-Löschabfrage korrekt zu sein. Allerdings hast du auch einige Infos "unterschlagen": - Was funktioniert nicht (in Bezug zu deiner Erwartung)? - Gibt es eine Fehlermeldung (wo/welche)? - Was gibt mysql_error() aus? - Wird der Datensatz wie gewünscht gelöscht? Ansonsten noch ein Hinweis: Zahlen-Feldwerte sollten nicht in Hochkomma oder Anführungszeichen gesetzt werden. Aber das sollte hier nicht das Problem sein, weil's MySQL auch so kann.

Das ist IMHO kein Kündigungsgrund, weder für eine ordentliche und schon gar nicht für eine ausserordentliche Kündigung. Siehe auch beim DGB zur Kündigung eines Ausbildungsverhältnisses und zur Zwischenprüfung.

Üblich sind Formatierungen dieser Art: Nachname, Vorname, Titel, (Auflage,) Jahr, Verlag Beispiel: Kofler, Michael, Visual Basic 6, 2000, Addison-Wesley Es empfiehlt sich, im Quellenverzeichnis für jeden Eintrag eine eindeutige Zitierweise zu definieren, etwa "VB6". Diese kann dann im Fliesstext oder in einer Fussnote referenziert werden, z.B. "VB6, S. 77 ff.".

Wie lang die Dokumentation minimal/maximal sein darf, erfährst du von deiner zuständigen IHK, üblich sind 10-20 Seiten. Entweder wird/wurde dir die Information zugeschickt, oder sie ist als Download auf der Website deiner IHK erhältlich. Im Zweifelsfall ruf dort an, die beissen nicht. Gezählt wird nur der eigentlich Inhalt ausschliesslich Deckblatt, Inhaltsverzeichnis und Anlagen. Um Platz zu schaffen ist daher zu empfehlen, alle Diagramme, Grafiken, Tabellen etc. in den Anhang zu verschieben.

Meine Erklärung lautet wie folgt: Ich habe dafür eine Extraseite zwischen Deckblatt und Inhaltsverzeichnis eingerichtet, das ganze habe ich aber auch schon als Anlage gesehen.

Wieso ist Times New Roman "keine Proportionalschrift"? Verwechselst du das eventuell mit Courier oder Courier New? Times und Konsorten sind sehr wohl proportional. Für Listings würde ich immer eine nicht-proportionale Schrift (eben Courier New) verwenden, allein schon um die Einrückungen und Ausrichtungen nicht zu verlieren. Sonst würde das Lesen sehr anstrengen.

Richtig. Die Serifen bilden vor allem an der Grundlinie der Schrift eine nahezu durchgehende Führung für's Auge des Betrachters. Das macht es einfacher, in der richtigen Zeile zu bleiben. Also ich benutze "Geneva", IIRC gehört die aber nicht zum Standardumfang. Keine Ahnung, woher ich die habe. Ansonsten gefällt mir "Book Antiqua" (in 11pt) sehr gut. Im Gegensatz zu "Bookman Old Style" sind die kursiven Zeichen wesentlich eleganter und die Fettschrift nicht so klotzig. "Verdana" ist ja eigentlich speziell für's Web und die Bildschirmdarstellung entwickelt, und nicht für den Druck. "Tahoma" gefällt mir auch recht gut, aber die Fettschrift ist mir etwas zu fett. Da finde ich "Trebuchet MS" besser, das verwende ich oft für Überschriften. Auf dem Mac wäre wohl "Helvetica" für eine serifenlose Schrift Standard...

Du musst kein PH erstellen, wenn es deine zuständige IHK nicht als Teil der Doku fordert. Selbst einer meiner Ex-Dozenten, der auch Prüfer ist, hält ein PH für abdingbar. In der Praxis gehört ein PH aber unbedingt zu einem vollständigen Projekt, allein schon weil dieses die inhaltliche Vertragsgrundlage darstellt. Bei einem internen Projekt wird es wohl kaum einen Werk(lieferungs)vertrag in dem Sinne geben, ohne PH hast du aber kein dokumentiertes Ergebnis der Fachkonzeptphase. Wichtig ist auf jeden Fall, dass du ein PH ablieferst, wenn du im Projektantrag eines angegeben hast. Ansonsten musst du dir eine gute "Ausrede" einfallen lassen.

Hallo jahfire! Wenn deine IHK keine bestimmte Schriftart fordert, warum "solltest" du dann eine andere verwenden? Davon mal abgesehen, und ganz allgemein: Für längere Texte wie eine Projektdoku würde ich immer eine Serifenschrift verwenden. Aber bitte nicht "Times New Roman", die ist potthässlich und an der erkennt man jedes Word-Dokument auf 100 Meilen Entfernung.

Hallo DerWolf! Ein neuer Thread wäre schon besser gewesen, denn deine Frage betrifft zwar auch das PH, hat aber eine andere Zielrichtung. Die Anfertigung eines PH ist unabhängig davon, ob das Projekt intern ist oder nicht. Bei einem internen Projekt ist es mindestens genau so wichtig. Insbesondere wenn es ein Teilprojekt eines größeren Gesamtprojekts ist.

Am besten Präsens unter Vermeidung des Ich-Stils. An einigen Stellen, wo zurückblickend dokumentiert wird, ist natürlich auch eine passende Vergangenheitsform möglich. Genauso wie im abschliessenden "Ausblick" (z.B. auf Folgeprojekte) auch eine Zukunftsform möglich ist.

DoEvents brauchst du nur dann, wenn du zwischendurch z.B. Aktualisierungen im Formular vornimmst, z.B. für den Progressbar. Wenn du sowas nicht nutzt, kannst DoEvents weglassen, allein schon wegen der Beschleunigung.

Hallo Phantom der Oper! Vielleicht habe ich das etwas zu streng formuliert. Ich meinte damit nicht, dass das Pflicht ist. Die IHKn/PAs verlangen üblicherweise keinen Quelltext.

Das erinnert mich an was: Bei der Index-Eigenschaft gibt man auch nicht den Namen des indizierten Feldes (also "Monat") an, sondern den Namen des Indexes. Wenn man den nicht manuell ändert, verleibt die Voreinstellung "PrimaryKey". HTH

Hallo Problemchild! Ganz einfach: Wenn du bei INSERT INTO nicht alle Felder mit Werten füllst, musst du auch angeben, welche Spalten gefüllt werden sollen. Also z.B. INSERT INTO projekt (Vorname, Name, Strasse, Ort, Plz, Geburt, Geschlecht) VALUES ('$Vorname', '$Name', '$Strasse', '$Ort', '$PLZ', '$Geburt', '$Geschlecht')

Das Feld, das man mit der "Index"-Eigenschaft angibt, muss in der Datenbank auch ein indiziertes Feld sein, sonst geht das nicht. Wenn du die DB-Struktur nicht ändern kannst/darfst/willst, nimmt die Find-Methode statt Seek.

Kernqualifikation ist fachübergreifendes Grundwissen, sprich das müssen alle Informatiker (aus allen "vier neuen IT-Berufen") können.

Hallo Berni, schau dir mal auf Uli's Prüfungs-Page die FAQ an, dort sind alle wichtigen Dinge beschrieben.

Hallo Art! Nein, ein Tutorial kann ich dir dazu nicht nennen, ich kann dir nur ein paar wichtige Tipps auf die Schnelle geben... Grundsätzlich: Da PHP auf dem Server läuft und JavaScript auf dem Client, "wissen" die beiden prinzipiell nichts voneinander. Somit ist eine Übergabe von Variablen im klassischen Sinne nicht möglich, ebenso wenig wie das gegenseitige Aufrufen von Funktionen. In diesem Sinne technisch unmöglich. Von PHP nach JS: Ein PHP-Skript tut eigentlich nichts anderes, als ein HTML-Dokument zu generieren, dass der Webserver an den Browser schickt. Genauso kann dein PHP-Skript auch in HTML eingebettetes JavaScript generieren, quasi "an den Browser ausgeben". Von JS nach PHP: Da hast du nur die Möglichkeit, ein Formular abzuschicken oder eine URL aufzurufen. Für beide kann natürlich eine PHP-Skriptdatei adressiert werden (ACTION bzw. HREF). Hier läuft die Übermittlung wie üblich über Formularfelder bzw. URL-Parameter. Dabei empfehle ich dir einen Blick in die dclp-FAQ zu werfen, insbesondere die Kapitel 10 und 11. HTH

Hallo Gremix! Hier sind meine 0,02 € zu deinen Fragen... Würde ich nicht sagen, da hier Inhalt, Umfang und Ergebnis abweichen. Das "Projektziel" sehe ich eher als zielorientierte Themeneinleitung, so wie der Auftraggeber es formulieren würde, quasi eine Art "kleines Lastenheft". Im Soll-Konzept ("Soll-Analyse" halte ich für nicht ganz passend) wird ein fachlicher Entwurf des späteren Produkts generiert, das Ergebnis hiervon ist dann das Pflichtenheft. Das musst du schon selber wissen. Wegen des Projektumfangs und der Tatsache dass ich die Durchführung alleine vornehme, habe ich mich ebenfalls auf eine einfache Tabelle beschränkt. Insbesondere einen Netzplan halte ich bei einem "Ein-Mann-Projekt" für ziemlich unsinnig. Meilensteine übrigens auch, aber die habe ich trotzdem drin, weil's die Prüfer gerade schick finden. Ich würde sagen Analyse der Produktumgebung, Ableitung der dafür benötigten Schnittstellen, Entwurf der Module bzw. Klassen und Schnittstellen. Das Ergebnis kann man durch PAP/Struktogramm, ETs und/oder UML darstellen. Man sollte es vermeiden, auf einer Gliederungsebene nur ein Element zu haben, bei dir z.B. 1.4.1 Entweder kommt mindestens noch ein 1.4.2 dazu oder 1.4.1 wird auch weggelassen (natürlich nur als Gliederungspunkt, der Inhalt bleibt). Ausserdem sollte man darauf achten, dass die Menge der Untergliederung über alle Abschnitte hinweg gleichmäßig ist. Aber das ist nur eine Empfehlung, kein Muss.

Besser ist es allemal, vor allem weil die eigentliche Doku (ausschliesslich Deckblatt, Inhaltsverzeichnis und Anhang) durch deine IHK in der Seitenzahl beschränkt ist, In deinem PH hast du keine Ist-Analyse oder ein Soll-Konzept. Das PH ist das dokumentierte Ergebnis dieser beiden Teilphasen. Wie sieht denn die Gliederung deines PH aus?

Welchen Stil du für deine Quelltexte und welche Namenskonventionen du nutzt, ist eigentlich völlig schnurz, da gibt es IMHO seitens der IHKn keine Vorgaben. Wäre auch ziemlich sinnlos. Wichtig ist nur, dass du dich für einen Stil entscheidest und diesen konsequent einhältst (bei C/C++ z.B. der Indian Hill Style Guide). Ausserdem gehört natürlich eine sinnvolle Kommentierung in den Source, das betrifft auch die Schnittstellen, Variablen, Strukturen etc. Das sind aber keine Forderungen, die nur für die IHK gelten, das gehört zum sauberen Programmieren per se dazu. Also sollten das auch keine Nacharbeiten für die Doku sein, sondern von vornherein beachtet werden. BTW: Der kommentierte Quelltext ist zugleich die Entwicklerdokumentation, und bei einem Projekt mit Programmierteil gehört diese natürlich dazu.