So, today is the culmination of an 8 week website that launches with the TV show.
For those of us that have a life: Big Brother.
The site has come together really well, with just a few minor issues in integration.
I sit here in the office preparing the first load of data to go into the system and stretching my fingers for when things need to be tweaked.
The largest hurdle to get over with this site is the large number of users that will be hitting the site. We think that we have got the site as lean as possible. There will be an initial hit when everyone has to download the css, js and images; but after that it should be smooth sailing.
If anyone is interested in what I know about the house: the answer is nothing.
As developers: they never released any real data to the dev site.
I have no interest in following BB.
Seems like the site has been completed (for launch). Pity I didn’t get the girl (probably needed to look for one if I wanted that to happen. Had to work hard to see the site launch)
Monday, April 23, 2007
Monday, March 19, 2007
Secret Projects and Tight Timelines
Probably something I should put in two posts. Since I haven’t had the time to update this clog though, if I don’t write them, one of them may get missed.
Currently working on a project that is not allowed to leave the confines of the office. I have usually been able to generalise the problem when I’ve pasted code before, but this time it would seem like I could give something away. I shouldn’t find any "interesting" code examples anyway since I only have time to work on my parts and my parts should contain no flaws :).
The next issue is the looming pressure of a very hard release date on the project that didn’t have the right amount of time to get it done in the first place. Everyone that works in IT knows that this is just a huge red alarm, attached to a bomb that is waiting to go off.
To me it is just a challenge that may be possible to meet. My current problem is that I’m the only one that wants to try to impress the customer. It would seem that everyone else is just coding at a standard pace. They know that the original timeline is a shocker and that is not their problem.
I was able to get a little bit of time into the challenge that mark pointed out but only got the layout right. My creativity this weekend was 0.
-= Comments
1. Jonathan | March 19th, 2007 at 10:52 am
Well, just remember that all bombs get stopped one second before they explode. And then he gets the girl.
You might not get the girl, or even the bomb, but good luck anyway.
On review, this sounds very much like a horoscope. Vague, meaningless, but can be applied to every possible situation.
Currently working on a project that is not allowed to leave the confines of the office. I have usually been able to generalise the problem when I’ve pasted code before, but this time it would seem like I could give something away. I shouldn’t find any "interesting" code examples anyway since I only have time to work on my parts and my parts should contain no flaws :).
The next issue is the looming pressure of a very hard release date on the project that didn’t have the right amount of time to get it done in the first place. Everyone that works in IT knows that this is just a huge red alarm, attached to a bomb that is waiting to go off.
To me it is just a challenge that may be possible to meet. My current problem is that I’m the only one that wants to try to impress the customer. It would seem that everyone else is just coding at a standard pace. They know that the original timeline is a shocker and that is not their problem.
I was able to get a little bit of time into the challenge that mark pointed out but only got the layout right. My creativity this weekend was 0.
-= Comments
1. Jonathan | March 19th, 2007 at 10:52 am
Well, just remember that all bombs get stopped one second before they explode. And then he gets the girl.
You might not get the girl, or even the bomb, but good luck anyway.
On review, this sounds very much like a horoscope. Vague, meaningless, but can be applied to every possible situation.
Saturday, February 24, 2007
Simple Code - percentages
I was trying to work out a percentage of one value against another:
Lots of conversion just to get an int value representation of a percentage.
Simplified:
Solved.
(int)((double)num/den*100)Lots of conversion just to get an int value representation of a percentage.
Simplified:
100 * num / denSolved.
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.
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 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 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.
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?
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>
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>
Subscribe to:
Posts (Atom)



