Footcow BlogFootcow Blog

Chaque release majeure de PostgreSQL (passage de la version 9.6 à la 10 par exemple) nécessite d'effectuer un dump et un restore de la base de données. Le travail n'est pas si fastidieux, mais nécessite quelques manipulations. Debian propose une migration plus simplifiée, destinées, à mon avis, aux bases de données de petites tailles, pour une migration rapide. Si vous travaillez sur des bases de plusieurs Go, cela fonctionnera, bien sur, mais l'interruption de service pourra être longue. Il existe d'autres moyens pour faire ce genre de chose avec des serveurs de réplication par exemple. Je vais donc vous décrire le process simple à mettre en place.

Leap représente une façon entièrement nouvelle d'interagir avec votre ordinateur. C'est plus précis qu'une souris, aussi fiable qu'un clavier et plus sensible qu'un écran tactile. Pour la première fois, vous pouvez contrôler un ordinateur en trois dimensions avec votre main et les mouvements des doigts.

Ce système n'est pas comparable au Kinect, qui ne fait que reconnaître les mouvements de la main. La technologie Leap est 200 fois plus précise que n'importe quoi d'autre sur le marché, et ceci quelqu'en soit le prix. De la taille d'un disque dur externe, le Leap peut distinguer chacun de vos doigts et le suivi de vos mouvements jusqu'au 1/100e de millimètre.

C'est comme le premier jour de la souris. Sauf que, personne n'a besoin d'un manuel d'instruction pour ses mains.

Force est de constater que Dotclear est à mon avis un des meilleurs moteur de blog à l'heure actuel. De par sa conception interne, et la souplesse de son interface, mais aussi grâce au support de PostgreSQL, ce qui hélas, se fait encore rare dans les moteurs de blog open source.
Mais Dotclear ne remporte pas la compétition ouverte contre Wordpress au niveau de l’engouement du grand public. Pourquoi ? Simplement parce que sa communauté est restée très franco-française. Sa documentation est toujours incomplète en anglais, et naturellement les plugins, pourtant souvent bien conçus, sont véritablement trop peu nombreux.
Voilà pourquoi dans le cadre de certains développements de ma société ou d'amis dans le besoin, je me suis dit qu'il serait bien de mettre de temps en temps la main à la patte pour faire avancer ce très bon produit. En l'occurrence, j'avais besoin de faire un connecteur assez spécifique pour permettre aux visiteurs d'un blog de s'inscrire à une newsletter envoyée depuis le très bon outil de routage d'email : MailChimp.

Quel client ne vous a pas demandé un jour de lui présenter des statistiques mensuelles de ses données ? Souvent il fallait faire les calculs, obtenir des agrégations et coder une interface de présentation qui prenait des résultats en colonne pour les remettre en ligne. Laborieux, souvent source d'erreur et de perte de temps cette méthode n'avait pas tellement d'équivalent directement en base de données. La solution est apparue depuis quelques release de PostgreSQL, il suffit de savoir manipuler l'extension Crosstab.

Si vous êtes un professionnel de l'email marketing vous ne savez que trop quelles sont les réalités de la mise en Spam de vos emails par les destinataires. Peu importe la pertinence du contenu de vos emails, ou de votre politique stricte d'optin, à un certain moment un ou plusieurs destinataires frappera le bouton "Ceci est un Spam" et par conséquent déposera une sorte de plainte contre vous. Chez les principaux webmail du moment il est très facile pour les destinataires de cliquer sur ce bouton, la plupart le comprennent comme un bouton de désabonnement. Ils peuvent l'utiliser quand ils ne font pas confiance à l'expéditeur, ou ils peuvent l'utiliser car il est plus facile à trouver que votre lien de désabonnement dans votre email.

Ces plaintes sont, hélas très négatives pour votre réputation. Si vous en obtenez un volume conséquent elles peuvent influer négativement votre déliverabilité. Vous empêchant d'arriver dans la boite de réception, voir de même dans le dossier de courrier indésirable de vos destinataires.

C'est donc ici que les boucles de rétroaction entrent en jeu.

Une base d'emailing n'a jamais été une valeur sûre. Vous avez peut-être des milliers d'adresses email mais ce n'est pas pour autant que vos destinataires ouvrent, ou cliquent dans vos messages, et ceci depuis plusieurs mois, voir des années. Cela va sans dire, vous prenez donc un certain nombre de risques à continuer à leur écrire. Envoyer des emails sur des comptes qui n'existent plus engendre forcément des risques sur la qualité de votre déliverabilité. Vous jouez même avec le feu, car de nombreux FAI se servent de ces adresses comme des adresses pièges et ainsi marquent les expéditeurs comme des spammeurs.

Bref, si vous êtes heureux d'avoir un volume conséquent d'adresses email ce n'est pas pour autant que vous êtes efficace. Vous jetez même un peu d'argent pas les fenêtres en coûts de routage inutile. Pensez bien qu'un utilisateur qui n'a ni ouvert, ni cliqué dans une de vos campagnes depuis plusieurs mois et pire encore depuis plusieurs années, ne va pas se mettre tout à coup à s'activer. Conclusion de quoi vous pouvez déjà prendre une mesure immédiate : supprimez ces adresses non recevable. Naturellement cela ne se fait pas d'une façon aussi radicale, et nous allons voir comment procéder.

Suite à un vieux billet concernant l'espace disque de vos bases de données PostgreSQL, il m'a souvent été demandé comment trouver la taille engloutie par les différents schémas qui composent votre base de données.

Akonadi, le service de stockage des données de toute la partie gestionnaire d’informations personnelles (PIM) de KDE 4, est livré en standard avec une configuration faite pour MySQL. Comme vous pouvez vous en douter, les lenteurs, ajouté au côté capricieux des mises à jour de MySQL et ma passion pour PostgreSQL m'ont rapidement fait migrer vers ce dernier choix. Depuis, je n'ai plus jamais entendu parlé d'Akonadi et tout fonctionne parfaitement bien. Voilà donc un petit mémo pour migrer votre configuration vers PostgreSQL en quelques minutes.

Qui n'a pas été confronté un jour à des blocages temporaires de déliverabilité, avec le sympathique message de bounce vous indiquant que vous avez trop d'adresses email invalides ?
Même si vous vous appliquez à entretenir une hygiène de base des plus rigoureuse, vous serez confrontés à cette situation. Et hélas, cela arrive de plus en plus souvent. Trop de risques pris dans l'acquisition de base de données pour obtenir plus rapidement des membres engendre ce genre de péripéties. Je ne saurais que trop insister sur ce sujet, mais la qualité l'emporte sur la quantité, encore plus sur le long terme. Il est impératif pour la pérennité de votre activité de bien prendre en compte cet aspect du recrutement, sinon un arbitrage naturel sera effectué par les fournisseurs d'accès, ou les webmails, qui réduiront votre déliverabilité plus vite que vous ne l'imaginez. Vous ne serez alors même plus capable de joindre vos abonnés légitimes, et pas seulement ceux que vous avez recrutés rapidement. Dans la plupart des cas, un blocage temporaire du à des adresses email invalides n'est pas aussi grave qu'un blocage permanent, car il dure généralement 24 à 72 heures et ne vous oblige pas à contacter le FAI pour demander que le blocage soit levé. Toutefois, vous ne serez pas en mesure d'écrire à vos adresses valides ou d'identifier les adresses non valides pour nettoyer votre liste jusqu'à ce que le blocage soit levé. Et, vous pourriez faire face à des restrictions plus importantes, voir à un blocage total chez ce FAI, si vous ne résolvez pas vos problèmes d'adresses invalides immédiatement.