CodePlay

PHP fejlesztői környezet OSX-en

kepes — Sun, 23 Oct 2011 11:13:36 +0000

Ha jól emlékszem lassan három hónapja gyűröm a MacBook Pro-t, és próbálom elfelejteni az évek alatt beidegződött Windows-t több kevesebb bosszúság árán. Eljutottam addig a pontig, hogy már nem csak felhasználóként szeretném használni az OSX-et, hanem az új webtárhely oldalunkat a Tárhelypark-ot oldalt is szeretném ezen fejleszteni és tesztelni mielőtt éles üzembe kerül. Mivel egyelőre ezt WordPress-el tervezzük, ezért szükségem van a Mac-en egy Apache/PHP/MySQL fejlesztői környezetre, amit most össze is rakok.

Állítólag a Mac már alap kiszerelésben is egy fejlesztői gép, ezért minden van rajta kezdve az Apache-tól a PHP-n át a Ruby-ig. Ez talán igaz is lehetne, ha nem derült volna ki azonnal, hogy azért egy kis tuningolás nem árt, mert egy alap WordPress futtatásához hiányzik egy két dolog: a PHP telepítésből az mcrypt könyvtár, a MySQL adatbázis kezelő, és némi Apache konfiguráció.

A konfiguráció amin dolgozom: Mac OS X 10.6.8 (10K549) – Snow Leopard

OSX Apache konfiguráció

Az OSX-ben már benne van az Apache, de nem fut, el kell indítani:

$ sudo apachectl start

leállítani vagy újraindítani így tudod:

$ sudo apachectl stop

$ sudo apachectl restart

Ha fut a webszerver akkor a localhost-on már látnod is kell egy böngészőből:

http://localhost

Apache Virtuális hosztok

Én szeretem a virtuális hosztok használatát, mert így könnyebb megjegyezni az egyes alkalmazások elérését, és nem kell foglalkozni az elérési utakkal az URL-ben. Úgy terveztem, hogy a létrehozott oldalakat a saját Sites könyvtáramban fogom tárolni a /Users/user/Sites könyvtárban, mert ezt használja több program is alapértelmezésben.

Az Apache konfigurációs fájlban (/etc/apache2/httpd.conf) engedélyezni kell a virtuális hosztokat:

/etc/apache2/httpd.conf

# Virtual hosts Include /private/etc/apache2/extra/httpd-vhosts.conf

A httpd.vhosts.conf konfigurációs fájlban felvettem a tarhelypark.local domain-hez tartozó hosztot.

httpd-vhosts.conf

ServerAdmin xyz@codeplay.hu DocumentRoot "/Users/kepes/Sites/tarhelypark-wp" ServerName tarhelypark.local ServerAlias *.tarhelypark.local ErrorLog "/private/var/log/apache2/tarhelypark.local-error_log" CustomLog "/private/var/log/apache2/tarhelypark.local-access_log" common

Hosts fájl az OSX-en

Ahhoz, hogy a virtuális hosztok működjelenk, még fel kell venni a megfelelő nevűt a /etc/hosts fájlba. A ServerName paraméterben megadott nevet kell hozzákapcsolni a localhost Ip címéhez.

$sudo nano /etc/hosts

127.0.0.1 localhost 255.255.255.255 broadcasthost ::1 localhost fe80::1%lo0 localhost 127.0.0.1 tarhelypark.local 127.0.0.1 myadmin.local 127.0.0.1 blog.tarhelypark.local

Miután ezt felvettük, és az Apache újraindult, a böngészőből el lehet érni a szervert a tarhelypark.local beírásával.

Symbolic link not allowed or link target not accessible

Jól használhatók még a szimbolikus linkek is, amiket trükkös engedélyezni. Nem a fő konfigurációs fájlban kell beállítani a FollowSymlinks paramétert mert egy inkludált konfig fájl felülírja azt.

/etc/apache2/users/username.conf

Options Indexes MultiViews FollowSymlinks AllowOverride All Order allow,deny Allow from all AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps

Amiért még ilyen hibaüzenetet kaphatunk, az a könyvtár jogosultsága amire a szimbolikus link mutat. Ha a konfiguráció után még mindíg jelentkezik a probléma, akkor jól nézd át a jogokat és tulajdonosokat!

PHP konfiguráció

Eredetileg nincsen php.ini fájl, létre kell hozni a /etc könyvtárban

$ sudo cp /etc/php.ini.default /etc/php.ini

PHP és mcrypt

A PHP alap konfigurációból hiányzik az mcrypt könyvtár, ami számos programhoz, például a PHPMyAdmin-hez is szükséges. Ezt most pótolni fogjuk.

Először is nézzük meg milyen php verzió fut a gépen:

$ php -v

PHP 5.3.4 (cli) (built: Dec 15 2010 12:15:07)

Nálam a PHP 5.3.4. Ahhoz, hogy az mcrypt-et hozzá tudjuk kapcsolni a PHP-hez szükségünk van a következő három dologra:

Xcode 3, amihez Apple Developer-é kell válnunk. Ez egy kicsit macerás, az xcode telepítve 9 Gb
mcrypt könyvtár (libmcrypt)
PHP forráskód, a megfelelő verzióval

Az xcode telepítése után csomagold ki a libmcrypt és php letöltéseket. A libmcrypt fordítása:

$ ./configure

$ make

$ make install

A PHP-ből nincsen szükség a teljes csomag lefordítására, csak az mcrypt kiegészítő szükséges:

