Category: Technology

Introducing Adaptive CV

16 December 2016

Now that I have got a new position, I will not be jealous if someone uses the same CV template as mine 🙂 Therefore, I decided to publish my CV template as open source. I call it Adaptive CV.

Alessandro Rossini's CV

Adaptive CV allows compiling different variants of a CV (e.g., a résumé and an extended CV) from a single LaTeX source. It is particularly suitable for academic CVs but flexible enough to be used with any CVs.

You can create your Adaptive CV on Overleaf or fork me on GitHub.

Please let me know if you have comments or questions, and good luck if you are seeking a job!

A step forward in my career

28 November 2016

Dear friends and colleagues,

I am excited to announce that I have accepted a position as Senior Advisor at EVRY Cloud Services in Oslo. EVRY is the largest IT company in Norway and among the largest in the Nordics with almost 10 000 employees. Cloud Services is a new business area of EVRY that offers advisory and consulting services to assist customers with designing the cloud solutions that best fit their requirements. I will start on the 1st of March, and I am looking forward to it!

EVRY at Fornebu

I would like to thank SINTEF for four rewarding years with the organisation; I will try to be a good ambassador for SINTEF in the future.

With optimistic wishes,
Alessandro

No, email is not a collaborative editing solution—A comparison of the state-of-the-art

11 May 2016

If you have co-authored at least one document in your life, you have probably experienced the pain of merging changes manually, especially when these changes are sent as email attachments.

Email is not collaborative editing
Source The Oatmeal

Nowadays there are multiple collaborative editing solutions that enable merging changes automatically. Unfortunately, many professionals are not aware of the capabilities offered by these solutions and keep sending changes as email attachments and merging them manually. Believe it or not, these professionals include software engineers and computer science researchers.

I think we can do better than that…

In this post, I aim to clarify the confusion around collaborative editing solutions by comparing the state-of-the-art:

The comparison is based on several criteria:

  • On-line co-authoring: the ability to edit on-line while seeing others’ changes in real-time
  • Off-line co-authoring: the ability to edit off-line and merge changes automatically when back on-line
  • Version control
  • WYSIWYG editor
  • LaTeX editor
  • Formatting capabilities
  • Support for OOXML format (DOCX, PPTX, XLSX, etc.): unfortunately, this proprietary format from Microsoft is still the most used document format
  • Support for OpenDocument format (ODT, ODP, ODS, etc.): this ISO standard format is used by many public institutions
  • Terms of service

Google Docs + Drive

Google Docs + Drive is probably the most used collaborative editing solution. It was released in 2006.

Pros

  • On-line co-authoring in the browser
  • Version tracking
  • WYSIWYG editor

Cons

  • Off-line co-authoring in Chrome only
  • Minimal formatting capabilities
  • Read-only support for OOXML format
  • Read-only support for OpenDocument format
  • Google Terms of Service

Unfortunately, the contras of Google Docs + Drive outnumber the pros.

The read-only support for OOXML and OpenDocument formats is particularly annoying. When you first edit a file in OOXML or OpenDocument format, Google Docs automatically creates a copy of the file converted into Google Drive format (GDOC, GSLIDES, GSHEET, etc.) without notifying you. For instance, this means that when you first edit a DOCX file, you will not edit this file as you would expect, but its GDOC copy, and you will end up having two copies of the same document in Google Drive. This may confuse you and your co-authors since you will be unsure about which copy of the document is the latest one. Moreover, this may compromise the formatting since format conversions are not always lossless.

Besides, the Google Terms of Service are particularly alarming. I am not a legal expert, so take my judgement of the terms of services with a grain of salt. Nevertheless, the Google Terms of Service (see the excerpt below) are most likely not suitable for co-authoring confidential documents.

“When you upload, submit, store, send or receive content to or through our Services, you give Google (and those we work with) a worldwide license to use, host, store, reproduce, modify, create derivative works (such as those resulting from translations, adaptations or other changes we make so that your content works better with our Services), communicate, publish, publicly perform, publicly display and distribute such content.”

Microsoft Word + OneDrive/SharePoint

Microsoft Word + OneDrive/Share Point is Microsoft’s answer to Google Docs + Drive. It was released together with Office 2013.

Pros

  • On-line co-authoring in the browser with Word online
  • On-line and off-line co-authoring with Word 2016 for Windows
  • Off-line co-authoring with Word 2013 for Windows, Word 2016 for Mac and Word for Windows Phone, Android, and iOS
  • Version tracking
  • WYSIWYG editor
  • Sufficient formatting capabilities
  • Support for OOXML format

Cons

  • No native support for OpenDocument format
  • Microsoft Services Agreement?

