Monday, December 28, 2015

Leadership: Gateway to a new YOU!

Lately, I've spent a lot of time reading up on leadership. I've been discussing the topic at length with friends, family, mentors and colleagues as well. It seems there is a few common threads that run through it all. And if you want to really be successful and happy in your life, you'd be better off to get this right.

Live by a core value system. Communicate with empathy. Build trust and by doing do so grow influence. Work together with others and delegate to maximize results.

Friday, December 18, 2015

Analyze, Trust, or Buy-In?

Do I really have to question everything? So I'm waiting at a train depot and of course there is a sign that advertises how much greener it is to ride the train than to drive a car on a daily commute. I'm going over-analytically submit a usual "it depends" sort of answer.

What might it depend on? much energy and what sources of energy are consumed with daily operations of the rail system? What is the waste of maintaining and building tracks vs roads? What is the total waste of producing and maintaining trains vs autos? What distance are you travelling? What additional energy and waste do you consume in your commute?

If we really want to prove the statement, we would have to analyze the data. Or we can just trust that the train company did this. Or perhaps some trusted analysis entity can verify the facts for us. I guess if I want to verify it I would either have to find a trusted authority (who knows if they really did a proper analysis), find data and do my own analysis (can I trust the data?), or just buy in.

Wednesday, December 16, 2015

The Importance of Understanding Expectations

A recent acquisition of a set of new chairs shed some light on how a solution can meet requirements while at the same time fall short of expectations. This caused that sudden realization to solidify in my gray matter. The upshot is that meeting requirements is a science while meeting expectations is an art. A friend, mentor and colleague has repeated so many times that software development is as much art as it is science - the majority of the chorus being sung in regards to choices of patterns and styles when coding. I want to come back to that though, but for now let me share a bit of the story of the chairs.

We were in the process of getting a new office space and one thing that came into play was the choice of new chairs for a communal/meeting/lounging area. The idea was that the chairs could be circled up to facilitate discussions. The first option had feet with pads, a bucket design, and a little desk top attached. Well, it would have been nice to have wheels and if the desk was removable so that it wouldn't be in the way if not needed. This feedback was given and the next sample chair that arrived with casters and a removable tray.

A few days later a sample arrived that fit those requirements. At first sight was a bulky eyesore of a white leather chair, with dirty handprints all over the back to boot. Then I rolled it around and the casters felt as if they would fall off. The removable tray was on the left - only on the left. It was nearly useless as it was genuinely too far away for comfort given the size of the chair and it was generally too small to support a laptop comfortably.

What is the lesson here? You get what you ask for! But seriously, think about how those requirements created solutioning constraints. What we needed was a modular place to gather comfortably and talk face-to-face for short durations. We needed the space to be able to double as a viewing space for presenting ideas, plans, apps, whatever. This is the art - understand the users needs, environment, and their expectations. Once you understand the users in this way, then you should have a better understanding of what solution to provide.

