Yii logo

Eddigi munkáim során nem éreztem igazán szükségét keretrendszer használatának.
A kívánt funkcionalitások megvalósításához vagy száz százalékig saját kódot, vagy valamely egyszerű cms megvalósítást használtam.
Tervezett, portál jellegű projektjeim megvalósítását azonban szerettem volna egy jól felszerelt, nagy teljesítményű
keretrendszerre alapozni.

A 2010-es év során rengeteg jót olvastam a yii-ről.
Kezdve attól, hogy a keretrendszert eleve nagy terhelésű webhelyek fejlesztésére tervezték, egészen addig, hogy több különálló technológia legjobb gyakorlatát valósítja meg.

Egy kis yii történet…

Egy meglehetősen fiatal keretrendszerrel van dolgunk, melynek első, 1.0-ás verziója 2008 decemberében látott napvilágot.

A yii atyja, Qiang Xue korábban a prado fejlesztőjeként dolgozott, így nem véletlen, hogy a két eszköz között rengeteg a
hasonlóság. A yii a prado-tól örökölte például a moduláris alkalmazás felépítést, a komponens alapú, esemény vezérelt programozási paradigmát, az adatbázis absztrakciós rétegeket, valamint jónéhány egyéb szolgáltatást is.

Mint azt a bevezetőben már említettem a yii bátran válogatott különböző, jól bevált technológiai megoldások közül.
A RubyOnRails-hez hasonlóan active record mintát használ az ORM (object relational mapping) megvalósításához. A jquery javascript könyvtár egy az egyben beépítésre került. A filtereket és a plugin architektúrát pedig a symfonytól lesték el a készítők.

Végső soron a yii személyében egy pehelysúlyú, jól dokumentált, kiválóan konfigurálható keretrendszert kapunk kezeink közé.
A telepítés rövid leírása után ismerkedjünk hát meg részletesebben a yii alapú alkalmazások felépítésével!

Telepítés

A yii telepítéséhez csupán a legfrissebb verziót szükséges letöltenünk és kicsomagolnunk webszerverünkre a
http://www.yiiframework.com/download
címről és indulhat is a móka!
Új alkalmazás létrehozásához nem kell mást tennünk, mint a parancssorból futtatni a következő ‘yiic shell’ parancsot:

[cc lang="css"]
% YiiRoot/framework/yiic webapp webroot/testdrive
[/cc]

Ezzel a yii létre is hozza nekünk a ‘testdrive’ névre hallgató alkalmazásunk vázát a szerverünkön.

Elkészült első yii alkalmazásunk

(Ha esetleg WAMP környezet esetén hibába botlanánk a parancs futtatásakor, vegyük fel a yiic.bat és a php.exe fájlok elérési útját a környezeti változók közé).
Ha ezen túljutottunk, vizsgáljuk meg az alkalmazások felépítését egy kicsit tüzetesebben!

Egy átlagos yii alkalmazás felépítése

A yii egy teljes mértékben objektum orientált keretrendszer, amely felépítésében a
DRY(don’t repeat yourself) fejlesztési módszert alkalmazza.

Yii alkalmazásaink a széles körben használt MVC architektúra alapján épülnek fel, ezzel megvalósítva az üzleti logika és a grafikus megjelenítés különválasztását.

Az MVC mellett azonban alkalmaz egy ún. front-controllert is, melyet kissé zavaró módon alkalmazásnak(application) hív.
Ez valójában egy singleton objektum, melyet a belépési script (index.php) a konfigurációs fájl
(testdrive/protected/config/main.php) beállításai alapján hoz létre és futtat a keretrendszer könyvtárában található
CWebApplication osztályból.

A front-controller hívatott kezelni a felhasználói kéréseket és tovább adni azokat a megfelelő controllernek.

Külön említést érdemel, hogy a main.php ‘components’ tömbjének konfigurálásával tudjuk változtatni az alkalmazásunkban használt komponensek tulajdonságainak értékeit. Ezért az application szolgál az alkalmazás-szintű konfigurációs változtatások eszközéül is.

Alapkönyvtára (base directory) a projektünk könyvtárszerkezetében található “protected” nevű mappa, melyen belül az érzékeny adatok (komponensek, modellek, controllerek, view-k) könyvtárai kapnak helyet.

Yii project könyvtárszerkezete (az alkalmazás mappája külön kiemelve)

A dokumentáció tartalmaz egy nagyon szemléletes ábrát az alkalmazás struktúrájáról, mely a
következőképpen néz ki:

Yii alkalmazás struktúra

