Elindult a KForm projekt, egy új formolós modul Kohana-hoz. Nem egy nagy dolog, view scriptek nélkül 150 sor az egész, de szerintem sokat tud, és egész jól használható. A wikiben van hozzá tutorial, szerintem nagyjából minden le van benne írva, kéretik próbálgatni, tesztelgetni, aztán bugreportokat kérek a projekt oldalán, vagy akár itt is. Kohana v3-hoz van írva, amihez amúgy megjelent egy egész használható wiki, úgyhogy mostmár kicsit könnyebben tanulható a cucc.

A view scriptek szintjén azért hoztam a formám, csapnivalóan rondák :) de ha minden igaz Vil már patkolja.

Ja, igen. Ez a 100. poszt a blogon :)

A Sun (vagy lehet inkább most már az Oracle-ről kellene beszélni) nem éppen a desktop platformjáról híres, de azért megtesz ezt-azt a fejlesztéséért. A Java Store egy olyan online szolgáltatás, melyen keresztül a felhasználók saját fejlesztésű desktop alkalmazásaikat tölthetik fel, és így azokat ingyen vagy pénzért terjeszthetik. Ezek az programok nyilván elsősorban swinges és JavaFX cuccok lesznek, legalábbis ez lenne a cél.

A Java desktop a JavaFX kapcsán már megmutatta, hogy minél jobban alkalmazni akarja a write once - run anywhere elvet, mivel elméletben a JavaFX programok egyaránt futtathatóak telefonon, böngészőben és desktopon. Ezt a hozzáállást a Java Store is követi, ezért különválasztották tőle a back-end szolgáltatását, a Java Warehouse-t. A programozó a warehouse-ba tölti fel az elkészült alkalmazást, a warehouse-hoz pedig különböző kliens-szolgáltatások kapcsolódnak, melyek felületet adnak a végfelhasználónak a letöltéshez - jelenleg az egyetlen ilyen kliens a Java Store. Nyilván az a cél, hogy legyen egy olyan kliens is, ami mondjuk telefonon fut. Más platform most így hirtelen nem is jut eszembe...

A Java Warehouse/Store szolgáltatások jelenleg private beta állapotban futnak, ez azt jelenti, hogy csak USA-beli fejlesztők használhatják, és nekik is meghívót kell hozzá igényelni. Valamikor 2010-ben kerül majd public állapotba a szolgáltatás.

Mikor először néztem utána ennek a Java Store témakörnek, a FAQ-ban egy elég érdekes bekezdést találtam, nagyjából az volt a lényege, hogy a private beta program után az egész szolgáltatás fizetős lesz - magyarul fizetnem kell majd azért, hogy - akár ingyenes - programokat feltöltsek a warehouse-ba. Ez eléggé olyan fafej oracle-s hülyeségnek tűnik, eléggé ki is buktam mikor ezt olvastam - azt még megértem hogy az Oracle nagyobb profitot akar kihozni a Sun-ból, de ne ilyen kretén módon már... Most nem találom ezt a részt, remélem azóta eltűntették, ez is olyan "baki" volt, mint az, mikor a G1 garbage collector használatát fizetőssé akarták tenni.

Az utóbbi napokban ismét kicsit aktuálisabbá vált a progtut.net 2.0 probléma, a portálon mostanában kicsit felpezsdült az élet (by elodani:)), így most már tényleg ideje lenne megírni egy korszerűbb és használhatóbb portált.

Az új portált Java-ban szeretném írni, php + kohana párossal valószínűleg kisebb meló lenne (mivel abban már több tapasztalatom van), de a java nyelvet sokkal jobban szeretem, és hiszek benne, hogy gyorsabb mint a php. Viszont nekem eddig úgy tűnik, hogy a php frameworkök kiforrottabbak és alkalmasabbak portálfejlesztésre mint a java frameworkök, jobban és egyszerűbben megoldják a tipikus webfejlesztéssel kapcsolatos problémákat. Ahhoz képest hogy milyen fapados technológia a php nagyon jók a keretrendszerek (amikkel találkoztam: CodeIgniter, Kohana, Zend, Yii). Az általam ismert java frameworkök közül valamelyik általam fontosnak tartott feature mindegyikből hiányzik.

