Weblabor

Ma már egyre több helyen használják előszeretettel a Drupal tartalomkezelőt. Elképzelhető, hogy mi is kerülünk olyan helyzetbe, amikor a megrendelő kérésére vagy főnökünk utasítására nekünk is ezzel az eszközzel kell majd dolgoznunk. A Drupal alapú fejlesztés egyedi látásmódot igényel, emiatt két lehetséges lelkiállapot képzelhető el. Rajongás, ha a rendszer által megkövetelt gondolkodási sémák egybeesnek a miénkkel. Mérhetetlen gyűlölet, ha kialakult módszereinket, bejáratott megoldásainkat nem használhatjuk. A hatékony munkához szükséges nyitott, tárgyszerű és semleges hozzáállás a legritkább esetben fordul elő, pedig ez lenne az üdvözlendő.

Szeretnéd te is weblaboros bögréből inni a reggeli kávét? Vagy nagy WL feliratos zöldpólóban menni be dolgozni?

Weblabor bögre

Itt a lehetőség: ha szeretnéd egy ilyen relikvián keresztül mások tudtára adni, hogy te is a hazai webfejlesztők legnagyobb közösségének része vagy, akkor töltsd ki a doodle-t, és szólj a melletted ülőnek is! Elegendő számú igény esetén azonnal intézkedünk.

A webnek az elmúlt néhány évben történő rohamos fejlődése, kétség sem férhet hozzá, nagyrészt az aszinkron lekérdezések (újra)felfedezésének köszönhető. Van azonban egy frusztráló korlátja ennek a technikának, melynek gyökerei egészen 1996-ig nyúlnak vissza: a same origin policy, mely nem engedi, hogy más tartományból, más protokollal vagy más porton keresztül érjünk el egy erőforrást. A megoldás azonban már ott található minden korszerű böngészőben.

Az általánosítás és specializáció az objektumorientált programozás központi eleme, mely során egy ősosztályból származtatott alosztály újabb tulajdonságokat és metódusokat kap. Mindez jól modellezhető JavaScriptben is, de akad itt egy kis probléma, ha az ősosztály konstruktora paramétereket vár…

A JavaScript objektumorientált, de nem a klasszikus OOP értelemben, ugyanis nincsenek osztályok, a JavaScript prototípus alapú. Balogh Tibor írt erről egy alapos, de könnyen emészthető cikket. Én a jelenségnek egy más aspektusát vizsgálnám meg: az osztály alapú objektumorientált programozást ismerők számára nehéz megérteni a JavaScript működését, és erre véleményem szerint a JavaScript is rájátszik egy kicsit. Miért van ez, és hogyan lehetne orvosolni?

Az uml-to-django a projekthez legyártott UML osztálydiagramból állítja elő a Django modelleket. Míg a fejlesztők célja, hogy tetszőleges osztálydiagramot tudjon az eszköz kezelni, jelenleg csak az ArgoUML tervező termékeit támogatja. Az ArgoUML egy általános célú designer UML diagramok készítéséhez. Úgy számítottam, hogy az ArgoUML-lel felvázolom az osztályokat, az uml-to-django-val legyártom a modelleket, és ezzel meggyorsítom a fejlesztés menetét. Tévedtem.

Már egy ideje forgatom a fejemben a gondolatot, hogy kellene egy gyakorlatorientált miniprojektet gyártani a PHP 5.3 képességei felderítésére. Jelentem, elérkezett a pillanat, úgyhogy ihun a reggeli kávé mellé a tapasztalatok.

Mit ír ki az alábbi JavaScript program, ha az első két alert: 1: undefined és 2: undefined?

alert('1: ' + typeof undef1);
alert('2: ' + typeof undef2);
alert('3: ' + undef1);
alert('4: ' + undef2);
// ...