SharePoint 2010 na Windows 7

Teď trochu odbočím od Dynamics AX, ale zas ne až tak daleko. Vazby SharePointu a Dynamics produktů se stále prohlubují a na změnu trendu to rozhodně nevypadá, takže to sem rozhodně patří. Přípravy SharePointu 2010 finišují a pokud je mi známo, měl by být představen 12. května (spolu s Microsoft Office 2010), k dispozici je ale samozřejmě betaverze (odkazy na konci). SharePoint 2010 je možné (pro vývojové účely) provozovat i na klientských operačních systémech, konkrétně Windows 7 a Vista SP1, a přesně to jsem chtěl vyzkoušet. Nechci zde opakovat nutné prerekvizity a podobně (vše najdete v odkazech), spíše popsat jednu konkrétní konfiguraci a problémy, které mě na ní potkaly. Instaloval jsem SharePoint Foundation 2010 na stroj s Windows 7 Enterprise x64, z relevantních aplikací jsem měl naistalován SQL Server 2008 R2, Visual Studio 2010 RC1 a Office 2007 x86. Postup instalace je popsán v tomto dokumentu a toho jsem se také snažil držet. Dočtete se v něm, že instalátor prerekvizit je připraven pouze pro Windows Server 2008 a na jiných systémech budete muset udělat několik kroků ručně. První problém nastal při povolování ASP.NET (chyba v aspnetca.exe). Vygooglil jsem cosi o duplikovaných ISAPI filtrech v IIS po upgradu z XP na W7 (což by se mě teoreticky mohlo týkat), ale nakonec stačilo zastavit IIS. Na druhý problém jsem narazil při povolování WCF non-HTTP activation (NetTcpPortSharing service failed to start). Kombinace EventLog + Google odhalila problém s .NET 4.0 a po jeho odstranění se instalace konečně podařila. Po instalaci SharePointu jsem spustil SharePoint Products Configuration Wizard a ten skončil zprávou, že nemohl nalézt sestavení Microsoft.IdentityModel. Tento problém vyřešila instalace Geneva Frameworku (download) - v prerekvizitách je uvedený, ale na ty je vždycky dost času. ;) Opětovné spuštění Configuration Wizardu proběhlo bez problémů a tím byla instalace úspěšně dokončena. Ještě se chci zmínit o instalaci SharePoint Designeru. Stáhnutí Designeru se mi samo nabídlo při pokusu o editaci knihovny (což mě potěšilo) a já jsem zvolil 64-bitovou verzi. Ta se ovšem nesnese s mými 32-bitovými Office 2007 a já musel stáhnout ještě 32-bitový Designer. A to jsem si už stejným způsobem naběhl s Visiem 2010… Tak hodně úspěchů s SharePointem 2010! [Užitečné odkazy] SharePoint Foundation 2010 Beta Hardware and software requirements (SharePoint Foundation 2010) SharePoint Server 2010 Beta Hardware and software requirements (SharePoint Server 2010) Setting Up the Development Environment for SharePoint Server MSTV.CZ: Technet konference: Sharepoint 2010 a Office 2010

AX.NET

Podle názvu byste možná řekli, že AX.NET má něco společného s Dynamics AX a .NET. A skutečně! AX.NET je nástroj usnadňující vývoj .NET aplikací, které volají aplikační logiku AX pomocí Business Connectoru. A v čem je to usnadnění? Zejména v tom, že AX.NET vytvoří z AOT .NET sestavení, obsahující všechny třídy, tabulky, enumy atd. Toto sestavení je pak přidáno do projektu ve Visual Studiu a objekty jsou připraveny k použití - lze volat metody tříd, přiřazovat hodnoty do polí v tabulkách atd. To vše s podporou všech schopností Visual Studia - IntelliSense, typová kontrola a spousta dalších. To proto, že díky AX.NET je Axapta jen další .NET sestavení. Skvělé řešení! AX.NET také podporuje LINQ dotazy (Language-Integrated Query, speciální syntaxe pro psaní dotazů), které překládá do X++ a spouští přes Business Connector (takže se opět použije veškerá AX aplikační logika). Praktickou ukázku můžete vidět například v tomto videu. Na AX.NET jsem narazil v podstatě okamžitě, co se objevili první zprávy, ale čekal jsem, zda se to podaří realizovat a jen jsem občas zkontrolovat, co na mě vypadlo z RSS. Ale zřejmě je na čase vzít tento projekt vážně, protože oficiální vydání má být právě dnes! Jen bych asi měl dodat, že jde o komerční projekt. Více informací o AX.NET naleznete na proisv.com.

Odhady pracnosti

