【日記】最近読んだ本の感想【2024/05/31】

幸福な王子/柘榴の家 童話集第一遍が「幸福な王子」、第二遍が「柘榴の家」で、今回は両方が一冊に纏まっているものを読んだ。幻想文学、というジャンルを(おそらくちゃんと意識しては)初めて読んで、あらゆるものに自我がある独特な世界観に圧倒されつつも楽しく読めたけど、よくよく考えたら「サルカニ合戦」とかも臼が喋ってるのに子供の頃は深く考えないで読んでたよなと思った。童話で花が喋ろうが打ち上げ花火が喋ろうが、読み聞かせてもらう子供にとっては問題ないのかもしれない。 ジャイロスコープ 短編集。あとがき的なインタビューで先生本人も仰ってるけど、読者の考える「伊坂さんらしさ」は若干薄い短編が多め(特に「ギア」とか)。「浜田少年ホントスカ」と「1人には無理がある」が特に好き。 特に「浜田少年ホントスカ」の、 「殺し屋なんていう便利な職業は、フィクションの中にしかいないですからね」 これを読んだ最初は、こういうメタ的に刺してくる台詞を登場人物に言わせるの好きだなー、とだけ思ってたけど、読み返してみるとこれってこっちの台詞に意識を持っていかせることで、少し前の浜田少年の「プロの殺し屋に頼んだ方がいい」という若干違和感のある台詞をかすませてるのがすごい。他にも好きな言い回しは山のようにあったけど、あげるとキリがないので割愛する。 夜の国のクーパー 伊坂さん祭り。 なんとなく、「私」にとってこの国はミニチュアの世界みたいな物なんじゃないかなぁと確たる証拠もなく漠然と考えていたので、まさか本当にそうだとは思わず読み進めていてびっくりした。 冠人に対する印象が文字通り180度ひっくり返ったけれど、「この親にしてこの子あり」という観点で凄まじく納得出来たのがよかった。物語上、一番明確な目的を持って動いていた複眼隊長の目的が、実は冒頭で既に達成されてました、という読み終わった後にわかるあっけなさも好き。殺し屋シリーズのような転がっていく楽しさ、というよりは、じわじわと謎が深まっていく面白さ、という感じだった。 二重人格 めちゃくちゃ難しくて自分の読解力を疑いそうになった。勢いで読み切った後に見た巻末解説に「ドエトスフキーの作品の中でも評価がわかれる」「冗長な書き方が~」的な事が書いてあってちょっと安心した。個人的には、タイトルとあらすじを見て、自分の理想の姿の他人格が内面に生まれて支配されてしまう話かなと思ってたんだけど全然違くて、自分が上手くいかない理由を突然現れた理想の自分が邪魔してくるからだと思い込んで破滅(自滅)するという話でちょっと意外だった。そもそも「二重人格」っていうタイトル自体が、本来はロシア語でのドッペルゲンガー的な単語の意訳らしいと知って納得した。他のドエトフスキー作品を何冊か読んでからまた読み返したい。 「後回し」にしない技術 kindle unlimitedで読んで良かったので再読。ドエトフスキーの小説読んでみようと思ったのもこの本から。「一冊読もう、ではなく一行読もう」とか、「ウォーミングアップに時間をかけるな」とか、後回し癖のある人(私)にとっては切れ味の鋭い言葉が多い。この本とか、「勉強が面白くなる瞬間」はモチベーションダダ下がっている時に読みたい。

<span title='2024-06-02 22:21:53 +0900 +0900'>6月 2, 2024</span>

【git】カウントしたコミットファイルの総文字数を自動でコミットメッセージに追加する

