April 2004 - Posts

• showing your hand

  I’ve been trying to do the whole “don’t run as administrator”/”principle of least privilege” thing for a while now.  And it’s pretty easy to tell who probably isn’t trying to follow it, by seeing who recommends tools that don’t work when you aren’t an administrator. And, to echo Andrew G Duthie’s statements on the matter, it’s hard to convince others to do it when respected people are the offenders. Posted Apr 24 2004, 09:12 PM by Andy Smith with 5 comment(s)

• MSDN tour video

  Channel9 has a great video tour of the MSDN offices. And by great, I mean that it includes me. Chris Sells and Scoble caught Darren Neimke and I hanging out with Kent Sharkey during the aftermath of the MVP summit. Posted Apr 15 2004, 08:59 PM by Andy Smith with 2 comment(s)

• Stronly Typed Resx

  Now this is a man of action. Michael Schwarz, upon seeing that vstudio2005 has a great feature where resx files have a codebehind which gives you easy strongly typed access to the resources, has created a macro which creates the resx codebehind for 2002/2003. I haven’t tried it yet, but I like it already. Posted Apr 14 2004, 05:46 PM by Andy Smith with no comments

• Spaghetti, CodeInPage, CodeBehind, and CodeBeside

  Now that Whidbey is around, I think it’s a good time to reflect on all these different coding models we’ve used over the years. Way back in the asp3 days, we had two basic but not-mutually-exclusive ways of putting our code into our page. The first version most people learned is the spaghetti code style. This is where you just have your html as you always did, and in the document where you wanted dynamic html, you’d put a <%=  %> block, and just emit some html. This was easy, quick, dirty, and horrible. Long term, this style is very bad for disciplined coding and maintenance. The other method was to put code in a separate script block element that was set to runat=”server”. This style doesn’t have a real name, so I’ll call it CodeInPage for this, but was much better in many ways, but probably the best win was that the logic was in one place and the presentation was in another. Unfortunately, the basic asp3 infrastructure didn’t really provide a lot of tools to help you write code this way. Many people wrote their own frameworks on top of asp3 to support this separation and while they worked, I never saw a single one that really felt “right”. Most used xml/xslt or COM based UI objects. And because these frameworks were fairly complicated, it was a hard sell to the new guys just learning asp3. Spaghetti was just way too easy and obvious for simple examples. And then asp.net came out and everything changed. Now we had a new layer on top of the basic request/response streams. We had serverside controls that we could manipulate with code in it’s own block. It was much closer to the  Form/Controls model that has proven so useful in both windows applications and which has existed on the browser clientside with elements and javascript. So now the spaghetti style, while still around, was obsolete. And beginners could really get into the dragging of controls onto the designer and handling button click events. It was natural and quick. So what are the options now? Well, there are two. The CodeInPage model and the new CodeBehind model. We’ve already talked about CodeInPage, and for those who don’t know (who are you and why are you reading this blog?), CodeBehind is where there is a separate file for the code. This file derives from Page, contains declarations for the server controls, and contains all the event handlers and such. The aspx file then derives from this class for the final page. Which one to use here has been a pretty big issue since asp.net was introduced to the world way back when. So here is where I get into some serious minority opinion, but hopefully people won’t dismiss it just because it’s the minority right now. Up front… I think the CodeBehind model is a bad hack. CodeBehind solves two tool-related problems while bringing in a whole host of other framework-related other problems. The two problems that CodeBehind solves is that intellisense needed 1 language per file to work, so the serverside code was put in one file and we are happy. It also eases the compiler pain of detecting bugs in serverside code, as it only needs to deal with the code files by themselves, not the ui declaration mixed in. However, look at the problems it creates… ·        While the codebehind is compiled, it is never checked against the aspx declaration, so any disconnects there, such as malformed DataBinding syntax areas, or mismatched IDs, or any host of other problems, won’t be known until runtime when somebody hits the page. But you get this misleading feeling that everything is ok because it compiled ok. ·        Take a hard look at the interaction between the CodeBehind class and the aspx Page class. The CodeBehind class contains control declarations and event handlers, but it never instantiates the controls. The aspx derives from the codebehind, also contains the same declarations, these declarations are hooked up by apparent magic, and actually instantiates the protected members of the base class. I don’t know about you, but if I saw somebody follow this pattern in any other context, I would be appalled. ·        It’s a bad application of the “separation of code and UI” concept. In general, seperation is a good idea. It is a bad design to be running sql commands from your button click event handler. However, this goes both too far and not far enough when it comes to code behind. Look, the code that interacts directly with the UI is forever linked to the UI. There will never be a true separation between a Panel declaration and the code that says MyPanel.Visible = false. And at the same time that you have this over-seperation of the code and UI, you also have all this code in the UI declaration file, disguised in databinding syntax blocks. Obviously the bulk of your app code should reside in non-UI assemblies. Business layer, Data Layer, etc… but right at the edge, where the UI needs functionality, there needs to be some code that ISN’T separated. Now I’m not saying that CodeBehind is all evil, it’s great for what it does, which is give you better tool support. I’m just saying that these bad things only exist in order to have a tool that has to be worked on less to offer more features and thus sell better. The pros and cons for CodeInPage are exactly the opposite. No vstudio support for things like a design surface that you drag controls on to. No intellisense in your code. No pre compilation for error checking. But the model, it seems to me, is more correct. It’s the tool that is not finished. The model here is better because everything in a page gets compiled to one class. The fact that the UI is declared in a different language than the what event handlers are coded in… seems rather irrelevant to me. Nobody seriously spazzes about a windows.forms app having the UI declaration ( Do Not Edit Me region ) and the form code being compiled to the same class. As far as I can tell, that’s only because they are in the same language. I don’t have a problem, one way or the other, as far as separate files for UI code and UI declaration is concerned. But the two are inexorably linked, and should be in the same class. This point of view only really effects me in that I don’t have intellisense in my UI code. I wouldn’t use the designer in vstudio 2002/2003 anyway, because it borks the markup so horribly. And I don’t mind not having a designtime compile step for the UI code, as it’s not a whole lot of code anyway. The dynamic compilation feedback and debugging support in asp.net is great as it is already. I don’t need to create some overly complex “web project” to build my site. I need a couple coded application tiers in its own solution, and a series of pages that use them. So now Whidbey stuff is shown… and they’ve gotten rid of all the problems in both models. The tool now completely supports the CodeInPage model, intellisense and all. And the CodeBehind model has been morphed into the CodeBeside model, where the two are compiled into the same class. All the synchronization and odd design anitpattern problems just float away. So now in Whidbey, there is zero technical reason to choose one over the other. Now it’s just a matter of… do I like my code in a separate file? Or do I prefer my code as a separate view on the same file? Personally… I like the single-file style still, if only for ease of copy-pasting examples to others and having a smaller file set to deal with. But the decision is so pointless, that I hope this whole discussion will just fade away. So ya, that’s my take, and I’m sure I’ll get flamed to hell for it… but hey, at least consider my points before you laugh and set the bozo bit. Posted Apr 14 2004, 06:56 AM by Andy Smith with 31 comment(s)

