Thanks, Steve, You’ll Be Missed

by Tyler Jensen 6. October 2011 15:28

apple

Four pictures, four thousand words. Steve Jobs. 1955-2011. RIP!

Tags:

Personal

DomainAspects: Aspect Oriented Library Update - Configuration by Code and Convention

by Tyler Jensen 4. October 2011 23:57

A year ago I posted a library that I enjoy using in one form or another called DomainAspects, an aspect oriented infrastructure or template for domain driven design in .NET applications. The library allows you to isolate cross cutting concerns such as exception logging and authorization from domain or business specific concerns. I promised to write more about the library but I got distracted with work and other topics.

In this post, I will introduce a new version of the library in which I mark the domain classes internal in order to isolate the implementation of the domain interface from the outside world making it impossible to create an instance of the domain implemenation directly. This change helps to enforce the use of the DomainAspects proxy wrapper to create and dispose of the domain object.

internal class ClassroomDomain : IClassroomDomain
{
  public List<string> GetStudents()
  {
    return new List<string>();
  }
}

I also wanted to explore the idea of getting away from XML configuration in part because Castle Project shuns it while supporting it for backward compatibility and in part because managing runtime configuration files can be problematic and convention is generally easier to support. Here's the aspect oriented service components being registered in the DomainFactory's static constructor:

container = new WindsorContainer(); //no more XML

container.Register(
  Component.For<IPrincipalProvider>()
  .ImplementedBy<PrincipalProvider>()
  .Named("PrincipalProvider")
  .LifeStyle.Transient,
  
  Component.For<IOperationAuthorizer>()
  .ImplementedBy<OperationAuthorizer>()
  .Named("OperationAuthorizer")
  .LifeStyle.Transient,
  
  Component.For<IOperationAuditor>()
  .ImplementedBy<OperationAuditor>()
  .Named("OperationAuditor")
  .LifeStyle.Transient,
  
  Component.For<OperationInterceptor>()
  .Named("OperationInterceptor")
  .LifeStyle.Transient);

Now, the DomainFactory's Create method uses the convention that the implementation has the same name without the "I" prefix on the interface name.

/// <summary>
/// Use this factory method to create a transient (one time use) instance.
/// </summary>
/// <typeparam name="T"></typeparam>
/// <returns></returns>
public static T Create<T>() where T : class
{
  var svc = container.GetService<T>();
  if (null == svc)
  {
    //resolution of type by convention MyClass implements IMyClass
    Type interfaceType = typeof(T);
    var implementedByName = interfaceType.AssemblyQualifiedName
      .Replace("." + interfaceType.Name + ",",
					"." + interfaceType.Name.Substring(1) + ",");
    Type implementedByType = Type.GetType(implementedByName);
    if (null == implementedByType) 
      throw new TypeAccessException(string.Format("Type {0} could not be found.", implementedByName));

    container.Register(Component.For(interfaceType)
      .ImplementedBy(implementedByType)
      .Named(implementedByType.Name)
      .Interceptors(InterceptorReference.ForKey("OperationInterceptor")).Anywhere
      .LifeStyle.Transient);
  }
  if (!isConfigured) throw initializationException;
  return container.Resolve<T>();
}

Now I remove the app.config from my projects and run my tests XML-config-free. There is a lot more fun stuff to explore in this library, so check back soon for more info on DomainAspects.

You can download the new code here: DomainAspects_v1_1.zip (30.25 KB).

Tags:

Code | DomainAspects

Fear Corrupts Process and Assures Failure

by Tyler Jensen 3. October 2011 17:05

A certain angel investor chose three companies in which to invest a relatively large sum. In the first, he invested $10 million. In the second, he invested $5 million. And in the third, he invested $1 million. A year later, the first had doubled in value because it had boldly used the capital to execute on its business plan. The second company had also doubled in size because they had taken the investment and worked very hard to grow their business. The third company had run into some problems and was afraid of losing their capital, so they did nothing and had nothing to show for it. The angel investor liquidated his interest in the third company and those people are now looking for work.

Yes, I’ve borrowed the plot for that story from someone much wiser than me. But it applies in today’s world of technology and software development as much as it applies to the context for which it was originally told. Fear paralyzes us into inaction or into making unwise choices which almost always result in the corruption of otherwise sound business processes and just as often leads to complete and utter failure.

