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. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 127 reacties, 139.456 views •

De engine in de toekomst

Onze site, code en engine kunnen altijd beter. De belangrijkste toepassing die nog niet gerealiseerd was bij de release van Tweakers 7, was de integratie van het forum. We willen namelijk dezelfde techniek gaan gebruiken om lijstjes forumtopics te kunnen presenteren, bijvoorbeeld als tab binnen een merkpagina. Die toont dan alle forumtopics die gekoppeld zijn aan het merk Kingston of producten van dat merk. Bovendien moet de zoektechniek die we voor veel andere onderdelen van de site hebben geïntroduceerd ook voor het forum gebruikt gaan worden. Omdat het hier gaat over tientallen gigabytes aan informatie, hebben we dit niet gelijk geprobeerd te integreren.

Dbadmin disk-grootte voor Topics en Messages

Op deze manier konden we eerst de basisideeën van de techniek goed in de praktijk testen. Bovendien zou het integreren van die functionaliteit onze overstapdatum weer weken of zelfs maanden uitgesteld hebben. Het is natuurlijk jammer voor degenen die al heel lang wachten op een betere zoekmachine in het forum, maar hij is eindelijk in ontwikkeling. Op het moment van schrijven is er zelfs al een goed werkende opzet, die we nu verder uitwerken :)

Forumtab van TPlink voor Tweakers 7

Daarnaast is het de bedoeling dat je de forumtopics ook bij de algemene zoekresultaten gaat vinden. Ook dit is geen triviale uitbreiding; dus ga er maar vanuit dat we de nieuwe forumzoekmachine eerst in gebruik nemen en dat we de geïntegreerde zoekfunctie pas in een latere iteratie uitbreiden.

Verder zullen we natuurlijk nog kijken naar andere onderdelen van de site die hier nog niet in opgenomen zijn en daar wel baat bij hebben. Momenteel vallen onder andere de Meuktracker, onze banensectie en wat andere kleinere delen nog (deels) buiten de boot. Ook die stonden eerder wel op het programma, maar zijn uiteindelijk uitgesteld om het Tweakers 7-project een gezonde einddatum te kunnen geven.


Door Arjen van der Meijden

- Lead Developer

In oktober 2001 begonnen met als voornaamste taak het technisch beheer van het forum. Daarna doorgegroeid tot senior developer en software architect. Nu lead developer, met een leidinggevende taak aan het team van programmeurs en systeembeheerders van Tweakers.net.

Lees meer over

Reacties (127)

Reactiefilter:-11270122+195+220+30
Moderatie-faq Wijzig weergave
Interessant om te lezen hoe het Tweakers.net platform werkt, er is duidelijk goed over nagedacht en serieus werk van gemaakt. Zeker geen speelgoed site dus. Het geeft ook maar weer eens aan dat er meerdere wegen zijn die naar Rome leiden.

Desondanks zou ik zelf toch andere keuzes gemaakt hebben. Niet omdat jullie keuzes verkeerd zijn of niet goed werken, maar omdat ik sterk het vermoeden heb dat je dezelfde performance, functionaliteit en schaalbaarheid waarschijnlijk ook kunt bereiken met een veel eenvoudigere setup, met veel minder hardware, en (misschien wel het belangrijkste): met veel minder eigen code. De beweegredenen om voor de huidige oplossing te kiezen zijn helder, en ingegeven door wat er tijdens de eerste ontwikkeling beschikbaar was, maar vandaag de dag kun je met een goed opgezette tiered technology stack denk ik hetzelfde bereiken met veel minder. Ik zit dan specifiek te denken aan een engine geschreven in een Python web-app framework, hosted via een wSGI server container, achter een nginx proxy, MongoDB+memcached voor je database. Dit zou prima horizontaal en verticaal moeten kunnen schalen, omdat je op elke laag van de database via de webapp, de wsgi server en de proxy met slechts configuratie (zonder code te hoeven schrijven) kunt kiezen hoeveel instantiaties je van elke laag wilt hebben, en hoeveel resources je per instantie wilt toekennen. Mits goed uitgewerkt (REST interface die gebruik maakt van alle beschikbare HTTP protocol features) zou slechts een klein deel van je requests daadwerkelijk in de Python web-app terecht hoeven te komen, en kan veruit het grootste deel als statische content of uit cache geserved kunnen worden via nginx.

Maargoed wat jullie nu hebben blijkt ook prima te werken, ik zou zelf alleen geen zin hebben om al die Java code te schrijven en onderhouden, ik vind het echt zo'n beetje de meest frustrerende en omslachtige programmeertaal die er is.

Een kleine opmerking nog over NoSQL/MongoDB: het is inderdaad zo dat je vaak gedenormaliseerde data in een NoSQL database opslaat, omdat dat ook vaak een prima oplossing met veel voordelen (geen complexe queries nodig, snel) en weinig nadelen (duplicatie, lastige updates) is. Er is echter geen enkele reden om sommige data niet genormaliseerd op te slaan zoals in een SQL database! Dit is een vaak gehoorde klacht van mensen die uit de SQL wereld komen en NoSQL maar niks vinden, maar niemand verbiedt je om delen van je database net zo op te slaan als je in SQL zou doen, wanneer dat beter past op de access patterns e.d. Je kunt dan misschien niet via joins in 1x dezelfde complex queries doen als met SQL, en zult af en toe je queries moeten splitsen, maar dat is een trade-off die meestal wel te verantwoorden is, omdat gemiddeld genomen het overgrote deel van je data write-once/read-only is, en dus heel prettig in een NoSQL database past.
Hoewel je post wel meer een Python verkoop praatje is zit er wel een kern van waarheid in - wat is er gebeurd met het KISS concept? Als je er als buitenstaander nuchter naar kijkt dan was mijn eerste ingeving: Waarom zo complex? Geen wonder dat hier al een aantal jaar aan gesleuteld wordt.

