It's been ten years since I had formal training in Spanish. Unfortunately, I haven't used any of it. Lately, I've been thinking about how I can fix that. I only know a couple of people who I could speak to, so forcing myself into it isn't quite an option. So, I figured I'd take a more sensible approach, given my day-to-day life. I have a three-pronged approach. First, I subscribed to a few Spanish-speaking blog feeds, which will allow me to read at my own pace. Next, I subscribed to a few Spanish learning podcasts to hone my listening skills. Finally, I've decided to write my blog posts in English and Spanish, which will allow me to express myself in Spanish. I'm hoping these three things will give me what I need to converse without taking five minutes to formulate sentences. Using blogs and podcasts will just help ensure I stick to it, since I already use these tools to stay on top of the tech industry.

This isn't intended to be a New Year's resolution, but I'm hoping I stick with it for the long haul. I'd appreciate any help correcting my grammar as I learn. This will obviously slow the frequency of my posts, since I'll have to write them in English and hand translate to Spanish. Hopefully, I'll grow a Spanish-speaking crowd to make that worthwhile for others.

Since I first had a chance to really get into it, PowerShell has been great. For the first time, I have a real issue, tho. PowerShell handles arguments differently than cmd.exe. Specifically, the difference is the colon (:). In cmd.exe, arguments are split by spaces; but in PowerShell, the colon translates into a new argument. For instance, myapp.exe -arg1 -arg2:abc translates to { "-arg1", "-arg2:abc" } in cmd.exe, but { "-arg1", "-arg2:", "abc" } in PowerShell. Sure, we can code around this; but why should we?

I just had to complain about the RichTextBox control in WPF. As part of the diff tool I'm working on, I spent a few hours working on an XSL stylesheet to color-code the different regions of the compared text files. Given the simplicity of XSL, I figured it'd be perfect to quickly get something out that looks the way I want it to and still leave room for customization later (i.e. to support VS Diff and/or TortoiseMerge styles later). So, off I go working on a stylesheet to format my proprietary XML (does anyone know of a standard XML representation of text changes?). Given my web experience, HTML was the easiest thing to go to, so that's what I did. Low and behold, HTML isn't supported by the WPF RTB. You've gotta be kidding me!? I guess this is just part of the "youth" of the technology.

While I have absolutely no doubt HTML support will be added later -- probably in the .NET 3.6/4.0 time frame -- I'm not waiting around for it. So, what are my options? One thread states that only text, RTF, XAML, and XAML package are supported; however, based on the test run right after HTML failed, RTF failed, too. I guess this leaves me with XAML, since text just won't cut it.

I wanted to learn XAML, so I guess I was just asking for it. The good news about this is that I should still be able to use my XSL approach and just have the stylesheet produce XAML instead of HTML. The other good thing about it is that the approach should enable me to get a little more fancy with the contents of the RTB. With some of the things I have in mind, this could be exactly what I need. It also gets me out of the RTF business, which is just one more "language"/API to learn.

As always, if anyone has any thoughts or suggestions, I'm all ears.

Given my new venture, I have to complain about something... small tools/utilities that don't close when I hit Esc. Don't get me wrong, I'm not saying everything needs to close on Esc, but there is a lot that could. Take, for instance, the vast number of utility windows in Windows... wait, no, let me revise that... How about every control panel applet (or whatever you call them). Ok, sure, a lot of them are dialog-based and close as you'd expect when Esc is pressed. Let's look at the Windows Update window in Vista, tho. Since it's based on Windows Explorer, Esc doesn't close it. There's no OK/Cancel button; no buttons at all. So why would it hurt to support Esc? Perhaps this is simply an oversite, but it's one that way too common. I can name a dozen places like this in Windows, but I'll spare you the agony. Microsoft isn't the only culprit, tho. All I ask is that developers think about their users a little more. Is there any way you can shave one keystroke, one mouse move, or even a transition from the keyboard to the mouse. All these things add up to big points in the user experience arena.

I recently got an error that didn't seem to make a lot of sense to me...

Specified element is already the logical child of another element.

It sounds pretty straight-forward, and I'm sure it normally is, but the real oddity is that the same section of code was working not too much before the latest run. I did a few searches and saw a number of people trying to address the problem the error actually talks about, reusing control instances. This seems to be more of a problem when you're programmatically adding controls, which I wasn't doing, so that made even less sense. Despite all this, I changed my code around, re-ran the app, and was rid of the problem. All good, right? Wrong.

