2023-01-11

#かがみの孤城 🐺🏰 オススメ鑑賞方法

アニメ

はじめに

100の方法で届けて、1届けばいい方です¹、nikkieです。

映画『かがみの孤城』、皆さまもう観ましたか？
私にはもうすごくよくて、何回も繰り返し劇場に足を運んでいます。

今回は、繰り返し鑑賞でのオススメポイントを共有します（ネタバレなしのつもりです）。
すでに観た方がもう一度足を運ぶ機会になれば嬉しいですし、まだ観ていない方も「面白そう！」と思って観に行っていただけたら最高ですね！

はじめに
目次
映画『かがみの孤城』とは
バリアフリー音声ガイドが超オススメ
丸の内ピカデリーさんでの鑑賞がオススメ
5週目（1/20(金)〜）、6週目（1/27(金)〜）、入場者プレゼントあります！
終わりに
P.S. こころちゃんかわいい

映画『かがみの孤城』とは

辻村深月さんの小説を原恵一監督がアニメ映画化！
12/23から公開しています。
現在3週目ですが、直近では「大ヒット御礼舞台挨拶²」と口コミで広がってきております！

詳細は以下のエントリに込めました。

バリアフリー音声ガイドが超オススメ

『HELLO MOVIE』というスマホアプリがありまして、それを使って音声ガイドが聴けるんです！
イヤホンを付けたまま映画を鑑賞する形になります。

「試しに一度使ってみるか」という気持ちで聴いてみたところ、私は音声ガイドが手放せなくなりました。
直近の数回は音声ガイドと一緒に堪能しています。
ぜひお試しください！

#かがみの孤城は2周目以降×バリアフリー音声ガイドの組合せが最強すぎるんです！https://t.co/6lUpsqmOyM
こころちゃん以外のストーリーも察されるし😭
フウカちゃんアキちゃんのあたり音声ガイドで、泣いちゃった…😭😭

繰り返し観ても聴いても耐性は付きません。
もう毎回泣かされてます…
— nikkie にっきー (@ftnext) 2023年1月7日

丸の内ピカデリーさんでの鑑賞がオススメ

私はかがみの孤城の初回を偶然新宿ピカデリーさんのシアター1（最大箱）で観ています。
素晴らしい音響の効果もあってどハマりしちゃったのですが、「おんなじくらい大きい箱でまた観たいな」と丸の内ピカデリーさんに足を伸ばしました。

丸の内ピカデリーさんでは、シアター1で上映されています。

シアター1は大きな劇場ですが、なんと2階席があるんです！（シアター2にもあります）
ちょっとした興味で2階席を体験したところ、目線の先にスクリーンがあるという体験に驚かされました。
見上げる感じじゃないんです！普通に座っているだけで目の先にスクリーン！
これは一度体験されるのをオススメします。

2階席で『かがみの孤城』を堪能したnikkie氏のツイートがこちら

丸の内ピカデリーさんでの #かがみの孤城めっちゃ好みなので、この感動を他の方にも伝えたいhttps://t.co/sifzxCYSxA
先日2階席の最前から観てみたんですが、
目線の位置にスクリーン！
天井のスピーカーに近いのもあり
1階席からとはぜんぜん違う体験でした。

こころちゃんのかわいさも2割増し！ pic.twitter.com/lrLIyBGald
— nikkie にっきー (@ftnext) 2023年1月7日

5週目（1/20(金)〜）、6週目（1/27(金)〜）、入場者プレゼントあります！

⋰
　　大ヒット御礼！2週連続
✨追加入場者プレゼント決定✨
⋱

2週連続❕追加入場者プレゼントの
配布が決定🐺✨#辻村深月✕#原恵一監督✕#佐々木啓悟
〈ここだけの風景〉が描かれた
スペシャルイラストカード💌

🏰第2弾 1/20(金)～
🏰第3弾 1/27(金)～

🪞詳しくは👇https://t.co/mmfFcBUBsv pic.twitter.com/RUjgrAcClj
— 映画『かがみの孤城』公式 (@kagami_eiga) 2023年1月8日

スペシャルイラストカードがもらえちゃいますよ〜
これは繰り返し鑑賞のまたとないチャンス！

なお、12/23〜配布された入場特典³があったのですが、その後が描かれていて、これはヤバいです。
ランダム3種だったんですが、コンプリート版を円盤とかにつけてください！
豪華版でもいいんで、揃ったやつ見たいんで！

終わりに

映画『かがみの孤城』を繰り返し観る上でのオススメポイントを共有しました。
丸の内ピカデリーさんは近くにないという方も、バリアフリー音声ガイドをぜひお試しください！！
そしてプレゼントがある1/20か1/27の週で劇場に行きましょう！
映画館リストはこちら

一度観た方には最高のPV、貼っておきますね（公式さん本当にありがとうございます！）

🪞｡:ﾟ･*

　　　映画『#かがみの孤城』
　　　　　　　　×
主題歌 #優里「メリーゴーランド」
　　　
　　　　　　　　　　　　　*:ﾟ･⋆｡🏰

鏡の世界に集められた７人🪞
その出会いが、奇跡を起こすー🎠✨

映画『かがみの孤城』
⋱⋱大ヒット上映中⋰⋰

🔊音声ONでご覧ください🎧 pic.twitter.com/hJHlm2x4CW
— 映画『かがみの孤城』公式 (@kagami_eiga) 2023年1月11日

P.S. こころちゃんかわいい

映画『かがみの孤城』は安西こころちゃん視点で描かれます。
それにしても、こころちゃんかわいい

映画 #かがみの孤城こころちゃんかわいいシーン、私のイチオシは

／
　お昼寝
＼

です！

すやすやかわいすぎる、ずっと見ていたい

かわいすぎるうううう
— nikkie にっきー (@ftnext) 2023年1月5日

ああ、こころちゃんかわいい…

かわいい

kawaii

🎬『#ハケンアニメ！』
チョイ見せ動画 4️⃣
･･････････････････

100の方法でも届くのは…❓
◤《行城理マーティング理論編》◢

刺され、アナタの胸にー⚡️#柄本佑

💬感想投稿キャンペーン実施中👇https://t.co/gmH2c8RKoQ

🎁数量限定入場プレゼントhttps://t.co/kjdA8mjUZK pic.twitter.com/m3q5f9E2KN
— 映画『ハケンアニメ！』公式 🔥絶賛上映中🔥 (@hakenanime2022) 2022年5月24日
↩
レポートもありますよ〜 ↩
なんとしてもコンプしたい…（公式さん、お願いします〜🥺） ↩

2023-01-10

メンテナ記 | GitHubでリリースを作るのは、怖くない

はじめに

