Searchin' It Old School

In recent months I've grown increasingly distant for fielding any kind of random questions I may have rattling around in my head to Stackoverflow and instead electing to hit up the good ole trusty channels of IRC. Don't get me wrong, I still feel Stackoverflow is the best forum resource we have on the web and revolutionized how to organize and index the best programming intel. In my personal top 10 for best web layouts .... ever.

My gripe really lies in the degree of importance centered around the reputation system and more so the silly squabbles it creates for points. Since I rarely post there, if ever, its more of what I observe whenever I scan around. Its to the point where I've actually seen people tout their Stack rep on their resume or LinkedIn profile. I don't necessarily find anything wrong with that but it has caused the level of formality that goes into jumping in on a thread to be a bit much and god forbid suffer the dreaded down vote.

Anyways, I guess what I'm saying is that sometimes its kind of nice to interact with people in a way that doesn't seem so mercenary like and are just willing to help the greater good. That is where IRC comes in. I've recently taken an interest in learning up on Backbone.js outside of work and because of its relative infancy, I have frequented its development crew's channel (#documentcloud on freenode.net) and to field/answer questions. Its a nice change of pace to say the least and I find myself hopping into a number of other channels on other topics (#jquery, ##csharp, etc.). In the real world, how often do we meticulously plan a question to our peers? Yea, we do our due diligence before bugging others but you don't need to fuss about how well groomed your question/answer is. Sometimes you don't even really know the question and are just in the ball park and need to talk through it so maybe you then you know what to hit the Stack for.

So yea, a quick thought for anyone who has forgotten Internet Relay Chat and looking for an alternative to the SO. Something I've BGC'd with Travis quite a bit on and figured it was time to put some ink to it.

"and then I put on my robe and wizard hat...."

Why Your Objects Aren't Objects...

Objects…

The crux of Object-Oriented Programming, or OOP as it is commonly referred.

Odds are if you are programming in the year 2011, you have learned to build and rely on them to accomplish just about everything. It makes sense right, since we are modeling the real world, and the real world is filled with them. Its been around for quite a while, with OOP making its first major foray into the programmer vernacular back in the 1970s via the SmallTalk programming language. Terms like polymorphism, encapsulation, access modifiers, properties, methods and the like should be very familiar to you. Even the typical greenhorn developer fresh from school knows how objects are composed into classes, how to leverage an Animal base class to let other animals boast about how they eat, as well as the notion of an interface to specify contracts that classes can implement.

So the question becomes, how did they go from objects to bags of data??

A little confused by that question? Well, for sake of argument, lets consider the typical developer being a .NET developer. In the .NET space, where the pace of technology seems to go at break-neck speed, there exists a sea of developers seeking guidance on what the "best practices" are for building applications. Unfortunately, many developers, including myself at one point, looked no further than the vendor that provided their framework. While Microsoft's online documentation proves to be a valuable source of information, there is also a history of providing application guidance that has been less than savory we shall say.

The Standard Enterprise Application Architecture?

Take for instance the Three-Layered Services Application guidance, which in my experience has surfaced in every development team I have been a part of. On its surface, it appears a very reasonable approach to building an application, and I have even been a part of mainstream developer training where it was proposed as the a standard application architecture for enterprise applications. It teaches us that we should separate our presentation, business and data access logic into separate layers, in order to enforce separation of concerns, and shield higher layers from physical changes at lower levels. This architecture even proposes that there are certain cross-cutting concerns that are understood to transcend layers, which makes sense as well, as we all know that things such as logging information and exceptions are agnostic to application architecture. The following diagram comes from the guidance, which spells out much more concretely the approach.

It all looks and sounds pretty logical, and even the term business entity seems to make sense, as it seems to convey that we are dealing with entities (objects) that are related to the business (domain). Its not until you start to unravel what the terms actually represent that it starts to break down. Coming directly from the guidance, it is stated that business entities

"... are data containers. They encapsulate and hide the details of specific data representation formats."

What about this definition sounds like an object? To be honest, not much besides perhaps stretching to say that the fields/properties of the data container represent attributes of objects in your business domain. As fishy as it sounds trying to make this type of code structure fit into the definition of a true object, we find ourselves doing exactly this kind of thing all the time.

So where did the behavior go?

In the three layer architecture, we are told that the behavior is really the "business logic", and that it belongs in its own container, labeled a business component. A business component is then defined as

"...the software realization of business concepts. They are the primary units of design, implementation, deployment, maintenance, and management for the life cycle of the business application. Business components encapsulate the business logic, also called business rules. These rules constrain the behavior of a business concept to match the needs of a particular company."

This coupled with the prior definition of the business entity clearly illustrate that there is a separation of behavior and state, which clearly does not line up with the notion of an object, the representation of both. While it is representing the notion of business entities, to Martin Fowler's point on anemic domain models, it is really doing nothing more than providing Data Transfer Object instances that are populated via Transaction Scripts. (for those with the P of EAA scorecards at home...) Its not to say that there is no value in the architecture at all, but what it does seem to promote is a departure from OOP back into more procedural programming. The very nature of a Transaction Script and DTO deviate dramatically from object-oriented design.

Therefore, a true object does not a business entity make...

Evaluating the Anemic Domain Model Pattern/Anti-Pattern

Even with the prevalence of OOP in modern programming, it definitely has its share of critics. Not just your standard run of the mill bloggers, but well-known researchers such as IBM's Chris Date and developers such as Richard Stallman (RMS). Just as there is criticism of OOP, there is also criticism for OOP-centric design patterns such as Domain Driven Design (DDD) that put heavy emphasis on building a core domain model that is centered around objects in the purest sense.

Greg Young points out in a blog post concerning this subject that there are indeed cases that seem to be a perfect fit for a model devoid of the complexities of a true domain model. Among his points, Greg brings to light some of the all-too-real issues that are present in a lot of "enterprise" apps:

• The domain we are modeling is inherently simple
• The OOP skills of the team members are lacking or not substantial enough to support a true domain model
• The non-functional benefits of the layered architecture are necessary

The problem I have with these points is the fact that they are pretty much true, despite what I would like to believe about development and architecture in general. As a developer who seeks to continually improve, and build applications on architectures that scale for tomorrow, it is disheartening to see a project take what may be a less valuable approach because of the risk of doing it in what might just be the "right way". However, I really can't argue the fact that introducing a greater risk into the project at the cost of benefits that may not be realized in the short term seems foolish. Especially if the only immediate benefit is developer satisfaction at implementing a more exotic architecture at a point in time when it wasn't needed/justified. We all know or are a developer that wants to do the latest and greatest things in software engineering on our own projects.

The Takeaway

At the end of the day, the answer for the use of true objects versus an anemic domain model lies within the context of the application. Sometimes the nature of the business prevents you from having the exposure to domain experts that is required to support a true domain model. Other times, you don't have that restriction and the added complexity pays dividends in the establishment of a core domain model that is then able to be leveraged outside of its original application in many meaningful ways. Either way, requirements for both the application at hand and the handling of domain-specific logic beyond that project are the key indicators for the approach that works best.

In the time I've spent doing software development, I've seen far more cases where anemic domain models were the quicker route and lead to immediate results. However, I have also been negatively impacted by the specificity of the code that a Transaction Script-based approach leads to as enhancements come down the pipeline. A lot of help comes in the form of vision on the part of project stakeholders, and unfortunately, that really is outside of the developer's role. The knowledge the customer/stakeholder has on the domain at hand is too valuable to lose sight of by asking those without vision to postulate on the future. That is about as useful as estimates on development tasks involving details you've never reviewed; its a shot in the dark at best.

Next time you go to create an object, realize that all may not be as it seems. The question you must ask yourself is, what is the impact on the application due to the way I'm implementing objects? Hopefully this post has helped to both explain why you may not be implementing objects completely, as well as what the ramifications are based on whether or not the objects you implement are considered true entities, or DTOs.

jQuery UI and you. (Part 1 of 2)

Well, I had a number of potential first post topics listed out and am deciding to go with the most topical at the moment. For my post I won't be revolutionizing the game with something cutting edge but rather discussing an interface framework I've grown more and more fond of over time. If it wasn't immediately evident from the subject, that framework is jQuery UI.

To know jQuery UI, you need to know what jQuery is. At its simplest, jQuery is a Javascript API that you can bolt into any web application/site that will make your (client side programming) life infinitely easier/better. jQuery not only simplifies standard client side programming but it also makes advanced things like effects and animations much easier to achieve. With all it can do and for how lightweight it is, jQuery is quickly (if not already) replacing Flash as the go to for advanced front end effects. This is old news for most devs but there are still a great deal of people to live in the server side world only or only know what college told them to know.

The High Level
jQuery UI ( jUI ) is basically an interface widget framework that is just additional extension on top of jQuery. It offers a lot of effects and controls (buttons, calendar, sliders, drag-n-drop, etc.) that are now common place on the web in addition to some newer concepts which can be implemented easily into your front end code. They take care of the basic core functionality so, if necessary, you can focus on addressing user interactions. Additionally, all HTML elements in all of the widgets are driven by a single style sheet that is inheritance driven so it really makes changes easy to implement globally.

This sounds a lot like ASP.NET themes but is on the complete other side of the spectrum. They are roughly the same idea but jUI lets you off road a bit more and style every component of your application as one cohesive unit and not just buttons, text boxes, etc.

Keep a Programmer Programming
Personally, I like working in Photoshop and building concepts/graphics - always have. However, I am quickly learning that I am in the minority in this area as programmers tend to be more inclined to have those responsibilities be delegated to a “legit” designer and just worry about the middle tier and punch out. Sometimes you have no choice. No matter how much I enjoy it though, tasks like making icons and small graphics is tedious/time consuming and there are tons of packages available that are probably better for such a simple task. That’s where jUI comes in handy. They offer a built in icon set for all of the standard (and some advanced) actions a user might need to perform. In their typical baller style, their dev team provides all of the icons in one lightweight image and uses CSS Spriting to determine which is displayed.

What’s that all mean? Colors, icons, width, etc. are all dictated by CSS classes applied to HTML elements which makes changes a code endeavor which is more up any programmer’s alley. No time fussing with in the 15x15 pixel world in Photoshop or PSPro.

Jazz Hands
One of my favorite aspects of the framework can be summed up in one word – ThemeRoller. The jUI people have been courteous enough to provide a customization tool that lets you tweak just about every aspect of your theme (background color, gradient styles, borders, hover styling, etc.) through a web app and then have it all packaged up to be deployed into your application within minutes. That way you can make your interface as loud or muted as you want. Client wishing they would have picked cornflower blue instead of sky blue last minute? Ain't no thang. Make the necessary changes in ThemeRoller and swap in the new CSS file. You can take it to the extent of providing them a link to the ‘Roller and let them tweak things until they are satisfied and just have them send you the link to the new theme when they are done so you can pull down the new CSS file. It’s simple as that.

.... and now its a made guy.
jQuery being bundled with Visual Studio 2010 was one of the notable additions to the IDE. Not notable because it made jQuery easier to implement (easier to use,maybe, with Intellisense), notable because the little open source framework got a nod from the Don. Fast forward to today, things have grown to the point where MVC3 is now tightly coupled with jQueryUI framework (quite well actually) to where developers can't help but leverage it to get the job done better/faster.


Side note - The script libraries Microsoft is including seems to be the final admission that "OK, we know MSAjax _might_ have sucked."..... and lets be honest, there is an UpdatePanel or two all of us would like to take back.

Wrap Up
Before this all comes off as a fan boy material (too late!) I will admit, if you are relatively new to the UI/Client side of things there is a bit of a learning curve with jQuery and its UI extension. Additionally, out of the box, these are straight forward web components so that means you'll be wiring up your own postbacks, hombre. Which also creates another obstacle in maintaining/recovering state. So there in lies the lead in to my next installment. MVC lets you architect a lot of this in a pretty seamless manner but for the rest of us that don't have clients/companies that are willing to drop the clams on VS 2010 I'll be piecing together some basic .NET wrappers to get you going in the right direction (or at least what I think is the right direction). Alright, that's all, the gardener has gardened all day and doesn't want to mow his own lawn anymore. I hope to have Part 2 done with the next couple weeks with some other posts sprinkled in between.

... and so it begins.

A couple weeks ago, the authors of CVCode started talking about the gap in a .NET community that is along the I-81 corridor, south of Harrisburg/Mechanicsburg. As we are finding out, a good number of Software Engineers exist in the area but nothing that really showcases the efforts/talents of its residents. From that, the idea for Cumberland Valley Code was born. Collectively we feel we have a wide variety of professional experience and an interesting arsenal of topics to get this thing started. That said, we will be leaving our agenda open to reader feedback so we can change gears accordingly.

Our focus?

To start, we will be geared towards current technologies so we can dig into some of the things that we all may not normally get exposure to on the daily. This means researching, debating and gaining useful experience in emerging tools, technologies and development practices that foster a culture of software craftsmanship.

Our goal?

We are hoping that enough interest gets generated as more articles get published over the coming months that this reaches the global development community for feedback and could also help generate enough local interest to spawn a Users Group in the area.