Tuesday, November 08, 2005

The blog has moved

I decided to stop using Blogger and moved to a dedicated hosting for blogging. Please check it out on max.textdriven.com.

Wednesday, August 17, 2005

Python programmer for sale

This's been a hot summer for me but now it ends, along with my contract work.

So if you need a (hopefully) good programmer, skilled in UNIX development, Python and Java platforms, agile methods and traditional engineering, please contact me. I'm interested in both short-term and long-term contract work.

Wednesday, June 08, 2005

pre-built mock classes?

There is a (relatively) widely used technique in unit testing, called mock objects. There is even a pMock library which provides a Mock class for a Python environment.


Given the "duck typing" nature of the Python itself, it's pretty trivial to build mocks without using any pre-built libraries. What is less trivial and potentially more worthwhile is to have a library of “stock” mock objects.


For instance, I found myself re-implementing ConnectionStub class again and again for different projects. And there is no shortage of other good candidates as well: socket, web request/response, thread objects, etc. Someone on a Python mailing list asks whether anyone implemented a mock filesystem interface, for example.


Having a library of such mock classes, realizing widely-used and “heavy” interfaces may be a good idea.


The only real problem I can think of is whether it’s possible to make these mocks generic enough. Mocks often contain some (application-specific) hard-coded rules and data to realize desired behavior. For instance, socket mock may fail when user attempts to write a “foobar” string – and unit test will use this to check how code handle these kind of errors. These rules may be generalized but it may lead to mock classes becoming unwieldy.


Even keeping this problem in mind, it’s still a reasonable idea for a library, but obviously I’m biased.


What do you think?

Friday, April 29, 2005

Non-obstrusive configuration

When writing an application the author has to think about wiring and configuration issues which often contradicts with fine-grained approach used during building it. These issues depends heavily both upon the design of the code itself (how much state does it have, how it is strutured) and the nature of the library (application) in question.

To clarify: an application consists of a number of functions/classes/modules each of them having (usually) a defined and well-understood scope and set of responsibilities. So far so simple - this is just good engineering practice. To get a coherent whole you need to wire it all together, configuring the parts along the way (network ports, passwords and other runtime options). And this is where it get messier.

How to achieve ease of wiring/configuration while not compromising on system's design on the same time?

I have run into these problems myself a number of times and almost every time has to come with some novel approach. Partly this is to be expected as different requirements calls for different solutions. Still, my own naiveness (experience level) has to play some role as well, as I may have missed some patterns obvious to a more experience programmer.

One of the biggest problems I had is that most of these solutions are obtrusive: once installed they tend to spread thru the code like viruses which hurts maintainability (if you ever change your mind and try a different approach) and code reuse.

The rule of thumb I've learnt so far is to try to split the application into two parts: core (a "library" in a traditional sense) and, um, application itself. While this does not solve the problem, at least it puts it within well-defined boundaries. OTOH, when this "application" gets incorporated into something still bigger you have to overhaul it again which is no good. Even without incorporating, the "library" part sometimes became smaller than the "application" part, which spoils the whole idea.

To put at least some meat into this post, I'd like to mention PyContainer library of Rafal Sniezynski, which is a Python implementation of "Inversion of Control" (IoC for short) idea. IoC in general and various implementations (called "containers") is a hot topic in Java community.

On the surface, this is exactly what I'm looking for: container manages wiring and configuration of its object according to given set of rules. But I can't tell for sure until I try. What I like most is the perceived level of obtrusiveness (lack of): components that go within container have no idea they are within "something" and thus can be developed, unit-tested and reused freely. Only part of the application that uses the container has to deal with it - and my only concern is to make it as small as possible.

P.S.: Re-reading my post I realized that problems I'm talking about may not be so obvious and/or so painful to the readers as they were to me. What was your experience? Do you share my frustration?

Wednesday, March 30, 2005

A problem with Python

Ian Bicking wrote a passionate post where he encourages community to put more efforts into Python-for-web-application domain.

I have another complain about the Python (both for language itself and tools and libraries around it). Here it is: Python cannot fully utilize hardware resources. You see, I have several [web] programs running on my machine, some in Java and some in Python. Some of these are the apps I'm writing and debugging myself, some are third-party.

When I'm working on Java app, I have some serious stuff loaded: Eclipse IDE, Tomcat web server, database server, Firefox with API documentation opened, etc. Basically, you need 1Gb of RAM to have it all work smoothly. And even then it takes 12 seconds to redeploy an application. And we all know Java technology has sophisticated JIT compilers which means execution speed is much higher compared to Python.

What do we see in Python? Instance of Vim editor, WebKit/Apache server, may be a Firefox running and a database. That's all. How much resources does it take? Nothing. How long does it take to redeploy a WebKit application? Nothing again. In fact, you could develop Python app on some archaic Celeron-666/256 Mb box and notice little difference with modern Athlon 2800+/1Gb. At least, that was my experience.

What the heck?

If the language can't make a serious load out of modern hardware it can't be nothing else then a toy language, right? Programming is hard and it must feel that way.

Therefore, I ask the community to put more efforts to "grow" both the language and the tools. The day I see my python application deployed in a 12 seconds to a WSGI-backed WebKit I know: we have a serious, mature language. No, not a "language" - it'd be called a "platform" by then. Definitely.