Ik denk wat mijn bovenbuurman ook probeert te zeggen: Sluit jezelf niet op in een tunnelvisie maar kijk ook naar het grotere plaatje. Misschien kan je vandaag de dag veel meer oplossen met een NoSQL oplossing dan je denkt. Maar aan de andere kant is 50GB aan DB data nou ook niet echt heel veel, dus heb je dat eigenlijk wel nodig? Daarnaast, T.net is niet de enige prijsvergelijker op deze wereld dus er zijn vast wel andere mensen die jullie problemen ook in zekere zin hebben gehad, en wellicht ook al opgelost hebben.

Ongeacht wat er gekozen wordt kiest is er sowieso al wat gewonnen - er is nu veel Java kennis in huis en je hebt als het goed is geleerd van de fouten die gemaakt zijn in het verleden. Het lijkt mij ook een logische stap om daar mee verder te gaan.

Voor de rest prima artikel en laat ze vaker zien!
50GB is inderdaad niet per se "veel". De datasets in deze java-omgeving zijn overigens tientallen tot honderden MB's, die 50GB is een voorbeeld van eentje die weer wat extra gradaties aan complexititeit toevoegt.

Maar zulk soort aantallen kunnen wel degelijk behoorlijk veel blijken te zijn in een context waarvan je soms complexe resultaten (denk aan de facetten met aantallen van de overgebleven hoeveelheid resultaten in de pricewatch) moet zien te produceren in een voor het web acceptabele hoeveelheid tijd...

En wij willen onze pagina's bij voorkeur binnen 100ms klaar hebben. Dan kan de webbrowser tenminste vlot aan de slag met het ophalen van allerlei aanvullende informatie en uiteindelijk het renderen van de pagina.

Als je de ruimte hebt om 10 - 20 seconden over je antwoord te doen... ja dan is zo'n omgeving mogelijk overkill. Dan zou het misschien allemaal nog wel in SQL-storage gezeten met de ingebouwde full-text search of eventueel daar dan een plugin voor (sphinx in mysql bijvoorbeeld) :)

[Reactie gewijzigd door ACM op 16 november 2012 20:20]

Ik ga even selectief quoten:
Maar zulk soort aantallen kunnen wel degelijk behoorlijk veel blijken te zijn in een context waarvan je soms complexe resultaten (denk aan de facetten met aantallen van de overgebleven hoeveelheid resultaten in de pricewatch) moet zien te produceren in een voor het web acceptabele hoeveelheid tijd...
Valide punt. Zeker i.c.m. een "standaard" SQL backend voorzie ik hier wel de mogelijke problemen mee ja. NoSQL kan je hier zeker helpen, mits je geen bergen relaties nodig hebt.
En wij willen onze pagina's bij voorkeur binnen 100ms klaar hebben
Maar tegen welke prijs? Als je je code en / of omgeving beter kan onderhouden door in 2 seconden ipv 100ms klaar te zijn dan is dat naar mijn mening zeker wel een sterk argument. Hoeveel users zullen T.net niet meer gebruiken omdat ze iets langer moeten wachten? Tientallen? Honderd? Lijkt mij niet echt spannend als daar (veel) minder onderhoud tegenover staat.
met veel minder hardware [...] maar vandaag de dag kun je met een goed opgezette tiered technology stack denk ik hetzelfde bereiken met veel minder. Ik zit dan specifiek te denken aan een engine geschreven in een Python web-app framework, hosted via een wSGI server container, achter een nginx proxy, MongoDB+memcached voor je database.
Hoewel ik zeker geen tegenstander ben van Python denk ik dat je als bedrijf 2x (of misschien wel 3x) moet nadenken of Python wel de juiste route is.
Als hardware het probleem is, dan bel je HP, Dell of elke andere hardware fabrikant en krui je zo nieuwe spullen naar binnen.
Als mensen het probleem is, praktisch elke IT-er heeft JAVA (of .NET) kennis in huis, opleidingen zijn geen probleem en de talen zijn eenvoudig te begrijpen. Je trekt zo een blik JAVA of .NET specialisten open.

Met Python begeef je je echter op glad ijs. Bijna geen enkele IT-er heeft Python kennis, opleidingen zijn vaak introductiecursussen en de taal heeft een steile leercurve. De code zelf kan ook nog eens op allerlei manieren worden opgebouwd en is daarmee dus veel 'programmeur' afhankelijker.

Python is leuk als Google of ZZP-er, maar als Python je core-business ondersteunt neem je zeker een risico.
Python heeft helemaal geen stijle leercurve! De taal is in veel opzichten simpeler dan Java (zeg ik als Java gecertificeerde, die van beroep Java ontwikkelaar is). Ook begrijp ik niet helemaal waar jouw idee vandaan komt dat Python enkel gebruikt wordt bij Google of door ZZP-ers. Veel high-profile sites en/of services en ook apps en games zijn m.b.v. Python gemaakt: Yahoo Maps, Yahoo Groups, Instagram website, Eve Online, stukken van Battlefield 3 etc.
Python krijgt steeds meer tractie, ook binnen grote bedrijven, dus dat probleem zie ik niet echt. Ook omdat tweakers.net hun systeem zelf ontwikkelt en beheert.

Ik ben zelf niet erg gevoelig voor argumenten als 'er zijn veel meer Java ontwikkelaars en/of consultants', een beetje ontwikkelaar is flexibel genoeg om zichzelf vlot in te werken in elke ontwikkel taal-, en omgeving, als het onder de knie krijgen van zoiets als Python een groter probleem is dan het onder de knie krijgen van de business logic van het systeem zelf, dan praat je over een ontwikkelaar die ik zelf toch al liever niet aan mijn code zou laten werken. Je moet gewoon de beste tools voor de toepassing kiezen, en mensen die capabel genoeg zijn om zich snel in te werken. Heel het idee van zoiets als een Python web app framework is sowieso dat je zo min mogelijk code hoeft te kloppen, en minder code = minder kans op bugs, en minder complexiteit, dus makkelijker te onderhouden en uit te breiden. Als ik naar de ellende kijk die door de gemiddelde Java programmeurs bij ons op het werk wordt geschreven, dan wordt ik daar echt heel erg treurig van. Leuk dat je makkelijk aan 10 Java prutsers kan komen, maar als je die vervolgens 5 jaar nodig hebt om de troep die ze hebben geproduceerd draaiend te houden, terwijl 5 goede ontwikkelaars die zich in elke ontwikkelomgeving kunnen inwerken het in 1 jaar goed doen, dan weet ik wel wat er goedkoper is. Het probleem met Java ontwikkelaars is juist dat er zoveel van zijn waardoor de slechte het verpesten voor de goede, en dat de meeste matige Java ontwikkelaars helemaal gebrainwashed zijn om overal lagen van complexiteit te introduceren en alles in termen van architecturen en objecten te proberen te vatten, omdat dat nu eenmaal is wat ze geleerd hebben. Juist zoiets als een web applicatie kan heel erg gebaat zijn bij oplossingen die een hybride zijn van object-georiŽnteerd en functioneel programmeren.