$ cd php-/ext/mcrypt/

$ sudo phpize

$ sudo ./configure

$ sudo make

$ sudo make install

Ezek után létre kell jöjjön egy .so fájl a /usr/lib/php/extensions/no-debug-non-zts-20090626 könyvtárban.

Az /etc/php.ini fájlban szerepelnie kell a következő két sornak:

extension_dir=/usr/lib/php/extensions/no-debug-non-zts-20090626 extension=mcrypt.so

Az Apache újraindításával a phpinfo-ban meg kell jelennie az mcrypt könyvtárban.

MySQL

A MySQL letöltés és telepítése egyszerű, ezt nem részletezem. Miután a telepítés befejeződött szükség van a my.cnf konfigurációs fájl létrehozására a /etc könyvtárban. Én a fejlesztéshez a legkisebb példa konfigurációt, a my-small.cnf fájlt választottam.

$ sudo cp /usr/local/mysql/support-files/my-small.cnf /etc/my.cnf

Alapértelmezés szerint a PHP rossz helyen keresi a sock fájlt, ezért meg kell változtatni a /etc/php.ini fájlban a mysql.default_socket bejegyzést:

mysql.default_socket = /tmp/mysql.sock

$ sudo /Library/StartupItems/MySQLCOM/MySQLCOM start

Érdemes belerakni a MySql-t a path -ba

$ nano ~/.profile export PATH=$PATH:/usr/local/mysql/bin

Facebook alkalmazás – Küldj egy lapot

kepes — Fri, 26 Aug 2011 09:10:15 +0000

Elindult az Allianz Biztosító megrendelésére készített Facebook alkalmazásunk a Küldj egy lapot. A játékban a felhasználók négy szituáció közül választhatnak, melybe ismerőseik arcát “behúzva” vicces képeket tudnak készíteni egy-egy képzeletbeli nyaralásról. A résztvevők között az Allianz egy darab két személyes Wellness hétvégét sorsol ki a játék végén. A fejlesztés során az ilyen jellegű játékokban megszokott Flash animáció helyett JQuery-t használtunk, a szerver oldalon Ruby on Rails dolgozik. A nagy látogatószám kiszolgálására képes szervert a Tárhelypark.hu biztosítja.

Facebook alkalmazás – Soproni nem nyertem

kepes — Mon, 01 Aug 2011 09:27:45 +0000

A Soproni és a Port.hu közös promóciója a rengeteg TV spottal megtámogatott “Nem nyertem” reklámhadjárat, melyben a Hol söröz oldalról indulva egy nem nyertes Soproni kuponnal bárki meghívhatja öt barátját egy sörözésre, az első kört a Soproni állja. A Facebook alkalmazás érdekessége, hogy több rendszert kötöttünk össze, melyben részt vett a Port.hu fejlesztőcsapata is. A felhasználó a Port.hu-ról vagy a Hol söröz-ről indulva jut el a Facebook alkalmazásig, ahol meghívhatja ismerőseit, összeállítva a meghívotti listát. Az ismerősök értesítést kapnak a meghívásról, majd bekerülnek a Port.hu rendszerébe is.

Facebook alkalmazás – Üzemanyagár tippelő

kepes — Tue, 26 Apr 2011 09:14:00 +0000

A múlt héten került éles üzembe új Facebook alkalmazásunk a Genertel Biztosító megrendelésére. Az Üzemanyagár Figyelő játékban a felhasználók a következő heti benzin és dízel üzemanyagárat tippelhetik meg. A helyes tippelők között minden héten 50-50 liter üzemanyag kerül kisorsolásra, ami véleményem szerint elég jó nyereménynek számít a Facebook játékok között, tekintve, hogy egy folyamatos játékról beszélünk, nem pedig egy egyszeri sorsolásról. A játék érdekessége fejlesztési szempontból, hogy a nyertesek sorsolását is elvégzi az adminisztrátori felületről, ahonnan az aktuális árak is feltölthetők.

Fájlrendszerek (ext3, ext4, xfs) és RAID összehasonlítás

kepes — Sun, 20 Feb 2011 11:52:59 +0000

Új Tárhelypark szerverünk telepítésekor nagy dilemma volt milyen fájlrendszert válasszunk, illetve maradjunk a már bevált hardveres SATA1 RAID vezérlőnél, vagy versenybe szállhat az alaplapi SATA2 RAID vezérlő is. Aránylag olcsó megoldást szerettünk volna, így most hardveres SATA2 raidvezérlőre nem gondoltunk. Az Internetet böngészve számos forrást találtunk mindkét fő kérdésben pro és kontra egyaránt, és további problémát okozott a döntésben, hogy egyes cikkek igen régiek, ez által elavultak lehetnek. Az eredményeket egy Google Docs táblázatban összefoglaltam, ezt fogom egy picit elemezgetni.

A teszt környezet

A teszt szerver konfigurációja a következő volt. Egyedül a Hardwer RAID és Szoftver RAID teszteléséhez volt különbség a konfigurációban, ahol a RAID kártyát értelemszerűen csak a tesztek egyik részénél használtuk.

Processzor	Intel Core i5 760
Memória	16 GB Kingston DDR3-1333
Alaplap	Intle LGA 1156 Platform Intel H55 Express chipset
Merevlemez	4db Seagate ST31000528AS
RAID kártya	Adaptec 2410SA 64Mb cache (write-thrught)
Alaplapi HDD vezérlő	Intel® H55 Express Chipset built-in 6 xSATA 3.0 Gb/s ports
Operációs rendszer	CentOs 5.5
Kernel	Linux version 2.6.18
RAID level	RAID10

