I am not one. Not yet. I tend to generalize the problems and go for a more complicated solution instead of directly going for a solution. I tend to move the discussion on a more theoretical area. It’s not a bad thing, not always. But if you happen to work with deadlines it might not be the best strategy. This is a critic I receive about my work time to time. Solution is not totally giving up but to know when to generalize and when not to. I am working on it.
For example I wrote earlier that I gave up my pet project when Enso went open source. That was a very logical decision. At the end I wanted the functionality in the first place. Although writing your own gives a different satisfaction I had one of that rare moment and think about “cost/benefit” ratio. After all I would still write my own commands and taste that satisfaction anyway. So I put things on hold and wait for the windows code to come out. Meanwhile I re-installed Enso and start playing with developer prototype. First wall I hit was the way user commands are handled. User commands and Enso communicates through RPC and firs you need to write your own RPC server. It’s not something big but that means your command is actually another application which communicates with Enso rather then embed itself in Enso and share the same process. I don’t know you but since I read few articles on OLPC I changed the way I look at the resource usage (CPU and RAM mainly), having enough CPU power does not justify the unnecessary CPU load for example. Think about, when you are shopping you pay the money based on how much they worth not how much money you have (I will not go into some branding and actual worth discussion here, but it’s the basic idea at least). I already have problems with Enso using some extra memory (an issue addressed before and promised to be solved hopefully). There is a Command Server implementation to ease the developing of user commands, which I tried, but still it is an extra python process which should be started manually in addition to Enso. By the way, Enso open source version promises a different way of command handling so this issue will be absolute soon. I ported one of my own commands to Enso, the one I use to write accent characters (from Turkish and Romanian) without switching to keyboard language or using insert symbol menu. It was pretty straightforward but I ran into few problems. It was mainly how Enso handles the commands (they are all lower case) and how the command server was propagating Enso calls to user commands (dropping command name argument from execute function for example). Nothing too major but like a piece of stone in your shoe… I guess I am trying write down all my excuses to re-start my pet project. So I can keep it short as well.
Yes, then I decided that writing my own was a nice learning environment and if I had to loose time on such issues anyway, I could waste that time for my own code. So I started back. Of course after playing with Enso, first thing I wanted to make was changing the GUI. I used wxPython for the first version but GUI itself was quite small (a frame, application icon, one text editor and one list box in total) and wxPython was the major contributer to the memory usage (over 14MB out of 20). I spent quite a time looking for a light wight alternative. I also checked the Enso’s code to get an idea. And somewhere I woke up… I was wasting quite a time which does not really change the functionality. OK, it would give some memory back but memory was not the main concern at this stage, it was the functionality. Although I still say you need to justify the resource usage, being a single developer, you also need to make up your priorities. So I decided to use a single HTML window to display the user entered text. I will not hide the fact that colors are inspired from Enso, another issue that I decided to postpone. This tiny little decision greatly affected rest of the process in few ways:
- Limited development resource (me) can be used for more important stuff
- Application got a more professional look and it boost the motivation (sort of turbo mode for coding)
- Look on my wife’s face changed so I didn’t feel like I had to give excuses why I am wasting my time on this stupid looking text editor and list box
With this quick gain, I decided to do few more changes and ended up almost redesigning all on the fly. I had few more places where I thought application should support but I never actually needed. For example it supported states for commands. When it is activated all commands are listed, but then when user makes a selection and confirms (using tab to commit the selected command) command can provide a list of arguments if it has any. User can give an argument, use tab and go to next state still in the same command. This way a command can provide several options for each argument level. Handy if you need to provide several arguments for the command. But it created usability problems and managing the states were problematic. Also when I start using the application I noticed that for this application trying to provide multiple arguments was not really a good idea. If your command needs more than one argument, then better to go for a GUI solution (IMHO). So I cleaned up all this generalization form the code. Code size reduced remarkably and it was a lot easier to maintain. Also writing user provided commands become easier.
I decided to keep working on this tool and use it as a glue application for my quest on software development process. There’s plenty of things to do and learn with this tiny application. And now it’s fun to use and develop even better.
I didn’t put a link to my pet project yet because first installation process is still not pain free, second I don’t have a good name for it yet, Enso is already taken
And no before/after screen shot yet since I just noticed when application is activated print screen does not work, I minor issue to fix. Later.