De Devschuur Coffee Corner - Iteratie ⓫

[Vincentio]

Mugwump schreef op woensdag 4 juli 2018 @ 15:40:
[...]


Ik zou zelf sowieso nooit in een dergelijke niche willen belanden. Een (of meer) generieke programmeertalen leren bied je veel meer flexibiliteit en opties om diverse werkgevers te kiezen.

Als ik mij over een ding geen zorgen hoef te maken als SAP ontwikkelaar is het de ruime keuze werkgevers

[Mugwump]

Vincentio schreef op woensdag 4 juli 2018 @ 19:35:
[...]


Als ik mij over een ding geen zorgen hoef te maken als SAP ontwikkelaar is het de ruime keuze werkgevers

Het is ook niet dat de vraag an sich beperkt is, maar hoeveel innovatieve startup doen iets met SAP? Hoeveel bedrijven die echt een eigen product maken doen dat met SAP?
In mijn ogen worden de echt toffe, leuke dingen niet met SAP gedaan. Je zit toch hoofdzakelijk in de CRM / ERP hoek in mijn ogen.

[Crazy D]

Mugwump schreef op woensdag 4 juli 2018 @ 22:41:
Het is ook niet dat de vraag an sich beperkt is, maar hoeveel innovatieve startup doen iets met SAP? Hoeveel bedrijven die echt een eigen product maken doen dat met SAP?
In mijn ogen worden de echt toffe, leuke dingen niet met SAP gedaan. Je zit toch hoofdzakelijk in de CRM / ERP hoek in mijn ogen.

Voor sommige mensen is dat een hele interessante en uitdagende hoek (ik denk vooral voor de niet-die-hard nerds hoewel ik niet in de SAP hoek zit, verveel ik me binnen de Exact omgeving niet vaak, maar de uitdaging zit hem vaak eerder in de processen, bedrijven, de mensen, de beperkingen van de standaard software).

[Vincentio]

Mugwump schreef op woensdag 4 juli 2018 @ 22:41:
[...]


Het is ook niet dat de vraag an sich beperkt is, maar hoeveel innovatieve startup doen iets met SAP? Hoeveel bedrijven die echt een eigen product maken doen dat met SAP?
In mijn ogen worden de echt toffe, leuke dingen niet met SAP gedaan. Je zit toch hoofdzakelijk in de CRM / ERP hoek in mijn ogen.

Remiqz is gebouwd op SAP bijvoorbeeld.
Het meeste werk zit natuurlijk wel in de traditionele bedrijfsprocessen, maar ook daar kan je soms best leuke dingen doen.
Wat dacht je van bijvoorbeeld AR binnen onderhoudsprocessen of in warehouses?
En IoT is natuurlijk goed toe te passen binnen supply chain en asset management.

Maar ik ga inderdaad geen game ontwikkelen binnen SAP.

Crazy D schreef op woensdag 4 juli 2018 @ 23:14:
[...]

Voor sommige mensen is dat een hele interessante en uitdagende hoek (ik denk vooral voor de niet-die-hard nerds hoewel ik niet in de SAP hoek zit, verveel ik me binnen de Exact omgeving niet vaak, maar de uitdaging zit hem vaak eerder in de processen, bedrijven, de mensen, de beperkingen van de standaard software).

En ook dat, hoe ga je een solide oplossing neerzetten inderdaad die de klant blij maakt.

[Mugwump]

Vincentio schreef op donderdag 5 juli 2018 @ 07:46:
[...]


Remiqz is gebouwd op SAP bijvoorbeeld.
Het meeste werk zit natuurlijk wel in de traditionele bedrijfsprocessen, maar ook daar kan je soms best leuke dingen doen.
Wat dacht je van bijvoorbeeld AR binnen onderhoudsprocessen of in warehouses?
En IoT is natuurlijk goed toe te passen binnen supply chain en asset management.

Maar ik ga inderdaad geen game ontwikkelen binnen SAP.

Ik zei ook bewust niet dat het helemaal niet gebeurde, maar dat het niet gebruikelijk is.

[...]


En ook dat, hoe ga je een solide oplossing neerzetten inderdaad die de klant blij maakt.

Dat is verre van iets dat uniek is voor SAP. Ook voor het gros van de generieke software development geldt dat. Alleen is die uitdaging in mijn ogen technisch op vele vlakken uitgebreider en boeiender dan wanneer je om een bestaand softwarepakket heen ontwikkelt.

[TheNephilim]

Spotify meldt wel vrolijk dat x-artiest een nieuw album heeft, maar als ik die op wil slaan "Wauw indrukwekkende collectie...", tldr: je bibliotheek zit vol!

[AW_Bos]

Ben ik nu de enige die het idee heeft dat binnen de RFC de value niet het juiste attribuut is voor een submitknop?
De value geeft dus een waarde aan de knop, die je vervolgens in een POST of GET beschikbaar krijgt. Maar in mijn geval wil ik dus een andere value eraan vasthangen. Stel je voor dat je de value moet vertalen in meerdere talen. Dan moet je dit steeds in je PHP-code weer afvangen?

code:

    <input type="submit" name="search" value="Zoeken" />

Waarom hebben ze niet iets als dit?

code:

    <input type="submit" name="search" value="search" label="Zoeken maar!" />

[azerty]

AW_Bos schreef op donderdag 5 juli 2018 @ 18:26:
Ben ik nu de enige die het idee heeft dat binnen de RFC de value niet het juiste attribuut is voor een submitknop?
De value geeft dus een waarde aan de knop, die je vervolgens in een POST of GET beschikbaar krijgt. Maar in mijn geval wil ik dus een andere value eraan vasthangen. Stel je voor dat je de value moet vertalen in meerdere talen. Dan moet je dit steeds in je PHP-code weer afvangen?

code:

    <input type="submit" name="search" value="Zoeken" />

Waarom hebben ze niet iets als dit?

code:

    <input type="submit" name="search" value="search" label="Zoeken maar!" />

Gewoon checken of de waarde niet leeg is / variabele bestaat? Dan maakt het niet meer uit wat erin staat

[Alex)]

AW_Bos schreef op donderdag 5 juli 2018 @ 18:26:
Ben ik nu de enige die het idee heeft dat binnen de RFC de value niet het juiste attribuut is voor een submitknop?
De value geeft dus een waarde aan de knop, die je vervolgens in een POST of GET beschikbaar krijgt. Maar in mijn geval wil ik dus een andere value eraan vasthangen. Stel je voor dat je de value moet vertalen in meerdere talen. Dan moet je dit steeds in je PHP-code weer afvangen?

code:

    <input type="submit" name="search" value="Zoeken" />

Waarom hebben ze niet iets als dit?

code:

    <input type="submit" name="search" value="search" label="Zoeken maar!" />

Die is er toch ook?

code:

<button name="search" type="submit" value="search">
Zoeken maar!
</button>

[AW_Bos]

Daar hebben jullie gelijk in.
Het wordt tijd dat in HTML 5.1 (bijvoorbeeld) die input-submit eens deprecated gaat worden.

[TheNephilim]

Leuk spelletje zo voor de vrijdag: https://regexcrossword.com/

[Otherside1982]

TheNephilim schreef op vrijdag 6 juli 2018 @ 11:23:
Leuk spelletje zo voor de vrijdag: https://regexcrossword.com/

Oh, dat is tof. Enkele jaren geleden zo'n hexagonale regex puzzel opgelost op papier voor een geocache puzzel.
Tof dat je er ook eenvoudig zelf kan maken op die website.

[Douweegbertje]

AW_Bos schreef op donderdag 5 juli 2018 @ 18:26:
Ben ik nu de enige die het idee heeft dat binnen de RFC de value niet het juiste attribuut is voor een submitknop?
De value geeft dus een waarde aan de knop, die je vervolgens in een POST of GET beschikbaar krijgt. Maar in mijn geval wil ik dus een andere value eraan vasthangen. Stel je voor dat je de value moet vertalen in meerdere talen. Dan moet je dit steeds in je PHP-code weer afvangen?

code:

    <input type="submit" name="search" value="Zoeken" />

Waarom hebben ze niet iets als dit?

code:

    <input type="submit" name="search" value="search" label="Zoeken maar!" />

Dat hebben ze wel, namelijk <button>. Als je 1 button in je form hebt is dat je submit button.

Ten tweede kan ik mij geen enkele nuttige use-case verzinnen dat je de value van een button in je backend wilt gebruiken om ook maar iets qua logica te doen. Niet alleen is het user input, er zijn ook 10 andere manieren om bepaalde logica op te vangen als het gaat om "welk form is het" of "is dit echt gePOST"

Dus ja, op zich een fair point dat de input type "submit" een beetje erg vaag is, maar je gebruik er van is nog vager

edit; ik zie dat ik nu een beetje spuit 11 ben.. sorry

[Alex)]

Douweegbertje schreef op zondag 8 juli 2018 @ 02:22:
[...]

Ten tweede kan ik mij geen enkele nuttige use-case verzinnen dat je de value van een button in je backend wilt gebruiken om ook maar iets qua logica te doen. Niet alleen is het user input, er zijn ook 10 andere manieren om bepaalde logica op te vangen als het gaat om "welk form is het" of "is dit echt gePOST"

Ik kan er wel eentje bedenken: meerdere acties op hetzelfde object, zoals "Save as draft" en "Publish".

[ Voor 5% gewijzigd door Alex) op 08-07-2018 02:43 ]

[Douweegbertje]

Alex) schreef op zondag 8 juli 2018 @ 02:41:
[...]

Ik kan er wel eentje bedenken: meerdere acties op hetzelfde object, zoals "Save as draft" en "Publish".

