öt perc dotnet

MS-SQL developer wanted

2010-03-10T22:33:00.004+01:00

Ez úton is köszönöm mindenkinek, aki jelentkezett .NET fejlesztőnek. (tesztelők jelentkezését még mindig várom!)
Ezúttal egy SQL gurut keresek:

SQL Fejlesztő

Legalább 3 év SQL Server / T-SQL fejleszési tapasztalat
Műszaki végzettség
Angol nyelvtudás írásban és szóban
.NET / ASP.NET ismeret előny

A munkavégzés helye Budapest belvárosa.
Jelentkezni a geri@otperc.net címre küldött önéletrajzzal lehet.

Windows 7 multi-monitor trükkök

2010-03-03T10:03:00.003+01:00

Tudta Ön, hogy Windows 7-en, ha több monitort használ, a WIN + SHIFT + Bal / Jobb kurzormozgató kombinációkkal ide-oda lehet dobálni az aktív ablakot a monitorok között?
Én eddig a zseniális UltraMon-t használtam (amit eztán is használni fogok, pl. a multi-taskbar támogatás miatt), de ez elég kényelmes, és out-of-the-box.

Az eredeti forrás (és további hotkey-ek lelőhelye) Bienor blogja.

Megjelent az AppFabric Beta 2

2010-03-02T13:55:00.002+01:00

Nemrégiben írtam az AppFabric-ba integrálódott Velocity-ről. Most ennek az AppFabric-nak jelent meg a második bétája – ez a kiadás támogatja a .NET 4 / Visual Studio 2010 duó Release Candidate verzióját.

A distributed cache vonalon az üzemeltetést könnyítő változásokat találhatunk(event log támogatás, PowerShell cmdletek cluster adminisztáláshoz) , illetve szofisztikáltabbá vált a memória kezelése azokban az esetekben, amikor sokkal több adatot próbálunk a cache-ünkbe gyömöszölni, mint amennyit annak fizikai memóriája elbírna.

Letöltés a http://msdn.microsoft.com/appfabric címről.

Még több .NET fejlesztő kerestetik - Frissítve!

2010-02-23T16:22:00.011+01:00

Újfent .NET fejlesztőt keresek. Nem is csak egyet, sőt, nem is csak egy területre:

ASP.NET Engineer (meglepő módon webes területre)

Legalább 3 év C# / .NET fejleszési tapasztalat
Kliensoldali webes technológiák (HTML, JavaScript, CSS) ismerete
Angol nyelvtudás írásban és szóban
SQL ismeret előny

.NET Developer (tesztelési területre)

Erős C#, .NET Framework (2.0-3.5) ismeretek
SQL ismeretek
Szoftverfejlesztési és -tesztelési módszertanok ismerete
Webes technológiák általános ismerete
Angol nyelvtudás írásban és szóban
Szoftvertesztelési tapasztalat előny
C++ tapasztalat előny

Update! További embereket is keresek, teszt területre. Ez nem annyira .NET, de hátha érdekel valakit... Nagy vonalakban teszt esetek kidolgozásáról és végrehajtásáról, a teszt konfigurációk telepítéséről és karbantartásáról, dokumentálásról szól.

QA Engineer

Az ideális jelölt

néhány év szoftver tesztelési tapasztalat rendelkezik
jó általános informatikai "rálátása" van (szoftverek, rendszerek működése, Windows adminisztráció, hálózati ismeretek)
automatizálási ismeretekkel rendelkezik (scriptelés, programozói tudás)
angol és magyarul egyaránt jól kommunikál írásban és szóban

A munkavégzés helye Budapest belvárosa.
Jelentkezni a geri@otperc.net címre küldött önéletrajzzal lehet.

Szóvégi üres karakterek SQL-ben

2010-02-22T23:56:00.006+01:00

Ebből mi lesz?

-- Nincs space a szavakban
IF 'test' = 'test'
    PRINT 'Igaz'
ELSE
    PRINT 'Hamis'
    

-- Vegyük észre a szó eleji space-t
IF 'test' = ' test'
    PRINT 'Igaz'
ELSE
    PRINT 'Hamis'
    

-- Vegyük észre a szó végi space-t
IF 'test' = 'test '
    PRINT 'Igaz'
ELSE
    PRINT 'Hamis'

Ebből az lesz, hogy:

Igaz Hamis Igaz

Meglepő? Ezért.

Saving changes is not permitted (SQL Server 2008)

2010-02-17T21:57:00.008+01:00

Aki SQL Management Studio 2008-cal dolgozik, az belefuthatott már a jelenségbe, hogy bizonyos táblaséma-módosító műveleteket nem képes a grafikus felületen elvégezni. Például ha egy NULL értéket felvenni képes mezőtől szeretnénk elvenni ezt a képességét, akkor a sémamódosítás helyett jön az ábrán látható dialógus, ami aztán a "User canceled out of save dialog (MS Visual Database Tools)" című üzenetbe, majd az addigi módosításaink elvesztésébe torkollnak.

Ezzel azért örvendeztet meg minket a Management Studio, hogy emlékeztessen: ami a felületről 1-2 kattintás, az a rideg valóságban nem mindig olyan egyszerű. Az alábbi séma-módosító műveletek végrehajtása nem triviális:

Új mező beszúrása létező oszlopok közé
Oszlop törlése
NULL érték engedélyezése/tiltása
Oszlop adattípusának megváltoztatása
Oszlopok sorrendjének megváltoztatása

A végrehajtásuk annyira nem triviális, hogy igazából lehetetlen - az, hogy mégis elvégezhetők, annak köszönhető, hogy a Management Studio a háttérben egy ügyes scriptet generál és futtat. A script egy új táblát hoz létre a kívánt sámával, majd átbűvészkedi bele a régi táblában található adatainkat. Innentől az már csak névdonornak kell: eldobásra kerül, az újonnan létrejött tábla pedig felveszi a személyazonosságát. Pont olyan, mintha.
A GUI felől ebből semmi nem látszik, egy esetet kivéve: ha egy éles, terhelés alatt álló adatbázis sok rekordot tartalmazó tábláján machinálunk, mert azt tuti észre lehet majd venni a GUI felől is. Csak nem afelől a GUI felől, amelyik felől mi szeretnénk.

Ezt a működést hívhatjuk mondjuk "üzemeltető-barát" beállításnak (nehezebb nagy hülyeséget csinálni), fejlesztési időben viszont mezők jönnek-mennek, közelező adatokról derül ki, hogy nem mindig ismertek, és más anomáliák is gyakran történnek - tehát jól esne, ha nem szopatna minket még a Management Studio is.
Szerencsére néhány (hat) kattintással "fejlesző-baráttá" tehető a működés: a Tools -> Options -> Designers -> Table and Database Designers fülön a Prevent saving changes that require table re-creation opció elől ki vell venni a pipát: Így már vidáman módosíthatunk a sémánkon. Érdemes néha a Generate Change Script gombra is rábökni, hogy miket gépel helyettünk össze a Management Studio. Köszönjük!

Windows 7 (vs. VS)

2010-02-16T17:53:00.003+01:00

A Windows 7 ezzel sokkol mostanában (mióta felkerült a Visual Studio 2010 RC). Van 3 Gibi RAM-om (igazából 4, de a 32 bites OS abból valamivel több, mint 3-at lát).

Elismerem, lehet olyan szituáció, amikor hasznos, hogy szól, hogy közel a vég - de nálam a devenv.exe 284 MB-ot eszik, ami ugyan nem kevés, de még mindig kevesebb, mint tizede az összes memóriának.
1.5G cache mellett is van még 800 mega szabad RAM-om.

Szerencsére (kis registry trükközéssel) kikapcsolható a dolog: Disabling the “Your computer is low on memory” and “Close programs to prevent information loss” dialogs.
Peace!

Senior .NET fejlesztő kerestetik

