‹Webakadémia /› » webfejlesztés

Tanulni, tanulni, tanulni

Bártházi András — Tue, 06 Dec 2011 14:23:15 +0000

Sikerült úgy alakítanom a szabadságaim, hogy szinte teljes decemberben szabadságon leszek. Unatkozni nem fogok, mert hamarosan megszületik második gyermekünk, és már csak emiatt is van itthon segíteni való a születés előtt is, utána pedig pláne (január legelejére vagyunk “kiírva”, de hetekkel előbbre várjuk a kissrácot). Emellett azonban úgy gondoltam, hogy egy komolyabb tanulást is lenyomok decemberben, amennyire időm engedni fogja majd.

A folyamatos tanulás egy jó webfejlesztőnél életmód jelleggel működik, a terveim viszont most egy igen intenzív hónapról szólnak. Szeretném elsajátítani az iOS/Mac fejlesztést úgy, hogy komoly programokat is le tudjak tenni az asztalra, és a Symfony 2-től a JavaScripttel kapcsolatos újdonságokig szeretnék további mély ismereteket összeszedni. A célok között szerepel az is, hogy kialakítsak egy olyan felállást, mely biztosítja azt, hogy a jövőben több tanulásra legyen lehetőségem a munka mellett is.

A kérdés, hogy milyen módon lehet a legtöbb tudást összeszedni? Úgy döntöttem, hogy első körben több tucatnyi órányi videóanyag megnézésével, és feldolgozásával fogom kezdeni.

iOS/Mac fejlesztés

Tősgyökeres webfejlesztőként érdekes nézőpontváltást jelent a mobil/desktop vonal felfedezése. A napi szinten is használható tudás elsajátítása melett pont egy ilyen teljesen új nézőpont meglépése is a célom, amitől azt várom, hogy más szemmel fogok tudni utána tekinteni a webfejlesztésre is. Az iOS/Mac fejlesztéshez az Objective C elsajátítása az első lépés, melytől egy kis C-s tudás megszerzését is várom, illetve az OO programozásban egy előrelépést.

Első blikkre az Objective C szintakszisa elég gáz (“szokatlan”), de sikerült felidéznem magamban azt az időszakot, amikor a Mac-kel ismerkedtem, és jópár dolog itt is “stevejobsi” módon idegen volt a Windows/Linux felől érkezve. Ahogyan akkor is pár nap / hét alatt sikerült túllendülni a szokatlanságon, most is így voltam vele, és még csak belekezdtem a tanulásba, de máris kezd tetszeni az egész környezet, és a nyelv lehetőségei.

Úgy látom, hogy a Delphivel szerzett tapasztalataim is segíteni fognak, az Xcode fejlesztés egyáltalán nem áll messze a több, mint tíz éve porosodó desktopos tapasztalataimtól. Abban az időszakban nem igazán sikerült semmi maradandó desktoposat letennem az asztalra, és nem is ezt, hanem a webfejlesztés irányt választottam, így a “komoly programokat is le tudjak tenni” nem kis kihívásnak tűnik.

Ígéretes anyagnak tűnnek az iTunes University-n fellelhetőek, ezek közül is a kiemelkedik a Stanford University-n tanító Paul Hegarty kurzusa, mely jelenleg is zajlik, s folyamatosan kerülnek fel az anyagok. Nagyságrendileg alapból 20-30 órányi megnézendő videóról van szó, amit utána végig is kell gyakorolni, és a házi feladatokat is érdemes lesz végigvinni, hogy elsajátítsam a céloknak megfelelő tudást – szóval nem egy gyorstalpalóról beszélünk. A következő kör további egyetemek előadóitól, illetve az Apple-től származó anyagok feldolgozása lehet. Sokat segít, hogy a gépemen, az iPad-emen és még az első generációs iPod Touchomon is tudom nézni a videókat. Nem utolsó sorban az angolomnak sem árt, ha egy ennyi videót feldolgozok.

Két-három értelmes, de nem egetverően bonyolult alkalmazás ötlet is van, meglátjuk meddig jutok velük.

Egyebek

Az egyéb tanulandókat is szeretném videók, prezentációk feldolgozásával kezdeni. Elég sok olyan konferenciaanyag gyűlt össze, melyek végignézésére a napi teendők mellett egyszerűen nem jutott időm, ezek végignézésére, kipróbálására most sort tudok majd keríteni. Ezeket megpróbálom majd blogbejegyzés keretében is összegyűjteni.

A jövőbeni tanulások biztosításához olyan megoldásokat keresek, melyek az eddig “elvesztegetett” időimet tudják hasznossá tenni, mint például az utazással eltöltöttek. A különböző prezentációk, videók offline, iPod Touch-on, iPad-en elérhetőségét, valamilyen közös nevezőre konvertálás lehetőségeit próbálom majd megcélozni.

Feed enhanced by Better Feed from Ozh

HipHop, avagy gyors PHP a Facebooktól

Bártházi András — Fri, 05 Feb 2010 14:13:17 +0000

A napokban be lett harangozva (bár még nem jelent meg a cég nyílt forrású projektjei között, de dolgoznak rajta), hogy a Facebooktól egy a PHP sebességét megsokszorozó fejlesztést fogunk kapni. A HipHop for PHP nevű projektnek bár vannak viszonylagosan komoly kötöttségei, de egyrészt ezzel együtt is nagyon hasznosnak tűnik, márészt a PHP-nak bármilyen jellegű frissítés, új vérvonal csak jót tehet.

A HipHop for PHP a gyakorlatban egy C++ fordító, illetve webszerver funkciót lát el. A Facebook azért fejlesztette ki, mert sem a PHP memóriafoglalásával, sebességével, sem a kódok más nyelvi környezetben felhasználhatóságával, s a kiterjesztések programozhatóságával nem voltak túl elégedettek, másfelől viszont már van egy hatalmas PHP-ben írt kódbázisuk, és a tanulhatósága is jó a nyelvnek.

Érdemes megnézni a prezentációjukat:

Illetve én is megpróbáltam összeszedni, hogy milyen gyakorlati különbségek vannak a HipHop és az eddig megszokott, Zend Engine-es PHP között:

C++-ra fordít

A HipHop a PHP forráskódot egy optimalizált C++ kódra írja át, melyet aztán a G++ fordítóval lehet futtatható kóddá alakítani. A nyelvi elemek, a teljes PHP-ben a programozó számára elérhető kódkörnyezet egy jól optimalizált C++ kódban testesül meg az átírás végére, melynek a PHP kódjához ezután nem sok köze van. Néhány – általában ritkán használt – funkció (legfőképpen a PHP kódból dinamikusan új kód előállítását megcélzóak): eval(), create_function(), a preg_replace “e” kapcsolója be lett áldozva a teljesítmény oltárán, mindazonáltal pár dolog, mint a call_user_func(), dinamikus változók, extract() megmaradtak. A hiányzó függvények miatt pár népszerű framework (konkrétan a Symfony felől hallottam ilyen véleményeket) várhatóan nem fog működni HipHoppal. Kérdés, hogy ki alkalmazkodik majd kihez, mennyit jelent majd a gyakorlatban a HipHop sebességnövekedése, s mennyire lesz kényelmesen használható – ezek majd a kód közzététele, és a lehetőségek pontos megismerése után derülnek ki.

