Archief - De koffiepauzehoek

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

dJeez

Legacy Member
Dieterg zei:
Gisteren naar meetup geweest over angular bij Kunstmaan. Het was één van de betere meetups waar ik al naartoe ben geweest.
Getver, ge had dat moeten zeggen hé. Ik was daar ook :p.

Dieterg zei:
Extradeluxe.be, wat moet dat wel niet een leuk project zijn geweest om aan mee te werken!? Echt knap gemaakt!
Dat was (en is) een leuk project ja, hoewel er voor mij maar weinig back-end werk bij kwam kijken (ik heb wel ook 2 dagen kunnen prullen met AngularJS, dus dat was wel meegenomen als eerste kennismaking). Ik kan u wel vertellen dat IE support erg frustrerend was (het weekend voor de launch bleek IE altijd te crashen bij het inladen van de films, die zijn toen nog lichter gemaakt - spijtig voor de andere browsers eigenlijk).

Voor diegenen die er niet bij waren : http://bit.ly/angularmeetup. De video's volgen nog (indien de kwaliteit goed genoeg is tenminste, want blijkbaar zijn daar wat twijfels over).

En even ter aanvulling : blijkbaar heeft het AngularJS team ook recent een blogpost geschreven over het organiseren van je code bij grotere projecten -> http://blog.angularjs.org/2014/02/an-angularjs-style-guide-and-best.html.

Dieterg

Legacy Member
dJeez zei:
Getver, ge had dat moeten zeggen hé. Ik was daar ook :p.
Ik had de link met u & kunstmaan te laat door. Toen ik op het even zelf was wou ik hier nog posten, maar het internet ging er te traag en de kans dat je het dan zou lezen was waarschijnlijk toch te klein..

Zijn er hier nog mensen hier die naar meetups gaan? Normaal probeer ik aanwezig te zijn bij de AngularJS meetups: The Belgian AngularJS Meetup Group (Brussels) - Meetup

W0utR

Legacy Member
Heeft er iemand ervaring met TDD en kan wat tips geven?

Jammer genoeg heb ik dat op mijn werk nooit nodig gehad, maar de laatste tijd is het gewoon noodzakelijk in de meeste jobs.

XTOF

Legacy Member
W0utR zei:
Heeft er iemand ervaring met TDD en kan wat tips geven?

Jammer genoeg heb ik dat op mijn werk nooit nodig gehad, maar de laatste tijd is het gewoon noodzakelijk in de meeste jobs.

Ik weet niet of je 'Uncle Bob' kent van clean coders? Hij heeft een heleboel video's over best practices in Java development waaronder ook een 2 uur durende video over TDD. Zeer interessant en heel goed uitgelegd!
Ik denk wel niet dat je zijn videos gratis online gaat vinden.. Als je de video wilt hebben, kan ik de 2 files van 1,7 gb wel eens proberen te uploaden :)

Hier kan je ze online kijken/downloaden tegen een klein bedrag:
- Clean Coders
- Clean Coders

W0utR

Legacy Member
Merci, zal ze zeker bekijken! $12 in totaal is de moeite niet, dus zal ze wel gewoon downloaden.

Shaddix

Legacy Member
Iemand tips voor logo design? Ik ben met een conceptje aan het uitwerken en heb er een logo voor in m'n hoofd maar ik kan nu moeilijk een duur agency daarvoor gaan inschakelen...
Wat zou een freelancer daar zoal voor vragen?

Ik heb ook al aan iets als 99designs gedacht, daar heb je voor 240 euro een logo, maar daar zou veel plagiaat op komen...

dJeez

Legacy Member
W0utR zei:
Heeft er iemand ervaring met TDD en kan wat tips geven?

