ゴミ / 曲 / 金 / 壺　大変

繋がりのない話を4つ書く。

最近、ようやく部屋に溜まっていたゴミを片付けた。生活式用として自炊ができる状態になく、デリバリーかNoshの弁当ばかり食べている上にその空き箱を捨てずにサイドテーブルなどの作業スペースに置きっぱなしにしてしまっていて、それで手の届く範囲や、それが埋まってしまったので床などがゴミだらけになっていた。それらに対してようやく手を付け、45Lのゴミ袋3つ分にまとめ上げた。これによってサイドテーブルが復活したのがとても嬉しい。

自分はゴミを溜めてしまうこと以外にも、食後の皿洗い*1や、洗濯、掃除など、継続的にやらなければならなさそうな家事が全くといって良いほどできない。1, 2ヶ月に一度、「そろそろ実害が出始めたな」といったトリガーによって突発的に行うことはあるが、毎日ないし毎週動くことはできない。これは昔からそうで、この種類のタスクの優先度をかなり低めに見積もってしまう節がある。これによって起きる弊害について特に考えていない(考えることができない)のか、起こったとしても気にしていないのかわからないが、とにかく僕は怠惰らしい。

そんな怠惰さによって完成する自分の部屋の惨状を人に伝えると大抵引かれてしまうので、おそらく将来的にはどうにかしたほうが良いのだろう。傍からの評価は自分が思っているより大事っぽくて、人との付き合いに支障をきたす場合もあるらしい。僕は色んな人とうまく付き合っていきたいよ。一体どうすれば良いのだろう。今の考え方だとあまりモチベーションに繋げられないので、なにか自分にとって画期的な考え方を持って納得するしかない。もしかして本当に動くのが嫌で(怠惰すぎて)掃除などに繋がる考え方を捨て去っているのではないか？どうするべきなんだろう。完全なる未解決です。

とある件によって曲を拵えないといけないのだけれど、現状進みが悪い。3月上旬には完成している必要があってかなりまずい。具体的には曲の全体的な方針の時点でずっと迷い続けている。何かを作っては消し、を繰り返している。道は長い。今もまた頑張って挑戦しているが、どうしても中途半端な何かができあがってしまいそうなところ。根を詰めるため、来週は有給をとって全部休みにした。これで完成してほしすぎる。将来の自分にご期待ください。よろしくお願いします。

僕はメインバンクとしてPayPay銀行を使っているのだけれど、どうやらPayPay銀行で発行しているデビットカードの番号が流出しちゃったらしい。多分、自分の依存しているサービス史で最も核心に近いインシデントだと思う。

で、これはPayPay銀行が悪いというよりは自分がどこかのサービスで決済した時にそのサービスが支払いの際に依存/利用している決済サービスがおもらししちゃった、というように見える。株式会社メタップスペイメントによる報告はこちら→ 不正アクセスに関するご報告とお詫び | 株式会社メタップスペイメント。実際の問題発生からカードの停止にラグがあることに気づいた。おそらくだけれど、メタップスペイメントから今回の対象になった自分のカード番号をPayPay銀行に通知し、それを受け取ってPayPay銀行はデビットカードを止めてくれたという流れによるものだと思う。また、この対応によってこれまで使っていたカード番号を引き続きで使うことはできなくなったので、再発行の申請を余儀なくされた。現在は到着待ち状態。生活の上でこのカードを使い倒しているのではよ来てほしい。

ここで実際に問題になった決済サービスが利用している「トークン方式」について疑問が生じた。単に決済について詳しくなく、トークン方式も初耳だった。調べてみると、ECサイトなどがカード情報を持つことなく決済を行うための仕組みのように見えた。具体的には↓の通りに読めた。

  1. ECサイト上の決済情報登録時、クライアントにカード情報を入力させる(これはECサイトには投げない)
  2. クライアントは上記カード情報を決済サービスに投げる
  3. 決済サービスはカード情報を保持し、この情報に対応したトークン(ランダムのような文字列)を返す
  4. クライアントはトークンを受け取ったのち、これをECサイトに投げる
  5. ECサイトはトークンや支払い金額など?を決済サービスに投げる
  6. 決済サービスはトークンからカード情報を引っ張ってきて、カード会社に対して金銭的なやり取りを要求する

トークン決済｜クレジットカード決済代行 F-REGI（エフレジ）

これは「クレジットカードの非保持化」というものらしく、2018年に施行された「改正割賦販売法」によって推進されているものらしい。決済サービス側もPCIDSSという国際的なセキュリティ標準に則って保持しているらしい。

【今さら聞けない】誰でもわかる PCI DSSの要件と対応方法 | ナレッジ／事例 TISプラットフォームサービス | 特集・レポート | ITソリューションのTIS株式会社

ECサイト側がこんな面倒くさい規格に則っていたらサイクルの速い商売の波に置いてかれてしまうだろうし、こういった分割は妥当に思う。今回はこれに準拠しているはずの決済サービス側が突かれてしまったということで、仕方のないことのように思う。仕方ないことではあるのだが、重大なインシデントには変わりがなく、担当者は現在進行系で大変な状態なのだろう。僕は昔「金や命を扱うサービスの開発には関わらないほうが良い」と教えてもらってたことがあって、今回の件を見てこの言葉を何度も思い出した。金や命を扱うサービスの開発には関わらないほうが良い。

壺についてはまあ順調で、さっきまた記録を更新した。5分を切ってからの変遷はこんなかんじ → 4:58 → 4:55 → 4:38 → 4:37 → 4:28

youtu.be

相変わらず大ミスをしすぎていて、これがなかったらもう普通に4分切ってたんじゃないか？という気持ちがある。ちなみに4:38の記録あたりからようやくスロープスキップに挑戦し始めた。はやいところ百発百中の精度を手に入れたい。

*1:これはもうできないことがわかったのでできれば使い捨ての食器を使うようにしている。洗い物を増やさないため。

マンガクロスの作品のRSSフィードを作成できるようになった

昨日、こんな記事を書いた→ 「僕の心のヤバいやつ」用のRSSフィードを作成した - 名有りさんの日記 が、実はマンガクロスでも連載中*1の潮が舞い子が舞いも見たいことがわかった。ので、やはり実装を適切に抽象化し、複数作品に対して対応できるようにした。

おそらく事実上は全ての漫画クロス作品に対応できたので、このリポジトリで全部をクロールできるようにする選択肢もあったが、しないようにした。もし他のマンガクロス作品が見たかったらご自分でフォークしてもらうと良さそう。src/main.rs の TARGETS を好きに変えることで達成できると思う。それか僕に推薦してハマらせる、など

*1:本流は別冊少年チャンピオンで連載中

「僕の心のヤバいやつ」用のRSSフィードを作成した

(追記)

結局マンガクロスの他作品にも対応できるようにした→ マンガクロスの作品のRSSフィードを作成できるようになった - 名有りさんの日記

(追記ここまで)

osmosfeedを使って自分のためのアンテナ(RSSリーダー)を作成する - 名有りさんの日記 でいろいろなRSSフィードを漁るようになったんだけれど、webで読めるタイプのマンガにRSSフィードはあまり無かったりするっぽいかった。ので、それこそosmosfeedよろしくでGitHub Actionsを使用して定期的に僕ヤバを見に行き、記事一覧をRSSフィードにするやつを作った。↑のリンクからどうぞ。

マンガクロスはSPAっぽくなっていて、アクセスした時にマンガの情報APIを叩く。これに各話、巻についての情報が付いてくるので、これをRSSのフィードにした。アクセスしてjsonをRustっぽく扱うのはふつうにserde, serde_jsonで、RSSフィードを作るためには GitHub - rust-syndication/rss: Library for serializing the RSS web content syndication format を使用した。ここまでやると、実はマンガクロスの任意の連載のRSSフィードを作り放題な気がするんだけれど、今の所マンガクロスの他の作品は読んでいないのでそのような共通化はなにもしていない。マンガが置いてある階層をリポジトリにそっくりそのままで置いて( naari3.github.io/mangacross-rss/yabai/feed.xml みたいな )、全ての作品についてそうすることを考えたけど、なんというかじぶんの中のラインを超えてしまうし、何より範囲が広くなって面倒を見きれなくなる。何事もスコープは狭いに限るのだ。

あとはふつうに .github/workflows を設置した。r7kamuraさんの r7k をそのまま持ってきたようなものにした。動きとしては、

  • まず tag.yml でmainブランチを監視、Cargo.toml の version が新しくなっていたら新しいタグを作る。
  • 次に、release.yml で新しいタグの作成を検知して新しいリリースを切る。
  • 最後に、build-rs.yml で新しいリリースの作成を検知して各OS向けのバイナリを作る。
  • 追加で1時間に1回バイナリをダウンロードして実行、gh-pagesに公開するやつを仕込んだ。

