Robert Binzley – Page 6 – BinzBlog

Build Dependency Question

On my current project we have two build trees, but they are not entirely separate. Build tree A knows nothing about Build Tree B, however Build Tree B has dependencies on projects in Build Tree A.

The problem we encounter is that the Build Trees are run on different build agents and the output of Build Tree A is only made available to Build Tree B when all of Build Tree A builds successfully. When a change is made to a project in Build Tree B that depends on a change also made in Build Tree A it can be hours before Build Tree A builds successfully all the way through and in the meanwhile Build Tree B fails until assemblies from Build Tree A are updated with the dependent change. This is because the change in Build Tree A ins’t made available until all of Build Tree A builds successfully.

I’m trying to work out solutions, the first that comes to mind is separating out the projects that both Build Tree A and B depend on that are in Build Tree A and create a third and shorter build Tree with only these assemblies. Allow both A and B to be dependent on this much smaller third Tree, then wait time for synchronization of dependencies for Build Tree B for items not in Build tree B become significantly less. Another idea was simply to have all output from from assemblies in Build tree A that Build tree B relies on be immediately made available to Build tree B when they are built, regardless of whether they causes issues for the rest of Build tree A.

Any thoughts on a better way will be greatly appreciated via twitter @binzleyTwit.

How To Manage DI Registrations For Dependencies?

On a recent project I have been working on we’ve had a dilemma with how to register dependencies in libraries that our application consumes but does not own. The development of these libraries is under our control, but separate from the top level consuming application’s development. Using dependency injection at all in our environment was very controversial, and now we are experiencing similar controversy regarding how to manage the dependencies of the libraries we consume when they are also using dependency injection.

The problem appears to be how to coherently register implementations that are not in assemblies that are referenced by the top level application. My thought is that the top level app should call registration modules in the assemblies it does references and allow those routines to register types in assemblies they reference, this would allow the top level application to be free of references to assemblies it doesn’t directly know about. Others believe the top level application should register all implementations discreetly so should have a reference to all assemblies that hold types that the application will eventually use. I can see how that is appealing, but I tend to think of what my application is consuming as being more plugins and I’d like the top level application to not have to care so much about the details of their implementations.

Perhaps the right answer is to have separate containers for things I want to be considered plugins and let them register what they need without having the top level application aware of it at all?

oData, DataServices, or Roll Your Own

On my current project we have been debating how to query a service that is potentially exposed over rest and or soap that talks in terms of domain objects, but really queries against data entities. What this means is that the queries at the business level are in terms of the domain object, for instance, give me all students that have a GPA property greater than 3. This query has to be transformed to the persistence layer, which may mean a sql query something like,

‘SELECT * FROM Student WHERE std_gpa > 3’.

The persistence layer may not use our domain objects, but it’s own entities that more closely reflect the database structure. This means that any query written in the context of the business objects must be transformed into the context of the data entities. What we have been trying to decide is if we should make our service query in terms of business objects and transform underneath or have our service expose our data entity objects directly and let callers transform on their own?

If we structure our service to talk in terms of business objects it will be harder to construct, since we’ll have to manage the transforms. The service will be easier for any caller that already uses our business objects to understand, however, and if our persistence mechanism changes in any way we can hide that from the callers as well. If we expose our data entities directly we will be able to publish the service faster, and it will be potentially more flexible as callers won’t be limited to queries that are only supported by the business object structure.

Agile Is More Than A Stand Up

A while ago I worked with a rather large software company that had long used a homegrown waterfall esque development process. They had built up a custom system around their process, and were trying to move to more of an ‘Agile’ based approach. I believe what was driving this was a long history of buggy and late deliverables, along with high turnover and low developer morale.

I was happy to see they were trying to change what was not working and move towards something that they thought would help solve some of their process issues. What’s interesting is that they did this in a very closed environment, that is they were creating a homegrown version of agile with little input from anyone who had worked with agile in the past. They started having ‘stand up’ meetings, but since there was little definition of team the one stand up meeting included all developers (This made them very long). They also introduced the notion of iterations, although they had not altered how they managed requirements so tasks were not defined, estimates were usually multiple days and no acceptance criteria existed.

I got the sense because there was a stand up, and tasks were in iterations the management felt they were implementing an ‘Agile’ process. I have always felt agile was more about team ownership, inclusion and transparency. I found it ironic to see an ‘Agile’ approach enforced on a group without any of the group’s input, and with no transparency into how the process was being driven.

My experience with agile, which ranges from helping to design and implement a process to participating in those crafted by others, is that the ones that work focus on process that create a sense of team ownership and responsibility. A stand up does help with this and I like stand ups. I think what is more important, however, is including the team in crafting tasks that they agree are actionable and have acceptable acceptance criteria before assigning them. I also think having regular retrospectives so the team can regularly provide feedback is a great way of creating a sense of team ownership.

If you simply impose stand ups and put ill defined tasks into iterations you are moving in the right directions. My fear, however, is that the two alone will create little change or sense of team accountability and will simply confirm that there is no better way than the homegrown waterfall system currently in place. I hate to see organizations miss opportunities to make real beneficial change as these opportunities can be few and far between.

Loving ToDictionary

I love ToDictionary()! It allows me to easily transform disparate data into a common format I can use to send to methods making those methods less coupled and more readily reusable. Let me provide an example.

I have a method that needs to process header values of web request and do certain things based on their values, the signature looks something like this:

public ComService  GetServiceBasedOnSource(IServiceFactory factory, 
                                           HttpRequestHeaders headers, 
                                           string tokenValue)

I was given a requirement to have the same processing occur based of off query string values if headers are not available. I was passing headers directly to my method, however, so wasn’t sure what to do. I figured I could pull out common code and have two methods, one with signature for headers and one with signature for query string parameter values, which is turns out are a collection of KeyValuePair if you use the Request.GetQueryNameValuePairs() method. When thinking about this I realized if I pulled the common code out I’d have to transform the different input into something I could process, so if I was going to alter data why not let caller do it and have one method with a signature that wasn’t dependent on headers or keyvaluepairs?

This is where ToDictionary makes life easy. I changed my signature to take a dictionary instead of headers or keyvaluepairs and toDictionary makes this transformation a snap. My method now looks like:

public ComService  GetServiceBasedOnSource(IServiceFactory factory, 
                                           Dictionary<string, string> dictionary, 
                                           string tokenValue)

And to use it I just ToDictionary the inputs:

public ComService  GetServiceBasedOnSource(factory, 
                                           Request.Headers.ToDictionary(x => x.Key, x => x.Value.FirstOrDefault()),
                                           token);

or 

public ComService  GetServiceBasedOnSource(factory, 
                                           Request.GetQueryNameValuePairs().ToDictionary(x => x.Key, x => x.Value), 
                                           token);