MVVM Smack Down Videos Now Online
12
Dec
In November myself and some friends presented an “MVVM Smack Down” at the North Texas Silverlight User Group. We did a head to head comparison of Prism 4, The MVVM Light toolkit, Caliburn Micro, and Jounce. It was presented with a bit of friendly banter and was meant really to enlighten, compare, and contrast more than to judge the various frameworks.
The videos are available here:
- Tim Jones presenting Prism V4
- David Yancey presenting Jounce
- Bonas Khanal presenting MVVM Light
- Justin Weinberg (yours truly) presenting Caliburn Micro
For many of us this was our first technical presentation in front of a public audience. There was areas for improvement and I didn’t have as much time as I would have liked, but I think all things considered it went fairly well.
I also wanted to give a special thanks to Shawn Weisfeld for recording the sessions for INETA (and all the sessions he records).
Code and Slides from Introduction to Silverlight Talk
11
Dec
This morning I gave a talk called “Introduction to Silverlight” at the North Texas PC User Group.
I had a great time giving this talk. Silverlight is the most fun technology Microsoft has created (Well, after the Xbox of course). I enjoy having the opportunity to share that fun with others.
Get the codes and slides here: Intro to Silverlight.12.11.2010.zip
Windows 7 Phone Launch Event
10
Oct
On October 20th and 21st I’m pleased to announce I’ll be assisting my fellow developers at the sold out 
Microsoft Windows Phone 7 Jump Start event. I really love taking part in opportunities like this because I find teaching and mentoring to be a most wonderful experience. There’s something wonderful about the moment when people really grasp a new concept. Windows Phone 7 is a potential game changer.
For developers, two of the most developer friendly technologies from Microsoft, Silverlight and XNA, are baked in and optimized for. Also, the Visual Studio tooling for Windows Phone 7 development is a joy to work with. While there are new concepts to understand such as tombstoning, live tiles, notifications,etc, current investments in Silverlight development pay off big on this platform. Speaking of Silverlight, is anyone else impressed that Microsoft elected to use Silverlight for their Windows Phone 7 landing page?
Founding of The North Texas Silverlight User Group
08
Oct
I’ve been meaning to post this for awhile.
A couple of guys at Sogeti and Broadlane (including yours truly) have formed the North Texas Silverlight user group! The response has been amazing. In less than three weeks we have gone from 0 to almost 40 attendees for the first meeting. We’ve also managed to wrangle two fantastic speakers, Caleb Jenkins and Teresa Burger for our first meeting. Caleb will be presenting on Windows Phone 7 “For World Domination” as the primary speaker for the first meeting. Knowing Caleb it’s bound to entertain. Teresa will be doing our first blend segment or “Blendlet” on grid splitters and handles in Microsoft Expression Blend.
Forming this group was in one sense much easier than I thought and in another much harder. What was easier than I thought is how willing people and companies are to help out. We needed money and our sponsors graciously agreed. We needed space at the last minute and Chris Koenig and Microsoft stepped up to the plate. We needed exposure and Teresa, Caleb, Shawn Weisfeld , and many others in the community retweeted and blogged on our behalf. The goodwill from everyone I interacted with during this process was heart warming.
The harder parts have been the little things that we as user group goers barely notice when done right. Getting food for 40, a space, security, swag, etc. is a more involved process that I would have thought. I bet going forward we’ll get it down to a science though.
Wish us luck and we hope to see you there! For more information visit the group at www.ntsilverlight.com.
Socrates on SOLID: The Dependency Inversion Principle
15
Aug
This is the sixth and final in a series of (hopefully) amusing posts into Robert Martin’s SOLID principles. It’s written as a dialog between Socrates and a student named Loej in the spirit of the dialectic method popularized by Plato. In this post, the principle explored is the “Dependency Inversion Principle”. I hope you find this enjoyable.
Socrates, who is the narrator of the dialogue.
Loej, who is but novice at the master’s feet.
Socrates: Here we are then. Do you recall what we discussed last time?
Loej: Yes the interface segregation principle.
Socrates: And what did this principle encourage?
Loej: It encourages dividing up interfaces so that, in general, each client gets its own interface.
Socrates: Very good. Today we discuss the last of Robert Martin’s SOLID principle, the Dependency Inversion principle.
Loej: I think he must be quite avuncular for giving us all this insight.
Socrates: Indeed. Anyway, the dependency inversion principle is perhaps the most counterintuitive of all of the SOLID principles.
Loej: Yeah it sounds like standing on your head while coding.
Socrates: Making the comprehension curve steeper is that this principle has taken on a life of its own. It has become a focal point for advocates of dependency injection and inversion of control containers. But these are not fundamental to the idea of dependency inversion.
Loej: So what is dependency inversion?
Socrates: According to Robert Martin, dependency inversion is a two part concept. First, high level modules should not depend upon low level modules. Rather, both should depend upon abstractions. Second, abstractions should not depend on details. Details should depend upon abstractions.
Loej: Wait please. One brain overload at a time. What is a high level module?
Socrates: Well, at the time Robert Martin’s original SOLID articles were written, a software movement called Structured Analysis and Design was becoming entrenched in software development.
Loej: You do realize that abbreviates to SAD.
Socrates: Indeed, and it was a bit sad. At that time we lost site of the code.
Loej: How so?
Socrates: Senior software staff were encouraged to stop coding and start architecting. Their job consisted of diagramming software processes at a high level and then exploding them into lower levels. In SAD, high level modules were defined by lower level modules ad nauseam. Abstractions were cut into pieces until defined by the gritty details.
Loej: Isn’t that what we have been taught by schools and almost all books? Haven’t we all been taught to think of software as smushing small bits into classes to create abstractions?
Socrates: Yes and we need to understand programming at that level, the concrete implementation level. But many of us stop when we can create an abstracted program from concrete parts. This is a natural stopping point, because this is the first time the code “works”.
Loej: But if it works, it works, right?
Socrates: What you really mean is that it works right now. Are you familiar with Ward Cunningham’s concept of technical debt?
Loej: You mean the second mortgage I took on my house to buy an MSDN Ultimate subscription?
Socrates: It’s the future pain we accrue with interest for doing things quick and dirty now. Have you ever cut corners for speed when a deadline was looming?
Loej: Sure. I think we all have.
Socrates: What usually happens?
Loej: We wind up having more defects or more trouble making changes down the rode.
Socrates: That’s technical debt, and unfortunately sometimes our frameworks encourage it. The last time you had to change your code to accommodate a new framework technology, what was it like?
Loej: It was like pulling weeds throughout the entire codebase.
Socrates: What if instead of composing classes from framework bits you composed them from abstractions?
Loej: Sure, but at some point you have to tie into the specifics.
Socrates: But you choose how and where you tie into the specifics. Can you strive to avoid having abstractions take unreasonable dependencies?
Loej: Sometimes the framework or specific technology dictates it though.
Socrates: True enough. Martin Fowler presented the idea of code smells when looking at target code for refactoring. I propose a similar idea when considering using a new .NET framework technology – a framework taste.
Loej: You’ve got to be kidding.
Socrates: I’m not. Do you like diet soda?
Loej: Sure. It was an acquired taste though.
Socrates: Diet soda tastes good after the first sip but leaves a bad aftertaste. You can get used to that though if you stick at it.
Loej: What does this have to to with .NET?
Socrates: Many .NET framework technologies are like that diet soda. They demo well but you know fundamentally it’s pretty nasty stuff. Still, if you stick with it, no matter how bad it is, you learn to love it.
Loej: That’s kind of funny.
Socrates: Now how about a fine Scotch? What did it taste like when you were a kid?
Loej: Horrible. Like a shag carpet
Socrates: Exactly. It was too complex a flavor. You had to grow into the nuances. Unlike the soda, you didn’t lean to tolerate it, you learned to appreciate it with maturity. Good framework technologies are like that.
Loej: I think we’ve totally lost site of dependency inversion.
Socrates: What I am getting at is that some technologies encourage SOLID principles and minimize technical debt. They help you fall into the “pit of success” Others heap on the technical debt with each new line of code. In regards to the dependency inversion principle, look for technology and patterns that helps you minimize dependencies and help you build self defining abstractions.
Loej: Well this has all certainly been insightful. Thank you master!
Socrates: Indeed. I hope you have found the SOLID principles a good starting point for thinking about software design. For more information check out the Los Techies, Code Better or the place it all started at, Object mentor. Until next time, remember to keep your code SOLID!
Socrates on SOLID: The Interface Segregation Principle
23
Dec
This is the fifth in a series of (hopefully) amusing posts into Robert Martin’s SOLID principles. It’s written as a dialog between Socrates and a student named Loej in the spirit of the dialectic method popularized by Plato. In this post, the principle explored is the “The Interface Segregation Principle”. I hope you find this enjoyable.
Socrates, who is the narrator of the dialogue.
Loej, who is but a blink of data in the maelstrom of the Net.
Socrates: We have we made great progress in our understanding of the SOLID principles. So far we have discussed the Single Responsibility Principle, the Open/Closed Principle and the Liskov Substitution Principle. Do you recall what each of these mean?
Loej: Yes. The Single Responsibility Principle says that a software entity should have only a single responsibility. Robert Martin further clarified this to mean that a class should have only one reason to change.
Socrates: Nicely stated. And the Open/Closed principle?
Loej: Easy enough. Software entities should be open to extension and closed for modification.
Socrates: And the Liskov substitution principle?
Loej: The Liskov substitution principle…
Socrates: Yes?
Loej: It said something about sets and subsets.
Socrates; Right. But what did we infer from it?
Loej: Oh. A consumer of a base class should remain ignorant of its subclasses.
Socrates: Great. Did we get a bit more from it?
Loej: Right. It says that descendants shouldn’t dictate the behavior of their parents.
Socrates: And also?
Loej: A descendant should guarantee the behavior of its parents or it shouldn’t inherit from it.
Socrates: Precisely! Another way to state the entire thing is that the the preconditions of a derived class routine must be the same or weaker to the base class and the post conditions of a derived class routine must be the same or stronger than the base class.
Loej: Uh.. I’ll take your word on that one.
Socrates:Today we discuss the I in solid, the Interface Segregation principle.
Loej: Ok. What does that mean?
Socrates: The interface segregation principle says that clients should not be forced to depend upon interfaces that they do not use.
Loej: Well that seems straightforward enough to enforce.
Socrates: Well it is now and it’s so fundamental in .NET today thanks to Interfaces it is often an afterthought. But originally Robert Martin had to use multiple inheritance to support it.
Loej: How is that? I heard multiple inheritance is bad.
Socrates: C++ doesn’t have interfaces as a language feature, so if you want to support more than one abstract interface without mucking up your inheritance hierarchy, you need to use it.
Loej: And in Java and C# we use interfaces?
Socrates: Exactly. If we follow the advice to the letter, almost every client should have its own custom interface.
Loej: Well, the benefits seem obvious.
Socrates: There’s another benefit Robert Martin didn’t discuss. Let me ask you, how many things can you keep in your head at once?
Loej: 7 +/- 2. I’ve heard that statistic a number of places.
Socrates: What if I told you you could remember much more than 7 +/- 2?
Loej: How so?
Socrates: By a process cognitive scientists call “chunking”. Try to remember these letters. A, M, T, I, F, A, N, S, L, H, P, C…
Loej: I’m already lost. I told you, I can only do about seven letters.
Socrates: But what about these letters? AAPL, MSFT, INTC
Loej: Oh I recognize those. Those are the stock symbols for Apple, Microsoft, and Intel.
Socrates: Did you know the second group had the same exact letters as the first group?
Loej: Really?
Socrates: Indeed. But you remembered the second group much easier. Why is that?
Loej: Because they were put together into meaningful stock symbols. I recognize those.
Socrates: And the first?
Loej: A tangled mess of letters. But what does this have to do with this principle?
Socrates: When interfaces are more targeted, they chunk more naturally. Similar to how the Single responsibility principle focuses each software entity to a specific purpose, so the interface segregation principle focuses each interface to a specific purpose, typically one per client.
Loej: I see. Like grouping the letters into stock symbols. I can see the benefit . It’s much easier to deal with small simple things than large things.
Socrates: Yes. But for the record, of all the SOLID principles, I am most dubious of this one.
Loej: Didn’t you just spend the last five minutes convincing me of this principle? What gives?
Socrates: I believe this principle is slightly misguided. To split up large interfaces into small ones always will achieve looser coupling, but high cohesion is a different matter. There is no guarantee of high cohesion. For example. Are these groups of letters easier to grasp than the random letters? AMTI FANS LHPC.
Loej: Not really, no.
Socrates: And yet they have been segregated into groups of the same size – 4 each.
Loej: But if you are really dividing up an interface based on client needs it wouldn’t be so arbitrary.
Socrates: True, this is contrived. But why should client dependencies dictate your design any more than other aspects?
Loej: What do you mean?
Socrates: In a domain driven design, quality interfaces are a natural aspect of the system. To segregate interfaces by client technology without the domain driving the process seems unnecessarily technical.
Loej: I see.
Socrates: One more to go Loej! until next time!
Socrates on Solid: The Liskov Substitution Principle
22
Dec
This is the fourth in a series of (hopefully) amusing posts into Robert Martin’s SOLID principles. It’s written as a dialog between Socrates and a student named Loej in the spirit of the dialectic method popularized by Plato. In this post, the principle explored is the “Liskov Substitution Principle”. I hope you find this enjoyable.
Socrates, who is the narrator of the dialogue.
Loej, who is but a tiny minnow in a sea of 1′s and 0′s
Socrates: Welcome back Loej. Last time we discussed the Open / Closed principle.
Loej: Yes. We agreed that software entities should be open for extension but closed for modification. In .NET, careful use of Interfaces help us achieve this goal.
Socrates: Excellent. Today we will discuss the ‘L’ in Solid, the Liskov substitution principle.
Loej: Gazoontite.
Socrates: Huh?
Loej: Oh, I thought you sneezed.
Socrates: The Liskov substitution principle states that, if for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.
Loej: Got it.
Socrates: Really?
Loej: Yes. It makes perfect sense. Crystal clear. I think we’re done.
Socrates: Well what does it mean then?
Loej: It means that if for each o1 (mumble) such that (mumble mumble) the behavior of (mumble) and Q.E.D. Can I go now?
Socrates: But you just repeated what I said, more or less. Look this one is fairly straightforward.
Loej: Alright then. Let’s get on with it.
Socrates: According to Liskov if in all cases I can substitute type A for type B then A is a subset of B. So If I could substitute Circles, Rectangles, and Squares for…
Loej: Shapes?
Socrates: Or snakes, sharks, and monkeys for…
Loej: Politicians?
Socrates: I was thinking animals. But if I can substitute one for the other, then I have a subtype to type relationship.
Loej: But this is just basic tenant of object oriented programming. A Cat IS AN animal. A Circle IS A shape.
Socrates: So then anywhere I expect an animal, I should be able to pass a cat, or a brontosaurus, or any other animal?
Loej: Yes. A brontosaurus IS A dinosaur which IS AN animal. You can pass them to a function that takes animals without a problem. That’s a basic property of polymorphism. I don’t see anything terribly profound here.
Socrates: Well, there is an important corollary which can be derived from the Liskov principle. Anywhere code expects a base type, the program shouldn’t need to know it’s getting a derived type.
Loej: So if our function takes an Animal it shouldn’t need to know that it’s really getting a Cat? But why not?
Socrates: What would happen if we added a Dog type?
Loej: I see. We might find that we had to modify the function that took an Animal to update its behavior for the Cat type in case it overlaps with the Dog type.
Socrates: Right and this violates the Open/Closed principle. But there is one more serious problem. If our function takes an Animal and then interrogates its subtype to discover how to handle the animal, the base type has taken a dependency on its subtype!
Loej: That would be bad.
Socrates: There’s an even more subtle side to the Liskov substitution principle.
Loej: What’s that?
Socrates: Just as it would be incorrect for a subtype to dictate its parent’s behavior, it is incorrect to assign a subtype that cannot guarantee its parent behavior.
Loej: But that’s not possible with an IS A relationship, right?
Socrates: Actually Bob Martin’s paper on the Liskov substitution principle discusses this in depth. IS A doesn’t guarantee behavior of subtypes conform to base types. To really get inheritance right takes some deeper thought.
Loej: If I can’t depend on IS A what can I depend on?!?
Socrates: Well, usually IS A ‘IS A’ valid criterion. Most of the time two classes in an IS A relationship will have the same behavior as you move down the inheritance tree. But think before your inheriting. Make sure that behavior and constraints are enforceable down the tree.
Loej: Well I definitely have some thinking to do.
Socrates: Until next time my friend.
