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

Ú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

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)

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)

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

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

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

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

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

- 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.