Nem igazán friss hús, de most kéne tanulni, úgyhogy most próbáltam ki a NetBeans legújabb verzióját. A php és javafx verzió érdekelt, a Java-ról egyrészt elhiszem hogy nagyon jó, másrészt kicsit mostanában (sajnos?) mellékvágányra került nálam a téma, a többihez (ruby, c/c++) pedig nem értek.

Először 1-2 hete a NetBeans for PHP-t néztem meg, hát mit ne mondjak rég láttam ilyen jó php környezetet. Na nem mintha sokat várnék, de ami kell azt tudja: syntax highlight megy, rendesen működik az auto-completion (legalábbis kohana-s cucchoz, aminek ugyebár kb ugyanúgy működik az autoloadere mint a ZF-é, ez mondjuk lehet benne van a dologban), ráadásul normális a sebessége is. Összehasonlításképp: eclipse-ben az autoloader hol megy, hol nem, és ha megy, akkor is döglassú.

Ezen kívül kipofozták a JavaScript syntax highlightert, 6.1-ben még elég pocsék volt, mostmár rendesen megy (legalábbis én nem tudtam olyan kódot produkálni a rászánt 2 perc alatt amitől megfeküdt volna). Ráadásul a standard DOM API-hoz van autocompletion és még popup doksi is, szóval igazán tisztességesen meg van írva a js támogatás is, nem nagyon láttam még ehhez hasonlót. Ha már így benne voltam megnéztem a CSS szerkesztőt is. Na itt lepődtem meg igazán, ugyanis nem csak hogy rendesen működik, hanem egy dobozban megjelenítni on-the-fly hogy az éppen szerkesztett CSS utasítás hogyan fog formázni egy divet, ráadásul ez is normális sebességgel működik - csöpögök.

Szóval PHP téren jelenleg nagyon odaveri a netbeans az eclipse pdt-t, érdemes váltani.

Ezután jött a JavaFX-es NetBeans, ettől már nem voltam annyira elragadtatva. Telepítés közben kicsit meglepődtem, mert a telepítő nem kérdezte, hogy hova akarom rakni a cuccot, hanem észrevette hogy már van egy NB telepítés a gépen (a php-s) és abba másolta a javafx-es cuccokat is. Gondolom ez nem javafx-specifikus dolog, hanem úgy alakították át a netbeans-t hogy egy gépen csak egy telepítés lehessen. Nem vagyok túl boldog tőle dehát istenem, ettől még nem dől össze a világ.

Viszont ez a JavaFX támogatás sehogy nem akar jó lenni. Még mindig nincs hozzá normális drag&drop editor, amit annak neveznek az annyi, hogy ráklikkolok egy gombra és a kódba beilleszt az adott widgethez egy sample kódot - akkor is, ha épp rossz helyen áll a kurzor és syntax erroros lesz a kód. Van még újításként egy preview nevű ablak amiben elvileg látjuk hogy hogy fog kinézni az éppen szerkesztett UI, ez elvileg nem lenne rossz csak ahogy néztem kicsit döcögve működik. Ezen kívül még mindig vannak olyan banális hibák, mint pl az hogy ha a forráskód hibás volt, aztán javítom, attól még a fájl ikonja továbbra is hibásnak jelzi, meg ilyesmi. Na nembaj legalább a kódszerkesztő jobban működik mint 6.5-ben.

Egyébként bekerült a netbeans-be egy olyan feature hogy az internal frame-eket lehet undockolni és akár másik workspace-re helyezni, ezt én pl az eclipse-ből nagyon hiányolom, úgyhogy most ennek szintén örülök:)

Nem is olyan régen indult a jQuery UI projekt, mikor fél éve utoljára láttam, akkor még eléggé kezdeti állapotban volt, nem nagyon látszott, mi lesz belőle... bezzeg most...

Röviden egy javascriptes ablakozós libről van szó, desktop-szerű felületet lehet vele varázsolni webalkalmazásoknak (ilyen még pl. a Yahoo UI, stb) - max respect azoknak akik ilyen projektbe bele mernek fogni, elég szívás lehet.

