it's been noticed...

§ October 1, 2009 01:22 by beefarino |

Just ignore this post, I just need to release some steam...

We just had an emergency team meeting.  The topic: it's been noticed by the executives that we're not always around when they are.  Someone needed something and one of us wasn't there to oblige.  That must have really chapped their hide.  

Well, I've noticed some things too.  Here's what I've noticed:

  • I'm VPN'ed into work at midnight fixing the build someone else broke;
  • I'm constantly tweaking our unit tests to keep them working as the rest of the team gets to plod on to greenfield pastures;
  • I'm responding to support emails at 2am;
  • I'm answering the support phone at 4am;
  • I still make the 9:30am scrum;
  • I bust my hump as a principal developer on a project, only to hear the executives single-out my superiors to praise for my work;
  • After four rounds of layoffs, I've taken on so many roles here I've lost track;
  • I haven't dropped the ball on any of my responsibilities (or if I have, no one has let me know about it);
  • I've been willing to drop my life for days at a stretch to make emergency trips to fix client issues;
  • I'm frequently the last one out the door at the end of the day;
  • I see my kids for maybe 90 minutes a day;

... and more thing I noticed: the people I work for only notice me when I'm not around.

 



when a property should be a method

§ September 29, 2009 13:46 by beefarino |

I posted a quip on twitter this evening:

note to devs: a boolean property that expects to be set to only a false or true value (and throws otherwise) should be a method instead.

Several people prodded me for more an explanation, so here it is.

Say you have a default feature, and you want to offer consumers of an object the ability to disable the feature.  One common practice is to use a boolean property, consumed like so:

// ...
thingWithFeature.DisableFeature = true;
// ... 

It's simple and makes sense.  However, I'm finding a lot of hardware SDKs are throwing exceptions when you try to set such a property to false, in this example indicating that you do not want to disable the feature (forgive the double negative).  In other words, the property is settable to one specific value.  E.g., the SDK implementation looks something like this:

// ...
public bool DisableFeature
{
    set
    {
            if( ! value )
            {
                throw new ArgumentException();
            }
            
            // ... disable the feature when the value is false
    }
}
// ...

As a consumer of this object, there is only one path I can take with the DisableFeature property that will result in a valid operation.  The property syntax goads the consumer into failure by offering up an illusion of functionality that does not exist.  As a developer, I have every reason to assume that a boolean property can be set to true OR false.  If one of those is not appropriate, then the property isn't a property, it's a method:

// ...
public bool DisableFeature()
{
    // ... disable the feature
}
// ...

As a method, the one valid path is captured unequivocally, and it's not possible for consumers to assume they can do more than they are allowed by the SDK.



The Most Moronic Value Converter Ever

§ August 26, 2009 06:43 by beefarino |

I'm really digging that I get to work with WPF at the moment.  Using advanced databinding features against MVVM are making quick work of the menial "datapult" applications I'm pounding out.  I still have a lot to absorb, but I'm getting there.

Being a n00b to XAML and WPF, I often find myself lost in a fog when things don't work.  E.g., this afternoon I spent a good 30 minutes trying to decipher a binding problem.  I was trying to use the data context of a TreeViewItem in the text of it's header template (you can laugh at my XAML, this is just me hacking):

<TreeViewItem ItemsSource="{Binding Profiles}">
    <TreeViewItem.HeaderTemplate>
        <DataTemplate>
              <TextBlock Text="{Binding Count}"/>
        </DataTemplate>
    </TreeViewItem.HeaderTemplate>
</TreeViewItem>

I tried several binding paths in the TextBlock, but nothing would show up in the tree node.  I ended up switching gears and trying to figure out what data context was actually available to the header data template.  Finding nothing from a cursory googling, I ended up creating a value converter that would convert the data object into it's underlying type:

namespace My.Converters
{
    public class ObjectToTypeConverter : IValueConverter
    {
        public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
        {
            if( null == value )
            {
                return "null";
            }
            return value.GetType();
        }
        public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
        {
            throw new NotImplementedException();
        }
    }
}  

The Convert implementation will return the System.Type of the data context (line 12), or the string "null" if no context is available (line 9).  At this point I can alter the XAML to simply spit out the actual type of the data context, giving me a clue as to why I'm clueless:

<Window ...
xmlns:Converters="clr-namespace:My.Converters">
...
<Window.Resources>
<Converters:ObjectToTypeConverter x:Key="ObjectToTypeConverter" />
</Window.Resources>
<TreeViewItem ItemsSource="{Binding Profiles}">
    <TreeViewItem.HeaderTemplate>
        <DataTemplate>
            <TextBlock Text="{Binding Converter={StaticResource ObjectToTypeConverter}}"/>
        </DataTemplate>
    </TreeViewItem.HeaderTemplate>
</TreeViewItem>
... 

Anyway, long story short, in my particular case the data context for the TreeViewItem header template is actually null - which makes no sense to me, I would have assumed it would have been the TreeViewItem's data context.  A quick relative sourcing of the binding solved my issue:

<TreeViewItem ItemsSource="{Binding Profiles}">
    <TreeViewItem.HeaderTemplate>
        <DataTemplate>
            <TextBlock Text="{Binding Path=Profiles.Count}" 
              DataContext="{Binding DataContext,RelativeSource={RelativeSource Mode=FindAncestor,AncestorType={x:Type TreeViewItem}}}"/>
        </DataTemplate>
    </TreeViewItem.HeaderTemplate>
</TreeViewItem> 

 



get-buildstatus PowerShell Script

§ July 21, 2009 08:16 by beefarino |

I just bashed out this powershell script to query the build farm status using the CC.NET server report XML page:

# get-buildstatus.ps1
$client = new-object system.net.webClient
$client.Headers.add("user-agent", "PowerShell")
$data = $client.openRead( 'http://builddashboard/ccnet/XmlServerReport.aspx' )
$reader = new-object system.io.streamReader $data
$s = $reader.readToEnd()
$data.close()
$reader.close()  
([xml]$s).CruiseControl.Projects.Project | ft;

Wicked simple - the WebClient class is used to connect to the build dashboard, and a stream reader object pulls the farm data.  The data is XML, which PowerShell considers warm butter and happily pivots and formats as a pretty table:

> get-buildstatus
name           category       activity       lastBuildStatu lastBuildLabel lastBuildTime  nextBuildTime  webUrl
                                             s
----           --------       --------       -------------- -------------- -------------  -------------  ------
SuperDuo 3....                Pending        Success        SuperDuo_14890 2009-07-21T... 2009-07-21T... http://buil...
SuperDuo Sa...                Pending        Success        SuperDuo_14725 2009-06-16T... 2009-07-21T... http://buil...
SuperDuo 2....                Pending        Success        SuperDuo_14706 2009-06-09T... 2009-07-21T... http://buil...
SuperDuo 2.2                  Pending        Success        SuperDuo_14888 2009-07-21T... 2009-07-21T... http://buil...
...

Of course, if you have the PowerShell Community Extensions installed, the get-url cmdlet reduces the script to a one-liner:

# get-buildstatus.ps1
([xml](get-url 'http://builddashboard/ccnet/XmlServerReport.aspx')).CruiseControl.Projects.Project | ft;

I think I'll push this into a PowerGUI powerpack...

Super happy fun time deluxe!  (Enjoy!)