Réfection de mon NAS

Plus que d’un vrai NAS, j’ai besoin d’une machine capable de stocker et sauvegarder mes données – Photographies, textes, documents, etc — de manière fiable.

Historique

Historiquement, j’ai commencé — il y a fort longtemps — par des sauvegardes sur disquettes, puis sur CD réinscriptibles ou non, enfin sur un disque dur et enfin des clefs USB. C’est assez peu pratique, mais ça faisait le travail. Des distributions Linux orientées NAS me faisaient de l’œil, mais ce n’était jamais le moment de sauter le pas.

Yunohost

J’ai tout de même fini par monter ce que j’appellerai mon premier NAS . Un PC de récupération, dual core de l’époque doté de quatre Go de Mémoire et d’un disque système de 250 Go augmenté d’un disque de 1To pour les données. Je voulais tester Yunohost, une distribution Linux permettant d’installer et utiliser des applications orientées « cloud personnel », principalement Gitlab (gestion de code source) et Nextcloud (agenda, notes, photos).

Yunohost fonctionne assez bien, avec des applications bien packagées et installables facilement. Avec une solution de sauvegarde à façon, le système était assez fiable.

Le gros défaut de Yunohost — pour mes usages — est d’être prévu pour être accessible depuis Internet, ce que je ne souhaite pas. J’ai également connu une grosse déception : suite à la dernière mise à jour, il m’a été impossible de faire fonctionner Gitea. J’ai eu beau désinstaller et réinstaller cette application, je suis resté le bec dans l’eau.

Puis il s’est produit …

Un accident

Cela arrive, le disque dur contenant mes données est tombé en panne, comme un préquel à la mort du disque de mon PC de bureau.

Une restauration des données sur le disque système – suffisant mais un peu étriqué – m’aurait laissé à la merci d’un éventuel nouveau problème de disque.

Nouvelle machine et réinstallation à blanc

J’ai acquis pour le prix très avantageux de zéro euros un PC au format slim destiné au recyclage. Mémoire augmenté après coup à huit Go, processeur quad core, format compact, ventilation très silencieuse, bref, une machine idéale pour un NAS tout en assurant l’avenir. Exit le disque de la bestiole, remplacé par un SSD pour le système, et deux disques à plateaux de 500Go pour les données. La carte mère ne disposant que de trois ports Sata, j’ai dû débrancher le lecteur-graveur de DVD.

Pour le système d’exploitation, j’ai choisi comme à mon habitude une distribution Debian de base augmentée de quelques utilitaires usuels comme htop, ksh, etc

Choix technique

Je voulais expérimenter de nouvelles applications, mais sans avoir à gérer des dépendances potentiellement conflictuelles sur MariaDb, Php, etc.

La solution s’appelle Docker, avec un conteneur pour chaque application. Sur une seule machine, pas besoin de Swarm ou de Kubernetes,

Les données sont stockées sur l’un ou l’autre des deux disques de données. Docker stocke les images de ses conteneurs là où il veut bien sur le disque système..

Portainer me permet au besoin d’arrêter ou relancer les conteneurs, et au pire, la ligne de commande devrait permettre de gérer les cas limites.

Fiabilité

Les deux disques de données sont une solution temporaire, le temps d’acquérir deux disques de un ou deux To et de les monter en miroir.

Tel quel, le système est stable et fiable. Passons aux applications.

Synchronisation de répertoires : Syncthing

Je m’en sers principalement pour copier rapidement certaines données de mon smartphone à l’aide de l’application éponyme.

Gestion de versions : Gitea

Un test de Gitlab ne m’a pas convaincu. Son utilisation est connue, simple à appréhender, presque intuitive, mais Gitlab est assez lent sur mon NAS. Trop lent, surtout comparé à Gitea qui fonctionnait comme un charme sur un simple dual core avec quatre GO de RAM. Exit donc Gitlab, rebonjour Gitea.

Gitea propose moins de fonctionnalités que Gitlab, mais il me suffit amplement… et il fonctionne sur ma « nouvelle » machine, alors que j’étais bloqué sur mon installation Yunohost.

NextCloud

Nextcloud permet à l’instar de Yunohost d’installer des applications : suite bureautique, prise de notes, agenda, calendrier, mails, photos, liste de tâches, kanban, messagerie instantanée, etc.

La sauvegarde de mon smartphone et le synchronisation de mon PC de bureau et de mon Netbook s’opèrent via une application Android et une application Linux

Sauvegardes

