Classifying open source projects status

I have several open source projects on GitHub. Some are active and some are abandoned, for example projects I worked on a few years ago related to technologies I’m no longer interested in.

The question is : how to honestly and quickly express this state to a visiting user ? Badges are the perfect way. Here is the classification I came up with so far :


The ideal case. The module is stable, is usable and has a quality I’m proud of. I’m keeping the source and dependencies up to date. I answer quickly to questions and contributions, my environment is ready.


A common case. I no longer work on this project, but it doesn’t mean that it’s no longer useful. Fell free to use it ! But don’t expect updates or fast answers. You are welcome to fork and take ownership in specialized module repositories. I will point to your fork if it becomes the main branch.


This is a new project I’m working on. You may have heard of it in a meetup or a blog post. You are welcome to have a look, but it is not ready for use in a serious project. API can change anytime. I may rewrite half of it whenever I feel like it. You are warned.

Too often overlooked : extended gcc warnings

This is not widely known, but the gcc compiler does a lot of code checkings. Unfortunately, the resultant warnings are disabled by default.

Only a few project I’ve seen so far use -Wall (a good start) and very few uses -Wextra and -pedantic (a little better). And those warnings are only a fraction of what gcc can do !

When enabled at the start of a project, those extensive warnings allow immediate (= low cost) correction of « smells » before they turn into real problems. It really complement tools like cppcheck or coverity.

Long story short, here are the warnings I use for gcc 4.1.2 (RedHat 5)

For C : -Wall -Wextra -pedantic -Wbad-function-cast -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wnested-xterns -Wconversion -Wfloat-equal -Wformat=2 -Winit-self -Winline -Wmissing-include-dirs -Wredundant-decls -Wshadow -Wstack-protector -Wstrict-null-sentinel -Wswitch-default -Wswitch-enum -Winvalid-pch -Wstrict-aliasing=2 -Wunknown-pragmas -Wundef -Wlarger-than-len -Wunsafe-loop-optimizations -Wpointer-arith -Wcast-qual -Wwrite-strings -Winline -Wvolatile-register-var -Wno-unused-parameter -Wno-variadic-macros

For C++ : -Wall -Wextra -pedantic -Wold-style-cast -Woverloaded-virtual -Wctor-dtor-privacy -Wconversion -Wfloat-equal -Wformat=2 -Winit-self -Winline -Wmissing-include-dirs -Wredundant-decls -Wshadow -Wstack-protector -Wstrict-null-sentinel -Wswitch-default -Wswitch-enum -Winvalid-pch -Wstrict-aliasing=2 -Wunknown-pragmas -Wundef -Wlarger-than-len -Wunsafe-loop-optimizations -Wpointer-arith -Wcast-qual -Wwrite-strings -Winline -Wvolatile-register-var -Wno-unused-parameter -Wno-variadic-macros

So just throw those warnings in your gcc project and enjoy !

googletest reference sheet

I recently started to use googletest at work. So far, I only used UnitTest++.

I was pleasantly surprised. googletest is on par with UnitTest++ for my usage. It works well. I recommend it.

The only missing thing is a convenient reference sheet which would avoid having to constantly browse the documentation.

So I wrote one : (LibreOffice / OpenOffice format)

screenshot of the googletest reference sheet

Enjoy, share and contribute !

CC0
To the extent possible under law, Offirmo has waived all copyright and related or neighboring rights to googletest reference sheet.

How to know which version of a component will be installed by apt-get ?

I was looking for a long time how to know beforehand the version of a component (tool, lib…) about to be installed by apt-get.

Indeed, if we need a recent version of a component whose corresponding apt-get doesn’t provide, best to save space by not installing a useless packet. I also needed it for cvm.

So the command is :

apt-cache showpkg (packet-name)

ou bien

apt-cache policy (packet-name)

See also stack overflow answer.

Reboot

New blog.

  • Hébergeur : HostPapa
  • Nom de domaine : via l’hébergeur
  • Un bon vieux WordPress
  • Un bon vieux mediawiki

Quelques mots sur le choix de l’hébergeur : OVH est très bien, mais j’ai voulu tester la concurrence. HostPapa est un peu plus cher, avec en théorie un hébergement « vert » et espace de stockage et bases de données illimités (et autres choses peu remarquables).

En pratique tout fonctionne, j’ai retrouvé toutes les fonctionnalités d’OVH.

J’ai particulièrement apprécié l’installateur Softaculous, qui permet en quelques clics d’installer des milliers d’outils comme wordpress, mediawiki… Les versions proposées sont bien à jour, l’installation est simplifiée, les bases de données créées automatiquement, les identifiants sont envoyés dans un mail récapitulatif.

De plus, on est prévenu en cas de mise à jour disponible et on peut faire des sauvegardes complètes (fichiers + base) de chaque outil en quelques clics.

En un mot : je suis conquis par cet outil, et bravo à HostPapa de le fournir ! Le temps, c’est de l’argent : à mon humble avis, rien que cet outil vaut le surcout. OVH, à quand l’intégration de Softaculous ?

[edit] À l’usage, HostPapa est très lent en hébergement mutualisé, et subit des interruptions de service intempestives (vu 2 fois en utilisation : plus de wiki, plus de blog…) donc à voir…