Jeg hader Microsoft .NET!
Hvordan kan det være, at alting skal tage 10 gange så lang tid at udvikle i Microsoft .NET som i stort set alle andre udviklingsmiljøer? Og hvordan kan det være, at når tingene så endeelig er kodet færdigt, så er det så tungt at man skulle tro det var løgn? Og hvordan kan det være at den HTML der spyttes ud – de færdige sider, under .NET altid ender med at være 3 gange så omfattende kodet som på de fleste andre systemer? Hvorfor er det som regel umuligt at opnå en code-to-text ratio på .NET sites på over 5%?
Jeg sidder p.t. og forsøger at få et stort eCommerce website optimeret. Ikke alene kører dette website under .NET med for at gøre det hele endnu værre er det opbygget under Microsofts Commerce server. Død over den! Magen til crap skal man satme lede længe efter. Det er muligt den commerce server kan et eller andet fantastisk – jeg har bare ikke fået øje på det endnu under den bunke af problemer som overskygger alt.
Det har kostet denne kunde alt, alt, alt for mange resurser (læs: penge!), at udvikle denne løsning, og hver gang jeg gerne vil have ændret en lille bitte ting tager det 2 dage, hvor det ville tage 30 minutter på alle andre platforme. Gang det så op med de hundredevis af små ting der SKAL ændres hvis dette site skal rykke i søgemaskinerne og så ser du problemernes omfang.
Og udgifterne vil fortsætte med at stige med samme faktor. Hver eneste lille forbedring der skal laves over de næste mange år, vil koste denne kunde 10-30 gange mere end de konkurrenter, der har valgt mere fleksible platforme.
Og så har vi slet ikke snakket om den tid der går med inddatering af produkter, tilpasning af side-indhold og META-koder. Alting tager 10 gange så lang tid på den platform. Det tager mig flere minutter at opdatere titel, META-tags og et tekstfelt pr. side. Det burde tage 10 sekunder!
Og når jeg så har lavet en rettelse slår den ikke igennem på sitet. For i en .NET løsning bliver man nødt til at cache alle aider. Hvis de ikke bliver det er det på det nærmeste umuligt at få en side frem, inden ens computer er blevet forældet. Det er groteskt langsomt.
Hvorfor tager det så lang tid at loade en simpel produktside i .NET? Hvad er det der sker inden i de systemer, som gør at noget der burde være simpelt og ligetil, bliver så ufatteligt tungt?
Det er muligt at de folk der arbejder på de kunders løsninger jeg sidder med bare ikke er særlig gode. Det kan jeg ikke vurdere. Og det er muligt at man kan lave lynende hurtige og kode-effektive publiserings-løsninger under .NET. Jeg har bare ikke selv set dem endnu.
Thomas skriver
hehe så er vi 2, for jeg er helt enig. Jeg har heldigvis ikke arbejdet så meget med det.
Mikkel deMib Svendsen skriver
Jeg vil tror at godt halvdelen af mine store kunder kører på .NET, så jeg har arbejdet rigtig meget med det. Og jeg kan ike rigtig undgå det, hvis jeg gerne vil arbejde med de kunder som jeg gør.
Søren Sprogø skriver
Jeg er ked af at sige det Mikkel, men det er ikke teknologien der har skylden.
.NET og Commerce server er et værktøj (framework), og en hammer er kun så god som den håndværker der svinger den.
Jeg har stor erfaring med .NET, og en del med Commerce Server (også den nyeste), og har set løsninger der kører perfekt og som er nemme at opdatere. Men fælles for disse løsninger er, at en “smed” med forstand på eCommerce og SEM har været med til at definere kravene, og svinge pisken over udviklerne.
Især vil jeg understrege at Commerce Server er et framework, og med mindre man customizer dele af det kraftigt med dine krav for øje, ja så får man noget der er tungt og besværligt.
Men igen, lad være med at skylde skyden på værktøjet. Det er simpelthen for nemt. Det er udelukkende projektlederen og udviklernes problem, at de ikke har haft ordentlig kendskab til teknologiens fordele og begrænsninger, og hvordan disse benyttes til at lave en fremtidssikret løsning.
Mikkel deMib Svendsen skriver
Min kritik er sådan set bare en opsumering af de praktiske erfaringer jeg har fra arbejdet med virkelig mange virksomheder på mange forskellige platforme. Og når jeg sammenligner alle dem der er på .NET og dem der er på andre platforme passer min kritik meget godt: Det er dyrere at udvikle, dyrere at rette i, og det ender med at blive tungere.
Du har givetvis ret i at det ikke behøver være sådan. jeg har også set mere specialicerede ting – ikke eCommerce, sites og applicationer i .NET som kører fint. Mit eget firmas framework for al produktion og kunder-kontakt kører i .NET – det har vi udviklet fra grundet. Og det er også OK, men det har bestemt også taget lang tid at få udviklet 🙂
Bo Drejer skriver
Hej Mikkel,
Det er jeg ked af at høre!
Du er meget velkommen til at tage fat i mig hvis du løber ind i problemer eller frustrationer. Der er mange måder at løse en opgave på og ikke alle projekter er jo grebet rigtigt an, så jeg er meget enig med Søren…faktisk er .NET stormet frem de sidste 3 år pga. hurtig udviklingtid…men jeg har da også set projekter som er kørt i skoven….
Jeg sidder i Microsofts DPE gruppe som har ansvaret for bl.a. udviklingsværktøjerne og .NET og vi vil meget gerne i dialog med skarpe folk, også SEO folk som dig!.
Så lad os da tage en snak om dine erfaringer i den nærmeste fremtid…hvad siger du, er du frisk? I am all ears!
Ciao 🙂
Bo
Daniel Nøhr skriver
Er godt nok en skam du har oplevet en del negativt ved .NET, der er selvfølgelig altid plus og minus ting men syntes bestemt at det er et kanon fedt programmerings sprog at arbejde med.
Jeg gik fra ASP classic og til ASP.NET og jeg går aldrig tilbage, der er simpelthen så mange fede ting i det framework også er plusset jo at jeg kan lave windows programmer osv. med samme sprog.
Indtil nu har jeg smidt mit meta og title i dens page_prerender load sådan jeg holder det lidt adskilt, dog har jeg ikke erfaring med eCommerce, men lyder ikke for godt mht. til den kunde du har haft!
Daniel Jepsen skriver
På et tidspunkt arbejdede jeg også en del i .NET, men synes også det kørte meget sløvt iforhold til det jeg ellers var vant til. Men må sku give Søren ret i at, det nok kommer an på manden bag skærmen og hvad man er vant til at arbejde i til daglig;)
Mikkel deMib Svendsen skriver
Hej Bo, jeg er frisk på at mødes. Smid en mail på mikkel@joyzone.dk så kan vi aftale nærmere.
Jeg ved at det teoretisk set er muligt at udvikle meget hurtigt i .NET – jkeg har selv set det demonstreret. men hvorfor tager alle de projekter jeg støder ind i så altid så lang tid? (mange forskellige udviklere i mange lande)
Og jeg mener da også, at hvis man afvikler flere ting i form af kompilerede komponenter på serveren, frem for i scripting sprog som ASP og PHP, så burde det gå hurtigere. Hvorfor oplever jeg det så næsten altid omvendt?
For, jeg kan da ikke forestille mig at det er fordi alle MS udviklerne er dårlige, og alle ‘Nix udviklerne er gode 🙂
Markus Loong Brandt skriver
Jeg har lidt blandede følelser hvad der angår NET framework. Jeg har været projektleder på nogle NET projekter og jeg må da give folk ret, der er sgu smeden og ikke hammeren det er galt med.
Bare et exempel, projetktet skulle generere et worddokument ud fra en skablon med omkring 6000 database indlæg. De første programører på projektet programerede løs og resultatet var at et tryk på knappen “dann word dikument” udløste 1 times fuld belastnig på serveren (double XEON 4GB ram) og i 7 ud af 10 tilfælde kom der en timeout fejl istedenfor et word dokument. Det kunne vi ikke leve med så vi fyrede programørene og fandt en ny. Han brugte 2 dage til research oge 1 dag til at programere (de andre tog 2 uger) resultatet var at processen tog 1 sekund uden mærkbar belastning på serveren.
Så ja.. smeden.. helt klart
Mikkel deMib Svendsen skriver
Er konklusionen så, at der er mange flere amatører blandt .NET udviklerne end blandt ‘nix udviklerne?
Søren Sprogø skriver
Problemet er, tror jeg, at du får utroligt mange redskaber foræret i .NET!
Brug for en listbox, der lister et databaseresultat? To liniers kode, og du behøver ikke lave noget HTML!
Brug for at liste et databaseresultat i en tabel, med edit, add og delete knapper? 5-10 liniers kode, og du behøver ikke lave noget HTML!
Men problemet er at disse “værktøjer” har det med at generere dårlig HTML, hvis man bare bruger dem som standard-værktøjer. Og hvis du ikke er over udvikleren med en pisk, vil han selvfølgelig forsøge at skære hjørner her. Det drejer sig jo oftere om at blive hurtigt færdig frem for at levere “god HTML”.
Så ja, når det kommer til .NET findes der utroligt mange “dårlige” udviklere. Men det er simpelthen fordi værktøjet er så nemt at bruge, og at det er for nemt for ellers “gode” udviklere at skære hjørner.
Men igen, Commerce Server er et elendigt produkt, hvis du ikke kender dets svage sider og kan finde ud af at gå ind og dække dem med din egen udvikling.
Til gengæld, en korrekt udviklet Commerce Server leverer nogle af de mest stabile og hurtige sites jeg nogensinde har set.
Så hvis du har brug for en snak om tingene med en UDEN for Microsoft også er du da mere end velkommen til at tage kontakt til mig også 😛
Morten Bock Sørensen skriver
Man kan vel sige at .NET er relativt nyt set i forhold til ‘nix sprogene, og derfor kan der vel også med god grund spekuleres i at der måske ikke er så mange erfarne udviklere, endsige udviklings chefer, og derfor er der måske nogle projekter der bliver grebet forkert an?
Jeg er selv forholdsvis ny i .Net verdenen, og arbejder primært med CMS’er, og der er der også stor forskel på hvordan systemer håndterer det faktum at de er skrevet i .Net. Nogle har blot “konverteret” metoderne fra deres gamle asp systemer, og udnytter altså slet ikke potentialet, mens andre igen har set pointen i .Net og dermed kan lave rasende hurtige systemer. Igen er det sikkert fordi systemudviklerne på de langsomme systemer ikke har en million open source projekter de kan hente inspiration fra, som der ellers har været tradition for i ‘nix verdenen?
Mikkel deMib Svendsen skriver
Min opgave er normalt ikke at udvikle sites, men jeg rådgiver ofte kunder om deres valg. Jeg må sige at jeg i stigende grad bliver nødt til at anbefale folk at overveje andre løsninger end .NET for når man ser på de samlede fordele og ulæmper og den samlede økonomi så hænger .NET bare ofte ikke sammen.
Jeg kan ikke huske et eneste .NET projekt jeg har været involveret i nogensinde, hvor den aftalte produktionstid har været overholdt. Hver eneste gang tager det længere tid end udviklerne mente det ville tage. Alene dette er et så stort problem, at det giver et stort minus i min bog.
Og jeg er helt enig med dig Søren i, at den kode der spyttes ud som standard er sindssyg dårlig. Hvorfor kan Microsoft ikke skrive ordenlig HTML?
MartinHN skriver
Jeg tror du har helt ret i, at der er flere amatører blandt .NET udviklerne. Kig selv på http://www.asp.net hvor du finder artikler, videoer, starter kits hvor du kan lære rigtig meget. Når du får så meget smidt i hovedet og får så hurtige resultater, er der nok nogle som tror de kan det hele. Men alt mht. skalérbarhed, afkobling, arkitektur osv., er mere eller mindre glemt. Alt bliver stort set lavet i brugergrænsefladen, og det er jo meget kritisk hvis en kunde f.eks. udskifter deres database-platform.
Søren Sprogø skriver
HTML-koden, som kontrollerne i .NET spytter ud, er dårlig/rodet fordi de skal kunne håndtere utroligt mange forskellige ting uden at udvikleren behøver at tænke over det.
Men hvis smeden kender sin hammer ordentligt ved jeg at en god udvikler med få redskaber kan få koden til ikke alene at være 100% W3C compliant, men også overholde forskellige standarder inden for tilgængelighed.
Igen igen igen tyder alt hvad du siger på at du har været udsat for utroligt mange dårlige håndværkere og projektledere. Årsagen til det skal nok findes i at hvis SEM og nem vedligeholdelse ikke er tænkt ind i projektet fra start af (uanset teknologi), så kan det være et helvede at rydde op i. Og det virker som om du altid kommer ind EFTER et system er blevet bygget og derfor sidder med et utaknemmeligt job.
En ting vil jeg dog give dig ret i: Script kode, som PHP og Classic ASP, er meget nemmere for enhver at gå ind og lige rette en smule HTML i uden man behøver de store programmeringskundskaber.
Compilet kode derimod kræver en programmør, og en ofte lang og besværlig migreringsprocess. Det har så et utal af andre fordele, som vil tage for lang tid at remse op her.
Men det er vel derfor at man normalt har skilt frontend’en (præsentationslaget) ud i nemt ændrede templates, og holdt al HTML ude fra kildekoden (forretningslogikken)? For det har i vel gjort i jeres projekt? 😉
Ellers følger man ikke Microsoft’s egne anbefalinger for hvordan teknologien best benyttes (n-Tier modellen kort fortalt), og så er vi tilbage til problemstillingen med håndværkeren og hammeren…
Anders Carlsen skriver
Ja, hvorfor er ASP.net så langsomt og hvorfor er der så mange som anvender det værktøj når der er så mange andre værktøjer som er meget skarpere. Og hvorfor sulter folk i Afrika nå der egentligt er mad nok og hvorfor betaler Undervisningsministeriet 55 milioner for et netsystem som ikke virker, når man kunne have fået et system til en tiendedel af prisen som virkede.
Det korte svar er uvidenhed. Uvidenhed er årsagen til al lidelse. 🙂
ASP.NET er fra starten af designet på en ide som jeg mener er en logisk fejl. Ideen er at man som udvikler skal kunne programmere som applikation uden at forholde sig til om slutressultatet er en windows appliktion eller en web applikation. En smuk tanke som desværre er totalt uden jordforbindelse og uden hold i virkeligheden.
Der var en der sagde at ASP.NET er jo bare et værktøj. Ja man kunne sige at ASP.NET / Visual Studio er en schweizerkniv med 120 funktioner. Den er flot og blæret og har skruetrækker, saks, tandbørste og al muligt. Som håndværker vil jeg dog ha en skruetrækker når jeg skal bruge en skruetrækker. Men ok, hvis kunden incisterer på at jeg bruger schweizerkniv så må jeg jo bøje mig.
Mikkel deMib Svendsen skriver
jeg synes du har en god pointe der, Anders. “One-size-fits-all” har det med ikke at passe til noget som helst. Og ja, en schweizerkniv kan 100 ting – men ikke en eneste af disse ting gør den bare halvt så godt som et dedikeret redskab. Måske er det der aben ligger begravet med .NET … I don’t know …
Jeg savner alvorligt, når kunder vælger system, at de laver en seriøs vurdering – stiller fordele og ulæmper og økonomi op ved siden af hinanden på de forskellige løsningsmuligheder. Gjorde flere det, er jeg 100% sikker på at mange ikke ville have valgt .NET.
Desværre sker der ofte det, at folk henvender sig til en leverandør, og så bliver det denne leverandørs begrænsninger der afgør systemvalget. Mange af de burauer der er gode (eller siger de er det) til .NEt kan f.eks. intet *nix og således indgår *nix systemer slet ikke i deres overvejelser – til skade for kunden.
> Og det virker som om du altid kommer ind EFTER et system er blevet bygget og derfor sidder med et utaknemmeligt job.
Nej, mange af de projekter jeg har sidet med har jeg været inde over lige fra de første skitser. Men det ændrer bare ikke ved at det altid tager dobbelt så lang tid at lave som udviklerne påstod fra starten, og at det stadig ender med at være dårligere end de løsninger jeg har med at gøre som kører på f.eks. ROR, PHP eller simpel ASP.
Egil Hansen skriver
Interessant indlæg og diskussion.
Jeg er selv i gang med mit første rigtige asp.net 2.0 web projekt og kan tydeligt se den tendens, som andre også har påpeget. Den fristende hurtige udviklingshastighed som loves i diverse tutorials på asp.net holder ikke rigtigt stik, hvis man vil lave tingende ordenligt.
Hvis man vil følge best pratices må man faktisk se bort fra en del af de features, som lader sig bygge en blog på 10 minutter.
Et eller andet sted synes jeg dog også at det er fair nok. asp.net gør alle i stand til at lave forholdsvis avancerede sider uden at skrive en linje rigtig kode selv. Skal man lave noget seriøst, må man dog frastå fristelsen og faktisk få lidt jord under neglende.
Bo Drejer skriver
Hej Mikkel,
Har sendt mail med forslag til dato…
/Bo 🙂
Jannik Anker skriver
Hej Mikkel,
Hvis samtlige .NET-projekter, du har været inde over, har resulteret i for lang udviklingstid, for tunge sider, dårligt opbygget administration og lange loadtider – og du samtidig siger at ca. halvdelen af alle de projekter du er inde over, pt. er .NET-baserede, så forstår jeg din frustration 😉 Men når du så sammenligner med “stort set alle andre udviklingsmiljøer”, er du sgu’ lidt ude at skide – for kender du “stort set alle andre udviklingsmiljøer”? Tror jeg ikke du gør, selvom du sikkert kender mange…
Som de fleste andre i denne “tråd” må jeg også lige sige, at .NET kun er, hvad udviklerne gør det til – det er stadig muligt (besværligt, men muligt) at lave grim, uorganiseret og langsom kode i .NET, men sker dét, er det absolut ikke teknologiens eller udviklingsmiljøets skyld, som jeg for begges vedkommende kun kan anbefale på det varmeste!!!
Niels Henriksen - Netopcom skriver
Hej Mikkel
Der fik du mig lige ud af stole….
Det er ikke .NET der er langsomt, det er programmøren der har kodet sitet. Jeg har selv set MEGET dårlige websites (har en kunde nu der har ventet med at få kodet deres site om og jeg venter stadig på at de skal acceptere mit tilbud).
Der er mange der ikke koder, så det er nemt at rette i eller læse.
Det er muligt i .NET at lave nogle rigtig gode ting og redskaber, sååå….. det er ikke systemet… det er manden bag 😉
Mikkel deMib Svendsen skriver
Jeg forstår slet ikke pointen i at bruge et system, hvor man skal starte med at lave alting om fordi den kode der spyttes ud er ubrugelig, og fordi HTML-koden fyldes om med så meget skidt at det er praktisk umuligt at få det ud af sitet som man kunne forvente.
Jeg kan konstatere, at alt for mange vælger .NEt uden at have gjort sig de nødvendige overvejelser, og uden at lave seriøse beregninger på hvad det faktisk kommer til at koste dem – kontra, hvis de valgte en anden løsning.
Jeg er egenligt lidt ligeglad med hvad der i teorien kan lade sig gøre og hvad der ikke kan. Jeg ser på det der faktisk sker, og faktum er, at de fleste af de løsninger der kommer ud på .NET er håbløse i alle de forhold jeg har med at gøre.
Og hvad er fidusen så, ved at have noget som nogle i teorien siger er godt (.NET) hvis resultatet er, at dit website bliver dårligere optimeret i søgemaskinerne og dårligere integreret end dine konkurrenter. Og hvordan kan du i længden forsvare, leve med, og konkurere på et marked, hvor dine konkurrenter slipper med 1/4-del i løbende vedligeholdelsesomkostninger.
Det er de faktiske forhold som jeg må forholde mig til og som jeg må rådgive kunder efter.
I praksis forholder det sig sådan, at hvis en kunde siger de kører .NEt må jeg fortælle dem at deres omkostninger til organisk SEO lige er steget med 100%. Hvis de så også er så uheldige at have valgt commerce serveren, må jeg skuffe dem yderligere, og sige som det er, at det nok vil komme til at koste 3-4 gange mere at optimere deres site, end hvis de havde lavet det med f.eks. ROR, PHP, ASP eller meget andet. Faktisk er der kun 2 andre systemer som er lige så slemme som commerce serveren: Domino servere og Broadvision CMS.-
I praksis sker der så stort set altid det, at man vælger at gå lidt på kompromis og lever med en optimering som er mindre end optimal. Ikke fordi det måske ikke kan lade sig gøre i teorien at gøre det bedre, men simpelt hen fordi det bliver for dyrt.
Husk på mit eksempel fra mit indlæg – en lille ting som udviklerne på .NET løsningerne siger tager 2 dage. Når jeg så sprøger en udvikler på et andet system, så siger de 30 minutter. Det er 32 gange længere tid på .NET. Gang det så op med de 100-200 forskellige småting jeg typisk gerne vil have ændret, og så ser du hvorfor det aldrig bliver gjort.
jeg ser stort set aldrig .NEt løsninger som er optimeret lige så godt som jeg ville have gjort. en jeg ser masser af løsninger der er virkelig godt optimeret udenfor .NET. Det er sgu da påfaldende …
Peter Terp skriver
Hej Mikkel
Jeg vil tildels give dig ret i det problem du nævner. Jeg har selv kodet en del .NET men også en del ASP og ColdFusion. Der er ingen tvivl om at det er væsentligt nemmere at rette i kode i de klassiske websprog.
Dog vil jeg sige at .NET kode sagtens kan laves både hurtigt, godt og vedligeholdsbart. Problemet er som regel programmeringen og projektlederen. FOR alt for mange bruger de “smarte” features som der bliver lagt op til i .NET (egentlig også pointen med sproget) – men min erfaring er at man ofte bliver låst hvis man bruger de mange drag and drop ting i Visual Studio. Laver man tingene fra bunden selv og prøver at undgå de i mine øjne forbandede Viewstates etc. så kan det faktisk lade sig gøre at lave både god og robust kode der også er forholdsvist hurtig at vedligeholde. Men det kræver en ikke doven programmør og ikke mindst en programmør der ikke bliver presset til at gøre det hurtigt.
Lars Bachmann skriver
Meget interessant debat i har gang i her.
Jeg koder selv ASP Classic og har mange gange overvejet at skifte til .NET.
Hvergang jeg har snakket med andre udviklere får jeg altid af vide at jeg er “gammeldags” og det eneste der virker er .NET.
Men det kan måske skyldes at man kan “springe over hvor gærdet er lavest” med de værkstøjer der følger med .NET?
Udover at arbejde med udvikling arbejder jeg også med SEO, så det er derfor vigtigt for mig at der bliver spyttet noget ordentligt HTML ud, og skal jeg sidde og kode alt HTML selv så kan jeg vel lige så godt holde mig til ASP Classic?
Mikkel deMib Svendsen skriver
> Men det kræver en ikke doven programmør og ikke mindst en programmør der ikke bliver presset til at gøre det hurtigt.
Så, du er enig med mig – det tager længere tid i .NET end i andre sprog?
For, når jeg presser programørerne til at gøre det hurtigt i f.eks. ASP eller PHP så virker det fint – men jeg forstår, at hvis man gør det samme med .NET så bliver det noget lort… 🙂
Men fortæl mig så lige, hvad er det der er så smart ved .NET hvis man fjerne alle de smarte ting der er indbygget, og alligevel skal kode sig manuelt ud af det hele for at opnå et ordenligt resultat?
Niels Henriksen - Netopcom skriver
Det smarte med .NET er at det er kompileret kode når den er kørt første gang. Så bliver siden hurtigere (men dog ikke hvis programmøren ikke har tændt for hjernen). Det er også smart at hvis man laver nogle classes i asp.net så kan de også bruges i en application eller på en mobiltelefon.
Grunden til at .NET skyder så meget “slam” kode ud er at programmøren bruger de kontroller der allerede findes. For at vise en liste i en browser skal man blot bruge én control samt en forbindelse til databasen.
Den GODE .NET programmør laver selv disse ting (peger lige på mig selv) og sørger for at koden er som den skal være.
Hvis man kigger i kildekoden så kan det være ligemeget om den er kodet i PHP, ASP eller .NET, HVIS man undgår at bruge “slam-kontroller”.
Mikkel – Når du siger at du lægger 100% oven i prisen fordi det er lavet i .NET, så har du ikke undersøgt deres kode ordentligt. Jeg har selv anbefalet en kunde at gå over til .NET fra ASP.OLD og sørge for at deres webside bliver SEO’et.
Så det kan godt lade sig gøre med .NET.
Mikkel deMib Svendsen skriver
Jeg ligger ikke 100% oveni prisen – jeg må blot konstatere, at mit arbejde bliver dobbelt så stort på .NEt som hvis det samme site var lavet i f.eks. PHP eller ASP – og endnu mindre hvis det er et “gammeldags” statisk website.
Faktum er, at der er 100 gange flere ting som kan går galt, og som altid gør det, i .NET løsningerne, og at løsningerne på disse problemer er mere komplicerede at forklare kunderne og mere komplicerede at få rettet på, og efterfølgende testet.
Dertil kommer, at jeg på mange andre platforma kan sætte mine medarbejdere i gang med undersøgelserne (og de er lidt billigere end mig), men på .NET ender aben altid på mit bord.
Så, når man ganger en højere timepris, med mere tid, ja så bliver det altså dyrere. Og den skal folk altså vide inden de vælger platform. Det bør indgå i den samlede omkostning ved et systemvalg, og den beregning laver folk simpelt hen ike i dag – og derfor står de efterfølgende og føler sig lidt “snydt” af dem der anbefalede dem .NET
Igen må jeg sige, at jeg er ret ligeglad med alle de teoretiske forklaringer på hvorfor .NET sagtens kan spytte pæn kode ud, når faktum er at det stort set aldrig sker, og jeg så efterfølgende skal bruge en helvedes masse tid på at identificere og dokumentere alt snavset.
Det må da være irreterende for Microsoft at der øjensynligt sidder så mange talentløse udviklere på .NET …
Niels Henriksen - Netopcom skriver
Så må du blot få dig en medarbejder som er så meget inde i .NET at du ikke skal kaste dig over det 😉
Men indrømmet, at der sidder nogle udviklere som ikke har begreb om at kode. Men det er ikke kun på .NET men også på andre platforme.
Jeg har selv udviklet i Perl, PHP, ASP og nu .NET. Og min erfaring er at fejlen ligger ALTID hos udvikleren. Ikke sproget.
Søren Sprogø skriver
> Så, du er enig med mig – det tager længere tid i .NET end i andre sprog?
Nej, du skal tvinge udvikleren til ikke at tage de nemme genveje, som .NET tilbyder.
Men som jeg har skrevet tidligere, så ja: Det tager længere tid at lave rettelser i et compilet sprog end det gør i et script sprog. Til gengæld har compilede sprog nogle andre kæmpemæssige fordele, noget man bør have taget stilling til tidligt i udviklingsfasen når man foretager sit teknologivalg.
Nogle af de hurtigste webshops jeg har arbejdet med har faktisk været baseret på Commerce Server og .NET teknologi. Desværre kan jeg ikke komme med nogen eksempler (faktisk har du selv været involveret i en af dem for mange år tilbage), da jeg af princip ikke udtaler mig offentligt på mine kunders vejne.
Alt det ovenstående tyder på, ganske som jeg også skrev tidligere, at projektleder og udviklere du har arbejdet med, ikke har fulgt best-practice n-Tier modellen, hvor man (grundlæggende) adskiller sin applikation i databaselag, forretningslogik og præsentationslag. Som jeg også skrev tidligere.
Er det gjort korrekt skal SEM-personen kun rette i præsentationslaget, som bør være adskilt fra det compilede kode i simple templates, der kan rettes uden at en programmør skal ind og compile. Og dermed undgår man den langsommelige og besværlige migreringsprocess, der som du skriver kan tage dage.
Men mange udviklere der stammer fra PHP, Classic ASP eller andre scriptbaserede sprog kender ikke til n-Tier, hvilket er en skam. Uanset om du udvikler i PHP eller Classic ASP giver n-tier dig nemlig nogle kæmpe fordele inden for scalability, genbrugbarhed og videreudvikling. Og det er når du benytter denne model at du med .NET opnår udviklingstider der er 10-20% mindre. Ganske som Microsoft reklamerer med.
Et eksempel kan jeg dog give: Tag et kig på koden bag mit eget website, http://www.afdeling18.dk, som netop er baseret på et .NET CMS (Umbraco) bygget korrekt over n-tier modellen. Det loader lynende hurtigt, og kræver ingen koderettelser overhovedet for at ændre i præsentationslaget. At det måske så ikke er 100% ordentlig HTML er HTML-smedens skyld, ikke teknologien eller systemets 🙂
Desuden skal du nok også skille skidt fra kanel: Commerce server er et kæmpe produkt, faktisk så stort at kun få på det danske marked er store nok til at de bør vælge det, og så godt som ingen udviklerhuse i Danmark har erfaring nok til at udnytte det optimalt. Men fordi Commerce Server er et “elendigt” produkt bør det vel ikke gå ud over .NET? Jeg ser en totalt forvirrende sammenblanding imellem de to i dine posts, hvilket gør det ret svært at komme med nogen sammenhængende svar på hvad der er rigtigt og forkert.
Men det er et kæmpe emne det her, og du stiller spørgsmål til rigtigt mange forskellige ting. Noget der er umuligt at gøre rede for i en (ubetalt) kommentar til en blog-artikel. Google lidt på n-tier modellens fordele, og fordelene ved compiled vs. script-sprog, og du vil måske finde svar på hvad der gør .NET godt. Spring over al marketing-gejlet fra Microsoft, da det som regel kun fremhæver alle de kontroller du får foræret, og som har det med at spytte dårlig HTML ud.
Mikkel deMib Svendsen skriver
Jeg bliver hevet ind på tekniske SEO opgaver over hele verden fordi at der faktisk ikke er ret mange som er dygtige nok til både det tekniske og SEO. Selv på det Amerikanske marked er der under 10 som kan lave disse opgaver – og vi henviser alle til hinanden. Så selvom jeg gerne ville, er det i praksis umuligt at få flere folk ind til netop disse opgaver. De få der er, skal ligesom jeg, have en meget høj løn for det vi laver. Udbud og efterspørgsel …
Mikkel deMib Svendsen skriver
> Er det gjort korrekt skal SEM-personen kun rette i præsentationslaget
Det er ikke helt korrekt, for der er mange web-arkitektur valg som ligger udenfor dette lag og som har afgørende betydning for SEO
jeg har efterhånden arbejdet med så mange udviklere, overalt i verden, og fra nogle af de mest respekterede bureauer at jeg simpelt hen ikke tror på den teori med at det bare skulle være udviklerne der er dårlige. Endnu mindre passer denne teori, når man sammenligner med udviklere i andre miljøer, hvor jeg slet ikke i samme grad oplever de samme problemer. Jeg tror simpelt hen ikke på at dem der tager jo i .NEt virksomheder er de dårlige, og de dygtige kun tager jobs andre steder.
Og igen er jeg egenligt ligeglad med teorien – faktum er, at det ALTID tager meget længere tid at optimere .NET løsninger, og at det kræver dyrere SEO-folk at gøre det. Det gør i praksis at det koster mindst dobbelt så meget at optimere en .NET løsning. Jeg har ikke set eksempler der påviser noget andet.
Dette mener jeg burde være noget som Microsoft virkelig gjorde noget ved. Det er et kæmpe problem for dem!
Desværre har Micosoft altid været ekstremt hovne når det handler om de anbefalinger vi SEO’ere kommer med. Masser af de alvorlige problemer der er med MS publiceringssystemer, generelt, har de kendt til i mange, mange år – men de gør intet ved det. Det samme har vi oplevet med andre store leverandører – f.eks. Broadvision, som indtil fornyligt slet ike kunne indekseres af søgemaskiner – overhovedet. Broadvision nægtede simpelt hen at gøre det muligt, og sagde hovent til kunderne at de jo ikke var et marketingselskab. Samme attitude oplever jeg med MS produkterne. De er ligeglade med SEO og marketing – og dermed skider de efter min mening på kunderne.
Det er det som jeg må forholde mig til og det som jeg bliver nødt til at rådgive mine kunder efter.
Lasse skriver
Costa Rica vrimler med uddannede computer scientists, der primært er skolet i .NET grundet universiteternes forkærlighed for Microsoft. ~$600-700 pr. måned for de mere eller mindre nyudklækkede, op til $2000 for top level developers med adskillige års erfaring (dog 22 % i sociale omkostninger). Dyrt at udvikle i .NET? Nah! 😉
Søren Sprogø skriver
Det er selvfølgelig 110% op til dig hvordan du rådgiver, baseret på dine tidligere erfaringer. Og det har jeg selvfølgelig stor respekt for.
Men “faktum” er også, at jeg personligt har været involveret i løsninger baseret både på .NET og Commerce Server, som både har loadet ekstremt hurtigt og været nemme at foretage SEM på. Og “faktum” er også, at jeg så bestemt har set lige så mange løsninger baseret på f.eks. Classic ASP, som har været et ekstremt helvede at foretage optimering på.
Som nævnt vil jeg ikke nævne disse i et offentligt forum, hverken de gode eller dårlige, da jeg aldrig udtaler mig offentligt om mine kunders løsninger. Men hvis nogen sidder i de tidlige faser i lignende projekter er de da velkomne til at tage kontakt for at få nogle hurtige, uvildige råd omkring hvad man skal passe på og hvad man skal gøre (beklager, ikke ment som reklame for mig men for at give folk mulighed for flere sider af den samme sag).
Mikkel deMib Svendsen skriver
Det er normalt ikke mig der beslutter hvem en kunde vil bruge som web-leverandør. Jeg bliver blot hyret til at få det bedste ud af det de har. Og meget ofte bliver jeg netop trukket ind på disse .NET løsninger fordi ingen andre har kunne få ordentlige resultater ud af det.
Om en kunde vil flytte udviklingen til Costa Rica er op til dem, men det gør det ikke nødvendigvis billigere. Og hvor mange teknisk kompetente SEO’ere er der lige der? eg har aldrig hørt om en eneste på de internationale markeder jeg bevæger mig på.
Når jeg så står overfor en .NET løsning, så er faktum at der er mange flere fejl som jeg skal have undersøgt for, og mange flere af de løsninger der skal til som er meget mere komplekse for udviklerne at få rettet.
Derfor sker der da også som regel det, at 60-70% af mine anbefalinger ender med at blive til virkelighed (når det går godt). Står disse virksonmheder så overfor konkurrenter, på andre systemer, som gennemfører 90 eller 100% af de anbefalinger jeg (eller andre SEO’ere) kommer med, ja så står .NET kunderne dårligere – de får ikke lige så gode resultater.
Tommy Adam Sjørring skriver
Mikkel De Mib
Det kan i første omgang synes let at udvikle i .NET og derfor kan dårlige programmører hurtigt spytte fungerende men elendig kode ud. Der bliver gjort alt for lidt ud af arkitektur, performance og reduktion af overflødige kodelinjer..
En dygtig .NET udvikler vil med sit .NET Framework kunne udvikle applikationer fra bunden som er langt bedre og billigere end en udvikler vil kunne på PHP og ASP hvad angår både performance, pris, genbrugelighed, hastighed osv.
Hvis du skal bruge 30 gange længere tid på dine .NET kunder, så skyldes det enten at deres projekter er elendigt opbygget/dokumenteret eller også er du bare ikke den rigtige mand til .NET opgaver – ja du skriver jo selv indirekte at du ikke er egnet til den slags opgaver, da du ikke kan se lyset som vi andre stråler os i til daglig 😀
Sjovt nok er de fleste negative indlæg i denne debat fra folk der ikke har arbejdet med .NET eller folk der har arbejdet “lidt” med .NET. Lad os hellere høre på .NET udviklere med 4-5 års proff. erfaring.
Lad følgende være min påstand: “.NET er et kraftfuldt og effektiv udviklingsværktøj, og har man styr på sin udvikling og arkitektur, findes der ingen teknologier der kommer i nærheden af .NET”.
mvh Tommy
Mikkel deMib Svendsen skriver
> Det kan i første omgang synes let at udvikle i .NET og derfor kan dårlige programmører hurtigt spytte fungerende men elendig kode ud.
Det er jeg helt enig i, og her ligger en del af skylden altså hos MS. Jeg har selv udviklet meget i ASP og er rimelig til det (jeg bliver aldirg super kode-nørd :)) og jeg husker da .NET kom frem, at det blev markedsført som en slags forlængelse af ASP og at det var super-let lige at hope over på. Det er det ikke, som de fleste sikkert ved her. ASP er ret simpel scripting – .NET er “rigtig” programering, af en type som f.eks. en kode-amatør som jeg ikke kan finde ud af.
Men min rolle er heller ikke kodning, men at analysere effekten af det som koden spytter ud, og så iøvrigt have god nok indsigt i de forhold der ligger til grund, til at der kan foreslås løsninger. Som f.eks. med view_state, som mange .NET udviklere misbruger helt vildt på steder hvor det slet ikke er nødvenigt. Det kræver ofte et alvorligt spark bagi, at få dem til at fjerne det der hvor det ikke skal bruges – men jeg ved at man kan, og kan således også rådgive om muligheden.
Jeg har haft med kunder at gøre på alverdens platforme. Naturligvis ikke alle – men mange, gennem de sidste 10 år. Jeg må som rådgiver leve med mange af de valg kunderne har taget, og forsøge at få det bedste ud af det det har, og indenfor de rammer de har mulighed for at arbejde med. Sådan er virkeligheden.
Og når jeg så ser henover en bred kam, på de forskellige kunder rundt omkring i verden jeg har betjent gennem mange år, så står det stadig lysende klart for mig, såvel som alle de af mine teknisk kompetente kollegaer, så ender .NET kunderne altid med størrer omkostninger i rådgivning og udviklingstid på de ting der skal gøres for at optimere deres sites ordenligt.
Naturligvis kan man finde eksempler der går stik imod dette, men det hjælper bare ikke de mange kunder jeg sidder, og har sidet med, som står med problemerne. Det er jo fint nok at I her siger, at de problemer som disse mange .NET kunder har, skyldes dårlig udvikling eller udviklere, men problemet er bare at de konkret sidder med aben. At det teoretisk set ikke behøver at være så skidt er lige meget for dem – for det er det 🙂
Hvis det vitterligt er rigtigt, at de mange problemer jeg støder ind i med kunder der bruger .NET, skyldes dårlige udviklere eller udvikling, så synes jeg Microsoft burde gøre noget for at stramme op i rækkerne. Det kunne f.eks. være gennem høje krav til certificering, og et pres på markedet for kun at bruge de top-certificerede udviklingshuse. Og så bliver Microsoft nødt til at “skrue ned for charmen” i forhold til at oversælge .NET til inkompetente folk.
Det gavner hverken .NET eller Microsoft på sigt, at jeg, og alle mine kollegaer i SEO-branchen, oplever SÅ mange problemer med .NET som vi gør – uanset hvad den væsentligste årsag til det så end er.
Og husk nu, at det ikke bare er .NET vi SEO’ere er på jagt efter. Vi har intet specielt had til Microsoft – vi hader bare dårlige webarkitekturer og kode 🙂
Der er mange andre systemleverandører og platforme som vi har jagtet gennem tiden – som nævnt f.eks. Broadvision CMS og Domino. Men, der er ikke nær så mange der benytter sig af lige de to, som .NET, så derfor er problemet ikke så stort mere. På samme måde som at Netscape’s gamle webserver kan være lidt irreterende på visse punkter – men da næsten ingen bruger den mere er det ikke så stort et problem.
Frank Nielsen skriver
Well, må lige give mit besyv med her, da jeg har en del grå hår fra denne branche 😉
Jeg arbejder som feelance konsulent indenfor optimering af performance/skalering færdig udviklet applikationer og implementering af kvalitets løft i applikationer igennem de sidste 8 år.
Jeg har arbejdet ligeligt i Java og .Net miljøer, og der er en akademisk forskel i hvordan de 2 verdener arbejder. Java verden har en meget mere akademisk indgangsvinkel end .Net. Som regel afspejles ved at java verden løser opgaven på et whiteboard inden der kodes hvorimod .Net mere ”kaster” sig over opgaven direkte i udviklings værktøjerne. Ved godt det er en generalisering, men det beskriver meget godt den forskel jeg oplever.
Når jeg starter i en ny virksomhed og kommer jeg ned i udviklingsafdelingen, er det første jeg kigge på væggene. Alt efter hvor mange whiteboards der er sat op, og hvad de er brugt til ved jeg nogenlunde hvordan arkitekturen ser ud i applikationen, på godt og ondt.
Mht .Net platformen er det største problem at Microsoft ikke har tænkt kvalitet i deres framework, hvilket det også tydeligt bære præg på hvis man kigger på forskellene imellem 2.0 og 3.0, eller i hvilken retning produkterne er på vej hen. Microsoft 1. prioritet har altid været at få ”sprøjtet” en masse kode ud i en fart og at det skal være nemt at lave kode/appliaktioner. Når det så er så nemt glemmer folk at tænke sig om, eller også gør de det først når det er for sent og problemet er konstateret i produktion.
Men men, i sidste ende er jo udviklernes ansvar/skyld hvordan applikationen ender op med at se ud. Og her tror jeg lidt selv erkendelse påtagelse af ansvar ville være på plads, at folk erkende at de ikke bare er ”guds gave til alverdens internet applikationer” og kan alt i hele verden. Det hvor film for alvor knækker, er hvor der er lavet trådet applikationer. Her har under 5% reelt forstand på hvad de har med at gøre – selv blandt eksterne konsulenter, hvilket er skræmmende. Men det er jo nemt at lave ”tråde”, og vupti så har man en flere trådet applikation – som jeg plejer at >>nu har man sluppet fanden løs i applikationen
Mikkel deMib Svendsen skriver
Tak for uddybningen 🙂
> Men men, i sidste ende er jo udviklernes ansvar/skyld hvordan applikationen ender op med at se ud.
Ja, men det hjælper bare ikke de kunder ret meget, som har hyret et ellers respekteret webbureau til at løse en opgave. Af de sidste 4-5 .NET opgaver, hvor jeg har været hyret til søgemaskineoptimering af, har ikke ET ENESTE af dem holdt de tidsranmmer som webbureauet lovede, og de færdige applikationer lever ikke op til de krav jeg stillede tidligt i processen. Ofte bliver mine krav ikke opfyldt, fordi alt “basis-kodningen” tager alt for lang tid, bliver dyrere, og der således ikke er resurser og tid til at gøre det der bør gøres i forhold til f.eks. søgemaskiner.
Så ender kunden med et stærkt forsinket projekt, et projekt der kører mindre end optimalt, og et projekt der ikke indeholder de elementer der skal til for at de kan konkurere ordentligt mod andre i markedet. Og det er bare ikke godt nok.
Hvad vil du foreslå kunderne skal gøre? Hvis det er korrekt at der er så mange talentløse udviklere i .NET miljøerne – selv indenfor de veletablerede og respekterede bureauer, hvordan skal kunden så kunne vælge det, som I alle samme siger han kan få med .NET?
Frank Nielsen skriver
Well, det eneste jeg kan foreslå kunden er det framework som vi pt arbejder. Det vil være en radikal ny måde at løse hele “udviklings” opgaven på, til stor glæde for rigtige mange – inkl dig. Jeg vil dog ikke omtale dette produkt yderlig, da vi ikke har en .exe version endnu – desværre.
Så lige nu har jeg ikke de store løsningsforslag til kunden, andet en at gå til klingen på deres webbureau og forlange kvalitet på nogen direkte måle bare punkter, såsom leverance tider og performance tal etc. Og for hver gang et af disse punkter ikke overholdes er det tilbage betaling ved kasse ét. Det er den hårde måde, men det kaster ansvaret tilbage til bureauet som så nok vil tage sig mere sammen. Ved godt det lyder underligt da det må betragtes som selvfølge, men kunden skal forlange kvalitet og følge op på det med hård hånd.
Et andet stort problem er at alting bliver udviklet fra bunden, hver gang. Derved introduceres de samme fejl igen og løsningen bliver aldrig helt gennemtænkt. Eftersom så meget, bliver lavet fra bunden, kræver det ofte mange ressourcer. Typisk kan man se firmaer udvikle en eller anden komponent i flere mande uger som reelt kan købes på nettet til $300 og implementeres på 2 dage. Hvis man valgt en mere generisk løsning vil fejlene kun opstå én gang og man opnår meget hurtigere en større styrke/kvalitet i produktet. Med en generisk løsning kræver det også at man tænker den rigtig godt igennem, inden den laves. Jo mere fejlbehæftet et produkt er og jo senere fejlene bliver fundet, jo mere skrider projektet i tid og dermed penge.
Jeg håber at du for snakket rigtig ”igennem” med Microsoft på jeres møde, dog tror jeg løbet er kørt. Vi må så bare prøve at styre det i den rigtige retning.
Mikkel deMib Svendsen skriver
> kunden skal forlange kvalitet og følge op på det med hård hånd.
Helt enig. Kunden har altid et ansvar også. Jeg synes også at kunder ofte afsætter alt for lidt tid til forundersøgelser og kravspecifikationer – det gælder både for webudvikling og søgemaskinestrategi.
Et af problemeerne er, at de fleste kunder forventer en række ting som en helt naturlig del af en webløsning – f.eks. at de store søgemaskiner faktisk kan crawle og indeksere deres website på en hensigtsmæssig måde. Det er ikke urimeligt at forlange. Det lover webbureauerne dem så at det kan. Men webbureauerne ved bare ikke nøjagtigt nok hvordan søgemaskinerne fungerer, og ikke mindst hvilke begrænsninger de har i den måde de crawler sites på og indekserer data. Så de tror måske at de laver noget der virker, men ender ofte med at det ikke gør det. De tør måske ikke indrømme, at de er amatører, når det kommer til søgemaskiner …
Jeg har intet imod at indrømme at jeg er en kode-amatør. Jeg ved nok til at kune snakke med dem der er dygtigere end mig, men ikke nok til selv at udføre kodningen. Det er langfra alle webbureauer der har samme ydmyghed i forhold til f.eks. søgemaskiner.
Når det så er sagt bør jeg også understrege at jeg da også har arbejdet, og arbejder, med mange webbureauer og udviklere rundt omkring, som fuldt ud erkender det de ikke kan – f.eks. omkring søgemaskiner. De velkommer normalt min deltagelse i kunde-projekter.
Men, selv de webbureauer der er åbne overfor mine (eller andres) input, ender alligevel alt for ofte med at være meget længere tid om at kode det de skal, med mindre end optimale resultater, og ofte med udskydelse af flere af mine “krav” p.g.a. tidspresset.
Så min oplevelse er som sagt ofte, at jeg synes kunderne får et framework der måske i teorien kunne være fantastisk, og som har en masse imponerende features indbygget, men de når bare aldrig dertil at de virkelig får glæde af dem. Og når jeg så ser på det de faktisk har fået slår det mig tit, at de kunne have fået nøjagtigt det samme ved at anvende et godt Open Source produkt, typisk på en Linux platform, til en brøkdel af prisen (inkl. udvikling og licenser) og væsentligt hurtigere.
For at sætte det hele lidt i perspektiv koster en IIS, MSSQL og commerce server licens hurtigt 100k for en dansk butik – hvortil kommer al udviklingen, som jeg ofte ser løber op i flere millioner. For de samme 100k (i MS licenser alene!) kan man hyre en forbandet god PHP/Linux mand i mindst 2 måneder – og på den tid kan han opsætte en ret avanceret shop på et godt Open Source produkt.
> Typisk kan man se firmaer udvikle en eller anden komponent i flere mande uger som reelt kan købes på nettet til $300 og implementeres på 2 dage.
Helt enig! Det ser jeg som et generelt problem med mange udviklere. De vil altid hellere selv lave alt fra grunden, for så har de fuld kontrol over alt hvad der sker. Problemet er bare, at man ofte sagtens kan klare sig med et standardiseret produkt. Disse udviklere glemmer helt at se på cost-benifit i de forskellige løsninger. Hvis noget der er 95% godt nok koster 1/100 del – så vil mange nok vælge det 🙂
I sidste ende handler det her jo om forretning – kundens forretning (hvilket i hvert fald er min fokus).
> Jeg håber at du for snakket rigtig ”igennem” med Microsoft
Jeg vil altid gerne snakke med interessante folk. Men det i sig selv løser jo ikke noget. Jeg har ingen forestilling om, at møde op til sådan et møde med en plan for hvad der bør ændres i deres frameworks for at gøre det mere søgemaskinevenligt. Microsoft har allerede den viden der skal til, indenfor deres egen organisation. Hvis de vil have mig til at hjælpe med at grave den frem, kan jeg naturligvis hyres til dette. Men, jeg oplever ikke at det er viden der er problemet – det er viljen til at bruge den.
Frank Nielsen skriver
>> Så min oplevelse er som sagt ofte, at jeg synes kunderne får et framework der måske i teorien kunne være fantastisk, og som har en masse imponerende features indbygget, men de når bare aldrig dertil at de virkelig får glæde af dem.
Og det er netop fordi de starter forfra hver gang de går til en ny kunde med et ”nyt” produkt, derved er synagien tabt.
>> Disse udviklere glemmer helt at se på cost-benifit i de forskellige løsninger. Hvis noget der er 95% godt nok koster 1/100 del – så vil mange nok vælge det.
Tror ikke der er nogen udviklere der ser på cost-benifit i relation til deres eget arbejde, de tænker tenik og ikke forretning – hvilket de dog burde.
Men jeg glæder mig til at introducere vores framework som helt sikkert vil skabe nogen dønninger i udviklingsverden til at starte med, og efterfølgende i forretningsverden. Men det vil jeg vende tilbage med når .exe version er klar. Frameworket vil omfatte stort set alle de aspekter der har været omtalt her i forbindelse med .net som det er baseret op, dog ikke seo hvor min viden er minimal. Men du kan sikkert belære mig med nogen ting når vi kommer til web delen, mht din kommende bog?!
Mikkel deMib Svendsen skriver
> Men du kan sikkert belære mig med nogen ting når vi kommer til web delen, mht din kommende bog?!
Ja, den vil indeholde langt de fleste af de informationer du har brug for, og henvise til flere.
Jacob Andersen skriver
Jeg arbejder selv med asp.net og kunne da godt tænke mig at vide, hvilke problemer der er med at bruge de asp.net kontrols. Er det lange ID tags eller store viewstates, som i mener der gør koden dårlig?
Mikkel deMib Svendsen skriver
> Er det lange ID tags eller store viewstates, som i mener der gør koden dårlig?
Ja, det er bestemt et af problemerne. Jeg har set view_state koder på 20-30.000 tegn og det giver simpelt hen så meget støj, at det skader søgemaskineoptimeringen.
Og generelt, spytter de fleste kontroller alt for meget kode ud i forhold til hvor effektivt det kan gøres hvis der renses ud i alt det unødvendige. Når jeg måler code-til-text raio på sites, så ser jeg generelt en meget lavere procent på .NET sites end de fleste andre.
Men tung kode er kun et af problemerne ved .NET – der er mange flere, og flere end jeg kan liste her 🙂
Lasse skriver
Hvad angår teknisk kyndige SEO-folk i Costa Rica, så tror jeg nu, at der er en hel del af slagsen. De er bare ikke synlige, da de enten ikke forstår sig på selvpromovering/personlig branding eller ikke ønsker at deltage i det ræs. Det er formentlig førstnævnte der er gældende.
Som eksempel kan nævnes en gut (den første SEO kyndige jeg mødte i CR) som er SEO manager for en af de største sportsbooks (hvis ikke den største) i verden. Han er ansat med en ganske pæn løn sammenlignet med mange af sine landsmænd, men gringoen der havde stillingen før ham fik 3 gange så meget i løn.
Indtil videre har jeg indtrykket af, at de mangler den “indre entreprenør” og generelt ikke blander sig ret meget i diskussionerne etc. i SEO-verdenen. De udfører deres job og tager sig til takke med lønnen. Et stabilt job er alpha omega her og vægtes noget højere end lønnen. Hvis de ikke stikker snuden frem er de selvfølgelig noget svære at spotte set i forhold til mange af jer andre.
Mikkel deMib Svendsen skriver
Fint nok, men Costa Rica er bare ikke aktuelt for 99% af de kunder jeg arbejder med, så det er i denne sammenhæng ret ligegyldigt 🙂
Peter Lundsby skriver
Hej Mikkel
Synes lige jeg prøve at forklare hvorfor .Net er fantatisk, specielt i forhold til tidligere tiders asp.
Grunden til at .Net løsninger nogle gange laver inferiør html kode, er at Page-modellen benyttes. Page-modellen er en abstraktion oven på almindelig web-programmering, der tilbyder en event-baseret programmeringsmodel og tilstand (i form af ViewState).
Det smarte med Page-modellen, er at den frigør programmøren til at koncenterer sig om at implementere selve applikationen, istedet for at skulle bekymre sig om kompliksitet af den underliggende platform. Udover Page-modellen er de fleste .Net sprog objektorienteret og stærkttypede. Hvilket også er at foretrække i forhold til scriptsprog på lidt større projekter.
Men Page-modellen er valgfri, så hvis man kommer ud for et projekt hvor den største arbejdsbyrde er optimering af markup, kan man helt gå udenom Page-modellen.
Så hvis man ser det i et lidt større perspektiv. er det ikke nødvendigvis dårligt at det tager meget længere tid at implementerer SEO rettelser i ASP.Net baserede løsninger. Bare der er sparet tilsvarende eller yderligere andre steder, som følge af Page-modellen.
Mht. til Commerce-server, så er det efter min mening er godt værktøj, der tit bliver brugt som kanon imod gråspruve. Specielt features til håndtering af kampagner, splittests og business intelligence er under udnyttede, hvilket er synd.
Mikkel deMib Svendsen skriver
Tak, det er altid godt med mere uddybende information 🙂
Jeg forstår så bare stadig ikke, hvorfor den HTML-kode der spyttes ud med page-modellen behøver at være så hæslig. Jeg har i hvert fald svært ved at se at der skulle være en teknisk årsag til at det slet ikke kunne lade sig gøre, at ændre denne model, så den HTML-kode der kom ud var meget mere “ren”. Selvfølgelug vile man kunne det, hvis man synes det var vigtigt nok.
Det virker på mig mest som et spørgsmål om prioritet. Jeg tror som sagt godt, at Microsoft ved hvad der burde gøres – hvad der burde renses op i. Jeg ved i hvert fald, at de har den vide i deres organisation.
Men, den hæslige HTML-kode er som sagt kun et ud af mange problemer jeg oplever med .NET
Det største problem, som jeg oplever det, er at både Microsoft, og du, undervuderer værdien og vigtigheden af en compatibel og ren web-grænseflade. Det gælder ikke kun i forhold til søgemaskiner. Du skriver at det skal ses i et større perspektiv. Helt enig, men det bliver det ikke i dag i tilstrækkelig grad af udviklere der, som jeg forstår dig, mener at det handicap mange virksomheder på .NET oplever i forhold til deres konkurrenters kan opvejes af en bedre platform.
Faktisk synes jeg er det er ret groteskt at “produktionsmetoden” prioriteres over “resultatet”. Sorry Hr. Jensen, den bil vi har lavet til Dem kan ikke køre – men vi lover Dem for, at den er produceret på en virkelig smart måde 🙂
Det er den samme diskusion vi (SEO-branchen) har haft med og om mange andre leverandører i markedet. Og tro mig, vi vinder disse kampe i sidste ende – for kunderne, dem der betaler for disse systemer, har i stigende grad indset vigtigheden af at deres virksomheders websites kan optimeres ordenligt i søgemaskinerne. Det er ikke en bi-ting der kan nedprioriteres til fordel for nogle teknisk set smarte løsninger. Hvis der ikke kommer kunder i butikken er der jo ingen til at betale for teknikken.
Martin Høst Normark skriver
Denne kommentar handler ikke direkte om .NET – men måske lidt.
Jeg har netop læst en blog post: http://www.nikhilk.net/Entry.aspx?id=163 som omhandler SEO i RIA’s (Rich Internet Application). Det er både mht. Flash, AJAX og Silverlight. Nikhil Kothari viser en teknik (som med garanti ikke er ny) hvor man på en side har f.eks. et Flash-object med indholdet til brugeren. Under Flash-objektet indsætter man så følgende til søgemaskinerne:
document.write(”);
Tekstbaseret indhold som søgemaskinerne kan indeksere…
document.write(”);
For brugeren vil JavaScriptet selvfølgelig gøre at man ikke får vist det tekstbaserede indhold – men kun Flash-indholdet. Men søgemaskinerne kører jo ikke JavaScript-koder og får derfor vist det tekstbaserede indhold…
Vil søgemaskinerne ikke sidestillet dette med cloaking?
Mikkel deMib Svendsen skriver
Der er masser af metoder til at skjule tekst på sider -f.eks. Flash-sider. Men ovenstående metode er bestemt ikke en af de mest elegante.
Men uanset teknik løser det bare ikke problemet med Flash.
Først og fremmest prioritere søgemaskinerne ikke skjulte tekster særlig højt, og du har ret i at det kan opfattes som spam.
Men det mest alvorlige problem er fortsat, at søgemaskinerne ikke kan linke ind til det punkt i flash-filmen eller AJAX applikationen, hvor de relevante indhold findes som der blev søgt efter.
Så før der indføres en standard som kan løse dette er der ingen ordentlige løsninger på Flash – eller AJAX.
Martin Høst Normark skriver
Men opdager søgemaskinen overhovedet at det er en skjult tekst? Nu fjerner bloggen her selvfølgelig javascriptet m.m. som jeg prøvede på at gengive. I og med at javascriptet ikke udføres – kan søgemaskinerne da stadig se hvad der oprindeligt ville ske hvis en bruger besøgte sitet?
Jeg kan godt følge dig i problemet med at linke til Flash og AJAX applikationer – mon Google kunne udvide deres Sitemap “koncept” til at indeholde oplysninger om Flash/AJAX links på et tidspunkt…
Mikkel deMib Svendsen skriver
Ja, søgemaskinerne er meget gode til at finde skjult tekst – uanset hvordan du laver den.
Google kan ikke løse problemer med Flash og AJAX alene – der skal en industristandard til. Sitemaps dur IKKE som en løsning, da det smadrer hele linkstruktur perspektivet.
Jesper Jørgensen skriver
Hej Mikkel
Absolut interessante betragtninger fra en der må redde kastanjerne ud af ilden for os andre når vi ikke lige er tilfredse med Googles syn på vores sites. Da jeg både beskæftiger mig med performance og SEO på Sitecore CMS (.Net baseret), kan jeg relatere mig til begge problemstilinger du opstiller: Dårlig performance og utilfredsstillende html kode.
Tro mig, man kan lave webløsninger der performer mere en usædvanligt godt, og hvor du har tæt på 100% styr på html’en. Hovedproblemet som jeg ser det er at områder som SEO og performance alt for ofte har ingen eller lille fokus i starten af denne type projekter. Først når man har skabt “uhyret” begynder man at stille spørgsmål som “kan det performe?” eller “hvordan vil Google ranke det?”.
Uanset om en løsning er udviklet i .Net miljøet eller ej mener jeg man bør kunne stille to væsentlige krav:
1) Man skal have en meget høj grad af frihed over den html der bliver genereret, og man skal forholdsvist nemt kunne ændre den hvis man fx. får en ekspert som Mikkel på besøg.
2) Løsningen bør have værktøjer til at identificere performance problemer, samt mulighed for at tune performance hvis den halter et sted.
Som nævnt ovenfor omkring fiorskellen mellem Java og .Net udviklere (som jeg hverken kan be- eller afkræfte), så er det super vigtigt at sådan en proces starter ved et whiteboard og ikke ved tastaturet. Måske er værktøjerne blevet så avancerede så projektlederne i dag har svært ved at forstå teknikken bag. Det første og bedste sted at starte vil være at SEO og performance som en naturlig ting skrives ind i kravspecifikationerne og at unge på IT uddannelserne undervises i vigtigheden af disse aspekter.
Mikkel deMib Svendsen skriver
Meget enig, Jepser.
Problemet er jo nok et langt stykke ad vejen, at teknikerne har taget magten over tekniken. Tekniken styres for ofte af tekniske krav frem for forretningsmæssige krav.
Det er “Amanda” problemet om igen. Man glemmer at involvere dem der skal bruge systemerne i udviklingen af dem, og man underprioritere deres krav. Og så ender man med systemer, som i teorien er fede, men som i praksis er noget lort.
I forhold til webudvikling er det somom, at websites bygges fra backenden og ud – hvor jeg mener de bør bygges fra frontended og bagud. Det bør være de forretningsmæssige, markedsføringsmæssige og brugermæssige krav der er i fokus, men desværre oplever jeg tit at det er teknik-fascination der driver møllen.
Lad os bruge Flash. Hvorfor? Fordi det er sjovt at lave Flash …
Lad os bruge Comerce Server. Hvorfor? Fordi jeg gerne vil lære at bruge den …
Lad os lave det i .NET. Hvorfor? Fordi alle siger det er så fantastisk …. Nå, men er det det? Det ved jeg ikke, for jeg er ikke så teknisk … 🙂
Jesper Jørgensen skriver
Jeg så for nyligt forsiden på et site i et nyt kundeprojekt og undrede mig over at den loadede langsomt og “ujævnt”. Der var tale om en helt statisk side som forsiden af websites er det for det meste. Da jeg spurgte ind til den underlige opførsel viste det sig at man havde valgt at opbygge sidens elementer med AJAX! En ting var at de så ikke udnyttede nogen af CMS’ets caching teknikker med dårlig performance til følge. Men en helt anden sag er søgemaskinerne formentlig slet ikke ville se denne side. Altså en SEO mæssig karastrofe. Gået på klingen viste det sig også at det var også teknikkerne der havde trumfet det igennem fordi Web 2.0/AJAX var nyt og spændende, men uden at der var skelet til de øvrige forretninsgmæssige krav.
Da CSS stylesheets blev en del af html standarden vrimlede det lige pludselig med websites hvor tekst og baggrunde stod og blinkede i røde, gule og grønne farver. Verden er gudskelov på nogle områder blevet klogere og er holdt op med denne uvane. Men hvorfor opstod fænomenet dengang? Fordi man lige pludselig kunne… Var det CSS standardens skyld! Nej selvfølgelig ikke, men den stiller nogle muligheder til rådighed som stiller krav til brugernes selvbehærskelse.
På samme måde ser jeg det med .Net. .Net giver en masse funktionalitet som på nem vis gør det muligt at lave websider med avanceret funktionalitet. Prisen er desværre mindre kontrol, og hvad jeg især kan frygte: at udviklerne med tiden glemmer deres grundlæggende håndværk. Jeg mener dog ikke dette er .Net’s skyld, på samme måde som man ikke kunne give CSS skyld for de blinkende tekster. .Net har masser af muligheder men få begrænsninger. Det er op til udviklerne at udvise den selvbehærskelse det kræver at undlade de genveje der modarbejder de forretningsmæssige mål.
Viewstate er et eksempel på en af disse muligheder som man skal omgås med forsigtighed. Jeg mener ihvertfald ikke det er god brugervenlighed at brugeren får en fejl a’la “Siden er forældet” fordi de trykker “backspace” i browseren midt i betalingsdelen. Men man er altså ikke tvunget til at bruge viewstate blot fordi man udvikler i .Net
Casper Hornstrup skriver
Der er selvfølgelig både fordele og ulemper ved .NET. Nu har jeg brugt en hel del værktøjer/sprog og jeg må sige at blandt disse der er .NET klart at foretrække til E-business applikationer:
C, C , PHP, ASP (VBscript), Delphi, Java, m.m. Memory leaks, utypede sprog, dårlige standardbiblioteker, dårlige RAD udviklingsmiljøer. Skidt, skidt, skidt. Java er på en klar andenplads efter min mening.
.NET i sig selv performer ikke vildt dårligt, men det kommer aldrig til at blive så hurtigt som unmanaged kode som C og C . Et problem er at mange udviklere har ikke performanceoptimering som en del af deres udviklingsproces. Sæt en profiler på koden. Du kan se nøjagtigt hvilken metode der brugt hvor meget af tiden. Optimer så de metoder der bruger mest tid.
Med .NET kan jeg bringe koden til dataene istedet for at bringe dataene til koden (på webserveren). Det kan give meget bedre performance i tilfælde med store datasæt. Jeg skulle arbejde på nogle datasæt med bl.a. 2,3 mill. danske adresser. Hvis du hiver de data over på webserveren så vil du få rigtig dårlig performance, så det var bedre at udføre behandlingen på databaseserveren. Første version tog 4 minutter. Det tog et par dage at få det ned på 8 sekunder. Optimering betaler sig. Man skal bare optimere de rigtige steder.