Git / GitHub に入門するならまずこの一冊 /「いちばんやさしい Git & GitHub の教本 第2版」を読んだ

「いちばんやさしい Git & GitHub の教本 第2版」を読んだ．「いちやさ」と謳っている通り，本当に本当に丁寧に書かれていて，説明の歩幅も小さく，Git / GitHub の初学者でも挫折することなく読み進められる一冊だった．また情報量も意図的に抑えられている気がしていて（読者層の定義がしっかりされていそう），開発現場で Git / GitHub を使う上で「最低限このあたりは知っておいて欲しいぞー❗️」という内容が凝縮されていた．もし Git / GitHub に慣れてなくて "これから学ぼうと思っていて〜" という人がいたら真っ先に紹介したいと思う👏

いちばんやさしいGit&GitHubの教本 第2版 人気講師が教えるバージョン管理&共有入門 (「いちばんやさしい教本」シリーズ)

圧倒的な読みやすさ

フルカラー🎨という良さもあるけど，とにかく図解とキャプチャの多さが印象に残った．初学者に技術を伝えるときに図解を活用するというテクニックはよく使うもので，例えばリポジトリの関係図やブランチ図がわかりやすく図解されていたけど，本書ではさらに「大量のキャプチャ」も載っていてとにかく読みやすくわかりやすかった．git コマンドの実行結果などはテキストとして載せることもできるけど，本書にはちゃんとターミナルで実行したキャプチャが載っていた．キャプチャ（画像）を載せるのってちょっとした修正に弱く，不要な情報が載っていないか慎重に確認する必要があって，個人的な経験から結構手間だったんじゃないかなぁーなんて思ったりもした．

他には Git をインストールする手順も「イイ感じにやれば良し！」みたいに言ってしまいそうだけど，Windows / macOS どちらにも対応したキャプチャが載っていて，これ以上ない手厚さだった（逆に言うとサイトデザインなどが変わったりすることへの影響は受けやすくなるけど本書の読者層には必要だと判断されたんだと思う）．

体験できる

Chapter 4 以降は Web サイトを実装するというテーマで実際に Git / GitHub を体験していく（プルリクエスト／レビュー／コンフリクトなど）．Git を学ぶためにはとにかく試すことが重要だと思うし，予期せぬ事故に出くわして理解が深まることもあると思う（例えば git reflog とかｗ）．だからこそ，Chapter 4 以降は本書を読むだけではなく，ぜひ実際に yasagit-2/ichiyasaGitSample リポジトリをフォークして体験して欲しいと思う❗️現時点で Fork が 750 を超えていて，体験されている人の多さに驚いた．また本書では「友達や仕事仲間と一緒に進めてみるのも良いよ」と書いてあって，確かにそうすると「よりチーム開発に近い体験」ができそう．

github.com

体験という意味だと GitHub の GitHub Skills（旧 GitHub Learning Lab） も便利で，僕はよく初学者に GitHub Skills を紹介している（必要なら自動翻訳も使ってもらいつつ）．本書と同じように Git / GitHub の基本操作を学べるし，さらにステップアップをして GitHub Pages や GitHub Actions を体験するコンテンツもある．本書を読み終わったら試してみると良いのではないでしょうか❗️

skills.github.com

現場目線

本書では，知っておくべき「現場目線なポイント」も紹介されていて，実践的だなーと思った．例えば以下など❗️このあたりは Git / GitHub の機能と言うよりも文化的な側面で，意識できていると良さそう．

• コミットメッセージの形式
• プルリクエストを誰がマージするか
• LGTM とは何か
• 絵文字
• レビューでのマナー

個人的に気になった

もしかしたら「いちやさ」の組版として定番なのかもしれないけど，以下のように文章の中央で分割されているレイアウト（段組）だと個人的に視線を動かせず，ずっと読みにくく感じていた．あくまで僕個人の感想なので一般的には読みやすいのかも〜

まとめ

「いちばんやさしい Git & GitHub の教本 第2版」を読んだ．これから Git / GitHub を学ぶぞ！という人におすすめできる．僕自身もこれまでの経験で Git / GitHub 未経験者に教える機会が多くあり，実際にペアプロのようにペアで話しながら教えるのが効果的だと思っていたけど，まずは本書を読んで簡単に体験してもらってからペアで教える流れがもっと良さそう❗️とも思えた．

他には細かいところだと，git switch と git restore の話は載ってないかもなぁーと思ったらちゃんと「ワンポイント」で言及されていたし，個人的に必須な code コマンドから VS Code を起動する設定まで載ってて最高かよ〜と思って嬉しくなってたら実際に Chapter 4 で使うようになってたし，他にも印象に残って読書メモにまとめていることが多くあった．

