man muss nicht mal feste ergebnisse liefern einfach durch eval jagen und prüfen ob ergebnis stimmt

[quote=Ronnie,10.07.2005, 18:44]Worauf ich in diesem Kontext mal hinweisen möchte ist der interaktive Lisp-Kurs der hier zu finden ist: http://www.psychologie.uni-trier.de/projects/ELM/elmart.html

Dürfte nur sehr schwer in Perl machbar sein, bzw. man bräuchte einen eigenen Parser, der übergebenen Code auf seine Sicherheit hin testet.

Das tolle daran ist, man meldet sich an und arbeitet Lektion für Lektion interaktiv durch. Bricht man irgendwo ab, fängt man das nächste mal an der selben Stelle wieder an.[/quote]
Ich habe mir den interaktiven LISP-Lernkurs mal angesehen. Das ist meines Erachtens viel zu aufwändig. Es geht mir nicht darum, die Lerninhalte noch einmal zu wiederholen. Es gibt genug gute Anleitungen. Es sollten lediglich die Tests erstellt und abgefragt werden.

Beispiel: Anstelle zu erklären, warum man "use strict;" verwenden soll, heisst die Aufgabe: "'use strict;' nutzt man, weil ..." und gibt als Antworten 3 richtige und 2 falsche Optionen. Nach dieser Machart gehören 10 Aufgaben zu einer Übungseinheit. Zu jeder Frage kann es dann Links zu weiterführenden Informationen geben.

Es geht mir um messbare Lernergebnisse. Nicht um ein weiteres Tutorial unter vielen.

Ich halte es für viel zu komplex, wirklichen Code eingeben zu lassen. Eher sollte aus 3 Code-Teilen der funktionierende herausgefunden werden.

[quote=kabel,10.07.2005, 19:20]mich interessiert hier eher KUMON.

tja, da hilft nur eine auswahl treffen und sich die tuts der entwickler angucke ne. und dann lektionen daraus konstruieren.
[/quote]
Zu Kumon kann ich ein paar Kontakte vermitteln, wenn das jemanden wirklich interessiert.

Korrekt ist: Es müssen Prüfbögen anhand bestehender Tutorien entwickelt werden. Darin steckt, wenn das richtig gemacht werden soll und laufend aktualisiert wird, unheimlich viel Arbeit.
Ich habe kein Problem, mich an einem Teil zu beteiligen. Aber das ist eine Aufgabe, die mehr als einer angehen muss. Sonst bleibt es Stückwerk.

Im übrigen könnte ich mir durchaus vorstellen, dass die Perl Foundation oder eine deutsche Vereinigung für die Ausstellung von Zertifikaten Geld von Firmen nimmt. Von Nutzern könnten andere (persönliche) Gegenleistungen eingefordert werden.

Das erinnert mich stark an die Multiple-Choice Prüfungen der IHKs, die davon aber auch immer mehr abkommen (jedenfalls bei komplexeren Ausbildungen), weil offene Prüfungsfragen deutlich besser über den Ausbildungsstand Auskunft geben, als statisches "Prüfungswissen". Dazu kommt das gerade Perl viel syntaktische Spielereien erlaubt und es immer mehrere Wege gibt eine Aufgabenstellung zu lösen.

Was die Strukturierung solcher Prüfungsaufgaben betrifft, würde ich mich an Merlyns "Einführung in Perl" orientieren, das AFAIR auch Übungsaufgaben enthält. Wenn man spezieller in Richtung CGI geht, sollte man wohl mit klassischem CGI (CGI.pm) beginnen (XHTML und CSS berücksichtigen - man sieht immer noch zuviel HTML 3/4), Validierung von übergebenen Formulardaten, Encoding, Persistenz (Datenbank-Verbindung, Sessions, Cookies), Templating (HTML::Template, Template-Toolkit), mod_perl und zuguterletzt Application-Frameworks wie Catalyst von sri.

[quote=Ronnie,10.07.2005, 22:04]Das erinnert mich stark an die Multiple-Choice Prüfungen der IHKs, die davon aber auch immer mehr abkommen (jedenfalls bei komplexeren Ausbildungen), weil offene Prüfungsfragen deutlich besser über den Ausbildungsstand Auskunft geben, als statisches "Prüfungswissen". Dazu kommt das gerade Perl viel syntaktische Spielereien erlaubt und es immer mehrere Wege gibt eine Aufgabenstellung zu lösen.