今日（1/10）、犬王の日じゃない？ nikkieです。

1日1エントリを使って、億劫と感じていたリリース作成を行いました🎉（偉い！）
SpeechRecognitionのv3.9.0のリリースです。

こちらについて、2022年12月の自分に送るエントリです。

前提；3.9.0のリリースは思っていたより大変でした

コラボレータとなったSpeechRecognition、2022/12/04にPyPIにv3.9.0をリリースしています。

2017年12月のv3.8.1以来5年ぶりのリリースです。
setup.py中のnameが変わっているなど着手時には見通せなかったつまづきもありましたが、なんとかリリースできました。

PyPIにリリースした後「GitHubにもリリースを作る必要あるんじゃないか、これ」と気づいたnikkie氏。
限界を迎えていたため、タグを打ち、予定地をドラフトだけして（一般には見えないまま）1ヶ月がすぎました。

伝えたいこと：2022年12月のnikkieへ

SpeechRecognition v3.9.0 リリース、お疲れさまでした！
コラボレータ活動、頑張ってますね〜、素晴らしいです。

GitHubにリリースを作る必要を認識していながら、なかなか手が動かない状況かと推察します。
手が動かない主な要因は「経験がない作業でどれくらい大変かも見通せず、着手しづらい」ことではないでしょうか。

実は、GitHubでのリリース作成手順は、以下のドキュメントにまとまっています！

スクリーンショットも豊富で、非常に分かりやすいです。
これだけ見れば操作は完全理解だと思います。

5年ぶりのリリースということで、自分が知らないプルリクエストがたくさんある状況というのが見通しづらい一因だと思います。
で・す・が、GitHubの機能でリリースノートがプルリクエストから自動生成されます！

これを使えば、一からリリースノートを書く必要がありません。
Uberiさんが残した前回のリリースノートに合わせて体裁を整えるだけで完成です！

どうですか？この2つを知ったら結構簡単なんじゃないかと思えてきませんか？
GitHubのリリース作成を待っているユーザもきっといますよ。
1日1エントリで大変だと思いますが、どこかで少しだけ時間を取ってリリースを作ってみてください。

未来のnikkieより

リリースを書いての所感

GitHubのドキュメント、そして自動生成機能に大変助けられました
pull requestのタイトルって、自動生成の中に出てくるので大事なんだな〜
- メンテナはpull requestに編集権限が付くけれど、タイトル変更はガンガンやっていってよさそう（これまで使い所分からず）
- pull requestに関わっているときがそのpull requestに一番詳しい。後で思い出すのに苦労しないように、タイトルをリリースノートだと思って整えちゃおう！
5年分のプルリクエスト、機能追加とバグ修正・改善、ドキュメントの改善が混在していた
- タイトルで見当がつかないものは内容を確認しつつ、大まかに種類分けした
- ラベルを使うと種類ごとに分けやすいのかも
- タイトルのプレフィックスを使ってもいいかも（Conventional commit的な） -全部のpull requestから自動生成されたけれど、どこまで取捨選択すべきなんだろう？
- 例えばv3.8.1には「Lots of small build system improvements.」とある
- v3.9.0でこれに該当するのはどういうpull request？私が実施したあまりにちょっとしたpull requestだけ削った
リリースノートのテンプレートってあるのかな？
- 有名どころのリポジトリってリリースノートどうやってるんだろう？真似してちょっとだけでもうまくやりたい

終わりに

自動生成に大いに助けられ、GitHubでのリリースを作ることができました。
やってみると色々気づきがあるもので、「pull requestがリリースの一部になる」というのはこれまで考えつきませんでした。

世の中のメンテナの皆さまはどうやってメンテナに入門されているんですかね？
駆け出しメンテナなので、メンテナの入門書的なものがあったら読んでみたいなあ。
リリースノートを支える技術とか、メンテナの所作をもっとうまくやる方法も知りたいです（調べてみよう）

SpeechRecognitionのv3.9.0、お楽しみください（Whisperサポートなどいろいろ入ってます）！
引き続きSpeechRecognitionにコードで価値を届けていく所存ですが、スターやスポンサーで支えていただけるととっても嬉しいです！

P.S. 達人のリリース活用術

textlintのazuさんはGitHubのリリースでブログを書いているそう！

GitHubでタグに対してリリースノートを書ける機能

このリリースノート機能は、パーマネントリンクもあるし、Markdownも書けるし、画像もアップロードできるし、絵文字でリアクションもできるし、RSSもあるし、通知機能もあるし、GitHub Discussion連携すればコメントも書けるし、全文検索もついてくるしこれブログとして使えるんじゃないかと思いました。

なるほど、こんな使い方もできるんですね〜

2023-01-09

メンテナ記 | setup.py中のnameを変えたらいかんぜよ

はじめに

夜明けは目の前ぜよ、nikkieです¹。

先月（2022年12月）に、コラボレータをしているSpeechRecognitionのv3.9.0をリリースしました🎉

リリースであった一幕をアウトプットします。

はじめに
目次
リリース作業の前提
- メンテナです！
- PyPIの認証にAPIトークンを使います
buildしたファイルをuploadしようとしたらエラー
setup関数のname引数に指定した文字列、変わってる〜！！
- name引数の指定変更の経緯を（できる範囲で）確認
エラーが送出された原因を理解する試み
- nameを変えたらなぜエラー？
- PyPIの「プロジェクト」という概念
終わりに

リリース作業の前提

メンテナです！

オーナーのUberiさんにnikkieをSpeechRecognitionのメンテナに設定していただきました。
PyPIでは共同編集者（collaborators）に2つのロールがあり、「メンテナ」ロールを付けてもらったということです。

ヘルプより：PyPI上のプロジェクトで使用可能な共同編集者の役割には、何がありますか？

メンテナ: パッケージのリリースのアップロードができる。共同編集者の追加、ファイル・リリース・プロジェクトの削除はできない。

PyPIの認証にAPI トークンを使います

ヘルプより：APIトークンを使ってPyPIで認証するにはどうすればよいですか？

We strongly recommend you authenticate with an API token where possible.

(nikkie訳) どこでもAPI トークンで認証するのを強くオススメします

上記のリンク先に日本語で手順が記載されています（ぜひやりましょう！）。
私は、PyPIに置いているライブラリごとにAPI トークンを作っています。

PyPIへのアップロードでは、以下のようにAPI トークンを指定しました。

twine upload -u __token__ -p pypi-接頭辞を含むトークン値 dist [dist ...]

buildしたファイルをuploadしようとしたらエラー

2022年1月のみんなのPython勉強会でaodagさんが発表された手順をベースにしています。

みんなのPython勉強会#77 パッケージングしよう from Atsushi Odagiri

