Vítejte na blog.vyvojar.cz Přihlásit | Registrovat | Pomoc

Po dlouhé době opět oživuji svůj blog, laskavý čtenář promine, že s poněkud sebepropagujicim sdělením. V druhé polovině října budu organizovat zmíněný mini-kurz sestávající ze 3 hodinových lekcí. Rád bych v něm shrnul vše, co jsem se dozvěděl v mnoha desítkách firem, jež jsem za poslední roky pracovně navštívil. Je zajímavé, jak se kultura vývoje v různých IT firmách liší, a to zcela nezávisle na velikosti firmy. Ve zmíněném kurzu se pokusím do nějakého společného průniku shrnout věci, o kterých jsem přesvědčený, že ve většině případů fungují.

Více informací o kurzu a odkaz na registraci najdete v oficiální pozvánce.

Michael

Během ledna budu pořádat sérii LiveMeetingů na téma uvedené v titulku. Už se těším, LiveMeeting akce jsou pro přednášejícího vždycky adrenalin a navíc testování (zejména automatické testování ve virtuálních prostředích) je pro mne do určité míry srdeční záležitost.

Tento web čte jistě řada lidí, které tato problematika zajímá, případně na ni prosím upozorněte své kolegy, které by zajímala. I když budu samozřejmě používat při ukázkách Microsoft nástroje, drtivá většina jich funguje velmi dobře i na testování aplikací napsaných na jiných platformách – pokud nevyvíjíte pro .NET framework, nemějte obavy, bude to zajímavé i pro vás.

Jedná se celkem o 5 přednášek s tématy:

  • Plánování, řízení a provádění funkčních testů aplikací
  • Automatizované funkční testování aplikací
  • Testování ve virtuálních prostředích
  • Zátěžové a výkonnostní testování a jejich vyhodnocení
  • Prostředky pro prevenci problémů v aplikacích

Samozřejmě vše je zdarma a účastníci 4 z 5 setkání dostanou dokonce knihu. V

Více informací a registrace jsou zde.

Každý chce neustále vědět, jaké změny musí v aplikaci učinit, aby běžela v cloudu, v tomto případě na Windows Azure. Jsou ale věci, které vám žádný návod neřekne, a musíte si je protrpět sami, stejně jako jeden z našich partnerů, který níže popsané zaznamenal.

Měl aplikaci, která musela přestat sbírat data v přesně stanovený čas, řekněme něco jako aukce. Ale nepřestala. Sbírala dál, a to ještě 2 hodiny poté. Důvod je celkem triviální, naprosto logický, ale snadno přehlédnutelný. Všechny aplikace, které dosud psali měli server i klienty ve stejné časové zóně (aniž by o tom někdo takto přemýšlel). Pokud si dáte na svém počítači DateTime.Now a DateTime.UtcNow, budou se o 1-2 hodiny lišit podle letního či zimního času. Ve Windows Azure ale běží všechny servery v UTC čase, takže tento rozdíl je na serveru vždy 0, ne však na klientovi. Čas na klientovi z ČR je tedy o 1-2 hodiny jiný než čas na serveru.

Dá se z toho vybruslit různými způsoby:

  1. nejčistší, ale ne moc komfortní je u všech časových údajů zároveň uvádět i časové pásmo, pro které údaj platí, neboť čas na hodinkách sám o sobě je nedostatečný údaj pro určení astronomického času.
  2. pokud víme, že na server přistupují klienti z jediného časového pásma, je možné to řešit konfigurovatelnou korekcí času (jenom pozor, že v létě je jiná než v zimě)
  3. je možné se pokusit o auto-detekci zóny např. tím, že JavaScript na klientovi zjistí aktuální čas a pošle ho v nějakém skrytém poli na server

Všechny 3 možnosti je možné považovat jako zbytečnou otravu. Na druhou stranu kouzlení s časovými zónami je denní chleba všech našich amerických kolegů, o ruských nemluvě. Globální datová centra do tohoto problému chtě nechtě zatáhnou i nás z našeho malého IT rybníčku.