ja ok fair enough.
Ik ben denk ik ook gewoon even in de war in de zin dat ik mij niet bekommer om hoe de frontend er precies uit ziet. Zelfs in jouw geval heb ik een "object" van m'n form. Daarop kan ik gewoon dynamisch actions op zetten. Actions door hun eigen routes/functions weer worden uitgevoerd. M.a.w. ik kijk niet eens hoe het form er precies uit ziet.

Maar dan nog zou je meer met het attribute "name" kunnen doen dan daadwerkelijk de "value" want die word gebruikt voor de tekst van het element. Dus je zou elke submit dezelfde name kunnen geven en dan de inhoud van de name kunnen checken ($_POST['namehier'] == 'edit') of if($_POST['edit']) etc. Dat is dan wellicht meer de "fix" voor het ding met dynamische values op basis van taal

[Mugwump]

Alex) schreef op zondag 8 juli 2018 @ 02:41:
[...]

Ik kan er wel eentje bedenken: meerdere acties op hetzelfde object, zoals "Save as draft" en "Publish".

Dat zijn gewoon twee totaal verschillende handelingen, dus die hebben aan de back end kant ook gewoon twee totaal verschillende endpoints, lijkt me. Kreeg een tijdje terug ook nog weer zo'n fijne codebase op basis van MVC voor m'n neus waar één pagina met een reeks aan diverse acties gewoon in één form / viewmodel / endpoint gepropt was waarbij de back end uit een berg conditionele statements bestond om überhaupt te bepalen wat er moest gebeuren en een enorm brei aan code om data selectief uit het viewmodel te halen, validaties en checks te doen en ga zo maar door. Dat was echt na slechts twee maandjes werk al totaal onoverzichtelijke en ononderhoudbare code geworden.

Nou zal je in PHP vaak genoeg geen viewmodels of iets vergelijkbaars hebben, maar ook dan kun je in ieder geval de logica scheiden om de boel overzichtelijk te houden.

[Alex)]

Allemaal leuk en aardig, maar een HTML-form kan maar één action hebben. Daar kun je wel omheen werken door met JavaScript te gaan hacken, maar of je codebase daar nou beter van wordt?

[Mugwump]

Alex) schreef op zondag 8 juli 2018 @ 20:44:
Allemaal leuk en aardig, maar een HTML-form kan maar één action hebben. Daar kun je wel omheen werken door met JavaScript te gaan hacken, maar of je codebase daar nou beter van wordt?

Het houdt je back end een stuk schoner en ik vind middels JS de actie bepalen en de form op de juiste wijze submitten niet onoverzichtelijker. Je zult sowieso waarschijnlijk verschillende validatie doen in beide gevallen. Criteria voor publicatie zijn doorgaans stringenter dan voor het opslaan als draft.

[Douweegbertje]

Alex) schreef op zondag 8 juli 2018 @ 20:44:
Allemaal leuk en aardig, maar een HTML-form kan maar één action hebben. Daar kun je wel omheen werken door met JavaScript te gaan hacken, maar of je codebase daar nou beter van wordt?

nja het voordeel is dat volwassen frameworks dit zo voor je kunnen oplossen. Ik dev bijna niet meer maar had recent even iets gemaakt in Symfony. Binnen 10 minuten had ik een form met CRUD, fout afhandeling (zowel front als backend), een entity en persistence naar de DB.

Echt holy shit wat gaat dat simpel en goed tegenwoordig

[Alex)]

Mugwump schreef op zondag 8 juli 2018 @ 21:54:
[...]


Het houdt je back end een stuk schoner en ik vind middels JS de actie bepalen en de form op de juiste wijze submitten niet onoverzichtelijker.

In plaats daarvan "vervuil" je de front-end. Of is het dan een minder erg omdat het iemand anders z'n probleem is?

Je zult sowieso waarschijnlijk verschillende validatie doen in beide gevallen. Criteria voor publicatie zijn doorgaans stringenter dan voor het opslaan als draft.

Dat is helemaal correct.

Maar in beide gevallen draait het om een vergelijkbare actie op hetzelfde object, waarbij het enige wezenlijke verschil de eindstand is. In het ene geval blijft het een draft, in het andere geval is het een nieuwe gepubliceerde versie.

Ik heb op dit moment te maken met een project waarin via JavaScript op allerlei magische manieren wordt bepaald waar een formpost heen gaat. Geloof me, daar word je ook niet blij van.

[Hydra]

Beide oplossingsrichtingen zijn IMHO prima en daarnaast simpel te implementeren. M.i. dus een beetje een "who cares". Volgens mij hebben we over 't algemeen lastiger zaken op te lossen dan hoe je het verschil gaat zien tussen "Publish" end "Save".

[Alex)]

Hydra schreef op maandag 9 juli 2018 @ 08:09:
M.i. dus een beetje een "who cares".

Zolang het door de hele oplossing heen maar consequent gebeurt.

[ThomasG]

Alex) schreef op zondag 8 juli 2018 @ 20:44:
Allemaal leuk en aardig, maar een HTML-form kan maar één action hebben. Daar kun je wel omheen werken door met JavaScript te gaan hacken, maar of je codebase daar nou beter van wordt?

Om dit soort situaties kan o.a. een <button> daarom form{action,enctype,method} e.d. attributten hebben. Daar heb je geen javascript voor nodig. Zo kun je het formulier standaard naar save laten verwijzen, en een aparte submit knop met een formaction="{publish-url}".

[ Voor 12% gewijzigd door ThomasG op 09-07-2018 09:46 ]

[TheNephilim]

ThomasG schreef op maandag 9 juli 2018 @ 09:45:
[...]
Om dit soort situaties kan o.a. een <button> daarom form{action,enctype,method} e.d. attributten hebben. Daar heb je geen javascript voor nodig.

Verrek! Dat heb ik nooit geweten, maar je hebt inderdaad gewoon oa.:

formaction HTML5
The URI of a program that processes the information submitted by the button. If specified, it overrides the action attribute of the button's form owner.

https://developer.mozilla...s/Web/HTML/Element/button

[orf]

Douweegbertje schreef op zondag 8 juli 2018 @ 23:09:
[...]
Ik dev bijna niet meer maar had recent even iets gemaakt in Symfony.
[...]

Waarom dev je bijna niet meer?

[Douweegbertje]

orf schreef op maandag 9 juli 2018 @ 09:50:
[...]


Waarom dev je bijna niet meer?

Ah, ja. De tl;dr versie is dat ik nu meer devops doe.

We hebben meerdere teams, voornamelijk verdeeld over het type sites wat we maakte (wp, typo3 en magento). Toendertijd waren de functies een beetje "full stack" te benoemen. Dus men moest ook dingen met "servers" doen. Een mix van managed hosting maar ook eigen vpsjes is wat we hadden. Persoonlijk vond ik het 1 grote cluster fuck. Combineer dat ook met het feit dat niet iedereen de behoefte had om "full stack dev" te zijn en dat zo'n functie titel ook soms een excuus is om dingen te doen omdat je niet gewoon iemand aanneemt die er expertise in heeft..

Dus de afgelopen 2 jaar ben ik o.a. bezig geweest om dat te structureren en sinds januari dit jaar draaien wij als webbureau alles zelf in de cloud. Daarbij ontwikkelen we ook dingen om het de devs makkelijker te maken (lokaal werken, bepaalde toegang, deployments, etc). Inherent hieraan ben ik dan ook weer meer bezig met het "regelen" en alles wat eromheen komt kijken dan het daadwerkelijk programmeren.

Je ziet vaak webbureaus naar een managed oplossing kijken, wat ook zeker een prima oplossing is. Onze ervaring was echter dat de lijntjes lang waren en de oplossingen maar matig. Nog even los van het financiële plaatje. We draaien misschien nu 10x meer winst over hosting..

Maar goed, ik doe soms echt van alles omdat ik alles interessant vind en het gaat mij relatief makkelijk af gaat. Dus ondertussen qua dev werk heb ik nog 2 magento extensions gemaakt en doe ik nog steeds wat security dingen buiten het werk om

[Mugwump]

Alex) schreef op maandag 9 juli 2018 @ 06:17:
[...]
In plaats daarvan "vervuil" je de front-end. Of is het dan een minder erg omdat het iemand anders z'n probleem is?

[...]

Dat is helemaal correct.

Maar in beide gevallen draait het om een vergelijkbare actie op hetzelfde object, waarbij het enige wezenlijke verschil de eindstand is. In het ene geval blijft het een draft, in het andere geval is het een nieuwe gepubliceerde versie.

Ik heb op dit moment te maken met een project waarin via JavaScript op allerlei magische manieren wordt bepaald waar een formpost heen gaat. Geloof me, daar word je ook niet blij van.

Ik word sowieso niet heel erg vrolijk van de wijze waarop veel JavaScript in elkaar zit. Ook daar geldt iets te vaak het mantra 'als het maar werkt', zeker wanneer er geen structuur wordt afgedwongen door een frameworkje.
De HTML button oplossing is wel de meest elegante. Bied je bovendien nog de mogelijkheid een site te maken die in de basis ook werkt zonder Javascript.

Hydra schreef op maandag 9 juli 2018 @ 08:09:
Beide oplossingsrichtingen zijn IMHO prima en daarnaast simpel te implementeren. M.i. dus een beetje een "who cares". Volgens mij hebben we over 't algemeen lastiger zaken op te lossen dan hoe je het verschil gaat zien tussen "Publish" end "Save".

