Even more George

As requested….
Dad giving George a bath
This is my favourite photo.
After the first couple of baths that were a little too cold in which George screamed his way through them, Susi and I have warmed them up a little and he now loves a bath from Dad.
I’ve only nearly accidentally drowned him twice, and a little coughing and spluttering later he’s ok. Note, they’re slippery little suckers and can be quite wriggly.

Advertisements

More about George

Anybody else sense a theme here ?
Here is a few more photos I took today. George is a little more alert today, like his father and both grandfathers is _very_ interested in certain parts of the female anatomy. In an infant this is cute, and results in much appreciation by the females, and encouragment. In an adult, this results in admonishment (mostly).
What happened in between ? .. sigh ..
More photos:
Just after a nappy change.
Moments after feeding. How drunk is that boy ?
Sound asleep.

Hello George, we’ve been waiting to meet you

George Eaves, baby boy, born 14th May @ 11:37am (Mothers Day), 6 pounds 14 ounces, to a very tired mother and a hopelessly teary father.
Sue and George are doing great, dad is getting there.
I’m so proud of my wife, it makes my heart ache, and tears well in my eyes. I can’t imagine it is possible to be any happier than I am right now.
Thanks to all the family and friends who’ve sent well wishes.. Sorry to those who I forgot to tell in time, but I’ve had other things on my mind. We do still love you all, but it was more sudden than we thought it would be.
Photos:
Just Born with Mum
Having a sleep
All snuggled up
A teary father

Windows Help File Editor

One of my cow-orkers has been working away on a nifty little environment for editing the Windows help file formats. It’s called HEHE (HTML Editable Help Environment)
It’s a pretty cute way of doing things if you want to use the Windows Help File for documentation. Certainly better in general than just scribbling shit on bits of paper, or in a notepad.
Personally, I’d rather use a Wiki, but I suppose I’m not the target audience for this kinda stuff anyways. However, could be a few peeps out there who might want to use something like this rather than having to install stuff on servers etc, or work in environments where that is not possible.
Check it out here

Using an ‘ooky detector’ to guide decisions

Yesterday I posted an article about configuring Tomcat and Eclipse for debugging, and my general dislike for running an application server and doing non-unit testing within the IDE.
I used the term ‘ooky’ to describe how I feel about this practice, as I have no real rational or definitive logical reason for not doing it, other than “I just don’t like how it feels”.
In one of the comments, Jon Tirsen mentioned that using ‘ooky’ as a means of making decisions isn’t such a great idea. I spent the evening pondering this and wondered why he would make that statement, especially from somebody who likes Ruby more than Java because it is more ‘elegant’. To me, this is clearly the use of an ‘ooky detector’ by Jon.
(Hey, I like Java more than C++ because it’s more elegant as well, and I agree that Ruby is a more elegant language than Java)
My gut feel, and general sense of ‘ookiness’ about people/projects/products/implementations has been a great indicator of success.
Maybe it’s an experience thing. I’ve got 20 years of experiences in which to build up my ‘ooky detection parameters’. If you’ve only got 5, then maybe your ‘ooky detector’ isn’t well calibrated.
I’ll happily admit that I’m often wrong, but these days I tend to be more right than wrong, and every decision that I make helps me calibrate my ‘ooky detector’ even further.
Why do I think using an ‘ooky detector’ works well ? Most of the time we are working in grey areas, and there is no absolute right or wrong. The concept of smells in code is very much a specific example of an ‘ooky detector’ and in many cases people have different calibrations for their code smell detection than others.
I think that if we examine many of the decisions that we make on a day-to-day basis, most of them have very little deep analysis and concrete decision making process, and we (as humans) tend to using an ooky detector.

Debugging with Tomcat and Eclipse using jpda

I’ve not had much need for debugging my servlets, but while I’m currently working on a legacy codebase, it’s a great means of stepping through what is really happening.
I’m not a fan of the “run Tomcat in Eclipse”, well, just because it feels ooky, and I’d rather run the two VM’s separately so I can bounce them independently, and because I write such crap code, I’d rather not crash both of them at the same time.
The information on how to make Tomcat and Eclipse play nicely together is a bit sparse, so I’ve provided a nice little summary here. This is working with Tomcat 5.0.X, Eclipse 3.2, JDK 1.4.2_*
Step 1. Configure Tomcat
(This is for the Win32 build with the spiffy UI for starting/stopping)
a) Open up the configuration GUI (“Configure Tomcat”)
b) Select the Java tab
c) Into the Java Options include (substituting the correct locations)
-Xdebug
-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n
-Dcatalina.home=c:\tomcat
-Djava.endorsed.dirs=c:\tomcat\common\endorsed
-Djava.io.tmpdir=c:\tomcat

NB: These are all on separate lines, with a <CR> at each EOL
d) Select the Startup tab
e) Into the Arguments section include:
jpda
start

NB: These are all on separate lines, with a <CR> at each EOL
f) Start and Stop Tomcat completely
2. Configure Eclipse (well, not much really to configure)
a) While in the Java perspective select Run/Debug…
b) Choose “Remote Java Application” from the tree (right click/New)
c) The defaults are all that is required.
d) Click “Debug” in the bottom corner to start it now, or Close for later
3. Debugging the Application
a) Select the servlet/code that requires examination
b) Create a breakpoint in the code
c) Click on the “Debug” (if not already debugging) (*)
d) Click on the Debug Perspective (optional)
— this should show the Eclipse connected to Tomcat, and there should be a huge list Threads and the title of the Debug should be something like:
NameOfApplication [Remote Java Application]
Java HotSpot(TM) Server VM[localhost:8000]

e) Now just run the application as normal (via a browser or whatever)
f) Watch in amazement as Eclipse debugs the application at the breakpoint.
(*) If you get an error such as “Failed to connect to remote VM. Connection Refused”. This normally means that Tomcat isn’t started, _or_ there is already a debugging session started via jpda. Check Tomcat is running, and check the Debug perspective to make sure that it isn’t running.