Jammer genoeg heb ik dat op mijn werk nooit nodig gehad, maar de laatste tijd is het gewoon noodzakelijk in de meeste jobs.
Als ik u een raad mag geven : BDD (Behavior Driven Development) zeker ook bekijken. Voor PHP is dat dan phpSpec en Behat (de eerste is internal BDD, de tweede external BDD - dus user stories geautomatiseerd uitvoeren op de site). Naar mijn aanvoelen evolueren meer en meer mensen die richting uit. phpSpec vind ik alvast een aanrader (mits je het correct gebruikt), en is echt super om mee te werken eens je het principe doorhebt (en je schrijft er imho ook direct cleanere code door, win-win dus). Voorbeelden van het gebruik kan je vinden in Open Source projecten (Sylius op GitHub vb., daar heb ik wel wat dingen uit geleerd om goede mocks te schrijven).

Moving to BDD with PHP | Blog | UVD

Shaddix zei:
Iemand tips voor logo design? Ik ben met een conceptje aan het uitwerken en heb er een logo voor in m'n hoofd maar ik kan nu moeilijk een duur agency daarvoor gaan inschakelen...
Wat zou een freelancer daar zoal voor vragen?
Vraag of check het eens op Graphics - Art - Design hier :p.

TheCrow7

Legacy Member
Dieterg zei:
Gisteren naar meetup geweest over angular bij Kunstmaan.

Zijn er mensen die daadwerkelijk nog de bomen in het javascriptbos zien?

Ik heb al met pure javascript als met jQuery en Mootools gewerkt, maar ik zou me eens moeten verdiepen in javascript want mijn kennis hierover is echt verwaarloosbaar.

Enkel rest de vraag: begin ik met pure javascript of kies ik voor een library/framework? En indien de 2de optie, welke lib?

bealzebub

Legacy Member
dJeez zei:
Als ik u een raad mag geven : BDD (Behavior Driven Development) zeker ook bekijken. Voor PHP is dat dan phpSpec en Behat (de eerste is internal BDD, de tweede external BDD - dus user stories geautomatiseerd uitvoeren op de site). Naar mijn aanvoelen evolueren meer en meer mensen die richting uit..

Het is een beetje een grijze zone als je over TDD vs BDD spreekt. Persoonlijk zie ik implementeren ahv phpSpec, rSpec, … tests niet als BDD, maar als pure TDD. Je gebruikt de "spec" grammatica om unit tests te schrijven (micro dus). Of je nu een assert of een expect/should assertion library gebruikt, de dingen die je test zijn identiek hetzelfde. Spec leest makkelijker voor een leek, assert is compacter, dus je zal voor- en tegenstanders van beiden vinden.

BDD is voor mij implementeren van user stories (Behat, Cucumber, …). En dikwijls is dat in min of meer verstaanbare tekst die dan via nifty regex naar opnieuw assertions worden omgezet. Je test echter vanuit een ander standpunt in je stack, vanuit de featureset en flow van je applicatie zelf.

TDD zie ik dus meer als het starten vanuit unit tests (micro) terwijl BDD vanuit de integration tests vertrekt (macro). En net zoals bij een RTS zal iemand die enkel maar micro of macro doet verpletterd worden door iemand die in staat is van beiden goed te doen :lol:

Soit, de interpretatie van wat TDD en wat BDD nu eigenlijk is maakt nie veel uit. Ontwikkelen aan de hand van tests zorgt gewoon voor betere focus, minder afleiding en uiteindelijk compactere en veel mooiere code als je t goed doet en dat is waar het uiteindelijk allemaal om draait. En niets geeft meer voldoening dan een applicatie ontwikkelen waar je testsuite heel snel draait (die dus bij elke aanpassing opnieuw de tests kan doorlopen) en waar je beetje bij beetje al dat rood in groen ziet veranderen.

TheCrow7 zei:
Zijn er mensen die daadwerkelijk nog de bomen in het javascriptbos zien?

Ik heb al met pure javascript als met jQuery en Mootools gewerkt, maar ik zou me eens moeten verdiepen in javascript want mijn kennis hierover is echt verwaarloosbaar.

Enkel rest de vraag: begin ik met pure javascript of kies ik voor een library/framework? En indien de 2de optie, welke lib?

tl;dr Leer eerst Javascript zelf goed, kies dan de lib die het beste past bij wat je wil doen.

