Stephen

After hours of troubleshooting, I’m starting to reconsider my initial enthusiasm for Ruby...

Sat, 27 Aug 2011 01:51:50 -0700

After hours of troubleshooting, I’m starting to reconsider my initial enthusiasm for Ruby metaprograming!

Learning Clojure (and Lisp) has prompted me to second guess the object-oriented programming model. ...

Thu, 26 May 2011 14:54:00 -0700

Learning Clojure (and Lisp) has prompted me to second guess the object-oriented programming model. I’ve been processing it for a few weeks (code in data structures instead of in objects). Now, whenever I am stuck writing some OO boiler-plate code, I can’t help considering it. I’ll have to try doing some real Lisp-like programming (solving real problems) to know for sure. This will take a while.

Got insomnia. Watching Clojure Concurrency by Rich Hickey.

Sun, 01 May 2011 04:47:00 -0700

Got insomnia. Watching Clojure Concurrency by Rich Hickey.

I got see some concurrent Clojure code while reading Programming Concurrency on the JVM. The syntax...

Wed, 27 Apr 2011 14:55:00 -0700

I got see some concurrent Clojure code while reading Programming Concurrency on the JVM. The syntax is similar to Lisp and the concurrent programming support (baked in) is very nice.

Method Chaining in Python with Iterators

Wed, 13 Apr 2011 21:01:00 -0700

I have been reading about Scala and learning improved coding practices along the way. In additional to wishing that I could use such a cool language at work, I’ve also been trying to apply what I’m learning towards improving my Python code. One of these “scalaisms” is the encouragement of method chaining. I think I must have considered method chaining a bit too smelly to really give it a shot. Once I saw some examples in a couple of Scala books, though, my mind opened up to the idea. Thinking about method chaining in Python while reading about iterators and generators (reading about functional concepts in Python) led me to consider applying both concepts. I came up with the idea of chaining iterators as a way to iterate over and filter large lists. A nice thing about iterators is that they are lazy. They only return their contents one item at a time. I wanted to chain iterators that could be dynamically plugged together to filter the contents of a list lazily. The rest of this blog post will be about my proof-of-concept code.

First, I needed something to iterate over. I decided to work with objects that represented pets in a pet store (the simplest idea I could come up with).

class Pet(object):
    @staticmethod
    def from_list(args_list):
        kwargs = dict()
        type_str = args_list[0]
        if type_str == "Dog":
            pet_clss = Dog
        elif type_str == "Cat":
            pet_clss = Cat
        else:
            raise ValueError("Unknown Pet type '%s'" % type_str)
        return pet_clss(**dict([[args_list[x], args_list[x+1]] for x in range(1, len(args_list)-1, 2)]))

    def __init__(self, **kwargs):
        self.name = kwargs['name']
        self.breed = kwargs['breed']
        self.owner = kwargs.get('owner', None)
        self.color = kwargs['color']

    def was_sold(self):
        if self.owner is not None:
            return True
        else:
            return False

class Cat(Pet):
    def __init__(self, **kwargs):
        Pet.__init__(self, **kwargs)
        self.meows = kwargs.get("meows", True)

class Dog(Pet):
    def __init__(self, **kwargs):
        Pet.__init__(self, **kwargs)
        self.barks = kwargs.get("barks", True)

I wanted to be able to load data from a CSV file, hence the from_list() constructor. Here is a parent class called Pet which is inherited by Cat and Dog.

The rest of the code is based on FilterablePetStore. This is an abstract class that I used to test two different approaches to implementing a filterable PetStore class.

class FilterablePetStore(object):
    def __iter__(self):
        raise NotImplementedError()

    def filter(self, filter_func):
        return PetStoreView(self, filter_func)

    def was_sold(self):
        return self.filter(lambda pet: pet.was_sold())

    def is_type(self, test_type):
        return self.filter(lambda pet: isinstance(pet, test_type))

    def is_color(self, color):
        return self.filter(lambda pet: pet.color.upper() == color.upper())

    def is_tabby(self):
        return self.filter(lambda pet: pet.color.upper().endswith("TABBY"))

    def as_list(self):
        return [pet for pet in self]

FilterablePetStore just contains some ideas of how a pet store might want to filter their list of pets. Notice also that filter() method takes a function as its argument, and all of the other methods simple reuse the filter() method by supplying a function.

