De Devschuur Coffee Corner - Iteratie ⓬

[armageddon_2k1]

Fair enough, naar herlezen heb je misschien wel gelijk....

misschien

[plofkip]

Docker rulez!

[CurlyMo]

dovo schreef op donderdag 12 september 2019 @ 22:10:
[...]
Van Docker zelf ben ik tamelijk tevreden. De hele doe alles in docker hype echter niet. Mijn wordpress blog staat gewoon op een shared hosting server, dat werkt prima en ik zie ook geen reden om dat in Docker of Kubernetes te steken.

Ik heb hier een VPS en daar ook gratis WP sites voor familie op gehost. Die staan in dockers zonder internet toegang. Toegang tot de docker gaat via een Nginx proxy. Als er een update moet plaatsvinden dan zet ik het internet toegang even aan. Zo kan ik toch veilig WP sites hosten van onkundige familieleden.

[Janoz]

Voor mijn huidige thuisserver heb ik de meest minimale ubuntu headless neergezet met eigenlijk alleen maar ssh er op. Alles draai ik vervolgens in Docker. Zeker omdat ik wel eens wat probeer vind ik het persoonlijk wel fijn dat ik gewoon weer een image weg kan flikkeren als ik er niks meer mee doe en dat ik dan niet 'bang' hoef te zijn dat er van alles blijft hangen. Ik nu ook erg simpel meerdere versies van dezelfde applicaties kan draaien. Speciaal voor zoneminder heb ik dan bijvoorbeeld nog een oude mysql5 draaien terwijl andere images gewoon de nieuwste mysql gebruiken. Door verschillende interne netwerken te gebruiken heb ik ook geen gepuzzel meer met al die verschillende poorten die al die applicaties willen exposen. En aangezien ik op linux draai is de extra overhead tov native draaiende applicaties helemaal niks.

Dus zelfs voor de gemiddelde thuisserver zie ik eigenlijk alleen maar voordelen om eerlijk te zijn.

[WernerL]

* WernerL probeert zich vandaag een weg te banen in de codebase van het bedrijf waar ik deze week gestart ben. Ik kom dit tegen:

JavaScript:

    let f: any = d.getElementsByTagName(s)[0];
    let j: any = d.createElement(s);
    let dl: any = l !== "dataLayer" ? "&l=" + l : "";

Iemand had geen zin om correcte type-informatie op te geven en is blijkbaar niet bekend met type-inference.

Sowieso wordt ik niet heel erg blij van dit AngularJS gebakje. Hiervoor alles met Typescript en react gedaan en dan is Angular in vergelijking eigenlijk best wel kut. Vooral omdat views niet typesafe zijn en er blijkbaar geen fatsoenlijke manier bestaat voor state-management. (State all over the place.. )


/rant

[farlane]

Weg daar, voor het te laat is.

[Mugwump]

dovo schreef op donderdag 12 september 2019 @ 20:57:
[...]


Er zal geen migratie naar python3 gebeuren is hun antwoord, ze beweren naar Go te migreren, maar hun experimentele repo waar dit in zit is een boeltje, en de main dev die commits deed is een half jaar geleden naar google vertrokken. Omdat ze gebaseerd zijn op zo een van die kei vage enterprise XML schema architecturen hebben ze ergens in 2012 generateDS.py geforked en nooit geupdatet naar de python3 compatible versie. Hun hele architectuur is dus zo brak tot wortel en een rewrite is de enige oplossing. Maar dat brengt natuurlijk geen bonus in het laatje bij management, dus blijven ze maar alle problemen met hun product naar ons - de kant - doorschuiven. Ik denk dat zij ervan uitgaan dat zolang ze centos7 blijven gebruiken ze nog 5 jaar safe zijn met python2.

Nou is verhuizen van Python naar Go geen slechte kueze natuurlijk, maar als het niet doorgezet wordt heb je daar weinig aan.

Ze gebruiken bijvoorbeeld ook Cassandra om alle data bij te houden, niet omdat Cassandra de juiste database was, de data vereist een ACID compliant database. Ik vermoed dat ze voor Cassandra kozen omdat een of andere zelfverklaarde expert daar een veto heeft getrokken. Als je dus queries op de API loslaat krijg je meestal errors omdat er concurrency/race conditions ontstaan. Door de loadbalancer te skippen, en een van de backend servers direct aan te spreken, kan je alvast een lagere error rate krijgen.

Mja, ik vind dat een beetje vreemde eis. An sich zegt ACID compliance van een database niet zoveel over concurrency / race conditions die je krijgt door API request. Als je je data juist opslaat, dan kun je de consistency gewoon tunen en dan krijg je wel terug wat er is weggeschreven.

Ik snap gewoon niet hoe dit allemaal kan, in mijn eerste jaar bachelor heb ik professionelere php5 projecten gezien door klasgenoten en die gebruikten nergens input sanitation.

Leuk om deze topic te lezen. Ik dacht dat ik de enige was die niet geobsedeerd is van Dockerize everything en dat Docker vreselijke en obsolete software architecturen maar zal oplossen.

Zit nu in een vrij groot project waar we (onder andere) van on-premise naar AWS migreren. Daarin merk je het gemak van het feit dat een enorme monolith al deels was opgesplits in gedockerizede microservices wel. Daarentegen zijn er ook zaken die we uit docker halen en gewoon in lambda's stoppen (wat uiteindelijk ook weer docker is onder de motorkap natuurlijk). Er moet ook nog een ouderwetse, behoorlijk slecht geschreven monolith overgezet worden. Ik weet nu al dat dat heel wat meer hoofdbrekens gaat geven.

[dovo]

Mugwump schreef op vrijdag 13 september 2019 @ 13:49:
Daarin merk je het gemak van het feit dat een enorme monolith al deels was opgesplits in gedockerizede microservices wel.

Ze gebruiken docker om bare-metal systemen te configureren. Ze runnen Docker met `--privileged` en escpapen de cgroups met een heel nasty bash script, waarna ze dus op de host scripts runnen. De applicatie waar ik het over heb is geen boekhoudpakket of soortgelijke applicatie, maar een kernelspace SDN voor openstack. Zelfs de kernel module injecteren ze vanuit Docker, bij een apt-update ligt het hele systeem er dan ook gewoon uit want er is geen apt-hook die deze rebuild. Verder gebruiken ze host networking met hardcoded poorten, dus niet docker networking. Ik zie echt niet in waarom je het ip adres van een interface door middel van een Docker container zou moeten instellen in plaats van ifupdown/systemd-networkd te gebruiken.

Over de database: misschien is een nosql database een optie, maar de huidige setup is gewoon zodanig gebroken dat het niet bruikbaar is. eg volgende restcalls.
eerst Post: maak mij resource A aan => Krijg OK terug
vervolgens Get: bestaat resource A? => Krijg OK terug
tenslotte Delete: verwijder resource A? => Sorry, resource A bestaat niet.

Ook even naar de python2 naar Go migratie gekeken, de twee gebruikers die code in deze repo staken zijn al vertrokken. Eentje in januari naar google, de andere in mei naar ergens anders. Ik denk niet dat we dit voor Centos9 gaan zien.

[plofkip]

C#:

public string action { get; set; } // Small letter because of naming conflicts

[dev10]

Oh wauw. Ik ken mensen die dat precies zo zouden kunnen doen.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Voutloos]

Nou ja, een commit reverten omdat de auteur te lui is om het zelf een keer te laten slagen op de pipeline vind ik anders helemaal niet zo heel absurd.

[ Voor 4% gewijzigd door Voutloos op 13-09-2019 20:48 ]

[Sandor_Clegane]

Jemig, Kubernetes.....Moving parts much?

Heb het aan de praat, maar jonge jonge wat een hoop spul heb je nodig zeg.
MetalLB, Helm & Tiller NFS provisioning client 4 Rpi's en dan ook nog de ARM packages anders: format exec errors up the wazoo.

code:

user@hephaestus:~/development/projects/docker/kubernetes$ kubectl get all -n kube-system
NAME                                                            READY   STATUS    RESTARTS   AGE
pod/coredns-86c58d9df4-m9h2r                                    1/1     Running   2          184d
pod/coredns-86c58d9df4-zptv5                                    1/1     Running   2          184d
pod/etcd-unicron-master                                         1/1     Running   0          8h
pod/hissing-sasquatch-nfs-client-provisioner-764687f76d-s7c74   1/1     Running   0          9m50s
pod/kube-apiserver-unicron-master                               1/1     Running   0          8h
pod/kube-controller-manager-unicron-master                      1/1     Running   0          8h
pod/kube-proxy-6tjzz                                            1/1     Running   2          184d
pod/kube-proxy-7bjb9                                            1/1     Running   2          184d
pod/kube-proxy-dzc5j                                            1/1     Running   2          184d
pod/kube-proxy-j65jd                                            1/1     Running   2          184d
pod/kube-scheduler-unicron-master                               1/1     Running   0          8h
pod/kubernetes-dashboard-56bcddb89b-js6jk                       1/1     Running   2          184d
pod/tiller-deploy-64dddb8f95-6dzzg                              1/1     Running   0          20m
pod/weave-net-6dk6r                                             2/2     Running   6          184d
pod/weave-net-d4vpq                                             2/2     Running   6          184d
pod/weave-net-kwm5b                                             2/2     Running   6          184d
pod/weave-net-lr8sr                                             2/2     Running   6          184d


NAME                           TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)         AGE
service/kube-dns               ClusterIP   10.96.0.10     <none>        53/UDP,53/TCP   184d
service/kubernetes-dashboard   ClusterIP   10.97.20.62    <none>        443/TCP         184d
service/tiller-deploy          ClusterIP   10.100.51.54   <none>        44134/TCP       26m

NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/kube-proxy   4         4         0       4            0           <none>          184d
daemonset.apps/weave-net    4         4         0       4            0           <none>          184d

NAME                                                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/coredns                                    0/2     2            0           184d
deployment.apps/hissing-sasquatch-nfs-client-provisioner   1/1     1            1           9m51s
deployment.apps/kubernetes-dashboard                       0/1     1            0           184d
deployment.apps/tiller-deploy                              1/1     1            1           26m

NAME                                                                  DESIRED   CURRENT   READY   AGE
replicaset.apps/coredns-86c58d9df4                                    2         2         0       184d
replicaset.apps/hissing-sasquatch-nfs-client-provisioner-764687f76d   1         1         1       9m51s
replicaset.apps/kubernetes-dashboard-56bcddb89b                       1         1         0       184d
replicaset.apps/tiller-deploy-64dddb8f95                              1         1         1       20m
replicaset.apps/tiller-deploy-7557459999                              0         0         0       26m




user@hephaestus:~/development/projects/docker/kubernetes$ kubectl get nodes
NAME              STATUS   ROLES    AGE    VERSION
unicron-master    Ready    master   184d   v1.15.3
unicron-worker1   Ready    <none>   184d   v1.15.3
unicron-worker2   Ready    <none>   184d   v1.15.3
unicron-worker3   Ready    <none>   184d   v1.15.3

