De Devschuur Coffee Corner - Iteratie 7

[Dido]

Tegen dat ik in de buurt van een pesnioengerechtigde leeftijd ga komen verwacht ik dat de meeste babyboomers gedaan hebben wat van ze verwacht wordt. Dan zou er opeens weer een hoop ademruimte moeten zijn in de gebieden waar zij nu en de komende jaren alle rek eruit halen: pensioenen en zorg.

[TheNephilim]

Een XML bestand van net geen 100 MB parsen, heerlijk op 'gewone' hosting...

[Firesphere]

TheNephilim schreef op maandag 01 september 2014 @ 15:50:
Een XML bestand van net geen 100 MB parsen, heerlijk op 'gewone' hosting...

Hoezo moet dat op een hosting? Kun je niet lokaal parsen en dan het resultaat uploaden?

[TheNephilim]

Firesphere schreef op maandag 01 september 2014 @ 15:56:
[...]

Hoezo moet dat op een hosting? Kun je niet lokaal parsen en dan het resultaat uploaden?

Nee, elke dag moet er automatisch een XML bestand gedownload worden (dat werkt) en dan het bestand inlezen in de database (dat werkt dus niet).

[ Voor 3% gewijzigd door TheNephilim op 01-09-2014 16:01 ]

[Firesphere]

TheNephilim schreef op maandag 01 september 2014 @ 16:01:
[...]


Nee, elke dag moet er automatisch een XML bestand gedownload worden (dat werkt) en dan het bestand inlezen in de database (dat werkt dus niet).

Hmmmm, je zou denken dat een xml inlezen niet zo heftig is, toch? Tenminste, ik heb meerdere SOAP koppelingen en XML-alike koppelingen draaien op een shared hosting, zonder problemen.

[TheNephilim]

Firesphere schreef op maandag 01 september 2014 @ 16:06:
[...]

Hmmmm, je zou denken dat een xml inlezen niet zo heftig is, toch? Tenminste, ik heb meerdere SOAP koppelingen en XML-alike koppelingen draaien op een shared hosting, zonder problemen.

Het zou niet zo'n probleem zijn als het XML bestand schoon was... maarja Zie een voorbeeld record hieronder...

SimpleXMLElement Object ( [isbn] => *201281147* [auteur] => Chunk Serie/HangUp [titel] => HangUp Navigation holder [...] )

Alleen al filteren op geldig ISBN en nog op zoveel andere bullshit, dat is vooral het probleem . Ik heb netjes (denk ik) een XML reader met callback, dus een bestand zo groot zou ook geen probleem mogen zijn.

Laten we het erop houden dat een nette feed een heleboel zou helpen

[_Moe_]

TheNephilim schreef op maandag 01 september 2014 @ 16:01:
[...]


Nee, elke dag moet er automatisch een XML bestand gedownload worden (dat werkt) en dan het bestand inlezen in de database (dat werkt dus niet).

Kan deze dan niet verkapt worden in kleinere delen? Bij een vorig bedrijf waar ik werkte, kregen we bijvoorbeeld per subcategorie van producten een xml.

[TheNephilim]

_Moe_ schreef op maandag 01 september 2014 @ 16:13:
[...]


Kan deze dan niet verkapt worden in kleinere delen? Bij een vorig bedrijf waar ik werkte, kregen we bijvoorbeeld per subcategorie van producten een xml.

De enige optie die ik had, was het downloaden van een SQL bestand. Daar ben ik alleen niet zo happig op!

[Firesphere]

TheNephilim schreef op maandag 01 september 2014 @ 16:15:
[...]


De enige optie die ik had, was het downloaden van een SQL bestand. Daar ben ik alleen niet zo happig op!

Hoezo niet? SQL is veel snellere oplossing gok ik.

En anders, zou ik de XML inlezen en in je database gooien, en pas daarna je filters en controles gaan toepassen.

[F.West98]

@error:
Eerste keer deploy naar een IIS server, ik faalde

Maar ik ga er nu aan werken

[Gamebuster]

Zojuist de HTML, HEAD en BODY tags verwijderd uit mijn views van de website. Waarom? Ze zijn optioneel volgens de HTML5 spec. Ook vele andere elementen hebben optionele start- of eindtags: Ik heb bijv. hier en daar wat </option> sluittags weggehaald.

Het gevolg: De homepage HTML is nu 4% bytes korter (van 3716 naar 3596 bytes)

Heb ook plannen voor om classnames en IDs te comprimeren, net zoals JS minifiers variable namen kleiner maakt. Alleen de HTML kan ik met compacte classnames al 21% (748 bytes) kleiner maken, dan heb ik de IDs nog niet meegerekend. De besparing in de JS en CSS files zal immens zijn, gezien de mijn classnames vrij lang zijn en veel gebruikt worden.

Minification van classnames wil ik realiseren door een soort globale lijst aan classnames te generen en die te converteren naar a-Z, aa-ZZ, enz. Dit wil ik automatiseren en ik denk dat ik dat wel kan realiseren zonder al te veel complicaties.

Bytes besparen in de website is een leuke hobby van me. Bijkomend voordeel: Je website wordt er lekker snel van. Ik heb eerder onze custom fonts gestript van bijzondere tekens, waarbij in sommige gevallen meer dan 200kb werd bespaard.

[TheNephilim]

Firesphere schreef op maandag 01 september 2014 @ 16:18:
[...]

Hoezo niet? SQL is veel snellere oplossing gok ik.

En anders, zou ik de XML inlezen en in je database gooien, en pas daarna je filters en controles gaan toepassen.

Dat is inderdaad sneller, misschien een alternatief. Het inserten van alle 235.000+ records is namelijk niet heel snel. Helaas het filteren zodat ik de benodigde 7000~9000 overhoud ook niet

En het project heeft al een jaar stilgestaan omdat er één van de partijen ermee stopte. Nu er een vervanger gevonden is, moet het laatste nog even gefixed worden.

Edit: na het inserten van 66.033 records kapt hij ermee. Looptijd van php overschreden denk ik. Nouja... dan wat anders bedenken dus.

[ Voor 10% gewijzigd door TheNephilim op 01-09-2014 16:45 ]

[Verwijderd]

PHP heeft daar een stuk over geschreven op hun site daar zijn een aantal oplossingen voor.......

[Firesphere]

TheNephilim schreef op maandag 01 september 2014 @ 16:45:
[...]


Dat is inderdaad sneller, misschien een alternatief. Het inserten van alle 235.000+ records is namelijk niet heel snel. Helaas het filteren zodat ik de benodigde 7000~9000 overhoud ook niet

En het project heeft al een jaar stilgestaan omdat er één van de partijen ermee stopte. Nu er een vervanger gevonden is, moet het laatste nog even gefixed worden.

