Might Know Something Else

Ja då ska jag väl ge en annan syn på valet av plattform. Drupalist som jag är är det väl lite färgat, men jag tror nog Bonnier gör rätt iaf om valet står mellan Drupal och EPI Server. Frågan är om det är rätt val långsiktigt? http://bit.ly/50Uhle

....ååååååfan... Skönt...då är dagens dos av onödigt och faktafelande vetande avklarat...

Nu landar info från http://www.mktmedia.se/ i Bonnier - EPiServer sökträffarna också. De är nöjda med att vara delvis klara med sin Polopoly javasatsning. AB:t omsatte för övrigt hela 61,5 Mkr år 2008.

Det kan vara värt att hålla i minnet att Kajetan Kazimierczak, som har skrivit http://tankemoln.wordpress.com/2009/11/21/varfo..., är en .NET-utvecklare på Dagens Industri.

Det kritiska inlägget försvann med ifrån nätet. Kanske dags för Bonnier att lyssna på icke MS-frälsta. Det skulle spara dem pengar om inget annat.

Ajfan.. Note to self: inte pilla på inlägg sent på natten. Nu är den nog tillbaka.

Det var väl pro-MS/EPiServer: Varför Drupal inte håller hos Bonnier
By Kajetan

Efter att Resumé nyligen släppte nyheten att Bonnier är på väg att byta CMS för sina största sajter till Episerver hördes det en hel del röster om att Drupal skulle vara ett likvärdigt eller rentav bättre alternativ för Bonnier. För sajter som Di.se, Dn.se, Sydsvenskan, Expressen… kom igen.

Jag säger inte att Drupal är totalt värdelöst, för det är trots allt ett hyffsat komplett CMS som man får out-of-the-box, men det räcker inte långt när det gäller sajter av den här storleken och komplexiteten.

Låt mig ta upp några exempel. Det finns betydligt fler, men här kommer ett par stycken.

Myten om moduler till allt mellan himmel och jord

Joakim Jardenberg reagerar på sin blogg på att det endast finns ”ytterst få” Extras (motsvarande moduler i Drupal) registrerade på Episervers sajt. Det finns ju tusentals för Drupal. Men det är en sanning med modifikation. Drupals moduler finns inte på riktigt. Förutom de välkända som Nodequeue, Views, CCK, och ett par till (som alla har en motsvarighet i Episerver out-of-the-box) finns det inte många som faktiskt fungerar, är uppdaterade, eller intressanta för en bredare publik. Flera registrerade Drupalmoduler är dessutom bara idéer, utan en enda rad kod. The Drupal Way. Publicera allt öppet, så kanske någon hakar på. Eller inte. Andra moduler har blivit övergivna så fort deras skapare hittade ett riktigt jobb. Episerver bygger på .Net-platformen och där finns ju rätt många högklassiga moduler att tillgå om man nu skulle vilja ha sådana.

Men det spelar ingen roll egentligen, eftersom de här modulerna används inte i så här stora sajtbyggen.Vare sig det gäller Episerver eller Drupal, så skrivs de affärsanpassade modulerna in-house.

The Drupal Way

Drupals absolut största användargrupp är små sajter som ligger på webbhotell och drupalkärnan är anpassad så att den ska vara enkel att använda för dessa användare. Även om det offentligt pratas och skrivs allt mer om Entreprise Drupal så är det rent av omöjligt att få in de förändringar som behövs i Drupalkärnan. Stora, prestandakrävande stajter ser lite annorlunda ut under huven än små privata bloggar. Att t.ex. lagra cachedata i databas är ett skämt. Men de stora sajterna är så få till antalet att deras krav inte kommer med. Men det är Open Source, så man får göra sina egna ändringar i Drupalkärnan (och flera sajter gör det). Och sen applicera dem varje gång Drupal släpper en uppdatering. Om och om igen, version efter version.

Sättet Drupal är skrivet på

Uppyggnaden med moduler som krokar in på olika ställen på sidan var säkert state of the art för ett sånt system när det begav sig. Idag stödjer t.o.m. PHP objektorienterad programmering. Dessutom körs alla modulerna på alla sidor, vilket gör att sajten antingen måste ha få sidor (sidmallar) eller lite funktionalitet. Eller få besökare. Annars håller det inte.

Prestanda och tillgänglighet

Ta di.se som exempel. Det brukar ligga runt 100 artikelpuffar på förstasidan. Flera av dem har dessutom kopplade artiklar. Förutom puffarna ligger det listor med mest lästa, mest kommenderade, mest skickade, börstips, börsfokus, telegram… En förstasida bestående av sisådär 200-300 noder utvalda av nära en halv miljon noder, som ska levereras ett par hundra gånger i sekunden. Det får en Drupalinstallation att sätta sig i ett hörn och gråta en skvätt. Även med cache påslaget. Och då är detta bara första sidan.

Vidare ska de här sajterna aldrig ligga nere. Om sajten är nere i en minut så påverkas tiotusentals besökare. Drupal klarar inte en kontrollerad större uppdatering utan att tas ner.

Teknik

Vi har Drupal med PHP och MySQL på ena sidan mot Microsoft .NET och MS SQL Server på andra sidan. De spelar inte ens i samma liga. Visst kan man få PHP och MySQL göra rätt mycket om man slänger hårdvara på dem med i enterprisesammanhang så saknas det rätt mycket. Både vad gäller funktionalitet och prestanda.

Framtidssäkert

Det system som Bonnier nu bygger bör vara framtidssäkert. Med facit i hand så har ju Dn.se och Di.se hållit fast vid sina respektive CMS-system i över 10 år. Vem vet när det blir dags för nästa satsning av denna storlek? Det sägs att valet av Episerver är en inlåsning medan Open Source inte är det. Men är det så? Är det säkrare att satsa på ett företag (som det dessutom går rätt bra för) eller på ett löst sammansatt gäng människor som skriver varsin modul. Inte ens Acquia räddar biffen idag. Vad händer om en utvecklare av en Drupalmodul blir sjuk? Eller råkar ut för något? Eller bara tappar intresset? I teorin kan ju ”någon annan ta över” men på riktigt? I några Open source projekt blir det så, men i de flesta inte. Jag tror inte att finns någon risk att Drupal går under inom en överskådlig framtid däremot kan någon av de viktiga modulerna, som ofta underhålls av en enstaka eldsjäl, sluta utvecklas eller hamna på efterkälken. Ska då Bonnier ta över utvecklingen av modulen? Det är nog inte riktigt deras affärsidé.

Det finns flera lyckade projekt där rätt så stora och kända sajter använder Drupal. Det skulle säkert även gå att skriva om Drupal så att det funkar för Di.se och Dn.se. Det skulle säkert gå att segla jorden runt i en optimistjolle också. Men varför? När man väljer ett CMS så gör man det för att bygga sina funktioner runt det, inte att skriva om det. I så fall skulle man ju lika gärna kunna skriva sitt CMS själv till att börja med.

Drupal kommer kanske någon gång att nå den mognad där den kommer vara intessant för stora sajter. Men den är inte där i version 6, kommer inte vara där i version 7 och förmodligen inte i 8 heller. Och Bonnier byter system nu, inte om fem år.

Därför tror jag mer på Episerver än Drupal i det här fallet.

Detta inlägg postades den 2009-11-21 kl 12:01 under Uncategorized. Du kan följa alla svar på detta inlägg via RSS 2.0-flödet. Du kan lämna ett svar eller trackback från din egen webbplats.
56 kommentarer till “Varför Drupal inte håller hos Bonnier”

1. Joel Abrahamsson säger:
2009-11-21 kl 13:53 | Svara

Mycket bra skrivet!

Utan att ha jobbat med Drupal själv kan jag inte riktigt värdera argumenten, men oavsett är det mycket uppfriskande att läsa ett inlägg i den här debatten som inte enbart är uppbyggt mha utdrag från respektive plattforms egen site och/eller ideologiska argument.
2. Tweets that mention Varför Drupal inte håller hos Bonnier « Kajetans tankemoln -- Topsy.com säger:
2009-11-21 kl 13:58 | Svara

[...] This post was mentioned on Twitter by Joel Abrahamsson, Henrik Lundberg. Henrik Lundberg said: Läs & begrunda openSource-konsulter: http://tinyurl.com/yaf9etu #drupal #epi [...]
3. Andreas Ek säger:
2009-11-21 kl 15:38 | Svara

