Hello Tanárúrkérem

Sokan kérdezték, mi lesz most velem? Jól eset ez a sok szeretet, ami az érdeklődésekből áradt. Leírom hát nektek mit tervezek 2014-re.

Viszlát Integral Vision

Több mint három éves közös munka a mai nappal véget ér. Az Integral Vision csapata és én külön folytatjuk tovább. Nincs más hátra, mint megköszönjem a nagyszerű csapatnak, és kiemelten Kulcsinak a közösen eltöltött nagyszerű éveket.

Megjelent az Insert modul legújabb 7.x-1.3 verziója

A héten jelent meg a Drupal 7.20 verziója, ami egy olyan javítást tartalmazott, ami az Insert modulnál hibás működést eredményezett. Mivel mi - az Integral Vision csapata - is számos projektben használjuk az Insert modult, nem volt kérdés, hogy beszállunk a hiba javításába.

A lehetetlen küldetés

Mivel raerek egy terjedelmes blogbejegyzésben reagált felvetéseimre, ezért gondoltam én is billentyűzetet ragadok és megpróbálok érdemben reagálni rá.

Nem lehet változtatni, írja, de én nem vagyok hajlandó elfogadni ezt az állítást.

Tisztába vagyok ugyanakkor azzal, hogy nehéz, sőt piszok nehéz megváltoztatni egy ilyen dolgot. Nehéz, de nem lehetetlen.

Az évszázad átverései az informatika érettségin

A videóban említett google csoport: http://groups.google.com/group/informatika-erettsegi

Címkék:

Magyarországi Web Konferencia 2011 - Élménybeszámoló

Az év második legnagyszerűbb eseménye számomra, hogy Joó Ádám vezetésével egy lelkes csapat ismét megrendezte a Magyarországi Web Konferenciát. Számos nagyszerű újítás mellett igyekeztek megőrizni a konferencia értékeit, amiktől az egyik legsikeresebb haza szakmai találkozóvá tudott válni a rendezvény. A sikert mi sem jelzi jobban, mint az, hogy a tartalmas szakmai programokat jóval ötszáz fő feletti nézősereg látogatta meg.

Nem indulhat hát mással e bejegyzés, mint egy hatalmas köszönettel és virtuális várveregetéssel Ádámnak és lelkes csapatának, akik energiát nem kímélve, szabadidejüket feláldozva hozták össze ezt a nagyszerű szombati napot.

Mivel előző nap született meg Huba fiam és csak a Fő utca elején, a vár lábánál találtam parkolóhelyet, lógó nyelvel és kissé kótyagos fejjel érkeztem meg a helyszínre valamivel tíz óra előtt. Nem vesződtem a program böngészésével, hanem Kulcsár Zsolt barátomra bíztam magam. Jól tettem.

Kulcsi Árvai Zoltán: Az első három másodperc című előadására invitált. Mivel dolgozott már együtt Zoltánnal egy projektben, ezért nem volt kétségünk afelől, hogy egy nagyszerű szakember előadását fogjuk hallani. Jóleső meglepetésként ért minket a tény, hogy Zoltán nem csak kitűnő szakember, hanem nagyszerű előadó is. Az előadása ugyan egy bevezető, kezdőknek szóló ismertető volt, mégis magával ragadó lendülete és számos felvillantott nagyszerű ötlete miatt végig élvezetes volt hallgatni. Nekem a legjobban a „főoldalas elmetrükkje” tetszett a legjobban. Ez a trükk arról szólt, hogy egy szájt főoldala az mindenkié, tehát a usability szakember ne akarja megmondani ott a tutit. Helyezzen el rajta megfelelő mennyiségű, egyértelmű navigációs elemet, amivel a látogatók gyorsan tovább tudnak navigálni azokra a belső oldalakra, ahol – lévén az már sokkal kevesebbeket érdekel – érvényesíthetjük szakértelmünket. Ha a vezérigazgató ki akarja rakni a képét, vagy a marketinges, hr-es, pr-os bele akar szólni, hogy mi legyen azon az oldalon, hát tegye. A látogatók nagy része úgyse arra az oldalra érkezik, hanem valamelyik belső oldalra. Zseniális. Az előadás egyetlen egy hibája az volt, hogy bár az első sorban ültem még se kaptam csokit. :)

