This is not a blog
I realized that I had some stories to tell about me and this website. This page contains dated entries, more like a changelog than a blog. Enjoy!
I realized that I had some stories to tell about me and this website. This page contains dated entries, more like a changelog than a blog. Enjoy!
I set up HTTPS on this website more than two years ago (see below). During these years, I have had some problems with StartSSL (revoking a certificate is not free; I also forgot to renew the key I was using to connect to their website, and it expired). This led me to give up HTTPS on this website. When I learned about the Let's Encrypt project, I was very pleased. It is now in public beta, and I have successfully used their service to restore HTTPS on this website. It works well, and it forced me to automate certificate renewal. I now have a cron job that automatically renews the certificate every month.
I am still not convinced by the current system of certificates. It exists for two different purposes: to encrypt HTTP requests between the client and the server, and to guarantee that the website you are visiting is really the one you asked for. The first part can be done with any TLS certificate. The second part requires that an authority validate the certificate. These are two totally different things, and I don't like the fact that these two things are paired. Moreover, I am still waiting for a better solution than a global, centralized authority for the authentication of the certificate.
As I did with GitHub for my new projects, I moved the hosting of this website and some of my projects from my personal router and NAS at home to a virtual server in the cloud. My router was too limited, and it was too complicated to install some dependencies on my NAS. I am now the happy owner of a Google Compute Engine micro instance. It costs less than 10 dollars per month and does a good job for basic hosting.
For a long time, I avoided cloud services. I remember in 2003 when I was using smartphones running Windows Mobile 2003 and wanted to have my e-mails pushed to my phone like what you get with an Exchange server. I set up my own mail server and tried to install Zarafa, a project providing an open-source implementation of the Exchange protocol. After some long nights, it finally worked. Then came Gmail, and I had a hard time giving up my custom mail server for this brand-new service. With the release of Android, that choice completely made sense. I realized that it was very time-consuming to keep my own setup, and it was not possible to compete with a product like Gmail.
However, I kept my SVN server up and running even after the launch of GitHub; my website was hosted on my router at home, and all my photos were on my NAS instead of Picasa.
Today we're in 2013. Cloud services are used by everyone. Revelations about PRISM made everyone think twice about putting their data in the cloud, and I think I'm the only guy who decided to take the opposite direction and to rely more on the cloud than before. Why? For two reasons. The first one is that it costs you a lot of time to keep your own environment up. This is a very interesting task in the beginning, but it does not make sense in the long term. The other reason is that current services are very well-connected and offer a lot of added value. Clone from GitHub, edit on Cloud9, test with CircleCI, push to Heroku: this is outstanding. That is why I decided to rely on these services for my new projects.
For a long time, I was using a TLS certificate I generated myself to provide HTTPS on this website. As my root certificate was not validated by any top-level authority, I used to ask my visitors to import this certificate in their browser as a top-level authority to avoid security warnings. I was conscious that it was a bit ridiculous, but I liked the fact that I was fully autonomous.
The time has changed. I now use StartSSL as a provider for all my TLS certificates. It's a free service that allows me to generate a certificate for each of my servers. Their website is very slow, but it does the job.
For this website, my web server was configured to serve pages using the "application/xhtml+xml" mime type (to be consistent with the doctype of the documents). The consequence was that silly browsers like Internet Explorer asked you to download the page instead of displaying it.
This is no longer true; it's time to move on. I just switched to HTML5. But I am a bit disappointed. I liked to have my HTML files well-formed as XML and to show this to your browser. That is why I used to declare these pages as XHTML1.1 with the "application/xhtml+xml" mime type. Moreover, xHTML allows you to use <![CDATA[
sections. Unfortunately, the W3C has withdrawn the XML syntax for HTML. Anyway, I'll keep my HTML files well-formed, with all their tags nicely closed. For curious people, and for me as a reminder, I replaced this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8" />
by this:
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">