Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie
Toon posts:

De Devschuur Coffee Corner - Iteratie ⓬ Vorige deelOverzicht

Pagina: 1 ... 14 15 16 Laatste
Acties:

  • Lethalis
  • Registratie: april 2002
  • Niet online
.oisyn schreef op woensdag 26 december 2018 @ 15:25:
[...]

Welk account? Voor een DoS attack ga je natuurlijk niet maar 1 account proberen.
Mja niet alles dat ik schreef ging over een DoS attack. Blokkeren doe je voornamelijk om brute forcen tegen te gaan.

DoS aanvallen zijn sowieso lastig te voorkomen en kun je beter op netwerkniveau aanpakken. Automatisch tijdelijk ip adressen blokkeren in de firewall als er ongebruikelijk verkeer vandaan komt etc.

The secret to creativity is knowing how to hide your sources ~ Walking on water and developing software to specification are easy.. as long as both are frozen.


  • Cloud
  • Registratie: november 2001
  • Laatst online: 18-01 16:09

Cloud

Moderator FM / T.net PowerMod

Go Hawks!

Lethalis schreef op woensdag 26 december 2018 @ 22:59:
[...]
DoS aanvallen zijn sowieso lastig te voorkomen en kun je beter op netwerkniveau aanpakken. Automatisch tijdelijk ip adressen blokkeren in de firewall als er ongebruikelijk verkeer vandaan komt etc.
Dat hangt wel af van het type DoS aanval natuurlijk. Zo'n typische aanval is natuurlijk zoveel mogelijk netwerkrequests vuren en die aanval kun je beter op netwerkniveau aanpakken. Maar een DoS kun je ook bereiken door requests te vuren waardoor de ontvanger de hele tijd blijft afwachten op extra info, óf via de cpu bereiken door gewoon heel dure requests te vuren. Bij dat soort methoden heb je een stuk minder requests nodig om hetzelfde eindresultaat te bereiken. Ik heb zo snel even geen voorbeeld maar het zou niet de eerste keer zijn :)

Neemt niet weg dat die lengtelimiet, als ie bestaat, in de meeste gevallen best wel een heel stuk hoger kan.

Never attribute to malice that which can be adequately explained by stupidity.


  • bwerg
  • Registratie: januari 2009
  • Niet online

bwerg

Internettrol

Cloud schreef op donderdag 27 december 2018 @ 10:14:
Neemt niet weg dat die lengtelimiet, als ie bestaat, in de meeste gevallen best wel een heel stuk hoger kan.
Een wachtwoordlengtelimiet van 20 of minder tekens geeft wachtwoorden die veel korter zijn dan de gemiddelde protocolheader, dus dat is gewoon puur om een gebruiker te fucken. Ik kan werkelijk geen goede reden bedenken.

* bwerg kijkt ING boos aan. In forum-discussies geven ING-medewerkers aan dat dat niet erg is, omdat korte wachtwoorden beter te onthouden zijn en dat soort volslagen BS-redeneringen. Mag ik even zelf bepalen wat ik gemakkelijk kan onthouden?

Ook de betweters die dan gaan uitrekenen dat er met bepaalde (zinloze) wachtwoordregels nog genoeg entropie over is... Die theoreten vergeten voor het gemak wel even dat gebruiksvriendelijkheid, en het gemak om wachtwoorden te onthouden, niet in aantal bits entropie uit te drukken is.

bwerg wijzigde deze reactie 27-12-2018 11:05 (39%)

Heeft geen speciale krachten en is daar erg boos over.


  • Cloud
  • Registratie: november 2001
  • Laatst online: 18-01 16:09

Cloud

Moderator FM / T.net PowerMod

Go Hawks!

bwerg schreef op donderdag 27 december 2018 @ 10:39:
[...]

Een wachtwoordlengtelimiet van 20 of minder tekens geeft wachtwoorden die veel korter zijn dan de gemiddelde protocolheader, dus dat is gewoon puur om een gebruiker te fucken. Ik kan werkelijk geen goede reden bedenken.
Inderdaad. Daar irriteer ik me ook altijd mateloos aan. Ik hoef echt geen 64 karakter passwords te hebben op elke site maar als 't al op of onder 20 karakters afgekapt wordt dan wordt ik boos ja.
* bwerg kijkt ING boos aan. In forum-discussies geven ING-medewerkers aan dat dat niet erg is, omdat korte wachtwoorden beter te onthouden zijn en dat soort volslagen BS-redeneringen. Mag ik even zelf bepalen wat ik gemakkelijk kan onthouden?
Klopt. Wachtwoorden moet je niet allemaal willen onthouden overal want dan zijn ze:
  • Of te makkelijk
  • Of te vaak herhaald
Ook de betweters die dan gaan uitrekenen dat er met bepaalde (zinloze) wachtwoordregels nog genoeg entropie over is... Die theoreten vergeten voor het gemak wel even dat gebruiksvriendelijkheid, en het gemak om wachtwoorden te onthouden, niet in aantal bits entropie uit te drukken is.
Yep :)

Never attribute to malice that which can be adequately explained by stupidity.


  • Gropah
  • Registratie: december 2007
  • Nu online

Gropah

Moderator Spielerij

Oompa-Loompa 💩

bwerg schreef op donderdag 27 december 2018 @ 10:39:
[...]

Een wachtwoordlengtelimiet van 20 of minder tekens geeft wachtwoorden die veel korter zijn dan de gemiddelde protocolheader, dus dat is gewoon puur om een gebruiker te fucken. Ik kan werkelijk geen goede reden bedenken.

* bwerg kijkt ING boos aan. In forum-discussies geven ING-medewerkers aan dat dat niet erg is, omdat korte wachtwoorden beter te onthouden zijn en dat soort volslagen BS-redeneringen. Mag ik even zelf bepalen wat ik gemakkelijk kan onthouden?

Ook de betweters die dan gaan uitrekenen dat er met bepaalde (zinloze) wachtwoordregels nog genoeg entropie over is... Die theoreten vergeten voor het gemak wel even dat gebruiksvriendelijkheid, en het gemak om wachtwoorden te onthouden, niet in aantal bits entropie uit te drukken is.
Met 20 tekens krijg je van mij ook al geklaag, standaard doe ik namelijk 24. Onthouden hoef ik eigenlijk niet op 6 wachtwoorden na; die voor keepass, dropbox, google, werkomgeving, desktop en laptop.

Strong, united, working 'till we fall


  • Matis
  • Registratie: januari 2007
  • Nu online

Matis

Rubber Rocket

Cloud schreef op donderdag 27 december 2018 @ 10:14:
Dat hangt wel af van het type DoS aanval natuurlijk. Zo'n typische aanval is natuurlijk zoveel mogelijk netwerkrequests vuren en die aanval kun je beter op netwerkniveau aanpakken. Maar een DoS kun je ook bereiken door requests te vuren waardoor de ontvanger de hele tijd blijft afwachten op extra info, óf via de cpu bereiken door gewoon heel dure requests te vuren. Bij dat soort methoden heb je een stuk minder requests nodig om hetzelfde eindresultaat te bereiken. Ik heb zo snel even geen voorbeeld maar het zou niet de eerste keer zijn :)

Neemt niet weg dat die lengtelimiet, als ie bestaat, in de meeste gevallen best wel een heel stuk hoger kan.
Slowloris is daar een mooi voorbeeld van :)

If money talks then I'm a mime
If time is money then I'm out of time


  • Sandor_Clegane
  • Registratie: januari 2012
  • Laatst online: 16-01 10:03

Sandor_Clegane

Fancy plans and pants to match

Spamd ook.

  • Lethalis
  • Registratie: april 2002
  • Niet online
Gropah schreef op donderdag 27 december 2018 @ 11:29:
[...]

Met 20 tekens krijg je van mij ook al geklaag, standaard doe ik namelijk 24. Onthouden hoef ik eigenlijk niet op 6 wachtwoorden na; die voor keepass, dropbox, google, werkomgeving, desktop en laptop.
Toch lijkt me dat lastig.

Ik log weleens vaker met webmail in op meerdere locaties bijvoorbeeld, daarvoor is toch wel erg handig dat ik het wachtwoord weet en dat dit niet 1 of ander random gegenereerde code is.

Wel probeer ik zoveel mogelijk 2FA toe te passen met bijvoorbeeld Google Authenticator en heb ik voor bijna alles een ander wachtwoord (en die bewaar ik wel allemaal in een Keepass bestand).

Nadeel daarvan is dat ik niet altijd bij het Keepass bestand kan. Ik zat ook al te kijken naar de Keepass app voor Android.

Enige nadeel van steeds meer afhankelijk van die telefoon zijn, is dat je echt niks meer kan zodra die telefoon stuk is. Toevallig zat ik een aantal weken geleden zonder mobiele telefoon en dan ben je toch zwaar de sjaak als je zo ongeveer nergens meer bij kan.

Ik maak ook altijd een backup van die Google Authenticator QR codes (in Keepass) voor als ik weer eens een andere telefoon heb en alles terug moet zetten.

Maar goed... ik ben een beetje sjappie wat mijn spullen betreft. Telefoons sneuvelen nog weleens. De laatste werd niet blij sinds de fingerprint sensor doorboord was :$ Hij lag in mijn rugzak bij mijn sleutels toen ik op het strand zat...

The secret to creativity is knowing how to hide your sources ~ Walking on water and developing software to specification are easy.. as long as both are frozen.


  • Gropah
  • Registratie: december 2007
  • Nu online

Gropah

Moderator Spielerij

Oompa-Loompa 💩

Lethalis schreef op vrijdag 28 december 2018 @ 11:09:
[...]

Toch lijkt me dat lastig.

Ik log weleens vaker met webmail in op meerdere locaties bijvoorbeeld, daarvoor is toch wel erg handig dat ik het wachtwoord weet en dat dit niet 1 of ander random gegenereerde code is.

Wel probeer ik zoveel mogelijk 2FA toe te passen met bijvoorbeeld Google Authenticator en heb ik voor bijna alles een ander wachtwoord (en die bewaar ik wel allemaal in een Keepass bestand).

Nadeel daarvan is dat ik niet altijd bij het Keepass bestand kan. Ik zat ook al te kijken naar de Keepass app voor Android.

Enige nadeel van steeds meer afhankelijk van die telefoon zijn, is dat je echt niks meer kan zodra die telefoon stuk is. Toevallig zat ik een aantal weken geleden zonder mobiele telefoon en dan ben je toch zwaar de sjaak als je zo ongeveer nergens meer bij kan.

Ik maak ook altijd een backup van die Google Authenticator QR codes (in Keepass) voor als ik weer eens een andere telefoon heb en alles terug moet zetten.

Maar goed... ik ben een beetje sjappie wat mijn spullen betreft. Telefoons sneuvelen nog weleens. De laatste werd niet blij sinds de fingerprint sensor doorboord was :$ Hij lag in mijn rugzak bij mijn sleutels toen ik op het strand zat...
Als je je telefoon al bij je hebt voor 2FA kun je ook het wachtwoord daar vandaan halen, of je bent ingelogd op mobiel om je mail te lezen ;)

Keepass in dropbox/drive/zoiets zetten is echt ideaal. Vervolgens kun je met je clients gewoon er vandaan lezen/naar toe schrijven en het word over het goed gedetecteerd als er iets veranderd is. Nog nooit problemen mee gehad. En mocht je telefoon stuk gaan, ja, dan ben je tijdelijk de sjaak, maar dat ben je dan ook bij alle diensten die 2FA hebben (zoals je mail waarschijnlijk ook)

Strong, united, working 'till we fall


  • Lethalis
  • Registratie: april 2002
  • Niet online
Gropah schreef op vrijdag 28 december 2018 @ 11:20:
[...]

Als je je telefoon al bij je hebt voor 2FA kun je ook het wachtwoord daar vandaan halen, of je bent ingelogd op mobiel om je mail te lezen ;)
Mja, ik ben ouderwets en ik heb echt een hekel aan berichten tikken op een telefoon. Ik vind een laptop al bewerkelijk :P Het liefst heb ik gewoon een ouderwets groot toetsenbord en een 24" scherm voor mijn neus voor alles dat meer dan 3 regels typen is.

The secret to creativity is knowing how to hide your sources ~ Walking on water and developing software to specification are easy.. as long as both are frozen.


  • Gropah
  • Registratie: december 2007
  • Nu online

Gropah

Moderator Spielerij

Oompa-Loompa 💩

Lethalis schreef op vrijdag 28 december 2018 @ 12:24:
[...]

Mja, ik ben ouderwets en ik heb echt een hekel aan berichten tikken op een telefoon. Ik vind een laptop al bewerkelijk :P Het liefst heb ik gewoon een ouderwets groot toetsenbord en een 24" scherm voor mijn neus voor alles dat meer dan 3 regels typen is.
Dat heb ik zelf ook. Maar het is prima zat voor 3 regels. En als het meer dan 3 regels is dan kan het meestal ook wel even wachten omdat ik wat moet uitzoeken of heb ik mijn laptop in de buurt liggen.

Strong, united, working 'till we fall


  • BertS
  • Registratie: september 2004
  • Laatst online: 11:54
Gropah schreef op vrijdag 28 december 2018 @ 11:20:
[...]

Keepass in dropbox/drive/zoiets zetten is echt ideaal. Vervolgens kun je met je clients gewoon er vandaan lezen/naar toe schrijven en het word over het goed gedetecteerd als er iets veranderd is. Nog nooit problemen mee gehad.
Dat dus. Ik heb onderweg m'n Keepass wachtwoord nodig, en bij ontbreken van m'n telefoon ook m'n dropbox-wachtwoord. Werkt heerlijk.

  • Ed Vertijsment
  • Registratie: juli 2014
  • Laatst online: 13:53
armageddon_2k1 schreef op vrijdag 21 december 2018 @ 08:32:
[...]
Even wat anders. Ik ben Angular en React aan het leren en was erg gecharmeerd van Angular >5. Een robuust framework, beetje over the top voor kleine dingen, maar voor mij snijdt het erg hout.

React is een stuk populairder, dus het leek me verstandig om daar ook mee bezig te gaan. Nu een paar weekjes mee bezig, maar het enige voordeel voor me lijkt te zijn dat je JSX kan gebruiken. De andere zogenaamde dingen als Flux en Redux komen op mij over als 'afterthoughts' die erbij zijn gejongd omdat ze het fundament niet goed gebouwd hebben.
- Het begint al met: YouTube: Hacker Way: Rethinking Web App Development at Facebook. Het MVC voorbeeld dat za daar geven is compleet verkeerd. Sinds wanneer mogen Views direct het Model aanpassen?
- Flinke boilerplate code die je moet toevoegen voor als je Redux wil implementeren.
- Global state voor de hele applicatie?
- Context is ook al zo'n vreemde. Je gaat dus een soort context creeren die eigenlijk een global service emuleert. Je componenten zijn dan vervolgens afhankelijk van een context en impliciet verwachten ze bepaalde waardes uit die context. Ze zijn dus helemaal niet meer ontkoppeld.

Zie ik nou iets enorm over het hoofd of hebben ze bij FB zich een beetje in een hoek ge-engineerd door hun architectuur keuze alles zo 1-directional mogelijk te houden? Waar Angular juist uitgaat van een totaal asynchroon muterende state.
Beetje laat maar mag ik nog even aansluiten?

Ik ben het helemaal met je eens dat het MVC voorbeeld in de video als een tang op een varken slaat. Maar zo heel vreemd is React (+ Redux ) niet. En helemaal onrealistisch is het voorbeeld in de video ook weer niet op de manier dat (JS) MVC frameworks wel degelijk banaan kunnen gaan of giga performance issues kunnen krijgen bij grotere projecten.

Ik heb dit gezien bij Angular 1 en Aurelia, met de nieuwe Angular of Vue heb ik geen ervaring maar volgens mij is het problem inherent aan "two-way data biding". Tegenwoordig doen we alles met React (en Redux) en dat schaalt in onze ervaring veel beter.
Flinke boilerplate code die je moet toevoegen voor als je Redux wil implementeren.
Klopt, eenmalig wat meer werk. Dat is als je Redux wilt gebruiken. Ik gebruik Redux alleen bij "horizontal state management" (sorry voor mijn warrige termen of voor als ie al in gebruik is). Hiermee bedoel ik dat componenten die die NIET genest zijn maar WEL naast elkaar staan. Hiervoor is Redux een goed overlappend state management systeem.

