sábado, 28 de diciembre de 2013

Fourth week: This is real!!!

This week I worked on one project the majority of the time, because I took 2 days off. When we thought that the story was almost finished we found some bugs of earlier things, so we spent time fixing those errors. Also I made some tests of the story in which I was working on, and we found out that on IE much of the styles where not working ……

Well, also I spend a whole afternoon searching Spree extensions that will help us on the project , that was really exciting we found important extensions, so as my boss said, it is getting the form that we want, and if everything goes right it is gonna  be “easy”.


Finally, I continue with the apprenticeship program, I continue reading a book about patterns in ruby, so far is great. Also I finish the tic tac toe in ruby applying all the knowledge that I got after this time of being in this program and I made some tests to it using rspec by the way, I think that this one is a really improvement of what I did the first time, I know that there are always more things that I can do to it, so I just need to keep in touch with the code to make it better each time I learn something.

sábado, 21 de diciembre de 2013

Third week: Nothing to say, I think I’m getting better and really hope that

This week, well was kind of confusing in one of the projects, because we started to find others tools in which we also can make it. We searched and compared the one that we got recommended with new ones. Finally we continue with the first one. I also started thinking about how to replicate the site that we need to build on Spree. Also I meet Sebastian, a guy that is in charge of guiding us on design issues, he is in charge of make the design of the site. He is really important, he knows a lot.

On the other hand, I started a new story on the second project. This one is a little bit difficult I think, but let’s see how it goes.

sábado, 14 de diciembre de 2013

Second week: This is really amazing

Now I’ll be working the first 3 days on one project and the other 2 days on the other project. During that week I continue learning Spree, this time focused on layout customization. So right now I know how to change the design of a Spree application, I learned how to secure a site with a username and password and also had the weekly iteration meeting with the client. This time was really scary; I need to improve my communication skills.

On the other side, on the other project I had a great advance, I finished my first story, it was really comfortable after been stressed for not knowing ruby on rails, but I’m getting a clearer understanding of it right now.


Also I took a half day to write and get a better understanding of the stories that I’ll be working during the internship for college purposes, and I got a refresh of how to write user stories, and how to put it on the tools that I’ll be using.

sábado, 7 de diciembre de 2013

First week of full time job as a developer

Finally I started being a full time developer in Pernix before start my internship as part of my last semester at college. I was really worried of being asked for something that I don’t know, but during that week I learned that when I don’t know something, research first and then if there are not good results ask to somebody.

During that week we talked about the projects that I’ll be working on. Also start getting closer with rails. I researched about spree that is kind of cms/ store developed in RoR as part of one of the projects. So I set up the environment to work with that and also made a basic demo using Spree. Also I had my first meeting with a real client (really exciting), it was to get started with the project, it was a walk through the current site that they have and told us about their worries what do they want to improve.


Moreover, I also started with the second project, it was a walk through to know what was it, how it works and how the code was structured. Then we started a really frustrating part because we needed to set up the environment  for it, which took a really long time, because of the versions of the gems, rails and ruby that were needed, not to mention that we needed to mount a local server, it was really hard, but finally we got help from our tech lead and another guy that make it work. After all of that chaos I started my first story on the second project. I was really nice to know that I’ll be coding something real. What showed me that I really need to take my free time and learn rails, I don’t want to be lost on it.

martes, 8 de octubre de 2013

Experience in the last weeks

Well I’ve been apart from this blog in writing about how is going my experience, but that’s because I’ve been reading a lot and also learning about Webrick, Sinatra and Heroku. So I was programming a little blog in ruby but using just webrick, because in the program they said that I cannot use any gem and things like that, also that I had to use rspec to test it. This blog took me a while because I did not get it so fast, webrick is kind of confusing for me, and also there is not too much information about it. So, I’m still stuck in testing, cause in first instance I did not know about how to run the server in the background, now that someone explain me how to do that I can do it, so I just need to figure out, the format of the parameters. I did some tests to that blog but, to another class that I use, no to the one that process the requests, so I need to finish that. Rspec is kind of trouble with these things when you need a server, because if you need to do tests to another class that doesn’t need a server is easier.

        Moreover, since yesterday I started to learn about Sinatra and Heroku, to make another blog. This time, I feel that it is easier than is with Webrick. Because, you can find more help about Sinatra, also I said that I feel it easier, because I just started yesterday and, I did research, some examples using Sinatra as the Hello world, process parameters and also start my blog’s application and till now I can write a new post, list all the posts, and the other 2 functions edit and delete are in progress.
