Martin Verzilli

Martin Verzilli

Always focusing in end users’ needs, Martin is our VP in user experience. Besides staying on the cutting edge as regards new technologies, he is particularly interested in applications related to medicine and humanitarian aid, subject on which he is writing his master thesis in Computer Science at UBA.

Install the RMagick gem in the painless way with Homebrew


Disclaimer: this section is just happy talking, if you want to get right to the beef, skip it and go right to the beef.

Yesterday was a sad day for me. It wasn’t meant to be like that.

I began the day with the intention of setting up a development environment for this amazing RoR application I’ll tell you about some other day. You know what it is like to set up a RoR environment: just a few gem installs here, a couple rakes there and voila! Two minutes after you started, you’re all set to begin coding.

Well, no. One of the required gems was RMagick, a wrapper of the arch-famous ImageMagick graphics processing library. In order to be able to install the RMagick gem, you need first to install ImageMagick.

So far so good, but this library has a whole lot of dependencies, and if you’re not a Unix and C Jedi (I’m not), it may be painful to get to a happy ending. I spent the day googling around looking for a good tutorial, and most of them recommended one of two alternatives:

  • Use MacPorts: tried, no success.
  • Use a script that some guy put together once. Basically it consisted of downloading, compiling and installing all the dependencies, and then ImageMagick: tried, no success.

I guess the reason why I failed with both alternatives is that at some point of the installation, I made a wrong a choice of version for any of the dependencies. By the end of the day, I still hadn’t been able to start debugging the application.

Then I spoke to my colleague Adrian Romero (who unfortunately doesn´t have a blog to point you to), and he suggested me to try with Homebrew. This is how the story ends, I used Homebrew, and was able to get back on track quite quickly.

Brewing magic

1) Install Homebrew

2) Install Ghostscript:

sudo brew install ghostscript

Pre-3) Update! Before brewing imagemagick, you may need to install git:

sudo brew install git

I might have not realized this step was necessary because I had already installed git in my machine before. Thanks Nielson for pointing out this!

3) Install ImageMagick:

sudo brew install imagemagick

Ok, step 3 may not be that easy. One of the dependencies, Little CMS, may fail to install because they removed the file from the URL where Homebrew looks for it. This causes the ImageMagick installation process to abort.

I worked this issue around by replacing the URL in the Little CMS Homebrew formula with a location where at the moment of this post’s publishing it can be found.

3a) Edit the formula:

sudo brew edit little-cms

3b) Look for this line:

url ''

3c) Replace with:

url '' (or an URL where you could find “lcms-1.19.tar.gz”)

3d) Try again to install ImageMagick (it should work now):

sudo brew install imagemagick

4) Welcome back home, just install the rmagick gem:

sudo gem install rmagick

5) Celebrate

Happy brewing!

How do I unit-test a class which depends on HttpContext?

Suppose you have to fix a bug in an ASP.NET application. You’re a TDD-guy so once you identify it, you write a test which should reproduce it. Then you run it and… null pointer exception. Your testing framework may have pointed you to the exact line, so you inspect it and see something like:

var foo = HttpContext.Current.[...];

Then you realize the guy who wrote the buggy class wasn’t a TDD-guy!

You need somehow to be able to inject an HttpContext object so you can run your tests without the need of running a web server. If you can do that, then you just mock it and… wait! HttpContext is a concrete class! So now, what?

Well, ASP.NET MVC comes with the assembly System.Web.Abstractions which adds classes to the System.Web namespace such as HttpContextBase, HttpRequestBase, and other abstractions of ASP.NET intrinsic objects.

Cool! Now you can mock HttpContextBase and inject it to the tested class.

Are you done? Not yet. HttpContextBase is of course a newer class than HttpContext, so not surprisingly HttpContext does not derive from HttpContextBase. Nevertheless, System.Web.Abstractions provides an HttpContextWrapper which does inherit from HttpContextBase and receives an instance of HttpContext through its constructor.

