Hron blogja

Kész, most lett elegem a spammerek idiotaságából. Miután ma reggel ismételten 152 spam kommentre mondtam nemet, nekiálltam beleheggeszteni az oldal kódjába az Akismet nagyszerű szolgáltatását a rakismet gem/plugin segítségével. Most figyelem az eredményeket.

Kicsit elkezdtem ismerkedni a GlassFish nevű... hát hirtelen nem is tudom, minek nevezzem. Több, mint webszerver, sőt még Java alkalmazásszervernél is sokkal-sokkal több.

Egyrészt képes ugyebár mindenre, amit egy Java alkalmazásszervertől (csúnya néven J2EE Container-től) az ember elvárhat: JSP-k, szervletek futtatása, valamint különféle babok (EJB) nagyüzemi kezelése. Ezt erősen megtámogatja JDBC oldalról, a deployment módjának szabad megválasztásával (alapvetően 4 opciónk van: feltöltjük a szerveren valahova, és az adminfelületen kitallózzuk; közvetlen töltjük fel az adminfelületre az appot; a szerveren az autodeploy mappába pakoljuk az appot; illetve ha használunk IDE-t, akkkor onnet is deployolhatunk, minden IDE-nek van pluginje hozzá), különböző opciók finomhangásával, és még nagyon sokáig sorolhatnám.

Másrészt azonban a laptopomon levő üveghal pillanatnyilag PHP, Ruby, és Python nyelvu webalkalmazások futtatására is képes (a blogom másolatát vígan futtatja) egy kevés beállítás után. Szinte hihetetlen, ezzel a dologgal talán nincs is olyan szó, hogy lehetetlen, maximum olyan, hogy "nincs idő megcsinálni".

Az admin felülete egyszerű és letisztult, és iszonyúan segíti a munkát. Webszervízekhez ad tesztfelületet, a webalkalmazásokat felkínálja indításra, és más egyéb finomságok.
Egy olyan webszerveren, ahol kicsit bővebb RAM áll az ember rendelkezésére, simán el tudom képzelni, mint Apache helyettest. Talán még a munka is kevesebb lenne vele. Persze, mivel jelenleg csak 1G RAM van a szerverünkbe, így az Apache jobb választásnak tűnik (a GlassFish indításához 512 minimum az ajánlott, és gondolom a kliensek számával erőteljesen növekszik a memóriaigény).

Persze, ez csak az első fellángolás. Vannak vele azért szívások rendesen, például a PHP-t egyáltalán nem volt triviális beállítani, a Quercus pl. ígéretesnek hangzott, aztán kiderült, hogy sokat akart a szarka... végül egy natív PHP feltelepítésével, valamint a Java-PHP Bridge nevű cucc beizzításával sikerült a gondokon urrá lenni. Érdekes, hogy ez a stuff amúgy belül PHP-CGI-t használ... ez annyiból jó, hogy a PHP átkonfigurálása után nem kell a komplett appszervert újraindítani (ez kicsit hosszú idő lenne), a változások azonnal érvényre jutnak.

Összességében véve azonban egy nagyon jó kezdeményezésnek tartom, amit érdemes jobban tanulmányozni. Nagyon sok jó dologra lehet egy ilyen cuccot használni, és annak csak egy része, hogy Java alkalmazásszerverként üzemeltessük.

A mai nap volt egy kis szabadidőm, és úgy döntöttem, kipróbálom a KDevelop KDE4-es variánsát, mi változott a jól ismert KDE3-as verzióhoz képest.
Miután nagy nehezen felhekkeltem és elindítottam, megnyitottam benne önmagát (vagyis az őt tartalmazó projektet). Azután fél percig még levegőt is csak elvétve vettem.

Ha azt mondom, hogy ezt az alkalmazást tényleg a nulláról írták és gondolták újra, akkor úgy hiszem, nem tévedek nagyot. Elsőre elég funkciószegénynek tűnik a program, de sosem szabad hinni az első pillantásra feltámadó érzelmeknek.