Ezután egy olyan blokk következett, ahol nem igazán volt számomra vonzó előadás. Vagyis pontosabban, mivel alig ettem az elmúlt napban valamit sokkal vonzóbb volt számomra a büfé szekció. Toltam hát egy szendvicset és megpróbáltam 200+ embernek elküldeni a jó hírt fiam születéséről. A modern technikának hála, ez egy óra alatt nem sikerült, így ki kellett hagynom a következő előadásblokkot is. Bár az az igazság, ebben a blokkban három olyan izgalmas előadás volt, amik között igen nehezen döntöttem volna, így kapóra jött, hogy kihagyhatom ezt a nehéz döntést. Közben leült mellém Krisztián dumálni, így nem volt kérdés, hogy az ő előadására fogok beülni.

Karóczkai Krisztián a szokásos lendülettel indult neki az előadásának, amire szüksége is volt, hisz – saját elmondása szerint – hajnali négyig rakta össze az előadását, ami meg is látszott rajta. Vagyis ezt csak az vette észre aki ismeri előadói stílusát és habitusát. Speciel én örültem ennek a „döcögősebb” stílusnak, hisz így volt rá lehetőségem, hogy még ott a helyszínen feldolgozzam, megértsem azt amiről az előadásban szó van. :) Krisztián az Open Web Application Security Project által kidolgozott legveszélyesebb hibákról beszélt. Ahol lehetősége volt egy rövid videóval mutatta be a lehetséges támadások kivitelezését és kivédését. Saját – hibásan elkészített – webalkamazásába tört be a különböző módszerekkel, és egyre másra győzte le korábbi tudatlan énjeit. Megmondom őszintén én nagyon élveztem az előadást.

Ezután Vészi Gábor és Farkas Szilveszter: DevOps a Prezinél című előadására ültem be. Kulcsival egyetértésben ismételten meg kellet emelnünk a kalapunkat a Prezi nyitott szellemisége előtt. Jó volt hallgatni, hogyan lesz egy kis vállalkozásból hatalmas világméretű cég. Érdekes volt látni, hogy a kezdeti egyszerűbb infrastruktúrát hogyan, mire és miért cserélik le. Tanulságos volt megfigyelni, hogy hogyan kezelik az egyre növekvő méretű fejlesztői csapat munkájának összehangolását. Biztos vagyok benne, hogy aki valaha is céget alapított, alig várja már, hogy ezekkel a problémákkal kelljen megküzdenie. Egyszóval jó volt látni a jó példát.

Mindent összevetve nagyszerű volt az idei rendezvény. Nagy köszönet illeti a szervezőket és az előadókat!

Címkék:

Mit tanulj meg a szabad szoftverről?

A szabad szoftver nem más mint közösségi alkotás.

Ebbe a közös alkotásba bárki beszállhat, nem kell hozzá programozói ismeret. Számos olyan része van a szoftverfejlesztésnek, amihez nem szükséges a forráskód ismerete. Sőt a nagy része a munkának pont ilyen feladatokból áll.

Legegyszerűbb, hogy ha használsz ilyen szoftvert és szereted, akkor elmondod mindenkinek azokat a jó dolgokat, amiket kedvelsz benne (marketing) és a fejlesztőknek pedig jelzed a hibákat (hibajelzés).

De nem csak a hibákat jelezheted, hanem, ha van egy jó ötleted, amit elég meggyőzően tudsz előadni, képviselni, azt a közösség meg fogja valósítani. Tehát úgy fejleszthetsz egy szoftvert, hogy egy sor kódot sem írtál.

