[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
JavaScript heeft denk ik in (relatief) korte tijd wel een enorme verandering ondergaan. Je ziet nu dat bepaalde zaken weer gestandaardiseerd worden, denk aan WebComponents bijv.gekkie schreef op donderdag 18 oktober 2018 @ 14:39:
Is het meeste rond javascript niet buitengewoon adhocerig tot stand gekomen ?
En in het kader van de discussie een tijdje terug over ICT en bouwknudde, vandaag het rapport van de OVV openbaar, laat de ICT alsjeblieft niks meer leren van zogenaamde "echte" "engineering", wat een puinbak van voor tot achter, van aanbesteding, ontwerp, uitvoering, toezicht tot en met de post-mortem analyse voor de aannemer zelf (middels TNO en ingenieursbureau) een en al wensdenken.
Hmmm als je weer eens wat anders doet van Python, ontdek je hoeveel convenience je daar eigenlijk wel niet hebt (nu met golang bezig), de prijs in performance overigens ook
[ Voor 12% gewijzigd door gekkie op 18-10-2018 15:52 ]
Ohja, en dat je dan npm install wilt doen maar faalt omdat gyp built met de verkeerde versie van pythonGamesMaxed schreef op donderdag 18 oktober 2018 @ 15:53:
Python heeft nochtans meer problemen dan node wanneer het om ecosysteem gaat. Pip, pyenv, setuptools, pipenv, venv, ...

Sowieso:
WTFquote: https://gyp.gsrc.ioGYP is a Meta-Build system: a build system that generates other build systems.
*whoot* nog een build-system, dat is ook wel een plaag aan het worden.
Afgelopen week nog lopen hannesen met "bazel" (mjah tensorflow ..) gezeik om het ding aan de praat te houden met limited resources.
Was er maar een meta-meta-build-system om meta-build-systems mee te builden, dan had je dat soort problemen niet!Ed Vertijsment schreef op donderdag 18 oktober 2018 @ 15:56:
[...]
Ohja, en dat je dan npm install wilt doen maar faalt omdat gyp built met de verkeerde versie van python.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Er gaat niets boven een beetje symbool politiekSociale media zoals Twitter, Reddit, Tumblr en Imgur zijn uitgesloten van geplande wetgeving in Groot-Brittannië die van pornowebsites vereist dat zij de leeftijd van hun bezoekers verifiëren.
De leeftijdscontrole geldt niet voor websites waarvan minder dan een derde van de inhoud bestaat uit pornografisch materiaal, staat in een voorstel van de Britse overheid, meldt The Guardian. Ook gratis pornowebsites hoeven de controle niet uit te voeren.

Naja in ieder geval mensen die deze al van nature hebben: https://www.curbed.com/20...human-blinders-wear-space
[ Voor 10% gewijzigd door gekkie op 18-10-2018 20:11 ]
Verwijderd
Nou dan maken die betaalde sites een pagina met 2x zoveel kattenfilmpjes en dan hoeven ze het ook niet te controleren.gekkie schreef op donderdag 18 oktober 2018 @ 16:46:
[...]
Er gaat niets boven een beetje symbool politiek, alsof zo'n puisterige puber er ook nog voor zou gaan betalen ook
.
Naja in ieder geval mensen die deze al van nature hebben: https://www.curbed.com/20...human-blinders-wear-space
Dan kun je op Twitter wel claimen: "We hebben een uiterst ongelukkig getimed conflict met onze website voor de #ESNS19 kaartverkoop.", maar mij houd je niet voor de gek.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Dat is wel jammer, wel complimenten voor het eruit wippen van Ticketmaster, wat een stelletje schurken zijn dat. Ben nog steeds sneu dat ik geen Radiohead tickets heb kunnen krijgen, stelletje fuckers.Mugwump schreef op vrijdag 19 oktober 2018 @ 10:58:
Eurosonic Noorderslag had dit jaar besloten om voor de kaartverkoop Ticketmaster eruit te wippen (op zich een nobel streven) en de kaartverkoop via de eigen website te laten verlopen. Dan zie je als IT'er natuurlijk al op voorhand aankomen wat er gaat gebeuren. Website die hoogstwaarschijnlijk in elkaar is geknutseld door een internetbureautje dat ook de hosting doet fungeert prima onder normale omstandigheden, maar op de enorme piekbelasting die ontstaat omdat mensen rond de klok van 10 uur wanneer de kaartverkoop start massaal op F5 blijven rammen is de site natuurlijk totaal niet berekend. Die ging dan ook compleet down vanaf 2 voor 10 met max database connection issues en 503s en dergelijke.
Dan kun je op Twitter wel claimen: "We hebben een uiterst ongelukkig getimed conflict met onze website voor de #ESNS19 kaartverkoop.", maar mij houd je niet voor de gek.
Maar het niet testen van de site onder load is wel een aanfluiting.
Edit: Het zou me ook niet verbazen als de organisatie geen idee had van de load, iets van: "Ah we hebben zoveel bezoekers, dus doe eens 10% er bij op dan moet het wel goed komen."
[ Voor 6% gewijzigd door Sandor_Clegane op 19-10-2018 11:19 ]
Less alienation, more cooperation.
Dit is een typische business case voor iets als Azure of AWS. Eenvoudig (en goedkoop) op kunnen schalen naar je behoefte (Azure kan het automatisch, ik heb geen ervaring met AWS) en nadien weer terugschalen om kosten te besparen.Sandor_Clegane schreef op vrijdag 19 oktober 2018 @ 11:07:
[...]
Maar het niet testen van de site onder load is wel een aanfluiting.
Edit: Het zou me ook niet verbazen als de organisatie geen idee had van de load, iets van: "Ah we hebben zoveel bezoekers, dus doe eens 10% er bij op dan moet het wel goed komen."
Het is ook heel lastig om dit soort situaties te 'load testen'. Om de juiste load tests te draaien heb je eigenlijk historische data nodig om gebruiksscenario's te kennen en te extrapoleren.Sandor_Clegane schreef op vrijdag 19 oktober 2018 @ 11:07:
[...]
Dat is wel jammer, wel complimenten voor het eruit wippen van Ticketmaster, wat een stelletje schurken zijn dat. Ben nog steeds sneu dat ik geen Radiohead tickets heb kunnen krijgen, stelletje fuckers.
Maar het niet testen van de site onder load is wel een aanfluiting.
Edit: Het zou me ook niet verbazen als de organisatie geen idee had van de load, iets van: "Ah we hebben zoveel bezoekers, dus doe eens 10% er bij op dan moet het wel goed komen."
Een load test die simpelweg 100 keer per seconde de 'home pagina' opvraagt is geen realistisch scenario. Een load test die evenredig veel requests doet naar alle pagina's op je site ook niet.
Je moet in zo'n geval eigenlijk gewoon data van voorgaande jaren hebben om te zien hoe gebruikers zich bij zo'n kaartverkoop gedragen. Hoe navigeren mensen naar je ticketspagina(via google of via verschillende pagina's op je eigen site), hoe vaak wordt daar gerefreshed en meer van dat soort zaken. Op basis van dat soort informatie kun je wat meer realistische load scenario's maken en testen doen.
Al is het sowieso al voor een groot deel op te lossen door caching lijkt me. Zo'n ticketvenstertje op de pagina is gewoon zo'n standaard iFrame integratie dus als site zelf kun je gewoon gecachede content serveren, de iFrame ververst wel onafhankelijk van jouw cache.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Precies, sharden van je DB of andere delen gaat niet automatisch.GrooV schreef op vrijdag 19 oktober 2018 @ 11:27:
Schalen gaat ook niet automatisch, hier moet je gewoon rekening mee houden met je architectuur.
Yep, laat dat nou data zijn die alleen Ticket Master heeft. Dus ik snap best dat dat niet heel vanzelfsprekend is.Mugwump schreef op vrijdag 19 oktober 2018 @ 11:38:
[...]
Het is ook heel lastig om dit soort situaties te 'load testen'. Om de juiste load tests te draaien heb je eigenlijk historische data nodig om gebruiksscenario's te kennen en te extrapoleren.
Een load test die simpelweg 100 keer per seconde de 'home pagina' opvraagt is geen realistisch scenario. Een load test die evenredig veel requests doet naar alle pagina's op je site ook niet.
Je moet in zo'n geval eigenlijk gewoon data van voorgaande jaren hebben om te zien hoe gebruikers zich bij zo'n kaartverkoop gedragen. Hoe navigeren mensen naar je ticketspagina(via google of via verschillende pagina's op je eigen site), hoe vaak wordt daar gerefreshed en meer van dat soort zaken. Op basis van dat soort informatie kun je wat meer realistische load scenario's maken en testen doen.
Al is het sowieso al voor een groot deel op te lossen door caching lijkt me. Zo'n ticketvenstertje op de pagina is gewoon zo'n standaard iFrame integratie dus als site zelf kun je gewoon gecachede content serveren, de iFrame ververst wel onafhankelijk van jouw cache.
Less alienation, more cooperation.
Ah joh, CosmosDB for everything.Skyaero schreef op vrijdag 19 oktober 2018 @ 11:25:
[...]
Dit is een typische business case voor iets als Azure of AWS. Eenvoudig (en goedkoop) op kunnen schalen naar je behoefte (Azure kan het automatisch, ik heb geen ervaring met AWS) en nadien weer terugschalen om kosten te besparen.
* Mercatres heeft afgelopen weken genoeg MS Azure conferences en talks gezien over de next thing you should have in your Azure subscription.
Verwijderd
Ik vind Cosmos echt een prachtig product, maar 'for everything' is precies waar het mis gaat in de praktijk.Mercatres schreef op vrijdag 19 oktober 2018 @ 12:06:
[...]
Ah joh, CosmosDB for everything.
* Mercatres heeft afgelopen weken genoeg MS Azure conferences en talks gezien over de next thing you should have in your Azure subscription.
Ik gebruik het nu in een project op basis van de SQL (voormalige documentDB) API. Dat werkt prima als je het gebruikt om snelle writes van (JSON) documenten te doen, reads op basis van key, de change feed om events te publiceren en b.v. SOLR bij te werken en ga zo maar door. Het feit dat je via stored procedures ook een basale vorm van ACID transacties kunt implementeren is ook ideaal.
Vervolgens gaat een collega van me ermee aan de slag voor een data science project. Na een maand komt ie klagen dat het echt een waardeloze database is. Hij kan niet eens joins tussen verschillende collections doen allerlei complexe analytische queries performen niet zoals hij het wil en ga zo maar door. Dat had ik hem op voorhand wel kunnen vertellen, maar dat soort semi-developers zijn niet zelden stronteigenwijs.
Partijen als Google, Microsoft en Amazon verrichten nou eenmaal geen wonderen. De basale theorie op het gebied van databases en de trade-offs die er bestaan zijn niet fundamenteel veranderd de afgelopen pakweg 30 jaar. Bij elke database moet je nadenken over je datamodel, rekening houden met de specifieke eigenschappen van de database en ga zo maar door.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
* Ryan_ vind het tijd voor een bak koffie

Je kunt ook gewoon met echte transacties testen. Heb je m'n e-mailadres nodig?Ryan_ schreef op vrijdag 19 oktober 2018 @ 13:59:
Mmm, vervelend. De sandbox modus van PayPal werkt sinds vannacht niet meer. Transacties blijven op pending staan en het sandbox account kan niet meer gevonden worden. Moeilijk testen zo.
* Ryan_ vind het tijd voor een bak koffie
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
En als hij nou moet testen of het bedrag goed verstuurd wordt naar hem ?kenneth schreef op vrijdag 19 oktober 2018 @ 14:27:
[...]
Je kunt ook gewoon met echte transacties testen. Heb je m'n e-mailadres nodig?
]|[ Apple Macbook Pro Retina 13" ]|[
Dan kan hij jouw e-mailadres gebruikenDeluxZ schreef op vrijdag 19 oktober 2018 @ 14:36:
[...]
En als hij nou moet testen of het bedrag goed verstuurd wordt naar hem ?
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
]|[ Apple Macbook Pro Retina 13" ]|[
Programmeren is moeilijk. Software engineering is moeilijker. Software architectuur is nog moeilijker. En de meeste klanten komen kwa prijs uit bij bedrijven die stap 1 eigenlijk al niet kunnen.Mugwump schreef op vrijdag 19 oktober 2018 @ 10:58:
Dan kun je op Twitter wel claimen: "We hebben een uiterst ongelukkig getimed conflict met onze website voor de #ESNS19 kaartverkoop.", maar mij houd je niet voor de gek.
https://niels.nu
De focus ligt waarschijnlijk ook heel ergens anders.Hydra schreef op vrijdag 19 oktober 2018 @ 16:25:
[...]
Programmeren is moeilijk. Software engineering is moeilijker. Software architectuur is nog moeilijker. En de meeste klanten komen kwa prijs uit bij bedrijven die stap 1 eigenlijk al niet kunnen.
Het is gewoon een informatieve website met een bepaalde belasting. Daar hoef je enkel rekening te houden met een wat hogere belasting vlak voor en tijdens zo'n festival.
Het type belasting dat je hebt als je zelf via je site de kaartverkoop gaat doen is van een hele andere orde. Uiteindelijk was de kaartverkoop ook gewoon rechtstreeks via een andere site te doen, dus het was handiger geweest om die route op voorhand te kiezen.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Mee eens. Maar dat bedrijf dat die zooi regelt had, in een ideale wereld, verteld dat ze niet bepaald experts zijn in sites maken met een dergelijke load. In the echte wereld zijn mensen helaas niet zo eerlijk.Mugwump schreef op vrijdag 19 oktober 2018 @ 16:37:
De focus ligt waarschijnlijk ook heel ergens anders.
Het is gewoon een informatieve website met een bepaalde belasting. Daar hoef je enkel rekening te houden met een wat hogere belasting vlak voor en tijdens zo'n festival.
Het type belasting dat je hebt als je zelf via je site de kaartverkoop gaat doen is van een hele andere orde. Uiteindelijk was de kaartverkoop ook gewoon rechtstreeks via een andere site te doen, dus het was handiger geweest om die route op voorhand te kiezen.
Heeft dat effect op ons? Eigenlijk wel. Als je vaak slechte kwaliteit tegenkomt ga je dat als de norm zien. Ons vakgebied is een lemon market, slechte devs halen dus simpel gesteld de salarissen van de goeie omlaag.
https://niels.nu
Techorama?Mercatres schreef op vrijdag 19 oktober 2018 @ 12:06:
[...]
* Mercatres heeft afgelopen weken genoeg MS Azure conferences en talks gezien over de next thing you should have in your Azure subscription.
Het is de vraag of ze zich het echt realiseren. Ik zie het van mijlenver aankomen, maar ik werk dan ook met systemen die hard groeien en waar we ons continu bewust moeten zijn van potentiële performance issues.Hydra schreef op vrijdag 19 oktober 2018 @ 16:39:
[...]
Mee eens. Maar dat bedrijf dat die zooi regelt had, in een ideale wereld, verteld dat ze niet bepaald experts zijn in sites maken met een dergelijke load. In the echte wereld zijn mensen helaas niet zo eerlijk.
Helaas wel, maar de schaarste is enorm en er zijn genoeg bedrijven die wel snappen wat het verschil isHeeft dat effect op ons? Eigenlijk wel. Als je vaak slechte kwaliteit tegenkomt ga je dat als de norm zien. Ons vakgebied is een lemon market, slechte devs halen dus simpel gesteld de salarissen van de goeie omlaag.
Ik denk niet dat mijn salaris heel erg onder druk staat door webbureautjes. De lage tarieven die de grote dozenschuivers in de crisis hebben gehanteerd en de import uit / outsourcing naar India zullen eerder een rol spelen.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
upscalen in Azure kan automatisch. Ik twijfel echter of downscalen ook automatisch gaatSkyaero schreef op vrijdag 19 oktober 2018 @ 11:25:
[...]
Dit is een typische business case voor iets als Azure of AWS. Eenvoudig (en goedkoop) op kunnen schalen naar je behoefte (Azure kan het automatisch, ik heb geen ervaring met AWS) en nadien weer terugschalen om kosten te besparen.
https://fgheysels.github.io/

Nu zijn er aparte epics nodig om de Non-functionals goed te maken.
Er wordt veel te veel ad-hoc gedacht en enkel gekeken naar de story ipv eens goed nadenken over de functionaliteit of de gedachte erachter. Zo worden oplossingen bedacht die als "framework" moeten dienen, maar die te beperkt in functionaliteit zijn en meer aanpassingen nodig hebben dan zou moeten.
let the past be the past.
Als je hoge load kan verwachten, lijkt het me ook niet slim om een rechtstreekse connectie te hebben vanaf die site naar een database, die zowiezo beperkt is in het max. aantal connecties.Mugwump schreef op vrijdag 19 oktober 2018 @ 10:58:
Eurosonic Noorderslag had dit jaar besloten om voor de kaartverkoop Ticketmaster eruit te wippen (op zich een nobel streven) en de kaartverkoop via de eigen website te laten verlopen. Dan zie je als IT'er natuurlijk al op voorhand aankomen wat er gaat gebeuren. Website die hoogstwaarschijnlijk in elkaar is geknutseld door een internetbureautje dat ook de hosting doet fungeert prima onder normale omstandigheden, maar op de enorme piekbelasting die ontstaat omdat mensen rond de klok van 10 uur wanneer de kaartverkoop start massaal op F5 blijven rammen is de site natuurlijk totaal niet berekend. Die ging dan ook compleet down vanaf 2 voor 10 met max database connection issues en 503s en dergelijke.
Het lijkt me beter dat je de geregistreerde aankopen eerst naar iets als een servicebus / eventhub gaat gaan posten, wat wel schaalbaar is. Een aparte worker kan dan die berichten op volgorde waarop ze werden geregistreerd naar de DB gaan wegschrijven op zo'n tempo dat de DB het wel aankan.
https://fgheysels.github.io/
Zie mijn opvolgende post.whoami schreef op vrijdag 19 oktober 2018 @ 17:20:
[...]
Als je hoge load kan verwachten, lijkt het me ook niet slim om een rechtstreekse connectie te hebben vanaf die site naar een database, die zowiezo beperkt is in het max. aantal connecties.
Het lijkt me beter dat je de geregistreerde aankopen eerst naar iets als een servicebus / eventhub gaat gaan posten, wat wel schaalbaar is. Een aparte worker kan dan die berichten op volgorde waarop ze werden geregistreerd naar de DB gaan wegschrijven op zo'n tempo dat de DB het wel aankan.
Er is nog steeds een third party provider en de pagina heeft enkel een Iframe met wat informatie er omheen.
Het heeft natuurlijk ook niets met het registreren van aankopen te maken als met al mis gaat bij de pagina-opvragingen.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
compleet down vanaf 2 voor 10 met max database connection issues
https://fgheysels.github.io/
Ja dat snap ik, maar het ging om opvragingen. Een servicebus of event hub gaat daarbij niet helpen.
Een dergelijke oplossing werkt vooral als je aan de command / write side relatief zware operaties hebt die je asynchroon kunt uitvoeren. Je schrijft dan namelijk snel iets weg en laat de afhandeling op de achtergrond plaatsvinden waarbij je een wachtrij hanteert voor eventuele zware load.
Het is sowieso de vraag of dat echt kan bij kaartjes bestellen. Je zult toch ergens moeten opvragen of er nog kaartjes beschikbaar zijn bijvoorbeeld.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Jullie hebben een paar goeie software engineer/architecten nodig die ook de ballen hebben nee te zeggen tegen de business. Regel 1 van agile wat mij betreft: "Build projects around motivated individuals.SPee schreef op vrijdag 19 oktober 2018 @ 17:19:
Er wordt veel te veel ad-hoc gedacht en enkel gekeken naar de story ipv eens goed nadenken over de functionaliteit of de gedachte erachter. Zo worden oplossingen bedacht die als "framework" moeten dienen, maar die te beperkt in functionaliteit zijn en meer aanpassingen nodig hebben dan zou moeten.
Give them the environment and support they need, and trust them to get the job done."
https://niels.nu
India is het probleem niet meer. De meeste bedrijven zijn van een koude kermis thuis gekomen wat India betreft, zeker wanneer het om software gaat met complexe functionaliteit die allerlei uitzonderingen kent.Mugwump schreef op vrijdag 19 oktober 2018 @ 16:55:
[...]
Helaas wel, maar de schaarste is enorm en er zijn genoeg bedrijven die wel snappen wat het verschil is
Ik denk niet dat mijn salaris heel erg onder druk staat door webbureautjes. De lage tarieven die de grote dozenschuivers in de crisis hebben gehanteerd en de import uit / outsourcing naar India zullen eerder een rol spelen.
De ruis in de communicatie alleen al maakt het bijna onmogelijk om een goed product af te leveren.
Waar ik echter wel een beetje van schrik, zijn de ontwikkelaars in oost Europa. Die spreken vaak vloeiend Engels, zijn hoogopgeleid, weten wel degelijk wat ze doen... En zijn goedkoper.
De ervaringen daarmee zijn stukken beter.
En dat kan wel lastig zijn.
Op mijn vorige werk is de hele development afdeling uiteindelijk ontmanteld. Alleen een paar seniors bleven om te communiceren en testen. De rest is weg.
PS
Een goede Indiër zal proberen te emigreren voor een betere toekomst - vaak met succes naar de VS etc - waardoor vooral veel middelmatige devs achterblijven.
Een goede developer in Tsjechië of Bulgarije boeit dat veel minder. Die heeft een prima leven in zijn thuisland en voelt zich relatief rijk.
Hij kan met de helft van wat wij verdienen riant leven daar. Vaak nog in een mooie omgeving ook.
Ze hebben dus minder last van brain drain.
[ Voor 16% gewijzigd door Lethalis op 19-10-2018 21:49 ]
Ask yourself if you are happy and then you cease to be.
Ik vind dat een vrij stellige claim. Zijn daar ook cijfers van?Lethalis schreef op vrijdag 19 oktober 2018 @ 21:32:
[...]
India is het probleem niet meer. De meeste bedrijven zijn van een koude kermis thuis gekomen wat India betreft, zeker wanneer het om software gaat met complexe functionaliteit die allerlei uitzonderingen kent.
De ruis in de communicatie alleen al maakt het bijna onmogelijk om een goed product af te leveren.
Waar ik echter wel een beetje van schrik, zijn de ontwikkelaars in oost Europa. Die spreken vaak vloeiend Engels, zijn hoogopgeleid, weten wel degelijk wat ze doen... En zijn goedkoper.
De ervaringen daarmee zijn stukken beter.
En dat kan wel lastig zijn.
Op mijn vorige werk is de hele development afdeling uiteindelijk ontmanteld. Alleen een paar seniors bleven om te communiceren en testen. De rest is weg.
PS
Een goede Indiër zal proberen te emigreren voor een betere toekomst - vaak met succes naar de VS etc - waardoor vooral veel middelmatige devs achterblijven.
Een goede developer in Tsjechië of Bulgarije boeit dat veel minder. Die heeft een prima leven in zijn thuisland en voelt zich relatief rijk.
Hij kan met de helft van wat wij verdienen riant leven daar. Vaak nog in een mooie omgeving ook.
Ze hebben dus minder last van brain drain.
Het gaat hier om de vraag of Indiërs nog veel werk doen, niet of ze top zijn. Er zijn best goede Indische ontwikkelaars. Er zijn er alleen zo achterlijk veel dat er ook heel wat middelmaat tussen zit.
Maar waar ik nu werk zit al veel import uit India en ook nog wel veel remote teams. Het idee dat import / outsourcing naar India voorbij zou zijn zie ik dus niet direct.
Mijn ervaring met ontwikkelaars uit Oost-Europa is erg positief. Zijn veelal goed geschoold, vaardig en spreken prima Engels. Hun tongval ligt een Nederlander natuurlijk ook beter dan die van een Indiër vanwege de grotere gelijkenis tussen de moedertalen. Overigens zijn ze niet per definitie heel veel goedkoper als ze hier werken en gewoon goed zijn.
Heb in het verleden ook wel eens gewerkt met Bulgaren die vanuit eigen land werkten. Die verdienden dan een voor ons redelijk bescheiden salaris, maar in eigen land gewoon 5x modaal.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Yup. Alleen werken die niet voor de low-cost outsourcing shops, en vaak wonen die ook niet meer in India.Mugwump schreef op vrijdag 19 oktober 2018 @ 22:44:
Er zijn best goede Indische ontwikkelaars.
https://niels.nu
(Slome reply -- omdat ik hier niet zo vaak "zit") ja, hier! Rust is de bom.TheNephilim schreef op dinsdag 9 oktober 2018 @ 09:28:
Mooie discussies hier!Had ook niet gedacht dat er zoveel developers hier zitten die iets met Go doen. Iemand ervaringen met Rust?
Rustacean
Helaas gaat het daar in veel bedrijven gruwelijk mis. Die gaan agile/scrum werken omdat het hip is, maar durven er niet aan te committeren.Hydra schreef op vrijdag 19 oktober 2018 @ 18:07:
[...]
Jullie hebben een paar goeie software engineer/architecten nodig die ook de ballen hebben nee te zeggen tegen de business. Regel 1 van agile wat mij betreft: "Build projects around motivated individuals.
Give them the environment and support they need, and trust them to get the job done."
Dat leidt er uiteindelijk toe dat de wensen van de business nog altijd leidend zijn, ook al zeggen de IT'ers dat het onhaalbaar is (of dat het bullshit is).
We are shaping the future
Soms wel een beetje jammer dat nieuwe talen als paddenstoelen uit de grond schieten. Uiteindelijk maken ze de basis wel makkelijker, maar al de bestaande ecosysteem moet je inleveren (waar zijn de refactoring tools?). Kan zijn dat ze er ondertussen er al wel (weer) zijn, en dan bedoel ik niet alleen een naam veranderen?djc schreef op zaterdag 20 oktober 2018 @ 20:49:
[...]
(Slome reply -- omdat ik hier niet zo vaak "zit") ja, hier! Rust is de bom.
[ Voor 4% gewijzigd door Feanathiel op 20-10-2018 23:05 ]
Het is wat ik bij diverse bedrijven gezien heb. Ja, ze doen nog steeds werk, maar nieuwe ontwikkelingen worden steeds vaker hier gedaan.Mugwump schreef op vrijdag 19 oktober 2018 @ 22:44:
[...]
Ik vind dat een vrij stellige claim. Zijn daar ook cijfers van?
In het algemeen geldt overigens dat we in de IT steeds meer met minder (maar hoge gekwalificeerde) mensen doen. Dit schijnt er ook voor te zorgen dat we minder outsourcen.
De groeiende populariteit van cloudoplossingen speelt hier ook een rol in. Omdat je een groot deel van het beheer simpelweg kwijt bent, kun je af met minder mensen voor een project.
En als je toch minder mensen nodig hebt, raak je de primaire voordelen van het traditionele outsourcen kwijt.
Maar goed, dit geldt niet voor alles en iedereen. Echt hele grote multinationals zullen vast nog veel outsourcen.
Bij de middelgrote ondernemingen eronder neemt het wel af. Wel gaat alles in rap tempo naar de cloud.
...
Compleet ongerelateerd, maar interessant artikel dat ik over exceptions heb gelezen:
https://blog.plan99.net/w...ptions-nothing-cee2ed0616
Het stukje over Go is ook wel interessant. Bug fixing wordt inderdaad lastig zonder stacktrace.
[ Voor 49% gewijzigd door Lethalis op 21-10-2018 12:25 ]
Ask yourself if you are happy and then you cease to be.
Maar de business bepaalt uiteindelijk wat de software moet kunnen, niet het ontwikkelteam. Natuurlijk, als het team zegt dat iets niet haalbaar is moet daar naar geluisterd worden maar als de wensen van de business niet leidend zijn, voor wie ontwikkel je dan de software?Alex) schreef op zaterdag 20 oktober 2018 @ 21:47:
Helaas gaat het daar in veel bedrijven gruwelijk mis. Die gaan agile/scrum werken omdat het hip is, maar durven er niet aan te committeren.
Dat leidt er uiteindelijk toe dat de wensen van de business nog altijd leidend zijn, ook al zeggen de IT'ers dat het onhaalbaar is (of dat het bullshit is).
Exact expert nodig?
Precies, het hele idee achter Agile is dat het productgedreven is. Een product owner bepaalt de koers, op basis van de wensen en prioriteiten van de business / stakeholders.Crazy D schreef op zondag 21 oktober 2018 @ 12:44:
[...]
Maar de business bepaalt uiteindelijk wat de software moet kunnen, niet het ontwikkelteam. Natuurlijk, als het team zegt dat iets niet haalbaar is moet daar naar geluisterd worden maar als de wensen van de business niet leidend zijn, voor wie ontwikkel je dan de software?
Het is wel zo dat als je je commiteert aan scrum en je wil er ook succes mee boeken dat je dan niet elke sprint steeds weer de scope gaat veranderen tijdens de sprint en meer van dat soort zaken.
Ik zie in de praktijk ook heel vaak een brak uitgevoerd iteratief watervalproces vermomd als scrum.
Er stond recentelijk nog wel een aardig interview op InfoQ over de overgang naar Agile werken:
https://www.infoq.com/news/2018/10/purposeful-agile
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
"Dit moet het worden en over 4 weken moet het live staan" is een prima opdracht als je vooraf al je eisen duidelijk hebt en er al technische ontwerpen zijn gemaakt.
Als het één groot raadsel is wat er nou precies moet komen, maar het wel over 4 weken live moet zijn, dan mag je wel een verdomd goed team hebben om dat allemaal in goede banen te leiden.
We are shaping the future
Om te janken eerlijk gezegd.Lethalis schreef op zondag 21 oktober 2018 @ 10:24:
[...]
Compleet ongerelateerd, maar interessant artikel dat ik over exceptions heb gelezen:
https://blog.plan99.net/w...ptions-nothing-cee2ed0616
Het stukje over Go is ook wel interessant. Bug fixing wordt inderdaad lastig zonder stacktrace.
Hij murmelt dat C++ pointers heeft en daarom geheugen kan lekken. Als "modern C++" versie gaat 'ie objecten by value in de vector stoppen (ipv een shared_ptr te gebruiken) en klaagt dat dat resources/performance kost.
[ Voor 5% gewijzigd door farlane op 21-10-2018 13:48 ]
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
De business wil graag bepaalde functionaliteit, en daar staat een bepaalde vergoeding tegenover. Soms wil de business iets wat onevenredig veel geld gaat kosten waardoor de verkoopprijs (of abonnementsprijs) omhoog moet waardoor er dus iets niet geprogrammeerd zal gaan worden.Crazy D schreef op zondag 21 oktober 2018 @ 12:44:
[...]
Maar de business bepaalt uiteindelijk wat de software moet kunnen, niet het ontwikkelteam. Natuurlijk, als het team zegt dat iets niet haalbaar is moet daar naar geluisterd worden maar als de wensen van de business niet leidend zijn, voor wie ontwikkel je dan de software?
Daarnaast heeft het ontwikkelteam zeker wel wat te zeggen. Als ze ontwikkelen aan een stuk software waar ze niet (meer) voor 100% achter staan, krijg je slechte kwaliteit software met de daaruit komende negatieve gevolgen....
Speel ook Balls Connect en Repeat
Ja daaaag, dat is geen ontwikkelteam maar een groep hobbyisten. Wees een vakman.Onbekend schreef op zondag 21 oktober 2018 @ 13:50:
[...]
Als ze ontwikkelen aan een stuk software waar ze niet (meer) voor 100% achter staan, krijg je slechte kwaliteit software met de daaruit komende negatieve gevolgen....
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Als je in zo'n situatie zit ben je ook geen Scrum / Agile aan het doen.Alex) schreef op zondag 21 oktober 2018 @ 13:43:
Ik bedoelde niet dat we niet voor de business ontwikkelen, ik bedoelde dat de business ook moet luisteren naar de input van het ontwikkelteam over wat realistisch is.
"Dit moet het worden en over 4 weken moet het live staan" is een prima opdracht als je vooraf al je eisen duidelijk hebt en er al technische ontwerpen zijn gemaakt.
Als het één groot raadsel is wat er nou precies moet komen, maar het wel over 4 weken live moet zijn, dan mag je wel een verdomd goed team hebben om dat allemaal in goede banen te leiden.
Ik zie wel vaker dat 'Agile' door organisaties wordt aangegrepen om een soort "waterval zonder fatsoenlijke requirements" te introduceren. Gewoon lekker één zinnetje roepen dat vervolgens snel af moet en het "zelfsturende team" moet het verder maar oplossen. Uiteindelijk heeft niemand daar verder iets aan.
Er ligt voor de PO een belangrijke taak weggelegd om de nog steeds bestaande verwachting dat je "op moment X tegen prijs Y resultaat Z kunt krijgen" te bestrijden.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Hear, hear.Mugwump schreef op zondag 21 oktober 2018 @ 14:13:
[...]
Als je in zo'n situatie zit ben je ook geen Scrum / Agile aan het doen.
[ Voor 3% gewijzigd door Alex) op 21-10-2018 14:21 ]
We are shaping the future
Dat is een wat andere situatie. In wezen bepaalt de PO enkel de prioriteit voor zover ik het kan zien en negeert daarbij het team. Het is niet zo dat het team krijgt opgelegd dat "X deze sprint af moet" ook al zou dat niet passen.Alex) schreef op zondag 21 oktober 2018 @ 14:19:
[...]
Hear, hear.
Members only:
Alleen zichtbaar voor ingelogde gebruikers. Inloggen
Ik ben het met je eens dat een goede PO de input van zijn team serieus neemt en ook meeneemt in de prioritering van zaken. Uiteindelijk is dat een combinatie van verwachte waarde en verwachte inspanning.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Dat stukje van het artikel vind ik ook een beetje apart.farlane schreef op zondag 21 oktober 2018 @ 13:46:
[...]
Om te janken eerlijk gezegd.
Hij murmelt dat C++ pointers heeft en daarom geheugen kan lekken. Als "modern C++" versie gaat 'ie objecten by value in de vector stoppen (ipv een shared_ptr te gebruiken) en klaagt dat dat resources/performance kost.
De reden dat ik dit soort artikelen lees, is ook om voor mezelf te bepalen: zijn exceptions iets goeds, of juist iets dat je wil vermijden?
Hoe meer ik daarover lees, hoe verwarrender het wordt
Als je met functional programming bezig bent, lees je vaak dat exceptions evil zijn en worden gezien als veredelde goto statements.
Ook wordt beargumenteerd dat je veel problemen al tijdens compile time kunt afvangen (null references met option types, gestructureerde error afhandeling met either en pattern matching, etc).
En dan ben ik geneigd om dit ook in plain old C# code toe te passen.
Maar is dat handig? Of is het blijven gebruiken van exceptions grotendeels prima?
Ask yourself if you are happy and then you cease to be.
In een organisatie die helemaal is ingesteld op agile/scrum werken is dat inderdaad zo. In een organisatie die wat meer in oude structuren blijft hangen, is de inspraak van de PO maar beperkt.Mugwump schreef op zondag 21 oktober 2018 @ 14:26:
[...]
Dat is een wat andere situatie. In wezen bepaalt de PO enkel de prioriteit voor zover ik het kan zien en negeert daarbij het team. Het is niet zo dat het team krijgt opgelegd dat "X deze sprint af moet" ook al zou dat niet passen.
Ik ben het met je eens dat een goede PO de input van zijn team serieus neemt en ook meeneemt in de prioritering van zaken. Uiteindelijk is dat een combinatie van verwachte waarde en verwachte inspanning.
We are shaping the future
Dan is dat nog steeds de keuze van de business, niet van het ontwikkelteam. Wie zijn "wij" om dat te bepalen? Daar heb je de product owner voor. Je kunt als team aangeven wat de ontwikkeltijd is en de risico's benoemen, maar als de business het dan nog steeds wil, heb je het maar te bouwen.Onbekend schreef op zondag 21 oktober 2018 @ 13:50:
De business wil graag bepaalde functionaliteit, en daar staat een bepaalde vergoeding tegenover. Soms wil de business iets wat onevenredig veel geld gaat kosten waardoor de verkoopprijs (of abonnementsprijs) omhoog moet waardoor er dus iets niet geprogrammeerd zal gaan worden.
Dan kun je wat mij aangaat ander werk gaan zoeken. Je input als vakman is welkom, je kunt risico's benoemen en argumenten aandragen waarom bepaalde functionele keuzes misschien niet zo handig zijn, maar als de business het wil heb je het te bouwen, punt. Raak je daardoor je motivatie kwijt? Zoek je maar een leuk hobby project of een andere baan. Je bent professional of je bent het niet.Daarnaast heeft het ontwikkelteam zeker wel wat te zeggen. Als ze ontwikkelen aan een stuk software waar ze niet (meer) voor 100% achter staan, krijg je slechte kwaliteit software met de daaruit komende negatieve gevolgen....
Exact expert nodig?
Waarom niet best of both worlds?Lethalis schreef op zondag 21 oktober 2018 @ 14:57:
En dan ben ik geneigd om dit ook in plain old C# code toe te passen.
Maar is dat handig? Of is het blijven gebruiken van exceptions grotendeels prima?
Het zit hem denk ik ook in de naam: exceptions zijn uitzonderingen.
Overal waar je verwacht dat het goed moet gaan, gebruik geen exceptions, maar een error object/code die gereturned wordt. En dan overal waar het goed moet gaan, gebruik exceptions.
Voorbeeldje misschien:
Een functie die user input accepteert zou geen exception moeten gooien als die input verkeerd is. Je verwacht namelijk dat het goed gaat, maar met normaal gebruik kan het fout gaan.
Een functie die een waarde uit een database trekt zou altijd dat moeten returnen. Als er geen verbinding met de db is, dan is dat een uitzondering en een exception moet dan gegooid worden. Je verwacht namelijk niet dat dat ooit fout zou gaan.
Ik zou dat ook graag zo doen op werk in C++, maar we zitten met zo weinig geheugen dat exception in de compiler zijn uitgeschakeld
Het antwoord heb ik niet voor je, ik weet alleen wel dat de argumentatie in dat artikel op zijn zachts gezegd zwak is.Lethalis schreef op zondag 21 oktober 2018 @ 14:57:
[...]
De reden dat ik dit soort artikelen lees, is ook om voor mezelf te bepalen: zijn exceptions iets goeds, of juist iets dat je wil vermijden?
Maar is dat handig? Of is het blijven gebruiken van exceptions grotendeels prima?
Persoonlijk vind ik exceptions een lastig verhaal; ze zouden code duidelijker moeten maken maar ik ervaar vaak het tegenovergestelde.
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Hoe bedoel je "inspraak van de PO"? Dat is gewoon degene die uiteindelijk de product backlog beheert.Alex) schreef op zondag 21 oktober 2018 @ 15:00:
[...]
In een organisatie die helemaal is ingesteld op agile/scrum werken is dat inderdaad zo. In een organisatie die wat meer in oude structuren blijft hangen, is de inspraak van de PO maar beperkt.
Betekent natuurlijk niet dat een PO volledig zelf kan doen wat hij wil. Uiteindelijk is de PO slechts doorgeefluik en degene die de belangen van de verschillende stakeholders afweegt.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Op papier, ja. In de praktijk is dat niet altijd zo.Mugwump schreef op zondag 21 oktober 2018 @ 15:10:
[...]
Hoe bedoel je "inspraak van de PO"? Dat is gewoon degene die uiteindelijk de product backlog beheert.
Klopt.Betekent natuurlijk niet dat een PO volledig zelf kan doen wat hij wil. Uiteindelijk is de PO slechts doorgeefluik en degene die de belangen van de verschillende stakeholders afweegt.
We are shaping the future
Omdat het al gauw een kwestie van best practices wordt. Je houdt van exceptions, of niet.diondokter schreef op zondag 21 oktober 2018 @ 15:07:
[...]
Waarom niet best of both worlds?
Het zit hem denk ik ook in de naam: exceptions zijn uitzonderingen.
Overal waar je verwacht dat het goed moet gaan, gebruik geen exceptions, maar een error object/code die gereturned wordt. En dan overal waar het goed moet gaan, gebruik exceptions.
Voorbeeldje misschien:
Een functie die user input accepteert zou geen exception moeten gooien als die input verkeerd is. Je verwacht namelijk dat het goed gaat, maar met normaal gebruik kan het fout gaan.
Een functie die een waarde uit een database trekt zou altijd dat moeten returnen. Als er geen verbinding met de db is, dan is dat een uitzondering en een exception moet dan gegooid worden. Je verwacht namelijk niet dat dat ooit fout zou gaan.
Ik zou dat ook graag zo doen op werk in C++, maar we zitten met zo weinig geheugen dat exception in de compiler zijn uitgeschakeld
Als je gelooft dat functies puur en eerlijk moeten zijn, dan doen ze nooit iets dat je niet verwacht. Dat betekent dat de output alle mogelijke uitkomsten moet omschrijven.
Het is dan dus logischer om een Either<Error, Result> terug te geven, dan alleen een Result en mogelijkerwijs een Exception (Java heeft hier met checked exceptions een soort tussenoplossing voor gevonden).
Maar gezien C# geen checked exceptions heeft, en een taal als Kotlin ook niet, hebben exceptions een vrij hoog "surprise" gehalte
Een Either<Error, Result> maakt meteen duidelijk wat er kan gebeuren.
Alleen schuilt er wellicht een gevaar in een groter systeem, dat een Error te algemeen kan zijn en het moeilijker kan zijn om de oorzaak van de error te achterhalen (omdat je geen stack trace hebt).
Ik ben dus ook benieuwd naar hoe een alternatieve oplossing als Either<L, R> schaalt ten opzichte van try catch
Ask yourself if you are happy and then you cease to be.
Er is geen reden om aan te nemen dat de Error in Result<Error,RetVal> geen stacktrace zou *kunnen* bevatten.Lethalis schreef op zondag 21 oktober 2018 @ 19:53:
Alleen schuilt er wellicht een gevaar in een groter systeem, dat een Error te algemeen kan zijn en het moeilijker kan zijn om de oorzaak van de error te achterhalen (omdat je geen stack trace hebt).
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Je kunt niet om Exceptions heen in .Net iig, zelfs een webrequest geeft een exception als hij een 404 krijgt. Wat niet echt een Exception waardig is maar ja, dat is een hele andere discussie.
Edit: Volgens mij op een Redirect en niet op een 404, maar ja punt blijft hetzelfde.
[ Voor 73% gewijzigd door Sandor_Clegane op 21-10-2018 20:53 ]
Less alienation, more cooperation.
De oude WebRequest-klasse en z'n afgeleiden doen dat inderdaad. De modernere HttpClient geeft een response-object dat aangeeft of het request succesvol was (een 200-code) en waarmee je de content kunt uitlezen.Sandor_Clegane schreef op zondag 21 oktober 2018 @ 20:40:
Je kunt niet om Exceptions heen in .Net iig, zelfs een webrequest geeft een exception als hij een 404 krijgt.
Daarbij moet wel opgemerkt worden dat de lifecycle handling van HttpClient een beetje vreemd is: de klasse implementeert weliswaar IDisposable, maar je moet 'm niet na elke use wegsmijten (dan loop je mogelijk tegen socket exhaustion aan). Een singleton wil je ook niet, want dan worden veranderen aan DNS-records niet meer opgepakt. De juiste manier is om IHttpClientFactory te gebruiken.
We are shaping the future
Yep, en niet alleen dat, als er een exception optreedt in de HTTP client en je multiple async/awaits in je programma "in flight" hebt die hem gebruiken dan kan het zijn dat deze allemaal silently failen omdat het hoofd object kaput is. Niet cool.Alex) schreef op zondag 21 oktober 2018 @ 21:20:
[...]
Daarbij moet wel opgemerkt worden dat de lifecycle handling van HttpClient een beetje vreemd is: de klasse implementeert weliswaar IDisposable, maar je moet 'm niet na elke use wegsmijten (dan loop je mogelijk tegen socket exhaustion aan). Een singleton wil je ook niet, want dan worden veranderen aan DNS-records niet meer opgepakt. De juiste manier is om IHttpClientFactory te gebruiken.
Less alienation, more cooperation.
Hah, onlangs exact tegen die issue aangelopen. Uiteindelijk kwam het daar op neer, na duizend suggesties van retry-policies enz.Alex) schreef op zondag 21 oktober 2018 @ 21:20:
[...]
Daarbij moet wel opgemerkt worden dat de lifecycle handling van HttpClient een beetje vreemd is: de klasse implementeert weliswaar IDisposable, maar je moet 'm niet na elke use wegsmijten (dan loop je mogelijk tegen socket exhaustion aan). Een singleton wil je ook niet, want dan worden veranderen aan DNS-records niet meer opgepakt. De juiste manier is om IHttpClientFactory te gebruiken.
Onder andere, ook Cloudbrew.
[ Voor 11% gewijzigd door Mercatres op 22-10-2018 15:27 ]
Dat is toch een heel ander probleem? Dat gaat over dat bepaalde dingen dynamisch worden opgelost terwijl dat prima statisch had gekund. En dat er dus helemaal geen dynamische vorm van error/exception-handling nodig was geweest.Lethalis schreef op zondag 21 oktober 2018 @ 14:57:
Ook wordt beargumenteerd dat je veel problemen al tijdens compile time kunt afvangen (null references met option types, gestructureerde error afhandeling met either en pattern matching, etc).
Het enige verschil tussen de functionele aanpak en de Java-aanpak (om het zo maar even te noemen) is dat in de functionele aanpak exceptions expliciet worden uitgeprogrammeerd, en je de semantiek dus ook zelf mag bepalen. Er bestaat zo geen verschil meer tussen exceptions en control flow (voor zover je daar in FP al over kunt spreken). Dat kan fijn zijn: als je functie een maybe/option-type teruggeeft is het leuk dat de syntax niet anders is dan in een functie die een complexe foutmelding teruggeeft. In Java zit je jezelf dan af te vragen of je iets nog een exception laat zijn, of dat het toch echt standaard control flow is en je dus een expliciet return-type nodig hebt. Aan de andere kant kost die flexibele vorm van exception handling in FP ook moeite: heb je net besloten om je fouten met Maybe/Either af te handelen, en dan kom je er tijdens het debuggen achter dat je eigenlijk toch wel graag gewoon de hele stack trace wil zien. Dan mag je je programma gaan refactoren om die tevoorschijn te toveren (voor zover je FP-taal sowieso iets als een stack trace ondersteunt).Lethalis schreef op zondag 21 oktober 2018 @ 19:53:
Alleen schuilt er wellicht een gevaar in een groter systeem, dat een Error te algemeen kan zijn en het moeilijker kan zijn om de oorzaak van de error te achterhalen (omdat je geen stack trace hebt).
Uitendelijk is alles gewoon een afweging expliciet versus impliciet, en beiden kunnen een bron van onduidelijkheid zijn. Impliciet is onduidelijk als het relevante zaken wegstopt en expliciet is onduidelijk als het veel foutgevoelige boiler-plate code geeft.
[ Voor 7% gewijzigd door bwerg op 22-10-2018 16:50 ]
Heeft geen speciale krachten en is daar erg boos over.
In België?Mercatres schreef op maandag 22 oktober 2018 @ 15:26:
[...]
Hah, onlangs exact tegen die issue aangelopen. Uiteindelijk kwam het daar op neer, na duizend suggesties van retry-policies enz.
[...]
Onder andere, ook Cloudbrew.
https://fgheysels.github.io/
Maar goed, voorlopig heb ik het even druk met wat achterstallig serveronderhoud n.a.v. een incident. Even een serieuze reminder dat we echt moeten gaan kijken naar een cloudoplossing of iets dergelijks.
[ Voor 55% gewijzigd door Lethalis op 22-10-2018 23:52 ]
Ask yourself if you are happy and then you cease to be.
'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind.' - Pratchett.
Ja daar heb ik toevallig net gereageerdboe2 schreef op dinsdag 23 oktober 2018 @ 09:00:
Het is terug school zeker? Zie hier een hele hoop huiswerkthreads passeren, maar vandaag ook een hele discussie met verschillende mensen die aan het brainstormen zijn hoe je best 2 strings aan elkaar hangt
Hoeder van het Noord-Meierijse dialect
Ik ben benieuwd wanneer en waarmee jullie zijn begonnen met programmeren en ik ben ook wel nieuwsgierig wat je er nu mee doet (indien je studeert of werkend bent).
Mijn aftrap: 2e helft jaren 80, toen ik een jaar of 8 of 9 was, ben ik begonnen met Logo op de MSX. Ik denk niet dat veel mensen dat nog kennen. Enkele jaren later ben ik overgestapt op MSX BASIC en op m'n 14e programmeerde ik voornamelijk assembly voor de Z80. Eind middelbare school (2e helft jaren 90) ben ik overgestapt op PC met Borland Pascal en (inline) assembly.
Tijdens mijn studie elektro gingen we verder met C en voor hardware design VHDL. Eind jaren 90 was Java sterk in opkomst, dus ook dat kregen we als vakken.
Daarna ging ik werken + studeren en kwam er meer Java en C++. Op mijn werk (1e helft 2000) was het vooral C++, soms een beetje Perl en uiteindelijk het nodige in MatLab. In 2007 nam ik afscheid van de software ontwikkeling en sindsdien programmeer ik heel soms, meestal scripting via Javascript en heel sporadisch een stukje C# in het produkt wat wij voeren.
Hoe is dat bij jullie verlopen?
[ Voor 3% gewijzigd door RobIII op 23-10-2018 14:17 ]
In de jaren '80 als kind nog wel wat aangeklooid met Basic op de C64. In mijn middelbare schooltijd nog wel wat gedaan met Basic onder DOS en later Visual Basic onder Windows.PageFault schreef op dinsdag 23 oktober 2018 @ 14:04:
~[mbr]*merged naar De Devschuur Coffee Corner - Iteratie ⓬*~[/]
Ik ben benieuwd wanneer en waarmee jullie zijn begonnen met programmeren en ik ben ook wel nieuwsgierig wat je er nu mee doet (indien je studeert of werkend bent).
Mijn aftrap: 2e helft jaren 80, toen ik een jaar of 8 of 9 was, ben ik begonnen met Logo op de MSX. Ik denk niet dat veel mensen dat nog kennen. Enkele jaren later ben ik overgestapt op MSX BASIC en op m'n 14e programmeerde ik voornamelijk assembly voor de Z80. Eind middelbare school (2e helft jaren 90) ben ik overgestapt op PC met Borland Pascal en (inline) assembly.
Tijdens mijn studie elektro gingen we verder met C en voor hardware design VHDL. Eind jaren 90 was Java sterk in opkomst, dus ook dat kregen we als vakken.
Daarna ging ik werken + studeren en kwam er meer Java en C++. Op mijn werk (1e helft 2000) was het vooral C++, soms een beetje Perl en uiteindelijk het nodige in MatLab. In 2007 nam ik afscheid van de software ontwikkeling en sindsdien programmeer ik heel soms, meestal scripting via Javascript en heel sporadisch een stukje C# in het produkt wat wij voeren.
Hoe is dat bij jullie verlopen?
Daarna gaan studeren en van alles met AHDL, Assembly, C, C++, Matlab, Java, Miranda, Prolog, JavaScript en vast nog wel meer dat ik me zo niet kan herinneren gedaan.
Qua werk begonnen met webcomponenten in ASP / PHP / Javascript / C#, vervolgens een tijd lang hoofdzakelijk full stack Java met dus Java en JavaScript en nu een tijdje weer wat rondklooien in de .Net wereld met hoofdzakelijk C# / Javascript en een klein beetje F#.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Toen ik 10 jaar oud was, kreeg ik een oude PC van mijn vader met Commander Keen 1 - 3 er op, omdat ik zeurde om een Nintendo.PageFault schreef op dinsdag 23 oktober 2018 @ 14:04:
Ik ben benieuwd wanneer en waarmee jullie zijn begonnen met programmeren en ik ben ook wel nieuwsgierig wat je er nu mee doet (indien je studeert of werkend bent).
Nadat ik een paar weken gespeeld had ermee, ging ik mij vervelen. Ik zag dat mijn vader voor zijn werk programma's met PowerBASIC schreef, dus toen wou ik dat ook proberen.
Dus kreeg ik een paar diskettes en installeerde ik PowerBASIC. Mijn vader had nog 2 boeken liggen, een language reference en een manual. Die heb ik toen beide gelezen en daarna ben ik kleine programma'tjes gaan maken.
In het begin vooral ASCII art. Met allerlei loopjes een zeilboot te voorschijn toveren. Dat soort dingen. Daarna ging ik programma's nabouwen. Ik heb bijvoorbeeld mijn eigen ARJMENU gemaakt. Gewoon omdat het kon.
Die fase - van 10 jaar oud tot 12 jaar oud - heb ik vooral ermee gespeeld uit verveling.
Daarna druk geweest op de middelbare school met de brugklas en alle nieuwe indrukken. En eigenlijk een paar jaar niks meer ermee gedaan. Totdat mijn vader een Windows versie nodig had van een DOS programma dat hij had gemaakt.
Toen was ik 15 en wou graag een nieuwe computer. Mijn vader was druk met andere dingen bezig en stelde dus aan mij voor dat als ik in de zomervakantie met Visual Basic een Windows versie van zijn programma zou maken, dat ik dan voor 1000 gulden nieuwe computeronderdelen mocht uitzoeken.
Long story short, heb ik toen in de zomervakantie zijn hele programma eerst herschreven van PowerBASIC naar Visual Basic, heb ik daarna het aantal regels code ongeveer tot 25% terug gebracht ( to keep it interesting
Op dat moment was wel vrij duidelijk dat ik later zeer waarschijnlijk programmeur zou worden.
Wij die Windows versie verkocht voor 8000 gulden, ik mijn PC gescoord en daarna heb ik er eigenlijk tot mijn eindexamen HAVO niks mee gedaan.
Door persoonlijke omstandigheden had ik na de HAVO geen zin meer in school. Mijn vader zocht nog mensen voor zijn ingenieursbureau en zo ben ik daar begonnen als technisch CAD tekenaar (ik kon al met AutoCAD omgaan toen ik 13 was, zo verdiende ik doorgaans mijn zakgeld in de vakanties bij mijn vader).
In de 5 jaar dat ik als CAD tekenaar heb gewerkt, heb ik wel geprobeerd een Hogere Informatica opleiding te volgen op afstand. Daarvan de propedeuse gehaald en een groot deel van de hoofdfase, waar ik programmeren met C en C++ leerde.
Ook programmeerde ik allerlei tools voor de zaak (met Borland C++ Builder). Een facturatiesysteem, een AutoCAD script compiler, en diverse tools voor AutoCAD met AutoLISP en DCL (denk bijvoorbeeld aan block bibliotheken, automatisch materiaallijsten die gegenereerd werden, etc).
Na 5 jaar werken bij mijn vader boterde het niet meer zo tussen mij en hem. Alles ging altijd maar om werk, werk, nog meer werk. In de tussentijd vond ik het ook weleens fijn om in het weekend met mijn vriendinnetje naar het strand te gaan etc. En dat werd soms serieus een probleem, omdat er in het weekend nog dingen moesten worden afgemaakt, die maandag aan de klant waren beloofd.
Op een dag flikkerde ik de sleutels op tafel en was het einde oefening.
En dat was het moment dat ik een baan als junior developer ging zoeken. 3 maanden later als .NET ontwikkelaar begonnen bij een bedrijf. Daar 4 jaar lang C# en ASP.NET gedaan, en veel over SQL Server geleerd. Daarnaast certificaten gehaald (waaronder MCAD).
Toen van baan geswitcht en nu werk ik alweer 11 jaar lang voor mijn huidige werkgever als .NET ontwikkelaar. De eerste jaren veel ASP.NET gedaan, daarna wat uitstapjes naar het maken van iOS applicaties en uiteindelijk aan de core producten gaan werken (die helaas technisch gezien vooral Windows.Forms zijn, maar wel qua programma complexer zijn).
Tsja.
Nog wel diverse keren geprobeerd een opleiding te volgen. Ik heb 8 certificaten van de Open Universiteit, waaronder diverse voor het programmeren met Java. Maar naast een fulltime baan die op sommige momenten toch ook behoorlijk stressvol was, nooit volgehouden om echt voor een bachelor te gaan.
So here I am. Al 15 jaar aan het werk als programmeur
Ask yourself if you are happy and then you cease to be.
Tegen het eind van de middelbare school raakte ik geinteresserd in 3d rendering en demo's (software rasterization en raytracing, opengl, direct3d), om uiteindelijk na de universiteit (niet afgemaakt, wel had ik al een HBO diploma) aan de slag te gaan als game developer. En ik werk na 14 jaar nog bij exact datzelfde bedrijf als waar ik toen begon
Wat doe je nu dan?PageFault schreef op dinsdag 23 oktober 2018 @ 14:04:
In 2007 nam ik afscheid van de software ontwikkeling en sindsdien programmeer ik heel soms
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Tijdens mijn VWO N&T een Atheneum+ klas gevolgd met onder andere Informatica. Daar kwam ik in aanraking met hogere programmeertalen en methodieken. Toen kwam ik er ook achter dat ik geen interesse had in grafische applicaties, maar meer de CLI / backend dingen.
Daarom gekozen om HBO Technische Informatica te studeren. Daar heb ik 3,5 jaar over gedaan. Toen gaan werken bij een bedrijf dat modulaire bouwblokken maakt voor de televisie-industrie en na 8,5 jaar de overstap gemaakt naar een bedrijf dat zich richt op e-commerce. Daar werk ik nu aan de backend.
If money talks then I'm a mime
If time is money then I'm out of time
Sindsdien heb ik geen Minecraft meer gespeeld.
Omdat ik alles zelf leerde, was de volgorde soms nogal scheef. Zo leerde ik eerst multi-threaden en daarna pas was een klasse was. Tsja, die priem getallen generator zou niet sneller worden van klassen
Verder heb ik me bijzonder vermaakt in Unity, de game engine, waarin ik een multiplayer fps heb gemaakt en een door rock raiders geïnspireerd spel.
Na twee en een half jaar begon ik aan mijn opleiding HBO Technische Informatica waarvan ik nu in mijn laatste jaar zit. Ik had nog al een voorsprong op de rest van mijn medestudenten, dus ik heb in de lessen niet heel veel geleerd.
Op mijn werk, waar ik ook stage heb gelopen, heb ik een embedded LoRaWAN library geschreven in C++ en ben nu voor mijn school minor bezig met Windows C++ en OpenCL.
Less alienation, more cooperation.
Is het niveauverschil met WO Technische Informatica dan zo groot? Bij ons waren er wel een paar vakjes waar mensen met uitgebreide programmeerervaring iets voordeel hadden, maar dat helpt je met door de vele Calculus- en Algebravakken, alle modelleervakken, formele methoden en ga zo maar door.diondokter schreef op dinsdag 23 oktober 2018 @ 19:25:
Na twee en een half jaar begon ik aan mijn opleiding HBO Technische Informatica waarvan ik nu in mijn laatste jaar zit. Ik had nog al een voorsprong op de rest van mijn medestudenten, dus ik heb in de lessen niet heel veel geleerd.
Zelfs bij purely functional programming hadden mensen zelfs eerder nadeel dan voordeel van hun (vaak imperatieve) ervaring.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Tijdens mijn studie pas in aanmerking gekomen met C++, ASM en Java. Bij mijn huidige functie C#, TypeScript en React voornamelijk. Helaas draait er ook nog meuk op Ruby on Rails wat ik on the job er maar even bij geleerd heb. Niet iets waar ik meer ervaring mee wil opdoen trouwens. Wat een ontzettend vervelend framework vind ik dat.
//edit
Ik ben volgens mij een beetje laat bij de party. Discussie gaat alweer ergens anders nover. *schuifelt weer weg*
[ Voor 8% gewijzigd door WernerL op 23-10-2018 20:04 ]
Roses are red, violets are blue, unexpected '{' on line 32.
WO is veel theoretischer. Zelf kun je praktische dingen makkelijker aanleren dan theorie.Mugwump schreef op dinsdag 23 oktober 2018 @ 19:33:
[...]
Is het niveauverschil met WO Technische Informatica dan zo groot? Bij ons waren er wel een paar vakjes waar mensen met uitgebreide programmeerervaring iets voordeel hadden, maar dat helpt je met niet door de vele Calculus- en Algebravakken, alle modelleervakken, formele methoden en ga zo maar door.
Zelfs bij purely functional programming hadden mensen zelfs eerder nadeel dan voordeel van hun (vaak imperatieve) ervaring.
Een groot deel van de wiskunde en bijna alles wat met elektronica te maken had, was wel nieuw voor me, maar met het daadwerkelijke programmeren heb ik altijd die 2 jaar voorgelopen.
Functionele talen hebben we nooit behandeld. Er is alleen op gewezen dat ze bestaan en dat ze anders zijn. Voor de rest is het een half jaar C, een half jaar Java en een kwartiel C++. Daarna sta je er zelf voor en heb je geen echte 'programmeer' lessen meer (al moet je het natuurlijk nog wel gebruiken in de projecten).
🠕 This side up
Dynamisch getypeerd, en heel veel dingen zijn impliciet waardoor het bij grotere projecten vaak enorm lastig is om te begrijpen wat er gebeurd en waar het gebeurd. Het debuggen van grotere webapplicaties heb ik nooit echt als heel plezierig ervaren. Neemt niet weg dat ik op dat moment ook nog niet heel bekend was met de codebase en ik collegas heb die vinden dat hun code "self-documenting" is.Koenvh schreef op dinsdag 23 oktober 2018 @ 21:25:
@WernerL Ik ben wel geïnteresseerd waar je aversie tegen Ruby on Rails vandaan komt. Waar komt dat door?
En verder de syntax. De taal kent veel leuke truukjes maar is ook een stuk minder flexibel dan C-achtige talen. Aantal keren problemen gehad code op een nette manier uit te lijnen met identation-errors als gevolg.
Mijn voorkeur gaat gewoon uit naar een statisch getypeerde taal omdat de compiler zichzelf dan nog nuttig kan maken voordat ik de code uitvoer.
[ Voor 26% gewijzigd door WernerL op 23-10-2018 21:37 ]
Roses are red, violets are blue, unexpected '{' on line 32.
Ken dit gevoel wel...WernerL schreef op dinsdag 23 oktober 2018 @ 21:32:
[...]
Dynamisch getypeerd, en heel veel dingen zijn impliciet waardoor het bij grotere projecten vaak enorm lastig is om te begrijpen wat er gebeurd en waar het gebeurd. Het debuggen van grotere webapplicaties heb ik nooit echt als heel plezierig ervaren.
Ik kreeg een hekel aan Rails vanwege alle "magie" die op de achtergrond gebeurt. De meeste dingen zijn echt goed beschreven, maar die ene edgecase waar je tegenaan loopt of iets wat je op een nét iets andere manier wil oplossen is dan vaak niet te fixen of te begrijpen tot een guru je er wat meer over vertelt.
Vaak komt het erop neer dat je dan wat gems moet inladen om de functionaliteit te regelen die je zoekt, maar als die dan weer net anders is dan je nodig hebt moet je weer van alles doen om jouw oplossing werkend te krijgen, óf je moet belachelijk veel Ruby zelf schrijven om letterlijk om het framework heen jouw eigen stuk functionaliteit te bouwen.
Ik werk zelf liever met iets als Spring (Java, of kotlin/scala, waar ik dan eens zin in heb
Natuurlijk staat en valt bovenstaande waarschijnlijk met de hoeveelheid ervaring die je hebt met de taal / het framework in kwestie, maar ik vind Rails lang niet zo'n "instapframework" als de echte Ruby-liefhebbers beweren.
Disclaimer: ieder zo zijn ding, mocht iemand zich aangevallen oid voelen hierdoor; niet mijn bedoeling en even goede vrienden
Overigens heb ik nooit indention errors meegemaakt in rails code. Ik vermoed dat je het hebt over linebreaks?
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Ja en nee. Ik ging ook gewoon voetballen met vrienden en was gek op martial arts.
Met de echte nerds op school ging ik maar oppervlakkig om. We gingen weleens bij elkaar thuis computerspelletjes spelen. Old skool, multi player op hetzelfde toetsenbord
Maar voor de rest begreep ik hun passies niet zo. Ze waren helemaal lijp van magic kaarten, wilden per se naar van die comic stores, hielden van science fiction.
Ik heb nog steeds geen enkele Star Wars of Star Trek film gezien.
En dat terwijl ik de videotheek zo ongeveer uit mijn hoofd kende m.b.t. alle actiekomedies uit de 90's. Ik keek echt veel films
Ask yourself if you are happy and then you cease to be.
GQBasic en QBasic, jeugdsentiment.oisyn schreef op dinsdag 23 oktober 2018 @ 17:56:
Toen ik 8 was begonnen met programmeren in GW-Basic. Dat stelde toen natuurlijk nog niet veel voor, maar met een paar listings overtypen uit de ComputerTotaal of PCM oid was mijn interesse wel gewekt en toen heeft mijn vader wat kinderboekjes gekocht over basic. In de brugklas ontmoette ik wat klasgenootjes die ook konden programmeren, en zo ging ik van GW-Basic naar QB, Pascal, ASM, C en uiteindelijk C++.
Tegen het eind van de middelbare school raakte ik geinteresserd in 3d rendering en demo's (software rasterization en raytracing, opengl, direct3d), om uiteindelijk na de universiteit (niet afgemaakt, wel had ik al een HBO diploma) aan de slag te gaan als game developer. En ik werk na 14 jaar nog bij exact datzelfde bedrijf als waar ik toen begon
[...]
Wat doe je nu dan?
Ik werk nu in de printer business voor de implementaties (meer configuratie en vooral veel troubleshooting) voor complexe print en scan oplossingen. Veel interactie met andere suppliers, veel koppelvlakken, dus veel zaken waar het mis kan gaan en vooral: waar veel te ontwikkelen is. Wanneer het echt moet, knutsel ik iets in elkaar om het aan het werk te krijgen, maar het liefst zo min mogelijk.
Verwijderd
ar en zit nu in het 2e jaar daarvan).
Ik programmeer al sinds mijn 11e, voornamelijk in Python. Bij mijn 1-daagse snuffelstage vorig jaar bij een *NIX consulting bedrijf zeiden ze dat ik op "MBO-ICT eindexam
enniveau" zit.
Ik heb nu eigenlijk geen vrienden, want in mijn klas zitten alleen een groepje jongens (en 1 meisje) die bijna allemaal 18 zijn, mij niet mogen en het ook eigenlijk alle
en maar over alcohol, wiet, meisjes en games hebben (wat mij allemaal niks boeit). Dan is er ook nog een groepje jongens die een beetje 'kinderachtig' zijn en in de pauz
es doen alsof ze een dino ofzo zijn, maar verder zijn zij op zich wel aardig, alleen heb ik niet zoveel fantasie om het maar zo te zeggen.
Op mijn basisschool had ik wel een paar vrienden, waarmee ik na school ook veel buiten speelde (vaak een soort zelf verzonnen combinatie tussen verstoppertje en tikkertj
e, maar dan vaak ook door een redelijk groot gebied). Helaas is mijn beste vriend naar Engeland verhuist, omdat zijn vader eerst in Sri Lanka een goudsmid was en in Nede
rland geen baan kon vinden als goudsmid, dus had hj de hele tijd van die bijbaantjes als krantenbezorger ofzo, maar toen had een vriend van die vader waarmee hij goudsmi
d was in Sri Lanka een baan gevonden in Londen, en zijn ze daar dus heen verhuisd.
Nu zit ik dus eigenlijk alleen achter mijn computer in mijn vrije tijd (en ook op school in alle uren dat ik geen les hebt, wat er sowieso 11 zijn, want dan moet ik wel
op school zijn en aangezien ik meestal al mijn huiswerk af heb, mag ik zelf weten wat ik doe), wat op een gegeven moment ook wel gaat vervelen.
[ Voor 0% gewijzigd door Microkid op 27-12-2018 16:49 ]
Die vlieger gaat wat mij betreft ook op voor Laravel. Leuk framework, maar te veel dingen die op achtergrond gedaan worden waardoor je soms geen idee hebt waar je het moet zoeken. Daarnaast krijg je ook nog regelmatig stacktraces waar je niks mee kunt.WernerL schreef op dinsdag 23 oktober 2018 @ 21:32:
[...]
Dynamisch getypeerd, en heel veel dingen zijn impliciet waardoor het bij grotere projecten vaak enorm lastig is om te begrijpen wat er gebeurd en waar het gebeurd. Het debuggen van grotere webapplicaties heb ik nooit echt als heel plezierig ervaren. Neemt niet weg dat ik op dat moment ook nog niet heel bekend was met de codebase en ik collegas heb die vinden dat hun code "self-documenting" is.
En wat dynamisch getypeerd betreft: ik zit hard te wachten op PHP 7.4. Daarin krijgen we typed properties.
Ben nu zelf mijn eerste software renderer aan het leren maken from scratch aan de hand van deze tutorial, maar dan in c# ipv C: Van het tekenen van een enkel puntje door bytes naar memory te schrijven, tot een volledig 3D model met correcte texturen, belichting en shaders..oisyn schreef op dinsdag 23 oktober 2018 @ 17:56:
Tegen het eind van de middelbare school raakte ik geinteresserd in 3d rendering en demo's (software rasterization en raytracing, opengl, direct3d), om uiteindelijk na de universiteit (niet afgemaakt, wel had ik al een HBO diploma) aan de slag te gaan als game developer. En ik werk na 14 jaar nog bij exact datzelfde bedrijf als waar ik toen begon
Het ging allemaal vrij vlot zolang ik geen translations/rotations moest doen. Nu gaat de wiskunde mij echter wat mijn pet te boven om het allemaal te snappen
'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind.' - Pratchett.
Ik ben sinds dit weekend aan het spelen met Laravel. Best leuk framework!dev10 schreef op woensdag 24 oktober 2018 @ 09:33:
[...]
Die vlieger gaat wat mij betreft ook op voor Laravel. Leuk framework, maar te veel dingen die op achtergrond gedaan worden waardoor je soms geen idee hebt waar je het moet zoeken. Daarnaast krijg je ook nog regelmatig stacktraces waar je niks mee kunt.
Zakelijk werk ik in Ruby on Rails (

RoR ken ik eigenlijk alleen van Gitlab CE en ik moet zeggen dat de mate van magie me wel "un peux nerveux" maakt als je er iets mee moet doen onder de motorkap (om nog maar te

Wel interessant dat eigenlijk elke min of meer dynamische taal nu wel (de mogelijkheid) tot statische typing krijgt.
[ Voor 17% gewijzigd door gekkie op 24-10-2018 10:36 ]
Ik begrijp prima dat Laravel een leuk framework is en als ik even snel iets in elkaar moet zetten gebruik ik ook vaak Laravel, maar op het moment dat ik een iets uitgebreidere applicatie bouw grijp ik liever terug op Symfony. Al die syntactic sugar in Laravel is leuk, maar het maakt het ook heel makkelijk om code te schrijven die lastig af te dekken is met unit-tests.Ryur schreef op woensdag 24 oktober 2018 @ 10:19:
[...]
Ik ben sinds dit weekend aan het spelen met Laravel. Best leuk framework!
Zakelijk werk ik in Ruby on Rails (). Merk dat die achtergrond mij wel helpt in Laravel trouwens!
[ Voor 12% gewijzigd door dev10 op 24-10-2018 10:37 ]
Cool!boe2 schreef op woensdag 24 oktober 2018 @ 10:15:
Ben nu zelf mijn eerste software renderer aan het leren maken from scratch
Op zich kun je best ver komen zonder de onderliggende wiskunde te begrijpen. De onderliggende vector en matrixoperaties zijn wel over te typen, daarna is het simpelweg het conceptueel toepassen van transformaties.Het ging allemaal vrij vlot zolang ik geen translations/rotations moest doen. Nu gaat de wiskunde mij echter wat mijn pet te boven om het allemaal te snappen
Oei, OpenGL "werkt" niet, het is een API.
[ Voor 7% gewijzigd door .oisyn op 24-10-2018 10:43 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
https://niels.nu
December 2019 dusdev10 schreef op woensdag 24 oktober 2018 @ 09:33:
[...]
En wat dynamisch getypeerd betreft: ik zit hard te wachten op PHP 7.4. Daarin krijgen we typed properties.
Vrijwilligerswerk is ook een goede manier om andere mensen te leren kennen. Probeer vrijwilligerswerk te zoeken waarbij je vooral fysiek aan de slag moet. Het mag lekker simpel werk zijn, gewoon even lekker bikkelen is heerlijk!Hydra schreef op woensdag 24 oktober 2018 @ 14:01: Wel is je sociale ontwikkeling in de leeftijd waarin je nu ziet enorm belangrijk; dus misschien toch eens kijken of je een sport of hobby kunt ontwikkelen waar je mensen leert kennen? Alleen maar binnen zitten wordt je ook niet socialer van
20 jaar geleden beginnen met Visual Basic 6 is geen schande, maar als je het nu nog gebruikt is er toch ergens iets niet goed gegaan
Ask yourself if you are happy and then you cease to be.
Kan geen kwaad om even wat lineaire algebra te leren als je dat doet inderdaad. Op zich is dat ook geen extreem moeilijke wiskunde.boe2 schreef op woensdag 24 oktober 2018 @ 10:15:
[...]
Ben nu zelf mijn eerste software renderer aan het leren maken from scratch aan de hand van deze tutorial, maar dan in c# ipv C: Van het tekenen van een enkel puntje door bytes naar memory te schrijven, tot een volledig 3D model met correcte texturen, belichting en shaders.
Het ging allemaal vrij vlot zolang ik geen translations/rotations moest doen. Nu gaat de wiskunde mij echter wat mijn pet te boven om het allemaal te snappen
Heb zelf enkel tijdens m'n studie wat gedaan met 3D programming en de eerste poging leverde ook wel een vrij spastisch dansend poppetje op.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
https://www.quora.com/My-...-the-amount-I-need-to-pay
https://wptavern.com/ryan...-in-a-6000-bill-overnight
https://dev.to/juanmanuel...-amazon-web-services-17fn
Natuurlijk zijn veel van deze voorbeelden simpelweg domme fouten die de gebruikers hebben gemaakt, maar het feit dat je geen keiharde limiet op de kosten kunt plaatsen, vind ik toch een beetje eng en is ook de reden dat ik neig naar het gebruiken van een dienst met een flat fee.
En ja, ik weet:
- Gebruik IAM security, zodat de keys beperkte rechten hebben.
- Gebruik 2 factor authentication.
- Don''t be stupid and don't share your keys.
Dan nog ben ik ook wat huiverig voor die dag dat mijn websites met een DDOS te maken krijgen. Stel ze staan bij zo'n flexibele cloud provider die vrolijk opschaalt, dan wordt dit ook een dure grap.
Kortom, hoe gaan jullie om hiermee?
Ik heb het ook niet echt in mij om elke dag die dingen in de gaten te houden en goede kans dat zo'n mailtje met een billing alert op de grote hoop eindigt bij mij

Een vast bedrag per maand betalen klinkt een stuk aantrekkelijker.
PS
AWS of Azure introduceren op mijn werk vind ik hierdoor ook een beetje eng. Je zou maar degene zijn die het adviseert en vervolgens de werkgever onbedoeld op kosten jaagt... (al dan niet omdat een collega een keer niet oplet)
[ Voor 7% gewijzigd door Lethalis op 24-10-2018 16:09 ]
Ask yourself if you are happy and then you cease to be.
Dit topic is gesloten.
Dit topic is niet de plaats om te lopen helpdesken. De Coffee Corner is primair bedoeld als uitlaatklep voor iedereen in de Devschuur® en niet als vraagbaak.