Het specifieke voorbeeld is natuurlijk vrij triviaal, maar dit soort zaken zijn nou juist de kern van goed software-ontwerp. Ik gaf eerder al een voorbeeld van een tijdje terug waarbij iemand gewoon één grote brij had gemaakt van een stuk of 5-7 verschillende operaties en objecten waarop die operaties werkten met één 'save' knop waarbij zijn back end dan maar uit moest vogelen wat er bedoeld werd. Eigenlijk had het een heel eenvoudig stukje software kunnen zijn dat verder niet zo spannend was, maar nu kostte een triviale wijziging al veel tijd.
Een blogje met publish / save as draft snapt het gros van de mensen ook gelijk wel, maar als je over bijvoorbeeld complexe financiële, juridische of logistieke domeinen praat ligt dat toch net wat anders.

Voor de wat uitdagendere problemen ben ik maar even begonnen aan de alfaversie van Greg Young's e-book over event versioning, hier gratis te lezen.

[Douweegbertje]

Mugwump schreef op maandag 9 juli 2018 @ 10:23:
[...]


Ik word sowieso niet heel erg vrolijk van de wijze waarop veel JavaScript in elkaar zit. Ook daar geldt iets te vaak het mantra 'als het maar werkt', zeker wanneer er geen structuur wordt afgedwongen door een frameworkje.
De HTML button oplossing is wel de meest elegante. Bied je bovendien nog de mogelijkheid een site te maken die in de basis ook werkt zonder Javascript.


[...]

Eens! Ik had daarom pas iets met webpack + es6 gebouwd. Again; holy shit wat chill. Classes

http://es6-features.org/#ClassDefinition

[Hydra]

Mugwump schreef op maandag 9 juli 2018 @ 10:23:
Het specifieke voorbeeld is natuurlijk vrij triviaal, maar dit soort zaken zijn nou juist de kern van goed software-ontwerp.

Tuurlijk. Maar enorm doorgaan op zo iets triviaals is vaak een vorm van bike-shedding. Je zult hier altijd afwegingen in moeten maken en die zijn nogal specifiek voor het probleem. Het heeft dus m.i. weinig zin om zo'n triviaal voorbeeld te nemen; in het 'echt' zijn de afwegingen vaak een stuk lastiger en dat zijn dan de issues waar je samen een consensus over moet bereiken.

Als je een 'pure' REST API hebt aan de back-end met verschillende end-points voor "Save" en "Publish" die ook nog eens door verschillende clients gebruikt wordt, dan wil je volgens mij niet die logica in de back-end zetten. Dan ben je in een generieke API client-specifieke logica aan het bouwen. Andersom kan natuurlijk ook.

Voor de wat uitdagendere problemen ben ik maar even begonnen aan de alfaversie van Greg Young's e-book over event versioning, hier gratis te lezen.

Ik vraag me af in hoeverre dit relevant is voor waar we het nu over hebben versus dat je graag wil laten weten met event sourcing bezig te zijn

Douweegbertje schreef op maandag 9 juli 2018 @ 10:33:
Eens! Ik had daarom pas iets met webpack + es6 gebouwd. Again; holy shit wat chill. Classes

http://es6-features.org/#ClassDefinition

Als ik in TypeScript mag werken wil ik wel front-end werk doen. Anders; fuck that noise. Ik doe niks meer (professioneel dan) met dynamically typed talen, en al helemaal niet meer met JS.

P.s. Vue.js is kut.

[ Voor 31% gewijzigd door Hydra op 09-07-2018 10:41 ]

[TheNephilim]

Douweegbertje schreef op maandag 9 juli 2018 @ 10:09:
[...]

Je ziet vaak webbureaus naar een managed oplossing kijken, wat ook zeker een prima oplossing is. Onze ervaring was echter dat de lijntjes lang waren en de oplossingen maar matig. Nog even los van het financiële plaatje. We draaien misschien nu 10x meer winst over hosting..

Je moet inderdaad echt flink de portemonnee trekken wil je fatsoenlijke managed hosting hebben. Tot zover doen wij eigenlijk niet zoveel hosting, maar wat we doen zijn automatisch geprovisioned VPSjes. Eigenlijk bevalt dat heel goed, je kunt namelijk alle kanten op, downtime/storingen/etc. is echt miniem en je kunt inderdaad nog wat verdienen ook.

Hydra schreef op maandag 9 juli 2018 @ 10:38:
[...]

Als ik in TypeScript mag werken wil ik wel front-end werk doen. Anders; fuck that noise. Ik doe niks meer (professioneel dan) met dynamically typed talen, en al helemaal niet meer met JS.

P.s. Vue.js is kut.

Wat is er zo kut aan Vue?

[ Voor 19% gewijzigd door TheNephilim op 09-07-2018 11:00 ]

[Mugwump]

Hydra schreef op maandag 9 juli 2018 @ 10:38:

Ik vraag me af in hoeverre dit relevant is voor waar we het nu over hebben versus dat je graag wil laten weten met event sourcing bezig te zijn

Het is meer een 'ik houd me ook bezig met zaken die niet zo triviaal zijn en ik plug gelijk het boekje van Greg Young even want die man heeft best een aardige visie op dingen'-reactie. Anders had ik je ook wel laten weten dat ik bezig mag met Azure Machine Learning, CosmosDb en meer van dat soort alleraardigste zaken.

[...]


Als ik in TypeScript mag werken wil ik wel front-end werk doen. Anders; fuck that noise. Ik doe niks meer (professioneel dan) met dynamically typed talen, en al helemaal niet meer met JS.

Ik deed al front-end in het IE6 / pre-jQuery tijdperk, dus ik heb er een flinke aversie tegen. Met Typescript en een fatsoenlijk framework is het tegenwoordig wel te doen inderdaad.

P.s. Vue.js is kut.

Ik zal het doorgeven aan mijn collega's die er net mee aan de slag zijn gegaan.
Wat is er precies kut aan?

[orf]

Douweegbertje schreef op maandag 9 juli 2018 @ 10:09:
[...]


Ah, ja. De tl;dr versie is dat ik nu meer devops doe.

We hebben meerdere teams, voornamelijk verdeeld over het type sites wat we maakte (wp, typo3 en magento). Toendertijd waren de functies een beetje "full stack" te benoemen. Dus men moest ook dingen met "servers" doen. Een mix van managed hosting maar ook eigen vpsjes is wat we hadden. Persoonlijk vond ik het 1 grote cluster fuck. Combineer dat ook met het feit dat niet iedereen de behoefte had om "full stack dev" te zijn en dat zo'n functie titel ook soms een excuus is om dingen te doen omdat je niet gewoon iemand aanneemt die er expertise in heeft..

Dus de afgelopen 2 jaar ben ik o.a. bezig geweest om dat te structureren en sinds januari dit jaar draaien wij als webbureau alles zelf in de cloud. Daarbij ontwikkelen we ook dingen om het de devs makkelijker te maken (lokaal werken, bepaalde toegang, deployments, etc). Inherent hieraan ben ik dan ook weer meer bezig met het "regelen" en alles wat eromheen komt kijken dan het daadwerkelijk programmeren.

Je ziet vaak webbureaus naar een managed oplossing kijken, wat ook zeker een prima oplossing is. Onze ervaring was echter dat de lijntjes lang waren en de oplossingen maar matig. Nog even los van het financiële plaatje. We draaien misschien nu 10x meer winst over hosting..

Maar goed, ik doe soms echt van alles omdat ik alles interessant vind en het gaat mij relatief makkelijk af gaat. Dus ondertussen qua dev werk heb ik nog 2 magento extensions gemaakt en doe ik nog steeds wat security dingen buiten het werk om

Ah, goed om te lezen.
Wij zijn één van die bureaus die het helemaal managed oplossen. Toevallig bij de partij die ook de hosting voor Tweakers doet. Daar ben ik heel tevreden over, maar de marge die wij op hosting doen zijn niet heel bijzonder. Daartegenover staat dat we wel een betrouwbaar cluster hebben met 24/7 support. Iets wat ik zelf niet wil leveren. Wij zijn daar ongeveer vijf jaar geleden naar gemigreerd. Daarvoor hadden we gewoon een stapel servers waar klanten op stonden. Als we niet deze historie zouden hebben, had ik misschien ook wel voor een eigen oplossing gekozen, maar daar had ik dan wel graag in willen "groeien". Met de sites die we nu hebben, mag je geen foutje maken en leun ik dus op de expertise van een bedrijf die dit als core business heeft.

[alienfruit]

Het gevoel wat ik bij Vue.js krijg is dat het een verbeterde versie van Angular is 😇
Ik gebruik zelf Dokku voor mijn privé webserver en moet zeggen dat het erg aardig werkt voor mij geklungel

[ Voor 37% gewijzigd door alienfruit op 09-07-2018 12:47 ]

[Hydra]

@TheNephilim @Mugwump

Een voorbeeld van waarom ik Vue kut vind is dat het out of the box enorm weinig voor je doet. Een goed voorbeeld zijn Ajax calls; daar moet je al bijvoorbeeld Axios voor gebruiken. Alleen maar om iets te doen wat je in echt elke SPA nodig hebt. Laat staan om te gaan met websockets met stomp ofzo. Dan ben je aangewezen op welgeteld 1 enkele library die ook gewoon nog eens niet werkt. Je merkt dat, t.o.v. een product als Angular, de documentatie en het ecosysteem echt enorm veel kleiner zijn.

Daarnaast mis ik echt een duidelijke guideline van hoe je nou iets zou moeten doen. Wat is nou ‘de’ manier om je project in te delen. Waar zou welke logica moeten zitten? Bij Angular heb je duidelijke guidelines en als iedereen die volgt loop je niet later tegen problemen op omdat een ander team het helemaal anders doet.

En verder is het kwa techniek gewoon vaag. In Angular als ik een div conditioneel wil renderen werkt dat op een logische en simpele manier. In Vue verdwijnen er gewoon om een of andere reden andere objecten uit de DOM zonder enige indicatie waarom.

