Duracellko.NET

Scrum Planning Poker pre Windows Azure

duracellko — Wed, 21 Nov 2012 11:59:00 GMT

Ak na projektoch reálne používate Scrum, tak pojem Planning Poker určite poznáte. Ide o techniku odhadovania pracnosti/zložitosti bez toho, aby sa jednotliví členovia tímu navzájom ovplyvňovali. Viac o tejto hre môžete nájsť na wikipedii. Planning Poker je reálna hra, ktorá sa hrá s reálnymi kartami. Samozrejme že nie s mariášovými, ale sú na to špeciálne určené karty. Problém nastáva, keď vývojársky tím je distribuovaný a teda nemá možnosť sa fyzicky stretnúť. Práve pre tento účel som vytvoril Planning Poker web aplikáciu. Jediné, čo k tomu potrebujete, je:

Webový prehliadač
Samozrejme nejaké komunikovadlo medzi členmi tímu. Niečo na konferenčný hovor, prípadne video konferenčný hovor.
A niekde hostovať webovú aplikáciu Planning Poker. Hoci aj na Windows Azure.

Keďže samotná aplikácia môže byť zaujímavá aj z pohľadu vývoja a je to v podstate moja prvá aplikácia pre Windows Azure, tak celý projekt môžete nájsť na CodePlexe. Takže nech sa páči Planning Poker 4 Azure.

CustomValidationAttribute nie je thread-safe

duracellko — Thu, 23 Jun 2011 20:29:22 GMT

Nedávno som narazil na chybičku v CustomValidationAttribute. A to konkrétne, že inicializačná procedúra v tejto triede nie je thread-safe. Presnejšie na začiatku tejto procedúry sa nastaví flag, že inicializácia už prebehla. Avšak ak medzitým nejaký iný thread validuje inú inštanciu tej istej triedy, tak si myslí že inicializácia už prebehla a pri spustení validačnej metódy vznikne NullReferenceException. A presne toto sa stalo mne.

Tento scenár sa vám asi ťažko podarí spraviť v nejakej webovej aplikácii. To by muselo niekoľko užívateľov naraz uložiť záznam rovnakého typu a aj to po spustení aplikácie. Ak sa to totiž raz podarí, tak atribút zostane inicializovaný až do ukončenia aplikácie.

Preto mne sa podarilo na túto chybu naraziť až keď som robil job, ktorý synchronizuje dáta v aplikácii. A aby to bežalo rýchlejšie, tak každý záznam sa synchronizuje paralelne cez Parallel.ForEach. A práve tu už nebol problém naraziť na NullReferenceException.

Bližší popis chyby je na connecte: http://connect.microsoft.com/VisualStudio/feedback/details/675788/customvalidationattribute-is-not-thread-safe

Nájdete tu aj zdrojový kód programu, ktorý presne túto chybu simuluje.

Clipboard Share alebo môj prvý open-source projekt

duracellko — Fri, 12 Feb 2010 14:35:18 GMT

Nedávno som dostal požiadavku na programček na posielanie obsahu clipboardu medzi počítačmi od človeka, ktorý používa viac počítačov naraz. Celkom jednoduchý programček s použitím WCF. Práve pri tom vznikol článok WCF service na voľnom TCP porte. Obsah sa pri posielaní šifruje a podpíše. Potom je možné prijať obsah clipboardu len od dôveryhodných odosielateľov.

Trochu bol problém zistiť zoznam počítačov, na ktorých beží tento programček. Práve na to som použil Net Peer Binding vo WCF.

A keďže je úplne zbytočné niečo spraviť, keď sa o to človek nepodelí, tak som sa rozhodol to dať na CodePlex.

A samotný Clipboard Share nájdete tu.

ObservableCollection

duracellko — Sat, 06 Feb 2010 16:01:30 GMT

Čo sa za mladi naučíš, v starobe ako by si našiel. Tak toto som našiel celkom neskoro. Už niekoľkokrát som potreboval kolekciu s udalosťami o pridaní a odobraní prvku. Napísať si takú kolekciu podedením z triedy Collection<T> nie je žiadny problém. Lenže načo niečo také, keď v .NET od verzie 3.0 máme triedu ObservableCollection<T>. A tá obsahuje dve udalosti.

CollectionChanged sa vyvolá, keď sa zmení kolekcia. Teda, keď tam pridáme, odoberieme prvok, zmeníme na určitej pozícii alebo vyčistíme kolekciu.
PropertyChanged sa vyvolá, keď sa zmení nejaký objekt v kolekcii. Toto funguje, iba ak objekty v kolekcii implementujú interface INotifyPropertyChanged.

A túto triedu som doteraz poctivo ignoroval práve preto, že je v netradičnej assembly WindowsBase, ktorú si spájam práve s WPF. Ale v skutočnosti táto assembly súvisí hlavne so XAML, ktorý je oveľa univerzálnejší ako WPF. Napríklad sa dá použiť s Workflow Foundation.

Ešte pre úplnosť, tak táto trieda je v namespace System.Collections.ObjectModel.

WCF service na voľnom TCP porte

duracellko — Mon, 25 Jan 2010 13:44:22 GMT

Nedávno som robil jednoduchú desktopovú aplikáciu, ktorá prenáša dáta medzi užívateľmi. Niečo ako instant messaging, len sa neprenášajú užívateľom písané správy. Keďže aplikácia nemusí fungovať cez internet, stačí len na LAN, tak som sa rozhodol použiť WCF a NetTcpBinding.

