Pages

Saturday, February 24, 2007

Simple Code - percentages

I was trying to work out a percentage of one value against another:
(int)((double)num/den*100)
Lots of conversion just to get an int value representation of a percentage.
Simplified:
100 * num / den
Solved.

Friday, February 23, 2007

Go Beryl

My clog has been missing pictures, so here are some which show off my current desktop (FC6).
The reason I took the first one is that I thought it was funny the way xmms was behaving when I applied water effects to the window.
This inspired me to take some more screen shots. The “cube”
And my burning effects on close window:
When I closed this screen shot, I thought the double burning effect was also cool, so I took another screen shot:
And what is the result of having all these effect you ask? 1/3 the battery life and a reason to show off.

-= Comments
1. Xavier | February 23rd, 2007 at 4:28 pm
Dammit, I haven’t been able to get Beryl working
Granted, I haven’t tried too hard, but I’m not keen freezing up my gnome session too often.

Wednesday, February 14, 2007

Java Thread Stack performance

The question came up at work the other day on how to solve problems with threads ‘losing’ resources. In particular, I think that threads aren’t release holds on database connections (bad). Basically at some point we run out of connections to use and everything goes to hell.

So, since we have access to the thread objects, I thought that it might be worth while finding where these threads are up to.
Strike 1.
Only Java 1.5 has Thread.getStackTrace(). We are running in 1.4

Well, what would be the performance of doing such a thing anyway.

One way of getting the stack is:
[java]try
{
throw new RuntimeException();
} catch(RuntimeException re)
{
result = re.getStackTrace()[0].getMethodName();
}

Java 1.4 via throw and catch method:
Execution length:1376
Execution length:1258
Execution length:1278
Execution length:1295
Execution length:1285

Java 1.5 via same method:
Execution length:1295
Execution length:1233
Execution length:1238
Execution length:1252
Execution length:1229

Good start: There is little difference between using 14 or 15.

But use:
[java]Thread.currentThread().getStackTrace()[0].getMethodName()
Java 1.5 via Thread.getStackTrace()
Execution length:15938
Execution length:16308
Execution length:12004
Execution length:16804
Execution length:17009

Definitely room for improvement.

Each of the stack elements was queried 100,000 times.
This test was done 5 times end to end.

This test does not answer a tougher question like "if the stack trace is deeper, would it become slower?".
The slower method is the only way (I know of) to access the stack of a thread that is not driving the current code though.

Friday, February 9, 2007

Business problems

Something that I don’t think University can really teach.

It has been something I’ve been observing more and more as my managers start to see me as more than just a programer.

Business A wants Feature B.
Estimate (in $$$) is more than Business A wants to pay.
Business A requests that they really want the Feature.

I know in my life, if I can’t afford a 24″ monitor, I simply won’t have it.
I am aslo very concious of my purchases. If I want a 24″ monitor, I will wait till I have the capital for 2 because I know that there is the possibility of the first one breaking down.

Obviously a business can’t justify this sort of reasoning.

Why would Business continue to persue something that they can’t have without meeting the requirements?

-= Comments
1. Gatesy | February 13th, 2007 at 10:28 pm
"Why would Business continue to pursue something that they can't have without meeting the requirements?"

Because the dudes in management either:

1) underestimate the complexity of the feature they’re asking for

2) miscalculate the supposed benefit of the feature they’re requesting

Personally, I would have thought that if there was such a pressing business case for such a feature, then they should either bite the bullet and pay for it, or ask the developers to leave hooks for future expansion. That way, everybody’s happy: if the developers do a good job there should be repeat business, and the client can phase their system in to suit their cash flow.

But then, I’m only an IT student - what would I know about business?

Thursday, February 8, 2007

Projects and their growing towers

<vent>
I’ve been put back on a project that I thought I was clear of. I’m not particularly fussed about being on it. But they have no viable plan to get the system to where it needs to be. This is not good for me.

A couple of issues have been building up and I am afraid of them just blowing up in someones hands.
* Build Scripts
* Documentation
* Change management

The build scripts are old. Everyone in the software industry knows that most things change, including the way things are built. I’m sure the build scripts were perfect for the initial stages of the system but they haven’t changed since. The problem is that the Owners (notice I’m trying to be generic?) of the project won’t spend any time (and money) cleaning up the outer edges of the project.

The documentation hasn’t really been kept up to date, but since the software hasn’t changed that much it hasn’t caused much of an issue. The problem is managing the documentation. Commiting OO documents to CVS makes it difficult to see changes between versions. It also makes it difficult (if not impossible) to merge documents. I asked around at work and the common answer was wiki. Wiki is good but we would lose things like table of contents (and page numbers), branding, levelled numbering and simple things like bookmarking. I tried to suggest the !boom thing on one of the blogs on byteclub that combines css and html to produce PDF but the overhead of time would probably be too great.

With regards to change management, this is more of a niceity that may come in handy at some point. There is no solid record of what has change and/or why. Since there has been none to start with, it is kind of hard to work out what I should do about it. If I had more motivation coming from the Business behind the project, I might be more interested: but this is not the case.
</vent>