Vandaar: IMHO is VueJS, t.o.v. AngularJS en Angular 2+, gewoon kut

Maarja. Front-end is sowieso kut, alles beter dan JQuery en met de hand delen van je DOM aan/uit zetten

[kaesve]

Hydra schreef op maandag 9 juli 2018 @ 14:45:
@TheNephilim @Mugwump
...

En verder is het kwa techniek gewoon vaag. In Angular als ik een div conditioneel wil renderen werkt dat op een logische en simpele manier. In Vue verdwijnen er gewoon om een of andere reden andere objecten uit de DOM zonder enige indicatie waarom.

Hoe gaat dit anders dan in angular 1.x? met een v-show blijven je objecten gewoon in je DOM staan. v-if haalt dingen uit je DOM, maar dat deed angular volgens mij ook

[Hydra]

kaesve schreef op maandag 9 juli 2018 @ 14:56:
Hoe gaat dit anders dan in angular 1.x? met een v-show blijven je objecten gewoon in je DOM staan. v-if haalt dingen uit je DOM, maar dat deed angular volgens mij ook

Probleem waar ik tegenaan liep was dat er steeds zooi verdween die niet zou moeten verdwijnen, die dus niet onder dat niveau stond maar er naast. Zonder enige indicatie waarom.

Het zal zeker te maken hebben met mijn gebrek een ervaring, maar in Angular werkte dit gewoon.

[Merlinni]

Door gebrek aan ervaring iets kut vinden is dan ook wel erg kort door de bocht.

Als er een framework is die makkelijk te leren is (vergeleken met React en Angular) is het wel Vue. Er is een style guide in de officiële docs en er zijn verschillende pre-made project structuren (Persoonlijk ben ik fan van Nuxt).

Puur omdat Vue zo flexibel is maakt het voor hij heel fijn om te gebruiken. Soms heb ik simpelweg gewoon geen Axios/websockets/Vuex/Router nodig. De mogelijkheden zijn er, maar je wordt niet geforceerd om dit te gebruiken. Ideaal toch?

[Hydra]

Merlinni schreef op maandag 9 juli 2018 @ 15:10:
Door gebrek aan ervaring iets kut vinden is dan ook wel erg kort door de bocht.

Da's wel heel selectief lezen.

Puur omdat Vue zo flexibel is maakt het voor hij heel fijn om te gebruiken. Soms heb ik simpelweg gewoon geen Axios/websockets/Vuex/Router nodig. De mogelijkheden zijn er, maar je wordt niet geforceerd om dit te gebruiken. Ideaal toch?

Voor mijn behoeftes niet. Voor een 'productie' applicatie zie ik veel meer in een mature framework als Angular. Voor 'ff snel' wil ik juist dat die standaard zooi gewoon werkt en aanwezig is. Als ik al iets als Axios nodig heb om een SPA te kunnen maken is het bijna sneller gewoon met 'ng' ff een Angular app te generen. De tooling van Angular is gewoon erg goed.

Let wel; di's gewoon een persoonlijke mening en ik ben vooral een back-ender. Neem het hoe je wil, maar ik suggereer veel korrels zout

[ Voor 63% gewijzigd door Hydra op 09-07-2018 15:16 ]

[Merlinni]

Hydra schreef op maandag 9 juli 2018 @ 15:12:
[...]


Da's wel heel selectief lezen.

Vandaar de verdere onderbouwing

[Hydra]

Merlinni schreef op maandag 9 juli 2018 @ 15:14:
Vandaar de verdere onderbouwing

Was nog niet klaar, sorry

[Mugwump]

Merlinni schreef op maandag 9 juli 2018 @ 15:10:
Door gebrek aan ervaring iets kut vinden is dan ook wel erg kort door de bocht.

Als er een framework is die makkelijk te leren is (vergeleken met React en Angular) is het wel Vue. Er is een style guide in de officiële docs en er zijn verschillende pre-made project structuren (Persoonlijk ben ik fan van Nuxt).

Puur omdat Vue zo flexibel is maakt het voor hij heel fijn om te gebruiken. Soms heb ik simpelweg gewoon geen Axios/websockets/Vuex/Router nodig. De mogelijkheden zijn er, maar je wordt niet geforceerd om dit te gebruiken. Ideaal toch?

De reden dat bij ons voor VUE is gekozen is voornamelijk omdat het in tegenstelling tot Angular niet feitelijk SPA afdwingt. Dat maakt een geleidelijk migratie van de brij die er nu staat naar iets met structuur een stuk makkelijker.

[.oisyn]

Is het alweer tijd voor toetsenborden?

Op kantoor is mijn UltraX dood aan het gaan . De spatiebalk doet het slecht en de J zit los.
Ik heb nu deze als replacement: pricewatch: Cherry STREAM 3.0 Grijs (Qwerty US)

I like it . Het is praktisch hetzelfde toetsenbord. De toetsen zijn iets snappier, wat ik op zich wel prettig vindt (al zou dat ook kunnen komen door de leeftijd van mijn UltraX).

[Merlinni]

Hydra schreef op maandag 9 juli 2018 @ 15:12:
Voor mijn behoeftes niet. Voor een 'productie' applicatie zie ik veel meer in een mature framework als Angular. Voor 'ff snel' wil ik juist dat die standaard zooi gewoon werkt en aanwezig is. Als ik al iets als Axios nodig heb om een SPA te kunnen maken is het bijna sneller gewoon met 'ng' ff een Angular app te generen. De tooling van Angular is gewoon erg goed.

Mocht je het ooit nog een poging willen geven kan ik je Vue-CLI en Nuxt aanraden. Dit is eigenlijk precies waar je op doelt (als ik je goed begrijp), namelijk met 1 command een project op starten zonder zelf over structuren na hoeven te denken/packages te installeren.

Hydra schreef op maandag 9 juli 2018 @ 15:12:
Let wel; di's gewoon een persoonlijke mening en ik ben vooral een back-ender. Neem het hoe je wil, maar ik suggereer veel korrels zout

No offence taken

Ondanks dat Vue qua leeftijd lang niet zo mature is als Angular zijn er toch al heel wat tooltjes ontwikkeld om mee te gaan met de grote spelers. Zeker waard om een keer in te duiken in ieder geval!

[armageddon_2k1]

Ik heb een Udemy Angular cursus gedaan, voor de leuk. Heb al 10 jaar niks meer met web meuk gedaan en ik moet zeggen... holy shit. Wat is de wereld veranderd. Ik vind het echt fantastisch, helemaal in combinatie met iets als Firebase is het tegenwoordig allemaal heel makkelijk.

Heb ook naar Vue gekeken, maar persoonlijk ben ik altijd veel meer van een framework dat een bepaalde manier van werken afdwingt. Dan krijg je naar mijn inziens altijd frameworks die een bepaald doel veel doortastender kunnen nastreven, omdat er meer aannames gedaan kunnen worden over het gebruik door de programmeur.

Mugwump schreef op maandag 9 juli 2018 @ 15:17:
[...]


De reden dat bij ons voor VUE is gekozen is voornamelijk omdat het in tegenstelling tot Angular niet feitelijk SPA afdwingt. Dat maakt een geleidelijk migratie van de brij die er nu staat naar iets met structuur een stuk makkelijker.

Angular Universal is toch geen SPA?

[ Voor 24% gewijzigd door armageddon_2k1 op 09-07-2018 15:31 ]

[gekkie]

.oisyn schreef op maandag 9 juli 2018 @ 15:24:
Is het alweer tijd voor toetsenborden?

Op kantoor is mijn UltraX dood aan het gaan . De spatiebalk doet het slecht en de J zit los.
Ik heb nu deze als replacement: pricewatch: Cherry STREAM 3.0 Grijs (Qwerty US)

I like it . Het is praktisch hetzelfde toetsenbord. De toetsen zijn iets snappier, wat ik op zich wel prettig vindt (al zou dat ook kunnen komen door de leeftijd van mijn UltraX).

Niet heel prijzig, dus als je er eens mee rond mept is het ook niet gelijk het einde van de wereld .

[Mugwump]

armageddon_2k1 schreef op maandag 9 juli 2018 @ 15:29:
Angular Universal is toch geen SPA?

Eerlijk gezegd kende ik de Universal variant niet. Dat lijkt wel wat anders te werken, maar het ziet er nou niet echt uit als iets dat je even snel gebruikt voor geleidelijke vervanging van je bestaande codebase.

[DevWouter]

@Mugwump en @armageddon_2k1: Universal is een pre-render oplossing. Als je een pagina curlt krijg je direct de uiteindelijk HTML opmaak en wordt daarna de angular javascript gebootstrapt (en vanaf dat moment is het gewoon weer SPA).

Dit is bedacht zodat oudere crawlers die geen of slechte Javascript ondersteuning hebben er toch iets meer zien dan 8 regels HTML.

[dcm360]

Hm, is zoiets dan ook de reden waarom een browser eerst de pagina rendert, waarna deze weer verdwijnt om vervolgens weer te verschijnen? Het lijkt erop dat ik steeds meer sites tegenkom die dat gedrag vertonen namelijk.

[DevWouter]

dcm360 schreef op dinsdag 10 juli 2018 @ 14:50:
Hm, is zoiets dan ook de reden waarom een browser eerst de pagina rendert, waarna deze weer verdwijnt om vervolgens weer te verschijnen? Het lijkt erop dat ik steeds meer sites tegenkom die dat gedrag vertonen namelijk.

Nee, prerender is feitelijk op de server een browser starten die javascript ondersteunt, de pagina laadt en vervolgens de document.body.innerHtml opslaat en dat vervolgens door stuurt zodat een browser/crawler die geen javascript ondersteunt iets te zien krijgt.