The next problem I had was a stack overflow (in another section of code). Ok, two strange errors in a row? Something's up. All I really remember changing since the last run was hooking up some command bindings. The call stack revealed that the problem was in a constructor of a user control on my main window. I removed some code from there, ultimately killing all functionality, but that didn't do it. I then went back to the main window and looked at the XAML. What could be triggering the repeated calls to the constructor? I then found a spot where I was doing some data binding. I definitely remember adding this recently and know I did it only half-understanding how it worked, so I removed it and all was back to normal.

That's pretty much when it hit me. The controls were being added multiple times because the constructor was being called successively. Bah! I went back and changed the original code I modified back to the way it was because I felt it was much more concise. Everything still worked, so I know that was the problem.

Basically, what I'm getting at is, if you get this error and you don't know why the heck it came up, comment out the offending code and try to re-run the app. If you get a stack overflow when calling InitializeComponent(), then the commented out code isn't the problem. Take a look at your XAML. Unfortunately, I don't know enough about how all that gets hooked up right now, so I can't give a definitive suggestion on where to start, but bindings are a pretty obvious one, so check there.

Ok, I just thought about something and had to tell somebody, so I volunteered you... (suckers)  Last week, I took a WPF class Brian Noyes  put on. In that class, he mentioned how the main reason people will consider WPF, at least initially, is when they're looking for a "differentiated user experience." I couldn't help but chuckle as my [strange] mind processed this, tho... "differentiated user experience" = DUX... so, if you want to ensure you have a differentiated user experience, you probably want to keep your DUX in a row. HA!! Get it! DUX -- ducks? I kill me!

...ok, forgive me. I just had to get that out. I'm not nearly a dork on here as much as I am in person. I need to work on that.

Every couple of weeks I come up with an idea of a project I'd like to work on to make my life a little easier. This time, I'm going to use it as a way to dig into WPF. To be honest, I've looked at WPF a few times and grumbled at the vastly different model and, of course, groaned at the lack of a data grid. I'm trying to get past that, tho. Actually, for this little venture, I don't need a data grid, so I'm not concerned there.

I've grown into a love-hate relationship with WPF. I love the ability to create compelling UIs, but dread the flux of non-standard apps that seems imminent. I love the idea of a new model, built on the lessons learned of past products -- Microsoft is usually pretty good at this -- but immature tools can kill any such benefits -- and let's face it, WPF is very immature "young." Like I said, tho, I'm working past these issues. Any new tool/technology has a learning curve and needs time to mold itself into what its users really need and want. I expect know WPF will be no different.

So, what will I be working on? Something that's caused me a lot of heartache... a diff utility. Not quite the compelling opportunity most expect, but I think there's plenty to gain. Worst case scenario, I get some experience with WPF and drop a half-implemented project -- it wouldn't be a first (unfortunately). At best, we'll have a great diff utility built on the latest and greatest .NET technology.

My intentions are to ultimately make this available on Codeplex, but I need to find out how to best do that. Not that a Codeplex project is hard to setup; I'm more concerned with including this in another initiative I'm trying to push, which would release even more code to the open source community.

If anyone has any input, I'm all ears. I'd also welcome any insight from seasoned Win Forms or WPF developers. Client development isn't my forté, so I'm sure I have plenty to learn. So, until I have a chance to share something, it's time to get down with my new mistress... WPF.

To my surprise, HTML 5 has been in the works since 2004. While still 5 years late, in my mind, this just shows the ridiculous nature of these standards. I'm not saying all standards are this way... who am I kidding? I love the idea of having standards, but they take entirely too long to make it to the real world. It's like seeing a fantastic project in a research firm. It most likely resolves something you've been pained by for years, but you won't be able to benefit from that work for several more years, most likely. But, I digress... HTML 5 seems to have 3 main goals in mind: flexibility, interactivity, and interoperability.

When thinking about flexibility, HTML 4 gives us a lot. One of the problems HTML 5 seeks to attack is the lack of meaning to one of the most popular tags. No, not the <table>, which is used entirely too much; the <div> tag. Wondering what the problem is? So was I at first glance, but I think what the group is coming up with is better. There will be new tags to represent different sections of a web page. I liken this a lot to a newspaper or magazine, but it works fairly well for the web. The idea is, instead of creating <div> sections to correlate to your header, navigation, different sections and the footer, you'd use more descriptive tags (i.e. <header>, <nav>, <section>, and <footer>). Consider the following images. The first represents what you might do in HTML 4 and the second in HTML 5.