A szoftveres RAID-hez a Linux-ban támogatott Multiple Device Drivert (Linux Software Raid – md parancs) használtuk.

Teszt szoftver

A teszt végrehajtásához a bonnie++ 1.96-os verzióját használtuk. Ebben több tesztet is összeállítottam, melyek lényegét az alábbi táblázat tartalmazza.

Bonnie test for IO performance	Csak az adatátvitel tesztelésére, nem történik fájl létrehozás
Testing with zero size files in directories	Üres fájlok kezelése könyvtárakba rendezve
Testing with tiny files	Kicsi, 10 bájtos fájlok kezelése könyvtárakba rendezve
Testing with max 100Kb files with directorie	Maximum 100kb méretű (véletlen méret) fájlok kezelése. Véleményem szerint ez hasonlít a legjobban egy web szerver működésére, főleg tárhely szolgáltatásra cPanel-el
Testing with 100Kb to 1Mb files with directories	Fájlok kezelése könyvtárakban 100kb és 1Mb közötti méretben véletlenszerűen. Ez a teszt szerintem jó közelítés MySQL adatbázis kezelő szerverhez.
Testing with 16Mb size files	16Mb méretű fájlok kezelése. Archiváló szerver működésének szimulálására

Minden tesztelt kikapcsolt és bekapcsolt gyorsítótárral (buffer) is lefuttattam, bár normál működésnél a buffer mindíg be van kapcsolva, így valójában csak ez az érdekes. A tesztek az összes fájlrendszeren lefutottak, mind szoftver mind pedig hardver RAID-et használva.

Az érdekesség kedvéért teszteltem az ext2-es fájlrendszert is, bár ezt éles környezetben nem szeretnénk használni, hiszen nem naplózó fájlrendszer.

A teszt szkript

MOUNT=/var/lib/vz SIZE=32042 LOG=bonnie.log SYSTEM=soft_raid_ext4 date >> $LOG echo "Bonnie test for IO performance" >> $LOG sync; time bonnie++ -m $SYSTEM -n 0 -u 0 -r 4092 -s $SIZE -f -b -d $MOUNT >> $LOG echo "Testing with zero size files in directories" >> $LOG sync; time bonnie++ -m $SYSTEM -n 50:0:0:50 -u 0 -r 4092 -s 0 -b -d $MOUNT >> $LOG echo "Testing with tiny files" >> $LOG sync; time bonnie++ -m $SYSTEM -n 50:10:1:20 -u 0 -r 4092 -s 0 -b -d $MOUNT >> $LOG echo "Testing with max 100Kb files with directories" >> $LOG sync; time bonnie++ -m $SYSTEM -n 30:100000:0:30 -u 0 -r 4092 -s 0 -b -d $MOUNT >> $LOG echo "Testing with 100Kb to 1Mb files with directories" >> $LOG sync; time bonnie++ -m $SYSTEM -n 30:1000000:100000:30 -u 0 -r 4092 -s 0 -b -d $MOUNT >> $LOG echo "Testing with 16Mb size files" >> $LOG sync; time bonnie++ -m $SYSTEM -n 1:17000000:17000000:10 -u 0 -r 4092 -s 0 -b -d $MOUNT >> $LOG echo "--- Testing with buffer ---" >> $LOG echo "Bonnie test for IO performance" >> $LOG sync; time bonnie++ -m $SYSTEM -n 0 -u 0 -r 4092 -s $SIZE -f -d $MOUNT >> $LOG echo "Testing with zero size files in directories" >> $LOG sync; time bonnie++ -m $SYSTEM -n 50:0:0:50 -u 0 -r 4092 -s 0 -d $MOUNT >> $LOG echo "Testing with tiny files" >> $LOG echo "Testing with max 100Kb files with directories" >> $LOG sync; time bonnie++ -m $SYSTEM -n 30:100000:0:30 -u 0 -r 4092 -s 0 -d $MOUNT >> $LOG sync; time bonnie++ -m $SYSTEM -n 50:10:1:20 -u 0 -r 4092 -s 0 -d $MOUNT >> $LOG echo "Testing with 100Kb to 1Mb files with directories" >> $LOG sync; time bonnie++ -m $SYSTEM -n 30:1000000:100000:30 -u 0 -r 4092 -s 0 -d $MOUNT >> $LOG echo "Testing with 16Mb size files" >> $LOG sync; time bonnie++ -m $SYSTEM -n 1:17000000:17000000:10 -u 0 -r 4092 -s 0 -d $MOUNT >> $LOG echo "--- end ---" >> $LOG

Mit vártunk a teszttől

Az Internetes információk begyűjtése közben a következő lényeges észrevételeket és kérdéseket tettük, melyekre választ kerestünk:

Melyik fájlrendszer mire alkalmas, melyik a legmegfelelőbb webszerver, mail szerver, MySQL szerver futtatására vagy adatmentésre.
Igaz-e a legenda, hogy mindegy a fájlrendszernek, hogy SATA1 vagy SATA2 a vezérlő, mivel a merevlemez fizikai sebessége a korlát, nem az átviteli sebesség
Melyik megoldás mennyire biztonságos, igaz-e, hogy a hardware RAID biztonságosabb például merevlemez kiesése vagy áramkimaradás esetén?

