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.

Egy hét Drupal 7: Az entitásról

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.

Első körben beszéljünk az entitásokról.

A Drupalban eddig mindenki tudta, hogy ha tartalom kezelésről volt szó, akkor azt a legkönnyebben a nodeok segítségével tudta megoldani. Az elgondolás lényege az volt, hogy adott a node, melyet a különböző modulok adatelemekkel és funkciókkal tudnak bővíteni. Ez nagyszerű volt, hisz ha volt egy oldal típusú tartalmam, vagy egy hír típusú, akkor ha az egyikhez megírtam a hozzászólás funkciót akkor az a másikkal is működött. Csak arra kellett figyelnem, hogy ezt úgy tegyem meg, hogy azt a típus nélküli nodehoz írjam meg. Ettől fogva a hírhez is és az oldalhoz is hozzá tudtam szólni, hisz mindkettő node volt. Sőt, amennyiben létrehoztam egy új tartalom típust, mondjuk képet, vagy képgalériát, akkor már azokhoz is igénybe vehettem ezt a nagyszerű szolgáltatást.

Azonban, maradt számos olyan tartalmi elemem, melyek nem voltak nodeok. Ilyenek voltak a kategóriák, a hozzászólások, felhasználók stb. Amennyiben ezekhez is igénybe kívántam venni azokat a szolgáltatásokat amiket a nodeokhoz kidolgoztak, trükköznöm kellett.
(Ilyen szolgáltatás volt például az, hogy az adott tartalmi elemhez újabb mezőket adjak hozzá, vagy megjelenítsem egy listában. Vagyis a CCK és Views modul)

A legalapabb trükk az volt, hogy az adott adatelemből nodeot gyártottunk. Ezzel aztán meg is oldottuk a problémánkat. Amennyiben társkereső oldalt akartunk készíteni, semmi más dolgunk nem volt, mint feltenni a Usernode(4.7.x, 5.x), vagy Content Profile(6.x) modulok egyikét. Ekkor minden egyes felhasználóhoz létrejött egy megfelelő típusú node. Semmi mást nem kellett tennünk, mint felvenni egy újabb CCK választó mezőt, melyben bejelölhették a delikvensek, hogy ők a focit szeretik vagy a baseballt és egy ügyes views lista segítségével már egymásra is találtak.

Azonban bármilyen szépen működött is ez a dolog, volt pár árnyoldal.

Először is, mivel két külön adattáblába, két külön modul írogatta azokat az adatokat amelyeket egy táblában kellett volna tárolnunk, igen magasra szökött az inkonzisztencia veszélye. Keletkeztek olyan felhasználók, akikhez nem tartozott node és keletkeztek olyan user nodeok, amikhez nem tartozott felhasználó. Amennyiben nem figyeltünk oda, könnyedén létrehozhattunk egy felhasználóhoz több tartalmat is. Egyszóval, volt egy olyan szuper bárhogyan konfigurálható rendszerünk amihez igazából jobb volt, ha nem nyúltunk hozzá.

A másik probléma ezzel a megoldással, hogy ha kevés hírünk volt, de sok felhasználónk, akkor is keményen dolgozott az adatbázisunk, hisz a hírek megjelenítéséhez először ki kellett szűrnie a felhasználókat az adattáblából és csak utána tudta rendezni és kilistázni a híreinket. Amint egyre több és több felhasználónk lett, úgy lett egyre nehezebb és nehezebb kilistázni a híreinket.

A „Csináljunk mindenből nodeot” megoldásnak ezen felül még volt egy árnyoldala. A node számos olyan frankó funkcióval rendelkezett, amire nem minden esetben lett volna igényünk. Ilyen szolgáltatások voltak azok, hogy egy node az verziókezelt, lehetett tudni melyik tartalmat melyik felhasználó látta már, lehetett szabályozni különböző szempontrendszerek szerint, hogy mely tartalmat mely felhasználó nézhess stb. Egyszóval számos olyan, ami egy tartalom kezelésekor jól jött de nem igazán volt szükségünk akkor erre, ha mondjuk felhasználókról, vagy csoportokról volt szó.

