Soci blog

Előző héten két érdekes hibát láttam ügyfeleknél.
Az egyikben láttam, hogy a lekérdezés végrehajtási tervében konverzió van, datetime -> integer, emiatt scan volt seek helyett, azaz lassú volt a lekérdezés.
Ami fura volt ebben, hogy egy izeID oszlop volt összehasonlítva egy datetime értékkel. Az ID-k tipikusan intek, megnézve a táblát tényleg az volt. Volt egy lokális változó, ami copy-paszta miatt datetimera sikerült int helyett, és ezzel írták tovább a where szűrést. A lekérdezés már 2 éve ment élesben. :)
Ami érdekes volt benne, hogy funkcionálisan jól működött, a számok szépen konvertálódtak dátumokká és vissza, nem volt vele gond, csak lassú volt az egész. Bizarr hiba.

A másik esetben egy ilyen lekérdezés volt:

declare @a int
while valami
begin
  select @a = oszlop from tabla where ...
end

Furcsa volt, hogy a @a furcsa módon tartalmazott értéket akkor is, amikor nem érintett sort a select a where miatt.
Jobban belegondolva ez nem is fura, hisz a select NEM ad értéket a változónak, ha nem érint sort, és NEM is nullázza ki. Első iterációkor a @a null, hisz nem kapott értéket, a második iterációnál meg benne volt az első futás eredménye, ami már nem null volt, bár azt várták. Nem nagy hiba, de időrabló tud lenni.

Hirtelen egymás utáni napokon 3 cégnél égetett be az SQL Server 2005-től létező option(recompile), miután nem működik.

A hint célja az lenne, hogy a konkrét paraméterértékek ismeretében kérünk egy újrafordítást, így az optimizer ki tud dobni felesleges ágakat a lekérdezésből, ezzel nagyon hatékony terveket tud létrehozni egyes speciálisabb lekérdezésekhez.
Pl. gyakori, hogy a paraméterre csak akkor kell szűrni, ha nem null, ha null, jöjjön vissza minden sor:

… where @param is null or oszlop = @param

Ez alapban scan lenne, lassú. Az option(recompile) hatására azonban ha a @param null, akkor teljesen kiesik a sor, ha nem null, akkor meg leegyszerűsödik erre:

… where oszlop = @param

Ez meg már jó kis gyors seek lesz, megfelelő index esetén.

Mi itt a gond? Csak az, hogy ez sok verzión NEM működik. Pedig működött. :)

Az ok a következő. SQL 2005-ben még nem működött. 2008-ra megcsinálták, ment, csakhogy egy igen durva bugot is beleszereltek: ha többen hajtanak végre ilyen hintelt lekérdezést, akkor összekeveredhetnek az eredményhalmazok. Ez az innye, bazmeg típusú bug. Gyorsan ki ki kommenteltek pár sort, mivel megvarrni meg nem olyan egyszerű, mint elrontani. Így ez most nem megy az újabb SQL Servereken.
Erland barátunk szerint az R2 RTM NEM tartalmazza még a javított verziót (magyarul helyesen működik, nem nem gyorsít).
Viszont ez az R2 CU1 már javítja.
Ezen doksi szerint már 2008-hoz is van javítás, a CU5-ben.

Már csak le kéne cseréni a cégeknek a 2005-öt. :)

Kb. egy hónap múlva elkezdek dolgozni egy igen komplex nagyvállalati enterprise app prototípusán. Ebben pár hónapon keresztül fogok részt venni, viszont valakinek ebből kész terméket is kellene készíteni. Ehhez nyitott meg a megrendelő cég 2 állást, amelyeket alább részletezek.
Ha kedvet érzel .NET-tel, a legmodernebb technológiákkal dolgozni és emberileg is passzol rád amit a követelményekben leírnak, akkor várunk szeretettel.
Az állások már most nyitottak, mivel a velem együtt dolgozzuk ki a prototípust, a cél az, hogy a tartósan a projekten dolgozó emberek mélységében tisztában legyenek azzal, amit tervezek.
Ha érdekel a dolog, az email címemen keresztül jelentkezhetsz.

A két állás:

Termékfejlesztési vezető

Több, mint 10 éve eredményesen működő, nemzetközi háttérrel rendelkező szoftverfejlesztő cég .NET és Oracle technológián alapuló, integrált vállalatirányítási rendszer fejlesztési projektjéhez termékfejlesztési vezető keres főállásban.

Feladat:
• Folyamatban lévő termékfejlesztési projekt vezetésének átvétele, újraszervezése;
• A termék specifikációjának áttekintése és teljessé tétele, a rendszerterv elkészítése;
• A fejlesztési csapat munkájának összehangolása , a termékfejlesztési projekt különböző fázisaiban a projekt céljainak elérése érdekében a megfelelő, felelős szakmai és vezetői döntések meghozatala;
• A projekttel kapcsolatos erőforrás-menedzsment, felelős becslések elkészítése , feladatok kiosztása, megoldások ellenőrzése;
• Fejlesztői csapat vezetése, együttműködés más szakmai vezetőkkel.

Cégünk számára az ideális jelölt:
Informatikai vagy műszaki felsőfokú végzettséggel rendelkezik, tapasztalata van, sikeres .NET-es termékfejlesztési projektekben vezető fejlesztőként/tervezőként, továbbá projektvezetésre alkalmas vezetői készségekkel rendelkezik. Határozott, céltudatos személyiség képes gyors döntések foganatosítására. Stratégiai, üzleti szemlélet jellemzi, képes ’big picture’-ben gondolkodni. Munkája magabiztos elvégzéshez Oracle ismerettel és közép szintű angol nyelvismerettel rendelkezik.

Munkavégzés helye: Budapest

Jelentkezés:
Hosszú távú, kölcsönös együttműködésre alapuló munkakapcsolat kialakítása érdekében várjuk jelentkezését.
Jelentkezését csatolt fényképes magyar és angol nyelvű szakmai önéletrajzzal, motivációs levéllel, referencia megjelölésével az alábbi címen várjuk: zsolt.soczo@gmail.com

A másik:

.NET vezetőfejlesztő

Több, mint 10 éve eredményesen működő, nemzetközi háttérrel rendelkező szoftverfejlesztő cég .NET és Oracle technológián alapuló, integrált vállalatirányítási rendszer fejlesztési projektjéhez vezetőfejlesztőt keres főállásban.

Feladat:
• A senior és junior fejlesztők szakmai irányítása, modultervezés, a feladatok megvalósítása a fejlesztőkkel és riportálás.
• A hozzá rendelt fejlesztők munkájának szakmai irányítása, számukra feladatok szabása és értékelése.
• Termék moduljainak tervezése a fejlesztési munka feladatokra bontása, kiosztása, visszavétele. A specifikációt végző konzulenssel való együttműködés a tervezés érdekében az ügyfél igény pontosítása ügyféllel szükség esetén.
• Döntés a tesztelési feladatokról, együttműködés a tesztelési csoporttal.
• Erőforrásbecslés, a megadott becslések visszaellenőrzése, a becslési folyamat pontosítása.

Cégünk számára az ideális jelölt:
Informatikai vagy műszaki felsőfokú végzettséggel rendelkezik, tapasztalata van, sikeres .NET-es termékfejlesztési projektekben vezető fejlesztőként. Pontos, precíz összehangolt munkavégzésre képes, munkája magabiztos elvégzéshez Oracle ismerettel és közép szintű angol nyelvismerettel rendelkezik.

Munkavégzés helye: Budapest

Jelentkezés:
Hosszú távú, kölcsönös együttműködésre alapuló munkakapcsolat kialakítása érdekében várjuk jelentkezését.
Jelentkezését csatolt fényképes magyar és angol nyelvű szakmai önéletrajzzal, motivációs levéllel, referencia megjelölésével az alábbi címen várjuk: zsolt.soczo@gmail.com

Eddig mindig, minden zökkenőmentesen ment a CIB-bel, de most megleptek.
16-án átutaltam az autók adóját, de véletlenül rosszul adtam meg az egyiket, ezért az internet banki rendszerükön üzentem, hogy vonják vissza.
Erre ma, 19-én, 3 nap múlva válaszolnak, hogy 1. nem lehet így visszavonni, csak telefonon, 2. ezt tárgynap 18 óráig lehet megtenni. Hasznos infó ez 3 nap múlva.

Nincs belőle dráma, majd beszélek a Diósdi adóhivatallal, hogy mi legyen a plusz pénzzel, csak szokatlan a CIB-től ez a válaszidő, illetve, nevetséges 3 nap múlva írni, hogy az utalást aznap 18 óráig lehet visszavonni. Legalább használtak volna múlt időt. :)

——————————

Tisztelt Soczó Zsolt!
Köszönjük, hogy hozzánk fordult kérdésével, mert így lehetővé tette, hogy teljes körű tájékoztatást nyújtsunk Önnek. [Nagyon hepi vagyok.]
Tájékoztatni szeretném, hogy tétel visszavonásra e-mailben nincs lehetőség. A tétel visszavonására a megadás napján 18 óráig van lehetőség telefonon keresztül a Cib24 ügyfélszolgálatán illetve személyesen bármely CIB bankfiókban.

Kérem, további kérdéseivel is forduljon hozzánk bizalommal! [Most aztán megnőtt a bizalmam, biztos írok még sokat ide.]

Üdvözlettel,
1 from many

Tavaly februárban elromlott a kazánunk, vettünk egy újat. A régi hagyományos cirkó volt, az új kondenzációs. Tavaly 277m3/hó volt a gáz átalányunk, most 210-re lőtték be.
Nyilván függ az időjárástól, menyire fűtünk be, mennyit vagyunk házon kívül stb, de a változás szerintem elég szignifikáns ahhoz, hogy a kazánra foghatjuk. 25% a diff, ami elég jelentékeny.

Még nem néztem, mi van benne, de VS SPknél nem szoktam agyalni, felrakom.

Amikor profilerrel megnézünk egy .NET kódot sokszor megdöbbentő helyen lesz benne bottleneck.

Az alábbi kód 1% időt visz el egy nagyon processzorintenzív kódban:

if (bar.L == 0)

Ami ebben lassú, az a System.Decimal.op_Implicit(int32). A bar.L egy decimal. Érdekes, mi?
Mi a megoldás? A 0 legyen valóban decimal, de int, amit konvertálni kell:

if (bar.L == 0M)

1% kevés, de sok 1% már számít.

Ha az insert table with (tablock) módon írjuk a lekérdezést, és az heap, akkor bulk insert lesz a sima insert. Nem kevés idő megtakarítást jelent ez.

Pár napja amikor elaltatom a gépet, azonnal felébred.

powercfg -devicequery wake_armed

Dell Wireless 1510 Wireless-N WLAN Mini-Card
Intel(R) 82567LM Gigabit Network Connection

Kiderült, hogy egy nemrég felrakott termék beállította a második hálókártyánál, hogy ébressze fel a gépet. Az volt a céljuk szerintem, hogy a wake on lan menjen, de ennél többet állítottak be, ez külön opció.

A fenti cím egy filmé, ami engem annak idején nagyon megfogott, Bálintot is, most is ezt nézi, ezt kérte (aztán Hawking egy új filmje jön, azt én is megnézem).

Az eleje elég depis, de a végén próbál optimista lenni.
Én is az voltam a hét elején, amikor az M1 mellett láttam a tucatnyi szélgenerátort. Végre valami jó dolgot láttam itthon.

Ha egy SQLCLR eljárásból kell meghívni valamilyen külső komponenst.
A trükk az, hogy a külső assembly-t is be kell telepíteni az SQL serverbe CREATE ASSEMBLY-vel, mivel az csak onnan hajlandó betölteni assemblyket (pár fw. alap dllt kivéve).