Edit: na het inserten van 66.033 records kapt hij ermee. Looptijd van php overschreden denk ik. Nouja... dan wat anders bedenken dus.

inloggen en sql command gebruiken, of bigdump gebruiken.

[WernerL]

PHP vanaf de command line draaien? Op die manier ooit 250.000 records in een database geknalt, ging prima. De timeout van PHP geldt afaik enkel wanneer je het script vanuit de browser start.

[ Voor 27% gewijzigd door WernerL op 01-09-2014 17:06 ]

[ThomasG]

WernerL schreef op maandag 01 september 2014 @ 17:05:
PHP vanaf de command line draaien? Op die manier ooit 250.000 records in een database geknalt, ging prima. De timeout van PHP geldt afaik enkel wanneer je het script vanuit de browser start.

Dat ligt aan je instellingen. Sommige Linux distributies doen dat automatisch, andere niet. En je kunt anders altijd nog set_time_limit (0); gebruiken.

[ Voor 3% gewijzigd door ThomasG op 01-09-2014 17:10 ]

[Firesphere]

WernerL schreef op maandag 01 september 2014 @ 17:05:
PHP vanaf de command line draaien? Op die manier ooit 250.000 records in een database geknalt, ging prima. De timeout van PHP geldt afaik enkel wanneer je het script vanuit de browser start.

Waarom de overhead van php daar bij gebruiken?
mysql -u {username} -p{PASSWORD} {databasename} < {sqldumpfile.sql}
(Hij kan een SQL-bestand krijgen, remember )

[ Voor 5% gewijzigd door Firesphere op 01-09-2014 17:11 ]

[Douweegbertje]

TheNephilim schreef op maandag 01 september 2014 @ 16:45:
[...]


Dat is inderdaad sneller, misschien een alternatief. Het inserten van alle 235.000+ records is namelijk niet heel snel. Helaas het filteren zodat ik de benodigde 7000~9000 overhoud ook niet

En het project heeft al een jaar stilgestaan omdat er één van de partijen ermee stopte. Nu er een vervanger gevonden is, moet het laatste nog even gefixed worden.

Edit: na het inserten van 66.033 records kapt hij ermee. Looptijd van php overschreden denk ik. Nouja... dan wat anders bedenken dus.

Ik heb zonder problemen 200k records geinsert. Niet zo bijster bijzonder. Je kan dit op verschillende manieren doen.. Gewoon 1 voor 1 wat redelijk traag is of een insert into blaat (x, y) values (x, y), (x,y),(x, etc..

Looptijd van PHP kun je ook uitzetten, en meestal draai je dit soort dingen juist via de CLI ipv een webpagina.

[RayNbow]

Gamebuster schreef op maandag 01 september 2014 @ 16:41:
Minification van classnames wil ik realiseren door een soort globale lijst aan classnames te generen en die te converteren naar a-Z, aa-ZZ, enz. Dit wil ik automatiseren en ik denk dat ik dat wel kan realiseren zonder al te veel complicaties.

Fijn als iemand de site wil scrapen.

[kaesve]

Gamebuster schreef op maandag 01 september 2014 @ 16:41:

Heb ook plannen voor om classnames en IDs te comprimeren, net zoals JS minifiers variable namen kleiner maakt. Alleen de HTML kan ik met compacte classnames al 21% (748 bytes) kleiner maken, dan heb ik de IDs nog niet meegerekend. De besparing in de JS en CSS files zal immens zijn, gezien de mijn classnames vrij lang zijn en veel gebruikt worden.

Minification van classnames wil ik realiseren door een soort globale lijst aan classnames te generen en die te converteren naar a-Z, aa-ZZ, enz. Dit wil ik automatiseren en ik denk dat ik dat wel kan realiseren zonder al te veel complicaties.

maar gzippen doet dat min of meer al voor jou. als je dat gebruikt zou ik ook kijken naar de winst in bytes na compressie. ik verwacht dat dat niet zo veel is.

[deadinspace]

.oisyn schreef op maandag 01 september 2014 @ 01:50:
Ik ook niet, maar ik hoopte je makkelijk af te schepen .

Mislukt

Het feit dat ik die trailing komma daar accepteer in die specifieke case waar het in mijn geval over gaat heeft niets met dat principe te maken, maar met het feit dat dat gewoon heel erg pragmatisch is en ik mijn kapitaal er wel op in durf te zetten dat dat nooit een groot probleem gaat vormen.

Naja, inmiddels is ook wel duidelijk dat het om opslag van configuratie gaat voor iets interns, niet voor data-exchange, dan is het minder erg.

Daar kwam die massale knee-jerk reaction ook vandaan denk ik; je had het zonder verdere context over een json-parser die niet-standaard json accepteerde, en dan denken veel mensen blijkbaar aan data-exchange, zien een potentieel probleem en plaatsen daar vraagtekens bij. Op zich wel goed, hebben we met zijn allen blijkbaar dus wel geleerd van het verleden

[incaz]

TheNephilim schreef op maandag 01 september 2014 @ 16:11:

Het zou niet zo'n probleem zijn als het XML bestand schoon was... maarja

Dat was een snelle iteratie! Dank voor een treffende illustratie waarom zut een probleem is

Gamebuster schreef op maandag 01 september 2014 @ 16:41:
Bytes besparen in de website is een leuke hobby van me. Bijkomend voordeel: Je website wordt er lekker snel van. Ik heb eerder onze custom fonts gestript van bijzondere tekens, waarbij in sommige gevallen meer dan 200kb werd bespaard.

Bytebesparing op websites lijkt mij grotendeels zinloos om snelheidswinst te halen, ik geloof eigenlijk niet dat het echt uitmaakt. (In alle profiling die ik heb bekeken waren de grootverbruikers de requests, de scripts en de rendering. En die blijven allemaal hetzelfde.)
200kb aan ongebruikte fonts weghalen is natuurlijk wel zinnig. Maar geminifiede classnames? (En inderdaad, gzip)

[Alex)]

RayNbow schreef op maandag 01 september 2014 @ 17:21:
[...]

Fijn als iemand de site wil scrapen.

Waarom zou je daar überhaupt rekening mee houden?

[TheNephilim]

incaz schreef op maandag 01 september 2014 @ 17:29:
[...]

Dat was een snelle iteratie! Dank voor een treffende illustratie waarom zut een probleem is

Wat wil je daarmee zeggen?

---

Anyway, er zijn inderdaad talloze manieren om dit op te lossen, maar ik heb niet alle mogelijkheden. Op dit moment heb ik het opgelost door het bestand op te splitsen in meerdere kleine bestanden.

[incaz]

Alex) schreef op maandag 01 september 2014 @ 17:30:

Wat wil je daarmee zeggen?

