Just to be clear, Marc Clifton’s MyXaml framework for adding a declarative UI mark-up language to today’s .NET framework is not a clone/sub-set of Microsoft’s XAML or Avalon targeted at Longhorn. In other words, while MyXaml provides a number of the benefits of declarative UI mark-up for building smart/rich clients today, MyXaml is not a way to write WinForms code today that will seamlessly turn into Avalon code tomorrow.

The reason I mention this is because I’ve seen some folks get a bit confused by the use of “Xaml” in the name (Marc is using XAML as the generic Extensible Application Mark-up Language and not as related to Microsoft’s XAML).

On the other hand, there are two other projects that are aiming to clone/sub-set XAML/Avalon on .NET today: Xamlon and Mobiform’s XAML products. I can’t claim that either of these will actually help you transition to Longhorn when it comes along, but I know that Xamlon’s XAML samples work with minor tweaks on their parser and on the WinHEC build of Longhorn.

Here. So far, it's provided the information required for two of my Orkut friends to wish me a happy birthday. Other than that, I haven't found a use for the site, however...

Jason Zander, a Microsoft Product Unit Manager, not only points out the implementation problems we have with being able to unload .NET assemblies, he recommends AppDomains as the solution you really want anyway. And then, when his commentors dissent, he’s right back in there asking for more information.

Have you got opinions on this topic? Make hay while the sun shines!

I'm not sure what I would make if I had one of these, but that doesn't stop me from wanting one.

It’s generally know that the thing we call software “engineering” is nothing like that. We just don’t have anything like the rigor that real engineering disciplines do and we need them. I wonder if Brian’s quest to understand the real software life cycle and codify them constitutes another step down the road that the other engineering disciplines took to become predictable, schedule-able, reliable, budget-able and robust. I hope so.

I haven’t read Coder To Developer, but I love the term that secretGeek has pulled from it: “Inch-Pebbles.” When I was running DevelopMentor Software I learned to schedule from my then-mentor John Robbins, who learned it at NuMega (of BoundsChecker fame).

John’s insight was that nobody can look at a software release or even a feature and come up with an accurate schedule. Instead, they hold up their thumb in the wind and say, “Hmmm… Two weeks.” Of course, it’s never anywhere close to that. However, if you break something down into tasks of 1-2 days, aka “inch-pebbles,” those can be accurately estimated and then rolled up into how long each feature and then each mile-stone will actually take (“What? Three months?!? I had no idea…“). Once I learned how to schedule debugging time (rule of thumb: as long as coding time), we were able to schedule our software to w/in a week or two (although John, to show off, would pad a little and pick the day and time and deliver the golden master CD with balloons, champagne and marching band music : ).

At the time, we didn’t have a name for the granularity that could be accurately scheduled and, since I haven’t read Mike’s book, I don’t know how he defines the term “inch-pebble,” but from now on, that’s what I’m going to call it and if that’s different from what Mike called it, well, then he’ll just have to update his definition in his next edition. : )

Here.

I love Luke’s RSS Aggregator [1]. He loves my book. For what more could a man ask?

[1] I just tried the lastest RSS Bandit — don’t get me started…

Ian posted a fun little snippet of XAML showing off the new support for image effects on anything that Avalon renders, not just images:

<FlowPanel xmlns=“http://schemas.microsoft.com/2003/xaml”
  xmlns:def=“Definition” Text.FontSize=“24″>
  <Text>This seems clear enough.</Text>
  <Text>
    <Text.ImageEffect>
      <ImageEffectBlur Radius=“3”/>
    </Text.ImageEffect>
    This is considerably less clear.
  </Text>
</FlowPanel>

I’ve rewritten it using a more compact syntax:

<Text ImageEffect=“*ImageEffectBlur(Radius=3)“>
This is considerably less clear.
</Text>

1. For 1 free UUID, is this legal XAML? Why or why not?
2. For 2 free UUIDs, what other popular XAML construct uses the exact same syntax?
3. For 3 free UUIDs, what popular C# construct has a similar syntax? How is it subtly different? (Hint: I’m not showing the difference in this example.)