Een lib is een hulpmiddel, Javascript is de taal. Zonder een grondige kennis van de taal en de concepten erachter (en Javascript is een gans ander beestje dan OO-talen zoals Java, PHP, Ruby, …) blijft alles wat je doet niet meer dan bricoleren.

Libraries zijn een beetje zoals IKEA meubels. Je moet alles zelf in mekaar steken, maar moeilijk is het niet, de onderdelen zijn allemaal voorgezaagd en alles past (zolang je weet wat waar hoort) mooi bij mekaar. Voor het meeste is dat ook genoeg, het zal je al heel ver brengen.

Dan heb je mensen die zelfs niet in staat zijn IKEA meubels in mekaar te steken en iets nemen dat door iemand anders in mekaar gestoken is (plugins). Die meubels die al in mekaar gezet zijn kunnen goed in mekaar gezet zijn of slecht, aan de buitenkant zie je t nie echt… of ze komen thuis en t past nie waar ze t willen zetten en ze zagen er zelf een stuk af en posten dan op dit forum omdat het meubel omver valt zonder de poten die ze in de vuilbak gegooid hebben.

De laatste en moeilijkste optie is van zelf meubels te leren maken. Het kost veel meer moeite en het zal zeker met vallen en opstaan zijn, maar je kan wel zelf speciale meubels maken, bestaande meubels beoordelen en de rommel van de goeie dingen scheiden.

Met Javascript libs en plugins is dat juust hetzelfde. Als je JS zelf kent ga je de juiste lib voor het juiste project kunnen kiezen, plugins naar waarde schatten als je ze wil gebruiken, ze eventueel kunnen aanpassen zonder dat ze uit mekaar vallen, … Het goeie en tegelijk slechte aan libs is dat ze naast normalizeren van browserincompatibiliteit ook veel extra toevoegen om je code er properder te laten uitzien: promises, iterators, wrappers, … Pas op, ik ben daar voorstander van, maar als je dan op een punt komt waar je iets speciaals wil doen en je niet snapt waarom die libs de zaken zo doen, dan loop je vast.

En soms is het gewoon beter van geen lib te gebruiken. jQuery met 15 animatieplugins om een slideshow te hebben met fancy effectjes op een mobile device…*god…*waarom toch??? jQuery heeft pakken code om problemen aan te pakken waar geen enkele mobiele browser boodschap aan heeft, animaties kunnen dikwijls via CSS (en dus hardware accelerated) ipv via timers in Javascript, …

TheCrow7

Legacy Member
bealzebub zei:
Leer eerst Javascript zelf goed, kies dan de lib die het beste past bij wat je wil doen.

...

Klinkt logisch nu je het zo schrijft. Thanks voor de uiteenzetting.

Moto

Legacy Member
Enkel rest de vraag: begin ik met pure javascript of kies ik voor een library/framework? En indien de 2de optie, welke lib?

Als ge een boek van javascript wilt lezen dan is deze niet slecht, zowiezo het "bad parts" gedeelte is wel handig om op voorhand te wezen

http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742/ref=sr_1_1?ie=UTF8&qid=1397745520&sr=8-1&keywords=javascript+good+parts

Voor de rest zeker gewoon javascript doen geen typescript / coffescript toestanden

Als framework -> AngularJs = :love: :woohoo: :applause:

kunt ook altijd op http://todomvc.com/ kijken wat u beter ligt



TDD is trouwens een religie, en geen software development methodologie

bealzebub

Legacy Member
Moto zei:
Als framework -> AngularJs = :love: :woohoo: :applause:

TDD is trouwens een religie, en geen software development methodologie

Hmmm, ipv zo religieus te zijn over angular zou je toch wel beter religieus zijn over TDD. Angular is nie slecht, daar nie van, maar hét van hét is t zeker ook nie.

Ik kan je in elk geval zeggen dat TDD wel degelijk een development workflow is en al rap een vereiste eens je met een groter project zit waar meerdere mensen op werken. Zeker als je met kleine iteraties zit komt het ook van pas, geen afleiding. Zonder zorgen kunnen refactoren, weten dat je cijfers nog altijd kloppen, ... En naar maatwerken toe kan BDD ook veel helpen: je schrijft de scenarios uit met je klant en dan implementeer je ze gewoon.