• updates to vstudio source control integration

  You know what feature is sadly missing from this list of changes to visual studio’s Whidbey enhancements to the source control integration? Built in support for Edit-Merge-Commit is still not there. CheckOut-CheckIn just does not cut it for distributed or owner-driven projects. When are they going to get this right? Posted Apr 14 2004, 12:11 AM by Andy Smith with 5 comment(s)

• The anonymous wikki under fire

  I would be seriously angry if this happened to me.  Of course, any site or application which accepts anonymous 3rd party content is going to fall for this eventually… but it’s just so sad that we can’t have a single thing that spammers won’t abuse. Posted Apr 13 2004, 10:27 PM by Andy Smith with 1 comment(s) Filed under: rambling

• Rob Chartier on home automation

  Rob Chartier has turned his home into a geek golden palace. I’ve loved the idea of this stuff for a long time now, but I don’t think it’s quite there yet for the really fun stuff. My fridge needs an IP Address durnit. :) Posted Apr 13 2004, 06:12 PM by Andy Smith with 1 comment(s)

• How the provider model isn't just a rename of a basic design pattern

  In the Yet Another Whidbey Post vein, I just wanted to talk a bit deeper on the provider model than what you can currently find on google or msdn. Usually, when most people hear about it and how it’s used, the first thing they usually think is… “that’s going to be useful for a lot of people in a lot of ways”. It’s great for the app dev who just wants simple functionality like login and membership and personalization. It’s also great for the guys who want to tweak the hell out of how those kinds of things are implemented. And at a different level, it’s great for third parties to provide presentation and business layer tiers for redistributed apps, while allows their clients to provide the final hook up to backend. But then the second reaction kinda depends on whether that person has learned about patterns. If they have, then they’ll probably connect the provider model to a couple of the GOF patterns and think, “oh great, this provider stuff is just a buzzword on top of a well known pattern.” Well, to that, I say that the provider model is a bit more than just a general pattern. The model is a composition/blending of the Abstract Factory, Strategy, Singleton and Component Configurator patterns, as well as, and this is important, an implementation spec for how and where those patterns connect, as well as how to implement some of the more hand-wavy parts of the pattern descriptions. To start from the API user point of view... It kind of has that Singleton feel. It’s not quite a strict implementation of Singleton, but it’s the best fit as far I know. The idea of having a static class that exposes the API, while lazy loading and proxying requests to an instance-based implementor… It’s not a pattern that has a name as of yet (that I know of, please correct me if I’m wrong ). The interaction and point behind the various implementers, is kind of a blending between Abstract Factory and Strategy. It’s a Strategy in that you have individual strategies for implementing a feature set. The strategy implementers don’t derive from the type the client uses, but instead the client calls a public “face” class’s methods, and the face class knows about and calls the methods on a abstract implementation base class. With providers, the face class generally has the same methods (albeit static) as the implementations, but that is by no means a requirement. However, it kind of breaks with Strategy in that the pattern kind of suggests that the client actively chooses the strategy to use, maybe even on a call by call basis, based on current conditions. In this respect, it’s more like Abstract Factory, in that the implementation is a configuration option, chosen via Component Configurator, as a separate config file. This is of course the right thing. The controls shouldn’t be deciding the provider, the app developer should be doing that. It’s not fully Abstract Factory, tho, because abstract factory is about creating other types. Provider implementions are about doing tasks not creating custom typed objects. And then the spec comes in. The spec is mostly about making both configuration for the app dev, and implementation of custom provider implementations, as easy and predictable as possible. In configuration, the spec defines how the xml configuration section should look. So that an app dev that knows how one provider feature works, such as Personalization, would know, in a general sense, how others such as Membership should work. Or that a tool can be written that can share significant portions of code for configuring the various features. For the individual provider implementer, the idea is that as much of the hard work as possible went into the feature provider face. Things like consuming the config files, determining provider, and getting the API right, is done by the feature’s face. And that the abstract base class which defines how provider implementers work is as simple and clear as possible to derive from and implement. The spec defines the good practice base classes that hint at how the configuration, initialization and usage will work. It also defines common naming schemes so that providers APIs are easy to discover and use. So anyway, that’s how I see it all coming together. And while it’s obviously not some big revolution that solves world hunger and pioneers peace in war torn areas of the world… Clearly, it is a nice and ultimately useful evolutionary step. In closing, I think this stuff is quite exciting. And not just because I’ll be able to do things faster and easier when Whidbey comes out, but because it gives us all a great model to use in our current apps when we have similar infrastructure problems to solve. So ultimately, this article wasn’t so much about Whidbey as I may have let on in the beginning, but more about how we can use these insights to make our current apps better both today and tomorrow. Posted Apr 13 2004, 05:56 AM by Andy Smith with 14 comment(s) Filed under: asp.net controls