Voor "vertical state management", hiermee bedoel ik componenten die NIET naast elkaar staan maar wel genest zijn gebruik ik het "container/component" pattern. Waarbij het bovenste de container is, die al de state heeft. En al zijn kinderen pure componenten zijn die alleen maar "props" hebben en geen state. Deze kunnen wel de container state updaten via callbacks die de state updaten in de container, welke alle children update (daar is die weer: FLOW).

Voor het gevalletje horizontal state management (om het nog maar even zo te noemen) heb je geen afgesloten scope waarin je de props kunt overhevelen. Dus gebruik je Redux welke deze props voor je "mapped" uit een grotere state welke dan weer in 1 bestandje leeft.
Global state voor de hele applicatie?
Nou niet helemaal, je kunt dus meerdere van deze "stores" aanmaken en enkel de stores gebruiken die je nodig hebt. Je hebt losse waarheden welke je desgewenst aan componenten kunt verbinden. Pas je 1 store aan, volgen alle AANGESLOTEN componenten automatisch. De overige componenten doen niets.
Context is ook al zo'n vreemde. Je gaat dus een soort context creeren die eigenlijk een global service emuleert. Je componenten zijn dan vervolgens afhankelijk van een context en impliciet verwachten ze bepaalde waardes uit die context. Ze zijn dus helemaal niet meer ontkoppeld.
Dit zegt mij niets :?

Mijn ervaring is dat two-way data flow vooral makkelijk is en niet zo erg als er niet nagedacht hoeft te worden over een grotere architectuur. Het is ook makkelijk om het fout doen waardoor je snel een split brain kunt creëren (of gewoon een hele trage website).

svenv.nl


  • GateKeaper
  • Registratie: april 2004
  • Laatst online: 18-01 14:20

GateKeaper

#1 Procastinator

Ik denk dat hij de nieuwe context api bedoeld.


code:
1
const { Provider, Consumer } = React.createContext({});

Procrastination for mr. President ! | Startup is looking for (wannabe) meteor developers. PM for info.


  • Ed Vertijsment
  • Registratie: juli 2014
  • Laatst online: 13:53
GateKeaper schreef op vrijdag 28 december 2018 @ 18:19:
[...]


Ik denk dat hij de nieuwe context api bedoeld.


code:
1
const { Provider, Consumer } = React.createContext({});

Oe, ik loop achter. Zo te zien is het een mooie aanvulling op het container/component pattern. Beetje de Redux provider voor een tree.

svenv.nl


  • armageddon_2k1
  • Registratie: september 2001
  • Laatst online: 18:30
Ed Vertijsment schreef op vrijdag 28 december 2018 @ 17:58:
[...]


Beetje laat maar mag ik nog even aansluiten?

Ik ben het helemaal met je eens dat het MVC voorbeeld in de video als een tang op een varken slaat. Maar zo heel vreemd is React (+ Redux ) niet. En helemaal onrealistisch is het voorbeeld in de video ook weer niet op de manier dat (JS) MVC frameworks wel degelijk banaan kunnen gaan of giga performance issues kunnen krijgen bij grotere projecten.

Ik heb dit gezien bij Angular 1 en Aurelia, met de nieuwe Angular of Vue heb ik geen ervaring maar volgens mij is het problem inherent aan "two-way data biding". Tegenwoordig doen we alles met React (en Redux) en dat schaalt in onze ervaring veel beter.


[...]


Klopt, eenmalig wat meer werk. Dat is als je Redux wilt gebruiken. Ik gebruik Redux alleen bij "horizontal state management" (sorry voor mijn warrige termen of voor als ie al in gebruik is). Hiermee bedoel ik dat componenten die die NIET genest zijn maar WEL naast elkaar staan. Hiervoor is Redux een goed overlappend state management systeem.

Voor "vertical state management", hiermee bedoel ik componenten die NIET naast elkaar staan maar wel genest zijn gebruik ik het "container/component" pattern. Waarbij het bovenste de container is, die al de state heeft. En al zijn kinderen pure componenten zijn die alleen maar "props" hebben en geen state. Deze kunnen wel de container state updaten via callbacks die de state updaten in de container, welke alle children update (daar is die weer: FLOW).

Voor het gevalletje horizontal state management (om het nog maar even zo te noemen) heb je geen afgesloten scope waarin je de props kunt overhevelen. Dus gebruik je Redux welke deze props voor je "mapped" uit een grotere state welke dan weer in 1 bestandje leeft.


[...]


Nou niet helemaal, je kunt dus meerdere van deze "stores" aanmaken en enkel de stores gebruiken die je nodig hebt. Je hebt losse waarheden welke je desgewenst aan componenten kunt verbinden. Pas je 1 store aan, volgen alle AANGESLOTEN componenten automatisch. De overige componenten doen niets.


[...]


Dit zegt mij niets :?

Mijn ervaring is dat two-way data flow vooral makkelijk is en niet zo erg als er niet nagedacht hoeft te worden over een grotere architectuur. Het is ook makkelijk om het fout doen waardoor je snel een split brain kunt creëren (of gewoon een hele trage website).
Bedankt voor je uitgebreide reactie. Na mijn oorspronkelijke post ben ik er wel meer in gedoken. Ik heb ook even bij Udemy 2 cursusjes in de aanbieding gekocht van Angular2+ en React (van Maximillian Schwarzmuller, wel een aanrader). Voor de profi's onder ons gesneden koek, maar voor mij erg leuk. Daar komt ik er wel meer achter dat beide methodes hun merits hebben. React is heel erg gedreven vanuit een UI-building perspectief, waardoor je dingen als de nieuwe Context-API, of Error Boundaries ook als het ware zo in je JSX stopt. Dat vind ik persoonlijk vrij awkward, maar aan de andere kant is JSX weer heel krachtig. Ook is het vrij duidelijk wat er gebeurt als je het component opent dan heb je alles wat je zoekt.

Angular2+ vind ik persoonlijk logischer, maar dat is misschien omdat ik meer in die klassieke architectuur met services, DI, events, observables en een vrij sterk OO en typesafe systeem denk. Nadeel is wel de enorme overload aan files die je creert en je een custom syntax in de HTML-templates injecteert (*ngIf etc).

Echter, voelt voor mij Angular2+ als een meer doordacht geheel aan en React meer als een verzameling best-practices en een idee erachter van "Woh, feature xxxx van ES6 is gaaf, zullen we daar een nieuwe feature bij verzinnen in React?". Maakt dat het wel een ultra-flexibel framework is en ik zie zeker de voordelen. React is populairder en ontwikkeld veel sneller lijkt het. Angular heeft natuurlijk nogal wat mensen vervreemd sinds hun enorme stap van AngularJS naar Angular2. Vanwege hun architectuur is het volgens mij wel mogelijk om, helemaal als Ivy er is, uiteindelijk veel meer te kunnen verbeteren (loading-times, app grootte etc) echt enorme braking-changes te introduceren.

Voor de lol was ik even een voorbeeld aan het maken welke een complexe SVG in elkaar zette a/d hand van wat data-bronnen. In React was ik zo klaar, in Angular duurde het allemaal wat langer.
GateKeaper schreef op vrijdag 28 december 2018 @ 18:19:
[...]


Ik denk dat hij de nieuwe context api bedoeld.


code:
1
const { Provider, Consumer } = React.createContext({});

Klopt. Ook hier ben ik wat meer ingedoken met behulp van een eigen voorbeeld. De docs vond ik niet erg sterk. Met mijn eigen SVG-voorbeeld kwam ik er al snel achter dat een Context de juiste manier was om niet alle layers die ik in de SVG had allemaal dezelfde parameters door te moeten geven (b.v. viewbox size, theme, etc). Dus zeker een goede API, maar vond het voorbeeld van de docs niet erg sterk of de dingen die ik op Medium gelezen had.

  • Ed Vertijsment
  • Registratie: juli 2014
  • Laatst online: 13:53
armageddon_2k1 schreef op vrijdag 28 december 2018 @ 19:20:
React is heel erg gedreven vanuit een UI-building perspectief
armageddon_2k1 schreef op vrijdag 28 december 2018 @ 19:20:
Angular2+ vind ik persoonlijk logischer, maar dat is misschien omdat ik meer in die klassieke architectuur met services, DI, events, observables en een vrij sterk OO en typesafe systeem denk.
Ik denk dat je hier de spijker op zijn kop slaat. React is enkel en alleen de UI, de "V" in "MVC", niets meer dan de view. Je kunt er ander dingen aanhangen om met data om te gaan of om te routen bijvoorbeeld.

Dit is ook een van de voordelen, je duwt niet al je code in een framework. Daarnaast is het meer in lijn met filosofie van "do one thing and do it well".
armageddon_2k1 schreef op vrijdag 28 december 2018 @ 19:20:
Echter, voelt voor mij Angular2+ als een meer doordacht geheel aan en React meer als een verzameling best-practices en een idee erachter van "Woh, feature xxxx van ES6 is gaaf, zullen we daar een nieuwe feature bij verzinnen in React?".
React wordt niet gebouwd om maar iets te bouwen, maar probeert wel de beste oplossing te bedenken met het oog op moderne JavaScript, en met minder op ES5. Dat gezegd hebben heb ik een collega die (kudo's daarvoor) het op IE8 aan de gang kreeg.
armageddon_2k1 schreef op vrijdag 28 december 2018 @ 19:20:
Maakt dat het wel een ultra-flexibel framework is en ik zie zeker de voordelen. React is populairder en ontwikkeld veel sneller lijkt het. Angular heeft natuurlijk nogal wat mensen vervreemd sinds hun enorme stap van AngularJS naar Angular2. Vanwege hun architectuur is het volgens mij wel mogelijk om, helemaal als Ivy er is, uiteindelijk veel meer te kunnen verbeteren (loading-times, app grootte etc) echt enorme braking-changes te introduceren.
Wij gebruiken Django voor de backend, 99% van alles wat wij op de backend doet past binnen Django. Als dat geld voor wat je binnen Angular kan doen dan raad ik je af met React aan de gang te gaan. React is dan te beperkt en dan zit je continu libraries aan elkaar te knopen.

Als je echter complexe JS componenten in een bestaand (of niet SPA) systeem wilt hangen is React veel geschikter.
[/quote]

Voor de lol was ik even een voorbeeld aan het maken welke een complexe SVG in elkaar zette a/d hand van wat data-bronnen. In React was ik zo klaar, in Angular duurde het allemaal wat langer.
armageddon_2k1 schreef op vrijdag 28 december 2018 @ 19:20:
Klopt. Ook hier ben ik wat meer ingedoken met behulp van een eigen voorbeeld. De docs vond ik niet erg sterk. Met mijn eigen SVG-voorbeeld kwam ik er al snel achter dat een Context de juiste manier was om niet alle layers die ik in de SVG had allemaal dezelfde parameters door te moeten geven (b.v. viewbox size, theme, etc). Dus zeker een goede API, maar vond het voorbeeld van de docs niet erg sterk of de dingen die ik op Medium gelezen had.
Dis dan ook typisch iets waar React een stuk geschikter voor is. Moest de SVG via externe services en in verschillende routes dynamisch opgebouwd kunnen worden wordt het iets interessanter.

Al met al is Angular een (all-in)-one framework waarbij je kan zeggen "go big or go home". Het bepaald hoe de gehele applicatie eruit gaat zien. Als dat geen probleem is kan het maar zo de beste keuze zijn.

Als je wil kunnen integreren met andere systemen dan kom je eerder op React uit. Dit is ook voor ons de keuze geweest om daar mee aan de slag te gaan.

svenv.nl


  • DevWouter
  • Registratie: februari 2016
  • Laatst online: 18-01 13:24
Ed Vertijsment schreef op vrijdag 28 december 2018 @ 21:39:
Voor de lol was ik even een voorbeeld aan het maken welke een complexe SVG in elkaar zette a/d hand van wat data-bronnen. In React was ik zo klaar, in Angular duurde het allemaal wat langer.

[...]


Dis dan ook typisch iets waar React een stuk geschikter voor is. Moest de SVG via externe services en in verschillende routes dynamisch opgebouwd kunnen worden wordt het iets interessanter.

Al met al is Angular een (all-in)-one framework waarbij je kan zeggen "go big or go home". Het bepaald hoe de gehele applicatie eruit gaat zien. Als dat geen probleem is kan het maar zo de beste keuze zijn.

Als je wil kunnen integreren met andere systemen dan kom je eerder op React uit. Dit is ook voor ons de keuze geweest om daar mee aan de slag te gaan.
Die twee zijn ook niet met elkaar te vergelijken. Angular is bedoeld om applicaties te bouwen en React is bedoeld is om componenten te bouwen.

Met React kan je hetzelfde als Angular, maar dan moet je de toolchain uitbreiden. Maar dan moet je kiezen om de tools zelf te schrijven of door een tool van een ander te gebruiken. Echter op dat moment ben je ook niet meer bezig met het vergelijken van "vanilla React" versus "vanilla Angular".

Wanneer er een keuze gemaakt moet worden tussen React en Angular dan sluiten de eisen vaak één of beide uit. Op het moment dat je maar 50% van Angular nodig heb dan kies je React. Heb je 150% nodig van wat React te bieden heeft dan kies je Angular.

Vergelijk de tutorials van beide en je ziet dat ze beide een andere vraag beantwoorden.

We doen niet grappig over grappen, grappen maken is bloedserieus werk


  • Ed Vertijsment
  • Registratie: juli 2014
  • Laatst online: 13:53
DevWouter schreef op maandag 31 december 2018 @ 13:21:
[...]


Die twee zijn ook niet met elkaar te vergelijken. Angular is bedoeld om applicaties te bouwen en React is bedoeld is om componenten te bouwen.

Met React kan je hetzelfde als Angular, maar dan moet je de toolchain uitbreiden. Maar dan moet je kiezen om de tools zelf te schrijven of door een tool van een ander te gebruiken. Echter op dat moment ben je ook niet meer bezig met het vergelijken van "vanilla React" versus "vanilla Angular".

Wanneer er een keuze gemaakt moet worden tussen React en Angular dan sluiten de eisen vaak één of beide uit. Op het moment dat je maar 50% van Angular nodig heb dan kies je React. Heb je 150% nodig van wat React te bieden heeft dan kies je Angular.

Vergelijk de tutorials van beide en je ziet dat ze beide een andere vraag beantwoorden.
Volgens mij zeg ik in mijn vorige post pretty much hetzelfde?

svenv.nl


  • DevWouter
  • Registratie: februari 2016
  • Laatst online: 18-01 13:24
Ed Vertijsment schreef op maandag 31 december 2018 @ 16:13:
[...]


Volgens mij zeg ik in mijn vorige post pretty much hetzelfde?
Het voorbeeld dat je aandraagt (SVG) is een betere use-case voor React dan het is voor Angular. Hierdoor lijkt jouw verhaal (waar ik verder grotendeels mee eens ben) opeens te veranderen in een A-versus-B verhaal.
Gezien jouw reactie is duidelijk dat het niet de bedoeling was.

Mijn post bekrachtigt verder ook alleen maar wat je in het eerste gedeelte al had geschreven en wat je in het tweede gedeelte bedoelde. ;)

We doen niet grappig over grappen, grappen maken is bloedserieus werk


  • R4gnax
  • Registratie: maart 2009
  • Laatst online: 16:09
Ed Vertijsment schreef op vrijdag 28 december 2018 @ 17:58:
En helemaal onrealistisch is het voorbeeld in de video ook weer niet op de manier dat (JS) MVC frameworks wel degelijk banaan kunnen gaan of giga performance issues kunnen krijgen bij grotere projecten.