Dat is dan wel weer leuk, een cluster van 4 Rpi's met een ZFS NFS mount van de Linux NAS af. Yay pielen!

[ Voor 89% gewijzigd door Sandor_Clegane op 13-09-2019 22:01 ]

[Lethalis]

Het is maandagochtend.

Ik gebruik niet vaak Docker, maar had nu snel Docker nodig om een image te maken... en kom er vervolgens achter dat het ineens niet meer op mijn computer staat. Geen idee waarom - want het stond er echt op en zeurde ook altijd om updates - maar ik denk "nou dan download ik het wel even snel opnieuw".

Vervolgens blijkt dat ik nu een account moet aanmaken en dat ze van alles willen weten.

En dat om 8 uur 's ochtends. Ja, dan ben ik niet op mijn best.

Dus ik probeer uit frustratie een account aan te maken met de naam "kutdocker"

Wat blijkt?

Het account bestaat al

Ik heb nu kutdocker2019

[ Voor 5% gewijzigd door Lethalis op 16-09-2019 08:14 ]

[RayNbow]

@Lethalis: Waarom niet bugmenot of zo gebruiken?

[kevintjeb]

@Lethalis Hmm. Had je dat account nodig bij het installeren of om het te kunnen downloaden? Bij het installeren kon ik het inloggen namelijk overslaan..

[Lethalis]

RayNbow schreef op maandag 16 september 2019 @ 08:30:
@Lethalis: Waarom niet bugmenot of zo gebruiken?

Hey dat ken ik helemaal niet! Is wel een idee voor de volgende keer ja.

kevintjeb schreef op maandag 16 september 2019 @ 08:31:
@Lethalis Hmm. Had je dat account nodig bij het installeren of om het te kunnen downloaden? Bij het installeren kon ik het inloggen namelijk overslaan..

Om het te kunnen downloaden. Ik zit op Windows btw.

[Douweegbertje]

Sandor_Clegane schreef op vrijdag 13 september 2019 @ 21:54:
Jemig, Kubernetes.....Moving parts much?

Heb het aan de praat, maar jonge jonge wat een hoop spul heb je nodig zeg.
MetalLB, Helm & Tiller NFS provisioning client 4 Rpi's en dan ook nog de ARM packages anders: format exec errors up the wazoo.

code:

user@hephaestus:~/development/projects/docker/kubernetes$ kubectl get all -n kube-system
NAME                                                            READY   STATUS    RESTARTS   AGE
pod/coredns-86c58d9df4-m9h2r                                    1/1     Running   2          184d
pod/coredns-86c58d9df4-zptv5                                    1/1     Running   2          184d
pod/etcd-unicron-master                                         1/1     Running   0          8h
pod/hissing-sasquatch-nfs-client-provisioner-764687f76d-s7c74   1/1     Running   0          9m50s
pod/kube-apiserver-unicron-master                               1/1     Running   0          8h
pod/kube-controller-manager-unicron-master                      1/1     Running   0          8h
pod/kube-proxy-6tjzz                                            1/1     Running   2          184d
pod/kube-proxy-7bjb9                                            1/1     Running   2          184d
pod/kube-proxy-dzc5j                                            1/1     Running   2          184d
pod/kube-proxy-j65jd                                            1/1     Running   2          184d
pod/kube-scheduler-unicron-master                               1/1     Running   0          8h
pod/kubernetes-dashboard-56bcddb89b-js6jk                       1/1     Running   2          184d
pod/tiller-deploy-64dddb8f95-6dzzg                              1/1     Running   0          20m
pod/weave-net-6dk6r                                             2/2     Running   6          184d
pod/weave-net-d4vpq                                             2/2     Running   6          184d
pod/weave-net-kwm5b                                             2/2     Running   6          184d
pod/weave-net-lr8sr                                             2/2     Running   6          184d


NAME                           TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)         AGE
service/kube-dns               ClusterIP   10.96.0.10     <none>        53/UDP,53/TCP   184d
service/kubernetes-dashboard   ClusterIP   10.97.20.62    <none>        443/TCP         184d
service/tiller-deploy          ClusterIP   10.100.51.54   <none>        44134/TCP       26m

NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/kube-proxy   4         4         0       4            0           <none>          184d
daemonset.apps/weave-net    4         4         0       4            0           <none>          184d

NAME                                                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/coredns                                    0/2     2            0           184d
deployment.apps/hissing-sasquatch-nfs-client-provisioner   1/1     1            1           9m51s
deployment.apps/kubernetes-dashboard                       0/1     1            0           184d
deployment.apps/tiller-deploy                              1/1     1            1           26m

NAME                                                                  DESIRED   CURRENT   READY   AGE
replicaset.apps/coredns-86c58d9df4                                    2         2         0       184d
replicaset.apps/hissing-sasquatch-nfs-client-provisioner-764687f76d   1         1         1       9m51s
replicaset.apps/kubernetes-dashboard-56bcddb89b                       1         1         0       184d
replicaset.apps/tiller-deploy-64dddb8f95                              1         1         1       20m
replicaset.apps/tiller-deploy-7557459999                              0         0         0       26m




user@hephaestus:~/development/projects/docker/kubernetes$ kubectl get nodes
NAME              STATUS   ROLES    AGE    VERSION
unicron-master    Ready    master   184d   v1.15.3
unicron-worker1   Ready    <none>   184d   v1.15.3
unicron-worker2   Ready    <none>   184d   v1.15.3
unicron-worker3   Ready    <none>   184d   v1.15.3

Dat is dan wel weer leuk, een cluster van 4 Rpi's met een ZFS NFS mount van de Linux NAS af. Yay pielen!

Nice
Er zitten zeker veel moving parts in, maar wat jij zegt is niet benodigd voor k8s zelf natuurlijk Dat zijn je eigen "wensen" die je er in wilt hebben.
Bijkomend voordeel van het draaien van k8s in de cloud is dat je dan bijv. loadbalancers hebt die integreren (dus geen metallb) en uiteraard je storage. Ik heb het zelf ook wel op baremetal opgezet, wat zeer zeker vele "moeilijkheden" met zich mee neemt.

ps. als je heel verslaafd word kan ik je https://www.meetup.com/Kubernetes-Addicts-Support-Group/ ook nog aanraden

[Hydra]

dovo schreef op donderdag 12 september 2019 @ 20:57:
Leuk om deze topic te lezen. Ik dacht dat ik de enige was die niet geobsedeerd is van Dockerize everything en dat Docker vreselijke en obsolete software architecturen maar zal oplossen.

Er zijn geen technische oplossingen voor problemen die vooral veroorzaakt worden door mensen. Een hoop mensen, developers incluus, denken dat een hoop termen weten te smijten hetzelfde is als shit echt snappen.

Je hele verhaal komt neer op slechte developers die geen ene fuck van software bouwen snappen. Ze kunnen programmeren ja, maar software engineering of architectuur snappen ze geen hout van. Shit aan elkaar duct-tapen is geen software engineering. En helaas heb ik, cynisch als ik ben, dat er door de oververhitte markt meer en meer van dit soort developers bijkomen terwijl de mensen die het echt snappen steeds schaarser worden.

Software wordt complexer en de developers die het bouwen worden steed dommer.

En nu van m'n grasveld af!

[Tjolk]

Hmm... Denk ga eens PHP storm proberen. Heeft alleen geen fatsoenlijke CodeIgniter support.

Nu kun je een hele (korte) discussie houden over CodeIgniter en 2019, maar de realiteit is dat ik wel het gros van mijn werk daarin moet doen.

So long, PHP Storm

[RobertMe]

Tjolk schreef op maandag 16 september 2019 @ 15:28:
Hmm... Denk ga eens PHP storm proberen. Heeft alleen geen fatsoenlijke CodeIgniter support.

Nu kun je een hele (korte) discussie houden over CodeIgniter en 2019, maar de realiteit is dat ik wel het gros van mijn werk daarin moet doen.

So long, PHP Storm

Wat is fatsoenlijk?

PHPStorm heeft ook geen support voor het in 2019 meer geaccepteerde Symfony, maar daarvoor is wel een plugin, hetzelfde als dat er een plugin is voor CodeIgniter. Overigens heb ik deze nu gegoogled en dus geen ervaring mee, het kan best dat de plugin ook niet goed is.

[Mugwump]

RobertMe schreef op maandag 16 september 2019 @ 15:37:
[...]

Wat is fatsoenlijk?

PHPStorm heeft ook geen support voor het in 2019 meer geaccepteerde Symfony, maar daarvoor is wel een plugin, hetzelfde als dat er een plugin is voor CodeIgniter. Overigens heb ik deze nu gegoogled en dus geen ervaring mee, het kan best dat de plugin ook niet goed is.

De 1-ster review die ik zie belooft niet veel goeds.

[Tjolk]

Ja, die doet dus maar een paar dingen en mist simpelweg references naar models en libraries.

Bijv:

PHP:

$this->load->model('User_model');
$this->User_model->userGet($id);

In bijvoorbeeld Netbeans en Visual Studio Code kun je dan Ctrl+klik doen naar de userGet method, maar in PHP Storm niet (ook niet met die plugin). Zulks werkt alleen als ik boven iedere class handmatig alle gebruikte classes definieer met @property. En daar ben ik botweg te lui voor omdat ik dat nu ook niet hoef.

Nu ben ik ook niet meer helemaal happy met Netbeans, dus ik ben gewoon even aan het rondkijken. Netbeans 8.2 komt niet verder dan PHP 7.0 wat op zich niet heel erg is, maar net ff onhandig. Apache Netbeans is erg sloom op Ubuntu merk ik. Visual Studio Code is een leuk alternatief tot nu toe, maar ben ik nog niet helemaal van overtuigd (al heb ik daar geen specifieke andere reden voor dan dat het anders is dan wat ik gewend ben )

[Voutloos]

Het gegeven voorbeeld moet je met een uurtje wel geregeld hebben via een .meta file, dus plugin auteur is blijkbaar een prutser.

Maar eh, CodeIgniter en 2019?

[Sandor_Clegane]

Douweegbertje schreef op maandag 16 september 2019 @ 10:20:
[...]


Nice
Er zitten zeker veel moving parts in, maar wat jij zegt is niet benodigd voor k8s zelf natuurlijk Dat zijn je eigen "wensen" die je er in wilt hebben.
Bijkomend voordeel van het draaien van k8s in de cloud is dat je dan bijv. loadbalancers hebt die integreren (dus geen metallb) en uiteraard je storage. Ik heb het zelf ook wel op baremetal opgezet, wat zeer zeker vele "moeilijkheden" met zich mee neemt.

ps. als je heel verslaafd word kan ik je https://www.meetup.com/Kubernetes-Addicts-Support-Group/ ook nog aanraden

