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

Egy átlagos nap

Tegnap egy átlagos fejlesztői nap volt, teli kihívásokkal. Még tegnap előtt este kezdődött amikor a lighthouson a formázó helper linkre hiba oldal jött be. Nade tegnap reggel belevgátam magam.

Reggel már működött a formázó helper így kezdtem a napot egy rails-es hiba bemutatásával. Persze nem úgy jelent meg a kódom ahogy szerettem volna, összecsúszott az egész.

Aztán elkezdtem egy ajaxos regisztrációs felület megvalósítását. A design tervhez leginkább a fancybox hasonlított, így amellett döntöttem. Neki is fogtam a testreszabásához. Kezdve ott hogy fix szélességgel magassággal dolgozik. Ez elvileg customizálható de nekem arra egy nagy semmi jelent meg ha én adtam meg értékeket. Na mondom mi? Megadtam erre csak a szélességet, erre akkor meg egy vertikális vonal jelent meg. Na elkezdtem debuggolni. Egyrészt magasság nem adható meg %ban mert hosszácsapja kódban a ‘px’-et, szélességnél meg kiderült hogy string megadással bugos így integer lett belőle. Kis okoskodás még a bezáró X-el. Nézni miért mozgatja scrollázáskor a boxot. Ezt is elkezdtem debuggolni de nem találtam meg hol csinálja. Na erre látom ez is inicializálásnál beállítható. Így már könnyebb volt megnézni hogy amúgy ezt hol kezeli kódban, csakhogy ott próbáltam console.log-os megoldást de nekem nem jelezett semmit firebug. De úgy látszik akkor mégse próbáltam ott. Na fancybox testreszabva, jöhet bele a tartalom generálás.

Csakhogy a tesztszöveg után amikor már render-t használtam volna nem jelent meg benne semmi. Hibát meg nem jelzett hogy nem találja a renderelendő filet. Na ezt is debug. Az erb-el parsolt js fileban lenne egy renderelés és vmiért nem jó. Ha ugyanazt a renderelést controllerből csináltam úgy belekerült. Gondoltam hogy valószínüleg ott lehet baj hogy egy js fileból egy haml file-t rendereltetek, de azért nem hiszem hogy tényleg emiatt lenne bibi, merthogy a vicc az, hogy ha megváltoztattam az amúgy controllernél működő renderelést partial-ös renderelésre akkor már ment js fileból is, ja és a partial ugyancsak haml file. (amúgy render :action=>:new volt ami nem ment jsből) * update

Na végre lehet regisztrálni, bár ekkor minden féle hibaüzenet jelent meg ha nem adtam meg semmit. Ezek az autentikáláshoz használt authlogic alap beállításai. Nekem ebből csak egy nem kellett de azt elég tricky volt kiszedni (nevezetesen a login névre nem akartam karakter megkötéseket, erre ilyet kellett belőnőm: c.validates_format_of_login_field_options(:with=>//) Mertha azt adtam ennek hogy nil, vagy false vagy üres hash azokkal mind nem volt jó. Kilőni tehát nem lehetett csak így hogy megadtam neki egy ilyen teszt regexpet.

Na működik rendesen regisztrálás, aktiválhatjuk mostmár a levélben kapott linkel. Amit használok progit az egy kezdő appból lett építve, és abban már volt egy kész megoldás emailes aktiválásra. Csakhogy az még régebbi authlogical ment. Újnál jelzett hogy a create_session! az nem létezik. Gúgli. Kb semmi találat erre. Böngészés minden felé mások hogy aktiválnak authlogic-al. Hát nem sok ilyen van. Néztem authlogic kódját ott egy sima create_session van csak. Hát akkor legyen az. Úgy már ment. Hállelujja.

Ja nem hállelúja merthogy aktiválásnál lévő layoutot nem használja. Hiába adom meg layout függvénnyel semmi. Kell még mellé a rendereléshez a layout => true. Aztán ezt is kidebuggoltam, legalábbis rákerestem neten. A lényeg hogy hiába van másik helyen a view akkor is úgymond relatív útvonalat kell megadni, mert ha /-el kezdjük az útvonal megadást akkor azt már konkrét file-nak veszi és ott alapba ki van lőve a layout használata.

Na azért jó dolog is volt tegnap. Finom beacon szalonnával aládúcolt tepsis hús ebédre. Na az jó volt, meg utána egy pohár borocska. Ja meg láttam hogy van itthon ilyen nagy üvegben két literes borunk. Na az már rendes falusi adag. Annak a látványától is jó kedvem lett. :)

Update:
Közben arra jutottam hogy ez valószínűleg amiatt van mert helperből és view-ből csak partial renderelhető. Bár ez nincs elég jól dokumentálva.

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)

« Újabb bejegyzések - Older Posts »