Also I finished the Clean code book and read Practical object oriented design in ruby book. These books gave me a lot of teachings. I’m actally planning to make a summary of all of my notes about the last book, but I need time to process all of them in a single article and then post it, hopefully I’m gonna do that when finish college.

       The apprenticeship program is a huge tool, where I’ve learned a lot of things, it is a great opportunity to learn how to do better code, and also learn how is the world of programmers. I’m so thankful, for being part of this program; it has made me grow as a person and also in this field of programming. 

viernes, 27 de septiembre de 2013

Dependency Inversion Principle

This is the last principle of the SOLID principles and what it states is:
“A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions.” (wikipedia)
This principle was stated by Robert C Martin. The main goal of this principle is decoupling.
Now as an example, let’s consider a “manager class which is a high level class, and the low level class Worker. We need to add a new module to our application because in the company there are some new specialized workers employed. We created a new class SuperWorker for this.”
“Let's assume that the Manager class is a complex one containing a very complex logic. And now we have to change it in order to introduce the new SuperWorker. Let's see the disadvantages:
we have to change the Manager class (remember it is a complex one and this will involve some time and effort). 
some present functionality from the manager class might be affected.
the unit testing should be redone.”
So, here is the code that violates the principle:
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;

public void setWorker(Worker w) {
m_worker=w;
}

public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}


And applying this principle we should obtain something like:

interface IWorker {
public void work();
}

class Worker implements IWorker{
public void work() {
// ....working
}
}

class SuperWorker  implements IWorker{
public void work() {
//.... working much more
}
}

class Manager {
IWorker m_worker;

public void setWorker(IWorker w) {
m_worker=w;
}

public void manage() {
m_worker.work();
}
}

Bibliography
OODesign.com. (n.d.). OODesign.com. Retrieved august 11, 2013, from http://www.oodesign.com/dependency-inversion-principle.html
wikipedia. (n.d.). wikipedia.org. Retrieved august 11, 2013, from http://en.wikipedia.org/wiki/Dependency_inversion_principle

viernes, 13 de septiembre de 2013

Interface Segregation Principle

This principle was postulated by Robert C Martin. It says that “no client should be forced to depend on methods it does not use” (wikipedia.org). But also in another site I found this other that I like much more “The ISP specifies that clients should not be forced to depend upon interfaces that they do not use. Instead, those interfaces should be minimised.” (Carr, 2011)
As an example of the violation of this principle we can have:

public class Contact
{
    public string Name { get; set; }
    public string Address { get; set; }
    public string EmailAddress { get; set; }
    public string Telephone { get; set; }
}

public class Emailer
{
    public void SendMessage(Contact contact, string subject, string body)
    {
        // Code to send email, using contact's email address and name
    }
}
  
public class Dialler
{
    public void MakeCall(Contact contact)
    {
        // Code to dial telephone number of contact
    }
}

But wait, why that this code violates the principle?? well the answer is that the classes Emailer and Dialler just need  some “attributes” of the class Contact, but they have access to all of them. And what we do is to hide the attributes or properties that are not needed for the classes.Doing that we got a consequence an violate another SOLID principle, but it represents clearly what  this principle means.
So, applying this principle we should get:

public interface IEmailable
{
    string Name { get; set; }
    string EmailAddress { get; set; }
}
public interface IDiallable
{
    string Telephone { get; set; }
}
public class Contact : IEmailable, IDiallable
{
    public string Name { get; set; }
    public string Address { get; set; }
    public string EmailAddress { get; set; }
    public string Telephone { get; set; }
}


public class MobileEngineer : IDiallable
{
    public string Name { get; set; }
    public string Vehicle { get; set; }
    public string Telephone { get; set; }
}

