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.