De Devschuur Coffee Corner - Iteratie ⓬

[Lethalis]

Sandor_Clegane schreef op maandag 28 oktober 2019 @ 12:02:
[...]
Model View Update is vele malen simpeler.

Waarom is Model View Update in jouw ogen simpeler dan Model View Presenter? Zeker in de door mij aangehaalde use case (Windows Forms development).

Als ik het goed begrijp, heb je bij MVU een Update functie die een nieuwe Model produceert (op basis van het oude Model en een request Message), die vervolgens wordt gerenderd met een View functie.

Hierbij is de Update functie dan goed testbaar, omdat hij altijd op basis van zijn inputs een bepaalde output produceert, waarbij je uitgaat van immutability en dus altijd het oude Model met het nieuwe Model kunt vergelijken na de transformatie.

Om dit goed te laten werken, heb je echter een framework nodig dat voorziet in de plumbing van het geheel. Dus je hebt tooling die jou helpt om een View te renderen bijvoorbeeld, en tooling die de request routing doet zodat je een Message / Model kunt geven aan de Update functie. Wat in Elm zeg maar de Runtime doet, om de Model, View en Update functies aan elkaar te knopen.

Zeg maar precies de taken die een Presenter als mediator heeft in het MVP pattern

Met het grote verschil natuurlijk dat er bij MVP van mutable state wordt uitgegaan.

[Ed Vertijsment]

Lethalis schreef op dinsdag 29 oktober 2019 @ 09:29:
[...]

Waarom is Model View Update in jouw ogen simpeler dan Model View Presenter? Zeker in de door mij aangehaalde use case (Windows Forms development).

Als ik het goed begrijp, heb je bij MVU een Update functie die een nieuwe Model produceert (op basis van het oude Model en een request Message), die vervolgens wordt gerenderd met een View functie.

Hierbij is de Update functie dan goed testbaar, omdat hij altijd op basis van zijn inputs een bepaalde output produceert, waarbij je uitgaat van immutability en dus altijd het oude Model met het nieuwe Model kunt vergelijken na de transformatie.

Om dit goed te laten werken, heb je echter een framework nodig dat voorziet in de plumbing van het geheel. Dus je hebt tooling die jou helpt om een View te renderen bijvoorbeeld, en tooling die de request routing doet zodat je een Message / Model kunt geven aan de Update functie. Wat in Elm zeg maar de Runtime doet, om de Model, View en Update functies aan elkaar te knopen.

Zeg maar precies de taken die een Presenter als mediator heeft in het MVP pattern

Met het grote verschil natuurlijk dat er bij MVP van mutable state wordt uitgegaan.

Ik kan dit enkel vergelijken met hoe dit in React werkt maar dis het vrij simpel. Een component (view) wordt gerendered op basis van een specifieke context (props). Die wordt (deels) gegenereerd door een reducer op basis van de huidige context en een actie (taak + payload). De hele reducer is gewoon een pure functie. En het component heeft helemaal geen state nodig. Lijkt mij, als jet trucje eenmaal door hebt, vrij simpel.

[Lethalis]

Ed Vertijsment schreef op dinsdag 29 oktober 2019 @ 11:57:
[...]


Ik kan dit enkel vergelijken met hoe dit in React werkt maar dis het vrij simpel. Een component (view) wordt gerendered op basis van een specifieke context (props). Die wordt (deels) gegenereerd door een reducer op basis van de huidige context en een actie (taak + payload). De hele reducer is gewoon een pure functie. En het component heeft helemaal geen state nodig. Lijkt mij, als jet trucje eenmaal door hebt, vrij simpel.

Ja, maar mijn punt is dus dat er een groot verschil tussen frontend web development en Windows Forms development zit, omdat frameworks als React bijvoorbeeld een virtual DOM hebben. Dus ondanks dat elke keer een nieuw component wordt gerenderd, past React voor jou de DOM in de browser aan (die wel stateful is, al is het alleen maar om performance redenen).

Bij Windows Forms heb je dat niet en moet je zelf de controls opbouwen / aanpassen. En omdat je dit dus toch al zelf moet doen, kun je net zo goed een Presenter daarvoor gebruiken.

[Matis]

Oei:

quote: https://lab.wallarm.com/p...-real-world-ctf-exercise/

PHP Remote Code Execution 0-Day Discovered in Real World CTF Exercise

Wij draaien gelukkig Apache als webserver, dus hebben er geen last van

[Voutloos]

Vast wel fijn, om na 10jr lang te horen dat Nginx beter is toch een pluspuntje voor Apache te ontdekken.

[ThomasG]

Matis schreef op dinsdag 29 oktober 2019 @ 12:13:
Oei:

[...]


Wij draaien gelukkig Apache als webserver, dus hebben er geen last van

Nee, met Apache heb je lat van 1000 en 1 andere problemen

[AW_Bos]

Op een forum die ik beheer kwam een interessant vraagje, waar zowel de ontdekker als ikzelf niet uitkom.
Wie snapt dit?

PHP:

<?php
$a = array(1,2,3,4,5,6);
foreach ($a as &$b) {
 $b *=2;
}

foreach ($a as $b) {
 echo $b .PHP_EOL;
} 
?>

De output is:
2
4
6
8
10
10

De verwachtte output is
2
4
6
8
10
12

Waarom is er twee keer een 10 achterelkaar, en niet op een volgend, zoals 10 en 12?

[AW_Bos]

Matis schreef op dinsdag 29 oktober 2019 @ 12:13:
Oei:

[...]


Wij draaien gelukkig Apache als webserver, dus hebben er geen last van

Heb ook maar wat servertjes geüpdated die Nginx gebruikten.
Maar ook met PHP in CGI-mode was er in 2012 een lek gevonden, best een kwalijke waarmee je de source kon bekijken. Daarom.... Gooi belangrijke bestanden buiten de webroot.

Het gaf mij toen wel inspiratie voor een fake-parameter die een fictieve code van mijn site liet zien, alsof alles exploited was .

[ Voor 20% gewijzigd door AW_Bos op 29-10-2019 16:09 ]

[DJ Henk]

AW_Bos schreef op dinsdag 29 oktober 2019 @ 16:03:
Op een forum die ik beheer kwam een interessant vraagje, waar zowel de ontdekker als ikzelf niet uitkom.
Wie snapt dit?

..

Waarom is er twee keer een 10 achterelkaar, en niet op een volgend, zoals 10 en 12?

Of het een echt antwoord is weet ik niet, maar ik kwam laatst deze tegen: https://stackoverflow.com...php-foreach-actually-work

Er gebeurt een hoop onder de motorkap wat je misschien niet verwacht.

[.oisyn]

AW_Bos schreef op dinsdag 29 oktober 2019 @ 16:03:
Op een forum die ik beheer kwam een interessant vraagje, waar zowel de ontdekker als ikzelf niet uitkom.
Wie snapt dit?

Dit is toch hét klassieke "PHP bad, m'kay" voorbeeld?

$b blijft een referentie naar het laatste element uit de eerste loop.

[AW_Bos]

.oisyn schreef op dinsdag 29 oktober 2019 @ 16:13:
[...]

Dit is toch hét klassieke "PHP bad, m'kay" voorbeeld?

$b blijft een referentie naar het laatste element uit de eerste loop.

Maar kan je er ook om heen zeilen?
En ja, ik ben bekend dat met bepaalde berekeningen erg vaag kan doen

[ Voor 11% gewijzigd door AW_Bos op 29-10-2019 16:14 ]

[Matis]

AW_Bos schreef op dinsdag 29 oktober 2019 @ 16:03:
Op een forum die ik beheer kwam een interessant vraagje, waar zowel de ontdekker als ikzelf niet uitkom.
Wie snapt dit?

PHP:

<?php
$a = array(1,2,3,4,5,6);
foreach ($a as &$b) {
 $b *=2;
}

foreach ($a as $b) {
 echo $b .PHP_EOL;
} 
?>

