On the usefulness of Akoma Ntoso

There's been very few laws that I followed closely, but all of them had a direct impact on my life, so I took this seriously. I didn't actually follow laws, but rather legislative processes because I either wanted a change or I was averse to it. In both cases, the object of interest was not a law itself, but its evolution.

You should already know that most laws are hand-crafted patches applied to previous laws. There are virtually no laws that are written from scratch, one notable exception is the constitution. Other laws refer to past laws.

For example, today's law that extends the powers of the Belgian intelligence service is a patch applied to the law that created the service in 1996, and it says literally this:

  • Go the the article 3 of the past law and append this extra paragraph
  • commit your changes in the legislative branch
  • push to the executive branch

If you go and search for the original law, you won't find it that easily, because laws were digitized back to 1998, while the original law dates from 1996. If you are lucky, you'll have free online access to the so-called 'consolidated' version of the law. That is, a version with all the patches applied. However:

3 disruptive technologies that will change policymaking

Version-controlled laws

Here's a EurActiv article that gives a bird's eye view of the subject of version control systems applied to legislation.

End-to-end verifiable anonymous voting

This one is better explained by Wikipedia. Here's the description of the simplest of such voting systems.

Inline comments

Here's the best implementation of inline comments until now.

 

Tags: 

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

SugarCRM

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
WHERE email IS NOT NULL
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.

Pages