Android “halála” is a post from: Pepusz.hu

Mondjuk a social connectivity és community is megér egy misét itt a blogon, mert igen érdekes világot élünk, viszont kis hazánkban sajnos ezekre a technológiákra bizonyos körökben még igen furcsán tekintenek.

Pl mikor egy marketinges ismerőssel beszélgettem aki egy ügynökségnél dolgozik és náluk az a legnagyobb social marketing, hogy csinálnak egy FB fan paget, akkor igen csak meglepődtem. Persze ez egy lépcsőnek jó, de sokkal találóbb amikor csinálnak rá egy alkalmazást, amiről az emberek azt sem tudják, hogy egy nagy büdös reklámot kapnak az arcukba.  Na ezt hívom én marketingnek és nem a fan pageket ami utána szanaszét spammel mindenféle idióta eventekkel.

Kicsit eltértem az eredeti témától, úgyhogy majd folyt köv.

Új WordPress, sok még vele a dolgom is a post from: Pepusz.hu

Passenger 3 Phusion Passenger 3, ami még egyszerűbbé teszi a rails appok deployolását akár apache vagy ngnix környezetben, touch tmp/restart.txt nélkül, végre.  Valamint ebben az új verzióban megtalálható egy standalon változat is, amivel kitudjuk váltani a mongrel/webrick környezetünk development területen. Amint komolyabban kipróbáltam, posztolok róla.

Garbage Collection és Ruby Heap Sajnos ezt még nem tudtam végignézni idő hiányában, viszont igen érdekesnek tűnik.

Video interjúk rails nagyágyúkkal

Google PageRank In Five Lines Of Ruby

Egykét link ami érdekes lehet is a post from: Pepusz.hu

Szóval a pepusz.hu blog újra éledt kicsit a tartalom változni fog, mivel már nem csak Railsről, hanem a Ruby szépségeiről is szót fogok ejteni, valamint minden olyan dologról amiről azt gondolom, hogy hasznos és érdekes lehet. Lehet ez jQuery, termék fejlesztés és egyéb munkával és szórakozással kapcsolatos dolog.

Mi történt az elmúlt időben:

• Rails 3.0 hamarosan megjelenik, közben voltak béták, RCk
• belevetettem magam a jQuery világába
• a projekteket átpakoltuk Amazon AWS alá
• Ruby 1.9

Ezek azok a dolgok amik a szabadúszó most már külsős életem részei, mivel októbertől a Nav N Go csapatát erősítem mint UI Developer.

Igyekszem legalább heti 1-2 posztot tolni, hogy növekedjen az internet.

Ahogy Plasztik Józsi mondaná: Függöny le

ReLoad is a post from: Pepusz.hu

budapest_rb

Budapest.rb Rails + Flash alapú technológiák is a post from: Pepusz.hu

Most a relációs adatbázisok rejtelmeiről nem akarok írni, hisz remélem egy kis alapja mindenkinek van. Annyit röviden, hogy ugye vannak kapcsolatok, egy-egy, egy-több, több-több kapcsolatok. Vannak kulcsok, ezeket egymással összeköthetjük és máris van egy relációs adatbázisunk.  

Railséknél minden ami adatbázis az ActiveRecord. A szabványos relációs adatbázisoknál vagy természetes illesztést csinálunk(megmondjuk melyik mező melyikkel egyenlő), vagy a private keyhez kapcsolunk egy foreign keyt. DHH szerint erre nincs szükségünk, mert ha railsnél csinálunk két táblát(movie, author), akkor elég megadnunk a review táblában a movie tábla id mezőjének nevét a következő formában (tábla név egyes számban)_id a példában movie_id. 

Egy-egy kapcsolat

Generáljunk két modellt (vagy adjuk hozzá a már meglévőkhöz a szükséges mezőket):

Movie(cim:string), Author(movie_id:integer, author_name:string)

migrate

Majd adjunk hozzá egy-két teszt értéket a táblákhoz.

Mivel még sem adatbázis oldalon nem mondtuk, hogy mi mihez csatlakozik, sem rails oldalon, ezért szükségünk lesz valamire amivel megmondjuk mi mihez csatlakozik.

