Kæmpebilleder i frimærkeformat lagde folketinget.dk ned - igen

Er det kun der mig der har hænderne for ansigtet mens jeg hulker "nej, nej, nej" ?

Det må være et håbløst inkompetent IT-firma som har lavet det system.

Hvor mange af skatteydernes penge har vi nu spildt igen?

Det er utroligt at så dårlige udviklere rent faktisk har arbejde, endda under en finanskrise hvor der burde være mange om buddet.

Ingen løsninger er bedre end det svageste led. At en eller flere personer ligger hires billeder på et website uden at tænke over konsekvenserne er jo ikke systemet eller udviklernes skyld. Det svarer jo til at sige at det er DTP programmet eller offsets skyld at et lowres billed bliver trykt. Jo det ville da være rart at værktøjer beskyttede imod de væste dumheder, men det ved vi alle at vi ikke vil betale for.

Til Anders, Nej det er ikke altid kompetente personer, der betjener systemerne, men et fornuftigt CMS havde selv skaleret billederne ned i en fornuftig størrelse, det har TYPO3, som jeg mest arbejder med, gjort i alle de 5+ år jeg har brugt det.

At det så også havde sparet skatteborgerne en hel del penge er en anden sag.

Er ganske enig.
Det undrer mig også, at de ikke har tænkt deres løsning igennem, inden at de startede udviklingen.

Det er jo ikke bare en lille webside, det er trods alt en side, som man (muligvis) kan forvente en stor del af Danmarks befolkning kigger forbi.
At man ikke har optimeret og dimensioneret systemet fra starten af, er ganske simpelt for dårligt. Det er noget, som man lærer på næsten alle IT-uddannelser i dag som en af de første ting.

Det ligner lidt, at man har kastet en pose penge ud og håbet på, at der kan laves et system for beløbet.
Hvilket har givet det resultat, som man kan følge med i her på Version2. ;)

For de interesserede, så er det Addition der er leverandør: http://ted.europa.eu/udl?uri=TED:NOTICE:78936-2007:TEXT:DA:HTML

... kontrakten var på 10 mill.

Billederne skal jo bare afspejle størrelsen på politikernes egoer. Det er mere utroligt, at de kunne holde sig til 6 MB.

Og så kan man downloade billedet i høj opløsning :-)

"Download billede i høj opløsning (jpg, 4,5 mb)"

Nå, vi begår jo alle fejl ind imellem. Bare en skam for denne leverandør, at blive udstillet så offentligt.

-Claus

Men desværre voldsomt amatøragtigt at deres webredaktører ikke er i stand til at generere en thumbnail af et billede inden de uploader det til deres cms. Det har intet med udviklerne at gøre, men ene og alene at den person som har bygget siderne op, har glemt en helt basal ting. Det har hverken noget med webcaching eller automatisk skalering at gøre. Det er et spm om at redaktøren af siden rent faktisk har en forståelse for basal web-opbygning. I dette tilfælde har opbygningen af siden så været overdraget til en person som ikke har den fjerneste anelse om bearbejdning af grafik eller webopbygning. Det er jo desværre problemet (og fordelen!) ved CMS'er af denne størrelse. At det giver personer uden den store faglige viden mulighed for at kunne lave indhold til siderne på en måde så det er i tråd med de retningslinjer der er afstukket fra dem der ved noget om det. I dette tilfælde gik det så bare grueligt galt. og redaktøren har med sikkerhed lært noget! :-)

Nej, billeder og størrelsen på dem er så centralt for hastigheden, at systemet skal kunne håndtere det.

Hvad med en lasttest inden prod? Den ville da have afsløret det her. Bruger selv LoadRunner med J2EE diagnstics.

Hvis formålet med et CMS er at give personer uden (web)faglig viden mulighed for at lave indholdet, er det vel netop CMS'ets og dets udvikleres skyld, når dette sker, da det jo ikke har levet op til sit formål. Eller hur?