De output is:
2
4
6
8
10
10

De verwachtte output is
2
4
6
8
10
12

Waarom is er twee keer een 10 achterelkaar, en niet op een volgend, zoals 10 en 12?

De VLD opcodes zijn als volgt:

code:

Finding entry points
Branch analysis from position: 0
2 jumps found. (Code = 125) Position 1 = 2, Position 2 = 5
Branch analysis from position: 2
2 jumps found. (Code = 126) Position 1 = 3, Position 2 = 5
Branch analysis from position: 3
1 jumps found. (Code = 42) Position 1 = 2
Branch analysis from position: 2
Branch analysis from position: 5
2 jumps found. (Code = 77) Position 1 = 7, Position 2 = 11
Branch analysis from position: 7
2 jumps found. (Code = 78) Position 1 = 8, Position 2 = 11
Branch analysis from position: 8
1 jumps found. (Code = 42) Position 1 = 7
Branch analysis from position: 7
Branch analysis from position: 11
1 jumps found. (Code = 62) Position 1 = -2
Branch analysis from position: 11
Branch analysis from position: 5
filename:       /in/8sI2T
function name:  (null)
number of ops:  13
compiled vars:  !0 = $a, !1 = $b
line     #* E I O op                           fetch          ext  return  operands
-------------------------------------------------------------------------------------
   2     0  E >   ASSIGN                                                   !0, <array>
   3     1      > FE_RESET_RW                                      $3      !0, ->5
         2    > > FE_FETCH_RW                                              $3, !1, ->5
   4     3    >   ASSIGN_MUL                                    0          !1, 2
         4      > JMP                                                      ->2
         5    >   FE_FREE                                                  $3
   7     6      > FE_RESET_R                                       $5      !0, ->11
         7    > > FE_FETCH_R                                               $5, !1, ->11
   8     8    >   CONCAT                                           ~6      !1, '%0A'
         9        ECHO                                                     ~6
        10      > JMP                                                      ->7
        11    >   FE_FREE                                                  $5
   9    12      > RETURN                                                   1

[Mugwump]

AW_Bos schreef op dinsdag 29 oktober 2019 @ 16:03:
Op een forum die ik beheer kwam een interessant vraagje, waar zowel de ontdekker als ikzelf niet uitkom.
Wie snapt dit?

PHP:

<?php
$a = array(1,2,3,4,5,6);
foreach ($a as &$b) {
 $b *=2;
}

foreach ($a as $b) {
 echo $b .PHP_EOL;
} 
?>

De output is:
2
4
6
8
10
10

De verwachtte output is
2
4
6
8
10
12

Waarom is er twee keer een 10 achterelkaar, en niet op een volgend, zoals 10 en 12?

code:

$a = array(1,2,3,4,5,6);
foreach ($a as &$b) {
 $b *= 2;
}

unset($b);

foreach ($a as $b) {
 echo $b .PHP_EOL;
}

Dit werkt wel. Welkom in de wondere wereld van scoping.

[bauke1994]

Even in psysh gegooid, het wordt er niet minder vreemd om:

PHP:

>>> $a = [1, 2, 3, 4, 5, 6];
=> [
     1,
     2,
     3,
     4,
     5,
     6,
   ]
>>> foreach ($a as &$b) {
$b *=2;
}
>>> $a;
=> [
     2,
     4,
     6,
     8,
     10,
     12,
   ]
>>> foreach ($a as $b) {
echo $b .PHP_EOL;
}
2
4
6
8
10
10
>>> $a;
=> [
     2,
     4,
     6,
     8,
     10,
     10,
   ]

[ Voor 43% gewijzigd door bauke1994 op 29-10-2019 16:24 ]

[.oisyn]

AW_Bos schreef op dinsdag 29 oktober 2019 @ 16:14:
[...]

Maar kan je er ook om heen zeilen?

.edit: oh wacht ik draaide "kan" en "je" om in mijn hoofd en zag het vraagteken niet

Ja, door een unset($b) te doen na de loop

[ Voor 27% gewijzigd door .oisyn op 29-10-2019 16:19 ]

[AW_Bos]

.oisyn schreef op dinsdag 29 oktober 2019 @ 16:17:
[...]

Wat is je punt?

Nee, heb het al...
Met die unset() zou het wel goed moeten werken.
Thanks to @Mugwump .

Zat me al te staren op de fout, net als de vraagsteller die ermee kwam.

[Mugwump]

Ik vind het echt een bizar fenomeen, dat gebrek aan block scopes. Zelfs als je niet met een reference werkt, maar gewoon iets doms als dit doet:

PHP:

$a = array(1,2,3,4,5,6);
foreach ($a as $b) {
 $b *= 2;
}

echo $b;

Dan spuugt ie dus 12 uit.

Ik ken geen andere C based taal die de variabele $b hier buiten de loop laat bestaan zo uit m'n hoofd. Dat levert ook dit soort verwarrende zaken op.

[.oisyn]

Mugwump schreef op dinsdag 29 oktober 2019 @ 16:27:
Ik ken geen andere C based taal die de variabele $b hier buiten de loop laat bestaan zo uit m'n hoofd. Dat levert ook dit soort verwarrende zaken op.

Behalve dan alle strong-typed C-based talen waarbij je de variabele definieert voor de loop. En daar ligt dus het probleem, het gebrek aan expliciete definitie. Javascript doet dit overigens ook

[ Voor 4% gewijzigd door .oisyn op 29-10-2019 16:36 ]

[Mugwump]

.oisyn schreef op dinsdag 29 oktober 2019 @ 16:35:
[...]

Behalve dan alle strong-typed C-based talen waarbij je de variabele definieert voor de loop. En daar ligt dus het probleem, het gebrek aan expliciete definitie. Javascript doet dit overigens ook

Ja, maar dan is dus de scope van de variabele bepaald door het feit dat je hem expliciet declareert.

Overigens doet Python dit ook doodleuk bedacht ik me nog.

[orf]

Ik snap het niet helemaal. Ik zou verwachten dat in de laatste iteratie $b een referentie heeft naar 12. Waarom dan toch 10?

[.oisyn]

Mugwump schreef op dinsdag 29 oktober 2019 @ 16:37:
[...]


Ja, maar dan is dus de scope van de variabele bepaald door het feit dat je hem expliciet declareert.

Daarom. Bij elke C-based taal waarvan jij vindt dat dit niet gebeurt, is het alleen als je 'm expliciet binnen de loop definieert. Maar nu bestaat er geen definitie, dus wat moet er dan gebeuren?

Deels komt het probleem ook omdat referenties in PHP gewoon raar zijn. $b wijst niet naar $a[4], zowel $b als $a[4] wijzen naar hetzelfde ding.

orf schreef op dinsdag 29 oktober 2019 @ 16:37:
Ik snap het niet helemaal. Ik zou verwachten dat in de laatste iteratie $b een referentie heeft naar 12. Waarom dan toch 10?

Zowel $b als het laatste element uit de array wijzen naar dezelfde value. Die value wordt gebruikt als de iterator in de tweede loop. Je past dus niet alleen $b aan, maar ook het laatste element in de array

In de eerste iteratie van de tweede loop is $a dus gelijk aan [2, 4, 6, 8, 10, 2], bij de tweede iteratie [2, 4, 6, 8, 10, 4], etc.

[ Voor 47% gewijzigd door .oisyn op 29-10-2019 16:46 ]

[orf]

.oisyn schreef op dinsdag 29 oktober 2019 @ 16:38:
[...]

Daarom. Bij elke C-based taal waarvan jij vindt dat dit niet gebeurt, is het alleen als je 'm expliciet binnen de loop definieert. Maar nu bestaat er geen definitie, dus wat moet er dan gebeuren?


[...]

Zowel $b als het laatste element uit de array wijzen naar dezelfde value. Die value wordt gebruikt als de iterator in de tweede loop. Je past dus niet alleen $b aan, maar ook het laatste element in de array

