DT blogi

Kuidas kulgesid kaugelt maalt tellitud projektid

Gunnar — Thu, 02 Sep 2010 10:25:13 +0000

Raskel ajal tellisid nii mõnedki inimesed omale tarkvaraarendustöid odavatest välisriikidest ja ega nad rõõmustama just pidanud. Ei suutnud minagi neid kõiki aidata, sest pole ma vana jumal, kes sõrmega osutades kõik jubedused siin ilmas lilleliseks suudaks maalida. Annan käesolevaga ülevaate sellest, mis proovijatel valesti läks ja millised olid tulemused.

Meist kaugel-kaugel Indias ja Pakistanis asuvate arendajate käest tellimisel eeldas kohalik äriboss midagi sellist:

hinnad on oluliselt odavamad, kuid tööde kvaliteet umbes sama, mis meil või natukene halvem, kuid siiski ei midagi hullu,
tööde tähtajad on umbes samad,
arendajaga tegeleme umbes sama palju, kui tänagi,
lõpeks laabub kõik hästi, nagu oleme harjunud.

Mõistlikud eeldused, kui peale vaatame ja midagi liigkeerukat polegi justkui küsitud.

Kogemused olid aga sellised:

hinnad on odavamad, kuid tööde kvaliteet ei kannata kriitikat,
arendajatel praktiliselt puudub iseseisev mõtlemine,
arusaam ja intuitsioon tellija soovide osas on pea olematu,
kõik asjad tuleb näpuga ette näidata ning teha puust ja punaseks nagu esimese klassi õpilasele,
kommunikatsioon on oluliselt tihedam, et asjad liiguksid, selgitada on vaja ka kõige elementaarsemaid asju, vigu toodetakse metsikult, neid parandatakse väga aeglaselt,
tööd valmivad kaootiliselt.

Ja kõige lõpuks need asjad, mis minu laualt läbi käisid ja mis pidid olema kvaliteetsed ja valmis, olid sellised:

80% lähtekoodist on kaootiline spagett, täis turvaauke, nigelaid lahendusi ja lausabsurdi,
ülejäänud 20% koodist on lahendatud nii halvasti ja tellija vajadustest mööda, et see tuleb täismahus ümber kirjutada.

Tulemus selline. Tehes nüüd lihtsa liitmistehte, saame tulemuseks, et suures ulatuses parandusi ja ümbertegemist vajab 100% lähtekoodist. Olge väga ettevaatlikud enne kui antud regioonidest midagi tellima hakkate ja kui teisiti ei saa, siis valmistage ette plaan kõikideks eeltoodud tõrgeteks.

Loe lisaks

Eneta ettekanded septembris

Gunnar — Mon, 30 Aug 2010 11:00:56 +0000

Sügisekuulutajana toimus Eneta raames ära juba üks ettekanne, kus ma tutvustasin põgusalt ASP.NET MVC kolmandamat versiooni, mis veel valmimisel. Septembris tõmbame aga kogu hooaja täiel tuuril jälle käima ja sissejuhatuseks on tulemas kolm põnevat ettekannet, millest siin paari sõnaga juttu teen.

08.09 – Teeme ise Windows … installika!

Heiki Tähis tutvustab meile kuidas teha ise Windows 7 installikas, mis just enda soovide järgi kohandatud. Ettekanne on suunatud inimestele, kes hoolitsevad pisemate firmade ja koduste arvutite eest. Loomulikult võivad kuulama tulla ka kõik teised, kellele see teema huvi pakub – nagu alati.

Ettekandele registreerumiseks kliki seda linki!

15.09 – Rääkimata jutud Exchange Server 2010st

Toomas Ruus Microsoftist paljastab meile mõningaid Exchange Server 2010 saladusi. Ettekandel on oodata rohkelt demosid. Tegemist rohkem adminide üritusega, kuid oodatud on ka kõik teised huvilised.

Ettekandele registreerumiseks kliki seda linki!

29.09 – UrlScan ja ASP.NET filtreerimine

Kuido Külm teeb loengul juttu lühidalt vajalikest baasteadmistest: kuidas IIS päringut töötleb, POST ja GET päringud, HttpModule ja HttpHandler. Lisaks sellest, mida kujutavad endast ISAPI Filter UrlScan ja Request Filtering ning kuidas neid olemasolevatele rakendustele seadistada ja mida võiks neist teada enne tarkvara loomist. Tegemist on ettekandega, mis võiks huvi pakkuda nii arendajatele kui ka adminidele.

Ettekandele registreerumiseks kliki seda linki!

Kindlasti pakub igasugu lahedaid ettekandeid ka oktoober, kuid sellest on veel vara rääkida. Käime algul ära siintoodud ettekannetel!

Loe lisaks

Andmevähi ravimine

Gunnar — Mon, 30 Aug 2010 08:00:44 +0000

Andmevähi ravimine pole lihtsamate killast tegemine. Mida kaugemale vähk on arenenud seda vaevalisem on ka ravi ja paljudel juhtudel on ravist oluliselt soodsam alustada alates nullist. Et ma niisama vingujate vendade ja nutunaiste kampa ei kuulu, siis pakun alati probleemidele välja ka lahendused. Selles kandes tutvustan ülevaatlikul tasemel plaani andmevähi ravimiseks. Kellel kogemusi, siis kõik tagasiside – nagu ikka – on teretulnud.

Tihti mõtlevad arendajad nii, et kui miski on katki, siis küll me selle kuidagi siva korda saame. Enamasti see aga nii ei lähe, sest meie käsitleme juhtumit, kus probleemid on tõusnud või tõusmas juba taevani. Rakenduse silumine, testimine ja edasiarendamine on muutunud elusaks põrguks, millest väljapääsu ei paista olevat. Kas tunneli lõpus paistab valgus või on see lähenev rong, mis projekti lõplikult tapab?

Plaan andmevähi ravimiseks

Eelmises andmevähi kandes kirjeldasin ära probleemid lähtekoodiga. Selles kandes püüan anda tegevuskava asjade samm-sammult parandamiseks. Kes loodab leida siit hõbekuuli, siis teadku, et ainus hõbekuul on projekti alguses korralik eeltöö ja oma meeskonna järjepidev harimine. Andmevähi tootnud tiimi jaoks on see hetkel tagantjärgi tarkus.

Sammud andmevähi raviks on järgmised:

Koonda päringud ja objektide loomine algul manager-klassidesse. See ei ole küll hea praktika lõplikuks lahenduseks, kuid mõtle sellele nagu põrandate pesemisele – põrandalt kõrgemale tõstetud asjad jäävad sinna ainult ajutiselt. Vähemasti hakkab kord tasapisi tekkima.
Vii päringud ja objektide loomine eraldi klassidesse. Sel teel muutuvad ajutised manager-id oluliselt õhemaks ja lihtsamini käsitletavaks. Jälgi hoolega, et igat tüüpi objektide luuakse ainult ühes kohas, mitte mitmes. Muidu paranemist pole, vähk võtab ainult teise kuju.
Muuda oma lähtekoodi selliselt, et ADO.NET objekte rakenduse äriloogika ja kasutusliidese kihis ei kasutata. See tähendab seda, et mainitud kihid saavad oma objektid kätte manager-ide käest.

Ma soovitan siinkohal appi võtta ka andmebaasidega tegelevad professionaalid, sest nende käest saab kuldaväärt teavet tavaliselt ja ma ei mõista, miks hoitakse neid enamasti arendusprotsessist nii kaugel. Muide, ka see on üks andmevähi põhjuseid, et õigete meeste käest jäetakse küsimata ja püütakse ise olla sama targad, kuigi teadmised puuduvad.

Nüüd on suurem tuli kustutatud ning esmane kord majja loodud. Sama mustrit hoides on võimalik vähemalt osal tiimist jätkata uute arendustega, kuid midagi suuremahulist ei soovita ma enne täieliku korra saabumist käsile võtta. Ütleme nii, et olukord on juba parem, kuid masinaid me haige küljest veel eemaldada ei saa.

Edasise arhitektuuri valimine

Ma ütlen just nimelt edasise, sest sellist asja nagu õige arhitektuur või ideaalne arhitektuur pole olemas. Inimesed, kes sellist asja jutlustavad, meenutavad mulle alati neid pealappidega fundamentaliste, kes ühe ja ainsa idee ja jumala nimel on nõus ükskõik millisteks tegudeks. Jääme meie aga maailmaga sõbraks ja võtame teadmiseks, et arhitektuur pole kas õige või vale, vaid rohkem või vähem sobiv. Kuid igal juhul peab see arvestama sellega, kus oleme täna ja kuhu jõutakse näiteks ülehomme. Üle pole mõtet pingutada.

Nüüd tuleb hoolega hinnata rakenduse mahtu ja selle edasisi arenguid. Soovitan kliendiga selles osas nõu pidada, et saada selgem pilt sellest, kuhu näiteks lähema paari aasta jooksul püütakse jõuda. Sellest lähtuvalt saab valida ka strateegia andmetega tegelemiseks. Martin Fowler pakub oma kultusteoses Patterns of Enterprise Application Architecture välja kolm võimalikku lähenemist:

Transaction Script – see on enam-vähem see, mis meil praegu olemas on, kuid korrastamist on vaja enam. See lähenemine sobib hästi rakendustele, mis on pisikesed ja lihtsad.
Table Module – andmebaasi tabelile seatakse vastavusse klass, mis teostab kõik sellega seonduvad operatsioonid. Midagi sellist on meilgi osaliselt olemas. See lähenemine sobib pisut suurematele rakendustele, mis ei tegele millegi keerukaga. Peamiselt andmete edasi-tagasi liigutamine lihtsal kujul.
Domain Model – täismahus objekt-orienteeritud objektmudel, mis kannab endas nii andmeid kui nendega seotud operatsioone.

Ma eelistan enamasti just viimast neist, kuid lihtsaid ja primitiivsemat laadi rakendusi ma sellise monstrumiga koormama ei hakka. Sellel puudub igasugune mõte ja jutt sellest, kuidas kümmet andmebaasi käsku tundev rakendus vajab täismahus teste, on suhteliselt absurd.

Koodi migreerimine uuele arhitektuurile

Peale arhitektuuri valikut tuleb otsustada ära, kuidas rakendus koodi üleviimine hakkab toimuma. Hea on mõelda, et teeme korraga kõik ühe hingetõmbega ära, kuid see toimib ainult väikeste rakenduste korral. Aastaid arendatud rakendused on enamasti nii mahukad, et vaja on plaani näiteks järgmise kuu kuni kolme või miks mitte ka pikema ajalise perioodi jaoks.

Kui tegemist on pikema ja mahukama tööga, siis üheks keerukaks kohaks saab uue arhitektuuri kasutamine paralleelselt vanaga. Need kaks asja tuleb omavahel liidestada ja neid tuleb paralleelselt kasutada vähemasti mõnda aega. Mõned soovitused:

planeeri migreerimine väga hoolikalt – see teeb protsessi oluliselt lihtsamaks, sest keerukaid üllatusi tuleb ette niigi palju,
kui on vähegi võimalik, siis planeeri migreerimine mõistliku suurusega tükkidena – näiteks vormi kaupa või klassi kaupa (sõltub olukorrast),
kohad, kus tuleb paratamatult kasutada uut ja vana korraga, tee sellised, et liidestamisel ei puudutatakse uue arhitektuuriga seonduvat – ajutiselt loodud klassid kustutad sa niigi lõpuks maha ja parem nakata halbade haigustega kaduv kood, mitte see, mis jääb.

Selle tegemise lõpuks peab käes olema olukord, kus vahepeal loodud korra eesmärgilised klassid võib kõik maha kustutada.

Kokkuvõtteks

Kogu see tegemine tundub hoomatav ja üldse mitte suur, kui seda eemalt vaadata. Kes korra käed on külge löönud, see avastab, et tegemist on oluliselt rohkem, kui keegi seda alguses oskas ette kujutada. Hea plaan on ajalised puhvrid võtta sellise tegemise juures suure varuga ja kindlasti tuleb teha väga põhjalik eeltöö, et niigi suur ootamatuste arv viia miinimumi.

Loe lisaks

Tarkvaraarendus, veeb, mobiilsüsteemid - Developers Team

MSDN Magazine ja Dr. Dobb’s digitaalselt tasuta saadaval!

Gunnar — Sun, 29 Aug 2010 20:33:23 +0000

Microsoft pakub tasuta lugemiseks MSDN Magazine ja Dr. Dobb’s ajakirjade digitaalseid versioone. Ainus, mis digitaalsete versioonide saamiseks teha tuleb, on täita oma profiil Microsofti lehel.

Soovitan, kui vähegi võimalik kasutada Internet Explorerit profiili täitmisel, sest teiste brauseritega on seal kohati tõrkeid esinenud ja ma ei ole 100% kindel, kas need pikka aega mind seganud vead on seal juba parandatud või ei. Ajakirjade tellimiseks klikka järgmisel pildil.

Egas muud, et head lugemist kui esimesed nummerid kohale jõuavad!

Loe lisaks

Mis juhtub kui andmekihi asemel on andmevähk?

Gunnar — Sat, 28 Aug 2010 15:19:52 +0000

Aeg-ajalt kirjutan ma siia ka paranähtustest tarkvaraarenduses. Mõtlesin, et tänagi võiks natukese üldisemal teemal jutustada ja võtta vaatluse alla, mis juhtub, kui andmed valatakse rakendusele selga nagu oleks keegi suure õlitünni ümber ajanud. Pealtnäha pole see probleem ehk hirmsaim, mis juhtuda võib, kuid lahkamisel see arvamus ehk muutub.

Nime “The mind is terrible thing to taste” pani ühele oma algusaastate plaadile industriaalset metalli viljelev loominguline kollektiiv Ministry. Tundub, et algne pisut väänatud fraas peab tihti paika, kui mõnelt süsteemilt kergitada kaas ja sisse piiluda. Hiljuti puutusin kokku ühe päris mahuka elajaga, millel hoolimata kõrgest east puudus nii arhitektuur, tehniline disain kui ka ühtne andmete käsitlus. Otsustasin paar väikest mõtet siiagi poetada, äkki on kellelgi sellest kasu.

ADO.NET valedes kätes

Tihti hakkab õnnetus pihta ohtratest artiklitest ja juhenditest, mis tutvustavad ADO.NET-i kui taevamannat ja õiget teed, mida minna. Rakenduse kasvades saab sellest väikeste sammude kaupa aga õudusunenägu, mis levib läbi rakenduse nagu ravimatu vähkkasvaja. Kujutage ette rakendust, mille äriklassid on täis koodi, mis küsib ADO.NET andmeid, kombineerib tabelitest andmeid ja moodustab uusi ADO.NET-i objekte, et need anda tagasi kasutusliidesele või teistele klassidele, mis taolise keemiaga edasi tegelevad.

ADO.NET-il on oma kindel koht rakendustes, kuid kindlasti ei pea ADO.NET-i objektid rändama läbi kõikide rakenduse kihtide. Keegi suurtest objekt-orienteeritud maailma isandatest nimetas taolist lähenemist tahtlikuks kuriteoks oma leivaisa vastu. Ja peale taolise salati nägemist saan aru, et ta oli oma ütlusis isegi leebe.

ADO.NET objekte on hea kasutada pisemates rakendustes, kuid kui meil on juba tegemist millegi sellisega, kus me jagame rakenduse erinevatesse kihtidesse, siis ADO.NET koht on andmekiht ja kaugemale see ulatuda sealt ilma hea põhjuseta ei tohiks. Või vähemasti ei tohiks see näha olla muudesse kihtidesse otse, sest alati leidub mõni vähe kogenud arendaja või muidu tuulepea, kes pikemalt mõtlemata sellest haarab.

Aja jooksul tekkivad probleemid

Probleeme, mis aja jooksul tasapisi väikeste sammudena tekib, ei ole just vähe. Ja oma olemuselt on need väga halvad, sest viivad vääramatult rakenduse kas surma sel teel, et selle hoolduskulud kasvavad taevasse või muutuvad uued arendused hoolimata mahust järjest utoopilisemaks oma hindadelt. Lisaks sellele kasvab ajakulu samas rütmis. Peamised probleemid, mis tekivad ja mille parandamine on jube kulukas, on järgmised.

Palju korduvat koodi – kuna andmed liiguvad mööda rakendust ringi nii objektide kui ka ADO.NET tabelitena, siis tekib mitmeid kohti erinevates klassides, kus mõni uus objekt nagu mullamutt oma nina maa seest välja pistab. Kui objekt saab juurde uue omaduse, siis tuleb teha vastav andmetega seotud muudatus kõikjale, kus antud objekt ADO.NET andmetest kokku pannakse.
Korduvad andmete teisendused – mitu haru lähtekoodis, kus ADO.NET kasvaja läbi on harud ajanud, vajavad andmete teisendamist ning teisendused rakendatakse kohtades, kus neid kas kohe või peatselt vaja läheb – iga arendaja teeb seda paraku enda kõhutunde järgi, sest reegleid pole kokku lepitud. Tulemus sama, mis eelmisel juhul.
Dubleeritud päringud – varem või hiljem leiab keegi andmebaasi liiklust optimeerides, et igati hea plaan on pärida ühe päringuga ära ka seonduvate objektide andmed. Miks mitte teha nii, kui näiteks O/R-mapperites on taoline strateegia kasutuses? Nüüd jõuame segadusega uuele tasemele – üks muudatus ühes tabelis võib põhjustada näiteks paarkümmend sarnast muudatust lähtekoodis erinevates kohtades. Inimtööd kulub sellise muudatuse tegemiseks mõnusalt. Kui on tegemist uue arendajaga projektis, siis pole imestada kui antud muudatuse tegemine koodibaasi võtab tal aega nädal või enam.
Hüppeliselt kasvav keerukus – iga uuendusega muutub rakendus järjest keerukamaks, sest “ummistunud” kohad, kus on tegevusi juba liiga palju, jäävad puutumata ning nakkuse saavad omale külge järjest uued kohad, mis seni on olnud õhukesed ja lihtsasti käsitletavad. Selle tulemusena muutub kood väikeste sammudena veelgi raskemini hallatavaks ja kontrollitavaks.

Kindlasti võib siia nimekirja lisada muidki probleeme. Näiteks tähendab taolises rakenduse korral lihtne muudatus andmebaasis seda, et üle tuleb testida kogu süsteem, mitte ainult see süsteemiosa, mida antud muudatus puudutas – mine tea, kus nurga taga veel vastavat tüüpi objekte luuakse.

Probleemid äripooles

Äriline pool hakkab antud problemaatika tekkimisel ja kasvamisel samuti uppuma probleemidesse, mida on järjest raskem ja raskem lahendada. Probleemid on lühidalt sellised.

Ebatäpsed ajahinnangud – ajaliste hinnangute andmine uutele funktsionaalsustele muutub järjest ebatäpsemaks, sest arendajad suudavad järjest vähem hinnata kohtade arvus süsteemis, mida antud uuendused mõjutavad.
Palju tasuta tööd – eelnevalt mainitud ebatäpsused toovad endaga kaasa palju sellist tööd, mis on ootamatu ning kasvab välja äkitselt nagu tapjalaine vaiksest veest. Kliendi käest ei saa raha juurde küsida, sest tema on lähtunud uute funktsionaalsuste tellimisel oma eelarvest ning jutt näiteks viis korda kallimast hinnast võib lõppeda kliendisuhte katkemisega. Paraku on enamasti nii, et sellisel juhul teeb teostaja antud tööd ära oma taskust, oma arendajate ületundide arvega, et graafikus püsida.
Uute tööde alustamine viibib – kui ajamahukaid “uudiseid” on kuhjunud piisavalt, siis valitseb tööde ajakavas juba parandamatu kaos. Uued tööd, millega arendajad peaksid kohe-kohe alustama, viibivad ning keegi ei oska öelda, millal nad probleemid lahendatud saavad. Samal ajal toob iga arvel olev päev välja veel uusi probleeme, mille lahendamiseks pole ei aega ega raha planeeritud.

Mida kõrgemalt tasemelt vaadata, seda suuremad need probleemid on.

Mis saab sellisest süsteemis edasi?

Enamasti loetakse taolisesse punkti jõudnud süsteem ebaõnnestunud, läbikukkunuks ning arendus peatatakse. Tellija otsib omale uued teostajad ning leiab rahalised vahendid süsteemi uueks versiooniks, mis ehitatakse üles alates nullist. Kuid nii ei lähe see igakord.

Kui süsteemi on ehitatud piisavalt kaua ja see on juba aastaid olnud kasutuses, siis võidakse otsustada ka perestroika kasuks, mille käigus tehakse kaosest kord. See ei ole ei lihtne ega odav protsess, kuid kui lasta kaosel edasi kasvada tõuseb selle likvideerimise ajakulu päevast päeva suurte hüpetena.

Milline on parim variant taolise süsteemiga edasi liikumiseks sõltub juba konkreetsest olukorrast ja probleemistikust. Ühest valemit ei ole ning enamasti mängib olulist rolli ka see, milliseks on antud ajaks kujunenud tellija ja teostaja suhted.

Loe lisaks

Andmevähi ravimine

Firefox Throttle - kuidas käitub veebirakendus erinevate ühendustega

Gunnar — Sat, 28 Aug 2010 13:04:12 +0000

Veebirakendusi on hea testida erineva kiirusega ühenduste otsas. Ühendusi ennast pole aga tihti kuigi lihtne organiseerida. Firefoxi jaoks on selleks otstarbeks loodud plugin nimega Firefox Throttle, mis aitab arendajatel veebirakendusi testida erineva kiirusega ühenduste võtmes.

Firefox Throttle on seadistatav lihtsa akna abil.

Läbi saab mängida erinevad alla- ja üleslaadimise kiirused, seejuures saab mängida ka stsenaariumit, kus GPRS-võrk on vahel või miks mitte üliaeglane GSM Data.

AJAX-i rakenduste juures on mõistlik allalaadimise kiirus äärmiselt oluline. Katsed kohalike mobiilvõrkude GPRS-iga näitasid, et päris paljud lehed ei avane korralikult, kuna ühendustel tekib timeout. Firefox Throttle ei pruugi küll täpselt järgi mängida GPRS-võrkude hädasid, kuid abi veebirakenduste testimisel on temast kõvasti.

Loe lisaks

ASP.NET MVC 3 seminari kokkuvõte

Gunnar — Thu, 26 Aug 2010 08:25:22 +0000

Eile toimunud ASP.NET MVC 3 seminaril tutvustasin ASP.NET MVC 3 Preview 1 põhjal uuendusi, mis on tulemas. Neile, kes kohale ei saanud tulla, annan kiire ülevaate räägitust ja lisan juurde ühe seminaril tehtud näite ka. Et osalejatelgi huvitavam oleks, siis kande lõpust leiab ühe peatüki eksklusiivset sisu kah. Lähipäevil panen Eneta portaali üles ka ettekande slaidid ja koodinäiteid, nii et hoidke silma peal, kellel huvi on.

Peamised uuendused on järgmised:

DI konteinerite ja Service Locator tugi (see on küllaltki vähe dokumenteeritud teema, kuid selle leevenduseks on installeriga kaasas näiterakendus antud teemadel),

Razor view engine,

Globaalsed action filtrid,

Action result-id erinevate HTTP staatuse koodide määramiseks,

andmevahetus kontrolleriga üle ViewModel objekti,

JSON pöördumiste tugi kontrollerite meetodites,

.NET 4.0 valideerimise raamistiku tugi,

Uued ümbersuunamismeetodid.

Et tegemist on ASP.NET MVC versiooniga, mis pole RC, siis on selge, et lõplik featuuride koosseis ei ole 100% paigas ja kindlasti lisandub juurde veel palju huvitavat.

Vedamaks välja tasemele 300 vastavat kannet, annan edasi ühe näite ka, mis seminaril tehtud sai. Teemaks siis uued action result-id ja serveri staatuse koodidega mängimine.

HttpNotFoundResult ja HttpStatusCodeResult

Need kaks uut action result-i võimaldavad tekitada olukorra, kus kontrolleri meetodi kutsumine lõpeb HTTP staatuse koodi muutmisega. Seni on tulnud seda teha pisut häkkide laadselt. Näiteks:

public ActionResult Product(int id)
{
var model = _productModel;
var product = model.GetProductById(id);

if (product == null)
{
Response.StatusCode = 404;
return View("Error404");
}

return View(product);
}

Nüüd saame näiteks puuduva lehe korral kasutada sellist lähenemist:

public ActionResult Product(int id)
{
var model = _productModel;
var product = model.GetProductById(id);

if (product == null)
return new HttpNotFoundResult();
//return new HttpStatusCodeResult(404);
//return HttpNotFound();

return View(product);
}

Välja kommenteeritud read annavad sama tulemuse, mis return järel välja kommenteerimata rida. Pole ju erilist vahet kahe näidatud meetodi vahel, võiks öelda. Aga on. Vähemasti nende jaoks, kes teste viitsivad kirjutada ja kelle rakendused seega kvaliteedilt konkurentidele pika puuga ära panevad.

HttpNotFoundResult kasutamine ühiktestides

Kontrolleri meetodite testimise teeb teinekord tülikaks just see, et koos kontrolleriga tuleb mängu veebiraamistiku alumiste kihtide klasse. Selleks, et eeltoodud meetodi testida, tuli varem testides ajada kontrolleri instantsile külge ka kõik HTTP-konteksti objektid. Mulle see lähenemine väga ei meeldi, sest parem kui testid on õhukesed ja parem kui neid saab kirjutada lihtsa vaevaga – palju saab neid kokku nii või teisiti.

Järgnevalt üks kiire näide testist, mis kontrollib eeltoodud meetodit olukorras, kus toodet ei leitud. Tegemist on ebaviisaka all-in-one meetodiga, mis päris koodis esineda ei tohiks (kuigi Eestis ma olen näinud vist kõik näited lives ära sellest, kuidas ei tohi).

[TestMethod]
public void ProductPageShouldReturn404IfProductNotFound()
{
var productId = 1;
var product = new Product
{
Id = 2,
Name = "Heineken",
Producer = "Heineken International",
Amount = 0.33M,
Unit = "l",
Price = 1.7M
};
var productList = new List { product };

product = null;

var model = new Mock();
model.Setup(c => c.GetProducts())
.Returns(productList);

model.Setup(c => c.GetProductById(productId))
.Returns(product)
.Verifiable();

var controller = new HomeController(model.Object);
var result = controller.Product(productId);

model.Verify();
Assert.IsNotNull(result);
Assert.IsInstanceOfType(result, typeof(HttpNotFoundResult));
}

Suurem osa testi koodist tegeleb sellega, et asendada mudeli meetodite kutsed ära meile sobivatega. Kontrolleri enda jooksutamine ja tulemuste kontrollimine on vaid paar tühist rida. Ei mingit jamamist HTTP-konteksti objektidega.

HttpStatusCodeResult laiendamine

HttpNotFoundResult ja HttpStatusCodeResult on küll head, kuid samas pisut puudulikud – hetkel ei saa me koos nendega anda kaasa sisu. Näiteks vea 404 korral oleks tore, kui saaksime anda edasi ka kasutajale arusaadava väljundi.

Mina lahendasin selle probleemi selliselt, et tegin uue klassi, mille baasiks on ViewResult. Klass ise on selline:

public class HttpStatusCodeWithBodyResult: ViewResult
{
private int _statusCode;
private string _description;

public HttpStatusCodeWithBodyResult(int statusCode,
string description = null)
: this(null, statusCode, description)
{

}
public HttpStatusCodeWithBodyResult(string viewName, int statusCode,
string description = null)
{
_statusCode = statusCode;
_description = description;
ViewName = viewName;
}

public override void ExecuteResult(ControllerContext context)
{
var httpContext = context.HttpContext;
var response = httpContext.Response;

response.StatusCode = _statusCode;
response.StatusDescription = _description;

base.ExecuteResult(context);
}
}

Ja koodis võiks seda kasutada selliselt:

public ActionResult NotFound()
{
var msg = "I cannot find this resource!";

// vajalik on vaade nimega NotFound.aspx või NotFound.cshtml
var result = new HttpStatusCodeResultWithBody("NotFound", 404, msg);
return result;
}

View nimega ProductError404.aspx on see, mis sisaldab kasutajale arusaadavat teksti tekkinud vea kohta.

Kokkuvõtteks

Kuigi aega oli seminaril vähe, sai siiski kõik oluline edasi antud. Tänastel ASP.NET MVC fännidel soovitan kindlasti kolmandama versiooniga hakata tutvust tegema, sest veel on aega selleks, et rääkida uue versiooni arengus kaasa. Vähemasti on minul selleks võimalus olemas ja kellel on uue versiooni osas soove, siis andku teada – head ideed pannakse ikka toime. Mis ettekanne järgmiseks minu poolt tuleb, ei ole veel selge. Käimas on jube kiire ja inimvaimu tõsiselt tappev periood, mis loodetavasti peatselt läbi saab. Arvatavasti ma millestki ahjusoojast jälle räägin, sest uut ja huvitavat on viimasel ajal juhtunud palju.

Loe lisaks

Kutse seminarile: ASP.NET MVC 3 areneb ja uueneb

Gunnar — Mon, 16 Aug 2010 21:49:38 +0000

Töine periood surub täiel hool peale ja aeg on otsad lahti teha ka Eneta ettekannetega. Et kuulajaid seni leidub, siis olen teie ees jälle ettekandega 25.08 kell 18:00. Sündmuspaigaks nagu ikka vana hea ITK ja ettekanne kõikidele huvilistele tasuta. Teemaks on seekord ASP.NET MVC 3.

ASP.NET MVC 3 on nii uus, et sellest pole väljas veel betatki. Küll on aga laiale avalikkusele mängida antud esimene Preview, mis sisaldab mitmeid uuendusi, mida kõikide eelduste kohaselt kolmandama versiooni koosseisust välja ei jäeta. Kindlasti võivad need asjad tulevikus muutuda, kuid ära nad vaevalt kaovad. Ettekandes tutvustan uusi asju ja nagu ikka – koodinäidet teen ka. Peale ettekannet vastan küsimustele ja annan nõu, niisama mulisen kah.

Mõned teemad, millest juttu tuleb, on järgmised:

Razor view engine,
uued action result’id,
näited action results’ide kasutamise kohta praktikas,
täiendatud andmevahetus kontrolleri ja vaate vahel,
JSON-formaadis action argument’id.

Lisaks sellele on veel teemasid, mis on juba praegu teada ja kindlasti lisandub ka midagi juurde. Üks huvitav üllatusnäide, mis veebimaailma lähitulevikku osaliselt puudutab, on mul ka ettevalmistatud. Aga seda näete kõik alles kohapeal, seniks las see olla minu väike saladus.

Kõik, kes osaleda soovivad – ükskõik kas kohapeal või interneti vahendusel – saavad ennast kirja panna Eneta portaali lehel Eneta kommuuniõhtu: ASP.NET MVC 3 areneb ja uueneb. Aega on kuni 23.08.

Lõpetan jutu nagu ikka – tule ise ja võta sõber ka kaasa!

Loe lisaks

Miks ei saa Windows Server 2008 peal SharePointi dokumendi teeke Windows Exploreris avada?

Gunnar — Sat, 14 Aug 2010 16:41:56 +0000

Kui arenduseks kasutatava Windows Server 2008 peal ei saa SharePointi dokumendi teeke Windows Exploreris avada, siis tuleb üks pisike restardiga lõppev lisaliigutus teha. Minu lühijuhend on selline.

1. Lase käima Server Manager.
2. Vali Features.
3. Vali Add Feature.
4. Märgi ära Desktop Experience nimeline featuur ja vajuta Next.

Kliki pildil hiirega, et seda originaalsuuruses vaadata.

5. Järgmises aknas vajuta nuppu Install.
6. Kui install on valmis, tee masinale restart.

Peale restarti on võimalik dokumendi teeke brauseri kaudu Windows Exploreris avada.

Loe lisaks

Visual Studio Lightswitch - ärieksperdid astuvad sammu lähemale arendusele

Gunnar — Tue, 10 Aug 2010 22:33:50 +0000

Ajal, mil ma teiste metallinimestega Saksamaal Euroopa suurimal festivalil prassisin, tegi Microsoft jälle ühe üllatuse. Visual Studio 2010 saab omale uue lisandi, millel nimeks Lightswitch. Peale vaadates leiame palju meile tuttavat Microsoft Office rakenduste maailmast ja üks mõtteid, mis mul kord suitsupausi aal peast läbi käis, oli midagi sellist, nagu Lightswitch pakub.

Lightswitchi võtab päris hästi kokku ASP.NET MVP Ken Cox oma blogi kandes Visual Studio Lightswitch - Welcome Advanced Amateurs:

“There are a lot of people in business who are wizards with tools like Excel, even though their primary job isn’t software development. Sometimes their apps become essential to the business process.

Lightswitch, announced at VSLive!, will appeal to advanced amateurs. The nice thing is that professional developers can take the code and scale it out without starting from scratch.”

Ehk siis – tegemist on vahendiga, mille abil saab lihtsa vaevaga luua andmetega seotud vorme nagu näiteks Microsoft Accessis. Kui rakendused muutuvad keerukamaks, siis saavad juba professionaalsed arendajad need üle võtta ja teha asjad selliseks nagu need olema peavad. Vähemasti selline on eesmärk. Vahele üks pilt ka enne kui minu pidustuste järgsete mõtete juurde asume.

Lightswitchi point on lihtne – selle abil saab luua mallide järgi päris palju igasuguseid vorme valmis paari liigutusega ja siduda need andmetega. Rakenduste loomisega saab hakkama tänane korralik Office’i gängster ja kui rakendus on kasvanud keerukamaks või kui see läheb ettevõttes laia kasutusse, siis astuvad mängu ka need liblikate keelt rääkivad progejad, kes teevad nii, et kõik toimima jääks.

Huvitavaks kohaks minu jaoks on hetkel see, et kas ja kuidas saavad sellise vahendiga koos töötada eriala ekspert ja professionaalne arendaja ning kui valutuks või valuliseks antud vahendi abil koostöö kujuneb eeldusel, et ekspert tunneb mingil määral Microsoft Office rakenduste loomist.

Lightswitch rakenduste jooksutamiseks on kaks varianti – töölaud ja veeb. See kõik pannakse paika Lightswitch rakenduse seadete abil. Klõpsa alloleval ekraanpaugul hiirega ja vaata lähemalt.

Kes rohkem pilte ja juttu soovib, siis Jason Zanders blogist leiab huvitava kande pealkirjaga Introducing Microsoft® Visual Studio® LightSwitch™. Sama kande kommentaaridest saame teada, et Lightswitchi esimene beta peaks kättesaadavaks muutuma meile 23.08.

Loe lisaks