Mit tanulnál szívesen?

Rég írtam a blogba, de most azt hiszem, megint lenne rá némi időm. Három téma foglalkoztat igazán, ha valakit érdekel bármelyik, hagyjon nekem egy kommentet! (Azt hiszem, nem kell regisztrálni hozzá.)

Gyakorlatilag készen van az a rendszer, amivel terveim szerint a következő 1-2 évben dolgozni szeretnék. Ez egy Zend Framework / Doctrine 1 alapú admin rendszer, ami elvileg JavaScript nélkül is működik, de viszonylag komoly jQuery / jQuery UI / TinyMce támogatással is rendelkezik. Szerintem van benne pár előremutató megoldás, például alapvetően HTML5-ös kódolást használtam, de egy kis plugin segítségével a HTML5 tageket HTML4-re kódolom az IE-nek, mobilioknak, elavult böngészőknek. Ezt a rendszert szívesen bemutatnám egy cikk sorozatban, de azon felül hogy szakmailag valószínűleg ez lenne a legizgalmasabb, szerintem ez érdekelné a legkevesebb embert. (Itt jegyezném meg, hogy többek között Szurovecz János blogjából elég sok ötletet merítettem. Mindenképpen ajánlom a blogját az RSS olvasótokba.)

Másik felvetésem, hogy programozás helyett visszatérnék a valódi szájtbilding témákhoz. Mostanában volt szerencsém egy tanult, de tapasztalatlan szájtbilderrel együtt dolgozni, a neki adott útmutatásaimat valószínűleg sokan tudnák a mindennapokban hasznosítani. 2-3 blogposzt biztos összejönne a hibás és vagy épp a jó elképzelések összegzéséből.

A harmadik, hogy két barátom is szeretne megismerkedni a JavaScripttel legalább közepes szinten, és magyar nyelven nem találnak igazán jó leírásokat. Én a magam részéről nagyon szeretem a NetTuts JavaScript from Null videóit, még ha nekem kicsit későn is jöttek ki. Könnyen lehet, hogy körül kéne néznem nekem is, mielőtt egy sorozatba belevágok, de ha van rá érdeklődés, szívesen foglalkoznék ezzel is. Néhány látványos és egyszerű megoldás bemutatása mellett kitérnék a DOM manipulálás buktatóira és megoldásaira, illetve valószínűleg egy kis jQuery forráskód elemzés is lenne benne.

Minden véleményt szívesen fogaddok, remélem lesz némi érdeklődés. Ha nem, akkor majd az aktuális hangulatom fog dönteni a kérdésben.

codesniffer gyorstipp

