飯能一周したい人生だった

飯能ライドで秩父まで抜けてわらじカツ丼で優勝して戻ってくるつもりが、通行止めの嵐で事前の調査不足を痛感したので、通行止めだった箇所と、秩父に抜けるにはどうすればいいのか、などをメモ程度に書いておく。

なお、この情報は 2021 年 5 月 8 日時点のもので、最新ではない可能性が高いです。ライド前に必ず一次情報を参照してください。

飯能、秩父周辺の通行止め情報

• https://www.pref.saitama.lg.jp/b0904/tukoseigen/index.html
• https://www.pref.saitama.lg.jp/b0902/ringyou/shinrinkanridoujoho.html

Rust プロジェクトのビルド速度

ご存知の通り、Rust のコンパイル速度は遅い。まぁそれだけ高級なことをやっているんだから仕方ないとは思う。 それにパフォーマンスダッシュボードを見てみると着実に改善していてすごい。

とはいえ、現実にはその遅さによって微妙な待ちが発生してしまうのは事実。何とかならないかな・・・と思っていたら 「GitHub Actions best practices for Rust projects」 という記事を見つけた。

記事自体のテーマは GitHub Actions における Rust プロジェクトだけど、そのうちの１つはビルド速度の改善。

これはうってつけだ！ということで早速趣味プロジェクトの CI に導入して試してみた。

アップグレード内容

• imeZi 167 → ENVE SES 3.4
• Selle San Marco Aspide Racing → fizik ANTARES VERSUS EVO 00 ADAPTIVE
• SHIMANO S-PHYRE RC9 → S-WORKS ARES

パーツじゃないものもあるけど目をつむってほしい。

acot というのは

puppeteer を使ったアクセシビリティテストフレームワークで、 ウェブサイトや Web アプリケーションに対してルールに基づいて機械的にチェックを行って結果をレポートしてくれます。 似たような目的を持ったツールは他にもあるようですが、静的解析ではなく、実際にブラウザに表示して AOM や DOM を使って検証を行うため、 マウスカーソルを要素にホバーしたときにどうなるかなど動的な検証が得意なのが特徴です。

ルールは ESLint のように extends で拡張可能なので、自社のアクセシビリティガイドラインに基づいたルールを構築することもできますし、 まだガイドラインのようなものがなければ、acot のプリセットも使えるし、スモールスタートで小さなルールセットから始めることもできます。

さらに実行戦略である Runner や結果表示の Reporter などプラグイン機構によって様々な環境に適用できそうです。 例えば GitHub の PR ごとに GitHub Actions で実行して結果をコメントとして残すようにしたり、 本番環境に対して定期実行させて結果を Slack に流したりできそうです。

無限の可能性

ということで無限の可能性を秘めているのでプラグインを作ってみようと思います。

思考停止プレス

これまで、いわゆる「マニュアル車」のようなペーパードリップのメリット・デメリット、淹れる時間、テクニックの追求をまるごと楽しんでいたわけだけど、 3 ヶ月前に長々と書いた記事のことなどすっかり忘れてしまうほどに、 Delter Coffee Pressにハマってしまった。

今回は思考停止して狂ったように Delter で 3 ヶ月間淹れまくった理由を、「なぜなぜ分析」で紐解こうと思う。自分のために。