De Devschuur Coffee Corner - Iteratie ⑬

[SPee]

Sebazzz schreef op zondag 9 januari 2022 @ 12:15:
[...]
Symantec Endpoint Protection hier, die scant bij elke file access. Daarnaast CarbonBlack sensor, Hive streaming en Umbrella Roaming Client.

Krijgt de laptop op zijn knieën, zelfs met uitzonderingen.

Jij mag uitzonderingen toevoegen van je systeembeheerder?
Die SEP zet alle poorten dicht bij mij, scant op donderdagen mijn HDD en encrypt alles wat ik naar een USB kopieer.
Ik weet niet meer goed of hij nu ook nog steeds poort 8080 bezet.
En daarnaast gaat al het internet verkeer via hun proxy, dus als je dacht dat je internet snel genoeg was...

[gekkie]

SPee schreef op zondag 9 januari 2022 @ 18:06:
[...]


Jij mag uitzonderingen toevoegen van je systeembeheerder?
Die SEP zet alle poorten dicht bij mij, scant op donderdagen mijn HDD en encrypt alles wat ik naar een USB kopieer.
Ik weet niet meer goed of hij nu ook nog steeds poort 8080 bezet.
En daarnaast gaat al het internet verkeer via hun proxy, dus als je dacht dat je internet snel genoeg was...

Al eens voorgesteld dat niet of minder werken met behoudt van salaris nog een stuk veiliger is ?

[Kalentum]

SPee schreef op zondag 9 januari 2022 @ 18:06:
[...]


Jij mag uitzonderingen toevoegen van je systeembeheerder?
Die SEP zet alle poorten dicht bij mij, scant op donderdagen mijn HDD en encrypt alles wat ik naar een USB kopieer.
Ik weet niet meer goed of hij nu ook nog steeds poort 8080 bezet.
En daarnaast gaat al het internet verkeer via hun proxy, dus als je dacht dat je internet snel genoeg was...

Jij mag kopiëren naar een USB? Staat bij ons dicht.

[Sebazzz]

SPee schreef op zondag 9 januari 2022 @ 18:06:
[...]


Jij mag uitzonderingen toevoegen van je systeembeheerder?

Nee, wel aanvragen voor processen en paden. Het werkt echter maar beperkt.

[F.West98]

https://github.com/Marak/colors.js/issues/285

Here we go again...

[DevWouter]

F.West98 schreef op maandag 10 januari 2022 @ 17:29:
https://github.com/Marak/colors.js/issues/285

Here we go again...

1. open source is a gift. you are not obliged to give gifts.
2. if you decide to give a gift, you don't shit into it
3. if you give a gift and shit into it, you are the asshole, no matter how expensive was the gift, or how ungrateful were the people receiving it.

— hasherezade (@hasherezade) 9 januari 2022

En voor zijn probleem had hij de licentie kunnen aanpassen. Het is gewoon trol.

[Koenvh]

@DevWouter Nee nee, je begrijpt het niet. Als je een Open Source project start, zeg je toe dat zolang je leeft je het project zal onderhouden, ervoor zal zorgen dat je een opvolger hebt als je komt te overlijden, dat je altijd alle versies onderhoudt, dat je prompt op issues reageert, en dat je altijd alle feedback verwerkt.

Zonder dollen: sommige mensen denken dat ze het recht hebben op iets. Die mensen kan ik dus ook niet uitstaan. Dat geldt zowel voor mensen die in de issues ondersteuning eisen, maar ook voor de ontwikkelaars die geld "eisen" voor hun gratis Open Source project.

De wereld zou toch zo veel mooier zijn als we allemaal een beetje lief zouden zijn tegen elkaar.

[ Voor 7% gewijzigd door Koenvh op 10-01-2022 17:59 ]

[gekkie]

Koenvh schreef op maandag 10 januari 2022 @ 17:56:
@DevWouter Nee nee, je begrijpt het niet. Als je een Open Source project start, zeg je toe dat zolang je leeft je het project zal onderhouden, ervoor zal zorgen dat je een opvolger hebt als je komt te overlijden, dat je altijd alle versies onderhoudt, dat je prompt op issues reageert, en dat je altijd alle feedback verwerkt.

Zonder dollen: sommige mensen denken dat ze het recht hebben op iets. Die mensen kan ik dus ook niet uitstaan. Dat geldt zowel voor mensen die in de issues ondersteuning eisen, maar ook voor de ontwikkelaars die geld "eisen" voor hun gratis Open Source project.

De wereld zou toch zo veel mooier zijn als we allemaal een beetje lief zouden zijn tegen elkaar.

Eigenlijk allemaal nog nooit in me opgekomen.
Al zou soms iets meer meedenken van de dev (bijvb in wat je zelf weer kunt bijdragen in debuggen en hoe dat het handigste kan met dat project) ipv in eerste instantie afhouden ook wel handig zijn.
Maar goed probeer wel altijd een goede omschrijving te geven van het probleem en wat ik al het getracht te doen.
Ahwel heb nog een forse bisect voor de kiezen, ergens van de week maar eens tussendoor zien te doen.

[.oisyn]

https://nypost.com/2020/0...making-materials-charged/
Same dude.

[gekkie]

.oisyn schreef op maandag 10 januari 2022 @ 18:18:
https://nypost.com/2020/0...making-materials-charged/
Same dude.

Kleurde dus wel vaker wat buiten de lijntjes zo gezegd

[Koenvh]

gekkie schreef op maandag 10 januari 2022 @ 18:06:
[...]

Eigenlijk allemaal nog nooit in me opgekomen.
Al zou soms iets meer meedenken van de dev (bijvb in wat je zelf weer kunt bijdragen in debuggen en hoe dat het handigste kan met dat project) ipv in eerste instantie afhouden ook wel handig zijn.
Maar goed probeer wel altijd een goede omschrijving te geven van het probleem en wat ik al het getracht te doen.
Ahwel heb nog een forse bisect voor de kiezen, ergens van de week maar eens tussendoor zien te doen.

Als mensen de moeite doen om mee te helpen ben ik al tevreden. Echter ontvang ik ook wel eens e-mail met HOOFDLETTERS en tekst à la "je bent een incompetente fallus, want <vermeend probleem x,y,z>" - dat gaat wel direct in de prullenbak, of als ik zin heb stuur ik iets terug als "Wat wil je hiermee precies bereiken?"

[gekkie]

Koenvh schreef op maandag 10 januari 2022 @ 18:39:
[...]

Als mensen de moeite doen om mee te helpen ben ik al tevreden. Echter ontvang ik ook wel eens e-mail met HOOFDLETTERS en tekst à la "je bent een incompetente fallus, want <vermeend probleem x,y,z>" - dat gaat wel direct in de prullenbak, of als ik zin heb stuur ik iets terug als "Wat wil je hiermee precies bereiken?"

Yups ik zie die dingen ook wel regelmatig voorbij komen. Voor mijn gevoel ook redelijk wat chinezen die er een halve regel brak Engels aan willen koppelen en bij iedere wedervraag om verder te komen weer hetzelfde posten en vervolgens eventueel met wat gescheld er de brui aangeven.