Adatbázisok elérése

A yii több lehetőséget is biztosít adatbázisaink elérésére és a velük való munkára:

A DAO (database access objects) egy általános adatbázis elérési felületet nyújt (a php PDO kiegészítőjére alapozva), melynek segítségével egységes nyelvet teremt több relációs adatbázis használatához.
Így könnyen válthatunk közöttük anélkül, hogy alkalmazásunk nagyobb átalakítására kényszerülnénk.

A DAO által támogatott RDBMS-ek a következők:

• -SQLite
• -MySQL
• -PostgreSQL
• -SQL Server
• -Oracle

Lekérdezéseink megírásához a yii biztosít számunkra egy ún. query buildert, mellyel objektum orientált módon írhatunk adatbázis lekérdezéseket.

Bár a DAO nem a legegyszerűbb módja adatbázisaink elérésének, bonyolultabb adatbázisműveletek csak ezen keresztül

megvalósíthatók.
Továbbá kihasználhatjuk a PDO nyújtotta lehetőségeket: a parameter binding-ot és a tranzakciókat (ez utóbbiról az active record használata esetén sem kell lemondanunk).

Az egyszerű CRUD műveletek programozása azonban sokkal könnyebben megvalósítható AR (active record) osztályokkal, melyeket a yii az ORM (object relational mapping) megvalósítására használ, azaz minden AR osztály egy-egy adatbázis táblát képvisel, minden AR objektumpéldány a tábla egy-egy sorának, az AR osztály tulajdonságai pedig az oszlopoknak feleltethetők meg.

Természetesen a lehetőségeink így sokkal korlátozottabbak, mint DAO esetén (ezért bonyolultabb műveleteknél nem fogjuk megúszni annak használatát), azonban az AR esetén is használhatunk tranzakciókat utasítások csoportos futtatásához.

Kód generálás, scaffolding

Cikkem első részének végére hagytam a varázspálca bemutatását.

A yii rendelkezik egy Gii névre hallgató, rendkívül egyszerűen használható, konfigurálható és bővíthető kódgeneráló platformmal.
Ahhoz, hogy használhassuk a gii-t először fel kell vennünk a konfigurációs fájlban a modulok közé (csak távolítsuk el az előtte
található kommenteket).

[cc lang="php"]

return array(
……
‘modules’=>array(
‘gii’=>array(
‘class’=>’system.gii.GiiModule’,
‘password’=>’pick up a password here’,
// ‘ipFilters’=>array(…a list of IPs…),
// ‘newFileMode’=>0666,
// ‘newDirMode’=>0777,
),
),
);
[/cc]

A jelszó beállítása után a
http://localhost/projekt_mappa/index.php?r=gii url-en tudunk belépni a felületre.
Innen már néhány mező kitöltésével egyszerűen létrehozhatunk modelleket, controllereket, modulokat, view-kat (form), illetve CRUD controllereket is.

Egy model létrehozása a gii használatával

Egy model létrehozásához például elég csak a Model generator oldal “table name” input mezőjébe beírni a használt adatbázis nevét és a gii legenerálja nekünk az azonos nevű model osztályt a protected/models mappába.

Befejezésül

Írásom első részében igyekeztem nagy vonalakban bamutatni a yii php keretrendszer alapvető szerkezeti felépítését, az általa használt technikákat, kapcsolatát az adatbázisokkal, valamint a gii által nyújtott kódgeneráló szolgáltatásait.

A cikk következő részében bemutatásra kerülnek a yii további szolgáltatásai, mint a TDD támogatása, a többrétegű caching,
az i18n (internationalization) és az l10n (localization), sminkek témák és egyéb finomságok, természetesen a teljesség igénye nélkül.

Azok számára, akiknek sikerült felkeltenem az érdeklődését a keretrendszer iránt íme néhány hasznos link:

• yiiframework.com – hivatalos weboldal
• yiihun.blogspot.com – magyar nyelvű yii blog
• yiiradiio.mehesz.net – a yii radiio weboldala

Mi is az a sprite?

A sprite-ok gyakorlatilag olyan képfájlok, amelyek egységbe olvasztva tartalmazzák oldalunk különböző grafikai elemeit.
Célszerű az állandó, vagy gyakran visszatérő elemeket logót, menü hátteret, vagy ikonsort (akár “hover”-állapottal együtt)
belevenni.

Saját oldalam sprite képe.

Sokan azt gondolhatják, hogy nem is kell többé design-tervet szeletelni.
Természetesen ez nem így van! Sprite-jaink méretét is ésszerű keretek közt kell tartanunk. Nem járható út, hogy
weboldalunk egész grafikáját egy képként kezeljük.