Ik heb dit gezien bij Angular 1 en Aurelia, met de nieuwe Angular of Vue heb ik geen ervaring maar volgens mij is het problem inherent aan "two-way data biding". Tegenwoordig doen we alles met React (en Redux) en dat schaalt in onze ervaring veel beter.
Ik werk al tijden met CanJS, waar two-way data-binding gewoon goed werkt. Geen rariteiten waar de zooi "banaan" gaat en ook geen performance issues.

Hangt dus ook nogal af van de kwaliteit van het framework, lijkt me?

  • Ed Vertijsment
  • Registratie: juli 2014
  • Laatst online: 13:53
R4gnax schreef op dinsdag 1 januari 2019 @ 19:23:
[...]


Ik werk al tijden met CanJS, waar two-way data-binding gewoon goed werkt. Geen rariteiten waar de zooi "banaan" gaat en ook geen performance issues.

Hangt dus ook nogal af van de kwaliteit van het framework, lijkt me?
Niet van het framework (hoewel wel gedeeltelijk), maar van de workload.

Two-way data binding werkt door op verschillende soorten objecten/primitives door verschillende soorten observers te zetten, of bepaalde notification API's waar beschikbaar. Het eerste scenario geeft een probleem op het moment dat een zeer grote dataset wordt gebruikt. Je zit dan met veel data + veel observers = veel geheugengebruik (simpel gezegd).

In het tweede scenario worden native API's gebruikt om mutaties bij te houden, dit is weliswaar efficiënter maar nog steeds problematisch(er) bij grotere datasets.

Het echt interessante komt echter als er (meerde niveaus van) afhankelijkheden tussen objecten zitten die doorberekend moeten worden. Dit is prima als jij een boodschappenlijstje app hebt maar als je grotere complexe projecten doet heb je een goede kans dat of je browser nee zegt op basis van CPU of geheugen.

Hier zit zeker een stuk verantwoordelijkheid/implementatie van de ontwikkelaar in maar een framework is ook een black box die dingen voor jou doet en waar je vaak maar beperkt in kan sturen.

Deze post legt uit hoe Aurelia er mee om gaat, hier staat ook beschreven dat in bepaalde omgeving zelfs geen observer mogelijk is en gewoon dirty checking wordt gebruikt.

Lang verhaal kort: state is duur, en veel state is erg duur. Voor simpele applicaties gaat dat prima mij bij complexe applicaties is het maar wat fijn om altijd exact te weten welke wijziging waar vandaan komt en alles atomisch wordt uitgevoerd.

svenv.nl


  • Matis
  • Registratie: januari 2007
  • Nu online

Matis

Rubber Rocket

Volgens mij heeft Google iets aan hun charts veranderd. Vroegah (lees een maand geleden) werd er nog automatisch gezoomd naar het zichtbare gedeelte. Als je op de vertikale as waardes had tussen 75 en 100, zag je gezoomd de grafiek met als minimum +/- 75 en maximum +/- 100.
Nu staat ineens alleen de bovenste kwart van de grafiek gevuld, want minimum is ineens 0 geworden :/

Edit; gelukkig niet de enige :D https://stackoverflow.com...behavior-changed-on-11-28

Gek genoeg lijkt het op Android (nog) wel goed te gaan met auto scaling.

Matis wijzigde deze reactie 02-01-2019 12:00 (21%)

If money talks then I'm a mime
If time is money then I'm out of time


  • R4gnax
  • Registratie: maart 2009
  • Laatst online: 16:09
Ed Vertijsment schreef op dinsdag 1 januari 2019 @ 19:55:
[...]


Niet van het framework (hoewel wel gedeeltelijk), maar van de workload.

Two-way data binding werkt door op verschillende soorten objecten/primitives door verschillende soorten observers te zetten, of bepaalde notification API's waar beschikbaar. Het eerste scenario geeft een probleem op het moment dat een zeer grote dataset wordt gebruikt. Je zit dan met veel data + veel observers = veel geheugengebruik (simpel gezegd).

In het tweede scenario worden native API's gebruikt om mutaties bij te houden, dit is weliswaar efficiënter maar nog steeds problematisch(er) bij grotere datasets.
One-way data binding heeft even zo goed een soort notificatie of dirty-checking nodig. Of dacht je dat je view-rendering pipeline niet een schop hoefde te krijgen over welke stukken van een view opnieuw neergezet moeten worden? Niets daaraan maakt het uniek tot two-way binding.

Grote datasets zijn inderdaad altijd inefficient. Omdat ze groot zijn.
In die soort gevallen val je terug op andere technieken. Data partieel renderen met virtualized rendering/scrolling, bijvoorbeeld. Datasets interleaved bijwerken, in kleinere batches, etc.

Als het framework wat je gebruikt de mogelijkheid geeft om bepaalde properties op je data model te markeren als 'non-observed' -- CanJS heeft die mogelijkheid, trouwens -- dan kun je dat gedeelte van je model op zo'n manier 'custom' afhandelen. Als je dan ook nog eens de mogelijkheid hebt om met de hand een notificatie het systeem van observable data terug in te sturen -- wat CanJS ook heeft -- is de puzzel rond.

Ik heb met CanJS virtualized rendering/scrolling oplossingen gemaakt waarmee je door letterlijk jaren aan prijsdata voor vakantie-pakketten kunt heen bladeren, met een bult extra vlucht-selectie, kamer-selectie, etc. er aan vast genageld. Geeft maar weinig performance problemen hoor.
Ed Vertijsment schreef op dinsdag 1 januari 2019 @ 19:55:
[...]

Het echt interessante komt echter als er (meerde niveaus van) afhankelijkheden tussen objecten zitten die doorberekend moeten worden. Dit is prima als jij een boodschappenlijstje app hebt maar als je grotere complexe projecten doet heb je een goede kans dat of je browser nee zegt op basis van CPU of geheugen.

Hier zit zeker een stuk verantwoordelijkheid/implementatie van de ontwikkelaar in maar een framework is ook een black box die dingen voor jou doet en waar je vaak maar beperkt in kan sturen.

Deze post legt uit hoe Aurelia er mee om gaat, hier staat ook beschreven dat in bepaalde omgeving zelfs geen observer mogelijk is en gewoon dirty checking wordt gebruikt.
Lees eens hoe CanJS computed properties implementeert; hoe ze dependents tracken; automatische binding/unbinding afhandelen; en hoe ze in recente versies een nieuw queuing systeem voor update notificaties doorgevoerd hebben:
https://www.bitovi.com/blog/canjs-4.0#queues

Aurelia zeikt een eind weg over het feit 'dat het niet kan'; ondertussen staat hier een framework wat bewijst dat het wel kan.
Ed Vertijsment schreef op dinsdag 1 januari 2019 @ 19:55:
[...]
Lang verhaal kort: state is duur, en veel state is erg duur. Voor simpele applicaties gaat dat prima mij bij complexe applicaties is het maar wat fijn om altijd exact te weten welke wijziging waar vandaan komt en alles atomisch wordt uitgevoerd.
Atomiciteit -- of in elk geval voorspelbare volgordelijkheid, want dat is wss. wat je hier bedoelt; gezien JS single-threaded is zonder shared memory -- wordt door CanJS netjes afgehandeld. Dankzij het eerder genoemde queuing systeem.

En wat betreft het 'weten waar een wijziging vandaan komt': daar hebben ze debug tooling voor.
https://www.bitovi.com/blog/canjs-4.0#debugging-tools

  • Ed Vertijsment
  • Registratie: juli 2014
  • Laatst online: 13:53
R4gnax schreef op woensdag 2 januari 2019 @ 12:26:
[...]


One-way data binding heeft even zo goed een soort notificatie of dirty-checking nodig. Of dacht je dat je view-rendering pipeline niet een schop hoefde te krijgen over welke stukken van een view opnieuw neergezet moeten worden? Niets daaraan maakt het uniek tot two-way binding.
Dat hangt maar net van je implementatie af. In het geval van Redux moet je zelf d.m.v. een action aangeven wat er moet gebeuren en hoe dat resulteert in een nieuwe state. Hier heb je geen observers voor nodig en dus.
R4gnax schreef op woensdag 2 januari 2019 @ 12:26:
Grote datasets zijn inderdaad altijd inefficient. Omdat ze groot zijn.
heb je alleen maar je footprint van je state object. En niet voor elk bound object een observer. En ja, dat maakt uit.
R4gnax schreef op woensdag 2 januari 2019 @ 12:26:
In die soort gevallen val je terug op andere technieken. Data partieel renderen met virtualized rendering/scrolling, bijvoorbeeld. Datasets interleaved bijwerken, in kleinere batches, etc.
Je benoemt hier technieken om rendering efficiënter te maken (React doet diet bijvoorbeeld met de Virtual DOM), we hadden het echter over efficiënt state management.
R4gnax schreef op woensdag 2 januari 2019 @ 12:26:
Als het framework wat je gebruikt de mogelijkheid geeft om bepaalde properties op je data model te markeren als 'non-observed' -- CanJS heeft die mogelijkheid, trouwens -- dan kun je dat gedeelte van je model op zo'n manier 'custom' afhandelen. Als je dan ook nog eens de mogelijkheid hebt om met de hand een notificatie het systeem van observable data terug in te sturen -- wat CanJS ook heeft -- is de puzzel rond.
Het zou helemaal inefficiënt zijn als een framework automatisch alles gaat binden. "Explicit is better than impliciet" houd ik hier even aan. Aurelia stelt je in staat om zelf de binding (type) aan te geven waar nodig. Een compleet model binden (kan ook) vind ik riskant aangezien die nogal eens heel groot kunnen worden. En als je alleen 1 boolean daarvan wilt binden zit je al vrij snel met overhead.
R4gnax schreef op woensdag 2 januari 2019 @ 12:26:
Ik heb met CanJS virtualized rendering/scrolling oplossingen gemaakt waarmee je door letterlijk jaren aan prijsdata voor vakantie-pakketten kunt heen bladeren, met een bult extra vlucht-selectie, kamer-selectie, etc. er aan vast genageld. Geeft maar weinig performance problemen hoor.
In een goede listview implementatie doe je natuurlijk netjes aan garbage collection. Ik zeg overigens ook niet dat het onmogelijk is het goed te krijgen. Het is alleen veel makkelijker je zelf in de voet te schieten met two-way binding.
R4gnax schreef op woensdag 2 januari 2019 @ 12:26:
Lees eens hoe CanJS computed properties implementeert; hoe ze dependents tracken; automatische binding/unbinding afhandelen; en hoe ze in recente versies een nieuw queuing systeem voor update notificaties doorgevoerd hebben:
https://www.bitovi.com/blog/canjs-4.0#queues

Aurelia zeikt een eind weg over het feit 'dat het niet kan'; ondertussen staat hier een framework wat bewijst dat het wel kan.
Aurelia gebruikt ES6 classes waarvan getters geen normale properties zijn en niet goed observable zijn op bepaalde browsers (volgens mij was dit het dirty check scenario), die design choice kun in twijfel trekken, ik houd er zelf ook niet van. Ik vraag mij af hoe CanJS die observed en of dit in Aurelia inmiddels anders wordt gedaan.

De post beschrijft niet hoe CanJS dit doet of kan aangezien het niet echt op de technische implementatie ingaat en uitgaat en demonstreert in ES5 code waar classes geen onderdeel van zijn.

On de side: termen als "zeikt" gaan roepen draag niet bepaalt bij aan een zinnige discussie.
R4gnax schreef op woensdag 2 januari 2019 @ 12:26:
Atomiciteit -- of in elk geval voorspelbare volgordelijkheid, want dat is wss. wat je hier bedoelt; gezien JS single-threaded is zonder shared memory -- wordt door CanJS netjes afgehandeld. Dankzij het eerder genoemde queuing systeem.
Je zou prima je redux state in een worker thread kunnen draaien hoor, losse mutaties (actions) zijn namelijk een stuk makkelijk naar worker threads te communiceren.

Los daarvan heeft JS al standaard more or less zijn eigen queue, of je daar je state op wilt baseren is discutabel (Aurelia implementeert ook een custom queue) maar in essentie kan je door alles in een setTimeout() te wrappen code aan het einde van even loop douwen die gewoon FIFO wordt afgehandeld.
R4gnax schreef op woensdag 2 januari 2019 @ 12:26:
En wat betreft het 'weten waar een wijziging vandaan komt': daar hebben ze debug tooling voor.
https://www.bitovi.com/blog/canjs-4.0#debugging-tools
Ik moet zeggen dat dat er nuttig uitziet al kan ik niet zien of het direct laat zien welk UI element ergens voor verantwoordelijk is.

Al met al ga ik je niet vertellen of je wel of niet two-way binding moet gaan gebruiken en ga je ook geen framework voorschrijven. Als jij goed uit de voeten kan met CanJS dan is dat prima. Ik gebruik inmiddels geen Aurelia meer, dat omdat hoewel het prima mogelijk is. Het een stuk minder sjiek werken is bij grotere complexe data sets en een one-way flow in mijn ervaring prettiger en betrouwbaarder werkt (voor ons).

Wij gebruiken nu React + Redux voor alles waar dit soort gedrag wenselijks is, zo niet gewoon request response en templates. Voor kleiner projecten React zonder Redux.

React is alles behalve batteries included. Dat vind ik persoonlijk fijn maar is zeker voor sommige een nadeel te noemen. En ja, al de configuratie van actions en reducers is, zeker in het begin wat meer boilerplate.

Al met al is geen enkel framework perfect.

svenv.nl


  • R4gnax
  • Registratie: maart 2009
  • Laatst online: 16:09
Ed Vertijsment schreef op woensdag 2 januari 2019 @ 13:50:
[...]


Dat hangt maar net van je implementatie af. In het geval van Redux moet je zelf d.m.v. een action aangeven wat er moet gebeuren en hoe dat resulteert in een nieuwe state. Hier heb je geen observers voor nodig en dus.
En er zijn nog steeds impliciet observers op die data aanwezig, ook al schrijf je ze zelf in een action.
Redux zal toch echt iets moeten registreren om te weten wanneer die actie aangeroepen moet worden.

En React zelf zal toch echt op de één of andere manier ook een schop moeten krijgen om de view bij te gaan werken.
Ed Vertijsment schreef op woensdag 2 januari 2019 @ 13:50:
heb je alleen maar je footprint van je state object. En niet voor elk bound object een observer. En ja, dat maakt uit.
En waar bestaat volgens jou een 'observer' uit?

CanJS maakt bijv. gebruik van een structuur waar observables werken als een soort van event source die op een gegeven moment een 'change' event naar buiten stuurt, tenminste: als er iets actief naar aan het luisteren is. Is dat niet het geval, dan worden die events niet gevuurt. (Dat werkt overigens transitief: computed properties die niet geobserveerd worden, observeren hun dependents ook niet.)

Je trekt heel hard aan het feit dat er altijd observers actief zijn en dat het maken van al die observers veel geheugen vreet. En dat is een veel te algemene stelling.
Ed Vertijsment schreef op woensdag 2 januari 2019 @ 13:50:
Je benoemt hier technieken om rendering efficiënter te maken (React doet diet bijvoorbeeld met de Virtual DOM), we hadden het echter over efficiënt state management.
Nee. We hadden het over two-way vs one-way binding. Dat strekt verder dan enkel state management.
Maar goed; zelfs als we het enkel over state management zouden hebben, dan is het nog steeds on topic.

De genoemde technieken zorgen er namelijk voor dat de hoeveelheid bindings die tegelijk actief hoeven zijn, gelimiteerd blijft. En zorgen er voor dat de hoeveelheid data die je tegelijkertijd in je state hebt zitten ook gelimiteerd kan blijven. (Lazy loaden/disposen.)

Werk je dan met een framework wat een beetje efficient omgaat met bindings op observables (zoals ik hierboven al uitgelegd heb, bijv.) dan helpen zulke technieken vanuit de consumerende views wel degelijk mee aan het efficient houden van je state management.
Ed Vertijsment schreef op woensdag 2 januari 2019 @ 13:50:
[...]

