Sešlo se mi pár různorodých informací, které nevydají na celý spot, ale připadají mi důležité nebo zajímavé, takže je všechny spojím alespoň do tohoto "pel mel spotu".

Nejprve k blogu.

1. Komu chybí měsíční archiv spotů podobný tomu, co byl v .TEXTu, už nemusí truchlit. V pravém navigačním sloupci naleznete měsíční archiv.
   
2. Jak jste si asi již všimli, kvůli novodobému moru jménem komentářový spam jsem zapnul u komentářů povinné zadání číselného kódu z obrázku.
   
3. Pár z vás si stěžuje na malé okno pro psaní komentářů. Vězte že na odstranění problému se usilovně pracuje ;). Přesněji řečeno, postupně změním celý layout blogu, ten současný mi ani po úpravách nevyhovuje.
   
4. Pokud  mi chcete sdělit něco důležitého nebo zajímavého, tak kontakty na mě naleznete nově v pravém navigačním sloupci.

Jestliže mi někdo z vás v poslední době napsal a nedostal odpověď, není to proto, že bych na odpovědi kašlal, ale někdy v té záplavě spamů i běžné korespondence mohu na nějaký důležitý mail zapomenout. Nestyďte se a napište mi znovu.

Chci ale zdůraznit, že v žádném případě už ode mě neobdržíte odpovědi na maily s technickými dotazy zaslané na moje soukromé emailové adresy. Hlavně poté, co jsem zredukoval počet svých příspěvků v odborných konferencích, začaly na moje adresy chodit maily, jejichž pisatelé ode mě chtěli rady z různých oblastí - od psaní severových ovládacích prvků přes webové služby k flashování MDA. Snažil jsem se na dotazy odpovědět a vždy jsem na konec mailu doplnil upozornění, že žádnou další radu takto přímo neposkytnu a žádal jsem každého, aby psal dále jen do konferencí, kde si jeho příspěvku může všimnout více lidí, kteří znají odpověď. Počet mailů ale stále rostl, a proto jsem se je rozhodl ignororovat, protože neznám žádný jiný účinný způsob, jak tazatele odradit. Snad moje rozhodnutí pochopíte, nejsem žádná soukromá poradna, ani nemíním suplovat support jiných firem.

Pobavilo mě, že pár nespokojených individuí mi napsalo, jak si dovoluji neodpovídat na jejich dotazy, když jsem za to placen Microsoftem. Zamyslel jsem se nad sebou, zastyděl za svou roztržitost, kvůli níž jsem zapomněl, že jsem na čestném místě výplatní listiny Microsoftu, a jal jsem se kontrolovat své konto, abych zjistil, kolik jsem si za posledni dobu nahrabal bez práce. Začal jsem také radostně uvažovat nad tím, do jakých nových akcií ten z modrého nebe spadlý balík nacpu. Avšak ani po podrobné prohlídce všech pohybů na účtu jsem nenašel žádnou příchozí platbu od Microsoftu, takže mi ruměnec z tváře zmizel a stud vystřídala nasranost, že si mi někdy dovoluje diktovat na základě svých stupidních a nepodložených domněnek, co pro něj musím udělat. Někteří lidé jsou opravdu zvláštní tvorové a podle mé skromné a ještě neverifikované hypotézy je Bůh stvořil proto, aby zkoušel naši laskavost k bližnímu, kultivovanost v chování a sebeovládání, a tedy nám pomohl dotahovat k dokonalosti vlastnosti, jež nám zabraňují řešit konflikty nadávkami či inzultací dotyčného a činí tak náš svět alespoň občas "nejlepším ze všech možných světů".

A pro nepřispívám už tak často do konferencí, jake se mnozí ptali?

1. Hlavním důvodem je čas, respektive jeho nedostatek. Více k tomuhle bodu asi nemá cenu dodávat.
   
2. Jak jsem už psal asi před rokem a půl v jednom příspěvku, myslím si, že EMWAC, jakožto konference, která pravděpdobně sdružuje nejvíce .Net vývojářů v Čechách, přestává plnit svůj účel. Proč? Když jsem se do ní přihlásil, bylo v ní tak 200 lidí a konferencí prošlo za den jen pár příspěvků. V současné době je přihlášeno přibližně 800 lidí, počet příspěvků za den silně kolísá, ale často je jich určitě několik desitek, což už je počet, při němž se více projevují chronické problémy konference.

