De Devschuur Coffee Corner - Iteratie ⓬

[kenneth]

Ik ben een groot fan van CLI, ben zelfs redelijk handig in vi, maar sommige dingen gaan sneller in de GUI. Voor commit, push, pull, branch, merge de cmdline; voor diffs, cherrypicking en conflicts liever een GUI. Momenteel is dat Git Extensions, maar ik ben er zeker niet mee getrouwd

[ThomasG]

GrooV schreef op maandag 13 januari 2020 @ 10:12:
Gewoon CMD git gebruiken, als je het eenmaal onder de knie hebt dan wil je niet anders

Behalve de programmeurs die op een Windows systeem werken, en last van het PATH-hell

[kenneth]

ThomasG schreef op maandag 13 januari 2020 @ 11:01:
[...]
Behalve de programmeurs die op een Windows systeem werken, en last van het PATH-hell

Git Bash

[Gamebuster]

We mogen from-scratch weer een API maken. We hebben hiervoor Graphql gebruikt in meerdere projecten, maar het is verassend ingewikkeld voor gebruikers blijkbaar. Ik heb echt hele rare requests gezien. Volgens mij doen sommige gebruikers zelfs gewoon strings in queries plakken, bijv.

code:

'{ myThings(nameContains: "' . $name . '") { id name } }'

Als je ze dan uitlegt dat er gewoon Graphql clients zijn mag ik ze gaan uitleggen hoe die werken. Query + variables concept is ook veeeel te ingewikkeld blijkt uit ervaring.

Ik twijfel of ik gewoon weer JSON/REST APIs gebruik voor dit project... Misschien JSON:API eens proberen. Nog niet eerder zelf een JSON:API... api gemaakt.

[ Voor 33% gewijzigd door Gamebuster op 13-01-2020 15:31 ]

[alienfruit]

Ik zit nu al twee uur te klungelen met Jenkins en secrets. Ik heb twee credentials toegevoegd aan Credentials store en vervolgens probeer dus deze op te halen met de credentials()-helper in een environment-blok. Denk maar niet dat het werkt! Ik zou niet weten hoe je dit kan debuggen

[Sandor_Clegane]

Oh, ik was doorgegaan met drone CI en ik kan het van harte aanbevelen mocht je flauw worden van Jenkins.

Voor de rest heb ik niks, sorry.

[armageddon_2k1]

Gamebuster schreef op maandag 13 januari 2020 @ 15:28:
We mogen from-scratch weer een API maken. We hebben hiervoor Graphql gebruikt in meerdere projecten, maar het is verassend ingewikkeld voor gebruikers blijkbaar. Ik heb echt hele rare requests gezien. Volgens mij doen sommige gebruikers zelfs gewoon strings in queries plakken, bijv.

code:

'{ myThings(nameContains: "' . $name . '") { id name } }'

Als je ze dan uitlegt dat er gewoon Graphql clients zijn mag ik ze gaan uitleggen hoe die werken. Query + variables concept is ook veeeel te ingewikkeld blijkt uit ervaring.

Ik twijfel of ik gewoon weer JSON/REST APIs gebruik voor dit project... Misschien JSON:API eens proberen. Nog niet eerder zelf een JSON:API... api gemaakt.

Praat me er niet van. Wij hebben een GraphQL api en we gebruiken die ook intern. Heerlijk is het om mee te werken vooral omdat ons data model er zo mooi op mapped. Maar onze externe API gebruikers lijken er erg veel moeite mee te hebben..... documentatie wordt sowieso niet gelezen en hun code kloppers denken niet zelf na maar willen gewoon code kloppen. Externe koppeling welke ik in 1 maand gebouwd zou hebben is door een externe partij nu al 14 maanden in ontwikkeling

[Gamebuster]

armageddon_2k1 schreef op dinsdag 14 januari 2020 @ 10:19:
Externe koppeling welke ik in 1 maand gebouwd zou hebben is door een externe partij nu al 14 maanden in ontwikkeling

De échte prijs van die offerte met lager uurtarief

Gelukkig kan je als API gebruiker weinig niet snappen aan JSON:API omdat het gewoon een JSON... (REST) API is.

...toch? We gaan het meemaken

[ Voor 28% gewijzigd door Gamebuster op 14-01-2020 11:30 ]

[Ryur]

Gamebuster schreef op dinsdag 14 januari 2020 @ 11:27:
[...]

De échte prijs van die offerte met lager uurtarief

Gelukkig kan je als API gebruiker weinig niet snappen aan JSON:API omdat het gewoon een JSON... (REST) API is.

...toch? We gaan het meemaken

Ik ben heel benieuwd. Ik kom de meest vreemde situaties tegen bij REST
Wat ik veel tegenkom is mensen die het verschil tussen POST & PUT niet begrijpen!

Of wat ik ook tegenkom, externe partijen die "true" (in een boolean veld) versturen, of "200" (in een integer veld).
Dat kom ik zovaak tegen dat in mijn API's worden beide versies ondersteund, en hoeft de externe partij geen rekening meer mee te houden.

Olaf van der Spek schreef op dinsdag 14 januari 2020 @ 12:13:
[...]

Dat is niet echt gezond op de lange termijn..

Heb je compleet gelijk in! Ik probeer het ook zoveel mogelijk te voorkomen, maar soms KAN je niks anders helaas.

[ Voor 37% gewijzigd door Ryur op 14-01-2020 12:15 ]

[Olaf van der Spek]

Ryur schreef op dinsdag 14 januari 2020 @ 12:05:
Dat kom ik zovaak tegen dat in mijn API's worden beide versies ondersteund, en hoeft de externe partij geen rekening meer mee te houden.

Dat is niet echt gezond op de lange termijn..

Ryur schreef op dinsdag 14 januari 2020 @ 12:05:
maar soms KAN je niks anders helaas.

Waarom (niet)?

[ Voor 22% gewijzigd door Olaf van der Spek op 14-01-2020 12:16 ]

[BarôZZa]

armageddon_2k1 schreef op dinsdag 14 januari 2020 @ 10:19:
[...]


Praat me er niet van. Wij hebben een GraphQL api en we gebruiken die ook intern. Heerlijk is het om mee te werken vooral omdat ons data model er zo mooi op mapped. Maar onze externe API gebruikers lijken er erg veel moeite mee te hebben..... documentatie wordt sowieso niet gelezen en hun code kloppers denken niet zelf na maar willen gewoon code kloppen. Externe koppeling welke ik in 1 maand gebouwd zou hebben is door een externe partij nu al 14 maanden in ontwikkeling

Kan je geen samplecode/library meeleveren?

Veel codekloppers lezen inderdaad niet, maar een stuk code kopiëren doen ze met alle liefde.

Vaak is het bouwen van een koppeling ook afgeschoven op een junior.

Overigens zie ik zelf maar weinig API's met echt goede documentatie. Google's documentatie is wel altijd briljant. Stap voor stap met duidelijke code en responses, zodat je je vooral kan richten op de implementatie ipv hoe je überhaupt de juiste data eruit krijgt.

[ Voor 14% gewijzigd door BarôZZa op 14-01-2020 12:47 ]

[Hydra]

armageddon_2k1 schreef op dinsdag 14 januari 2020 @ 10:19:
Praat me er niet van. Wij hebben een GraphQL api en we gebruiken die ook intern. Heerlijk is het om mee te werken vooral omdat ons data model er zo mooi op mapped. Maar onze externe API gebruikers lijken er erg veel moeite mee te hebben..... documentatie wordt sowieso niet gelezen en hun code kloppers denken niet zelf na maar willen gewoon code kloppen. Externe koppeling welke ik in 1 maand gebouwd zou hebben is door een externe partij nu al 14 maanden in ontwikkeling

Heb dat vroeger (heb het over meer dan 10 jaar terug) ook regelmatig met SOAP gebaseerde API's gehad. Je kunt een Java client zelfs gewoon laten genereren uit de WSDL. Maar dat vertikken veel developers dan gewoon te leren. Even een uurtje in iets nieuws duiken hebben ze geen zin in. Heb toen een paar maal het zelf zitten doen, maar dan wel met een uurtarief van 150 euro. Klant nog steeds helemaal blij, want het was binnen een week (we vaak een week op de factuur maar ondertussen maar een paar uur werk ook nog) af in plaats van de estimate van maanden die die developers gaven.

Heb ook wel eens met de CTO van een bekende uitzender hier een gesprek over gehad hoe dat dan kon. 'Em toch eens uitgelegd dat iets meer geld willen uitgeven aan je developers het wel eens waard kon zijn. Blijf het bijzonder vinden hoe makkelijk het is in ons vakgebied eigenlijk wekenlang geen hol uit te voeren.

[armageddon_2k1]

BarôZZa schreef op dinsdag 14 januari 2020 @ 12:45:
[...]

Kan je geen samplecode/library meeleveren?

Veel codekloppers lezen inderdaad niet, maar een stuk code kopiëren doen ze met alle liefde.

Vaak is het bouwen van een koppeling ook afgeschoven op een junior.

Overigens zie ik zelf maar weinig API's met echt goede documentatie. Google's documentatie is wel altijd briljant. Stap voor stap met duidelijke code en responses, zodat je je vooral kan richten op de implementatie ipv hoe je überhaupt de juiste data eruit krijgt.

Nou, waar zeg ik dat we dat niet doen dan? We leveren samples, kant en klare React Components, en een stappenplan hoe te beginnen, incl een primer van OAuth2.

Helpt niet. De vragen variëren van: “Waarom kan jullie GraphQL geen XML terugsturen” tot “Kan je niet gewoon een superlang password voor ons instellen? Dat OAuth is veel te lastig te implementeren en als we gewoon een wachtwoord doen van 128 tekens hebben we 1024 bits encryptie. Dat raadt niemand.”

Zelf kom ik oorspronkelijk uit 8 jaar mechanische productontwikkeling bij een grote Nederlandse reus die iets met medische apparatuur doet. Ook hier zag je het. Totale onwil van, vooral maar niet beperkt tot wat oudere, collega’s om ook maar iets nieuws te leren (CAD systeem, ontwikkelmethodologie, je natuurkunde iets bijspijkeren). Luiheid voerde de boventoon. Hoeveel engineers van HBO en WO niveau van een groep van vijftig niet in staat waren een fucking standaarddeviatie met de hand uit te rekenen was ongeveer 45. En dat moet dan Six Sigma (wat overigens in de fysieke product ontwikkeling wél een goede methodiek is) gaan hanteren. Liefst wilde een groot deel gewoon elke dag een beetje in hun oude vertrouwde CAD systeempje 3D dingetjes maken. Maakt het uit dat we er 500,000 per jaar vrijwel identiek moeten produceren... Om nog maar te zwijgen over de marketingmensen wiens hele wereld bestond uit Excel maar verdomden om iets te leren als een Pivot Table of mee kunnen werken in het Requirements Management Systeem waar ze nogal een belangrijke input waren. Of de mede engineer die zegt: ach, zolang ik de 26e weer een bedrag bijgeschreven zie worden vind ik het allemaal prima.

