Daniel Cadenas

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.