In de eerste iteratie van de tweede loop is $a dus gelijk aan [2, 4, 6, 8, 10, 2], bij de tweede iteratie [2, 4, 6, 8, 10, 4], etc.

Ah, helder! Goeie uitleg.

[Mugwump]

.oisyn schreef op dinsdag 29 oktober 2019 @ 16:38:
[...]

Daarom. Bij elke C-based taal waarvan jij vindt dat dit niet gebeurt, is het alleen als je 'm expliciet binnen de loop definieert. Maar nu bestaat er geen definitie, dus wat moet er dan gebeuren?

Een impliciete declaratie is in mijn ogen nog steeds een declaratie.

In de statically type C talen doe je iets als foreach (var x in y) { .. }, waarbij je dan dus in de foreach een declaratie hebt. Feitelijk is dat niet anders als je geen strong typing kent.
Het volgende geeft bijvoorbeeld een error in Python op de tweede print:

Python:

def example(par1):
    abc = 3
    print(abc)

print(abc)

Ik definieer hier de variabele feitelijk ook impliciet, maar dat doet verder niets af aan de scoping regels.
Dit mag dan wel weer zonder problemen:

Python:

abc = [1, 2, 3, 4]

for b in abc:
    print(b)

print(b)

In mijn ogen is dat ook gewoon impliciete variabeledefinitie met een scope.

[.oisyn]

Mugwump schreef op dinsdag 29 oktober 2019 @ 16:46:
[...]


Een impliciete declaratie is in mijn ogen nog steeds een declaratie.

In de statically type C talen doe je iets als foreach (var x in y) { .. }, waarbij je dan dus in de foreach een declaratie hebt. Feitelijk is dat niet anders als je geen strong typing kent.
Het volgende geeft bijvoorbeeld een error in Python op de tweede print:

Python:

def example(par1):
    abc = 3
    print(abc)

print(abc)

In PHP ook. Met function scopes doen ze het prima, het gaat mis met block scopes. Tja, dat is gewoon een taalkwestie (C had in het begin overigens ook geen block scopes).

[BarôZZa]

.oisyn schreef op dinsdag 29 oktober 2019 @ 16:53:
[...]

In PHP ook. Met function scopes doen ze het prima, het gaat mis met block scopes. Tja, dat is gewoon een taalkwestie (C had in het begin overigens ook geen block scopes).

De manier van PHP vind ik een stuk logischer dan blockscopes met impliciete declaraties, want bij de laatste weet je niet direct wat de scope van een variabele is. Bij expliciete declaraties zijn block scopes een stuk duidelijker.

Voorkomen de blocked scopes bij jullie trouwens meer bugs of ontstaan er juist meer bugs door? Zelf vind ik de PHP way een stuk gebruiksvriendelijker en heb nooit last van rare bijwerkingen. Bij andere talen is het wel eens gebeurd dat er een rare bug met scopes ontstond. Waarom is de waarde x? Ohhhhhh ja

-----

