sábado, 27 de julio de 2013

How to write user stories rspec and cucumber

First of all, what we need to know what are the components of a story, well, there are: a title, a narrative and acceptance criteria
Cucumber
In cucumber you have to write features so:
First you have to create a file with the extension .feature
In there you keep this format:
Feature: Name of the feature
   As a ….
   I want to ….
   So I can …
Note: you can also do it just writing a paragraph explaining what is that feature about.
After that you need to write the Scenarios, so basically the format is:
Scenario: name of the scenario
    Given ……
    When  ...….
    Then …….
And where the points are you just replace for text where you explain what is going to happen. For example in The RSpec book in the first part they make a code braker game so the first feature and scenario that they describe is starts game and they do it like this:
Feature: code-breaker starts game

  As a code-breaker
  I want to start a game
  So that I can break the code

  Scenario: start game
    Given I am not yet playing
    When I start a new game
    Then I should see "Welcome to Codebreaker!"
    And I should see "Enter guess:"

After writing our feature now we need to write the steps, because if we run our feature like that it will give us some warnings and errors. So we write our steps in another file called   xxx_steps.rb like this:
Given /^I am not yet playing$/ do
end

When /^I start a new game$/ do
  game = Codebreaker::Game.new(output)
  game.start('1234')
end

Then /^I should see "([^"]*)"$/ do |message|
  output.messages.should include(message)
end

Where basically if you can notice the format is just
Given/When or Then followed by /^What we write in the scenario$/  do
call the methods
end

So with that we’re done with cucumber.
Let’s see how we do it in rspec, here what we do is describe:
describe "class name" do
    describe "what I’m testing" do
      context "which is the case" do
        it "what it does" do
          marker = Marker.new('1234','5555')
          #"also if I add  pending "What it's pending"" (so in this way the line after pending is not run)
          marker.exact_match_count.should == 0
        end
      end

     describe "what I’m testing" do
      context "which is the case" do
        it "what it does" do
          marker = Marker.new('1234','5555')
          #"Also if I add pending "What it's pending""
          marker.exact_match_count.should == 0
        end
      end
                .
                .
                .
     end
                .
                .
                .
     describe "what I’m testing" do
      context "which is the case" do
        it "what it does" do
          marker = Marker.new('1234','5555')
          #"Also if I add pending "What it's pending""
          marker.exact_match_count.should == 0
        end
      end
     end
end

So in that way after we describe each scenario and all if we run the spec everything just says that things are not yet implemented, we are ready to the next step that is write the logic.

Bibliography



Chelimsky, D. (2010). The RSpec Book. The Pragmatic Bookshelf.

viernes, 26 de julio de 2013

Ruby learnings

Well in this post I'm going to show some simple examples to start with ruby. These are a really simple examples and this post is oriented to people with any experience in ruby. Also I'll be posting more examples in a while but there will be in git I'll put the link at the end of the post.

So, basically I'm going to show you how to make a class and into it there are going to be some examples in ruby, like factorial function, the first hello, find out if a number is prime and given an array with names print those that start with a determined letter.

Here is the complete code:

_________________________________________________________________________________

class Examples

  def initialize
    @people = ["Carlos","Maria", "Juan", "Sonia", "Sandra" ]

  end

  def call_examples
    hello_ruby
    print "The result of 5! is #{factorial(5)} \n"
    print "Is 7 prime? #{ is_prime_number?(7)} \n"
    print "Is 16 prime? #{ is_prime_number?(16)} \n"
    starts_with?("S")
  end

  def hello_ruby
    print "First hello in ruby!!\n"
  end

  def factorial(number)
    result = 1
    if number > 0
      result = number * factorial(number - 1)
    else
      result = result * 1
    end
    return result
  end

  def is_prime_number?(number)
    divisor = 2
    if number == 2
      return true
    end
    while divisor < number
      if number%divisor == 0 and not number == divisor
        return false
      end
      divisor += 1
    end
    return true
  end

  def starts_with?(letter)
    @people.each {|x| match?(letter, x)}
  end

  def match?(letter,name)
    if name.start_with?(letter)
      print "#{name} starts with #{letter} \n"
    end
  end

