Spartacus nyomában

Visegrád – szláv eredetű szó, jelentése: magas vár, fellegvár

Az idén eddig már kétszer sikerült túrázni eljutnom, ami még mindig fájóan kevés, de legalább több mint tavaly. Júliusban sikerült megismernem a festői szépségű Spartacus-ösvényt, aminek bejárását mindenkinek javaslom.

Könnyű túrát terveztünk, úgyhogy gépesítve terveztünk helyzeti energiát szerezni, melyet ereszkedéssel kinetikus energiává alakítva kevés fáradtsággal tudunk élményekre szert tenni. A szervezés olyan körülményesre sikeredett, hogy az eredeti bivakolás később kempingezéssé szelídült, majd miután az időjárás-jelentés okozta vaklárma okán pár hettel korábban lefújtunk egy alkalmat ekkor már a szemerkeélő eső ellenére is elindultunk, igaz csak egy egynapos kiruccanásra.

Az eredeti útvonal helyett az utolsó pillanatban döntöttünk úgy, hogy a Dobogókő - Pilisszentlászló - Visegrád utat tesszük meg. A terv szerint az útvonal Dobogókőtől a piros háromszög, majd piros kereszt úton át megy Pilisszentlászlóra, ahonnan a zöld úton át Visegrádon ér véget.

Dobogókő

A busz lassan vonszolta magát, és bár a mellettünk folyamatosan szellentő kutya a busznak nem segített, de ez az élmény egléggé belém égett, hogy egy időre ne akarjak sárga buszra szállni. A gazdáját kiválóan szórakoztatta a szituáció. Valahogy én is kibírtam a szagokat.

Dobogókőn a szívcsakra helyett egy számomra nyomasztóan kiépített hely fogadott. Ha már így alakult, akkor egy finom kávét vettünk indítónak egy szimpatikus büfénél. Egy étteremnél az udvaron vaddisznó-pörkölt készült bográcsban a hívogató tábla tanusága szerint. Ezek az illatok végre kellemesek, hívogatóak voltak.

A Dunakanyar felé néző kilátót hamar megtaláltuk. A kilátás szép volt, de a borús idő miatt itt nem láttuk még a Dunkanyart teljes pompájában. Hallhattunk azonban részleteket a transzneműek szerepéről a StarTrek világában más túrázóktól. Úgy ítéltük meg, hogy túl sok itt a városi. Inkább utunkra indultunk valami kiégett, omlásveszélyes épület mellett a piros úton.

Irány Pilisszentlászló

Az út első fél órája eseménytelen volt, miután letiltottuk a különféle szoftveres segítségek idegesítő kuruttyolásait. A kellemes csendben miután először találkoztunk más túrázókkal sikeresen eltévesztettünk egy kanyart, és letértünk az útról. Erről persze csak később értesültünk, hála a letiltott figyelmeztetéseknek, amelyek akkor is erre figyelmeztettek, amikor még a tervezett úton haladtunk 😒.

Ha már így jártunk, akkor vissza ugyan nem fordulunk! Erdészeti ösvényeken, csapásokon át tértünk vissza az útra. Ennek a szakasznak a felénél lehetett, amikor a derékig érő fűben gázolva a tüskés bokrokat félrehajtogatva mentünk egy egykor terepjáró autóknak is járható úton, és jobbfelől a botótoson túlrol az erdőből meghallottunk valamit. Valami nagyot. Nagyon nagyot. Az a mondás az itthoni vadakkal kapcsolatosan, hogy nem kell tőlük nagyon félni, mert jobban félnek tőlünk. Egy pillanatig szerintem nem állt ez az egyenlőtlenség.

A piros útra visszaérve időszerű lett az energiabevitel, úgyhogy kerestünk egy nyugodt helyet, ahol teát főzhettünk, és megebédelhettünk. Tovább indulva kipróbáltam új, olcsó ivózsákomat (Auchan sajátmárkás). A víz ihatatlan műanyag-ízű volt, a szaga is kellemetlen műanyag-szagú volt. Azóta próbáltam mindenféle javasolt praktikákat , de továbbra is olyan maradt, ahogy következő túrámon tapasztaltam. Vettem inkább egy Decathlon sajátmárkásat. Ez nem büdös, de még enm volt alkalmam kipróbálni.

Innen hamarosan elértük Pilisszentlászlót, ahol megtaláltuk a Kéktúra két pecsétjét is, valamint egy öreg Praha gyártmányú teherautót. Egy kocsma/kisbolt hibrid még szombat délután is nyitva volt, így feltöltöttük folyadéktartalékainkat, és kidobtuk az ebéd óta hurcolt szemetünket.

Mivel a késett indulás és eltéveszett út miatt itt már jelentős késében voltunk az eredeti tervekhez képest, ezért erősen bele kellett húzni. Ezen a szakszon azonban olyan látványos útban volt részünk, ami ritka az itthoni túraútvonalak közt.

Körülbelül negyed órája hagyhattuk el Szentlászlót, amikor egy táblára lettünk figyelmesek, mely látszólag a lovas útvonalon volt. Ez a Spartacus-ut fokozott nehézségére hívta fel a figyelmet. Később azonban gyanús lett, hogy mi magunk is ezen az úton járunk, és a felhívás nem a lovasoknak szólt.

Spartacus ösvény

A Spartacus-ösvény egy egykoron vadászok által használt útvonal, melyen anno Horthy-Miklós is vadászott. Az 1930-as évek környékén alakította ki a pilisi vadásztársaság. Ahogy a Spartacus névből is sejthető a kommunista diktatúra idején kapta a nevét. Az “ókor szocialista hőséről” elnevezett sportklub neve ragadt végül az úton valahogy. A természetjárók sok éven át aktívan lobbiztak a vadásztársaságnál az út turisták előtt megnyitásáért, ám erre egészen 2015-ig várni kellett.

Nem véletlen vannak kint a figyelmeztető táblák (a fotó az ösvény visegrádi végén készült), és nem véletlen nem lelkesedett a vadásztársaság a széles közönség előtti megnyitásért. Az út bár – átlagos erőnléttel könnyen letudható – néhol elég keskeny az út, van ahol csak egy cipőnyom széles, és oldalt kiadós esés majd gurulás vár az óvatlan túrázókra. A készített képeim ezt sajnos nem adják jól vissza, de azért néhányat megosztok.

Szarvas-bérc

Bár már siettünk, de mind az út egy-egy nehezebb része, mind a kilátás meg-megállásra csábított. Mészkő oszlopok, melyek akár még a római-kori erőd maradványai is lehettek, érdekes sziklák, kidőlt vagy épp lenyűgöző helyeken növekvő fák szegélyzték utunk, amikor egy hegytetőre vezető ösvényt találtunk. Mivel ezen a szakaszon a becsültnél jobban haladtunk, ezért rátértünk az ösvényre. A meredek, és a morzsalékosság miatt néhol meg-megcsúszó ösvény kicsit elbizonytalanított. A Szarvas-bérchez vezetett ez az út, ahol fennséges kilátás tárult elénk, feledtetve a sietséget, a gördülő köveket.

Tovább a Spartacus-ösvényen

Miután kigyönyörködtük magunk folytattuk az utat, abban a reményben, hogy elérjük az utolsó kompot, vagy a 8 órai buszt. Szép volt az út, de a legszebb része csak ekkor jött. Itt voltak a legmeredekebb hegyoldalak a legkeskenyebb ösvényekkel is. A képeken utitárasam, és lábdublőröm szemlélteti ezt.

A szép kilátású meredélyes szakasz után erdő következett, ahol a Jenő-kunyhó nevű épületre bukkantunk. Az épület egykori vadászház, de nyitva áll az ajta és be van rendezve. A berendezés része egy fűrész és fejsze, ami a kunyhó melletti tűzrakóhely felélesztéséhez hasznos, de egy poloskás penészes szivacsú ágy is, amit nem értek miért hagytak ott. Összeségében nyomasztó a ház belseje. Túl sok a kacat, ami miatt a kosz is. Az épületet egyébként Horthy Miklós építtette, Jenő nevű testvérének emlékét őrzi neve.

Visegrád

Egy gyors uzsonna után rohamtempóban haladtunk Visegrád felé, kis fahidakon és szép ösvényeken át. Az utolsó szakaszt már aszfalton és erőltetett menetben tettük meg. A busz azonban a menetrend előtt pár perccel érkezhetett, mivel odmenet az utolsó néhány perces egyenes úton sem láttuk elmenni, majd hiába vártunk rá percekig. Az ekkor befutó komp személyzetétől megtudtuk, hogy több komp már nem indul aznap Nagymarosra, így nem tudunk vonattal hazamenni.

Más lehetőség híján egy vendéglő udavarán egy-egy pohár bor mellett vártuk be az utolsó buszt Szendetendre felé, majd a HÉVvel visszatértünk a nátriumlámpák borostyán derengésébe.

Praegustator

Egy ideje elkezdtem egy régóta halogatott projektemen dolgozni. Ez egy olyan program lesz, ami gépi tanulás (jobban hangzik mint a statisztika 😉) segítségével fogja a híreket kategorizálni, előszűrni számomra. Legalábbis egyelőre ez a célom. Ezért lett a neve Praegustator.

Mivel még erősen fejlesztés alatt áll a program, és a feldolgozó csővezeték még sokat változhat, ezért a letöltött cikkeket mentem, hogy amennyiben módosítom a feldolgozó futószalagot, akkor meg tudjtam ismételni a feldolgozást, és a modellt az új kimenet alapján újra tudjam tanítani.

Közel egy hónapja fut már egy verzió tesztüzemben, és több mint 1GB már az adatbázis mérete. Megvizsgálva az adatbázist több tanulságot levontam. Egyfelől az adat felét a mentett cikkek törzsei teszik ki, másfelől a kinyert szöveg-jellemzők tárolási formátuma is erősen pazarló.

Mivel a szöveg-jellemzők valószínűleg SQL lekérdezésekkel (is) feldolgozva lesznek, ezért ott egy tömörített bináris blobban tárolás nem megoldás a helytakarékosságra, ezért ott inkább a reprezentáció finomhangolásával nyertem némi helyet.

A cikkek szövegtörzsét azonban csupán mentéskor egyszer írom, és csak akkor olvasom, amikor egy módosítás után a szöveg-elemző futószalaban az elemzés kimenetelét újra kell generálni. A feldolgozás nem SQL-ben, hanem a C# alkalmazásban történik.

Ezen szempontok figyelembevételével úgy döntöttem, hogy az eddig szövegként tárolt HTML szövegtörzs helyett azt tömörítve fogom tárolni. Már csak a tömörítési eljárást kellett kiválasztani.

A Weissmann-átlag

A Silicon-Valley című méltán sikeres amerikai vígjáték sorozat első évadjában lehetett a veszteségmentes tömörítések jellemzésére használt – a sorozat kedvéért megalkotott – Weissmann-átlaggal (angolul Weissman-score) találkozni.

Mivel nagyon professzionális vagyok, ezért úgy döntöttem, hogy a tömörítési eljárás kiválasztását illendő lenne empirikus úton, mérésekre alapozva végezni, de jó móka lenne ezt a Weissmann-átlagot is kiszámolni.

A Weissmann-átlag, amint már írtam, egy film kedvéért kitalált áltudományos mérőszám, veszteségmentes tömörítő algoritmusok összehasonlítására.

Weissmann-score képlete

A képletből látható, hogy ez abszolút összehasonlításra sajnos nem igazán alkalmas, legalábbis a referencia értékek (skálafaktor, tömörített adatok, referencia algoritmus tömörítési aránya és futásideje) megadása nélkül.

