digitalMoto.net

Yamaha is delaying delivery of my Super Tenere.  The earthquake and subsequent tsunami did not directly impact Yamaha’s production facilities, but it has impacted Yamaha suppliers. 

So…

They are hoping to have all of the bikes delivered by November, 2011.  Which means my early release 2012 XT1200Z model won’t be.  It’s just a 2012. 

<sigh> 

I’m a bit disappointed but not surprised.  I figured that unless my bike had make it onto a container ship before the devastation, it would be very unlikely that Yamaha could meet their original production schedule. 

I can cancel my order and get a full refund of my earnest money, but I don’t think I want to do that.  I don’t want the BMW R1200GS/A.  It costs too much for what you get when compared with other models.  I didn’t like the KTM Adventure.  The Ducati Multistrada is a nice bike but it isn’t dirt worthy.  Maybe I just like bikes with “Super” in their name especially when they come in black.

In any case, I’m going to sit tight and wait. 

From Tech Republic

1. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.
2. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.
3. No matter how much "karate" you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.
4. Don’t rewrite code without consultation. There’s a fine line between "fixing code" and "rewriting code." Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
5. Treat people who know less than you with respect, deference, and patience. Non-technical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.
6. The only constant in the world is change.  Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
7. The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect—so if you want respect in an egoless environment, cultivate knowledge.
8. Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don’t take revenge or say, "I told you so" more than a few times at most, and don’t make your dearly departed idea a martyr or rallying cry.
9. Don’t be "the guy in the room." Don’t be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
10.   Critique code instead of people—be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

I know I have failed to live up to these ideals.  I fail at #10 quite regularly.  Being astoundingly good at NOT being a people-person, it’s almost second nature. 

After thinking about this for a little while, I guess I’m not good at being nice to people who violate rules #1 – #3.  If you think your code is perfect then we are going to have problems.  No one’s code is perfect.  Not mine.  Not yours.  Get over it.

You have to understand, there are no junior programmers in my world (current contract).  We’re all senior.  We’re all expected to kick ass and take names.  If you can’t live up to that ideal, then you shouldn’t be here.  That’s the nature of the gig.  I do my level best to live up to that ideal.  I expect the same from my peers (especially when they are on my payroll).  If I see a logic flaw or gratuitous code when a one-liner would work, I want the code fixed.  Period. 

Delivering quality matters.  Set your ego aside and get to work.  I’ll do the same.  Maybe we can create something really cool in the process.

Footnote:

Yes.  I know I’m an insufferable bastard when it comes to certain things.  I’m not going to change just to suit others.  I can’t make myself not care about the few things that I actually care about.  Code happens to be one of those things. 

Skynet has become self-aware. 

More!

Assumptions:

• XamDataGrid
• Attached property used to capture the MouseDoubleClick event

private static void MouseDoubleClickHandler(object sender, MouseButtonEventArgs e)
{

  var sourceParent = VisualTreeHelper.GetParent((DependencyObject)e.OriginalSource);
  if (sourceParent is RepeatButton) // eject if double click in scrollbar
    return;

  ...

}

Cresting a rise west of where 217 connects to 26, I had a “moment” this morning. 

I was humming along as usual, in the left lane, on the right side next to the dotted white line.  The car in front of me slammed on his brakes.  I followed suit, locking the rear wheel in the process.  The rear wheel starts to slide to my left as I grab more front brake further unloading the rear end. 

At this point I have no idea why the car in front of my is slamming on it’s brakes when it had been doing 65.  But the idea of rear ending him doesn’t exactly appeal to me, so I follow suit.

Then I hear the impact.  The guy in front of me just hit something.  A flash of gray as a milk crate bounces off the concrete barrier to my left.  You know the kind.  With the metal reinforcement ring at the top. 

Amazing what the brain can catalog when focused.

A split second and it was over.  I’m back on the throttle to escape panic stops in my rear view.  Gone.  After I see more fresh debris against the median, I move over into the center lane until the concrete median transitions to open grass. 

Hmm…  I need to work on my panic braking skills. 

The FJR has ABS and linked brakes so I can hammer both ends with confidence.  The SuperDuke isn’t as advanced on the techno scale.  Must practice that one.     

Last night the cats were acting very weird.  Sydney, who usually curls up near me most nights, would not leave me alone.  She woke me up at least 6 times. 

This morning I learned that we had a 2.2 Earthquake around 4am.  That would explain things a bit.

Pacific Northwest Seismic Network

So what is the difference between a bunch of punks doing the pogo and a metal head mosh pit? 

I grew up a punk (Black Flag, Dead Kennedys, Generation X, etc).  My wife’s a metal head with a British twist (Queensryche, Judas Priest, Black Sabbath, Deep Purple, etc).  She likes mosh pits.  I dislike people touching me to put it mildly. 

