Archives for posts with tag: software

You can’t get there from here. That seems to be the theme with too many programming interfaces. In particular, the .Net System.DirectoryServices classes are too general purpose such that specific tasks become maddeningly difficult or impossible. I know AD and I know LDAP, but trying to do simple things with .Net is just too difficult.

For example, AD is based on LDAP and x500 which describes a hierarchical object system. Conceptually it is very similar to a file system. AD containers are similar to file system directories. AD objects are similar to file system objects. Yes, this is an oversimplification, but you should be able to do something like CD (change directory) from an AD parent container into a child container. However, there is no CD command in DirectoryServices. Instead, you have two choices: specify the full path to a container to connect to it, or enumerate all of the children of a container and choose one to connect to. The enumeration returns the full path of each child. There is no navigation by relative paths. Worse yet is the complexity of LDAP paths themselves (thanks to x500). It doesn’t need to be this complicated.

This complexity is compounded by the way the .Net System.DirectoryServices classes are implemented. They are just wrappers around the ADSI COM interfaces. ADSI uses IDispatch. This made some sense back in 1998 when ADSI was being designed. At that time Visual Basic was the predominant Microsoft scripting language and IDispatch provided a convenient dynamic typing system. Another decision made at that time was to have ADSI support multiple directory protocols including LDAP and WinNT (and later IIS). Unfortunately this adds a layer of unnecessary complexity to the .Net wrappers due to the fact that there many subtle differences between these and the other supported protocols.

It could have been done differently. A namespace and set of classes could have been designed specifically for doing common AD operations. Those classes could have talked directly to AD using the LDAP wire protocol but at the same time abstracting and simplifying the complexities of LDAP and AD. Instead we are left with multiple layers of interfaces with really no simplification at all. Microsoft did add the System.DirectoryServices.ActiveDirectory namespace classes to address some of the underlying complexities, but only for specific scenarios like managing forests and trusts. Ditto for System.DirectoryServices.Protocols. A simple operation like finding all users that match a set of conditions still requires an understanding of many complex details. How many people understand pre-fix notation and its application to LDAP query filters? Why should people even have to be subjected to such difficulties?

Fortunately there are promising solutions. One is the Active Directory module for PowerShell. The authors did a good job of translating many of the AD/LDAP peculiarities into standard PowerShell syntax. The other is a new API that has been added to the Windows Azure Active Directory. This is being called a Graph API. It is a RESTful web service that references all AD objects using standard URI naming. AD objects become web resources with standard URI resource naming. The attributes on objects that describe relationships to other objects (e.g. group membership, OU containment) are also expressed as URIs. Hence the “graphness” that allows simple traversal based on object relationships. See Kim Cameron’s blog for more graph API info.

In the meantime, accessing AD from .Net remains challenging without resorting to writing lots of code or buying third party libraries.

Advertisements

Software should follow the KISS principle, keep it simple Sherwood. Yes I know this is old news, but it is so important it needs repeating. This applies to all aspects of the software development process. The functional design should aim for addressing the most pressing user needs. The user interface should be clean and consistent in its layout and operation. Last, and certainly not least, the underlying code should not try to do more than the functionality and UI require.

One thing that I have seen repeatedly is designers trying to solve non-existent problems. There is pressure from marketing for feature bullet points. They also want to entice people to upgrade, so yet more pressure to add features. API designers and coders try to future-proof by adding the capability to handle anticipated needs. This is often called “extensibility points.” The problem is that almost all such efforts miss the mark because technology changes so quickly and in often unpredictable ways.

Complexity in code invites bugs and security issues. The easiest way to minimize these issues is to write absolutely no more code than necessary. This also helps to keep projects on track. Engineers and technologists by their nature want to invent stuff, so the tendency to do more than necessary is understandable. Resist the urge and take pride in elegantly delivering what is needed and no more.

Psychologists and kindergarten teachers like to tell us that we are all special. Well, when it comes to Microsoft online services, I am a bit too special. I have two accounts using the same email address; a Hotmail/Live account and an Office 365 account. I was using the Office 365 account for email (I own the domain name of the email account) and the Live account for Zune, Win7 phone syncing (SkyDrive) and PC folder syncing (Mesh). This used to work fine but is now broken. The problems started at about the same time that Microsoft announced the upgrade of Hotmail to Outlook.com. I am consistently getting redirected to the wrong logon server. So, to cut to the chase, I tried to change the email address associated with my Live account. The email-change page gave me the ominous warning that changing the email address would break syncing on my phone. This was not surprising. However, it went on to state that I would have to wipe and reset my phone back to its factory state to re-enable syncing using the new account name. Yikes! Whose idea of user-friendly is this? To be fair at least I got a warning.

So you might ask why would I be crazy enough to have to accounts with the same email address. Technology is an incremental thing; you try new stuff as it becomes available. I’ve owned my domain name for a long time. I wanted to have a constant in the shifting sands of the Internet. I created the Live account using that email address several years ago. I never actually used it for email though. My domain registrar also provided the POP email service for me. I then decided to make the switch to Office 365 for email and the other services it offers. I signed up with the same email address. I had to go to my domain registrar and update the MX records. Fortunately I understood the concepts around DNS records. Doing the Office 365 sign-up without knowing anything about DNS would be daunting. At any rate things worked fine for half a year until MS unveiled outlook.com as the successor to hotmail.com. The back end authentication code must have changed the cookie format so that both logins create similar cookies. Additionally there must be something that is stored on the back end though because even deleting cookies and starting in safe mode (so the Office sign-in assistant isn’t running) does not solve the problem.

The biggest issue is when I try to open a SharePoint Online document locally. The web service login prompts me for credentials and apparently goes to the wrong account so I get an access-denied. I also have to log into Office 365 on a different browser from SkyDrive (which is understandable; each browser has its own cookie cache). I can’t log into hotmail at all. No big loss since I didn’t get email there, but just part of the symptoms.

I will try limping along as things are until my phone contract expires. The chances of my getting another Windows phone are pretty slim. WP7 is a vast improvement over the prior Windows Mobile but it is far from perfect. Maybe it will be time to get an iPhone?

I have lots of ideas about how software should be written but I’m not particularly adept at expressing them. Jeffrey Snover’s writing, OTOH, is very eloquent and persuasive. His latest blog post here  discusses a topic that is near and dear to my heart. He uses the term technical debt. I don’t know if he is the originator of the term, but it succinctly captures the issue. In a nutshell the problem is product managers who favor investing in shiny, new features at the expense of basic functionality. This has been a problem for as long as I’ve been involved in the computer software industry (25 years). The marketeers want to have impressive bullet lists of features for a new product release. They give lip service to customer satisfaction but would much rather sell something first and worry about how well it works afterwards. This is a big problem for desktop software but becomes critical for customers who pay for online services.

Paid-for online services give a service level agreement (SLA) guarantee as to the availability and reliability of the service. It is a major problem (and a breach of contract) if the service is unavailable for any extended period of time. There is a more insidious problem that can occur when transient loads cause service resources to be momentarily unavailable. In the aggregate it appears that everything is fine, but individual users could see disconnections or other service failures. The only way to detect these situations is with very fine-grained performance monitoring of all of the service components. This is a difficult problem to solve but it can be solved with sufficient development resources. Unfortunately it is not very sexy. Will management have the wisdom to make this investment or will it be just more technical debt. Time will tell.