Not Waving But …

Well this is very interesting. A highly concurrent, safely distributed, dynamically updateable, highly reliable platform is just what is needed for a stock exchange or ECN (which is really just a less regulated exchange for other assets anyway).

Of course it will not help in a lot of areas. One of the irritating problems building financial systems is that so much is arbitrary. It evolved in an ad hoc manner with a huge amount of Not Invented Here going on; just look at the number of “Standard” Unique Identifier systems there are for Equities (You have to support them all…). No programming system will fix that, but being able to focus on managing it well because you are building on top of a system that runs phone switches (which are about as reliable as you get; outside Aerospace and Nuclear Installations) will be interesting.

I will be following Joel’s work if I can; and I’ll probably end up buying yet another Pragmatic Programmer title.

I have been feeling a bit dense and struggling with a problem of how to change the state of a running process in Erlang. The problem was that Erlang is a Functional language that only allows single assignment. The solution to holding state in Functional languages is (apparently, to keep the state in function parameters. Thanks to the folk on the Erlang Questions lists, sorry it took so long.

Well, what follows is the outcome of a rusty developer trying to get the hang of state in a functional, Actor based language. It is probably not very “erlangy” but I hope it helps others get out of the mess I was in.
If you are interested the key point for me was to realise that the receive loop happens inside the function (loop()). This means that the loop parameter is already bound and is accessible, but cannot be reassigned. Each set of code can use X but X can only be changed by calling loop() with a new value.

I hope the following makes sense (It does work).
-module(basic).
-export([start/0, rpc/2]).

start() ->

spawn(fun() -> loop(1) end).

rpc(Pid, Msg) ->

Pid ! {self(),Msg},
receive

{Pid, Response} -> Response

after 50 ->

io:format(”no response~n”)

end.

loop(X) ->

receive

{From, cancel} ->

io:format(”~p is exiting~n”, [From]),
From ! {self(), X};

{From, {get_x}} ->

io:format(”X is currently: ~p~n”, [X]),
From ! {self(), X},
loop(X);

{From, {set_x, Dx}} ->

io:format(”Changing X from: ~p to: ~p ~n”, [X, Dx]),
From ! {self(), Dx},
loop(Dx);

DoNotUnderstand ->

io:format(”~p does not understand: ~p ~n”, [self(), DoNotUnderstand]),
loop(X)

after 10000 ->

io:format(”Nothing has happened, X is:~p~n”,[X]),
loop(X)

end.

I have been following Matthiou Rieu’s Raven project using Rake and Gems to improve the Java build experience. Now he and Matthew Foemmel have got together to merge Raven and JRake.

I have high hopes for this and will be watching developments with interest.

I do hate it when I’ve been dense. I hate it even more when I have been smugly dense.

I have always had a thing about applications producing to much logging. Generally a production log line should only be produced if it is needed. That is if someone is going to look at it and take action on it or it is going to be part of an audit trail of some kind. I get quite worked up about the issue (a developer on my team once deployed an application that produced several Gigabytes of logging a day; “just in case”.)

Anyway, a couple of days ago, I had just related to Steve Freeman that in another project a previous developer had developed a rather byzantine Java logging framework that required a logging API to be passed in to all classes. I was sitting back waiting for the inevitable “yeah, what an idiot” response when Steve actually said “sounds like a good idea”.

Huh?

“Well”, continued Steve [this is from memory], “passing in the API allows you to test the log output of the class and, as logging is part of the class API it should be tested. If it is important that that line is produced you should test it. If it isn’t then you shouldn’t produce it.”

DOH! There we are, very succinct and to the point. If your production system produces it you should test it. Completely obvious in retrospect, and it may help solve the over logging problem most teams seem to have too.

(more…)

I have just read this article about Toyota’s continuous improvement culture. The article is very inspiring, I recommend it. The conclusion highlights a crucial point; one that is, I believe, the source of many of the problems introducing agile approaches.

“People who join Toyota from other companies, it’s a big shift for them,” … “They kind of don’t get it for a while.” They do what all American managers do–they keep trying to make their management objectives. “They’re moving forward, they’re improving, and they’re looking for a plateau. As long as you’re looking for that plateau,it seems like a constant struggle. It’s difficult. If you’re looking for a plateau, you’re going to be frustrated. There is no ’solution.’”

Even working at Toyota, you need that moment of Zen.

“Once you realize that it’s the process itself–that you’re not seeking a plateau–you can relax. Doing the task and doing the task better become one and the same thing,” Shook says. “This is what it means to come to work.”

Experienced agile proponents know that continuous improvement is part of the deal. In order to sell the process they usually sell a “brand” that is rolled out “as is” because they are selling to an organisation that is looking for the solution. The problem is that there is not a solution; not within a single organisation if it is any size, not even within a single team if it exists for any length of time.

There is not, and can never be, a perfect system or process. The world is a complex, ever changing environment so any system needs to continually adapt. Even if the environment did not change much changes in the process generate unforeseen consequences that require further changes to compensate.

When selling an Agile, Lean or whatever process you have to make the practitioners understand that this is simply a starting point for a continuous meta-process of continual reflection and improvement carried out by everyone involved. If they don’t understand that they (and you) are going to fail.

I recently attended a presentation in the City of London on a high powered infrastructure component and architecture.  The attendes were the usual bunch of attendees, IT guys at the geekier end of middling to senior management, early adopters of various technologies.

During one of the sessions the presenter was explaining how this technology could enable Service oriented architectures:

“I guess most of you are implmenting SOA now.  In fact, how many of you are implementing SOA right now?”

Of the forty attendees one hand was tentatively raised.

After my dalliance with Typo I am back on Wordpress.  I found I was spending too much time fiddling with Typo and not enough time writing (and the fact thta my half assed configuration just stopped working with monotonous regularitywas discouraging).

So here I am back on Wordpress.  It was a manual migration so it looks like I wrote a bunch of stuff today.

Lets see if I manage to spout off a little more now eh?

Well, Here I am on Typo. Still finding my way around and working out the details. I think I am going to have to learn one of the markups soon.

Thanks go to James Robertson for spotting this… In bytegeist Dermot Hogan argues that “Object Oriented Programming has failed”.

His first example of the massive failure of OO is:
“But let me give you two cases from my own experience. First was the company that was going to build a new OOP banking system. Great idea! Just create a banking class library and use it to build banking applications like cars off a production line; or like shelling peas - or whatever inane simile you want to come up with to disguise the lack of any deep analysis. Or if the truth be known, any analysis at all: this is the world of banking. The problem was (and is, and always will be) that processing dosh does not correspond to an OOP paradigm.”

Now, maybe I’m old fashioned, but my guess is that “the lack of any deep analysis. Or if the truth be known, any analysis at all” probably had something to do with it.

His second example is:
“I was working on fixing a bug in an object oriented Perl system. Yes. Perl can be made object oriented; it isn’t elegant (think of camels dancing) but it does work. I noticed the error low down in the class library and like a good programmer fixed it, got it tested and thought no more about it.” and then after causing trouble for a supposedly unrelated user it hit him: “What I’d done was to modify the behaviour of a base class. And this behaviour had then propagated with effortless ease through the whole damned system. But, with financial systems, this is a no-no. In a typical financial system, all responsible users have to sign off on a change before it goes live. After all this is real money we’re taking about here. Especially if it’s the bank’s own. With this particular system, that sign-off involved users in most of the capitals of Europe!”

Amazing! OO programming techniques now manage impact analysis, regression testing and change management! And I thought they were a way of managing complexity in code.

The sad thing is that there are a lot of developers and development managers out there who really do think that some new technique will eliminate the need for analysis, correct change management process, configuration management and all the other “boring” bits. Well, they haven’t; the “boring” bits are the bits that separate the professionals from the gifted, and not so gifted, amateurs. They can be done, or not, whether you are building with OO, procedural, relational and/or functional technologies. You can do them with lots of, or little, ceremony. They do, however, have to be done.

I had some code accepted into a Ruby project yesterday. Run, don’t walk to SVG::Graph, an SVG graphing package. I am quite pathetically excited about it. Does anyone know of an SVG viewer that runs in Firefox?