EPi är inte bara CMS och publicering. Det är i högre grad en integrationsplattform med exempelvis workflows (WWF) och AD. EPi jobbar bra och målmedvetet att inte uppfinna nya påhittiga lösningar utan lutar sig i mångt och mycket mot Microsoft. Så det stora i ämnet är att Bonnier väljer ett tydligare MS-spår.
* Nils säger:
2009-11-23 kl 09:31 | Svara

Intressant då de är inne på ett OD spår för att AD kostar ca 1000 gånger mer.

Sen åter igen, vilka arbetsflöden? Vet du hur redaktionella flöden fungerar öht?

Bonniers har ju med tydligt sagt de skall jobba i Macmiljö emot EPI. Alla de som bytte till MS miljö 1998-2003 är ju på väg tillbaka till Apple. Det för lägre kostnader och för mindre IT avdelningar. Finns ju tidningar som hade IT-avdelningar som fyrdubblades efter bytet. Tycker det säger det mesta.
o Snaxalig säger:
2009-11-23 kl 16:08

Möjligt att DI.se vill ha Mac på klientsidan, men uppenbarligen inte på serversidan. Så vitt jag förstått så installeras EPiServer CMS på servern och klienterna är vanliga webbläsare. Så vad är motsägelsen i det?
o Nils säger:
2009-11-23 kl 21:45

Svar till Snaxalig

Konstigt att IT-folket inom Bonnier säger en sak och agerar annorlunda. Fast sanningen är väl den att de blivit överkörda. Precis som att de har kvar fotostation. Aftonbladet har ju slängt ut windows och fått lägre it-budget. Fast när beslut tas av andra grunder än IT-mässiga, då blir det som med EPI. 1900-tals tänk om igen.
4. Emil Stenström säger:
2009-11-21 kl 19:31 | Svara

Utmärkt skrivet inlägg.

Jag kan inte värdera hur bra Drupal håller sig pretandamässigt, nog måste det gå att ha t.ex. filbaserad cache? Flera stora sajter som använder Drupal har ju betydligt mer trafik än lilla DI.se, så jag tror faktiskt inte att det är där skon klämmer…

Vad gäller EPi så har dom, i alla fall i tidigare versioner, haft begränsningar på hur många sidor som kan ligga i varje nivå i systemet utan att det blir segt. Jag gissar nu, men jag har för mig att gränsen var runt 100 sidor. Om det stämmer så håller inte heller EPiServer för den last som DI har utan att byggas om…

Som sagt, kul med ett inlägg med välgrundad kritik!
* Kajetan säger:
2009-11-21 kl 20:53 | Svara

Emil, visst finns det filbaserad och minnesbaserad cache som tilläggsmoduler till Drupal, som t.ex. Boost och Cache Router. De verkar dock lida av det jag beskrev innan. De uppdateras av några enstaka eldsjälar som inte orkar/hinner/vill uppdatera dem i samma takt som Drupal uppdateras. Och de är inte i alla lägen stabila.

Dessutom tror jag inte att cache, eller någon annan av de punkter jag beskrev skulle ensamt bli en show stopper ens för en stor sajt. Men ihop är det mycket som måste övervinnas och någonstans slutar det att vara någon mening med att tvunget välja en plattform som inte är optimal.
o Pelle Wessman säger:
2009-11-23 kl 21:11

Jag ser inte några indikationer på att ex. Cache Router skulle vara instabil eller inte hinna uppdateras. Drupal 7 är inte ens släppt i beta, men Cache Router har redan en version ute för den nya versionen. Känns ju inte som att det är brist på engagemang bakom då?
5. Per Lundkvist säger:
2009-11-21 kl 19:51 | Svara

Bra skrivet,håller med.
6. Andreas Ek säger:
2009-11-21 kl 20:01 | Svara

Åja, nog är di.se av respektabel storlek och last?
7. joelabrahamsson säger:
2009-11-21 kl 20:23 | Svara

Emil, det stämmer om man ser till en standardinstallation där sidorna levereras av LocalPageProvider som är optimerad för en trädliknande sidstruktur. Det går dock att med den optimera för en annan struktur, men då får man jobba lite ”mot systemet”. Men, eftersom sidmodellen i EPi är providerbaserad, kan man också relativt enkelt optimera för en annan struktur med en egen provider.
Det är också ett exempel på varför jag tror att EPi är ett bra val; samtidigt som det mesta följer med out-of-the-box är det också utbyggbart åt i princip alla tänkbara håll.
8. Martin säger:
2009-11-22 kl 00:24 | Svara

Angående MySQL och PHP mot .NET och MSSQL så kör väl i princip alla stora sidor MySQL och PHP? Inte många sajter som kör .NET och MSSQL? Jag tänker framför allt på stora, innoverande och ledande siter som Digg, Facebook, Zimbra, iStock Photos, Adobe Craigs list .. Sen är jag inte säker men tror t.o.m Youtube kör PHP+MySQL. Twitter kör väl i alla fall MySQL tror jag, även om de använder Ruby on Rails på toppen.

I Sverige använder väl Aftonbladet PHP+MySQL, som trots allt är den mest besökta webplatsen, eller?
* Kajetan säger:
2009-11-22 kl 00:42 | Svara

Den mest besökta webbplatsen i Sverige är enligt KIA-index msn.se och de tror jag inte kör MySQL eller PHP ;)

Jag har inte jobbat med sajter som är av den storleken du nämner så jag har inga personliga erfarenheter. Jag tror dock att det kan finnas en nivå där Microsoftlicenser, eller överhuvudtaget programvara ”of-the shelf” inte är nog och Open Source är enda alternativet. Senast jag läste om det så körde t.ex. yahoo.com en egenmodifierad version av Postgres. Google körde någon liknande lösning. De håller förresten på och utvecklar ett eget programmeringsspråk och kommunkiationsprotokoll för webben… så det går inte att jämföra dessa giganter med Bonniers tidningswebbar. :)
o Nils säger:
2009-11-23 kl 09:35

Sanningen är ju den att MS är små i världen. De stora sidorna kör på linux/unix.

Stockholm.se visade ju i starten hur driftsäker den var. Den kör EPI vad jag vet.
9. Per säger:
2009-11-22 kl 00:43 | Svara

Intressant att du bara väljer att skriva vad du personligen tycker är negativt med Drupal, men inte med ett ord skriva vad du tycker är bra, eller kanske än viktigare – bättre, med EPIserver.

Tillsist undrar jag i vilka större sammanhang EPIserver är prövat. Även om deras produkter är helt OK, är de i mina ögon på intet sätt bländande. Och glöm inte att företag eller inte, så är det utvecklat enbart i vår lilla blåbärsnation. Av svenskar, för nordbor. På gott och ont.

För att sammanfatta gör Bonnier endast rätt om de har för avsikt att lägga ned den interna utvecklingen. Annars skapar de bara overhead med att köpa system som de ändå har för avsikt att lägga tid och resurser på att omforma till sitt eget. Något som med 99,9% sannolikhet kommer ske. Om man ser till kostnaden är Open Source-lösningar bra när man har behov att anpassa och vill skapa själv, medan lösningar à la EPIserver är bra när man inte orkar bry sig och bara vill ha något färdigt.
* Kajetan säger:
2009-11-22 kl 01:51 | Svara

Jag känner inte att jag har tillräckligt med erfarenhet av Episerver för att uttala mig om dess fördelar eller brister i detta sammanhang.

En mediasajt består oftast av mer än bara CMS. Jag håller med dig att med färdiga lösningar som Episerver (eller Drupal för den delen) slipper man bry sig om detaljer. Men det kanske är det man är ute efter? Att koncentrera den interna utvecklingen på att skapa affärsnytta och användarupplevelse istället för att gräva ner sig in hur detaljerna fungerar? Så länge de fungerar.
10. Stina Bjurström säger:
2009-11-22 kl 01:36 | Svara

Grymt bra och initierat skrivet. Det behövde sägas. Tack!
11. Nils säger:
2009-11-22 kl 09:13 | Svara

Du har inte mycket koll på redaktionella flöden och vad en CMS för mediaföretag kräver.