Was die Strukturierung solcher Prüfungsaufgaben betrifft, würde ich mich an Merlyns "Einführung in Perl" orientieren, das AFAIR auch Übungsaufgaben enthält. Wenn man spezieller in Richtung CGI geht, sollte man wohl mit klassischem CGI (CGI.pm) beginnen (XHTML und CSS berücksichtigen - man sieht immer noch zuviel HTML 3/4), Validierung von übergebenen Formulardaten, Encoding, Persistenz (Datenbank-Verbindung, Sessions, Cookies), Templating (HTML::Template, Template-Toolkit), mod_perl und zuguterletzt Application-Frameworks wie Catalyst von sri.[/quote]
Ronnie: Richtig. Mir schwebt die "Billiglösung", die Dich an die IHK erinnert vor. Das mag nicht innovativ erscheinen, ist es aber, wenn es sinnvoll angewendet wird. Bei der IHK funktioniert es nicht, weil es allein aus Arbeitsspar-Motiven angewendet wird.

Wenn die Aufgaben durchdacht und gut aufbereitet sind, macht das viel Sinn. Du kannst keine offenen Fragen stellen, weil Du dann einen brauchst, der prüft. Der kostet Geld. Und das wird keiner, der gerade Perl lernt bezahlen wollen. Also eine Totgeburt. Eine (endlose) Reihe von Multiple-Choice-Tests ist jedoch ein Einmalaufwand und braucht nur in verschiedene Sprachen übersetzt zu werden. Das ist skalierbar und von der Perl-Gemeinde zu schaffen.

Richtige Tests müssen Firmen machen.

Die Quellen die Du genannt hast, finde ich gut. So würde ich mir das auch vorstellen.

Hm, und was ist wenn man das ganze so ein bischen an das Überprüfen von Algorithmen anlehnt?
Mir schwebt da sowas vor:
Man hat eine Eingabe bei der eine gewisse Ausgabe heraus kommt.
Die Eingabe wäre dabei die Aufgabenstellung und die Ausgabe das richtige Ergebnis, bzw. die richtige Ausgabe.
So wäre der Freiraum der multiplen Lösungswege gegeben.
Mit dem passenden Parser wäre zumindest schonmal im CGI-Bereich einiges an lösungen abgedeckt. Schwieriger wird es eher bei grafischen Anwendungen.

[quote=pktm,10.07.2005, 23:07]Hm, und was ist wenn man das ganze so ein bischen an das Überprüfen von Algorithmen anlehnt?
Mir schwebt da sowas vor:
Man hat eine Eingabe bei der eine gewisse Ausgabe heraus kommt.
Die Eingabe wäre dabei die Aufgabenstellung und die Ausgabe das richtige Ergebnis, bzw. die richtige Ausgabe.
So wäre der Freiraum der multiplen Lösungswege gegeben.
Mit dem passenden Parser wäre zumindest schonmal im CGI-Bereich einiges an lösungen abgedeckt. Schwieriger wird es eher bei grafischen Anwendungen.[/quote]
Das von Dir beschriebene Prüfverfahren klingt so ähnlich wie "Tests". Das gefällt mir gut. Allerdings muss sowas unabhängig von bestimmten Methoden und vor allem Moduln sein. Wenn beispielsweise in einem bestimmten Unternehmen bestimmte (vielleicht auch proprietäre Module wie in Deinem Fall ein Template-Parser) zum Einsatz kommen, taugt das Tutorial nichts. Am besten wäre wirklich eine von Modulen und Methoden unabhängige Aufgabe, die jeder lösen kann.

Die Richtung klingt sehr gut. Aber ist das nicht auch "superaufwändig"? Bei Multiple-Choice ist man jedenfalls auf einer einfach zu standardisierenden Ebene. :-)

Auf meine Bewerbung hab ich zwar nie eine Antwort erhalten, aber ich geb trotzdem mal ein paar tips. :)

* Keine multiple choice tests!!! Jeder mensch lernt anders, fuer mich persoehnlich hat sich "learning by doing" als beste Methode erwiesen.