1. Nedostatečné technické a personální zázemí - viz třeba věčné, otravné a nikdy neřešené stížnosti kvůli Reply-To hlavičce.
   
2. Absence FAQ dokumentu - začátečnící jsou v každé konferenci vítáni, ale vždy je lepší, když jsou dotazy, které se už objevily x-krát, zodpovězeny v samostatném a na konferenci nezávislém dokumentu, než když se odpověď napíše nově příchozím pokaždé znova a znova přímo do konference.
   
3. Neexistence moderátorů - každá veřejná konference by měla mít moderátory, kteří dbají na dodržování zakladní netiquette, kontrolují formát příspěvků, a upozorňují (nejen) nováčky na prohřešky. Kořením každé konference jsou OT příspěvky, jenže na Emwacu bylo dny, kdy OT příspěvků byla většina. I to je práce pro moderátory. Já jsem ten poslední, kdo by nad sebou chtěl nějaké dráby, ale taktní a trpělivý moderátor může úroveň konference jen pozvednout.
   
4. Konference by měla být rozdělena minimálně na dvě další - jedna konference by byla pro začátečnické dotazy a druhá pro pokročilé dotazy. Není příjemné se prohrabovat nediferencovanými maily, kdy v jednom mailu pisatel řeší záludnosti webových služeb a WSDL specifikace, a hned v následujícím mailu se někdo jiný potýká se základní syntaxí jazyka C#. Řešení obou dotazů je bezesporu pro oba tazatele  stejně důležité, ale myslím, že jejich příspěvky nepatří do jedné konference.
   
5. Bod, který vyplývá z předchozích bodů. Konference je nepřehledná a je v ní spousta duplicitních dotazů i odpovědí.

Update: Reakce Romana Pichlíka

Při psaní business vrstvy libovolné aplikace jste jistě narazili na následující problém, který můžeme demonstrovat na profláknutém příkladu s objednávkami a jejich položkami. Pod položkou rozumíme instanci třídy, ve které jsou uloženy informace o vybraném produktu, počtu objednaných kusů produktu a celkové ceně. Objednávka a položka objednávky jsou třídy, které jste už určitě psali tolikrát, že nemáte rádi ani jejich názvy ;)

Každá objednávka má 0..n položek a vyžádáme-li si konkrétní položku z kolekce všech položek (Items) u objednávky, která již byla uložena do databáze, musí dojít nejprve k nahrání kolekce. Je jedno, zda položky nahráváte ihned privátní metodou nazvanou třeba loadItems volanou z konstruktoru třídy Objednávka, nebo zda (a lépe) používáte zpožděné nahrávání, kdy kolekce Items je naplněna stejnou metodou teprve po prvním přístupu a konstruktory všech business objektů pouze uloží předané unikátní identifikátory (Id) a naplní své vlastnosti uloženými daty (kromě kolekcí) až po prvním přístupu k nějaké vlastnosti (kombinace vzorů Lazy Load a Ghost). Na přístupu k plnění dat objektů nezáleží, jen vždy musíte garantovat, že uživatel objektu musí  přistupovat k datům objektu, aniž by si byl vědom provedených výkonnostních optimalizací - interní impementace je i zde nedotknutelné privatissimum objektu.

Jak zjistíte v metodě loadItems, jaké položky objednávka (třída Order obsahuje? Přes datovou vrstvu spustíte dotaz, která vrátí všechny záznamy s daty pro všechny položky objednávky - parametrem dotazu je samozřejmě Id objednávky. Kruciálním problémem je ale vytvoření položek objednávky (třída OrderItem) z vrácených záznamů. Jaké máme možnosti?

1. Vytvoříme novou instanci OrderItem a předáme jí do konstruktoru její Id. Výhodou je, že třída Order není s třídou OrderItem nijak svázána a pouze jí předává její identifikátor. Velkou nevýhodou ale je to, že object OrderItem při obnovování svých dat z databáze bude znovu posílat dotaz do databáze "dej mi data pro mé Id", což nebude nijak efektivní přístup zvláště, když v objednávce budou desítky nebo stovky položek a každá z nich s opulentní rozhazovačností pošle svůj dotaz do databáze. Navíc je to zcela zbytečné, protože data již byla vyzvednuta v metodě loadItems, ale "jen" nebyly objektu OrderItem předána.
   
2. V metodě loadItems přečteme záznamy položek objednávky, vyzvedneme data ze všech sloupců a pro každou položku vyvoláme konstruktor, který akceptuje všechny vlastnosti položky. Tedy kromě Id předáme i celkovou cenu, počet kusů atd. Sice jsme se již zbavili opakovaného dotazování do databáze položkami objednávky, ale objevily se další zásadní nevýhody. Třída objednávka je zatížena zbytečnou znalostí rozhraní (konstruktoru) třídy OrderItem a při změně třídy OrderItem, jakými jsou přidání nebo odebrání vlastnosti, budeme muset provést i změny ve třídě Order. Při tomto řešení jsme se právě vydali na strastiplnou a rozháranou životní cestu,  nazývanou moderními mudrci ze softwarových pousteven ve svých písemných testamentech "Maintenance Nightmare". Stejný problém budeme mít při plnění vlastností OrderItem, navíc bychom u každé vlastnosti museli mít i set přístupovou metodu, z čehož by se měl všem autokritickým vývojářům obracet žaludek.
   
3. Třídě OrderItem přidáme konstruktor, který přijímá záznam z databáze - v případě .Net Frameworku tedy objekt DataRow. Tohle řešení sejme povinnost nést břemeno znalosti rozhraní třídy OrderItem z třídy Order, ale zanechá nás s třídami, jejichž veřejné (nebo minimálně "internal") rozhraní je zapráskáno objekty z nižších vrstev. Proč by třída měla ukazovat, že je závislá na objektech DataRow, jejichž hlavní doménou je databázová vrstva? Perzistence je u business objektů nutné zlo, ne alfou a omegou a hlavním důvodem jejich existence. Bohužel, i v mnoha složitých projektech jsou stále k vidění jen truchlivé krabičky s daty z databáze a metodami Load a Save doplněné o honosnou etiketu "business vrstva" od nějakého rekvalifikovaného outsidera s kriplovsky laděným elánem Horsta Fuchse, co se v pomatení smyslů rozhodl pomoci saturovat deficit pracovních sil na trhu s vývojáři.

Než přejdu ke cachování dat, jen drobná poznámka, abych předešel dotazům. Metoda loadItems může poslat dotaz, který vrátí jen id položek objednávky, takže se data na klienta netahají dvakrát a můj problém pak působí jen jako vykonstruovaná obsese. I v tomte případě se ale místo jednoho dotazu budete potýkat s desítkami dotazů, které vyzvedávají - většinou zcela zbytečně - data jen pro jednu instanci OrderItem. Jestliže mám k tomu příležitost, je lepší vyzvednou všechna data pro všechny objekty najednou jedním "úsporným" dotazem a přitom dovolit v případě potřeby objektu přímé obnovení dat z databáze svým separátním dotazem.

Když tedy není pro nás přijatelný konstruktor s objektem DataRow, musíme při vytváření objektu "OrderItem" sdělit, odkud může načíst svá data. Jinými slovy, objekt OrderItem musí vědět, kam mu třída Order "schovala" objekt DataRow. Proč bychom ale neefektivně každému objektu extra sdělovali, odkud může načíst svá data? Zavedeme raději jeden centrální objekt - cache na příchozí data z databáze. Pak stačí objektu OrderItem předávat jen Id jako v první variantě a přitom  využívat všech výhod cachování dat.

Co od takové datové cache požadovat?

1. Třída musí být globálně viditelná pro všechny objekty. Půjde tedy o Singleton, respektive pro webové aplikace bude vhodné použít PseudoSingleton (Thread Specific Storage).
   
2. Rozhraní, které se nemění s přidáváním dalších business tříd a které mohou používat jednotným způsobem všechny objekty. Takže chceme univerzální metody pro ukládání i vyzvedávání dat jakéhokoli objektu, ne nějaké stále bobtnající rozhraní s metodami StoreOrdeItem, StoreOrder, StoreXX, StoreXY, ... .

Zde je jednoduchá implementace třídy, která zatím splňuje naše nároky. Zobrazit kód

Myslím, že kód je sám o sobě dostatečně vypovídající, takže jen stručný komentář. Statický atribut Instance vrátí pro každý thread specifickou instanci třídy, která se pro jeden thread chová jako běžný Singleton. Metoda CloseInstance odstraní instanci třídy pro daný thread a tuto metodu je vhodné volat ve webové aplikaci na konci každého požadavku v obsluze události EndRequest v souboru global.asax. Metoda StoreData uschová předaný datový řádek (argument row) pro objekt daného typu (argument type) - metoda předpokládá, že řádek obsahuje sloupec Id, který je jednoznačným identifikátorem každého business objektu. Metoda GetData vrátí dříve uložený řádek pro typ v argumentu type a pro objekt, jehož id bylo předáno v argumentu businessObjectId. Po vrácení dat je uložený řádek odstraněn, aby nebyly vlastnosti business objektu permanentně obnovovány z dříve uložených a již neaktuálních dat.

Přístě si ukážeme, jak si u business objektů vynutit používání třídy DataCacheHelper bez duplikace kódu a rizika, že zapomenete v nově přidané třídě řádky z instance DataCacheHelper vyzvedávat, a také postupně z DataCacheHelperu vydělíme různé aspekty jeho chování, abychom umožnili rekonfiguraci DataCacheHelperu za běhu aplikace a adekvátně vyladili jeho činnost pro různé typy aplikací.

Jednou ze silných motivací, proč si vůbec udělat řidičák, byla i moje nezřízená chuť "geeka" otestovat už konečně a hlavně pořádně GPS navigaci.

Chvíli jsem pokukoval po nějakém vychytaném přístroji od firmy Garmin, ale cena mě odradila. Nejsem obchodní zástupce ani jiný podobný týpek, který projíždí republiku křížem a krážem, a ani sofistikované argumenty, pocházející z líhně falešných racionalizací mého horšího já, mě nepřesvědčily, abych investoval skoro 30 000 do jednoúčelového přístroje.¹ Místo Garmina jsem zakoupil bluetooth GPS Holux 230 a program Pocket Kim v navigačním balíčku 'NaviPack' od firmy Sunnysoft. Součástí 'NaviPacku' je i výborný držák Dicota Keeper pro PDA, který jsem uchytil na přední sklo auta a zatím na něm drží jako přibitý. K PDA dostanete také USB kabel, kterým můžete dobíjet PDA přímo z notebooku nebo USB konektor zasunete do nabíječky na 220V či do cigaretové nabíječky v autě. Chytré a univerzální řešení. Stolní nabíječka i cigaretová nabíječka k PDA i GPS jsou také součástí NaviPacku.

Pocket Kima jsem vzal, protože v lednu aplikace SmartMaps i Dynavix na své entré do světa navigace teprve čekaly.

K samotné navigaci:

Pocket Kim

Testoval jsem hlavně verzi 2.9, protože ve verzi 3.0 uvedené v květnu se na MDAII drasticky zpomalí odezvy aplikace po spuštění GPS. Proto je (nejen) pro mě verze 3.0 zcela nepoužitelná.
V lednu se jednalo o aplikaci, která měla ze všech dostupných programů asi nejlepší mapové pokrytí Čech. Ve srovnání s programy cizí provenience (Navigon, TomTom Navigator) byl po stránce vzhledu i ovládání už tenkrát Pocket Kim špinavým káčátkem, z něhož se ve verzi 3.0 vyklubala neskutečně odpudivá a demencí postižená labuť. Nepřeháním. S žádnou verzí není radno manipulovat v autě, když jste na místě řidiče, ale ve verzi 3.0 je utrpením i volba trasy v pohodlném křesle doma, protože se neustále musíte přes stále stejně nepříjemné a neintuitivní "dotykové prstové" menu proklikávat k navigačním bodům.

Aby Pocket Kim ve verzi 2.9 komunikoval s BT GPSkou, musel jsem nainstalovat Pocket Bluetooth Tools.

Problémem Pocket Kima je poměrně malá databáze míst, do kterých vás dokáže přímo navigovat. Jinak řečeno, třeba v Praze nemůžete navigovat z ulice do ulice, ale musíte vždy najít nejbližší navigační bod, který ale také může být za sedmero horami o tři bloky dále. Částečně se to dá obejít přes zadání vlastního bodu do mapy, ale k němu jste navigováni podobně jako při jízdě ve hrách GTA nebo Mafie = řídíte se jen hrubě podle směru šipky v mapě;). K tomu nepotřebuji satelitní navigaci.

