DPC Consulting

Scala Meetup 2016.03

March 5, 2016, elek

Hosszú idő után újra volt Scala meetup Budapesten. (Mármint előadós fajta, mert pair programozós fajta szokott lenni sűrűbben is.

Az apropó az volt, hogy a Typesafe/Lighbend különítménye épp Budapesten találkozott.

Az előadások:

Reactive Microservices by Christopher Hunt

Az előadás a szokásos reactive mantrákkal kezdődött (“without resilience nothing matters”). Néztünk egy átlagosnak tűnő microservice alkalmazást (Play, REST, Postgres) amin a kis fűszer csak a cache-elés volt. Viszont rögtön elképzeltük, hogy a cache bizony mennyire problematikus lesz, ha három példány futna az alkalmazásból (ugye ha bármelyik példány írna az adatbázisba, az összes cache-t invalidálni kell.

Aztán az egyszerűség kedvéért (sic!) hogy ne kelljen mondjuk egy message brokert telepítenünk, elkezdtünk használni egy akka clustert és egy postgresql clustert is.

Aztán a hasonló elveken működő conductr-t vettük szemügyre. Ez alapvetően egy agent, ami minden gépen fut és (micsoda véletlen) egy Akka clustert alakítanak ki a node-ok és segítenek deployolni.

Az érzéseim kicsit vegyesek voltak. Egyrészt az előadásból nem nagyon derült ki, hogy miért lenne meggyőzőbb mint bármi más (aztán beszélgetve utána @huntchr-rel azért jobban árnyalódott a kép). Kérdésre válaszolva (miért jobb mint egy docker swarm) azt felelte, hogy már most sok tool van, ezért az igény valid, és majd meglátjuk melyik a jobb.

Ráadásul az volt egy példa, hogy mivel a közös loggolás (minden instance logja egy helyen legyen) nagyon fontos, ezért beépítve van benne elasticsearch cluster. Persze ez eszi a memóriát ezért elkezdtek épp csinálni egy elasticsearch api-t emuláló in-memory lightweight valamit. Na ez szerintem tipikusan az, amikor hozunk egy rossz döntést (mindenképpen legyen benne elastic search a közös logra), aztán próbáljuk menteni a helyzetet. Én pl. arra szavaznék, hogy mindenki maga döntse el, hogy hogyan akar közös logot. Igen az elasticsearch egy jó megoldás, de még van más is (pl. valami felhő alapú mint pl. a logentries).

Azon kívül ha összehasonlítjuk a Netflix/Spring cloud stack-kel azért látszik, hogy annak elég erős feature setje van egy conductr-el szemben. (Pl. ribbon/client side load balancer). Nehéz a Spring ökoszisztémájával versenyezni, utolérni. Viszont az teljesen igaz, hogy azt a kérdést, hogy hogy jutnak el a Spring boot jarok a környezetekbe és hogy indulnak el Spring Cloud jelenleg nem oldja meg, és a conductr-ben az az újdonság, hogy a deploy tool össze van növesztve a service registryvel és már deploy time használhatjuk az adatokat, ami kétség kívül egy jó irány lehet.

((Meg persze ha egyszer a Scala-sok kezében ott van az Akka, akkor előbb utóbb várható, hogy mindenki épít belőle egy clustert.))

Mindenesetre meglátjuk mi lesz. A Spring cloud most afelé halad, hogy a service registry/config service is cserélhető legyen (alakulnak a consul.io, zookeeper implementációk is a meglévők Netflix/Spring-es mellé), ami elég erős ígéret, de a deployra tényleg kell valami válasz (ami akár lehet valami 3rd party tool is).

Lutz Hühnken: Everything You Always Wanted to Know About Pattern Matching

Ez viszont egy klasszikus command line-os pattern matching előadás volt. Az alapoktól kezdve haladóbb témákig (name based extractors, unapplySeq, stb.). Nagyon jól összeszedett előadás volt, volt remek íve és szerintem kezdők/haladók egyaránt találtak benne izgalmasat. (Eleve scala compiler debug kimenetével illusztrálni a dolgokat elég meggyőző…). Ilyen előadást meghallgatnék még sok más topicban is.

A “slide”-ok itt elérhetőek. (replesent-ben kell futtatni)

Docker + Java?

November 27, 2015, elek

Láttam már Java projektet docker-re váltani és láttam már projektet visszaváltani docker-ről. Mert a docker ugyan elég erős kártya és sok mindent üt, semmiképpen nem aduász. Legalábbis ha Java világról beszélünk.

Docker

Komplex futtatókörnyezet: Ha az alkalmazásunk futtatása több mint egy sima jar elindítása, mindenképpen hasznos lehet, hogy minden tudás a futtatáshoz egy docker konténerbe lesz beleégetve. Pl. ha elképzelem hogy egy wildfly alkalmazás szerver (vagy Fuse OSGi konténer) kell hogy fusson (akár más processzekkel együtt), pláne ha az alkalmazásszerverbe plusz modulokat és jar-okat kellett telepíteni, akkor jó eséllyel könnyebb lesz az életünk, ha ezt egyszer lescripteljük egy Dockerfile definícióban.

Változó futtatási környezet: Képzeljük el ráadásul, ha ezek változnak. Mondjuk a 23.2-es alkalmazásunkhoz még derby-client.jar kell a wildfy-ba, a 24.0-ban már mongodb. Elvileg megtehetjük, hogy ezeket valami provisioning eszközbe definiáljuk (ansible/puppet/chef, de ha lehet választani, akkor ansible). Ilyenkor viszont a provisioning eszköz definícióit is verziózni kell és valahogy biztosítani kell, hogy a megfelelő verzióval deployoljunk. (valamint mindig leprogramozni a dowgrade-eket is) Ennél jóval egyszerűbb a docker, amivel egyszerűen vissza tudunk váltani az előző konténerre és akkor még az előző setup fog futni.

Erőforrások korlátozása: A docker ezt is ingyen adja. Ha többre van szükségünk mint az -Xmx, pl. processzor korlátozásokra, akkor ezt egyszerűen megtehetjük. Természetesen itt sincs mágia, kézzel is megtehetnénk standard linux toolokkal (a docker is cgroup-ot használ), de itt megint bonyolultabb lesz, ha ezt docker nélkül verziózni akarjuk és automatikusan deployolni.

Környezetek, verziók, és ezek közötti váltás: Az egyik legfontosabb dolog tehát az, hogy egyrészt a docker konténernél elkészülnek a verziózott alkalmazáskörnyezetek (amiben egy adott verziójú alkalmazás együtt van az ahhoz a verzióhoz szükséges futtató környezettel). Másrészt nagyon megkönnyíti, hogy ezeket az alkalmazás+környezeteket egymás után futtassuk különböző konfigurációkban. (fejlesztői test, user acceptance test, production). Ez a környezetek közötti váltás szerintem az egyik legfontosabb előny, amit a docker-rel kapunk.

Több gépen futó alkalmazáshalmaz: És az is lehet hogy eljutunk oda, hogy kinőjük a környezetünket és egyszer csak azt vesszük észre, hogy egy 10+ gépen futó sokszor tíz docker container nyája közepén állunk. Dockerre épülő alkalmazások közül több is van, ami ezt a helyzetet nagyon megkönnyítheti. Az egyik legismertebb a kubernetes, de még sok más elérhető. Ezekkel általában rábízzuk az alkalmazásra, hogy valahol indítson abból még többet, ami nekünk kell és valahogy intézze el, hogy mindenki megtalálja (kicsit elnagyolva, részletesebben talán egy későbbi bejegyzésben)

Nem docker

Az előzőekért cserébe a docker természetesen magával hozza a saját komplexitását. Semmi sincsen ingyen. És vannak esetek, amikor nincs másra szükségünk mint egy egyszerű java -jar-ra.

Egyszerű futtatási környezet: Mondjuk képzeljünk el egy sima spring-boot/spring-cloud alkalmazást, ami tényleg nem több mint egy java -jar. (vagy sparkjava, dropwizard, stb.). Itt egy dologra van szükségünk, egy szerverre meg egy JVM-re. Ha nem gyakran változik a környezet (mondjuk a JVM verziója), docker nélkül se egy mágia jar fájlokat mozgatni és indítani (és mennyivel kisebb és egyszerűbb az egész).

Docker-compose: Bárhogyan is megpróbáljuk beleégetni a konténerekbe az egész futtató környezetet végső soron lesz valami leíró, ami azt mondja meg, hogy ha több konténerünk van, azok hogy működjenek együtt (linkelések, portok, stb.). Erre előbb utóbb lesz valami alkalmazás, amiből a legkézenfekvőbb a docker compose, de a kubernetesnek és más tooloknak is vannak saját leírói. Ezek tehát így is úgy is kilógnak a konténerek zárt világából, és ha már ott tartunk, hogy konténerek + leíró, akkor már csinálhatnánk azt is, hogy jar fileok + leíró.

Egyszerűbb konfiguráció, futtatás: Ha nincsenek docker containereink sok minden leegyszerűsödik. Nem kell szüttyögnünk a Dockerfile-okkal és azok tesztelésével. Nem kell azokra a kérdésekre válaszolni, hogy mikor frissült vajon a docker containerünkben lévő oprendszer (biztonsági frissítések??) vagy hogy hogyan fogjuk az összes docker container syslog-ját egyszerre látni.

Fejlesztés: A docker-ben elvileg az a jó, hogy fejlesztési időben is pont el tudjuk indítani a későbbi production környezetet. A gyakorlatban viszont azt látom, hogy ezt csak komplex setupoknál csinálják a fejlesztők (pl. egy fuse konténer mindenféle extrával), ha csak egy jar file-t kell elindítani, akkor azért a fejlesztők inkább elindítják azt az IDE-ben és gyorsabban haladnak.

Nem lineáris komplexitás növekedés: Az eddigiekben leírtak mellé képzeljük oda, hogy valaki nem tud ellenállni a microservice hype-nak (erről majd szintén lesz szó még később). 3 konténert (backend + frontend + valami) még nagyon kényelmes docker-re kezelni, de ha az alkalmazásunk már mondjuk 25 microservice instanceből áll és van test/production/uat, akkor már 75 docker konténer lesz a compose fájlban, amit össze akarunk linkelni.

Spring cloud: Persze ha 25 instance-ből áll az alkalmazásunk, akkor így is úgy is szívás lesz. Olyan varázslat nincs ami megszünteti a komplexitást, csak olyan, ami át helyezi egy olyan területre, ahol esetleg jobb tooljaink vannak. A spring cloud pl. számos olyan szolgáltatást ad (service registry, configuration server, api gateway, loadbalanced clients), amik segítségével leegyszerűsíthető a futtatás, és végül el tudunk jutni oda, ahová docker-rel is. Mert csak el kell indítanunk egy csomó jar fájlt véletlenszerűen egy csomó vason, akik mind benéznek a config szerverhez, beszólnak a service registryben, megtalálják egymást és működnek.

Harmadik út?

Minden eszköz csak egy legódarabka a játékban és sok mindent meg lehet építeni a meglévő eszközökkel.

Az azonban látszik, hogy sokan keresik az utat és gondolkodnak, hogy mit tehetné meg kezelhetővé a helyzetet.

Nomad: A Hashcorp például csinált egy olyan scheduler-t Nomad néven, ami azt tudja, mint a docker-re épülő társai. Ha megmondjuk neki, hogy kell még egy instance, annak megkeresi a megfelelő helyet (ugye ez már a 10+ gép + microservice instance-ek garmadája helyzet) és ott elindítja. Ráadásul okosan csinálták meg: nem egy teljes konténer cluster-t akartak csinálni (mint a kubernetes), hanem csak egy funkcióját, a schedulert, az viszont használható mindennel együtt (ráadásul támogat docker-t is és standalone jar-okat is).

Capsule: Vagy itt van a capsule.io. Ez eredetileg azt tudja, mint a maven shade plugin, egy nagy futtatható jar file-t csinál. amit csak el kell indítani. Kicsit trükkösebb, mert az eredeti jar fileokat használja, csak kicsomagolja egy temporális könyvárba, ezért nem kell foglalkozni a leírók összefésülésével, mint a shade pluginnel.

Sőt, kitalálták azt is, hogy innentől az, hogy hogyan futtassuk igazából pluginelhető kell hogy legyen (caplets-eknek hívják). Ha tudja milyen Java osztályt kell elindítani, azt eltudja indítani sima process-ként, service-ként, vagy úgy hogy a függőségeket közvetlen egy maven repóból frissíti be (hmm, easy autoupdate…).

És ha már itt tart, akkor az egyik caplet el tudja indítani a jar file-t egy lightweight lxc konténerben is.

(Megjegyzés: Kár hogy a capsule maven/gradle pluginjei még elég fapadosak, és az alap capletsen felüli dolgokat kicsit szenvedés bevarázsolni, és némelyik caplet is elég teszteletlen, pl pont a serviceként futtató jvsc wrapper).

De az irány érdekes. Végül is docker-rel is eljátszhatnám, hogy a konténer maga mindig ugyanaz és nem buildelem le, viszont a sima meztelen jar-omat már egy (vélhetően ritkán változó, verziózott) docker containerben indítom el. Ekkor a docker előnyei is megmaradnak, de a komplexitásból is vágtunk kicsit (illetve áthelyeztük a komplexitást azokra a szolgáltatásokra, amit mondjuk a spring-cloud ad sima java processzként).

Docker konténerek linkelése II, Consul és Registrator

October 14, 2015, elek

Az előző postban láttuk, hogy alapszinten hogyan lehet összelinkelgetni a konténereinket csupán a docker fapados eszközeit használva. De vannak persze minderre már kicsit komolyabb eszközök is.

Service Registry, Consul

Ha már annyi konténerünk van, hogy egyre nehezebb számon tartani őket logikusan hangzik, hogy indítsunk el egy kockás füzetet, amibe majd mindent szépen felírunk, hogy mi hol van. Hívjuk a füzetet service registry-nek és valósítsuk meg a consul alkalmazással.

A consul egy változatos módokon clusterezhető service registry. Amellett hogy viszonylag okosan skálázódik, megszólítható DNS-en keresztül is (a HTTP API + interface mellett) valamint van benne health check: az agent úgy tudja a service-t regisztrálni, hogy folyamatosan figyeli, hogy mikor kell a regisztrációt visszavonni.

Ezek közül a DNS API az egyik legszórakoztatóbb játék. Ha egy service-t beregisztrálunk, akkor nem kell vesződni azzal, hogy aki használni akarja hogy fogja megtalálni, elég ha beírjuk a consul instance-t is DNS szervernek. Pl. ha volt egy valami service-ünk, akkor:

 > dig @localhost valami.service.dc1.consul

; <<>> DiG 9.10.3 <<>> @localhost valami.service.dc1.consul
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54249
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;valami.service.dc1.consul. IN  A

;; ANSWER SECTION:
valami.service.dc1.consul. 0    IN  A   172.17.0.3

;; Query time: 1 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Oct 21 15:22:45 CEST 2015
;; MSG SIZE  rcvd: 84

Persze portokkal már nem ilyen egyszerű a játék, bár az is elérhető SRV rekordok formájában, de ott lehet hogy már egyszerűbb a HTTP API-t használni.

Registrator

Ahhoz hogy a docker konténereink regisztrálva legyenek a consulban, minden konténerben kéne futnia egy agentnek. Ezt nyilván valóan nem szeretnénk. Szerencsére van a registrator nevű projekt, ami azt csinálja, hogy feliratkozik az összes docker eseményre, és ha van valami a dockerben akkor annak megfelelően frissíti a consul-t (vagy az etcd-t vagy a skydns-t).

Docker

A docker konténerek környékén több információra is kiváncsiak vagyunk:

  1. Mi a docker konténer belső dockeres IP címe.
  2. Mi a docker0 interface IP címe a hoston (láttuk hogy ez nagyon jól jön helyi linkelés esetén)
  3. Mi a host külső IP címe (ha esetleg több hoston futtatnák docker-t, akkor jól jöhet)
  4. Mik a belső port kiosztások (hagyományos linkelésnél ez számít)
  5. Mik a host gépre kiforwardolt portok (ha valaki más gépről akarná a service-t megkeresni)

Alapvetően két esettel számolunk (illetve akár többel is, de azt majd a végén fogjuk látni):

  1. Ha csak egy gépünk van, akkor elvileg elég lehet tudni a belső IP-ket (1) és belső portokat (2).
  2. Ha több gépen vannak a konténerek, akkor már valószínű a host IP (3) és a forwardolt portok (5) érdekelnek.

A registrator elvileg mindkettőt tudja.

Egy gép

Indítsunk egy consul-t:

sudo docker run -d -p 8400:8400 -p 8500:8500 -p 53:53/udp -h node1 progrium/consul -server -bootstrap -ui-dir /ui

Innen már megnézhetjük a webes interface-t is: http://localhost:8500

Indítsuk el a registrator-t -internal kapcsolóval:

sudo docker run -d  --name=registrator --volume=/var/run/docker.sock:/tmp/docker.sock gliderlabs/registrator:latest -internal consul://10.8.0.172:8500

Indítsunk el egy példa service-t:

sudo docker run -e SERVICE_NAME=valami --name web5 --label type=frontend -p 7679:80 -d test

Majd ellenőrizzük a registert:

curl -v http://localhost:8500/v1/catalog/service/valami | jq
[
  {
    "Node": "node1",
    "Address": "172.17.0.1",
    "ServiceID": "56290e6d259f:web7:80",
    "ServiceName": "valami",
    "ServiceTags": null,
    "ServiceAddress": "172.17.0.3",
    "ServicePort": 80
  },
  {
    "Node": "node1",
    "Address": "172.17.0.1",
    "ServiceID": "56290e6d259f:web7:443",
    "ServiceName": "valami",
    "ServiceTags": null,
    "ServiceAddress": "172.17.0.3",
    "ServicePort": 443
  }
]

Vagy akár DNS-en keresztül

 > dig @localhost valami.service.dc1.consul

; <<>> DiG 9.10.3 <<>> @localhost valami.service.dc1.consul
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54249
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;valami.service.dc1.consul. IN  A

;; ANSWER SECTION:
valami.service.dc1.consul. 0    IN  A   172.17.0.3

;; Query time: 1 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Oct 21 15:22:45 CEST 2015
;; MSG SIZE  rcvd: 84

Több gép

A második esetben a registrátornál az -internal kapcsoló helyett segítsünk megtalálni a külső interface-ünk IP-jét:

sudo docker run -d  --name=registrator --volume=/var/run/docker.sock:/tmp/docker.sock gliderlabs/registrator:latest -ip=10.8.0.172 consul://10.8.0.172:8500

Ekkor az eredmény:

 > curl -v http://localhost:8500/v1/catalog/service/valami | jq
[
  {
    "Node": "node1",
    "Address": "172.17.0.4",
    "ServiceID": "0bbcbb14882c:web7:80",
    "ServiceName": "valami",
    "ServiceTags": null,
    "ServiceAddress": "10.8.0.172",
    "ServicePort": 7680
  }
]

Vagy:

 > dig @localhost valami.service.dc1.consul

; <<>> DiG 9.10.3 <<>> @localhost valami.service.dc1.consul
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17600
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;valami.service.dc1.consul. IN  A

;; ANSWER SECTION:
valami.service.dc1.consul. 0    IN  A   10.8.0.172

;; Query time: 1 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Oct 21 15:42:22 CEST 2015
;; MSG SIZE  rcvd: 84

Összefoglalás

A consul alkalmazása ott kezdődik, ahol több gépen futnak már a docker konténereink, és ott folytatódik, amikor a több gép docker konténereit egy virtuális hálózatra fűzzük fel. Ilyet tud pl a Weave (aki, micsoda véletlen, épp a registrator szponzora) vagy a Flannel. Ezek az eszközök viszont már megint egy szinttel feljebb visznek minket, ami pedig megint egy következő történet lesz.

JavaDay Kyiv

October 6, 2015, dpc

Now the JUG UA team is working hard on the 5th JavaDay Kyiv, which will be held in Kyiv on 6th-7th of November.

Thanks to Jelastic, the Father of Java James Gosling will speak online at conference. The JUG UA has started to collect questions for James on Facebook. So don’t hesitate and post or like questions.

This year’s conference will have deep focus on Java-core platform (Java 8 & Java 9), microservices and Java Enterprise technologies.

Preliminary conference program is available here, after the conference at October 8th, Venkat Subramaniam will give training “Essence of Agility - The Key Technical Practices”

Anniversary JavaDay Kyiv facts:

Among our speakers are James Gosling (online), Venkat Subramaniam, Arun Gupta, Bruno Souza, Robert Field, Marcus Lagergren, Maurice Naftalin, Patrycja Wegrzynowicz, Baruch Sadogursky, Kai Waehner, Mohamed Taman, Oleg Šelajev and many others.

Docker konténerek linkelése

September 30, 2015, elek

A docker legjellemzőbb felhasználási módja, amikor az alkalmazásunk több docker konténerben szétosztva fut. Vélhetően van egy futó docker konténer, ami az adatbázist nyújtja, és mondjuk van egy, amiben a backend fut (REST interface-ek) és van egy amiben a frontend (single page js app).

Célszerűen a frontend-ben egy nginx fut, ami kiszolgálja a statikus html/css/js fileokat és a /api kéréseket tovább proxyzza a backend felé.

A kérdés az, hogy hová kell proxyzni a kéréseket? A frontend és backend konténereket külön deployoljuk ezért várhatóan sokszor megváltozik az ip címük. Amire szükségünk van, az egy dinamikus összerendelés a kettő között, ami alapján a frontend mindig a legújabb backend példány felé tudja továbbítani a kéréseket.

Példa konténerek

A példa kedvéért vegyünk egy egyszerű http szervert backendnek:

docker run -d --name backend -p 8000:8000 python  python -m http.server

Majd futtassunk egy frontendet:

docker run -p 1600:80 --name frontend --link backend:backend -it nginx bash

Adjuk hozzá a proxy_pass direktívát a /etc/nginx/conf.d/default.conf filehoz, hogy bizonyos url alatt érkező kéréseket a backend API-jára irányítunk.

location /usr {
   proxy_pass http://?.?.?.?:8000
}

Majd futtassuk az nginx-et (nginx).

(Megjegyzés: általában itt /api url-t kell elképzelni, de mivel a backend kezdeményünk a root könyvtárat ajánlja ki http-n, játékból azt játszuk, hogy a /usr alatt vannak az értékes API hívások, amiket majd a frontend single page app fog hívogatni.)

Ez így mind szép, de mit írjunk a kérdőjelek helyére?

Linking + environment variables

Mivel a két konténert összelinkeltünk (--link backend:backend), ezért a frontend konténerben elérhetőek azok a környezeti változók, ami alapján tudjuk, hogy hol keressük a backend-et.

BACKEND_NAME=/frontend/backend
BACKEND_PORT=tcp://172.17.0.34:8000
BACKEND_PORT_8000_TCP=tcp://172.17.0.34:8000
BACKEND_PORT_8000_TCP_ADDR=172.17.0.34
BACKEND_PORT_8000_TCP_PORT=8000
BACKEND_PORT_8000_TCP_PROTO=tcp

Sajnos az nginx nem támogatja a környezeti változók használatát a config fileokban, de kis erőfeszítéssel tudunk olyat írni, hogy indulás előtt lecseréljük a proxy_pass értékét a környezeti változó alapján. (man sed)

Ha megcsináltuk, a konténerek elkezdenek tökéletesen együttműködni. A böngészőből a http://localhost:1600 cím a statikus tartalmat, a http://localhost:1600/usr a proxzyott api hívásokat adja vissza.

Egészen addig, amíg újra nem deployoljuk a backendet (docker stop backend, docker rm backend, docker run –name backend …). Ilyenkor ugyanis jó eséllyel új ip címet kap a konténer és a kapcsolat a két konténer között megszakad addig amíg a frontendet is újra nem indítjuk.

Linking + host file

Szerencsére a docker linkelésének van egy másik oldala is. A /etc/hosts file dinamikusan frissül a linkelt konténer aktuális ip címével:

172.17.0.51 frontend
172.17.0.51 frontend.bridge
172.17.0.37 backend
172.17.0.37 backend.bridge

Tehát ha újraindítjuk a frontend-et: a környezeti változókban még a régi ip-k lesznek, de a host file-ban az újak. Tegyük tehát a backend hostnevet a proxy_pass direktíva után.

Sajnos így sem megy. Az nginx ugyanis cacheli a domain név feloldásokat. Ha a domain névszerverből jön mondhatunk timeout-ot, de a /etc/hosts file örökre cachelődik.

(Elvileg rakhatnánk az nginx mellé egy lokális dns szervert, például dnsmasq-t, de csak bonyolítaná a dolgot, ráadásul a dnsmasq-t se egyszerű rávenni a host file újra olvasására.)

Ambassador pattern

Tovább válogatva a megoldások között szembe jön az ambassador container minta, ahol egy harmadik konténert teszünk a backend és a frontend közé, ami csupán routolja a kéréseket. Sajnos azonban a leírással ellentétben ez a mi problémánkat nem oldja meg, ha a backend megváltozik (új ip), akkor az ambassador konténert is újra kell indítani és utána pedig a frontendet. (Az ambassador konténer előnyeit úgy tűnik nem csak én nem értem.)

Grand ambassador

Szerencsére azért van még más megoldás is. A grand ambassador konténerben nem egy egyszerű socket proxy lakik, hanem egy go program, ami a docker event stream-jéből rájön a változásokra és konténer újraindítás után jó irányba fogja proxyzni a kéréseket:

docker run -d -v /var/run/docker.sock:/var/run/docker.sock --name backend_ambassador -p 7000:8000 cpuguy83/docker-grand-ambassador -name backend

Látható, hogy a docker.sock-ot bemappeltük a konténerbe, hogy az ambassador matathasson benne, és lássa mi változik. De cserébe innentől a backend_ambassador 7000-es portja újraindítás után is a backend-re mutat, ezért a frontend már összelinkelhető a backend_ambassador-ral.

Igaz cserébe kicsit bonyolítottuk a dolgot. Az összes api hívás forgalmát átküldtük egy plusz rétegen (nagy terhelésekre minimum tesztelni kéne, keep-alive, stb…) és egyel több konténerre van szükségünk.

Port over host

Egy egyszerű megoldás azonban van még.

A frontend docker konténerből ugyanis nem csak a backend konténer érhető el, hanem a host gép docker interface-e is.

4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:55:33:33:99 brd ff:ff:ff:ff:ff:ff
    inet 172.17.42.1/16 scope global docker0
       valid_lft forever preferred_lft forever

Mivel backend konténernek publikáltuk a portját, nincs más dolgunk, mint a host gép docker interface-ének ip-jét használni. Ez az ip, ha nem is túl kanonikus módon de elő varázsolható, és vélhetően sokkal kevésbé fog változni (max docker daemon restartok után).

Ez egy kicsit lazábban csatolt, de biztos kapcsolatot ad a két konténer között

Service discovery

A fapados és egyszerű megoldás tehát a docker host ip-jének és a publikált portnak a használata. De persze egy komolyabb környezetben valószínű komolyabb eszközök is vannak: pl. egy key-value store, amibe minden service-t regisztrálunk és lekérdezhetünk (akár DNS interfacen keresztül mint pl. a Consul-nál). Ezek a megoldások már akkor is működhetnek ha több gépen futó konténereket akarunk összekapcsolni. De erről a szintről majd egy másik történet fog szólni…

Microservices (JUM)

September 17, 2015, elek

A tegnapi JUM-on két előadás is szólt a microservice-ekről. Az első egy általánosabb bevezető volt (Peter Boon - The Theory of Microservices), a második egy tehnológiai megvalósítást mutatott meg (Norbert Sram - Java in the land of microservices ).

Az előadások érdekesek voltak, de több olyan dolog is előjött, amik szerintem pontosításra szorulhatnak. Az alábbi szövegben a címek általában az előadásból/prezentációból valók, alatta a kommentjeim.

[Microservice is] “Architectural style without formal definition”

Ez a (nem)definíció rögtön szimpatikus volt, mert nem húzza túl szorosra a határt. Számomra ugyanis az az érdekes, hogy hol húzzuk meg a határt a microservice-ek és a monolit alkalmazások között. A kettő között ugyanis ott vannak még valahol a moduláris alkalmazásaink is, bár mintha ezt ritkán vennénk észre.

A prezentációban pl. a jellemzők nagy része gond nélkül ráhúzható lett volna egy moduláris alkalmazásra is. (A distributed szó emlékeim szerint nem szerepelt, csak a network latency jelent meg később mint hátrány.)

Egy kicsit azt gondolom, hogy az esetek jó részében csak modularitástra van szükségünk, és miközben ezt keressük megkapjuk a microservice-ek vagy az OSGi komplexitását is.

“SOA != Microservices”

A másik nagy kedvencem, amikor gondosan elhatárolódunk a SOA-tól. Persze értem én, sajnos a nagy enterprise termékek ugyancsak lejáratták a SOA szót, és ha a SOA számunka végtelen sok WSDL, akkor tényleg nem ugyanaz.

Az előadás második felében azonban rögtön előjött az interface-ek verzózásának kérdése (nem így volt megfogalmazva, de erről volt szó), és ha elkezdünk microservice-eket gyártani, akkor előbb utóbb nagyon hasonló kérdésekkel fogunk találkozni, mint egy SOA architektúrában.

A SOA démonizálása helyett inkább tanulni kéne belőle, mert ha őszintén összehasonlítanánk a kettőt, nagyon sok párhuzamosságot találnánk…

Persze SOA v2 néven nehéz lenne eladni…

Teknősök

A második részben egy példát láthattunk microservice architektúrára. A példa egy teknősbékákat figyelő alkalmazás megvalósítása volt (kamera, hőmérséklet, stb.).

Persze azt értettük, hogy egy ilyen kis (RPi-n futú alkalmazás) megvalósításához valószínűleg a microservices architektúra pont nem annyira ideális, ez inkább csak kísérlet, tanuló projekt volt.

De amellett, hogy valószínű jobb lett volna valami életszagúbb példa itt is előjön a kérdés, hogy hol az a komplexitás, amikor már megéri microservice-eket használni. (Lásd még Fowler bácsit itt és itt, valamit az ellenvéleményt itt.)

Ez egyik slideon például fel voltak sorolva a nevek, hogy kik használják (Amazon, Google, NetFlix, stb.), de nekik vélhetően teljesen más problémájuk van mint egy átlagos backend-frontend webalkalmazásnak.

Hasonló a helyzet mint a NoSQL-nél: sokszor sok innováció/trend a nagy startup cégektől ered, és előfordul, hogy az ő környezetükben bevált problémákat gondolkodás nélkül alkalmazni akarják minden más környezetben is.

(Figyelem, nem azt állítom, hogy ezek nem alkalmazhatóak. Pl. szerintem egy schema-free MongoDB sok esetben egy-szerveres környeteben is sokkal hasznosabb, mint egy SQL szerver. De pl. egy Cassandráról ezt nem állítanám)

“DRY or RY?”

Az állítás az volt, hogy a jó öreg Don’t Repeat Yourself már érvényét vesztette, és inkább implementáljunk mindent többször le a különböző service-ekbe. Például ne optimalizáljuk ki temp.jar-ba a hőmérséklet kezelő dolgokat, mert akkor túl nagy függőség lesz a microservice-eink között, hiszen több komponens is ugyanattól a jar-tól függene.

Szerencsére ez a mondás a kérdések alatt kicsit szelidült arra, hogy a utilityket azért megoszthatjuk. (Anélkül elég furcsa lenne, hogy a hibernate.jar-t használhatja több komponens, a temp.jar-t meg nem???)

A problémát alapvetően értem, attól féltünk, hogy ha az egyik komponens már más fajta adatot vár (közös POJO megváltozik a protokolban), akkor sok service-t újra kell deployolni.

De azért nézünk szét a világban. Olyat, hogy service interface-ek változnak, olyat már láttunk sokat (helló SOA) és eddig is valahogy megoldottuk a problémát (pl. lehet visszafelé kompatibilis változtatásokat tűrő protokolt használni). Meg azt is, hogy különböző verziójú függőségei vannak különböző service-eknek.

És igen, az is lehet egy eszköz a sok közül, hogy duplikálunk bizonyos kódokat, de én nem merném kijelenteni, hogy az egyetlen út és a DIY-nek vége a microservice világban.

“if multiple services access the same database, not doing microservices”

Ez is elhangzott mindkét előadásban. És ismét csak az a helyzet, hogy értem a mögöttes gondolatot (ha azonos sémát használunk, akkor az egy nagyon erős függőség két komponens között, amik függetlenek akartak volna lenni.), de a világ ennél azért összetettebb.

Példul a slideok-on valami miatt csak relációs adatbázis példák voltak (és a JOIN volt a probléma). Mi a helyzet pl. a MongoDB-vel, ahol a liberális sémakezelés miatt ez a függőség sokkal kissebb?

Mi a helyzet egy CouchDB-vel? Nem tekinthető-e az egész adatbázis úgy mint egy külön service, amit a HTTP REST API-n bárki elérhet?

És ha a CouchDB tekinthető, akkor ha a protokol nem HTTP, akkor ott miért nem?

Ismétlem: értem, hogy a függőségekről akartunk beszélni, de én – talán nem vagyok elég bátor – nem mernék ennek örvén olyan szabályokat megfogalmazni, ami sok esetben nem biztos hogy feltétel nélkül követendő.

Összefoglalás

Az emberiség nagy részének nem microservice-ekre van szüksége, hanem moduláris alkalmazásokra. Moduláris alkalmazást lehet microservice architekturával és máshogy is csinálni, és van amikor a microservice-ek elosztott tulajdonságaira is szükség van.

De már előre rettegek attól, hogy mennyi kontár kód fog születni a (félreértelmezett) microservice trend zászlaja alatt.

Javabar

February 13, 2015, sngeza

Security outsourced: federated authentication/auth­orization and Java

Február 26-án újra JavaBar: www.meetup.com/bpjavabar

Trendek és távlatok a Java világából

Előadó: Varga Péter

Az előadásban áttekintjük a federált autentikációhoz/autorizációhoz kapcsolódó alapvető technikákat és szabványokat. Szó lesz többek között OAuth 2.0-ról, OpenID Connectről, SAML-ról, Json Web Tokenekről és ezek viszonyáról.

Kiderül, milyen mechanizmusok működnek a social authentication megoldások mögött (Facebook, Google, LinkedIn stb. login) és hogy hogyan tudunk hasonló funckionalitású szolgáltatást mi magunk is létrehozni.

A felmerülő szabványok használatát működő Java és JavaScript példákon keresztül mutatjuk be. Federációhóz segítségül hívjuk a nyílt forrású OpenAM IRM szolgáltatásait.

És természetesen lesz kávé (Java)!

(már 20 várólistás!!! Kéne egy jó nagy terem, ki tud felajánlani?)

HOUG Konferencia - Call for Papers

February 13, 2015, sngeza

Call for Papers - Előadók jelentkezzetek!

Jelentkezzetek előadással a HOUG konferencia Java napjára! www.houg.hu/konferencia

Az idén március 23-tól 25-ig tart a HOUG Konferencia Siófokon, a Hotel Azúrban. Az első napon, március 23-án lesz a Java szekció: egy konferencia a konferenciában. Erre várjuk az előadásokat.

Milyen előadásokat várunk?

Idén nincs kifejezett fő téma, de leginkább az olyan előadásokat preferáljuk, amelyek valamilyen tapasztalatról, érdekes projektről, újszerű megoldásról számolnak be (tehát pl. nem szeretnénk egy felsorolást a Java8 újdonságairól, de érdekel, hogyan oldottatok meg egy konkrét problémát pl. a Java8 valamelyik újdonságával). A teljesség igénye nélkül: JavaSE, JavaEE, Spring, Java-barát nyelvek és technológiák (pl. Scala, Ruby, …), HTML5 és JavaScript, JavaScript keretrendszerek.

Itt lehet jelentkezni előadónak: http://konferenciak.advalorem.hu/houg-2015/palyazas

Mi az a HOUG konferencia, és mi a Java nap és miért jó ez nekünk?

A HOUG, a Magyarországi Oracle Felhasználók Egyesülete (nem az Oracle Hungary Kft), évente rendez két nagy eseményt, a tavaszi 3 napos Konferenciát és az őszi szakmai napot. A HOUG-nak van egy Java Szakosztálya, amelyben azon munkálkodunk, hogy a konferencia Java szekciója ne csak egy alibi-szekció legyen, hanem érdekes, ismert szakmai eseménnyé váljon. Az elmúlt pár évben elértük, hogy most már egy teljes nap Java lesz, ÉS ez a nap ingyenes a hallgatóknak. Már “csak” jó előadások kellenek!

Nem adok elő, hallgatóságnak jöhetek?

Persze, regisztrálj a http://konferenciak.advalorem.hu/houg-2015 címen. Az első nap ingyenes. Itt alakul a program: http://konferenciak.advalorem.hu/houg-2015/program (később részletesebb lesz).

Ingyenes?

Az első nap, a Java Konferencia INGYENES, hallgatóknak, előadóknak egyaránt.

A további napok, illetve a szállás, étkezés díjai itt olvashatók: http://konferenciak.advalorem.hu/houg-2015/reszveteli%20tajekoztato (HOUG egyesületi tagoknak 10% kedvezmény)

Reklám:

A HOUG jogilag egyesületi formában működik. Hogy minél függetlenebb, szakmaibb lehessen, szüksége van a tagdíjakra, amihez szükség van tagokra. Itt lehet belépni: http://houg.hu/pls/apex/f?p=201:LEGYENONISTAG:0 , az egyéni tagság évi 5000Ft, nem mondanám, hogy nagyon drága.

Várjuk az előadókat, a hallgatókat, az új tagokat!

Üdv,

Simon Géza geza.simon@houg.hu

GeeCON 2014, Prága

December 9, 2014, pisti, soma, gabor

Day 1

Opening ceremony

gabor A megnyitó fő poénja, sok más szellemes megjegyzés mellett, nyilván a legfontosabb információ: a wifi jelszó.

10:30 - 11:30 Neal Ford - This is Water

“This keynote describes the water you swim in but cannot see anymore, like relational databases and application servers. Additionally, it jerks you out of safe, warm water (briefly) to describe a strange, fantastical world with things like immutable database server, phoenix machines, and lambdas.”

gabor Az előadó három betű segítségével mutatta be a tudomány mai állását a Jáva világában, hol is tartunk valójában: milyen eszközeink vannak, milyen technológiákkal rendelkezünk, illetve rávilágitott azokra, amink lehetne még. Fondorlatos hasonlatokon keresztül megkezdtük a funkcionális nyelvi történelmi utazásunkat: a nűtől indulva deltán keresztül eljutottunk egészen lambdáig, mint a Jáva 8 legnépszerűbb újításáig. A többmagos processzorok világban a funcionális szemlélet és a funkcionális paradigmák sokkal jobban idomulnak ezekhez az architektúrákhoz. Méltán mondhatjuk, hogy a funkcionális programozás a reneszánszát éli, hiszen sikerült megtalálni a hiányzó kapcsot az egyetemi kutatólaborokban rekedt kisérleti stádiumban lévő funcionális programozás és a való életben, mindenapokban használt technológiák között. E kapocs megszemélyesítője lehet a Jáva 8-ból a lambda kifejezése, a Clojure, a Groovy vagy éppen a Scala. Az előadó a könyvéből vett egyszerű példákon keresztül mutatta be, mennyivel tömörebben (és ekvivalens módon) fejezhető ki ugyanaz a probléma a lambda kifejezés segítségével, funkcionális megközelítésben. Én csak gratulálni tudok az előadónak, nagyon érdeke, értékteremtő és színvonalas előadást láthattam, méltó egy keynote előadáshoz.

This is Water

11:50 - 12:50 Janne Sinivirta - Pragmatic Architecture for Agile Teams

pisti BDUF (“big design up front”) vs. YAGNI (“you ain’t gonna need it”). A nagy kérdés: tervezzünk-e meg mindent előre, az összes lehetséges jövőbeli funkcionalitásra kiterjedően, vagy szigorúan csak a legszükségesebbekre fókuszáljunk. A legfontosabb, hogy minél hamarabb felismerjük a problémát, elkezdjünk munkálkodni rajta, az ismeretlen részekből PoC-ot (Proof of Concept) építsünk, hogy minél több információt gyűjthessünk róluk. Bármelyik tervezési koncepciót is választjuk, fontos, hogy tisztában legyünk azzal, hogy az architekt nem feltétlenül egy önálló pozíció, hanem egy felelősségi kör, melyet a csapatnak kell vállalnia. Minden tagjának részt kell vennie a tervezési folyamatokban, ezzel egyidejűleg pedig képben kell lenniük a projekt egészét illetően. (Ne nevessünk a juniorok ötletén!) Ezenkívül fontos a kommunikáció. Beszéljünk a döntéshozókkal, hiszen ők is csak emberek, ha azt mondjuk ezt nem lehet megtenni, csak tovább dobjuk a labdát. A megvalósított architektúra végül hasonlítani fog magára a szervezetre aki elkészítette. (Conway törvénye nyomán.) Ha például a szoftver két moduljának kell korrektan együttműködnie, akkor az azokat fejlesztő két csapatnak is megfelelően kell kommunikálnia. Ha valami nincs rendben a csapatok közötti kommunikációval, a szoftver moduljai is hasonlóképpen fognak működni. Mindig beszéljünk a megrendelőkkel, derítsük ki, mit szeretnének valójában. Lehet nekik nincs is arra szükségük, amit mi tervezünk leszállítani számukra. Ne a jövőbeli terveikről beszéljünk, és legfőképpen ne ezek szerint építsük az architektúrát. Végezetül beszélni kell a dokumentációról. A legfontosabb , hogy akkor írjuk, ha az segíteni fog annak, aki majd használni fogja! (Tehát tudjuk kinek írjuk!) A “must have” dokumentációk:

gabor Az előadón látszott a mérhetetlenül nagy, főleg tapasztalati úton szerzett tudás. Ezt sikerült a tapasztalokon alapuló gyakorlatias előadásban, rengeteg, az életből vett példákon keresztül bemutatni. Everybody loves documentation. Az egyik közkedvelt téma a dokumentáció-írás: öndokumentáló kódot kell írni, ez a rész benne van ebben és ebben, és még sorolhatnám, hangzanak fel a tologató, halogató mondatok. Nekem ez a része tetszett a legjobban az előadásnak. Az agilis módszertan is megköveteli a jóldokumentáltságot, viszont csak és kizárólag azoknak a dokumentumok meglétére fókuszál, amelyekre valóban szükségünk van. Melyek azok a dokumentumok, amelyek nélkülözhetettlenek? Domain dictionary, internal component diagram, external integration diagram, domain model as code, desicion log. Ezek az önmagukért beszélő, nem plusz dokumentumok, hanem kizárólag a lényeges és szükséges elemek, amelyek a valóban fontos információkat lényegretörően tartalmazzák. Akik az agilis irányba mozdulnak, egy hibaforrás lehet, ha nem veszik elég komolyan a dokumentumok készítését, pedig nagyon hamar megtérül a befektetett energia. Ezen dokumentumok hiánya idézhet elő olyan jól ismert eseményeket, amelyek végtelen időt képesek felemészteni, például felesleges plusz körök futása, újra és újra megkeresni különböző dolgok lelőhelyét, újabb és újabb megbeszélések, mi miért történt, mire miért eset a választás, a sor a végtelenségbe mutat. Nagyon hasznosnak véltem a látottakat, így fogom csinálni.

soma Az előadás egyik számomra legérdekesebb példája a decison log fontosságával kapcsolatban merült fel. A példa arra világitott rá, hogy a decison log megléte mennyi kellemetlenségről tud minket megvédeni.

Leg több esetben rengeteg frameworköt és eszközt használunk. A mérhetetlen mennyiségű függőség verziója közül, miért éppen az egy-ket verzióval régebbit választottuk, miért nem a legujabb verziót használjuk. Egy hosszabb projekt során ezek a korai döntések feledésbe merülhetnek, és rengeteg fejtörés tud okozni amikor az egyik eszköz verziószámát léptetjük mert, bekerült az a feature ami-t használnánk vagy éppen javították az egyik kis hibát. Hatalmas öröm mellet elváltjuk a verziót, és mérhetetlen mennyiségű munkaórába tud kerülni az, hogy újra rá jöjjünk, hogy az a verzió nem kompatibilis egy másik eszköz függőségével.

12:50 - 13:40 Lunch Break

gabor Nem tudom felidézni azt a pillanatot mikor ebédeltem utoljára moziban.

soma “Marhajó marha pörkölt!” és eközben egy érdekes beszélgetés a “Pragmatic Architecture for Agile Teams” előadásról. Arról, hogy az agilis, no-architecture módszer alkalmazásánál, az esetleges kudarcok, bukások esetén kik voltak a felelősök, kik azok akiket felelőségre lehet vonni? A régi módszer szerint van egy architect akire lehet ilyen esetekben “mutogatni” míg az agilis, no-architecture kollektív döntései esetén, vajon ki, milyen mértékben felelős?

13:40 - 14:40 Oliver Gierke - Whoops! Where did my architecture go?

gabor Humormorzsákkal fűszerezett, színvonalas prezentációt láthattunk, egy rendkívűl alaposan felkészült előadóval, rengeteg demo-val. Az előadáson végig érezhető volt a német precizitás.

A horizontális architektúra felosztás már a kisujjunkban lehet pár év gyakorlat után, mégis hajlamosak vagyunk elfelejteni, hány szinten is van lehetőségünk dekomponálni a problémát megoldó alkalmazásunkat, milyen finom granualitású lehet egy rendszer felosztása: modulok, layerek, vertikális felosztás, alrendszerek, a deployment unitok mint a war és jar fájlok, package-ek, osztályok. Egy komponens vizsgálatakor más nézőpontokat is bevezethetünk az egyetlen felelősség elve mellett, ilyen például a módosítással járó kozkázatnak a csökkentése, mellyet a függőségek minimalizálásával érhetük el. Ennek megoldásában segítségünkre lehetnek a package-ek és azok elnevezési konvenciói és a vertikális felosztás kettőse, az előadás két kulcsfontosságú szereplője a függőségek csökkentése érdekében.

Egy jól irányzott demo segítségével megnézhettünk, hogyan kell kihasználni a package-ekben rejlő lehetőségeket, hogyan kell pár apró trükk segítségével leszorítani a fordítási folyamat közelébe a visszacsatolást az esetleges hibákról, hibalehetőségekről, hogyan menedzselhetjük legkönnyebben függőségeinket. Az előadó a demo során kísérletet tett arra, milyen messze tud eljutni csupán plain Jáva alkalmazásával.

A package-ek konvencionális elnevezése előremutató, megalapozhatja a későbbi beavatkozások mértékét: sokkal fontosabb az elv, hogyan tartsuk karban a kódbázisunkat, szemben azzal, hogyan implementáljuk azt. (How to implement an architecture inside a codebase? versus How to maintain an architecture inside a codebase?) A package-ek számát tekintve is a minimumra kell törekednünk.

Mennyivel karbantarthatóbb kódot eredményez a következő package struktúra: customer.domain, customer.presentation, customer.service, customer.repository

Eszköz a karbantartási folyamatokra - Koncepcionális hibáink felderítésére, architekturális patternek betartatására, a package-eink és osztályaink statikus analizálására megszületett Sonargraph nevű program, melynek napi szintű használatára sarkall minket az előadó. A Sonargraph egy statikus kódanalizáló program többek között az alábbiakra hivatott megoldást nyújtani: architekturális pattern-ek, körkörös dependenciák felfedezése, láthatóság, layerek, slice-ok közötti kapcsolatok, plusz, millió riportot illetve kimutatást lehet készíteni kedvenc alkalmazásunkról.

A packagek segítségével befolyásolhatjuk a láthatóságot is, ezáltal a függőségek is nagy mértékben csökkenthetők: Nagyon egyszerű dolgokról van szó. Például, a layerek horizontális felosztásánál a default publikus interfész mellett az implementáció szükségszerűen (minimum) package private. Hangsúlyozta az olyan hibajelenséget is, hogy ha megkérdezünk egy Jáva fejlesztőt, hogy ennek és ennek az elemnek miért ilyen és ilyen a láthatósága kérdésre az IDE default így hozta létre rossz válasz. Egy Customer osztály esetében annak konstruktora ha package private, akkor nincs lehetőségünk meg-new-sni se vertikális slice-okból, se horizontális layerekből, tovább csökkentve ezzel a felesleges függést.

A packagekben rejlő lehetőségeket, és a vertikális felosztásból fakadó előnyöket megfűszerezhetjük még egy újabb szemléletű metrikával a dekomponálási folyamat során: különítsük el a gyakran valtozó és a nem gyakran változó kódhalmazokat is egymástól.

Csak ajánlani tudom minden fejlesztőnek az előadásról szóló blogbejegyzést, a whoops-architecture példaprogram vizsgálatát, és a Sonargraph programot napi szintű használatra.

whoops architecture whoops architecture prezi github

soma Számomra ez az előadás volt a legkedvesebb, és egyben a leg tanulságosabb. Pár mondatban összefoglalni ezt az eőadást nem lehet, de megpróbálom. Az előadás leglényegesebb üzenete az volt, hogy miért fontos és hasznos a függőségeink ismerete, milyen eszközökkel lehet vizsgálni ezeket, milyen egyszerű módszerekkel és szabályokkal lehet redukálni függőségeinket.

Az előadás elején elhangoztak a slice és layer megfogalmazása, melyik ki számára érdekes. Az egyik érdekesebb kérdés még az előadás elején elhangzott: Adott egy jáva alkalmazás. Milyen package konstrukcióval valósítható meg a függőségek redukálása, minimalizálása. Válaszok: layer, layer.slice, slice.layer, slice. Mit ne mondjak, a helyes válaszra tartották fel a kezüket a legkevesebben, ami a slice. A kapott válasz furcsa, az indoklás annál érdekesebb. A demo során meg nézhettük, hogy milyen tipikus hibálat lehet elkövetni egy szokásos layer, layer.slice konvenció esetén. Például láthatósági problémák, mert ezekkel a konvenciókkal az osztályok láthatósága majdnem minden esetben kizárólag publikus lehet, hiszen hogyan hivatkozhatnánk egy repository package-ban lévő interface-ra a service package-ban lévő osztályból. A megoldás ezért lesz a slice, hiszen ha van egy customer package-nk akkor ebben “naming convention” segítségével létre tudunk hozni minden szükséges réteg beli osztályt, az alsóbb rétegek osztályait package private-ra (alapértelmezettre) állítjuk, meg tudjuk védeni a kódunkat, biztosan nem lesznek hivatkozások ezekre az osztályokra, interfészekre más package-k ből. Így tudjuk csökkenteni a lehettséges függőséget egy alkalmazáson belül. “Start with less packages and the least visibility possible…”

13:40 - 14:40 - Andrzej Grzesik - GO! The one language you have to try in 2014

pisti A Go (vagy más néven golang) egy a Google által fejlesztett programozási nyelv, mely munkálatainak 2007-ben láttak neki. Az előadó nem egy tutorial, sokkal inkább egy bemutató jellegű előadást tartott nekünk, mely során bemutatta a nyelv, számára izgalmas és érdekes újításait, különbségeit. Mindenek előtt el kell mondani, hogy ez egy statikusan típusos nyelv, mely leginkább a C-re hasonlít. Rendelkezik garbage collection-nel, típus biztos, valamint rendelkezik néhány plusz beépített típussal, mint például a változó-hosszúságú tömbök.

Futás idejű dependenciákkal nem rendelkezik, az import keyword-ökkel pedig magukat a forráskódokat kaphatjuk meg. Egy valamire azonban ügyelni kell. A fel nem használt importokat jobb, ha előre kitöröljük, ne várjuk meg, hogy a kezünkre üssenek. Egyetlen egy elfogadott formázással rendelkezik, így egységes küllemű kódok fognak megszületni a különböző forrásokból.

Goroutin-okkal a szálkezelésbe pillanthatunk be, míg a channel-ekkel az egyes függvények közötti kommunikációt valósíthatjuk meg (melyek akár barrier-ként is viselkedhetnek). Exception-ökkel nem rendelkezik, helyettük inkább return code-okkal működhet kis rendszerünk. Ha tesztjeink rendben lefutnak (nem történik semmi), akkor megnyugodhatunk, error code esetén pedig elgondolkodhatunk a hiba okán.

Remélem ezen rövid összefoglaló másnak is remek ízelítőként szolgált.

14:50 - 15:40 Neal Ford - Functional Thinking in Java 8, Clojure, Groovy, and Scala

gabor A keynote előadás folytatása egyetemi hangulatban, leginkább ezzel tudnám jellemezni a látottakat. Eléggé mélyen tárgyalt, részletes példákon keresztül ismerhettük meg a funkcinális feature-ket. Kicsit az volt az érzésem a tempót illetően, hogy “a férjen bele minden az időbe sebesség” volt a jellemző. Azok, akik nem találkoztak még funkcionális nyelvekkel, nem sajátították még el az elméleti alapokkal, azoknak egy nehezen emészthető egyetemi kurzusra sikerült betévedniük. A gyorsaság ellenére tetszett, és az egyetemi funkcionális programozás után ismét sikerült felkelteni az érdeklődésem, és igérem, most egy nagyobb erőbedobással fogok neki a funkcionális nyelvek elsajátításának.

Functional Thinking

16:00 - 16:15 Matej Briškár - JBoss Forge – building apps happens to be fun

soma Ez volt az az előadás, ami számomra egy “marketinges maszlagnak” tűnt. Az előadás során betekintés nyerhettünk abba, hogy milyen egyszerű használni a JBoss Forge eclipse pluginjait, milyen pillanatok alatt lehet egy alkalmazást “összekattintani”. Miben különbözik, miben jobb mint más hasonló eszközök? Erre a kérdésre sajnos nem kaptunk választ.

16:00 - 16:15 Václav Vávra Lockless hashmap implementation

gabor Ez jó volt, mert ebből nem értettünk semmit.

pisti Az előadás rövid volt, gyors lefolyású és nyilván ennek köszönhetően tömör és érthetetlen. Az előadó egy saját maga által fejlesztett sakk programot mutatott be, melyben egyedi megoldásokkal rukkolt elő. A címben szereplő hashmap implementáció is ehhez hasonlatos volt. A pillanat tört része alatt bent voltunk a sűrűjében… és ott is maradtunk az előadás végére. Kár.

16:40 - 17:00 Katarzyna Mrowca - Agile Project Management Anti-Patterns

pisti Mindenekelőtt el kell mondani, hogy míg az agilis project management (és ezen belül is például a Scrum) egy termék elkészítésének remek alternatívája, nem testesíti meg “az Egy igaz utat”. Tartsuk szem előtt, hogy semmiképp se legyünk “Scrum nazi”-k! Mit is jelent ez? Sokan olyannyira lelkesen ugranak bele a Scrum szabályrendszerébe, “rituális” szertartásaiba, hogy nem veszik észre, hogy lassan egy egyszerű költözködéshez, vagy az otthoni házimunka beosztásához is a Jira-t és a Scrum-ot használják. Nem hiába: ha van egy kalapácsunk, mindent szögnek nézünk!

gabor Egyetlen állandó dolog van, ez pedig a változás, és aki nem választja a haladást, nagyon gyorsan a sor végén találhatja magát. Elég nehéz a váltás, főleg ami a módszertant illeti, de statisztikák is megmutatták, megéri az agilis módszertan irányába mozdulni. A váltás folyamatában elkövetett, tipikusnak mondható hibákba engedett betekintést a következő előadás. A nézők soraiból többször lehetett hallani egyes anti patternek ismertetése alatt a felismerést és a hozzá tartozó sóhajokat: tényleg, valóban, ezt mi is rosszul csináljuk.

pattern1 gabor Aki elkötelezte magát az agilis menedzsment mellett, akkor annak azt teljes egészében véghez kell vinni, olyan nem lehet, hogy az egyes, kettes, és az ötös elv tetszik, ezeket átemelem, a többi esetében meghagyom a tradicionális gondolkodást. Ez egy mérhetetlenül rossz gyakorlat, nem fog működni, nem is lehet sikeres, hiszen az agilis módszertan nem így lett megtervezve. Mindazon jólbevált tradiciónális képességeknek búcsút kell mondani, amik a vízesés modelből ránk maradtak. Az említett model legfőbb hibája, hogy csak a folyamat legvégén kapunk visszacsatolást, amely a legtöbb esetben igenis késő. Ehhez viszont alapjaiban kell megváltoztatni a módszertant, ezért nem lehetséges, hogy csak bizonyos részeket emelünk át az agilis módszertanból.

pattern2 Meeting a meetingről gabor Önmagáért beszél, no comment.

pattern3 pisti A hagyományos project management-ből ismerős deadline-ok szigorú betartása ismerős lehet a félig hagyományos, félig agilis management-nek. Ugyanúgy, mint a project managernek - mint egy elhanyagolhatatlan Scrum szereplőnek - a daily standup-okon való részvétele.

pattern4 pisti Beszéljünk a megrendelővel, csak és kizárólag azokat a feature-öket fejlesszük le, amikre valóban szüksége van.

patternN gabor Számomra legkedvesebb, legmulattatóbb anti pattern, az önmagáért beszélő excel driven managment. Egyes helyeken azonnal szembetűnik, hogy legalább annyira őrült megoldás, mint a word-be illetszett jpg kép. Nem is gondolnánk, hogy lehet tetézni a fő problémát azzal, hogy az excel még csak nem is az első, hanem a második vagy akár a harmadik riportáló dokumentum, ahova a feladatokat, határidőket és egyéb jegyzeteket vésik. Nem IT szektorból hallottam, de létezik, “Váltottunk a Jira-ra, de azért még írjuk be az excelbe is.”

17:10 - 18:00 Martin Skurla - When assertThat(you). understandUnitTesting() fails

pisti A Unit teszteléshez mindannyian értünk. Az előadó szerint mindannyian csak azt hisszük, hogy értünk és valójában anti-pattern-ek egész sorát követjük minden egyes teszteset megírásakor. Vegyük sorra ezeket: A “testMethodName”-hez hasonló elnevezések rossz berögződéseknek számítanak. Nem lehet belőlük első ránézésre egyértelműen megtudni, hogy mi is a teszteset célja. Nagy valószínűséggel ezen függvények ráadásul nem is csak egyfajta lefutást próbálnak lefedni. Sokkal célszerűbb a “viselkedés + bemenet + kimenet” formát alkalmazni függvényeink elnevezésekor. Fontos a logikai csoportosítás, tehát nem feltétlenül kell ragaszkodnunk ahhoz, hogy ugyanazon osztály teszteseteit ugyanabba a teszt osztályba helyezzük el. Sokkal célszerűbb viselkedés szerinti teszt osztályokat létrehozni.

A “ClassNameTest” elnevezés is hasonló anti-pattern, mint legelső versenyzőnk volt. Ha logikai csoportosítás szerint hozzuk létre a teszt osztályokat, ezeket a rossz beidegződéseket el tudjuk kerülni. Egy teszteset többszöri végrehajtása ugyancsak kerülendő. Ennek egy tipikus esete, mikor feltételek, illetve ciklusok alapján építjük fel metódusunkat. Ha elkerülhetetlenek ezek a helyzetek, inkább szedjük szét több különálló függvényre őket.

Ne rendeljünk egy változóhoz több értéket. Az ehhez hasonló újrahasznosítások kerülendőek, mivel így többek között zavarosabbá válik a teszteset, valamint egy megváltozott állapotú objektum miatt a teszt végül nem a várt eredményt fogja adni. Minden változónak legyen meg a konkrét értéke, ami ne változzon a teszt lefutása közben.

Ugyancsak rossz szokás az assertTrue, assertFalse és assertEquals használata. Utóbbi esetén a teszteset olvasójának így nem lesz első ránézésre egyértelmű, hogy a vizsgált értékeknek miért is kell egyenlőséget mutatniuk. A legjobb megoldás saját osztályok használata erre a célra. A legjobb példa erre az előadás címe: “When assertThat(you).understandUnitTesting()”. Ha ez a teszt elbukik, rögtön tudjuk, hogy van az elgondolásainkkal egy kis probléma.

Ne használjunk error message-eket az assert-eknél, mivel pontosan ezek a szövegek fognak változatlanul maradni egy esetleges refactor után, aminek köszönhetően teljesen értelmetlen hibaüzeneteket fogunk kapni. A konzolra való loggolás még a Unit tesztelés esetén is kerülendő, már csak azért is mert helyes lefutás során egy lélek sem fogja ezeket elolvasni.

Összevont assertion-öket ne írjunk. Pl.: assertTrue(something && something). Ezek félrevezetőek és megnehezítik a kód olvasását.

A @Before metódusban ne inicializáljuk a változóinkat, mert megtörjük az “arrange - set - assert” mágikus kört. Ezek közül is értelemszerűen az “arrange” részt fogjuk elveszíteni. Nagyon érdekes, elgondolkodtató előadás volt. Szerintem mindenképpen érdemes átgondolni ezek alapján az eddigi Unit teszt írási szokásainkat. Sokat fejlődhet.

Day 2

11:30 - 12:30 Gleb Smirnov - Java Concurrency Under the Hood

soma Egy nagyon érdekes előadást hallhattunk a concurency-ről és ami mögötte van. Az előadás során az Open-JDK legmélyére túrtunk, az előadó professzionalizmusáról mindent elárul az a kérdés amit a JVM kódjának olvasása közben tett fel: “… ez tegnap még nem volt itt! Aki tudja mit csinál ez a kódrészlet, vendégem egy sörre!”. A több processzor mag viselkedéséről, a java volatile direktívájáról rengeteget tudhattunk meg. Bemutatott olyan tipikus többszálas programozás során előforduló hibákat amikre fel kell készülni, ha az ember concurency-vel akar foglalkozni. Megmutatja azt, hogy ha valaki nem érti ennek a legmélyét, akkor milyen production beli problémákkal találkozhat. Az egyik demo során bemutatott példakód 1 milliószor lett lefutattva, és azt kaptuk hogy mindössze pár száz esetben müködött rosszul a program. Az ilyen hibákat eléggé nehéz kidebuggolni, hiszen lehet, hogy a fejlesztési és teszt időszakban nem jelentkezik a probléma, vagy olyan egyszeri hibának tűnik, hogy elsiklunk felette. (sajnos nem emlékszem az eszköz nevére amit használt a futtatáshoz és a statisztikához) Az előadást mindenki számára csak ajánlani tudom. slides

13:20 - 14:20 Lukas Eder - 2000 Lines of Java? Or 50 Lines of SQL?

soma Az előadás hasznos volt, rámutatott egy két olyan tipikus hibára amit Java fejlesztőként könnyű elkövetni, ha nagyobb adatbázissal dolgozunk. Nem szeretném részletezni ezeket a hibákat, akit érdekel a téma, olvassa el az alábbi blog bejegyzéseket.

http://blog.jooq.org/2013/07/30/10-common-mistakes-java-developers-make-when-writing-sql/

http://blog.jooq.org/2013/08/12/10-more-common-mistakes-java-developers-make-when-writing-sql/

http://blog.jooq.org/2014/05/26/yet-another-10-common-mistakes-java-developer-make-when-writing-sql-you-wont-believe-the-last-one/

14:30 - 15:30 Miroslav Kopecky - The Robot under dictate of the LegoMindStorm + Java Concurrency API: Let.s shift the future!

gabor Már bánom, hogy hallgattam a többiekre, amikor feltették a kérdést, hogy melyikre üljünk be.

pisti Érdekes előadásnak lehettünk részesei. Az előadó nagy szenvedéllyel és átéléssel mutatta be a hallgatóságnak munkája alanyát, egy 20 centiméter magas LegoMindStorm robotot. Maga a robotépítő készlet egy otthon is elérhető, voltaképp LEGO készlet, mely tartalmaz - az alapvető építőelemeken felül - nyomásérzékelőt, giroszkópot és távolság érzékelőt, csak hogy párat említsek az egyéb tartozékok közül. Az előadó feladata az épített robot mozgását lehetővé tevő motorok működésének összehangolása. Személy szerint nekem is lehetőségem nyílt az egyetemi tanulmányaim során használni egy ilyen készletet, és megoldani egy bonyolult feladatot. Ami ott az egyik legnehezebb feladatnak bizonyult, az a robot pontosan 90 fokos fordulásának elérése volt. Sajnos ez a készlet hiányosságainak köszönhetően csak az esetek 60-70%-ban sikerült. Szívderítő volt látni, hogy valaki ekkora odaadással képes beszélni saját munkájáról, izgalmassá téve az előadást az erre fogékonyabbak számára. Másoknak is tudom ajánlani.

Golden spokes

Lehet a vonaton sörözni? Ezért járok vonattal.

Jó, jó a szoba megvan, de a wifi miért nem működik már? (történt ugyanis hogy 3 programozónak több mint fél órába telt sikerült csatlakoznia az internetre)

gabor Izgatottan vártuk a zárszót, de előtte a legos gyerek képes volt megkérdezni még a mikrofonba, mint a témához szorosan nem kapcsolódóan, hogy van-e a közönség soraiban egy Thomas, mert órák óta keresi.

ForgeRock IRM Summit 2014, Dublin

November 12, 2014, sngeza

Last week we attended the European summit for Identity Relationship Management (which (IRM) is not just a new, fancier name for Identity and Access Management (IAM) as it turns out, but more. Some quick notes:

First of all, Ludo has a concise summary of the two and a half days here: Ludo’s Blog. Him being a photo enthusiast too, there are pictures too. Can you find us on one of them?

My personal favourite presentation was Ian Glazer’s (Salesforce) contemplating whether we already have a round wheel. Interesting topics, great presentation style, unconventional slides. He also introduced the next logical step after person, organizationalPerson, inetOrgPerson. It is of course hipsterOrgPerson Barbara Jensen!

I made a note to myself to check out Juju, a config management tool for the cloud era. We saw a demo too.

Also encapsecurity and their multi factor authN with TouchID. Among the technical details we also got to learn that “it’s not your attribute if you’re not born with it”, i.e. “you are not your phone”.

And at night @xmlgrrl was singing and @jonibrennan played the flute.

Thanks, organizers, see everyone next year.

Hacktivity 2014, Budapest

October 10, 2014, gabor

Sok év után, idén először sikerült eljutnom a Hacktivity-re, Kelet-Közép Európa IT Biztonsági Konferenciájára, melynek idén októberben a MOM Kulturális Központ adott otthont. A Hacktivity az etikus hackerek, biztonsági tanácsadók és szakértők fóruma. Lelkes amatőr érdeklődőként látogattam ki a rendezvényre. Számtalan könyvet, cikket elolvastam már a témával kapcsolatban, gyakorlatom nincs, tehát kíváncsi voltam.

A rendezvény fő mondanivalóit annak rendje és módja szerint a két napos rendezvény két keynote előadása hordozta magában: mire kell figyelnünk a mai világban a biztonság tekintetében, milyen új kihívásokkal kell szembenéznűnk, legyünk akár felhasználók, fejlesztők, biztonsági szakértők.

Keynote előadások

Jason Chan Keynote - Építsünk üvegházat: modern szoftver architektúrák és gyakorlatok biztonsági adaptációi

A mai szoftverek hatalmas átalakuláson mennek keresztül, tekintve az infrastruktúrát, az üzemeltetést, sőt, még a szoftverfejlesztés módszertana is gyökeres megváltozott. A tradícionális vízesés modellt kiszorítják az agilis módszerek, megjelennek a mikroszervizek a monolitikus (makro)rendszerekkel szemben, egyre több és több szolgáltatás jelenik meg felhő alapokon, egyre nagyobb figyelmet kap a DevOps.

Ami az alkalmazások biztonságát illeti, ideje gyászolni: viszlát traditionalis alkalmazás biztonság, alig ismertünk, nem sok időt töltöttél velünk.

Új feladatok várnak ránk, új problémákkal találjuk magunkat szemben, ugyanis a jól bevált tervezési mintákat és a tradícionális biztonsági modelleket nyugodtan elfelejthetjük. Egy folyamatosan változó rendszerben újabb és újabb biztonsági problémák lépnek fel, amelyekhez nehéz idomulni, folyamatos nyomonkövetést igényel, hogy időben be tudjunk avatkozni. Egy ilyen rendszer esetében nem tudunk egyetlen egzakt szabályrendszert, modellt, védelmi protokollt felépíteni, amely hatásos és gyorsan képes reagálni. Új technikák és eszközök szükségesek, amelyek minden törvényszerűségtől mentesek, csupán irányelveket és paradigmákat tartalmazhatnak.

Mi a teendő ezután? Mindenek előtt ismernünk kell a környezetet, amivel dolgozunk. A hangsúly ennek a változó környezetnek a folyamatos karbantartásán, monitorozásán van, és az ezekből valamilyen metrikahalmaz által meghatározott, tesztelés útján kinyert adatokon. Az agilis módszertanhoz hasonlóan, itt is nagyon fontos, minél hamarabb legyen visszacsatolásunk a rendszer állapotát illetően, jelen esetben biztonsági szemmel nézve: a tesztek elvégzése után az ezekből készített rengeteg riport segítségével feltárhatjuk a rendszer sérülékeny pontjait. A folyamatot az előadó által megadott sémában tudunk követni: discover, inventory, test, report. Jason Chan a Netflix által fejlesztett, nyílt forráskódú Security Monkey eszköz segítségével a fent említett sémában kínálja a megoldást rendszerünk biztonságának megőrzése érdekében. Zárszóként az egyik legfontosabb irányelv, amely a biztonsági kérdésekben igen komoly hibaforrás: Next, tomorrow, later versus now.

David Jacoby - IOT: HOGYAN TÖRTEM FEL A LAKÁSOM

David Jacoby Vezető biztonsági kutató, Skandináv Régió, Globális Kutató és Elemző Csoport David 2010-ben csatlakozott a Kaspersky Lab-hez mint a skandináv régió és a Benelux államok vezető biztonsági kutatója. https://hacktivity.com/hu/hacktivity-2014/eloadok/david-jacoby/

Egyértelműen hatásos és tanulságos prezentációnak lehettünk szem- és fültanúi a szombat reggeli nyitó előadáson, amelyen David elmesélte, hogyan hackelte meg a saját otthonát. David Jacoby azt a feladatot kapta, tesztelje saját otthonának biztonságát, mennyire szenzitív és sérülékeny az a hely, ahol él, egyszóval feltörte saját otthonát. Az eredmény megdöbbentő, ugyanis nem arra fektette a hangsúlyt, hogyan csinálta, sokkal inkább arra, hogy miért, és félelemre ad okot az a tény, hogy milyen könnyen. 3 hónapot töltött azzal hogy feltörje az otthonában található kütyüket. Ezalatt sikerült meghackelnie a NAS adattárolóját, hálózati routerét, nyomtatóját. Az okostévéjének a képernyőjére kirakott egy képet, Borat mosolyog rajta. Elmondása szerint azért volt könnyű dolga Davidnek, mert az elektronikai eszközei kivétel nélkül csatlakoztatva vannak az otthoni hálózatra. Mindannyiunkban felmerül a kérdés, hogy egy blu-ray lejátszónak mi szüksége van internet kapcsolatra, illetve az otthoni fájlszerverünk miért érhető el a világhálóról.

A mindenki által szajkózott “rohanó világ”, mára már dogmává vált mondása itt is megfigyelhető. Rohanunk előre, mindig egyre újabb és újabb termékek jönnek ki a piacra, amit tegnap vásároltam holnapra elavul, és a gyártók kontójára írható fel, hogy a régebbi termékekre (a tegnapira) már nem jön ki újabb és újabb biztonsági frissítés. A kereskedelemből ismert time-to-market kifejezésből a time egyenlő a “Holnapra” mondattal, ezáltal rengeteg hibás, biztonságilag szempontból tragikusnak mondható termék. Percről percre állítják le x típus gyártását, y gyártását kezdik el, z terméket nem fejlesztik tovább, stb. Az már mellékes, hogy a legtöbb esetben nem is értesülünk ezekről, külön vadászni kell a hálózaton, hogy jön-e még ki új frissítés kedvenc okos kütyünkre vagy sem. David meg is jegyezte: mikor felhívta egy pár biztonsági résre a figyelmet egy-két gyártónál, általában kétféle választ kapott: az egyik, hogy nálunk nincsenek biztonsági rések, nyilván az eszköz tökéletes, a másik, ez a megdöbbentőbb, az már régi, mármint a 6 hónapos termékre.

A 6 hónap az régi, mégis milyen időközönként vegyek tv-t?

Tehát a gyártók hozzáállása problémát okoz, nem csak szoftveresen lehet bejutni az eszközre hanem hardverhibákból származó biztonsági réseken keresztül is. Hemzseg a piac az olyan kütyüktől, amelyek gyárilag rosszul vannak, vagy leginkább sehogy sincsen beállítva. A legtöbb eszköz mindenféle felhasználónév jelszó pár nélkül elérhető, hozzáférhetőek az esetleg rajta beállított ügyfél adatok, példának okáért egy hálózati modem és/vagy router esetében. Minden eszköz, amely rendelkezik hálózati interfésszel, sebezhető. Az előadáson mutatott olyan böngészőből elérhető konfigurációs felületet, hogy a bal oldali menüben elérhető volt két elem, a harmadik nyitva volt a jobb oldalon, mint tartalom, és csak idők múlva esik le egyébként hogy eredetileg a menü három pontból áll. Nem éppen a legtámadhatóbb pontja a programnak, de tény, hogy defektes, és minősíti is a terméket, leginkább a gagyi kategóriába sorolható.

Ugyanolyan hibás a felhasználó is, a felhasználó sem fordít elég időt és energiát a saját otthoni biztonsági beálllításaira. Ez lehet idő hiánya, lustaság, nem megfelelő szaktudás hiánya, nem megfelelő segítségkérés hiánya. Az esetek megdöbbentően nagy százalékában az internetről elővarázsolt hálózati kütyü alapértelmezett felhasználónév jelszó párosa elegendő a bejutáshoz. Nyilván az a felhasználó, aki még arra is lusta, hogy a gyári alap jelszót megváltoztassa, nem fogja a további beállításokat sem elvégezni, az, aki a mai napig nem érti, mi szükség van a jelszó használatára, azzal nem lehet mit kezdeni.

További példa beállításokra, amelyet David is hangsúlyozott, az az eszköz amelynek feltétlenül nem kéne, hogy elérje az internetet, például egy fájlszerver vagy NAS szerver, amelyen a családi fotóalbumot tároljuk, lehetne egy másik hálózaton, egy másik szegmensen. Ez nyilván már komolyabb beállításokat, szakértelmet, komolyabb időbefektetést igényel, amelyre már nem minden felhasználónak van lehetősége, és nyilván nem is várható el a felhasználótól, és így akaratukon kívűl válhatnak sebezhetővé.

A megoldás A tudomány mai állása szerint nincs: egész egyszerűen nem lehet mondani egy egzakt megoldás a problémára, mert nem lehet az ellenőrzésünk alatt tartani saját kis kütyüjeinket. David szerint egy nagyobb kontrolra lesz szükség az otthoni hátózatunk felett, mely nagyon nagy valószínűséggel valamilyen magasabb szintű biztonsági szoftverben fog manifesztálódni. Egyelőre ismeretterjesztő anyagok terjesztésével, beállításokban való segítségnyújtással, és a felhasználók hozzáállásának változtatásával lehetne növelni a védelmet: A gyártók és szakemberek annyiban lehetnek a segítségünkre, hogy megfelelő használati útmutatóval, kellő mennyiségű információval látják el a készüléket. Felhasználóként meg igenis tessék odafigyelni legalább arra, hogy az alapértelmezett jelszót meg kell változtatni, továbbá ne legyünk lusták átolvasni, értelmezni, beállítani, és ha nem megy, akkor segítséget kérni, és el kell felejteni a “a drágább az biztos jobb is” elvet.

eXploitable Markup Language

Mivel rengeteg helyen találkozunk az XML-lel közvetve vagy közvetlenül, rengeteg technológia épül rá, alapjául szolgálhat kommunikációs protokolloknak, esetleg elrejtve titokban beágyazottan használjuk, (és még a végtelenségig sorolhatnám,) érdemes volt megnézni a róla szóló, nevében is kifejező előadást: eXploitable Markup Language. Az előadók szerint: Az XML feldolgozókat érintő támadási formák ősidők óta ismertek, ennek ellenére tapasztalatunk szerint még mindig nem kapnak elég figyelmet. Igaz, hogy az előadás elején viccesen leszögezték, hogy főleg nem webes XML támadásokról lesz szó, az első néhány demo mégis ebbe a kategóriában futott, hogy megismerhessük XML fájljainkban rejlő gyengeségeket. Egy gyakorlat-orientált előadás keretei között minden egyes rövid elméleti kérdés, egy-egy ötlet egy célzott, a való életből vett példán egy PoC programmal volt végvezetve és bemutatva. A webes példákon keresztül megismerhettük, hogyan kell belecsempészni XML állományokba úgy kódrészeket, hogy azok meg is hívódjanak. Ezt követően a való életből egy példát említenék: az egyik, ami nagyon elnyerte a tetszésem az az volt, hogyan lehet egy Visual Studio Project megnyitásával eljutni egy távoli asztal kapcsolathoz, és léphetünk be adminisztrátori jogosultságokkal. Elég összetettnek éreztem, rengeteg csillag-együttállásnak kell stimmelnie ugyan, de láthattunk példát arra, hogyan kell egy víruskeresővel ellátott mail szerverről, egy bizonyos víruskereső egy hibájából fakadóan, továbbjutni és átvenni az irányítást az azonos hálózaton lévő szerveren XML alapú attachment segítségével. A rengeteg demoval egy hasznos, szórakoztató előadást láthattam. Aki a bővebb technikai részletek iránt érdeklődne, hogyan kell felkészülni az ilyen és hasonló támadások ellen, annak az XXE témakörben való elmélyülést javaslom.

Kémelhárítás

A sajtóban is tárgyalt, nemzetbiztonsági körökben előszeretettel használt FinSpy Androidos kémprogram működése is terítékre került Marosi Attila előadásában.

Az előadó bemutatóként a nagyérdemű előtt telepítette a kémprogramot, majd bemutatott pár konfigurációs lépést, mely eseményekre figyeljen az alkalmazás, hogy a program a megfelelő pillanatokban aktivizálódhasson. Így például láthattuk, hogyan lehet kiolvasni a telefonkönyvet, illetve hogyan lehet a telefonra érkező hívást átírányítani, és lehallgatni a készüléket. A kémprogramot nemzetbiztonsági szervek is használják, ennek ellenére a program titkosítás szempontjából korántsem mondható erősnek: A kulcs egy mai átlagos számítógéppel alig másfél nap alatt visszafejthető, ennek megléte nem is feltétlen szükséges, és a konfigurációs fájl is csak az x-edik verzióban kapott kulcsos védelmet.

Megtudtuk, ha IMEI számunk van, mindenünk van: ha nem is mindenre, de sok mindenre elég, elég lehet. A sors ironiájának is felróható, hogy ez a számsor, még szerencse :), megtalálható a telefonunkon. A kémprogram a titkosított csatornán természetesen ezt az információt is továbbítja a szerver felé. A program egyébiránt tartalmaz kisebb-nagyobb késleltetéseket, hogy ne tűnjön fel a megnövekedett adatforgalom, erőforráshasználat.

Megtudtuk, hogy kémprogrammal fertőzött telefonunk SMS segítségével konfigurálható, és ha ez még nem lenne elég, ráadásként ehhez például nem szükséges a kulcs ismerete. Az üzenetek elnyelődnek, tehát a tulajdonos tudomást sem vesz arról, hogy a figyelem középpontjában áll.

Intermezzo

Feladatok, játékok, érdekességek - A rendezvény egyes helyszíneire, például a szervezőknek, VIP vendégeknek, sajtóképviselőknek stb, csak megfelelő színű karszalaggal, STAFF feliratú polóval, bármilyen hasonló igazolvánnyal lehetséges a belépés. Korábbi konferenciák alkalmával, lévén ez egy biztonság-technikai fesztivál, igen, ezekre a helyekre be kellett jutni, kellett csinálni bent egy fotót, vagy bármilyen módon bizonyítani kellett, hogy bent volt az illető, és ezért különböző értékes tárgynyeremények jártak. Mivel nem találtam semmilyen ráutaló jelet, a feladatról megfelelő reklámot, nem hallottam pletykát, nem kockáztattam. A kérdőív kitöltések mellett, amelyek az e-mail címünk megszerzéséért és későbbi hírlevelekért léteznek, vannak izgalmas játékok is, amelyeknek akár további állomásai is lehetnek. Én is tollat ragadtam és kitöltöttem egy játékot, ahol egy security log-ból kellett a kérdésekre a megfelelő választ kikeresni egy szuper baseball sapkáért(Y). A 24 órás versenyre azért nem neveztem, mert nekem biztos, hogy egy ici-picivel több időre lett volna szükségem. :)

Hasznos mondások

Hosszasan töprenghetünk azon, van-e merszünk felcsatlakoznunk a rendezvény WIFI hálózatára.

a promóciós névjegykártyákon szereplő QR kódot van-e bátorságunk okostelefonunkkal beolvastatni

a redundancia lényege, hogy több helyről lehet ellopni ugyanazt az adatot

Android

A második napon több előadás foglalkozott az okostelefonok, főleg az Android támadhatóságával.

Sokakat mozgat a kérdés, az okostelefonok világában mennyire érezhetjük magunkat biztonságban, mire kell, kellene odafigyelnünk, milyen új veszélyek leselkednek ránk, és mit tud tenni akár a biztonsági szakértő, akár a felhasználó, akár a fejlesztő. Régen is lehetett ilyet, csak kicsit nehezebben, tartja a szóbeszéd. Manapság se könnyű, de az eszközkészletet tekintve jóval szélesebb a paletta.

A probléma Milyen kérdések merülnek fel egy Androidos alkalmazás telepítése közben. Egy apk letöltése és telepítése során a telefonunk különböző jogosultságokat kér tőlünk, engedélyt kér az alkalmazás mihez férhet hozzá, és ha valamivel esetleg nem egyeznénk bele, akkor megszakítjuk a folyamatot. Joggal merül fel bennünk a kérdés, hogy egy zseblámpa programnak mi szüksége van internet-hozzáférésre, miért kérdezi meg identitásunkat, továbbmegyek, mégis mi kell neki a telefonkönyvből? GPS lokációra is sűrűn látunk feleslegesnek tűnő példát: biztos lekérdezik, hol használtam a zseblámpát, és legközelebb oda telepítenek közvilágítást. Továbbgondolva a problémát: valóban csak azt teszi az alkalmazás, amire engedélyt adtunk, vagy éppen most kerülünk be a következő adatbázisba?

A biztonsági szakemberek elemzőprogramok segítségével keresik a választ: milyen veszélyes, kártékony kódokat tartalmaznak az egyes alkalmazások funkciói, milyen adatokat továbbít rólunk a rendszer, és még sorolhatnám.

Napjaink nehézségei - Tegyük fel, hogy szeretnék egyes kódrészleteket tömöríteni és/vagy elrejteni. Ebben nyújtanak segítséget a packerek. A packer a definíciója szerint olyan csomagolóprogram, mely a szoftver egyes részeinek tartalmát tömöríti és/vagy elrejti. Kíváló megoldást kínál azon emberek számára, akik kártevő kódrészleteket, a 90-es évek “termékeként” ismert malware-eket rejtenek el saját alkalmazásukban, vagy mások által publikált, megbízható alkalmazásokban, amelyeket feltörtek, és továbbadtak.

Ebben az esetben a legismertebb elemző programunkat az apktoolt nyugodtan kidobhatjuk. A Separating from Packers előadáson a következő packereket tárgyalta az előadó: Pangxie􏰀, LIAPP,􏰀 Bangcle,􏰀 ApkProtect. Pár elméleti kérdés tisztázása után, a felsorolt packerek közül kettőt “éles környezetben” bemutatott, hogyan kell a packer segítségével becsomagolt alkalmazásokat visszafejteni. Az előadásban tárgyalt packer-ek - a Bangcle és az ApkProtect - a DEX fájlokban levő titkosított kódokat használják, melyeket az alkalmazás az osztott könyvtárakban található natív kódot felhasználva tölt le futásidőben, tehát pusztán a fejlesztés megkönnyítésére szánt emulátor memóriájában megkereste azt a memóriaterületet ahol az alkalmazásunk található, és onnan kiolvasta és visszafejtette a tikosított obfuszkált forráskódot. Ezek szerint a “Mire is jó valójában az Android Emulátor?” kérdésre a válasz attól függ, melyik konferencián ülünk éppen (developer tool vs hacking tool).

Másik nagy probléma az alkalmazás kommunikációja a külvilág felé, milyen adatokat szolgáltatunk, küldözgetünk szerte a világba a tudtunk nélkül. Megoldás lehet a telefonunk route-olása, vagy egy tűzfallal megtámogatott számítogépre való proxy-zás, de a blackbox féle tesztelést a vagtában való lövöldözéshez hasonlította a két penteszter, akik a következő előadást tartották a Android témában: Advanced tracing and monitoring. A megoldás lényege: A VM-be bytekódszinten a függvények belépési és kilépési pontjain a paramétereket kiolvassák, és az Android log API-jának segítségével kiírják az eredményeket. A Python-t azért szereti mindenki, mert tömör, gyorsan lehet benne algoritmusokat, megvalósításokat kipróbálni, és mindez meg van fejelve azzal, hogy már meg van benne írva minden. Itt is láthatuk a hatékonyságát, pár apró kis script segítségével összeraktak előttünk egy debugger, elnevezésükben deLogger nevű programot, mely név hűen tükrözi, mit csinál valójában a program. Nem több mint öt-hat kattintás meg egy-két input mező kitöltésével igen hamar létre lehet hozni megabájtos fájlokat, így hát célszerű a számunkra releváns kódrészletek feltárására koncentrálnunk, ha elemzünk egy Androidos alkalmazást.

A lehetőségek tárháza dinamikus idejű megoldásokra is kiterjed. Stílusos címválasztással, a Beoltjuk az Androidot című előadáson bemutattak egy Vaccine névre hallgató programot, amely futási idejű elemzést, beavatkozást, manipulációt tesz lehetővé: egy kis kódot beszúrunk az APK-ba, majd kapcsolódunk hozzá és a Java Reflection felhasználásával futási környezetben módosítjuk az értéket, a hívási metódusokat, a nem biztonságos osztályokat és a feladatok automatizálására saját szkripteket hozunk létre. Csodálatos volt látni, hogy az apk kódjának megváltoztatása nélkül hogyan lehet kisebb-nagyobb változtatásokat eszközölni akár egy egyszerű kis táblás játékon.

Summary

Azon túl, hogy rengeteg érdekes, meghökkentő, olykor vicces demo segítségével temérdek hogyan kérdésre kaptunk választ, a fő mondanivaló igenis az, hogy nem törődünk eleget az otthonunkat érintő biztonsági kérdésekkel, gyártói oldalról még ráadásul akadályoztatva vagyunk. Létezik megoldás, ez pedig az idő. Kellő ráfordítással igenis lehet tenni a rosszindulatú behatolások ellen, nem szabad sajnálni az energiát, ugyanis a ráfordított idő nem mutat a végtelenbe, és még most neki kell állni a feladatnak, mikor még nem késő.

gabor

HOUG Szakmai nap

September 18, 2014,

Ha innen nézem: a Java még mindig az egyik leghasználtabb programozási nyelv, főleg bizonyos piaci szegmensekben. Ha a másik oldalról nézem: annak ellenére, hogy Magyarországon valószínű jelentős Java programozó populáció lakik, a szakmai események száma továbbra is sajnálatos módon kicsi.

Ezért is szerencsés, hogy újra lesz HOUG szakmai nap Október 2-án, benne hangsúlyos Java képviselettel. A program (és az előzetes regisztráció) elérhető a HOUG oldalról.

Ami már biztos hogy lesz, az JavaEE/SE/Spring, de lehet még előadásra is jelentkezni 25 perc és villámelőadás (kb. 6 perc) terjedelemben. (Szerintem nincs annál menőbb előadó, mint aki 6 percben tud emlékezeteset alkotni.) Előadással jelentkezni lehet pl. a geza pont simon kukac houg pont hu email címen.

OSGi és classloderek

May 29, 2014,

Ha alapokról kellene elkezdeni az OSGi működését – mondjuk egy tanfolyam keretében – akkor biztos, hogy még mielőtt bármit elmondanánk, a classloaderek működését kéne megértetni. Igazából meglehetősen egyszerűek a szabályok, de jó tudatosítani őket. Ha nem ismerjük a szabályokat, az OSGi konténerünk változatos ClassNotFound exception-ök dzsungelévé tud válni. De ha tudjuk mi hogy működik, elég egyszerű rátalálni az ösvényre.

Kérdés: Milyen classloader fogja betölteni az osztályunkat, ha eddig még nem volt betöltve, de a kódunkban valahol szerepel a new MyClass() kifejezés.

Válasz: Az a classloader, aki azt a kódot töltötte be, ahol példányosítani próbálunk.

1. Példa

Tegyük fel, hogy van 2 bundle-unk a konténerben (legyen mondjuk a nevük service és client).

A service tartalma:

A client tartalma:

Ebben eddig semmi meglepő nincs. Tudjuk, hogy az OSGi bundle egy sima jar file, ami attól érzi magasabb rendűnek magát, hogy a MANIFEST-ben okos mondásokat tartalmaz. A service például megengedi, hogy a hu.dpc.demo.osgi.util csomag alatt található osztályokat bárki lássa, aki szeretné.. Az igényt az Import-Package mondással jelenti be a client bundle.

Két class loaderünk lesz tehát, mindegyik bundle-nak egy. Ha a clientben valami nem található, a service classloadere is az exportált packagekből adhat osztályokat. Ha a BundleActivator-ban (ami esetünkben kb. olyan mint a main) meghívjuk a new FactoryUtil() konstruktor, akkor mivel a saját classloader nem tölti be, az import nyomán megtalált service classloader ad nekünk egy FactoryUtilt. A new Account()-ot viszont egyértelműen a service classloadere hozza létre, hiszen a FactoryUtil-t – akiben ez a a példányosítás szerepelt – is ő hozta létre.

2. példa

Miért fontos ez? Próbáljunk elképzelni egy olyan felállást, amikor a service szeretne plugint betölteni futás közben. Például:

A service tartalma:

A client tartalma:

Mi fog történni? A FactoryUtil-t a service bundle töltötte be. A client bundle látja az exportált dolgokat a service-ből, de a service semmit se tud a clientről. Tehát a plugin leírót se fogja megtalálni és null-al fog visszatérni a getPluginRegistration("myPlugin") hívás.

Természetesen még rengeteg lehetőségünk van. Egyrészt vannak további OSGi trükkök Dynamic import, Fragment Bundle, másrészt level3-on már belép az, amikor kézzel állítgatjuk különböző framework-ök classloadereit. (Általában a jól megtervezett frameworkök azt vagy engedik vagy kifejezetten igénylik…). De ezek részletes kifejtése sajnos nem fér ide a margóra. Frameworkök tervezéséhez viszont ezt a remek bejegyzést ajánljuk.

OSGi névsorolvasás

May 14, 2014,

A hőskorban létezett egy magyar nyelvű wikioldal jhacks néven, amit még Kocka szerkesztett. Itt szintem minden Java-val kapcsolatos technológiáról volt egy két bekezdés, ami elmondta, hogy mi az. A wiki azóta már eltűnt az idők homályában, egy nem frissülő snapshot változata nem rég óta olvasható egy github-os archívumban.

Most amikor OSGi alapú technológiákról és termékekről akarok majd több posztot is írni ez a wiki jutott eszembe. Jól jönne ugyanis némi rövid magyarázat, hogy az elkövetkezők során jobban érthető legyen, melyik komponens micsoda és mi a szerepe.

Ez a poszt tehát egy rövid felsorolás lesz, seregszemléje, néhány OSGi-os toolnak.

OSGi: Az OSGi a hiányzó modularizáció a JDK-hoz. Tud classpath szeparációt, dinamikus újraindítást, servicek és függőségek kezelését. Távolról nézve (leegyszerűsítve) sok jar file futtatása egy egyszerű konténerben ahol nagyon jól szabályozva van, hogy hogy láthatják egymást és egymás service-eit a jar-ok. A jar-okban van a META-INF/MANIFEST.MF-ben minden féle OSGi specifikus metaadat. Emiatt nem földhözragadt jar fileoknak fogjuk hívni őket, hanem magasztos OSGi bundleoknak. Pedig csak jarok.

Apache Felix: OSGi-hoz tehát kell egy konténer, ami intézi a szabványos életciklust, láthatóságot, stb. Ezek közül két népszerű darab az Apache Felix és az Eclipse Equinox. Igazából előbb utóbb úgy is kiderül, hogy nem a konténer a lényeg, hanem, hogy milyen alap funkcionalitás van még benne.

Apache Karaf: Ha az extrák számítanak, akkor működik az is, hogy fogjuk a Felixet, mellérakunk extrákat, és úgy terjesztjük. Ez a Karaf. Nagyon nem ritka dolgok amit nyújt: ügyesen kitalált deploy, config management, logging, deployment stb. Sok dolgot ráadásul külön fejlesztenek (pl. pax-os projektek), csak itt szépen összerakva lehet elindítani. Egész szerethető jól működő dolog.

Apache ServiceMix: A szépemlékű Java Business Integrationt (JSR 208) is implementáló ESB megoldás. Van benne egy JBI kompatibilis Normalized Message Bus, és sok adapter. A jelentősége mára már igen lecsökkent. Egyrészt az Apache Camel-ben már sokkal több adapter van, másrészt a JBI specifikáció meg úgy tűnik nem váltotta meg a világot és lassan eltűnik. A ServiceMix attól még itt van velünk együtt. Főleg azért mert egy pillanatban ugrott egy nagyot és a ServiceMix nevű doboz átváltozott egy Karaf + néhány okos dolog (CXF, activeMQ, stb.) terjesztésévé egy Karaf konténerben. Innentől már szinte mindegy is, hogy az eredeti service bus-ból mennyi maradt benne fontos, ha egy jól összerakott Karaf alapú alkalmazás platformot ad.

Apache Camel: Az un. Enterprise Integration Patterneket megvalósító integration megoldás. Kb. úgy kell elképzelni, hogy van benne egyrészt rengeteg adapter, másrészt jó néhány api, amivel a sok adapter közötti üzenet áramlást lehet szabályozni (üzenetek transzformációja, szétszedése, összeszedése, elágazást, stb.). Szép fluid API-val működik, de van jó Springes és blueprint támogatása is.

Jboss Fuse: Ha már ennyit érnek az extrák, lehet még fokozni: fogjunk egy Karaf-ot (Felix + extrák) rakjunk mellé még Camel-t meg ServiceMix-et meg mondjuk egy Zookeper alapú clusteres config managementet és dobozoljuk be. Ez a Fuse, amit a a JBoss kb. 2 éve megvett magának. Az új opensource változat fabric8.io néven fut. A levelező listája alapján tetszhalott, de csak azért mert minden fejlesztő IRC-n lóg és ott beszélgetnek. A fabric a fuse legnagyobb hozzáadott értéke, a clusteres varázslat zookeper alapokon, pont jó lett elnevezni az open source változatot.

Camunda: Kicsit kilóg a sorból, mert ő egy beágyazható BPMN workflow motor. Be táplálunk egy BPMN grafikont és szépen megcsinálja a lépéseket sorrendben. Kb. 1 éve forkolta a Camunda nevű konzultáns cég az Activityből (akiknek meg az azóta is létező jBpmn a nagypapájuk). OSGi-t hivatalosan nem támogat, de nem hivatalosan persze remekül megy. Mivel a workflow motor csak a magas szintű processért felel, pont jól kiegészíti mondjuk egy camel, aki az adaptereket és transzformációkat alapból tudja nyújtani.

A fő szereplők ők. De ahogy írtam még új és új mellékszereplők jutottak eszembe, ők viszont majd csak későbbi epizódban fognak előbukkanni. Maradjanak velünk.

HOUG konferencia, Java szekció

March 24, 2014,

Nem is tudom mikor volt utoljára Java konferencia Magyarországon. Talán a régi Sun-os időkben és ott se a legvégén. Már csak ezért is nagy szó szerintem, hogy az idei HOUG konferencián a Java szekció egy külön fél napot kapott. Az érdeklődők száma (az elején még plusz székeket is be kellett hozni) és az előadások színvonala is azt mutatta, hogy egy ilyen alkalom akár nagyobb időkeretet is (most csak kb. 25 perc volt egy előadásra) megérdemelne.

Összességében abszolút megérte részt venni a rendezvényen. Remélem hogy jövőre vagy egy másik alkalommal már teljes nap hallgathatunk teljes előadásokat Java témakörben, mert sokszor 25 perc után épp akkor ért véget egy előadás amikor kezdett érdekes lenni.

Disclaimer: e sorok írója szintén előadott, a fenti sorok (ahogy mindig) magánvéleményét tükrözik.

Javabar videó: Garbage First Garbage Collector Algorithm

January 30, 2014,

Örömmel jelentjük, hogy megjelent az első videó a Javabar új videó csatornáján.

Az emlékezetes előadáson Varga Péter beszélt az új G1 (Garbage first) szemétgyűjtő algoritmusról, és természetesen a kontextusról is, hogy hogyan is működik Javaban a szemét gyűjtés.

Az előadás itt megnézhető online.

Amíg további előadások is felkerülnek ajánljuk a Javabar következő alkalmát, ahol azokról a JDK-ben elérhető eszközökről lesz szó, amiket elég ritkán használnak, pedig minden Java telepítéssel megkapjuk őket és nagyon hasznosak tudnak lenni.

Az előadás február 11-én lesz. Jelentkezés itt.

Devoxx 2013 szumma

November 24, 2013,

Már több mint egy hete vége van a Devoxxnak, de mindenképpen akartunk még írni, egy összefoglalást, hogy lezárjuk az előadásokról szóló folyamat és folytathassuk valami mással.

Összességében mindenkinek ajánljuk a konferenciát, akit a Java érdekel. (Akit viszont csak Android, vagy csak Javascript, az talán jobb helyet is talál) Ez egy össz-Java konferencia volt, viszonylag erős JavaEE jelenléttel. JVM feletti egyéb nyelvek (Clojure, Scala, Kotlin, Ceylon…) nagyjából egy-egy előadás erejéig merültek fel. Egy év múlva ingyenesen elérhető lesz minden előadás a Parleys.com-on, illetve néhány hét múlva ugyanott fizetősen. Aki nem tudott kijutni, az oda olcsóbban befizethet, kérhet három nap dedikált munkaidőt és végignézheti az előadásokat. A személyes beszélgetésekről, BOF-ról, kiállításról ugyan lemarad, de mondjuk a sorban állásokról is. A tartalom elérhető, csak rá kell szánni az időt.

PS: Akit még a tartalom érdekel jó szívvel ajánljuk Tvik remek összefoglalóját.

Koen Aers: Introducing Forge 2

November 16, 2013,

A Devoxxon az ebédszünetek egy óráig tartottak, de még ez alatt az idő alatt is mentek az előadások. Ezek voltak az úgynevezett Quicke-k: rövid, negyedórás előadások, épp csak felvillantottak egy témát. Ezekre a helyekre amúgy lehetett pályázni (volt Call For Papers) és talán ezért egy kicsit vegyesebb is volt a felhozatal.

A Forge 2-ről szóló pont egy említésre méltó volt, tömör, tisztességesen összeszedett demó. A Forge a jboss scaffolding toolja, azaz arra hivatott, hogy létrehozzon tipikus minta projektet választható összetevőkkel és komponensekkel. Működik command line is és az Eclipse-es jbosstools részeként is, de ez utóbbi se sokkal több mint egy ablakban futó command line eszköznél.

Illetve eddig nem volt több. A 2-es verzióban viszont már gui-s támogatás is van. A scaffolding tool tetszőleges pluginjei most már ha megfelelő apit használnak úgy tudják definiálni az elérhető paramétereiket, hogy abból szép IDE varázsló is megjeleníthető, és természetesen a command line-os programban pedig működik az automatikus parancskiegészítés. Erről szólt a negyed óra.

Más kérdés, hogy szükségünk van-e egyáltalán scaffolding toolokra, vagy minden projekt olyan egyedi lesz idővel, hogy úgy se érdemes sablonokat használni.

Erre a kérdésre sok válasz létezik, de az idő – ahogy arra tanult kollegám rámutatott – a scaffolding tooloknak kedvez. Egyre újabb és újabb keretrendszerek jönnek, és minél több fa az erdőben, annál jobban jön egy térkép. A Yeoman, például, aminek egy része a scaffolding, Javascriptes világban egész szép népszerűséget kezd elérni, tehát az igény úgy látszik megvan.

De persze vannak más utak is. Az angularjs egy minta projektet tart karban angular-seed néven, ott elég azt leklónozni és már is megvan az alap projektünk. A maven pedig ugye az archetype plugint adja, ami minta projektet tud generálni, de klasszikus scaffoldingot (pl. entitásokhoz további komponenseket, pl. REST végpontot generálni, stb.) nem tud. De még így is sokkal több ez, mint amit a Gradle ad, ahol teljesen hiányzik ez a funkcionalitás.

Most viszont kezdek arra hajlani, hogy ha már szükség van ilyen eszközre, akkor az legyen build tooltól független, de jól összerakott eszköz. (Ehm, mivel jelenleg a Gradle az, amire szavazok, muszáj ezt képviselnem). És ha már külső eszköz, a Forge (főleg a jövőbeni 2-es verziója) meglehetősen pofásnak tűnt.

A jelenlegi változatnak (1.4) amit letöltöttem még voltak sorjás részek. Például mennyire jó lenne, ha a kontextust nem kéne a Forge console-ból beállítanom, hanem az aktuálisan megnyitott Java osztály lenne az. Pl. megnyitok egy Java osztályt, megmondom, hogy loggert ide, és meg is kapnám. A loggert IDE templatekkel ugyan meg lehetne oldani, de ez egyrészt tudna IDE független lenni, másrészt komplexebb műveleteket is el tud végezni (létrehoz egy osztályt és be is regisztrálja egy XML leíróban).

A 2-es verzió viszont elég ígéretes.

Jean-francois Denise: Avatar.js

November 15, 2013,

Az Avatar.JS nyílttá tételét ha jól emlékszem az idei Java One-on jelentették be.

Amíg a Vert.x a Node.JS-ből tanult dolgok alapján csinált egy hasonló szellemiségű, de okosan kitalált Java-s eszközt, az Avatar.js nem más mint egy Node.JS futtató környezet Java-ban a Java8-ban megjelenő új javascipt motorra a Nashornra építve. A cél a 100% kompatibilitás. Jelenleg a v0.10.08 a cél, és a (Node.JS) unit tesztek 80%-a már lefut (némelyik kis módosítással). Persze ez a szigorú megfelelni akarás áldozatokat követel. Például a Java NIO (a Vert.x-ben az ezt használó netty van) helyett a libuv-t (amint a Node.JS is használ) rakják bele JNI (!!)-n keresztül, azaz nem tisztán Java, hanem van natív része is. A sebessége pedig sokkal lassabb (nincs pontos mérés, de nagyságrendileg 2x-3x) mint a natív Node.JS.

Miért használná akkor bárki? Az ajánlat szerint azért, mert itt meg lehet hívni a Java világ összes library-jét. Az old-school szinkron dolgoknak, amiket nem akarunk meghívni a villám gyors kéréseket feldolgozó száltól szeparált külön Executor van. A demó alkalmazásban pl. Java libraryk végezték a képfeldolgozást egy külön szálon, és ha kész volt, akkor visszahívott az avatar.js feldolgozó száljába, ami a javascript feldolgozást végezte. Ez az integráció kiforrottabbnak tűnt, mint a Vert.x-é, bár az is lehet, hogy erről pont nem volt slide a másik prezentációba. Emellett még a Java Security Model-el próbálják a Node.JS felhasználókat csábítani, itt szépen mindenhol végigvezették, és a Java Security beállításokkal le lehet korlátozni a futtatott javascript lehetőségeit.

Mindezek mellett dolgoznak még egy AvatarEE megoldáson (ahol az egészet belerakják Java EE környezetbe/app szerverbe), valamint az npm-nek (gyk. nodejs csomagkezelő) megfelelő apm-en. Ez utóbbi még nem nyílt forráskódú. A kérdések között valaki megkérdezte, hogy mikor lesz. Az előadó azt válaszolta, hogy fogalma sincs (!!!).

Van tehát az egyik oldalon egy ügyes aszinkronitásra épülő, multi-language (Java, JS, JRuby, JPython,…) keretrendszer, clusterezhetőséggel (by Hazelcast), ügyes event bus implementációval, jó command line támogatással. Ez a Vert.x. Ezzel szemben áll az Avatar.js ami majd egyszer teljesen Node.JS kompatibilis lesz, majd egyszer talán majd gyors is, tartalmaz natív részt, de lehet benne Java Security mondásokat mondani.

Ez eddig szerintem egyértelműen a Vert.x felé mutat, de ne legyünk igazságtalanok: az Avatar.JS még csak most indult. Talán csak némi idő kell a lemaradás behozására, és talán majd akkor a választ is meg kapjuk arra, hogy melyik része mikor lesz szabadon elérhető…

Scott Kurz: Batch Application for the Java Platform (JSR-352)

November 15, 2013,

A Java EE7 része már a JSR-352 batch processzing specifikáció is. Akik láttak már Spring Batch-et, azok valószínűleg tudják hová tenni. A többieknek: valami olyasmiről van szó, hogy van task olvasó, eredmény kiíró interface, és persze a futtató is. Be tudja olvasni a feladatokat, lefuttatni, akár párhuzamosan (de nem clusterbe), és szépen végig vannak gondolva a konfigurációk, hogy hány feldolgozás legyen egy tranzakció, mi legyen hiba esetén újrakezdhető, stb. Mindezt szép békebeli XML configurációval vezérelve.

Arról meggyőzött az előadás, hogy ez egy átgondolt API, de azért korántsem fogott el az az érzés, hogy most fel kell állnom, odamenni a pénztárhoz és bevásárolni minél több batch processing implementációt.

Annak, hogy valami JSR, szabványosított implementáció, több előnye is lehet. Egyrészt, mint például a JPA-nal, örülhetünk annak, hogy ha egy alkalmazásunk hordozható az implementációk között. Vagy az is lehet pozitívum, hogy mostantól egy batch processzing elérhető Java EE7 keretein belül is.

Én egyiket se éreztem olyan erős érvnek. Biztos csak a tapasztalatlanságom miatt, de valahogy az volt az érzésem, hogy azt, amit az API keretein belül meg tudnék csinálni, azt API nélkül is le tudnám kódolni 1-2 hét alatt, és akkor az pont úgy fog működni, ahogy én szeretném, és nem kell feltételes elágazásokat kódolni XML-ben.

Untitled

De azt is elfogadom, hogy ez csak az első lépés. Nyilván majd még fejlődik a JavaEE-vel tovább, és akkor a jövőben talán olyat se kell olvasni, hogy:

Java-based JSL (Job Specification Language) annotations rejected by original Expert Group