Wat je beschrijft klinkt eerder een AB implementatie (VWO of https://www.google.com/analytics/optimize/) waar ze de pagina laden om vervolgens je toch snel naar een andere pagina te sturen of een paar elementen opnieuw in te laden.

Een alternatief zou een turbo-link implementatie zijn. Vaak is er dan een balk boven aan die aangeeft hoeveel content er geladen is.

Als het van die grijze blokken zonder content is (zoals hieronder) dan is het eerder een pagina waarbij ze content dynamisch geladen wordt.

[ThomasG]

dcm360 schreef op dinsdag 10 juli 2018 @ 14:50:
Hm, is zoiets dan ook de reden waarom een browser eerst de pagina rendert, waarna deze weer verdwijnt om vervolgens weer te verschijnen? Het lijkt erop dat ik steeds meer sites tegenkom die dat gedrag vertonen namelijk.

Die sites hebben dan een krakkemikkige implementatie. Het hele idee van de server side rendering is dat de initiele view, dus als je net op de site komt of na een F5, super snel is en dat je daarna seamless overgaat op de dynamische variant. Op het moment dat wat jij beschrijft gebeurt is het gewoon een slechte website.

[Mugwump]

DevWouter schreef op dinsdag 10 juli 2018 @ 12:14:
@Mugwump en @armageddon_2k1: Universal is een pre-render oplossing. Als je een pagina curlt krijg je direct de uiteindelijk HTML opmaak en wordt daarna de angular javascript gebootstrapt (en vanaf dat moment is het gewoon weer SPA).

Dit is bedacht zodat oudere crawlers die geen of slechte Javascript ondersteuning hebben er toch iets meer zien dan 8 regels HTML.

Ja, dat las ik al.
Ik bemoei mij zelf vrij weinig tegen het front end gedeelte aan, maar het gaat al lastig genoeg worden om geleidelijk stukken over te zetten naar Vue. Ik keek vandaag nog eens naar de Sonarcube analyse en die kwam met heel wat JavaScript methodes met een cognitive complexity van 100+, herdefinitie van variabelen op vele plekken, een wirwar van == en === door elkaar en ga zo maar door.

[DevWouter]

Mugwump schreef op dinsdag 10 juli 2018 @ 18:47:
Ja, dat las ik al.

Het was ter aanvulling op jouw "Dat lijkt wel wat anders te werken"

Mugwump schreef op dinsdag 10 juli 2018 @ 18:47:
Ik bemoei mij zelf vrij weinig tegen het front end gedeelte aan, maar het gaat al lastig genoeg worden om geleidelijk stukken over te zetten naar Vue. Ik keek vandaag nog eens naar de Sonarcube analyse en die kwam met heel wat JavaScript methodes met een cognitive complexity van 100+, herdefinitie van variabelen op vele plekken, een wirwar van == en === door elkaar en ga zo maar door.

Oef... Dat klinkt als een brown-field situatie die tegen het zwart aan zit. Is het niet verstandiger om eerst het kwaliteitsprobleem aan te pakken en dan pas naar Vue te migreren?

[TheNephilim]

DevWouter schreef op woensdag 11 juli 2018 @ 09:32:

[...]

Oef... Dat klinkt als een brown-field situatie die tegen het zwart aan zit. Is het niet verstandiger om eerst het kwaliteitsprobleem aan te pakken en dan pas naar Vue te migreren?

Nadeel is dat je dan wel twee keer door de code heen moet.

Wij hebben hier een PHP-project dat uit 2006 stamt en geschreven is toen we nog erg jong (en vooral onervaren) waren. Inmiddels is er een begin gemaakt om alles opnieuw te schrijven, maar dat zal nog een flinke klus worden.

Wel leuk om te zien hoe flinke lappen met code ineens veel compacter eruit rollen in de nieuwe versie. Idee is dat alles straks hetzelfde werkt voor de gebruiker, die moet eigenlijk geen verschil merken, gewoon 1-op-1 de features overnemen.

[Mugwump]

DevWouter schreef op woensdag 11 juli 2018 @ 09:32:
[...]

Oef... Dat klinkt als een brown-field situatie die tegen het zwart aan zit. Is het niet verstandiger om eerst het kwaliteitsprobleem aan te pakken en dan pas naar Vue te migreren?

Het ergste is nog dat dit in de basis een greenfield project was. Ik heb de back end volledig vanaf scratch opgezet in Azure. De front end integreert wel in een bestaande oplossing, maar is feitelijk een volkomen geïsoleerde .Net MVC oplossing. Het is zo'n typisch voorbeeld van een project dat van greenfield naar brownfield gaat in slechts enkele maanden door een clubje heel, heel matige developers.

We heben de front end lead er uitgeknikkerd en het team een kwaliteitsimpuls gegeven, dus dat gaat wel goedkomen. De huidige codebase zit vol met bugs en staat nog niet eens in productie ondanks een 'agile' aanpak. De vorige lead vertikte het namelijk ook om de helft van de bugs die hij voor zijn kiezen kreeg op te lossen omdat hij vond dat gezond verstand maar gespecificeerd had moeten worden.
Ik zou gewoon bij het raken van bestaande functionaliteit refactoring / migratie naar Vue meenemen. Een tweestapsaanpak is eerder gewoon dubbel werk.

[armageddon_2k1]

TheNephilim schreef op woensdag 11 juli 2018 @ 10:29:
[...]
Idee is dat alles straks hetzelfde werkt voor de gebruiker, die moet eigenlijk geen verschil merken, gewoon 1-op-1 de features overnemen.

<knuppel in hoenderhok>
Waarom doe je het dan? Herschrijven leidt sowieso tot nieuwe bugs die je nooit hebt gezien en voor de gebruiker wordt de functionaliteit dus tijdelijk minder. Het feit dat het een hele oude codebase is doet vermoeden dat er geen goed test-set is en dus ook niet goed te checken is of de meeste functionaliteit echt hetzelfde werkt.

Daarnaast, veel € verbranden voor geen verbetering naar de user.
</knuppel>

[ Voor 6% gewijzigd door armageddon_2k1 op 11-07-2018 11:23 ]

[Verwijderd]

.

[ Voor 94% gewijzigd door Verwijderd op 11-07-2018 11:26 ]

[TheNephilim]

armageddon_2k1 schreef op woensdag 11 juli 2018 @ 11:21:
[...]


<knuppel in hoenderhok>
Waarom doe je het dan? Herschrijven leidt sowieso tot nieuwe bugs die je nooit hebt gezien en voor de gebruiker wordt de functionaliteit dus tijdelijk minder. Het feit dat het een hele oude codebase is doet vermoeden dat er geen goed test-set is en dus ook niet goed te checken is of de meeste functionaliteit echt hetzelfde werkt.

Daarnaast, veel € verbranden voor geen verbetering naar de user.
</knuppel>

Met de applicatie zoals hij er nu bij staat kunnen we niks, als in nieuwe dingen toevoegen, bugs oplossen, dat willen we oplossen door alles opnieuw te schrijven. De hele zwik staat niet in versiebeheer en het lukt eigenlijk ook niet om het op onze ontwikkelmachines aan de praat te krijgen. Het is niet eens vrij ingewikkeld allemaal wat er gebeurd in de applicatie, dus we verwachten dat het schrijven van feature tests al een boel problemen kan opvangen.

Die verbetering voor de gebruiker komt daarna, maar we willen voorkomen te verzanden in nieuwe features voordat we alle functionaliteit geport hebben. Daarnaast willen we de schare trouwe gebruikers niet afschrikken door een compleet anders werkende applicatie. Dat willen we daarna geleidelijk aan oppakken. Het enige wat we wel meteen gaan doen is alles responsive maken. Op dit moment is het eigenlijk nauwelijks te gebruiken op tablet, laat staan telefoon.

[DevWouter]

TheNephilim schreef op woensdag 11 juli 2018 @ 10:29:
Nadeel is dat je dan wel twee keer door de code heen moet.

Je zult altijd meerdere keren door dezelfde code heen gaan. Door het eerst op te ruimen zorg je ervoor dat de migratie naar een nieuw framework makkelijker gaat en de kans op nieuwe bugs kleiner is.
Mochten er dusdanig veel bugs zijn dat het product al "half-kapot" is dan wordt het natuurlijk een ander verhaal (zoals wat Mugwump beschrijft).

Mugwump schreef op woensdag 11 juli 2018 @ 11:00:
Het ergste is nog dat dit in de basis een greenfield project was. Ik heb de back end volledig vanaf scratch opgezet in Azure. De front end integreert wel in een bestaande oplossing, maar is feitelijk een volkomen geïsoleerde .Net MVC oplossing. Het is zo'n typisch voorbeeld van een project dat van greenfield naar brownfield gaat in slechts enkele maanden door een clubje heel, heel matige developers.

We heben de front end lead er uitgeknikkerd en het team een kwaliteitsimpuls gegeven, dus dat gaat wel goedkomen. De huidige codebase zit vol met bugs en staat nog niet eens in productie ondanks een 'agile' aanpak. De vorige lead vertikte het namelijk ook om de helft van de bugs die hij voor zijn kiezen kreeg op te lossen omdat hij vond dat gezond verstand maar gespecificeerd had moeten worden.
Ik zou gewoon bij het raken van bestaande functionaliteit refactoring / migratie naar Vue meenemen. Een tweestapsaanpak is eerder gewoon dubbel werk.

Mee eens, hier heb je een situatie waarbij het product al dusdanig kapot is dat je de vraag kan stellen of het niet sneller is om opnieuw te beginnen. Vaak ga ik hier de code opsplitsen in verschillende onderdelen om vervolgens per onderdeel het volledig te herschrijven.

[armageddon_2k1]

Mugwump schreef op woensdag 11 juli 2018 @ 11:00:
[...]


Het ergste is nog dat dit in de basis een greenfield project was. Ik heb de back end volledig vanaf scratch opgezet in Azure. De front end integreert wel in een bestaande oplossing, maar is feitelijk een volkomen geïsoleerde .Net MVC oplossing. Het is zo'n typisch voorbeeld van een project dat van greenfield naar brownfield gaat in slechts enkele maanden door een clubje heel, heel matige developers.

Dit snap ik niet. Ik lees termen Greenfield en Brownfield en die ken ik vanuit engineering (niet software, maar massa consumenten producten) projecten. Kijkend naar wat ik kan vinden hierover op software dev gebied snap ik niet helemaal hoe je van Greenfield naar Brownfield kan gaan. In essentie is Greenfield op een heel nieuwe basis en Brownfield is op bestaande basis of in ieder geval naast een bestaande basis. Als je from scratch begint kan je per definitie niet naar Brownfield gaan. Een opvolgproject dat voortborduurd op je Greenfield project is dan wel Brownfield.

Maar dan nog... de indruk word gewekt dat Greenfield beter is dan Brownfield, maar, zeker in mijn wereld, lijkt het tegenovergestelde vaak waar te zijn. Het 'wiel opnieuw uitvinden' en 'NIH' zijn er mooie voorbeelden van.

A good way to measure the success or failure of a development effort is the time required before the accumulated advantages provided by the system equal the time and expense invested.

Using this measurement, brownfield development clearly provides the most ROI. Greenfield projects must be completed, installed, and new business processes implemented before they can begin bringing value to the company. Elapsed time and investment necessary before the first derived advantage is given can be measured in years and hundreds of thousands of dollars. Furthermore, the entire investment must be made before any return is seen. If it turns out that the project is misguided in some way, this won’t be discovered until the entire budget is spent.

Brownfield development, however, provides a much shorter timeframe to payback since new features and architectural enhancements can be rolled out along the way. Often the first improvements can be pushed out to users within a few weeks of the start of a project. Whether these improvements are additional features, performance improvements, or internal architectural enhancements, can be decided by the development team, but whatever is scheduled first can be in production and providing value quickly.

[Mugwump]

armageddon_2k1 schreef op woensdag 11 juli 2018 @ 13:02:
[...]


Dit snap ik niet. Ik lees termen Greenfield en Brownfield en die ken ik vanuit engineering (niet software, maar massa consumenten producten) projecten. Kijkend naar wat ik kan vinden hierover op software dev gebied snap ik niet helemaal hoe je van Greenfield naar Brownfield kan gaan. In essentie is Greenfield op een heel nieuwe basis en Brownfield is op bestaande basis of in ieder geval naast een bestaande basis. Als je from scratch begint kan je per definitie niet naar Brownfield gaan. Een opvolgproject dat voortborduurd op je Greenfield project is dan wel Brownfield.

Dat is ook precies waar ik het hier over heb. Er is met niets begonnen. We zitten nu weliswaar nog steeds in hetzelfde project op papier, maar door de architecturele heroverwegingen zitten we met een 'bestaand systeem' dat geleidelijk aan herschreven moet worden. Je hebt dus een bestaand project als uitgangssituatie.

Maar dan nog... de indruk word gewekt dat Greenfield beter is dan Brownfield, maar, zeker in mijn wereld, lijkt het tegenovergestelde vaak waar te zijn. Het 'wiel opnieuw uitvinden' en 'NIH' zijn er mooie voorbeelden van.

Dat hoeft niet zo te zijn, maar dat is in de praktijk helaas wel zo. Software-ontwikkeling mag zichzelf graag een ingenieursvak noemen (zeg ik als Ir. in de software engineering), maar in de praktijk heeft het weinig van doen met een brug of een auto ontwerpen en bouwen / produceren. Daar zijn hele boeken over volgeschreven. Je haalt een stuk software niet even door gestandaardiseerde tests om de kwaliteit te bepalen zoals je met ontwerpen, prototypes en testmodellen in veel ingenieursdisciplines wel doet.
Ik zou ook nog wel eens een succesvolle brug gebouwd willen zien worden als men op een kwart van het project besluit dat de brug moet eindigen op punt C in plaats van punt B, na een half jaar toch liever op punt D, de welstandcommissie ondertussen besluit dat de brug toch te hoog is en tot horizonvervuiling lijkt, de betonnen voeten geen gezicht zijn en vervangen moeten worden door iets anders en ga zo maar door.

In een goed opgezet brownfield project valt prima te werken. Maar dat betekent vaak ook wel dat er steeds wordt doorontwikkeld en ook verouderde technologieën worden vervangen, nieuwe ontwikkelaars worden ingewerkt en dus weten wat de verschillende onderdelen doen en waar ze te vinden zijn en ga zo maar door. Dat valt dus in de praktijk behoorlijk tegen.

[DevWouter]

armageddon_2k1 schreef op woensdag 11 juli 2018 @ 13:02:
Dit snap ik niet. Ik lees termen Greenfield en Brownfield en die ken ik vanuit engineering (niet software, maar massa consumenten producten) projecten. Kijkend naar wat ik kan vinden hierover op software dev gebied snap ik niet helemaal hoe je van Greenfield naar Brownfield kan gaan.

In de software wereld kan het verschillende dingen beteken: Legacy code (zowel in goede als slechte kwaliteit), slechte infrastructuur, afhankelijkheid aan een derde partij, geen tests/documentatie, lage kwaliteit en zo voorts.

Persoonlijk vergelijk ik het met een grasveld.
Wil je er een stadium van maken? Greenfield.
Wil je een bulldozer huren? Brownfield.

Het beste is om de term te vermijden... En ja, ik ben me bewust dat ik er mee begon.

[armageddon_2k1]

Dus, Greenfield = mooie code, goede tests, mooie architectuur. Brownfield = smerige shite.
:-)

