The .NET Sweatshop

Working day and night to help .NET users get the most out of programming the coolest platform on the planet.

Wednesday, November 26, 2003

An update on my ink-thinking code--it didn't win. Alas, there were a lot of submissions and many were very cool, although I don't think they were all really useful as much as they were nifty displays of technology and programming. I know, I know--sour grapes, right? Actually, I think it brings up an interesting point. I like bringing up Alan Cooper (Father of VB) a lot because I think he has some pretty good insight on what technology should be and what technology shouldn't be. The fact that the book I am reading from him is called "Inmates Are Running The Asulym" (or something like that--I don't recall the exact title) says it all. Technologists make things unnecessarily complex at times. He used his digital camera as an example. It gets more and more powerful, but your ability to operate basic functions gets lost as a result and we, as consumers, accept that as the price to pay for progress. It's a little bit like the theory of worker producitivity skyrocketing and yet people are working more hours per work than ever before. Something just doesn't fit. Anyway, let's take my app, for example. Nothing special. It's a utility you open from Internet Explorer that gives full access to mark up a website with your pen and save the annotated page to disk or even e-mail it to a friend. You can turn any web page into your own editorial playground with a quick click of a button. Say you are surfing the web when you spot a site that has an interesting set of material (pictures, text, etc.) that you want to tell a friend about. So you send the link and then spend 10 minutes trying to describe to your friend what you found so interesting about the site. Wouldn’t it be better and faster to tell him with ink? With my app, you can draw landmarks on maps, scribble notes on articles, or even draw funny goatees on political leaders and then, with a click, send it to your friend through Microsoft Outlook, reminding everyone that a little ink is worth a thousand words. I've used this thing will several work and non-work related projects. I'll be the first to admit that the code is NOT incredibly complex and my problems were contained in the automation of the IE button to trigger the app, the app to access the open web page, and then interfacing with Outlook as the mail client to send the attachment. Lots o' COM Interop, but a pretty clean app nevertheless. Now I can't think of anyone who couldn't use this app. The other apps were cool, but some were games and others were ways to do things with ink that you could do just fine without ink. Technology rears its ugly head. The Tablet PC will never get its niche until you prove it can do something markedly better than a notebook. I said this in an earlier blog, but it bears repeating. To me, that's the secret to merging technology & business. It's why the internet, e-mail, word processing, and spreadsheets were all revolutionary. The internet blewaway microfiches, e-mail made faxing look inefficient and wasteful, word processing made typewriters look like clumsy inflexible machines, and spreadsheets sent calculators to the museums where they could hang out with abacuses as forgotten tools of the past. The Tablet can do that to notebooks, but we need to stress what consumers can do differently or much better than they can already do. Sure, we can look to invent new tasks for people, but new tasks won't sell new products. Making old tasks arcane in favor of the new tasks--now that's your better mousetrap. Yet another techie MBA rant, I suppose. But whether I do it here or I go off and start my own company, you can bet this is where I plan to focus my efforts...

Wednesday, November 19, 2003

