Releasenotes voor development-iteratie #102

Zoals jullie inmiddels wel gewend zijn, willen we jullie op de hoogte houden van waar we achter de schermen mee bezig zijn. Naast de uitgebreide iteratie-updates hebben we daarom ook dit soort releasenotes, waarin we jullie bijpraten.

Verbeteringen automatische incasso / aboshop

Bij het afrekenen van een abonnement in de aboshop kregen meerdere tweakers een foutmelding dat er iets misgegaan was met de betaling, terwijl dit niet het geval was. Dit hebben we opgelost. Daarnaast hebben we het bestelformulier overgezet naar nieuwe Twig-templates en konden we eindelijk de oude code van de aboshop naar de code graveyard verplaatsen. Ook zijn nog wat tekstwijzigingen en de afbeelding van het welkomstgeschenk vernieuwd. Heb jij de Tweakers sokken al?

Community Pick

Bij de afgelopen .plan van development-iteratie #101 hebben jullie massaal gestemd om beter onderscheid te maken tussen koper en verkoper in Vraag & Aanbod. Dit hebben we natuurlijk meteen opgepakt en het resultaat kun je vinden bij de gebruikersbeoordelingen in V&A.

In de volgende iteratie-update kun je weer stemmen op de community pick. Steun ondertussen je favoriete feature in het Mooie Features-forum met een thumbs-up zodat deze bij ons op de radar verschijnt.

Kleine verbeteringen en bugfixes

• We hebben de knoppen voor het volgende/vorige artikel iets aangepast. Nu wordt het type artikel erbij getoond, zodat je weet waar je doorheen aan het bladeren bent.
• Dankzij Adaolin hebben we een bugje kunnen fixen waarbij niet-ingelogde gebruikers bij het toevoegen van een product aan een wensenlijst een lijst van gearchiveerde wensenlijsten te zien kregen. Bedankt voor het doorgeven!
• Bij productspecificaties waarbij zowel kleine als hele grote waarden moeten kunnen worden weergeven, ging dat niet altijd goed. Dit kwam omdat onze java-code nog met 32bit-integers werkte. Dit hebben we aangepast naar 64bit-integers en zo kunnen we een breder bereik verwerken.
• Sliders werden op mobiel niet meteen goed weergegeven op het overzichtstabblad bij een productcategorie.

Reacties (41)

[DutchKevv]

Leuk dat jullie de dev plannen openbaar maken Geeft soms een leuk kijkje in de keuken!

Anyway, niet zo heel belangerijk ->

Maar de JS files van tweakers lijken maar half gecompressed.. Heb er 3 gepakt en kon gemiddeld 20% er af snoepen met een betere compressie.. Bijvoorbeeld 25% winst op de general.js.

Toch maar weer in de pocket

Success!

[crisp]

Wij minificeren geen variabele- en functienamen, dat maakt onze javascript nog een beetje debugbaar (plus dat de tool die we nu gebruiken daar ook geen ondersteuning voor heeft ).

[Verwijderd]

Daarvoor bestaan er source maps, maar misschien ondersteund jullie tooling dat ook niet?

[crisp]

De tool die wij nu nog gebruiken is een van de eerste minifiers op basis van een echte javascript parser Inmiddels zijn er inderdaad betere tools zoals UglifyJs. We zijn er echter nog niet aan toegekomen dat aan te passen. De winst is ook niet zo heel erg groot absoluut gezien; onze JS is al aardig compact

[Verwijderd]

Ik doel eigenlijk op de winst van source maps, op zich staat dat los van de minifier of uglifier.

[crisp]

Als devvers kunnen we met een parameter wel de non-minified versies van onze scripts inladen. Simpel maar effectief

[Verwijderd]

ok handig, komt op hetzelfde neer

[AW_Bos]

Was dat eigenlijk een publieke parameter, als ik vragen mag?

[crisp]

Nee, dergelijke switches zijn bij ons 'beveiligd' op account- en ip niveau. We hebben bijvoorbeeld ook een switch om ons voor te doen als een Belgische bezoeker, om uitgevoerde queries in onze console te zien, of zelfs andere gebruikers te imiteren

[AW_Bos]

Ik zie dat niet alles minified is.
x/responsive/article.js is dat weer niet.