Mensen zijn gewoon fucking lui.

Niet dat ik nou direct de Messias ben, maar net als een hele prettige collega nu vind ik het super leuk in m’n vrije tijd nieuwe technieken te proberen, boeken te lezen (deze week Clean Architecture en Clean Agile uit. Kom uit een andere branche, dus even wat in te halen ). Maar een paar van de collega’s leren niks nieuws tenzij je ze verplicht. TDD? Nooit van gehoord. MVP? Ook niet. Gewoon lekker je JS brei uit blijven scheiten.

Opa gaat naar bed

[ Voor 44% gewijzigd door armageddon_2k1 op 15-01-2020 00:10 ]

[Koenvh]

@armageddon_2k1 Is het altijd wel onwil, of soms ook gewoon onmacht/onkunde? Niet iedereen kan zomaar eventjes leren hoe OAuth2 werkt, of GraphQL, en da's niet altijd alleen maar luiheid.

Daarnaast verwacht ik ook niet dat mensen dat in de vrije tijd gaan bijhouden; mag uiteraard wel, maar je kunt 't mijns inziens niet iemand verplichten. Voor veel mensen is een baan gewoon dat ding waardoor het eten op tafel gezet kan worden, en niet meer. Ik zou dat niet volhouden, maar als een ander daar content mee is, en de baas ook, waarom zou jij je er dan druk over maken?

Ik snap je frustratie heus wel, en ik heb dat ook wel, maar met je eraan ergeren heb je alleen jezelf mee.

[armageddon_2k1]

@Koenvh Begrijpelijke reactie hoor Maar in 14 maanden moet je OAuth2 wel begrepen hebben. In de andere voorbeelden gaat het om 2 jaar zonder tests code kloppen.

Overigens erger ik me er niet zo heel erg meer aan. Het is gewoon een kwestie van accepteren dat het in elke branche zo is

Nee ik verwacht niet dat je al je vrije tijd opoffert en het voor velen ‘maar’ een baan is, maar deze branche verandert enorm snel. Soms hoor je wel verhalen dat je als 35jarige (ikzelf ben 34) al te oud zou zijn voor de branche. Dat vind ikzelf kul en ik denk ook meer dat dat Amerikaanse taferelen zijn, maar ik kan me wel voorstellen dat als je op je 24 professioneel bent begonnen en je in 11 jaar nauwelijks bij hebt geleerd je nu een letterlijke oude fossiel bent.

[ Voor 9% gewijzigd door armageddon_2k1 op 15-01-2020 08:55 ]

[dev10]

armageddon_2k1 schreef op woensdag 15 januari 2020 @ 08:54:
... maar ik kan me wel voorstellen dat als je op je 24 professioneel bent begonnen en je in 11 jaar nauwelijks bij hebt geleerd je nu een letterlijke oude fossiel bent.

Dat is nog een redelijke understatement. Als ik kijk naar hoe de tech-stack waar ik nu mee werk er tien jaar geleden uit zag en hoe die er nu uit ziet:

- PHP: Tien jaar geleden zaten we nog op PHP 5.2, als je al geluk had dat je hoster dat ondersteund
- MySQL: Tien jaar geleden zaten we op versie 5.1, zonder bijvoorbeeld fulltext indexen in InnoDB
- Laravel: De eerste versie hiervan is uitgebracht in 2011, maar is ook totaal niet meer vergelijkbaar met hoe Laravel nu is.
- Redis: bestond tien jaar geleden nog niet
- Elasticsearch: bestond tien jaar geleden nog niet
- NodeJS: bestond tien jaar geleden nog niet
- React: daar had nog nooit iemand van gehoord
- Docker: idem
- Kubernetes: idem

Dan kun je heel leuk tien jaar ervaring hebben als ontwikkelaar, maar als je al tien jaar bent blijven hangen in PHP 5.2 en MySQL 5.1 dan is die ervaring niet heel relevant.

[Mugwump]

dev10 schreef op woensdag 15 januari 2020 @ 11:22:
[...]


Dat is nog een redelijke understatement. Als ik kijk naar hoe de tech-stack waar ik nu mee werk er tien jaar geleden uit zag en hoe die er nu uit ziet:

- PHP: Tien jaar geleden zaten we nog op PHP 5.2, als je al geluk had dat je hoster dat ondersteund
- MySQL: Tien jaar geleden zaten we op versie 5.1, zonder bijvoorbeeld fulltext indexen in InnoDB
- Laravel: De eerste versie hiervan is uitgebracht in 2011, maar is ook totaal niet meer vergelijkbaar met hoe Laravel nu is.
- Redis: bestond tien jaar geleden nog niet
- Elasticsearch: bestond tien jaar geleden nog niet
- NodeJS: bestond tien jaar geleden nog niet
- React: daar had nog nooit iemand van gehoord
- Docker: idem
- Kubernetes: idem

Dan kun je heel leuk tien jaar ervaring hebben als ontwikkelaar, maar als je al tien jaar bent blijven hangen in PHP 5.2 en MySQL 5.1 dan is die ervaring niet heel relevant.

Stil blijven staan is natuurlijk nooit goed, maar dit soort veranderingen zijn toch niet echt heel fundamenteel. Waar Elasticsearch misschien 10 jaar geleden nog niet bestond, bestaat Lucene al sinds '99 en kent zelfs Lucene wel weer voorgangers en theoretische principes die al veel langer bestaan. Laravel bestond misschien nog lang niet in haar huidige vorm, maar al dat soort frameworkjes zijn gewoon veelal hetzelfd en als je er een paar hebt gezien kun je vrij makkelijk generaliseren.
Containers zijn vrij nieuw, maar veel concepten waren er ook al in de tijd van VMs en dergelijke.
Als je veel ervaring hebt leer je ook abstraheren en makkelijk nieuwe dingen oppakken die feitelijk niet veel meer zijn dan oude wijn in nieuwe zakken. Er zijn de afgelopen 20 jaar ook nauwelijks echt fundamentele paradigmaverschuivingen geweest in de softwareontwikkeling. Hooguit weer een opleving van wat zaken die al van decennia terug stammen.

[CodeCaster]

GrooV schreef op maandag 13 januari 2020 @ 10:12:
Gewoon CMD git gebruiken, als je het eenmaal onder de knie hebt dan wil je niet anders

Dat argument hoor ik zo vaak, maar ik ben het daar pertinent mee oneens. Met een degelijke GUI kun je met minder toetsaanslagen hetzelfde doen, en tegelijk alles overzichtelijker in beeld houden. Alléén al het typen van git commit -m "SomeMessage" duurt langer dan Ctrl+Shift+C, SomeMessage, Ctrl+Enter. En dan Ctrl+Shift+P om te pushen.

En kiezen wat er daadwerkelijk in een commit komt, is (voor mij) grafisch veel overzichtelijker dan met ASCII-art en handmatig git add/reset pad/naar/file typen. Of snel de diffs bekijken van de bestanden die je wil committen. Of icoontjes die de vershillende bestandstypes aangeven. Of een overzicht van de geschiedenis en overige branches. Of met twee keer klikken een degelijke diff-tool (Beyond Compare ) opstarten en daarmee conflicten oplossen. Of een overzichtelijke squash/interactive rebase.

Dat mensen de commandline fijn vinden, moeten ze zelf weten. Ik kan daar mijn weg ook prima in vinden. Maar ik zal nooit zonder GUI kunnen. Dus dat ik "nooit meer anders zal willen" is gewoon niet waar. Wees jij lekker blij met je commandline, maar ik zal mijn GUI nooit helemaal kunnen loslaten.

Dat gezegd hebbende, Git Fork nu alweer een paar dagen naar volle tevredenheid in gebruik, erg fijne tool, bedankt voor de suggesties!

---

En heel wat anders, WTF zijn ze allemaal aan het doen bij Stack Overflow. Eerst iemand ontslaan omdat die aangeeft moeite te hebben met het verplicht moeten gebruiken van "xi/xir" als "preferred pronouns", en liever gewoon het genderneutrale "they/their" wil gebruiken, als het al ooit opkomt. Nee, dat mag niet, eruit!

En toen viel de community over elkaar heen, het bedrijf Stack Overflow stopt zo'n beetje alle uitgaande communicatie en nu zijn er eergisteren weer twee oudgedienden vertrokken (Shog9 en Robert Cartaino). Mensen die duizenden uren in de community hebben gestopt en in dienst waren van het bedrijf, hup, eruit!

Het bedrijf zwijgt in alle toonaarden. Wat ze willen: het elke gebruiker naar de zin maken, vooral nieuwe gebruikers, want meer gebruikers is meer pageviews en dus meer geld. Dat ondertussen 99,9% van de nieuwe vragen poep zijn, en dat mensen liever code uit bestaande antwoorden copy-pasten dan een op de OP toegespitst antwoord tikken, lijkt niemand wat uit te maken.

Er is ondertussen een nieuwe beweging gaande, Codidact, waarin een paar handen vol members een nieuwe site willen maken. Ik ben erg benieud, maar het is niet de eerste keer dat dat geprobeerd is.

[ Voor 3% gewijzigd door CodeCaster op 15-01-2020 13:45 ]

[GrooV]

CodeCaster schreef op woensdag 15 januari 2020 @ 13:31:
[...]

Dat argument hoor ik zo vaak, maar ik ben het daar pertinent mee oneens. Met een degelijke GUI kun je met minder toetsaanslagen hetzelfde doen, en tegelijk alles overzichtelijker in beeld houden. Alléén al het typen van git commit -m "SomeMessage" duurt langer dan Ctrl+Shift+C, SomeMessage, Ctrl+Enter. En dan Ctrl+Shift+P om te pushen.

En kiezen wat er daadwerkelijk in een commit komt, is (voor mij) grafisch veel overzichtelijker dan met ASCII-art en handmatig git add/reset pad/naar/file typen. Of snel de diffs bekijken van de bestanden die je wil committen. Of icoontjes die de vershillende bestandstypes aangeven. Of een overzicht van de geschiedenis en overige branches. Of met twee keer klikken een degelijke diff-tool (Beyond Compare ) opstarten en daarmee conflicten oplossen. Of een overzichtelijke squash/interactive rebase.