手短に言うと

python -m build .
twine upload

です（これだけで済むなんて、ホント便利になりましたよね）。

これを実行したところ、2でエラー²🙀

The name isn't allowed

ただ、これまでのコラボレータ活動からなんとなく思い当たるところがありました。

setup関数のname引数に指定した文字列、変わってる〜！！

ドキュメントとしては以下のあたりの話になります（setup.pyの他、setup.cfgやpyproject.tomlとの対応も記載されています）。
https://setuptools.pypa.io/en/latest/userguide/quickstart.html#basic-use

buildしてできるファイルの名前はspeech-recognition-3.9.0で始まりました。
setup関数の<name引数の値>-<version引数の値>と参照されています。

一方、PyPIのページのURLやpip installではSpeechRecognitionと指定します。

結論を言えば、name引数の指定を戻し、SpeechRecognition-3.9.0で始まるファイルをbuildしたところ、uploadできました！

name引数の指定変更の経緯を（できる範囲で）確認

PR #434で修正されています。
Fixed IBM call to use api key. by chrisspen · Pull Request #434 · Uberi/speech_recognition · GitHub

その中の1コミット：Fixed package name. · Uberi/speech_recognition@3446b13 · GitHub

PR #434は機能追加というメリットがありつつも、それを打ち消すように感じられるほどコードベースに混乱を招いている³（デメリット）フシがあります⁴。
「Fixed package name.」というコミットですが、「これでパッケージがリリースできるかは当時は未確認で、結果的にバグが混入してしまったということなのかな」と私の中では整理しています。
（PyPIのURLをキャメルケースからケバブケースに変えようという意図でfixなのかな）

エラーが送出された原因を理解する試み

nameを変えたらなぜエラー？

リリース時はuploadを通すことを優先していて完全なエラーメッセージを控えられていません。
アウトプットにあたり、エラーの原因を調べたところ、PyPIのヘルプの以下ではないかなと考えています。

https://pypi.org/help/#project-name

The project name is too similar to an existing project and may be confusable.

(nikkie訳) プロジェクトの名前が既存のプロジェクトに類似しすぎており、混同させやすい（ため、その名前が使えない）

SpeechRecognitionとspeech-recognition、編集距離は小さめなので、類似していると判定されたのではないかと考えます。

なお、SpeechRecognitionは5年ほどリリースが止まっていたため、その間にfork版がPyPIにリリースされています⁵。

nameにforkと付けることで類似しているとは判定されなくなる面もあるのかもしれないですね。

PyPIの「プロジェクト」という概念

PyPIの用語集を引きます（ありがたいことに日本語で読めるんです！）。
https://packaging.python.org/ja/latest/glossary/#term-Project

Pythonにおけるプロジェクトは、 :term:`PyPI <Python Package Index (PyPI)>`に登録される一意の名前を持っていなければなりません。

今回の経験から、「setup.pyのname引数に指定したのは、プロジェクトのnameと言えるのではないか」と考え始めています。
パッケージの名前はspeech_recognition⁶ですが、PyPIからはSpeechRecognitionという名前（＝プロジェクト名）でインストールします。

（ここでは深く立ち入りませんが、）pip install SpeechRecognitionでspeech_recognitionパッケージがsys.path⁷の下に配置される。
だからimport speech_recognition as srとインポートできる、ということではないかと考えます。

プロジェクト名（SpeechRecognition）とパッケージ名（speech_recognition）が完全一致していなくてもいいことの説明にもなっている記載も見つけました。

そのプロジェクトを稼働させるためにインポートされるパッケージの名前に因んでプロジェクトに名前をつけるのが普通であるという強い慣習があることを覚えておいてください。しかしながら、常にそうしなければならないわけではありません。

終わりに

SpeechRecognition v3.9.0リリースで経験したエラーから、プロジェクトという概念の理解が深まりました。
setup.pyで定義しているmetadataにはプロジェクトの設定をする項目もあるということなのかなととらえ始めています（誤解している可能性もあるので、buildやtwineやpip installでnameをどう扱っているか、どこかでガッツリ調べ尽くしたいですね）。

1日1エントリ、頻度を上げたことでちょっとしたネタでも書きやすくなっているメリットを感じていますが、他のことを劣後させざるを得ない状況にもなっています。
並行してコラボレータ活動などやっていきたい気持ちはあるので、今回は結び付けてアウトプットしてみました。

SpeechRecognitionについてはコラボレータとしてできそうなことはいくつか浮かんでいます。
もっとコードで価値を届けていく所存ですが、スターやスポンサーで支えていただけるととっても嬉しいです！

さよなら私のクラマー / alu.jp
↩
コミットメッセージに控えてありましたが、完全版ではなさそうです↩
リファクタリングの名のもとに、既存のメソッドの返り値が複数となる（タプルを返す）ように変更され、それが原因でテストが落ち続けていました（修正済みです）。ユーザが使うメソッドの挙動を変えているので、ファウラーさん（『リファクタリング』）やフェザーズさん（『レガシーコード改善ガイド』）が言っている意味での"リファクタリング"ではないですね↩
PR #434は巨大なプルリクエストになってしまっています。タイトル以上のことをガンガンやっている、単一責任違反のプルリクエストです↩
いくつもあるfork版とどう折り合いをつけていくか、これも抱えている宿題の1つです↩
__init__.pyが置かれたディレクトリ名でもあります。パッケージ名はPythonにおける名前の制約を受けますね（ハイフンが使えない、など）↩
「モジュールを検索するパスを示す文字列のリスト」 https://docs.python.org/ja/3/library/sys.html#sys.path ↩

2023-01-08

「Bootstrapでclassに指定するmdって、何？」　ブレークポイントを知り、モバイル用のレイアウトだけに余白を追加するまで

はじめに

「そこは、私の世界を変える入り口でした¹」、nikkieです。

映画『かがみの孤城』応援目的で縦書き鏡文字ジェネレータを開発しています。
その中でBootstrapの理解が深まる経験をしました。
その経験をアウトプットします。

はじめに
目次
縦書き鏡文字ジェネレータ、モバイル用のレイアウトにしたい！
col-8とcol-md-8の違いって、何？
- ブレークポイント！
- ブレークポイント指定の読み方
モバイル用のレイアウトだけで余白を入れたい
- 余白を入れる（ただし、すべてのレイアウトに適用される）
- モバイル用のレイアウトだけで余白を入れる
終わりに
P.S. Mediumってどんな端末の画面サイズなの？

縦書き鏡文字ジェネレータ、モバイル用のレイアウトにしたい！

年始に1日ハッカソンして作った縦書き鏡文字ジェネレータ。

Bootstrap 5でスタイルを当てています。
実現したい見た目は

