The .NET Sweatshop

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

Sunday, October 15, 2006


In addition to the new .NET Sweatshop, I am also blogging on non-MS topics on my new site "sandmansays.com" (instead of "Simon Says"). It's my way of sharing observations of my career in the software industry, particularly the last five since I graduated from b-school. I realized that my philosophical blog entries are probably better suited for a different place than anything that is MS-focused. Hope you like it...

http://softwaremba.sandmansays.com/


Wednesday, April 07, 2004


In case you still come here to look for my blog, I've moved to MSDN and I am blogging there. The link is at:

http://blogs.msdn.com/sandyk


Thursday, February 12, 2004


We've been getting a lot of feedback lately about the simplicity of our blocks (or lack thereof). The Data Access application block (DAAB) has been a hit, but some people (myself included) think that while it was cool, the scope was small enough to limit the impact it's had on my coding behavior. But that's the beauty of it for most people. Two classes (one a supporting class, really) and a small series of straightforward methods. You can never look at the CHM file and have great success with the DAAB. The Exception Management block offered more flexibility and configurability and that made lots of people happy, but some were confused by the options. "Just tell me what to do--I don't need options" is what one person once told me. And then there's UIP + Asynch Invocation. Both would be hugely useful if people could understand them. We recently did a webcast on UIP and the turnout doubled the the turnout of all the other webcasts we've had--mostly people who really wanted to functionality and were trying to make heads or tails of it. So what's the solution? Is the the DAAB's simplicity, the EMAB's flexibility, or UIP's thoroughness? I lean toward EMAB myself, but I think we are always going to do what we think the situation calls for. While I will advocate erring on the side of simplicity, I don't think UIP could have been as simple as the DAAB and still have been useful. But that doesn't mean that more easily consummable classes and improved QuickStarts can't help save the day. There's your real solution--keep it useful but give them the clear on-ramp. That's the QuickStart dream. Now we just have to give the Quick Start a new name so that all the baggage associated with it goes away...


Wednesday, February 04, 2004


Several weeks ago, I did another webcast--this time as a "guest appearance" with Ron Jacobs. Yes, my life has been reduced to a series of cameos in our webcasts. As the speakers get better, I step back and just orchestrate. Still, I like to participate and I've got no problem playing second banana. Ron was doing his presentation on Shadowfax, the upcoming reference architecture from PAG. This has the potential to be wicked cool. It's a long time in coming from us (we've been meaning to do one of these for years) and has the potential to be something extremely useful for customers. But, of course, the big three letters come out to play on this one: S-O-A. Aaah!!! Hide the children!!! I tend to think SOA is a little like community--everybody's got an opinion on what it means and what it entails. I think many people believe MSFT's message is that everything in the world should be a web service. Well, what would be so wrong about that. :) OK, that might be a LITTLE unrealistic. Still, implementing an SOA does not require web services, SOAP, WSDL, or any other four-letter acronym (nice to see we've evolved from TLAs). To really have an opinion on what SOA is, you need to know what a service is in the context of SOA (i.e., what are we "orienting" on?). I like Andrew Layman's description of a service best. In Keith Ballinger's book (I swear I am not trying to shill for that book, but it does come in handy) ".NET Web Services", he described a web service as "application logic that is accessible through Internet standards". I like that definition. Notice that it doesn't mean only the XML/SOAP/WSDL/UDDI stack. However, if you want maximum flexibility for the long-term, it's hard to beat XML. It's this eternal battle for programmers between not wanting to ditch old apps (the "if it ain't broke" syndrome) vs. wanting to embrace the future (the "bells & whistles" syndrome). I remember someone asking me if web services was the next CORBA--great intentions, good implementation, and doomed to failure due to incompatability and lack of vendor support & standardization. I'd like to think efforts like WS-I are built to avoid that. That's why Shadowfax is built to support multiple communications mechanisms. Web Services are still the best method for many (most?) cases, but if you want to stay away from the XML, we got your back. Service-Oriented Architectures without web services? What'll they think of next?


Wednesday, January 28, 2004


If there’s one constant complaint that I get about my blog (OK there may be more than one complaint that I get about my blog, so maybe it’s the biggest complaint), it is that I do not have an RSS Feed. And unfortunately, Blogspot is still not supporting RSS or else I have not have not figured out how to use it. So what’s a good ex-developer to do (besides switch and incur the switching costs)? Write my own code to create the RSS, of course. This actually fits with some side work that I have been doing for PAG to create a feed of patterns & practices of material, so I figured I'd start with that and then my own blog could leverage this work. But I noticed something very interesting as I was writing the code: most RSS feeds are static. I guess that makes sense because it may seem like overkill to build a web application which gives the same data to everyone all day long. However, wouldn’t it be nice to filter the content of an RSS feed or merge them into a way that works for you? I noticed Yahoo has about fourteen different feeds for each different type of news. I can get a little crazy to manage all those feeds and seeing that they’re all coming from Yahoo. My goal was to create a feed that will give you all the sub feeds based on the query string that you passed in to the ASP.NET application. But certainly there is SOME code to start with, right? When I did a search for code to steal, er borrow, to start off my work, I didn’t find any RSS generating code. I’m sure it’s there, but Google wasn’t helping. So, I went at it on my own. I built a small SQL DB and wrote a web service to create CRUD access to it. I developed an Infopath form to let team members submit items for future use (I’ve been dying to do something useful with InfoPath, so this was pretty cool). I created a serializable class that had the same structure as the RSS schema to let .NET do most of the XMLing for me. I then wrote the ASP.NET app to parse the feed for what you need. If no query string is sent, you get the whole Magilla (blocks, guides, webcasts, news, workspaces—man, we do a lot). But when you send a Query String with the letters B and G (so it’d be http://website/page.aspx?filter=BG) , all you get are blocks and guides. If you used the URL http://website/page.aspx?filter=B, all you’d get were blocks. Given we have over 100 things in the database and are constantly adding to it, I think people would like to limit the content they hear about and I think I’d like nothing less than to manage a half-dozen feeds. I just don’t have that kinda time. The code is obviously not that complicated, but I’m so proud of the ability to use one database and one URL and let the ASP.NET application do the busy work instead of me as the dev or my audience as the user. I guess that’s today’s moral, isn’t it? Let your code do the work so that you and your users don’t have to.


Wednesday, January 21, 2004