end
example = Examples.new
example.call_examples
_________________________________________________________________________________

Let's see each method:


def hello_ruby
    print "First hello in ruby!!\n"
end 

This one is the first example that everybody learn when starting a new language, so it is very simple. The command print just put what you want into the console. You can change the things between "".


 def factorial(number)
    result = 1
    if number > 0
      result = number * factorial(number - 1)
    else
      result = result * 1
    end
    return result
  end

Factorial, factorial function is about multiply the given number by its predecessor until it is 0.
So for example if we have 7! we should do 7*6*5*4*3*2*1*1, the last one is because when the number is zero the result is 1.


def is_prime_number?(number)
    divisor = 2
    if number == 2
      return true
    end
    while divisor < number
      if number%divisor == 0 and not number == divisor 
        return false
      end
      divisor += 1
    end
    return true
  end

This function as its name says it tells us if a number is prime. The important part of this method is the while cycle, where I search for the modulo of the number%divisor because if it is equal to 0 the number is not prime.


def starts_with?(letter)
    @people.each {|x| match?(letter, x)}
  end

  def match?(letter,name)
    if name.start_with?(letter)
      print "#{name} starts with #{letter} \n"
    end
  end

And this last example is about using an array, what I do is to compare each first letter of each element of the array with a given letter if the element starts with the letter it will be printed.

Note: This is the link to github in https://github.com/fernandacoto/Ruby_Examples , in that repository I hope to continue updating examples each time more complex.





Behavior Driven Development(BDD)

BDD was developed by Dan North and according to The RSpec book BDD “is about implementing an application by describing its behavior from the perspective of its stakeholders.”  It is based on TDD or Test Driven Development. And one of the purposes of BDD is to understand the problem from the point of view of the stakeholders, so in this way we will write software that matter, software that satisfies our client expectation.
There are 3 principles of BDD:
  1. Enough is enough: This is all about doing what we have to do and anything else, because it could be a waste of effort.
  2. Deliver stakeholder value: Everything should produce value, if it doesn’t produce it, don’t do it
  3. It’s all behavior: This is because BDD focus on behavior instead of structure.

     So I can say that the main purpose of BDD is to minimize the communication’s problems that are in almost every project. In BDD exists a triad that includes the words: Given, When and Then.

BDD consists of writing stories and derivate these stories into scenarios.  For example in the book that I mentioned earlier they explain that there is a cycle in BDD which is:

Basically following this cycle we will be applying correctly BDD. In another post I’m going to show how to write user stories and scenarios.

Bibliography

Chelimsky, D. (2010). The RSpec Book. The Pragmatic Bookshelf.


What is clean code?

This question should have so many answers if you ask it to different people. For example in the Clean Code book, there are so many answers in the first chapter, and some of them are:
  •  “Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control”(Grady Booch)
  • “You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem”( Ward Cunningham)

     For me what is clean code is not an easy answer. After start reading Clean Code book, right now I understand that clean code is more than just a program that runs correctly. Clean code is a code that you can read as it was a history, that has meaningful names in variables, classes, methods. Also clean code is code that is well structured, that does not have any duplication.

     Moreover clean code is code where classes and methods are small and explain what they do in its easiest form without any comment. But, for me also after been here in Pernix, I’ve learned that clean code also have tests, where there are a really important thing to make a great application. Clean code is also efficient, focused, and people are not afraid to modify it.  On the other hand, I can tell that clean code also is about to use right the principles and patterns that exist. Because in the end, that is why patterns and principles exist; applying all these things together make clean code.

Bibliography


Martin, R. C. (2009). Clean Code. Prentice Hall.

lunes, 22 de julio de 2013

GIT Branching


This post is going to be an example that my tutor in Pernix showed me about how is that git branching, merge and rebase work.

Basically, this is used when there is more than one person working in a project, and everybody have to work in different things. What I'm going to show is that I have a repository with some files so i'm going to do 2 “copies” of that repository in which I will work, and make different changes,then I will merge everything in the master branch and delete the branches I've created. What is the idea with this, since there are so much people working on the same files, probably the all of them are not going to have the latest release or latest changes, that a coworker did, so with this we are able to have everything up to date, without the problem of having different things in the files that we are having as base.