HW és SW RAID biztonság

Az Adaptec hardver RAID kártya biztonságosságához nem fér kétség, hotplug tehát a merevlemezek menet közben cserélhetők, áramkimaradás esetén garantált az adatkonzisztencia, HA és itt egy nagy HA, nincsen bekapcsolva a kártyán levő gyorsítótár, mert ilyet biztonsági elem nélkül ne tegyünk. Backup battery hiányában ugyanis áramszünet esetén a teljes, visszaállíthatatlan adatvesztés esélye igen nagy. A 2410SA-hoz nem vásárolható backup battery sajnos, azonban a teszteket mégis bekapcsolt cache-el végeztem, mert kikapcsolva már az elején siralmas eredményeket kaptam.

Meglepetés volt a szoftver RAID, amiről eddig nem tudtam, hogy hotplug, és lehet nem is minden esetben igaz amit most írok. Biztonsági próba képp működő terhelt állapotban húztam le az egyik merevlemezről a tápkábelt. Az oprendszer üzent mail-ben, logban, és szépen futott tovább a teszt. Ugyanezzel a mozdulattal a tápot visszadugva, a Linux érzékelte az új lemezt, amit utána hozzáadhattam a RAID kötethez ahonnan kiesett. Így már csak az áramszünet okozhat problémát, de itt az adatvesztés esélye nem nagyobb mint a hardver raid esetében kikapcsolt cache-el.

Eredmény

A táblázatban megjelöltem zölddel a legjobb, pirossal a legrosszabb eredményeket. A “+++”-al jelölt értékek nem mérhetőek,mert a Bonnie++ dokumentációja szerint olyan gyorsan lefut a teszt, hogy az nem mérhető értelmesen. Ezeket az értékeket én nagyon jónak ítélem. Az elemzésbe kizárólag a bufferelt értékeket néztem.

Az egyes tesztekből az alábbi következtetéseket vontam le

Bonnie test for IO performance	Az átviteli tesztben a SATA1 egyértelműen lemaradt a SATA2 mögött. Mivel itt a fájlrendszernek nincsen különösebb jelentősége, ezért az egyes fájlrendszerek közeli eredményeket produkáltak.
Testing with zero size files in directories	Üres fájlok létrehozásával az ext4 és ext3 szoftver raid boldogul a legjobban. Az xfs nem képes értelmes sebességgel fájlokat létrehozni és törölni (bár ehhez nem is használ CPU-t, de ez nem számít). A hardver raid lemaradt egy picit.
Testing with tiny files	Az XFS szoftver raid veri a mezőnyt, de az EXT4 szoftver raid sem teljesít rosszul a tesztben. A hardver raid itt még próbálja tartani a lépést bár már feleannyi fájlt tud létrehozni mint a SATA2-es szoftver raid
Testing with max 100Kb files with directorie	Az EXT4 szoftver raid a nyertes, a hardver raid még nagyobb lemaradása mellett. Érthetetlen, hogy az XFS miért marad le ennyire a fájlok törlésében. Gyanús, hogy valami bug van vagy elkonfigurálást követem el
Testing with 100Kb to 1Mb files with directories	A nagyobb fájloknál a SATA1-es hardver raid egyértelműen lemarad, a mezőnyt az EXT4 vezeti
Testing with 16Mb size files	Egyértelműen látszik, hogy a SATA1 sebessége nagymértékben befolyásolja a nagyobb fájlok kezelését. EXT4 nyer a fájlrendszerek közül.

A nyertes

A tesztekből egyértelmű, hogy a SATA1 sebessége jóval alulmúlja a SATA2 sebességét, nem igaz, hogy nem ez a szűk keresztmetszet. Minél nagyobb fájlokkal dolgozunk, annál szembeötlőbb a különbség.

A fájlrendszerek közül az XFS használja a legkevesebb processzort, de ez mit sem ér, mert nagyságrendekkel lassabb is egyes esetekben. Kizárólag igen kis fájlok esetében használható, aminek most nem látom gyakorlati hasznát. Az ext3 csak néhol és csak kis mértékben kerekedik felül az ext4-en, amit akár tesztelési hibának is tekinthetünk.

A nyertes az ext4 fájlrendszer a szoftveres SATA2 Raid10 konfigurációval. Ezt a fájlrendszert érdemes használni, persze csak abban az esetben ha nem fektetünk be egy hardveres SATA2-es raid vezérlőre.

Ruby on Rails kezdetek

kepes — Sun, 16 Jan 2011 17:30:34 +0000

Előző bejegyzésében Almi kifejtette, nem sok jót jósolunk a Java technológiának sajnos, így kénytelenek voltunk más fele is nyitni érdeklődésünket. Az iPhone és Android mobil fejlesztések mellett választanunk kell egy Web-es MVC keretrendszert, ami egyszerű, támogatott, és a fejlesztés menete ha lehet gyorsabb minta a Java-s technológiákkal. Én eddig a PHP/Zend Framework párost támogattam, mert PHP-t már láttam előtte, de ennek alternatívája a Ruby On Rails. Ma megpróbáltam egy minimális “Hello World” alkalmazást létrehozni Rails-ben, ennek buktatóit szedtem össze.

