Read my book

I wrote books about Webpack and React. Check them out!

Tuesday, December 22, 2009

Placidity - Part 6, Plugin Architecture III

Previously we separated commands as plugins. We also prepared the interpreter so that commands may be provided to it. I will look into implementing a plugin loader in this part of the series.

Monday, December 21, 2009

Placidity - Part 5, Plugin Architecture II

The commands provided by the interactive interpreter were separated as "plugins" in the previous part of this series. Currently they are totally separate from the interpreter part. I will look into hooking them up with the interpreter in this part, at least on mock level. :)

Sunday, December 13, 2009

Placidity - Part 4, Plugin Architecture I

In the previous part of this series we finalized the variable related functionality and implemented a simple "help" command to help the user. I concluded the post by noting the structure of command architecture could use some extra effort. Let's focus on that in this part and come up with a proper plugin architecture.

Monday, December 7, 2009

Placidity - Part 3, Variables II

So far our interactive interpreter handles simple math expressions and variables. After last post I realised it would be useful to have a way to print stored variables and to remove them. To make our interpreter easier for the user it would be useful to provide "help" command as well. I will implement those features in this blog post. So let's get to work.

Sunday, December 6, 2009

Placidity - Part 2, Variables I

The first part of this tutorial series showed how to set up a Python project and use py.test test runner for Test Driven Development (TDD). Before proceeding any further, be sure to check it out as this part will build directly on it.

In this part of the series I will focus on implementing some additional functionality to our interactive interpreter. The main goal is to show how the behavior specified in the tests helps us to shape it up. Last time we managed to implement an interpreter that could be used to perform simple calculations. It would be extremely useful if it was possible to store the results into variables and then reuse them as part of calculations. Let's focus on that next.

Placidity - Part 1, Getting Started

I remember one of the first applications I ever wrote was an interpreter implemented in BASIC. Essentially it just provided the user some questions and then gave back amusing answers. Of course the most known example of this sort of application is Eliza.

Instead of writing an Eliza bot, I'm going to show you how to write one similar to the one provided with Python. The easiest way is just to extend the current implementation [1][2]. I'm not going to do that in this tutorial, however.

Initially I tried to write this tutorial by slowly accumulating working bits of code and then restructuring it as new demands came up. After a while I realized this approach was far from good. At one point I ended up doing some nasty looking metaprogramming with Python's magic methods. That's when I decided it's time to try out a better approach.

Rather than just diving into the code, it's possible to take a look at this problem a bit different way. We could come up with a some sort of class design (see UML) or try a different kind of development approach and worry about design as we go.

As it is quite easy to specify the behavior of an interactive interpreter, I believe it's better to try the latter alternative in this case. I'm going to use Test Driven Development (TDD) approach to achieve this.

If you have never heard of this technique before, it may seem a bit backwards first. Instead of writing the code first and testing it later, in this case you focus on the tests first and derive the code based on that. Any code that does not map to some existing test can be considered to be "dead" and should not be there. In principle the code coverage of tests should be 100%.

So how should the tests be written then? As I stated before it's all about specifying behavior. TDD is an excellent technique to use for specifying an API. Note that it is not a design technique. However, it allows you to refactor your code. This means that you can alter the structure of the code while retaining confidence in it. Essentially it helps you to avoid those nasty regressions that so easily sneak into code.

Before writing any tests, let's set up the project!