Voltunk ma Sheryvel a CSI kiállításon, nem mondom, hogy rossz volt, de a reklám alapján többre számítottam. Aztán lehet csak fiatalabbak vannak megcélozva vele.
Csütörtökön Gergő kollégám jóvoltából a Szépművészeti Múzeumban lévő "Botticellitől Tizianóig" kiállítást néztük meg a munkatársakkal. Ez mondjuk nem az én világom, de azért volt ott pár szép/érdekes kép.
Kappét - aki valszeg már megérkezett Új-Zélandra - pedig üdvözlöm, ha sikerül net közelébe kerülnie 
Hétvégén a címben szereplő rendezvényen - azaz iaido versenyen - vettem részt. Na nem azért mentem el, mert akkora nagy májer lennék, hanem mert a mesterünk, Patrik sensei jött el, vezette a szombati edzést, illetve továbbképzést tartott a magyar bíráknak, aztán lássa már, hogy élnek még az emberei
Nem is jutottam tovább a körmérkőzéseken, de nagyon jól éreztem magam, és rendesen elfáradtam. Majd jövőre megmutatjuk, amikor már remélem nem csak Zsolt és én versenyzünk majd
[valami videófoszlány lehet érkezik majd]
A hétvégét edzéssel töltöttem, elég intenzív volt, kb. mindenem izomlázas egy kicsit. Nagyon jó volt, szerintem jól tudtunk haladni, ha minden jól megy, akkor hónap végén még egy iaido versenyen is képviselni fogom a csapatot (na nem mintha annyira jól menne, bár állítólag nem is megy olyan rosszul).
Íme egy kép, ezúttal joval:
Kellemes ünnepeket kívánunk minden kedves erre tévedőnek!
Kicsit sűrű volt a hét, ma sikerült először megfelelő mennyiségűt aludnom.
Szerdán edzés után ültünk be beszélgetni egy kicsit karácsony alkalmából, én marcipánból csináltam egy kardot és egy jo-t, amit közösen elfogyasztottunk Csütörtökön a bitnetes srácokkal vacsiztunk együtt.
Tegnap volt a cégnél karácsonyi party, a hangulatnak megfelelően, Szinetár Dóra & Bereczki Zoltán, a Princess és Szentpéteri Csilla lépett fel, nekem tetszett.
Aztán később a volt Siemenses kollégákkal futottunk össze annak apropóján, hogy itthon vége a projectnek sajnos. Ennek ellenére megvolt a szokásos hangulat, sőt, Kaliforniát megjárt Zolitól egy macis rendszámtáblát is kaptam
Ha a lenyúlásoknak van diszkrét osztályozása, akkor ez valszeg a "szó szerinti másolás" utáni második fokozat, ráadásul épp a Microsoft által elkövetve - ráadásul épp nemrég volt egy hasonló ügyük. Vad. Persze alvállalkozó volt bizonyára most is.
Egyébként a Plurk szimpatikus próbálkozás, bár én nem szeretem a mikroblogokat, de ha szeretnem, akkor tetszene 
És ott dolgozik Armin Ronacher, akire a python iránt érdeklődőknek érdemes odafigyelni, talán még húsz éves sincs, de már olyan dolgok fűződnek a nevéhez többek között, mint a Jinja és a Werkzeug.
A hétvégét - illetve péntek/szombat/vasárnap - a cégcsoport kb. háromnegyedével együtt Blumauban töltöttem, és igen jól éreztem magam.
A helyet Hundertwasser tervezte, és nagyon tetszett az egész, bejött, hogy nincs sehol két egyforma részlet. Azt mondjuk nem tudom, hogy lakni milyen lehet ilyen helyen (pláne takarítani a sarkokat ), de rövid időre kikapcsolódni tökéletes.
Odafele érintettük Semmeringet, az eredeti terv az volt, hogy majd ott szánkózunk, de ez hó hiányában elmaradt sajnos, úgyhogy sípálya mászás és hógolyózás lett helyette, illetve a lelkesebbek szemeteszsákon azért le tudtak csúszni, annyi hó volt.
Aztán Blumauban fürdés és buli, minden szempontból frankó a hely, a szaunában igazi gőzmester osztotta az áldást néha, nem kis szakértelemmel.
Szombat délután curlingezni mentünk, de nem jégen, hanem betonon. Annyira nem fogott meg a dolog, szinte jobb volt szögeket beverni egy tuskóba a kalapács hegyes felével - ez állítólag osztrák nemzeti játék, és a lenyege az volt, hogy amikor valaki beverte a szögét, akkor annak forralt bort kellett fogyasztani, akinek meg sokáig nem sikerült eltalálnia, annak meg azért, a többieknek meg csak úgy
Én is csináltam néhány képet, de a céges oldalon vagy egy csomó.
A hétvégén pofátlanul egyszerű csokis csillag sütiket csináltunk - Shery találta a "receptet" valami Milkás reklámban, csak mi nem tejcsokit használtunk, hanem igazibbat.
Annyi az egész, hogy levelestésztát kinyújt az ember, kiszaggatja, középre egy kocka csoki, tetejére mégegy réteg tészta, tojással megkenni, be a sütőbe, és kész.
Hmm, kinézek az ablakon, és itt legel egy rénszarvas a tuják mellett...
...aztán kicsit később megérkezett maga a Mikulás is, aki pont úgy nézett ki, mint Rudolf Péter, és teljesítette a még kedden összegyűjtött kívánságainkat, minket pl. "pókerezni tanított"
Egyébként minden tiszteletem, nagyon kedves volt, és igen frankó műsort hozott össze!
Tök jó, hogy van pythonban pl. operátor overloading - én legalábbis szeretem, DE:
TM = list class MyList(TM): def __add__(self, a): return [self[a[0]]] >>> a = MyList([1,2,3,4,5]) >>> isinstance(a, list) True >>> a + [1] # ez lista osszefuzes lenne [2]
Ilyesmit azért illetlenség csinálni, randa dolgokat eredményezhet, ha egy olyan függvénynek adunk egy ilyen objektumot, ami listát vár. Persze ennek a fordítottja is igaz, és nem csak elrontani tudunk így dolgokat, de megszépíteni is.
Az Class(TM) élő példa, bitbucketen láttam valahol
Elég rég nem volt szétkapva a kardom, ráfért már egy nagyobb generál, úgyhogy ma rendbe raktam, minden rész passzos, semmi sem lötyög. Aki még nem látott katanát szétszedve, annak íme egy kép:
Épp nemrég számoltam utána, hogy Zsolttal már több, mint nyolc (8) éve edzünk együtt. Ez alatt az idő alatt kb. egyszer sem vágtam meg magam, eddig Már nagyon csúszkált a kard a hüvelyében, ezért a múltkor kicsit tuningoltam rajta, és már nem kevésbé csúszik ki. Mikor ma mutatni akartam valakinek, hogy hogy sikerült a tuning, akkor mégis kicsúszott, én meg reflexből a hüvelyt fogó bal mutatóujjamat rácsaptam - az élére. Nem éles, szerencsére, és a körmöm is ott volt, de azért két-három milliméter hideg acél átsuhant az ujjam hegyén
(az a körmömön nem odafolyt, hanem úgy átvágta, és nem, egyáltalán nem éles)
A lényeg, hogy ennél nagyobb sebesülés sose érjen.
Valaki kérdezte, most megmértem, a kardom 952 gramm.
Vad levelet kaptam ma az "OTP banktól".
Received: from User ([66.80.47.199]) by florence.cdhk.cdhklaw.com ... From: OTP Bank <service@otp.hu> Subject: Fontos! Tisztelt Ьgyfelьnk! Ez a hivatalos йrtesнtйst arrуl, hogy a hitelkбrtyбjбt korlбtozott volt. A kцzelmъltban felьlvizsgбltбk a kбrtyбt, йs ъgy tűnik, hogy a vele kapcsolatban бllу tцbb mint 1 szбmlбk. Цsszekapcsolja a hitelkбrtya tцbb sokszoros szбmlбk szigorъan tilos, йs azt is tцrvйny bьnteti. Цn most mбr felkйrtйk, hogy nyъjtson informбciуkat a hitelkбrtyбjбt. Az OTP Bank azonnal kivizsgбlja az ьgyet, йs ha a vizsgбlatot az Цn javбra fogjuk visszaбllнtani a fiуkjбt. Hogyan бllнthatom vissza a szбmlбjбt? ...
Amellett, hogy valami érdekes kódlappal íródott (gyanúsan orosz), és rosszul formázott HTML volt az egész, az is kiderült, hogy az OTP valszeg csak a google translate segítségével tud magyarul, illetve, hogy a honlapjuk a http://[valami ipcim]/otp.hu/include.php oldalon található
Az oldal persze ugyanúgy néz ki, mint az OTP rendes oldala, csak gondolom saját céljaikra teszik el majd az emberkék adatait. Egy picit finomodnak, és simán sok ember bedőlhet nekik...
Aki valaha részt vett már valami "nemzetközibb" dologban, esetleg programozott is már, az valószínűleg találkozott már az időzónák problémájával.
Java fejlesztő kollégák közül néhányan kicsit belegabalyodtak a Date és Calendar osztályok, illetve az időzónák kezelésébe, a Java és a MySQL összebarátkoztatásánál. Annyit segítek azért azoknak, akik ezután fognak ilyesmivel találkozni, hogy hasonló szituációkban az eltárolt időt ne misztifikáljuk túl, tekintsünk rá úgy, mint egy számra (mostmár jellemzően valami 64bites egész), ami nem több, mint egy szám, egészen addig, amíg egy felhasználónak meg nem mutatjuk. A megmutatás már messze nem ilyen egyszerű, mert akkor bejön az időzóna meg a nyári időszámítás, meg a mittomén. (Szóval a probléma kezelhető, de azért jobb lenne nélküle.)
Egyre sűrűbben előkerül a téma, hogy el kéne felejteni a téli-nyári időszámítás átállást, mert amellett, hogy felesleges (a google szerverei pl. nem a nappal kellnek, és nem este 10-kor fekszenek le...sőt az, hogy este 10, az igazából értelmetlen önmagában...), milyen már, hogy vonatok várnak egy órát az semmi közepén, hogy "időre" érjenek be a következő állomásra. Támogatom.
Sőt, mégtovább megyek, legyen mindenhol UTC (vagy bármi más, de egységes). Amíg az emberek csak olyan messzire mentek el egy nap, hogy a templomtoronyra rálássanak, addig persze mindegy volt, hogy a szomszéd faluban esetleg tök mást mutat a toronyóra - bár már ekkor előjött a probléma, még ha csak gondolati síkon is, emlékezzünk csak Mr. Phileas Foggra, aki 80 nap alatt kerülte meg a Földet, és "nyert" egy extra napot azzal, hogy átment a dátumválasztón.
Nade ma már nem nem csak a toronyóra látótávolságáig merészkedünk el, hanem egyszerre beszélgetünk (mi, CEST: GMT+1 +1DST) finn (EET: GMT+2 +1DST), amerikai (Texas: GMT-6 +1DST) és fülöp-szigeteki (GMT+8, nincs DST) srácokkal, ilyenkor marha egyszerű időben leegyeztetni bármit is. És a kiragadott példa valós, egy multi cég sem kellett hozzá, csak egyetlen darab szerver, és közös hobbi.
Vagy mi van az űrhajósokkal, akik naponta közel 16-szor kerülik meg a Földet a Nemzetközi Űrállomással? Ők Willihez hasonlóan naponta 16 napot nyernek, vagy vesztenek? (wow, időutazás) És mi lenne, ha ők is a földi időzónák szerint mérnék az időt, úgy kéne bejelentkezniük, hogy "Hello Huston, minden OK, tizenkét óra huszon... nem, tizenegy óra huszon... ahh... faszom fél11leszvetelvege.
Persze megértem, hogy milyen "rossz" lenne, hogy mondjuk szegény japánok az eddigi "reggel" 6 óra helyett 21 órakor kelnének fel, de nem is 9-re járnának dolgozni, hanem éjfélre. És a világon mindenki tudná, hogy Londonban mikor van délutáni öt órai tea, 17 órakor. Még ha valaki épp akkor mosná a fogát valahol Indiában lefekvéshez készülődve.
Nehéz lenne megszokni biztos, de meg lehetne. Legyen 5 év az átállás, amíg mindenki mindenhova kiírja mind a kettőt, aztán utána már csak az UTC-t. Nem lenne sokkal rosszabb, mint a Forint - Euro átállás (bár ha így haladunk, nincs sokkal kisebb esélye az egységes időzóna korábbi bevezetésének :P).
Le az időzónákkal!
P.S.:
Ha viszont nem, akkor javaslom, hogy a déli féltekén toljuk el a hónapokat hattal, mert a Télapó télen kell, hogy jöjjön, Ausztráliában is.
Felmerült a kérdés, hogy érdemes lenne-e frissítenünk a jelenlegi (opencsw-ből jött, 5.0.51-es, tehát jó régi) mysql-ről újabbra. Nameg blackshepherd is olyan lelkesen tesztel, tesztelek én is akkor egy kicsit.
A vas (narancs) egy Intel SR2400-as, két darab kétmagos 3GHz-es Xeonnal, 4 Giga rammal, és Solaris 10u7-tel, külön ZFS-sel, teljesen alapértelmezett beállításokat használtam, amiken azért - mind oprendszer, mind db oldalon - lehet nem keveset csiszolni.
Sysbench-et használtam én is, 100000 soros táblával, egy tranzakciós-írós-olvasós és egy csak olvasós tesztet futtattam, semmi trükkös paramétert nem állítgattam. A mysql 5.4.3 RW tesztjét lefuttattam úgy is, hogy az innodb raw partíciót használ (illetve ZVOL-t), de szinte semmi különbség nem volt. Beszéljen helyettem a gnuplot:
Az szépen látszik, hogy a vegyes használatnál az innodb nagyot fejlődött - úgy fest a read-only teljesítmény rovására. Myisam esetében pedig kb. a fentebb említett tesztekben szereplő +20%-os teljesítménynövekedés látszik (bár rohadtul máshogy néz ki a grafikon, de közel sem annyira finom, kevés volt az időm sajna). Mindenesetre megéri az újabbat használni szerintem.
Ami viszont engem meglepett, az a postgresql, amit tényleg csak a suckIT féle tesztek miatt vontam be a tesztbe, de igencsak odacsapott... (mysql-lel azért több a tapasztalatom, pláne nagyobb terhelés esetén, de ideje a postgressel is lassan tapasztalatokat gyűjteni).
Adott ez a friss sebességrekord, hogy 15,5 terabit/sec-es sebességet sikerült elérni a 7000 kilométeres tenger alatti kábelen. Ezt a tudós kollégák ügyes marketinggel lefordítják 100 petabit/sec kilométerre vetített sebességre, ami jól hangzik, csak olyan szempontból nem igaz, hogy egy (azaz 1) kilométeren jó ideig a közelébe sem fognak érni. A sávszélesség szerintem kb. bármekkora távolságon 15,5 terabit/s lenne földi körülmények között, ezért ha a világ leghosszabb kábelét használják, akkor a legnagyobb "kilométerre vetített" sebességet érhetik el. [A zindexen meg egyenesen el is felejtik megemlíteni a tényeket, és csak a bulvár marad, kicsit átfogalmazva, ahogy egyszerűen nem igaz.]
A fény ugyanis 1 illetve 7000 kilométert elhanyagolható idő alatt tesz meg, legalábbis az opto-elektromos konverzióhoz és a számítógépeink jelfeldolgozásához képest. Tehát ezt a 100 petabit/s/km vagy milyen mértékegységű rekordot ugyanezzel a technológiával, csak egy jóval hosszabb kábellel felül lehetne múlni (szerintem).
A klasszikus adathordozókkal megrakott teherautós példa itt is alkalmazható. Ha a teherautót mondjuk 1 óra megpakolni, és 100 km/óra az átlagsebessége, akkor szinte mindegy, hogy 10 métert, vagy 100 métert megy.
Ennyit számít a marketing
Bizony már ennyire megöregedtem
A gimiben volt a találkozó - ahol ránézésre túl sok minden nem változott -, elég sokan eljöttek, mindenki elmondta, hogy kb. mi történt vele az elmúlt tíz évben, vacsiztunk, aztán beszélgettünk. A fő téma a szülés és a babák voltak, amibe én kevésbé tudtam beleszólni, de majd egy későbbi talin esetleg
Szerintem jól sikerült, én jól éreztem magam, köszi a szervezést!
Ha már megcsináltam, hogy tornado működjön rendesen Solarison is, akkor gondoltam meg is mérem, hogy mennyire rendes az - de legalábbis összehasonlítom az általunk használt hagyományos fascgi megoldással.
Igazából a tornadot nem WSGI appok futtatására találták ki, de azt is tudja, és hát egy tipikus python webalkalmazás belehelyezhető (jó esetben) egy WSGI konténerbe, úgyhogy miért ne. A tesztalkalmazás egy nagyon alap Django project lett, amiben nincs semmi, csak amit a django-admin.py startproject legyárt, illetve egy extra view, ami kiírja ügyesen, hogy Hello World!.
Hat féle felállást hasonlítottam össze, minden előtt volt egy nginx, azért is mert a cucc egy zónában futott, illetve mert a fastcgi-ket nem tudom közvetlen megszólítani "böngészővel":
A mérést az előzőhöz hasonlóan az apache féle ab programmal végeztem, a 1, 10, 100, 1000, 5000 és 10000 párhuzamos klienst szimulálva, az utolsó esetben összesen 50000, egyébként 10000 lekéréssel. Az áteresztő képességen kívül (request/sec) felírtam a kliensek 50/95/99/100%-ának kiszolgálási idejét (milisec). Utóbbi adatokból inkább nem rajzoltam grafikont
Az előzőhöz hasonló módon a teszt egy x86-os Solaris 10-on futott - nem ugyanazon a gépen -, és ugyanúgy minden tesztet háromszor futtattam le, a legjobb eredményt feljegyezve.
Grafikon az áteresztőképességekről:
Konklúzió: a tornado bizony jóval hatékonyabb, mint a sima fastcgik, pláne, ha egy többmagos/többprocesszoros gépen a processzormagok számának megfelelő mennyiségűt indítunk (...reméljük a GIL-től majd megszabadul a python, és akkor ki lehet használni a szálakat rendesen...). Ahogy látszik viszont a _Select alapú ioloopnak meg vannak a korlátai, ha valahol ezt vagyunk kénytelenek használni, ott nginx oldalon tudunk korlátozni, hogy ne kapjon egyszerre mondjuk ezernél több kérést.
Bár a haproxy gyengébben szerepelt, mint az nginx magában, az azért lehet, mert Solaris 10-en még nem támogatja az event ports féle pollingot, csak a régebbi /dev/poll féle megoldást - ennek ellenére jól teljesít, linux alatt valószínűleg ő nyert volna.
A lényeg, hogy a tornado úgy fest valóban képes megbirkózni a tízezer kliens problémájával, és django alkalmazások alatt is jól használható, ha sok klienst kell kiszolgálni.
A nyers számok, ha valakit érdekel: tovább...
Ez egy blog. A velemenyunk a mienk, ezert szubjektiv, es meglehet, hogy neha csak picit fedi az egyetemes igazsagot. Mellesleg akinek nem tetszik, az nezze helyette a tvt.
Egyebkent nyugodtan lehet idezni, kepeket toltogetni, szabadok vagyunk.
Ha esetleg valami szemelyes kozolnivalod van, amit nem szeretnel kommentbe leirni, akkor tobbek kozott elerhetsz minket a [akiacikketirta] kukac horak pont hu emailcimen.