Overigens hoef je nog niet eens van een Python framework uit te gaan, dat was slechts het meest voor de hand liggende voorbeeld waar momenteel ook de meeste nieuwe ontwikkeling aan moderne web technologie plaatsvindt. Met PHP, Ruby of node.js kun je ook hele mooie dingen maken, hoewel ik zelf van mening ben dat Python de meest gebalanceerde optie is voor web toepassingen.

[Reactie gewijzigd door johnbetonschaar op 16 november 2012 18:55]

Heel het idee van zoiets als een Python web app framework is sowieso dat je zo min mogelijk code hoeft te kloppen, en minder code = minder kans op bugs, en minder complexiteit,
Dat geldt niet altijd. Voor kleine scriptjes is Python leuk, maar zodra je een bepaalde grote bereikt wordt Python juist steeds minder snel om in te programmeren en op een gegeven moment wordt het juist flink langzamer.

Dit komt omdat in Python je niet weet welk type waar gebruikt wordt. Maak je een change, good luck dat niet in een of andere obscure functie hier een aanname over word gedaan die pas live ontdekt wordt als gebruiker X actie Y doet waar je nooit had bedacht een test voor te maken.

In Java pak je zulke dingen er VEEL sneller uit, zodat bij iets grotere software Java velen malen sneller werkt.

Vergeet ook niet dat Python traag is. Niet gewoon een beetje traag, nee, echt HEEL ERG traag. Sommige dingen die in C, C++, Java, C# of Scala een seconde kosten, hooguit twee seconde, kosten in Python makkelijk een minuut of meer.

Alweer, voor kleine scriptjes maakt dat niet uit. Voor een web app met veel visitors is dat killing.

En moet ik over de GIL beginnen in Python? Liever niet he, want je weet wel hoe laat het dan is...
Dit komt omdat in Python je niet weet welk type waar gebruikt wordt. Maak je een change, good luck dat niet in een of andere obscure functie hier een aanname over word gedaan die pas live ontdekt wordt als gebruiker X actie Y doet waar je nooit had bedacht een test voor te maken.
Dat heeft weinig te maken met het feit dat python een getypeerde taal is of niet, en meer over je programmeerstijl, discipline, en tests. Desnoods ga je defensief programmeren en assertions voor elke publieke functie hangen.
Blerghhh... daar gaat dan je zogenaamde winst in sneller programmeren :P
Ben het eens met je dat de architectuur zoals die er nu ligt wat complex is maar vooral ook ten koste gaat van de performance.

Zo zou ik persoonlijk nooit kiezen voor den REST interface voor interne communicatie. Een REST interface voor externe partijen is prima maar tussen je back en frontend juist niet. Zo blijf je vertalen. Eerst uit je database naar Java objecten (hopelijk via een orm) en daarna van java objecten weer naar je rest-formaat (JSON of XML) en daarna moet php weer je rest berichten parsen. Daarnaast krijg je, zoals het artikel ook al aangaf, enorm veel onderlinge koppelingen.

Waarom niet gewoon een complete Java oplossing. Zowel front als backend in Java en dan heb je al die problemen niet. Java kent genoeg prima frontend frameworks zoals Play die hier prima geschikt voor zijn en waarmee je heel snel frontends kunt ontwikkelen. Deze oplossing schaalt ook prima (zowel horizontaal als verticaal) en kent slecht 1 vertaalmoment bij het ophalen of opslaan van de data in je database.

Maar de oplossing die ik hier beschrijf kan ook prima in bv python of .net gerealiseerd worden.

@YopY: Tja, JSP. Dan heb je al aardig wat jaartjes geen Java frontend meer gedaan, neem ik aan. JSP was hell maar Play of Grails zijn super en werkt echt veel lekkerder dan PHP.

[Reactie gewijzigd door sys64738 op 20 november 2012 11:38]

Waarschijnlijk zijn ze niet voor een volledige rewrite gegaan vanwege de al grote bestaande PHP codebase. En eerlijk is eerlijk: front-end Java is verre van prettig, in mijn beperkte ervaring (JSP en co). Ik weet niet of bijv. Play dat iets prettiger gemaakt heeft ondertussen.
En eerlijk is eerlijk: front-end Java is verre van prettig, in mijn beperkte ervaring (JSP en co). Ik weet niet of bijv. Play dat iets prettiger gemaakt heeft ondertussen.
JavaServer Faces (JSF) heeft dat ondertussen een heel stuk prettiger gemaakt.

Dat komt met name door libraries die je met JSF gebruikt zoals PrimeFaces (components) en OmniFaces (soort Guave voor JSF).
Ik vind de nieuwe Pricewatch anders niet fijner werken.

Sorteren op criteria werkt alleen maar als je via het hoofd Pricewatch menu begint.

Begin je via de homepage, en zoek je dan via de "universal content bar", dan kom ik wel uit bij Dominator geheugen, maar op die pagina kan ik dan niet meer sorteren op criteria als "grootte", modules etc.