Před odjezdem na dovolenou jsem ještě stihl připravit veřejné zdrojové kódy pro MSTV.CZ – je totiž nutné odstranit vazby na interní systémy, aby aplikace fungovala. Aktuální verze používá všechny možné technologické vychytávky z .NET frameworku 4 (např. stránkování dat na straně serveru ve WCF Data Services) a Silverlightu 4 (např. běh mimo prohlížeč). Zároveň jsem ještě vytvořil dva klony:

  • On Premise – tuto verzi je možné spustit na lokálním vývojářském webovém serveru nebo IIS proti lokální SQL databázi
  • Cloud – tato verze běží na Windows Azure proti SQL Azure (anebo na lokálním emulátoru Windows Azure proti lokální SQL databázi)

Zdrojové kódy si můžete stáhnout na www.mstv.cz kliknutím na ikonku vpravo nahoře. Relativně podrobný návod k rozchození je přiložen. Kódy nejsou chráněny žádnými právy a můžete je libovolně využít pro svoji potřebu – studovat, modifikovat, sami provozovat apod.

Začnu trochu zeširoka. Mobil používám odhadem 12 let. Pokud hodně uberu, tak mi upadne 1x za čtvrt roku. To je zhruba 48 pádů – a nic. No a pak přijde pád číslo 49 a dopadne to takhle:

clip_image001

Pokud chcete mít na mobilu stejný skin, postup instalace je následující: Zajeďte na benzínku, kde mají dlažbu na podlaze (prakticky každá). Natankujte plnou nádrž. Při placení položte mobil na pult. Vezměte kartu CCS a přiložte ji k mobilu. Společně zasouvejte do přední kapsy jeansu a upusťte na zem. Hodně štěstí s Vaším novým skinem.

Michael

P.S. Střepy jsou dost ostré.

P.S.2. Z mobilu nevypadla baterie a zůstal normálně funkční. Jenom dotykový displej sice displejoval, ale nedotykoval.

Na naší televizi http://www.mstv.cz jsem zveřejnil 3 screencasty věnující se novinkám v práci s pracovními položkami. Počet jejich shlédnutí svědčí o tom, že jsem si vybral pro vývojáře zcela otravné téma :-) To ovšem nic nemění na věci, že se jedná o vysoce důležitou součást vývoje v týmu. V nové verzi je možné vytvářet hierarchie pracovních položek (úloha, podúloha, podpodúloha apod.). Též je možné vytvářet pojmenované typové vazby mezi položkami s vlastní logikou (např. co závisí na čem, kruhové závislosti nejsou povoleny). Obě tyto možnosti pak umožňují plnou synchronizaci s Projectem a řadu dalších zajímavých scénářů. Pracovní položky je možné analyzovat pomocí automaticky generovaných Excelových analýz  a k dispozici jsou též nové plánovací sešity pro rozdělování práce mezi iterace a mezi lidi v rámci jedné iterace.

VSTS 2010 - hierarchie v pracovních položkách
http://www.mstv.cz/vyvojari/videos/206/VSTS-2010---hierarchie-v-pracovnich-polozkach

VSTS 2010 - vazby mezi pracovními položkami
http://www.mstv.cz/vyvojari/videos/207/VSTS-2010---vazby-mezi-pracovnimi-polozkami

VSTS 2010 - analýza a plánování pracovních položek
http://www.mstv.cz/vyvojari/videos/212/VSTS-2010---analyza-a-planovani-pracovnich-polozek

2. června 2009 se v Praze uskuteční konference s krkolomným názvem Software Architect & Developer Forum. Více informací zde.

Věnovaná bude novinkám a vylepšením v pokrytí životního cyklu aplikací, které přinese příští verze Visual Studia. Vzhledem k tomu, že zhruba 3/4 obsahu padá na mou hlavu, dovoluji si vás všechny touto formou pozvat. Pro mne to bude zcela jistě adrenalin, protože plánuji vše demonstrovat na Beta verzi, která ještě není k dispozici - a do konference už jsou jenom 3 týdny.