[crisp]

klopt, maar dat zijn sowieso erg kleine scripts waar het weinig voor zal uitmaken (zeker met gzip compressie)

[guanche]

Is dat nog steeds die tool die je waay-back een keer geschreven hebt daarvoor? (naam staat me even niet meer bij)

[crisp]

Jep, JSMin+

[ACM]

Heb je het dan over gzip-compressie, over 'minification' of iets anders?

[DutchKevv]

De compressie / minification.

Zoals @crisp ook al aangeeft, zijn er met moderne tools nogal wat kb's te besparen (denk aan uglify etc).

Er is inderdaad niet bijster veel JS dat ingeladen word, maar persoonlijk had ik de files ook gepacked in 1 bundle ipv als losse files inladen.

Nu is er een general.js, frontpage+banners+storage.js en reacties.js etc.. Maar als je tweakers bezoekt, zul je altijd de general + frontpage + reacties nodig hebben, immers bij het eerste beste artikel dat je leest heb je alle bovengenoemde files toch al nodig, dus kun je ze net zo goed packagen in 1 file.

Scheelt naast de KB's van het compressen, vooral weer een aantal requests (browser heeft een limiet van max 6 tegelijk, IE zelfs maar 2-4).

Straks met http2 zal het weinig verschil maken, maar voor nu is het toch nog wel een makkelijke win.

Maar nogmaals, het is geen JS minded website, dus een wereld van verschil zal het niet gaan maken. Het is vooral een makkelijke win

[Reactie gewijzigd door DutchKevv op 24 juli 2024 11:23]

[ACM]

Straks met http2?!

We hebben het al meer dan een half jaar

Overigens zullen veel bezoekers helemaal niet per se die reacties nodig hebben, het is niet ongebruikelijk dat juist bezoeker met weinig visits (en dus koude cache) alleen maar pagina's in de pricewatch bezoeken.

[DutchKevv]

Ah oké oke.. Maar staan er in de pricewatch geen reacties etc dan?

En dat tweakers http2 ondersteunt is natuurlijk maar het halve verhaal, alle clients moeten het ook ondersteunen

[ACM]

Eens, maar gelukkig is ook daar goed nieuws. Onze loadbalancers krijgen zo'n 85% van de requests op de https-versie van tweakers.net (inc. gathering.tweakers.net en de image-domeinen) via HTTP/2.

[Reactie gewijzigd door ACM op 24 juli 2024 11:23]

[DutchKevv]

Ah das al aardig wat!

Ja in dat geval vervalt de nood eigenlijk om te bundelen.

Werk momenteel voor moederbedrijf van Pabo en ChristineLeDuc etc en daar halen ze ongeveer 40%. Al komen daar natuurlijk ongeveer het tegenovergestelde publiek met net zo averechts moderne client machines

Na anyway, never mind in dat geval. Zal dan nog weinig winst boeken op Tweakers

Go go go!

[Ulster Seedling]

Bij de afgelopen .plan van development-iteratie #101 hebben jullie massaal gestemd om beter onderscheid te maken tussen koper en verkoper in Vraag & Aanbod. Dit hebben we natuurlijk meteen opgepakt en het resultaat kun je vinden bij de gebruikersbeoordelingen in V&A.

https://ic.tweakimg.net/ext/i/imagenormal/2001434121.png

Is het niet logischer om de toevoeging bij de andere user te tonen? Op dit moment staat er "(koper)" of "(verkoper)" achter de naam van de auteur van de review. De review gáát echter over de andere user, dus het lijkt me relevanter om weer te geven of díé koper of verkoper was.

[Reactie gewijzigd door Ulster Seedling op 24 juli 2024 11:23]

[ACM]

We zouden dan ook beide kunnen doen?

Dus in dit voorbeeld komt er dan: 'Beoordeling van Rees (koper) over Femme (verkoper) ...'

[Ulster Seedling]

Persoonlijk lijkt dat me niet nodig. De review gaat over de 'tweede' user, dus het is van belang om snel duidelijk te hebben wat voor rol die speelde. Een vermelding bij de 'eerste' user is dan een beetje dubbelop. Maar het lijkt me in ieder geval beter dan de huidige situatie

