…never trust what the user tells you.
…when none cares what operating system he is using.
Ok, ok… it's just one of the mandatory requirements.
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."
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;
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.
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
__utmz for everything at ec.europa.eu, as well as a couple of other cookies for itself, such as
piwiki_visitor, as well as a
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.
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.
Remember my story about Neelie Kroes hacking EU-Azerbaijan relations? I made a Freedom of Information request to DG Connect, and they replied that there is no forensic report whatsoever that studied this "hacking" attempt. We may thus safely assume that there was no hacking whatsoever. See the attached reply below.
… — Do you have a mortgage?
Seriously, an employee with a mortgage to repay is submissive and risk-averse. Exactly the kind of person most businesses look for.