mboost-dp1
Skolestyrelsen
Magten (40) skrev:Og flere:
Jeg går ikke udfra at nogen af jer med på projektet, så hvorfra ved i at opgaven er så simpel? Jeg er bare nysgerrig - for i min verden, hvis det var så simpelt, så havde Cowi vel fundet nogen til at løse problemet og sparket @ventures ud.
Det kræver nogen siger sandheden.
Jeg kan varmt anbefalde: http://bit.ly/8nJrAW
Der er ikke mange programmør der ved hvad de i virkeligheden fortager sig ... mange sidder i et højniveaus programmeringssprog fjernt fra operativsystem og netværk, og forstår ikke hvordan disse basale ting fungere.
Jeg har måtte ligge ører til mange påstande igennem tiden:
1) Det er netværket der holder min pakke i 1 minut og 20 sekunder ... nej det er dig der ikke har fattet MTU og buffer valg i en TCP socket.
2) Hvis jeg deler problemet op i små bider går det hurtigere ... nej det går ikke hurtigere at søge igennem en 2GB byte fil hele tiden, istedet for blot at læse den igennem én gang ... nu tager det jo 7 dage før programmet bliver færdigt.
3) Hvorfor er databasen langsom? ... Frameworket du bruger holder 2.000 SQL sessioner kørende, der hver bruger resourcer, selvom du kun har én SQL forspørgelse kørende.
Kik på hvor lille en mængde data der skal analyseres i skoletesten og hvor meget én CPU kan klare i sekundet ... er resten overhead, der skal gøre programørens hverdag nemmere?
Forrige afsnit er en provokation.
Det er ikke nødvendigt at vide for 99% af det der skal laves.clysel (51) skrev:Der er ikke mange programmør der ved hvad de i virkeligheden fortager sig ... mange sidder i et højniveaus programmeringssprog fjernt fra operativsystem og netværk, og forstår ikke hvordan disse basale ting fungere.
Derudover skal man alligevel bruge 80% af sin tid på forretningsudvikling. Og det er måske vigtigere at udviklerne bliver bedre til at kommunikere med kunden, end de kan kode C og assembler.
At der er rent programmeringsmæssige problemer i arkitekturen er jo så et helt andet problem, som alligevel ikke kan løses af en datalogiker eller autodidakt C udvikler.
Problemet for @ventures er åbenbart at deres ASP.NET udviklere ikke har været egnet til opgaven.
Men det ville stadigvæk ikke nytte noget at sætte en datalog uden erfaring i C# til at udvikle systemet, fordi den tilgang du har til software udvikling fra universitet er en verden til forskel til hvordan man faktisk laver webudvikling.
Opfølgning:
Ifølge nyheder på diverse danske nyhedssite (jeg gider ikke linke), så har COWI fastslået at systemet har klaret belastningen før, og at det derfor ikke er et spørgsmål om hardware.
Altså de har bekræftet at det er en systemfejl. Hvilket betyder et eller flere af følgende:
- Dårlig arkitektur
- Dårlig kode
Så er vi ved at være nede på det niveau hvor der er mere end en håndfuld på newz.dk som kunne gøre det bedre.
Det er desværre alt for nemt at skrive dårlig performance ASP.NET. Modsat er det ikke svært at skrive god performance ASP.NET, men det kræver modet til at refactor og ændre i arkitekturen.
Hvis de nationale tests er udviklet i en vandfaldsmodel, så er der nok ikke blevet lavet nok om i arkitekturen til at fixe performance. Og så sidder der en håndfuld udviklere som ikke har en jordisk chance for at fixe problemet i dag, mens kritikken hagler ned.
Ifølge nyheder på diverse danske nyhedssite (jeg gider ikke linke), så har COWI fastslået at systemet har klaret belastningen før, og at det derfor ikke er et spørgsmål om hardware.
Altså de har bekræftet at det er en systemfejl. Hvilket betyder et eller flere af følgende:
- Dårlig arkitektur
- Dårlig kode
Så er vi ved at være nede på det niveau hvor der er mere end en håndfuld på newz.dk som kunne gøre det bedre.
Det er desværre alt for nemt at skrive dårlig performance ASP.NET. Modsat er det ikke svært at skrive god performance ASP.NET, men det kræver modet til at refactor og ændre i arkitekturen.
Hvis de nationale tests er udviklet i en vandfaldsmodel, så er der nok ikke blevet lavet nok om i arkitekturen til at fixe performance. Og så sidder der en håndfuld udviklere som ikke har en jordisk chance for at fixe problemet i dag, mens kritikken hagler ned.
clysel (51) skrev:Der er ikke mange programmør der ved hvad de i virkeligheden fortager sig ... mange sidder i et højniveaus programmeringssprog fjernt fra operativsystem og netværk, og forstår ikke hvordan disse basale ting fungere.
Programmørers evner er også normal fordelte.
Det er nødvendigt at vælge en teknologi stak, en arkitektur og en udviklings process der gør at man kan lave acceptabel software med et team med 10% Einstein'er 40% Elvis'er og 50% Mort'er.
Windcape (53) skrev:Det er ikke nødvendigt at vide for 99% af det der skal laves.
Jeg vil da mene at det er nødvendig ballast for stort set al software udvikling.
Hvis software udvikling skal være engineering og ikke 1) google, 2) copy paste, 3) virker det ikke så gå til punkt 1.
Windcape (53) skrev:Derudover skal man alligevel bruge 80% af sin tid på forretningsudvikling. Og det er måske vigtigere at udviklerne bliver bedre til at kommunikere med kunden, end de kan kode C og assembler.
Den påstand har været god latin i den danske IT branche i mange år.
Men jeg mener, at det er forkert.
Hvis god kommunikation med kunden skal have nogen effekt, så skal den der kommunikerer forstå hvad der kommunikeres om.
Gode kommuniktions evener er en god ting, men kun hvis de bygger oven på en reel IT viden. Hvis ikke grundlaget er i orden, så er det værdiløst.
Windcape (53) skrev:Men det ville stadigvæk ikke nytte noget at sætte en datalog uden erfaring i C# til at udvikle systemet, fordi den tilgang du har til software udvikling fra universitet er en verden til forskel til hvordan man faktisk laver webudvikling.
Efter min mening vil:
- en datalog uden erfaring klare sig bedre end en med kortere uddannelse uden erfaring
- en datalog med erfaring klare sig bedre end en med kortere uddannelse med erfaring
Forskellen vil dog nok være markant større i det andet tilfælde.
Du skal ikke undervurdere god uddannelse.
For at udvikle den rigtige løsning til @ventures vil jeg mene at et stærkt kendskab til C# og .NET, samt god erfaring med arkitektur er vigtigt.arne_v (58) skrev:Jeg vil da mene at det er nødvendig ballast for stort set al software udvikling.
At sætte Poul-Henning Kamp til at udvikle systemet ville give et tvivlsomt resultat. Og at udvikle det i C ville være urealistisk.
Hvis jeg skal lave en webløsning der skal supportere 200k brugere i ASP.NET, vil jeg stadigvæk mene at det er irrelevant at forstå grundlæggende programmering, da man netop ikke udvikler til et OS eller maskinel, men en webserver/applikationsserver.
Det er vigtigere at forstå HTTP, Browsers og IIS7, og måske lidt viden omkring netværk, end det er at kunne programmere i C.
Det mener jeg heller ikke jeg gør. Jeg mener bare at en datalog som kun kan kode i Haskell og C vil løse opgaven dårligere end f.eks. en Datamatiker som har kodet ASP.NET i et par år.arne_v (60) skrev:Du skal ikke undervurdere god uddannelse.
At have begge dele i samme team ville nok give en endnu bedre løsning. Men at mene at begge to skal være kernelhackers vil være en katastrofe for at udvikle webapplikationer.
Windcape (55) skrev:
Ifølge nyheder på diverse danske nyhedssite (jeg gider ikke linke), så har COWI fastslået at systemet har klaret belastningen før, og at det derfor ikke er et spørgsmål om hardware.
Altså de har bekræftet at det er en systemfejl. Hvilket betyder et eller flere af følgende:
- Dårlig arkitektur
- Dårlig kode
Fejl kan give sig sære udslag, så det kan ikke afvises at det er fejl i koden.
Men de to punkter er ikke hvor jeg ville starte en undersøgelse. Hvis noget har performet OK men lige pludseligt ikke gør det og der ikke er releaset ny kode, så ville jeg starte med at snakke med system og netværks admin. Normalt er performance af software heldigvis rimeligt konsistent (man skal bare ikke blankt afvise muligheden af at man har en unormal situation).
Windcape (61) skrev:For at udvikle den rigtige løsning til @ventures vil jeg mene at et stærkt kendskab til C# og .NET, samt god erfaring med arkitektur er vigtigt.
Helt enig.
Windcape (61) skrev:At sætte Poul-Henning Kamp til at udvikle systemet ville give et tvivlsomt resultat. Og at udvikle det i C ville være urealistisk.
PHK er ikke specielt højt på min liste over folk til at designe og udvikle en sådan web app.
Men hvis der er mange requests for static content kunne det godt give mening at putte Varnish foran web app.
Windcape (61) skrev:Hvis jeg skal lave en webløsning der skal supportere 200k brugere i ASP.NET, vil jeg stadigvæk mene at det er irrelevant at forstå grundlæggende programmering, da man netop ikke udvikler til et OS eller maskinel, men en webserver/applikationsserver.
Det er ikke muligt at designe godt performende og skalerende apps ved kun at kigge på de definerede interfaces. Man er nødt til at have en grundliggende forståelse for hvad der sker under mmotohjelmen.
Windcape (61) skrev:Det er vigtigere at forstå HTTP, Browsers og IIS7, og måske lidt viden omkring netværk, end det er at kunne programmere i C.
C er næppe nyttigt.
Men en forståelse for styre systemer, processer, tråde, memory, disk IO og netværks IO er nødvendig.
Men netop cache of static content skulle da helst have været det mindste af alle problemer.arne_v (68) skrev:Men hvis der er mange requests for static content kunne det godt give mening at putte Varnish foran web app.
Man kan også nemt mindske trafikken med bzip compression, som alle browsere understøtter i dag. Det kan gøres rimeligt nemt i ASP.NET, men bør overordnet sættes op direkte fra webserveren.
Et bud er måske at ASP.NET udviklerne hos @ventures ikke har været med til at lave opsætningen, og bare har udviklet problemet. I så fald kan det jo skabe problemer, hvis man ikke kan påpege det internt.
Men du har næsten ingen måder at styre disse på fra en typisk web-applikation. Og hvis du er en normal udvikler nede på gulvet har du sjældent muligheden for at påvirke opsætningen af disse.arne_v (68) skrev:Men en forståelse for styre systemer, processer, tråde, memory, disk IO og netværks IO er nødvendig.
Engang imellem er det ok at have specialister i højniveau teknologi som ikke ved som meget om lav-niveau.
Windcape (71) skrev:Men netop cache of static content skulle da helst have været det mindste af alle problemer.
Jeg er helt enig med:
clysel (72) skrev:Prøv at lave nogle målinger, før du gætter.
Umiddelbart ville jeg nemlig tro at cacheable content er en ret stor del. At caching kunne hjælpe bør ikke afvises upfront.
Windcape (71) skrev:Man kan også nemt mindske trafikken med bzip compression, som alle browsere understøtter i dag. Det kan gøres rimeligt nemt i ASP.NET, men bør overordnet sættes op direkte fra webserveren.
Det kunne hjælpe hvis det er båndbredden som er problemet.
Det kan heller ikke afvises.
Men sådan noget bør undersøges systematisk.
Windcape (53) skrev:Derudover skal man alligevel bruge 80% af sin tid på forretningsudvikling. Og det er måske vigtigere at udviklerne bliver bedre til at kommunikere med kunden, end de kan kode C og assembler.
Hvem snakker om at skrive C og assembler kildetekst?
Der skal bare noget basal forståelse ind for hvad man i virkeligheden fortager sig.
Hos Finans Ministeret leverandør har der ej været nogen forståelse for hvad man fortager sig ... udvikleren sidder i .NET ASP og bruger nogle fine værktøjer (og kan er sikkert udvikle 6 gange hurtigere end før), men den endelig applikation lader brugerens browser sende 9KB i en HTTP POST header som reelt kun indeholder 100 byte data ... hvorefter webserveren bruger 12 sekunder på at behandle data:
http://www.version2.dk/artikel/14081-10000-job-ska...
At der er rent programmeringsmæssige problemer i arkitekturen er jo så et helt andet problem, som alligevel ikke kan løses af en datalogiker eller autodidakt C udvikler.
Jeg ser tit der er problemer med frameworket ... det er ikke interessant for udviklingerne ... det er jo ikke deres skyld. Men med den holdning får man jo ikke løst problemet.
Men det ville stadigvæk ikke nytte noget at sætte en datalog uden erfaring i C# til at udvikle systemet, fordi den tilgang du har til software udvikling fra universitet er en verden til forskel til hvordan man faktisk laver webudvikling.
Det var da noget af en påstand.
Hvilken tilgang har man til software udvikling på et Universitet?
Er det bedre at sætte en webudvikler til at udvikle i et programmeringssprog han ikke kender?
Windcape (55) skrev:så har COWI fastslået at systemet har klaret belastningen før, og at det derfor ikke er et spørgsmål om hardware.
Hvilken logik de ligger for dagen ... det er jo praktisk at simplificere og tænke i kasser ... "den kasse har vi da ikke ændret i, så kan fejlen ikke ligge der"
Windcape (62) skrev:Det mener jeg heller ikke jeg gør. Jeg mener bare at en datalog som kun kan kode i Haskell og C vil løse opgaven dårligere end f.eks. en Datamatiker som har kodet ASP.NET i et par år.
Vi lærte, Pascal, C, Miranda, ML, Prolog, MC68K (til kerne opgaven) og SQL92 ... den næste årgang startede med ML, hvilket var genialt, da alle studerende derved var på samme niveau, og nogle ikke derved havde en fordel ... på vores hold faldt der en del med Pascal erfaringer fra, fordi de ikke fuldte med til forlæsninger og lige pludselig var de langt bagud.
Siden hen har det været trivielt at sætte sig ind i nye programmeringssprog ... det jeg har lært fra studiet er at tilegne mig ny viden.
Windcape (62) skrev:
At have begge dele i samme team ville nok give en endnu bedre løsning. Men at mene at begge to skal være kernelhackers vil være en katastrofe for at udvikle webapplikationer.
Der kommer an på hvad din applikation skal yde.
De webserver jeg sætter op, bliver OS da konfiguret til maks ydelse ... helt ned til valget af filsystem, sizing af cache ... hvilken cache er bedst, OS'ets eller databasens .. der er ikke noget svar, så det skal måles.
Kører vi bedst med én Core eller de 2 maskinen er født med ... ja jeg har i nogle situationer været nød til at slå en Core fra, for at skod applikationen kunne performere bedre.
Windcape (71) skrev:Men du har næsten ingen måder at styre disse på fra en typisk web-applikation. Og hvis du er en normal udvikler nede på gulvet har du sjældent muligheden for at påvirke opsætningen af disse.
Fordi man ikke har mulighed for at ændre X betyder det ikke at man ikke bør tage hensyn til X.
Windcape (71) skrev:Engang imellem er det ok at have specialister i højniveau teknologi som ikke ved som meget om lav-niveau.
Jeg er skeptisk overfor om man overhovedet kan være specialist i højniveau uden at have en forståelse for lavniveau.
Men netop misbrug af viewstate i ASP.NET er en af faldgruberne! Men det er også helt normalt at IKKE misbruge det, fordi man faktisk har mere end 2 måneders erfaring med ASP.NET WebForms.clysel (74) skrev:Hos Finans Ministeret leverandør har der ej været nogen forståelse for hvad man fortager sig ... udvikleren sidder i .NET ASP og bruger nogle fine værktøjer (og kan er sikkert udvikle 6 gange hurtigere end før), men den endelig applikation lader brugerens browser sende 9KB i en HTTP POST header som reelt kun indeholder 100 byte data ... hvorefter webserveren bruger 12 sekunder på at behandle data:
Ellers kunne man have brugt ASP.NET MVC, som så slet ikke bruger viewstate :)
Det er trivielt at lære ASP.NET, men du kommer nemt til at misbruge ViewState, fordi det IKKE er en del af de kurser og bøger som man typisk vil studere!clysel (74) skrev:Siden hen har det været trivielt at sætte sig ind i nye programmeringssprog ... det jeg har lært fra studiet er at tilegne mig ny viden.
Men her antager du at du med til at sætte webserveren op som webudvikler!clysel (74) skrev:Der kommer an på hvad din applikation skal yde.
De webserver jeg sætter op, bliver OS da konfiguret til maks ydelse ... helt ned til valget af filsystem, sizing af cache ... hvilken cache er bedst, OS'ets eller databasens .. der er ikke noget svar, så det skal måles.
Kører vi bedst med én Core eller de 2 maskinen er født med ... ja jeg har i nogle situationer været nød til at slå en Core fra, for at skod applikationen kunne performere bedre.
Jeg vil sige at det er ret unormalt!
Det er rigtigt, men for de fleste folk med en deadline betyder det jo typisk at man ikke gør det alligevel.arne_v (77) skrev:Fordi man ikke har mulighed for at ændre X betyder det ikke at man ikke bør tage hensyn til X.
Hvis bzip kompression skal køres over IIS, og jeg som udvikler af webapplikationen ikke kan få lov at påvirke opsætningen, så er det ude af mine hænder om det bliver slået til eller ej.
At der så kan foretages processforbedringer er en anden sag, men ikke en som handler om udviklernes kompetancer.
Jeg tænker mere teknologisk.arne_v (77) skrev:Jeg er skeptisk overfor om man overhovedet kan være specialist i højniveau uden at have en forståelse for lavniveau.
Specielt ved webudvikling kan man godt specialisere sig i produkt-teknologier, og ikke skulle fordybe sig i ting der er håndteret af webserveren eller styresystemet.
#79
Det er en af de sikre måder at få projekter kørt af sporet at arbejde i siloer.
Udviklerne laver en ASP.NET web app, DBA laver en SQLServer database, sysadm installerer Windows og IIS, netværks manden opsætter firewalls/routere/switche. Og så til sidst ser man om det hele virker fornuftigt når det skal snakke sammen.
Det duer ikke. Det hele skal designes som en helhed.
Det er en af de sikre måder at få projekter kørt af sporet at arbejde i siloer.
Udviklerne laver en ASP.NET web app, DBA laver en SQLServer database, sysadm installerer Windows og IIS, netværks manden opsætter firewalls/routere/switche. Og så til sidst ser man om det hele virker fornuftigt når det skal snakke sammen.
Det duer ikke. Det hele skal designes som en helhed.
#80
Men ikke destro mindre er det normalt at arbejde i siloer, specielt i større organisationer :-)
Og selv Einstein Dataloger som designer systemet som helhed, kan misbruge ViewState hvis de ikke ved bedre. Og jeg vil stadigvæk vove at påstå at datalog som måske er god til matematik og kan kode i ML og Erlang, stadigvæk har ligeså høj chance for at misbruge ViewStage som enhver anden! (Da konceptet er rimelig enestående for WebForms som teknologi)
Erfaring med kritisk systemer, og derudover en høj selvkritik og nysgerrighed er absolutte nødvendigheder for enhver udvikler til 100-million projekter.
Og selvfølgelig en chef som acceptere at du har lært at noget var forkert, og at det skal kodes om, selvom det virker. Dette her er nok det sværeste punkt.
Men ikke destro mindre er det normalt at arbejde i siloer, specielt i større organisationer :-)
Og selv Einstein Dataloger som designer systemet som helhed, kan misbruge ViewState hvis de ikke ved bedre. Og jeg vil stadigvæk vove at påstå at datalog som måske er god til matematik og kan kode i ML og Erlang, stadigvæk har ligeså høj chance for at misbruge ViewStage som enhver anden! (Da konceptet er rimelig enestående for WebForms som teknologi)
Erfaring med kritisk systemer, og derudover en høj selvkritik og nysgerrighed er absolutte nødvendigheder for enhver udvikler til 100-million projekter.
Og selvfølgelig en chef som acceptere at du har lært at noget var forkert, og at det skal kodes om, selvom det virker. Dette her er nok det sværeste punkt.
Windcape (81) skrev:Og selv Einstein Dataloger som designer systemet som helhed, kan misbruge ViewState hvis de ikke ved bedre. Og jeg vil stadigvæk vove at påstå at datalog som måske er god til matematik og kan kode i ML og Erlang, stadigvæk har ligeså høj chance for at misbruge ViewStage som enhver anden!
Udover at lære ML o.lign. skulle de også gerne have lært en masse om at arbejde med problemer analytisk, som gerne skulle udmønte sig i bedre løsninger.
Windcape (81) skrev:(Da konceptet er rimelig enestående for WebForms som teknologi)
Du kan godt bede JSF om at gemme state client side.
Det skal måske nævnes at de fleste ASP.NET udviklere som har erfaring med andre teknologier, samt lederne af det internationale community (som f.eks. Jeff Atwood) alle mener at ASP.NET MVC er en bedre teknologi og udnyttelse af C# end WebForms er!clysel (51) skrev:Kik på hvor lille en mængde data der skal analyseres i skoletesten og hvor meget én CPU kan klare i sekundet ... er resten overhead, der skal gøre programørens hverdag nemmere?
Netop problemer og misbrug af ViewStage, og mange andre problemstillinger har fået folk til at fravælge teknologien.
Jeg kan forsikre dig om at der er ligeså mange problemer havde du valgt at basere din løsning på f.eks. PHP med Zend, eller Python med Django.
Og RoR er også kendt for at være skalere afskyeligt.
Så hvis du vil foreslå en bedre teknologi er du da velkommen :)
Jeg tvivler på det er det de har sagt. Det er nok nærmere fordi folk har stillet spørgsmålstegn ved om miljøet var underdimensioneret - men når miljøet tidligere har klaret samme belastning + mere, så er det jo næppe grunden.clysel (74) skrev:Hvilken logik de ligger for dagen ... det er jo praktisk at simplificere og tænke i kasser ... "den kasse har vi da ikke ændret i, så kan fejlen ikke ligge der"
Windcape (78) skrev:Men netop misbrug af viewstate i ASP.NET er en af faldgruberne! Men det er også helt normalt at IKKE misbruge det, fordi man faktisk har mere end 2 måneders erfaring med ASP.NET WebForms.
Eller man blot interesseret sig i hvad man i virkeligheden laver.
Kik i netværket. Et simpelt mozilla plugin som firebug kan vise det.
Windcape (78) skrev:
Men her antager du at du med til at sætte webserveren op som webudvikler!
Jeg vil sige at det er ret unormalt!
Enig ... det flytter blot udviklingerne væk fra hvad de i virkeligheden gør, og deres dårlige design er derved andres problem.
Nej & nej. Men du tror da vel ikke at de helt lader være med at undersøge hardwaren?clysel (88) skrev:Giver hardware altid den samme ydelse?
Er hardware fejlfrit?
Jeg kan iøvrigt ikke finde nogen steder hvor Cowi afviser at det er hardware problemer. Kun at de siger systemet tidligere har haft samme belastning og mere til.
Magten (90) skrev:Jeg kan iøvrigt ikke finde nogen steder hvor Cowi afviser at det er hardware problemer. Kun at de siger systemet tidligere har haft samme belastning og mere til.
Formuleringen var:
COWI fastslået at systemet har klaret belastningen før, og at det derfor ikke er et spørgsmål om hardware.
Vores leverandør til de automatiske lagerområder og sorteringsanlæg havde samme holdning ... og det er en rigtig god holdning at have .... HVIS man er leverandør og ikke gider at hjælpe til med at løse problemet .. det kan man som leverandør jo miste penge på (de arbejder jo helst ikke gratis, ej hvis det er deres fejl).
Windcape (71) skrev:Men du har næsten ingen måder at styre disse på fra en typisk web-applikation. Og hvis du er en normal udvikler nede på gulvet har du sjældent muligheden for at påvirke opsætningen af disse.arne_v (68) skrev:Men en forståelse for styre systemer, processer, tråde, memory, disk IO og netværks IO er nødvendig.
Det er ikke helt korrekt, du kan rent faktisk gøre stortset hvad der passer dig inde i IIS'en (dermed ikke sagt at der ikke er faldgruber man skal være opmærksom på). IIS 7 arkitekturen tillader endda at hooke ind på stortset alle niveauer i pipelinen. Et solidt kendskab til OS arkitekturen kan faktisk betyde uhyggelig meget for hvordan man vælger at udvikle sine webapplikationer - hvis der er tale om noget der skal kunne håndtere rigtig mange requests.
En tommelfingerregel når det kommer til ASP.NET og high-performance er at gå udenom alle de her ting som er ment til at gøre livet lettere for udviklerne (gælder formentlig ikke kun ASP.NET) - og lad være med at gøre brug af frameworks og teknologier du ikke forstår i detaljer hvordan fungerer, om man så skal skrive dem selv fra bunden for at opnå det.
Det er desværre en ret udbredt tendens at framework-udviklere har sat loftet for deres teknologier sådan ca. omkring en mellemstor webshop der måske har 500.000 daglige hits. Når man så laver noget der skal kunne håndtere 500.000.000 daglige hits, så knækker de forskellige hjælpeframeworks sammen. Så lærer man at lave tingene selv og så lærer man at sætte sig ind i OS arkitekturen :-)
Hvis man ikke forstår hvad der sker med ens applikation fra højeste abstraktionslag og hele vejen ned igennem OS arkitekturen og ned på hardware-niveau - så bør man i det mindste stræbe efter at forstå det, hvis man er interesseret i at forbedre sine evner indenfor alle former for software-udvikling. Der er skrevet massere af bøger på området, som enhver udvikler med respekt for sit erhverv burde læse.
gnarfsan (94) skrev:Man kan dog have sin tvivl om hvor pengene er blevet af, for det er godtnok mange timer, med plads til masser af tests.
Det lyder af meget.
Men software projekter skalerer jammerligt.
Sådan groft sagt:
timeforbrug = konstant * pow(funktionalitet, 1.2)
Store projekter virker altid dyre.
arne_v (98) skrev:Store projekter virker altid dyre.
Jo tak, men 33 mand der ikke laver andet i et helt år, til 1500 kr i timen? Jeg ved godt at der også er at der også er overhead i form af analyse og projektering, men stadig. Så kompliceret virker den opgave heller ikke. (Jeg er selv programmør/udvikler)
mstify (96) skrev:
lad være med at gøre brug af frameworks og teknologier du ikke forstår i detaljer hvordan fungerer, om man så skal skrive dem selv fra bunden for at opnå det.
Jeg er helt enig hvad du skriver.
En af mine venner havde en opgave han tabte til anden side.
Dem der fik opgaven, havde fået en ide om de selv kunne implementere en SQL server der ydede bedre. (Det var det helt vilde setup, med RAM til at cache alt, og flere servere, og sync mellem dem, alt hvad de kunne finde på af smarte ting, og masser af penge til konsulenter og hardware)
Men det ydede forfærdeligt uden den store belastning. De søgte derfor hjælp hos ham, hvilket han nægtede hvis ikke han fik opgaven.
Til sidst fik han opgaven, brugte et par dage og installerede det på en hjemmebygget maskine. Da besøgstallet steg, da deres kataloger blev sent ud til skandinavien, blev deres 10Mbit linie belastet maks (CPU 96% idle).
BZip fjernede 10Mbit belastningen og maskinen ligger på 90% idle når den er hårdest belastet.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund