Feeds:
Bejegyzések
Hozzászólások

Készítettem egy plugin-t (gem-ként is használható) ami a formtastic plugint használja és jQuery alapú in-place editort valósít meg. Jintastic néven fut.

Itt lehet csekkolni: http://github.com/rubymood/jintastic/tree/master

Leírásban megtalálható hogy milyen módokon lehet használni vmint hogy miért érdemes használni. Minden esetre a jelenleg elérhető megoldásoknál szerintem mind jobb. :) De ha vki szerint van jobb megvalósítás in-place editorra, ami könnyebben használható, mégbarátságosabb etcetera etcetera az jelezze.

Függőségek kezelése

Sok fajta van az életben, sokunk rabja is párnak, de mivel ez egy fejlesztői blog, ezért most kód függőségről lesz szó, azaz hogyan függjön a projektünk egy plugintól/modultól/stb. Folytatás az előző post kiegészítéseként.

Submodult megismertük hogy nem para. Legalábbis a legtöbb esetben bőven megteszi. De mi van akkor ha változtatni akarunk egy submodul pluginen? Ez akkor probléma ha nincs jogunk  felpusholni a változtatást, ugyanis ha a változtatásunkat bekommitáljuk a projektünkbe azután ha vki kicheckoutolja akkor a submodulunk commit id-je egy nem létező idre fog mutatni, ergo baj lesz. Submodulról azt kell tudni hogy ez a legegyszerűbb választás a mindennapi használathoz (mindemellett fontos betartani néhány alapszabályt, különben probléma lehet: pl kicheckoutnál submodule update használata, vagy épp submodul patchnél projektünk pusholása elött submodul pusholása). Viszont ha a fenti eset felmerülhet, érdemes elgondolkodni más alternatíván.

Braid

Tegyük fel patchelnünk kell egy használt plugint. Ha nem akarjuk megvárni amíg a patchünk bekerül a plugin repójába, vagy nem akarunk ilyenkor mindig forkokat a patchelendő pluginjeinkhez, használjuk a braid-et. Projetünkbe beépül a braides plugin. Rails pluginként való telepítéshez segítő opció van. Lehet patchelésünk után updatelni nyugodtan plugin repójából. Viszont ha pl saját pluginünket használjuk (azaz a miénk a remote repoja), és szeretnék a projektünkből a patchelt pluginunkat feltölteni a plugin repojába azt nem tudja (elvileg 0.6tól fogja tudni).

Subtree merge strategy

Hasonló a braidhez, annyiban különbözik hogy alap beépített git parancsokkal operál. Viszont ezek túl bonyolúltak. Ellenben vannak hozzá sake taskok amik megkönnyítik a használatát.

Giternal

Akiknek a pluginjeikhez hasonló kényelmes funkcionalitás szükséges (update, push) mint a projektjükhöz, azoknak ez ajánlott. Ezzel lehetőség van a braidnél említett patchelt plugin könnyű felpusholására a saját repójába.

Resources:

Ez csak egy rövid összefoglaló volt a git kapcsán felmerülő lehetőségekről függőség kezelése kapcsán. Igazából a mindennapi használatban derül ki egyik-másik jobb/rosszabb tulajdonsága. Pl ha normálisan fejlesztenénk, azaz lenne egy master és egy development branchünk kapásból és egy új funkciót akarnánk ami egy plugint használna és azt submodulként akarnánk betenni azt jó tudni, hogy nem az adott branchez hanem a superprojekthez adja. Így ha átváltunk master branchre de még nem akarjuk betenni repoba egy új commitnál mert még fejlesztés alatt az új funkció akkor tehetjük pl ignorra a submodul mappáját.

Git submodule

Submodul, jó? Nem jó?

