Archive

Archive for October, 2009

Why I Love Erlang

2009/10/24 2 comments

Haven’t written in a while… been busy at work and my hobby project. This weekend I realized why I love Erlang… you don’t really understand the strength of Erlang until you have worked on heavy loaded live systems which need immediate attention.

I’m currently involved in a project which has a lot of subscribers. I can’t go into any details (NDA) but I can say this; We had a problem where one of our applications somewhere in the cluster would go down and not bounce back properly (very simple explanation of the problem :))

Anyway, we fixed a problem and got clearance to patch it and then went home. During the evening I wanted to check if the system was behaving, fortunately I could access the site from home. 4 logins later and a lot of SSH:ing and RSA keys and Personal codes I logged on to the shell… that’s when I realized that for me to check what I wanted to check on each node would be incredibly tedious since I would have to go through the connection procedure if I wanted to monitor everything at the same time OR I would have to disconnect and connect to another node OR I would have to RPC individually to each node I wanted to check.

Well anyway… after 3 seconds of thinking I just opened my text editor and wrote this:

ChkApp = fun(App) ->
  lists:map(fun(Node) ->
    case rpc:call(Node, application, which_applications, []) of
      {bad_rpc, Reason} ->
        {Node, Reason};
      Apps ->
        {Node, lists:keymember(App, 1, Apps)}
    end
  end,
  Cluster) end.

Copy/Paste into the shell and then just run…

x> ChkApp(my_application).
[{'node1@192.168.1.10', true},
 {'node2@192.168.1.20', true},
 {'node3@192.168.1.30', true}].

After you are done… monitoring/working just f(ChkApp). Done.

This maybe doesn’t look like much, but think about it…

  1. You can in a very easy way run a command on another node and get it back in Erlang terms.
  2. You can define Funs and run them how ever you want, you can even nest Funs and build up monitor/introspection tools on the fly
  3. There is no XML or complicated/tedious setup you have to make to call other nodes… you just… well… rpc:call them 🙂

Now a note of caution; Doing these sort of things on a Live system is very sensitive… be careful but I do have a golden rule I have set for myself: As long as you only read and don’t write data, then you are fine.

I was just sitting an imagining trying to do this in Java… and a big relief hit me…

It is these small things that make me love Erlang.

Advertisements
Categories: Erlang Tags:

more wxErlang bugs…

I’ve found two more bugs in wxErlang. The library is definitely not done yet but it has come really far. I guess it’s just a matter of people using it and ironing out the bugs. It looks really promising and GUI programming with Erlang is going to be as easy as a snapp (well… ehm…. almost :D)

The first bug occurs when net_kernel isn’t started before you create and object and then start net_kernel and the object is called (kindof). I had a temporary fix for that but Dan Gudmundsson is going to fix it in better way… my patch was simply a workaround.
details here: http://www.nabble.com/wxe_server-bug–%28and-patch%29-td25890987.html

Second bug is a bit strange and I don’t have it confirmed yet that it is a bug. It happens when you try to destroy an object from an event callback. E.g. if you create a frame, then connect left_down event, handle the event in a callback and destroy the frame then you can not create a new frame until the process has returned from the callback function.
details here: http://www.nabble.com/wx_object-locks-td25925583.html

Peace.

Categories: Erlang Tags: ,

in case in case this happens

2009/10/15 2 comments

I truly hate nested case clauses in Erlang they are the root of all that is unholy and should be banned. I have what some consider a fanatic principal when it comes to case clauses and that is: Never have more then one case clause per function. Sure you will argue that it’s not that bad and if you know what you are doing it’s fine and sometimes you can’t avoid it and bla bla bla!

Well guess what, it sucks and I got solid proof to back that!

Why nested case clauses suck

consider this code:

case foo() of
  not_foo ->
    case bar() of
      not_bar ->
        case baz() of
          not_baz ->
            {error, none};
          yes_baz ->
            baz
        end;
     yes_bar ->
        bar
    end;
  yes_foo ->
    foo
end.