SQL tanfolyamot tartok egy cégnél (.NET 4-et és Design Patternst meg egy másiknál :). Az oktatások arra jók, hogy mindig rájövök mit nem tudok, így aztán van módom újat tanulni. Azt meg általában szeretek. :)

Na szóval, ha a szerver oldalon történik egy exception valamilyen sql parancs végrehajtási hiba következtében, akkor ez szépen látszik a profilerben, csak az nem, mi váltotta ezt ki.
Most lapozgattam az Inside Microsoft SQL Server 2005: Query Tuning and Optimization könyvet, és ott belefutottam a megoldásba.
Nem csak az Errors And Warnings: Exception eseményt kell bekapcsolni, hanem a User Error Message-et is.
.
A képen látható, az EventSequenceből szépen összerakható az események egymásutánisága.
Ez megint egy olyan apró kérdés volt, amit 5 perc guglizás megold, de hát nem ilyenekkel van tele az ember feje?

Már el is felejtettem, hogy van ilyen. Öregszem. :)

.NET 4-es tanfolyamhoz írok egy prezentációt. A co és -contravarianciát próbálom érhetővé tenni. Kb. ez van a slideokon:

Variance annotations – covariance 1.

class Allat { }
class Kutya : Allat { }

interface IAllatGyar<T> where T : Allat
{
    T Create();
}
class AllatGyar<T> : IAllatGyar<T> where T : Allat
{
    public T Create()
    {
        return default(T);
    }
}
AllatGyar<Kutya> kutyagyar = new AllatGyar<Kutya>();
IAllatGyar<Allat> allatGyar = kutyagyar; //cast, jogos?
Allat a = allatGyar.Create(); //mit ad vissza, típusbiztos?

Type ordering
Kutya <: Allat - A Kutya az Allat osztály leszámazottja
k : Kutya - k a Kutya típus egy példánya
Ha k : Kutya és Kutya <: Allat, akkor k : Allat (Liskov féle helyettesítési elv)
Igaz-e, hogy ha Kutya <: Allat, akkor IAllatgyar< Kutya > <: IAllatgyar< Allat > ?
Egy Kutya példány implicit castolható Allattá. Az Allatgyar< Kutya > típusbiztosan castolható-e Allatgyar< Allat >-tá?
Ha csak kimeneti paraméterként vagy visszatérési értékként jön ki T, akkor igen, mert Kutya <: Allat, így minden kimeneti paraméternél a Allat referenciával biztonságosan elérhető egy leszármazott Kutya példány is.
Ha igen, akkor T covariant, mert a típusparaméterek type orderingje érvényes a típust használó generikus típusra is, ugyanabban a sorrendben (Kutya <: Allat ==> IAllatgyar< Kutya > <: IAllatgyar< Allat >).
C# 4-ben az interfész metódus vagy delegate szignatúrában az out kulcsszó jelzi ezt:

interface IAllatgyar<out T>.

Amikor ez nem megy:

class Allat { }
class Kutya : Allat { }

interface IAllatGyar<T> where T : Allat
{
    T Create();
    void Valami(T t); //T befelé megy!
}

AllatGyar<Kutya> kutyagyar = new AllatGyar<Kutya>();
IAllatGyar<Allat> allatGyar = kutyagyar;

kutyagyar.Valami(new Kutya()); //Ez nyilván ok

allatGyar.Valami(new Lo());    //És ez???

Ha bemeneti paraméter is T, akkor az IAllatgyar< Allat > statikus típuson, amely valójában a IAllatgyar< Kutya > dinamikus típusra mutat átadható lenne más állat is, pl. Ló, amely szintén Allat leszármazott, de az nyilvánvaló runtime hibát okozna. Ezért nem lehet covariant T, ha az interfészen bemenetként is szerepel T.

Érhető ez így? Bármilyen javaslatot szívesen fogadok. A delegatekhez is írok persze anyagot, ez csak az eleje.

Double checked lockingnak indult, de bug lett belőle. Mit rontottam el?

