As an ArgoUML contributor I'm going to blog my activities here, so that they may draw interest by other developers or help other developers when doing tasks similar to what I've done. AND(!) the grand vision that makes an Argonaut what he is, TO THRIVE IN THE BIG DANGEROUS WORLD, TAKING THE Argo TO A GOOD SHORE ;-))

Monday, February 06, 2006

htmled revisited – Handbook entries to blog posts automated

I'm again revisiting my idea of developing automation for transforming content developed in my handbook into Argonaut's-life blog posts. The way I blog until now is seriously flawed, in that it does not follow the feeling that these entries are actualy made in the moment. This is the truth, with the catch that I will only put them in the blog when I'm online and in a batch way. It gives the wrong feeling to persons reading it and I must change this.

But, alas, to change it I must automate a bit and it is here that the problem begins. The high level requirements are identified here, although I'm now less ambitious and just want to automate the transformation of the content of my programmer's handbook entries into Argonaut's life posts.

Details of my handbook entries:

  • I write in a daily oriented way, always starting with H2 tag and with standard european date format – yyyy-mm-dd.
  • As stated previously the entries are written in a last in goes to the end manner.
  • The handbook is made of several HTML files, all in the same directory.
  • I also include several pictures that are stored in the handbook directory.

I would be happy if in a first step, the converter simply creates single posts out of the handbook entries. The end result could be a group of posts, structured around a directory tree of dates/posts. I may put the content by hand in the blog and the pictures in my website. One problem is the post title. Here I would choose to use H3 level tags. These are the normal heading level within the daily entries.

The automation makes also some formating that satisfies blogger requirements, such as one HTML post must be all within one line. It must fix my handbook intra-links into links that work in the blog, etc.

Friday, February 03, 2006

Executable List of Limitations

Another idea I had today is to put the List of Limitations of a program into the program. This would warn the user about some specific limitation only when he uses functionality that contains a limitation. I have done this with the C++ module reverse engineering part.

C++ module List of Limitations

I did this because it was a module I wanted to integrate, but, it has so many limitations that providing this possibility with warning users of the limitations would be too frustating for anyone than myself. But, it is a rather interesting way of explicitly warning users about something that could annoy them. Today I had the idea of inserting this for all limitations! It is something for the user like TODO and FIXME markups are for developer. With the advantage that he may turn off the LoL warnings after seeing them for the first time. This could be easy with the new technologies such as Aspect Oriented Programming and Attribute Oriented Programming (e.g., Java 5 Annotations).

The kind of user warning depends on the type of program, e.g., ArgoUML would present a warning message while a server application adds a warning sentence in the log. This is also a much better way to manage limitations than using LoL list within the change management tool or a document sent to the user / customer.


I helped finding and fixing [Issue 3917] unit tests failing - default model not initialized. It is very good that ArgoUML has unit tests. Without them I think that release problems would increase a lot. Near release almost everyone who cares will be a bit stressed and the possibility for errors will increase. For this we have the automated unit tests, acting as a safety net.

I should state that ArgoUML developers don't do as much as they should test driven development and test driven bug fixing. This is a practice that isn't enforced by the leader and by the commit rules. But, given time it might be...

Now, imagine that it was. Imagine that commiting a change in the production code should be done with a companion test or at least should be covered by tests. How difficult it would be to verify and automate this? We would need to mark commits to repository as atomic, make a complete build with unit tests executed with coverage and check that the commit is according to the coverage criteria. The commit is rolled back if it is sub-standard, being the commiter warned about this by email.

This requires atomic commits, something CVS does not have, but, Subversion does. It requires integration between the tools used in this scenario: version control system and build tool; build tool and coverage tool; build tool and coverage tool results details related to a set of specific changes; build tool and email system; mapping between version control system user IDs and users details (i.e. email).

Looking into the above requirements, I think that almost everything is possible with open source tools. It would require heavy build knowledge and a dedicated server with rollback rights, but, it is certainly possible.

One problem is the dependencies between one commit and the following. One much more important problem is the total lack of human review in all this!

No, in the end I think this is a bad idea. We should educate persons to follow good practices and then measure. Not put a machine enforcing this!

Wednesday, February 01, 2006

Am I a Software Engineer?

About two years ago I decided to change my job title to Software Engineer. I did this because I think that what is missing in the Software Development field is the application of Engineering practices.

Now I found out this paper about Software Engineering Myths. The author certainly has a point and I am indeed one person that according to him is abusing of the Software Engineer title. But, you can only say this if you agree with his central point that you only are doing Software Engineering if your work is derived from some formal basis. This is a rather biased view! What I've seen in other Engineering fields is that what more establishes their common ground is the set of practices they follow. I would even say that they aren't close to science, but they use recipes derived from this formal basis. Them they mix and match according to experience to do their work.

What are the practices that we are using today that would conceed a person the Software Engineering title? I think these are things like

  • requirements management
  • modeling
  • testing
  • simulations
  • metrics
  • use of a software development process

Some of these have indeed a formal and theoretical basis. Some don't. But, they are accepted practices by the whole field. They categorize the Software Engineer.

So, although I agree with some of the observations of Sahil Thaker, I will continue to use this title, since I belive what I do is Engineering and not plain development.

ArgoUML next release

ArgoUML is arriving the next stable release. Its a very interesting time since this is the first version that we have support of UML 1.4 and XMI 1.2 with the MDR library. The active core developers base has grown now with Ludo and Tom (kudos to them), which makes a big difference. We have development in installers and the new ArgoUML AndroMDA module.

I wouldn't say that our sail is fully inflated by a good steady wind, but, we're certainly going in that direction :-))

Reader Shared items