Wat een haat naar JS hier trouwens. Ik vind het altijd prachtig hoe de taal uitnodigt om hele creatieve trucjes te verzinnen(jaja, ik weet dat alle pro's alleen maar hele pro dingen doen die vooral goed te onderhouden zijn en vooral niet leuk zijn). Vanilla JS is heerlijk, alle variantjes en frameworks vooral viezig(JQuery is de duivel en react is de nieuwe jquery). Was het laatst bezig met m'n Chrome extensie(die wordt briljant trouwens, dat niemand die feature nog bedacht heeft). Daar heb je content scripts en background scripts. De background scripts hebben toegang tot de Chrome APIs en de content scripts niet, maar ze kunnen wel onderling messages sturen.

Maar het is Javascript, dus alles mag en alles kan. Dus dan stuur je gewoon de gehele structuur van de Chrome API's naar je contentscript, die het daar weer opbouwt en waarbij alle functies automatisch op de achtergrond via messages de functies op de backgroundscript uitvoeren. Zodat je in je content script gewoon chrome.tabs.open() chrome.downloads.download() en dergelijke kan gebruiken zoals het hoort.

Is het de meest nette oplossing? Neuh. Ik snap uiteraard prima waarom de APIs niet in de contentscript beschikbaar zijn, maar als je creatieve gedachtenspinsels blijken te werken dan is dat altijd toch wel koel. Gewoon omdat het kan.

[.oisyn]

BarôZZa schreef op dinsdag 29 oktober 2019 @ 22:23:
[...]

De manier van PHP vind ik een stuk logischer dan blockscopes met impliciete declaraties, want bij de laatste weet je niet direct wat de scope van een variabele is. Bij expliciete declaraties zijn block scopes een stuk duidelijker.

Dat klopt, als declaraties impliciet zijn dan valt er natuurlijk niet fatsoenlijk meer mee te werken (is $a in een nieuwe block scope nou een nieuwe variabele of dezelfde als de $a in de omliggende scope).

JS heeft daar wel een aparte expliciete definitie voor: let.

[Lethalis]

BarôZZa schreef op dinsdag 29 oktober 2019 @ 22:23:
[...]
Wat een haat naar JS hier trouwens. Ik vind het altijd prachtig hoe de taal uitnodigt om hele creatieve trucjes te verzinnen(jaja, ik weet dat alle pro's alleen maar hele pro dingen doen die vooral goed te onderhouden zijn en vooral niet leuk zijn).

Totdat je met meerdere mensen tegelijk aan een project werkt en iedereen zijn eigen creatieve trucjes heeft... en geen hond meer begrijpt wat de code doet.

Wanneer opdrachtgevers en werkgever praktisch met een hakbijl achter jou staan wanneer iets het langer dan 15 minuten niet doet, dan heb je het liefst zo saai mogelijke code die eenvoudig te debuggen is en waarvan je meteen ziet wat hij doet

[ThomasG]

BarôZZa schreef op dinsdag 29 oktober 2019 @ 22:23:
[...]

De manier van PHP vind ik een stuk logischer dan blockscopes met impliciete declaraties, want bij de laatste weet je niet direct wat de scope van een variabele is. Bij expliciete declaraties zijn block scopes een stuk duidelijker.

Voorkomen de blocked scopes bij jullie trouwens meer bugs of ontstaan er juist meer bugs door? Zelf vind ik de PHP way een stuk gebruiksvriendelijker en heb nooit last van rare bijwerkingen. Bij andere talen is het wel eens gebeurd dat er een rare bug met scopes ontstond. Waarom is de waarde x? Ohhhhhh ja

Dat is dus iets typisch voor PHP en JavaScript. Daar heb je (tenzij je moderne JavaScript gebuikt) alleen global scope, of function scope. Als je een variable hergebruikt voor een ander doel heeft dat soms rare side effects (zoals een variable met de zelfde naam eerst als by-reference en daarna als by-value te gebruiken). In strong-typed compiled talen komen zulke dingen een stuk minder voor, omdat je dan gewoon compile fouten krijgt; of de programmeur moet heel creatief zijn geweest.

Het is trouwens sowieso niet aan te raden om variable met de zelfde naam te hergebruiken voor een ander doel. Dat is vaak een teken van code smell.

[DevWouter]

.oisyn schreef op dinsdag 29 oktober 2019 @ 16:38:
[...]

Daarom. Bij elke C-based taal waarvan jij vindt dat dit niet gebeurt, is het alleen als je 'm expliciet binnen de loop definieert.

Uitgezonderd Visual C++, daar werd de init-sectie van de for loop gelekt. Good times

[Mugwump]

BarôZZa schreef op dinsdag 29 oktober 2019 @ 22:23:
[...]

De manier van PHP vind ik een stuk logischer dan blockscopes met impliciete declaraties, want bij de laatste weet je niet direct wat de scope van een variabele is. Bij expliciete declaraties zijn block scopes een stuk duidelijker.

Voorkomen de blocked scopes bij jullie trouwens meer bugs of ontstaan er juist meer bugs door? Zelf vind ik de PHP way een stuk gebruiksvriendelijker en heb nooit last van rare bijwerkingen. Bij andere talen is het wel eens gebeurd dat er een rare bug met scopes ontstond. Waarom is de waarde x? Ohhhhhh ja

Hierboven heb je dus een voorbeeld van een rare bijwerking van het gebrek aan block scopes (icm reference variables).

Ik geef zelf sowieso de voorkeur aan talen als Java of C#.
Ik zit in een hoek waar ook veel Python wordt gebruikt voor BI & data science. Dan zie je toch vaak dat het allemaal leuk werkt zolang de hoeveelheid code niet uit de klauwen groeit, maar als dat wel gebeurt, dan wordt het al snel vrij chaotisch. Dat heeft ook wel deels te maken met het feit dat de mensen die de code schrijven geen pure developers zijn, maar je leest ook niet voor niets dat er bij grotere projecten of bedrijven zoals Dropbox die intensief gebruik maken van Python toch weer wordt teruggegrepen op iets als MyPy om type checking in te voeren.

[.oisyn]

DevWouter schreef op woensdag 30 oktober 2019 @ 09:32:
[...]


Uitgezonderd Visual C++, daar werd de init-sectie van de for loop gelekt. Good times

Niet met MS extensions uit . En anders:

C++:

#define for if (false); else for

[ThomasG]

.oisyn schreef op woensdag 30 oktober 2019 @ 10:03:
[...]

Niet met MS extensions uit . En anders:

C++:

#define for if (false); else for

Dat doet mij ineens denken aan een nieuwe C++ feature wat ik graag in andere talen zou zien: if (init-statement; condition) en switch (initial-statement; variable).

[gekkie]

Mugwump schreef op woensdag 30 oktober 2019 @ 09:38:
[...]
maar je leest ook niet voor niets dat er bij grotere projecten of bedrijven zoals Dropbox die intensief gebruik maken van Python toch weer wordt teruggegrepen op iets als MyPy om type checking in te voeren.

Is op zich nu buildin, alleen hebben je libraries nog geen type hinting of stubs er voor, dus je kan vooral je eigen code checken, maar goed het begin is er. Guido kwam er bij dropbox toch wel achter dat (optional) type checking in sommige gevallen wel handig is.

edit: miste de "nog geen" .. bij de libraries, al heb ik er bij een aantal al wel pull-requests voor gezien of plannen makerij hoe er mee om te gaan.

[ Voor 11% gewijzigd door gekkie op 30-10-2019 10:33 ]

[Olaf van der Spek]

.oisyn schreef op woensdag 30 oktober 2019 @ 10:03:
[...]

Niet met MS extensions uit . En anders:

C++:

#define for if (false); else for

Werd, als in VC6 (denk ik).

[.oisyn]

Olaf van der Spek schreef op woensdag 30 oktober 2019 @ 11:11:
[...]

Werd, als in VC6 (denk ik).

Ja, maar dat was een MS extension. Dat kon je uitzetten, maar dan moest je alle extensions uitzetten (dus compilen met /Za), maar dan compileerde de standaard Windows headers niet meer, dus echt een valide optie was het niet. Vanaf 2002 had je /Zc:forScope om te conformeren aan de standaard terwijl de extensions aan staan. Tegenwoordig is dat ook standaard en kun je het niet meer uitzetten.

[ Voor 3% gewijzigd door .oisyn op 30-10-2019 11:25 ]

[Mugwump]

Zijn er hier meer mensen die aanlopen tegen voorstellen voor enorm complexe oplossingen om te voldoen aan de GDPR? Dit is nou alweer het tweede project waarop iemand een voorstel presenteert met allerlei versleuteling van persoonlijke data, gescheiden opslag en ga zo maar door. Dat soort oplossingen gaan de projectduur zeker met 50% ophogen en zorgen voor een enorme berg accidental complexity met alle gevolgen van dien (impact op performance, kosten, onderhoud, enz).

[Ed Vertijsment]

Mugwump schreef op woensdag 30 oktober 2019 @ 11:50:
Zijn er hier meer mensen die aanlopen tegen voorstellen voor enorm complexe oplossingen om te voldoen aan de GDPR? Dit is nou alweer het tweede project waarop iemand een voorstel presenteert met allerlei versleuteling van persoonlijke data, gescheiden opslag en ga zo maar door. Dat soort oplossingen gaan de projectduur zeker met 50% ophogen en zorgen voor een enorme berg accidental complexity met alle gevolgen van dien (impact op performance, kosten, onderhoud, enz).

Ik merk vooraal angst en onwetendheid. Allerlei moeilijke fratsen om naar bepaalde gebruikers bepaalde informatie niet te tonen (die wel gewoon in de database staat). Er wordt van alles bedacht maar er wordt niet gewoon even naar de regels zelf gekeken.

[Skyaero]

Mugwump schreef op woensdag 30 oktober 2019 @ 11:50:
Zijn er hier meer mensen die aanlopen tegen voorstellen voor enorm complexe oplossingen om te voldoen aan de GDPR? Dit is nou alweer het tweede project waarop iemand een voorstel presenteert met allerlei versleuteling van persoonlijke data, gescheiden opslag en ga zo maar door. Dat soort oplossingen gaan de projectduur zeker met 50% ophogen en zorgen voor een enorme berg accidental complexity met alle gevolgen van dien (impact op performance, kosten, onderhoud, enz).

Yup, gescheiden databases die dan tijdelijk aan elkaar gekoppeld moeten worden e.d. Alsof dat uberhaupt effectief is.

GDPR wordt nog altijd niet goed begrepen terwijl het in de basis niet zo moeilijk is. "Waarom heb ik deze data nodig en is de gebruiker daar mee akkoord?

[ElkeBxl]

Skyaero schreef op woensdag 30 oktober 2019 @ 14:15:
[...]
GDPR wordt nog altijd niet goed begrepen terwijl het in de basis niet zo moeilijk is. "Waarom heb ik deze data nodig en is de gebruiker daar mee akkoord?

Pas op, straks zet je de GDPR consultants nog zonder werk

[ThomasG]

Skyaero schreef op woensdag 30 oktober 2019 @ 14:15:
[...]


Yup, gescheiden databases die dan tijdelijk aan elkaar gekoppeld moeten worden e.d. Alsof dat uberhaupt effectief is.

GDPR wordt nog altijd niet goed begrepen terwijl het in de basis niet zo moeilijk is. "Waarom heb ik deze data nodig en is de gebruiker daar mee akkoord?

Het probleem bij vele is dat zij data opslaan wat ze helemaal niet nodig hebben, en dus eigenlijk helemaal niet op mogen slaan.

[Mugwump]

Skyaero schreef op woensdag 30 oktober 2019 @ 14:15:
[...]


Yup, gescheiden databases die dan tijdelijk aan elkaar gekoppeld moeten worden e.d. Alsof dat uberhaupt effectief is.

GDPR wordt nog altijd niet goed begrepen terwijl het in de basis niet zo moeilijk is. "Waarom heb ik deze data nodig en is de gebruiker daar mee akkoord?

Het heeft veelal ook te maken met overijverig techneuten die helemaal los gaan op complexe oplossingen en het braafste jongetje van de klas willen zijn. De complexe oplossing in dit project werd overigens zojuist weer overbodig gemaakt door een mailtje van legal waarin werd aangegeven dat we ons prima kunnen beroepen op een langere bewaartermijn zoals beschreven in het BW, in plaats van de eigen interpretatie over hoe lang de data nodig zou zijn. Niks geschieden databases en encryptie, maar gewoon een retentieperiode waarna automatische schoning plaatsvindt.

[Douweegbertje]

Mugwump schreef op woensdag 30 oktober 2019 @ 14:34:
[...]


Het heeft veelal ook te maken met overijverig techneuten die helemaal los gaan op complexe oplossingen en het braafste jongetje van de klas willen zijn. De complexe oplossing in dit project werd overigens zojuist weer overbodig gemaakt door een mailtje van legal waarin werd aangegeven dat we ons prima kunnen beroepen op een langere bewaartermijn zoals beschreven in het BW, in plaats van de eigen interpretatie over hoe lang de data nodig zou zijn. Niks geschieden databases en encryptie, maar gewoon een retentieperiode waarna automatische schoning plaatsvindt.

+1.

Bij een grote vervoerder ooit eens deze change gemaakt:

- Minus 2 columns in een database (overbodige data)
- Retentie van 2 dagen op succesvolle processen
- Retentie van 2 weken op failed processen.

GDPR proof en iedereen is er bij gebaat. Zowel consument als "bedrijf" (in de zin van dev kosten ).

[Mugwump]

Douweegbertje schreef op woensdag 30 oktober 2019 @ 14:53:
[...]


+1.

Bij een grote vervoerder ooit eens deze change gemaakt:

- Minus 2 columns in een database (overbodige data)
- Retentie van 2 dagen op succesvolle processen
- Retentie van 2 weken op failed processen.

GDPR proof en iedereen is er bij gebaat. Zowel consument als "bedrijf" (in de zin van dev kosten ).

Probleem is een beetje dat wij zitten met DynamoDB als immutable, append-only data store, die we in combinatie met DynamoDB Streams gebruiken voor 'persist-and-publish'. Dan is 'even de data opknippen in twee tabelletjes' niet echt een optie. Je kunt wel weer een aparte PII-store in elkaar gaan knutselen, maar ja dan zit je weer met transacties. Tegenwoordig heeft Dynamo wel transacties, maar het levert je dubbele write kosten op en performancetechnisch is het ook niet optimaal. Bovendien is de opgeslagen data vrij divers in complexe JSON structuren met best wat velden die aangemerkt worden als 'persoonsgegevens'. Je zou kunnen gaan voor een extra tabel waarin je dan de key van elk item hetzelfde houdt evenals de JSON structuur, maar dan mét adresgegevens en een kortere TTL dan de hoofdtabel, terwijl je in de hoofdtabel de PII velden wegpoetst, maar dat blijft enorm veel extra overhead opleveren. Je moet dan in je code ook per type json dat je opslaat ook weer gaan bijhouden wat er weggepoetst moet gaan worden en weggeschreven in de aparte tabel. Bovendien moet je dan in je publish mechanisme weer een merger gaan inbouwen. Kan allemaal wel, maar zonde van de tijd en de extra kosten als het ook gewoon simpel kan.

[Douweegbertje]

Mugwump schreef op woensdag 30 oktober 2019 @ 15:30:
[...]


Probleem is een beetje dat wij zitten met DynamoDB als immutable, append-only data store, die we in combinatie met DynamoDB Streams gebruiken voor 'persist-and-publish'. Dan is 'even de data opknippen in twee tabelletjes' niet echt een optie. Je kunt wel weer een aparte PII-store in elkaar gaan knutselen, maar ja dan zit je weer met transacties. Tegenwoordig heeft Dynamo wel transacties, maar het levert je dubbele write kosten op en performancetechnisch is het ook niet optimaal. Bovendien is de opgeslagen data vrij divers in complexe JSON structuren met best wat velden die aangemerkt worden als 'persoonsgegevens'. Je zou kunnen gaan voor een extra tabel waarin je dan de key van elk item hetzelfde houdt evenals de JSON structuur, maar dan mét adresgegevens en een kortere TTL dan de hoofdtabel, terwijl je in de hoofdtabel de PII velden wegpoetst, maar dat blijft enorm veel extra overhead opleveren. Je moet dan in je code ook per type json dat je opslaat ook weer gaan bijhouden wat er weggepoetst moet gaan worden en weggeschreven in de aparte tabel. Bovendien moet je dan in je publish mechanisme weer een merger gaan inbouwen. Kan allemaal wel, maar zonde van de tijd en de extra kosten als het ook gewoon simpel kan.

Elke case is anders, ik bedoel alleen aan te geven dat, whatever manier, er vaak nog wel simpele oplossingen zijn. Ik ben mij er zeker van bewust hoe lastig het soms kan zijn.

[BarôZZa]

Lethalis schreef op woensdag 30 oktober 2019 @ 09:12:
[...]

Totdat je met meerdere mensen tegelijk aan een project werkt en iedereen zijn eigen creatieve trucjes heeft... en geen hond meer begrijpt wat de code doet.

Wanneer opdrachtgevers en werkgever praktisch met een hakbijl achter jou staan wanneer iets het langer dan 15 minuten niet doet, dan heb je het liefst zo saai mogelijke code die eenvoudig te debuggen is en waarvan je meteen ziet wat hij doet

Ik werk al aardig wat jaar in teams, leid er nu zelfs eentje. Maar heb ook altijd wel wat persoonlijke projectjes, waarbij ik alleen m'n eigen code soms moet ontcijferen. En overigens weet ik knappe oplossingen van collega's meestal juist wel te waarderen, mits het uiteraard nut heeft, efficiënt is en nog wel te volgen valt. Beter dan het copy-paste maar net wat anders en daardoor ongeveer hetzelfde als elders in de code. En te saaie code schrijven zuigt natuurlijk flink wat plezier uit het werk.

Bij m'n eerste werkgever had de lead developer moeite met ternary operators, dus wilde hij dat iedereen overal if statements gebruikte .

Gelukkig zit ik nu ergens waar tijdsdruk en dergelijke niet meer de boventoon voeren.

[ Voor 3% gewijzigd door BarôZZa op 30-10-2019 16:05 ]

[Olaf van der Spek]

.oisyn schreef op dinsdag 29 oktober 2019 @ 22:49:
[...]

Dat klopt, als declaraties impliciet zijn dan valt er natuurlijk niet fatsoenlijk meer mee te werken (is $a in een nieuwe block scope nou een nieuwe variabele of dezelfde als de $a in de omliggende scope).

JS heeft daar wel een aparte expliciete definitie voor: let.

Hoe groot / wat is het voordeel van impliciete definities eigenlijk (nog)?
auto / let / var typen kan het probleem niet zijn.

[Sandor_Clegane]

Lethalis schreef op dinsdag 29 oktober 2019 @ 09:29:
[...]

Waarom is Model View Update in jouw ogen simpeler dan Model View Presenter? Zeker in de door mij aangehaalde use case (Windows Forms development).

Als ik het goed begrijp, heb je bij MVU een Update functie die een nieuwe Model produceert (op basis van het oude Model en een request Message), die vervolgens wordt gerenderd met een View functie.

Hierbij is de Update functie dan goed testbaar, omdat hij altijd op basis van zijn inputs een bepaalde output produceert, waarbij je uitgaat van immutability en dus altijd het oude Model met het nieuwe Model kunt vergelijken na de transformatie.

Om dit goed te laten werken, heb je echter een framework nodig dat voorziet in de plumbing van het geheel. Dus je hebt tooling die jou helpt om een View te renderen bijvoorbeeld, en tooling die de request routing doet zodat je een Message / Model kunt geven aan de Update functie. Wat in Elm zeg maar de Runtime doet, om de Model, View en Update functies aan elkaar te knopen.

Zeg maar precies de taken die een Presenter als mediator heeft in het MVP pattern

Met het grote verschil natuurlijk dat er bij MVP van mutable state wordt uitgegaan.

Ik had niet goed gelezen

[.oisyn]

Olaf van der Spek schreef op woensdag 30 oktober 2019 @ 15:59:
[...]

Hoe groot / wat is het voordeel van impliciete definities eigenlijk (nog)?
auto / let / var typen kan het probleem niet zijn.

Ik vind het lastig. Het is iets waar ik over na heb gedacht bij KolQ, en het probleem zit 'm in de global scope. Ik vind de aanpak van PHP niet fantastisch, waarbij je elke globale variabele in een functie expliciet moet declareren. Draai je dat om, dan kom je op iets in Javascript, waarbij je lokale variabelen expliciet moet declareren, en anders verwijst het automatisch naar een global. Maar dan kom je op de vraag: moeten globale variabelen ook expliciet gedeclareerd worden? Ergens is dat gek, aangezien je members van objecten ook gewoon on the fly aan kunt maken en weer weg kunt halen, dus waarom niet in de global object? Uiteindelijk doe ik dus ook gewoon wat javascript ook doet. Lokale variabelen expliciet definieren, anders is het een global.

[ThomasG]

Wanneer kunnen we eigenlijk de Tweakers Preview van KolQ verwachten?

[.oisyn]

Oh ik kan wel een .exe delen

[Ryur]

BarôZZa schreef op woensdag 30 oktober 2019 @ 15:58:
[...]
Bij m'n eerste werkgever had de lead developer moeite met ternary operators, dus wilde hij dat iedereen overal if statements gebruikte .

Ik heb niet echt moeite met ternary operators, maar als ik zie wat voorn brij er soms langskomt met het gebruik van ternary operators!

Of wat ik ook veel tegenkom is dat men een if gebruikt, en dan een hele korte else.
Doe dan de statement precies om switchen zodat je een early return hebt!

Voorbeeld:

Ruby:

if Company.present?
  # 400 regels aan code (ja nog zo een!)
else
  render head: 404

[Alex)]

Tot je een code review hebt door een senior dev die vindt dat je maar 1 return per function mag hebben.... been there done that

[ThomasG]

Alex) schreef op woensdag 30 oktober 2019 @ 18:10:
Tot je een code review hebt door een senior dev die vindt dat je maar 1 return per function mag hebben.... been there done that