Les sauvegardes, c’est la vie. Cf. une nouvelle fois mon expérience récente. Docker ne propose pas en soi de solution de sauvegarde des containers qui me convienne. Les volumes Docker sont dirigés vers des répertoires physiques sur mes disques de données ; l’archivage de ces répertoires devrait suffire.

J’effectue des sauvegardes périodiques via des procédures manuelles. Ce n’est pas optimal, mais en attendant mieux…

Nextcloud est un peu particulier pour les sauvegardes. S’il propose une application de sauvegarde globale et automatisée, il ne permet pas d’effectuer une sauvegarde application par application. Cela viendra peut-être.

Bilan provisioire

J’utilise cette installation depuis plusieurs semaines/mois — Comme le temps file !

Nextcloud fonctionne très bien, comme on pouvait s’y attendre. Seule l’application « Photos » est parfois un peu lente lors du premier affichage d’une photographie, mais rien de rédhibitoire.

Point très important pour moi, j’ai retrouvé un serveur Git utilisable tant pour mes codes sources que pour mes écrits.

Côté utilisation mémoire, le démarrage de Nextcloud se fait sentir après le démarrage du NAS, mais ensuite, en dehors des synchronisations, l’occupation mémoire plafonne à moins de deux Go. Du coup, j’ai installé un conteneur JupyterLab, histoire de m’amuser un peu.

Petite sélection d’applications pour Android

Bien digéré ? La GDB est passée ? Pas encore ?

Par chez-moi ça va, pas de mal aux cheveux, malgré une fondue un peu … Mouip, bon, c’est du fromage fondu après-tout, lourd et une poil gras, mais on survit.

Il me restait un petit article à écrire à propos de la libération partielle de mon smartphone. Quel intérêt y aurait-il à « libérer » sont téléphone si c’est pour y installer des applis qui ne le sont pas.;.

Mon « setup » est stabilisé depuis quelques semaines, avec deux profils. Le profil « sandboxed » permet d’accéder aux services Android sans polluer le profil principal. Il me sert pour l’application Maps, le jours de grande fainéantise, et pour mon appli bancaire. Le profil principal me sert pour mon utilisation courante.

Voici ma sélection d’applications. Elle est susceptible d’évoluer encore. Signal, par exemple, risque de passer à l’As, dès que je lui aurai trouvé un remplaçant.

Utilisation quotidienne, ou presque

• Syncthing : Synchronisation avec mon NAS
• VLC : Le lecteur multimédia que j’utilise déjà sur PC
• Geometric Weather : Application météo
• Fitotrack : Suivi de mes sorties vélo
• Free42 : Une émulation de calculatrice HP .. Le RPN, c’est la vie 😉
• Signal : Mon appli SMS, ainsi que conversations et téléphonie via le net
• FlorisBoard : Clavier virtuel
• Nextcloud : Accès aux applications de mon NAS
• Fedilab : Mon point d’accès au Fediverse, en particulier Mastodon
• NewPipe : Client Youtube libre

Utilisation occasionnelle

• OsmAnd : En remplacement de Google maps. L’appli n’est pas encore parfaite, mais elle s’améliore avec le temps.
• Tor Browser : Navigateur web via le réseau TOR.
• Buran : Client Gemini, que je commence à découvrir
• Notepad : Editeur de notes au format texte
• Imagepipe : Editeur photos, en cours de découverte
• Mobilizon : En cours de découverte également, cette appli permet de se tenir au courant d’événements dans une ville, une région, un pays…
• Freeteuse : Télécommande pour les très rares fois où je regarde la télévision

App stores

J’ai installé ces application via F-Droid lorsque c’était possible, ou à défaut via Aurora Store, après avoir vérifié les autorisations demandées et l’absence de pisteurs sur le site Exodus Privacy.

Comparatif : Zim v/s One Note

Je ne suis pas fan des produits made « in Redmond », comme on disait autrefois. Chez-moi, c’est de l’Unix et rien d’autre. Au travail cependant, c’est Windows qui mène la danse, et je n’ai pas le choix.

Pour mes prises de notes, j’ai conservé une copie de Zim , mais tôt ou tard, je risque de devoir m’en passer, et donc de migrer vers One Note. Pour ne pas rester scotché le jour où ça arrivera, j’ai décidé de tester le produit, et de l’utiliser au jour le jour en lieu et place de Zim.

Premier écueil, l’organisation des notes. Ça n’a presque rien à voir, et je ne parle même pas des raccourcis clavier et des menus.

Zim Desktop

Zim est pour ce que j’en sais un logiciel libre et open source. C’est à la fois un outliner, un wiki, un gestionnaire de tâches, un générateur de site web, et j’en oublie certainement.