Dat mensen de commandline fijn vinden, moeten ze zelf weten. Ik kan daar mijn weg ook prima in vinden. Maar ik zal nooit zonder GUI kunnen. Dus dat ik "nooit meer anders zal willen" is gewoon niet waar. Wees jij lekker blij met je commandline, maar ik zal mijn GUI nooit helemaal kunnen loslaten.

Dat gezegd hebbende, Git Fork nu alweer een paar dagen naar volle tevredenheid in gebruik, erg fijne tool, bedankt voor de suggesties!

---

En heel wat anders, WTF zijn ze allemaal aan het doen bij Stack Overflow. Eerst iemand ontslaan omdat die aangeeft moeite te hebben met het verplicht moeten gebruiken van "xi/xir" als "preferred pronouns", en liever gewoon het genderneutrale "they/their" wil gebruiken, als het al ooit opkomt. Nee, dat mag niet, eruit!

En toen viel de community over elkaar heen, het bedrijf Stack Overflow stopt zo'n beetje alle uitgaande communicatie en nu zijn er eergisteren weer twee oudgedienden vertrokken (Shog9 en Robert Cartaino). Mensen die duizenden uren in de community hebben gestopt en in dienst waren van het bedrijf, hup, eruit!

Het bedrijf zwijgt in alle toonaarden. Wat ze willen: het elke gebruiker naar de zin maken, vooral nieuwe gebruikers, want meer gebruikers is meer pageviews en dus meer geld. Dat ondertussen 99,9% van de nieuwe vragen poep zijn, en dat mensen liever code uit bestaande antwoorden copy-pasten dan een op de OP toegespitst antwoord tikken, lijkt niemand wat uit te maken.

Er is ondertussen een nieuwe beweging gaande, Codidact, waarin een paar handen vol members een nieuwe site willen maken. Ik ben erg benieud, maar het is niet de eerste keer dat dat geprobeerd is.

git commit -m shift + insert Maar goed, ik zeg ook niet dat het sneller is, alleen dat je via cmd wel beter het git proces snapt.

Wat betreft SO, ze moeten wel iets veranderen want het is voor nieuwkomers gewoon heel onvriendelijk. Als jij daar een "simpele" vraag stelt wordt je niet echt bepaald vriendelijk behandeld terwijl iedereen het natuurlijk ergens moet leren en we allemaal als noobs zijn begonnen. Iets waar Tweakers Devschuur overigens ook last van heeft.

Of dit dan de juiste manier is dat is een ander verhaal maar ik begrijp goed dat de huidige community niet houdbaar is. En ja, SO/SE is gewoon een bedrijf wat betekend een gezonde aanwas van nieuwe leden nodig is.

[CodeCaster]

GrooV schreef op woensdag 15 januari 2020 @ 13:58:
[...]

git commit -m shift + insert Maar goed, ik zeg ook niet dat het sneller is, alleen dat je via cmd wel beter het git proces snapt.

Ook daar ben ik het niet mee eens. Ik heb niet beter geleerd wat een commit en een branch zijn door het in te tikken in plaats van het aan te klikken, ik heb geleerd hoe Git werkt door erover te lezen en door het te gebruiken naast andere version control systems, en vooral door (expres) veel fouten te maken en die te leren herstellen.

Wat betreft SO, ze moeten wel iets veranderen want het is voor nieuwkomers gewoon heel onvriendelijk. Als jij daar een "simpele" vraag stelt wordt je niet echt bepaald vriendelijk behandeld terwijl iedereen het natuurlijk ergens moet leren en we allemaal als noobs zijn begonnen. Iets waar Tweakers Devschuur overigens ook last van heeft.

Dat moet helemaal niet veranderen. Stack Overflow noch Tweakers zijn "Leer hier programmeren"- of "Leer hier online communiceren"-sites.

Er zijn niet genoeg mensen die dingen duidelijk én correct kunnen uitleggen om óók nog eens 9 van de 10 nieuwe gebruikers te leren dat ze:

• Een leesbaar verhaal moeten neerzetten
• Code moeten formatteren als code, en tekst als tekst
• Een duidelijke, beantwoordbare vraag moeten stellen, die on-topic is
• In het geval van een compileer-, runtime- of logica-fout hun code, de verwachte output en de eigenlijke output moeten weergeven

En serieus, scroll eens langs de nieuwe vragen, letterlijk 9 van de 10 nieuwe vragen heeft problemen op dit vlak. Dan wil je niet de tijd verdoen van iemand die die vraag prima kan beantwoorden in twee minuten, eerst vijf minuten nodig heeft om de post te interpreteren en leesbaar te maken.

En dan heb je nog last van een immens cultuurverschil. Er zijn miljoenen gebruikers op de site voor wie dingen als plagiaat of toegeven dat je iets niet snapt onbekend zijn. Dus die kopiëren de titel van de vraag naar Google, en plakken het eerste het beste resultaat als antwoord, ongeacht of het daadwerkelijk de vraag beantwoordt. Zulke mensen ben je liever kwijt dan rijk, maar er zijn niet genoeg gebruikers die zich dáár druk om maken. Sterker nog, hun vriendjes in hetzelfde kantoor upvoten ze wanneer jij ze daarvoor een downvote geeft.

Of dit dan de juiste manier is dat is een ander verhaal maar ik begrijp goed dat de huidige community niet houdbaar is.

De huidige situatie is dus inderdaad onhoudbaar. Hij was redelijk houdbaar, tot de "summer of love", waar ineens alles moest kunnen. Kijk, nare, sarcastische reacties zijn vervelend en horen niet op die site. En dat is toen ook aardig in de kiem gesmoord.

Maar "wees lief tegen iedereen" is niet hetzelfde als "iedereen moet alles kunnen posten wat 'ie wil".

En ja, SO/SE is gewoon een bedrijf wat betekend een gezonde aanwas van nieuwe leden nodig zijn.

Natuurlijk zijn er nieuwe gebruikers nodig. Die gebruikers moeten wel iets kúnnen. Zo niet, en als ze de kern van de site daarmee slopen, gaat het de kant op van Yahoo Answers, en dat wil niemand.

En dan zou je me een elitaire soup nazi kunnen noemen, en dat mag. Ook daar zal ik het niet mee eens zijn. Kwaliteitsstandaarden hebben nut, kijk bijvoorbeeld maar naar Wikipedia. Als álles zou mogen, zou het niet het niveau hebben wat het nu heeft. Neemt niet weg dat het veel te wensen overlaat, maar het zou nog veel erger kunnen.

[ Voor 4% gewijzigd door CodeCaster op 15-01-2020 14:37 ]

[GrooV]

CodeCaster schreef op woensdag 15 januari 2020 @ 14:35:
[...]

Ook daar ben ik het niet mee eens. Ik heb niet beter geleerd wat een commit en een branch zijn door het in te tikken in plaats van het aan te klikken, ik heb geleerd hoe Git werkt door erover te lezen en door het te gebruiken naast andere version control systems, en vooral door (expres) veel fouten te maken en die te leren herstellen.


[...]

Dat moet helemaal niet veranderen. Stack Overflow noch Tweakers zijn "Leer hier programmeren"- of "Leer hier online communiceren"-sites.

Er zijn niet genoeg mensen die dingen duidelijk én correct kunnen uitleggen om óók nog eens 9 van de 10 nieuwe gebruikers te leren dat ze:

• Een leesbaar verhaal moeten neerzetten
• Code moeten formatteren als code, en tekst als tekst
• Een duidelijke, beantwoordbare vraag moeten stellen, die on-topic is
• In het geval van een compileer-, runtime- of logica-fout hun code, de verwachte output en de eigenlijke output moeten weergeven

En serieus, scroll eens langs de nieuwe vragen, letterlijk 9 van de 10 nieuwe vragen heeft problemen op dit vlak. Dan wil je niet de tijd verdoen van iemand die die vraag prima kan beantwoorden in twee minuten, eerst vijf minuten nodig heeft om de post te interpreteren en leesbaar te maken.

En dan heb je nog last van een immens cultuurverschil. Er zijn miljoenen gebruikers op de site voor wie dingen als plagiaat of toegeven dat je iets niet snapt onbekend zijn. Dus die kopiëren de titel van de vraag naar Google, en plakken het eerste het beste resultaat als antwoord, ongeacht of het daadwerkelijk de vraag beantwoordt. Zulke mensen ben je liever kwijt dan rijk, maar er zijn niet genoeg gebruikers die zich dáár druk om maken. Sterker nog, hun vriendjes in hetzelfde kantoor upvoten ze wanneer jij ze daarvoor een downvote geeft.


[...]

De huidige situatie is dus inderdaad onhoudbaar. Hij was redelijk houdbaar, tot de "summer of love", waar ineens alles moest kunnen. Kijk, nare, sarcastische reacties zijn vervelend en horen niet op die site. En dat is toen ook aardig in de kiem gesmoord.

Maar "wees lief tegen iedereen" is niet hetzelfde als "iedereen moet alles kunnen posten wat 'ie wil".


[...]

Natuurlijk zijn er nieuwe gebruikers nodig. Die gebruikers moeten wel iets kúnnen. Zo niet, en als ze de kern van de site daarmee slopen, gaat het de kant op van Yahoo Answers, en dat wil niemand.

En dan zou je me een elitaire soup nazi kunnen noemen, en dat mag. Ook daar zal ik het niet mee eens zijn. Kwaliteitsstandaarden hebben nut, kijk bijvoorbeeld maar naar Wikipedia. Als álles zou mogen, zou het niet het niveau hebben wat het nu heeft. Neemt niet weg dat het veel te wensen overlaat, maar het zou nog veel erger kunnen.

Als jij geen veilige plek kunt creeren waar mensen zorgeloos een vraag kunnen stellen zonder afgebrand te worden of lastig gevallen te worden in het geval van vrouwelijke programmeurs dan moet je je schamen als #1 developer Q&A site. Punt.

Dat sommige gebruikers zich te goed voelen om beginnende vraagstellers te helpen moet je als platform boven staan en daar tegen optreden

[CodeCaster]

GrooV schreef op woensdag 15 januari 2020 @ 14:40:
[...]

Als jij geen veilige plek kunt creeren waar mensen zorgeloos een vraag kunnen stellen zonder afgebrand te worden of lastig gevallen te worden in het geval van vrouwelijke programmeurs dan moet je je schamen als #1 developer Q&A site. Punt.