PCの画面サイズでは2カラム構成（Canvasとボタン群を左右に並べる）
スマホの画面サイズでは1カラム構成（Canvasの下にボタン群が来る）

でした。
※お手元で見たい方は https://ftnext.github.io/flipped-letters-generator/ へどうぞ。

1日ハッカソンでここまでやりきったつもりでしたが、スマホでアクセスしても2カラム構成でした。
そのときのHTMLはこちら

<main>
  <div class="container">
    <div class="row">
      <div class="col-8">
        <!-- Canvasが来ます -->

縦書き鏡文字ジェネレータで実現したい見た目は、過去にPyCon JPスタッフ向けに作ったプロポーザルレビューアプリのテンプレート²で実現済みです³。
そのときどうやったのかなとコードを見に行くと、col-8ではなくcol-md-8と指定していました⁴。
「そうか、mdがいるのか」とHTMLを修正。
スマホの画面サイズでは1カラムとなりました！

<main>
  <div class="container">
    <div class="row">
-      <div class="col-8">
+      <div class="col-md-8">
        <!-- Canvasが来ます -->

`col-8`と`col-md-8`の違いって、何？

追加したmdがそもそも何なのかが分かっていなかった⁵ので、この機にドキュメントに当たることにしました。
※col自体や、8の方（12カラムあるうちの8つを指定）については今回は深めません

ブレークポイント！

このmdはブレークポイント（breakpoint）と呼ばれるそうです⁶。

☝️のドキュメントの中の「Available breakpoints」を読んでいくと⁷

Bootstrapには6つのデフォルトのブレークポイントがあり、grid tiers と呼ばれる 6つのデフォルトのブレークポイントが含まれています。

「Available breakpoints」にあるブレークポイントについての表が参考になります（必見だと思います！）。

6つのデフォルトブレークポイント
クラスインフィックス⁸
- None(指定なし), sm, md, lg, xl, xxl の6つ
適用される画面サイズ

col-md-8のmdは、Mediumブレークポイントを示すインフィックスなんですね！
col-8はインフィックスの指定がないのでX-Smallブレークポイントを指定している、と。

ブレークポイント指定の読み方

グリッドシステムのドキュメントの「How it works」より

そのブレークポイントとその上のすべてのブレークポイントに影響を与えます (e.g., .col-sm-4 applies to sm, md, lg, xl, and xxl).

例を見てなるほどと思いました。
col-sm-4（Smallブレークポイントのインフィックス）はSmallとSmallより上のすべてのブレークポイント（sm, md, lg, xl, xxl）を指定したことになる、と。

ジェネレータの実装は、以下のように説明できます。

col-md-8（Mediumブレークポイントのインフィックス）はMedium以上のブレークポイント（md, lg, xl, xxl）の指定
col-8（X-Smallブレークポイントのインフィックス）はX-Small以上のブレークポイント（None, sm, md, lg, xl, xxl）の指定
- これはすべての画面サイズでの指定ということだと理解しています

col-8は「すべての画面サイズで12カラム中8つ」と指定していて、col-md-8は「Medium以上の画面サイズでは12カラム中8つ」と指定（Mediumより小さい画面サイズでは指定なし）ということなんですね！
（col-8はすべての画面サイズに適用されるから、スマホの画面サイズでも1カラムにならず、2カラム構成だったわけですね）

モバイル用のレイアウトだけで余白を入れたい

col-md-8によって、スマホの画面サイズでは1カラム構成にできました。
ただ、トップの段落のまわりに余白が入らなかったり、Canvasとテキスト入力欄の間に余白がなかったり（下図）と余白を調整したくなりました。

余白を入れる（ただし、すべてのレイアウトに適用される）

1カラムのとき、Canvasとその下に来るテキスト入力欄の間（縦方向）に余白を入れることを考えます。
まず浮かんだのはCanvas（のdiv）にmargin bottomの指定でした。

<main>
  <div class="container">
    <div class="row">
-      <div class="col-md-8">
+      <div class="col-md-8 mb-5">
        <!-- Canvasが来ます -->
      </div>
      <!-- 別のdivでテキスト入力欄（など）が来ます -->

このmb-5という指定もブレークポイントが関わっています！

https://getbootstrap.jp/docs/5.0/utilities/spacing/#notation

クラスは，xs の場合は {property}{sides}-{size} という形式で sm、md、lg、xl、xxl の場合は {property}{sides}-{breakpoint}-{size} というクラスになります。

mb-5は、X-Small以上の画面サイズ（＝すべての画面サイズ）でsize 5のマージンをbottomに入れる指定ということですね。
これで余白は追加されたのですが、「この余白はPCの画面サイズでは不要なんだけど、すべての画面サイズに入れるしかないのかな」と少しもやもやが残りました。

モバイル用のレイアウトだけで余白を入れる

ドキュメントを参考に、以下のクラス指定でやりたいことができました！

# https://github.com/ftnext/flipped-letters-generator/blob/46495b09b20300036260f03a25c49e174722a782/src/index.html#L52
<main>
  <div class="container">
    <div class="row">
-      <div class="col-md-8 mb-5">
+      <div class="col-md-8 mb-5 mb-md-0">
        <!-- Canvasが来ます -->
      </div>
      <!-- 別のdivでテキスト入力欄（など）が来ます -->

すべての画面サイズではなく、スマホの画面サイズだけで余白が入ります（ブラウザの開発者ツールで確認）

どのようにこの指定に至ったのかを明かします。
ドキュメントを読む中でヒントに気付きました。

ブレークポイント指定の読み方を知ったドキュメントには以下のようにあります：

ブレークポイントごとにコンテナやカラムのサイズや振る舞いを制御することができます。

🤔（sm以下では余白あり、md以上では余白なしって指定できる、ってこと？でもどうやるんだろう）

余白（マージンやパディング）の指定のドキュメントで、size 0の説明が目を引きました

0 - for classes that eliminate the margin or padding by setting it to 0

この2つのインプットからひらめいた仮説が「ブレークポイントを2つ指定すればいいのでは」というもの。

mb-5はX-Small以上の画面サイズ（＝すべての画面サイズ）でCanvasのbottomにsize 5のマージン
mb-md-0はMedium以上の画面サイズでCanvasのbottomにsize 0のマージン（＝マージンなし）
- Medium以上の画面サイズではこちらを優先

つまり

X-Small以上Medium未満の画面サイズ（None, sm）では、bottomにsize 5のマージン
Medium以上の画面サイズ（md, lg, xl, xxl）では、bottomにマージンなし

これを実装して試してみると、想定したとおりに動きました🙌

終わりに

