Het was in totaal een paar duizend pond dus dat hakt er wel lekker in als het een goede doelen project is en dus geen betalende klant ofzo
Ik zou een 200 met een lege array sturen. Je gaat niet specifiek opzoek naar een item die niet gevonden is, je wilt gewoon alle items ophalen. Als dat er geen zijn, dan is de request succesvol, maar is de data gewoon leeg. Als je een item opzoekt met een ID, dan faalt de request want het ID is niet bekend. Dus een 200 lijkt me logischer.:
[...]
Het was in totaal een paar duizend pond dus dat hakt er wel lekker in als het een goede doelen project is en dus geen betalende klant ofzo
Ik heb hier een discussie als je een endpoint /items hebt en vervolgens zijn er geen items in de datasource moet je dan 200 met lege array of juist 404 terug sturen als API zijnde?
Ik zit in de juiste hoek, alleen woon niet meer in Noord-Brabant. Maar ik zal het onthouden als de andere gesprekken niets worden.
[ Voor 41% gewijzigd door WernerL op 02-06-2020 18:35 ]
Roses are red, violets are blue, unexpected '{' on line 32.
200 met lege array. Het is gewoon een normaal 'correct' antwoord en de resource bestaat gewoon.
https://niels.nu
Je hebt ook Hired.com, Talent.io, Okta.com:
Honeypot is trouwens geweldig. Europees platform waarop bedrijven uit hoofdzakelijk Duitsland, Nederland en Engeland jouw kunnen contacten. Ondertussen al van een 6-tal bedrijven bericht ontvangen waar ik een kennismakingsgesprek mee in kan plannen. In totaal blijft mijn profiel 5 weken online dus ik verwacht dat ik wel met genoeg bedrijven kan spreken als dat op dit tempo doorgaat.
Ja precies, zou sta ik er ook in
Ik heb eigenlijk alleen 204 gebruikt bij PUT acties
[ Voor 15% gewijzigd door alienfruit op 02-06-2020 23:34 ]
Heb me net bij een paar van die websites aangemeld als zijnde werkgever, ik ben heel benieuwd of er iets goeds uit komt:
[...]
Je hebt ook Hired.com, Talent.io, Okta.com
Ik kende ze allemaal niet dus er gaat een wereld voor mij open iig:
Ja, Hired is een leuke site. Daar heb ik als werkzoekende goede ervaringen mee. Talent.io hoor je meer van Nederlandse bedrijven als in het VK zit. Succes
en het komt op een geschikt moment; het andere leukste bedrijf uit Noord-Brabant (dat van mij 
) is ook hard aan de weg aan het timmeren.
https://niels.nu
Vraag en aanbod:
Ben nog steeds op zoek naar een goeie site voor ZZPers zonder dat daar ranzige recruiters tussen zitten. Het had zo mooi kunnen zijn met Elect
Closures begin ik te snappen, maar protocols gaan er moeilijk in (enige voorkennis is een beetje php & HTML). Ik ga ze een paar keer in de praktijk moeten tegenkomen of schrijven voor ik er echt iets van begrijp of er een meerwaarde in zie.
Ah, ik had juist gelezen dat de grootste wijzigingen achter de rug zijn, dat de taal een pak volwassener is dan vroeger (Swift 3 - The Grand Rename
). Samen met Catalyst heeft dat mij over de streep getrokken om voor Swift te gaan tov andere programmeertalen.
🠕 This side up
"er mee kunnen werken" heeft ook nogal wat levels.
1
2
| git commit -am 'changes of [date]' git push |
) documentatie.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Nee, niet perse expert (alle ins en outs), maar je basiskennis. Ik vind git nou ook niet echt puur een developers skill. Het komt op zoveel vlakken terug en zeker met een beetje 'modern werken' (lees: infra-as-code, devops, etc), zou je toch minimaal een checkout, pull, commit, push en merge/pull -request onder de knie kunnen hebben.
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Zodra je er mee in aanraking komt vind ik zeker dat je best even tijd mag investeren in het bekend raken met het. Gelukkig val ik nog niet in de professionals die 5k+ verdienen groep dus ik mag nog rustiger aan doen:
[...]
Nee, niet perse expert (alle ins en outs), maar je basiskennis. Ik vind git nou ook niet echt puur een developers skill. Het komt op zoveel vlakken terug en zeker met een beetje 'modern werken' (lees: infra-as-code, devops, etc), zou je toch minimaal een checkout, pull, commit, push en merge/pull -request onder de knie kunnen hebben.
Of je nu in netwerken, beheer, of whatever zit, is dit toch wel iets wat overal terug kan komen.
Als ik het nou op mijzelf reflecteer en ik kom iets nieuws tegen wat iedereen gebruikt (incl. de organisatie waar ik werk) dan gooi ik er toch echt wel even wat energie tegenaan om minimaal iets er mee te kunnen.
En nog los van dat allemaal, je hebt het uiteindelijk wel over professionals die 5k+ verdienen en allemaal zo agile moeten zijn. Je mag dan IMO wel enige vorm van basisskill IT verwachten.
Overigens was het ook een rant. Gezien dat de devschuur ook een uitlaapklep is
(en ja het was overduidelijk een rant)
Oh ik zie de voordelen echt wel, maar het blijft toch wel een dingetje dat omschakelen naar een taal die net een wat andere syntax heeft voor mensen die al moeite hebben om niet in een Pavlov-reflex weer een try-catch-finally constructie te copy-pasten, maar in plaats daarvan eens een try-with-resources te gebruiken. Java 7 is ook pas 9 jaar oud natuurlijk, dus dat is ook wel erg nieuwerwets.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Rust al overwogen ?:
Daar zitten al zoveel uitdagingen in dat ook nog even verwachten dat vastgeroeste devs over gaan stappen op Kotlin niet hoog op de prioriteitenlijst.
Ik zat meer aan Cola te denken.:
[...]
Rust al overwogen ?
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
wat elders een unit-test is, is daar de "pepsi-test" ?Dat hangt ervan af wat je website doet, en hoe gevoelig dat is. Voorbeeldje: je hebt een endpoint POST /maak-geld-over-naar-Koen, die op basis van cookies geld overmaakt van de rekening van de ingelogde gebruiker naar mij. Zonder CORS kan ik op appelflap.nl niet met Javascript automatisch een POST request doen naar dat endpoint zonder dat de gebruiker dat doorheeft (je browser blokkeert dat). Als je "*" instelt, dan mag opeens elke website dat doen, zonder dat de eindgebruiker dat doorheeft (meer geld voor mij dus
).
🠕 This side up
Ja, ik wilde enkele van onze eigen domeinen in de Allow-Origin lijst slingeren ipv. *. Dat zou toch prima moeten kunnen en zonder dat het problemen kan veroorzaken zolang je Safe Content Policy, Same Origin headers ook goed hebt staan? Inderdaad wil ik geldmaschhhinnne.nl niet geld kunnen overmakenDat hangt ervan af wat je website doet, en hoe gevoelig dat is. Voorbeeldje: je hebt een endpoint POST /maak-geld-over-naar-Koen, die op basis van cookies geld overmaakt van de rekening van de ingelogde gebruiker naar mij. Zonder CORS kan ik op appelflap.nl niet met Javascript automatisch een POST request doen naar dat endpoint zonder dat de gebruiker dat doorheeft (je browser blokkeert dat). Als je "*" instelt, dan mag opeens elke website dat doen, zonder dat de eindgebruiker dat doorheeft (meer geld voor mij dus
In principe is elk domain die je in je allow-origin list opneemt een extra attack vector. Er hoeft immers maar op 1 van die sites een XSS injectie bug te zitten, of "externe" compromised scripts geladen te worden en dan ben je vatbaar voor aanvallen.:
[...]
Ja, ik wilde enkele van onze eigen domeinen in de Allow-Origin lijst slingeren ipv. *. Dat zou toch prima moeten kunnen en zonder dat het problemen kan veroorzaken zolang je Safe Content Policy, Same Origin headers ook goed hebt staan? Inderdaad wil ik geldmaschhhinnne.nl niet geld kunnen overmaken
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
1
2
3
4
5
6
| await fetch("http://api", options)
.then(async response => {
await response.json().then(async json => {
// ... und so weiter
}
}) |
Engineering is like Tetris. Succes disappears and errors accumulate.
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
Biertje iemand? Het is warm.
[ Voor 15% gewijzigd door Hydra op 17-06-2020 16:55 ]
https://niels.nu
Wit of bruin biertje?:
Nou, dat was een enerverende dag. Om een of andere reden niet erg productief
Lekker op de bank
Ben net neer geploft met een weizen in het zonnetje, gelukkig ook weer wat nog niet gecommite code terug gevonden op m'n andere flap, dus ook nog buitengewoon productief:
Nou, dat was een enerverende dag. Om een of andere reden niet erg productief
.
[ Voor 30% gewijzigd door gekkie op 17-06-2020 17:09 ]
Je zou toch hopen dat overheid en co onderhand dan wel dual-browser is.
.
[ Voor 10% gewijzigd door gekkie op 17-06-2020 17:10 ]
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
Reken er maar niet op.:
Je zou toch hopen dat overheid en co onderhand dan wel dual-browser is.
Eentje (IE) voor de kansloze legacy intranet meuk.
Andere voor het grote boze internet (cq wat modernere intranet applicaties).
Ook al moet ik bekennen dat ik ook nog een windows xp VM heb rondslingeren op met whooping activex ip-camera settings te kunnen wijzigen
"Nee dan raken de gebruikers in de war" of "Nee, IT support geen Chrome want dat is onveilig".
[ Voor 19% gewijzigd door Hydra op 17-06-2020 17:48 ]
https://niels.nu
Pale ale lag er ook, welliswaar niet zelf gebrouwen, maarja moet toch keuzes maken.:
, niet mijn smaak. Ik pak lekker een zelf gebrouwen New England IPA
, beetje net als het gedonder waar de zon inmiddels al weer plaats voor heeft gemaakt.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
In mijn geval is het deels wel degelijk een vervanging. Het project waar ik nu aan werk krijgt redelijk wat data aangeleverd in kleine berichtjes (~30-50 miljoen per dag). Die moeten zsm verwerkt worden wanneer de aanleveringen binnen redelijke marges (er slaan nog wel eens wat systemen in de keten op hol die zorgen voor een soort van interne DDoS
) blijven. Dat soort asynchrone berichtverwerking bestaat uit een aantal kleine stapjes als archiveren voor auditing doeleinden, een anticorruptionlayer voor basale validatie / mappen naar een consistent intern formaat en het toepassen van wat basale businesslogica en het vastleggen van events in een database. Die stapjes kun je prima laten doen door een AWS Lambda, terwijl je SQS inzet (of AWS step functions eventueel) voor het (ont)koppelen van de stapjes. "The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Oh dat klinkt gaaf.:
[...]
In mijn geval is het deels wel degelijk een vervanging. Het project waar ik nu aan werk krijgt redelijk wat data aangeleverd in kleine berichtjes (~30-50 miljoen per dag). Die moeten zsm verwerkt worden wanneer de aanleveringen binnen redelijke marges (er slaan nog wel eens wat systemen in de keten op hol die zorgen voor een soort van interne DDoS
Daarmee heb je een oplossing die heel snel kan schalen. Die lambda's stel je namelijk gewoon in op een maximaal aantal concurrent executions om te bepalen wat de maximale throughput is die je wilt ondersteunen. Is er geen aanlevering dan zijn je kosten praktisch nul, komen er bakken data binnen, dan draait de boel op maximale capaciteit. Door gebruik te maken van SQS en DynamoDB zorg je ook dat je geen externe bottlenecks creëert. Wat je namelijk nog wel eens ziet is dat mensen zo'n serverless function bouwen die als een idioot kan schalen, maar die wel afhankelijk maken van externe services / databases die niet helemaal opgezet zijn volgens de schaal maar raak voor een knaak gedachte met als gevolg dat je die databases of exteren services overlaadt en je systeem alsnog vastloopt.
Yep, dat is dus SQS.:
[...]
Oh dat klinkt gaaf.
En hoe koppel je die losse lambda's dan weer? Doe je dat dan met een message broker ertussen?
[ Voor 32% gewijzigd door Mugwump op 18-06-2020 11:58 ]
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Ja dat diagram was ik ook tegengekomen op Twitter ja, zag er wel wat indrukwekkend uit zo op het eerste gezicht.:
[...]
Yep, dat is dus SQS.
Dat is dus ook weer 'serverless' dus eigenlijk doe je niet veel meer dan een queue aanmaken. Het hele beheer van de message broker is voor je weggeabstraheerd en je betaalt eigenlijk enkel nog per lees- / schrijfactie. Dat gaat al wel vrij snel in de kosten lopen, dus wij gebruiken wel waar mogelijk / nodig de batchvarianten waarbij je tot 10 berichten per keer kan lezen / schrijven.
Als je reguliere queues gebruikt, dan schaalt het eigenlijk vrijwel oneindig (voor onze behoeften iig). Je hebt ook nog FIFO queues voor zaken als ordering en exactly once delivery die een stuk beperkter zijn qua throughput, maar in mijn ogen moet je schaalbare message processing gewoon lekker idempotent maken. Je kunt wel leuk je message broker alles precies één keer laten aanleveren, maar het komt in de praktijk gewoon regelmatig voor dat (bulk)processen bij aanleverende systemen klappen en herstarten, waardoor je als nog dubbele aanleveringen krijgt.
Nadeel van SQS an sich is wel dat de berichtgrootte is beperkt tot 256kb. Op zich geen ramp, maar dat betekent wel dat je naar alternatieve oplossingen moet kijken indien berichten ook (incidenteel) groter kunnen zijn dan 256kb.
Edit: Het is ook niet per definitie veel complexer dan 'traditionele verwerking' in ons geval hoor. We hadden altijd al message queues voor ontkoppeling tussen delen van het proces (in ActiveMQ) en feitelijk werd het consumeren van berichten ook gewoon gedaan door stukjes code, maar dan in de vorm van Message Driven Beans in enorme monolitische applicaties op logge applicatieservers. Kwam toevallig laatst nog een Twitterdraadje tegen waarin ook wat werd geklaagd over de 'complexiteit' van serverless architecturen met wat AWS plaatjes. En ja als je 5 losse Lambda's met Queues tekent zijn dat meer icoontjes dan wanneer je 5 queues tekent en die allemaal verbindt aan slechts één applicatieserver, maar daarin abstraheer je dan feitelijk alle onderliggende complexiteit gewoon weg. Vergeet ook niet dat je bij Lambda's en SQS allerhande monitoring en logging gewoon out-of-the box krijgt en dat door zaken zichtbaar uit elkaar te trekken het veel makkelijker is om eventuele bottlenecks in je proces te signaleren. In oude on-premise systemen die wij nog beheren zie je vaak dat er performance issues zijn op die gigantische applicatieservercluster waardoor berichtverwerking tot stilstand komt en het aloude 'have you tried turning it off and on again?' maar letterlijk gescript is omdat dat vaak het probleem oplost en men al maanden tevergeefs heeft proberen te achterhalen waar nou de bottleneck zit.
Maar het klinkt wel erg vet allemaal, bij mijn vorige stage gewerkt met micro services en RabbitMQ dat vond ik al erg indrukwekkend.
Ach, laat je ook niet afschrikken door achitectuurdiagrammen hoor, daar leer je wel doorheen kijken. De wat grootschaligere IT-oplossingen zijn nou eenmaal vaak ook redelijk complex en in de loop der jaren gegroeid waardoor het al snel overweldigend lijkt. Stel je begint met een simpele webapplicatie met een SQL database eronder. Feitelijk teken je die als een diagram met twee blokje, lekker overzichtelijk. Dan blijkt toch dat voor de zoekfunctionaliteit die SQL database niet meer voldoet en je daar iets als ElasticSearch wilt inzetten. Dat wil je dan misschien weer laten vullen door een procesje dat om de zoveel tijd op de achtergrond draait of zelfs triggert op basis van berichtjes die op een message broker worden gezet. Dat levert alweer een paar nieuwe blokjes op. Misschien krijg je wel enorm veel bezoekers die vaak hetzelfde bekijken waardoor je database heel zwaar belast wordt en besluit je iets van caching met Redis te gaan toevoegen, nog meer blokjes! En zo ga je van twee blokjes naar een heel indrukwekkend uitziend diagram.:
[...]
Ja dat diagram was ik ook tegengekomen op Twitter ja, zag er wel wat indrukwekkend uit zo op het eerste gezicht.
Geen idee eigenlijk of het bedrijf waar ik nu aan het afstuderen ben en binnenkort ga werken al iets doen met "serverless" eigenlijk, ik weet wel dat ze met FireBase werken.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Funny story; onder water doet AWS "gewoon" aan polling op de SQS. Collega had privé wat zaken aan een SQS geknoopt, maar zette nog geen data op de queue. Maar er werden wel kosten gemaakt. Bleek te komen doordat AWS elke x tijd een read-actie uitvoerde om te kijken of er nieuwe items in de queue staan. Maar het blijft mooi speelgoed
Read the code, write the code, be the code!
Klopt, dat staat ook wel ietwat verborgen vermeld in de documentatie. Ze raden namelijk Long Polling onder andere aan vanwege kostenreductie::
[...]
Funny story; onder water doet AWS "gewoon" aan polling op de SQS. Collega had privé wat zaken aan een SQS geknoopt, maar zette nog geen data op de queue. Maar er werden wel kosten gemaakt. Bleek te komen doordat AWS elke x tijd een read-actie uitvoerde om te kijken of er nieuwe items in de queue staan. Maar het blijft mooi speelgoed
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Er wordt in mijn ogen te vaak naar oude situaties gekeken en kennis blijft bij dit soort IT-beheerders vaak niet op pijl. Uitzonderingen daargelaten overigens, ik wil niet iedereen over een kam scheren maar zie dit in mijn (professionele) omgeving best vaak gebeuren. Omdat browser merk 'X' ooit slecht uit een test kwam, vinden we m nu nog steeds onveilig, het heeft dan vaak ook geen zin om de discussie aan te gaan, want overtuigen lukt toch niet.:
[...]
"Nee dan raken de gebruikers in de war" of "Nee, IT support geen Chrome want dat is onveilig".
Ja echt. Beiden heb ik gehoord als reden om op een IE versie te blijven die nog ActiveX gebruikt.
Oh ja; en daarvoor hadden ze ook Windows XP nodig, want nieuwere versies ondersteunden die antieke IE niet
Hoop dat ze daar nu wel voorbij zijn, dat was 10 jaar terug ofzo.
Naast SQS kan je ook allerlei andere events gebruiken als trigger om Lambda functies aan elkaar te koppelen. Je kan bijvoorbeeld de Lambda laten draaien voor nieuwe Items in een DynamoDB-tabel, of voor nieuwe bestanden in een S3-bucket.:
[...]
Oh dat klinkt gaaf.
En hoe koppel je die losse lambda's dan weer? Doe je dat dan met een message broker ertussen? Oh of is SQS daarvoor. Ziet er aardig complex uit wel maar wel vet.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Misschien was @armageddon_2k1 wel documentatie aan het schrijven? Kunnen genoeg redenen zijn waarom een developer veel schrijft zonder dat het code is.:
[...]
Tijd voor een IDE met auto-complete?
. Waarvan ik ook bergen handige features wel gebruik, maar autocomplete echt een stuk minder.
2x Dell UP2716D | R9 7950X | 128GB RAM | 980 Pro 2TB x2 | RTX2070 Super
.oisyn: Windows is net zo slecht in commandline als Linux in GUI
Ik zit al kneedeep in Jetbrains:
[...]
Tijd voor een IDE met auto-complete?
[ Voor 23% gewijzigd door armageddon_2k1 op 19-06-2020 07:25 ]
Engineering is like Tetris. Succes disappears and errors accumulate.
Dit topic is gesloten.
:strip_exif()/u/80759/monstermania_small.gif?f=community)
/u/12668/hydra.png?f=community)
:strip_icc():strip_exif()/u/77332/crop5e54ec42433bc_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/437778/crop684040f89be83_cropped.jpg?f=community)
/u/262310/ava.png?f=community)
:strip_exif()/u/259931/stuiterbal2.gif?f=community)
:strip_icc():strip_exif()/u/36003/crop584e9e5c223bd.jpeg?f=community)
:strip_exif()/u/47168/loop.gif?f=community)
:strip_icc():strip_exif()/u/6143/rincewind.jpg?f=community)
:strip_icc():strip_exif()/u/36083/crop5dca9e34ce091_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/68028/crop5c0ef8207f712_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/174665/crop5f3505845c31b_cropped.jpeg?f=community)
/u/105842/Homer_60x60.png?f=community)
/u/189240/av70.png?f=community)
/u/243953/crop56f55a7bcf291.png?f=community)
:strip_icc():strip_exif()/u/492949/crop627d0c893ea0e_cropped.jpg?f=community)
:strip_exif()/u/48440/crop6130a5af754ae_cropped.webp?f=community)
/u/175723/crop5dbbf867e8d37_cropped.png?f=community)
:strip_exif()/u/306933/ezgif.com-optimize.gif?f=community)