Tulajdonképp nincs komoly tapasztalatom a CodeSnifferrel és épp emiatt nem is próbálok meg belemenni a mélységeibe, de baromira idegesített, hogy ha Zend standarddal próbáltam elemeztetni a Zend Framework dokumentumomat, a többsoros függvényhívásoknál, mindig vinnyogott, hogy a hívás első sorában a nyitó zárójel után ne álljon semmi. (Opening parenthesis of a multi-line function call must be the last content on the line) Márpedig a doksi szerint ez nem gond. (http://framework.zend.com/manual/en/coding-standard.coding-style.html)

A saját kódomban még csak javítgathattam volna a dolgot, mert arra nem látok a leírásban semmit, hogy ténylegesen a standard elleni vétség lenne a paraméterek új sorra helyezése. A Doctrine által generált kódot viszont macerás és felesleges lett volna emiatt módosítani. Emiatt mindig kihagytam a generált könyvtárat kb így:

$: phpcs -n --standard=Zend --encoding=utf-8 --ignore=*/tests/log*,*application/models/Base*,*library/Zend*,*library/Doctrine*,*library/vendor*,*orig* ./

Mivel viszont még a parancssoros projekt-generátor is generál többsoros hívást ahogy a paraméterek a zárójel után kezdődnek, ezért úgy döntöttem inkább belenyúlok a Snifferbe.

Megjegyzés CS-t nem ismerőknek: A fenti parancs elindítja a CodeSniffert, kikapcsolja a figyelmeztetéseket (pl sor hosszabb, mint 80 karakter), beállítja a Zend-et mint standard és egyértelműsíti, hogy utf-8 fájlokkal fog dolgozni, majd vesszővel elválasztva megadja a kihagyandó könyvtárakat, végül megadja, hogy melyik könyvtárban dolgozzon a Sniffer.

 

Előszöris meg kellett keresnem a CodeSniffert, ami nálam a /usr/share/php/PHP/CodeSniffer/ könyvtárban ült. Kikerestem és megnyitottam a Zend Standardot, ami meglepő módon a Standards/Zend alkönyvtár volt, melyben egy ruleset.xml és egy Sniff könyvtár van. Ha megnyitjuk az xml fájlt, az alábbi leírást pillanthatjuk meg hozzá: 

A coding standard based on an early Zend Framework coding standard. Note that this standard is out of date.Nyilván ezt a helppel is elő lehet hozni, én sosem tettem. Mindegy, ne bántsuk a Standardot, inkább hozzunk létre egy sajátot gyorsan. Mivel furcsa mód a Zend alkönyvtárban levő Sniffeket egyáltalán nem használja a rulest.xml, ezért ne is foglalkozzunk felük. Hozzunk létre egy új könyvtárt és másoljuk át az xml fájlt:

$: sudo mkdir /usr/share/php/PHP/CodeSniffer/Standards/MyZend
$: cd /usr/share/php/PHP/CodeSniffer/Standards/MyZend
$: sudo cp ../Zend/ruleset.xml ruleset.xml

Maga a szabály, ami nekem fájt a FunctionCallSignature volt, amit a PEAR szabályrendszerből vesz az xml. Másoljuk át ezt is a megfelelő könyvtárba:

$: sudo mkdir -p Sniffs/Functions
$: sudo cp ../PEAR/Sniffs/Functions/FunctionCallSignatureSniff.php Sniffs/Functions/FunctionCallSignatureSniff.php

Ezután szerkesszük a ruleset.xml fájlunkat, írjuk át a ruleset tag nevét MyZend-re aés cseréljük ki a PEAR.Functions.FunctionCallSignature-t MyZend.Functions.FunctionCallSignature-re. Ezután nyissuk meg a FunctionCallSignatureSniff.php fájlt, írjuk át az osztály nevét MyZend_Sniffs_Functions_FunctionCallSignatureSniff-re, végül a fájl vége felé található következő kódrészt kommenteljük ki:

if ($tokens[($openBracket + 1)]['content'] !== $phpcsFile->eolChar) {
    $error = 'Opening parenthesis of a multi-line function call must be the last content on the line';
    $phpcsFile->addError($error, $stackPtr, 'ContentAfterOpenBracket');
}

$prev = $phpcsFile->findPrevious(T_WHITESPACE, ($closeBracket - 1), null, true);
if ($tokens[$prev]['line'] === $tokens[$closeBracket]['line']) {
    $error = 'Closing parenthesis of a multi-line function call must be on a line by itself';
    $phpcsFile->addError($error, $closeBracket, 'CloseBracketLine');
}
Ezután már csak egy dolgunk van, reménykedni, hgoy előbb-utóbb elérhető lesz egy sokkal jobb Zend CodeSniffer csomag, mint a jelenlegi, mert természetesen ez inkább egy hack, mint egy korrekt megoldás.

Extraként, ha főleg Zend Frameworkkel dolgozunk, akkor alapértelmezetté tehetjük a standard csomagunkat:

phpcs --config-set default_standard MyZend
Címkék: zend framework codesniffer

ubuntu apache installálás 2

avagy kubuntu for dummies 2

Az előző részben összeraktuk a szervert, de pár dolog még hiányzik, ezeket gyűjtöttem most össze.

Pear + PHPUnit

Először installáljuk a peart:

sudo apt-get install pear

Majd installáljuk a phpunitot is:

sudo pear channel-discover pear.phpunit.de
sudo pear channel-discover pear.symfony-project.com
sudo pear install phpunit/PHPUnit

xDebug

Az xDebug installálása elvileg egyetlen kattintás, de sajnos nem fog rögtön lefutni, ha nem telepítettük még a php5-dev csomagot. (Panaszkodni fog a pecl valahogy így: "running: phpize sh: phpize: not found ERROR: `phpize' failed.")

sudo apt-get install php5-dev
sudo pecl install xdebug
Ne lepődjünk meg, ha a pecl ellepi a konzolunkat szöveggel, ilyenkor forrásból állítja össze nekünk az xdebugot.

Ha a kurzor visszanyerése előtti utolsó sor valami olyasmin, hogy "You should add "extension=xdebug.so" to php.ini
", akkor már majdnem jó a helyzet, de a php még nem tud az xdebugról. nézzük meg hol jött létre az xdebug.so, ehhez nyissuk meg az /usr/lib/php5 könyvtárat és ls-el keressünk egy dátummal kezdődő könyvtárat. Nálam ez a 20090626+lfs volt. Ez kelleni fog a következő lépéshez, létrehozunk egy külön beállítás fájlt a modulnak:

sudo gedit /etc/php5/conf.d/xdebug.ini

Ennek első sora legyen:

zend_extension=/usr/lib/php5/20090626+lfs/xdebug.soAz apache újraindítása után elérhető lesz az xdebug, megjelenik a phpinfo()-ban is, de először inkább állítsuk be izlés szerint az xdebugot. (További opciók: http://www.xdebug.org/docs/)

PhpMyAdmin

sudo apt-get install phpmyadminBár ez borzasztó egyszerűnek tűnik, az első kubuntu intallálásomkor valamiért így nem akaródzott működni. Ekkor letöltöttem a forrást, de egy XP-s NTFS vinyóra volt. Mivel viszont itt nem lehet jogosultságokat megadni, ez azt eredményezte, hogy a phpmyadmin elkezdett nekem hibát dobni, amikor ki akartam kapcsolni a jelszókérést. Épp ezért, bár nyilván működhet a forrásból kicsomagolt program is, ha egy mód van rá én a jövőben maradok a ez előre csomagolt verziónál.

CodeSniffer

Az egységes kódhasználat nagyszerű dolog, sajnálatos, hogy egy átlagos projektben is szinte lehetetlen megcsinálni. Pontosabban a saját kóddal semmi gond, de ha már akár csak két idegen könyvtárat is használni szeretnénk, szinte biztosan különböző kódolási mintákat fognak követni. Azért legalább a saját kódunk egységességét megpróbálhatjuk követni a CodeSnifferrel:

pear install PHP_CodeSniffer-1.3.0RC1

PHP beállítások

sudo gedit /etc/php5/apache2/php.ini

Szeretem a feltöltéshez kapcsolódó beállításokat jó nagyra venni, így könnyen importálhatok több száz megás adatbázisokat a saját gépemre. Ehhez általában csak a max szótöredékre keresem végig a php.ini-t.

max_execution_time = 300
max_input_time = 600
memory_limit = 512M
post_max_size = 400M
upload_max_filesize = 400M

Jöjjenek a hibabeállítások. Saját körneyezetről van szó, úgyhogy hadd jöjjenek a hibaüzik, inkább itt mint élesben... A html_errors amúgy kicsit megviccelt, mert Windows alatt sosem kellett foglalkoznom vele, itt viszont xdebug-gal sem kaptam a szokásos szép kimenetet.

error_reporting = E_ALL | E_STRICT
display_errors = On
display_startup_errors = On
html_errors = On

Ezen kívül én még az open_short_tag = Off beállítást preferálom, úgyse használok rövid taget és a komolyabb keretrendszerek is tiltják általában. (Egyetlen általam ismert kivétel a CodeIgniter, de azt már régóta nem használom és a template fájlokban fel is oldja a problémát egy config beállítással.)

Hiányzó PHP modulok

sudo apt-get install php5-curl

Hiányzó apache modulok

Futassuk elkészült oldalainkon a YSlow és Page Speed lekéréseket és máris hiányozni fog pár modul az alapértelmezett apachból.

sudo a2enmod expires

sudo a2enmod headers

 

Címkék: linux php ubuntu apache

javascript budapest meetup

Augusztus 30-i meetup videói a hétvégén lettek kész, köszönet értük Hardi Jánosnak!

Itt én beszélek a QUnitról, a Jqueryhez köthető egységtesztelő rendszerről: http://vimeo.com/14703534

Utánam Szalóki Róbert következett a Yahoo saját keretrendszerének, a YUI3-nak bemutatásával: http://vimeo.com/14699878

Végül pedig Fodor Márton egy fantasztikus fejlesztést mutatott be, amivel konzol nélküli böngészőkben lehet tesztelni a JavaScriptet: http://vimeo.com/14694068

Címkék: javascript meetup jquery yui

ubuntu apache installálás (lamp-server)

avagy kubuntu for dummies

Mivel meghalt az elsődleges winchesterem, úgy döntöttem ezentúl Kubuntu lesz az alap és az XP a vendég. Két hete se vagyok full-time linuxos, 9 éve használtam XP-t. Emiatt lehet, hogy lesz itt jónéhány poszt, ami a többségnek triviális vagy érdektelen, de amit én visszakeresnék később. Valószűleg ez is egy ilyen lesz.

Megjegyzés: Mivel úgy tudom, az Ubuntu elterjedtebb, mint a Kubuntu, ezért a gedit szövegszerkesztőt használtam a példákban, de természetesen a Kubuntus kate is ugyanúgy működik.

Apache installálás

A tasksel egy Debian megoldás programcsomagok egybepakolására, Ubunutu és persze Kubuntu alatt is elérhető. A lamp-server rögtön telepíti nekünk az apache2 php5-mysql libapache2-mod-php5 mysql-server csomagokat.

sudo tasksel install lamp-server

A teljesség kedvéért még megjegyzem, hogy a fenti parancs ekvivalens a sudo apt-get install lamp-server^ paranccsal.

Az első virtuális szerver beállítása

Legyen az új virtuális hoszt a www könyvtárunk mysite alkönyvtárában és legyen az public_html mappa a publikus könyvtár.

Először módosítsuk a az alapértelmezett szerver beállításokat, hogy később ne kelljen már foglalkozni vele.

sudo gedit /etc/apache2/sites-available/default

Másoljuk az alapértelmezett beállításokat a létrehozandó szervernek megfelelő új fájlba:

sudo cp /etc/apache2/sites-available/default
/etc/apache2/sites-available/ipip

Ha ez megvan, szerkesszük az új hoszt fájl beállításait:

sudo gedit /etc/apache2/sites-available/mysite

és adjuk meg a feltétlenül szükséges beállításokat, a felesleget törölhetjük

<VirtualHost *:80>
    ServerAdmin emailcimed@szerver.com
    ServerName myserver.localhost
    DocumentRoot /var/www/mysite/public_html
</VirtualHost>
Ha ez kész, következő lépés az új hoszt fájl élesítése, ehhez egy linket hozunk létre a sites-enabled mappában ami az új fájlunkra fog mutatni. Ezt a linket létrehozhatnánk sajátkezűleg is, de leggyorsabb a debian alapú rendszerekben elérhető a2ensite parancsot használni.

sudo a2ensite mysite

A parancsot könnyű megjegyezni, ha tudjuk mit jelent: apache2 enable site. Ennek megfelően működik az a2dissite parancs is, amit akkor adhatunk ki, ha valamiért szeretnénk elérhetetlenné tenni az oldalunkat. Nyilván ennek éles szerveren van jelentőssége, de nem árt tudni fejlesztőknek sem.

Rendben tudassuk még a rendszerünkkel, hogy a mysite.localhost az mi vagyunk, ne kezdjen netezni, ha meglátja valahol, mert például megnyitnánk a böngészőben. Nyissuk meg a hosts fájlt:

sudo gedit /etc/hostsa localhost-ot tartalmazó sor alá vigyünk fel egy új sort:

127.0.0.1          mysite.localhostElvileg már csak annyi dolgunk van, hogy újraindítsuk a apache-t.

sudo /etc/init.d/apache2 restart

Szervernév

Ilyenkor valószínűleg még figyelmeztetést ad a szerver, nekem azt, hogy:

apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
 ... waiting apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName

Nyissuk meg az apache konfigurációs fájlját:

sudo gedit /etc/apache2/apache2.confAdjunk egy új sort a fájl végéhez:

ServerName szajtbilder-devahol szajtbilder-dev lenne a szervernév, természetesen ez szabadon választható. Ha ismét újraindítjuk a kiszolgálót, akkor valószínűleg most már hiba nélkül le fog futni az indítás.

Apache modulok

Rendben a szerver mostmár működik, de ha megnyitunk egy .htaccess-t használó virtuális szervert, akkor nagy valószínűséggel csak egy hibaüzenetet fogunk kapni a fent megadott saját adatainkkal. Ilyenkor nyissuk meg az apache error-log fájlját, ami ha meg nem változtattuk a host beállíásoknál, akkor a /var/log/apache2/error.log fájl. Ebből kiolvashatjuk, hogy milyen modul hiányzott a futáshoz.

Én például elsőre azt kaptam, hogy

Invalid command 'RewriteEngine', perhaps misspelled or defined by a module not included in the server configurationilyenkor meg kell nézni, hogy melyik modul része a RewriteEngine és aktiválni a modult. Az elérhető modulok az /etc/apache/mods-available könyvátrba kerülnek és az /etc/apache/mods-enabled-ben szereplők kerülnek betöltésre az apache indításakor. Akárcsak a virtuális host fájlok esetében, most is rendelkezésünkre áll a link létrehozására egy egyszerű debian parancs, a a2enmod. Mivel a RewriteEngine a rewrite modul része, adjuk ki a következő két parancsot:

sudo a2enmod rewrite
sudo /etc/init.d/apache2 restart

 Az első mint mondottam engedélyezi a rewrite modult, a második pedig újraindítja a kiszolgálót.

Remélem lesz még rajtam kívül valakinek ez a kis leírás.

Hamarosan pedig egy QUnit szösszenet fog itt megjelenni, hiszen augusztus 30-án erről fogok előadást tartani a budapest-js résztvevőinek.

rekurzív másolás szerverről szerverre

Nem vagyok egy linux guru, de néha-néha kénytelen vagyok parancssorból megoldani kisebb-nagyobb feladatokat. Most épp szerverről szerverre kellett másolni egy teljes honlapot. Nem nagy kunszt, de SSH-n keresztül a parancssoros FTP-vel nem ment a rekurzív letöltés, vagyis a fájlstruktúra megtartása, a könyvtárak automatikus létrehozása.

Szerencsére a wget nem csak http-n hanem ftp-n keresztül is tud letölteni, ráadásul rekurzívan is. Igaz elsőre kihagytam a rekurzió szintjeinek megadását, ezért csak 5 szintig töltötte le a tartalmat. A megoldás a -l20 hozzáadása volt, amivel korlátlan szintet le tudunk húzni a szerverről, illetve a -nc direktíva hozzáadása, hogy ne töltsön le semmit, amit már első nekifutásra letöltött.

Ezek után már csak a példa összeállítása maradt hátra. Ha szerverünk az ftp.example.com, a felhasználó nevünk szajtbilder és a jelszavunk j3lSzo, akkor a következő parancsot kell megadnunk:

wget -r -l0 -nc 'ftp://szajtbilder:j3lSzo@ftp.example.com'Akinek ennél többre van szüksége, annak itt az eredeti leírás szinte minden formátumban, vagy egy részletesebb wget bemutatás magyarul.

Sajnálom, hogy a Ruby on Rails poszt folytatása még nincs kint. Túlságosan elmerültem a témában és rendbe kell egy kicsit vágni még.

Címkék: linux tipp

blog.hu komment linkek kigyűjtése

Az előbb arra vetemedtem, hogy kigyűjtöttem egy blog.hu-s poszt összes kommentjét. Mivel sokszáz kommentben volt vagy 50 link, nem éreztem alternatívának a kézi gyűjtést. Helyette beizzítottam inkább a Firebugot és a FireQuery-t, aztán írtam rá gyorsan egy jQuery utasítást.

$('.commentText a[rel=nofollow]').each(function(){var url=$(this).attr('href');$('#mainWrapper').prepend('<p><a href="'+url+'" target="_blank">'+url+'</a></p>');})

Lehet, hogy van jobb megoldás is, de én elégedett voltam az eredménnyel, gondoltam hátha egyszer hasznos lesz másnak is...

Egyébként a fenti kifejezés a kommentek szövegében megkeresi a felhasználók által megadott linkeket - tehát a válaszok miatti linkekeket kihagyja -, kiszedi az url címeket és  berakja őket linkként, soronként a blogposzt elejére. Ráadásképp még hozzáadtam azt is, hogy új lapon/ablakban nyissa meg a linket, úgy kényelmesebbnek találtam.

Címkék: firefox javascript tipp jquery

ruby on rails kezdőlépések 1

Rég nem írtam, pedig sok érdekeset találtam és tanultam mostanában. Igazából három téma van, amiről szeretnék írni. Az egyik a teszt vezérelt fejlesztés, ami itthon szinte még ismeretlen fogalom, de legalábbis alig-alig használt eljárás. (A weblabor nemrég megjelent, PHP osztályok egységtesztelése című írása hiánypótló, ajánlom mindenkinek, aki számára ez új témakör!) A második a PHP-GTK, amit nagyon sokan ismernek és használnak, de valahogy elég gyengén dokumentált még nemzetközi szinten is, itthon meg pláne. A harmadik pedig Ruby és Python fejlesztések, amikkel csak most ismerkedek igazából én is.

Ja és sok mindent nincs mit írni róla, de nagyon jó volt az első JavaScriptes meetup, jövő héten pedig jön a második! Azt nem mondom, hogy próbáljatok meg eljönni, mert úgy is megint tele lesz a terem, de várom már az biztos!

Na de térjünk a tárgyra! Úgy döntöttem a Ruby lesz a következő programnyelv amivel megismerkedek, bár nem kizárt, hogy párhuzamosan el fogom kezdeni a Pythont is, hogy élesben alkothassak véleményt róluk. Mindkét nyelv arról ismert, hogy szép, tömör, lényegretörő. A Python mellett szól, hogy gyorsabb és az asztali alkalmazás fejlesztéshez is széles eszköztárat kínál, míg a Ruby mögött nagyobb a felhajtás és erősebb a közösség.  Ezen kívül utóbbi sokkal inkább a webes fejlesztésre orientálódik, mivel a Ruby on Rails (rövid nevén RoR vagy Rails) keretrendszer húzza maga után a nyelv fejlesztését is. Legalábbis ezt mondják a nagyok, én meg csak közvetítek, mint szinte mindig.

Na de ne is teketóriázzunk sokat, hanem játszunk egy kicsit a Rubyval, mint nyelvvel, hasonlítsuk össze kedvenceinkkel, aztán essünk neki a Railsnek.

Igazából nem kizárt, hogy ez a kis mini-tanfolyam már létezik magyarul, de úgysem pontosan fogom követni a szöveget, így talán annak sem jön rosszul ez a verzió, aki már az eredetit olvasta. Mindenesetre én egy-két bevezetőnek szánt írás elolvasása után úgy döntöttem, hogy a hivatalos útmutató kezdőlépéseit követem és alakítom át a saját belátásom szerint.

Az írás azzal kezd, hogy elmondja, mik is a Rails alapfilozófiájának elemei. Én ebbe most nem szeretnék nagyon belemenni, a lényeg röviden annyi, hogy nagyon gyors fejlesztést tesz lehetővé azáltal, hogy tipikusan mindennek van egy alapértelmezett értéke és csak akkor kell konfigurálással vesződni, ha el akarunk attól térni. Ezen felül még az lehet fontos, hogy egy kiterjesztett MVC architektúrára épül és erősen támogatja a REST alapú szolgáltatásokat. Igazából ezeket ma már minden komolyabb PHP alapú keretrendszer alkalmazza, így valószínűleg ezekben sok újdonság nincs, térjünk a lényegre!

Vigyázat! A következő írás azzal az előfeltétellel lesz csak teljes értékű, hogy az olvasó legalább egy MVC architektúrájú, szkript nyelv alapú keretrendszert ismer. Az egyes lépések talán ennek hiányában is követhetőek, de ami az általam ismert keretrendszerekben közös, azokat köztudottnak tekintem.

Telepítés

Először is töltsük le a Ruby legújabb stabil verzióját, ez jelenleg az 1.9.1-es verzió. A linuxot használóknak könnyű dolguk van, mert a legtöbb disztribúcióban benne van és tipikusan egy sor begépelésével fel is telepíthetik. Ubuntun például így:

sudo apt-get install ruby1.9.1-full

Windowsra sem egy ördöngősség, csak a weboldalt kell megtalálni a telepítőhöz, de én már megtaláltam nektek: http://rubyinstaller.org/

Ha a Ruby már a gépen van, akkor Windowson még érdemes a telepített csomag konzolját kinyitni, mert az hozzáadja a legfontosabb fájlokat az elérési útvonalhoz és nem kell nekünk szerkeszgetni/szemetelni a Windows PATH-t.

Ha ez megvan, installáljuk a Railst, ez már platform független lesz:

gem install rails

Talán annyit még fűzzünk ide, hogy a gem és a később előkerülő rake a ruby segédprogramjai, előbbi telepítésekért, utóbbi adatbázis műveletekért felelős ebben a cikkben.

A Rails telepítése után navigáljunk a leendő RoR projektjeinket tartalmazó könyvtárba és hozzunk létre egy új Rails projektet. A Rails alapértelmezetten Sqlite3 adatbázist szeretne használni, én viszont MySQL-t fogok, ráadásul a szokásos blog alkalmazás helyett egy webáruházat építek kezdő projektként. Ezeknek megfelelően a következőképpen hozom létre az rshop nevű új projektet:

$ rails rshop -d mysql

Kis szerencsével fennakadás nélkül létrejön a projektünk és láthatjuk, hogy kaptunk egy szép rakás könyvtárat és fájlt. Nyissuk meg a config/database.yml-t és lepődjünk meg, hogy a Rails már be is állított magának 3 adatbázis konfigurációt development, test és production néven. (Ha esetleg valaki nem tudná, ez egy YAML (ejtsd: dzseml) fájl, ami egy elterjedt leíró nyelv. Főleg ilyen konfigurálásra szokás használni, mivel mint látható, igen jól olvasható az emberi szem által. A PHP világában talán a Symfony keretrendszer a legjellegzetesebb használója, de más projektekben is megtalálható.)

Mindenesetre itt és most elég, ha arról meggyőződünk, hogy a fejlesztési (development) környezetekhez tartozó adatbázisok kapcsolódási adatai rendben vannak, mert erre hamarosan szükségünk lesz.

Mielőtt azonban létrehoznánk a táblákat, installáljuk a Rails MySQL modulját a parancssorunkból, ennek hiánya ugyanis biztosan hibát fog okozni.

gem install mysql

Ezután, ha nem a legújabb MySQL-t használjuk, vagy az 1.9.1-esnél újabb Rubyt (ami ezen sorok írásakor még nem létezik), akkor megpróbálhatjuk létrehozni az adatbázist, de ne ijedjünk meg ha hibába futunk:

rake db:create

Mivel nem installáltam még ezer gépre, ezer konfigurációban a Railst, ezért csak a saját tapasztalataimat írhatom le, mindenesetre én itt egy olyan hibaüzenetet kaptam, hogy a LIBMYSQL.dll nem található. Némi keresés után azt találtam, hogy a nálam telepített MySQL 5.1.x adatbázis nem kompatibilis a Rails telepítésemmel. A megoldás viszonylag egyszerű, töltsük le a szükséges libmysql.dll fájlt és másoljuk a Ruby bin könyvtárába. Ezután már szépen lefutott a rake parancs és létrejött a fejlesztői adatbázis.

Helló, világ!

Jó programozói szokás szerint, hozzuk létre az első Ruby on Rails alkalmazásunkat, ami kiírja nekünk, hogy "Helló, világ!". Sok értelme persze nincs, de legyünk kockák...

Ehhez feltétlenül kell egy controller és egy view. Legyen a controller a későbbi kezdőlapunk, így adja magát a home nevű controller létrehozása, amit Windows alatt az alábbi paranccsal hozhatunk létre: (Linux alatt a ruby parancs most és a továbbiakban is elhagyható.)

ruby script/generate controller home index

Ha ez lefutott, akkor keressük meg a most generált, megjelenésért felelős sablon fájlt, amit app/views/home/index.html.erb néven találunk meg a projektünkön belül. Vegyük elő minden ötletességünket és írjuk az alábbiakat a fájlba:

<h1>Hello, világ!</h1>

Gyakorlatilag ennyi az egész, de ahhoz, hogy meg is tudjuk nézni az eredményt, még el kell indítanunk a szerver alkalmazást a parancssorból:

ruby script/server

Nálam eltart egy ideig, mire beizzítja magát a Rubyval telepített WEBRick szerver, ezért először azt hittem baj van, de nem. Pár sorban közli a szerver, hogy mit csinál, illetve, hogy a Ctrl+C karakterkombinációval lehet leállítani és a főbb paramétereit. Ekkor nyissuk meg a böngészőben a http://localhost:3000/home/index URL-t, és ha minden igaz, ki is pipálhatjuk a témát.

Azt még említsük meg, hogy a Rails projekt létrehozása után már elindíthattuk volna a szervert és a http://localhost:3000/ cím megnyitásával kaptunk volna egy helyes kis üdvözlő képernyőt. Ez jelezte volna, hogy minden a legnagyobb rendben, a Rails működőképes és a projekt létrejött. Ezt a funkciót mindjárt eltávolítjuk, úgyhogy akit érdekel, az vessen rá egy pillantást most.

Tovább a cél felé

Előszöris az előbb létrehozott home controllert tegyük ténylegesen nyitó oldallá! Ehhez először kitöröljük a public/index.html fájlt, majd megnyitjuk a config/routes.rb fájlt, ami természetesen az aktuális URL-t képezi le egy belépési ponttá, vagyis ennek segítségével határozza meg a Rails, hogy melyik controller melyik actionjét (vagyis függvényét) kell meghívni.

Láthatjuk, hogy a megnyitott fájl tele van # karakterekkel kezdődő komment sorokkal, amik segíthetnek a beállításokban, útmutatást adnak. Nekünk most csak annyi a dolgunk, hogy lehetőleg a kommentek alá, de a meglévő route beállítások fölé beszúrjuk a következő sort:

map.root :controller => "home"

Elvileg készen is vagyunk, ha fut még a szerver, akkor megnyithatjuk a http://localhost:3000/ címet és megkapjuk a szép kis helló-világ alkalmazásunkat. Ha pedig mélyebben elmerülnénk a routes.rb képességeiben és funkciójában, akkor itt egy nagyszerű angol nyelvű leírás.

Kategóriák

A Scaffolding a CodeIgniter használók számára biztosan nem kell bemutatni, de gyanítom sok más keretrendszer használói is ismerhetik a kifejezést. Lényege, hogy mi megadjuk, hogy milyen adatokra lesz szükségünk, a rendszer pedig generál nekünk ehhez egy adminisztrációs felületet. Ahogy a CI esetén magam is megtapasztaltam már, azt mondják a Rails esetében is macerásabb jól testreszabni az így generált alkalmazásrészt, mint megírni az egészet nulláról. Ugyanakkor ez egy olyan területe a Railsnek, amit biztosan nem szabad kihagyni a tanulásból, úgyhogy ismerkedjünk meg vele!

A mostani posztnak nem célja komolyabb tervezéseket elvégezni, úgyhogy csak egy kategóriát és terméket tartalmazó táblát hozunk létre, az azokat összekapcsoló táblát (pivot table) és egyéb adatbázis elemeket a későbbiekre hagyjuk.

Kezdjük a kategóriával, ami egyelőre csak egy névből álljon:

ruby script/generate scaffold Category name:string

Ez a kis parancs egy szép rakás fáljt generál nekünk, köztük egy adatbázis migrációs fájlt is, ami nagyon érdekes, mert olyan formában jön létre, hogy minden változás az adatbázis szerkezetében nyomonkövethető és visszaállítható lesz. A migrációs fájl a db/migrate/ mappában található és az aktuális időbélyeg után a _create_category.rb nevet viseli. Érdemes kicsit tanulmányozni a fájlt, vagy akár többet is megtanulni a Rails adatbázis migrációról.

Vegyük észre, hogy bár mi határozottan egyes számban hoztuk létre a kategória állványát (scaffold=állvány), a létrehozott fájlok többsége viszont többes számban tartalmazza a kategória szót. Ez is a RoR egyik koncepciója, a modelleket egyes számban hozzuk létre, de például az adatbázisban a tábla, vagy a sablonokat tartalmazó mappa többes számot fog kapni. Hozzuk is létre az adattáblát a következő paranccsal:

rake db:migrate

Ha létrejött, linkeljük be a kategóriákat a főoldalra! A views/home/index.html.erb fájl második sorába írjuk a következőt:

<%= link_to "Kategóriák", categories_path %>

Ha leállítottuk már a szervert, akkor indítsuk el újra és próbálgassuk a kategória létrehozási / szerkesztési / törlési képességeinket és veregessük hátba magunkat.

Termékek

A mostani poszt már kezd kezelhetetlen méreteket ölteni ezért már csak a termékek kategóriát hozzuk létre:

ruby script/generate scaffold Product name:string price:float

Ennek az egésznek természetesen nem sok értelme van, ha nem tudjuk hozzárendelni a kategóriákhoz a termékeket és vice versa. Éppen ezért a következő posztot ezzel kezdem, ráadásul nem is kell rá sokat várni.

Címkék: rails ruby

egy elhalt tápegység margójára

Ha az ember gépe egyszer csak nem indul, az sosem jó. Számítógép közeli emberek ilyenkor csavarhúzót ragadnak, vesznek hozzá egy vagy néhány zombigépet és – jellemzően hangos anyázások közepette – elkezdik kisakkozni, hogy hol is van a hiba gyökere. Ezen magam is többé-kevésbé átestem, de igyekszem a kaptafánál maradni és nem fogok úgy csinálni, mintha nálam jobb IT szakembert még nem hordott volna hátán a Föld. Röviden annyi, hogy úgy döntöttem, eljött a gépcsere ideje.

Először is elnézést kérek attól a kedves olvasómtól, aki a segítségemet kérte, de választ sajnos a fentiek miatt sosem kapott. Őt arra kérném, hogy küldje el a levelét és ígérem egy napon belül válaszolni fogok. Másodszor ugyanezen történet fontos tanulsága, hogy sose töröljünk levelet a szerverről. Az igazság az, hogy én sok-sok éve gmail-t használok a levelezésem bonyolítására, de az utóbbi időben, bizonyos címeimet inkább a számítógépen tárolom. Ennek több oka is van, nincs is ezzel baj, a személyes e-mail címem beállításánál viszont meghagytam az üzenetek törlését. Szerencsére ez túl nagy problémát nem jelentett, mert a fontosabb levelezéseim megmaradtak, de ez az egy levél is olyan gond, amit könnyű lett volna elkerülni.

Szerencsére az elpazarolt időn és „kidobott” pénzen kívül ez volt az egyetlen közel-visszafordíthatatlan vesztességem, illetve az elvesztett feedjeim. Ha nagyon akartam volna, kimenthettem volna őket a régi vinyómról, de nem lett volna egyszerű. Úgy döntöttem, inkább megteszem, amit már rég óta terveztem és átnézem a delicious-ban tárolt linkjeimet és az alapján építem újra a listát. Ha meglesz, feltétlen csinálok egy szabványos mentést, illetve itt is közzéteszem a kedvenc feedjeimet. Több mint 1000 linket kell átnéznem, szerintem hétvégére meglesz.

Tervezem ezen felül, hogy csinálok egy sorozatot az általam ideálisnak gondolt környezet kiépítéséről, de már így is elég sok dologba vágtam bele, az időm pedig mindig szűkös. Majd meglátjuk…

 

zend framework quickstart

Pár napja elhatároztam, hogy folytatom a PHP keretrendszerek sorozatot, amit ott hagytam abba, hogy nézzük meg gyakorlati feladatok megoldásait a Zend Framework és Symfony keretrendszereken belül. Ehhez gondoltam jó ujjgyakorlat lesz a quickstart elvégzése. Sajnos most is rá kellett döbbennem, hogy hiába az óriási hype a ZF mögött, a dokumentáció ezen a ponton nagyon hiányos, a kezdőknek nyújtott segítség pedig minimális.

Na most már maga a feladat is elég primitív, nehéz legalábbis ennél egyszerűbb feladatot elképzelni amihez űrlap is kell és adatbázis is, de végülis ez még önmagában nem probléma. Szerintem az viszont már tényleg túlzás, hogy még a dekorátorok használatát sem mutatják meg, megelégszenek egy alap űrlap kinézettel a tutorial alkotói. Sőt, azt gondolom, hogy egy ilyen komoly háttérrel és felhasználói bázissal rendelkező rendszertől az is elvárható lenne, hogy az elkészült "műhöz" tesztek írásában is segítséget adjon. Talán túlzás, de a magam részéről azt se bánnám, ha rögtön a tesztvezérelt fejlesztést is a zászlójukra tűznék, szerintem nem állna semmiből.

Aztán hajamat majdnem kitéptem, mire rájöttem, hogy a parancssoros controller létrehozás miért nem működik. A lényeg, hogy elkezdett a Zend Framework könyvtáramból include-olni, aztán amikor megtalálta a projektet, akkor folytatta a projekt saját könyvtárából. Na most innentől kezdve az egy szép dolog, hogy mindenhol require_once meg include_once volt, de simán megnyitotta kétszer ugyanazt a fájlt, hiába létezett már a kérdéses osztály. Nem tudom pontosan megmondani, hány órát vett el ez a hiba az életemből, de nem egyet az biztos, ugyanis a legtöbb általam bevetett trükköt simán felülírta a keretrendszer, ráadásul sok minden nem is működhetett, hiszen egyszerűen rossz helyen kerestem a hibát. Az is megdöbbentő volt, hogy hány száz osztályt deklarált magának a hiba helyéig, nagyjából 150-et. El is gondolkoztam, hogy vajon mi értelme van 150+ osztályt deklarálni ahhoz, hogy létrehozzon egy controller és egy view fájlt, ráadásul mindkettőt üresen.

Na mindegy, miután rájöttem a hibára, kiiktattam az include_path-ből a zend könyvtáramat és bemásoltam a zf.php-t és zf.bat-ot a projektkönyvtáramba. Ott megadtam nekik, hogy hol vannak a zend osztályai és ment minden mint a karikacsapás. Utána a tutorialon már hamar végig szaladtam és bár a fent említett hiányérzetem igen erős volt, gondoltam "befejezem" a projektet.

Itt még jött egy nagyszerű ötletem, letöltöttem a projektet .zip fájlként és láss csodát, abban szerepeltek tesztfájlok is. Igaz nem mind, de legalább a controllerek teszt fájljai ott voltak, még ha elavult és hiányos formában is. Az elavultság nem volt vészes, csupán az application könyvtárt neveztük el a Quickstart utasításai alapján Default modulnak és pár osztálynév elé kellett ezért a Default_ sztringet beszúrni. A hiányosság viszont nagyobb problémát okozott, ugyanis az elkészült vendégkönyv az email cím és üzenet mezőkön kívül egy csrf védelmet és egy captchát is tartalmazott. Na most itt ugye pont az a lényeg, hogy ne lehessen automatizált módon kitölteni, így valahogy meg kell tudni, hogy mit vár a rendszer válaszként, csakhogy az űrlap objektumot tartalmazó view objektumhoz, pontosabban a tényleges végrehajtást végző controllerhez nem olyan könnyű hozzáférni, legalábbis nekem nem jött össze. Szerencsére a megoldás sokkal egyszerűbb, ennek a bejegyzésnek hála, gyorsan megvolt. Érdekesség, hogy miután leesett nekem is, hogy a session adatokból hamarabb megvan az eredmény, azért rájöttem arra is, hogy ez a megoldás a csrf érték kinyerésére is egyszerűbb, mint a "hivatalos", válaszból kiolvasós verzió, mondjuk ez lehet, hogy szőrszál hasogatás.

Ezen kívül még csak annyi dolgom volt, hogy kiiktassam az adatbázis újbóli létrehozását a setUp-ban, ugyanis az sqlite adatbázis fájlt a rendszer fogta, így nem lehetett törölni. Bár nyilván rá lehet jönni, hogy hogyan engedtessük el, de nekem erre most nem volt energiám, talán majd a jövőhéten. Illetve ha valaki tudja a megoldást, akkor várom sok szeretettel! ;)

Ezért megdolgoztam keményen. Bár a Zend vs Symfony sorozat gyakorlati része csak most kezdődik, előny a franciák büszkeségénél.

Címkék: zend framework keretrendszerek

programozók, kések és keretrendszerek

Előszöris remélem senki nem veszi tolakodásnak, ha egy kicsit kisajátítok egy fórum témát. Mentségemre szóljon, hogy a többség valahol az én hozzászólásomhoz reagált. Sokat fogok most ollózni, de igyekszem minél szabatosabban fogalmazni és pontosan kifejteni a véleményemet. A téma alapjául egy blogmark szolgált, de a bejegyzéssel olyan szinten nem értek egyet, hogy linket sem adok neki. A Weblaboros beszélgetés viszont itt elolvasható: http://weblabor.hu/blogmarkok/103683.

programozók és kések

Kezdeném ott, hogy legfőbb vitapartnerem szerint két féle programozó van: a favágó, aki konvenciókat keres és keretrendszert használ, és a művész, aki kihívásokat keres és megoldásokat alkot. Tiszteletben tartva a véleményét és ígérve, hogy nem citálom őt többet itt elő, én mégis máshogy csoportosítanék.

  • Én azt gondolom, hogy először is vannak a kezdők és spagettihuszárok. A kezdőkből természetesen bármi lehet később, a spagettihuszár, aki hosszú évek óta képtelen az érdemi fejlődésre. Ők azok, akik sosem szánják rá az időt, hogy megismerjenek új eszközöket. Jellemzően azt hiszik, PHP-ban programozni az tud jobban, aki több függvényt ismer a doksiból, vagy előbb meg tud írni egy 100 soros programot úgy, hogy nem dob hibaüzenetet. Őket valószínűleg el kell fogadni olyannnak amilyenek és menekülni tőlük ahogy lehet. Idegennek a munkájukba belejavítani tilos és életveszélyes...
  • Aztán vannak a haladók, akik olvasgatnak mindenféle okos dolgot, tanulnak a jobbaktól, összerakják a kis elemeket és és fejlesztgetik a saját toldozott-foltozott rendszerüket. Sokszor abba az álomba ringatják magukat, hogy a több megabájtos keretrendszerek használatának elkerülésével, sokkal gyorsabb programot kap a felhasználó, kevesebb áramot fogyaszt a vas és mivel ők már olvastak ilyen-olyan biztonsági résekről is, ezért "tudják", hogy ők már védve vannak. Gyakran említik azt is, hogy a nyílt forráskódú cuccokban bárki könnyen talál hibát, ráadásul még publikálhatják is a réseket, így egy potenciális támadónak csak meg kell keresnie egy foltozatlan hibát. Bezzeg a jó kis sufnituning admin oldal mindig működni fog. Ebben ugyan elvileg lehet is igazság, de szerintem 99%-uk sosem futtatott egy tesztet sem, sem Unit, sem biztonsági tesztet. Illetve hasonló százalékban lehetnek ők magányos farkasok is, már a munkát illetően. Ha már elvégeztek egy munkát, akkor az valószínűleg azért többé-kevésbé rendben van, de ha egy kicsit is fontos a projekt, akkor érdemes portolni a régi tartalmat, különben az ember csak a haját tépi az egyedi megoldások "szépségén".
  • Aztán vannak a rajongók. Mint az élet minden területén, itt is vannak, akik egy keretrendszer elkötelezett hívei és isten se tudná meggyőzni őket, hogy nem biztos, hogy ugyanaz a rendszer a legjobb választás mindenre. Jobb esetben ez azért egy elismert és komoly rendszer, ez esetben valószínűleg megéri megtartani és használni, amit átveszünk tőlük, feltéve, hogy az nagyjából legalább működik. Ők általában szívesen segítenek azoknak, akik most találták meg rajongásuk tárgyát és igyekeznek a haladókat is annak használatára buzdítani. Publikálni ritkán szokták, de kisebb-nagyobb módosításokat végeznek a keretrendszerükön.
  • Vannak az igazi használók, akik kipróbálgatnak mindent, ami felkelti az érdeklődésüket és azt használják, amelyiket az adott szituációban a legjobbnak találnak. Közölük sokan hozzá is tesznek egy-egy rendszerhez, esetleg publikálják is a tapasztalataikat, arra viszont kevésnek van ideje, hogy kezdőknek segítsen. Csapatban szívesen dolgoznak, de még nem feltétlenül ők a vezetők.
  • Végül pedig vannak a guruk, akik nem csak kenik-vágják a legjobb praktikákat, de össze is tudják szedni a gondolataikat, projektmenedzsmentben is otthon vannak. Képesek precízen kitalálni a céljaikat, megvitatni a tapasztalatokat és végigvinni egy komoly fejlesztést.

Na most, ha az a kérdés, hogy ezek közül melyik a favágó és melyik a művész, én nem tudnám megmondani. Érzem, hogy nem tökéletes az asszociációm, de nekem kicsit olyan ez, mintha azt kéne eldöntenem, hogy kést készíteni vagy a késsel fát faragni nagyobb művészet-e. Vagy épp aligha jutna valakinek eszébe, hogy egy faragott fa értékét a kés művészi értéke befolyásolja. Na de mindegy is. A lényeg, hogy kést a guruk és a haladók készítenek, a kezdők és spagettihuszárok fel se fogják, hogy mi az, a többiek pedig választanak egy szép kést és farigcsálnak. Ráadásul nem biztos, hogy csak a költséghatékonység miatt, lehet, hogy nem jó késkészítők vagy épp pont ez untatja őket...

keretrendszerek

És akkor most szépen, szájbarágósan összeollózom, hogy miért kell nekünk keretrendszer.

mit tudnak?

  1. Kialakítanak egy jó struktúrát a létrehozandó programnak. (Tipikusan MVC valamilyen továbbfejlesztéssel)
  2. Meghatároznak egy egységes kódolási stílust.
  3. Adnak egy sor hasznos modult, osztályt, függvényt.
  4. Jól dokumentáltak. (Legalábbis remélhetőleg)
  5. Automatizálnak sok biztonsági megoldást és könnyen elérhetővé tesznek továbbiakat.

kellenek ezek?

  1. Az átgondolt struktúra nekem megúszhatatlannak tűnik, mert fontos, hogy a fejlesztő mindig tudja, hogy mit hol talál, akkor is ha nem ő írta az adott részt. Persze tömegével látni még mindig olyan szoftvereket, hogy minden funkció be van vágva egy külön php fájlba, a közös részek meg copy-paste alapon ott figyelnek az összesben, kezdve az adatbázis-kapcsolattól az analytics javascript kódjáig minden, de ezek az uramisten kategórába tartoznak. (Hemzsegnek a biztonsági hibáktól, átláthatatlanok és karbantarthatatlanok.) Tehát miért is lenne jobb, ha én hoznám létre a struktúrát egyesével egy sima másolás vagy parancssori parancs kiadása helyett?
  2. A kódolási stílus egységesítése majdnem ugyanaz, mint a struktúráltság, csak egy másik vetülete ugyanannak a problémának. Ahol 1-nél több programozó van, ott már érdemes konveciókat alkalmazni. Érdemes kiindulni abból, hogy előbb-utóbb, minden szoftverhez több, mint 1 programozó fog tartozni és nagy valószínűséggel nem kerül egy projektbe két programozó, aki azonos stílust használ. A konvenciók használata biztosítja, hogy a teljes mű mindenkor jól olvasható maradjon, függetlenül attól, hogy ki végezte el a változtatásokat. Érdekesség, hogy míg a legtöbb rendszer a PEAR standardra hivatkozik, mégis szinte mindenki változtat rajta.
  3. A modulokat, függvényeket ha akarom, használom, ha nem akarom, akkor meg nem. Ráadásul ha nem akarunk nagyon egyedi külső modulokat beilleszteni - amit amúgy általában semmi nem tilt -, akkor egy olyan kódot kapunk, amit az azonos kódolási stílus miatt sokkal kellemesebb és gyorsabb olvasni, elemezni. Pláne ha az ember szeme már "ráállt" a kódolási stílusra. A rendszerek többsége automatikussá teszi ugyan a betöltést, de az utolsó pillanatig nincs semmi betöltve (csak a betöltő modul), így hiába több megabájt egy rendszer, a jellemző futása nem lesz lényegesen hosszabb egy bármilyen lecsupaszított programnál. Persze a késes példához visszatérve, nem mindegy, hogy valamilyen feladathoz a bozótvágóval látunk neki vagy bicskával...
  4. Az egyszemélyes rendszerek dokumentáltsága szinte sosem veszi fel a versenyt egy komoly nyílt keretrendszerrel. Az ugyan tény, hogy ez még nem veszi le a programozó válláról a dokumentálás felelősségét, de mégis nagy segítség lehet. Ráadásként sok esetben még ehhez a feladathoz is kész eszközöket kapunk a keretrendszerrel, amik egységessé és gyorsá teszik ezt az amúgy unalmas munkát.
  5. Ha valamiben igazán pocsék a programozók nagy része, az a biztonsági kérdések vizsgálata. (Engem is beleértve.) Egyszerűen mire kiizzadunk magunkból egy funkciót, ami működik, és főleg működik a megbízó gépén(!), plusz még többé-kevésbé hülyebiztos is, addigra már rég a következő, vagy következő utáni funkció megvalósításán jár az agyunk. Természetesen itt óriási előny, ha az embert órabérre fizetik, de legyünk őszinték, a főnökök se biztos, hogy örülnek, ha a drága programozók már "kész" funkciókkal molyolnak. Egy jó keretrendszer ilyenkor a legjobb barát a Földön. Az XSS, CSRF és SQL befecskendezés és egyéb védelmek ha nem is teszik egy csapásra tökéletessé a szoftvert, de mindenképp sokkal magasabb szintre emelik biztonságot. És, hogy tgr-t idézzem: "Saját keretrendszer használatának lehet értelme (bár ez nem ugyanaz, mint az eredeti cikkben szereplő no-framework, aminek szvsz nincsen), saját XSS szűrőének legfeljebb akkor, ha XSS-re specializálódó biztonsági szakértő vagy."

ennyi?

Távolról sem. A teljes eszköztár keretrendszerenként más és más még volumenében is, de olyan eszközök, mint a gyorsítótár kezelés, adatbázis és futási mutatók vagy a unit testing támogatása ma már mindegyik komoly rendszerben elérhető.

jó, de nem túl lassúak ezek?

Erről azt gondolom, hogy ez ennél összetettebb kérdés.

Először is ahogy nem ér összevetni egy html oldal beolvasási idejét egy adatbázisból dolgozó php oldal feldolgozási idejével, ugyanúgy nem ér egy átlagos php oldalt összevetni egy objektumorientált, biztonságos működést garantáló keretrendszer futási sebességével. Ha tényleg annyira fontos nekünk hogy hány századmásodpercig izzasztjuk a szervert egy oldal összerakásával, akkor rengeteg olyan eszközt kapunk, amivel ez a kép akár meg is fordítható. Ehhez nem kell más csak egy kis bonyolultság a feladatba és egy jó gyorstárazás a keretrendszerbe. Ugyanakkor még a legegyszerűbb oldalnál is hasznos egy gyors framework, mert ilyen esetekben az alapértelmezett konfiguráció sem lesz észlelhető időígényű, ráadásul a többi kedvező szolgáltatást és a gyors bonyolítás lehetőségét is megtarthatjuk.

Ugyanakkor az eddig leírtaknál fontosabb, hogy a renderelési idő normális esetben csak minket, fejlesztőket érdekel. Ha időről van szó, akkor sokkal fontosabb a fejlesztés és a betöltés ideje. Előbbit a keretrendszer óriási mértékben csökkenti, utóbbit pedig szinte nem befolyásolja. A betöltési hossza ugyanis sokkal inkább függ a megjelenítendő képek, szkriptek és stíluslapok számától és méretétől, mint a php futási idejétől, legalábbis amíg azt 1-2 tizedmásodpercen belül tudjuk tartani, addig biztosan.

megéri a sok tanulást?

Hosszú távon mindenképp. Aki még nem ismer egy keretrendszert se, annak bármelyik elismert szoftver sok újdonságot fog hozni, a többieknek pedig ezt már úgysem kell mondani.

Általánosságban azt hiszem elmondható, hogy kisebb feladatok megoldására minden framework alkalmas, ha pedig olyan komolyságú projektünk van, amelyik megvalósításához egy általunk ismert rendszer sem elég rugalmas, akkor is óriási segítség az ismeretük. Ha ilyen feladatba ütköznék, akkor én biztosan először körülnéznék, hogy melyik rendszer áll a legközelebb az elképzeléseimhez, akár az addig ismeretlenek közül is. Ha arra jutnék, hogy egyik sem jó, akkor a legvalószínűbb az, hogy a PHP sem a megfelelő nyelv a feladat megoldására. Illetve amennyiben mégis PHP-ban kellene dolgoznom, akkor is egy már létező rendszert alakítanék át az igényeim szerint, ebben egészen biztos vagyok.

Címkék: php keretrendszerek

a google már visszaszámol

Az eredeti (angol nyelvű) Google kereső oldalon az itthon "Jó napom van!"-ként ismert "I'm feeling lucky!" gombra kattintva egy JavaScript visszaszámlálót kapunk, ami visszaszámol az új évhez, méghozzá másodpercben.

Itt ki is lehet rögtön próbálni: http://www.google.com/ncr

Mivel a szkript a saját gépünk óráján alapul, így várhatóan szinte mindenkinél pontos is lesz.

Címkék: google javascript

eclipse vs notepad++ i.

A hatékony programozás nagyon fontos része a megfelelő eszközök megtalálálása. Ahogy azt már korábbi bejegyzésekben is említettem, nekem ez az Eclipse PDT, viszont mostanában sokszor megőrjít a lassúságával. Hozzá kell tennem, hogy ez jelentős részben az elavult számítógépemnek köszönhető, de még egy pár hónapot ki kell bekkelnem vele, ezért mostanában gyakran a másodlagos szövegszerkesztőmet használom, ami nekem a Notepad++. Azt hiszem ezzel nem vagyok egyedül. Igaz, hogy egy vérbeli IDE-hez képest fapados szoftver, de legalább villámgyors akármilyen számítógépen, az alapvető szövegkezelése pedig tökéletes. Nyilván rengeteg apróság van amit nem tud, de kis utánajárással a többség orvosolható. Ezek közül most kettőt mutatnék be, valószínűleg lesz még folytatás is.

Sablonok, Snippets, QuickText

Az általam ismert komoly PHP IDE rendszerek mindegyike rendelkezik valamilyen kedvenc kódok hozzáadására alkalmas funkcióval. PDT alatt erre tulajdonképpen rögtön két lehetőség is van. Egyfelől van template beállítási lehetőség, ahol tetszőlegesen hozhatunk létre sablonokat és új fájl létrehozásához vagy gyorskifejezéshez rendelhetjük őket, vagy van a Snippets ablak ahol pedig jól látható helyen, gyorsan elérhetően tárolhatjuk kedvenc kódjainkat, ráadásul ez nem is PDT függő, viszont amennyire tudom nem lehet őket gyorskifejezésekhez rendelni.

Megjegyzés: Gyorskifejezés az én szótáramban olyasmi, mint a gyorsbillentyű, csak itt le kell írni egy kifejezést és utána valamilyen "titkos" billentyűvel kell jelezni az szoftver felé, hogy ezt a kifejezést most értékelje parancsként. Például PDT-ben alapértelmezetten van egy sablon egy általános osztály létrehozására és az a cls nevet kapta. Ezért ha php fájlban vagyunk és leírjuk új szóként, hogy cls és utána egy szóköz karaktert ütünk, akkor a cls szó kitörlődik és helyette a cls néven definiált sablon jelenik meg, megspékelve azzal, hogy rögtön lehetőséget kapunk változók átírására is.

Mind a Snippets mind a sablonok lehetővé teszik változók definiálását a sablonban. Snippetsnél két lépcsőből áll a változó létrehozása, egyfelől a sablonba be kell írni a változó nevét egy ilyen alakban: $(valtozo_nev), másfelől külön meg kell adni a változót is az ablakban, ennek előnye, hogy rögtön alapértelmezett értéket is rendelhetünk hozzá és leírást is megadhatunk, mindkettő igen hasznos.

A sablonok létrehozásánál erre ugyan nincs lehetőség, csak a fenti formát kell a sablonba írni, viszont nagyon ügyesen meg van csinálva, hogy a sablon beszúrása után rögtön lehetőséget kapunk a változók átírására és Tab használatával végig is mehetünk a definiált változókon, egyesével megadva mindegyik értékét.

Notepad alatt erre nincs lehetőség ellenben van egy QuickText nevű plugin, melynek telepítése a Notepad++ esetében megszokott kicsomagolás-fájlbeillesztés-újraindítás. A dll fájlt másoljuk plugin könyvtárba, az ini fájlt a szoftver gyökérkönyvtárába és meg is vagyunk, a használata pedig elég hasonló az eclipse féle sablonokhoz. Igaz még csak elnevezett változókat sem hozhatunk létre, viszont a $ karakter elhelyezésével beszúrási pontokat hozhatunk létre, amelyek között a tab ismételt megnyomásával váltogathatunk. Egy hátránya van az Eclipse féle sablonhoz képest, az hogy az elnevezett változók hiányában nem tudunk tippet adni, hogy mit is kellene az adott beszúrási ponthoz írni, mégis óriási segítség tud lenni adott esetben. Lehet, hogy csak én voltam szerencsétlen, de a régi leírás alapján elég sokat elszenvedtem vele, úgyhogy most szólok mindenkinek, hogy már nem a Ctrl+Enter hanem a Tab megnyomására aktiválódik a funkció!

PHP Explorer, Function List

Az Eclipse elég sok féle projekt és kód nézettel, kis segítővel készíti a fejlesztőket, ezek közül is az egyik legkézenfekvőbb a PHP Explorerbe beépített fájlelemző funkció, ami alapból egy sima explorer ablaknak tűnik, viszont az egyes fájlok még tovább nyithatóak és megmutatja a bennük definiált osztályokat, osztályváltozókat, konstansokat és függvényeket. Ráadásul egy kis ikonnal még jelzi is a legfontosabb tulajdonságaikat épp csak a függvényleírást nem adja ki, legalábbis tudtommal.

Hogy mire jó ez? Két dologra is. Egyfelől ha keresem, hogy pontosan hol és hogy is van egy adott függvény definiálva, akkor gyorsan megtalálom, nem kell ténylegesen szerkesztésre megnyitnom minden fájlt. Másfelől ha egy nagyobb fájlban dolgozom, akkor nem kell végignéznem az egészet, megtalálom a PHPExplorerben a függvényt és megnyitásra odaugrik a szerkesztő a fájlban. Meg kell jegyezni, hogy mindkét funkcióra biztosít az Eclipse ennél jobb eszközöket, de általában a PHPExplorer amúgy is nyitva van, mert gyakran nyitogatok fájlokat fejlesztés közben, így többnyire én ezt használom. Igazán príma kis eszköz, aminek sajnos egyáltalán nincs ekvivalens megoldása Notepad++ alatt.

Van viszont két kiegészítő ami, ha nem is együtt de külön-külön azért ennek egy egyszerűsített verzióját biztosítja. Az egyik egész egyszerűen az Explorer nevet kapta és nem is véletlenül, mert pontosan egy explorer ablakot varázsol a szerkesztőnkbe. Ugyan kicsit zavaró, hogy nem projektenként mutatja a fájljainkat, mint az Explorer, viszont van egy kedvencek része is ami nálam gyakorlatilag a projektkönyvtárak gyüjteménye. Nem annyira intuitív, de működik.

Ehhez csapjuk hozzá a Function List nevű kiegészítőt és máris kaphatunk egy fájlelemzésre alkalmas funkciót is. Nálam régóta telepítve van, de csak most vettem rá magam, hogy rájöjjek a használatára is. A lényeg, hogy alapból nincs konfigurálva a plugin, azt nekünk kell megtenni.

Tegyük is meg. Nyissuk meg a kiterjesztés menüjében a Language Parsing Options ablakot, válasszuk ki a PHP-t és Hozzunk létre egy új csoportot Function néven, és adjuk meg a következő beállításokat:

  • Function Begin: "function "
  • Function List Name: "[\w]*"
  • Function End: "\("
  • Body Begin: "{"
  • Body End: "}"

Ha ez megvan akkor hozzunk létre egy új csoportot Class néven és adjuk meg a következő beállításokat:

  • Subgroup: Functions
  • Function Begin: "class "
  • Function List Name: "[\w]*"
  • Body Begin: "{"
  • Body End: "}"
  • Body Begin To Body End: "{"

Biztos ami biztos, csináltam egy screenshotot a beállításokról:

Elvileg ha ezután elmentjük a beállításokat és megnyitunk egy php fájlt, akkor a Function list ablak valami hasonlót fog mutatni:

Mára ennyi. Előbb-utóbb biztos hasznos lesz valakinek. Köszönet az eredeti FunctionList bejegyzésért Danielnek (aki ezt nem fogja megérteni), és persze a szoftverek és kiegészítők fejlesztőinek. ;)

 

