kakakakakku blog

Weekly Tech Blog: Keep on Learning!

Dockerfile の ARG を使って FROM を変数化する

コンテナイメージを作るときに Dockerfile の FROM に指定する「イメージ名」「タグ名」をビルドごとに変えて設定したく,Dockerfile の ARG を使って実現できた.試しながら学んだポイントをまとめる❗️

Dockerfile 例

例えば,以下の Dockerfile では ARG を使って VERSION を変数化していて,docker build コマンドを実行するときに --build-arg オプションを使うと変数に値を挿入できる.もし --build-arg オプションを使わなかった場合はデフォルト値(今回の例だと latest)のままになる.

ARG VERSION=latest
FROM nginx:${VERSION}

ARG の仕様や注意点などはドキュメントに詳しく載っている.

docs.docker.com

実際に docker build --build-arg コマンドを実行して,NGINX 1.22NGINX 1.23 のコンテナイメージを作ったところ,期待通りに起動できた.よって,Dockerfile の ARG を使うことで「Dockerfile」を共通化できるようになった❗️

NGINX 1.22

$ docker build . --tag my-nginx:1.22 --build-arg VERSION=1.22
$ docker run -p 8080:80 my-nginx:1.22
(中略)
2023/03/07 00:00:00 [notice] 1#1: nginx/1.22.1
(中略)

NGINX 1.23

$ docker build . --tag my-nginx:1.23 --build-arg VERSION=1.23
$ docker run -p 8080:80 my-nginx:1.23
(中略)
2023/03/07 00:00:00 [notice] 1#1: nginx/1.23.3
(中略)

ARG のスコープに気を付ける

ドキュメントに載っている通り,FROM より前に設定した ARG はビルドとは異なるスコープ(ビルドステージの外側)になる点は理解しておく必要がありそう.

An ARG declared before a FROM is outside of a build stage, so it can’t be used in any instruction after a FROM. To use the default value of an ARG declared before the first FROM use an ARG instruction without a value inside of a build stage:

実際に確認するため,以下のように Dockerfile に VERSIONversion.txt に書き出す1行を追加した.コンテナを起動して version.txt を確認すると,スコープが異なるためファイルの中身は「ブランク」だった.

ARG VERSION=latest
FROM nginx:${VERSION}
RUN echo ${VERSION} > version.txt

正しくは FROM の後にもう一度,デフォルト値は指定せずに VERSION を追加する必要がある.

ARG VERSION=latest
FROM nginx:${VERSION}
ARG VERSION
RUN echo ${VERSION} > version.txt

すると,期待通りに version.txtVERSION を書き出せた❗️

# cat version.txt
1.23

# cat version.txt
1.23

# cat version.txt
latest

3000円台で買えてコスパ良し!マランツプロ M4U を1ヶ月使ってみた

Amazon で "そこそこ" 評判が良く,メーカーは信頼できるマランツプロ 🎵 そして何よりもお手軽すぎる「3000円台(記事を書いてる 2/25 時点だとなんと3,192円 💰)」という価格にも驚きで,あまり期待はせずに検証も兼ねて「888M マランツプロ USB コンデンサーマイク M4U」を買ってみた❗️

1ヶ月(2023年2月)ミーティングや収録で使ってみて,結論としては「十分に使えた👌」ので紹介したいと思う.価格もお手軽なので「マイク入門」にも良いと思う.ただし macOS で使う場合には自分自身の環境 (macOS Monterey と Ventura) だと問題もあって,その点も紹介する〜

\( 'ω')/ コスパ最強マイクだぁぁぁー

製品紹介(M4U と MPH1)

マイク (M4U) 側の端子は XLR になっていて,付属の A/D コンバーターに接続して使う.A/D コンバーターと macOS 側は USB Type-A で接続する.そして製品画像にも載っている通りマイクスタンドも付属していて,セットアップするとすぐに使える.マイクの質感も良くて「高級感」というか「プロっぽさ」もある❗️ちなみに A/D コンバーターの AUDIO OUT にはヘッドホンを接続できて,セット購入したヘッドホン (MPH1) を検証も兼ねて使っている.

自宅デスクに並べて1枚撮ってみた 📷

macOS で発生した音声トラブル

実際に macOS (Ventura) にセットアップをしてマイク音を確認したら完全に NG ⚡️マイク音のノイズ(音が割れている)が酷く,聴くに耐えないレベルだった.正確に言うと常時ノイズが出ているわけではなく,最初数秒はキレイに収録できていたと思ったら,急激にノイズで埋め尽くされてしまう感じ.環境依存も考慮して別の macOS (Monterey) で確認してもノイズはなくならず,Windows で確認したところ問題なくクリアな音を収録できた.macOS での不具合は Amazon のレビューにも同じコメントが数件あって,再現性はありそうだった 💦

macOS 対応って書いてあるのに全く使えないのは厳しく,返品をしようと思ったけど,もしかしたら...と思って「A/D コンバーター」を変えてみた.するとビンゴ 🎯 驚くことに macOS でもクリアな音を収録できるようになった.コンバーターも種類が多くて悩んだけど,失敗しても落ち込まずに済みそうな「UGREEN USB オーディオ変換アダプタ」を買った.現在だと 1,099円で買える〜 💰

「UGREEN USB オーディオ変換アダプタ」を使う注意点としてはオーディオ装置名が「USB Audio Device」と表示されてしまって判別しにくいところ.付属の A/D コンバーターは「MARANTZ M4U」と表示される.

まとめ

その後は1ヶ月ほどミーティング(10回)や収録(ポッドキャスト練習)でマイク (M4U) を使ってみて,問題なく使えるようになった.ミーティングでは相手に音質を確認して「クリア❗️」と言ってもらえていて(サービス側のノイズ軽減が効いてる可能性はある),練習で収録したポッドキャストも音質的には「問題なく聴けるレベル」になっていた.そして「単一指向性」なので "ある程度は" 環境音を拾わずに収録できる.コスパ最強マイクと言えそう 👏

ただし 自分自身の環境だと macOS では問題があって,A/D コンバーターを追加で買うことを考えると価格的には別の選択肢もありそうだし,僕は音響の専門家ではないので,もっと厳密に音を分析すると他にも良し悪しは出てくると思う.それは別途レビュー記事や YouTube などを参照してもらうのが良いかと〜

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

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

圧倒的な読みやすさ

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

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

体験できる

Chapter 4 以降は Web サイトを実装するというテーマで実際に Git / GitHub を体験していく(プルリクエスト/レビュー/コンフリクトなど).Git を学ぶためにはとにかく試すことが重要だと思うし,予期せぬ事故に出くわして理解が深まることもあると思う(例えば git reflog とかw).だからこそ,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 switchgit restore の話は載ってないかもなぁーと思ったらちゃんと「ワンポイント」で言及されていたし,個人的に必須な code コマンドから VS Code を起動する設定まで載ってて最高かよ〜と思って嬉しくなってたら実際に Chapter 4 で使うようになってたし,他にも印象に残って読書メモにまとめていることが多くあった.

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

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

関連記事

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

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