Daniel Cadenas

CORS with Ext.js

2011-10-11T19:04:00.001-02:00


Ext.Ajax.useDefaultXhrHeader = false
Ext.Ajax.request({url:'http://ipv4.0-9.fi', success: function(res,req){alert(res.responseText)}})

Download a file from upload or file sonic with curl

2011-09-10T16:42:00.003-03:00

Wupload:

curl -d "email=your@email.com&password=yourpassword&redirect=/file/159344782" -b cookies.txt -c cookies.txt  www.wupload.com/account/login -L -o 20110910StokevsLiverpool1ertPachorriarte.mkv

Filesonic:

curl -d "email=your@email.com&password=yourpassword&redirect=/file/2820172905" -b cookies.txt -c cookies.txt www.filesonic.com/user/login -L -o somevideo.wmv

Valgrind on your ruby extension test

2011-03-09T21:47:00.001-02:00

valgrind --num-callers=50 --error-limit=no --partial-loads-ok=yes --undef-value-errors=no rspec spec/extension_spec.rb

Ssh tunnel for socks proxy

2010-12-21T13:48:00.001-02:00

ssh -fCqND 8080 linode

apr_poll timeout while running ab

2010-04-05T02:40:00.002-03:00

If you get this error while running ab (ApacheBench) on your mac:

apr_poll: The timeout specified has expired (70007)

It may get fixed with:

sudo sysctl -w net.inet.ip.portrange.first=32768

sudo sysctl -w net.inet.tcp.msl=100

New Ruby gems

2010-04-02T16:45:00.003-03:00

Oops! It's been a while since the last time I updated my blog.

I promise I'll try to get back to business and write more often whenever I find some time.

First of all, many months ago I joined Cubox, a new uruguayan startup that works for many US clients including partnership and offshore work with renowned Rails shops. We are continuously growing and we are always happy to add talented developers to our team so if you are interested and are passionate about Ruby, Rails and agile development just email us.

We believe in open source, we use it in all our projects and we also contribute to the community. Here is an update of my latest new gems which were not covered in this blog. I hope you find them useful, click on the links for more info:

Preforker: Easily create preforking servers (like Unicorn architecture)
Rankable Graph: Calculates the pagerank of medium sized graphs (some millions of nodes).
State Pattern: A classical implementation of the state pattern.
Active Record State Pattern: State pattern applied to Rails models.
Stubborn: Helps finding missing external API stubs in your tests.
Google Set: API for Google Sets.
Change Watcher: Helps keeping a log of changes. Useful to store scraped info from cron scripts.

So check them out and contribute!

Gem to send mails through Gmail

2009-05-22T19:23:00.007-03:00

I made this little gem, gmail_sender that I find useful to log things when I'm running some script in my VPS, I use it for things like this:


require 'rubygems'
require 'gmail_sender'

g = GmailSender.new("gmail_account", "password")
begin
  #Some interesting script that returns some interesting results in script_results
  g.send("dcadenas@gmail.com", "It worked!", script_results.to_yaml)
rescue => e
  g.send("dcadenas@gmail.com", "It didn't work :(", "#{e.message}\n#{e.backtrace}")
  raise e
end

So all you need to pass to the send method is an email address, the subject and the email content.

Source code is here and you can install it with sudo gem install dcadenas-gmail_sender (remember to add github to your rubygems sources).

Some useful bash functions

2009-05-22T19:12:00.004-03:00

I use this bash functions to open vim with splits for each file in which grep or rak find the pattern I'm searching for:


grepvim(){
  grep -rl "$1" $2| xargs mvim -o +/"$1"
}

rakvim(){
  rak -l "$1" $2| xargs mvim -o +/"$1"
}

Tunneling through SSH

2009-04-20T17:45:00.002-03:00

To tunnel through ssh do:
ssh -v -nNT4 -R :4007:localhost:3000 linode

which maps the remote port 4007 to the local port 3000.linode is the host you want to connect to which should be properly configured in your ssh config.

Joined ENTP!

2009-03-10T01:39:00.004-03:00

Oh I just realized that I never wrote a post about me joining ENTP 4 months ago!!
I'm thrilled about this great chance I'm having working with some of the most talented Ruby developers the world has to offer and I wish that osmosis does its magic and maybe I get at least some tiny part of their mojo. I'm really happy!

RSpec fun

2009-03-10T01:31:00.003-03:00

So I was there, running a huge and slow rspec test suite on my Mac and thought "god, I wish I could make it run faster just by tilting my laptop right and make those damn dots fall" so... the most awesome rspec optimization was born :p

Capistrano and Git problems

2008-12-12T15:51:00.006-02:00

If you get this error when deploying with Capistrano:

ERROR:gitosis.serve.main:Repository read access denied

You may solve it with:

ssh-add ~/.ssh/id_rsa

This is needed because my ssh config is configured to forward my identity to the deployment machine (with ForwardAgent yes) so the ssh agent must know my private key.

Recursively replace all files with tabs in Linux

2008-10-19T23:58:00.006-02:00

Ok I don't want to forget this ever again so I will write it here.

sed 's/ //g' `find -type f`

Note I'm using both the grave accent "`" and the apostrophe "'". "`" is used to create a special kind of shell escape that substitutes each line of the output in the place you inserted it. So sed will be called once for each file found by find.
It's the same as doing manually:

sed 's/ //g' ./file1.txt sed 's/ //g' ./file2.txt sed 's/ //g' ./dir/file2.txt . . .
To type the tab inside the sed regexp hit ctrl-v and then the tab key.
find -type f will show in each line the path of each file recursively.

Auto Focusable Forms

2008-10-10T23:13:00.006-02:00

Just commited a Rails plugin (my first one, yay!!) to give automatic focus to the first input of the first form in each of your views.

Of course you can disable this behaviour but I think that having focus in the first input by default can be very useful.

You can read more in the project page here.

Internet Explorer 7 accept header and Rails respond_to

2008-10-07T20:00:00.003-02:00

If you browse through IE to an url that should spit html but instead you see the feed reader page (the one with the text "You are viewing a feed that contains frequently updated content") then just be sure that the page's respond_to has the html mime type as its first item instead of atom or rss.

This solution addresses the way IE constructs its http request accept header which accepts any MIME type you may be serving so the first one available will be accepted which is not necessarily the html you are expecting.
Firefox doesn't have this problem because it explicitly states what it wants.

So in summary, change this:


respond_to do |format|
  format.atom
  format.html
end

to this:


respond_to do |format|
  format.html
  format.atom
end

One thing to keep in mind when extending Ruby classes

2008-10-06T02:07:00.009-02:00

I was reading this post in Mauricio Fernandez's blog (rcov) and I got surprised about the behavior I'm summarizing in the following code:

class A
  def foo
    "A#foo"
  end
  
  def singleton_class
    class << self
      self
    end
  end
end

a = A.new
puts a.foo #=> A#foo
puts a.singleton_class.ancestors.inspect #=> [A, Object, Kernel]

module X
  def foo
    "X#foo"
  end
end

class A
  include X
end

a.extend X
puts a.foo #=> A#foo (and not X#foo!!!!!!!)
puts a.singleton_class.ancestors.inspect #=> [A, X, Object, Kernel] (and not [X, A, X, Object, Kernel])

So remember, you cannot extend or include a class with a module that is already present in the ancestors chain, it will be ignored!

mocha_mock_path error in your tests

2008-09-26T12:29:00.002-03:00

If you use stubs in your Mocha tests but they break because of this error:

ActionView::TemplateError: undefined method `mocha_mock_path'

Check that you also stub the class method.


stub(:title => 'a title', :class => News)

Tip about encapsulation

2008-09-19T18:46:00.013-03:00

I like this simple and practical Kent Beck's tip about encapsulation (from Fowler's Getter Erradicator article):

...always beware of cases where some code invokes more than one method on the same object...

It's not a rule but I think it can be considered one more smell to have in mind.

Stubbing/Mocking constants with Mocha

2008-09-10T12:34:00.004-03:00

As far as google told me, it seems you can't use Mocha against constants.
One alternative proposed is changing the constant in the test where you need it like these:


class Module
   def redefine_const(name, value)
     __send__(:remove_const, name) if const_defined?(name)
     const_set(name, value)
   end
end

And inside the test case you change the constant to what you need and restore it after the test ends:


Object.redefine_const(:RAILS_ENV, 'production')

But if you can control the code that uses the constant there's a more clean way. Just wrap it in a method and get the constant through the method. During testing you just mock the method:


class A
  def rails_env
    RAILS_ENV
  end
  #...some more code that gets the constant RAILS_ENV using the method rails_env...
end

And then in your test you just do a normal expectation:


A.any_instance.expects(:rails_env).returns 'production'

You could even have some module that wraps all useful constants in your app, so constant dependent code gets easily testable and clean.

Singleton class magic without using singleton classes

2008-09-03T11:25:00.007-03:00

Excellent posts here and here by Jay Fields where he gives an alternative to use singleton classes.

Instead of doing this:


class << self
  def hi
    puts 'Hi'
  end
end

You do this:


mod = Module.new do
  def hi
    puts 'Hi'
  end
end
extend mod

Reverse Ajax and Prototype with Mongrel handlers

2008-08-25T23:38:00.017-03:00

The most common use of reverse Ajax or Comet calls is having some piece of information in your webpage that you want to update as soon as some remote event triggers, always without polling. Let's make a little experiment to see how this works:

Client side

So you start a request, the web server waits for the event to happen, and finally, a while later, the response is sent back to the client. When this process ends, it's very common that you want to start it again. You want to have a continuous ajax call when the event is also continuous, when it can happen many times.
To deal with this, as I'm using prototype, I made this javascript routine to start listening for the event:


function continuousAjaxCall(url, method, params,
                            successCallback){
  waitingForResponse = false;
  function iteration(){
    if(!waitingForResponse){
      waitingForResponse = true;
      new Ajax.Request(url, 
       {
         method: method,
         parameters: params,
         onSuccess: theSuccessCallback
       });
    }
  };

  function theSuccessCallback(transport){
   successCallback(transport.responseText);
   waitingForResponse = false;
  };
  
  return new PeriodicalExecuter(iteration, 1);
}

So now if you do:


continuousAjaxCall("/WebFacade/SomeWebService", "post",
                   "taskid=" + taskNumber, callback);

you will start listening to the web service in /WebFacade/SomeWebService using method post and with taskid=taskNumber as the http body parameter.
The callback is a routine that will be executed each time the event is triggered. For example we could do this to show the result from the web service:


function callback(responseText)
{
  alert(responseText);
}

The routine returns a prototype PeriodicalExecuter that you can use to stop listening:


pe = continuousAjaxCall(...
pe.stop()

Server side

In the server side I have some Mongrel handlers serving the client pages. The key here is the line sleep 1 until @@submitted_value that waits until some new value is submitted and only then responds to the ajax request:


require 'rubygems'
require 'mongrel'
include Mongrel

@@submitted_value = nil

class ReverseAjaxHandler < HttpHandler
  def process(request, response)
    response.start(200) do |head,out|
      head['content-type'] = 'text/html'
      sleep 1 until @@submitted_value
      out << @@submitted_value
      @@submitted_value = nil
    end
  end
end

class SendHandler < HttpHandler
  def process(request, response)
    response.start(200) do |head,out|
      #Code that renders the "/send" page and sets the @@submitted_value
      #...  
      #...  
    end
  end
end

h = HttpServer.new("0.0.0.0", "5000")
h.register("/wait", ReverseAjaxHandler.new)
h.register("/send", SendHandler.new)
h.register("/files", DirHandler.new('.'))
h.run.join

It's nice to have this as a Mongrel handler because it's simple, but keep in mind that this implementation was made just for the purpose of this example and it is not thread safe. I don't control the access to the global variable @@submitted_value

Demo

I made a little demo about this using some mongrel handlers like the one in the previous post:

The code for this article and it's demo can be found here.

Standalone Mongrel handler Hello World

2008-08-24T14:00:00.007-03:00

I think this is the simplest Mongrel handler you can create. It doesn't depend on Rails so this is not what you need to write if you want to install a Rails friendly Mongrel handler.


require 'rubygems'
require 'mongrel'

class HelloHandler < Mongrel::HttpHandler
  def process(request, response)
    response.start(200) do |head,out|
      out << 'Hello World!'
    end
  end
end

h = Mongrel::HttpServer.new("0.0.0.0", "5000")
h.register("/hello", HelloHandler.new)
h.run.join

Notes:

If you want to output html remember to include head['content-type'] = 'text/html' inside the inner block

To include static pages you can add h.register("/files", DirHandler.new('.')). After this you can access all files in the current directory through this url http://localhost:5000/files

A dependency graphs gem

2008-03-13T01:06:00.006-03:00

Some days ago I had to do a big refactoring involving almost 100 C# projects, a little monster. I thought it would be very helpful to have a dependency graph that could quickly show me the projects dependencies I was interested in at any given moment and that would let me apply some filters to the result.
I didn't like the few things I found in the net so I did a Ruby program to traverse csproj files and generate a Graphviz graph with the desired results, something like this:

So as I thought this could be useful to a lot of people I decided to make it open source so I created this Rubyforge project to host it.

I made some changes to make it generic so that it could be used for any kind of text files that have parseable dependencies hidden inside.
There are 2 examples stored in a yaml configuration file that deal with C# projects and Ruby requires statements.

So for example, if you want to graph your C# projects you do this from the root directory:

depgraph -type csproj

And if you want to graph the requires dependencies of your Ruby files you do this:

depgraph -type ruby_requires

Then if you add a new entry in the yaml configuration file you'll be able to do this:

depgraph -type [new entry name]

You can also filter by directories and node name regular expressions against source and dependency targets. I'll add more functionality in next releases but it's already usable.

To install it:

gem install DepGraph

As always, check the project's webpage and the specs for more info.

A file system integration tests helper

2008-03-04T20:50:00.013-02:00

A common problem that arises when creating integration tests against the file system is not having a one on one mapping between test cases and file structures.

The most popular solution is having one generic file structure defined outside the test case (manually or in the test fixture set up) in which a generic set of files are shared among many different test cases.
This works, but the problem is that we lose a lot of the documenting benefit of tests.

The expressive power we could gain by the explicit creation of customized test files for each test case is very important.

Of course we should test all we can inside our unit tests but it's always good to have something in our toolbox in case we have to go to the real thing at some moment.

One example is when you have to deal with highly coupled legacy code in which your only practical solution may be testing directly against it's file inputs and outputs.

So considering all this I made a very simple ruby gem, filetesthelper, that let's you do something like this:


require 'rubygems'
require 'filetesthelper'
include FileTestHelper
  
...
  
def test_some_code_that_uses_the_file_system
  #Let's say that the current directory here is X
    
  with_files('dir1/file1' => 'file1 content',
             'file2' => 'file2 content') do
    #Now the current directory changed to Y which
    #is a new directory created under Dir.tmpdir
    #containing only 'dir1/file1' and 'file2'.

    #Put some test code here.
    File.open('file2') do |f|
    ...
  end
    
  #When we finish we are back at directory X and
  #the Y directory is deleted with all its contents
end

Check the specs for some more details.

To install it just type gem install filetesthelper from the command line.

A Visual Studio 2005 solution generator in Ruby

2008-02-24T22:23:00.007-02:00

Sometimes when you develop a big product you don't have a big solution that involves all your projects, but instead you have many smaller solutions that are used as views for some particular aspect of the product. This has the benefits that brings separation of concerns at a product structure level and you also get less resource costs from Visual Studio.

But sometimes you need a monster solution (100 projects for example) as this would be useful when you need to make global refactorings, build scripts, metric analysis, etc.

Mantaining this sln file manually is not the best thing to do because for example you can easily miss new projects added or removed from a smaller sln in which some developer is working at a smaller scope. You can ask the developer to keep it up to date with each change but that's an RMBT (Risky Manual Boring Thing) which is a smell.

So I made this simple ruby script that creates an sln file containing all the projects found in the current directory tree.
It will recursively search for csproj files in your directory tree and create the corresponding project entries with the correct guids.

Note that:

You can optionally specify the sln file name.

The source control bindings must be mapped manually.

The native guid generator used is taken from here.

Names

2007-12-27T16:32:00.000-02:00

From http://www.xkcd.com/

More about refactoring

2007-12-08T19:09:00.000-02:00

Some points of disagreement with the critique against the Refactoring book found in this article about smells:

Assuming that he is right in that most of us know how to refactor, I think that's because experience gave us the needed knowledge. Time and pain was needed. This time and pain, as in any knowledge area, can be reduced by reading books, like Fowler's.
Apart from this, I think even a developer with experience and knowledge of most refactorings could miss some smells. We are humans and we acquire bad habits.
A big part of the knowledge gained with experience is too intuitive and that brings some problems. When things are intuitive and you suddenly find someone that doesn't share your intuition you have to fight back with solid explicit arguments. Fowler's book helps you ease the work needed to find those arguments letting you show clearly why your intuition is the way it is. You can do it yourself of course, but it's easier to reuse the effort someone else did, if you share it of course.
The book defines a vocabulary to deal with our intuition or implicit concepts, that is very very important. Now we can share it and we can communicate more efficiently. The same advantage we discovered after design patterns appeared.
He agrees with Fowler that smells are important. The book is a reference to smells. IMO refactoring is more about identifying design problems (smells) than about the relatively simple things needed to make them disappear, but it's both of course.
Things that are important, like smells, must be made explicit so the problem can be easily studied and possibly build some more knowledge on higher level concepts. One of those higher level concepts that could be further developed was the development philosophy of Continuous Design in which a core concept is refactoring.
I think there's a confusion between simplicity and importance. Not only complicated books are important.

I think that a big reason for this disagreement comes from not seeing smells as thightly tied to refactoring as I see them.

More about architects

2007-12-04T23:31:00.000-02:00

I found this great Fowler's article which I think compliments well with my previous post saying that architects are programmers.

Then I found this other great webpage he wrote about software design.
In the paragraph Do you wanna be an Architect when you grow up? he talks about this issue. I think that the I'm not just a mere programmer - I'm an architect feeling he points out is one of the reasons people feel so much against this natural unification of responsibilities.

Just imagine a football team in which only forwards are supposed to score goals and discouraged to assist and midfielders can only assist but are discouraged to score goals, it would be just stupid the way resources would be wasted with this separation.

Now imagine a software system in which only the architect takes architecture decisions and doesn't touch code, and programmers only code and don't take architecture decisions. It is unnatural.

Wouldn't be better if all players, err, programmers could make that decision as a team? You would just listen more carefully to the experienced programmer that is the architect and you'd have to be more trained on design. But that has always been your responsibility, you develop software! A programmer without design knowledge (or will to improve it) is like a football player that can't make a decent pass.

Finally it seems Jeremy D. Miller reads my mind with this post.

So I got quite surprised to discover so many similarities. I guess this architects are developers belief is more popular than I thought and that can only be good!

The meaning of refactoring

2007-12-03T02:21:00.000-02:00

For a lot of people refactoring is not important. For some people this is because they don't know the correct meaning. They think it's just the name someone made up to describe simple code changes.
That's not refactoring.
You refactor when the changes you make improve the design while keeping its behaviour unchanged. Knowing when and how this improvement should be made is what is taught in the literature.

But there's another group of people that know the correct definition but still don't believe in it. This is because they measure their design quality just by its behaviour, so if the code already does what it's intended to do, they think it's good code. They believe in the "Don't touch the design if it's not broken" mantra (a slightly more valid reason to believe in this comes from lacking a good set of tests that act as a safety net for your design improvements).
For this reason they slowly start accumulating design debt. At some point, not too far in time, this unattended design improvement brings the impossibility to change code as it can't be controlled. This is because it's too difficult to understand and see all consequences of any change they may do, so either they don't change code anymore, or if they do, they start seeing bugs appear everywhere because they broke something they couldn't see it could get broken. So they say "You see? I was right, code shouldn't be changed if it's not broken", a self-fulfilling prophecy.

So in summary, refactoring requires the ability to systematically identify and improve problematic designs and it's important because it pays your design debt. This is necessary to understand and change your code easily.

This are great books you can read to improve your refactoring skills:

Refactoring: Improving the Design of Existing Code
Refactoring to Patterns
xUnit Test Patterns: Refactoring Test Code

Escaping CDATA

2007-11-13T23:13:00.000-02:00

This is a handy code that wraps a string with CDATA escaping any CDATA inside it:


public static string CData(string data)
{
    if (string.IsNullOrEmpty(data))
    {
        return string.Empty;
    }

    string result = Regex.Replace(data, "]]>", "]]]]><![CDATA[>");
    return "<![CDATA[" + result + "]]>";
}

Update: Clarity

Architects and programmers

2007-11-09T19:48:00.000-02:00

I'm currently working in a project for a client bank. Some days ago we had a meeting where they showed us their IT's organizational chart which had been recently updated. They had two departments, one of them was made by business analysts and software architects, and the other department is the software factory where programmers are supposed to be. I interpreted that they were even physically two different sections. I'm not sure if I'm alone in this but I think this separation is wrong. I think that architects belong to the same space as developers because they are essentially the same thing.

Architects are programmers

We must notice that architecture is a subset of design which implies that an architect is a designer. Now, if we agree that programmers are the designers of software then a good programmer that is capable of designing this subset, is an architect. Also notice that there are no good architects that are bad programmers. Being a good programmer is a prerequisite for being called architect.

With a similar reasoning we can conclude that a programming language is not more nor less than a software design language.
Of course there are other tools to design software (diagrams, etc), but a programming language is better as its product is the only design representation that is directly interpreted by the computer and the only one that has a 1 on 1 relation between what you expect and what you get.
Used correctly, they are better at communicating a design than the alternatives.

So architects should program but they also should do it in the same physical space as the rest of programmers. Not only because they have to communicate their ideas but also for two extra benefits:

Feedback.
Probably the most essential characteristic of software design is that it evolves by iterating. Even when doing waterfall, you evolve and iterate (the problem is that you stop too early doing so and you do it on paper). This evolution can only be done with realtime feedback and you won't get feedback if you are not inspecting and touching the guts of your child.
You can only assess the correctness of your initial "paper level architecture" with the detailed "code level architecture", you should have a deep understanding of the most real representation of your architecture so you can be able to gather immediate feedback both against interpretation errors when some developer didn't understand you and against your own errors. Even if you are errorless (I don't believe that), feedback lets you learn about the domain and improve continuously your design.

Maximizing transfer of expertise and knowledge.
If an architect is just a good and respected developer, then why not transfer its merits to the teammates. This would end up being a win-win situation because they'll keep improving and they know they will be responsible for the general improvement. The waste and problems that represent using programmers as if they were code generation tools is as silly as having not programming architects. Their design abilities must be improved. If they can't improve, well, then they are too stupid and risky even as a code generation tool, so don't hire them if you don't intend to use them as architects.

The separation problem

Divide and conquer it's a great heuristic. But if you fail to spot the point in which you should stop dividing, then it's counterproductive. Some things belong together. And when those things are split you'll find problems.
So if we have an architect that is not involved in programming we'll get two situations:

We have an excellent programmer, probably the best in our company, that is being used only for writing word documents and making presentations and diagrams. This is any design representation you imagine except the one in which he is good at and at the same time the one that is the more important and cannot be skipped. Yes, this is the one that is least understood by other departments of the company, but the architect role should be constructing software, his main target of communication are the programmers from the trenches. Communication with the rest is secondary.

We have a bad programmer that was choosen for some reason to make the architecture of the system. Let's not extend on this for obvious reasons.

A bit of metaprogramming

2007-11-06T23:31:00.000-02:00

I added some functionality to the technique shown in this Jay Fields post so that you can retrieve your original method(s). You can use it for aspect programming but remember that if you want a real framework for doing so then just use AspectR or some similar library.

First you add your behaviour to an existent method:


class TestClass
def testMethod(param1, param2)
"Original output with parameters #{param1} and #{param2}"
end
end

class TestClass
after_method :testMethod do |returnValue, param1, param2|
"The original output is: " + returnValue
end
end

If now you call testMethod('a', 'b') you'll get this string:
The original output is: Original output with parameters a and b, so you successfully decorated the initial method.

Now if you want to get the original behaviour and remove your method decoration, just do:


TestClass.undo_after_method(:testMethod);

And now after sending testMethod('a', 'b') you'll get:
Original output with parameters a and b.

Here is the code:


class Class
def after_method(method_symbol)
previous_method = instance_method(method_symbol)

define_method(method_symbol) do |*args|
returnValue = previous_method.bind(self).call(*args)
yield returnValue, *args 
end

singleton_class.push_previous_method(previous_method)
end

def undo_after_method(method_symbol)
method_key = instance_method(method_symbol).to_s.to_sym
previous_method = singleton_class.pop_previous_method(method_key)
if previous_method
define_method(method_symbol) do |*method_args|
previous_method.bind(self).call(*method_args)
end
end
end

def singleton_class
class<<Class;self;end;
end

class<<Class
#A hash that holds all the stacks.
#Each stack holds the current set of behaviours that decorate the initial method
@previousMethodsStacks = {} 

def pop_previous_method(method_key)
previous_methods_stack = previous_methods_stacks[method_key]

if(previous_methods_stack and previous_methods_stack.size > 0)
previous_method = previous_methods_stack.pop

if(previous_methods_stacks[method_key].size == 0)
previous_methods_stacks.delete(method_key)
end
end
previous_method
end

def push_previous_method(previous_method)
previous_methods_stack = previous_methods_stacks.fetch(previous_method.to_s.to_sym) do
previous_methods_stacks[previous_method.to_s.to_sym] = []
end
previous_methods_stack.push(previous_method)
end