Les notes sont saisies et affichées dans des pages contenant du texte et des graphiques. Une page peut contenir des sous pages sur plusieurs niveaux, et l’arborescence est affichée dans un panneau sur la gauche de la fenêtre.

Les possibilités de formatage du texte sont assez limitées, mais largement suffisantes pour un usage au quotidien.

De multiples plugins et outils externes étendent les possibilités de base de l’outil. Par exemple, un plugin permet d’intégrer des diagrammes via l’outil Graphviz, d’autres donnent accès à l’outil de gestion de versions (versionning) installé sur la machine.

Gros important pour les nanoteurs : un compteur de mots est intégré dans le menu « Outils ».

Pour les paranos dans mon genre, le plugin de versionning est un gros plus, de même que le format utilisé pour stocker les notes. Même si Zim le cache bien sous son interface à la WYSIWYG, tout à part les graphiques est stocké dans des fichiers texte au format markdown. Si un fichier est corrompu, seule la page ou le graphisme concerné sera perdu.

Les points forts : logiciel libre, format de données ouvert, souplesse, présence de plugins et simplicité.

Les points faibles : interface un peu vieillotte, quelques rares plantages, heureusement sans perte de données.

One note

One note est un logiciel propriétaire. Son interface, à quelques gros détails près, est plutôt agréable à utiliser. C’est un gestionnaire de notes pur jus, avec une organisation assez rigide en blocs-notes, sections et pages. Il existe également la possibilité de créer des sous-pages, mais j’en trouve la mise en œuvre peu pratique.

Les possibilités de formatage du texte sont beaucoup plus étendues que celles de Zim, trop même, mais chacun peut y trouver son compte, à condition de s’y retrouver dans les différents bandeaux d’outils. C’est du WYSIWYG à la mode Microsoftienne. Perso, je trouve que ça fait un peu bloatware : trop de fonctionnalités dont la plupart ne me sont pas utiles.

Je n’ai pas trouvé de système de plugins, mais One Note s’interface très bien avec Outlook, par exemple pour y créer des tâches, et pour envoyer des notes par mail. Je n’ai pas exploré ces aspects de l’outil. Plus tard, peut-être.

Le format des données est à priori propriétaire, mais je peux me tromper. Le gros hic pour moi est que si le fichier d’un bloc-notes est corrompu ou perdu, c’est le bloc-notes entier qu’il faudra restaurer. Dans ces conditions, et parce qu’un outil de versionning est à mon sens mal adapté à des fichiers de type binaire, il vaut mieux prendre les devants et effectuer des sauvegardes fréquentes de ses fichiers.

Les points forts : bonne intégration aux produits Microsoft, interface soignée à quelques détails près.

Les points faibles : logiciel propriétaire, format propriétaire, le système de post-its dans les pages, le système de bandeaux d’outils, les outils de formatage trop nombreux.

Pour conclure

J’ai commencé à utiliser One Note en prévision du jour où Zim deviendrait persona non grata au travail, et je me fais peu à peu à ses différences avec Zim. Ca ne me plaît pas de l’avouer, mais c’est un bon outil.

Pour autant, est-ce que je vais continuer à l’utiliser ? Au travail, oui, mais ça en restera là. Pour le reste, je vais continuer à utiliser Zim, qui colle plus au genre d’outils que j’affectionne : simple à aborder, multi plateformes, extensible, open source.

Mon utilisation de Zim pour le NaNoWriMo

Comme dit dans mon billet Zim Desktop, entre éditeur de texte et outliner, j’utilise maintenant Zim pour écrire mes textes. Le Camp Nanowrimo en cours confirme que c’est un bon outil d’écriture. Bien sûr, il n’est pas à cent pour cent orienté écriture comme par exemple scrivener mais avec un peu de méthode, il permet de créer un premier jet sans trop se casser la tête. En effet, tout est accessible depuis l’arborescence des pages.

Je n’utilise que deux niveaux de pages :

• Les dossiers. Ils regroupent les documents par thèmes
• Les documents. Ce sont mes chapitres, fiches persos, etc

Le dossier « persos »

Chaque document de ce dossier contient une « fiche perso ». Pour chaque personnage je note, outre l’identité, l’âge et une description générale, tout ce qui le définit dans le cadre du texte en cours d’écriture. Son passé, ses manies, ses craintes, et une description succinte de son rôle dans les arcs du roman.

Le dossier « ships »

Tous mes nanos, sauf le premier, sont de la science fiction. Sci-Fi ou SF pour les intimes. Le déplacements à longue distance se font par ce que d’autres appellent « vaisseaux spatiaux », mais que j’appelle des navires. C’est moins science-fictionnesque, mais ça reflète mieux ma vision « industrielle », où la marine a un rôle central et structurel dans l’expansion humaine.

Chaque navire a sa propre fiche, presque comme un personnage, où je note tout ce qui est utile – ou pas – dans le récit. Nom propre, immatriculation, taille, génération, etc.

Le dossier « Systèmes »

Mes récits prennent place dans le cadre d’un essaimage humain vers d’autres systèmes. Le problème de la propulsion est apparu assez tôt, mais une fois résolu d’une manière ou d’une autre, l’expansion a bel et bien eu lieu, de proche en proche. Les dates d’abordage, d’installation, les noms, les climats, reliefs, gravité, etc sont ajoutés au fur et à mesure des besoins.

Le dossier « Villes »

Il s’agit de la description des installations humaines prenant part aux différents arcs du récit. Je leur ai choisi des noms de cités plus ou moins réalistes : Thulée, Lutèce, Lapyuta, Europe, Brest, suivant leur emplacement ou leur utilité principale.

Le dossier « Plots »

Chacun des arcs, ou « plots » y est détaillé. Les personnages qui y participent, où, comment , dans quel but.

En exception au principe de séparation « Dossiers/Documents » ce dossier porte également mes remarques, questions, idées à propos des différents plots, les « A faire plus tard », les « nota bene », les recherches à effectuer.

Le dossier « texte »

Chaque document de ce dossier contient une unité d’écriture. Ça peut être un chapitre, le texte d’une journée lors d’un nanowrimo, des notes.

Pour rappel, le nommage des documents est important, vu que Zim les liste par ordre alphabétique. Mes documents portent donc le numéro du jour où le texte a été écrit.

D’autres dossiers ?

Tous ces dossiers ont été créés en fonction des besoins. Leurs noms et leurs contenus risquent fort d’évoluer. D’autres pourraient apparaître. Par exemple, la réécriture de « L’Arracheuse d’Âmes » et de « Blocus » ne pourra pas vraiment coller à ces dossiers car le cadre « géographique » est beaucoup plus restreint, avec l’essentiel de l’action se passant sur « l’Îlot » première installation humaine hors de la biosphère terrestre, et sur la région lilloise.

Pour conclure …

L’important n’est pas tant le découpage en dossiers que de regrouper les informations nécessaires sur le déroulement des arcs du récit.

A l’extrême, « Qui », « Quoi », et « Où », et « Texte » sont peut-être les seuls dossiers vraiment nécessaires.

… gros foutoir en vue !

Le texte est découpé par journées d’écriture, mais en fin de correction, il « vaut mieux » avoir des chapitres, et là, ça se complique. En passant de l’un – les journées d’écriture – à l’autre – les chapitres – des passages sont supprimés, déplacés, étendus, éclatés.

Gros foutoir en vue !

Zim Desktop, entre éditeur de texte et outliner

Depuis ma première participation au NaNoWriMo, j’ai écrit mes textes avec gedit, ou pluma, qui est le même produit avec un autre nom, allez comprendre. Bref, gedit a tout pour plaire :

• simple, sans fioriture
• extensible et utilisable pour programmer (mise en évidence de la syntaxe)
• possède un compteur de mots, de paragraphes, de caractères
• multi-documents, avec l’usage d’onglets
• léger en mémoire
• très réactif
• son mode « sans distraction » permet de se concentrer sur le texte, sans risquer d’être dérangé par une autre application.

Bref, c’est presque la panacée.

Presque ? L’usage de multiples documents – plusieurs dizaines dans mon cas – simultanément me posait problème :

• plusieurs documents à ouvrir
• navigation facile mais pas optimale entre les différents onglet

C’est tout ce que j’ai à lui reprocher, mais c’est assez pour que j’aie eu envie de tester autre-chose. Comme j’utilise Zim depuis une bonne année pour gérer mes notes, et au vu de ses possibilités, le choix a été très vite fait :

• outliner : les pages peuvent être organisées en arborescence, très pratique pour organiser ses notes
• wiki : des liens peuvent être établis entre les pages.
• interface avec mercurial pour gérer les versions des pages
• Un compteur de mots

Le choix a donc été très vite fait.

Présentation générale

La fenêtre d’un « document » Zim, ou bloc-notes ressemble à ceci :

