Heres to 2017... and to New Beginnings

Ok, I'll admit it, I am a procastinator. Even though I have the best of intentions at times, I still find myself battling the desire to learn versus actually doing the work, and when you are a husband and father it can be easy to play the Dad card. Additionally, when the technology you have come to learn and love has largely remained unchanged, you can hit a comfort zone where there is seemingly no real "need" to grow. (This seems to be a real epidemic in the enterprise dev space unfortunately) However, as a new year has dawned I am finding myself feeling mentally renewed and ready to start taking on some of the more significant technical challenges I see before me since I last wrote an entry to this blog. (Yes it really has been going on 6 years!) Topics such as cloud computing, data science, mobile and responsive/progressive web design are at the forefront of my mind these days, and I figure if sharing my experiences of diving into these topics can help others then that is a way I can contribute some small portion to those that have helped me over the years.

Heading into the coming months I am hoping to touch on a number of topics, each of which are either highly relevant to what I do on a daily basis as an enterprise developer or an area of interest of mine that I think would be interesting to research. With this though I do want to clarify that I am not going to be presenting these posts as some sort of authoritative piece, where I spend hours or days performing research and writing a small thesis. I've found that to be one of the primary reasons I avoided blogging for so long as well. What I will do though is my due diligence and try to not serve as one of the many echo chambers on the web and provide my own unique insight into my situation and how the technology applies. My intention with this blog is and always has been to share my experiences and hopefully serve as a way to help others in similar situations or provide a place for discussion.

Now, enough of the banter and on to the blogging. I wish everyone a healthy and prosperous new year and look forward to providing some fresh new content this week.

Dipping a Toe in the Backbone Pool.

Over the last couple months my endeavors in the Web application world, both personal and professional, would have one common denominator - a lot of moving client side parts (code). With this, I knew I wasn't the first or last person to encounter the same code maintability/readability/organization obstacle so I ventured out on to see what was available and also relatively painless to ramp up on..... enter Document Cloud's Backbone.js framework. Backbone is a javascript library (built on top of Underscore.js and jQuery) meant to give some MVC structure to the otherwise Wild Wild West world of client side development. In skimming their documentation I could grasp immediately where the authors were going with it and how intuitive it was. That's not to say there isn't a learning curve but it's one of those that is well worth getting over, in my opinion.

Like anything, once you get a firm grasp of the overall framework the advanced operations kind of fall into place. There are useful resources out there written by developers in the community on advanced usage. That said, there were some pain points I encountered that made bridging the gap from rookie to novice a little challenging. With that in mind I set out to write up a sample app that would help me get over the hump. So for this entry I will dissect the included example and highlight the important stuff.



The apps purpose is simple - load a collection of items to an unordered list at run time and allow the users to add items of their own dynamically. All wired with click events to be toggled with a gray background to indicate selected and white background to indicate not selected.

NOTE: I suggest touring through the Fiddle a bit and understanding how things before continuing below. Loading it in another tab to flip back and forth to while continuing might also be beneficial.

Models
Model extensions are essentially representations of our data that we will be retrieving from our data tier and working with on the presentation layer. For this example we only have one model:

Item model - the Item model only has 2 properties (name and ordinal) and were are configuring their respective defaults. These will map seamlessly with a JSON data set, which we will see later.

Collections

Collections are, simply put, collections of Models.

ItemList - A basic instance of a collection that will contain Item models.


Views
Views are really what organizes and drives your interface; this is where you start modularizing everything. How you do this is entirely up to you, basically any element (be it the overall containing or any element somewhere in a list) on a page can be represented by a View. Once you work with Backbone a bit, you get a better feel for how to modularize your View logic.

ItemEntryView - This view will handle the user interactions with the textbox and "Add" button at the top of the page.



Notables:

el: Those familiar with jQuery the $(‘.itemEntry’) will look familiar. Here I am specifying the selector for the element (hence, el) on the page that an instance of ItemEntryView will control.

ItemView - This view will control any "Item" element that is added to the ItemsView.



Notables:

• className: Kind of self explanatory; this is the CSS class that will be added to the element that contains the views contents. In this case it would be "item".
• tagName: Since this view is dynamically generated, you may want to specify what kind of element will contain the views contents. In this case, I have an li element specified so these views will be output as ‹li>. *content here* ‹/li>.
  
• events: The events array is a shorthand way to let you wire up events for the view. I only have one event setup for when the view is clicked it will call the "toggle" function. Simple as that and Backbone takes care of the rest.

When new views are added or updated after the initial page load, the events are attached to them (think jQuery live/delegate).

ItemsView - The view that will manage all of the ItemView instances added to the .items container.


Notables:

• collection: Here we are essentially specifying a collection that the ItemsView will “listen” to and give context to the view when collection is referenced in other methods.
• initialize: The constructor of a View that is called when a ItemsView is invoked. Just specifying the collection property will give you context, in order to stay in sync with the collection we bind any resets and adds to the collection with callbacks to the render and add methods, respectively. Simply put, any time a reset/add is called on the collection (outside of this view) the render/add method for this view will be called; that way the UI stays in sync with the data. This is where the meat and potatoes of Backbone really start to show themselves.
  

AppView - This is the page level controller that manages/sets up all of the views within the page.

Conclusion

Still some confusion? Here's a visual:

Hopefully this mess all offers another helpful look at this framework and helps someone out looking to learn up on it. There is a lot of useful functionality in this library so I am still learning the ins and outs and working it into apps, when practical.

P.S. While Backbone definitely helps alleviate a lot of typing, applications can still produce a significant amount of code. Managing that on an enterprise level would be a whole other post.
To help get an idea on how to properly arrange things I suggest taking a look at this tutorial.

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.