Natural Order Development

Just had a reason to open up my code archives. Not a big deal, just checkout the older stuff from the Subversion archives and add some new Eclipse projects.

Lions, tigers and bears oh my. What the heck are all those warnings!?

LOL one of the things I started doing a few years back was to start worrying about TDD and code complexity. Somewhere in the last couple of years I added the metrics plugin for Eclipse (http://eclipse-metrics.sourceforge.net/). Which is very nice since it supports complexity checking using a number of different metrics:

• McCabe's Cyclomatic Complexity
  
• Efferent Couplings
  
• Lack of Cohesion in Methods
  
• Lines Of Code in Method
  
• Number Of Fields
  
• Number Of Levels
  
• Number Of Locals In Scope
  
• Number Of Parameters
  
• Number Of Statements
  
• Weighted Methods Per Class

Sometimes you really should let the past remain the past. I had such fond memories of all these cool and wonderful applications and utilities I wrote years ago at the beginnings of Java. Yet here I was looking at them using the latest Eclipse with all the TDD and metrics warning thumbscrews in place (to keep me honestly doing what I preach) having to view my own legacy code.

This will make far me less critical of other legacy code I have to clean up from now on. Yes, my legacy applications still compiled, they still worked. But code coverage is zero, cyclomatic complexity is up in the 50s for most of my methods (in the hundreds for the control points) and oh my do I really have methods over 200 lines long! This is a very humbling experience.

If you'll excuse me I need to sweep the dirt off the floor, dust the corners and polish the brass in my own legacy code.

I always love a good laugh and this one is great. The developers and testers at Google have put up a great "How to Write 3v1L, Untestable Code" article with tongue in cheek and enough sarcasm to really tickle your thought processes. In reality is a list of things not to do as a developer. I love the reverse style delivery. You can find the complete post here: Google Testing Blog (http://googletesting.blogspot.com/2008/07/how-to-write-3v1l-untestable-code.html).

Well it has been a cruddy day. I have been trying to figure out a problem with the fcgi implementation. Seem to have been running circles around myself here.

There is a bug in the Django source specifically in django/core/servers/fastcgi.py that was ignores the output settings unless the process is being daemonized. So I added the else clause below has fixed it so I am now getting stdout and stderr messages.

    if daemonize:
        from django.utils.daemonize import become_daemon
        become_daemon(our_home_dir=options["workdir"], **daemon_kwargs)
    else:
        if options['outlog']:
            so = open(options['outlog'], 'a+', 0)
            os.dup2(so.fileno(), sys.stdout.fileno())
        if options['errlog']:
            se = open(err_log, 'a+', 0)
            os.dup2(se.fileno(), sys.stderr.fileno())

Except that that breaks the fcgi interactions. With that change I am not able to get responses through the auto-generated named pipes. It seems I have to hand it the bind name for the pipe. But if I do that and daemonize it then lightttpd looses control and if I stop the services the python processes persist.

On the other hand I am getting a lot of code crawling experience on the python classes. Which leads me to another observation.

Why are so many open source developers so lazy about documentation. If you are going to publish something you dang well had better provide solid design docs, API references and user docs. But, no fcgi is not well documented, lighttpd is not well documented, django is not well documented and Sphene Community Tools are not well documented. Which means I have to spend hours of code crawling to figure anything out.

And it isn't just open source developers I have the same problems at work too. Major enterprise systems with cruddy docs and lots of black magic development lead to a nightmare of work. I have heard some people laugh at this and say "well that is called job security." It isn't job security it is crappy development and laziness. My customers have plenty of additional work they want me to do. I am sure they could give me a list 60 years long.

<SIGH> well back to code crawling.