Wordt dit nog eens aangepakt?
Je zult in je klacht onderscheid moeten maken tussen de onderliggende techniek en de uiteindelijke inzet en presentatie ervan. Die laatste zijn waar je klachten over lijken te gaan (en alle andere die hier genoemd worden) terwijl dit artikel over de eerste gaat :)
Wat heb ik aan een uitstekende techniek als er minder mee kan dan vroeger met andere techniek?

Leuk hoor die productgroepen, maar echt handig? Nee.
Voor gebruikers is natuurlijk de presentatie en bruikbaarheid veel belangrijker, maar als dat dan ook nog eens gehinderd zou worden door beperkingen in de onderliggende techniek... dan wordt het alleen maar nog erger.
Het voordeel van een krachtige ondergrond hebben is dat we relatief eenvoudig aan de "buitenkant" kunnen sleutelen, zonder alles wat daar onder zit weer aan te moeten passen.

We zijn echt niet met de release van "tweakers 7" gestopt met bijschaven. Maar net als dat "tweakers 6" heel veel bijgeschaafd is in de loop de jaren, zal dat ook met 7 gebeuren. 't Feit dat we ondertussen alweer iets van 500 "tickets" opgelost hebben sinds de lancering onderschrijft dat alleen maar.

Sterker nog, ik ga er van uit dat als er een "tweakers 8" komt dat daar weer het hele bijschaaf-proces van voorafaan begint. En dat is niet omdat we er niks van leren, maar omdat de projecten van dusdanige grootte zijn dat zelfs uitvoerig testen lang niet alle verkeerde interpretaties van bezoekersgedrag en -voorkeuren zal vinden. En daarnaast worden er uiteraard ook altijd wel bugs gemaakt (niet dat we dat expres doen... maarja :/ )
Ik bedenk me dit nu pas trouwens: je klacht over "de nieuwe pricewatch" is onterecht. Het gedrag dat je beschrijft is namelijk niets anders dan met tweakers 6 al het geval was.

Toen kon je ook alleen maar op specificaties van producten filteren en sorteren als je via de categorie naar een lijstje producten was gegaan. Maar niet als je via de zoekbox bovenaan de pricewatch-portal ging.

De algemene zoekomgeving wordt ook aardig complex als we zouden proberen de specificaties van producten er tussen te stoppen. Wat doe je als er producten uit twee verschillende categorieen staan? Stel je zoekt op "sony" (en ja, mensen doen dat), verwacht je dan dat alle specificaties van Sony-producten bij elkaar staan of juist alleen degenen die gedeeld worden door alle producten. Waarbij in dat geval waarschijnlijk dus geen specificatiefilters overblijven... Hooguit iets als garantie.
Met jouw "dominator"-zoekopdracht gebeurt zelfs al zoiets, er staan naast geheugenmodules tenslotte ook een processorkoeler, een ventilator, drie games en iets uit de overclocking-categorie tussen...

Ik geloof dat er wel plannen zijn om dit beter te onderzoeken. Maar hoewel het een eenvoudig probleem is om te beschrijven ("er staan geen specificatiefilters") is het een vrij lastig probleem om op te lossen :)
Er missen inderdaad nog aardig wat criteria en soms zelfs product groepen (terwijl die producten wel in de pricewatch staan).

Hoop dat hier inderdaad nog verandering in gaat komen :)
Ze moeten bouwen wat ze willen als de gebruiker maar tevreden is over het resultaat. En hoewel de storm is gaan liggen heb ik nog niemand gehoord in mijn omgeving die tevreden is over de nieuwe site incl pricewatch.

De site zelf is dramatisch om te zien op een desktop pc en is puur gemaakt voor op een tablet of telefoon, helaas na een maand nog geen echte verbetering op dat punt gezien. Bij de pricewatch moet je tegenwoordig helemaal terug naar de hoofdpagina van pricewatch als je binnen een catogorie naar een andere wil.

Custom je site aanpassen vind ik geen optie, de hoofdsite moet al normaal bruikbaar zijn.

Wat gelukkig wel blijft zijn de vele relevante nieuwsitems maar helaas zie ik hier ook steeds meer een verschuiving naar zaken die weinig tot niets met it te maken hebben bv de witgoed afdeling in pricewatch, en de soms advertentieachtige artikelen zoals steeds vaker lijkt voor te komen vooral bij Apple en Samsung.
Wij zijn er in de T7 versie van de Pricewatch van uit gegaan dat een goede zoekfunctie een veel snellere en efficientere manier is om bij een product te komen is dan door een categorieboom klikken. Op elk punt in de Pricewatch kun je via de search direct naar een ander product of een andere categorie springen zonder via de homepage te gaan. Zo'n categorieboom is aardig als de structuur niet zo complex is maar het bleek af en toe behoorlijk lastig om obscure categorieŽn ergens kwijt te kunnen. Bovendien waren ook in die situatie veel productcategorieŽn niet direct vanaf de homepage toegankelijk: zo moest je maar net weten dat 'beamers & projectoren' als subcategorie was weggestopt onder 'overige randapparatuur' - en dat was uit de oude Pricewatch home op geen enkele manier af te leiden.

In de praktijk blijkt echter dat flink wat mensen zo gewend zijn aan het browsen door die boom - mede door de beroerde search in de oude site - dat het gebruiken van de search niet bij ze opkomt, of het bladeren op zich al prima beviel.

