2015. december 3., csütörtök

SonarQube - LDAP csoport szinkronizáló plugin

A SonarQube lehetőséget ad arra, hogy az LDAP plugin segítségével az authentikációs és az authorizációs információkat LDAP-ból vagy Active Directory-ból kérjük le. Ez a gyári plugin a felhasználók minden belépésekor aktualizálja a csoportokat, azonban a működésének az előfeltétele, hogy a csoportok a SonarQube saját adatbázisában már benne legyenek. Alapesetben kézzel kellene felvenni akár több száz LDAP csoportot, így inkább fejlesztettem hozzá egy kiegészítőt.

SonarQube-LDAPGroup-Synchronizer plugin egy JRuby On Rails alapú widget, ami a SonarQube felületén a Settings / Configuration / LDAP Group Synchronizer menüpont alatt érhető el az adminisztrátor szerepben lévő felhasználók számára.


A plugin, a sonar.properties-ben megadott LDAP beállításokat használja és a felületen megjelenő gombbal indíthatjuk el az aktualizálást. Tervezem a kiegészítőm továbbfejlesztését azzal, hogy a SonarQube szerver indulásakor is automatikusan végrehajtson egy szinkronizálást a ServerStartHandler kiterjesztési pont segítségével.


Az elkészített plugin forráskódját feltöltöttem a github-ra. Ha továbbfejlesztési ötleted lenne hozzá, welcome...

2015. november 19., csütörtök

Jenkins - Pipeline Version Updater plugin

Nemrég blogoltam a Jenkins Delivery Pipeline használatának előnyeiről és arról, hogy a pipeline verziószáma kiemelt szereppel bír, mivel végig kíséri az összes lépést és benne lesz a létrejött telepítési egységek nevében is. A verziószám generálását többféleképpen el lehet végezni, most csak egy lehetséges megoldást szeretnék bemutatni, ami éppen illeszkedett ahhoz környezethez ahol a kialakított CI rendszert használták.

Az ötletem, aminek a megvalósításához fejlesztettem egy Jenkins plugin-t az volt, hogy a pipeline verziószáma két részből álljon, az első rész a legfrissebb SCM TAG értéke legyen (pl.: v2.0.0) a második rész pedig egy 1-ről induló, buildenként növekvő szám, ami egy új TAG érkezésekor mindig 1 értékre inicializálódik. Azért, hogy az SCM tag értékénél a verziószám pattern-t kötelező legyen betartani, szerver oldali GIT HOOK-ot alkalmaztam, hasonlóan ahhoz mint amit ebben a cikkben írtam.

Az elkészült plugin forráskódját megnyitottam és feltöltöttem a github-ra. A használatához csak be kell pipálni a Pipeline Version Updater checkbox-ot a Build Environments szekció alatt, ahogy az alábbi kép is mutatja.


Most pedig nézzük meg gyakorlatban is a plugin verziózásának működését, az alábbi pipeline részlet alapján. A legfrissebb scm tag a v2.0.0 volt így az első build indításakor a v2.0.0.1 lett a pipeline verziószám. A következő build indításakor sem érkezett újabb scm tag, ezért a pipeline verziószám v2.0.0.2 értéket vette fel.


Ezután a vezető fejlesztő meg-tag-geli a forráskódot a v2.0.1 verziószámmal, ahogy az alábbi kép is mutatja.


A következő buildnél a v2.0.1.1 értéket veszi fel a verziószám, a legfrissebb scm tag és az 1-ről induló build number alapján.


Ez lenne az általam kialakított pipeline verziószámozós rendszer. Ha kérdésed lenne ezzel kapcsolatban, esetleg Ti más utat választottatok a verziózáshoz szívesen veszem az ötleteket.

Stay tuned...!

2015. november 3., kedd

Robot teknősök - Személyes tapasztalatok

A robot teknősök társasjátékról már írtam korábban a játékos programozás gyerekeknek sorozatban, azonban most szeretném a saját tapasztalataimat is megosztani a játékkal kapcsolatosan. A kisfiam 4 éves születésnapjára kapta tőlem ezt a társasjátékot és azonnal láttam hogy tetszeni fog neki, sok szép színes kártya amiket lehet rakosgatni... 

Megbeszéltük a szabályokat és elkezdtünk vele játszani. A szabályok szerint ő pakolta le a kártyákat, én pedig a lerakott kártyák alapján irányítottam a teknőst, valamint néha szerepet is cseréltünk. Egy nekifutásra 2 játékot tudtunk játszani (kb. 15 perc, utána mással játszottunk mert megunta) de nagy meglepetésemre, így is nagyjából 5 nap alatt végig mentünk az összes pályán (1. kőfal, 2. jégfal+lézer, 3. tolható láda, 4. funkció béka). Nagyon érdekes volt, hogy a függvény hívást - a funkció béka kártya lerakásával egy általunk előre megadott kártyasor lépései hajthatók végre - azonnal megértette és tudta is használni. Persze ennek nagyon örültem, azonban ezzel kijátszottuk a játékot és nincsenek újabb kártya típusok amiket pedig még várt volna...

Megfigyeltem, hogy nem menet közben gondolja ki, hogy melyik lesz a következő kártya amit le fog tenni, hanem miután felépítettem az akadálypályát, még a játék kezdete előtt a kezével végigmutatja, hogy merre fogja majd irányítani a teknőst, azaz előre megtervezi annak az útvonalát (a programsort), aztán csak gyorsan ledobálja a kártyákat én meg tologatom a teknőst és kiadom a kötelező berregő hangokat.

Ez egy ajánlott vétel! .)

2015. november 2., hétfő

dynaTrace - JDBC batch insert

A teljesítménybeli problémák egy része konfigurációs (jvm, pool) hiányosságokra vezethető vissza, azonban a legtöbb esetben mégis maga az alkalmazás kódja vagy az egyes API-k ill. keretrendszerek nem megfelelő használata okozza a legsúlyosabb veszteségeket. Már az egyetemen is mondogatták, hogy nagy mennyiségű adat beszúrását kötegelve végezzük el, mert a DML műveletek (insert, update, delete) egyenként történő végrehajtása, külön-külön adatbázis feldolgozást és magasabb hálózati overhead-et is jelent.

Az alábbi program 20.000 JDBC insert műveletet fog lefuttatni egyenkénti (tehát nem kötegelt) végrehajtással.


Ahogy a dynaTrace PurePath dashleten is láthatjuk, a válaszidő 13.4 másodperc volt, 97%-ban Input-Output művelettel a lekérdezések végrehajtásánál.


Módosítsuk a programot és nézzük meg, hogy mennyi javulást érünk el, ha az insert műveleteket kötegelve hajtjuk végre.


Az alábbi képen látható eredmény magáért beszél, sikerült a válaszidőt 1.8 másodpercre lecsökkenteni minimális forráskód módosítással. 


Érdemes arra odafigyelni, hogy a nagyméretű kötegek esetén időnként (minden x insert után) futtassunk le egy JDBC batch insertet, különben OutOfMemorError keletkezhet amennyiben a heap memória megtelik!

2015. október 19., hétfő

dynaTrace Certified Associate

Ma délelőtt sikeresen leraktam a Dynatrace Application Monitoring 6.2 Associate Certification vizsgát az Examity vizsgarendszeren keresztül. Hasonlóan más gyártókhoz, a dynaTrace is 3 szintet határozott meg a tanúsítványoknál: Associate, Professional, Master. Szóval itt is maradtak az APM rövidítésnél... :)


A vizsgán 73 kérdésre kellett válaszolni 73 perc alatt, amiből a végén csak 45 másodpercem maradt, szóval igyekeznem kellett. A nehézségi szintet elég jól belőtték, voltak benne lexikális tudásra építő, a dynaTrace belső működésének ismeretét feltételező és "hogyan oldanád meg" típusú kérdések is. Így utólag azt mondanám, hogy aki részt vett már egy Telvice-es core dynaTrace tréningen és legalább fél éve aktívan használja a dynaTrace-t, annak már érdemes megpróbálkozni vele. A vizsga ára 200 USD. Ha esetleg több infó is érdekelne a vizsgával kapcsolatban, ne kíméljetek...

2015. október 12., hétfő

Jenkins - Delivery Pipeline, Build Pipeline

Pár éve már írtam a Jenkins-ről és a folyamatos integráció (CI = Continuous integration) lényegéről, most pedig a KEKKH-s CI bevezetési projektem kapcsán ennek a "tovább fejlesztéséről" szeretnék pár gondolatot megosztani. 

Kisebb projekteknél talán még elfogadható lehet, ha minden részfeladatot egy Jenkins job-ba sűrítünk, azonban hamar a következő igények merülhetnek fel:

  • Vizuálisan is szeretnénk lekövetni, hogy éppen melyik lépés futtatásánál tart a folyamat
  • Sebesség optimalizálás céljából, szeretnénk beazonosítani a lassú lépéseket
  • Vannak olyan lépések amelyeket párhuzamosan is lehetne futtatni
  • Párhuzamos lépések esetén csak akkor akarunk tovább haladni ha minden párhuzamosan indított lépés sikeres volt (join)
  • Egy adott lépéstől kezdve szeretnénk indítani a pipeline-t. (pl. a terheléses teszteléstől)

Ezen igények megvalósítására két Jenkins plugint is bevethetünk: Build Pipeline és a Delivery Pipeline. Én az utóbbit választottam, mert a build pipeline a párhuzamosan join-olt jobokat nem jeleníti meg jól.

Az alábbi képernyőképen az NLR alkalmazáshoz kialakított CI Pipeline látható. A dobozkák magukért beszélnek, így csak röviden írnám le mi is történik az egyes lépéseknél. A Build lépés során a forráskód lefordul és létrejönnek a telepíthető modulok, alkalmazások. A Unit Test lépésnél kiderül, hogy vajon funkcionálisan is minden jól működik. A Static Code Analysis lépésnél elindul egy SonarQube alapú kódellenőrzés, amivel párhuzamosan Cobertura alapú kódlefedettség (Code Coverage) és JBoss Tattletale alapú könyvtár függőség elemzés (JAR Analysis) is történik. Amikor ezen lépések mindegyike sikeresen befejeződött a modulokat ki kell tenni (Deploy) az alkalmazás szervere, majd egy gyors Smoke tesztet futtatni a telepítés sikerességének ellenőrzéséhez. Ezután következhet a dynaTrace-szel integrált JMeter alapú teljesítmény tesztek futtatása (Performance Test), majd a dynaTrace-szel integrált Selenium alapú UI tesztek (Browser Test) futtatása. Amennyiben minden lépés sikeres volt, akkor az utolsó, Store Artifact lépésnél a telepített modulok bekerülnek a Nexus repositoryba.


A pipeline verziószáma - esetünkben a v1.0.0.3 - végig kíséri az összes lépést, benne lesz a buildelt telepítési modulok nevében, a SonarQube analizálásnál, a performancia és böngésző tesztek során létrejött dynaTrace-es session-ök nevében és  persze a Nexus repositoryban eltárolt moduloknál is.

Ha valamelyik lépés hibára futna (pl. volt 1 hibás unit tesztünk), akkor az adott doboz piros színnel jelenik meg és a következő lépések már nem futnak le, hibásnak jelölve ezzel a teljes pipeline-t. A hiba fogalmát a SonarQube és a dynaTrace-es Jenkins build breaker funkcionalitással mi magunk határozhatjuk meg. Ha például volt legalább 1 blocker prioritású SonarQube hiba, vagy ha volt olyan JDBC lekérdezés a perf. teszt során ami 8 másodpercnél tovább futott, hibásnak jelölve az adott lépést, megállíthatjuk a pipeline lépéseinek további futását.

Szóval, jó dolgokat lehet ezekkel a pluginokkal csinálni, használjátok és ha van kérdésetek, ne tartsátok magatokban...

2015. október 9., péntek

GIT Update Hook - Commit Message Restriction

A GIT Hook-ok lehetőséget adnak arra, hogy egy saját szkriptet futtassunk le, bizonyos GIT-es események bekövetkezésekor. A GIT művelet típusától függően választhatunk a kliens oldali ill. szerver oldali hook-ok közül.

Amit el szerettem volna elérni az az volt, hogy csak abban az esetben lehessen feltölteni a módosításokat a GIT szerverre, hogyha a kommit üzenetek megfelelnek egy általunk definiált formátumnak, esetünkben a "RED-123 kommit-üzenet" mintának, ahol is a RED-123 annak a redmine issue-nak az azonosítója amin a fejlesztő éppen dolgozik.

Itt megjegyezném, hogy az Eclipse-hez léteznek mylyn issue tracking connector-ok (JIRA, Mantis, Bugzilla, Trac) amelyek lehetővé teszik, hogy a fejlesztő magához vegyen egy taszkot és a kommittoláskor az issue azonosítójával automatikusan kitöltik a kommit üzenetet, így azt már nem kell kézzel beírogatni. Ezen konnektorok használata mindenféleképpen javasolt, amennyiben létezik ilyen plugin az általunk használt fejlesztő eszközhöz ill. ticketing rendszerhez.


A GIT (esetemben RhodeCode) szerveren, a repository hooks könyvtárában létrehoztam egy update futtatható fájlt az alábbi tartalommal, ami meghívódik minden egyes git push művelet esetén és csak a megfelelő kommit üzenet formátum esetén engedélyezi a kód feltöltését.
#!/bin/sh

refname="$1"
oldrev="$2"
newrev="$3"

for rev in `git rev-list $oldrev..$newrev`
do
    comment=`git log --format=%B -n 1 $rev`
    echo "Your commit message is: "$comment
    str=$(grep ^RED-[0-9]\\+[[:space:]][a-zA-Z0-9]* <<< $comment)
    if [ "$str" == "" ];then
       echo "[POLICY] Your message is not formatted 
             correctly! Use the 'RED-123 message' pattern, please"
       exit 1
    fi
done
echo "Thank you for your valid GIT commit message format!"
exit 0

Amennyiben javítani szeretnénk egy véletlenül elrontott kommit message-en, az Eclipse git staging view/ commit message/ Amend/ edit previous commit funkcióval tehetjük meg. 

2015. október 5., hétfő

dynaTrace Redmine Action Plugin

Már pár hónapja a KEKKH-ban tevékenykedek CIdynaTrace illetve GWT-s tesztelés témákban, ahol is a feladataim között volt a dynaTrace és a Redmine issue kezelő integrálása. Az elkészített plugin lényege, hogy amikor egy dynaTrace-es riasztás történik (pl. egy webservice túl lassan válaszol) akkor a dynaTrace egy új issue-t vesz fel a Redmine-ba, kitöltve az issue-t a hiba körülményeihez tartozó releváns információkkal (system profile, prioritás, riasztás oka). Amennyiben a probléma folyamatosan jelen van természetesen nem szemeteli teli az issue kezelőt ugyanazzal a problémával.


Az elkészült plugin és a konfigurációs dokumentációja szabadon elérhető ezen a linken. A plugin tesztelve lett Redmine 2.x és 3.x-es verziókkal is. Eredményes monitorozást mindenkinek!

2015. június 9., kedd

dynaTrace Nagios Plugin

A KH Bank igényei alapján nemrég fejlesztettem egy dynaTrace plugin-t, ami a dynaTrace által rögzített riasztásokat, a Nagios ill. klónjai számára (OP5, Icinga) képes automatikusan továbbítani. A pluginnál felhasználtam a jsendnsca API-t, ami elvégzi a Passive Check-ek elküldését a Nagios NSCA add-on számára.


Az elkészült plugin-t felraktam a dynaTrace community portálra, ahonnan szabadon letölthető a dynaTrace és a Nagios oldali konfigurációs dokumentációval együtt. Jó monitorozást!

2015. május 3., vasárnap

Maidenhead - dynaTrace 6.2 workshop

Az elmúlt héten részt vettem a Maidenhead-ben megtartott, dynaTrace 6.2 újdonságait bemutató 2 napos workshop-on. A dynaTraceWeb keretében, a GWTgridster.js és highcharts alapokon egy olyan webes felületet hoztak létre, ahol a meglévő dashbordjaink nézegetése mellett akár sajátokat is gyorsan összepattinthatunk. Az újdonságok között volt a Smart Analysis Engine továbbfejlesztése, az instrumentációs cache-elés, az exception szenzor feljavítása, a külső szolgáltatások nevesítésének megoldása és a licence kezelési módosítások. Az új feature-ök mellett szó volt az agenteket és a dynaTrace architektúrát is nagyban érintő jövőbeli fejlesztésekről, melyekről a dynaTrace Product Manager-e mesélt személyesen. A dT 6.2 a jövő hónapban fog megérkezni, várjuk szeretettel! :)


A workshop után még 3 napot Londonban töltöttem, ahol megnéztem a város főbb nevezetességeit és persze a híres múzeumokat is melyekre már nagyon kíváncsi voltam. Ez a kis pihenés most pont jól jött a munkával, tanulással és vizsgákkal tele zsúfolt elmúlt félév lezárásaként.

2015. április 2., csütörtök

Java SE 8 - Stream API további példák

A Stream API lehetőségeit érdemes minél jobban kihasználni, ha már Java SE 8-on fejlesztünk, ezért a múltkori cikket folytatva nézzünk meg még néhány használati példát.

Az alábbi kód megjeleníti a legtöbb karaktert tartalmazó String-et a listából. Látható, hogy milyen elegánsan használható a Comparator funkcionális interfész comparing() statikus metódusa mivel nem kell mindkét összehasonlítandó objektumot definiálni, csak azt kell meghatározni egy lambda kifejezéssel, hogy miszerint végezzük el az összehasonlítást. A max() hívás visszatérési értéke egy Optional<T> típusú objektum, amitől lekérdezhetjük az eredményt egy get() hívással vagy akár azt is hogy volt-e egyáltalán valamilyen eredmény: isPresent().
List<string> fruitList = 
 Arrays.asList("Alma","BaNÁN","KÖRTE","szILVA","BaracKok","kiwi");

String max=fruitList.stream()
 .max(Comparator.comparing(s -> s.length())).get()

System.out.println(max); //BaracKok
A következő példa a listában található sztringeket összefűzi az első 3 karakterük felhasználásával. A sztringeket 3 karakteres formára leképező map() már ismerős lehet az előző cikkből, azonban van itt egy újdonság is a reduce(). A reduce segítségével a Collection elemeit egy adott értékre redukálhatjuk le, hasonlóan ahogy a korábban bemutatott max() is működik. A példánál maradva, itt a reduce feladata az lesz, hogy a 3 karakteres sztringeket összefűzze egy String-be.
String concat=fruitList.stream().map(s -> s.substring(0, 3))
 .reduce("",(acc,curr) -> acc+curr);

System.out.println(concat); //AlmBaNKÖRszIBarkiw
A végére hagytam a kedvencemet a flatMap metódust, amivel egy listákat tartalmazó lista elemeit a lehető legelegánsabb módon dolgozhatunk fel. A Java 8 előtti időkben ehhez még 2 for ciklust kellett volna használnunk...
List<List<String>> list = new ArrayList<>();
List<String> sList1 = Arrays.asList("aaa", "bbb", "ccc");
List<String> sList2 = Arrays.asList("ddd", "eee", "fff");
List<String> sList3 = Arrays.asList("ggg", "hhh", "iii");  
list.add(sList1);list.add(sList2);list.add(sList3);

// external iteration
for(List<String> ls: list)
 for(String s: ls)
  System.out.println(s);  

// internal iteration
list.stream().flatMap(l->l.stream())
       .forEach(e->System.out.println(e)); 
Hát ennyi lett volna a Stream API, a folytatás hamarosan következik.

2015. március 3., kedd

Java SE 8 - Stream API bevezető

Legutóbb a Java 8 funkcionális interfészeivel ismerkedtünk meg, most pedig következzen a Stream API. A Java 8 könyvtárakhoz kapcsolódó legnagyobb változások a Collections API-t érintették, többek között megalkották a Stream API-t, amivel a Collection-ben lévő objektumokat - kihasználva a Lambda kifejezések lehetőségeit - most már stream-ként is feldolgozhatunk.

A Stream API előtti időkben ha egy listát akartunk bejárni, akkor külső (external) iterációt alkalmaztunk, ami feleslegesen terjengőssé tette a kódot valamint a párhuzamosított végrehajtásra való átállás esetén az egészet újra kellett írnunk. A Stream API egy olyan fluent megoldást ad a kezünkbe, ahol nem kell külön for ciklusokat definiálnunk, az iteráció (internal) részleteit lekezeli az API.
List<String> fruitList = 
 Arrays.asList("Alma","BaNÁN","KÖRTE","szILVA","BaracKok","kiwi");

// external iteration
long xcount = 0;
for (String str : fruitList) {
 if (str.length() == 4)
  xcount++;
}
System.out.println(xcount); //2

// internal iteration with Stream API
xcount=fruitList.stream().filter(str -> str.length() == 4).count()
System.out.println(xcount); //2
Az fenti kódrészlet megszámolja a 4 karakteres String-eket a Java 8 előtti és a Stream API által bevezetett iteráció használatával. Az internal iterációnál maradva, a stream() hívással elkérjük a listában található objektumok stream-jét, majd a Lambda kifejezést használó intermediate filter() művelettel kiválogatjuk a 4 karaktereseket, végül a count() terminate hívással lekérdezzük ezen elemek darabszámát. Érdemes tudni, hogy az intermediate műveletek csupán konfigurációs (lazy) feladatot látnak el, a tényleges bejárás a terminate (eager) művelet során történik meg.
Set<String> set = fruitList.stream()
 .filter(str -> str.length() != 4)
 .map(str -> str.toUpperCase()).collect(Collectors.toSet());

System.out.println(set); // [BARACKOK, KÖRTE, BANÁN, SZILVA]
A következő példa a nem 4 karakteres Stringeket nagybetűssé alakítja, majd az eredményt egy Set-be teszi. A map() konfigurációs művelet az értékeket egy másik értékre konvertálja át, az esetünkben minden egyes String-et - ami a filter()-ben definiált feltételnek megfelel - nagybetűssé alakít. A collect() hívással megkezdődik a Stream feldolgozása és a megfelelő objektumok bekerülnek az új Set-be.

A folytatásban további példákat fogok mutatni a Stream API használatára. De most legyen egy kis házi feladat: a filter() és a map() milyen funkcionális interfészt használ paraméterként?

2015. február 17., kedd

Code Monkey Island - Társasjáték ifjú kódereknek

A Code Monkey Island egy újabb társasjáték azoknak a 8+ éves gyerekeknek, akik játékos formában szeretnének a kódolás alapjaival megismerkedni. A Robot Turtles társasjátékhoz hasonlóan ez is egy Kickstarter-es projektként indult és napok alatt elérték a megcélzott összeget. A játék során megtanulható a vezérlési szerkezetek, adatstruktúrák, boolean logikai műveletek, értékadás és néhány matematikai művelet használata is.

A játékot mindenki 3 utasítás kártyával kezdi, amiből ki kell választani egyet amikor sorra kerülünk és a megadott utasítást végrehajtani, majd húzni kell egy új lapot. A programozás tanulás az utasítás kártyák alkalmazásában rejlik, melyekből néhány az alábbi képen is látható. A játék során találkozhatunk más állatokkal és gyümölcsökkel is amelyek extra lépéseket adnak. Végül az a játékos nyer, akinél mind a három majom leghamarabb körbeér a sziget körül.


Ami tetszett:
  • Jó ötlet a programozási koncepciók alkalmazásához
  • Tetszett a színvilág és az ábrák kivitelezése a kártyákon
  • Többen is játszhatják, így jó hangulatban fog telni a tanulás
Ami nem tetszett:
  • Egy társasjátékokhoz képest magas ár: 40$+30$ szállítás: 18.000Ft


2015. február 11., szerda

Robot Turtles - Társasjáték Logo alapokon

A robotok után nézzük meg azt a társasjátékot, ami a kickstarter történetében a legtöbb támogatót szerezte meg a táblajátékok kategóriában, ez pedig a Robot teknősök. A Primo-hoz hasonlóan, ez is a Logo alapjain nyugszik és a játékhoz még olvasni sem kell tudniuk a gyerekeknek.

A játékot négyen játszhatják egyszerre. Mindenki kiválaszt egy adott színű teknőst és az ehhez tartozó kártyákat magához veszi, majd fel kell építeni egy labirintust a falakat ábrázoló kártyákkal, ahova ékszereket ábrázoló kártyákat is elhelyezünk. A játék célja, hogy a teknősöket el kell juttatni az ékszerekhez, úgy hogy utasításokat tartalmazó kártyákat (előre lép, jobbra fordul, balra fordul) egymás mellé letesszük a megfelelő sorrendben. A kezdeti időszakban amikor a gyerekek leraknak egy kártyát, a teknőst egyből mozgathatjuk a megfelelő irányba, később amikor már belejöttek a játékba csak a teljes lépés sorozat megadása után. Hiba esetén (pl. ha falnak mentünk), kiáltani kell hogy bug van a kódban és a debuggolás során javítani kell a hibát.


Ahogy a gyerekek egyre profibbá válnak, úgy újabb kártya típusokat lehet hozzáadni a játékhoz. Ilyen például a jégfal, amit a lézer kártyával át lehet vágni vagy a béka akinek kioszthatunk egy feladatot mint lépés sorozatot, amit később bármikor meghívhatunk mint egy függvényt.

Ami tetszett:
  • Jó ötlet volt a Logo-t átültetni társasjáték formába
  • Fokozatosan új kártya típusok vihetők be a játékba (jégfal, béka)
  • Az egész család játszhat vele, mivel mindenki nyer így nincsenek vesztesek
  • Nem kell hozzá számítógép és mobil telefon sem
  • Megfizethető és a magyar verzió is megvásárolható (6.000Ft)
Ami nem tetszett:
  • Nem hasonlítható ahhoz, mint amikor egy valódi robot elkezd működni a kódod alapján, habár itt most nem is az a cél

2015. február 8., vasárnap

Lego Mindstorms - A legók királya

Talán a Lego Mindstorms a legismertebb robot, amit 10 éves gyerekeknek készítettek a programozás tanuláshoz, habár be kell vallanom én is szívesen eljátszadoznék vele. Mint sokan mások én is úgy voltam, hogy ennyi pénzért köszönöm inkább nem, de ha körbenézünk hogy a hasonló programozást tanító játékok milyen árban vannak, rájöhetünk hogy ez sem kerül sokkal többe.


A doboz többféle, külön-külön megépíthető programozható robotot rejt, melyek érzékelőkkel és motorokkal is rendelkeznek valamint távirányítóval irányíthatók. A robot programozását a számítógépen tudjuk elvégezni, majd a megírt programot áttölthetjük (USB/wifi/bluetooth) a robot agyába ami egy 300Mhz-es ARM9 mikrokontroller (EV3 brick), de a PC-ről is irányíthatjuk a robotot amennyiben nem az autonóm működést választjuk például a mikrokontroller alacsony számításkapacitása miatt. A robotot többféle nyelven programozhatjuk, így van köztük olyan is amit fiatalabb gyerekeknek ajánlanak. Az ismerkedéshez Kiss Róbert ingyenesen letölthető magyar nyelvű könyvét érdemes átnézni.

Ami tetszett:
  • Más Legó elemekkel is összeépíthető és bővíthető
  • Kiépült ökoszisztéma, rengeteg kiegészítő, könyv és leírás
  • A Legókhoz illően igényes és strapabíró kivitelezés
  • Ha több robotot is építünk, azok képesek egymással kommunikálni
Ami nem tetszett:
  • Nem olcsó (110.000 Ft), habár a többi konkurens játékot elnézve ebben a kategóriában átlagosnak mondható
  • A kiegészítők irreálisan drágák, egy 200 forintos szenzort becsomagolnak legóba és több mint a 100 szoros árat kérik el érte
  • Vigyázni kell az alkatrészekre, mert a pótlásuk nehézkes
  • Ki fog ezután a szabadba menni focizni?


2015. február 4., szerda

Toot - Programozás tanulás hangokkal

A Primo csapat következő nagy dobása a Toot nevű játék lesz, melyet a Primo-hoz hasonlóan szintén a 3-6 éves korosztály számára találtak ki. Az óvodás gyerekek számára a legfontosabb, hogy az egyes utasítások szekvenciális végrehajtását megértsék, így ezt a játékot is ennek a játékos gyakorlására fejlesztették ki. Az eddig bemutatott játékoktól eltérően itt most nem izgő-mozgó robotokat kell beprogramozni, hanem a hangoké és a szavaké lesz a főszerep.


A játék 8 darab fadobozkából áll, amelyekben egy-egy mikrofon és hangszóró kapott helyett. A gyerekek hangja rögzítésre kerül amint belebeszélnek vagy énekelnek a kockákba, majd a felvett minta egy rázás hatására visszajátszható. A játék szépsége, hogy a szemüveges bajuszos  kocka után (kezdő pont) ezek a kockák egymás után lerakhatók majd a bajuszos kockán lévő gomb megnyomásával a felvett hangok egymás után lejátszhatók. De ez még nem minden, játszhatunk még vele a memóriakártyákhoz hasonló hangalapú párkeresést is vagy párosítós (kutya - ugatás) játékokat is. Opcionálisan egyébként a mobil telefonnal is összeköthető a játék, ahonnan például a memória vagy a párosítós játékokhoz szükséges hangokat tölthetjük be a kockákba.

Ami tetszett:
  • Talán ez az első bemutatott játék, amit egy 3 éves gyereknek már oda mernék adni, hogy lekösse a figyelmét
  • Kreatív ötlet az utasítások szekvenciális végrehajtásának megtanításához
  • A játékhoz nem feltétlen szükséges számítógép vagy mobil használata
  • Többféle játék is játszható vele
Ami nem tetszett:
  • Ha nem lesz valami központi kockatöltő állomás, akkor elég macerás lesz töltögetni a dobozokban lévő elemeket ha lemerülnek. :(
  • Az ár még nem ismert, de szerintem az is ide fog tartozni


2015. február 2., hétfő

Cubes Coding - Kockával kódoljon a gyerek

A Cubes Coding csapata is kockákkal való kódolásra építi a robot játékát, amit már 3 éves kortól ajánlanak a gyerekeknek. A nagyobb kockák összeillesztésével készíthető el a robot programja, a kisebb kockák pedig a paraméterek szerepét látják el. A játék nagyon hasonlít (és szerintem az ötletet is onnan vették) a KIBO robothoz, azonban a robot felprogramozásához nincs szükség a kockák vonalkódjainak leolvasására, azokat csak a csatlakozókon keresztül kell összedugni. A játék kezdeti stádiumban van, mivel saját robot még nem érhető el hozzá és megvásárolni sem lehet. Érdemes lesz majd visszanézni 1 év múlva hogy hova sikerült eljutniuk.


Ami tetszett:
  • A kockákkal kialakított programkód beolvasása egyszerű
  • Sokféle parancs és paraméter (28 parancs és 16 paraméter kocka)
Amin nem tetszett:
  • Nincs benne túl sok újdonság, a KIBO robot ötletét vették alapul


2015. január 26., hétfő

Dash & Dot - Használd a kreativitásod

Manapság kevés olyan játék van, amiben a gyerekek igazán kiélhetik a kreativitásukat, azonban a következő robot páros pont egy ilyen. Nincsenek kötöttségek, nincsenek konkrét feladatok és lépések, viszont van 2 robot Dash és Dot akiket a mobilon keresztül felprogramozhatunk arra a feladatra amit éppen kitaláltunk nekik.

Dash kerekeken gurul, tud világítani, hangot kiadni és a beépített szenzorai segítségével az előtte lévő tárgyak távolságát is képes meghatározni. Dot kisebb és szerényebb képességekkel rendelkezik, nincsenek kerekei és szenzorokat sem kapott, cserébe a testvérével bluetooth kapcsolaton keresztül tud kommunikálni és a vonóhoroggal elvitetheti magát.


A játékot 5 éves kortól ajánlják, a nagyobbak akár saját programokat is írhatnak a nyílt API-ra építve, hasonlóan ezekhez az appok-hoz. A játék egyébként hasonló játszhatósági sémára épül mint a Codie robot, ehhez képest az előnye hogy a 2 robottal összedolgoznunk és sok kiegészítő elérhető hozzá, hátránya viszont hogy nincs bennük annyi szenzor.

Ami tetszett:
  • A mobilos alkalmazások ötletesek, szépen kialakított felületek
  • Szép a robotok külső kialakítása, a KIDO ilyen téren nem jött be
  • Nem a szokásos, de nagyon kreatív kiegészítők illeszthetők hozzá: xilofon, lego connector, vonóhorog, buldózer.
Ami nem tetszett:
  • A Wonder Pack ára, a két robottal és a kiegészítőkkel: 300$ (80.000Ft)
  • Mobiltelefon szükséges a használatához
  • Kevés szenzorral rendelkeznek a robotok

2015. január 20., kedd

KIBO - Programozás fakockákkal

A KIBO egy olyan robotkészlet amit speciálisan a 4-7 éves gyerekek számára terveztek és a programozás mellett a fizikai aktivitást, a kreativitást és művészeti érzéket is képes fejleszteni. A KIBO fakockák egymás mellé illesztésével a gyerekek összerakhatják az utasítások sorozatát, azaz magát a programot. Miután elkészült a program, a robot járműbe épített vonalkód leolvasóval végig kell pásztázni a kockákat, majd a start gomb megnyomására a robot végrehajtja az utasításokat a megfelelő sorrendben. A kockák, típusonként eltérő feladatra utasítják a robotot: előre mozgás, jobbra ill. balra fordulás, forgás, világítás a lámpával, zenélés. A készletben találhatunk olyan kockákat is, amelyekkel feltételes szerkezeteket definiálhatunk paraméter lapok használatával, de további szenzorokkal is bővíthetjük a robotot.


Ami tetszett:
  • Bővíthető a fakockákkal meghatározott utasítás készlet
  • Mivel egyszerre többen is játszhatnak vele, ráhangol a csapatmunkára
  • Nem kell hozzá bekapcsolni sem a számítógépet, sem a mobiltelefont
  • Strapabíróbbnak tűnik mint az azonos korosztálynak szánt Primo
Ami nem tetszett:
  • A 10 darabos alapszett ára 229 USD (60.000 Ft), a 18 elemet tartalmazó szett pedig 399 USD (100.000 Ft) -ba kerül
  • A paraméter lapok használatát erőltetettnek látom
  • A robot vonalkód olvasón keresztüli programozása egy idő után már kicsit macerás


2015. január 15., csütörtök

Codie - A hernyótalpas jármű, ami megtanít kódolni

Codie egy magyar fejlesztésű hernyótalpas robot jármű, amibe egy halom szenzort belepakoltak: iránytű, giroszkóp, távolság érzékelő, fény érzékelő, szín érzékelő, mikrofon és vonal olvasó. A járművet mobiltelefonon keresztül lehet felprogramozni, úgy hogy egy folyamat diagramot kell összerakni, ahol megadhatjuk, hogy a szenzorok által mért információk alapján mit csináljon a robot. Csak néhány példát említve, kerülje ki az akadályokat, tapsolásra elinduljon vagy éppen villogással jelezze ha sötét van a szobában. Található még rajta egy programozható led kör és egy speaker is valamint a kialakított bluetooth kapcsolaton keresztül a robot képes visszajelezni a telefon számára. Az ajánlott célközönség a 8 és 14 év közötti korosztály. Ha sikerül tartani az ütemezést az első széria már 2015 nyarán a boltokba kerülhet, addig is nézzétek meg a bemutató videót. Hát igen, szívesen kipróbálnám...


Ami tetszett:
  • Sok szenzort tartalmaz, ami lehetőséget ad az egyéni kreativitás kiéléséhez
  • Tetszik, hogy egy flow chart diagramon húzogathatjuk össze az algoritmust
  • Az ára alacsonyabb lesz mint a konkurens termékeké: 160$ (40.000 Ft)
  • Ügyes formai kialakítás, a robot nem esik fejre :)
Ami nem tetszett:
  • Előnyösebb lenne, ha a mobilos flow chart diagram inkább lentről felfele bővülne
  • A mobilos programozással a gyerekeket a kijelző elé tereljük valamit a játékot és a flow élményt is könnyen megzavarhatják a bejövő hívások, sms-ek és email-ek. 

A múlthéten egyébként felvettem a kapcsolatot a Codie fejlesztőivel és megosztottam velük pár ötletemet (flow chart irány, mobil nélküli felprogramozás lehetőségei, stb...) valamint pár felmerült kérdésemre is választ kaptam. Ezúton is köszi és sok sikert a robothoz!

Itt találod a játékos programozás gyerekeknek gyűjtő topikot.

2015. január 11., vasárnap

Primo - Logo programozás óvodásoknak

Primo egy olyan 3-7 éves korosztály számára készített játék, ami a Logo ötletét egyszerűsíti le a programozás alapjainak megtanításához. Aki esetleg a Logo-t nem ismerné, van egy teknősünk a képernyő közepén, aki a bepötyögött utasítások alapján (előre, fordul, tollat lerak, stb.) képes a képernyőre rajzolni akár bonyolult alakzatokat is.


A Primo szett tartalmaz egy kocka alakú robot járművet (Cubetto), utasítás blokkokat mint kis színes fa elemeket (előre, balra, jobbra, függvény hívás) és egy táblát amire az utasítás blokkok felhelyezhetők. A játék lényege, hogy Cubetto-t elvezessük a céljához, ami lehet a fa házikó vagy bármi más a szobában, úgy hogy kikerüljük az esetleges akadályokat. Cubetto pontosan úgy fog haladni, ahogy mi felprogramoztuk az utasítás blokkokkal a táblán, azaz a megadott utasításokat egymás után végrehajtja. A haladó játékosok akár függvényhívást is használhatnak, aminek az utasításait az alsó zöld keretes funkció sorban adhatunk meg, majd a zöld fakarikákkal akár többször is meghívhatunk.

Érdemes tudni, hogy a Primo kizárólag open source elemekből építkezik, így annak lelkét is Arduino lapkák adják. Ezen az oldalon elérhető a dokumentáció, tervrajzok és az Arduino programkódok is amivel akár mi magunk is megépíthetjük a Primo-t. Remek!

Ami tetszett:
  • Remek megvalósítás, ahogy a Logo programozást átültették ebbe a formába
  • Egyszerű, így a legkisebb gyerekek számára is gyorsan megtanulható a kezelése
  • Nem kell hozzá bekapcsolni sem a számítógépet, sem a mobiltelefont
  • Teljesen open source, így a tervrajzok és a kódok alapján bárki megépítheti
Ami nem tetszett:
  • Az alapkészlet ára 282$ átszámolva kb. 75.000 Ft
  • Habár személyesen még nem tapogattam meg, de a kisautó (Cubetto) nem hiszem hogy egy 3-4 éves gyerek kezében túl sokáig épségben maradna
  • Az egyszerűsége miatt szerintem hamar megunható, habár valódi tapasztalataim nincsenek vele
  • Nem bővíthető, például újabb szenzorokkal vagy utasítás blokkokkal

2015. január 6., kedd

Játékos programozás gyerekeknek

Most egy új téma következik a programozáshoz kapcsolódóan. Mivel érdekelt a téma és körbenéztem, megosztom veletek amit találtam:


Programozni jó és a világ is olyan irányba halad, hogy a gyerekek minél korábban megismerkedjenek a kódolás szépségeivel, mivel fejleszti a logikus gondolkodást, a problémamegoldó készséget és a kreativitást is. Azzal nem értek egyet, hogy a gyerekeket már 10 éves kor előtt a számítógép elé kellene ültetni kódolni, de úgy gondolom hogy vannak olyan játékok amikkel igenis lehet fejleszteni a programozói készségeket. Innen jött az ötlet, hogy a következő sorozatomban felkutatom azokat a lehetőségeket amivel a 3 és 14 év közötti korosztályt el lehet kezdeni programozni tanítani.

Az én időmben persze még nem volt túl nagy választék, nekem például egy C64-es gépem volt amin egyszerű programokat írogattam BASIC-en, de az általános suliban is tanultunk programozást már 3. osztálytól Logo nyelven. A Logo egyébként a mai napig is megállja a helyét, most is csak ajánlani tudom. Azóta viszont majdnem eltelt 20 év és szerencsére a lehetőségek száma is megsokszorozódott, szóval lesz miből válogatnom.

A következő néhány bejegyzésben olyan a programozást tanító játékokat fogok bemutatni, amelyek kifejezetten óvodás vagy általános iskolás gyerekek számára készültek. A válogatás és az értékelés is szubjektív, így csak a saját véleményemet tükrözi. Összeírtam azokat a jellemzőket, amelyeket én fontosnak tartok egy ilyen játéknál, igaz mindegyiknek egyik játék sem fog megfelelni:

  • Adjon teret az egyéni kreativitásnak, de tartalmazzon konkrét feladatokat is
  • Ne kelljen hozzá a számítógépet vagy a mobil telefont bekapcsolni
  • Legyen strapabíró, különösen a 3-6 éves gyerekeknek szánt játékoknál
  • Legyen bővíthető (akár saját) kiegészítőkkel
  • Egyénileg és többen is lehessen vele játszani (csapatban vagy egymás ellen)
  • Legyen megfizethető, mert a programozás mindenkié

2015. január 2., péntek

2014-es évértékelő

Ezt az évet is a szokásos visszatekintő évértékelőmmel kezdem, amiben röviden összefoglalom mit is csináltam az elmúlt esztendőben, de előtte még egy hirdetmény következzen. Mivel többen is szóltatok, hogy nehéz megjegyezni a blogom url-jét és a régi nagy kedvenc JBoss Seam keretrendszert is már máshogy hívják (4 éve innen jött a Seamplex név), ezért új domain nevet választottam.

A munkám alapvetően nem változott az elmúlt 2 évben, még mindig a dynaTrace hivatalos támogatásával, pilotolással és performancia optimalizálással foglalkozom. A tavalyi évhez képest az ügyfélszámunk ismét sokat nőtt, a meglévő ügyfeleink egy részénél pedig licence-ket is bővítettünk. Hát igen, ők már mind a dynaTrace APM eszközt használják:

  • Raiffeisen Bank Zrt.
  • K&H Bank Zrt.
  • Erste Bank Hungary Zrt.
  • MagNet Bank Zrt.
  • Raiffeisen Bank Románia
  • Magyar Telekom Nyrt.
  • Telenor Magyarország Zrt.
  • Földgázszállító Zrt.
  • MVMI Informatika Zrt.
  • Generali Biztosító Zrt.
  • GIRO Zrt.
  • ShiwaForce Zrt.
  • Szerencsejáték Zrt.
  • Magyar Közút Nonprofit Zrt.
  • Szellemi Tulajdon Nemzeti Hivatala
  • Országos Nyugdíjbiztosítási Főigazgatóság
  • Nemzeti Infokommunikációs Szolgáltató Zrt.

A megnövekedett dynaTrace installációk támogatása miatt, a tavalyi év elején felvettünk egy új kollégát (Attilát) aki leginkább a .NET-es dynaTrace ügyfelek és a DC-RUM-os support tevékenységeket végzi. Hát nagyon úgy néz ki, hogy ebben az évben ismét szükség lesz a bővülésre. (Ha érdekel a téma, szólj!)

Ami pedig engem illet, a dynaTrace-es feladataim mellett, az év elején részt vettem az amsterdami Compuware EMEA rendezvényen, előadtam a Szoftvertesztelés VI. és a 2014-es webes konferencián, fent voltam a ComputerWorld címlapján és írtam az agilis teljesítmény-menedzsment fontosságáról. A már régóta halogatott Oracle Java vizsgákat is leraktam (1Z0-803, 1Z0-804), így hivatalosan is Oracle Certified Professional, Java SE7 Programmer lettem, ami azért volt fontos a számomra, mert a dynaTrace-es ügyfeleinknél elkezdtem a Jávát is oktatni.

Ez a Java oktatási ötlet egyébként onnan jött, hogy a dynaTrace-t legtöbbször az üzemeltetés vásárolja meg és az üzemeltetők általában nem rendelkeznek elegendő Java ismerettel, ami viszont sokszor hasznos lehet a dynaTrace használatakor. Ezért találtam ki, hogy hozzunk létre Java oktatásokat az üzemeltetőknek, így születtek meg a Java SE üzemeltetőknek és a Java EE üzemeltetőknek című 5 napos tréningek. A Java EE tréning gyakorlati feladataihoz több alkalmazás szerverből is lehet választani (Weblogic, WebSphere, JBoss) így mindenki azon tanulhat amit egyébként is használ nap mint nap.

Úgy gondolom, hogy a legizgalmasabb része az évértékelőknek mindig is a jövőre vonatkozó szakmai célok meghatározása. Mivel hasznosnak bizonyultak és a munkahelyem is támogatja, szeretném folytatni a Java vizsgák letételét a Java SE 8 professional illetve valamelyik hamarosan kiadásra kerülő Java EE 7 expert vizsgával. Tervezem, hogy blogolok majd a Java 8 újdonságairól, a dynaTrace-szel beazonosított tipikus problémákról és a mostani kedvenc témakörömről, az egészen fiatal gyerekeknek szóló programozás oktatás lehetőségeiről, ami igazából csak egy fontos dologról szól, a kreativitásról!