My take on Design Patterns

In case you haven't filled your quota for reading sarcastic poorly written hyperbole about software construction I present my take on Design Patterns. Now with example python code.

Chapter 0: The singleton

Since the invention of the stack and data structure programmers have been hounded by people telling them not to use globals. The singleton exists to confuse people until they give up criticizing your code for the use of global variables. Use them constantly.

Chapter 1: Constructin stuff is hard.

Often times you want things but getting them is hard and fraught with complication. For example we might have a car object & constructor: Car(bankAccount). However we might want to abstract the nasty details of its construction since creating a car object should be easy: class CarFactory: def __init__(self,bankAccount): self.bankAccount = bankAccount # We could make this __call__ or even use a closure but # this confuses java & c++ programmers who are easily # frightened with out many lines of boilerplate code. def createCar(self): return Car(self.bankAccount) creditCardForCar = CarFactory(lifeSavings) # now elsewhere the nasty "details" are abstracted away myNewCarIcantAfford = creditCardForCar.createCar() As you can see this is an ingenious pattern that is clearly better than using closures or currying of constructor arguments because now I have 2x as many objects.

Chapter II: Square pegs can go in round holes

Say you are using a poorly designed library or even better several poorly designed libraries that must interact together prehaps a result of the Ballmer peak. You will often have things like OMGBestLibraryEveryString and WTFBBQLibraryString. They are both strings that do that same thing but their authors seeing the clear deficiencies of using a standard string class have chosen to write a completely new one (because new is better). Its times like these you need one of two things: a bottle of wiskey or a design pattern. Put down that single malt its time to create some facades and proxy. There are two names because it would be boring to call something a wrapper pattern. Also people might think you were saying rapper pattern which would lead to profound confusion and eventual disappointment. in this case we do the following: class FacadeWrapperProxyOfOMGBestLibraryEveryString: def __init__(self,bbqstring): self.bbqstring = bbqstring # no reimplement all 50 of bbqstring's methods # and overloads minding painful edge cases and # bugs! (you can get the wiskey out again) Now everything is wonderful again.

3: Messages and misc stuff

Turns out even though OOP is modeled after passing messages to objects methods are not suitable for publish subscribe or message passing systems. This is very fortunate because now you can write extra objects to facilitate this lack of foresight.

Chapter iv: This chapter is missing because of a race condition in the chapter singleton manager factory.

Chapter 5: Take back that CS theory

Its really annoying when you are trying to engineer software and some "computer scientist" starts talking about algorithms and uses confusing words like state machine and language translation. Fear no more! They are now patterns! If someone suggests they are not just look perturbed and hand them a copy of design patterns.

Canceling Xna

After a year of not using XNA creator's club and being generally morally opposed to the whole concept I decided to cancel it. Long story short this requires contacting xbox support (weeee). The only truly annoying part is how hard it is to find out this is what you must do and what the phone number is you must call.

It seems borderline unethical to not have a mechanism for canceling your account that is as easy as signing up.

jQuery bounding region plugin

While working on some javascript network visualization software I am coding for work I came up with a jQuery plugin function that calculates the bounding box around the query using offset() and width() and height() returning an object that has left,top,bottom, and right members.
(function() {
   jQuery.fn['bounds'] = function () {
     var bounds = {  left: Number.POSITIVE_INFINITY, 
                      top: Number.POSITIVE_INFINITY,
                    right: Number.NEGATIVE_INFINITY, 
                   bottom: Number.NEGATIVE_INFINITY};

     this.each(function (i,el) {
                 var elQ = $(el);
                 var off = elQ.offset();
                 off.right = off.left + $(elQ).width();
                 off.bottom = off.top + $(elQ).height();

                 if (off.left < bounds.left)
                   bounds.left = off.left;

                 if (off.top < bounds.top)
                   bounds.top = off.top;

                 if (off.right > bounds.right)
                   bounds.right = off.right;

                 if (off.bottom > bounds.bottom)
                   bounds.bottom = off.bottom;

               });
     return bounds;
   }
 })();

Network Visualization in the Browser

I am working on doing network visualization in javascript using html canvas via John Resig's excellent processing.js. Right now it uses a force directed layout system where each edge in the graph has a spring and all nodes repulsed from each other. I noticed the results seem to be work best in firefox but not safari which makes me wonder if some of the Math object functions differently between the two? Once I separate out the connected components and remove the artificial walls around the simulation it should provide better results since the repulsion system wont cause the graph to expand indefinitely.

This will be part of a large visualization system which I intend to open source if I can. The other part being a diagram tool more suitable for point to point circuits.

Here is a link to my current prototype visualizer.

Building internal webapps

I couple months ago I picked up Enterprise Integration Patterns. It was a lot better then I thought it would be considering it contained the word enterprise in the title. The premise of the book is that using message queues/buses allows for easier integration of applications even spanning organizational boundaries.

This got me thinking about web services exposed through REST/http. One of the nice benefits of http is that it has clients in almost every language and environment. While exposing services and tools with a http interface can solve more than the immediate problem of feeding your ajax app it can also allow a larger set of people to leverage your service.

It seems like the smartest thing any organization that has lots of internal services could do would be to make a directory of such services maybe even use RDF. Of course the problem is the reliability of these services may vary depending on the needs of the original author and the maintainer. Requiring the author of every web service to make sure their service is up 24/7 might not be appropriate.