Hogyan telepítsünk Google Closure-t Eclipse alá, avagy út a „helloworld”-ig
A bejegyzés apropóját ebben a hónapban aktualizált, és általam tegnap beszerzett Closure: The Definitive Guide c. könyv adja, melynek első, Introduction to Closure fejezetét 5 azaz öt óra alatt sikerült – Eclipse alól ill. alá – abszolválnom. Ezt az időt szeretném megspórolni és 10 percesre redukálni annak, aki hasonló fába szeretné vágni fejszéjét. Magyarán a következőekben egy gyors telepítési útmutató következik Win7, Google Closure és Eclipse témakörben.
Wiki à la Yii
Ebben a rövidke leírásban azt szeretnénk bemutatni, milyen egyszerű elkészíteni egy elegáns webes alkalmazást a Yii keretrendszer segítségével. Ha a későbbiekben igény lesz rá, természetesen belevághatunk kényesebb témákba is, mint például a biztonság, gyorsítótárazás, komolyabb Active Record használat stb.
Konnektivista Drupal programozó képzés indul
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ő.
Weblabor bögre és póló: kérnél?
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.
■Aszinkron lekérések más tartományból
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.
Nagy terhelésű rendszerek fejlesztése 2.
Mielőtt a bevezető cikk után rátérnénk a konkrét load balancing és clusterező megoldásokra, szeretnék egy jelentéktelennek tűnő, ám de annál hasznosabb eszközt bemutatni. Hölgyeim és uraim, konzolokat elővenni, debuggereket bekapcsolni, háttérfolyamatokat írunk.
Cross-domain JavaScript kommunikáció egyszerűen
Cross-domain JavaScript kommunikációra több lehetőség is adott – Flash, XML-RPC, postMessage() –, azonban ha egyszerű célokra keresünk egyszerű megoldást, akkor ezek közül egyik sem a legjobb. Vagy nem teljes körűen alkalmazható technikák, vagy a probléma látszólagos egyszerűségéhez képest túl bonyolultak és nem áll rendelkezésre mindkét oldalon a megvalósításukhoz szükséges programozói munkaóra. Sőt, az is előfordulhat, hogy a másik oldal nem kellően felkészült egy ilyen bonyolultabb csatorna kialakítására.
JavaScript öröklődés
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…
Gondolatok a JavaScript prototípusosságáról
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?
Első szabály: ne hibázz!
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.
