Archive for July, 2005

Need more inputs on home theater gear

Monday, July 18th, 2005

People who know me will tell you I’m not much of a gadget dude, at least not when you consider that I’m a software engineer. That said I’ve been pondering how to get the full potential out of our Motorola Dual-Tuner DVR High-Definition Set-Top DCT6412. Urban legend suggests I can upload recorded DVR content to a PC via the set-top’s IEEE 1394 ports. I’d need a PC of some sort (the media server) situated near my TV and A/V gear. While I’ve got a variety of home networking options at my disposal, I’m faced with the physical distance limiation of running a IEEE 1394 cable from the set-top to the PC. Unless some hardware hacker can make the content accessible via the ethernet port, this is my only option. At the present I don’t have a budget that allows for luxuries as frivilous as home entertainment media storage and playback, but if/when I do here’s what I’d want.

1) Easy archiving of recorded DVR content to media server
Preferably I could do this in batch (copy all of last week’s Three Stooges episodes) as opposed to real time playback (yawn).

2) Easy playback from media server to my home theater system
This sounds simple, but I’ve got some requirements. My 36″ Toshiba HD-TV is broken, so it only displays 480p (progressive) signals properly. 480i from analog devices (VCR, nintendo, etc.) aren’t viewable. That means playback of any media must be done at 480p. That also means I’ll need component (RGB style) video connectors from the media server to my receiver. Another lame thing about my present setup, my receiver only has 2 sets of component video inputs – one used by the set-top, the other by my Playstation2. I did a quick search on crutchfield and found this <sarcastic>modest</sarcastic> model, but even if I traded in my truck I’d barely have money left over for cables and accessories.

Questions for the world:
Has anyone successfully played back video from a PC in 480p to an HD-TV?
What sort of PC hardware is needed?
How do you control all this in a living room setting?

I imagine switching A/V inputs on my receiver to the PC input and using a wireless keyboard/mouse. I’ve got this pimped out bluetooth rig upstairs.

This blog’s comment feature is broken, so email me any suggestions.
Thanks.

Posted in Geek | No Comments »

Latest trend in sales force outsouring

Wednesday, July 6th, 2005

Sales Person
Coco can play golf with customers while smiling and nodding in agreement for hours. When you factor in that he’ll work for bananas, the choice becomes clear.

Posted in Fun | No Comments »

JavaONE – final day

Friday, July 1st, 2005

The last day was pretty chaotic with our flight status changing throughout the day. The only complete session I attented was Managing Your Application’s Performance Into Production. It was one of my favorite sessions as it wasn’t too commercial, yet not just abstract solutions are J2EE spec. experts are fond of doing.

Basically the topic was monitoring, and how to achieve a balance between visibility and performance overhead. (think Heisenberg’s uncertainty principle). The more instrumentation, the bigger the performance impact – even if it’s trivial the fundamentals remain. The presentation was sponsored by Veritas (recently acquired by Symantec I learned) and briefly mentioned how they achieve this goal.

Using a pattern they call “Adaptive Instrumentation”, the profile execution stacks and identify the best intrumentation points in code. Their instrumentation is done dynamically at runtime using aspects. Many other sessions I attended involved using AOP to achieve different things. The most favored solution today is using some form of class loader magic. While the specifics may vary by implementation, it goes something like this:

An “agent” has a listing of code points to instrument. At class loading time, the agent intervenes and provides an instrumented version of the class as it’s loaded. There are some real benefits to this approach:

1) no special build is required. You can used the RC or production bits as desired
2) restarting the app is all that’s needed to “undo” the instrumentation – this makes it somewhat reasonable in some production environments (easy rollback)
3) there’s no deployment changes – no classpath trickery (think Clover) or jmx hooks needed.

The single biggest theme I’d like to apply is “don’t assume test outcomes or usage patterns”.
Too often we *think* we know what sort of traffic to use during load tests. Maybe historically production purchases have been 70% red products, and 20% blue products – while that’s a decent place to start, if the market suddenly shifts and everyone is buying purple we could experience a largely untested usage scenario.

Using this Veritas solution one can make reaction based (think IRT) investigations more productive. The evil code is profiled instrumented and we effectively are provided with debugging like output that can even show values and state of the the stackflow.

Posted in Geek, JavaONE | No Comments »