public class Emailer
{
    public void SendMessage(IEmailable target, string subject, string body)
    {
        // Code to send email, using target's email address and name
    }
}


public class Dialler
{
    public void MakeCall(IDiallable target)
    {
        // Code to dial telephone number of target
    }
}


Bibliography
Carr, R. (2011, january). blackwasp.co.uk. Retrieved august 11, 2013, from http://www.blackwasp.co.uk/ISP.aspx
wikipedia.org. (n.d.). wikiperia.org. Retrieved august 11, 2013, from http://en.wikipedia.org/wiki/Interface_segregation_principle

viernes, 6 de septiembre de 2013

Liskov´s Substitution principle

What this principle states is that “in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S without altering any of the desirable properties of that program”. The principle was first introduced by Barbara Liskov.
The principle imposes some requirements that are:
Contravariance of method arguments in the subtype.
Covariance of return types in the subtype.
No new exceptions should be thrown by methods of the subtype, except where those exceptions are themselves subtypes of exceptions thrown by the methods of the supertype (wikipedia)
Also I have to say that in the 11th video of the clean code they talk about this principle and say important things like:
The representative rule: it says that representatives don’t share the relationships of the things they represent.
Inheritance brings rigidity
One of the possible solutions in problems with violation to the Liskov´s Substitution principle could be apply the adapter pattern.
Moreover there are some heuristics:
If the base class do something the derive class must do it too.
Violation: A derive  function is written to unconditional throws an exception.
Violation: The presence of “if instance of” statement.
As an example I’m going to reproduce the example showed by Uncle Bob in the video of clean code. The example consists of a program that uses the class rectangle but then there is a new requirement that makes implement the square class, and as all of we know a square is a type of rectangle. But what happens is that sometimes we don’t know what type of object will be returned.

//Violation
class Rectangle
{
protected int width;
protected int height;

public void setWidth(int width){
width = width;
}

public void setHeight(int height){
height = height;
}
public int getWidth(){
return width;
}
public int getHeight(){
return height;
}
public int getArea(){
return width * height;
}
}

class Square extends Rectangle 
{
public void setWidth(int width){
width = width;
height = width;
}
public void setHeight(int height){
width = height;
height = height;
}
}

/*Applying the Liskov´s substitution principle, what we can do is making a class square that does not extend the rectangle class. And we can do that because as Uncle Bob says a square is a type of rectangle but the class rectangle is not a rectangle is a bunch of methods that represents the behavior of a rectangle.*/

class Rectangle
{
protected int m_width;
protected int m_height;

public void setWidth(int width){
m_width = width;
}

public void setHeight(int height){
m_height = height;
}
public int getWidth(){
return m_width;
}
public int getHeight(){
return m_height;
}
public int getArea(){
return m_width * m_height;
}
public int getPerimeter(){
return (2 *m_width ) + (2 * m_height);
}
}

class Square 
{
protected int side;
public void setSide(int side){
side = side;
}
public void getSide(){
return  side;
}
public int getArea(){
return side * side;
}
public int getPerimeter(){
return 4* side;
}
}
Bibliography
wikipedia. (n.d.). wikipedia.org. Retrieved august 11, 2013, from http://en.wikipedia.org/wiki/Liskov_substitution_principle

jueves, 22 de agosto de 2013

Open Close Principle

The father of this principle is Bertrand Meyer, this principle was first presented in Bertrand’s Book Object Oriented Software Construction. What this principle states is that a module or class should be open for extension, but close for modification. But how’s that possible, what do we should understand for extension and close.

Extension: It should be easy to change the behavior of that class or module.
Close: Source code should not change.

The main benefits of use this principle is:
Help with the maintenance of code.
Clearer code

As an example of the violation of this principle we can consider a class that is in charge of drawing different shapes, it should be clear that this violates this principle because each time we want to add a new shape we have to modify the code.

Code Violating the OCP

class ShapeEditor{
       public void drawshape(Shape  shape){
               if (shape.type == 1)
                   drawtriangle(shape);
               else
                    if (shape.type == 2)
                        drawcircle(shape);
}
         public void drawcircle(Circle circle) {....}
         public void drawtriangle(Rectangle rectangle) {....}
}

