#

jdh's blog

theme and variations
Thursday Feb 22, 2007

working remotely: Prague Paradise

This past year, I decided to leverage some intersecting reasons for travelling to Prague on business.  But instead of just doing a business trip, I proposed to my management that I work out of the Sun office in Prague for a short time while also mixing in vacation time, so I could both experience the city and make a connection with Sun folks at a non-U.S. site.  My management was very obliging, and before I knew it, my Prague plan panned out.

I was in Prague for the month of September.  Prague is a truly lovely city. A river runs through the center of the old part, with history and statue laden bridges crossing it.  Many of the beautiful old buildings are lit up at night.  I had an apartment in this part of the city.  The transit system is fabulous.  I used a combination of tram and subway to get to work;  each workday, I got to see the city's architectural highlights from the tram.

Sun is well set up for working at a remote site.  I secured 24x7 access to the Prague Sun site, which meant I could work at hours that suited me.  My laptop was already set up with the tools I need (mail reader, StarOffice, browser).  I plugged it in to the local network, which provided seamless access to my home directory and Sun's tools.  I was able to use a local access number from the office phone to dial into U.S. 800-based conference calls, and could even call in from my apartment by dialing first into the office phone system.  The phone connection was quite good -- only occasionally did I have trouble with voice synchronization.  I had brought my headset with me; it worked perfectly, which made my calls as easy as when calling from my main office or from home.

My husband visited for the middle 2 1/2 weeks.  We were fortunate to have glorious weather for the entire month of September, with blue skies and 70 degree days.  We went to the old churches and the famous castle, to the opera, to pubs, and also to several outdoor hangouts overlooking the city and river.  We explored outside the city for 5 days, and enjoyed both natural beauty and several beautiful and historic smaller towns.  Some motorcycle friends rode over from Marseille and stay for a couple of days; we showed them what we'd discovered.

Working in Prague was surprisingly comfortable and similar to my work experiences at home, or at other U.S. based Sun locations.  I could have just worked at the Prague site for a few days, then taken a vacation in the Czech Republic, but this experience of vacation days intermingled with days at work gave me the opportunity to get to know Prague and the Sun culture at this site.  It makes me hungry for more such experiences. Next time, I should try for 6 months or a year!

Monday Feb 12, 2007

double trouble

Well, folks, this time it's 4 hands again but 2 pianos!  I have a friend with 2 pianos who suggested we do a piece together.  She is a truly fine pianist and I'm very excited to be playing with her.

My piano teacher helped me find a really fun piece by Wilhelm Friedrich Bach - one of the younger Bach sons.  This music is neat for a couple of reasons.  The interplay between the 2 pianos is really delightful.  It alternates between the pianos echoing the other -- working a little motif back and forth up to some climax, and the pianos playing hand in hand -- playing little runs and arpeggios up and down the keyboard a 3rd apart. The other neat thing about this piece is that the music bridges Baroque and Classical.  There are clean melodies and classical harmonies, but it is filled out with all of the trills and frills associated with the Baroque.  I've never played a piece with so many trills.  That will be the main challenge, to get our trills to play nicely with each other.

I look forward to performing this for my friends, but much of the pleasure is in the practicing together.  I feel lucky to have found yet another person to make music with.

Friday Jan 12, 2007

blogging

Reactions to my starting a blog:

I would shoot myself if I had to do that.  (a sibling)

I have a blog - it gives me a chance to show off my knowledge about the subjects I'm an expert at, which is a good way to enhance my future job prospects.  (a friend)

First there were mailing lists, then forums, now blogs.  They all continue the trend of talking to more and more people that you are less and less familiar with.  It gives folks the perception of a wider audience.  Why just post your rants to a mailing list when you can post to the world?  (a close relative)

My, what a thoughtful, analytical person you are!  You have an interesting view on the world, and are an excellent writer.  (a parent - could you tell?)

Blogs are the perfect medium for introverts.  There is no one to make eye contact with, and no requirement to respond to (or even allow) comments.  (an even closer relative)

I'd SHOOT myself if I had to write that crap every day/week!  (a sibling -- no, actually, a *different* sibling)

Friday Dec 08, 2006

Complexity: basic system monitoring