Miért érdemes spriteokat használni?

A régi időkben bevett gyakorlat volt a weboldal design-ját minnél apróbb képekre szétvagdosni, ezzel biztosítva a gyors
oldalbetöltés illúzióját a megjelenítéskor.
A fent említett módszer valójában a teljes letöltési idő nagymértékű növekedését eredményezte, a következő okokból
kifolyólag:

- A weboldal teljesítményét nagyban befolyásolja a klienstől a szerver felé intézett http kérések száma. Ebben az esetben
minden egyes kép letöltése egy-egy újabb kérés elküldésével járt. Napjaink böngészői általában 4-6 párhuzamos http
kapcsolatot létesíthetnek egyszerre (a régebbiek csak kettőt tudtak), ez azt jelenti, hogy tíz kép esetén az első 6/4/2 töltődik
le (böngészőtől függően), majd ezek után következhet csak a képek fennmaradó része. Az így összeadódó válaszidők
nagymértékben növelik az oldal letöltési idejét.

- A sprite-ok mérete kisebb, mint a sok kisebb kép összesített mérete. Ez annak köszönhető, hogy csak egyszer kell
elküldeni, bizonyos képenként ismétlődő adatokat (színtáblákat, formázási információkat).

Egy egyszerű példa:

A sprite-ok hatékonyságát legegyszerűbb egy példán keresztül bemutatni. Az alábbiakban egy ikonsort állítunk be egy vízszintes lista elemeinek háttereként. Ez meglehetősen életszerűtlen igaz, de a célnak megfelel.

Egyszerű ikonsor külön-külön háttérképekkel:

(a kép csupán szemléltetés céljából szerepel, nem a példa valódi megvalósítása)

HTTP kérések száma: 5

Képek összesített mérete: 9,58 KB

CSS kód:

[cc lang="css"]
#icon_list li { float: left; width: 40px; height: 40px;}

#icon_one { background-image: url(“ikonsor1.jpg”); }
#icon_two { background-image: url(“ikonsor2.jpg”); }
#icon_three { background-image: url(“ikonsor3.jpg”); }
#icon_four { background-image: url(“ikonsor4.jpg”); }
#icon_five { background-image: url(“ikonsor5.jpg”); }
[/cc]

Egyszerű ikonsor sprite használatával:

Ebben az esetben elegendő csak egyetlen háttérképet beállítani és azt a background-position tulajdonság segítségével pozícionálni.

HTTP kérések száma: 1

Kép mérete: 7,48 KB

CSS kód:

[cc lang="css"]
#icon_list li { background-image: url(“ikonsor.jpg”); float: left ; width: 40px; height: 40px; }

#icon_one { background-position: 0px 0px; }
#icon_two { background-position: -40px 0px; }
#icon_three { background-position: -80px 0px; }
#icon_four { background-position: -120px 0px; }
#icon_five { background-position: -160px 0px; }
[/cc]

Példánkban a http lekérések száma 4-gyel, a kép(ek) mérete pedig 2KB-tal csökkent a sprite használatával (és még nem is állítottam be hover állapotot, ami plusz 5 lekérés lett volna az első példában).

Láthatjuk, hogy már egy ilyen egyszerű esetben is milyen számottevő a javulás mértéke, így azt is el tudjuk képzelni mekkora lehet a teljesítménynövekedés egy teljes weboldal esetén.
Érdemes lehet legalább saját weboldalunkon kipróbálni, nem fogunk csalódni!

Mások is használják!

Szinte minden, nagy terhelésnek kitett weboldal esetén találkozunk spriteokkal, íme néhány példa:

Css sprite-ok a nagy óriások oldalain

Változások a fejlesztés menetében

Használatuk természetesen bizonyos többletmunkával jár és kisebb-nagyobb változtatásokat követel jól megszokott fejlesztési módszerünkön is.

Egyesek azt tanácsolják, hogy először építsük fel az oldalunkat hagyományos módon, majd valamilyen külső eszközzel (mint
például a SpriteMe -spriteme.org- ) készítsünk sprite-ot az arra alkalmas képekből és ezek után dolgozzuk át a teljes oldalt.

Mások a sprite alapú sitebuildet ajánlják, már a fejlesztés kezdetétől.

Munkáim során volt “szerencsém” mindkét módszert kipróbálni és jómagam is a második megoldás mellett teszem le a
voksomat. Egy kis tervezéssel sok többletmunkától kímélhetjük meg magunkat.