Ami a sebesség növekedést illeti, a Facebook webes forgalmánál 50%-kal kevesebb processzor használatot tapasztaltak ugyanakkora, az API-nál 30%-kal kevesebb processzor használatot dupla forgalom mellett. Ezek nem feltétlenül tűnnek hatalmas számoknak, de ha belegondolunk, hogy több, mint 30.000 szerverük van (2009 októberi adat), akkor mindjárt komoly spórolásról beszélhetünk.

Fejlesztőkörnyezet

A fordítás a kód méretétől függően várhatóan nem tizedmásodperces, másodperces sebességű lesz, így leginkább egy deploy folyamatba lesz beilleszthető. Ez így nehézkes lenne fejlesztés közben, így elkészült egy HPHPi névre hallgató interpreter is, ahol kimarad a fordítgatás, így a fejlesztés könnyebbé válik. Ez a megoldás eval() függvényt is megvalósítja, de a HipHophoz közel áll.

Deployment

A deployment során nem PHP kódot kell a szerverekre eljuttatni, hanem egy darab lefordított, “hatalmas” bináris fájlt. Egy HipHop szerver egy processzként, threadek segítségével fog futni, leállás nélkül lehet új verzióra átállni vele.

PHP kiterjesztések

A Facebook programozók saját bevallásuk szerint jópár PHP kiterjesztést használnak. Nem túl tiszta számomra, hogy pontosan mely kiterjesztések lesznek a HipHoppal is használhatóak, de a fenti prezentációban 100.000 sornyi kiterjesztés függvényről beszélnek, mely a HipHop részét képezi – ezzel gondolom jópár kiterjesztés le van fedve.

Beépített webszerver

A HipHop saját webszerverrel rendelkezik, ami az én meglátásomban hatalmas előnyként jelentkezik, mindazonáltal a hoszting cégek dolgát ezzel sem könnyíti meg. Gondolom a webszerver a statikus fájlok kiszolgálására nincsen felkészítve, illetve nem feltétlenül támogatja a rewrite rule-okat, és más hasonló tipikus általános webszerver funkciókat sem, így várhatóan egy nginx/lighttpd felhúzása proxyként a HipHop elé lehet a legcélszerűbb felállás.

Roadmap

A HipHop PHP jelenleg az 5.2-es PHP verzióval kompatibilis, de szeretnék az 5.3-as verziót mielőbb beérni. További cél az Apache támogatása is.

Kinek jó, kinek nem?

Aki néhány nyílt forrású programot futtat egy hoszting cég szerverén, az várhatóan semmit sem fog profitálni a HipHop megjelenésével, sem a hoszting cégek, sem a nyílt forráskódú projekteket fejlesztők várhatóan nem fognak rövid távon átállni rá. A célcsoport sokkal inkább azok a saját nagyobb projekteket kivitelező fejlesztők, melyek jópár szerverre dolgoznak, API-t fejlesztenek, ahol a PHP kódokra jelentős terhelés jut. Ezekből adódóan a HipHop célja nem a Zend Engine lecserélése, ez egy párhuzamos vonal lesz.

Még több olvasnivaló

Ha valaki egy jó kis tech olvasnivalóra vágyik, akkor ajánlom neki Terry Chay írását, jó sok részletről lehet nála olvasni egy hosszú-hosszú blogbejegyzés keretében.

Feed enhanced by Better Feed from Ozh

jQuery 1.4 újdonságok

Bártházi András — Fri, 15 Jan 2010 14:58:59 +0000

Megjelent a jQuery 1.4, számos újdonsággal, mely miatt érdemes áttérni az új változatra. A legtöbb dologban visszafele kompatibilis az 1.4-es verzió, a potenciális problémák listáját azonban érdemes átnéznie annak, aki régi kódot frissít.

Az újdonságokat egy prezentációban szedtem össze ezentúl, de inkább csak azokat, melyeket érdekesebbnek, izgalmasabbnak találtam:

jQuery 1.4 újdonságok

View more presentations from András Bártházi.

További olvasnivalók:

Feed enhanced by Better Feed from Ozh

Kiadták az EcmaScript 5-öt

Bártházi András — Sat, 12 Dec 2009 12:06:27 +0000

Megjelent az EcmaScript 5, vagyis a JavaScript, ActionScript programozási nyelvek mögött álló szabvány legújabb változata, melyet ebben a blogbejegyzésben én most simán lejavascriptezek. Az új változat még érettebbé teszi a JavaScript nyelvet a “strict mód” bevezetésével, illetve pár kisebb-nagyobb kiegészítést hoz be a használható függvények terén.

Az EcmaScript történetével úgy tűnik, hogy részben megismétlődik a CSS kapcsán már látott felállás: a korábbi EcmaScript 4 változatként kiadni tervezett (de ki nem adott) verziót végül csak az ActionScript valósította meg (pedig jó dolgok voltak benne), így az EcmaScript 5 végülis az EcmaScript 3 utódjaként jelenik meg. A JavaScript motorok világa azonban pörög, ott a legfiatalabb Google V8-a (Chrome), a Mozilla TraceMonkey-ja (Firefox), az Apple Nitroja (Safari), nem beszélve a többi böngészőben megjelent, vagy böngészőktől független futtatást lehetővé tevő motorról, tehát ideje volt egy kis ráncfelvarrásnak. Pár motor már támogatja is a megjelent újdonságokat.

Strict mód

A strict mód egy szigorúbb programozási stílust tesz lehetővé, kidobálva azokat a problémásabb részeket a nyelvből, melyek nem igazán váltak be, vagy egyszerűen túl lazák egy komoly programozási nyelvhez. A szigorúbb JavaScriptre a következő “paranccsal” lehet átállni:

"use strict";

Vegyük észre a megoldásba rejtett tökéletességet, vagyis hogy a parancs visszafele kompatibilis, a régebbi motorokban semmilyen hatása nem lesz az önmagában álló sztring literálnak. A teljes scriptünkben is használhatjuk a strict módot, de egy függvény elején megemlítve csak azon a függvényen belül is használható.

Az EcmaScript 5-öt támogató motorokban a következő fontosabb hatásokat váltja ki a “parancs”:

A változókat használat előtt deklarálni kell a var paranccsal. Aki írt már nagyobb projekteket sok változóval, függvényekkel, és órákat debuggolta, hogy mi lehet a gond néhány furcsa hiba mögött, az tudja értékelni igazán ezt a változtatást. Egy függvényben ha nem használunk var-t, akkor a változó a globális névtérben jön létre, s ha mindezt két függvénynél is megtesszük, melyek pluszban még egymást is hivogatják, a végeredmény egy gyönyörű káosz lesz. Persze ez csak az egyik felállás, amikor gondot okozhat az, ha nem használjuk a var-t, s ezzel nem deklaráljuk, hogy az adott változó hol lesz elérhető. Jó gyakorlat volt eddig is mindig használni a var-t, ezentúl a JavaScript motor jelezni is tudja felénk, ha hibát vétünk.
Az eval()-on keresztül futtatott kódrészlet elkülönített névtérben fut. Vagyis egy eval(“var x = 10;”); console.log(x); parancssor strict módban egy “undefined” értéket fog kijelezni számunkra. Az új x változó csak az evalon belül használható.
Az oktális szám literálok (vagyis a nullával kezdődő számok, mint a 010) le lesznek tiltva. Eddig a var x = 010; után az x változó értéke 8 volt, strict módban viszont 10 lesz. Eddig sem használtam, ezentúl sem fogom az oktális számokat, egy hibalehetőséggel kevesebb.
A with használata hibát fog eredményezni. A with használata az évek során nem vált be, a használata majd minden böngészőben lassú, és számos hibalehetőséghez is vezethet. A JavaScript programozók körében eddig is az volt a közvélekedés, hogy a with nem használandó.
A delete parancs segítségével nem lehet ezentúl függvényeket, változókat, (függvény) paramétereket törölni. Pontosabban eddig sem lehetett, csak nem kaptunk hibaüzenetet, hanem csendben nem történt semmi.
A függvényeknek nem lehet több ugyanolyan nevű paramétere, és az objektumok deklarációjakor sem fordulhat elő többször ugyanaz a kulcs.
Az arguments ezentúl csak olvasható lesz. Az arguments helyi változó segítségével az aktuális függvény paramétereit érhettük el, s akár módosíthattuk is eddig, de ez nem volt egy túl szép megoldás.

Függvény környezet

Az EcmaScript új objektumokat, illetve metódusokat is hoz magával:

A natív JSON támogatás talán az egyik legfontosabb újdonság. A JSON.parse() segítségével fel tudjuk dolgozni a JSON sztringet, a JSON.stringify() segítségével pedig egy objektumból készíthetünk JSON sztringet. Mind a két függvénynél kiszűrhetünk egyes kulcsokat egy második paraméterként definiált függvény segítségével.
A függvény objektumok bind() metódusa segítségével ezentúl úgy hívhatjuk meg a függvényt, hogy a kontextust is definiáljuk. A lehetőség megegyezik a Prototype függvénykönyvtár által is definiált megoldással.
A Date objektumok ezentúl feldolgozni és létrehozni (toISOString metódus) is tudnak ISO szabványú dátumokat (2009-12-12T12:12:12.000Z).
A String objektumok kaptak egy trim() metódust.
Az Array objektumok (vagyis a tömbök) egy halom új metódust kaptak: indexOf, lastIndexOf, every, some, forEach, map, filter, reduce, and reduceRight. Ezek többnyire eddig is jelen voltak így (natívan a böngészők által) vagy úgy (függvénykönyvtárak használatával), most már szabványosak is.

Objektum rendszer

Az EcmaScript 5 számos újdonságot hoz az objektumok és tulajdonságaik kezelését illetően is:

Az Object.preventExtensions(obj) metódus letiltja az objektum bővíthetőségét (új tulajdonságok hozzáadását), az Object.isExtensible(obj) pedig lekérdezi, hogy bővíthető-e az adott objektum.
Az objektumok különböző tulajdonságai új meta leírókkal bővülnek, az érték mellett az adott tulajdonság írhatósága (writable), felsorolhatósága (enumerable), módosíthatósága (configurable) is olvashatóak, illetve írhatóak. Ehhez kapunk egy adag új függvényt.

Összefoglalás

A Firefox újabb verziói, illetve az Internet Explorer 8 egy részét már támogatják az újdonságoknak, én a Firefox egy nightly verziójával kísérleteztem több-kevesebb sikerrel (például strict módban az oktális érték deklaráció nálam hibát dobott, nem pedig decimális számként értelmezte az értéket). Próbáltam a fentieket több forrásból is összeszedni, tesztelni, a szabvány PDF-je annyira száraz olvasmánynak bizonyult számomra, hogy inkább másodlagos forrásokból dolgoztam. Ezek miatt csúszhatott hiba is a fentiekbe, ha valaki talál valamit, szóljon!

John Resig alaposan összefoglalta a témát két bejegyzésében is, ezeket csak ajánlani tudom: ECMAScript 5 Objects and Properties és ECMAScript 5 Strict Mode, JSON, and More.

Feed enhanced by Better Feed from Ozh

Demo 2009 – ott leszünk

Bártházi András — Wed, 25 Nov 2009 16:07:49 +0000

Az imént jött a levél, hogy a “Social Media Campaign Center” munkanevű startup ötletünkkel bejutottunk a (hazai) Demo ’09 döntőjébe, avagy a decemberben rendezendő konferenciára. 30 pályázó közül először 15-öt, majd végül 8-at választott ki egy számomra nagyon szimpatikus, igazi szakmai megbeszélésen a zsűri (mely befektetőkből, a piacot és a különböző technológiát is jó ismerő szakemberekből állt).

Az Amerikából indult DEMO már húsz éve ad lehetőséget a startupok számára megmérettetésre, s hasonlóan működik, ahogy az általam is szervezett Startup konferencia: az előadók 6 percben mutathatják be projektüket a közönség előtt. Hazánkban eddig még csak egy alkalommal került megrendezésre, tavaly én teljesen lemaradtam róla.

Ötletünk az olyan közösségi média kampányok hatékony, gazdaságos kivitelezését elősegítő eszköz, melyről a későbbiekben majd még osztok meg részleteket. A konferencián első helyezést elérő startup lehetőséget kap a jövő év elején szervezendő amerikai konferencián való részvételre is. Tekintettel arra, hogy a mi ötletünk sokkal hasznosabb, mint amilyen látványos, ezért komolyabb eredményeket egyelőre nem várok a részvételtől, de majd még meglátjuk, hogy hogyan sikerül majd a prezentáció.

Feed enhanced by Better Feed from Ozh

Where Is the Love?

Bártházi András — Sun, 22 Nov 2009 09:14:57 +0000

Mostanában elég sok olyan nyílt forrású projektet nézek meg (tegye fel a kezét, aki nem nyílt forrású cuccokat használ fejlesztéseihez manapság), melyek frissnek, újnak számítanak. Keresem az új ötleteket, vagy a régi ötletek jól használható megvalósításait. Egyre könnyebb megtalálni ezeket a projekteket.

