Meetup prezentációm a.k.a. Firefox kiterjesztések fejlesztése

2008-06-04 11:00

Ma volt Meetup nap, én pedig előadtam. Alap szintű előadás Firefox kiterjesztés fejlesztés témában. Aki esetleg nem tudott eljönni és az eseményeket realtime sem tudta követni, utólag majd megnézheti videón. Az én prezentációm pedig itt is megtekinthető:

kommentek

Első nap a Virgónál

2008-06-02 13:58

Eredetileg nem akartam írni az első napomról, de aztán találtam ezt az első munkanapos élményt az rss olvasómban, és kellett valami, hogy belinkelhessem. Olvassátok el. Vicces.

Velem azonban semmi ilyesmi nem történt. Volt viszont madárcsicsergős meeting, grillparti délben, később torta, még több meeting, és persze munka is. Sőt, ami azt illeti beérkezésem utáni második órában már ki is pipálhattam az első feladatomat, ami egy projekt update volt Rails 2.1-re (BTW, aki nem Edge-en él az lépjen fel 2.1-re. Érdemes).

Azt mondják, azért nem minden nap ilyen, ez csak a beetetés. Viszont a légkör jó volt, és a projekt is jónak tűnik (a rubys része legalábbis). Kaptam monitort is (Samsung 223BW, az itthoni nagyobb, meg jobb is, de a célnak ez is megfelel), meg vadiúj Apple alu billentyűzetet. Persze szokás szerint a magyar Apple kereskedők nem voltak képesek hajlandóak megérteni, hogy angol kiosztással szeretném, de ebből inkább nem csinálok problémát. A következő körben szerintem beszereztetek magamnak egy Griffin Elevator notebook állványt is. Múlt héten volt alkalmam a KiBuban kipróbálni, és beleszerettem.

kommentek

Angol projekt oldal, GitHub repók, stb.

2008-06-01 14:14

Aki még nem tudná, szerdán tartok egy meetup prezit Firefox kiterjesztés fejlesztésről. Aki tud, jöjjön el, infók a meetup blogon. Szóval tekintettel arra, hogy holnap kezdek a Virgónál, nem hagyhattam utolsó pillanatra a prezentáció elkészítését. Nagy valószínűséggel nem lett volna már rá sok időm. Tehát ez készült el ma délelőtt. Szép Keynote-os lesz, syntax highlighttal, meg mindennel. Oh, és easter egg is lesz benne. Erről ennyit.

Ha már úgyis FF kiterjesztésekkel kezdtem a napot, gondoltam rendet rakok közöttük. Felraktam a három fontosabb Firefox kiterjesztésem addons.mozilla.org-ra (AMO), csináltam nekik GitHub-os repositoryt, ezzel hivatalosan is megnyitva a forrásukat. Végül csináltam egy angol nyelvű oldalt, amin összegyűjtöttem a egydélutános projekteket. Ez a lackac.name címen érhető el. Elég fapados lett, de a célnak egyelőre megfelel. Itt amúgy megtalálható a link a kiterjesztések AMO oldalaira és a GitHub repositorykhoz is.

Úgy érzem produktív nap volt. Most pedig alvás, hogy holnap ne legyek teljesen kómás az első Virgós napon.

kommentek

Heroku, majdnem Google AppEngine Railshez

2008-05-29 15:38

Minden Rails fejlesztő arról álmodozik, hogy mikor lesz Google AppEngine-ben Ruby support. Ez persze nagyon hasznos lenne, viszont van itt valami ehhez hasonló jószág, aminek Heroku a neve.

Ez egy online rendszer Rails alkalmazások fejlesztésére és hosztolására. Van webes IDE is, de persze lehet lokálisan is fejleszteni, amihez nem árt alap szintű git felhasználói ismeret, mivel a Heroku a git verziókezelőre épít.

Jelenleg a szolgáltatás meghívásos béta állapotban van. Én már kaptam pár hete meghívást, de sajnos még nem jutott időm alaposabban kipróbálni. Talán meg tudok pár embert hívni, ha valakit érdekel. Most viszont olvasom ezt a Herokuval játszadozós bejegyzést róla és igazán megjött hozzá a kedvem.

Mit akarsz, ez nem is AppEngine