[Mugwump]

armageddon_2k1 schreef op woensdag 11 juli 2018 @ 20:09:
Dus, Greenfield = mooie code, goede tests, mooie architectuur. Brownfield = smerige shite.
:-)

Nee, Greenfield = er staat nog niets, je hebt alle ruimte om mooie code / tests / architectuur op te zetten, brownfield = er zijn ongetwijfeld mensen geweest die mooie code / tests / architectuur neer hebben willen zetten, maar die zijn daar niet in geslaagd.

[orf]

Is het weer eens tijd voor Joel on software?

[armageddon_2k1]

@orf Juist, daar dacht ik dus ook aan ;-)

[Verwijderd]

armageddon_2k1 schreef op woensdag 11 juli 2018 @ 20:09:
Dus, Greenfield = mooie code, goede tests, mooie architectuur. Brownfield = smerige shite.
:-)

Die termen slaan echt als een tang op een varken.

[Mugwump]

orf schreef op woensdag 11 juli 2018 @ 20:15:
Is het weer eens tijd voor Joel on software?

Dan gooi ik er een Martin Fowler tegenaan.

[F.West98]

En als toetje dan nog een XKCD: https://xkcd.com/844/

[Neko Koneko]

.oisyn schreef op maandag 9 juli 2018 @ 15:24:
Is het alweer tijd voor toetsenborden?

Op kantoor is mijn UltraX dood aan het gaan . De spatiebalk doet het slecht en de J zit los.
Ik heb nu deze als replacement: pricewatch: Cherry STREAM 3.0 Grijs (Qwerty US)

I like it . Het is praktisch hetzelfde toetsenbord. De toetsen zijn iets snappier, wat ik op zich wel prettig vindt (al zou dat ook kunnen komen door de leeftijd van mijn UltraX).

Toetsenbord openschroeven en gewoon eens goed schoonmaken is geen optie?

[ThomasG]

Neko Koneko schreef op donderdag 12 juli 2018 @ 09:06:
[...]


Toetsenbord openschroeven en gewoon eens goed schoonmaken is geen optie?

Een beetje lijm doet wonderen. Dan zitten de toetsen niet meer los.

[Sandor_Clegane]

armageddon_2k1 schreef op woensdag 11 juli 2018 @ 20:09:
Dus, Greenfield = mooie code, goede tests, mooie architectuur. Brownfield = smerige shite.
:-)

Elke brownfield is ooit begonnen als een greenfield.

[.oisyn]

Neko Koneko schreef op donderdag 12 juli 2018 @ 09:06:
[...]


Toetsenbord openschroeven en gewoon eens goed schoonmaken is geen optie?

Hoe denk je dat ik het zo lang heb uitgehouden?

Bij de J is er een pikkie afgebroken van de scissor, dus die blijft niet goed op z'n plek. Maar ik zou de scissor natuurlijk prima kunnen vervangen of verwisselen met een andere toets die ik amper gebruik. Bij de spatiebalk werkt het membraan op de printplaat niet helemaal lekker meer. Ik had al geprobeerd om 'm iets te verdikken op de plek waar de dome de toets raakt zodat ik 'm minder diep in hoef te drukken, maar ik blijf aanslagen missen die ik aan de rand van de spatiebalk doe.

Maar, om heel eerlijk te zijn, ik vind deze Cherry echt een stuk lekkerder typen. Er is iets meer kracht nodig en ze maken een duidelijkere klik. Ik denk dat ik mijn UltraX thuis ook maar preventief vervang (en misschien een lading extra toetsenborden insla voor als deze ook niet meer wordt geproduceerd ). I love it

[ Voor 3% gewijzigd door .oisyn op 12-07-2018 11:16 ]

[Matis]

Pff, de laatste weken doet de Mijn ING-website icm Lastpass extensie in Chrome het niet meer