Ik heb ook niet overal tijd en zin in om alles al (vooraf) geheel te debuggen, sommige projecten zijn al vrij kansloos vanwege hun esoterische build-systeem wat ook nog in lockstep zou moeten werken met de code
(ja Google, that's you met dat gebazel bij tensorflow, wat een hell om dat te builden en dus te kunnen debuggen).

[ Voor 18% gewijzigd door gekkie op 10-01-2022 18:43 ]

[Creepy]

En laten we dan maar niet noemen dat er nog steeds mensen zijn die symantic versioning, of "latest", en auto updates van dependencies een goed idee vinden. Poef, daar ging je CI build ineens terwijl je zelf niks hebt veranderd (jaja, lockfiles enzo als workaround, maar gezien de gigantische thread in de colorjs issue......... dus....)

[gekkie]

Naja dat hele NPM is wel zo'n klucht aan het worden, waarbij het meeste in wat grotere libs zou moeten zitten die wat meer gezamelijke aandacht krijgen ipv die one-liner-one-man show die dat NPM ecosysteem is.

[Mugwump]

Creepy schreef op maandag 10 januari 2022 @ 21:08:
En laten we dan maar niet noemen dat er nog steeds mensen zijn die symantic versioning, of "latest" en auto updates van dependencies een goed idee vinden. Poef, daar ging je CI build ineens terwijl je zelf niks hebt veranderd (jaja, lockfiles enzo als workaround, maar gezien de gigantische thread in de colorjs issue......... dus....)

Ik heb echt zo'n pesthekel aan NPM. We gebruiken het eigenlijk alleen omdat we onze IaC ontwikkelen in typescript middels AWS CDK. CDK v1 bestaat uit drie miljard losse dependencies voor alle verschillende infra componenten. Als je dan latest minor gebruikt en AWS zit in zijn wekelijke update cyclus, dan liggen je pipelines plat omdat elke dependency los wordt geüpdatet en minor versie 35 van component A weer niet compatibel is met minor versie 36 van component B.

Gelukkig hebben ze inmiddels een versie 2 van CDK waarin ze het licht hebben gezien en alles in één enkele dependency hebben gestopt, maar dat vergt natuurlijk ook weer een enorme bak rework omdat het om mijn huidige project pakweg 20 git projecten raakt op dit moment.

[gekkie]

Mugwump schreef op maandag 10 januari 2022 @ 22:26:
[...]


Ik heb echt zo'n pesthekel aan NPM. We gebruiken het eigenlijk alleen omdat we onze IaC ontwikkelen in typescript middels AWS CDK. CDK v1 bestaat uit drie miljard losse dependencies voor alle verschillende infra componenten. Als je dan latest minor gebruikt en AWS zit in zijn wekelijke update cyclus, dan liggen je pipelines plat omdat elke dependency los wordt geüpdatet en minor versie 35 van component A weer niet compatibel is met minor versie 36 van component B.

Gelukkig hebben ze inmiddels een versie 2 van CDK waarin ze het licht hebben gezien en alles in één enkele dependency hebben gestopt, maar dat vergt natuurlijk ook weer een enorme bak rework omdat het om mijn huidige project pakweg 20 git projecten raakt op dit moment.

Vanwaar om dat niet in python of java te doen, maar in typscript met de NPM hell er gratis bij ?

[Mugwump]

gekkie schreef op maandag 10 januari 2022 @ 22:58:
[...]

Vanwaar om dat niet in python of java te doen, maar in typscript met de NPM hell er gratis bij ?

Dat heeft een beetje meer de teamsamenstelling te maken. De devs spreken allemaal vloeiend Java, alleen hebben we er ook wat opsers bij voor wie Java een beetje eng is om de één of andere reden. Dus toen is typescript er maar als compromis uitgekomen.
Van Python werd niemand vrolijk.

[gekkie]

Mugwump schreef op maandag 10 januari 2022 @ 23:01:
[...]
Dat heeft een beetje meer de teamsamenstelling te maken. De devs spreken allemaal vloeiend Java, alleen hebben we er ook wat opsers bij voor wie Java een beetje eng is om de één of andere reden. Dus toen is typescript er maar als compromis uitgekomen.
Van Python werd niemand vrolijk.

Naja vanwege java is eng en python ugh indentatie, voor ik neem aan voornamelijk glue-code die hele NPM sores op je neer laten dalen. Keuzes keuzes keuzes, het verschil tussen "ops" en "oeps" is niet zo heel groot

[gekkie]

Urgh docker containers die voort borduren op ubuntu's die inmiddels letsencrypt certificaten niet meer slikken en dan fijn niet weer willen git clonen
Niets is voor de eeuwigheid zullen we maar zeggen.
(aangezien het incidenteel eens moet bouwen overleef ik het wel met het ignoren van de SSL verify).

[ Voor 19% gewijzigd door gekkie op 10-01-2022 23:22 ]

[RagingPenguin]

Creepy schreef op maandag 10 januari 2022 @ 21:08:
En laten we dan maar niet noemen dat er nog steeds mensen zijn die symantic versioning, of "latest", en auto updates van dependencies een goed idee vinden. Poef, daar ging je CI build ineens terwijl je zelf niks hebt veranderd (jaja, lockfiles enzo als workaround, maar gezien de gigantische thread in de colorjs issue......... dus....)

Op zich is daar niks mis mee, zolang je maar een lock file gebruikt om te zorgen dat de versies van commit X de versies zijn die op die toen geldig waren en niet degene die nu geldig zijn. Anders is het russische roulette of je dependencies iets opleveren wat met elkaar wil werken.

[Koenvh]

gekkie schreef op maandag 10 januari 2022 @ 18:41:
[...]

Yups ik zie die dingen ook wel regelmatig voorbij komen. Voor mijn gevoel ook redelijk wat chinezen die er een halve regel brak Engels aan willen koppelen en bij iedere wedervraag om verder te komen weer hetzelfde posten en vervolgens eventueel met wat gescheld er de brui aangeven.

Ik heb ook niet overal tijd en zin in om alles al (vooraf) geheel te debuggen, sommige projecten zijn al vrij kansloos vanwege hun esoterische build-systeem wat ook nog in lockstep zou moeten werken met de code
(ja Google, that's you met dat gebazel bij tensorflow, wat een hell om dat te builden en dus te kunnen debuggen).

Oh, dat wil ik best doortrekken: als ik je repository clone en iets aanpas, dan kun je niet eisen dat ik ook een pull request voor mijn aanpassing maak, net zomin als ik ook niet kan eisen dat je mijn pull request accepteert als ik 'm toch maak. Soms doe ik het wel, soms niet.

De mensen die bij mij klagen zijn volgens mij vooral kinderen die denken dat ze alles kunnen krijgen als ze maar hard genoeg schreeuwen (het project wat ik op dit moment in gedachten heb is iets wat iets toevoegt aan Euro Truck Simulator 2, dan krijg je ook kinderen als doelgroep), en dan wil ik nog wel eens een "opvoedende" reactie terugsturen over netjes met elkaar omgaan. Af en toe werkt dat gelukkig

[gekkie]

Koenvh schreef op maandag 10 januari 2022 @ 23:43:
[...]
Oh, dat wil ik best doortrekken: als ik je repository clone en iets aanpas, dan kun je niet eisen dat ik ook een pull request voor mijn aanpassing maak, net zomin als ik ook niet kan eisen dat je mijn pull request accepteert als ik 'm toch maak. Soms doe ik het wel, soms niet.

De mensen die bij mij klagen zijn volgens mij vooral kinderen die denken dat ze alles kunnen krijgen als ze maar hard genoeg schreeuwen (het project wat ik op dit moment in gedachten heb is iets wat iets toevoegt aan Euro Truck Simulator 2, dan krijg je ook kinderen als doelgroep), en dan wil ik nog wel eens een "opvoedende" reactie terugsturen over netjes met elkaar omgaan. Af en toe werkt dat gelukkig

Iemand moet ze opvoeden en op zich is het zo toch nog makkelijk om ze achter het git-behangetje te plakken

[Koenvh]

gekkie schreef op maandag 10 januari 2022 @ 23:46:
[...]

Iemand moet ze opvoeden en op zich is het zo toch nog makkelijk om ze achter het git-behangetje te plakken

Klopt, dus dan schrijf ik vaak iets terug als:
"Wat wil je nu precies met je bericht bereiken? Als je me wilt irriteren, gefeliciteerd, dat is je gelukt. Ik doe dit vrijwillig, en met de toon die je nu aanslaat heb ik al bij voorbaat geen zin meer om iets voor je te doen. Echter, ik ga ervan uit dat je het niet zo bedoelt, en ik geloof in tweede kansen, dus als je het nog een keer op een normale, vriendelijke toon kunt schrijven, dan wil ik best kijken wat ik kan doen."

Ik hoop dat ze er iets van leren

[gekkie]

Koenvh schreef op dinsdag 11 januari 2022 @ 01:03:
[...]

Klopt, dus dan schrijf ik vaak iets terug als:
"Wat wil je nu precies met je bericht bereiken? Als je me wilt irriteren, gefeliciteerd, dat is je gelukt. Ik doe dit vrijwillig, en met de toon die je nu aanslaat heb ik al bij voorbaat geen zin meer om iets voor je te doen. Echter, ik ga ervan uit dat je het niet zo bedoelt, en ik geloof in tweede kansen, dus als je het nog een keer op een normale, vriendelijke toon kunt schrijven, dan wil ik best kijken wat ik kan doen."

Ik hoop dat ze er iets van leren

Kan zo op stackoverflow voor de copy-paste

[Mugwump]

gekkie schreef op maandag 10 januari 2022 @ 23:11:
[...]

Naja vanwege java is eng en python ugh indentatie, voor ik neem aan voornamelijk glue-code die hele NPM sores op je neer laten dalen. Keuzes keuzes keuzes, het verschil tussen "ops" en "oeps" is niet zo heel groot

Persoonlijk heb ik nog liever NPM dan indentation-as-a-language-construct.

[gekkie]

Mugwump schreef op dinsdag 11 januari 2022 @ 07:32:
[...]
Persoonlijk heb ik nog liever NPM dan indentation-as-a-language-construct.

Smaken verschillen

[bwerg]

Iets wat in een uurtje aan te leren is en waar prima mee om te gaan is versus een fundamenteel stuk ecosysteem wat in je project altijd last zal geven. Ach ja.

Nee, dan die dynamische typering...

* bwerg rent

[gekkie]

bwerg schreef op dinsdag 11 januari 2022 @ 09:38:
Iets wat in een uurtje aan te leren is en waar prima mee om te gaan is versus een fundamenteel stuk ecosysteem wat in je project altijd last zal geven. Ach ja.

Nee, dan die dynamische typering...

* bwerg rent

Met een wurgslang als blok aan het been ?

[Caelorum]

bwerg schreef op dinsdag 11 januari 2022 @ 09:38:
[..] Nee, dan die dynamische typering... [...]

Static types zonder type inference..

[gekkie]

Hmm tijd om m'n code maar eens per git commit te gaan verkopen als NFT, wat een wereld
(non fungible is het al redelijk en met sha1 hebben we ook een token, ready to go ..)

[ Voor 32% gewijzigd door gekkie op 11-01-2022 09:44 ]

[bwerg]

Caelorum schreef op dinsdag 11 januari 2022 @ 09:41:
[...]

Static types zonder type inference..

Wat, in standaard python?

Ik heb mijn python-kennis al een tijdje niet meer opgepoetst maar de laatste keer dat ik de laatste python drie punt zoveel installeerde was de boel toch verdacht dynamisch getypeerd.

[kameraadpjotr]

Koenvh schreef op dinsdag 11 januari 2022 @ 01:03:
[...]

en ik geloof in tweede kansen

Ik niet.

Een hobby blijft een hobby, en het leven is te kort om me bezig te houden met kleine kindjes die op de vloer liggen te stampen omdat ze hun speeltje niet krijgen (eigen kinderen uitgezonderd uiteraard ;-)).

[gekkie]

kameraadpjotr schreef op dinsdag 11 januari 2022 @ 09:46:
[...]
Ik niet.

Een hobby blijft een hobby, en het leven is te kort om me bezig te houden met kleine kindjes die op de vloer liggen te stampen omdat ze hun speeltje niet krijgen (eigen kinderen uitgezonderd uiteraard ;-)).

