Architecture Astronautics - My Definition

The inappropriate use of structure and design patterns in an application.

Architecture Astronautics - Dependency Injection

Dependency injection is like crack for architecture astronauts.

Here's why this pattern sucks:

1) Abstraction behind dynamically loaded interfaces makes it harder to understand and debug the code. Time is money, developers take longer, money is wasted. Hard coding and recompiling, while less elegant, works, saves time, and makes everyone's life easier.

2) You aren't going to need it.

The only semi-practical implementation of this pattern that I have seen, is swapping databases or services so that development or testing can continue in an incomplete system. I say semi-practical because even when lip service is given to the correct circumstances the implementation has always been so awful that any theoretical gain is lost. I've also seen core business logic implemented in this pattern, which in an enterprise, is a complete waste of time. In short, I've never seen an application of dependency injection that saved a company money.


Hard code your dependencies.
Don't be afraid to recompile.

Principles of Enterprise Application Architecture - Rant One: Delta T.

Delta T, which I will define as the time between when you hit f5 to compile and the time when you hit the breakpoint that you set in the code.

Anything that an architecture does that increases this must be carefully considered.

If your architecture increases Delta T without giving back something concrete and appreciable, it sucks.

Things that unnecessarily increase Delta T:
1. Too many projects in a solution.
2. Unnecessary deployment procedures - if it is more than hitting f5, it is probably unnecessary.
3. Peripheral projects that must be run simultaneously, or first - an 8 tier architecture with SOA? Failure.

If you didn't think about it the tradeoffs carefully or recognize that there are tradeoffs in any architecture, if you didn't ask yourself if you were making a mistake doing it this way, or if you thought you did something really cool and new: you did not, you just wasted everyone's time who ever has to maintain or develop on your application, you're costing your company money, and you annoy me.

Code highlighting

It took me far to long to figure out how to highlight my code correctly in my last post.

http://www.stevetrefethen.com/highlighter/default.aspx

Fun with lc.exe

Third party components suck. Or they are misused. Or something. But they annoy me terribly. I've never met a third party component that I liked. Infragistics, Syncfusion, ComponentOne, etc. They all find ways of complicating my life, wasting the time that they were meant to be saving.

The latest travesty inflicted upon me is an annoying popup dialog that rears its ill-thought out head every time I compile a project that contains it. Which just happens to be 22 times during a normal compile of my most commonly used solution. This happens because I reinstalled my OS and didn't reinstall the component library, but I don't really care why or why it is difficult for me to get another license or behave like a reasonable adult. This is my computer and you're infecting it with malware. You suck.

Step one: turn Visual Studio on itself and break the code when the annoying dialog is in my face.

As it turns out, VS is calling an external process called lc.exe interesting...

What to do... Rename lc.exe to lc.exe.old, copy notepad and rename it lc.exe, and copy my new notepad-lc.exe into the directory where lc.exe was. Then recompile.

Notepad pops up instead of my annoying dialog. What fun. But no less annoying really.

Step two: create a console project that does absolutely nothing. Name it lc.exe. Copy it to the directory where I found lc.exe. Result: happiness.

However, my happiness was relatively short lived. It turns out that a subsequent program vbc.exe is looking for the lc.exe's output. Something called <filename>.exe.licenses.

Step three: alter my lc.exe program to create an empty file called <filename>.exe.licenses in the output directory.

That time it worked and I shall never be bothered by that particular annoying popup again. I will probably run across another third party component that was clever enough to withstand this fix eventually, but until then, my lc.exe shall make me smile and compile much faster and with far less annoyance.

 1 class Program
 2     {
 3         static void Main(string[] args)
 4         {
 5             Console.WriteLine("End.");
 6             string path = string.Empty;
 7             string dllName = string.Empty;
 8 
 9             //'/target:WIN.Contest.Host.dll /complist:Properties\licenses.licx /outdir:"obj\Debug - Fast\\"
10             foreach(string arg in args)
11             {
12                 Console.WriteLine(arg);
13                 System.Diagnostics.Debug.WriteLine(arg);
14 
15                 if (arg.StartsWith("/target:"))
16                 {
17                     dllName = arg.Substring(8);
18                 }
19                 else if (arg.StartsWith("/outdir:"))
20                 {
21                     path = arg.Substring(8);
22                 }
23             }
24         
25             string outputFilename = System.IO.Path.Combine(path, dllName);
26             outputFilename += ".licenses";
27 
28             System.IO.File.CreateText(outputFilename);
29 
30             Console.ReadLine();
31         }
32     }

This worked for a while, but failed when I actually tried to use some of the irritating gui components that I hate. So I settled on another solution.
AutoHotKey
I wrote an autohot key script that lies in wait for the dialog to pop up, then it closes it. So now I never see the dialog and don't have to explore the guts of Visual Studio further, nor do I have to play nice with the irritating 3rd party.