Het zou helemaal inefficiënt zijn als een framework automatisch alles gaat binden. "Explicit is better than impliciet" houd ik hier even aan. Aurelia stelt je in staat om zelf de binding (type) aan te geven waar nodig. Een compleet model binden (kan ook) vind ik riskant aangezien die nogal eens heel groot kunnen worden. En als je alleen 1 boolean daarvan wilt binden zit je al vrij snel met overhead.
Eens.
Ed Vertijsment schreef op woensdag 2 januari 2019 @ 13:50:
In een goede listview implementatie doe je natuurlijk netjes aan garbage collection. Ik zeg overigens ook niet dat het onmogelijk is het goed te krijgen. Het is alleen veel makkelijker je zelf in de voet te schieten met two-way binding.
Maar, daar ben ik het oneens mee. Leg me eens uit waarom two-way data binding hier problemen zou leveren die je met one-way binding niet hebt?
Ed Vertijsment schreef op woensdag 2 januari 2019 @ 13:50:
Aurelia gebruikt ES6 classes waarvan getters geen normale properties zijn en niet goed observable zijn op bepaalde browsers (volgens mij was dit het dirty check scenario), die design choice kun in twijfel trekken, ik houd er zelf ook niet van. Ik vraag mij af hoe CanJS die observed en of dit in Aurelia inmiddels anders wordt gedaan.
CanJS trapt bewust niet in die valstrik en hanteert een eigen set observeerbare model classes. DefineMap voor objecten en DefineList voor arrays. Je schrijft property definitie specificaties per model eigenschap en het prototype van de class swapt die on-the-fly uit voor getter/setters die alle nodige hooks voor observability aan boord hebben.

Daarnaast werken ze aan een alternatieve observeerbare structuur dmv ES6 proxies.
Je hebt als ontwikkelaar daar de keuze wat je gaat doen.

Wil je liever een object van buiten het framework op een andere manier observeren, dan kun je daarvoor een eigen computed property definiëren met get/set/on/off functies om de waarde op te vragen; weg te schrijven; object-specifieke observatie handlers te registeren; en weer te ont-registreren.

Of (ongedocumenteerd, helaas) je maakt gebruik van het lager gelegen systeem waarmee CanJS bijv. Promise observeerbaar heeft gemaakt. Dat is ook niet echt moeilijk. De ontwikkelaars van dit framework hebben wat dat betreft heel goed naar extensibility gekeken.
Ed Vertijsment schreef op woensdag 2 januari 2019 @ 13:50:
On de side: termen als "zeikt" gaan roepen draag niet bepaalt bij aan een zinnige discussie.
Mja; I calls 'em, as I sees 'em.
Als je nagaat dat elke keer wanneer iemand vraagt "waarom kan Aurelia dit niet?" hetzelfde excuus van stal gehaald wordt, om maar te vermijden te gaan kijken naar een rewrite. Ja; dan vind ik dat slap gezeik.
Ed Vertijsment schreef op woensdag 2 januari 2019 @ 13:50:
Je zou prima je redux state in een worker thread kunnen draaien hoor, losse mutaties (actions) zijn namelijk een stuk makkelijk naar worker threads te communiceren.

Los daarvan heeft JS al standaard more or less zijn eigen queue, of je daar je state op wilt baseren is discutabel (Aurelia implementeert ook een custom queue) maar in essentie kan je door alles in een setTimeout() te wrappen code aan het einde van even loop douwen die gewoon FIFO wordt afgehandeld.
Grappig dat je met redux worker aankomt. CanJS had nl. 4 jaar geleden een experimentele branch waarmee ze je hele applicatie in een worker kunnen draaien en enkel de view nog op de main thread. Jammer genoeg nooit uitontwikkeld. Was een mooi concept; maar helaas lag de ontwikkelaandacht destijd elders.

CanJS' queue systeem werkt een klein beetje anders dan een naive setTimeout.
Ze maken feitelijk gebruik van een set van verschillende queues die in de juiste volgorde geflushed worden en - bijv. vanwege dependents in computed properties - weer aangevuld worden. Zo pingelen ze een paar keer heen en weer terwijl alles opnieuw uitgerekend wordt en state bijgewerkt wordt, alvorens de laatste queue gedraint wordt waar de DOM mutaties aan vast hangen om de view bij te gaan werken.
Ed Vertijsment schreef op woensdag 2 januari 2019 @ 13:50:
Al met al is geen enkel framework perfect.
Klopt. Alles heeft z'n voors en z'n tegens.

Net zoals one-way binding niet impliciet beter/makkelijker/veiliger/sneller/etc dan two-way binding hoeft te zijn.
Dat is eigenlijk de boodschap hier.

  • Ed Vertijsment
  • Registratie: juli 2014
  • Laatst online: 13:53
Omdat dit topic over meer (of minder) gaat dan JS frameworks libraries houd ik m kort en stel ik voor om ofwel, onze conclusies te trekken, danwel een nieuw topic te openen.
R4gnax schreef op woensdag 2 januari 2019 @ 17:28:
[...]


En er zijn nog steeds impliciet observers op die data aanwezig, ook al schrijf je ze zelf in een action.
Redux zal toch echt iets moeten registreren om te weten wanneer die actie aangeroepen moet worden.

En React zelf zal toch echt op de één of andere manier ook een schop moeten krijgen om de view bij te gaan werken.
Er is een groot verschil tussen een action en een observer. Een observer is inzekere zin een automatische action dispatcher. Je hebt gelijk als je zegt dat Redux een schop moet krijgen maar dat gebeurt altijd door de ontwikkelaar gecontroleerd door een directe call. Je hoeft niet naar een object te gaan kijken maar kunt direct aanbellen. Tuurlijk zal er iets ergens vandaan moeten komen. maar het scheelt even simpel gezegd de helft omdat je alleen via de view (one way) hoeft te kijken of er iets gebeurd. Tuurlijk is dit niet altijd een probleem maar we hadden het hier over grote datasets.
R4gnax schreef op woensdag 2 januari 2019 @ 17:28:
CanJS trapt bewust niet in die valstrik en hanteert een eigen set observeerbare model classes
Dat is natuurlijk een prima oplossing maar dan zit je vast in een oude syntax waar de rest van de wereld naar classes gaat.
R4gnax schreef op woensdag 2 januari 2019 @ 17:28:
Grappig dat je met redux worker aankomt. CanJS had nl. 4 jaar geleden een experimentele branch waarmee ze je hele applicatie in een worker kunnen draaien en enkel de view nog op de main thread. Jammer genoeg nooit uitontwikkeld. Was een mooi concept; maar helaas lag de ontwikkelaandacht destijd elders.
gezijk
Even de bal terugkaatsen. Redux heeft (meerdere) werkende implementaties van state in een worker thread draaien. Niet in conceptfase, niet op een experimental branch. Maar gewoon vandaag te gebruiken. Overigens als je de code die implementaties bekijkt zie je dat zoiets echt niet moeilijk te implementeren is, puur een indicatie van dat simpel wellicht ook beter is?
Ho ho, don't get me wrong. Tenzij je hele basale operaties doet moet je zeker niet setTimeout gebruiken als scheduler.

Anyhow, bij voortzetting wellicht handig om dat in een nieuw topic te doen. If not, fijne avond alvast. :)

svenv.nl


  • GateKeaper
  • Registratie: april 2004
  • Laatst online: 18-01 14:20

GateKeaper

#1 Procastinator

Ed Vertijsment schreef op woensdag 2 januari 2019 @ 18:10:
maar dan zit je vast in een oude syntax waar de rest van de wereld naar classes gaat.
En ook alweer van terug komt. (zie react-hooks).

Procrastination for mr. President ! | Startup is looking for (wannabe) meteor developers. PM for info.


  • Mugwump
  • Registratie: mei 2017
  • Nu online
In 2019 naar classes gaan, gekke front enders. :P

  • DevWouter
  • Registratie: februari 2016
  • Laatst online: 18-01 13:24
Mugwump schreef op donderdag 3 januari 2019 @ 00:34:
In 2019 naar classes gaan, gekke front enders. :P
Uhm... Ik wil niet moeilijk doen, maar heb jij ooit html gezien? Het zit vol met classes :Y)


HTML:
1
2
3
4
5
<div class="container">
  <div class="row">
     <div class="col"> And so on... </div>
  </div>
</div>

We doen niet grappig over grappen, grappen maken is bloedserieus werk


  • Antrax
  • Registratie: april 2012
  • Laatst online: 13:23
DevWouter schreef op vrijdag 4 januari 2019 @ 19:11:
[...]


Uhm... Ik wil niet moeilijk doen, maar heb jij ooit html gezien? Het zit vol met classes :Y)


HTML:
1
2
3
4
5
<div class="container">
  <div class="row">
     <div class="col"> And so on... </div>
  </div>
</div>

:Y)

  • Mugwump
  • Registratie: mei 2017
  • Nu online
DevWouter schreef op vrijdag 4 januari 2019 @ 19:11:
[...]


Uhm... Ik wil niet moeilijk doen, maar heb jij ooit html gezien? Het zit vol met classes :Y)


HTML:
1
2
3
4
5
<div class="container">
  <div class="row">
     <div class="col"> And so on... </div>
  </div>
</div>

Ja, want ik doe zelf gewoon full stack. Ik was ook niet degene die zei dat de hele wereld naar classes ging. :P

  • Ed Vertijsment
  • Registratie: juli 2014
  • Laatst online: 13:53
DevWouter schreef op vrijdag 4 januari 2019 @ 19:11:
[...]


Uhm... Ik wil niet moeilijk doen, maar heb jij ooit html gezien? Het zit vol met classes :Y)


HTML:
1
2
3
4
5
<div class="container">
  <div class="row">
     <div class="col"> And so on... </div>
  </div>
</div>

Ik heb toch altijd wel wat moeite gehad met classes als “row” of “col”, veel te gefocussed op opmaak in plaats van descriptive te zijn.

Ik prefereer namen die beschrijven wat ze zijn, niet hoe ze er uit zien.

svenv.nl


  • Mugwump
  • Registratie: mei 2017
  • Nu online
Ed Vertijsment schreef op zondag 6 januari 2019 @ 22:44:
[...]


Ik heb toch altijd wel wat moeite gehad met classes als “row” of “col”, veel te gefocussed op opmaak in plaats van descriptive te zijn.

Ik prefereer namen die beschrijven wat ze zijn, niet hoe ze er uit zien.
Daar heb je eerder de ID voor zou ik zeggen. Classes zijn nou juist hoofdzakelijk bedoeld om styling generiek toe te passen.

  • OkkE
  • Registratie: oktober 2000
  • Laatst online: 18-01 08:56

OkkE

Front-end ninja :+

Ed Vertijsment schreef op zondag 6 januari 2019 @ 22:44:
[...]


Ik heb toch altijd wel wat moeite gehad met classes als “row” of “col”, veel te gefocussed op opmaak in plaats van descriptive te zijn.

Ik prefereer namen die beschrijven wat ze zijn, niet hoe ze er uit zien.
Ik ben ook geen voorstander van classes als “text-center” of “spacing-top”, maar juist classes als “row” en “col” zijn in mijn ogen juist prima. Het vertelt imho wel wat het is, namelijk een rij met daar binnen kolommen en zorgt er voor dat je een eenvoudig te herkennen (en onthouden) systeem hebt voor de globale layout van je website.

OkkE wijzigde deze reactie 07-01-2019 08:36 (9%)

“The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer.”
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers.


  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 12-01 22:39
OkkE schreef op maandag 7 januari 2019 @ 08:35:
[...]

Ik ben ook geen voorstander van classes als “text-center” of “spacing-top”, maar juist classes als “row” en “col” zijn in mijn ogen juist prima. Het vertelt imho wel wat het is, namelijk een rij met daar binnen kolommen en zorgt er voor dat je een eenvoudig te herkennen (en onthouden) systeem hebt voor de globale layout van je website.
text-center, spacing-top e.d. gebruiken is eigenlijk ook gewoon slecht. Als je dan later bepaald dat de tekst bij bepaalde dingen niet meer gecentreerd is, moet je alle html elementen aanpassen. row en col zijn inderdaad (iets) beter. Het liefste geef je het namen als comment-body ipv row. Maar dat is ook niet altijd praktisch, bij veel verschillende types.

Maar laten we eerlijk zijn, welke manier je ook gebruikt, het blijft eigenlijk gewoon monkey-patching. Wat we allemaal willen zijn custom HTML elementen, zodat je het beeste gewoon bij zijn naam kunt noemen, en we niet meer hoeven te klooien.

  • TheNephilim
  • Registratie: september 2005
  • Laatst online: 18-01 17:46

TheNephilim

Wtfuzzle

Er is niks mis met "utility CSS frameworks", of hoe je deze werkwijze dan ook wil noemen. Echter kun je niet van BEM ineens de classes ed. gaan vervangen door utility varianten. Je moet ook je HTML op de schop nemen. Utility CSS in combinatie met components werkt heel goed. Ik vind het heerlijk dat ik niet meer uren hoef na te denken over hoe ik een bepaalde div-class moet gaan noemen die één specifiek ding moet doen dat nergens anders meer voorkomt. Je knalt er de juiste utility-classes in en klaar.

VILF Gaming


  • Crazy D
  • Registratie: augustus 2000
  • Laatst online: 15:50

Crazy D

I think we should take a look.

ThomasG schreef op maandag 7 januari 2019 @ 11:25:
row en col zijn inderdaad (iets) beter. Het liefste geef je het namen als comment-body ipv row. Maar dat is ook niet altijd praktisch, bij veel verschillende types.
Ik ben geen front-ender maar als je een table hebt met rijen en de ene keer zijn dat comments maar de andere keer een lijst van gevonden medewerkers, is row en col toch nog steeds prima als basis (die bepalen via de css dat het een table is), en voeg je extra classes toe voor de detaillering (als er extra opmaak nodig is naast de row en col). col--comment bijvoorbeeld.

Exact expert nodig? itwize.nl


  • dev10
  • Registratie: april 2005
  • Laatst online: 13:45
ThomasG schreef op maandag 7 januari 2019 @ 11:25:
[...]
Wat we allemaal willen zijn custom HTML elementen, zodat je het beeste gewoon bij zijn naam kunt noemen, en we niet meer hoeven te klooien.
Webcomponents dus: https://www.webcomponents.org/introduction

Heb jij HBO werk- en denkniveau en ben je op zoek naar een baan als developer? DM mij voor meer info.


  • Ed Vertijsment
  • Registratie: juli 2014
  • Laatst online: 13:53
Mugwump schreef op zondag 6 januari 2019 @ 23:01:
[...]


Daar heb je eerder de ID voor zou ik zeggen. Classes zijn nou juist hoofdzakelijk bedoeld om styling generiek toe te passen.
Dat zou ik juist niet doen, id's moeten uniek zijn en dit maakt je component dus niet herbruikbaar. Nu kan je zeggen dat je, je navigatiebalk toch niet hergebruikt en differentiëren tussen herbruikbare en niet-herbruikbare componenten maar dan zit je A: vast aan niet herbruikbaarheid (en ja, ik zie echt situaties waarin de navigatiebalk toch herhaaldelijk terug moet komen). en B: met twee manieren om hetzelfde te doen wat nou ook niet bepaald handig is.

Bij voorkeur selecteer ik altijd op classes. Tag selectors zijn breekbaar, er kan iemand namelijk zomaar wegens SEO een h3'tje in een h4'tje willen veranderen en dan wil je niet (altijd) je styling meenemen. Op id selecteren breekt herbruikbaarheid (zie hierboven) en classes blijven dan over.

Een voorbeeld van een uitzondering is werken met WYSIWYG content, je kan immers niet de klant vragen om keurig classes op h3'tje te gaan zetten. In dat geval gebruikt een wysiwyg mixin die binnen de scope van een component dit afdwingt zonder globaal alles te gaan overriden.
OkkE schreef op maandag 7 januari 2019 @ 08:35:
[...]

