Hallo,

soeben habe ich im Wiki einen neuen Artikel angefangen, der eine Liste häufiger Programmierfehler werden soll.

Einige von diesen Fehlern waren schon im FAQ-Bereich beschrieben. Diese habe ich verlinkt. Hoffentlich habe ich nicht zu viel geschrieben, was schon woanders vorhanden war.

Ich finde es praktischer, die Liste der häufigsten Fehler in einem Artikel gesammelt zu haben, als in den Unterkategorien der FAQ verstreut. Es hat zwei Vorteile:
1) Neulinge können es auf einmal lesen
2) Man findet es schneller, wenn man jemandem im Forum einen Link mit einer Beschreibung seines Fehlers schicken möchte.

PerlFallen

Die Idee gefällt mir sehr gut, aber ich fürchte bei diesem Vorgehen wirds schnell unwartbar.

Ich kenn mich mit Twiki nicht aus, aber Ideal wäre wenn wir lauter Detailartikel schreiben könnten, aus denen automatisch eine Zusammenfassung erstellt wird.

Also

[Titel]
[Stichwörter]
[Kurzfassung]
[Detailbeschreibung]


und im Übersichtsartikel werden nur Titel und Kurfassung (<2 Zeilen) angezeigt.

Man könnte übrigens auch anfangen besonders gute Boardpostings mitzuverlinken.

Hm, so etwas wäre in der Tat auch gut. Auf jeden Fall sollte die "Kurzfassung" keinen Klick entfernt sein. Denn im Gegensatz zur FAQ ist es ja bei den Fallen so, dass man eigentlich nicht weiß, in welcher Kategorie man die Fallen suchen muss, in die man eventuell tappen könnte, sondern eigentlich alle auf einmal sehen sollte.

Als Vorbild habe ich http://wooledge.org:8000/BashPitfalls genommen. Das finde ich eigentlich ziemlich praktisch, weil man da alles auf einen Blick sieht. Allerdings haben die Code in den Überschriften (und damit im Inhaltsverzeichnis), was schon teilweise recht schwierig ist, weil man dann das problematische Code-Stück in einer Zeile zusammenfassen muss, und Festbreitenschrift in Überschriften macht sich auch nicht so gut.

Und es gibt eigentlich auch nicht so viele Fallen wie FAQs, daher kann es sein, dass ein einziger Artikel trotzdem reicht.

LanX-+2008-08-16 19:44:27--

Man könnte übrigens auch anfangen besonders gute Boardpostings mitzuverlinken

Hast Du eines im Auge? :)

betterworld+2008-08-16 20:07:06--

Hm, so etwas wäre in der Tat auch gut. Auf jeden Fall sollte die "Kurzfassung" keinen Klick entfernt sein. Denn im Gegensatz zur FAQ ist es ja bei den Fallen so, dass man eigentlich nicht weiß, in welcher Kategorie man die Fallen suchen muss, in die man eventuell tappen könnte, sondern eigentlich alle auf einmal sehen sollte.

ja insbesondere weil IMHO bei Perl mehr als 26 Pittfalls zusammenkommen.

betterworld+2008-08-16 20:07:06--

Als Vorbild habe ich http://wooledge.org:8000/BashPitfalls genommen. Das finde ich eigentlich ziemlich praktisch, weil man da alles auf einen Blick sieht.

ja eben ne kondensierte Fassung sollte linear durchsuchbar sein, aber die Detailinfo muss auf je eine eigene Seite um wachsen zu können.

Danke für den Link ich bin damals von bash zu Perl gekommen, und jetzt weiß ich auch wieder warum ;-)

BTW: perltrap

betterworld+2008-08-16 20:07:06--

Und es gibt eigentlich auch nicht so viele Fallen wie FAQs, daher kann es sein, dass ein einziger Artikel trotzdem reicht.

ich weiß nicht ... komt drauf an was man unter einer Falle versteht, die übergänge sind fließend. Deswegen hätte auch auch gerne Stichwörter, die helfen die Sache auch mehrdimensional zu kategorisieren.

Theoretisch sollte Twiki sowas können, praktisch würde auch ein Cron-Job- mit nem Robot reichen der regelmässig alle einzelartikel parst und die Abstracts extrahiert.

betterworld+2008-08-16 20:07:06--

LanX-+2008-08-16 19:44:27--

Man könnte übrigens auch anfangen besonders gute Boardpostings mitzuverlinken

Hast Du eines im Auge? :)