Két fajta forrásom van, az egyik típus a nyílt forrású kódokat hosztingoló oldalak, a másik típus pedig a blogok, melyek kedvenc témáimról szólnak. Ezzel alapvetően gondolom nem mondtam újdonságot, de ezeket most megpróbálom össze is gyűjteni, hátha tudok adni olyan tippeket, melyeket mások nem ismernek. Szívesen venném azt is, ha ti is megosztanátok kedvenc forrásaitokat.

Forráskód hoszting oldalak

Szóval jellemzően két forráskód hoszting oldalt ismerek, ahol rengeteg új projekt talál otthonra. Mind a kettőnél díjmentesen hosztolhatjuk nyílt forrású kódjainkat, ha ilyen projektbe kezdünk, mindenképp megéri valamelyik közül választani:

GitHub

A Git verziókezelő rendszer egyre nagyobb teret hódít, s bár én még nem próbáltam ki, de valamikor annak is eljön majd az ideje. E köré lett felépítve a GitHub, mely a publikus projekteken kívül arra is lehetőségek kínál, hogy saját projektjeinken dolgozzunk. Keresőjével elég sok érdekességet lehet fellelni. Itt van hosztolva a Node.js és a Redis, de itt található meg a Cappuccino, a Processing JS, az Underscore, az NGiNX HTTP push module és még több tucatnyi érdekes kód.

A Git lehetőségeiből adódóan bárki nagyon könnyen hozzá tud járulni ezeknek a projekteknek a fejlődéséhez, mivel nem kell hozzáférést kérni a forrás írásához, hanem könnyen lehet új ágat indítva belefejleszteni amit szeretnénk bármely projektbe, aztán persze a kód tulajdonosa majd eldönti, hogy ez bekerüljön-e a fő ágba.

Google Code

A Google Code egy SVN alapú kód hoszting szolgáltatás, mely nem csak a kódok tárolását, hanem komplexebb lehetőségként azok wiki alapú dokumentálását, illetve hibajegy kezelését is lehetővé teszi. Itt vannak közzétéve a Google saját nyílt forrású kódjai is (az Androidtól kezdve a Closure-ig). Sajnos a keresője (pedig Google!) messze nem olyan jó, mint a GitHubé, de azért érdekes projekteket lehet itt is fellelni. A Redis például itt kezdte a kódjának a közzétételét, majd átköltözött a GitHubra, de a dokumentáció és hibajegy kezelés az itt maradt. Itt van az openscope, swfobject, a PubSubHubBub, a flot, az iui, a blueprintcss, a TrimPath, stb.

Blogok

A blogok hagyományosan olyan információforrások, melyek jól válogatott, érdekes tartalmakat kínálnak. Én a következőkre vagyok feliratkozva:

Egyebek?

Ami még jól használható, de jó zajos forrás is egyben, az a delicious megfelelő feedjei, de a popular részlegre is feliratkozhatunk. Ti mit olvastok, követtek a webfejlesztés tág témakörét illetően?

Feed enhanced by Better Feed from Ozh

Mac OS X + Flash 10.1: videó problémák

Bártházi András — Sat, 21 Nov 2009 08:16:34 +0000

Az újdonság varázsa elbűvölt, és úgy döntöttem, hogy feltelepítem a Flash 10.1-es verzióját, hogy kipróbáljam tényleg olyan gyors-e ahogyan olvasni róla. Erről meggyőződni végülis nem tudtam, ámde az összes videó lejátszás elromlott a YouTube-tól az IndaFilmig, a régi Flash verziót pedig nem engedte telepíteni a rendszer. Pár nap után elegem lett a dologból, és rászántam magam hogy megkeresem a megoldást – ami hasznos lehet azoknak is, akik Flashre fejlesztenek, és váltogatni szeretnének különböző verziók között Macen.

Röviden a megoldás: a /Library/Receipts/Adobe Flash Player.pkg törlése. Próbáltam leszedni a Flash-t, ami sikerült is (bár az uninstaller elég sokat gondolkodik cselekvés előtt), de ez sem hozott megoldást: a rendszer továbbra sem engedte a régebbi verzió (10.0.x) telepítését, egy “A newer version of this software already exists on this volume.” hibaüzenettel szerelt le. A bekezdés elején említett fájl törlésével a telepítő végül már nem reklamált, s engedte telepíteni a korábbi változatot is.

Egyébként ahogy kiderült, a /Library/Receipts/ könyvtárba a telepítők dolgoznak, ide rögzítenek különböző jogosultságokat leíró információkat a telepített alkalmazásokról. Az itt levő fájlok eltávolítása akkor okozhat problémát, ha egy már telepített alkalmazást meg szeretnénk gyógyítani, ez esetünkben nem igazán állt fenn, nálam már fenn se volt a Flash, tehát nyugodt szívvel törölhettem a hozzá tartozó fájlt. Hasonló probléma egyébként más programoknál is előfordulhat, a megoldás keresgélése közben én végülis egy MySQL telepítés kapcsán fellépő probléma leírásánál találtam meg a megoldást.

A történet egyébként segített ráébreszteni arra, hogy mennyire függök – és valószínűleg függünk – a Flashtől és a videózástól, érdekes élmény volt.

Feed enhanced by Better Feed from Ozh

Acquia Drupal telepítő

Bártházi András — Sun, 15 Nov 2009 07:10:27 +0000

Ezen a hétvégén zajlik hazánkban a Drupal Hétvége, s bár részt venni rajta nem tudok, de péntek-szombat-vasárnap Drupalos pólóimmal tisztelgek az esemény előtt, illetve próbálom követni a fejleményeket. A tegnapi előadások fóliái, sőt, a videók is már elérhetőek a rendezvény honlapján. Bár már korábban is hallottam róla, most sikerült eljutnom odáig, hogy kipróbáljam a helyi gépre egy komplett Drupalt varázsló kezdeményezést, az Acquia Stack Installert, amit ezúton ajánlanék.

Az Acquia Stack Installer a Drupal alapjait lerakó, illetve a közösséget továbbra is aktívan vezető/támogató Dries Buytaert cégének, az Acquianak a fejlesztése. Egy Apache+PHP+MySQL, illetve Drupal telepítőről van szó, mely nem csak feltelepíti ezeket a szoftvereket a szükséges beállításokkal, de a menedzselésüket is lehetővé teszi.

A Windowsra és Mac OS X-re is elérhető telepítő nem csak az alap Drupalt, hanem még egy adag modult is feltelepít, a célja az, hogy nagyon gyorsan egy működő Drupal környezet álljon a rendelkezésünkre, melyet mind felhasználóként, mind pedig fejlesztőként birtokunkba vehetünk. A telepítés nálam zökkenőmentesen lezajlott, s letöltéssel együtt röpke tíz perc alatt már el is kezdhettem kattintgatni a Drupal oldalon.