Det er ligeså kløgtigt som retsinfo, hvor en af bekendtgørelserne består af en b[/b] side på over ½ GByte, udelukkende lutter indscannede sider, som billedfiler af tekst!

Og så (nogen må gerne forklare hvorfor) lykkes det åbenbart asp servere at overtage magten over browseren, så eneste udvej, mens ens internetforbindelse er ved at blive rødglødende er at slå browseren ihjel.

Hvis man henvender sig til retsinfo, så får man spitzenklasse svar:

Tak for din henvendelse af 6. juli 2009 vedrørende bekendtgørelse nr. 617 af 26. juni 2009. Vi er opmærksomme på, at det kræver mere kapacitet end sædvanligt at åbne siden.

Mere kapacitet end sædvanligt - suk.

/Christian

Det er ligeså kløgtigt som retsinfo, hvor en af bekendtgørelserne består af en (en) side på over ½ GByte, udelukkende lutter indscannede sider, som billedfiler af tekst!

Det er jo bilaget fra EU som fylder... det meste i Retsinfo i ren tekst. Jeg vil tro at det er fordi de ikke ville ændre i bilaget.

Og så (nogen må gerne forklare hvorfor) lykkes det åbenbart asp servere at overtage magten over browseren, så eneste udvej, mens ens internetforbindelse er ved at blive rødglødende er at slå browseren ihjel.

Forkert browser måske ? ;-)
I Firefox 3.0.x med NoScript på Linux kunne jeg godt lukke det låste faneblad.

Det er i øvrigt indholdsleverandørernes våde drøm at have en webserver som kontrollerer din browser, vidste du ikke det ?

Det vil det ikke er projektets udviklere (som sikkert har måttet leve med en fastpris kontrakt på 10 mio.), der har dummet sig, men igen en ledelse af et software indkøb, der har investeret i et inkompetent stykke CMS software? I det her tilfælde Sitecore.

Lad mig starte med min holdning gennem knap 30 år som udvikler:
Der findes [b]ikke[/b] dumme brugere, kun [b]dumme systemer[/b]!

I den forbindelse synes jeg det er uhørt at brugeren (redaktøren?) skal tage stilling til, og bruge tid på at skalere billeder inden upload.

Normal praksis, som selv nybegyndere kan finde ud af, er, at lave en upload funktion.

Denne funktion skal kunne modtage en arbitrær størrelse af en given fil og [b]selv[/b] skalere til den ønskede størrelse.

Så forretningsgangen for en uploadfunktion er ca:
1) Modtag billedet (i systemet)
2) Hvis width > maxwidth eller height > maxheigt, så skaler ned til den ønskede størrelse, hvor man bevarer aspect ratio.
[b]Samtidig[/b] dannes en thumbnail i den ønskede størrelse.
3) Disse 2 filer gemmes, og evt. en højopløselig (originalen), hvis man skal lave plakater.

Så er der nogle der mener (ud fra et brugersynspunkt), at man kan benytte billedet som thumbnail ved at skalere ned i browseren, da det store billede derved er tilgængeligt i browserens cache.
Men det forudsættter, at man vil se 'det store billede', ellers er det total spild af båndbredde.

Ud fra artiklen, lyder det som om man har begået de mest fundamentale fejl, altså:
- Undlade at skalere ned servereside.
- Undlade at generere thumbnails.

Suk - disse ting har man kunnet finde på nettet gennem formentlig en halv snes år.

Vi skal også kigge på caching

Caching hjælper ikke på det faktum, at man bruger ~873 KB på en simpel forside.
Det vil være bedre at muge ud i møget.

(Eller købe en 1Tbps linie)

Det er jo bilaget fra EU som fylder... det meste i Retsinfo i ren tekst. Jeg vil tro at det er fordi de ikke ville ændre i bilaget.

Ja, men indholdet er ren tekst, så lur mig om ikke det eksisterer i elektronisk format - jeg tvivler det er lavet på en gammel IBM kuglehovedmaskine.

Og ellers så er der altså noget der hedder OCR.

Herudover, hvis de så endelig skulle lave noget så tåbeligt, så kunne de i det mindste dele bilaget op i bidder, som lå på egne sider, og så linke til dem - på den måde undgår man at loade ½G data for at læse selve bekendtgørelsen der fylder nogle få kb.

/Christian

Det burde næsten kræve at firmaet der har lavet siden får en bøde.

De må jo ikke have en skid forstand på hjemmesider.
Selvom jeg kun laver hjemmesider til privat brug har jeg da aldrig gjort noget SÅ DUMT!

De siger at

Vi har netop genstartet serveren, men det er nok et problem, som kommer igen,

Så er det jo ikke store jpegs der er problemet for det kan man jo rette på kort tid. Skulle de så ikke have lidt mere bandwidth eller en ny server?

Er der nogen af de folk, der kritiserer sitecore, som rent faktisk har arbejdet med systemet?

Jeg er helt enig i, at det ikke bør være webredaktørens ansvar manuelt at generere thumbnails af billeder til sitet, især ikke da man sagtens kan forestille sig, at det samme billede skal anvendes i mange forskellige dimensioner på et site.
Men sitecore har faktisk en glimrende, indbygget funktion til dette. Det eneste, det kræver er, at udvikleren angiver den ønskede bredde, højde, maxbredde, maxhøjde etc. hvor billedet udskrives, så skaleres det serverside og gemmes i cachen. Simpelt og godt.

Ifølge min erfaring er sitecore et virkeligt fint CMS, med mange muligheder for effektiv performanceoptimering, men tankeløs brug af systemet kan selvfølgelig give nogle ret uheldige resultater. Uden at kende de nærmere omstændigheder, vil jeg antage, at skylden ligger hos udviklerne, ikke softwareindkøberne.

Jeg vil gerne tilslutte mig Stig Johansens holdning, dog med en lille tilføjelse:
Der findes ikke dumme brugere, kun dumme systemer - og uvidende udviklere.

Jeg vil gerne tilslutte mig Stig Johansens holdning, dog med en lille tilføjelse:
Der findes ikke dumme brugere, kun dumme systemer - og uvidende udviklere.

Hmmm. Hvordan hænger din holdning her sammen med at Sitecore fungere? Det er vel systemet der er dumt, fordi det har tilladt brugerne (udviklerne og/eller redaktøren) at lave noget som får systemet i knæ.

Det er vel systemet der er dumt, fordi det har tilladt brugerne (udviklerne og/eller redaktøren) at lave noget som får systemet i knæ

Jeg vil give dig fuldstændig ret.
Det må helt klart være PC-systemet der er noget galt med. Hvis man havde brugt en Wii i stedet for, så kunne (udviklerne og/eller redaktøren) ikke lave noget galt.
Hvis man ikke kan lave noget galt, så er der som regel ikke nogle muligheder.

Hvis pågældende udviklere havde lavet det i PHP eller et andet CMS, så havde de jo lavet samme fejl.

Hvis pågældende udviklere havde lavet det i PHP eller et andet CMS

Inden jeg bliver flamet om PHP ikke er et CMS, så lad mig omformulere:
Hvis pågældende udviklere havde lavet det i from scratch i PHP eller et andet CMS end Sitecore

Hehe - ja.
Med stor fleksibilitet kommer stort ansvar. I dette tilfælde tilsyneladende lidt mere, end udviklerne kunne løfte.

I dette tilfælde tilsyneladende lidt mere, end udviklerne kunne løfte.

Er det noget du ved, eller noget du har hørt?

Noget det ser ud til, deraf tilsyneladende.

Som tidligere skrevet, kender jeg jo ikke de nærmere omstændigheder omkring udviklingen og kan derfor på basis af de præsenterede informationer og mit sitecore-kendskab blot antage, at det omtalte issue skyldes et mindre glitch i udviklingen - eller en mangel i kravsspecifaktionen eller kvalitetskontrollen, om man vil :)

Jeg opponerer (og er spydig, undskyld for det), fordi du hænger udviklerne ud og dømmer dem, uden at vide om de har skylden, pas på med det :-)

Er jeg den eneste, der sidder og smiler en smule over, hvorfor det netop er Sophie Løhde, der er blevet fundet frem af de 179 medlemmer?

:o)

Folketinget var ret tidligt ude med et flot og effektivt system, der hurtigt gjorde det muligt at følge med i deres arbejde. Senere har de så klistret en mere imødekommende (og rigeligt overlæsset) portal foran, men heldigvis var dokument-oversigten fortsat i et mere minimalt design.

Nu er dokument-oversigten så desværre blevet fuldt integreret i det stadigt tungere layout. En mere elegant løsning kunne være at udnytte CMSets fleksibilitet, og give brugerne mulighed for frit at vælge mellem lagkagepynt og et strammere design.

Samtidig er alt før 2004 efterladt i en skuffe for sig, med forkerte billedlinks. Det betyder, at almindelige søgninger behændigt glemmer fortiden, hvad de fleste politikere vel er godt tjent med...

Også alle vore gamle links ender nu i en ikke særligt imødekommende fejlside. Lidt simpel programmering kunne have genereret det korrekte link ud fra det gamle, men det er åbenbart for meget forlangt...

Endelig kræver links til mail-adresserne en lokal email-opsætning, hvilket udelukker kontakt via webmail etc, da systemet ikke på en nem måde fortæller adressen.

Det hele virker lidt forhastet og uigennemtænkt, men det kan vel nå at komme på plads. Ovenstående er også skrevet til webmasteren.

der har været på overarbejde.
Nu fylder billedet af Sophie Løhde kun 12.86kB i formatet 133x133.
Det samme gør Holger K's billede ;-)

/Claus

He, he...
Forestil dig samme motiv fra et af de (meget) ældre mandlige medlemmer.
(Eller mit eget øje for den sags skyld :-)

Sophie har jo et kønt øje!

/Claus
PS. Er det mon venstre eller højre øje vi ser?

Nej, nej, nej...
De er, i skrivende stund, vist ikke helt færdige med overarbejdet derinde på borgen!

Checkede lige DF (!) og her er properties for Pia Adelsteens thumb nail billede:
3632px × 3632px (scaled to 84px × 84px)
5602.77 KB (5737239 bytes)

• Og for Liselott Blixt:
  84px × 84px
  7.71 KB (7895 bytes)

Ku' ikk' li' la' være :-)

/Claus

"Addition søger kompetente Sitecore CMS konsulenter"
http://www.addition.dk/About/Careers.aspx

Det er da dejligt med et firma som har selvironi... :-)

Sitecore er i øvrigt et udemærket CMS.
/C

Vi kan alle begå fejl. Og det er derfor vi tester.

Det virker ikke som om der udført tilstrækkelige performance-test af folketingets system i det her tilfælde. Når det samtidig går 'live' samme dag, som folketinget har åbningsdebat virker næsten overmodigt.

Jeg undres - hvad er der blevet udført af test forud for lanceringen, og hvordan har man vurderet risikoen ved at 'gå live' med et nyt system på en af de dage, hvor man på forhånd må kunne forvente større belastning end normalt?

/Niki

Hej Niki,

Du kan læse om, hvilke test sitet var igennem inden lancering, her:

http://www.version2.dk/artikel/12458-leverandoer-undgaar-skideballe-efte...

vh.

Jesper
Version2

Vi kan alle begå fejl. Og det er derfor vi tester.

Ja, men i det her tilfælde tror jeg ikke der har været tale om decideret test.

Det virker ikke som om der udført tilstrækkelige performance-test af folketingets system i det her tilfælde. Når det samtidig går 'live' samme dag, som folketinget har åbningsdebat virker næsten overmodigt.

Jo, men det har åbenbart været tiltænkt, at 'live' skulle ske samtidig med folketingets åbning.

Fra:
http://www.version2.dk/artikel/2096-ny-cms-loesning-skal-loefte-folketin...

forventes i drift samtidig med åbningen af Folketinget i oktober 2008

Se bort fra årstallet, men man har vel ligesom haft et år ekstra til netop at raffinere systemet.

MHT test, så vil jeg godt sætte en kasse øl på højkant i forhold til følgende postulater:
- Der er [b]ikke[/b] lavet en ordentlig funktionsprøve, fordi:
Hvis det havde været gjort, så ville man have opdaget det der latterlige med at skalere store billeder til thumbnails.

• Der er [b]ikke[/b] lavet en availability prøver over 30 dage (subsidiært 20 arbejdsdage), fordi:
  Så ville disse søgebotter, som angiveligt skulle være et problem, forlængst have indexeret siderne, og dermed ikke udgøre et problem.

• Der er [b]ikke[/b] lavet en svartidsprøve (subsidiært stresstest) fordi:
  Så havde man forlængst observeret, at systemet stod af i en sky af hestep....

Det undrer mig, efter et års forsinkelse, at man idriftsætter et utestet system, uagtet man skulle tro, at det forgangne år skulle have plads til test/kvalitetssikring osv..

Det kan da godt være at der ikke er udførst tests, og at man ved at have udført disse havde fundet og rettet de fejl der nu er. Det er dog ikke kernen i problemet.
Det kan kun ses som symptombehandling, da det jo ikke er her hunden ligger begravet.

Man kan som bekendt ikke teste god kvalitet ind i et produkt, (en bil bliver ikke bedre kvalitet fordi den skal køre den dobbelte distance på testbanen), det har Toyota m.fl. lært os. Altså må man tilbage og spørge sig selv (5 * WHY), for at finde root cause, som ganske givet ligger i en for dårlig proces omkring udvikling, endsige, de meget snævre rammer der ligger i kontrakterne når man arbejde med IT for den offentlige sektor.

Så lad os nu en gang for alle finde root cause for alle disse problematiske offentlig projekter, uagtet hvem der er leverandør, hvilke produkter osv. der er involveret.

I dag er der 2 konktraktformer i IT verdenen (fast pris og timebaseret), begge har de en ting til fælles, den ene part bærer al risiko, og er næsten garanteret at blive taber, altså win/loose eller loose/win.

Lad os nu begynde at bruge nogle mere tidsvarende konktraktformer, så det lugter lidt mere af win/win.

Og så skal vi altså til at tage os sammen proces mæssigt - ligesom vi skal blive langt bedre til at finde ud af hvad ting koster.

Tjek linket til gæstebogen:
"<a href="/Aktuelt/Gaestebog_betatest.aspx">Sig din ærlige mening om ny ft.dk</a>"

Det virker, "ærligt talt", lidt amateurish, at have noget med "beta" på en side i drift - det burde være testet til døde før det blev lagt op. Det er jo ikke en familieside - den har jo sikkert kostet et par kr.?

Jeg har tabt en del fremtidige kunder på at være kompetent. Hvis man vil vinde kunden skal man være billigst - ikke bedst.

Så lad os nu en gang for alle finde root cause for alle disse problematiske offentlig projekter

'root cause' er EU udbudsprocessen, som vi ikke lige kan ændre.
så:

Lad os nu begynde at bruge nogle mere tidsvarende konktraktformer

ligger ikke lige om hjørnet.

@Gunnar:

Hvis man vil vinde kunden skal man være billigst - ikke bedst

Det kommer ganske an på hvilke udvælgelseskriterier, der er fremsat i udbudsbekendtgørelsen.