Wil je perse via een categorie bladeren dan is de huidige category browser in combinatie met het ontbreken van een echte breadcrumb inderdaad niet bepaald handig. De behoefte daaraan hebben we onderschat. We zijn aan het kijken of we een goede oplossing kunnen vinden om een categorieview terug te brengen. Probleem daarbij is dat de hoeveelheid categorieŽn nogal groot is (Pricewatch Unsorted geeft een aardige indicatie: http://tweakers.net/pricewatch/unsorted/) dus je krijgt een enorme lijst waarbij een groot deel standaard buiten beeld staat.
Gisteren zocht ik naar monitoren, staan die onder "Computers" of onder "Beeld en geluid"? De zoekfunctie werkt inderdaad heel makkelijk. Maar wat je als gebruiker niet verwacht is dat je daarmee ook naar categorieŽn kunt zoeken, daar kwam ik net pas achter. Je zou dit kunnen voorkomen door de hele zoekboom niet te tonen.
Blij te horen dat er aan de breadcrums gewerkt wordt deze vind ik erg waardevol in de PW.
En dat is dus precies het probleem: wanneer je met je muis aan het klikken bent, wil je niet even via je toetsenbord een categorie in het zoekvenster intoesten. Je wilt gewoon met je muis klikken.

Volgens mij is hier dus echt niet over nagedacht.....
dus omdat jij "te lui"ben om je toetsenbord te gebruiken moet tweakers dat maar mee nemen in hun idee over hoe ze een pricewatch beter kunnen laten werken? we kunnen misschien ook gewoon vaker de poging proberen te nemen om onze gewenning een beetje aan de kant te gooien ipv alleen maar alles af te kraken.
quote: Wij zijn er in de T7 versie van de Pricewatch van uit gegaan...

Hmm, je weet toch wel dat elke aanname het begin van alle ellende is... ;)

Persoonlijk vind ik het (nog) geen verbetering, ik geeft het nog even de tijd.
Is er ergens de optie om de oude layout terug te zetten dat zou ik erg fijn vinden.
Leuk om te lezen hoe jullie tot een architectuur plaatje gekomen zijn.

Zelf het afgelopen jaar een framework ontworpen en gebouwd op basis van cassandra en elastic search en herken zeker wel een aantal van de limitaties die m.b.t. genoemde producten genoemd worden. Eerst gebruikten we solr maar daar worden de queries trager als er gelijktijdig ook een index wordt geupdate. Elastic search heeft hier minder last van.

Hebben jullie i.p.v. activemq (Waarom niet RabbitMQ ;) ) ook overwogen om Hazelcast of Terracotta te gebruiken om cached objecten over de verschillend jvms te delen?
't Informeren gebeurt vanuit PHP naar Java, dus een puur-java oplossing voor synchronisatie is niet heel zinvol dan :)

Op zich is iets als Terracotta wel interessant zodra het buiten de reikwijdte van 1 machine gaat, maar de totale actieve dataset waarmee gewerkt wordt zit onder rond de 3GB. Dus dan zijn inspanningen voor een "extra grote VM" wat overbodig :)
't Informeren gebeurt vanuit PHP naar Java,
Misschien een stomme vraag, maar waarom op termijn dan ook niet voor de web layer Java gebruiken?

Je hebt het nagenoeg identieke JSP (html markup met fragmenten code ertussen), of heel goede meer high-level frameworks zoals bijvoorbeeld JSF (JavaServer Faces).
Er zijn diverse redenen voor op te noemen, ik zie het in ieder geval niet gebeuren. Denk aan:
- Het is enorm veel werk, we komen in de buurt van de 400k regels php-code...
- We hebben nog steeds meer php-kennis in huis dan java (en zeker dan jsp en de frameworks voor de presentatielaag)
- Het biedt weinig meerwaarde, het brengt eventueel die back- en frontend dichter bij elkaar, maar een scheiding in dergelijke verantwoordelijkheden is alsnog geen gek idee.

En dat dus verder nog afgezien van eventuele voorkeuren voor het ene of het andere platform en/of nadelen vs voordelen die met het platform samenhangen.

Dus kortweg: het biedt in mijn ogen domweg te weinig voordelen ten op zichte van de inspanning en kosten die ervoor zijn vereist. Alle voordelen zullen bijna automatisch in het niet vallen tegen het nadeel van een rewrite van de complete code-base naar java/jsp...

[Reactie gewijzigd door ACM op 17 november 2012 10:51]

Ik snap de nadelen en dan met name de hoeveelheid werk die natuurlijk aanzienlijk is. Het lijkt me ook niet realistisch om in 1 klap de hele frontend/weblayer te gaan herschrijven, maar stukje voor stukje is er een hoop mogelijk.

Qua de kennis moet je natuurlijk ook niet vergeten dat je nu een hele back-end in Java hebt, dus dat de kennis van Java steeds verder zal toenemen.
een scheiding in dergelijke verantwoordelijkheden is alsnog geen gek idee.
Het klinkt ook als een goed idee, maar bedenk wel dat ook bij het gebruik van dezelfde taal deze scheiding te realiseren is. De voordelen van een gemeenschappelijk taal is wel dat het uitwisselen van programmeurs tussen beide lagen makkelijker maakt, en dat het ook code re-use (bedenkt models/entities die je nu op 2 plekken defineert waarschijnlijk) makkelijker maakt.

Nu hoeft zeker niet altijd een applicatie volledig op 1 platform te draaien. Als er echt redenen zijn dat 1 onderdeel in een andere taal is omdat die taal beter is voor dat onderdeel, dan is het natuurlijk een goede keuze.

Echter, PHP is niet noodzakelijkerwijs 'beter'. Het is alleen een toevallige (legacy) situatie.

Persoonlijk heb ik bij een aantal projecten ook deze setup gezien, en het veroorzaakte toch problemen en spanningen. Misschien dat het bij jullie wel goed gaat, maar just my 2 cents ;)
Waarom nog steeds Apache, alles wijst tegenwoordig naar Nginx vooral als je goed wilt cachen en zeker voor grote websites.

Ik moet zeggen dat wij voor een Applicatie ook Java gebruiken qua server-side kant en dat gaat uitstekend. Voor mij is Java iig geen rare keuze.
In onze ervaring is de combinatie van Apache + PHP nog altijd aanzienlijk krachtiger dan Nginx + "allerlei lijmwerk" + php. En bovendien... het caching-deel (en dus de statische resources) hebben we al helemaal uitbesteedt aan Varnish, dus uiteindelijk blijven alleen de pure php-requests over voor de webservers.
In onze benchmarks was Apache daar zelfs sneller mee dan Nginx.
Verder scheelt het in gebruik houden van Apache dat we onze jarenlange ervaring en op maat gemaakte configuraties niet hoeven te herschrijven naar Nginx zonder dat het echt noemenswaardige voordelen heeft.