A Drupal mögött nem csak nemzetközi szinten, de hazánkban is egyre nagyobb fejlesztői kapacitás sorakozik fel, s a Drupal.hu mögött álló csapat is szép munkát végez a népszerűsítést illetően. A Drupal felhasználói interfésze, s az elérhető lehetőségek a kemény munkának köszönhetően egyre jobbak lesznek, a 7-es Drupal verzióban kellemes újdonságok várhatóak.

Feed enhanced by Better Feed from Ozh

A HTML 5 és CSS 3 újdonságai

Bártházi András — Fri, 13 Nov 2009 08:00:49 +0000

Beindult a marketing gépezet a HTML 5 kapcsán, viszont viszonylag keveset hallani arról, hogy a marketing dumákon kívül miről is van szó pontosan (bár korábban például már én is írtam a HTML 5-ről). A Flash leváltására alkalmas csodaszerként, a Google új fegyvereként, a HTML webkettőjeként szokás emlegetni, holott a történet egész másról szól. Egy néhol száraz, de igen érdekes specifikációról. Sőt, a HTML 5 mellett itt van a CSS 3, és itt van az SVG és egyéb más lehetőségek is. Egy több bejegyzésből álló sorozatban megpróbálom összeszedni, hogy mi is volt a HTML 5 és a CSS 3 története, hogy pontosan milyen új eszközöket kapunk ezekkel a specifikációkkal, s hogy hol tart most ezeknek a böngészőkben implementálása.

HTML 5 – így történt

A Wikipédia HTML 5 szócikke nem túl bőbeszédűen, de egész jól összeszedi, hogy hogyan is jutottuk el a HTML 5 mai állapotáig. Az egész a WHAT Munkacsoport (Web Hypertext Applications Technology Working Group) megalakulásával kezdődött 2004 júniusában, pár hónapos előkészítő munka után. A csoport alapítói az alternatív (IE-hez képest) böngészőgyártók, konkrétan az Apple (Safari), a Mozilla Alapítvány (Firefox) és az Opera Software (Opera) voltak, céljuk egy a W3C-tól független, annál hatékonyabban működő, nyitott, laza összefogás volt. A Microsoft eleinte ki lett hagyva a játékból, később pedig egy ideig még nem ismerte el a törekvéseket, de az IE 8 kapcsán már elkezdett implementálni részleteket, és az IE 9-ben további implementációk várhatóak. A W3C akkoriban nem a rugalmasságáról volt híres, a (nem alacsony tagdíjat fizető) tagok vehettek csak részt a döntésekben és az irányok meghatározásában, és sokkal inkább az akadémiai hozzáálláson, mint a praktikumon volt a hangsúly. A problémák a W3C ajánlásokban szereplő, de a böngészőkben nehezen megvalósítható, vagy egyszerűen csak nem használt funkciókban (lásd például a CSS 2.1 megjelenésének oka, vagy az XHTML 2.0 teljes csődje) jelentkeztek.

A WHATWG a Web Forms 2.0, Web Apps 1.0 és Web Controls 1.0 dokumentumok elkészítésével kezdett el foglalkozni. A Web Forms célja a HTML 4.01-ben definiált form elemek olyan jellegű bővítése volt, melyek a régi böngészőkkel is kompatibilisek, de igazodnak a kor igényeihez, és JavaScripttel a régi böngészőkben is megvalósíthatóak. A Web Apps egy sokkal összetettebb, a webalkalmazásokat támogató, már létező és teljesen új fejlesztések szabványos irányba tereléséről szólt. Új HTML elemektől kezdve a session kezelés, a helyi adattárolás, WYSIWYG szerkesztés, 2D és 3D canvas, különböző kommunikációs megoldások és további kisebb-nagyobb fejlesztések mind a HTML leíró nyelvet, mind pedig a DOM-ot illetően az, amit magába foglalt a specifikáció. Végül a Web Controls célja olyan lehetőségek definiálása volt, melyek lehetővé tennék új “widgetek”, kvázi HTML elemek definiálását és működésének leírását.

Az új ajánlások közzététele és tervezése eleve a W3C ajánlások formátumával kompatibilis módon zajlott, és célként volt kitűzve, hogy amennyiben lehetséges, a W3C fogadja majd be a dokumentumokat. A szabványok kialakítása ezután nagy lendülettel elkezdődött, új elemek is beléptek, és volt olyan is, amiről kiderült, hogy mégsincs rá szükség, és 2006-ban indult egy blog is, mely folyamatosan beszámol azóta is a fejleményekről. 2007-ben a W3c bejelentette, hogy újra nekifut a HTML történetnek, ekkor már nyílt levelezőlistával, és határozottan együttműködve a WHATWG-vel is.

A Web Apps 1.0-ba végül beleolvadt a Web Forms 2.0, és átnevezték HTML 5-re, a Web Controls pedig időközben elhalt a nem túl nagy érdeklődés, illetve a hasonló célú XBL 2.0 miatt.

HTML 5 – itt tartunk

A HTML 5 fejlesztése kifejezetten aktív. A specifikálás azóta sem állt meg, s bár elég jól körvonalazódott már a HTML 5 tartalma, továbbra is előfordulhat, hogy új elemek kerülnek be, vagy kikerülnek kevésbé fontos elemek, sok részlet pedig folyamatosan finomításra kerül. A böngészőgyártók elkezdeték implementálni a különböző lehetőségeket, összességében elmondható, hogy az összes szóba jövő böngésző jó úton halad, s még ha az Internet Explorer le is van maradva, de a legtöbb dolog ebben a böngészőben is implementálva lesz szépen lassan.

Egy bekezdésben nehéz lenne összefoglalnom, hogy mennyi részlete van a specifikációnak, nagyon-nagyon komplex. Nagyon sokat lehet tanulni belőle nem csak a jövőről, de arról is, hogy most hogyan működnek a böngészők és úgy általában a web, hiszen a céljai között az eddig nem dokumentált, de az évek során kompromisszumos megoldásként összeállt viselkedések definiálása is szerepel. A dokumentum nem csak a HTML elemeket, hanem a DOM lehetőségeit, illetve egyéb, a HTML feldolgozásához, megjelenítéséhez kapcsolatos részleteket is leír. Íme egy önhatalmúlag összeállított kivonat:

oldalvázat, szekciókat leíró elemek: body, section, nav, article, aside, h1-h6, hgroup, header, footer, address
új szöveges elemek, mint például: time, progress, meter
új tartalmat beágyazó elemek, mint például: figure, video, audio, source, canvas, map
az újfajta beviteli mezők, form elemek és a komplex formok leírását lehetővé tevő jelölők, elemek
interaktívitást lehetővé tevő elemek: details, command, menu
microdata – adatok HTML-be ágyazásának és kiolvasásának módja
a HTML és a JavaScript kapcsolatát, események működése
offline alkalmazások létrehozásának lehetősége
linkek, kapcsolódó tartalmak leírásának (feedektől a nofollow-on át a faviconokig) módja
a felhasználói interakcióval kapcsolatos lehetőségeket, mint például: szöveg kiválasztása, WYSIWYG szerkesztés lehetősége, helyesírás ellenőrzés, drag’n'drop
kommunikáció különböző domainek között az oldalon belül és a külvilággal
HTML vs. XHTML kérdést és a feldolgozás mikéntje
a megjelenítés az alapvető kérdésektől a betűtípusok kezeléséig
az idejétmúlt elemeket mint például: applet, marquee, frame, DOM lehetőségeket és az ezekkel kapcsolatos hibakezelést

Elég szabadon válogattam a dokumentumból részleteket, de a lista hosszúságából talán látszik, hogy nem egy 5 perces olvasmányról van szó, s hogy a böngészőgyártók elé igen komoly feladatok vannak kitűzve. Hogy tovább árnyaljam a képet, az olyan lehetőségek például, mint a canvas elem, itt a felsorolás egyik pontjában egy belső felsorolás részeként szerepelnek csak, holott egy könyv teljes fejezetét, vagy akár egy könyvet is lehetne szentelni a témának.

CSS 3 – így történt

A CSS 3 egy egészen más utat járt be, a kezdetektől W3C projektként fut. Itt is érdemes elolvasni a Wikipedia CSS bejegyzését, jól mutatja be a CSS múltját. A CSS 2 1998 májusában jelent meg, de a böngészők már ekkor komoly lemaradásban voltak, a Macintoshra kiadott Internet Explorer 5.0 a CSS első változatát is csak két évvel a második változat kiadása után, 2000-ben implementálta, és ezzel az első, legmodernebb böngésző volt akkor. A második változatot évekkel később sem tudta egyik böngésző sem megvalósítani teljes egészében annak viszonylagos összetettsége miatt. A helyzet normalizálása érdekében hozta ki a W3C a CSS 2.1-es változatát, mely alapvetően egy butított megvalósítás volt, a praktikumot előtérbe helyezve, és igazodva az akkori böngészőkhöz kihagyták belőle a “megvalósíthatatlan” részeket.

Tanulva a hibáiból a CSS 3 immár modularizált lett, vagyis különböző funkciók mentén modulokra robbantották az újdonságokat, melyeket a böngészők így “csomagban” tudnak megvalósítani, vagy akár átmenetileg figyelmen kívül hagyni. A CSS 3 egyes moduljai közel végleges, más moduljai kezdetleges állapotban vannak (helyzet), hatalmas mozgolódás nincs is ezirányban a specifikáció terén (a teljesen hiányos roadmap), havonta egy-két dokumentum frissül. Az implementációt illetően a böngészőgyártók bár nem rohannak, de jó ütemben implementálják az érdekesebb modulokat, adott funkciókat egész jól valósítanak már meg, sok dolog van még így is hátra.

A CSS 3 fejlesztése is sokkal nyitottabb folyamat már, mint korábban volt, a levelezőlistához bárki csatlakozhat, és véleményt, javaslatokat formálhat az irányokról, problémákról.

CSS 3 – itt tartunk

A CSS 3-nak vannak izgalmas, már-már eszement részei is, érdemes átfutni a specifikációt, és ismerkedni egy kicsit a várható irányokról, de ezeket én is igyekszem majd összefoglalni. Ahogy a HTML 5-nél, itt is összeszedtem egy listát, mely a CSS 3 különböző moduljait, és azok szerepét foglalja össze:

CSS Template Layout: a CSS 2.1-ben “nincs” olyan elem, mely oldalak layoutjának leírására, meghatározására szolgálnak (a float-ok ilyen célú használata például egy kompromisszum csak), a CSS Template Layout ezt a hiányosságot próbálja meg orvosolni. Elsőre elég vad és szokatlan, de mégis hatékonynak tűnő leíró megoldással.
CSS Aural Style Sheets: a CSS alapvetően a vizuális megjelenítésről szól, ez a CSS 3 modul viszont azt írja le, hogy hogyan lehet hangokat kapcsolni a dokumentumokhoz, illetve az eseményeihez (hover, oldal betöltődés, stb.), továbbá hogy hogyan lehet ezeknek a hangoknak a különböző tulajdonságait befolyásolni (balansz, hangerő, stb.).
CSS Backgrounds and Borders: a CSS 2.1 szabvány viszonylag puritán lehetőségeket kínál egy adott block megjelenésű elem hátterének és keretének beállításához. Ez a modul azt írja le, hogy hogyan rendelhetünk akár több háttérképet is egy elemhez, hogy hogyan állíthatjuk be azok pozícióját, kivágását és torzítását, illetve a kereteket illetően hogyan lehet a vonalak helyett képeket használni, vonalas keretet hogyan lehet lekerekíteni, s hogyan lehet árnyékot beállítani.
CSS Basic User Interface: formok különböző állapotaival kapcsolatos kiválasztók (Web Forms 2.0-hoz kapcsolódóan), a kerethez hasonló outline, egérkurzorok – az alapvető felhasználói interfész elemekről szól ez a modul.
CSS Basic Box Model: szintén alapvető dolgokkal foglalkozó modul, mely a doboz modellről szól, a display tulajdonság különböző értékeiről, a float és clear hatásáról és viselkedéséről, az overflow-ról és hasonló témákról. Az eddig használt, de részleteiben nem definiált, az IE overflow-x, overflow-y lehetőségének “legalizálásáról” és teljesen új dolgokkal is foglalkozik ez a modul.
CSS Extended Box Model: ami nem fért bele a Basic modellbe – egyelőre ebben a modulnak még nem kezdődött el a publikus kidolgozása sem
CSS Marquee: animált üzenősáv lehetőségek leírását teszi lehetővé, a doboz modell moduljából vált ki.
CSS Cascading and Inheritance: ez a modul az olyan alapvető szabályokról, mint az öröklődés, egymásba ágyazás, különböző médiák kezelése szól, alapértelmezett értékek, szabályok súlyának számítása szól. Alapvetően az eddig nem tisztázott, de nagyjából ugyanúgy működő megoldások pontos dokumentálása a célja, nagy újdonságokat nem hoz be.
CSS Color: a színek leírásának módjáról szól, ami újdonság benne, az legfőképpen a “negyedik dimenzió”, avagy a áttetszőség mint “szín” komponens kezelése.
CSS Fonts: a betűkészletek kezelését foglalja magában ez a modul, újdonságot a betűtípusok méreteinek egymáshoz igazításával és a “letölthető”, avagy a felhasználó gépén nem jelen levő betűkészletek használhatóságával kapcsolatban hoz.
CSS Generated Content for Paged Media: a Paged Media modulon felüli lehetőségek “oldal alapú” médiákhoz, mint például egy nyomtatott dokumentum verzió, vagy akár egy prezentáció. Olyanok vannak benne, mint dinamikus hivatkozások a dokumentumon belül (“lásd a 25. oldalon”), vagy például az oldal fejlécének/láblécének beállítása a dokumentum h1/h2/h3 (vagy bármilyen más) elemeinek segítségével.
CSS Generated and Replaced Content: oldal tartalmak létrehozásáról, vagy cseréjéről szóló modul, “hivatalosan” ezzel lehet például egy szöveges fejléc elemet képre cserélni, vagy adott elemek elé/mögé beszúrni tartalmakat
CSS Hyperlink Presentation: a linkek megjelenéséért, viselkedéséért felelős, például hogy mikor számít “aktívnak” egy link, de az is leírható a modulban foglaltak segítségével, hogy hol (új ablak, fül, stb.) nyiljon meg egy link.
CSS Introduction: ez egy összefoglaló modul, ami egy bevezetést, áttekintést (fog) adni a CSS 3 lehetőségeiről – majd ha “kész” lesz.
CSS Line Layout: a sorok függőleges igazítását, továbbá az összefüggő szövegek első karakterének, első sorának kiválasztóját írja le.
CSS Lists: a különböző listák megjelenésének leirhatóságát szabályozza ez a modul, a számozástól kezdve képek elhelyezéséig a listaelemek elé.
CSS Math: matematikai képletek, kifejezések (MathML) megjelenésének szabályozását végzi.
CSS Multi-column Layout: szövegek több oszlopba renderelését megvalósító modul, az oszlopok számának megadásától az elválasztó “hézag” paraméterének megadásáig lehet szabályozni a megjelenítést.
CSS Namespaces: az XML névtereinek támogatása CSS-ben is: a kiválasztók kiegészítése névtér támogatással.
CSS Object Model: a DOM “szabvány” azt szabályozza, hogy hogyan érhetőek el és módosíthatóak a HTML és XML dokumentumok “kívülről” valamilyen (pl. JavaScript) programnyelv által, ez a modul ugyanezt írja le, csak a CSS tulajdonságok kapcsán.
CSSOM View Module: egy dokumentum megjelenésének szabályozása valamilyen (pl. JavaScript) programnyelv által – konkrétan a dokumentum és elemek scroll pozíciójának állítása került bele ebbe a modulba, de foglalkozik a tartalmak kiválasztásával és az egér eseményekkel is.
CSS Paged Media: a korábban már említett modul, mely az oldalak fejlécének, láblécének, oldalak sorszámozásának állításáért felelős.
CSS Positioning: a position tulajdonság értékeinek pontos viselkedését szabályozó modul.
CSS Presentation Levels: különböző megjelenési szinteket, lépéseket definiál, például egy prezentáció egyes oldalaihoz definiálhatunk lépéseket (hányadik lépés), és megadhatjuk, hogy ha az adott lépésnél (szintnél) vagyunk, akkor mi legyen látható.
CSS Reader Media Type: ez a modul már megszűnt, de a különböző felolvasók támogatásáról szólt.
CSS Ruby: egyes írásoknál (pl. kínai és japán) léteznek az olvasást segítő “meta” írásjelek, melyek például az adott “szó” kiejtését teszik egyértelművé – ezek az úgynevezett “ruby”-k. Ezek pozícionálását szabályozza le ez a modul.
CSS Scoping: hogy pontosan mi is akarna lenni ez a modul, arról nem találtam konkrét információt, de a CSS Namespaces modulban létezik egy hasonló témakör – mely a kiválasztók működési területéről szól.
Grid Positioning: a CSS Template Layout modul is megpróbál választ adni arra a kérdésre, hogy hogyan lehet leírni egy komplex oldal layoutját, ez a modul is ezért a területért felelős, s alapvetően “grid”, azaz háló alapú layoutok leírását teszi lehetővé, kevésbé vad szintakszissal, mint társa.
CSS Speech: ez a modul azt szabályozza, hogy egy adott dokumentum hogyan prezentálható hang formában. Elég sok felhasználási lehetősége lehet az okostelefonoktól a navigációs rendszerekig.
CSS Style Attribute Syntax: a HTML (és egyéb CSS-sel szabályozott dokumentumok) “style” tulajdonságának formátumát definiálja – ez az egyik olyan alapvető dolog, ami korábban nem igazán volt szabályozva.
CSS Syntax: a CSS szabvány formátumának átfogó szabályozása, a leírónyelv filozófiáját foglalja magában.
CSS Tables Module: a táblázatok megjelenéséért felelős modul.
CSS Text: szövegek megjelenését szabályzó modul, az aláhúzástól kezdve a szövegek több sorra törésének leírásáig foglalja össze a terület kérdéseit.
CSS Text Layout: folytatja az előző modul feladatait, a függőleges írásiránytól kezdve a jobbról-balra történő írások jelöléséig.
CSS Line Grid: összetett szimbólumok vonalhoz igazodását leíró modul, mint például a japán szövegek karaktereinek egymás alá illesztése.
CSS Values and Units: a CSS értékeinek (számok, szöveges színek, URL-ek stb.) és egységeinek (px, em, ex, stb.) pontos működését és leírását szabályzó modul.
CSS Web Fonts: megszűnt, beleolvadt a CSS Fonts modulba.
Behavioral Extensions to CSS: dokumentum elemekhez viselkedések csatolását leíró modul – kvázi új dokumentum elemek hozhatóak létre a segítségével (pl. egy elemhez hozzárendelhetünk egy külső URL-en – XBL leírónyelvvel – leírt viselkedést).
CSS Flexible Box Layout Module Level 3: elemek box és inline-box megjelenéssel történő renderelését leíró modul.
CSS Image Values Module Level 3: képekre hivatkozó CSS tulajdonságok (pl. háttérkép) szabályait írja le.
CSS 2D Transforms Module: olyan kétdimenziós transzformációkat ír le, mint a mozgatás, nyújtás, forgatás, torzítás.
CSS 3D Transformations Module: perpektívikus 3D alapú transzformációkat ír le, a kétdimenziós transzformációkat ruházza fel egy harmadik dimenzióval.
CSS Transitions Module: átmenetek (oldal betöltődéstől kezdve a hover effektekig) viselkedését leíró modul.
CSS Animations Module: mozgás és egyéb animáció leírása CSS segítségével: időzítések, állapotok, késleltetések.