Dat ligt natuurlijk aan de situatie. Soms zijn meerdere return statements duidelijker, soms weer niet. Veel belangrijker is de cyclomatic complexity van de functie. Als je veel return statements hebt in een functie is dat vaak wel een teken van code smell.

[Alex)]

Ja, eens. Maar ik heb liever een drietal if-returns boven elkaar (als het gaat om checks) dan een moeilijke brei aan and-statements met een flinke lap code in de if.

Als er echt complexe logica gebeurt heb ik liever dat het wordt opgeknipt in een paar methods en in een eigen class gaat.

[Ed Vertijsment]

Volgens mij moeten zulke dingen niet te strikt worden opgevat. In veel gevallen maken ze sense, soms niet.

[Ryur]

Ed Vertijsment schreef op woensdag 30 oktober 2019 @ 18:41:
Volgens mij moeten zulke dingen niet te strikt worden opgevat. In veel gevallen maken ze sense, soms niet.

Volledig mee eens! Maar je hebt in onze vakgebied(en) van die personen die alles precies volgens de richtlijnen volgen, ondanks dat de richtlijnen in bepaalde situaties niet werkbaar zijn.

Ik heb ooit eens samengewerkt met iemand waarvan alle variabelen woorden moesten zijn, en geen afkortingen (zelfs als die algemeen geaccepteerd waren). En ja dat hield ook in bij een simpele for-lus dat je niet zomaar met i mocht werken!
Of dat je variabelen kreeg van 20-30 tekens, waar je bijvoorbeeld "BSN" zou gebruiken moest ik perse "burgerservicenummer" voor gebruiken