Now all you have to do is encapsulate or your uses of HttpContext.Current in some way that let’s you substitute it for an injected mock transparently for the user code.

In my case, it was more convenient to inject via a setter:

        private HttpContextBase context = null;
        /// <summary>
        /// Allows HttpContext injection, mainly for testing purposes
        /// </summary>
        public HttpContextBase CurrentHttpContext
                context = context ?? new HttpContextWrapper(HttpContext.Current);
                return context;
                context = value;

But it would be exactly the same to do it via a constructor. Then, you just have to replace all your HttpContext.Current calls with calls to the property CurrentHttpContext:

var foo = CurrentHttpContext[...];

When you see there’s an assembly called “Abstractions” with abstract classes and wrappers for preexisting concrete or even sealed classes, it becomes obvious that the ASP.NET MVC team has written its code with testability in mind, and that’s great! So kudos to them :)

Neyun is here!

I’m glad to announce the first Beta Release of Neyun has been oficially launched!

Neyun is a web application which lets you navigate and query through all your pictures, emails, messages, videos and links, no matter if they come from your RSS feeds or your Facebook, Gmail, Twitter, Flickr, YouTube, Digg or accounts.

Neyun automatically imports your data and extracts tags from it. Then you can visualize it in an homogeneous way, just like if it all came from the same application. You’ll have a tag cloud where you’ll find all these extracted tags. Using them, you’ll be able to filter your data: you can select one of them to see all its elements, or intersect two of them to see which elements are tagged with both.

But these are not the only ways of filtering your data. By activating the “timeline view” you’ll be able to see the elements matching your criteria ordered above a timeline, which gives you the ability to see when an element has been added at a glimpse.

If these filters are not enough, you can do a full text search over the elements.

Neyun also extracts relations between your elements. So, let’s say you are browsing a Facebook contact’s profile (let’s call him John Doe… pretty creative I am), you can see John’s pictures, events, etc, listed in the same place. So, what if you have a picture of your boyfriend in Flickr and somebody else of your Facebook list uploaded another one? You’d like them to be related to your boyfriend, wouldn’t you? Ok, we know Neyun is not thaaaaat smart to realize of this relation (at the moment… just give us some time to look into it :) ), but you can manually set it.

I could spend hours talking about Neyun (I acknowledge I’m not very objective when I do), but why don’t you try it yourself?  Go get your beta at Neyun’s homepage, and let me know what you think!


Programming paradigms and correctness

For many, programming nowadays means writing some code in an object oriented programming language such as C#, Java or C++ at a lower level. Well, those are the mainstream languages nowadays and the reigning paradigm is the object oriented one.

What is a programming paradigm? It’s a philosophical and theoretical framework within which solutions to problems of algorithmic nature are formulated. What a definition! Well, to say it simpler, a paradigm represents a way of thinking, thus a programming paradigm is one way of thinking about programming.

Let’s take for example C#, Java, C++, etc. They’re all in fact imperative object oriented languages. How do you think about programming when you use an imperative language? You’re thinking in state, which is a snapshot of your machine’s memory. Can you guess what I was thinking about when John Doe asked me to write a function which adds 5 to a given parameter and I wrote this?

int Add5(int x)
  for (int i = 0; i < 5; i++)
  return x;

This is what I thought: “x comes with a value, stored somewhere. I can add 1 to that value and store it again. So now I have x+1 instead. The next time I add 1, I’ll have x+2. If I add 1 five times… bingo!”

Ok, if I did think that “smoothly” it’ll take hours to write the simplest program, and I would be fired in a couple of days. I, as any imperative programmer, do it pretty naturally, but that’s because we have assumed and internalized the paradigm!

That kind of reasoning (“I have this value stored here, then I transform it in this way, then I transform the result in that way, etc”) is exactly what we do when we demonstrate correctness of an imperative program according to a specification.

And that happens in general: the mechanisms to prove correctness of a program in a given paradigm are deeply connected with the way we think when we write programs in that paradigm.