I have a weird job. I work at the world's largest software company, but my group doesn't necessarily create software (sometimes we do, sometimes we don't). In some ways, I feel like a book/web publisher. Yet my job requires a higher technical acumen than the average MBA or even the average EE-turned-MBA. Sometimes, the stuff we create is as complex as the stuff that goes into the product. As a result, I need to not only be well-versed on our releases, but also drive into other sources of content. I need to get my hands dirty every now and then just to get a sense of what the customer is feeling as well as satisfy my intellectual curiosity. I tell most people that I read anywhere between 20-25K pages of technical content in 2002. 2003 saw me cut back a little (I felt like the foundation was well-laid), but I do manage to crack open a title or two. My latest is .NET Web Services: Architecture and Implementation with .NET by Keith Ballinger. Keith works for Microsoft and I know he's got his act together regarding web services, WSE, and everything in between. When I got the book, I was a little disappointed at what seemed to be a thin book, at least my technical standards (300 pages). However, I have to admit that it was a pretty good book. It filled a lot of holes in my knowledge of web services, told me a lot of what I always wanted to know about web services but was afraid to ask, and gave me a solid taxonomy of terms that makes it easier to communicate about web services. The debates of "Document vs. RPC" and "Encoded vs. Literal" that were discussed in the WS-I meetings now have better general context to me. We cover this in the WS-I Base Profile guidance we deliver, but this is the uber-primer. I'm not trying to be Oprah here and start a book club, but it's definitely worth a look if you don't feel confident about your knowledge of web services. For me, it also helped because it went under the hood of Visual Studio and the massive automation that occurs when creating or subscribing to a web service. Don't get me wrong, I love the automation. Still, it's important to understand what's going on (just like it's nice to know how your car works inside even if all you do is us the gas, brake, and steering wheel). So, highly recommended. Another book I am in the middle of is Chris Sells' book on WinForms--but that's a blog entry for another time. OK, maybe I am going the Oprah route. Given the size of her empire, I could do worse. :>

Wednesday, November 12, 2003

I was talking with someone regarding code access security (CAS) the other day. If you've never heard of it or always wondered what it was but were afraid to ask, CAS is a security model in .NET that selectively restricts system resources that code can access and the types of privileged operation that the code can perform. It ignores the user who calls the code in favor of the credentials of the code itself. This Cperson I was speaking to was a CAS naysayer who seemed to feel that it was just too hard to administer and the performance hit was too much. However, I don't think that is necessarily smart thinking. Granted, the configuring each .NET assembly individually could be insane as assemblies proliferate. But if you use "Code Groups" (think .NET Roles/"Trusted Subsystems" for assemblies instead of users) to define certain consistent permissions, you can scale your administrative ability. The assembly operates under the permissions granted to the group by you (the administrator) and only you can create groups and adjust permissions. Just like managing inidividual identities in SQL, it doesn't have to be a nightmare. Meanwhile, the performance is something I see getting better in the future and I don't believe it is prohibitive now, either.

So, big deal. Maybe it is easier than thought. Maybe it isn't too slow and will likely get better. Why is this important? The low opinion of CAS isn't unique--I've heard a lot of people say it. Sometimes, I think part of the problem is that people don't quite understand the intent behind it. Once upon a time, all software came on floppy disks and users knew everything going on their system. But things are changing. CAS is extremely useful because of all the code installed over the Internet nowadays and how often users don't know when the downloaded code is safe. Worms & viruses are the bane of Microsoft's existence and any measure to stop them from doing their damage has to be considered. CAS can, among other things, protect the user from himself by treating the code the way Windows treats AD permissions for user access to files and other resources. After all, just like users, not all code is created equal. The analogy holds in a lot of ways. For example, strong naming assemblies is the equivalent of an assembly's user name and password. All of this reinfornces the principle of least priveleges and relates it to code to (a) protect users from themselves and (b) recognizing that the current state of software has a lot of software calling other software with no user interaction. The latter point is getting continually more significant as time goes on. Given the importance of messaging in service-oriented architecture and how we are trying to reduce human interaction, code will need to open itself up more and more. It is imperative that architects and developers start thinking about the code accessing their applications just as much as the user running the code--especially if there is not user. Not to sound like the marketing machine that I am, but .NET is incredibly forward-thinking and, like it's approach with XML and web services, it's work with CAS is a technology that I see being extremely important for the future of software development. Give it some thought and check out the chapters in Improving Web App Security that covers it. I think it does a much better job than I do explaining what it is and how to use it...

Chapter 8 + Chapter 9

Tuesday, November 04, 2003

So the biggest developer party of the year is finally over and my hangover isn’t too bad. I’m not talking about the alcohol—after all, who had time to drink? (OK, I did a little, but never on the job). No, I’m talking about the hangover from the exhausting process of envisioning our strategy for PDC and then executing on the plan for getting patterns & practices as visible as possible at an event that focused on future technologies (not exactly our forte). PDC has been on our agenda for three months and we did a lot of work to prepare for it. As the event drew closer, we continually ratcheted up the effort until T-minus 0 when it was showtime. Despite California wildfires and some technical glitches, I am pleased to say it was wildly successful for patterns & practices, just as it was for Microsoft. I thought I’d recap it for all of you…

Of course, we had guidance built specifically to release for the event. We worked closely with the Longhorn Evangelism Team and the Dev Div to create the “The Developer’s Guide to Interoperability and Migration for ‘Longhorn’” as the first release in the “Emerging Practices” series of guidance for pre-release products. The guide was released as part of the launch of the MSDN Longhorn Developer Center last Monday. You can see it at:

For the event itself, five of us made it down to Los Angeles. Jim Newkirk, Mike Kropp, Ron Jacobs, Wojtek Kozaczynski, and myself each spent many hours at pavilion booth fielding questions (and compliments) regarding the entire library of guidance. As booth captain, I personally spent 19+ hours on my feet across the three days and got away from the booth for a total of 20 minutes. My feet were literally bleeding and yet I think I speak for all of us when I say it was definitely worth it. We talked with hundreds of enterprise developers from all industries. They were given copies of “Application Architecture for .NET” as well as the November patterns & practices CD and many of them were anxious to share their experiences using patterns & practices in their production environments. Meanwhile, two Regional Directors ran evening “Birds of a Feather” sessions around patterns & practices. Despite wanting to just go back to the hotel and sleep, we all volunteered to attend both sessions to lend our support. To close out the event, 800 copies of Improving Web Application Security were issued to attendees of the Security Symposium on Thursday as the essential reference to reinforce secure coding principles and methodologies. From beginning to end, we were in the thick of things. Not too bad for a Gang of Thirty (or GoT, as I like to think of us). And the effects of this stuff will linger long after. More Emerging Practices, our revamped web-site, and our brand new store on at (yes, we are pushing that "practices" v-root wherever we go. :>) But fortunately, our event calendar will finally ease up for awhile. That's great--I need the rest!