Ik ben ook geen voorstander van classes als “text-center” of “spacing-top”, maar juist classes als “row” en “col” zijn in mijn ogen juist prima. Het vertelt imho wel wat het is, namelijk een rij met daar binnen kolommen en zorgt er voor dat je een eenvoudig te herkennen (en onthouden) systeem hebt voor de globale layout van je website.
Maar is het wel een rij met kolommen? Of staat gewoon alles onder elkaar op mobiel? Het probleem blijft hetzelfde, het beschrijft een visuele weergave van een component en dat hoort gewoon niet thuis in een HTML tree, daar heb je immers je stijlsheet voor.

Container is wellicht minder erg, (al vind ik dit een component dat eigenlijk niet nodig zou moeten zijn). De term beschrijft namelijk niet hoe het eruit ziet maar wat het doet.

Ed Vertijsment wijzigde deze reactie 07-01-2019 14:20 (6%)

svenv.nl


  • Mugwump
  • Registratie: mei 2017
  • Nu online
Ed Vertijsment schreef op maandag 7 januari 2019 @ 14:14:
Maar is het wel een rij met kolommen? Of staat gewoon alles onder elkaar op mobiel? Het probleem blijft hetzelfde, het beschrijft een visuele weergave van een component en dat hoort gewoon niet thuis in een HTML tree, daar heb je immers je stijlsheet voor.
Je interpreteert rij en kolom nu als visuele zaken terwijl het ook bijvoorbeeld gewoon wiskundige concepten in een matrix zijn.
En zelfs als het bijvoorbeeld een producttabelbetreft dan ga je toch niet elke rij een CSS class product of zelfs productX geven en dan elke cell een class prijs of zelfs prijsvanproductX geven?

  • alienfruit
  • Registratie: maart 2003
  • Laatst online: 16:55

alienfruit

the alien you never expected

Wat doen jullie als je een oudere versie van een browser nodig hebt voor een bug report? Bijv. ik heb een bug voor Chrome 57.0.2987 (Windows 10). Kan nergens bij Google een website vinden met een archief van oudere versies

  • OkkE
  • Registratie: oktober 2000
  • Laatst online: 18-01 08:56

OkkE

Front-end ninja :+

Ed Vertijsment schreef op maandag 7 januari 2019 @ 14:14:
Maar is het wel een rij met kolommen? Of staat gewoon alles onder elkaar op mobiel? Het probleem blijft hetzelfde, het beschrijft een visuele weergave van een component en dat hoort gewoon niet thuis in een HTML tree, daar heb je immers je stijlsheet voor.

Container is wellicht minder erg, (al vind ik dit een component dat eigenlijk niet nodig zou moeten zijn). De term beschrijft namelijk niet hoe het eruit ziet maar wat het doet.
Voor mij is row niet perse een rij in de visuele zin van het woord maar een verzameling; het had ook collection of matrix mogen zijn. Zelfde met col, dat is niet zo zeer een kolom in de visuele zin van het woord maar één element binnen zo'n verzameling; dat had ook item of cell kunnen zijn.
Enige reden dat ik nog steeds row en col gebruik is omdat het ook in Bootstrap is gebruikt en daar door herkenbare classes, waarbij het ook voor mijn collega's direct duidelijk is wat het doet.

Dat soort classes vind ik heel wat anders dan een text-center, want dat vind ik wel een visuele class die te veel zegt over de vormgeving en dus op een andere manier moet worden opgelost.
alienfruit schreef op maandag 7 januari 2019 @ 15:13:
Wat doen jullie als je een oudere versie van een browser nodig hebt voor een bug report? Bijv. ik heb een bug voor Chrome 57.0.2987 (Windows 10). Kan nergens bij Google een website vinden met een archief van oudere versies
Tot nu toe nooit een oude versie van Chrome (of Firefox of Safari) nodig gehad gelukkig. De persoon die zoiets meldde kon altijd updaten naar de laatste versie. :-) En gelukkig kan je voor Internet Explorer wel oude versies downloaden.

OkkE wijzigde deze reactie 07-01-2019 15:24 (18%)

“The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer.”
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers.


  • alienfruit
  • Registratie: maart 2003
  • Laatst online: 16:55

alienfruit

the alien you never expected

Ja klopt, het is een melding in Sentry dat iets fout gaat in polyfill.js. Maar ja, ik weet op basis van het tipadres niet om welke gebruiker het gaat. Ik wilde dus zelf even kijken of het iets is wat op te lossen was.

  • Ed Vertijsment
  • Registratie: juli 2014
  • Laatst online: 13:53
Mugwump schreef op maandag 7 januari 2019 @ 14:46:
[...]


Je interpreteert rij en kolom nu als visuele zaken terwijl het ook bijvoorbeeld gewoon wiskundige concepten in een matrix zijn.
En zelfs als het bijvoorbeeld een producttabelbetreft dan ga je toch niet elke rij een CSS class product of zelfs productX geven en dan elke cell een class prijs of zelfs prijsvanproductX geven?
OkkE schreef op maandag 7 januari 2019 @ 15:21:
[...]

Voor mij is row niet perse een rij in de visuele zin van het woord maar een verzameling; het had ook collection of matrix mogen zijn. Zelfde met col, dat is niet zo zeer een kolom in de visuele zin van het woord maar één element binnen zo'n verzameling; dat had ook item of cell kunnen zijn.
Binnen een tabel of matrix is het dan ook gewoon correct. Een tabel bestaat immers conceptueel al (zoals jullie zelf goed opmerken) uit rijen en kolommen. Voor tabellen zijn dit prima benamingen. Net zo goed als je gewoon een <table> tag gebruikt voor tabellen waar dat voor layouts absoluut not done is.
OkkE schreef op maandag 7 januari 2019 @ 15:21:
[...]

Enige reden dat ik nog steeds row en col gebruik is omdat het ook in Bootstrap is gebruikt en daar door herkenbare classes, waarbij het ook voor mijn collega's direct duidelijk is wat het doet.
Het probleem is dan dat Bootstrap het fout doet, en je het hier doorzet en niet oplost. Wellicht met een reden maar het blijft een onjuiste benadering ervan. Overigens hoort naar mijn inziens deze layout logic gewoon in een stylesheet en niet in de HTML tree.
alienfruit schreef op maandag 7 januari 2019 @ 15:13:
Wat doen jullie als je een oudere versie van een browser nodig hebt voor een bug report? Bijv. ik heb een bug voor Chrome 57.0.2987 (Windows 10). Kan nergens bij Google een website vinden met een archief van oudere versies
Browserstack.

Ed Vertijsment wijzigde deze reactie 07-01-2019 15:48 (9%)

svenv.nl


  • Mugwump
  • Registratie: mei 2017
  • Nu online
Ed Vertijsment schreef op maandag 7 januari 2019 @ 15:28:
Het probleem is dan dat Bootstrap het fout doet, en je het hier doorzet en niet oplost. Wellicht met een reden maar het blijft een onjuiste benadering ervan. Overigens hord naar mijn inziens deze layout logic gewoon in een stylesheet en niet in de HTML tree.
Dat is uiteindelijk ook een interpretatiekwestie. De layoutkwestie zit ook gewoon in je stylesheet. Die bepaalt namelijk hoe je rows en je cols weergegeven worden. Rows en cols geven meer aan dat je een repeterend iets hebt (een row) en daarbinnnen meerdere elementen, veelal ook repeterend. Het staat de stylesheet verder vrij om te bepalen hoe dat dan verder weergegeven moet worden.

Daarnaast is er natuurlijk ook een zeker pragmatisme. Als je consistentie in je layout wil houden met een zekere basisstructuur zoals bijvoorbeeld een Bootstrap grid, dan ontkom je haast niet aan het beschrijven van de relatie tussen componenten in dergelijke generieke structuren. Er is natuurlijk ook een reden dat een class attribute niet beperkt is tot één enkele class, maar er gewoon veel meer ondersteund. Je kunt een div naast een 'row' class ook best een 'product' class meegeven als je dat handiger vindt.
In pragmatisch opzicht mis ik ook volledig het voordeel van een dergelijke aanpak. Wat levert het precies op om 'beschrijvende classes' te gebruiken?

  • gekkie
  • Registratie: april 2000
  • Laatst online: 19:25
Yeuh de FOSDEM talks staan weer online, waar kan ik me laten klonen, weer genoeg potentieel interessants wat parallel is.
Gelijk m'n halve doopceel mogen lichten voor een inreisvisum van de gemeente Brussel.

  • Gropah
  • Registratie: december 2007
  • Nu online

Gropah

Moderator Spielerij

Oompa-Loompa 💩

alienfruit schreef op maandag 7 januari 2019 @ 15:13:
Wat doen jullie als je een oudere versie van een browser nodig hebt voor een bug report? Bijv. ik heb een bug voor Chrome 57.0.2987 (Windows 10). Kan nergens bij Google een website vinden met een archief van oudere versies
Man, praat me niet over browser versies. Zo vaak gehad dat ik een bugreport wil indienen, om bij het checken van de versie er achter te komen dat ik outdated ben (met 0.0.2 oid), waarna hij gaat updaten en ik het nog eens mag gaan testen

Strong, united, working 'till we fall


  • alienfruit
  • Registratie: maart 2003
  • Laatst online: 16:55

alienfruit

the alien you never expected

Hah, Browserstack is een goed idea. Eens vragen of we er een abo op hebben

  • Ed Vertijsment
  • Registratie: juli 2014
  • Laatst online: 13:53
Mugwump schreef op maandag 7 januari 2019 @ 15:56:
[...]

Dat is uiteindelijk ook een interpretatiekwestie.
Uiteindelijk wel, alles wat hier gezegd is dan ook subjectief, voel je ook zeker niet aangevallen als het anders doet.
[/quote]
Mugwump schreef op maandag 7 januari 2019 @ 15:56: Wat levert het precies op om 'beschrijvende classes' te gebruiken?
Een van de problemen die ik tegenkwam met het gebruik van Bootstrap/jQuery is dat veel frontend code en met name HTML dermate complex en bloated werd dat het lastig werd om templates her te gebruiken. De wens is bij ons namelijk om componenten pluggable van het ene project in het andere te slepen, er een nieuw jasje aan te hangen en klaar. Nog beter zou zijns om "pip install navbar" te doen et voilà done.

In het bovenstaande scenario wil je niet dat in de template al staat waar een component zichzelf plaatst of hoe het eruit komt te zien. Je wilt alleen de logic en inhoud bewaren. Daarnaast hadden we andere problemen die het in de weg zaten om vrij componenten uit te wisselen.

We houden nu het volgende aan.

- Alles is een component, templates (views) zijn slechts configuraties van welke componenten op een pagina mogen werken.
- Composition over inheritance. Geen aanpassingen van componenten maar gewoon nesten.
- Componenten mogen enkel binnen hun border-box opereren om zo collissions met andere componenten te voorkomen, het parent component is verantwoordlijk voor de uitlijning/plaatsing van de children.
- Een template (view), als deze al bestaat is enkel verantwoordelijk voor het uitlijnen van children.
- Geen opmaakcode in HTML. SASS moet 100% geïsoleerd zijn logic/content.
- Geen (SASS) globals, globals zijn evil. Alle styling moet in componenten zelf bepaald worden. Om code te delen kunnen mixins uit libraries gebruikt worden. Altijd met een explicite import van een library zelf.
- Geen CSS resets, CSS resets zijn globals. Daarnaast onbetrouwbaar door het geneste karakter en niet nodig want alle styling staat op het component zelf.
- Componenten hebben voor zowel SASS, JS, als HTML hun eigen dedicated map en delen niets met elkaar uit deze map. Alles shared code gaat via libraries.
- Libraries mogen niet direct code wegschrijven (SASS), deze worden meerdere malen geïmporteerd en dit zou dus resulteren in een loze regels op een stylesheet.

Daarnaast houden we nog wat generieke regels aan zoals "gebruik BEM" maar die zijn mindere interessant voor deze discussie.

Dit zijn een hoop regels om aan te houden maar het zorgt ervoor dat je pijnloos code van project A in project B kunt draaien.

svenv.nl


  • DevWouter
  • Registratie: februari 2016
  • Laatst online: 18-01 13:24
Ed Vertijsment schreef op maandag 7 januari 2019 @ 16:14:
[...]
Een van de problemen die ik tegenkwam met het gebruik van Bootstrap/jQuery is dat veel frontend code en met name HTML dermate complex en bloated werd dat het lastig werd om templates her te gebruiken.
Allereerst ben ik het volledig met je verhaal eens, maar ik denk wel dat Bootstrap en jQuery wel wat meer eer verdienen.
jQuery was geniaal omdat het je als ontwikkelaar geen rekening meer hoefde te houden met allerlei verschillen tussen de browsers (we hebben het over 2006).
Bootstrap was geniaal omdat je met een paar regels code een complete pagina kan bouwen en het heleboel standaard ontwerp gaf die meteen geschikt waren voor mobiel (we hebben het over 2011).

5 jaar geleden zou ik echt niet snel iets gedaan hebben zonder die twee, maar tegenwoordig zit Bootstrap en Jquery mij vaker in de weg dan wat anders.

Ahh... Ik kan me nog de dag herinneren dat ik jQuery uit een productie website haalde... Alles werkte, maar 2 maanden later stond er op eens een collega aan mijn bureau met het verzoek of ik jQuery er terug in kon stoppen zodat hij $('.comment').length kon doen ivm Analytics. Heb hem toen fijntjes uitgelegd wat document.querySelectorAll('.comment') hetzelfde doet.

We doen niet grappig over grappen, grappen maken is bloedserieus werk


  • Ed Vertijsment
  • Registratie: juli 2014
  • Laatst online: 13:53
DevWouter schreef op maandag 7 januari 2019 @ 18:32:
[...]


Allereerst ben ik het volledig met je verhaal eens, maar ik denk wel dat Bootstrap en jQuery wel wat meer eer verdienen.
jQuery was geniaal omdat het je als ontwikkelaar geen rekening meer hoefde te houden met allerlei verschillen tussen de browsers (we hebben het over 2006).
Bootstrap was geniaal omdat je met een paar regels code een complete pagina kan bouwen en het heleboel standaard ontwerp gaf die meteen geschikt waren voor mobiel (we hebben het over 2011).

5 jaar geleden zou ik echt niet snel iets gedaan hebben zonder die twee, maar tegenwoordig zit Bootstrap en Jquery mij vaker in de weg dan wat anders.

Ahh... Ik kan me nog de dag herinneren dat ik jQuery uit een productie website haalde... Alles werkte, maar 2 maanden later stond er op eens een collega aan mijn bureau met het verzoek of ik jQuery er terug in kon stoppen zodat hij $('.comment').length kon doen ivm Analytics. Heb hem toen fijntjes uitgelegd wat document.querySelectorAll('.comment') hetzelfde doet.
Don’t get me wrong here. jQuery was zeker geniaal. De belofte van bootstrap maakt alles makkelijk heeft het voor mij nooit waar kunnen maken maar laten we niet vergeten dat het oorspronkelijk een prototype tool was. Het was initieel nooit bedoelt als productie franework.

svenv.nl


  • RobIII
  • Registratie: december 2001
  • Nu online

RobIII

Moderator Devschuur®

^ Romeinse 3 ja!

Unlimited free private repositories with GitHub Free *O*

RobIII wijzigde deze reactie 08-01-2019 08:10 (16%)

Flat earth is not theory, it is a diagnosis.

Over mij | Wat vervelend


  • kenneth
  • Registratie: september 2001
  • Niet online

kenneth

achter de duinen

Net gedowngraded! Thanks, Microsoft!

kenneth wijzigde deze reactie 08-01-2019 08:14 (7%)

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


  • Tjolk
  • Registratie: juni 2007
  • Laatst online: 18-01 15:09

Tjolk

FP ProMod
Ed Vertijsment schreef op maandag 7 januari 2019 @ 14:14:
Tag selectors zijn breekbaar, er kan iemand namelijk zomaar wegens SEO een h3'tje in een h4'tje willen veranderen en dan wil je niet (altijd) je styling meenemen niet meer met die persoon samenwerken.
FTFY. :O

Tjolk is lekker. overal en altijd.


  • Laurens-R
  • Registratie: december 2002
  • Laatst online: 16-01 23:50
kenneth schreef op dinsdag 8 januari 2019 @ 07:59:
[...]