Címkék: szoftverek eszközök eclipse notepad

eftépézz okosan

Először is elnézést mindenkitől, aki szerint ez a cím most a magyar nyelv durva megerőszakolása volt. Valahol egyetértek, de a blog indításakor elhatároztam, hogy amennyire lehet, igyekszem mindent magyarosan írni. Nekifutottam az "ftp-zz"-nek is, de mivel mind a kettő nagyon rossznak tűnt, választottam a magyarosabbat.

A mai poszt valójában csak egy kedvcsináló, nem sokára publikussá teszek egy nyílt forráskódú kis cuccot, ami egy rakás dologban segíteheti a fejlesztők mindennapjait. Az egészet arra építve kezdtem fejleszteni, hogy egy ügyfelem gépére próbáltam a Magento webáruház rendszert telepíteni. Na most a probléma ott kezdődött, hogy nem kaptam Control Panelt (szerintem nincs is a szerveren) csak egy ftp-t, és ezért kénytelen voltam a kicsomagolt fájlokat feltölteni a szerverre. Na most az hogy a 16 megás 1.3.2.4 verzió kicsomagolva 46 mega még nem lett volna nagy gond, de a 8500 fájl okozta overhead egész egyszerűen lehetetlenné tette a műveletet.

Megmondom őszintén, hogy nem nagyon kutattam eszközök után, úgy éreztem 2 perc alatt írok egy szkriptet, ami kicsomagolja nekem a feltöltött fájlomat. Ez hamar meg is volt, viszont mivel a program csomagolta ki a fájlt és csak magának adott írhatósági jogosultságot, ezért nem tudtam módosítani azokat. Szerencsére egy php.net-ről lopott kis függvény hamar segített ezen is. Futtatás után tehát még megváltoztattam a fájlok jogosultságát is. function modeTree($dir, &$message, $mode=0777) {
  $files = glob( $dir . '*', GLOB_MARK );
  foreach ($files as $file){
    if (substr($file, -1) == '/')
      modeTree($file, $message);
    else
      chmod($file, $mode);
  }
  chmod($dir, $mode);
  return TRUE;
}