First I’ll show the simple way to implement method chaining in Python. This does not use iterators. Each method in the chain returns a new object which contains its own list of pets. (I actually coded this one second, hence the ‘2’ in the name).

class PetStore2(FilterablePetStore):
    def __init__(self, list_of_pets):
        self.pets = list_of_pets

    def __iter__(self):
        return iter(self.pets)

    def filter(self, filter_func):
        return PetStore2(filter(filter_func, self.pets))

    def as_list(self):
        return self.pets

This should be pretty straight forward. The filter() method returns a new PetStore2 instance with a new (possibly smaller) list of pets. Additional methods are inherited from FilterablePetStore.

The more interesting implementation uses iterators. The goal of this code was to lazily evaluate each call to next() (see iterators) all the way through the chain of methods.

class PetStore(FilterablePetStore):
    def __init__(self, list_of_pets):
        self.pets = list_of_pets

    def __getitem__(self, index):
        assert isinstance(index, int), "Index must be an integer"
        return self.pets[index]

    def __iter__(self):
        return PetStoreView(self, lambda pet: True)

class PetStoreView(FilterablePetStore):
    def __init__(self, pets, filter_func):
        self._pets = pets
        self._location = 0
        self._filter_function = filter_func

    def __iter__(self):
        return self

    def next(self):
        try:
            try:
                next_item = self._pets.next()
            except AttributeError:
                next_item = self._pets[self._location]
                self._location += 1
        except IndexError:
            raise StopIteration()
        if self._filter_function(next_item):
            return next_item
        else:
            return self.next()

Here the iterator is implemented by the PetStoreView class. A potential drawback of this approach is that you don’t end up with a PetStore object, but since the goal was to create an iterator chain, this isn’t a big deal. Each element is passed down the filter chain and, if it passes all of the filters, is iterated over. Each element waits until the next iteration before being filtered; there are no intermediary lists.

So what is my conclusion? That will have to come in another post!

Here is the code for anyone who wants to play with it.

High Level Concurrency with JRuby and Akka Actors

Tue, 04 Jan 2011 12:42:05 -0800

High Level Concurrency with JRuby and Akka Actors:

I’m learning Scala (which admittedly has required more effort from me than learning Ruby or Python did) largely because I want to use Erlang like actors in an OO style language. That original goal has been expanded since I have learned the many ways that Scala improves the programming process beyond just actors. Still, here is another option that meets my original goal without learning Scala: JRuby with Akka actors. This is a very compelling option for concurrent programming in a high productivity language.

Interfacing with DOORS using Python Socket

Wed, 22 Dec 2010 19:29:00 -0800

For as long as I’ve been doing DXL development, I’ve desired ways to interface DOORS with languages besides DXL. This desire was rooted in my prior experience with writing automation scripts for Rational ClearQuest. Though quirky, I had found CQ very easy to automate using COM. Rational DOORS, on the other hand (owing most likely to its Telelogic origins) provides very little in the way of COM automation or any other interface besides DXL for automation. It is my opinion that this design decision is a legacy form of lock-in for the DXL language (and associated consulting charges). The COM automation for DOORS is limited to launching DOORS, sending it DXL code, hoping that the code succeeds, and then possibly receiving some string output. (Note that the opposite is true when DOORS is the client; automating other COM components is reliable, if tedious).

In addition to this simple COM server capability, DOORS also provides a similar socket server. It still requires automating DOORS using a fair amount of DXL code. If we accept that we are going to have to muck around with DXL code, possibly dedicating it towards providing an API that is driven by code written in another language over the socket, we can still manage to get a lot of work done. The usage of such a system seemed obscure to me at first (the documentation didn’t help a ton), but it was actually pretty easy to create a simple socket server in DXL and a socket client in Python. This is is where Python really shines.

Here is the DXL socket server code. This code can be executed in the DXL interactive editor. It will lock up the client GUI while the code loops waiting for connections. Connecting clients can then send arbitrary DXL code or the keywords “quit_” (to disconnect) or “shutdown_” (to shutdown the DXL socket server).

Here is the Python socket client code. First, to shutdown the DXL socket server, run the client script like “python IPC_Client.py —shutdown”. This will unblock the DOORS GUI. Otherwise, run the script without any arguments and the three print_* functions will send DXL code to the socket server and then print the returned results.