Het is niet echt moeilijk, het is gewoon veel. Eerst het cluster, dan nog alles uitvogelen ( namespaces, overlay networks etc. etc. ) en het dan ook nog eens goed aan de praat krijgen met alle logs en dergelijke.

Nu met de .Net er eens tegenaan babbelen. Thanks voor de tip!

Edit: Kubernetes schrijft veel, eerst maar eens mijn cluster van TFTP laten booten denk ik. Daar gaan we weer.

[ Voor 5% gewijzigd door Sandor_Clegane op 16-09-2019 18:47 ]

[Sebazzz]

plofkip schreef op vrijdag 13 september 2019 @ 14:38:

C#:

public string action { get; set; } // Small letter because of naming conflicts

C#:

public string action { get; set; } // Small letter because of naming conflicts

[...]

public Action Action { get; set; } // bound by primary key 'action'

[Douweegbertje]

armageddon_2k1 schreef op vrijdag 13 september 2019 @ 07:56:
Maar echt niemand forceert je toch om je WP site in Docker te hangen? Heeft dat gesprek überhaupt plaatsgevonden?

Ik wil het hier trouwens wel over hebben

Ooit mijn eigen site eens op k8s gezet, niet omdat ik nou fan ben van WP maar om het eens te testen wat de mogelijkheden zijn. WP is dan eigenlijk vrij klote omdat het totaal niet cloudnative of iets dergelijks is. Ik gebruik nu misschien een buzzwordje maar wat ik bedoel te zeggen is dat de "internals" van WP gewoon wank zijn.

Desalniettemin is dat wel deels te fixen! Het eindresultaat is ook best tof.
Zo build ik dus automatisch images van mijn website en gebruik ik geen mounts maar een s3 bucket. De database is dan wel gewoon.. een database.
Eigenlijk gedraagt de website zich non-persistent. Alle changes in prod zijn weg bij een restart van de container. M.a.w. updates doe ik lokaal c.q. via de pipeline. Vervolgens nog varnish er voor en je hebt een leuke setup.

Het klinkt misschien vrij simpel maar het was toch even wat werk om het zo te krijgen.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[gekkie]

Douweegbertje schreef op maandag 16 september 2019 @ 22:16:
[...]
Desalniettemin is dat wel deels te fixen! Het eindresultaat is ook best tof.

Maar schiet je er ook iets mee op .. buiten dat het "tof" is.

Zo build ik dus automatisch images van mijn website en gebruik ik geen mounts maar een s3 bucket. De database is dan wel gewoon.. een database.
Eigenlijk gedraagt de website zich non-persistent. Alle changes in prod zijn weg bij een restart van de container. M.a.w. updates doe ik lokaal c.q. via de pipeline. Vervolgens nog varnish er voor en je hebt een leuke setup.

Errrhm welke wijzigingen in productie zijn dan op eens foetsie en waarom zou je dat willen ?

En als het alleen je files on disk(/s3 meuk) zijn en niet je DB, wat gebeurd er bij creatieve schema changes van creatieve plugins die graag lekker direct database peek'n en poke'n (wat een volkssport lijkt te zijn onder WP plugins bakkers) met uiterst creatieve update scripts .. na een update'tje her en der ?

[Alex)]

gekkie schreef op maandag 16 september 2019 @ 23:12:
[...]

Errrhm welke wijzigingen in productie zijn dan op eens foetsie en waarom zou je dat willen ?

Dat zijn natuurlijk al die aangepaste PHP-files wanneer er weer eens een securitylek in Wordpress of één van de vele plugins is misbruikt.

Nuke & Pave is sneller dan Cleanup & Update

[ThomasG]

De grote vraag is natuurlijk waarom er überhaupt changes zijn in de productie omgeving; ik neem aan dat je het dan niet hebt over data.

[Mugwump]

ThomasG schreef op dinsdag 17 september 2019 @ 10:13:
De grote vraag is natuurlijk waarom er überhaupt changes zijn in de productie omgeving; ik neem aan dat je het dan niet hebt over data.

Het zou me niets verbazen als source files FTP'en nog best een gebruikelijke deploymentstrategie is in de PHP-wereld.

[P-Storm]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[CurlyMo]

@P-Storm Het blijft de klassieke regel. Hoe hoger de beveiliging hoe makkelijker mensen het voor zichzelf proberen te maken om het werkbaar te houden. De laatste paar jaar zijn er zat van die incidenten bij bijv. de politie in het nieuws geweest. Of onlangs nog de patiënteninformatie op een boodschappen briefje.

[P-Storm]

@CurlyMo Dat klopt inderdaad. Vaak hoor ik dat het snel af moet zijn, wat tijd is geld en de klus moest eigenlijk eergisteren al gedaan worden in 2x zo weinig tijd. Dat helpt ook niet met security.

Soms heb je ook te maken met incompetentie, dus ik kan mij prima aansluiten bij Hydra zijn redenatie.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Douweegbertje]

gekkie schreef op maandag 16 september 2019 @ 23:12:
[...]

Maar schiet je er ook iets mee op .. buiten dat het "tof" is.


[...]

Errrhm welke wijzigingen in productie zijn dan op eens foetsie en waarom zou je dat willen ?

En als het alleen je files on disk(/s3 meuk) zijn en niet je DB, wat gebeurd er bij creatieve schema changes van creatieve plugins die graag lekker direct database peek'n en poke'n (wat een volkssport lijkt te zijn onder WP plugins bakkers) met uiterst creatieve update scripts .. na een update'tje her en der ?

Ik wil dat omdat dat nou juist het nut is van een image. Dat is eigenlijk mijn 'state'. Dat is het "nadeel" van WP dat je bijv. plugins kan installeren via de backend. Nja dat soort dingen gebeuren dus niet.

Ik schiet er wel degelijk iets mee op. Ik heb dus mooie omgevingen die identiek aan elkaar zijn. Updates zijn mooi te testen en easy door te voeren. Bij eventuele security issues gooi ik mijn container weg en heb ik weer een schone WP.

Het gemak zit hem uiteindelijk meer in het dev process en CI/CD. Ik zou zelf niet meer op een andere manier met WP willen werken. Niet dat ik daar nou echt veel mee/ga werken

De exacte reden om dit te doen is om een soort poke te maken richting WP m.b.t. hun official docker images die mounts benodigd hebben en dus echt anti-container zijn (imo). Naast de shitload aan guides die allemaal docker misbruiken voor WP. Ik doe het dus andersom en doe alles qua containers "goed", en pas WP waar benodigd aan om het wel meer cloud native te maken.

[mcDavid]

P-Storm schreef op dinsdag 17 september 2019 @ 11:11:

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Wie zegt dat ze die wachtwoorden überhaupt opslaan? Nergens voor nodig als je ze on-the-fly kunt berekenen toch, kunnen ze nooit uitlekken

[gekkie]

Douweegbertje schreef op dinsdag 17 september 2019 @ 12:17:
[...]
Ik wil dat omdat dat nou juist het nut is van een image. Dat is eigenlijk mijn 'state'. Dat is het "nadeel" van WP dat je bijv. plugins kan installeren via de backend. Nja dat soort dingen gebeuren dus niet.

Ik schiet er wel degelijk iets mee op. Ik heb dus mooie omgevingen die identiek aan elkaar zijn. Updates zijn mooi te testen en easy door te voeren. Bij eventuele security issues gooi ik mijn container weg en heb ik weer een schone WP.

Het gemak zit hem uiteindelijk meer in het dev process en CI/CD. Ik zou zelf niet meer op een andere manier met WP willen werken. Niet dat ik daar nou echt veel mee/ga werken

De exacte reden om dit te doen is om een soort poke te maken richting WP m.b.t. hun official docker images die mounts benodigd hebben en dus echt anti-container zijn (imo). Naast de shitload aan guides die allemaal docker misbruiken voor WP. Ik doe het dus andersom en doe alles qua containers "goed", en pas WP waar benodigd aan om het wel meer cloud native te maken.

Neem aan dat je de content dus ook niet "live" in productie aanpast en je dus een dynamische statische site publisht (of statisch dynamisch .. whatever you like) ?

Wordpress is dus je offline editor en online renderer ?

[Hydra]

Douweegbertje schreef op dinsdag 17 september 2019 @ 12:17:
De exacte reden om dit te doen is om een soort poke te maken richting WP m.b.t. hun official docker images die mounts benodigd hebben en dus echt anti-container zijn (imo). Naast de shitload aan guides die allemaal docker misbruiken voor WP. Ik doe het dus andersom en doe alles qua containers "goed", en pas WP waar benodigd aan om het wel meer cloud native te maken.

'De' standaard PHP docker tutorial; je proces via docker starten en dan nog steeds je PHP files naar de running docker volume mount FTPen. Ik weet niet wat het met PHPers is maar het is bizar hoeveel mensen nog in die werkwijze uit '98 zijn blijven hangen.

Je zit volledig op de juiste weg door images als immutable 'dingen' te zien. Als wij een vorige versie van een service willen deployen zetten we ook geen .jar over naar een draaiende docker image; we deployen gewoon een vorige geversionede image.

gekkie schreef op dinsdag 17 september 2019 @ 12:43:
Wordpress is dus je offline editor en online renderer ?

De 'content' zal wel in een database opgeslagen worden, maar ik vermoed dat het probleem met veel CMSen is dat de 'content', dus de data, nogal sterk gekoppeld is aan de layout.

[ Voor 15% gewijzigd door Hydra op 17-09-2019 13:29 ]

[gekkie]

Hydra schreef op dinsdag 17 september 2019 @ 13:28:
[...]
De 'content' zal wel in een database opgeslagen worden, maar ik vermoed dat het probleem met veel CMSen is dat de 'content', dus de data, nogal sterk gekoppeld is aan de layout.

En potentieel afhankelijk van je plugins .. aan plugins en allerlei custom database tabellen waarin dus schema changes zitten. Dus ik neem aan dat het een soort offline(/intranet) editor is en dus in productie puur een renderer waarbij alles gedeployed wordt (wp install + plugins, en volledige bijpassende DB data).

Heb al aardig wat WP installs kapot zien gaan door lui die van backups alleen de files terug plaatsen en niet de bij behorende DB, daar op door gewerkt, tot er van allerlei errors kwamen door plugins die het niet meer snapten omdat er een schema-change van plugins niet terug gerold was.

[Hydra]

@gekkie zo blij dat ik niet in dat wereldje zit...

[Janoz]

Plugin installatie is onderdeel van het builden van je image. Vervolgens kun je keurig je image testen in een test of staging omgeving. Werkt het, kan ie door, werkt het niet dan flikker je het image weg. In de 'grote mensen wereld' heb je vervolgens ook versioning op de database met bv liquibase.

[gekkie]

Hydra schreef op dinsdag 17 september 2019 @ 14:13:
@gekkie zo blij dat ik niet in dat wereldje zit...