$zip = new ZipArchive;
$file = 'magento-1.3.2.4.zip';
$message = '';

if ($zip->open($file) === TRUE) {
    $folder = getcwd() . str_replace('//', '/', '/'.$_POST['unzipfolder']);
    $message .= "Kitömörítés ($folder): ";
    $message .= $zip->extractTo($folder) ? 'ok.<br />' : 'hiba.<br />';
    $zip->close();
     
    modeTree($folder, $message);
    $message .= $folder . ' írható.<br />';
}

if ($message):
  echo "    <h2>Üzenet</h2>\n";
  echo "    <p>$message</p>\n";
endif;
FONTOS: Természetesen mindennek 0777 jogosultságot adni nem a legbiztonságosabb dolog a világon, éles rendszerben mindig körültekintően érdemes kiválasztani, hogy melyik könyvtárakhoz milyen hozzáféréseket kívánunk adni. Ugyanennyire fontos az is, hogy lehetőleg csak a legszükségesebb fájlokat tartsuk a webről elérhető könyvtárainkban.

A fejlesztett kis szoftver természetesen ennél többet fog tudni. A teljes igénye nélkül:

  • Könyvtárak becsomagolása
  • Fájlok minta szerinti jogosultság kezelése
  • Fájlok minta szerinti mozgatása
  • Fájlok karakterkódolásának megváltoztatása (iconv)
  • Adatbázis(ok) sql fájlokba mentése
  • Egyszerű belépés