Lijk me dat het toch met enige regelmaat nuttige verbeteringen of bugfixes met zich mee kan brengen.
Dus afhankelijk van je liefde voor het project of de code zou dat toch zowel aardig als nuttig kunnen zijn.
Daarnaast een heel klein stukje investeren in de toekomst in de hoop dat het kwartje valt bij die kinderen en het later ook prettigere mensen zijn om mee te werken in eender welk eco-systeem je ze wellicht nog eens tegen gaat komen of code van hun zou kunnen gebruiken.

[Alex)]

Hallo 👋🏻

De kerstvakantie zit er voor mij weer op, aan het werk. 50 ongelezen emails maar, valt me mee.

[Mugwump]

bwerg schreef op dinsdag 11 januari 2022 @ 09:38:
Iets wat in een uurtje aan te leren is en waar prima mee om te gaan is versus een fundamenteel stuk ecosysteem wat in je project altijd last zal geven. Ach ja.

Nee, dan die dynamische typering...

* bwerg rent

Heb je daar een uur voor nodig?

[Caelorum]

bwerg schreef op dinsdag 11 januari 2022 @ 09:45:
[...]

Wat, in standaard python?

Ik heb mijn python-kennis al een tijdje niet meer opgepoetst maar de laatste keer dat ik de laatste python drie punt zoveel installeerde was de boel toch verdacht dynamisch getypeerd.

Nee, maar zowel npm als python is ruk

[gekkie]

Alex) schreef op dinsdag 11 januari 2022 @ 10:04:
Hallo

De kerstvakantie zit er voor mij weer op, aan het werk. 50 ongelezen emails maar, valt me mee.

> /dev/null ?

[Firesphere]

Koenvh schreef op maandag 10 januari 2022 @ 23:43:
[...]

Oh, dat wil ik best doortrekken: als ik je repository clone en iets aanpas, dan kun je niet eisen dat ik ook een pull request voor mijn aanpassing maak, net zomin als ik ook niet kan eisen dat je mijn pull request accepteert als ik 'm toch maak. Soms doe ik het wel, soms niet.

En toch zou ik graag een soort licence zien, die dit wel verplicht.

Elke wijziging moet terug naar de bron. De bron kan dan beslissen of het de moeite waard is of niet.

Voorkomt ook een hoop dubbel werk.... hoop ik.

[gekkie]

Firesphere schreef op dinsdag 11 januari 2022 @ 10:58:
[...]

En toch zou ik graag een soort licence zien, die dit wel verplicht.

Elke wijziging moet terug naar de bron. De bron kan dan beslissen of het de moeite waard is of niet.

Voorkomt ook een hoop dubbel werk.... hoop ik.

Maar is het dan voldoende om dat gene over de schutting te gooien (wat je min of meer met GPL hebt, publiceer je wijziging en klaar), want een hoop effort gaat vaak toch zitten in het idee of de feature fatsoenlijk te integreren in de upstream repo.

[Ghehe]

Lekker bitchen over programmeertalen in de koffiehoek onder het genot van een kopje koffie Heerlijk

[gekkie]

Ghehe schreef op dinsdag 11 januari 2022 @ 11:05:
[Afbeelding]

Het dingetje is ... deden ze dat maar, ik zou nachten lang door programmeren

[whoami]

Mugwump schreef op maandag 10 januari 2022 @ 22:26:
[...]


Ik heb echt zo'n pesthekel aan NPM. We gebruiken het eigenlijk alleen omdat we onze IaC ontwikkelen in typescript middels AWS CDK. CDK v1 bestaat uit drie miljard losse dependencies voor alle verschillende infra componenten. Als je dan latest minor gebruikt en AWS zit in zijn wekelijke update cyclus, dan liggen je pipelines plat omdat elke dependency los wordt geüpdatet en minor versie 35 van component A weer niet compatibel is met minor versie 36 van component B.

Gelukkig hebben ze inmiddels een versie 2 van CDK waarin ze het licht hebben gezien en alles in één enkele dependency hebben gestopt, maar dat vergt natuurlijk ook weer een enorme bak rework omdat het om mijn huidige project pakweg 20 git projecten raakt op dit moment.

Ik ben niet thuis in de Java & AWS wereld, maar als ik dit goed begrijp, dan doen jullie Infrastructure as Code op een imperatieve manier, en niet declaratief ?
Heb je op AWS niets waarmee je je resources declaratief kunt beschrijven; a la ARM of beter nog bicep, in Azure ?

[Mugwump]

whoami schreef op dinsdag 11 januari 2022 @ 13:58:
[...]

Ik ben niet thuis in de Java & AWS wereld, maar als ik dit goed begrijp, dan doen jullie Infrastructure as Code op een imperatieve manier, en niet declaratief ?
Heb je op AWS niets waarmee je je resources declaratief kunt beschrijven; a la ARM of beter nog bicep, in Azure ?

Je hebt in AWS 101 manier om infrastructure as code te doen (nou ja, 101 in het binaire stelsel dan ).
Eigenlijk is CloudFormation de basis. Dat zijn inderdaad templates in declaratieve vorm middels YAML of JSON. Daar zijn we ooit mee begonnen, maar allemaal geen groot fan van. Toen is AWS gekomen met Cloud Development Kit (CDK). Daarmee specificeer je inderdaad meer imperatief je infrastructure as code.

Daar zitten in mijn ogen heel veel voordelen aan. Naast het unit testen van je IaC is het ook veel makkelijker om modulair te werken door herbruikbare constructs te maken. Bovendien heeft CDK ook weer 'higher level constructs' die feitelijk wrappers zijn om zaken waardoor het veel minder verbose is. In CloudFormation moet je vaak heel veel loze attributen specificeren die in die constructs gewoon automatisch voor je worden meegegenereerd omdat het feitelijk gewoon default waarden zijn.

Bovendien kun je op die manier ook nog weer juist de componenten van je systeem opslaan in een artifact repository zoals bijvoorbeeld in CodeArtifact van AWS zelf. Dat maakt het weer heel makkelijk om on demand een eigen stack van je systeem te maken bestaande uit verschillende versies van onafhankelijke componenten voor testdoeleinden en dergelijke.

En eigenlijk vind ik hergebruik van allerhande conditionele zaken, functies voor gestandaardiseerde naamgevingsconventies, aspects / decorators en ga zo maar door allemaal veel makkelijker in een imperatieve taal dan in declaratieve vorm.

[Koenvh]

Firesphere schreef op dinsdag 11 januari 2022 @ 10:58:
[...]

En toch zou ik graag een soort licence zien, die dit wel verplicht.

Elke wijziging moet terug naar de bron. De bron kan dan beslissen of het de moeite waard is of niet.

Voorkomt ook een hoop dubbel werk.... hoop ik.

Hoe zou dat werken? De GPL komt daar het dichtste bij in de buurt, je publiceert je wijzigingen, en die kan de andere partij weer overnemen, maar dat is in principe ook wat ik doe. Maar als een project een style guide van tientallen pagina's heeft, tests heeft die uren moeten draaien op een setup die ik niet heb, etc. etc., formeel moet bewijzen dat het programma nog steeds eindig is met mijn wijziging, dan heb ik daar ook niet altijd zin in.

Ik zeg niet dat ik het erg vind dat een project die eisen heeft, dat begrijp ik heel goed, maar het gevolg daarvan is wel dat mensen dus minder snel zullen bijdragen. En dan is het ook nog de vraag of de wijzigingen wel in lijn zijn met het originele project.

[Koenvh]

kameraadpjotr schreef op dinsdag 11 januari 2022 @ 09:46:
[...]


Ik niet.

Een hobby blijft een hobby, en het leven is te kort om me bezig te houden met kleine kindjes die op de vloer liggen te stampen omdat ze hun speeltje niet krijgen (eigen kinderen uitgezonderd uiteraard ;-)).