Dat het bouwen van goede feeds en goede bestanden veel tijdswinst oplevert, en dat jij een stuk minder problemen had gehad als men aan de andere kant meer aandacht had besteed aan een goede opbouw. Maar ik begrijp nu bij teruglezen dat het om niet-schone data gaat, niet om niet-schone syntax?

[Ealanrian]

Vandaag het eerste dagje pre-masters gehad aan Utwente. Damm wat gaat dat snel maar wat is het uitdagend en dus leuk om te doen. Word wel duidelijk hard werken en helaas minder proggen

[TheNephilim]

incaz schreef op maandag 01 september 2014 @ 17:35:
[...]


Dat het bouwen van goede feeds en goede bestanden veel tijdswinst oplevert, en dat jij een stuk minder problemen had gehad als men aan de andere kant meer aandacht had besteed aan een goede opbouw. Maar ik begrijp nu bij teruglezen dat het om niet-schone data gaat, niet om niet-schone syntax?

Hoe doe je zo quoten?

De syntax is niet geweldig, maar kan ik niks van zeggen. Echter is de data in de velden niet consistent, kan ik vooraf niet filteren (op categorie of leverancier bijv.) en zit er enorm veel rotzooi in. Dingen die er (volgens mij) niet in horen te staan.

<product><isbn>??</isbn> [...] is niet echt handig bijvoorbeeld

[alienfruit]

[b][message=42814980,noline]RayNbow schreef op maandag 01 september 2014 @ Fijn als iemand de site wil scrapen.

Lekker belangrijk... daar ga je als site toch geen rekening mee houden?

[RayNbow]

Alex) schreef op maandag 01 september 2014 @ 17:30:
Waarom zou je daar überhaupt rekening mee houden?

alienfruit schreef op maandag 01 september 2014 @ 17:40:
Lekker belangrijk... daar ga je als site toch geen rekening mee houden?

http://www.w3.org/QA/Tips/goodclassnames ?

[_trickster_]

[b]RayNbow schreef op maandag 01 september 2014 @ 17:57:
http://www.w3.org/QA/Tips/goodclassnames ?

Ik vind er nog wel een groot verschil in zitten om de code leesbaar te maken voor de Developers ( duidelijke Class namen )

Of de source goed leesbaar de houden voor de eindgebruiker / Scrapper, die ten slotte de Source niet hoeven te lezen / te begrijpen, die hebben alleen boodschap aan de gerenderde site.

[incaz]

Hmmm, het zou wel leuk zijn als de overheid het zou doen, rekening houden met scrapers, als ze geen zin hebben hun informatie behoorlijk te ontsluiten.

[TheNephilim]

Damn ik ben wat aan het compilen op een VPS'je, wat duurt dat allemachtig lang

[Swedish Clown]

Heerlijk, iedereen is kantoor uit en even met snoeiharde muziek code refactoren. Heerlijk ook dat de beveiliging hier zojuist half dansend over de vloer loopt.

[RayNbow]

incaz schreef op maandag 01 september 2014 @ 18:08:
Hmmm, het zou wel leuk zijn als de overheid het zou doen, rekening houden met scrapers, als ze geen zin hebben hun informatie behoorlijk te ontsluiten.

Het zou ook mooi zijn als YouTube het ook zou doen... De oude site was een stuk simpeler om te crawlen.

[Douweegbertje]

RayNbow schreef op maandag 01 september 2014 @ 17:57:
[...]


[...]


http://www.w3.org/QA/Tips/goodclassnames ?

Heb je het zelf ook gelezen?
In zijn voorbeeld minify je uiteindelijk het bestand, dmv 'andere' class names. w3 heeft het over duidelijkheid, als in een codestandaard. Wereld van verschil.

Je hebt toch ook gewoon minified js & css? Dat kun je toch ook amper lezen... Nou, en hiermee heb je al een stukje minified HTML.

[Gamebuster]

RayNbow schreef op maandag 01 september 2014 @ 17:21:
[...]

Fijn als iemand de site wil scrapen.

Als ze willen scrapen, kijken ze 5 seconden naar de broncode en zien ze dat alle data via een JSON API wordt opgehaald en spreken ze dat API direct aan. Natuurlijk is dat niet de bedoeling...

[Gamebuster]

incaz schreef op maandag 01 september 2014 @ 17:29:
Bytebesparing op websites lijkt mij grotendeels zinloos om snelheidswinst te halen, ik geloof eigenlijk niet dat het echt uitmaakt. (In alle profiling die ik heb bekeken waren de grootverbruikers de requests, de scripts en de rendering. En die blijven allemaal hetzelfde.)
200kb aan ongebruikte fonts weghalen is natuurlijk wel zinnig. Maar geminifiede classnames? (En inderdaad, gzip)

Mijn CSS file is 25537 bytes, minified in productie.

Deze bevat 205 keer een classname, bestaande uit 94 unieke classnames.

De 52 meest voorkomende classnames kan ik verkleinen tot 1 teken: reeks a-z en A-Z. De rest tot 2 tekens; aa tot zz.

Alle classnames bij elkaar zorgen voor 5656 bytes in mijn CSS file: Gemiddeld 27 tekens per classname (ik hou van lange namen)

Na verkleinen van de classnames naar ruwweg gemiddeld 1,5 teken per classname zullen de classnames achteraf maar 308 bytes innemen. Tegenover 5656 is dit een besparing van 5348 bytes in de CSS, naast de 748 bytes die ik ongeveer kan besparen in de HTML. (heb ik eerder uitgerekend)

Voor mijn CSS is dit een besparing van 21% over al minified CSS.

Hoeveel het verschil is na gzip weet ik inderdaad niet, maar sinds wanneer is "gzip" het argument om maar niet aan compressie/minification te doen? Jij minified toch ook je CSS/JS voordat je het gzip't?

Ook in mijn Javascript heb ik veel classnames. Ook hier kan ik ze comprimeren d.m.v. een preprocessor. Hier moet ik echter nog een oplossing voor bedenken. Mijn JS gaat al door een pre-processor heen om 'm te minifien en te builden tot een productie versie, hier kan ik wel een extra hook in zetten. Misschien dat ik een soort "macro" toevoeg voor classnames. Voorbeelden:

JavaScript:

// alles tussen backticks een classname ("smerige" hack)
element.classList.add("`lange-classname`");

// alle classnames met hun "gecomprimeerde versie" worden in een hash gezet
// - of, voor productie -
// een search-and-replace naar CLASSNAMES[...]
element.classList.add(CLASSNAMES["lange-classname"]);

[ Voor 19% gewijzigd door Gamebuster op 01-09-2014 19:23 ]

[Douweegbertje]

Imo, met bijv. 100k bezoekers per dag scheelt elke byte.
Hoewel zoveel bezoekers met een winst van 10 bytes maar ~ 1mb oplevert kan het wel snel aan tikken.