Kortom: Apache is gewoon behoorlijk stabiel en erg flexibel zonder door allerlei hoepels te hoeven springen om met PHP te mogen werken. Dat laatste is iets dat (tot voor kort?) met Nginx zeker nog wel het geval was/is.
Goede argumenten!
Waarom maken jullie niet (delen) hiervan open source/community based? Ik denk dat er erg veel tweakers zijn die, in ruil voor een mooie badge naast hun naam, graag hun steentje bijdragen aan een beter Tweakers
Ook dit is een van die vragen die we vaker terugzien :)

Het OS maken van (delen van) de software van Tweakers is een ingewikkelde situatie met erg veel afwegingen om te maken. Er zijn tenslotte allerlei commerciele belangen naast de belangen van de community.
Daarnaast vereist het ook nog een aanzienlijke inspanning van het bedrijf en dan vooral de developers eracher.

Commercieel gezien werkt OS natuurlijk vooral als het niet (het deel van) de software is waar je je geld door verdient, danwel als je software je niet op voorsprong zet ten op zichte van de concurrentie.
Vanuit het perspectief van een website: de gegevens achter je website moeten - bij voorkeur samen met de bezoekers/community - zo'n unieke formule opleveren, dat niemand met dezelfde software jouw positie noemenswaardig in gevaar kan brengen. Bijvoorbeeld door een directe concurrent van je te worden of als bestaande concurrent het product te verbeteren.

Hoewel er allerlei stukken software binnen tweakers geschreven zijn die daaraan voldoen, denk ik dat we juist met de pricewatch toch wel moeten oppassen... Voorbeeld van delen die daar beter op aansluiten zijn bijvoorbeeld forumsoftware en een reactiesysteem. Dat zie je dan ook op het internet, Reddit en Slashdot zijn gebaseerd op open source websitesoftware. Maar ik denk niet dat er veel concurrenten zullen zijn ontstaan door simpelweg dezelfde software ergens anders op te starten. En reeds bestaande concurrenten hebben doorgaans al vergelijkbare software in gebruik of bezoekers die het niet erg vinden dat het wat anders werkt.

Maar naast commerciele belangen zijn er ook nog andere dingen om mee op te passen. Zodra je commiters toelaat moet je sowieso alle commits die binnenkomen nakijken. In een perfecte wereld zou natuurlijk elke commit aan je eigen kwaliteitsstandaarden voldoen, maar in werkelijkheid valt dat waarschijnlijk tegen. Sowieso loop je een risico dat een externe committer bij zijn commit helemaal niet stil gestaan heeft bij gevolgen elders in de code.
Denk aan een wijziging in css waarbij ineens op een ander deel van de site een tabel ineens heel lelijk wordt.
Verder verwacht ik dat een OS-traject alleen succesvol wordt als we ook daadwerkelijk tijd hebben om de commits te verwerken in de productie-site. Als we er geen tijd voor hebben of alleen maar commits binnen krijgen waar we niet op zitten te wachten - en dus afwijzen - zullen de committers snel geirriteerd raken.
Dat betekent in ieder geval dat de commits relatief eenvoudig voor de committer en bezoekers zichtbaar moeten worden. Deze Engine is nou niet bepaald een zichtbaar deel. Sterker nog, om er uberhaupt wat mee te kunnen heb je zowel een goed gevulde database als een zinvolle frontend nodig...
Van alle bugs die gemeld worden zit dan ook het merendeel juist niet in deze code, hooguit in er tegenaan liggende php-code voor de verwerking van resultaten. Maar vaak nog wat laagjes/stapjes ervandaan.

Kortom: ik denk niet dat met name dit project in ons belang is (commercieel gezien) om aan de wereld vrij te geven. Verder heeft dit deel zodanige afhankelijkheden dat we veel moeite moeten steken in een testfrontend danwel (delen van) onze huidige frontend ook vrij moeten geven en vooral dat we ook een forse testdataset moeten gaan aanbieden.

Daarnaast durf ik persoonlijk in ieder geval niet te garanderen dat we de tijd hebben (of van ons management mogen maken) om naar commits te kijken, vragen te beantwoorden, bugfixes te testen en naar de nieuw geintroduceerde bugs te zoeken... Het is natuurlijk maar sterk de vraag of die tijd opweegt tegen domweg zelf met de code bezig zijn :P

[Reactie gewijzigd door ACM op 18 november 2012 11:57]

Bovendien was MySQL 5.1 in die tijd net uit, wat betekent dat we nog op 5.0 draaiden en die stond niet bekend om zijn performance met complexe queries en queries met subqueries
Waarom dan niet een DB-platform gebruiken dat daar wel goed mee om kan gaan?
Ik denk omdat je anders dan de hele site kan verbouwen voor zoiets, omdat een groot deel van Tweakers op MySQL draait. Niet een geweldige goede oplossing.

[Reactie gewijzigd door AW_Bos op 16 november 2012 14:19]

Dat probleem heb je alleen als je geen abstractielaag tussen de data access en de DBMS (MySql in dit geval) hebt geplaatst. Ik mag hopen dat ze in hun Java-engine niet SQL (nog nog erger: MySQL specifieke instructies) gebruiken om tegen MySql te praten. Dat is toch niet echt een net design...
Zodra je een beetje geavanceerde SQL-features wilt gebruiken (denk aan dingen als recursieve queries) zul je zelfs met een abstractielaag toch snel op database-specifieke SQL uitkomen.