のだけれど、GitHub Actionsのタグ/リリース生成に対して、GitHub Actionsが発火してくれなかった。僕のアカウントからのタグ/リリース作成には反応するのに。これが今解決できないのでタグが作成された後にのリリース作成は手動でやっている。これを解決したい。ので、もし知っていたらなにか教えて下しあ。

(追記)どうやらGitHub Actionsに自動的に付与されるGITHUB_TOKENには特別な制約があるとのことだった。発火したActionからさらに別のActionが発火できないようになっているらしい。

Automatic token authentication - GitHub Docs

When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs. For example, if a workflow run pushes code using the repository's GITHUB_TOKEN, a new workflow will not run even when the repository contains a workflow configured to run when push events occur.

まあそれはそうかも、よく見るとr7kamuraさんのymlも PERSONAL_ACCESS_TOKEN を指定していたので、そうするようにしたら動くようになった。めでたし。

壺5分切り達成、仕事、などがありました

壺をやり続けてきたけど、ついに5分を切ることができた。2018年くらいからやっていた記憶があるので、おおよそ4年来でこの目標を達成できたことになる。

ただ、途中でやっていない期間も多かったので、実際にやった期間としてはもっと短くなる。3年ぶりくらいに継続して挑戦した結果、5分を切れたという感じ。いや、いずれにせよかなり嬉しい。

その後もう少しやったらすぐ3秒縮めることができた。こちらは偶然にも動画に撮ってあって、これをYouTubeにあげてみた*1。

youtu.be

悪いところを挙げるとこんな感じ。

  • 各所もたついている
  • ピンクのシルクハットがだめ
  • バケツがだめ
  • スロープのショートカットをしていない

つまり、まだ安定している状態ではない。まだ様々な見込みがあるので、もう少しだけ挑戦してみようと思う。なんなら4分切ることも可能なように思えてきた。

技術記事を書いた↓。といってもコードはひとつも出てこないが。

「秘伝化したJenkinsと共に動いているレガシーなDockerをバージョンアップする」をやった - 名有りさんの日記

最近、仕事がつらくなってきている。数年間運用されたチームだから様々な種類の負債があるのは仕方がないことだけれど、これらが最近になって一気に露見してきた。チームで地道につぶしているが、ちょっとつらい。インシデントに対する対応を行って、その根本対応となるようなチケットを切り分けて担当してもらう、というのもやっているが、最近はこれも辛い。僕個人の技能としてタスク管理がうまいことできないからだろうか？よくわからん。わからんことばっかりやっていて、わかるようになるのは楽しいが、「負債をほったらかした結果だぞ」と後ろ指を指されている気分になって辛くなっているのかもしれん。

やることがあるんだけれど、それが手に付かない僕に対してイオンさんが教えてくれたやつ↓

*1:ニコニコ動画もそうだけど、YouTubeも長い尺の動画の扱いには時間がかかるのだなと思った。AV1とやらなのだろう。

「秘伝化したJenkinsと共に動いているレガシーなDockerをバージョンアップする」をやった

仕事でレガシーなEC2インスタンス上にあるレガシーなJenkinsと共に動いているDockerエンジンをアップデートする対応を行った。その際の備忘録を書いておく。

tl;dr

状況としては以下の通り

  • Jenkinsでのデプロイに使用しているDockerのバージョンが古すぎる
  • Jenkinsが動いているEC2インスタンスを複製してJenkins Agentとして起動した
  • master側のDockerをアップデートし、古いDockerと新しいDockerそれぞれを好きに使い分けられる状態にした

くわしく

Jenkinsの上で動いているDockerのバージョンが古すぎるため、新し目のalpineを使用したイメージを扱えない問題が発生していた。詳細は以下を参照してほしいが、ようは musl が扱う新しい命令を runc が対応しきれていない、という問題だった。