Microsoft Word + OneDrive/Share Point is superior to Google Docs + Drive by any criteria. I could not find any paragraph in the Microsoft Services Agreement that looks as scary as the one from the Google Terms of Service. Nevertheless, I am not willing to give Microsoft the benefit of the doubt, so I keep this agreement with a question mark in the list of contras until a legal expert proves me that it is suitable for co-authoring confidential documents.

Overleaf

Overleaf is the ultimate collaborative editing solution for LaTeX enthusiasts. It was released in 2013 (then called WriteLaTeX).

Pros

  • On-line co-authoring in the browser
  • Off-line co-authoring with Git
  • Version labelling
  • LaTeX editor
  • Maximal formatting capabilities

Cons

  • Steep learning curve for non-academics
  • No support for OOXML format
  • No support for OpenDocument format
  • Overleaf Terms of Service?

Similar to the Microsoft Services Agreement, I could not find any paragraph in the Overleaf Terms of Service that looks as scary as the one from the Google Terms of Service. Nevertheless, I keep these terms with a question mark in the list of contras until a legal expert proves me that they are suitable for co-authoring confidential documents.

Summary

The following table summarises the features offered by each of the compared collaborative editing solutions.

 On-lineOff-lineVersioningWYSIWYGLaTeXFormattingOOXMLOpen
Document		Terms
Google✓✗✓✓✗✗✗✗✗
Microsoft✓✓✓✓✗✓✓✗?
Overleaf✓✓✓✗✓✓✗✗?

Is there a clear winner? I do not think so.

If you are a perfectionist in formatting and prefer working with LaTeX, Overleaf is the solution for you. If you are not too concerned with the formatting and prefer working with WYSIWYG editors, I recommend you to choose Microsoft Word + OneDrive/SharePoint.

I belong to the first category, and I co-author scientific papers using Overleaf only. However, I have to admit that Microsoft has done an excellent job with its collaborative editing solution, and I do not mind co-authoring other documents such as project deliverables in Word anymore if my colleagues ask me to.

We can put an end to imperial units

30 November 2014

“In metric, one milliliter of water occupies one cubic centimeter, weighs one gram, and requires one calorie1 of energy to heat up by one degree centigrade—which is 1 percent of the difference between its freezing point and its boiling point. An amount of hydrogen weighing the same amount has exactly one mole of atoms in it. Whereas in the American system, the answer to ‘How much energy does it take to boil a room-temperature gallon of water?’ is ‘Go fuck yourself,’ because you can’t directly relate any of those quantities.” Wild Thing by Josh Bazell.

I have not read Wild Thing, and I do not have any idea about who Josh Bazell is, but I love this quote. It brilliantly summarises how superior the International System of Units (i.e., the modern form of the metric system) is to the system of imperial units, as shown in the following illustration:

Visual comparison of metric and imperial units

Yet, nowadays…

The USA is the only industrialised country in the world that still uses a system of units developed from English units (i.e., the United States customary system), as well as the only industrialised country in the world that has not adopted the International System of Units2(see Metrication in the USA).

Canada and the UK have adopted the International System of Units, but their metrication process is far from being complete (see Metrication in the UK and Canada).

Despite the fact only a minority of countries have not adopted the International System of Units, the majority of countries are still contaminated by the system of imperial units. Think about it… Even in continental Europe, where the metric system comes from and where the imperial units are nowhere in the education curriculum, screens are measured in inches, aircrafts’ altitude is measured in feet, watercrafts’ speed in measured in knots, etc.

The problem is that, to anybody who grew up with the International System of Units, an advertisement of a 55” TV screen tells very little about the actual size; a captain announcing that the plane is cruising at 30,000 feet tells very little about the actual altitude; a speedometer showing that the boat is cruising at 20 knots tells very little about the actual speed.

This is ridiculous and has got to stop. Governments of all countries adopting the International System of Units have to enforce that this system is used in absolutely every application and that any trace of imperial units is consigned to history.

If you are a man or woman of science, or if you simply have common sense, please share this post on every social network, and tag your tweets and instagrams with the tag #banimperialunits.

Here are some examples of tweets that you can send to your politicians.

Inch is not an official unit in Norway. Why are screens measured in inches and not centimetres? #banimperialunits

Foot is not an official unit in Italy. Why does the aviation industry use feet and not metres? #banimperialunits

Knot is not an official unit in Spain. Why does the ship industry use feet and not metres? #banimperialunits

Together, we can put an end to imperial units.

