When EU institutions write about opensource… it reads like a good joke

Here is an excerpt of the Legal aspects of free and open source software workshop notes. Every phrase is a masterpiece.

"When the public agency has decided that open source requirements are particularly important for a specific software acquisition case, the process described in this section can be followed. This process would end in the agency downloading open source software itself, with no fee paid whatsoever. Separately, commercially provided services and support, if required, may be acquired by publishing calls for tender. Note that this process can be abandoned at any point - for instance, if the software cannot be found easily, or evaluated, or once downloaded is found unsuitable for any reason. At that point, the other approach described in the next section can be followed, namely, publishing a call for tender for open source software."

A visual argument against mass-market CRM software

I had this stuck in my head for months, but only now managed to have some time to write it up

Below are two snippets of SQL code that do the same thing, namely extract the number of contact emails per year from a CRM. The result in both cases is something like the following:

| count(*) | y      |
|     1142  | 2012|
|     1148  | 2013|

The first query is written against a heavily customized SugarCRM instance. The second is written against my own home-made CRM


SELECT count(*), year(email_addresses.date_created) y
  FROM email_addresses LEFT JOIN email_addr_bean_rel
  ON email_addr_bean_rel.email_address_id = email_addresses.id
  WHERE email_addresses.email_address LIKE '%@%'
    AND email_addr_bean_rel.bean_module = 'Contacts'
    AND email_addr_bean_rel.deleted = 0
    AND email_addresses.invalid_email = 0
    AND email_addresses.opt_out = 0
    AND email_addresses.deleted = 0 GROUP BY y;

Custom CRM

SELECT COUNT(*), YEAR(created_at) AS y
FROM clients
GROUP by YEAR(created_at);

It should be obvious even for a non-programmer which is easier to understand. What is not obvious for non programmers is the amount of effort one needs to make before SugarCRM starts doing things it was not designed for. I could now start talking about the importance of data structures and how the UI is irrelevant, but this will take more pages than Google can handle.

How the European Commission disrespects its own cookies directive

The most popular interpretation of the cookies directive is that websites should warn about cookies that are not essential for the operation of the websites. For instance, a cookie set to keep the items in your shopping cart is essential for the operation of an online shop and users should not be warned. If the cookie is set to track user activity for marketing purposes (e.g. by Google Analytics for targeting ads) — that's not essential, and the user should be warned.

The main website of the European Commission sets cookies to store information on surveys. This is not essential to the operation of the website, so technically they should warn about it. Bit they do not. OK. that's a small problem, they are almost clean… on sufrace.

If you look a little bit further, you'll see that parts of ec.europa.eu set Google Analytics cookies for the whole ec.europa.eu domain. For instance, EURES homepage sets Google Analytics cookies __utma, __utmb, __utmc and __utmz for everything at ec.europa.eu, as well as a couple of other cookies for itself,  such as eures_client_nr and piwiki_visitor, as well as a EURES_SESSIONID.

An example of project management workflow

Here's an example of software project management worfklow that I use daily.

Each project is split into two uneven parts:

  • Definition of project scope and objectives
  • Project execution and follow-up.

The main difference is that the former is document-based while the later uses a bug issue tracker

For definition of project scope and objectives, we edit a series of documents:

  • Personas — a list of different kinds of people that may be using the product, e.g. readers, clients, journalists, etc
  • User stories — a description of how these personas would use the product
  • Functional requirements — a non-technical list of features induced from user stories
  • Technical requirements — a list of technical features, induced from functional requirements
  • Budget estimation — based on technical requirements and team skills.

There's also an optional Traceability matrix — a many-to-many mapping between functional requirements and technical requirements.

For project execution and follow-up, we use an issue tracker Assembla to define:

  • Milestones — e.g. "Freeze data structures"
  • Tickets — for individual tasks, such as "Update the logo"
  • Components — to group tickets by origin or subproduct, e.g. "Marketing & Sales requests", "Newsletters"
  • Time — estimate and invested time, related to a ticket or not.

How screen resolutions changed over the past 7 years — it's not the mobile revolution, dude

This picture is well worth a thousand words. It shows 7 most popular screen resolutions on a mid-sized website in 2006 and in 2013. 1024x768 was taking a lion's share in 2006 but there's no clear winner in 2013. Websites that were designed to be best viewed in 1024x768 look much worse on the majority of screens nowadays.