なお，本書は id:syobochim に献本してもらって読んだのに書評記事をまとめることができず，ずるずると伸びてしまってごめんなさい🙇‍♂️そして献本ありがとうございました❗️さらに重版おめでとうございます🎉

おかげさまで、いちばんやさしいGit&GitHubの教本の重版が決まりました〜！🎉🎉🎉 https://t.co/8WaA3BHd9a

— しょぼちむ (@syobochim) 2023年2月24日

Git / GitHub の初学者に最高の一冊でした❗️

いちばんやさしいGit&GitHubの教本 第2版 人気講師が教えるバージョン管理&共有入門 (「いちばんやさしい教本」シリーズ)

関連記事

kakakakakku.hatenablog.com

Calendly 1on1 振り返り（2023年2月）

気軽に 1on1 などのミーティングを申し込める「Calendly」というサービスをテスト運用として1ヶ月導入してみたので（2023年2月），簡単に振り返ってみようと思う．Calendly は本当に便利で今後も継続して使っていくぞー❗️という気持ち．Calendly の機能紹介は以下の記事にまとめてある．

kakakakakku.hatenablog.com

1on1 件数

2023年2月の Calendly 1on1 テスト運用では「4名」とお話できた❗️どの 1on1 もとても楽しく，あっという間に時間がたってしまった⏳テスト運用中なのに積極的に申し込んでもらってありがとうございました❗️感謝ぁぁぁ ＼( 'ω')／

1on1 のトピックをザッと分類すると以下だった．

• 雑談: 1名
• テックブログ相談: 1名
• 技術相談: 2名

1on1 前日までに

まず，1on1 前日までに Notion にドキュメントを作る．前に検証記事を書いた通り，Calendly と Zapier を連携すると自動的に Notion にドキュメントを作れるけど，Calendly の無料プランだと Zapier 連携は使えなくて残念...！そして，Notion ドキュメントにネタ帳（アジェンダやメモなど）をまとめていく．

• アイスブレイク
• 前にお会いしたのはいつか（もしくははじめてお話するか）
• 最近はどんなアクティビティをされているのか（ブログ / Twitter / GitHub などを網羅的に確認する）
• 記載してもらった 1on1 トピックに関する情報をまとめる
• etc

ネタ帳をまとめるのに少なくとも30分以上は必要なので，直前にバタバタしないように 1on1 前日までに終わらせている🍀

kakakakakku.hatenablog.com

1on1 開始前

マイクとカメラなどオーディオ機材の動作確認をしてから，開始5分前には Google Meet に接続する．カメラ位置や画面共有をするときのために接続確認などをしつつ，残った時間は「笑顔の練習」として，頬を上げ下げして表情を柔らかくしている（この頬を上げ下げしている姿を見られたら本当にヤバイ👽笑）．

また Calendly 1on1 を募集する前に個人的に決めた「意識するべき3つのポイント」があって，1on1 開始前に見直している．

• ① 傾聴しよう！（自分のことばかりを話さないように）
• ② 無理にアドバイスをしすぎないようにしよう！（アドバイスおじさんにならないように）
• ③ 時間を厳守しよう！

1on1 終了後

1on1 の後は Notion ドキュメントに僕自身の振り返りを簡単にまとめている．常により良い 1on1 を目指して模索中❗️

• どんな話をしたか
• より良い 1on1 にするためにどんな改善ができるか
• また 1on1 を申し込んでもらえるとしたらどんな話をしたいか
• etc

良かったこと

負担にならないように 1on1 後のアンケートは取得していないけど，僕としてはとにかく楽しく 1on1（雑談）ができたことは良かったと思う❗️そして，無理にアドバイスをしすぎないように気を付けつつも，相談や疑問に多少なりとも回答できたり，少しは背中を押せたんじゃないかなぁーとは思う．また申込み時の質問に「顔出し: ON/OFF」の希望を設定しておいたのは正解だったと思う．できる限り，気軽に 1on1 ができるようにしたいと思っている．

改善できること

まず，2023年2月のテスト運用では「10-11時」の2枠で 1on1 を募集していた．仕事によってバラバラだとは思うけど，10時だと朝会（デイリースタンドアップ）などとカブってしまうということも多そうだと気付いた．そこで，今後は時間をずらしたり，場合によっては平日夜や週末も候補日にできると良さそうだった．2023年3月以降はできる限りバラバラとスキマ時間を Calendly 1on1 枠として確保してみようと思う 📅

