Archiver wanted

Időnként backup-ot szoktam csinálni a notebook-om vinyójáról, de -hogy is mondjam- elég kezdetleges módszerrel: Simán átmásolom a partíciókat egy külső USB-s HDD-re. Illetve most már csináltam egy kezdetleges szoftvert, ami nem akad el ékezetes fájloknál (mint a windows vagy a Total Commander néha), normálisan előre összegyűjti a különbségeket amiket másolni kell, viszonylag értelmesen kiírja hogy mennyi van még hátra, nem zabálja a procit és a memóriát és tudom hogy mi van ha a művelet közben leállítom. Viszont még nagyon sok funkció hiányzik belőle. Talán érdemesebb lenne választanom a meglévő archiváló szoftverek közül, minthogy ezzel pepecselek, de semmi ingerenciám használhatatlan programokkal való szíváshoz és (un)installálgatáshoz. Megmondom őszintén, a legkevésbé kedvelt elfoglaltságaim közé tartozik Google alapján találomra letöltött programok kipróbálgatása, úgyhogy inkább megkérdezem: Tudtok jó archiváló/másolat készítő szoftvert ami teljesíti az alábbiakat?

• Fusson Windows XP-n és Vista-n, de ne akarjon nagyon beépülni a rendszerbe. Ne másszon bele a registrybe, ne indítson service-t, ne rakjon bele új menüpontokat a könyvtár explorerbe. Nem gond ha Java.
• Értelmes GUI-ja legyen, amihez nem kell pilótavizsga.
• Tudjon külső USB-s vinyóra archiválni. (Ez nem egy nagy igény.)
• Meg lehessen mondani neki, hogy mely könyvtárakat archiválja, melyeket hagyja ki.
• Természetesen támogassa az incremental backup-ot. A régi fájlokat felülírhatja, nem gond.
• Legyen nagyon reszponzív: Mindig tudjam hogy hol tart. Normálisan írja ki hogy mennyi idő és hány kilobájt van hátra a másolásból. Az sem árt ha az átviteli sebességet kiírná.
• Bármikor para nélkül le lehessen állítani. Archiválás közben is lehessen használni a gépet.
• Jó lenne ha tudna olyat, hogy eleve titkosítva írja ki az archívot, és akkor kellene egy olyan szoftverkomponens is, amivel ebbe a titkosított archívba bele tudok nézni. Ezt a szoftverkomponenst jó lenne ha nem kellene installálni, hanem akárhova bepottyantva működne. (Tipikusan az archív mellé tenném be a külső vinyóra és onnan futtatnám.)
• Ha jelszó alapú titkosítást tud már az is jó, de szuper lenne ha valami kulcsos megoldást is támogatna.
• Legyen ingyenesen letölthető, korlátozás- és köcsögségmentes.

Ezek az igényeim. Tudtok valami olyan szoftvert ami ezeket biztosítja? Vagy kénytelen leszek tovább reszelgetni a sajátot?

JUM XII.

Elsőnek Viczián István beszélt a JAX-WS mélyvízről. Számomra elég elrettentő hatása volt az előadásnak. Eddig nagyjából megkímélt a sors a SOAP technológiától és remélem ezután is így lesz. Találkoztam olyan projekttel, amiben szerepelt, de nem nekem kellett foglalkozni vele, vagy amikor hasonló megoldást kellett alkalmaznom találtam más módszert. Az előadás végén említésre került még pár hasonló SOA technológia. Ezek közül a REST-tel már volt dolgom és úgy érzem hogy az egészen használható egyszerűen azért, mert nem akartak mindent helyben megoldani, hanem az a mondás, hogy az üzenetek topológiája MásValaki Problémája, azaz ha akarom XML, ha akarom JSON, ha akarom akármi. És tényleg: én éppen JSON-nal használtam, ahol más formában szintén előjönnek hasonló dolgok amire JAX-WS és JAXB-nél figyelni kell. Cirkularitás, ilyesmik.

A második előadáson Csutorás Zoltán beszélt az agilis módszertanokról. Az elején az autógyáraknál és a közgázos diagramoknál nem értettem hogyan fogunk eljutni a szoftverfejlesztésig, de aztán szépen összeállt a kép. Kiderült számomra, hogy a Scrum nem egy levegőbe kitalált buzzwörd (mint a Cloud) hanem egy tanulmányokon és tapasztalatokon alapuló szigorú módszertan amit nem csak IT technológiában használnak. A Toyota gyárrendszere is hasonló elveken épül (Lean Management, bármit is jelentsen). Végülis engem a pipeline feldolgozásra emlékeztet ez az egész. RISC processzorok makrószinten. Három dolog biztos: Egyik hogy pár ügyféloldali managgert a környezetemből is elküldenék agilis módszertanokkal ismerkedni, mert az tényleg nem járja hogy először kiköpünk ezer oldal doksit az igényeik szerint, aztán leprogramozzuk vízesésben a hülyeséget. Másik dolog, hogy bebookmarkolom az előadó blogját és amint lesz időm rá olvasgatom. Harmadik dolog, hogy nem hallottam az előadáson csirkékről és disznókról, úgyhogy még biztos nagyon sokmindent nem tudok a Scrum-ról.

Uccsó előadás az Google Androidról szólt, amit nem kell senkinek bemutatni. Kiss Gergely a Linuxos oldaláról közelíti meg a dolgokat. Régebben egyébként már találkoztam vele egy Bp Newtech Meetup-on. Ő volt az, aki egy ősrégi kütyün életre lehelte az Android-ot, amikor még a fasorban sem voltak direktben ilyen telefonok. Az előadás legfontosabb hozama számomra a Hundroid portál és a magyar Android közösség bemutatása volt. (Van még ilyen is, nem tudom hogy ez ellenség-e vagy barát. Úgy látom PZ is kommentel úgyhogy ez valami hivatalos valami lehet.) Megkérdeztem tud-e magyar fejlesztésekről. Mondta hogy tud egy angol tanuló szoftverről, az Ustream-eseknek van Android implementációja, (Ustream-mel felvettük az előadásokat, utólag is megnézhetőek. Könnyen kezelhető, jó cucc! Valahol itt vannak a videók. Persze a minőség pocsék, van még min javítanunk.) és persze rögtön le is demózott egy kis alkalmazást: a saját OpenOffice prezentációját egy saját készítésű Androidos alkalmazással vezérelte bluetooth-on keresztül.

Jó sokan voltunk, a rendelkezésre álló időkeretet kicsit átléptük, sörözés úgy tudom most elmaradt, következő alkalom jövőre.

Megoldás

Szóval ott tartottam hogy Scala és Java programkódokat hasonlítgatok össze, ami egy tömbben egy adott karakter előfordulásait számolja meg. Egy szerény 30 millió karakteres tömbön próbálgattam a négyféle programkódot, amit az előző post-ban fabrikáltam össze tegnapelőtt: Volt sima for ciklusos és rekurzív algoritmus Java-ban és Scala-ban is.

Nézzük hogyan muzsikáltak:

Az első sima Java megoldás (1.) kb 160 ezredmásodperc alatt birkózik meg a feladattal. A Scala program, amibe a Java imperativizmusát másoltam le (2.), 1200 ezredmásodpercig dolgozik ugyanezen. Ez egyáltalán nem elhanyagolható különbség, de mégegyszer hangsúlyoznám, hogy ész nélkül írtam át a Java kódot Scala-ba: Egyszer talán majd pörgök egy post-ot ezen a különbségen is, de alapvetően "nem érdekel ez most engem".

Következőnek a (4.) Java programkódot tárgyalom ki, amit kvázi funkcionálisan írtam meg, rekurziót használva, viccből. Na ez már hatezer karakteres bemeneti karaktertömbnél is csúnyán elcsattan StackOverflowError-ral. Ha ismerjük a rekurzió működését, -azaz hogy a program minden egyes függvényhívásnál felépít egy stack frame-et- ez nem is túl meglepő. Ahány karakter, annyi stackframe: a verem hamar felzabálja a memóriát.

Végül jöjjön a (3.) funkcionális Scala program, ami a 4.-eshez hasonlóan rekurziót használ. Ez viszont nem száll el StackOverFlowError-ral, sőt egész jó időt hoz, kb. 160 ezredmásodpercet. Csak kicsivel lassabb mint a legelső kód. Hogyan lehet ez?

A megoldás kulcsa a farokrekurzió és annak kioptimalizálása. A dolog lényege, hogy a rekurzív függvény legutolsó művelete saját magának a meghívása. Még általánosabban, ha egy függvény utolsó művelete egy másik függvény meghívása (Tail Call). Ilyenkor levezethető, hogy a legutolsó stackframe újrafelhasználható, vagy legalábbis eldobható a következő függvény meghívása előtt. A jelenlegi Java-t futtató JVM implementáció nem támogatja ezt a feature-t. Vannak rá törekvések, ami talán új bájtkód prefixet is szükségessé tenne, de ez nem a közeljövőben fog megvalósulni. Biztonsági kérdések is felmerülnek, mert a Java nem optimalizálhatja ki csak úgy a stack frame-eket. Kivétel dobásánál vagy hozzáférési jogosultság ellenőrzésnél nem szerencsés ha hiányoznak frame-ek. A ScalaByExample.pdf -ami külön fejezetet szán ennek a magyarázatára- megemlíti hogy a Scala esetében farokrekurzió optimalizására lehet építeni, de a stackoverflow-n találtam még két kitételt ezen felül: Csak lokális vagy final függvények esetében.

Aki arra is kíváncsi hogy a Scala (valószínűleg) hogyan oldja meg, illetve hogyan oldható ez meg magas szinten egy nyelv meglévő elemeivel a program átírásával de az algoritmus jellegének megtartásával, az itt találhat egy kimerítő leírást róla. Elég messziről indul és körmönfont példát hoz, de egyébként nem egy bonyolult dolog. Hasonlít a Command Pattern-re.

Egyébként ezzel az egésszel csak arra akartam megnyugtató választ kapni, hogy a Scala-ban előszeretettel használt tail rekurzió megállja-e a helyét gyári környezetben. A válasz: igen.

Scala fejtvény

Ahogy beleolvasgattam egy-két Scala ismertetőbe az volt az érzésem, hogy folyton túl kézreálló példákat próbálnak hozni a nyelvhez. Arra gondoltam, csinálok egy olyan példát, ami nem annyira kézreálló. Számoljuk meg egy karakter tömbben a paraméterben megadott karaktereket. Sokkal kreténebb példákat is lehetne kitalálni, de én most megelégszem ezzel. Java-ban elég kézenfekvő a megoldás (1.):

public int count(char a, char[] array) {
  int ctr = 0;
  for(char ch : array) if(ch==a) ctr++;
  return ctr;
}

Ezt tükörfordításban ész nélkül kb. így lehet átírni Scala-ba (2.):

def count(a: Char, array: Array[Char]) : Int = {
  var ctr = 0;
  for(ch <- array) if(ch==a) ctr = ctr + 1;
  ctr;
}

Viszont a Scala funkcionális nyelv és ha ezt a paradigmát kihasználva szeretnénk megírni a programot, nem tehetjük meg, hogy ezt mondjuk: ctr = ctr + 1. Ez az a dolog, ami miatt ezt én "nem kézreálló példának" tartom. Ehelyett valami olyasmit kell elkövetnünk, mintha fél lábon állva a bal fülünket a jobb kezünkkel a fejünk mögött átnyúlva vakarnánk meg (3.):

def count(a: Char, array: Array[Char]) = {
def count_(i : Int, ctr : Int) : Int =
  if(i == array.length) ctr else
    count_(i+1, if(array(i)==a) ctr+1 else ctr)
  count_(0, 0)
}

Bár nem tartozik szorosan a témához, azért néhány Scala jellegzetességet gyorsan kiemelek: A külső függvénynek nincs meghatározva visszatérési értéke, mert kikövetkeztethető. Nem írtam pontosvesszőket a sor végére, mert a fordító így is érti miről van szó. Ja és ezek egymásba ágyazott függvények, ráadásul a belső függvény látja a külső bemenő paramétereit.

Csak a vicc kedvéért, ezt az utóbbit visszaírom java-ba, úgyhogy ha az előző megoldás nem volt érthető, talán ez tisztába teszi a dolgokat némileg a Java-s emberek számára is. Itt viszont már két függvényre van szükségem (4.):

public int count(char a, char[] array) {
  return count_(a, array, 0, 0);
}
    
private int count_(char a, char[] array, int i, int ctr) {
  return i==array.length ? ctr :
    count_(a, array, i+1,
      a==array[i] ? ctr+1 : ctr);
}

Namost a kérdés a következő: Szerintetek a négy megoldás mennyire gyors és mi történik (és miért - főleg ez a lényeges) ha egy jó nagy -de még nem akkora nagy hogy azonnal OutOfMemoryErrort okozzon- karaktertömböt adok meg bemeneti paraméterként? A megoldást megírom pénteken. Ha addig valaki bekommenteli a megfejtést, kap tőlem egy sört vagy ezzel egyenértékű élvezeti cikket a következő JUM-on.

JUM XI.

Nézőcsúcs született a tegnapi JUM-on. Mondjuk így könnyű, hogy nem két nappal az esemény előtt derül ki hogy mik lesznek az előadások és mi a helyszín. Az új Számalk épület igazán trendi, letisztult helyszínt szolgáltatott Wifi eléréssel.

Néhány szó az előadásokról:

PMD, Checkstyle - statikus kódanalízis
Ha arra vetemednél, hogy saját szabályok szerint akard ellenőrizni a Java kódodat (vagy másét) akkor ezek közül kell használnod valamelyiket. Az egyikben Java-ban kell vizsgálgatni az Absztrakt szintakszisfát-t, a másikban pedig XPath-tal kell bűvészkedni. A kód duplikációk is könnyen kibújnak a zsákból ezekkel az eszközökkel, mert nem lehet átverni őket megváltoztatott változónevekkel, kommentekkel és whitespace beszúrásokkal. Az előadáson nagyvonalúan átsiklottunk fölötte, hogy mi az az Antlr és Javacc, ami a PMD-ben ill. a Checkstyle-ben dolgozik. Nos, az utóbbi parser generátor és az előbbi is valami olyasmi. Lényeg hogy ha ezekbe betoljuk egy nyelv (jelen esetben a Java) formalizált szintaktikai szabályait, akkor tudnak olyan parser-t generálni, ami fel tudja építeni egy forrásfájlból a szintakszisfát. Aztán ezt lehet interpretálni, elemezni, compilálni. Talán egyszer ezekről a parser generátorokról is lehetne előadás.

Oktech profiler
Sok olyan kérdésre rávilágított az előadó, amin eddig nem is gondolkodtam el. Hogyan lehet profájlolni? Instrumentálni lehet a kódot, vagy mintavételezni a stacktrace-t. Mindkettőnek megvannak az előnyei és a hátrányai. Ők az utóbbi irányba indultak el és nyílt forrásúvá tették a kódot. A jelenlegi formában még elég száraz a kimeneti formátuma, de van benne perspektíva. Mivel a mintavételezéses profiling főleg kilóra tudja megmondani hogy mikor mi fut én olyan bővítéseket tudnék elképzelni, amik színes grafikonokat rajzolnak.

Google App Engine
Ez is jó előadás volt. Átjöttek a Google App fejlesztő legnagyobb szívfájdalmai: olyan a fejlesztés mint egy akadálypálya, ha tényleg akar valami komolyat csinálni az ember, hamar megtalálja a falakat. Van egy hosszú lista, hogy mely java frameworkök támogatottak, melyek részben és melyek nem. Alapvetően szervlet technológia, nagyjából van JPA, de vannak bizonyos korlátok, pl. max ezer fájl lehet egy alkalmazásban. Ha pl. Dojo-t akarok használni vagy más Javascript keretrendszert ami sok kis képet használ, akkor máris bajban vagyok. A GAE folyamatosan fejlesztés alatt áll, néha bejönnek új feature-ök, néha megjelenik valami új bekezdés a honlapon. Egy bizonyos forgalmi határig ingyenes, aztán pedig fizetős. Ez az ingyenes forgalmi határ sok kritériumból tevődik össze kezdve a napi processzoridőtől a napi max deployolások számáig. Ennek ellenére szeretjük a Google-t, mert még mindig látszik a törekvés hogy adni is akarnak valamit nem csak lenyúlni. Fontos még, hogy eredetileg Python-ra volt támogatás. Java csak idén tavasszal lett, ezért még mondhatni gyerekcipőben jár.

A JUM utáni sörözéseket kellene még komolyabban venni. Legközelebb akkor novemberben!