OK, I haven't stood on a soap box for a while, so what better time than in January when all things are anew. My latest thoughts revolve around the future of Microsoft and how I hope they evolve in their relationship with customers. Having worked at Intel, there's no law that is more near and dear to my heart than Moore’s Law. It has revolutionized the computing industry by constantly increasing processing capacity. The power of enormous mainframes of yesteryear can now be provided by an average laptop. Yet, as hardware performance has increased, the reliability of these systems has decreased. For years, an alarming trend developed where the gain in processing power was countered by the loss of reliability due to the increasing complexity of the software. System crashes are withstood for the sake of accepting this complexity. Internet connectivity has only made this challenge worse. Windows XP marked a huge turn for the better and Microsoft had begun to buck the trend of increasing unreliability. However, with the proliferation of viruses and worms, PCs are still susceptible to more today than at any other time. While Microsoft adopted the Trustworthy Computing initiative two years ago, people still remain at risk and security has become the bane of Microsoft’s existence. According to CNet, Trend Micro, the world's third-largest antivirus software maker, said that computer virus attacks cost global businesses an estimated $55 billion in damages in 2003, a sum that is expected to increase this year. We can sing and dance about enhanced video, audio, etc. , but until it’s safe to go back into the water, Windows will remain threatened by Linux and OS X. But Microsoft knows this and they are spending millions to correct the problem. So everything is hunky-dory, right? Well, not exactly. It's partly an education issue and partly a usability issue. Someone I respect greatly made a comment that our security content shouldn't teach people why something happened, just how to fix their problem. The analogy was that someone who's car needs oil doesn't necessarily want to know what the mechanic needs to do--he just wants it done. I agree to an extent, but as a vehicular idiot, I must confess that I don't appreciate the need for oil changes and I am a little leery of mechanics that work on my car. After all, what else are they doing to my car? What I don't know CAN hurt me--I think most people believe that and as long as they do, it helps to navigate your way around the PC a little bit. After all, people who understand their cars have better driving experiences and people who understand their PCs have better computing experiences. It also makes for a more loyal customer. The more knowledgeable you are about an OS, the less you become about another--witness my feeble attempts to navigate around my wife's grandmother's iMac. And if you think I was bad, you should have seen her. Not to compare a stupid PC virus to cancer, but reading Lance Armstrong's biography, I couldn't help but marvel at the research he did to understand his illness. His self-education was vital to understanding not only what happened to him, but also what was going to happen to him, and how he could best approach the problem. He could've simply said "Doc, just do whatever it takes to make me better." but informed decisions likely saved his life. Like I said, cancer is a world away from a PC virus, but the high-level principle is the same--the more you know, the better off you will be. I'm not saying users should be expected to study the intricacies of the PC, but "knowledge is power". Here's hoping Microsoft makes an effort to teach rather than just fix--maybe then, we can stay out of this constant "react" mode...


Wednesday, January 14, 2004


As you've probably heard, the Middleware Company launched the Serverside.NET (http://theserverside.net/) yesterday as a sister site to the Serverside.com. For those of you who are not familiar with Serverside.com, it is one of the most successful on-line J2EE community sites. We worked with Middleware a year ago on a completely unrelated project and I always thought of them as really bright guys. When they mentioned they were thinking about TSS.NET, I was really excited and committed to help them in any way possible. So, with the site up and running, we have commited to providing them with unique patterns & practices-related content that they can feature on their site. To kick off their site launch, preview chapters of our upcoming Perf & Scale guide are headlining the brand-new Serverside.NET site. In the future, we will provide them with materials that don’t necessarily fit on MSDN, like beta materials, case studies, interviews, etc. I'm hoping this will increase our exposure to J2EE developers and architects that likely have never heard of patterns & practices. I think our content can really help change people's perceptions of Microsoft in the enterprise. Plus, Middleware’s tremendous ability to generate a thriving community will make this a great new channel for getting more substantive early feedback from a broader audience than we have in the past. In other words, our stuff will get even tighter. I think this is a great step for .NET as a whole and I suggest you keep watching for more great material from PAG on the Serverside.


Wednesday, January 07, 2004


OK so I took some time off from my blog over the last couple of weeks for the holidays. It was a refreshing time to go down to California and enjoy a little sun. Of course, any weather is better than Seattle this time of year. I keep mumbling the mantra “think of July, think of July”. Given that it is now 2004, I’m gonna fall into that same routine that everybody else does in January and look back on the year gone by. Certainly it was an exciting year for Microsoft and patterns & practices. For Microsoft, we introduced Windows Server 2003 and Visual Studio 2003, my trusty Tablet PC, and don’t forget about Outlook 2003, part of the wonderful office 2003 suite. No it’s not a sales pitch ladies and gentlemen but if you do not have Outlook 2003, you are sincerely missing out. I’m even using the speech function of Microsoft work right now to actually make out this blog. Can't beat that, although I think I sometimes feel more comfortable typing rather than speaking sometimes. Alas, I am a child of the PC generation.

As for patterns & practices, we released another set of blocks as well as several pieces of guidance on security, operations, patterns, the whole gamut. I feel like this year we’re really hit a critical mass in the size of our library and I’m looking forward to what 2004 will bring. I think some of my favorite moments happened in Los Angeles during the PDC. I know I already raved about it in my blog previously, but it was so great it’s worth repeating. That memory of the effusive customer response to our content is what helps me get through the rough days where this job gets a little tiring. Thanks to all who were there and I hope to see you at TechEd.

Before I sign off and get ready for a real blog entry next week, since I have you here, I thought I should give you two Best Of’s from the personal side:

--Best movie: Lost in Translation. I know expects the Microsoftie to say it is Lord of the Rings, but I’m sorry. This movie was great!
--Best album: Linkin Park, Meteora. What a great group and so young—I hope they continue to make great music for years to come.


Wednesday, December 17, 2003


THE WEEK BEFORE CHRISTMAS
****************************************************
'Twas the week before Christmas, when all through Bldg 5
The PAG team was cranking and the halls were alive;
The big grids were hung by the stairwell with care,
In anticipation of new patterns that would soon be there.
And our devs were coding something far better than javabeans,
For it was visions of app blocks that were dancing on their screens;
I was in my office, thinking of unique new plans
To spread the p&p gospel to our hungry .NET fans.
When out near the atrium there arose such a clatter,
I sprang from the office to see what was the matter.
What I saw before me hardly qualified as breaking news
The usual suspects were embroiled in a heated game of foos.
I worked my way into the game and proceeded to kick some major butt
My lethal defense & quick reflexes knocked my out of my 5pm rut.
Sure, there was work to do and I couldn't let down the team
But it can get demanding here and it helps to vent a little steam.
You see, in PAG, it's a thankless job taken on by a motley crew.
It's a team effort to change the world and we all deserve our due.
So after a year of hard work, may my teammates get all they seek,
"MERRY CHRISTMAS TO ALL, AND TO ALL A GOOD WEEK!"