Net gedowngraded! Thanks, Microsoft!
Ik moet zeggen dat Microsoft inderdaad goed bezig is. Ik hoop dat mensen die skeptisch waren over de overname ook inzien dat een overname ook voordelen (zoals deze kan hebben). Ik betwijfel of Github deze stap had gemaakt indien ze niet waren overgenomen.

Ik vind de vooruitgang bij Microsoft echt enorm de afgelopen jaren; ze richten zich echt in een hele brede manier op developers en embracen veel (open-source) technologie die bijdraagt aan software ontwikkel trajecten. In het verleden voelde ik me toch in een soort Microsoft bubble zitten; de API's en frameworks waren heel erg Microsoft georienteerd, waar Microsoft nu een mantra lijkt te hebben van "if you can't beat them, join them". Er worden veel proefballonnetjes opgelaten... veel ruimte voor experimenteren. En als iemand anders het beter heeft gedaan, zijn ze eerder bereid om hun eigen framework te vervangen door de betreffende 3rd party library.

Ik mis Steve Balmer voor geen meter. :w

Laurens-R wijzigde deze reactie 08-01-2019 12:29 (13%)


  • kenneth
  • Registratie: september 2001
  • Niet online

kenneth

achter de duinen

Ja, de focus lijkt verschoven van developers binden omdat ze niet anders kunnen (lock-in) naar developers binden omdat ze niet anders willen (goed ecosysteem). Wat mij betreft een goede richting ja.

kenneth wijzigde deze reactie 08-01-2019 12:36 (7%)

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


  • Mugwump
  • Registratie: mei 2017
  • Nu online
kenneth schreef op dinsdag 8 januari 2019 @ 12:35:
Ja, de focus lijkt verschoven van developers binden omdat ze niet anders kunnen (lock-in) naar developers binden omdat ze niet anders willen (goed ecosysteem). Wat mij betreft een goede richting ja.
Waar ze alleen nog wel eens vanaf mogen is het idee dat ze zelf weer allerlei UI concepten moeten uitvinden. Die blades in Azure en ook al die net niet intuïtieve zaken in VSTSAzure Devops storen me mateloos. :P
Maar verder zie ik inderdaad heel veel positieve ontwikkelingen.

  • Alex)
  • Registratie: juni 2003
  • Laatst online: 18:14
Laurens-R schreef op dinsdag 8 januari 2019 @ 12:26:
[...]


En als iemand anders het beter heeft gedaan, zijn ze eerder bereid om hun eigen framework te vervangen door de betreffende 3rd party library.
Al komen ze daar soms wel weer op terug. In de volgende release van .NET Core gaan ze weer by default hun eigen JSON serializer gebruiken i.p.v. JSON.NET.

We are shaping the future


  • Ed Vertijsment
  • Registratie: juli 2014
  • Laatst online: 13:53
Muah een beetje flauw niet? SEO hoeft niet je favo beroep te zijn, is het van mij ook niet maar het genoemde scenario komt vaan genoeg voor en dan mag je best een beetje de verantwoordelijkheid bij jezelf leggen om gewoon robuuste software te maken.

svenv.nl


  • BladeSlayer1000
  • Registratie: april 2013
  • Laatst online: 19:30
Zeker mooi nieuws van Github, scheelt mij omschakelen tussen Github en Bitbucket :)

  • Tjolk
  • Registratie: juni 2007
  • Laatst online: 18-01 15:09

Tjolk

FP ProMod
Ed Vertijsment schreef op dinsdag 8 januari 2019 @ 15:31:
[...]


Muah een beetje flauw niet? SEO hoeft niet je favo beroep te zijn, is het van mij ook niet maar het genoemde scenario komt vaan genoeg voor en dan mag je best een beetje de verantwoordelijkheid bij jezelf leggen om gewoon robuuste software te maken.
Nou ja, mijn favoriete beroep is het ook zeker niet. Maar als iemand denkt dat hij de oorlog kan winnen door een h3 om te zetten na een h4 zit je wel heel erg in de marge te pielen. Misschien relevant is de buitencategorie van competitieve markten ofzo, maar doorgaans geldt gewoon dat je moet zorgen voor goede content een descriptive DOM. Dus niet alles aan elkaar hangen met divjes, maar netjes section, nav etc. gebruiken. Een h3 en h4 zijn beide headings en een h3 is simpelweg van groter belang dan een h4. In je document, dat is. Als je de hele santekraam van h1 gaat voorzien om aan te geven dat alles super duper belangrijk is dan lachen de zoekmachines je ook gewoon keihard in je gezicht uit.

Verder is het sowieso mijn kop thee niet hoor, dat SEO geneuzel. Ik hoef me daar ook niet druk om te maken gelukkig.

Tjolk is lekker. overal en altijd.


  • Ed Vertijsment
  • Registratie: juli 2014
  • Laatst online: 13:53
Tjolk schreef op dinsdag 8 januari 2019 @ 16:44:
[...]

Verder is het sowieso mijn kop thee niet hoor, dat SEO geneuzel. Ik hoef me daar ook niet druk om te maken gelukkig.
Daarom laat je dat (ik ook) over aan de expert en zorg ik ervoor dat de opmaak onafhankelijk functioneerd van de koppenstructuur of de naam van tags.

Overigens zijn er meerdere redenen te bedenken om tags te husselen. Maar je frontend zou er niet stuk ok moeten gaan.

svenv.nl


  • Mugwump
  • Registratie: mei 2017
  • Nu online
Ed Vertijsment schreef op maandag 7 januari 2019 @ 16:14:
[...]


Uiteindelijk wel, alles wat hier gezegd is dan ook subjectief, voel je ook zeker niet aangevallen als het anders doet.
[/quote]


[...]


Een van de problemen die ik tegenkwam met het gebruik van Bootstrap/jQuery is dat veel frontend code en met name HTML dermate complex en bloated werd dat het lastig werd om templates her te gebruiken. De wens is bij ons namelijk om componenten pluggable van het ene project in het andere te slepen, er een nieuw jasje aan te hangen en klaar. Nog beter zou zijns om "pip install navbar" te doen et voilà done.

In het bovenstaande scenario wil je niet dat in de template al staat waar een component zichzelf plaatst of hoe het eruit komt te zien. Je wilt alleen de logic en inhoud bewaren. Daarnaast hadden we andere problemen die het in de weg zaten om vrij componenten uit te wisselen.

We houden nu het volgende aan.

- Alles is een component, templates (views) zijn slechts configuraties van welke componenten op een pagina mogen werken.
- Composition over inheritance. Geen aanpassingen van componenten maar gewoon nesten.
- Componenten mogen enkel binnen hun border-box opereren om zo collissions met andere componenten te voorkomen, het parent component is verantwoordlijk voor de uitlijning/plaatsing van de children.
- Een template (view), als deze al bestaat is enkel verantwoordelijk voor het uitlijnen van children.
- Geen opmaakcode in HTML. SASS moet 100% geïsoleerd zijn logic/content.
- Geen (SASS) globals, globals zijn evil. Alle styling moet in componenten zelf bepaald worden. Om code te delen kunnen mixins uit libraries gebruikt worden. Altijd met een explicite import van een library zelf.
- Geen CSS resets, CSS resets zijn globals. Daarnaast onbetrouwbaar door het geneste karakter en niet nodig want alle styling staat op het component zelf.
- Componenten hebben voor zowel SASS, JS, als HTML hun eigen dedicated map en delen niets met elkaar uit deze map. Alles shared code gaat via libraries.
- Libraries mogen niet direct code wegschrijven (SASS), deze worden meerdere malen geïmporteerd en dit zou dus resulteren in een loze regels op een stylesheet.

Daarnaast houden we nog wat generieke regels aan zoals "gebruik BEM" maar die zijn mindere interessant voor deze discussie.

Dit zijn een hoop regels om aan te houden maar het zorgt ervoor dat je pijnloos code van project A in project B kunt draaien.
Of je gebruikt een server side framework als Vaadin, kun je tenminste in een fatsoenlijke taal herbruikbare componenten bouwen. :P

  • Ed Vertijsment
  • Registratie: juli 2014
  • Laatst online: 13:53
Mugwump schreef op dinsdag 8 januari 2019 @ 19:44:
[...]


Of je gebruikt een server side framework als Vaadin, kun je tenminste in een fatsoenlijke taal herbruikbare componenten bouwen. :P
Goede design principles zijn taal en framework agnostisch. Geen framework is zo goed om afstand van deftig werk te verantwoorden.

svenv.nl


  • Mugwump
  • Registratie: mei 2017
  • Nu online
Ed Vertijsment schreef op dinsdag 8 januari 2019 @ 19:59:
[...]


Goede design principles zijn taal en framework agnostisch. Geen framework is zo goed om afstand van deftig werk te verantwoorden.
Goede design principles zijn toch net wat lastiger toe te passen in Assembly dan in bijvoorbeeld Java of C#. :P

  • Ed Vertijsment
  • Registratie: juli 2014
  • Laatst online: 13:53
Mugwump schreef op dinsdag 8 januari 2019 @ 20:23:
[...]


Goede design principles zijn toch net wat lastiger toe te passen in Assembly dan in bijvoorbeeld Java of C#. :P
True, maar design principles zijn er om code beter en leesbaarder, beter te onderhouden, veiliger (etc. etc.) te maken. Hogere talen delen een beetje dat doel.

Maar zowel in Java als in Python of PHP of C# of Javascript of (S)CSS kun je DRY principles toepassen of seperation of concerns toepassen of gescoped werken.

Dus tenzij je in assembly zit te tikken snap ik je punt niet helemaal.

svenv.nl


  • Douweegbertje
  • Registratie: mei 2008
  • Laatst online: 13:59

Douweegbertje

Wat kinderachtig.. godverdomme

kenneth schreef op dinsdag 8 januari 2019 @ 12:35:
Ja, de focus lijkt verschoven van developers binden omdat ze niet anders kunnen (lock-in) naar developers binden omdat ze niet anders willen (goed ecosysteem). Wat mij betreft een goede richting ja.
Of dat ze nu in elk geval private repo's kunnen inzien voor meer data. Ik heb geen tinfoil hat op maar ik zie dit ook nog wel legitiem als één van de grotere redenen.

  • rutgerw
  • Registratie: juni 2004
  • Laatst online: 19:01
Douweegbertje schreef op woensdag 9 januari 2019 @ 09:28:
[...]


Of dat ze nu in elk geval private repo's kunnen inzien voor meer data. Ik heb geen tinfoil hat op maar ik zie dit ook nog wel legitiem als één van de grotere redenen.
Waarom zouden 'ze' (wie: Github of Microsoft?) dat willen? Het is niet dat je iets kan met die data, afgezien van wat geaggregeerde statistiekjes produceren. Als 'ze' iets doen met die data, lijkt me niemand meer code daar wil plaatsen toch?

  • Cloud
  • Registratie: november 2001
  • Laatst online: 18-01 16:09

Cloud

Moderator FM / T.net PowerMod

Go Hawks!

rutgerw schreef op woensdag 9 januari 2019 @ 09:37:
[...]
Waarom zouden 'ze' (wie: Github of Microsoft?) dat willen? Het is niet dat je iets kan met die data, afgezien van wat geaggregeerde statistiekjes produceren. Als 'ze' iets doen met die data, lijkt me niemand meer code daar wil plaatsen toch?
Ik snap 't ook niet. Ik bedoel op zich wel, als je écht paranoïde bent.

En stel nu dat ze dat wel doen, wat zou GH of MS daar nu werkelijk mee kunnen? En belangrijker nog, als zoiets ooit uit komt: wat zou er dan gebeuren en is het dát voor GH en MS waard? Een beetje het (één na) meest waardevolle bedrijf ter wereld om zeep helpen om in private repo's rond te grasduinen..

Maar goed, het is het aloude argument tegen de cloud. Dropbox medewerkers zitten ook tussen iedereens privé foto's te kijken en Microsoft leest de samenvattingen van je belastingaangiften in OneDrive toch ook al :+

Never attribute to malice that which can be adequately explained by stupidity.


  • Douweegbertje
  • Registratie: mei 2008
  • Laatst online: 13:59

Douweegbertje

Wat kinderachtig.. godverdomme

Cloud schreef op woensdag 9 januari 2019 @ 10:26:
[...]

Ik snap 't ook niet. Ik bedoel op zich wel, als je écht paranoïde bent.

En stel nu dat ze dat wel doen, wat zou GH of MS daar nu werkelijk mee kunnen? En belangrijker nog, als zoiets ooit uit komt: wat zou er dan gebeuren en is het dát voor GH en MS waard? Een beetje het (één na) meest waardevolle bedrijf ter wereld om zeep helpen om in private repo's rond te grasduinen..

Maar goed, het is het aloude argument tegen de cloud. Dropbox medewerkers zitten ook tussen iedereens privé foto's te kijken en Microsoft leest de samenvattingen van je belastingaangiften in OneDrive toch ook al :+
Nogmaals; mij boeit het niet zoveel over wat bedrijven e.d. inzien. Ik gebruik zelf prima github, outlook, gmail etc. Sterker nog; bij mij waren e-mails opeens allemaal gelezen (ik lees niet alle e-mails). Na contact e.d. met outlook kreeg ik het argument "ja dat was een bugje". Sure.

Het gaat er niet om of ik nou paranoïde ben of niet, ik ben wel realistisch. Ik besef gewoon dat zowel outlook als gmail de content inlezen. Metadata bewaren, tags, bepaalde keywords etc. Er zal vast geen medewerker specifiek mijn fototje bekijken maar ik durf wel te beweren dat alles gebruikt wordt in een big data bakje.

Wellicht zie jij niet perse een reden (immers geef je wat generieke voorbeelden van data inzien) maar het heeft wel degelijk een waarde dat je van miljoenen mensen hun private repo's kan inlezen. Je moet het naar mijn mening alleen niet inzien dat iemand een stukje code wilt; maar juist globaal diverse info wilt hebben :)

In de voorwaarden e.d. staat ook expliciet dat ze je content parsen. Easy om dan wat tags eraan te koppelen :)
Er staat ook dat ze informatie sharen; maar het niet verkopen. Dit is natuurlijk heel makkelijk. Maak een contract van "github partner" voor 10k p/m en je "shared" gratis de content?..

------

Los van al mijn niet perse onderbouwde mening gebruik ik gewoon Github en vind ik het een prima partij (idem MS.) Laten we alleen ook een beetje realistisch blijven? :)
We do share certain aggregated, non-personally identifying information with others about how our users, collectively, use GitHub, or how our users respond to our other offerings, such as our conferences or events. For example, we may compile statistics on the usage of open source licenses across GitHub. However, we do not sell this information to advertisers or marketers.
We do share aggregated, non-personally identifying information with third parties. For example, we share the number of stars on a repository, or in the event of a security incident, we may share the number of times a particular file was accessed.
We do share certain aggregated, non-personally identifying information with others about how our users, collectively, use GitHub, or how our users respond to our other offerings, such as our conferences or events. For example, we may compile statistics on the usage of open source licenses across GitHub. However, we do not sell this information to advertisers or marketers.
We need the legal right to do things like host Your Content, publish it, and share it. You grant us and our legal successors the right to store, parse, and display Your Content, and make incidental copies as necessary to render the Website and provide the Service.

  • Cloud
  • Registratie: november 2001
  • Laatst online: 18-01 16:09

Cloud

Moderator FM / T.net PowerMod

Go Hawks!