意味を理解せずに使っていたcol-md-8（ブレークポイント）について、何を指定しているのか説明できるまで理解を深められました。
理解が深まったことで、「あるブレークポイントまでは〜〜で、そこからは〇〇」のようなレイアウト指定の仕方にも気付きました！

Bootstrapのブレークポイントという道具についてはどう使っているかが言語化できるようになりました。
「魔法だな〜」と感じて使っている状態（＝道具に使われている状態）はだいぶ脱せたかなと思います。
一方、ブレークポイントがラップしているCSSの仕組みなど、まだまだ魔法と感じる部分は多いです。
そのあたりは今後の伸びしろとして、チャンスが来たときにキャッチアップしたいと思います。

One more thing...
nikkieにとってはBootstrapの理解を深める機会にもなった映画『かがみの孤城』、皆さま、ぜひ観に行ってください〜！

P.S. Mediumってどんな端末の画面サイズなの？

ブレークポイントのドキュメントの中の「Available breakpoints」の表、書いてあるピクセル数が具体的な端末と結び付けられませんでした。

Medium md ≥768px

Bootstrap 4の情報ですが、以下が参考になりました。
Bootstrapのバージョンによってブレークポイントやインフィックスは変わるかもしれませんが、ピクセル数と端末の対応は変わらないだろうと、参考にしています。
（Bootstrap 5のドキュメントは探しきれていないので、ご存じの方ぜひ教えてください）

タブレット端末など 768px 以上

sm (Small:スマホサイズ)
md (Medium:タブレットサイズ)

そして、こちらのとほほさんのBootstrap 4入門でも、画面サイズに応じた多段階の指定を紹介されていますね！
（<div class="col-sm-4 col-md-8">B</div>）

なお、とほほさんはBootstrap 5入門も公開されています！すごい👏

↩
静的サイトとしてアーカイブしたページが https://pyconjp.github.io/pycon.jp.2021.review/201001.html で見られます↩
Bootstrap（当時は4）については、時間の制約から理解を深めることをせずに、Exampleを真似て実装しました↩
https://github.com/pyconjp/pycon.jp.2021.review/blob/352ec3f2ac5d9473ed723882597287f23f4e79ab/reviewsite/templates/review/detail_proposal.html#L11 ↩
分かっていたら「col-8と指定すればどんな画面サイズでも2カラムになる」と勘違いしないと思うのです↩
Bootstrapのドキュメント、日本語で読めるようになっていてありがたい限りですね。プロポーザルレビューアプリ実装時は英語だったと記憶しています↩
grid tiersは追っていませんが、https://getbootstrap.jp/docs/5.0/layout/grid/#grid-tiers のあたりではないかと思われます。「グリッド層の数をカスタマイズすることもできます。」↩
頭に付くのがプレフィックス（接頭辞）、末に付くのがサフィックス（接尾辞）なので、中に付く＝インフィックス（漢字をあてるなら、中置辞？）と理解しています↩

2023-01-07

週末読書ログ | ふりかえりをさがして

はじめに

梅雨ちゃんと呼んで🐸、nikkieです。

ふりかえり（retrospective）について、週末にインプットしました。
現時点のバックアップとしてアウトプットします。

はじめに
目次
nikkieのふりかえり、これまで
初手はケント・ベック『エクストリームプログラミング』
ふりかえりといったらこの本！『アジャイルレトロスペクティブズ』
『アート・オブ・アジャイルデベロップメント』
- 初版（5.5 ふりかえり）
- 2版（英語）
ふりかえりについてのその他のリソース
ふりかえりについての気付き
- すぐ先に「次回がある」と考えられる！
- ふりかえりに関する情報源で満たした
終わりに
P.S. ふりかえりをテーマに読み漁った背景

nikkieのふりかえり、これまで

ふりかえりの経験は3年半ほど。
XPを実践するユーザベースの開発チームに加わったのをきっかけに、イテレーションのふりかえりに参加したり、ファシリテータをしたりしています。
これまでは経験豊富なファシリテータのみようみまねでやってきました（『アジャイルレトロスペクティブズ』を最初にパッと読んだくらいです）。

やや前の記事ですが、開発チームのふりかえりの様子は以下のような記事があります！

初手はケント・ベック『エクストリームプログラミング』

ふりかえりについての記述をXPの提唱者ケント・ベック氏の著書（第2版¹）で探すと、原則²の中にありました。

5.7 ふりかえり（Reflection）より

フィードバックを最大化するには、XPチームのふりかえりを行動と組み合わせるべきである。(Kindle の位置No.795-796)

氏の言は非常に簡潔なので、他の本にあたって解像度を上げていきます。
ここでretrospectiveではなくreflectionという語が使われているのも面白いですね（retrospectiveはプラクティスを指す使われ方が多いからかな？）

ふりかえりといったらこの本！『アジャイルレトロスペクティブズ』

最初に読んだ本を改めて手に取ります。
5つのフェーズからなるふりかえりの構成が示されます（第1章）。

場を設定する
データを収集する
- データとは、事実と感情
アイデアを出す
何をすべきかを決定する
レトロスペクティブを終了する

各フェーズのアクティビティについても豊富に紹介されていますね。

『アート・オブ・アジャイルデベロップメント』

イテレーションのふりかえりについて扱われています。

初版（5.5 ふりかえり）

著者のJames Shoreさん流のふりかえりの構成が示されます³：

ノーム・カースの最優先条項⁴
ブレインストーミング
- 6つの領域を用意
- イテレーションでの出来事やブレインストーミングで出たアイデアを書き出す（領域に貼り出す）
ミュートマッピング
- 誰も話さずに関連する付箋を近くに置く（関連しない付箋は互いに離す）
ふりかえり目標
- チームをよりよくするため、チーム全体が次のイテレーションのあいだに努力する目標を決める
- 具体には踏み込まず、大まかな方針のアイデアを出す

2版（英語）

ふりかえりの構成がちょっと更新されていました。
初版から引き続き『アジャイルレトロスペクティブズ』を踏襲しつつ、わずかに変更したものを紹介していると理解しています。

ノーム・カースの最優先条項
ブレインストーミング
ミュートマッピング & ドット投票
洞察を生み出す
- 会話ベースでアイデアを探索する
- 例：「なぜこの付箋の集まりをカイゼンが最も重要として選択したのか」
ふりかえり目標

ふりかえりについてのその他のリソース

びばさん『ふりかえりガイドブック』

技術書典やQiitaなど精力的にふりかえりについて発信されているびばさんの本！
『アジャイルレトロスペクティブズ』と並んでまず読む本となりそうな印象を受けています。

ノーム・カース『Project Retrospectives: A Handbook for Team Reviews』（英語）

Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks) (English Edition)

