Monthly Archives: April 2016

Design patterns: Iterator and Strategy

Was looking at the “strategy” and “iterator” patterns today. They are both operational/behavioral patterns, which makes them different from the creational patterns like the Factory Method, for instance. What’s interesting is that they might not be that different when it comes to the implementation. It’s the usage which makes them different.

Strategy pattern is about having different ways of doing something. Factory Method is about having different ways of creating something. From this standpoint, it seems that factory method is just a specialized strategy pattern.

Either way, back to the normal-world examples..

What’s the iterator? It’s, basically, something or someone who you can ask for the next available item in a set of items, and who can give you access to all those items in the set. In that sense, a waitress in the restaurant will be iterating through your meal choices as you are having a five course meal, for example.

What’s the strategy? First of all, I’m wondering if it’s the right word for this pattern since it’s not necessarily the “strategy” we are talking about – sometimes it looks more like a tactic. However, the idea is that you may have different ways of doing something. For example, if you wanted to move to another house, you would have at least a couple of choices: you could do it yourself, or you could hire somebody to do it for you. Those would be your “strategies” as far as relocation is concerned. They are both about moving, but they assume different implementations.

Dynamics CRM – there are still things to discover

Yesterday, my fellow Dynamics CRM consultant Natalia Shlega who I talk a lot to (the main reason being not so much the fact that she’s a CRM consultant, though that does contribute.. but, rather, the fact that we happened to be married) pointed me to an article describing status reason transitions in Dynamics CRM.

What surprised me is that I’ve never seen it before even though I do customize CRM every day, and, yet, it has been a few years since this feature made its appearance in CRM 2013.

So, for those of you who used to be in the trenches just like I did, here is a link:

The tricky part about this feature is that it’s sort of hidden in CRM. By the time you get to those far (not necessarily dark) corners of Dynamics CRM application, you usually know what you are doing and why, so you just want to have it done and you are not paying attention to anything else. That probably explains why there turned out to be a function which has been sitting there for a few years, yet I have not noticed it even once.

And the moral? Well, I guess it’s good to have proved, once again, that Dynamics still has secrets to discover. That’s what makes it interesting.

Alex St. John thoughts on game development: Art vs Labor