Douweegbertje schreef op woensdag 9 januari 2019 @ 11:17:
[...]
Het gaat er niet om of ik nou paranoïde ben of niet, ik ben wel realistisch. Ik besef gewoon dat zowel outlook als gmail de content inlezen. Metadata bewaren, tags, bepaalde keywords etc. Er zal vast geen medewerker specifiek mijn fototje bekijken maar ik durf wel te beweren dat alles gebruikt wordt in een big data bakje.
Exact dat laatste. En dan vraag ik mij af wat er mis is met dat big data bakje, want dat is iets hééél anders dan 'in je private repositories kijken' wat mensen als angst hebben. Niemand kijkt erin. Natuurlijk maken ze wat gebruikersstatistieken. Jij wil toch ook trending repos vinden? Dat is inderdaad interessant, ook voor een bedrijf als Microsoft.
Wellicht zie jij niet perse een reden (immers geef je wat generieke voorbeelden van data inzien) maar het heeft wel degelijk een waarde dat je van miljoenen mensen hun private repo's kan inlezen. Je moet het naar mijn mening alleen niet inzien dat iemand een stukje code wilt; maar juist globaal diverse info wilt hebben :)
De waarde die het heeft, zijn die aggregated statistieken en niet de specifieke inhoud waarop die statistieken gebaseerd worden. Mensen lopen nu angstig te doen over dat laatste maar over het algemeen vinden ze het eerste dikke prima. Mijn punt is dat voor dat laatste geen serieuze reden bestaat om bang voor te zijn.
In de voorwaarden e.d. staat ook expliciet dat ze je content parsen. Easy om dan wat tags eraan te koppelen :)
Er staat ook dat ze informatie sharen; maar het niet verkopen. Dit is natuurlijk heel makkelijk. Maak een contract van "github partner" voor 10k p/m en je "shared" gratis de content?..
De voorwaarden, althans de laatste die je geeft, zeggen inderdaad dat ze parsen. Dat moet ook wel gezien hoe de site werkt dus dat is niet echt weg te laten. Daar zijn het nu eenmaal van die voorwaarden voor, ze zijn er niet voor de praktische gang van zaken maar voor het juridisch indekken.

Voor wat betreft handig gebruik maken van partnerships om sneaky aan die voorwaarden te 'ontkomen' zijn we weer full circle: waarom zou MS dat doen? Wat is het risico als dat uitkomt? Is het dat een bedrijf als MS waard? Sorry maar het is écht onnodig angst zaaien.

ALS, en nogmaals een dikke vette ALS, als Microsoft zoiets zou willen gaan doen? Dan kondigen ze dat hartstikke duidelijk aan voordat ze zoiets doen (en helpen ze tegelijkertijd GH om zeep). No way dat een bedrijf als MS het risico van die shitstorm zou willen lopen.
Los van al mijn niet perse onderbouwde mening gebruik ik gewoon Github en vind ik het een prima partij (idem MS.) Laten we alleen ook een beetje realistisch blijven? :)
Nou ja, inderdaad. Ik zeg ook precies dat: laten we een beetje realistisch blijven. Wij verschillen alleen van mening over wat nu realistisch ís.

Never attribute to malice that which can be adequately explained by stupidity.


  • DevWouter
  • Registratie: februari 2016
  • Laatst online: 18-01 13:24
rutgerw schreef op woensdag 9 januari 2019 @ 09:37:
[...]


Waarom zouden 'ze' (wie: Github of Microsoft?) dat willen? Het is niet dat je iets kan met die data, afgezien van wat geaggregeerde statistiekjes produceren. Als 'ze' iets doen met die data, lijkt me niemand meer code daar wil plaatsen toch?
Bijna alle Microsoft technologie heeft telemetry in zich zitten en dat zullen ze ook aan GitHub gaan toevoegen. Dat geeft Microsoft een heleboel data over hoe GitHub gebruikt wordt maar ook welke ontwikkelingen er plaats vinden.

Dit maakt het voor Microsoft een stuk makkelijker om de plannen van hun andere diensten daarop aan te passen. Op die manier kunnen ze hun concurrenten makkelijker voorblijven.

Voorbeeld: Zien ze een heleboel requests van 1 IP afkomen dan kunnen ze onderzoeken wat er op dat IP gebeurt. Dit kan bijvoorbeeld een dienst zijn dat automatisch je code controleert op fouten en vervolgens automatische pull-request maakt en dit maken ze op omdat op dat IP ook een webserver draait.

Dit voorbeeld maakt het voor Microsoft makkelijker om continue te innoveren en de concurrentie achter zich te laten. Dit voorbeeld demonstreert ook aan dat zelfs zonder te kijken naar hoe je account geconfigureerd is welke opkomende diensten er ontstaan. Ze waarborgen jouw privacy en beschermen hun financiële belangen.

Let op: Ik zeg niet dat dit gebeurt, noch of het goed of slecht is, maar als dit gebeurt dan zou ik dat niet vreemd vinden. Echter ik zou Microsoft zijn vermogen om geld te verdienen niet onderschatten. Zij kopen bedrijven om geld te verdienen en hun aandeelhouders te vrede te houden (zoals het ook hoort).

We doen niet grappig over grappen, grappen maken is bloedserieus werk


  • Douweegbertje
  • Registratie: mei 2008
  • Laatst online: 13:59

Douweegbertje

Wat kinderachtig.. godverdomme

Cloud schreef op woensdag 9 januari 2019 @ 12:02:
[...]

Exact dat laatste. En dan vraag ik mij af wat er mis is met dat big data bakje, want dat is iets hééél anders dan 'in je private repositories kijken' wat mensen als angst hebben. Niemand kijkt erin. Natuurlijk maken ze wat gebruikersstatistieken. Jij wil toch ook trending repos vinden? Dat is inderdaad interessant, ook voor een bedrijf als Microsoft.

[...]

De waarde die het heeft, zijn die aggregated statistieken en niet de specifieke inhoud waarop die statistieken gebaseerd worden. Mensen lopen nu angstig te doen over dat laatste maar over het algemeen vinden ze het eerste dikke prima. Mijn punt is dat voor dat laatste geen serieuze reden bestaat om bang voor te zijn.

[...]

De voorwaarden, althans de laatste die je geeft, zeggen inderdaad dat ze parsen. Dat moet ook wel gezien hoe de site werkt dus dat is niet echt weg te laten. Daar zijn het nu eenmaal van die voorwaarden voor, ze zijn er niet voor de praktische gang van zaken maar voor het juridisch indekken.

Voor wat betreft handig gebruik maken van partnerships om sneaky aan die voorwaarden te 'ontkomen' zijn we weer full circle: waarom zou MS dat doen? Wat is het risico als dat uitkomt? Is het dat een bedrijf als MS waard? Sorry maar het is écht onnodig angst zaaien.

ALS, en nogmaals een dikke vette ALS, als Microsoft zoiets zou willen gaan doen? Dan kondigen ze dat hartstikke duidelijk aan voordat ze zoiets doen (en helpen ze tegelijkertijd GH om zeep). No way dat een bedrijf als MS het risico van die shitstorm zou willen lopen.

[...]

Nou ja, inderdaad. Ik zeg ook precies dat: laten we een beetje realistisch blijven. Wij verschillen alleen van mening over wat nu realistisch ís.
DevWouter schreef op woensdag 9 januari 2019 @ 13:48:
[...]


Ze waarborgen jouw privacy en beschermen hun financiële belangen.
Tja, het enige wat ik er over wil zeggen is: nieuws: Ministerie: Windows 10 Enterprise en Office zijn risico voor privacy ...

Onbewust gebeurd er soms meer dan dat je denkt.

Douweegbertje wijzigde deze reactie 09-01-2019 16:31 (4%)


  • Cloud
  • Registratie: november 2001
  • Laatst online: 18-01 16:09

Cloud

Moderator FM / T.net PowerMod

Go Hawks!

DevWouter schreef op woensdag 9 januari 2019 @ 13:48:
[...]
Echter ik zou Microsoft zijn vermogen om geld te verdienen niet onderschatten. Zij kopen bedrijven om geld te verdienen en hun aandeelhouders te vrede te houden (zoals het ook hoort).
Absoluut. Maar ik denk wel dat Microsoft GitHub gekocht heeft om indirect aan te verdienen. GitHub zou toch nooit rendabel worden omdat het gewoon strookt met waarvoor ze het meeste gebruikt worden.

Maar juist dat opnemen in het ecosysteem en veel betere en vergaande integraties; ja daar kunnen ze aan verdienen door meer mensen naar het platform te krijgen. En weer betere statistieken enzo te verkrijgen :)
Douweegbertje schreef op woensdag 9 januari 2019 @ 16:30:
[...]
Tja, het enige wat ik er over wil zeggen is: nieuws: Ministerie: Windows 10 Enterprise en Office zijn risico voor privacy ...

Onbewust gebeurd er soms meer dan dat je denkt.
Absoluut :) Het gaat ook wel eens mis maar dit soort dingen zijn vaak onschuldig in aanleiding. Microsoft was niet (kwaadaardig) er op uit om gebruikersgegevens van rijksambtenaren op te sporen; ze krijgen die gebruikersgegevens van alle gebruikers dus óók die van rijksambtenaren. Het is wel problematisch maar niet kwaad bedoeld (even afgezien van de W10 telemetrie discussie op zich maar dat was goed bekend).

GitHub kan niet heimelijk nog meer van je verzamelen want je geeft immers alles al. Het enige waar je bang voor zou kunnen zijn is inderdaad of een backup van GitHub op de verkeerde plaats belandt ofzo maar dat is niet anders dan vóór de overname. Dat zijn dan ook fouten buiten je eigen macht om en is niet kwaad bedoeld. En daarnaast, die specifieke angst is een valide argument tegen je spullen in de cloud zetten natuurlijk. Maar goed, zo zie ik het :)

Cloud wijzigde deze reactie 09-01-2019 16:58 (49%)

Never attribute to malice that which can be adequately explained by stupidity.


  • ZaZ
  • Registratie: oktober 2002
  • Laatst online: 00:26

ZaZ

Tweakers abonnee

Alex) schreef op dinsdag 8 januari 2019 @ 13:23:
[...]

Al komen ze daar soms wel weer op terug. In de volgende release van .NET Core gaan ze weer by default hun eigen JSON serializer gebruiken i.p.v. JSON.NET.
Is dat niet om voornamelijk om de reden dat veel mensen zelf ook JSON.NET referencen en dan dus collisions in versies krijgen? Dat is natuurlijk wel te spoofen maar dat is waarschijnlijk niet de user experience waar ze naar opzoek zijn voor voornamelijk nieuwe gebruikers die hun tutorials volgen.

Ik denk dat ze best wel openstaan voor een alternatief, maar door volledig op (in dit geval) JSON.NET te leunen je weer nieuwe obstakels krijgt.

Lekker op de bank


  • Hydra
  • Registratie: september 2000
  • Laatst online: 16:56
DevWouter schreef op woensdag 9 januari 2019 @ 13:48:
Let op: Ik zeg niet dat dit gebeurt, noch of het goed of slecht is, maar als dit gebeurt dan zou ik dat niet vreemd vinden. Echter ik zou Microsoft zijn vermogen om geld te verdienen niet onderschatten. Zij kopen bedrijven om geld te verdienen en hun aandeelhouders te vrede te houden (zoals het ook hoort).
Precies. En dit geldt gewoon voor alle grote beursgenoteerde bedrijven. Als er op korte danwel lange termijn waarde gehaald kan worden uit iets doen ze dat ook. Maakt niet uit of het MS, Google, Facebook, Amazon of Philips is. Die bedrijven moeten zich bewegen binnen wetten en regels, maar dat is wel ongeveer de max beperking die ze hebben. Bedrijven zijn niet inherent goed of slecht, ze zijn gewoon.

https://niels.nu


  • .oisyn
  • Registratie: september 2000
  • Laatst online: 16:44

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

If we can hit that bullseye, the rest of the dominoes will fall like a house of cards. Checkmate.


  • TheNephilim
  • Registratie: september 2005
  • Laatst online: 18-01 17:46

TheNephilim

Wtfuzzle

Net zoiets als dat je een website bezoekt, bijv. Hovenier X en vervolgens overal advertenties ziet van Hovenier X. Dat is toch weggegooid geld? Ik weet immers al van het bestaan van Hovenier X, richt die advertenties op nieuwe klanten... dat is toch veel logischer? :?

VILF Gaming


  • Douweegbertje
  • Registratie: mei 2008
  • Laatst online: 13:59

Douweegbertje

Wat kinderachtig.. godverdomme

TheNephilim schreef op vrijdag 11 januari 2019 @ 10:13:
[...]


Net zoiets als dat je een website bezoekt, bijv. Hovenier X en vervolgens overal advertenties ziet van Hovenier X. Dat is toch weggegooid geld? Ik weet immers al van het bestaan van Hovenier X, richt die advertenties op nieuwe klanten... dat is toch veel logischer? :?
Remarketing. Afhankelijk van de use-case (type product, webshop, etc) kan dit veel meer opleveren dan alleen richten op nieuwe leads. Zeker voor producten die je eigenlijk niet zomaar komt. Denk hierbij aan de wat duurdere producten.
Daarnaast is het continue promoten van een merk een manier om een bepaald bewustheid te creëren bij je klanten. Immers zien ze het steeds terug komen.

Een beetje hetzelfde als je zelf een nieuwe auto aan het zoeken bent, bij de dealer geweest ben en wel een zwak voor model X (niet tesla..) hebt gekregen. Vervolgens zal je de komende weken opvallen dat je die auto veel vaker ziet ;)

  • .oisyn
  • Registratie: september 2000
  • Laatst online: 16:44

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

Douweegbertje schreef op vrijdag 11 januari 2019 @ 13:19:
Een beetje hetzelfde als je zelf een nieuwe auto aan het zoeken bent, bij de dealer geweest ben en wel een zwak voor model X (niet tesla..) hebt gekregen. Vervolgens zal je de komende weken opvallen dat je die auto veel vaker ziet ;)
Wow, en dat allemaal door het algoritme van Amazon :o

If we can hit that bullseye, the rest of the dominoes will fall like a house of cards. Checkmate.


  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 12-01 22:39
Douweegbertje schreef op vrijdag 11 januari 2019 @ 13:19:
[...]


Remarketing. Afhankelijk van de use-case (type product, webshop, etc) kan dit veel meer opleveren dan alleen richten op nieuwe leads. Zeker voor producten die je eigenlijk niet zomaar komt. Denk hierbij aan de wat duurdere producten.
Daarnaast is het continue promoten van een merk een manier om een bepaald bewustheid te creëren bij je klanten. Immers zien ze het steeds terug komen.

Een beetje hetzelfde als je zelf een nieuwe auto aan het zoeken bent, bij de dealer geweest ben en wel een zwak voor model X (niet tesla..) hebt gekregen. Vervolgens zal je de komende weken opvallen dat je die auto veel vaker ziet ;)
Veel advertenties werken gewoon ruk. Ik heb toevallig een tijd geleden online een nieuwe winterjas gekocht. Ik had niet via google gezocht, maar direct bij die webwinkel waar ik vaker koop een nieuwe jas gekocht. Vervolgens krijg ik 3 maanden lang op zo'n beetje iedere website die Google AdSense gebruikt advertenties tegen van willekeurige webshops of ik daar een winterjas wil kopen. En dat wil ik niet, want dat heb ik al gedaan.

In feiten worden er dus gewoon twee partijen belazerd. Ik als consument omdat ik wordt dood gegooit met advertenties waar ik niets (meer) aan heb, en de webwinkels omdat ze die views moeten betalen terwijl de kans dat ik er op klik en daar iets koop heel erg klein is.

  • Douweegbertje
  • Registratie: mei 2008
  • Laatst online: 13:59

Douweegbertje

Wat kinderachtig.. godverdomme

ThomasG schreef op vrijdag 11 januari 2019 @ 13:59:
[...]
Veel advertenties werken gewoon ruk. Ik heb toevallig een tijd geleden online een nieuwe winterjas gekocht. Ik had niet via google gezocht, maar direct bij die webwinkel waar ik vaker koop een nieuwe jas gekocht. Vervolgens krijg ik 3 maanden lang op zo'n beetje iedere website die Google AdSense gebruikt advertenties tegen van willekeurige webshops of ik daar een winterjas wil kopen. En dat wil ik niet, want dat heb ik al gedaan.

In feiten worden er dus gewoon twee partijen belazerd. Ik als consument omdat ik wordt dood gegooit met advertenties waar ik niets (meer) aan heb, en de webwinkels omdat ze die views moeten betalen terwijl de kans dat ik er op klik en daar iets koop heel erg klein is.
De advertenties zien kost vrijwel niets. Daarmee is het ook één wat goedkopere vorm van adverteren soms ;)
Daarnaast.. hoe vervelend het ook is; jij vergeet dat bedrijf nu niet meer. Negatieve "reclame" werkt soms ook beter dan positieve.

