Visual Studio 2010 Sexy Edition

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

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

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?

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

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