#dépendance
Publications relatives à cette étiquette
Montre
J’ai une Suunto Ambit Black [archive] achetée il y a une douzaine d’années. (Merci à Suunto de garder une page avec les caractéristiques d’un produit qui n’est plus construit / vendu ! C’est notamment utile pour comparer les spécifications de taille et poids.) Je me demandais si les montres actuelles allaient pouvoir résister à une température inférieure à -20°C et il semblerait que ce ne soit pas le cas, tous les modèles que j’ai consulté spécifient clairement que c’est la limite basse.
Détail marrant : Kilian Jornet était déjà sur les photos de promotion de la Suunto Ambit Black et on le retrouve sur la Coros Apex 2 Pro d’aujourd’hui.
Au-delà de l’aspect scientifique d’envisager une montre qui résiste aux températures locales, il y a une situation récente qui me reste en tête aussi (ce n’est pas la première fois, et ce ne sera certainement pas la dernière). Une position GPS précise aurait certainement pu m’aider dans ce cas là, si je n’avais pas été trop entêté pour ne pas la consulter. J’envisage aussi des objectifs sur lesquels j’ai besoin de me rassurer / entraîner spécifiquement en ayant une idée des distances que je pourrais parcourir dans un contexte donné que j’envisage plus rapide que ce que j’ai l’habitude de faire.
Je cherche en priorité une montre qui affiche un fond de carte, ce n’est pas tant ma trace programmée que ce qu’il y a autour qui m’intéresse dans d’autres contextes exploratoires. Sur ma montre actuelle, je ne pouvais qu’enregistrer une trace à suivre qui m’indiquait les déviations mais pour ma pratique ce n’était pas très intéressant. Savoir qu’il y a un lac / chemin forestier à proximité peut changer ma sortie. Difficile de savoir a priori si les données pour mes lieux de balade seront à jour ou suffisamment détaillées.
J’ai regardé l’Apple Watch Ultra 2, la Suunto Vertical Titanium Solar, des Garmin d’« aventure » et finalement la Coros Apex 2 (Pro). Dans tous les cas, ce sont de grosses montres et j’ai un poignet fin. Dans tous les cas, le marketing est complètement délirant 🙃. Sans compter le prix. La Coros semble être la moins chère (!) qui réponde à l’ensemble de mes attentes, la version Pro ayant une meilleure précision GPS et autonomie, ce qui m’importe beaucoup.
Ah, aussi. Difficile à justifier, même amortie sur la prochaine décennie… et c’est d’ailleurs là où j’ai de sérieux doutes en terme d’obsolescence programmée, ce qui a duré 10 ans ne durera probablement plus 10 ans. Triste réalité. J’essaye de ne pas trop me demande si je vais être capable de passer encore une décennie à arpenter la forêt.
Montre moi tes peurs et je te dirai comment les acheter.
P.S. : j’ai un petit truc qui me gratte aussi dans le fait de ne pas être utilisateur régulier de uMap, ce qui est un manque à différents niveaux. Avoir davantage de données me motiverait certainement à jouer avec. Il y a des lieux que je veux garder intimes et d’autres qui sont déjà bien publics. J’ai une vieille envie de pouvoir raconter mes sorties sur un fond de carte à la StoryMap (avec Leaflet ?) pour agrémenter les récits de sons et images correspondants aux lieux parcourus.
In·directions
Any time you have a design that references the same value across multiple pieces of UI, I’d suggest that is an opportunity for abstracting that value into a name that better describes the intention of the value in the design.
Je me demande souvent quel est le bon niveau hiérarchique au sein des CSS modernes. L’approche constatée actuelle semble être de mettre des variables par couleur (par exemple) puis ensuite définir des variables intermédiaires pour leur donner un sens pour un contexte donné.
:root {
--umap-color-darkBlue: #263B58;
}
button {
--color-primary: var(--umap-color-darkBlue);
}
button.primary {
background-color: var(--color-primary);
}
Il s’agit ici de partir d’un exemple simpliste mais concret. J’imagine qu’il y a autant de dévelopeur·euse que de façon d’écrire ces 3 seules déclarations :). Pourquoi :root et pas html ? Est-ce qu’il faut définir les couleurs primaires sur le button ou sur form, nav ? Ou faire sauter cet intermédiaire ? Est-ce qu’il faut button.primary, .primary, .button-primary, .button.button-primary ? Etc, etc.
Et je ne mentionne même pas les solutions à partir de :host / :host-context() ou :scope qui sont encore d’autres façons de faire qui sont peut-être amenées à devenir populaires.
Venant d’un langage dont l’un des mantras est There should be one-- and preferably only one --obvious way to do it.
, il est plus difficile de se retrouver devant une telle… flexibilité ? Lorsqu’on envisage un commun sur ces 10 prochaines années, comment trouver une stratégie maintenable qui s’inscrira dans la durée avec enthousiasme ?
Ce qui est certain, c’est que l’approche de Tailwind ne me convient pas du tout.
To keep up with the ever-evolving CSS standard Tailwind introduced another set of language literals. Over the years Tailwind has grown from a simple set of atoms to a vendor-specific language with expressions, operators, and method calls.
File over app is a philosophy: if you want to create digital artifacts that last, they must be files you can control, in formats that are easy to retrieve and read. Use tools that give you this freedom.
File over app is an appeal to tool makers: accept that all software is ephemeral, and give people ownership over their data.
Learn about the systems that already exist, and build on them rather than around them. If an existing system doesn’t do what you want, maybe the problem is in the design of your system, not that one.
If you do build a new component, make sure it’s of general utility. Don’t build infrastructure that solves only the problems of your own team.
It’s easy to build complexity. In the rush to launch, it’s quicker and easier to code than to redesign. But the costs accumulate and you lose in the long run.
Archives
Google will no longer be keeping a backup of the entire Internet. Google Search’s “cached” links have long been an alternative way to load a website that was down or had changed, but now the company is killing them off. Google “Search Liaison” Danny Sullivan confirmed the feature removal in an X post, saying the feature “was meant for helping people access pages when way back, you often couldn’t depend on a page loading. These days, things have greatly improved. So, it was decided to retire it.”
Google will no longer back up the Internet: Cached webpages are dead
[archive]
(rires)
Forcément en lisant ça un samedi matin, j’étais immédiatement motivé pour améliorer la façon dont j’archive les liens par ici. À commencer par des méta-données qui permettraient d’avoir une prévisualisation des liens un peu enrichie.
Je me dis que je ne dois pas être le seul à essayer d’extraire des informations des pages. Et j’en trouve pas mal : hyperlink_preview, extruct ou url_cache pour ne citer qu’eux. Cela me met sur la piste de Lassie qui semble extraire ce que j’aimerais avoir : une image ou favicon, potentiellement une description, ainsi qu’une langue. Jake Lazaroff m’avait depuis répondu qu’il génère en fait ses vignettes au moment de la construction du site. Je ne veux pas totalement suivre cette approche car je ne veux pas stocker d’images additionnelles mais je vais essayer d’avoir une solution hybride.
Cela m’embête de plus en plus de coupler le générateur de site aux (méta-)données des archives. À méditer.
Pour ce qui est de l’interface, ça attendra un autre jour. J’ai tout de même ajouté des attributs hreflang et la bonne langue dans les pages d’archives, un truc qui me grattait depuis un bout de temps.
Cela fait bien longtemps que je regrette d’avoir acheté des enceintes Sonos. Hier — encore une fois frustré par l’application proposée par défaut — je découvre SoCo ainsi que soco-cli après quelques recherches. Je passe ensuite la soirée à batailler avec Automator pour pouvoir faire un clic-droit sur un dossier local et que ça me lise les fichiers FLAC qui sont dedans.
J’arrive à la solution suivante :
on run {input, parameters}
tell application "Terminal"
do script "cd ~/sonos && sonos Chambre play_dir '" & (POSIX path of input) & "'"
end tell
return input
end run
Ce n’est pas très élégant et je n’ai pas réussi à faire en sorte que ça se lance dans iTerm mais au moins ça joue de la musique.
drab focuses on providing JavaScript functionality where it’s most useful. Many of the elements are helpful wrappers around browser APIs. Here are some of the features of the library.
Le futur qui se dessine à ce sujet est très stimulant. Cela fait 15 ans qu’il y a une production de masse de code JS qui n’est ni réutilisable, ni interopérable. J’ai bon espoir que ce soit en train de changer.
When trying to defend this, economists typically claim that we have unlimited desire for new stuff. Apparently, rather than dedicating the time gains from technology to leisure, we pour it into making more stuff for ourselves. This is bogus. People do have a limited desire for new things, because dedicating yourself to endless production (and consumption) comes at the expense of hanging out with your family, friends and pets, or doing stuff like walking in the wilderness or surfing the waves. What people actually desire is a balance of many things, but the system we’re stuck in has unlimited desire for one direction only. That’s because it’s a vortex unleashed by humans who no longer know how to stop it.
Tech doesn’t make our lives easier. It makes them faster
[archive]
Un bon article à lire après 24h de galères techniques 😅.
Extinction
So where have all the websites gone? Well, the people who make them have all gone to war for the capitalist machine. They grew up and got jobs. A natural part of growing up. Silos came and plucked their voices. Invasive memes and short form content grew in their place. Hustle overtook leisure. Harassment overtook openness. Influence overtook creativity. An economy of interestingness replaced by one of followers, likes, and engagement metrics.
One important thing to note; websites aren’t extinct. In fact, you’re on one now! Uploading your own words is ancient technology but still works.
En réponse à Where have all the websites gone?
[archive]
que j’ai déjà cité. Peut-être que la capacité à publier est toujours là mais que nous avons trop changé pour être capables de perdurer dans cette pratique. 2024 pourrait me faire mentir car je vois une certaine effervescence dans mon agrégateur. On va bien voir si ça dure. On va bien voir si je dure.
Guidé par le besoin, je suis en train d’automatiser des ancres sur mes <hr>, fausse bonne idée ? En affinant un peu le style ça me convient pour l’instant.
public-inbox implements the sharing of an email inbox via git to complement or replace traditional mailing lists. Readers may read via NNTP, IMAP, POP3, Atom feeds or HTML archives.
public-inbox spawned around three main ideas:
- Publicly accessible and archived communication is essential to Free Software development.
- Contributing to Free Software projects should not require the use of non-Free services or software.
- Graphical user interfaces should not be required for text-based communication. Users may have broken graphics drivers, limited eyesight, or be unable to afford modern hardware.
public-inbox aims to be easy-to-deploy and manage; encouraging projects to run their own instances with minimal overhead.
public-inbox - an "archives first" approach to mailing lists [archive]
D’une certaine manière, l’extinction de voix des un·es fait mon bonheur de découverte aujourd’hui. J’espère que le réflexe ne sera pas de passer de Google Groups à Microsoft Github Discussions par commodité.
… ça veut dire qu’en vrai, les droits humains, tu t’en fiches pas mal.
Et que tu es juste un peu raciste.
Voilà.
Cette photo est floue, c’est devenu tellement rare avec un téléphone (OK Boomer :p). Les couleurs étaient superbes et une fois les mains réchauffées c’était une ambiance très agréable. On n’a pas croisé grand monde. La rééducation active continue tranquillement son chemin.