Il y a un peu moins de 3 ans je publiais un article Comment un casque réducteur de bruit a changé ma vie ? dans lequel je parlais de mon acquisition d'un casque Bose QuietComfort 25.

Dans les commentaires a href="https://blog.genma.fr/?Comment-un-casque-reducteur-de-bruit-a-change-ma-vie" title="Comment un casque réducteur de bruit a changé ma vie ?">du billet de blogplusieurs personnes remontent les problèmes d'acouphène qu'elles rencontrent au bout de quelques temps avec des casques réducteur de bruit.

Je me suis donc dit que ce serait intéressant, après 3 ans, de faire partager mon retour d'expérience.

J'utilise ce casque à minima 3h par jour, dans les transports en commun et dans la rue. Je suis la majorité du temps en mode passif. Le casque couvre l'intégralité de l'oreille et cela étouffe le son extérieur et cela me suffit pour m'isoler du bruit environnant sans toutefois m'en couper définitivement. Je n'active la fonction que je qualifierai de mode actif de correction du son (qui utilise alors l'énergie d'une pile, pile rechargeable que je recharge environ une fois par mois / mois et demi) que lorsque je suis dans le métro, quand il y a une conversation bruyante ou du bruit environnant (fenêtre ouverte). Ce dispositif actif créée une sorte de sensation de vide d'air et si le son (musique ou autre est coupé), on a une sorte de souffle sourd qui entoure l'oreille et qui est gênant. Il faut que la réduction de bruit passive se fasse avec diffusion de son pour que ne ce soit pas gênant. La majorité du temps je suis en mode passif.

Lorsque je suis dans la rue et que je reçois / passe un appel via le téléphone auquel est relié le casque, j'active le mode réduction de bruit ce qui permet d'avoir un kit main libre avec un son de bonne qualité. Mais je ne garde le casque que sur une des deux oreilles, je libère l'autre oreille, ce qui permet de compenser le souffle et le gène de la réduction de bruit qui est plus prononcé que dans le cadre de l'écoute d'une musique ou d'une émission en continue (dans le cadre d'un appel, il y a des phases de blanc ou votre interlocuteur vous écoute et avec la réduction de bruit, on ne s'entend pas parler ou de façon atténuée et c'est perturbant).

J'ai utilisé ce casque en environnement bruyant de type openspace, là encore la majorité du temps en mode passif. Je n'active le mode actif que quand il y a vraiment du bruit et que je souhaite m'isoler. Je ne rencontre pas de problème d'acouphène (par chance peut être), mais je pense que l'usage en mode majoritairement passif joue. A voir.

Le casque n'est pas lourd, je le porte pendant un moment sans soucis. Il n'y a qu'en été où il tient chaud aux oreilles et la transpiration devient gênante, nécessitant de l'enlever et de laisser sécher. Le cuir des écouteurs et la mousse sont toujours les mêmes depuis le début, mais peuvent être changés facilement, avec des produits accessoires de la marque (assez cher) ou alternatif.

Je ne commenterai pas la qualité sonore du casque, elle me convient pour mes usages (écoute de musique MP3 ou de podcast, de vidéos Internet (Youtube ou autre) donc des sons compressés par défaut).

Voilà, pas grand chose à dire de plus pour l'instant.

Le premier texte sur ce site a été publié (et effacé depuis) le 2 juin 2004.

En juin 2004 je débutais ce blog sous SPIP sur des pages perso de Free.fr. 2004 c'était l'année de la naissance d'Ubuntu... L'année de la naissance de Korben.info, au mois de juin. Le site Archive.org permet de retrouver quelques pages de cet époque...

15 ans plus tard, c'est aussi 15 ans de vie pour moi. Je suis passé de l'approche des 25 ans à celle des 40 ans. Je suis toujours avec RyoOki et en 15 ans. 15 ans de changement de vie professionnel, 15 ans de Linux, de logiciels libres et d'opensource. 15 ans (en fait plus, depuis les années 80) de geek et popculture. 15 ans (en fait plus de 20 ans) d'Internet... 15 ans de partage sur ce blog, d'écrit personnel, intimiste, de réflexions... 15 ans de vie partagée sur Internet.

Le jour de la publication de cet article, je suis à la maternité pour faire le suivi de l'arrivée imminente de Mononoke (des billets à suivre dans les prochaines semaines, mois et années en perspective). Comme ça vous savez tout !

Si vous lisez ces mots, laissez en commentaire votre premier souvenir de ce blog, ça me fera plaisir.

Dans le présent billet je voudrais mettre le focus sur une bonne pratique de documentation que nous avons au sein de mon équipe d'administrateur système, à savoir celle d'ajouter des extraits de bash_history dans le suivi des tickets dans le Kanban.

Je pars du principe que vous utilisez un shell bash par défaut, que ce soit sur votre machine en local ou sur les machines serveurs accédées à distance. Le principe reste le même avec les autres shells.

Le *bash_history* est le fichier caché qui contient l'historique des commandes shell (bash) saisies dans un terminal et qui est conservé dans le dossier de chaque utilisateur. Ces commandes correspondent donc aux commandes saisies au cours des différentes sessions. Le bash_history est donc une forme de traçabilité des actions.

Dans le présent billet ce sera un abus de langage pour désigner les dernières commandes tapées en tant qu'administrateur système.

Quand on fait de l'administration système, il est pratique de retrouver des commandes ou séquences de commandes déjà tapées et de les rappeler pour les ré-exécuter, dans son terminal.

Dans le cadre d'une documentation wiki, un exemple valant mieux qu'un long discours, nous avons comme bonne pratique d'ajouter dans le suivi du ticket (dans le Kanban, je ferai un billet dédié nos processus d'usage du Kanban) les commandes issues d'un copier coller du bash_history.