EPI är och har aldrig varit anpassat för en modern sajt. Att bygga något med .net och Microsoftlösningar är seriöst hål i huvudet. Det är små sidor med lite trafik och där upptiden är oviktig som kör med windowslösningar.

Jag undrar hur många som försvarar EPI som varit på någon av de stora IFRA mässorna runt om i världen och sett vad framtiden för mediasajter ser ut. Det är inte något som är så låst till Microsoftmiljö för det första, samt det är system som fungerar tillsammans med redaktionella system, så att det inte krävs två skilda miljöer.

För oss som sett vad olika EPI-partners har visat för koncept på mediasajter skrattar oavbrutet. En modern redaktion idag skall jobba som en gemensam enhet. Inte en web och en print. Det blir inte bara dyrt utan tungjobbat. Framtiden är att alla jobbar i ett system som i sin tur kan använda alla kanaler.

Drupal fungerar med en hel del redaktionella system. Det gör inte EPI.

Så EPI valet handlar om något helt annat. Det handlar med stor sannolikhet om att använda Bonnier som referenskund. Det finns ju idag inga större tidningar som använder EPI, vad jag vet, men med DN i listan så kan kanske en utlandsexpansion fungera.

Hur man än vrider och vänder på det hela kommer hela EPI valet kosta en massa och frågan är om det någonsin sjösätts. Tidningarnas chefredaktörer tycks ju körts över och frågan är om de är redo för att lägga mer pengar på webben än vad de gör idag. Webben är ju ingen främmande fågel idag och bör integreras som i övriga världen. Synd bara att svenska förlag är så tröga.
* Kajetan säger:
2009-11-22 kl 11:44 | Svara

Tack för din kommentar. Om nu Drupal inte håller av de anledningar som jag skrev ovan, så spelar det ingen roll om det finns stöd för redaktionella system. Vilka redaktionella system fungerar Drupal med förresten? Länk till lämpliga, fungerande, moduler tack, inte hype.

Di.se körs nu på .net och den verkar varken lånsam eller nere. Något man inte riktigt kan säga om t.ex. polopolysajter alla gånger.

Jag ska kanske passa på att klargöra att mitt inlägg inte är en jämförelse av Epi mot Drupal. Jag ville bara få fram varför Drupal inte håller. Jag har erfarenhet av både .Net och LAMP och tycket personligen att det första är ett bättre val, om man har råd. Epi har jag ingen praktisk erfarenhet av.

Vad har du själv för erfarenhet av redaktionella flöden och system i praktiken, annat än att besöka IFRA mässor?
o Nils säger:
2009-11-22 kl 14:35

Det finns ju x antal andra system som är bättre än EPI. Fast är tanken att utvecklingen skall ske i låglöneländer och att de fått EPI licenser så kanske allt kommer i ett annat ljus.

Tunga sidor som facebook körs ju inte på .net. Alla större sidor körs på icke Microsoftplattform, det beror på flera olika orsaker. Den första är att plattformen är dyr. Den andra är att den är inte lika skalbar. Den tredje är att det är lättare att jobba tillsammans med andra system. Det finns massor med andra argument, men hur man än vänder och vrider på det är .net något för mindre lösningar.

Drupal är ganska ”enkelt” att anpassa för ett redaktionellt flöde. Det finns exempel på detta i USA och en del europeiska länder. I Sverige har väl ingen riktigt ”fått till det”. Svenska systemet Newspilot kommer ju nu med en koppling och som vad jag förstått skall fungera helt perfekt. Fast alla kör ju inte Newspilot säger vän av ordning och nej det är inte stort utanför landets gränser. Det är många andra system som är på gång och det system jag jobbar mycket med släpper inom kort en lösning som integrerar det helt.

Fast det är ju bara att googla. Jag finner ingen större mediasajt som kör med EPI. Dupal finns det gott om exempel däremot.

EPI håller inte för att kopplas in i flödet. Det blir två skilda delar. Något som kostar en massa resurser för redaktionerna och som gör att vi står på samma plats som under slutet av 1990-talet. Stora företag som Adobe har ju talat för att få bort denna värld med två olika system utan bara jobba med samma grundinnehåll och sen föra ut det i rätt kanal. Nu är de inte bäst på det, men när en spelare som Adobe säger det, då borde även någon på kunna lyssna.

Sen när det gäller polopolysajterna så har ju bristen på hårdvara varit ett problem. När man inte köper in mer än vad som minimalt krävs i hårdvara då får man problem. Det är samma sak vid inköp av redaktionella system, köper man inte in rätt hårdvara då kvittar det ju hur bra mjukvaran är.

Jag har jobbat med ett 80-tal europeiska tidningar. Jobbat med dessa kära kanaler sedan början på 1990-talet och en hel del med webb sedan 1995. Så jag har mitt på det torra. Och ja, jag har sett hur olämplig en EPI lösning är.
o Joel Abrahamsson säger:
2009-11-22 kl 15:12

Nils, att du inte kan köra tunga siter på .NET och att ”Alla större sidor körs på icke Microsoftplattform” är befängt. Både msn.com och live.com hör till top 10 vad gäller trafik globalt. Sedan kör ju även siter som Myspace, Newegg och Microsoft.com på .NET.
Med andra ord så känns ditt påstående om att ”hur man än vänder och vrider på det är .net något för mindre lösningar” rätt galet.
* Jojje säger:
2009-11-22 kl 16:55 | Svara

Nils! Lite mer hårda fakta vore bra för att kunna bemöta dina åsikter. Vilka x system är överlägsna Episerver och varför? Varför skulle inte .NET fungera för di.se imorgon när det fungerar idag? Vad är det som gör Drupal mer lämpligt för ett redaktionellt flöde?
o Nils säger:
2009-11-23 kl 06:42

EPI är i grunden vad jag skulle kalla för dokumenthanteringsinriktat, inte alls artikell och det flöde som används inom media. Med EPI blir det igen två system som inte har med varandra att göra. Det ger ökade kostnader och dubbelt arbete.

Då jag inte vill lyfta fram enskilda system, då jag anser det är någon annans bord, dock alla jag sett på olika IFRA arrangemang är mer lämpade än EPI. Det är ju inte för inte som EPI är en främmande fågel inom media just för det inte är anpassat för det arbetsflöde som gäller.

Windowsplattformen kräver en massa hårdvara och upptiden är inget att hurra för. En unix/linux server har betydligt bättre upptid. För webben är det A & O med hög upptid. I tider med olika nätattacker så är windows mer utsatt och innebär sämre upptid. Windows har undermål upptid. Se bara på bilddataser som kör Fotostation. En riktig stor Akilleshäl hos många redaktioner. När man väljer annan lösning som rullar på linux/unix så ökar upptiden.

Det finns ju redaktionella system som jobbar med drupal som gör att de stannar kvar i sitt vanliga redaktionella system och webben blir en naturlig del.

Vilka bilddatabaser funkar med EPI förresten? Jag ser inga när jag har kontrollerat.

Det handlar ju om att den vanliga redaktionen skall hantera webben som en av alla andra delar. Att ha två redaktioner, en print och en web/nyamedier är ju helt sjukt 2009. Det finns ju ingen anledning till att dela upp det när deras verktyg löser det utan problem! EPI innebär ju att fortsätta att ha dubbel bemanning. Det är hål i huvudet på den som valt EPI för redaktionellt användande 2009.
12. Danne M säger:
2009-11-23 kl 02:28 | Svara

Jadu Kajetan!

Verkligheten är ju den att det är betydligt lättare att hitta riktigt stora siter som körs på Drupal, än vad det är med riktigt stora siter som körs på EPI-server.

Hur kommer sig detta?

Framför allt, verkligheten, så som det faktiskt ser ut.
Får ditt resonemang att framstå som högst märkligt.
* Kajetan säger:
2009-11-23 kl 08:29 | Svara

Ja, det tycks ju vara den allmänna uppfattningen. Men ge mig ETT exempel. Alltså en sajt storlek di.se eller dn.se (eller helst båda ihop) som körs på Drupal. Som verkligen körs på Drupal, inte som använder Drupal som ett sidoprojekt i någon källare någonstans.
o Andreas säger:
2009-11-23 kl 14:29