• Yet Another MVP Summit Reflection

  So I rolled into denver last nite to a post-mvp-summit Unread Messages folder of over 2000 items. It took me a solid 3 hours to plow thru all that, but it was well worth it for the trip. Like everybody else, I obviously can't talk about any tech that's not already public, so this essentially becomes a shoutout to the guys that I wandered up to and had some fun with. Day 0, And So It Begins I have a flight at 8:30 AM to seatac, so I just stay up until the drive to the airport, planning on hopping on the plane and sleeping till seattle. As Peter Provost mentioned, that didn't quite happen. What happened was me staring at the fog out the window, while I waited for over 4 hours as my plane was delayed 15 minutes at a time. The crying baby next to me allows me approximately 10 minutes of nap time, and I land at seatac way later than I wanted, with much less sleep than I wanted, and a growing distaste for Frontier. So now i'm having a great time chatting with the growing number of signed-in MVP's and drinking at a respectable pace. There was a great booth at the sign-in room where MS Research was showing off the really interesting stuff going on in the Netscan project. I ended up spending most of the time at the signin room chatting with Marcie Robillard, Steven Smith, Scott Hanselman, Peter Provost, James Avery, Rob Chartier, amoung others. I'm not even going to pretend to remember everybody at the table later during the get together at the W, but I remember a highly political discussion with Plip. Day 1, Tired and Intrigued at the same time So I wake up entirely too late to make the free shuttle to the campus, and end up grabbing a cab to make it there just in time for the sessions. At this point I'm running on about 5 hours sleep since saturday, still not completely sober from the previous nite, and most likely looking like I have the face of grim death. However I did wade my way thru some great presentations on the coming features in data and debugging. And of course the don box and chris anderson show was entertaining, if not particularly enlightening. Post agenda, we all went out for some beer and pool to Pikes Place Brewery, i think. But at around 11PM, having over 60 hours of almost uninterupted non-sleep, it was time to crash. Day 2, Executives and The Big Party I obviously can't say much about the executive talks beyond, "Ballmer is a great speaker and rallyer of the troops". However, I sat in on some great discussions in a pseudo-organzied lunch where I was at a table with community leaders from around the world. After the agenda was done, we all went back to the campus conference center and had a blast. Ambrose Little has some great photos. And, as Peter Provost mentioned, upon getting back to the hotel we got invited up to the presidential suite for an impromptu after party. Day 3, Deep Tech Talks I do feel kind of bad because I completely skipped most of the presentations, in favor of sitting around talking geek with Darren Neimke, Scott Mitchell, James Avery, and others. That was some good times; with everybody fairly awake and juiced up about deep tech ideas. So now the MVP Summit is technically over, but there is always more to do. Personally, I opted to follow Darren Neimke around, because he has an amazing ability meet with and connect people. I really can't say enough about how personable Darren is. We spent much of the nite chatting with Justin Rogers (and wife Amy ( Hi Amy ) ) who is one of the most diversely intelligent devs out there, even if he is a bit too worried about perf for my tastes. ( Just getting in my last jab there justin :) Day 4, The Wanderers Darren has plans to stay in seattle for a little while longer, and had set up some extremly loose arrangements with MS guys to come visit them at the offices during the week, and so we wandered around the MS campus, popping into buildings and asking if they had some free time to talk. Amoung a few others, the venerable aspnet dev center guy, Kent Sharkey, was quite hospitable, and we all had some great threads going. And of course, We also spent some more time with Justin, and not only that but he and Amy we also extremely kind enough to cart us around town. Wrap up So ya, that's the experience. I still can't believe the size of the crowd, both external and internal, that Microsoft gets together every year for this event. Big thanks to everybody. Posted Apr 09 2004, 07:52 PM by Andy Smith with 4 comment(s)

• Apple Laptop Design

  Even tho Greg only has on complaint about apple laptops, I have one more, and it's a deal-breaker for me.In their quest for “thin“, they didn't recess the touchpad quite enough, and meat of my thumb would constantly move the cursor around.maybe it's something I could get used to...  but well designed hardware doesn't need to be gotten used to, it's already right. Posted Apr 02 2004, 03:27 PM by Andy Smith with 2 comment(s) Filed under: rambling