Le bash history est bien évidemment à nettoyer un peu (surtout si on a tâtonné). Il faut idéalement rajouter des commentaires pour les commandes qui ne sont pas évidentes. Cela permet d'avoir rapidement la structure pour l'ébauche de la documentation où l'on généralisera si besoin les commandes pour que ce ne soit plus spécifique aux actions menées dans le cadre du ticket mais utilisable dans un cadre plus général.

Dans le cas d'un post-mortem, le bash_history permettra d'analyser la démarche et les actions qui ont été réalisées pour résoudre un problème, de retrouver les pistes qui ont été explorées et celles qui n'ont pas abouties.

Il y a un peu plus de deux ans, j'avais déjà commencé une phase de réflexion sur le minimalisme (cf mon billet de blog Je suis en phase de minimalisme) en me rendant compte que la réflexion était déjà plus ancienne... Avec l'agrandissement de la famille, la réflexion perdure.

Quand on va avoir un enfant, il y a tout un tas d'objets, de choses diverses et variées que l'on avait pas auparavant et qu'il semble nécessaire d'avoir et de posséder. Il y a des choses qui semblent évidentes, d'autres qui semblent utiles et certaines pour lesquelles on se questionne de la réelle nécessité. Beaucoup de choses auront un usage sur une durée limitée dans le temps, pour peu qu'elle soient vraiment utiles. Je ne détaille pas les choses et objets en question, cela n'étant pas le sujet du présent article de blog.

Pour préparer la venue de notre enfant, nous consultons donc régulièrement les sites de petites annonces pour acheter des objets déjà utilisés, mais nous consultons également les sites de dons. Pourquoi des sites d'annonces d'objets déjà utilisés et ne pas vouloir à tout prix des choses neuves ? Au delà de l'aspect économique, il y a une démarche militante. Dans une société de consommation qui pousse à toujours posséder plus, avoir plus de choses qui ne sont pas durables, réutiliser des choses et objets, donner une seconde, troisième (ou plus) vie à un objet n'est pas une mauvaise chose. Il y a donc une forme de recyclage) à recourir à des objets de seconde main. Il ne faut pas non plus tomber dans l'excès du ce n'est pas cher (cas des annonces d'occasion) ou c'est gratuit (cas du don) et d'entrer dans une spirale de cumul d'objets. Cf le minimalisme évoqué au début de cet article.

Ces derniers mois de préparatifs, nous avons cumulés différents objets dont nous pensons qu'ils peuvent être et seront sûrement utiles. Mais nous nous posons bien la question de l'utilité de l'objet. Il y a des objets que nous n'aurions pas acheté que nous avons récupéré. Mais nous savons que nous les garderons en bon état et que nous les redonnerons à notre tour si ou quand nous n'en aurons plus usage. Contribuant ainsi au cycle du don.

Je pense pas que je ferai de billets sur les objets et la parentalité, je n'en ai pas fait sur toute la phase de gestation et d'attente. Il existe des tas d'articles et de sites dédiés sur ces thématiques. Je saisissais juste le prétexte des préparatifs pour rédiger et partager une pensée, une réflexion sur les objets, l'occasion et le don d'une façon générale.

Dans le présent billet je voudrais mettre le focus sur une bonne pratique de documentation que nous avons au sein de mon équipe d'administrateur système, à savoir celle d'ajouter des extraits de bash_history dans le suivi des tickets dans le Kanban.

Je pars du principe que vous utilisez un shell bash par défaut, que ce soit sur votre machine en local ou sur les machines serveurs accédées à distance. Le principe reste le même avec les autres shells.

Le *bash_history* est le fichier caché qui contient l'historique des commandes shell (bash) saisies dans un terminal et qui est conservé dans le dossier de chaque utilisateur. Ces commandes correspondent donc aux commandes saisies au cours des différentes sessions. Le bash_history est donc une forme de traçabilité des actions.

Dans le présent billet ce sera un abus de langage pour désigner les dernières commandes tapées en tant qu'administrateur système.

Quand on fait de l'administration système, il est pratique de retrouver des commandes ou séquences de commandes déjà tapées et de les rappeler pour les ré-exécuter, dans son terminal.

Dans le cadre d'une documentation wiki, un exemple valant mieux qu'un long discours, nous avons comme bonne pratique d'ajouter dans le suivi du ticket (dans le Kanban, je ferai un billet dédié nos processus d'usage du Kanban) les commandes issues d'un copier coller du bash_history.

Le bash history est bien évidemment à nettoyer un peu (surtout si on a tâtonné). Il faut idéalement rajouter des commentaires pour les commandes qui ne sont pas évidentes. Cela permet d'avoir rapidement la structure pour l'ébauche de la documentation où l'on généralisera si besoin les commandes pour que ce ne soit plus spécifique aux actions menées dans le cadre du ticket mais utilisable dans un cadre plus général.

Dans le cas d'un post-mortem, le bash_history permettra d'analyser la démarche et les actions qui ont été réalisées pour résoudre un problème, de retrouver les pistes qui ont été explorées et celles qui n'ont pas abouties.