方々で暗号解読はよいと言っているけれど、記事にしてなかったっぽいので書いておく。
これで暗号のなんたるかを知った。いわゆる「技術書」ではないけれど、暗号の入門書としてとてもおすすめ。
古今東西の暗号にまつわるドキュメンタリーのテキスト化作品で、性質上強烈なインシデントの実例も知れる。
読んでいくと暗号は運用が大事であることが身に染みると思う。
20年以上前の本だけれど、現在との差分は楕円曲線暗号が実用されるようになったくらいだろう。未来の量子暗号についても記述がある。2020年代にリメイクや追記がされるとしたら、ブロックチェーンは取り上げれそうな気がする。
とにかくおすすめ。落ちはない。
nippper、読んでいてるとプラモデルを組みたくなるいいサイト。
ではなく、工具としてのニッパーについて。
カジュアルなプラモデラーにとって一番重要な工具はニッパーだ。昨今のキャラクタープラモデルはニッパーでパーツをゲートからカットして組み立てるだけでかっこ良く仕上がる。他は要らないと言ってもよい。
そんなニッパーはそこそこの本数が手元にある。ITエンジニアにとってのキーボードのようなものだろうと思う。最近少し使い勝手を再確認したのでまとめておく。
違う。
でもない。
である。
実によい。
自分はなぜか突然歌いだすミュージカル映画はそんなに好きではなく、必然的にインド映画も食わず嫌いだったのだけれど、バーフバリを観て物語の中に組み込まれた歌と踊りにはいたく感動してしまった。そんなバーフバリの監督の作品なら面白いだろうとＲＲＲを観に行ったら期待に1000%位で応えてくれる最高作品だった。
最高です。アクションエンタメ映画が好きなら必見です。
つい
ナートゥ、ナトゥナトゥナトゥナトゥナートゥ
— 光電/7474 (@koudenpa) 2022年10月28日
とつぶやいてしまう。
ヘビーループしてしまう。
すごい力のある作品をありがとう。
感想は「最高」としか言ってないな。まぁ最高なのだから仕方ない。今の時代にとっていろんな要素がある作品ではあるけれど、圧倒的なパワーのある作品に野暮な言葉は不要かなと思う。
普段この時間（金曜日の夕方）は仕事の時間に多少ITに関するブログ記事を書いているのだけれど、今日はさぼって（休憩にして）ＲＲＲについて書いてしまった。
2022年10月22日、ついにダイの大冒険のアニメが大団円を迎える。感無量すぎたのでFigmaダイを改造して竜魔人にしてしまった。
元々模型はキャラクタープラモのパチ組＋部分塗装位なので手馴れてはいないけれど、それっぽくなったので満足だ。
竜の紋章は蛍光塗料を使ってみた。最終決戦でギラギラと輝く紋章と瞳があまりにも印象的だった。それが改造動機でもある。
もはや言葉は要らない。
ダイの剣とともに最終回を迎えたいと思う。
晴れていたのでダイの剣を撮った。
— 光電/7474 (@koudenpa) 2022年10月4日
やはり青空が背景でないとね！
ダイの大冒険アニメも後三話か。。。 pic.twitter.com/jIxUfmbo6m
Webアプリケーションエンジニアとして仕事をしていると、まぁまぁ隙間時間がある。
など様々な場面で生まれる。
これらの隙間時間に何をしている傾向があるか少し振り返ってみた。
どのくらいの隙間時間か？ でそれなりに使い分けをしているつもりだったけれど、改めて振り返ってみるとそんなことはなかった。ほんとにちょっとした時間なのか、ある程度まとまった隙間なのか、位の分け方だった。
自分の仕事スタイルについての解像度が少し上がってお得だった。
調子がいいときはこうした形で隙間時間を有効活用できていて、悪いときはぼんやりしてしまっていることが多い。これは仕方ない。調子が悪いときの隙間時間は諦めてないものと考えている。
どうやって調子がいい状態を保てばよいのか？ これだ！ という答えはまぁない。あれば実践してる。が現実は厳しい。
隙間時間はチリツモなので調子をよく保って時間当たりの成果を増やしていきたいもんです。
なお、実際にはTwitterのタイムラインを見ていることも多々ある様子。
葬送のフリーレン人気投票 | 少年サンデー の投票が締め切られましたね。皆さん誰に何票投票しましたか？ 僕はヒンメルに1万数十票の非ガチ勢です。
さて、この人気投票はツイッターに特定のハッシュタグをつけてツイートという形で行われたので、第三者も投票状況を見ることができる。自分はこれを集計して大喜びしていた。
上記の記事を書いていた時点では投票状況の取得を手動更新をしていたのだけれど、どう考えても何日かしたら飽きて放置するので自動更新したかった。
GitHub Pages向けのコンテンツ取得なのでGitHub Actionsで更新すればよかろう、とGitHub Actionsのscheduleで日に二回ほど最新のデータの取得、リポジトリへのPushとPagesへのデプロイをするワークフローを実行するようにしてみた。
これを1つのワークフローでやってしまった。
GitHub Actions既定の GITHUB_TOKEN でリポジトリにPushしても、そのPush等を条件としたワークフローは動作しない（不測の無限ループを回避するのが主な理由であるっぽい）。
なので、Push契機で他のワークフローを起動してデプロイするようなことは別途トークンを用意するなどの手間があるのだけれど、同一のワークフロー内で「続けてGitHub Pagesへデプロイ」してしまえばワークフロー内で更新された状態をデプロイできる。
（外部に依存する）データの収集、リポジトリへPush、Pagesへデプロイ、これを1つのワークフローで済ましてしまう省力構成はまぁまぁ実用的なのではないかと思った。
ので記事にして備忘した次第。
投票結果が楽しみだ。それまでは第三者の集計を眺めて待ちたい。