Na de nem adom fel, keresem a megfelelő java keretrendszert. Lássuk mit szeretnék:

* layout page / content page rendszer egyszerűen megvalósítható legyen és emiatt ne kelljen lemondani az egyéb feature-ökről

* a fenti viselkedés egyszerűen letiltható legyen egyes action-ökben, hogy lehessen ajaxozni és rss feed-eet generálni

* szépek legyenek az URL-ek, kohana/CI-szerűen az URL egyes részeit át lehessen adni paraméterként a controllernek

* a request paramétereket automatikusan rakja be a framework egy bean-be, és legyen kiforrott annotáció / xml alapú validációs mechanizmus

* lehessen vele Java objektumot JSON-ba konvertálni

* ne akarjon beleszólni a framework a layout-ba, ne határozza meg az oldal struktúráját

* esetleg még az jó lenne, ha a frameworköt lehetne GWT-vel integrálni

Úgy nagyjából ennyi. Szerintem nem kérek sokat...
Eddig a struts-ot és a stripes-t néztem, mindkettő több pontnál elvérzett, de szerencsére van még miből válogatni :)

Persze ez nem azt jelenti, hogy a java nem alkalmas webfejlesztésre. Inkább arról van szó, hogy a java frameworköket inkább nagy alkalmazásokhoz, belső céges ügyviteli portálokhoz, rengeteg űrlap gyors (automatizált) kezeléséhez fejlesztették, így nem a progtut.net-szerű portálok jelentik a tipikus feladatokat. Nyilván kiváló technológiák a GWT meg a JSF, de arra alkalmatlanok, hogy az egész progtut.net-et ezekre alapozva írjam meg.

Ha valaki tud a fenti kritériumoknak megfelelő Java keretrendszert, az ne tartsa magában :)

A Prism egy firefox-addon, melynek segítségével úgy futtathatunk alkalmazásokat, mintha desktop programok lennének. Gyakorlatilag egy minimál-böngésző (tényleg minimál, ugyanis semmi nincs az ablakban), amihez be lehet konfigurálni különböző webalkalmazásokat. Az benne a szép, hogy nem úgy működik, hogy elindítjuk a prism-et és utána csatlakozunk az alkalmazáshoz amit éppen használni akarunk, hanem mikor felveszünk egy alkalmazást prism-ben, akkor beállíthatjuk, hogy hol legyenek hozzátartozó shortcut-ok (mondjuk én ubuntun csak az asztalra tudtam tenni, winen nem tudom), és így "közvetlenül" indíthatjuk a programot - valóban olyan, mintha desktop alkalmazás lenne. Nem egy tabban fut a böngészőben, és nincsenek benne az olyan sallangok - könyvjelzők, menü, stb - amire az alkalmazásnak úgysincs szüksége és csak foglalja a helyet. Valljuk be, a gmail webes kliensének vagy egy bugtrackernek pl. nincs sok keresnivalója a browserben.

Azt hiszem a következő években az lesz a tendencia, hogy összefolynak a desktop és webes programok, és ebbe az irányba nagyon komoly lépést jelent a prism. Tulajdonképp itt már tényleg mindegy, hogy mondjuk egy cloud szolgáltatással egy desktop vastagklienssel vagy egy html alapú vékonyklienssel kommunikálunk, a felhasználó számára nincs különbség. Megfelelően átgondolt tervezés esetén persze a programozónak se gond portolni a klienst, de ez már másik téma :)