De CPU gaat naar 100% en daar blijft het dan bij. De enige manier om de CPU weer rustig te krijgen is door het tabblad af te sluiten of de extensie de nek om te draaien.
De problemen manifesteren zich zowel op mijn Ubuntu 18.04 en Windows 10 systeem.

Ik weet niet wie van de twee ik de schuld moet geven, maar bloedirritant is het wel... Het is in ieder geval gekomen sinds ING over is op het nieuwe thema / layout.

De enige manier om nu op een desktop in te loggen op Mijn ING is door eerst de LastPass vault te openen, daar op zoek te gaan naar de inloggegevens van Mijn ING, deze te kopiëren, om ze vervolgens in een tekstbestand te plakken. Vanuit daar kan ik dan de gebruikersnaam en wachtwoord in de webpagina invullen en inloggen.

[Sandor_Clegane]

Matis schreef op zaterdag 14 juli 2018 @ 11:18:
Pff, de laatste weken doet de Mijn ING-website icm Lastpass extensie in Chrome het niet meer

De CPU gaat naar 100% en daar blijft het dan bij. De enige manier om de CPU weer rustig te krijgen is door het tabblad af te sluiten of de extensie de nek om te draaien.
De problemen manifesteren zich zowel op mijn Ubuntu 18.04 en Windows 10 systeem.

Ik weet niet wie van de twee ik de schuld moet geven, maar bloedirritant is het wel... Het is in ieder geval gekomen sinds ING over is op het nieuwe thema / layout.

De enige manier om nu op een desktop in te loggen op Mijn ING is door eerst de LastPass vault te openen, daar op zoek te gaan naar de inloggegevens van Mijn ING, deze te kopiëren, om ze vervolgens in een tekstbestand te plakken. Vanuit daar kan ik dan de gebruikersnaam en wachtwoord in de webpagina invullen en inloggen.

Daar was toch een post over? ING heeft de inlogpagina aangepast zodat password managers niet meer werken.

nieuws: ING gaat na of zijn Chrome-inlogpagina weer wachtwoordmanagers kan on...

[Matis]

Sandor_Clegane schreef op zaterdag 14 juli 2018 @ 11:21:
Daar was toch een post over? ING heeft de inlogpagina aangepast zodat password managers niet meer werken.

nieuws: ING gaat na of zijn Chrome-inlogpagina weer wachtwoordmanagers kan on...

Die was ik op mijn zoektocht naar de bron van het probleem nog niet tegengekomen.

Wat een ontzettende slechte zaak en wat een drogredenen worden er door de ING gegeven om het probleem te bagatelliseren...

[ThomasG]

Gewoon geen Chrome gebruiken Als er een applicatie resource hungry is dat eigenlijk niet in verhouding staat tot wat het doet, dan is het Chrome wel.

[Matis]

ThomasG schreef op zaterdag 14 juli 2018 @ 11:40:
Gewoon geen Chrome gebruiken Als er een applicatie resource hungry is dat eigenlijk niet in verhouding staat tot wat het doet, dan is het Chrome wel.

Ik zal de laatste zijn die ontkent dat Chrome onzuinig met zijn resources omgaat, maar ik vind het een fijne browser.
De systemen waarop het draait, hebben toch genoeg geheugen voor Chrome.

[Alex)]

ThomasG schreef op zaterdag 14 juli 2018 @ 11:40:
Gewoon geen Chrome gebruiken Als er een applicatie resource hungry is dat eigenlijk niet in verhouding staat tot wat het doet, dan is het Chrome wel.

Hetzelfde kan gezegd worden over alle applicaties die gebouwd worden op Electron.

[Lye]

Alex) schreef op zaterdag 14 juli 2018 @ 14:06:
[...]

Hetzelfde kan gezegd worden over alle applicaties die gebouwd worden op Electron.

Dat komt toch op hetzelfde neer, Electron gebruikt toch ook Chromium/Blink voor de rendering?

[Alex)]

Lye schreef op zaterdag 14 juli 2018 @ 14:56:
[...]


Dat komt toch op hetzelfde neer, Electron gebruikt toch ook Chromium/Blink voor de rendering?

Yep.

[gold_dust]

orf schreef op woensdag 11 juli 2018 @ 20:15:
Is het weer eens tijd voor Joel on software?

Daar ben ik het niet mee eens, software heeft absoluut een maximale houdbaarheidsdatum. Om verschillende redenen, zoals ontwikkeling van talen en frameworks op zich maar ook omdat veel software simpelweg niet gedocumenteerd is, schaalbaar of onderhoudbaar is opgezet, of dat een onderliggend design totaal ontbreekt. Er lopen nogal wat prutsers in de software industrie rond.

Op een gegeven moment moet je gewoon een code freeze instellen, opnieuw beginnen en de oude software uitfaseren. Persoonlijk ga ik me de vingers niet meer branden aan legacy code, ik wijs ook projecten om die reden af.

Er bestaan inderdaad vandaag nog bijvoorbeeld Unix commando's met code uit de jaren '70 maar dat is eerder uitzondering dan regel.

Die Joel heeft soms best wel een punt maar veel van z'n posts raken kant nog wal. Bovendien is er nogal wat verandert sinds het jaar 2000 toen hij die post schreef. Ik zou iemand met een bedrijf dat een bugtracking tooltje op de markt heeft/had nou niet als autoriteit zien omtrent alles wat met software ontwikkeling te maken heeft, ook al profileert hij zichzelf wel zo.

[armageddon_2k1]

@gold_dust Trello is ook van hem geloof ik. Prima tool.

[Sebazzz]

Alex) schreef op zaterdag 14 juli 2018 @ 14:06:
[...]

Hetzelfde kan gezegd worden over alle applicaties die gebouwd worden op Electron.

Dat komt doordat alles in een seperaat process moet. Je kan beargumenteren dat dat voor Electron apps een stuk minder belangrijjk is.

[Mugwump]

Er valt best wat voor te zeggen dat developers wel heel snel geneigd zijn om te zeggen "begin maar weer helemaal overnieuw". Ik heb ook genoeg projecten gedaan waar je met de kennis die je aan het eind van het project hebt over wat de klant / business nu eigenlijk wil je bij nader inzien het systeem heel anders had willen opzetten. Dat is dan meestal geen optie. Als je een goede set regressietests hebt opgebouwd kun je bij het implementeren van nieuwe features wel wat structurele herbouw meenemen.

Ik had onlangs echter een klusje om een stuk software van een collega flink aan te pakken. Daar zaten weer eens exact 0 tests bij, er was geen documentatie en ga zo maar door. De opzet was echt volkomen idioot qua architectuur. Men had gekozen voor Azure functions. Een eerste stap in het verwerkingsproces van data was bestanden van een SFTP overbrengen naar cloud storage.
Dat was geïmplementeerd met drie functies. De eerste pollde een SFTP voor nieuwe bestanden, zette deze op het lokale filesysteem van de function, zette metadata in een database en een berichtje met een verwijzing naar de metadata op een message queue.
De tweede functie ontving het berichtje, las de metadata uit de database, kopieerde het bestand van lokale filesysteem naar cloud storage, werkte metadata bij en zette weer een berichtje met verwijzing naar metadata op een andere queue voor verdere verwerking.
Dan draaide er nog een derde functie die periodiek de metadata pollde om te kijken of er bestanden succesvol waren gekopieerd waarna deze werden verwijderd van de SFTP.

Dat hele stuk code heb ik maar genegeerd en ik heb een functie van een paar regels code geschreven die een bestand kopieert, het het verwijdert van de SFTP en een berichtje op een queue zet voor verdere verwerking.

[farlane]

gold_dust schreef op zondag 15 juli 2018 @ 10:36:
[...]
Ik zou iemand met een bedrijf dat een bugtracking tooltje op de markt heeft/had nou niet als autoriteit zien omtrent alles wat met software ontwikkeling te maken heeft, ook al profileert hij zichzelf wel zo.

.... For my day job, I’m the CEO (and co-founder) of Stack Overflow...

[Firesphere]

gold_dust schreef op zondag 15 juli 2018 @ 10:36:
[...]

Die Joel heeft soms best wel een punt maar veel van z'n posts raken kant nog wal. Bovendien is er nogal wat verandert sinds het jaar 2000 toen hij die post schreef. Ik zou iemand met een bedrijf dat een bugtracking tooltje op de markt heeft/had nou niet als autoriteit zien omtrent alles wat met software ontwikkeling te maken heeft, ook al profileert hij zichzelf wel zo.

Heb je enig idee wie Joel Spolsky is? Je zou misschien even die naam kunnen DuckDuckGoen?

[Crazy D]

farlane schreef op zondag 15 juli 2018 @ 11:27:
[...]




[...]

CEO en co-founder van de grootste helpfile op internet geeft vooral aan dat ie een goed idee heeft gehad, niet dat ie alles van software ontwikkeling weet

[farlane]

Crazy D schreef op maandag 16 juli 2018 @ 08:25:
[...]

CEO en co-founder van de grootste helpfile op internet geeft vooral aan dat ie een goed idee heeft gehad, niet dat ie alles van software ontwikkeling weet

Programmeerhelpfile, dat dan weer wel. Maar je hebt gelijk.

[Mugwump]

Firesphere schreef op maandag 16 juli 2018 @ 06:51:
[...]

Heb je enig idee wie Joel Spolsky is? Je zou misschien even die naam kunnen DuckDuckGoen?

Verantwoordelijk voor VBA. Staatsvijand #1 zou ik zeggen.

[ThomasG]

Mugwump schreef op maandag 16 juli 2018 @ 08:47:
[...]


Verantwoordelijk voor VBA. Staatsvijand #1 zou ik zeggen.