And OPS you get a cause_clause error in your live system… and it happens a little bit now and then and you have no idea why or when and your tests sure aren’t finding this really nasty edge case… so What do you do now??. You could try to trace foo(), bar() and baz() but tracing on a live environment isn’t a very good idea… besides you have to leave your trace on for possible hours because the bug might not happen very often! Well you could argue that if you don’t know what the possible return values are you designed it wrong… well that is kindof the point I’m trying to get across! There are a lot of versions on how to “re-write” this.. an example is the classic “construct a tuple” shortcut:

case {foo(), bar(), baz()} of
  {_, _, yes_baz} -> baz;
  {_, yes_bar, _} -> bar;
  {yes_foo, _, _} -> foo
end.

I put the first clause matching the right hand side first on purpose to show that this short cut really doesn’t make sense. In this case you are running 3 commands (which might very well even have dependencies) and you only want to know one of them. In case of true/false functions this is another common type:

case (foo() orelse bar() orelse baz()) of
  true ->
    %% do something...
  false ->
    %% do something else...
end.

problem here is that you don’t know which one succeeded or caused the truth value. In the end I have found that breaking this down in three functions is the best:

f() ->
 case foo() of
   true -> foo;
   false -> b()
 end.

b() ->
 case bar() of
   true -> bar;
   false -> c()
 end.

...

It would still give you a more readable code, if you get an error such as case clause then you know where it is. You wouldn’t want to trace a live system but imagine that you still did, then you would in this case have to trace at least three cases in the nested case clause version while in this version you can trace only 1 (This is still a fairly naive way of looking at it, but it is still better).

NOTE: Seriously, don’t do it though (trace a live system), I turned on a trace in a live system once and by mistake put a trace on a very actively used function, we had to kill the node! but being cleaver as we usually are the node was in such a way that it could safely be killed because we had other nodes that we could fail over on without loosing any data (hahaa!)… but in the end I still was lucky and it was a stupid thing to do :D.

If you have 1 case clause per function and you have small functions then you are much much more likely to know where an error will end up, it becomes clear as day… you know what you called, and with what argument so you should be able to narrow down the reasons for the error. Simply put; you can’t trace case clauses and that means a lot.

I think I shall call this one the “single clause” philosophy (since it probably applies to if clauses as well). The fact is that it has helped me shorten my functions a lot. Probably the number one mistake that people do in functional programming do is to treat functions other then functions; using if statements instead of pattern matching etc. Functions should be small (maybe 5-10 lines, very rarely more) and do only 1 thing (unless it is a glue function which its purpose is to call other functions).

Pattern matching is the power of all righteous.

Categories: Erlang, Philosophy Tags: ,

Erlang User Conference! Oh yeah :)

Found out yesterday that I’m going! This is great! I love the conferences, I have been to 1 EUC before and 2 Erlang Factories. You get to meet all these nerds squeezed into a big room presenting and discussing nerdy things and once in a while someone cracks a nerdy joke and everyone laughs in a nerdy laugh.

I Love it… 🙂 See you all there!

Erlang User Conference

 

Categories: Erlang Tags:

wx_object patch

wx_object.erl has had a few problems. I’ve posted a patch to fix these problems. Quoting my email to erlang-patches:

I’ve attached a patch that fixes two issues with the wx_object.erl file.

1) I removed a pattern match in the start functions so that if a server returns {stop, …} in the init function it doesn’t crash with a badmatch error.

2) I added 2 call functions which makes it possible to call an wx_object using the registered name that was used when creating the object. Currently it was only possible to make a call to an object when you have the reference and not by name.

I have tested it in normal cases but I can’t guarantee 100% bugfree fixes 😀
This patch will get anyone going until these issues are fixed (or patch applied) to the release.

cheers,
/Mazen

Until I find out how to attach files to this blog… you can find the patch here: http://www.nabble.com/wx_object-fixes.-td25819342.html

Categories: Erlang Tags: , ,

Break it down…

2009/10/04 3 comments

For some reason when I work on personal software projects I always start on big ambitious 0nes and never small realistic ones. I get this idea and I get ambitious and work every second I have to spare on it and then burn out and get tired of it and leave it, and all this within a really short timespan.

