Tuesday, 30 October 2007

is struts that great?

People rave on about Struts and a lot of architects choose it for their technology stack, but I have to wonder why. J2EE already has a framework, it's called Servlets and JSPs. It uses a centralised file-based configuration (web.xml), and if people use it correctly, there's no reason why you can't use an MVC model for your application (i.e. apply some common sense and good practices). In fact, you could argue that Servlets and JSPs are just the "V" part of the MVC model, with Session Beans being the "C" part and Entity Beans being the "M" part.

Likewise Struts is the view part of the MVC model, you still have to code the control and model parts yourself. Actions are not the controller part, they are a the link between the view and the controller.

The reference article states the following advantages of Struts:
  • Centralized File-Based Configuration. Just like a regular J2EE application then, with it's web.xml.
  • Form Beans. Not exactly difficult to code up yourself and what Struts gives you doesn't really utilise a lot of re-use.
  • Bean Tags. OK, so struts gives you this tag library and a few other cool tag libraries, but they are trivial to implement and could easily be put in to a re-use library within your own company.
  • HTML Tags. Ditto.
  • Form Field Validation. Yeah OK, pretty useful, but have you seen the implementation? What a mess.
  • Consistent Approach. As I said in one of my earlier comments, you still have to code a lot of stuff yourself, consistent approach is about programming in a sensible fashion. Further more, templating engines (e.g. velocity) and MDA are becoming used more extensively, and these provide a consistent approach. Struts does not actually enforce any kind of consistency. The configuration is a mess and actions are simply Servlets with a different name.
So, I partially agree with a couple of the points, but I fully agree with all the disadvantages mentioned.

I really feel it is a waste of time getting up to speed with Struts. You're going to lose focus on real programming and become swamped by messy configuration and inappropriate framework code when there already exists a simple and effective framework in the form of Servlets and JSPs. The only good frameworks are the ones that encourage good programming practices and almost feel as though they are an extension of the language, or a filler of the gaps in the language. (Yes, of course I am talking about OSGi)

That all said, I have no experience with Struts2. Does the same spaghetti configuration exist? Are actions still bloated, glorified Servlets? To be honest, I can't even be bothered trying to find out!

In conclusion, Struts (like other bloated frameworks, read Hibernate) are a waste of time and just add unnecessary overhead and footprint to any project. Get back to basics and keep things simple. Think about re-use as you write your code and you will end up with a "framework" that works for you and your company, but don't go looking to create one!

Thursday, 25 October 2007

Gaikokugo - a wizard in 30 minutes

I was trying to enter some vocabulary in to Gaikokugo, the language learning suite I have been developing and realised that it was a bit tedious. The vocabularly appears in a sheet and to enter new vocabulary I had the following process:
  • double click the sheet to create a new row
  • click on the new row and edit the values in the properties view (using the mouse to move between properties)
  • tab out of the properties view and double click the sheet to start again
This wasn't optimal, so I decided to implement the following:
  • Select "New Entry..." from the "View" menu OR double click the sheet.
  • A wizard opens and focus is set to the "local" word input. There are also inputs for the foreign words, categories and level, and a check box (which is checked) so that the wizard opens again once "finished".
  • Now I can quickly enter vocabulary simply by entering the local word(s), foreign word(s) and hitting enter to have the wizard save the input and re-open to start again, or I can tab through an also update the categories and level, which are defaulted to whatever is selected in the CategoryView.
This took about 30 minutes to implement, which basically means the length of my commute in to Glasgow. Once you get over the learning curve menus, forms, wizards and so on are very easy to implement with Eclipse RCP.

I have some refactoring to do. I have a VocabularlySheet and the NewVocabularyWizard. I need to abstract these in to "LanguageEntry" (the super-class of Vocabulary, Phrase and Conversation) generic components so that I can reuse the same code in the other perspectives.

One thing I find confusing about Eclipse is the terminology it uses. As a user of Eclipse I would be find it difficult to use the concept of pages, perspectives and views. As a result I have called perspectives views for the sake of the user. They select either Vocabulary, Phrase or Conversation view from the view menu, but what they are really doing is changing perspective and seeing a bunch of different Eclipse-views.

Wednesday, 17 October 2007

OSGi and UML - again

I think I'm happy with it now, though it has took some time getting here. I suspect Peter Kriens could pick holes in this (please), but I feel this is a good representation of how the bundles in Gaikokugo, my language learning application, look:


This morning I decided to email my friend and mentor John Skelton, co-author of Schaum's Outlines: UML to ask for some advice. As I was explaining the situation to him I essentially made the breakthrough that I realised it simply isn't important to show the bundle that the interface (the service) is declared in and everything else just fell in to place. Looking back I think Peter had been trying to drill this in to my thick head. =)

For instance, in a more complicated example I've been using at work, I have the interface out on it's own. The bundle that contains the interface uses the interface, even though it also declares it but the interface is not shown within a bundle, it is just shown out there being used by various bundles. By drilling down in to the UML model you can see which bundle the interface belongs to and so I have shown this in a seperate package (class) diagram. These diagrams are going to become part of the softare architecture document I'm writing (which is a new one for me as I usually hate writing them, but am enjoying it this time - perhaps I'm getting old?).

So in the above diagram, I have used an absolutely bog standard UML2 implementation diagram (aka component diagram). I think it's pretty clear that the "db" bundle exposes the interface, that the "db.db4o" bundle implements the interface and that the "rcp" and "db4o.test" bundles use the interface. There's no mention of a dependancy on the bundle that exposes the interface, just the interface itself, which is the best approach for keeping the system as loosely coupled as possible. In the above example the interface is shown inside the bundle that contains the interface is only shown because it doesn't do anything with the interface itself.

The one thing that is missing in the diagram above is the service listener that Peter mentions in his article ( as part of the register, get, listen operations that can be done on a service) but I am happy this can be represented with a simple dependancy connector that states the relationship is one of listener.

In conclusion, this is perhaps not as elegant as Peter's notation, but I'm happy that I can get the message across using UML. I can imagine that the diagrams could get complicated, but at the same time that kind of forces the architect to break things down in to more managable chunks. That would mean it is hard to get a view of the big picture, so it is a matter of swings and round-abouts.

Oh, and I did find a free tool for doing drawings, it was in Open Office! It's the first time I've had office software on my personal hardware for ages as I have been using Google Docs for some time now. Hopefully Google will come up with a nice online collaborative drawing tool next - hint hint! ;-)

Now, my next problem is exposing my OSGi services as WebServices, but I'll leave that one for another post.

roles in the software world

I was pondering what certain "roles" within software companies should actually mean. I think it's a grey area, though I'm not sure it even matters really. Here's a few that I encounter fairly often and how I interpret them. I have also written them up in terms of my perceived "pecking order" with a.n.organisation.

Please feel free to post other ones and/or your interpretations. Which one of these is closest to your title? Do you feel you meet my description? If not, is your description appropriate to the role you actually do, not just the name?

Programmer

Quite rare these days, I feel, but if someone had this role I would say that they basically just wrote code. No design or interpretation, they take a spec and make it work. They would most likely contribute to a piece of software, but not be directly responsible for the final deliverable, that being handled by someone more senior.

Analyst Programmer

Like the programmer, but able to take requirements and assess the feasibility of what is required then create a spec and basically code it up.

('Software' | specialisation) Developer

(e.g. Software Developer, Java Developer, Senior Java Developer, etc)

Like the analyst programmer, however, a developer would be able to produce the final deployable result. They may also be required to contribute to estimates and mentor more junior members of the team. The design output from a developer is most likely minimal. After the spec, they code.

The senior version may manage a small team of other developers, delegating tasks throughout the project lifecycle. They would no doubt have a hand in the planning of the project's deliverables and milestones.

('Software' | specialisation) Engineer

A specialist version of the Developer that will also produce high quality software design documentation to a level and detail in which it can be understood by other members of the team. An engineer may also be required to capture requirements, performance analysis, high level design and detailed design.

The senior version is similar to the "Senior" Developer in that they will be leading small teams, mentoring, delegating work, contributing to project plans and so on.

I'd like to think this is where I am at now.

Technical Architect (TA)

My feeling here is that there's quite a bit of overlap between this role and Engineer role. The major difference is that the TA probably won't touch any code unless absolutely necessary. They may be involved in the design of the architecture for multiple projects at the same. The role is primarily a documentation creation and work validation role, they would most likely make the biggest contribution a software architecture document, for instance. In an organisation with a TA and Senior Engineers, these roles would probably work together with the TA delegating the responsibility of delegating tasks to the Software Engineer.

Solutions Architect (SA)

My view of what the SA should be is that of someone who is ultimately responsible and accountable for one or more projects. The SA collates all the information about the final solution; deployment environments, software versions, managing non-functional requirements and so on. It is also their responsibility to validate the technical architecture of the software solution, though not necessarily to have a hand in designing it. They will typically add all the guff to the software archiecture document that is not actually to do with the software, you know, the stuff that everyone skips and just makes the 30 page succint document 120 pages.

While the role is perceived as "higher" than that of a TA, the SAs I have met have usually been less technically competant than the senior developers/engineers on the team. A good SA should be able to bridge the gaps between the technical people, business people, project management and quality assurance. They are natural leaders and amicable.

Monday, 15 October 2007

OSGi services

I think I'm finally starting to "get" where Peter Kriens was coming from in his blog entry on OSGI design techniques.

