Rafael Noronha

I have been mentoring an apprentice at Stefanini SDC.

During the early follow-up, I thought that a code kata would be a good way to encourage the apprentice to solve programming problems.

To specify what I’d like to see implemented, I wrote a few unit tests, and explained how automated tests would help us.

I also introduced test-driven development, and how it might be useful during the code kata resolution.

A day after the apprentice was able to add more unit tests to the test suite, thus extending the program behavior.

What I realized is that TDD as a methodology of work, involves the apprentice in a cycle of continuous learning, disclosing how execution of each new instruction added to the program happens.

A great value brought by TDD as a tool supporting education is the fact that the student prematurely get used to specifying software behavior before implementation.

Another skill the apprentice would develop at a early stage is requirements analysis.

I’m very excited about where this is going to take us, and it has been also a great experience.

Sorry, this entry is only available in Portuguese.

Sorry, this entry is only available in Portuguese.

I would like to share some thinking on Domain Driven Design.

The amazing value provided by Domain Driven Design is the focus on the business side of the Software.

This same focus brings a constraint to your software development process: IN-DEPTH Business Knowledge becomes a MUST HAVE.

I just want to make sure you will remember this constraint when planning to apply DDD.

If you have any sort of problem on the matter of handling this constraint, take my advice: Stay with the CRUD based option.

Domain Driven Design can absolutely improve what you are going to deliver to your customer.
But don’t expect all you have to do is having stuff that you call “Aggregate Root”, “Domain Model”, or “Repository”.

Sorry, this entry is only available in Portuguese.

It sucks hard every time I think about how we commonly solve complex business problems in software development.

Probably at sometime you’ve built a piece of software intended to handle a lot of business rules, being this software surrounded by a complicated and rigid data model.

The problem with this solution is how hard would be bringing to the software different concepts and rules.

Having a tool as powerful as the DSL concept out there, I just can`t believe why something as amazing as that isn’t at our hands right now, when we deal with that kind of scenario.

I’m going to investigate deeply the technical aspects of internal DSL’s,  because if there is something I want to apply to my daily job – someday, it surely would be a killer business DSL – something I believe being capable of putting a software well ahead of the average.

If you are a software developer and you have no idea how amazing can be such tool, do me a favor and make a research about domain-specific languages now.
You can start here, and here.

Sorry, this entry is only available in Portuguese.

Hopefully as a professional you have always established new career goals.

This is between the few attitudes that can push you to wherever you want, when constantly exercised.

The key point is: we need to draw, establish, and pursue these goals.
Opportunities will appear and require braveness and wisdom of the management of such things.

Probably the people at this course will be passionated about what whey work on, facing challenging environments at the professional side.

On the other hand, people who are not policing their career tend to fall in something called confort zone.
At the comfort zone, professionals face the same kind of situation in a daily basis.

Honestly, I can’t figure out something more boring than that.
This is the kind of scenario that completely discourages me.
Being in this scenario should be the best way to making your life boring, easy and low profitable.

Luckily I see myself closer to the first scenario, and at the present  nothing encourages me more than experiencing it.

What about you, dear reader?
How serious are you taking your professional career?

Maybe the biggest mistake made by programmers is marrying with the tool they have at hands.
I really can’t figure out something worse than that.

Being married isn’t the same as being specialist:                                                          

Being a Microsoft specialist is ok.
Being a Java guru is ok.
Being a Ruby on Rails expert is ok.

The problem comes when you specialize in a technology and get tied to it.
Closing your eyes for the different options out there.

Don’t do that if you plan to be a better programmer.
When you tie yourself to one specific technology, you lose the big picture.

Until you get closely in touch with some different programming languages, platforms and technologies, you won’t be capable of saying a given tool is nice, or best suited for a job at hands.

Typewriters aren’t that bad while you don’t hear about computers.
Tied to a single technology you would also be merely resolving specific issues, lost in the middle of countless platform-specific developers.

Let me give you some of my (short) work experience.
I worked one year developing web applications upon the .net platform, and something called web forms.

At .net community, there are a lot of guys thinking asp net web forms is such a great web platform. You know why?
Because all the relevant web development experience they have was built on top of this single technology.
They lost the big picture! And they are tied to such horrible piece of technology. 

What about different programming paradigms?
While working with .net, my language of choice is c# (by now). 

While attempting to build decent software with it, I saw myself juggling.
Juggling to please c# compiler.

As I don’t work to a cirque, I realized something could be wrong.
Luckily I’m not the guy married to a tool.
And I had heard about something called Ruby on Rails.
So I decided to give it a shot, while working with web development.

Today I must say Ruby on Rails seems to me a much more reasonable tool to have at hands while I’m building web applications.
And I know exactly why Ruby and Rails are better suited for it.
I met the options out there. 

Probably I’m going to switch the tool at my hands for a long time.
Because there is no divorce pain on it.

Your engineering skills and career can only benefit from the different experiences you are going to dip. 

Try it!

This is a brief criticism to countless bloggers out there writing about stuff like “Doing foo with bar”, “Foo quick tip”, you know, all that articles and tutorials teaching how to solve some specific problem within a given platform (commonly such problem being not really interesting).

I don’t think this kind of article is that bad, but if all you are blogging about is that kind of stuff, probably I’m not one of the guys subscribing to your blog.

I’m not sure my blogging style is better than that, and I’m certainly not the right person to telling.
But since I started this blog I’m always looking for topics that I may have something interesting to share.

For the record, I don’t think programming advice can’t bring success to your blog.
You should succeed on that being a very smart guy, having a lot of insights about software design and an endless ability to write about how amazingly you apply engineering techniques.

Currently I can think in one guy capable of doing that:
Ayende Rahien, who have been writing about software engineering in a daily basis, with great authority.

Probably there is a great community around you if you are such a smart and disciplined blogger (please let me know, by the way).

At the brazilian side, currently I like the blogging style of guys like Fabio Akita and Carlos Brando, both smart Ruby on Rails activists.

So, are you one of those bloggers who tend to write about quick tips, or you do a more elaborative style?

Sorry, this entry is only available in Portuguese.

Are you a very skilled software developer?

So you should agree with me. This is the best code ever:






Yes, there is no code.

There is something better than writing good code:
Not writing code.

The platform and frameworks you work with must enable you to not write code.
Or, at least, to write much less code.

Just remember, writing code is bad.

Since I started to give practice to the concepts involving REST and ROA, I wonder why this knowledgment is not the way to go when companies are building web applications.

Maybe the problem is that people become used to build web apps while this knowledgment didn’t have much ground.

Beside that, there are technologies out there absolutely disregarding how the web is supposed to behave.

I’m telling about asp.net Web Forms.
Looking from a technical perspective, I have no words to express how freak it seems to me.

And still thinking about web technologies, today I see Ruby on Rails as the easier way to go if you take the architecture of the web seriously (but there are different options out there).

Probably a lot of people still do not realize the benefits of working together with the http protocol and the infrastructure around it.

So my question is, are you embracing REST ?

Do you see good profit on applying ROA or you think it is all about coolness and aesthetics?

At this post I’ll show you how I have been responding to Ajax requests at web apps built on top of rails 2.3.

Ajax completely changed the web experience, and I highly recommend you to embrace it whenever your requirements are not disallowing you.

For the sake of curiosity, at my current project probably more than 90% of post/put/delete requests are performed asynchronously.

If you don’t know the way Rails can handle that, it is a very simple concept.

You write some Ruby code that will generate javascript code, being this js code executed when the request is responded with success.

We can do that writing rjs files, or, my preferred method, we can generate the code directly from a controller call.

This could bring us some SRP problems, if we were writing this code at the controller class.

But my approach is encapsulating the response code at helper methods, because that should be the home of any code taking care of html concerns.

I think this is a good way to keep my code well organized so anyone can easily identify how things are supposed to work looking to the helper methods, without being required to open a lot of rjs files.

At this gist you can see a sample code of this approach.

Do you prefer the rjs option?
Maybe I’m going against one of those Rails conventions?

Tell me you are used to explicit your intent every time you write code, and probably I’m talking to a very skilled programmer.

Explicit intent is a quite simple concept.
Great news. Despite the simplicity, there are huge advantages on bringing it to our daily work.

When the intent of code is explicit, future maintenance of this code is kept at a very healthy level.

You know, things can be bad when we are working with poor code.
Lack of explicitness is probably one of the biggest clues indicating your code is in trouble.

Sadly I’m not sure this is something every good programmer is aware.
So I’ve decided to rant about it.

Let’s see how easy can be identifying lack of explicit intent.

Here is some testing code extracted from spree, an open-source e-commerce solution that seems to have a solid code base.
Hopefully you are used to write testing code and you know it should receive the same care as your production code.

require File.dirname(__FILE__) + '/../spec_helper.rb'

describe Payment do
  before(:each) do
    @order = Order.new
    @order.checkout_complete = true
    @order.stub!(:total).and_return(100)
    @payment = CreditcardPayment.new(:order => @order)
  end

  describe "save hook" do
    it "should mark order as paid if payment_total = total" do
      @order.stub!(:payment_total).and_return(100)
      @order.should_receive(:pay!)
      @payment.save
    end
    it "should mark order as paid if payment_total > total" do
      @order.stub!(:payment_total).and_return(101)
      @order.should_receive(:pay!)
      @payment.save
    end
    it "should not mark order as paid if payment_total < total" do
      @order.stub!(:payment_total).and_return(99)
      @order.should_not_receive(:pay!)
      @payment.save
    end
  end

end

Testing code wrote on top of rspec tends to be very expressive, being the intents of what is happening pretty explicit.
You can see it at this code.

But I have an issue with the setup code.
It failed in telling us what is happening at a first moment:

  before(:each) do
    @order = Order.new
    @order.checkout_complete = true
    @order.stub!(:total).and_return(100)
    @payment = CreditcardPayment.new(:order => @order)
  end

When looking for a good understanding of what is going on, we are enforced to follow the code at a low level.

And if this kind of issue propagate at the code base, programming productivity and focus may be affected.

I told you explicit intent is a quite simple concept.
It is also pretty easy to be applied:

require File.dirname(__FILE__) + '/../spec_helper.rb'

describe Payment do
  before(:each) do
    create_and_checkout_a_given_order
  end
  def create_and_checkout_a_given_order
    @order = Order.new
    @order.checkout_complete = true
    @order.stub!(:total).and_return(100)
    @payment = CreditcardPayment.new(:order => @order)
  end
  describe "save hook" do
    it "should mark order as paid if payment_total = total" do
      @order.stub!(:payment_total).and_return(100)
      @order.should_receive(:pay!)
      @payment.save
    end
    it "should mark order as paid if payment_total > total" do
      @order.stub!(:payment_total).and_return(101)
      @order.should_receive(:pay!)
      @payment.save
    end
    it "should not mark order as paid if payment_total < total" do
      @order.stub!(:payment_total).and_return(99)
      @order.should_not_receive(:pay!)
      @payment.save
    end
  end
end

What the heck? Giving a name to that piece of code is all we were required to do?

Yes, and now we can read this code without worrying about what is happening at some anonymous and mysterious piece of code.

Giving meaningful names to your code is a very powerful technique.
Having deserved a whole chapter at Clean Code, by Robert Martin.

So, when you understand exactly what is happening at some code you just get in touch, a very skilled programmer should be behind it.

Sorry, this entry is only available in Portuguese.

Sorry, this entry is only available in Portuguese.

Sorry, this entry is only available in Portuguese.

Sorry, this entry is only available in Portuguese.

 I’ve become a professional programmer working on the .NET platform.

.NET is pretty cool, C# also.
But it seems like something is missing, while I am working with web applications.

I think the web is pretty cool, and I really like to work on making it even more cool.
But with a static programming language at hands, my work have become so much pragmatic, and kind of boring.

I don’t want to worry about IoC, DI, AOP and all that stuff, when looking for a minimal sense of flexibility, just to please C# compiler.
And I don’t want to take all those framework decisions, writing all that crap infrastructure code, every and every time I start a new project.

Not while working on cool web applications.

What I want is simplicity, polish and freedom.
So I can take out of my brain all that distractions, keeping my focus at the product level.

Static programming showed her face to me.
And she is ugly.

I’m going to give Ruby on Rails a second shot, as I’ve already tweeted.

I really like the Rails mentality, and how Ruby code looks like.
And I’m very interested in work with something that please me, instead of please what I’m working on.

Look, I am not saying .NET and C# sucks.
Okay, maybe I do think so, when we talk about web programming.

This is kind of subjective.
I am okay if you do not agree with what I pointed out.

What I believe is that we should look for the right tool when doing a job.
Because there is no such tool solving all sort of problems, on top of the best suited approach. Sorry, C Sharp.