http://www.economist.com/ kör enbart Drupal och borde kunna mätas med di.se och dn.se..

http://ads.economist.com/economistcom/site-stat...
Worldwide Unique Visitors: 3,452,807
Worldwide Page Views: 23,822,218

Source: IBM SurfAid, Monthly Average, May-July 2009.
o Kajetan säger:
2009-11-23 kl 14:49

Ja. Och deras sidor heter .cfm för att Drupal är skriven i Cold Fusion? Och att det på flera sidor i koden står

meta name="generator" content="TYPO3 4.1 CMS"
ringer heller inga klockor? Lita inte blint på någon föreläsning du sett på youtube. Kolla upp fakta. Oftast är de bara en ”view source” bort.

Dessutom har väl di.se sisådär 4-5 gånger fler sidvinsningar under en månad.
o Pelle Wessman säger:
2009-11-23 kl 21:20

Anledningen att det kan stå Cold Fusion på vissa ställen av The Economists är för att de successivt flyttar över sajten till Drupal och att front end delarna är de som flyttas sist.

Jag tror inte att The Economist teamet skulle flyga runt på drupalkonferenser i hela världen om de inte verkligen höll på att byta. Jag tror inte heller att de ledande personerna inom drupalcommunityt skulle stå och ljuga mitt framför en församling på drupalvärldens största konferens om vilka deras roll är i konverteringen.

The Economists kommer ganska snart att köra på enbart Drupal och det verkar inte uppskattas finna några problem med det. Kan hända att de inte hunnit flytta alla delar än dock.
o Kajetan säger:
2009-11-24 kl 02:03

Jag säger inte att folk inte jobbar på det.

På den tiden det begav sig så flög Dagens Industris team runt på Drupalkonferenser i hela världen och träffade höjdarna som pratade sig varma om diverse saker. Men det höll inte i praktiken.

Därför tror jag inte på saker som är ”på väg att bli”. Jag kommer gärna och lyssnar när de varit uppe och kört ett tag. :)
13. Nils säger:
2009-11-23 kl 06:50 | Svara

Svar till Joel Abrahamsson:

Du väljer att dra fram sidor där Microsoft själv står för hårdvara och mjukvaran. Det är ju inga vanliga .net lösningar där inte utan det är mycket hemma snickat av MS.

Sen är det ju unix på topp tio
http://toolbar.netcraft.com/stats/topsites
Se bara på BING som körs på Akamai Technologies UNIX.

Windows fasas allt mer ut globalt inom mediaindustrin.
* Joel Abrahamsson säger:
2009-11-23 kl 08:43 | Svara

Jag hade ingen aning om att Microsoft sponsrar MySpace och NewEgg med hårdvara. Har du någon källa till det?

Gällande Bing så använder de så vitt jag kan se Akamai som CDN men en snabb koll med exempelvis httprecon visar att de flesta request hanteras av IIS 6.0.
o Nils säger:
2009-11-23 kl 09:09

MySpace jobbar tätt med MS. Det är ju ingen hemlighet. De har ju haft driftsproblem när de var poppis. Nu är de ju snart ett minne blott.

Bing utnyttjar ju Akamai tar hand om de stora topparna. Lastbalansera i windows är ju som sagt inte MS starka sida.
* Joel Abrahamsson säger:
2009-11-23 kl 09:19 | Svara

Jag är fullt beredd att hålla med dig om att jag inte skulle välja windowsbaserade lastbalanserare men det har ingenting att göra med vilken miljö jag skulle vilja ha min CMS-drivna site på.

Hur som helst, jag anser att det är befängt att påstå att Windowsservrar och .NET inte skulle kunna klara last och vara skalbara och att det är väl bevisat (se exempelvis på PlentyOfFish som var den 13:e mest besökta siten i USA under 2008 och snurrade på fem servrar). Du är av en annan åsikt, och det är helt OK med mig :)
o Nils säger:
2009-11-23 kl 09:27

PlentyOfFish kör med statsiska html sidor med enkla formulär. Det är ju inte så jobbigt att drifta.

En mediasajt som kör med video, har massa med kommenatsfunktioner, kopplingar till pingtjänster och sen kopplas på det redaktionella systemen, då krävs lite annat i bakgrunden.

Vad jag förstått kring EPI projektet så är det ingen koppling till de redaktionella systemen och därför är så mycket 1900-tals tänk att jag blir häpen. Fast det finns säkert en agenda för det med.

Fast Bonniers brukar inte vara så aktiva på IFRAs internationella arrangemang, så jag är inte så förvånad. De satsar ju på att starta en utvecklingsavdelning i USA som bara skall titta på läsplattor. Så det säger ju en del hur långt de har kommit.
14. Andreas Ek säger:
2009-11-23 kl 08:19 | Svara

Jag kan inte låta bli att le och bli lugn när kommentarerna stegrar.
Om windows håller på att fasas ut inom mediabranschen, vad är då problemet? Då kommer det att lösa sig av sig självt, eller?
Jag är tvärtom övertygad om att MS har mer att ge mediebranschen och att Bonnier tar ett klart steg i rätt riktning som fler hus kommer att följa.

Att sedan skilja på tryck och webb i redaktioner har visat sig framgångsrikt. För att åstakomma en bra webb så måste redaktionen kunna fokusera på sin utkanal för de används på olika sätt som komplement till varandra. Det är 2009!
* Nils säger:
2009-11-23 kl 09:21 | Svara

Trams.

MS har inget att ge medieföretagen. De har ingen förståelse för de krav som finns. Bara ett exempel, MS har idag ingen webbrowser som kan hantera ICC profiler. Så Case Closed.

Bonnier kommer snart inse hur dyrt det är att komma in i windowsträsket. Det krävs enormt större IT satsningar och en fördubbling av personalen är vad som står på agendan.

Nej, det är inte framgångsrikt att dela på webb och tryck. Idag när branschen allt mer ser hur röda siffror websatsningarna ger, så handlar det om att använda ett flöde istället för att köra med två eller fler flöden. För trotts det är 2009 så är det inga websatsningar som går med vinst, enda undantaget är väl Aftonbladet, men resten av företagen går med förlust. Annonsintäkterna täcker inte på långa vägar websatsningarna.

TU har ju tydligt talat om andra modeller för att göra så att webben går med plus. Då är det inte att fortsätta att jobba med två kanaler som borde vara en. Att ha dubbla tjänster som allt mer har delat upp redaktionen i två delar. I stället för att ha en vi känsla så är det en vi och dom. För oss som varit ute på tidningarna har sett problemet. Gemensamma system kompromissas och det finns tidningar som kör med dubbelt av allt. Det håller inte.

Så det är pinsamt att se alla EPI-konsulter som slåss med näbbar och klor för att försvara valet. Bonnier har säkert en helt annan agenda. Vi måste med inse att chefredaktörerna har ännu inte sagt ok. Jag tror inte vi kommer se EPI gå skarpt i någon större utsträckning. Tidningarna vill inte släppa på personal till någon central enhet som med stor sannolikhet läggs ner med tiden och ersätts med konsulter.

Så kom igen, när var ni senast på en IFRA mässa kära EPI försvarare?
15. Bonnier väljer EPiServer, men vad är sant? | Might Know Something Else säger:
2009-11-23 kl 09:40 | Svara

[...] Dessutom får alla snabba Open Source (Drupal och tom. WordPress har nämnts) förespråkare en rejäl, initierad klänga i förm av detta pro-EPiServer inlägg av anonyma (varför?) Tankemoln. [...]
16. Vilket CMS väljer du? « Per Vikström @ Internet säger:
2009-11-23 kl 11:32 | Svara

[...] annat intressant inlägg kring Bonnier är detta. Där förklaras varför Bonnier valde EPiServer istället för Drupal. Det som gör att [...]
17. thr säger:
2009-11-23 kl 11:44 | Svara

”The blind leading the blind?”

Nu håller jag förvisso med om att Drupal, i sig, är ett rent jävla helvete att jobba med (prestanda, språket, databasen, etc.). Men EPIServer är långt från bra, har jobbat heltid som EPiServer utvecklare under ett längre tag nu, min erfarenhet är följande:

* EPiServer är ohyggligt dyrt om man ser till alternativen (även i .NET-världen)

