So, I ran into a weird situation: when I installed Windows, I used Live account to create my user. In preview version of Windows 8 it created a profile dir based on the user part of e-mail address of the Live account, so from [email protected] it created an user hrgy with same profile dir. However, the final version is changed it to create account based on your first name, it was “Gábor” in this case. Notice the accented second letter.

The problem with folders containing non-ASCII char in its name is obvious: not all program can handle it correctly. It has a displaying problems in some apps, and some apps cannot create their files in this profile.

The fix was not so easy but I now describe required steps.

First if you do not have an another administrator user than you, then you have to create it. Windows 8 does not allow to log into the built-in Administrator account anymore, so you have to create one in Control Panel. It’s pretty straighforward and net contains a bunch of howtos for it, so I skip describing this step.

Now, log out from your account, and log in into the new one.

Start regedit and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

In the subkeys (subfolders) find one what displays your old dirname in ProfileImagePath attribute. In my case the value was C:\Users\Gábor. Right click, edit and replace last part of the path to what you want to use.

Important: Even if world collapsing, do not log in into your own account (what being modified) until you finish these steps!

Then, you have to reboot into Safe mode. The easiest way is press Shift + F8 during boot. If you seeing the Windows splash displaying in “wrong” resolution then you are in Safe mode.

Important: you have to log in into the newly created admin account, not into your own one!

Then you have to rename your profile folder. Start a command prompt in Safe mode, and type following:

cd C:\Users
move old_name new_name

The old_name is the old name of your profile directory, the new_name is what you specified in RegEdit. In my case it was:

cd C:\Users
move Gábor hron

Now you are done! If you striclty follwed this tutorial, then if you reboot and log in into your account, you do not see any change, except the %USERPROFILE% environment variable carries the new name.

Note: I saw only one bug: iCloud Photo stream stored the full path of my Pictures folder in its database and I had to relocate it. It’s a bug in iCloud, not a Windows problem.

Disclaimer: This tutorial is tested by me but I do not guarantee anything. Take a backup from your important data before start doing this. I am not responsible if your data lose, you cannot login anymore or your kitten vanishes.

Az előző cikkben alapszinten megismerkedtünk az Nginx-szel, valamint megtudtuk, mitől és miben gyorsabb, mint a kihívójának szánt Apache.

Ebben, és a következő cikkben azt vizsgáljuk, hogy hogyan tudunk egy PHP alapú site-t futtatni vele, például egy Drupal alapú portált.

A cím az utolsó betűig igaz - de csak addig. Pár hete (hmm… hónapja?) jártam-keltem a KÖKI Terminálon nyílt Tescoban, és nem tudtam elmenni egy fahéjas sütemény mellett, nevetséges áron volt, “Hamar kész” - hirdette a felirat. Naná hogy vettem.

Ma jutottam el odáig, hogy megint eszembe jutott (egy fenét, pár napja kerestem valamit a fagyasztóban és szembejött), mondom pocsékba ne vesszen már, megcsinálom.

Szóval, vettem egy nagy levegőt, meg egy még nagyobb tepsit (úgy értem, a levegőnél…) és belevágtam. A címke szerint 80 percet kell pihentetni, hát gondoltam, ez nem olyan betű szerinti dolog, hogy percre kellene betartani, ebédcsinálás előtt kiraktam, ebéd + pihi után álltam neki megcsinálni. Volt az 90-120 perc is, de ki számolja…

Aztán olyat mondott a címke, hogy vegyek sütőpapírt, borítsam a tepisbe, és utána rá a sütit. Na most nekem elég sokféle papír kószál itthon, sütőpapír az pont nem. Mivel már belevágtam (az ilyet nem szabad visszafagyasztani, mert elég undorító lesz utána) így a sütőpapírt kicseréltem alufóliára, mert az volt itthon. A csere egyszerű volt, tepsiből nem létező sütőpapír kidob, alufólia beterít.

A következő utasítás az volt, hogy 185 fokon kell sütni. Mivel nekem csak ilyen nempontos gázsütőm van, belöktem 5-ös fokozatra, és felhúztam az órát öt percre, ha nagyon elszaladna a ló, ott még lehet korrigálni mondjuk egy 4-es fokozattal. Kimentem, semmi extra, rápörgettem még 5-öt a kisvekkerre (a címke 10-12 perces sütést ír, de ez valami sablonból van, sosem vettem még olyan terméket, amit tényleg meg lehett volna csinálni ennyi idő alatt. A jobbik esetben nyers volt, a rosszabbikban… hát… érdekesen sötét).