Egyelőre ezekre érzem úgy, hogy igényem lesz. De ha bárkinek van valami jó ötlete ezzel kapcsolatban, akkor természetesen örömmel veszem.

Még vacilálok azon, hogy rakjak-e bele fájlfeltöltést. Talán egyszerűbb lenne, de én jobban szeretem ftp-vel feltölteni a nagy fájlokat, hogy lássam a folyamatot is.

Ja és még valami! A megoldás egyelőre nem a legszebb, mert egy fájlban van a munkát végző php résztől a css-ig minden, viszont így egyszerűen feltölthető és törölhető az egész. Valószínűleg beépítek egy egyszerű időkapcsolót is, ami elérhetetlenné teszi a rendszert, ha nem módosult egy pár napig. Vélmények ezzel kapcsolatban?

Címkék: php ftp

windows parancssor trükkök

Azoknak a szerencsétleneknek, akik hozzám hasonlóan egy microsoft operációs rendszerre vannak kényszerítve valamilyen okból és ennek ellenére komolyan gondolják, hogy php-ban lehet fejleszteni, óriási segítség lehet a következő pár programocska és trükk:

Színes parancssor Windowson

Bár sokan Cygwin-t használnak a probléma feloldására, hála a jó istennek (és ennek a drága symfony-s posztnak) most már tudok kultúrált megoldást is. Symfony, PHPUnit és SimpleTest használóknak kötelező.

Megoldás: Ansicon

Installálás:  Letöltés, ansi.dll és ansicon.exe bemásolása egy szimpatikus könyvtárba és a környezeti változóknál a PATH-hez hozzáadjuk a könyvtárunkat. Ez után még be kell írni a Parancssorba, hogy "ansicon.exe -i" ezzel installáljuk a szoftvert. Persze a szoftvernek is támogatnia kell a színes szövegeket, Symfony használók erre kapnak tippet az eredeti posztban.

Virtuális könyvtárak (Symlink)

Idegesít, hogy minden projekthez be kell másolnod a keretrendszerek kódjait? Unix alapú rendszeren ilyet senki nem tesz, de mi XP használók alapból nem sokat tehetünk. Vagy legalábbis meg kell dolgozni érte. Szerencsére nem vészes a dolog.

Megoldás: Junction

Telepítés: Nincs, csak arról kell meggyőződni, hogy a letöltött junction.exe fájl előrhető legyen. (PATH)

Drag n drop könyvtárak

Ahelyett hogy hosszú könyvtárneveket begépelnénk, elég csak egy megnyitott Intézőből belehúzni az adott könyvtárat a parancssorba.

Címkék: windows kiegészítők

10 király ártáblázat dizájn

Jó lenne azt mondani, hogy a legjobb 10, de valójában csak úgy 40-50 többé-kevésbé ismert nemzetközi oldal ártáblázatát néztem meg, sőt némelyiket ehhez hasonló posztban találtam csak. Sebaj következzenek a legjobbak:

1. Brightbox

2. ConcetpShare

3. GetBackboard

4. JobSpot

5. JumpChart

6. ProtoShare - régi

 

7. Shopify

 

8. Squarespace

 

9. The Resumator - régi?

 

10. Wufoo

 

Címkék: design táblázat

vektor-ember karácsonyra

Bár messze még pont két hónap van hátra az ünnepig, egyre több helyen már erre való hivatkozással gyűjtik a látogatókat az Internettel, dizájnnal, programozással foglalkozó nemzetközi portálok.

Ezekből fogom mostantól megosztani a kedvenceimet. Most szólok, hogy lesznek, amik nem ideiek, de nem hiszem, hogy mindenki ismeri őket.

Kezdem rögtön egy tavalyival, a WeFunction tavaly novemberben publikálta ingyenesen letölthető és használható vektoros emberkéjét.

Címkék: ingyen karácsony vektor

eszközök webes képekhez

Optimalizálás

Sajnos nagyon sok webes fejlesztő magasról tesz arra, hogy az általa létrehozott weboldal hány kéréssel fordul a webszerverhez és mekkora fájlokat töltet le a felhasználóval, míg egyszer bele nem fut valamilyen ebből fakadó problémába, jellemzően lassan töltődő oldalakba. A YSlow nevű Yahoo eszköz megjelenése elég sok cikket eredményezett a maga idejében, de sokan biztos még mindig felesleges macerának tartják az optimalizálásokat. A következő eszközök talán őket is meggyőzik, hogy nem ördöngősségről van szó.

A PunyPNG egyesével optimalizálja a fetöltött képfájlokat és egy zip tömörített fájlként vagy egyesével lehet letölteni az elkészült képeket.

A CSS Sprite Generator ezzel szemben egy zip fájlt vár és az abban szereplő képfájlokból készít egy sprite-ot. Együtt használva a PunyPNG-vel körülbelül 3 perc alatt előállíthatunk egy optimalizált CSS tündért. Letölthetjük az elkészült képet és kimásolhatjuk a generált CSS osztályokat.

Ikonok

Az iConvert képet alakít ikonná. Előnye, hogy külön Windows, Linux és Macintosh ikonokat is készít.

Ha kimondottan faviconra van szükség, én jellemzően ezeket az eszközöket használom: favicon.ico, FavIcon Generator, de itt találtok továbbiakat is.

Inspiráció

Wordle egy ötletes szolgáltatás: Szavak listájából, RSS url-ből vagy éppen delicious.com címkék alapján létrehoz egy címkefelhő-szerű de annál sokkal mókásabb képet. A betűtípus és egy rakás egyéb dolog még beállítható. Hátrány lehet, hogy az alkalmazás futásához Java kiegészítésre van szükség.

És végül ha esetleg elakadnál a következő weboldalad színvilágának kiválasztásával, itt egy pár oldal, ami segíthet a döntésben: kulerCOLOURlovers + Copaso, Color Sheme Designer, ColorBlender, Color Explorer.

Címkék: eszközök

angular

Miško Hevery, a Google tesztelés-specialistája egy újabban egy elég érdekes kezdeményezés híreit közli blogján, melynek neve Angular, és a GetAngular.com címen érhető el. A projekt azt ígéri, hogy egy szolgáltatás keretein belül programozás nélkül hozhatunk létre egyéni alkalmazásokat. Ez azt jelenti, hogy nincs szükség javascript programozásra és ha jól értem nincs is lehetőség szerver oldali programozásra és adatbázis berhelésre a szó megszokott értelmében. Ehelyett alapvetően html-el dolgozunk, ami persze kap némi kiegészítést. Ennek segítségével bizonyos konvenciók alapján módosítjuk a szerver oldali részt.

A kezdeményezés érdekesnek tűnik, a kipróbálás "természetesen" ingyenes, de a professzionális változat is megfizethetőnek tűnik, feltéve, hogy arra már csak bevált szolgáltatásoknak van szüksége.

Az alábbi videóban egy gyors bemutató keretében 5 perc alatt elkészítenek egy egyszerű alkalmazást.

Misko kapcsolódó cikkei:

Címkék: angular

php keretrendszerek iv.

Avagy Zend vs Symfony I.

Sajnos igazán behatóan egyik rendszert sem ismerem, de egy-egy kisebb projektet már összeraktam a másik két rendszerrel is, a hivatalos tutorialokat végigcsináltam, így talán mondhatom, hogy rálátásom már van.

Érdemes megjegyezni, hogy a Zend Frameworköt nagyon sokan egy komponens-könyvtárnak tartják, de ez csak annyiban igaz, hogy akként is hibátlanul funkcionál. Ugyanakkor szerintem (majdnem) mindenre képes, amit egy modern MVC rendszertől elvárhatunk, ellenben ezt a struktúrát egyáltalán nem kényszeríti a felhasználókra.

Fejlesztés

Úgy érzem a Zend mellett szólhat, hogy amögött sokkal inkább konszenzus van, míg a Symfonyt egy egyszemélyes hadjáratként jellemzik. Az igazság viszont az, hogy Potencier elég jó programozó ahhoz, hogy ez ne okozzon túl nagy fejfájást. A két projekt fejlesztésére sem panaszkodhatunk, mindkettőhöz szinte hetente jönnek ki frissítések.

Sebesség

A jelenlegi Symfony verzió a legtöbb kritikát egyértelműen a sebessége miatt kapja, a fejlesztők viszont azt ígérték, hogy erre fogják a legnagyobb hangsúlyt fektetni a közeljövőben. Ígéretes benchmarkokat már mutattak, meglátjuk mi jön össze belőle. Az biztos, hogy egyszer-kétszer elkerekedett a szemem, amikor láttam egy futási fát Symfony alatt, valószínűleg tényleg van ott mit faragni. Érdemes megjegyezni, hogy a Zend is rendszerint alulmarad sebességben a kisebb rendszerektől, ami alighanem annyit jelent csupán, hogy több mindenre képes, valamint az is elgondolkoztató, hogy a PHP objektumkezelésén is talán lehet még csiszolni, még mindig elég költséges az objektum generálás. Mindezek ellenére egy kisebb weblapon sosem fog érződni, hogy ez most lassabb, mert Zendet/Symfonyt használ, ha csak a fejlesztő el nem baltáz valamit. Egy nagyobb projektnél viszont biztos hogy nagyon hamar meghálálja magát a jól átgondolt struktúra.