Oh, de moeite die ik er daarna instop is ook zeker niet zo groot als iemand die normaal een bericht stuurt. Wat ik vooral hoop te bereiken is dat andere mensen (kinderen) het lezen (dit is grotendeels openbaar), en dan tot inkeer komen. Sommige kinderen hebben geleerd dat door hard te schreeuwen ze altijd krijgen wat ze willen, waarschijnlijk omdat de ouders altijd eraan toegeven, en ik wil ze laten zien dat dat dus niet zo werkt. Daarnaast zou ik het zonde vinden als mensen niet meer aan dit soort dingen werken puur omdat ze in plaats van "bedankt" een lawine van opdringerige kinderen over zich heen krijgen.

[RagingPenguin]

whoami schreef op dinsdag 11 januari 2022 @ 13:58:
[...]

Ik ben niet thuis in de Java & AWS wereld, maar als ik dit goed begrijp, dan doen jullie Infrastructure as Code op een imperatieve manier, en niet declaratief ?
Heb je op AWS niets waarmee je je resources declaratief kunt beschrijven; a la ARM of beter nog bicep, in Azure ?

Infrastructure as Code gaat ook wel eens full-circle waar je weer lekker imperatief een declaratief config object aan het bouwen bent. Hier gebruiken we o.a. jsonnet om code te schrijven die json config opbouwd op basis van wat input. En dat is dan nog redelijk declaratief, maar we hebben ook nog wat python scripts die een hele omgeving opzetten en dat is echt puur een imperatief stappenplan aflopen met alles wat er moet gebeuren.

[CurlyMo]

Koenvh schreef op dinsdag 11 januari 2022 @ 15:29:
[...]

Hoe zou dat werken? De GPL komt daar het dichtste bij in de buurt [...]

Wat je zegt. Die licentie bestaat niet en dit zou onmogelijk te handhaven zijn. Ook vraag ik me af of het sowieso wenselijk is. Neem een project als Open Office. Het is een enorme last als je tot einde der tijden alle wijzigingen terug moet leggen in fork als die zoveel uit elkaar gegroeid zijn.

[whoami]

Mugwump schreef op dinsdag 11 januari 2022 @ 15:08:
[...]

En eigenlijk vind ik hergebruik van allerhande conditionele zaken, functies voor gestandaardiseerde naamgevingsconventies, aspects / decorators en ga zo maar door allemaal veel makkelijker in een imperatieve taal dan in declaratieve vorm.

Ik zit in de Azure hoek, en daar gebruiken ik vooralsnog bicep templates en ARM templates om resources te gaan beschrijven die ik wil gedeployed zien. Dat is declaratief, en dat vind ik net handig, want je beschrijft hoe de resource die je wil, er moet uit zien. Als je dat imperatief doet, dan moet je toch zelf altijd gaan checken: is het een nieuwe resource, of bestaat die al. Moet ik iets updaten, en zoja, wat.

[Mugwump]

whoami schreef op dinsdag 11 januari 2022 @ 16:35:
[...]

Ik zit in de Azure hoek, en daar gebruiken ik vooralsnog bicep templates en ARM templates om resources te gaan beschrijven die ik wil gedeployed zien. Dat is declaratief, en dat vind ik net handig, want je beschrijft hoe de resource die je wil, er moet uit zien. Als je dat imperatief doet, dan moet je toch zelf altijd gaan checken: is het een nieuwe resource, of bestaat die al. Moet ik iets updaten, en zoja, wat.

Ja dat moest ik misschien even nuanceren, dat hoef je hier dus niet.
Wat je feitelijk doet is als het ware stacks als objecten maken die dan als properties de verschillende resources hebben. Dat transpileert naar een declaratieve template en het deployen / diffen / updaten regelt CloudFormation gewoon voor je.

[Firesphere]

CurlyMo schreef op dinsdag 11 januari 2022 @ 15:58:
[...]

Wat je zegt. Die licentie bestaat niet en dit zou onmogelijk te handhaven zijn. Ook vraag ik me af of het sowieso wenselijk is. Neem een project als Open Office. Het is een enorme last als je tot einde der tijden alle wijzigingen terug moet leggen in fork als die zoveel uit elkaar gegroeid zijn.

De oplossing daar voor bestaat al. Namelijk, een andere license.

Het bestaan van een license die vereist dat verbeteringen etc. worden teruggestuurd naar de bron voor evaluatie of het goed is om mee te nemen in de originele code, betekend niet dat elk project deze license maar direct moet aannemen.

"Bijvoorbeeld {groot project} zou problemen krijgen" betekend dat het project de verkeerde license heeft gekozen.

[ Voor 26% gewijzigd door Firesphere op 11-01-2022 23:01 ]

[Firesphere]

Koenvh schreef op dinsdag 11 januari 2022 @ 15:29:
[...]

Hoe zou dat werken? De GPL komt daar het dichtste bij in de buurt, je publiceert je wijzigingen, en die kan de andere partij weer overnemen, maar dat is in principe ook wat ik doe. Maar als een project een style guide van tientallen pagina's heeft, tests heeft die uren moeten draaien op een setup die ik niet heb, etc. etc., formeel moet bewijzen dat het programma nog steeds eindig is met mijn wijziging, dan heb ik daar ook niet altijd zin in.

As above, dan heb je voor het betreffende project de verkeerde license gekozen.

Niet elk project heeft baat bij een dergelijke license, maar er zijn zeker projecten die er wel baat bij hebben.

Ik zeg niet dat ik het erg vind dat een project die eisen heeft, dat begrijp ik heel goed, maar het gevolg daarvan is wel dat mensen dus minder snel zullen bijdragen. En dan is het ook nog de vraag of de wijzigingen wel in lijn zijn met het originele project.

En dat is dus aan de maintainers om te beslissen, niet degene die de wijzigingen terug geeft.

[CurlyMo]

Firesphere schreef op dinsdag 11 januari 2022 @ 22:59:
[...]

De oplossing daar voor bestaat al. Namelijk, een andere license.

Oftewel, een nieuwe licentie. Want de licentie die jij beschrijft bestaat dus niet.

Het bestaan van een license die vereist dat verbeteringen etc. worden teruggestuurd naar de bron voor evaluatie of het goed is om mee te nemen in de originele code, betekend niet dat elk project deze license maar direct moet aannemen.

Het is niet echt passend bij de open source visie om dit te eisen en ik denk dat een project zich heel erg in de vingers schiet als het dat zou doen.

[Firesphere]

CurlyMo schreef op dinsdag 11 januari 2022 @ 23:04:
[...]

Oftewel, een nieuwe licentie. Want de licentie die jij beschrijft bestaat dus niet.

Nee... andersom

Jij beschrijft dat een license die terug bijdragen vereist een probleem is voor grote projecten.

Waarop ik dus zeg dat dat probleem al niet bestaat, vanwege de huidige bestaande licenses.

[...]

Het is niet echt passend bij de open source visie om dit te eisen en ik denk dat een project zich heel erg in de vingers schiet als het dat zou doen.

Het past verbazend goed in de open source visie, situaties zoals ontstaan waar een groot bedrijf een klein project volledig misbruikt voor financieel gewin, zonder de maker hier voor te bedanken, zouden dan anders opgelost worden.

Hoewel voor Elastic een dergelijke license om andere redenen weer niet handig is.

[CurlyMo]

Firesphere schreef op dinsdag 11 januari 2022 @ 23:08:
[...]

Nee... andersom

Jij beschrijft dat een license die terug bijdragen vereist een probleem is voor grote projecten.

Het punt was niet groot project, het punt was projecten die forken en vervolgens een heel eigen leven gaan leiden.

Het past verbazend goed in de open source visie, situaties zoals ontstaan waar een groot bedrijf een klein project volledig misbruikt voor financieel gewin, zonder de maker hier voor te bedanken, zouden dan anders opgelost worden.

Daar heb je de huidige licenties toch al voor? Een (weak) copyleft geeft je alle inzage in wat het grote bedrijf met jouw code doet.

De open source visie legt geen restricties op hoe open source code gebruikt mag worden. Vrije distributie en vrije aanpassing zijn niet voor niks twee kernaspecten van Open Source. Je doet nogal inbreuk op vrije aanpassing wanneer er een dwingend plicht bestaat code terug te moeten leveren.

[armageddon_2k1]

Zo, sinds kort weer eens aan de gang met Angular. Ben zelf meer een backend-oriented persoon, maar heb de afgelopen jaren veel moeten doen met React.

Maar wat een verademing is Angular toch weer. Ja, in React heb je razendsnel een MVP-tje in elkaar geragt, maar algemeen state-management vind ik voor grotere applicaties echt een drama. Context, Redux etc, het is allemaal maar .... meh.

Met Angular is het allemaal vrij 'enterprisey' met services, DI, component lifecycles etc etc, maar het werkt toch wel gewoon. Ook state-management met services + observables werkt wel een heel erg stuk fijner moet ik zeggen. En het is ook in een oogopslag duidelijk wat de bedoeling is.