Outre les barres de menu, d’outils et de statut, la fenêtre principale est séparée en deux parties redimentionables :

• l’arborescence des pages à gauche,
• la page courante à droite

La page en cours d’affichage est surmontée de « breadcrumps » listant les dernières pages accédées. Cliquer sur l’un d’eux affiche la page correspondante.

Utilisation

Un « document » Zim s’appelle un bloc-notes, et l’on peut en créer plusieurs. Par exemple, j’en ai créé un pour mon blog, et un autre pour le NaNoWriMo 2016, et j’en créerai un autre encore pour corriger « L’arracheuse d’Âmes »,
Un bloc-notes contient un ensemble de pages et de sous-pages que l’on peut organiser comme on le souhaite. Pour un roman, on pourra créer une page par chapitre, et une sous-page par scène. Pour NaNovembre 2016, j’ai simplement commencé par créer une page par jour.
Attention lors du nommage des pages, car Zim les trie par ordre alphabétique. Si on veut forcer un ordre particulier, on pourra préfixer les noms des pages, par exemple avec un numéro.
Une fois une page sélectionnée dans l’index, ou créée, on peut y taper son texte au kilomètre. Les mises en forme de base (titres, gras italique, souligné, etc) sont disponibles, et on peut insérer des images, des liens vers d’autres pages, des urls, …
C’est l’usage de base, entre traitement de texte et outliner.

Un petit détail qui compte : il y a également une version Windows (mes PC persos tournent sous Linux) identique à la version Linux, ainsi qu’une version pour Mac OS, mais ne ne l’ai jamais utilisée (no apple at home).

Sous le capot

Un bloc note est un répertoire où les pages sont stockées sous forme de fichiers texte, et les pièces jointes sont stockées dans des sous répertoires. Il est donc facile de stocker les versions successives d’un bloc-notes dans un gestionnaire de versions, comme mercurial. Ca peut paraître un peu geek, mais c’est très pratique à l’usage, surtout avec le plugin « Gestion de versions ».

Les plugins, justement, couvrent une bonne partie des besoins périphériques à la création de texte : journal, liste de tâches, carte des liens, diagramme, mode sans distraction, etc.
Un peu à part, les « Outils personnalisés » permettent de lancer un programme ou un outil externe sur le texte d’une page.
Pour les plus courageux, Zim est écrit en Python, ainsi que ses plugins.

Conclusion provisoire

Zim allie à mon sens le meilleur d’un traitement de texte basique, d’un outliner et d’un wiki, et ses fonctions de base peuvent être étendues, avec un peu de travail.

Comme déjà dit, je l’ai utilisé pour mon NaNoWriMo 2016, et une fois les commandes de base assimilées, l’écriture est aussi fluide qu’avec gedit, avec des fonctions plus étendues disponibles de la préparation jusqu’à la correction du texte.

Odin, Heimdal, Heimdal, Odin … ?

Suite à mon problème de Samsung Note saturé, j’ai du me rendre à l’évidence : il va bien falloir étendre cette partition « système ».

Premier point : quelle taille choisir ? Ajouter un ou deux giga-bytes serait risquer de se retrouver dans la même situation à l’issue d’un nouveau changement de format de binaires imposé. Soyons extrême pour une fois, et faisons moitié-moitié. Huit Gigots pour le système, huit gigots pour les données. Mes photos, vidéos, textes et autres seront stockés sur ma carte SD.

Second point : les outils. Le logiciel Odin est très réputé pour installer des versions alternatives d’Android et repartitionner l’espace de stockage du téléphone, mais il a le tort de n’exister que sous Windows. Or, Windows, chez-moi, connais pas. Le système au pinguoin me suffit et j’ai horreur des courants d’air. J’ai donc voulu tenter l’aternative sous Linux, à savoir Heimdall.

Sur ce coup là, j’ai été un peu fainéant : les firmware android utilisables sous Odin tombent directement dans la main. Pour Heimdall, et bien j’ai lâché l’affaire après quelques heures. Exit Heimdall. « Bonjour Odin, tout va ? Tu as fait bon voyage ? Bon, bosse maintenant ! » Réponse d’Odin au pingouin aviné « Mais heu, c’est pas Windows, ce truc ! » Odin n’aime pas Wine. J’aurais dû me douter.

Comme je n’ai pas trop le choix ni le temps, j’ai fini par installer Odin sur un PC d’emprunt sous Windows, et j’ai suivi le mode d’emploi, à savoir :