Wednesday, December 10, 2003


A couple weeks back, I blogged about the conversation that friend and I were having regarding CAS and whether it was a viable alternative for software developers nothing to create secure applications. I think one of the best parts of being an employee of Microsoft is having these engaging conversations. The differences of opinion make for great debates and interesting topics to write about in my blog. Another interesting topic recently arose with a different friend regarding the state of software development. This friend seems to believe that software development will move completely to India in the next three to four years. Eventually the U.S. will find no reason to cultivate the software coding talents and instead focus more on higher level tasks such as architecture and design. As a member of the Platform Architecture Guidance team that revels in seeing increased focus architectural knowledge, that should make me a happy camper. However as a nerd and a fan of good coding, this concerns me. Coding is an art and to see it commoditized breaks my heart and to see it completely leave the US would be a shame. Fortunately I don’t hold the same opinion. This whole situation reminds me of about fifteen years ago when Japan seemed to dominate the market for cars and electronics and their semiconductors were way ahead of us. I remember how others is ongoing fear that the Japanese people would eventually own the United States thanks to their superior high-tech prowess. I once told someone back in high school that my goal in life was work for company that brought the U.S. back to preeminence in engineering. Looking back to my three years of Intel and now on my third year Microsoft, I think I fulfilled that prophecy. While still talented, Japan is no longer the juggernaut that once. Now, a software development crisis has occurred where India (and to a lesser extent Russia and other countries) seems to have taken quite a bit of work away from the United States. Companies are finding it much more cost effective to outsource coding to these nations where the quality is solid and the costs is far far cheaper. So, is software coding terminal? Are the days of pulling up VS, cracking open a Mountain Dew, and going to town over? I really don’t think so I think these trends tend to normalize. I believe that many companies are not inclined to trust the overseas results completely in addition to the U.S. is always gonna be strong about trying to protect jobs internally especially ones that are typically high pay. You may recall several years ago that they had a "made in USA" campaign that was built strictly around trying to leverage American product into buying products made domestically. You could make an argument ten years ago or fifteen years ago about random stuff and how everything was going to be built in China and Taiwan. Things are still being built there, but at the end of the day the U.S. still manufactures quite a bit of junk. I don’t expect software to be any different. Any company that believes that their IT assets are strategic should not risk them to external vendors. That’s why the financial institutions are where they are--they invest heavily in IT capital including human resources. The best companies are the ones that don’t chance it. Heck, that kept Oracle and Sun in business for several years with high-priced software and hardware packages. Plus, don't expect India to stay in the lower marging software development areas when there are more lucrative areas to attach. Going back to the Japanese analogy, they are no longer all about cars w/ 50 MPG. Instead, they are Lexus and Acura. They moved up the stack and so will India. And yet, Detroit is still making cars. It's all part of the ever-globalizing world of business we live in. We just need to make sure we don't just dump something like software overboard as a result of assuming one country can usurp an entire function. My $.02 and I owe you a penny...


Wednesday, December 03, 2003


I don't normally give that much time to the application blocks in this blog, but I am a fan--less of what they are now and more of what I think they could be in the future. In the days of COM & DCOM, the programming stack consisted of the (a) kernel, (b) the Win 32 API, and (c) the Microsoft Foundation Classes (MFC). My ideal stack of the future would be the (a) kernel, the (b) .NET Fx (CLR + Framework classes), and (c) PAG deliverables.

The Win 32 API allowed access to fundamental functionality of the OS as well as access to entire feature set of Windows. Want to open a window, play a tune, or capture a mouse-click? The Win 32 API was there for you. MFC was the layer on top that made it easier for users to take advantage of those APIs as well as the C/C++ languages in general. It contained classes that were no more/less complex than our blocks, including my favorite, CString, that took the pain and likely errors of character manipulation out of programming. The proud dev probably thought he was above using that, but I loved that it saved me time. Could I have written CString myself? Absolutely. But why? MS did it for me! Just like creating ActiveX controls. You could either use the ATL (yikes) or whip something up in 30 seconds flat with the MFC AppWizard and then start building my business logic on top of it. Now, the latter probably included some functionality I didn’t need, but who cares—I was off and running. Some people like to go to a tailor, go though painstaking measures to get fitted for a custom suit, and spend countless hours and dollars to get the perfect look. Others know they are a 42 Regular, tweak a little bit on the cuffs, and go. How perfect do you want it? I personally don’t have the time or the $$ to get fitted perfectly for suits and I think most devs are short on time and $$ as well. However, the multiple levels of abstractions is great news for consumers…

Now, with the .NET Fx classes, they’ve really abstracted a lot more than the Win 32 API (to be expected given the CLR itself is an abstraction of the OS) and managed to work themselves into the MFC space (see the diagram). However, they still need to be focused on intrinsic functionality and their decisions on abstractions are countered by their need to provide flexibility. Abstraction vs. flexibility—that’s where I see the tradeoff with programming models. That means there’s still some abstraction required (which is where the patterns & blocks fit in). The best thing about the blocks is that we provide both by delivering the abstraction as a white-box assembly that can be tweaked and modified as necessary. By putting in the right mechanisms, we can multiple entry points for customers to employ abstractions as well as raising the level of implementable abstraction. Yet, by providing code, we still provide flexibility. Plus, with the “old school” methods, you have discrete entry points to a certain degree. You either program to the kernel, the Win 32 APIs, or the MFCs. With “new school”, your entry point in the PAG part of the stack is almost “analog” given the guidance and customizability of our deliverables. Take the data access block assembly as is, just gut the code for the pieces you want, or build on top of it and re-compile the assembly. That flexibility is a huge opportunity to win competitively. Finally, shipping out of product cycle gives us a huge advantage over MFC (which was locked into the VC++ cycles) by being more dynamic and responsive. That's where the excitement of this job comes in for me. Just like the .NET guys must've felt with DCOM, I feel like we are taking a great base idea (an extensible framework like MFC) and taking it to the next level for a new generation of software paradigms.


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:

http://msdn.microsoft.com/longhorn/understanding/books/migrationguide/

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 Amazon.com at http://www.amazon.com/practices/ (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!


Wednesday, October 29, 2003