[Mugwump]

Ryur schreef op woensdag 30 oktober 2019 @ 19:41:
[...]

Volledig mee eens! Maar je hebt in onze vakgebied(en) van die personen die alles precies volgens de richtlijnen volgen, ondanks dat de richtlijnen in bepaalde situaties niet werkbaar zijn.

Ik heb ooit eens samengewerkt met iemand waarvan alle variabelen woorden moesten zijn, en geen afkortingen (zelfs als die algemeen geaccepteerd waren). En ja dat hield ook in bij een simpele for-lus dat je niet zomaar met i mocht werken!
Of dat je variabelen kreeg van 20-30 tekens, waar je bijvoorbeeld "BSN" zou gebruiken moest ik perse "burgerservicenummer" voor gebruiken

Ik ben helemaal voor beschrijvende namen ten faveure van onleesbare afkortingen, maar je kunt er ook in doorslaan.
Daarentegen heb ik ook wel weer enorm veel voorbeelden gezien van specs waar ze bijvoorbeeld besloten XML te gebruiken voor informatieuitwisseling omdat het zo lekker zelfbeschrijvend is, maar er vervolgens achter kwamen dat de hoeveelheid uit te wisselen data fors toenam, waarna men maar vrij willekeurig letters ging weglaten uit de tags. Noem een waterpomptang gewoon een waterpomptang en geen WtPTng of iets dergelijks.

[.oisyn]

ThomasG schreef op woensdag 30 oktober 2019 @ 16:47:
Wanneer kunnen we eigenlijk de Tweakers Preview van KolQ verwachten?

https://oisyn.nl/KolQ.zip
Disclaimer: No warranties. Do not use this software. Ever.

Kruisje minimized naar tray, ctrl-click op kruisje sluit 'm af. Of met quit() . restart() reset de VM en leest stdlib.kolq opnieuw uit. De syntax leer je maar uit die file

[Ryur]

Mugwump schreef op woensdag 30 oktober 2019 @ 19:50:
Ik ben helemaal voor beschrijvende namen ten faveure van onleesbare afkortingen, maar je kunt er ook in doorslaan.

Er zit een verschil tussen beschrijvende namen en geaccepteerde afkortingen
BSN, HBO, VMBO-T, VWO als voorbeelden. Die ex-collega van mij wilde graag dat ik die volledig uitschreef (en ja hij was gedragen door het management).
Een van de redenen waarom ik daar weg ben

_{Ik moet van bijna alle afkortingen opzoeken hoe ze volledig uitgeschreven heten. Ja ik was bezig met onderwijssoftware, zoals je wel kan merken aan de woorden}

Mugwump schreef op woensdag 30 oktober 2019 @ 19:50:
Daarentegen heb ik ook wel weer enorm veel voorbeelden gezien van specs waar ze bijvoorbeeld besloten XML te gebruiken voor informatieuitwisseling omdat het zo lekker zelfbeschrijvend is, maar er vervolgens achter kwamen dat de hoeveelheid uit te wisselen data fors toenam, waarna men maar vrij willekeurig letters ging weglaten uit de tags. Noem een waterpomptang gewoon een waterpomptang en geen WtPTng of iets dergelijks.

Dat heb ik (gelukkig) nog niet meegemaakt! De XML's waarmee ik heb gewerkt waren dat wel enorm logge files, maar ze waren wel heel duidelijk qua elementnamen gelukkig!

[ Voor 3% gewijzigd door Ryur op 30-10-2019 20:14 ]

[Matis]

Alex) schreef op woensdag 30 oktober 2019 @ 18:10:
Tot je een code review hebt door een senior dev die vindt dat je maar 1 return per function mag hebben.... been there done that

Bij mijn vorige werkgever moesten sommige onderdelen van de software volgens de MISRA standaard ontwikkeld worden. Die schrijft dat ook voor.

Mijn oplossing om dat te omzeilen was een hele grote

C:

do {

} while(false);

Een dan op gezette plekken en break ipv return

[Mugwump]

Ik kom het ook nog vaak in databases tegen. Kolomnamen als wnplnm in plaats van woonplaatsnaam. Sommige mensen leven kennelijk nog in de tijd dat elke byte opslag telde.

[Alex)]

Als je diep in de krochten van SAP duikt kom je ook overal afgekorte kolomnamen tegen. En dan ook nog eens in het Duits, want SAP is Duits. Gelukkig staat er wel bij vrij veel een omschrijving bij (of is die nog wel te vinden), anders kom je er echt niet uit.