Miután felmerült a submodule gondolata elbizonytalanodtam benne, hogy nem e rossz megoldás, mert pl mivan ha pont mikor deployozunk aközben volt frissítés submodulunkon és akkor a git submodule update hatására hiba lehet production környezetben. Nos aki ilyenre gondolt az feleslegesen paráztatta magát, mert ugyan itt is felmerült ez a para de egy szép példával megnyugtatnak mindenkit. (Aki hamarabb akarja tudni a választ annak pedig elárulom hogy ha submodult adunk projektünkhöz akkor a legközelebbi commitunkal a submodul kicheckoutolt commitját küldjük el, és a történethez az még hozzátartozik, hogy ha inicializáljuk a projektünket és aztán mondjuk git submodule update --init akkor azt a commitot fogja kicheckoutolni submodul repóból amivel bekerült projektünkbe. )
(másik hasznos leírás submodulról: http://woss.name/2008/04/09/using-git-submodules-to-track-vendorrails/ )

Gem vs submodul

A fentiekben megismert megnyugtató tudás birtokában viszont el lehet gondolkodni a projektünkhöz szükséges gem-ek submodulként való alkalmazásán. Ugyanis ha a rails config-ban nem pontosan adjuk meg a gem dependency-t, azaz version-nek nem adunk meg semmit, vagy épp felgmán :version=>”>=2.1.0″ adunk meg akkor lehet a production szerveren frissítik a gem-et (mert épp vkinek a legújabb változat szükséges) míg te a saját gépeden nem és lehet azzal már nem lesz kompatibilis az alkalmazásod egy új deploy után mikor újraindul szerver. Persze ha pontosan adjuk meg a versiont minden gemünknél akkor nincs ez a probléma. De pozitív a submodulban hogy nem kell nyaggatni a szerver tulajt hogy ugyan tegye már fel ezt meg azt a gem-et, hanem minta ügyfelek lehetünk akikkel sosincs gond. :)

Capistrano submodulal

Eddig ok. Mit kell tenni hogy ez a valóságban is működjön. Pl capistranonál meg kell adni a következőket

set :git_enable_submodules, 1
ssh_options[:forward_agent] = true

Ezzel engedve van a submodulok automatikus kicheckoutolása minden deploynál. (Ne felejtsük: csak akkor szedi update le a legújabbat ha a projektünkben frissítettük a submodult)

Capistrano beágyazott submodulal

Nade mi van akkor, ha a submodulban submodult használnak? :) Amolyan félelem és reszketésesen azt is kérdezhetnénk: Mennyi a majom?? Ehhez felejtsük el amit a fenti bekezdésben írtam és menjünk biztosra:

require 'capistrano/deepmodules'; set :deploy_via, :remote_cache

Ennyi. Ehhez viszont szükséges ez. (leírás itt)

Egyéb:

  • ssh kapcsolatnál ne felejtsük el megadni github-nak a production szerveren lévő publikus kulcsunkat is.
  • capistrano nem törli a már nem használt submodulokat (leírás, megoldási tip itt)

Rails.root változás

Az új 2.3.0 változatban megváltozott a Rails.root működése. Eddig sztringként tért vissza, most viszont Pathname-ként. Az útóbbival csak annyi a probléma hogy felülírja a + metódust, így nem sztring konkatenálást végez hanem útvonalakhoz méltón eléggé figyel a relatív és abszolút útvonalakra. Pl ha a Rails.root+”/public” parancsot adjuk ki, akkor 2.2.2 változatnál még helyesen összefűzi a két útvonalat, 2.3.0-nál viszont /public lesz az eredmény. Szerintem ez sok helyen okozhat problémát. Az első pluginnál amit 2.3.0 alatt használtam rögtön belefutottam ebbe. Kicsit debuggolni kellett mi a baja. :)

Mivel a Rails.root+”public” csak az új változattal jó, köztes megoldás lehet pl a “#{Rails.root}/public”

Mint arról már beszámoltam, be lett újítva egy laptop. Most pár apró dologgal egészíteném ki azt a bejegyzést.

Vincseszter kattogás

