377 Times Around the Moon

2025/2/26~2026/3/25

1ヶ月の取り組み
1. PC/スマホ環境整備
考えのまとめ
OSS開発:MuseScore　学習まとめ
来月の方針

1ヶ月の取り組み

仕事か、睡眠か、MuseScoreのソースコードを読んだりC++のコードを書くかばかりだった。
あとTwitter
休日の出費が食費だけ…。
また極端な生活をしてしまったので、来月は少しはおでかけしたい。

PC/スマホ環境整備

pixel4a データ移行（写真動画など）
- 今年初めに「死へのアップデート」を喰らってからこの端末もそろそろ限界
- pixel9a 早く欲しい
Windows の OneDrive を整理
- 連鎖してPCのドキュメント類も整理
手持ちPCのSSD耐久性が急に気になる
- GSmartControl でSSD耐久性を調べる
- まだ10％程度の耐久性(TBW)使用済みらしい
このブログの設定調整
- デザインを変更。技術的な記事を書きやすいデザインにした
- プログラミング記事を書けるように、Highlighting Code Blockプラグインを導入

考えのまとめ

できる人たちは情報を掴むのが早いし先を走っている印象
- 情報の上流側にいるか、下流側にいるかの違いとはなにか？
- 自分が生産者側の立場でいられるかどうかが大きいかもしれない
- 負担や責任を負っている人のほうが質の良い情報・人に巡り会っている
- →仕事のスキルアップを考えるようになる
専門性を磨きたい気持ちが強くなる
- 自分の魅力を上げたい（特に良いパートナーに出会いたい）となると、やはり職業や専門性が要だと考えるようになる
生成AIは部下として扱う
- ユーザーが良い指示を出せるか？　責任を押しつけていないか？
- 「体育会系はAIを活用するのが上手」説をTwitterで見かけたが私も納得した。
  - 司令塔としてチームの目標達成に向けてメンバーを率いるのと同じ
  - チームプレイのスポーツと同じく、複数のプレイヤーに同時に指示を与えて動かし、全体のバランスを見ながら調整し、成果に繋げる
生成AIの活用
- AIはネットに転がっている既存の知見を焼き増ししているだけだとしても、そういった基本的な情報をユーザーの説明する具体的な状況に応じてバランス良く適用して見解を出力できる、というのは大きな価値がある。
- 役立つ情報というのはたいていありふれていて、使い古されていて、つまらないものばかりなので。当たり前のことを当たり前にさらっとできる人がいちばん強い。
私が憧れるタイプ：個人事業主的な生き方ができる人
- 優秀さ、賢さを重視していたつもりだが、これは親の価値観を引き継いでいただけだった
人との距離感について（特に対女性、マイノリティとの関わり方）
- 女性だって好きな男性以外には素っ気ないのがデフォルトなのだから、こちらも同じで良くない？　パートナーを大切にできれば十分。
- 距離が遠い人の愚痴や悩みを真剣に聞かない。他人を感情のゴミ箱扱いする人から遠ざかる。こちらは支援職でもないので。
- 自分に関係のない社会問題にも首を突っ込まない。自分や家族の幸せを優先させたい。
- 仕事をして納税して勉強をしているなら、それだけで社会貢献は十分。私的な場でくらい、自分の好きな価値観や倫理観を持っても良いじゃんと考えるようになった。言動をコントロールできるならそれでよい。（無理してマイノリティに配慮した価値観を持たなくてもいい）
- この割り切りで、他人がマイノリティ軽視の言動を取っていても、まあ仕方ないよね、と怒らずにいられるようになった。
「私に相応しい居場所」を考えるようになる。環境は大事。
- 過去に飲み込まれたトラブルは、居場所の選択を間違えたからではないか。
誰についていくか？
- 社内政治もそうだが、勝ち馬に乗ろうと考えるより、好きな人を選んだほうが後悔はなさそう
- 価値観が自分と合うかで選びたい。
- 私をリードしたがる人間で、私から見て魅力に感じる人はほぼいない。
協調性も必要だが、チームの成果に繋がらない自分勝手なカスのために協調性を発揮しない。
同世代で趣味に打ち込む人をみると、なぜかイライラするようになってきた
- 私が結婚したり、仕事をもっと頑張らなければ、と考えるようになったからかも
- 趣味に一生を捧げるのも悪くないけど、私としてはその先の展望が見えなくなった。そこで友達ができてもいずれ散り散りになる将来が見える。「友達」という関係性の限界を知ってしまっている。

