Week in Seattle - Tech

I sent out an email a couple nights ago to refer some people to this blog. In the email, I mentioned that it was an inspirational trip. Since then, I have received TONS (ok, just 3) requests to elaborate on what was so inspirational. I'm not sure if that's because people are genuinely curious, or because I misspelled "inspirational" and they wanted to taunt me by repeating it. Either way, here we go.

The trip to Microsoft was basically 3 days of "Here's all of the cool stuff we're working on". And they're right... it's cool. It covered the upcoming Visual Studio Orcas and .NET 3.5.

From the agenda, here are the topics covered
Tuesday
- Kick off
- Setting the stage for Orcas
- Intro to Syndication
- Using WF rules
- What's new in Orcas / Linq
- Intro to ASP.NET AJAX
- VSTS in Orcaas and Beyond

Wednesday
- Using PowerShell to manage WF & WCF
- JSON and AJAX with WCF
- Workflow Driven User INterface
- Workflow Enabled Services
- Durable Services


Thursday
- WF Performance
- VSTO in Orcas
- Federated Identity for Devs
- .NET Compact Framework 3.5
- Intro to WMI and Eventing in Orcas
- ADO.NET entity framework
- WCF Performance

As you can see, they gave overviews of a lot of stuff.

When I first started my career, I went to training a few times. These were always good for exposure to new technologies that I hadn't yet come across (because I was just starting), but they weren't much more than that. The instructors just read the materials and facilitated the labs. In most cases, they didn't know much about beyond the course contents.

The Microsoft presentations were the exact opposite. They had some slides and supporting materials, but they most certainly were not reading a script. These are the people who actually designed and wrote the software. The guys (sidebar: for the purposes of this rant, "guys" is synonmous with "people") who created WCF talked about WCF and answered our questions about it. How great is that? Additionaly, they're just regular people (albeit, smarter than most). They weren't Microsoft marketing guys. They showed up in jeans and sneakers, ate lunch with us, and simply talked without preaching. They were trying to sell something, obviously, but they were selling it on merit, not on flash. They were selling the stuff they work on every day. (Actually, a lot of the technology is free, so "sell" is really "convince us to use". I don't need convincing.)

The 3 days revealed 2 things about myself:
1 - I couldn't get up there and do a professional presentation like that. I have enough skills in areas that I can speak intelligently about, but I wouldn't be composed about it. Things like this were recently described to me as "soft skills". Sure, I can code, but I probably shouldn't be allowed to talk to clients.
2 - None of my skills are laser-focused on a particular technology. I know a lot of things about a lot of things, but I don't know everything about anything. I have recognized this previously and planned to act on it, but never did. In fact, when WCF was still called Indigo, I had every intention of becoming intimately familiar with it. Instead, I continued working on all of the same projects using all of the same skills.

Since I started programming professionaly, 2 things have blown up on me, and unfortunately, both of them were recently. The first one was a big deal. I rewrote a component that sends messages to one of our external clients. I wrote the original component so was more than capable of writing the upgraded component. It passed rigorous testing and was promoted to production. There, it promptly failed every few messages. The key difference between the old and new was WebClient vs WebRequest. I tried to recreate the scenario locally by running tens of thousands of automated tests, and could not get it to occur. Unfortunately, the client was not helpful. We needed to know what was happening on their side so that we could isolate where it was going wrong, but they wouldn't help. After hours of debate, I rewrote the component again using WebClient. Everything started working. A friend of mine strongly suggested many times that we go back to WebClient, but I didn't want to surrender. It was a fixable problem, but eventually, I had to give in. WebClient uses WebRequest, so it should have worked. We simply needed to know what was happening on the client side so we could adjust whatever properties needed to be adjusted. (Incidentally, that same webrequest object was used for all other clients as well. It only failed for this one, so it was not a fundamental problem with the component). I lost 2 days of sleep on it and felt absolutely miserable about it. I designed and built the entire messaging system for the enterprise, and that was the only thing to go wrong in 2 years. (That is, aside from occasional bugs and mishaps, etc. Unfortunately, I am mortal (unconfirmed) and do make errors.)

The second time was at my new company, and wasn't as bad. This time, I had to implement a remoting solution. Though I had a lot of messaging experience, it was via sonic and, to a lesser extent, web services. I hadn't actully done anything with remoting. I didn't have long to gear up and get the first version in place.

As before, everything worked well in development and testing. There was another remoting service running in the same app domain. I was aware of that, and took it into consideration. However, once it went to QA, it started failing. This was due to conflicts with the other service which, as I already said, I accounted for, so it shouldn't have been a problem. (I was expecting a particular issue under a particular circumstance. That was on the to-do list, but this wasn't it.) Fortunately, I was able to quickly identify the issue , but coming up with a fix was a different story. I recreated the issue using NUnit, then hit Google hard. The problem was never resolved. I had to settle for a workaround.

It occurrs when there are 2 channels in one app domain, but they differe either by security or serialization format. If the first one is secure, then the second one is secure. If the first one is not secure, then the second one may be secure without causing a problem. If one is using XML serialization then they both must, and the same for BINARY. I took comfort in recognizing that the existing remoting service had the same problem. It's not something that I introduced, I just happened to be the second service. This remains unresolved, but I made a personal commitment to get a better handle on these things. Prior to it failing, I only had about 18 hours invested, so I only lost 1 night of sleep this time. Additionaly, it's not a production ready application, so I didn't break existing functionality. (For those of you taking notes, the work-around was to make sure both channels were setup the same: same security, same serialization)
Both of the issues above were communication related. The first was via web services (sort of), and the second via remoting. Prior to that, I spent a lot of time doing messaging and SOA. I learned a lot of stuff over the last few years, but it's apparent that I'm not a guru. I could probably claim an expert on some of the stuff, but not guru.

And at long last I come to the point. I would like to become a WCF guru. I think I have a strong handle on SOA concepts and how things should be done. I may be proven wrong on that, but until I have evidence to the contrary, I'm going to proceed as if I know what I'm talking about. Now I need to improve on the implementation of those concepts, and all roads lead to WCF. I'm not going to worry about the remoting problem anymore, at least not for a while. Remoting is old news. I want to focus on WCF so that when I implement a WCF solution I don't have to wonder if it's going to backfire in QA or production. I need to keep my other skills up to date, but my primary focus will be WCF. I will continue my existing side projects and use WCF where feasible. For new projects, WCF will be in there from the get-go. It'll be fun, and I will make every effort to achieve guru status.

To address the first problem: Subpar soft skills. In this case, that may just be the way it is. Everyone has their pros and cons. I think they are at least average which, in this case, is good enough for me. We can't all be public speakers and power point experts.