Als je er echt meer van wilt weten kan je beter eens met een marketing expert (een echte..vele denken dat ze het zijn) praten. Ik pak gelukkig soms her en der wat op aangezien we een digital agency zijn met een marketing zuster bedrijf erbij ^^

  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 12-01 22:39
Douweegbertje schreef op vrijdag 11 januari 2019 @ 14:20:
[...]


De advertenties zien kost vrijwel niets. Daarmee is het ook één wat goedkopere vorm van adverteren soms ;)
Daarnaast.. hoe vervelend het ook is; jij vergeet dat bedrijf nu niet meer. Negatieve "reclame" werkt soms ook beter dan positieve.

Als je er echt meer van wilt weten kan je beter eens met een marketing expert (een echte..vele denken dat ze het zijn) praten. Ik pak gelukkig soms her en der wat op aangezien we een digital agency zijn met een marketing zuster bedrijf erbij ^^
Dat is dus niet zo. Ik heb werkelijke geen idee welke winkels mij het probeerde aan te smeren. Het waren ook nog eens jassen van een compleet ander "type" dan waar ik in geïntresseerd was en ook gekocht heb. Het enige wat die advertenties bereikt hebben is dat als ik door een artikel op een webpagina scrollde er links of rechts een afbeelding van een jas voorbij kwam. Het zijn dus gewoon nutteloze advertenties geweest waar ze onnodig voor hebben betaald.

  • Alex)
  • Registratie: juni 2003
  • Laatst online: 18:14
Een paar jaar geleden ben ik op citytrip naar Stockholm geweest. Vanaf Arlanda is er een snelle trein naar het centrum, de Arlanda Express. Maanden na m'n citytrip kreeg ik nog elke dag advertenties te zien voor Arlanda Express. 8)7

We are shaping the future


  • Mugwump
  • Registratie: mei 2017
  • Nu online
Ik heb ook regelmatig dat Google m'n zoekopdracht ongevraagd corrigeert en dat ik vervolgens drie maanden reclame krijg voor de gecorrigeerde zoekterm. :')

  • BladeSlayer1000
  • Registratie: april 2013
  • Laatst online: 19:30
Even een random rant over de website van NPO start, wat een irritante website..
Mooi dat je jouw categorieën horizontaal scrol baar maakt met de scrol wiel op de muis, maar zorg er dan ook voor als mensen naar beneden willen scrollen dat er genoeg ruimte zit tussen je categorieën ...

  • Sandor_Clegane
  • Registratie: januari 2012
  • Laatst online: 16-01 10:03

Sandor_Clegane

Fancy plans and pants to match

Alex) schreef op vrijdag 11 januari 2019 @ 18:41:
Een paar jaar geleden ben ik op citytrip naar Stockholm geweest. Vanaf Arlanda is er een snelle trein naar het centrum, de Arlanda Express. Maanden na m'n citytrip kreeg ik nog elke dag advertenties te zien voor Arlanda Express. 8)7
Misschien wilde je nog een keertje? ;)

  • Firesphere
  • Registratie: september 2010
  • Laatst online: 01:36

Firesphere

Yoshis before Hoshis

Marketing is redelijk complex als het aankomt op targeting.

Ook een reden dat ik m'n vliegtickets altijd in incognito mode bestel. En bij voorkeur met een valse browserstring en via VPN. Anders zie je vaak dat de prijzen omhoog gaan gebaseerd op het aantal keer dat je de site hebt bezocht.

Als de marketing werkt, kun je een hoop geld verdienen met targeting :)

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!


  • Douweegbertje
  • Registratie: mei 2008
  • Laatst online: 13:59

Douweegbertje

Wat kinderachtig.. godverdomme

ThomasG schreef op vrijdag 11 januari 2019 @ 16:24:
[...]
Dat is dus niet zo. Ik heb werkelijke geen idee welke winkels mij het probeerde aan te smeren. Het waren ook nog eens jassen van een compleet ander "type" dan waar ik in geïntresseerd was en ook gekocht heb. Het enige wat die advertenties bereikt hebben is dat als ik door een artikel op een webpagina scrollde er links of rechts een afbeelding van een jas voorbij kwam. Het zijn dus gewoon nutteloze advertenties geweest waar ze onnodig voor hebben betaald.
eh ja maar je vergeet misschien dat jij als persoon niet leidend bent voor de uitkomst van een advertentie? Dus ja.. geld "verpest" voor jou, maar wellicht is het voor die andere ~3% wel relevant en dan is het gewoon prima.

Uiteindelijk gaat het domweg over een simpele rekensom. Het conversie percentage met de daarbij behorende winst vs de kosten. Trust me.. als die niet okay is dan stoppen ze heus wel zulke campagnes.

Natuurlijk wil je je campagnes optimaliseren maar dat is niet per persoon te doen. Wat je niet moet vergeten is dat *views* echt heel cheap zijn. Het zijn de clicks die pas goed geld kosten.

Derhalve als je een ad vervelend vindt: klik er op. Misschien heeft ze dat wel 2-10 euro gekost :+

  • kenneth
  • Registratie: september 2001
  • Niet online

kenneth

achter de duinen

Prima uitleg, @Douweegbertje.

Altijd fascinerend om te zien hoe mensen die niet in het vak zitten zeker weten dat mensen die wel in het vak zitten er niets van begrepen hebben. "Targeted ads zijn geldverspilling omdat ik een zinloze ad zag!!1". Right. Marketeers doen maar wat en hebben nooit van metrics gehoord.

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 12-01 22:39
kenneth schreef op zaterdag 12 januari 2019 @ 14:28:
Prima uitleg, @Douweegbertje.

Altijd fascinerend om te zien hoe mensen die niet in het vak zitten zeker weten dat mensen die wel in het vak zitten er niets van begrepen hebben. "Targeted ads zijn geldverspilling omdat ik een zinloze ad zag!!1". Right. Marketeers doen maar wat en hebben nooit van metrics gehoord.
Voor sommige producten heb je gelijk, voor andere juist niet. Als het nu om een pot pindakaas ging kon ik het nog wel begrijpen. Maar als het gaat om iets wat je eens in de paar jaar koopt, dan schieten de advertenties hun doel compleet voorbij als je het pas te zien krijgt nadat je al een soortgelijk product gekocht hebt. Want het is niet alsof ik mijn auto ga inruilen omdat ik 2 weken nadat ik hem gekocht heb een advertentie van een andere auto zie.

Aan de andere kant hebben zulke advertenties wel effect. Want je wordt er zo schijt ziek van dat je die producten juist niet gaat kopen. En is dus ook een van de redenen waarom mensen ad blockers gebruiken: irritante advertenties, en ads waar je helemaal niets aan hebt.

ThomasG wijzigde deze reactie 12-01-2019 14:49 (13%)


  • kenneth
  • Registratie: september 2001
  • Niet online

kenneth

achter de duinen

Als de conversie omhoog gaat door iets doms te doen, is het dan nog dom?

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


  • Marc3l
  • Registratie: december 2005
  • Laatst online: 20:42
ThomasG schreef op zaterdag 12 januari 2019 @ 14:41:
[...]
Voor sommige producten heb je gelijk, voor andere juist niet. Als het nu om een pot pindakaas ging kon ik het nog wel begrijpen. Maar als het gaat om iets wat je eens in de paar jaar koopt, dan schieten de advertenties hun doel compleet voorbij als je het pas te zien krijgt nadat je al een soortgelijk product gekocht hebt. Want het is niet alsof ik mijn auto ga inruilen omdat ik 2 weken nadat ik hem gekocht heb een advertentie van een andere auto zie.

Aan de andere kant hebben zulke advertenties wel effect. Want je wordt er zo schijt ziek van dat je die producten juist niet gaat kopen. En is dus ook een van de redenen waarom mensen ad blockers gebruiken: irritante advertenties, en ads waar je helemaal niets aan hebt.
Natuurlijk werk het anders bestonden ze niet. Dat het niet voor jou werkt wil nog niet zeggen dat ze geen conversie opleveren.

Hetzelfde als popups, iedereen heeft er een hekel aan maar ze converteren wel.

  • Voutloos
  • Registratie: januari 2002
  • Niet online
Zo'n beetje iedereen beweert dat ze niet worden beïnvloed door advertenties. Het kan niet anders of vrij veel mensen schatten dat zelf verkeerd in. :P

Talkin.nl daily photoblog


  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 12-01 22:39
Voutloos schreef op zaterdag 12 januari 2019 @ 20:33:
Zo'n beetje iedereen beweert dat ze niet worden beïnvloed door advertenties. Het kan niet anders of vrij veel mensen schatten dat zelf verkeerd in. :P
Maar daar gaat het dus helemaal niet om. Als ik geregeld een advertentie zie over een pot pindakaas, wordt ik daar inderdaad (onbewust) door beinvloed. En mensen gemiddeld om de paar weken een nieuwe pot pindakaas kopen is de kans groot dat ik de volgende keer het merk van de reclame neem. Dus ja, reclame werkt.

Het probleem is echter dat ze wel tracken waar je naar gekeken hebt, maar niet tracken wat je ook gekocht hebt. Stel je gaat nu naar een webwinkel en zoekt naar computer muizen is de kans groot dat je reclame gaat krijgen van computer muizen. Als je dan echter een keuze maakt, en vervolgens een computer muis koopt, dan blijf je nog weken lang reclame zien voor computer muizen. Is de kans groot dat je weer een muis gaat kopen? Is er een grote kans dat je de muis gaat omruilen? Ze kunnen dan beter reclame laten zien voor willekeurige andere producten dan iets wat je al gekocht hebt en een lange levensduur heeft, want dan is er een grotere kans dat ik daar iets mee doe.

  • Douweegbertje
  • Registratie: mei 2008
  • Laatst online: 13:59

Douweegbertje

Wat kinderachtig.. godverdomme

ThomasG schreef op zaterdag 12 januari 2019 @ 20:52:
[...]
Maar daar gaat het dus helemaal niet om. Als ik geregeld een advertentie zie over een pot pindakaas, wordt ik daar inderdaad (onbewust) door beinvloed. En mensen gemiddeld om de paar weken een nieuwe pot pindakaas kopen is de kans groot dat ik de volgende keer het merk van de reclame neem. Dus ja, reclame werkt.

Het probleem is echter dat ze wel tracken waar je naar gekeken hebt, maar niet tracken wat je ook gekocht hebt. Stel je gaat nu naar een webwinkel en zoekt naar computer muizen is de kans groot dat je reclame gaat krijgen van computer muizen. Als je dan echter een keuze maakt, en vervolgens een computer muis koopt, dan blijf je nog weken lang reclame zien voor computer muizen. Is de kans groot dat je weer een muis gaat kopen? Is er een grote kans dat je de muis gaat omruilen? Ze kunnen dan beter reclame laten zien voor willekeurige andere producten dan iets wat je al gekocht hebt en een lange levensduur heeft, want dan is er een grotere kans dat ik daar iets mee doe.
Het is vaak een combinatie:

- Bedrijf heeft er weinig/geen verstand van hoe een campagne goed in elkaar gezet moet worden
- Zoals ik eerder al zei: De kosten voor de views is echt nihil op de andere kosten. M.a.w. qua centjes maakt het eigenlijk niet uit waardoor de noodzaak soms ook totaal niet aanwezig is.
- Daarop volgend; soms is het ook nog bewust. Je hebt het gekocht maar je blijft advertenties zien. Dat kan een strategie zijn

Dan spelen er soms ook dingen daarnaast; misschien heb je op diverse devices gezeten waardoor de sale niet helemaal gekoppeld is aan de ads. Wellicht heb je toch onbewust (of bewust) op product gerelateerde website gezeten waardoor dit eigenlijk een nieuwe trigger is.

"Het probleem" is helaas alleen jouw probleem. Misschien heel cru maar *insert company here* geeft er niet veel om als 0.01% klaar is met zn ads als ze een dikke conversie draaien. Ik heb het zelf meegemaakt bij een relatief goedlopend bedrijfje (5-6 man). Die gooide er wel 10.000 per dag (!) er tegenaan. Het is gewoon een investering die je mits de juiste kennis direct kan omzetten in meer omzet. In bovenstaande geval was elke euro er 10 waard (dus 1 ton per dag omzetten...)

M.a.w. je betaald voor je klant (lead). Als je weet dat je conversie op 2% zit en gemiddeld X winst (niet omzet) geeft, dan weet je ook wat je kan betalen voor je klant om je winst te vergroten. Dit kan ook allemaal automatisch met biedingen op de juiste ads, tijdzones, etc etc.

Op het moment dat het echt lekker gaat kan je hier best in los gaan. Zeker als je ROAS (Return on Ad Spend ) c.q. ROI gewoon enorm goed is; ga je zeker niet op micro-niveau optimaliseren.

Dus zodra je beseft dat een bedrijf 1 euro betaald om 10 euro winst te maken, realiseer je ook dat het een bizare wereld kan zijn en dat heel veel andere dingen dan niet meer uitmaken :+

  • Crazy D
  • Registratie: augustus 2000
  • Laatst online: 15:50

Crazy D

I think we should take a look.

ThomasG schreef op zaterdag 12 januari 2019 @ 20:52:
Als je dan echter een keuze maakt, en vervolgens een computer muis koopt, dan blijf je nog weken lang reclame zien voor computer muizen. Is de kans groot dat je weer een muis gaat kopen? Is er een grote kans dat je de muis gaat omruilen? Ze kunnen dan beter reclame laten zien voor willekeurige andere producten dan iets wat je al gekocht hebt en een lange levensduur heeft, want dan is er een grotere kans dat ik daar iets mee doe.
Maar wil jij dat Google weet dat je een muis hebt gekocht? Ik vind t toch wel fijn dat reclameboeren niet mijn winkelwagen kunnen zien bij afrekenen...

Exact expert nodig? itwize.nl


  • AW_Bos
  • Registratie: april 2002
  • Laatst online: 19:32

AW_Bos

Sjoema flop 🧙‍♂️

Vanmiddag de laatste hand leggen aan het rechten-systeem in mijn CMS.
Het is een beetje afgekeken naar hoe (My)React vroeger werkte (toen je het nog kon downloaden), en gebruikt dus rechtengroepen waaraan je 'rules' hangt die verdeeld zijn in C-R-U-D-P rechten (ook publiceren valt eronder, aanmaken wil niet zeggen dat het meteen online staat) :)

Enkel nog even de webinterface afmaken om de groepen en rechten in te stellen en te INSERTEN/UPDATE'en.

Maar weet iemand nog hoe het overervingssysteem in de theorie werkte bij (My)React? :P
Die werkte ook op diverse manieren, herinner ik me.

AW_Bos wijzigde deze reactie 13-01-2019 12:49 (12%)

...


  • azerty
  • Registratie: maart 2009
  • Laatst online: 19:18

azerty

McFly

AW_Bos schreef op zondag 13 januari 2019 @ 12:48:
Vanmiddag de laatste hand leggen aan het rechten-systeem in mijn CMS.
Het is een beetje afgekeken naar hoe (My)React vroeger werkte (toen je het nog kon downloaden), en gebruikt dus rechtengroepen waaraan je 'rules' hangt die verdeeld zijn in C-R-U-D-P rechten (ook publiceren valt eronder, aanmaken wil niet zeggen dat het meteen online staat) :)

Enkel nog even de webinterface afmaken om de groepen en rechten in te stellen en te INSERTEN/UPDATE'en.

Maar weet iemand nog hoe het overervingssysteem in de theorie werkte bij (My)React? :P
Die werkte ook op diverse manieren, herinner ik me.
Vraag het anders eventjes in het topic in het Abo forum waar je vragen kunt stellen over de zaken achter de schermen van Tweakers, misschien krijg je daar een antwoord :)
Pagina: 1 ... 14 15 16 Laatste


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank, Intermediair en Independer de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True