Tanulás

Szerintem ebben a kérdésben nincs egy ligában a két rendszer. A Zend elemei jól le vannak írva, de hogy hogy kéne a keretrendszert rendeltetése szerint használni az nem igazán. Van ugyan egy hivatalos tutorial, de mint korábban említettem, az is bugos. A bugot ugyan valószínűleg javították azóta, de azért ez azt is jelzi, hogy nem igazán foglalkozik a kérdéssel a fejlesztői gárda.

A Symfony ehhez képest már túlzás is. Nagyszerű leírások és tutoriálok tömkelegei, az egyetlen probléma, hogy nagyon-nagyon részletes. De legalább aki átrágja magát a végtelennek tűnő anyagon, az utána úgy érzi, hogy tud mindent. Ami persze nem igaz...

Kódgenerálás

Régebben irtóztam mindenféle kódgenerálós dologtól, de most már kezdem megszeretni. A két keretrendszer itt is hozza a róla kialakult képet. A Zend ad pár parancsot a fontosabb kódrészek generálásához, míg a Symfony eláraszt a különböző variációkkal. Nem mondom, biztos hasznos mindegyik, de egy kezdőnek szinte megtanulhatatlannak tűnik. Az új NetBeans viszont nagyban segít ezen a kérdésen, úgyhogy újoncoknak erősen ajánlott az új IDE. (Erről később szeretnék részletesebben is írni, jelezzétek ha komoly igény lenne rá.)

Külsős fejlesztések, pluginek

Ez a fejezet mindkét projekt esetében szinte fikciónak tűnik. Mindkettőről lehet tudni, hogy nagyon sokan használják, fejlesztenek vele ezerrel, ugyanakkor a nyílt forráskódú projektek amiket találtam, egytől-egyig kezdetlegesek és jellemzően hemzsegnek a hibáktól.

Ez alól talán csak a Magento kivétel, ami valóságos buzzword lett mostanában. Az is lassan vezető e-commerce megoldássá válik, ugyanakkor még ezt a rendszert se mondanám tökéletesnek, megszenvedtem vele mire feltelepítettem a gépemre.

Csalódás, hogy mostanában egész sok open source fejlesztést néztem át a sourceforge-on, de alig-alig akad olyan amelyik akár csak egy stabilabb béta szintet elérne és emellett bevált keretrendszert használna.

Konklúzió

Most még nincs, mert hamarosan jön egy folytatás, ahol az gyorsítótár kezelést, űrlap generálást, adatellenőrzést, hitelesítést és úgy általában a biztonságot szeretném egy kicsit górcső alá venni.

Talán annyit azért meg lehet már most állapítani, hogy a nagyon-nagyon jó programozóknak és/vagy nagyon nagy projekteknek inkább a Zend flexibilitása lesz a nyerő, aki viszont szereti ha minél több nyűgött levesznek a válláról vagy akinek nem világmegváltó gondolatai vannak, hanem gyorsan szeretne jó minőségű kódot létrehozni az talán jobban jár a Symfonyval. Mindenesetre a Jobeet tutorialt minden programozónak végig kéne olvasnia egyszer, aki nem tartozik a közvetlen programozói-elithez.

Címkék: php symfony zend framework keretrendszerek

pénzügyek, számlák, közös költségek és kölcsönök

Már nagyon régóta kerget a gondolat, hogy kéne írni egy jó kis pénz- és kölcsönmenedzser programot, de valahogy mindig oda lyukadok ki, hogy erre most nincs időm és pénzem. Mivel viszont közben a szükségem egy ilyen eszközre egyre nagyobb lett, gyorsan körülnéztem az elmentett linkjeim között, hogy mit lehetne gyorsan használatba venni. Legnagyobb megdöbbenésemre semmit sem találtam.

Hogy kicsit konkrétabban taglaljam az igényeimet:

  • tudjam vezetni rajta a kiadásaimat és bevételeimet partnerek szerint
  • adjon összesítést a kiadásaimról és bevételeimről
  • kezeljen közös költségeket, minél összetettebb költség és tehermegosztást tudjon kezelni
  • legyen minimum megfizethető (5-8$/fő/hó max)
  • tudjon angolul
  • legyen szolgáltatás vagy szolgáltatásként futtatható szoftver.

Előny ha:

  • tud magyarul
  • ingyenes
  • képes projektmenedzselésre is

Projektmenedzser szoftverekkel amúgy rogyásig voltam, de arra igazából van külön eszközöm, úgyhogy olyan nagyon nem érdekelt.

Elkezdtem keresgélni a delicious.com-on a közös tudásbázisra építve, sorra az alábbi linkeket dobta a gép:

  • http://www.mint.com/
  • http://www.wesabe.com/
  • http://www.freshbooks.com/
  • http://sidejobtrack.com/
  • https://www.buxfer.com/
  • http://www.gnucash.org/
  • http://www.getcashboard.com/sign_up
  • http://pulseapp.com/
  • https://www.pearbudget.com/
  • http://www.getharvest.com/
  • https://money.strands.com/moneystrands/
  • http://lessaccounting.com/
  • https://www.moneytrackin.com/
  • https://www.billmonk.com/
  • http://basecamphq.com/

Ennyi fért azt hiszem az első oldalra. Nézzük őket sorra:

Mint.com: amerikai irányítószámot kért. Ha nagyon akartam volna biztos ki lehetett volna trükközni a dolgot, ráadásul nagyon szép az oldal és az ígéret szerint "csak" reklámból élnek. Mondjuk ha beindul a bolt akkor eleve jobb egy olyan szolgáltatás, ami azért reklám-mentesíthető, de nem ez volt a fő ok, hanem inkább olyan szolgáltatást kerestem, ahol szívesen látott vendégnek érzem magam.

Wesabe.com: talán csak türelmetlen voltam, de úgy láttam ez nagyon nem az a szoftver amit én kerestem. Ez inkább valami kollektív tanácsadói klubnak tűnt. Gondolom reklámokkal is tele...

Freshbooks.com: nagyon profik külalakra, de úgy érzem ez inkább egy projektmenedzser, mint pénzügyi. Biztos gyönyörű számlákat és értesítéseket küld, de a használhatatlan ingyenes verzión felül a legolcsóbb szolgáltatás is 19$/hó, ami szerintem bőven túl sok. Bár nem próbáltam ki, így biztosan nem tudom, de szerintem alkalmatlan de minimum kényelmetlen arra, amire nekem kell.

SidejobTrack.com: nem jött be az oldal. Ilyenkor jön rá az ember milyen könnyű elbukni egy potenciális ügyfelet...

Buxfer.com: nálam ez lett a nyerő választás. A design ugyan nem túl csili-vili, de abszolút használható, a funkcionalitás letisztult és (nekem) kézre is esik. Az alap szolgáltatás ingyenes és tulajdonképpen teljes, de teljes szolgáltatás is csak 3-4 dollár havonta. Bónuszként még magyarul is tud, forintot is ismeri, sőt költési kereteket is meg lehet adni és még figyelmeztetések is vannak. Mindezek tetejében ha jól láttam még egy programozói API is elérhető, de még nem volt időm komolyabban tanulmányozni. Egyelőre tökéletesnek tűnik.

GnuCash.org: ez nem szolgáltatás, hanem egy nyílt forráskódú szoftver, pc-re (talán Windowsra?) telepíthető. Nem tanulmányoztam alaposabban.

GetCashboard.com: ez (is) inkább egy projektmenedzser, mint egy pénzügyi segítő. A design amúgy elég visszafogott, az ingyenes verzió pedig használhatatlan, de legalább teljes verzió valamivel barátságosabb a freshbook árainál.

PulseApp.com: na ez egy nagyon komoly szoftver. Igaz úgy látom náluk sincs projektmenedzsment, de nagyon jól néz ki az oldal. A legkisebb fizetős verzió 9$/hó, ami nekem kicsit sok most, de tényleg nagyon szép az oldal. Egy ingyenes verzióra mindenesetre regisztráltam magam és kipróbáltam. Elsőrangú ahogy új számla regisztrálása közben új projektet vagy akár új ügyfelet enged létrehozni, de megosztott számlát nem tud kezelni, vagy ha igen, akkor még tanulnom kell, hogy hogyan. Azt hiszem jelentések nélkül használhatatlan az alkalmazás, de összességében azt hiszem ez a program a pénz-menedzsment basecampje. (Amúgy a basecemppel is tud szinkronizálni.)

PearBudget.com: jópofa szolgáltatás, de sajnos nem teljesítette az igényeimet. A projekt alcíme "Really Simple Budgeting" találónak tűnik, de talán túlságosan is egyszerű az a budgeting. Viszont 3$/hó-ért egy korrekt szolgáltatás azoknak akiknek nincs szüksége közösködésre. Ami igazán különlegessé teszi az eszközt az az, hogy várakozásokat is meg lehet, sőt kell adni. Vagyis beállíthatod, hogy mennyit költesz fodrászra vagy nyugdíjra havonta, illetve, hogy mennyi lesz várhatóan a bevételed. Ha ez megvan, akkor már csak el kell kezdeni bevinni a tényleges számlákat, és gondolom egy elég jó képet kap a végén az ember a realitásról.

GetHarvest.com: ez is inkább projektmenedzser, azon belül is inkább az alsó kategória.

MoneyStrainds.com: nem akarom leszólni őket, de ez sem az ami nekem kell. Igazából a design nem fogott meg, de a poszt kedvéért beregisztráltam, mert azért témába vágónak tűnt a szolgáltatás. Nem volt szimpi, hogy nem nagyon tájékoztattak, hogy mi és mennyibe került, csak az derült ki, hogy ingyen regisztrálhatok. Most hogy beregisztráltam, úgy érzem ez valami nagyon hasonló lehet, mint a Mint.com, csak nem olyan szép. Bejelentkezés után rögtön el akarta kérni a bankkártyám adatait (persze az oldal hemzseg a biztonságra utaló logóktól), hogy automatikusan lekérhesse a költéseimet, meg persze alapból 10 ajánlattal megtalált bejelentkezéskor. Pár kattintás alapján nem találtam "partner" hozzáadási lehetőséget, még kevésbé közös kiadások vezetésére szolgáló lehetőséget. Van viszont egy "community" fül is, sanszos, hogy ott hasonló közösségi ötletelés, "tanácsadás" megy, mint a Wesabe.com oldalán. Eddig jutottam, akit érdekel vagy használja esetleg megírhatná a tapasztalatait.

Lessaccounting.com: ez is inkább a projektmenedzser, ami azért kicsit jobban fókuszál a bankszámlák és számlák kezelésére. Utóbbit ingyen is szolgáltatja, a projektmenedzser viszont 20$/hó minimum.

Moneytracking.com: ha tehetem majd adok nekik még egy esélyt, de egyelőre megbuktak nálam. Hogy miért? Először is magyarul fogadtak, de hibásan és szinte minden oldalon vegyesen kellett magyar és angol szöveggel találkoznom, és nem sikerült igazából regisztrálnom sem. Macerás volt, hogy a captchát nem sikerült megfejtenem, hol kitörölte a jelszavamat az előző próbálkozásból, hol meg a megváltoztatott captcha alatt kellett volna kitörölnöm az előző próbálkozás eredményét. Ráadásul bár magyarul beszélt hozzám, de minden alapértelmezetten amerikai beállításokkal jött fel. Szóval biztos összejött volna, de kényelmetlen volt. A legcsúnyább az egészben, hogy amikor feladtam és meg akartam keresni a szolgáltatásokat, hogy összefoglalhassam, akkor úgy csinált a szoftver, mintha ezer éve beregisztráltam volna már... A design sem egy nagy durranás, a szolgáltatások listája viszont ígéretes és úgy látom valami apit is fejlesztenek, amit mi fejlesztők szeretünk amúgy. Gyerekcipő efektus, azért én drukkolok nekik.

BillMonk.com: amikor megláttam az oldalt rögtön rájöttem, hogy ezt kerestem a könyvjelzőim között. Itt már jártam. (Amúgy a projektmenedzserként aposztrofált oldalakon is, de ez most mellékes.) Rögtön be is regisztráltam és tulajdonképpen nem is csalódtam. Jópofa, hogy nem csak pénzügyeket, hanem ingóságokat is tud kezelni, viszont kellemetlen, hogy partnereket csak úgy lehet felvenni (ha jól értem az FAQ-t), hogy azok beregisztrálnak. Úgy tűnik a szolgáltatás ingyenes, a pénzük valószínűleg az Obopay nevű fizetési eszköz terjesztésében és az átutalásokban van vagy lehet. Magyarul nem tud, illetve sajnos a forintot sem ismeri, ami kicsit fura, mert amúgy nagyon sok pénznem elérhető. Összességében azért tetszett az oldal.

Basecamp.hq: talán a legismertebb projektmenedzser-szolgáltatás, ha jól tudom a RubyOnRails létrejöttének egyik fő oka és de-facto szabvány. Őszintén szólva ennek ellére soknak tartom a 24$/hó-s minimum árat, de nekem most így se, úgy se felel meg.

 

Az érdekesség kedvéért még két további találati oldalt megnyitottam, de ott már csak az érdekesebb linkeket nyitottam meg. Azoknak is a java következik:

Geezeo.com: a MoneyStraindshez hasonló szolgáltatás lehet. Nekem tetszett a designjuk nagyon. (link)

JustThrive.com: megérne egy alaposabb ránézést, mert jónak tűnik, de szintén az ingyenes, bankkártyakezelős szolgáltatás, ami nem egészen az amit én keresek. Ugyanakkor nem vagyok benne biztos, hogy nincs megosztott számlavezetés. (link)

Dimewise.com: ez egy borzasztó egyszerű kis eszköz. Havi 5 dolcsiért végtelen számú számlát vezethetünk. A kiadások és bevételek egymás alatt sorakoznak minden számlában, soronként egy leírás, dátum, összeg meg még pár apróság. Elvileg azért vannak összesítések is, de odáig nem jutottam el, mert sikerült rávennem külön macerálás nélkül a rendszert, hogy egy végtelen átirányítással megölje a Firefox fülemet, úgyhogy nem kapnak linket.

BudgetTracker: ez a szolgáltatás még nagyon ígéretes. Nem tudom, hogy azért nem ismertebb, mert a design egy kicsit gyengébb, mint a fentiek átlaga vagy csak még új, de nagyon jó kis alkalmazás, ami mindent tud, ami nekem fontos lenne. Alapvetően az ingyenes szolgáltatás is teljesen jó, de a fizetős rész is kevesebb, mint 3 dollár havonta. Utóbbi ráadásképp letölthető Excel kompatibilis formátumban és szinkronizálja magát a Google Calendarral is.

Címkék: karrier szoftverek

kedvenc firefox kiegészítőim