Most ideas I get have to do with a small concept or technique I want to try out but it seems that I can’t make sense of them unless I put it in a bigger picture. Many of my friends seem to be able to just try out something or build something just for the heck of it but I can’t seem to do that; seriously starting to wonder if there is anything wrong with me hehe 🙂 Sure I’ve written small code snippets to test something but that is different; the concept or technique I’m referring to is a lot bigger then small code snippets.

As soon as I have an idea I have to put it in a bigger picture. All of my projects have been like that and they end up half (more often much less then half) done. I complete the project up until the end where the concept or idea I want to try out is done or a conclusion has reached, proven successful or otherwise, nevertheless, a conclusion.

The project before the one I am currently working on the exact same thing happened, I had a great idea and I started implementing it. As all other projects before it I burnt out and left it after a week of intense hacking, exactly where I leave the other projects; after I reach a conclusion.

The current project I’m working with however became different. When I was to start it I first hesitated and asked myself if this would be yet another boom-bam-thank-you-mam project, so I decided to use a different approach. When reading my favourite news site once (reddit) I came across a user comment (what he was commenting about, I don’t recall) which had a great idea about how to organise projects like the ones I wanted to complete.

I realised that the core problem was not that I didn’t want to complete the project or that I was too lazy, no the real problem was that I didn’t always have hours or even one hour to spend on it. This caused me to shrug every time I thought about continuing the project, I saw this big black hole in front of me consuming all my time when I have so much other stuff to do, even if the project was really really interesting, I simply didn’t have the time!

Realising this was a big break through, now I only had to do what the person in that comment suggest to be done, namely: break down all the activities in 10-15 minute tasks or similar (can’t remember the exact minutes he mentioned but that’s beside the point). I set of to plan the project like I always do and as things started getting closer to actually starting to implement the thing I started making up small tasks in my head about what needed to be done. Every time I wanted to work on the project I now knew that it wouldn’t take more then a short moment of my time to move it forward somewhat.

A task can be anything, and it can be really small… I have realised that there is no task that can’t be broken down, sometimes it can even be to read a section of documentation just to know what to do next and in some cases I have broken down the task of reading one section into two tasks; read the first and the second part. I will try to find the comment on reddit (it was a long time ago) but this has seriously allowed me to push my projects forward even thought I don’t have very much time to spare.

This is also the way I’m writing this blog 🙂

Categories: Personal Tags:

Secret Erlang project finally taking shape…

For about 4-5 months now I have scribbled, pondered, sketched, asked diffuse questions to colleagues and played around with wxErlang. When I finally had a clear picture of how I wanted it I abandoned the duct tape programming and continued on to the extreme programming style.

Today I had a big break through… I was able to finish something that has taken me more then 2 weeks to solve. It has also meant hacking a small part of the wx_object module that comes with wxErlang. I sent an email to the erlang-bugs mailing list and had 1 response… but I hope the bug of the second question will be fixed. I’m going to post a patch to erlang-patches soon.

I have also discovered something. Test driven development in this case sucks, it is so time consuming and so stupid that I will never ever touch it again (in this project). Test driven development only work if you use small components with clear interfaces which can be isolated (fairly) easy from other parts of the system… otherwise there is no use. I don’t want to have to spend 90% of my time writing stubs which I have to change every 5 minutes just to be able to run the tests… it’s stupid!

I use test driven development (kind of, no one I have ever met in my life does TDD 100% they way it is suppose to be done) every single day, but in a way that makes sense. In this type of project, a project that has to do with wxErlang and GUIs, it is a complete waste of time. I’m going to use a more structured approach where when ever I hit a question I want to answer I go back to the drawing board and redesign and build prototypes and then add the solution to the main branch without creating a single test case. The tests I can write afterwards… there is no shame in using a hammer to hammer down a nail, and a screw driver to screw down a screw. Face it.. TDD isn’t always going to work…

Until then… I have some more issues to resolve 🙂

Categories: Erlang Tags: ,