Ça faisait des années que je voulais aller essayer ce bloc.
Je ne sais pas si j'ai oublié de prendre les bonnes prises, ça m'a semblé difficile:
excellents mouvements en tension, mais le sloper au centre est particulièrement misérable pour le grade.
(à faire à 5°C, de préférence)
Un dernier jour à Cumberland.
Je n'ai pas réussi à trouver assez de pouvoir pour faire Slurpee Low, ni le beta de toe hook, ni le
beta de campus ne fonctionnait.
Le gens semblent penser qu'il s'agit de "Sugar V7", mais le guide des réglements indique que Sugar
passe dans la pince. Il n'y a pas de pince ici. C'est juste une version plus dure du bloc
précédent.
Note au passage: il y a vraiment des lignes eliminate ici, c'est un peu dommage.
La ligne sugar v7 vaut la peine, même si c'est légèrement forcé.
Le guide original dit V9, le nouveau guide dit v7/8.
Raby dit: V7 pour quelqu'un de 5'8".
Un seul mouvement dur avec des pieds bien placés et une prise de réception gigantesque.
Ça bouge bien, mais c'est encore un peu sale en haut.
Il y a une prise qui sonne creux près de la sortie, personellement je crois qu'on devrait l'arracher avant que quelqu'un parte avec en grimpant...
Le premier mouvement m'a semblé difficile pour le grade suggéré de V5.
Pour ceux qui aime les lignes de campus sur crimps avec des pieds de 2mm.
Visuellement c'est magnifique, mais les doigts l'apprécie moins.
Ça rappelle un peu l'express à val-david, avec des mains coupantes et des pieds plus minces.
Peu de mise à jour cette automne, je crois que je suis sorti grimper 5 fois.
C'est la vie.
J'étais au Tennessee pendant 3 semaines en Novembre, voici donc un résumé video des envois qui vallaient la peine.
Il y en aurait plus, mais ma caméra el cheapo a décidé de ne pas filmer, ou d'arrêter pendant que je grimpais dans certains blocs tel que Tractor Traylor V8, Guillotine V6 et Orb Direct V9.
C'est dommage car ce sont de méga classiques.
Donc, la prochaine fois j'amène une caméra moins cheap :-)
Le voyage en résumé:
11 jours de grimpe
80 envois
216 essais
Aucun bloc dur dur
7 v5, 7 v6, 12 v7, 6 v8, 1 v9
En bref, au début du voyage j'étais malade, il faisait chaud, j'étais en forme de chaise d'ordinateur et mon épaule gauche était -- et est toujours -- mal en point. (les belles excuses...)
Après 5 sorties passées à m'arracher la peau sur les slopers et 2 jours de pause, mon corp a fini par se réveiller.
Ce n'était pas la forme de Bishop l'an dernier, mais ça faisait quand même du bien de grimper en possession de mes moyens.
Voici donc les blocs filmés, en ordre d'ascension.
Crux de petites croutes douloureuses et méga rétablissement dans l'épaule gauche.
Je l'ai eu au premier essai et la sortie ne m'a pas donné envie d'essayer la version longue, V9 qui part loin à droite.
Les prises sont toutes très moyennes au départ, on tentait de trouver un beta délicat.
Finalement c'est passé en allant à droite avec un peu plus d'intention.
La section du mileu est assez facile, mais il y a un plat immonde dans la sortie!
(La ligne de droite, Latin for Dagger V5, c'est aussi majeur!)
J'avais les doigts tout roses et chaque prise me semblait granuleuse, prête à me percer la peau.
Le livre guide indique it's not over till it's over, avec raison!
Il reste des mouvements délicats en haut avec une chute potentielle douteuse dans l'arbre..
This is a (hopefully) short piece explaining the process of debugging ObjectId collisions in MongoDB,
in an environment involving Ruby and containers (GCP Cloud Run Jobs -- basically kubernetes jobs).
MongoDB is a document database: json documents can be stored in it and each document has its
own unique ObjectId. (This is a very simplified summary, more info here.)
An ObjectId is a 12 byte number that uniquely identifies a document.
This number is generated on the client, before inserting a new document in the db.
While the format is standard,
each client library has to implement it.
The ObjectId format is as follows:
4 bytes timestamp in seconds from unix epoch
5 bytes random value generated once per process. This random value is unique to the machine and process.
3 bytes counter, initialized to a random value, incremented every time an ObjectId is generated.
I like these IDs, they're sortable-ish across machines, the 5 bytes of random "process id" should be
enough to avoid collisions, they're fast to generate and you can get 16M of them per second before
they repeat.