2 dingen worden beetje gemist:

- Edit knop voor je berichtje
- en als iemand geen onderwerp invult, dan valt er niks te klikken (zie carpool sectie) misschien een idee om dat een "verplicht" veld te laten wezen?

Edwin, ik moet Ravenger toch echt gelijk geven... als je een simpel iets maakt, wat alleen jij onderhoud, dan kun je doen zoals jij. Maar als het door veel mensen gebruikt word, en een groep mensen support daarop moeten geven, plus dat het financieel ook impact heeft als het eea niet werkt? dan wil je toch dat als jij op vakantie bent, dat een van de anderen het dan gewoon van je over kan nemen om de wijziging voor een functionaliteit door te voeren.

Dan krijg je een functionaliteitomschrijving, ontwerp, form design, div diagrammen/flowcharts voor de werking, welke alle in de remarks vermelden welk stuk source het is, of in de source welk diagram/flowchart het is. Plus dan nog koppelingen naar de ?manager? zodat er een vorm van bewaking over is. Heb al genoeg moeten ?ontwikkelen? om dat soort ?abstracte? onzin erg te waarderen. Zeker als je de flowcharts tot 4 of 5 lagen diep moet uitbouwen. Dan is met jouw methode het project gewoon niet te managen omdat je op gegeven moment niet meer weet waar je mee bezig bent, en wat er nog gedaan moet worden. Ook worden dan een hoop dingen ?vergeten? omdat je niet een overzicht hebt van wat er allemaal gedaan moet worden, waarop je de dingen kan afstrepen.

chemas-microsoft-comfficeffice" />> >

De discussie mbt welke ?taal? beter is, is er een van welke functionaliteiten heb je nodig, en welke taal ?past? daar het beste bij aan ondersteuning. Sommige dingen zijn gewoon niet mogelijk met de ene taal, en met de andere wel, of andersom. Van te voren uitzoeken wat waarmee het makkelijkste/beste gedaan kan worden is dan nog niet eens zo?n gek idee. De taal die de gevraagde functionaliteit kan leveren met vrij standaard ?termen? is dan vaak de beste, naast dat er gekeken moet worden waarop je gaat bouwen. Bv C++ applicatie vs een Flash-website. Het hangt er volledig vanaf wat de behoefte precies is.

> >

En dan nog ?terminologie? zoals die ?abstracte zooi?: je kan moeilijk in je communicatie de daadwerkelijke code gebruiken als verduidelijking, je kan beter de abstracte delen refereren in de vorm van dat dit en dat deel klaar is van deze of gene flowchart. Dan weet iedereen waar je het over hebt, en hoeven ze niet zelf de taal te bestuderen en daarna je code lezen om erachter te komen wat je nou eigenlijk ?af? hebt, want tegen die tijd hadden ze het net zo goed zelf kunnen doen.

> >

?Ontwikkelen? vs ?Schrijven?: een applicatie ontwikkel je (is meer een proces van verfijnen van functionaliteit etc) en code schrijf je als eigenlijk de applicatie al ontwikkeld is (in meest ideale geval, maar meestal moeten er nog flink wat wijzigingen worden doorgevoerd voordat de programmeur/schrijver klaar is met het coden van de source).

bweugh EDIT KNOP!!!!!!!! of een PREVIEW!!!

hmmz, jij begrijpt nog steeds niet waarom dus die "abstracte" zooi er is...

In 99,99999% van alle gevallen begrijpt de manager NIET wat jij aan 't schrijven bent, en zoals ik al zei, als hij het WEL begrijpt, en hij moet jouw code doorlezen 1x in de week om te weten waar jij mee bezig bent, en wat je al klaar hebt, dan had hij het net zo goed ZELF kunnen schrijven. Die abstracte zooi daar kun je mee aangeven in welk onderdeel je wat af hebt of in bezig bent, zonder dat iemand ooit in jouw source hoeft te snuffelen en daar kostbare tijd mee kwijt is. Op moment dat jij overreden word door een auto, dan kan hij iemand inhuren, 'm de diagrammen/flowchart's en de functionaliteitsbeschrijving laten zien, en diegene kan rechtstreeks naar het onderdeel waaraan door jou de dag ervoor nog gewerkt werd.

Uit je reacties kan ik afleiden dat je als een Remi aan 't ontwikkelen bent, en dat je met niemand rekening hoeft te houden buiten jou om. Maar als je met 20 man 1 app aan 't maken bent, en iedereen doet een ander ding, en de manager moet dat in goede banen leiden, dan is het handig om afspraken te hebben van welke datatypes worden gebruikt tussen de verschillende delen bv. Of afgesproken te hebben wat voor soort images worden aangeleverd door de grafische man, de tekst word aangeleverd in asscii format, numerieke data in binair format etc. Achter de ontwikkeling van een website zit lang niet altijd maar 1 Remi te werken hoor, daar zitten soms 20 Remi's  te praten met een Manager die nergens verstand van heeft, behalve van de abstracte dingen. Als je dan met 5 man in dezelfde taal bezig bent, en de manager geeft je op om flowchart die en die te gaan coden met dat en dat als "input" en dat en dat moet de output zijn naar die en die functie, wat allemaal te vinden is in die en die flowchart/functiedesign. Dan sta jij te klapperen met je oren...

Waarom ik bv ook de conventionele talen erbij trek? je kan makkelijk een webapp maken om bv html te laten genereren door de executable te draaien op de webserver, als een webtaal je niet de juiste mogelijkheden biedt. of je kan client-side (liever niet) werken dmv bv Active-X componenten etc.