Változások az OpenSocial alapú fejlesztésben

Az OpenSocial fejlesztésekkel kapcsolatban több fejlesztő is nehezményezte, hogy körülményes a kialakított, JavaScript központú fejlesztés és ez nagyban nehezíti alkalmazásaik hatékony fejlesztését. Az OpenSocial 0.9-es szabvány erre próbál megoldásokat adni, amit ha jobban áttekintünk, akkor valóban sok-sok fejlesztő életét megkönnyítő megoldást találunk.

Mik is ezek az újdonságok:

  • Data Pipelinening
  • továbbfejlesztett OpenSocial Templating
  • OSML - OpenSocial Markup Language

‘Változások az OpenSocial alapú fejlesztésben’ teljes szövege

HTML és CSS szerkesztés gyorsan és szépen

A fejlesztések során igyekszünk olyan eszközökkel dolgozni, amelyek növelik a hatékonyságunkat és a kód karbantarthatóságát is. Ez az egyik oka annak, hogy tavaly felvettük az eszköztárunkba a Rubyt és vele együtt a Rails keretrendszert. Azóta már több projektet átadtunk amelyek ezeket a technológiákat használják. A nagyobb dolgok mellett azonban szükséges néha az alacsonyabb szinteken is nagytakarítást végezni, és megtalálni minden összetevőből a legmegfelelőbbet.

Idén a kliens oldali fejlesztés megkönnyítéséhez sikerült két ilyen összetevőt találni. Ezekből az egyik a Haml, amely egy indentáláson alapuló HTML és XML kód generálására használható nyelv. A másik pedig ennek a párja a Sass, amely hasonlóan CSS kód generálására használható. Mindkettőnek egyik nagy előnye a sima HTML/CSS illetve a HTML-hez Ruby világban hagyományosan használt ERB-vel szemben, hogy sokkal kevesebb a kódban a sallang és az ismétlődés (DRY). Emelett persze sok további előnnyel rendelkeznek. Haml esetében a szép kimenetet és a filterekkel való kiterjeszthetőséget emelném ki, Sass esetében pedig a konstansok és egyszerű műveletek használatát, illetve a css mixineket.

A Sass oldalhoz még a Compass keretrendszert is bevetettük, ami sok hasznos mixint definiál nekünk előre illetve a népszerűbb CSS frameworkökhöz (YUI, Blueprint, stb.) is ad rugalmasan használható Sass átiratot.

Próbáljátok ki, nekünk bevált! Ha esetleg mélyebben érdekelnek az előnyök, és hogy mi hogyan működik, akkor ajánlom figyelmedbe a bevezetés előtt tartott belső traininghez készült előadás slidejaimat:

Gadgetfejlesztés Rubyval: gadgeteer

OpenSocial gadget fejlesztésénél előfordulhat, hogy a kisalkalmazásunkból egy háttéralkalmazással kell kommunikálnunk. Erre nagyon jó módszereket nyújt a platform, és így az egész fejlesztési folyamat olyan lesz, mint egy jól megtámogatott AJAX intenzív webalkalmazás-fejlesztés. A backend oldalra a platform rugalmassága és a gyors fejlesztés miatt kiválóan alkalmas valamilyen rubys webframework. Az alábbiakban bemutatok pár eszközt, amit felhasználhatunk a backend fejlesztés során. Többek közt egy Virgos fejlesztésű Rails plugint is nyílttá teszünk, ami leegyszerűsít néhány dolgot.

‘Gadgetfejlesztés Rubyval: gadgeteer’ teljes szövege

Sharding a’la Virgo

A feladat, nagyon nagy mennyiségű adat tárolása – esetünkben 30G rekord –, viszont az adatok rendelkeznek azzal a kellemes tulajdonsággal, hogy bizonyos szempont szerint szeparálhatók.

Ilyen esetekben jöhet szóba valamiféle sharding megoldás, más néven horizontális particionálás. Az ilyen megoldások lényege, hogy az adatokat fizikailag külön adatbázisban tároljuk. A szükséges adatokat az egyes shardokról külön-külön visszanyerjük, majd elvégezzük az esetleges utófeldolgozást (pl.: a különböző shard-okról származó adatok rendezése). Itt rögtön meg is mutatkozik, hogy mikor nem jó a sharding technológia: ha az utófeldolgozás túl költséges. ‘Sharding a’la Virgo’ teljes szövege

MySQL előadás az OpenSource BI konferencián

Először mi is meglepődtünk, mikor a Sun megkeresett minket, hogy egy BI konferencián kellene MySQL előadást tartani. Már csak azért is, mert BI és DW területen nem kifejezetten elterjedt a MySQL. Gyors telefonos egyeztetés a szervezővel. Szerinte elég aktuális a téma, ha már távközlési cégek is keresnek Magyarországon MySQL adattárház szakértőt. A BI területről jövő résztvevőknek valószínű nem lesz ismerős a MySQL, legyen szó adattárházakról és új dolgokról is, 40 percbe férjen bele. Ez volt tegnap.

A MySQL a cserélhető storage engine architektúra miatt jól testreszabható célfeladatokra egy storage engine cserével. Egy adattárházas storage engine-t onnan lehet megismerni, hogy nem sor, hanem oszlop alapon tárol. Ez elég sok optimalizációra ad lehetőséget, a legtriviálisabb az, hogy tömöríteni jobban lehet (mert egy oszlopban ugyanolyan típusú adatok vannak).

A MySQL és a Falcon engine újdonságait már valószinűleg hallotta előtte is a közönség, ha voltak Oracle 7 vagy 8 újdonságok előadáson. Ez így elsőre viccesnek hat, de ahhoz képest, hogy CRUD adatbáziskezelőnek indult, már támogat tranzakciókat, nézeteket, és triggereket.

Az előadás után többen érdeklődtek a MySQL-ről (főleg az enterpriseról) meg arról, hogy mi milyen esetben milyen adatbáziskezelőt használnánk. Szerintünk sikerült annyira jól, hogy rögtön ide is teszem a prezentációt, hogy le lehessen tölteni.