Valóban nem AppEngine-ről van szó, de valami hasonló környezetet kapunk itt is. Az alkalmazások az Amazon EC2 elosztott rendszerén futnak, kapunk egy hasznos parancssori eszközt az alkalmazásaink karbantartására. A deployment annyiból áll, hogy kinyomunk egy lokális verziót a Heroku szerverén található git repositorynkba. A migrationöket, szerverújraindítást elintézi a rendszer helyettünk.

Szóval amit nyerünk:

  • nem nekünk kell szervert konfigurálni
  • Cloud Computing Amazon EC2-őn
  • Webes GUI és/vagy parancssoros segédeszköz és git
  • Teljes Rails környezet (gemek, pluginek)

Mindez jelenleg ingyenes, bár nem hinném, hogy béta után is így maradna. Valami hasonló modellt tudok elképzelni, mint az AppEngine-nél, de erről még nincs semmilyen információ. Bár ki tudja, lehet hogy most RailsConfon bejelentenek valamit.

kommentek

JRuby on Rails komoly környezetben

2008-05-26 02:04

A legutóbbi JRubys bejegyzésben én is arra a következtetésre jutottam, hogy JRuby már most használható production környezetben is. Most pedig itt egy újabb ragyogó példa erre.

A Collaborative Software Initiative (CSI) hasonló gondolkodású cégeket fog össze kollaboratív szoftverfejlesztés során. Nemrég egy open-source web-alapú szoftver fejlesztésébe kezdtek, amely a fertőző betegségek kezelésében és bejelentésében fog segítséget nyújtani.

Fejlesztői platformként a JRubyt és Railst választották. Az InfoQ által készített interjúban a program menedzser elmondja, hogy miért a JRubyt választották, és mik a tapasztalataik vele. Olvassátok el, hasznos. Én most csak egy részt idéznék (kiemelés általam):

More than anything, we have been impressed with the drive of the JRuby community. It is very ambitious and also pragmatic. The core team is comprised of some spectacular developers. The focus seems to be on the right things. Better Java integration, constant performance improvement, and collaborating with the JVM folks on improving the JVM for all dynamic languages. This is all good.

A JRuby fejlesztők valóban mindent megtesznek, hogy ez a platform jól alkalmazható alternatíva legyen bármilyen enterprise, Java, vagy akár Ruby környezetben is.

kommentek

Parancssori kiegészítés rakehez

2008-05-22 04:17

Az egyre növekvő rake task lista sokszor gondot okoz, ha valamilyen feladatnak nem tudjuk a pontos nevét. Ilyenkor segíthet a parancssori kiegészítés (a.k.a. bash completion). Ehhez fel kell rakni a bash-completion csomagot, aminek a mikéntjébe itt nem megyek bele.

Legszebb a dologban, hogy saját kiegészítési stratégiákat is írhatunk tetszőleges programhoz. A fent említett rake szituációhoz írtam az alábbi kiegészítőt:

_rake()
{
    COMP_WORDBREAKS=${COMP_WORDBREAKS//:}
    local curw
    COMPREPLY=()
    curw=${COMP_WORDS[COMP_CWORD]}
    local tasks="$(rake -T 2>/dev/null | cut -d\  -f2)"
    COMPREPLY=($(compgen -W '$tasks' -- $curw));
    return 0
}
complete -F _rake rake
complete -F _rake jrake

Ezt így ahogy van hozzá kell vágni a .bashrc fájlunk végére, terminál újra megnyit, és innentől kezdve ha beírjuk például, hogy rake db: és TAB-ot nyomunk, már látjuk is, hogy milyen lehetőségeink vannak.

Bónusz tipp: hasonló elven működős gem könyvtárt Textmateben megnyitós.

kommentek

JRuby tapasztalatok

2008-05-20 11:56

A hétvégén volt időm játszadozni egy kicsit JRubyval, de arra már nem jutott, hogy össze is foglaljam a tapasztalataimat. Most megpróbálom a lényeget leírni.

Korábban már volt szó itt a blogon arról, hogy mi is a JRuby. A projekt jelenleg a 1.1.1-es verziónál tart és jelenlegi állapotában már akár élesben is használható. A nyelvi elemek és a core library tekintetében 99%-ban kompatibilis a Ruby 1.8.6-al, viszont van néhány limitáció illetve implementációs különbség, amire oda kell figyelni. Ezekről, Rails futtatásról, Java integerációról és GUI programozásról lesz most itt szó.

Limitációk

A JRuby teljes egészében Java-ban írt Ruby implementáció. A platformfüggetlenség jegyében nincs mód arra, hogy részben C-ben írt gemeket telepítsünk hozzá. Ez persze nem minden esetben probléma. Például a mongrel és hpricot gemek képesek java kódra is fordítani a külső függőségüket, hála a Ragel állapotgép fordító rugalmasságának. (mellékszál: erről is kellene írnom egyszer, mármint a Ragelről). Más gemekhez pedig készülnek java alapú implementációk (pl. rmagick4j). Mindenesetre érdemes figyelni arra, hogy szükségünk van-e ilyen gemekre.

Szintén a Java nyelvből adódó további limitáció, hogy a JRuby nem támogatja a folytatódásokat (continuation, mi ez magyarul?), ami tulajdonképpen nem nagy probléma, mivel ez úgysem lesz a Ruby 2.0 része sem. A JRuby nem rendelkezik finom időzítővel, bár ezt a hiányosságot egy jövőbeni JVM verzió orvosolhatja. Szintén JVM-ből adódó hiányosság néhány POSIX metódus hiánya (főleg fájlkezelés területén). Ezeket a hiányosságokat általában meg lehet kerülni, illetve nagyobb részük későbbi fejlesztések során pótolva lesz.

Megint hasonlóan a hivatalos Ruby implementáció következő verziójához a JRuby a JVM jóvoltából natív szálakkal rendelkezik. Ezt talán nem is a limitációk között kellene felsorolni, hiszen ennek köszönhetően sokkal hatékonyabb többszálú programok készíthetők. Mindenesetre ez egy újabb pont, ahol figyelnünk kell az ebből adódó különbségekre.

Rails alkalmazások futtatása

Nem meglepő módon ennek a témának van talán a legnagyobb irodalma (oldal alján linkek). Egy Rails alkalmazás futtatása szinte ugyanolyan egyszerű, mint a hagyományos Ruby interpreterrel. Amire oda kell figyelni, hogy az ActiveRecord működéséhez szükséges az ActiveRecord-JDBC gem, és természetesen az adatbázis szerver JDBC drivere is.

Teljesítmény szempontból, bár pontos méréseket nem végeztem, az indulás kivételével sokkal gyorsabbnak tűntek az alkalmazások, mint MRI-vel. Az indulás általában lassabb, ami leginkább a jirb (JRuby irb) esetében idegesítő. Maga a Rails alkalmazás viszont még tovább gyorsítható AOT fordítás segítségével. Ezt Rails alkalmazáson nem próbáltam még.

Nem mozgok túl otthonosan a Java alkalmazás szerverek világában, de a JRuby wiki alapján úgy tűnt, hogy ezek nagy része szintén támogatott. Lehet Rails alkalmazást futtatni Tomcat, WebSphere és GlassFish környezetben is. Ez igazán hasznos lehet Javaban írt enterprise rendszerekkel való integrálás elősegítésében. Az enterprise környezet beli alkalmazásról további tapasztalatok olvashatók egy Fortune 100 egyikének dolgozó feljlesztőtől.

Java integráció

Az eddigiekből már valószínűleg kiderült, hogy a JRuby legnagyobb előnye társaival szemben a java integráció. És ez nem csupán a JVM előnyeiben merül ki, hanem lehetőség van kétirányú kapcsolatra is Ruby és Java kód között. A legegyszerűbb talán egy rövid példával illusztrálni:

require 'java'
include_class 'java.util.ArrayList'

list = ArrayList.new
list.add(1)
list.add(7)
list.add "negyvenketto"
list.each {|i| puts i} # prints "1\n7\nnegyvenketto\n"
list.remove(7)
list.add "bye"
list.each {|i| puts i} # prints "1\nnegyvenketto\nbye\n"

Persze a példa kicsit buta, de a lényeget szemlélteti. Az include_class metódushoz hasonlóan lehetőség van teljes package-et is betölteni: include_package('javax.swing').

Ennél picit bonyolultabb a másik irány. Még nem sikerült magamon erőt vennem, hogy 10 sornál több Java kódot írjak, ezért ezt még nem próbáltam, de a vállalkozó kedvűek erről is találhatnak bőven dokumentációt.

GUI programozás

Köszönhetően a jól kiforrott Java-ás GUI programozási lehetőségeknek, már ez sem olyan terület, ahol a derék programozó csak fejvakarva áll. Persze eddig is voltak megoldások, de korántsem voltak mindenre alkalmasak. Persze a Ruby nem is olyan nyelv, ami elsősorban erre hivatott, de ezek a lehetőségek mégis nagyon hasznosak tudnak lenni a gyors prototipizálásban.

Hogy még egyszerűbb legyen a helyzet itt egy lista a Javas GUI könyvtárakhoz írt segédkönyvtárakról. KiBus múltamból kifolyólag engem egy itt nem említett fogott meg. A JRuby lehetőségeit kihasználva egy srác írt egy keretrendszert a népszerű Processing vizualizációs környezethez. A Ruby-Processing segítségével mindazt meg lehet valósítani, amit processingben, még külső library-k betöltésére is van lehetőség. Egyre azért érdemes figyelni. A JRuby alapesetben JIT módban futtat, ami valós idejű vizualizációhoz lassú. Az AOT mód segíthet, de még így is lassabb lesz, mint a natív Java.

Overall tapasztalatok, összegzés

Legyen az webalkalmazás keretrendszer, vagy GUI programozás a JRuby mindegyik esetben jól használható. A fent említett limitációkon kívűl más kompatibilitási problémába nem ütköztem. Az integrációt szépen megoldották, és ezen a területen a Java 1.7 megjelenésével még további javulások várhatóak.

Ugyanakkor fontos figyelni arra, hogy minden helyzethez a megfelelő eszközt alkalmazzuk. Webalkalmazás futtásra a JRuby már most nagyon jól használható, és jó alternatíva lehet Java-ás rendszerek helyett, vagy akár azokkal integrálva is. Ahol lehet ott, érdemes előre fordítani a kódot, mivel a JIT fordítás nem hoz sok javulást az MRI-hez képest. A számítás intenzív és grafikus feladatokat pedig ha lehet hagyjuk a Java-ra. Azért van az is ott, hogy segítsen.

Végül pár hasznos forrás és tutorial:

kommentek

PageRank adatok lejáró domainekhez és Callout fix [update]

2008-05-16 02:27

Két update korábbi projektekhez. Ami a domain feedes projektet érint, a két feed átkerült FeedBurnerre, és raktam PageRank adatot a lejáró domaines feedbe. A feedek címe és további részletek az domain feedes bejegyzésben. A másik a callout projektet érinti. Kijavítottam (remélhetőleg) egy bugot, ami miatt a GreaseMonkey egy idő után megszűnt működni. Ha továbbra is tapasztaljátok, hogy pl. a TurulRewind eltűnik egy idő után, akkor szóljatok. Nekem úgy tűnik, hogy mostmár ez rendben van. A bugfixhez telepítsétek a Callout 0.3.2 verziót.

Update

Hangya jóvoltából a parkoló domaines feed elérhető PageRank alapján szűrt formában is. A megoldás Yahoo Pipes-szal készült, és köszönet érte. Amúgy hamár ott voltam belenéztem a Pipesba. Sokat fejlődött, mióta legutoljára láttam, ami körülbelül akkor lehetett, amikor indult. Akkor még ilyen bonyolultabb dolgokat nem lehetett összerakni, úgy tudom még reguláris kifejezések sem voltak. Így már használni is lehet.

kommentek

Egy év távlatából

2008-05-15 06:36

Észre sem vettem és eltelt egy év a lackac.hu blog életében. Az első bejegyzés tavaly április 29-én keletkezett. Azóta változtak picit a témák, gyakoribbak lettek a bejegyzések, és hát sok minden történt az egy év alatt.

Ebben a visszatekintő bejegyzésben összeválogattam, hogy nekem mi tetszett leginkább a korábbi posztok közül. Nem szempont a bejegyzések forradalmi jellege, még csak az írás minősége sem. Inkább az alapján válogattam, hogy milyen hatással volt rám.

A kezdetek

Az egész a Kitchen Budapesttel indult. Kellett egy hely, ahova felrakom a pályázatomat, és amúgy is mocorgott bennem egy blog gondolata. A következő fél évet nagy mértékben meghatározta a KiBu. Olyan dolgokon dolgoztam ott, mint egy multitouch screen, amiről az első beválogatott bejegyzés is szól. Túl sok időm nem maradt Rubyra és Railsre, és bár több kibus projektben is használtam őket, nem ez volt sajnos a jellemző.

Hobbi projektek

Tavaly december környékén kezdett elegem lenni a médiaművészesdiből és elkezdtem más irányba nézelődni. Ekkor indult be a hobbiprojekt gyártás is talán az egydélutános hat-or-not projekttel. Ez a projekt amúgy a későbbiekben kitűnő talajul szolgált mindenféle Rubys kísérletezésre, bár ezekből nem sok minden látszik. Ide tartozó infó, hogy az egészet lehet hogy újraírom pythonban, hogy legyen mivel Google AppEnginet tesztelnem.

Később építettem domain rss feedet egyik kedvenc ruby gememmel, és a tavaszi konferenciaszezont pedig egy online backchannel szolgáltatással indítottuk. Ehhez kapcsolódó hír, hogy a backchannellel kapcsolatban még nagy terveink vannak. Csak jusson idő rá.

Firefox kiterjesztések

Már nem is tudom hányszor váltottam ide-oda Safari és Firefox között. Talán a második Firefox 3 béta környékén ez újra megtörtént a tűzróka irányába, és végül ott is ragadtam. Az indok, hogy sokkal használhatóbb macen, mint elődei, és egyszerűen kiegészíthető új funkciókkal. Erre kicsit rá is kaptam és ennek hatására született több firefox extension is. A kedvencem ezek közül a rendszerüzenet küldözgetős, de nézzétek meg a többit is.

Növekvő forgalom

A gyakoribb posztolásnak és természetesen a twitter közösségnek köszönhetően a lackac.hu felkeltette "A"-listás blogger Angelday figyelmét is, minek következtében a blog megtapasztalt egy plastik effektet. A látogatási statisztikákat arra a pár napra szépen megdobta a plastik felől jövő forgalom, és jó látni, hogy az új látogatók nagy része megmaradt később is.

Szakmai mozgolódás

A kibus félév után már nagyon hiányzott az aktív webfejlesztés, úgyhogy tavaly év végén megkerestem egy régi francia ismerősömet, Etiennet, aki itt élt Budapesten, és korábban már ajánlott Rubys munkát. Végül becsatlakoztam pár projektjébe, amit a Woa csinál, és nagyon jó volt. Mivel ezt csak kvázi félállásban csináltam, azt kezdtem el tervezgetni, hogy alapítok céget, és bevállalok más közben kirajzolódni látszó projekteket is. El is indultam ennek rögösnek vélt útján, amiről az első cégalapítós bejegyzésben írtam. Később azt beszéltük meg Etiennenel, hogy mivel ő amúgy is meg akarja szüntetni a magyar cégét, és csak a franciát viszi tovább, én átvenném tőle a stafétabotot. Persze ez se lett volna sokkal egyszerűbb, mint egy cégalapítás, de legalább mindketten jobban jövünk ki.

Végül mégsem ezt az utat választottam, mivel kaptam egy jobb ajánlatot a Virgo Systemstől. Sokat töprengtem, hogy elfogadjam-e, de végül úgy döntöttem, hogy jelenleg ez a legjobb számomra. Aztán majd meglátjuk.

Szóval itt tartok most. Aki idáig elolvasta, annak köszönöm. A kommentekben szívesen látnám, hogy nektek melyik bejegyzések tetszettek leginkább, és javaslatokat is szívesen fogadok.

kommentek

Ruby implementációk és a Ruby jövője

2008-05-05 16:25

A hosszú hétvégém kicsit másképp alakult, mint ahogy terveztem, így nem jutott még időm jobban belemélyülni a JRuby rejtelmeibe. Ehelyett elolvastam Charles Nutter szép hosszú írását a különböző Ruby implementációk ígéreteiről és veszélyeiről. Charles, aki a JRuby egyik fejlesztője, a cikkben a főbb Ruby implementációk történetét, jelenlegi állapotát és jövőjét elemzi. Ajánlom mindenkinek, akit kicsit is érdekel a téma, érdekes és hasznos olvasmány.

Röviden Összefoglalom, hogy mik a fő meglátásai. Egy implementáció életében szingularitásnak tekinthető, amikor képes gond nélkül futtatni Rails keretrendszerre épülő alkalmazásokat. Egyrészt mivel erről szól ma a Ruby világ nagy része, másrészt mert ez magával vonz más sok hasznos dependenciát is (IRB, RubyGems, Rake). Ennél talán lényegesebb szingularitás definíció lehet egy implementáció életére nézve, amikor ezt képes a Ruby 1.8 sebességénél gyorsabban megtenni.

A Ruby 1.8 (MRI, Matz Ruby Interpreter) jelenleg a kvázi sztenderd implementáció. Azért csak kvázi, mivel nincs hivatalos specifikáció (de erről majd később). Lassú, nincs natív szálkezelés és nagy a memóriaigénye. Mégis ez a legelterjedtebb, erre készülnek elsősorban az alkalmazások, ezzel kompatibilisek a gemek. Sok Rails skálázási probléma visszavezethető a Ruby 1.8 hiányosságaira. Idővel azonban ez az implementáció idejétmúlt lesz, a fejlesztők továbblépnek, és egy szebb világ köszön ránk.

A Ruby 1.9 fejlesztésénél nagy hangsúlyt fektettek a Ruby 1.8 fent említett hátrányaira. Beépítették a YARV ("Yet Another Ruby VM") Bytecode alapú futtató motort, ami Koichi Sasada munkája. Van több szintaktikai újítás is, normális Unicode támogatás, de a Ruby jövője szempontjából sokkal fontosabb az új memória modell és a Bytecode alapú futtatás. A Ruby 1.9 azt jelképezi, ahova a többi implementáció kell majd valamikor eljusson. Már most gyorsabb az 1.8-nál és gyakorlatilag használható állapotban van. Még mindig mozgó célpont, sok dolog még nincs véglegesítve, de jelenlegi állapotában elmondható róla, hogy nagyjából elérte a második szingularitást. A Ruby 1.9 problémája, hogy bár gyors, még mindig nem eléggé. Teljes alkalmazásokon tesztelve a sebességnövekedés általában nem éri el még az 50%-ot sem.

A JRuby egy Java alapú Ruby implementáció. Szinte teljes egészében kompatibilis a Ruby 1.8 implementációval, és a fejlesztők több dolgot is átvettek az 1.9-ből. Szintén képes nagyobb Rails alkalmazásokat futtatni. Gyorsabb, mint az 1.8 interpretált és fordított módban is. Interpretált módban nagyjából 15-20%-kal, fordított módban többszörösen gyorsabb. Mivel a JVM-re épül, annak a objektum modelljét, Garbage Collector-át és bináris reprezentációját használja. További előnye a JVM alapoknak, hogy képes Java osztályokkal is kommunikálni, ami előny nagyvállalati környezetben való alkalmazáskor.

Az alternatív implementációk közül a JRuby áll a legjobb helyen, és nem csak a stabilitás, gyorsaság és kompatibilitás területén, hanem a fejlesztői aktivitás területén is. Két fő fejlesztője 2006 óta a Sun alkalmazásában dolgozik főállásban a projekten. Charles a cikkben a JRuby 2.0-át teljes Java integrációval év végére jósolja.

Fejlettségét tekintve a JRubyt a Rubinius követi. Evan Phoenix által indított projekt célja egy olyan Ruby implementáció elkészítése, ami minél nagyobb részben Rubyban íródik. A kód nagy részét a sebesség vagy néhol a kód függőségek miatt kénytelenek C-ben írni, így jelenleg nagyjából 50-50% a két nyelv aránya. Ez nyilván a Ruby oldalára dönti a mérleg nyelvét, hiszen ugyanannyi sor forráskód Rubyban sokkal többet tud kifejezni, mint C-ben.

A Rubinius ígérete, hogy ha sikerül kompatibilissé tenni, és gyorsabbá, mint az 1.8, akkor ez akkár jobb implementáció lehet az 1.9-nél is. Mivel a kód nagy része Rubyban van, ezért ha elérik, hogy a Ruby kód gyorsan fusson, akkor az ezekre is hatással lesz. A Rubinius veszélyei a legnagyobb előnyéből fakadnak. Míg a kompatibilitással nagyon nem lesznek gondjaik, addig a teljesítménnyel kapcsolatban nagy kihívások elé néznek.

Tavaly az IronRuby implementáció bejelentése villanyozott fel. Ez egy .NET alapú implementáció, és ebben a tekintetben hasonlít a JRuby projektre. A fejlesztést a Microsoft indította, bár a kódba beemelték egy korábbi .NET alapú implementáció, a Ruby.NET lényegi részeit. Az IronRuby az IronPythonhoz hasonlóan a Microsoft DLR-jére épül (Dynamic Language Runtime), aminek a segítségével könnyen lehet .NET-en futó dinamikus nyelv implementációkat készíteni. A projekt a Microsoft OSS licensze alatt fut, de sajnos a fejlesztés nem folyik hagyományos Open Source szellemben. Főként néhány MS fejlesztő dolgozik rajta, akiket John Lam vezet, a meetingek zárt falak mögött folynak, és a forráskódhoz sincsen "élő" hozzáférés.

Az IronRuby segítségével lehetőség lesz Windows Desktop alkalmazások fejlesztésére is. Silverlightra már most is lehet fejleszteni. Ezzel együtt az IronRuby legnagyobb ígérete egy gyors és jól használható Windows alatt futó Ruby implementáció. A Windows eddig a mostohagyerek szerepét töltötte be a Ruby világban. Én pár éve próbálkoztam egyszer Windowson Railst futtatni, de egy napi szenvedés után feladtam. Valamit sikerült összehozni, de közel se éreztem magam olyan otthonosan a kialakított fejlesztőkörnyezetben, mint Linuxon vagy MacOSX-en.

Windows support in Ruby has always lagged behind UNIX support, partially because Windows "sucks" for various definitions of "sucks".

Kompatibilitás tekintetében sokat kell még a projektnek fejlődnie. Még messze áll attól, hogy Railst tudjon futtatni. Sebesség tekintetében viszont hasonló eredményeket érhet el, mint a JRuby.

A főbb implementációk közül az utolsóként említett meglepett. A MacRuby az Apple alkalmazásában álló Laurent Sansonetti műve, és célja egy olyan Ruby 1.9-re alapozott implementáció, mely Objective C környezetben fut. Az eddigiek közül erről még nem hallottam, viszont igazán ígéretesnek tartom. A Ruby 1.9-re alapozás érdekes választás, hiszen az 1.9 még sokat változhat a jövőben, másrészt viszont érhető, mert így annak sok előnye megtartható. A MacRuby leginkább a JRubyhoz, vagy az IronRubyhoz hasonlítható. Ez egy olyan implementáció, ami sok előnyt kovácsolhat a Objective C környezetbe való integráltságból. Valószínűleg gyorsabb lesz az 1.9-nél is, és segítségével sokkal egyszerűbben lehet majd MacOSX alkalmazásokat (akár iPhone alkalmazásokat?) fejleszteni.

Jelenlegi állapotában még nem képes nagyobb alkalmazásokat futtatni, és távol áll attól, hogy Railst futtasson, de ahogy valaki a kommentek között rámutat, a MacRubynak nem a gyorsabb Rails futtatás lesz a legnagyobb előnye, hanem a szoros integráció a MacOSX rendszerrel.

Záró gondolatok

Valamelyik blogon pár hónapja olvastam egy kritikát a sok implementáció negatív hatásairól (most nem találom a cikket). Már akkor sem értettem teljesen, hogy miért lenne probléma a sok különböző implementáció. Egyrész mindegyiknek megvan a maga felhasználási területe, másrészt nagy előnye ezeknek a projekteknek, hogy a különböző implementációk fejlesztői együtt dolgoznak egy Ruby specifikációs projekten, amivel elkerülhetők a inkompatibilitási problémák.

Véleményem szerint ezek a projektek együtt fejlődve tovább finomítják a nyelvet, és stimulálják a Ruby közösséget. A fejlesztők közötti egészséges versenyszellem pedig szintén a közösség javára válik, akik stabil és gyors implementációkat kapnak minden fontosabb környezethez.

Egy későbbi bejegyzésben mindenféleképpen visszatérek a JRubyra. Azért is érdekel a téma, mert lehet hogy lesz jövője a Virgos munkám során is, lévén ők eddig leginkább Java és .NET rendszereken dolgoztak. És ha már kísérletezgetek, vetek egy pillantást majd a MacRuby projektre is.

kommentek

« Újabb bejegyzések | Régebbi bejegyzések »

Ez itt Bácsi László blogja Rubyról, Ruby on Railsről, JavaScriptről, saját projektekről.

Ajánlj engem