nee (... außer meinen eigenen Genialitäten ;)... aber ich denke es ergibt sich zwangsläufig, wenn bestimmte Fragen sich häufen und die Trap-seiten verlinkt werden.

EIn guter EInstieg wäre auch aus dem Archiv alle Postings rauszusuchen die schon mal verlinkt wurden, so a la Googlerating ;-)


Ich denke es steckt ein riesiges ungehobenes Potential im Twiki allerdings scheiter ich daran mich da einzuarbeiten. Und momentan find ich das Community-Wiki leider unübersichtlich, die meisten Sachen finde ich weil ich in ner Googlesuche drüberstolper.

Hingegen im Forum gibts eher die Dialogische Situation wo aus dem "Streit" sehr viel Wissengewinn entsteht. Leider haben nun beide Tools verschiedene Interfaces...

man kann sowas mit dem twiki machen, das würde ungefähr so wie die FAQ funktionieren,
es geht auch ein bisschen simpler. ich kann mich da gerne mal dran versuchen. es müssten
am besten alle artikel mit einem bestimmten prefix anfangen und den abstract mit twiki-syntax
kenntlich machen.

@pq: soweit ich recherchieren konnte sollte man das mit Twiki Forms machen können und den Abstract dann in einer Textarea definieren können, oder?
Bei TwikiTemplates sind auch Beispiele wo die Namen neuer Seiten automatisch erweitert werden, z.B. Trap_...

@All: THEMA:Design
Findet ihr nicht auch dass das Twiki von Tiwki.org mit größerem Zeilenabstand deutlich lesbarer ist? Außerdem macht mal den Browser schmal und vergleicht mal die Seite TwikiTemplates von twiki.org mit der hiesigen. Dort gibts für den line-wrap keine Untergrenze und es wird ein Rand gelassen, bei uns muss man scrollen. Ich fänd eher ne Obergrenze der Zeilenlänge sinnvoll. Außerdem könnte man das Logo in der Kopfzeile auch 30-50% kleiner gestalten, und so den Platz für größeren Zeilenabstand zurückgewinnen. Nur mal so als Diskussions-Anregung...

LanX-+2008-08-16 22:52:37--

ja eben ne kondensierte Fassung sollte linear durchsuchbar sein, aber die Detailinfo muss auf je eine eigene Seite um wachsen zu können.

Ja. Es ist zurzeit sicherlich noch nicht optimal... wahrscheinlich sollte man jeden Abschnitt mit einem prägnanten Beispiel anfangen. Aber es ist ja ein Wiki, also würde ich mich über fruchtbares Teamwork freuen :)

Quote

Danke für den Link ich bin damals von bash zu Perl gekommen, und jetzt weiß ich auch wieder warum ;-)

Hehe.. Naja, die ganz schlimmen Pitfalls in Bash muss man halt einfach kennen, dann kann man sie auch umgehen (hauptsächlich die Sache mit den Quotes: find "$(locate "$foobar" | head -n1)" und so). Aber man kann in Perl natürlich viel mehr ausrichten als in Bash.

Quote

BTW: perltrap

Interessant.. ich glaube, ich hab das schon mal gesehen, ist aber schon lange her. Auf den ersten Blick sieht es ja so aus, als ob es nicht nur um Perl geht, aber dann merkt man, dass es für Umsteiger verschiedener Sprachen ist.

Allerdings würde ich jetzt nicht sagen, dass so viele Trivialitäten wie "Arrays index from 0. Likewise string positions in substr() and index()" in den Wiki-Artikel reinmüssen. Auf so etwas kommt man eigentlich sofort, weil der Code sonst nicht funktioniert. Ich war jetzt eher auf so Fehler aus, die man unbemerkt macht (Beispiele siehe Wiki).

Quote

EIn guter EInstieg wäre auch aus dem Archiv alle Postings rauszusuchen die schon mal verlinkt wurden, so a la Googlerating ;-)

Es gibt ja ThreadsImForum

Quote

Hingegen im Forum gibts eher die Dialogische Situation wo aus dem "Streit" sehr viel Wissengewinn entsteht.

Ja, didaktisch ist das schon angenehm, es zu diskutieren.

Ich finde es ja gut, dass es engagierte Neulinge wie Dich gibt, aber nach einiger Zeit wirst Du wohl auch merken, dass es langsam langweilig wird, immer wieder zu erklären, warum man mit $1 aufpassen muss etc. :)

pq+2008-08-16 23:05:08--

man kann sowas mit dem twiki machen, das würde ungefähr so wie die FAQ funktionieren,
es geht auch ein bisschen simpler. ich kann mich da gerne mal dran versuchen.