OSS開発:MuseScore　学習まとめ

やったこと

Musescoreの .cppファイル、.hファイルをひたすら読む。
- 見慣れない構文、頻出の英単語が出てきたら調べる
休日は1日1問、コーディング問題を解く。
- C++コーディング演習（第1問～第8問）
- C++コーディング演習（第9問）

キーワード

とにかくコードを読んでいて出てきた疑問を片っ端から調べていたので、体系もなにもない。しばらくコードを読みまくって現場感覚を掴んでからC++の教本を読もうと考えている。

名前空間
リソースファイル
スマートポインタ
参照カウント
依存性注入 (DI: Dependency Injection)
IoCコンテナ
A::B
アロー演算子 (->)
ストリーム入出力
挿入演算子 (<<)
コンストラクタ
デストラクタ (~MyClass())
プリプロセッサ命令
純粋仮想関数
ポリモーフィズム
オーバーライド
前方宣言
三項演算子 ( A ? B : C )
static const bool A = B;
ラムダ式　[キャプチャ](引数リスト) -> 戻り値の型 {処理};
オーバーロード（多重定義）
- 関数のオーバーロード解決
ラッパー
auto (型推論)
シングルトン
抽象クラス
インターフェース
範囲ベースforループ　for (const auto& 変数 : コンテナ){ }
メンバ初期化リスト
- コンストラクタの:の後に書いて、オブジェクトのメンバ変数を効率的に初期化する
enum（列挙型）
ヘルパー関数
デバッグ用マクロ
assert
std::function
std::bind
コールバック関数
ハンドラー
ディスパッチャー
STLコンテナ
find(), end()
dynamic_cast
ランタイム型情報
引数指定 &(参照), *(ポインタ)
参照とエイリアス (int& a = b)
二重ポインタ (a**)
[[fallthrough]]
スタック変数
ヒープ変数
std::set　重複を許さない集合
ret　エラーハンドリング
- ret型：編集・ファイル処理など失敗する可能性がある関数に向いている
デバッグ
- ステップオーバー：関数の中に入らず、次の行に進む
- ステップイン：関数の中に入る
- ステップアウト：今の関数を最後まで実行して、関数の外に出る
ウォッチ式：式を追加して値の変化をみれる
コールスタック：関数の呼び出し履歴を管理
シングルスレッド、マルチスレッド
std::thread
テンプレート関数
inline
演算子オーバーロード
スコープ管理{ }
mutable :constメンバ変数でも変更可
コールバック関数：関数の引数として渡され、後から実行される関数
MIME：データの種類を識別するフォーマット(Multipurpose Internet Mail Extensions)
ユニフォーム初期化

覚え書き

