Firefox, Fiddler and HTTPS

Today I was debugging some interaction between one of our products and Twitter 1.1 API protected by OAuth 1.0a . As it happens, I was using Fiddler to have a look at tokens being passed back and forth.

As I finished my debug session, I forgot to turn off Fiddler session and wanted to check my emails on gmail. I was getting warnings by Firefox about google SSL certificate chain not being valid. Strange. Then I moved to Facebook and there I also had all kind of problems. After adding an exception for to the SSL trust (!) I was able to open the site, but as text only without any additional resource (images, css): you can imagine what Facebook site looked like. I could not even browse to because Firefox did not even trust that side (ironically enough…)!

After a white it dawned on my that Fiddler might be the culprit: surely enough, after turning off Fiddler everything went back to normal.

So the moral of the story is: if you see sudden problems with Firefox and HTTPS, be sure that you don’t have Fiddler running in the background causing havoc. :)

UPDATE: Eric in the comments suggests how to configure Firefox to accept Fiddler’s certificate (see

Posted in Misc, Tools | Tagged , , , | 2 Comments

Dependency Injection for Dummies

Antonio Vidal has translated this post into Spanish: you can find it here.

Dependency injection is a very simple concept: if you have an object that interacts with other objects the responsibility of finding a reference to those objects at run time is moved outside of the object itself.

What does it mean for an object to "interact" with other objects? Generally it means invoking methods or reading properties from those objects. So if we have a class A that invokes method Calculate on class B, we can say that A interacts with B.

In the following example we show class A interacting with class B. We can equally say that A depends on class B to fulfill a responsibility. In this case, it not only invokes its method Calculate but it also creates a new instance of that class.

class A
  private B _b;

  public A
    _b = new B();
  public int SomeMethod()
    return (_b.Calculate() * 2);

In the following example, on the other side, the responsibility of getting a reference to an implementation of a class of type B is moved outside of A:

class A
  private B _b;
  public A(B b) 
    _b = b; 
  public int SomeMethod()
    return _(b.Calculate * 2);

In this case we say that a dependency (B) has been injected into A, via the constructor. Of course, you can also inject dependencies via a property (or even a regular method), like in the following example:

class A
  private B _b;

  public B B 
     get { return _b; }
     set { _b = value; }

  public int SomeMethod()
    if (_b != null)
        return _b.RetrieveValue() * 2;}
        return -1;

So this is all there is about dependency injection. Everything else just builds on this core concept.

Like for example Inversion Of Control (IoC) tools which helps you wiring together your objects at run time, injecting all dependencies as needed. So what exactly is Inversion of Control and how does it relate to Dependency Injection (DI)?

I like to associate IoC to the Hollywood Principle: "Don't call us, we'll call you". IoC is a design principle where reusable generic code controls the execution of problem-specific code: it is a characteristic of many frameworks, where the application is built extending or customizing a common skeleton; you put your own classes at specific points and the framework will call you when needed.

You can use an IoC container as a framework to perform Dependency Injection on your behalf: you tell the container which are the concrete implementation classes for your dependencies and the container will make sure that your constructors or setters will be called with the right objects.

Therefore, IoC containers are just a convenience to simplify how dependency injection is handled. But even if you don't use one you could still manually perform dependency injection.

(If you want to have a look at how an IoC container works you can jump to my mini tutorial on Ninject).

Why is the concept of dependency injection important? Because by applying it, you simplify your design (separating the responsibility of using an object from the responsibility of retrieving that object) and your code becomes much easier to test, since you can mock out the dependencies substituting them with fake (stub) objects. But that is the subject for another post.

Posted in .NET, C#, Design and Patterns | Tagged , , , | 6 Comments

Why Functional Programming Matters in Fsharp

Today I've found myself reading again the excellent paper Why Functional Programming Matters, where the author describes the core activity of programming in a functional fashion in terms of "glueing functions together".

It's been a while since I last played around with F#. So I decided this would be a good time to refresh some of the core concepts by translating some of the examples from his paper into F#.


The paper starts off describing how a reduce function could be devised, extrapolating a common behavior from a certain set of functions. Let's first consider a function to sum all the items in a list:

    let add a b = a + b
    let rec sum l =
        match l with
        | [] -> 0
        | h::t -> add h (sum t)

Nothing too fancy going on here. Let's now consider a similar function that instead multiplies together all the items in a list:

    let mul a b = a * b
    let rec product l =
        match l with
        | [] -> 1
        | h::t -> mul h (product t)

If you compare the structure of the two functions sum and product you can see that the two are very similar. The are only two differences between the two:

  • The value being returned when an empty list is matched (0 vs 1).
  • The function being applied between the head of the list and the application of the recursive function to the remaining of the list (add vs mul)

It's easy, then, to extrapolate a more general reduce function, as follows:

    let rec reduce f a l =
        match l with 
        | [] -> a
        | h::t -> f h ((reduce f a) t)

Let's consider all the pieces step by step:

  • reduce is a (recursive) function accepting a function f, a value a and a list l.
  • f is the function that we want to apply between two elements of the list (sum or mul in the two examples above)
  • a is the value that we want to return when f is applied to the empty list (0 or 1 respectively), and
  • l is the actual list we want to operate on.

Let's try this new function in the interactive window:

  > reduce;;
  val it : (('a -> 'b -> 'b) -> 'b -> 'a list -> 'b)
  > reduce add 0 [1;2;3];;
  val it : int = 6
  > reduce mul 1 [1;2;3];;
  val it : int = 6

As you see, the compiler infers the types involved in reduce as follows:

  • ('a -> 'b -> b') is the description of f: a function that takes two arguments of type 'a and 'b and returns one item of type 'b (note that 'a and 'b may in some cases represent the same type, as with add and mul).
  • 'b is a parameter of the same type as the one returned by f.
  • 'a listis a list of items the same type as the first argument of f.
  • 'b is finally the return type of the whole reduction process
  • .

There's an interesting special case: when 'b is 'a list. That is, when f has the following form: ('a -> a' list -> a' list). A function receiving an item and a list and returning another list. Can you think of any function like that? What about concatenating an item and a list?

    let cons a l = a::l

Let's see how the F# interactive interprets the new function we've just created and an example of usage:

    > cons;;
    val it : ('a -> 'a list -> 'a list)
    > cons 1 [2; 3];;
    val it : int list = [1; 2; 3]

And we now consider cons as our f function, first parameter of the reduce, we can write for example:

    let append a b = reduce cons b a
    let copy l = reduce cons l [] 

where append concatenates two lists and copy simply replicates any given list:

    > append;;
    val it : ('a list -> 'a list -> 'a list)
    > append [1;2] [3;4];;
    val it : int list = [1; 2; 3; 4]
    >  copy;;
    val it : ('a list -> 'a list)
    > copy [1;2;3];;
    val it : int list = [1; 2; 3]

In the following post we'll continue translating some more core functions from the "Why Functional Programming Matters" into F#. Stay tuned!

Posted in F# | Tagged , | 2 Comments