Mindig van egy függőség az egyik tábla felöl, ez jelenleg a author tábla, tehát ebbe a modelbe kell beszúrnunk, azt hogy ez függ, a movie táblátol. Ezt a következő módon tudjuk csinálni: belongs_to :movie. Mivel, hogy egy-egy kapcsolatról beszélünk, ezért a movie táblának van egy “származéka” ezt a has_one :author sorral tudjuk érvényesíteni. 

Ennyi, meg is adtuk, hogy mi mihez hogyan, tehát már relációban vannak a tábláink. Most már csak az a kérdés, hogy kell ezeket használni? Teljesen szimpla pont szintaktikával letudjuk kezelni a dolgokat mind a két irányból.

Nézzük először a Movie tábla felöl.

m = Movie.find :first
 
#kérdezzük le hozzá az author nevét
 
m.author.author_name
 
#Másik oldalról
 
a = Author.find :first
 
a.movie.cim 
 
a.movie = m #kapcsolat létrehozása
 
a.build_movie(:cim=>”Star wars”) #kacsolat létrehozása egy új film hozzáadásaával
 
a.save #buildnél mindíg kell save
 
a.create_movie(:cim=>”Star wars”)  #ilyenkor automatikus save van.

Egy-több, több-több kapcsolat

Ugye itt van egy szülő és ennek sok gyereke lehet, létrehozásnál egy különbség van, hogy a szülőnl a has_one, helyett has_manyt kell használni. pl has_many :reviews.

Itt is ugyanúgy működik a pont szintaktika, csak ne felejtsük el, hogy ha a szülőtől indítjuk, akkor ugye egy collectionként kell kezelni a lekérdezés eredményét, az az m.reviews egy object tömböt fog visszaadni, még akkor is ha ez a tömb egy elemű, tehát ha én kérném a m.reviews.id-t akkor itt egy object_idt fogok kapni. Tehát ehhez vagy meg kell adni konkrétan az elem elhelyezkedését, vagy egy cikluson kell végig futtatni az egészet.

Több-több kapcsolatnál ugye van egy join táblánk ezt létre kell hozni, a megfelelő külső kulcsokkal és ugye ebben két függőség lesz a két szülő fele. A szülőknél pedig meg kell adni, hogy has_and_belongs_to_many :egyik, has_and_belongs_to_many :másik.

Egykét varázsszó ami még hasznos lehet:

has_many :join
 
has_many :valami, :though => :join
 
has_many :valami, :dependent => :destroy     #destoynál a gyerek elem ide tartozó részeit is törli
 
has_many :valami, :dependent => :delete       #gyorsabb a destroynál, de elveszítjük a filterek rugalmasságát
 
has_many :valami, :dependent => :nullify         #”bontja a kapcsolatot”

Van itt még sok okosság, de úgy gondolom, hogy azokat már mindenki maga megtudja nézni, ha szükséges lesz nekik:

• egyedi asszociációk
• rekurzív kapcsolat
• named scopes

Comments

• 2009. január 10. szombat, tzs writes: Asszem akkor most letisztázhatom hogy melyik melyik. Mivel én PHpzom elég régóta, de nem vagyok az a klasszikus progmatekos kocka, ezért kicsit nehezebben esik le néha a tantusz. Leírnék pár példát hogy PHP esetében melyik Rails megoldás illeszkedhet a leginkább, hátha egyszerűbben megértem az ActiveRecordot. 1. SELECT * FROM tabla1, tabla2 WHERE tabla1.id=tabla2.id 2. SELECT * FROM tabla1 LEFT JOIN tabla2 ON tabla1.id=tabla2.id Tehát az első az 1:n a második az 1:1 kapcsolat rubyban?
• 2009. január 29. csütörtök, pepusz writes: Az első az egy természetes illesztés, a második egy join. Az 1:n az nem ettől lesz 1:n hanem hogy egy tabla1 beli adathoz tobb tabla2 beli tartozik. Azaz a tabla kettoben tobb olyan sor is lehet aminek a kulso kulcsa ugyanarra a tabla1 beli adatra mutat. 1:1nel pedig 1 tabla1 beli adathoz 1 tabla2beli adat tartozik.
• 2009. szeptember 25. péntek, cazatixow writes: cazatixow... lil wayne new tattoos ...
• 2010. február 02. kedd, DJ Tacee writes: Szia! Gratulálok az írásaidhoz, követem a blogod, én is most ismerkedem RoR-el. Majd belinkelem az első appjaim amint elkészültek.