Az elmúlt napokban kibertámadások következtében sorra omlottak össze olyan nagy cégek szerverei mint a PostFinance, a PayPal, a Mastercard, vagy a Visa (utóbbinak magam is szemtanúja voltam tegnap este), de hasonló sorsra jutott Sarah Palin republikánus politikusnő és az ügy számos egyéb érintettjének weboldala is.

Érdekes ügy ez, melynek forgatókönyve már-már egy sci-fiére kezd emlékeztetni. A “miértek” meglehetősen tisztázatlanok, a “hogyan”-ok viszont annál látványosabbak. A szerepek tényleg hollywoodot meghazudtoló módon körvonalazódnak…

A Gerillák:

Történetünk lázadói a magukat rendkívül fantáziadús módon Anonymousnak nevező csoport, amely laza kötelékekből áll és folyamatosan, szabadon szerveződik újra és újra.

Hadműveleteiket az “Operation payback” fedőnevet viselő akciósorozat égisze alatt hajtják végre.

A vicc az egészben annyi, hogy minden hírcsatornán félelmetes hacker-ként aposztrofálják őket (ezt a valódi hackerek rendkívüli módon sérelmezik is), pedig ahhoz amit csinálnak semmilyen magas szintű informatikai képzettségre, extra számítógépes ismeretre nincs szükség.

Pont ez jelenti a mozgalom erejét, hogy bárki, akinek kedve szottyan beállhat néhány órára online Che Guevarásat játszani, de erről még majd később…
Most nézzük a szemben álló felet!

A Hatalom:

Mint az a híradásokból is kiderül, a hatalom legfőbb megtestesítője
- ez esetben is – maga az Egyesült Államok kormánya. A harcszíntéren azonban itt sem ők vannak leginkább a porondon, hanem a hozzájuk lojális “szövetséges” multicégek.

Elsőként itt van például az árulónak kikiáltott amazon.com, amely kormányzati intésre “kihúzta” a szerverparkot a wikileaks alól, valamint az ismert kártyatársaságok, melyek megtagadták az oldalnak szánt adományok átutalását. Ne felejtsük ki a sorból a szervezet számláját befagyasztó svájci PostFinance bankot sem!

Természetesen az elsőre hezitáló, a szólásszabadság zászlaját lobogtató közösségi oldalak is kihátráltak, engedve a felülről érkező erősödő nyomásnak.

A Harcmodor:

Mint már említettem az Anonymous sikere abban áll, hogy egy rendkívül primitív támadásfajtát valósítottak meg, meglehetősen “felhasználóbarát” módon.

A technika neve DDoS (Distributed Denial of Service), azaz elosztott szolgáltatás-megtagadás, amely az ún. flooding (elárasztás) típusú támadások közé tartozik.
Röviden annyiról szól, hogy távoli gépekről egy időben kezdik tömeges HTTP kérésekkel, vagy TCP/UDP csomagok küldésével túlterhelni a célpont szervereit, így azok megfelelően nagy támadás esetén megtagadják a szolgáltatást, magyarul összeomlanak.

A DDoS ilyen formában történő alkalmazása ugyanakkor az egyik legkevésbé kártékony támadástípus. Nem irányul közvetlenül információszerzésre, vagy a pénzügyi szolgáltatások akadályozására, csupán a weboldalak ellen használják.
Így megnyugodhatnak azok is, akik banki átutalásaik biztonságáért kezdenének aggódni!

Ne higgyük azonban, hogy csak az Anonymous él a fent említett eszközökkel! Több hírforrás beszámolói szerint az amerikai kormányzat ugyanilyen módszerekkel blokkolta a wikileaks által nyilvánosságra hozott adatok hozzáférhetőségét az előző hetekben. Ezt persze tovább erősítette az is, hogy a botrány hatására rengetegen akarták letölteni a dokumentumokat.
Magam is megpróbáltam, de a letöltési linkre kattintva a rendszer nálam is túlterheltségre hivatkozott.

A Csodafegyver:

Végére hagytam magát a “csodafegyvert”, amely elengedhetetlen a támadások végrahajtásához.

Az eszköz a LOIC (Low Orbit Ion Cannon – Alacsony Röppályás Ion Ágyú) névre hallgat
(ez aztán tényleg leveri a biztosítékot minden sci-fi rajongónál) és hivatalosan hálózatok terhelés-tesztelésére fejlesztették ki.

Forráskódja C# nyelven íródott és bárki számára nyilvánosan elérhető, letölthető például a Github, vagy a Sourceforge kódmegosztó oldalairól is.
A telepítést követően megadhatjuk a kívánt terhelés típusát, intenzitását és természetesen a “tesztelni” kívánt webhely URL-jét.

Az igazán ördögi és már-már ijesztő megvalósítás azonban a JS LOIC nevű változat (nevében a JS a JavaScriptet jelenti).
Ez gyakorlatilag egy webalkalmazás, amely mindenféle telepítés nélkül, online elérhető és szinte egyetlen kattintással aktiválható.
Egy kisiskolás is könnyű szerrel tudja kezelni,
azonban használatára senkit sem biztatnék!

A következő epizódból…

A cikk írása során folyamatosan érkeznek hírolvasómra azok az üzenetek, melyek egy OpenLeaks nevű ellenoldal tervezett elindításáról számolnak be.
Az oldal folytatni kívánja a wikileaks “hagyományokat”, viszont
elmondásuk szerint, az eredetileg tervezett, felelős formában.
A website alapítói Assange volt munkatársai, akik úgy gondolták, hogy vezérük vezetési stílusa nem szolgálja a webhely eredeti céljait.

Tudatos ellenintézkedésről van szó, vagy csak meg szeretnék lovagolni a témát övező felhajtást? – mindenki döntse el maga.
Én mindenesetre kíváncsian várom a fejleményeket!

Első benyomás…

Első pillantásra.., várjunk csak!
Először még be kell jelentkeznünk a facebook fiókunkba, hogy elinduljon!
Ha ezzel megvagyunk, első pillantásra olyan, mintha egy felturbózott google Chrome-ot kaptunk volna, pluginokkal telepakolva a képernyő két oldalán.

Nem véletlenül, a RockMelt ugyanis a google Chromium 7-es böngészőprojektjére épül. Kíváncsi vagyok, hogy a külcsínyen változtatnak-e a végleges változatban, vagy marad a chrome életérzés.
Azért bevallom, nekem ez az egész megjelenés így összességében kissé olcsónak hatott.

Mi lehet a cél?

Az emberben akaratlanul is felmerül a kérdés, hogy mennyire gondolják komolyan ezt a dolgot. Valóban részt kívánnak majd venni a böngészők között dúló, amúgy is kiélezett harcban, vagy “csupán” azokat fanatikus felhasználókat kívánják megszólítani, akik a neten töltött idejük 90%-ában a facebookon lógnak.
Esetleg még mindig az oldalt övező (már-már csillapodni látszó) felhajtásban bíznak, “félmilliárd felhasználó nem tévedhet” alapon.

Instant facebook?

Mint már említettem a RockMelt beépítve megvalósítja az anyaoldal (érdekes ezt így leírni) legfőbb, nélkülözhetetlen funkcióit. A baj csak az, hogy egyenlőre elég döcögősen.

A baloldali oldalsávon sorakoznak bejelentkezett ismerőseink profilképei, majd alattuk az offline lévők abc sorrendben.
Legfelül található saját képünk, melyre kattintva a chat-ablakot hívhatjuk elő.
Jobboldalon pedig az üzenőfal, profil oldalunk és egy külsős funkció a twitter csatorna érhető el. Valamint bővíthető egyéb hírcsatornákkal is, de erről még majd később.
A harmadik fontos tartozék az állapotsor és a meglehetősen nagyra sikerült keresősáv között elhelyezkedő megosztás gomb, melynek segítségével egyetlen gombnyomással közzétehetjük az éppen böngészett oldal url-jét üzenőfalunkon.

Mindez szép és jó, de a megvalósítás azért kívánni valókat hagy maga után. Legfőbbképp a szinkron hiányzik a böngésző és maga a facebook között.
Meglehetősen nagy csúszásban van az oldal üzenőfalához képest a RockMelt üzenőfal csatornája (amely természetesen minden “fontos” történésről beszámol nekünk).
A kijelentkezés is problémás, külön-külön valósul meg az oldalon és a böngészőben. Ez még nem is lenne annyira zavaró, de ha a böngészőn belül váltunk offline-ra, akkor bezárja az összes megnyitott oldalunkat.

Az egyik hírportál leírásában olvastam, hogy a RockMelt szakít a Chrome által használt “egy ablak, két funkció rendszerrel”, vagyis nem az állapotsort használja beépített keresősávként. Tapasztalataim szerint ez nem teljesen így van.
Bár az állapotsorba történő begépelésnél az autosuggest először az ismerőseink között keres (kb. az első két betűig), az enter lenyomása után, amennyiben nem létező url-t adtunk meg, automatikusan a google találati oldalára repít minket. Ugyanez történik a keresősáv használatakor is. Utóbbinál azonban jópofa megoldás, hogy a keresési eredmények egy keskeny felugró ablakban jelennek meg és nem nyit automatikusan új lapot nekik