Jeg har f.eks. engang lavet kravspec'en til udbud af hosting af Navition Stat.
Det der var tale om statens økonomisystemer med dertil hørende oplsninger/betalinger m.v. var 1. prioritet [b]sikkerheden[/b], og ikke prisen.
Så uanset prisen, så ville man dumpe på sikkerheden, hvis den ikke var tilstrækkelig.

men tilbage til tests:

Det kan da godt være at der ikke er udførst tests....

Det er en lidt dårlig analogi du fremfører her.

I disse offentlige projekter, er der tale om indkøb af ubesete varer, alene baseret på funktionelle (og objektivt [b]målbare[/b]) krav.

Der er med andre ord ikke tale om at teste i den forstand, men at 'inspicere varen'.

Man kan ikke købe en 'Toyota', men et 'Transportmiddel', der skal opfylde nogle krav.

Hvis man har krævet, at dette 'transportmiddel' skal kunne køre 200 km/t, så er det naturligt, at efterprøve om det nu også kan det.

På samme måde, hvis dette 'transportmiddel' skal kunne transportere minimum 20 samtidige passagerer, så er det også naturligt at efterprøve det.

Core problemet er, at man allerede i kravspec'en definerer systemet, og det er det, det bliver givet bud på.

Ændringer undervejs vil naturligvis koste ekstra i det omfang ændringen ikke er forudset i kravspec'en.

Så 'it simply boils down to':
For dårlige kravspec's og eller manglende 'inspicering af varen', som åbenbart er tilfældet i denne sag, med mindre der ikke har været krav.

Det er klart, at hvis der ikke har være krav om svartid, antal samtidige brugere, oppetid, minimalistisk javascript, CSS osv, så kan man ikke gøre gældende, at der er tale om en mangel.

Hmm.. - i skrivende stund er siden utilgængelig - hvilken undskyldning mon man vil bruge denne gang?

Interessant, at man skal have minuspoint for at beskrive den virkelige verden.

Men jeg tillod mig lige at montere en monitor med 1/2 times interval, og her er resultatet:
[pre]
MonitorLogsId(INT);MonitorURIsId(INT);TickId(FLOAT);TickSubId(INT);StartTime(FLOAT);StartTick(FLOAT);EndTick(FLOAT);NumberTicks(FLOAT);StatusCode(INT);StatusString(TEXT);NumberOfThreads(INT);ConnectTime(FLOAT);FirstToLast(FLOAT)
1;1;1380094200.37702;10001;40100.372044;1380094200.97103;1380104256.3132;10055.342173;10110;;1;55.108491;9999.669997
2;1;1380135277.08059;10001;40100.37252;1380135277.65976;1380145335.08;10057.420235;10110;;1;55.986869;10000.739242
3;1;1381935293.7528;10001;40100.393353;1381935294.2432;1381935475.07331;180.830103;200;OK;1;49.426882;43.490836
4;1;1383735298.19164;10001;40100.414187;1383735298.69203;1383735439.47508;140.783055;500;Internal Server Error;1;49.35551;36.62147
5;1;1385535306.71847;10001;40100.43502;1385535307.21109;1385535488.09678;180.885693;200;OK;1;49.100672;46.200528
6;1;1387335311.28887;10001;40100.455854;1387335311.77938;1387335500.63887;188.859483;200;OK;1;54.902034;47.665443
[/pre]
Jeg har ikke til hensigt at komme med forklaringer på indholdet, da der tilsyneladende ikke er det fornødne kendskab til 'tingenes tilstand', men jeg går ud fra, at man i det mindste ved, at 200 OK er essentielt.

Interessant, at man skal have minuspoint for at beskrive den virkelige verden.

Måske fordi "to be" er mere interessant end "as is"?

... kontrakten var på 10 mill.

Gad vide hvor meget det vil koste, hvis man beder dem om at tænke samtidig ? :)

Interessant, at man skal have minuspoint for at beskrive den virkelige verden.

Også lidt interessant, at nogle går op i om de får minuspoint :)