EngravingItem クラスの定義を追う
- operator = の削除→コピー代入を禁止。つまり参照やポインタで扱う設計にした
- 親要素の取得・子要素をリストで取得→親子のツリー構造がある
要素選択をUI処理とデータ処理で別々に書く
- →UI側の選択の仕様を変更してもデータが壊れないようにする
変数名の接頭辞 o ：original,old（元の、古い）要素？
命名ルール m_ :クラスのメンバ変数を表す
型の命名に出てくる _t：typeの略、特定用途のための型
- 例：　staff_idx_t: staff_idxを表す型　型をみればその変数の役割がすぐに分かる
矩形の描画にfor文が出てくるのはなぜか？　1回ではだめなのか
- 要素の複数選択で、連続していない範囲を選択する場合を考慮
アロー演算子(->)とドット演算子(.)
- -> はポインタ型のオブジェクトに対してメンバを参照する
- . はオブジェクトに対してメンバを参照する
- 例：a->b().c() :aはポインタ、a->b() はポインタのメンバ関数呼び出し、bの戻り値はオブジェクトなのでこのような表記になる
bool function() const:
- この位置のconstは、「このメソッドがメンバ変数を変更しないことを保証する」意味
this: いまこのメソッドを実行しているインスタンス自身のアドレス
- hoge.a->b(hoge)　hoge.a->b(this) は違う。ここでthisはhogeを指してはいない
各メソッドの終盤に出てくる apply()
- 編集処理の実行でなく、変更の「確定・通知」が本当の役割らしい
classA::func(){…}の中身で扱える変数分類
- メンバ変数：classの定義にあるもの、privateエリアも含む
  - thisを使うと、自身のインスタンスのメンバ変数を参照できる
- ローカル変数：func()の中で宣言したもの
- 引数
AddBoxes() （譜面にボックスを追加するメソッド）の疑問
- 引数には（ボックスを追加すべき）位置の情報を含まないのに、内部処理だけで挿入位置を特定している。
- どうもメソッド内部で、メンバ変数などを参照しながら挿入位置を決定しているらしい。
- 直感的には違和感があった。→関数の責務が偏っているかも？　という指摘も
- ユーザーの操作感では「この小節のあとに1小節追加」といった処理を求めるから、引数には「ヒント：選択地点の直後に挿入」の情報を与えるだけでOKらしい
NotationInteractionクラスと engravingクラスの棲み分け
- NotationInteraction ユーザーの操作を受け取り、適切な処理を指示する（＝UIロジック層）
- engraving::Score など実際に記譜データを変更する（＝モデル・ドメイン層）
std::shared_ptr<子クラス> a; に対して、<親クラス>Ptr func(){ return a; } は可能
- つまり、子クラスのポインタ a を親クラスのポインタとして返すことは許される。
- スマートポインタに対して、暗黙のアップキャスト（親クラスへの変換）を許しているから.
VSCodeでC++を動かしたい：まずビルド（Shift+Ctrl+B）→デバッグ(F5)

環境設定、整備

VSCodeでデバッグしたい→MinGWインストール、環境設定
- where gdbに詰まってデバッグエラーが出る。ビルドにつかうファイルのパスが正しく読み込めて折らず苦戦
- windowsの「システム環境変数」と「ユーザー環境変数」は別物
- powershellでは”where gdb“でも反応がないが、”get-command gdb“だとパスを確認できる

周辺知識

BSPツリー（バイナリ空間分割）
計算量
- 探索、ソート、データ構造選択
レジスタ　（VSCodeデバッガの変数 (Registers)から）
- CPU:一般目的レジスタ
- Segs：セグメントレジスタ
- FPU：浮動小数点演算レジスタ
- SSE:SIMD演算レジスタ（高速ベクトル演算など
- OtherRegisters:フラグレジスタ、制御レジスタなど
（関係ないけど）ハードウェア、自作PCにも興味を持つ

開発にかかわる英単語、慣用表現