Edit: Voordeel van het enkel bij de tweede user tonen is dat je in één oogopslag kunt zien waar de beoordeling voor was, je hoeft enkel "(koper)" of "(verkoper)" te spotten en het is duidelijk. Toon je het voor beide users, dan moet je alsnog goed lezen/kijken/nadenken erover.

[Reactie gewijzigd door Ulster Seedling op 24 juli 2024 11:23]

[matroosoft]

Dat lijkt mij wel de meest duidelijke oplossing..

[Chrotenise]

Amen.

[Chocoball]

Als verkoper kan ik weinig met de velden Voldoet aan beschrijving en Aflevering bij de koper. Toch vul ik ze altijd in omdat ik niet weet of dit invloed heeft op de V&A-beoordelingsscore?

Is het dan niet beter deze velden weg te laten of niet invulbaar te maken bij het beoordelen van de koper? Ik zou namelijk niet weten op welke andere criteria ik de koper nog verder kan beoordelen dan communicatie. Beoordeling over de betaling kan ook in het commentaarveld.

[ACM]

Dat stond in het originele verzoek... maar er zijn - zoals altijd - corner cases waar het dan weer lastig wordt (iig met weglaten). Zodra er bijvoorbeeld sprake is van een ruil-deal hebben beide partijen een verantwoordelijkheid met betrekking tot die beoordelingen.

Als ze ook daadwerkelijk niet leeg te laten zijn, dan moeten we daar nog wel naar kunnen kijken. Ik ben er met de uitwerking van dat ticket eigenlijk voetstoots van uit gegaan dat ze niet verplicht zouden zijn

[ehtweak]

'Voldoet aan beschrijving' & 'Aflevering' is toch ook niet zo relevant voor verkoper?
Dat vul ik ook niet in, als verkoper zijnde, m.b.t. de beoordeling van de koper.
Alleen het 'Communicatie' item is dan van belang.
M.a.w. geen sterren, onbeoordeeld laten, heeft ook geen invloed op het gemiddelde, heb ik gemerkt.
Mag aannemen dat dit zo in stand blijft?

[ACM]

Jahoor. Dat gaan we niet veranderen. Als ze relevant zijn, graag invullen, ook als je zelf de verkoper bent. Maar inderdaad alleen invullen als ze relevant zijn.

We gaan dat dan niet ineens als 0 tellen. En mocht je ons daar toch op betrappen, dan hebben we daar een bug geïntroduceerd

[TwistedMindNL]

Artikel gereleaset om 13:37, nice touch

[Xav]

Was alweer te lang geleden...

[Reactie gewijzigd door Xav op 24 juli 2024 11:23]

[HKLM_]

"Bij de afgelopen .plan van development-iteratie #101 hebben jullie massaal gestemd om beter onderscheid te maken tussen koper en verkoper in Vraag & Aanbod. Dit hebben we natuurlijk meteen opgepakt en het resultaat kun je vinden bij de gebruikersbeoordelingen in V&A."

Ik moest alsnog zoeken wat er nu veranderd was, het is wel duidelijker maar het valt niet echt op...

[ACM]

Het lijkt me ook weer niet het belangrijkste element van een beoordeling (toch?), dus als dit wel moet opvallen, ten koste van welk(e aandacht voor een) element mag dat dan gaan?

[Luca]

Is het niet een idee om weer een poll te gebruiken in dit artikel? En zo iedere keer wat dingen die de community graag wil af werken.

[ACM]

Dat doen we ook, maar dan bij elke 2e keer.

[Verwijderd]

Ziet er weer goed uit allemaal

[Anonymoussaurus]

Bedankt weer! Erg fijn dat jullie de community laten kiezen voor nieuwe functies!

[Kiswum]

Bedankt voor deze mooie toevoeging. Het was even zoeken naar de verschillen, maar het is in ieder geval zichtbaar. Zoals ACM al aangaf, het is lastig om het op te vallen, zonder de rest uit het oog te verliezen.

@Sven Koene, een nieuwe naam. Veel succes en plezier bij Tweakers!

[Zvennn]

Thnx! Dat gaat zeker lukken

[Martinspire]

Niet iets nieuws om op te stemmen?

[matroosoft]

Elke tweede keer: Releasenotes > iteratie-update