Dat is een stroman, dit is nooit toegestaan geweest. Afbranden en lastigvallen wordt bestraft,en terecht. Dergelijke comments worden verwijderd, er wordt opgetreden tegen de personen die dat doen. Stack Overflow ís een "veilige plek". Dat mensen zenuwachtig worden voordat ze een vraag durven posten, is terecht. Je gaat ook niet zonder spanning iets presenteren voor een groep mensen. Dan kun je maar beter even dubbelchecken of je, binnen jouw macht, alles hebt gedaan om een begrijpbare vraag te stellen met alle relevante details.

Als je die spanning niet hebt, of niet wil hebben, is die site niet de plek voor jou. En dat heeft niets met een "safe space" te maken.

Dat sommige gebruikers zich te goed voelen om beginnende vraagstellers te helpen moet je als platform boven staan en daar tegen optreden

Waarom vind je dat dat moet? Waarom denk je dat de situatie waarin álle soorten vragen moeten kunnen, houdbaar is?

Om zo'n site blijvend succesvol te laten blijven, heb je mensen nodig met kennis, geduld én die goed kunnen uitleggen en schrijven. Die zijn schaars. Die wil je niet vervelen en uiteindelijk wegjagen met de zoveelste "waarom compileert dit niet?", waarbij de helft van de code mist, de compiler-foutmeldingen missen en de vraag verschoond is van ook maar enig zelfonderzoek of zin om te leren.

[armageddon_2k1]

Allemaal leuk en aardig, maar de shitstorm kwam omdat sommige mensen die juist wel heel welkomend waren voor nieuwelingen zonder melding eraf getieft waren vanwege een "verwachting van mogelijke schending van toekomstige CoC" omdat ze moeite had met "xi/xir" vs het al neutrale "they/their". Dat is wel even iets anders.

Als het waar is dat iemand eraf gegooid wordt vanwege een "verwachting van mogelijke schending van een reeds ongepubliceerde Code of Conduct"... tja, dan ben je alle geloofwaardigheid kwijt.

EDIT: Je zou zeggen dat er, met alle machine learning hype, iets mogelijk moet zijn om simpele 13 in een dozijn vragen, automatisch te laten beantwoorden op basis van oude antwoorden en hem dan ergens te archiveren. Mocht je het er niet mee eens zijn dan kan je actief aangeven waarom.

Dingen als:
Concat string object using plus assign
Get random values from two columns
die lenen zich daar goed voor.

[ Voor 36% gewijzigd door armageddon_2k1 op 15-01-2020 15:32 ]

[GrooV]

Sorry dat ik het zeg maar ik denk dat als je het probleem bij SO niet ziet wat betreft de toegankelijkheid dat je misschien zelf onderdeel van het probleem bent. Helemaal als je zegt dat het maar goed is dat er alleen mensen met kennis op zitten, ook die zijn ooit zo begonnen.

Kijk maar naar Jon Skeet, de meeste vragen die hij heeft beantwoord zijn van beginnende gebruikers. En altijd vriendelijk, zulke mensen heeft SO nodig. Beginennde gebruikers enthousiast maken zodat ze uiteindelijk ook mensen gaan helpen

Een simpele zoektocht op Google naar Stackoverflow + toxic levert genoeg verhalen op.

Waarom kunnen sub-Reddit's wel goed omgaan met beginnende gebruikers en SO niet?

@armageddon_2k1 SO heeft zelf niet (inhoudelijk) gereageerd dus we horen het verhaal maar van 1 kant helaas.

[ Voor 5% gewijzigd door GrooV op 15-01-2020 15:40 ]

[armageddon_2k1]

GrooV schreef op woensdag 15 januari 2020 @ 15:31:
Sorry dat ik het zeg maar ik denk dat als je het probleem bij SO niet ziet wat betreft de toegankelijkheid dat je misschien zelf onderdeel van het probleem bent. Helemaal als je zegt dat het maar goed is dat er alleen mensen met kennis op zitten, ook die zijn ooit zo begonnen.

Kijk maar naar Jon Skeet, de meeste vragen die hij heeft beantwoord zijn van beginnende gebruikers. En altijd vriendelijk, zulke mensen heeft SO nodig.

Tot hier met je eens.
Ik moet zeggen dat ik SO minder gebruik voor de moeilijkere problemen die ik heb omdat ik gewoon bijna nooit meer antwoord krijg. Een paar jaar geleden kreeg ik op moeilijkere vragen nog wel antwoord maar nu sneeuwen ze onder. Er is dus, voor mijn gevoel, wel degelijk een probleem met een enorme aangroei van mensen die gewoon een simpele vraag op SO pleuren en antwoord verwachten waardoor het nut van SO minder wordt. Is dit direct de schuld van de nieuwelingen? Nee. Zoeken van antwoorden moet je leren. Zelfstandig uitpluizen moet je leren. Je moet de juiste terminologie leren. En in sommige gevallen zal het zeker een mentaliteitsdingetje zijn. Als ik kijk naar mijn vragen van toen ik 18-20 was op Tweakers staan er ook gehaaste vragen tussen. Onze stagiair zegt ook "Als ik iets niet weet pleur ik het op SO".
In mijn vorige werk was het ook zo dat een jonge HBO werktuigbouwkundige ook meteen zei bij een krachtenberekeningetje: "Ik weet het niet. Hulp." Geduldig hem op materiaal wijzen en hem leren dat ie het echt wel weet en het zelf kan uitvinden en het komt goed.

Een simpele zoektocht op Google naar Stackoverflow + toxic levert genoeg verhalen op.

Waarom kunnen sub-Reddit's wel goed omgaan met beginnende gebruikers en SO niet?

Tja, zoek eens op "reddit toxic" zou ik zeggen. Krijg je ook genoeg verhalen. Een Google search zegt niet zo heel veel. Afgezien van het feit dat het ook nog eens persoonlijk gefilterd is door een onbekend Google algoritme en dus totaal niet kwantitatief herhaalbaar is....

@armageddon_2k1 SO heeft zelf niet gereageerd dus we horen het verhaal maar van 1 kant helaas.

O, ze hebben gereageerd (de CTO). Dat was ook vrij makkelijk te vinden:
https://meta.stackexchang...-next-steps/334646#334646

Deze heeft aangegeven dat het proces niet juist gevolgd is bij het 'ontslag' van de moderators. Het ontslag is van september en hij geeft zelf aan in die post dat de nieuwe CoC in oktober komt. Daarnaast geeft ie aan met de 'ontslagenen' in contact te komen om het proces en de gang van zaken te bespreken. Dit is niet gebeurd.

[boe2]

Dat allemaal over een "code of conduct"? Wat meer moet daar in staan dan "be nice"

[Gropah]

boe2 schreef op woensdag 15 januari 2020 @ 15:59:
Dat allemaal over een "code of conduct"? Wat meer moet daar in staan dan "be nice"

Ik ben het zelfde, maar er zijn schijnbaar veel mensen die er erg veel waarde aan hechten.

Heb zelf wel eens een congres achtig iets georganiseerd en we wouden en bepaalde spreker erg graag hebben, maar die wou alleen komen als er een CoC was met daar in ieder geval punt x, y en z benoemd, anders kwam die niet. Dus toen was er ineens een CoC voor het evenement met daarin dingen x, y, z en nog een paar kleine dingetjes.

[gekkie]

Mjah waarbij je CoC weer als mepmiddel gebruikt kan worden om dingen af te dwingen middels naming and shaming dan wel het dreigen er mee. Achja beschaving, het blijft een dun laagje vernis.

[DaWin]

boe2 schreef op woensdag 15 januari 2020 @ 15:59:
Dat allemaal over een "code of conduct"? Wat meer moet daar in staan dan "be nice"

Omdat mensen dat op hun eigen manier interpreteren, voornamelijk in eigen voordeel. 99% van de mensen zal het wel volgen (met of zonder conduct) maar net die paar die vinden dat ze alles mogen zeggen en vinden dat mensen maar geen aanstoot moeten nemen kan je dan met de CoC om de oren slaan. En het is inderdaad steeds gebruikelijker om een fatsoenlijke CoC te hebben om minderheden te garanderen dat ze niet onbestraft onheus bejegend worden.

gekkie schreef op woensdag 15 januari 2020 @ 16:09:
Mjah waarbij je CoC weer als mepmiddel gebruikt kan worden om dingen af te dwingen middels naming and shaming dan wel het dreigen er mee. Achja beschaving, het blijft een dun laagje vernis.

Dat dus

[ Voor 19% gewijzigd door DaWin op 15-01-2020 16:11 ]

[armageddon_2k1]

Ik denk dat we dit ook meer vanuit de bril van de U.S. 'cultuur' (ja, die quotes zijn expres) moeten zien. Die is gewoon heel erg anders dan die van ons. Van de Europese landen zijn wij dan (afgezien van UK natuurlijk) wel het meest gefocust op nieuws vanuit de U.S. In de U.S. willen ze ten alle tijden accountability af kunnen schuiven en hun straatje schoon vegen. Ik kan je verhalen vertellen van samenwerken met onze collega's uit de U.S....poe.

Dus tja, ik ben het ermee eens.... "doe effe normaal" is denk ik wel wat meer de norm hier. Echter, die normaal moet wel bespreekbaar zijn.

[boe2]

DaWin schreef op woensdag 15 januari 2020 @ 16:10:
[...]

Omdat mensen dat op hun eigen manier interpreteren, voornamelijk in eigen voordeel. 99% van de mensen zal het wel volgen (met of zonder conduct) maar net die paar die vinden dat ze alles mogen zeggen en vinden dat mensen maar geen aanstoot moeten nemen kan je dan met de CoC om de oren slaan. En het is inderdaad steeds gebruikelijker om een fatsoenlijke CoC te hebben om minderheden te garanderen dat ze niet onbestraft onheus bejegend worden.

Heb daarbij wel een deja-vu naar bepaalde controversiele topics op github een tijd terug.

Mij lijkt het vooral op voeden van extreem narcisisme bij bepaalde mensen. Het is een site over programmeren, je ras of gender heeft welgeteld 0% relevantie.

[DaWin]

boe2 schreef op woensdag 15 januari 2020 @ 16:12:
[...]

Heb daarbij wel een deja-vu naar bepaalde controversiele topics op github een tijd terug.

Mij lijkt het vooral op voeden van extreem narcisisme bij bepaalde mensen. Het is een site over programmeren, je ras of gender heeft welgeteld 0% relevantie.

Het hebben van een CoC is voeden van extreem narcisme? En ras, gender (of wat je dan ook onderscheidt van anderen) zou geen relevantie moeten hebben inderdaad. Helaas is de werkelijkheid weerbarstiger.

[boe2]

DaWin schreef op woensdag 15 januari 2020 @ 16:17:
[...]