そして，1on1 のトピック的に一度話して終わりではなく，また定期的にお話したいなぁーと思うことがほとんどだった．僕としてはウェルカム👌だけど，1on1 を申込む側としては「2回目ってイイんだろうか...」と不安になってしまう可能性があると気付いた．そこで Calendly 1on1 のサイトに FAQ を追加しておいた．お待ちしています❗️

(FAQ) 1on1 の申込みは1回限りですか❓
→ 2回目/3回目もウェルカムなので定期的に 1on1 しましょう❗️

まとめ

簡単に Calendly 1on1 のテスト運用（2023年2月）を振り返ってみた❗️

Calendly の操作や運用など，全体の流れは把握できたのでテスト運用は終了して，今後も引き続き 1on1 を受け付けることにした．Calendly 1on1 の申込みは以下のリンクや kakakakakku blog のサイドバーから気軽にどうぞ〜

＼( 'ω')／ うぇーい

calendly.com

生産性を高めれば高めるほどますます忙しくなる /「限りある時間の使い方」を読んだ

タイトルに惹かれて「限りある時間の使い方」を読んだ．僕は日常的に "忙しく時間がないなぁ..." と感じることが多い（忙しいフリをしているだけの可能性もある）．やりたいことは多いけど全然処理しきれず，常に何かしらを犠牲にしているというモヤモヤもあって，本書を読んでみることにした．

僕自身は "意識高い" 自己啓発本が大好きではあるけど，本書はそういった「ライフハック本」ではなく，○○をしろ！○○はするな！という内容ではなかった．もっと哲学的な内容が多く，根本的な "何か" を気付かせてくれる感じで，人生や時間について考えながら読み進めることができた．また本書で繰り返し出てくる「生産性オタク」や「完璧主義者」はまさに僕自身のことを揶揄しているようにも感じられて，時間をコントロールしているはずなのに常に何かに追われているという点は非常に刺さった．他にも刺さった箇所は「読書メモ」に箇条書きにしておく❗️

限りある時間の使い方

目次 🕛

もう章タイトルを見るだけで刺さる...

• Part 1「現実を直視する」
  • 第1章 : なぜ、いつも時間に追われるのか
  • 第2章 : 効率化ツールが逆効果になる理由
  • 第3章 : 「時間がある」という前提を疑う
  • 第4章 : 可能性を狭めると、自由になれる
  • 第5章 : 注意力を自分の手に取り戻す
  • 第6章 : 本当の敵は自分の内側にいる
• Part 2「幻想を手放す」
  • 第7章 : 時間と戦っても勝ち目はない
  • 第8章 : 人生には「今」しか存在しない
  • 第9章 : 失われた余暇を取り戻す
  • 第10章 : 忙しさへの依存を手放す
  • 第11章 : 留まることで見えてくるもの
  • 第12章 : 時間をシェアすると豊かになれる
  • 第13章 : ちっぽけな自分を受け入れる
  • 第14章 : 暗闇のなかで一歩を踏みだす
• エピローグ : 僕たちに希望は必要ない
• 付録 : 有限性を受け入れるための10のツール

読書メモ 🕛

読みながらメモしたことを箇条書きで残しておく❗️本書の完全な引用ではなく僕自身の解釈も含めてある〜

Part 1

• 効率を上げれば上げるほどますます忙しくなる
• 生産性オタクは TODO リストを消化することに夢中
• そもそもやりたいことを全部やる時間はない
• 時間をコントロールしようとすればするほど時間のなさにストレスを感じる
• 給料は良いけど忙しすぎて家族とゆっくり過ごせない
• もっと効率的に進めれば忙しさから逃れられるという希望を捨てる
• 時間をコントロールするために完璧なスケジュールを作るとそれを邪魔する遅延や割り込みにストレスを感じてしまう
• 完璧主義者は大切なことを先延ばしにする
• 完璧を目指していたらいつまでたっても着手できない
• 注意散漫では相手を気遣うことさえできない

Part 2

• 時間との戦いに勝てるわけがない
• 時間をうまく使おうという強迫観念にとらわれている
• 休日も TODO リストを作って生産的に過ごしたくなる
• 何もしていないことが嫌と感じる怠惰嫌悪
• 目標志向すぎると誰が見ても圧倒されるような業績を残さないと時間を無駄にした気がしてしまう
• 個人主義的な時間に対抗して少しだけ共同の時間を取り戻してみる
• 宇宙的無意味療法
• 自分はまだ本当の人生を生きていない

