2014. november 23., vasárnap

ApacheCon Budapest - második nap

Mint mindennel, ezzel a konferencia-naplóval is lemaradtam, de megígértem és behozom, még ha senki nem is olvassa el :)

Szóval reggel az Apache Brooklyn projecttel ismerkedtem meg, amit azóta el is kezdtem próbálgatni, bár még nem sikerült teljesen elhelyezni a fejemben hogy pontosan hova fog passzolni :) Mindenesetre komplex alkalmazásokat lehet vele telepíteni nagyon gyorsan és egyszerűen. Ez igazán tetszene, bár az MS-Word doksinál nekem majdnem bármi szimpatikusabb.

Szintén feltünt a radaron a newts, ami Cassandrára épített adatbázis kifejezetten olyan time-series adatok tárolására, a bemutató szerint az olvasási sebesség tűrhető, de az írási sebesség zseniális. Egy ilyennek igazán sok helyet lehet találni a hétköznapi életben. Az OpenNMS fejlesztői konkrétan a hálózat terhelésének követésére használják.

Az egyéb kategóriában a JClouds előadásokat hallgattam meg. Nekem mindig úgy tűnt, hogy a system developerek jobban szeretnek python-t hajtani, de nekem határozottan jól jön egy java absztrakciós réteg.

Este a CloudStack srácokkal és pár emberrel a CouchDB fejlesztők közül a Szimpla kertben lógtunk, az egyébként is gyanús CouchDB arcok főleg az alapítvány belügyeiről beszéltek, aminél akár még a szivárványmintás pónilovak legújabb kalandjai is jobban érdekel.

2014. november 18., kedd

ApacheCon Budapest - első nap

A hétfő nagy részét a CXF előadásokon töltöttem. A Spring Websocket lecserélését CXF-re egyelőre nem tettem napirendre, de a JAX-RS 2.0 demók közben rájöttem, hogy sokkal jobban is kihasználhatnám a JAX-RS API-t a CXF-ben, különösen az async újdonságokat. Nagyon érdekel, hogy az asszinkron dolgokkal hogyan alakul a szerver teljesítménye ha összegyúrom az infinispan async API-jával. Sokat kellett várni arra, hogy felhasználható állapotba jöjjön a servlet async support, most a végén remélem meglátjuk hogy megérte :)

Rendkívül szociális nap volt a hétfői, egy csomó emberrel találkoztam személyesen, akivel eddig csak leveleztünk és azt se tudtam hogy néz ki. De azért nem voltak köztük se ufók, se alienek.

Kicsi statisztika:
Nagyon kevés magyar van, talán 10-15, szerintem kicsit borsos lehet az ár, a munkaadóink meg sóher stricik.
Ennél már csak nőből van kevesebb, talán 3 a résztvevők közül, még 3 szervező, 1-2 fejvadász. Nagyobb posztereken kellene reklámozni, hogy nem gyűlöljük az programozó lányokat.
...csak a programozókat úgy ahogy vannak egyébként :-)

2014. november 13., csütörtök

Apache BP

Nem szeretném azt a látszatot kelteni, hogy bárki követné vagy érdeklődne iránta, vagy bárkit tájékoztatni szoktam volna arról hogy hol vagyok és mit csinálok, csak gondoltam szólok és igérek, hogy a jövő héten Budapesten leszek az Apache konferencián. Aki nem jön, annak írok beszámolót itt arról, ami engem érdekel és megragad a fejemben addig, amíg le nem írom, aki meg jön, azzal esetleg fussunk össze. Szocializálódjunk, vagy mi.

2014. október 21., kedd

Egynemű házasság

Nemrég egy új főnökömnek (gyűjtöm a managereket) próbáltam elmagyarázni hogy mi a szituáció a projecten és valahogy ez a megnevezés jutott eszembe: egynemű házasság.

Az egynemű házasság alatt azt értem, hogy a projectre úgy helyeznek új munkaerőt, hogy az a projecten már meglévő fejlesztők képességeit nem kiegészíti, hanem azt lefedi.

