Weblabor

A cikksorozat előző részében megismerkedtünk a Node.js rendszer telepítésével és alapvető működésével. Most újabb részletekbe ásunk bele, és megnézzük, hogyan tudunk hatékonyabb alkalmazásokat írni.

Az utóbbi néhány évben szaporodni kezdtek azon alkalmazások, melyek megkövetelik a lehető legkisebb késleltetéssel a közel valósidejű információ elérést. Friss élményként említhetnénk a közösségi oldalakat is, de persze az igény már jóval ezek előtt megszületett: gondoljunk csak a pénzügyi alkalmazásokra, vagy akár a több szereplős játékokra. Az alábbiakban megpróbálok átfogó képet nyújtani azon javascriptes technikákról, amelyekkel képesek lehetünk valós idejű információ elérésre.

A közelmúltban szűntek meg az Extra.hu utolsó szerverei és ezzel már nem titok a titok: eláruljuk, hogyan működött.

A Node.js (vagy másnéven Node) egy rendszer, melyben JavaScriptben írhatunk szerver oldali alkalmazásokat. Maga a rendszer C/C++-ban íródott, és egy esemény alapú I/O rendszert takar a Google V8 JavaScript motorja felett.

Próbálok nagy szavakat találni, miért érdemes egy-egy alkalmazásba naplózást építeni, de mindig a hiba felderítéshez lyukadok ki. Biztosan az olvasó is találkozott olyan felhasználóval, aki rendszeresen futott bele egy hibába, amit az elmondása alapján nem lehetett reprodukálni. Vagy olyanba, amibe csak egy-két felhasználó szaladt bele, olyan úton, amire fejlesztőként egyáltalán nem gondoltunk. Ilyenkor hatalmas segítség lehet, hogy lépésről lépésre végig tudjuk követni felhasználót.

Ha valaki egy előzetes áttekintés útán úgy gondolja, hogy az XAML mindössze az n+1-edik módja annak, hogy grafikus felületeket írjunk le valami elvont XML formátumban, az nagyon téved. Az XAML igazából egy olyan deklaratív, XML alapú .NET nyelvjárás, aminek segítségével objektumgráfok deklarációja írható le olyan formátumban, ami az XML jellegéből adódóan ember és gép számára nagyon könnyen olvasható, megérthető és kezelhető.

A legtöbben egy típusos nyelv segítségével ismerkedtünk meg a programozással, tanultunk a számítógépes számábrázolásról, és a „fejünkbe verték”, hogy óriási különbség van az egész és a lebegőpontos számok között. De a JavaScript csak egyféle számot ismer… Hogyan tekintsünk rá? Pontosan mit ért alatta? Mi a leggyakoribb számokkal kapcsolatos hiba, amit a programozók elkövetnek? Ezekre a kérdésekre keresem a választ a teljesség igényével.

Ebben a részben az osztályok közötti öröklést valósítjuk meg. Mint azt látni fogjuk, ez nem is annyira egyszerű feladat. A javascriptes öröklődésre több megoldás született. Létezik olyan, ahol másoljuk a prototípusok tulajdonságait, és olyan is, ahol a leszármazott osztály prototípusa az ős osztály egy példánya. Vizsgáljuk meg ez utóbbit kicsit közelebbről.

Nemrég tett közzé Farkas Máté (fmate14) blogbejegyzést tömb bejárási problémákról, amelyhez kapcsolódóan Galiba Péter (Poetro) szóba hozta, hogy létezik egy hasOwnProperty() nevű Object metódus. Kicsit jobban utánajártam, és kiderült, hogy MSIE nem támogatja, a többi nagyobb böngésző viselkedése pedig néhány esetben eltérő, ezért úgy döntöttem, hogy egy az egyben felülírom ezt a metódust.

A Dojo Toolkit (továbbiakban: Dojo) elsődlegesen böngésző alapú fejlesztést támogató JavaScript eszközkészlet. Az alábbi írás nem kíván és nem nyújt átfogó képet az eszközkészletről, ehelyett egy Dojora támaszkodó példa alkalmazás fejlesztésén keresztül bemutatja a toolkit képességeinek, szolgáltatásainak egy szeletét. A kitűzőtt feladat az alábbi: jelenítsünk meg tíz, URL hashként megadott kulcsszóra illeszkedő fotót a Flickrről Lightbox jellegű albumba szervezve.