A kattogási parára való megoldás nem teljesen működött úgy ahogy szerettem volna. Felfüggesztésből való  újraindításnál megint kattogott, valamint a vincseszter hőmérséklete is emelkedett a megoldás alkalmazásakor 36-38 fokról 46-47 fokra. Olvastam hogy a melegedést a 64 bites változat megoldotta egyeseknél. Nosza, fel is tettem a 32 bites mellé. Sajnos a melegedés továbbra is fennállt, viszont alapba nem kattogott a vincseszter. Viszont felfüggesztés esetén vagy már felhasználó váltásnál is újra kezdte, és ezt a “jó” szokását már újraindítás után is megtartotta. No ekkor már jobban utánanéztem ennek az egésznek. És végül találtam egy egyszerű megoldást: /etc/default/acpi-support file-ban a ENABLE_LAPTOP_MODE értékét false-ról állítsuk true-ra. Ez végeredményben a hdparm -B 254 /dev/sda trükköt alkalmazza. De aki jobban utána akarna nézni a dolgoknak:
http://www.samwel.tk/laptop_mode/
https://wiki.ubuntu.com/PowerManagement
A melegedés miatt amúgy nem kell parázni, 60 fokig működő képes a laptophoz adott vincseszter.

Dual boot

Mint fentebb említettem most kép oprendszer van a gépen. Filóztam rajta hogy legyen megoldva ahome partíció kezelése. A meglévőt használja az új rendszer is vagy külön legyen neki is. Mivel a 64 bites változatnál kapásból más fajta flashplayer plugin szükséges a böngészőkhöz, ezért inkább a külön partíció mellett döntöttem. Viszont hogy a pidgin azonos helyre archíváljon vagy épp a thunderbird azonos helyen menedzselje a leveleket a 64 bites változatnál felmountoltam a 32 bites home partícióját (ehhez ugye az kellett hogy mikor először telepítjük az ubuntut a home-ot külön helyre csatoljuk), majd a 64 bites változatnál symlink-eket hoztam létre a meglévő 32 bites változatnál lévő helyükre. Így egész kényelmes. :)
Monutoláshoz létrehoztam az mnt mappában egy ubuntu8.10-32bit nevezetű mappát majd az /etc/fstab-hoz hozzáadtam a következő sort:
/dev/sda6    /mnt/ubuntu8.10-32bit    ext3    relatime,errors=remount-ro 0    2
(nálam sd6-nál található a 32 bites változat home partíciója, másnál lehet hogy máshol van, megtalálásában segítség lehet: sudo fdisk -l) Linux guruk, írjátok meg ha a fenti megoldást egyszerűbben is meg lehet oldani.

Egyéb változások 64 bites ubuntuval

  • a Cib bankos para megoldódott az icedtea6-plugin csomag telepítésével.
  • felfüggesztés után nincs hang
  • hibernálás után az usb-s cuccok nem működnek

A hibák olyanok, amik lehet utánajárással valószínűleg megoldhatóak lennének, de nem zavarnak annyira. A felfüggesztés pl nekem elég ahogy most működik.

Ami még hasznos lehet..

az a partimage nevezetű csomag. Ha már van egy jól beállított rendszerünk, és nem szeretnénk ha vmi belerondítana, ezzel a programmal könnyedén – akár tömörítve – is lementhetjük majd ugyanilyen könnyedén visszaállíthatjuk partíciónkat. (csak annyi szükséges hogy amit archiválunk az a partíció ne legyen felmountolva)

Előzmény

A héten sikerült beszereznem életem első laptopját egy Dell Inspiron 1525 “személyében”. Két fajtán gondolkodtam, vagy Dell vagy Macbook. Szívni nem igen akartam operációs rendszer miatt, viszont mivel a Dell ezen típusa külföldön már alapba Ubuntu rendszerrel is vásárolható, így úgy gondoltam nem lesz nagy kockázat ez a típus. Nos elöljáróban annyi, hogy nem tévedtem.:)