class Shape{
        int type;
}

class Triangle extends Shape {
         triangle() {
             super. type=1;
                        }
 }

class Circle extends Shape {
      circle() {
           super. type=2;
                }
 }

A possible solution could be:

class ShapeEditor {
  public void drawShape(Shape shape) {
  shape.draw();
  }
 }

 class Shape {
  abstract void draw();
 }

 class Triangle extends Shape  {
  public void draw() {
  // draw the triangle
  }
 }
class Circle extends Shape  {
  public void draw() {
  // draw the circle
  }
 }

jueves, 8 de agosto de 2013

Single Responsability Principle

This term was first introduced by Robert C. Martin, the author of the Clean Code Book. And what he wants to teach us is that a class must have only one responsibility. But wait!!, what  is a responsibility? Well Robert C Martin says that a responsibility is a reason to change.
The advantages of applying the SRP in our work are:  
We are going to obtain classes more robust and focused.
Code complexity is reduced.
Readability
Clearer code

As an example we can consider a system of a company in which there is a class that has methods that deal with business rules, reports and also the database (the example showed by Uncle Bob in the video of Clean Code):

public class Employee{
         public Money calculatePay(){…}
         public String reportHours(){…}
         public void save(){…}
}

As we can see here is violated the SRP because  calculatePay() will change whenever the business rules change for calculate the salary. In reportHours(), the case for change is when someone wants a different format to do a report. And finally save()  will change when the schema of the DB changes.
So how do we fix that, and fulfill this principle?
Well, we have to split this into different classes, in this case 3 because the class below has 3 reasons to change as I explained earlier. So the result could be:

public class Employee{
         public Money calculatePay(){…}
}

public class EmployeeReport{
         public String reportHours(Employee e){…}
}

public class EmployeeStore{
         public void save(Employee e){…}
}

domingo, 4 de agosto de 2013

Clojure learnings

Well this post as the title says it’s going to be about clojure. Clojure is a functional programming language and it is a dialect of lisp. In this language every expression goes into parenthesis. And its syntax is kind of different because here for example to do add number you have to write ( + 2 3), or if you want to know the length of a vector you have to do (count vector) instead of vector.length as you do it in ruby.  I’m starting with this programming language, it is completely new for me, and it is very interesting.
Now I’m going to show you some simple examples to get started with Clojure.
Well let’s start with hello world:
If you do it directly from console you can write: print “Hello World”
But if we do it making a function, we can write:

(defn hello [] "Hello World")

and then just call it from console like this: (hello)
Also from what I’ve been doing I can tell that if you have to define a global variable, you have to make it an atom. So for example in the next example I did a function that counts the number of elements of a vector, but first I defined the vector.

(def example_array (atom (vector 1 2 3 4 5)))
(defn largo []
  (count  @example_array))

Other of the examples that I did was to insert an element into a vector, so in the next function I call the function with the number that I want to add to the vector.

(def example_array (atom (vector 1 2 3 4 5)))
(defn insert [arr number]
  (conj arr number))

Another thing, was trying to do the factorial function I made a try, but when I was testing it, I found that if I give number greater than 29 it says integer overflow, I’m still figuring out, but it is a good start I think.

;; for numbers < 30
(defn factorial [number]
  (if (<= number 1)
    1 (* numeber (factorial (- number 1)))))

And also, I have to tell you that comments in Clojure start with “;;”
The next function prints the numbers from 10 to 1.

(def a (atom 10))
(while (pos? @a) (do (println @a) (swap! a dec)))

Also I made a function which you give it a vector and its length, and it prints a vector with the odd numbers.

(defn oddnumber [x nums]
    (take x
      (for [n nums
            :when (odd? n)]
        n)))

Moreover, if you have a vector you can ask if it contain a determined element.

(def example_array (atom (vector 1 2 3 4 5)))
(contains? example_array 2)

And here are some more examples:

(defn square [number]

    (* number number))

(defn add [number number2]

    (+ number number2))

(defn whenexpression [number]
  (when (= 1 number) true)
)


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