private static volatile Dictionary<DateTime, Pair<TimeSpan>> holidayDays;
private static readonly object staticLock = new object();

private Dictionary<DateTime, Pair<TimeSpan>> GetHolidayDays()
{
    if (holidayDays == null)
    {
        lock (staticLock)
        {
            if (holidayDays == null)
            {
                holidayDays = new Dictionary<DateTime, Pair<TimeSpan>>();
                FillTradingHours(holidayDays, "HOL");
            }
        }
    }
    return holidayDays;
}

Felírom magamnak, hasznos lehet.
http://www.sommarskog.se/share_data.html

BUÉK minden kedves olvasómnak.

Az előző év eléggé bizi volt. Első félévben sok munka, második félévben ATS fejlesztés. Emiatt nem sokat blogoltam, meg semmi egyéb jelentős szakmai közösségi életet nem éltem. Emiatt az őszi MVP önértékelést be se adtam, nem szeretek úgy megkapni valamit, ha úgy érzem nem érdemeltem meg.
Így 2011. január 1-től már nem vagyok MVP. 7 évig folyamatosan az voltam, köszönöm a Microsoftnak a bizalmat és magát az elismerést.
Az idei évet most tervezem meg, próbálom meghatározni a arányokat: az ügyfélmunkák, a trading és a közösségi dolgok súlyát. Mindenesetre tervem, hogy idén újra többet fogok írni, konf előadást is vállalok, ha lesz olyan, amihez értek, így várhatóan megint többet lehet majd látni.
Sajnos az agyam egyszálú, ezért ha pl. elkezdek programolni, akkor amíg meg nem oldom az adott feladatot, addig elvonulok a világ elől, mert hajt, hogy még nincs meg a megoldás. Blogolni meg így nem lehet. Szóval idén megpróbálok ebben valami kompromisszumot kialakítani. :)

BUÉK még egyszer mindenkinek! :)

http://www.dofactory.com/Patterns/PatternSingleton.aspx

A mellékelt példakódban valami nem igaz. Mi?

Mostanában elég sokat turkálok problémás webappok dumpjában. Leírom magamnak is, hogy lehet lementeni .NET stringeket a dumpból.
WinDbg dolgok következnek.

A nagy stringeket kilistáztatom a
!DumpHeap -min 100000 -type System.String
paranccsal.

Valamelyik heapről kinézek magamnak egyet, és az előbbi parancs kimenetének első oszlopában található címet felhasználva belenézek a du cím paranccsal.
Pl.
0:000> du 5ce31140
5ce31140 “*****<sitecore database=”SqlSer”
5ce31180 “ver”>.. <sc.variable name=”da”

Az elején a kuszaság (átírtam csillagokra, mert elrontotta a htmlt) a .NET Stringek adminisztrációja és az object header.
Ha szemre tetszik a string, akkor pl. ki akarom menteni fájlba.
Nézzük meg a szöveges rész előtti bináris részt (dd).

0:000> dd 5ce31140
5ce31140 793308ec 00040001 0002836c 0073003c
Az első 8 byte az object header (32 biten, 64-en ez asszem 16 byte), sync block és type leíró. Számunkra ez érdektelen. A 3. dword már érdekesebb, ez a string hozza karakterekben. Azaz bájtban ennek a duplája, mert 2 bytes unicode ábrázolást használ a .net.
Így stringünk hossza 0002836c*2 byte. A 0073003c már a < karakter (003c) és az s betű (0073), szokásos fordított Intel sorrendben.
A szöveges tartalom tehát a 5ce31140+0c címen kezdődik (headert átlépjük), és 0002836c*2 a hossza.
A tartalom fájlba írása már egyszerű:
.writemem c:\temp\s1.txt 5ce31140+0c L0002836c*2

Kedvencem a WinDbg, de ezt már mondtam. :)