Biztos lehetne még érdekességeket felfedezni a RockMelt közösségi funkcióinak működésében, de ezt meghagyom azoknak, akik nálam sokkal otthonosabban mozognak a fent említett oldalon.

Like-ok és dislike-ok:

Természetesen a böngésző, tartalmaz apró újításokat a facebook integráción kívül is. Ezek között léteznek szerethetőbb és kissé zavaróbb megvalósítások is.

Jó ötletnek tartom például a jobb oldali sáv kihasználását rss hírcsatornák számára. Különösen tetszik, hogy automatikusan felajánlja a könyvjelzőinkben szereplő oldalak csatornáit megnyitásra.
Az oldalsávok eltüntetésének módját azonban tehették volna egyértelműbbé is, mivel 1024×768-as felbontás esetén (az oldalsávokkal csökkentett szélesség miatt) gyakran vízszintesen is kell görgetnünk.
Sz.v.sz. használhattak volna valamilyen automatikus megjelenés funkciót is alapértelmezettként. Így azonban marad a főmenü, vagy a jobbklikk menü a kikapcsoláshoz.

Valamint meglehetősen idegesítő, hogy minden oldal megnyitásakor felugrik a nyelvválasztó ablak. Igaz ez a “never translate hungarian” gombbal kikapcsolható, így nem is sorolnám a tényleges negatívumok közé. Másik apróság, amit már a Chrome esetében sem értettem, hogy miért nem lehet a könyvjelző eszköztáron fordított időrendi sorrendben feltüntetni a könyvjelzőket? Én így gondolnám logikusabbnak.

Teljesítmény.

Nem vetettem alá a RockMelt-et tüzetesebb tesztelésnek, csak néhány sunspider tesztet futtattam rajta, majd ugyanezt elvégeztem egy mezei google chrome-on is.
A tesztek eredménye nem volt túl meglepő. Egyszer egyik, másszor a másik teljesített hajszálnyival jobban, de nagyságrendileg hasonló időket produkáltak.

Összegzés

Összességében elmondhatom, hogy kissé többet vártam a facebook böngészőjétől.
Különösen az alapján, hogy a projekt mögött a legendás mosaic és netscape böngészők atyja Marc Andreessen áll.
Bevallom naiv módon valamilyen kreatív megjelenésben, kezelőfelület megvalósításban reménykedtem, így kissé csalódott vagyok a látottak alapján.
Ugyanakkor, még ha személyesen nem is éreztem késztetést, hogy alapértelmezett böngészőnek állítsam be, biztos vagyok benne, hogy amennyiben kijavítják az apró buktatókat és sikerül tényleg szinkronizálni a site-tal, akkor a facebook célközönségének nagy részét
tehetik elkötelezett felhasználóikká.

Végső soron pedig ne felejtsük el, hogy egyenlőre csak egy bétával van dolgunk, így még rengeteg dolog megváltozhat a végleges kiadásig. Mindenesetre kíváncsian várom a folyatatást!

Korábban már többször olvastam különböző írásokat a verziókezelésről (sőt, próbálkoztam is a Tortoise SVN-el), de úgy gondoltam, hogy erre csak azoknak a fejlesztőknek van szükségük akik nagy projekteken, vagy komplett szoftverek fejlesztésén munkálkodnak, általában egy fejlesztői csapat tagjaként. Tévedtem.
Visszatekintve látom, hogy mennyi fejtöréstől és másolgatástól kímélhettem volna meg magam, ha már a kezdetektől fogva egy ilyen rendszert használok.

A verziókövetésre rengeteg kiváló megoldás létezik. Az én választásom a Git-re esett, melyet a későbbiekben egy cikksorozat formájában bővebben is bemutatni szándékozom.
Jelen írásomat mintegy kedvcsinálóul szánom azoknak, akik szeretnék könnyen és átláthatóan kezelni kódállományukat és még nem kötöttek közelebbi barátságot egyik VCS-sel sem.

Mi is az a verziókezelés?

A név magáért beszél. A wikipédia leírása szerint:
“Verziókezelés alatt több verzióval rendelkező adatok kezelését értjük.”
A cél gyakorlatilag az, hogy lehetővé tegyük a programunk korábbi verzióihoz való visszatérést és elejét vegyük a csapatban történő fejlesztés során adódó fejetlenségeknek.