Let's start:
  1. First we are going to see the branches that we have, that can be done with the command: git branch -a.
  2. Now I'm going to do a branch where I'm going to do some changes to the files. The creation of the branch is done with the command git checkout -b BranchTest1
  3. After that we type again the command git branch -a and and it should appear the list of repositories we have.
  4. The command to change the branch in which we are is git checkout master (in this case master is the name of the branch but if we are on the master we also can say git checkout BranchTest1), so let's change to the master branch
  5. Then we make a pull rebase to be sure that everything is up to date git pull --rebase origin master
  6. Now we need to be in the BranchTest1: git checkout BranchTest1
  7. Let's make a change in a file
  8. We need to verify the status of the files in the repository so we do it with the command git status, in my case that says that I modified a file
  9. Right now we need to add the file modified with the next commands in the order that they appear a) git add . b) git commit -m "primer commit branching" c) git push origin BranchTest1
  10. Pass to the master branch git checkout master
  11. Now create a new branch git checkout -b BranchTest2
  12. Modify a file and add it to git as in step 9
  13. Let's pass to master branch git checkout master
  14. Now we are going to merge the changes in BranchTest2 git merge BranchTest2
  15. Then we push it in the master branch: git push origin master
  16. After that we change to BranchTest1 git checkout BranchTest1
  17. And now we do a pull –rebase ,and here is the thing we were searching , we're gonna have a conflict git pull --rebase origin master
  18. Now go to the file that is showing us the conflict and solved it,the editor will show you where is the conflict
  19. Then add the file git add <Filename>
  20. Also we need to do git pull origin BranchTest1
  21. After we do git push origin BranchTest1
  22. Finally we do git pull --rebase origin master, git checkout master, git merge BranchTest1, git push origin master
  23. And delete the branches git branch -d BranchTest1 , git branch -d BranchTest2 git push origin :BranchTest1 git push origin :BranchTest2

domingo, 21 de julio de 2013

Week 3

Well this is the 3rd week, since I started the apprenticeship program. So far, I’ve learned to program in Ruby, and also I have done a tic tac toe on it. I think that it has been a great time for me because I have learned so much. Comparing the first tic tact toe that I sent to enter into this, with the one I finished the last Monday, it is a huge improvement (I have to say that it has so much to do in things about refactoring, and also maybe improve the names, but that’s difficult when you’re starting), at the end of the post I will attach the link to git, where the code is.

Moreover, I did my first gem, so exciting! In the beginning I was kind of stressed because it did not work, but at the end checking with a friend that is also in this program, we figure it out that the problem was a capital letter (huh  :-S). I’m going to add the gem to github too, for all the people that like me at the beginning did not know how to do a gem. Also, they explained me about the Presenter-Interactor-Repository and Screamming Architecture, so I’m going to write the main ideas of these. About the second one, it is that the architecture must reflect what problem it is been solved, it is like to not adapt a problem to an architecture, instead of that  we should create an architecture that satisfy the problem.
And the Presenter-Interactor-Repository pattern  is because ruby is based on MVC or model view controller, but because we have to remove dependencies, is why are created the presenters, interactors and repository. Basically repository is the one that is in charge of the communication with database, so with that we do not need to worry about to be link to a specific database. The presenter is the one who removes the dependency between the controller and the view. And finally the interactor is the one who removes the dependency between the model and the controller.
On the other hand, I also have to read about git branching, and for me that is really confusing, so I need to do an example to understand it better. But the idea of branching is to have a branch (es) that contain the same as the master branch, so we will work on the branch created and after being sure that everything works fine make a merge or rebase to unify the branch created with the master. When I make an example I will post it, to make it clear.

Also, I did a tutorial about CSS from W3schools, it was really interesting, and helped me a lot. For example the different types to apply styles to a web page, also the tricks like how to format a table, the box model, display and other things. After that I also took the quiz, and I did  pretty good,  so now all I need is to put all I’ve learned from that in the practice.