* Ich hatte neulich die chance das technische review fuer Learning Perl 4th Edition zu machen, so weiss ich das es dazu einen tollen Frage/Antwort teil von brian d foy geben wird. ;)

* Alpha geek!!! Es lohnt sich wenigstens einen hochkaraetigen Programmierer zu engagieren, andere werden dadurch meist motiviert sich selbst weiterzuentwickeln. Ausserdem kann er schnelle und qualifizierte Antworten fuer die meisten Fragen liefern.

* Buecher! Neben Standardwerken wie dem Kamelbuch sollten auch Sachen wie Advanced Perl (Panther), Higher Order Perl und Perl Best Practices vorhanden sein.

* Kommunikation! Programmierer verfuegen meist nur ueber eingeschraenkte soziale kompetenz, deshalb lohnt es sich z.b. einen irc channel zu eroeffnen. (Fuer nicht geeks schwer zu verstehen, lohnt sich aber!) Ausserdem ist die Kommunikation und Entwicklung damit nicht mehr Standort gebunden.

* Frameworks! Gerade bei web entwicklung vereinfachen frameworks wie Catalyst die arbeit ungemein. Im irc channel hoere ich taeglich Saetze wie "catalyst rockz! i just rewrote an app with cat on a single evening which took me two months before!". :) Foerdert unter anderem auch saubere abstraktion und die nutzung von "best practices". Hier is mein Artikel mit nem netten Beispiel. :)

* Pair programming! Kleine (2 Programmierer) teams bilden (oder vom Alpha geek bilden lassen), das erhoeht die motivation und macht einfach mehr spass.

* Shared Version Management! Bei Google z.b. hat es sich bewehrt ein einziges grosses Quelltext repository zu betreiben. So sind beitraege zu projekten nicht an teams gebunden, jeder im gesamten unternehmen kann ideen beisteuern und vom code der anderen lernen. (eventuell dann auch ganz einfach das team wechseln)

* Open Source Projekte! Durch ermutigung an open source projekten mitzuarbeiten (Module ins CPAN stellen oder patche schicken...etc.) laesst sich die Motivation (und vorallem das know-how) ungemein erhoehen! Google erlaubt seinen mitarbeitern 20% ihrer Arbeitszeit fuer private projekte zu nutzen! (IMO sehr clever)

* Community! Die gruendung bzw. teilnahme an einem Perl Monger Stammtisch macht viel spass und sorgt fuer neue Eindruecke. Hier wird ueber neue Module diskutiert, Programme von Damian und Abigail erklaert und natuerlich Bier getrunken. :)

[quote=kalyxo,10.07.2005, 23:48][quote=pktm,10.07.2005, 23:07]Hm, und was ist wenn man das ganze so ein bischen an das Überprüfen von Algorithmen anlehnt?
Mir schwebt da sowas vor:
Man hat eine Eingabe bei der eine gewisse Ausgabe heraus kommt.
Die Eingabe wäre dabei die Aufgabenstellung und die Ausgabe das richtige Ergebnis, bzw. die richtige Ausgabe.
So wäre der Freiraum der multiplen Lösungswege gegeben.
Mit dem passenden Parser wäre zumindest schonmal im CGI-Bereich einiges an lösungen abgedeckt. Schwieriger wird es eher bei grafischen Anwendungen.[/quote]
Das von Dir beschriebene Prüfverfahren klingt so ähnlich wie "Tests". Das gefällt mir gut. Allerdings muss sowas unabhängig von bestimmten Methoden und vor allem Moduln sein. Wenn beispielsweise in einem bestimmten Unternehmen bestimmte (vielleicht auch proprietäre Module wie in Deinem Fall ein Template-Parser) zum Einsatz kommen, taugt das Tutorial nichts. Am besten wäre wirklich eine von Modulen und Methoden unabhängige Aufgabe, die jeder lösen kann.

Die Richtung klingt sehr gut. Aber ist das nicht auch "superaufwändig"? Bei Multiple-Choice ist man jedenfalls auf einer einfach zu standardisierenden Ebene. :-)[/quote]
Den Parser wollte ich auch nur zum checken der Ausgabe verwenden, die ja im CGI-Bereich wohl (X)HTML sein wird.
Dann ist es auch weniger aufwendig.
Nehmen wir mal das Gästebuch. Aufgabenstellung ist ein Gästebuch mit der Eintrags- und Ansichtsfunktion zu bauen.
Das ergebnis werden entweder 2 Scripten mit unterschiedlichen Ausgaben sein (das eine das Eingabeformular und das andere die Gästebucheinträge) oder 1 Script mit 2 Runmodes. Was genau geprüft werden kann muss halt noch in der Aufgabenstellung beschrieben werden.
Wenn man jetzt einen netten Parser mit passender Grammatik über die Ausgabewebdeiten laufen lässt müsste sich eine mit einer anderen vergleichbare Datenstruktur bilden.
Arbeits macht es natürlich mehr als ein Multiple-Choice-Test (denke ich), aber es ist eine alternative und vor allem auch praktische Art etwas zu lernen (wo wir ja dann allerdings auch wieder beim Thema lerarning by doing wären).
Grüße, pktm

[quote=pktm,11.07.2005, 01:42][quote=kalyxo,10.07.2005, 23:48][quote=pktm,10.07.2005, 23:07]Hm, und was ist wenn man das ganze so ein bischen an das Überprüfen von Algorithmen anlehnt?
Mir schwebt da sowas vor:
Man hat eine Eingabe bei der eine gewisse Ausgabe heraus kommt.
Die Eingabe wäre dabei die Aufgabenstellung und die Ausgabe das richtige Ergebnis, bzw. die richtige Ausgabe.
So wäre der Freiraum der multiplen Lösungswege gegeben.
Mit dem passenden Parser wäre zumindest schonmal im CGI-Bereich einiges an lösungen abgedeckt. Schwieriger wird es eher bei grafischen Anwendungen.[/quote]
Das von Dir beschriebene Prüfverfahren klingt so ähnlich wie "Tests". Das gefällt mir gut. Allerdings muss sowas unabhängig von bestimmten Methoden und vor allem Moduln sein. Wenn beispielsweise in einem bestimmten Unternehmen bestimmte (vielleicht auch proprietäre Module wie in Deinem Fall ein Template-Parser) zum Einsatz kommen, taugt das Tutorial nichts. Am besten wäre wirklich eine von Modulen und Methoden unabhängige Aufgabe, die jeder lösen kann.

Die Richtung klingt sehr gut. Aber ist das nicht auch "superaufwändig"? Bei Multiple-Choice ist man jedenfalls auf einer einfach zu standardisierenden Ebene. :-)[/quote]
Den Parser wollte ich auch nur zum checken der Ausgabe verwenden, die ja im CGI-Bereich wohl (X)HTML sein wird.
Dann ist es auch weniger aufwendig.
Nehmen wir mal das Gästebuch. Aufgabenstellung ist ein Gästebuch mit der Eintrags- und Ansichtsfunktion zu bauen.
Das ergebnis werden entweder 2 Scripten mit unterschiedlichen Ausgaben sein (das eine das Eingabeformular und das andere die Gästebucheinträge) oder 1 Script mit 2 Runmodes. Was genau geprüft werden kann muss halt noch in der Aufgabenstellung beschrieben werden.
Wenn man jetzt einen netten Parser mit passender Grammatik über die Ausgabewebdeiten laufen lässt müsste sich eine mit einer anderen vergleichbare Datenstruktur bilden.
Arbeits macht es natürlich mehr als ein Multiple-Choice-Test (denke ich), aber es ist eine alternative und vor allem auch praktische Art etwas zu lernen (wo wir ja dann allerdings auch wieder beim Thema lerarning by doing wären).
Grüße, pktm[/quote]
Mal im ernst, ich wuerde nicht CGI pruefen, sondern begruenden lassen warum CGI eine schlechte Wahl ist und welche alternativen besser waeren! :)

Ausserdem ist die Anwendung an sich am geringsten zu bewerten, dafuer aber sollte besonders auf unit tests und pod coverage geachtet werden!

Wir wissen alle das Perl dem Programmierer viele freiheiten laesst, also sollte ein test oder sogar eine zertifizierung, hohen wert darauf legen zu beweisen das der Programmierer damit auch umzugehen weiss!\n\n

<!--EDIT|sri|1121039505-->