Nem mindegyik modult fejlesztik persze aktívan, van, amelyik több éves – vagy azért mert befejezettnek tekinthető, vagy azért, mert nem volt rá komolyabb igény. Számos aktív modulról lehet viszont olvasni manapság, ezek megvalósításánál talán a WebKit (Safari és Chrome mögött) áll az élen.

A fentiekből jól látható, hogy vannak nagyon alapnak tekinthető modulok, melyek jól kidolgozottak, és a CSS filozófiáját, pontos szintaktikáját mutatják be, vagy már évek óta használt, de eddig pontosan nem definiált részleteket szabályoznak.

Összefoglalás

Mint a fentiekből is látható, izgalmas korba születtünk. Jópár évnek kell eltelnie, mire a HTML 5 és a CSS 3 többségét használni fogjuk majd tudni, de sok olyan részlet van, melyeket már ma is tudunk használni, vagy mert a “gracefully degradation” jegyében a felhasználó egy tökéletesen működő, csak fapadosabb megoldással találkozik az azokat nem támogató böngészőkben, vagy pedig azért, mert JavaScript vagy más megoldásokkal azokban a böngészőkben is működőképesek lehetnek, melyek alapvetően nem támogatják még azokat. Ahol ez a helyzet, s ahol ebből nem származik komoly hátrány, ott mindenképpen javaslom az újdonságok használatát, hiszen ezzel kényelmesebbé tehető a modern böngészőket használók élete, és látványos megoldásokat lehet kihozni a dologból.

Emlékeimből, illetve a különböző dokumentumokból, blogbejegyzésekből igyekeztem rekonstruálni a történteket, ha valaki másképp tud valamit, ne hezitáljon azt jelezni egy hozzászólás formájában. Folyt. köv.

Feed enhanced by Better Feed from Ozh

Closure Compiler

Bártházi András — Tue, 10 Nov 2009 08:09:28 +0000

Pár napja tette elérhetővé a Google belső használatú JavaScript könyvtárainak egy részét egy hármas pakkban: a Closure Tools keretében mutatta be a Closure Compiler, a Closure Library és a Closure Templates eszközöket. Az elsőre térnék ki egy kicsit részletesebben, mert egy elég kellemes eszközt kapunk, de nézzük meg azt is, hogy mit tud a többi.

A Closure Tools csomag tehát az alábbi összetevőkből áll:

Closure Compiler: egy JavaScript “tömörítő”, mely több algoritmus segítségével képes csökkenteni a JavaScript kódok méretét, illetve gyorsítani is azt.
Closure Library: a Google saját JavaScript könyvtára, leginkább a Dojo-hoz tudnám hasonlítani, egy a matematikai függvényektől a kommunikáción keresztül a felhasználó interfész elemekig kínál megoldásokat.
Closure Templates: JavaScriptben és Javaban megvalósított sablonozó

A Closure Library-re a névterek, illetve az átláthatóságot javító, de sok gépelést igénylő hosszú, angol nyelvű függvénynevek jellemzőek. Személy szerint nem szeretem ezt az irányzatot, én inkább a tömören fogalmazó leíró megoldásokat kedvelem (a Perltől a jQuery-ig), ennek ellenére érdemes vetni a lehetőségekre egy pillantást, mert ha a formátum nem is nyeri el feltétlenül mindenki tetszését, de a lehetőségek kellemesek (mondom ezt úgy, hogy a hasonló névterekkel dolgozó Dojo sohasem tudott meggyőzni).

Amiket kiemelnék a Library nem túl átlátható lehetőségei közül:

UI elemek: melyek segítségével a GMailben, GDocsban látható menüt, toolbarokat építhetünk, gombokat tehetünk ki és a Flasht is eltakaró dialógus ablakokat nyithatunk
Gyorsbillentyű kezelés
Helyesírás ellenőrzés
Gears támogatás
Böngésző előzmények kezelés

Persze ennél sokkal több van a függvénykönyvtár mögött, az SVN repository-ból sokminden kiderül, és ott a dokumentáció is.

A Closure Template egy sablonkezelő rendszer. Röviden csak annyit írnék róla, hogy szintén nem az ízlésem szerint való, mivel – ha jól láttam – előzetes fordítást igényel (a template-ről JavaScript, illetve Java kódra). Így valóban a lehető leggyorsabb megoldást kínálja, de fejleszteni annyira nem kényelmes a segítségével. Ha már sablonkezelő és JavaScript, akkor nekem a Trimpath-féle megoldás sokkal inkább tetszik.

A Closure Compiler viszont mindenképpen egy hiánypótló eszköz. Komoly optimalizációkat képes végrehajtani a kódon, felismerve a nem használt részeket, az egyszer használt függvényeket megszüntetve, kódrészleteket összevonva, stb.

Az egyszerű whitespace eltávolító (megjegyzések, sortörések, felesleges pontosvesszők) alapszolgáltatásnak számít más optimalizálók esetében is. A bonyolultabb optimalizálók képesek egyebekre is, mint például a változónevek rövidítésére, az objektum["tulajdonsag"] kódrészlet objektum.tulajdonsag formára hozására, stb. A Closure Compiler azonban ennél is továbbmegy, például a következő optimalizációk elvégzésével:

if (a) { b(); } -> a && b()
if (a) { b(); } else { c(); } -> a?b():c()
return 2*3; -> return 6;
var a; var b; -> var a,b;

A következő kódrészletből:

function osszeadas(a, b) {
  return a+b;
}
alert(osszeadas(3,8));

Ezt csinálja:

alert(11);

De képes azokat a függvényeket eltávolítani, melyeket nem használunk a kódunkban, így ha nagyobb függvénykönyvtárakkal dolgozunk, nem kell aggódnunk amiatt, hogy felesleges részeket is betöltünk, az optimalizáció során ezeket eldobja ugyanis a program. Itt egy még bonyolultabb optimalizációval is találkozhatunk.

A Closure Compilerről persze el kell mondani, hogy nem feltétlenül biztonságos a használata, bonyolult kódelemzést végez ugyan, de egy eval(), vagy más rossz JavaScript megoldás azt eredményezheti, hogy a végeredmény nem lesz működőképes. Ezt a megfelelő JavaScript kódolási stílus betartásával, konfigurációs paraméterek segítségével (mit engedünk, mely részekre engedjük), a kódban tippek leírásával, vagy a komolyabb tömörítések kikapcsolásával tudjuk kivédeni – értelemszerűen az előbbiek a javasoltak.

Az optimalizáló online (ingyenes), API-val is rendelkező szolgáltatásként, de parancssori eszközként is elérhető. Érdemes játszani vele egy kicsit, látványos. A Firebug kiegészítő segítségével a tömörített kódban előforduló hibákat is könnyen debuggolhatjuk, így az éles rendszerben sincsen kizárva a hibakeresés lehetősége.

Feed enhanced by Better Feed from Ozh