Finally, I started reading the rspec book, that’s about rspec, cucumber, BDD and also talks about TDD. Right now I’m on chapter 19, and I stopped on that because from that chapter they talk about rails, and I don’t have any knowledge on it. This book started with an example of how to use rspec, cucumber making a code breaker. For me that is something unknown, so many files to do. But it is really interesting, the form in which they explain the cycle of how cucumber and rpec are related to build things. The idea is to have a cycle of red/green/refactoring in cucumber, making the scenarios and steps, after that we repeat the cycle but with now rspec, that there is where we specify the spec files. And finally when we have everything passing and the only mistakes that we have are the ones that are about logic we are ready to start writing the logic of the app that we are making. Also in the book they talk about the problems that people have with the projects they develop, exactly about the problems with communications, costs and others. It is important that every team work based on a contract, have a clear understanding about the requirements and the behavior that an application should have, how the changes at the beginning do not have so much impact on the scope of the project and the costs, but how risky and expensive is to make changes when the project is in an advance state. There is a lot to say about this book, they talk about many things, in the second part of the book for example they make an explanation about what is Rspec and cucumber, and talk about the structure, methods, syntax, etc, of each one.

domingo, 14 de julio de 2013

Week 2

This week I tried Clojure that programing language uses the Java Virtual Machine and it is a general-purpose language. This language is a dialect of Lisp. Basically what I did with this language was reading 2 chapters of Clojure that were about the installation of it and also a little bit about how it works. I checked a page that is a little tutorial about this language, too.
Additionally I read about SOLID principles, and Bryan also explained about it. So, what is SOLID? The meaning of each letter it’s going to be explained in a moment. The purpose of SOLID is that if we follow these principles we are going to have applications that are easy to extend and maintain.
Let’s see what that SOLID means:
S: Single Responsibility Principle
The main idea with this principle is that classes must have only one reason to change.
O: Open/Closed Principle
The general idea with it is that a class should be open for extension but closed for any changes (just bugs)
L: Liskovs Substitution Principle
This is about heritance. It says that a method takes determined class as an argument; it must be able to work with any subclass.
I: Interface Segregation Principle
It is about interfaces, that they should be small, because large interfaces make harder to extend smaller parts of the system.
D: Dependency Inversion Principle
“It states that you should let the caller create the dependencies instead of letting the class itself create the dependencies.”
Beyond these topics I also keep on with the Clean Code book, this time with chapters 3 and 10 that were about functions and classes respectively, the main things that I should stand out are:
  1. Functions should be small
  2. Blocks within if-else statements, while statements should be a line long
  3. The indent level of a function should be one or 2.
  4. Functions should do just one thing; they should tell us a clear story
  5. A level of abstraction per function.
  6. Also they mention in this chapter how important the names are
  7. A function should have the minimum amount of arguments
  8. Functions do either do something or answer something but not the two at the same time
  9. We should prefer return exceptions instead of error codes.
  10. A class should have one responsability
  11. Also it is important keep classes with higher cohesion.
  12. Apply the SRP.

Moreover, I watched 2 videos about test driven development, they were really interesting, and make clear why do we should apply TDD. In these videos it is remarked the importance of TDD and the main things are:
  • Expressiveness of code is needed in this way comments are not needed.
  • Be careful with spaces and indentation.
  • We must avoid the code rot, because it makes the code fragile, rigid and stationary
  • The people allow code rot because if they clean it they will break it.
  • Tests let you clean the code
  • TDD speeds development
  • We need to have control defects with TDD we can do, then there is no fear of making changes later
  • The test set must have a very small runtime
  • Uncle Bob mentioned 3 laws of TDD and these are:

            - write no production code except to pass a failing test
- write only enough of a test to demonstrate a failure
- write only enough production code to pass the test
  • Uncle Bob says that we must write tests before code.
  • Writing tests first makes the production code testable
  • Also with TDD you obtain a better design
  • TDD reduce debug time
  • TDD reduce documentation
  • TDD allows cleaning the code
  • To do well code we have to rework and refine it, it is not going to be perfect the first time.

domingo, 7 de julio de 2013

