Content-Length: 136420 | pFad | https://blog.magnolia.tech/
プレゼン資料、報告資料など、文書で人に何かを説明する資料を作るときは、まずは資料もないところから「説明の練習」をはじめる
まずは2-3分で短く説明する
次に段々時間を延ばしていってターゲットにする時間（たいてい10分〜15分とかになることが多い）くらい想定する資料の流れで喋れるようになってから実際のドキュメントを作り始める
最初は声に出さないけど、次第に声にだして練習を繰り返す
どんなドキュメントを描くにしても2-3分で概要を説明できるようになってから書いてって言ってる
— magnoliak🍧 (@magnolia_k_) February 20, 2025
短い時間でポイントに絞って説明できないなら、まだドキュメントを書く段階じゃない
LTやって膨らませて長い発表に成長させていく感じ
ドキュメントを作るところから始めると、細かいところや、レイアウトとかに先に気持ちが持っていかれてしまって、書きたいことに集中できないから、まずは説明する流れを作るために繰り返し説明の練習だけをやる
そこから実際のドキュメントの作成に入ると結果的にトータルで早くできる
Kent Beckの『Tidy First?』を読んだ
本書は、より広い範囲を扱う「リファクタリング」ではなく、もっと狭い範囲である「コード整頓」を扱う本
意図的に狭い範囲に絞って論じてることもあり、全部で132ページしかない
語り口も非常に軽妙で、さらっと読めてしまう
第Ⅰ部には15個の整頓方法が出てくるが、どれも解説自体は非常に短く、さらっと終わっているのだけど、その背景には長年の経験から深い洞察がある
しかし、きっと日本でこの手の本を書こうとしたら、もっと網羅的に！とか、もっと高度なテクニックを！みたいな指摘が来て、読み切れないような量になってしまうのでは？と思った
第Ⅰ部、全部でたったの40ページしかない
どれも、「え！もう終わり？」くらいの解説だし、「デッドコード」の章なんて実質「消そう」しか言ってない、超シンプル！
「ステートメントを小分けにしよう」も、実質「ちゃんとコードの区切りに合わせて空白行を入れよう」しか言ってない
一つ一つがシンプルだし、解説も少ないからこそ「まずはやってみよう」と思わせるシンプルさ、引き算の世界
続く第Ⅱ部がタイトルである「Tidy First?」の伏線回収に入るターン
じゃあhowは分かったけど、whenは？というのがこの章のポイント
how, when と続いて、第Ⅲ部は、「why」...なぜ整頓をしないといけないのか、その理由が語られるところがポイント
単なるプラクティスのカタログ本かな？と思っていたけど、そうではなく、一つ一つの手法はさらっと、かつすぐに実践できるレベルに留めて、実際のコードにどうやって適用していくか、それが理路整然と書かれていて、非常に面白く、一気に読み切ってしまった
ただ、一回読むだけで終わりにするのはもったいないし、何度でもこの先読める本
一方で、実際のコードの整頓方法に関する解説は40ページしかないので、まずはここまで読み切って、実際のコードに適用してみることを繰り返して見るのがいいかも
世の中のコードの書き方の本は、ゼロから書くか、全部を一度に奇麗に直すことが前提になっていて、なかなか「現実と折り合いをつける」ことにフォーカスしていないので、ここまで実践的な本はなかなか無いと思う
とにかく最初の40ページを読んでみましょう！！！
zshの設定を見直すために、改めてzshの設定ファイルの意味や、読み込まれるタイミングなどを調べたら、けっこう環境によって違うので、まとめておく
ドキュメントでは設定ファイルがどのフェーズで読み込まれるかは解説してくれるが、それぞれの設定ファイルに「何を書くべきか？」「何を書くべきではないか？」は教えてくれない
どのようなタイミングで読み込まれるかを知っておくことで、それを決めることができるようになるはず
.zshenv全ての環境で必ず読み込まれる
そのため、あまり設定を入れ過ぎない方がよい
自分の環境では後述する.zprofileと、.zshrcの読み込み先を$HOME/.config/zshディレクトリとする設定だけを入れている
export ZDOTDIR=$HOME/.config/zsh
こうすることで.configディレクトリ配下をgitのリポジトリとしてバージョン管理できるようになる
.zprofileログインシェルで読み込まれる
echo $0の出力が-zsh(コマンド名の先頭がハイフン)の場合は、ログインシェル
「ログイン」と付いているが、必ずどんな環境でもユーザーがログインした時に一度だけ実行されるという意味ではない
後述するが、環境によってまったく読み込まれなかったり、ユーザーログイン時に一度だけ読み込まれたり、ターミナルのウインドウが立ち上がる度に何度も読み込まれたりする
読み込まれるタイミングや回数に最も気をつけるべき設定ファイル
ログインシェル、かつ非インタラクティブシェル、という環境もあるので、出力結果が表示されるとは限らない
つまり、設定する内容はPATHの設定など、環境変数の設定のみに絞った方がよい
.zshrcインタラクティブシェルで読み込まれる
echo $-の出力にiが含まれている場合は、インタラクティブシェル
履歴や、プロンプトの設定、gitのリポジトリ状態の表示など、シェルにの操作、入出力に関する設定を書く
ターミナルエミュレータのウインドウを開く度に「ログインシェルかつ、インタラクティブシェル」が立ち上がる
.zprofileはユーザーログイン以降、複数回読み込まれることを前提に書くべきと言える
ただし、設定で非ログインシェルに変えられるため、ターミナルエミュレータの設定との整合性には要注意
他のプロセスに影響するような、例えば「設定ファイルへ追記」のような変更はすべきではない
現在のプロセスと、その子プロセスのみに影響する「環境変数」の設定に絞った方がよい
なお、macOSのターミナルエミュレータは、Terminal.appだけでなく、macOS専用のiTerm2や、クロスプラットフォームのGhosttyも全てデフォルトではログインシェルを起動する
Ubuntu 24.4で確認
ログイン方法によって異なるため、要注意
sshでログインすると、「ログインシェルかつ、インタラクティブシェル」が立ち上がる
ただし、コマンド起動を直接指定している場合は、シェルを経由しないため、必要な環境設定が行われない可能性に注意
X WindowベースのGNOMEにログインした後、ターミナルエミュレータを立ち上げると、「非ログインシェル、かつインタラクティブシェル」が立ち上がる
デフォルトではログインシェルではないため、明示的に読み込むように設定しないと.zprofileは読み込まれない
ターミナルエミュレータの設定を変えれば、立ち上げた時に「ログインシェル」となるように変えられ、その時は.zprofileが読み込まれる（macOSの逆）
WaylandベースのGNOMEにログイン時に、「ログインシェル、かつ非インタラクティブシェル」が実行され、そこからウインドウマネージャーが立ち上がる
つまり、この時点で.zprofileが読み込まれ、環境変数が設定され、以降のプロセスにはこの環境変数が引き継がれる
ターミナルエミュレータを立ち上げると、「非ログインシェル、かつインタラクティブシェル」が立ち上がるが、ログイン時に.zprofileが読み込まれているため、環境変数は引き継がれている
ターミナルエミュレータの設定を変えれば、ログインシェルにできるが、既に.zprofileは読み込まれた状態なので、わざわざ変える必要は無いと思われる
WaylandベースのGNOMEにログインした時に、ログインシェルが実行される仕組みは、以下のソースコードを参照
ここでは、興味深いテクニックが使われてる
普通にシェルスクリプトとして起動する
ユーザーのシェルを取得
そのシェルをログインシェルとして実行する、その際実行中のプロセスと置き換える形で起動する
新たにログインシェルとして起動したプロセスの中で、再度スクリプトを実行
ログインシェルとして立ち上がっていると、上記のロジックがスキップされる
GNOMEのセッションマネージャーが起動し、ウインドウの起動に移る
ログインシェルとして実行されているので、.zprofileが読み込まれているので、その中で設定された環境変数は以降のプロセスに引き継がれていく...
ハック！って感じだ
X Windowと、Waylandの設計思想の違いが見てとれて面白いけど、Waylandベースの方がしっくりくる
上記の調査結果を踏まえると...
.zshenvには極力なにも書かない.zprofileには環境変数の設定(PATHの追加など)に絞る.zshrcにはシェルの操作や、入出力に関するもの、.zshenvや、.zprofileに書けないものを書くX Windowベースの環境では、ログイン時に.zprofileが読み込まれるように設定の追加を行う
(SSHでのリモートログイン時にはログインシェルとなるので、一貫性を確保するため)
という方針でzshの設定ファイルを書くのが良さそう
年明けくらいから常用するターミナルエミュレータをGhosttyに切り替えたので、その導入メモ
デフォルトでは下記のパスのファイルを編集する
メニューの「Settings...」を選択すると、このファイルが開かれる
$HOME/Library/Application Support/com.mitchellh.ghostty/config
ただし、下記の設定ファイルの場所もサポートされている
$HOME/.config/ghostty/config
設定できる項目が多いので、非公式の設定ファイル編集ツールで設定可能な項目をチェックすることをお勧めする
font-family利用できるフォントは、ghostty +list-fontsで確認できる、モノスペースフォントのみが対象
指定しない場合は、Jetbrains Monoが利用される
自分の環境では、ターミナルではちょっとクセのある文字が好みなので、0xProto Nerd Font Monoを使っている
font-featureリガチャの設定が効き過ぎているので、必ずfont-feature = -dligを設定することをお勧めする
勝手に「ます」が「〼」に変換されて、「文字化けか？」と驚くことになる（「株式会社」を「㍿」に変換するのは、もはや改変では？と思えるし）
デフォルトでリガチャが有効なのは嬉しいけど、ちょっとやり過ぎ感
font-sizeモニタとウインドウのサイズに合わせて設定する
themeghostty +list-themesで、非常に分かりやすいプレビュー表示が出てくるので、好みの設定に
最近は、tokyonightを使っている
cursor-style、cursor-style-blinkカーソルのスタイルと、ブリンクの設定
mouse-hide-while-typingキーボードからの入力中に、マウスカーソルを表示するか否か
termデフォルトでは、xterm-ghosttyが設定されているが、リモートログイン先などでterminfoが無いことで表示が崩れる場合に明示的に設定する
開発版のncursesには既にxterm-ghosttyがマージされているが、リリースされて普及するにはまだ時間がかかりそうなので、当面はxterm-256colorなどを設定しておくのが良さそう
また、その場合、以下の設定を追加することで、sudo実行時に環境変数がリセットされ、term=xterm-ghosttyに戻ることを防ぐことができる
shell-integration-features = sudo
window-width、window-height初期のカラム数、行数を指定する
フォント周りと、テーマ、カラム数、term以外はほとんど設定する必要も無さそうな項目が多く、設定ファイルが大きくならないのは良い
Fujiwara Tech Conference 2025というイベントに行ってきた
ecspressoを始めとする数々のOSSをリリースしているFujiwaraさんのファンミーティングといえるイベント
みんながそれぞれFujiwara-wareに対する愛を語っていた、とても素敵なイベントになっていた
最後のFujiwaraさん自身のキーノートも良かった（カメラの話から始まるのが新鮮だった）
直前に公開されたツナギメエフエムのFujiwaraさん回と、上記のスライドを読めば君も立派なFujiwaraファンになれる！
ツナギメエフエムFujiwaraさん登場回
割とみんなが言っていたことをまとめると、「実用的」「境界線の切り方が良い」「便利さがじわじわ分かる」「組み合わせの妙」みたいなところか
これを一言で「センス」と言ってしまうと見も蓋も無いけど、必要なものを作り、みんなに公開し、自身も色々なソフトウェアへ貢献する...OSSの良い側面が一番強く出ているのが一連のFujiwara-wareじゃないかなーと思いました
問題を見つける
— magnoliak🍧 (@magnolia_k_) January 18, 2025
境界線を見つける
小さく作る
みんなで使う
コードがスケールして、みんなの助けになる感じが凄い
#fujiwara_tech_conf
あの姿勢がみんなを引き付けるんだなと思ったイベントでした
ちなみにFujiwaraさんがご自身のソフトウェアにたいして付けている愛称であるところの「隙間家具OSS」という言葉が初めて登場したスライド、実は吉祥寺.pmでの発表が最初だったそうで、毎回ちゃんと「吉祥寺.pmでの発表で初めて言った」と言及頂くので、ほんとうに有り難い。イベントを長く続けていると、こんな良いことがある、嬉しい。
最後に主催のMoznion氏より、「次回Fujiwara Tech Conference 2026でお会いしましょう」と締めの挨拶が有りましたので、皆さん楽しみにしていてください。
新社会人みたいな人にアドバイスを求められたら毎回同じことを言っているけど、だいたいこんな感じ
— magnoliak🍧 (@magnolia_k_) January 12, 2025
食事・運動・睡眠は最優先にする
ロールモデルは立場が近い人を複数設定する
趣味など常時関心が持てるものを用意する
これは突き詰めると、自分なりの基準点を設定しましょう、という話で
食事・運動・睡眠は、言うまでもなく...
立場が近い人をロールモデルにするのは、割とすぐに「自分は同じ振るまいができているか？」というのを振り返られるから、というのもあるし、かつそれが「複数」必要なのは過度に比較し過ぎて”逃げ場”が無くならないように。
10年後に振り返るより、1年くらいの間に振り返って「同じことができているかな？」と比較できるといいし、世の中完全な人は居ないし、どんなに凄い人でも自分が完コピする必要もないし。
関心があることを常時持つのは、それが「関心が持てなくなったときに立ち止まれるから」...「あんなに熱心にやってたことに、集中できなくなった」というのは分かりやすい黄色信号だからねって。
ほかにももっといっぱい言いたくなるけど、そんなにたくさん一度に言っても覚えられないので、まずはこの3つだけ
自分は柔軟に、抽象的に思考できる方だと思っていたけど、自分が詳しい設計を見直す必要があるときに、驚くくらい既存のアーキテクチャや、実装に縛られて思考していることに気付いたことが有って、人は簡単にバイアスから逃れられないんだなぁと思った、マル https://t.co/zReu5njYZs
— magnoliak🍧 (@magnolia_k_) January 6, 2025
「自分が一番詳しい」という状態をまずは目指すべきだと思うけど、そこからどうやって離れるか？みたいなところはあるよなー
— magnoliak🍧 (@magnolia_k_) January 6, 2025
対象に近づき過ぎると、俯瞰的にものごとが見れなくなってしまう、詳しいという自負が目を曇らせてしまう...
自分が分かる範囲で理解しているだけで、本当に必要な見方ができていない、分かるべきことが分かっていない、ということが有るよなー、でもそんなに簡単には変えられないよなー、分からないよなーということなので、色々な価値観や経験の人の話を聞くのが大事なんじゃないかなと思った
Fetched URL: https://blog.magnolia.tech/
Alternative Proxies: