Ruby Srbija

Novi Sad, 10. decembar 2011.

Mon, 19 Dec 2011 16:06:00 +0100

Novi skup je bio u Novom Sadu pod organizacijom Rendered Text-a. Obradovao nas je dobar odziv i to što je skoro polovina ljudi došla iz različitih gradova.

Posle uvodnog ćaskanja prešli smo na dvočasovni dojo gde su 4 grupe radile na zadatku - trebalo je isparsirati poslednje objavljenje gemove sa rubygems.org, ukrstiti one čiji je kod na GitHub-u, i sortirati ih po broju pratilaca koje autor gema ima. Ideja je da su novi gemovi zapaženih developera verovatno vredni pažnje.

Na kraju smo zajedno diskutovali šta je koja grupa uradila. Svi smo imali nešto drugačiji pristup - pisanju specova ili organizaciji koda, što je diskusiju učinilo veoma zanimljivom. Vreme je brzo prošlo tako da nam ostaje samo da uskoro ponovimo nešto slično.

Beograd, 25. jun 2011.

Thu, 30 Jun 2011 11:53:54 +0200

U organizaciji Jablana i Saleta, ovaj sastanak se zbio u komfornim prostorijama firme Vast. Na zadovoljstvo svih, posećenost je bila najveća do sada (13 ljudi), a recimo i da je Dalibor došao čak iz Skoplja.

Verovatno su zbog toga aktivnosti odstupile od predloženog rasporeda: glavne teme uvodnog razgovora su bila iskustva sa upotrebom Rubija na poslu i izazovi sa kojima se susreću ljudi čije se firme zasnivaju na drugim tehnologijama, ili gde ne postoji kultura pisanja testova.

To nas je odvelo u salu za prezentacije, gde je autor prisutnima pokazao primer primene BDD-a na popravljanje baga u real life kodu, što je bilo propraćeno diskusijom o RSpec-u i Cucumber-u, vežbanju, picom i krofnama (što se nastavilo na listi). Puno smo pričali i o uslovima za poslovanje u Srbiji.

Par linkova za kraj (Korijeva sabrana dela):

Ruby.rs sastanak u Bgd

Fri, 10 Jun 2011 14:57:48 +0200

Prošlo je već dosta vremena od poslednjeg ruby.rs sastanka i red je da organizujemo sledeći. Firma vast.com, u kojoj radimo Sale i ja, izašla nam je u susret i obezbediće prostorije i infrastrukturu.

Dakle, očekujemo sve rubiste u subotu, 25. juna u 16 sati u prostorijama Vasta - Trg Nikole Pašića 9, ulaz pored Novosti, žuta vrata.

Program bi bio sličan onom od prošlog sastanka:

sat-dva TDD coding dojo u parovima (nadam se da MarkoA nema ništa protiv da nam pripremi neki zadatak poput onog od prošlog puta)
sat-dva neobavezne diskusije ili prezentacije (ako ima interesenata: npr. izveštaj sa neke konferencije, predstavljanje softvera itd)

Molio bih samo da nam, ako ste u mogućnosti, unapred najavite prisustvo na mejl ["6a61626c616e40726164696f6e692e6361"].pack('H*') ili na Google mailing listu.

16. april 2011., Novi Sad

Wed, 27 Apr 2011 13:41:00 +0200

16. aprila 2011. naša mala družina se ponovo okupila u Novom Sadu, u kancelariji Rendered Text-a koja deluje kao poprilično fino mesto za rad. U odnosu na prethodni zvanični sastanak (od koga je prošlo dosta vremena), povećao se i broj Ruby programera u Srbiji, no na žalost nisu svi mogli da se pojave na sastanku. Nadamo se da će nas sledeći put biti u većem broju :)

Glavna aktivnost ovog sastanka je bio coding dojo, gde je zadatak koji smo rešavali bio PacMan. Ideja je bila da rešimo problem korišćenjem TDD. Problem smo rešavali tako što smo prvo pisali testove za određene akcije koje Pacman može da radi, a zatim pisali kod koji implementira te akcije. Tu smo se upoznali sa RSpecom. Na žalost ja do sada nisam imao velikog iskustva sa testiranjem (jedino od RSpeca što sam video je u RailsTutorialu), ali mislim da sam u tom nekom kratkom vremenu uz Darka i Marka uspeo da razumem neke nove stvari. TDD je odličan jer čoveka tera da u trenutku misli samo na jednu stvar koju implementira, i da se trudi da tu stvar što elegantnije reši. Ja sam tokom rada imao taj osećaj, jednostavno nisam gledao mnogo napred kao što inače radim, i razmišljao sam samo o malom delu koda koji smo u tom trenutku implementirali. Ako bismo kasnije odlučili da refaktorišemo neki kod, testovi su tu i bićemo sigurni da je sve ok. Naravno, i kada dodajemo nove stvari u kod ovime smo sigurni da se ništa što smo već napisali nije pokvarilo. Može se čoveku učiniti da ovakav razvoj traži više vremena, ali je to što smo sigurni da je sve dobro vredno truda. Pisanjem testova dobijamo praktično i dokumentaciju onoga što pišemo, tako da je to još jedan veliki plus (ko još voli da piše dokumentaciju nakon završenog posla :)).

Takođe smo bili podeljeni u grupe, i menjali se za računarom na određeno vreme, tako da je još jedna od “tehnika” sa kojom sam se ja prvi put ovde susreo i programiranje u paru. Divna tehnika, jer ovako možeš dosta da naučiš od ljudi sa kojima radiš, a i lakše je primetiti greške za vreme pisanja koda (bilo sintaksne ili semantičke prirode). Meni se ovo učinilo kao dobra tehnika da se dobije dobar kod, a i kasnije je neko pomenuo da Pivotal Labs radi isto tako. Poprilično zanimljiv način rada, koji bih voleo da praktikujem u svom svakodnevnom poslu.

Da sumiram svoje utiske: super ekipa (@darkofabijan, @jablanovic, @Lesa_ns, @marijanpovolni, @markoa, @sale87), super tema i poprilično uspešan sastanak. Nadam se da ćemo se uskoro okupiti u Beogradu u još većem broju i nastaviti da upoznajemo nove zanimljive tehnike za razvoj.

И онда орач рече, "Реци нам о раду."* или .rvmrc

Fri, 22 Apr 2011 00:31:00 +0200

Овај чланак је инспирисан:

Доктор Никовим саветом
Примером апликације о тестирању JavaScripta
И Срђановим “црвкутом”

Често изађу нове алатке и ако нису приказане на повољан начин, могу лако да мимоиђу потенционалне кориснике. Тако сам чуо за RVM у пролазу и дуго времена нисам обраћао пажњу на њега. Тек касније сам почео да га користим.

Сада бих да опишем врло сажето корисне делове горе поменуте алатке, јер сматрам да сам сајт то не ради довољно добро, али више то радим из љутње што ја нисам почео да користим све могућности овог пројекта. Па да спречим да се то не деси другима.

Увод

Шта је RVM? Само име говори шта ради: Ruby Version Manager, омогућава више верзија рубија да функционишу на једној машини. Али не само то, интересантан део је да уз верзије рубија, омогућава и опстанак “џемова” за сваку верзију. Но може још и нешто да омогући: посебну инсталацију “џемова” за сваки пројекат на вашој машини.

И сада, најбољи део, то све може да се активира аутоматски, за сваки пројекат чим се нађете у самом директоријому пројекта. И за све је заслужан само један фајл: .rvmrc.

Како?

RVM је скуп скрипти написаних у bash-у, које створе .rvm у вашем $HOME директоријому, где стави све жељене верзије рубија и њихове “џемове”.

Ви онда можете да бирате коју верзију рубија желите овако:

$ rvm list
    rvm rubies

   ruby-1.9.2-p136 [ x86_64 ]
=> ruby-1.8.7-p330 [ x86_64 ]

$rvm use 1.9.2

што ће да пређе са верзије 1.8.7 на верзију 1.9.2.

Зимница

То је прилично једноставно, али како шта је са “џемовима”? И они могу да се инсталирају исто као и пре:

$ gem install bundler

али овако је још и лакше пошто ће све бити инсталирано у вашем радном простору, тј. $HOME/.rvm.

То је практично, али посебно интересанто је то што можете да правите посебне скупове “џемова” који одговарају само одређеним пројектима. На следећи начин:

$ rvm gemset create moj-izbor

Пребаците се у тај нови скуп:

$ rvm ruby-1.9.2-p136@moj-izbor

И онда инсталирате пожељне “џемове”.

Информације

Путем rvm info можете да видите више детаља о тренутном стању вашег RVM окружења. На пример, да видите где су тренутно инсталирани “џемови” које користите:

$ rvm info|egrep "GEM_(HOME|PATH)"
    GEM_HOME:     "/home/taliban/.rvm/gems/ruby-1.9.2-p136"
    GEM_PATH:     "/home/taliban/.rvm/gems/ruby-1.9.2-p136:/home/taliban/.rvm/gems/ruby-1.9.2-p136@moj-izbor"
#
# пази ово ------------------------------------------------------------------------------------^^^^^^^^^

Аутомата

Прилично једноставно, али може бити још и лакше, нарочито ако радите на више пројеката или ако тестирате један пројекат на разне начине. Створите фајл .rvmrc у самом директоријуму пројекта са:

 rvm ruby-1.9.2

тако да не морате ручно да мењате ваше окружење, већ ће RVM то радити аутоматски од тада чим уђете у тај пројекат.

* део из књиге “Пророк” од Халила Џибрана

(слика преузета са pressonline.rs)

Блог у синатри, епизода једанаеста

Sat, 16 Apr 2011 14:21:01 +0200

Да објасним мало о овом пројекту, да ставим кратак опис о њему:

emacs README.md

и додам:

Једноставни блог у Синатри за [http://ruby.rs](http://ruby.rs)

Simple blog in Sinatra for [http://ruby.rs](http://ruby.rs)

па то ставим у гит:

$ git add README.md 
$ git commit -m "додајем README.md"
[master 67807a9] додајем README.md
 1 files changed, 3 insertions(+), 0 deletions(-)
 create mode 100644 README.md

Било би добро да када посетим неку страницу која не постоји, да прикажем грешку, попут: Nothing to see here, move along.

Отворим нови огранак у гиту:

$ git checkout -b 404
Switched to a new branch '404'

У blurgh_spec.rb, додам следећу спецификацију:

describe "error page" do
  it "should display a pre defined 404 message" do
    get '/non-existent-page'
    last_response.body.should match("Nothing to see here")
  end
end

покренем тест који наравно не пролази:

Failures:

  1) blurgh routes and content error page should display a pre defined 404 message
     Failure/Error: get '/non-existent-page'
     Errno::ENOENT:
       No such file or directory - spec/fixtures/non-existent-page.md
     # ./blurgh.rb:50:in `readlines'
     # ./blurgh.rb:50:in `get_post'
     # ./blurgh.rb:61:in `block in '
     # ./spec/blurgh_spec.rb:67:in `block (4 levels) in '

Да бих то исправио, морам да променим get_post методу из овога:

def get_post(post)
  header, body = File.readlines(Config.options['store'] + "/" + post + ".md", "")
end

у ово:

def get_post(post)
  begin
    header, body = File.readlines(Config.options['store'] + "/" + post + ".md", "")
  rescue Errno::ENOENT
    not_found
  end
end

not_found do
  "Nothing to see here"
end

Да објасним шта се овде изменило: begin … rescue омогућава да се изврши File.readlines метода, али ако се види грешка коју се приказала предходно: Errno::ENOENT онда да се покрене not_found метода. not_found метода је специфична, јер је већ унапред дефинисана у самом sinatra пројекту за употребу у оваквим случајевима, када се појављује грешка. И уместо да се види грешка, путем ње, може да се прикаже пожељно упозорење.

Покренем тестирање и све пролази.

Па да испробам и саму апликацију, додам:

store: spec/fixtures

у setup.yaml. И покренем:

$ shotgun blurgh.rb

Видим два чланка који се налазе под spec/fixtures, као што се видело и пре. И да би испробао нову методу укуцам http://localhost:9393/let2 на којој се види порука: Nothing to see here.

Да то сада додам у гит:

$ git status
# On branch 404
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   blurgh.rb
#   modified:   setup.yaml
#   modified:   spec/blurgh_spec.rb
#

$ git add blurgh.rb setup.yaml spec/blurgh_spec.rb

$ git commit -m "приказивање грешке за непостојећу страну"
[404 fb7e5c8] приказивање грешке за непостојећу страну
 3 files changed, 19 insertions(+), 2 deletions(-)

И да додам то у главно стабло гита:

$ git checkout master
Switched to branch 'master'

$ git merge 404
Updating 67807a9..fb7e5c8
Fast forward
 blurgh.rb           |   11 ++++++++++-
 setup.yaml          |    3 ++-
 spec/blurgh_spec.rb |    7 +++++++
 3 files changed, 19 insertions(+), 2 deletions(-)

Сада има сисем за блоговање, написан у 75 линија рубија. Који је тестиран. Може још шта да се дода, систем није комплетан. Али има добру основу.

Сав овај рад, окачен је овде.

Блог у синатри, епизода десета

Sat, 02 Apr 2011 02:13:48 +0200

Да би документација тестова била читљивија, преправим

context "the view" do

context "the index view" do

и додам нови тест:

context "the post view" do
  it "should show post content" do
    get '/let'
    last_response.body.should match("25. марта 1923. - Слетањем авиона на линији Париз-Цариград на")
  end
end

Тај тест наравно не пролази, зато што не постоји ништа што би приказало садржај фајла. То могу да омогућим тако што створим методу која ће приказивати индивидалне чланке:

get '/:post' do
  @config, @content = get_post(:post)
  erb :post
end

и додам и post.erb у views/:

<%= @content %>

само да би било што једноставније и да би омогућио да тест прође.

Покренем тест, и он пада са следећом поруком:

1) blurgh routes and content the post view should show post content
     Failure/Error: get '/let'
     TypeError:
       can't convert Symbol into String
     # ./blurgh.rb:46:in `+'
     # ./blurgh.rb:46:in `get_post'
     # ./blurgh.rb:58:in `block in '
     # ./spec/blurgh_spec.rb:44:in `block (4 levels) in '

што значи да се get_post метода не добија одговарајући аргумент. Зато преправим:

@config, @content = get_post(:post)

@config, @content = get_post(params[:post])

покренем тестирање поново и све прође.

Но нисам баш задовољан предходним тестом, он само проверава прву линију чланка

last_response.body.should match("25. марта 1923. - Слетањем авиона на линији Париз-Цариград на")

Било би боље када би учитавао сав фајл. Зато изменим тест у:

it "should show post content" do
  get '/let'
  article = File.readlines("spec/fixtures/let.md", "")[1]
  last_response.body.should match(article)
end

јер ми изгледа читљивије. Па покренем тест… који прође.

Додам напредак у гит:

$ git status
# On branch posts
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   blurgh.rb
#   modified:   spec/blurgh_spec.rb
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#   views/post.erb
no changes added to commit (use "git add" and/or "git commit -a")

Овде се види да је views/post.erb нови фајл који још није унет у гит. Зато требам да га додам са осталим фајловима где је направљена промена:

$ git add blurgh.rb spec/blurgh_spec.rb views/post.erb 

$ git commit -m "приказивање чланака"
[posts 5540485] приказивање чланака
 3 files changed, 20 insertions(+), 5 deletions(-)
 create mode 100644 views/post.erb

Било би добро да додам да може да се види наслов када се прикаже чланак.

it "should show post title" do
  get '/let'
  config = File.readlines("spec/fixtures/let.md", "")[0]
  post_options = YAML.load(config)
  last_response.body.should match(post_options['title'])
end

Покренем тест, и он не пролази, зато што немам начин да прикажем наслов на страници која приказује чланке.

Зато преуредим get ‘/:post’ у:

get '/:post' do
  @config, @content = get_post(params[:post])
  @title = YAML.load(@config)['title']
  erb :post
end

подесим post.erb:


  <%= @title %>


<%= @content %>

покренем тест и он прође. Зато да учитам у гит:

$ git status
# On branch posts
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   blurgh.rb
#   modified:   setup.yaml
#   modified:   spec/blurgh_spec.rb
#   modified:   views/post.erb

$ git add blurgh.rb spec/blurgh_spec.rb views/post.erb 
$ git commit -m "приказивање наслова чланака"

Сада да додам датум за чланке. Прво да додам тест:

it "should show post date" do
  get '/let'
  config = File.readlines("spec/fixtures/let.md", "")[0]
  post_options = YAML.load(config)
  last_response.body.should match("20110325")
end

Па да се уверим да тест пада:

$ bundle exec rake

И онда да преправим get ‘/:post’:

get '/:post' do
  @config, @content = get_post(params[:post])
  post_options = YAML.load(@config)
  @title = post_options['title']
  @date =  post_options['date']
  erb :post
end

и да променим post.erb:


  <%= @title %>



  <%= @date %>


<%= @content %>

Покренем тест и он прође. Па да додам напредак у гит:

$ git status
# On branch posts
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   blurgh.rb
#   modified:   spec/blurgh_spec.rb
#   modified:   views/post.erb
#

$ git add blurgh.rb spec/blurgh_spec.rb views/post.erb

$ git commit -m "приказивање датума чланака"
[posts d005862] приказивање датума чланака
 3 files changed, 14 insertions(+), 1 deletions(-)

Па да додам овај огранак у главни, тако што се прво пребацим у master огранак:

$ git checkout master
Switched to branch 'master'

и сада да додам posts огранак у master:

$ git merge posts
Auto-merging blurgh.rb
CONFLICT (add/add): Merge conflict in blurgh.rb
Auto-merging spec/blurgh_spec.rb
CONFLICT (add/add): Merge conflict in spec/blurgh_spec.rb
Auto-merging spec/config_spec.rb
CONFLICT (add/add): Merge conflict in spec/config_spec.rb
Auto-merging views/index.erb
CONFLICT (add/add): Merge conflict in views/index.erb
Automatic merge failed; fix conflicts and then commit the result.

Ово је ново. Порука ми говори да измене које сам направио се не подударају апсолутно са садржајем master огранку.

Да би то решио, морам да направим измене ручно. Отворим прво blurgh.rb и видим следеће:

module Config
<<<<<<< HEAD:blurgh.rb
  def self.title
    options["title"]
  end

=======

Да би то поправио, морам сам да коригујем у едитору. Бацим се на посао, фајл по фајл… То су тестови да ми помогну да ништа није пропуштено.

Али ако у међу времену покушам да додам огранак posts поново, добићу следећу грешку:

$ git merge posts
fatal: You have not concluded your merge. (MERGE_HEAD exists)

то је зато што гит није могао аутоматски да дода нови огранак, па је направио нове фајлове, спајањем постојећих фајлова у master огранку са фајловима из posts огранка.

Да би то решио, морам прво да средим све фајлове и да сви тестови пролазе. Затим да видим статус гита, и тек онда да додам фајлове:

$ git status
blurgh.rb: needs merge
spec/blurgh_spec.rb: needs merge
spec/config_spec.rb: needs merge
views/index.erb: needs merge
# On branch master
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#   new file:   spec/fixtures/let.md
#   new file:   spec/fixtures/o-kapadokiji.md
#   new file:   views/post.erb
#
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   unmerged:   blurgh.rb
#   unmerged:   spec/blurgh_spec.rb
#   unmerged:   spec/config_spec.rb
#   unmerged:   views/index.erb
#

$ git add blurgh.rb spec/config_spec.rb spec/blurgh_spec.rb views/index.erb

али требам да додам и нове фајлове:

$ git add spec/fixtures/o-kapadokiji.md spec/fixtures/let.md views/post.erb

На крају учитам све промене у гит:

$ git commit -m "додајем рад на чланцима"

Ако погледам лог гита, видим да су то и поруке из posts огранка:

$ git log --oneline | head -5
88f2449 додајем рад на чланцима
d005862 приказивање датума чланака
4a40483 приказивање наслова чланака
5540485 приказивање чланака
a79f8c8 смршао blurgh_spec.rb

Наставља се …

Блог у синатри, епизода девета

Fri, 01 Apr 2011 17:07:05 +0200

Резултат тестирања изгледа овако:

$ bundle exec rake

Config
  .title
    should return value
  when the title is blank
    should return nothing
  when the title is missing
    should return nil
  .store
    should return value
  .all
    should return all the values

blurgh
  routes and content
    should respond to /
    should have a title
    the view
      should have a body html elements
      the posts URLs should be listed
  get_posts
    should return posts
    on the index page
      the posts URLs should be listed
      the posts titles should be shown
  get_post
    should return a post in two parts

Finished in 0.02477 seconds
13 examples, 0 failures

То је зато што сам одредио да формат резултата теста буде: —format doc у .rspec фајлу.

Но проблем је што сам ставио:

on the index page
  the posts URLs should be listed
  the posts titles should be shown

да је унутар get_posts. То би приуредим и да наместим да буде читљивије.

Тренутно blurgh_spec.rb изгледа овако:

# -*- coding: utf-8 -*-
require 'spec_helper'

describe "blurgh" do

  def app
    @app ||= Sinatra::Application
  end

  context "routes and content" do
    before :each do
      YAML.should_receive(:load_file)\
       .with("setup.yaml").and_return({"title" => "Naslov", "store" => "posts"})
    end

    it "should respond to /" do
      get '/'
      last_response.should be_ok
    end

    it "should have a title" do
      get '/'
      last_response.body.should match("Naslov")
    end

    context "the view" do
      it "should have a body html elements" do
        get '/'
        last_response.body.should match("")
      end

      it "the posts URLs should be listed" do
        get '/'
        # last_response.body.should match("let")
        last_response.body.should match('Авионски лет')
      end
    end
  end

  describe "get_posts" do

    before do
      YAML.should_receive(:load_file).with("setup.yaml")\
        .and_return({"title" => "Naslov", "store" => "spec/fixtures"})
    end

    it "should return posts" do
      first_article = File.readlines("spec/fixtures/o-kapadokiji.md", "")[1]
      second_article = File.readlines("spec/fixtures/let.md", "")[1]
      store = Config.all['store']

      get_posts(store).should == \
      [[20110325,  {"url" => "let", "title" => "Авионски лет", "body" => "#{second_article}"}],\
       [20110324, {"url" => "o-kapadokiji", "title" => "Кападокија", "body" => "#{first_article}"}]]
    end

    context "on the index page" do
      it "the posts URLs should be listed" do
        get '/'
        last_response.body.should match("let")
        last_response.body.should match("o-kapadokiji")
      end

      it "the posts titles should be shown" do
        get '/'
        last_response.body.should match('Авионски лет')
        last_response.body.should match('Кападокија')
      end

    end

  end

  describe "get_post" do

    before do
      YAML.should_receive(:load_file).with("setup.yaml")\
        .and_return({"title" => "Naslov", "store" => "spec/fixtures"})
    end

    it "should return a post in two parts" do
      get_post("o-kapadokiji").should have(2).parts
    end

  end

end

Да би то променио, променим прво:

context "routes and content" do
  before :each do
    YAML.should_receive(:load_file)\
     .with("setup.yaml").and_return({"title" => "Naslov", "store" => "posts"})
  end

context "routes and content" do
  before :each do
    YAML.should_receive(:load_file)\
     .and_return({"title" => "Naslov", "store" => "spec/fixtures"})
  end

Покренем тестирање и оно прође.

Али сада се то понавља три пута, што да не ставим то пре почетка свих тестова:

before :each do
  YAML.should_receive(:load_file)\
    .and_return({"title" => "Naslov", "store" => "spec/fixtures"})
end

а остале избришем. Покренем тест и пролази без жалби.

Вратим се предходној жељи где би да групишем сродне тестове, тако да преуредим фајл да изгледа овако:

# -*- coding: utf-8 -*-
require 'spec_helper'

describe "blurgh" do

  before :each do
    YAML.should_receive(:load_file)\
      .and_return({"title" => "Naslov", "store" => "spec/fixtures"})
  end

  def app
    @app ||= Sinatra::Application
  end

  context "routes and content" do

    it "should respond to /" do
      get '/'
      last_response.should be_ok
    end

    context "the view" do

      it "should have a title" do
        get '/'
        last_response.body.should match("Naslov")
      end

      it "should have a body html elements" do
        get '/'
        last_response.body.should match("")
      end

      it "the posts titles should be shown" do
        get '/'
        last_response.body.should match('Авионски лет')
        last_response.body.should match('Кападокија')
      end

    end
  end

  describe "get_posts" do

    it "should return posts" do
      first_article = File.readlines("spec/fixtures/o-kapadokiji.md", "")[1]
      second_article = File.readlines("spec/fixtures/let.md", "")[1]
      store = Config.all['store']

      get_posts(store).should == \
      [[20110325,  {"url" => "let", "title" => "Авионски лет", "body" => "#{second_article}"}],\
       [20110324, {"url" => "o-kapadokiji", "title" => "Кападокија", "body" => "#{first_article}"}]]
    end

  end

  describe "get_post" do

    it "should return a post in two parts" do
      get_post("o-kapadokiji").should have(2).parts
    end

  end

end

Што је у мом мишљењу, читљивије и логичније. Покренем тест и он прође. Да додам у гит:

$ git status
# On branch posts
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   spec/blurgh_spec.rb
#

$ git add spec/blurgh_spec.rb 
$ git commit -m "смршао blurgh_spec.rb"
[posts 0e3722c] смршао blurgh_spec.rb
 1 files changed, 18 insertions(+), 34 deletions(-)

Блог у синатри, епизода осма

Thu, 31 Mar 2011 00:00:48 +0200

Сада да претворим фајлове у HTML линкове.

Прво направим тест под describe “get_posts”:

it "the posts titles should be shown" do
  get '/'
  last_response.body.should match('Авионски лет')
  last_response.body.should match('Кападокија')
end

Онда да подесим index.erb:

<%= @title %>

<% @posts.each do |post| %>
   <%= post[1]['title'] %>
<% end %>

покренем тест, и он успешно прође. Да додам напредак у гит:

$ git status
# On branch posts
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   spec/blurgh_spec.rb
#   modified:   views/index.erb
#

$ git add spec/blurgh_spec.rb views/index.erb

$ git commit -m "омогућено претварање наслова чланака у URL на почетној страници"
[posts b1ad84c] омогућено претварање наслова чланака у URL на почетној страници
 2 files changed, 8 insertions(+), 1 deletions(-)

Било би добро да сада могу да видим и саме чланке. Пошто су они сами фајлови, треба ми нека метода која ће да их чита. Да кренем са тестом:

describe "get_post" do
  pending
end

покренем тестирање:

$ bundle exec rspec spec/blurgh_spec.rb

и оно пада са:

Pending:
  blurgh get_post 
    # Not Yet Implemented
    # ./spec/blurgh_spec.rb:69

Када размислим мало боље о овоме, како ће се фајлови читати, то ће бити у суштини овако:

/име-фајла

Но како они треба да изгледају кад су прочитани. Слично као и када их get_posts чита, сачињени од два дела. Први део је YAML конфигурација а други, сам садржај.

Тако да пишем следећи тест:

describe "get_post" do
  it "should return a post in two parts" do
    get_post("o-kapadokiji").should have(2).parts
  end
end

Покренем тест, који пада, зато пишем следећу методу:

def get_post(post)
  header, body = File.readlines(Config.options['store'] + "/" + post + ".md", "")
end

покренем тест и он пада:

1) blurgh get_post should return a post in two parts
   Failure/Error: get_post("o-kapadokiji").should have(2).parts
   NoMethodError:
     undefined method `+' for nil:NilClass
   # ./blurgh.rb:46:in `get_post'
   # ./spec/blurgh_spec.rb:76:in `block (3 levels) in '

46 линија је средина предходне методе и она очекује конфигурацију за Config. Зато преправим тест да изгледа овако:

describe "get_post" do

  before do
    YAML.should_receive(:load_file).with("setup.yaml")\
      .and_return({"title" => "Naslov", "store" => "spec/fixtures"})
  end

  it "should return a post in two parts" do
    get_post("o-kapadokiji").should have(2).parts
  end

end

Покренем тест, који успешно прође.

Па додам то у гит:

$ git status
# On branch posts
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   blurgh.rb
#   modified:   spec/blurgh_spec.rb
no changes added to commit (use "git add" and/or "git commit -a")

$ git add blurgh.rb spec/blurgh_spec.rb

$ git commit -m "учитавање чланка"
[posts b1290dd] учитавање чланка
 2 files changed, 17 insertions(+), 0 deletions(-)

Овде би било добро да обратим пажњу на:

get_post("o-kapadokiji").should have(2).parts

специфично на have(2).parts део. parts је само реч која је ту додана да би тест био читљивији. Она може бити замењена са неком другом и тест ће и даље да прође. На пример:

get_post("o-kapadokiji").should have(2).сарма

пролази као важећи тест.

Ако заменим сарма са class, добијам следећу грешку:

1) blurgh get_post should return a post in two parts
     Failure/Error: get_post("o-kapadokiji").should have(2).class
     NoMethodError:
       undefined method `matches?' for RSpec::Matchers::Have:Class
     # ./spec/blurgh_spec.rb:76:in `block (3 levels) in '

што ми указује на то да је have(2) сачињена од Have класе. Ако погледам https://github.com/rspec/rspec-expectations/blob/master/lib/rspec/matchers/have.rb видим следеће под примерима:

#   should have(number).named_collection__or__sugar

…

# If the receiver IS the collection, you can use any name
# you like for named_collection. We'd recommend using
# either "elements", "members", or "items" as these are all
# standard ways of describing the things IN a collection.

па примери:

# Passes if [1,2,3].length == 3
# [1,2,3].should have(3).items #"items" is pure sugar

Наставак следи…

Блог у синатри, епизода седма

Tue, 29 Mar 2011 17:06:58 +0200

Било би пожељно да овај систем може да учита чланке и да их прикаже. Идеја је да чита чланке из одређеног директоријума који је наведен у конфигурационом фајлу setup.yaml на следећи начин:

store: posts

За то да направим нови огранак у гиту:

$ git checkout -b posts

Прво желим да Config чита и .store врати име директоријума. То означим у тесту овако:

describe ".store" do
  it "should return value" do
    YAML.should_receive(:load_file).with("setup.yaml").and_return({"store" => "posts"}) 
    Config.store.should match("posts")
  end
end

покренем тест и он не прође:

1) Config.store should return value
   Failure/Error: Config.store.should match("posts")
   NoMethodError:
     undefined method `match' for nil:NilClass

Онда у Config додам нову методу:

def self.store
  options["store"]
end

Поново покренем тест, и овај пут прође. Додам тај рад у гит:

$ git status
# On branch posts
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   blurgh.rb
#   modified:   spec/config_spec.rb
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git add blurgh.rb spec/config_spec.rb
$ git commit -m "додана метода Config.store"
[posts b243446] додана метода Config.store
 2 files changed, 12 insertions(+), 0 deletions(-)

Сада имам тачно одређено место где ће да се држе чланци, али још немам ништа да их учитам. То желим да ми уради метода get_posts која ће да врати све фајлове директоријума на који указује store. Тест за ту методу изгледа овако:

describe "get_posts" do
  it "should return posts" do
    Dir.should_receive(:entries).with("posts").and_return(["sample_post.md", "another_sample_post.md"])
    get_posts.should == ["sample_post.md", "another_sample_post.md"]
  end
end

И кад покренем тестове, добијем следеће:

 1) blurgh get_posts should return posts
Failure/Error: get_posts.should == ["sample_post.md", "another_sample_post.md"]
NameError:
  undefined local variable or method `get_posts' for #

Напишем следећу методу у blurgh.rb:

def get_posts
  Dir.entries(Config.store)
end

покренем тестирање поново и тест прође.

Но то ми није довољно, јер како ћу да организујем чланке, овако су враћени у “хрпи”. Било би боље када би они могли да буду организовани по датуму.

И како ћу за наслов ?

То би могло да се реши овако: сваки чланак да буде сачињен делимично у YAML формату, то јест, први параграф, а остатак да буде сам чланак. На пример да садржај фајла изгледа овако:

title: Кападокија
date: 20110324

Премало се зна о Кападокији пре него што је постала персијска
сатрапија. Зна се само да је Кападокија била у време Хета веома
значајна земља и да се управо у њој налазила хетска престоница
Хатуша. Иако сатрапија у персијско време, Кападокија је сачувала
известан степен самосталности.

То би било у реду за један чланак, али шта са get_posts методом ? У каквом формату да врати чланке ?

Било би добро да буду враћени у следећем формату:

[[["20110324"], {"title" => "Кападокија", "body" => "Премало се зна о Кападокији..."}]]

На тај начин могу лако да сортирам чланке.

И шта још би могао да ту додам? Адресу, тј. URL сваког чланка. Намерно бих да title буде наслов у самој страници а да име фајла буде URL. Тако да ако предходни пример чланак назовем: o-kapadokji.md, формат који би get_posts метода враћала би био:

[["20110324", {"url" => "o-kapadokiji", "title" => "Кападокија", "body" => "Премало се зна о Кападокији..."}]]

Да то направим да буде направићу два фајла која ћу да користим за тестирање:

$ mkdir spec/fixtures
$ emacs spec/fixtures/o-kapadokiji.md

И ту ставим горе наведени текст. Онда отворим други фајл:

$ emacs spec/fixtures/let.md

Ставим следећи текст:

title: Авионски лет
date: 20110325

25. марта 1923. - Слетањем авиона на линији Париз-Цариград на аеродром
у Панчеву, Краљевина СХС постала део тада малобројне породице држава
повезаних ваздушним саобраћајем.

Сада да преправим тест:

describe "get_posts" do
  it "should return posts" do
    first_article = File.readlines("spec/fixtures/o-kapadokiji.md", "")[1]
    second_article = File.readlines("spec/fixtures/let.md", "")[1]
    YAML.should_receive(:load_file).with("setup.yaml").and_return({"title" => "Naslov", "store" => "spec/fixtures"}) 

    get_posts.should == \
    [[20110325,  {"url" => "let", "title" => "Авионски лет", "body" => "#{second_article}"}],\
     [20110324, {"url" => "o-kapadokiji", "title" => "Кападокија", "body" => "#{first_article}"}]]

  end
end

Да објасним овде да first_article и second_article су само фајлови учитани, да не бих писао цео њихов садржај. И store сада чита фајлове из spec/fixtures.

Покренм тестирање:

$ bundle exec rspec spec/blurgh_spec.rb

али тест не прође:

1) blurgh get_posts should return posts
     Failure/Error: get_posts.should == \
     Errno::ENOENT:
       No such file or directory - posts

То је зато што на самом почетку теста имам:

before :each do
  YAML.should_receive(:load_file).with("setup.yaml").and_return({"title" => "Naslov", "store" => "posts"}) 
end

који попуњава store са posts. Да би то спречио одвојићу прва неколико теста у једну целину на следећи начин:

 context "routes and content" do
   before :each do
     YAML.should_receive(:load_file).with("setup.yaml").and_return({"title" => "Naslov", "store" => "posts"}) 
   end

   it "should respond to /" do
     get '/'
     last_response.should be_ok
   end

   it "should have a title" do
     get '/'
     last_response.body.should match("Naslov")
   end

   context "the view" do
     it "should have a body html elements" do
       get '/'
       last_response.body.should match("")
     end
   end
 end

док је други тест сам за себе.

Покренем тест и он опет не пролази:

1) blurgh get_posts should return posts
   Failure/Error: [["20110325"], {"url" => "let", "title" => "Авионски лет", "body" => "#{second_article}"}]]
     expected: [[["20110324"], {"url"=>"o-kapadokiji", "title"=>"Кападокија",
     ...

што је и пожељан резултат. Јер ако се анлизира грешка, драгачија је од предходне: не жали се о томе како не може да прочита неки фајл, већ да резултат методе није идентичан очекиваном.

Сада да прилагодим методу, да би прошао тест:

def get_posts

  all_posts = Hash.new {
    |h,k| h[k] = Hash.new(&h.default_proc) 
  }

  post_dir = File.join(Config.store + "/" + "*.md")

  Dir.glob(post_dir).each do |post|
    header, body = File.readlines(post, "")
    data = YAML.load(header)
    all_posts[data['date']]['url']   = post.gsub("\.md", "").gsub(Config.store + "/", "")
    all_posts[data['date']]['title'] = data['title']
    all_posts[data['date']]['body']  = body
  end

  all_posts.sort.reverse

end

all_posts je “хаш хашева” (следи објашњење!). Dir.glob чита фајлове из Config.store и попуњава all_posts.

Покренем тест и … он падне:

1) blurgh get_posts should return posts
   Failure/Error: YAML.should_receive(:load_file).with("setup.yaml").and_return({"title" => "Naslov", "store" => "spec/fixtures"})
     (Syck).load_file("setup.yaml")
         expected: 1 time
         received: 3 times

Ово ми говори да сам добио жељени резултат, но само је метода позивала YAML.load_file више него што је означено у тесту. Овде ми тест не помаже да програм буде коректан, већ и ефикаснији.

Преправим методу у:

def get_posts

  all_posts = Hash.new {
    |h,k| h[k] = Hash.new(&h.default_proc) 
  }

  store = Config.store
  post_dir = File.join(store + "/" + "*.md")

  Dir.glob(post_dir).each do |post|
    header, body = File.readlines(post, "")
    data = YAML.load(header)
    all_posts[data['date']]['url']   = post.gsub("\.md", "").gsub(store + "/", "")
    all_posts[data['date']]['title'] = data['title']
    all_posts[data['date']]['body']  = body
  end

  all_posts.sort.reverse

end

покренем тест и сада прође. Што значи да треба да се убаци у гит:

$ git status
# On branch posts
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   blurgh.rb
#   modified:   spec/blurgh_spec.rb
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#   spec/fixtures/
no changes added to commit (use "git add" and/or "git commit -a")
$ git add blurgh.rb spec/blurgh_spec.rb spec/fixtures/
$ git status
# On branch posts
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#   modified:   blurgh.rb
#   modified:   spec/blurgh_spec.rb
#   new file:   spec/fixtures/let.md
#   new file:   spec/fixtures/o-kapadokiji.md
#
$ git commit -m "урађена метода get_posts"
[posts fba900e] урађена метода get_posts
 4 files changed, 81 insertions(+), 31 deletions(-)
 rewrite spec/blurgh_spec.rb (73%)
 create mode 100644 spec/fixtures/let.md
 create mode 100644 spec/fixtures/o-kapadokiji.md

Наставља се… (у следећој епизоди RSpec пије пиво и осваја свет)

Да видим како би то сада могао да организујем да се листа чланака прикаже на почетној страни.

Додам следећи тест:

context "on the index page" do
  it "the posts URLs should be listed" do
    get '/'
    last_response.body.should match("let")
    last_response.body.should match("o-kapadokiji")
  end
end

под **describe “get_posts” **, покренем тестирање и оно пада:

1) blurgh get_posts on the index page the posts URLs should be listed
   Failure/Error: last_response.body.should match("let")
     expected "\n  \n    Пази сад\n\n  \n\n" to match "let"
   # ./spec/blurgh_spec.rb:47:in `block (4 levels) in '

што ми указује да мој тест чита прави setup.yaml, што треба исправити тако што наместим да се YAML објекат учита пре самог теста. То урадим на следећи начин, тако што омогућим у before блоку:

describe "get_posts" do

  before do
    YAML.should_receive(:load_file).with("setup.yaml")\
      .and_return({"title" => "Naslov", "store" => "spec/fixtures"})
  end

  it "should return posts" do
    first_article = File.readlines("spec/fixtures/o-kapadokiji.md", "")[1]
    second_article = File.readlines("spec/fixtures/let.md", "")[1]

    get_posts.should == \
    [[20110325,  {"url" => "let", "title" => "Авионски лет", "body" => "#{second_article}"}],\
     [20110324, {"url" => "o-kapadokiji", "title" => "Кападокија", "body" => "#{first_article}"}]]
  end

  context "on the index page" do
    it "the posts URLs should be listed" do
      get '/'
      last_response.body.should match("let")
      last_response.body.should match("o-kapadokiji")
    end
  end

end

Тест опет пада, али са садржајем који сам ја дефинисао у тесту:

1) blurgh get_posts on the index page the posts URLs should be listed
   Failure/Error: last_response.body.should match("let")
     expected "\n  \n    Naslov\n\n  \n\n" to match "let"
   # ./spec/blurgh_spec.rb:53:in `block (4 levels) in '

Сада да наместим да index.html добије линкове чланака, преправим оригинални get ‘/’ у:

get '/' do
  @title = Config.title
  @posts = get_posts
  erb :index 
end

и у index.erb додам:

<% @posts.each do |post| %>
   <%= post[1]['url'] %>
<% end %>

покренем тест, али овај пут само одређени, задњи тест на којем радим:

bundle exec rspec -e "blurgh get_posts on the index page" spec/blurgh_spec.rb

резултат је:

Failures:

    1) blurgh get_posts on the index page the posts URLs should be listed
       Failure/Error: YAML.should_receive(:load_file).with("setup.yaml")\
         (Syck).load_file("setup.yaml")
             expected: 1 time
             received: 2 times
       # ./spec/blurgh_spec.rb:36:in `block (3 levels) in '

што ми говори да очекивани резултат теста је тачан, али да се конфигурациони фајл чита два пута. Једном се чита:

@title = Config.title

а други пут:

@posts = get_posts

Могао бих да преправим Config модул да чита резултате само једном и да их све врати. Нешто овако:

self.all
  options["title"], options["store"]
end

Али што се тиче овог чланка, овако је једноставније за сада, ма да можда није изванредно ефикасно. Но да не заборавим, ставићу белешку да се овоме вратим и погледам поново:

module Config
  # TODO: moze biti efikasnije

Сада да подесим тест:

YAML.should_receive(:load_file).exactly(2).times.with("setup.yaml")\
  .and_return({"title" => "Naslov", "store" => "spec/fixtures"})

Додао сам: .exactly(2).times што ће омогућити да тест прође:

$ bundle exec rspec -e "blurgh get_posts on the index page" spec/blurgh_spec.rb
Run filtered using {:full_description=>/(?-mix:blurgh get_posts on the index page)/}

blurgh
  routes and content
    the view
  get_posts
    on the index page
      the posts URLs should be listed

Finished in 0.02366 seconds
1 example, 0 failures

Покренем тест за цео програм и добијам следећу грешку за четири случаја:

blurgh
  routes and content
    should respond to / (FAILED - 1)
    should have a title (FAILED - 2)
    the view
      should have a body html elements (FAILED - 3)
  get_posts
    should return posts (FAILED - 4)

 ...    

 Failure/Error: YAML.should_receive(:load_file).with("setup.yaml").and_return({"title" => "Naslov", "store" => "posts"})
   (Syck).load_file("setup.yaml")
       expected: 1 time
       received: 2 times

И то исто могу да исправим тако што учиним исту измену и за те тестове, али опет добијам следећу грешку:

1) blurgh get_posts should return posts
   Failure/Error: YAML.should_receive(:load_file).exactly(2).times.with("setup.yaml")\
     (Syck).load_file("setup.yaml")
         expected: 2 times
         received: 1 time
   # ./spec/blurgh_spec.rb:37:in `block (3 levels) in '

Што ми указује да ћу више труда потрошити на измени тестова, него да применим нову методу all у Config модулу. Зато вратим ове две задње измене и додам нови тест:

describe ".all" do
  it "should return all the values" do
    YAML.should_receive(:load_file).with("setup.yaml")\
      .and_return({"title" => "Naslov", "store" => "posts"}) 
    Config.all.should == {"title" => "Naslov", "store" => "posts"}
  end
end

са методом:

def self.all
  options
end

Покренм тестове за Config:

$ bundle exec rspec spec/config_spec.rb

сви прођу.

Сада да преправим тестове за blurgh:

it "should return posts" do
  first_article = File.readlines("spec/fixtures/o-kapadokiji.md", "")[1]
  second_article = File.readlines("spec/fixtures/let.md", "")[1]
  store = Config.all['store']

  get_posts(store).should == \
  [[20110325,  {"url" => "let", "title" => "Авионски лет", "body" => "#{second_article}"}],\
   [20110324, {"url" => "o-kapadokiji", "title" => "Кападокија", "body" => "#{first_article}"}]]
end

