Archive for the ‘software engineering’ Category

Notes on Enterprise Architect

Friday, September 21st, 2007

What I don’t like:

  • I want to create a constructor, but more often than not I forget to remove the void return. Hence it creates a method called ClassName with a return type void on code generation. Surely it should be smart enough to realise that this is a constructor-like signature?
  •  I want to be able to delete elements from my design easily. Why can’t I? No, really..WHY?
    • Selecting multiple classes from a class diagram and hitting delete only removes them from the image, not EA as a whole. Ok, I don’t mind that so much… it’s a half decent failsafe. But WHY OH WHY isn’t there the ability to click on an item in the project view tree and press delete on my keyboard? What is this CRTL-D bollocks?
    • Better still, why on earth can’t I delete multiple items at once? This is ridiculous.
  • Seems I can’t attach relationships to each other easily and then move them all about at once. This drives me insane.
  • Clicking on the same spot of a class seems to bring a different prompt/dialog/result each time… gah.
  • Overall, it’s just the worst HMI/HCI I’ve ever used in a mainstream application.

In short, it’s about as powerful as it is not usable. There’s got to be better options? Perhaps I’ll stick with Umbrello or ArgoUML in future? But of course, they’re not as feature-rich. Further investigation required.

What I should have already known about OO…

Monday, September 3rd, 2007

I recently had the opportunity to partake in a course on Object Orientated Analysis and Design. Over the course of 5 days, I managed to get a clearer understanding of OOD than I had in 4 years of University. The key? The obliteration of buzzwords, and the abstracting away from the technical implementations of OO. With what seems in hindsight a logical choice, our presenter seperated OO into two parts: Abstract OO and Concrete OO. The Concrete part of course deals with the language-specific features of OOP; Encapsulation, Dynamic Binding, Inheritance, and so on. Abstract OO on the other hand deals with the three foundations of the concept, as opposed to the implementation of it. These are Classification, Specialisation, and Polymorphism.

Now when I went to university, OO was taught hand-in-hand with a language. I’m starting to think that this should not be the case. The risk here is that the student, as I did, forms definitions for terms like Polymorphism in a Java/C++/C#/etc-only context. In reality, no language is the same and there are subtle differences in the way that each implements OO concepts. By splitting OOP into concrete and abstract concepts, the idea of Object Orientation itself is also much easier to grasp. I can now explain, without using buzzwords or just repeating the question, what terms like Specialisation actually mean. The same could not be said of me while I was at University- and the worrying thing there is the fact that I still scored quite highly.

What that means for the students who didn’t score quite as high as me is worrying- especially those who didn’t bother to learn things like UML- have they just spent <insert ridiculous amount of money here> on a 3 or 4 year degree without actually learning anything?

Dammit Hibernate, that data is stale!

Tuesday, August 21st, 2007


A user operation has changed the status of some entities in our database. Hibernate, while wonderful and all, is retrieving stale data from its cache instead of from the database. How do we force Hibernate to look at the database, or realise that the data has changed?


Well, first and foremost, this isn’t Hibernate’s problem. From

“hibernate can’t magically know when the data changes in the database, how can you expect it to notify your application?”

The system I’m working on has a long-session setup, where the underlying database can be modified without Hibernate’s knowledge. This would seem to be a problem other people have encountered:

“The long EDT session caches fetched objects. What if the database changes from outside the application and you want to display the changed data? Your only chance is to close the session, delete all objects, which were attached to the old session and are potentially stale, open a new long session and retrieve all the data to be displayed again.”

So, this particular developer recommends closing the session and opening it again. The problem being for me, that there are other objects in this session that will be potentially lost when it is closed and reopened again; not to mention the chance that a user somewhere else may try to make a change impacting the session while a session is closed! Which brings us to Session.refresh(Object):

“* Refresh() is OK for telling HIbernate to update the in-memory contents of the object, but there are three problems with it. One is that there is a bug with cascading refreshes, so that if you try to refresh an object that has a to-many association where one of the items in the collection has been removed on the server, it will fail with an exception. This is not too bad, you can solve it by disabling cascades and doing it all manually. Two is also a minor point, which is that the docs recommend not using this method. They don’t say why. Three is that it does an immediate SQL fetch for each refreshed object, so it is very inefficient to refresh batches of objects, and since there is no refreshing query capability (see first point), there is no efficient way that I can see to refresh a list of items. This is especially bad with the prior point about sort ordering, because it means that I’m much more likely to need to have to refresh all the items in a list.”