Az utóbbi időben nagyon csendben voltam, ennek az volt az oka, hogy a sok első féléves munka után azt mondtam, hogy most már itt az ideje komolyabban venni az automatikus trading rendszer írását, és nem csak éjszakánként fejleszteni. Ez egy rengeteg erőforrást zabáló, intenzív kutatási és programolási kaland volt, ilyenkor nincs erőm/kedvem blogolni. Volt benne sok frusztráló pillanat, amikor már fel akartam adni.
De a sok munka úgy néz ki kifizetődő. :)
Közel 4 hete már élőben fut a rendszer, és azt hozza, amit a backtest ígért. %-ot, stb. szándékosan nem mondok, de jelentősen több, mint egy befektetésé. Másként minek öltem bele 2 évet?
Hogy ez mennyire stabil hosszabb távon? Ezt csak a Jóisten tudja. 319 trade történt eddig, az statisztikailag már elég jelentős, így bízok benne, hogy stabil lesz a rendszer hosszabb távon is.

Az alábbi kép pár napja készült, ami egy ritka idegbeteg nap volt, akkor jelentette be a FED, hogy 600 milliárd dollárt tol be a gazdaságba.

A 3. trade 1.5 percig tartott. :)

Jelenleg 8 future termékkel (az alapjuk deviza, stock index és állampapír), 16 egyedileg paraméterezett algoritmus példány tradel. Hosszabb távon ennél több lesz majd, hogy lehetőleg ne legyenek olyan napok, amikor szívinfarktust kapok. A 2. nap pl. ilyen volt, akkor 2000$ bukót kellett lenyelnem.
Az egész tőzsdében ez a legnehezebb, a pszichológiai rész. Egyensúlyozni a mohóság és a félelem övezte mezsgyén. Félelmetes dolog ez, igencsak megmozgatja az ember emócióit. Ezt kell persze levetkőzni, ez a lényege az egésznek. Most pénteken pl. nem sikerült, és nem indítottam el csütörtök éjszaka, csak péntek délután, annyira megégetett az előbb írt veszteség. Pedig ilyenek törvényszerűen vannak, benne vannak a backtestben is. Csak más dolog statisztikákat nézni, meg más átélni. Mellesleg jót keresett volna a kieső időben, nem volt idegbeteg nap, mint egy hónappal korábban. Ez alap hiba volt, kifizettem a tanulópénzt.
Technológiai hátterét tekintve W2k8 R2, IIS7, .NET4, EF4, WPF, WCF, SQL Server 2008 R2, SQL Reporting Services alapú a rendszer. Elképesztő sebességeket lehet elérni .NET4-gyel, csak rendes design és odafigyelés kell hozzá. Meg sok profile-ozás. :)
Az SQL Serverben 15 milliárd sor van egy táblában, és teljesen jól lehet kezelni. Ez is tervezés és indexelés kérdése.

Akit érdekel a téma, az alábbi tőzsdés könyveket ajánlom, nekem ezek segítettek:
Come Into My Trading Room: A Complete Guide to Trading
High Probability trading
The Encyclopedia of Trading Strategies
New Trading Systems and Methods
Cybernetic Trading Strategies: Developing a Profitable Trading System with State-of-the-Art Technologies
Reading Price Charts Bar by Bar: The Technical Analysis of Price Action for the Serious Trader
Technical Analysis: The Complete Resource for Financial Market Technicians (nekem az első kiadás van meg)
Quantitative Trading Strategies: Harnessing the Power of Quantitative Techniques to Create a Winning Trading Program
Quantitative Trading: How to Build Your Own Algorithmic Trading Business
High-Frequency Trading: A Practical Guide to Algorithmic Strategies and Trading Systems
Professional Stock Trading: System Design and Automation
Trading Systems That Work: Building and Evaluating Effective Trading Systems
Mechanical Trading Systems: Pairing Trader Psychology with Technical Analysis
The Evaluation and Optimization of Trading Strategies
Evidence-Based Technical Analysis: Applying the Scientific Method and Statistical Inference to Trading Signals
Short Term Trading Strategies That Work
Trade Like a Hedge Fund: 20 Successful Uncorrelated Strategies & Techniques to Winning Profits