Minél egyszerűbben szerettem volna eljutni addig, hogy böngészőmben megjelenjen az első MVC-s weboldal, tényleg minimális igényekkel, csak azt akartam látni, menyire bonyolult a dolog, nem érdekelt maga a nyelv. Windows 7 alatt próbálkoztam, így egy icsit specifikus az írás, és valószínűleg a problémák is, de könnyen adaptálható más oprendzserre.

Tehát Felmentem a Ruby On Rails oldalára, és kiválasztottam a Letöltés menüpontot, és letöltöttem az éppen aktuális 1.9.2-es verziót. Az oldalon meglehetősen jól nem csak az van leírva, hogy honnan töltsük le a dolgokat, hanem, hogy hogyan indítsuk el a Rails-t. Ez kicsit kevés a Hello World-höz, de jó kiindulás.

A letöltés után a Ruby /doc könyvtárában van egy pdf, ami alapján elkezdtem az első alkalmazás fejlesztését (334. oldal) de ez annyira régi, hogy nem bizonyult megfelelőnek. A parancsok megváltoztak azóta mióta ezt írták, és az 1.9.2 parancsosora másképp működik. Azért a nyelv elsajátítására még jó lehet majd később, elég részletesnek látszik.

A könyv után a Getting Started leírással próbálkoztam, ami már jóval naprakészebb információkat tartalmazott. Elsőként el kell érni a Ruby-t ami Windows alatt elég egyszerű, mert a telepítő a Start menübe telepít egy ”Start Ruby Command Prompt” nevű ikont, de más oprendszerben is csak annyi a trükk, hogy a /bin könyvtár legyen a PATH-ben. Próba képpen érdemes lefuttatni a ruby parancsot magéban, ami megjeleníti a paranacs helpjét. Ha megy akkor a Rails telepítéséhez a következő parancs szükséges:

gem install rails

Érdemes tudni kis háttér információt a fenti parancshoz, mégpedig, hogy a Ruby alaprendszer mellé kis csomagokként telepíthetők kiegészítések, ezek a gem-ek. Ilyen kiegészítő például a Rails is, ami nem a Ruby nyelv része.

Mivel elvileg a keret adott a fejlesztéshez, létrehoztam a projekt könyvtáramat. Ez tetszőleges helyen lehet, és a D: meghajtóra tettem egy ruby_workspace könyvtárba, követve az eddig jól bevált Eclipse-es névkonvenciót. Amint megvan a könyvtár lépjünk is bele – itt lesznek majd a projektjeink – majd a rails new helloworld parancsal létrehoztam a helloworld projektet

mkdir ruby_workspace cd ruby_workspace rails new helloworld

A Rails projekt futtatásához számos gem-et kell telepíteni majd, de ezt a Ruby megoldja, és egy leíróban tárolja minden projekthez, mire van szüksége. Ezek szintén nincsenek még letöltve, ezért letöltöm őket a következő paranccsal:

bundle install

Elvileg olyan stádiumba került a projekt, hogy akár futtatható lenne egy szerveren, ezért megpróbáltam elindítani:

rails server

sqliste3.dll is missing from your computer

A fenti hibaüzenet jelent meg egy kis ablakban, ami kicsit flusztráló, mert úgy éreztem mindent a Rails leírás szerint csináltam eddig. Kis Google és mindjárt megvan az eredmény, szükségem van az SQLite adatbáziskezelőre, mert az eléréséhez szükséges dolgokat a Ruby telepíti ugyan, de magát az adatbáziskezelőt nem. Gyorsan letöltöttem innen az SQLite Letöltés oldaláról a DLL verziót, és bemásoltam a Ruby /bin könyvtárába. Sok helyen írják, hogy másoljuk a System32-be de ez utoljára Windows 3.1 alatt volt megengedhető, ezért NE tegyük!

Újra megpróbáltam elindítani a szervert:

rails server

bind(2) (Errno::EADDRINUSE)

Megint egy kis idegesítő szálka a tervem közepén, miszerint 2 perc alatt megvan a Hello World. Nem jöttem rá miért, de valami a Windows 7 alatt rátelepedett a 3000-es portra, amit szegény Rails szerver próbál használni, és így nem tud. Megoldásként át kell rakni a szervert egyel nagyobb portra:

rails server -p 3001

Csodák csodája, elindult végre:

=> Booting WEBrick => Rails 3.0.3 application starting in development on http://0.0.0.0:3001 => Call with -d to detach => Ctrl-C to shutdown server [2011-01-16 13:40:39] INFO WEBrick 1.3.1 [2011-01-16 13:40:39] INFO ruby 1.9.2 (2010-12-25) [i386-mingw32] [2011-01-16 13:40:39] INFO WEBrick::HTTPServer#start: pid=9676 port=3001 [2011-01-16 13:41:03] INFO going to shutdown ... [2011-01-16 13:41:03] INFO WEBrick::HTTPServer#start done.

A futó szerver tesztelhető a következő linken: http://localhost:3001

Hello Ruby MVC

Eljutottam oda, hogy végre kiírhatom a böngészőbe az áhított üdvözlést. Először létre kell hozni hozzá egy Controller és egy View osztályt. Szerencsére a Rails generálni tudja ezeket:

rails generate controller home index

A paranccsal annyit mondtunk, hogy szükségünk van egy home nevű kontrollerre, aminek van egy index akciója. A parancs futása közben a képernyőn megjelenik milyen fájlokat hoz létre, érdemes egyesével átnézni őket tanulás végett, de ezzel most én nem foglalkozom. Gyorsan megmódosítom a /app/views/home/index.html.erb template fájlt, hogy benne legyen a “Hello Ruby” és kipróbálom az új kontrolleremet a következő linken: http://localhost:3001/home/index

