From Enomalism to Enomaly ECP

As Reuven Cohen mentioned on his blog, Enomalism is now known as Enomaly ECP (Elastic Computing Platform). So, I'm going to be doing my best to start calling Enomalism Enomaly ECP. I can't make any promises though. I still occasionally call Pidgin Gaim.

Enomalism developer guide

I've started work on the Enomalism developer guide. I've only just begun writing it so there is a lack of content at the moment. However, the good news is that I'll be frequently updating it. So check back often.

The guide hopefully be a useful starting point for creating Enomalism extension modules as well as using the exposed API. If there is any area that is lacking (that doesn't already have a TODO label) or missing completely, be sure to let me know.

Object orientation

I figured I would give my thoughts on my view toward object orientation and it's benefits. Also, why it makes a difference using an object-oriented programming language as opposed to a functional or procedural language.

I think a definition would serve its purpose here. What is object orientation? Object orientation in the context of software development is a practice that developers undertake in order to better represent abstractions. Notice I'm referring to the idea of object orientation and not the features that define an object-oriented programming language. You could, in theory, practice object orientation in a functional language. You would just need to implement the object-oriented language features using the language itself. Which doesn't gain anyone anything.

Lots of developers use functional languages today and there is absolutely nothing wrong with that it it is done right. Good design is good design. The C programming language has been around for decades and is going nowhere fast. It is cross-platform, fast, and relatively easy to program in.

C++ is the object-oriented C (an increment of C). It defines the object-oriented constructs necessary for C to be considered an object-oriented programming language. Enough of the history lesson already.

Class

The class lies at the very heart of object-orientation. The class classifies things. This makes sense in software because even when developing in a functional language, you are still implicitly modeling abstractions. For example, consider the following functional code that defines a user and some behavior that the user is capable of.

def create_user(user_name=None, password=None, is_active=None):
  user={}
  user['user_name']=user_name
  user['password']=password
  user['is_active']=is_active
  return user

def is_user_active(user):
  if user['is_active']:
      return True

if __name__=='__main__':
  user=create_user(user_name='test',\
                   password='123',\
                   is_active=True)
  print 'Is the user active?',is_user_active(user)

Here we have a user abstraction that is very difficult to comprehend. Lets take a look at the equivalent object-oriented functionality.

class User:
   def __init__(self, user_name=None, password=None, is_active=None):
       self.user_name=user_name
       self.password=password
       self.is_active=is_active
      
   def is_active(self):
       return self.is_active
  
if __name__=='__main__':
   user=User(user_name='test',\
             password='123',\
             is_active=True)
   print 'Is the user active?',user.is_active()

Here, it is much more obvious that we are dealing with a user abstraction. In the main program, we actually create a user object. This object then encapsulates the user essence. That is, the behavior associated with the concept of a user is bound to that object. This is illustrated when we invoke user.is_active().

I'll continue this discussion as part two (or something like that) because I have much to say about other object-orientation topics.

Pygments

I thought I'd mention the Pythonic syntax highlighter Pygments. It is a very powerful syntax highlighter written in Python. It has a nice API that can be used from Python applications as well as a nice command line utility. Here is some sample output from the Pygments command line:

class MyClass:
   """This is my class."""
   def __init__(self):
       """Constructor."""
       self.my_attr=False
      
   def set_my_attr(self, my_attr):
       """Set the my_attr attribute."""
       self.my_attr=my_attr
      
   def get_my_attr(self):
       """Return the my_attr attribute."""
       return self.my_attr
  
if __name__=='__main__':
   my_obj=MyClass()
   my_obj.set_my_attr('Hello!')
   print 'ATTR:', my_obj.get_my_attr()
  

This was actually printed to the console screen but can easily be captured in an HTML file.

Dynamic turbogears widgets and validation.

If you are using TurboGears widgets and have a need to build widgets dynamically within the context of a request, it simply doesn't work. Well, that's not entirely true. Here is a case where it is.

Say you are displaying a form to a user that displays a selectbox widget. This selectbox widget contains a list of languages supported by your application that the user can choose. For this, you would use a TurboGears widget. Now, say that you also want the default selection to be the language of the requesting client. This is a case where the widget would need to be dynamically constructed within the context of the request.

So far, so good. We can build TurboGears widgets in web controllers no problem. Now, what if we want to enforce some validation on the language selector? We use a TurboGears validator to say this widget may not be empty say. Well, when the widget validation fails, so does your widget because it can no longer be constructed. This is because the validation logic is taken care of for the developer outside the controller.

This is an obscure case but it is nonetheless realizable. Perhaps the TurboGears validation decorator should offer more flexibility in how widget failure validation is handled. Maybe this is already possible?

Trace Modeler

I just recently tested out a UML interaction diagramming tool called TraceModeler. The reason I call it a interaction diagramming tool is because that is exactly what it is. It doesn't have the ability to create other UML diagram types. But this comes in handy. It is by no means a bloated tool and if you find yourself frequently creating UML sequence diagrams, this is a good tool to use.

After using the application, I noted that its superiority lies in the interaction fragments. I've never had much luck with open source solutions while creating sequence diagrams. So, overall great tool. Although it isn't open source, the price is competitive. I also like the student license.

Colubrid

The Colubrid looks like a very promising Python WSGI publishing system. Here is the hello world taken from the examples directory in the source code:

from colubrid import BaseApplication, Request, HttpResponse

class HelloWorld(BaseApplication):
  def __init__(self, environ, start_response):
      super(HelloWorld, self).__init__(environ, start_response)
      self.request = Request(environ, start_response)

  def process_request(self):
      return HttpResponse('Hello World')

app = HelloWorld
if __name__ == '__main__':
  from colubrid import execute
  execute()

Thats it, nice and simple. It is ideally suited for simply exposing controllers to the web. Without any excess features. Although, I'm not too sure what the future plans for Colubrid are if any.

The UML meta model.

The UML meta model is an enormous tomb of a specification. All this is required to define a set of rules for what can and cannot be drawn in a UML diagram? Well, it does much more than that. There are semantics defined for every single element in the language. These semantics are by no means simplistic. Which would make sense my most people cringe at the thought of the UML meta model, or even the UML itself.

But these detailed explanations need not be daunting and boring. One approach I take is to learn one aspect of the UML form an end user perspective. This means reading documentation (not the UML specification) and creating sample diagrams in this one area; say, for example, activity diagrams. Once you have mastered the end user perspective, you can then dive into the specification. After I did this, the specification revealed several insights to my sample models. Not only that, but also made me think twice about code I had written, or code I had been planning to write.

Learning the entire UML specification upfront with no real high level modeling experience is an unrealistic goal. Rather, learn some general UML concepts and use the specification to solidify ideas and to enlighten, rather than frustrate.

Building an exception based API

Building an exception based API is useful for several reasons. One benefit I'm going to discuss here is the ability to model your system as a mesh of signals, or events. When dealing with exceptions, most people tend to lean toward using signal in the terminology. I, however, don't which term is used. The goal of creating an exception based API is to move away from the traditional synchronous invocation. Using events or signals achieves this.

I'm going to move out of the problem space here for a moment and into the solution space. In a programming language, when an exception is raised by some function or method, the normal flow of control is interrupted. I most cases, this is caused by a more primitive error such as in index error or name error. The flow of control then propagates outward, toward the highest level in the code. Along the way, there may be exception handlers. There are specialized code blocks that will execute if the appropriate exception is raised will the code in the context of the exception handler is executed.

The idea I'm trying to get across here is that exceptions can easily be modeled as signals. The code that raises the exception often has no idea if this exception will take place before the code is executed.

One approach to modeling an exception based API is to build a custom exception for the various flows of control. For example, we might model something like the following for a RESTful framework:


Here we have a Application object that represents application, or controller. The application object interacts directly with the Request object. The request object represents the request that is sent to our application from some client. Most web frameworks already support this abstraction out of the box. The remaining objects, GET, POST, PUT, and DELETE, are all modeled here as exceptions. Although there is no way to differentiate the regular objects from the exceptions, this is not the focus of this diagram. The focus here is to show how exceptions can be used as more than just exception handlers.

Another point to note, the sequence of messages dispatched from the Application object are not meant to represent the ordering of the message. It is meant to represent to potential messages that may be dispatched in response to a client request.

Building software objects as resources

The term resource oriented architecture often refers to software design in the context of the web. Object design can take this principle into account before the web even needs to be considered. It is, after all, simply an architectural principle used to build a scalable and robust system.

One approach here is to take into account the four most common HTTP methods and implement this functionality in a base class. For example, if we were to implement this in Python, we might implement a base class that define these methods. But these methods may be abstract, not intended to actually do anything.

class Resource:
   def get(self, *args, **kw):
       pass

   def put(self, *args, **kw):
       pass

   def post(self, *args, **kw):
       pass

   def delete(self, *args, **kw):
       pass

In this case, other resources in your system would inherit from Resource and define the behavior of these methods. The key idea here being that you are building a resource oriented architecture at a level of abstraction that is not concerned with the web at all. This is powerful because it lets the developer shift the application code from framework to framework.

The actual code that deals with web requests is simple. It says "I got a GET request for this resource. Application, what should I tell the client?". And the application can easily respond in a way that makes sense to the framework. Not only that framework, but possibly others as well.

Enomalism update

The long weekend is over and work toward a stable Enoamlism2.1 release resumes. Today, I've renamed some key classes in the Enomalism data model. uuid_search is now know as UUIDSearch and perm_select is know know as PermSelect. These changes help keep the code in sync with PEP8.

The config_editor Enomalism extension module now has a more package-like structure. Several json-conversion functions have been implemented. These still have yet to be invoked by the various REST controllers. The Queue and QueueMessage classes now have setter/getter methods implemented and ready to use.

I've noticed that all classes in the UUIDSearch.by_prefix() method need some reconsidering. They do not check permissions. If each object that is returned by this method has permissions checked against it, this is a serious performance bottle-neck. The good news is, we simply need to use PermSelect for the various object filters.