趣味で書いている小説をgitで管理していて、進捗把握のためにコミットメッセージにその日1日書いた総文字数を入れ込んでいます。 こんな感じで。 以前までは、SF作家である藤井太洋先生自身が公開してくださっている拡張機能: novel-writerのステータスバー表示で文字数を把握し、手動でコミットメッセージを書いていました。 ただ、この方法にはいくつかの(個人的には解決したい)問題があり、 日付が回ると文字数がリセットされるので、うっかりしてると差分の文字数がわからなくなる 特定のファイルや変更は含みたくない場合がある(翌日への自分のメモなど) コミットメッセージへの手打ちを辞めたい 上記二つに関しては、私が拡張機能で出来ることを把握しきれていないだけ or 今後改善される可能性はありますが、どうせならコミット時に自動でコミットメッセージ入力できたら楽だよなぁという動機があったので、ちょっと調べてスクリプトを組んでみました。 やったこと 下記のスクリプトを.git/hooks/commit-msgとして設定します。 #!/bin/bash # ステージングエリアに追加されたファイルの差分を取得し、文字数をカウントする関数 # .git/hooksに移動させて、`chmod +x .git/hooks/commit-msg`を実行することでコミット時にhookされる get_character_count() { # ステージングエリアに追加されたファイルの差分を取得 diff_output=$(git diff --cached) # 追加された行の文字数を合計する added_characters=$(echo "$diff_output" | grep '^+' | sed 's/^+//g' | wc -m) # 削除された行の文字数を合計する deleted_characters=$(echo "$diff_output" | grep '^-' | sed 's/^-//g' | wc -m) # 追加された文字数と削除された文字数の合計を計算する total_characters=$((added_characters - deleted_characters)) # 結果を出力 echo "$total_characters" } # コミットメッセージに追加 character_count=$(get_character_count) echo "📝 $character_count 文字" >> "$1" スクリプト内でやっている事はかなりシンプルで、git diffの結果である追加行(+で始まるもの)と削除行(-で始まるもの)の文字数をそれぞれカウントして差し引いて、総文字数を計算しているだけです。...

<span title='2024-05-06 14:51:45 +0900 +0900'>5月 6, 2024</span>

【github】mainではないブランチから派生したブランチでPRを出すとき

ベースブランチってどこ向け? タイトルの通り、main(default)ではないブランチから派生したブランチのPRを出すのに謎の抵抗感があったのですが、githubくんがかなりよしなにしてくれることに気がついたのでその挙動を備忘録として書いておきます。 (知っている人にとってはめちゃくちゃ当たり前体操な内容だと思います) TL;DR main(default)ブランチから切ったブランチAから更に切ったブランチA2のPRを出すときは、難しいこと考えずにブランチA向けにPR出すのが良き。 どういうこと? たとえば、チームメンバーがmainから派生したbranchAで作業していたとします。 branchAに乗っている機能が前提の作業をするために、branchAからbranchA2を切りました。 branchA2の作業が終わりPRを出したいのですが、branchAはまだ細かい部分のPR中でmainにはマージされていません。 さて、このbranchA2のPRの向き先はmainかbranchAか、という話です。 今こうして自分で書いていても「いやbranchA向けだろ……」と思うのですが(main向けにPRを出すと、branchAのコミットもPRに乗ってしまうためかなり見づらいことになるので)、 「branchA向けに出したとして、branchAがmainにマージされたらbranchA向けのPRはどういう扱いになるんだ……? mainでrebase or mergeしてmain向けに直さないといけないのか?」と漠然と面倒臭がっていました。今までは。 この「PRのbaseとなっているブランチがマージされていった後にデフォルトのブランチ向けのPRに直す」作業、githubが勝手にやってくれます。 実例 (ほとんどmainにしかpushしていないprivateリポジトリで実験) test-branch-Aというブランチををmainから切ってPRを出したとします。 その後、test-branch-Aから切ったtest-branch-A2のPRをtest-branch-A向けに出します。 (PR作成時にbaseが選べるし、作成した後もEDITボタンから変更できます) この状態でtest-branch-AのPRがマージされると、 Base automatically changed from test-branch-A to mainというログが残って、test-branch-A2のPRがmain向けに自動修正されます。 めちゃくちゃ便利だ……。もっと早く気が付きたかった。 PR出した後は、ベースとなるブランチ自体に先んじてマージしちゃうか、そっちの作業を待ってからmainにマージするか、どちらにせよベースとなるブランチで作業している方とのコミュニケーションは必要ですが、とりあえず派生元にPR出しておけばあんまり困ることは(今のところの経験上)ないです。 派生PR、もう怖くない!な備忘録でした。