Ha egy picit bátrabb vagy, megismerkedhetsz olyan eszközökkel, amikkel a forráskódból működő programot lehet készíteni és részt vehetsz a szoftver tesztelésében. Ez jóval egyszerűbb mint hinnéd. Pár csomagot kell telepítened a gépedre és egy-két parancsot kiadnod. Ezek a lépések általában jól dokumentáltak, hisz a közösségi fejlesztésnek egyik kulcsa, hogy ahhoz bárki könnyedén csatlakozhasson. Ráadásul, vannak olyan, úgy nevezett scriptnyelvek (ilyen pl. a PHP), amiknél még fordítanod sem kell.

Nem csak ember és gép között kell fordítani, hanem ember és ember között is. Ha a fentiek nem vonzanak, csatlakozhatsz a helyi honosító csoporthoz is, ahol az adott szoftver magyarítását végzik. Nincs nagyszerűbb érzés, mint egy programban viszontlátni a saját fordításunkat.

Eleinte a különböző támogató(support) fórumokon a kérdéseidre fogod keresni a választ, de egy idő után Te is tudsz majd segíteni az utánad jövőknek. Ezzel is részt vehetsz a közös alkotásban.

Legvégül, de csak ha igazán érdekel, beszállhatsz a programozásba is. Készülj fel, hogy nem lesz egyszerű dolog, hisz számos olyan új fogalmat, munkamódszert kell elsajátítanod, amikre eddig, amikor egyedül dolgoztál, nem volt szükséged.

Mivel nem kényszerít senki ezekre a tevékenységekre, olyan mélységig vonódsz be, amennyire szeretnél. Ha csak használni akarod a szoftvert, akkor a második bekezdésben leírtak szerint járj el. Tudnod kell azonban, hogy minél több munkát fektetsz egy ilyen közösségi fejlesztésbe, annál több olyan kompetenciát szedhetsz magadra, amivel később a munkaerőpiacon könnyebben érvényesülhetsz.

Ha az infótanárod csak annyit képes kinyögni, hogy „a szabad szoftver azért jó, mert belepiszkálhatsz a forrásba”, akkor kérlek mutasd meg osztálytársaidnak ezt a blogbejegyzést. (Ha a tanár elég nyitott akkor természetesen neki is.)

Ha a tanárod mutatta neked ezt a blogbejegyzést, akkor becsüld meg őt!

Egy hét Drupal 7: Oldal kiszolgálás és a drupal_render

Most, hogy gőzerővel készülök az Integral Vision Workshop rendezvénysorozatunkra, úgy gondoltam megosztok egy pár érdekességet, gondolatot a Drupal 7 verziójáról.

Ma az oldalkiszolgáló mechanizmus egyik legnagyszerűbb újdonságáról fogok beszélni.

Eddig a Drupal oldalkiszolgáló mechanizmusa a következőképpen működött: Amennyiben nem adtunk vissza semmit az oldal tartalmát előállító függvényben, akkor a Drupal feltételezte, hogy a kimenetet már mi magunk kiküldtük, és ezért ő "semmit nem csinált". Abban az esetben, ha visszaadtunk egy szöveget akkor azt úgy tekintette, mint a weboldalunk tartalmi része. E köré a tartalmi rész köré rakta a régiókat és mindenféle egyéb okosságot ami szükséges volt az oldalunk megjelenítéséhez. (A fent jelzett okosságokat egyébként a sminkünk, page.tpl.php (6.x, 7.x) és html.tpl.php (7.x) fájljában találhatjuk meg)

A hetes Drupalban azonban van egy merőben új lehetőség, mely azok számára, akik valaha is állítottak elő űrlapot a Drupalban, csak örömöt, újdonságot nem fog jelenteni.

Egy hét Drupal 7: JavaScript library

Most, hogy gőzerővel készülök az Integral Vision Workshop rendezvénysorozatunkra, úgy gondoltam megosztok egy pár érdekességet, gondolatot a Drupal 7 verziójáról.

Ma a library fogalmáról és pár JavaScript újdonságról lesz szó.

Számos esetben előfordul, hogy kisebb látványelemekkel, felhasználói élményjavítókkal szeretnénk feltuningolni weboldalunkat. Ilyenkor általában a netről összevadászott JavaScript csodákat kell az oldalunkba illeszteni.