Pro

  • http://mysoft.hu oldalon rendelve már a rendelés napján át tudtam venni. Barátságos kiszolgálás, segítőkészség, 4 év gari (mint máshol). Ha a videókártyát nem nézzük akkor hasonló hardware mac-ből 130 ezerrel drágább.
  • most mondhatnám hogy egyszerűen minden megy kapásból de azért felsorolok pár dolgot amikkel amúgy gond szokott lenni: touch pad, felfüggesztés, fényerő szabályozó, hangerő szabályozó, webcam, lehajtva nem kapcsol ki monitor stb. (bluetooth eszközöm nincs, wifi-m se, de látja a közeli helyeket) Nos, ezek mind mennek, sőőt.
  • új dolgok is működnek amik előző Ubuntu változatnál nem: egeremen van két gomb amin előre/hátra nyílas gomb van. Ezekkel firefoxban tudtam windows alatt adott fülön historyban lépkedni. Ez is jó most.

Kontra

  • új ubuntuval nem tudok felmenni cib bankra (vmi java bug)
  • hibernálás után nem áll fel a hálózat
  • fényesség változtató gyorsbillentyűknél egy gombnyomásra van hogy 3 értéket is ugrik

Egyéb

Az, hogy előző gépem (2 gigás celeron, 512 mega ram) után most szédítő a sebesség (2,16 core duo, 2 giga ram) az alap. Php, ruby mind könnyedén feltelepült. Viszont ami még érdekes lehet:

  • thunderbird-ben gmail-es fiók
  • levél érkezés értesítő thunderbird-höz
  • alapba 8.10-ben már van nautilusban iso mountolási lehetőség, viszont ez még nem a legjobb, helyette gui-s mountoló: gmountiso
  • torrentezéshez ajánlom a vuze-t (azureus folytatása). nagyon profi a legújabb verzió.
  • total commanderes file kezelés: krusader (csomagkezelőből leszedhető, viszont ott a legújabb béta változat van ami csinált már furcsaságot :) )
  • 6 cellás aku kb 140 percig bírta
  • random mód elugrik a kurzor gépelés közben az egér által mutatott helyre. oka: touchpad érzékenységéből adódik hogy gépelés közben néha úgy érzékel mintha rányomnánk. megoldás: rendszer->beállítások->egér->érintőtábla fül->’egérkattintás engedélyezése az érintőtáblával’-t kilőni. Voilá!
  • laptopon található egy Media Direct nevezetű gomb, ami windows-hoz lett kitalálva. célja hogy win betöltődése nélkül lehessen filmeket nézni. ezzel nem is lenne gond ha linux partíciónk nem lenne, ekkor ugyanis megnyomása után elcsesz mindent és csak a windows partícióját lehet visszahozni. állítólag meg lehet oldalni hogy pl bekapcsoló gombra a windows, erre a gombra meg pl az ubuntu induljon el de ehelyett inkább a leszedése mellett voksoltam. megoldás: le kell gyalulni az egész vincsesztert (úgy el van dugva ez a kis progi hogy a partíció kezelő programok se látják) tehát érdemes gparted-el bootolni és ezzel a procedúrával indítani dell-es pályafutásunkat. gyaluláshoz:
    dd if=/dev/zero of=/dev/sda bs=4k
  • vincseszter gyakran csinálta, hogy kattant egyet, mintha 5 másodpercenként kiírna cache-ből vinyóra. mint kiderült 5 nap alatt 6000-szer csinálta. nos megvan rá a megoldás: íme (az itt említett smartctl parancs a smartmontools csomagban található)
  • van egy fényerő szabályozó progi, de azzal hiába állítottam be bármit, mindig 100%-ra ugrott brighntess ubi betöltődésekor (BIOS sem érdekelte). megoldás: beállítások->energiagazdálkodás->képernyő fényerejének beállítása. ezt már megjegyzi :)

Konklúzió

Egész egyszerűen nagyon meg vagyok elégedve ezzel a párosítással. Szerintem akik mac mellett filóznak azoknak érdemes lehet elgondolkodni egy költséghatékonyabb és ugyan úgy működő megoldás mellett.