When initially designing the system it is important to define what services are going to be used (get, register, listen). I've been trying to force this in to a UML component diagram but this is implementation specific, which is what the UML is good for, as Peter says, but it is not so useful for the level of analysis that Peter's design technique is aimed at.

I also found this article from IBM describing a UML profile for services, which may be useful.

I really need to get to grips with UML profiles!

My next 6 weeks I will be documenting the design of a new OSGi based system that I am architecting at work, as well as continuing that design and giving it some detail, so I think I will have plenty of chance to get up to speed with UML properly. My aim is prove the design that is in my head (and partially implemented) before spending too much (more) time writing code to support it. At that point I will also be getting a couple of team members to help me out, so I want the design of the system to be clear in order to aid in delegating the implementation work.

Bit of ramble there but I think my conclusion is... the OSGi Design Technique is going to be a useful analysis tool and UML is going to be good to show how it needs to be/has been implemented. Of course, now I need to find a (preferably free/opensource) tool that can help me do the types of diagrams that Peter produces.

Thursday, 4 October 2007

Gaikokugo - high level design

I decided to try and document my approach with Gaikokugo. My first problem is describing OSGi services in UML. Peter Krien's touched on this in his blog [here], and looks like he gave up. I like Peter's simple notation and the more complicated diagram further down the post is likely to get very complicated in a UML environment. However, I'm determined to use UML (as there are so many tools to hand and is pretty much an industry standard), so here is what I came up with to describe the core components of the Gaikokugo Language Platform as it currently stands using a simple component diagram.



The components represent OSGi bundles or Eclipse plugins, as appropriate.
  • gaikokugo.common contains common classes used throughout and exposes no services. Right now it contains a single class; GaikokugoException, which is an unchecked exception that can be used to wrap checked exceptions or thrown when it is unreasonable for the application to cope with the current situation or checked exception.
  • gaikokugo.rcp is the UI part of the application, an Eclipse specific plugin. All of the UI code is in here at the moment. This may change and I'm already considering adding an extension point to allow a re-usable Exception handler to be plugged in to handle the unhandled exceptions and report them back to me via email, or directly in to buzilla, etc. This is likely to be a seperate project and an extension point is probably not even required, now that I think about it.
  • gaikokugo.db is a standard OSGi bundle that exposes the persistence interfaces for the application. One of my goals for this application was to avoid having to have the user "save" their work as they went along, so my design forces the implementation of the db to be persistent throughout. I do talk in terms of database, but the GaikokugoDBService's only method is to open a file on the filesystem. How this file is read and written is up to the persistence implementation.
  • gaikokugo.db.db40 is a persitence implementation based on db40 and registers itself as an implementation of the GaikokugoDBService interface exposed in the db bundle. I was using the db40 OSGi bundle, but I just couldn't work out what benefits it gave me over included the libraries in the bundle itself and I had problems getting Eclipse to detect it as a plugin. Anyway, all of the implementation code for the db is specific to db4o in this bundle, so no problems with classloaders or anything like this.
  • gaikokugo.db.db40.test doesn't yet exist, but will contain unit tests for the db40 implementation. This will most likely be executed using ProSyst's Test Platform... but even though it is excellent it isn't a free piece of software, so I may build my own OSGi based unit testing framework.
  • likewise gaikokugo.rcp.test also does not exist, but envisaged having UI unit tests in this bundle, as well as an implementation of the db bundle specific to the UI tests. Not sure how I am going to do this yet, but I believe it is possible to hook in to the UI programmatically in order to simulate user activities.
There is still lots to be done, but at least I have done some design... I have started listing the features of the project as "Mylyn Tasks" within my Eclipse IDE. I probably need a better way to do this as I frequently switch from my laptop to my desktop PC and I don't think the tasks come along for the right. I should probably setup bugzilla or something similar.

"old" technology

I've been so fascinated by new technologies recently, I had forgotten just why people use the "old" stuff. Yes, technology is moving along at a rapid pace, but consider this n-tier architecture:
  • SQL database (Oracle, MySQL, SQLServer, etc)
  • Hibernate 2
  • EJB 2
  • Struts 1.3.8
Nothing amazing or innovative there... at least not by today's standards, but only a few years ago the latter three were hot technology. Today they are stable, reliable and simply work exactly how you expect them to and there are lots of tools to help you work with them very effectively. So, I'll be revisiting some of this technology in the next few days (though I am off to Spain for a week on Sunday) to get back up to speed, just in case I happen to need it again.

Monday, 1 October 2007

new personal project: gaikokugo

I start my Japanese lessons on Tuesday and in a strange attempt to help myself learn better I've started a new project called "gaikokugo", which I believe (and hope) is Japanese for foreign language.

More details can be found at the above link, but to summarise, this is going to be an Eclipse based RCP application using db4o as the underlying database, with three perspectives, vocabulary, phrases and conversations and include automatic testing facility (where feasible).