CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Raymond Lewallen

Framework Design, Agile Coach, President Oklahoma City Developers Group, Microsoft MVP C#, TDD, Continuous Integration, Patterns and Practices, Domain Driven Design, Speaker, VB.Net, C# and Sql Server

February 2007 - Posts

  • Sam Gentile in Oklahoma City March 5th

    CodeBetter's very own Sam Gentile will be in Oklahoma City on March 5th to talk to the user group about Service Oriented Architecture with Windows Communication Foundation.

    Don't miss this rare chance to see a master in action who has already deployed framework 3.0 based enterprise applications and learn from his experiences.

    Details are here.

  • Patterns are not buzzwords

    buzz·word

    1. A word or phrase connected with a specialized field or group that usually sounds important or technical and is used primarily to impress laypersons: "'Sensitivity' is the buzzword in the beauty industry this fall" (ADWEEK).
    2. A stylish or trendy word or phrase.
    3. a word or phrase that is frequently used because of its importance or popularity especially among a certain age-group or profession
      Example: `Recycling' is the new buzzword.

    I'm kinda poking fun at a coworker here with this.  He didn't specifically say that "Strategy", "State", "Supervising Controller" or anything like that was a buzzword, but I recall he did say "Open-Closed Principle" (which is, of course, a principle of OO, not a design pattern) is a buzzword, or something like that.

    Patterns are not buzzwords.  At least not in the way that I think of what a buzzword is.  I did find a source that defines buzzword as "a word or phrase, often sounding authoritative or technical, that is a vogue term in a particular profession, field of study, popular culture, etc."  But what it neglates to elaborate on is the fact that buzzwords have a lifespan.  They are short-lived in their meanings, usually no longer than a few years.  Software design patterns do not fit that category.  They are long lasting, have concrete definitions and stand as a solid form of communication in the industry.

    I've heard on occasion people call patterns, practices or principles buzzwords.  In fact, they are not.  They are a form of communication amongst a group of people, in this case, developers and even managers, to simplify and create more effective communication.  A common and efficient language is critical to a properly built and well oil development machine.

    Its so much easier to say "I'm going to decorate this class." than it is to say "I'm going to add some sort of dynamic functionality to this class."  Ok, not too bad.  But now, how about take something common like a factory pattern.  Yeah, NOW how much easier is it to say that you're going to implement a factory pattern, rather than go all out and talk about how you're going to be designing an interface for creating objects, but your implementation is going to be allowing subclasses to make the decisions on which actual instances of classes they want to create.  If someone tells me template, I know what they are talking about without further explanation.

    Its important to know and understand design patterns, otherwise when someone else tells you they are going to implement a strategy and get rid of the switch statements, you might be uneasy about what it about to happen if you don't understand what they are talking about.  The best way to learn them is to write code.

    Here is more information regarding "patterns" and "communication" here on CodeBetter.

  • WPF/E requires a Javascript Master?

    You know I haven't dug just a whole lot into WPF/E.  I did spend about 4 hours yesterday giving a hard and quick look at it though.  What did I get out of it?  Well, how is something that requires and ties into javascript the way it does ever going to compete with Flash?  Not only that, but you have to have the client install something that will render the xaml (it installed something, this is what I assumed it was, for the vector graphics and animation and whatnot).  WPF/E resources on the web are lacking in info from what I've found, and the expression series of tools website doesn't have any good information either.  All the demos and tutorials are too remedial to make an informed decision about the products and technology.  I spent 2 hours on a tutorial on Expression Blend, and at the end of it, my synchronization of databound elements wouldn't stay in sync like they were supposed to, which was the entire purpose of doing the demo.  I could have done the same thing in VS in about 5 minutes and made it work fine.  The only advantage was that I could slap some nice coloring and layout stuff onto the page with Expression Blend.

    BTW, Expression Design is pretty damned slick.  You can create full vector images just like if you were using Photoshop, and export them out to XAML.  I thought that was impressive.  The demo on that was nice too.

    So I downloaded about all the demo's and websites I could find on WPF/E, and every one of them is filled with a TON of javascript.  How is that easier than anything else I'm doing?  Seems like going backwards to me.

    I also got the trial of Expression Web and downloaded the starter kit.  I thought there was going to be something cool in there, but turns out, there is nothing (that my untrained eye can find) that has anything to do with WPF!  Its just a plain Asp.Net 2.0 website!

    Is WPF/E really a viable solution?  Is it going to get widespread use in the future?  My first impressions after spending about 4 hours with it is no, at least not for enterprise applications.  Its use is primarily for media, vector graphics and animation - period.  All interaction with these elements requires javascript, and what appears to be a lot of it, and that's a big downer to me.  I admit I know nothing about Flash except that it looks cool and requires a plug-in to run in my browser.  From a user perspective, WPF/E will be the same thing.  However, from a developer prospective, are you going to quit using your Flash model and switch to WPF/E?  Is it really going to be better?  Javascript and untyped form data... oh joy.  Cross platform is a plus though :)

    I went through quite a bit of WPF/E stuff yesterday and I have to say, that's probably as far as I'm going to go with it for quite awhile.  The technology doesn't fit what I do, because I don't build Amazon or YouTube or anything of those websites that would benefit and look snazzy with this type of ability that WPF/E provides.

    Those of you have do have more than 4 hours of "getting to know you" time with WPF/E, feel free to set me straight on this.

  • Speaking at Tulsa Code Camp on March 10th

    For those of you in the Oklahoma, Kansas, Missouri, North Texas, North Arkansas areas, the 1st annual Tulsa Code Camp will be Saturday, March 10th, 2007.  The central theme is .Net 3.0/3.5.

    There are already several great speakers setup.  I'm going to be presenting a one hour talk on design patterns and another one hour talk on C# 3.0 language specification features.  Then its a drive back home to get on a plane early the next morning to head to Seattle for a week, as I know several of the speakers will be doing.

  • Controller != code-behind

    This always drives me nuts.  I'm working on a brand spankin new project that has zero code, so a co-worker and I are working on how we want to address the MVP implementation.  So lately I'm reading up on new ideas that people have come with since the last time I did a ground-up implementation regarding MVP, service facades, business proxies, etc, and then most of my reading is on mocking MVP and looking at things like StructureMap and Spring.Net.  My co-worker is looking at MVP stuff and Web Client Software Factory and ObjectBuilder and the like.  So if anybody has any excellent resources, feel free to post them here.

    Ok, so back to it, I was looking up MVP ideas and came across this page.  Half way down the page it says "Controller: Code-behind .vb/.cs files"  and goes on to say "ASP.NET doesnt have central controller function, instead the code-behind file can directly make request to the Model and can update the dataset. But lot of controller function can be implemented in code behind class events in .aspx or .ascx pages, like Page_Onload(), OnItem_Created() etcevents."

    IMO: No, no, no.

    Code-behind is View.  Always.  Controllers are UI agnostic and have no knowledge of System.Web at all in Asp.Net applications.  Zero.  Zilch.  Fowler last year split the MVP into Passive View and Supervising Controller.  Passive view is the more testable of the two because all behavior of the view is driven by the presenter, and is the most popular way to design MVP in Asp.Net.  Presentation Model is another popular way to design MVP and is close to Passive view except it is a more view-event-driven design, which works well, but events are harder to test.  Regardless of which way you go, there is a clear and obvious seperation of responsibilities, and I'm pretty sure if Fowler had written any of those to be specific to .Net, somewhere in the first or second paragraph of each one, he would say "code-behind is view code, never controller/presenter".

    If you place controller responsibility into the code-behind, good luck with testing that.  Your lack of cohesion goes up, your tightness of coupling goes up, extensibility drops and testability drops.  Its a serious design flaw to do that, so just don't.  I could send you to probably 100 different sites that talk about this if I google it, but I'll leave you to do it.

    If anybody has any ideas to the contrary regarding placing controller design into code-behind, I'd love to discuss the topic.  Like I said, I've refocused on MVP lately because of the new project and am loving all the new ideas I have been finding regarding designing MVP for mocking, so I'm all into talking about ideas right now.

    Once we are done, I'm going to share what we came up with as an overall MVP architecture on here, but that's probably a few weeks away.

  • How to look, or at least feel, like a complete fool - Part 2

    An extension of this, how many of you would have spent more than 5 seconds debugging why this won't compile?

    public string Hello
    {
        return null;
    }

    I spent 5 minutes.  This is what happens when you spend too much time switching between VB and C#.  I feel like I'm my very own DailyWTF lately.

  • How to make a complete fool out of yourself

    Its easy.  Just do what I did.  First, turn off your brain.  Then tell somebody that adapters and dependency injection work in similiar fasions.  Have that somebody tell 10 of their friends, and then each of those 10 people tell 10 more people and so on.  But don't stop there.  Then tell that person that facades and templates behave the same.  Repeat the whole tell your friend have them tell their friend thing.

    Ok, so now that you look like a complete and utter idiot, turn your brain back on.  Go back and read the conversation, think about who was talking here, realize it was you, go puke in the toilet and then bury your head in the sand in embarassment.

    I've never had an episode of complete brain malfunction like that before in my life.  You ever just have something snap in your head, like something turned back on and say to yourself "What?  Huh?  Wait a minute, what did I just say?"

    Just for clarification, adapters and DI do not behave the same.  At all.  Adapters "adapt" from interface A to interface B.  DI is a custom implementation plug-in like behavior pattern.

    Also, subconsciously, I meant to say that adapters and facades behave in similiar but obviously seperate fasions.  Facades provide unified interfaces (this is where template crossed my mind because you often used facades to unify multiple template interfaces, at least I do) and adapters, again, adapt interfaces from one to another.  Why random misfirings occurred in my brain and those 3 simple, one line explanations came out all wrong, I may never know.

    Please tell me that I'm not the only one to have done something this stupid and embarassing.  Please.  Share your quick stories here so I won't feel alone.

  • Materials from Dallas Presentation

    Over 90 people attend my talk in Dallas on Wednesday.  It was a great crowd with some wonderful discussions.  Below are the links to both the presentation deck and the VS2005 solution.

    Here are photos from the presentation, thanks to Giovanni Gallucci of www.TheAgencyBlog.com.

    Here is the powerpoint.

    Here is the zipped solution file.

  • Presenting to North Dallas User's Group on Wednesday, Feb. 7th.

    Yes, if you are in the Dallas area, I will be presenting to NDDUG tomorrow evening.

    Title:
    Designing Frameworks - The Do's and Do Not's

    Abstract:
    Designing frameworks can be very tricky.  There are so many things to consider when designing an API that it takes several books covering several points of view each to really cover everything that is involved.

    This presentation is designed to give you a basic understanding of framework design: proper abstraction, encapsulation, allowance for extensibility and performance in general.  You have to remember, when somebody uses your framework, most of what they know about your framework is going to be assumptions on their part.  We'll discuss the common assumptions and how to make your code adhere to commonly accepted practices.

    More importantly, we'll look at identifying problems, common code smells, refactorings and patterns and avoidance of common problems in general.

More Posts