Relációs adatbázis rails alatt. is a post from: Pepusz.hu

ui: Mielőtt bárki megjegyezné, hogy nem így szokás mondani, annak mondom, hogy tudom, csak ez ilyen hagyomány nálam.

Comments

• 2009. január 10. szombat, tzs writes: Bádog Karajcsont és túlélhető 2009et:D

Amit majdnem elfelejtettem is a post from: Pepusz.hu

Most ebben a postban a filterekről fogok beszélni.

 

A filterek lehetővé teszik számunkra, hogy elő- és utó- feldolgozást csináljunk. (ej de magyaros lett). Ezeket a filtereket használhatjuk authentikálásra, cachelésre, DRY-osításra, stb. A filterek effektíve hozzáférnek mindenhez, ami abban az osztályban elérhető. Van jó pár féle filter, viszont a használatuk hasnló.

Ezeket a filtereket ugye mindig az osztály deklaráció után kell megadni

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class BankController < ActionController::Base
 
  before_filter :audit
 
 
 
  private
 
    def audit
 
      # method description
 
    end
 
end

Ilyenkor a filter érvényes lesz minden egyes metódusra, ami az osztályban van. Ezt valahogy szűkítenünk kéne, erre van két varázs szó: only és except ezek egy-egy tömb, amikben felsoroljuk azokat a metódusokat amikre szeretnénk, hogy érvényesek legyen. Pl, ha csak az index metódusra szeretnénk, akkor nly=> :index, ha azt szeretnénk, hogy a :foo és a :bar ne legyen benne a filterben, akkor :except=>[:foo, :bar].

class BankController < ActionController::Base

    before_filter :audit,  nly=>:index

    before_filter :check, :except=>[:foo, :bar]

    def index

    end

     def foo

    end

   def bar

   end

    private

      def audit

        # method description

      end

       def	  check

        # method description

       end

  end

Nagy vonalakban ennyi, persze nem csak before_filter van, hanem after_filter, prepend_before_filter, prepend_after_filter, around_filter, skip… stb.

Comments

• 2009. január 10. szombat, tzs writes: VISSZATÉÉÉÉRT:D

Filterek is a post from: Pepusz.hu

Bővebben, lackac.hu

Most láttam a levlistán, eme csodás hírt. Én még nem tudom, hogy el tudok-e menni, de igyekszem.

Comments

• 2008. szeptember 07. vasárnap, Lacus writes: Helyesen: el tudok-e menni valamint: eléggé elfoglalt vagyok
• 2008. szeptember 08. hétfő, pepusz writes: köszi
• 2008. szeptember 18. csütörtök, LacKac writes: Jó, hogy eljöttél. :)
• 2008. szeptember 18. csütörtök, pepusz writes: Jó volt ott lenni. ;)

Meetup is a post from: Pepusz.hu

Addig is mindenkinek minden jót.

Comments

• 2008. október 07. kedd, tzs writes: arra mindenképp kivávcsi vagyok, hogy kezeli ruby a relációs táblákat.
• 2008. október 07. kedd, pepusz writes: most már tényleg hamarosan elkészül, hétvégére ígérem.
• 2008. november 05. szerda, tzs writes: melyik hétvégére?:D
• 2008. november 05. szerda, pepusz writes: :S :D
• 2008. december 17. szerda, tzs writes: no akkor most végleg elfogyott a lendület?
• 2008. december 17. szerda, pepusz writes: A lendület nem fogyott el, csak az idő. Bízom benne, hogy most a téli szünetben tudok írni egykét postot.
• 2008. december 17. szerda, tzs writes: ok addig végigcsinálom a példákat:)

Sry is a post from: Pepusz.hu