Ja, wär cool :)

[s]Sollten wir das dann so wie bei dem obigen Bash-Link machen, dass Code in den Überschriften steht?[/s] Ach nee, das würde dann wohl über den Abstract besser gehen.

betterworld+2008-08-17 17:03:57--

Quote

EIn guter EInstieg wäre auch aus dem Archiv alle Postings rauszusuchen die schon mal verlinkt wurden, so a la Googlerating ;-)

Es gibt ja ThreadsImForum

ja das wird (oder besser wurde) händisch gepflegt oder?

betterworld+2008-08-17 17:03:57--

Quote

Hingegen im Forum gibts eher die Dialogische Situation wo aus dem "Streit" sehr viel Wissengewinn entsteht.

Ja, didaktisch ist das schon angenehm, es zu diskutieren.

Ich finde es ja gut, dass es engagierte Neulinge wie Dich gibt, aber nach einiger Zeit wirst Du wohl auch merken, dass es langsam langweilig wird, immer wieder zu erklären, warum man mit $1 aufpassen muss etc. :)

Ne find ich nicht prickelnd, auch nicht als hiesiger "Neuling", ein schneller Link auf ein gutsortiertes Wiki wär mir oft lieber.

Was ich aber meinte ist dass die Dynamische Situation eines Forums mehr motiviert und Tiefe rauskitzelt als ein Wiki wo man kein Feedback bekommt.

Ich habe zumindest den Eindruck dass hier im Board mehr abgeht.

Aber statt uns in Projekte und Grundsatzdiskussionen zu versteigen, mal ein Brainstorming was IMHO in die Trapsammlung auch reingehört:

* Parameterübergabe udn Rückgabe von Hashes und Arrays erfordern oft Refs
z.B. proc( @a,@b )
* Listen vs Scalar Kontext
* Lexical vs Package-Variablen
* @a[0] ist ein Slice kein Arrayzugriff ->Perldoc-FAQ
* Parameter im Zweifel öfter Klammern:
z.B. print ( slice /;/ ) [1]; ergibt Syntaxfehler
* sub proc () {} erzwingt leeren Prototype

LanX-+2008-08-18 00:09:55--

Quote

Es gibt ja ThreadsImForum

ja das wird (oder besser wurde) händisch gepflegt oder?

Ja. Die Liste der Editor-Threads ist noch nicht so alt (habe es vor ein paar Monaten im Editor-Artikel angefangen aufzulisten und dann gestern in die Threadsammlung umgezogen, weil ich sie da erst entdeckt habe :)

Quote

Ne find ich nicht prickelnd, auch nicht als hiesiger "Neuling"

Ich meinte natürlich "Neuzugang" ;)

Quote

Was ich aber meinte ist dass die Dynamische Situation eines Forums mehr motiviert und Tiefe rauskitzelt als ein Wiki wo man kein Feedback bekommt.

Stimmt, man kann hier schneller Information zusammentragen, jedoch geht sie auch schnell wieder in den Tiefen verloren.

Quote

Aber statt uns in Projekte und Grundsatzdiskussionen zu versteigen, mal ein Brainstorming was IMHO in die Trapsammlung auch reingehört:

* Parameterübergabe udn Rückgabe von Hashes und Arrays erfordern oft Refs
z.B. proc( @a,@b )
* Listen vs Scalar Kontext
* Lexical vs Package-Variablen
* @a[0] ist ein Slice kein Arrayzugriff ->Perldoc-FAQ
* Parameter im Zweifel öfter Klammern:
z.B. print ( slice /;/ ) [1]; ergibt Syntaxfehler
* sub proc () {} erzwingt leeren Prototype

Package-Variablen sind ein guter Punkt. Das lässt sich wahrscheinlich auch gut damit verbinden, noch mal ausdrücklich auf strict hinzuweisen und auf den entsprechenden Artikel zu linken.

Oh ja, die Sache mit den Klammern nach print ist auch eine tiefe Falle.

Was meinst Du mit dem letzten Punkt? Ist das einfach für Leute gedacht, die aus anderen Sprachen gewohnt sind, überall "()" hinzuschreiben?

Was mir noch so vorschweben würde:
* Unportabilität von "\n"
* Aufpassen mit Benutzereingaben: SQL-Injections (->DbiPlatzhalter), CSS, system($var), etc.
* Allgemeine Warnung, dass man eigentlich so gut wie nie "sed", "grep" und Konsorten als externe Programme aufrufen muss, weil man so gut wie alles mit Perl (und CPAN) machen kann