def previous_methods_stacks
@previousMethodsStacks
end
end
end

The RSpec tests are here.

Functional programming

2007-11-04T08:02:00.000-02:00

I remember making a Mastermind solving program in Erlang some years ago back in university. I enjoyed it a lot and I thought it was a shame that the functional programming paradigm was not mainstream.

Luckily it seems times are changing and you can find that Erlang is getting more popular, DSLs are getting attention (so Lisp will gain it too) and Microsoft seems to be slowly trying to put his own functional language, F# (ML), at the same level of C#.

So while surfing the web about this interesting times I found this very pleasant to read web page that can make you recover from your imperative programming comma. Good reading!

About the object-relational impedance mismatch

2007-11-03T00:52:00.000-02:00

I agree 100% with this Bob Martin's post about the problems that arise when using the Active Record data layer pattern.

I think Active Record's problems come from implementing it from the beginning of your project which has the risk of biasing your design towards a weak domain model. You will tend to make design decisions that fit well with Active Record and it will be more difficult to realize you should be refactoring towards having a domain model.

You can't be sure whether your app will be really data-centric until it's finished and the most flexible design to cope with this doubt is starting with the simplest domain model. If at the end it gets anemic and you don't find it's behaviour outside, possibly in a service layer, then you can substitute it with the data layer, which could be Active Record.

So I like Martin's idea of considering the datalayer as an implementation detail. It may be an important detail, but details don't belong to abstractions, and if you mix them you fix'em (sorry couldn't avoid that).

It's easier to start flexible and then tighten than start tight and then get flexible.

So I think it's easier to add Active Records to your domain models than adding a domain model to your Active Records. And you'll have the advantage that you are not tied with a particular Active Record implementation.

I'd use a pure AR solution only if I'm very very sure that I'm dealing with a simple CRUD that won't change in the future, and even then I'd feel uncomfortable. The application may be data centric now but you can't be sure if it will keep being that way in the future. You don't know that even if you are the only client of the app.

Running RSpec with Autotest on Windows

2007-10-30T22:23:00.000-02:00

If you are on Windows and you see a LoadError similar to this when running autotest:

Open ruby\gems\1.8\gems\rspec-1.0.8\lib\autotest\rspec.rb and change this line


    return "#{ruby} -S #{@spec_command} #{add_options_if_present} #{files_to_test.keys.flatten.join(' ')}"

with this one


    return "#{ruby} -S spec #{add_options_if_present} #{files_to_test.keys.flatten.join(' ')}"

This fixed my problem but of course it's just a hack.

Ruby and DSLs

2007-10-29T00:38:00.000-02:00

Here you can see an excelent screencast by Peter Vanbroekhoven about creating DSLs in Ruby.
This is another appealing aspect of the language.

In my work I program mainly in C# and I couldn't avoid comparing his example with Linq.
I still didn't put my hands deeply on Linq, and I guess it must be much bigger than Peter's example but I can't avoid being amazed at the simplicity in which he shows how to have your own hand made Linq in Ruby with very little work.

So Ruby seems to be not just a programming language, it's a DSL programming language which it's something extremely powerful due to the productivity and readability that brings the higher level of abstraction. That's always good.

Funny BDD logo

2007-10-28T20:24:00.000-02:00

This is a nice one from Robby on Rails

Ruby

2007-10-28T03:59:00.000-02:00

My new toy is the Ruby language (I know, toys are a serious thing). I'm experimenting a bit, trying to see why all the fuss. Until now I like what I see. It's my first experience with a dynamic language and I feel quite comfortable with it. What I like most until now is duck typing, and no, it's not a typo, I really mean duck, the animal.

This comes from the more pure concept of interface in which you consider that two different objects have the same interface if they respond to the same messages, to the same way of interacting, of talking to them.

The duck analogy comes from saying that if something looks like a duck, then it's a duck. So in Ruby you don't need to define interfaces the way C#/Java does. Interfaces exist but you don't define them, they are already there, conceptually.

The biggest advantage I see about this is that the effort needed to assure that your design is low coupled is greatly reduced. Any object can be substituted by any other that implements the required methods without extra work. This dramatically improves your efficiency when making changes and evolving your design and testing gets easier.

Let's compare a bit C# and Ruby interfaces:


interface Cuackable
{
  void Cuack();
}