Week 1

Well this is my first week in the apprenticeship program; it has been kind of difficult  because I never thought that setting up the environment to start coding will cause that amount of errors. But before to get deeper into what have I done so far, I would like to tell you how I get into this program.

I’m a student of “computer engineering” that is more like "software engineering" in Tecnológico de Costa Rica. In my second year, I went to a exhibition where I heard about it, so since that moment I wanted to enter into this program. Now I’m going to start the last semester of my studies at college, and I have decided to do this. Let's see how it goes...

The first thing that I did was: set up the environment, so….
How to install RVM, Ruby, VIM, Bundler and git?
First of all, I’m using Ubuntu 11.10. Open the terminal and now we have to write the next commands on it.

RVM y git:
sudo apt-get install build-essential git-core
·         sudo apt-get install curl
·         bash –s stable <<(curl –s https://raw.github.com/wayneeseguin/rvm/binscripts/rvm-installer)
·         source /etc/profile.d/rvm.sh
·         echo ‘[[ -s “/home/name/.rvm/scripts/rvm” ]] && source “/home/name/.rvm/scripts/rvm” ‘ >> ~/.bashrc
Note: Remember to change name in the path above for your user name
·         source ~/.bashrc
·      To check that everything was installed correctly type: type rvm | head -1. It has to return you rvm is a function

Ruby:
·         rvm install 1.9.3
·         rvm use –default 1.9.3

VIM:
·         sudo apt-get install vim-gnome

Bundler
·         gem install bundler
·         bundle init
·         bundle install

Beyond the environment set up, I also have to start learning ruby, because this is my first time trying this programming language. So I took the little course to get started with ruby in tryruby.org, also I searched others tutorials (that I have not finished yet). On the other hand, some lectures and videos were assigned.
I read the chapters 1 and 2 of Clean Code book (if you’re interested on improving your way, and how to make better code that’s a perfect book). Basically, the lectures and video were about improving code and the main things that I think would be helpful are:

  •   Functions and classes should be small.
  •   The name of each variable, function, class, etc must be very descriptive about what it means or does.
  •   We need to avoid, and we must quit the duplication in our code.
  •   Refactoring, we need to keep in mind that concept.
  •   Classes must have only one responsibility.
  •   Functions must do one thing.
  •   It is better to have a code with descriptive names, than have a code that has comments.
  •   Also it is better that functions do not receive any argument.
  •   If we have to pass arguments to a function, try to keep the number of them at the minimum.
  •   Never pass a Boolean as an argument of a function, because Robert C. Martin says that’s a sign that the function is doing more than one thing.
  •  As we augment the number of arguments to pass in a function, we are making it harder to understand.
  •  Robert C. Martin also says that the length of the name of a variable, function or whatever in the code should be inversely proportional to the scope of this.
  •  It is good to practice TDD; it makes you improve the code.
  •  You can’t do everything in a time; have in mind that big things are reached by small steps.
  •  One thing at a time.
  •  Keep code clean.

What’s coming?
In the next post I’m going to talk a little bit about Clojure, SOLID, patterns. Also I started coding a Tic Tac Toe on Ruby and I’ll have to apply all I have learned so far, so when I finish it, I’ll post the link where you can find it.

Bibliography:
git. (n.d.). Retrieved july 2013, from git-scm.com: http://git-scm.com/book/en/Getting-Started-Installing-Git
Honsberg, A. (2012, May 8). Retrieved july 2013, from Install RVM ( Ruby Version Manager ) in Ubuntu 12.04 Linux for Ruby 1.9.3: http://www.andrehonsberg.com/article/install-rvm-ubuntu-1204-linux-for-ruby-193
MARTIN, R. C. ( 2008). Clean Code. PRENTICE-HALL INTERNATIONAL EDITION.
Martin, R. C. (2010, may). Retrieved july 2013, from http://www.infoq.com/presentations/Robert-C.-Martin-Bad-Code

Morin, M. (n.d.). Retrieved july 2013, from ruby.about.com: http://ruby.about.com/od/advancedruby/ss/Creating-And-Distributing-Gems-With-Bundler_2.htm