Dat kun je wel een lelijk ontwerp vinden, maar in omgevingen waar performance (en/of andere eigenschappen die je met database-specifieke SQL beter kunt behalen dan zonder) belangrijk is kan het toch een goede keus zijn dat te gebruiken.
Zolang je geen dynamische queries (lees: opbouwen vanuit code) gebruikt, kun je deze prima wegmoffelen achter een stored procedure. Daardoor heb je geen specifieke (My)SQL code in je back-end staan, waardoor je net even wat losser tegen je database implementatie aan leunt. Het wordt er ook iets wat sneller op doordat niet telkens de query hoeft te worden overgebracht naar de database server.
Onze code en toepassing van MySQL is van voor dat ze stored procedures ondersteunden... we hebben daarbij domweg teveel code om zomaar even over te stappen op een compleet andere manier van werken.
Dat zou uiteraard gradueel kunnen, maar ik ben niet echt een fan van het in de database opslaan van functionaliteit (wat SP's effectief zijn), die scheiding bijt je altijd wel ergens weer (het niet scheiden natuurlijk ook).
Met ACM. Daarbij komt nog dat SPs vanuit het oogpunt van versiebeheer en deployen/rollbacken van functionaliteit een hell zijn. Ik heb ze in een grijs verleden weleens gebruikt (lees: misbruikt), maar ben daar keihard van teruggekomen.
Hoezo is versiebeheer een hell? Uiteindelijk is het gewoon plain text en dat kun je prima in versiebeheer zetten.

rollback is ook prima te doen, mits je een database gebruikt die transactional DDL ondersteunt. Dan kun je namelijk ook je verificatie tests binnen de transactie (dus deployment) opnemen en afhankelijk van de resultaten een commit of rollback uitvoeren.

MySQL kent deze opties niet, maar in PostgreSQL (of bv. Oracle) is het geen enkel probleem.

Wij doen niet anders en beheren hier een database van een paar TB met ongeveer een miljoen unieke bezoekers per dag, ~800 transacties per seconde, goed voor ~20.000 (eenvoudige en zeer complexe) queries per seconde. High performance is hier het allerbelangrijkste, dat is ook de reden dat we voor stored procedures hebben gekozen: logica hťťl dicht op data zodat er zo min mogelijk data uitgewisseld hoeft te worden. En dat werkt, gemiddelde tijd per transactie (die dus meerdere queries bevat) is minder dan 10ms, ondanks dat we ~200 concurrent users van data moeten voorzien. Stored procedures kunnen dus prima werken.
Wat recursive queries betreft, dit kan MySQL juist niet dus dit is eigenlijk een gek voorbeeld, maar ik snap wat je bedoelt :)

Wat ik in mijn post als reactie aan BlackHawkDesign al aangeef, ook al gebruik je DBMS specifieke SQL-instructies of features, dan kan een abstractielaag als Hibernate hier alsnog bij helpen.
Volgens mij inderdaad door de history, het is ooit begonnen met PHP en dan ga je inderdaad niet een volledige website opnieuw opbouwen. Zeker niet een site van deze omvang.
Als ze toendertijd ANSI-SQL in de PHP laag gebruikte en dus geen DBMS specifieke SQL-instructies, zou hier eenvoudig een abstractielaag tussen kunnen worden gezet.

In het geval dat ze SQL-instructies van MySQL hadden gebruikt, zullen andere DBMS'n met dezelfde doelgroep ook deze functionaliteit beschikbaar hebben gehad. Een voorbeeld is de SQL instructie "TOP" van Microsoft Sql Server en "LIMIT" van MySQL:
dba.stackexchange.com/questions/1115/top-x-of-sql-server-in-mysql-analog

Om dit te voorkomen kon bijvoorbeeld Hibernate worden gebruikt:
http://en.wikipedia.org/wiki/Hibernate_(Java)
Waarom dan niet een DB-platform gebruiken dat daar wel goed mee om kan gaan?
De andere genoemde redenen gelden voor andere databases net zo lijkt me: erg veel data met erg veel condities met SQL bij elkaar harken is gewoon niet zo efficiŽnt.

(los daarvan zijn er natuurlijk nog steeds wel goede redenen te bedenken om een andere database te gebruiken)
De andere genoemde redenen gelden voor andere databases net zo lijkt me: erg veel data met erg veel condities met SQL bij elkaar harken is gewoon niet zo efficiŽnt.
Daarom is er ook een markt voor een speciaal soort database dat specialiseert in de zogenaamde faceted search.

Endeca (nu aangekocht door Oracle) is er zo een. Veel van de sites die wij afleveren binnen de reisbranche draaien hun zoeksysteem daar op en dat zijn zeker geen kleine databases.
Voor de mensen die Java-twijfels hebben en uit de PHP-hoek komen, misschien is het interessant om eens te kijken naar SpringSource Grails, onder de motorkap wordt Spring MVC en Hibernate gebruikt, is Jetty als servlet-engine geintegreerd en aan de achterkant kun je in puur Java/Groovy ontwikkelen. Dit maakt de overstap naar de Java/Spring/Hibernate-taal erg interessant voor mensen die nieuwsgierig zijn, maar denken dat het allemaal 'eng' is in Java. Grails bewijst het tegendeel. Zie www.grails.org. In combinatie met de InteliJ IDE is dit erg productief.

[Reactie gewijzigd door Tjeerd op 16 november 2012 16:29]

Hibernate is leuk maar een erg zwaar systeem. Backends wil je zo veel mogelijk clean houden.
Het probleem en verhaal dat Hibernate slecht zou presteren is maar deels waar, het is wel belangrijk om een goed genormaliseerd datamodel te hebben. Verder kun je kiezen om alles over te laten aan Hibernate of om queries zelf te schrijven. Je kunt daar zelf een balans in zoeken. Momenteel zit ik bij een bedrijf waar alles lowlevel in JDBC en insertqueries gebeurt en handmatig verbindingen worden opgebouwd en gesloten. Dat werkt prima, maar het kost zoveel extra tijd en verhoogt de kans op transactieproblemen, verbindingen die niet goed worden afgesloten enzovoorts. Lazy (geen relaties van records ophalen) en eager fetching (wel kinderen/gerelateerde records ophalen) is wel iets om mee uit te kijken bij Hibernate omdat het nogal gulzig data kan gaan ophalen. Daarbij het feit dat een taal als Grails dynamic finders heeft, zodat je data ophaalt dmv User.getByName(...), zonder dat je een regel SQL hoeft te schrijven. Resultaat is dat het gemiddelde bedrijf heel snel wat op poten heeft gezet.

@ACM: JdbcTemplate is een prima stuk techniek uit Spring om mee te werken idd, als je geen Hibernate (ORM) wil gebruiken.

[Reactie gewijzigd door Tjeerd op 17 november 2012 09:37]

Er zijn uiteraard allerlei mates van ingewikkeldheid. Omdat wij SQL zelf al hadden afgeschreven voor dit project (in de tijd dat we de SQL nog vanuit php uitvoerden) werden de benodigde queries ineens vrij simpel. Maar wel een vrij belangrijke eis werd dat objecten efficient in geheugen moesten kunnen blijven.

Hoedanook, uiteindelijk gebruiken wij Spring's (Simple)JdbcTemplate's om het gros van de Pooling- en JDBC-overhead voor ons af te handelen, maar schrijven we wel zelf de paar SQL-statements en de bijbehorende RowMappers. Dat gaat dan in de orde van 1 a 2 queries per objecttype, vaak alleen een "fetch all"-equivalent om bij het opstarten het geheugen te vullen, soms een "get all modified since"-statement en verder nog een "get by id"-query om de vernieuwde data op te halen.
Dat kan vast ook in Hibernate, maar zodra je van CRUD alleen maar de R nodig hebt is het uiteindelijk misschien wel minder werk om domweg zelf je queries te schrijven dan om via Hibernate alle mappings te moeten regelen :P
Onzin. Als je het goed configureert is Hibernate echt niet zwaar hoor.
- Afhankelijkheid
- Ondersteuning
- 1+N
- Minder controle op collections
- enz

Om een pakket te implementeren zeker op schalen zoals hier op Tweakers.net zal ik wel 10x nadenken om zo'n pakket te implementeren.
Interesant (voor mij) om is wat meer te weten over de techniek achter tweakers.net. Ook zullen er hopelijk wat mensen de omzet nu beter begrijpen. Artikel was voor mij wat te technisch (geen enkele java kennis hiero!) maar zoals aangehaald is het wel is leuk om te zien hoe het er achter de schermen aan toe gaat, voor mij als normale gebruiker.

Hopelijk zullen mensen nu ook wat beter begrijpen wat de beweegredenen waren voor t.net. Dat scheelt vaak veel in kritiek en commentaar.

En nu we het er toch over hebben, wanneer gaat al dat wit weg? :+

Edit:spelfoutje

[Reactie gewijzigd door Postius op 16 november 2012 14:07]

Dat kan je al aanpassen hoor, rechts boven in twee de icon
Volgens mij wordt er bedoeld dat er behalve een klein veld bovenin de website wat van licht naar donker (en andersom) kan worden veranderd, de hoeveelheid wit tussen de nieuwsberichten op de frontpage, in de nieuwsberichten zelf en de comments het wit niet aan te passen is van licht naar donker.
Zelfs op z'n donkerst is de site nog te wit. Het doet gewoon pijn aan je ogen.
Een deel van je comentaar slaat natuurlijk nergens op.

Wanneer er software matig verkeerde keuzes gemaakt worden (zoals bv bij de nieuwe tNet waar nog niks aan gedaan is) dan moet je niet de techniek de schuld geven. Er zijn (gezien alle reacties) fouten gemaakt.

Daarbij vind ik deze artiekelen zeker interessant en ik hoop dat er meer van dit soort artiekelen komen. Daarvoor leest de "oude" tweaker toch tweakers.
@ wimdezoveelste.
Om jou gerust te stellen, dat wit gaat voorlopig niet weg.
Als ik naar T7 kijk, heb ik het idee dat het een beetje voor portable devices is gemaakt/geoptimaliseerd.
Pak maar een TFT panel en zet er geen data op maar wel CCFL (verlichting) dan zul je zien dat je scherm wit is.
Toch wel slim bekeken, houdt je accu het misschien wel tien minuten langer vol...

[Reactie gewijzigd door Murdy op 16 november 2012 22:57]

Ik stoor me totaal niet aan het wit. Het ziet er juist fris uit.
Ik stoor me er dus wel aan, hoop dat ze hier snel iets aan gaan doen....
Er is toch al een nieuwe slider voor de side-bars van de site en een "padding" slider om meer text / cm^2 op je beeld te krijgen?

Persoonlijk zou ik nog wel meer tekst in beeld willen, nu is ongeveer 1/3 van het scherm in gebruik bij mij, dat mag best 1/2e worden. Ook het grijs is nu op z'n donkerst nog nťt niet donker genoeg.

Wel typisch trouwens, ik klik op een link over T.nets backend, en ik krijg tot 2x toe:

Ooops
Er ging iets mis met het ophalen van deze pagina, probeer het zo nog een keer. (503 Service Unavailable 42065847)
:+
Ok, ik heb die optie net pas gevindt, wist nog niet dat die optie er was, bedankt voor de tip :)
Zou het niet mogelijk zijn dat je bij de pricewatch een bestellijst kan ingeven

(bv voor camer'a een specifieke lens + een specifieke body, en nog wat accesoires
of vr computers een behuizing + geheugen + moederbord + ...)

en dat de pricewatch de goedkoopste leverancier vindt voor het volledige lijstje, want nu moet je het soms bij tien firma's bestellen.

"t is maar een idee...
Dit is al mogelijk, je kunt een wensenlijst opstellen en daar kiezen bij hoeveel leveranciers je wilt bestellen.

OT: zeker interessant om dit te lezen, lijkt me prettig als het forum geintegreerd wordt in de zoekresultaten.
Hoe zou dit hebben uitgepakt met C++ ipv java. En gebruik van linux piping (stdin / stdout) in plaats van http?
Je bent 2 keer zo lang met de integratie bezig en wint er niks aan.
Waarom zou je daar twee keer zo lang over doen?

Op dit item kan niet meer gereageerd worden.



HTC One (M9) Samsung Galaxy S6 Grand Theft Auto V Microsoft Windows 10 Apple iPad Air 2 FIFA 15 Motorola Nexus 6 Apple iPhone 6

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True