日記

趣味で書いている小説を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の結果である追加行(+で始まるもの)と削除行(-で始まるもの)の文字数をそれぞれカウントして差し引いて、総文字数を計算しているだけです。...

ベースブランチってどこ向け？ タイトルの通り、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、もう怖くない！な備忘録でした。

(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の入れ子の関数とクロージャ、シンプルに知らなかったです。使い過ぎはネストが辛くなりそうなので良くないと思う（というかユースケース自体あんまり思いつかない）けど、外側の関数のスコープを持ってくれる性質を利用して、コード理解の一助のためにロジックの一部を別関数に切り出す時なんかには有効そうだなと思いました。

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

最近個人で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で使うデータベース。詳しくはこれから調べる。

個人開発でアプリ出したいなぁと思っていて（今は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の草形式で自分の頑張りが見られるので、モチベーションアップに繋がりそうです。 (個人で触るコードのみの環境なのでサクッと導入しましたが、仕事上の守秘義務のあるコードを触る環境なんかに入れる時はセキュリティ的にちゃんと色々調べないといけないと思います。)