Weblabor

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.

Jelen cikksorozatban egy javascriptes keretrendszer alapjait fektetem le. Konkrétan arról lesz szó többek között, hogy hogyan lehet JavaScriptben használhatóbbá tenni az osztályokat, csomagokat létrehozni, és egyszerűsíteni a típusellenőrzést.

Szükség van-e projektmenedzsmentre?

Profi az, aki tudja, mit csinál

Azt gondolom, profi az, aki tudja, mit csinál. Tudja nem csak akkor, amikor beír egy sor PHP-t, de akkor is, amikor rendszerbe szervezi a sorokat, tudja akkor, amikor ennek megjelenítést tervez, de tudja akkor is, amikor az egész készítés folyamatát kell megszerveznie, átlátnia.

És persze ha valamit nem csinál profin, igyekszik ezen változtatni.

De hogyan szervezünk projektet? Miért úgy?

Miért nem jók az ismert módszerek? Miért nem használjuk őket?

Az SQL nyelv fejlesztése az 1970-es évek elején az IBM-nél kezdődött. Ezzel egy időben készültek el az első relációs adatbázisok (RDBMS). Az SQL kidolgozásánál elsődleges szempont volt az egyszerűség megőrzése azzal együtt, hogy rendkívül komplex lehetőséget nyújtson az adatok hozzáféréséhez. Az SQL és RDBMS rendszerek kéz a kézben fejlődtek az elmúlt 40 évben. Hatalmas adatmennyiséget kezelünk ezekkel a rendszerekkel, nagyon sokáig svájci bicska-szerűen mindenre megoldást kínáltak. Kialakultak az informatika szegmenseihez idomuló megoldások, így amikor a web elterjedt, vele együtt lettek népszerűek az egyszerűbb RDBMS rendszerek, mint a MySQL vagy a PostgreSQL.

Webes munkáim során sok adminfelületet csinálok, ahol rengeteg űrlap is készül, és ellenőrizni kell a kitöltött adatokat. Ezt az ellenőrzést szerveroldalon mindenféleképpen meg kell tennünk. Kliens oldalon ugyan nem kötelező, de manapság alapvető elvárás. Ha meg akarjuk spórolni a kliensoldali ellenőrzést, a szerver oldali kontroll után úgysem ússzuk meg a visszajelzést, hogy valami adat nincs rendben. Ha pedig ellenőrzünk kliens oldalon is, akkor ugyanazt a logikát kell két nyelven kiviteleznünk; ha egy újabb mező kerül az űrlapba, akkor két helyen kell a kódot módosítani.