Csörgésre lustán kiballagtam (+1-2 perc), megvizsgáltam úgy szemileg, meg megbökdöstem a kés hegyével, lagymatag és puha volt, szóval kollektív döntésként született, hogy kell neki még 5 perc. Kisvekker orrát megtekertem megint.

Miután megint egy cikk kellős közepébe csörgött bele a határidő, így úgy döntöttem, hogy egy életem, egy halálom, én bizony ezt nem fogom visszarakni a sütőbe, lett légyen akármilyen is az a sütemény. Végül nem volt szükség ilyen kemény elhatározásra, a süti magától is nagyon szép állagú lett, picit barna, de az nem baj.

A kiszedéssel viszont megszenvedtem. Mondjuk úgy, hogy nem véletlen ajánlanak ehhez sütőpapírt, bár az is csak felezi a kiszedési időt, ellenben megkönnyíteni nem fogja. A fahéjas töltelék ugyanis elég ragaszkodó természetű, viszont engem annyira nem kedvel, inkább az alufólia iránt mutatott élénk érdeklődést. Végül több, mint 20 perces hősies küzdelem után rá tudtam beszélni arra, hogy egy rongyos, összetépett, ragacsos alufólia közel sem annyira vonzó, mint egy szép új kéztőrlővel leterített tiszta tányér.

Tanulságok:

• Kell venni egy tekercs sütőpapírt, akkor is, ha csak szökőévente egyszer támad ilyen ötletem. Mivel nem romlik meg, nem szagosodik meg, valamint alig foglal helyet, így mindenképpen megéri, főleg, mert elég sok időt megspórol.
• Sose higyjünk a címkére írt sütési utasításnak vakon. Mindig ellenőrizzük szemileg a készülő termék állagát, mert azt a címkét Átlag Istvánné szül. Mindegy Jolán számára írták, nem pedig nekünk.

Ettől eltekintve ízre semmi probléma, a kicsit megkaramellizálódott alap pedig abszolút nem okoz problémát.

I just created this small hook for my Rails projects. It helps me to make my codebase clean.

You can clone it at Gist

I sucked a bit with Gitiles, Gerrit’s Gitweb implementation, because this project lacks an INSTALL file.

So, basically you have to do following:

• First, check out of the source:

  git clone https://gerrit.googlesource.com/gitiles

• After you cloned the source, compile it with Maven:

  mvn package -Dmaven.test.skip=true

Now, you got gitiles-war-1.0-SNAPSHOT.war in gitiles-war/target folder. Deploy it under your application server, in this case I put it to Jetty’s webapps folder.

• Tricky part is coming: you will faced with an error message, what says some configuration options are missing. This is because you didn’t created any configuration file yet. By default, webapp searches its configuration in the webapp root folder, but - because jetty explodes this folder every restart, I decided to put it to some more persistent place. I am do not run any other thing under this Jetty than Gerrit and Gitiles, so I created the gitiles.config under Jetty’s etc folder:

1
2
3
4
5
6
7
8
9
10
11

[gitiles]
    # Repositories placed here
    basePath = /srv/git/repositories
    # Do not check they are exported
    exportAll = true
    # This URL will be displayed as clone URL. DO NOT FORGET TRAILING SLASH!
    baseGitUrl = ssh://cr.hron.me:29418/
    # Title of site (doh)
    siteTitle  = Gitiles - kingmax.hron.me:/srv/git/repositories
    # I dunno why, but it is have to be configured.
    canonicalHostName = kingmax.hron.me

• The config file above is cool, but Gitiles still crying… yeah, because you have to tell where it should find that. To do this, you must export a System property com.google.gitiles.configPath. I was very lazy, so I edited jetty.xml and before last closing tag I pasted this:

1
2
3
4

<Call class="java.lang.System" name="setProperty">
    <Arg>com.google.gitiles.configPath</Arg>
    <Arg><SystemProperty name="jetty.home" default="." />/etc/gitiles.config</Arg>
</Call>

Ezen cikk a tervek szerint egy sorozat része lesz, amely majd szép lassan (ahogy időm engedi) kerül ki a blogra.

Lássuk tehát az első részt, mely - ahogy a cím is utal rá - egyfajta általános bemutatása lesz ennek a pici webszervernek.

Mi az Nginx?