тест у овом случају неће да прође јер get_posts метода очекује аргумент. Њу преправим у:

def get_posts(store)

  all_posts = Hash.new {
    |h,k| h[k] = Hash.new(&h.default_proc) 
  }

  post_dir = File.join(store + "/" + "*.md")

  Dir.glob(post_dir).each do |post|
    header, body = File.readlines(post, "")
    data = YAML.load(header)
    all_posts[data['date']]['url']   = post.gsub("\.md", "").gsub(store + "/", "")
    all_posts[data['date']]['title'] = data['title']
    all_posts[data['date']]['body']  = body
  end

  all_posts.sort.reverse

end

Покренем тест, али он пада:

1) blurgh routes and content should respond to /
   Failure/Error: get '/'
   ArgumentError:
     wrong number of arguments (0 for 1)
   ...

Порука је да у get ‘/’ користим нешто са погрешним бројем аргумената. Изменим блок да сада користи аргумент у позиву у get_posts методи:

get '/' do
  blurgh_conf = Config.all
  @title = blurgh_conf['title']
  @posts = get_posts(blurgh_conf['store'])
  erb :index 
end

Покренем тестирање и све прође:

$ bundle exec rake

И пре него што убацим то у гит, било би добро да погледам како то заправо изгледа.

Отворим setup.yaml и додам:

store: spec/fixtures

покренем апликацију:

$ shotgun blurgh.rb

И погледам http://localhost:9393/ и видим имена фајлова.

Вратим измену у setup.yaml и додам рад у гит:

$ git status
# On branch posts
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   blurgh.rb
#   modified:   spec/blurgh_spec.rb
#   modified:   spec/config_spec.rb
#   modified:   views/index.erb
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#   .bundle/
no changes added to commit (use "git add" and/or "git commit -a")
$ git add blurgh.rb spec/ views/
$ git status
# On branch posts
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#   modified:   blurgh.rb
#   modified:   spec/blurgh_spec.rb
#   modified:   spec/config_spec.rb
#   modified:   views/index.erb
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#   .bundle/
$ git commit -m "приказује листу чланака на index.html"
[posts 21d9938] приказује листу чланака на index.html
 4 files changed, 45 insertions(+), 13 deletions(-)

Једна напомена овде, кад сам урадио git status приказана су четири фајла. Али ја сам уписао само три аргумента кад сам радио git add:

$ git add blurgh.rb spec/ views/

То је зато што када се гиту дају аргументи са завршном /, он учита фајлове из тог директоријума.

У следећој епизоди: претварање фајлова у линкове и можда још нешто…

Блог у синатри, епизода шеста

Tue, 29 Mar 2011 17:06:26 +0200

Пошто имам сада основну структуру, мало да “затегнем” тестирање.

Створим нови огранак у коме ћу да радим:

$ git checkout -b mocks

Кад сам намештао YAML објекат да врати садржај фајла:

YAML.stub!(:load_file).with("setup.yaml").and_return({"title" => "Naslov"})

ја сам користио stub!. А описивао сам stub. Иако обе методе врше исту сврху, stub! (са узвичником) потиче из RSpec верзије 1, док је stub из RSpec 2. Обе раде у верзији 2.

То може да се преправи, али би било боље да се пређе на нешто још и боље: mocks.

Пре него што то урадим да објасним шта је шта.

Stub је замена за објекат или делове, тј. методе, за објекат.

Mock је “лажни” објекат.

Која је разлика ?

Разлика између stub и mocks је у томе што је mock “интерактиван”. Шта то тачно значи? У овом случају то значи да mock јасно дефинише да треба да се назове/користи. Ако није назван/коришћен током теста, тест је неуспешан. Док stub неће да се жали ако се не користи у тесту.

Ево и примера:

describe ".title" do
  it "should return value" do
    YAML.stub!(:load_file).with("setup.yaml").and_return({"title" => "Naslov"}) 
    Config.title.should match("Naslov")
  end
end

ако додам у њега додам YAML.stub(:load):

describe ".title" do
  it "should return value" do
    YAML.stub!(:load_file).with("setup.yaml").and_return({"title" => "Naslov"}) 
    YAML.stub(:load) # <-- додатак
    Config.title.should match("Naslov")
  end
end

Тест ће да успе. Али ако то урадим са mock-ом:

describe ".title" do
  it "should return value" do
    YAML.stub!(:load_file).with("setup.yaml").and_return({"title" => "Naslov"}) 
    YAML.should_receive(:load)  # <-- додатак
    Config.title.should match("Naslov")
  end
end

тест не пролази:

Failures:

  1) Config.title should return value
     Failure/Error: YAML.should_receive(:load)
       (Syck).load(any args)
           expected: 1 time
           received: 0 times

Да би направили тест да буде што реалнији, боље би било да се пише овако:

describe ".title" do
  it "should return value" do
    YAML.should_receive(:load_file).with("setup.yaml").and_return({"title" => "Naslov"}) 
    Config.title.should match("Naslov")
  end
end

Онда заменим све stub! са should_receive и покренем тестове:

$ bundle exec rake

сви пролазе. Да видим шта је измењено:

$ git status
# On branch mocks
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   spec/blurgh_spec.rb
#   modified:   spec/config_spec.rb

Онда да их додам у гит:

$ git add spec/blurgh_spec.rb spec/config_spec.rb
$ git commit -m "мала измена у тестовима, са stub на mock"

И онда додам нове измене у главно стабло кода:

$ git checkout master
Switched to branch 'master'
asimic@byzantium:~/dev/blurgh2$ git merge mocks
Updating 4f37cd4..c13635d
Fast-forward
 spec/blurgh_spec.rb |    2 +-
 spec/config_spec.rb |    6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

$ git merge mocks
Updating 4f37cd4..c13635d
Fast-forward
 spec/blurgh_spec.rb |    2 +-
 spec/config_spec.rb |    6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

Блог у синатри, епизода пета

Tue, 29 Mar 2011 17:06:01 +0200

До сада, радио сам само са тестовима, нисам заиста пробао апликацију. Најлакши начин да се покрене синатра апликација је користећи shotgun. Дакле:

$ git checkout -b proba
$ emacs Gemfile

И у њу додам:

gem 'shotgun'

Па $ bundle install

Да би покренуо апликацију:

$ shotgun blurgh.rb

И отворим http://localhost:9393/, али ту је грешка, јер нема setup.yaml фајла.

Направим setup.yaml са следећим садржајем:

title: Пази сад

Поново отворим страницу, и видим “Пази сад” у h1 таговима као што очекујем.

Да убацим садржај у гит:

$ git add Gemfile setup.yaml
$ git commit -m "апликација приказује странице"
$ git checkout master
$ git merge proba

Блог у синатри, епизода четврта

Tue, 29 Mar 2011 17:05:33 +0200

Пошто је ово систем за блог, било би пожељно да има начин како ће моћи да прикаже садржај.

Правим нови огранак:

$ git checkout -b views

Напишем следећи тест у blurgh_spec.rb:

context "the view" do
  it "should have a body html elements" do
    get '/'
    last_response.body.should match("")
  end
end

следеће:

$ mkdir views
$ emacs views/layout.erb

у који додам:


  
    <%= yield %>

у фајл views/index.erb ставим:

<%= @title %>

У главном програму додам следеће:

get '/' do
  @title = Config.title
  erb :index 
end

покренем тест и он прође.

Онда рад додам у гит:

$ git status
# On branch master
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   blurgh.rb
#   modified:   spec/blurgh_spec.rb
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#   views/
no changes added to commit (use "git add" and/or "git commit -a")

То ми говори да су измењена два фајла: blurgh.rb и spec/blurgh_spec.rb и додан views.

$ git add blurgh.rb spec/blurgh_spec.rb
asimic@byzantium:~/dev/blurgh2$ git add views/
asimic@byzantium:~/dev/blurgh2$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#   modified:   blurgh.rb
#   modified:   spec/blurgh_spec.rb
#   new file:   views/index.erb
#   new file:   views/layout.erb

Друго додавање у гиту: git add views/, намерно сам користио / на самом крају јер то онда дода гиту све фајлове у том директоријому.

И за крај:

$ git commit -m "додани views"
$ git checkout master
$ git merge views

Блог у синатри, епизода трећа

Sat, 26 Mar 2011 13:56:00 +0100

А шта ако setup.yaml нема title дефинисан? Или ако нема setup.yaml ништа у себи?

Отворим нови огранак:

$ git checkout -b extra_checks

и ту почнем да пишем тестове у spec/config_spec.rb:

context "when the title is blank" do
  it "should return nothing" do
    YAML.stub!(:load_file).with("setup.yaml").and_return({"title" => ""}) 
    Config.title.should match("")
  end
end

Пробам:

$ bundle exec rspec spec/config_spec.rb

Тест прође. Онда додам други:

context "when the title is missing" do
  it "should return nil" do
    YAML.stub!(:load_file).with("setup.yaml").and_return({}) 
    Config.title.should be_nil
  end
end

И он прође. Онда пробам све тестове заједно:

$ bundle exec rake

Config
  .title
    should return value
  when the title is blank
    should return nothing
  when the title is missing
    should return nil

blurgh
  should respond to /
  should have a title

Finished in 0.01154 seconds
5 examples, 0 failures

Сви пролазе. Онда додам напредак у гит и све ставим у главно стабло:

$ git add spec/config_spec.rb
$ git commit -m "још тестова за Config.title" 
$ git checkout master
$ git merge extra_checks

Блог у синатри, епизода друга

Fri, 25 Mar 2011 17:54:00 +0100

Да би додали нешто ново, пожељно је да се направи нови огранак (branch) у гиту:

$ git checkout -b config_file    
$ git branch
* config_file
  master

Са задњом сам направио нови огранак и наместио њега као тренутно место у гиту где ће ићи сав нов рад.

Овај систем ће читати своју конфигурацију из setup.yaml фајла, чији формат ће изгледати овако:

title: Име мог блога
store: posts

Title ће бити сам наслов, suffix је завршни део назива фајлова, у овом случају у Markdown формату и store означава где ће се фајлови стављати.

Тако да када будем отишао на почетну страну ја требам да видим наслов или назив. То треба да се подеси у тесту:

it "should have a title" do
  get '/'
  last_response.body.should match("Naslov")
end

И ако покренем тестирање:

$ bundle exec rake

следећа грешка се појављује:

Failures:

  1) blurgh should have a title
     Failure/Error: last_response.body.should match("Naslov")
       expected "" to match "Naslov"
     # ./spec/blurgh_spec.rb:16:in `block (2 levels) in '

Да би то решио, ‘/’ адреса треба да испише наслов који ће да добије из фајла у YAML формату.

Пошто ништа не чита тај фајл, направићу модул који га чита. Али прво да кренем са тестом:

emacs spec/config_spec.rb

И ту опишем како би да се понаша тај модул:

require 'spec_helper'

describe "Config" do

  describe ".title" do
    it "should return value" do
      Config.title.should match("Naslov")
    end
  end

end

Ту означим да метода title ће вратити вредност дефинисану у фајлу, у овом случају то ће бити “Naslov”.

Онда напишем Config модул у blurgh.rb:

module Config
  def self.title
    options["title"]
  end

  private
  def self.options
    YAML.load_file("setup.yaml")
  end
end

где приватна метода options чита YAML конфигурацију. Модул се

Да би могао да читам YAML формат, додам:

require 'yaml'

Вратим се тесту, покренем га, он не ради:

 Failure/Error: Config.title.should match("Naslov")
 Errno::ENOENT:
   No such file or directory - setup.yaml

То је зато што тај фајл и не постоји. Зато требa да се створи “лажни” фајл:

YAML.stub!(:load_file).with("setup.yaml").and_return({"title" => "Naslov"})

stub је део RSpec-а и он намести да метода врати пожељне резултате. У овом случају намести да YAML врати учитан фајл setup.yaml са садржајем “title: Naslov”.

Ако погледате пажљиво, видећете да он у ствари не вараћа

"title: Naslov"

већ Hash са садржајем:

"title" => "Naslov"

То је зато што у овом случају ја желим да YAML објекат врати што “реалнији” резултат. Шта то значи? Када YAML учита неки фајл, он учита вредности из њега и стави их у Hash. А пошто ја овде хоћу да наместим YAML да ми врати пожељне вредности, ја их сам попуним.

Сада да пробам само задњи тест:

$ bundle exec rspec spec/config_spec.rb

Он прође.

Сада се вратим на првобитни тест у spec/blurgh_spec.rb и додам у it “should have a title” do:

YAML.stub!(:load_file).with("setup.yaml").and_return({"title" => "Naslov"})

покренем

$ bundle exec rake

и опет тест за наслов пада. То је зато што ништа се не враћа из главне синатрине методе. Да би то исправио додам следеће:

Config.title

покренем

$ bundle exec rake

И уместо да сви тестови прођу, први пада. То је првобитни тест, зато што он не може да нађе setup.yaml фајл. Да би то исправио, убацим следећи блок:

before :all do
  YAML.stub!(:load_file).with("setup.yaml").and_return({"title" => "Naslov"})     
end

Али тада само први тест прође, други пада. Ако изменим блок у before :each, онда сваки тест у blurgh_spec добије “лажни” фајл, то јест stub setup.yaml фајла:

require 'spec_helper'

describe "blurgh" do

  before :each do
    YAML.stub!(:load_file).with("setup.yaml").and_return({"title" => "Naslov"})     
  end

  def app
    @app ||= Sinatra::Application
  end

  it "should respond to /" do
    get '/'
    last_response.should be_ok
  end

  it "should have a title" do
    get '/'
    last_response.body.should match("Naslov")
  end

end


$ bundle exec rake

Config
  .title
    should return value

blurgh
  should respond to /
  should have a title

Finished in 0.01046 seconds
3 examples, 0 failures

После овог напредка, додам то у гит. Прво да видим статус:

$ git status
# On branch config_file
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   blurgh.rb
#   modified:   spec/blurgh_spec.rb
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#   spec/config_spec.rb
no changes added to commit (use "git add" and/or "git commit -a")

Што значи да blurgh.rb и spec/blurgh_spec.rb су измењене а spec/config_spec.rb је нови фајл.

Све промене додам гит (у два корака):

$ git add blurgh.rb spec/blurgh_spec.rb spec/config_spec.rb
$ git status
# On branch config_file
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#   modified:   blurgh.rb
#   modified:   spec/blurgh_spec.rb
#   new file:   spec/config_spec.rb
$ git commit -m "додан нови модул Config"

Погледао сам статус гита, чисто да видим да ли је све тачно унешено.

Тренутно сам и даље на огранку config_file, да потврдим:

$ git branch
\* config_file
  master

Да би унео нови део напредка у главно стабло гита, требам да се пребацим у њега и да упишем нове рад. То радим овако:

$ git checkout master
Switched to branch 'master'

$ git merge config_file
Updating b740f6e..b95240c
Fast-forward
 blurgh.rb           |   13 +++++++++++++
 spec/blurgh_spec.rb |   12 +++++++++++-
 spec/config_spec.rb |   12 ++++++++++++
 3 files changed, 36 insertions(+), 1 deletions(-)
 create mode 100644 spec/config_spec.rb

Блог систем у синатри, епизода прва

Wed, 23 Mar 2011 15:27:00 +0100

Идеја овог чланка је писање апликације у синатри, са тестирањем и гитом. Предходно знање ових технологија/апликација није потребно.

Блог систем треба да има YAML фајл у коме се убаци наслов, и место где ће да се држе чланци.

Од самог почетка користићу тестирање:

$ mkdir blurgh
$ cd blurgh 
$ emacs Gemfile

и додам:

source 'http://rubygems.org'

gem 'sinatra'
gem 'rack-test'
gem 'rspec'
gem 'rake'

онда инсталирам:

$ gem install -r bundle 
$ bundle install

Да би омогућио да RSpec функционше, требам да направим следеће фајлове:

$ mkdir spec
$ emacs spec/spec_helper.rb

И додам следеће:

require File.join(File.dirname(__FILE__), '..', 'blurgh')

require 'sinatra'
require 'rack/test'
require 'rspec'


# set test environment
set :environment, :test
set :run, false
set :raise_errors, true
set :logging, false


RSpec.configure do |c|
  c.include Rack::Test::Methods
end

Кључни део овде је додавање: Rack::Test::Methods. То омогућава тестирање уз помоћ rack.

Онда направим први тест:

$ emacs spec/blurgh_spec.rb

и напишем први тест:

require 'spec_helper'

describe "blurgh" do

  def app
    @app ||= Sinatra::Application
  end

  it "should respond to /" do
    get '/'
    last_response.should be_ok
  end
end

да покренем тај тест:

$ bundle exec rspec spec/blurgh_spec.rb

он наравно неће да прође јер још увек нема главне апликације, зато

$ emacs blurgh.rb

и додам следеће:

#!/usr/bin/env ruby

require 'sinatra'

get '/' do
end

поново покренем тестирање:

$ bundle exec rspec spec/blurgh_spec.rb

и избаци следеће резултате:

$ bundle exec rspec spec/blurgh_spec.rb 
.

Finished in 0.01479 seconds
1 example, 0 failures

да би то било мало разговетније, покренем тестирање са “документационом” опцијом и бојом, овако:

$ bundle exec rspec -f doc --colour spec/blurgh_spec.rb 

blurgh
  should respond to /

Finished in 0.01517 seconds
1 example, 0 failures

То је добар почетак, и то ћу да убацим у гит:

$ git init
$ emacs .gitignore

и ту ставим следеће:

Gemfile.lock

## Mac OS
.DS_Store

## Textmate
*.tmproj
tmtags

## Emacs
*~
\#*
.\#*

## Vim
*.swp

додам фајлове у гит:

$ git add .
$ git status

који врати следеће:

# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached ..." to unstage)
#
#   new file:   .gitignore
#   new file:   Gemfile
#   new file:   blurgh.rb
#   new file:   spec/blurgh_spec.rb
#   new file:   spec/spec_helper.rb
#

