[PHPhulp] Tutorials en Scripts, doorgaan of stoppen?
Misschien meer een wiki met een git-systeem voor pull requests?
Misschien ook een extra optie om gelijk te kunnen zien wat de code doet de server het verwerkt ?
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 :)
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
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 :).
Gewijzigd op 27/03/2015 20:32:52 door Thomas van den Heuvel
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.
NOLot - op 27/03/2015 19:06:18:
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.
Gewijzigd op 28/03/2015 15:26:30 door John D
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.
Toevoeging op 28/03/2015 15:42:43:
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.
Frank Nietbelangrijk op 28/03/2015 15:37:22:
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.Een stroomdiagram is meer een tool om je programmaverloop te omschrijven.
Gewijzigd op 28/03/2015 15:56:08 door John D
even gegoogled en gevonden op: www.nldit.com
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
De handeling van het schrijven van de broncode heet codering .
Het kan ook het programmeren worden genoemd, omdat het deel uitmaakt van de computer programmeren .
Echter , het proces voor het creren van software is meer dan het schrijven van de code ; " .
Debugging ' het omvat ook het uitvoeren van de compiler en het herstellen van fouten ,
een proces dat bekend staat als bij gebruik als specifieke termen in plaats van in algemene zin ,
codering kan verwijzen naar het specifieke proces van typen in de code ,
terwijl de programmering kan verwijzen naar elke fase van het proces ,
met inbegrip van het samenstellen en debuggen .
Het kan ook het programmeren worden genoemd, omdat het deel uitmaakt van de computer programmeren .
Echter , het proces voor het creren van software is meer dan het schrijven van de code ; " .
Debugging ' het omvat ook het uitvoeren van de compiler en het herstellen van fouten ,
een proces dat bekend staat als bij gebruik als specifieke termen in plaats van in algemene zin ,
codering kan verwijzen naar het specifieke proces van typen in de code ,
terwijl de programmering kan verwijzen naar elke fase van het proces ,
met inbegrip van het samenstellen en debuggen .
programmeren is dus een breder begrip dan coderen. Stroomdiagrammen maak je niet achteraf nee.
Gewijzigd op 28/03/2015 16:20:13 door Frank Nietbelangrijk
John D op 28/03/2015 15:21:16:
Leer je op websites programmeren of coderen? Meestal is het coderen. Leren programmeren is een heel ander verhaal.
NOLot - op 27/03/2015 19:06:18:
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.
Huilen :)
Niemand wil denk ik op 2 plekken hun code uploaden/aanpassen.
En minder kritiek opbrengen maar wel feedback geven om bijvoorbeeld het niveau van de code hoger te brengen.
Ook moeten de developers dan wel wat kennis van PHP hebben en niet alleen procedurele code neerzetten als repo.
Woef Woef.
Gewijzigd op 29/03/2015 16:08:27 door Paco de Wulp