Az Nginx neve az angol Engine X (X motor) kifejezésből származik, ejteni is eszerint kell, tehát ˈen-jən eks.

Magát a motort egy Igor Sysoev nevű srác fejleszti 2002 óta, a kód maga 2004-ben lett nyilvános. Az elsődleges cél egy pehelysúlyú, ugynakkor skálázható webszerver létrehozása volt, mely képes egy online tartalomszolgáltatónál felmerülő legtöbb problémával megbirkózni, például az ún. C10K problémával, a legtöbb akkori webszervernek ugyanis problémát okozott egyidejűleg több, mint 10 000 kapcsolatot kezelni.

Jelenleg az Nginx a világ harmadik legnépszerűbb webszervere, a 2012-es NetCraft felmérés szerint az összes mért oldal 12.07%-át Nginx segítségével szolgálják ki.

Az Nginx előnyei

De mi teszi oly népszerűvé ezt a furcsa nevű webszervert? Mi az, amiért egyre-másra jelennek meg leírások, tutorialok hozzá, ami a legbiztosabb jele egy termék népszerűségének?

Az egyik kétségtelen ok a gyorsaság. Az Nginx statikus fájlok kiszolgálásában és proxyként is sokkal nagyobb sebességgel szolgál ki elődjeinél. A Wordpress.com mérései szerint - megfelelő gép mellett - az átlagos 70000 req/s simán elérhető vele.

Ennek az egyik oka az, hogy az Nginx nem feltétlenül forkol mindig külön processzt vagy szálat az új kapcsolatoknak, ahogy pl. az Apache egyes feldolgozómoduljai (prefork, ITK) teszik, sőt erre nincs is szüksége, mert eseményalapú a feldolgozása, így nem csak több kapcsolatot, de több eseményt is le tud egyetlen feldolgozó szál kezelni. Ennek köszönhető egyébként az is, hogy hasonló terhelés mellett a memóriaigénye messze elmarad a klasszikus webszerverekétől. Erről bővebben itt lehet olvasni.

A másik oka az, hogy az Nginx sokkal agresszívebben cachel a memóriában az elődjeinél. Megfelelő konfigurálás és többé-kevésbé fix (nem, vagy ritkán változó) tartalom mellett elérhető az, hogy gyakorlatilag a memóriából történjen a kiszolgálás.

A pufferelés egyébként nagyon sokrétűen konfigurálható, ugyanakkor nem a legkönnyebben emészthető téma.

Előnye még a jó minőségű dokumentáció. A legtöbb modulnak nagyon részletes dokumentációja van, néhány konkrét használati eseteket is bemutat, mely teljes biztonsággal átvehető egy az egyben a saját konfigurációnkba.

További előnyeként szokták sorolni a konfigurációs fájl könnyű érthetőségét. Akik valamilyen C szintaxisú nyelvben (PHP, Perl, C/C++, Java, stb) programoznak, azoknak nagyon is ismerős lehetnek a blokkok és a sorvégi pontosvesszök, melyekből a konfiguráció felépül.

A következő cikkben az Nginx és a PHP kapcsolatát fogom bemutatni, és példákon keresztül szemlélteni

Este újra megnéztem az Avatar-t, éjjel pedig furcsa álmom volt. Gyakorlatilag továbbálmodtam a történetet, pedig ez ritka eset nálam.

Szóval, a sztori lényege az, hogy Jake, miután az emberek többsége elhagyja a bolygót, két ottmaradt tudóssal nekiáll felfedezni azt. Az gondolom már a filmből is mindenki számára világos volt, hogy ez gyakorlatilag egy hatalmas, dúsan burjánzó dzsungel. Ami nem, az az, hogy a bolygón vannak olyan helyek, “szent helyek”, ahova még a Navik se mennek túl sűrűn. Jake bemerészkedik az egyik ilyen helyre (amit persze a népe nem igazán helyesel, de nem igazán tiltják meg, bár figyelmeztetik őt a veszélyre). Mint kiderül, ezek a helyek valójában romok, egy fejlett, de letűnt civilizáció romjai.

Ha hasonlítani kellene, akkor a földi dél-amerikai civilizációhoz hasonlítanám, azonban annál sokkal fejlettebb, idősebb civilizációról van szó. Azt tudjuk, hogy a ma ismert Navik együtt élnek a természettel, igyekeznek minél kevesebb kárt okozni. Nos, elődeik kapcsolata a természettel ennél sokkal bonyolultabb volt. Bár ők is természetimádó nép voltak, azért az nem okozott nekik gondot, hogy a nagy erdőségekből kis ligeteket csináljanak, miközben terjeszkedtek.