2010-02-15T07:20:00.005+01:00

Szolgálati közlemény: webes területen tapasztalt .NET fejlesztő kerestetik, .NET 3.5 / C# 3.0+, ASP.NET (MVC és/vagy WebForms, Web Services), verziókezelő-rendszer használati tapasztalattal.
Bővebb információ, kapcsolat: http://ssp.cloudapp.net/dotnet.

ASP.NET 4.0 Request Validation

2010-02-14T23:10:00.004+01:00

Történt, hogy a Moxicode TinyMCE editor-ját szerettem volna használni egy MVC alkalmazásban - a válaszott platform és az IDE pedig természetesen mi más is lehetett volna, mint a .NET Framework 4.0 RC, illetve a Visual Studio 2010 RC.

Némi plumbing kód megírása után az elgondolás életre is kelt és prímán működött - egészen az első POST-ig, amiután a "System.Web. HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client (form-elem-neve="veszélyes-dolgok-pl-html")." üzenettel elragadott a Sárga Halál. Hát, persze, ilyesmit nem lehet POST-olni, mert a HTTP request validációja során az ASP.NET motor megtagadja a kérés viszolgálását, ha valami potenciálisan veszélyeset (pl. HTML kódot) talál a POST-olt értékek közt. Ki kell kapcsolni a validációt az adott oldalra.

Mi sem egyszerűbb ennél, az .aspx oldalunk @Page direktívájánál megmondjuk, hogy ValidateRequest="false", és kész is vagyunk. Illetve lennénk, ha ez egy WebForms alkalmazás lenne. Az MVC applikációnkat teljes mértékben hidegen hagyja ez a beállítás, és továbbra is validál. Kis keresés, és halleluja: az MVC motor máshol validál, mint a WebForms, itt a Controller feladata a validálás, és az Action-ökre rakott [ValidateInput] attribútummal szabályozhatjuk, hogy szeretnénk-e validálást, vagy sem. Editálás esetén nem akartam:

[ValidateInput(false)]
public ActionResult Edit(string id)
{
    return View();
}

Egyszerű - viszont ugyanúgy nem működött, mint az előző megközelítés. Itt már hosszabb és keservesebb nyomozás következett, de végül meglett az ok: ASP.NET 4.0 Beta 2-től megváltozott a default request-validálási módszer, már a BeginRequest alatt megtörténik. A változtatás azt célozza, hogy a request validation áldásos tevékenységét ne csak .aspx oldalakon, hanem webservice híváson, handlereken, egyebeken is élvezhessük.
Hogy ezt az új fajta validációt hogy lehet kikapcsolni, nem tudom; de vissza lehet térni a "régihez", ami tiszteletben tartja a direktívákat és attribútumokat, mindössze egy sort kell elhelyeznünk a Web.configunkban:

<httpRuntime requestValidationMode="2.0" />

Szintén 4.0-ás újdonság, hogy saját validátort is készíthetünk, amit szintén a httpRuntime elem attribútumaként adhatunk meg:

<httpRuntime requestValidationType="MyValidator, MyAssembly" />

Végezetül, ha kikapcsoljuk a "gyári" validációt, ne feledkezzünk meg helyette saját ellenőrző kódokat beépíteni.
Boldog Validálást!

flee - Fast Lightweight Expression Evaluator

2010-02-12T11:25:00.001+01:00

A flee (Fast Lightweight Expression Evaluator) pont az, ami a neve. Egy gyors, pehelysúlyú kifejezés kiértékelő - aki dolgozott már LINQ Dynamic Query Library-vel, annak nagyjából érthető miről van szó. Erről:

static void Main(string[] args)
{
    var ctx = new ExpressionContext();
    ctx.Variables.Add("now", DateTime.Now);
    var expression = ctx.CompileGeneric<string>("now.ToString(\"yyyy-MMMM-dd (dddd)\").ToUpper()");
    var result = expression.Evaluate();
    Console.WriteLine(result); // Output: "2010-FEBRUÁR-12 (PÉNTEK)"
}

Azaz egy sztring-kifejezésből, mint pl. a "sqrt(a^2 + b^2)" vagy a "now.ToString("yyyy-MMMM-dd (dddd)").ToUpper()" képes IL kódot előállítani. A kifejezésünk nyelve kicsit C#, kicsit VB, erősen típusos, de nem case sensitive...

A flee LGPL licencelésű, ami praktikusan azt jelenti, hogy ha (az egyébként letölthető) forráskódján nem módosít az ember, csak a lefordított assemblyt referenciálja, akkor szabadon használható akár nyílt, akár zárt, non-profit vagy for-profit feljesztésekben egyaránt.

Process Monitor vs. Visual Studio 2010

2010-02-11T11:33:00.002+01:00

Természetesen engem sem hagyott hidegen a Visual Studio 2010 kiadásra jelölt verziójának megjelenése. A letöltés gyorsan megvolt, az telepítéshez azonban el kellett távolítani az előző, Beta 2-es verziót – az upgrade lehetőség hiánya megszokott a beta vagy CTP jelölésű termékeknél. Nosza, uninstalláljunk!

Control Panel, Programs and Features, VS 2010, remove. A fenti állapotig sikerült eljutni körülbelül 1 perc alatt, aztán vége. Vártam 10 percet, hátha lesz valami, de nem. Hát jó, akkor elő kell venni a sok éves szakmai tapasztalatot és profizmust: ezt bizony újra köll indítani!

Sajnos a csodafegyver nem segített. Ugyanebbe az állapotba jutottunk. Ide finomabb műszerek fognak kelleni!

Az feltűnt, hogy az alkalmazás nem fagy le a szó klasszikus értemében: valószínű mindenki ismeri a “nem válaszol” állapotot, amikor se kép, se hang. Na, itt nem ez volt: ez valamit molyolhat a háttében, de se a procit nem tekeri, se a memóriát nem zabálja, se őrületes I/O-t nem produkál a Task Manager szerint.

Meg kéne tudni, mivel molyol az alkalmazás. Erre kiváló eszköz a Sysinternals utilitik közül a Process Monitor. A mellékelt képen látszik, hogy a setup.exe valamiért szerelembe esett a Z: meghajtómmal, és mindenféle temp fileokat pakol oda. A dolog szépséghibája, hogy az én Z:-m egy WebDav-on keresztül hálózati meghajtóként felmappelt dokumentumtár, ami sok mindenre jó, speciel nagy mennyiségű, relative kis fájl tömeges, gyors létrehozására, olvasására, törlésére teljes mértékben alkalmatlan.

Az igazi vicc, hogy amolyan harctéri sebész módjára szépen lecsatoltam a Z: meghajtóm – a setup.exe leállítása nélkül. Az még kicsit próbálkozott, aztán mikor belátta, hogy volt zé, nincs zé, szó nélkül továbbfutott, és néhány perc alatt eltakarította a Visual Studio 2010 Beta 2-t.

Remélem így én is hamarosan csatlakozhatok az RC sebességéről, stabilitásáról áradozók egyre népesebb csoportjához! :)

Tuple

2010-02-09T15:41:00.002+01:00

- Mit tettek értünk a ró redmondiak? Semmit!
- Visual Studio 2010 Relase Candidate!
- Mit?
- VS2010 RC.
- Ó, igen, ezt ők adták, ez igaz.
- És variancia-támogatást a nyelvbe.
- Igen, relase candidate-et, és variancia támogatást, igen, de ezektől eltekintve...
- Az AppFabricot!
- Jól van, de eltekintve a release candide-től, a variancia-támogatástól, az AppFabrictól, a dinamikus nyelvek támogatásától, az újraírt workflowtól eltekintve... mit adtak nekünk a róredmondiak?

Hát a Tuple-t.
A tuple egy olyan adatszerkezet, ami több, különböző típusú "al-elemet" fog össze. Kb. mint egy tömb, aminek mindegyik eleme más-más típusú lehet.