Největším nedostatkem Pocket Kima je ale úplná absence hlasové navigace. Místo toho na vás před každou křižovatkou, kde máte odbočovat, začne Pocket Kim nesměle pípat. To znamená, že se musíte kouknout na displej PDA a zabočit podle toho, co vidíte na displeji. V Praze si neustálé koukání na displej nedovedu představit, takže podle mě se podle pípání opravdu jezdit nedá. A když na displej PDA dopadá sluneční světlo, tak toho také moc neuvidíte.

Testovací jízda s Pocket Kimem

Vybrali jsme cestu z Benešova do Průhonic u Prahy přes Týnec nad Sázavou (tedy ne po dálnici). Jestliže Pocket Kima sleduje spolujezdec, dá se podle něj jet. Pocket Kim selhal pouze jednou, když jsem na jednom odlehlejším místě trval na tom, aby Petra odbočila doleva, aniž bych vzhlédl od displeje:). Když se mě zeptala už potřetí, jestli to myslím vážně, že má zatočit doleva a dodala "do toho zákazu vjezdu" došlo mi, že Pocket Kim se nás snaží navést na nějakou užitkovou cestu, která evidentně nikam nepokračuje, protože na jejím konci je stodola. Takže poučení: kromě displeje je dobré stále sledovat reálné okolí a dopravní značky.

Ve dvou se tedy sice s Pocket Kimem jakžtakž jezdit dá, ale stejně musíte neustále kontrolovat, jestli vás náhodou mapové podklady nevedou někam do pole nebo do zdi. Bez hlasové navigace je Pocket Kim nepoužitelný ve větších městech, kde je hustá doprava, protože při koukání na displej nestíháte sledovat okolí. Abych ale Pocket Kima jen nehaněl - jeho vektorové mapové podklady zabírají pouhých 8 MB (ve verzi 3.0 o něco více) a Pocket Kim také nabízí 140 (ve verzi 3.0 220) měst do úrovně ulic.

SmartMaps
Společnost Aponia uvolnila nedávno čtrnáctidenní demo verzi svých map ve verzi Navigator. SmartMaps jsou bitmapové mapy, takže demo zabírá na paměťové kartě, bez které se neobejdete, úctyhodných 212 MB. Velikost je ale dána podrobností map a jejich podobností s tištěnými mapami. Doporučuji si demo stáhnout, i když nechcete použivat navigaci, a pokochat se mapami, abyste věděli, o čem mluvím. Na ovládání verze Navigator jsem si rychle zvykl, komunikace s BT GPS byla bezproblémová. Předností SmartMaps je také rozsáhlá a stále se rozšiřující databáze zájmových bodů - stačí si jen vybrat, k jakému zámku nebo hradu vás mají dnes SmartMaps dovést, a na cestě si třeba nechat vyhledat nejbližší benzínovou pumpu po rozsvícení "hladového oka" nádrže. SmartMaps mají jen 13 krajských měst do úrovně ulic.

SmartMaps mají hlasovou navigaci a můžete si vybrat, zda chcete být instruováni mužským nebo ženským hlasem. My jsme měli většinu času zapnutý mužský hlas, protože Petra po chvíli navigování ženským hlasem, který jsem původně preferoval já, rezolutně prohlásila, že už tu hysterku poslouchat nebude. Hlasy, a to ani ten mužský, opravdu nepůsobí příliš profesionálně, ale na navigaci stačí. Máte také možnost volit mezi plnou a zjednodušenou navigací - myslím, že jinou než zjednodušenou nevydrží nikdo používat, protože když se v rozšířené navigaci během pěti minut desetkrát dozvíte, že máte pokračovat rovně a po jaké silnici jedete, tak začnete být asi stejně jako já mírně podráždění. Zjednodušená navigace hlásí jen důležité odbočky. Instrukce jsou typu "Za 250 metrů odbočte doprava".

SmartMaps jsme otestovali na stejné trase jako Pocket Kima. Do Průhonic jsme dorazili bez sebemenších problémů, jen při zpáteční cestě SmartMaps v Čestlicích nenahlásily, abychom pokračovali po vedlejší silnici a nechaly nás jet po hlavní (buď šlo o nepříliš dávno provedenou změnu značení hlavní a vedlejší silnice, nebo o chybu v navigačních podkladech). Během chvíle a po našem ignorování povelu k otočení SmartMaps přepočítaly trasu a dovedly nás zpět do Benešova.

SmartMaps nejsou špatné, ale stále se neobejdete bez koukání do mapy. Projeli jsme i jiné trasy a hlavně na více křižovatkách umístěných blízko za sebou je hlasová navigace poněkud chaotická. SmartMaps jsou ale výborným kompromisem mezi užitnou hodnotou a cenou.

Dynavix

A dostáváme se k nekorunovanému králi navigace po Čechách, i když jsem měl možnost vyzkoušet Dynavix jen pouhé 2 hodiny, protože Telematix (ke své vlastní škodě) demo verzi nenabízí, ale naštěstí mi Dynavixe zapůjčil můj kolega z práce Michal. Ovládání Dynavixu není špatné, i když zahraniční programy, o kterých jsem psal výše, mají stále ovládání lepší a "vychytanější". To ale nevadí - (budoucí) úspěch Dynavixu stojí na nejkvalitnějších mapových podkladech pro ČR a na úžasné hlasové navigací. Přesnost mapových podkladů je opravdu špičková, což se projevuje i tím, že v některých městech se můžete nechat navigovat až do úrovně čísel popisných! Mimochodem, Dynavix bude brzy dodávat i podrobné mapové podklady pro Evropu.

Už jsem psal, že hlasová navigace je úžasná a mohu dodat další superlativa. Je profesionální, vůběc neobtěžuje a je neuvěřitelně přesná. Jak taková typická navigace probíhá? Jedete a Dynavix vás upozorní nevtíravou hláškou "připravte se na odbočení vlevo". Před křižovatkou se ozve přesnější instrukce "za 250 metrů odbočte vlevo". To by mi stačilo, ale hochům z Telematixu ne, a tak když vjedete do křižovatky, ozve se ještě povel "nyní doleva". Petra zhodnotila navigaci slovy: "Podle toho dokáže jet kamkoli i blbec".

Zkušební cesta vedla z Benešova do Bystřice, pak do Divišova a Ostředka a zpět. Několikrát jsem odbočili do nějakých malých vesniček, abychom Dynavix zmátli, ale ten vždy jen přepočítal trasu a dále nás navigoval ke zvolenému cíli. V jedné vesničce měl Dynavix v mapě dokonce nějakou zpevněnou polní cestu, na kterou se nás snažil navést, protože tvrdil, že vede nejrychleji do cíle. Jen zde jsem raději jako nevěřící Tomáš uhnul jinam, abych neskončil někde v bahně nebo v houfu divočáků, což jsou okolnosti, s nimiž ani Mistr Dynavix zatím nepočítá .

Dynavix obsahuje samozřejmě i nejaké nedodělky - verze 1.0 má na některých PDA problémy s BT ovladačem, často se ozývala zbytečná hláška o ztrátě satelitního signálu, i když jen poklesl počet satelitů na tři atd. Na to, že je Dynavix ve verzi 1.0, jde ale podle mě opravdu o slušně vyzrálý produkt.

Cena sice není lidová, skoro 8000 Kč, ale já jsem na 99% rozhodnutý, že si Dynavix pořídím - nic lepšího pro Čechy opravdu není. Neměl jsem ho dostat do ruky ;)

Další odkazy k Dynavixu:

• Preview Pavla Kozy
• Více kritické zkušenosti Michala Jedličky

Tohle bylo zatím opravdu jen pár mých zkušeností s navigačními systémy, ale po zakoupení Dynavixu se zde určitě ještě pár podobně laděných spotů objeví.

1. Malá poznámka na okraj. Garmin nyní dodává i navigaci na zařízeních s OS Windows Mobile (iQueue)

Protože nikdo nedodal kompletní řešení k hádance z 26.7., zde je odpověď.

1. Třída MessageReceiverBase - událost MessageReceived, návrhový vzor Observer.
   
2. Třída MessageReceiverBase -metoda CreateMessage, návrhový vzor Factory Method. Metoda CreateMessage vrací přímo instancí třídy Message nebo její potomky. Potomci třídy MessageReceiverBase mohou metodu přepsat a vrátit z metody například instanci OrderMessage, aniž by byly dotčeny vysokoúrovňové scénaře pracující pouze s rozhraním Message a deklarované na úrovni MessageReceiverBase.
   
3. Třídy MessageReceivePoint, MessageReceiverBase a její potomky můžeme považovat za participanty návrhového vzoru Bridge. Třída MessageReceivePoint je abstrakcí - logickým přístupovým bodem, který dokáže přijímat data na daném URI a který interně využívá konkrétní fyzický přístupový bod, jímž je potomek třídy MessageReceiverBase zapouzdřující detaily komunikace po zvoleném přenosovém protokolu. Metoda Listen třídy MessageReceivePoint deleguje volání na metodu Listen třídy MessageReceiverBase. Samozřejmě lze o potomcích třídy MessageReceiveBase uvaživat i jako o strategiích, jak zaznělo v diskuzi o spotu, i když si myslím, že vzor Bridge lépe vyjadřuje role tříd.
   