Maar goed komt er eigenlijk wederom op neer dat er een hoop mensen zijn die er de ballen van snappen en vervolgens bij hun shared hosting maar wat aanrommelen en de link tussen WP en plugins versies en DB schema niet snappen. Sterker nog, "wat is een DB voor een beest ?". Maar ondertussen wel in die shared hosting dus zelf de helft van backups terug zetten. En er vervolgens ook totaal geen belangstelling voor hebben. Achja dan is de oplossing ook simpel: "Opnieuw beginnen want je hebt de meuk grondig verneukt."

[Douweegbertje]

Een belangrijk onderdeel is dus niet ad hoc random plugins erin te gooien.
Ik kies bewust voor plugins waarvan ik weet dat ze okay zijn. Dat houd ook zeker in dat je sommige niet kan (en wilt) gebruiken omdat ze random/ad hoc scripts, files en dirs maken/gebruiken.

https://sysrant.com/cloud-native-wordpress/

Dit was mijn blogpost. Eigenlijk had ik er nog een vervolg met betere code e.d. van willen maken.. Maar andere prio's

[gekkie]

Zitten die golang types de hele dag aan de LSD .. wie heeft die dateformat ongein verzonnen een specifieke datum als voorbeeld gebruiken, maar dan alleen die specifieke datum, zal wel de geboorte van het gedrocht zijn ofzo. Geen idee of ik weer een mea culpa moet maken omdat het al in de golang-sucks documentatie staat, maar ik heb nu echt koolstof-nano-tube-bretels nodig om te zorgen dat m'n broek niet afzakt.

[Solaire]

gekkie schreef op dinsdag 17 september 2019 @ 16:04:
Zitten die golang types de hele dag aan de LSD .. wie heeft die dateformat ongein verzonnen een specifieke datum als voorbeeld gebruiken, maar dan alleen die specifieke datum, zal wel de geboorte van het gedrocht zijn ofzo. Geen idee of ik weer een mea culpa moet maken omdat het al in de golang-sucks documentatie staat, maar ik heb nu echt koolstof-nano-tube-bretels nodig om te zorgen dat m'n broek niet afzakt.

Het is gewoon 1/2/3/4/5/6. 1 is de maand, 2 is de dag, 3 is het uur, 4 de minuut, 5 de seconde en 6 het jaartal.

Het is wennen... maar dat is met elke taal. Vind Golang best goed gedocumenteerd eigenlijk, kort en straight to the point. Maar je moet het wel leren lezen en schrijven.

[dev10]

CurlyMo schreef op dinsdag 17 september 2019 @ 11:27:
@P-Storm Het blijft de klassieke regel. Hoe hoger de beveiliging hoe makkelijker mensen het voor zichzelf proberen te maken om het werkbaar te houden.

En zie hier, dit is precies de oorzaak van de hack bij Diginotar. Een kabeltje dat aangelegd is, zodat medewerkers niet steeds de 'koude kluis' in hoefden om een certificaat uit te geven. (Klein beetje kort samengevat, maar dat was wel de strekking)

[gekkie]

Solaire schreef op dinsdag 17 september 2019 @ 16:16:
[...]
Het is wennen... maar dat is met elke taal. Vind Golang best goed gedocumenteerd eigenlijk, kort en straight to the point. Maar je moet het wel leren lezen en schrijven.

Mjah dat geldt voor PHP ook.

En net maar eens begonnen in wat literatuur over Rust, maar ook dat heeft wel weer een aantal nieuwe creativiteiten aan shortcuts die ik nog niet ergens anders tegen gekomen ben.

[Voutloos]

Solaire schreef op dinsdag 17 september 2019 @ 16:16:
[...]
Het is gewoon 1/2/3/4/5/6. 1 is de maand, 2 is de dag, 3 is het uur, 4 de minuut, 5 de seconde en 6 het jaartal.

IIk wist bijna zeker dat dit een grap was. Toch maar gezocht en ... WTF.

Áls het al een idee is, probeer dan nog tenminste iets van een ISO 8601 volgorde te gebruiken.

quote: random bron

(This date is easier to remember when written as 01/02 03:04:05PM ‘06 -0700.)

Ah, de gemakkelijk te onthouden locale-afhankelijke presentatie.

Sluit [alg] Slechtste programmeervoorbeelden deel 5 maar, vergeet alle grappen over PHP maar, dit overtreffen we niet meer.

[Boudewijn]

CurlyMo schreef op dinsdag 17 september 2019 @ 11:27:
@P-Storm Het blijft de klassieke regel. Hoe hoger de beveiliging hoe makkelijker mensen het voor zichzelf proberen te maken om het werkbaar te houden. De laatste paar jaar zijn er zat van die incidenten bij bijv. de politie in het nieuws geweest. Of onlangs nog de patiënteninformatie op een boodschappen briefje.

Ja behalve dat dit voorbeeld, en het boodschappenlijstje-op-patientdossier-verhaal niets te maeken hebben met 'hoge beveiliging'
Dit is gewoon clusterfucking voor prutsers 0.9 beta.

[ Voor 4% gewijzigd door Boudewijn op 17-09-2019 17:05 ]

[Hydra]

Boudewijn schreef op dinsdag 17 september 2019 @ 17:05:
Dit is gewoon clusterfucking voor prutsers 0.9 beta.

De grootste eye opener van volwassen worden is dat de meeste van die volwassen ook maar gewoon wat aankutten en over 't algemeen geen idee hebben van wat ze nou precies doen.

[Mugwump]

Hydra schreef op dinsdag 17 september 2019 @ 17:37:
[...]


De grootste eye opener van volwassen worden is dat de meeste van die volwassen ook maar gewoon wat aankutten en over 't algemeen geen idee hebben van wat ze nou precies doen.

Ik schrik er inderdaad ook altijd weer van hoeveel mensen dingen doen zonder te begrijpen wat ze nou eigenlijk aan het doen zijn. Heb ook wat collega's die vaak naar me toe komen met de vraag "het werkt niet, weet jij waarom?". Dan ben ik eerst vijf minuten met ze bezig om te kijken wat er dan niet werkt, wat ze hebben gedaan en hoe ze daartoe zijn gekomen. Meestal blijkt dat er wat zaken bij elkaar geknipt en geplakt zijn in de hoop dat dat zou werken, maar men neemt niet de moeite om het echt te begrijpen, waardoor het oplossen van problemen ook maar willekeurige trial en error blijft.
Hoe je zo kunt werken ontgaat mij persoonlijk.

[armageddon_2k1]

Wij bieden bij ons pakket SSO aan, middels OAuth2 (+ evt OpenID Connect erbovenop), en veel van onze klanten willen het. Maar het aantal IT afdelingen dat daarop ingericht is..... 3% wellicht? De meesten hebben ab-so-luut geen enkel idee. Je krijgt dan vragen als:
- Maar dan kunnen jullie dus gewoon al onze gebruikers-wachtwoorden aftappen? Nee
- Ik stuur je een lijstje met gebruikersnamen en ww's toe okee? NEE!
- Houden jullie rekening met Varnish in onze Auth? ...wat?...
- Dit is allemaal ingewikkeld, misschien kan iemand van jullie even kijken hoe het in onze Azure AD ingesteld moet worden. Hier is m'n username en password, kan je zelf instellen. Oh my...
- Ja, we ondersteunen OAuth2.0 hoor, geen probleem. Hier is ons SAML endpoint..
- Ik stel voor dat we jullie IT-manager betrekken bij ons maandelijks cybersecurity overleg, daar jullie nu bij al onze gegevens kunnen.
- Heel fijn dat SSO, maar kunnen jullie niet alleen voor mij instellen dat ik dat niet hoef, want het kost me teveel moeite om elke keer m'n wachtwoord in te vullen. Ik had zelf bedacht dat jullie vast wel in kunnen programmeren als je mijn email-adres invult dat ie dan gewoon automatisch naar onze projecten gaat?
- We kregen allemaal requests binnen van jullie server, dus we hebben jullie geblacklist. Ja we weten ook niet waarom de software niet meer werkt.

En dat zijn dan de IT'ers. Het ergste zijn de managers die zich ermee gaan bemoeien en dan belangrijk gaan doen om het belangrijk zijn met dingen als:
- Kunnen we een stappenplan op gaan stellen met SMART punten voor het integratie-traject van AutO?
- En hoe is de privacy geregeld? Wat sowieso een mega-open vraag is.... hoe antwoord je daar nou op.

Een hele grote klant van ons, een zeer grote NL partij, heeft Azure als backend. Ze zijn nu al 3,5e maand bezig om 1 docker container werkend te krijgen omdat ze het zo nodig 'on-premise' wilde hebben.

Iedereen prutst maar wat aan....
Het niveau vind ik soms om te huilen en dan schat ik mezelf ook niet in als een coding rockstar.

EDIT:
Over de Go discussie. Spuiten die gasten crack? Waarom nou weer een hele nieuwe manier van datetime gaan verzinnen als het een van de allerlastigste dingen is om goed te doen en er miljoenen FTE's aan voorafgegaan zijn in andere talen. De basis bouwen is vast prima, maar het gezeik zit hem in de edge-cases. En jawel hoor:

Here are some corner cases not handled by the time package.

It's not possible to specify that an hour should be rendered without a leading zero in a 24-hour time format.

It's not possible to specify midnight as 24:00 instead of 00:00. A typical usage for this would be giving opening hours ending at midnight, such as 07:00-24:00.

It's not possible to specify a time containing a leap second: 23:59:60. In fact, the library assumes a Gregorian calendar with no leap seconds.

Nee, leap seconds zijn absoluut niet belangrijk. Helemaal niet bij zo'n ultra-globaal bedrijf als Google en een taal die prat gaat op "High-performance networking and multiprocessing". Dat je Python scriptje dat niet doet, okee, maar een taal waar ze mega-concurrent web-shizzle willen doen....

De afgelopen jaren zijn er elke keer weer problemen doordat er geen rekening gehouden wordt met die shit.

30 juni 2020 (next leap second) wordt leuk.

[ Voor 34% gewijzigd door armageddon_2k1 op 17-09-2019 19:37 ]

[Sandor_Clegane]

Yay, het hele cluster boot nu via PXE... Het was wat werk maar dan heb je ook wat.

Linux is ook echt wel tof, zo flexibel als wat. Mits je de juiste documentatie hebt iig.

Mooiste is, snapshot nu gewoon de gehele RPI via de NAS, ZFS is ook geweldig.

Nu Kubernetes erop.....

[Gropah]

armageddon_2k1 schreef op dinsdag 17 september 2019 @ 19:27:
Wij bieden bij ons pakket SSO aan, middels OAuth2 (+ evt OpenID Connect erbovenop), en veel van onze klanten willen het. Maar het aantal IT afdelingen dat daarop ingericht is..... 3% wellicht? De meesten hebben ab-so-luut geen enkel idee.
[...]