nudge :微調整
spatium :楽譜のスペース・間隔（ラテン語由来）
raster :グリッド、マス目
accidental type :臨時記号の種類
extract :抜き出す
staff :五線
renderer :描画するもの
duration :(音符の)長さ
segment :1つの拍、休符、記号の配置単位
stem :音符の符幹
ledger :加線
numeric :数値の
rect,rectangle :矩形、長方形
intersect :重なる
coord :coordinateの略、座標
constrain :制限、拘束
outgoing :外に出る、発信
exec :execute,実行する
point2page：ある座標(point)を楽譜ページ座標(page)に変換
offset :ずれ、位置の補正、相対距離、移動量
entry :入力、データの一要素
precede :～に先行する
adjacent :隣り合う
flip :ひっくり返す、反転させる
compute :論理的に導く
ellipse :楕円
brush :ブラシ（塗りつぶし） cf. pen:輪郭を描く、線
explicit :明示的な
trail :末尾に続くもの
tuplet :連符
snap :ピタッと揃える
system :組段（同時に演奏される全ての譜表の集まり）
MMRest (Multi-measure Rest)：長休符
clef :音部記号
keysig :調号（♯、♭の数）
timesig :拍子記号
fraction :分数、時間位置や長さを分数で表す型
vertical :垂直の、縦方向の
extract :抽出する
brace :波括弧
parenthesis (複:parentheses) :丸括弧
numerator :分子
denominator :分母
cue :参考用の音符（他パートの楽譜の一部小さく表示したもの）
grip :オブジェクトをつかんで移動・編集できるつまみ

教訓

コードを読みながら意識したポイント
- ファイル名、変数名から中身の抽象度を推測する
- 出てきたクラスや関数の定義を追いかける
- いま扱おうとしているのは、変数？ポインタ？二重ポインタ？　型は何か？
- この代入はコピー？参照？
- 全体像と細部を交互に見る。視野の縮尺を自在に動かしながら細部を詰める
データ構造、アクセスについての学び
- 全体のデータをどこかでひとまとめに管理していて、各関数でポインタを渡して操作しているという仕様に気づく
- 「配列」的なデータ構造はいろいろある（set,vector,list…）が、データ量が膨大になると選択の良し悪しでメモリ効率やパフォーマンスが変わる。根拠を持って選択すべし。
もしエンジニア職を目指すならどういう価値観で行きたいか？
- 仕事で求められる役割を果たすなら膨大な具体例・実践をインプットしないといけない。
- 技術の流行り廃りに左右されず、役立つソフトウェアを長く支えたい。発信やトレンドのキャッチアップに振り回されないキャリア形成も考えられる。これまで、エンジニアは目新しさにすぐ飛びつけなければならないと思っていた。
- 目立つことより価値を生むことが大事だし、技術イベントなどで目に付く人たちのスタイルに振り回されなくていい。そういうのが好きならやってもいいけど。
- 「この人が設計したものは後々困らない」という信頼を得たい
基本の大切さ
- コーディング問題を解くと、ifやforなど基本的な処理の組み合わせなのにミス多発する
- 間違いの原因は基本が身体に染みついていないから
  - 引数を参照で受け取る→戻り値なし、void型、returnしない
  - 引数をコピーで受け取る→戻り値あり、型も指定、returnする
- 分かるとできるの差が大きい
- 「基本を絶対に落とさない」だけでも実力がついている
- かっこよさ、エレガントな手法、独自な方法はまだまだ不要
「ユーザー視点の直感的操作」を裏方でロジックを考え実現させるのは手間が掛かる
変数を取り込んで、いじって、吐き出すのを繰り返すだけなのにMuseScoreのようなソフトウェアが実現している驚き
自分が開発者サイドだと、この処理がベストなのか？を悩んでいつまでもアウトプットできなそう
- まず動くものを作る。
- 最適解を考えるのは、動かしてからでいい。
- まず試さないと何が悪いかも分からない。
- どこまで最初に準備して、どこからトライアンドエラーに移すかのバランス感覚が難しい
着眼点の変化
- はじめ：C++の文法、ライブラリ、環境構築、全体と部分の対応
- 1ヶ月続けてみて：コードの解釈から、設計思想を探るようになってきた。ユーザー操作を何でも受け入れない。楽譜として意味が通るかどうかをチェックしながら限定的にユーザーの操作を許可しているんだなあなどと気づく。
ソフトウェアの設計スキルを高めれば、（人への）権限委譲も上手くなりそう。
- ただし余計な私情が絡まなければ。
- 人間が個別に動いても全体として機能するように業務の振り方を設計できたら組織は動くよね