Het hebben van een CoC is voeden van extreem narcisme? En ras, gender (of wat je dan ook onderscheidt van anderen) zou geen relevantie moeten hebben inderdaad. Helaas is de werkelijkheid weerbarstiger.

De stackexchange draad praat over dat they/them pronouns niet voldoende zijn en dat wanneer iemand vraagt om met xim/xer geaddresseerd te worden je je daaraan dient te houden of je vliegt buiten. Dat is inderdaad iemand plezieren die als enig doel heeft testen hoe ver men kan gaan met vreemde eisen en hoe men een groot bedrijf naar hun pijpen kan laten dansen.

Hier schrijf ik de zin met het genderneutrale "men/hun" in het nederlands. Stel je nu voor dat ik op tweakers eis dat men voortaan naar mij verwijst als "xij heeft een vraag gesteld". In een normale omgeving wordt je hiermee weggelachen, en terecht.

[ Voor 16% gewijzigd door boe2 op 15-01-2020 16:26 ]

[CodeCaster]

GrooV schreef op woensdag 15 januari 2020 @ 15:31:
Sorry dat ik het zeg maar ik denk dat als je het probleem bij SO niet ziet wat betreft de toegankelijkheid dat je misschien zelf onderdeel van het probleem bent.
[...]
Een simpele zoektocht op Google naar Stackoverflow + toxic levert genoeg verhalen op.

Ik denk dat het probleem is dat je stelt dat de toegankelijkheid het probleem is. Jij vindt dat blijkbaar iedereen, ongeacht zijn taalbeheersing, kennisniveau, motivatie en geschiktheid om een beantwoordbare vraag te stellen, welkom moet zijn op het platform.

Ik ben het daar niet mee eens. Je moet eens weten hoeveel huiswerkdumps, non-repro's, duplicaten, vragen naar meningen en überhaupt onbegrijpelijke vragen er per dag gepost en gesloten worden. Het zijn juist de mensen die dergelijke vragen stellen en het deksel op hun neus krijgen, die vervolgens blogs en tweets gaan posten dat het zo'n nare site is. En die krijgen dan bijval van de mensen wie dat ook eens overkomen is. Dat maakt nog niet dat ze gelijk hebben in dat het anders moet.

Het feit dát er kwaliteitsstandaarden zijn, en dat die lange tijd gehandhaafd zijn, maakt dat de site is wat 'ie nu is, namelijk een geweldig naslagwerk voor de meest uiteenlopende programmeerproblemen.

Helemaal als je zegt dat het maar goed is dat er alleen mensen met kennis op zitten, ook die zijn ooit zo begonnen.

Kijk maar naar Jon Skeet, de meeste vragen die hij heeft beantwoord zijn van beginnende gebruikers. En altijd vriendelijk, zulke mensen heeft SO nodig. Beginennde gebruikers enthousiast maken zodat ze uiteindelijk ook mensen gaan helpen

Dat zeg ik niet. Ik zeg dat het moeilijk is om zulke mensen te behouden, als er mensen zijn die claimen dat alles maar moet kunnen op zo'n site. Ik zeg dat het aantal mensen zoals Jon Skeet dat goed is in zelfs het meest eenvoudige probleem grondig te analyseren, de denk- of implementatiefout die OP heeft gemaakt te benoemen zonder deze te beledigen en vervolgens een bruikbare, onderhoudbare oplossing aan te leveren met uitleg die voor een boel mensen nuttig is, extreem zeldzaam is.

En dat zijn toch echt de mensen die de site gemaakt hebben tot wat het is. Er is helemaal niks mis met simpele vragen. Er is wel iets mis met mensen die denken dat hun vraag uniek is als de variabele b heet in plaats van a, en dus boos worden als hun vraag als duplicate wordt gesloten van een die het probleem uitlegt in de context van a.

En het is precies die continue stroom van "bagger" die @armageddon_2k1 noemt die ervoor zorgt dat de mensen met ervaring afdruipen. Voor elke interessante vraag zijn er 99 die de moeite niet waard zijn. En wat komt er voor hen in de plaats? Mensen met minder ervaring, mensen die minder goed zijn in goede oplossingen bedenken, mensen die niet goed hun gedachten kunnen verwoorden zodat een breed publiek ze begrijpt.

"Try this: [code I found on Google]" is geen antwoord. Ja, misschien kan OP weer verder. Maar misschien zit er wel een dikke SQL injection vulnerability in die code. Je weet het niet, want de experts lezen de antwoorden niet meer. En de volgende die het antwoord vindt, weet niks van SQL injection. En zijn project compileert ook weer, dus hier, heb een upvote.

Waarom kunnen sub-Reddit's wel goed omgaan met beginnende gebruikers en SO niet?

Sorry, maar bijvoorbeeld /r/learnprogramming haalt het in de verste verte niet bij Stack Overflow of Code Review qua kwaliteit. En dan nog, dat is niet de scope van laatstgenoemde sites.

Iemand leren programmeren, iemand leren leren, is niet het doel van SO. Nogmaals, daarvoor heeft het niet genoeg gebruikers die dat op een geduldige en duidelijke manier kunnen, je hebt daar bijna één-op-één-begeleiding bij nodig, en het aantal mensen dat daar zin in heeft en de benodigde kwaliteiten voor heeft, is eindig. Het aantal mensen dat iets niet snapt en dan maar een vraag op internet wil kunnen kwakken en een antwoord eisen, is oneindig.

[ Voor 9% gewijzigd door CodeCaster op 15-01-2020 17:05 ]

[BarôZZa]

dev10 schreef op woensdag 15 januari 2020 @ 11:22:
[...]


Dat is nog een redelijke understatement. Als ik kijk naar hoe de tech-stack waar ik nu mee werk er tien jaar geleden uit zag en hoe die er nu uit ziet:

- PHP: Tien jaar geleden zaten we nog op PHP 5.2, als je al geluk had dat je hoster dat ondersteund
- MySQL: Tien jaar geleden zaten we op versie 5.1, zonder bijvoorbeeld fulltext indexen in InnoDB
- Laravel: De eerste versie hiervan is uitgebracht in 2011, maar is ook totaal niet meer vergelijkbaar met hoe Laravel nu is.
- Redis: bestond tien jaar geleden nog niet
- Elasticsearch: bestond tien jaar geleden nog niet
- NodeJS: bestond tien jaar geleden nog niet
- React: daar had nog nooit iemand van gehoord
- Docker: idem
- Kubernetes: idem

Dan kun je heel leuk tien jaar ervaring hebben als ontwikkelaar, maar als je al tien jaar bent blijven hangen in PHP 5.2 en MySQL 5.1 dan is die ervaring niet heel relevant.

Die ervaring is juist relevant, want die twee dingen zijn de enige twee constante factoren door de jaren heen. Versie verschillen daar gelaten, maar dat is niet zo heel spannend. De andere shiny speeltjes wisselen om de zoveel jaar.
Een paar jaar geleden probeerden mensen me nog wijs te maken dat ik toch echt flink moest investeren in
- Flash
- Zend framework
- JQuery
- Bootstrap
- WordPress

Want anders liep je achter. Maar de eindstand is natuurlijk dat de frameworks en libraries nooit zo heel spannend zijn, elke noob er wat mee kan bouwen en je nu niet zo flitsend meer bent met je Zend certificaat. Lui die echt prima zonder hulpmiddelen kunnen PHP'en/JavaScripten zijn een stuk zendzamer, dan mensen die wat met Laravel en React in elkaar kunnen knallen.
Niet dat je geen tools moet gebruiken overigens als je daar graag mee werkt. Maar het zegt heel weinig imo, sowieso kan je met de meeste van die dingen zonder ervaring beginnen en het je heel snel eigen maken.

[ZaZ]

Voor de Fork gebruikers:
Fork gaat binnenkort betaald worden. Als je 'm koopt met de coupon earlybird dan krijg je wat korting.

[Merethil]

ZaZ schreef op donderdag 16 januari 2020 @ 10:32:
Voor de Fork gebruikers:
Fork gaat binnenkort betaald worden. Als je 'm koopt met de coupon earlybird dan krijg je wat korting.

Ik zie op de website zo geen melding hiervan. Waar heb je dit gezien? Op 't moment staat bij de downloads ook nog gewoon "free" en verder geen opmerkingen over "paid in the future" oid...

Edit: Zie wel wat op github hierover, en blijkbaar op https://fork.dev/buy maar zelfs de MacOS-versie heeft mij nog niet geprompt om een licentie te kopen.

[ Voor 15% gewijzigd door Merethil op 16-01-2020 10:51 ]

[armageddon_2k1]

Merethil schreef op donderdag 16 januari 2020 @ 10:38:
[...]


Ik zie op de website zo geen melding hiervan. Waar heb je dit gezien? Op 't moment staat bij de downloads ook nog gewoon "free" en verder geen opmerkingen over "paid in the future" oid...

https://github.com/ForkIssues/TrackerWin/issues/571

Most likely we will not have a free version because we don't a time to support it. I'm not sure if the existing versions will work.

[Merethil]

armageddon_2k1 schreef op donderdag 16 januari 2020 @ 10:50:
[...]


https://github.com/ForkIssues/TrackerWin/issues/571


[...]

Dit vond ik ook dus net, maar voor nu is het nog een manier om ze te ondersteunen zonder verder de verplichting te kopen. Nog maar eens goed evalueren of ik deze wil houden dan, of dat ik b.v. overga op Git Extensions die hier veel voorbij komt.

[BarôZZa]

CodeCaster schreef op woensdag 15 januari 2020 @ 16:45:
[...]

Ik denk dat het probleem is dat je stelt dat de toegankelijkheid het probleem is. Jij vindt dat blijkbaar iedereen, ongeacht zijn taalbeheersing, kennisniveau, motivatie en geschiktheid om een beantwoordbare vraag te stellen, welkom moet zijn op het platform.

Ik ben het daar niet mee eens. Je moet eens weten hoeveel huiswerkdumps, non-repro's, duplicaten, vragen naar meningen en überhaupt onbegrijpelijke vragen er per dag gepost en gesloten worden. Het zijn juist de mensen die dergelijke vragen stellen en het deksel op hun neus krijgen, die vervolgens blogs en tweets gaan posten dat het zo'n nare site is. En die krijgen dan bijval van de mensen wie dat ook eens overkomen is. Dat maakt nog niet dat ze gelijk hebben in dat het anders moet.

Het feit dát er kwaliteitsstandaarden zijn, en dat die lange tijd gehandhaafd zijn, maakt dat de site is wat 'ie nu is, namelijk een geweldig naslagwerk voor de meest uiteenlopende programmeerproblemen.

