Apr 15 2018

Developer-friendly job search. The tooling

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.

Apr 23 2015

CherryPy questions: testing, SSL and Docker

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.

Jan 25 2015

Future of CherryPy: bright and shiny?

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.

Dec 08 2014

Qooxdoo “next” and targeting website development

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.