routes.rb

Még egy kívánságom van a Ruby isteneitől, hogy az index megjelenéséhez ne kelljen beírni a teljes útvonalat. Ehhez törölni kell a /public/index.html fájlt és konfigurálni kell a rendszert a /conf/routes.rb fájlban.

root :to => "home#index"

Mi lesz veled Java?

almergabor — Fri, 05 Nov 2010 10:39:35 +0000

Az utóbbi idők fontosabb Java történései:

Oracle megvette a Sun-t, így a Java-t is
James Gosling a Java szülőatyja otthagyta Sun-t (vagyis már az Oracle-t)
Oracle perli a Google-t az Android-os Java miatt (hogy pontosan miért, az számomra elég zavaros)
Apple bejelentette, hogy a Mac-es Java-t nem fejlesztik tovább
És egyáltalán kevesebbet hallani a Java-ról

Ezt a témát jártam körbe kicsit részletesebben.

1. Ezzel talán az a gond, hogy az Oracle miután megvette a Bea-t, már akkor is gondban volt, hogy mit csináljon azokkal a termékeivel, amikből kettő lett neki, és ez helyzet csak romlott a Sun megvételével, ahol megint csak hasonló termékek voltak. Mintha maga az Oracle sem tudná, hogy például, akkor most Weblogic, vagy Glassfish, vagy IAS. (Na jó, az IAS, csak vicc volt )

Tavaly az Oracle fejlesztői konferencián az előadónak csak záporoztak a kérdések, hogy akkor most IAS-t kell-e használni, vagy Weblogic-ot. A vicc az egészben az volt, hogy pont azokban a napokban látott napvilágot az Sun felvásárlásának a híre, és valaki még a GlassFish-re is rákérdezett, persze az előadó csak az IAS és Weblogic témára tudott mit mondani, mégpedig, hogy Weblogic-ot érdemes használni, az IAS már csak egy ideig lesz támogatva.
A nagy cégekre általában azt mondják, hogy maga az ördög. Ez most sincs másként, mivel az Oracle, így már egy nagyon-nagyon nagy cég lett.
Az ilyen cégek lépéseit mindenki nagyon kritikusan figyeli. Legyen szó akár a Google-ről, az Apple-ről, vagy éppen az Oracle-ről.
Az Oracle adatbázis licenszekről tudjuk, hogy elég drágák, és nem lapul mindenkinek a fiókjában pár darab, így ha lehet, minden informatikai vezető kétszer is meggondolja, hogy kell-e neki Oracle, vagy használjon valami mást, mondjuk MySQL-t.
Mivel még korábban a Sun megvette a MySQL-t, ami így megint csak az Oracle kezében landolt, a lehetőségek tovább szűkültek, mivel az Oracle ebből is jó kis pénzt szeretne behúzni.
Elég csak megnézni a jelenlegi MySQL árakat: http://mysql.com/products/
Egy Clusteres MySQL kb. évi 2 millió forint.
Hogy az emberek mennyire ugranak mindenre amit az Oracle változtat, mutatja a napokban felkapott hír, miszerint a MySQL Classic Edition már nem tartalmazza az InnoDB storage engine-t: http://www.infoq.com/news/2010/11/MySQL-Classic-InnoDB
Már több helyen olvastam, hogy ha új projektet indítasz, akkor inkább PostgreSQL-t használj, vagy valamilyen NoSQL terméket.