4. Třída AddMesageAttributesProcessor - jak vyjadřuje její název, jedná se o realizátora vzoru Content Enricher - k přijaté zprávě dodává další informace, které nebyly přímo její součástí ale které jsou důležité pro další zpracování zprávy. Příklad - messagingový systém přijme objednávku a Content Enricher ke zprávě doplní údaje o platební morálce zákazníka.
   
5. Třída FilterMessageAttributesProcessor - opět dle názvu můžete usuzovat, že jde o návrhový vzor Content Filter. Procesor z přijaté zprávy odstraní všechny informace, které nejsou důležité pro další zpracování a které by pouze zbytečně vytěžovaly zdroje serveru. Příklad - messagingový systém přijme obrázové přílohy, které není třeba posílat k dalšímu zpracování, ale pouze se archivují v DMS, takže nemá smysl hnát obrázky celým procesem vyřizování objednávky. Content Filter obrázky ze zprávy před jejím dalším zpracováním odstraní.
   

Jak někteří z vás (Petr :) ) správně vytušili, diagram také svádí k tomu, aby byl rozšířen o Intercepting filter nebo o vzor Pipes&Filters - tyto vzory v něm ale v současné podobě nalezneme poze jako latentní možnosti, které můžeme uskutečnit doplněním a úpravou vztahů mezi existujícími třídami.

Jedna soukromá zpráva, ale mám opravdu radost, takže se o ní s vámi podělím. Po poměrně velkém úsilí ;) se mi podařilo udělat zkoušku z jízd, takže už mohu začít konečně oficiálně;) používat svoje auto a skončí tak moje cesty do Prahy vlakem a busem, které už byly časově neúnosné. Hlavně spolehlivost Českých drah mi pravidelně pumpovala povinnou dávku adrenalinu do žil. Potřebujete stihnout nějaké jednání, vstanete kvůli tomu o hodinu dřív, nastoupíte do vlaku plni optimismu v kvalitu veřejných služeb dotovaných v míře větší než malé z vašich daní a o stanici dále a půlhodině čekání nějaký pologramotný zaměstnanec drah zakoktá, že "lokomotiva je rozbitá, vole a dál se nejede".

Aby to nebylo úplně OT, v mezičase před složením řidičáku jsem stihl otestovat navigační systémy Pocket Kim, SmartMaps a Dynavix, takže brzy se zde objeví nějaké srovnání.

Na serveru CE4YOU můžete v v diskuzi Programování klást své dotazy, které se týkají problémů s vývojem pro Pocket PC a SmartPhone miláčky . Nezáleží na tom, s jakým vývojovým nástrojem pracujete - takže se můžete ptát na vývoj v Compact .Net Frameworku 1.0 (2.0), na vývoj nativních aplikací v C++ nebo i na bastlení ve stařečkovi eVB.

Specializovaná konference na Emwacu není a otázky kolem Pocket PC platformy zůstávají v obecných konferencích většinou bez odpovědi, proto si myslím, že tématicky úzce zaměřená konference bude pro všechny vývojáře pro platformu Windows Mobile příjemným a postupně znalostmi nabytým koutkem. :)

Informace poslední: Jsem moderátorem tohoto fóra, takže jej aktivně sleduji a pokud znám odpověď, nenechávám si ji pro sebe.

Dokážete na následujícím diagramu najít všechny použité návrhové vzory?

Pokud by to někomu přišlo trapně jednoduché, můžete dávat návrhy na vylepšení diagramu...

BTW: Ten diagram není z reálného projektu, takže můžete opravdu usuzovat na návrhové vzory jen podle vztahů, případně podle názvů elementů v diagramu. Je to jen hra

Stažení diagramu

Konečně jsem se dostal k přestěhování blogu na vlastní doménu. Děkuji Michalovi za dosavadní hostování blogu i za pomoc při exportování spotů z .TEXTu. Důvodem mého odchodu není nějaký truc vůči Michalovi, ale jak jsem psal již dříve, moje zvláštní úchylka, která se projevuje tím, že jsem nerad na komkoli závislý, byť by šlo o tak příjemného a vstřícného člověka jako je Michal. Myslím, že Nikos Kazantzakis v Řeku Zorbovi říká, že zvětšování naší svobody je jen iluze a že se jen zvětšuje délka provazu, na kterém jsme uvázáni, takže můžeme dělat stále větší okruhy kolem stromu, k němuž je provaz upevněn. I kdyby to bylo pravda, cítím se teď s delším (a ne snad šibeničním) provazem na krku lépe.

