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!

Leidsin nauditava ja kergelt loetava lühijuhendi Scrumi kohta. See on kirjutatud Ken Schwaber’i ja Jeff Sutherland’i poolt. Originaalis on see muidugi inglise keeles, aga juba praeguseks hetkeks on seda tõlgitud mitmesse keelde ja mitmesse keelde tõlkimine on pooleli. Ehk võtab keegi kätte ja tõlgib ka eesti keelde ;)

Juhend millest kirjutan asub Scrum.org–s:

• http://www.scrum.org/scrumguides/

Head lugemist!

Juba Visual Studio 2008-st ja TFS 2008-st on koodifaili peale minnes võimalik näha selle koodifaili hetke seisu autoreid koodihalduse muudatuste kaupa. Kuna pilt on väärt 1000 sõna, siis järgnevad illustratsioonid loodetavasti aitavad paremini mõista.

Et saada koodifaili annotatsioon, tuleb teha järgmist:

Ja seejärel tekib teil koodifailile järgnevale sarnane vaade.

Antud vaade näitab, kuidas see koodifail niisugused koodiread omale sai. Kes need kirjutas, millal ning mis koodimuudatustes need kajastuvad. See on vahest päris kasulik vaade, kui soovite teada, miks mingi koodifail on just niisugune nagu ta on ja kes on muudatused teinud.

Nüüd DevDays –i üritusel sain ma valgustatud ühe kuulaja poolt, et annotatsiooni on võimalik koodifaili ajaloost suvalise koodifaili hetke seisu pealt genereerida. Varasemalt olen ma ainult täheldanud, et seda saab hetke (viimase) seisu pealt generereerida. Mingil põhjusel on see mul kahesilma vahele jäänud, aga see on minu meelest nii hea avastus, et tasub jagamist. Võimalik, et paljud teavad seda juba ammusest.

Igatahes, kui te lähete ühe faili koodiajaloo peale, siis sealt on võimalik iga koodifaili muudatuse peal ka “Annotate”  valida ning sel juhul saate te ajaloolise koodifaili seisu pealt samasuguse vaate nagu eespool.

Ehk siis View History faili peal.

Ja seejärel sobiva ajaloos oleva kirje peal Annotate.

Olen sellest võimalusest ise puudust tundnud ja vot, tegelikult on see alati olemas olnud ;)

Edu!

Parajalt krüptiline sai see pealkiri. TFS-s on olemas sündmuste teenused (Event Services), mille abil antakse teada registreeritud osapoolele (subsriber) kui teda huvitavad andmed TFS-s on muudetud. Näietks, kui taski muudetakse, siis antakse saadetakse veebiteenusele sõnum, milles kirjas informatsioon muutuse kohta ja selle najal saab see veebiteenus uuendada selle taski kasutusloo (user story) küljes olevaid andmeid. Oletame, et taskil muudeti tehtud töö või järele jäänud tööaja hinnangut, siis on ju tore, kui kasutusloo juures on summeritud kõikide taskide järele jäänud tööde maht tundides ja see on alati täpne taskide põhjal. Niisugune automaatika väldib tülikat manuaalset tööd ja seda kasutavad mitmeid protsessimallid nagu näiteks Scrum for Team System.

  Nüüd üks jõudlusprobleem, mis oli 2008 versioonis on see, et iga muudatus põhjustab teate saatmise. Kui samaaegselt töötab TFS–i kallal palju inimesi, kes kõik muudavad tööülesandeid, siis võib lõpptulemusena TFS-il olla väga suur koormus ainult nende teadete vastuvõtmise ja haldamisega.

  TFS 2010-s on selle jaoks implementeeritud viide, mis vaikimisi on 2 minutit. See tähendab, et esimesest muudatusest alates oodatakse 2 minutit ja pärast aja mõõdumist võetakse kõik muutused selle hetkeni ning saadetakse teated. See tähendab, et teenusel mis saadab ja mis vastu võtab on palju mõistlikum koormus ja määratud aja jooksul tehtud muudatuste teated kogutakse kokku.

Kuidas seda viite aega muuta?

  Kahjuks ei ole selle viite aja muutmise jaoks ühtegi toredat kasutajaliidest. Küll, aga leidsin ühe lihtsa powershelli skripti, mida teiega jagaks ja mis minul toimis.

   1: [Reflection.Assembly]::Load("Microsoft.TeamFoundation.Client, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")

   2:  

   3: # Modify the TFS configuration server URL as necessary.

   4: $configServer = new-object Microsoft.TeamFoundation.Client.TfsConfigurationServer "http://devtfs:8080/tfs/"

   5:  

   6: # Get the TF registry service.

   7: $tfsRegService = $configServer.GetService([Microsoft.TeamFoundation.Framework.Client.ITeamFoundationRegistry])

   8:  

   9: # Set the notification delay to 10 seconds. All collections will use this delay unless they override this value in the collection hive.

  10: $tfsRegService.SetValue("/Service/Integration/Settings/NotificationJobDelay", 10)

Nüüd panete kindlasti tähele, et seade nimetus on NotificationJobDelay. See seade eksisteerib ja saab seada nii projekti kollektsiooni kui ka serveri konfiguratsiooni tasemel. TFS otsib seda seade väärtust järgnevalt:

1. NotificationJobDelay at the collection-level. (Assuming you're dealing with a collection-level action like a checkin or a work item modification.)
2. NotificationJobDelay at the configuration server-level.
3. DefaultDelayedJobDelay at the collection-level. (Assuming you're dealing with a collection-level action like a checkin or a work item modification.)
4. DefaultDelayedJobDelay at the configuration server-level.
5. Default to 120 seconds.

Nüüd kaks tähtsad biti, enne kui muutma asute:

• Peale antud powershelli käivitamist tuleb teha recycle “Microsoft Team Foundation Server Application Pool” -ile või iisreset või siis piisab ka TFS –i rakenduskihi web.config-i muutmisest. Eks valige ise sobiv.
• Teine tähtis bit on see, et antud viidet ei tasu 0–ks panna, 1 sekund on kasulikum – see on inimesele  märkamatu viide, aga rakenduse mõttes võib see koormust säästa. Eks oleneb massist.

Veidi rohkem infot leiate ka Chris Sidi blogist, kust ka antud powershelli skript pärit on.

Soovin jagda kahte vinget täiendust TFS –i tavavahenditele.

TFS Workflow Control

TFS Web Access saidis on igal tegevusel/tööl ajaloo vaates võimalik näha graafilist esitlust staatuse muutumise kohta – millal see juhtus, kelle pool, miks ja mis staatuseks. Järgnev pilt illustreerib seda.

Üks puudusi Visual Studio Team Exploreris on see, et sarnast vaadet/esitlust seal ei ole.

Nüüd üks nutikas tüüp Michel Perfetti on teinud täienduse nii Team Explorerile kui ka Web Accessile, mis toob sarnase vaate mõlemasse vahendisse mõndade äggedate nüansidega. Workflow vaadet on võimalik grupeerida erinevaid parameetreid kasutades nagu distsipliin või iteratsioon. Graafiliselt on ka muidugi vahvam. Ta on täienduse pannud tööle nii TFS 2008 –ga kui ka TFS 2010 RC –ga (hetke versioon). Eks RTM on ukse taga.

• Rohkem infot ja kontrollid @ http://tfsworkflowcontrol.codeplex.com/
• TFS 2010 RC versioon kontrollidest

TFS Workitem Visualization

Antud vahend võimaldab kenasti pärida ja visualiseerida informatsiooni seotud workitem’itega linkide, changeset –ide jm info põhjal. Vahend oskab analüüsida sõltuvusi workitemite jm vahel, millele workitem linki omab.

Use DGML to visualize and analyze your TFS Work Items. Included is the ability to perform basic risk/impact analysis. It helps answer the question, "if I change this requirement, what is my potential impact to other requirements?"

Visualiseerimiseks kasutab VS2010 sõltuvuste esitamise diagramme.

Näiteks – ma saan võtta kasutuslood ja seotud taskid ning koodi muudatused ning visualiseerida need ja ka minna vaatama, mis muudeti igas changesetis.

Või huvitab mind hoopis seosed kasutuslugude, vastuvõtu testide, bugide ja testi jooksutuste seosed.

Punased on Bugid, mis on loodud testilugude juurde teste manuaalselt läbi käies.

Kollane on kasutuslugu. Hall on testilugu. Helesinine on manuaalne testi jooksutus.

Täitsa kasulik visualiseerimine ja põnevusega ootan, kuhu see vahend edasi liigub.

• Vahendi kodu @ http://visualization.codeplex.com/
• Dokumentatsioon
• Sõltuvuste visualiseerimie näide

Head uurimist ja kasutamist!

Soovin jagda kahte huvitavat leidu, mida ise veel pole jõudnud veel katsetada, aga plaanin mängida esimesel võimalusel. Millegi pärast ei lühene TODO nimekiri tänapäeval enam märkimisväärselt – võtad midagi ära ja paned aga miskit uut asemele. Ma kuulsin nendest leidudest eelmisel nädalal toimunud MVP Summitil USA-s, kui MVP –d jagasid teiste arendajatest MVP –dega oma kogemusi ja leide (see info oli üks väheseid mitte NDA all olevaid).

Esimene nendest on ASP.NET MVC Turbine.

Minu arusaamist mõõda lihtsustab see ASP.NET MVC projekti loomist, milles on by default olemas IoC container, võimalik kasutada mitmeid erinevaid view mootoreid ja mugav ModelBinderite injectimine. By Default on võimalik mugavalt hallata oma rakenduse voogu (control application flow). Installeriga on kaasas mitmed Visual Studio projekti tüübid, mis aitavad siis ASP.NET MVC Turbine projekti luua. Kasutab palju ära MvcContrib projekte/komponente.

Rohkem infot leiate järgnevatelt linkidelt:

• http://mvcturbine.codeplex.com/
• http://turbineproject.com/
• http://lozanotek.com/blog/archive/2009/12/01/MVC_Turbine_v2.0_RTM.aspx
• http://mvcturbine.codeplex.com/releases/view/36541 (projektiga on kaasas kaks näidisprojekti – Okonau ja NerdDinner.NET, mis on üle viidud Turbine peale).

Teine huvitav leid on ASP.NET WebForms MVP projekt, mis pakub Model-View-Presenter mustrit kasutavat raamistiku ASP.NET WebForms peal. Projekt on hetkel küll CTP, aga juba reaalselt kasutuses mitmes projektis Austraalias (sealhulgas teenindamas saiti millel mitu miljonit vaatamist kuus). Ma olen ise suur fänn MVP mustrile ASP.NET WebForms projektides, üks väheseid meetodeid teha oma webforms rakendus testitavaks ja samas siiski saada ära kasutada olemasolevat kontrollide pagasit ASP.NET –s. Projekt on plaanitud jõudma v1.0 –i MIX10 ajaks (15-17 märts - http://live.visitmix.com/)

Rohkem infot leiate järgnevatelt linkidelt:

• http://webformsmvp.codeplex.com/
• http://webformsmvp.com/
• http://blog.tatham.oddie.com.au/

Siia juurde väike huvitav diskussioon austraaliast:

• video-asp-net-mvc-vs-asp-net-webforms-will-webforms-be-replaced-by-mvc/