A while ago I mentioned how I had to switch off my spambot protection because of something broken in the new Wordpress Indigo theme I installed. It turned out the theme writer forgot to add all the necessary “plugin API hooks” to the theme files. The hooks are basically a set of markers that Wordpress uses to mark locations in the theme where extra functionality can be inserted with the help of plug-ins.

The Peter’s Anti-Spam Image Plugin that I use for comments hooks into the theme at the location marked with the comment_form hook. This hook was missing from the comments.php and the Anti-Spam plugin was not displaying.

I double checked the remaining hooks and found a couple of other ones missing as well. Makes you wonder how difficult it would be for the Wordpress Theme site to create an automatic theme checker that verifies the presence of required plugin hooks for all newly uploaded themes? This would serve as a basic code review for theme writers and I’m sure it would save many people trying out new themes from wasting time figuring out why functionality that worked on their previous theme has suddenly stopped working when they applied a new theme.

Oh and btw, it took the spambots about a month to index the site again and start posting spam comments. In the last week I would get between 3-5 spam posts per day which was the main reason why I finally got around to fixing the antispam plugin.

I’ve been spending quite a bit of time doing systems design with the help of component diagrams this week. I used to draw component diagrams as a bunch of simple boxes with a few interconnecting lines to show “relationships” between sub-components and call them high-level component diagrams. I was therefore quite surprised by - when done properly - how much additional information can be captured in this type of diagram e.g. for our SOA project we can show details of specific interface points between components.

As this is a new project we’re using the top-down approach to design. We have 2 remote teams designing separate but very interconnected parts of a fairly complex SOA system and the teams create and share the component diagrams for the individual pieces to help both sides understand each other’s designs and make sure everybody is on the same page. It’s working well. Design inconsistencies are spotted quickly and misunderstandings are avoided as we peer-review each other’s diagrams. We all prefer drawing boxes and arrows rather than writing copious amounts of text and diagrams are easy to update so the cycle is quick and productivity is high.

For modeling we use Borland Together Architect (finally something that knows UML 2.0!). Deliverables of our design phase can be either JPG exported diagrams or the entire Together Architect workspace as is. This is fantastic as we don’t waste time creating those of-little-value 100-page documents based on some 50Mb template which no one reads anyways and they are outdated the moment you start development.

With Together Architect I can take this whiteboard drawing:

and convert it into this in about 10 minutes:

I have used the following articles as reference during the component design stage:

• UML Component Diagrams - Really this one is all you need. It’s a great article that talks about component diagram best practices, describes some of the nuances in modeling components, describes the various ways to model relationships, etc. Excellent refresher article! Also:
• UML Basics: The Component Diagram (from IBM)
• Sparx Systems UML 2.0 Tutorial

As you start working with component diagrams you’ll quickly realise which things make sense and which don’t. Maybe it’s not necessary to show the DAO classes as a component on every diagram. Maybe indicating only a single type of relationship is good enough for this design and leaves it less cluttered. I believe that there is no right or wrong way of creating these diagrams. Different projects will have different requirements with respect to detail, types of components you want to show etc. As long as everybody on the team has the same understanding of diagram semantics and the diagrams are shared and reviewed across the team your project should get the maximum benefit of this stage of the design.

Had a short panic attack the other day. Got an email saying my blog got hacked! Included in the email were my user id and password to the blog. My first thought “how the ?$#@” but then the *hacker* went on to point out how in the code for the todolist in my previous blog entry which I made available for download I accidentally left in the login details to my site. To make matters worse the password was the same I used for my web mail account which he went on to log on to send the actual email from.. what a slap in the face of this sloppy blog writer…

I’m glad this was noticed by somebody honest enough to point this out to me. One can only have nightmares about the *bad* stuff that could happen to your identity should it get into the wrong hands..

On a different note - a couple of updates to the blog itself over the last few weeks: I have made my old wiki public - maybe somebody will find useful information in there - link available through the top menu or here. I have also added a link to my new and growing collection of external pages I have recently read and found interesting in one way or another. I will keep this updated as often as need be..

I’m back doing real work this week - even got some coding to do, playing around with Spring again. The company I’m currently working for uses several features of Spring I haven’t used before but they certainly highlight Spring’s maturity and ability to integrate with everything - from EJBs and schedulers and configuration setups to Spring MVC and DWR and Grails. I’m waiting for Aggie to spring-load a bean that controls one of the industrial robots that she’s been working with.

Some of the things that Spring is used for here:

• Configuration management using a custom PropertyPlaceholderConfigurer
  This moves configuration of bean properties from the applicationContext.xml file into config files where they can be maintained based on environment and/or host system.
• Instantiating a shared Spring Context from EJBs with beanRefContext.xml
  This is also discussed here. I will be looking into this in more detail soon on an upcoming project. I have run into some of the problems that the first poster mentioned and want to investigate further.
• EJB Service Proxies using SimpleRemoteStatelessSessionProxyFactoryBean.
  This really highlights what Spring is about - dependency injection. Being able to treat an EJB as any other bean allows for easy substitution of a mock bean for testing etc. The ProxyFactoryBean also allows for easy configuration of all EJB properties in the applicationContext.xml file.

I also found this interesting link about Spring Best Practices. It mentions autowiring - don’t think I’ve ever used it - must look into that.