A skálázhatóság témában szokás ezt X-axis-nak nevezni, és ott jól produkál, tipikusan webalkalmazásokat egész könnyű (ha nem csinált valaki valami turpisságot) X-axis mentén skálázni. A lényeges különbség viszont az, hogy a számítógépekkel összevetve az emberek lassan tanulnak és ráadásul sok hibával, azaz mind másként tanulnak meg valamit. Ez oda vezet, hogy kialakul pár vita és persze személyfüggő, hogy mennyi, de egyre több koordináció válik szükségessé. A problémán az sem segít, hogy az emberek természetes viselkedése a versenyzés, ez ugyanis nem minden eset válik a szoftver javára például gyakoribbá vállnak a túlmérnökölt megoldások.

Hát ennyit akartam megosztani ma, hogy én így gondolkodok erről nagy általánosságban véve, a többi bullshitet költsétek ti hozzá :)

2014. szeptember 8., hétfő

Websüket

2006 körül minden az AJAX-ról szólt. Mindenki dinamikusan generált HTML-ből állított kezdett weboldalakat összeállítani, de azért még jónéhány full-page reload volt benne. A kommunikáció többnyire tényleg XML volt, néha jöttek-mentek html darabok is.

2010 körülre már megint mosogatószert meg focicsapatot jelentett az AJAX. Az XML látványosan veszített népszerűségéből, elkezdték egyéb formátumok átvenni a helyét, főleg JSON de láttunk már olyan perverziókat is mint a BSON és társai. A formátumok káoszában a REST homályos útmutatásai teremtettek hébe-hóba rendet.


Itt a történelemórát had szakítsam félbe, hogy azt is elmondhassam közben, hogy milyen elégedett voltam azzal, hogy a rémesen túlbonyolított és szemellenzős szerveroldali MVC rendszereket itt ezen a ponton jórészt elavulttá tették az egyoldalas webalkalmazások. Ez nem azt jelenti, hogy nincs többé aki használja őket, hanem csak egyszerűen COBOL-völgyi bányászoknak tartja őket a sok nagyvárosi okostojás.
De nem csak ez okozott kárörömet rothadó lelkemben, hanem az is, hogy a javascript programozók komoly lehetőségeket kaptak arra, hogy bizonyítsák, nagyon egyszerű, könnyű és stabil rendszereket tudnak építeni kedvenc platformjukra, a böngészőkre. A pofáraesésen csak azért nem tudtam szívből derülni, mert nekem is fájt.Ez egy nagy adag komplexítást levett a java backendről és tulajdonképpen ma egy java backend fejlesztő élete akár rettentő egyszerű is lehetne egy végletekig idealizált esetben. Csak olyasmikkel kellene foglalkoznia, mint megbízhatóság, kiválló válaszidők, skálázhatóság és mindenek elött persze (hmm...) egyszerűség. Hát azért nem egészen itt állunk, de őszintén úgy gondolom, hogy ez a lehetőség adott. Csak hát elkú ugye, már megint.

Nade félre ezekkel.

2014 van és miután évekig vártunk hogy leülepedjen és letisztuljon a webfejlesztés, végre ovisokra és nyugdíjasokra bízhassuk amíg mi szebb kihívásokat keresünk magunknak, tartok tőle hogy ismét csalódás fog érni. Bár már évekkel ezelött is írtam a websüket szabványról, azóta kidobták, mégis visszaengedték, megszületett végre a java api, satöbbi. Szóval úgy tűnik, végre itt van a websocket, nagyon lassan de elhárulnak az akadályok előle. (Nem tudom miről beszélnek amikor gyors fejlődést emlegetnek az emberek, szerintem tüttyögésről meg pöcsölésről lehetne beszélni.)
De nekem felmerül a kérdés: ha van egy folyamatos full duplex kapcsolatod a szerverrel, ugyan mi a fenének akarnál REST-et használni. A webalkalmazások egy jelentős részének új paradigmára, új eszközkészletre van szüksége.

No ennyi. Vár a gyár.

Hron, remélem megválaszoltam a kérdésedet legalább részben :)

2014. augusztus 19., kedd

kotlin helyzet

Csak egy gyors véleményösszegzés arról, hogy hol tarhat most a kotlin programnyelv fejlesztése. A project célkitűzésein végigfutva:
  • Legalább olyan gyors compiler legyen, mint a javac
    Ezt jelenleg alulmúlja a kotlin. Állítólag hónapokon belül érkezik az incremental compiler, de még nem jött meg. Nyomai persze már vannak a forráskódban. Szerintem jelenleg elég lassú. (fordítás közben az ember végigvizslatja az I7-es processzorral szállított laptopok árait)
  • Java kompatibilis
    Ezen a téren viszont egészen jó, teljesen normálisan használható a kotlin kód java kódból és fordítva. Az extension funkciók szerintem jól eltalált dolog, a null protection is transzparens a java felől nézve.
  • Biztonságos
    A designt nézve elég biztonságos, de nekem hiányoznak az olyan eszközök, mint a findbugs, amivel gyorsan automatikusan végig lehet túrni a kódot tipikus hibák után. Fejben már elkezdtem összeszedni egy listát azokról a dolgokról, hogy hogyan lehet magadat lábon lőni kotlinban egész könnyen.
  • Kifejező
    Ez passzol. Közel sem olyan cifra, mint a scala, de az egyszerűségével nekem tetszik.
  • Milyen főbb lépések vannak hátra
    Ezt megkérdeztem a fejlesztőktől és válaszoltak. Igen pont abból a párbeszédből kiderül, hogy visszafelé nem kompatibilis. Ezért library jellegű dolgot írni kotlinra még kissé bosszantó. Le is mondtam az egyébként csinos spek BDD toolról a jbehave javára.

Hát ennyi. Kérem kapcsolja ki.

2014. június 11., szerda

Heti hype: Akka

Mostanában igen gyakran jártam mindenféle meetupokra és igazán pofátlanság tőlem hogy nem számoltam be egyetlen egyről sem, mert igazán jók is voltak köztük. Konkrétan az egyik, ami egészen jó volt, a zürichi scala buherátorok Akka meetupja volt. Nem számítom magam az aktív scala felhasználók közé, de az Akka érdekelt egy projecthez.

Az Akka egy actor-based concurrency framework, amit scala-ban írtak, de van egészen jó API-ja java-hoz is. (A magyar szakmai szókincsem hanyatlását kivállóan demonstrálja az előző mondat) Az actor rendszerekben minden folyamatot egy actor jelképez. Ezek az actorok létrehozhatnak további actorokat és üzeneteket küldözgethetnek egymásnak. Az üzenetek stílusát tekintve inkább a "megmondás" a jó ötlet mint a kérdés. A kérdés is lehetséges, visszakapsz egy Future-t, nekem gyanús hogy ott lehetséges deadlock, de mindegy, ennyi az alapötlet.
Az actor nem egy szál. Nem tudni, hogy melyik szálon, melyik processzoron (illetve cluster esetében: melyik gépen) fog futni és hogy mikor és milyen sorrendben kapja meg az üzeneteket. Igazából nem is feltétlenül garantált, hogy valaha megkapja, ez bizonyos esetekben elfogadható.

Bár én is csak gyüjtögetem a tapasztalatokat az Akka háza tájáról, nem tűnik univerzálisan minden többszállú feldolgozásra hasznosnak vagy akár csak alkalmasnak is. Ennek ellenére:
  • Az akka meetupon az egyik közbekiabáló például azt találta ki, hogy Oracle tárolt eljárásokba integrálná az Akka-t, azért mert lehetséges. Kétségtelenül némi emberáldozat árán lehetséges, de minek?
  • Az egyik stack overflow felhasználó JDBC connection pool-t csinált Akka-ból. Nem is tünt fel neki semmi, csak az, hogy lassú.
  • Szintén a stack overflow-on az egyik leggyakoribb kérdés az Akka-val kapcsolatban, hogy egyáltalán mire használható.






Szóval javaslat mindenkinek, aki Akka-t használ illetve tanulgat (magamat is beleértve): gondolkodjunk el azon, hogy nem-e valami technológiai maszturbációt követünk el. Pár dologra jó az Akka, de nem mindenre.