.NET at 9.400 ft above sea level

It wasn't sure until the last minute but now I'm positive I'll be at TechEd 2004. All I'll have to do (besides surviving the trip) is to spent some time at Cabana 5 & 6, so if you want to chat about the ins and outs of developing with .NET do come along (but please don't bring hard questions, who wants to work hard in San Diego?)

Perhaps because I did real distributed computing with Java in the first place, I like to tinker low-level (but not too much low-level). Perhaps, that's why I use Remoting a lot. Oh yes, I know Indigo is coming and I know web services is the thing for SOA (according to our high priests, anyway). But Indigo is 2006 and, unfortunately back to the real world, I have to write systems in 2004. In this year, I (tend to) use web services if I have to talk with other platforms but I (tend to) use remoting if I need to separate .NET front-ends from .NET business logic. And I just love the sink architecture of remoting: one of my early successes was to *copy* Ingo Rammer sink for zipping messages and making an application ten times faster without changing the server or the client code (oh boy, the guys in that company still think I'm a genius). And now, through the TheServerSide.Net I come acquainted with a remoting sink for probing remoting conversations (as you can see, I'm also fond of recursion). Isn't sinking cool?

I've been visiting Panamá for almost two months now (alas, a really nice place to visit). During this time we've started the .NET User Group here. We used DotNetNuke to create the portal, and it has proved to be an amazing piece of software (for being free and, even more so, running flawlessly in really unexpensive hosts). But we had to set up the site in Spanish, so we had two localize DNN: it took a couple of nights to understand the inner workings of DNN and a couple more to translate 90% of the labels and messages. A lot of the text was in database tables already but we had text scattered through the code, the user controls and the pages. In the end, the localization process was not a big deal but it still required the source code and some good expertise in ASP.NET. As I said, DNN is an amazingly good product but one item below average is its discussions module, so we started to hunt for a third party module (it's a tribute to DNN popularity the fact that there's a market for 3rd party modules and site development), we found a couple of interesting options like YAF which is OSS and ActiveForums which is commercial (but you can buy the code) but again no easy localization. Come to think of it, of the growing number of OSS .NET projects, most of them only target the English language with i18n going from poor to non-existant. Message to Microsoft: tell the thriving .NET OSS community to start thinking multicultural.

Our web site hosting is about to expire so we started to search for a new provider. Nothing particularly wrong with the current one, but we want a host that is more focused on .NET, particularly we want ASP.NET 1.1 support (including as much components as possible) and SQL Server 2000, Win2k3 being a big nice-to-have. It so happens that there's a raft of offerings (which says a lot about the growing popularity of ASP.NET) but the market options and twists are as confusing as ever (I feel pity for non-technical people trying to choose a host). We finally settled on one provider and a runner-up. As we had some problems with our credit card payment with the winner (we are in Ecuador and weekend financial transactions can be tricky) we set up an account with the runner-up KarmaaHost. But, finally our original transaction went through so we ended up with *two* hosting sites! We quickly mailed KarmaaHost to cancel the order (which was already paid and set up) and they promptly followed our instructions. So we had very little chance to experience Karmaa hosting but I can say that their customer service is superb.

The bigger the project the more the devil is in the details: how you handle exceptions, how you log errors, how you setup your VSS connection, etc., etc. There are dozens (several dozens) of small conventions that a team must follow and many times people don't follow these conventions simply because they don't know about them or because it's 3 AM and go figure in which lost manual is the standard for connecting to a SMTP server (*if* such a standard exists for our project) so we just fire up or own solution (or, if we are clever, cut&paste and example from MSDN) and there goes the standard, that's one of the many beginnings of the end of the normalization.

I have to admit I am a solo programmer: as a lot of my coding is trial-and-error I don't really like people watching me make mistakes or mumbling :-) More on the practical side, I think it is more efective if once the code is working *and* polished I explain the what's, why's and how's (something, ahem, I'm good at, ahem). But, as a consultant, many times I have to help my customers with their coding chores. Currently, for example, I'm helping a very experienced team to get up to speed with .NET distributed development. First all, we defined our architecture (security, layers, logging, etc., etc.) and then we prioritized the use cases. What is left to do every day now is to select a task, we discuss our options, do some drawings, and start to program (somebody from the team and me). I have to admit that I take the keyboard kind of reluctantly (remember my first line) but most of the times it works pretty well: after some stumbling, the job gets done; furthermore and to my amazement, my fellow programmer finds the experience *enlightning*, which to me is kind of funny (remember, these are pretty smart and skillful people, it only happens that they don't know .NET). As I said, given the choice I'd rather programmer alone and explain what I did later but if I am forced to do pair programming I have to admit the technique works really well.

My brother Alex is one hell of a business apps developer. He's been for years using C/S tools and just a few months ago I convinced him of using ASP.NET, after some reticence he started to program in the .NET platform and it amazes me the various (somewhat small but certainly real life) apps he has crafted in this short period. Yet, Alex being mostly an alien to our O-O, XML, etc. hoopla, there is a number of things he hasn't been acquainted with. Last week, a customer asked Alex to create a tool that helped the customer salespeople to create proposals with Excel, mostly, the salesman didn't want to switch from Excel to a green terminal window to check product prices and stocks, I talked Alex about the Office 2003 Research Services and he (reluctantly again) agreed to give it a try, so we used the best part of yesterday and today afternoons discussing the architecture of the research pane (he knows a little about web services but nothing about XML) and then creating a couple of research services that do most of what his customer wants, Alex is impressed and even I am impressed with what we accomplished: it looks like we worked far longer than what we actually did. One point to note though, the Research Services SDK is indispensable to do this kind of job but it is somewhat awkward to use for me, moreover, it was completely irritating for Alex (who's a talented programmer who just doesn't know XML), besides creating the long XML response document is tedious: one could use a higher order API. All in all, my bro is starting to like Office 2003 and web services but still don't get what's the fuss about XML.

As many of you probably now, Shadowfax is (or will be) an application block for writing distributed application around remoting, web services, Biztalk, etc. Just a couple of days ago a new alpha release was uploaded to gotdotnet and, as most of my consulting time nowadays goes around distributed applications in .NET, I have no other option than downloading Shadowfax and checking what Ron Jacobs and his mates are doing. Now, I really won't sleep this weekend!