Kedves Olvasóim,
boldog Karácsonyt nektek.
Idén megszakadtam a munkától, így szinte alig írtam, pedig rengeteg új dolgot tanultam: Oracle, NHibernate, WCF mélységei, WPF perf tuning, stb. Jövőre remélem sikerül kidumpolni az agyamból ezeket, mert -főleg az NHibernate- nagyon jó dolog. EF elment szabira, mióta megismertem. :)
Csak nálam van mostanában, hogy nem lehet hívni, és én se tudok másokat hívni, de az sms és az adatkapcsolat megy?
A készülékem döglődik, vagy a telenor?
Meg kell adni a regisztrációjakor explicit, ha azt akarjuk, az legyen.
public static readonly DependencyProperty MyPropertyProperty =
DependencyProperty.Register(
"MyProperty",
typeof(int),
typeof(Window1),
new FrameworkPropertyMetadata(0, FrameworkPropertyMetadataOptions.BindsTwoWayByDefault));
1 órámat ismét elvittek. :)
Ezt Bálint (7 éves) kérdezte (iskolában hallotta), a válaszként azt mondtuk, hogy piszkálni.
-Jó, akkor megdugom Pannit.
:)
Az előző post kommentjei alapján (amit nagyon köszönök mindenkinek) nem kaptam sok bátorítást az aszinkron, queue alapú, kérés-választ különválasztó gazdag kliens - szerviz kommunikációhoz, úgy tűnik senki nem csinált ilyet, így nem akarok úttörő lenni a témában.
Ehhez még hozzájárul, hogy hétvégén méregettem az MSMQ teljesítményét. Azért ezt, mert a WCF is erre épít, és pl. az NServiceBus is.
A tesztkód 1.5kByteos üzeneteket rak át egyik sorból a másikba. Az ötlet innen jött, csak többszálasítottam.
A tesztkód:
using System;
using System.Diagnostics;
using System.Messaging;
using System.Threading;
namespace MsmqTran
{
class Program
{
private const int NumberOfTests = 1000;
private const int MaxDop = 10;
private static readonly ManualResetEvent[] WaitForEmpty = new ManualResetEvent[MaxDop];
static void Main()
{
var q1 = new MessageQueue(@".\private$\test_queue1");
var q2 = new MessageQueue(@".\private$\test_queue2");
Console.WriteLine("Filling source queue...");
var b = new byte[1500];
using (var msmqTx = new MessageQueueTransaction())
{
msmqTx.Begin();
for (int i = 0; i < NumberOfTests; i++)
{
q1.Send(b, msmqTx);
}
msmqTx.Commit();
}
q2.Purge();
Console.WriteLine("Starting to move data from source queue to destination queue");
var sp = Stopwatch.StartNew();
for (int i = 0; i < MaxDop; i++)
{
WaitForEmpty[i] = new ManualResetEvent(false);
ThreadPool.QueueUserWorkItem(o => ProcessMsg(q1, q2, (ManualResetEvent)o), WaitForEmpty[i]);
}
WaitHandle.WaitAll(WaitForEmpty);
Console.WriteLine("Duration: {0}ms, throughput: {1:F0} messages/s", sp.ElapsedMilliseconds, 1000.0 * NumberOfTests / sp.ElapsedMilliseconds);
}
private static void ProcessMsg(MessageQueue q1, MessageQueue q2, ManualResetEvent w)
{
while (true)
{
using (var msmqTx = new MessageQueueTransaction())
{
msmqTx.Begin();
Message message;
try
{
message = q1.Receive(TimeSpan.FromMilliseconds(0), msmqTx);
}
catch (MessageQueueException e)
{
Console.WriteLine(e);
w.Set();
break;
}
q2.Send(message, msmqTx);
msmqTx.Commit();
}
}
}
}
}
A gépemen 50 tran/sec-kel megy 1 szálon, és 200 fölé nem nagyon megy. Jó, ez laptop, de relációs adatbáziskezelővel (sql server és oracle is fut a gépen) több ezer tran/seccel mennek a dolgok. Szóval ez elég gázosan lassú. Emellett csúnya leállásokról is írnak a blogokban, amikor beáll az msmq.
Marad a aszinkronított WCF egyelőre, csak a szerverről visszafelé hívásokat tervezem queue alapon megcsinálni, WCF msmq bindinggal. Így tudom értesíteni az appokat polling nélkül. Erre 3 okom van most:
1. Az offline (disconnected) pessimistic lock feloldódott, lehet szerkeszteni valamit.
2. Frissíteni kell a kliens cache-ben valamit.
3. Email jellegű üzenetküldés az appok között.
Köszönöm még egyszer az építő javaslatokat.
Próbálom megtörni magamban a megszokott gondolkodási sémákat. Tervezek egy nagy, többrétegű LOB alkalmazást. A szervizrétegnek elsődlegesen a WPF rich klienst kell kiszolgálni, de jó lenne, ha mobil kliensek is tudnák ezt fogyasztani.
Ha a szerviz interfész finom felbontású, sok kicsi metódussal, akkor a kommunikáció sok időt rabol el, lassú lesz az app (chatty interfész).
Ha durva felbontású (chunky), akkor megvan a veszélye, hogy a fogyasztó WPF app formjaihoz lesz illesztve, célirányosan, így akkor meg mobil kliensek nem fogják tudni hatékonyan fogyasztani.
Egy érdekes alternatívát láttam a probléma feloldására itt és itt.
Ebben az összes kliens-szerviz kommunikáció message alapú, teljesen aszinkron. Egy kitöltött form adatait elküldik egy queueba, a szerver pedig egy másik üzenettel válaszol erre. Azaz a kliens alapjaiban aszinkron, és a válaszok események formájában jönnek vissza.
A message alapú kommunikáció nagy előnye, hogy az üzeneteket össze lehet nyalábolni, és egyben elküldeni. Így a szerviz lehet finom felbontású, de a kommunikáció mégis gyors, nem sok kis darabból áll. Érthetően ezt szinkron, rpc jellegű szerviz hívásokkal nem lehet megcsinálni.
Ez a fajta queued, service bus alapú gondolkodásmód szokatlan nekem, de nagyon szimpatikus. Van valakinek tapasztalata ilyen rendszer tervezésével? Bármilyen url, pointer, könyv, személyes tapasztalat érdekelne. Úgy érzem nagy dolgokat lehet ezzel összerakni, csak meg kell alaposan értenem.
Még egy gondolat. WCF proxyk használatával az alapban message alapú, asszinkron kérés-válaszokból összeraknak egy RPC jellegű kommunikációt, úgy, hogy a kliens vár a szerver válaszára. Aztán a kliens kedvéért, hogy ne blokkoljuk le a GUIt csinálunk háttérszálat, ahol bevárjuk a szerviz válaszra váró szálat. :)
Miért nem használunk eleve aszinkron üzenetváltásokat, és akkor sokkal egyszerűbb lesz a kép. A kliens bepostázza a kérést a buszra, és megy tovább. Amikor a válasz megjön, akkor meg erről eseményben értesül. Nyilván itt is vannak háttérszálak, hisz ki fogadná akkor a szervertől jövő választ, és ki hívná vissza a kliens eseményeken keresztül, de valahogy akkor is tisztábbnak tűnik a kép, mint az erőltetett RCP-jellegű módszernél. Nem?
Pár hónapja vettem egy Kindle DX-et. Nagy érvágás volt, tokkal, vámmal 570$ volt, ami fájt. De nagyon nem bántam meg, és ezt nem a kognitív disszonancia mondatja velem. :)
Amióta megvan, sokkal többet olvasok. Az elmúlt két hónapban legalább 20 könyvet és vagy 30 kisebb cikket tanulmányoztam benne. Nem mindet olvastam ki A-tól Z-ig, de tudjuk, hogy a szakmai könyveket nem is mindig így szoktuk (max., ha új területről van szó).
Ha van pl. egy codeproject, msdn, stb. cikk, vagy egy whitepaper, bármi, ami pár oldalnál több, már nyomom is rá calibre-vel, aztán olvasom az ágyban (kocsiban váráskor, játszótéren, dokinál, stb.).
És még nem használom ki csak tört részét annak, amit lehetne vele olvasni (hírek, blogok, stb.). Az esti mese is erről megy, a mekről. :)
Szóval imádom, aki szeret olvasni, szeretni fogja. A technikai speciókról nem írok, ez olyan, amit látni kell, aztán vagy utálod, vagy szereted.
Az üzleti igény egy olyan adatbázis struktúra létrehozása, amelyben az előre definiált táblák adatai mellé a kusztomerek saját maguk is fel tudnak venni plusz adatokat, anélkül, hogy ehhez az adatbázistáblákat és az alkalmazást módosítani kellene. Sajnos nem csak letárolják ezeket, de még keresni is akarnak egyesekre. Azaz egyfajta open schemat kellene megvalósítani. Erre jó lehet az Entity-Attribute-Value megoldás, de úton-útfélen gonosznak van kinevezve. Értem én, hogy szar belőle lekérdezni, marha nagy lehet, ha egyszerűen csinálják meg nem típusos (én minden típushoz akarok egy oszlopot létrehozni), de milyen használható alternatíva van vele szemben?
Olvastam a serialized blobot, pl. egy xml oszlopba rakjuk a plusz dolgokat. Elvileg lehet xqueryzni, meg indexelni, de érzésre ez se egyszerű, se gyors nem lesz.
A sparse colum esetén séma módosítással jár az új adat definíciója. Ez egyrészt nem tetszik secu okokból (alter table kell hozzá), másrészt elég gáz szervizelni az alkalmazást, ha 50 ügyfél saját oszlopokkal bővítheti a tábláinkat.
Szóval, mi a jó a feladatra? Nekem még mindig az EAV tűnik a legkezelhetőbbnek.
Apa, azt a cifra ruhás nénit miért az önkormányzat tartja el? :)
(Meséltem feleségemnek mit hallottam az orvosi rendelő várójában, Bálint is hallotta, és ügyesen kiszedte a lényeget. :)
Időben el kell kezdeni az ifjúság nevelését, kurva világ lesz itt, ha nem lesz öntudatosabb a következő generáció.
Meglegyintett a sötét oldal, ezért kénytelen leszek kicsit érteni az Oracle-höz is. :)
Tud valaki jó könyvet, ami valamiféle SQL Server - Oracle turbó átképzésről szól? Nem akarom a create table-nél kezdeni, ikább valami diff könyv kellene.
Persze, lehet ez nem ilyen egyszerű, el kell kezdeni valami Essential Oracle könyvvel.
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.
