This version of the page http://maxischenko.in.ua/blog/page/18/ (0.0.0.0) stored by archive.org.ua. It represents a snapshot of the page as of 2008-06-12. The original page over time could change.
Max Ischenko’ blog

profiling unit tests

November 1st, 2004
As were already noted elsewhere, the so-proud-of, “batteries included” Python standard library has a lot to be improved. And while Java tools often being critiqued as overly complex, many of python modules are arguably simplistic, not just “as simple as possible”.

I run into this just yesterday, when tried to profile my unit tests.

Usually unit tests run in a fraction of a second. Sometimes though, most often because of some heavy-weight interface not being stubbed, they suddenly could take a several seconds. So I thought to myself: “It would be nice if I could a get report about which test methods ate most of the time”.

After struggling for half an hour with a profiler (hotshot or the old one, whatever, they both use pstats module) I give up. Sure enough, I could get an overall program statstics, even filter it by name of the function with a regexp, but there were no way to trace from the actual function (like socket.connect) to a test method that called it (like testReportServerStatus). Or at least, I didn’t find it. The latter is probably the case and the reason I was not able to find it is because pstats has a contrived API. I would say, almost a lack of it thereof. When called, it just prints to the screen what’s been told but have no way to just return accumulated statistical data lump, so I could play with it by myself.

But then another idea came to my mind. Why do I have to struggle with a profiler in the first place? I already have a framework (unittest, that is) which handles the task of runing the test methods. It should be simple to extend it to allow time measurement and report results, shouldn’t it? Well, it turned out more or less simple.

I had to extend both TestSuite class and TestRunner but it did worked. The only major problem I encountered is that TestSuite per se has no idea from which module a particular test has come. Luckily, I was already using my own function to gather test suites so it was simple to establish a module-to-suite mapping. Still, it prints only name of the modules not name of the actual test methods but at least it works. Any idea how to fix this is welcome, though.


Programmer’s HowTo

November 1st, 2004
Several years ago, when trying to master Linux I had to read a lot of documentations, man pages and HOW-TOs in particular. The topics covered by these manuals/how-tos were rather routine (as it seems to me today) - things like modem setup, font setup, pppd configuration, etc. The distinguishing feature for most of the good ones is that they’re tightly packed with useful information - often I had to re-read them in order to grok completely.

Recently I stumbled upon another HOW-TO: How to be a Programmer by Robert L Read. While he addresses a different topic - the topic of a professional growth as a programmer - he managed to preserve the spirit of these HOW-TOs: concise, clear and packed with insights.

That’s one of the best texts I had read on a topic in the last few years and arguably the one with the best size/usefulness ratio. It’s a pity I haven’t encountered it earlier (the first version was released in 2000).


Best Software Essays of 2004

October 1st, 2004
An interesting discussion has opened on Joel On software forum - Joel asks readers to post essay which they consider were the best essay on software in 2004 (2003 is accepted as well). Great way to discover articles and/or authors you may have missed.

As it turns out, I’ve already read about a third of them and they were indeed excellent. Looking forward to consume another two-thirds though.

Check it out here: Best Software Essays of 2004.


Google Desktop

October 1st, 2004
In recent weeks/months Google literally flooded us with new products and services. Yesterday they released a Google Desktop — windows application that indexes your hard drive and provides an integrated search: both for web and local files simultaneously.

I don’t intend to describe it in details here or post screenshots how it looks on my computer. Just envy to those guys that happen to be in the right place to work for Google and have an itch to build something remarkable by myself.

update: Bloglines’s Most Popular Links puts google desktop on the top, with +641 increase from yesterday! I guess it’s more than all other delta combined.


sofware as a service

October 1st, 2004
disclaimer: I’m nor a business wise nor I pretend to be one, so the following thoughts may be just bogus or make you laugh. OK with me. But if you laugh, please spare a minute and enlighten me as well.

I regret I couldn’t attend Web 2.0 conference, as it turned out to be quite fruitful for ideas, both for business approaches and technical questions. I did listen to some of the talks given on the conference, thanks to ITconversations and The Web 2.0 weblog sites.

One of them was a Gillmor Gang from October 8, 2004 on which Kim Polese (CEO), presented her new company, SpikeSource. Their business model assumes building a “solid product offering” on top of open source components. For their launch, they’re planning to offer a product stack that would include MySQL, Apache, PHP and JBoss. In the future, they would create new offering, driven by the customer’s demands. And they have been developing a “deep computer science” code that would allow (as I understood) to build and maintain these product stacks in a (semi-)automatic fashion. They are going to earn money from the support, training and other service-type activities, contributing the code back to the open source community.

While the idea looks interesting and the talk is quite entertaining I wonder how good this approach would scale in terms of revenue. One of the nice things with software is it’s “softness” - once you built a product it costs nothing to duplicate (and sell) any number of copies. With any service, costs to run it usually proportional to it’s size. Plus, scaling it depends on people - which mean you need right stuff, with appropriate training, experience, etc, etc. So, basically, building a software product is (potentially) much more profitable than selling a service and it’s much easier to sell.

The SpikeSource (again, IIUC) has two assumptions to address this issue. Firstly, in the brave new world that’s coming software components (at least, at the infrastructure level) are a commodity and hence it’s very hard to squeeze a revenue in this market niche. IOW, could you build and sell a web server? Probably only a very specialized one, because it hard to compete with Apache. Secondly, there would be a custom software in their offering, as an value-add for basic OSS components. So, the success would depend on whether they could add enough value to the commodities to attract customers.

P.S.: I had read a couple of months ago about a similar initiative to provide a solid OSS-based platform for enterprises on top of Debian but just can’t find a link. Pity.

P.P.S: About a year ago, I was dreaming about starting a similar company here in my country (Ukraine) but not having had enough experience, money and courage I put it aside. So I’m a bit envious (again). ;-)

update: google search for “Lightweight Business Models” turns up quite a few interesting links.
update: fascinating post from Jason Fried about “human scaling” and some intrigue details about the Basecamp product.