The markup would then look like this for HTML 5...

<body>
  <header>...</header>
  <nav>...</nav>
  <article>
    <section>
      ...
    </section>
  </article>
  <aside>...</aside>
  <footer>...</footer>
</body>

The first thing I thought was that this new model may not map 100% to all sites. Then I realized, they're just websites. You may not think about things as "articles," but that doesn't mean there isn't an equivalent in your context. There are, of course, more and more apps are moving to the web, so depending on how that happens, these may not work. I don't see this getting rid of the <div> tag, tho; merely offering something more specific to use, when applicable. Mixed with CSS, these new tags could be very nice.

There will also be better support for the head (<h#>) tags. Currently, most people use different tags at different levels and style them appropriately, so every <h1> looks the same, no matter what level they're at. With HTML 5, head tags will be more contextual, where different levels will be treated differently. Actually, I'm making an assumption here that probably isn't true at this time -- that CSS will know the difference between the different tags at different levels. CSS 2 most likely won't be able to, but hopefully CSS 3, whenever that's supposed to be out, will. Here's a block of HTML to portray the structure I'm referring to...

<section>
  <h1>Level 1</h1>
  <section>
    <h1>Level 2</h1>
    <section>
      <h1>Level 3</h1>
    </section>
  </section>
</section>

My vision is that the 2nd and 3rd <h1> in this example would be treated as <h2> and <h3> tags today.

While the new tag structure is nice, it's more for designers than developers. The feature developers will be happy to see will be the additional interactivity support, which will require much less work and more compliance across the board. Given the rise of multimedia content online, native support for multimedia content via <video> and <audio> tags is one of these improvements. One of the things that aggravates me about the current talk of these tags is a controls attribute, which specifies whether to use the default or custom controls. This is an attribute with no value, which isn't XHTML compliant. I know HTML isn't XHTML, but it'd be nice if the damn standard would at least take a step in the right direction. The additional ="true" wouldn't polute the spec. Despite that, the tags look promising. With the ability to customize the UI and built-in support for common actions like play, pause, and setting the current play time, I think most people will be fairly happy. That's not it, tho, there will also be APIs to support 2D drawing, storage, offline capabilities, editing, drag & drop, messaging, and my favorite, back button management. I haven't seen much about these, but I'm very excited about storage, offline, and back button management capabilities. These are problems that plague web developers.

As for interoperability, HTML 5 will be represented by its structure, rather than syntax. The key benefit of this is that it allows better support for the two formats HTML documents support: HTML and XHTML. As I understand it, the dual support is to provide better backward compatibility support with HTML. I see this and think, "Then why the hell would I even use HTML?" Maybe it's just me, but I'd rather use the markup language that provides the most forward compatibility. XHTML also provides some integration with external XML formats. The argument for HTML seems to be all about supporting lazy designers/developers who feel burdoned by the enforced structure. To me, they just need to get over it. The lack of structure in HTML is one of the main reasons the language sucks so much and causes so many problems across browsers. You could probably liken this to the VB vs. C# wars that were kicked off 7 years ago. To me, forward compatibility is more important than backward compatibility (aka laziness ). Different strokes, I guess.

Looks like Google and Yahoo have plans to make your inbox a social networking nexxus. I have to admit I like the idea. The only problem is how to display it. Yahoo's idea is that you care more about email from your contacts than others, which is a very good one, in my opinion. Most Outlook users implement rules to add this type of functionality, which works, but has never been 100% for me. Maybe I don't know what I'm doing, tho. I guess my problem with the whole idea is the same as my problem with rules. My inbox is my todo list. If something goes in another location, I ignore it. For this reason, rules do more harm than good. In Outlook, I tend to maximize my inbox-viewing real-estate by docking and minimizing the folders and calendar/tasks toolbars to each side. I love the capability, but this comes at a cost -- namely, I can't see how many emails are in each folder or what appointments or tasks I have. Bottom line is I hope the idea spreads and Microsoft picks up on it for Windows Live and Outlook. I'm interested in what each group will come out with.

It's been a while since I've complained about version numbers, but Rocky Lhotka's  latest post about his versioning scheme for CSLA has sparked another bout. What Rocky is doing is retarded. He's dumbing down version numbers for those who fine versioning difficult. When .NET was first released, this is something I knew was coming. Look at Java, where developers deal with a dozen different frameworks and tools just to work on their project and guess what... they're all different version numbers! Hell, even the desktop and server frameworks are different. Ok, so the latter is a tad ridiculous, but the former makes complete sense. Every tool should have its own version number which accurately depicts its version. Major version numbers only change when there's a major change in the code -- typically a breaking change. Sure, this might include .NET 2.0 vs 3.0, but it doesn't have to. Don't blame Microsoft's stupid version numbers on yours. If your users don't understand proper versioning, why the hell are you listening to them!?

I still have to say .NET 3.0 isn't necessarily wrong. WPF was a major change that should've been introduced as a major upgrade. I'd say that all four parts of .NET 3.0 are major updates. The real problem I see with .NET 3.0 has nothing to do with the version number, but the lack of any other improvements, which would've further justified the version number. Honestly, I would've been fine with 2.1 or 3.0. The real butcher of a job Microsoft did on version numbers was 3.5. What the hell was that!? There were no, nor were there ever planned to be any intermediate versions. Again, I'd have been fine with 2.2 or 3.1, but 3.5 was just stupid. I had hoped this wouldn't turn out to be the next version, but no such luck.

On the lighter side of things, the big improvement for Silverlight will now be Silverlight 2.0. I imagine this had something to do with the .NET 3.x version issues. Either way, it's nice to see.

IE has supposedly blocked 900,000 phishing attempts per week within the first year of operation. With 300 million installs, that equates to one phishing attempt for every 333rd person. Granted, I probably don't know 333 people who've installed IE7, but I haven't seen one phishing attempt. We aren't the typical users, tho, so maybe others are balancing that out. Just curious what others' experiences are. I do find it funny the feature was pretty highly touted at its release, but has obviously turned out to be of minimal benefit. Maybe it's just me, tho. Don't get me wrong, 900,000 blocked attempts is definitely good. I guess I was expecting a higher percentage than .3%. I wonder what it's like for other browsers.

Update (12/14/2007): Corrected the statement about 900,000 phishing attempts in the first year; it was 900,000 per week. Thanks, Eric !

There's been a big change in Microsoft in the past five or so years. The biggest thing we've noticed is the increased transparency on key initiatives. The change isn't limited to Microsoft, tho. Weblogs have increased communication between vendors and consumers, which has been great, from a consumer standpoint. I love knowing about what's coming and feeling like I have some say in the future of my favorite apps -- albeit merely a perception and not reality in some cases. I look at the various Microsoft projects and think about how the level of transparency differs. It's kind of amazy how the Visual Studio team is so open, yet the IE team is so closed. I'm starting to think there's a pattern, tho. There seems to be a relationship between the amount of competition a product has and the level of transparency of its team.

Think about it, Visual Studio is unequalled. The closest competition is Eclipse, which is for a different platform. .NET is pretty much the same. Java's out there, but seems to be declining in popularity more and more. Sure, there are plenty other development platforms out there. .NET isn't even the most used; but I'd argue that it is the most popular and newsworthy. Anyway, the point is that, since there isn't a lot of active competition for .NET and Visual Studio, the product teams share a great deal. We have a lot info about what's coming in the next release of Visual Studio and have been seeing previews since before Visual Studio 2008 was released. How many other companies do this? Name one.

Then there's Windows. While Windows may be the most used operating system in the world, there is competition. Consumers are looking at the Mac and the corporate/government world has always kept an eye on Solaris and the various flavors of Linux. The thing I find funny is that it's never about features when discussing Solaris and Linux; at least that's the impression I get. There's obvious competition that's always on the heels of Windows, but the lead is undeniable. Given the comfortable lead, the team shares a good amount. Of course, with the issues Vista had, I expect we'll see slightly less transparency this go-round. We should see a list of features and plenty of CTPs, but not quite what the VS team does.

IE has a lot of competition. The browser market has almost always been a heated battle. IE's losing market share because of the stagnation of IE6, but finally made a comeback with IE7. The market has changed, tho, thanks to Firefox. Opera has always been out there, but never made too significant of an impression. That's too bad, because I think the Opera team does have something to show. The truth is, all browsers are lacking innovation. When's the last time we saw something new? Anyway, I think this heavy competition is why we haven't seen anything from the IE team. I think they have something up their sleeve -- something truly innovative. Maybe it's just wishful thinking, tho. I'm sure we'll see CTPs and/or betas, but not quite as much as with Windows. Zune is another product in this area; perhaps even more so than IE.

The relationship between competition and transparency makes a lot of sense, when you think about it; especially in the corporate world, where money's at stake. I just wish everyone would share insight into their goings-on.

I've always wanted to tech-out my house. Part of that is setting up a nice DVR system which is remotely available. Windows Media Center has always been there, but I just haven't delved into it, yet. Once Windows Home Server hit the scene, this just gave me more to look at. Channel 10 is running a series of videos on how some of us geeks use technology outside the office. These are always nice, because they expose you to things you probably don't know about or haven't seen in action. The latest of the series went over Steve Lindsay's setup. This is exactly what I'm wanting to setup: Media Center and Home Server with web and mobile access. If you're into this kind of thing, you'll probably want to check out Jeff Sandquist's  setup, too.

For the first time, the IE team  has released tidbits on the next release of the popular web browser. What's the news? The version number. You've gotta be kidding me, right!? I think we've all been calling the damn thing IE8 for quite some time. The fact that the team went out of their way to tell us it'll be called IE8 is somewhat ridiculous. Get over yourself, people, you're not that creative. The post was somewhat reminiscent of... naw... the damn post was a rip-off of the Silverlight team, where Tim Sneath  listed other possible names for the product. That post was pretty funny and I'd suggest checking it out, if you haven't already.This just annoys me. It's even worse than the astounding announcement that Steve Jobs will have the opening keynote at MacWorld 2008. Freakin' morons...

Here's an interesting comparison of the user interfaces for Mac and Windows over the past ~13 years. I found it somewhat interesting, so I put a little more effort to see which ones came out first, hence the timeline below the UI comparison...

In the timeline, I marked the significant releases in red. This is just my opinion, of course, and others may think otherwise. The first thing I have to say is they should've included Windows 3.x, which is fairly similar to MacOS 7. Also, I want to say MacOS 7 is relatively similar to previous releases, visually, but I'm not 100% sure. Aside from that, if you compare it to the above UI comparison, you notice that Apple did a good job of pumping out releases fairly quickly, but Microsoft beat them to the market with Windows 3.0. Windows 3.1 was the release that really caught on, tho. Of course, the big story was Windows 95. I want to say Windows 95 had the largest release in the history of personal computers. The 7 year stagnation between MacOS 7 and 8 is probably the worst thing Apple could've done. I don't know about the promises at the time, but this was worse than the Vista release! Beyond that, MacOS 8 wasn't even much of an improvement. In my mind, Windows 95 leap-frogged MacOS, who wouldn't come close to catching up until 5.5 years later, with MacOS X. To say that another way, Apple couldn't beat Microsoft until they dropped their main code-base and started with Unix. I think that says a lot about the quality of Apple's code. Ok, maybe that's a low blow, but whatever. 9 months later, Microsoft released Windows XP, which gave Windows a bubbly/cartoony UI... which I have always hated. Finally, Windows Vista hits the streets in 2006 with a lot of big improvements, arguably the biggest upgrade since Windows 95. Of course, with such a huge market behind Windows, Microsoft can't survive without its vendors, which is the biggest reason Vista isn't on every desktop... well, the Windows users' desktops, at least. Lastly, the next incremental release of MacOS X was released last month. "Leopard" has a few very nice features, but isn't really a huge upgrade. Honestly, since MacOS X, Mac users haven't seen any big changes. So, we're coming up on 7 years since the last major Mac upgrade. Don't you think it's about time we see something big? Don't expect it, tho. I'd put my money on the next version of Windows coming out before a major upgrade to MacOS. Of course, Windows "7" may not be as big as I was hoping. Those changes may be reserved for the Windows 8.0 release, which I'd guess would be around 2012. Man... that's forever!

A few weeks ago, Mix 08 was announced. I started to check it out and contemplate how much I wanted to attend, since I missed the first one and decided to skip the last one and go to PDC instead... which was cancelled *grumble, grumble* Well, I'm not making that mistake this year. However, another conference I have an interest in attending just popped up: SD West 2008. At first, I was thinking how nice it'd be to check out both. Mix started out being a web developer conference, but has become more about user experience, which I have a great deal of interest in. SD West is an architecture forum. Unfortunately, I just found out they're both happening the same week. Decisions, decisions...

Given the fact that Mix has slightly moved away from the more technical developer content, I think I might opt for SD West. Of course, SD West has more non-Microsoft content I may not be interested in. I'd be lying if I said location doesn't matter. Mix is in Vegas, which is definitely fun; but SD West is in Santa Clara, which would be a first. I've been to San Fancisco, but that was quite a while ago. I'd like to get some feedback from someone who's been to both, but I guess I'll have to take a deeper look at the content of each to see which one would be more valuable.