P19: to by me zajimalo, na co se musis takhle ucit nemyslny detaily, tohle bych vyresil za par minut s pomoci google (a to sem to v zivote nevidel), prijde mi nesmysl, ze nekdo pozaduje na pohovoru neco takovyho.
nicmene na tvoji otazku. ja sem nasel na googlu tohle
System.Collections.Concurrent Namespace ()
http://msdn.microsoft.com/en-us/library/system.collections.concurrent.aspx
jsou to implementace primo v netu pro thread safe kolekce (mezi nimi je i quene.
ale protoze jsem to nikdy nepotreboval nevim, zda je to best praktices.

Zdravím,

připravuju se na pohovor a našel jsem úlohu v C#:
mám semaphor a queue (nesmím použít žádnou 3rd party library). Mám napsat thread-safe queue, ke které přistupuje několik vláken, které do fronty vkládají a ostatní vlákna z fronty vybírají. Těch co z fronty čtou je o poznání více než těch, co do ní vkládají. Rychlost je hlavní kritérium (jak jinak :D).

Jako pravověrný webař v tom popravdě hodně plavu, napsal jsem tohle, ale nechce se mi věřit, že by to bylo ono, tak jednoduchý:

public void Enqueue(object obj)
{
_semaphore.WaitOne();
_queue.Enqueue(obj);
_semaphore.Release();
}

public object Dequeue()
{
object obj = null;
_semaphore.WaitOne();
obj = _queue.Dequeue();
_semaphore.Release();
return obj;
}
Můžete mě prosím někdo nakopnout správným směrem?

Díky moc

ALIK: To jo. Ale kdyz vemu ten svuj managed kod a zkopiruju ho u projektu WPF do projeku Store, tak mi to v zasade pobezi. Maximalne s nejakejma drobnejma upravama.

TENCOKACISTROMY: Ne, WPF a WinRT má společné jen to, že podporují jazyk XAML (který lidi znají ze Silverlight a WPF, nicméně i u něj se implementace odlišují) pro definici vzhledu a .NET jako "jazyk". Vše ostatní je jiné. Zatímco WPF je implementováno jako nadstavba, WinRT je nativní Win API. Jedná se o další implementaci toho samého, na co je poslední dobou MS odborník - WPF, Silverlight, WinRT sice vypadají, že jsou si podobné, ale jedná se o zcela jinou implementaci (skoro) téhož.

tak ja vsechny kontroly zatim kreslim primo v kodu pomoci drawing context, xaml je pouzit akorat pri nanaseni kontrolu na plochu, ale tam bude casem designer a taky se to bude delat v kodu.

TENCOKACISTROMY: Tak jsem to aspon pochopil.

ALIK: Prave proto mas pouzit WPF - to je "nativni" zpusob jak tam delat UI.

ALIK: Jestli se pro nej rozhodnes (ostatne proc ne, kdyz ti bude stacit), tak nam tu dej vedet jaka s tim byla zkusenost.

TENCOKACISTROMY: Já narážel i na UI. Neboť se jedná o zcela nezávislou separátní implementaci a z WinRT nelze z UI tuším použít nic, co není založeno na WinRT, beru jako reálné riziko, že vizuální WPF komponenty nebudou kompatibilní s RT verzemi.

TENCOKACISTROMY: Jsem si vědom toho, že na Access posledních cca deset let nešáhli a že je na něm vidět, že není vlajkovou lodí, takže se místy chová dosti neohrabaně a z pohledu uživatele nepřívětivě. Dále, že jeho použití je "rozumné" pouze do chvíle, do kdy si projekt vystačí se základním chováním, tj. bez potřeby maker. U zákazníků bez hrozícího potenciálu růstu (dle počtu uživatelů, počítačů a složitosti databáze) to nabízím jako alternativu k plnohodnotné implementaci. Neboť se na trhu vyskytl nový LightSwitch, který na první pohled vykazoval potenciál, vzal jsem ho do úvahy a v rámci ní se obrátil i zde na vás. Díky za názory.

ALIK: V obecnem pripade ne, ale pokud nepouzivas zadny unmanaged zalezitosti, tak neni v zasade zadna prekazka k tomu, aby to nejelo. S tim unamanged mam samozrejme na mysli, ze to nesmi pouzivat ani referencovany assembly apod...

S kompatibilitou s WinRT bych v obecném případě nebyl úplně optimistický, jedná se o zcela oddělenou implementaci. Nicméně aktuální Portable Class Library ve VS 2013 má pro ".NET for Windows Stores" zaškrtávátko.

TENCOKACISTROMY: to si me potesil :)

ALIK: Proti accessu nic nemam, ale ten vyvijeli 10 let, nez vydali verejnou verzi. Pak to dalsich deset let uspesne vylepsovali a byl to sveho casu asi nejlepsi RAD nastroj pro datacentricky aplikace. Od verze XP dal to s nim jde ale z kopce.

Pokud jeho schopnosti staci na tvuj projekt, klidne ho pouzij.

tck: jak je to vubec s portaci na WinRt
delam ted jistou multitouch aplikaci ve wpf, a chtel bych to pak casem mit na tabletech, protoze tam to skutecne ma smysl a samozrejme ty s winrt jsou levnejsi. tak jestli to pude nejak snadno. nepouziva to zadny databaze, je to jen xaml a samozrejme c# ale nic specialniho.

WinForms neuvažuji. Pokud hrubou sílu, tak WPF.

urcite doporucuju vysrat se na winformy, to nema zadnou budoucnost

mimochodem mrkni na tohle
patterns & practices: Prism - Home
http://compositewpf.codeplex.com/

Low Cost jsem myslel třeba "naklikání" v Accessu s tím, že pokud na to nasadí více lidí či si začne vymýšlet, tak tu částku "odepíše" jako náklad na prototyp. Mám několik zákazníků, kteří jsou s naklikáním v Accessu již několik let spokojeni.

Na druhou stranu, zákazník s obratem 50 tisíc měsíčně těžko kývne na řešení na 200 tisíc (čísla jsou jen ilustrační a nemají s diskutovaným zadáním žádnou souvislost). Náklady, se kterými přijdu, prostě musí být přiměřené jeho možnostem.

TENCOKACISTROMY: souhlasim
ale mozna na to co potrebuje by slo vyuzit neco co je levnejsi nebo free (nejsem si jistej jestli neco existuje) a treba casem tam hodit ten tlerik nebo devexpress, to uz by nemel byt problem, pokud bude dusledne dodrzovat mvvm

Ok, díky.

Ad budget, zde jsem vycházel z odhadu částky, kterou zákazník bude ochoten za tu srandu, co si vymyslel, zaplatit, a toho, že v dohledné době pravděpodobně nebudu mít pro ty komponenty jiné využití a tím investici do nich rozložit. Mám v plánu mu nabídnout jedno "low cost" řešení s odpovídajícími omezeními a jedno plnohodnotné, takže možná na ty komponenty přece jen dojde.

Ja osobne bych LightSwitch nepouzil prave kvuli tomu jak to ulehcuje. Dle mej dlouholetejch zkusenosti s temahle ulehcujicima frameworkama od MS to vypada tak, ze jeakmile chces trochu uhnout z cesty, kterou ti pripravili tak stravis mladi nad tim, jak to udelat a jeste to bude fungovat napul.

Jestli se ti nechce morit s WPF, muzes pouzit Winforms - ale ty se postupne stavaji mene a mene podporovane (napr. na WinRT winforms nepustis).

btw. ad budget ... zamyslete se nad tim kolik stoji vase prace a jak dlouho budete delat neco obdobdnyho. Temer vzdycky vyjde nakup tedlech komponent levneji. Zbavte se stigmatu, ze musi byt vsechno inhouse.

Mohu ještě poprosit o důvody, kvůli kterým doporučuješ WPF před LightSwitch, tj. například na čem bych mohl u LightSwitch narazit?

Díval jsem se na ty komponenty DevExpress/Telerik a jsou mimo dostupný budget, takže zatím vyhrává asi ony OData (ještě jsem to ale nestihnul vyzkoušet).

ALIK: Normalne to udelej ve WPF.

Díky ještě jednou.

Omlouvám se, z předchozího příspěvku vypadlo slovo. V prosbě na doporučení technologie jsem měl na mysli technologii na vytvoření UI k databázi, tj. kde bude uživatel vytvářet/editovat/mazat data.

ALIK: My na reporty pouzivame DevExpress XtraReports. Dobry jsou taky reportovaci nastroje od Teleriku. Rozhodne v zadnym pripade nechces pouzivat Crystal Reports. Ty jsou silena hruza. A ActiveReports zaspali dobu.

Díky za rychlé reakce.

Pro úplnost se ještě zeptám, co doporučíte za technologii, která by vytvoření oné zlevnila a zpříjemnila (vyjma hrubé síly s databingingem ve WPF). Mně jako potenciální nástroje napadly jen LightSwitch a Access (z Office).

ALIK: Vyvaruj se snah prinutit uzivatele, aby si udelal vlastni report.
Maximum co ale stejne dokaze min jak 5% uzivatelu je upravit si pripravenej report.

Navrh od H_U_N_T_E_R se mi zda pro praxi docela dobrej.