Pár hónapja röppent fel a hír, hogy a Google App Engine java támogatást kap. A GAE egy olyan cloud szolgáltatás, melynek a skálázhatóság a lényege: ha olyan alkalmazást fejlesztünk, melynek gyorsan meg fog ugrani a terheltsége, és mondjuk nincs pénzünk tizesével venni alá a szervereket, akkor tehetjük a GAE-re, a google majd adja alá az infrastruktúrát. Eddig csak python-ban lehetett fejleszteni rá, mostantól java-ban is (nem meglepő, inkább az a kérdés, hogy miért nem a java-val kezdték).

Persze a GAE-n nem használhatunk minden java technológiát: szervlet, jsp, jstl van, más gyakorlatilag nincs. EJB, Hibernate, JDBC felejtős, magyarul gyakorlatilag csak a view rétegben használhatjuk a megszokott eszközöket, meg az alkalmazáslogikát betolhatjuk a szervletekbe.

JDBC, JPA és Hibernate nincs, tehát a google saját perzisztencia-réteget ad. Tulajdonképp nem saját API, hanem egy saját JDO implementáció, ami egy objekum-alapú adatbázis-spec (nemrég írtam egy hasonlóról - nem hiszem hogy sokan használták már, tehát ezzel valószínűleg meg kell ismerkednünk.

Amit még kapunk a google-től, az egy API a google felhasználó-kezeléséhez, ill. egy eclipse plugin (nem meglepő, a google minden saját technológiájához eclipse plugint ad, lásd android, gwt).

Getting Started guide itt.

A gravatar.com egy talán leginkább az OpenID-hez hasonló szolgáltatás, viszont annál sokkal egyszerűbb: ez összesen annyit biztosít, hogy egységes avatar-t használhatunk "bármely" (a gravatar-t támogató) portálon.

Nem nagy dolog, ahogy nézem nem is túl elterjedt az OpenID-hez képest, de azért a nagyobb CMS-ek támogatják, egyébként pedig pofonegyszerű integrálni, összesen pár sor, de akinek ez kényelmetlen, az használhat wrapper class-t.

Megjelent a Zend Framework 1.8. A ZF - a kismillió php framework közül - talán a legfejlettebb és legkiemelkedőbb. Ha másért nem, legalább azért érdemes megemlíteni, mert a Zend cég fejleszti, akik a php nyelvet is karbantartják.

A ZF új verziója sok újdonságot hozott, olyanokat, melyeket én eddig nagyon hiányoltam. Ilyen például az alkalmazásunk struktúrájának felépítéséhez használható CLI, melyet a zf/bin/ könyvtárban találhatunk. Könnyen létrehozhatunk vele új projektet, azon belül új kontrollert vagy view scriptet. Fix fájlrendszert határoz meg a projektnek, ami szerintem szintén jó, nem szerettem, hogy eddig minden ZF tutorial-ban kicsit más volt a könyvtárstruktúra, más volt a .htaccess fájl, az index.php, stb. Új, objektum-orientált bootstrap került a frameworkbe, ez a Zend_Application osztály, így mostantól ez sem vesz el órákat új projekt kezdésekor.

Újratervezték az autoloader-t is (pontosabban jött egy új), mely képes különböző névterekhez különböző loadert rendelni, így kevesebb probléma van azzal, ha a projektünkben olyan komponenseket is használunk, melyek nem követik a Zend elnevezési konvenciókat.

Mikor egy akármilyen szoftvert fejlesztünk, általában megerősítést kérünk a felhasználótól, mikor az egy fontos és/vagy nem visszaállítható műveletre ad utasítást. Ilyen lehet egy táblázatból egy elem törlése, vagy akármi. Desktop alkalmazásoknál ezen különösebben nincs mit túltárgyalni, megjelenítünk egy message boxot vagy valami hasonlót, és megkérdezzük a felhasználótól, hogy valóban végre akarja-e hajtani az adott műveletet. Webalkalmazások fejlesztésekor alapvetően két lehetőségünk van a visszakérdezésre:
* egy javascript confirm dobozban kérünk megerősítést, vagy valamilyen kliens-oldali DOM-manipulációval megjelenítünk egy megerősítő dobozt
* elküldjük a HTTP-kérést, de nem végezzük el egyből a műveletet, hanem előtte egy új oldalon kérünk megerősítést.

Az első módszernek több előnye van, pl mivel a kliens-oldalon történik a megerősítés, nem terhelik a szervert a félrekattintások, szebben is néz ki, a felhasználó számára is kevésbé körülményes.

Azonban sokkal kevésbé biztonságos, könnyen adhat lehetőséget súlyos következményekkel járó XSS támadásra. Tegyük fel, hogy valaki olyan spamet küld, amiben van egy link, ami mondjuk egy közösségi portál "profil törlése" funkciójának címére mutat. A felhasználó rákattint, nem nézi meg előtte hogy hova mutat a link, és már törölte is az accountját, mivel a javascriptes megerősítést kikerülte a spammer.

Tehát kritikus műveleteknél mindig oldal-újratöltéssel (vagy ajax-szal) érdemes megerősítést kérni, így mindenképp látja az user hogy mit csinál. A példánál maradva, mikor a felhasználó mondjuk a "profil törlése" linkre kattint, akkor tároljuk szerver-oldalon - célszerűen sessionben - hogy rákattintott, kérjünk megerősítést, ha azt megkaptuk, akkor nézzük meg, hogy a folyamat szabályosan zajlott-e (nem egy spam-ből jött a megerősítés) majd csak azután végezzük el a műveletet.

A Google bejelentette az O3D projektet, ami egy JavaScript API 3D tartalmak böngészőn belüli megjelenítésére.

Nekem tetszik az ötlet, ha befut, akkor sokat dobhat a JavaScript - mint RIA platform - pozícióján. Tulajdonképp már régen megvolt a lehetőség egy ilyen fejlesztésre, hiszen a JS canvas nem mai találmány, csak nem nagyon van kihasználva. Az O3D böngészőplugin tartalmaz hardveres támogatást is, tehát nem a javascript motornak kell szoftveresen megoldani az összes számolást. Az API kulcsfogalma a scene graph, mely egy objektumhálóként (vagy faként) modellezi az ábrázolt teret, tehát más a megközelítés, mint mondjuk az OpenGL-nél, ez inkább a Java3D API-hoz hasonlít.

A pluginnek van egy olyan nagy előnye, hogy ad hardveres támogatást, és van egy olyan nagy hátránya, hogy fel kell telepíteni. Ez azért problémás, mert a JS csak azért indulhat versenyzőként RIA téren, mert nem kell hozzá plugin, bárhol fut, ahol böngésző van - tudásban persze nyilván nagyságrendekkel a flash, silverlight alatt áll. Szerintem ezért választotta a Google a javascriptet a saját webkettes alkalmazásai elkészítéséhez, és ezért nem fejlesztett saját technológiát (csak a JS-re húzta rá a GWT-t). Így sokkal gyorsabban és könnyebben szerzett felhasználói bázist (pl. sokkal kevesebben használnának gmail-t ha plugint kellene telepíteni hozzá). Az O3D ezt az előnyt sajnos nem élvezi.

A hwsw.hu cikke szerint a következő firefox kiadás lehet, hogy a 4.0-s verzió lesz (eddig ugyebár 3.1-ről majd 3.5-ről volt szó). Ennek az az oka, hogy a fejlesztők JavaScript motort cserélnek, a SpiderMonkey-t felváltja a TraceMonkey, és mivel ezzel elég sok szívás van, valószínűleg csak 2010-ben lesz release. Sajnos ez azt jelenti, hogy a két kiadás között több mint 2,5 év fog eltelni, ami nagyon sok, és valószínűleg meg fogja érezni a FF piaci részesedése. A 3.0 a jelenlegi böngésző-piacon azért már annyira veszettül nem számít izmosnak, inkább a középmezőnybe sorolható, és ez 2010-ig még romlani fog, hiszen most jelent meg az IE8 és mindjárt itt a Chrome 2.0.