Voorbeeldje:
GLTGV = Gültig von = geldig vanaf

En de evenknie... GLTGB.

[Koenvh]

.oisyn schreef op woensdag 30 oktober 2019 @ 19:53:
[...]


https://oisyn.nl/KolQ.zip
Disclaimer: No warranties. Do not use this software. Ever.

Kruisje minimized naar tray, ctrl-click op kruisje sluit 'm af. Of met quit() . restart() reset de VM en leest stdlib.kolq opnieuw uit. De syntax leer je maar uit die file

Ik vind het idee leuk. Ik ben benieuwd naar de voortgang

En sommige dingen zijn gewoon leuk zonder nuttig te zijn, zoals dit:

[R4gnax]

BarôZZa schreef op woensdag 30 oktober 2019 @ 15:58:
Bij m'n eerste werkgever had de lead developer moeite met ternary operators, dus wilde hij dat iedereen overal if statements gebruikte .

Ooit zelf ook nog eens ergens tegen aangelopen waar vanuit een implementatie-partner zelfs enkelvoudige ternaries met heee---l simpele right-hand expressies uit den boze waren, "want dat snappen onze medewerkers niet."

Maar inline lambda delegates aan elkaar rijgen was kennelijk geen enkel probleem.
Ik kwam heel erg in de verleiding om demonstratief iets te schrijven zoals:

C#:

return Ternary.Select( foo, () => "bar", () => "baz");

[Antrax]

.oisyn schreef op woensdag 30 oktober 2019 @ 19:53:
[...]


https://oisyn.nl/KolQ.zip
Disclaimer: No warranties. Do not use this software. Ever.

Een binary van een forum downloaden, what could possibly go wrong.

Grapje natuurlijk @.oisyn, hvj, xoxo. ntb.

[Olaf van der Spek]

.oisyn schreef op woensdag 30 oktober 2019 @ 16:43:
Ik vind het lastig. Het is iets waar ik over na heb gedacht bij KolQ, en het probleem zit 'm in de global scope. Ik vind de aanpak van PHP niet fantastisch, waarbij je elke globale variabele in een functie expliciet moet declareren.

Het probleem is de syntax. Ruby gebruikt @instance en @@class syntax, zoiets zou voor globals IMO goed werken. Heb je ook geen g_, m_ prefixes of suffixes meer nodig.

Draai je dat om, dan kom je op iets in Javascript, waarbij je lokale variabelen expliciet moet declareren, en anders verwijst het automatisch naar een global. Maar dan kom je op de vraag: moeten globale variabelen ook expliciet gedeclareerd worden? Ergens is dat gek, aangezien je members van objecten ook gewoon on the fly aan kunt maken en weer weg kunt halen, dus waarom niet in de global object? Uiteindelijk doe ik dus ook gewoon wat javascript ook doet. Lokale variabelen expliciet definieren, anders is het een global.

Klinkt toch wat error prone.

[bwerg]

Alex) schreef op woensdag 30 oktober 2019 @ 18:10:
Tot je een code review hebt door een senior dev die vindt dat je maar 1 return per function mag hebben.... been there done that

Och, ja. En dan in elke branch result = blabla, en dan aan het einde return result. Want dat is véél duidelijker, natuurlijk.

Haat aan programmeurs die het idee achter stijl-richtlijnen (duidelijkheid, overzicht) zelf niet meer als hoofddoel nemen, maar richtlijnen gewoon als dogma hanteren. Wordt dan priester of zo.

[Mugwump]

bwerg schreef op donderdag 31 oktober 2019 @ 11:26:
[...]

Och, ja. En dan in elke branch result = blabla, en dan aan het einde return result. Want dat is véél duidelijker, natuurlijk.

Haat aan programmeurs die het idee achter stijl-richtlijnen (duidelijkheid, overzicht) zelf niet meer als hoofddoel nemen, maar richtlijnen gewoon als dogma hanteren. Wordt dan priester of zo.

Dat komt ook vaak gewoon omdat ze de boel niet écht snappen. Als je niet écht begrijpt wat je aan het doen bent, dan klamp je je vast aan regeltjes. Het is makkelijker om je vast te houden aan een stelregel als 'elke methode moet gedocumenteerd worden' of 'elke methode behalve getters en setters moet gedocumenteerd worden'. Het doel is uiteindelijk dat andere developers begrijpen wat iets doet. Als je een methode retrieveOrder hebt, dan heb ik weinig aan javadoc waarin de omschrijving 'retrieves an order' staat met omschrijving van de return value 'the order'. Relevante informatie is voor mij bijvoorbeeld het gedrag van de methode indien de order niet bestaat. Dat de methode een order ophaalt had ik al wel gezien aan de methodenaam. Maar jezelf verplaatsen in de gebruiker van een methode en je afvragen welke niet triviale informatie je in documentatie moet stoppen vereist een ander niveau van competentie dan simpelweg wat non-informatie in de documentatie een methode plempen.

[P-Storm]

Net gekeken hoe je een git patch file maakt en toepast. Best wel makkelijk, nog nooit gedaan vanaf command line

Git is het versiebeheer waar ik tot nu toe het minste het gevoel heb gehad dat het mij tegen probeert te werken. Hoe ervaren jullie git of juist andere versiebeheer systemen?

[.oisyn]

Perforce, whooo!

[kenneth]

Voor studie een tijd Mercurial gebruikt. Minder krachtig en waarschijnlijk ook minder snel maar zoveel eenduidiger. Ik waardeer de kracht en snelheid van git enorm maar verwarrende commando's, opties en termen maken het af en toe tot een harentrekker. Git Koans

Het is niet zo erg dat ik gitless wil gebruikem maar gelukkig zijn er wel GUIs en goede documentatie

[Matis]

P-Storm schreef op donderdag 31 oktober 2019 @ 13:59:
Net gekeken hoe je een git patch file maakt en toepast. Best wel makkelijk, nog nooit gedaan vanaf command line

Git is het versiebeheer waar ik tot nu toe het minste het gevoel heb gehad dat het mij tegen probeert te werken. Hoe ervaren jullie git of juist andere versiebeheer systemen?

Bij mijn vorige werkgever SVN en CVS gebruikt. Dat werd, zeker met de manier waarop wij projecten draaiden, steeds moeilijker om daarin goed te kunnen werken.
Van de een op andere dag overgegaan op git. Wat een verademing.

Ik duw bijna alle projecten in git, als is het maar voor mezelf om een tijdslijn op te bouwen van bepaalde onderdelen van het project.

Dit hoeft echt niet alleen maar software te zijn, soms ook (tekst)documenten of afbeeldingen. Ik vind het erg fijn werken en ook de tools en tooling / systemen eromheen werken erg fijn

[ThomasG]

kenneth schreef op donderdag 31 oktober 2019 @ 15:13:
Voor studie een tijd Mercurial gebruikt. Minder krachtig en waarschijnlijk ook minder snel maar zoveel eenduidiger. Ik waardeer de kracht en snelheid van git enorm maar verwarrende commando's, opties en termen maken het af en toe tot een harentrekker. Git Koans

Het is niet zo erg dat ik gitless wil gebruikem maar gelukkig zijn er wel GUIs en goede documentatie

Ik neem aan dat je voornamelijk op Windows werkt, want dan is Mercurial inderdaad gemakkelijker in gebruik. Op *nix systemen niet. Iedereen doet altijd net of git rocket science is, maar het is allemaal vrij eenvoudig. Het zijn juist de GUI's die het allemaal ingewikkeld maken

[kenneth]

ThomasG schreef op donderdag 31 oktober 2019 @ 15:20:
Mercurial inderdaad gemakkelijker in gebruik.

Eenduidiger, niet makkelijker

Bij git heb je per commando soms compleet andere opties (zie die git Koans: git remote -v versus git branch -a, of git remote rm versus git branch -d) en de ene keer heet het staging, soms heet het index en soms heet het cached. Het went allemaal wel, maar het is niet nodig.