Het is niet alleen voordelig voor de client, maar ook voor je server. Ik had één dag een dikke piek van bezoekers (20k bezoekers in ~ 5 uur) op een website die niet helemaal netjes in elkaar zat. Dit resulteerde in een enorm data verbruik.

Goed, tegenwoordig is het niet meer zo lastig om een goede server voor weinig geld te hebben, en dataverkeer kost ook geen goud meer.. toch zie ik wel voordelen om je spul netjes te optimaliseren. Echter voor elke 'basic / standaard' website is het misschien een zware overkill.

Wel leuk hobby projectje oid om lekker aan te sleutelen. Ik hou ook wel van stats en tot het gaatje gaan qua optimalisatie

[RobIII]

Gamebuster schreef op maandag 01 september 2014 @ 19:13:
Hoeveel het verschil is na gzip weet ik inderdaad niet

Dan ga dat eerst maar eens meten. Als je zelf zegt "Bytes besparen in de website is een leuke hobby van me" zou je toch zeggen dat je wist hoeveel gzippen wel/niet uitmaakt t.o.v. wel/niet minifiën en hoeveel gzippen plus minifiën uitmaakt t.o.v. gzippen zonder minifiën

Gamebuster schreef op maandag 01 september 2014 @ 19:13:
maar sinds wanneer is "gzip" het argument om maar niet aan compressie/minification te doen?

Als je gzipped heeft minifiën niet héél veel nut; het is niet 0 maar wel (bijna) verwaarloosbaar. Maar leesbare code > "minified" code (lees: ingekortte classnames). Als jij classnames minified doe je dat waarschijnlijk "handmatig"? Als je / omdat je JS/CSS (automatisch (lees: "gratis")) kunt laten minifiën voordat je deployed (dus ergens in je pipeline) dan doe je dat uiteraard gewoon want mét of zonder gzip scheelt 't altijd wel wat. Maar wat jij doet (classnames kort maken) is niet iets wat makkelijk geautomatiseerd kan worden zodat verwijzingen naar die classnames in HTML/JS/whatever ook 'automatisch meegepakt worden' == dure handenarbeid == de moeite niet waard voor die paar bytes.

Op high-traffic sites (FB, Google, Twitter, Reddit, SO... dat soort sites) scheelt inderdaad elke byte en kan een paar bytes besparing enkele gigabytes per dag besparing opleveren.

[ Voor 11% gewijzigd door RobIII op 01-09-2014 19:59 ]

[Gamebuster]

Ik wil dit soort optimalisaties zo min mogelijk in mijn code terug zien. Minification van classnames gaat prima in CSS en HTML zonder aanpassingen in de code zelf; bij de CSS kan dit eenmalig gebeuren bij het builden van de productie assets en in de HTML kan dit op runtime als plugin voor mijn HTML builder.

Ik ga het absoluut niet met de hand doen, dat is gekkenwerk. Ik ben juist aan het uitzoeken hoe je het kan automatiseren op een zo'n transparante manier mogelijk. Voor de JS moet ik nog een oplossing vinden.

Gzip pas ik sowieso wel toe; Ik kan me niet voorstellen dat als je 5000 bytes bespaard op een CSS file, dat je dit niet terugziet in de gzipped versie ervan. Toch kan ik het pas meten als ik de minification daadwerkelijk heb gemaakt; ik kan het niet vooraf testen.

[ Voor 40% gewijzigd door Gamebuster op 01-09-2014 19:30 ]

[RobIII]

Gamebuster schreef op maandag 01 september 2014 @ 19:27:
Voor de JS moet ik nog een oplossing vinden.

En daar ben ik dan wel eens benieuwd naar. Ik zag je eerder al een "search-and-replace" noemen. Als je dergelijke ongein op een béétje codebase loslaat (dus een niet-context-sensitive Search and Replace) heb je in no-time je code om zeep geholpen. Dan kom je al heel wat meer tooling en andere ongein aan 't aan elkaar knopen om dat goed werkend te krijgen (if at all; ik heb in ieder geval zoiets nog nooit (als in volledig zoals jij wil / beschrijft) gezien, maar ik ben een beetje 'uit' de front-end fads )

[ Voor 5% gewijzigd door RobIII op 01-09-2014 19:42 ]

[Megamind]

Ik heb handmatig gzip toegepast in een WebAPI project waarbij er grote OData queries worden gestuurd, alle tabellen zijn nu een stuk kleiner, enige nadeel, het kost je wel enorm veel aan CPU. Staat nu nog op compression level 5 van de 10, verschil wordt niet veel groter maar CPU gaat wel hard omhoog.

[ Voor 18% gewijzigd door Megamind op 01-09-2014 19:42 ]

[Gamebuster]

Ik heb in mijn geval de mazzel dat de codebase volledig door mij geschreven is. Een context-loze search-and-replace gaat waarschijnlijk werken; alle classnames die vanuit de Javascript gebruikt worden, zijn puur voor de styling van elementen, en is dus aanwezig in de CSS.

Verder, al mijn classnames hebben een vrije vaste benaming-structuur. Zoals eerder aangegeven is de gemiddelde lengte 27 tekens. De kans op collisions is near-0: Er zijn geen classnames als "active", "column" e.d.; alle classnames bestaan uit meerdere woorden gescheiden met een streepje. Als ik een search-and-replace doe op "<classname>", heb ik waarschijnlijk bijna 100% van de cases te pakken. De overige cases kan ik met de hand herkennen.

Toch is er een kans op fouten. Daarom denk ik nog na hoe ik het exact ga aanpakken. Ik denk dat een macro het beste in de buurt komt van "werkt prima" zonder code clutter. Je kan dan denken aan iets als CLASS(dit-is-een-lange-classname) waarbij ik een search-and-replace daarop doe.

Megamind schreef op maandag 01 september 2014 @ 19:41:
Ik heb handmatig gzip toegepast in een WebAPI project waarbij er grote OData queries worden gestuurd, alle tabellen zijn nu een stuk kleiner, enige nadeel, het kost je wel enorm veel aan CPU. Staat nu nog op compression level 5 van de 10, verschil wordt niet veel groter maar CPU gaat wel hard omhoog.

[afbeelding]

Holy shit, van 25MB naar 1MB? Lees ik dat nou goed?

[ Voor 20% gewijzigd door Gamebuster op 01-09-2014 19:43 ]

[RobIII]

Mja, je moet 't ook vooral allemaal lekker helemaal zelf weten hoor Ik krijg er alleen kippenvel van een een behoorlijk NIH gevoel bij.

Gamebuster schreef op maandag 01 september 2014 @ 19:42:
Holy shit, van 25MB naar 1MB? Lees ik dat nou goed?

Aan GZippen heb je (in 99% van de gevallen) véél meer aan dan aan 'minifiën'. Platte tekst (en dan met name code en data want daar zit lekker veel structuur en repeterende tekst in) comprimeert als een dolle. Daar kan 'minifiën' zelden tegenop. De combinatie van die twee technieken kan nog wel wat éxtra opleveren maar GZippen is 't eerste wat ik zou doen.

[ Voor 111% gewijzigd door RobIII op 01-09-2014 20:01 ]

[Gamebuster]

RobIII schreef op maandag 01 september 2014 @ 19:43:
Mja, je moet 't ook vooral allemaal lekker helemaal zelf weten hoor Ik krijg er alleen kippenvel van een een behoorlijk NIH gevoel bij.

[...]

Aan GZippen heb je (in 99% van de gevallen) véél meer aan dan aan 'minifiën'. Platte tekst (en dan met name code en data want daar zit lekker veel structuur en repeterende tekst in) comprimeert als een dolle. Daar kan 'minifiën' zelden tegenop. De combinatie van die twee technieken kan nog wel wat éxtra opleveren maar GZippen is 't eerst wat ik zou doen.

Snap ik, maar gzip staat simpelweg gewoon aan. Daar kan ik verder weinig aan doen

[Megamind]

Daarom goed je console in de gaten houden, hoe groot is je pagina t.o.v. hoeveel bytes gaan er over de lijn.

[Gamebuster]

N.a.v. het herhaaldelijk noemen van gzip, merkte ik iets op in de config van m'n server...

code:

        gzip off;
        gzip_disable "msie6";

        # gzip_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

Iemand heeft hier een serieuze case van maandag gehad.
Zoek de mogelijkheden voor optimalisatie.

edit: Done, gzip werkt nu. Today was a good day
edit2: HTTPS + Gzip... gaat dat wel samen...?

[ Voor 15% gewijzigd door Gamebuster op 01-09-2014 20:15 ]

[Alex)]

Waarom zou je zelf willen minifyen, daar bestaan toch al decennialang tools voor?

[Gamebuster]

Alex) schreef op maandag 01 september 2014 @ 20:17:
Waarom zou je zelf willen minifyen, daar bestaan toch al decennialang tools voor?

Wijs me 1 tool aan die classnames en IDs kan minifyen in je HTML, CSS en JS.

[Martijn19]

https://code.google.com/p/closure-stylesheets/ ?

[Alex)]

Gamebuster schreef op maandag 01 september 2014 @ 20:18:
[...]

Wijs me 1 tool aan die classnames en IDs kan minifyen in je HTML, CSS en JS.

Closure Compiler + Stylesheets + Templates.

[RayNbow]

Gamebuster schreef op maandag 01 september 2014 @ 20:18:
[...]

Wijs me 1 tool aan die classnames en IDs kan minifyen in je HTML, CSS en JS.

Waarom zou je IDs willen minifyen? Die dienen als fragment identifiers.

[incaz]

Nou ja, om dezelfde reden dat een compiler variabelenamen wegcompileert lijkt me? Ik weet niet of je heel veel id's hebt en of het dus wat oplevert, maar het is in principe niet zinniger of onzinniger dan minifyen van classnames - als het zowel in html, js en css gebeurt is er niks aan de hand.

[kaesve]

Het is wel onzinniger, omdat id's extra functionaliteit hebben: http://en.wikipedia.org/wiki/HTML#Attributes leidt naar het subkopje 'Attributes' omdat dat subkopje dat id heeft. Als je het zou minifyen, wordt het iets als http://en.wikipedia.org/wiki/HTML#z, wat een stuk minder makkelijk te onthouden is

[ Voor 7% gewijzigd door kaesve op 01-09-2014 21:41 ]

[farlane]

incaz schreef op maandag 01 september 2014 @ 21:30:
Nou ja, om dezelfde reden dat een compiler variabelenamen wegcompileert lijkt me?

Leg uit? Een variabelenaam wegcompileren?

[phex]

sexyVarName -> a
anotherSexyVarName -> b

[whoami]

Obfuscaten, gelijk we zeggen

[Rutix]

whoami schreef op maandag 01 september 2014 @ 22:58:
Obfuscaten, gelijk we zeggen

Niet perse. Obfuscaten is het onleesbaar van code maken voor mensen dat hoeft niet gelijk te zijn aan minifying

[Gamebuster]

Net guardians of the galaxy gekeken... Damn dat is een zwaar overrated serie pixels.

Martijn19 schreef op maandag 01 september 2014 @ 20:39:
https://code.google.com/p/closure-stylesheets/ ?

Awesome

[ Voor 20% gewijzigd door Gamebuster op 01-09-2014 23:38 ]

[.oisyn]

phex schreef op maandag 01 september 2014 @ 22:38:
sexyVarName -> a
anotherSexyVarName -> b

Eerder:

localName1 -> stack + 4
localName2 -> stack + 8
globalName -> offset 00523b38h

[RobIII]

.oisyn schreef op maandag 01 september 2014 @ 23:38:
[...]

Eerder:

localName1 -> stack + 4
localName2 -> stack + 8
globalName -> offset 00523b38h

Came here to say that, just to find out you beat me to it

whoami schreef op maandag 01 september 2014 @ 22:58:
Obfuscaten, gelijk we zeggen

Obfuscaten is iets anders; je kunt broncode obfuscaten (variabelen foo, bar en baz worden lo10l01l0lol1l, lo10l01l0l011l en 1o10l01l0l011l bijvoorbeeld zodat ze a) lastig te lezen zijn en b) lastig uit elkaar te houden zijn en dan kan er nog vanalles worden gedaan met het 'om-schrijven van logica' zoals (simpel voorbeeld, uit de duim gezogen) if a < b wordt if b > a etc. om code lastiger te doorgronden te maken) en ook op 'machine niveau' kun je code lastig(er) te doorgronden maken door veel jumps naar overal-en-nergens te doen, logica te herschikken zodat 't wel doet wat 't moet doen maar "anders" waardoor je even een mindfuck krijgt, bit-twiddling of opcode truukjes uit te halen die gewoon, bijv., "mul 2, x" doen maar "lsh 1, x" 'lezen' waardoor je brein weer extra 'load' krijgt bij 't begrijpen ervan etc. (wat effectief natuurlijk deels ook gebeurt als je broncode obfuscate).

Bij minifyen is 't doel kleinere (bron)code produceren t.b.v. minder data over de lijn -> snellere page loads. Dat een 'side effect' daarbij is dat myTotallySaneVariableName wordt omgeschreven naar a en dat dat dus wat weg heeft van obfuscation is, IMHO, puur een side-effect.

[ Voor 75% gewijzigd door RobIII op 02-09-2014 00:08 ]