Wat? Zijn er kwaliteitsstandaarden op Stack Overflow? Ik dacht dat het altijd gewoon één grote vraagbak was waar echt alles gesteld kon worden. De antwoorden zijn vaak ook van bedenkelijk niveau, vaak een JQuery oplossing om twee cijfers bij elkaar op te tellen. Dat betekent dat er dus nog een niveau lager is met bagger die gesloten wordt.

Maar juist doordat er relatief weinig gefilterd/gesloten wordt is de drempel laag en is de site zo groot geworden waardoor je praktisch alles kan vinden. De drempel verhogen lijkt me nooit zo handig.

Dan krijg je al snel dat één slechte vraag tien zure reacties oplevert van mensen die zich geroepen voelen om als gatekeeper op te treden. Dat had je hier op Tweakers ook, waardoor niemand meer een programmeervraag durfde te stellen, want dan kreeg je meteen allemaal dolle members op je dak die vonden dat je niet genoeg had gegoogled. Vind het zelf nooit zo'n probleem om iemand te helpen met z'n JQuery carousel op z'n Wordpress template oid . Maar veel developers voelen meer voor 2 minuten lang een zure reactie te typen ipv 1 minuutje te helpen.

"Try this: [code I found on Google]" is geen antwoord. Ja, misschien kan OP weer verder. Maar misschien zit er wel een dikke SQL injection vulnerability in die code. Je weet het niet, want de experts lezen de antwoorden niet meer. En de volgende die het antwoord vindt, weet niks van SQL injection. En zijn project compileert ook weer, dus hier, heb een upvote.

Maar dat is toch altijd zo geweest op SO? Ik zie de antwoorden ook meer om je op weg te helpen, zelden als perfecte oplossing die je meteen in productie kan knallen.

De kracht van SO is imo dát ze bijna overal een antwoord voor hebben, ook al is het antwoord crap. Ik geloof best dat er wat experts op de site rondhangen, maar het overgrote deel is verre van. Dat oudgedienden een community verlaten omdat ze het niet eens zijn met de richting is ook niks bijzonders. Een site wil meestal groeien, oude members willen vaak dat zaken vooral zo blijven als ze zijn, ook al stagneert de boel.

[Hydra]

BarôZZa schreef op donderdag 16 januari 2020 @ 12:28:
Ik dacht dat het altijd gewoon één grote vraagbak was waar echt alles gesteld kon worden.

Ik wil even dit stukje eruit lichten omdat ik 't interessant vind:

Het doel van SO is uberhaupt niet het zijn van een vraagbaak. Het doel van SO is een soort wikipedia van programmeerkennis te zijn. Met vragen en daarop kwalitatief goeie antwoorden. SO is heel expliciet niet voor "help mij met deze opdracht" type vragen bijvoorbeeld. Een eis aan elke vraag is dus dat het iets is dat voor meer dan 1 persoon nuttig is.

Het probleem is alleen dat het te idealistisch is; er zit vaak aardig wat nuance in een specifieke vraag, en bovendien verandert het antwoord overtijd omdat de talen / frameworks e.d. over tijd veranderen. En dat is het grootste probleem van SO; dat de accepted antwoorden van 10 jaar terug, nu wel eens volkomen verkeerd kunnen zijn.

M.i. is de kwaliteit in het algemeen geen enkel issue; over het algemeen hebben de meeste vragen goeie antwoorden. Ook zijn te specifieke vragen niet zo'n issue. De problemen zitten vooral in dat antwoorden niet goed mee kunnen veranderen en dat nuances te vaak wegvallen. Dit zit hem ook voor een groot dele in slechte moderatie; je ziet dan toch wel weer dat de kleinste stukjes macht mensen naar 't hoofd stijgen.

[BarôZZa]

@Hydra Je liet me bijna twijfelen.

Launched in 2010, the Stack Exchange network comprises 173 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Het is letterlijk een vraagbak en dat is heel slim, aangezien veel mensen een vraag googlen. Uiteraard snap ik dat ze liever niet hebben dat je post: 'hoe maak ik m'n huiswerk?' Want dat levert geen verkeer op. Zo lang je het formuleert als iets waar andere mensen ook naar zoeken is het volgens mij prima.

De vraag-format is ook slim omdat je zo specifieke content krijgt, bij klassieke forums had je veel sneller dat het offtopic ging.

Overigens zie ik juist wel regelmatig dat er nieuwe antwoorden bijkomen en mensen zeggen dat een ouder antwoord niet goed is. Misschien dat het niet het accepted antwoord is, maar daar kijk ik sowieso nooit naar.

Over de kwaliteit verschillen we denk ik van mening. Ik heb het hierbij overigens vooral over de code samples die geplaatst worden. Daar zitten hele wilde dingen tussen. Vaak ook onnodig complex/omslachtig. Of de bekende JQuery dingen.

Ik zat er vooral regelmatig toen ik met Magento moest werken. Ideaal om rare bugs/foutmeldingen te googlen, maar de oplossingen waren vaak tenenkrommend. Mogelijk dat het anders is bij populairdere vragen met meer antwoorden, maar ik kom vaak uit bij vragen met 1 of 2 antwoorden die allebei niet echt goed zijn.

[Hydra]

BarôZZa schreef op donderdag 16 januari 2020 @ 14:58:
@Hydra Je liet me bijna twijfelen.

Het komt uit een interview met Jeff Atwood, volgens mij kan je het wel ergens terugvinden op z'n blog (CodingHorror).

Over de kwaliteit verschillen we denk ik van mening. Ik heb het hierbij overigens vooral over de code samples die geplaatst worden. Daar zitten hele wilde dingen tussen. Vaak ook onnodig complex/omslachtig. Of de bekende JQuery dingen.

Ik lees vrijwel geen front-end posts, dus ik denk dat dat ook wel verschil maakt. Bij Java antwoorden zitten waarschijnlijk iets minder prutsers. En de slechte antwoorden hebben meestal een negatieve score.

[ Voor 46% gewijzigd door Hydra op 16-01-2020 15:18 ]

[ElkeBxl]

Zoals we hier in België zeggen: iemand zin in een tas koffie?

[Ryur]

ElkeBxl schreef op vrijdag 17 januari 2020 @ 09:11:
Zoals we hier in België zeggen: iemand zin in een tas koffie?

[Afbeelding]

Ik wil die chocolaatjes eromheen wel!
En lijkt mij heel lastig te drinken eigenlijk.

Vreemde mensen die Belgen

[ Voor 5% gewijzigd door Ryur op 17-01-2020 09:24 ]

[Crazy D]

Hydra schreef op donderdag 16 januari 2020 @ 14:27:
Een eis aan elke vraag is dus dat het iets is dat voor meer dan 1 persoon nuttig is.

Voor jou en je klasgenootjes

[gekkie]

Ryur schreef op vrijdag 17 januari 2020 @ 09:23:
Vreemde mensen die Belgen

Liever een sloot (van ditto kwaliteit) ?

Hmm kwaliteit van de bugmelding van de dag is ook weer ongeveer het niveau "Het doet het niet!" ..
Tsja moet je niet grumpy worden als ik semi ongezien retourneer dat "Bij mij doet het het wel, doei!".

[alienfruit]

Bah, vandaag ontslagen voornamelijk omdat ik geen leidersrol op mij nam gezien mijn senority en omdat het beter voor het project en team was dat ik weg ging. Oftewel er waren gewoon één of een paar mensen in Product die mijn kop niet aan stonden en mij er uit hebben gewerkt. Gelukkig hebben ze het niet gisteren gedaan dat was namelijk de dag mijn moeder een jaar geleden overleed.

[ Voor 16% gewijzigd door alienfruit op 17-01-2020 16:10 ]

[wackmaniac]

Is dat valide grond om iemand te ontslaan?

[ Voor 4% gewijzigd door wackmaniac op 17-01-2020 16:21 ]

[downtime]

wackmaniac schreef op vrijdag 17 januari 2020 @ 16:13:
Is dat valide grond om iemand te ontslaan?

In de proeftijd wel.

[.oisyn]

downtime schreef op vrijdag 17 januari 2020 @ 16:47:
[...]

In de proeftijd wel.

In de proeftijd heb je geen valide reden nodig.

[Koenvh]

@alienfruit Sterkte met beide.

[Hydra]

@alienfruit wat rot zeg. Heb je dit helemaal niet aan zien komen?

[alienfruit]

Ik zag de bui inmiddels wel aankomen door een gesprek wat ik had met de baas eerder deze week. Ik was met van alles bezig, betere CI setup, betere automated tests, werkte aan betere documentatie of guidelines tbv. schrijven tests e.d. Ik had een versie van de nieuwe design al werkend. Maar ja, dat heb ik vanmiddag maar allemaal weg gegooid.

Maar een tijd terug heb ik een aanvaring gehad met een vrouwelijke collega; ze is behoorlijk dwingend, en vond het nooit leuk als je haar vroeg waarom ze bepaalde ontwerpkeuzes maakte. Nu zijn er meer mensen die niet echt lekker met haar samen werken of liever niet willen werken. Persoonlijk, denk dat zij de hoofdoorzaak is dat ik er uit lig.

[ Voor 33% gewijzigd door alienfruit op 17-01-2020 20:51 ]

[BladeSlayer1000]

@alienfruit sterkte!

[Hydra]

alienfruit schreef op vrijdag 17 januari 2020 @ 20:47:
Maar een tijd terug heb ik een aanvaring gehad met een vrouwelijke collega; ze is behoorlijk dwingend, en vond het nooit leuk als je haar vroeg waarom ze bepaalde ontwerpkeuzes maakte. Nu zijn er meer mensen die niet echt lekker met haar samen werken of liever niet willen werken. Persoonlijk, denk dat zij de hoofdoorzaak is dat ik er uit lig.

Klinkt dan ook niet echt als een fijn bedrijf om mee te werken. Misschien dus wel positief; zo'n incentive voor een stap vooruit in je carriere

Every cloud a silver lining enzo...

[alienfruit]

Dank je wel, komt vast wel goed. Ik krijg een maand doorbetaald zonder op kantoor te hoeven komen.
Voelt alleen vervelend om meteen weg te worden gestuurd zonder afscheid te kunnen nemen van andere collega's op andere verdiepingen of je werk voor de meeting af te ronden.

[.oisyn]

Da's wel heel rigoureus. Jij zat niet in NL toch?

[alienfruit]

Ja, werkte bij een bank in Londen. Ik hoorde van een collega dat deze vrouwelijke collega waar ik een aanvaring mee had en er zijn minstens drie of vier mensen die niet meer haar samen willen werken.

[Alex)]