“If you want reload objects which changed out of hibernate (database triggers, other application etc) you can use : session.refresh(ent).
Unfortunately, you have to refresh only one object/entity with this method, but it’s only what hibernate offer - hibernate have great caching mechanism and refreshing complete session can be performace downgrade.
You can call rebuild session factory, of course, but it is time consuming operation.”

Very well. Looks like it might be time for me to try refresh(). My one concern however is that it’s only for one object; and my database is modified by an import operation, so when 100,000 items are imported… well, let’s just see how long that takes.

Teaching People About People

Tuesday, April 10th, 2007

One of the more common problems you think you’d encounter in the software/IT industry is the need to interact with workmates with little people skills. Indeed; the stereotypical image of a software engineer or programmer is one of a sad little man stuck in a cubicle away from the outside world, with only his compiler for company and a big mug of coffee. His most frequent interaction with people would be his boss quickly telling him how he needs to work harder, or perhaps a discussion with another, equally reclusive geek around the coffee machine.

Reality is a lot further from the this image than a lot of people think. That said, there are those among us who are quite happy playing dungeons and dragons and not really talking to people- and good for them. But there is an underlying problem with our workforce and its people- and it is one that most likely affects many other industries.

University can teach a graduate about many things. It can teach you about compilers, coding style, design, and the theory of programming and software engineering. It can teach you about how to drink quickly and have a myriad of adventures with the opposite (or perhaps same) sex. What university does not teach students is what to expect in the real world; how to behave in a professional environment, how to deal with a difficult workmate in a professional manner, or overbearing boss with unrealistic deadlines.

Work experience is often touted as a solution to this problem; it is not. Even work experience struggles to assist; often, the work experience “kid” is given menial tasks, not taken seriously, or treated as someone who brings youth to an organisation but no real talent or ideas. Part time jobs can’t hold a candle to a full-time position for much the same reason; and besides, there’s nothing like the day-in-day-out grind of the real world to shatter the ideals and expectations of a recent graduate.

What graduates and new starters need in this position is a scheme that allows them to settle into their environment. Not just a mentor who shows them the water cooler, parking bay and stationary bin, but a friend and experienced hand who can guide them through what is expected of them in their position, how much time they have to strive towards that, what they are and are not doing right, how to behave in a professional manner, and most of all someone a newbie can trust.

The unfortunate thing is that this doesn’t happen nearly enough, or with enough quality or care, in the industry. As a result, mistakes aren’t highlighted and corrected at an early stage in your career. Graduates are faced with people that have no time for them, or their mistakes, and certainly don’t have the time or care to talk to them about things. These graduates often have no way of knowing how to deal with these people; they were taught how to talk to a computer, but not necessarily a customer.

So how do we solve this dilemma? Universities would argue they’re there to help students learn how to ask better questions, and not to train them in the ways of the workforce. Organisations would argue that universities are sending them graduates who have little practical knowledge and no idea of how to act as a professional. And graduates will just sit there confused, wishing someone would take responsibility (while perhaps taking none of it themselves).

My best guess is probably that there has to be a coming together of all three elements. Universities have to start taking responsibility for the production of graduates with little practical knowledge or qualifications- some do this more than others- and look at ways to produce graduates with an ability to adapt to changing situations and technologies, and an ability to communicate well with others. A recent discussion with an academic member of the University of Western Australia’s Arts faculty yielded the interesting information that companies in the business of journalism don’t actually want journalism graduates. They prefer intelligent, politically-savvy students with a good understanding of a wide range of social issues as opposed to a student who has been ingrained into a particular style of writing and editing.

It is more than likely that the same applies to other industries. Industry has its role to play too, however. The onus is on companies to provide good graduate programs or mentoring schemes to help students adapt to professional life, and fill any gaps that university education may have not quite have had the time or resources to cover. Until this happens on a regular basis and with good results in large companies, I simply have to recommend graduates start small, where they may have more opportunities to learn quickly in a more intimate, people-driven environment.

Finally, there is also an onus on us, the graduates, to look out for what companies want in their new starters, and to learn at university what we need to be able to freely adapt in an ever-changing environment. Finally, we need to realise that there are some people who just have really, really crappy attitudes and/or unrealistic expectations of you out there; and that these people are the ones that we’ll have the most trouble with, not the quiet, socially-maladjusted geek in the corner. The key is to try and not let it affect you to much, and then one day, when you’ve coded enough, studied enough, and just done enough hard work, you might just be able to spring a suprise on them.