An alternative to the imperative paradigm is functional programming. This one may not be that familiar to all programmers, since it’s more rarely used in industry. Those with an academic background will know it for sure.

What are we thinking of when we program with a functional language? We are thinking in composing and applying functions. There’s no state here. If we need to repeat some task, we make use of recursion. Programs look a lot more like math equations than in imperative. Functional programming lovers, say a functional program is so much more declarative and self-evident than an imperative one. I agree, but that’s true once you got used to think “in functional”. At first, if you come from imperative programming, it’s not that easy to get it.

Let’s see our completely useless “Add5″ function written in Haskell, a functional programming language:

add5 :: Int -> Int
add5 x = addN 5 x

addN :: Int -> Int -> Int
addN 0 x = x
addN n x = 1 + addN x (n-1)

I had to use an auxiliary function called addN, which let’s me recurse over N and repeatedly add 1 five times. That’s what I meant when I said repetition is performed through recursion.

Now, have you noticed the arity of addN? Int -> Int -> Int. To simplify things, we could say the 2 first parts of it mean the function expects 2 ints as parameters, and the last one says it returns an int.  That would work. However, it would hide the power of functional programming. In functional programming, functions are first class citizens. They can be understood as operations as usual, but they can be used as values also. They can even be data structures. The way to parenthesize Int -> Int -> Int, is Int -> (Int -> Int). What does that mean? addN is a function which takes an Int and returns another function! The arity of the new function is Int -> Int. Knowing this, we could redefine add5 in a simpler way:

add5 = addN 5

See? We don’t need to use both parameters of addN at once. If we did, we would obtain an int. Instead, we just give it the first one, and we get a function! So we defined a whole family of functions by defining a single function! We can do this due to another feature of the paradigm: partial application of functions. We are partially applying addN when we just give it the first param.

This is just the top of an iceberg about functional programming. Trust me, it’s amazing.

How do we prove correctness in functional programming? Basically through induction. Since the repetition artifact is recursion, and all the statements are given as equations, this mathematical tool is all we need. That’s one of the advantages of not having to rely in state to perform our computations. And that gives us the clue of what we think of when we program in the functional paradigm: recursion and equations.

Finally, a third paradigm (there are dozens of paradigms!): the logic paradigm. It has a pretty famous language: Prolog.

What do we think when we program in the logic paradigm? Well, we think in what we don’t know and what we do know. The result we want to get is what we don’t know. The program consists in stating which are those things we don’t know and we want to know (called “goals”) and stating which things are true (called “knowledge base”).  Let’s go back to add5, now in Prolog:

nat(suc(X)): - nat(X).

add(zero, X, X).
add(suc(X), Y, suc(Z)) :- add(X, Y, Z).

add5(X, Y) :- add(X, 5, Y).

I also needed to define a couple of auxiliaries. First of all, in Prolog all our statements are predicates. A program is a set of predicates and a goal. In the first 2 lines, we define the naturals. We assert to things: “zero is a natural” and “if X is a natural, then suc(X) is a natural”. Then we define the relation “add”. First we say that the result of adding zero to any number is the same number. Then we say, “if I add one to one of the operands, then the result also must be greater by one”. As in functional, repetition is expressed through recursion. Then we define add5 in terms of add.

To execute this program, we have to ask Prolog to find what we don’t know in terms of this knowledge base. We would do it like this:

? add5(10, X)

And Prolog would answer 15. If there were more than one feasible result, we could ask Prolog to return another answer. The question means: “find any X such that add5(10, X) is true”. Prolog then tries to infer X from the given knowledge base.

How do we prove correctness? Well, the answer is… we don’t! The one who proves correctness in this case is Prolog. We just state truths, then Prolog proves that the result it found is correct according to those proves.

Knowing more than one programming paradigm helps us think in different ways when it comes to solving a problem. You may not use many of them usually, but it’s a great mind exercise to at least try them a couple of times. If you didn’t yet, I hope this post encourages you to take a look at them!