Některá lákadla na navnadění (pouze namátkou, seznam zdaleka není úplný):

  • Historické ladění - možnost podívat se na zásobník a stav programu v minulosti, neboli "Dr. Watson pro .NET framework"
  • Revoluční vylepšení v pracovních položkách anebo "co tam mělo být už od začátku, protože to každý chtěl"
  • Gated check-in - anebo není možné rozbít týmový build, špatné změny jsou vráceny zpátky autorovi
  • Manuální testování aplikací - s videozáznamem průběhu a možností opakovaného spuštění automaticky nahraných kroků
  • Příprava virtualizovaného testovacího prostředí jako součást buildu
  • Sdílení virtuálů mezi vývojáři a testery (snapshot v okamžiku chyby)
  • Robotické testování uživatelského rozhraní

a mnoho dalších. Srdečně vás zvu.

 

Visual Studio 2010, jehož Beta verze se již brzy objeví, nabízí některá zajímavá vylepšení v oblasti verzování zdrojového kódu. Povětšinou nejde o změny v možnostech TFS, ale o přepracované anebo zcela nové uživatelské rozhraní. Novinky jsem zaznamenal v podobě 3 screencastů:

Při vývoji aplikací a vychytávání chyb může problém přijít ze zcela nečekané strany. V komentáři jsem dostal hlášení, že www.mstv.cz nefunguje ve Firefoxu. Ne že bychom naši aplikaci příliš podrobně testovali, ale přece jenom, základní funkce jsme zkoušeli i na jiných prohlížečích než je IE a vše se zdálo v pořádku. Jako první jsem se pokusil porovnat svoje funkční prostředí s tím nefunkčním, ale nebyl patrný žádný rozdíl.

Poté se ale ukázalo, že v nouzovém režimu Firefoxu vše funguje a odtud byl už jenom krůček k zjištění, že vše způsobuje doplněk AdBlock (tímto díky Kamilu Zmeškalovi za reportování chyby a perfektní diagnostiku problému). Zatímco webové stránce chybějící banner celkem nevadí, nebohá RIA aplikace si řekne o data pomocí “podezřelého URL” – něco jako http://jmeno.webu/services/dataservice.svc/banners(1) a díky slovu banner v URL dostane zpátky “kulový”.

Oprava specifickou try-catch konstrukcí namísto globálního odchycení chyby (se zalogováním chyby a restartem aplikace) je triviální. Přesto ale zůstává pachuť v ústech “co mi to s tou aplikací provedli”.

P.S. Radikální řešení s přejmenováním části URL z Banners na BannXXXXers jsem z etických důvodů zamítnul :-)

Normálně píšu na svém blogu česky, ale tentokrát to může být zajímavé i pro ostatní, proto přepínám do angličtiny... switching to English...

Recently, I have prepared three TFS checkin policies for a customer. They hope they will find them useful so I hope you might find them useful as well. Source code is included as an attachment at the end, there are no licensing or copyright restrictions – use at your will. Enjoy!

Michael

Same Branch Policy

Same Branch Policy prevents users from accidentally checking in into more than one branch with a single changeset. This is usually an unintentional mistake  – vast majority of changesets should contain files that all belong to the same branch. This mistake creates confusion and costs extra work to rollback and correct when it happens. Originally, I thought about automatic evaluation from the tree of branch relations but customer was afraid that this won’t work correctly for all variations of branching schemes, so branch definitions are created manually:

clip_image002

When this policy is not satisfied, user is defined in a standard and understandable way:

clip_image004

Path Validation Policy

This policy is an expanded version of Forbidden Patterns Policy from TFS Power Tools. It checks for patterns in file paths and offers an extra level of comfort and flexibility such as:

  • More comfortable rule definition – for many cases, StartsWith and EndsWith are more handy than regular expressions.
  • Customizable error message for each rule
  • Ability to prompt the user without actually violating the policy
  • More readable policy violation messages

See screenshots below:

clip_image006

clip_image008

clip_image010

Import Project Policy

Customer wants all the projects in a solution to import some standard settings, such as Code Signing, via <Import Project=”…”/> in MSBuild files. This policy checks whether projects in  a solution import required settings and if this <Import> is the last subelement in a file (and thus cannot be easily overridden):