Het idee achter VBA is zo slecht nog niet. Het is alleen de uitwerking dat gewoon ruk is. Zoals dat het in de meeste gevallen totaal niet meer werkt als je het op een ander systeem zet, vooral als het een andere locale heeft. Netzoals dat Excel kapot gaat al je een excel met formules in een Nederlands Excel maakt, en je het opent op een Engels Excel.

[gold_dust]

farlane schreef op zondag 15 juli 2018 @ 11:27:
[...]

Want CEO's staan algemeen bekend om hun goede programmeerkennis? Als CEO heeft hij misschien wel 10 jaar al geen IDE opgestart. Ik kom regelmatig bij gebrek aan beter, sommige weken dagelijks, op stackoverflow en letterlijk alle vragen die gesteld zijn en die ik ook had kunnen stellen zijn door de %^&* moderatoren gesloten. Wat een waardeloze site is dat geworden.

Your logical fallacy is: appeal to authority.

[Matis]

gold_dust schreef op maandag 16 juli 2018 @ 09:35:
Your logical fallacy is: appeal to authority.

Dat is een blijvertje

[Mugwump]

ThomasG schreef op maandag 16 juli 2018 @ 09:35:
[...]
Het idee achter VBA is zo slecht nog niet. Het is alleen de uitwerking dat gewoon ruk is. Zoals dat het in de meeste gevallen totaal niet meer werkt als je het op een ander systeem zet, vooral als het een andere locale heeft. Netzoals dat Excel kapot gaat al je een excel met formules in een Nederlands Excel maakt, en je het opent op een Engels Excel.

Waarmee je dus feitelijk zegt dat Joel best leuke ideeën heeft, maar weinig verstand van concrete implementatie.

spoiler:

Geintje natuurlijk.

[Neko Koneko]

.oisyn schreef op donderdag 12 juli 2018 @ 10:18:
[...]


Hoe denk je dat ik het zo lang heb uitgehouden?

Bij de J is er een pikkie afgebroken van de scissor, dus die blijft niet goed op z'n plek. Maar ik zou de scissor natuurlijk prima kunnen vervangen of verwisselen met een andere toets die ik amper gebruik. Bij de spatiebalk werkt het membraan op de printplaat niet helemaal lekker meer. Ik had al geprobeerd om 'm iets te verdikken op de plek waar de dome de toets raakt zodat ik 'm minder diep in hoef te drukken, maar ik blijf aanslagen missen die ik aan de rand van de spatiebalk doe.

Maar, om heel eerlijk te zijn, ik vind deze Cherry echt een stuk lekkerder typen. Er is iets meer kracht nodig en ze maken een duidelijkere klik. Ik denk dat ik mijn UltraX thuis ook maar preventief vervang (en misschien een lading extra toetsenborden insla voor als deze ook niet meer wordt geproduceerd ). I love it

Oh, je komt van een toetsenbord met scissorswitches, dan kan ik wel begrijpen dat je iets anders zoekt

Ik wou dat er betaalbare ergonomische toetsenborden met mechanische switches waren ik ben op zich een groot fan van de Microsoft ergnonomische toetsenborden maar met mechanische switches zouden ze nog beter zijn.

[.oisyn]

Neko Koneko schreef op maandag 16 juli 2018 @ 09:49:
[...]


Oh, je komt van een toetsenbord met scissorswitches, dan kan ik wel begrijpen dat je iets anders zoekt

Dit is ook een tobo met scissor switches . Voor mij niets anders.

[ThomasG]

.oisyn schreef op maandag 16 juli 2018 @ 09:51:
[...]

Dit is ook een tobo met scissor switches . Voor mij niets anders.

Toch doet jouw avatar anders vermoeden

[DevWouter]

gold_dust schreef op zondag 15 juli 2018 @ 10:36:
[...]
Die Joel heeft soms best wel een punt maar veel van z'n posts raken kant nog wal. Bovendien is er nogal wat verandert sinds het jaar 2000 toen hij die post schreef. Ik zou iemand met een bedrijf dat een bugtracking tooltje op de markt heeft/had nou niet als autoriteit zien omtrent alles wat met software ontwikkeling te maken heeft, ook al profileert hij zichzelf wel zo.

Je had dit stuk beter weg kunnen laten. Door het "aanvallen van een persoon" loop je het risico dat andere mensen die persoon willen "verdedigen" met als resultaat dat je discourse krijgt. Jammer, want de overige 66% van jouw post was wel on-topic.

gold_dust schreef op zondag 15 juli 2018 @ 10:36:
[...]

Daar ben ik het niet mee eens, software heeft absoluut een maximale houdbaarheidsdatum. Om verschillende redenen, zoals ontwikkeling van talen en frameworks op zich maar ook omdat veel software simpelweg niet gedocumenteerd is, schaalbaar of onderhoudbaar is opgezet, of dat een onderliggend design totaal ontbreekt. Er lopen nogal wat prutsers in de software industrie rond.

Op een gegeven moment moet je gewoon een code freeze instellen, opnieuw beginnen en de oude software uitfaseren. Persoonlijk ga ik me de vingers niet meer branden aan legacy code, ik wijs ook projecten om die reden af.

Er bestaan inderdaad vandaag nog bijvoorbeeld Unix commando's met code uit de jaren '70 maar dat is eerder uitzondering dan regel.

Software heeft in mijn ogen geen maximale houdbaarheidsdatum. Software wordt gebruikt om een specifieke oplossing aan te bieden en een oplossing heeft wel een houdbaarheidsdatum. Over tijd kunnen de eisen, zowel functioneel als technologisch, veranderen waardoor het zijn waarde verliest.

Maar wat jij beschrijft klinkt ook meer als "code" en ook daar ben ik het niet mee eens om dezelfde reden als hier boven. Zolang de eisen niet veranderen hoeft de oplossing ook niet te veranderen.

Als voorbeelden draag je aan gebrek aan schaalbaarheid en gebrek aan onderhoudbaarheid. Echter als we er van uit gaan dat de bestaande oplossing voldoende was, dan is zou er geen noodzaak zijn om op te schalen of om de code te onderhouden. Echter als je de code moet gaan onderhouden of het systeem moet opschalen dan heeft dat vaak een reden en dus kunnen we er van uit gaan de eisen verandert zijn.

Gebrek aan documentatie en gebrek aan design zijn vaak argumenten die pas bij het aanpassen naar van de code naar boven komen. Mogelijk dat zij een oorzaak zijn, maar als we weer van uitgaan dat de software ten tijde van acceptatie goedgekeurd was dan kan kunnen we dat uitsluiten. De kans is groter dat door de wijziging van eisen het toen gekozen ontwerp onvoldoende is. We weten allemaal hoe ontwikkelaars reageren wanneer ze te horen krijgen dat het eisen pakket gewijzigd is.

Tot dus ver de punten waar ik het met je oneens ben.

Er zijn echter ook scenario's waarbij een complete rewrite te verdedigen is:
- De kosten voor het aanpassen van een bestaande oplossing zijn een veelvoud van een nieuwe oplossing. Vaak lopen de kosten van nieuwbouw dusdanig uit dat achteraf gezien het juist nadelig is.
- Er kan een substantieel functionele wijziging zijn in de eisen waardoor de bestaande oplossing niet als basis gebruikt kan worden. Persoonlijk zie ik dat eerder als een nieuw product waarbij men vaak verwijst naar de eisen van het andere product (denk mspaint die ook SVG moet gaan ondersteunen).
- Er kan een technische wijziging zijn in de eisen waardoor de bestaande oplossing niet gebruikt kan worden. Dat is zeer zeldzaam voor een complete rewrite omdat een partial rewrite vaak het probleem oplost (denk aan porten naar een ander OS).
- Volledig gebrek aan kennis en geen budget om de kennis op te bouwen. Eigenlijk is dit het kostenplaatje argument weer, maar deze behandelt het design/documentatie probleem specifiek. In mijn beleving is dat een lose-lose scenario omdat je verantwoordelijk bent voor het iets te bouwen waar geen kennis voor is en waarbij de eis vaak is "zoals het nu is, maar dan in project/taal/framework/etc". Zonder kennis van het bestaande systeem is de kans groot dat je iets anders maakt dan nodig is.

TL;DR: Een complete rewrite is zelden nodig tenzij de eisen dusdanig veranderen dat er geen gebruik gemaakt kan worden van de code van de bestaande oplossing. Vaak is een partial rewrite beter en goedkoper.

[alienfruit]

Soms herschrijven wij gedeelten van projecten voornamelijk omdat SAP nu de mogelijkheid ingebouwd heeft en zodoende vervolgens SAP's zijn zorg is

[ThomasG]

DevWouter schreef op maandag 16 juli 2018 @ 10:11:
[...]

TL;DR: Een complete rewrite is zelden nodig tenzij de eisen dusdanig veranderen dat er geen gebruik gemaakt kan worden van de code van de bestaande oplossing. Vaak is een partial rewrite beter en goedkoper.

Dat is natuurlijk zo als je er vanuit gaat dat er goede code geschreven is; dus niet of het voldoet aan de (gewijzigde) requirements, maar of het onderhoudbaar is e.d. Helaas kom ik geregeld nog de beroemde spagetti code tegen, en om dat te gaan refactoren kost minstens net zoveel - zo niet meer - tijd en geld als (delen) volledig herschirjven.

[farlane]

gold_dust schreef op maandag 16 juli 2018 @ 09:35:
Your logical fallacy is: appeal to authority.

It's important to note that this fallacy should not be used to dismiss the claims of experts, or scientific consensus. Appeals to authority are not valid arguments, but nor is it reasonable to disregard the claims of experts who have a demonstrated depth of knowledge unless one has a similar level of understanding and/or access to empirical evidence.

Dus wat mij betreft ligt de burden of proof bij jou wat betreft de claim dat hij geen autoriteit is.