Ask yourself if you are happy and then you cease to be.
Het voordeel van een ORM is voor mij niet dat ik geen SQL meer moet schrijven; het voordeel is voor mij change-tracking, mapping, caching, unit-of-work gedrag.Sandor_Clegane schreef op maandag 29 oktober 2018 @ 16:40:
Lastig, als je elke keer je tool moet second guessen kan je je afvragen wat het dan nog oplevert. Juist met die complexe queries wil je juist dat hij zijn werk goed doet, daar heb je hem tenslotte voor.
https://fgheysels.github.io/
Hoezo scary? IBM heeft imo. een goed imago.Lethalis schreef op maandag 29 oktober 2018 @ 18:10:
Hm scary stuff.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Red Hat heeft een veel vrijer beleid ten opzichte van open source. Je mag als werknemer van Red Hat zelfs dingen bouwen die concurreren met Red Hat.Antrax schreef op dinsdag 30 oktober 2018 @ 05:40:
[...]
Hoezo scary? IBM heeft imo. een goed imago.
Het zijn juist die nevenactiviteiten van getalenteerd personeel die vaak tot gave dingen leiden.
Bij IBM is dit einde oefening. Daar heb je gewoon een keihard concurrentiebeding.
Dat soort dingen lees ik op Reddit iig van mensen die voor beide bedrijven werken.
Ik ben ook benieuwd wat dit voor Fedora gaat betekenen...
Ask yourself if you are happy and then you cease to be.
Wat me vooral opvalt is dat een bedrijf dat al jaren niet echt een visie heeft, toch nog zolang overleeft en het geld weet te vinden om voor een astronomisch bedrag een ander bedrjf over te nemen dat wel weet wat het doet.
Net als Sun, best jammer.
Less alienation, more cooperation.
Tijd zal het leren. De nuance ontbreekt nogal op redditLethalis schreef op dinsdag 30 oktober 2018 @ 07:03:
Dat soort dingen lees ik op Reddit iig van mensen die voor beide bedrijven werken.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Beetje overdreven. IBM was begin jaren '00 juist een van de driving forces achter een hoop Java open source. IBM is een van de redenen dat het Java ecosysteem zo open is.Lethalis schreef op dinsdag 30 oktober 2018 @ 07:03:
Bij IBM is dit einde oefening.
Ik denk dat het wel meevalt. Microsoft gaat niet hard ingrijpen in Github, dat zou het risico hebben dat de waarde keldert. Voor IBM geldt hetzelfde wat betreft Red Hat vermoed ik.
Maar wie weet zit ik er naast; gebeurt ook regelmatig
IIT tot hier?Antrax schreef op dinsdag 30 oktober 2018 @ 08:30:
Tijd zal het leren. De nuance ontbreekt nogal op reddit
[ Voor 14% gewijzigd door Hydra op 30-10-2018 09:27 ]
https://niels.nu
Was dat niet Google?Sandor_Clegane schreef op dinsdag 30 oktober 2018 @ 08:08:
IBM, where technology goes to die.
We are shaping the future
Volgens de nieuwe ceo zal er niks veranderen; https://webwereld.nl/soft...-ceo-trotseert-vragenvuurHydra schreef op dinsdag 30 oktober 2018 @ 09:26:
Microsoft gaat niet hard ingrijpen in Github [...]
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Ja, logisch, dat kan ik volgen. Die software doet nu een Math.Floor(vertraging / 5) en dat moet eruit."Tegenwoordig zijn al onze borden digitaal, maar dat betekent niet dat we dit zomaar met één druk op de knop kunnen toepassen. Daar zijn wijzigingen in de software voor nodig."
Een paar regels code veranderen en dat uitrollen naar alle schermen op de perrons duurt een paar jaar? Agile, much?De NS benadrukt dat nog onduidelijk is wanneer het onderzoek precies start. ,,Als de klant het graag wil en het blijkt technisch mogelijk, dan kunnen we een pilot met één of een beperkt aantal stations of trajecten doen."
Pas als zo'n proef slaagt, wordt verdere invoering overwogen. Maar dat laat zeker nog een paar jaar op zich wachten. Vertragingen en slechte informatie daarover behoren momenteel tot de grootste ergernissen van treinreizigers.
Ik zeg: uitrollen, en social media + klantenservice monitoren om te kijken of er veel negatieve feedback op komt. Zo ja, dan draai je het terug. Zo nee, dan laat je het lekker live staan.
We are shaping the future
Denk je serieus dat een dergelijke wijziging een 'paar regels code' is?Alex) schreef op dinsdag 30 oktober 2018 @ 09:45:
Een paar regels code veranderen en dat uitrollen naar alle schermen op de perrons duurt een paar jaar? Agile, much?