So what’s the difference?  Why does the pogo seem “OK” and pleasant group bonding experience while a mosh pit sounds like a thinly veiled excuse to anonymously punch someone? 

Maybe I’m idealizing the whole issue. 

Current playlist:

• Marilyn Manson
• Ministry
• Rammstein
• The Ramones

Current track:

Stirb nicht vor mir
Rosenrot
Rammstein

True codeplex gold! 

Once again, I ran into a binding problem.  I want a view to bind to a XamDatGrid contained inside the selected content pane inside of a XamDockManager.  I have a sample project working perfectly with this syntax:

  DataContext="{Binding ActivePane.Content.DataContext}"

When it was time to migrate the code over to my production app everything fell apart.  Eventually, I found a circular DataContext reference by using Snoop.  My detail view was bound to the same view model as the content pane housing the XamDataGrid.  So binding to Path=ActivePane.Content was the same as binding to Path=. which did nothing to get me to the active item in the view model.  Oops.

My final solution was to expose the ViewModel behind the View at the DockManagerViewModel level.  So now this XAML code works:

  DataContext="{Binding Path=ActiveViewModel}"

Snoop: the WPF Spy Utility  Learn it.  Know it.  Love it.

Here’s how I managed to get there. 

I merged 2 assemblies.  (Both contained xaml files.) 

My steps to get into this minor mess.

1. Dragged the files from the smaller assembly into the larger one. 
2. Renamed the larger assembly. 
3. Updated the project properties to match the new name/function of the assembly through the project properties screen.   
4. Ran the ‘Adjust Namespace’ tool in Resharper across the entire project. 
5. Build
6. BOOOOM!!!

The first error listed is:

Library project file cannot specify ApplicationDefinition element.

Does that sound familiar?

The problem is the ‘Build Action’ on the .xaml file properties.  When I moved the xaml files the build action was changed to “ApplicationDefinition”.  These settings fix it:

Build Action –> Page

Copy to Output Directory –> Do not copy

Custom Tool –> MSBuild:Compile

Go through all of your xaml files.  Make sure they are all using these settings. 

Worked for me. 

Reference:

Buried in this article is a pointer by Marco Zhou that helped me figure it out.   

With WPF apps, you can add a last-ditch exception handler.  As usual there are two ways to wire it up.  You can add it to the App.xaml

<Application
  …
  DispatcherUnhandledException="ApplicationDispatcherUnhandledException"
  >

or you can add it into the constructor App()

public App()
{
  DispatcherUnhandledException += AppDispatcherUnhandledException;
}

voidAppDispatcherUnhandledException(objectsender, DispatcherUnhandledExceptionEventArgs e)
{
  throw new System.NotImplementedException();
}

The purpose of this handler is to catch any unhandled exceptions from the main UI thread. Which also presents its limitations.  It works only on the UI thread.  That said, every time I hosed my app it was on the main UI thread. 

Silverlight apps don’t have this exact functionality.  In Silverlight, you handle the UnhandledException.  The “dispatcher” is left out of the mix.  It can be wired up in basically the same way as the WPF version.  My guess is that because Silverlight runs within the browser context, it never has control of the main UI thread.  IE/Firefox/Chrome are hosting the Silverlight app so handling exceptions is more limited in a contextual sense. 

I use the DispatcherHandlerException to handle fatal errors.  As the app closes, I can capture the exception details and save them as needed.  (E.G.: Log the error, send tech support email, etc.) Then I provide some information to the user so that the app doesn’t “just close” without any notice.  Apps that go blank tend to annoy my wife.  If my wife would be annoyed, I can safely assume someone else would be annoyed too.

If you can recover from the exception, you can mark the event as handled and keep going.

CYA early and often.

References:

WPF Version: DispatcherUnhandledException

Silverlight Version: Unhandled Exception

This is an continuation of the code I posted yesterday. 

I ended up reworking and extending my VisualTreeHelpers class after more research. 

With this version, I’ve tried to merge several ideas with a more fluent naming style.  First, I found that I needed to walk the VisualTree looking for (possibly) multiple instances of a given class. The new GetDescendantsByType<T>(DependencyObject parent) method supports that.  I disliked the GetAncestorByType<T>(DependencyObject descendant) logic, so I reworked it to suit my tastes.  And of course, I renamed things.  The influences remain, but the direct lineage is less obvious.   

Babble, babble…

Read more…

Continuing with the theme of standing on the shoulders of those who came before us…

Today, I need to find a control “somewhere” in the visual tree.  I found two different solutions to the issue.  One finds child controls.  The other finds ancestors.  Since I copped the code from other sites (link in the comments section for each method) I won’t promise that everything works to perfection.  I’ve used the FindVisualChildByName<T>() method in my code so my confidence is higher with that one.

Here’s the class I ended up with: 

Read more…