No, de vissza a sztorihoz. Szóval Jake bemerészkedik az egyik ilyen romba, felderíti, és találnak pár érdekes leletet, köztük néhány vésetekkel teli kőtáblát. Ezeken főképp képek láthatóak, írás szinte alig, de annyit azért sikerül kiolvasni belőle, hogy itt egy fejlett civilizáció lakott, elég nagy lélekszámmal. Találtak néhány térképet is a holdról, illetve olyan szintű leírásokat az óriásbolygóról, ami egyértelművé teszi, hogy űrutazásra képes fajról van szó.

Egy másik romban, találnak egy furcsa, fallal lezárt helységet. Majd’ egy hónapjuk rámegy, mire sikerül kitalálni, hogy jussanak be. Bent két asztalt találnak, két-két székkel, a mennyezeten pedig fura díszítésű panelek lógnak a két asztal felett. Az egyik kutató, aki korábban azt próbálta meg kitalálni, hogy milyen jellegű mezőgazdasága volt a civilizációnak, fáradtan roskadt le az egyik székre… majd meglepően gyorsan el is aludt. Néhány perc múlva felébredt, és elmondta, hogy rájött a megoldásra, ilyen és ilyen eszközöket használtak, stb. Mivel erre vonatkozóan eddig semmilyen bizonyítékot nem leltek, persze mindenki kételkedett a szavában. Pár nappal később azonban felfedeztek pár mezőgazdasági témájú vésetet, ami pontosan megfelelt a kutató által vázoltaknak. Néhány további kísérlet után rájöttek, hogy a szoba egyfajta tudástárként működik, letölti a betérő fejébe azokat a válaszokat, melyekre kiváncsi.

Jake közben talál egy kötáblát, tele neveknek és dátumoknak tűnő vésetekkel. Ő is kipróbálja a szobát, és valami különös történik…

Az a tábla valóban neveket tartalmazott, méghozzá különböző uralkodók neveit. Amikor Jake leül a szobában, egy név jár folyamatosan a fejében, a szoba pedig hozzáférhetővé teszi számára ezen uralkodó naplóját. Mint kiderül, a Navik ősei nem volt egységes faj, az egyes klánok közt folyamatos volt a viszálykodás. Az az uralkodó, akinek a naplójához Jake hozzáfért, az utolsók egyike volt. A faj hosszú életű volt, a száz helyi év teljesen átlagos kornak számított, a mai embernél talán valahol 50-60 évnek felel meg. Az uralkodó naplójába gondosan feljegyezte az általa vívott harcok minden eseményét. Pusztító harcok voltak ezek, rengeteg áldozattal. A naplóbejegyzésekből azonban az is kiderül, hogy írójuk belefásult a harcba, értelmetlennek találja, ő maga már nem is nagyon támadt, csak a városát védelmezte. Mivel tisztában van azzal, hogy nem győzhet, összedob egy csapatot nőkből és gyerekekből, akiket beküld az egyik erdőbe. Pár évvel később egy - közelebbről meg nem nevezett - fegyver elpusztítja az egész civilizációt, a naplót író uralkodó is teljesen véletlenül menekül meg.

Csatlakozik a menekültek csapatához, és elhatározzák, hogy újrakezdik, de az alapoktól. Megtiltja, hogy visszamenjenek a romokhoz (nem mintha nagyon lenne miért…), és elkezdenek az ősi módon élni, gyűjtögetni, vadászni… Ő maga is csak egyszer megy vissza - a halála előtt nem sokkal -, hogy befejezze a naplóját.

A Navik faja tehát újrakezdés, visszatértek ősi gyökereikhez, és teljesen elfeledték a múltat.

Jake és csapata úgy dönt, hogy erről nem szólnak a Naviknak. Ha egyszer maguktól megtalálják a tudástárt, hát legyen, de nem látják értelmét annak, hogy ezt a népet megbolygassák ilyen szörnyű emlékekkel.

Azért vannak dolgok, amikkel lehet szépeket szívni.

A feladat valami olyasmi volt, hogy kell egy újrafelhasználható “cím” osztály, ami külön táblára is képeződne le, hogy ne a megfelelő táblákat terheljük feleslegesen, plusz a címek amúgy se mindig kellenek pl. a felhasználókezeléshez. Azért kell újrafelhasználhatónak lennie, mert két különböző dolog is használ címeket a rendszerben.