Oeh interessant. Ik zit nu voor mijn werk ook te kijken naar hoeveel moeite het zou zijn om een authentication en authorization systeem op te zetten mbv OAuth en OpenID Connect, maar ik vind het moeilijk om er een goede tutorial, intro of technische implementatie omschrijving voor te vinden. Heb je nog iets liggen om mensen er aan te helpen?

[Mugwump]

Het is overigens ook wel weer wat overdreven om te stellen dat echt helemaal niemand weet wat ie doet. Ik zit nu op een project met een team waarin echt iedereen behoorlijk goed weet wat ie doet.
Dat maakt je werk ook gelijk tien keer leuker in mijn ogen. Niet meer codereviews waarbij de tranen je in je ogen schieten, een infra- / beheerafdeling die je alles moet uitleggen en voorkauwen en ga zo maar door. Gewoon lekker en team waarin iedereen meedenkt, zijn eigen vak snapt en ook nog wel redelijk wat van dat van een ander en men elkaar dus prima aanvult / versterkt. Wou dat al mijn projecten zo waren.

[Giesber]

armageddon_2k1 schreef op dinsdag 17 september 2019 @ 19:27:
Wij bieden bij ons pakket SSO aan, middels OAuth2 (+ evt OpenID Connect erbovenop), en veel van onze klanten willen het. Maar het aantal IT afdelingen dat daarop ingericht is..... 3% wellicht? De meesten hebben ab-so-luut geen enkel idee. Je krijgt dan vragen als:
...

Klinkt interessant, dat hebben wij ook nodig!

Werkt die Oaud2 ook op Linux?

[BladeSlayer1000]

P-Storm schreef op dinsdag 17 september 2019 @ 11:11:

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 7% gewijzigd door BladeSlayer1000 op 17-09-2019 23:09 ]

[Matis]

Bij mijn vorige werkgever hadden ze een tijdsregistratiesysteem waarbij het standaardwachwoord bij iedereen 0 was. Dit zonder de verplichting om het bij de eerste keer inloggen te wijzigen.

We konden praktisch bij iedereen inloggen, ook de directe en de IT afdeling

[DeluxZ]

Gropah schreef op dinsdag 17 september 2019 @ 21:28:
[...]


Oeh interessant. Ik zit nu voor mijn werk ook te kijken naar hoeveel moeite het zou zijn om een authentication en authorization systeem op te zetten mbv OAuth en OpenID Connect, maar ik vind het moeilijk om er een goede tutorial, intro of technische implementatie omschrijving voor te vinden. Heb je nog iets liggen om mensen er aan te helpen?

In .NET toevallig? Kijk dan eens naar IdentityServer

[Gropah]

DeluxZ schreef op woensdag 18 september 2019 @ 08:24:
[...]


In .NET toevallig? Kijk dan eens naar IdentityServer

Liever in Go of Python, maar als het als microservice te draaien is, is C# wellicht geen probleem. Ik zal eens in IdentityServer duiken.

[DeluxZ]

Gropah schreef op woensdag 18 september 2019 @ 08:53:
[...]


Liever in Go of Python, maar als het als microservice te draaien is, is C# wellicht geen probleem. Ik zal eens in IdentityServer duiken.

Go wordt toch alleen gebruikt door crack junkies heb ik gelezen ?

[Gropah]

DeluxZ schreef op woensdag 18 september 2019 @ 08:54:
[...]


Go wordt toch alleen gebruikt door crack junkies heb ik gelezen ?

well, slap my butt and call me a junkie, want ik gebruik het (met plezier) voor mijn werk.

[Hydra]

Mugwump schreef op dinsdag 17 september 2019 @ 18:06:
Hoe je zo kunt werken ontgaat mij persoonlijk.

Beetje 'hard' maar het 'hoe' is vooral dat dat soort mensen overal alsnog aangenomen worden. Alsof we fabrieksarbeiders zijn en slechte developers alsnog een positieve bijdrage leveren.

[ElkeBxl]

Hydra schreef op dinsdag 17 september 2019 @ 17:37:
[...]


De grootste eye opener van volwassen worden is dat de meeste van die volwassen ook maar gewoon wat aankutten en over 't algemeen geen idee hebben van wat ze nou precies doen.

"Volwassen zijn gewoon kinderen met verantwoordelijkheden" zei iemand ooit tegen mij. Is me altijd bijgebleven en is helaas zo waar.

[Matis]

Hydra schreef op woensdag 18 september 2019 @ 08:56:
Beetje 'hard' maar het 'hoe' is vooral dat dat soort mensen overal alsnog aangenomen worden. Alsof we fabrieksarbeiders zijn en slechte developers alsnog een positieve bijdrage leveren.

Tel daarbij de schaarste op de arbeidsmarkt bij op et voila. Iedere scriptkiddie of schoolverlater wordt tegenwoordig als senior software architect fullstack cyber security expert blockchain developer aangeprezen door diverse recruiters. Vreselijk.

Bij ons op de zaak zijn we er ooit ook in getrapt. Een ervaren Symfony (PHP backend) ontwikkelaar, paste precies binnen ons plaatje. Puntje bij paaltje: Die jongen wist niet eens wat Symfony was en kende geen OO methodieken.

Hij had, naar eigen zeggen, wel eens een websiteje (is dat een woord ) gebouw

[Marc3l]

Hydra schreef op dinsdag 17 september 2019 @ 17:37:
[...]


De grootste eye opener van volwassen worden is dat de meeste van die volwassen ook maar gewoon wat aankutten en over 't algemeen geen idee hebben van wat ze nou precies doen.

Is dat niet algemeen het idee van het leven?
Niemand wat toch wat we hier echt doen / moeten doen op aarde, eigen rommelt iedereen hier maar wat aan

[CurlyMo]

Matis schreef op woensdag 18 september 2019 @ 09:20:
[...]
Bij ons op de zaak zijn we er ooit ook in getrapt. Een ervaren Symfony (PHP backend) ontwikkelaar, paste precies binnen ons plaatje.

Ik heb ooit een gesprek vroegtijdig afgekapt, omdat iemand in vrijwel alle niveau's wel ervaring had. Dus van machine code tot high-level / front-end taal.

Mijn eerste vraag (na kennismaking) was gelijk de diepte in. Zou je bij alle talen kunnen vertellen wat je er ooit in gedaan hebt. Hoe groot of klein dat ook was. Ik begin gewoon op alfabetische volgende. Assembly Wat heb je daarmee gedaan. Voor de sollicitant was dit veel te lang geleden zei die. Toen vroeg ik of hij kan aangeven waar je (een analyse van) assembly voor zou kunnen gebruiken. Ook dat wist hij niet. Toen ging ik zelf voorbeelden geven. Ik heb ik zelf ook nooit mee gewerkt, maar weet wel waarvoor je het kan gebruiken (bijv. kijken hoe je C code in CPU instructies uitwerkt). Ook dat deed geen belletje rinkelen bij de sollicitant. Toen vroeg ik waarom het dan op zijn CV stond. Dat was er opgezet door een vriend van hem Daarna stelde ik de vraag of het nog zin had om de B van Basic of de C van C langs te gaan, maar al gauw genoeg werd duidelijk dat we het gesprek direct konden stoppen, want meneer had zijn programmeertaal kennis compleet bij elkaar gebluft.

Laten we het er op houden dat ik vaker sollicitanten heb afgewezen, omdat ik, ook in de laatste rondes, twijfelde over de technische kennis en de betreffende sollicitant zich ofwel niet kon verweren tegen mijn kritische vragen ofwel geen blijk gaf van enig meta-analytisch talent.

[Woy]

armageddon_2k1 schreef op dinsdag 17 september 2019 @ 19:27:
Wij bieden bij ons pakket SSO aan, middels OAuth2 (+ evt OpenID Connect erbovenop), en veel van onze klanten willen het. Maar het aantal IT afdelingen dat daarop ingericht is..... 3% wellicht?

Oh, dat klinkt zo herkenbaar. Ik kreeg ook veel de vraag wat het zou kosten om een klant aan te sluiten op onze oplossing met SSO. Antwoord was meestal iets van: "Aan onze kant ongeveer 5 minuten, als de klant weet wat hij doet ook 5 minuten daar, maar dat kan wel uitlopen tot meerdere dagen/weken als de klant niet weet wat hij aan het doen is"

Gropah schreef op dinsdag 17 september 2019 @ 21:28:
[...]
Oeh interessant. Ik zit nu voor mijn werk ook te kijken naar hoeveel moeite het zou zijn om een authentication en authorization systeem op te zetten mbv OAuth en OpenID Connect, maar ik vind het moeilijk om er een goede tutorial, intro of technische implementatie omschrijving voor te vinden. Heb je nog iets liggen om mensen er aan te helpen?

Je moet vooral goed beseffen dat je identity server en je identity client los van elkaar staan. Voor de identity server kun je ook eerst eens beginnen met wat standaards zoals bijvoorbeeld gewoon een gratis instance van Azure AD ( of ongetwijfeld ook iets vergelijkbaars bij Google/Amazon ). Afhankelijk van je uiteindelijke wensen is het vaak wel nodig om zelf iets te hosten zoals met bijvoorbeeld Identity Server (4). Dat dat in .NET haalt niet zoveel uit voor hoe de rest van je application stack er uit ziet.

Op zich is het allemaal niet zo spannend, maar het kan wel even duren voordat je het concept een beetje snapt, zodat je door de bomen het bos weer ziet . Als het kwartje eenmaal gevallen is.

[Hydra]

CurlyMo schreef op woensdag 18 september 2019 @ 09:37:
Dat was er opgezet door een vriend van hem

Bzzzt. Next. Ik kan veel hebben maar je tijdens je interview gewoon gaan liegen is gewoon exit. Als je daar al liegt weet ik zeker dat we als we je aannemen grote problemen gaan krijgen.

Ik vind het echt bizar hoe vaak het voorkomt dat mensen zich in een programmeerjob naar binnen proberen te bluffen. Veel geld + "een beetje achter een computer zitten" zal wel een combinatie zijn die veel mensen aantrekt.

[ Voor 24% gewijzigd door Hydra op 18-09-2019 09:47 ]

[CurlyMo]

Hydra schreef op woensdag 18 september 2019 @ 09:46:
[...]
Bzzzt. Next. Ik kan veel hebben maar je tijdens je interview gewoon gaan liegen is gewoon exit. Als je daar al liegt weet ik zeker dat we als we je aannemen grote problemen gaan krijgen.

Laten we het zo zeggen. Net zo min als ik niet met zekerheid kan zeggen dat God niet bestaat, kon ik ook niet met zekerheid zeggen dat deze persoon via reverse engineering op een internetloze zolderkamer bezig was met programmeren en een vriend na een paar jaar zei: "Wow, heb je jezelf gewoon Assembly aangeleerd zonder enige vorm van documentatie?!?". "Wat is Assembly?" "Dat wat je al die jaren aan het doen was zonder het te beseffen"

