Today I take a break to discuss naming conventions since this is a frequent consideration. An inventory is a source of great pride. The name for an asset sticks to it  for its lifetime and it is easier to remember and find an asset by name.  This is particularly important when assets look all the same and we want the name to reflect something more than just a serial number to tell them apart.  Names have to be friendly for the customer to use and they should have the consistency that an administrator wants from the types of assets maintained in the inventory.  That is why Information Technology personnel pay great attention to naming the assets in their inventory.  Often they include a prefix in the name of the asset to recognize the location or categorization of the assets. 

It's true that the inventory or database objects have become synonymous  since it is easier to manage the inventory with a table no matter how large how it grows. Moreover, several routine operations including the create, update and delete on the assets become easier to take on tables.  Also it is easier to add properties of the asset as columns of the inventory table as and when the need arises. Administrators have long used this technique to tag the assets in the inventory. Besides, the identifier of the asset in this table need not just be its name but that’s a longer story. If we were to look at just the names of the assets in the inventory table as the primary means for lookup, wouldn't it be convenient to store and fetch the properties of the asset given the name. Unfortunately, such reads come with the onus of authenticating,  authorizing and auditing the access to the inventory.  

What if the information of the asset could be available on the asset itself so that the user and not just the administrator can quickly tell the attributes of the asset. For example, the finger protocol used to provide the status of a particular computer system. Such information now is accessible easily and securely from APIs over HTTP. Administrators often went a step ahead of keeping this information local to the asset for easy readability. For example, the asset information could be displayed on the desktop wallpaper of a Windows or other Operating Systems. Others keep it stored on a local file that can be displayed on the terminal for no network access information. 

This provided the convenience to consolidate all readable information on the asset locally in a centralized spot and in a variety of formats such as JSON, xml and even configurations.  Till date, many Linux based systems use files to store release, version and configuration information for applications, operating systems and services.  These can be queried over ssh or other protocols and most system center tools allow us to directly read the information from the target so that we can check if our inventory is out of date as systems get reused or repurposed. A name must be static. 

The additional charm of using a richer naming system by way of this extended information is that we can now have aliases and multiple names. For example, an administrator can assign an IPV4 as well as an IPV6 name as appropriate. Arguably both names may not be more user friendly than an alias but it avoids the over thinking of a name with overloading of purpose.  

In the end every asset may genuinely get a name that jives with the user rather than the administrator. Hopefully that name will become just as popular as the robots in the Star Wars movie. 

#codingexercise
We were looking at an exercise involving sum of all numbers formed by subsequences in  the digits representing a number and a similar technique to count the number of repetitions. The same is true to count the number of subsequences as well
We use the fact the number of subsequences is represented by combinations which are represented by  binomial coefficients. Let's take an example and see the pattern:
a0, a1, a2
can be combined as a0 + a1 + a2  + a0a1 + a1a2 + a0a2 + (a0a1a2 ) resulting in 7 subsequences
and these are infact the sum of the binomial coefficients.
Int GetCount(List<int>A, int start, int end)
{
If (start>end) return 0;
If (start==end)return A[start];
Int sum = A.Sum();
int count= 0
For (int n = 1; n <=A.Count; n++)
       count += GetNChoosekDP(A.Count, n)
Return count;
}
int GetNChooseKDP(uint n, uint k)
{
if (k == 0 || k == n)
    return 1;
return GetNChooseKDP(n-1, k-1) + GetNChooseKDP(n-1,k);
}