Drupal hetesben bevezetésre került az entitás fogalma, melyet egy node feletti egységként kéne elképzelni. Így lehetővé vált az, hogy a megvalósítani kívánt funkcióknál eldönthessük, hogy az melyik tartalmi szinten lesz számunkra érdekes. Ezek egy részét ráadásul az entitás létrehozásakor mi magunk is szabályozhatjuk. Pl. azt, hogy lehessen-e hozzá mezőket kapcsolni vagy legyen-e verziókezelt.

Minden entitásnak vannak olyan altípusai – úgynevezett bundle –, melyekhez a FieldAPI segítségével különböző mezőcsokrokat kapcsolhatunk. A node-nál ez a node típus, a kategóriáknál a szótár a felhasználóknál meg a ... hopp és itt a rés a pajzson, mert nincsenek a felhasználónak altípusai. Természetesen, nem lenne Drupal a Drupal, ha nem lenne egy alter hook amivel ne lehetne ezen a szörnyű helyzeten is változtatni.

De ne szaladjunk ennyire előre, ezt majd a workshopon. Készítsünk egy olyan Drupal 7 modult, ami egy olyan pehelysúlyú tartalmi elemet – egy entitást – valósít meg, mely semmi más mint egy darab táblában egy darab mező. Nézzük az én megoldásomat!

Logikus

Még mindig vannak dolgok amik bár logikusak mégis nem teljesen egyértelműek a számomra, ha PHP-ról van szó. Ránézel, kipróbálod, meglepődsz, végiggondolod és a fejedre csapsz, hogy "Logikus!!"

  1. function e($a) {
  2. $a++;
  3. }
  4.  
  5. function f(&$a) {
  6. $a++;
  7. }
  8.  
  9. function d($var) {
  10. print_r($var);
  11. print '<br />';
  12. }
  13.  
  14. $a = 1; d($a); // 1
  15.  
  16. e($a); d($a); // 1
  17.  
  18. call_user_func('e', $a); d($a); // 1
  19.  
  20. call_user_func('e', &$a); d($a); // 2
  21.  
  22. $f = 'e';
  23. $f($a); d($a); // 2
  24.  
  25. $f(&$a); d($a); // 3
  26.  
  27.  
  28. $a = 1; d($a); // 1
  29.  
  30. f($a); d($a); // 2
  31.  
  32. call_user_func('f', $a); d($a); // 2
  33.  
  34. call_user_func('f', &$a); d($a); // 3
  35.  
  36. $f = 'f';
  37. $f($a); d($a); // 4

Természetesen vannak olyan dolgok amik nem mennek, mert miért is mennének.

  1. $f = 'echo';
  2. $f('hello');

Ennek a kimenete az lesz, hogy nincs "echo()" függvény. Persze, hogy nincs, hisz az echo az egy nyelvi elem mint pl. a "for". Logikus!

Bemutatkozik a Skinr modul

Mivel a legutóbbi DUGon tartott előadásomat többen szerették volna megnézni felvételről ezért úgy döntöttem egy online közvetítés kíséretében megismétlem. Remélhetőleg sikerül majd felvételt készíteni az eseményről, így az is meg tudja tekinteni majd, aki az adás időpontjában nem tud felkapcsolódni a netre.

Időpont: 2010 december 1. szerda 18:00
Helyszín: Otthoni kényelmes karosszék és kapcs ford a Tanárúrkérem TV-re

Drupal Hétvége szervezői szemmel