Eerlijkheidshalve heb ik zonder te weten dat het al bestond ook precendence walking, topological sort, variant van data-vault modelling uitgevonden. Ik heb alleen niet de illusie dat dat niet vaker voorkomt onder programmeurs.

Ander voorbeeld was een persoon die voor een webdevelopment project meerdere backend talen noemde op zijn CV. Het antwoord op vraag waarom er twee backend talen gebruikt waren was zacht gezegd verwarrend en dat lag niet aan mijn kennisniveau

[ Voor 10% gewijzigd door CurlyMo op 18-09-2019 10:07 ]

[Gropah]

Woy schreef op woensdag 18 september 2019 @ 09:45:

[...]

Je moet vooral goed beseffen dat je identity server en je identity client los van elkaar staan. Voor de identity server kun je ook eerst eens beginnen met wat standaards zoals bijvoorbeeld gewoon een gratis instance van Azure AD ( of ongetwijfeld ook iets vergelijkbaars bij Google/Amazon ). Afhankelijk van je uiteindelijke wensen is het vaak wel nodig om zelf iets te hosten zoals met bijvoorbeeld Identity Server (4). Dat dat in .NET haalt niet zoveel uit voor hoe de rest van je application stack er uit ziet.

Op zich is het allemaal niet zo spannend, maar het kan wel even duren voordat je het concept een beetje snapt, zodat je door de bomen het bos weer ziet . Als het kwartje eenmaal gevallen is.

Opzich wel een goede. Het "probleem" is dat we met veel verschillende bedrijven koppelen. Op dit moment krijgen ze dan nieuwe login credentials bij ons, maar als ze een eigen inlogsysteem hebben dan willen wij eigenlijk op den duur makkelijk daarmee koppelen. Ook omdat we juist proberen om het allemaal zo toegankelijk en veilig mogelijk te maken. Maar het is altijd een goede om eerst meer conceptueel bezig te zijn en snappen wat het allemaal kan, oplost en juist niet kan.

[Hydra]

Gropah schreef op dinsdag 17 september 2019 @ 21:28:
Oeh interessant. Ik zit nu voor mijn werk ook te kijken naar hoeveel moeite het zou zijn om een authentication en authorization systeem op te zetten mbv OAuth en OpenID Connect, maar ik vind het moeilijk om er een goede tutorial, intro of technische implementatie omschrijving voor te vinden. Heb je nog iets liggen om
mensen er aan te helpen?

Kun je eerst eens uitleggen wat je functioneel wil bereiken? Er wordt veelal naar OAuth gegrepen (of JWT) zonder dat mensen de voors en tegens afzetten voor hun use-case.

[GrooV]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Verwijderd]

Nu het toch gaat over cv's en (eerlijk) weergeven wat je kennis is: ik heb ooit ergens een checklist gezien waarmee je op een score / niveauindicatie kwam. Iets als 'gebruikt libraries', 'schrijft libraries' etc. Soort taxonomie voor developement skills. Iemand enig idee? Ik vind hem niet meer...

(Ga vanmiddag CV bijwerken )

[CurlyMo]

Verwijderd schreef op woensdag 18 september 2019 @ 10:19:
'gebruikt libraries', 'schrijft libraries'

"Gaat naar een library". Verder dan dat besef van een library komen sommigen al niet.

[Verwijderd]

CurlyMo schreef op woensdag 18 september 2019 @ 10:30:
[...]"Gaat naar een library". Verder dan dat besef van een library komen sommigen al niet.

"Snuffelt door diverse libraries op zoek naar inspiratie en, in geval van library-selectie 'code smells'" komt dan vast niet geloofwaardig over

[Gropah]

Hydra schreef op woensdag 18 september 2019 @ 10:14:
[...]


Kun je eerst eens uitleggen wat je functioneel wil bereiken?

Ik kijk op dit moment al een stapje verder dan het bedrijf op dit moment precies nodig heeft, maar:

We integreren met verschillende bedrijven.

edit: de integratie is als volgt: Wij hebben een systeem draaien en bepaalde mensen moeten tot bepaalde delen toegang hebben. Om daar bij te komen moeten ze in loggen.

Sommige van die bedrijven zullen zelf een SSO oplossing hebben of een AD of iets in die richting. Daarnaast zullen er ook minder frequente (soms eenmalige) gebruikers zijn, voor wie het misschien handiger, beter of makkelijker is om in te loggen via bijvoorbeeld Google of Facebook.

We kunnen voor alle gebruikers inloggegevens aanmaken en uitgeven, maar ik voorzie nu al dat veel mensen die gaan vergeten, mails niet krijgen, dat soort spul, waar we (in ieder geval ik) liever geen tijd aan kwijt zijn. Daarom zou ik liever uit gaan van de inlog van een 3e partij, zijnde het bedrijf zelf of google/facebook. In mijn beperkte kennis van OpenConnect en OAuth lijkt dat qua protocol te doen wat ik denk dat wij op den duur nodig hebben.

Het zal niet direct op implementatie uitlopen, maar ik wil mij vooral oriënteren zodat het makkelijker is om te bepalen wanneer het moment bereikt is dat we wel moeten overstappen en evt. ook in architectuur keuzes kunnen maken om de overstap makkelijker te maken. Naast dat het natuurlijk ook gewoon erg interessant is.

[ Voor 5% gewijzigd door Gropah op 18-09-2019 10:48 ]

[Mugwump]

Hydra schreef op woensdag 18 september 2019 @ 08:56:
[...]


Beetje 'hard' maar het 'hoe' is vooral dat dat soort mensen overal alsnog aangenomen worden. Alsof we fabrieksarbeiders zijn en slechte developers alsnog een positieve bijdrage leveren.

Ik doel vooral op hoe je op die manier nog plezier / eer uit je werk kunt halen. Ik haal de voldoening totaal niet uit de werkwijze 'klooien totdat het werkt, strik eromheen en niet meer aanzitten'. Ik doe wel vaak een PoCje om iets werkend te krijgen, maar software ontwikkelen is veel meer dan alleen de happy flow voor een beperkte belasting werkend te krijgen. Ik haal de voldoening meer uit een elegant geschreven stuk software dat ook voldoet aan alle nonfunctionals van uitbreidbaarheid tot performance.

En wat de industrie zelf betreft wordt software development helaas binnen veel organisaties ook gewoon gezien als iets waar je een bak 'handjes' tegenaan gooit, terwijl een team van 2-3 goede senior developers die in staat zijn om te werken op basis van businesswensen vele malen effectiever fungeren dan een team van 10 matige developers met de bijbehorende overhead voor de vermeende 'vertaalslag' en hiërarchische structuren die weer moeten worden opgetuigd voor grotere teams. Bovendien is de eerste variant een stuk goedkoper.

Het is ook een belangenkwestie. De leveranciers van 'handjes' hebben vooral als doel om zoveel mogelijk uurtjes te draaien. Dan is efficiënt werken met een klein team juist een stuk minder voordelig, want er zijn veel minder facturabele uren. Ik zie dat bij mijn werkgever ook steeds meer. Bij een klant waar zowel ik als wat collega's die al 20 jaar stilstaan zitten merkt de klant langzamerhand ook wel dat er een duidelijk verschil zit in wat er geleverd wordt. De klant klaagt er echter niet om dus voor m'n werkgever boeit dat totaal niet. Sterker nog, het is een klant die best op de kosten zit, dus als wij zaken te snel leveren, dan is de kans aanzienlijk dat er gekort gaat worden en er dus minder mensen worden weggezet bij die klant.
Wij moeten richting klant uiteraard wel diplomatiek zijn, dus als je de vraag krijgt waarom ontwikkeling op project X traag gaat, dan kan ik moeilijk gaan zeggen dat de mensen die we daarop hebben zitten gewoon echt een stuk minder competent zijn en al 20 jaar categorisch lijken te weigeren om zichzelf te ontwikkelen. Dan gooi je er dus maar weer een lulverhaal over legacy software die heel complex is geworden onder hoge tijds- en kostendruk vanuit de klant. Dat klopt in beperkte mate, maar het ligt gewoon voor 80% aan de mensen die we op zo'n project hebben zitten.

Deze mensen moeten straks over naar ons project (wij herbouwen een aantal legacyprojecten naar een geïntegreerde cloud native oplossing). Bij de klant bestaat de verwachting dat dit betekent dat we dan met twee keer zoveel mensen ook twee keer zoveel gaan leveren, maar ik vrees een beetje dat we met twee keer zoveel mensen juist minder gaan leveren. Ik mag straks de helft van mijn tijd gaan spenderen aan mensen die het heel eng vinden om een Java versie nieuwer dan 6 te gebruiken proberen te laten werken in een omgeving die op alle fronten totaal nieuw voor ze is en daarbij ook nog eens zorgen dat ze de codebase niet verbaggeren met procedurele code bestaande uit methods met 20 geneste try / catch / finally blocks en dergelijk.

[Skyaero]

Hydra schreef op woensdag 18 september 2019 @ 09:46:
[...]
Veel geld + "een beetje achter een computer zitten" zal wel een combinatie zijn die veel mensen aantrekt.

Waar zit het vele geld??

[Alex)]

Wat denk ik niet meehelpt is de focus op 'agile' van de afgelopen jaren, en de hele industrie die eromheen is ontstaan (kijk eens in je LinkedIn-netwerk naar hoeveel 'scrum masters' je ziet).

Steeds meer en meer bedrijven zijn 'agile' gaan werken omdat dat voordelen biedt (en die zijn er echt wel!), ik vraag me gewoon af in hoeveel organisaties de ontwikkelteams ook echt begeleid zijn in wat er nodig is om succesvol agile te kunnen werken. Het zou mij niet verbazen als er veel organisaties zijn waar 'agile werken' vooral een synoniem is voor 'snel releasen', maar waarbij er geen aandacht is voor dingen als CI/CD, testing en het managen van technical debt.

Als je voorheen een ontwikkelteam had met een groot aandeel junior ontwikkelaars, waarbij dat nu junior agile ontwikkelaars zijn, zullen die niet uit zichzelf gaan kijken hoe ze die debt kunnen wegwerken terwijl ze ook nog 'snel moeten releasen' en moeten kunnen reageren op een veranderende wereld and all that.

[Hydra]

Skyaero schreef op woensdag 18 september 2019 @ 12:26:
Waar zit het vele geld??

Software engineering betaalt vrij prima toch? Ben zelf sinds begin dit jaar ZZPer en vind het best 'veel geld'.

Alex) schreef op woensdag 18 september 2019 @ 12:41:
Steeds meer en meer bedrijven zijn 'agile' gaan werken omdat dat voordelen biedt (en die zijn er echt wel!), ik vraag me gewoon af in hoeveel organisaties de ontwikkelteams ook echt begeleid zijn in wat er nodig is om succesvol agile te kunnen werken. Het zou mij niet verbazen als er veel organisaties zijn waar 'agile werken' vooral een synoniem is voor 'snel releasen', maar waarbij er geen aandacht is voor dingen als CI/CD, testing en het managen van technical debt.