Gyakran ezek a csodák nem csak egy JavaScript fájlból álltak, hanem tartalmaztak css fájlokat is. Számos esetben különböző függőségeik voltak. Volt, hogy nem jQuery függvénykönyvtárat, hanem valami mást használtak, ami miatt nehezen tudtuk az oldalainkba illeszteni azokat. Azokról a widgetekről már ne is beszéljünk, amiknél a javascript fájlokat az adott projekt oldaláról kellet beszúrnunk. A Drupal 7 megoldást kínál ezekre a problémákra, egy kis próba modul segítségével nézzük meg hogyan.

Egy hét Drupal 7: Simpletest

Most, hogy gőzerővel készülök az Integral Vision Workshop rendezvénysorozatunkra, úgy gondoltam megosztok egy pár érdekességet, gondolatot a Drupal 7 verziójáról.

Ma, ahogyan ígértem arról lesz szó, hogyan tudjuk tesztelni az elkészített modulunkat.

A Drupal hetes egyik legnagyobb újításai közé tartozik az, hogy a minőség biztosítása érdekében bevezették az automata tesztelést. Mielőtt rátérnénk arra, hogy ez miért jó és hogyan használható, előtte tegyünk egy kis kitérőt a programozott tesztelés felé.

Az elmúlt hónapokban Marhefka István aka info@ és Zsoldos Péter alias zsepi kalauzolásával merültem el a Test Driven Development világában. Mindketten igen komoly nagyvállalati tapasztalattal rendelkeznek e téren. Egyikük a Javas világot ismeri jobban, míg másikuk a .Net fejlesztőeszközök használatában jártas. Azonban, amit tanultam tőlük, az jóval több mint eszközök puszta ismerte.

A módszer röviden annyi, hogy mielőtt nekiállnánk a kód írásának, a kód automata tesztelését lehetővé tevő teszteseteket írjuk meg. Egy új funkció bevezetése a következő lépésekből kell, hogy álljon:

  1. Adj hozzá egy tesztet
  2. Futtasd a teszteket és figyelj arra, hogy az új teszted elbukjon
  3. Írd meg a kódod
  4. Futtasd a teszteket és figyeld, hogy mindegyik teszt sikeres legyen
  5. Refaktoráld a kódodat a tesztek segítségével

Első hallásra a világ legnagyobb hülyeségének tűnik, hogy az ember először tök feleslegesnek látszó kódsorok gyártásával foglalkozzon és csak utána lásson neki a tényleges hasznot hajtó kódsorok bepötyögésének. Amennyiben az ember ráveszi magát, hogy egyedül kipróbálja ezt a metodikát, biztosan elmegy tőle a kedve. Elmegy, hisz éppen egy tanulási folyamat elején vagyunk, így az egy-két hónapos gyakorlás utáni egy perces munkákkal az elején, akár egy napot is elbíbelődhetünk.

Amennyiben belevágunk egy ilyen kalandba nem baj, ha megfelelő motiváltsággal, kitartással és egy tapasztalt segítőtárssal vágunk bele. Nekem ez utóbbiból szerencsére kettő is akadt.

Nézzük milyen előnyökkel jár, ha ezt a metodikát követjük.

Az első nyereség az abból adódik, hogy mint mindig, a legelején meg kell terveznünk azt, hogy mit fogunk elkészíteni. Ennek a tervnek a végeredménye tud lenni egy olyan kis program, ami leírja azt, hogy mi az elvárt működése a programunknak. Gondoljunk bele. Már egy egyszerű függvénynél is meg szoktuk mondani, hogy milyen bemeneti paraméterekre milyen kimenetet várunk. Miért ne tennénk ezt úgy, hogy azt később is fel tudjuk használni? Később, amikor már nem lesz kedvünk minden egyes javításkor az összes lehetséges esetet végigpróbálni. Ekkor rettentő jól fog jönni, hogy ezt egy gépre, egy automatára bízhatjuk.