<span title='2024-03-08 18:16:03 +0900 +0900'>3月 8, 2024</span>

日記(~2023/07)

(2023/06/17) We updated our RSA SSH host key - Github 私用のPCで久々にpushしようとして警告出て、ちゃんと公式情報見た上で対応できたけど、3/24以降仕事以外のコードをpushしてなかったことが地味にショックでした。 (2023/06/24) 広くなったベランダで育て始めたペパーミント、苗買ってきた時よりなんか葉っぱ過疎ってないか……?と思って見てみたら馬鹿でかい青虫がついててリアルタイムでもりもり葉っぱ食べられてました。 (2023/06/26) 「AI分析でわかった トップ5%社員の習慣」を読んで、上位5%社員のXX%が〜っていうのに関しては、サンプリング数少ないから95%の人たちと違って一概には言えないんじゃないの?(この本作るために良いところだけピックアップするときにだいぶバイアスかかってそう)とは思ったけど、これ実践してみようかなと思うところはいくつかあったので読んでよかったです。 読んですぐに(内容は本とは全然関係ない)スーパーミニマムな社内LTをしたんですが、「資料作りに時間をかけない」と割り切って最初からNotionにまとめることで割と短い時間で形に出来たのが個人的にいい学びでした。 (2023/06/27) JavaScriptの入れ子の関数とクロージャ、シンプルに知らなかったです。使い過ぎはネストが辛くなりそうなので良くないと思う(というかユースケース自体あんまり思いつかない)けど、外側の関数のスコープを持ってくれる性質を利用して、コード理解の一助のためにロジックの一部を別関数に切り出す時なんかには有効そうだなと思いました。

<span title='2023-06-27 17:14:07 +0900 +0900'>6月 27, 2023</span>

日記(~2023/06)

(純然たる日記の寄せ集めです) (2023/04/01) ながら聞き用にbocoのPEACE SS-1買いました。 仕事中に音楽とかラジオとか聴きたい派なんですが、ずっとイヤホンをしていると耳が痛いし、中耳炎になって危ないってよく聞くし……と思って数年前にShokz(旧Aftershokz)の骨伝導イヤホンを買ったのが骨伝導との出会いでした。 買った当時は気にならなかったんですが、しばらく経ってちょっといい椅子を導入してヘッドレストにクッションをつけたら首周りの部分が干渉するようになってしまって、ちょっと不便だな〜と思っていたところにPEACE SS-1くんと出会いました。実に快適です。ありがとうboco。 (耳を挟むように押し込むと音量上げたりできるらしいですが、なんか直感的に出来なくてコツが必要&挟み込み部分の寿命縮めそうなので本体操作は諦めてます) (2023/06/16) 最近調べ物によくChatGPTを使っていて、便利だなぁと思う反面このままいくと原神のスメール編で学者たちに起きていたこと(聞けばなんでも出してくれるアーカーシャ端末があるから、誰も一次情報に触れようとしなくなる)が自分の中で起こりそうだなぁと漠然と考えたりしてました。 利便性の恩恵を受けつつ、自分で調べ物をする感覚は忘れないように上手く間をとっていきたいです。 (2023/06/17) 応用情報がCBT方式になるのを密かに待っているんですが(基本情報はそれで去年受けた)、長文読解とか記述方式の回答とかの相性の問題で中々導入されないんじゃないか説が結構濃厚な感じがするので、観念して秋季に受けようかなと考え中です。 予定があれば早起きできることを証明したいと思います。

<span title='2023-06-17 15:11:15 +0900 +0900'>6月 17, 2023</span>

Flutter周りで知ったことまとめ

最近個人でFlutterを触っていて楽しいので色々調べていて、その時知ったことや勉強会で聞かせてもらった話などのまとめ。 (「こんな便利なものあるんだ〜」と思っても一回ブラウザのタブを開いちゃうと忘れがちなので、自分用のリンク集として) Material Design3 https://m3.material.io/ Material 3 is the latest version of Google’s open-source design system. Design and build beautiful, usable products with Material 3. (拙訳) Material 3 は、Google のオープンソース デザイン システムの最新バージョンです。 Material 3 を使用して、美しく使いやすい製品を設計および構築します。 Googleのデザイナーと開発者によって構築・サポートされている、オープンソースなデザインシステム。 Android, Flutter, そしてWeb向けのUXガイダンス・UIコンポーネントの実装が含まれている。 PrimaryColorを選択するだけでいい感じに各色設定してくれたりするので便利。 (絶対それ以外の便利な使い方もある) // ThemeDataで指定する ThemeData( useMaterial3: true, colorSchemeSeed: Colors.XXX, // 好きな色 ) これだけでデフォルトの「テストです!!!」と言わんばかりの真っ青なヘッダが変わるのでちょっと「おぉ……」ってなる。 DartPad https://dartpad.dev/ Dartの構文を気軽に試せる。便利。 ちなみに、新しいバージョンを試したいときは下のstable channelを押して切り替える。 Serverpod https://serverpod.dev/ reverpodならぬServerPod。 Flutterコミュニティ向けに、Dartで書かれたOSSのアプリサーバ。 isar https://isar.dev/ hiveのv2系としてのプロジェクトらしい? Flutterで使うデータベース。詳しくはこれから調べる。

<span title='2023-03-11 20:43:27 +0900 +0900'>3月 11, 2023</span>

Wakatime導入してみた

個人開発でアプリ出したいなぁと思っていて(今はFlutterくんと仲良くなるためにチュートリアルやってるだけですが)、毎日少しずつでもコーディングするモチベーションが欲しい……!と思ってwakatimeを導入しました。 wakatimeは、VSCodeなどのエディタと連携して、実際にコーディングしている時間を計測してくれるサービスです。 ちょうど最近登録したLAPRAS(GithubやTwitterなどからクローリングした情報をまとめてポートフォリオにしてくれるサービス)のbeta版機能として連携できるようになっていて知りました。 個人で使っているPCのVSCodeにだけ導入しておけば、完全に個人でコーディングしている時間を集計できるのが良さげです。 インストール&セットアップ サイトからgithubでサインアップ settingsにあるSecret API Keyをコピーしておく VSCodeの拡張機能でwakatimeをインストール インストールが終わるとAPIKeyの入力を求められるのでペースト これだけです。ダッシュボードは割とリアルタイムに反映されるので、少しコードを触って見に行くと集計されてます。 どのリポジトリを触ったか、どの言語を触ったか、更にはデバッグしていた時間なども記録されてました。 profileに反映されるのは少し時間がかかりますが、少しすると表示され始めます: (githubのProfileにバッジも置いてみた) 結論: 良さそう 最初は「ブログでもzennの記事書くときでも結構だらだらmdファイル触るし、触った言語比率とかそういうのpublicになるとちょっと恥ずかしいな〜」みたいな謎のプライド(?)で導入を悩んでいたんですが、公表するデータは制御できるし、最初から気軽な気持ちで導入しておけばよかったなと思いました。 サイト内でコーディング時間のゴールも設定できる&profileの草形式で自分の頑張りが見られるので、モチベーションアップに繋がりそうです。 (個人で触るコードのみの環境なのでサクッと導入しましたが、仕事上の守秘義務のあるコードを触る環境なんかに入れる時はセキュリティ的にちゃんと色々調べないといけないと思います。)

<span title='2023-02-28 23:40:16 +0900 +0900'>2月 28, 2023</span>