Mostanában többször is a fejemet vertem a falba, annyi ideig tartott mire a sztaki szótáram popup ablaka előugrott. Ennek oka ugyan többes, de gondoltam körülnézek, hogy van-e valami jó alternatíva. Nos, egy-két fordító plugint találtam, de nekem elég bizarrnak tűntek, úgyhogy egyelőre kimaradok sajnos a jóból. Ellenben a kommentekben megírhatnátok, hogy ti mit használtok fordításhoz, én meg összeszedem a kedvenc tűzrókás kiegészítőimet:

Fejlesztői eszközök

UrlParams: talán a legritkábban ezzel a kiegészítővel találkozom a hasonló összefoglalókban, pedig én nagyon szeretem, mert egyszerű és gyors. Egyetlen feladata, hogy megmutatja a weboldalnak küldött legfontosabb adatokat. Elsősorban ezalatt a post és get paramétereket kell érteni, illetve a hivatkozási oldalt, ahonnan az aktuális oldalra érkeztünk. Fel van telepítve nálam az ennél sokkal komolyabb Live HTTP Headers is, de azt valamiért ritkábban használom.

Firebug, FireQuery: A Firebugot szerintem senkinek nem kell bemutatni, aki webfejlesztéssel foglalkozik, mindannyiunk megmentője és legkedvesebb barátja. A Firebughoz rengeteg kiegészítés is telepíthető annyi féle, hogy felsorolni is nehéz lenne, ugyanakkor nekem nem nagyon volt még szükségem egyikre sem. Talán a Firequery-t mondanám kivételnek, ami nem jQuery-t használó oldalak hackelésénél segítség tud lenni a jQueryben járatosak számára.

OperaView, Chrome View: Hiába na, lustaság fél egészség. Egy kattintásos a kompatibilitás ellenőrzés vagy böngészőváltás rulez. (Nem csak fejlesztőknek.)

Én ugyan ritkán használom, de azt hiszem a sitepoint.com által létrehozott Codeburner for Firebug még egy ajánlható dolog. Ez gyakorlatilag az egyes HTML és CSS elemekről ad részletes tájékoztatót a Firebugon belül. Létezik a kiterjesztés közvetlen Firefoxhoz is a rendkívül ötletes Codeburner for Firefox néven.

Egyéb eszközök

QuickRestart: Az új Firefoxok nagyon stabilak és elég gazdaságosak memóriaügyileg, így az utóbbi pár hónapban alig használtam az újraindítás gombomat, pedig ugyanazt az őskövület számítógépet használom sok-sok éve.

NoScript: Én nagyon szeretem a NoScript programot, pedig "portál" üzemeltetőként nekem is okoz némi veszteséget a NoScript. Ugyanakkor fantasztikus dolog, hogy kézben tarthatom, hogy kinek a milyen flash mozija szívja el a kapacitást a hasznos programjaimtól, illetve a kártékony jószágokkal is sokkal kevesebb bajom van általa. Nem utolsó sorban ráadásul egy adott cégről is sok mindent elmond szerintem, hogy milyen képet adnak magukról JavaScript nélkül.

Download Statusbar: Azt hiszem ez az egyetlen kiegészítőm, ami nem hasznos inkább csak csinos. Mindenesetre sokkal kényelmesebb, hogy ha letöltök ezer dolgot, akkor nincsenek felugró ablakok, csak a fájlok egymás mellett szépen kultúráltan felsorolva a képernyő alján.

Címkék: firefox

3 szabadúszó hiba, ami sokba kerülhet

Ez a cikk a freelancefolder.com hasonló cikke alapján íródott, kiegészítve a saját tapasztalataimmal és az olvasói véleményekkel.

Amikor az ember szabadúszó, akkor az idejét árulja pénzért, szóval érdemes odafigyelni, hogy lehetőleg minden munkával töltött perc pénzt hozzon. Vannak azonban olyan tipikus szokások és hibák, amiket könnyű elkövetni, mert látszólag kevés időt igényelnek, de különböző okokból mégis túl sok időt emésztenek fel. Ilyenkor aztán értelemszerűen az órabéred csökken és csökken.Figyelj oda az alábbi hibákra és kezdj el úgy pénzt keresni, ahogy azt megérdemled!

Határok kijelölésének elmulasztása

Amikor próbálsz megélni, könnyű azt mondani a kliensednek, hogy „Hívjon bármikor, ha valami kérdése van vagy szeretne valamit megváltoztatni”. Természetesen teljes elérést akarsz adni nekik, hogy elégedettek legyenek és továbbra is téged alkalmazzanak. Csakhogy a vég nélküli elérés azt jelenti, hogy nem vagy csak nehezen tudod kontrollálni a kliensre fordított idő mennyiségét.

Megoldás: Mielőtt elkezdesz egy projektet, tudasd a megrendelőkkel, hogy a nap mely szakaszában vagy elérhető a számukra és kérd meg őket, hogy ezen kívül emailben keressenek, melyben részletesen leírhatják az igényeiket. Ilyen módon, amint dolgozni kezdesz rögtön előtted lesz a kérésük és adott eseteben azonnal neki tudsz látni a feladatnak.

Megjegyzés: Saját pályafutásom során nekem sosem volt ilyen problémám, de lehet stressz-oldó hatása, ha az ember tudja, hogy munkaidőn kívül nem fogják munkával telefonon zavarni. Az eredeti poszt hozzászólásai között többen is a telefonos kapcsolattartást átkozták, volt aki egyenesen odáig ment, hogy ő bizony telefonon nem elérhető az ügyfeleinek, illetve olyan is van, aki pénzt kér a telefonos konzultációért. Én inkább azért preferálom az emailes érintkezést, mert az írás megmarad…

Ingyen munka

Mindig lesznek emberek a Földön, akik úgy gondolják, hogy ingyen munkát végeztetni egy szabadúszóval vagy bármilyen üzleti partnerrel az egy elfogadható dolog. „Add hozzá ezt változtatást és legközelebb is veled dolgoztatok” vagy „Ó, nem vettem észre, hogy a feladat-leírás nem tartalmazza ezt a funkciót”. Ezek talán ártatlannak hangzanak, de az igazság az, hogy a kliens próbál nyomás alá helyezni, hogy végezz neki ingyen munkát. Természetesen az ingyen munka szintén az órabéred esését eredményezi, ráadásul akinek egyszer elvégzel valamit ingyen, annak jó eséllyel legközelebb is el fogsz.

Megoldás: A projekt elkezdése előtt próbálj meg mindent megtenni, hogy bármilyen kis extra igényt, ami az alap feladatokhoz reálisan tartozhat megbeszéljetek és mondd el az ügyfelednek is, hogy ez neki is nagyon fontos, mert amit nem beszéltek meg időben, az nem fog a megállapodásokban szerepelni és így elkészíteni sem tudod a kialkudott ár keretein belül.

Időrabló beidegződések

Szabadúszó sokféleképpen lehet valaki, de amikor számítógéppel dolgozik, akkor bizony nagy az esélye, hogy az ember hagyja magát kisebb-nagyobb időkre elvonni a figyelmét. Egy email itt, egy kis twitterezés/fórumozás ott, esetleg egy gyors látogatás a kedvenc híroldaladon… aztán egyszer csak azt veszed észre, hogy elment a nap és te messze nem végeztél annyi munkát, amennyit szeretnél. Mivel valamiből meg is kell élned, ezért ilyenkor biztosan túlórázni fogsz.

Megoldás: Amikor dolgozol, tűzz ki magad elé apró célokat vagy időkereteket, amíg a fentiek egyikét sem engeded meg magadnak, utána pedig gyorsan jutalmazd meg magad egy kis pihenővel. Ilyenkor végezd el ezeket a rutinokat.

Megjegyzés: Ezt a hibát magam is rendszeresen elkövettem. Az utóbbi időben lettem úrrá a problémán, nekem a következők segítettek: először is kikapcsoltam az email figyelmeztetőmet. Naponta nagyjából kétszer megnézem inkább a leveleimet. Átváltottam Netvibesról egy asztali feed-olvasóra, amit beállítottam, hogy 3 órán át egyáltalán ne zaklasson hírekkel. Ez azért is jó, mert 3 óra után viszont kapok egy jelzést, hogy ideje pihenni egy kicsit. Már csak az okoz kisebb problémát, hogy az egyik kedvenc fórumomnak nincs feedje, de szerencsére romlik is a minősége, így hamarosan az sem fog plusz időt rabolni. (Szerk: az MSN, Skype és egyéb chat programok kikapcsolása szintén nem rossz ötlet szerintem, hacsak a munkához nem kell valamiért.)

Ha úgy érzitek kimaradt valami, írjátok meg hozzászólásban!

Címkék: karrier

php keretrendszerek iii.

Ott tartom az előző epizódban, hogy összehasonlítottam a Zend Frameworköt és CodeIgnitert a saját szubjektív szempontjaim alapján és a tesztelhetőségről ejtettem pár szót.

Na most azt tudni kell, illetve aki esetleg olvasta azóta Miško Hevery blogját az tudja is, hogy a Google teszt-szakértője szerint a tesztelhetőség egyik szent grálja az úgynevezett függőség beszúrás (dependency injection, link2) és az ahhoz tartozó konténer. Na most ezek Java környezetben már jól kiforrott rendszerek, PHP-ban viszont a fejlesztők többsége szerintem még nem is hallott róla. Igaz, mostanában mintha ez a közösség is kezdené felkapni a témát. Most nem fogom mélységeiben kifejteni a dolgot, de hamarosan erre is sor kerítek, addig is ajánlom mindenkinek a fent említett Hevery, vagy Marton Fowler blogjait.

Na de nézzük mit rejteget a PHP világa a témában. Először is van egy nagy halom kis könyvtár, ami segít kezelni, megvalósítani és karbantartani a függőségbeszúráshoz szükséges konténer osztályt, ami az egyes objektumainkat a függőségeikkel együtt elő tudja állítani vagy vissza tudja adni. Ezek igen kis méretű dolgok, talán kivétel nélkül mindegyik 100KB alatti, de a Symfony keretrendszer mögött álló Fabian Potencier egy egészen vicces, 140 karakteres osztállyal is meglepte a közösséget, melyet Tweety névre keresztelt. Ami engem illet, nekem két fontos kritériumom volt a használandó könyvtárral kapcsolatban. Az egyik, hogy támogassa a konstruktoron keresztüli és szetter függvényen keresztüli beszúrást is, mégpedig azon egyszerű okból, hogy az elterjedt Java könyvtárak előbb-utóbb mind rákényszerültek mindkettő támogatására, ami nekem azt jelzi, hogy a kiforrott rendszerek nélkülözhetetlen részei. A másik elvárásom az volt, hogy álljon mögötte olyan személy vagy szervezet, ami garantálja, hogy a projekt nem hal hamvába időnek előtt. Ez számomra az alábbi opciókat hozta:

Bár nem tudom pontosan ki áll a projekt mögött, de a japán Seasar szintén elég összeszedettnek tűnik, feltételezem ők sem fognak eltűnni. Igaz, nem próbáltam a rendszerüket.

Rövidnek tűnik a lista? Valóban az, valószínűleg elsősorban azért, mert volt még egy elvárásom, mégpedig az, hogy tudjam használni a könyvtárat a már meglévő projektjeimmel. Néhány php keretrendszer szintén kínál függőség beszúrást, de amennyire a nyitóoldalaikból kitűnt, ezek többnyire integráltak a rendszerbe, legalábbis önállóan nem letölthetőek. Ráadásul ezek a rendszerek többnyire a második/harmadik vonalba tartoznak, ami az ismertségüket illeti. Persze ez önmagában nem probléma, a Kohana is egy nagyszerű rendszer a maga nemében. Ezeket találtam én, talán vannak még mások is:

Némileg később találtam összesen három Zend Frameworkel és függőségbeszúrással kapcsolatos projektet. Az egyik a Xyster nevű keretrendszer kiterjesztés volt, ami nekem több okból nem szimpatikus, a második egy Zend_Di nevű könyvtár, amiről összesen csak ezt a cikket sikerült fellelni. Ezen kívül van még egy Ossigeno nevű tartalomkezelő rendszer, amit az általam nagyra tartott Giorgio Sironi jegyez, de sajnos nem igazán fektet bele energiát.

Sebaj, a Symfony rendszere mindent tud, amire nekem szükségem van és nagyszerűen integrálható bármilyen php5-öt támogató rendszerbe, CodeIgniterben is vígan elfut.

Ezzel nagyjából párhuzamosan futottam bele egy másik tesztelhetőségi problémába, nevezetesen, hogy hogyan is kellene egy adatbázist tesztelni, ugyanis én akkorra elsősorban a Kohana ORM rendszerét használtam, ami villámgyors megoldásokat eredményez, ellenben statikus factory függvényhívásokkal működik, ami sajnos szerepel Miško feketelistáján. Ez ugyan kikerülhető, de addigra már egyre gyakrabban futottam bele a Doctrine ORM rendszerbe, melyet szinte minden komolyabb fórumon megemlítettek, beleértve az általam próbált összes keretrendszer fórumait. Kipróbálgattam és nagyon tetszett, el is határoztam, hogy majd valami komolyabb projektnél ezt fogom használni és fel is iratkoztam az RSS-ére. Pár nap múlva aztán vagy egy bejegyzés vagy hozzászólás linkjeit használva valahogy leesett, hogy a Symfony igen komolyan támogatja Doctrine-t, igaz opcionálisan működik anélkül is, de ez engem kevéssé érdekelt. Úgy döntöttem hát hogy adok egy esélyt a Symfonynak is. Amikor aztán elolvastam, hogy a Symfony alapból támogatja a Zend Framework könyvtárainak használatát, akkor igencsak rákattantam a rendszerre. Jelenleg gyakorlatilag itt tartok, a negyedik részben viszont igyekszem bemutatni, hogy miket is tanultam a Symfonyval kapcsolatban. Ha energiám engedi, akkor igyekszem még a cikk-sorozat keretein belül bemutatni a FLOW 3 és Lion rendszereket is, hátha megérdemelnek egy kis reklámot, de majd meglátjuk.

A következő bejegyzésem némileg könnyedebb témákat érint majd negyedik rész várhatóan egy hét múlva lesz elérhető, remélem sokan visszanéztek majd!

Címkék: php keretrendszerek

objektum orientált css ii.

Ott tartottunk tehát, hogy összeraktuk az oldal vázát. Természetesen messze nem vagyunk még készen.

Következzenek az oldaldobozok.

Van két objektumunk, az archív lista és az utolsó kommentek listája. Kezdetnek hozzunk létre egy egységes oldaldoboz osztályt, legyen ez .side-box:

.side-box
  { padding: 20px 80px 20px 40px;
  }
  .side-box:not(:last-child)
    { border-bottom:1px solid #ccc;
    }
    .side-box > header h3
      { margin-bottom:0; 
      }
    .side-box > header p 
    { text-transform:uppercase;
      font-style:italic;
      font-size:90%;
    }
