from Rock import Fort

by jesse in


Why yes, I have been living under a rock. For those who don't know - I'm getting married in June, so my life has been a little crazy with that stuff, and trying to tie off some of the hemorrhaging arteries at work. No, I don't think the building will burn down without my presence, but I do think I need to tie off some of the key projects I have been working on prior to me vanishing for a a few weeks.

This sort of ties into why I hate vacations. Don't get me wrong - I know a person needs them, god only knows I need one bad - but going away leaves your company/team flat if they have to interface/work on your projects, and it always throws you behind the curve on events.

In any case - things progress. I've had my nose buried in the installer system I've written. I've discovered a few things which surprised me (i.e.: The SimpleHTTPServer stuff in python does not support byte-range support (the inclusion of new modules in 2.5 should help that) and all in all, I think my grasp of more abstract concepts within python is improving.

RE: A Previous post about libraries, I've found myself pushing the internal QA team to build out a nice shared Python Library which the tests/applications can leverage as part of normal runtime.

I set the requirements to be fairly clear - PEP8 compliance, clear documentation, etc. I've also been fairly retentive about the "generic" nature of the included libraries - that's caused some friction when dealing with things to be put in, but I see it as the only way to really manage the library itself.

For instance - say you have a module from the STL in Python - let's say the SimpleHTTPServer module.

Now, person X comes to me with an implementation of an HTTP server. Except it's not just that. It's an http server that only runs on a certain port, serves certain file types, is not threaded/thread-safe, etc. My tendency is to say "no" and to work with them to make it into a less specialized version of the library.

The reason is simple - for shared modules/code, I feel it is really important to take away the methods for the exact implementation that person needs and only include those which lie outside of that implementation - the "Generic" functions/methods. This way, the module is more general-use then highly specialized.

Oh, it's the story of my career - avoiding over-specializtion.

Don't get me wrong - I think there is a place for specialization. By a module's very nature, that module is specialized into a specific function/role. The specialization I am talking about lies directly with the role (i.e: Server Web Pages) of the library, not the implementation (Server on port 3289, only php files) of the library.

Blech, I'm rambling.

In any case, if you haven't seen it, Goooogle is talking about having an Automated Testing get together in London (I've never been there) - I was thinking of typing up a paper for presenting, but there's a bit of an issue with what information I can share, versus what's considered IP for the company.

More information can be found here: conference-on-automated-testing