[ Voor 6% gewijzigd door kenneth op 31-10-2019 15:42 ]

[Mugwump]

kenneth schreef op donderdag 31 oktober 2019 @ 15:24:
[...]
Eenduidiger, niet makkelijker

Bij git heb je per commando soms compleet andere opties (zie die git Koans: git remote -v versus git branch -a, of git remote rm versus git branch -d) en de ene keer heet het staging, soms heet het index en soms heet het cached. Het went allemaal wel, maar het is niet nodig.

Git heeft niet voor niets in een recente versie de experimentele commando's git switch en git remote geïntroduceerd.

[kenneth]

Mugwump schreef op donderdag 31 oktober 2019 @ 15:27:
[...]


Git heeft niet voor niets in een recente versie de experimentele commando's git switch en git remote geïntroduceerd.

Cool! Het gaat om git restore trouwens Hier meer: https://github.blog/2019-08-16-highlights-from-git-2-23/

[Boudewijn]

.oisyn schreef op donderdag 31 oktober 2019 @ 14:16:
Perforce, whooo!

ik lees op wiki dat ze groot zijn in de gaming markt, weet jij waarom dat is?

* Boudewijn heeft perforce voor het laatst een jaar of 15 geleden aangeraakt .

[Mugwump]

kenneth schreef op donderdag 31 oktober 2019 @ 15:47:
[...]

Cool! Het gaat om git restore trouwens Hier meer: https://github.blog/2019-08-16-highlights-from-git-2-23/

Eh ja, restore bedoelde ik inderdaad.

[.oisyn]

Boudewijn schreef op donderdag 31 oktober 2019 @ 15:53:
[...]

ik lees op wiki dat ze groot zijn in de gaming markt, weet jij waarom dat is?

Binary content. Een project gaat makkelijk over de terabyte aan content in het depot (en dan reken ik revisies niet eens mee).

[plofkip]

Deze Git GUI wordt ook goed beoordeeld: https://git-fork.com/

[Gropah]

plofkip schreef op donderdag 31 oktober 2019 @ 16:10:
Deze Git GUI wordt ook goed beoordeeld: https://git-fork.com/

Helaas, zoals wel vaker met dit soort tools, is het alleen voor Windows en Mac

[plofkip]

Ik zie het probleem niet 😏😜

[Antrax]

Gropah schreef op donderdag 31 oktober 2019 @ 17:41:
[...]

Helaas, zoals wel vaker met dit soort tools, is het alleen voor Windows en Mac

Ik weet toevallig dat SmartGit ook voor Linux is.

[farlane]

Gebruik zelf geregeld GitKraken. Electron much, maar desondanks wel aardig voor de grafische invalshoek. Je blijft de terminal nodig hebben overigens...

[Ed Vertijsment]

Ik heb zelf nooit behoefte aan GUI git tools gehad, niet dat alles hardcore op Vim en op de commandline moet maar vind git gewoon lastig in GUI’s mee te werken. Hoe slim sommige tools ook zijn.

[Lethalis]

Gropah schreef op donderdag 31 oktober 2019 @ 17:41:
[...]
Helaas, zoals wel vaker met dit soort tools, is het alleen voor Windows en Mac

[Koenvh]

Ik vind GitKraken ook fijn werken - vooral om het overzicht op een hele commitboom te hebben en een commit te kunnen maken voor een aantal bestanden (vind ik in ieder geval makkelijker in een GUI dan in de CLI).

[Matis]

Antrax schreef op donderdag 31 oktober 2019 @ 19:06:
Ik weet toevallig dat SmartGit ook voor Linux is.

Klopt, ik gebruik zakelijk ook SmartGit op Linux (Ubuntu 18.04).

[kwaakvaak_v2]

De laatste update van Git Fork voegt ook een quick launch / shortcut systeem toe, waar je ook eigen shortcuts aan toe kan voegen. Komende weken eens testen of het ook echt zo handig is als het klinkt

Windows en Mac only.

[Douweegbertje]

Ben ik dan apart dat ik puur alleen de CLI voor git gebruik?

[whoami]

Douweegbertje schreef op vrijdag 1 november 2019 @ 15:20:
Ben ik dan apart dat ik puur alleen de CLI voor git gebruik?

Nee, ik gebruik enkel de CLI (en de integratie die Visual Studio biedt).

[kwaakvaak_v2]

Douweegbertje schreef op vrijdag 1 november 2019 @ 15:20:
Ben ik dan apart dat ik puur alleen de CLI voor git gebruik?

Nee hoor, doe ik ook 90% van de tijd Soms ook niet.

[dev10]

Douweegbertje schreef op vrijdag 1 november 2019 @ 15:20:
Ben ik dan apart dat ik puur alleen de CLI voor git gebruik?

Nope. Ik heb nog geen GUI voor Git gevonden waarmee ik net zo snel ben als via de command line. Het enige dat ik wel doe is committen vanuit PHPStorm aanverwant IDEs, maar verder doe ik echt alles met de command line.

[Kalentum]

Ik gebruik ook af en toe een Gui (sourcetree) voor git. Vooral als ik teveel geprutst heb en visueel het equivalent van 'git add -p' wil doen

[WernerL]

Changes stagen en merge-conflicten fixen doe ik via VSCode, de rest via de command line. Nooit begrepen waarom mensen denken een GUI nodig te hebben voor git.

[ Voor 8% gewijzigd door WernerL op 01-11-2019 20:34 ]

[Koenvh]

WernerL schreef op vrijdag 1 november 2019 @ 20:33:
Changes stagen en merge-conflicten fixen doe ik via VSCode, de rest via de command line. Nooit begrepen waarom mensen denken een GUI nodig te hebben voor git.

Nodig hebben? Ik heb heel weinig nodig, maar 't is wel handiger.

[n9iels]

Douweegbertje schreef op vrijdag 1 november 2019 @ 15:20:
Ben ik dan apart dat ik puur alleen de CLI voor git gebruik?

Nee zeker niet. De enige keer dat ik een GUI heb gebruikt ging deze allemaal "slimme" dingen doen en heeft effectief mijn branch om zeep geholpen. Verder zie ik collega's ook als een aap op knopjes klikken zonder te weten wat ze doen.

Enige wat ik soms doe is de graph overview bekijken om even te zien waar het een en ander vandaan komt. En merge conflicts met VS code oplossen omdat deze snel alle conflict files markeert. Maar merge/rebase commands zeker met CLI

[farlane]

n9iels schreef op vrijdag 1 november 2019 @ 22:52:
[...]
Nee zeker niet. De enige keer dat ik een GUI heb gebruikt ging deze allemaal "slimme" dingen doen en heeft effectief mijn branch om zeep geholpen.

Hoe dan?

Verder zie ik collega's ook als een aap op knopjes klikken zonder te weten wat ze doen.

Daar kun je moeilijk de GUI verantwoordelijk voor stellen lijkt me. Een GUI is geen substituut voor kennis van zaken hebben.

[Mugwump]

Ik vind de git integratie in IntelliJ veelal ruim voldoende. Die in Visual Studio vond ik echt dramatisch, dan kun je inderdaad beter gelijk gebruik maken van de CLI.

[Antrax]

n9iels schreef op vrijdag 1 november 2019 @ 22:52:
Verder zie ik collega's ook als een aap op knopjes klikken zonder te weten wat ze doen.

Uh? Ik gebruik zowel de GUI en de CLI. De GUI wat vaker uit luiheid maar dat is dan niet gelijk zo dat ik geen cli kennis hebt.

Edit:
Eigenlijk wat @farlane net al zegt:

farlane schreef op zaterdag 2 november 2019 @ 15:41:
Daar kun je moeilijk de GUI verantwoordelijk voor stellen lijkt me. Een GUI is geen substituut voor kennis van zaken hebben.

[ Voor 31% gewijzigd door Antrax op 02-11-2019 17:04 ]