How to write good Kamaelia components and systems
Posted by Jason Baker on July 15, 2008
I’d like to apologize for two things:
- For not posting to my blog in so long.
- For not continuing the distutils discussion. I’d kind of abandoned the idea for using distutils to distribute my app, but might end up using it to package my gateway, so stay tuned.
With that said, I think it’s time for me to share my views on the subject of what a good Kamaelia component is. Some of these are general rules of thumb of computer science, but they bear repeating here too. So here it goes. My rules for writing good Kamaelia components:
- Keep it simple, avoid premature optimization, and take small steps. If you’re not totally new to programming, you’ve probably heard this a million times before. But a reminder never hurts.
- Design your components to work well with others. You don’t know what someone else will want to use them for. For example, I’m using Ryan’s HTTPServer code to serve webpages via XMPP. I won’t get into the technical details of how that works here in my blog, but suffice it to say that I’m using Ryan’s code for something I’m for sure he didn’t imagine it would be used for. And it works pretty well. Make sure to keep in mind that rule 1 overrides this rule, though. Don’t convolute your code because you think someone else may want to use it later.
- Don’t forget about shutdown handling. Let’s face it. Making your components shut down properly in Kamaelia/Axon is a pain. I think Michael and Matt will both agree with me on this. But don’t ignore it. That will only make the problem worse.
- Beware the “one true” programming paradigm, including Kamaelia. Since I’ve been programming in Kamaelia, I’ve begun to wonder how I’ll ever transition back to “normal” programming. Indeed, Kamaelia is a fun and inventive way to program concurrently. But that doesn’t mean that it’s best suited for every situation. You may find that it’s better to just go with plain old structured or object oriented programming for some problems. And there’s nothing wrong with that. Personally, I use what I like to call a “wrap around” rule. That is to say, I always try to progam the solution I can wrap my head around the easiest. Chances are, I can get Kamaelia to do just about anything I want it to do. But if I find myself unable to fathom how I’ll do something in Kamaelia, I don’t do it in Kamaelia.
- Be creative and have fun. I constantly am trying to think of new ways to do old problems. And sometimes it doesn’t work out so well. But the worst case scenario is that I learn a new way not to do things and have to start over. Best case scenario is that I find something innovative.
- Be lazy. I won’t get too much into the specifics of this, but I see a lot of components written using a lot of unnecessary code. For example, when you check an inbox, how many times have you written the following lines of code:
while self.dataReady('some_inbox'): msg = self.recv('some_inbox') do_stuff_with_msg(msg)
You may not realize it, but Axon components now have a built in function Inbox that takes care of two of those three lines for you. Thus, those three lines can be written using a simple list comprehension:
[do_stuff_with_msg(msg) for msg in self.Inbox('inbox')]
In my opinion, that’s a lot more readable than the first version.
You may agree or disagree with the points I bring up. And that’s fine. But those are my views on what it takes to write good systems using Axon and Kamaelia.