Now lets return to the code for a minute. Choosing design and style of architecture and code is an art. In order to deliver to the needs and the expectations, we must first understand the users of the code and deployment. Sometimes, you are the user and sometimes other developers. Ops teams could be users. What goals will users have in the future? There will be a need to change the code - its code of course so it is always changeable. The code will have to be changed in ways so that unexpected things do not happen. Other developers will want to understand the code, and without a whole lot of pain. You and others may want to be able to write unit tests against the code, or other forms of automated tests. Sure you could obfuscate everything and keep the code as compact as possible, keep it super-efficient, keep it obscure so that only the mightiest of developers can understand it. var a=g();a++;if((b===x&&y!==l)||(z|1)&&((((((m())+5/c)&3)|(l-5)))){return g===h?(6*f)>=9?'v'::''.....
but why would you put future you through that? It's like looking at a Jackson Pollack piece, except that someone will have to change it someday. Imagine what kind of mess you'd end up with if over time several other painters of varying skill level changed one of those would probably end up a muddy looking mess before you know it! Instead its a nice clean mess.

Sometimes we inherit a Pollack. And sometimes we are asked to change a Pollack. Oh where to begin! In this way, the art of software can be lost in the science. The art of software is more like a mural on an endless can add on without destroying the original, especially if the original lends itself to extension and to change. Picture a mural on a wall that begins to the left and continues endlessly to the right. If the first part has lines that lead the eye to the right, we have something to build on. If it has white-space we can add to it by filling in the space. As our mural is continued over time to grow to the right, we may decide to change a part somewhere to the left of the current one. Themes can be continued, but maybe some offensive part will be changed or something later causes an earlier work to be inadequate and that part would need to be revitalized lest it bring the whole down.

When applied to software, we must think of the art of it as well as the science and leave our designs and styles open to change and before that to be understood.

Tuesday, December 8, 2015

Javascript Constructor Pattern to Ensure new is Called

Here is a pattern that will ensure "new" is called when defining an object constructor. When calling a JavaScript constructor function, if "new" is not used, then the variable being assigned will be undefined unless the constructor function returns something else.

function Griffen(name){ = name;
  if(this instanceof Griffen){
  return new Griffen(name)

Wednesday, December 2, 2015

JavaScript Constructors

I learned a lot about creation patterns from this today. I was even inspired to do my own experiments on some creation patterns not shown there.

JS Bin on
go there

Wednesday, November 18, 2015

Data Modeling - The True Meaning of Entities

When modeling data an entity refers to a unit that has properties which we are modeling. Some of those properties of the entity are intrinsic (natural properties) and some are extrinsic (externally applied/relative properties). If we model our entities such that the intrinsic properties belong to a root model (Person) and the extrinsic properties belong to subclasses of the root model (Employee) we can establish a proper representation of actual relationships of the entities in our model.

To illustrate, let's take a common example of modeling a person who is an employee at a specific company.

The person has some natural properties: Name, DOB, Gender, etc. These properties describe the entity in its base state. As an employee, the person may have additional properties that relate specifically to their state as an employee: id, email address, extension, location, title, etc. This person will also have some personal properties that may be interesting to model: email(s), phone number(s), address(es), family, etc.

If we are modeling the data as a relational model, none of the columns in the data tables should be nullable. Nullable columns are a clear indicator that the data can be further normalized and that it does not likely represent the entities accurately.

To achieve the goal of creating our model, we need to be able to create the proper relationships:

Person - Email (1:*)
Person - Address (*:*)

These relationships bring up interesting questions (and leave ambiguity in the model).

If someone has more than one address and one primary address is a requirement (assuming we are not modeling homeless), then how does a many-to-many relationship enforce the many-to-one relationship that must exist to model the persons primary residence?  Address may be either of two types: primary xor non-primary. We could set a bit flag to identify primary. In order to enforce the *:1 (an address can be primary for more than one person) constraint with the primary, we would need an FK on the Person table and a reference to the address table. In the *:* relationship above, how can that FK be constrained to the PrimaryAddress type? The answer lay in table-per-type (TPT). We want to get to this:

Person - Address (*:*)
Pesrson - PrimaryAddress (*:1)

To implement the TPT for this model, we would need an Address table a PrimaryAddress table and a AdditionalAddress table. The Address would contain the details of the address and the PK. But each typed table would contain an FK to the Address table which is also its own PK. The Person record would contain a FK ref to the PrimaryAddress. An additional xref table would be needed to link the Address table to the Person table in general, this would be a *:* relationship. This PersonAddress table can better represent the fact that more than one Person can live at the same Address and a Person may have more than one Address. The FK to the PrimaryAddress will enforce and show that the Person must have a PrimaryAddress and the 1:1 relationship between PrimaryAddress and Address will establish which Address is that Person's primary Address.

It is important to recognize the boundaries of the entity since any entity may serve as the root. It is equally important to establish distinctions between different types/classifications of entities. Here are a few examples of these relationships:

Person (base type) -> [Employee, Parent, Volunteer, Student, Teacher] (sub-types)
Contact (base type) -> [Email, Phone -> [Internal], Skype, Signal -> [Tree, Smoke, Call]] (sub-types)
Relationship (base type) -> [Friend -> [Best, Acquaintance], Family -> [Sibling -> [Brother, Sister], Parent -> [Mother, Father], Cousin, ...] (sub-types)

In this way we can establish meaningful relationships in the data model, while accurately representing the entities we are modeling.

Saturday, November 7, 2015

ASP.NET MVC RenderAction, Action

In attempting to render some popup boxes with data driven select lists into a layout (_Layout) I came across an issue. The layout was being called recursively each time the action was being called by RenderAction or Action html helper methods.

I moved them to a partial outside the layout and called RenderPartial from layout. This did not help. Nor did calling the Partial helper. After a bit of research, I found that I was returning a View which uses a layout page according to how the app was configured.

The fix was to return a PartialView from the GetDialog action. For sake of brevity, I set the return type of the method to a PartialViewResult. GetDialog looks like this:

public PartialViewResult GetDialog(string dialogName)

    var dialog = _dialogFactory.GetDialog(dialogName);

    return PartialViewResult(dialog.TemplateName, dialog.Model);


And the layout template like this

    @Html.Action("GetDialog", "Menu", new { dialogName = "NameFilter" })

Which renders a JQuery UI dialog to the output stream without the recursive layout calls.