It is quite interesting to me to see how software job market works in the Netherlands
from an active candidate’s point of view. Unfortunately one great journey has almost
ended and there is a firm incentive to find something at least as good. Having my
current job through StackOverflow Jobs, I intended to keep using what proved to work,
like marking the profile active, entering python -django -sysadmin into the search
field, adding relevant filters and subscribing to the search. That, as such, of course
works, but it looks it is not the most popular software talent recruitment service
that Dutch companies use. And many companies are still quite happy to pay 20% of the
gross year salary per new hire to the volume-oriented keyword-matching salesmen,
colloquially referred as recruiters.
Basically this is a CherryPy work-in-progress article. However, it aims to draw the line
with testing infrastructure I was working on, as it seems to be completed. The article
covers what has been done and what issues I met along the way of reviving the test suite
to serve its purpose. The way is not traversed fully of course and there’s a lot left to
do. It also seeks to justify concerns about CherryPy SSL functionality’s correctness and
viability. As well, it tries to answer appeared questions about official Docker image and
its range of application.
First off, I really hope so, tough at the same time I see the reasons for it. Moreover
I have been trying to contribute back to the community by giving knowledge that could hopefully
cut the rough edges that I’ve met on my way of learning and employing CherryPy [1]. And when
CherryPy is calling, I have something to say.
This article is my consideration in reply to the holiday post [2] by Sylvain Hellegouarch
in CherryPy user group about its current state and future, which recalls to older big
discussion [3] about the status of development of CherryPy.
Initially, this post was meant to be an open letter to Martin Wittemann, an urge to do not break the only
robust and consistent JavaScript development environment, in sense of bug #8618 [1]. How robust and
consistent? Most importantly it is about:
- Code structure: modern feature-rich object model with properties, events, interfaces, mixins and more,
namespace tree, data-binding,
- Dependency management: automatic and transparent dependency resolution, component packaging,
- Deployment: code optimisation, single- and multi-part builds,
- Standard library: i18n, CLDR, high level BOM API, normalised events, normalised ECMAScript, test
infrastructure, API documentation, feature detection.
All this comes out-of-the-box, builds layer on layer, is seamlessly integrated and handed to an end developer
on a silver platter. The codebase is one of the best quality I have ever seen. It is readable,
comprehensible, possible to extend, and is a huge a knowledge resource per se. And note, I am talking about
tools and environment, not UI. Like former Qooxdoo developer, Fabian Jakobs, stated in one of his
presentations [2]:
Don’t just look at the widgets, look at the development tools as well.
Luckily, as was recently stated in Website fundamentals: next challenges [3], the “next” (branch and then a
separate repo [4]; later referenced Next) turned out to be a experimental website-oriented fork of Qooxdoo,
which doesn’t mean to be merged back to Qooxdoo. At least any time soon. Panic is soothed, impending doom
doesn’t overhang the good times. It’s time to dissect and discuss.