1. Comprendre et accepter que l’opération entière pourrait transformer le téléphone en un très beau presse papier, et que ni les auteurs des logiciels ou documents, et encore moins l’auteur de cette page ne peuvent être tenus responsables en cas de problème.
2. Sauvegarder les données du téléphone : photos,mails, vidéos, etc
3. Repartitionner et installer le Stock ROM Jelly Bean pour Samsung, comme indiqué par exemple ici.
4. Attendre que ça se passe
5. Installer un custom recovery, comme indiqué par exemple ici.
6. Installer Cyanogenmod. Les « howto » ne manquent pas, bonne lecture (et une bonne dose d’anglais, désolé). J’ai choisi la méthode la plus simple, à savoir copier l’archive sur la carte SD du téléphone et l’installer depuis le recovery
7. Je n’ai pas eu à le faire, mais il faudra peut-être installer les applications google, ou gapps. Les howto indiquent lamarche à suivre en même temps que le reste.

Après plusieurs essais (heureusement, Odin permet de repartir de zéro), tout s’est finalement bien passé, sauf le point 6. Archive foireuse donc installation refusée.

Ça n’a pas l’air très glorieux, mais je me suis retrouvé avec un Jelly Bean by Samsung avec un custom recovery et un espace système assez grand pour y installer tout l’Android Market (ou quelque soit le nom qu’il porte à ce jour) ou presque. J’ai décidé de le laisser quelques jours dans cet état, le temps de redécouvrir Jelly Bean avec la surcouche constructeur …

… comprendre :  » Il est tard, j’ai les yeux qui se croisent, mon téléphone fonctionne, et je-veux-mon-lit !  »

Gérer un blog avec tiddlywiki

Lorsque j’ai commencé à bloguer, écrire des billets sur internet, je ne pensais pas que ça aurait duré aussi longtemps. Aujourd’hui j’y suis encore, avec comme il se doit des hauts et des bas.

Après un temps il m’a fallu historiser cette activité, en compiler des références pour de futurs billets, et pour les replacer dans leur contexte. Un autre besoin, une nécessité est de classer repérer les billets parus, les brouillons, les publiables, les planifiés.

Si au départ un simple fichier texte suffisait, il m’a bien fallu un jour passer à la vitesse supérieure. Un wiki classique eût bien fait l’affaire, mais l’idée de me trimbaler (j’ai tendance à écrire un peu partout) avec une base de données, un serveur web, une application php et tout le bazar ne m’enchante pas le moins du monde.

Revenons donc aux basiques:

• un wiki,
• une mise en oeuvre simple,
• une utilisabilité de tous les instants…
• … vous voyez maintenant où je veux en venir…

J’utilise un document tiddlywiki, simplement enrichi de la macro siteMap.

Pour rappel, la macro siteMap permet d’afficher une carte du wiki sous la forme d’une arborescence de tiddlers, la hiérarchie étant définie par les tags.

Le premier tiddler visible à l’ouverture de ce tiddlywiki contient plusieurs appels à cette macro sitemap.

Pour les gens pressées, ça se trouve à la fin de ce billet.

Pour les autres, voici d’abord quelques explications, en tentant de rester compréhensible.

Les billets avant parution

Avant parution chaque billet passe par trois tags successifs:

1. Brouillon (draft)
2. A relire
3. A paraitre

J’ai donc un tiddler contenant le code suivant, qui me permet de voir ce qui reste en stock (prêt à publier) ou en cours de rédaction :

<<siteMap 10_draft>>
<<siteMap 20_aRelire>>
<<siteMap 30_aParaitre>>

Publication d’un billet

Quand je publie un billet, je renomme son tiddler en lui ajoutant la date (format aaaammjj) et remplace ce tag d’état par

• un tag pour chaque catégorie du billet
• et un tag Maaaamm (aaaa = année, mm = mois) indiquant le mois de parution

Si le document tiddlywiki prenait de l’embonpoint, il serait (presque) envisageable de supprimer le texte des plus anciens (une hérésie à mon sens) en n’en conservant que les titres.

Historisation des billets
Chaque billet porte un tag de la forme Maaaamm correspondant au mois de sa parution.

Pour chacun de ces tags, je crée un tiddler ayant un tag Yaaaa correspondant à l’année.

De même pour chaque Yaaaa, je crée un tiddler portant le tag « timeline », et ce tag est utilisé par un appel à la macro siteMap :

<<siteMap timeline>>

L’historique du blog apparait maintenant trié par années et par mois.

Classement par catégories

Pour chaque catégorie du blog je crée un tiddler dont le nom commence par un caractère « _ » et ayant pour tag la catégorie mère, ou le tag « categories » si c’est une catégorie de base.