онда упишем те промене фајлове:

$ git commit -m "сам почетак"

што испише следеће резултате

[master (root-commit) ea5dd64] сам почетак
 5 files changed, 58 insertions(+), 0 deletions(-)
 create mode 100644 .gitignore
 create mode 100644 Gemfile
 create mode 100755 blurgh.rb
 create mode 100644 spec/blurgh_spec.rb
 create mode 100644 spec/spec_helper.rb

Али пошто је то досадно да се стално куца, користићу rake да то аутоматизујем:

$ emacs Rakefile

у коју додам ово:

require 'rspec/core/rake_task'

RSpec::Core::RakeTask.new do |t|
  t.rspec_opts = ["-r ./spec/spec_helper.rb"]
  t.pattern = 'spec/**/*_spec.rb'
end

то омогућује RSpec да покреће тестове када се укуца:

$ bundle exec rake spec

Али пошто ће то бити честа радња, да омогућим да куцам што мање, додајем и ово:

task :default => "spec"

Тако да могу да укуцам само:

$ bundle exec rake

Да би имао боју и опис тестова, отворим нови фајл .rspec и у њега убацим:

--colour --format doc

Сада резултат изгледа боље:

$ bundle exec rake 

blurgh
  should respond to /

Finished in 0.0092 seconds
1 example, 0 failures

То сада може да се дода у гит:

$ git status

ми покаже који су нови фајлови које могу да додам:

$ git add Rakefile .rspec
$ git commit -m "додајем Rakefile и .rspec"

Опис књиге: Rails 3 in Action

Sun, 20 Mar 2011 01:05:00 +0100

Књиге које описују неку тренутну технологију или “алат” брзо остаре и њихов значај губи смисао, зато што касни за технологијом коју описује. Није много другачије што се тиче “Шина” (или ти Rails). Штавише, мислим да су књиге које описују Rails, кад се издају, већ “бајате” и говоре о томе како се радило јуче.

“Rails 3 in Action” покушава да то мало измени, тако што почиње да учи читаоца како се ради са Rails-ом почевши са методологијама где се пишу тестови прво, па тек онда сам програм. За то је аутор књиге изабрао Cucumber и RSpec. Све то је праћено коришћењем Git система за одржавање кода.

Аутор то ради тако што да мали увод у све технологије, али да би то најбоље дочарао прави апликацију и објашњава кораке. На тај начин доступа читаоцу не само да види како се тренутно пишу апликације са тестирањем, него како и он сам ради.

Моје разумевање “краставца” је да он треба да опише систем. Технологија коју он тестира може да се замени а да features и steps (делови који сачињавају краставац) могу да остану идентични. Начин на који аутор то приказује, није могуће. Модели скоро да нису тестирани, али зато контролери јесу.

Књига наводи два аутора: Јехуду Кетца и Рајана А. Бига. Али заправо Рајан је пише сам. Но то не значи ништа негативно, књига служи као добра референца.

Други разлог зашто наводим ауторе је JavaScript, и баш специфично jQuery. Иако је Јехуда један од главних програмера на Rails и jQuery пројектима (или барем је био до издања Rails верзије 3), jQuery се и не помиње. Има један део где се говори о Prototype, али то је само мали пример.

Да ли бих препоручио ову књигу? Моје мишљење је да не постоји један извор информација, без обзира на област. Тако да сматрам да је књига само још један начин на који можете видети нови приступ. Ја сам купио ову књигу, у MEAP* издању, и неки пут погледам како је аутор радио или применио нешто. Али читање блогова и праћење пројекта, не само Rails, већ Cucumber, RSpec и других је потребно. Али ако нисте пре користили Rails, и желите да научите како да развијате пројекат тако што пишете прво тестове па програм, књига је добар увод.

Rails 3 In Action - издавачева страница

Пројекат коришћен у књизи се налази овде на github-у.

* MEAP - електронско издање, где се добија приступ књизи док се још пише, поглавље по поглавље (Manning Early Access Program)

(текст је преправљан 13. априла 2011)

Tri saveta Rubi početniku

Tue, 13 Apr 2010 17:55:33 +0200

Pratim prilično redovno pitanja sa Ruby tagom na StackOverflow, i primetio sam da se dobar deo pitanja vezanih za Ruby kao jezik vrti oko načina za manipulaciju podacima smeštenim u osnovne Rubi strukture podataka - često postavljač pitanja okači svoje “naivno” parče koda i pita kako bi izgledalo “elegantnije” ili “rubističkije” rešenje.

S tim u vezi, evo par saveta za Rubi početnika koji želi da što pre prevaziđe ovakva pitanja, koja se zapravo svode na pisanje Java ili PHP koda u Rubiju:

Naučite jako dobro čemu služe i kako rade metode Enumerable#map i Enumerable#inject!
Prođite nekoliko puta kroz dokumentaciju za Enumerable, Array i Hash, pažljivo pročitajte koje metode nude i koje sve oblike te metode mogu da uzmu (neke primaju opcioni blok itd).
Naučite šta su blokovi. Naučite u čemu se razlikuju od funkcija, kako se prosleđuju i pozivaju iz metoda. Naučite pojam closures.

Postoji još nekoliko “alata” koje Rubiju daju prednost nad “običnim” jezicima, ali se za početak zadržite na ove tri stavke, dok ih ne usvojite u potpunosti.

Hacking a subselect in ActiveRecord

Mon, 08 Mar 2010 23:57:35 +0100

Hacking a subselect in ActiveRecord :

U našoj Rails aplikaciji imamo jedan prilično nezgodan problem, o kome sam već pisao na DPT-u. Ukratko, treba mi broj slogova koji vraća SQL upit grupisan po nekoliko polja (videti primer na DPT-u). S obzirom da se ovo koristi iz Rails aplikacije korišćenjem ActiveRecord-a, nije moguće (barem u to doba nije bilo) izvršiti upit korišćenjem podupita, tj. nije moguće izvesti nešto ovako:

SELECT COUNT(*) FROM
(SELECT 1 FROM tabela GROUP BY a, b) t

Pomoću uputstva na linkovanom članku ovo je ipak moguće izvesti, doduše malim hakovanjem pozivanjem privatne metode na ActiveRecord::Base klasi. Ona generiše SQL string koji posle koristimo kao vrednost parametra :from u upitu koji vraća COUNT, nešto ovako:

count_sql = Model.send(:construct_finder_sql, :select => 1, :group => 'a, b')
Model.count(:from => "(#{count_sql}) a")

Izgleda da radi. ;)

Je li f()==5 i 5==f() isto?

Sun, 07 Feb 2010 23:41:47 +0100

Vi koji ste radili sa C-olikim jezicima setićete se jedne od konvencija pri pisanju if-uslova, da se vrednost sa kojom se promenljiva poredi piše sa leve strane znaka jednakosti, a promenljiva s desne (if 5 == i naspram uobičajenog if i == 5), zbog česte greške da se umesto dvostrukog znaka jednakosti stavi jednostruki, i odradi dodela vrednosti promenljivoj s leve strane, za šta se neki kompajleri ne bi bunili.

Samo naoko sličan problem javlja se ponekad i u Rubiju, ali ne zbog moguće greške u kucanju, već zbog prirode znaka jednakosti.

Analizirajući performanse jedne skripte profajlerom, primetio sam da se u listi pozivanih metoda neočekivano javlja metoda Time#<=> (koja opet, iz ko zna kog razloga, zove BasicObject#method_missing), iako sam bio prilično siguran da u kodu nemam poređenje objekata klase Time. Detaljnijim pregledom shvatio sam da se poziv te metode javlja pri proveri rezultata jedne metode, tj. u otprilike ovakvom koodu:

return if m() == false

(Pre nego što počnete prozivku zbog onog == false, reći ću da mi je bila potrebna eksplicitna provera za false, tj. nisam hteo da mi se uslov ispuni ako je rezultat metode nil, već samo false.)

Ispostavilo se da metoda m u nekim slučajevima vraća objekat klase Time. (Ok, još malo pravdanja: metoda m je zapravo metoda send na jednom objektu, i može zapravo pozivati različite metode, otud nije baš uvek izvesno šta će se naći kao vraćena klasa.) S obzirom da je u Rubiju manje-više sve ili objekat ili poziv metode nekog objekta, ono == je takođe poziv metode. U slučaju klase Time, ovaj operator ne vrši jednostavno poređenje referenci, pa se usled toga == kome je poziv metode sa leve strane različito ponaša od onog gde je sa leve strane npr. false. Ok, da ne grešim dušu, kood se ponaša isto, ali se izvršava različitom brzinom, što opet nekad može da bude bitno.

Da bi se izbegla nepotrebna logika vezana za konkretnu implementaciju metode == levog objekta, dovoljno je promeniti redosled:

return if false == m()

false je u Rubiju instanca klase FalseClass, i njeno == je isto što i obično Object#==, odnosno jednostavna provera jesu li u pitanju isti objekti.