i'm back!

Wow, it's been a while!

But I'm back now, and with good news:

I landed my first rails job! I'm currently working for a nice startup who works with a major credit card company... The team is very talented, and they're very nice people! I'm very happy, I'm already learning a ton of new stuff at a very fast pace. That's much better than learn on my own, at home!

Another good thing: I've FINALLY finished my first sample application! Take a look at it on GitHub and Heroku. If you want to see more, just ask me for the username and password. I'll implement a signup system using devise later, it's on my todo list. =)

updating rvm and ruby

I'm starting a new project today, and I wanted to update Ruby to its latest version before starting.

The first thing I tried was to use RVM to upgrade the Ruby version, but it didn't work. I had to upgrade RVM first, so the last Ruby version would be included in the "known Rubies" list:

$ rvm get stable

When I ran rvm list known, it was there:

[ruby-]2.0.0[-p195]

And this last command did the trick:

$ rvm upgrade 2.0.0-p0 2.0.0-p195

the good book

It's been a while since I posted for the last time.

I was watching the rails workshop like crazy and trying to extract every last bit of knowledge of it. Now I'm done, and it's time do start coding again, so I'll be posting more.

I still have to finish Kent Beck's TDD book, I've read only the first part, but today I felt the impact it had. Kent, I salute you!

I was coding something to a friend, and I was really able to think in a TDD-way, it was awesome, there's no going back now.

But the best part was refactoring the code. Kent says "Eliminate duplication", and I think I'll tattoo this on the back of my hands. Refactoring is AWESOME! Identify the duplication, eliminate it, "cool, my code looks cleaner!", run tests, all green, FUCK YEAH! It's almost like magic, you code shrinks before you eyes, becomes cleaner, and you have full confidence that you code still works.

If you wanna take a look at my code, see how it evolved, it's all here.

I wonder how much more cool stuff there is to learn in books like the classics Refactoring and Code Complete. I wish I had 48 hours in a day. =)

domain specific languages

The very first time I've hear about DSLs was after the Thoughtworks Boot Camp in March/2012.

I've read some articles after that, but I just really understood it after I started using Capybara.

Capybara is a framework for testing user interaction in rails applications.

A Capybara test will have statements like these:

visit "/"
click_link "My account"

fill_in "Your email", with: "john@example.org"
fill_in "Your password", with: "test"
click_button "Login"

Those statements are part of the Capybara framework. They are part of a language that was created specifically for the purpose of testing web applications. This is the Capybara DSL. A small language created for this specific purpose, or domain.

I've read that DSLs are not a new topic, but with the popularity of dynamic languages like Ruby, they are easy to create and incredibly useful. I'll try to create my own in the near future.

all in

Last friday I quit my job to study Rails full time.

And I must say I'm quite happy. The first day was a bit overwhelming, the workshop I'm currently attending has A LOT of information, and it will take some time to soak it all up, but the teacher is really good, and it's better to learn from a master than try to learn everything by myself.

It will take a lot of time and effort, but I'm feeling great about it, and I'm 100% motivated.

Let's do this! =)

method aliasing

It's possible to create aliases for methods in Ruby:

Now we can call either say_hello or greet and have the same results:

> h = Hello.new
=> #<Hello:0x9390ba8>

> h.say_hello
Hello!
=> nil

> h.greet
Hello!
=> nil

posting by chance

I had a delightful day with my girlfriend yesterday. =)

But just before I went to bed, I realized I hadn't written a single line of code all day, and that's bad luck. =)

It was already late and I after searching for ten minutes or so (man, it's hard to find a website with real simple exercises) I chose a trivial problem: write a program that simulates rolling a par of dice (I wanted something really simple, just to write my bit of code for the day and not upset the Coding Spirits).

I started writing a test, something like:

def test_roll_dice

  die = Die.new

  result = die.roll

  # assert... wait, what?

end

What would be my assertion? That the result had to be between 1 and 6? But if I write a roll() method which returns numbers between 1 and 7, the test would pass 85% of the time. I thought about it for a while, and I really don't have any clue of how to test random stuff. I hope Kent covers that in his book...

The really fun thing is that something trivial like this led me to a meaningful question, something interesting that I will surely look into later.

I guess programming is like a box of chocolates... =)

rewriting history 2

Continuing from my last post:

I've discovered how to get back to an old commit. I was at chapter 16 and that's what I did:

git checkout chapter_14_SHA1_id

Took me back to chapter 14 again. After working through chapters 14 and 15 for a second time, I commited the code just before chapter 16. To make my HEAD revision point to this last commit, I did:

git reset chapter_16_SHA1_id

I re-coded chapters 14 and 15, and went from chapter 16 on. The first chapter 14 and 15 commits went to hell, but that's ok for now.

And I also found a way to correct the last commit, which is great if we forget do add a file or something like that. After adding the files as usual, that will do the trick:

git commit --amend

Awesome! =)

rewriting history 1

As I said before, I'm coding in Ruby as I follow through Kent's book. Whenever I start a new chapter, I commit the code. If I want to start over the chapter I'm in, I just revert my changes. I haven't discovered how I would revert my code to an old commit yet (for instance, if I wanted to work through the second chapter again), but I'm pretty sure there is a way.

Between chapters 14 and 15, I made some minor changes to the code. My history was something like this:

commit - going to chapter 14
commit - minor changes
commit - minor changes
commit - deleted file
commit - going to chapter 15

I wanted to go back to chapter 14, but I didn't want to lose the minor corrections I did before chapter 15. I was wondering if there was a way of merging multiple commits, and after some googling, I've found this article. It is possible and very easy to do. I've merged my commits and now the repo is just like I wanted.

I think git will never cease to amaze me.

blast from the past

Yesterday, when I wrote the last line of that code snippet, I felt weird. It didn't feel right.

Today, when my friend and mentor The Fridge read the post and saw it, he said that last line was practical, but could be a bad idea in Rails views, because it could bloat the code in no time.

Thinking about it reminded me of the pairing session I had with one of Thoughtworks guys. Then I decided to revisit the code we wrote on that day. I've discovered some really cool stuff:

• The true magic of git: I was running my code on an Ubuntu VM at the time. After I was lured to the dark side of the Force I deleted the VM and saved all my Ruby stuff in a tar.gz file. After more than an year, I extracted it all to a folder in Windows, and EVERYTHING was there: the repo was working, all the commit history, even the files' statuses was untouched. It was really mind blowing. Would it happen if I was using SVN? I don't think so. I guess Linus is right.

• All my tests were green: yay!

• My code was broken: damn! That boot camp was one of my first experiences with TDD, so that's ok, I guess. I had all my classes and methods covered by tests, but my main source file wasn't. Or maybe I had tampered with the code recklessly after the boot camp, I don't know. But the cool thing was: I had and old piece of code that wasn't working. Then I wrote a new test for and old broken feature. And I was like "I wonder if that's how it feels like to deal with legacy code using TDD". I haven't got to that part on Kent's book yet, and I know there are some good books on this topic.

• Yep, that code was bad. I remember Netto telling me that stuff like that exposes the guts of your class and that's bad. (his wording was better, for sure)

So a better way of doing it would be something like this:

Ah... That's much better... =)

private rovering

The code in Kent's book is all Java, but as I follow through I'm coding in Ruby, and this change led to some interesting discoveries.

After changing an attribute in my class to private, my code stopped working for no apparent reason. After some googling I've found this article. The access specifiers (public, protected, private) have slightly different meanings in Ruby and Java. For my code to work, I had to use protected, while in Java I'd had used private. Interesting.

I've also learned about the Value Object design pattern. This is a cool pattern to implement small things like a pair of coordinates (x,y) and such. And that reminded me of last year's Thoughtworks Boot Camp I attended. They presented the Mars Rover problem to us. The rover position should be represented by two coordinates and the orientation, for example: 0,0,N. In this case, The rover would be on the top bottom left corner of the map, facing north. The position would be represented perfectly by something like this:

I don't know if there's anything more to this pattern, but Martin Fowler's book which describes it is already in my to do list.

first off

Okay, so where should I begin?

Ruby is the language, Rails is the framework, so the Ruby language would be a good place to start.

I know the basics of Ruby, but before I delve deeper into it and start coding like crazy, there's something else: there's no point in learning the most awesome language in the world and use it to write crappy code. So, before I write any Ruby, I have to make sure I do it right. Therefore, the first step of my journey will be Test Driven Development.

I'm starting to read the classic Test-Driven Development By Example by Kent Beck, and doing my coding using Ruby and test-unit. I know rspec is the big thing in unit testing nowadays, but the goal now is to learn TDD itself and not worry about the framework. Test-unit will do for now, as it's simple, intuitive and didactic.

wtf?!?

Despite of what you're thinking, this blog is not about oral sex and ancient constructions, although that would make a really hilarious topic. Imagine the pictures! Machu Picchu! The Colosseum! Stonehenge!

This blog is about my journey to become a good Ruby On Rails developer. Oral By Ruins is just an anagram for Ruby On Rails. Sorry to blow away your expectations...