Tervek

Jelenleg őszi elhavazódásban leledzek, így post dömping ideiglenesen szünetel. Viszont szeretném felhívni a figyelmet október 11-ére, amikor is a Merb 1.0 fog megjelenni (előre láthatólag). Szerintem érdemes lehet foglalkozni vele, ha másért nem már csak azért is, mert aki kimaradt a Rails felfutásából az a merb-el most megismerkedve ott lehet a Rubys élbojban.

Viszont a címre utalva: tervezem egy több bejegyzésből álló sorozat elindítását egy új projektem kapcsán felmerülő kérdések köré szervezve. Az alábbi témakörök várhatóak:

  • kód editor (vim)
  • Ruby elmélyülés (osztályok, modulok, mix-inek, metaprogramozás világában)
  • Git (github)
  • BDD (Rspec, autotest)
  • Merb (de lehet végén Rails lesz :) )
  • Projekt fejelsztése kapcsán felmerülő témák

Ezek a témakörök nem azt jelentik, hogy ezekben fullosan otthon vagyok. Kiválasztásukban sokkal inkább a kiváncsiság és a megismerés vágya játszik szerepet (persze többekhez volt már ilyen-olyan szerencsém). Hozzá kell még tennem, hogy mindamellett, hogy ezt a kronológiai sorrendet fogom követni, az előbbiekből következik, hogy a fejlesztés egy előrehaladottabb állapotában bizonyára lesz majd olyan felfedezésem, amely a felsorolt témakörök egyikéhez tartozik. Mivel nem akarok nagy keszekuszaságot, ezért a fejlesztés előtt lévő átfogó témakör bejegyzéseimet fogom updatelni, de erről az új bejegyzésekben jelezni fogok, ami lehet abban fog kimerülni hogy simán belinkelem az adott témakört kifejtő bejegyzésemet, ami már a bővített változatot fogja tartalmazni.

Gondolkodtam rajta hogy mennyire érdemes úgy írnom a magyarországi első ruby-s találkozóról, hogy kb 10 napja egy látógatója se volt a blogomnak, de mivel ez történelmi nap lesz, így illik megemlíteni.
Szóval 2008 szemptember 17-én budapest.rb este 7-kor a KÉK-ben.

Filóztam rajta – mivel már voltam ilyen meetup félén -, hogy mennyire jó ötlet ruby témakörben ez a meetup-os személelet, azaz gyors, pörgős előadások tartása. Gondolok itt arra a sok emberre, akiknek nem sok közük lehet még a ruby-hoz, vagy rails-hez, viszont kiváncsiak és eljönnek. Nos nekik hiába mutat az ember pár dolgot, ami a ruby-s fejlesztők dolgát megkönnyíti, nem fogják tudni értékelni, másrészről meg nem lehet a ruby-ról 5 perces előadást tartani. Végülis ez nem csak nekem juthatott eszembe, mivel lesz egy hosszabb előadás is szerencsére és ezt a későbbiekre is tervezik.

Szóval lehet vmi elkezdődik végre itthon is.

Rails console

A Rails egy igen fontos játszóteréről ejtenék pár szót, és ez nem más mint a console. Hogy mi ez, hogy indítsuk el és hasonló alapokról nem ejtenék most szót, inkább tippeket, ötleteket adnék a célból, hogy ez a hasznos eszköz megkönnyítse a dolgunkat Rails-es projektjeink esetén.
Azért azt talán fontos megjegyezni, hogy amit a console-ban teszünk azt az aktuális környezetben tesszük. (ez ugye legtöbbször a development) Ez azt jelenti hogy ha éppenséggel az adatbázisunk rekordjaival babrálunk, és módosítunk rajtuk, az bizony save esetén ténylegesen elmentődik. Hogy ezt elkerüljük, indítsuk a console-t a -s kapcsolóval (s mint sandbox).

Console-unk egyéni beállítására lehetőségünk van a home-unkban található .irbrc file szerkesztésével (windows esetén). Mivel ez a file egy ruby szkript file, így lényegében ruby kódot fogunk beleírni. Fontosabb konfigurációs lehetőségek:


#kódbehúzás
IRB.conf[:AUTO_INDENT] = true

#history elmentése
require 'irb/ext/save-history'
IRB.conf[:SAVE_HISTORY] = 100
IRB.conf[:HISTORY_FILE] = "#{ENV['HOME']}/.irb-save-history"

Bármilyen egyéb hasznos kód console-ban való újrafelhasználásához érdemes elmenteni őket az .irbrc file-ba.

Számomra hasznos segítségek


#lenti metódust meghívva kiírja a projektünkben létrehozott named route-okhoz tartozó információkat (milyen HTTP kérést "generál", milyen url mintára illeszkedik, valamint azt, hogy melyik controller melyik action-ja hívódik meg általa</pre>
def named_routes
  ActionController::Routing::Routes.named_routes.each {|name, r| printf("%-40s %s\n", name, r) }; nil
end

#hasonló a fentihez, viszont itt az összes rout megtalálható és nincsenek nevesítve
def routes
  puts ActionController::Routing::Routes.routes
end

#irb betöltése után fut le
IRB.conf[:IRB_RC] = Proc.new do
  #lenti kód hatására a console ablakunkba kerül a log kimenete
  #igen hasznos, így pl rögtön láthatjuk milyen sql futott le a háttérben
  ActiveRecord::Base.logger = Logger.new(STDOUT)
  ActiveRecord::Base.instance_eval { alias :[] :find }
end

#prompt helyén látható az adott projekt neve
rails_root = File.basename(Dir.pwd)
  IRB.conf[:PROMPT] ||= {}
  IRB.conf[:PROMPT][:RAILS] = {
    :P ROMPT_I => "#{rails_root}> ",
    :P ROMPT_S => "#{rails_root}* ",
    :P ROMPT_C => "#{rails_root}? ",
    :RETURN   => "=> %s\n"
  }
IRB.conf[:PROMPT_MODE] = :RAILS

#kiírja egy objektum vagy osztály saját metódusait ha meghívjuk rajta az own_methods metódust
class Object
  def own_methods
    own_methods = self.methods - self.class.superclass.methods
    own_methods.sort.each{|n| printf("%s\n", n)}
    self.class.to_s + " object has " + own_methods.size.to_s + " methods"
  end
end