En los van het feit of je nu je tests vooraf of achteraf schrijft... als je op github een pull request stuurt wordt die meestal gewoon direct geweigerd zonder deftige test coverage, en zeker nu travis CI en aanverwanten gewoon ingebouwd zitten.

Moto

Legacy Member
Dit boek zou ik echt niet aanraden aan iemand die weinig of geen javascript kent..

wel ik lees

Ik heb al met pure javascript als met jQuery en Mootools gewerkt, maar ik zou me eens moeten verdiepen in javascript

dus ik verwacht genoeg voorkennis, maar niks houd u tegen om iets beters voor te stellen ;)

Moto

Legacy Member
Hmmm, ipv zo religieus te zijn over angular zou je toch wel beter religieus zijn over TDD. Angular is nie slecht, daar nie van, maar hét van hét is t zeker ook nie.
Betekenis van de smileys is dus "Ben heel blij met AngularJs, "

Ik kan je in elk geval zeggen dat TDD wel degelijk een development workflow is en al rap een vereiste eens je met een groter project zit waar meerdere mensen op werken.

Wel heb tot nu toe nog geen project gedaan (in mijn 15 jaar als IT-consultant) waar ik TDD als een vereiste zou zien
Wilt niet zeggen dat goede test-coverage in bepaalde contexten effectief noodzakelijk is (bv medische software / 3rd party libraries,...)
Op uitzondering van 1 hebben geen enkel van mijn projecten unit tests/integration tests

dJeez

Legacy Member
bealzebub zei:
Soit, de interpretatie van wat TDD en wat BDD nu eigenlijk is maakt nie veel uit. Ontwikkelen aan de hand van tests zorgt gewoon voor betere focus, minder afleiding en uiteindelijk compactere en veel mooiere code als je t goed doet en dat is waar het uiteindelijk allemaal om draait. En niets geeft meer voldoening dan een applicatie ontwikkelen waar je testsuite heel snel draait (die dus bij elke aanpassing opnieuw de tests kan doorlopen) en waar je beetje bij beetje al dat rood in groen ziet veranderen.
Daar ben ik het nu eens volmondig mee eens :p. De grens is inderdaad grijs want BDD borduurt verder op TDD, maar wat spec voor mij specifiek interessant maakt is net de focus op de flow van je code op basis van de specificaties. Het sluit naadloos aan bij de Agile Development methodologie (die we hier gezien bepaalde klanten ook meer en meer aan het gebruiken zijn) en dat werkt voor mij persoonlijk dan ook iets makkelijker (als je het van bij aanvang gebruikt zoals het hoort).

Moto zei:
Wel heb tot nu toe nog geen project gedaan (in mijn 15 jaar als IT-consultant) waar ik TDD als een vereiste zou zien
Als IT-consultant lijkt mij dat al vreemd, want doorgaans is dat nu een vereiste alvorens je maar aan de slag mag.

En tenzij je een kant-en-klaar product aflevert en het dan laat sterven lijkt het mij ook niet echt aannemelijk. Het heeft helemaal niets te maken met religie. Langlopende projecten die door de tijd evolueren kunnen gewoon niet deftig zonder tests, tenzij je graag om de X aantal tijd alles opnieuw gaat herschrijven (en ook dan zijn tests makkelijk om te weten wanneer iets breekt) of graag extra veel tijd steekt in debugging. Op korte termijn kost het idd wat extra tijd (en dus een extra investering), maar op lange termijn bekeken levert het wel snel op (omdat je minder tijd moet steken in wijzigingen en ook snel weet waar er iets scheelt).

Agile proberen te werken (wat wel een hype is) zonder unit tests lijkt mij bij voorbaat al goed voor zelfmoord.

Om het met B.A. Baracus te zeggen : I Pity The Fool Who Doesn't Write Unit Tests
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan