Ma olen viimasel ajal mõtisklenud, et millal on kasulik kasutada var võtmesõna C# –i koodis ja millal see võib hoopiski segadust tekitada koodi lugejas. Minu mõtted ei pruugi olla mitte kuidagi originaalsed siin, kuigi ma loodan, et natukenegi on. Ei ole hetkel kuskilt juhendeid selle jaoks lugenud.

Praktikas olen ma jõudnud järgnevatele lähenemistele:

• Kasuta var –i juhul kui lood mõnda kompleks objekti nagu FileInfo, SqlConnection, DateTime …

Näide:

   1: var stopper = new Stopwatch();

Koodirida on loetav ja mõnusam muuta. Teistpidi oleks täitsa tüütu.

• Ära kasuta var –i lihttüüpide puhul nagu int, string, double, …
• Ära kasuta var-i objekti omaduse või meetodi kutsumisel tagastustüübi defineerimisel, kui tegu on lihttüübiga

Näide:

   1: var sourceLocation = ConfigurationManager.AppSettings["SourceLocation"];

   2: var targetLocation = ConfigurationManager.AppSettings["TargetLocation"];

   3: var sizeCounterInMB = 0.0000;

   4: var allFiles = Directory.GetFiles(sourceLocation, "*.*", SearchOption.AllDirectories);

   5: var file = allFiles[0];

   6: var targetFullPath = file.Replace(sourceLocation, targetLocation);

   7: var fileInfo = new FileInfo(targetFullPath);

   8: var directory = fileInfo.DirectoryName; 

Kas sa tõesti saad aru lihtsalt peale vaadates, mis tüüpi asi sulle tagasi antakse? Oletame et sa ei tea ConfigurationManager.AppSetting indexerist midagi või teistest objektidest ning nende omadustest.

Palju paremini loetav on sama kood järgneval kujul:

   1: string sourceLocation = ConfigurationManager.AppSettings["SourceLocation"];

   2: string targetLocation = ConfigurationManager.AppSettings["TargetLocation"];

   3: double sizeCounterInMB = 0.0000;

   4: string[] allFiles = Directory.GetFiles(sourceLocation, "*.*", SearchOption.AllDirectories);

   5: string file = allFiles[0];

   6: string targetFullPath = file.Replace(sourceLocation, targetLocation);

   7: var fileInfo = new FileInfo(targetFullPath);

   8: string directory = fileInfo.DirectoryName; 

Ka koodi kirjutamisel saab peale vaadates paremini aru mis olevusega tegu on ning on lihtsam manipuleerida.

Ma hetkel mõtisklen, kas keerukamate objektide puhul on kasulikum tagastustüübi defineerimisel kasutada var–i või mitte. Mugavam kindlasti, aga loetavam?

Mis te arvate ja missuguseid reegleid kasutate var-i juures?

Oma igapäevatöös olen harjunud kasutama kahte ekraani ja ma usun, et see on tavapärane lähenemine arendajate juures. Praegusel ajal võib siht olla juba 3 ekraani suunas. Arendades on vaja Visual Studiot (koodi) näha ühelt ekraanilt, browserit teiselt ekraanilt.  Võibolla isegi jagada hoopis Visual Studio kahe monitori peale ja siis oleks vaja kolmandat monitori browseri jaoks, et saaks otsida, vaadata ja lugeda samaaegselt ning kasutada ära infot koodi kirjutamise juures. See kõik tõstab produktiivsust – sest ei pea akente vahel pendeldama koguaeg.

Teine asi, mida ma oma igapäevatöös kasutan juba aastaid on virtualiseerimine – mul on olemas host masin, kus pole peale meilikliendi, browseri ja Office’i eriti midagi. Ning siis on mul 1..n virtuaalset masinat, millest vähemalt üks on arendamiseks mõeldud. Nüüd siit tulebki probleem – ma soovin kasutada ja ühenduda oma virtuaaalse arendusmasina külge ja samal ajal kasutada mitut ekraani selles remote desktopi sessioonis.

Ma olen pikka aega kasutanud ühte ekraani arendamisel üle remote desktopi, kuna olen laisk olnud, pole mahti olnud või pole piisavat motivatsiooni olnud seda probleemi lahendada. Igatahes, täna hommikul sai mõõt täis ja otsustasin probleemi ära lahendada. Järgnevalt kirjeldakski tulemust, milleni jõudsin.

Lahendus

Lahendus koosneb kahest osast. Esimene nendest on see, et alates Remote Desktop v6.0 on võimalik remote desktopi rakendust span’ida üle mitme ekraani. Seda saab teha käivitades käsurealt remote desktopi järgnevalt:

mstsc /span

Mida see siis õigupoolest teeb? Ütleb remote desktopile, et paigutu üle virtuaalse desktopi, mis võib koosneda mitmest monitorist. Väike lõik mstsc helpist:

Kõik on tore ja ilus kasutades /span –i laiendit, ainult et niimoodi jagatud virtuaalset desktopi kasutades panete te tähele koheselt erinevaid ebameeldivusi. Nagu näiteks see, et sisse logimine on läinud kahe ekraani keskele ja asub poolenisti mõlemal, igakord kui avate akna siis see avaneb poolenisti ühel monitoril ja teisel monitoril, igakord kui teete maximize, siis toimub see üle kogu virtuaalse desktopi, taskbar on üle kogu virtuaalse desktopi jne.

Ma olen suht kindel, et need pisiasjad muutuvad häirivaks ja nad ei anna tulle tunnet, et sul on tegu mitme monitoriga, vaid ühega desktopiga üle kahe.

Mängu tuleb lisavidin nimega SplitView!

SplitView on niisugune lahe vidin, mis jookseb teie virtuaalses masinas, mida soovite mitme monitoriga kasutada ja ta lahendan kõik ees pool välja toodud probleemid ja ebameeldivused. Ta tekitab teile tunde, nagu te ei remote’ks vaid teil ongi mitu monitori ja kõik toimib täpselt nii nagu te olete harjunud. Taskbar pole enam üle terve virtuaalse desktopi, maximize toimib ühe monitori sees, asjad avanevad ühe monitori sees, mitte üle virtuaalse desktopi jne.

Elu on ilus ja virtuaalse masina ja mitme monitori kasutamine ei ole omavahel enam konfliktis või tekita ebameeldivust.

SplitView ei ole tasuta vidin! Sellest veidi lähemalt varsti.

Lisainfo SplitView kohta:

• Admin Guide
• Download
• Multiple monitors with remote desktop and splitview

Kõik on tore ja see on minu poolt hetkel katsetatav lahendus. (mstsc /span + SplitView)

Ma oleksin väga huvitatud lugejate kogemustest sama probleemi lahendamisel või kogemustest SplitView –ga?

SplitView litsentseerimist vaadates tekib mul mitmeid küsimärke. See mitte kuidagi ei soodusta arenduse seisukohast vahendi kasutamist. Nimelt on vaja Remote Desktopi puhul “Terminal Services Edition” litsentsi, ja see maksab kas 729$ per server või siis 59$ per concurrent user ainult, et miinimum 20 kasutaja litsentsi? 20 –nd litsentsi pole mul küll nüüd vaja ja 729$ on liiga krõbe.

On kellelgi reaalset kogemust SplitView tootjate ja selle vahendi litsentseerimisega?

Tööjuures saab parajalt XML-i ja XPath’iga tegevusi tehtud ning siiamaani oleme XPath’i päringute testimiseks kasutanud XmlSpy’d. Nüüd mõned päevad tagasi mõtlesime, et palju toredam oleks kõikke XML-i ja XPath’iga seoses teha ühest vahendist, nii et ei peaks lahkuma Visual Studiost. Lisaks on ilma konfigureerimata kahe erineva XML-i töövahendi kasutamisega faili formaatimisel erinevustega parajalt jurasid.

Seega avasin oma VS2010-s Extension Manager’i (paremal) ning otsisin vastavat vahendit Visual Studio Galleryst ja leidsingi - TTXPathNavigatorVSIX. Täpselt see mis vaja, integreeritud vahend VS2010-ga ning võimaldab testida XML-i andmete peal XPath’i väljendeid.

Muidugi pakub XmlSpy palju rohkemat, kui XML-i kirjutamine ja XPath’i väljendite testimine, aga meie kontekstis on see üks peamisi tegevusi ja tundub, et nüüdsest saame ainult Visual Studio’ga hakkama (Visual Studio võimaldab nii schema abil kirjutamist, valideerimist, XML-i kirjutamist + snipeteid, intellisensi, XSLT debuggimist – ja nüüd ka XPath’i testimist).

Kui teil Extension Manager ei meeldi või kasutate varasemat versiooni Visual Studiost, siis saate otsimiseks kasutada Visual Studio Gallery lehekülge.  Kusjuures VS2008 –le on sama vahend ka olemas ;)

See pole teabmis kaunis vahend, aga täitsa produktiivne. Kirjutad aga otsingu teekonna ja tulemused käid läbi F8 ning Shift+F8 (tagurpidi).

Edu!

Väga huvitav uudis VS-i meeskonna poolt. Nimelt on beta versioonina kättesaadav Team Foundation Server Scrum v1.0 protsessimall, mis on Microsofti poolt toetatud ja välja töötatud ning täies mahus Scrumile vastav.

Protsessimall sisaldab endas termineid (ja Workitem’eid) nagu Sprint, Product Backlog Item,  Bug, Impediment. Huvitaval kombel on Sprint Backlog Item (või SPI) asemel Task, aga samas on Task hea lühikene nimetus ning kergemini hoomatav (kõik savad aru, mis see on). Puudu on ka sprint retrospective, samas ma pole kindel, kas see peaks kajastuma üldse TFS-s. Oma meeskonnas ma küll kirjutan selle alati TFS-i ja 3 kuud hiljem (mingi aja mõõdudes) on hea tagasi vaadata ning võrrelda uue retrospectiviga. Kas elu on parem ja kus me olime 3 kuud tagasi.