Képzeljük el, hogy egy metódusban vissza kell adnunk egy string-et és egy int-et. Több lehetőségünk is van, pl. string visszatérési érték + 1 out int paraméter használata, vagy egy egyszerű, "adathordozó" oszály legyártása, ami pont egy string-et és egy int-et tud getelni-setelni. Lehetőleg inkább csak getelni, setelni csak a létrehozásakor. Na a Tuple pont ez utóbbit tudja.

A Tuple egy generikus adatszerkezet, ami a generikus típusparamétereinek megfelelő adatokat tudja tárolni. Az adattagokat csak létrehozáskor lehet beállítani, a tuple példány életciklusában később már csak getelni lehet az tuple által biztosított Item1, Item2, Itemn propertyken keresztül. Mivel ez legalább olyan érthetetlen lett, mint a többi magyarázatom, jöjjön a példa:

var tuple = new Tuple<string, string, int>("otperc", ".net", 42);
string s1 = tuple.Item1;
string s2 = tuple.Item2;
int i = tuple.Item3;

Még elegánsabb, ha a Tuple.Create() statikus metódussal gyártjuk le a Tuple példányunkat, ekkor ugyanis a fordító képes a generikus típusparamétereket a metódushívás paramétereinek típusából kiinferálni. Magyarul, nem kell kiírni a kacsacsőrös rész:

var tuple = Tuple.Create("otperc", ".net", 42);

Ennyi. Nem rakétatudomány, de hasznos kis tool.

Visual Studio 2010 Sexy Edition

2010-01-15T19:00:00.002+01:00

A közelgő Visual Studio 2010 releassel kapcsolatban egy érdekes pletyka szivárgott ki a napokban a Microsofttól. A szoftverfejlesztő keretrendszernek egy speciális kiadása is elérhetővé válik majd 2010 április 12.-én: a Visual Studio Sexy Edition. A programról a splash screen mellett néhány technikai információ is napvilágot látott.

A kiadás érdekessége, hogy a már megszokott programnyelveket - a C#-ot, illetve Visual Basic .NET-et - nem támogatja a kiadás, és az újdonságként érkező F# nyelven sem tudunk alkalmazásokat fejleszteni segítségével, mindössze egyetlen programnyelvet, az abszolút újdonságként debütáló L#-ot fogja támogatni.

A Comenius Logo fejlesztői közösség máris azzal vádolja a redmondiakat, hogy az L# tulajdonképpen egy nagy nyúlás, egy az egybe' a logóról, mindössze a bonyolultabb nyelvi elemeket hagyták el. Egyesek jogi lépéseket, mások öri harit fontolgatnak.
A LOLCODE fejlesztők viszont üdvözölték az újonnan megjelenő lehetőséget, mert bár .NET LOLCODE compiler eddig is létezett, de most végre ők is a .NET ecosystem first class citizenjei lehetnek - igaz, ehhez egy új nyelvet kell elsajátítaniuk. Szerencsére ebben segít a közeljövőben megjelenő Teach yourself L# in one hour (including a 10 minutes long coffee break) című könyv.

Enum.TryParse

2010-01-08T16:20:00.001+01:00

Tegyük fel, hogy van egy ilyen enumerációnk:

enum Fruit
{
    Apple,
    Pear,
    Grape
}

Amennyiben valahonnan egy ilyen enum értéket sztringként kaptunk meg (tehát pl. volt egy olyan sztringünk, hogy "Apple"), és azt szerettük volna a konkrét enum értékke alakítani, az Enum.Parse() statikus metódushoz fordulhattunk segítségért:

public static void ParseEnum(string fruitName)
{
    Fruit fruit = default(Fruit);
    bool parsingSuccesful;

    try
    {
        fruit = (Fruit)Enum.Parse(typeof(Fruit), fruitName);
        parsingSuccesful = true;
    }
    catch (ArgumentException)
    {
        parsingSuccesful = false;
    }

    if (parsingSuccesful)
    {
        Console.WriteLine("Enum parsed succesfully, value: {0}.", fruit);
    }
    else
    {
        Console.WriteLine("Enum couldn't be parsed.");
    }
}

Működni működik, de elég cifra kód. A Framework 4.0 Base Class Library-jében kapunk egy új, generikus metódust, a TryParse(), amivel jóval egyszerűbbé és érthetőbbé válik a kód:

public static void ParseEnum40(string fruitName)
{
    Fruit fruit;

    if (Enum.TryParse(fruitName, out fruit))
    {
        Console.WriteLine("Enum parsed succesfully, value: {0}.", fruit);
    }
    else
    {
        Console.WriteLine("Enum couldn't be parsed.");
    }
}

Külön szépség, hogy bár az Enum.TryParse() egy generikus metódus (tehát valójában az Enum.TryParse<Fruit>()-ot hívjuk), de a típusparamétert - mivel az ugyanaz, mint a második függvényparaméter, az out fruit típusa -, nem kell kiírnunk, a fordító kiinferálja nekünk.

Mindennek ellenére, hogy most már ilyen rettenetesen könnyű és szép enumokkal dolgozni, azért azt tartsuk észben, hogy az enum-sztring konverzió elég lassúcska, teljesítményérzékeny alkalmazásokban néha rá kell programoznunk, ha nem akarunk odaborostásodni a gép elé.

.NET Framework 4 poszter

2010-01-07T15:23:00.004+01:00

A "fejlesztői poszterek" az internet feltalálása óta valószínűleg a világ leghaszontalanabb dolgai közé számítanak, ennek ellenére szeretjük őket.
Egy fejlesztői szoba osztályokat ábrázoló poszterek nélkül olyan, mint egy lakatosműhely Samantha Fox poszter nélkül: jó, jó, de nem igazán kelt professzionális hatást.

A Framework 4.0-ás verziójának közelgő megjelenésével egyúttal a szabad falfelületek további apadására is lehet számítani: NETFX4-Poster.pdf!

Miért pont 1753-01-01?

2010-01-06T18:24:00.006+01:00

Vajon miért pont 1753 január 1. a legkorábbi dátum, amit az SQL Server a datetime típusban tárolni képes? For some historical reasons - jelen esetben szó szerint.

Bár az embernek könnyen úgy tűnhet, hogy az, hogy mi most 2010-et írunk, valami egyetemleges reprezentációja az idő múlásának, igazából számos naptár-rendszer létezett, és létezik ma is (az ortodox zsidók szerint pl. most 5770 van).
Európa nagy részén már a mai időszámítás kezdetétől a Juliánusz-naptárat használták, ami körülbelül ugyanaz, mint a ma is használatos naptár, leszámítva, hogy nincsenek benne szökőévek. (update: Voltak benne szökőévek - pont az volt a baj, hogy túl sok. A Julián-naptár éve mintegy 11 perccel hosszabb, mint a tropikus év.) Emiatt viszont lassan "csúszkálni" kezdtek az évszakok, ami nem volt túl kellemes. A tarthatatlan helyzetet megoldandó, XIII. Gergely pápa kidolgozta a Gregorián- (Gergely-) naptárat, amiben egyrész már voltak szökőnapok, másrészt a bevezetésének volt egy kis trükkje, mert az addig összeszedett csúszást át kellett "időugrani".

Nem is volt zökkenőmentes a bevezetés, az országok szinte egyenként vezették csak be. Az angolszász világ pl. 1752 szeptember 4.-én - másnap már egy szép őszi szeptember 14 virradt rájuk. Az 1752 szeptember 14 előtti dátumok kezelése így több szempontból is problémás: egyrészt a hiányzó 10 nap miatt, másrészt kultúrától függően mást-mást jelent egy dátum, meg aztán az se világos, hogy előtte akkor kell-e számolni a szökőévekkel, vagy sem...