Footnotes

  1. One may argue that calorie is not a unit of the metric system. In the International System of Units, which is an evolution of the metre-kilogram-second (MKS) system of units, which in turn is a variant of the metric system, both mechanical and thermal energies are measured in Joule. However, in the centimetre-gram-second (CGS) system of units, which is another variant of the metric system, the thermal energy is measured in Calories. Therefore, I would still consider Calorie as one of the units of the metric system, although not of the International System of Units. Besides, I do not think Josh Bazell aimed at being scientifically rigorous, so I would excuse him for not clarifying which variant of the metric system he refers to. ↩
  2. The two other countries that do not adopt the International System of Units are Myanmar and Liberia, while the four other countries that adopt Fahrenheit for everyday applications are Bahamas, Belize, the Cayman Islands, and Palau. ↩

The sad story of the vCard format and its lack of interoperability

15 November 2012

I have tried to reach the zen of address book synchronisation for many years. However, I have always experienced that some contact information, especially instant messaging and social networking addresses, gets lost or corrupted during the synchronisation.

The most adopted format for representing contact information is the vCard, whose last version is the 4.0 (see IETF’s RFC 6350, 2011), while the most adopted protocol for accessing contact information is the CardDAV (see in the IETF’s RFC 6352, 2011), which is based on the vCard format. Therefore, I performed a little empirical study of the actual interoperability of the vCard format.

First, I defined a sample contact:

Joe Bloggs
me@joebloggs.com
+44 20 1234 5678
1 Trafalgar Square, WC2N London, United Kingdom
Web: https://joebloggs.com
Skype: joe.bloggs
Twitter: @joebloggs

Second, I added this contact to four different address books:

  • Apple Contacts (formerly Address Book)
  • Cobook
  • Google Contacts
  • Memotoo

Third, I exported each of the address books to a vCard file.

Fourth, I created a sample vCard file based on the vCard format 4.0.

Finally, I compared the exported vCard files and the sample vCard file among each other. The differences between these files blew my mind.

In the following, I show these vCard files and discuss the properties that are not interoperable. Note that I stripped the irrelevant properties and rearranged the remaining properties to make the comparison easier.

Sample vCard file

BEGIN:VCARD
VERSION:4.0
N:Bloggs;Joe;;;
FN:Joe Bloggs
EMAIL;TYPE=home;PREF=1:me@joebloggs.com
TEL;TYPE="cell,home";PREF=1:tel:+44 20 1234 5678
ADR;TYPE=home;PREF=1:;;1 Trafalgar Square;London;;WC2N;United Kingdom
URL;TYPE=home;PREF=1:https://joebloggs.com
IMPP;TYPE=home;PREF=1:skype:joe.bloggs
X-SOCIALPROFILE;TYPE=home;PREF=1:twitter:https://twitter.com/joebloggs
END:VCARD

In my opinion, the specification of the vCard is substandard. Believe or not, it does not support social networking addresses yet. Even worse, it supports constructs that prevent interoperability, namely grouped properties and non-standard properties.

Grouped properties are properties prefaced with the same group name. They should be grouped together when displayed by an application. I will show examples of grouped properties later.

Non-standard properties are properties defined unilaterally or bilaterally outside the standard. They may be ignored by an application.

For instance, I was forced to represent the Twitter address by a non-standard X-SOCIALPROFILE property:

X-SOCIALPROFILE;TYPE=home;PREF=1:twitter:https://twitter.com/joebloggs

Apple Contacts (version 7.1)

BEGIN:VCARD
VERSION:3.0
N:Bloggs;Joe;;;
FN:Joe Bloggs
EMAIL;type=INTERNET;type=HOME;type=pref:me@joebloggs.com
TEL;type=CELL;type=VOICE;type=pref:+44 20 1234 5678
ADR;type=HOME;type=pref:;;1 Trafalgar Square;London;;WC2N;United Kingdom
item1.URL;type=pref:https://joebloggs.com
item1.X-ABLabel:_$!<HomePage>!$_
IMPP;X-SERVICE-TYPE=Skype;type=HOME;type=pref:skype:joe.bloggs
X-SOCIALPROFILE;type=twitter:https://twitter.com/joebloggs
END:VCARD

The vCard file exported by Apple Contacts is only partially based on the vCard format 3.0 (see IETF’s RFC 2425 and RFC 2426, 1998) and its extension for instant messaging (see IETF’s RFC 4770, 2007).

The web address is represented by a standard URL property grouped together with a non-standard X-ABLabel property:

item1.URL;type=pref:https://joebloggs.com
item1.X-ABLabel:_$!<HomePage>!$_

This issue can be solved by changing the type of the web address from “home page” to “home”. This leads to a vCard file where the web address is represented by a standard URL property:

URL;type=HOME;type=pref:https://joebloggs.com

The Twitter address is represented by a non-standard X-SOCIALPROFILE property:

X-SOCIALPROFILE;type=twitter:https://twitter.com/joebloggs

Cobook (version 1.1.6)

BEGIN:VCARD
VERSION:3.0
N:Bloggs;Joe;;;
FN:Joe Bloggs
item1.EMAIL;type=INTERNET:me@joebloggs.com
item1.X-ABLabel:_$!<Home>!$_
item2.TEL;type=VOICE:+44 20 1234 5678
item2.X-ABLabel:_$!<Mobile>!$_
item3.ADR:;;1 Trafalgar Square;London;;WC2N;United Kingdom
item3.X-ABLabel:_$!<Home>!$_
item4.URL:https://joebloggs.com
item4.X-ABLabel:_$!<Home>!$_
item5.IMPP;X-SERVICE-TYPE=Skype:x-apple:joe.bloggs
item5.X-ABLabel:_$!<Home>!$_
X-SOCIALPROFILE;type=Twitter;x-user=joebloggs:https://twitter.com/joebloggs
END:VCARD

The vCard file exported by Cobook is only partially based on the vCard format 3.0. With the exception of the name, all the contact information is represented by either grouped properties or non-standard properties.

Google Contacts (15 November 2012)

BEGIN:VCARD
VERSION:3.0
N:Bloggs;Joe;;;
FN:Joe Bloggs
EMAIL;TYPE=INTERNET;TYPE=HOME:me@joebloggs.com
TEL;TYPE=CELL:+44 20 1234 5678
ADR;TYPE=HOME:;;1 Trafalgar Square;London;;WC2N;United Kingdom
item1.URL:https\://joebloggs.com
item1.X-ABLabel:_$!<HomePage>!$_
X-SKYPE:joe.bloggs
item2.URL:https\://twitter.com/joebloggs
item2.X-ABLabel:Twitter
END:VCARD

Google Contacts does not support social networking addresses natively, so I was forced to add them as URLs.

The vCard file exported by Google Contacts is only partially based on the vCard format 3.0 (see IETF’s RFC 2425 and RFC 2426, 1998).

The colon in all the URLs is unnecessarily escaped.

Similar to Apple Contacts, the web address is represented by a standard URL property grouped together with a non-standard X-ABLabel property:

item1.URL:https\://joebloggs.com
item1.X-ABLabel:_$!<HomePage>!$_

I guess this is because Google Contacts specifically targets Apple Contacts when exporting to a vCard file. This issue can be solved by changing the type of the web address from “Home Page” to “Home”. This leads to a vCard file where the web address is represented by a standard URL property:

URL;TYPE=HOME:https\://joebloggs.com

The Skype address is represented by a non-standard X-SKYPE property:

X-SKYPE:joe.bloggs

The Twitter address is represented by a standard URL property grouped together with a non-standard X-ABLabel property:

item2.URL:https\://twitter.com/joebloggs
item2.X-ABLabel:Twitter

Memotoo (15 November 2012)

BEGIN:VCARD
VERSION:2.1
N:Bloggs;Joe;;;
FN:Joe Bloggs
EMAIL;INTERNET;HOME:me@joebloggs.com
TEL;HOME;CELL:+44 20 1234 5678
ADR;HOME:;;1 Trafalgar Square;London;;WC2N;United Kingdom
URL;HOME:https://joebloggs.com
X-SKYPE-USERNAME:joe.bloggs
X-TWITTER:https://twitter.com/joebloggs
END:VCARD

The vCard file exported by Memotoo is only partially based on the vCard format 2.1.

The Skype address is represented by a non-standard X-SKYPE-USERNAME property:

X-SKYPE-USERNAME:joe.bloggs

The Twitter address is represented by a non-standard X-TWITTER property:

X-TWITTER:https://twitter.com/joebloggs

Conclusion

Given the results of this study, it is not surprising that the import/export of vCard files as well as the synchronisation via CardDAV do not behave as expected most of the time.

Common contact information such as email addresses, telephone numbers, postal addresses, web addresses, and instant messaging addresses can be represented in two ways: using standard properties, or using standard properties grouped together with non-standard properties. The second way is currently used by Apple (and other vendors targeting Apple); it is unnecessary, prevents interoperability, and promotes vendor lock-in.

Other common contact information such as social networking addresses are not supported at all.

So what should be done? Here is my suggestion:

First, the IETF should remove grouped properties and non-standard properties from the specification, since open standards should promote rather than prevent interoperability. Second, the IETF should add social networking properties to the specification. Third, the IETF should provide an official validator for vCard files. Finally, the vendors should implement the last version of the vCard format, and they should do it right.

Update 22 November

I have shared my concerns in IETF’s vCardDAV mailing list. You can follow the thread here.