インターフェイスが大きく変わるわけでもないし、エイヤでDockerをアップデートしてしまっても良い気がしたが、このJenkinsが場当たり的に管理されてきた経緯もあり、自分自身が全てのJobについて「責任を持って管理できている」と言えるではなかった。そのため、もし問題が発生しても良いようにする方法を考える必要があった。以下のようなものが浮かび、以下のような懸念が浮かんだ。

  • AMIのバックアップを取ってからDockerをバージョンアップして、問題があったらバックアップからリストアする
    • 別の対応でJobを新しく定義などしており、巻き戻すと新たなコストが発生しかねない
  • 別インスタンスでDockerを起動して、 DOCKER_HOST をそちらに向け変えることでいつでも切り替えられるようにする
    • たしか別ホスト上のDockerにボリュームってマウントできないよね、既存のJobの要件によっては動かない
  • AMIのバックアップ経由でEC2インスタンスを複製し、Jenkins Agentを起動できる環境を用意した上でそちらだけDockerをバージョンアップする
    • これまでのJobがこれまで通りに動くことが期待できる
    • Job単位でmaster/Agentを切り替えることも可能

というわけで新たにJenkins Agentを建てることになった。といってもとても簡単で、masterのJenkinsからAgentの環境にSSHできるようにするだけで良い。一点、ログイン対象のユーザーのログインシェルが指定されていることが必要なので、 jenkins ユーザーを使いまわしたい場合はこれに気をつける必要がある。 $ chsh jenkins -s /bin/bash

その上で、Job実行時のパラメーターとして実行対象のAgentを切り替える対応も行いたい。Pipelineで作成されていればJenkinsfileに手を入れてもらうだけで良いが、そうでない場合についてはJobの設定でどうにかする必要がある。単一のAgentに縛ることは素のJenkinsで既に達成可能だが、切り替えられるようにする場合は以下のプラグインを使用する。

このパラメーターを各Jobに仕込むことで、新しいDockerではJobが失敗してしまった場合に古いDockerが存在するAgentに切り替えて実行する、という対応が可能になる。

あとは経過観察。すべてが新しいDockerでも問題なく動作して「ほら、エイヤで上げてもよかったじゃん」と笑いながら言えるようになることを期待している。

本当はこのあたりの杜撰とも言えるJenkinsの状態を見直したいが、それにしてはあまりにも巨大なので、CasCプラグインなどを使ったコード化が充分に行われているJenkinsの作成を進めている。job-dslやDocker下での管理はまずますうまくいきそうなので、個人的にも期待している。

音MAD作者のブログを集めたアンテナを作成している

さっきこんな記事を書いた→ osmosfeedを使って自分のためのアンテナ(RSSリーダー)を作成する - 名有りさんの日記

技術的な、難しいことはさておき、ようはブログのアンテナを作成することができた、というもの。これの音MAD界隈版作ろうとしている。恐らく自分が観測できている範囲の音MAD作者のブログはほとんど集めきっていてるはずで、これを実際に運用し始めている。

この収集方法は @otomad_blomaga というTwitterアカウントのように選りすぐられたものではなく、機械的に動かしている。なので例外的に音MADについて触れたような記事を取り上げられないが、でもある程度の網羅性は担保できていると思う。

現在のリストは以下の通りで、既に更新されていないものも含めて161件ものブログが開設されている。そのうちの116件は note.com のアカウントで、昨今のトレンドを感じられる。次点ははてなブログで、40件ほど。

これらのリストから1時間に1回ほどデータを収集するようになっていて、新しい記事があればおそらく新着記事に追加される。うまく動いていないようだったらぜひとも教えてください。

また、このリストから漏れてしまったブログについても随時募集中で、僕に直接伝えるか、GitHubに知見があるのであればリポジトリにPRを投げてもらうか、このフォームからリクエストを投げることができる。ぜひとも協力していただきたいです。逆にリストから削除してほしい時は、それもまた僕に直接伝えてください。もうしわけない。

既にRSSリーダーを利用している方については、上に張ったリストを追加してもらうか、このアンテナ自体がRSSのフィードを提供しているので、それを読み込んでもらうと良いと思う。ただちょっと巨大かも。僕は↓このフィードを使った運用をしていないので、もし巨大すぎて不都合があるようだったらそれについて教えてほしいかも。

なぜこれを作るのか

一番大きな理由は自分がよく見ているコンテンツを作っている人がどんな文章を書いているのか？というのを探るためだけど、もうちょっと書いてみる。