[armageddon_2k1]

Ah, mijn fantastische gave om ergens een discussiegroep binnen te komen en iets te zeggen en het slaat meteen helemaal dood

[FastFox91]

@armageddon_2k1 Ik ben ook meer backender dan frontender, maar heb compleet een tegenovergestelde mening over React/Angular. In React kan je veel sneller components maken, waardoor je kleinere components maakt en daardoor leesbaarder. Geef mij maar hooks.

[Merethil]

armageddon_2k1 schreef op vrijdag 14 januari 2022 @ 08:07:
Ah, mijn fantastische gave om ergens een discussiegroep binnen te komen en iets te zeggen en het slaat meteen helemaal dood

Is dat je goede voornemen? De Devschuur coffee corner doodslaan?

armageddon_2k1 schreef op woensdag 12 januari 2022 @ 15:20:
Zo, sinds kort weer eens aan de gang met Angular. Ben zelf meer een backend-oriented persoon, maar heb de afgelopen jaren veel moeten doen met React.

Maar wat een verademing is Angular toch weer. Ja, in React heb je razendsnel een MVP-tje in elkaar geragt, maar algemeen state-management vind ik voor grotere applicaties echt een drama. Context, Redux etc, het is allemaal maar .... meh.

Met Angular is het allemaal vrij 'enterprisey' met services, DI, component lifecycles etc etc, maar het werkt toch wel gewoon. Ook state-management met services + observables werkt wel een heel erg stuk fijner moet ik zeggen. En het is ook in een oogopslag duidelijk wat de bedoeling is.

Ik was ooit begonnen met AngularJS en toen gingen ze over op Angular 2, nee Angular 3.... Nee, toch Angular 4 waarna er iets van backwards compatibility in kwam.
Eigenlijk was ik er toen helemaal klaar mee en wilde ik er niets meer van weten dus ging ik terug naar serverside HTML in elkaar plakken met Spring Boot en Freemarker templates, maar het bleef knagen.
Tijdje VueJS geprobeerd, vond ik op zich wel heel fijn werken alleen voelde het op den duur heel vreemd om maar "app"-# zoveel aan te maken voor elk elementje.

Angular weer eens geprobeerd laatst en ik was eigenlijk best tevreden over hoe snel ik up-and-running was. Het blijft alleen jammer dat je het halve internet moet binnenhengelen voor de simpelste "hello world", maar NPM he...

Ben zelf een integratieconsultant, dus ik doe eigenlijk heel weinig frontend - ik knoop liever dingen aan elkaar op een middleware. Maar de API's die wij soms moeten maken worden ook door Angular frontends gebruikt dus ik was eens benieuwd hoe makkelijk het is om deze te implementeren. Blijkbaar relatief simpel, maar zo spannend zijn onze API's ook niet.

[armageddon_2k1]

FastFox91 schreef op vrijdag 14 januari 2022 @ 08:17:
@armageddon_2k1 Ik ben ook meer backender dan frontender, maar heb compleet een tegenovergestelde mening over React/Angular. In React kan je veel sneller components maken, waardoor je kleinere components maakt en daardoor leesbaarder. Geef mij maar hooks.

Ja React is veel sneller om initieel mee te ontwikkelen, maar na een paar projecten met React gedaan te hebben, waaronder een forse backoffice applicatie en een aardige customer-facing-webapp moet ik zeggen dat ik state-management van Angular middels observables en services echt vele male beter vind dan dat matige Redux.

En na verloop van tijd heeft React meer de neiging om naar spaghetti te gaan, waar Angular je forceert om meer in een stramien te blijven. Dat laatste is soms hinderlijk, maar resulteert er wel in dat mensen sneller te onboarden zijn en men minder snel hacky buiten de lijntjes tekent.

Dat neemt niet weg dat een ervaren React-developer een nette code-base kan opzetten. Maar de instap voor React is lager, wat ervoor zorgt in mijn ervaring dat er vrij snel naieve code in de applicaties komt.

P.s., wat betreft hooks: Het is mooie techniek, maar ook hier zit de 'devil in the details'. Een simpele 'interval'-hook van meneer Abramov himself: https://overreacted.io/ma...arative-with-react-hooks/
En dan nog afgezien van de call-order die niet mag veranderen....

Als we dan kijken naar een framework dat hetzelfde doet als React, maar dan beter, dan vind ik Elm echt heel mooi. Het dwingt namelijk veel meer af dan React, maar heeft eenzelfde filosofie. Maar dan static typed en volledig functional.

[ Voor 44% gewijzigd door armageddon_2k1 op 14-01-2022 08:42 ]

[RobertMe]

armageddon_2k1 schreef op vrijdag 14 januari 2022 @ 08:36:
Dat neemt niet weg dat een ervaren React-developer een nette code-base kan opzetten. Maar de instap voor React is lager, wat ervoor zorgt in mijn ervaring dat er vrij snel naieve code in de applicaties komt.

Lets get this over with then.

spoiler:

Beetje zoals PHP dus. Makkelijk instappen, veel mediocre developers daardoor, maar ook gewoon goed in te programmeren door iemand die dat wel wil / kan.

[armageddon_2k1]

RobertMe schreef op vrijdag 14 januari 2022 @ 09:04:
[...]

Lets get this over with then.

spoiler:

Beetje zoals PHP dus. Makkelijk instappen, veel mediocre developers daardoor, maar ook gewoon goed in te programmeren door iemand die dat wel wil / kan.

Rust daarentegen...

[RagingPenguin]

RobertMe schreef op vrijdag 14 januari 2022 @ 09:04:
[...]

Lets get this over with then.

spoiler:

Beetje zoals PHP dus. Makkelijk instappen, veel mediocre developers daardoor, maar ook gewoon goed in te programmeren door iemand die dat wel wil / kan.

Als redelijk ervaren React developer en php hater ben ik het hier nog niet eens zo heel erg mee oneens, zolang het hebben over de Redux-voor-alles, 3-hooks-per-component en zero-abstractie architectuur . React is inderdaad niet heel beginners vriendelijk, maar de massieve populariteit zorgt er wel voor dat het op elk bootcamp word aangeleerd.

Wat wel een flink verschil is is dat de skill-cap van React een stuk hoger ligt dan bij PHP. Al snap je FP en reactive programming dan kan je met React hele mooie dingen maken met een abstractie niveau dat je met een OOP framework (zoals bv. Angular) nooit voor elkaar zult krijgen.

[FastFox91]

armageddon_2k1 schreef op vrijdag 14 januari 2022 @ 08:36:
[...]
Als we dan kijken naar een framework dat hetzelfde doet als React, maar dan beter, dan vind ik Elm echt heel mooi. Het dwingt namelijk veel meer af dan React, maar heeft eenzelfde filosofie. Maar dan static typed en volledig functional.

Elm Al professional kunnen gebruiken of ergens tegengekomen?

[Matis]

FastFox91 schreef op vrijdag 14 januari 2022 @ 09:21:
Elm Al professional kunnen gebruiken of ergens tegengekomen?

Ik ken Elm niet, dus kan geen antwoord geven op jouw vraag.