L’ajout d’un nouvel appel à la macro siteMap donne le classement des billets par catégories:

<<siteMap categories>>

Au final

L’état du blog apparaît dans un tiddler affiché par défaut et contenant le texte suivant :

|<<siteMap 10_draft>> <<siteMap 20_aRelire>>|<<siteMap 30_aParaitre>>|
|<<siteMap categories>>|<<siteMap timeline>>|

Utilisation des rappels dans Tiddlywiki/mGSD

J’utilise Tiddlywiki et un de ses dérivés, mGsd au quotidien pour suivre l’avancement de mes chantiers en cours.

Le suivi par listes de tâches et par contextes ne suffit pas toujours, car certains événements arrivent à date planifiée, par exemple les mises en production, opérations de services, etc.

Par ailleurs certaines actions sont récurrentes, avec répétition quotidienne, hebdomadaire, mensuelle, etc.

mGsd fournit un outil fort pratique: les rappels, ou ticklers. Je ne me suis décidé à m’y intéresser que récemment. Pourtant leur utilisation est des plus simple:

Création d’un rappel

1. Cliquer sur le lien « + tickler » en haut du mGsd, ou dans le projet concerné
2. Sélectionner une date
3. Dans le dialogue qui apparait, saisir le libellé du rappel et valider
4. Le nouveau rappel apparaît

Description d’un rappel

Chaque rappel possède les attributs suivants :

• Période :
  • one time – une fois
  • daily – quotidien
  • weekly – hebdomadaire
  • fortnightly – tous les quinze jours (j’adore les dialectes anglais et étasuniens!)
  • monthly – mensuel
  • yearly – annuel
• Date du rappel
  • Cliquer sur la date pour la modifier dans le calendrier qui apparaît alors.
  • Cette date peut être modifiée par des raccourcis y ajoutant un jour (+d), une semaine (+w), un mois (+m) ou un an (+y)
• Projet
• Domaine (Area)
• Contacts associés (Associated contact)

Suivi des rappels

mGsd fournit plusieurs outils de suivi des rappels :

• Dans des tableaux de bord
  • Tickler DashBoard : tous les rappels par échéances : aujourd’hui, dans la semaine, pour la suite
  • Tickler DashBoard by Contact : tous les rappels
• Dans chaque projet

Par ailleurs un de mes tiddlers par défaut affiche les rappels du jour, en incluant le code suivant (recopié d’un des tableaux de bord officiels) :

<<mgtdList
	title:'Ticklers Requiring Action'
	startTag:Tickler
	tags:'!Actioned'
	view:Tickler
	mode:global
	newButtonTags:'Tickler Enabled Once'
	where:'tiddler.ticklerIsActive()'
	sort:'tickleDate'
	dontShowEmpty:yes
	ignoreRealm:{{config.mGTD.getOptChk('AlertsIgnoreRealm')?'yes':''}}
>>

Utilisation des rappels

Lorsque la date d’un rappel est atteinte, un lien ‘*ticklers*’ clignote sur le bandeau en haut du document mGsd.

Cliquer sur ce lien ouvre un tiddler contenant la liste des rappels du jour.

Plusieurs actions sont possibles pour chacun d’eux suivant sa périodicité :

• fermer le rappel one time en le cochant
• activer le rappel pour la prochaine date d’activation en cliquant le lien ‘+d’, ‘+w’, ‘+f’, ‘+m’, ‘+y’
• ouvrir le rappel pour ensuite le supprimer en cliquant le lien ‘delete’
• ouvrir le rappel pour en modifier les propriétés

Suppression d’un rappel

Un rappel n’est qu’un tiddler spécialisé. Sa suppression se fait en l’ouvrant dans le document mGsd, puis en cliquant le lien ‘delete’.

Un menu personnalisé pour MonkeyGtd/mGSD

Il y a quelques tiddlers auxquels je veux pouvoir accéder souvent et rapidement dans mes documents MonkeyGtd, par exemple le plan du site ou le nuage de tags.

Le moyen le plus simple est d’ajouter un menu déroulant dans la barre de menu du document (DashBoard, Project, etc) .

Vous avez surement découvert le menu déroulant ‘more’ dans la barre de menu du document (DashBoard, Project, etc) en haut de votre document MonkeyGtd.

Ce menu ‘more’ est en fait défini dans le tiddler appelé MainMenu :

 {{tag{<<tag more|GTDComponent>>}}}