A SQL Server fejlesztő a ~~Microso~~ Sybase-nél pedig egy huszárvágással letudták a nehézségeket: nem kezelnek 1753 előtti dátumokat.

Persze voltak államok, ahol még ennél is később vezették be a Gergely-naptárat, a nagy Szovjetúnióban pl. csak az első világháború után - nem véletlenül volt a Nagy Októberi Szocialista Forradalom évfordulója november 7.-én...
By the way, azt tudják, hogy miért 31 napos július meg augusztus is, miközben a február meg ilyen rövidke? Hát mert augusztust Augustus császárról nevezték el, egészen konkrétan ő maga nevezte át a nyilvánvalóan sokkal bénább Sextilius (update: helyesen: Sextilis) névről - viszont ez a hónap csak 30 napos volt, szemben a Julius caesarról elnevezett szomszéd Júliussal, ami meg 31, úgyhogy az amúgy is kicsit rövidebbre sikerült februárból (annak már úgy is mindegy) egy nap le lett csípve, és ~~Sextil~~ augusztushoz adva. Hiába, no, a szerénység gyakran együtt jár az ilyen pozíciókkal!

Klasszikus (módú) szívás

2010-01-04T15:59:00.006+01:00

Ha egy webalkalmazásunkban szeretnénk a HTTP response-hoz saját header érték(ek)et fűzni, kézenfekvő(nek tűnik) a megoldás: elérjük a HttpResponse példányunkat, azon van egy Headers kollekció, annak meg van Add metódusa:

Response.Headers.Add("MyHeaderInfo", "XY");

Erre IIS 5 / 6 / 7 Classic Mode alatt egy PlatformNotSupportedException-t kapunk, merthogy "This operation requires IIS integrated pipeline mode.". Mifene, classic módban nem tudunk headereket hozzáadni a response-hoz? Természetesen de, csak másképp:

Response.AddHeader("MyHeaderInfo", "XY");

Vagy használhatjuk az AppendHeader() metódust is, pont ugyanazt csinálja, mint az AddHeader (az AddHeader valójában egyszerűen csak továbbhív az AppendHeaderre, ami a valódi mágiát csinálja, érdemes megreflektorozni).

Community Powa

2009-12-26T14:27:00.006+01:00

Kerestem fülbe dugható fülhallgatót. Szerencse, hogy az Interneten számos ár-összehasonlító oldal létezik, így a keresgélés jóval egyszerűbb - ráadásul a legtöbb helyen pontozni, kommentezni is lehet az egyes termékeket, így már vásárlás előtt teljes képet kaphat a megvásárolni kívánt portákáról. Találtam is egy elég szimpatikus darabot, a Sennheiser CX 300-as modelljét, nézzük, mit írnak róla!

"Ma vettem és elsőre letaglózott. ...10-es skálán 8-ast adnék neki, de így 5-ös skálán legyen 5-ös. Jó érték-arány, professzionális hangzás. Csak ajánlani tudom!"

Na, hát ez kiváló, bár a 10-es skálán 8-as eredményt ötös skálán ötössé konvertálni elég furcsa, lehet, hogy inkább egy másik értékelő véleményére kéne hallgatni. Nézzük mit ír a következő!

"Egy olcsóbb Panasonic inear-t szerettem volna leváltani vele. Nem sikerült. Annak ellenére, hogy Sennheiser, a hangja borzalmas, egyszerűen sérti a fület. Mindenféle EQ beállítással kipróbáltam, de egyik sem jött be. A közepei üvöltenek, a magas is sok, mélye pedig egyáltalán nincs. Nagyot csalódtam a gyártóban."

Ajaj, hát ezek szerint ez mégsem annyira tökéletes. De várjunk csak, nézzük mit írnak még:

"A legjobb! Ez előtt kb. 20-30 fülest kipróbáltam, de egyik se váltotta be a hozzá fűzött reményeket... Már fél éve használom a CX300-at és bátran kijelenthetem, hogy ez a legjobb ár/érték téren. Gyönyörűen szól! A 25Hz-es szinuszhullámtól, amit ráadtam, azt hittem, hogy fölrobbantja a fejem."

Hát akkor mégis elég jó lehet, bár itt megint számolni azoknak az embereknek a beszámíthatósági faktorával, akik 25Hz-es szinuszt hallgatnak.
Jobb lenne valami zenei műveltséggel bíró személy tapasztalataira... de hoppá, hát itt van!

"zenélek már 16 éve,és ugyan abszolút hallásom nincs,de tökéletes zenei relatív hallásom van,ilyen képességek birtokába mondom erről a fülesről hogy egy minőségi darab.csak akik a sok rosszon éltek előtte,azoknak ez most túl erős /gyenge lehet attól függ ogy előtte milyen fülesük volt. érdemes az eq-val próbálkozni,kiválló hangzást lehet elérni vele."

Na, hát jó ez az írástudók szerint is. Akkor most már biztos, hogy jó lesz. Na még egy véleményt elolvasok...

"Egyszerüen nem szól tisztán. Kár, hogy megvettem. Kásás és a magas az szörnyű. Próba kell mindenképpen mielött megveszed, mert ha valaki erre 16 év zenélés után rámondja, hogy minőségi, akkor tényleg megosztja rendesen az embereket. Az ilyen vélemény maximum egy utalás arra aki zenéhez értőnek tartja magát."

Hajjaj, akkor most mégsem?

"Kitűnő hangzás, kitűnő dinamika, kitűnő kivitelezés! Ezzel lehetne jellemezni a CX300-at! Bődületesen jól szól! Mindenkinek csak ajánlani tudom!"

De, jó ez, kitűnő!

"Nulla a cucc! Sajnálom, hogy megvettem. Ami ebből szól, azt ne nevezzük hangzásnak."

Jajj, nem. Mégsem. Vagy...?

"A Sennheiser cx300 a legjobb ami valaha a fülemben volt!!! Leginkább a munkahelyemen használom a fülest, hogy "gyorsabban teljen az idő"."

Na, akkor most jó ez...

"Egy hifi üzletben volt lehetőségem vásárlás előtt meghallgatni. Ezek után a vásárlás elmaradt!"

Nem, mégsem, vagy...?

És így tovább, a végtelenségig. Műértők szakvéleményei, majd a műértők hozzá nem értését leleplező műértő írások, szépen, sorban, egymás alatt, a személyeskedő anyázás határmezsgyéjét még épp át nem lépve (amivel ez a fórum egyébként a kultúráltabbak közé pozícionálódik).
Ráadásul a kis füldugasz ára elég szép szórást mutat, 6.734 Ft-tól kerek 12.000 Ft-ig kapható, ami a következő, a széles nyilvánosság számára elérhető felületeken óhatatlanul felbukkanó kaszt, a beavatottak számára olyan magas labda, amit nem lehet nem lecsapni. Megtudhatjuk, hogy ezt a modellt hamisítják, sok helyen a boltokban is hamisítványt kapni, 8000 alatt biztos, afölött meg ki tudja, hát ki, ki más tudná, mint a nagybetűs FÓRUMOZÓ, csak szét kell bontani a borítást, és lesz ott egy szám, ami ha négyessel kezdődik, akkor eredeti, ha hatos, akkor hamis, és mint ilyen, kerülendő, sz*r, értéktelen szemét.

Végül az lett, hogy legutóbb, mikor a szokásos ünnepek előtti nagybevásárlást intéztem egy hyperben (fel kellett tölteni az égetettszesz-készleteket), leakasztottam a szögről egy Panasonic fülest, 1990 Ft, nem egy audiophile cucc, de a célnak megfelel, az Asian Dub Foundation egész meggyőzően dörren meg rajta reggel a négyeshatoson.
Mi lett volna velem a Közösség nélkül? Valószínű egy háromszor (esetleg négyszer, ötször, vagy hatszor) ilyen drága fülest tömködnék reggelente a fülembe, aztán gondolkozhatnék erősen, hogy most amit hallok, az tetszik-e nekem, vagy sem.