The other day I had my second contact with a Real Customer, and I learned something.  (Come to think of it, I learned something at my first meeting as well.  This is a trend I'm trying hard to extend by insinuating myself into meetings with customers.)  We have a bunch of really cool systems at Sun -- across a wide range, from high end to low end, covering both SPARC and x64 platforms.  Some customers buy lots and lots of them.  And then want to manage them.

We also have some pretty neat tools for managing and monitoring systems: Sun Management Center  (SunMC) has been around for a number of years, and supports pretty much all of our SPARC platforms.  N1 System Manager  (N1SM) is newer; it was initially targetted for the lower end volume systems, starting with x64 platforms, but has been expanding its focus.  Both tools provide a conduit through which to monitor Sun systems.  Both provide a normalized view, hiding the variations in how those systems report status or generate notifications.  Both also provide upward interfaces to enable integration into 3rd party tools.  In this way we're similar to IBM (Director) or HP (System Insight Manager).

I'd heard that customers aren't always so interested in a 3 tiered management solution, where there is the managed system, an element manager such as N1SM managing the basic hardware infrastructure, and a higher level manager for the data center as a whole.  My main reaction was, those pesky customers, they are never satisfied - this solution is quite sufficient for their needs.

Then in comes the Real Customer, with a big dose of Reality.  It turns out that the second tier running our nifty consolidation layer that knows the special ins and outs of our systems requires some real hardware on which to run.  This isn't just theoritical complexity, this is complexity in terms of additional hardware and software to deploy and manage.

So what should we do?   Provide flexibility.   And that's what we're doing.  We've recently provided some packages that enable direct integration between our systems and third party tools, such as CA Unicenter and MOM.  And this is a trend that we are continuing.   It may not be possible to fully represent some special aspects of our systems through non-Sun tools that focus on enabling management across a wide variety of systems, but we can certainly enable the basic system monitoring and management that is common to all systems.

Wednesday Nov 15, 2006

nightmare

I awoke with a start from a nightmare I had after composing the previous blog entry about who the better programmer is.

My mother is gesticulating wildly.  Her eyes are flashing, she is speaking rapidly.  She suddenly understands -- it is all related!  She finally sees the big picture -- the really big, complete picture.  She needs to articulate this idea. She is desperate to make us understand the relationships and patterns she has discovered.  She cannot get the information out fast enough; she is about to expode with the urgency of it!

My father is mute.  He is staring straight ahead, eyes dry and red.  He has almost uncovered every possible path through the most complex problem in the world.  He has no time to sleep, even to blink.  His head is so full of understanding every single nuance of this problem that it has pushed out his capacity to speak.  And who has time for speech anyway -- that would interfere with the speed with which he is reaching the solution!

Thank God they are actually both retired, and have become rather more interested in hot tubbing than in soliloquies or solutions.

Tuesday Nov 14, 2006

my mother should have been a programmer

My father is very smart.  He was an electrical engineer.  He used calculus in normal worklife to explain and create.  He built things that measure things that measure (very small) things.  He can reduce a problem down to its component parts, solve it, then express the solution in its most elemental, elegant form, and implement it the smallest possible space.

My mother is very smart.  She was a history teacher and is a writer.  She sees the interaction between culture, technology, personalities and how it drives events.  She sees patterns in history - the ways it repeats.  She can present a thesis succinctly, then validate it by showing the contributing factors and logical conclusion.  She rapidly organizes information to make it understandable; she explains complex relationships through simple concepts that build on each other.

Which of these people would make a better programmer?

I have often thought it is my mother.  Good programming is very much about organizing information, and not so very much about using calculus or fitting into a small package.  It is also about providing a map for how to understand and approach both the problem and solution.

But of course that ability to understand and solve hard problems and strip down the solution to its most efficient and elemental form is so critical.  Maybe it is my father.

Maybe my mother was really intended to draw the boxes with lines and arrows between them, and my father to take that concept and apply it - to understand and address the ramifications it introduces.

Come to think of it, I guess that kind of sums up their marriage.  No wonder their combined lives have been so successful.

Monday Nov 13, 2006

not perfection, but

 

I performed that duet yesterday afternoon.   It was ok.  I give myself a B+.  Most importantly, it was music -- my duet partner and I echoed each other's phrases, and there was delicate feeling and elasticity in the right sections.  It was rousing in other right sections.  I didn't ever lose it (and neither did she).  I did lose one hand for a few measures (not literally, you understand), and played a few notes wrong here and there, but feedback was that it was fun to listen to.   Guess I'll trust the feedback.

It's hard to not be perfect.  Not that I ever am, but that doesn't make it any easier.  Hey, at least I delivered, on time, if  with some bugs. :-)

