Archive for the ‘.NET’ Category

.NET fejtörő 2.

Tuesday, January 20th, 2015

Piros vagy zöld lesz a teszt kimenete? Válaszokat indoklással kommentben várom. A hozzászólások moderálva vannak, hogy 2 napot tudjam késleltetni a válaszokat, így mindenkinek lesz ideje gondolkodni. Jó filózást!

[TestMethod]
public void Teaser2()
{
    StringBuilder sb = new StringBuilder();

    for (int i = 0; i < 10; i++)
    {
        sb.Append(i + ' ');
    }

    Assert.AreEqual("1 2 3 4 5 6 7 8 9", sb.ToString());
}

A Test Driven Development tanfolyam következő felvonása február kilencedikén lesz, szeretettel várlak.

EF WithRequiredDependent – mit csinál ez?

Thursday, January 15th, 2015

Nem jövök rá, pontosan mit is csinál ez? A HasRequired már önmagában megcsinálja a foreign keyt, mit ad ez még a modellhez?

.NET fejtörő 1.

Thursday, January 15th, 2015

Piros vagy zöld lesz a teszt kimenete? Válaszokat indoklással kommentben várom. A hozzászólások moderálva vannak, hogy 2 napot tudjam késleltetni a válaszokat, így mindenkinek lesz ideje gondolkodni. Jó filózást!

[TestMethod]
public void Teaser1()
{
    try
    {
        var a = Math.PI;
        var b = 0;
        var c = a / b;
    }
    catch (DivideByZeroException exception)
    {
        Assert.Fail("A kutya fáját");
    }
}

A Test Driven Development tanfolyam következő felvonása 2015. február kilencedikén lesz, szeretettel várlak.

Gyors .NET tömörítő algoritmusok

Sunday, January 11th, 2015

A backtesteremben nagyon sok adatot kell kezelni memóriában, sok gigabájtot. A memóriacache-emben tömörítve vannak az adatok. Tömörítésre eddig a .NET GZip algoritmusát használtam, fastest módban, így elfogadható sebességet és tömörítést kapva.
Most viszont olvastam róla, hogy vannak alternatív algoritmusok is. Tettem hát egy próbát, az alábbi eredményeket kapva:

.NET GZipStream fastest mode:
Compression time: 00:00:00.1801551, compressed size: 75,122.00
Decompression time: 00:00:00.2001859

Ez a baseline.

Snappy native:
https://snappy4net.codeplex.com/
Compression time: 00:00:00.1815305, compressed size: 508,387.00
Decompression time: 00:00:00.1464451

Hát, ez nem győzött meg.

Lz4:
http://lz4net.codeplex.com/
Compression time: 00:00:00.6303679, compressed size: 41,926.00
Decompression time: 00:00:00.1364594

Ez se az igazi sebességben, de legalább jól tömörít.

Lz4Native:
https://code.google.com/p/lz4-net/
Compression time: 00:00:00.0925361, compressed size: 49,862.00
Decompression time: 00:00:00.1757730

Na, ez már tetszik. Jobban tömörített, mint a gzip, fele annyi idő alatt, mint az, és a decompress is egy kicsit gyorsabb. Kipróbálom majd igazi adatokkal is, meglátjuk, ott hogy zenél.

Invalid file karakterek lecserélése

Wednesday, January 7th, 2015

Egy webes munkában file nevet kellett generálni a letöltendő fájloknak. Az eredeti névben lehet kettőspont, stb. ami nem megengedett fájlnevekben. A böngésző is lekezeli ezt valahogy, de én akartam ezt előre megoldani.

Itt vannak megoldások a feladatra.

Sokféle megoldást adnak, nekem a linq-s tetszik legjobban:

var invalidChars = Path.GetInvalidFileNameChars();
var invalidCharsRemoved = stringWithInvalidChars.Where(x => !invalidChars.Contains(x)).ToArray();

De ez a legfurább logikájú, ez ütötte meg a szememet:

string cleanFileName = String.Join("", fileName.Split(Path.GetInvalidFileNameChars()));

Erre mondja az angol, hogy convoluted logic?

Test Driven Development tanfolyam: február 9.

Console.WriteLine blokkolás

Tuesday, November 11th, 2014

Ma megint láttam valami újat, kár, hogy bosszúság árán. Egy program logol fileba és konzolra is. VS debugger alatt futott, majd detacholtam. A detacs hatására a Console.WriteLine többet nem tért vissza, nem hibát adott, hanem blokkolta a hívást, ezzel teljen megállítva a program működését. Gondlom a VS átirányította a std outot magára, a detacs során viszont valami nem jött össze neki. Tanulság: ne tessék a debuggerel szórakozni, ha produkciós kódról is fontos futtatásról van szó.

Ha stringeket kell formázni, ez hasznos lehet

Friday, October 10th, 2014

Pl. Format(“{Elso} – {Masodik}”, obj);

Az objből kiszedi az Elso es Masodik property-k értékét, és behelyettesíti.

Íme pár implementáció, nekem a szerzőé bevált (HaackFormatter).