Als je voorheen een ontwikkelteam had met een groot aandeel junior ontwikkelaars, waarbij dat nu junior agile ontwikkelaars zijn, zullen die niet uit zichzelf gaan kijken hoe ze die debt kunnen wegwerken terwijl ze ook nog 'snel moeten releasen' en moeten kunnen reageren op een veranderende wereld and all that.

In mijn ervaring zijn het meestal niet de ontwikkelaars die het probleem zijn bij een agile transformation maar meer de rest eromheen. Je hebt dan opeens allemaal project managers die eigenlijk geen rol meer hebben en zich dan maar PO noemen en op ongeveer dezelfde voet doorgaan. Of erger; bedrijven waar agile als extra laagje op een dysfunctioneel systeem wordt gesmeerd: dus nog meer crap en micromanagement in plaats van meer vrijheid.

[ Voor 72% gewijzigd door Hydra op 18-09-2019 12:53 ]

[Mugwump]

Alex) schreef op woensdag 18 september 2019 @ 12:41:
Wat denk ik niet meehelpt is de focus op 'agile' van de afgelopen jaren, en de hele industrie die eromheen is ontstaan (kijk eens in je LinkedIn-netwerk naar hoeveel 'scrum masters' je ziet).

Steeds meer en meer bedrijven zijn 'agile' gaan werken omdat dat voordelen biedt (en die zijn er echt wel!), ik vraag me gewoon af in hoeveel organisaties de ontwikkelteams ook echt begeleid zijn in wat er nodig is om succesvol agile te kunnen werken. Het zou mij niet verbazen als er veel organisaties zijn waar 'agile werken' vooral een synoniem is voor 'snel releasen', maar waarbij er geen aandacht is voor dingen als CI/CD, testing en het managen van technical debt.

Als je voorheen een ontwikkelteam had met een groot aandeel junior ontwikkelaars, waarbij dat nu junior agile ontwikkelaars zijn, zullen die niet uit zichzelf gaan kijken hoe ze die debt kunnen wegwerken terwijl ze ook nog 'snel moeten releasen' en moeten kunnen reageren op een veranderende wereld and all that.

Agile betekent in veel organisaties vooral dat teams enorm flexibel moeten zijn, oftewel stakeholders krijgen ideeën en die moeten dan ad hoc even geïmplementeerd worden. We werken toch immers Agile?

[Hydra]

Mugwump schreef op woensdag 18 september 2019 @ 12:53:
Agile betekent in veel organisaties vooral dat teams enorm flexibel moeten zijn, oftewel stakeholders krijgen ideeën en die moeten dan ad hoc even geïmplementeerd worden. We werken toch immers Agile?

Dat is gelukkig niet mijn ervaring. Het is afhankelijk van de bedrijven waar je werkt natuurlijk, maar over 't algemeen heb je gewoon een sprint en een backlog en wordt er niet tijdens een sprint geschoven.

[ElkeBxl]

Alex) schreef op woensdag 18 september 2019 @ 12:41:
Het zou mij niet verbazen als er veel organisaties zijn waar 'agile werken' vooral een synoniem is voor 'snel releasen', maar waarbij er geen aandacht is voor dingen als CI/CD, testing en het managen van technical debt.

Al paar keer meegemaakt dat ik in een "agile" team terecht kwam maar eigenlijk waren er haast altijd dezelfde problemen:

• Management misbruikte het "agile" zijn om zo snel mogelijk features erdoor te pushen maar weigeren zelf een beetje "agile" te zijn als het op budget/tijd/scope aan komt
• Zaken zoals testing, wegwerken van technical debt, documenteren en dergelijke werden als "niet nuttig" gezien omdat zo'n zaken nu eenmaal tijd in beslag namen. Met de nodige gevolgen...
• Er werden constant stories extra toegevoegd aan de sprint ipv die in de backlog te zetten
• Storypoints stonden gelijk aan x mandagen werk
• Vaak waren er altijd wel een paar met een dubbelrol. Zoals in een scrum setting dat iemand tegelijk product owner en scrum master was waardoor de kerntaken van scrum master al snel "vergeten" werden

Ik zit nu als consultant op mijn 5e project op anderhalf jaar tijd en slechts 1 klant deed het echt goed, 1 andere klant deed het bijna goed en de andere 3 werkten zogezegd agile maar faalden er heel hard in...

Mugwump schreef op woensdag 18 september 2019 @ 12:53:
[...]
Agile betekent in veel organisaties vooral dat teams enorm flexibel moeten zijn, oftewel stakeholders krijgen ideeën en die moeten dan ad hoc even geïmplementeerd worden. We werken toch immers Agile?

QFT

[Alex)]

Hydra schreef op woensdag 18 september 2019 @ 12:47:
[...]

In mijn ervaring zijn het meestal niet de ontwikkelaars die het probleem zijn bij een agile transformation maar meer de rest eromheen. Je hebt dan opeens allemaal project managers die eigenlijk geen rol meer hebben en zich dan maar PO noemen en op ongeveer dezelfde voet doorgaan. Of erger; bedrijven waar agile als extra laagje op een dysfunctioneel systeem wordt gesmeerd: dus nog meer crap en micromanagement in plaats van meer vrijheid.

Dat is ook precies mijn punt.

Voor de ontwikkelaars verandert er inhoudelijk niet veel, behalve dat ze nu ineens elke 2 weken iets releasebaars moeten hebben. Want anders wordt 'de sprint goal' niet gehaald en dan is de scrum-akela teleurgesteld en moet het team zich tijdens de eerstvolgende retrospective heel goed gaan afvragen waarom dat niet gelukt is enzo.

Wat @ElkeBxl in haar post beschrijft is ook mijn ervaring met 'agile werken' bij een groot bedrijf. Met als kers op de taart dat er wel elke 2 weken geleverd moest worden, volgens een door hoger manglement vastgelegde kalender, terwijl er gedurende ruim een jaar nooit wat naar productie ging.

In de tussentijd moesten we dus wel elke 2 weken een set features opleveren, ook als dat eigenlijk niet paste in de tijd die we hadden. Want budget voor extra ontwikkelaars was er niet, waardoor we in onze sprints geen tijd meer hadden voor dingen zoals refactoring, wegwerken van technical debt, enzovoorts.

We wilden wel, maar we hadden er maandenlang echt geen tijd voor.

[ElkeBxl]

Alex) schreef op woensdag 18 september 2019 @ 13:20:
[...]
Voor de ontwikkelaars verandert er inhoudelijk niet veel, behalve dat ze nu ineens elke 2 weken iets releasebaars moeten hebben. Want anders wordt 'de sprint goal' niet gehaald en dan is de scrum-akela teleurgesteld en moet het team zich tijdens de eerstvolgende retrospective heel goed gaan afvragen waarom dat niet gelukt is enzo.

Oh ik heb een hekel aan zo'n retrospectives. Vaak genoeg kan management het dan niet af als er gezegd wordt dat ze onrealistische verwachtingen hadden waarvan het team duidelijk op voorhand had aangegeven dat het onrealistisch was...

Of management is er niet eens bij waardoor de retrospective meer op een praatgroep lijkt...
Me: "Hi, my name is Elke and I didn't reach the unrealistic sprint goal..."
Everybody: "Hi Elke"

[Alex)]

Herkenbaar ja. Mijn input bij de retrospectives was na een tijdje dan ook niet veel meer dan "wat <naam> al zei".

[ElkeBxl]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 3% gewijzigd door ElkeBxl op 18-09-2019 13:35 . Reden: Vergat brakke Jira te vermelden ]

[Immutable]

Agile werkt goed bij een service georiënteerde software, waarbij je allerlei microservices hebt draaien e.d.

Maar zijn hier ook mensen die in de embedded wereld werken? O.a. Microcontrollers / ARM computers met linux? Kan daar Agile überhaupt wel toegepast worden? Ik zie meestal de waterval methode voorbij komen in deze wereld. Of werkt hier iedereen alleen maar aan backend systemen ofzo?

[Alex)]

Ohja, JIRA. Die tool waarmee je in één klap "agile" bent

[Verwijderd]

Ik kan agile koken

Maar zonder gekkigheid: de methode an sich is prima. En breed toepasbaar, zelfs buiten software. Voor projecten met (veel) onbekenden ideaal.

Heb in m'n cv nu als buzzwords git en jira gezet

[mcDavid]

ElkeBxl schreef op woensdag 18 september 2019 @ 13:27:
[...]

Oh ik heb een hekel aan zo'n retrospectives. Vaak genoeg kan management het dan niet af als er gezegd wordt dat ze onrealistische verwachtingen hadden waarvan het team duidelijk op voorhand had aangegeven dat het onrealistisch was...

Of management is er niet eens bij waardoor de retrospective meer op een praatgroep lijkt...
Me: "Hi, my name is Elke and I didn't reach the unrealistic sprint goal..."
Everybody: "Hi Elke"

Misschien dat ik er iets te serieus op in ga doordat ik eerder dit jaar een scrum-master cursus heb gedaan, maar het management heeft ook helemaal niets te zoeken bij een retro. De retro is voor het scrumteam zelf, om verbeterpunten aan te dragen in de manier van werken.

Immutable schreef op woensdag 18 september 2019 @ 13:54:
Agile werkt goed bij een service georiënteerde software, waarbij je allerlei microservices hebt draaien e.d.

Maar zijn hier ook mensen die in de embedded wereld werken? O.a. Microcontrollers / ARM computers met linux? Kan daar Agile überhaupt wel toegepast worden? Ik zie meestal de waterval methode voorbij komen in deze wereld. Of werkt hier iedereen alleen maar aan backend systemen ofzo?

Ligt er een beetje aan hoe complex de materie en het team is. Agile (of specifieker scrum) leent zich goed voor een bepaald type complexiteit, maar idd heel veel projecten zijn gewoon te simpel/overzichtelijk om agile aan te vliegen, of juist te complex.

[ Voor 31% gewijzigd door mcDavid op 18-09-2019 14:27 ]

[Hydra]

ElkeBxl schreef op woensdag 18 september 2019 @ 13:27:
Oh ik heb een hekel aan zo'n retrospectives.

Het probleem zijn niet de retrospectives maar het management. Afgeven op 'agile' is een sterk gevalletje 'shooting the messenger'. Als je gaat van geen proces naar een proces, welk proces dan ook, en merkt dat je bedrijf disfunctioneel is, dan ligt dat echt niet aan het proces.

Retro's zijn ongeveer de belangrijkste meetings.

mcDavid schreef op woensdag 18 september 2019 @ 14:21:
Misschien dat ik er iets te serieus op in ga doordat ik eerder dit jaar een scrum-master cursus heb gedaan, maar het management heeft ook helemaal niets te zoeken bij een retro.