Maar is het niet een beetje dood? Als ik zo naar Github kijk (ik ga ervan uit dat we het over https://elm-lang.org/ hebben) dan is er de afgelopen 9 maanden niets gebeurd: https://github.com/elm/core

De laatste (bugfix) tag is al van bijna 2 jaar geleden: https://github.com/elm/core/tags

Vind je het niet doodeng om dat (professioneel) te gebruiken als framework?

[RagingPenguin]

Matis schreef op vrijdag 14 januari 2022 @ 09:44:
[...]

Ik ken Elm niet, dus kan geen antwoord geven op jouw vraag.

Maar is het niet een beetje dood? Als ik zo naar Github kijk (ik ga ervan uit dat we het over https://elm-lang.org/ hebben) dan is er de afgelopen 9 maanden niets gebeurd: https://github.com/elm/core

De laatste (bugfix) tag is al van bijna 2 jaar geleden: https://github.com/elm/core/tags

Vind je het niet doodeng om dat (professioneel) te gebruiken als framework?

Elm is inderdaad pracktisch dood, en het was nooit echt groot. Het is vooral het de architectuur die bekend was, maar verder werd de taal niet vaak gebruikt. Als je Elm zou willen gebruiken ben je beter af met React, TypeScript en fp-ts en vergeet het concept van een losse state store die je direct aan componenten bind.

[FastFox91]

Matis schreef op vrijdag 14 januari 2022 @ 09:44:
[...]

Ik ken Elm niet, dus kan geen antwoord geven op jouw vraag.

Maar is het niet een beetje dood? Als ik zo naar Github kijk (ik ga ervan uit dat we het over https://elm-lang.org/ hebben) dan is er de afgelopen 9 maanden niets gebeurd: https://github.com/elm/core

De laatste (bugfix) tag is al van bijna 2 jaar geleden: https://github.com/elm/core/tags

Vind je het niet doodeng om dat (professioneel) te gebruiken als framework?

Helaas geen professionele ervaring, maar voor een hobby project met tientallen gebruikers werkt het mega stabiel. Ik vind het ook prettig om na een aantal maanden terug te komen en dat ik niet weer allemaal packages moet updaten, conflicten, deprecated code heb etc. Het is ook nog versie 0.x.

Why is it a good thing that Elm doesn’t get frequent updates? First of all, it means your code will last a long time! It also means the language is very stable, because features are carefully thought out before being implemented.

[armageddon_2k1]

Matis schreef op vrijdag 14 januari 2022 @ 09:44:
[...]

Ik ken Elm niet, dus kan geen antwoord geven op jouw vraag.

Maar is het niet een beetje dood? Als ik zo naar Github kijk (ik ga ervan uit dat we het over https://elm-lang.org/ hebben) dan is er de afgelopen 9 maanden niets gebeurd: https://github.com/elm/core

De laatste (bugfix) tag is al van bijna 2 jaar geleden: https://github.com/elm/core/tags

Vind je het niet doodeng om dat (professioneel) te gebruiken als framework?

Volgens mij wordt het niet geupdate omdat het nagenoeg feature-complete is.
https://iselmdead.info/

[Matis]

Mja, zo zou je het natuurlijk ook kunnen benaderen.

[RagingPenguin]

armageddon_2k1 schreef op vrijdag 14 januari 2022 @ 10:07:
[...]


Volgens mij wordt het niet geupdate omdat het nagenoeg feature-complete is.
https://iselmdead.info/

'feature-complete' is gewoon een aardige manier om te zeggen 'niemand gebruikt dit meer voor nieuwe dingen, maar we houden het nog online voor legacy software'. Er zitten in die repro ook nog best een hoop issues en pr's waar niemand op reageert.

[Voutloos]

Al was het maar voor security, nieuwe problemen en countermeasures zullen eeuwig blijven komen, je code is al nooit bugvrij..
Zonder actieve security fixes of vooruitgang is een project gewoon dood.

[Janoz]

Als het werkelijk zo 'feature-complete' is had ik op z'n minst een v1.x verwacht ipv een v0.x. Ik ga mijn tijd iig niet in Elm steken, laat staan dat ik het in een pro omgeving überhaupt voor zou stellen.

[ElkeBxl]

armageddon_2k1 schreef op woensdag 12 januari 2022 @ 15:20:
Ja, in React heb je razendsnel een MVP-tje in elkaar geragt, maar algemeen state-management vind ik voor grotere applicaties echt een drama. Context, Redux etc, het is allemaal maar .... meh.

Met Angular is het allemaal vrij 'enterprisey' met services, DI, component lifecycles etc etc, maar het werkt toch wel gewoon. Ook state-management met services + observables werkt wel een heel erg stuk fijner moet ik zeggen. En het is ook in een oogopslag duidelijk wat de bedoeling is.

Allemaal redenen waarom ik vaak die vergelijkingen tussen Angular/React/Vue/... niet altijd zo zinvol vind. Ja je kan er hetzelfde mee maken maar ze zijn allemaal wel wat beter in bepaalde toepassingsdomeinen. Ik ben zelf fulltime Vue dev maar voor de grotere enterprise apps zou ik zeker kijken naar Angular en voor iets zoals een kleine blog of MVP ofzo zou ik ook naar React kijken.

Angular vond ik fantastisch om mee te werken toen ik veel met streams bezig moest zijn en data moest combineren. Data uit meerdere REST endpoints, data die uit websockets kwam, data die userinput was, ... Dan is het zo handig om alles op observables te pipen om het op 1 scherm te kunnen tonen zonder dat ik me zorgen hoefde te maken waar die data vandaan kwam en hoe die tot stand kwam.

Vue was voor mij een verademing om mee te werken in een context waar Angular veel te bulky aanvoelde. Eenvoudige component trees maken, geen nood om met observables bezig te zijn voor wat meer basic reactieve data, composition API die voor mooie abstracties kan zorgen, options API die components schrijven super basic houdt, ... Er wordt veel minder het handje vastgehouden, wat ik fantastisch vind. Maar in een organisatie waar er meer structuur en uniformiteit nodig is over meerdere codebases kan ik me wel voorstellen dat zoiets ongewenst is.

Merethil schreef op vrijdag 14 januari 2022 @ 08:21:
[...]
Tijdje VueJS geprobeerd, vond ik op zich wel heel fijn werken alleen voelde het op den duur heel vreemd om maar "app"-# zoveel aan te maken voor elk elementje.

Huh? Die snap ik niet Enige keer dat ik een "app" moest aanmaken in Vue was altijd bij het opstarten van het project wat de Vue CLI voor mij deed. Buiten eens het toevoegen van een plugin moest ik nooit meer aan de App component komen. Of je hebt het misschien over iets anders dan wat ik denk?

RagingPenguin schreef op vrijdag 14 januari 2022 @ 09:49:
[...]


Elm is inderdaad pracktisch dood, en het was nooit echt groot. Het is vooral het de architectuur die bekend was, maar verder werd de taal niet vaak gebruikt.

Ik ken niemand die Elm vaak gebruikt. Ooit eens een namiddagje workshop over gehad 3 jaar geleden ofzo, ik ben er al alles over vergeten Nu heb ik er vooral de tijd niet meer voor om er nog eens deftig naar te kijken. Het feit dat ik het nooit professioneel nodig heb, helpt niet om zelfs de goesting te hebben ernaar te kijken.

[Merethil]

ElkeBxl schreef op vrijdag 14 januari 2022 @ 11:25:

[...]

Huh? Die snap ik niet Enige keer dat ik een "app" moest aanmaken in Vue was altijd bij het opstarten van het project wat de Vue CLI voor mij deed. Buiten eens het toevoegen van een plugin moest ik nooit meer aan de App component komen. Of je hebt het misschien over iets anders dan wat ik denk?

Ik doelde hierop (uit hun examples, je kan er zelf natuurlijk nuttigere namen aan geven maar... Moeite ):

code:

var app = new Vue({
  el: '#app',
  data: {
    message: 'Hello Vue!'
  }
})

var app2 = new Vue({
  el: '#app-2',
  data: {
    message: 'You loaded this page on ' + new Date().toLocaleString()
  }
})

var app3 = new Vue({
  el: '#app-3',
  data: {
    seen: true
  }
})

var app4 = new Vue({
  el: '#app-4',
  data: {
    todos: [
      { text: 'Learn JavaScript' },
      { text: 'Learn Vue' },
      { text: 'Build something awesome' }
    ]
  }
})

Oftewel: alles wordt een Vue-object met z'n eigen state en logica. Ik kon het niet helemaal goed in m'n hoofd krijgen waarom ik dit nou zou doen, en hoe ik nou lekker dingen hergebruik. Maar ik ben dan ook een frontender van niks Ik houd me liever gewoon bezig met data op de juiste (en meest efficiënte) manier verplaatsen van A naar B (en C, en D, en.... Ja.)

[gekkie]

Merethil schreef op vrijdag 14 januari 2022 @ 08:21:
[...]
Is dat je goede voornemen? De Devschuur coffee corner doodslaan?

Ik doe gelukkig niet aan cappuccino, een gewoon bakkie pleur kun je moeilijk nog doodslaan.
Maar goed @armageddon_2k1 moet dus wel wegblijven van de Borrel, dood bier, ugh.

[RagingPenguin]

Merethil schreef op vrijdag 14 januari 2022 @ 11:33:
[...]


Ik doelde hierop (uit hun examples, je kan er zelf natuurlijk nuttigere namen aan geven maar... Moeite ):

code:

var app = new Vue({
  el: '#app',
  data: {
    message: 'Hello Vue!'
  }
})

var app2 = new Vue({
  el: '#app-2',
  data: {
    message: 'You loaded this page on ' + new Date().toLocaleString()
  }
})

var app3 = new Vue({
  el: '#app-3',
  data: {
    seen: true
  }
})

var app4 = new Vue({
  el: '#app-4',
  data: {
    todos: [
      { text: 'Learn JavaScript' },
      { text: 'Learn Vue' },
      { text: 'Build something awesome' }
    ]
  }
})

Oftewel: alles wordt een Vue-object met z'n eigen state en logica. Ik kon het niet helemaal goed in m'n hoofd krijgen waarom ik dit nou zou doen, en hoe ik nou lekker dingen hergebruik. Maar ik ben dan ook een frontender van niks Ik houd me liever gewoon bezig met data op de juiste (en meest efficiënte) manier verplaatsen van A naar B (en C, en D, en.... Ja.)

Nu ben ik niet zo thuis in Vuejs, maar is dat niet een stuk beter als je .vue bestanden gebruikt? Maar goed, dit is ook een van redenen dat ik liever React gebruik. Zo'n 95% van je React code zal uit gewone JS functies bestaan die niets anders doen dan wat JSX returnen.

[OverloadOfRed]

Merethil schreef op vrijdag 14 januari 2022 @ 11:33:
[...]


Ik doelde hierop (uit hun examples, je kan er zelf natuurlijk nuttigere namen aan geven maar... Moeite ):

code:

var app = new Vue({
  el: '#app',
  data: {
    message: 'Hello Vue!'
  }
})

var app2 = new Vue({
  el: '#app-2',
  data: {
    message: 'You loaded this page on ' + new Date().toLocaleString()
  }
})

var app3 = new Vue({
  el: '#app-3',
  data: {
    seen: true
  }
})

var app4 = new Vue({
  el: '#app-4',
  data: {
    todos: [
      { text: 'Learn JavaScript' },
      { text: 'Learn Vue' },
      { text: 'Build something awesome' }
    ]
  }
})

Oftewel: alles wordt een Vue-object met z'n eigen state en logica. Ik kon het niet helemaal goed in m'n hoofd krijgen waarom ik dit nou zou doen, en hoe ik nou lekker dingen hergebruik. Maar ik ben dan ook een frontender van niks Ik houd me liever gewoon bezig met data op de juiste (en meest efficiënte) manier verplaatsen van A naar B (en C, en D, en.... Ja.)

Huh, waarom zou je in 1 bestand 4 apps aanmaken? Lijkt er zelfs op dat het pagina's zijn, dat kan sws beter met Vue router

Ik vond onze setup al vreemd dat we in 1 applicatie 3 dikke Vue apps hebben draaien, maar dit is weer een stapje 'erger' imo

[Merethil]

OverloadOfRed schreef op vrijdag 14 januari 2022 @ 15:20:
[...]


Huh, waarom zou je in 1 bestand 4 apps aanmaken? Lijkt er zelfs op dat het pagina's zijn, dat kan sws beter met Vue router

Ik vond onze setup al vreemd dat we in 1 applicatie 3 dikke Vue apps hebben draaien, maar dit is weer een stapje 'erger' imo

Tja, misschien snapte ik gewoon niet goed hoe je in één app meerdere elementen los kon inladen/veranderen/watchen etc? Ik volgde gewoon de tutorial op de vuejs website, maar die is niet heel duidelijk

[OverloadOfRed]

Merethil schreef op vrijdag 14 januari 2022 @ 15:21:
[...]


Tja, misschien snapte ik gewoon niet goed hoe je in één app meerdere elementen los kon inladen/veranderen/watchen etc? Ik volgde gewoon de tutorial op de vuejs website, maar die is niet heel duidelijk

Hm ik kijk nu inderdaad naar de docs voor Vue 2 en daar zie ik inderdaad meerdere app elementen... weird!
Ik heb de tutorials op de vue docs nooit doorgenomen, heb het geleerd met VueMastery tutorials

[SH4D3H]

RagingPenguin schreef op vrijdag 14 januari 2022 @ 13:28:
[...]
Maar goed, dit is ook een van redenen dat ik liever React gebruik. Zo'n 95% van je React code zal uit gewone JS functies bestaan die niets anders doen dan wat JSX returnen.

In Vue kan dat ook. Al zal je daar dan eerder gewoon een waarde returnen (ipv JSX) die dan weer in de template gebruikt kan worden. En in Vue 3 met de composition API lijkt Vue ook weer wat meer op React (met Hooks).

[ElkeBxl]

Merethil schreef op vrijdag 14 januari 2022 @ 11:33:
[...]
Oftewel: alles wordt een Vue-object met z'n eigen state en logica. Ik kon het niet helemaal goed in m'n hoofd krijgen waarom ik dit nou zou doen, en hoe ik nou lekker dingen hergebruik. Maar ik ben dan ook een frontender van niks Ik houd me liever gewoon bezig met data op de juiste (en meest efficiënte) manier verplaatsen van A naar B (en C, en D, en.... Ja.)

Nog nooit zo'n code zelf geschreven. Zoals de rest hier zegt, inderdaad met 1 .vue bestand per component werken en dan gebeuren zo'n dingen automatisch op de achtergrond. Kan je per file en dus per component mooi je template, script en style hebben. Geen idee waarom ze het met de docs zo uitleggen. Tenzij je ergens een kleine Vue instance wil hebben in ander framework kan ik me nog wel voorstellen dat je zelf eens "new Vue(...)" zit te schrijven. Maar lijkt me niet dat meeste Vue gebruikers zo gaan werken. Meesten gaan de gegenereerde code van de Vue CLI gebruiken met dus hun App component als root van hun component tree.

OverloadOfRed schreef op vrijdag 14 januari 2022 @ 15:20:
[...]
Ik vond onze setup al vreemd dat we in 1 applicatie 3 dikke Vue apps hebben draaien, maar dit is weer een stapje 'erger' imo

Whut? Why? Nu ben ik echt curieus wat daar de reden achter is

Ik zit zelf wel met speciale situatie dat 1 codebase gebruikt wordt voor 5 websites te maken dus ik zit zelf wel met 5 App components maar die hun component tree is voor 80% gescheiden, en de overige 20% is een kleine chunk aan "shared" componenten die generiek zijn door middel van slots en dergelijke. Altijd leuk bij het deployen van een fix die vaak impact heeft op 5 websites, zijn dan direct 5 deploys tegelijk. Kwestie van het deployment team bezig te houden

[Merethil]

ElkeBxl schreef op vrijdag 14 januari 2022 @ 15:52:
[...]

Nog nooit zo'n code zelf geschreven. Zoals de rest hier zegt, inderdaad met 1 .vue bestand per component werken en dan gebeuren zo'n dingen automatisch op de achtergrond. Kan je per file en dus per component mooi je template, script en style hebben. Geen idee waarom ze het met de docs zo uitleggen. Tenzij je ergens een kleine Vue instance wil hebben in ander framework kan ik me nog wel voorstellen dat je zelf eens "new Vue(...)" zit te schrijven. Maar lijkt me niet dat meeste Vue gebruikers zo gaan werken. Meesten gaan de gegenereerde code van de Vue CLI gebruiken met dus hun App component als root van hun component tree.

Het zal wel te maken hebben met of je een SPA via de Vue CLI maakt, of dat je VueJS als een soort jquery overal inhangt en gewoon mee aan de slag gaat. Ik deed dat laatste, en nu ik het zo lees lijkt het erop dat de docs inderdaad dat gebruik dus ook voordoen. Bijzonder, ik zou denken dat ze net als Angular/React/etc. gewoon de SPA-route zouden gebruiken in hun documentatie.

[OverloadOfRed]

ElkeBxl schreef op vrijdag 14 januari 2022 @ 15:52:

[...]

Whut? Why? Nu ben ik echt curieus wat daar de reden achter is

Ik zit zelf wel met speciale situatie dat 1 codebase gebruikt wordt voor 5 websites te maken dus ik zit zelf wel met 5 App components maar die hun component tree is voor 80% gescheiden, en de overige 20% is een kleine chunk aan "shared" componenten die generiek zijn door middel van slots en dergelijke. Altijd leuk bij het deployen van een fix die vaak impact heeft op 5 websites, zijn dan direct 5 deploys tegelijk. Kwestie van het deployment team bezig te houden

Meerdere redenen, maar belangrijkste toch wel ervaring met Vue en frontend werk uberhaupt.
't is een PHP omgeving met brakke code die stuk voor stuk vervangen wordt.
Het leek de (alleen maar junior) developers destijds het best om 2 apps te maken.

In principe is alles opgebouwd uit components dus we zouden het wel kunnen combineren, maar als de keuze ligt tussen ouwe troep ombouwen naar nieuw, of het 'nieuw' verbeteren wint de eerste altijd

[Koenvh]

Zijn we ondertussen alweer bij Vue 2?
* Koenvh houdt het allemaal niet meer bij wat er op webfront-endgebied gebeurt.

Ik ben afgelopen weekend bezig geweest met HTML en wkhtmltopdf voor het typesetten van een PDF die nu gedrukt wordt. Lekker analoog

[scosec]

Koenvh schreef op vrijdag 14 januari 2022 @ 16:37:
Zijn we ondertussen alweer bij Vue 2?
* Koenvh houdt het allemaal niet meer bij wat er op webfront-endgebied gebeurt.

Ik ben afgelopen weekend bezig geweest met HTML en wkhtmltopdf voor het typesetten van een PDF die nu gedrukt wordt. Lekker analoog

3

Ps ken je Google puppeteer? Verademing ten opzichte van wkhtmltopdf

[Koenvh]

scosec schreef op vrijdag 14 januari 2022 @ 21:13:
[...]


3

Ps ken je Google puppeteer? Verademing ten opzichte van wkhtmltopdf

Nee, ken ik niet. Ik was eigenlijk vooral op zoek naar een manier om paginanummers toe te voegen aan de PDF (blijkbaar kan dat niet met CSS, valt me tegen), en toen stuitte ik op wkhtmltopdf

De laatste keer toen ik naar Vue keek was 1.0 nog net niet uit geloof ik, en zo lang geleden kan dat niet geweest zijn... Oh, 2015

[ Voor 15% gewijzigd door Koenvh op 14-01-2022 23:53 ]

[armageddon_2k1]

Puppeteer FTW. Heb een Puppeteer service draaien in K8 welke m’n PDF’s rendert. Mooie is dat ik nu dus hele complexe PDF’s kan maken, indien het maar gewoon in HTML er goed uitziet. Middels JS eventueel dingen rechtzetten na DOM rendering.

[Koenvh]

armageddon_2k1 schreef op zaterdag 15 januari 2022 @ 08:58:
Puppeteer FTW. Heb een Puppeteer service draaien in K8 welke m’n PDF’s rendert. Mooie is dat ik nu dus hele complexe PDF’s kan maken, indien het maar gewoon in HTML er goed uitziet. Middels JS eventueel dingen rechtzetten na DOM rendering.

Ja, dat doe ik dus ook grotendeels met wkhtmltopdf (min dat JS gedeelte, hoewel dat ook werkt geloof ik). Ik gebruikte eerst gewoon de Chrome print als PDF optie (het is voor één boekje), maar daar kun je dus geen paginanummers of inhoudsopgave toevoegen. Met ruim 500 pagina's is dat wel onhandig.

[armageddon_2k1]

Nee daarom bouw ik het dus ook gewoon op in de browser met print styles. Dat werkt prima. Wij hadden rapporten met SVGs die over meerdere pagina’s verdeeld moesten worden met metadata ernaast. En die SVGs moesten dan aangepast worden aan de hoogte van de metadata ernaast. Met vanillaJS, wat slimme CSS en puppeteer een “eitje”.

Wel opletten dat je “fontsize hinting” uitzet als je boundingRect enzo gaat uitlezen… dat zorgt dat er wat pixels anders berekent worden……

[ Voor 18% gewijzigd door armageddon_2k1 op 15-01-2022 17:10 ]

[Immutable]

armageddon_2k1 schreef op zaterdag 15 januari 2022 @ 17:09:
Nee daarom bouw ik het dus ook gewoon op in de browser met print styles. Dat werkt prima. Wij hadden rapporten met SVGs die over meerdere pagina’s verdeeld moesten worden met metadata ernaast. En die SVGs moesten dan aangepast worden aan de hoogte van de metadata ernaast. Met vanillaJS, wat slimme CSS en puppeteer een “eitje”.

Wel opletten dat je “fontsize hinting” uitzet als je boundingRect enzo gaat uitlezen… dat zorgt dat er wat pixels anders berekent worden……

Ja Vanilla JS is wel echt een kicke front-end framework/library http://vanilla-js.com/

Zelf denk ik toch echt dat het hele front-end naar webassembly gaat met daarboven op frameworks gebaseerd in JOU favoriete taal + Browser API's. (En een framework in jou favoriete taal)

C# -> Blazor (Nu met .NET 6 werkt het eindelijk wel fatsoenlijk. Inclusief DLL's op je front-end. )
Rust -> Yew / Dioxus(https://dioxuslabs.com/) (ben ik stiekem wel fan van..)
En ga zo maar door.. (Alles wat een webassembly output heeft op de compiler)

[Ghehe]

[Twitter: https://twitter.com/DennisCode/status/1474187999336304649?s=20]

Anyway, tijd voor (nog) een bakje troost op deze sombere maandagochtend

[Caelorum]

Immutable schreef op maandag 17 januari 2022 @ 09:27:
[...]
Zelf denk ik toch echt dat het hele front-end naar webassembly gaat met daarboven op frameworks gebaseerd in JOU favoriete taal + Browser API's. (En een framework in jou favoriete taal)

C# -> Blazor (Nu met .NET 6 werkt het eindelijk wel fatsoenlijk. Inclusief DLL's op je front-end. )[...]

Je denkt te klein. Kijk maar eens naar iets als Bolero. Er gaan gewoon weer frameworks op frameworks worden gebouwd

[Alex)]

Zijn er hier eigenlijk mensen die iets doen met Blazor?

[gekkie]

* gekkie weet van toeten noch Blazor

[DevWouter]

Alex) schreef op maandag 17 januari 2022 @ 12:29:
Zijn er hier eigenlijk mensen die iets doen met Blazor?

Nope, maar ik beweeg ook makkelijk tussen de verschillende libraries en frameworks.
Bovendien vind ik het erg onduidelijk welk probleem blazor eigenlijk wilt oplossen. De oorspronkelijk inzet vond ik goed, maar over tijd is het een soort alternatief voor Angular geworden.

[Cloud]

Alex) schreef op maandag 17 januari 2022 @ 12:29:
Zijn er hier eigenlijk mensen die iets doen met Blazor?

Ik gebruik het voor website die intern draait om wat lichtgewicht home automation mee te doen. Dan heb ik één plek waar ik informatie over mijn zonnepanelen kan zien, komende weersinformatie, mijn zonwering kan bedienen, en zo nog wat. Verder draaien er wat services op de achtergrond voor polling van andere devices en dergelijke. Ook fungeert de app als proxy voor de zonnepanelen. Mijn omvormer stuurt bijvoorbeeld zijn api calls naar mijn app. Die breidt vervolgens de request uit met informatie verkregen vanuit andere devices en forward deze daarna naar PVOutput. Visueel stelt het weinig voor: het is puur de basis template (hello world met counter) alleen dan uitgebreid met mijn eigen pages en dingen.

Ik ben geen webdeveloper maar het was wel érg makkelijk om draaiend te krijgen. Ik wil verre van alles met Javascript blijven en ook geen zoektocht doen naar welk framework nu weer het meest praktisch was. Ik kan het niet bijhouden en wil ik eigenlijk ook niet (nul ambitie op webdevelopment vlak). TypeScript zou dan nog okay zijn als taal maar afgezien hiervan heb ik het nergens voor nodig. Toen Blazor uitkwam stond dat mij toe om vrijwel alles met C# te doen afgezien van wat verdwaalde <html> tags. Hoefde maar een heel klein beetje syntax te leren voor het render-specifieke deel maar dat was peanuts

DevWouter schreef op maandag 17 januari 2022 @ 13:14:
[...]
Bovendien vind ik het erg onduidelijk welk probleem blazor eigenlijk wilt oplossen.

Ik zit niet echt in het wereldje, maar voor mij loste Blazor een heel duidelijk probleem op: alles in één taal (geen JS). Voor mij persoonlijk komt front-end development daarmee een stuk dichterbij backend development. Er zullen vast meer frameworks zijn die dat doen, maar het feit dat ik alles met C# kan doen was voor mij het meest belangrijk. Dat maakte mij in elk geval enthousiast. Ik kan me voorstellen dat dat feit voor mensen doorslaggevend kan zijn

[ Voor 19% gewijzigd door Cloud op 17-01-2022 13:29 ]

[Evilbee]

Alex) schreef op maandag 17 januari 2022 @ 12:29:
Zijn er hier eigenlijk mensen die iets doen met Blazor?

Wij gebruiken het als een simulatie tool om met een paar simpele knoppen berichten naar onze applicatie te sturen. De applicatie is een combinatie van een dotnet5 backend en Angular frontend.

[DevWouter]

Cloud schreef op maandag 17 januari 2022 @ 13:20:
[...]

Ik zit niet echt in het wereldje, maar voor mij loste Blazor een heel duidelijk probleem op: alles in één taal (geen JS). Voor mij persoonlijk komt front-end development daarmee een stuk dichterbij backend development. Er zullen vast meer frameworks zijn die dat doen, maar het feit dat ik alles met C# kan doen was voor mij het meest belangrijk. Dat maakte mij in elk geval enthousiast. Ik kan me voorstellen dat dat feit voor mensen doorslaggevend kan zijn

Iets met hamers en schroeven

Het oorspronkelijke idee achter Blazor was een emulatielaag in je browser zodat je dotnet in je browser draaide, maar inmiddels is de focus vooral backend technologie geworden met een frontend als thin client.

Blijkbaar moest de technolgie een product worden.

[Sebazzz]

Alex) schreef op maandag 17 januari 2022 @ 12:29:
Zijn er hier eigenlijk mensen die iets doen met Blazor?

Ja, we maken al onze nieuwe applicaties in Blazor. Het bevalt enorm

[Cloud]

DevWouter schreef op maandag 17 januari 2022 @ 14:43:
[...]
Het oorspronkelijke idee achter Blazor was een emulatielaag in je browser zodat je dotnet in je browser draaide, maar inmiddels is de focus vooral backend technologie geworden met een frontend als thin client.

Huh? Misschien begrijp ik je verkeerd maar volgens mij was dat niet de bedoeling van Blazor hoor. De backend technologie was er grotendeels al (Razor Pages) en de rest is nog steeds gewoon ASP.Net Core.

De intentie van Blazor was volgens mij het toevoegen van interactiviteit aan dat bestaande pakket, maar dan met puur C#. Initieel volgde daaruit dan Blazor Server die middels React (dacht ik) partial updates aan een pagina kon doen. In een iets later stadium kwam daar Blazor WebAssembly bij die het nog verder naar de browser bracht, maar dat zou ik geen emulatie noemen

[Sebazzz]

Cloud schreef op maandag 17 januari 2022 @ 15:33:
[...]

Initieel volgde daaruit dan Blazor Server die middels React

Nee, het gebruikt een virtual DOM, net zoals React. Voor de rest is er niets gelijk