Szóval a jQuery UI egy nagyon szép cucc, jól témázható, az eddigiek alapján jónak tűnik a dokumentációja, látszik, hogy van mögötte egy cég. Még egy úgynevezett ThemeRoller nevű appot is összehoztak, amivel egyszerűen össze lehet kattintgatni új témákat.

Tulajdonképp szépen fejlődik a javascriptes világ, minden negatívuma ellenére. Szerintem még egy jó darabig nem fogja átvenni a helyét a weben semmilyen RIA-technológia sem, sőt, inkább teljesen ki fognak szorulni a piacról (ami nem is baj).

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.

Elindult a JSMag, egy javascripttel foglalkozó online magazin. Sajnos az újság $4.99-be kerül, ami azért magyar viszonylatokban elég sok. Pedig az első szám tartalma alapján nagyon színvonalas lehet, komolyan elgondolkodtam rajta hogy megrendelem.
Az 1. szám tartalma:

* ExtJS: bevezetés
* A piros pirula: funkcionális programozás JS-ben
* Unit-tesztelés JS-ben
* JS kód debugolása
* jQuery 1.3 újdonságok

Nagyjából minden (jó és kevésbé jó) webprogramozó nagyjából ennyit tud a javascript nyelvről. A legtöbben írogatnak szkripteket amiknek a nagyrészét (a szükséges függvényeket ill. attribútumokat) guglival találták, olvasnak és írnak atomgagyi, minden szakmaiságot nélkülöző "tutoriálokat", vagy még rosszabb esetben töltögetnek szkripteket (hóesés, analóg óra, és minden, ami egy 14 éves scriptkiddie honlapján kötelezően szerepel). Ja, és persze szorgosan anyáznak napokig hogy "mé nem megy ez a sz*r", meg hogy mekkora sz*pás ez a típustalanság (ami egyébként fejlesztői szempontból teljesen jogos).

Kevesen ismerik a javascript nyelv alapjait és lényegét, pedig ez egy olyan dolog ami egészen egyedi és különleges talán minden más programnyelvhez képest: a javascript egy teljesen objektum-orientált nyelv, teljesen speciális objektum-szemlélettel: nincs klasszikus típus-fogalom és osztály-objektum kapcsolat. JS-ben az objektumokat származtatjuk egymásból, pontosabban minden objektumnak vagy egy prototípusa, melyből új objektumokat ("példányokat") származtathatunk. Így gyakorlatilag a típusos OO nyelvekből ismert osztályhierarchia beleágyazódik a futás-időben létrejövő objektum-hálóba (object network/graph). A javascriptnek ezt a speciális működését gyakorlatilag senki nem ismeri eléggé, senki nem használja ki, senki nem érti meg, minden js framework első dolga hogy valahogy ráerőlteti a klasszikus OO nyelvek típusos működését a js-re. Pedig azt hiszem nagyon sok érdekes és innovatív lehetőség rejlene a nyelvben (és rejlik már a kezdetek óta, hiszen ezek a lehetőségek léteznek már a nyelv legelső specifikációja óta).

Hogy miért nem érdekel senkit a javascript? Azt hiszem azért, mert eléggé "gagyi webes szkriptnyelv"-ként került be a köztudatba, és az ajax-robbanás is inkább csak néhány objektumra ill. az xml-kapcsolatra terelte rá a figyelmet, mint a nyelv alapjaira. Kutató informatikusok se foglalkoznak vele.

Nem mintha én tudnám rendesen a javasciptet - de én legalább tudom, hogy mennyire nem tudom :) Szerintem kicsit mélyebben is bele fogom ásni magam a témába, mitöbb, talán megér a dolog egy cikksorozatot a progtut.net -en :) De azt csak akkor fogom megírni, ha kész lesz a progtut.net 2.0 (fogalmam sincs hogy az mikor lesz).