Ha a fenti elképzelés nem is szimpatikus, akkor is valahogyan ki kell próbálnunk az általunk elkészített kódot. Gondoljunk bele, ilyet mi is csinálunk. Folyamatosan készítünk apróbb tesztkódokat, amiket azután kitörlünk. Miért ne őrizhetnénk meg ezeket? Miért kéne kidobálnunk ezt a munkánkat?

Tudom, hogy hihetetlennek hangzik, de amennyiben elég jól ismerünk egy teszt keretrendszert, vagyis, megfelelő gyakorlatunk van a használatában, a plusz munka költsége gyakorlatilag nulla.

Persze, ha valaki erre azt mondja, hogy ez nem igaz, annak igazat kell adnom. Nem nulla, annál jóval kevesebb. Kevesebb, hisz ebben a pillanatban a rövid távú nyereség mellett hosszú távú nyereségeink is lesznek. Ki gondolná ugyanis, hogy egy jól kitesztelt helyen a kódban még egy hiba felbukkanhatna? Senki. Ha jobban belegondolunk, mi is tudunk ilyen eseteket mondani, ráadásul valószínűleg arra is emlékszünk, hogy ezeknek a hibáknak a megtalálására mennyivel több időt kellett anno fordítanunk. Ezeket a régebben kidobált időket is megnyerhetjük.

Amikor azt mondom refaktor, lehet többek ereiben meghűl a vér. Azonban ha azt is közlöm, hogy én refaktor alatt arra gondolok, hogy átírom a kódomat pusztán azért, hogy szebb és tisztább legyen, már többek nemtetszését is kivívhatom. Kivívhatom, hisz azért dolgozzak, hogy se gyorsabb, se jobb ne legyen a kódom, csak más? Puszta programozói kivagyiságból? Csak azért, hogy élvezettel nyúlhassak hozzá és ne kelljen fintorognom az egy két hónappal ezelőtt írt szörnyszülöttem miatt? Miért nem írtam már meg az elején jól? Azért, mert én lennék a legszomorúbb, ha két hét múlva ugyanaz a programozó lennék. Ugyanazokkal a módszerekkel gyártanám az ugyanolyan kódot. Ekkor nem programozó lennék, hanem kisipari kódsegédmunkás.
Természetesen nem beszéltünk arról, hogy mi van, ha csapatban dolgozunk. Akkor ezek az igények hatványozottan jelentkeznek, hisz nehéz úgy közösen dolgozni, hogy mindenki csak a saját gondolatmenetének megfelelő kódot gyárt.

Egy ilyen refaktor hosszú távon nagy nyereséggel kecsegtet, de automata tesztek nélkül elképzelhetetlen, hogy ennek a munkának az ember nekilásson. Ezért is jó a menet közbeni tesztkódokat megőrizni, hisz nem kerül semmibe se (a kezdeti tanulási időszakon kívül természetesen), csak nyereségünk lesz belőle.

A harmadik lehetőség az, hogy egy hiba kijavítása után írunk egy rövidke kis tesztet, mely biztosítja azt, hogy a hiba megléte esetén jajveszékeljen a rendszerünk, míg a javítás utá szép csendben lefussanak a tesztek. Ez utóbbit használják elsősorban a Drupal hetes fejlesztése során.

Ezzel a módszerrel el lehet kerülni azt, hogy egy már, a rendszerbe bekerült hibajavítás onnan, valamilyen véletlen folytán kikerüljön, valamint csökkenteni lehet annak az esélyét, hogy egy hibajavítás újabb hibák garmadát generálja.

Amint láttuk, lehet a fejlesztés előtt, a fejlesztés alatt és a fejlesztés végén is használni ezt a módszert. Tapasztalt barátaim szerint azonban a fejlesztés utánra már semmi esetre sem érdemes hagyni, mert akkor nagyon nagy valószínűséggel csak egy frusztráló, kellemetlen hiányérzetünk lesz csak egy el nem végzett feladat után. Nem beszélve arról, hogy olyankor már tényleg csak nyűg lesz ez a feladat és semmi előnyét nem fogjuk élvezni.

Nézzünk meg, hogy a tegnapi kis próba modulomban én hogyan használtam a fent leírtakat.