A legegyszerűbb és egyben legkevésbé hatékony verziókezelési technika (melyet bevallom sokáig én is használtam) az, ha kódjainkat minden nagyobb változtatás előtt egy-egy külön mappába mentjük és ezeket próbáljuk megfelelően megkülönböztetni.

Hamar rá kellett döbbennem, hogy ez az út csak addig járható amíg csupán egy-két dédelgetett projektünk van.
Idővel, nehézkessé vált megjegyezni a tartalmi különbségeket az egyes verziók között, nem is beszélve a hatalmas tárterület használatról.

Természetesen a verziókezelő rendszerek többek közt a fent említett problémákat hivatottak orvosolni.

A koncepció dióhéjban:

Napjaink verziókövető szoftverei különböző megvalósításokat alkalmaznak az verzió-előzmények hatékony tárolása és a munkafolyamatok zökkenőmentességének biztosítása érdekében.
Az alapkoncepció viszont mindegyiknél hasonló. Az alábbiakban a verziókezeléssel kapcsolatos alapfogalmakat tekintem át:

A tároló (repository):

A verziókezelők projektünk aktuális verzióját és annak előzményeit külön erre a célra használt tárolókban (repository) raktározzák el.

A munkamásolat (working copy):

A kód egy részének (általában egy adott) példánya, amelyen a fejlesztő éppen dolgozik a saját gépén.
A munka befejeztével ennek állapota kommitok formájában tárolásra kerül a repositoryban.

Kommitok:

A kódunkon történt legfrissebb változtatásokat úgynevezett kommitok formájában érvényesíthetjük a tárolókon belül, melyek mintegy pillanatképként tartalmazzák azokat, illetve projektünk aktuális állapotát.

Ha zsákutcába futnánk fejlesztés közben, akkor ezek alapján kereshetjük vissza kódunk korábbi verzióját. Ezért célszerű minden nagyobb módosítást követően kommitolnunk.

A fejlesztési történet (development history):

Az adott projekt kommitjainak összességét értjük alatta, az első (initial commit) kommittól kezdve az utolsóig (head commit).

Checkout:

A módosítani kívánt fájlok lekérése a repositoryból ún. checkoutok formájában megy végbe. Ezekre még a későbbiekben visszatérek.

Pushing:

Adatok feltöltése a központi repository-ba.

Fetching:

Adatok lekérése a központi repository-ból.

Fejlesztési ágak (branch-ek):

Lehetőségünk van ún. fejlesztési ágak
létrehozására is, ha projektünket esetleg a tervezettől eltérő irányban is szeretnénk továbbfejleszteni. Valamint az eredeti verziót érintetlenül hagyva tudunk kísérletezni.

Összefésülés (merging):

A fejlesztési ágak létrehozása mellett lehetőségünk van ezek egyesítésére is. Ennek folyamatát összefésülésnek (angolul: merging)nevezik.

Rendszerek közti eltérések:

Természetesen az egyes rendszerek más-más módon valósítják meg a fent említett komponenseket és eljárásokat.
Léteznek központosított és elosztott verziókövető rendszerek. Az alábbiakban megkísérlem nagy vonalakban bemutatni ezek működésbeli sajátosságait.

Központosított verziókövető rendszerek:

A centralizált rendszerek, mint pédául a Subversion egy központi tárolóban (repository), valamilyen adatbázis segítségével (a Subversion esetében ez BerkeleyDB vagy FSFS) tárolják valamennyi kódunk történetét.

A tároló lehet egy távoli szerveren, vagy akár a saját gépünkön is.
Amennyiben csapatban fejlesztünk az első eset gyakoribb.

A központosított rendszerekre jellemző munkafolyamat, hogy a teljes kódállomány csak a repositoryban található meg
(centralizált workflow). A fejlesztők innen kérik le (checkout) a módosítandó fájlokat. Majd a munka végeztével összefésülik a munkapéldányt a tárolón belül találhatóval. Ez az ún. lemásolás – módosítás – összefésülés ciklus.
A subversion leellenőrzi, hogy nem áll-e fent konfliktusveszély a pusholni kívánt munkapéldány és a tárolóban található adatok között. Azaz, hogy az adott fájlt nem módosította-e valaki más, miután mi lekértük. Ebben az esetben ugyanis felülírnánk az ő módosításait a sajátunkkal. Ilyen helyzetekben jelentkezik a verziókezelők csoportmunkát koordináló szerepe.

Sajnos tárterület használat szempontjából ez a módszer sem túl hatékony (egyes mérések szerint 30x több merevlemezt használ a projektek tárolására mint a Git), ugyanakkor megvan az az előnye, hogy részleges lekéréseket (ún. partial checkout) folytathatunk. Azaz ha például csak egyetlen fájlon kívánunk módosításokat végezni, nem kell letöltenünk az egész repository-t, elég csak az aktuális fájlt tartalmazó almappát. Itt gyorsan szeretném azt is megjegyezni, hogy egy teljes Git repository mérete gyakran kisebb mint egyetlen svn checkout-é.

Elosztott verziókövető rendszerek:

A fent említett rendszerek nagyban különböznek központosított társaiktól.

Az elosztott szerkezet alapján itt minden fejlesztő rendelkezik a repository egy-egy teljes másolatával, amely a munkapéldánnyal azonos mappában helyezkedik el. Ez jelenti ezen rendszerek igazi erejét.

Nagyban növeli a műveletek végrehajtásának sebességét, mivel szinte mindegyik (a push és a fetch kivételével) csak a lokális repositoryval kell, hogy kommunikáljon.
Valamint megszűnteti a központi meghibásodás veszélyét, mivel a központi repository meghibásodás esetén bármely lokális munkapéldánnyal egyszerűen pótolható.

Elosztott verziókezelő használatával a munkafolyamatok felépítése is számos formát ölthet.
A központosított munkafolyamaton kívül felállíthatunk fejlesztői hierarchiákat is a csapaton belül.
Ilyen például az integrációs menedzser workflow, ahol egyetlen fejlesztőnek (ő lesz az int. menedzser) van csak joga a központi repository-ba kommitolni. A többiek mind a saját különálló tárolójukba pusholnak, innen húzza át az integrációs menedzser a kommitjaikat a központi repóba.

Egy kis Git történet…

A Git Linus Torvalds, a Linux atyjának nevéhez fűződik, melyet eredetileg a linux kernel verzióinak kezeléséhez fejlesztettek ki.

Eredetileg BitKeepert használtak erre a célra, de mivel az időközben fizetőssé vált Linus egyéb, ingyenes alternatívák után kezdett kutatni. Azonban az akkori megoldások közül egyik sem felelt meg az elvárásainak, így saját verziókezelő fejlesztésébe fogott.

Így született meg a Git, ami gyors, elosztott rendszerben történő verziókövetést tett lehetővé, különös figyelmet fordítva a nem lineáris fejlesztés (branchek) támogatására.

Miért pont a Git??

Hazudnék, ha azt állítanám, hogy választásom során nem játszott szerepet az a nemzetközi hájp, ami a Git körül kialakult az utóbbi időkben (azt hiszem ez nem csak nekem tűnt fel). Nem szoktam ész nélkül “divatot” követni, valamint nem szeretnék ítélkezni egyik vagy másik rendszer felett sem (már csak azért sem mert nem rendelkezem igazán releváns tapasztalattal használatuk során), egyszerűen csak úgy éreztem, hogy tényleg a Git a legmegfelelőbb választás számomra.

Emellett rengeteg kiváló tulajdonsága van, nem csak a központosított verziókezelőkkel , hanem elosztott társaival szemben is.

A cikksorozat következő részében ezen tulajdonságokról fogok bővebben szót ejteni, hogy miért is érdemes igazán a Git-et választani.
Elöljáróban szerepeljen itt néhány fontos szempont:

• - Rendkívül gyors
• - Minden lokákis
• - Helytakarékos
• - Staging area a kommitok összeállításához
• - Tetszőlegesen szervezhető workflow

Természetesen a lista koránt sem teljes, de erről majd a következőkben…

Magam és referenciáim bemutatása mellett régóta dédelgetett tervem valósul meg saját fejlesztői blogom elindításával.
Ennek keretein belül, heti egy (esetleg több rövid) bejegyzés beküldését tervezem.

A szakmai írások mellett egy személyes kategória is helyet kapott a blogban, ide kerül majd minden egyéb dolog amit érdemesnek tartok megosztani a világgal.

A webhelyen belül külön oldalt szenteltem a Gyakran Ismétlődő Kérdéseknek(Gy.I.K.), melyek újra és újra felvetődnek munkáim során. Valamint helyet kapott a szokásos “kapcsolat” és “magamról” oldalak mellett egy kis fotógaléria, és az általam olvasott könyvek listája (“könyvespolc”) is.

Kellemes böngészést kívánok mindenkinek!