Viva la blocks. Another one is here!!! Everyone needs to monitor apps and there's a host of things to do: determine what info you want, design the event triggers, and make them available for analysis in an appropriate format. But building useful logging capabilities into applications can be a huge pain. To help provide effective event-capture for enterprise applications, PAG has designed the latest patterns & practices : the Logging Application Block. This block uses the Microsoft Enterprise Instrumentation Framework (EIF) and the Microsoft .NET Framework to help customers design instrumented applications. We've made sure that it's available to everyone as well--as opposed to the MSDN Universal subscribers. The link is on the block's home page. I really like the way this block turned out. I think the documentation is pretty good and our field members (who have been using our block for a month or so now) have been raving about it. The block includes event sinks for SQL Server, MSMQ, both Windows Event & Trace Logs and WMI. I know what you're asking: what about the Exception Management Block (EMAB, as well like to call it)? How does it relate? Well, this block provides all the functionality of the EMAB and more. Yes, I know the next question: some of you already deployed EMAB as part of their applications and may wonder how to move forward. Fortuntately, that's pretty well covered in the docs. Basically, the EMAB can use different publishers to raise exceptions to different sinks. Just raise the exception to EIF instead of a data store. Once EIF catches the exceptions, it pretty gets caught by the logging block, which can process the events. Since the EMAB's event sink was set in the config file, you don't even need to touch your app to use the logging block. Ahh, the beauty of config files. :)

Anyway, we've got more blocks out in the future. But we'll try not to deluge you like we did back in June. Enjoy this one. Kick the tires. Experiment with it. And if you like it, let the patterns & practices team know about it through the feedback alias...

Next blog--the PDC wrap up...


Tuesday, October 21, 2003


My code thinks in ink. Really. At Microsoft, they just had a competition for writing PowerToys for the TabletPC that thinks in ink. They plastered ads for the contest all over campus and they kept using the phrase "Does Your Code Think In Ink?" I admit it. I fell for it. But, I dragged my feet for the first few weeks of the contest. I was having a hard time figuring out an idea for what my Power Toy would do. I had a couple of cool ideas around collaborative messaging, but a lot of it had been done already. Besides, I think that ranks higher on the cool factor than the usefulness factor (and anything on a Tablet automatically qualifies as cool :>). So, I kept asking myself--why do I think a Tablet is so useful (see my previous post). And the main thing was that, much like the code I was asked to write, I think in ink. Whiteboard, notepads, whatever. When I want to give feedback on a document, I have a hard time using Word's reviewing feature. It's not that the feature isn't useful--I just prefer to mark a doc with an angry red pen. :> That's when it hit me on what to do. However, to not jinx my submission, I will save the details of my app for another entry. What I will tell you is one man's six-day journey through the world of C#. Not as a guy who does it for a living, but rather someone who understands enough to be dangerous but not enough to have the simple answers all in my head. From Sunday at 1pm to Friday at 11:59pm (the time of my submission), I spent every momentum not on campus thinking about, stressing about, and coding this app. I'd stay up late at night, I'd do it on the bus, etc. As I like to explain it to my wife when I get into this mindset and start fumbling everything else that loses focus, I was in "developer mode"....

So, what was my biggest frustration? I spent 2.5 days figuring out something that was eventually solved with 5 lines of code. ARGHH!!! Wanna hear something worse--it had nothing to do with ink. Double ARGHH! I was trying to launch the toy from IE and then have the app do some info sharing with IE. Now, the obvious avenues were cut off by security and I will NEVER argue against that. In fact, this was a tricky thing that I was asking to do. But the frustration came from sifting the web to find the information--even with the vaunted Google search engine. I know, I know. A guy that works for Microsoft and posts his product on MSDN shouldn't talk. But, to quote a former president, "I feel your pain". What was most frustrating was reading docs that were clearly out of date. I was finding approaches that were appropriate for IE 2.0. People need to stick and XML tag in HTML docs that provides the date the doc was generated. It wasn't until Wednesday night that I was able to start coding in ink. Fortunately, Thursday's baseball playoff Game 7 and the post-game buzz kept me awake and alive for a late night of coding (to answer the certain questions of that statement and make my tangential remark, [a] yes I can code and watch baseball at the same time and [b] I detest the Yankees and hate that they made another World Series and it broke my heart to see the Sox come that close, but that game is the reason why baseball is such a tremendous spectator sport. Who didn't get choked up watching the seeing Bret Boone watch his little brother accomplish something they'd probably acted out in their backyard for years). Anyway, thanks to a patient wife and Aaron Boone, I finished the app at 11:30pm on Friday night. I actually got virtually every feature in there, built the installer, and did some pretty extensive testing to prove the thing was tip top. So, let's review. In a project that really lasted ~130 hours, I spent 60 of it looking for one answer. Not coding. Not architecting. Not testing. Not deploying. Now you can take a shot at me and say it's my fault for not knowing when to cut my losses, but this app would've stunk without this feature (as you'll understand when I post the app explanation in a future blog). I guess the point I am laboring to make is that we really need to make the right answers consumable and readily available. In the tool? Perhaps (I'm a fan of Dynamic Help, but believe that's incrememental and takes a lot of hp when you're coding on a laptop). But cleaning out old irrlevant docs and archiving them where they belong--that'd make me happy. Little written in 1995 helps me today (I should know--I actually knew how to code somewhat proficiently back then before the MBA Gods had their way with me :>). Creating more intelligent search enginers and tagging docs intelligently. I know it's the dream of WinFS to make finding what you're looking for less challenging and I pray that WinFS can save the day. Cuz folks, not even the good folks at Google were able to save me...


Thursday, October 09, 2003