2. Hogy James Gosling (http://en.wikipedia.org/wiki/James_Gosling) otthagyta az Oracle-t, inkább csak szimbolikus jelentőséggel bír, de mindenképpen érdekes dolog. A Java fejlesztők körében (persze csak akik egyáltalán tudtak róla), így nem lett sokkal népszerűbb az Oracle.

3. A Google felhasznált valamilyen kódrészleteket a Java forrásából. Ezért perel az Oracle: http://www.infoq.com/news/2010/08/oracle_sues_google

Az ügy egyébként elég bonyolultnak tűnik, viszont egy érdekes felvetést olvastam valahol: az egész azért van, hogy a Google megvegye a Java-t az Oracle-től, mivel az nem tud vele mit kezdeni, a Google pedig az Android miatt picit felkavarná a Java körüli állóvizet. Nem tudom mennyi igaz belőle, mindenesetre érdekes.

4. Mivel egyre több Java fejlesztő használ Mac-et, így sokaknak fájó az a bejelentés, hogy az új Mac OS X Lion operációs rendszerben, már nem lesz alapból megtalálható a Java. Mivel az Apple fejleszti a Mac-es Java-t, és gondolom az Oracle megint csak kicsit pénzéhesen sokat kért, amire Steve Jobs beintett.

5. Egyre kevesebbet lehet hallani a Java-ról. Régebben, alig bírtam a Google Reader-em Java-s híreivel, manapság jó ha kéthetente van egy-egy érdekes hír. Mintha már mindenki mindent leírt volna amit tudott a Java-ról. Nincs miről írni, mert nem történik semmi Érdemes megnézni, hogy például az O’Reilly kiadónál nincs előkészületben egyetlen Java-s könyv se: http://oreilly.com/java/index.html

Ami még érdekes, hogy maga a Java nyelv és a körülötte lévő technológiák jóval bonyolultabbak, mint kellene.

Ha valaki manapság egy átlag Java-s web-es projektbe belecsöppen, akkor körülbelül a következő dolgokkal találkozhat, amikről tudnia kell:

Java
Spring
Hibernate
Struts2
Maven

Az előbb felsorolt technológiák mindegyikéről külön könyvek jelentek meg, mindegyik technológia megtanulása hónapokba telik.

Betanulási idő, és legtöbbször sajnos fejlesztési idő szempontjából a PHP, Python vagy akár a Ruby, még mindig sokkal jobb választásnak tűnik, mint a Java (leszámítva a nagyvállalati környezetet).

Bruce Tate könyve elég érdekesen írja le ezt az egész folyamatot, igaz ő a Ruby szempontjából közelíti meg a dolgot, de próbál objektív maradni: http://pragprog.com/titles/fr_j2r/from-java-to-ruby

Azt mondja, hogy a feladatok nagy részére sokkal ésszerűbb mást használni, esetében Ruby-t, mind Java-t.

Most, hogy ezeket így leírtam, azon gondolkodom, hogy mindezt csak önigazolásként gyűjtöttem-e össze. Azért, mert nem látom a jövőmet a Java-ban.

Nem tudom.

Facebook alkalmazás iPhone4 nyereményjátékhoz

kepes — Wed, 03 Nov 2010 19:00:23 +0000

Most állítottam éles üzembe egy rövid fejlesztésünket, amit a Genertel biztosító rendelt meg. A program a biztosító új nyereményjátékát reprezentáló, meglehetősen egyszerű Facebook alkalmazás, ahol egy 10 kérdéses tesztet kell kitöltenie minden játékosnak a KRESZ-szel kapcsolatban. A játék a helyes válaszok és az idő alapján értékeli a játékosokat, és még “jogsit” is generál a játékos saját fényképével. Valódi célja azonban, hogy a minden játékos tisztában legyen a Genertel nevével, a Genertel megjelenjen a Facebookon. A fejlesztésen túl a Facebook alkalmazást Tárhelypark üzletágunk hosztolja egy elég nagy teljesítményű VPS szerveren. A design részben a mi munkánk, főleg a honosítással kapcsolatban voltak vele feladatok. És most pár technikai részlet…

A fejlesztéshez a projekt méretét és a Facebook API-t figyelembe véve PHP5-öt választottunk, az adatokat az egyszerűség kedvéért pár MySQL tábla tárolja. Azért, hogy ne a nulláról induljunk, felhasználtuk a Zend Framework legújabb verzióját, így az MVC is könnyedén megvalósításra került. A Facebook eléréséhez a legújabb, Graph API-t használtuk, ami azért hozott pár meglepetést a Zend-el együtt, de erről majd egy-két későbbi cikkben is megemlékezem. Megjelenítéshez a már bevált JQuery van az applikáció mögött, bár ez talán csak a kérdések közti “áttűnésben” látszik meg.

A projekt talán legnagyobb feladata a jogosítvány generálása volt, úgyhogy remélem sokan generálnak majd jogsit a saját profilképükkel és pontjukkal. A jogsival megszenvedett a grafikus, és a PHP-Facebook-Képkezelés trió is pár órányi guglizást eredményezett. Nevezetesen, hogy a feltöltött képeket Facebook konvertálja (JPG), az applikációban megjelenő egyes képeket pedig cache-eli. Ennek eredményeképp, az a kis, icipici lekerekítés a jogsi sarkainál, ahol az “átlátszóság” van, nem volt mindig átlátszó. Aztán még rá kellett illeszteni a jogsi háttérre a profil képet is, ami néha JPG, néha GIF, kideríteni nem egyszerű, mert a Facebook egy redirect-en keresztül adja.

De aztán sikerült, most pedig kíváncsian várom, milyen gyorsasággal terjed el az alkalmazás úgy, hogy a megrendelő elmondása szerint egyáltalán nem lesz hirdetve a nyereményjáték sem a Facebook-on, sem pedig a Genertel saját oldalán. Számítok egy nagy és hirtelen felhasználószám növekedésre, de majd meglátjuk. Remélem a VPS bírja majd. Ha nem, akkor kap még egy-két procit.

Jelszavak kezelése cégen belül

almergabor — Fri, 01 Oct 2010 09:05:04 +0000

Már régóta probléma cégen belül a jelszavak kezelése. Szolgáltatásokhoz amilyen jelszót megadtunk, felírtuk, elraktuk, elhagytuk, jelszó emlékeztetőt kértünk. Ha ez sem segített újat regisztráltunk.

Szerverek esetében természetesen a probléma kicsit bonyolultabb. Persze kulcsozunk, de ezen felül még jelszavakat is adunk. Ezt már jó ha valahol tároljuk.

Ötlet volt, hogy írjuk fel egy papírra és be a széfbe, de persze nekem általában otthon este tíz körül jut eszembe, hogy ezt vagy azt még el kellene intézni, így ez az ötlet nem jó.

Amikor elkezdtünk alternatívákat keresni, tudtuk, hogy nem lesz tökéletes megoldás, és azt is, hogy a paranoiánkon néha kicsit felül kell kell kerekednünk. Persze tudatában vagyunk annak, ha valaki fel akar valamit törni, akkor fel is töri, de kérdés mennyi idő alatt.

Amit most mi használunk, az a Password Gorilla + Dropbox kombó.

A Password Gorilla egy fő jelszót használó alkalmazás ami egy fájlban tárolja a jelszavakat, így csak egy jelszót kell megjegyezzünk.

A Dropbox -ot pedig arra használjuk, hogy ezt a fájlt mindenki elérje.

(Aki nem ismerné a Dropbox-ot az regisztráljon most azonnal itt: http://www.dropbox.com/referrals/NTI1NDE3NDQ5 Ez nekem azért jó, mert kapok minden ezen a linken keresztül regisztráló felhasználó után 250MB ingyen tárhelyet. Bocsi, köszi.)

Szóval a Dropbox egy online mentési hely, ahova pakolhatod a fájljaidat, szinkronizálhatod azt a gépeddel és meg is oszthatod azt a Interneten az arra érdemesnek tartott emberekkel.

Mi az egészet úgy használjuk, hogy mindenkinek van Dropbox-a, az egyikünk megosztott egy mappát a többiekkel. Feltelepítettük a Password Gorilla-t, egyikünk létrehozott egy új jelszó fájlt, amit a Dropbox-os mappájába mentett.

Ennyi.

Innentől bárki nyitja meg a fájlt és módosítja a többieknél szinte azonnal ott a változás.

Fontos volt számunkra az is, hogy Mac, Linux és Windows platformon is fusson a dolog, mert mindenki mást használ természetesen.

A következő lépés, hogy mindezt iPhone és Android telefonokon is tudjuk használni. (Bár erre éppen még nem volt szükség, de ki tudja.)

Ti mit használtok?

Android onItemClick probléma ListView és Button használatakor

kepes — Tue, 27 Jul 2010 23:16:26 +0000

Népszerű és mindenképp használatra javasolt komponens Androidon a ListView. Gyakorlatilag a legtöbbet használt UI elem, bárhmely programot használunk, rendszeresen feltűnik különböző formákban. Lényege, hogy a képernyőn megjelenő elemeket egy listába rendezzük, és ezt a listát görgethetjük le-fel ha nem fér ki minden elem a képernyőre. Használata relative egyszerű, amíg nem akarunk egyedi megjelenést, például Button vagyCheckbox komponenseket belerakni, mert ekkor azonnal beleütközünk a problémába, a ListView onItemClickevent handler nem hívódik meg kattintáskor.

Az Internet tele van a problémával, de teljes egészében leírt megoldást ritkán találni. Általában utalások vannak rá, hogy tároljunk ID-t a Tag mezőben, vagy írjuk át az Adapter-t, de mik is ezek az utalások tulajdonképpen?

A feladat amit kitaláltam egy olyan ListView megjelenítés, ami a SimpleAdaptert-t használja adatforrásnak, így a layout betölthető XML-ből egyszrűen. A layout tartalmaz egy gombot, amit megnyomva az Activity onClick metódusa hívódik meg. A probléma itt következik: az onClick az onItemClick-el ellentétben nem kapja meg melyik soron kattintottunk. Valahonnan pedig illene tudni, hiszen nem minden soron ugyanazt szeretnénk végrehajtani.

Az ötelt a fent amlített netes leírások alapján adja magát, tároljuk le az onClick-et meghívó View Tag-jében (View.setTag(Object o)) a szükséges azonosítót, így az onClick-ben a paraméterként megkapott View-tól le tudjuk kérdezni.

Minden ListView a lista elemeit egy Adapter osztálytól kapja (ListView.setAdapter()) a getView() metóduson keresztül. Az adapter kis átírásával megoldható, hogy a lista elemeibe bekerüljön a az Id a megfelelő Tag property-be, amikor a ListView meghívja a getView()-t. Leszármaztattam hát a SimpleAdaptert-t:

public class ClickableButtonListAdapter extends SimpleAdapter {	

	private static final String HASHMAP_ID = "_id";

	public ClickableButtonListAdapter(Context context,
			List> data, int resource, String[] from,
			int[] to) {
		super(context, data, resource, from, to);

	}

	@SuppressWarnings("unchecked")
	@Override
	public View getView(int position, View convertView, ViewGroup parent) {
		View view = super.getView(position, convertView, parent);
		setViewTag(view, ((HashMap) getItem(position)).get(HASHMAP_ID) );
		return view;
	}

	private void setViewTag(View view, Object tag) {
		view.setTag(tag);
		if (view instanceof ViewGroup) {
			for (int i=0; i < ((ViewGroup) view).getChildCount(); i++) {
				setViewTag(((ViewGroup) view).getChildAt(i), tag);
			}
		}
	}
}

A példában a lista elemei HashMap-ek, így ebből szedem ki az Id-t. A HahMap-ben az Id mező az “_id” elemben van, így ezt keresem ki, és rakom a Tag-be. A setViewTag() rekurzív metódus végigmegy az összes megjelenítendő View elemen és beállítja a Tag-et, így bármelyikre definiálhatjuk majd az onClick-et, mindig megkapjuk a Tag-ben a kiválasztott sor Id-ját.

Az Activity-ben az onClick() igen egyszerű:

public void onClick(View v) {
         Toast.makeText(this, "onClick id: " + v.getTag(), Toast.LENGTH_SHORT).show();
}

Nem mondom, hogy szép megoldás, de használható. Jobban tetszene, ha az Android megfelelően támogatná az egyedi ListView létrehozását esetleg azzal, hogy az onItemClick meghívódna, és eldönthetném, hogy mit akarok kezdeni az eseménnyel.