A mérés

Mivel az alkalmazásom .Net Core 2.0 alapon fut, így eredetileg ott mértem meg az elérhető algoritmusok teljesítményét.

A következő algoritmusokat vetettem össze:

  1. Gzip – a .Net keretrendszer részeként elérhető
  2. Deflate – szintén elérhető a keretrendszer részeként, a Gzip algoritmus ezen alapul
  3. Bzip2 – Linux alatt népszerű, a gzipnél tömörebb, de lassabb algoritmus. Mivel a keretrendszer nem szállítja, ezért egy külső managelt könyvtárral próbáltam ki: [SharpZipLib 1.0.0-alpha2(https://www.nuget.org/packages/SharpZipLib/1.0.0-alpha2). Natív kóddal feltehetően gyorsabb lenne.
  4. Brotli – A Google új üdvöskéje. Natív .Net Core megvalósítás: BrotliSharpLib 0.2.1

A keretrendszer következő, 2.1-es verziója azonban natív Brotli támogatást fog hozni, így átálltam egy előnézeti verzióra, hogy annak a teljesítményét is össze tudjam vetni a többi versenyzőével. Így a Brotli kétszer is szerepel a mérésekben.

Minden algoritmusnak vannak különféle beállításai. Én mindegyiknél a leggyorsabb és legtömörebb módokat próbáltam ki, nem finomhangoltam egyiket sem.

A méréseket egy ~80 MB méretű adatbázis mentésből kinyert korpuszon végeztem. Az adatok mentett HTML dokumentumok, magyar és angol nyelveken vegyesen.

A mérést nem mikrobenchmarkként végeztem, nem ismételtem meg többször, nem számoltam szórásokat. Nekem most elég jó volt egy egyzserűbb mérés is.

Eredmények

Az eredményeket a mérőprogram csv formátumban elmentte.

Adat elemzés, egy csipetnyi Excel gyűlölettel

Az adatok feldolgozásához úgy döntöttem, hogy kipróbálom az Excelt. Elég kevéssé ismerem, és vannak, akik erre esküsznek. Nekem eddig csak csalódásokat oozott, mindig jobban működött egy Python scriptet összedobni, mint a táblázatkezelővel szenvedni, de még programozó kollégák is azt állítják, hogy van, hogy az Excel legjobb választás adat turkálásra. Gondoltam adjunk még egy esélyt neki!

Kipróbáltam.

Tévednek.

Amennyit küzdöttem vele, az alatt Python segítségével többször is elvégeztem volna amit akartam, és így sem vagyok teljesen elégedett a kapott grafikonokkal. Az adatból másfajta adatok kinyerésével nem is próbálkozom már, annyira körülményes, elmásznak az oszlopnevek, meghülyülnek a képletek.

A transzponálással külön meg kellett küzdenem. Szánalom.

  1. Jelölj ki egy pont akkora területet mint a transzponálandó transzponáltja!
  2. Ne nyomj entert,
  3. hanem nyomj Ctrl+Shift+Entert!

A CSV import elég awkward, és frissíteni sem lehet lehet könnyen, de azért adatkapcsolatként szerepel, amit törölni kell és újra betölteni a filet egy újabb mérés után. Egy Python script esetében ez felnyíl-enter lenne. Ehelyett 20 kattintás, ha más a sorok száma, akkor képletek frissítgetése…

Most képzeljük el, hogy szórásokat is számoltam volna, több adatsort kellett volna korreláltatni hozzá azonos elem különböző méréseiből. Erre teljesen alkalmatlan eszköz az Excel.

Egy olyan scatterplot, amiben van értelmes jelmagyarázat is, és címkéi is vannak az adatpontoknak… Feladtam ott, hogy legalább a pontokra sikerült felrakni a címkéket.

További számításokat nem végeztem inkább, másfajta plotokat sem készítettem. Egyszerűen alkalmatlan komolyabb adatfeldolgozásra. Varázsbillentyűk. Képlet frissítés után gondosan copy-pastelni végig a sorban/oszlopban. Nem értem milyen elme tud így gondolkozni. Nincs absztraháló ereje, teljesen ad-hoc, átláthatatlan. Vagy valaki olyan, akit beleszoktattak ad-hoc hülye eszközök használatába, és ettől torzult az elképzelése egyes munka/kognitív folyamatokról. Talán egy könyvelő? Az adószabályok, a főkönyv számozott-elnevezett kategriái, és az ÁNYK hasonló pokolbéli kínzóeszközök… Azok után az Excel akár tűnhet is megfelelő eszköznek.

A Weissmann paraméterek

Ahogy a táblázatból is látható, a gzip algoritmus Optimal (linux világban gzip -9) változatát tekintettem referencia algoritmusnak. A skálafaktor értéke α = 1 volt.

Lássuk már az eredményeket

Algoritmus Idő
[sec]
Tömörítés Sebesség
[Mbyte/sec]
Weissmann átlag
α = 1
gzip 0,562755 4,241916 138,625 1,0000
gzipfast 0,221613 3,761087 352,020 0,7391
deflate 0,457420 4,243974 170,548 0,9579
deflatefast 0,214454 3,762704 363,771 0,7351
bzip 9,942345 4,549692 7,846 2,7860
bzipfast 9,717193 4,519541 8,028 2,7327
brotli 88,602744 5,325078 0,880 -15,0365
brotlifast 0,926333 1,953454 84,216 0,5155
brotlicore 44,596294 5,324878 1,749 19,7554
brotlicorefast 0,209611 3,835408 372,175 0,7463

Ugyanez képen

Mérési eredményeket megjelenítő diagram

Végkövetkeztetés

Mivel a Brotli tömörebb, bár nagyságrendileg lassabb, arra esett a választásom. A Gzip általában jó választás, fast módban is egész jól tömörít, nagyon gyorsan, de arra jutottam, hogy mivel elég sok cikket kell majd tárolnom, de nem nagyon nagy tempóban érkeznek, ezért jobban megéri alaposabban tömöríteni. Egy dokumentum tömörítése még így átlagosan is 10ms alatti (A BrotliSharpLib legtömörebb módjával), és jelenleg 15 percenként néhány tucat dokumentum érkezeik csupán. A Brotli kitömörítési sebessége a gzipével összemérhető elvileg, de azt nem mértem meg.

A Brotlit amúgy kifejezetten webes tartalom tömörítésére találták ki, a leggyakoribb angol szavak és HTML tagek is szerepelnek az előre generált szótárában, aminek köszönhetően ilyen tartalmat még hatékonyabban tud tömöríteni. Ezért is gondoltam, hogy most jó választás lehet számomra.

Jelenleg a managelt BrotliSharpLib megoldását használom, majd a framework 2.1-es verziójának kiadása után frissítésekor átállok a Microsoft megoldására, mivel az közel kétszer gyorsabb. A biztonság kedvéért kipróbáltam, és a két megoldás kimenete szinte azonos, méretben is csak néha akad néhány byte eltérés. Egymás kimenetét sikeresen ki tudják bontani. Résen kell lenni, az ördög nem alszik!

PiedPiper

Bár az általam számolt Weissmann átlagokkal a SiliconValley sorozatból ismert értékkel nem lehet közvetlenül összevetni a PiedPiper Weissman számát, én megteszem!

A filmben az érték az elképesztő 5,2-re adódott, amitől mindeki el volt alélva! Ezt azzal érték el, hogy egy 132 GB méretű filet 24,35 GB-ra tömörítettek 12 másodperc alatt.

Nekem a .Net Core 2.1-es Brotli 80MB-ot 15MB-ra tömörített 44 másodparc alatt, és ez 19 pontot ért az én összehasonlításomban

A győztes tehát egyértelműen a… na jó, ennek tényleg semmi értelme :)

C# 7.2

If you’re going to break it, then break it good. Break everything.
Get to the very front of the line. Don’t like move up a couple of slots.
That’s pointless.

Anders Hejlsberg (probably on async/await in C#)

Megérkezett a C# nyelv 7.2-es kiadása, amiről alig fél év késéssel én is értesültem!

Csodás funkciókkal, mint például public static async Task Main(){ /*...*/ } !

Ki is próbáltam működik is! Mit mondhatnék? I’m livin’ the dream!

Valójában az async Main a 7.1-es kiadás újdonsága, is de a 7.2-es is tartalmaz hasznos újdonságokat, például másolás nélküli struct érték átadást, ami gyorsíthat akár a kódunk sebességén, vagy a protected private láthatóságot, ami protected, vagy assembly private helyről láthatóvá tesz egy típust. Néha talán jól jöhet..

Érdemes átnézni a funciókat, sokat javult a nyelv, apró kényelmi dolgokban is, illetve potenciálisan teljesítményt hozó dolgokban is..

Amit jobban várok, az a C# 8 a rekord típusokkal, de az már egy másik történet. Persze ebben az is szerepet játszik, hogy már majdnem mindent amit vártam megkaptam a 7. verzióval is. 😄

A maga idejében a Windows 95 felhasználó felülete forradalminak számított. Bár a korábbi grafikus felület koncepciókra épített, azokból számos ponton merített, mégis erededi Microsoft termék, valódi kutatás-fejlesztés eredménye volt. A felület, mely oly nagy hatással volt a legtöbb azt követő grafikus felületre rengeteg felhasználói visszajelzés, kontrollcsoportos vizsgálat alapján született meg.

A Windows 95 jött, láttuk, és győzött. A Microsoft mai piaci helyzete – sikerei és kudarcai egyaránt – jelentős részben ennek a terméknek a sikerén alapulnak.

Erről a témáról találtam az alábbi kimerítő, kiváló írást:

Designing Windows 95’s User Interface

Hideg téli estékre, egy pohár forralt bor mellé kiváló technika-történelmi utazás.

a hivatkozás archivált változata

SQL motivációs levél

PREPARE FOR RESTRICTED USE OF NATURAL TEXT

Ma egy hiba után nyomozva az adatbázis sémákat nézve tapasztalt kollégám felhördült, hogy miért használunk SQL kulcsszavakat táblanévként. Látva a több mint 800 szavas SQL kulcsszó listát (ami több implementáció specifikus részt is tartalmaz) azt mondtam, hogy ennyi szókinccsel már Londonban munkát lehet kapni. Brogrammer kolléga erre azt a kihívást intézte, hogy írjak motivációs levelet SQL nyelven.

Bár eredetileg úgy gondoltam, hogy 800 szó mosogatni elég csak, mégis inkább egy adatbázis adminisztrátori munkát pályáznék meg az OpenScale System International cégnél:

TO: RESOURCE OPERATION AT OPEN SCALE SYSTEM INT.
FROM: MAX BERNOULLI

THERE IS A POSITION FOR SQL DATABASE ADMIN.
CURRENT WORK TERMINATED.
ROLE MATCHED EXISTING OPERATOR DEGREE.
HAVING SOME ROUTINE, ILIKE TO READ LOGS.
REFERENCES INCLUDE A YEAR OF FOREIGN WORK.
INSENSITIVE FOR POSITION IN CUBE OR ISOLATION.
ILIKE TO WORK AS MEMBER OF DETERMINISTIC, DYNAMIC GROUP.
COMITTED TO RESULT WITH EXCEPTION OF USING COBOL LANGUAGE.

PREPARED TO BEGIN ASSIGNMENT, STARTING ANY DAYOFWEEK.
TEMPORARY WORK IS ALSO NOT OFF LIMIT.

CALL ANY TIME WHEN HAVING IDENTIFIED RESULT.

MAX BERNOULLI

Szerintem egész jó lett! 🎭