—–

TDDre még van van pár helyem, akit érdekel, vagy ismerősét érdekli, jelentkezzen. Ha a jelentkezéskor a megjegyzésbe beírod a HaackFormatter szót, akkor még él a 150-es kedvezményes ár.

Ha egy MVC site nem ad vissza semmit

Thursday, October 9th, 2014

De hibát se, akkor lehet egyszerűen nincs minden IIS modul feltelepítve, ami kell hozzá.

TDD helyek

Monday, October 6th, 2014

Srácok/lányok/hölgyek/urak,
fogynak a helyek a TDD tanfolyamra keményen, az akciós ár beindította a gépezetet. Arra kérem aki jelentkezni szeretne, hogy töltse ki mihamarabb a webes formot, hogy lássam, mekkora teremre lesz szükség.

Köszi: soci

TDD tanfolyam kedvezményes ár még él pár napig

Wednesday, October 1st, 2014

Többen jeleztétek, hogy a cégeteknél nem lehet ilyen gyorsan finanszírozást találni a tanfolyamra, mivel az akciót csak 1 hete hirdettem meg. Ezért ha valaki még szeretne élni a 150-es árral jelezze nekem, így nyugodtan tudja intézni papírügyeket.

TDD tanfolyam újra – extra előfoglalási akcióval

Monday, September 22nd, 2014

Újra lesz TDD tanfolyam novemberben. Aki gyorsan lép, sokkal olcsóbban jöhet most tanulni.

Részletek itt, várok mindenkit szeretettel.

Visual Studio Profiler .NET Framework belsejéhez

Monday, September 15th, 2014

Windows 8-n már nem látszanak a rendszerhívások a profilerben, mivel nincsenek pdbk a natívra lefordított .net rendszerkódokhoz, ez pedig kellene a profilernek (illetve, mivel nagyon más a profiler mögötti infrastruktúra a Windows 8 szigorúbb secuja miatt).

Itt leírják, hogy lehet ngenelt assemblykhez pdbt generálni.

Az első, source nélküli leírás nekem nem volt elég, a metódusnevek helyén valamilyen hash szerű érték jelent csak meg, az nem túl hasznos.

Hogy ne kelljen kézzel cicózni a sok assemblyvel, itt a megoldás.
Végigszántja a gacot, és nyomja hozzájuk a pdbket. Ráadásul megcsinálja 32 és 64 bitre is. Szeretjük a Wintellectet.

Visual Studio repair

Friday, September 12th, 2014

A tegnapi gépdöglődés után Visual Studio repair volt, mivel indulás után szórta a hibákat, melyik modulja nem megy. A sima repair a Programs and Feature-sből nem segített. Két dolgot tettem, amitől rendbe jött. Egyrészt felraktam az VS 2013 SP3-at, másrészt kitöröltem pár megsérült config fájlt (hogy melyik segített sajnos emiatt nem tudom behatárolni).

C:\Users\soci\AppData\Local\Microsoft\VisualStudio\12.0\devenv.exe.config
Másrészt itt ha valamelyik, az adott assemblyhez tartozó fájl megsérül, akkor se indul a buli:
C:\Users\soci\AppData\Local\Microsoft_Corporation\

Ha valami misztikus oknál fogva semmilyen .netes program nem megy egy gépen, akkor lehet a központi config beteg, ezek a környéken:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\

Értelemszerűen kell a verziót és a bitnesst nézni.

WCF channel és channelfactory lezárás

Monday, July 28th, 2014

A WCF channelek lezárása egyértelmű, ha rendben van a csatorna Close(), ha faulted, Abort().
De mi van a channelfactory-vel?
Amiért a kérdés előjött az az, hogy egy szerviz rendszeres használata során 2 perc utáni hívásoknál elszállt a hívás. A kliens ezt élte meg:
An existing connection was forcibly closed by the remote host

A szerveren meg egy belső exception volt, amit a WCF lenyelt, de jelezte, hogy valami nem ok:
The I/O operation has been aborted because of either a thread exit or an application request.

A figyelmem a channelfactory-re terelődött. Az lokális változóként volt létrehozva, és ebek harmincadjára szabadon engedve. Jaj, ez beteg. Lokális dispose nem jó rá, mert akkor lezárja az összes általa nyitott csatornát (legalábbis vélemények szerint).

Próbáltam egy statikus példányt letárolni, azzal létrehozni a csatornákat, de ez is lepukkant 2 perc után (doksi szerint thread safe, több szálból használtam).

Végül nem maradt más, mint minden csatornához saját factory instance-et létrehozni, és a csatorna használata után mindkettőt lezárni. Pedig elvileg meg lehet osztani a factory-t, teljesítmény okokból. Ebben az alkalmazásban ez megfelelő megoldás, de ha sok csatornát kellene nyitni, az nem tetszene. Valaki látott már ilyen esetet?

MemoryCache bug

Saturday, July 26th, 2014