まず音MAD作者の方々が書くブログは面白い。恐らく音MADの制作の過程で生まれた所感の方向性*1とブログみたいなものとの相性が良いという事もあるだろうが、別に音MADに関連したものではなくとも面白く、そのセンスはさすが創作に根を詰めているだけあるなと思ったりもする。これを逃さず閲覧できるアンテナを作成したかった。

また、これは集合知としても役立つ気がしている。これは「音MADに関する技術的な記事を逃さないようになる」というだけではなく、ただ普通に関係のないことについて書かれた文章についても同じように捉えられると思っている。ブログは後世に伝える手段としてはかなり優れているように思う。現に数年前に更新したっきりでそれ以来全く更新のない音MAD系のブログも存在しており、ただその記事は今でも問題なく閲覧できたりする。日記ってすごいかもしれん - 名有りさんの日記の下の方に書いたことと似たような気持ちだが、みんなが文章を書き続けるとそれが界隈自体のアーカイブとして機能し始めると思う。そのための、草の根としてのアンテナでもありたい。

よろしくお願いします → otomad-feed

*1:ネタ/技術/思考

osmosfeedを使って自分のためのアンテナ(RSSリーダー)を作成する

github.com

  • yamlファイルにRSSフィードを書き溜めておく
  • 新着記事一覧のhtmlを静的ファイルとして作成する
  • GitHub Pages配下に設置する
  • これを定期的に動くGitHub Actions上で実行する

そうすることでRSSフィードのためのアンテナを用意することができるようになる。というのがosmosfeedの特徴。上述した環境をかんたんに用意するためのテンプレートも存在しており、テンプレートを使用したリポジトリを作成した後、yamlを埋めるだけでosmosfeedを使えるようになる。既存のRSS追うやつと違って、これはGitHub上にyamlで管理するだけなので大変にお手軽で、移植性もかなり高い。なにより、GitHub Actionsと連携するのがとても賢いなと思い、自分もこれに従ってみることにした。

これまでははてなブログの購読リストのみを使用していたが、性質上はてなブログしか集めることができないために他種の媒体を追うのが困難になっていた。今回によってRSSフィードを配信している媒体であればなんでも追えるようになったのだと思う。

運用してすぐに「更新日時をかなり未来に置いておくことで、特定の記事を記事順の先頭に置くハック」の存在を思い出す。アンテナの先頭もそういった記事で埋まってしまう。これらの記事は意味合い的には新着記事ではなく、アンテナ運用の上ではただ邪魔なだけなので、「未来の記事はアンテナに含めない」のような対応が必要になった*1。ので、PRを投げた。投げてから反映されるまでの間は自分のネームスペース上にosmosfeedをpublishし、それを利用するように変更していた。昨日くらいにマージ、最新版がpublishされたようなのでそちらを利用するように変更した。

また、osmosfeedが吐き出すhtmlは事前に用意されたテンプレートを使用しているのだが、これを自分で用意することも可能。今回、記事のサムネイルを記事一覧右側に設置したかったので、そのように対応した。ただ、サムネを取得する方法があまり良いとは言えない方法だった*2ので、どうするのが妥当か？を聞いてみたところ (osmoscraft/osmosfeed discussion#75) 、現在取り組まれているv2にサムネイル取得のためのコードが存在し(または用意中で)、これをバックポートすることで対応できるのではないか？という話を頂いた。今後に期待すると良さそう。

ここで書いたそれぞれの対応は、osmosfeedの性質によって実現できる対応だと思った。体験がかなり良い。

もしこれを見ているあなたも試したくなったのであれば、以下のページを参考にするか、手っ取り早くは先程挙げたテンプレートからリポジトリを作成すればよい。

paiza.hatenablog.com

GitHub Pagesは性質上パブリックなものなので、生成結果のアンテナもパブリックなものとして公開される。これを利用することで、「特定の界隈をまとめたアンテナをその界隈に対して共有することもできる」と考えた。これは共有知としてかなり有用なのではないか。GitHubで管理されている性質上、誰でもフォークでき、もし追加すべきブログがあるのであればそれを対象に加えることもできるだろう*3。そういった記事をこれから別記事として書く。

*1:もうすこし賢い対応方法はあるだろうが、この対応で自分の要望は解決されるので問題なし

*2:そもそもRSSフィードとしてサムネを用意する方法がめちゃくちゃたくさんあって簡単に対応できない

*3:しかしこれはgitに対する知見が前提になってしまう