Nem akarom nagyon húzni az időt, az alábbi kód született rá:

1
2
3
4
5
6
7
8
9

class Address < ActiveRecord::Base
  belongs_to :addressable, :polymorphic => true
end

class User < ActiveRecord::Base
  has_many  :addresses, :as => :addressable
  has_one   :billing_address , :as => :addressable, :class_name => 'Address', :conditions => { :billable => true, :shippable => false }
  has_one   :shipping_address, :as => :addressable, :class_name => 'Address', :conditions => { :shippable => true, :billable => false }
end

Erre kedves barátom azt mondaná, hogy szép baleset. És akkor még nagyon finoman fogalmazna. Nézzük, mik azok a buktatók, amin át lehet esni egy ilyet nézve:

• A has_many asszociáció ugye azért kell, hogy legyen valami, ami polimorf. Elvben bele lehet suvasztani a has_one mellé is, de nekem egyébként is kell tudnom a címeket egyben lekérni, akkor meg miért ne emelném ki?
• Az előbbi asszociáció alapján definiálunk két hozzárendelést. Ugye itt a hangsúly a :conditions hashen van, ez mondja meg, hogy a polimorf tömbből mely adatok kellenek (pontosabban, hogy az asszociáció alapján generált query-ben a WHERE feltétel hogyan bővüljön)
• Az egyik trükk az, hogy mindenképp meg kell adni az osztályt is, ugyanis a has_one asszociáció nem kéri le ezt az infót a hivatkozott polimorf asszociációtól, hanem saját maga áll neki találgatni - természetesen rosszul.
• A másik trükk pedig, hogy mivel ez egy kétparaméteres, egymást kölcsönösen kizáró feltétel, így mindkettőt meg kell adni, különben létrehozáskor előjöhet olyan csúfság, hogy valaki meghinteli a dupla false-t - vagyis úgy mentünk el pl. egy billing címet, hogy az elvész az :addresses tömb nevű fekete lyukban (van értelme amúgy a dupla false-nak is, csak abból nem billing meg shipping címek lesznek, hanem csak címek). Azaz, mentéskor a billing_address-en keresztül mentünk, de a mentés után a billing_address pont ugyanolyan nil lesz, mint előtte volt vala.

Azért ezzel is sikerült egy jó órát szívni…

I started to understand how [Redis] is working and how can I use it in my projects. In my current project I collect some informations with background jobs, and store these informations in Redis. I choosen this way because these data should not be really persistent (that’s why I not decided to use MySQL as storage) because it can be collected quickly again if vanishes (it collected periodically) but I would like to access it quickly.

Redis has a beautiful interface to handle data. However, I usually like if the data storing logic is separated from my business logic. After some thinking I decided to store object in a easiest way I can: I store them in a “smart” hash. Basically, all hashes are key-value store, and Redis is a key-value store too. So, I extended ruby’s Hash class, and overriden some methods…

Már régóta keresek egy olyan IDE-t, ami képes nem csak projektszinten kezelni és szintaxis-kiemelést adni a Ruby/Rails projektjeimnek, de magát a nyelvet is “beszéli”, vagyis van például kódkiegészítés, refaktorálás, figyelmeztetések, etc, etc. Az általam eddig ismert legkomolyabb IDE, a NetBeans is csak elég alapszinten beszélte a Ruby nyelvet - aztán ki is vették belőle a támogatást, jelenleg a plugin folyamatosan haláltusáját vívja, 7.2-höz már meg sem jelent semmiféle verzió.

Egy StackOverflow böngészés során akadtam rá a JetBrains RubyMine nevű IDE-jére. Saját bevallásuk szerint az eszköz képes nyelvi szinten is kezelni a Ruby-t, illetve támogatja az összes nagyobb teszkörnyezetet. Mivel amúgy is épp indítottam egy projektet, úgy gondoltam, adok neki egy esélyt, hát legfeljebb letörlöm, és folytatom az eddigi módon, TextMate és Vim párossal. Szerencsére csalódtam. Pozitívan. Hatalmasat.