Dat is wel heel rigoreus... sterkte en succes bij de zoektocht naar iets nieuws.

[Lethalis]

@alienfruit Sterkte!

[Antrax]

alienfruit schreef op vrijdag 17 januari 2020 @ 20:47:
Ik zag de bui inmiddels wel aankomen door een gesprek wat ik had met de baas eerder deze week.

Vervelend om te horen. Gelukkig liggen de banen voor het oprapen.

[alienfruit]

Eigenlijk verveel ik mij de pleuris momenteel.

[Koenvh]

alienfruit schreef op maandag 20 januari 2020 @ 11:55:
Eigenlijk verveel ik mij de pleuris momenteel.

Ik wil best wel wat werk doorschuiven hoor
En anders kun je altijd nog op koekjes gaan klikken

[scosec]

alienfruit schreef op maandag 20 januari 2020 @ 11:55:
Eigenlijk verveel ik mij de pleuris momenteel.

Mooi de tijd om weer eens een extra verdieping te doen in techniek of er iets nieuws bij te pakken.

Verveel mijzelf zelden

[alienfruit]

Als je een lichte vorm van depressie hebt nadat je ouders en oma is overleden binnen twee jaar dan heb ik zelf liever wat bezigheidstherapie (en houd je af van sombere gedachten) zoals werk wat er nu niet is. Zou deze week ook naar de therapeut gaan maar HR doet vaag of dit nog mogelijk is.

Wat is nu qua technologie slim om te leren afgezien van Kubernetes?

[scosec]

alienfruit schreef op maandag 20 januari 2020 @ 12:45:
Als je een lichte vorm van depressie hebt nadat je ouders en oma is overleden binnen twee jaar dan heb ik zelf liever wat bezigheidstherapie (en houd je af van sombere gedachten) zoals werk wat er nu niet is. Zou deze week ook naar de therapeut gaan maar HR doet vaag of dit nog mogelijk is.

Wat is nu qua technologie slim om te leren afgezien van Kubernetes?

Heftig. Bezig zijn wil dan wel helpen denk ik. Sporten is ook niet verkeerd trouwens.

Wat voor functie oefen je precies uit? Kan wel wat dingen roepen maar weet niet of je daar iets aan hebt.

[alienfruit]

Ik werkte aan FX trading platform voor een bank voor de SME sector; bezig met ASP.NET Core 3, React, bezig met het opbouwen van een design system om wat orde in de zaak te brengen, verbeteren van de algehele accessibility van de website. Er waren plannen om naar de cloud te gaan met Helm, Kubernetes, Jenkins etc. Docker snap ik wel maar Kubernetes ken eigenlijk alleen bij naam. Ik last net wel over Hasura GraphQL dat ziet er wel cool uit

[CodeCaster]

@alienfruit wat ik soms wel interessant vind is de ThoughtWorks Technology Radar.

Een keer of twee per jaar brengen ze platforms, technologieën, tools en talen in kaart. Natuurlijk is het niet alomvattend noch zaligmakend, maar het geeft wel een idee van richtingen die je zou kunnen gaan onderzoeken.

[alienfruit]

Ja, dat ken ik. Helemaal niet aan gedacht om naar te kijken. Zitten leuke dingen in ook redelijk wat Java gerelateerde dingen.

[scosec]

alienfruit schreef op maandag 20 januari 2020 @ 13:19:
Ik werkte aan FX trading platform voor een bank voor de SME sector; bezig met ASP.NET Core 3, React, bezig met het opbouwen van een design system om wat orde in de zaak te brengen, verbeteren van de algehele accessibility van de website. Er waren plannen om naar de cloud te gaan met Helm, Kubernetes, Jenkins etc. Docker snap ik wel maar Kubernetes ken eigenlijk alleen bij naam. Ik last net wel over Hasura GraphQL dat ziet er wel cool uit

Kubernetes kan. Ik weet niet hoe ver je in de ops kant wilt duiken. Ik vind persoonlijk dat als developer meer iets voor de ops kant. Die infra wil ik niet perse mee bezig zijn. Dat is meer een specialisme op zichzelf voor mijn idee.

Je kunt ook in Azure duiken. Daar zitten ook wat leuke speeltjes in als je toch in de MS Stack werkt.

[alienfruit]

Je hebt helemaal gelijk hoor @scosec maar ik denk een basis begrip van Kubernetes kan nooit kwaad. Net als de weg een beetje weten met Docker enzo.

[armageddon_2k1]

De basis van Kubernetes kennen is niet zo moeilijk en zal ik altijd aanraden. Het is gewoon altijd handig als je iig de taal spreekt van DevOps.

[Skyaero]

Is er een devOps software oorlog aan de gang of zo? Ik wordt op verschillende platformen, zoals Reddit en Linkedin, doodgegooid met advertenties voor DevOps tools, zoals CircleCI en Harness.

Ik heb het gevoel alsof ik iets aan het missen ben. Voor de record, ik zit volledig in de Microsoft tools en gebruik dus ook Azure DevOps.

[dev10]

Skyaero schreef op dinsdag 21 januari 2020 @ 10:41:
Is er een devOps software oorlog aan de gang of zo? Ik wordt op verschillende platformen, zoals Reddit en Linkedin, doodgegooid met advertenties voor DevOps tools, zoals CircleCI en Harness.

Ik heb het gevoel alsof ik iets aan het missen ben. Voor de record, ik zit volledig in de Microsoft tools en gebruik dus ook Azure DevOps.

Herkenbaar dit. Afgelopen paar maanden ben ik mezelf aardig aan het inlezen op het gebied van DevOps, Kubernetes, AWS, Azure, etcetera en ik word doodgegooid met dit soort advertenties.

[armageddon_2k1]

Aangezien Google aangegeven heeft dat ze grootste willen worden met Cloud diensten binnen een paar jaar denk ik dat de concurrenten denken: "De beste verdediging is de aanval".

[kwaakvaak_v2]

armageddon_2k1 schreef op dinsdag 21 januari 2020 @ 11:55:
Aangezien Google aangegeven heeft dat ze grootste willen worden met Cloud diensten binnen een paar jaar denk ik dat de concurrenten denken: "De beste verdediging is de aanval".

Maar al die CI/CD diensten zijn niet van Google

Wel is er op dit moment een soort van hype aan gang rond GITOps, en veel van die tools springen daar handig op in en zijn naarstig op zoek naar klanten voor hun dienst. Beetje vergelijkerbaar met wat er jaren terug gebeurde in hosting land met control panel systemen waarmee vrij snel 'hosting providertje' kon spelen.

Een deployment maken voor Kubernetes is best ingewikkeld als je er voor de eerste keer naar kijkt, je moet service definition, ingress, volumes, deploy YAML files maken, of je eerst verdiepen in hoe HELM charts werken. En veel van die tools proberen die drempel te verlagen, en dat is denk ik wel een goede zaak. Veel developers willen helemaal niet bezig zijn met hoe, wat en waar deployment van hun code. Die willen gewoon naar een branch commiten, of een tag toevoegen en klaar. En of dat nu naar AKS,GCE, EKS of iets anders is, zou helemaal niet moeten uitmaken. Zolang je maar een container hebt met je applicatie erin en een systeem wat die container er naar toe duwt.

Kubernetes is op dat gebied denk ik voorlopig wel een blijvertje, als je het goed opzet kun je relatief gemakkelijk wisselen van Cloud leverancier omdat het systeem en de API zo opgezet is dat je je alle vendor specifieke classes zoals bijvoorbeeld storage gewoon kan vervangen voor een andere, zolang die class maar de storage interface implementeert.

[armageddon_2k1]

kwaakvaak_v2 schreef op dinsdag 21 januari 2020 @ 14:31:
[...]


Maar al die CI/CD diensten zijn niet van Google

Dat is mijn punt, of begrijpen we elkaar totaal niet.

[kwaakvaak_v2]

armageddon_2k1 schreef op dinsdag 21 januari 2020 @ 14:33:
[...]

Dat is mijn punt, of begrijpen we elkaar totaal niet.

Ik vrees dat, dat laatste het geval was

[alienfruit]