Drupal Hétvége jegyzetfüzetét először fogom a kezembe.Remélhetően egyre többen leírják majd mi tetszett nekik a Drupal Hétvégében, milyen új információval lettek gazdagabbak és milyen gyümölcsöző, friss kapcsolatokra tettek szert rendezvényünkön. Én most arról szeretnék írni, hogy egy szervező szemével milyen volt a rendezvény.

Mindenekelőtt szeretnék köszönetet mondani mindazoknak, akik részt vettek valamilyen módon a szervezésben. Munkájukról felesleges szuperlatívuszokban beszélném. Nincs rá szükség. Elég csak arra a tényre hivatkoznom, hogy a kérdőívünk kitöltőinek a száz százaléka válaszolt pozitívan az „újra eljönnél-e” kérdésünkre.

Na de szaladjunk vissza az időben, hisz egy rendezvény szervezése mindig jóval előbb kezdődik, mint ahogyan azt bárki is gondolná.

Használhatóság világnapja

Zseniális volt. Röviden ennyit tudnék mondani. Nagyszerű előadások, jó előadók. Pörgős, szép ívű program. Pónya Judit és Rung András (valamint a többi szervező) kitett magáért.

Az ív megrajzolásában nagy szerepet játszott Polgár Péter Balázs előadása, melyben azt taglalta a használhatóság mint fogalom milyen tág értelemben értelmezhető. Felhívta a figyelmet arra, hogy az előadók bár különböző területeken dolgozva különböző megnevezéseket használnak a különböző fogalmakra azért mégiscsak egy dologról beszélnek.

Eztán belelendültünk. Judit a felhasználó oldalát, szempontjait mutatta be. Arra a kérdésre adta meg a választ, hogy miért fontos a felhasználónak a usability. Utána Vecsei László a másik oldalt, az üzleti szempontokat taglalta. Mindkét előadás adott olyan újdonságokat a számomra, melyekért már érdemes volt elmenni a rendezvényre.

A szünet előtt András mutatta be, mennyire hatékony tud lenni egy használhatósági vizsgálat és milyen gyorsan hozhatja akár a forgalom megduplázódását is. Kár, hogy nem készült róla videó felvétel, mert ütős marketing anyag tudott volna lenni bármely ilyen témával foglalkozó csapat számára, ha el kell adni az ügyfélnek a szolgáltatását.

A szünet után Herendy Csilla osztotta meg velünk tesztelési tapasztalatait, majd Fehér Katalin az online közösségek munkára fogásáról beszélt. Talán felesleges ismételnem, hogy ezek az előadások is, mint szinte mindegyik ezen a napon, olyan kulcs információkat, gondolat ébresztő ötleteket tartalmazott amik az aha élményt(nem a popegyüttes, az a-ha) adták.

A két prezis előadó Laufer László és Udvardy Dávid szintén kitett magáért. László konkrét példákon keresztül mutatta be hogyan fejlesztették a prezi felhasználói felületét. Megtudhattuk hogyan derítették fel és javították ki a hibákat.

Az utolsó előadásban Almásy Csilla gerincgyógyász arról beszélt, hogy a megfelelően kialakított, vagyis felhasználóbarát munkakörnyezet nem csak kényelmi, hanem egészségügyi szempontok miatt is fontos.

Sajnos el kellett rohannom, így a gyümölcsöző eszmecserékre már nem tudtam maradni.

Mindent összevetve köszönettel tartozom a szervezőknek, hogy összehozták ezt a nagyszerű délutánt!

Érdekel a Drupal? Itt a helyed!

Ha csak érdeklődsz a Drupal iránt és a Program áttekintése után bizonytalan vagy kérlek feltétlen olvasd le ezt a bejegyzést! A programot ugyanis úgy állítottuk össze, hogy a rendszert egyáltalán nem ismerő érdeklődők rengeteg új információval lehessenek gazdagabbak.

Minden előadás nagyszerű lesz, én most igyekszem azokat kiemelni amik az érdeklődők, a Drupallal ismerkedni vágyók számára lehet fontos.

Oldalak