Tutorial - Ist ein Lerneffekt vorhanden?
-
Ich habe die Frage doch beantwortet: "Nö" bedeutet nein.
Bye, TGGC \-/
-
ah so, na dann reicht auch gut kommentierter Quelltext.
bye
tt
-
TheTester schrieb:
ah so, na dann reicht auch gut kommentierter Quelltext.
Warum nicht probieren? Wenns nix wird, wird man das schon früh genug erfahren. Und wenn es etwas wird: ist doch super.
-
ich glaub für ein programmier tutorial ist guter schreibstil wohl eher zweitrangig......solange er rüberbringt wie das ganze funktioniert
-
kommentar am rande:
ich vermisse in vielen tutorials das warum
es steht oft drin mach dies und mach jenes dann funktionierts aber es wir
selten vermittelt aus welchem grund man es gerade so macht
den grund findet man dann meist erst später wenn man ne weile damit arbeitetTotWGPG is ein gutes beispiel das viel vermittelt und wenig einfach nur vorschreibt
am besten is wohl ne ausgeglichene mischung aus fakten, praxis, hintergrundwissen und ne prise humor
hab neulich auch n kleines minnitut geschrieben
wie findet ihrs?
http://www.euro-games.net/files/ez/pdf/speicher_debuggen.pdf
-
tomf schrieb:
ich glaub für ein programmier tutorial ist guter schreibstil wohl eher zweitrangig......solange er rüberbringt wie das ganze funktioniert
Nein, das denke ich nicht. Viele Skripte zu IT-Themen von Hochschulprofessoren sind inhaltlich wirklich sehr sehr gut. Aber kaum lesbar. Staubtrocken, und es kommt keine Beziehung zwischen Autor und Leser zu Stande.
Ich bin der Meinung, daß gerade ein Lehrbuch beim Leser eine Stimmung aufkommen lassen muß wie "Ich lese nur noch dieses Kapitel, dann gehe ich ins Bett. Oh. Schon so spät?". Der Leser muß widerstrebend aufhören zu lesen, weil er was anderes tun muß.
D.h. es ist wichtig eine Abwechslung reinzubringen, und auch einen Spannungsbogen aufzubauen - d.h. eine gewisse Menge an ungelösten Problemen aufbauen und erst nach und nach auflösen. Der Leser kann sich daran dann selbst versuchen, oder weiterlesen.
Nix schlimmeres, als ein Buch das nach dem Schema 1.1.3.4 Die Initialisierung der DirectX(TM)-Schnittstelle 1.1.3.5 Erstmalig in den Grafikmodus schalten 1.1.3.6 Einfache Linien im Grafikmodus zeichnen vorgeht.
Meiner Meinung nach unterscheidet sich ein gutes Fachbuch gar nicht so stark von einem Roman - es muß einen Handlungsfaden geben, alles hängt zusammen, es gibt ein Happy End, es gibt beim Leser einen Spannungsbogen, er WILL weiterlesen, und zwischenzeitliche Erfolge ("ich wußte es, der Gärtner war's, die Sau").
Dieses Buch hier http://www.c-plusplus.net/titelanzeige.php?ISBN=3446194320 ist sicherlich ein Extrembeispiel dafür, was man aus einem Fachbuch alles machen kann.
Btw - ein Tutorial unterscheidet sich wohl in erster Linie vom Fachbuch nur durch die Form der Veröffentlichung.
-
Marcus du darfst auch dein Buch erwähnen, das ist auch sehr locker und persönlich
geschrieben und du sprichst oft einfach direkt aus was du denkst bzw. viele denken
aber es wird nie direkt erwähnt. Mir fällt zwar grad kein Beispiel mehr ein, aber
bei einigen der Fragen in deinem Buch dachte ich mir auch, ja genau warum und wenn
dann einem endlich mal wer die Antwort sagt wieso überhaupt so, dann ist man wirklich
froh
TGGC ich werde dein Tutorial auf jeden Fall lesen
-
ShadeOfMine
***********Warum nicht probieren? Wenns nix wird, wird man das schon früh genug
erfahren. Und wenn es etwas wird: ist doch super ok.allgemein
*********Ich bin auch immernoch der Meinung es hängt von der Zielgruppe ab die damit erreicht werden soll. Ich pers. bin zb. nicht so der Freund von kumpelhaften Büchern. Man kann ein Buch sicher auch so "angenehm" gestalten ohne überflüssige Witzchen usw.. Allein durch die präsentierten Inhalte, in ihrer Art der Aufbereitung usw. . Aber wie schon gesagt welche Zielgruppe? Studenten? Hobbycoder? Jugendliche im Bereich 14-16? Und da fängts dann an, was kann ich als Autor von denen erwarten, was könnten sie wissen, was sind sie sich bereit anzueignen, was können sie verstehen. Wenn ich ein Tutorial für zb. Java verfasse und dort mit allem Objektorientiertem Schnickschnack und diversen Design und Coding Modellen arbeite. Kann ich erwarten das der Leser das kennt? Wie siehts mit der Vorbildung aus etc.
bye
tt
-
@TheTester: Sicher hast du recht, dass man die Zielgruppe abgrenzen sollte. (Bei meinen Tutorien versuche ich das meist durch einen Prolog in dem ich das was in dem Tutorial zu erwarten ist skizziere zu erschlagen). Was allerdings den Stil anbelangt, so denke ich, dass "locker flockig geschrieben" nicht bedeutet, dass man aus dem Buch eine Witzfiebel macht. "locker flockig" fängt schon bei etwas ganz trivialem wie der Anrede an. (Schreibe ich "du" oder "sie"?) bzw. den Sichtpunkt: (Sie, Du oder Wir?).
Ich für meinen Teil z.B. bevorzuge das "wir". Es vermittelt einem weniger das Gefühl, von einem Lehrer angesprochen zu werden als viel mehr das Gefühl eines "Gemeinsam mit dem Autor erarbeitens". (Ich habe das zwar bei meinen auch immer zu Ziel allerdings krieg ich nie feedback ob ich das auch hingekriegt habe (o: Nichtsdestotrotz hab ich schon einige (Fach-)Bücher gelesen in unterschiedlichsten Stilen und obige Aussage ist eher eine Erkenntnis aus der "Selbstbeobachtung")
Ich denke auch, wenn man den Vorsatz "gemeinsam mit dem Lesenden Erarbeiten" zum Ziel nimmt, dass dann die Problematik, dass nicht erklärt wird "wieso" abnimmt.Ich finde Marc++us hat absolut recht. Ein gutes Fachbuch unterscheidet sich nur minimal von einem Roman. Man muss irgendwo einen guten Mix finden finden aus "romartigem" Schreibstil und Sachlichkeit.
-junix
-
Das hat nichts mit kumpelhaft zu tun. Die Distanz muß natürlich immer erhalten bleiben.
Ich habe
- "gestandene" Ingenieure >40 in Regelungstechnik unterrichtet
- Studenten in Meß- und Regelungstechnik
- Schüler und Hobbyisten in C und C++und bin dabei immer nach der gleichen Linie vorgegangen, obwohl die Themen unterschiedlich waren und die Altersgruppe der Zuhörer ebenfalls.
Generell kommt ein trockener Spruch immer gut an. Er lockert auf, entkrampft die Situation, sowas kann man bei jedem Zuhörerkreis immer bringen. Das geht selbst bei einer Kundenpräsentation.
Es ist ein Verhängnis deutscher Fachbuchautoren zu glauben, daß mit dem Schwierigkeitsgrad des Themas auch der Schreibstil trocken werden muß.
Das findet man oft... Einführung in C ist leicht und locker geschrieben, aber ein Buch über Software-Engineering kaum noch lesbar wg. des "wissenschaftlichen Schreibstils". Das muß nicht sein. Trotzdem das Thema anspruchsvoller wird, ist es doch so, daß sich die Leser selbst nicht wirklich ändern. Wenn jemand als 20jähriger über ein Beispiel in einem Einsteigerbuch zu C++ geschmunzelt hat, wieso soll der als 35jähriger Projektleiter bei einem Buch über Risikomanagement von Softwareprojekten nicht mehr schmunzeln?
US-Autoren bewältigen meiner Meinung nach dies übrigens besser, aus meiner Sicht auch ein Grund warum viele übersetzte Titel besser laufen als Originalwerke aus Deutschland zum gleichen Thema.
Schöne Beispiele z.B.
Der Klassiker http://www.c-plusplus.net/titelanzeige.php?ISBN=3826613554 - gut geschrieben, mit einem Augenzwinkern
Oder http://www.c-plusplus.net/titelanzeige.php?ISBN=3826613260Staubtrockene Themen, und doch amüsant lesbar. Kumpelhaft ist da nichts.
-
Ebenfalls ein gutes Beispiel finde ich dieses hier:
The Art of Designing Embedded Systems | ISBN: 0750698691
"The Art of Designing Embedded Systems" von Jack Ganssle
-junix
-
also, ich kann von einer sehr positiven tutorial erfahrung sprechen,das war als ich php lernen wollte, tut.php-q.net, ist wohl vielen hier ein begriff.
Für mich hatte es eine Ideale mischung aus theorie und quellcode,das war sehr schön, und heute kann ich fast alles was php zu bieten hat-oder habs schonmal gemacht(und danach wieder vergessen :D).@TGGC wenn du ein Sprachen unabhängiges tutorial anstrebst, musst du den leuten beibringen, algorithmen zu verstehen,und ihnen beibringen, selber auf einem blatt papier einen algorithmus mit all seinen Verfeinerungen zu basteln.
Wenn du das geschafft hast,musst du im tutorial selber "nurnoch" auf die sprach basierten tücken aufmerksam machen("in c++ musst du dafür pointer benutzen") dann hast du einen sehr hohen lernerfolg, und kannst die leute dazu bringen, sich ein einfaches programmierproblem selbst zu erarbeiten.
ps: jaja, ich sollte mich selber öfter mal daran halten, was ich schreibe, aber bei mir liegt das problem eher in der sprache selber, nich am algorithmus, und da hilft eh nur üben üben üben, und jeden tag eine neue größere aufgabe...
-
Ich werde das dann wohl mehr wie ein besseres Entwicklertagebuch gestalten. Dann erhebe ich keine Anspruch darauf, das irgendwer kapiert oder ich etwas beibringen müsste.
Bye, TGGC \-/
-
oh, die Herausforderung zu hoch? (o;
-
Die Zielsetzung wurde präzisiert.
Bye, TGGC (Zu viele Primitive hier.)
-
So, dann meckert mal los: http://www.fh-merseburg.de/~roesch/tggcg
Jetzt kann man ja zur Not noch was ändern.
Bye, TGGC \-/
-
Seite 4 und 5 sind das gleiche und auf Seite 5 führt Zurückpfeil auf Seite 3.
Edit: Scheinbar gibt es erst 4 Seiten...
Naja, das hier hat mir echt ne Weile Angst gemacht("Hilfe, da bewegt sich was!").
-
Ein neues Bild wird hier erst, wenn der Monitor auch wieder anfängt ein neues Bild zu zeigen.
-
BTW: Da dieser Thread über Tutorials gerade im Spiele-/Grafikprogrammierung-Forum steht, könnt ihr auch gleich mal über mein Tutorial über Bilder und Java meckern. Es ist schon etwas älter und inzwischen bin ich damit selbst nicht mehr so zufrieden. Mich interessiert aber, was ihr an dem Text schlecht findet.
http://www.javacore.de/tutorials/michalicek/Bilder_und_Java.pdf
-
@Saugie:
Es gibt erst 4 Kapitel, wie kommst du auf 5? Wieso Angst? Es ist ein im Web übliches, animiertes *.gif.@Nukem:
Mhh, da fehlt wohl ein Wort!Bye, TGGC \-/