Miks niisugune areng, kui on olemas mitmeid Scrumi protsessimalle TFS-ile? Tuleb välja, et hoolimata hetke valikust on paljud just seda Microsofti käest küsinud. Ma arvan, et see on igate pidi positiivne areng ning veel üks protsessimalli valik, mida korralikult arendatakse ei ole paha. Valik on hea.

Värsket protsessimalli ei ole ma veel proovinud, aga varsti katsetan ära.

Hea lühiülevaade on Aaron Bjorki blogis.

Uue protsessimalli leiate aga Visual Studio Gallery lehelt.

Kohe kohe on RTM olekusse jõudmas uus Visual Studio 2010 toodete perekond ja selle tähistamiseks Eestis on Microsoft organiseerinud arendajatele ürituse nimega DevDays 2010, mis toimub nii Tallinnas kui ka Tartus. See üritus on mõeldud kõigile .NET-s arendajatele (või huvitatutele!) ja sisaldab järgmisi ettekandeid nii Eesti kui ka välismaa esinejate poolt:

• What’s new in Visual Studio 2010 (Luka Debeljak)
• ASP.NET 4.0 – veebiarendus täiskäigul (Gunnar Peipman)
• Distributed data apps with .NET & SQL Server 2008 (Zlatko Knežević)
• TFS 2010 – rusikas silmaauku igas mõõdus arendustiimile (Taavi Kõosaar)
• Developing with Internet Explorer, now and future (Zlatko Knežević)
• What’s new in Cloud Services (Luka Debeljak)

Üritus on tasuta! Üritus leiab aset 21.04.2010 Tartus ja 22.04.2010 Tallinnas ning saab registreerida Eneta veebilehel kasutades järgmisi linke:

• DevDays 2010 – Tartu
• DevDays 2010 – Tallinn

Pärast ettekandeid saab kätt proovida XBOX 360 konsoolidel või lobiseda tuttavate/sõpradega.

Kõikkide eelduste kohaselt olen mina mõlemal päeval olemas ja heameelega lobisen VS2010 ning TFS 2010 teemadel.

Näeme seal!

Selle nädala kolmapäeval on ENETA–l kavas järgmine kommuuniõhtu, mille teemaks on Testipõhine arendus .NET–s ja lektoriks Mart Karu. Mart Karu tunnen ma isiklikult, sai mõnda aega koos tehtud arendust Justiitsministeeriumis ja RIK-is (Registrite ja Infosüsteemide Keskus). Tema oli esimene, kes mulle unit testide pisiku ja testil põhineva arendamise konseptsioone tutvustas ja seda aasta 2004 lõpus, ta ise oli sellega tegelenud juba varem. Ma tean, et ta on tugev TDD ja unit testide pooldaja ning oma projektides kasutab ta igapäevaselt neid, kuigi viimased aastad võibolla rohkem ruby kontekstis. Igatahes on tal pikaajaline ja reaalne kogemus, mille najal on kindlasti põnev ja kasulik kuulata, kuidas ja mis vahenditega testipõhist arendamist on võimalik teha .NET –s.

Ma ise loodan, et ta tutvustav konseptsioone, vahendeid ja näitab nende kasutust kohapeal. .NET –s on olemas väga suur hulk erinevaid vahendeid testipõhise arendamise ja unit testide toetamsieks – õige valiku näitamine saab olema paras väljakutse.

Kommuuniõhtu kohta leiad rohkemat infot järgnevatest allikatest:

• Sündmuse info ja registreerimine @ Eneta.ee
• Arutelu Eneta foorumis

Ma ise kavatsen osaleda Live Meetingu vahendusel, kuna viibin Rootsis sel nädalal.

Mart Karule soovin edu selle esitlusega!

Kindlasti saab vahva olema!

.NET –i ja C# maailmas on kaks arendamisreeglite kogu, mida võetakse kui de facto standardina aluseks oma arendamisreeglite ja kokkulepete dokumendi/kogumiku loomisel.

Üheks neist on Microsofti poolt uuendatav “Design Guidelines for developing class libraries”.

Teiseks on vast kujunenud IDesign’i “The IDesign C# Coding Standard for development guidelines and best practices”.

Vaieldamatult põhjalikumad raamatud antud teemadel on “Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries” v1 ja v2. Ise olen läbi lugenud v1 ja see oli vägagi õpetlik ja nauditav. Põhimõtteid, mida sealt lugesin rakendan ma oma igapäeva arenduses siiamaani ja nad toimivad (on muutnud koodi paremini hallatavaks, organiseeritumaks ning ühtlasemaks).

• Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries v1
• Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries v2

SQL –i maailmas olen ma leidnud ka mõned viited, mis võivad kandideerida alusena:

• Best Practices , Design and Development guidelines for Microsoft SQL Server

Muide http://code.msdn.microsoft.com –s olev SQL Examples on üldse väga nutikas ja põnev koht kasulike näidetega.

Võibolla teate mõnda paremat .NET –i, C# –i või SQL maailmas? Palun jagage kommentaarina siia postituse juurde.