Látható, hogy ismét figyeltünk a két alapszabályunkra: elkülönítettük a struktúrát a dizájntól, azzal hogy nem foglalkoztunk konkrét megvalósítási beállításokkal, az objektumunk jelenleg a struktúra által meghatározott méreteket fogja követni. Ezen kívül elkülönítettük a tartalmat a konténertől is azáltal, hogy az oldaldobozok gyermek elemit opcionálissá tettük, azok nem szükségesek a doboz elfogadható kinézetéhez. A gyermek elemek ugyan kaptak némi igazítást, de a lehető legkisebb mértékűt, ami az elképzeld dizájnhoz szükséges.

sidebar

Mivel viszont elképzelhető, hogy máshol is az oldaldobozokhoz hasonló stílust szeretnénk adni az objektumunknak, ezért hozzunk létre egy kiterjesztést, egy új osztály formájában:

.pop-out > section > *
  { display:block;
    background:#fefefe;
    border:1px solid #474747;
    padding:20px;
    position:relative;
    width: 120%;
    left:20px;
  }

Szóval ez most mit is csinál? Kiválaszt minden elemet, ami egy .pop-out osztályú objektumunk section elemének közvetlen gyermeke és azokat ruházza fel apró stílusbeli jegyekkel, többek között jobbra tolja őket a rendes folyásukhoz képest 20 pixellel.

"Na de akkor most mégiscsak beállítottunk egy szélességet! Mi lesz a struktúra és a dizájn szétválasztásával?" A szélességet be kellett állítani, mert a megcélzott belső elemek túl közel lennének egymáshoz, mert az objektumunknak helykitöltést (padding) adtunk. Ez most kifogásnak hangzik a saját szabályaink megszegésére, de valójában az elem százalékbeli szélesség-értéket kapott, tehát továbbra is a objektumtól függ, amit pedig továbbra is a struktúra határozhat meg.

Így néz ki, amit most létrehoztunk:

popout

Azt mondtunk, hogy az osztályokat lehetőleg mindig felső-szintű objektumokra alkalmazzuk és használjunk gyerek-választó css szelektorokat, hogy ne kelljen figyelembe venni a gyerek-elemek konkrét megvalósítását. Az objektum-orientált CSS-nek ugyanakkor az is része, hogy könnyen lehessen stílusokat mixelni egymással. Például könnyen elképzelhető, hogy egy címsor stílust olyan objektumokon szeretnénk használni, amelyeknek nincs sok köze egymáshoz. Éppen emiatt érdemes létrehozni egy objektumokra húzható fejléc és lábléc kollekciót létrehozni és azokat közvetlenül a fejléc vagy lábléc elemre alkalmazni. Ezáltal nem kell egymáshoz nagyon hasonló kódot különböző osztályokhoz hozzáadni, ezáltal egyfelől kevesebb kódot kell létrehozni, könnyebb egyszerre módosítást végezni a hasonló stílusú objektumokon, ráadásul gyorsabb is lesz a stíluslapjaink betöltése és persze azzal együtt az oldalunké is. (Szerintem ráadásul ez a megoldás párhuzamba állítható az objektum-orientált programozás interfész fogalmával, miszerint hasonló funkcionalitást/megvalósítást kívánunk meg egymástól független osztályoktól/objektumoktól - Thoer)

Hozzunk létre egy absztrakt fejléc osztályt. Ahogy észre fogod venni, az utolsó kommentjeink fejlécének egy .post-it nevű fejléc-stílust adunk. A .post-it stílus így fog kinézni:

.post-it
  { border:1px solid #db5500;
    padding: 10px;
    font-style:italic;
    position:relative;
    background:#f2965c;
    color:#333;
    transform:rotate(356deg);
    -moz-transform:rotate(356deg);
    -webkit-transform:rotate(356deg);
    z-index:10;
    top:10px;
    box-shadow:1px 1px 0px #333;
    -moz-box-shadow:1px 1px 0px #333;
    -webkit-box-shadow:1px 1px 0px #333;
  }

 

postit

Érdemes megfigyelni, hogy habár ezt a post-it stílust mi kimondottan egy objektumunk fejlécére akarjuk alkalmazni, de a .post-it osztály megírásakor szándékosan figyelmen kívül hagytuk ezt a részletet. Ennek az az előnye, hogy így adott esetben más elemekre is lehet majd alkalmazni, akár egy lábléc is lehet post-it, de akár egy teljes objektum is. Adott esetben kiterjesztést is írhatunk majd hozzá, hogy teszem azt a .post-it.important osztály hátterének színe piros legyen.

Ne zárd be a szelektoraidat, sosem tudhatod, hogy mikor lehet szükséged azokra a stílusokra!

A komponens könyvtár az objektum-orientált CSS egy nagyon fontos része, egy általános alapszabály, hogy amikor hasonló stílusokat akarsz különböző helyen használni, akkor absztrahálni kell. Természetesen előfordul, hogy valamit már beleírtunk egy osztály leírásába, azt később szeretnénk újrahasznosítani, ilyenkor kénytelenek vagyunk némileg újraírni a kódot, mégis érdemes ezt azonnal megtenni, mert egy jól karbantartott kódon könnyebb és gyorsabb kisebb módosításokat gyakran elvégezni, mint egy átgondolatlan kódot karbantartani.

Ezeket a komponenseket az oldal fejlécben és az utolsó kommentek dobozában találod:

.meta
  { font-size:75%;
    font-style:italic;
  }
.subtitle
  { text-transform:uppercase;
    font-size:90%;
    font-weight:bold;
    letter-spacing:1px;
    text-shadow:1px 1px 0 #fff;
  }

 

Poszt belsőoldal

Nos, az index oldal kész van, nézzük mit találunk a megnyitott poszt oldalán. Csak duplikáljuk az index oldalt post.htm néven és cseréljük ki az oldal header és section részét ezzel a kóddal:

      <header>
        <h1>Object Oriented CSS</h1>
        <p class="subtitle">(really just a bunch of best practices and patterns; not a new language)</p>
        <nav>
          <ul>
             <li><a href="index.htm">Home</a></li>
             <li><a href="#" class="selected">Archives</a></li>
             <li><a href="#">About</a></li>
             <li><a href="#">Contact Us</a></li>
          </ul>
        </nav>
      </header>
      <section>
        <article class="post">
          <header>
            <span class="date">September 10, 2009</span>
            <h2>Check out WorkAwesome!</h2>
          </header>
          <section>
            <img src="http://nettuts.s3.amazonaws.com/450_ooCss/img/wa.jpg" alt="Work Awesome" />
            <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse quis urna dui,
            ut tempus tortor. Aliquam enim massa, porta a vehicula in, vehicula at lectus. Ut turpis
            diam, porttitor a iaculis quis, bibendum non lectus. Nullam vitae erat a felis pulvinar
            tempor ut id leo. Aenean accumsan feugiat ultrices. Duis rhoncus eros id odio faucibus
            imperdiet. Nulla nibh mauris, placerat sagittis placerat sed, commodo in mi.</p>
            <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse quis urna dui,
            ut tempus tortor. Aliquam enim massa, porta a vehicula in, vehicula at lectus. Ut turpis
            diam, porttitor a iaculis quis, bibendum non lectus. Nullam vitae erat a felis pulvinar
            tempor ut id leo. Aenean accumsan feugiat ultrices. Duis rhoncus eros id odio faucibus
            imperdiet. Nulla nibh mauris, placerat sagittis placerat sed, commodo in mi.</p>
            <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse quis urna dui,
            ut tempus tortor. Aliquam enim massa, porta a vehicula in, vehicula at lectus. Ut turpis
            diam, porttitor a iaculis quis, bibendum non lectus. Nullam vitae erat a felis pulvinar
            tempor ut id leo. Aenean accumsan feugiat ultrices. Duis rhoncus eros id odio faucibus
            imperdiet. Nulla nibh mauris, placerat sagittis placerat sed, commodo in mi.</p>
            <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse quis urna dui,
            ut tempus tortor. Aliquam enim massa, porta a vehicula in, vehicula at lectus. Ut turpis
            diam, porttitor a iaculis quis, bibendum non lectus. Nullam vitae erat a felis pulvinar
            tempor ut id leo. Aenean accumsan feugiat ultrices. Duis rhoncus eros id odio faucibus
            imperdiet. Nulla nibh mauris, placerat sagittis placerat sed, commodo in mi.</p>
          </section>
          <footer>
            <ul>
              <li><a href="#">Digg!</a></li>
              <li><a href="#">Share!</a></li>
              <li><a href="#">Like!</a></li>
            </ul>
          </footer>
        </article>
        <article class="comments">
          <header><h2>Comments</h2></header>
          <section>
            <article class="comment">
              <header><p>First-commenter</p><p class="meta">Sept 10</p></header>
              <section><p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse quis urna dui,</p></section>
            </article>
            <article class="reply comment">
                  <header><p>Reply-commenter</p><p class="meta">Sept 12</p></header>
                  <section><p>diam, porttitor a iaculis quis, bibendum non lectus. Nullam vitae erat a felis pulvinar</p></section>
                </article>
            <article class="comment">
              <header><p>Second-commenter</p><p class="meta">Sept 10</p></header>
              <section><p>tempor ut id leo. Aenean accumsan feugiat ultrices. Duis rhoncus eros id odio faucibus </p></section>
            </article>
            <article class="author comment">
              <header><p>The author</p><p class="meta">Sept 11</p></header>
              <section><p>diam, porttitor a iaculis quis, bibendum non lectus. Nullam vitae erat a felis pulvinar</p></section>
            </article>
            <article class="comment">
              <header><p>Fourth-commenter</p><p class="meta">Sept 12</p></header>
              <section><p>imperdiet. Nulla nibh mauris, placerat sagittis placerat sed, commodo in mi</p></section>
            </article>
          </section>

Látható, hogy rögtön értelmet nyertek az újrahasznosíthatóságért tett erőfeszítéseink. Csak hozzá kellett adni a post osztályt a blog-bejegyzésünk tartalmához és máris elvégeztük a munka nagyját.


Kommentek

Nézzük most a kommenteket, remek lehetőség az objektum-orientált CSS-ben való elmélyedésre. Előszöris adjuk hozzá ezt a kódot a stíluslapunkhoz:

.comment
  { border:1px solid #ccc;
    border-radius:7px;
    -moz-border-radius:7px;
    -webkit-border-radius:7px;
    padding:10px;
    margin:0 0 10px 0;
  }
    .comment > header > p
      { font-weight:bold; 
        display:inline;
        margin:0 10px 20px 0;
      }

Ez önmagában ad egy kis stílust a hozzászólásainknak, de menjünk egy kicsit tovább. A HTML-ben vannak válasz-kommentek és szerzői-kommentjeink is.

.reply.comment
  { margin-left:80px;
  }
.author.comment
  { color:#ececec;
    background:#474747;
  }
Ahogy már korábban is jeleztem, most is figyelni kell, hogy a két osztály között ne legyen szóköz, az mást jelentene! Érdemes megfigyelni, hogy ez esetben, nem felülírjuk a .comment osztály egy-egy tulajdonságát, hanem hozzáadunk, ráadásul más-más tulajdonság-csoportot definiál a két kiterjesztés. (Ez többek között azért is érdekes, mert ezáltal úgy tudunk majd szerzői-válasz kommenteket létrehozni, hogy azt nem is definiáltuk külön. Bár ez véleményem szerint éles környezetben inkább a véletlen hozzáadott érték, mint az technika saját eredménye és következménye. - Thoer)

És akkor nézzük a kész kommenteket:

comments

Most, hogy ez megvan, adjunk hozzá egy komment-űrlapot a komponens könyvtárunkhoz:

.comments-form p
  { padding:5px;
    border-radius:5px; 
    -moz-border-radius:5px; 
    -webkit-border-radius:5px;
  }
.comments-form p:hover
  { background:#ececec; 
  }
.comments-form label
  { display:inline-block;
    width:70px;
    vertical-align:top; }
.comments-form label:after
  { content: " : ";
  }
.comments-form input[type=text],
.comments-form button,
.comments-form textarea
  { width:200px;
    border:1px solid #ccc;
    border-radius:5px;
    -moz-border-radius:5px;
    -webkit-border-radius:5px;
    padding:2px;
  }
.comments-form button[type=submit]
  { margin-left:70px;
  }
Íme a frissen létrehozott űrlapunk, lekerekített sarkú beviteli mezőkkel és egy finom kis egér-érzékeny effekttel.

commentsform

Ebben az esetben némileg kétséges, hogy van-e értelme megtartani az objektum-orientált CSS fundamentális elképzelését, miszerint a stílusoknak függetlennek kell lennie az azt megvalósító elemektől, ugyanakkor ennek az osztálynak nincs sok értelme ha más elemekre alkalmazzuk, mint űrlapra. Felmerülhet a kérdés, hogy érdemes-e megváltoztatni az osztályt például form.comments-form-ra, amolyan biztonsági okokból. Mit gondoltok?

Nos, ezzel most már érintettünk mindent ami a témával kapcsolatos, plusz talán egy kicsit közelebb hoztuk a html5 és css3 vívmányait is az olvasóhoz.

Összefoglaló lépések az objektum-orientált css megvalósításához

  1. Határozd meg az alap-objektumodat.
  2. Használj egy általános nullázó stíluslapot (reset.css), állítsd be az alap elemek általános stílusait és az alap-objektumod stílusait.
  3. Adj osztályokat az objektumaidnak és komponenseidnek, hogy elérd a kívánt stílust és érzetet.

Nem hoztunk most létre egy standard üzenetet, de az például egy nagyszerű gyakorló-példa lehet bárkinek, aki szeretne megbarátkozni az objektum-orientált CSS-sel. Próbálj meg létrehozni egy üzenet osztályt, amit egyformán lehet bekezdésre (p) vagy listaelemre (li), vagy egy komplett objektumra alkalmazni.  Aztán ha megvan, terjeszd ki, hogy hiba, figyelmeztetés vagy hibakeresés üzeneteket is megkülönböztetve meg tudjon jeleníteni.

Mindig hasznos az objektum-orientált CSS?

A válasz nem lehet egyszerűen "igen" vagy "nem", valószínűleg azért nem, mert az objektum-orientált CSS nem egy nyelv, csupán stílusok és bejáratott praktikák egy közös elnevezése. Lehet, hogy a standardizált HTML objektumok alkalmazása/felépítése például egy-egy projektben nem megoldható vagy felesleges, ugyanakkor a CSS ajánlások nagy része valószínűleg akkor is igaz marad. Ugyanakkor bár elkezdheted a HTML-t minimalizált formában kódolni és néhány id és class segítségével gyorsabban összedobni a dizájnt, mint az objektum-orientált CSS esetében, de az egészen biztos, hogy sokkal nehezebb lesz módosítani azt vagy akár csak hozzáadni is. Ezzel szemben elkezdheted használni a fent vázolt ajánlásokat, amivel hosszabb idő lesz eredményt elérni, de mindig tudni fogod, hogy hova kell nyúlnod, ha módosítani akarsz valamit.

Én jobban szeretem a jól megtervezett, átlátható és módosítható megoldásokat. És Te?

Címkék: css html5 css3