Tijdens mijn zoektocht naar Kubernetes studiemateriaal kwam ik ook Flagger (https://docs.flagger.app/faq) tegen. Kennen jullie dit? Het ziet er voor mij indrukwekkend uit en lijkt mij best handig dat je je traffic naar PROD en zowel je toekomstige PROD kan sturen en kijken of alles goed verwerkt wordt. Zo ja, automatisch promotie van deze nieuwe build.

[SPee]

Nee, nooit van gehoord. Wel van een ander product dat zoiets doet; vamp.

Met de huidige CI/CD tools zullen er wel meer producten zijn die dat doen.

[ Voor 29% gewijzigd door SPee op 21-01-2020 22:43 ]

[Renzmeister]

Als je Kubernetes overweegt, kan ik aanraden om je op zijn minst ook even te verdiepen in Docker Swarm. Is een beetje een ondergeschoven kindje t.o.v. Kubernetes, maar is veel eenvoudiger in gebruik en behoorlijk krachtig. Is ook nog eens secure by default, wat Kubernetes niet is.

[kwaakvaak_v2]

Renzmeister schreef op woensdag 22 januari 2020 @ 11:19:
Als je Kubernetes overweegt, kan ik aanraden om je op zijn minst ook even te verdiepen in Docker Swarm. Is een beetje een ondergeschoven kindje t.o.v. Kubernetes, maar is veel eenvoudiger in gebruik en behoorlijk krachtig. Is ook nog eens secure by default, wat Kubernetes niet is.

Swarm is zeker een mooi product, maar het probleem van Swarm is dat het niet helemaal helder is wat de toekomst daar van is.

Mirantis trekt de stekker uit de commercieele support van Swarm. En het is twijfelachtig hoe lang Docker Inc. (het bedrijf achter de Docker runtime) kan blijven bestaan nu ze hun kroon juwelen aan Mirantis hebben verkocht. Ik verwacht niet dat de andere container runtime's een swarm mode achtig iets gaan inbouwen.

Wat dat betreft is ook het wel interessant om in de gaten te houden wat Rancher Labs allemaal aan het doen is. Die zijn heel hard bezig om juist het operationele beheer deel van selfhosted K8s veel makkelijker te maken. Eenvoudig uitrollen van nieuwe clusters met RKE of K3s. Versimpelen van deployements via RIO en het managen van je cluster via de Rancher UI.

[plofkip]

Renzmeister schreef op woensdag 22 januari 2020 @ 11:19:
...
Is ook nog eens secure by default, wat Kubernetes niet is.

Wat is er by default niet secure aan k8s dan?

[alienfruit]

Ik zit nu een beetje te kijken naar http://skaffold.dev dat ziet er ook interessant uit. Ik vind Kubernetes er makkelijk uit zien in de videos maar als je er eenmaal zelf mee aan de slag gaat valt het vies tegen. Misschien moet ik gewoon zoiets als de Google of AWS cloud variant gebruiken ipv. van zoiets als k3s?

De Vamp.io website vermeld allemaal dingen waar vervolgens niks over te vinden is in de documentatie bijv. feature toggles of A/B testing. Ik ben eigenlijk wel op zoek naar een open-source oplossing hiervoor.

[ Voor 25% gewijzigd door alienfruit op 22-01-2020 15:04 ]

[gekkie]

Mjah .. op zich zijn al die framework / tools er over heen interessant, maar wat als het broodje poep de ventilator raakt ome Willem ?

Hetzelfde heb ik een beetje bij: "de deployment dat is voor devops en niet voor devs."
Mjah leuk, maar als je er als dev niet goed voor zorgt dat je applicatie en al zijn dependencies goed met de effecten van kubernetes overweg kunnen, ben je vooral van een SPOF naar een MPOF gegaan met in het ergste geval corrupte data.

[kwaakvaak_v2]

gekkie schreef op woensdag 22 januari 2020 @ 15:11:
Mjah .. op zich zijn al die framework / tools er over heen interessant, maar wat als het broodje poep de ventilator raakt ome Willem ?

Hetzelfde heb ik een beetje bij: "de deployment dat is voor devops en niet voor devs."
Mjah leuk, maar als je er als dev niet goed voor zorgt dat je applicatie en al zijn dependencies goed met de effecten van kubernetes overweg kunnen, ben je vooral van een SPOF naar een MPOF gegaan met in het ergste geval corrupte data.

Dat risico is in een niet container based omgeving ook aanwezig, maar dan met andere dependencies.

[Frolos]

mijn ARM templates werken niet mee /vent

[Hydra]

alienfruit schreef op woensdag 22 januari 2020 @ 14:57:
Ik zit nu een beetje te kijken naar http://skaffold.dev dat ziet er ook interessant uit. Ik vind Kubernetes er makkelijk uit zien in de videos maar als je er eenmaal zelf mee aan de slag gaat valt het vies tegen. Misschien moet ik gewoon zoiets als de Google of AWS cloud variant gebruiken ipv. van zoiets als k3s?

Je moet ook niet zelf een K8s cluster gaan beheren. Da's complete tijdverspilling. Dat soort 'eigen' clusters zijn vooral bedoeld om te leren.

Als dev iets in K8s deployen is behoorlijk simpel, niet complexer dan dat zelf rechtstreeks op een VM te doen in ieder geval. Een cluster orchestrator beheren daarentegen is gewoon werk voor specialisten. Ga dus geen eigen K8s clusters runnen als je ook minimaal 2 Opsers kunt betalen inclusief on-call diensten.

[alienfruit]

Oh ja, ik snap dat je zoiets als AWS of GKS wil gebruiken uiteindelijk maar qua zelfstudie is het wel handig. Het is een knap staaltje werk

Ik had vandaag ook een job interview en willen niet verder wegens mijn beperkte AWS kennis. Ik vraag mij af wat ze verwachten? Er zijn zoveel diensten van AWS dat je bijna niet alles kan kennen. Ik heb voornamelijk met de IoT gerelateerde producten gewerkt en natuurlijk S3, Lambda's, EC2. Maar dat was dus niet genoeg. Zelf kenden ze IoT producten van AWS weer niet of ABAP.

[ Voor 57% gewijzigd door alienfruit op 23-01-2020 12:25 ]

[Hydra]

@alienfruit waar kreeg je specifiek vragen over?

[Mugwump]

alienfruit schreef op donderdag 23 januari 2020 @ 12:22:
Oh ja, ik snap dat je zoiets als AWS of GKS wil gebruiken uiteindelijk maar qua zelfstudie is het wel handig. Het is een knap staaltje werk

Ik had vandaag ook een job interview en willen niet verder wegens mijn beperkte AWS kennis. Ik vraag mij af wat ze verwachten? Er zijn zoveel diensten van AWS dat je bijna niet alles kan kennen. Ik heb voornamelijk met de IoT gerelateerde producten gewerkt en natuurlijk S3, Lambda's, EC2. Maar dat was dus niet genoeg. Zelf kenden ze IoT producten van AWS weer niet of ABAP.

Als je zo gedetailleerd zoekt naar vaardigheden dan moet je als werkgever wel heel gewild zijn. Ik zou ook wel collega's willen aannemen die echt goed snappen hoe je goede software ontwikkelt, alle AWS services van buiten kennen en ga zo maar door, maar wij moeten toch echt vaak genoegen nemen met heel wat minder. Als mensen maar op hoofdlijnen snappen hoe zaken werken dan dat ze uit hun hoofd kunnen oplepelen hoe je in Cloudformation een securitygroup definieert of iets dergelijks.

Zou op zich ook af en toe wel eens wat minder middelmatige collega's wensen. Zit nu weer een stuk werk van een collega dat 'af' was voordat hij lekker twee weken op vakantie ging te herschrijven. Leuk dat je probeert een abstractie van een repository te maken met een interface, maar dan moet je daar natuurlijk niet gaan werken met return types die bij één van de specifieke database implementatie horen. Zou bijna archunit gaan gebruiken om af te dwingen dat je in de domain package geen rechtstreekse references naar aws sdk packages mag hebben, maar dan weet ik al wat er gebeurt...dan verhuist de interface gewoon naar de infra package. Verder is het ook wel handig dat je je bij een batch proces afvraagt hoe je omgaat met failures / retries, even nadenken over de hoeveelheden data en verwerkingstijd voordat je gewoon alles doodleuk in je geheugen laadt en ga zo maar door, zucht.

[armageddon_2k1]

Heb je liever iemand die precies alles weet dat voldoet aan het functieprofiel of iemand die het niet allemaal weet maar heel duidelijk in staat is zich dingen eigen te maken en bij te leren? Ik weet het wel.

[Hydra]

Mugwump schreef op donderdag 23 januari 2020 @ 13:10:
Als mensen maar op hoofdlijnen snappen hoe zaken werken dan dat ze uit hun hoofd kunnen oplepelen hoe je in Cloudformation een securitygroup definieert of iets dergelijks.

Precies. Shit die ik 1 keer per jaar doe, onthou ik niet. Ik onthou waar ik dingen kan vinden. Veel efficienter.

Zou op zich ook af en toe wel eens wat minder middelmatige collega's wensen. Zit nu weer een stuk werk van een collega dat 'af' was voordat hij lekker twee weken op vakantie ging te herschrijven. Leuk dat je probeert een abstractie van een repository te maken met een interface, maar dan moet je daar natuurlijk niet gaan werken met return types die bij één van de specifieke database implementatie horen. Zou bijna archunit gaan gebruiken om af te dwingen dat je in de domain package geen rechtstreekse references naar aws sdk packages mag hebben, maar dan weet ik al wat er gebeurt...dan verhuist de interface gewoon naar de infra package. Verder is het ook wel handig dat je je bij een batch proces afvraagt hoe je omgaat met failures / retries, even nadenken over de hoeveelheden data en verwerkingstijd voordat je gewoon alles doodleuk in je geheugen laadt en ga zo maar door, zucht.

Let de hate flow. Ben zelf wel een fan van ArchUnit maar zou het niet snel inzetten. Dit is een soort van 'common sense' die mensen hebben of niet, en je voornaamste hoop is dat ze open staan voor het idee dat ze iets nieuws moeten leren.

Dit alles neemt overigens niet weg dat "je weet niet genoeg van AWS" waarschijnlijk niet echt het hele verhaal is. Bedrijven zijn gewoon summier in feedback bij afwijzingen omdat je anders vaak gezeur krijgt.

[Frolos]

armageddon_2k1 schreef op donderdag 23 januari 2020 @ 13:47:
Heb je liever iemand die precies alles weet dat voldoet aan het functieprofiel of iemand die het niet allemaal weet maar heel duidelijk in staat is zich dingen eigen te maken en bij te leren? Ik weet het wel.

Ik ben heel blij dat mijn huidige team inzag dat ik die competenties heb. Nu bij de werving van een nieuw teamlid is dat ook alles waar ik persoonlijk naar kijk. Conceptueel denken en eagerness zijn minstens net zo belangrijk als parate kennis

[Renzmeister]

plofkip schreef op woensdag 22 januari 2020 @ 12:56:
[...]

Wat is er by default niet secure aan k8s dan?

Correct me if I'm wrong. Maar volgens mij kunnen -default- in k8s alle pods met elkaar communiceren. Docker maakt gebruik van Linux bridges op de host om te bepalen welke containers met elkaar kunnen communiceren (en uiteraard host -> container port mapping). En in Swarm mode maakt Docker overlay networks o.b.v. de services die je creeert (en ook hier kan je een service extern ontsluiten d.m.v. port forwarding).

[plofkip]

Renzmeister schreef op donderdag 23 januari 2020 @ 14:49:
[...]


Correct me if I'm wrong. Maar volgens mij kunnen -default- in k8s alle pods met elkaar communiceren. Docker maakt gebruik van Linux bridges op de host om te bepalen welke containers met elkaar kunnen communiceren (en uiteraard host -> container port mapping). En in Swarm mode maakt Docker overlay networks o.b.v. de services die je creeert (en ook hier kan je een service extern ontsluiten d.m.v. port forwarding).

Weet zo even niet uit m'n hoofd of dat zo is, maar ik zie het probleem niet zo als je gebruik kunt maken van namespaces.

[gekkie]

Voor wie weer in de schoolbanken wil (of lui live-streamen, maarja dan missen we je goede vragen):
https://fosdem.org/2020/s.../containers_and_security/
https://fosdem.org/2020/schedule/track/containers/

[Matis]

Ik probeer (in PHP) al de hele dag een nette functie te schrijven welke een bedrag (float) omhoog afrondt naar x,95. Dus 0.50 wordt 0.95, 0.95 blijft 0.95 en 0.96 wordt 1,95.

Het pad dat ik nu bewandel is dat ik de float cast naar een integer, de remainder inspecteer. Is deze minder dan 0.95, tel dan 0.95 bij de int op. Is deze meer dan 0,95 tel dan 1.95 bij de int op.

Het voelt zo omslachtig, maar kan geen "nettere" (lees leesbare) manier bedenken...

[I-King]

@Matis kun je hier iets mee? Ceil (x + 0,05) - 0,05

[ Voor 41% gewijzigd door I-King op 23-01-2020 15:54 ]