O odhadech pracnosti při tvorbě softwaru už byla napsána řada knih a já ani nemám ambici přinést tímto článkem něco nového. Přesto… povědomí vývojářů, konzultantů, projekt manažerů (a všech ostatních ;)) o zkušenostech, které softwarový průmysl nasbíral za desítky let své existence, je mimořádně nízké, takže trocha opakování snad neuškodí. V tomto článku chci ukázat, jak dělám odhady programátorských prací já osobně a upozornit na některé časté chyby. Můj osobní přístup nelze samozřejmě považovat za univerzálně platný. Pro další postupy, lepší vysvětlení, teoretické podklady, statistiky atd. musíte zapátrat v odborné literatuře. V češtině nelze než doporučit Odhadování softwarových projektů (možná znáte originální název Software Estimation: Demystifying the Black Art). Cíl odhadu Nejprve je třeba si ujasnit, k čemu má odhad sloužit. Z toho pak plyne, v jaké fázi projektu odhad potřebujeme, s jakou přesností atd. Někdy stačí velmi vágní odhady (projekty typu až to bude, tak to dodáme) jindy je třeba dělit práci do iterací, volit variantu, která se stihne do fixního data atd. Odhad by měl poskytnout data dostatečná pro plánování a řízení projektu, nemůže poskytnout přesné číslo, jak dlouho bude práce trvat (tuším McConnell to nazývá „předpovídání budoucnosti“). Přesto je nalezení tohoto magického čísla cílem odhadů na mnoha projektech – a asi nepřekvapí, že v předpovídání budoucnosti lidstvo velký pokrok neudělalo. :-) Jednou z nejčastějších chyb je přímá kalkulace ceny projektu z odhadu (odhad v hodinách × hodinová sazba). To je také zřejmě důvodem, proč jsou tak často požadovány „předpovědi budoucnosti“. Krom negativních dopadů na konstrukci ceny má tento přístup také dopad na tvorbu odhadu – místo aby se udělal co nejpřesnější odhad a cena se stanovila nezávisle, vytváří se tlak na změnu odhadu. Problém je v tom, že takto modifikovaný odhad (ať už kterýmkoli směrem) může být těžko použit pro plánování projektu. Byl jsem dokonce svědkem snah přenést zodpovědnost za dodržení „odhadu“ na vývojáře. Nutným důsledkem by pak bylo dohadování mezi vývojářem (snažícím se nadsadit odhad tak, aby se do něj vždy vešel) a projekt managerem (snažícím se stlačit termín). Skutečný odhad by v takovém procesu figuroval jen zcela okrajově. Kdy odhadovat Projekt lze odhadovat v kteroukoli fázi, ale dosažitelná přesnost je limitována množstvím informací, které jsou k dispozici. Například pokud odhadujete pracnost na základě pouhého uživatelského požadavku, nemá podle mého názoru smysl větší přesnost než Malá/Střední/Velká náročnost (a i tak se to často nepodaří trefit). Pokud chcete získat (relativně) přesný odhad, potřebujete znát všechny funkční požadavky i způsob implementace. Protože v Dynamics AX většinou zasahujete do existujícího kódu, je nutné vědět, jaké části již existují a bude je možné využít a jaké je třeba nově naimplementovat. Někdy je také vhodné vytvořit prototypy nejasných částí ještě před odhadem pracnosti. To všechno si pochopitelně vyžádá určitý čas, se kterým musí být počítáno v projektovém plánu. Jak odhadovat První a nejdůležitější částí odhadu je dekompozice na menší části. Tyto části je nutné nejprve vůbec identifikovat (do té doby jen tušíte, co všechno bude asi tak třeba udělat), ověřit, zda pokrývají všechny požadavky, a nakonec je postupně odhadnout. Často nejsou všechny potřebné informace k dispozici, ale je možné odhadnout alespoň některé části a ke zbylým se vrátit později. Já projekt člením po (relativně) samostatně funkčních blocích realizovatelných v řádu hodin čí dnů (dnů v případech, kdy je v odhadu příliš mnoho nejistoty). Odhady rozepisované podle jednotlivých objektů (tedy ne podle funkcí) považuji za hůře členitelné a nerespektující skutečný postup práce při vývoji. Ke každému funkčnímu bloku zapisuji vše, co je třeba udělat, ale tyto detaily neodhaduji samostatně. Seznam pak používám i v průběhu vývoje ke kontrole, zda je vše naimplementováno, a k vykazování stavu implementace. V mém případě vypadá popis bloku nějak takto: Parametrizační tabulka (EDTs, help texty, tabulka, formulář, menu item, do menu) Členění na menší části má ještě několik dalších výhod. Zejména je jasné, co je vlastně do odhadu zahrnuto, a v případě změn lze snadno přidat/odebrat určité bloky, popř. zpětně vysledovat, jaká práce chyběla v odhadu a přesto se musela udělat. Když už víte, co všechno se bude programovat, zbývá jen udělat odhad. Na většině projektů (alespoň co mohu soudit z mé zkušenosti) je odhad číslo popisující za jak dlouho by se práce mohla stihnout. Pak se pár věcí zkomplikuje a výsledek se oproti odhadu liší i o stovky procent. Odpovědí na tento problém (a nejen na něj) je definice odhadu jako rozsahu, do kterého výsledná pracnost s vysokou pravděpodobností padne. Když jsem o tomto přístupu poprvé četl (v praxi jsem ho nikdy neviděl), nedovedl jsem si to moc představit. V praxi se ale ukázalo, že je to postup velmi přirozený a rychle se na něj zvyká. Prostě odhadnete optimistickou variantu (to je to výše zmíněné za jak dlouho se to dá stihnout) a naopak pesimistickou. Odhad pak daleko lépe popisuje, jaké situace mohou nastat a zabraňuje zaměňování odhadu za termín, kdy bude práce určitě hotova. U jednočíselných odhadů se také často projevuje tlak na jejich snížení – zde to nepředstavuje problém, protože optimistická varianta je zahrnuta, ale zároveň je zřejmé, že to skutečná pracnost bude pravděpodobně větší. Na závěr Doufám, že jsem něco málo z problematiky odhadování odhalil a ne zamlžil. Vědomě jsem pominul celou řadu důležitých věcí, třeba využívání dřívějších odhadů (a jejich úspěšnosti), ale domnívám se, že začít je třeba výše uvedeným. A pak už jen zlepšovat…

Generátor přístupových metod pro AX4

Pomalu se zabydluji ve svém novém působišti ve Velké Británii a tak se zas pokusím trochu vyprázdnit buffer věcí, o které bych se chtěl podělit. První z nich je velmi stručná - jelikož můj aktuální projekt běží na AX 4.0, připravil jsem .xpo generátoru přístupových metod i pro tuto verzi AX. Stahovat můžete zde.