Absoluut. En da's ook prima een punt voor een retro; dat er mensen bijzitten die er niet bijhoren. Afgezien van eventueel een agile coach horen daar alleen teamleden bij te zijn.

Immutable schreef op woensdag 18 september 2019 @ 13:54:
Agile werkt goed bij een service georiënteerde software, waarbij je allerlei microservices hebt draaien e.d.

Agile wordt toegepast in de zorg, het heeft an sich niks met software te maken, hoewel het uit de software wereld komt. Het heeft dus ook niks met 'microservices' te maken. Die link is er gewoon niet.

Maar zijn hier ook mensen die in de embedded wereld werken? O.a. Microcontrollers / ARM computers met linux? Kan daar Agile überhaupt wel toegepast worden?

Tuurlijk kan dat.

Ik zie meestal de waterval methode voorbij komen in deze wereld. Of werkt hier iedereen alleen maar aan backend systemen ofzo?

De reden dat je dat ziet is omdat dergelijke omgevingen vaak enorm conservatief zijn. "Het werkt nu toch?" is killer voor elke verbetering. En bij dat soort clubs wordt vaak gecowboy-code.

[ Voor 65% gewijzigd door Hydra op 18-09-2019 14:29 ]

[Alex)]

Ik vind retro's echt de meest kansloze meetings om na elke sprint te hebben.

Af en toe een calibratiemoment vind ik wel goed, maar als je in een team zit wat goed functioneert en waarbij alles z'n gangetje gaat zie ik geen reden om elke 2 weken in een kringetje te gaan zitten om tegen elkaar te zeggen dat het allemaal heel goed is gegaan.

Wanneer je nog aan het opstarten bent is het wel nuttig om te volgen of iedereen een beetje aan het settlen is. Bij wijzigingen aan de teamsamenstelling of het werk wat er gedaan wordt, ook wel. Maar als je in een steady state zit? Nee.

[ElkeBxl]

Verwijderd schreef op woensdag 18 september 2019 @ 14:19:
Ik kan agile koken

Haha, waren wij gisteren nog mee aan het lachen wat dat zou zijn als je een agile restaurant hebt.

"Ah u wil erwtensoep? Hier is uw kokend water, tijdens de volgende sprint zullen we de erwten toevoegen en ter plekke aan tafel de boel voor je mixen. Oh en de kruiden zullen we tijdens de volgende gang geven. Uiteindelijk eindig je dan in je maag ook met iets wat ongeveer op erwtensoep lijkt hé..."

mcDavid schreef op woensdag 18 september 2019 @ 14:21:
[...]


Misschien dat ik er iets te serieus op in ga doordat ik eerder dit jaar een scrum-master cursus heb gedaan, maar het management heeft ook helemaal niets te zoeken bij een retro. De retro is voor het scrumteam zelf, om verbeterpunten aan te dragen in de manier van werken.

True. Helaas zat er haast altijd wel iemand van management in het scrum team met 1 of andere dubbelrol (zoals scrum master). Maar zoals je in mijn eerdere posts kon lezen ging er sowieso een hoop fout.

Hydra schreef op woensdag 18 september 2019 @ 14:25:
[...]
Het probleem zijn niet de retrospectives maar het management. Afgeven op 'agile' is een sterk gevalletje 'shooting the messenger'. Als je gaat van geen proces naar een proces, welk proces dan ook, en merkt dat je bedrijf disfunctioneel is, dan ligt dat echt niet aan het proces.

Ook true. Maar als management perse deel van het scrum team wil zijn, moeten ze ook maar tegen de kritiek kunnen tijdens retrospectives.

[CurlyMo]

Hydra schreef op woensdag 18 september 2019 @ 14:25:
[...]
Afgeven op 'agile' is een sterk gevalletje 'shooting the messenger'.

Behalve als die messengers de zendelingen beginnen uit te hangen. Dan stel ik iets voor in het team om vervolgens te horen te krijgen: "Precies zoals ze met agile methode X bedoelen". Ehm, ja boeiend, vind je het ook een goed idee nog los van hoe je het noemt of wie het in een vorm heeft gegoten.

[ThomasG]

Alex) schreef op woensdag 18 september 2019 @ 14:28:
Ik vind retro's echt de meest kansloze meetings om na elke sprint te hebben.

Af en toe een calibratiemoment vind ik wel goed, maar als je in een team zit wat goed functioneert en waarbij alles z'n gangetje gaat zie ik geen reden om elke 2 weken in een kringetje te gaan zitten om tegen elkaar te zeggen dat het allemaal heel goed is gegaan.

Wanneer je nog aan het opstarten bent is het wel nuttig om te volgen of iedereen een beetje aan het settlen is. Bij wijzigingen aan de teamsamenstelling of het werk wat er gedaan wordt, ook wel. Maar als je in een steady state zit? Nee.

Er is altijd ruimte voor verbetering. Omdat "alles goed gegaan is", betekend natuurlijk niet dat er geen punten zijn die achteraf gezien beter konden; ook al zijn ze goed genoeg gegaan.

[Alex)]

Wat ook een mooie is is als je aangeeft dat je denkt dat iets beter kan, om dan te horen krijgen "gaan we niet doen, want dat hoort niet zo volgens Scrum." Bam, deur dicht. Geen verdere onderbouwing behalve dat het 'niet hoort'.

Sowieso krijg ik een beetje jeuk van sommige termen, "Scrum-rituelen" bijvoorbeeld.

[CurlyMo]

Alex) schreef op woensdag 18 september 2019 @ 14:31:
Wat ook een mooie is is als je aangeeft dat je denkt dat iets beter kan, om dan te horen krijgen "gaan we niet doen, want dat hoort niet zo volgens Scrum." Bam, deur dicht. Geen verdere onderbouwing behalve dat het 'niet hoort'.

Sowieso krijg ik een beetje jeuk van sommige termen, "Scrum-rituelen" bijvoorbeeld.

[Hydra]

Alex) schreef op woensdag 18 september 2019 @ 14:28:
Ik vind retro's echt de meest kansloze meetings om na elke sprint te hebben.

Af en toe een calibratiemoment vind ik wel goed, maar als je in een team zit wat goed functioneert en waarbij alles z'n gangetje gaat zie ik geen reden om elke 2 weken in een kringetje te gaan zitten om tegen elkaar te zeggen dat het allemaal heel goed is gegaan.

Ik geloof er geen fluit van dat je niet elke twee weken wat puntjes hebt waar je het eens over wil hebben. En als het dan heel soepel loopt allemaal; prima. Dan ben je in 10 minuten klaar toch?

CurlyMo schreef op woensdag 18 september 2019 @ 14:29:
Behalve als die messengers de zendelingen beginnen uit te hangen. Dan stel ik iets voor in het team om vervolgens te horen te krijgen: "Precies zoals ze met agile methode X bedoelen". Ehm, ja boeiend, vind je het ook een goed idee nog los van hoe je het noemt of wie het in een vorm heeft gegoten.

Je begrijpt niet wat ik bedoel. Ik heb het niet over mensen. Ik heb het erover dat de methode zelf aan het licht brengt dat je problemen hebt. "Agile coaches" die zich overal te pas en te onpas tegenaan bemoeien heb ik niks mee, helemaal als die mensen zelf uberhaupt geen software dev ervaring hebben en alleen maar een cursusje 'agile coach' gedaan hebben. Boekjeswijsheden oplepelen kan iedereen.

ElkeBxl schreef op woensdag 18 september 2019 @ 14:29:
[...]

Haha, waren wij gisteren nog mee aan het lachen wat dat zou zijn als je een agile restaurant hebt.

"Ah u wil erwtensoep? Hier is uw kokend water, tijdens de volgende sprint zullen we de erwten toevoegen en ter plekke aan tafel de boel voor je mixen. Oh en de kruiden zullen we tijdens de volgende gang geven. Uiteindelijk eindig je dan in je maag ook met iets wat ongeveer op erwtensoep lijkt hé..."

Grappig aangezien een keuken over 't algemeen via een soort kanban-methode werkt. Over het algemeen werkt 'agile' heel erg goed op plekken waar met korte iteraties geproduceerd moet worden. Ga een keuken maar eens 'waterval' inrichten; een paar weken plannen en er dan achter komen dat de gasten in de zomer weinig trek hebben in ertwensoep.

Je parallel werkt beter de andere kant op vrees ik

ElkeBxl schreef op woensdag 18 september 2019 @ 14:29:
Ook true. Maar als management perse deel van het scrum team wil zijn, moeten ze ook maar tegen de kritiek kunnen tijdens retrospectives.

Het agile manifesto is er vrij duidelijk in dat je je mensen gewoon moet vertrouwen. Als manager je in een retro voegen staat daar m.i. lijnrecht tegenover. Ik zou ook hard gaan protesteren.

Ik heb gelukkig vooral positieve ervaringen met scrum implementaties.

Alex) schreef op woensdag 18 september 2019 @ 14:31:
Wat ook een mooie is is als je aangeeft dat je denkt dat iets beter kan, om dan te horen krijgen "gaan we niet doen, want dat hoort niet zo volgens Scrum."

Dan snap je agile gewoon niet. Het idee is dat je het proces afstemt op de behoefte van je team. Als je team met T-shirt sizes wil werken i.p.v. punten dan moet dat gewoon kunnen. Als een agile coach daar een issue van maakt (want geen burndown grafiek!) dan heeft 'ie het gewoon niet begrepen.

[ Voor 15% gewijzigd door Hydra op 18-09-2019 14:38 ]

[Alex)]

ThomasG schreef op woensdag 18 september 2019 @ 14:31:
[...]
Er is altijd ruimte voor verbetering. Omdat "alles goed gegaan is", betekend natuurlijk niet dat er geen punten zijn die achteraf gezien beter konden; ook al zijn ze goed genoeg gegaan.

Daarom zei ik ook, "af en toe een calibratiemoment".

Af en toe zijn er gewoon van die periodes waarin weinig noemenswaardigs gebeurd. Dan gebruik ik m'n tijd liever anders.

Hydra schreef op woensdag 18 september 2019 @ 14:34:
[...]

Ik geloof er geen fluit van dat je niet elke twee weken wat puntjes hebt waar je het eens over wil hebben. En als het dan heel soepel loopt allemaal; prima. Dan ben je in 10 minuten klaar toch?

Het is aan jou of je dat wel of niet gelooft, ik deel hier slechts mijn ervaringen en geef mijn mening. Ik heb echt wel de nodige retrospectives meegemaakt waarin sprint-op-sprint hetzelfde werd gezegd:

"Wat ging er goed? We hebben alle stories afgemaakt en de klant is blij."
"Wat kon er beter? Nou ja, de dingen die we al meerdere keren hebben aangegeven maar waar niks mee gebeurt want <corporate politics>."
"Welke score geef je aan de afgelopen sprint? Oh, dezelfde als vorige keer."

Op een gegeven moment is zo'n sessie dan niets meer dan een box ticking exercise.