作者:Kerth, Norman L.
Addison-Wesley Professional

Amazon

イテレーションよりも長い期間を扱うレトロスペクティブ（特にプロジェクトレトロスペクティブ）について、『アジャイルレトロスペクティブズ』でこの本が案内されました。
2001年の本ですが、プロジェクトのレトロスペクティブについては決定版とも言えるような知見があるようで大変気になっています。

『アジャイルふりかえりから価値を生み出す』

今回インプットする中で存在を知った一冊。

日本でいう「ふりかえり」というプラクティスで使えるアイディアを実践的にまとめた本です。このミニブックの日本語版がでました！

このエントリで紹介した複数の本には平鍋さんが関わっていらっしゃって、すごい方だなと改めて思いました。

ふりかえりについての気付き

気づいたこと2点をアウトプットします。

すぐ先に「次回がある」と考えられる！

『アート・オブ・アジャイルデベロップメント』を読んで目からウロコだったのが「常に来週がある」という考え方。
イテレーションの期間を1週間とすると、1週間後に次のふりかえりがあるので

ふりかえり目標を考えるまとまりが投票で決まらなければ、コイン投げで決めてしまう
- 来週もふりかえりをするんだ。重要な問題であれば、また出てくるだろう。(p.101)
重要と認識している人が少数のために投票で選ばれなくても、重要であれば来週（やその後）のふりかえりで再度現れる
ふりかえりに時間がかかりすぎている場合も、来週があると考えて対処する

このようにふりかえりに関する様々なことに対処できます。
ふりかえりは1回限りでなく、イテレーションのたびに繰り返し行われるもので、「一度のふりかえりに肩肘張って無理に詰め込みすぎることもないんだな」と気付きました。

ふりかえりに関する情報源で満たした

ふりかえりに関しては、私の中で「どんな本を参照すればいいんだろう」という疑問は完全に引っ込みました。
むしろ、「こんなにたくさんの情報源、参照しきれないよ〜」という状態です。

今回はざっくりと考え方を追うのを優先しています。
具体のアクティビティに関しては、『アジャイルレトロスペクティブズ』や『ふりかえりガイドブック』で解像度を上げていくとよさそうに考えています。

終わりに

ふりかえりについての読書ログと、そこからの気付きのアウトプットでした。
みようみまねでやってきましたが、書籍（理論）を参照して、腑に落ちた点が多かったり、「わかっていなかったな」という伸びしろに気づいたり、経験値が学びに昇華された感覚です。

思うに、誰しもアジャイルの旅の途中にいる⁵。
得た知見を元に、実践する日々！
XPの旅は続くのです。

P.S. ふりかえりをテーマに読み漁った背景

agile_devsのビデオ鑑賞会がきっかけです。
1/7(土)はRetrospectiveがテーマでした。

鑑賞会で教えていただいたのですが、今年もふりかえりカンファレンスが開催されるそうです！（4/8 🐸）

エクストリームプログラミング

Amazon

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

Amazon

アート・オブ・アジャイルデベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)

作者:James Shore,Shane Warden
オライリージャパン

Amazon

（『アート・オブ・アジャイルデベロップメント』はオライリーさんでPDFが現実的かもしれません）

アジャイルなチームをつくるふりかえりガイドブック始め方・ふりかえりの型・手法・マインドセット

作者:森一樹
翔泳社

Amazon

『アート・オブ・アジャイルデベロップメント』2版によると、初版にはなかったそうです。https://www.jamesshore.com/v2/books/aoad2/improvement の注1です↩
XPの価値とプラクティスをつなぐ（橋渡しする）のが原則という理解です↩
初版の英語版は公開されています。James Shore: The Art of Agile Development: Retrospectives ↩
「この会では、プロジェクトの全員が置かれた状況下でベストを尽くした、ということを疑ってはならない」 プロジェクトの「ふりかえり」 -- Retrospectives by Norm Kerth：An Agile Way：オルタナティブ・ブログ（『アート・オブ・アジャイルデベロップメント』ではより詳細な訳です）↩
恥ずかしいセリフ禁止！↩

2023-01-06

新しい概念を最小限にして、自作VS Code拡張をMarketplaceに公開する

VS Code

はじめに

「今はまだ勇気も自信もぜんぜんだから」、nikkieです。

Visual Studio Code、通称「VS Code」の拡張自作シリーズです。
自作した拡張をMarketplaceに公開できたのですが、「もし自分がもう一度最初からやるなら、新しい概念に慣れるためにこうやればよかったんじゃないかな」という最小手順をアウトプットします。
ドキュメントに沿ってやりきった後、ドキュメントを眺めていたら記載がありました。

はじめに
目次
前回までの自作VS Code拡張！
VS Code拡張をMarketplaceに公開するためのドキュメント
新しい概念を最小限としてVS Code拡張を公開！
1. vsceコマンド
- パッケージにする際の注意点
- 動作環境 (2023/01/12 追記)
2. Visual Studio Code Marketplace
- publisherを作る
- 作成したpublisherにvsixファイルをアップロード
終わりに
P.S. vsixファイルについて

前回までの自作VS Code拡張！

VSCode Conference Japan 2021のハンズオンテキストを元に、自作拡張を開発しています🎀

この拡張のE2Eも書けた¹ので、いよいよ公開することにしました。

VS Code拡張をMarketplaceに公開するためのドキュメント

公開手順は「Publishing Extensions」という情報量豊富なドキュメントに記載されています。

これに沿って自作拡張を公開までできた²のですが、新しい概念が複数登場したため私には大変な道のりとも感じました。

vsceコマンド
Azure DevOpsの組織
- personal access token
Visual Studio Code Marketplaceのpublisher

このドキュメントにはvsceコマンドを使って自作拡張を公開する方法が網羅されているのです。
ですが、その中に新しい概念を最小限として公開する方法も紹介されていたんです！

新しい概念を最小限としてVS Code拡張を公開！

Alternatively, you can package the extension (vsce package) and manually upload it to the Visual Studio Marketplace publisher management page.³

(意訳) あるいは、vsce packageコマンドで拡張をパッケージし、Visual Studio Marketplaceのpublisher管理ページに手動でアップロードしてもよい

この方法では登場する新しい概念は2つで済みます。

vsceコマンド
Visual Studio Code Marketplaceのpublisher

1. `vsce`コマンド

npm install -g @vscode/vsceでインストールします⁴。
Node.jsの環境が必要です。

カレントディレクトリが自作拡張の開発ディレクトリとして話を進めます（package.jsonなどがあるディレクトリです）。

自作拡張をパッケージにするコマンドはvsce packageです。
vsce lsでパッケージにするファイルの一覧を確認できます。

