[PHPhulp] Tutorials en Scripts, doorgaan of stoppen?
Door
Wouter J
op 25-10-2014 15:41
gewijzigd op 26-10-2014 11:36
5.013 views
Beste lid,
Het PHPhulp forum behoort tot een van de actiefste programmeer en PHP forums van Nederland. Dat komt onder anderen door de grote groep actieve leden die beginners helpen met hun grote kennis van de programmeerwereld. Hartelijk bedankt voor je inzet en tijd!
Het zal je echter ook wel opgevallen zijn dat deze site ook wat minder actieve plekken kent. We hebben het dan met name over de Scripts en Tutorials onderdelen. Als team vinden we dit jammer en hebben daarom het afgelopen jaar acties gestart om dit weer op gang te krijgen. Deze acties kregen helaas geen reactie en zijn allebei afgeblazen.
Daarom vragen we bij deze om jullie ideeën en meningen. Wat zorgt er voor dat deze onderdelen zo inactief zijn geworden? Is het bijvoorbeeld te ouderwets en horen tutorials en scripts nu meer thuis op site's als tuts+, laracast en knpuniversity? Of wil je best iets maken, maar weet je niet hoe het moet en wat er van je verwacht wordt?
Misschien besteed je wel al je vrije tijd aan het forum en heb je daardoor geen aandacht meer voor de andere onderdelen (sidenote: vele reacties op het forum zouden zo in de tutorials geplaatst kunnen worden).
Kortom: Vertel ons jouw ideeën over de tutorial en script onderdelen. De geopperde ideeën/functionaliteiten zullen in deze post worden bijgehouden, om het geheel overzichtelijk te houden.
Alvast bedankt.
Wouter J
Namens het PHPhulp team
[tab][size=small]Dit topic is gemaakt voor een goede en degelijke discussie. Het topic zal sterk door moderators in de gaten worden gehouden, zodat het niet ontspoort.[/size][/tab]
[hr]
[li]Reacties motiveren niet tot het maken van een nieuwe script (post)[/li]
[li]Het is niet duidelijk wat er verwacht wordt (post)[/li]
[li]Er zouden meer tuts voor beginners moeten komen (post)[/li]
[li]Scripts zijn verborgen (post)[/li]
[li]Het versturen van een script of tutorial is te ingewikkeld en werkt niet goed (post)[/li]
Ik mis ook de sites die jij opgenoemd hebt Elmar, ik heb programmeren geleerd via die websites :) In de php wereld is tegenwoordig zoveel mogelijk met bijvoorbeeld composer, maar voor zoiets moet je wel enige kennis van zaken hebben als programmeur. Ik heb het gevoel dat de meeste mensen hier op phphulp.nl mensen zijn die in hun vrije tijd wat lopen te kutten met php. Van de meeste vragen op het forum kun je ook zien dat ze gewoon een standaard script gedownload hebben en dan wat dingen proberen aan te passen zonder dat ze enig benul hebben waar ze mee bezig zijn... De vraag is dan wat voor scripts kun je maken wat handig is voor zulke mensen?
Ik heb mij bijvoorbeeld de laatste tijd wat verdiept in compilers en daarvoor een eigen template engine gemaakt. Heb ik super veel van geleerd en het werkt ook goed. Ik kan het hier wel posten, maar de vraag is wat heeft het voor nut? De mensen die verstand van zaken hebben zullen slim genoeg zijn om even te googlen en erachter te komen dat twig een stuk stabielere optie is. Voor wie post je het dan? Een template engine is niet echt iets wat iemand even in zijn website stopt, omdat je html en php makkelijk kunt mixen. Dan blijven mensen over die er wat van kunnen leren door middel van het lezen van mijn code. Maar ik heb niet echt het gevoel dat die groep hier aanwezig is.
Volgens mij zijn de beste scripts om hier te posten iets in de richting van een image uploader inclusief html, css en javascript. Oftewel iets wat mensen kunnen copy pasten in hun eigen in elkaar geflanste website zonder dat ze hoeven na te denken. Dat soort scripts maakte ik echter 8jaar geleden, nu heb ik daar geen zin meer in omdat ik weet dat er (betere) kant en klare scripts online te vinden zijn.
En nu blijkt dat je je files een voor een moet toevoegen voor een script; dat kan natuurlijk beter! Maar zou geen belemerring moeten zijn om scripts te posten :)
TL;DR: lees de dikgedrukte stukken; waar "tutorial" staat kun je dit ook in gedachten vervangen door "script".
NOLot heeft wel een punt, zij het misschien een beetje plastisch verwoord ;-). Het punt (zoals ik het zie) heeft te maken met: wat is je doelgroep. Als deze breed is (van beginner tot (en met) gevorderde) dan hoef je niet zo selectief te zijn met je inhoud, al vind ik niet dat als iemand iets vraagt op het forum dat je op voorhand een zogenaamd "te complex" antwoord zou moeten uitsluiten.
Dan is er inderdaad over de jaren ook de verschuivende tendens van "communities" (ik ben zelf (en weer) een telg van sitemasters, maar daar is het enorm rustig :)) naar google/stackoverflow. Als je de lijn doortrekt dan zou deze site op den duur ofwel een startpunt kunnen zijn/blijven voor beginners(vragen) en/of een naslagwerk voor "de basis". Een soort van "best practises" handleiding heeft wel wat, maar dan moet je dat wel een beetje lostrekken van hoe code op dat moment precies geschreven wordt (als dat mogelijk is) of dit over tijd een beetje bijhouden en aanpassen, maar ja, daar heb je dan ook echt mensen voor nodig die dat bijhouden.
Waar ik mij (op andere sites) altijd enorm aan erger is dat informatie niet voorzien is van een datum. Als je iets leest en denkt "Hee dat idee is wel geinig, oh wait, anno 2000" dan weet je ook niet zo goed wat je ermee moet en als een datum helemaal ontbreekt kun je meestal iets afleiden uit reacties ofzo, maar ja, het is fijn om te weten of datgene wat je gebruikt uit dit soort artikelen inmiddels niet compleet achterhaald is. Voor wat voor oplossing je ook kiest: zet er alsjeblieft een datum bij.
En over het niet willen schrijven van tutorials / artikelen vanwege mogelijke kritiek: het is de taak van moderators om dit soort discussies op de rails te houden. Iets wat wel funest is is dat meningen die niet "geaccepteerd" worden meteen verwijderd worden, dat is enkel een goede manier om alle discussie de nek om te draaien. Als je discussieert over dingen kun je iets leren (dit houdt dus ook in dat als iets ontkracht wordt je dit niet meer als argument kunt gebruiken en ook dat als iets aannemelijk wordt gemaakt je op den duur van mening kunt veranderen). Je leert op zijn minst (in) hoe(verre) iemand over iets nagedacht heeft. "Kritiek" zou echter nooit een reden moeten zijn om iets niet te doen. Daarnaast, "de juiste manier" bestaat niet, dus laat al die PHP zealots uit de verschillende kampen maar lullen. Het is veel belangrijker dat je je eigen oplossingen kunt onderbouwen in plaats van dat deze op voorhand afgeschreven worden omdat ze niet aan vorm X of standaard Y voldoen.
Nog een tegeltje: je moet argumenten niet tellen, maar wegen.
Het schrijven van tutorials is niet voor iedereen weggelegd. Je moet een zeker talent hebben om dingen op een zodanige manier uit te leggen zodat de stof eenvoudig te begrijpen is, zonder noodzakelijke details achterwege te laten (oftewel: zo simpel mogelijk, maar niet simpeler).
Ik zou het gewoon omdraaien: schrijf een tutorial als je iets uitgezocht hebt en dit wilt delen, en niet om iets te schrijven over iets wat je ooit uit zou willen zoeken. Dit laatste schept een zekere "verplichting" terwijl het eerste meer de vorm van een uittreksel / naslagwerk heeft. Het eerste garandeert ook een zeker persoonlijk "nut" ook naar de toekomst: je kunt je eigen onderwerp(en) nog eens nalezen. Schrijf een tutorial dus vooral voor jezelf.
Als je dan besluit om iets te schrijven realiseer je dan dat dit best veel tijd gaat kosten en zorg dat je shit werkt. Niets is zo irritant als niet-werkende voorbeelden. Vaak wordt er niet echt gedaan aan proofreading of het simpelweg testen of dingen ook echt doen wat je zegt dat ze doen. Voor iemand die iets probeert te leren is dan meestal de verwarring compleet.
Tutorials zijn zelden nooit in 1 iteratie klaar (<-- see what I did there :)). Daarom is het ook verstandig om ook je tijd te nemen en anderen concept-versies te laten lezen voor de uiteindelijke publicatie.
Ik zou de scripts/tutorials niet op voorhand weggooien (ook vanwege vindbaarheid/SEO) maar enige moderatie of een waarschuwing als iets echt verouderd is lijkt mij niet onverstandig :).
Veel bezoekers zijn Mensen die weinig ervaring hebben in programmeren. Wat zij leuk vinden is een script in elkaar te zetten aan de hand van een "IKEA handleiding" waarbij duidelijk staat aangegeven over welke tools zij moeten beschikken en wat het "instap-niveau" is. Daarna volgt een stap voor stap handleiding hoe je het script in elkaar moet zetten.
Na de reactie van Thomas gelezen te hebben denk ik dat er een lading werk in gaat zitten om een mooie set tutorials te schrijven. Wellicht is het daarom een idee om de koppeling LID-TUTORIAL los te laten en een werkgroep te ronselen die hiermee aan de gang gaat. Leden van de werkgroep kunnen elkaar dan aanvullen / corrigeren en het schrijfwerk kan verdeeld worden.
Ik mis ook de sites die jij opgenoemd hebt Elmar, ik heb programmeren geleerd via die websites :)
Leer je op websites programmeren of coderen? Meestal is het coderen. Leren programmeren is een heel ander verhaal. Leren programmeren doe je zonder programmeertaal, om maar iets te noemen: met bijvoorbeeld stroomdiagrammen, datamodellen en technieken voor gestructureerd programmeren. Dit kom je tegen op HBO opleidingen. In MBO opleidingen beperkt het zich veelal tot 6 weken coderen en dan ben je designer/developer. Een volkomen misplaatste benaming omdat niet elke designer ook developer (programmeur) is en omgekeerd. Daarnaast is het zo dat vrijwel iedereen meteen aan de knoppen wil en niet meer de moeite neemt om programmeer theorie te leren. Er komt steeds meer en meer trial-on-error programmatuur in zwang.
Ik zie veel waarde in de tips van Ozzie (26/10/2014 02:03:53), kleine stukjes effciente php code die goed uitgelegd worden en waar iemand dan iets van kan leren. Dat blijft dan wel bij coderen. Het strekt te veel te ver voor phphulp om ook nog eens te onderwijzen in gestructureerd programmeren.
>> Leren programmeren doe je zonder programmeertaal, om maar iets te noemen: met bijvoorbeeld stroomdiagrammen, datamodellen en technieken voor gestructureerd programmeren.
Programmeren moet je volgens mij leren door gedegen onderwijs en vooral door het te doen. (programmeren dan :p)
Een stroomdiagram is meer een tool om je programmaverloop te omschrijven.
>> Het strekt te veel te ver voor phphulp om ook nog eens te onderwijzen in gestructureerd programmeren.
inderdaad daarom leuke praktijk gerichte duidelijke tuts van een hoge kwaliteit. Die kleine stukjes horen daar bij maar mij inziens mogen in een hoger level best kleine stukjes samengevoegd worden maar dan wel met een verwijzing naar de kleine stukjes zodat de lezer weer omlaag kan qua niveau.
[size=xsmall]Toevoeging op 28/03/2015 15:42:43:[/size]
Om een voorbeeld te noemen:
Veel lezers zijn geïnteresseerd in een inlogsysteem. Een dergelijke tut mag er dan best komen maar een dergelijk systeem kent behoorlijk wat andere onderwerpen waar je al eens eerder mee bezig geweest moet zijn. Bijv:
- array's
- SQL
- password encryption
- forms
- sessions
- (vul maar in)
Alle bovenstaande in de lijst moet dus ene aparte tut voor zijn en naar terug verwezen worden in de inlogsysteem tutorial.
Een stroomdiagram is meer een tool om je programmaverloop te omschrijven.
Nee, je maakt eerst stroomdiagrammen voor je programma (is overigens wel old skool) en daarmee ga je coderen (wat jij noemt programmeren). Stroomdiagrammen zijn niet voor documentatie achteraf. In meer moderne omgevingen gebruik je UML voor je ontwerp.
