On a day when I’m fighting with WCF, WPF, polling and MVVM my 5 year-old son visits and draws me a picture:
He says I’m the really tall superhero with the big blue light sabre. The little guys are evil coders that Daddy is going to squash.
This from the kid who tells everyone he wants to be a geek like his Dad when he grows up.
Man, kids sure know how to put a smile on your face…
Using a bit of a misleading nomenclature, one of the constructors for TimeSpan uses ‘Ticks’ to initialize the object.
I have been using Environment.TickCount for eons, it seems, where 1000 ‘ticks’ equals one second. Because of some of the processing I’m doing right now, I decided to use DispatchTimer to simplify pushing info back to the UI thread from background data refreshes.
Here’s some code that looks innocent enough:
_dispatchTimer.Interval = new TimeSpan(3000);
_dispatchTimer.Tick += new EventHandler(dispatcherTimer_Tick);
_dispatchTimer.IsEnabled = true;
Unfortunately, when run, the timer is firing (or at least trying to) approximately every 1ms. Which…is about as fast as it’ll go. In fact, I was getting 12-16 lines of output in my logger from the tick event firing about every 11ms. Oops.
Now, had I read the tooltip from the constructor or otherwise checked the doc’s, I would have seen that TimeSpan actually accepts ticks as 100 nanoseconds.
So, in passing in 3000 as the parameter for the constructor I was actually telling it to tick every 0.000003 seconds. Nice.
Ahem. That should read:
_dispatchTimer.Interval = new TimeSpan(30000000);
Karl Schifflett, one of the key players in the WPF arena, is now working at Microsoft. I don’t follow him close enough to know when he made the switch (I think earlier this year), but I am hoping that this will start to clear some of the waters.
The WPF Toolkit on the CodePlex website gives us a project template from the folks working on WPF at Microsoft. This is a great start, but it collides in some regards with Karl’s work in the Power Toys. On top of that, there are very respectable folks out there blogging their thoughts and pattern approaches to MVVM for both WPF and Silverlight.
I know that patterns are just that: patterns. They aren’t the be-all and end-all of development practices and you can’t adopt them as policy. BUT, I would argue, those who share that view – and take an honest look at it – also know that using patterns in everything you do is a little bit of an academia dream.
I’m fortunate at the company I’m at now, but previously I have had very few managers who know GoF-speak. In fact, as recently as the last few years I have worked at shops where they wrote, flat-out adopt patterns as policies as the law, failing your code review if you don’t use the pattern as a law-abiding coder should…even if it’s the worst possible approach to the solution.
So when I say I’m hoping for clearer waters in the MVVM pattern, I’m not asking for one source of guidance that I can accept as law; rather, I’m hoping that – with some of the bigger minds in this space now working together – that the tools and the pattern can start to enjoy a more unified growth.
Ultimately, what would be nice, is when we as 
developers can sit in a room together, bring up MVVM and not all have a different picture in our minds as to what we’re actually talking about. I’ve never, in bringing up Abstract Factory, been asked, “Oh, do you mean Frank Geevers implementation, or Garry Frank’s?” It’s just…Abstract Factory. And people get it.
I’m getting the feeling we’re getting close to this. There is a good set of WPF folks at MS, the developer credited with MVVM works there, now Karl, Jamie Rodriguez as well…
I guess the one drawback would be the other side of the trap: Microsoft releases a toolkit and guidance on the Patterns & Practices web site and then managers start making that the law…and likely for web services, too. :oS
One of the people I highly regard in the MVVM/WPF spectrum is Karl Schifflett. Not only has he contributed some absolute gems to the coding world through his blog, but he has co-conspired to open the gates to the WPF internal rendering and visual tree engine that, for many once-WinFormers-would-be-WPFers is so foreign to how they roll.
Confession time: I feel pure geek here. I highly anticipate the next release of XAML Power Toys. If that doesn’t come across ‘geek’ enough for you, how about this: I am actually looking excited about the incremental version of a plug-in for an integrated development environment that leverages the existing XAML tools and adds code-generation and LoB application rapid prototyping.
forward to
Mmmmm. Prototyping…
Anyways…I have put out a couple of suggestions that Karl is working into his next build. Sweet.
Raven (the project I’m working on) is growing up quickly and the rapid release schedule of the application does not really allow for, say, time to do things like code my own forms. Working with the XAML power tools I am able draft the first few versions of a form before we start the styling and business rule authoring process.
This turns out to be very productive. There are three apps now in the wild for Raven – Prospect, QueueMonitor and HelpDesk – and this was achieved in just three short months.
I have been able to spike out the customer stories in hours rather than days, and using a direct connection to the dev or test database (using LINQ to SQL…another prototyping tool in my developer’s Swiss army knife) and the XAML Power Toys, I can actually stitch together forms with real data that the users recognize. This lets them get past the visual deficiencies of the iteration much more quickly.
…well, not really.
But, indirectly, he singlehandedly exposed a health care system that allowed a girl to die.
He then manipulated it to ensure that he wouldn’t, but still hasn’t refunded my money for the crappy iPod that always freezes.
Congrats to everyone who buys Apple products: your evil leader will be back to lead the demons soon.
http://www.msnbc.msn.com/id/31509368/ns/health-health_care/
And, by many accounts, there are far less selfish actions exerted by those on the other side of the ‘glass’:
On the evidence, [Steve Job] is nothing more than a greedy capitalist who's amassed an obscene fortune. It's shameful. In almost every way, Gates is much more deserving of Jobs' rock star exaltation.
Article on the Apple Cult’s leader: Cult of Mac
Okay, either people don’t know about this, or it’s being distributed in other ways.
The team that runs the web servers for Microsoft has compiled a list of nearly every available mobile device type that has requested a page from its servers (using services like Live, Hotmail, etc). The compilation includes an incredible set of over five dozen properties exposed about the mobile browser used on that device.
If you write applications for mobile devices, you need to be using this! Because each device might be in horizontal or vertical mode, because the screen sizes vary, because different devices can playback different kinds of media, because some mobile devices might support AJAX…because of a whole host of things, if you are writing web applications for mobile devices using ASP.Net you really need to get plugged in here.
Here’s the project site on CodePlex: Mobile Device Browser File
Now, what gets me is that there are so few downloads. Even the one that’s been around longest has not even 700 downloads!
What’s so beautiful about this nonsense I’m going on about? Well, check this out:
Simply by dropping the mobile.browser file in a folder in your project you gain instant capabilities detection from the existing framework, without a line of code. Except, of course, to check the capabilities.
How easy is this:
if (Request.Browser.IsMobileDevice)
{
if (int.Parse(Request.Browser["ScreenPixelsWidth"]) > 240)
Label1.Font.Size = 40;
else
Label1.Font.Size = 20;
}
Now, you are likely to do something more interesting, like serving up appropriate image types for the devices.
Either way, when you pair this with ASP.Net MVC you start to get some very interesting things going on, as Scott Hanselman wites.
I just can’t believe more people aren’t developing in the mobile space…or don’t care to leverage this powerful resource!
Just ran into another deployment problem.
I went to publish a demo project to a live production server that was set up about two years ago. The machine is fairly mid-level for its era. It is running Server 2K3.
And its system drive is formatted as Fat32.
So back to the deployment problem. I went to deploy and, after getting everything setup (host headers, created application, test app memory pool, virtual directory) in IIS I attempted to publish.
No go. No Front Page extensions.
So I download the bits and try to install…no go. Must install on an NTFS partition. Crap.
Now I’m left with the decision to either try to upgrade the drive to NTFS or setup an FTP account. Eck. But it’s a production server and there is exactly zero hit on running FTP.
Username, password, home directory all configured and slamming the project up on good’ole port 21…
Rough couple of days here.
The legacy application server has been acting up and causing a lot of problems. Unfortunately that means that I’m tied up for hours at a time trying to track down errors, login problems, server performance issues or helping to debug reports that were written four years ago that no one remembers who or for what purpose the report was written.
</rant>
I have been trying to work through some issues with the TcpClient’s ability to stay connected to a custom device that supports telnet. I can make the connection just fine, but after I read from the stream, then write back to it, I unfortunately lose the connection.
Checking the CanRead and CanWrite properties always return true, but reading from the stream was causing an exception. I later sourced this part out to an IO exception because I was reading past the end of the stream…but I was doing that because I was expecting more text coming down the pipe.
Also, there seems to be a significant performance hit when you start to read from a NetworkStream object. When I fire up CMD and telnet into the device I receive the data I expect (namely, the login request) almost instantly; there is a 5-7 second delay using the managed wrappers.
I did, however, manange to wrap up development on my background ping library. This will help the CSRs as they work the helpdesk. There are currently 3-6 devices that as a matter of process we check for visibility with pings when a customer calls in. I am this |-| close to having that fully automated and running for any related device between our head end and the client.
Tomorrow is Thursday. I need visible output for this week’s goals…
An interesting post from the folks on the Visual Studio Editor blog site:
Not only will you be able to make, copy/paste, drag/drop, and delete box selections, but you’ll also have the new ability to insert and edit text on multiple lines.
Box selection is one of those hidden treasures in Visual Studio. Prior to having it as part of the IDE I used to copy and paste blocks of code or text data files I had to massage over into Word to use the box selection features of Office.
This is the next step, with multi-line editing becoming part of the tool mix we are getting treated to:
The full article (with video) is here.
This is my pledge:
In spite of having to do some experimental development for the iPhone – and thus having to live with a Mac Mini on my desk – I will not convert to being a Mac user.
There are no buttons on the mouse. The keyboard is terrible.
But I must admit, I am quite fond of a device that sounds like Wall-E when it boots up…
Today I was trying to spike out a simple test where I was maxing out my network card and/or my CPU as fast quickly as possible.
Don’t ask.
Anyways, I had two blocks of code that I was working on, one to scan a subnet for ICMP-responsive devices, and another to blitz said devices with ping requests. I needed to collect a bunch of IPs to ping so I didn’t fully flood any devices…then I was switching back to the block that did the pinging. After using the Visual Studio buttons for commenting and removing comments for a while I remembered some c commenting bits I learned a while ago.
This is a really simple trick that an old friend of mine showed me back in the late 90’s (who now works at ohai). The idea here is that you often find yourself working between two code blocks, but don’t want one to run while the other is, you’ll be forever commenting out one block of code and uncommenting the other.
In any language that supports the following two comment marks:
/*...*/ and //
…it is really easy to set up to comment out one block of code and work on the other. Here’s the setup:
//*/
Console.WriteLine("Hello");
/*/
Console.WriteLine("Hello");
//*/
Now for the trick. You’ll see that the top block is active and the bottom block is commented out. To switch between blocks, simply comment out the first slash on the first line, as so:
/*/
Console.WriteLine("Hello");
/*/
Console.WriteLine("Hello");
//*/
…and Presto! you have activated the second block.
I don’t normally run into this when I’m working in a TDD project, but I do hit it when I’m spiking a fair bit. This isn’t really a game-changer or anything, but it is certainly handy when you’re fighting with a block of code or two.
I am in the process of setting up my development VM and taking a little inventory for the apps that I find indispensible on a weekly – if not daily – basis.
Here they are, in no particular order:
These keep me working and productive. I suppose I should also mention Office apps in general (Outlook, Word, Excel) but I’m one of those crazies that thinks those should just be baked into the OS already…or immediately available through a browser with just the right amount of functionality that I never have to wait for…
Sometimes you find a solution to a problem and you just add it to your Swiss Army Knife of code to handle similar problems down the road. If you’ve ever used a Timer on a WinForms application, you’ve likely run into the following error message:
Cross-thread operation not valid: Control 'someControl' accessed from a thread other than the thread it was created on.
Since .Net 2.0 I’ve run the same game strategy for hopping back over to the UI thread when I want to make updates. Basically, I make a delegate with the appropriate parameters to handle whatever update I want (like strings for the Text property on a Lable), then check InvokeRequired to re-call the method, if necessary.
But I’ve been neglecting a good friend: anonymous delegates.
Today I came across an article related to something entirely different and they mentioned ‘MethodInvoker’. This turns out to be a very clean implementation. Because the anonymous delegate gets the scope variables of the method it’s created in, you don’t have to pass parameters, nor do you have to re-call the same method.
The end result – sans named delegate – looks elegantly like the following example:
void CoordsReceived(object sender, CoordinatesReceivedEventArgs e)
{
this.Invoke(new MethodInvoker(delegate()
{
lblLattitude.Text = e.Lattitude.ToString();
lblLongitude.Text = e.Longitude.ToString();
}));
}
Still very readable, arguably more so, and still takes care of getting back on the right thread to update the UI.
I can’t believe I missed this for so long…all those delegates!
I recently responded to a thread on MSDN forums where a person was trying to get something to happen when the IsFocused property of a ComboBox was set to true in WPF.
Because of some of the work I had previously done on retemplating my own ComboBox, I quickly recognized that this was an issue with the way the control is templated. Largely, what is going on is that the ComboBox has a complex visual tree and when the ComboBox is in edit mode the control that has focus is actually a textbox inside the control template.
Thus, the ComboBox in WPF will never have its IsFocused property set to true.
I realized, though, that this has an effect on other things, such as trying to template a control through styles and triggers without replacing the entire visual tree.
Take the following style for a WPF Button:
<Style TargetType="Button" x:Key="ButtonStyle">
<Style.Triggers>
<Trigger Property="IsEnabled" Value="True">
<Setter Property="Effect">
<Setter.Value>
<DropShadowEffect/>
</Setter.Value>
</Setter>
</Trigger>
</Style.Triggers>
</Style>
If you put that in the Windows.Resources section of your window and set up a button to use that style, you’ll see that the button
immediately reflects the DropShadowEffect. Change the above IsEnabled to IsFocused and run the app. The DropShadowEffect is only rendered if the button has focus.
Now, try the same thing with a style for the ComboBox:
<Style TargetType="ComboBox" x:Key="ComboBoxStyle">
<Style.Triggers>
<Trigger Property="IsEnabled" Value="True">
<Setter Property="Effect">
<Setter.Value>
<DropShadowEffect/>
</Setter.Value>
</Setter>
</Trigger>
</Style.Triggers>
</Style>
This, again, works off the hop, even with IsFocused. But if you set IsEditable to true, things change.
As you can see from the screenies to the right, we don’t get our drop shadow rendered 
even when the control has focus when it’s in edit mode.
I think the only solution is to work around this through code-behind in the class. This means that you’ll either need to plop some code into each form where you want to bind to the IsFocused property of the ComboBox, or you’ll need to create your own control library (not a bad idea if you’re trying to do something like this, I suppose).
So, I tried to go down that route. My first attempt, though close, isn’t what we are looking for. Indeed, it looks kinda cool and 
some might find it funky, but it doesn’t put the shadow where we’d like – namely, on the ComboBox itself.
Here’s the code:
this.comboBox1.Loaded += delegate
{
TextBox tb = (TextBox)comboBox1.Template.FindName("PART_EditableTextBox", comboBox1);
if (tb != null)
{
Style tbStyle = new Style(typeof(TextBox), tb.Style);
Trigger effectTrigger = new Trigger();
effectTrigger.Property = TextBox.IsFocusedProperty;
effectTrigger.Value = true;
Setter dsSetter = new Setter(TextBox.EffectProperty, new DropShadowEffect());
effectTrigger.Setters.Add(dsSetter);
tbStyle.Triggers.Add(effectTrigger);
tb.Style = tbStyle;
}
};
Perhaps a simpler approach would be just storing a couple of style references in the window (or the control, if you’re rewriting) as such:
Style _cboDropShadowStyle;
Style _cboCleanStyle;
We build up our styles in the ComboBox.Loaded delegate:
this.comboBox1.Loaded += delegate
{
// store the clean style
_cboCleanStyle = new Style(typeof(ComboBox), comboBox1.Style);
// build and store the dropshadowed style
_cboDropShadowStyle = new Style(typeof(ComboBox), comboBox1.Style);
Trigger effectTrigger = new Trigger();
effectTrigger.Property = ComboBox.IsEnabledProperty;
effectTrigger.Value = true;
Setter dsSetter = new Setter(ComboBox.EffectProperty, new DropShadowEffect());
effectTrigger.Setters.Add(dsSetter);
_cboDropShadowStyle.Triggers.Add(effectTrigger);
};
Then, finally, we write our event handlers (be sure to mark the XAML up accordingly):
private void comboBox1_GotFocus(object sender, RoutedEventArgs e)
{
comboBox1.Style = _cboDropShadowStyle;
}
private void comboBox1_LostFocus(object sender, RoutedEventArgs e)
{
comboBox1.Style = _cboCleanStyle;
}
If you’re not already using the XAML Power Toys from Karl Shifflett, and you’re developing WPF/Silverlight apps with the MVVM pattern, well…get on it!
While he is a VB-er, he kindly makes his tools available to those of us on the dark side as well (those who develop in c#). Unfortunately there is a small issue with the code generation bits for the Create ViewModel For Class feature.
For all collection types the output is similar to the following:
private IEnumerable(Of QueueMember) _queueMember;private IEnumerable<QueueMember> _queueMember;
This is a small cost for the significant benefits of this IDE enhancement and I wholly hope that, now that Karl is working for the mothership, that these features are carried into the new IDE.
Wouldn’t it be great to have a Pattern Extensions toolset, allowing for code-generation of stubs for various patterns? Of course, it would be extensible, so you could implement your own variations. Seems to me this is close already, with templates and snippets, just that it’s fractured. I routinely develop various bits working with Resharper, project templates and snippets to fill in the blanks, but an actual tool window and community support for all kinds of stub generation would be a great addition.
Thanks to everyone who made this last weekend’s Walk to Cure Diabetes such a success in such a small town. We set a local record with 360 walkers and raised over $32,000 going directly to finding a cure for Type 1 Diabetes.
Here is the post from last week where I mentioned a video featuring my son: via YouTube.
To donate: go here.
I am running into a problem under certain circumstances with projects created by the WPF Model-View template for WPF applications in Visual Studio 2008.
When I try to add a new class to a project through the Visual Studio 2008 IDE I receive the following error message when I try to add a new class (or icon, LINQ to SQL file, etc):
I can reproduce this easily:
I am running Vista 64, Visual Studio 2008 SP1 with .Net 3.5SP1. There are no add-ins loaded except the debugger. I do not (typically) run as Admin, but this makes no difference in this case as the same behaviour is observed either way.
I do not see this problem if I do not add the test project.
The black art of software development is shrouded with geek-speak, bumped (read:missed) deadlines, over-budgetness and tens of thousands of lines of code that very few can appreciate the beauty of. I'm hoping to write a few words every week to keep focused on the tasks central to the success of this project.
The first few bits in the Raven HelpDesk have been delivered for feedback to the the HelpDesk staff. It was well received and though not terribly functional, it has ensured that our environment is configured and they have everything they need to run the app. They are also now in the feedback loop to help establish features and process changes.
The idea on an agile project is that we're trying to get bang for the buck, continuously delivering what serves the company where it is needed most. Bang comes in two forms: saving money and making money. Which is really the same thing. Since the large part of development on Raven is internal, this means we are looking at the 'saving' side of the equation.
My goal is to be delivering a NextMostImportantThing every week. Some things will be more visible than others, some things will require process changes or new processes. With co-operation and guidance from co-workers, these will all move us to greater profitability, proficient staff, efficient software and better productivity.
Here are the five NextMostImportantThings in my queue (also referred to as Customer Stories):
Next week, I am trying to complete "Identify Customer - Automated through asterisk", to which I am very close. I will be back into data conversion and correction mode early in the week and working with some domain experts here to get the next block of data bits in line.
Many of these stories play into each other. For example, two other stories (Poll Asterisk Queue, Present Asterisk polling results) were completed when I wrote the code this week for the Helpdesk Monitor (aka, Thompson Turkey). The queue monitor rose in priority this week as Queue Tip continues to fail on a daily basis, sometimes several times a day. This usually results in one or more emails, phone calls or visits to a technician, who must then reset the application.
Because I was preparing to work on the "Identify Customer" story, the Helpdesk Monitor was a great test-bed and served the purpose of retiring Queue Tip.
The YAGNI Principle
I have already received a number of requests for features in different parts of the app.
YAGNI stands for "You Aren't Gonna Need It". Developing under the YAGNI principle means that all feature requests and software development tasks are run through the filter of "Is this required? Is it desired? What will it cost? Can we make that money back? Will anyone actually use it? Has the person requesting the feature thought through these same questions? Do they fully understand the domain?".
Continuous input from folks in various departments helps to keep all stories in context of what is TheNextMostImportantThing and therefore helping move this project into the black as it saves the company money...in effect allowing it to pay for itself.
If you just want to grab some properties off a list of well-known entities in an Active Directory group, here’s some code to help you achieve that:
DirectoryEntry group = new DirectoryEntry(LDAP://CN=yourgroup,CN=users,DC=domain,DC=ca);
object members = group.Invoke("Members", null);
foreach (object member in (IEnumerable)members)
{
DirectoryEntry entry = new DirectoryEntry(member);
Console.WriteLine(entry.Name);
Console.WriteLine(" {0}", entry.Properties["telephoneNumber"].Value);
Console.WriteLine(" {0}", entry.Properties["displayname"].Value);
}
If you know the data is in there, but you’re not sure what it is called in Active Directory, you can change that foreach loop to the following to dump everything you’re allowed to see. This is pretty trivial in any .Net language, and the Active Directory properties are easy to work with (they’re just a collection):
foreach (object member in (IEnumerable)members)
{
DirectoryEntry entry = new DirectoryEntry(member);
foreach (string prop in entry.Properties.PropertyNames)
{
Console.WriteLine(" {0}: {1}", entry.Properties[prop].PropertyName, entry.Properties[prop].Value);
}
break;
}
I added the break in there so it just dumps the properties of the first entity in the list.
Obviously, you’ll want to change the “yourgroup”, “domain” and “com” to whatever your server is configured to use. Then, you’ll be well on your way to extracting properties for users stored in Active Directory.
I am so proud of my son, who gets over 3000 needles a year and still wears a smile on his face.
Please pledge online if you would like to support Juvenile Diabetes. (That’s http://jdrfca.donordrive.com/index.cfm?fuseaction=donorDrive.participant&eventID=700&participantID=13898 if you have trouble in your reader.)
Brandon has been living with Type 1 Diabetes since the age of 4 and receives daily insulin injections to keep him alive.
Juvenile Diabetes is not contracted from something you do or don’t do, from how much of something you eat, or how much exercise you get. It is an auto-immune disease that strikes kids, who live with the disease their entire lives.
Thanks to all who have helped Brandon and his Screemin’ Beemers raise over $10,000 so far!