Community power, köszönöm!

Kovariancia és kontravariancia C# 4.0-ban

2009-12-18T14:42:00.002+01:00

Miről beszélünk?

C#-ban egy referencia típusú változó mindig a saját típusára, vagy az abból leszármazott típusra mutathat. Ez teljesen transzparens, amikor egy object referencián meghívsz egy metódust, mindegy, hogy a referencia tényleg egy object-re, string-re, Kiskutya-ra mutat-e. Ezzel valószínűleg mindenki találkozott már az első "Objektum-orientált programozás" órán, valamint azóta kb. egycsilliárdszor.
Nevezzük ezt mondjuk "egyes számú szabály"-nak.

Ha két típust (mondjuk T-t és U-t) egymáshoz hasonlítunk, az alábbi négy lehetőségből pontosan egy lesz igaz:

T nagyobb, mint U (OOP terminológiával: T őse U-nak - a System.Object őse a System.String-nek, tehát az object nagyobb, mint a string)
T kisebb, mint U (OOP terminológiával: T leszármazottja U-nak - a System.String a System.Object leszármazottja, tehát a string kisebb, mint az object)
T egyenlő U-val (OOP terminológiával: T és U ugyanaz a típus)
T-nek nincs kapcsolata U-val (OOP terminológiával: navajon?)

Vegyünk egy műveletet, ami a típusokkal mókol valamit, egy adott típusból egy másikat csinál valamilyen szabály alapján: T-ból T'-t, U-ból U'-t.

Hogyha a T' ugyanolyan relációban lesz U'-vel (a fenti négyből), mint T volt U-val, akkor a művelet kovariáns. Ha a művelet megfordítja a relációt (pontosabban: a kisebbséget-nagyobbságot megfordítja, az egyenlőséget és a "közömbösséget" változatlanul hagyja), akkor a művelet kontravariáns.

Érthetetlen, ugye? Nézzünk egy példát!

Adott két típus, mondjuk a System.Object és a System.String (közülük az object a "nagyobb"). Most vegyünk egy "műveletet", ami csinál valamit a típusokkal. Ilyen művelet például a "képezzünk T tömböt", vagy a "képezzünk T listát". Lesz tehát object[] (aka. T'), string[] (aka. U'), List<object> (legyen mondjuk T''), List<string> (logikusan U'') típusunk.

Milyen viszonban vannak ezek a típusok egymással? Az object[] nagyobb, mint a string[]? Hát nézzük meg, az egyes számú szabály értelmében, ha az, akkor értékül lehet neki adni:

// C# 1.0 kód
string[] stringArray = new string[] { "http://", "otperc", ".net" };
object[] objectArray = stringArray;

A C#-ban a tömbképzés már a nyelv legelső verziója óta kovariáns.

És a List<string> castolható List<object>-té?

// C# 2.0 kód
var stringList = new List<string> { "http://", "otperc", ".net" };
var objectList = (List<object>)stringList; // ez nem fordul!

Erre bizony még a nyelv 3.0-ás változatában is egy "Cannot convert type 'System.Collections.Generic.List<string>' to 'System.Collections.Generic.List<object>'" a fordító válasza.

Veszélyes utakon

De vajon ha a tömböknél meg tudták oldani a dolgot már az 1.0-ban, akkor miért nem ment a genericnél a másodiknál? Eric Lippert azt mondja erről: "az a mód, ahogy a C# támogatja a tömböknél a kovarianciát, broken.
Azért került be a CLR-be, mert a CLR tervezői képessé akarták tenni azt a Java(-szerű) nyelvek támogatására, és ehhez szükség volt rá. Aztán mi beraktuk a C#-ba, ha már a CLR-ben bent volt. Sokat vitatkoztunk ezen a döntésen, és ma már nem örülök neki túlságosan, hogy így alakult, de most már nem sok mindent tudunk csinálni."

Miről beszél Lippert? Lássunk egy példakódot:

private static void GetDataMethod(object[] objectArrayParam)
{
    foreach (var item in objectArrayParam)
    {
        Console.WriteLine(item);
    }
}

private static void SetDataMethod(object[] objectArrayParam)
{
    objectArrayParam[0] = new object();
}

static void Main(string[] args)
{
    string[] stringArray = new string[] { "http://", "otperc", ".net" };
    object[] objectArray = stringArray;

    GetDataMethod(objectArray);
    SetDataMethod(objectArray);
}

Az első metódus lefut, de a második futtatásakor egy "ArrayTypeMismatchException: Attempted to access an element as a type incompatible with the array." üzenetet kapunk. A hangsúly a futtatásakoron van: sikerült egy erősen típusos nyelvbe egy olyan konstrukciót beemelni, ami remek lehetőséget ad a compile-time típusbiztosság-ellenőrzés kikerülésére - amivel pedig megnyílnak a pokol kapui.

A helyes út

A C# 2.0-tól van olyan variancia-támogatás is a nyelvben, ami nem “broken”, méghozzá a generikus delegate-ek:

private static string GetString()
{
    return "http://otperc.net";
}

static void Main(string[] args)
{
    Func<object> functionThatReturnsObject;
    functionThatReturnsObject = GetString;
    object o = functionThatReturnsObject();
}

A Func<T> egy T típust visszaadó metódust reprezentál - tehát a Func<object> egy olyat, ami object-et ad vissza. Ez a "metódusreferencia" bátran mutathat olyan metódusra, ami string-et ad vissza. Mi baj lehet? Semmi. A hívó ugy is object-et vár, nem érheti meglepetés. Bármi olyanra mutathatunk, ami specializáltabb, mint mi (az object-es példa esetében praktikusan bármire). Visszafele viszont nem megy a dolog, ha a hívó string-et vár, nem adhatunk object-et.

A generikus delegate-ek a castolása visszaadott típusokra nézve kovariáns.

Nézzük a másik esetet, mikor a típusparaméter nem a visszaadott típust, hanem a paraméter típusát mondja meg. Az Action<T> delegate egy visszatérési érték nélküli, egy T típusú paramétert váró metódust reprezentál. Ha egy metódus mondjuk object-et vár, bátran elérhetjük egy olyan Action-ön keresztül, ami string-et (vagy bármi már specializáltabbat) vár, mert az "alatta lévő", object-et váró metódus simán meg fogja enni:

private static void ConsumeObject(object obj)
{
    Console.WriteLine(obj);
}

static void Main(string[] args)
{
    Action<string> methodThatConsumesString = ConsumeObject;
    methodThatConsumesString("http://otperc.net");
}

A generikus delegate-ek castolása a paraméterek típusára nézve kontravariáns - a típusbiztosság pedig mindkét esetben compile-time ellenőrzött.

Variancia a C# 4.0-ban

Eddig láttunk példát a kontra- és kovarianciára is, annak jó és kevésbé jó implementációjára tömböknél, delegate-eknél. Egy valamit nem láttunk általános generikus típusoknál, pl. egy List<T>-nél a variancia használatára. Azért nem láttunk, mert nincs. C# 3.0-ig nem volt lehetőségünk mondjuk egy List<string>-et List<object>-té castolni - C# 4.0-tól majd lesz. Bizonyos esetekben.

Nem meglepő, hogy ezt a fajta támogatást a nyelvbe "nem-broken" módon igyekeznek behozni - a klasszikus kecskés-káposztás felállásban, miszerint használhassunk kontra- vagy kovariáns hozzárendeléseket ott, ahol azok működőképesek és hasznosak, de maradjon meg a fordításidejű típusbiztosság-ellenőrzés is. Hogy tudjuk szétszeparálni az működő eseteket a nem-működőktől? Nézzük meg újra a legelső példakódunkat:

GetDataMethod(objectArray); // ez a metódus lefut
SetDataMethod(objectArray); // ez ArrayTypeMismatchException-t dob

Miért tud futni az első, és miért nem a második? Mi a különbség?
Mondjuk első közelítésben az "adatáramlás iránya". Az elsőben csak iterálunk, "kiveszünk" adatokat, míg a másodikban "berakni" próbálunk.

A delegate-es példánál is, a visszatérési érték típusa ("kimenő irány") kovariáns - ami X típust ad vissza, az visszaadhat X-et, vagy bármi specializáltabbat. A másik irányba meg fordítva.

A C# 4.0-ba két új kulcsszó került be a variancia támogatására: az in és az out varianciamódosítót (jó, egyikük kulcsszó-pályafutásának sem ez a kezdete, de ez most egy új szerepkör). Ezzel a két kulcsszóval generikus interface-ek típusparamétereit jelölhetjük meg, mint "bemeneti" (kontravariáns) vagy "kimeneti" (kovariáns) paraméter.

Egy példa talán érthetőbbé teszi a dolgot: vegyük például az IEnumerable<T> generikus interfészt. Egy ilyen osztályból T típusú elemek "jönnek ki" - tehát T-nél "nagyobb", általánosabb elemeket is kivehetünk. Egy IEnumerable<string> vígan tud IEnumerable<object>-ként is viselkedni. Bajt nem csinálhatunk, mert "befele" nem megy adat, nem fordulhat elő, hogy egy, magát IEnumerable<object>-nek mutató IEnumerable<string>-be egy int típusú adatot rakunk, merthogy az object megbírja azt is.

A .NET Framework 4.0-ban ennek az interfésznek így néz ki a definíciója:

public interface IEnumerable<out T> : IEnumerable
{
    IEnumerator<T> GetEnumerator();
}

Azzal, hogy ki lett rakva az out, a T paraméter kovariánssá vált:

// C# 4.0 kód:
IEnumerable<string> enumerableOfString =
    new string[] { "http://", "otperc", ".net" };
IEnumerable<object> enumerableOfObject = enumerableOfString;

Annak pedig, hogy az out-ot ki lehetett rakni, egy előfeltétele volt: a T csak a "kimeneti oldalon" szerepelt az interfész definíciójában.
Most nézzünk meg egy másik interfészt:

public interface IComparer<in T>
{
    int Compare(T x, T y);
}

Itt most az "in" módosítót használták, a T paramétert kontravariánssá téve - talán most már nem túl meglepő a felfedezés, hogy a T csak bemenő paraméterként használt. T helyére bepasszol T, vagy bámi nála specializáltabb: egy comparer, ami össze tud hasonlítani két object-et, két stringet is össze tud.

Természetesen az in és az out típusparaméterek használata nem csak a framework fejlesztők kiváltsága, mi is használhatjuk őket a saját interfészeinkben.

Osztályokon nem, azt egy "Invalid variance modifier. Only interface and delegate type parameters can be specified as variant." üzenettel jutalmazza a fordító. A variancia ugyanis műveleteken értelmezett, a műveleteket pedig leginkább a delegate-ek és az interfészek írják le. Az List<T> típusparaméterére nem rakhattak ilyen módosítót, mert a T ki- és bemenő oldalon is használt. Viszont az List<T> egyben IEnumerable<T> is (illetve IEnumerable<out T>), úgyhogy ha "azt az arcát mutatja", akkor használhatjuk úgy.

Szintén ellenőrzi a fordító, hogy ha in vagy out varianciamódosítót használsz, akkor a típusparamétered tényleg csak a megfelelő helyen bukkanjon fel, out paramétert bemenőként használva "Invalid variance: The type parameter 'T' must be contravariantly valid on '<metódusnév>'. 'T' is covariant." üzenetet kapunk, in-t kimenőként használva pedig "Invalid variance: The type parameter 'T' must be covariantly valid on '<metódusnév>'. 'T' is contravariant."-et.

A teljes és kendőzetlen igazság

Be kell vallanom: a fenti postból sok minden nem igaz. Illetve igaz, csak nem úgy. Néhol egyszerűsítésekkel éltem, pl. a “kisebbség-nagyobbság”, “hozzárendelhetőség” és a “leszármazás” fogalmait illene jobban tisztába rakni. Belátható, hogy a kettő nem ugyanaz, mert bár fentebb láttuk, hogy az IEnumerable<object>-nek símán értékül adhatjuk az IEnumerable<string>-et, ez az “egyes számú szabály” értelmében azt is jelenti, hogy az IEnumerable<string> öröklési láncában (bocs, megint pongyola vagyok, interfészről beszélünk: öröklési fájában) valahol szerepelnie kéne az IEnumerable<object>-nek. Egyet biztosíthatok: nem szerepel.

Ha ezek a részletek is a helyükön lennének, akkor korrekt lenne az írás, viszont érthetetlen. A neten rengeteg anyag fellelhető, but I won’t bring it to you – you have to bing it for yourself. :)

Összes tábla összes adatának törlése SQL Serverben

2009-12-10T16:47:00.006+01:00

Fejleszési-tesztelési időben előfordul, hogy szeretnénk "nyomni egy resetet" az adatbázisunkon: a séma marad, de ki szeretnék dobni minden adatot. TRUNCATE-eljünk mindent!

-- disable all constraints
EXEC sp_MSForEachTable "ALTER TABLE ? NOCHECK CONSTRAINT all"

-- delete data in all tables
EXEC sp_MSForEachTable "DELETE FROM ?"

-- enable all constraints
EXEC sp_MSForEachTable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT all"

A középső sor a tényleges truncate, a kezdő-záró ALTER TABLE-ök csak a kényszerek betartatását kapcsolják ki, majd vissza - így a FOREIGN KEY-ek sem akadályozzák meg az adatok törlését.

az eredeti script és további bölcsességek a témában:
How do you truncate all tables in a database using TSQL? @ StackOverflow

az sp_MSforeachtable tárolt eljárás további hasznos felhasználási lehetőségei:
8 Common Uses of the undocumented Stored Procedure sp_MSforeachtable @ SQLServerCurry

Forráskód másolása HTML-ként Visual Studio-ból

2009-12-07T17:10:00.001+01:00

Ha valamilyen technikai irományt (dokumentációt, blogbejegyzést, stb...) készítünk, gyakran lehet szükség arra, hogy abba forráskódot illesszünk be. Ez még nem agysebészet, Visual Studióban kódrészlet kijelöl, CTRL+C, CTRL+V, és kész, átmegy a szöveg.
Egy dolog viszont nem megy át: az a gyönyörű syntax highlight (na jó, Word-be átmegy). Pedig a Studio kódkiemelős funkciója remek, jó lenne azt úgy például HTML-ként kiemelni.

Pont ezt tudja a CopySourceAsHtml nevű Visual Studio add-on, amit ingyenesen le lehet tölteni a http://copysourceashtml.codeplex.com/-ról.
A 3.0-ás verzióban már egy .msi installert kapunk, next-next-finish telepítéssel. Utána egy egy VS újraindítás, és a File, Edit menükben, illetve a kijelölt szöveg context menüjében egy új elem bukkan fel: a Save/Copy as HTML.
Ha már vannak saját CSS stílusaink, azok használatára is beidomíthatjuk.

Nullérték-vizsgálat egyszerűen

2009-12-05T08:00:00.002+01:00

Eredeti (Java-s) ötlet itt: http://cesjava.freeblog.hu/archives/2009/10/13/a_NUllPointerException_transzparens_kezelese/.

Saját továbbgondolás (C#):

public static class NullReferenceCheckExtensions
{
    public static void CheckIfNull<T>(this T instance)
        where T : class
    {
        if (instance == null)
        {
            string argumentInfo = TryGetArgumentInfo();
 
            if (argumentInfo == null)
                argumentInfo = string.Format("An instance of type '{0}'.", typeof(T).FullName);
 
            throw new ArgumentNullException(argumentInfo);
        }
    }
 
    private static string TryGetArgumentInfo()
    {
        try
        {
            var st = new System.Diagnostics.StackTrace(true);
            var callerFrame = st.GetFrame(2);
            var fileName = callerFrame.GetFileName();
            var fullSource = System.IO.File.ReadAllLines(fileName);
            var info = fullSource[callerFrame.GetFileLineNumber() - 1].Trim();
            return info;
        }
        catch
        {
            return null;
        }
    }
}

Használat:

public void MyMethod(string name, Uri uri)
{
    name.CheckIfNull();
    uri.CheckIfNull();
}

Osszunk nullával!

2009-12-04T07:50:00.005+01:00

double one = 1;
double zero = 0;
try
{
    var x = one / zero;
}
catch (DivideByZeroException)
{
    Console.WriteLine("Csak hiszed...");
    Console.WriteLine("http://www.blackwasp.co.uk/CSharpInfinity.aspx");
}

WCF exception faultá alakítása háziassszonyoknak

2009-12-03T19:02:00.001+01:00

Adott a szituáció, hogy van egy üzleti logia / üzleti folyamat rétegünk, amiből szeretnénk néhány dolgot publikálni a külvilág felé - ehhez a WCF a választott technológiánk. Néhány dolgot nem publikálunk, azokat csak a service réteget assemblyként referenciáló kódok érik el (ők is a sajátjaink, a rendszer többi komponense).
A WCF remek választás, hisz pont erről szól: úgy implementálhatod a service rétegedet, hogy arra koncentrálsz, amit csinálni akarsz - azzal meg nem kell törődnöd, hogy hogy lesz ez a szolgáltatás távolról elérhető. Nem kell a kommunikációval foglalkozó kódot írnod, csak felpattintasz néhány attribútumot (, átfusz néhány ezer sor XML-t), és kész. Eddig hurrá.

A feketeleves ott kezdődik, hogy az üzleti folyamatok végrehajtása nem mindig sikeres (akár azért, mert nem álltunk a helyzet magaslatán, mikor implementáltunk, akár azért, mert valami külső körülmény - pl. egy elhalálozott adatbázisszerver - miatt nem tudjuk teljesíteni kliensünk kérését).
Vegyük pl. a jó öreg számológép szolgáltatást - jelen esetben a megvalósításunk, a FawltyCalculator kicsit bugos. A metódusunk hívása egy kövér DivideByZeroException-t fog dobni.

[ServiceContract]
interface ICalculator
{
    [OperationContract]
    int Divide(int dividend, int divisor);
}
 
public class FawltyCalculator : ICalculator
{
    public int Divide(int dividend, int divisor)
    {
        int result;
        result = dividend / (divisor * 0); //buggy
        return result;
    }
}

A dolgok ilyentén való félremenésére a kliensoldalon is fel kell készülni. A WCF megteszi nekünk azt a szivességet, hogy a szolgáltatások futása közben dobott, kezeletlen kivételeket szépen megeszi, és a szervíz hívásra küldött válaszban jelzi, hogy baj van (volt).
A túloldalon (a kliensnél) ez egy FaultException képében fog materializálódni. Ott tehát nem egy DivideByZeroException elkapására kell felkészülni, hanem egy FaultException-ére, amivel egy baj lesz: semmit nem fogunk tudni arról, hogy mi is ment félre, kifutottunk a memóriából, nullával osztottunk, vagy kihalt alólunk valami egyéb szoftverkomponens. Megtehetjük ugyan, hogy arra instruáljuk a WCF-et, hogy adja vissza a kliensoldalnak a részletes exception-t, ami development-time hasznos feature, de produkciós környezetben nem túl szerencsés (egyrészt nem túl user friendly megoldás, másrész túl sok mindent köthetünk így a klienseink orrára, amit esetleg nem szeretnénk).

A megoldás: dobjunk magunk is FaultException-t, már a service oldali kódban! Annak megadhatunk FaultReason-t, FaultCode-ot, az szépen át fog menni a kliens oldalra:

    public int Divide(int dividend, int divisor)
    {
        int result;
        try
        {
            result = dividend / (divisor * 0); //buggy
        }
        catch (DivideByZeroException)
        {
            throw new FaultException(
                new FaultReason("A nullával való osztás nem menő."),
                new FaultCode("DIVIDE_BY_ZERO")
                );
        }
        return result;
    }

Ez eddig remek. Mi vele a gond? Az, hogy a WCF azt ígérte nekünk, hogy úgy kódolhatunk szolgáltatást, hogy közben nem kell ilyesmivel törődni. Márpedig ha a Divide() metódus nem egy WCF-en át elérhető szolgáltatás lenne, hanem csak úgy meghívnánk kódból, akkor még úgy is nehezen indokolható a fenti try-catch blokk, ha nem véletlenül vagyunk mi a FawltyCalculator dedikált fejlesztői.
Mi történik itt? Ez az absztrakció szivárog.
Sőt, ez inkább már folyik.

Az lenne a jó, ha nem kéne FaultException-t dobnunk, de mégis, akkor, és csakis akkor, ha a metódunkat WCF-en keresztül, távolról hívják, valahogy mégis úgy legyen minden, minthacsak azt dobtunk volna.
Szerencsére van megoldás, úgy hívják, hogy IErrorHandler (a System.ServiceModel.Dispatcher névtér alatt lakik). Nem túl meglepő módon ez egy interface, ami két metódus megvalósítását írja elő: a HandleError()-ban a szervízoldalon dobott, kezeletlen kivétellel kezdhetünk valamit (logging, alkalmazás meghalasztása, stb.), a ProvideFault() pedig pont az, ami nekünk kell: az exception ismeretében megkonstruálhatjuk a kliensünknek adandó választ. Ezt akár bit (na jó: XML element) szinten is kontrollálhatjuk, de ha lustábbak vagyunk, rábízhatjuk a Frameworkre is a legyártását:

public void ProvideFault(Exception error, System.ServiceModel.Channels.MessageVersion version, ref Message fault)
{
    FaultException faultException = null;
 
    if (error is ApplicationException)
    {
        faultException = new FaultException(
            new FaultReason(string.Format("Alkalmazáshiba történt ('{0}').", error.Message)),
            new FaultCode("APPLICATION_ERROR")
            );
    }
    else if (error is System.Data.Linq.ChangeConflictException)
    {
        faultException = new FaultException(
            new FaultReason(string.Format("Több felhasználó próbálta párhuzamosan módosítani ugyanazt az adatot.")),
            new FaultCode("DATABASE_CONCURRENCY_ERROR")
        );
    }
 
    // Still unhandled - provide some default...
    if (faultException == null)
    {
        faultException = new FaultException(
            "Kezeletlen kivétel történt.",
            new FaultCode("UNHANDLED_ERROR"));
    }
 
    var messageFault = faultException.CreateMessageFault();
 
    // ref Message fault
    fault = Message.CreateMessage(
        version,
        messageFault,
        "http://www.w3.org/2005/08/addressing/soap/fault"
        );
}

[Felhívnám a figyelmet a "http://www.w3.org/2005/08/addressing/soap/fault" sorra, azt magában fél nap volt kififikázni.]

Ezek után már csak rá kell vennünk a WCF-et, hogy használja is az errorhandlerünket.
Ehhez készítenünk kell egy osztályt, ami implementálja az IServiceBehavior interfészt. Ennek az osztálynak a ApplyDispatchBehavior() metódusában fogjuk az ErrorHandlerünket befűzni a WCF folyamatába. Ezután három út van: a) programozottan bepéldányosítjuk a service behaviorunkhat, és megetetjük a service host objektummal, b) az IServiceBehavior megvalósításon kívül leszármazunk az Attribute-ból is, és attribútumként felpattintjuk a szervizünkre c) az IServiceBehavior megvalósításon kívül leszármazunk a BehaviorExtensionElement-ből, és az app.configban konfiguráljuk az error handlingot. (Ez mekkora!)
Én a b)-t választottam:

public sealed class ErrorBehaviorAttribute : Attribute, IServiceBehavior
{
    private Type _typeErrorHandler;
 
    public ErrorBehaviorAttribute(Type typeErrorHandler)
    {
        _typeErrorHandler = typeErrorHandler;
    }
 
 
    public void Validate(ServiceDescription description, ServiceHostBase serviceHostBase) { }
    public void AddBindingParameters(ServiceDescription description, ServiceHostBase serviceHostBase, System.Collections.ObjectModel.Collection<ServiceEndpoint> endpoints, BindingParameterCollection parameters) { }
 
    private IErrorHandler CreateTypeHandler()
    {
        var typeErrorHandler = (IErrorHandler)Activator.CreateInstance(_typeErrorHandler);
        return typeErrorHandler;
    }
 
    public void ApplyDispatchBehavior(ServiceDescription description, ServiceHostBase serviceHostBase)
    {
        IErrorHandler typeErrorHandler = this.CreateTypeHandler();
        foreach (var channelDispatcher in serviceHostBase.ChannelDispatchers)
        {
            (channelDispatcher as ChannelDispatcher).ErrorHandlers.Add(typeErrorHandler);
        }
    }
}

Ennyi. Megy. Persze lehet még tovább cifrázni, pl. hosszú távon a ProvideError() jó eséllyel hízik túl minden vállalható méreten, de ez már egy másik sztori.
Mára ennyit!

SQL Server High Availability megoldások

2009-11-27T17:06:00.006+01:00

Az SQL Server több lehetőséget is biztosít számunkra, hogy magas rendelkezésre állású környezeteket alakíthassunk ki vele. Alapvetően négy út van, amin elindulhatunk:

Failover clustering: ez a lehetőség egy kicsit kilóg a sorból, mert igazából nem (csak) SQL Server szolgáltatás: megosztott diszk(ek)en és azokat közösen használó cluster node-okon alapuló megoldás. Ezeket az erőforrásokat a Microsoft Cluster Service (MSCS) segítségével egyetlen virtuális erőforrássá gyúrhatjuk egybe a külvilág számára - ez a virtuális erőforrás saját azonosítóval (IP címmel, hosztnévvel, stb) rendelkezik, klienseink ehhez kapcsolódnak, és nem is tudják, hogy a clusteren belül melyik gép szolgálja ki őket.
Ez egyben azt is jelenti, hogy ez egy szerver-szintű megoldás, tehát nincs lehetőség arra, hogy egy SQL Server instance csak bizonyos adatbázisán használjuk, míg másokon ne.
Hátránya, hogy a közös disk single point of failure: ha az meghal, oda a cluster (tehát minimum érdemes valamilyen RAID megoldásban gondolkodni adattárolás szinten). Géphalál esetén, vagy ha az oprendszer megáll vagy megállítottuk (lásd: patchelés), a cluster többi gépe pillanatok alatt át tudja venni a kiszolgálást a működésképtelen node-tól, miközben a kliensek ebből jó esetben semmit nem vesznek észre.
Database mirroring: ez esetben két adatbázisunk van, egy éles (principal), és annak egy készenléti tükre (mirror).
Látható, hogy ez egy database-level HA megoldás, tehát egy instance-on belül eldönthetjük, hogy mely adatbázisokat szeretnénk tükrözni, és melyeket nem.
A tükrözést kétféleképp is megvalósíthatjuk: szinkron (egy művelet akkor tekinthető végrehajtottnak, ha az élesről a tüköradatbázisba is átkerült az adat), illetve aszinkron módon (az tranzakciók az éles adatbázisban kommitálódnak, a tükör a háttérben szinkronizálódik). Az előbbi nagyobb adatbiztonságot, de rosszabb teljesítményt, míg az utóbbi az esetleges adatvesztés (a élesen már igen, de a tükrön még nem commitálódott tranzakciók) kockázata melletti jobb performanciát biztosít.
A mirror adatbázis a kliensek számára nem használhatók, de készíthetők róla snapshot-ok, amik az adatbázis adott időpillanatbeli, csak olvasható verziói - reporting feladatokra ideális lehet, ha nem szeretnék az éles szervert report-lekérdezésekkel terhelni, és nincs szükség abszolút real-time adatokra.
Log shipping: A log shipping némileg hasonlatos a mirroring-hoz, ahelyett vagy amellett is használható. A mirroringgal szemben egynél több másodlagos adatbázist is támogat.
Gyakorlatilag arról van szó, hogy az éles adatbázisról készítünk egy backup-ot, azt visszaállítjuk, mint másodlagos, majd (konfigurálható) időnként automatikusan log backup készül az élesről, ami a másodlagos adatbázis(ok)on visszaállításra kerül. Így lesz egy (konfigurálható) delay az éles és a tükrök között, ez néha nem jó, néha meg de: például ha egy kikommentezett WHERE feltétellel az összes munkavállalónk nevét Kovács Józsefnévá UPDATE-eljük, nem rossz, ha megvan az eredeti állapot.
Replication: A replikáció szintén adatbázis-szintű megoldás, sőt: lehetőségünk van csak az adatbázis bizonyos részeit replikálni. A replikáció a publisher-subscriber modellre épül, az elsődleges adatbázisunk publikálja az adatokat (vagy azoknak egy részét), amire a másodlagos adatbázis(ok) "előfizetnek". A másodlagos adatbázisok használhatók lekérdezésre, vagy bármilyen reporting funkcióra. A replikáción belül három al-típus létezik:
- snapshot: minden egyes szinkronizációkor egy "fénykép" (snapshot) készül a publisher sémájáról és adatairól az adott időpillanatban és jut el a subscriberekhez. Ebben az esetben a másodlagos adatbázisok csak a szintkronizáció pillanatában lesznek up-to-datek (mint a megállt óra,ami napjában kétszer pontos). Akkor alkalmazható, ha ez megengedhető, vagy csak kis mennyiségű adatot mozgatunk. Hasznos lehet akkor is, hogy az éles adatbázisban rengeteg művelet történik, de minket igazából csak a végeredmény érdekel ("nap végi zárás" - mennyi lett a záróegyenleg?).
- transactional: itt az első lépés egy snapshot replikáció (ezzel áll elő a "tükör"), majd a publisher összes séma- és adatmódosítása real-time eljut a subscriberek felé is, így a tranzakcionalitás biztosított.
  A subscriber adatbázis(ok) írhatók ugyan, de ezek a módosítások nem jutnak vissza a publisher felé, szóval gondoljuk át, hogy mit csinálunk.
- merge: itt is egy snapshot-tal indulunk, de mind a publisher, mint a subscriber(ek) módosításai követésre kerülnek, és alkalomadtán szinkronizálódnak (ez remek lehetőség konfliktusok kialakulására, amikor több subscriber próbálja ugyanazt az adatot módosítani).

Bár ez egy relatíve hosszú post, mégis nagyon (nagyon-nagyon-nagyon) csak a felszínét kapargatja a magas rendelkezésre állás, megbízhatóság, skálázhatóság témakörének. Szerencsére elég sok szakirodalom található a témában (én most épp ezt gyúrom, ez ugyan nem csak HA témákat jár körül, de elég jó, küldeném mindenkinek aki szereti; de ezen felül sok más könyv, vagy akár a BOL is rengeteg információval szolgál).
Ennek ellenére szerettem volna összeszedni legalább nagy vonalakban a lehetőségeket, merthogy annyi van, hogy az ember könnyen eltévedhet, még mielőtt egyáltalán elindult volna - ami nem túl szerencsés.