I got a TabletPC a couple of months ago. I had been begging for one for a long time. I love the ability to scribble down notes and keyboards do not support scribbling. I have to admit that when I finally got it, I was a little concerned I'd be disappointed. Y'know, it's like when you get really excited for that Christmas gift and by the time Christmas rolls around, your expectations are so high, there's no way the gift will meet it. Well, I have to say the Tablet achieved as expected and it changes a lot of the way I do things. I love it. I love being able to draw pictures, scribble to-do lists and meeting notes, and even do crossword puzzles on the computer. But the most interesting thing about it has been my ability to sell the idea to the technophobes. My bro, the doc, treats PCs the way a four-year treats asparagus (yuk!). Yes, when I was showing him my Tablet and talking about all the ways he could use it, you could see the skepticism and fear melting away. I started telling him about how he could completely transform his sports medicine clinic and by the end, he was completely sold. In fact, I was starting to dream about building the system for his company. Dozens of Tablets connected via a WLAN that enable easy info capture & sharing. I was also putting it in a student context about how note-taking and documentation annotations could totally increase student productivity and that got my wife (a former techie who's going to grad school for public affairs) on the bandwagon and thinking she needs one. I'm so proud to be part of a company that helped put this thing out. Of course, given my day-to-day work and how we speak of this thing called "smart client", I wonder how many of our enterprise customers realize the potential of this thing to be the next level of business. Probably not many--I feel like the leap forward on this product is more exciting for someone who doesn't like computers more than those who live on it. For those who live on it, it's a cool incremental increase. For those who don't, it breaks down the barrier of keyboards and mice that have scared off too many people. Of course, while the enterprise customer may not need it for its internal users, the enterprise that is trying to make a customer web experience more enjoyable could do themselves a huge favor by finding a way to build this in to their app. We've got the killer device--now, we need the killer app that goes with it...


Friday, October 03, 2003


OK, I spent a lot of time travelling over the past few weeks and I even planned to write an entry on one of my plane rides. But, I got carried away with my non-techie blog entry about the Orioles closing out the year (an off-line entry I still haven't posted :<) and never got around to that fun .NET stuff. Still, travelling out of the friendly (or sometimes, not so friendly) confines of Redmond enables me to see the world in a whole new light. You get away from the techie perspective and see the real world. My two main stops were to do some recruiting back at b-school in Philly and then swing up to Providence to see my technophobic 37-year old brother and recently initiated 74-year old father. I'll cover the latter visit another time, but the visit to business school was pretty interesting. I was there to seek out the hot talent that will be tomorrow's leaders at Microsoft. Whaton is a kick-ass school and I'm proud to be a grad. The amount of Type A's running around there is frightening. Going there was a little like a player going from college to the NFL. The game just speeds up like you are fast forwarding a VCR (or fast-forwarding a DVD player, if you are so technically inclined). This was my second time back to recruit and while the faces change, the spirit and attitudes remain the same. The job market isn't what it was three years ago when I was looking, but confidence helps in situations like these and most of these students are brimming with it. Of course, I feel funny when these people think I hold the key to their future at Microsoft and work hard to impress me. I prefer situations where I can get them excited about the company and just have an informal chat about the future of technology and the business opportunities there. So, while I was signed up to do the recruiting bit on Wednesday, I had a chat with a guy in the Tech Club about doing an informal talk on .NET the night before. No recruiting. No resumes. Just me up there on stage telling the world about Microsoft. I thought it might go for an hour. I'd give them the half-hour schpiel and then answer a few questions and call it a night. Plus, it started at 9pm and the e-mail to solicit the audience didn't go out until the night beforehand. I wasn't even sure if more than 3 people would attend...

Well, there must've been 25-30 people there and they were awesome. The audience was different than what I've become accustomed to (devs + architects), but that made the questions even more interesting. Some wanted to understand the technology a little deeper and I had to be careful how deep I went to avoid giving these guys the bends. I even started writing some C# code before realizing that if OOP is something VB guys are resisting, the MBA world probably isn't anxious for it either. Meanwhile, other people were trying to separate the hype from reality with web services and some of the other "next big things" that Microsoft, Sun, IBM, et al continually push. I was impressed to hear their skepticism and excited to tell them about what Microsoft has done and how much easier it is to make it real. In all, the session lasted over 2.5 hours and it touched on dozens of interesting questions. The main messages: web services are real, they are ready for deployment today, and the things you can do today are amazing. The next generation is just going to make it incredibly simpler. I was telling someone today that some of the future products of Microsoft will do for HST ("hoooking s--t together", the preferred acronym to EAI) what VS.NET did for web services. Make it real and change the game. I, for one, can't wait and I can't wait to make this talk again next year. That's why working for Microsoft is so great--there's always so much to look forward to and it never ends...


Friday, September 12, 2003


Looks like Blogger got the site stats thing working, so now we'll know if people are coming to the blog. Time to start sticking the site on my e-mail signature...

I'm real busy. Much like Ed, I've got a dizzying array of things going on. Some things I can reveal and other I could tell you, but I'd have to kill you (and I don't know how that would work with a blog--that's just not scalable thinking). One of the interesting things that's being discussed is how to make patterns digestible for those who don't have an appetite for it. Nowadays, too many people fear design patterns. I confess that even I am not a complete convert, although the work that David Trowbridge & company did with Enterprise Solution Patterns Using Microsoft .NET definitely swayed my opinion (chapter 1 alone is worth the read to see patterns in a whole new light). But a lot of people just won't have it--especially if you're a VB dude that still resisting OO programming as well. I was speaking to a Microsoft partner from Kentucky (and all around good guy) about patterns. He's a die-hard VB fan, but loves patterns as well (kinda like my vegetarian wife who admits she occasionally craves a bacon cheeseburger). He believes that convincing the VB world about patterns is not an impossible task and Microsoft owes it to the VB community to support that education effort. I tend to think he is right and it's something I'd like to see us get involved in. From my pre-Microsoft days as a developer and evangelist to my current status as a Microsoft dude, I've always felt very strongly about the way Microsoft has supported and strengthened it's developer community. Much is made of the Linux devs, but I am more impressed by the legions of devs who have created countless app for the MS platforms and I think their loyalty has less to do with platform ubiquity and more to do with the TLC Microsoft has always given. From MSDN (despite our complaints that p&p stuff doesn't get highlighted enough, it's still the best repository for tech content in the world) to Visual Studio (I can't say enough about the wizards, IntelliSense, etc.--I can't believe I used to code in emacs in college!), Microsoft has always done what it takes to carry their loyal devs to the next level. Making VB.NET was part of that as well. As a p&p guy, I feel that sense of obligation with getting those who can benefit from patterns to see the light. Patterns are not for everyone (heck, I'm still not sure they're for me), but I think there are a whole load of VB programmers that would go hog wild for this stuff if we can make it sexy. Therein lies the challenge. Like I said, I'm real busy...


Tuesday, September 09, 2003


The Tie Fighter looks great in the office, I must say. Lego just rocks.

Stuff aside, right now got too much things to do. There's the reference app, smart client guidance, tools stuff, giving-feedback-to-product-groups thing, and aspect stuff. Plus the authorization and profile mgmt blocks are coming out and we have to review the design - they look great but in their infancy these things always have some quirky twists here and there that need ironing out.

Jim and I talked about the patterns & practices tool stuff today and he and I think very similarly about it. You can go deep into a set of features that are true but start giving diminishing returns... but there are a couple of wins that can be done with minimal infrastructure investment for the Everett VS.NET, that would be a major win: broad tuning of enterprise templates and code gen stuff. I need to get with Pascal Belaud again, to make a joint story on that. His Olymars stuff is great, and we may give it an extra twist of lime here an there. One thing I want to decouple is the metadata schema from the metadata loading from an external source (SQL). Coupling both from my experience building generators reduces some opportunities for future growth...but to be fair I haven't looked at his latest version (last time I opened it was ~4 months ago)...in the meantime I encourage you to check it out.



Tuesday, August 19, 2003


Building guidance is fun. And gruelling too.
But, related to Sandy's last post, there's an aspect of building guidance which I'll share- it's the responsibility that goes with making recommendations on how to design, build, secure, etc your systems.
It's with this is mind that I entitle this log entry....

The Weight Of Giving Guidance

Providing best practices for application developers is a great privilege, but a great responsibility too. There's of course the typical standard stuff that goes into executing any software project - like an Application Block. There are responsibilities to meet customer demands under a gazillion constraints. But there is a meta-responsibility in whose light the 'patterns and practices project execution' metrics (as in-time, in-budget, bug-count, happy-team etc) pale. The responsibility that goes with knowing (or at least..hoping) a large set of architects, developers, and operators will be following the advice.

I like feeling personally accountable for the guidance we give. When we write content & code about something, I like to feel the weight* that goes into giving those recommendations and dealing with those problems. It goes beyond dogfooding - trying to follow the guidance ourselves at PAG to build a system. It also goes beyond the beta-testing in live accounts that happens during guidance development.

What I like doing is working directly, closely, intimately, with customers who are at critical decision points and help them through the issues by providing information, material, and processes, and yes, being a part of the team and having an opinion in the decision making. I think it's important to be able to look at someone in the eye when recommending them whether to use datasets or build custom business entity classes. To be able to work with the developers who will be following that recommendation, answering the conceptual and nitty-gritty questions . And giving them your cell phone number to be able to track you down in case something went astray when, for example, they discover they need to change the way they build entities when they already have 300 of them, a trained team of 10 developers, and a whole set of design decisions made upon the previous choice. But it's not the fear of the call that drives improvement. Working closely with them builds an empathic connection that can't be easily severed. When one of those guys stays late at night working on a toughie you should have prevented, you feel the hit.

So there it is - guidance is not fire and forget. If you are part of an architecture team, or set design policy/guides for others, I'm sure you do have a measure of personal accountability for defects in the engineering advice which is the outcome of your effort... at PAG, even though we are in far-off-where-is-it-anyways-often-blamed-for-ivory-tower-thinking Redmond,WA,USA, we feel that accountability too.

[AGCCTG] Changed the St.Germain CD -Finally. For Paul Van Dyk. And Delerium is coming to town.
[TCGGAC] Still waiting for my Lego.StarWars.TieInterceptor. That'll snazz up the collection in the office quite a bit.

*Does guidance have mass? I guess I mean weight in a Kunderian way.


Monday, August 18, 2003


OK, Ed takes care of the thought leadership and I will serve as the shameless shill of new guidance that is on our site. The latest guide from our team is the WS-I guidance that we worked on in coordination with the XML Web Services team. It is located at:

WS-I Guide

I was able to witness some of the neogtiations that went on between all the companies involved to settle on the final ratified rules and it was a clearly an impressive experience. It was overwhleming to see a lot of really smart people feeling empowered to change the way people connect their apps. As one director from another group at Microsoft put it, "we are helping define how people will be implementing their systems for the next 20 years. We have to take that responsibility very seriously." It's that sort of thinking that really makes me excited to be a part of this company...


Thursday, August 14, 2003


As Sandy said, if you got stuff to blame BlueBricks for, I'll take the hit..but please go to the GotDotNet wokspaces first. Theres lots of people who can help buffer the anger :)

There's Models and Then There's Models

So if you work specifying metamodels, or domain models, you will have surely gone through what I have just gone through right now.
It starts simple. You start modelling a space because it happens to have too many entities - in my case the mental threshold is just above one. And it starts getting richer. Enrich, normalize, refactor, enrich, recheck assumptions, come from another angle, add something, remove half, bring back half of that, focus on the left side of the diagram, on the right side of the diagram, and suddenly you end up with the 100% correct-truthful-to-boot-mathematically-provable-ultraprecise-specification....covering 2 miles square

Which brought to mind the endless discussion between the usefulness and usability of something. A complex model can be extremely useful - bringing in the right indirections, separations, classifiers, generalizations, specializations, subdivisions, and so on - but it is unusable as the number of decisions that need to be taken to implement one instance of it explodes. Suddenly doing something 'simple' seems to take 38 decisions from superabstract to gunky levels. And that's not what I want to do for a living. I want to make it easier.

All this in the end brings up one question in some people's heads:
Why? Why not forget all this hogwash about models, metaprogramming, and metadata stuff and let you write the code?
What's the value?
I think the typical answer revolves around many topics, but boils down to one thing: Compression of information

Think about code. Think about it in terms of the decisions you need to take.
Think about all the decisions that need to be taken to give it the right 'context' - exception management, transactions, authorization, etc.
You would need...a finite amount of yes-no answers before knowing how you want to deal with these things.
Simple Example: Transactions: Required, Requires New, Supported, Not Supported. 4 decisions = 2 bits.
Simple Example: Exception handling: no try/catch, try/finally, try/catch/finally, try, catch(publish), and finally.

Now think about all the decisions you would need to take to write the code to implement these decisions. Should I write an exception handler? For what exception type - a generic or a specific one? The number of yes-no decisions needed to write the code is way larger than the number of yes-no decisions you need to answer to completely specify the desired behaviour. And there it is - while in code it may take N bits to express a decision in code, that decision really requires M bits. The remainder bits (N-M) are duplication, redundancy, noise (or non-significant bits), or derivable from context.

We have to deal with this every day when building Application Blocks for .NET. You may have notice they are heavily based on metadata. I use these guidelines in myhead when designing the metadat models and schema for those models:
- The model should separate unrelated concerns (eg separate dev stuff from ops stuff)
- The model should be normalized to reduce redundancy and duplication (eg reduce places where a type name is declared)
- The model should allow for variability points (setting structure rather than policy - or architecture rather than implementation)
- Allow generic multiplicity - if you see 2 subelements may be needed for a certain element, think about supporting N.

But metadata can get complicated. This complexity can be reduced by some useful techniques:
- The schema should group together related concerns as seen by an audience or by a use case to reduce the files and places to touch in order to 'do something'. Tools can help in this too.
- The configuration system should have smart defaults, being able to robustely deal with incomplete specification and expose incosisitent specification.

Sometimes though, a little extra is needed than what you may have planned for, this is how you cope with unforseen change:
- Allow for extensions of the metadata schema that do not invalidate the part you need (ability ti intermesh extra elements, attributes, etc)
- Allow pass-through parameters - see how people can specifiy extra attributes in your metadata schema, and give it to the appropriate components related to that segment.

Having good metadata schemas have another effect which is visible in certain environments : by actually providing a declarative environment and a metadata schema, you are exposing what are the decisions you need to take. Sometimes what makes you fail is not your wrong decisions, but the ones you didn't know you had to take, or the ones that the wrong people took without knowing the impact. And adding the time dimension, tools can help the right metadata decisions happening at the right time.

Of course many people don't like this whole metadata thing. They'd rather code themselves. As with any technique there's good and bad ways of using it. It's important to understand:
- where using metadata compresses the decisons and where it actually expands (think of it as an abstraction level. For some stuff, specifying what you want in code is more compressed than expresing it in other ways)
- when it is applied, by whom, and when it can be changed and what is the impact

Happy modelling.

[000] Listening to St germain. Gotta Change that CD.
[010] Still cooking the aspects thingie. There were some good discussions in the last MSR Campridge fest, (DUUUUH). Dang. I should have not turned down the invitation.
[110] Scott and Naveen are working on the Logging Block - a set of EIF publishers for SQL and MSMQ, EMAB -EIF integration, and other coolness.
[100] It's sunny outside but no flying around today for Ed
[101] I just found out our word template can import boilerplates. I think I might make some for the app block writers.
[111] This whole codegen thing and templates for metaprogramming transformation thing in tools is not getting enough of my time for it to happen. I had some cool stuff in my old notes, will need to fish them out.
[011] Sandy, Srinath just beat the heck out of Per and me at Foos.
[001] Just finished traversing a cube following Hamming distances of 1. Given a hypercube of N dimensions, what's the amount of points that can be touched with (1..N) hamming distances?


Wednesday, August 13, 2003


As you see from the previous post, we have a new blogger in the .NET Sweatshop. Ed is Captain Bluebrick, the renegade Solution Architecture that is the father of the App Blocks you see on the patterns & practices site. There are few people at Microsoft with as much enthusiasm as EdJez and he backs it up with a great knowledge of the .NET Framework and customer challenges. He and Srinath actually give this blog a little credibility, so I'm hoping they keep posting. I've got more to say, but I'll let you digest Ed's first post before I do my thing...


Tuesday, August 12, 2003



BlueBricks.

There it is. I mean, you shouldn't have to build the yet-another-once-again-data helper right? So if you have been following Sandman's shameless plugs into patterns & practices (please do: p&p) you know what I'm talking about - the Application Blocks for .NET. They help you build better systems, faster.

It's been a privilege....
Before saying anything else - let me place the focus where it is due. BlueBricks was put together by a lot of effort of a lot of smart folks within and outside of Microsoft. It was individuals who felt the need, and built solutions for their peers. So - here it is to the first wave of BlueBricks devs. It's been a privilege to work with each one of you:

- Steve Busby & Bart Robertson - for the COM & .NET interop stuff, the fundamental 'what if we...' meeting, and finding ways to take my bif. Steve must wake up at night recalling my pleas - "Busby - Find me Brrrrains!!"
- Franco Ceruti & Fili Selvas Patino- for the endless design discussions and the needed support & drive to go on when the effort seemed (was!) just too much.
- [Ami]Tabh Srivastava & Jeff Kercher - for the wmi guide, the asp.net authn stuff. Jeff's contribution to the software industry: IPV6 security and... "Are you building an app? Y/N...N:have beer"
- Chris Brooks and Kenny Jones. The first block implementers. Chris & Alex wrote the data access guide and built the 1.0 of DAAB, and Kenny the EMAB. If you have a support question about the blocks their cell phone # is.. (By the way, Jason Hogg has recently updated them! DAAB can get typed datasets! FINALLY!)(By the way - Please manage your exceptions, it makes Kenny happy)
- Angela Crocker , Chris Schoon - 'passing data thru tiers' and 'app-managed authorization' guides. The architectural reviews drove Angela nuts enough to become an Architect Evangelist.
- Jackie Richards, Aaron Barth , Ray Escamilla& Brett Keown, Team Development, Debugging, Package & Deploy - always cool to work w the ol' gang from PSS. If anyone can make a tough problem go away, it's them.
- Graeme Malcolm & Alex Mackman, the first writers from Content Master we worked with - Graeme survived me in an architectohrrea bout that lead to this
- Ronen Ashkenazi & Avi Ben-Menahem - the caching guide & block design. Check out the pluggable "Stoghage" and "expighations" on that block.
- Michael Stuart, Diego Gonzalez, Ed Lafferty and the gang: for the UIP, CMAB and Updater. Michael kindof represents the archetypical bluebricks dev in my mind - passionate for the cause and customers, critical in thought, and always asking for more funding.

Of course there are a lot more people now, and there are many others in test (Mo, Chris), writing (many!), management overhead (no need to point fingers), etc that helped all along. Them, and the consultants, specialists, partners and customers who shaped this are literally many hundreds. But it was the push and passion and precision of these folks that let us grow to what it is today. It was a fun process - I got to experience first-hand what it was to grow an underdog project from skunkworks status to...the publicly known under-dog-skunkworks it is today. The start-up mindset is alive and well. I got to sleep in the office for the first time since I joined MS. I became part of the coolest alias around- The Think Tank. I got to build the BlueBricks server on a hand-me-down box which still sits under my desk. Are we done? oh no. Keep on reading.

Here's the takeaway for this post: p&p and the Application Blocks are built by lots of people like you, for people like you. That means something - it means you can be part of it too. We are still learning about how to share plans and get feedback in a scalable way, but in the meantime we created one GotDotNet workspace for each Application Block & topics so you can go and help shape the future.

Thought of the minute
When I started BlueBricks I had a set of principles in mind which I won't state right now because lots of things come to mind. I hope the philosophy will gleam through this and other posts.

It's interesting though how folks who work a lot with software and think holistically are able to develop a sense for software - a sense not unlike sound, smell or touch. A sense that can be probably traced back to, or rationalized into, basic software principles (coupling, cohesion, Demeter, etc). And like any sense, you develop a system of aesthetics for what you perceive. (you know - you may run into an APIs that feels rough. Objects may seem to be tangled. I've heard Martin Fowler refer to how code smells). When I talk about 'design philosophy' or 'aesthetics' it raises some people's eyebrows from some folks, but it also gets understanding looks.

I've seen many types of frameworks for developers, but they can be classified in two familes - those that you code to and those you code with.

You can tell them apart right away. The ones you code to usually have a big symptom - you have to structure your code to some interface, and when object A wants to call object B it needs to call the framework who will do a lot of stuff for you and then invoke B through this interface. I like thinking of them as clerks - you ask them to do something, and they go and deal with other folks and things that the clerk - and sometimes only the clerk- can talk to.

Those frameowrks you code with, however, are different in structure and convey a different feeling when using them. These present well-encapsulated services that you can consume and that help set the stage for your work, but don't get in the way. I call these the 'guardian angel' frameworks- they won't deal with other components in your application, rather, they'll help you deal with them in the right way.

Example: Think of the User Interface Process Application Block. It sets the controllers, state and does page/window navigation for you. But your ASP.NET page calls the controller the usual way. It's a 'normal' .NET component call. No unnatural command pattern getting in the way, no pesky untyped parameters, no loss of productivity in defining 'payload types'. As we keep tackling tougher problems with the blocks we keep pushing ourselves to conform to this. I'd like to be able to say 'you've just added X capability to your app - without touching your functional logic code'

So where do they get mixed up? Well, some types of things (like authorization, instrumentation, and other aspects) would actually benefit from being able to be 'in the way'. But without being in the way. Other things should just be 'declarations' ('of intent'?). But aspects & metaprogramming - "code gen" - and tooling are another story, albeit a nearby one :) Stay tuned.