#ri kimenete a konzolban lesz.
#Használata: ri 'String.reverse' vagy ha nem tudjuk melyik
#osztályban található a metódus csak simán írjuk be: ri :strftime
def ri(*names)
  system(%{ri #{names.map {|name| name.to_s}.join(" ")}})
end

Egy általános, a fenti kódokat tartalmazó .irbrc megtalálható itt. Ebben látható, hogy a Rails specifikus beállítások csak akkor futnak le ha Rails console-ját indítjuk.

Egyéb trükkök a végére

Dupla tab billentyű leütésével lehetőségünk van metódusokat/osztályokat kiegészíteni. Olyan mint a shell-ben a mappa és file kiegészítés tabra.

Törlés: clear vagy ctrl+shift+l

Console-unkban használhatjuk az app változót. Ez az ApplicationController::Integration::Session-nak felel meg.
Ilyeneket csinálhatunk vele:
>> app.get ‘/hello/world’
=> 200
>> app.response.headers
=> {”Status”=>”200 OK”, “type”=>”text/html; charset=utf-8″,
“cookie”=>[], “Cache-Control”=>”no-cache”,
“Content-Length”=>13}
>> app.response.body
=> “Hello, world!”

>> app.person_path(1)
=> “/people/1″
>> app.person_path(:id => 1)
=> “/people/1″
>> app.person_path(:id => 1, :section => ‘enrollment’)
=> “/people/1?section=enrollment”

>> app.formatted_person_path(1, :js)
=> “/people/1.js”
>> app.formatted_person_path(1, :x ml)
=> “/people/1.xml”
>> app.formatted_people_path(:rss)
=> “/people.rss”

>> app.search_people_path(:query => ‘Brian’)
=> “/people/search?query=Brian”

>> app.get app.search_people_path(:query => ‘Brian’)
=> 200
>> app.request.request_uri
=> “/people/search?query=Brian”
>> app.request.params
=> {”query”=>["Brian"]}

>> app.post ‘/account/login’, { :username => ‘defunkt’, :password => ‘razzletaz’ }
=> 200
>> app.cookies
=> {”_session_id”=>”9d1c014f42881524ff6cb81fb5b594bc”}

Igen hasznos tud lenni y (mint to_yaml) parancs.
y User.find(1) == puts User.find(1).to_yaml

Létrehozhatunk új session-öket az irb parancsal. Ha azt akarjuk hogy pl a User modell scope-ját használjuk az új session-ben: irb User
Ezután a find(1) automatikusan a User modell find metódusát indítja el.

Session-ök listája: jobs
Session-ök közti váltás: fg 0, fg 1, stb

A kedvenc trükköm pedig így a végén, a projekt specifikus beállítások. Nemrég ismerkedtem meg a REXML-el. Namost ahhoz, hogy eljussak pl egy adott xml node kereséséhez ezen a procedurán kellett mindig végigmennem:


require 'rexml/document'
u=User.find(1)
xml=REXML::Document.new u.folder_tree
node=REXML::XPath.first(xml, "//*[@id=1]")

Ahelyett hogy ezt mindig begépeljem, más projektnél meg esetleg más kezdő parancsokat, a következőt csináltam az .irbrc file-ba:


IRB.conf[:IRB_RC] = Proc.new do
  case File.basename(Dir.pwd)
    when "projekt_neve"
      require 'rexml/document'
      @u=User.find(1)
      @xml=REXML::Document.new @u.folder_tree
      @node=REXML::XPath.first(@xml, "//*[@id=1]")
    when "projekt_neve2"
  end
end

Pontosan 4 hónap 7 napja történt, amikoris levelet írtam egy barátomnak. És mielőtt még ténylegesen belevetném magam a cikkek írásába, azt a levelet még bepréselem ide:

azt hiszem most lettem végképp szerelmes a ruby-ba.

volt egy példa, aminél egy tömb elemeit egy adott feltétel szerint leválogatták, és utána a leválogatott elemek szummáját vették:
my_array.find_all{|item| item % 3 == 0 }.inject(0){|sum,item| sum + item }

nézegettem hogy milyen szép is ez aztán hogy haha, mennyivel bonyolultabb ezt megoldani php-ban. aztán filóztam és rájöttem hogy nem.
php-ban kb így nézne ki:

$sum=0;
foreach($my_array as $item) {
   if ($item%3==0) {
       $sum+=$item;
   }
}
print $sum;

ami zavart az az, hogy rubynál kétszer megyünk végig a tömbön (egyszer az egészen, utána a leválogatotton)
elkezdtem filózni hogy hogyan lehetne szebben megoldani ruby-ban.
azt találtam ki hogy egy olyan szummázó metódust írok, ami egy adott feltétel teljesülésekor szummázza a többihez a tömb adott elemét.
és most jön a lényeg, hogy ez milyen szép ruby-ban. ugyanis az alap típusokat kezelő osztályok is nyitottak, így bármikor módosíthatod vagy bővítheted őket. nincs más hátra mint csinálni egy plusz metódust az Array class-ba ami egy kapott kód blokkot ( { és } határolt kód) használ fel a szummázó feltételben.

class Array
   def sumexp
       sum=0
       each {|x| if (yield x) then sum+=x end}
       sum
   end
end

használata pedig:  [1,2,3,4,5,6].sumexp {|x| x%3==0 }

hát nem gyönyörű?!

(azon filózok hogy kellene egy ruby-val foglalkozó blogot írnom, kezdő bejegyzés pedig lehetne ez )

Hát emígyen történt…

Older Posts »