class ADuck : Cuackable
{
  public void Cuack()
  {
    //cuack the ADuck way
  }

  public void Swim()
  {
    //swim the ADuck way
  }
}

class BDuck : Cuackable
{
  public void Cuack()
  {
    //cuack the BDuck way
  }

  public void Swim()
  {
    //swim the BDuck way
  }
}

So If you need the Cuackable interface from your client code, you declare a variable or parameter that will eventually hold an ADuck or BDuck implementation.

The compiler knows you can use ADuck or BDuck because they declare they implement the needed interface.
You know you can use ADuck or BDuck because they implement the method signatures that you need. So there's a mismatch between the way you think of the interface and the way the compiler does (Ruby doesn't have this mismatch, we'll see this later).

What happens if now you realize that Swim should be part of another interface? Well then you'll have to define a new Swimable interface and define Swim as it's only member. You'll also need to implement that interface in each of the classes that implement the method and you'll also need to make the clients use that interface.


interface Cuackable
{
  void Cuack();
}

interface Swimable
{
  void Swim();
}

class ADuck : Cuackable, Swimable
{
  public void Cuack()
  {
    //cuack the ADuck way
  }

  public void Swim()
  {
    //swim the ADuck way
  }
}

class BDuck : Cuackable, Swimable
{
  public void Cuack()
  {
    //cuack the BDuck way
  }

  public void Swim()
  {
    //swim the BDuck way
  }
}

Now imagine that you have a third client method that requires to use both Cuack and Swim. In that case you'd have to pass the same object in two parameters to the client method:


void ClientMethod(Cuackable cuackable, Swimable swimable)
{
  //code
  cuackable.Cuack();
  //...
  swimable.Swim();
  //more code
}

//later you could call ClientMethod with the same object if you think that's correct...
aDuck = new ADuck();
ClientMethod(aDuck, aDuck)

//or with different objects if that's what's intended...
ClientMethod(new ADuck(), new BDuck());

Another alternative for the first example, although not the same, is creating another new interface that joins Cuackable and Swimable, a good name would be, ermmm... Duck. Then now you'd be implementing three different interfaces, all describing the different ways your client code can see your objects.

This grows exponentially being the number of possible interfaces 2^n - 1, where n is the number of public methods. Of course your clients see them only in the subset of 2^n - 1 that is useful to them, but this will be still a big number in non trivial systems, always assuming that you really believe in object polymorphism and the interface segregation principle which encourages having small interfaces.

As you can see, such a big number of interfaces is impractical to handle in strongly typed languages so we usually change the way we design to cope with this programming infrastructure problem and we start violating principles of good design. The most common solution to this is having huge interfaces with clients that, of course, just use a subset of them. This is, among other problems, a manteinance nightmare. But a smaller nightmare than the more correct alternative of having one interface for each method.

Ruby's duck typing

Let's see the previous code in it's Ruby version:


class ADuck
  def cuack
    #cuack the ADuck way
  end

  def swim
    #swim the ADuck way
  end
end

class BDuck
  def cuack
    #cuack the BDuck way
  end

  def swim
    #swim the BDuck way
  end
end

def client_method(can_cuack_and_swim)
  #code
  can_cuack_and_swim.cuack
  #...
  can_cuack_and_swim.swim
  #more code
end

client_method(ADuck.new)

#or you can split it in two like the previous C# example

def client_method(can_cuack, can_swim)
  #code
  can_cuack.cuack
  #...
  can_swim.swim
  #more code
end

client_method(ADuck.new, BDuck.new)

As you can see, we don't define interfaces, they are implicitly there because as we said earlier, interfaces are defined by the clients. client_method just asks that the object that is passed as a parameter implements the required method. If you create a new class that implements those required methods, then you implement client_method required interface, your client sees a duck because your object behaves the way it expects, like a duck, no more extra work for creating and mantaining your classes interfaces. That's simplicity and programmer friendliness, from there you get easier abstraction, free low coupling and the resultant increase in quality and productivity in the right way.

Welcome!

2007-10-24T01:06:00.000-02:00

Welcome to my technical blog!

Here I intend to have a place to write about all the things I find interesting in my profession. Next, I hope my posts are also interesting. My second objective is having a place to keep all those code snippets and small tips we all learn while working, which in my case are usually spread between books, computer files, notes, torn papers, and the most volatile of them all, my head. I just hope I don't forget my url.