A keďže je to desktopová aplikácia a môj protokol nie je žiaden štandard, tak som nevyhradil žiaden špecifický TCP port, na ktorom by služba počúvala. Ale narazil som na problém, že donútiť WCF službu počúvať na ľubovoľnom voľnom porte a ešte zistiť ten port nie je celkom jednoduché. Našťastie je to možné a nie je to žiadna tragédia.

Najprv na NetTcpBinding musíme nastaviť nejaký špecifický namespace aj name. Potom po pridaní ServicePoint do ServiceHost nastavíme na ServicePoint ListenUriMode na Unique. Toto zabezpečí, že WCF služba bude fungovať na ľubovoľnom voľnom TCP porte.

A po spustení ServiceHost vyhľadáme ChannelDispatcher s príslušným name a namespace. A potom už stačí len zobrať Lister Uri a z nej prečítať port.

Tu je kód ako to spraviť.

// vytvorim novy ServiceHost

var host = new ServiceHost(new MyService(), new Uri(“net.tcp://localhost/MyService”));

// nastavim TCP binding

var binding = new NetTcpBinding();

binding.Namespace = “MyNamespace”;

binding.Name = “MyServiceBinding”;

// pridam a nastavim ServicePoint

var sp = host.AddServicePoint(typeof(IMyService), binding, String.Empty);

sp.ListenUriMode = ListenUriMode.Unique;

// spustime sluzbu

host.Open();

// zistim TCP post

var channelDispatcher = host.ChannelDispatchers.OfType<ChannelDispatcher>().FirstOrDefault(cd => cd.BindingName == “MyNamespace:MyServiceBinding”);

int port = 0;

if (channelDispatcher != null)

{

port = channelDispatcher.Listener.Uri.Port;

}

Alebo ak máte radšej zápis pre konfiguračný súbor.

<system.serviceModel>

<host>

</baseAddresses>

</host>

</service>

</services>

</system.serviceModel>

Takto máme službu, ktorá sa vždy otvorí na náhodnom porte. Predpokladajme, že sa nám podarí toto číslo portu dostať na klienta. Ja som na to použil NetPeerTcpBinding kanál. Celkom sranda vecička, ale o tom inokedy. Keďže klient vie port pre daný počítač, tak nie je problém poskladať URI a pripojiť sa na WCF službu. No na moje prekvapenie to trochu problém je. Je totiž rozdiel medzi URI, ktorá identifikuje službu, a URI, na ktorej služba fyzicky beží.

URI, ktorá identifikuje službu, je tá, ktorú zadávame pri vytváraní endpointu (alebo servicepointu). V našom prípade je to base address, ktorú sme zadali pri vytvorení ServiceHost.

Fyzická URI je tá, ktorú musíme zadať klientovi, aby vedel, kam sa má pripojiť. V našom prípade to bude URI so správnym názvom počítača a uvedeným TCP portom. Napr.: net.tcp://duracellkopc:12345/MyService

A tu je kameň úrazu. WCF štandardne predpokladá, že obidve URI sú rovnaké. Teda až na názov počítača. To je jediná časť URI, ktorá sa ignoruje, avšak aj toto sa dá zmeniť. Takže klient vytvorí TCP spojenie a pošle požiadavku na službu so špecifickou URI. Lenže WCF na serverovej strane povie, že žiadnu službu na URI s takým portom nepozná.

Našťastie aj pri klientovi sa dá povedať, že má pristupovať k službe s určitou URI, ale fyzicky sa má pripojiť niekam inam. A to niekam inam sa vo WCF nazýva ClientViaBehavior. Čiže konštruktor pre klienta by bol asi takýto.

public MyServiceClient(Uri remoteAddress)

: base(new NetTcpBinding(), GetPortLessUri(remoteAddress))

{

Endpoint.Behaviors.Add(new ClientViaBehavior(remoteAddress));

}

private static Uri GetPortLessUri(Uri uri)

{

var uriBuilder = new UriBuilder(uri);

uriBuilder.Port = –1;

return uriBuilder.Uri;

}

Tak a máme službu, ktorá beží na ľubovoľnom voľnom porte a zároveň aj klienta, ktorý sa na ňu vie pripojiť.

Ako zobraziť okno bez focusu

duracellko — Wed, 20 Jan 2010 23:29:06 GMT

Toto je rýchly blog, aby som to nemusel googliť zase niekoľko hodín.

Jedna možnosť je overide vlastnosti ShowWithoutActivation. Stačí, aby táto vlastnosť vrátila true a okno nebude mať focus pri otvorení. Problém je, že toto nefunguje pri TopMost formách. Avšak našiel som pekný trik. Overide vlastnosti CreateParams. Táto vlastnosť vytvorí argumenty, ktoré sa pošlú funkcii CreateWindowEx. Toto ponúka celkom dosť možností. A hlavne nastaviť štýl okna na WS_EX_NOACTIVATE. Tento štýl znamená, že okno nebude mať nikdy focus, ani keď užívateľ na neho klikne. Tento štýl sa používa na floating toolbars a podobne okná, keď užívateľ klikne na gombík na toolbare, ale focus má stále hlavné okno.

Ja som toto použil pri vlastnej notifikácii nad ikonou v system tray. A tu je kód.

protected override CreateParams CreateParams

{

get

{

CreateParams result = base.CreateParams;

result.ExStyle |= WinApi.WS_EX_NOACTIVATE;

return result;

}

Ešte pre úplnosť, tak WS_EX_NOACTIVE = 0x08000000. Toto je možné zistiť na stránke www.pinvoke.net. Mimochodom veľmi dobrá stránka ak potrebujete volať WinAPI z .NET.

Task Parallel Library a .NET 4.0

duracellko — Tue, 27 Oct 2009 12:59:16 GMT

S TPL som sa hral už, keď vyšla prvá verzia CTP. TPL je framework, ktorý má uľahčiť vývoj algoritmov optimalizovaný pre viac jadrové procesory. A v dokumentácii som sa dočítal, že CTP nevytvorí viac threadov, ako je jadier v procesoroch. Teda threadov môže byť viac, ale nespiacich by nemalo byť viac. Je to celkom rozumná podmienka, pretože v skutočnosti nemôže bežať paralelne viac threadov ako procesorov. Každý ďalší thread sa musí deliť o procesor, a teda dochádza k prepínaniu threadov, čiže v skutočnosti nebežia paralelne, len sa veľmi rýchlo striedajú.

Než budem pokračovať, tak najprv musím zadefinovať dve veci. Je to čisto moja definícia, ktorú som už párkrát písal na aspnet.sk.

Paralelný algoritmus – algoritmus, ktorý využíva viac procesorov. Čiže sa skladá z úloh, ktoré môžu bežať naraz na viacerých procesoroch. Avšak každá takáto úloha využíva len procesor a pamäť. Žiadne iné zdroje ako disk, databázu, web services nepoužíva. Napríklad paralelné triedenie alebo raytracing.
Asynchrónna úloha – úloha, ktorá sa má spustiť na pozadí a hlavný proces môže vykonávať niečo iné, pokiaľ sa úloha vykonáva. Typický príklad je asynchrónne volanie web service. Web service sa zavolá na pozadí a hlavný program beží ďalej a nie je zamrznutý.

Tieto definície som si zaviedol po zoznámení sa s TPL CTP1. A taktiež všeobecná poučka hovorila, že TPL je určené práve na paralelné algoritmy a nie asynchrónne úlohy. Paralelné algoritmy využívajú len procesor, a práve preto nemá význam aby sa spúšťalo viac úloh paralelne, ako je procesorov. Proste celý algoritmus nemôže bežať rýchlejšie, ale skôr pomalšie, lebo aj context switch niečo stojí. A na jednojadrovom procesore by mal bežať algoritmus úplne sekvenčne.

Naopak asynchónnych úloh môžem mať spustených oveľa viac ako je procesorov. Veď aj tak každý thread spí a čaká, kým sa niečo dokončí na nejakom inom zariadení (napríklad na servery, kde beží web service).

Práve preto TPL CTP bola určená na paralelné algoritmy, ale nebola vôbec vhodná na asynchrónne úlohy. Lenže toto sa zmenilo v .NET 4.0. Najprv som si všimol, že v MSDN okrem klasických príkladov na paralelné násobenie matíc pribudli aj príklady na asynchrónne volanie web service. A na stránke Introduction to Tasks píšu, že úlohy sú plánované pre maximálnu priepustnosť, ale nič o tom, že by počet threadov bol obmedzený počtom procesorov. Dokonca tam píšu, že celé je to postavené na klasickom .NET ThreadPool, aj keď som niekde čítal, že ten bol prepísaný. História bola asi taká, že v CTP1 to bolo postavené na ThreadPool, potom v CTP2 si napísali vlastný plánovač a asi na základe neho prepísali ThreadPool v .NET 4.0.

Tak som sa rozhodol overiť, ako to je s tým počtom threadov. Spravil som si jednoduchú funkciu, ktorá opakuje cyklus, kým ubehne 15 sekúnd. A túto funkciu som pustil 15-krát paralelne.

private static void WaitTasks()

{

var time = new TimeSpan(0, 0, 15);

Parallel.For(0, 15, i => Wait(time, i));

}

private static void Wait(TimeSpan time, int id)

{

var startTime = DateTime.Now;

Console.WriteLine("Task {0} starts at {1:hh:MM:ss.ff}... {2}", id, startTime, Task.CurrentId);

var now = DateTime.Now;

while (now < startTime + time)

{

now = DateTime.Now;

}

Console.WriteLine("Task {0} ends at {1:hh:MM:ss.ff}... {2}", id, DateTime.Now, Task.CurrentId);

}

A výsledok bol asi nasledovný:

Task 0 starts at 01:10:06.63... 1

Task 7 starts at 01:10:06.69... 2

Task 14 starts at 01:10:07.88... 3

Task 1 starts at 01:10:10.43... 4

Task 8 starts at 01:10:14.31... 5

Task 2 starts at 01:10:18.90... 6

Task 0 ends at 01:10:21.83... 1

Task 3 starts at 01:10:21.83... 1

Task 7 ends at 01:10:22.20... 2

Task 9 starts at 01:10:22.20... 7

Task 14 ends at 01:10:22.90... 3

Task 5 starts at 01:10:22.90... 8

Task 1 ends at 01:10:25.95... 4

Task 11 starts at 01:10:25.95... 9

Task 8 ends at 01:10:29.66... 5

Task 13 starts at 01:10:29.66... 10

Task 2 ends at 01:10:34.47... 6

Task 3 ends at 01:10:36.83... 1

Task 4 starts at 01:10:36.83... 1

Task 9 ends at 01:10:37.30... 7

Task 10 starts at 01:10:37.30... 7

Task 5 ends at 01:10:38.25... 8

Task 6 starts at 01:10:38.25... 8

Task 11 ends at 01:10:40.95... 9

Task 12 starts at 01:10:40.95... 9

Task 13 ends at 01:10:45.11... 10

Task 4 ends at 01:10:51.86... 1

Task 10 ends at 01:10:52.34... 7

Task 6 ends at 01:10:53.26... 8

Task 12 ends at 01:10:55.95... 9

Takže je vidno, že až 5 threadov bežalo paralelné, aj keď nezačali všetky naraz, ale ThreadPool chvíľu čakal, či sa mu nejaký thread neuvoľní. Je to vidieť aj na nasledovnom obrázku.

Potom som ešte spravil to, že som rovnakú funkcionalitu prepísal pomocou Delegate.BeginInvoke, čo využíva ThreadPool a je v .NET už od verzie 1.0.

private static void WaitThreads()

{

var time = new TimeSpan(0, 0, 15);

var waitDelegates = new Action<int>[15];

var waitAsyncResults = new IAsyncResult[waitDelegates.Length];

for (int i = 0; i < waitDelegates.Length; i++)

{

waitDelegates[i] = id => Wait(time, id);

waitAsyncResults[i] = waitDelegates[i].BeginInvoke(i, null, null);

}

WaitHandle.WaitAll(waitAsyncResults.Select(ar => ar.AsyncWaitHandle).ToArray());

}

Výsledok bol ten istý. Tiež sa vytvorilo 5 threadov a aj časy boli rovnaké.

Aby som to celé zhrnul, tak som bol vždy toho názoru (spolu s Vlkom), že s TPL v mojej praxi veľmi do styku neprídem a podobne je na tom so mnou väčšina programátorov. Veď koľkí z vás programujú násobenie matic alebo iné paralelné algoritmy. Zato jednoduché asynchrónne volanie webservice je asi problémom väčšiny z nás. A keďže prístup TPL sa v .NET 4.0 zmenil, tak aj ja musím zmeniť svoj názor. Proste TPL je už vhodná aj na asynchrónne úlohy a stačí si porovnať v mojom príklade funkcie WaitTasks a WaitThreads.

Žiaľ neexistuje na MSDN článok o TaskScheduler, že ako to je s jeho optimalizáciou práve pre paralelné algoritmy. Zatiaľ je tam len To Be Done.

Stream.CopyTo

duracellko — Sun, 25 Oct 2009 16:56:01 GMT

Trochu som si pozeral to nové Visual Studio a veľmi ma potešila úplna maličkosť. Nová metóda Stream.CopyTo. Aj preto, že určite každý ste si ju sami napísali aspoň raz. Jej funkciou je skopírovať obsah Stream-u do druhého Stream-u. A sú dve verzie.

Stream.CopyTo(Stream destination);

Stream.CopyTo(Stream destination, int bufferSize);

V tej druhej verzii môžete povedať, aký veľký buffer sa má pri kopírovaní použiť.

Na MSDN to nájdete na http://msdn.microsoft.com/en-us/library/system.io.stream.copyto(VS.100).aspx

INNER JOIN cez dva stĺpce a OR

duracellko — Mon, 19 Oct 2009 08:36:54 GMT

Tak je tu ďalšie T-SQL okienko. Tentoraz ide čisto len o problém na SQL Server. Možno na iných databázach sa query optimalizátor správa trochu inteligentnejšie. A možno aj nie :)

Pracujem na systéme postavenom nad MS CRM, kde fyzické osoby sú uložené v entite contact a právnicke v entite account. Pre tých, ktorým MS CRM nič nehovorí, tak každá (alebo väčšina) entita je uložená v dvoch SQL tabuľkách, pričom tieto dve tabuľky sú spojené vo view s rovnakým názvom ako je názov entity. Každý objekt má primárny kľúč uniqueidentifier, teda GUID, takže každý objekt má jedinečné ID v rámci celej databázy.

Ďalej som mal vo vedľajšej databáze v tabuľke zoznam klientov, ktorí sa majú nejak spracovať. Stačí zoznam GUID a typ, či ide o account alebo contact. Klient môže mať nejaké zmluvy, ktoré sú uložené v custom entite new_contract. Problém MS CRM je, že nad jedným stĺpcom môže byť len jeden foreign key. Takže new_contract obsahuje dva stĺpce new_account a new_contact, pričom vždy je vyplnený práve jeden z nich. A tu je kameň úrazu. Chcem vybrať všetky zmluvy klientov, ktorí sú v pomocnej databáze. Tak som spravil jednoduchý SELECT.

SELECT *

FROM ProcessClient PC INNER JOIN – zoznam klientov na spracovanie

New_MSCRM.dbo.new_contract Cn ON Cn.new_account = PC.ClientId OR Cn.new_contact = PC.ClientId

WHERE Cn.DeletionStateCode = 0

Lenže tento príkaz, ktorý sa mal vykonať za sekundu trval niekoľko minút. Aj nad stĺpcom new_account aj new_contact existujú indexy. Tak som predpokladal, že query optimalizátor pre každého klienta vyhľadá zmluvy podľa jedného aj druhého indexu a potom tieto dve množiny zjednotí. Dokonca operácia zjednotenia by bola veľmi jednoduchá, lebo vždy by bola jedna množina prázdna. Lenže podľa query plan sa SQL Server vykašľal na oba indexy a robil full scan nad celou tabuľkou.

Riešenie bolo rozdeliť podmienku OR do dvoch joinov.

SELECT *

FROM ProcessClient PC LEFT JOIN

New_MSCRM.dbo.new_contract CnA ON CnA.new_account = PC.ClientId LEFT JOIN

New_MSCRM.dbo.new_contract CnC ON CnC.new_contact = PC.ClientId

WHERE ISNULL(CnA.DeletionStateCode, CnC.DeletionStateCode) = 0

Problém bol v tom, že celý SELECT bol oveľa zložitejší a na zmluvy som mal naviazané ešte ďalšie tabuľky a tie by som musel tiež zdvojiť. Takže by sa celý príkaz stal zbytočne nečitateľný. Našťastie som si spomenul na čarovné slovíčko CROSS APPLY. Keď nevedel query optimalizátor spraviť UNION automaticky, tak mu ho treba napísať exaktne. Takže výsledok bol nasledovný.

SELECT *

FROM ProcessClient PC CROSS APPLY (

SELECT * FROM New_MSCRM.dbo.new_contract CnA ON CnA.new_account = PC.ClientId

UNION ALL

SELECT * FROM New_MSCRM.dbo.new_account CnC ON CnC.new_contact = PC.ClientId

) AS Cn

WHERE Cn.DeletionStateCode = 0

A naozaj pomohlo. Vykonanie príkazu sa skrátilo na sekundu. Takže vyhnite sa OR operátorom v joinoch a naozaj funkčné a čitateľné riešenie je použiť UNION v CROSS APPLY.

T-SQL a výber prvej asociovanej položky

duracellko — Thu, 13 Aug 2009 07:51:35 GMT

Po Sirovom príspevku na T-SQL pridám aj ja niečo. Predstavte si, že máte dve tabuľky Contact a PhoneNumber.

Contact

ContactId

FirstName

LastName

ďalšie stĺpce

PhoneNumber

PhoneNumberId

ContactId

Number

Pričom ContactId v tabuľke PhoneNumber je foreign key na stĺpec ContactId z tabuľky Contact.

A problém je nasledovný. Treba vybrať všetky kontakty a ku každému najviac jedno telefónne číslo. Je úplne jedno ktoré, ale najviac jedno. Určite väčšina z vás už podobný problém riešila. Ja používam už od čias mojich začiatkov s SQL nasledovné riešenie.

WITH PhoneNumberMinId (ContactId, MinPhoneNumberId) AS

(

SELECT ContactId, MIN(PhoneNumberId) AS MinPhoneNumberId

FROM PhoneNumber

GROUP BY ContactId

)

SELECT C.*, PN.Number

FROM Contact C LEFT JOIN

PhoneNumberMinId PNMI ON PNMI.ContactId = C.ContactId LEFT JOIN

PhoneNumber PN ON PN.PhoneNumberId = PNMI.MinPhoneNumberId

Táto syntax sa dá použiť len v SQL Server 2005 a vyššej verzii, ale použil som ju kvôli lepšej čitateľnosti a zrozumiteľnosti. Pred SQL 2005 som používal nasledovný select, ktorý je sémanticky úplne rovnaký.

SELECT C.*, PN.Number

FROM Contact C LEFT JOIN

(

SELECT ContactId, MIN(PhoneNumberId) AS MinPhoneNumberId

FROM PhoneNumber

GROUP BY ContactId

) AS PNMI ON PNMI.ContactId = C.ContactId LEFT JOIN

PhoneNumber PN ON PN.PhoneNumberId = PNMI.MinPhoneNumberId

Podobnú štruktúru mám teraz aj v MS CRM. Lenže MS CRM primárne kľúče nepoužíva Integer ale GUID. A SQL nepodporuje funkciu MIN nad GUID. Takže moje dlhoročné riešenie prestalo fungovať. Našťastie v SQL Server 2005 pribudli novinky, ktoré podobný problém dokážu vyriešiť. A to konkrétne funkcia ROW_NUMBER spolu s PARTITION BY.

WITH IndexedPhoneNumbers (ContactId, Number, RowIndex) AS

(

SELECT ContactId, Number,

ROW_NUMBER() OVER (PARTITION BY ContactId ORDER BY PhoneNumberId) AS RowIndex

FROM PhoneNumber

)

SELECT C.*, IPN.Number

FROM Contact C LEFT JOIN

IndexedPhoneNumbers IPN ON IPN.ContactId = C.ContactId AND IPN.RowIndex = 1

Možno to niekomu pomôže. Možno niekto pozná ešte elegantnejšie riešenie, tak nech ho kľudne pridá do komentárov.

Windows 7 sa začne predávať 22. októbra

duracellko — Wed, 03 Jun 2009 07:01:55 GMT

Táto informácia sama o sebe asi nemá takú vážnosť, aby sa dostala na môj blog. Ale tento krát sa Microsoft trafil do mojich narodenín. Ešte šťastie, že na RC sú celkom dobré ohlasy. Nerád by som bol, keby to bol nejaký nepodarok :)

LINQ 2 SQL, DataLoadOptions a CompiledQuery

duracellko — Wed, 01 Apr 2009 14:15:28 GMT

Len pre obnovenie pamäte DataLoadOptions je trieda, kde sa definuje eager-loading pre LINQ 2 SQL. Použitie je asi nasledovné:

var context = new MyDataContext(connectionString);

var dlo = new DataLoadOptions();

dlo.LoadWith<User>(u => u.Roles);

context.LoadOptions = dlo;

DataLoadOptions má však niekoľko obmedzení.

LoadOptions sa musí nastaviť ešte pred prvým query.
LoadOptions, ani samotný DataLoadOptions objekt sa už nemôžu meniť po spustení prvého query.

Vzhľadom na tieto obmedzenia som nastavovanie LoadOptions dal priamo do konštruktoru triedy MyDataContext. Tu som nastavil eager-loading, ktorý je tipický pre celú aplikáciu. Napríklad pre niektoré entity sa načíta rovno aj ich vlastník a podobne.

Dnes sme riešili performance a niektoré query sa museli predkompilovať.V LINQ 2 SQL na toto slúži trieda CompiledQuery. Použitie je celkom jednoduché:

Func<MyDataContext, int, User> getUser;

getUser = CompiedQuery.Compile((MyDataContext context, int userId) => context.Users.FirstOrDefault(u => u.Id == userId));

var context = new MyDataContext(connectionString);

User user1 = getUser(context, 1);

volanie funkcie getUser trva asi 10tinu času neskompilovaného query.

Lenže tu sme narazili na problém, že pri volaní getUser nad rôznymi inštanciami MyDataContext to hádzalo výnimku “Compiled queries across DataContexts with different LoadOptions not supported.” Z tohoto sú jasné obmedzenia vlastnosti LoadOptions, pretože každá expression sa interne skompiluje.

Naštastie riešenie bolo jednoduché. V statickom konštruktore sa vytvorí jedna inštancia DataLoadOptions a v konštruktore MyDataContext sa do LoadOptions nastaví práve táto jedna inštancia. Keďže sa DataLoadOptions už potom nemení, tak by to malo byť aj thread-safe.

Čo bolo ale zujímavé, že pri tejto implementácii sa čas kompilácie query (myslím bez použitia CompiledQuery) skrátil asi na polovicu.

Applications = Code + Markup

duracellko — Thu, 05 Feb 2009 13:12:46 GMT

Konečne mi dorazila knižka na tému WPF od legendy Charles Petzold. Charles Petzold je expert na vývoj užívateľského rozhrania pod Windows. Čítal som od neho ešte knižku Programming Windows, kde písal o programovaní pod Windows 3.1 v C pomocou WinAPI. To bolo ešte za čias, keď sa ani ináč nedalo, lebo ešte neexistovalo ani MFC ani iné objektové knižnice na WinAPI. Síce som nikdy nenapísal žiadnu Windows aplikáciu v čistom C, ale aspoň som pochopil architektúru Windows UI. Teda hlavne ako funguje posielanie správ oknám a podobne. A tažím z toho do teraz. Aj keď používam .NET Windows Forms API, tak si viem predstaviť, čo sa deje na pozadí.

Keďže WPF je úplne nová architektúra (aspoň tak som to zatiaľ pochopil) a nie len nové objektové rozhranie nad WinAPI, tak som sa rozhodol, že znova siahnem po knižke od svojej legendy, aby mi odhalil túto novú architektúru. Síce WPF už existuje nejaký čas, ale ja som sa k tomu dostal až teraz. Ale veď nikdy nie je neskoro.

Viac info o knižke nájdete na http://www.microsoft.com/learning/en/us/Books/6476.aspx

Anonymní delegáti vo foreach

duracellko — Wed, 22 Oct 2008 11:32:35 GMT

Dnes to budú 2 tipy v jednom článku. Prvý problém je, ako načítať v LINQ 2 SQL asociované kolekcie. Mám entity Customer a Contact. A samozrejme Customer má kolekciu Contacts. A potrebujem v jednej metóde načítať zákazníkov aj s ich kontaktmi. Dá sa na to použiť trieda DataLoadOptions. Asi nasledovne:

var dlo = new DataLoadOptions();

dlo.LoadWith<Customer>(c => c.Contacts);

dataContext.LoadOptions = dlo;

return dataContext.Customers.ToList();

Toto zabezpečí, že v jednom SQL príkaze sa načítajú zákazníci aj ich kontakty. Čiže iba jeden dotaz na databázu, čo je oveľa efektívnejšie ako keby sa pre každého zákazníka nahrávali kontakty pomocou lazy-load metódy. Problém je ale v tom, že kontakty nepotrebujem načítať vždy, ale len v určitej metóde. A vlastnosť LoadOptions má nasledovné obmedzenia:

Ak objekt DataLoadOptions priradím vlastnosti LoadOptions, tak tento objekt nemôžem meniť. To znamená, že nemôžem zavolať metódu LoadWith.
Ak sa na danom DataContext objekte spustilo nejaké query, tak vlastnosť LoadOptions nie je možné zmeniť.

Našťastie kolekcia Contacts má metódu SetSource, čiže kontakty pre zákazníka môžem načítať z ľubovoľného zdroja typu IEnumerable<Contact>. Takže najprv načítam zákazníkov. Potom načítam všetky kontakty týchto zákazníkov do kolekcie List<Contact>. Sú to síce 2 dotazy na databázu namiesto jedného, ale stále je to konštantný počet oproti lineárnemu pri lazy-load. No a potom pre každého zákazníka stačí nastaviť zdroj kontaktov nie z databázy, ale z tohto listu.

/// <summary>

/// Loads the contacts for customers in one SQL statement.

/// </summary>

/// <param name="customers">The customers to load contacts for.</param>

/// <param name="customerQuery">The customer query. If null, then customers are selected from the list.</param>

public void LoadCustomerContacts(IList<Customer> customers, IQueryable<Customer> customerQuery)

{

if (customers == null)

{

throw new ArgumentNullException("customers");

}

IQueryable<Contact> contactsQuery = null;

if (customerQuery != null)

{

contactsQuery = Context.Contacts.Where(c => customerQuery.Any(cus => cus == c.Customer));

}

else

{

int[] customerIds = customers.Select(c => c.Id).ToArray();

contactsQuery = Context.Contacts.Where(c => customerIds.Contains(c.CustomerId));

}

var contacts = contactsQuery.ToList();

foreach (var customer in customers)

{

if (!customer.Contacts.HasLoadedOrAssignedValues)

{

customer.Contacts.SetSource(contacts.Where(c => c.CustomerId == customer.Id));

}

A tu som narazil na problém s anonymným delegátom alebo lambda funkciou vo foreach cykle. Teda sa dostávam k druhému bodu v tomto článku. Keď som túto metódu spustil, tak všetci zákazníci mali rovnakú množinu kontaktov a to boli kontakty posledného zákazníka. Síce som hneď pochopil, v čom je problém, ale aby som ho mohol vysvetliť, tak najprv vysvetlím ako fungujú anonymní delegáti. Lambda funkcia je len iný zápis anonymného delegáta, takže pre ňu to platí rovnako.

Predchádzajúca funkcia sa dá zapísať a preloží sa nasledovne. Najprv sa vygeneruje pomocná trieda, ktorá udržuje stav.

private class DelegateClass

{

public Customer customer;

public bool DelegateMethod(Contact c)

{

return c.CustomerId == customer.Id;

}

Potom sa foreach cyklus preloží nasledovne.

DelegateClass delegateStatus = new DelegateClass();

IEnumerator<Customer> enumerator = customers.GetEnumerator();

enumerator.Reset();

while (enumerator.MoveNext())

{

delegateStatus.customer = enumerator.Current;

if (!delegateStatus.customer.Contacts.HasLoadedOrAssignedValues)

{

delegateStatus.Contacts.SetSource(contacts.Where(delegateStatus.DelegateMethod));

}

Samozrejme, že tento môj preklad je len približný a hlavne som si vymyslel rozumnejšie názvy ako tie, čo generuje C# kompilátor. Ale dôležité je, že objekt typu DelegateClass sa vytvára iba raz pred vykonaním cyklu. Takže na konci majú všetky zdroje kontaktov v podmienke Where odkaz na ten istý objekt DelegateClass a teda toho istého zákazníka. A preto sa vždy načítajú len kontakty posledného zákazníka. Riešením je samozrejme presunúť riadok "DelegateClass delegateStatus = new DelegateClass()" do vnútra cyklu. Takže stačilo prepísať foreach cyklus nasledovne.

foreach (var customer in customers)

{

if (!customer.Contacts.HasLoadedOrAssignedValues)

{

int customerId = customer.Id;

customer.Contacts.SetSource(contacts.Where(c => c.CustomerId == customerId));

}

Alebo druhá možnosť je hneď za SetSource nahrať kolekciu kontaktov.

foreach (var customer in customers)

{

if (!customer.Contacts.HasLoadedOrAssignedValues)

{

customer.Contacts.SetSource(contacts.Where(c => c.CustomerId == customer.Id));

customer.Contacts.Load();

}

Záver je jednoduchý. Pri použití anonymných delegátov v cykle si treba vždy uvedomiť, kde sa vytvára inštancia stavového objektu delegáta. Aby sa nestalo, že rôzni delegáti zdieľajú ten istý stav.

Forms authentication na Reporting Services

duracellko — Fri, 10 Oct 2008 11:45:20 GMT

Mám trochu času, tak sa môžete tešiť z toho, že oživím trochu svoj .NET blog. Tento krát napíšem ako som rozbehával ASP.NET forms authentication na Reporting Services. Toto som síce riešil dávnejšie, ale až teraz som si našiel čas to napísať.

Asi ešte nie som dostatočne google addicted, ale najprv som siahol po MSDN a až potom po google. Na MSDN síce bolo napísané, ktoré interfacy mám implementovať, ale len veľmi stručne tam bolo napísané že ako ich mám implementovať. Teda o niektorých operáciách interfacov som sa viac dozvedel z ich názvu ako zo samotného popisu v MSDN. Takže som prešiel na možnosť B, a teda google. Najlepšie by bolo nájsť článok o tom, ako to už niekto urobil. A aj som našiel. MS na codeplexe zverejňuje všetky oficiálne sample k SQL Server. Čiže je tam možné stiahnuť aj príkladovú databázu AdventureWorks, ktorá bola dodávaná s SQL Server 2005. No a našiel som tam aj sadu príkladov pre Reporting Services a v tejto sade príkladov je aj príklad na forms authentication. Všetko je to na stránke http://www.codeplex.com/MSFTRSProdSamples/ a príklad sa volá Security Extension Sample.

Takže som si daný príklad stiahol, otvoril a spravil svoju vlastnú implementáciu. Tu som si všimol, že kusy kódu, ktoré boli uvedené v MSDN ako príklad, sú vlastne z tohto príkladu. Väčšina práce spočívala v copy&paste. Zmenil som len to, že som použil vlastný membership provider a pri autorizácii je možné v ACL použiť aj rolu, nie len užívateľa. Nasadil som to na Report Server a ono to normálne fungovalo. Ale žiaľ nie až tak normálne. Problém bol v tom, že ak som zadal do prehliadača adresu Report Serveru, tak zobrazenie login stránky trvalo asi 1 minútu. Potom, keď sa užívateľ prihlásil, tak všetko fungovalo tak ako má. Fungovalo nastavovanie práv a bolo to rychle ako Report Server, ktorý používa windows autentifikáciu.

Pozrel som log Report Server a tam boli NullReferenceException. Čo ešte nie je dôvod minútové zdržanie. Potom som pozrel Report Web (teda front-end) log a tam boli time-outy. Tak som zase otvoril svoj obľúbený .NET Reflector a našiel som si funkcie, ktoré boli uvedené v stacku pri výnimkách. A problematická procedúra bola nasledovná. Najprv ešte uvediem implementáciu GetUserInfo operácie v IAuthenticationExtension, ktorá bola použitá v príklade.

public void GetUserInfo(out IIdentity userIdentity, out IntPtr userId)

{

// If the current user identity is not null,

// set the userIdentity parameter to that of the current user

if (HttpContext.Current != null && HttpContext.Current.User != null)

{

userIdentity = HttpContext.Current.User.Identity;

}

else

userIdentity = null;

// initialize a pointer to the current user id to zero

userId = IntPtr.Zero;

}

Užívateľ zobrazí Default.aspx stránku.
Každá stránka v RS front-ende je odvodená od triedy ReportingPage. Na tejto stránke sa odchytí udalosť Init.
V tejto udalosti sa zisťuje, či sa má pre komunikáciu s back-endom použiť SSL alebo nie.
Najprv sa zavolá ListSecureMethods() web metóda na back-ende bez použitia SSL. V konfigurácii som nezapol, že SSL je vynútené.
Na back-ende sa odchytí udalosť HttpApplication.AuthenticateRequest.
V tejto udalosti sa zistí, že sa používa forms authentication a uživateľ nie je prihlásený (HttpContext.Current.User == null), tak sa do response headers pridá položka RSNotAuthenticated.
Ďalej sa v tejto udalosti zavolá GetUserInfo metóda našej authentication extension. Užívateľ ešte nie je prihlásený, takže ako userIdentity vráti null. Lenže ďalej sa volá IIdentity.Name, čo vyvolá NullReferenceException, ktorú som našiel v logu.
Táto výnimka sa pošle na front-end. Pri prijímaní odpovede z back-endu sa nájde v hlavičkách položka RSNotAuthenticated, takže sa do response headers, ktoré pôjdu z front-endu na prehliadač, zapíše, že sa má presmerovať na login page. Ale neukončí sa spracovanie requestu.
Doteraz by všetko ako-tak fungovalo, až na to zapisovanie NullReferenceException do logu. Táto výnimka sa odchytí na front-ende. Ten si myslí, že back-end nekomunikuje na nezabezpečenej linke, tak skúsi zavolať ListSecureMethods() web metódu cez SSL.
30 sekúnd sa čaká.
Potom sa hodí WebException s tým, že nastal time out. Toto sa tiež zapísalo do logu.
Táto výnimka sa odchytila v HttpApplication.Error, kde sa spustí HttpServerUtility.Transfer s tým, že sa spustí Error.aspx. Samozrejme, že aj táto stránka je odvodená od ReportingPage, takže celý cirkus od bodu 2 sa zopakuje. Čo je ďalších 30 sekúnd čakania.
Nakoniec sa na klienta pošle asi stránka, že nastala neočakávaná chyba. Lenže táto sa ani nezobrazí, pretože browser si hneď v hlavičke prečíta, že sa má presmerovať na Login.aspx.

Najprv som si myslel, že sa problém vyrieši, keď sa na web server nainštaluje SSL certifikát. Lenže toto nepomohlo. Možno to nebolo úplne správne nainštalované, lebo ten certifikát samozrejme nebol overený certifikačnou autoritou. Tak som sa rozhodol, že metódu GetUserInfo z príkladu mierne upravím. A to nasledovne:

public const string GuestUserName = "_Guest_";

public void GetUserInfo(out IIdentity userIdentity, out IntPtr userId)

{

if (HttpContext.Current != null && HttpContext.Current.User != null)

{

userIdentity = HttpContext.Current.User.Identity;

}

else

{

userIdentity = new GenericIdentity(GuestUserName);

}

userId = IntPtr.Zero;

}

Potom ešte samozrejme bolo potrebné upraviť AuthorizationExtension tak, že užívateľ _Guest_ má všetko zakázané bez ohľadu na to, čo je v ACL zoznamoch. A minútové čakanie zmizlo :)

Takže ak aj vy budete siahať po príklade na security extension pre Reporting Services, tak si dajte pozor na túto chybu.

Ďalší problém sa vyskytol, keď som na Report Server chcel pristupovať cez SQL Server Management Studio, tak mi stále tvrdil, že som nezadal správne meno alebo heslo. Problém bol v tom, že v našej aplikácii sú uživeteľské mená v tvare domain\username. Samozrejme, že domain nie je NT doména, ale jednoducho užívateľské meno sa skladá z dvoch častí oddelených opačným lomítkom. Lenže SQL Server Management Studio tú časť pred lomítkom zahodí. Teda možno to dáva do parametru domain pri prihlasovaní, ale ten sa pri forms authentication ignoruje. Takže som to vyriešil tak, že moja security extension pracuje s menami v tvare domain/username. Čiže používam normálne lomítko. A vždy pri použití membership providera zamením normálne lomítko za opačné.