There was a controversial article by Alex St. John last week where he went on saying that game developers should be prepared to work 80 hours per week, presumably not compensated for those extra 40 hours. This article was mentioned in my CodeProject subscription – that`s how I happened to find it. But here is a link in case you have not seen it yet:

With all due respect to the people involved in game development (and to all other IT people working unpaid overtime), I feel the problem is deeper than simply counting the hours we get paid for.

Did you ever want to finish something so badly that you had to stay through the night to get it done? I am not talking about paid work only – it could be anything.. might as well be a hobby project. That happened to me quite a few times, and I have to say it does feel different when you keep pushing till it’s finally done. It is, probably, somewhat similar to how athletes approach their competitions – there is no way a long-distance runner can take a break having run half the distance. It is all or nothing, and it is now or never.

If you succeed, you get that great feeling of accomplishment, and you actually become proud of yourself. But those positive feelings only happen if you do want to do what you are doing – if, instead, you are just “made” to work late.. nothing but frustration happens as a result.

So, getting back to St. John’s article. He calls game development an art. That’s probably his way of saying that one comes to work to stay there for a number of hours, but one has to treat art in a totally different way – that’s not something that can be properly scheduled and delivered. It’s more like something that consumes the artist, and that’s the only way to create something that stands out.

Yes, I see why it does not work well being presented like that. Historically, art has never been the most profitable occupation for somebody willing to make a decent living. Yet it can difficult on one’s personal life. However, also historically, art has always been something people were fascinated with.

Hence, I am wondering if the reason why that article produced such a strong negative response is simply that, in our extremely politically correct world, it is dragging everyone back to the inconvenient basics: really great computer games are works of art. However, as it has always been, those involved in art making are, usually, underpaid. So it is, basically, you take it or leave it, since you can’t convert art into labor and expect the same results.

PS. Outside of the game development, the same idea may lead to a lot of interesting implications. Basically, what would have happened if all software development were treated as art?

Business Analysis: Reading BABOK

While reading BABOK, I came across the following requirements classification – what’s interesting, I worked with quite a few business analysts, however, many of them would not be able to clearly explain the difference between business requirements and functional requirements. The information below is for my reference, then. Not that it becomes absolutely clear what the difference is after reading this, however, it it’s , at least, clear that there is some.

Business Requirements

Statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative

Stakeholder Requirements

Describe the needs of stakeholders that must be met in order to achieve the business requirements. They may service as a bridge between business and solution requirements.

Solution Requirements

Describe the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution. Solution requirements can be divided into  two sub-categories:

– Functional requirements: describe the capabilities that a solution must have in terms of the behavior and information that the solution will manage, and

– Non-functional requirements or quality of service requirements: do not relate directly to the behavior of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have

Transition Requirements

Describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirement types because they are of a temporary nature. Transition requirements address topics such as data conversion, training, and business continuity.

Visionaries – who are they

There are people who inspire, who seem to know what they are doing, and in whose presence you start seeing the picture. We call them visionaries.

Somehow, I was wondering what differentiates visionary people from others. And, then, I realized that, while talking about this quality of the human beings, we often use it in an almost magical sense. Although, in general, we call “visionaries” those who can see the big picture and connect the dots for others without necessarily going into the smaller details. And, as that vision is applied/implemented, the smaller details get organized better.

Here is a problem, though.. Humans’ capacity to understand things is somewhat limited. Yet, as we start getting into the details of something, it becomes more and more complicated to understand and communicate those intricacies to the others. That’s just simple logic – if you want to understand and explain the details, you have to spend much more time than if you only wanted to communicate the big picture.

What is the big picture, though? It depends on the perspective. For an electrician bothered with the details of how all those wires are organized in your house, the big picture might include all the electrical equipment located throughout the house. However, for somebody concerned with the efficiency of the power grid, those details would be absolutely irrelevant. Everyone has their own big picture and everyone is concerned with their own level of details.

Naturally, then, those who are concerned with the higher level of details might be considered “visionaries” by those who have to look at the underlying level of details.

In case of the electrician above, a person who’d be talking about standardizing electrical equipment locations in the houses might be considered a visionary by the electricians in the sense that, as their vision gets applied, the wiring becomes more predictable/better organized for the electricians.

In other words, I wonder if this whole situation can be presented like this:



At the top of the pyramid chart, there would be people who are least concerned with the details. They are working with the really big picture. The number of people at the top level is not even comparable with the number of people at the bottom of the pyramid where everyone is concerned with the smallest details.

So, the “area” of each level of this pyramid represents the number of people there. And, at the same time, it represents the “zoom” level.. In other words, the area is also representative of the level of details. As you are getting more and more details at the lower levels, you need more and more people to work with those details since it becomes more and more difficult to handle them. On the other hand, as you are getting up the pyramid, you need less people since there are less details.

And there is yet another conclusion this chart might communicate. As you keep moving between those levels, it is possible that the level of details becomes so different that people positioned at the different levels can’t understand each other anymore. In the sense that they are normally concerned with the details which are only remotely relevant at that point. In other words, to consider somebody a visionary, one still has to have some appreciation for the details the visionary is talking about, so both persons may have to be not that far apart on the pyramid chart.

PS. I’m not implying this is a 100% accurate interpretation.. or an accurate interpretation at all.. but it does put those things in perspective for me and makes them a little less magical, at least.

Dynamics CRM: Adding a filter to the lookup

Here is a short code sample on how to add a pre-search filter to the lookup

function onLoad()
Xrm.Page.getControl(…).addPreSearch(function () { addPreSearchFilter(); });

function addPreSearchFilter()

var filter = “<filter type=’and’>” +
“<condition attribute=’…’ operator=’not-null’/>” +


Design patterns in the real life: abstract factory and factory method

There are two design patterns which are called “factory” patterns: factory method and abstract factory. They are called factories because they produce something. The interesting thing is that there are other creational design patters which are called differenctly, but they still produce something, so, just following this logic, all those patterns could be called factories.

The devil is, as always, in the details. Singleton is focused on the ability to reuse the same object. Prototype is focused on the ability to create a copy of an object. Factory patterns are focused on the mass production of new objects.

Still, what would be the real-life analogy for the abstract factory?

We are talking about the facility that can produce families of objects. It seems, this is what restaurants do.. Restaurants can produce breakfasts, launches, and dinners. What exactly you get for launch depends on which restaurant you go to. Those are the keys in this pattern:

– There is a client (you)
– The client is provided with a concrete implementation of the abstract factory (that particular restaurant around the corner)
– The client knows that that particular factory can produce objects of specific type (you can order breakfast, lunch, or dinner in that restaurant)

What’s the difference from the abstract method pattern? There seem to be quite a bit of overlap in these two, however, where abstract factory is less specialized and can create many different things, abstract method is all about creating different versions of the same. In the example with the restaurants above, we would be talking about those restaurants that can serve lunch only. So, we would come in and say “I want launch special”. And, depending on the restaurant, we would get a particular version of that lunch.

Handling N:N relationships in Dynamics CRM plugins

Here is a quick and dirty example of how a plugin could be created to handle N:N associations. A plugin like this would need to be registered for the “Associate” message of “any” entity:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Microsoft.Xrm.Sdk.Client;
using Microsoft.Xrm.Sdk;

public void Execute(IServiceProvider serviceProvider)
  IPluginExecutionContext context = (IPluginExecutionContext)
 if (context.InputParameters.Contains(“Target”) &&
     context.InputParameters[“Target”] is EntityReference &&
     ((EntityReference)context.InputParameters[“Target”]).LogicalName == YOUR_ENTITY_NAME)
   if (context.InputParameters.Contains(“Relationship”))
      Relationship relationship = (Relationship)context.InputParameters[“Relationship”];
      if (relationship.SchemaName != YOUR_RELATIONSHIP_SCHEMA_NAME) { return; }

      EntityReferenceCollection re = (EntityReferenceCollection)context.InputParameters[“RelatedEntities”];




So, why is XRM awesome?

Don’t get me wrong, I’m not going to say that XRM is flawless and/or that it fits anything and anyone. Not at all actually. If you gave me 15 minutes, I could keep complaining about missing XRM features for all that time.

However, what I’m going to say is that, with the proper application of XRM customizations, Dynamics CRM can be tweaked to cover almost any business needs. As far as server-side customizations are concerned, XRM really allows you to do almost anything with the data that’s being passed back and forth between the user and the server.

XRM is not as advanced on the client side as it is on the server side, and that’s one reason there always used to be those “unsupported customizations” which any responsible consultant would at least point out to the client. However, it’s still quite advanced there. Not to mention that one can opt for a completely custom implementation of the specific piece of the client-side functionality and use an iframe to embed that additional piece into the existing CRM forms.

How does it all add up, though? Awesome, not awesome, too many customizations, not enough customizations..

In my view, it’s a matter of having proper functional fit-gap analysis done. Yet it has to be functional not in the “technological” sense, but, rather, in the business sense. It`s a little difficult to draw the line; however, what I mean is that all those XRM perks which come with Dynamics CRM, such as the ability to quickly create new entities and forms, are not primary business functions. They are a nice addition to the core functionality, that’s true, but, on their own, they will not cover required business scenarios.

In that sense, a fair statement might be: if CRM can cover significant amount of the functional business requirements out of the box, then it`s very likely going to be worth the efforts which will be put into the implementation before your CRM project goes live. And the reason XRM is awesome, in that sense, is that it will likely allow you to cover the rest of the requirements, as long as you are ready to invest into the implementation. Although, quite frankly, this is no different for any other off-the-shelf software.

And, then, the real proof of XRM awesomeness is this: there are succesfull implementations of Dynamics CRM which can hardly be considred CRM implementations at all. Those are completely custom applications with a lot of custom entities and with a lot of business logic implemented in the plugins/javascripts. Still, they are successful. Which proves the power of XRM. Whether it makes sense to take it that far is still a question, of course, but a different one.