A MemoryCache osztály ASP.NET hoszt alatt időnként Dispose-olja magát. Nagyon kedves. Mindezt úgy teszi, hogy nem dob semmiféle exceptiont, csak ha beleraksz valamit, nem marad benne.
4.5-ben fixálták, de 4.0-ra is van workaround vagy hotfix is. Részletek itt.

Unit teszt snippet

Saturday, May 24th, 2014

Tolom a teszteket ezerrel (ATS-elek), ez a kis snippet jól jött.

TDD is dead. Tényleg?

Monday, May 12th, 2014

Pont TDD tanfolyam volt előző héten, amikor volt egy videó, amiben David Heinemeier Hansson, Martin Fowler és Kent Back beszéltek (vitatkoztak?) a témáról. A kiváltó cikk ez.
A második két ember gondolom közismert, David Heinemeier Hansson a Ruby on Rails létrehozója.

Az első rész nem volt túl mély, remélem a másodikban kicsit jobban belejönnek, bár lehet, hogy kár ezt várni. Van, amikor természetesen jön a TDD, van, amikor nem, ilyenkor igyekszünk utólag tesztelni, ha sikerül. Semmi se szentírás a szakmában, van, aki elölről szereti, van, aki hátulról. Mint az Eurovíziós dalfesztiválon. :)

Computing a Cartesian Product with LINQ

Tuesday, April 22nd, 2014

Na, ezzel izzadtam volna, ha magamtól kell kitalálni.

Memória táblák meghajtása OR mapperrel

Tuesday, April 22nd, 2014

Az SQL Server 2014-es memóriatáblákat csak akkor lehet a lehető legközvetlenebb módon elérni, ha natív kódra fordított tárolt eljárásokkal érjük el. Az OR mapperek viszont alapban sima, dinamikus SQL-eket generálnak. Ha így akarunk CRUD műveleteket végrehajtani egy memória táblán, akkor az átmegy a szerver interop rétegén, ami jelentősen belassítja azt. Többszörösére. Emiatt -jelen tudásom szerin-, ha OR mapperel akarjuk meghajtani a memória táblákat, akkor saját spket kell írni. Kipróbáltam a dolgot, de falakba ütköztem. Ugyanis az OR mapperek elvárják, hogy pl. egy update után visszaadja a szerver az xxx rows affected information message-et, ebből tudja az OR mapper, hogy sikerült a sor módosítása. Ha nem jön vissza semmi, akkor azt hiszi, hogy az optimista konkurencia ellenőrzés miatt nem sikerült a sor módosítása (azt hiszi valaki közben módosította vagy törölte a sort), így exceptiont dob. Viszont a memória táblás update NEM adott vissza XXX rows affected üzenetet, így az OR mapper exceptiont dob (NHibernate.StaleObjectStateException és ).
A megoldás tehát valószínűleg az lehet, hogy ki kell kapcsolni az OR mapper optimista konkurrencia ellenőrzőjét.
Egyelőre NHibernate-nél nem találtam megoldást rá, legalábbis a Conf ORM-es “code first” mapping módszerrel. EF-en még nem próbáltam.
Mindenesetre kiírtam msékhez a kérdést, ha jön válasz, megírom.

Az ORM batching perf vonzata

Friday, April 18th, 2014

Az egyik ügyfelemnél letöltenek pár száz sort memóriába Entity Frameworkkel. Ott C# kóddal mindenféle komplex módon kitalálják, melyik entitást hogyan kell módosítani, majd a módosítások eredményét az EF betolja adatbázisba. Bár a szerveren nem volt nagy terhelés, mégis volt amikor 1000 fölött volt a batch request/second.

Miért? Mert az EF nem tudja összenyalábolni a módosításokat, hanem egyesével küldi be őket. Azaz, ha 300 sor módosult, akkor 300 update fog bemenni, ennyi roundtrip lesz. Ez annyira gáz, hogy egyszerűen nem értem az MS-t, miért nincs még batching a 6-os EF-ben.

Mutatok egy példát, mekkora hatása van ennek. Az NHibernate bármennyire is elhanyagolt manapság, de ő szépen tud batchelni.
A következő példában letöltök 20000 sort, módosítom mindet, majd visszamentem a módosításokkal. EF-fel ez 11mp.
NHibernate-tel meg tudom mondani, hány utasítást küldjön be egyszerre. Ettől függően az alábbi számok jönnek ki:

NHib test - BatchSize: 1000000, Duration: 00:00:00.9390957
NHib test - BatchSize: 100000, Duration: 00:00:00.8363326
NHib test - BatchSize: 10000, Duration: 00:00:00.8463299
NHib test - BatchSize: 1000, Duration: 00:00:01.0654756
NHib test - BatchSize: 100, Duration: 00:00:01.3361271
NHib test - BatchSize: 10, Duration: 00:00:02.4312424
NHib test - BatchSize: 1, Duration: 00:00:10.4669159

Elég nagy batch méretnél a 10 mp lemegy 1mp alá!
EF-nél 11, és kész. Cáfoljon meg valaki, hogy rosszul tudom, és az EF is tudja ezt.