One of the greatest fears in software development that corrupts process and assures failure is the fear to tell the client or customer no. In the world of software development, especially in internal enterprise software development, the fear of saying no can be so paralyzing that we often place impossible burdens on teams already pushed to their limits. The fear of saying no can lead us to short circuit our process, skip critical steps and gloss over real analysis and careful design. The fear of saying no can lead to general discord when a team member objects and the manager angrily brushes her off, dismissing her concerns as irrelevant or inconsequential. This fear leads to chaos and assured failure. Failure to deliver on time. Failure to communicate and manage realistic client expectations. Failure to establish credibility and confidence with the client and the organization. Failure to keep and foster a well organized, happy and productive team.

So how can one overcome this fear? You just jump. How does the diver overcome his fear of heights to jump from a platform so high the first time? He just jumps. How does a skydiver overcome her fear of falling to her death from an airplane? She just leaps or is pushed. And then training and preparation take over and fear is overcome. You may never completely overcome the fear of saying no. But if you jump, take a leap of faith, just do it, you’ll find that you have not died and that you will have an easier time doing it the next time.

When we overcome our fear and take a leap of faith, we can accomplish great things. Let us work like the first two companies in our story and succeed.

Tags:

Commentary | Management | Principles | Software Development

Software Architecture: Use Cases, Not Frameworks

by Tyler Jensen 30. September 2011 06:46

I enjoy continually learning from Robert Martin (Uncle Bob). Sometimes I disagree with him but usually only until I’ve thoroughly processed what he is trying to teach me. In his latest missive on 8thlight.com, Uncle Bob writes a stunningly cogent brief called Screaming Architecture in which he makes a critical point: software architecture is all about the use cases of a system and NOT the framework.

“Architectures are not (or should not) be about frameworks. Architectures should not be supplied by frameworks. Frameworks are tools to be used, not architectures to be conformed to. If your architecture is based on frameworks, then it cannot be based on your use cases.”

Focus on the use cases and perhaps even group them into logical hierarchies with tidy “40,000 foot level” epochs that describe the thing you are building. Is it a customer relationship management system? The first thing we should notice in an architecture, whether document or code, is that this is a CRM system. Presentation, delivery, storage and communication frameworks are all secondary, just plumbing, not the architecture.

“A good software architecture allows decisions about frameworks, databases, web-servers, and other environmental issues and tools, to be deferred and delayed.”

I’m not completely at this point in my journey toward architectural perfection but I recognize the need to strive for this idea of producing architectures that are designed to solve the problems of the users first rather than designed fit within the strictures of a framework while addressing the use cases after the fact.

I recommend you read the full article. Take Uncle Bob’s advice, as I intend to do, and focus more strongly on architecture for your use cases on your next project. Use frameworks carefully and work to keep your business code independent of your frameworks and thus imminently more testable. And don’t forget your tests.

Tags:

Commentary | Software Architecture

How to Earn Respect as a Leader in the Workplace

by Tyler Jensen 29. September 2011 11:37

I’ve recently been interested in the subject of respect and the question of whether respect is given or earned. My conclusion is that respect is given most often when it is earned and certainly most easily when that is so. In contemplating and researching this subject, I ran across a post by Bret Simmons that I liked very much called 10 Ways to Earn Respect as a Leader in the Workplace.

I recommend you read the full article but I’ll share a few of my favorites here along with some personal thoughts about each one.

Get to know your co-workers and their families.
This is the author’s first point and I think most important one. It is very hard to give respect to someone who has no empathy and does not appear to be genuinely interested in you and your personal circumstances. A little bit of real care can earn a lot of respect.

Communicate clearly and regularly.
If one does not hear from or speak with his manager on a regular basis, it is impossible for the first point to occur. And if a person is left in the dark with respect to what is happening within the organization, an atmosphere of fear and a feeling of neglect can result in poor attitudes and even overt disrespect.

Make generous use of self-deprecating humor.
When I work with someone who refrains from making deprecating remarks about others but has the self confidence to take a jab at himself from time to time in order to put others at ease, I’m more likely to feel comfortable working with that person and will certainly have more respect for him.

Admit when you screw up.
Nothing can destroy the respect you have earned more rapidly than dodging responsibility for your own mistakes. Nothing can more irreversibly damage your own reputation more powerfully than when you throw a subordinate or coworker under the bus rather than owning up and facing the music. At the same time, the opposite is true. If I have a boss who takes responsibility for mistakes made and asks the team for their support as she takes corrective action, I will have just that much more respect for that person.

Stand behind your staff during times of difficulty.
When mistakes are made by subordinates or coworkers, stand by them. Don’t abandon them in an attempt to save yourself. Chances are you will all survive but you will have lost their respect forever. The author writes, “If you can’t stand behind one of your team members, then you don’t belong in management and you’re certainly not a leader.”

Tags:

Commentary | Management

Me...

Tyler Jensen

Tyler Jensen
.NET Developer and Architect

Month List

Other Stuff