A RubyMine ugyanis nem csak egyszerűen jó, hanem - amennyire tudom - a maga nemében jelenleg páratlan a piacon azzal, hogy tényleg hozza azt, amit ígér, vagyis teljes mértékben támogatja a Ruby nyelvet és a Rails keretrendszert, sőt, még ennél is tovább megy, beépített támogatása van a lokalizációk kezeléséhez, grafikusan mutatja, hogy mely mdoeljeink vannak adatbázisban, képes a Rails projekt szerkezetét Rails-aspektusú nézetben mutatni (ahol nem mappák és fájlok vannak, hanem kategóriák, pl. Controllers, Models, Helpers), a kontrollerek akcióihoz hozzá tudja rendelni a nézeteket, partialokat, a refaktor során pedig olyan mélységekbe is lemegy, amiről álmodni sem mertem soha - egy modell átnevezésekor képes a nézetekben is utánanézni az útvonal metódusoknak, és megfelelően átnevezni azokat!

Ezen felül csak úgy mellékesen, képes kezelni az RVM-et, támogatja a Bundlert, a Rails generátorokat, a Rake taszkokat, SCSS-t meg CoffeeScript-et, … meg ilyen kis semmiségeket is.

Az egyetlen probléma vele a kissé hiperaktív kódkiegészítése, ha leírok egy nyilat, rögtön ugrana rá, pedig én magamtól szoktam szóközt is ütni utána, de azzal meg elfogadom az első lehetőséget is egyben - ami általában rossz ötlet. Biztos le lehet valahogy beszélni róla, majd utánanézek (de ha valaki tudja a tuti megoldást, a komment doboz mindig nyitott az ilyesmikre :-) ), egyelőre még elviselem.

Jelenleg folyamatosan használom az épp aktív projektemhez, teljesen jól szolgál, bár még képességeinek csak szerény részét használom. Most egyelőre a 30 napos próbaidőszakban vagyunk (dicséretes, hogy ez alatt sem ugrál föl valami kis ablak indításkor, hogy még 22.45 nap van hátra, és mostazonnal vedd meg - ez rém undorító, ha tetszik, úgyis megveszem - főleg, mert lejár -, ha meg nem tetszik, akkor ez a kapacitálás csak ront a dolgon), ám azt gondolom, hogy a 66 euro a személyes licencért abszolút megéri.

Amit nem használok belőle (sem), az a Git integráció, nekem a git még mindig parancssoros dolgot jelent, egyszerűbb kiadni a git co feature-awesome-stuff parancsot, mint GUI-ban kikattintgatni. Legalábbis szerintem.

A JetBrains honlapját tallózgatva (ismét) ráakadtam a TeamCity nevű CI szerverre is, ezzel egyszer volt már egy futó kapcsolatom, de valamiért nem sikerült telepíteni, és a végén Jenkins lett belőle. Most ismét kapott tőlem egy lehetőséget, hogy elinduljon, és meggyőzzön. Ezúttal mindkettő sikerült is neki.

A TeamCity-ről azt érdemes tudni, hogy egy olyan Continous Integration szerver (továbbiakban CI szerver), melyet nagyon egyszerű kezelni, és nagyon jól áttekinthető felületet ad, még egy felületes szemlélő számára is (ezt muszáj volt elsütni :-) ).

A RubyMine fejlesztők blogján pedig találtam egy írást, mely borzasztóan felcsigázta a kíváncsiságomat. Azt merték ugyanis állítani, hogy TeamCity beépítetten képes kezelni a RSpec és a Cucumber tesztek kimenetét, arrol riportot készít, hibáról értesít. Plusz, a TeamCity beépítetten támogatja az XMPP alapú notifikációt, amit pl. a Jenkins csak pluginnel tud.

Sajnos a TeamCity egyik hiányossága, hogy ő viszont már csak korlátozott mértékben képes kezelni a Bundlert: képes felismerni a létét, és azon keresztül futtatni a rake taszkokat, de már pl. egy bundle install -t képtelen elengedni, azt kézzel kell egy külön Build Step-ben, viszonylag kacifántosan megoldani. Végül sikerült, de azért nem voltam felhőtlenül boldog. Viszont az első teszteredmények feledtették velem az ezen a téren történt csalódást, mert pontosan azt kaptam, amit elvártam: mindenféle külön konfiguráció nélkül jelenítete meg a Cucumber es RSpec tesztek eredményét, ráadásul egy egészen barátságos felületen.

Tényleg nem JetBrains reklámnak szánom ezt a postot, de azért annyira érződik mindkét terméken, hogy ezeket olyanok fejlesztik, akik láttak már közelről Rails projektet, meg RVM-et, meg ilyesmit… például a Jenkins Ruby pluginjénél nem volt ilyen érzésem.