Podcast Review: Adam Carolla

I'm not a big podcast guy, but I do have a few regulars. I'm a fan of Bill Simmons, the ESPN Sports Guy and probably the most read sports columnist in the US, and I love the CBC Radio: Search Engine podcast, but lately I've found myself regularly tuning in to the digital musings of Adam Carolla.

It seems to me like Hollywood works in posses. I'm not sure if this is a certifiable trend, but the Judd Apatow phenomenon is not unique to Seth Rogan and Co. In fact, this phenomenon might be another instance of viral marketing - or maybe "marketing through networking" is a better term. With Apatow films (and some mimickers, like Zach and Miri Make a Porno,) the same cast of actors each take turns starring and guest starring and making cameos in each other's movies. Even Kevin Smith, with Porno, got an honourary pass into the Apatow guild when he got Rogan and Elizabeth Banks to star in his film. Hollywood loves this because it garantees a certain minimal box office and makes marketing easier for them.

The same could be said for the Jimmy Kimmel crew. Kimmel and Carolla started off in radio, but they eventually hosted The Man Show together. Kimmel has gone on to great success on ABC, while Carolla went back to early-morning talk radio on CBS. Carolla's show was #1 in many parts of the US, but CBS pulled it recently when they shut down their radio operations (or at least the station that was producing Carolla's show - I'm not sure of the details and it's not really that important.) I only caught the last couple of days before the show went off the air, but it was consistently funny and surprisingly touching at the end. Carolla plays the persona of a a-hole with a heart of gold down to a tee. Carolla, Simmons, Kimmel, Sarah Silverman (who dates Kimmel) and others, including Dave Dameshek, have all worked together, hang out together (we hear and read about the Sunday afternoon football games at Kimmel's house from multiple sources) and give each other props by supporting each other's projects.

The day of the announcement, Carolla was on Bill Simmons' podcast (see how that works?), who coincidently worked with Kimmel on his show in the early days before returning to his post as a fulltime columnist at ESPN. Carolla announced that he was fine with the layoff, since CBS will pay him out for 2009, so instead he's going to do a podcast for free and have some fun with that.

Which brings us full circle. Carolla is now pulling in the biggest numbers of any podcast available via iTunes, ever, and he's almost done it by accident. However, this is not really surprising - he's getting plugs from Simmons (who has a several million per column readership) and Kimmel. He's also gotten some very good guests. And finally, since he's doing this all on his own, he's producing a semi-professional show with professional entertainers that has no limits to the conversation - anything goes. No FCC, no sponsors, no nothing. The result is a surprisingly intimate (if you want to call it that) experience. You get the feeling that you're sitting in a room with these guys, just shooting the shit. But the guys are real stars - some of them are the best at what they do.

What's also intriguing is that you're getting that feeling with some recognizable personalities: Kimmel, Simmons, Andy Dick, Seth McFarlane, Tom Arnold, Dave Dameshek, Aisha Tyler... these are pretty big names. And what's more interesting is what they talk about - Andy Dick goes into his substance absuse issues, Tom Arnold discusses his relationship with Roseanne Barr and why he hates Jason Alexander, Seth McFarlane explains the origins of Stewie from the Family Guy (my girlfriend was thrilled to find out that he based him on Henry Higgins from My Fair Lady), and so on and so forth. And throughout, Carolla uses his radio host experience to draw out interesting tidbits from his guests, while chipping in some hilarious stories of his own.

But the best part is the regularity - I think one of the most underrated reasons why podcasting isn't the new radio is consistent scheduling. I'm a creature of habit, and I like the idea that every morning I can wake up, and before I step out the door to head to work I can grab the latest Carolla podcast from iTunes. He's managed to do this on a daily basis during the week - and has a bonafide guest to boot. If you have the discipline to produce content that regularly, you'll beat out everyone who only drop a podcast whenever it's convenient for them.

Read more...

WPF: Great Resource

I recently had a severe memory leak issue relating some latent WPF animations - a very innocuous animation in a third-party toolkit was causing a complete memory leak of my user control within my application. What's worse is that our workflow called for us to destroy and re-create the control, and as a result the control was leaking several times over.

I found the solution to this problem on Ramon's weblog. I searched quite a long time for this issue and his blog was the only place where I found the information I needed (including MSDN, of course.) So I wanted to give him a shout-out over here. He lists a few interesting and nasty WPF-related memory leaks that are being worked on by Microsoft.

I'll explain the particular issue I was facing in a future post.

Read more...

WPF: Generalizing using generic.xaml

In my previous post, I went on (and on) about a mechanism for loading generic styles and data templates using a Uri load component scheme. This would load your styles and apply them to the control or window that does the loading.

Since then, I've discovered the somewhat magical and better solution to all this, which is to define a file called \Themes\Generic.xaml in your project root. This apparently tells WPF to tap into its uber styling code and plug in your styles defined here.

I had to dig deeper here, because my templated code was working for my main component, but as soon as I added it to the definition of a floating frame outside of the control (which is a third-party component that I don't have control of) it failed to read the template. Adding the Data template definition to \Themes\Generic.xaml did the trick.

Read more...

WPF: Loading Generalized DataTemplates in Code

I've been working WPF quite a bit recently and am discovering the ins and outs of this beast. It's nothing if not ambitious.

I personally like it. A lot. I worked with .NET Forms previously and Win32, and Java Swing before that, and this is far and away the most sophisticated UI framework I have ever seen. However, it's still relatively new and documentation (as well as good examples) can be scarce.

One thing that I've noticed when browsing examples online is that most people present ideas through trivial examples - in fact, they repeat the same information through repeated trivial exercises that can be found on other sites. I'll try to avoid doing that, but that also means that I'm going to assume that you know what you're doing. I'm not going to post tutorials or explain basic WPF concepts that are covered in the all the main WPF resources (see another post in the future.) I'm going to post annoying factoids that have halted progress for me personally at work, and hopefully this will help someone out there.

Let's jump in and take a look at generalized DataTemplates in WPF. By generalized, I'm talking about the DataTemplates that set their type via the DataType property. Sampled from MSDN:

<DataTemplate
  DataType="{x:Type c:GreekGod}">
   <TextBlock Text="{Binding Path=Name}" Foreground="Gold"/>
</DataTemplate>

Like the Style element, DataTemplate uses the DataType property as a way of hooking itself into the general scope of your application. Style's version of this is TargetType.

Now, here's the problem: Where do you specify this DataTemplate? Where does it go in the project? No one seems to make this clear, or provides a satisfactory answer. The real answer is that this DataTemplate needs to exist in a loaded Resources dictionary somewhere up the logical chain of elements where you expect it to be used.

Everyone assumes a trivial layout for a project. "If you need to create a DataTemplate, then just add it to the Window.Resources element, dumbass." However, this is not very helpful, for anyone who is working outside the standard layout conventions (for instance if you're developing WPF controls for a mixed managed application, and blending them into a Win32 frame.) Sometimes, you don't have the benefit of simply adding the template to a higher level component because, wait for it, the XAML might actually be dynamic. Maybe your application reads in XAML to construct a class at runtime. Maybe popping in a DataTemplate definition here is not such a good idea.

So now I'm scratching my head and going back to the root of the problem - how does WPF know about this template in the first place? If I put it in a loose XAML file in my project, and have it compiled, shouldn't the template be properly registered at runtime? Turns out that that isn't the case. Loose XAML does not a loaded component make, which I thought was interesting, and actually makes a lot of sense. This is something that may not be clear from MSDN: Just because you put a DataType property on a DataTemplate in a ResourceDictionary element without a x:Key in a XAML file that is compiled into your project, doesn't mean that it's actually registered with WPF at runtime. It needs to be loaded into the logical chain somewhere.

XAML is cool, but it's still a static definition of components. If you're going to need to sew anything in, you're best bet is to go back to code.

In my case, the answer lay in dynamically loading the XAML and adding it to my root control's MergedDictionaries set (no handy top-level Window, sorry), in the root control's constructor.

To do this, you create a Uri object that points to your project XAML resource (compiled BAML, actually), and use the Application.LoadComponent() static method to load and create the root node of the XAML. If you store your DataTemplate in a ResourceDictionary, the code might look something like this:

public RootControl() {
 InitializeComponent();
 Uri uri = new Uri("MyAssembly;component/Templates.xaml", System.UriKind.Relative);
 Resources.MergedDictionaries.Add((ResourceDictionary) Application.LoadComponent(uri);
 
 // ... continue initialization
}

Take a look at the MSDN Uri class definition for details as to why this syntax works. The above code is written for an assembly called "MyAssembly.dll", and with a XAML file called Templates.xaml in the root of the project. If you place your loose XAML files in subfolders, add the path after "component" in the Uri. "component" is really just the root of your project.

MergedDictionaries is a handy way of importing and aggregating resources from different definitions into a single Resources object. By loading the XAML into the root component's merged dictionary, you are indirectly registering the DataTemplate into the current logical scope, meaning it will be applied to your instantiated data.

A note concerning Merged Dictionaries and performance. If you have many resources and they are merged into a control that instantiated many times over, be aware that each Merged Dictionary is created once per component - you may want to look into ways of statically organizing your resources. I'll probably be looking at this on my side and will share any advice concerning this in future posts.

Of course, if your root class has a XAML definition, then go ahead and use this simpler notation:

<RootControl x:Class="UserControl"
 xmlns="..."
 xmlns:x="..." >
<RootControl.Resources>
 <ResourceDictionary>
    <ResourceDictionary.MergedDictionaries>
       <ResourceDictionary Source="Templates.xaml"/>
    </ResourceDictionary.MergedDictionaries>
 </ResourceDictionary>
 </RootControl.Resources>
</RootControl>

And that's that. Hopefully this post manages not only to convey how to load templates via code, but also provides a bit of insight into how WPF does things under the hood.

Read more...

A Note About This Page

I have a reasonably wide variety of interests, among them music, movies, politics, photography, tango, and sports (mostly hockey.) I might use this space to talk about any of those things, but my profession is software design and programming. I was trained as a Software Engineer at Concordia University at the turn of the millennium, and have been working at Autodesk Canada for the past five years in Montreal, Canada. It would be fantastic if people other than programmers read these humble words, but I'm guessing that if anyone stumbles on this page, it'll be a programmer googling some inane or arcane detail concerning WPF or .NET or something (what I currently work with at my job.) Hopefully some of those programmers will have other interests and will stick around for the other things I have to say.

So here goes...

Read more...