刺さりすぎ...🔪

まとめ 🕛

「限りある時間の使い方」を読んだ．少し皮肉なのは，僕は有給を取った日 (2/9) に本書を読んでいて，さらに TODO リストに従って「45 min ポモドーロ x 3（読了）」そして「45 min ポモドーロ x 2（ブログ下書き完了）」で時間管理をしているところ．

当たり前のように休日も含めて毎日 TODO リストを使って過ごしているし，日々の "無駄な時間" を見つけてはなくすことができないかを考えているけど，まぁ "少しは" 価値観を見直してみようかなという気持ちにはなった．とは言え，ライフハックは今後も実践したいし，無謀だと言われても本書に対抗して「時間との戦いに勝ちたい」と思っている❗️本書から何も学べていないw

あと本書を読んでて笑ったところは「ビッグロックの法則はいかさま」という話と「著者がオーロラを見たときの感想」かな〜

限りある時間の使い方

Playwright for Python: PDF 形式で印刷する

Playwright for Python でウェブサイトのスクリーンショット（画像形式）を取得するのではなく「PDF 形式で」取得したいこともあると思う（実際に最近あった〜）．Playwright for Python では page.pdf() を使えば簡単に実装できる❗️

そして page.pdf() はデフォルトで「印刷用 CSS : @media print」を認識してくれるため，ウェブサイト側のデザインに沿って "整って" 表示された PDF を取得できる．

playwright.dev

page.pdf()

デフォルトの用紙サイズは Letter なので format オプションで A4 など適切な用紙サイズを指定しておくのが良いと思う．

page.pdf(path='pdf/print.pdf', format='A4')

page.emulate_media() + page.pdf()

もし @media print ではなく @media screen で PDF を取得する場合は page.pdf() の前に page.emulate_media() でメディアを変更しておく必要がある．

page.emulate_media(media='screen')
page.pdf(path='pdf/screen.pdf', format='A4')

試す

今回はサンプルとして，MDN のドキュメントを @media print と @media screen それぞれで PDF 化した「1ページ目」を載せておく．MDN のドキュメントだと大きな差はないけど「ヘッダー部分」は @media print にはなく，ある程度は "整って" 表示されていると思う👌

developer.mozilla.org

今回試したサンプルコード

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto('https://developer.mozilla.org/ja/docs/Web/CSS/@media')

    page.pdf(path='pdf/print.pdf', format='A4')

    page.emulate_media(media='screen')
    page.pdf(path='pdf/screen.pdf', format='A4')

    browser.close()

Playwright for Python: screenshot() に指定できる便利なオプション3選

Playwright for Python の page.screenshot() でスクリーンショットを取得するときに指定できる「便利なオプション3選」を紹介する❗️

1. full_page

ウェブサイトのスクリーンショットを「全て」取得する場合 full_page オプションが使える💡デフォルトは False になっているけど，使う機会は多いと思う❗️以下のように実装できる．

page.screenshot(path='images/1_full.png', full_page=True)

2. clip

ウェブサイトのスクリーンショットを「部分的に」取得する場合 clip オプションが使える💡スクリーンショットを長期間残しておくと，アーカイブしておくファイルサイズも増えてくるため，本当に必要な部分に限定してスクリーンショットを取得しておくのは良いプラクティスだと思う❗️

• x（軸にする x 座標）
• y（軸にする y 座標）
• width（横幅 px）
• height（縦幅 px）

以下のように実装できる．

page.screenshot(path='images/2_clip.png', clip={'x': 150, 'y': 150, 'width': 400, 'height': 400})

3. mask

スクリーンショットの一部を「隠して」取得する場合 mask オプションが使える💡隠す箇所には Playwright for Python の Locator オブジェクトを配列で指定する．例えば kakakakakku blog の "ブログタイトル" と "記事タイトル" を隠すなら，以下のように実装できる．ドキュメントを確認したところ，現状だと色はピンク (#FF00FF) 固定になっていた．

page.screenshot(path='images/4_mask.png', mask=[page.locator('#title > a'), page.locator('.entry-title')])

今回試したサンプルコード

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto('https://kakakakakku.hatenablog.com/')

    page.screenshot(path='images/0_default.png')
    page.screenshot(path='images/1_full.png', full_page=True)
    page.screenshot(path='images/2_clip.png', clip={'x': 150, 'y': 150, 'width': 400, 'height': 400})
    page.screenshot(path='images/3_mask.png', mask=[page.locator('#title > a'), page.locator('.entry-title')])

    browser.close()