GeeCON 2014, Prága
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.
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:
- External integration diagram
- Internal component diagram
- Domain model
- Domain dictionary (hogy mindenki ugyanarra gondol-e)
- Decision log (hogy mit miért és milyen verzióban használunk)
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
Ki hallott már a helyről, ahol dolgozom? Oh, mennyi kéz, ez több mint ahányan production-ben használják a Jáva 7-et.
Szóval elővesszük a kedvenc projekt manager programunkat, gradle, maven, bármelyik másik, és nem letöltjük meg bemásoljuk a jar fájlt, ez nem a 90-es évek, helló! üdvözöllek a jövőben.
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.
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/
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.