Rediscovering the Obvious

…stumbling in the footsteps of greatness

Archive for April, 2007

DataTriggers are VERY cool

without comments

I’ve been reading a lot about Triggers in WPF styles, but I didn’t have much call to use them yet since we’re still working on getting a UI out there and databound for a decent slice of the app… we haven’t really started looking at nifty UI behavioral effects yet, and Triggers only work against DependencyProperty objects.

Well, thanks to this useful article, I discovered the joy of the DataTrigger, which can target any old .NET object (PODNO – Plain old dot net object?)  I’d previously blogged this code for auto-expansion of a full tree view:

            <TreeView.ItemContainerStyle>
                <Style>
                    <Setter Property=”TreeViewItem.IsExpanded” Value=”True”/>
                </Style>
            </TreeView.ItemContainerStyle>

It turns out that adding a data trigger to that same style enabled me to perform the default selection in the tree node, which was otherwise proving to be quite a challenge writing code like (_orgSelectionTree.ItemContainerGenerator.ContainerFromItem(value) as TreeViewItem).IsSelected = true; That code, unfortunately, doesn’t work until the TreeViewItem corresponding to value is already rendered at least once, causing even MORE problems.

            <TreeView.ItemContainerStyle>
                <Style>
                    <Setter Property=”TreeViewItem.IsExpanded” Value=”True”/>
                    <Style.Triggers>
                        <DataTrigger Binding=”{Binding Path=IsPrimaryUserOrganization}” Value=”True”>
                            <Setter Property=”TreeViewItem.IsSelected” Value=”True”/>
                        </DataTrigger>
                    </Style.Triggers>
                </Style>
            </TreeView.ItemContainerStyle>
 

I need to get better at adding search engine terms for these posts, but luckily the code samples will get me TreeView and TreeViewItem in this case.
 

Written by erwilleke

April 25th, 2007 at 9:52 am

Posted in Uncategorized

How clothes are like software processes

without comments

I’ve recently been simmering on a process metaphor that likens a
given company’s software processes and practices to an individual’s
choice in clothing.  This isn’t really fully-conceived, but I want to
get it out there sometime soon, so I’ll push it out, and maybe edit it
over time. 

How clothes are like processes 

No person goes naked. If you try, you get arrested unless you’re in nudist camps (or you die of exposure).
No company goes without processes. If you try, you go out of business unless you’re in a research environment.

Sane people only wear heavy clothes and coats in the winter, and stick to light clothes in the summer.
Sane companies use heavy processes and standards when they have to, and stick to lighter processes when they don’t.

Effective people wear clothes appropriate to the current activity, instead of combat boots for sprinting.
Effective companies adapt their processes to the current work product,
instead of forcing document reviews on a lunch announcement.

Smart people wear suits when they’re applying for a job at a bank, and spend extra time cleaning lint and hair off the suit.
Smart companies demonstrate established, formal processes when applying
for a contract with the Navy (FDA, bank, etc), and spend extra time.

Crafty people wear casual, hippy clothes when they are selling goods at a commune.
Crafty companies are casual and laid back about software processes when proposing contracts with relaxed clients.

Happy people wear clothes that feel good on their bodies, clothes they enjoy putting on in the morning.
Happy companies use processes that feel good to work in, processes that give people the feeling of progress while implementing.

Sophisticated people wear designer clothes to convey a specific image to the viewer.
Sophisticated companies implement well-known processes to convey a specific image to the clients.

Perceptive people avoid the perception they’re wearing cheap clothes.
Perceptive companies avoid the perception they’re using unrecognized processes.

Oblivious people don’t know about fashion, and wear jeans and a t-shirt.
Oblivious companies don’t know about processes, and don’t follow any established processes.

Angry young men are aware of fashion rules, but intentionally flout the need for conformance, being marginalized by society in the process.
Angry young companies are aware of processes, but intentionally flout
the need for conformance, being marginalized by mainline businesses in
the process.

[Self-comments]

I’m not sure I like the phrase “relaxed clients”, but I don’t know what word better implies a client that doesn’t care for processes, and just wants results.

Written by erwilleke

April 24th, 2007 at 1:19 pm

Posted in Uncategorized

Mean Time to Failure

without comments

I really find Michael’s post resonating with me today. I’ve reread it several times and each time I bring more and more out of it. While I’m not an XP zealot or a certified Scrum master of any sort, I have studied the approaches extensively over the last four years as I worked towards process definitions for the consulting company I worked for, and I’ve repeatedly felt the same pain Michael expresses.

The bullet points are extremely on, if somewhat pessimistic realistic in nature. However, I’ve always felt that it’s borderline pointless to present a risk without having at least a CONCEPT of a potential mitigation. Even if my mitigation is just a straw-man, it’ll still help get the discussion rolling. This starts with learning, is expanded by learning, and is finished by more learning.

Oh, and Michael, what you’re proposing isn’t a methodology, it’s a philosophy (or maybe a paradigm). It also sounds very happily Lean. Let’s keep talking, though, it’s good stuff!

Written by erwilleke

April 24th, 2007 at 10:05 am

Posted in Uncategorized

Automatically expanding a WPF grid

without comments

 Took me a while to figure it out, so here it is.

        <TreeView Name=”_orgSelectionTree” >
            <TreeView.ItemContainerStyle>
                <Style>
                    <Setter Property=”TreeViewItem.IsExpanded” Value=”True”/>
                </Style>
            </TreeView.ItemContainerStyle>
        </TreeView>

Written by erwilleke

April 23rd, 2007 at 3:51 pm

Posted in Uncategorized

One more spot…

without comments

If you’re willing (and able) to work in Indianapolis, we’ve got one more spot available. Successful candidates will be passionate about .NET and highly capable C# developers. You’ll get the chance to work with WPF, WCF, SQL Server, nHibernate, TFS, and many other TLA’s! Send me an email if you’re interested, or if you’d like more information about the project, product, etc… eric dot willeke at gmail dot com

 

Written by erwilleke

April 18th, 2007 at 2:47 pm

Posted in Uncategorized

New colleague…

without comments

I’m very happy to welcome Paul Hacker to my development team. His experience and energy will be making a huge impact on the project, the product, and my own development. Paul, a once (and future?) MVP, blogs at http://phacker.wordpress.com/.

Paul, glad to have you!

Written by erwilleke

April 13th, 2007 at 9:50 pm

Posted in Uncategorized

1-800-GOOG411

without comments

Amazing! Handled a local call about BW3′s easily, by voice, and came back with “Did you mean Buffulo Wild Wings…” AND nailed it to the closest one to my current location.

 THEN, they text messaged me the data for free.

Hello Google!

(from http://feeds.feedburner.com/~r/JohnBattellesSearchblog/~3/108920255/003532.php among others)

 

Written by erwilleke

April 13th, 2007 at 9:46 pm

Posted in Uncategorized

Pack Notation for style merging

without comments

Just so I remember (Company.Product.Module is the naming convention we use for both namespaces and assemblies)  

            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source=”pack://application:,,,/Company.Product.Module;component/AppStyles.xaml”/>
            </ResourceDictionary.MergedDictionaries>

[EDIT]
The code for loading this into the application resources during startup is:

        // In App : Application
        protected override void OnStartup(StartupEventArgs e)
        {
            base.OnStartup(e);

            Uri uri = new Uri(“pack://application:,,,/Company.Product.Module;component/AppStyles.xaml”);
            ResourceDictionary rd = new ResourceDictionary();
            rd.Source = uri;
            Application.Current.Resources.MergedDictionaries.Add(rd);
        }

 

If you wish to use Application.Current.LoadComponent( uri ), however, it fails with an error that absolute URI’s are not allowed.  This pack:// naming convention was a bear to figure out the details, and several of the examples provide by the MSDN text do not work.

More information on the pack notation in WPF at http://msdn2.microsoft.com/en-us/library/aa970069.aspx

[UPDATE2]

http://nerddawg.blogspot.com/2005/12/more-on-resource-loading-in-wpf.html has a lot more information on this.
 

Written by erwilleke

April 3rd, 2007 at 4:06 pm

Posted in Uncategorized

Lifecycles…

without comments

Slurp, burp, hiccup, sneeze, wipe, change, sleep… [repeat]

How’s that for an iterative development process? Currently, I (well, Elle) has an iteration every two to three hours. Initial release will be in 18 to 21 years, with ongoing maintenance after that. We do expect our cycle time to lengthen after the initial few months of development, especially since we are locked into scope-bounded iterations instead of time-bounded ones by the constraints of the development project.

I do, however, expect that one of the side-effects of such an aggressive schedule will be burn-out among the oversight team, but that team has been identified as being highly motivated and any turnover seems to be a highly remote possibility. We did mitigate some initial risk by bringing in highly experienced contractors for the first few weeks to assist in establishing the basic patterns development will follow.

We are very lucky in that there is a large body of existing practices on which we can draw. We are confident that little or none of the development done on this project will be revolutionary, thus our aggressive estimate of +/- 1.5 years. There is risk that the oversight committee may cancel further development and move directly into the maintenance phase if the schedule drastically overruns the 21 year estimate.

 <aside>I very much feel like a geek right now </aside>

Written by erwilleke

April 2nd, 2007 at 7:00 pm

Posted in Uncategorized