blog.tornkvist.org

The OTP docs.

tobbe — 2009-03-08T00:32:33+01:00

I played around with Xmerl today and came up with yet another approach to parse the simple example in an earlier post of mine.

The OTP docs are good but unfortunately often a bit too terse. How many times haven't I been tearing my hair trying to understand some aspects of the documentation. In most cases, a simple example would have been enough. I think the OTP team really should consider adding more examples to the docs. I mean, what's the point with docs that you don't understand?

--Tobbe

RFC 4226 - HMAC-Based One-Time Password Algorithm

tobbe — 2009-03-21T01:57:05+01:00

I have recently implemented RFC 4226 and put it on github. The idea is to explore ways of providing One-Time passwords in for example an OpenID setting, or for mobile applications. An old technique where comercial solutions have been around for years. Here is the beginning of an Open Source solution.

Next I'm thinking of writing a j2me app. (what?, this is unheard of, programming in Java at my age...) to run on my mobile. I've started to read up on the topic, written a Hello World program using the SUN WTK (the example program actually dies in the emulator because of a nullpointer exception...). I need to get a hold on the signing part of the MIDLet though.

--Tobbe

Seethrough and NItrogen

tobbe — 2009-04-07T04:37:26+02:00

I’ve made a little proof of concept of how Seethrough could be used as an alternative/complement to the current record-based way of constructing the HTML. The generated HTML source can be compared to the original. The postback work, but not the actual flash update. This is because I didn’t get the dom_state pickle stuff correct.

As little background to Seethrough I recommend the ZPT docs. A very nice read IMHO.

Currently, Nitrogen do lots of its magic with the help of the process dictionary. This makes it magical indeed but it also makes it hard to understand what exactly is going on. It would be better to, either pass around a ADT with a well defined API, or have an erlang process maintaining the magic. I would prefer the former since it minimies the side effects and makes debugging a lot easier. For example, in this little proof of concept, it would have been very easy to plug in the generation of Javascript, DomState, etc. But I guess it isn't too late to fix this, Nitrogen is still in its infancy.

--Tobbe

The importance of side-effect free coding

tobbe — 2009-04-07T14:38:57+02:00

There has recently been some discussions about ugly coding patterns like:

State1 = foo(State, ...
State2 = bar(State1, ...
State3 = baz(State2, ...

People have argued that they want destructive assignment, variable rebinding and what not.

But the thing is, doing it this way have very nice properties. For example:

It is easy to create Unit testcases, an effect of not relying on side-effects.
It is easy to debug, for example using a tool such as 'redbug' we can easily trace what data that enters a particular function (and leaves it), and we can do this in our production system.
A side-effect free function is like a lego block, i.e. it can easily be reused. Also, its internals is of no concern for anybody else and can safely be modified as long as the Input/Output interface doesn't change.

The example above shows the use of: State1...State2... etc. It is a case which seldom occurs, at least for me. As a thumb-of rule, I always try to make my function clauses short, constantly breaking down the code into smaller pieces of functions. This way, I seldom need to write code like the above example. If I need to perform multiple updates of a datastructure, I often write code like this:

foldf([in(Key,Val2), in(Key2,Val),....], DB).

where foldf/2 and in/2 looks like:

foldf(Fs,Db) -> lists:foldl(fun(F, Acc) -> F(Acc) end, Db, Fs).
in(K,V) -> fun(Db) -> in(K,V,Db) end.

But I think that regardless of what style of programming you choose, the benefits of side-effect free code that I've described, clearly outweigh the problems of the ugly looking code example. During my ~18 years of daily Erlang programming, I've come to notice that whenever I end up with really hard bugs, they often has to do with side-effects, either caused by the use of Mnesia, by some message-passing gone a stray or by timing issues. Confining your side-effects as much as possible makes it possible to build the rest of you system in a rock-solid lego fashion.

--Tobbe

QLC power

tobbe — 2009-07-03T14:08:31+02:00

I've been doing some more work on my query DSL (described in an earlier post) for an internal project at my work.

I had a number of 2GB sized Mnesia disk_only tables that I wanted to traverse in a QLC query as one single table. Writing a QLC handler solved that very nicely:

tables() ->
    Tables = all_tables(),
    TF = fun() -> next(Tables) end,
    InfoFun = fun(keypos) -> 2;
             (_)      -> undefined
          end,
    qlc:table(TF, [{info_fun, InfoFun}]).


next([T|_] = Tables) ->
    next(Tables, mnesia:dirty_first(T));
next([]) ->
    [].

next([_|Ts], '$end_of_table') ->
    next(Ts);
next([T|_] = Tables, Key) ->
    [hd(mnesia:dirty_read(T, Key)) |
     fun() -> next(Tables, mnesia:dirty_next(T,Key)) end];
next([], '$end_of_table') ->
    [].

So now I can make QLC queries like:

[T#tab.name || T <- my:tables(), T#tab.age > 42]

Hurray for QLC!

--Tobbe