Tweakers 7: waarom een eigen Java-back-end?
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.
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 
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.
Inhoudsopgave
Reacties (127)
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
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 vrijdag 16 november 2012 14:07]
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)
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...
(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.
OT: zeker interessant om dit te lezen, lijkt me prettig als het forum geintegreerd wordt in de zoekresultaten.
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.
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...
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 vrijdag 16 november 2012 22:57]
Java? Een ASP.NET backend was beter geweest 
Is ASP.NET niet voor de frontend? 
Niet specifiek, met ASP.NET kan je ook simpel api/services bouwen. Dus ze hadden daar ook voor kunnen kiezen, alleen in dit geval is Java een logische keuze (platform, database e.d.)
[Reactie gewijzigd door BlackHawkDesign op vrijdag 16 november 2012 14:35]
ASP.NET is inprincipe gewoon .NET draaiend bovenop IIS. Je hebt wel gewoon toegang tot het gehele .NET framework. Maar ja, als je Linux servers hebt kan je beter Java gebruiken. Vandaar de
[Reactie gewijzigd door sanderev66 op vrijdag 16 november 2012 15:16]
Nee hoor. .NET kan je ook gebruiken i.c.m. een MySQL database.
Veel alternatieven beloven een betere productiviteit dan Java, maar als je het gebruik van een goede IDE meerekent, zijn de productiviteitsvoordelen van het alternatieve platform dan nog relevant? Doelt dit nu op ontwikkelkosten, dan; moeilijke vraag. Geen inzicht in jullie budget. Doelt dit op het functioneren/prestaties van je applicatie dan; hell yeah!?
Een groot deel van het typewerk dat je in Java meer moet doen dan in andere platforms op de JVM valt immers weg door allerlei gradaties van autocompletion, code generation en short-keys. Denk daarbij aan het automatisch genereren van getters en setters, en het automatisch plaatsen van import-statements op het moment dat je het voorstel van de autocompletion accepteert. Of te wel, er is onder andere voor Java gekozen omdat er geen goede IDE beschikbaar was voor andere talen? Visual Studio 2008 was toen ook al beschikbaar met alle beschikbare add-ons
Wat ons betreft was Java destijds een prima keus. Sterker, als we nu opnieuw moesten beginnen zou Java alsnog veel kans maken. We hebben nu eenmaal Java-kennis in huis en het is een uitgebreid platform met een scala aan bibliotheken en tools. Denk bijvoorbeeld aan de uitgebreide ide's en profilers die voor Java bestaan. Zijn er vergelijkbare tools voor de alternatieve platforms?
Het hele artikel had een stuk korter kunnen zijn als je deze regel meteen had opgenomen. Of anders samengevat: Het ontwikkelen van Tweakers was veel duurder geweest wanneer we het NIET voor, op Java gebaseerde technologieën hadden gekozen. De reden hiervan is dat de R&D voor alternatieve, inclusief de aanschaf voor ondersteunende programmatuur (hint Visual Studio) en personeel die de omschakeling (bijvoorbeeld naar .NET) zoude willen maken (kom, geef maar toe
) zo veel geld had gekost dat we meer reclame op de site moesten dumpen om het geheel betaalbaar te houden. En dat hadden jullie de lezers weer niet fijn gevonden.
Wat ik helemaal vergeten ben te vermelden. Ondanks de wat vage conclusie vind ik het een interessant artikel. En de developers mogen wel een veer in hun hoed gestoken worden voor het werk wat ze leveren.
Overigens begrijp ik de kritiek die er vanuit de opensource community op Microsoft is wel. Visual Studio is verre van gratis, tenzij je de expres versie gebruikt. Die is alleen een beetje uitgekleed en moet je twee aparte instanties installeren wil je het werk kunnen doen wat de developers van Tweakers moeten verrichten. 1-0 voor de opensource community als je VS al vergelijkt met een IDE als Netbeans. Namelijk 638euro voor de simpelste VS versie tegenover de al jaren gratis verkrijgbare, Netbeans, Eclipse, Mono, vul de andere maar in. Het geld issue zal waarschijnlijk voor Femme (sorry als ik andere original crew vergeet te vermelden) ten tijden van de oprichting van Tweakers.net hebben meegespeeld. Vergeet even niet aan wie we dit alles hebben te danken
De rechtstreekse 2-0 die enkele minuten later volgt is dat softwareprojecten waar in dit
artikel naar gerefereerd worden veelal een oorsprong hebben in een door professionele hobbyisten ontwikkelde technology stacks. Bij mijn weten is de Apache groep een van de grootste initiatieven. En wederom allemaal gratis te her gebruiken maar vooral: Uitbreidbaar (mits je echt kan programmeren). Daarbij mag je al sinds jaar en dag bijdragen aan hun projecten. Dat kreeg je als buitenstaander voor twee jaar geleden nog niet zo eenvoudig voor elkaar bij Microsoft. Pas korte tijd accepteerd Microsoft meer vanuit de community waar ze overigens ook gretig gebruik van maken.
Dus ik snap de afkeer tegen Microsoft wel. Ik vind het geen wat ik van de Microsoft Technologie stack gebruik fijn werken en voorlopig zie ik even geen reden om over te stappen naar een alternatief. Maar mocht in de toekomst zich een baan aanbieden die dat vereist ben ik er zeker niet blind voor.
Veel alternatieven beloven een betere productiviteit dan Java, maar als je het gebruik van een goede IDE meerekent, zijn de productiviteitsvoordelen van het alternatieve platform dan nog relevant? Doelt dit nu op ontwikkelkosten, dan; moeilijke vraag. Geen inzicht in jullie budget. Doelt dit op het functioneren/prestaties van je applicatie dan; hell yeah!?
Een groot deel van het typewerk dat je in Java meer moet doen dan in andere platforms op de JVM valt immers weg door allerlei gradaties van autocompletion, code generation en short-keys. Denk daarbij aan het automatisch genereren van getters en setters, en het automatisch plaatsen van import-statements op het moment dat je het voorstel van de autocompletion accepteert. Of te wel, er is onder andere voor Java gekozen omdat er geen goede IDE beschikbaar was voor andere talen? Visual Studio 2008 was toen ook al beschikbaar met alle beschikbare add-ons
Wat ons betreft was Java destijds een prima keus. Sterker, als we nu opnieuw moesten beginnen zou Java alsnog veel kans maken. We hebben nu eenmaal Java-kennis in huis en het is een uitgebreid platform met een scala aan bibliotheken en tools. Denk bijvoorbeeld aan de uitgebreide ide's en profilers die voor Java bestaan. Zijn er vergelijkbare tools voor de alternatieve platforms?
Het hele artikel had een stuk korter kunnen zijn als je deze regel meteen had opgenomen. Of anders samengevat: Het ontwikkelen van Tweakers was veel duurder geweest wanneer we het NIET voor, op Java gebaseerde technologieën hadden gekozen. De reden hiervan is dat de R&D voor alternatieve, inclusief de aanschaf voor ondersteunende programmatuur (hint Visual Studio) en personeel die de omschakeling (bijvoorbeeld naar .NET) zoude willen maken (kom, geef maar toe
) zo veel geld had gekost dat we meer reclame op de site moesten dumpen om het geheel betaalbaar te houden. En dat hadden jullie de lezers weer niet fijn gevonden.Wat ik helemaal vergeten ben te vermelden. Ondanks de wat vage conclusie vind ik het een interessant artikel. En de developers mogen wel een veer in hun hoed gestoken worden voor het werk wat ze leveren.
Overigens begrijp ik de kritiek die er vanuit de opensource community op Microsoft is wel. Visual Studio is verre van gratis, tenzij je de expres versie gebruikt. Die is alleen een beetje uitgekleed en moet je twee aparte instanties installeren wil je het werk kunnen doen wat de developers van Tweakers moeten verrichten. 1-0 voor de opensource community als je VS al vergelijkt met een IDE als Netbeans. Namelijk 638euro voor de simpelste VS versie tegenover de al jaren gratis verkrijgbare, Netbeans, Eclipse, Mono, vul de andere maar in. Het geld issue zal waarschijnlijk voor Femme (sorry als ik andere original crew vergeet te vermelden) ten tijden van de oprichting van Tweakers.net hebben meegespeeld. Vergeet even niet aan wie we dit alles hebben te danken
De rechtstreekse 2-0 die enkele minuten later volgt is dat softwareprojecten waar in dit
artikel naar gerefereerd worden veelal een oorsprong hebben in een door professionele hobbyisten ontwikkelde technology stacks. Bij mijn weten is de Apache groep een van de grootste initiatieven. En wederom allemaal gratis te her gebruiken maar vooral: Uitbreidbaar (mits je echt kan programmeren). Daarbij mag je al sinds jaar en dag bijdragen aan hun projecten. Dat kreeg je als buitenstaander voor twee jaar geleden nog niet zo eenvoudig voor elkaar bij Microsoft. Pas korte tijd accepteerd Microsoft meer vanuit de community waar ze overigens ook gretig gebruik van maken.
Dus ik snap de afkeer tegen Microsoft wel. Ik vind het geen wat ik van de Microsoft Technologie stack gebruik fijn werken en voorlopig zie ik even geen reden om over te stappen naar een alternatief. Maar mocht in de toekomst zich een baan aanbieden die dat vereist ben ik er zeker niet blind voor.
[Reactie gewijzigd door theike op vrijdag 16 november 2012 20:23]
Je hebt een sterk punt vind ik, al zal die beslissing niet (geheel, vermoed ik) op financiele gronden genomen zijn. Er heerst, zover ik weet (en ik weet niet zo veel), bij bepaalde mensen binnen tweakers een afkeer tegen Microsoft (producten).
Ook zijn er veel tweakers die zouden gaan stuiteren als er ineens voor MS producten wordt gekozen.
Daarnaast is (zoals in het artikel vermeld wordt) gekozen voor in-house kennis, en dat ligt niet bij .NET en IIS maar bij Tomcat en Linux. En daarmee bedoel ik het "gemak" ipv het financieel "gewin".
Ook zijn er veel tweakers die zouden gaan stuiteren als er ineens voor MS producten wordt gekozen.
Daarnaast is (zoals in het artikel vermeld wordt) gekozen voor in-house kennis, en dat ligt niet bij .NET en IIS maar bij Tomcat en Linux. En daarmee bedoel ik het "gemak" ipv het financieel "gewin".
[Reactie gewijzigd door Razwer op vrijdag 16 november 2012 19:37]
We hebben op zich niet een afkeer van Microsoft.
Maar we gaan niet even ons complete serverpark omzetten van Linux naar Windows, alleen maar zodat we dan .NET kunnen draaien... Dat is naast aardig prijzig ook domweg heel erg veel werk.
Dan is een Java-omgeving erbij draaien een stuk eenvoudiger, dat kan op dezelfde of vergelijkbare Linux-machines (met) die we al hebben en houdt ook het beheer een stuk eenvoudiger.
Bovendien hebben we domweg geen .NET-kennis in huis. Hoewel er altijd gezegd wordt dat een goede programmeur zich in elke taal in moet kunnen werken is het wat mij betreft een mythe dat dat ook gelijk hetzelfde niveau oplevert als dat een ander platform dat je wel al kent. In mijn geval heb ik veel ervaring met PHP en Java, maar zou ik voor een vergelijkbare applicatie (het php-deel of java-deel) in .NET toch eerst wel flink wat kennis moeten opdoen. Puur qua code en opzet hoeft het dan nog niet eens zoveel te verschillen...
En daar komt dan nog de leercurve voor een effcient werkende IIS met .NET, terwijl we al een vlot draaiende LAMP-stack (nouja, aangevuld me een varnish, een extra activemq, nog een mongodb en een voor memcached en dus een tomcat
) hadden.
Maar we gaan niet even ons complete serverpark omzetten van Linux naar Windows, alleen maar zodat we dan .NET kunnen draaien... Dat is naast aardig prijzig ook domweg heel erg veel werk.
Dan is een Java-omgeving erbij draaien een stuk eenvoudiger, dat kan op dezelfde of vergelijkbare Linux-machines (met) die we al hebben en houdt ook het beheer een stuk eenvoudiger.
Bovendien hebben we domweg geen .NET-kennis in huis. Hoewel er altijd gezegd wordt dat een goede programmeur zich in elke taal in moet kunnen werken is het wat mij betreft een mythe dat dat ook gelijk hetzelfde niveau oplevert als dat een ander platform dat je wel al kent. In mijn geval heb ik veel ervaring met PHP en Java, maar zou ik voor een vergelijkbare applicatie (het php-deel of java-deel) in .NET toch eerst wel flink wat kennis moeten opdoen. Puur qua code en opzet hoeft het dan nog niet eens zoveel te verschillen...
En daar komt dan nog de leercurve voor een effcient werkende IIS met .NET, terwijl we al een vlot draaiende LAMP-stack (nouja, aangevuld me een varnish, een extra activemq, nog een mongodb en een voor memcached en dus een tomcat
) hadden.[Reactie gewijzigd door ACM op vrijdag 16 november 2012 22:46]
Java / ASP.NET zijn slechts middelen om iets te bereiken, niet het doel. In dit geval lijkt mij ook dat Java de best keuze was/is om dat doel te bereiken.
Leuk en goed artikel, wat dieper ingaand op de techniek, dat is toch iets waarmee Tweakers zich kan onderscheiden! Goed dat jullie de ontwikkelingen in de techniek ook op jezelf betrekken, compliment .
.Leuk om eens wat meer van de achterkant van tweakers te lezen. Dit soort artikelen mogen vaker van mij voorbij 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.
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.
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.
Blij te horen dat er aan de breadcrums gewerkt wordt deze vind ik erg waardevol in de PW.
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.
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.....
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.
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.
Waarom dan niet een DB-platform gebruiken dat daar wel goed mee om kan gaan?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
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 vrijdag 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.
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.
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.
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.
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).
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.
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.
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)
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)
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.Waarom dan niet een DB-platform gebruiken dat daar wel goed mee om kan gaan?
(los daarvan zijn er natuurlijk nog steeds wel goede redenen te bedenken om een andere database te gebruiken)
Daarom is er ook een markt voor een speciaal soort database dat specialiseert in de zogenaamde faceted search.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.
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.
Prachtig artikel, goed geschreven en interessant. Bedankt! :-)
Netjes geschreven en goed te begrijpen. Kort gezegd werden jullie door de hoeveelheid data/operaties die moesten worden uitgevoerd, geforceerd om dieper na te denken over de architectuur van de site en hebben jullie gekozen voor een soort api interface. Java is logische keuze,zeker als de voorkant al met php werkt. De architectuur ziet er netjes uit
[Reactie gewijzigd door BlackHawkDesign op vrijdag 16 november 2012 14:33]
Mooi verslag, goed duidelijk. Zoiets graag vaker !
tnx !!
tnx !!
Er was me al een paar dagen geleden iets opgevallen aan de pricewatch. Zag er zeer overzichtelijker uit en er waren meer producten. Prima gedaan, zou ik zeggen, want pricewatch was hiervoor erg bar slecht.
uhhh... deze engine staat al een jaar of wat online voor de pricewatch en is nu 'slechts' uitgebreid naar de rest van de site.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