vsce packageが正常終了すると拡張子がvsixのファイルができています。
例：hoge-fuga-0.0.1.vsix
これがパッケージになったVS Code拡張です。

パッケージにする際の注意点

YeomanでスキャフォールドしたREADMEのままではエラーとなる
- Make sure to edit the README.md file before you package or publish your extension.
- README.mdを編集する（タイトルだけ残すなど、大きくコンテンツを削った）
- ref:
package.jsonにpublisher ID（後述）の記載が必要
- "publisher": "publisher ID",
- 未記載だと後述のアップロードでエラー
ハンズオンのテキストに沿っている場合、package.jsonのnameを変える
- Marketplaceでnameが重複すると、後述のアップロードでエラーとなる

この記事では立ち入りませんが、Marketplaceで存在感を出す方法として、Marketplace integrationにいくつかのファイルのtipsが紹介されています。

動作環境 (2023/01/12 追記)

node v16.14.2
npm 8.5.0
vsce 2.11.0

2. Visual Studio Code Marketplace

ブラウザを操作してvsixファイルをアップロードします。

まず https://marketplace.visualstudio.com/manage からログイン（私はMicrosoftアカウントを使いました）。

publisherを作る

ログインした後に表示されるページでpublisherが作れます。
publisherとは「Visual Studio Code Marketplaceに拡張を公開できる識別子 (A publisher is an identity who can publish extensions to the Visual Studio Code Marketplace.⁵)」です。

「Create publisher」から作りましょう。
必須項目のNameを入力するとIDも同じ値になりました（Basic informationの箇所）。

作成したpublisherに`vsix`ファイルをアップロード

作成したpublisherを選択し、「New Extension」-> 「Visual Studio Code」と選択します。
パッケージしたvsixファイルをアップロードすると処理され、エラーがなければMarketplaceに公開されます！
あなたの作った拡張を世界に公開！

私にはわかりにくかったのですが、Extensionsの各行は右クリックすると、AvailabilityをPublic / Unpublishedと切り替えられます（Nameの…（More Actions…）と同様のメニューです）。

終わりに

新しい概念を最小限にしてVS Code拡張を公開する方法を共有しました。
vsceコマンドでパッケージし、それをpublisherのExtensionとして手動アップロードできます。

私の意見では、いままでやったことがないことをやるときは新しい概念が1つが一番やりやすいです。
新しい概念が2つ3つとあると、難易度が一気に跳ね上がります（うまくいかなくなり、途中で諦めることになるかもしれません😢）。
「Publishing Extensions」のドキュメントは情報量が豊富ですが、新しい概念が多く、私にはハードルが高い内容でした。
いままでやったことがないことをやるとき、新しい概念が少ない方法があるなら、私はそちらをオススメします。

なお手動アップロードは初めての方にはオススメですが、概念に慣れた後は「Publishing Extensions」に沿うのがオススメです。
この記事では説明していない「Azure DevOps」によって、vsceコマンドだけで拡張が公開 できちゃいます！（アウトプットはまたの機会に）

P.S. `vsix`ファイルについて

vsixファイルさえあれば code --install-extension my-extension-0.0.1.vsix でインストールできます！⁶
インストールできるかの確認にもよさそうですね

VS Codeの拡張のメニューにも「Install from VSIX...」があります⁷。

そしてインストールした拡張は、例えばmacOSなら~/.vscode/extensionsに置かれているんです！⁸

2023-01-05

読書ログ | #ミノ駆動本 13章「モデリング」とDeveloper eXperience Day 2021

設計

はじめに

リンクスタート！ nikkieです。

『良いコード／悪いコードで学ぶ設計入門』（通称ミノ駆動本¹）の読書ログです。
13章「モデリング」を読んだところ、ミノ駆動さんの過去の登壇と結び付いて刺激的でした。
ここにログを残します。

はじめに
目次
ミノ駆動本 13章「モデリング」
2021年4月 Developer eXperience Day 2021
13章「モデリング」とクソコード動画「Userクラス」解説とのつながり
理解したこと箇条書き
エヴァンス本から、深いモデル
「Userクラス」で風刺されたこの構造、他のクソコード動画でも見たような…
終わりに
P.S. その1 ミノ駆動本_読書pyの予習
P.S. その2 「変換能力」

ミノ駆動本 13章「モデリング」

公開されている目次を引用します。

13 モデリング ―クラス設計の土台―

13.1 邪悪な構造に陥りがちなUserクラス
13.2 モデリングの考え方とあるべき構造
13.3 良くないモデルの問題点と解決方法
Column クソコード動画「Userクラス」
13.4 機能性を左右するモデリング

13章を読んで、ミノ駆動さんの過去の登壇から思い出されたものがありました。

2021年4月 Developer eXperience Day 2021

2021/04/10にオンライン開催されたDeveloper eXperience Day 2021。
ミノ駆動さんは「クソコード動画『Userクラス』で考える技術的負債解消の観点」という発表をされています。

多くのサービスで技術的負債になりやすい筆頭格として、Userクラスがあります。本セッションでは、Userクラスの負債により引き起こされる弊害を描いた、風刺動画を上映します。Userクラスでどんな課題が生じるのか、なぜ負債化しやすいのか、そして負債解消に必要な観点についてお話致します。

クソコード動画や、発表のアーカイブ、発表資料は上記サイトから見られます。

また、logmiさんに書き起こしがあります。

発表資料は以下の構成です（レジュメ(slide=3)参照）。

劇中の問題
システムとは何か
情報システム開発とモデリング
Userクラスが抱える問題
モデリング解決編
モデリング発展議論

13章「モデリング」とクソコード動画「Userクラス」解説とのつながり

気づいた対応を、ミノ駆動本の目次にネストする形式で示します（Developer eXperience Day 2021の資料は斜体にしました）。

13.1 邪悪な構造に陥りがちなUserクラス（ & Column クソコード動画「Userクラス」）
- 劇中の問題
13.2 モデリングの考え方とあるべき構造
- システムとは何か
- 情報システム開発とモデリング
13.3 良くないモデルの問題点と解決方法
- Userクラスが抱える問題
- モデリング解決編
13.4 機能性を左右するモデリング
- モデリング発展議論

この対応関係に気づけたのは私にとって大きかったです。
何がよかったかと言うと、Developer eXperience Day 2021の発表を元々聞いていたので、ミノ駆動本の13章が読みやすくなりました。
同じ話をプレゼンテーションの構成でも書籍の構成でもインプットとなったので、読書中は「一回インプットしたことあるから分かる！分かるぞ」と心地よい体験でした。

理解したこと箇条書き