* Det finns ingen dokumentation av värde, ja det finns ett SDK (sdk.episerver.com) men den är så knapphändig att det inte ger något om man inte redan kan större delen av EPiServer redan.

* Det finns inga böcker, inget material eller tutorials som är uppdaterade och korrekta. Ja, world.episerver.com existerar men vem orkar rota igenom hundratalsblogposts för att *kanske* hitta det man söker (oftast finns det inte)

* EPiServers support är i princip helt värdelös, dem tar enorm lång tid på sig att svara och man får ofta ”det går inte”, ”vi vet inte”, ”ni måste prata med utvecklarna vi kan inte detta på supporten” som svar.

* Om man vill göra något som går det minsta utanför vad som är tänkt med grundsystemet i EPiServer så krävs så mycket extra jobb att det inte ens är tänktbart för de flesta projekt, istället får man tvinga in det i den struktur som finns som standard.

* De ”moduler” som finns till EPiServer (både från EPiServer själva och 3:e-parts) är, förvisso fungerande, men lider av samma problem som EPiServer själv (dvs. dålig support, ingen dokumentation alls, svårt/omöjligt att anpassa)

* sk. ”PageTypes” i EPiServer (de grundläggande ”building blocks” man bygger upp strukturen i siten av) är definierade 50% i kod och 50% i själva admin systemet vilket gör deployande ett rent helvete då det inte räcker att deploya bara källkoden för att uppgradera siten

* Då EPiServer använder sina PageTypes som dess grundläggande data-store meckanism så blir det 100% rent omöjligt att versionhantera databasen (för den oinsatte så kan du se PageType’s enkelt som tabeller i MSSQL/MySQL, väldigt förenklad jämnförelse)

* EPiServers ökända VPP gör det också extremt svårt att flytta data som ligger i dessa mellan dev/live-siten.

* Ingen tillgång till källkod (ja jag är medveten om reflector), detta är en extremt stor brist i system som är såhär komplexa och saknar vettig dokumentation.

* EPiServers ”certifiering” är ett skämt och liknar mer de glosor man fick i lågstadiet (dvs. komma ihåg vad olika klasser/config inställningar heter) istället för att sätta på prov hur duktig man är som utvecklare.

* EPiServers admin/redaktörs gränssnitt är inte vänligt mot folk som inte har stor tekniskt kompetens.

Jag har utvecklat fyra stora siter var av en är ~100k LOC C# i EPiServer , och ärligt talat skulle jag (om jag hade ett val) aldrig utveckla en till site i EPiServer som jag vet om (i förväg) att den ska göra något som inte stöjds av EPiServers baspaket.
* Johan säger:
2009-11-23 kl 13:22 | Svara

thr:

”EPiServer är ohyggligt dyrt om man ser till alternativen”
Det finns ohyggligt många alternativ, därför håller inte riktigt ditt argument. Vad menar du dessutom med dyrt? Licens? Totalkostnad för implementation?

”dokumentation[en] … är så knapphändig att det inte ger något om man inte redan kan större delen av EPiServer redan.”
Motsägelsefullt.

* Det finns inga böcker, inget material eller tutorials som är uppdaterade och korrekta. Ja, world.episerver.com existerar men vem orkar rota igenom hundratalsblogposts för att *kanske* hitta det man söker (oftast finns det inte)
Ganska bra poäng. Men hur många CMS har ”uppdaterade böcker”? På world.episerver.com kan man också söka, så slipper man rota. Alternativt använda Google. Själv hittar jag faktiskt oftast det jag behövt så.

”EPiServers support är i princip helt värdelös”
Känner jag inte igen alls. Jag som varit med ett antal år kan visserligen konstatera att den inte är så bra som förr, men jag får oftast snabb och bra respons. Men jag är öppen för att detta kan påverkas av partner- och kundstatus.

”Om man vill göra något som går det minsta utanför vad som är tänkt med grundsystemet i EPiServer så krävs så mycket extra jobb att det inte ens är tänktbart för de flesta projekt, istället får man tvinga in det i den struktur som finns som standard.”
Först säger du grundsystemet och sen säger du strukturen. Vilket av dom menar du? Känner oavsett inte igen detta alls. I princip alla projekt jag varit med om de senaste 2 åren har anpassningar gjorts, som har gått ganska smidigt – allihopa.

”De ”moduler” som finns till EPiServer (både från EPiServer själva och 3:e-parts) är, förvisso fungerande, men lider av samma problem som EPiServer själv (dvs. dålig support, ingen dokumentation alls, svårt/omöjligt att anpassa)”
Har haft blandade resultat här. En officiell modul var riktigt kass, andra har varit bra. De större tredjepartsmoduler jag provat har funkat bra. Enligt min erfarenhet är moduler – speciellt antalet – något open source-fanatikerna verkar tycka är ett av de viktigaste argumenten för eller emot någon plattform, men i verkliga projekt kommer det argumentet väldigt långt ner på listan.

Angående dina ”PageTypes”-argument rekommenderas ett besök på Joel Abrahamssons PageTypeBuilder-projekt :)

”EPiServers ökända VPP gör det också extremt svårt att flytta data som ligger i dessa mellan dev/live-siten.”
VPP är ett standardkoncept från Microsoft och EPiServer har dessutom flera providers så vad menar du?

”Ingen tillgång till källkod (ja jag är medveten om reflector), detta är en extremt stor brist i system som är såhär komplexa och saknar vettig dokumentation.”
Jag tycker inte att bristen på tillgänglig källkod i ett komplext system måste vara något negativt i sig själv. Det beror ju mer på hur systemet funkar och hur det används! Men sen är jag inte open source-fanatiker.
Självklart hade det varit trevligt att ha källkoden tillgänglig! Men det är ungefär 5 gånger på lika många år som jag tyckt att jag behövt använda Reflector och rota runt.

”EPiServers ”certifiering” är ett skämt och liknar mer de glosor man fick i lågstadiet (dvs. komma ihåg vad olika klasser/config inställningar heter) istället för att sätta på prov hur duktig man är som utvecklare.”
Den är bättre än Microsoft utvecklarcertifieringar (om det nu är ett argument i sig…) Sen verkar du ha missat en del av poängen med certifieringen också; den handlar inte bara om hur bra man är som utvecklare utan det handlar även delvis om produktkännedom.
Kan du ge mig exempel på bra utvecklarcertifieringar?

”EPiServers admin/redaktörs gränssnitt är inte vänligt mot folk som inte har stor tekniskt kompetens.”
??? T o m EPiServer-motståndarna säger ofta att EPiServer bara blivit så populärt för att webbredaktörerna tycker det är enkelt (inte WordPress-enkelt, men enklare än de flesta system). Har faktiskt aldrig hört någon säga att gränssnittet inte är ”vänligt”.

Tycker faktiskt som helhet ditt inlägg är ganska konstigt från en som ska ha jobbat som ”EPiServer utvecklare under ett längre tag”. Jag har aldrig stött på någon EPiServerutvecklare som varit så negativ som du låter och det låter faktiskt som du på förhand bestämde dig för att det var dåligt. Därmed inte sagt att det inte finns utvecklare som är negativa till det. Jag jobbar inte på EPiServer och jag är tror inte det skulle vara rätt val för _alla_ Bonniers sajter. Jag säger inte att EPiServer är perfekt. Som juniorutvecklare var jag lyrisk men efter ett tag märker man bristerna. De bristerna är dock inte de du listat – med undantag för sidtypshanteringen, men det löser som sagt PageTypeBuilder-projektet delvis.
o thr säger:
2009-11-23 kl 13:50

* Vad jag menade med ohyggligt dyrt är licenskostnaden, själva utvecklingskostnaden för en site i sig brukar inte stå i speciellt stor relation till vilket CMS man använder i grunden.

* Angående dokumentationen så syftade jag på att enda gången den ger något är när man behöver leta upp småsaker som parameternamn, förklaring på metoder, etc. Detta ger bara något om man redan har en större föreståelse för CMS:et i sig.

* Hur många CMS som har uppdaterade böcker? ~5 sekunder på google och jag hittade denna Drupal 7 boken: http://www.tomgeller.com/content/my-beginners-d... (nu är jag inget fan av Drupal heller, men trying to make a point here). Om det inte finns böcker så finns det vettiga manualer, t.ex. Django, som är gjort med tidningsindustrin i åtanke har både gratis böcker och en extremt bra manual.

* Angående supporten, senaste gången jag hade kontakt med dem tog det ~1 vecka att få svar, och vi fick svaret ”Det går inte att göra”. 5 Dagar senare hade vi implementerat det vi ville göra som dem sa inte gick (hade gärna visat kod, etc. men kundavtal, etc.)

* Ang. grundsystemet/strukturen så syftar jag på bas-installationen av CMS5 (dvs. grundsystemet) och dess struktur, vi kanske har olika defination på smidigt eller gjort helt olika saker – men att episerver skulle vara ”smidigt” att modifiera är långt ifrån min erfarenhet.

* Håller med om att tredjeparts-moduler i det stora hela ofta spelar ganska liten roll, men ofta för att dem inte *går* att anpassa och det slutar med att man får utveckla något eget istället för att ta dess plats. Ja det finns några bra moduler för EPiServer (ImageVault t.ex.) men på det stora hela är de moduler som finns väldigt dåliga på alla områden (kvalité, dokumentation/suport, utökningsbarhet)

* Ang. PageTypeBuilder så är jag väl medveten om det, men ska det verkligen vara en så stor lucka i ett system som kostar ~90.000 i runda slängar så att en tredje part måste bygga en modul som ändrar en så grundläggande sak som hur datastrukturen definieras?

* Bristen på källkod hade inte varit något problem om, och jag säger om, det hade funnits ett vettigt SDK (förvisso en helt annan branch men kolla på DirectX till exempel, ingen källkods tillgång där men DirectXs MSDN Docs är bland de bästa dokumentationer jag använt). Eller om det hade funnits kurser värda namnet (jag har gått både standard + advanced kursen när jag startade med EPiServer).

* Bra utvecklarcertifiering? Nja, det är svårt – vet ingen jag tycker är vettig, dock anser jag MS är bättre än EPiServer, men detta är ju en småsak i det stora hela.

* Angående admin-gränsnittet så vidarebefodrar jag bara vad de fyra största kunderna har relayat till oss, då jag som utvecklare har svårt att sätta mig in i vad som är svårt/lätt för gemeneman.

Mitt inlägg är konstigt hur? Att jag inte tycker om EPiServer är konstigt efter att jag har arbetat med det? Du kommer du från förutsättningen att alla som jobbat med EPiServer anser det är bra? Förhand bestämt mig? Det har blivit tiotusentals rader kod skrivet i system byggda på EPiServer vid det här laget, skulle inte kalla det ”på förhand”.

Obs, stycket nedan handlar inte mycket om EPiServer i sig.

Dock ser jag att många EPiServer utvecklare kommer från en strikit .NET bakgrund, vilket jag inte gör, och helt enkelt inte har sett världen utanför MS-domäner (nu säger jag inte att det är så för dig, utan generellt om man ser till kollegor och kontakter jag har haft genom åren). Jag har arbetat i en mängd olika platformar och språk och ser lätt det som fattas i EPiServer / ASP.NET världen.

Grundproblemet anser jag ligger i att EPiServer i sig inte är väl utänkt nog och sedan är byggt ovanpå en teknik (WebForms) som var modern 2002 när .NET 1.1 släpptes och har fått patch på patch på patch på patch för att hålla sig uppdaterad med de nya tekniker som kommit under åren.

Jag anser att .NET är utan tvekan det bästa Microsoft producerat (.NET 4.0 ihop med VS2010 och Windows7 är en våt dröm av integrering mellan olika system), men ASP.NET i sig är gammalt och förlegat och detta är en stor del av EPi’s problem.
18. Björn säger:
2009-11-23 kl 12:47 | Svara

Det går att lista för- respektive nackdelar med EPi/Drupal väldigt länge. Kanske är det ett symptom på att det delvis handlar om religion (oh yeah) och delvis om att båda har sina respektive styrkor?

Beträffande skalbarheten så är jag övertygad om att det går att få båda systemen att fungera bra där. Kanske kostar det lite mer i det ena fallet (EPi?) men i sammanhanget blir det nog ganska små pengar ändå.

Däremot:

1) Som vanligt är det istället konsultens klassiska huvudvärk: Kunden har redan valt CMS utifrån helt fel (eller fullständigt oklara) grunder. Hade det varit bättre att använda Polopoly där de tre största (och mest skeptiska?) bolagen har lång erfarenhet? Mycket ont kan sägas om Polopoly, men det är ju inte markant mycket sämre eller dyrare att jobba med än EPiServer.

2) Hur många procent av en klassisk mediesajt är idag ”CMS” och hur mycket är ”annat” (integrationer, presentation, etc etc). CMS:et står för en allt minde del. Att välja teknik som ligger i framkant avseende de aspekterna är viktigare än vilket CMS som ligger bakom. Idag ägnar så många duktiga utvecklare tid på att jobba i cirklar runt system som är dåligt anpassade för ändamålet. För sajt != CMS!

Inga av dessa frågor verkar ha övervägts och det kommer vara ett större problem än vilket CMS som snurrar i bakgrunden.
19. thr säger:
2009-11-23 kl 13:01 | Svara

@Björn: Ser inte varför fråga 1) behöver behandlas, det finns fler CMS det vet alla men nu var det dessa två som var ”up for discussion”.

Ang. fråga 2) så är det ju tyvärr så att CMSet du väljer *påverkar* hela siten, top-to-bottom, integration, presentation, etc. så jag skulle vilja säga att valet av CMS faktiskt *är* viktigt.

Det enda jag skulle se som viktigare är att ha ett team som är erfaret och vet vad dem gör, med ett bättre team så spelar valet av platform mindre roll medans om man har ett sämre team så är valet av platformen väldigt viktigt.
* bjornlilja säger:
2009-11-24 kl 14:18 | Svara

thr: Hela frågan är ju överspelad, och behöver därför inte behandlas. Dom har valt EPiServer. Punkt.

2) Du har helt rätt! Det är precis det jag menar: Och väljer du ett dåligt CMS får du spendera massa tid på att bygga dig runt det.

Håller helt med dig om ett bra team. Det går att bygga bra webb på de flesta plattformar med rätt erfarenhet.
20. Kalle säger:
2009-11-23 kl 13:08 | Svara

Förstår inte hur ett mediebolag kan välja ett dokumentbaserat system framför ett innehållssystem. Vilket är den viktigaste strategiska frågan här.
21. Nils säger:
2009-11-23 kl 18:56 | Svara

Den stora frågan är, varför inte utnyttja den bas de redan har, dvs de redaktionella system som finns. Varför 2009 fortsätta med två parallella system är den stora frågan. EPI har ingen koppling till något redaktionellt system.

Så vi kan fortsätta att tjata om det ena systemet emot det andra. Den viktigaste frågan, varför inte jobba med tekniken som finns på plats redan idag? Det behövs ingen webredaktion 2009. Det behövs heller inte två system som gör nästan samma sak.

Någon teknisk knowhow tycks inte Bonniers besitta. Det är den stora skrämmande sanningen.
22. Pelle Wessman säger:
2009-11-23 kl 21:05 | Svara

Du skriver att de flesta affärsanpassade modulerna byggs in-house så att det kvittar att det finns många små moduler för Drupal – det är visserligen sant att sajtspecifik kod byggs specifikt för en sajt, men ”The Drupal Way” är ju att så lite sajtspecifik kod som möjligt skrivs och att sajten så långt som möjligt konfigureras genom moduler som CCK, Views, Panels, småmoduler etc så att det i slutändan i princip bara är temat som behöver göras specifikt för en sajt för att få den unik. På de flesta sajter fungerar det förvånansvärt bra.

Att Drupals största användargrupp skulle vara små sajter måste jag protestera mot. Jag skulle så gott som aldrig använda Drupal till en liten sajt – då är ex. WordPress i de flesta fall överlägset. Drupal kommer till sin rätt när man kommer upp i medelstora sajter – eller om man har väldigt annorlunda och specifika krav så att ex. WordPress inte är ett alternativ.

Att cachen lagras i databasen för Drupal är långt från prestandaoptimalt – det ger en liten prestandakick – men är ju inte den långsiktiga lösningen för större sajter. Cachen i databasen är ju dock något som alla servrar klarar av – därför också det som är inbyggt. Var cachen lagras ändrar man däremot lätt och det finns ju ett antal cache system som gör så – ex. Cache Router som kan spara cachen i ex. Memcache och APC.

Att de stora drupalsajterna är så få att deras krav inte kommer med i Core är direkt fel. Varför? Jo för att ex. Drupal.org själv är en så stor sajt (fler pageviews än Aftonbladet.se enligt Alexa och ges samma ”traffic ranking” som Aftonbladet.se) att de kräver en väldigt sofistikerad serverarkitektur. Drupal.org driftas av några av drupalvärldens bästa serverexperter och optimeringar som görs där publiceras öppet och blir tillgängliga för communityt.

En av serverexperterna från Drupal.org jobbar för bolaget Four Kitchen som bl.a. hjälper The Economists med deras serverinfrastruktur. De har publicerat en drupalkompatibel distribution vid namn Pressflow som är extra optimerad mot vissa plattformar. Den innehåller vissa optimeringar som ännu inte nått Drupal Core eller som inte platsar där och kan därför om normala Drupal inte skulle ge nog med prestanda gå att växla över till för många.

Ett annat företag som också hjälper The Economists är Chapter Three som släppt en högprestanda stack med LAMP, APC och Varnish som en öppen EC2 avbild: http://getpantheon.com/ Den bygger vidare på PressFlow med opensource världens bästa serververktyg för att leverera en enligt diagrammen ganska imponerande prestanda – dock själv ännu inte hunnit testa.

Att Drupal inte har nog med stora sajter för att få igenom prestandaoptimeringar är alltså inte alls sant. Drupal är i sig en stor sajt och de finns väldigt många kompetenta människor som jobbar proffessionellt med att optimera drupalmiljöer och som också har väldigt centrala roller i drupalcommunityt.

Att Drupal skulle ladda in all kod vid alla sidladdningar vet jag inte vad du har fått ifrån. Templates laddas absolut inte in när de inte behövs och Drupal stödjer mycket väl att funktioner separeras ut i filer som enbart laddas in när funktionerna behövs – och så görs också. Det finns en medvetenhet om hur separering av kod inverkar på prestanda och i Drupal 7 fanns det t.ex. långt skridna planer på ett väldigt avancerat kodregister som dock skrotades för allt utom klasser då det ansågs ge för låga prestandavinster gentemot sin komplexitet om jag minns rätt.

Angående cachen av artikelpuffarna måste du ha missat exempelvis Views som lätt skulle slänga in allt det där i ex. Memcache-drivna cachar och aldrig ens vara i närheten av att göra en databasfråga så länge som resultatet redan är cachat. Dessutom lägger man ju något som Varnish eller Boost ovanpå det när det gäller nyhetssajter i den kalibern och då når de flesta anrop ju inte ens Drupal och än mindre databasen och Drupal borde mycket väl mäkta med. Och det är bara en av många möjliga vägar att gå.

Att Drupal inte skulle klara av större uppdateringar utan att ligga ner kanske delvis stämmer. Men där finns det initiativ såsom Aegir som gör det lätt att flytta en sajt mellan olika versioner av plattformar och såväl testa att en uppgradering gått bra som att utföra den utan någon nertid alls i princp – vad jag kan se.

Att kalla Drupal för en produkt av ett ”löst sammansatt gäng” är ju inte riktigt sant. Det finns många företag och många sajter som har satsat stort i plattformen och som tillsammans med många frivilliga bildar ett väldigt tight community. Att det dessutom enbart vore i teorin som någon annan tar över ett dött projekt är inte heller särskilt sant. Det finns inbyggda mekanismer i Drupals community för att ta över döda projekt och det är vad som uppmuntras – att istället för att skapa en miljon moduler som gör samma sak så ska man försöka samarbeta för att bygga ett fåtal bättre. Till och med hopplösa fall där även en av Drupals core-maintainerns sagt att modulen borde dö har vänt runt och fixats: http://www.davereid.net/content/state-of-drupal...

Alla som kör sajter på Drupal har ett gemensamt intresse av att Drupal ska må bra. Så länge det finns en kritisk massa som har det gemensamma intresset så kommer alltid underhållet av systemet att fungera på ett eller annat vis under en överskådlig framtid – om inte alla kommunikationsmetoder skulle utraderas så att man inte längre kunde samlas.

Att ex. Bonnier inte har som affärsidé att tillverka drupalmoduler är väl självklart – men det har väl ingen hävdat att de skulle ha heller? De producerar inte modulerna för att det skulle vara deras affärsidé utan för att det hjälper dem att tillhandahålla världens bästa websajter – vilket väl borde vara deras affärsidé om något. Exempelvis så jobbar om jag minns rätt skaparen av de tunga modulerna Views och Panels på Sony som ju bekant är ett skivbolag. Sonys affärsidé är musik – inte drupalmoduler – men de ser väl drupalmodulerna som ett led i att kunna förmedla sin musik.

Jag är övertygad om att det skulle gå att bygga i princip alla av de stora mediabolagens webbsidor i Drupal. Det går säkerligen att göra i EpiServer också. Jag skulle valt Drupal – men jag är inte insatt i EpiServer så jag kan inte säga att man inte bör välja det.

Drupal är extremt utökningsbart – har en väldigt stark community – en bra dokumentation och en god grund av bra moduler.
* Kajetan säger:
2009-11-23 kl 22:37 | Svara

Oj, det var en mastig kommentar. Jag håller med dig i mångt och mycket. Jag har träffat David från Four Kitchen och pratat databaser med honom och jag har träffat flera av de som driver drupal.org.

Jag måste först förtydliga vad jag menar med ”en mindre sajt”. Det är en ganska homogen sajt med upp till några tusen noder och under en miljon sidvisningar i månaden. Alltså sådant som man kan köra på ett webbhotell utan att bli utslängd för att man belastar för mycket. Alltså där

Jag är inte helt säker på att jag tycker WordPress är för mindre sajter än Drupal. De har lite olika syfte och man ska välja verktyg efter behov. :)

Jag håller dock inte riktigt med dig vad gäller moduler. Som jag skrev innan så tycker jag inte de flesta är något att ha. De stora som Views, CCK, Panels, Nodequeue osv. borde vara en del av Core eller i alla fall utvecklas parallellt med Core, men ”track record” ser inte ut så. Nu blir det väl någon sorts bättring på den fronten, men inte tillräckligt ännu.

Som jag skrev, jag tror att det säkert skulle gå att köra di.se på Drupal. Det skulle dock kräva så många anpassningar och omskrivningar av drupal att det inte skulle vara värt. Då kan man lika gärna välja ett annat system där man slipper anpassa ”core” så mycket och bara kan utöka det som finns.
o Henrik Sjökvist säger:
2009-11-24 kl 11:00

Jag håller dock inte riktigt med dig vad gäller moduler. Som jag skrev innan så tycker jag inte de flesta är något att ha. De stora som Views, CCK, Panels, Nodequeue osv. borde vara en del av Core eller i alla fall utvecklas parallellt med Core, men ”track record” ser inte ut så. Nu blir det väl någon sorts bättring på den fronten, men inte tillräckligt ännu.

Det finns en ovilja att inlemma moduler med hög utvecklingstakt som Views i core eftersom de då får en långsammare releasecykel och på så vis riskerar att hållas tillbaka. Sen spelar det ju i realiteten ingen som helst roll för en sajt om modulerna som används ingår i core eller inte. Är modulen viktig för många kommer den att underhållas oavsett. Det är ju det som är poängen med open source och ett starkt community.
Litar man inte på det kan man ju köpa sig support av något konsultbolag.

När i princip vem som helst kan skapa och lägga upp en modul på drupal.org är det klart att alla inte är mästerverk, men det spelar ju å andra sidan ingen roll, man behöver ju inte använda de som inte håller måttet. Nas blir ju inte sämre för att Dogge släpper en skiva.

Jag har ingen insikt i DI:s behov och varför core skulle behöva patchas, men vad gäller cachning så kräver D5 patchar för memcache och reverse-proxy (varnish, squid), D6 för reverse-proxy (eller så kör man Pressflow) och D7 inga alls.
23. Dick Olsson säger:
2009-11-24 kl 01:40 | Svara

Jag kan inte annat än att hålla med Pelle Wessman ovan.

Men vore det inte intressant med en ”Ultimate CMS Showdown”?

ULTIMATE CMS SHOWDOWN

Sätt ihop två lag; fyra Drupal-utvecklare och fyra EpiServer-utvecklare. Någon neutral person får sätta ihop en specifikation på en webbplats (förslagsvis en enklare tidningssajt eftersom det är aktuellt i denna diskussionen). Teamen får sedan 24 timmar på sig att möta specifikationen så bra som möjligt.

Lagen sitter tillsammans i en och samma lokal och alla 24 timmarna streamas live på nätet för bästa möjliga omvärldsbevakning.

UTVÄRDERING

När teamen lagt 96 timmar på webbplatsen (4 personer * 24 timmar) utvärderas webbplatserna utifrån ett antal kriterier som denna neutrala person anser vara viktiga för en webbplats. Lämpligt är också att någon form av kontrollerad belastningstest körs på sajterna.

Vad tror ni om detta? Vore det inte en rolig grej för att få diskussionen mer konkret och saklig? :)
* Kajetan säger:
2009-11-24 kl 01:56 | Svara

Tvärt om är detta precis sånt larv som gör att seriösa företag vänder i dörren.

På 24 timmar hinner du inte ens läsa igenom specifikationen. Inte ens om ni är 4 stycken.

Dessutom är inte detta någon ”Ultimate showdown” utan en förklaring till varför ett visst system inte fungerade för en vis uppgift.
* thr säger:
2009-11-24 kl 11:46 | Svara

Håller med Kajetan, 24 timmar? Hinner vi inte ens skriva alla use-cases på.
24. Henrik Sjökvist säger:
2009-11-24 kl 10:18 | Svara

Vi har Drupal med PHP och MySQL på ena sidan mot Microsoft .NET och MS SQL Server på andra sidan. De spelar inte ens i samma liga. Visst kan man få PHP och MySQL göra rätt mycket om man slänger hårdvara på dem med i enterprisesammanhang så saknas det rätt mycket. Både vad gäller funktionalitet och prestanda.

Både Digg och Facebook är byggda med PHP och MySQL. Vad jag förstår har Facebook efter hand bytt ut flaskhalskod mot specialmoduler skrivna i C (vilket skriptsspråk pallar 300+ miljoner aktiva användare?) och båda sajterna har migrerat delar av databasen från MySQL till Cassandra. Å andra sidan torde ju enbart Facebooks ”About us”-sida ha haft flera dagliga besökare än hela DI.se redan 2007.

Man kan ha mycket åsikter om PHP:s brist på elegans, men faktum är att väldigt många sjukt stora sajter rullar på LAMP-stacken, så frågan är vad som egentligen saknas i ”enterprise”-sammanhang förutom licensavgifterna och slipsarna.
25. Björn Sållarp säger:
2009-11-24 kl 23:43 | Svara

Mycket snack om att Facebook kör PHP men inte att de har 30.000. Ändå tycker jag Facebook känns lite slött ibland.
http://www.datacenterknowledge.com/archives/200...

Tänk vad mycket sidor man skulle kunna visa med så mycket hårdvara, oavsett språk.

Intressant och bra inlägg förövrigt, Kejtan. Med några få väl valda rader lyckades du locka hit de alltid så pålästa open source trollen som normalt kommenterar på IDG.
26. bjornlilja säger:
2009-11-25 kl 00:38 | Svara

@Björn: Menar du att antalet servrar skulle vara en indikation på att PHP är sämre? Det finns ganska få referenscase att jämföra med om man säger så…

Alla vet att olika programmeringsspråk skalar på olika sätt och gör det olika bra. Men när det kommer till RIKTIG skalning har programmeringsspråket väldigt liten betydelse, det är andra typer av lösningar (minnescachar, distribution, specialskrivna databaser) som levererar prestanda på den nivån. Därför är Facebook, Digg och Twitter inga bra exempel i den här diskussionen.

Hade Facebook behövt mer eller mindre än 50 terrabyte memdcache om dom kört .NET? Det är liksom inte en relevant diskussion.

Det är roligt hur ordet ”enterprise” retar gallfeber på många. Och man kan förstå varför. Det är tokigt omodernt att tro att det ordet på något sätt skulle borga för ”större och kraftfullare” lösningar. Lika tokigt är det att säga att ett givet programeringsspråk är mycket snabbare (låt oss säga C eller Python mot exempelvis .NET). Vilken halvtaskig implementation som helst kan förstöra den skillnaden.

Vi byggde DN.se med Java och Polopoly. Både språket och CMS:et har sina problem, men tack vare duktiga programmerare fungerar saker hyfsat bra. Någon annan har hackat en sajt i EPi eller Drupal och har sina problem.

Det handlar till slut alltid om man tror på fördelarna med ”the enterprise way” eller ”the open way”. Det är lite som Cola och Pepsi, alla vet ju att Cola är godare….eller?

Google kör Python förresten, det måste vara ett riktigt bra språk… Snabbt som tusan.

Nja... jag skulle nog inte kalla mig specifikt .Net-utvecklare. Jag är en utvecklare, dvs jag tar saker till en ny nivå ;). Jag löser problem med de verktyg jag tycker passar bäst. Dock blir det rätt mycket ,Net i jobbet ja, även om jag håller ett öga på ditv.se också, som är nästan helt Drupal. :)
Hej förresten.

Hej själv Kaj! (För dem som inte förstår kopplingen så skall jag berätta att jag en tid var konsult på DI:s IT-avdelning och hjälpte dem med bl.a. DiTV som kör på Drupal.)

Jag är lite förvånad över ditt blogginlägg. Jag minns att du inte var helt tillfreds med Drupal, men du hörde ju inte till de mest rabiata motståndarna. Tvärtom upplevde jag dig som försiktigt nyfiken på Drupal. Därför förvånar det mig att du i ditt blogginlägg framför en rad ogrundade eller direkt felaktiga påståenden.

I en del fall vet jag att du talar mot bättre vetande. Tag t.ex. din kommentar om att det "är ett skämt" att använda databasen som cache. Jag vet att du vet att Drupal har en pluggbar cache-arkitektur, i vilken memcache som regel pluggas in. Att dölja det faktum och istället lyfta fram och håna det som är tänkt som "fall back" för de allra enklaste sajterna är snudd på oärligt.

När jag läser ditt blogginlägg får jag en känsla av att du hos läsaren vill skapa rädsla, osäkerhet och tvivel (FUD) rörande Drupal. Men varför? Jag tror inte för en sekund att det ligger i Bonniers och DI:s intresse. Tvärtom!

Pelle Wessman har på ett förtjänstfullt sätt bemöt dina påståenden. Så istället för att jag gör om samma sak, och säkert inte hälften så bra, så hänvisar jag till Pelles svar på din bogg: http://tankemoln.wordpress.com/2009/11/21/varfo...

Jag gillar fortfarande Drupal när den används där den ska användas. Till det mesta faktiskt. Bonnier kör väl Drupal på en massa sajter i både USA och Sverige, så det är absolut inte Drupal som är problemet. Dock tycker jag, personligen (jag är ingen Bonniemegafon) att ett system inte bör användas till något det inte var tänkt för. Då blir det bara fel. Jag tycker det blev olyckligt att inlägget tolkas som någons sorts Drupal vs Epi-historia, för det var det inte alls tänkt att vara. Nu har jag dock ett nytt inägg på min blogg, så låt oss glömma det här :)

Det förstår jag verkligen. Som när jag intervjuade utvecklare på två av landets största mediehus. De som verkligen hade vettiga, objektiva synpunkter var de som faktiskt jobbat med flera CMS-plattformar. Det har du inom Microsoft och Open Source också - vilket inte är helt vanligt i det här landet.

Yup, som han själv skrev för 11,5h sedan ;)

Jag ska bli mindre anonym, jag lovar. Jag hade bara inte haft tid att slänga upp en introduktion. Trode inte att ett så tacksamt ämne skulle komma som uppslag för mitt första blogginlägg. /tankemoln

Var det, börja här i kommentarerna t ex. ;)

Du får en hint http://groups.drupal.org/user/21217

Hey! En från DI.se .NET-teamet, där snackar vi insatt.