clip_image012

clip_image014

Po několikatýdenním trápení se mi podařilo dotlačit k Beta verzi náš nový projekt masivně využívající Silverlight 2.0 - Microsoft TV. Přináší krátká vzdělávací videa pro vývojáře na různá témata.  Televizi najdete na http://www.mstv.cz, oficiální oznámení najdete na blogu českého DPE (http://blogs.msdn.com/vyvojari/archive/2009/02/23/microsoft-tv-startuje.aspx).

Pro začátek na něm najdete nějaká začátečnická videa od kolegy Štěpána (http://www.mstv.cz/vyvojari/authors/stepanb) a nějaké moje tipy a triky pro TFS (http://www.mstv.cz/vyvojari/authors/mjurek). Doufáme, že počet dostupných videí bude rychle vzrůstat, za kterýmžto účelem hledáme dobrovolníky, kteří by se chtěli také zviditelnit a přispívat.

 Jako formu sledování doporučujeme předplatit si RSS feed, který na stránce najdete.

Jakékoliv náměty a připomínky vítány !!!

Vyvíjel jsem nějakou demo aplikaci (na Surface, ale to není až tak důležité). Při tom jsem si ověřil, že ani přibývající množství šedin neochrání člověka před tím, aby v kódu dělal triviální chyby, které ho nutí si tyto šediny vzteky rvát. Posuďte sami.

Potřeboval jsem dynamicky měnit obrázek v UI, přičemž jsem předem neznal jeho rozlišení ani stranový poměr. Byl umístěn v kontejneru s pevnou výškou a šířkou (z určitého, pro ilustraci nepodstatného důvodu jsem nemohl použít dynamičtější kontejner). Mým cílem bylo změnit velikost kontejneru tak, aby poměr stran odpovídal poměru u vloženého obrázku. Napsal jsem tedy zhruba následující kód:

ScatterViewItem container = (ScatterViewItem) this.Parent;
container.Width = this.Photo.Source.Width / this.Photo.Source.Height * container.Height;

Vše fungovalo perfektně. O místo vedle jsem měl stejný problém s vloženým videem. Copy/Paste a malá úprava mne přivedly k tomuto kódu:

ScatterViewItem container = (ScatterViewItem) this.Parent;
container.Width = this.Movie.NaturalVideoWidth / this.Movie.NaturalVideoHeight * container.Height;

Tento ovšem naprosto nefungoval. Kdo první uhádne proč? Nehledejte v tom nic tajemného, je to opravdu chyba na úrovni prvního ročníku programování na gymnáziu, jenom není na první pohled příliš vidět.

 

Nedávno se na blozích objevily úžasné reference na imitace uživatelského rozhraní Outlooku ve WPF (pozor, není to funkční Outlook, jenom vzhled). Ke stažení byl kompletní kód a navíc i řada cvičení, ve kterých jste si toto rozhraní mohli sami udělat a ledacos se přitom přiučit. Poté však přestal fungovat původní link, čímž plně odhalil slabost dnešních vyhledáváčů - tento skvělý zdroj dnes prakticky nejde najít, neboť všechny nalezené odkazy používají starý špatný link.

Naštěstí se mi podařilo sehnat původního autora a ten mi dal nový, vyhledávači téměř nedohladatelný odkaz - http://www.microsoft.com/switzerland/msdn/de/presentationfinder/detail.mspx?id=104056

Pro nalákání ještě jeden screenshot:

WPFOutlook

Poslední edice TFS Power Tools byla vydána 7.listopadu, ale nese název "October 2008". Podobnost s VŘSR je zarážející, ale doufám, že čistě náhodná. Jedná se přitom o edici, která přináší nejvíce nových užitečných funkcí od začátku vydávání Power Tools, které slouží jako určitý druh inkubátoru pro funkčnost, která se často objeví v dalších verzích. Konkrétněji:

  • Integrace do shellu Windows - častý požadavek uživatelů. Operace se zdrojovým kódem (check-in, check-out atd.) je možné dělat bez spuštěného Team Exploreru. Podobně jako jsou uživatelé Subversion zvyklí v TortoiseSVN.
  • Team Members - celkem pěkný doplněk do Team Exploreru umožňuje komunikovat se členy týmu (IM, email) a zjišťovat základní informace o nich - zobrazovat si jejich shelvesety, changesety, pending changes, úlohy, přiřazené bugy apod.
  • Powershell - dříve se pro automatizaci operací se zdrojovým kódem dal použít tf.exe z příkazové řádky. Nyní jsou k dispozici též cmdlety pro Powershell, což je mnohem komfortnější

Bližší informace na blogu Briana Harryho:

Nedávno jsem dělal drobnou aplikaci v Silverlight a na docela dlouho jsem se "zasekl", což je situace, kterou každý vývojář zná více než dobře. Když jsem potom zpětně přemýšlel, proč jsem na to šel tak hloupě, uvědomil jsem si, že jsem se nechal vést celkem iracionální intuicí. Podvědomě jsem si totiž spojil dvě věci, které jdou zpravidla ruku v ruce, ale jsou ze své podstaty zcela nezávislé - a to asynchronní spuštění nějaké akce (konkrétně dokončení asynchronního volání webové služby v okamžik, který nemá uživatel pod kontrolou) a spuštění na pozadí (přesněji spuštění na jiném threadu než na tom, který obsluhuje uživatelské rozhraní). Ve standardním .NET frameworku (WinForms, WPF aplikace apod.) s touto chybnou úvahou nenarazíte, ale v Silverlightu ano...

Neviděl jsem to sice napsané černé na bílém, ale všechny moje experimenty ukazují, že ... v Silverlight aplikaci je běhovým prostředím vytvořen jeden jediný thread pro každý Silverlight <object> vložený v prohlížeči, který se stará o všechno - animace, uživatelské akce (stisknutí tlačítka), asynchronní spuštění dokončovacích akcí a dalších úkonů seřazených v nějaké interní frontě. Jakýkoliv další thready si musíte explicitně sami vytvořit. Napadly mne celkem tři důvody proč tomu tak je:

  • První - ohleduplnost vůči prohlížeči. Silverlight plugin běží v aplikaci prohlížeče (na rozdíl od klasické aplikace, která má svůj vlastní proces) a je tedy na místě být vůči hostujícímu procesu ohleduplný. Čím méně threadů, tím méně CPU času hostujícího procesu si můžu přivlastnit, a tím menší šance, že mu způsobím komplikace a ohrozím jeho stabilitu.
  • Druhý - ohleduplnost vůči vývojářům. Silverlight je určen pro "masy vývojářů", nejenom pro pokročilé a zkušené. Chtít po této široké skupině, aby zvládala synchronizaci při práci se sdílenými zdroji, spouštěla akce pomocí Dispatcher.BeginInvoke a delegátů anebo si zvykla, že si její kód v určitých situacích nemůže "sáhnout" na aktuální stav uživatelského rozhraní by asi bylo příliš.
  • Třetí - kombinace prvního a druhého důvodu

Výše popsaná situace má některé zajímavé, byť zcela logické důsledky:

  • Pokud pustíte jakýkoliv déle trvající kód (anebo například Thread.Sleep), celá aplikace přestane reagovat, zastaví se animace apod. A to bez ohledu na to, zda tento kód spustíte jako důsledek akce uživatele anebo je to obsloužení dokončení asynchronního volání. Pokud chcete dělat cokoliv náročnějšího, vytvořte si vlastní thread.
  • Není třeba používat Dispatcher.BeginInvoke, prostě pracujte s UI a neřešte to. Pokud si ale vytváříte vlastní thready, v nich musíte Dispatcher použít.
  • Asynchronní operace webových služeb zřejmě nelze snadno převést na synchronní. Pokud by vás lákalo použít IAsyncResult.AsyncHandle.WaitOne pro čekání na dokončení volání, tak na to rovnou zapomeňte - aplikaci tím navždy "zavěsíte", neboť thread čeká na dokončení události, které nikdy nenastane - není k dispozici thread, který by ho udělal.

Tak hodně štěstí...

Více článků Další stránka »