Pár základních informaci na úvod.

URL
http://blog.renestein.net

RSS
http://blog.renestein.net/SyndicationService.asmx/GetRss

ATOM
 http://blog.renestein.net/SyndicationServiceExperimental.asmx/GetAtom

1. Blog již neběží na TEXTu, ale na DASBlogu. DASBlog jsem si vybral, protože mi přijde lépe napsaný a umožňuje kromě dalších vychytávek třeba publikaci spotů přes mail. Bohužel zatím ukládá data do XML, ale dá se žít i s touto drobnou vadou. Protože jsem do útrob DASBlogu dostatečně nahlédl. pokusím se pár spotů o DASBlogu napsat. Důvodem k přechodu na DASBlog bylo také odpoutání se od toho, co kolega Daniel Steigerwald v hyperbole nazval zárodkem fašismu v podobě .TEXTu v .NET komunitě. :)

2. Při převádění spotů jsem je znovu všechny roztřídil do nových kategorií, protože staré kategorie nevyhovovaly a mnohdy nebyly ani v původních kategoriích spoty správně zařazeny.

3. Trochu později jsem zjistil, že se mi zatím nepodařilo korektně převést všechny komentáře. Na tom budu muset ještě zapracovat.

4. Přišlo mi docela dost emailů od lidí, kteří se ptali, kdy vyjde další článek o UML na Interval.cz. Dobrou zprávou pro všechny tazatele snad bude to, že další díl seriálu jsme již redakci poslal a snad se mi podaří v seriálu pokračovat rychlejším tempem než dosud. Dále díky benevolenci serveru Interval.cz a jeho šéfredaktora Viléma Málka budu moci s měsíčním zpožděném publikovat články z Intervalu na svých stránkách. Takže brzy se zde objeví všechny mé články v ucelené podobě.

5. Články zmíněné v předchozím odstavci chci publikovat na samostatné subdoméně a moji ambicí je vytvořit stránky o návrhu, designu a vývoji aplikací, které budou v ideálním případě pro všechny zájemce ekvivalentem toho, co představují vynikající stránky JakPsátWeb pro html kodéry.

6. Když už jsem u toho inspirování se jinde. Na weblogu je také sekce Zaujalo mě, ve které budou bez další kategorizace odkazy na kvalitní články, které mě v poslední době zaujaly. Zcela nepokrytě se přiznávám, že nápad jsem zkopíroval od Jirky Macicha.

7. Frekvence publikování na blogu bude (snad) vyšší než doposud.

8. Pár lidí mělo zájem o reklamu na blogu. Nyní je možné se na reklamě domluvit - kontaktujte mě a domluvíme si podmínky.

To nejlepší na konec: Jestliže se vám líbila Malá typologie českých vývojářů, a bylo vás asi dost, když do celkového počtu čtenářů započítám i rozzuřené emaily od jistých rozkošně se vyjadřujících anonymních přátel, můžete se těšit na pokračování.

Nikdy bych nevěřil, že spot, který jsem napsal za 20 minut kvůli katarzi a vůběc očištění od špatných nekřesťanských myšlenek týkajících se humánní anihilace špatných vývojářů sklidí takový ohlas a že se v něm tolik lidí pozná. Inu, co Čech, to vývojář:). Kromě typologie vývojářů se připravuje i typologie projektových vedoucích - sondu do světa SW firem je potřeba zasunout co nejhlouběji a nezůstat na povrchu.

Zajímavé a trochu smutné je, že moje technické spoty si přečetla přibližně jedna třetina z počtu čtenářů, kteří zhlédli typologii vývojářů - raději z toho nebudu induktivně dovozovat, proč se tak v Čechách daří bulváru a jinému škváru.

BTW: Také jste zaregistrovali, že seriál o VB.NET přestal konečně vycházet? Boží mlýny melou pomalu, ale nakonec nezapomínají ani na svět SW. ;)

Takže vítejte;)

Jak mě upozornil jeden kolega, tak jsem nedal ke stažení prezentaci z přednášky o návrhových vzorech a .Net Frameworku z listopadového programátorského večera.

Takže pro zájemce napravuji:

V archivu ČVUT je i videozáznam přednášky, i když já sám jsem nenašel odvahu se na sebe narcisticko-kriticky podívat ;)

Prezentace, velikost 675 KB