Cette ligne indique simplement que tous les tiddlers portant le tag ‘GTDComponent‘ seront disponibles dans le menu déroulant ‘more’. Simple et efficace

J’ai donc ajouté la ligne qui suit pour ajouter un menu ‘tools’.

 {{tag{<<tag tools|QuickAccess>>}}}

Ce menu tools contiendra des liens vers les tiddlers portant le tag ‘QuickAccess‘, par exemple:

Pour alimenter ce menu j’ai donc ajouté le tag ‘QuickAccess‘ à quelques tiddlers utiles, entre autres GtdStats, RelatedUrls, SiteMap, et TagCloud

Faire évoluer ce menu est très simple puisqu’il suffit d’ajouter ou retirer le tag ‘QuickAccess‘ aux tiddlers que l’on veut voir figurer dans le menu.

Mon tiddler « MainMenu » modifié:

[[Dashboard]]
 [[Project]]
/%
 <<tag Realm>>
 {{new{''<<newTiddler label:'+'  title:'New Action'  tag: Action Next GTD>>''}}}
 {{tag{<<tag Action>>}}}
 {{new{''<<newTiddler label:'+' title:'New Project' tag: Project GTD>>''}}}
 {{tag{<<tag Project>>}}}
 {{new{''<<newTiddler label:'+' title:'New Tickler' tag: Tickler GTD>>''}}}
 {{tag{<<tag Tickler>>}}}
 {{new{''<<newTiddler label:'+' title:'New Context' tag: Context GTD>>''}}}
 {{tag{<<tag Context>>}}}
 {{new{''<<newTiddler label:'+' title:'New Area' tag: Area GTD>>''}}}
 {{tag{<<tag Area>>}}}
%/
@@padding-left:1em;font-size:70%;
 [[starred|Starred]] &nbsp;&nbsp;
 {{tag{<<tag inbox|InboxTiddlers>>}}}
 {{tag{<<tag updt|UpgradeTools>>}}}
 {{tag{<<tag more|GTDComponent>>}}}
 {{tag{<<tag tools|QuickAccess>>}}}

@@
 @@padding-left:1em;color:[[ColorPalette::PrimaryLight]];<<tiddler MonkeyGTDVersion>>@@

Add a custom menu to MonkeyGtd/mGSD

In my monkeyGtd documents I want to keep a quick access to a few tiddlers, for example the tag cloud, the site map and the projects statistics.

The quickest mean to achieve this is to add a custom drop down menu to the main menu.

You already know the ‘more’ menu. It is defined in the ‘MainMenu’ tiddler :

 {{tag{<<tag more|GTDComponent>>}}}

This single line simply tells that any tidller tagged as ‘GTDComponent’  will appear in the ‘more’ dropdown menu. Quick, easy, efficient.

So I have added this line to add a ‘tools’ menu:

 {{tag{<<tag tools|QuickAccess>>}}}

This menu will contain links to eacha and every tiddler tagged as  ‘QuickAccess‘, for example :

To feed this menu I have simply tagged as  ‘QuickAccess’  the GtdStats, RelatedUrls, SiteMap, and TagCloud tiddlers

This menu can be quickly modified by tagging/untagging tiddlers as ‘QuickAccess’.

My Modified ‘MainMenu’ tiddler:

[[Dashboard]]
 [[Project]]
/%
 <<tag Realm>>
 {{new{''<<newTiddler label:'+'  title:'New Action'  tag: Action Next GTD>>''}}}
 {{tag{<<tag Action>>}}}
 {{new{''<<newTiddler label:'+' title:'New Project' tag: Project GTD>>''}}}
 {{tag{<<tag Project>>}}}
 {{new{''<<newTiddler label:'+' title:'New Tickler' tag: Tickler GTD>>''}}}
 {{tag{<<tag Tickler>>}}}
 {{new{''<<newTiddler label:'+' title:'New Context' tag: Context GTD>>''}}}
 {{tag{<<tag Context>>}}}
 {{new{''<<newTiddler label:'+' title:'New Area' tag: Area GTD>>''}}}
 {{tag{<<tag Area>>}}}
%/
@@padding-left:1em;font-size:70%;
 [[starred|Starred]] &nbsp;&nbsp;
 {{tag{<<tag inbox|InboxTiddlers>>}}}
 {{tag{<<tag updt|UpgradeTools>>}}}
 {{tag{<<tag more|GTDComponent>>}}}
 {{tag{<<tag tools|QuickAccess>>}}}

@@
 @@padding-left:1em;color:[[ColorPalette::PrimaryLight]];<<tiddler MonkeyGTDVersion>>@@