[00] My whiteboard has the Authorization, Authentication & Profile App block design on it. Interested?Just created the workspace.
[01] Listening to St Germain.
[10] I once applied for a job @ Saunders-Vixen, and I think I might've gotten the job - and was outsourced to MS for the time being.
[11] Working on the Application Block template to help ourselves @ MS and others be able to build these with more consistency and efficiency.


Thursday, July 31, 2003


For the past five weeks, I have inherited the role of patterns & practices marketing dude. Steve Elston, a long-time MS employee and one of the coolest people I met here, finally stepped down and decided to lead the chill life with his wife and kids. Good for him, but unfortunate for our team--those are some big shoes to fill. p&p made some major strides in the past year. Still, we're not on a lot of radars and people don't recognize us universally just yet. Admittedly, our catalog is still growing and I expect us to gain better traction in the future, but we really need to rachet it up. Last year, we got millions of hits and hundreds of thousands of people downloading our guides, but I believe that's our dedicated fan base and some word of mouth--people need to find us in the first place. Hopefully, anyone reading this blog has taken a peek (another shameless plug: http://www.microsoft.com/practices/), but if we are to continue building more of this stuff, we need your help. Post to our newsgroups. Mail to the alias for this blog (see the about us page). Pass feedback to MSDN. Remember when MTV first came out? Sting, Pete Townshend, Pat Benatar all screaming "I want my MTV!". Well, if you really like us, tell MSDN. Tell microsoft.com. Notify your favorite Microsofties. Tell them "I WANT MY PATTERNS & PRATICES". Meanwhile, share the secret--with your friends, your family, even your german shepard. We're still the underdog here and we need your voices to be heard to get us the resources to build more and make it more easily accessible. OK, off my soapbox. Next post will be more oriented to the content and I won't try to start any revolutions. Well, I don't think so...


