Archive for the ‘Programming’ Category

Ideas for analysing legacy code

Saturday, May 31st, 2008

Basildon Coder wrote about the P.G.Wodehouse method of Refactoring, which reminded me of a graphic I have seen at the Museum of Modern Art in ‘Design and the elastic mind’: Code Profiles by W. Bradford Paley. A demo how the graphic evolved can be seen on the site of the Whitney Museum.

The basic idea is to have a program on one single page / in one single graphic, which shows the overall structure and density of the program part you are looking at. Bradford Pailey adds an overlay that shows the actual execution path on top of the code.

I wonder whether this idea, which is currently art rather than a programming tool,  can actually be implemented as part of an IDE plugin (I’m thinking of Eclipse as I’m working with Eclipse 99% of my time).

The code is of course already available in any IDE and profiling data could be obtained from the Eclipse Test and Performance Platform or other profiling tools.

However, it’s not yet clear to me how the interaction between the different classes and packages can be covered. The graphic by Bradford Pailey shows a program that consists of one file only – at least that’s what it looks like.

Tell a story

Tuesday, May 6th, 2008

This is about a topic, which developers are not really fond of: communication. We tend to sit in front of the computer for hours, not talking to anybody, letting our dear little synapsis do whatever they do etc., but the last thing we can really do well is to explain to others what seems to be absolutely clear to ourselves.

Today we had a meeting with our team about our build process. Well, the first part was easy: I talked about make / ant / maven to make my colleagues aware of some build tools and showed them an ant script that did the usual stuff, customized for our projects. It just took a few minutes until I heard some comments like “we didn’t need a build process on the mainframe for decades, why now on Windows/Java?”. I was quite glad, that we had a strict order from audit department, so I could blame audit that we have to do this “useless stuff”. Hopefully, they realized later on that a build process is really useful…

But the more difficult part was the discussion about how a build process can or should change the deployment process. It turned out that it was very difficult for most people (including me) to describe the different possible process steps (code review, branching, tagging, automated and manual testing etc.). We talked a lot, but suddenly I realized what we needed: a story.

When you talk with other people about processes, about user interaction or similar things, make up a short story with small steps like the following:

  1. We decide to freeze the code and deploy it and then
  2. We do a final code review and then
  3. We create the distribution and then
  4. We run our automatic test tool against the distribution and then
  5. We actually deploy it.

I don’t care for the details of the steps here, but the point is that you should try to embed your tools, your proposals or whatever in such a small story. We had quite a discussion about whether the deployment “should be atomic”. But what does this really mean? In practice? I couldn’t understand what my colleague meant before I used a story like the one above. Then suddenly we didn’t talk about atomic or not, instead we could say: in step 5 we deploy exactly the same distribution which has been created in step 3 OR we recreate the distribution in step 5, relying on the fact that neither the source code nor the general setup changed in the meantime.

You have probably been in similar situations again and again. Next time try to wrap your problem or proposal in a small story, your discussion partners being the leading characters. It can shorten a discussion by hours and may give you an easy time.

Safari Web Inspector

Sunday, April 27th, 2008

A week ago I bought my first Mac – a MacBook Pro – and I really think that this was a very good decision. It takes some time to get used to the different GUI and also to different shortcuts, for example I’m still not used to the Apple key, but that is most certainly just matter of time.

But as I do some web development from time to time, I was at first a bit disappointed when I searched for some Safari plugins that support web development. I used some firefox plugins to analyze the DOM and CSS and I really wanted the same in Safari. There is a list of interesting plugins for Safari, but I wasn’t satisfied until I found the Web Inspector. Absolutely straightforward to use and really useful. Exactly what I was looking for.

Here a quick overview about the main features:

  1. View the DOM hierarchy with folded nodes.
    This gives you a good overview about the structure and whenever you select a node, it is highlighted in the actual web site.
  2. Analyze the CSS for each node.
    You can see the CSS as defined in the style-sheet but also the actually applied style, which combines browser defaults, inherited CSS and the explicitly defined CSS.
  3. See all scripts, style-sheets, images or other media that is used for this page
  4. And quite a lot more….

If you are interested in web design and you are using Safari, this is really a must.