https://niels.nu
Ja.Hydra schreef op dinsdag 30 oktober 2018 @ 09:53:
[...]
Denk je serieus dat een dergelijke wijziging een 'paar regels code' is?
In het InfoPlus-systeem is er een veld dat "gedempte vertrekvertraging" heet, daarin staat de vertraging naar beneden afgerond in increments van 5 minuten. Er is ook een veld dat "Exacte vertrekvertraging" heet.
Als het méér dan een paar regels code aanpassen is om de waarde uit een ander veld te halen, is er iets behoorlijk fout gegaan bij het ontwerp van die software.
Eventueel moet er nog iets worden aangepast aan hoe de informatie wordt gepresenteerd: momenteel wordt er gewisseld tussen "+5 minuten" (in een blauwe balk) en de treinsoort ("Intercity"), bij een vertraging van 1 minuut is dat misschien wat minder relevant. Dat is natuurlijk wel iets meer werk, maar dat zou geen jaren mogen duren. Zelfs geen weken.
[ Voor 4% gewijzigd door Alex) op 30-10-2018 10:01 ]
We are shaping the future
De reden dat de vertraging aan de reiziger wordt gemeld in stappen van 5 minuten is om de Windows file-copy taferelen te voorkomen. Niet vertraagde treinen hebben altijd voorrang op vertraagde treinen, vertraagde treinen kunnen dus veel rode seinen krijgen en soms op een ander spoor worden gezet zodat ze nog wel wat minuten vertraging dicht kunnen rijden. De vertraging is geen constante tijd, dat kunnen ze vooraf moeilijk inschatten. Dan vind ik +5 op het bord beter dan dat het springt van 2 minuten naar 4 minuten naar 3 minuten, etc.Alex) schreef op dinsdag 30 oktober 2018 @ 09:58:
[...]
Ja.
In het InfoPlus-systeem is er een veld dat "gedempte vertrekvertraging" heet, en dat de vertraging naar beneden afrondt en toont in increments van 5 minuten. Er is ook een veld dat "Exacte vertrekvertraging" heet.
Als dat méér dan een paar regels code aanpassen is, is er iets behoorlijk fout gegaan bij het ontwerp van die software.
Eventueel moet er nog iets worden aangepast aan hoe de informatie wordt gepresenteerd: momenteel wordt er gewisseld tussen "+5 minuten" (in een blauwe balk) en de treinsoort ("Intercity"), bij een vertraging van 1 minuut is dat misschien wat minder relevant. Dat is natuurlijk wel iets meer werk, maar dat zou geen jaren mogen duren. Zelfs geen weken.
Begrijpelijk, maar dat ga je niet oplossen door het dan maar op 5 minuten te laten staan. In de app en op de websites wordt vertraging ook al tot op de minuut nauwkeurig getoond. Ook in bussen en aansluitend OV wordt vertraging vaak exact getoond, het zijn alleen de reisinformatiesystemen van NS zelf die de vertraging afronden.ThomasG schreef op dinsdag 30 oktober 2018 @ 10:03:
[...]
De reden dat de vertraging aan de reiziger wordt gemeld in stappen van 5 minuten is om de Windows file-copy taferelen te voorkomen. Niet vertraagde treinen hebben altijd voorrang op vertraagde treinen, vertraagde treinen kunnen dus veel rode seinen krijgen en soms op een ander spoor worden gezet zodat ze nog wel wat minuten vertraging dicht kunnen rijden. De vertraging is geen constante tijd, dat kunnen ze vooraf moeilijk inschatten. Dan vind ik +5 op het bord beter dan dat het springt van 2 minuten naar 4 minuten naar 3 minuten, etc.
Als je de exacte vertraging toont weet je wel meteen waar je als reiziger aan toe bent. Ik vind het persoonlijk best wel vervelend als ik op een perron sta, de trein van 15:07 "+5 minuten" heeft, en om 15:13 nog niet in zicht is. Dan zie ik liever "15:07 +7" zodat ik weet dat ik 'm over een minuut wél zou moeten kunnen verwachten. Als de vertraging dan verder oploopt zie ik dat ook meteen op het bord.
Als de verkeersleiding besluit dat een andere trein voor mag gaan, dan zal de informatie op de borden hoe dan ook wijzigen (er komt dan ineens een andere trein te staan).
Een kijkje naar hoe onze buurlanden het doen:
- Duitsland: DB toont vertraging ook afgerond ("etwa 5 Minuten später")
- België: toont oorspronkelijke vertrektijd met daarnaast vertraging in minuten
- VK: toont exacte verwachte tijd indien beschikbaar (21:19 Dartford, exp. 21:22), anders "Expected" of "Delayed".
[ Voor 15% gewijzigd door Alex) op 30-10-2018 10:09 ]
We are shaping the future
Je vergeet daarbij even dat het Nederlandse spoor een van de complexere ter wereld is. Nederlandse treinen rijden in vergelijking metrodiensten. Je kunt dat echt niet vergelijken met het VK of Duitsland. Treinen in het VK en Duitsland hebben veelal vrijbaan, als in: het is de enige trein die op dat stuk spoor zal rijden in een blok van 15 minuten. In Nederland, vooral in de randstad, is dat een blok van slechts een paar minuten. Dus loop je bij een vertraging tegen veel meer problemen aan. Je kunt het ook niet met de bus vergelijken, omdat die niet op een geregeld spoor rijdt en het veel makkelijker is om vertraging goed te maken.Alex) schreef op dinsdag 30 oktober 2018 @ 10:08:
[...]
Begrijpelijk, maar dat ga je niet oplossen door het dan maar op 5 minuten te laten staan. In de app en op de websites wordt vertraging ook al tot op de minuut nauwkeurig getoond. Ook in bussen en aansluitend OV wordt vertraging vaak exact getoond, het zijn alleen de reisinformatiesystemen van NS zelf die de vertraging afronden.
Als je de exacte vertraging toont weet je wel meteen waar je als reiziger aan toe bent. Ik vind het persoonlijk best wel vervelend als ik op een perron sta, de trein van 15:07 "+5 minuten" heeft, en om 15:13 nog niet in zicht is. Dan zie ik liever "15:07 +7" zodat ik weet dat ik 'm over een minuut wél zou moeten kunnen verwachten. Als de vertraging dan verder oploopt zie ik dat ook meteen op het bord.
Als de verkeersleiding besluit dat een andere trein voor mag gaan, dan zal de informatie op de borden hoe dan ook wijzigen (er komt dan ineens een andere trein te staan).
Een kijkje naar hoe onze buurlanden het doen:
- Duitsland: DB toont vertraging ook afgerond ("etwa 5 Minuten später")
- België: toont oorspronkelijke vertrektijd met daarnaast vertraging in minuten
- VK: toont exacte verwachte tijd indien beschikbaar (21:19 Dartford, exp. 21:22), anders "Expected" of "Delayed".
Met "in bussen" bedoelde ik trouwens informatie in de bus over aansluitende treinen op een station.
We are shaping the future
Ook
Less alienation, more cooperation.
De sample size van 4300 is niet bizar hoog en ik weet niet of er een selection bias in zit, maar het ondersteunt wel wat ik eerder zei dat mijn voorkeur voor Java niet zozeer te maken heeft met de taal maar met het ecosysteem.
Ook interessant: https://blog.github.com/2...1-post-incident-analysis/
Postmortem van de GH outage.
[ Voor 15% gewijzigd door Hydra op 31-10-2018 09:27 ]
https://niels.nu
Sorry, maar ik vind javascript echt compleet kut qua ecosysteem (als het tooling gaat npm moat oa left-pad, het feit dat je schijnbaar 10 tools nodig hebt om een builtpipeline te krijgen) en toch staat die op #1? Verder weet ik niet precies waar je de voorkeur van java vanwege het ecosysteem vandaan haalt, maar er word volgens mij in die hele survey niets genoemd over het ecosysteem?Hydra schreef op woensdag 31 oktober 2018 @ 09:26:
Vond deze toevallig vandaag: https://jaxenter.com/java...s-open-source-151240.html
De sample size van 4300 is niet bizar hoog en ik weet niet of er een selection bias in zit, maar het ondersteunt wel wat ik eerder zei dat mijn voorkeur voor Java niet zozeer te maken heeft met de taal maar met het ecosysteem.
[...]
Helemaal mee eens hoor. Het JS ecosysteem heeft veel rommel. Dat het actief is, betekent niet perse dat de kwaliteit goed is.Gropah schreef op woensdag 31 oktober 2018 @ 10:30:
Sorry, maar ik vind javascript echt compleet kut qua ecosysteem (als het tooling gaat npm moat oa left-pad, het feit dat je schijnbaar 10 tools nodig hebt om een builtpipeline te krijgen) en toch staat die op #1?
Ik heb een tijdje geleden uitgelegd in een post hier (n.a.v. iets dat @Lethalis zei volgens mij) dat mijn voorkeur naar Java over bijvoorbeeld C# vooral komt door het grote open source ecosysteem/de community en niet de taal zelf. Ik kwam die link tegen vandaan en vond het treffend dat het verschil in OS activiteit zo groot is.Verder weet ik niet precies waar je de voorkeur van java vanwege het ecosysteem vandaan haalt, maar er word volgens mij in die hele survey niets genoemd over het ecosysteem?
Bedoel het niet als 'bewijs' of een 'told you so' ofzo, vond het alleen interessant genoeg om te delen.
https://niels.nu
Kan je meteen lekker Swift schrijven voor Android, iOS, Mac, Windows of WebAssembly 👌
Electron is alleen handig als je precies dezelfde UX/UI wil hebben overal. Maar ja, dat werkt ook niet altijd lekker imho
En als je je eindgebruikers haat. Electron-based applicatiesalienfruit schreef op woensdag 31 oktober 2018 @ 14:22:
Electron is alleen handig als je precies dezelfde UX/UI wil hebben overal.

Ik heb nog liever te maken met Java Swing.
[ Voor 10% gewijzigd door Alex) op 31-10-2018 14:36 ]
We are shaping the future
Maar het is dringend en ze zeggen nog vriendelijk hoiMatis schreef op woensdag 31 oktober 2018 @ 14:34:
Sinds een aantal dagen hardnekkige spammers in de spambox:
[Afbeelding]

Het Java ecosysteem is inderdaad veel groter.Hydra schreef op woensdag 31 oktober 2018 @ 10:51:
[...]
Ik heb een tijdje geleden uitgelegd in een post hier (n.a.v. iets dat @Lethalis zei volgens mij) dat mijn voorkeur naar Java over bijvoorbeeld C# vooral komt door het grote open source ecosysteem/de community en niet de taal zelf. Ik kwam die link tegen vandaan en vond het treffend dat het verschil in OS activiteit zo groot is.
Vandaag toch een beetje plezier in mijn werk: voor een nieuw project besloten om mezelf uit te dagen en dus helemaal voor ASP.NET Core gegaan. Tevens een Docker image van mijn applicatie gemaakt en deze als container gedraaid.
Vervolgens meteen kennis gemaakt met Razor Pages die het maken van websites een stuk simpeler maken. Hoef ik niet meteen overal een Controller voor te schrijven.
En in plaats van onze interne data access library meteen voor Dapper gegaan.
.NET development kán wel leuk zijn
Ask yourself if you are happy and then you cease to be.
Als je met Java projecten niet uitkijkt zit je ook in Java 5 met JSP te werken en dit op een antieke Websphere te deployen hoorLethalis schreef op woensdag 31 oktober 2018 @ 15:26:
.NET development kán wel leuk zijnHet is gewoon jammer dat ik zo vaak Windows.Forms zooi moet doen en dat verkleurt mijn beeld een beetje.
https://niels.nu
Gelukkig heb ik de keuze uit vele projecten doorgaans. Heb nu ook weer een collega die achter me aan zit om doorontwikkeling te gaan doen op één of ander primitief CRUD-interfaceje in .Net MVC en plain javascript / css (ok, nog wel met jQuery, maar dat is het dan ook).Hydra schreef op woensdag 31 oktober 2018 @ 15:30:
[...]
Als je met Java projecten niet uitkijkt zit je ook in Java 5 met JSP te werken en dit op een antieke Websphere te deployen hoor
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Asp net core is best slick. Ik gebruik nu Giraffe in combinatie met Kestrel, dat is best mooi. Publishen en dan zo in een container werkt ook goed. Enige wat me weer even dwarszat was dat als je een console gebruikt .Net je applicatie stil zet. Met screen zo op te lossen.Lethalis schreef op woensdag 31 oktober 2018 @ 15:26:
[...]
Het Java ecosysteem is inderdaad veel groter.
Vandaag toch een beetje plezier in mijn werk: voor een nieuw project besloten om mezelf uit te dagen en dus helemaal voor ASP.NET Core gegaan. Tevens een Docker image van mijn applicatie gemaakt en deze als container gedraaid.
Vervolgens meteen kennis gemaakt met Razor Pages die het maken van websites een stuk simpeler maken. Hoef ik niet meteen overal een Controller voor te schrijven.
En in plaats van onze interne data access library meteen voor Dapper gegaan.
.NET development kán wel leuk zijnHet is gewoon jammer dat ik zo vaak Windows.Forms zooi moet doen en dat verkleurt mijn beeld een beetje.
Less alienation, more cooperation.
care to elaborate ?Sandor_Clegane schreef op woensdag 31 oktober 2018 @ 20:16:
[...]
Enige wat me weer even dwarszat was dat als je een console gebruikt .Net je applicatie stil zet. Met screen zo op te lossen.
https://fgheysels.github.io/
Ik heb een server process met daarin een Console.Readline(). Blijkbaar als je dat op Linux draait en je zet hem naar de achtergrond met nohup of bg dan gebruikt .Net een system call om iets met de terminal te doen wat net helemaal lekker gaat en dan stopt je applicatie. Het proces wordt krijgt dan de status "stopped".
Zie: https://stackoverflow.com...round-using-sudo-on-linux
Uitleg: https://github.com/dotnet/cli/issues/6216
Waarom gebruik je dan een console? Het is nog in progress.
[ Voor 8% gewijzigd door Sandor_Clegane op 31-10-2018 22:34 ]
Less alienation, more cooperation.
Het viel me namelijk een beetje op dat een webapplicatie die ik geschreven heb ineens lege pagina's serveerde, en juist bij mensen die er via Facebook kwamen. Blijkt Facebook dus gewoon een query achter een fragment in de url te plaatsen, en dat zorgt er wel voor dat dingen sneuvelen.
Daarom gebruiken wij op onze Linux servers byobu. Een wrapper om screens en Tmux heen. Op die manier kun je meerdere shells binnen dezelfde sessie openen en hoef je dus ook niet meer naar de achtergrond te duwen.Sandor_Clegane schreef op woensdag 31 oktober 2018 @ 22:32:
Ik heb een server process met daarin een Console.Readline(). Blijkbaar als je dat op Linux draait en je zet hem naar de achtergrond met nohup of bg dan gebruikt .Net een system call om iets met de terminal te doen wat net helemaal lekker gaat en dan stopt je applicatie. Het proces wordt krijgt dan de status "stopped".
Zie: https://stackoverflow.com...round-using-sudo-on-linux
Uitleg: https://github.com/dotnet/cli/issues/6216
Waarom gebruik je dan een console? Het is nog in progress.
If money talks then I'm a mime
If time is money then I'm out of time
https://github.com/dotnet/corefx/pull/18003Sandor_Clegane schreef op woensdag 31 oktober 2018 @ 22:32:
[...]
Ik heb een server process met daarin een Console.Readline(). Blijkbaar als je dat op Linux draait en je zet hem naar de achtergrond met nohup of bg dan gebruikt .Net een system call om iets met de terminal te doen wat net helemaal lekker gaat en dan stopt je applicatie. Het proces wordt krijgt dan de status "stopped".
Fixed in 2.0 milestone een jaar geleden?
PS
Dat is geen garantie dat het probleem niet terugkeert natuurlijk. Heb op full CLR ooit met een MailMessage bug te maken gehad (bijlagen max 3MB) die serieus 2 keer gefixt moest worden.
Een regressie die met een test simpelweg voorkomen had kunnen worden.
[ Voor 19% gewijzigd door Lethalis op 01-11-2018 07:04 ]
Ask yourself if you are happy and then you cease to be.
Screen fixed het, dat van byobu ga ik eens bekijken. Thanks.
Less alienation, more cooperation.
https://join.slack.com/t/...EwODA0YjY3YzYyZTMzMDI3MTk
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Jeej nog iets om toe te voegen aan het lijstjeFiresphere schreef op donderdag 1 november 2018 @ 08:48:
Even een kleine reminder. Omdat IRC tegenwoordig wel heel erg oldskool is, is er een Slack workspace. Join the movement!
https://join.slack.com/t/...EwODA0YjY3YzYyZTMzMDI3MTk
Without nipples, boobs are pointless - 365 project - In mijn hoofd is het alle dagen Kerstmis - What type of bees make milk? Boobies! - What type of bees are scary? BoooOOOOOooobeees! - Cactusliefhebster
We are shaping the future
It's Slack,je kan het mutenElkeBxl schreef op donderdag 1 november 2018 @ 09:11:
[...]
Jeej nog iets om toe te voegen aan het lijstjeMeerdere groepchats op Messenger, meerdere groepchats op Whatsapp, hoop collega's op Telegram, 1 Discord kanaal, 1 Slack kanaal, Teams op het werk, paar DM conversaties op Twitter, ... En dan staan mensen versteld dat ik niet altijd antwoord
Maar ok, I joined
Gah... not helpful
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Hier stopte ik met lezen.Firesphere schreef op donderdag 1 november 2018 @ 08:48:
Even een kleine reminder. Omdat IRC tegenwoordig wel heel erg oldskool is,
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Sure. HugOps!
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Als het een achtergrond proces moet zijn, waarom maak je dan gebruik van deSandor_Clegane schreef op woensdag 31 oktober 2018 @ 22:32:
[...]
Ik heb een server process met daarin een Console.Readline(). Blijkbaar als je dat op Linux draait en je zet hem naar de achtergrond met nohup of bg dan gebruikt .Net een system call om iets met de terminal te doen wat net helemaal lekker gaat en dan stopt je applicatie. Het proces wordt krijgt dan de status "stopped".
Zie: https://stackoverflow.com...round-using-sudo-on-linux
Uitleg: https://github.com/dotnet/cli/issues/6216
Waarom gebruik je dan een console? Het is nog in progress.
1
| BackgroundService |
1
| HostBuilder |
Argh; hoe scrhijf je hier weer inline code ?
[ Voor 4% gewijzigd door whoami op 01-11-2018 09:50 . Reden: te veel markdown geschreven de laatste tijd ]
https://fgheysels.github.io/
Note the cool in oldskool.Firesphere schreef op donderdag 1 november 2018 @ 08:48:
Even een kleine reminder. Omdat IRC tegenwoordig wel heel erg oldskool is, is er een Slack workspace. Join the movement!
https://join.slack.com/t/...EwODA0YjY3YzYyZTMzMDI3MTk
kut-slack
https://fgheysels.github.io/
Een pluspuntje voor Teams: conference calls werken veel beter dan in Skype for Business.
We are shaping the future
Is niet mijn post. Die kwam ik tegen met dezelfde symptomen.whoami schreef op donderdag 1 november 2018 @ 09:49:
[...]
Als het een achtergrond proces moet zijn, waarom maak je dan gebruik van decode:en de
1 BackgroundServicecode:class ?
1 HostBuilder
edit:
Argh; hoe scrhijf je hier weer inline code ?
Less alienation, more cooperation.
Als veel mensen er niks van snappen is er misschien wel iets mis mee...R4gnax schreef op zondag 28 oktober 2018 @ 23:44:
[...]
Weinig mis met CSS. Veel mensen snappen er gewoon niets van en hebben geen zin zich er in te verdiepen, maar geven er liever op af. Als ze niet binnen 5 minuten snappen hoe het werkt omdat de werkingswijze en opzet buiten hun normale denkwereldje ligt, dan is het meteen ruk, klote en een "clusterfuck".
Maar help me eens even dan: Hoe kan ik in CSS zeggen voor elkaar krijgen dat ik twee stylen combineer en nog een extra property toevoeg, om aan DRY te doen zeg maar?
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
farlane schreef op donderdag 1 november 2018 @ 20:55:
[...]
Als veel mensen er niks van snappen is er misschien wel iets mis mee...
Maar help me eens even dan: Hoe kan ik in CSS zeggen voor elkaar krijgen dat ik twee stylen combineer en nog een extra property toevoeg, om aan DRY te doen zeg maar?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| .panel { background : #eee; border : 1px solid #888; display : block; padding : 20px; } .panel--rounded { border-radius : 20px; } .panel--spacy { padding : 40px; } |
En combineren maar in je HTML:
1
2
3
4
| <div class="panel">base</div> <div class="panel panel--rounded">rounded</div> <div class="panel panel--spacy">extra spacy</div> <div class="panel panel--rounded panel--spacy">extra spacy + rounded</div> |
Nou... moeilijk hoor.

[ Voor 18% gewijzigd door R4gnax op 01-11-2018 22:07 ]
Over DRY gesprokenR4gnax schreef op donderdag 1 november 2018 @ 22:05:
[...]
Cascading Stylesheet:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 .panel { background : #eee; border : 1px solid #888; display : block; padding : 20px; } .panel--rounded { border-radius : 20px; } .panel--spacy { padding : 40px; }
En combineren maar in je HTML:
HTML:
1 2 3 4 <div class="panel">base</div> <div class="panel panel--rounded">rounded</div> <div class="panel panel--spacy">extra spacy</div> <div class="panel panel--rounded panel--spacy">extra spacy + rounded</div>
Nou... moeilijk hoor.
Je wilt dat gewoon in je CSS kunnen doen natuurlijk..
Waarom is dat in strijd met DRY? DRY houdt ook niet in dat je een Class X niet interface A en B mag inheriten omdat je dat ergens anders ook doet.EddoH schreef op vrijdag 2 november 2018 @ 07:11:
[...]
Over DRY gesproken![]()
Je wilt dat gewoon in je CSS kunnen doen natuurlijk..
DRY wordt nog wel eens verkeerd opgevat in de zin dat er nergens een letter code hetzelfde zou mogen zijn, maar dat is natuurlijk niet het geval.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Nee maar als je in je HTML file 100 keer een 'base' CSS Class moet gaan toevoegen, dan vind ik dat wel tegen DRY ingaan. Punt is dat je dan in CSS vaak gewoon een kopie van een 'base' class maakt die je uitbreidt met specifiekere properties. En aan het eind heb je of 100 deels gelijke CSS classes of 100 keer die base Class in je HTML staan.Mugwump schreef op vrijdag 2 november 2018 @ 10:36:
[...]
Waarom is dat in strijd met DRY? DRY houdt ook niet in dat je een Class X niet interface A en B mag inheriten omdat je dat ergens anders ook doet.
DRY wordt nog wel eens verkeerd opgevat in de zin dat er nergens een letter code hetzelfde zou mogen zijn, maar dat is natuurlijk niet het geval.
Alsjeblieft.. https://jsfiddle.net/58wg1hc6/EddoH schreef op vrijdag 2 november 2018 @ 11:01:
[...]
Nee maar als je in je HTML file 100 keer een 'base' CSS Class moet gaan toevoegen, dan vind ik dat wel tegen DRY ingaan. Punt is dat je dan in CSS vaak gewoon een kopie van een 'base' class maakt die je uitbreidt met specifiekere properties. En aan het eind heb je of 100 deels gelijke CSS classes of 100 keer die base Class in je HTML staan.
]|[ Apple Macbook Pro Retina 13" ]|[
En daar gaan we alDeluxZ schreef op vrijdag 2 november 2018 @ 11:20:
[...]
Alsjeblieft.. https://jsfiddle.net/58wg1hc6/
Na nog 5 andere wensen zit je op 10 verschillende techs en frameworks die al elkaars 'flaws' proberen op te lossen.
Het is gewoon SCSS ... Verder NIKS. Je kan het ook gewoon uittypen in CSS hoor als je dat liever wiltEddoH schreef op vrijdag 2 november 2018 @ 11:24:
[...]
En daar gaan we al![]()
Na nog 5 andere wensen zit je op 10 verschillende techs en frameworks die al elkaars 'flaws' proberen op te lossen.
1
2
3
4
5
6
7
8
9
10
11
12
| .panel, .panel--spacy, .panel--rounded { background: #eee; border: 1px solid #888; display: block; padding: 20px; } .panel--rounded { border-radius: 20px; } .panel--spacy { padding: 40px; } |
[ Voor 33% gewijzigd door DeluxZ op 02-11-2018 11:27 ]
]|[ Apple Macbook Pro Retina 13" ]|[
Haskell sucks, you read it here firstfarlane schreef op donderdag 1 november 2018 @ 20:55:
[...]
Als veel mensen er niks van snappen is er misschien wel iets mis mee...
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
Ja, zo kan ik het ook, het is gewoon <insert random library>, verder niks!DeluxZ schreef op vrijdag 2 november 2018 @ 11:25:
[...]
Het is gewoon SCSS ... Verder NIKS. Je kan het ook gewoon uittypen in CSS hoor als je dat liever wilt
Cascading Stylesheet:
1 2 3 4 5 6 7 8 9 10 11 12 .panel, .panel--spacy, .panel--rounded { background: #eee; border: 1px solid #888; display: block; padding: 20px; } .panel--rounded { border-radius: 20px; } .panel--spacy { padding: 40px; }
De 'native' oplossing vind ik gewoon niet elegant. Let's agree to disagree.
Wat is er niet elegant aan? Het is dit of niet 'DRY'... pick your favoriteEddoH schreef op vrijdag 2 november 2018 @ 11:33:
[...]
Ja, zo kan ik het ook, het is gewoon <insert random library>, verder niks!
De 'native' oplossing vind ik gewoon niet elegant. Let's agree to disagree.
]|[ Apple Macbook Pro Retina 13" ]|[
Hoeder van het Noord-Meierijse dialect
Ik weet niet waarom je dat zou doen eerlijk gezegd. Dan zou je eerder eens kritisch naar je design moeten kijken. CSS heeft ook de optie 'inherit' als je zaken wilt erven van parent elementen bijvoorbeeld.EddoH schreef op vrijdag 2 november 2018 @ 11:01:
[...]
Nee maar als je in je HTML file 100 keer een 'base' CSS Class moet gaan toevoegen, dan vind ik dat wel tegen DRY ingaan. Punt is dat je dan in CSS vaak gewoon een kopie van een 'base' class maakt die je uitbreidt met specifiekere properties. En aan het eind heb je of 100 deels gelijke CSS classes of 100 keer die base Class in je HTML staan.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Het "probleem" met CSS: je kunt het jezelf zo moeilijk maken als je maar wilt. Wat vaak het probleem is: er is ergens boven in de style 'inheritance' een "(ontwerp) fout" gemaakt, en dat proberen ze dan met selectors op te lossen door bepaalde properties te overschrijven. Of meerdere class names die in combinatie met een ander parent class net even iets anders doet, e.d. Hun source bestand is dan "cleaner", maar de HTML en output CSS worden een beetje tricky.Harrie_ schreef op vrijdag 2 november 2018 @ 11:57:
Ik snap de discussie hierboven m.b.t. CSS niet zo goed. Waarom zou je een hoop dubbele code in je CSS moeten hebben dan; je kunt toch prima meerdere css-classes toevoegen aan een html-element?
Gesteld werd dat er niets mis is met CSS. Nu gebruik je SASS om een flaw in CSS op te lossen. We kunnen dus stellen dat er wel iets mis is met CSS. Het mist definieerbare constanten en functies.
[ Voor 7% gewijzigd door .oisyn op 02-11-2018 12:42 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
https://niels.nu
Devschuur coffee corner?
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Precies!.oisyn schreef op vrijdag 2 november 2018 @ 12:40:
Devschuur coffee corner?
https://niels.nu
Ik snap je niet 100% wat je bedoeld.Mugwump schreef op vrijdag 2 november 2018 @ 11:59:
[...]
Ik weet niet waarom je dat zou doen eerlijk gezegd. Dan zou je eerder eens kritisch naar je design moeten kijken. CSS heeft ook de optie 'inherit' als je zaken wilt erven van parent elementen bijvoorbeeld.
Anyway, het blijft een smaak discussie. Ik vind CSS enkele functionaliteiten missen die je code netter en beter onderhoudbaar maken. Meerdere mensen vinden dat blijkbaar niet.
Ik ben geen (front-end) developer, dus wellicht mis ik dingen.
Argumenten dat het met SASS op te lossen is vind ik typerend voor de webdevelopment wereld. Het is pleisters plakken, zoals @.oisyn ook aangaf.
So let's talk coffee! Ik ben op zoek naar een goeie volautomatische espressomachine. Iemand suggesties?
Een barista inhuren?EddoH schreef op vrijdag 2 november 2018 @ 13:27:
[...]
So let's talk coffee! Ik ben op zoek naar een goeie volautomatische espressomachine. Iemand suggesties?
Read the code, write the code, be the code!
De CSS van de koffieapparaten!EddoH schreef op vrijdag 2 november 2018 @ 13:27:
So let's talk coffee! Ik ben op zoek naar een goeie volautomatische espressomachine. Iemand suggesties?
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
Dit is de beste koffieEddoH schreef op vrijdag 2 november 2018 @ 13:27:
[...]
So let's talk coffee! Ik ben op zoek naar een goeie volautomatische espressomachine. Iemand suggesties?
Lekker op de bank
Pff. Heb een Solis hand apparaat. Automaten komen niet in de buurt.EddoH schreef op vrijdag 2 november 2018 @ 13:27:
So let's talk coffee! Ik ben op zoek naar een goeie volautomatische espressomachine. Iemand suggesties?
[ Voor 4% gewijzigd door Hydra op 02-11-2018 13:40 ]
https://niels.nu
Dat vind ik toch een beetje als stellen dat Java of C# pleisters zijn omdat Java bytecode en CIL ruk zijn. SASS of Less compileert gewoon naar CSS. Als je iets als als Vaadin of GWT gebruikt dan compileer je ook gewoon naar javascript, evenals zaken als Typescript. Ik zou de front end evolutie eerder in die trend plaatsen. Je hebt primitieve tools die door de onderliggende laag begrepen worden (browsers versus OS'en / hardware). In de loop der tijd komen er 'hogere talen' die uiteindelijk weer 'compilen' naar de basale instructies die door het onderliggende systeem worden begrepen.EddoH schreef op vrijdag 2 november 2018 @ 13:27:
[...]
Ik snap je niet 100% wat je bedoeld.
Anyway, het blijft een smaak discussie. Ik vind CSS enkele functionaliteiten missen die je code netter en beter onderhoudbaar maken. Meerdere mensen vinden dat blijkbaar niet.
Ik ben geen (front-end) developer, dus wellicht mis ik dingen.
Argumenten dat het met SASS op te lossen is vind ik typerend voor de webdevelopment wereld. Het is pleisters plakken, zoals @.oisyn ook aangaf.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Pff, da's hetzelfde als je deployment naar productie handmatig doen. 'Veel beter want je hebt veel meer controle'Hydra schreef op vrijdag 2 november 2018 @ 13:38:
[...]
Pff. Heb een Solis hand apparaat. Komt niet in de buurt van automaten
Heb je wel een punt. Een continuous coffee delivery pipeline opzetten gaat hiermee niet lukken. Maargoed; daar heb je ongeschoold personeel voor.EddoH schreef op vrijdag 2 november 2018 @ 13:40:
Pff, da's hetzelfde als je deployment naar productie handmatig doen. 'Veel beter want je hebt veel meer controle'
M'n dochter
https://niels.nu
Ik geef toch ook een voorbeeld hoe je dit specifieke "probleem" kunt oplossen met plain CSS. Dat CSS bepaalde dingen mist wat SASS/LESS wel bied ben ik het mee eens..oisyn schreef op vrijdag 2 november 2018 @ 12:39:
[...]
Gesteld werd dat er niets mis is met CSS. Nu gebruik je SASS om een flaw in CSS op te lossen. We kunnen dus stellen dat er wel iets mis is met CSS. Het mist definieerbare constanten en functies.
]|[ Apple Macbook Pro Retina 13" ]|[
Dat hoeft natuurlijk niet, het voorbeeld is volgens BEM-syntax geschreven, dat bedacht voor pretty much dit (en andere dingen). Je kan het prima opschrijven als class="panel spacy rounded" maar dan ga je weer andere issues krijgen die je op andere manieren zult moeten oplossen.EddoH schreef op vrijdag 2 november 2018 @ 11:01:
Nee maar als je in je HTML file 100 keer een 'base' CSS Class moet gaan toevoegen, dan vind ik dat wel tegen DRY ingaan.
Met alle respect, CSS is zoals elke taal niet perfect, maar de problemen die jij beschrijft zijn IMO toch echt PEBKAC te noemen.
Nogmaals, met all respect maar dat is gewoon PEBKAC, dit zal bij mij direct leiden tot een geweigerde pull requests. "Ga maar refactoren..."EddoH schreef op vrijdag 2 november 2018 @ 11:01:
Punt is dat je dan in CSS vaak gewoon een kopie van een 'base' class maakt die je uitbreidt met specifiekere properties. En aan het eind heb je of 100 deels gelijke CSS classes of 100 keer die base Class in je HTML staan.
Ik geloof je direct, ik heb alleen nog geen elegante oplossing gezien hier zonder SASS waar je dus niet continu je HTML volpropt met allerhande classes maar gewoon in je CSS een combinatie van meerdere classes kunt maken. Het zal vast aan mij liggen, ik ben de eerste die dat toe zal geven. Gelukkig ben ik geen front-ender.Ed Vertijsment schreef op vrijdag 2 november 2018 @ 13:54:
[...]
Nogmaals, met all respect maar dat is gewoon PEBKAC, dit zal bij mij direct leiden tot een geweigerde pull requests. "Ga maar refactoren..."
Ja, maar dat is het probleem met voorbeelden. Iedereen gaat all-in op een voorbeeld en vergeet daarbij de kern van de discussie. Dit specifieke probleem is wellicht op te lossen, maar het blijft lelijk om overal hardcoded values te gebruiken. Dat leerden we 30 jaar geleden al af bij het programmeren, maar blijkbaar heeft de ontwerper van CSS die memo niet ontvangen oidDeluxZ schreef op vrijdag 2 november 2018 @ 13:53:
[...]
Ik geef toch ook een voorbeeld hoe je dit specifieke "probleem" kunt oplossen met plain CSS
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
In dat geval prima, ik denk dat ik ook walgelijke constructies op kan zetten op de backendEddoH schreef op vrijdag 2 november 2018 @ 14:03:
[...]
Ik geloof je direct, ik heb alleen nog geen elegante oplossing gezien hier zonder SASS waar je dus niet continu je HTML volpropt met allerhande classes maar gewoon in je CSS een combinatie van meerdere classes kunt maken. Het zal vast aan mij liggen, ik ben de eerste die dat toe zal geven. Gelukkig ben ik geen front-ender.

Tja, ergens moet de "composition" plaatsvinden. Als je 2 classes nodig hebt, heb je dus minstens 2 scenario's voor hetzelfde component. Dan wil je op elk component dat scenario willen definen, en dat doe je, tada, door er een class op te zetten.EddoH schreef op vrijdag 2 november 2018 @ 14:03:ik heb alleen nog geen elegante oplossing gezien hier zonder SASS waar je dus niet continu je HTML volpropt met allerhande classes
Dit is gewoon composition over inheritance, met scss of less kun je inheritance of zelfs multiple inheritance bereiken maar de vraag is waarom je dat zou willen.
Die compositie wil je niet (altijd, geforceerd) in je HTML doen, zeg ik als software engineer (of in jouw woorden: iemand zonder kennis van zaken).Ed Vertijsment schreef op vrijdag 2 november 2018 @ 14:18:
[...]
In dat geval prima, ik denk dat ik ook walgelijke constructies op kan zetten op de backendals ik in een stuk zit waar ik niet geremd wordt door kennis van zaken.
[...]
Tja, ergens moet de "composition" plaatsvinden. Als je 2 classes nodig hebt, heb je dus minstens 2 scenario's voor hetzelfde component. Dan wil je op elk component dat scenario willen definen, en dat doe je, tada, door er een class op te zetten.
Dit is gewoon composition over inheritance, met scss of less kun je inheritance of zelfs multiple inheritance bereiken maar de vraag is waarom je dat zou willen.
Ik begrijp dat jij hier geen punt van maakt. Prima. Kwestie van smaak I guess.
Dit wil ik gelijk de wereld uit helpen, ik zij dat over mijzelf als ik sommige dingen in de backend probeer uit te vogelen,EddoH schreef op vrijdag 2 november 2018 @ 14:22:
(of in jouw woorden: iemand zonder kennis van zaken).
Ik ben dan wel benieuwd naar je beweegredenen omdat niet daar te doen maar ergens anders (waar je dan vervolgens gewoon sass voor kan gebruiken, we schrijven ook geen assembly meer). Ik zeg dat niet om je punt te aan te vallen, puur uit interesse.EddoH schreef op vrijdag 2 november 2018 @ 14:22:
Die compositie wil je niet (altijd, geforceerd) in je HTML doen
Stroman, er werd niet gesteld dat CSS iets mist omdat je walgelijke constructies op kán zetten.Ed Vertijsment schreef op vrijdag 2 november 2018 @ 14:18:
[...]
In dat geval prima, ik denk dat ik ook walgelijke constructies op kan zetten op de backend
Je linkte eerder naar iets over BEM, en dan kom je het volgende tegen:
Dat klinkt, in mijn ogen, heel erg als een lapmiddel. Het is een best practice om, binnen de limitaties van CSS, toch net en modulair te kunnen werken.— But wait!
My HTML looks all bloated and messy with BEM!
This seems to be the most frequently mentioned argument against BEM.
Remember, until CSS supports scope, there is no way to get around inheritance in modular environments other than sticking unique CSS classes (or attributes) to any given element.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Zeker waar, al vind ik BEM alles behalve lelijk, maar zijn error codes ook niet een lapmiddel bij gebrek aan exceptions (so I'm told, not sure).[b].oisyn schreef op vrijdag 2 november 2018 @ 14:36:[/b
Je linkte eerder naar iets over BEM, en dan kom je het volgende tegen:
[...]
Dat klinkt, in mijn ogen, heel erg als een lapmidel. Het is een best practice om, binnen de limitaties van CSS, toch net en modulair te kunnen werken.
Ik heb eerder al aangegeven dat CSS, net zoals elke andere taal niet perfect is. Dat echter het probleem dat werd gesteld gewoon neerkwam op er niet juist mee omgaan.
CSS bied standaard vrij weinig bescherming tegen foutief programmeren, dat kun je ook over C zeggen, en sure dat is whataboutism maar het bied wellicht enig perspectief. Hoewel ik ook graag nieuwe features in CSS zie komen die de zooi verbeteren is het ook aan de programmeur om daar gewoon op een goede manier mee om te gaan.
Je haalt nu hardcoded values erbij en wil variables hebben. Volgens mij heeft dat niets te maken met het probleem waar we mee begonnen dat je meerdere classes op een element nodig hebt als je wat extra wil? Dat is precies wat BEM syntax voorschrijft. Om in het voorbeeld te blijven panel = block. rounded space = modifier..oisyn schreef op vrijdag 2 november 2018 @ 14:05:
[...]
Ja, maar dat is het probleem met voorbeelden. Iedereen gaat all-in op een voorbeeld en vergeet daarbij de kern van de discussie. Dit specifieke probleem is wellicht op te lossen, maar het blijft lelijk om overal hardcoded values te gebruiken. Dat leerden we 30 jaar geleden al af bij het programmeren, maar blijkbaar heeft de ontwerper van CSS die memo niet ontvangen oid.
]|[ Apple Macbook Pro Retina 13" ]|[
Euh.... ja? Not quite sure what you're getting atEd Vertijsment schreef op vrijdag 2 november 2018 @ 14:45:
[...]
Zeker waar, al vind ik BEM alles behalve lelijk, maar zijn error codes ook niet een lapmiddel bij gebrek aan exceptions (so I'm told, not sure).
Maar dan komen we weer op het punt wat ik al aanstipte in de eerste zin van mijn vorige post. Niemand heeft het over dat je lelijke shit kan maken in CSS. Het gaat om het feit dat je (en ik chargeer nu enorm) alléén maar lelijke shit kan maken in CSS. Net als in C trouwens, dus wat dat betreft goede analogieCSS bied standaard vrij weinig bescherming tegen foutief programmeren, dat kun je ook over C zeggen, en sure dat is whataboutism maar het bied wellicht enig perspectief. Hoewel ik ook graag nieuwe features in CSS zie komen die de zooi verbeteren is het ook aan de programmeur om daar gewoon op een goede manier mee om te gaan.
Persoonlijk vind ik het gemis aan composition in CSS dan weer een van de mindere problemen overigens, al zou het mooi zijn als je dat op CSS niveau op kan lossen ipv op HTML niveau. Ik zie liever de mogelijkheid om constanten, functies en expressies te kunnen gebruiken, zodat je je 'theme' vooraf kunt definieren en dat het makkelijk aanpasbaar is.
Aan de andere kant, het is natuurlijk zo dat je wel prima CSS generators kan gebruiken. Om de analogie met C aan te houden, een C compiler is ook maar een generator die ASM uitspuugt
Nee, constanten, variabelen zijn variabelDeluxZ schreef op vrijdag 2 november 2018 @ 14:55:
[...]
Je haalt nu hardcoded values erbij en wil variables hebben.
[ Voor 17% gewijzigd door .oisyn op 02-11-2018 15:02 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Volgens mij gebruiken we allebei een hele hoop woorden om voor 90% het met elkaar eens te zijn. Ik concludeer het volgende en voel je vrij om deze te challangen..oisyn schreef op vrijdag 2 november 2018 @ 14:56:
[...]
Euh.... ja? Not quite sure what you're getting at
[...]
Maar dan komen we weer op het punt wat ik al aanstipte in de eerste zin van mijn vorige post. Niemand heeft het over dat je lelijke shit kan maken in CSS. Het gaat om het feit dat je (en ik chargeer nu enorm) alléén maar lelijke shit kan maken in CSS. Net als in C trouwens, dus wat dat betreft goede analogie.
Persoonlijk vind ik het gemis aan composition in CSS dan weer een van de mindere problemen overigens, al zou het mooi zijn als je dat op CSS niveau op kan lossen ipv op HTML niveau. Ik zie liever de mogelijkheid om constanten, functies en expressies te kunnen gebruiken, zodat je je 'theme' vooraf kunt definieren en dat het makkelijk aanpasbaar is.
Aan de andere kant, het is natuurlijk zo dat je wel prima CSS generators kan gebruiken. Om de analogie met C aan te houden, een C compiler is ook maar een generator die ASM uitspuugt
- CSS is tamelijk beperkt.
- Het is aan een dev om daar fatsoenlijk mee om te gaan.
- Het hoeft niet persé in prut te resulteren als je de juiste patterns gebruikt en weet watje doet.
- Die patterns zijn nu eenmaal lapmiddelen om de taal een beetje te helpen, zoals vaker gebeurd is.
Overigens tik ik zelden vanilla CSS maar kickt er altijd wel iets van scss/postcss voordat de boel de browser raakt.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Wat is het verschil in een niet mutable taal als CSS?
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Dat is een verkeerde vraagstelling. Je vraag is wat variabelen te zoeken hebben in een niet mutable taal als CSS. Dat er een verschil zit tussen constanten en variabelen lijkt me vrij evident, en dat is onafhankelijk van de context.Sebazzz schreef op vrijdag 2 november 2018 @ 15:05:
[...]
Wat is het verschil in een niet mutable taal als CSS?
.edit: oh trouwens dat is niet waar. Variabelen hebben er wel wat te zoeken, als parameters van functies.
.edit2: Nou ja, er zit denk ik een verschil tussen wiskundige variabelen en variabelen in imperatieve programmeertalen. Iets als Haskell noemt zijn variabelen ook variabelen, en die zijn ook duidelijk niet variabel. Ik denk dat je wat ik bedoel in CSS ook best variabelen kunt noemen, ja.
[ Voor 31% gewijzigd door .oisyn op 02-11-2018 15:13 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
🠕 This side up
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Kun je de corner size niet doen met REM units ?.oisyn schreef op vrijdag 2 november 2018 @ 14:56:
[...]
Nee, constanten, variabelen zijn variabel. Ik haal niets erbij, de discussie ging om de tekortkomingen van CSS. En volgens mij ging het specifiek om DRY. Hoewel het niet in het voorbeeld naar voren kwam, zijn al die pixelgroottes voor corners en padding ook gewoon een vorm van DRY, want meestal zijn ze aan elkaar gerelateerd. Je kunt niet zomaar 1 cornersize aanpassen zonder ook 10 andere waardes aan te passen om het er nog steeds mooi uit te laten zien, bij wijze van spreken.
]|[ Apple Macbook Pro Retina 13" ]|[
Dus stel je bouwt met een server side MVC framework een website, maar op bepaalde pagina's gebruik je JavaScript als een soort mini SPA om bijvoorbeeld een interactief grid te maken?
Vroeger deed ik dit met AngularJS. Ik vond het handig dat ik het ff snel op een bestaande pagina kon integreren.
Nu heb ik laatst aan een echt Angular project gewerkt, waar de hele webapplicatie Angular en TypeScript is... En ik vind het eigenlijk een draak. Het KISS principe is overboord en het project valt van de node_modules dependency hell regelmatig uit elkaar.
Voor een ander project ben ik met Razor Pages aan het spelen en het is zoveel simpeler voor rechttoe en rechtaan een website bouwen.
En als ik dan op sommige pagina's waar het nuttig is, een simpel JavaScript framework gebruik vind ik dat voldoende (al vraag ik me wel af wat dit anno nu dan moet worden without resorting to jQuery, wellicht ReactJS).
Nu gaan er vast mensen schreeuwen dat het niet handig is en dat anno nu alles client side moet, maar ik heb toch zo mijn twijfels.
Ik hou van minimalisme en eenvoud om tot een bepaald doel te komen. En voor 90% van de projecten waar ik aan werk, tellen de voordelen van alles client side doen minder zwaar mee.
Kijk, ik begrijp prima dat het schaalbaarheidsvoordelen biedt wanneer je tig users hebt, maar als ik een backoffice app bouw die door pakweg 10 man gebruikt wordt, boeit dat niet.
Daar zijn security en stabiliteit koning.
Hmm.
Ask yourself if you are happy and then you cease to be.
CSS inheritance moet je zien als mixins of traits, Die zijn vrij te stapelen of niet; jouw keuze.EddoH schreef op vrijdag 2 november 2018 @ 07:11:
[...]
Over DRY gesproken![]()
Je wilt dat gewoon in je CSS kunnen doen natuurlijk..
Het gedrag wat je er in vastlegt, leg je in elk geval maar 1 keer vast.
Als je dit met directe inheritance / extension in CSS op wilt gaan lossen krijg je een state-explosion waarbij je elke mogelijk combinatie moet gaan vastleggen. Dat vind je dan wel DRY? Kom op zeg...
[ Voor 4% gewijzigd door R4gnax op 02-11-2018 19:09 ]
Welkom bij Angular. Do not stay a while ...[b]Lethalis in "De Devschuur Coffee Corner - Iteratie ⓬"Nu heb ik laatst aan een echt Angular project gewerkt, waar de hele webapplicatie Angular en TypeScript is... En ik vind het eigenlijk een draak. Het KISS principe is overboord en het project valt van de node_modules dependency hell regelmatig uit elkaar.
VueJS is een bekende lichtgewicht. Een andere die ik zelf veel inzet is CanJS. Bitovi heeft met dat framework heel goed werk afgeleverd. Eeuwig zonde dat het nog steeds niet doorgebroken is.[b]Lethalis in "De Devschuur Coffee Corner - Iteratie ⓬"
Voor een ander project ben ik met Razor Pages aan het spelen en het is zoveel simpeler voor rechttoe en rechtaan een website bouwen.
En als ik dan op sommige pagina's waar het nuttig is, een simpel JavaScript framework gebruik vind ik dat voldoende (al vraag ik me wel af wat dit anno nu dan moet worden without resorting to jQuery, wellicht ReactJS).
Ik zou aan ReactJS niet beginnen; het eco-systeem is een rommeltje zonder guiding principles. Dat is pas echt node_modules hel. Iemand die daar nu instapt en technologie-keuzes moet gaan maken; alles bij elkaar moet gaan zoeken; etc. verzuipt daar gewoon in. Om enkel een project gestart te krijgen moet je eigenlijk al een halve expert zijn.
En nee; bootstrapping packages helpen daarbij echt niet veel. Die werken totdat je iets moet hebben wat net buiten de mal valt. Of totdat er ergens iets omvalt en je in de verste verte niet weet what-the-fuck er fout is gegaan.
Lang niet alles hoeft client-side. Alleen zijn er sommige dingen die je qua UI nou eenmaal niet handig vanuit de server kunt regelen. Heb je bijv. uitvouwmenu's die zich vertalen naar een zijwaarts uitschuivend dock-paneel voor mobile; dan wordt het al verleidelijk om dat stuk client-side te gaan regelen. Zeker als je ook nog met gelaagde menustructuren moet gaan werken en het zich een beetje gelikt moet gaan gedragen.[b]Lethalis in "De Devschuur Coffee Corner - Iteratie ⓬"
Nu gaan er vast mensen schreeuwen dat het niet handig is en dat anno nu alles client side moet, maar ik heb toch zo mijn twijfels.
Ik hou van minimalisme en eenvoud om tot een bepaald doel te komen. En voor 90% van de projecten waar ik aan werk, tellen de voordelen van alles client side doen minder zwaar mee.
Kijk, ik begrijp prima dat het schaalbaarheidsvoordelen biedt wanneer je tig users hebt, maar als ik een backoffice app bouw die door pakweg 10 man gebruikt wordt, boeit dat niet.
Daar zijn security en stabiliteit koning.
Hmm.
Heb je grote multi-step prijsopgaves zoals je in de reisindustrie heel vaak ziet, dan zul je ook al gauw iets client-side willen gaan doen met partial refreshes; loading spinners; etc. om alles voor de gebruikers zo gestroomlijnd mogelijk te houden.
Krijg je echter een simpele pagina met bedrijfsinformatie; een blog; of een contactformulier; ja, dan hou je het lekker bij server-side rendering.
[ Voor 7% gewijzigd door R4gnax op 02-11-2018 19:22 ]
Het een hoeft het ander toch niet uit te sluiten? Natuurlijk hoef je niet alles direct in CSS op te lossen, het is alleen jammer dat het überhaupt niet kan in vanilla CSS, dat is het enige wat ik aangeef. Als het niet handig zou zijn, waarom implementeren tools als LESS/SASS dat dan wel? Voor de lol? Uit doc van SASS:R4gnax schreef op vrijdag 2 november 2018 @ 19:08:
[...]
CSS inheritance moet je zien als mixins of traits, Die zijn vrij te stapelen of niet; jouw keuze.
Het gedrag wat je er in vastlegt, leg je in elk geval maar 1 keer vast.
Als je dit met directe inheritance / extension in CSS op wilt gaan lossen krijg je een state-explosion waarbij je elke mogelijk combinatie moet gaan vastleggen. Dat vind je dan wel DRY? Kom op zeg...
Ik snap werkelijk niet dat je er zo zwart wit tegenaan kijkt en zoveel aanstoot aan mijn opmerking neemt..Extend/Inheritance
This is one of the most useful features of Sass. Using @extend lets you share a set of CSS properties from one selector to another. It helps keep your Sass very DRY
Dat je het 'handig' met extend kunt bereiken, betekent niet gelijk dat het dan ook een goed idee is:EddoH schreef op vrijdag 2 november 2018 @ 19:52:
Als het niet handig zou zijn, waarom implementeren tools als LESS/SASS dat dan wel?
https://webinista.com/updates/dont-use-extend-sass/
https://www.sitepoint.com/avoid-sass-extend/
https://www.sitepoint.com/sass-extend-nobody-told-you/
https://csswizardry.com/2...tend-when-to-use-a-mixin/
https://oliverjash.me/201...ing-objects-in-oocss.html
https://www.smashingmagaz...ing-in-sass-without-mess/
En zo kan ik nog wel een waslijst bij elkaar pakken voor je.
[ Voor 7% gewijzigd door R4gnax op 02-11-2018 20:26 ]
Wat ik zo snel kan zien is dat al die artikelen ingaan op de implementatie van extend door Sass, niet zozeer het concept.R4gnax schreef op vrijdag 2 november 2018 @ 20:24:
[...]
Dat je het 'handig' met extend kunt bereiken, betekent niet gelijk dat het dan ook een goed idee is:
https://webinista.com/updates/dont-use-extend-sass/
https://www.sitepoint.com/avoid-sass-extend/
https://www.sitepoint.com/sass-extend-nobody-told-you/
https://csswizardry.com/2...tend-when-to-use-a-mixin/
https://oliverjash.me/201...ing-objects-in-oocss.html
https://www.smashingmagaz...ing-in-sass-without-mess/
En zo kan ik nog wel een waslijst bij elkaar pakken voor je.
Ik ga eens goed kijken naar VueJS. Heb daar eerder weleens iets over gelezen inderdaad. Voordeel is dat het veel lijkt op AngularJS wat ik al ken.R4gnax schreef op vrijdag 2 november 2018 @ 19:19:
[...]
VueJS is een bekende lichtgewicht. Een andere die ik zelf veel inzet is CanJS. Bitovi heeft met dat framework heel goed werk afgeleverd. Eeuwig zonde dat het nog steeds niet doorgebroken is.
PS
Voor even zit ik weer in het stenen tijdperk... mijn SSD is overleden

En ik moest hem uiteraard een tweede keer openen omdat ik nog een schroefje vergeten was
[ Voor 36% gewijzigd door Lethalis op 03-11-2018 00:04 ]
Ask yourself if you are happy and then you cease to be.
Dit topic is gesloten.
Dit topic is niet de plaats om te lopen helpdesken. De Coffee Corner is primair bedoeld als uitlaatklep voor iedereen in de Devschuur® en niet als vraagbaak.