Download all java older releases

Ok, i know that at least once in the life java programmer has to download jdk 1.3.0_u03 to reproduce the old, freaky and disturbing issue on the legacy system.

Because we need to support this system.

Searching for such a download main be a pain in the butt, unless we know the magic url - http://java.sun.com/products/archive/

Yes, I know that's no more Sun, but it anyway allows you to download specific versions of JDK, JRE and other stuff! Which is really useful for real-life experience.

New blog platform - does it worth it?

Hello again.

I'm thinking of moving to the shared hosting with own domain name and Wordpress installed - seem to like more configuration.

It is now up with the blogger imported.
http://lexaux.net.ua/wordpress

Try it - do you feel it comfortable? Like the styles? Any ideas on whether this change may be good or bad?

Thank you!

Show effect - collecting ideas!

Hello, my dear fellows.

Show effect - as is
I have recently thought of the 'Show effect'. You know it - when you are presenting your application, or the new iteration to the customer (or anyone external) - you frequently run into situation when the small action results in a large stack trace spanned for the screen?

Imagine the demo to your customer. You:

• show nice things - feature A is implemented
  
• show great things - feature B which is very important for the business - is implemented! (applause on the background)
  
• show awesome things - the designs ARE there, even if they were provided 2 days ago!
  
• and then you are about to show little bit of functionality (notifying user about their registration), which is not that important (and thus not that verified) - you get an awful error statring with text Unhandled exception java.lang.NullPointerException

Then all your show becomes a bit compromised.

Minimize your risks with smaller efforts
So, I kept thinking on this for a while - how does one minimize these 'show' risks?
I have been feeling this myself - we had a demo each week for 5-6 weeks with a customer, and we had to demonstrate the progress.
It is pretty hard to show significant feature progress within a week, isn't it? And we were on really tight schedule.
So, these are several things I figured out - sure that I'm not the first who found them, but better would be if you the readers would get them from other's experience than from own:

1. Time and connection. Be sure that you don't make everyone wait too much and also that everyone is setup for the show. In the distributed teams it is common that dev team is located in different country, so that the technical solutions for presentations are being used (screensharing services and the voice calls usually)
   Make sure everyone knows where to get and how to setup the screensharing before you start the show. Provide your help if needed.
   
2. Always have a plan of presentation. Even if the things are simple, you need to have written plan before you so you don't waste time thinking on 'what should I click next?'. You should be presenting your work in such a way so your listeners feel that you are completely confident with what you are doing.
   Surely, there is always a place for unforseen changes - your customer may ask you to perform some action which does not fit to your plan. Be calm and confident :)
3. Rehearse the demo, at least 2 times, following the written steps you've done in item 2 of this list.
   
4. Try not to show too much - if some features are half-implemented you'd rather not show them than make the whole appearance of the project half-complete.
   
5. Make sure no one could compromise your demo without knowing it. Good point here is that you ask no one to touch demo server during the show - by any means. 2 demo users logged in with the same accounts from different machines can lead to catastrophic results.
   
6. Don't forget about the user experience. If you are showing something to non-technical people (or even technical people but not of your organization) make sure that you have the unexpected exception page configured correctly - so that even if everything fails, user is still presented with the comfortable page with correct and unambigous steps of what to do next. Making custom pages for HTTP 500, 404 etc is also a nice thing.
   Another point here is that if the custom error page is not breaking the overall design feeling. With this little trick subject of your demo would feel much more like a complete application (if it even is a prototype).
7. Put mocked things in. If you have designed sketches with very nice flash application you don't have yet (and your customer knows you don't) - put them as static pictures. And then as soon as the new feature is completed, replace that static pictures with the functioning parts.
   
8. Don't forget to say thanks once the demo is over - the people involved had to put off their ongoing work and tasks (which may be also important) to take participation in your show.
9. ...

The question is still open
It would be great if you could share some of your great experience - cases, practices, ideas - about the show effect.
Thank you! And comment on, I'll add the wise thoughts to the list :)

Testing code hl

  
public static void main() {
}

Seems to be working now.

Great thanks, dear Heisencoder! I've taken the steps at
http://heisencoder.net/2009/01/adding-syntax-highlighting-to-blogger.html

New York Homicide map

Here is a strange and terrible example of how maps can be used - http://projects.nytimes.com/crime/homicides/map
The map shows in points the places where murders has happened in New York only, and how they were distributed. Looks like Central Park is the safest place

Be Peaceful!

Time Tracking

You might have asked yourself a question - what should be your own working day length in order to reach the best performance?
There are different approaches for this.

I always used to work more than intended/I'm paid for. E.g. for the last month or so I've been sitting in the office and performing my dues for 10-12 hrs a day :o)

I started feeling this becoming a mo(:)bius strip - the longer you work the worse results are. I started feeling lack of patience, less creative insight and worse memory.

So, the first experiment I've done is not to work on weekends :) at all.
Next thing to try would be the 'kill' timer - I would start it as soon as I start working, and get off the work not depending on current status when it reaches 9 hours (9 is pretty a resaonable time, giving a hr for all the chit-chat, coffee breaks and lunch)

Will see how it goes.

I've already found a stopwatch for this - XNote Stopwatch - http://www.xnotestopwatch.com/ .
Now need to try how it goes.

Updates would follow soon - and have a good rest of the weekend.

Find a location by IP address

I was wondering how does one find a user's location (lat lng or city) by an IP address.
Thankfully, found one free and (looks good).

It offers APIs for different platforms (i'm happy with Javascript, yes).

Here is the actual link - http://www.maxmind.com

TDD - what should go first

Hi.

Plenty of time has passed since the last time I opened The Blog.

The topic of the day is 'how you write code good'. I don't remember times when I had enough time for the unittests. So, i'm trying to figure out several rules for myself to stay when working. Now the following sequence seems to be doing its job:

How this happens now. I want to write a new business-logic method:

1. I create a method stub in a (bean). With the name only.
2. I think of what should this method get as input, and what should produce in output, in both normal and exceptional cases.
   
3. I modify method to the correct signature.
   
4. Then - i generate javadoc ;). In the javadoc I write down all the thoughts I had when was doint 2. of this list.
5. I go to test. And create 1 test class for this method. In this class, I do write one-by-one all the cases (negative and positive) of how it's done.
6. Mocking - I'd use it, but yet we have a pretty well-done structure, so I can rely on live objects. Though, I'd try using mockito for the brand new things.
   
7. I run tests - they fail. That's good :)
8. I implement method - tetsts should start working. If one of them fails, I need to correct either the tests themselves or the method - depending on what's error.

/me knows that all the stuff above is well-known, wide-used and so on. The list should be treated as a reminder for myself.