August 2005 - Posts
One of my favorite features within .NET 2.0 is ClickOnce. I’ve deployed two prototype applications using ClickOnce and overall I’m a big fan. As a “web guy” learning about win forms I love the fact that I can continue to have an easy deployment in the Win Forms world. Every time I load up an app and get the nice dialog asking me if I want to get the latest version everything feels right in the WinForms world. No longer do I have to uninstall and reinstall applications, I just click on the application and it automatically updates itself if a new version is available.
Although ClickOnce is a great technology I wonder if it’s too late to the party. The average corporate business user has been brainwashed to think that if it’s not a web app it’s not for them. Over the past couple of years the industry has strongly advocated the web and slowly but surely most business applications have been converted to a web platform. With the migration to the web IT departments have gained the benefit of having an “easy” deployment, and users have been granted access to their applications from anywhere in the world. Ah….the power of the web.
With the added benefits of mobility and easy deployment also come some costs. The web is a stateful beast. Many a developer has spent endless hours trying to make their web app feel more like a windows app. It turns out users want responsive applications along with that mobility and easy deployment. In an attempt to provide users with a more responsive interface developers across the world have tried endless hacks. Out of all these hacks has come AJAX. The saviour of the web platform. The technology that will bring the responsiveness of a windows app to the browser. Erm, I’m not sure I buy that. While some applications will be able to leverage AJAX to provide users with a more responsive application, AJAX != Windows. No matter how much AJAX you sprinkle on your web application you will not get the responsiveness you will get from a Windows App. AJAX is cool, AJAX will help improve the usability of some applications, AJAX DOES NOT MEAN WE SHOULDN’T DEVELOP ANY MORE WINDOWS APPLICATIONS.
A very large number of business applications in the world today could see tremendous value in moving back to a Windows world. That’s right I said it. Move you applications from the web back to Windows. Of course do so only if you can develop your application using .NET 2.0 and ClickOnce. And only do so if it actually makes sense, don’t start moving your web based shopping cart to a Windows app. Do consider moving your web based business applications back to Windows.
I’m sure your thinking to yourself, “are you nuts?”.
Do I really expect you to give up your mobility?
No. In fact I’ll give you even more mobility. I’ll create a Smart client application that provides offline support. This way you can “get shit done” (tm) even when you have no Internet or wifi connection. Sure it won’t be 100% fully featured when your in disconnected “mode” but it will be a lot more featured then your “Server not found” page.
Do I really expect you to give up on your web application that you can access from any platform?
Yes. The fact is many business applications out in the world today only support a single browser anyway (IE), so just pretend that when you click on the link to the application that it’s opening in IE. I’ll even give you a toolbar that looks like IE if it will make you feel better. With that said if you really do need to be able to access the application from a Mac, Windows, and Linux you may be better off with a web application. I’ve found that most business application only support IE, if this is the case for you consider ditching the web for Windows!
The web is great for a lot of things, however, it is NOT great for everything. If your building software using .NET consider fighting the urge to go with the flow and move everything to the web. Give your users what they want. Give them an application that is easy to deploy, provides them mobility, AND is responsive. Give them a Windows app!
I’m experimenting with some Google Ads on my site. I’m expecting the ads to bring in a boatload of money so I can retire early.
Ok, not really….hopefully it will provide a little money to help with the costs of being out on my own. Let me know if they get too annoying, if you’d prefer different placement, or if you just disagree with having ads altogether.
I knew there
had to a clean way to do this. Unfortunetly I didn’t know what that clean way was…..until now.
Jeffrey Palermo has a nice summary writeup of Ron Jacobs thoughts on SOA. On a related note I saw a number of interesting podcasts on Ron Jacobs podcast page relating to service orientation (SO).
-
| SO Technology Model Applied | Enough beating around the bush - now we get to the meat of how this thing gets implemented. | [mp3] |
| The SO Technology Model | Ron and Beat discuss how the Technology model aligns with the SO model | [mp3]
| Service Orientation Models | Ron and Beat chat about three models for architecting solutions with the principles of service orientation. | [mp3
]
James Shore has placed “An
Extreme Stake in the Ground”. Where would you like to place your stake?
I think I’ll put mine right next to his. 
In the
September 2005 issue of MSDN Magazine
Griffen Caprio has written an article on Dependency Injection (DI). Using dependency injection is a great way to make components more testable. I’m in the process of investigating a couple different component containers that support DI so I’ll be sure to post back with more when there is more to post back with.
During the last couple months I’ve been coding almost exclusively in VS.NET 2005. This of course means I’ve had to go without all the nice features of ReSharper that I’ve grown accustomed to. Although a version of ReSharper has been released for VS.NET 2005 it’s still too buggy for actual use. During this time I’ve slowly learned some of the keyboard shortcuts that do the things I’m used to relying on ReSharper for.
SHIFT+ALT+F10 – This brings up the “Smart Tag” window when it’s available. I often use this when I’ve referenced a type but have not yet “imported” the namespace, as well as when I inherit from an interface (or class) and want to implement the methods of the given interface.
CTRL+R+R – Rename refactoring.
CTRL+R+M – Extract method refactoring.
What’s your favorite VS.NET shortcut?
Jessica Fosler has a nice post on
Keeping your UI Responsive and the Dangers of Application.DoEvents. Within it she discusses some options for removing calls to Application.DoEvents for updating the UI which may help improve the responsiveness of your app.
Over the last couple weeks I've been getting "up to speed" on Indigo.
I read "Programming Indigo", read the various articles over on MSDN, as
well as experimented with the Indigo Beta 1 bits.
During this time I came across a lot of positive feedback on Indigo.
There are clearly a lot of people who are "on board" with what
Microsoft is trying to accomplish with Indigo.
This past weekend I came across a series of posts from
John-Cavnar-Johnson that are pretty critical of Indigo. In
Mort Gets
the Message John criticizes what he calls the OO facade that Indigo
pushes on developers. He goes on to point out the specific items which
he dislikes in
10 Things I Hate About Indigo.
Although I don't necessarily agree with John, I can see where he is
coming from. In particular I think the points he makes about Indigo
service calls feeling just like normal method calls is pretty legit.
If boundaries are explicit why do Indigo service calls feel just like
calling a method on an object?
John is also pretty critical of the attribute based approach that
Indigo uses for defining data contracts and message contracts. I like
the Indigo approach to defining contracts. I agree with John that it
could lead developers to litter their domain model with messaging meta
data. I think we need to start advocating a seperate
messaging/contract layer that sits above our domain model. We should
explicitly define our messages within this layer and have a translation
layer that takes those messages and converts them to our domain
objects. The obvious downside to this approach is that we add another
set of classes to our project that we have to maintain.
It sounds like John wants to deal with a Message object. He doesn't
want something that looks like a normal object, he wants it to look and
feel different. He wants his boundaries to feel explicit. He wants to
feel like he's dealing with messages not objects.
I can't say I blame him, isn't that what the four tenets of service orientation are all about?
One of the items that I have on my list of todo’s is the evaluation of some options for a container for components in .NET. Within systems we very often have a lot of dependencies between components. To help reduce the coupling of these components we can make use of a container such as PicoContainer that supports dependency injection.
Is anyone using a component container out there in the .NET world? If so which one?
A couple days ago I had my first “pair programming” experience. Overall it went pretty well. It was hard to get started but once we got rolling things moved along pretty well. Anyway that’s not the point of this post.
As I was driving I started to look at a new piece of functionality that we wanted to add and saw some dependencies between the logic that we were about to add and another component within our project. Before implementing the DoSomethingCool() method that we were looking to implement I took some steps to make it so our tests could be isolated. The first step I took was to decouple the components by allowing the component which we were dependent on to be “injected” using constructor dependency injection.
MyDependentClass dependentClass;
public MyClass(MyDependentClass dependentClass) {
this.dependentClass = dependentClass;
}
This allowed us to inject a mock implementation of MyDependentClass and ensured we were only testing a single component.
Now MyDependentClass had a number of methods on it, one of which our new set of logic was going to make use of. The method we needed to utilize was performing a lookup of an object using the FindSomeThingYouNeed() method. Rather then use the FindSomeThingYouNeed() method on the MyDependentClass object I decided to create a MockMyDependentClass object that had the FindSomeThingYouNeed() method “mocked”. This way I could fake out MyClass by providing a dummy implementation of the FindSomeThingYouNeed() method. Doing this would allow me to test in isolation my DoSomethingCool() method.
Now I had too basic options for mocking out the FindSomeThingYouNeedMethod(). I could either create an interface for the MyDependentClass such as:
public interface IDependentClass {
CoolObject FindSomeThingYouNeed();
// and on and on for all other “stuff” needed
}
or I could make the FindSomeThingYouNeed() method on the MyDependentClass object virtual. Since I only needed to mock out this one method I chose to mark the FindSomeThingYouNeed() method as virtual and override the behavior in my MockMyDependentClass.
So as I performed the necessary steps to make the method virtual and mock out the implementation my pair started to grimmace a bit (not really but it sounds better). Noticing his “grimmace” I paused. He then mentioned that he didn’t really feel right about marking a method as virtual JUST to test. At first I thought, well that’s just the price you have to pay for testability. If testability is important we’ll learn to live with a few extra virtual keywords.
As the remainder of our pair session continued I had this lousy feeling about those virtual methods. I started to think that the need for virtuals just for testing might be a smell. I decided to get some feedback from the test driven development mailing list on yahoo.
What I realized after reading a couple of replies is that I may have been too quick to just jump into the implementation using a virtual. I should have stopped and considered the “smell” and evaluated if it was the right decision. Rather then marking methods virtual left and right I should consider the design of my app and look at ways that I might be able to remove those virtuals since they *may be* pointing to a design flaw within my application.
So the moral of the story is:
Never get so set in your thinking and the way that you do things that you can’t change. Remember that things that don’t feel quite right to you AND even more so to your pair may need some more thought. Don’t just say, we’ll that’s the price we pay for testability. Think about if that price really needs to be paid. Think about alternate designs that may reduce any “smells” from cropping into your system. Ok, so maybe I don’t have a real moral of the story. The point is, well, I don’t have a point I just wanted to tell the story…
As I’ve mentioned several times recently I’m thinking a lot about different architectural issues relating to the development of a set of services for “our” product. One of the things that I’ve been realizing is that we have very little real world guidance for how to build services. We talk a lot about the high level concepts such as sharing schema not type, following the four tenets of service orientation, and etc. but we talk very little about the real stuff that we need to think about when designing services.
A data driven application that is using a domain model is pretty well covered. We have things like Domain Driven Design that help us layer our application into entities, factories, and repositories. We have all the information we could ever want about DataSet’s. Yet we have very little about real world development of services. Perhaps it’s out there and I just haven’t come across it yet. Perhaps it’s talked about just not in the circles that I frequent.
As I learn and experiment with various real world services issues I’m going to try and record my findings, thoughts, and experiences here. Below are some things that I’ll likely be developing some thoughts around:
– How does O/R Mapping fit in with services?
– How does one leverage their domain model when developing services?
– How do we best provide customized views of our data to our services while leveraging an O/R Mapper behind the scenes?
– How does having to support multiple databases impact the way our domain is developed? (Ok, this one isn’t very service focused)
– And much much more….
TheZel asked for some material on Indigo. There’s probably a bunch more out there but below is the material that I’ve come across so far….
WinFX SDK: What is Indigo
Programming Indigo: The Programming Model
Programming Indigo: Contracts
Introduction to Indigo (video)
This is useful for those of us who like continuous integration and also like ClickOnce.
How ClickOnce Manifest Generation works with MSBuild
Dave Burke let me know that my comment form is all busted up. If you receive a nice error message when submitting a comment you should be able to go re-submit it and get things to work. Obviously this is only a short term solution as I’ll be looking into what’s going on with the form tonight. Anyway, just wanted to let everyone know that my comment form may boom-bust on you. I’ll try and have it fixed up shortly.
One of the things that’s been on my mind a lot recently is how best to design services. I’m definitely a strong believer in a contact first approach to services. I particularly like the “contract first” design approach in Indigo since it’s done using C# code.
We’ve been designing some basic services recently but too be honest we haven’t exactly been doing things contact first. We’ve been starting with our objects/tables and simply passing those objects directly along to the client application. GASP! Yeah, I know, so anyway while we’ve been doing this I’ve obviously been thinking a lot about the fact that we’re not designing our messages and contacts we’re just taking what our objects are giving us and passing them on down the line. As I’ve been doing this I’ve been realizing why designing our contacts is important. Although our objects have a lot of the data that we’ll be sending along in our messages they don’t have all the data, and they certainly don’t have it formatted and organized in a way that will help us ensure we can have chunky service calls.
So as I’ve begun thinking about our migration to a better approach I’ve been thinking a lot about how best to fit messages/contacts in with our object model. In a very large number of instances our messages are going to contain about 95% of the data that is contained in a single instance of one of our objects. As I began thinking about the system as a whole I started to realize this was probably going to be the case across the board. So we have a set of objects that come pretty darn close to matching up the the messages we want to be sending back to our clients but we know we don’t actually want to be sending our objects. What is the best way to keep our contacts/messages and objects separate but also not have to write a translator object for every conversion of one of our objects into one of our messages?
Client does work that results in a message being sent
Service receives message
Service translates the message into objects that our repository/data layers recognize
Service hands objects off to a unit of work type objects for processing
Service receives a status/response from our unit of work and translates it into a response message
Service sends response message
Client receives response
How do we reduce the amount of translation required for taking messages and turning them into objects? How do we reduce the amount of work required for taking the results of a unit of work (again most likely our objects) and translating them into our response messages?
Another topic that has been on my mind recently is O/R Mapping and how it fits into a services oriented system. Since the messages that we send back to our client are not our actual objects we’ll need to transform the results that we retrieve from our O/R Mapper into messages. Often times the data we need in our messages will not match up directly with a table that we’re “mapped” to in our mapper. For instance, if we have a foreign key reference to another table, it’s pretty likely that we’ll want to bring back the details of the record to which we have our FK reference. However, if we’re brining back large chunks of data how best do we design our application and specifically the portion of our application using an O/R Mapper to handle this. Perhaps it’s as simple as mapping our objects to views, perhaps there’s more to it?
Although this blog posts is mostly a series of questions I’m not sure I’m necessarily expecting answers. I’m more logging a bunch of things that I’m currently thinking about so I can reflect back on the thoughts in the future. Hopefully this will mean some future posts that are of interest. Of course if you have thoughts and opinions on any of my ramblings here I’d love to hear them. Either drop me an email, leave a comment, or contact me via the “Contact” link in the top nav of my site.
I started a new gig recently which I’m really enjoying. The job offers a lot of changes which I’m a fan of. These include the following:
1) Moving from a consulting shop to a software shop.
2) Moving from the web world to the windows world.
3) Moving from one place trying agile to another place trying to do agile (hrm, I guess that’s kinda the same).
4) Moving from a place that did minor “services” work to a team that is planning on making a lot of our application available via services.
#4 is the one that spurred me to pick up David Pallman’s “Programming Indigo” book. Over the past couple weeks I’ve been reading through the book learning about the various “things” that make up Indigo. This involves how do define contacts using [DataContract] and [DataMember] attributes, how to define our service contacts using [ServiceContact] and [OperationContact], as well as how to define the behavior of our services and methods using the [ServiceBehavior] and [OperationBehavior] attributes.
After reading Programming Indigo I have to say I’m impressed with the programming model. Things seem very easy to setup and configure in Indigo. I’ve started to work on a prototype app that will be using Indigo so I’ll be curious to see if things start to get more confusing or convoluted when I start doing “real services work”.
If your interested in services, and particularly Microsoft’s vision for services in the future I’d definitely recommend picking up Programming Indigo. The book doesn’t go into a lot of detail but it does provide all the information necessary for getting up to speed on the primary building blocks of Indigo. I would have liked more discussion on the various options for security and examples for when you’d use each, as well as case studies that dove deeper into the internals of Indigo, but, overall it was a book I’d read again.
A couple days ago Tim Haines posted a blog entry where he asked his readers to chime in on how we thought AJAX could be used to improve the usability of his online shop, HandyShop. I’ve been pretty busy of late so am just now getting around to responding. I haven’t had a chance to follow all the responses up to now so hopefully people won’t yell at me too bad when I duplicate their idea. I feel as though I might be violating the “spirit” of a blogversation by not “listening” to what others have said up to now, but I’m doing it anyway!
AJAX is a nice fancy term for using XML over HTTP. It’s nothing all that new but it has a fancy name now so is “all the rage”. I think the most important thing to keep in mind when considering how to use AJAX is to remember the reasons one would choose to use AJAX in the first place. The web doesn’t provide the greatest user experience to visitors. Every time they perform an action, especially in the .NET world, they’re paying the price. The price is of course the amount of time it takes to post back to the server to respond to their action. The beauty of AJAX is that we can begin to offer users a more responsive and thus more usable interface. We begin to be able to offer some “Smart Client’ish” things to our users.
Ok, so get to the friggin point already, right? How can we use AJAX to improve a shopping cart?
The most important thing you can offer visitors of your website is the ability to view your items. If you’re smart you’re going to let the user view the items in different colors, sizes, and shapes [HandyShop View Item page]. You should let them view the item as part of an outfit, recommend things that go nicely with what your selling and if possible allow them to add that item to an “outfit”. To be fair this isn’t really something I thought up, a client that I worked with at my previous gig (I just switched gig’s for those of you who didn’t know) did a bunch of interesting things with this that could be improved with AJAX. The client is/was anthropologie.com. Go take a look at their “Create a look” functionality. When viewing a given item they show related items that make up a “look”. Although we didn’t really use AJAX we did have some client side script which feels a little AJAX’ish. In the right hand column is the upsell items for the item currently being viewed. Since the upsell item shown may not be something the user particularly likes they can view other items by clicking “previous” or “next”. This allows them to “shuffle through” the related items until they’re able to find something they like. Clicking on “Add to Outfit” doesn’t do anything AJAX’y but it sure would be cool if you could. I really like the idea of viewing items as an outfit, and I really like the idea of using AJAX to make it a very pleasant experience for the user.
The other feature that you can see on the Anthro site is the ability to view any item in different colors. Again not totally AJAX but a nice touch for a user visiting the site. Finally providing the visitor with different views (front, back, on a model) of your product with the ability to zoom, pan, and feel your product are nice features that could benefit from AJAX as well.
Ok, now let’s jump back to summary/category pages. On any summary pages such as this page on HandyShop, AJAX should be used to allow the user to sort, filter, and group items. It’d be cool if on a category/summary page the user could start hiding items. Clicking a “remove” could “fly” the item over the the right “waiting area”. Then the user could slowly filter the items down to the items they’re interested in. Another cool feature would be the ability to filter items in a summary page using AJAX. Imagine having a color, or price filter at the top of the page I linked to above. As the user works his way through the filters the items in the list could slowly be filtered down using AJAX. Then if you could view the items side by side, again with lots of AJAX thrown in, you’d be in the money!
So anyway I think a shopping site could definitely use AJAX in a lot of interesting ways to display items, allow the user to select alternate colors and sizes to view, as well as present upsell and cross sell items. Additionally the upsell and cross sell items should be able to be added to the current view so visitors can see items together to decide if they should buy it all, or just a single item. Provide them with interesting ways of sorting and filtering category pages, and allow them to work their way through the items in a way that allows them to find just what they want.
After the user’s viewing an item they should be able to add an item to the cart. They should then be able to update the cart’s contents again with some superdy duperdy snazzy AJAX functionality. The entire “cart experience” should be done using AJAX to help ensure the user doesn’t get frustrated with all our posts backs and bail.
Since the demo Handy Shop doesn’t have too many other areas within it other then displaying items lets move on to checkout. As I stated just above I think working with the shopping cart should be done using ajax. It’d be nice if a user could hover over an item to view a preview image of the product they have in their cart (in case they forgot). Integrating cross sell and upsells directly into the cart view with the ability to add those items to the cart could definitely help increase sales as well. Other minor things that the current checkout does via postbacks that I think should be done client side are:
– Selecting to use your billing address as your shipping address
– Updating quantities and recalculating totals
Although HandyShop doesn’t have very many steps during checkout I think using AJAX to step the user through the checkout process could be something that would be well received by users. Often times retailers force us to step through a 4–5 step process with annoying page refreshes in between. Side note: isn’t it funny that now that we have this super new “cool” technology it so easy to being being picky about the things we’ve been accepting as a fact of life for so long? Ok, back on topic. So by making the checkout process a single screen with various panels and inputs being hidden and shown and necessary data being sent back using AJAX I think we could create a checkout experience that customers would come back too time and time again.
Anyway, I’m sure I could ramble on for a little while longer but I think it’s best if I stop now. It’s amazing how when you’re procrastinating you can find time to ramble on about things such as how to improve a store with AJAX.
In summary…
AJAX is cool. Making money from an online shop is cool. Making MORE money from an online shop because of excellent use of AJAX is the coolest. 
This is one of those annoying blog posts that someone (never me) makes when they want to remember to read something that sounds very interesting or relevant to things they’re working on.
One of the things I’m going to have to think about at some point on my “current project” is how we can make the UI customizable and extensible. John deVadoss’ has an article on the Architecture Resource Center that aims to address this requirement, called “Metadata-Driven User Interfaces”. I haven’t actually read the article as of yet (only skimmed) so if it ends up being lousy feel free to send whatever kind of flame’s you can think up to my inbox.
Martin Fowler has a post about how closures positively impact the overall development experience when using collections in Smalltalk. When I first came across some of the “closure” support in C# 2.0 I was pretty excited that such a revolutionary concept had been included in my language of choice. It didn’t take long for me to realize that closures were something that smalltalkers, rubyists, and pythonites had been using for a long time. Regardless they’re a very useful language feature that I find myself using a lot.
Below are some of my posts related to the topic:
I’ve recently been dropping in on various people in the industry to get their thoughts on the best way to build distributed systems (SOA if you will) using today’s technology. I threw in the wrinkle that performance was very high on the importance scale.
When we start talking about performance people usually begin to shy away from web services, as I did, how