Elsőre az tűnt fel, hogy bámészkodás közben a kódszerkesztőn felejtett egérkurzor alatti kóddarabról kicsit lejjebb hihetetlen részletes információkat kaphatunk, a projekt megnyitásától számított néhány másodperc múlva (a régi kdevelop-nak sokszor 3-5 perc is kellett, mire megismerkedett egy közepesen nagy kódfával).
A projektnézet hagyományos helyén, a bal oldalon található, ám a tartalma kissé trükkös. A KDevelop4 ugyanis értelmezi a Makefile/CMakeList.txt fájlokat, és az azokban található targetekhez tartozó fájlokat egy 'virtuális mappában' jeleníti meg (az ikonja eltér a mappáétól, így könnyű megkülönboztetni), míg a targethez nem tartozó fájlok a rendes, fájlrendszerbeli helyükön látszanak.

A projektimport hihetetlen egyszerű lett, akár egy töküres mappát is megnyithatunk projektként, és dolgozhatunk benne. Egyedüli kitétel, hogy amit a projekt importálásakor megadtunk build rendszert ahhoz tartanunk kell magunkat, mert az automata buildscript-parser ez alapján dolgozik és állítja össze a projektnézetet.
A projekt elmentésére lehetőség nincsen, ugyanis a program automatikusan elmenti a projekt változásait, amikor az import- vagy beállítóablakon az 'OK' gomb megnyomásra kerül.

Újdonság, hogy kibővült a használható verziókezelők köre. Immáron a CVS-től a Git-en át a Mercurial-ig szinte minden használható, ami nem, az pedig hamarosan az lesz, hiszen a programozási felületek is rengeteget egyszerűsödtek.
Ehhez hozzáalakult a projektablak jobbkattintásos menüje is, bár azt hozzá kell tenni, hogy még kissé nem tiszta a logikája a veriókezelő menüknek. De még minden változásban van, így ez csak egy előzetes vélemény, akár még javulhat is.

A rendesen létrehozható projektek köre viszonylag szűk, (talán a fenti importálási lehetőség miatt) sima cmake/make alapú projekt nincs is, csak Qt-s vagy KDE-s, illetve néhány KDE plugin-hoz vannak előredefiniált sablonok (erősítvén azt az érzésemet, hogy a KDE4 része vagy egésze ezzel az eszközzel készül).

A szövegszerkesztő elég sok változást hoz ugyancsak. Teljesen átalakult a jobboldali sáv, a összecsukó/kinyitó ikonok stílusa is változott, és ezen művelet is nagyon sokat gyorsult.
A szintaxiskiemelésről sok szót nem érdemes ejteni, teljes egészében átveszi a kate menüit és képességeit e téren, tehát amit a kate ki tud szinezni, azt a KDevelop is ki tudja.

Általánosságban elmondható tehát, hogy külsőleg és funkcióiban teljesen megújult a KDevelop4, ezen felül sokkal gyorsabb és önállóbb lett. Érdekes módon viszont a kódja sokkal kisebb, ugyanis nagyon sokmindent kiemeltek a kdevplatform nevű csomagba, éspedig azért, hogy a többi fejlesztőeszköz is profitálhasson a KDevelop fejlesztése során született dolgokból. Ennekokán valószínűsítem, hogy a Quanta, a KBabel és a többi program is egy megújult, funkcióban sokkal gazdagabb verzióval jelentkezik majd a KDE4 keretében.

Nem hivatalos források megerősítették, hogy a KDE 4.2 kiadásban sajnos nem lesz még KDevelop4, legkorábban talán a KDE 4.3 kiadásában vehetjük először szemügyre ezt a csinos fejlesztőeszközt. Addig sajnos türelemmel kell lenni.

No comment.

#define talloc(type) (type *) malloc(sizeof(type))

Almos vagyok, ugyhogy ez most csak egy link

Megint egy... ennek a sorozatnak sosincs vege?

Szoval, ha olyan uzeneteket kapnal, hogyaszongya:

 ArgumentError in <%= controller.class %>#index

NULL pointer given

Akkor beleszaladtal abba, hogy a gem-kent csomagolt 2.7.3-as mysql.so lib csak a 5.0-as libmysql.dll-lel hajlamos egyutmukodni korrektul. Innet szerezheted meg jol, arra kell ugyelni, hogy a klienseknel nem eleg csak a commandline klienst (mysql.exe) kijelolni, hanem az other tools-t is ki kell, akkor lesz libmysql.dll amit be lehet masolni a ruby bin mappajaba.

Forras: Railsforum: mysql driver not working with Rails 2.0.2