ミノ駆動本のキーワードは「目的」っぽい！
- システムは目的達成手段
- モデルはシステム（目的達成手段）の一部
- 👉モデルも目的達成手段
  - Developer eXperience Day 2021では、ミクロなシステム
- 目的を表現した名前
  - 10章「名前設計」につながる！
プログラミングって概念操作していたってことか！
- 情報システム＝コンピュータを使ったシステム
- 現実世界の概念を仮想世界（コンピュータ上）へ変換している
- コンピュータによって概念操作を高速化
- 概念操作を認識できたことで、少し上の視座から日夜やっていることを捉えられそうな感覚！

エヴァンス本から、深いモデル

13.4で「深いモデル」が導入されます（Developer eXperience Day 2021では、発展議論）。
ソースは『エリック・エヴァンスのドメイン駆動設計』のおそらく8章「ブレイクスルー」。
過去のミノ駆動さんの発表で紹介された「シェアパイ」の例（深いモデルの例）が登場する章です。

深いモデルは、一度に1オブジェクトという小規模なリファクタリングが連続して行われることで、徐々に姿を現すことができるのだ。(エヴァンス本 Kindle版 p.196)

開発していて突如「今浮かんだこの設計、既存の設計とぜんぜん違うけどうまくいくじゃん」となる経験はしたことがあって、これが「ブレイクスルー」！
そして、これはリファクタリングを重ねて、理解が蓄積される（エヴァンス本の言い回しでは、開発者の視界が明確になる）ことで起こる！

リファクタリングを重ねた先に、深いモデルに至る出来事があるのか！

「Userクラス」で風刺されたこの構造、他のクソコード動画でも見たような…

クソコード動画Userクラスを見返したところ、巨大なクラスの左右に複数のクラスが並ぶ構造、どこかで見たぞ。
👉直近の一枚岩モデルでした！
お商品クラスの両側に、たくさんのおクラスがつながってますわ〜

ミノ駆動 on Twitter: "クソコード動画「一枚岩モデル」 #AWSDevDay https://t.co/NwfOmXWy6F" / Twitter

終わりに

ミノ駆動さんの過去の登壇との関連を見出しながら13章「モデリング」を読んだログでした。

ミノ駆動本の13章「モデリング」については書籍と同様の主張に書籍以外のメディアでも触れられます。
気になった方はお好きなメディアでぜひ触れてみてください！

良いコード／悪いコードで学ぶ設計入門―保守しやすい　成長し続けるコードの書き方

作者:仙塲大也
技術評論社

Amazon

P.S. その1 ミノ駆動本_読書pyの予習

1/6(金)開催、ミノ駆動本_読書py事前もくもくの一環として13章を読んだのでした〜

P.S. その2 「変換能力」

13.4で出てくる「変換能力」

世の中の優れたしくみは、優れた変換能力を有しています。(ミノ駆動本 Kindle 版 p.452).

思い出したのは『アイの歌声を聴かせて』のAIシオンさん。
サトミを幸せな状態に"変換"しようとするシオンさん、尊すぎるでしょ…

機械学習のブレイクスルーもあって、コンピュータで変換できるものは一気に増えていますね（2022年は画像生成など）。
アイうたで描かれた世界も手の届くところまで来ているような気がしますね。

過去にも何度か取り上げています。「ITエンジニア本大賞 2023」で投票したおすすめの本の1冊は『良いコード／悪いコードで学ぶ設計入門』です #itbookaward #ミノ駆動本 - nikkie-ftnextの日記 ↩

はじめに

目次

映画『かがみの孤城』とは

バリアフリー音声ガイドが超オススメ

丸の内ピカデリーさんでの鑑賞がオススメ

5週目（1/20(金)〜）、6週目（1/27(金)〜）、入場者プレゼントあります！

終わりに

P.S. こころちゃんかわいい

はじめに

目次

前提；3.9.0のリリースは思っていたより大変でした

伝えたいこと：2022年12月のnikkieへ

リリースを書いての所感

終わりに

P.S. 達人のリリース活用術

はじめに

目次

リリース作業の前提

メンテナです！

PyPIの認証にAPIトークンを使います

buildしたファイルをuploadしようとしたらエラー

setup関数のname引数に指定した文字列、変わってる〜！！

name引数の指定変更の経緯を（できる範囲で）確認

エラーが送出された原因を理解する試み

nameを変えたらなぜエラー？

PyPIの「プロジェクト」という概念

終わりに

はじめに

目次

縦書き鏡文字ジェネレータ、モバイル用のレイアウトにしたい！

col-8とcol-md-8の違いって、何？

ブレークポイント！

ブレークポイント指定の読み方

モバイル用のレイアウトだけで余白を入れたい

余白を入れる（ただし、すべてのレイアウトに適用される）

モバイル用のレイアウトだけで余白を入れる

終わりに

P.S. Mediumってどんな端末の画面サイズなの？

はじめに

目次

nikkieのふりかえり、これまで

初手はケント・ベック 『エクストリームプログラミング』

ふりかえりといったらこの本！『アジャイルレトロスペクティブズ』

『アート・オブ・アジャイル デベロップメント』

初版（5.5 ふりかえり）

2版（英語）

ふりかえりについてのその他のリソース

びばさん『ふりかえりガイドブック』

ノーム・カース『Project Retrospectives: A Handbook for Team Reviews』（英語）

『アジャイルふりかえりから価値を生み出す』

ふりかえりについての気付き

すぐ先に「次回がある」と考えられる！

ふりかえりに関する情報源で満たした

終わりに

P.S. ふりかえりをテーマに読み漁った背景

はじめに

目次

前回までの自作VS Code拡張！

VS Code拡張をMarketplaceに公開するためのドキュメント

新しい概念を最小限としてVS Code拡張を公開！

1. vsceコマンド

パッケージにする際の注意点

動作環境 (2023/01/12 追記)

2. Visual Studio Code Marketplace

publisherを作る

作成したpublisherにvsixファイルをアップロード

終わりに

P.S. vsixファイルについて

はじめに

目次

ミノ駆動本 13章「モデリング」

2021年4月 Developer eXperience Day 2021

13章「モデリング」とクソコード動画「Userクラス」解説とのつながり

理解したこと箇条書き

エヴァンス本から、深いモデル

「Userクラス」で風刺されたこの構造、他のクソコード動画でも見たような…

終わりに

P.S. その1 ミノ駆動本_読書pyの予習

P.S. その2 「変換能力」

PyPIの認証にAPI トークンを使います

`col-8`と`col-md-8`の違いって、何？

初手はケント・ベック『エクストリームプログラミング』

『アート・オブ・アジャイルデベロップメント』

1. `vsce`コマンド

作成したpublisherに`vsix`ファイルをアップロード

P.S. `vsix`ファイルについて