Saturday Nov 11, 2006

Complexity and Completeness: FMA

Complexity brings joy into the life of an engineer: it is so satisfying to find all the nooks and crannies of a problem and come up with a solution that covers them all. No, wait. Complexity is the nemesis of the engineer: it is so hard to be satisfied with an 80% solution. The desire to provide a complete solution is almost unbearable, beyond all reasonable expectations of the company or customer, Must an engineer resort to damned statistics to prove that an inelegant or incomplete solution is sufficient, and a more efficient use of time? Sufficient for whom? For the consumer of course. Being associated with a less than perfect solution repulses me, yet I am the very customer that would never pay what it costs for perfection.

One of my favorite examples of the agony and ecstasy of complexity is FMA (fault management architecture - see Mike Shapiro's blog). FMA is hard.1 I've looked at the blog entry by past Sun luminary Andy Rudoff, in which he provides a summary of the concepts of FMA.  The concepts are so pure and beautiful. And simple!

But it all starts with fault trees. One must explain every fault that could occur, and every symptom (error) it might produce. Then in the middle there are all the timing issues - how long will related errors take to show up? And will they show up, because after all the paths for communication are not perfect? And at the end is the problem of how to isolate the fault. Who are all the constituents who will be affected, and how do we guarantee there is no race condition between multiple actors?

Right now we take an all-or-nothing approach to a vertical segment of faults -- all cpu faults, for example. Essentially we diagnose a complete subtree of faults, but ignore faults caused by a component closer to the root of the fault tree (maybe the fault is really a power supply problem that affects all components in the box). This is how we make the problem tractable. But the complete subtree approach gets particularly hard for I/O, where components can have a great deal of interaction, not necessarily all in a nice hierarchy, and errors are reflected in all directions. Cindi McGuire has lead a herculean effort to wrestle down I/O fault management into something containable and expressible, but getting every device to participate in FMA has stumped this effort. The job is not complete. The ability to diagnose with complete accuracy remains an unrealized vision.

So I wonder - would it be so bad to just sprinkle some FMA around? For example, if we have evidence that a particular subset of faults is most common or catastrophic, can we can provide just sufficient error reporting and diagnosis to narrow the fault landscape to find the instigators of those most egregious faults? Maybe we allow drivers to be enhanced to some minimal level of error reporting to enable just that type of diagnosis, for example. This might make it easier for driver writers inside and outside of Sun to inch their way along the path of enabling the full FMA vision.

1 let's go shopping

Friday Oct 27, 2006

just one more compile

Hi. This is my opening foray into blogging. As such I will start small. I am small, so I guess that kind of fits.

I was practicing the piano recently (I am going to play (half of) a Schubert duet at an upcoming recital) and was reminded again of the similarity between practicing piano and coding. I have a very bad case of the "just one more compile" syndrome these days. You know how you really mean to leave for dinner, you mean to get to bed and get some rest, but you're hot into fixing a bug, or making some section of code more elegant and understandable. You haven't quite got it right, but you can see it there waiting for you, if you just try one more time... and then suddenly you've missed dinner, or ended up staying up to ridiculous hours. Not that you mind, because your mind is still racing even when you finally do stop.

That's how it is with practicing. Can't quite play some section with the right timing. Need to try out a different fingering. Is there a better way to get that entire phrase hang together and make emotional sense? No that's not quite it, let me try something else -- or, yes, that's getting there, now can I get it to really work reliably?

But then, I think everything's the same as everything else. Or at least has aspects that can be found to be similar. When I first started working in computers, I had to develop a filter to translate from one protocol to another. It was a new idea to me. For a long time after that, it seemed to me that everything was a filter of some sort. It still often seems that way. Why, playing the piano is being a filter isn't it! You read the music that the composer wrote and then provide your interpretation of it.

And then there's jazz. Kind of blows that analogy out of the water, doesn't it.

Ok, time to retreat. Bye.


Archives
Links
Referrers