[Douweegbertje]

RobIII schreef op maandag 01 september 2014 @ 23:55:
[...]


Bij minifyen is 't doel kleinere (bron)code produceren t.b.v. minder data over de lijn -> snellere page loads. Dat een 'side effect' daarbij is dat myTotallySaneVariableName wordt omgeschreven naar a en dat dat dus wat weg heeft van obfuscation is, IMHO, puur een side-effect.

Tis simpeler om te zeggen dat "myTotallySaneVariableName" bijvoorbeeld "sbrilaaealtnmtlemnyvoeyaa" wordt.. Juist omdat obfuscation meer het verstoppen van het origineel is en/of moeilijker maken om het origineel te achterhalen. Ik zie het haast meer als een scrambler.

Imo is het makkelijk te vertellen wat obfuscation is dan minifien.

[ Voor 4% gewijzigd door Douweegbertje op 02-09-2014 00:16 ]

[RobIII]

Douweegbertje schreef op dinsdag 02 september 2014 @ 00:15:
Tis simpeler om te zeggen dat "myTotallySaneVariableName" bijvoorbeeld "sbrilaaealtnmtlemnyvoeyaa" wordt.. Juist omdat obfuscation meer het verstoppen van het origineel is en/of moeilijker maken om het origineel te achterhalen. Ik zie het haast meer als een scrambler.

Hoe is 'sbrilaaealtnmtlemnyvoeyaa' een minification van 'myTotallySaneVariableName'? Of begrijp ik je post nou verkeerd? Mijn laatste alinea gaat over minification als je dat gemist mocht hebben Jij hebt 't over obfuscation waar ik de voorlaatste alinea aan spendeer

Kort:

foo, bar en baz worden (bijvoorbeeld) bij
• obfuscation: lo10l01l0lol1l, lo10l01l0l011l en 1o10l01l0l011l
• minification: a, b en c

Hoewel bij obfuscation natuurlijk ook prima a, b, en c kunnen worden gebruikt, maar die zijn makkelijker uit elkaar te houden als je probeert broncode (of "decompiled code") te de-obfuscaten (wat vaak toch (deels) noeste "grijze massa arbeid" is)

[ Voor 27% gewijzigd door RobIII op 02-09-2014 00:39 ]

[Verwijderd]

RobIII schreef op maandag 01 september 2014 @ 19:43:
Mja, je moet 't ook vooral allemaal lekker helemaal zelf weten hoor Ik krijg er alleen kippenvel van een een behoorlijk NIH gevoel bij.

[...]

Aan GZippen heb je (in 99% van de gevallen) véél meer aan dan aan 'minifiën'. Platte tekst (en dan met name code en data want daar zit lekker veel structuur en repeterende tekst in) comprimeert als een dolle. Daar kan 'minifiën' zelden tegenop. De combinatie van die twee technieken kan nog wel wat éxtra opleveren maar GZippen is 't eerste wat ik zou doen.

Wellicht een interessant artikel inzake CSS minifying en het gebruik van Gzip: CSS Minifier and alphabetiser. Zo te zien zit er nog best een winst in (~20%) te behalen bij het efficienter minifyen van CSS, als ik dat artikel mag geloven. Wat Gzip bijvoorbeeld leuk vind, is alfabetisch geordende properties.

[Rutix]

RobIII schreef op dinsdag 02 september 2014 @ 00:18:
[...]

Hoe is 'sbrilaaealtnmtlemnyvoeyaa' een minification van 'myTotallySaneVariableName'? Of begrijp ik je post nou verkeerd? Mijn laatste alinea gaat over minification als je dat gemist mocht hebben Jij hebt 't over obfuscation waar ik de voorlaatste alinea aan spendeer

Kort:

foo, bar en baz worden (bijvoorbeeld) bij
• obfuscation: lo10l01l0lol1l, lo10l01l0l011l en 1o10l01l0l011l
• minification: a, b en c

Hoewel bij obfuscation natuurlijk ook prima a, b, en c kunnen worden gebruikt, maar die zijn makkelijker uit elkaar te houden als je probeert broncode (of "decompiled code") te de-obfuscaten (wat vaak toch (deels) noeste "grijze massa arbeid" is)

Je begrijpt zijn post verkeerd hij bedoelt dat obfuscaten ook van 'myTotallySaneVariableName' , 'sbrilaaealtnmtlemnyvoeyaa' kan maken omdat het niet als doel heeft om zo klein mogelijk te zijn maar niet te lezen ;P

[RobIII]

Rutix schreef op dinsdag 02 september 2014 @ 07:57:
[...]

Je begrijpt zijn post verkeerd hij bedoelt dat obfuscaten ook van 'myTotallySaneVariableName' , 'sbrilaaealtnmtlemnyvoeyaa' kan maken omdat het niet als doel heeft om zo klein mogelijk te zijn maar niet te lezen ;P

...wat ik dan maar matige obfuscation vind; bij kortere variabelenamen (zeg foo en bar) heb je een stuk minder permutaties en zijn de variabelen nog steeds goed uit elkaar te houden. Maar het valt wel onder obfuscation ja.

[incaz]

kaesve schreef op maandag 01 september 2014 @ 21:40:
Het is wel onzinniger, omdat id's extra functionaliteit hebben: http://en.wikipedia.org/wiki/HTML#Attributes leidt naar het subkopje 'Attributes' omdat dat subkopje dat id heeft. Als je het zou minifyen, wordt het iets als http://en.wikipedia.org/wiki/HTML#z, wat een stuk minder makkelijk te onthouden is

Da's waar. Als die functionaliteit nodig is, is het inderdaad niet handig om te minifyen.

[.oisyn]

RobIII schreef op dinsdag 02 september 2014 @ 08:45:
[...]

...wat ik dan maar matige obfuscation vind; bij kortere variabelenamen (zeg foo en bar) heb je een stuk minder permutaties en zijn de variabelen nog steeds goed uit elkaar te houden. Maar het valt wel onder obfuscation ja.

Korte namen zijn juist beter uit elkaar te houden, en is daarmee dus slechter dan het gebruik van lange namen.

[Voutloos]

Het maakt vooral ook niet uit, want je kan immers eenzelfde tool draaien welke namen oplevert van een door jouw gewenste lengte.

[Jan_V]

Jan_V schreef op maandag 25 augustus 2014 @ 21:56:
[...]

Zelf ben ik nog van de 'overal-een-interface-voor-maken'-code. Zal morgen het stuk van Ayende wel even lezen, misschien kom ik dan tot andere inzichten.

[oude-koeien-uit-de-sloot]
Zo, het heeft even geduurd, maar ik ben er eindelijk aan toe te komen om alle posts van Ayende te lezen over Limit your abstractions.
Het is zeker een interessante kijk op dingen en waarschijnlijk ook goed toepasbaar. Wel even wennen qua concept, maar vast en zeker werkbaar.
Wel zit ik nog een beetje met het 'injecteren' van de benodigde properties die sommige objecten/classes nodig hebben. Tevens zou ik waarschijnlijk een soort van CommandExecutor toevoegen, wat SteveR ook aanhaalt in de comments, zodat je niet rare if-statements krijgt in je productie code.

Binnenkort maar eens proberen dit uit te voeren in een project en kijken hoe ver ik er mee kom. Het lijkt in ieder geval te zorgen voor een veel 'schonere' codebase.

[F.West98]

* F.West98 deelt koffie uit

*gaaaap*

[Rutix]

Nu pas wakker? Luilak! Ik zit al bijna 5 uur op kantoor

[Alex)]

Eindejaarsgesprek gehad met mijn manager. Ging goed

[Kayr]

Alex) schreef op dinsdag 02 september 2014 @ 11:46:
Eindejaarsgesprek gehad met mijn manager. Ging goed

Eindejaars.... in September....?

[Alex)]

Kayr schreef op dinsdag 02 september 2014 @ 11:47:
[...]

Eindejaars.... in September....?

Ons nieuwe fiscale- en carrièrejaar begint nou eenmaal op 1 september.

[Laurens-R]

@alex: Gefeliciteerd... heb ook de mijne gehad

[Gamebuster]

http://www.pointerpointer.com
^ lol

http://donottouch.org (filmpje bevat enkele seconden soort-van NSFW)
^ awesome

[ Voor 65% gewijzigd door Gamebuster op 02-09-2014 14:49 ]

[Matis]

Gadverdamme.

Sinds 1 september zijn we met onze webbased urenregistratietool van een lokale server naar de cloud gegaan.
Wanneer je nu de tool (lees URL) wilt openen, moet je eerst handmatig een certificaat installeren in de browser. Daarna moet je dat certificaat middels een wachtwoord decrypten en dan pas kun je inloggen.
Voor iedere browser op iedere PC moet bovenstaand proces doorlopen worden, wil je er bij kunnen.


Over "security through obscurity" gesproken.

[ Voor 4% gewijzigd door Matis op 02-09-2014 12:57 ]

[alienfruit]

Ach nog altijd beter wanneer het alleen werkt in Silverlight in Firefox... SAP ByD prut

[xehbit]

Gamebuster schreef op dinsdag 02 september 2014 @ 12:35:
http://www.pointerpointer.com
^ lol

http://donottouch.org
^ awesome

Hahahaha prachtig die 2e

[Swedish Clown]

F.West98 schreef op dinsdag 02 september 2014 @ 11:39:
* F.West98 deelt koffie uit

*gaaaap*

Nu pas wakker? Dacht dat jij les had om die tijd of ben je aan het spijbelen?

[TheNephilim]

Matis schreef op dinsdag 02 september 2014 @ 12:57:
Gadverdamme.

Sinds 1 september zijn we met onze webbased urenregistratietool van een lokale server naar de cloud gegaan.
Wanneer je nu de tool (lees URL) wilt openen, moet je eerst handmatig een certificaat installeren in de browser. Daarna moet je dat certificaat middels een wachtwoord decrypten en dan pas kun je inloggen.
Voor iedere browser op iedere PC moet bovenstaand proces doorlopen worden, wil je er bij kunnen.
[afbeelding]

Over "security through obscurity" gesproken.

Dat doen ze bij de RDW ook zo, als je aansluit als autohandelaar.

[Matis]

alienfruit schreef op dinsdag 02 september 2014 @ 12:58:
Ach nog altijd beter wanneer het alleen werkt in Silverlight in Firefox... SAP ByD prut

Voorheen werkte het alleen in Internet Explorer < 10 op Windows. Nu werkt het wel in diverse browsers op zowel Windows als Linux-based OSen.

[Rutix]

Gamebuster schreef op dinsdag 02 september 2014 @ 12:35:
http://www.pointerpointer.com
^ lol

http://donottouch.org
^ awesome

Die tweede is wel nice. Alleen jammer dat er dus een NSFW stukje in zit

TheNephilim schreef op dinsdag 02 september 2014 @ 13:28:
[...]


Dat doen ze bij de RDW ook zo, als je aansluit als autohandelaar.

Dat is een holder of key principe denk ik (wel een crappy implementatie though).

[Gamebuster]

Rutix schreef op dinsdag 02 september 2014 @ 14:43:
[...]
Die tweede is wel nice. Alleen jammer dat er dus een NSFW stukje in zit

Cursor erop plaatsen dan maar

[Koetjeboe]

Die 2e is ook leuk met de javascriptconsole open

[Gamebuster]

N.a.v. die "do not touch" site, heb ik het idee gekregen om een soort lemmings game te maken, waarbij iedereen met zijn cursor een pad kan maken. Niet dat ik het daadwerkelijk ga uitvoeren, maar het is wel een geinig idee

[BikkelZ]

Gamebuster schreef op dinsdag 02 september 2014 @ 14:55:
Niet dat ik het daadwerkelijk ga uitvoeren, maar het is wel een geinig idee

Story of my life bro

[F.West98]

Ik zat net ook gewoon op school hoor
Met een laptop.

[RobIII]

.oisyn schreef op dinsdag 02 september 2014 @ 09:41:
[...]

Korte namen zijn juist beter uit elkaar te houden, en is daarmee dus slechter dan het gebruik van lange namen.

Dat zeg ik toch?
foo obfuscaten naar lo10l01l0lol1l en bar obfuscaten naar lo10l01l0l011l
is beter dan
foo obfuscaten naar ofo en bar obfuscaten naar rab

myTotallySaneVariableName obfuscaten naar lo10l01l0lol1ll1o0l101l0l10lo01l
is beter dan
myTotallySaneVariableName obfuscaten naar sbrilaaealtnmtlemnyvoeyaa

[ Voor 17% gewijzigd door RobIII op 02-09-2014 15:18 ]

[OkkE]

Ugh. Website update live zetten op een externe webserver waar we geen SSH toegang hebben. Dat is sowieso al vervelend (wat voelt FTP toch ouderwets en enigszins scary), maar het lijkt er op dat de versie die nu live staat in de map "test.domein.nl" staat ipv "www.domein.nl"...

[Gamebuster]

BikkelZ schreef op dinsdag 02 september 2014 @ 15:00:
[...]


Story of my life bro

Jammer is dat he

[.oisyn]

RobIII schreef op dinsdag 02 september 2014 @ 15:16:
[...]

Dat zeg ik toch?

Dat bedoel je misschien, maar dat zei je niet:

Rutix schreef op dinsdag 02 september 2014 @ 07:57:
[...]

Je begrijpt zijn post verkeerd hij bedoelt dat obfuscaten ook van 'myTotallySaneVariableName' , 'sbrilaaealtnmtlemnyvoeyaa' kan maken omdat het niet als doel heeft om zo klein mogelijk te zijn maar niet te lezen ;P

RobIII schreef op dinsdag 02 september 2014 @ 08:45:
[...]

...wat ik dan maar matige obfuscation vind; bij kortere variabelenamen (zeg foo en bar) heb je een stuk minder permutaties en zijn de variabelen nog steeds goed uit elkaar te houden. Maar het valt wel onder obfuscation ja.

Samenvatting: van "myTotallySaneVariableName" "sbrilaaealtnmtlemnyvoeyaa" maken vind jij maar matige obfuscation

[ Voor 6% gewijzigd door .oisyn op 02-09-2014 15:34 ]

[Merethil]

.oisyn schreef op dinsdag 02 september 2014 @ 15:32:
[...]

Dat bedoel je misschien, maar dat zei je niet:


[...]


[...]

Samenvatting: van "myTotallySaneVariableName" "sbrilaaealtnmtlemnyvoeyaa" maken vind jij maar matige obfuscation

Hij zegt toch juist dat bij korte namen zoals "foo" en "bar" je dan maar heel weinig permutaties hebt, dus dat je graag ziet dat obfuscation niet alleen woorden husselt maar er langere namen van maakt?

Voor je laatste stukje: Ja, want je krijgt dan gezeur met korte namen, dus de VORM van obfuscation is slecht. Zijn zelf aangeraden vorm is een stuk minder makkelijk te lezen voor buitenstaanders.

[ Voor 28% gewijzigd door Merethil op 02-09-2014 15:35 ]

[.oisyn]

Merethil schreef op dinsdag 02 september 2014 @ 15:34:
[...]


Hij zegt toch juist dat bij korte namen zoals "foo" en "bar" je dan maar heel weinig permutaties hebt

Dat zegt ie idd

dus dat je graag ziet dat obfuscation niet alleen woorden husselt maar er langere namen van maakt?

Dat is iets wat je er nu zelf bij bedenkt dmv logisch redeneren, maar dat stond er niet. Het tweede stukje is op z'n minst ambigu, maar het eerste stukje duidelijk niet. Het ging om het gebruik van lange namen, Rutix zegt daar wat over, en RobIII reageert met "wat ik maar matige obfuscation vindt", en vervolgens begint ie over korte namen (ergo, hij vindt lange namen matige obfuscation)

Voor je laatste stukje: Ja, want je krijgt dan gezeur met korte namen, dus de VORM van obfuscation is slecht. Zijn zelf aangeraden vorm is een stuk minder makkelijk te lezen voor buitenstaanders.

Wederom, dat is wat ie bedoelde, maar niet wat er heel duidelijk stond opgeschreven in die ene post.

Maar goed, deze metadiscussie is pas obfuscation.

---

Ontopic: ben het niet met RobIII eens dat jsahhrfegrlkajrhhawg duidelijker te lezen is dan lo10l01l0lol1ll1o0l101l0l10lo01l.

Verder heeft Korben eerder natuurlijk een heel goed punt. De namen boeien eigenlijk niet echt, een decompiler kan die dingen prima renamen naar iets wat wél goed uit elkaar te houden is.

[ Voor 14% gewijzigd door .oisyn op 02-09-2014 16:01 ]

[Merethil]

.oisyn schreef op dinsdag 02 september 2014 @ 15:40:
[...]

Dat zegt ie idd

[...]

Dat is iets wat je er nu zelf bij bedenkt dmv logisch redeneren, maar dat stond er niet. Het tweede stukje is op z'n minst ambigu, maar het eerste stukje duidelijk niet. Het ging om het gebruik van lange namen, Rutix zegt daar wat over, en RobIII reageert met "wat ik maar matige obfuscation vindt", en vervolgens begint ie over korte namen (ergo, hij vindt lange namen matige obfuscation)


[...]

Wederom, dat is wat ie bedoelde, maar niet wat er heel duidelijk stond opgeschreven in die ene post.

Maar goed, deze metadiscussie is pas obfuscation.
Ontopic: ben het niet met RobIII eens dat jsahhrfegrlkajrhhawg duidelijker te lezen is dan lo10l01l0lol1ll1o0l101l0l10lo01l.

Verder heeft Korben eerder natuurlijk een heel goed punt. De namen boeien eigenlijk niet echt, een decompiler kan die dingen prima renamen naar iets wat wél goed uit elkaar te houden is.

Op een forum van Tweakers zou je toch verwachten dat (het overgrote deel van) de lezers dit zelf wel kan opmaken uit zijn manier van schrijven? Ik snap dat je er graag op wijst dat hij wat ambigu schrijft, maar je hebt het zelf begrepen, net als ik en waarschijnlijk vele anderen. Waarom dan nog een punt van maken?

[Dido]

.oisyn schreef op dinsdag 02 september 2014 @ 15:40:
Maar goed, deze metadiscussie is pas obfuscation.

Nogal ja, ik ben eerlijk gezegd de draad volledig kwijt. Ik weet dat het over obfuscation gaat, maar wie nu precies wat heeft gezegd en waarom een ander daar dan wel of niet instemmend op reageert... sterker nog, ik weet niet eens zeker wie het nu wel of niet met wie eens is.

Ik ben wat gewend vanuit W&L, maar dit niveau van metaobfuscation verdient een pluim!

[Coca-Cola]

Dido schreef op dinsdag 02 september 2014 @ 15:55:
[...]

Nogal ja, ik ben eerlijk gezegd de draad volledig kwijt. Ik weet dat het over obfuscation gaat, maar wie nu precies wat heeft gezegd en waarom een ander daar dan wel of niet instemmend op reageert... sterker nog, ik weet niet eens zeker wie het nu wel of niet met wie eens is.

Ik ben wat gewend vanuit W&L, maar dit niveau van metaobfuscation verdient een pluim!

Misschien een nieuwe titel voor .oisyn: 'discussie metaobfuscator 2015'

[.oisyn]

Merethil schreef op dinsdag 02 september 2014 @ 15:48:
maar je hebt het zelf begrepen

Ja net pas, met behulp van jouw post en het stukje wat RobIII in zijn laatste post heeft bijgeëdit maar wat ik niet zag omdat edits niet updaten

[ Voor 29% gewijzigd door .oisyn op 02-09-2014 16:00 ]

[Dido]

Coca-Cola schreef op dinsdag 02 september 2014 @ 15:57:
Misschien een nieuwe titel voor .oisyn: 'discussie metaobfuscator 2015'

x010ooI0I2^11-0x111 dan toch wel? Of heb ik de discussie nou helemaal verkeerd begrepen?