Thursday, July 10, 2003


Hi folks,

Sorry to be slow on the blog, but the last month has been extra hectic. We've been churning stuff out left and right and now we are in event mode as well. We're heavy into TechEd season, we've got our internal field meeting coming up next week, and plans are already underway for our big partner event and PDC, the king of all events! But, I thought I'd fill you in on some nifty new releases we have just had coming out (I've been reading Richard Feynmann lately and he keeps using the word "nifty", so I stole that one from him). Here are three new blocks for your development pleasure:

User Interface Process Application Block


Simple yet extensible framework for developing user interface processes. It is designed to abstract the control flow and state management out of the user interface layer into a user interface process layer. This enables you to write generic code for the control flow and state management of different types of applications (for example, Web applications and Windows-based applications) and helps you write applications that manage users' tasks in complex scenarios (for example, suspending and resuming stateful tasks).


Configuration Management Application Block


A simple yet flexible solution that you can use across all your applications to manage configuration data. Specifically, it provides a set of methods that allow you to read and write application configuration data without the need to instantiate objects or perform complex data conversions in your code through a flexible data model that allows you to use any in-memory data structure to represent your configuration data.


Application Updater Application Block


A .NET solution that provides a "pull model" solution to automatically download application updates from a central location, designed for organizations who want the rich functionality of Windows Forms applications with the centralized manageability of Web-based applications. By using the Updater Application Block to download application updates, you can overcome the security "sand box" limitations of downloading Windows Forms applications through a browser, while still maintaining control and security over the application update process.

Lots of stuff to help devs do stuff on the web tier or with the celebrated "smart client". Ron Jacobs, a colleague of mine here at PnP wrote some code that showcase them. Visit his site at:

The World of Ron Jacobs

Let us know what you think about the blocks. We've got plenty more in addition to these that I will cover in the near future.




Wednesday, June 18, 2003


It's finally here. After 8 long months of blood, sweat, & tears, the menfrom the "Security GoF" has just released the follow-up to Building Secure Web Apps. This guide helps you design, build, & configure tough web apps that withstand most attacks and mitigate the extent of damage if someone slips by. The key words: holistic and systematic. STRIDE is cool and it gets the ball rolling, but as JD puts it, this guide is gonna "rock people's world". Now, I gotta warn you--this thing is HUGE. Over 800 pages and it's free as a PDF! There will be a print version for those of you who don't want to destroy your printers, but this isn't about selling books. Security is like a baseball umpire--you don't notice him until he screws up. Well, you don't know security until you've been burned. Unfortunately, most of you have been burned whether you realize it or not. This guide is a collection of experiences converted into actionable guidance. How To's, Checklists, QuickStarts. I think I even saw the kitchen sink in there ;>. Anyway, take a look and let me know what you think (mailing address is swtshpATmicrosoft.com).

Improving Web Application Security


Wednesday, June 11, 2003


Obviously, security is a key issue here at Microsoft and especially within our guidance juggernaut. Specifically dealing with ASP.NET, our first guide is out there and our second guide is soon to follow. The security studs at @Stake did a study of WebSphere on Red Hat running against Win 2003/.NET Fx 1.1 and I have to say I was pretty happy with what they came up with, especially because they pointed out the emphasis that Microsoft put on provididng security guidance. That's JD, Srinath, Ray, and Dunner (or as I like to think of them, the Security GoF ;>). When I started on this job, everyone was telling me we couldn't be better than IBM & their Redbooks. It reminded me of Conan O'Brien's first episode 10 years ago when everyone told him he could never be as good as Letterman. Well, folks, I loved Letterman but Conan is better. And Redbooks are cool, but we're better. No trash-talking, just one man's opinion. Well, one man and the folks at @Stake. Check out their report at:

http://www.atstake.com/research/reports/eval_ms_ibm

(WARNING: Shameless Plug Ahead)
And for those of you who have been enligtened by our first guide, you can find it at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetlpMSDN.asp?frame=true


Home