お気持ちの表明

思考を雑に外出していきます

脂肪吸引のお気持ちメモ

この記事は、学術バーQ・Communicative Bar & Cafe HANABI Advent Calendar 2025 の15日目の記事です。

脂肪吸引をやろうとしている。 この話をすると「いや、そんな太ってないやんけ。」という反応をされがち。 まあ私が気になるから100万近い金をぶちこもうとしているのだが、お気持ちを聞かれすぎたので言語化してみる。

人生で腹が平らだった時期がないので体験したい

小さい頃は丸々太っていたが、身長が伸びて外見上細身に見える感じにはなってきた。 だが、服から見える四肢が細いだけで、お腹周りはずーっとラブハンドルがある感じだ。 内臓脂肪は運動や食事制限でである程度落とせているが、皮下脂肪はしぶとく残っている。 ダイエットとして運動・食事制限は定期的にやったり、日常の摂取カロリー量は気をつけているが、一向に腹が平らにならない。

そもそも「腹が平らではない」という人間は食事が好きなので、ダイエットが苦痛だ。 趣味を我慢しても、いつまでたっても「腹が平らになる」というゴールにたどり着けない。 我慢が足りないのだろうが、美味しいご飯はたくさんあるし、我慢もしてられない。

もう私としてはダイエットの頑張りパワーが尽きているので、課金で吹き飛ばせるなら吹き飛ばしたい。

あと、脂肪吸引すると腹部の脂肪細胞の総数が減るから、お腹周りが丸々太る可能性が低くなるのが良い。 かわりに別の箇所に脂肪が蓄えられることになるんだろうが、お腹よりは許せるきっと.....。

自分の持ってる金を自己投資にぶっこめる時期がそろそろ終わり

私は最近結婚して、子どもの予定もある。 結婚してからもそうだが、自分の給与の適用先が、どんどん自分から家族に移っていってる。 子どもが生まれたら、きっと経済的にも子どもの優先順位が上がって、自分だけにメリットがあるお金や時間の使い方に躊躇する時期がやってくると思っている。 そう考えると、今のタイミングが自分のためにお金や時間をぶっとばしやすい最後の時期になるかもしれないと思っている。 なので、お金が足かせで実行に移せていない自分のやりたいことがあるなら、ぶっこむべきだなという判断になった。

父親の同一特徴を除外したい

私にはクソゴミな父親がいて、離婚している。 私は常にそのクソゴミな父親の対比を取る反面教師な人生を送っている。 その反面教師の観点のひとつに「デブ」がある。 「デブ」という観点を破壊するためにも、脂肪吸引はすごく役立つと思っている。

...と書いてるとすんごい執着がある気がするけど、学術バーQで「なぜお前は脂肪吸引をするのだ」と問を建てられまくって、他者に説明可能な要素をひねり出してたら観点として出てきたという感じなので、そんな深刻ではない。 これと似た思考で「ハゲ」も破壊する予定があり、来年は自毛植毛してくる予定になっている。


そんなわけで、年末余ってた有給使って仕事早めに締めて、年末にかけて家でダウンタイムを過ごそうと思っている。 「手術談まとめてnoteで手術代稼ごうぜ!」というネタ提供も受けたので、そのうち詳細に書いてnoteで身売りしようと思います。

放送大学、学術バーQ、道具屋の話

この記事は、学術バーQ・Communicative Bar & Cafe HANABI Advent Calendar 2025 の10日目の記事です。

最近の振り返りと、ジャーナリングみたいな記事です

放送大学に入学して4年経った

色々あって、小さい頃から他人の思考過程の考えるのがライフワークと化している感じだった。ただ、同じぐらい「ものづくり」も好きだったのと、通いやすさから高専に進学。社会人になってからも、心理学系の本を読んだりして、興味はずっとあった。

ソフトウェアエンジニアとして働いてからは、この職業は単にプログラムを組むだけが仕事ではないなあと思った。「プログラムを組む」は、「具体化された問題の解決方法」のひとつを自動化し、コンピュータ上で誰でも発動できる状態に落とし込む作業だと思っている。「具体化された問題の解決方法」の定式化が正しいか、選択した解決方法が正しいかなどを考えると、掘り下げるところはたくさんある。「具体化された問題の解決方法をプログラムとして具体化する」の掘り下げを進めると、その前段の問題や周辺環境についての認知や手入れが必要になりがちで、プログラミングの知識だけでなく、認知科学系や人文科学系な知識や思考が必要だなあとなってきた。

そんなわけで、社会人になってからも認知科学系や人文科学系の本を読んでいた。だけど、勉強しているだけじゃなくて、資格みたいな他者に証明可能なものがあったら良いなあと思った。そんなとき、豆腐さんと同じコミュニティで放送大学が流行っていた(?)のを見かけて、その流れで認定心理士のことを知った。高専(専攻科)まで出ていて学位は持っていたので、心理学系の単位を一通り取って申請すればもらえるとわかり、「取るぞ!!!」となった。1学期で2教科ぐらいのペースで取っていたが、4年通ってそろそろ所定単位数を満たせそう。

www.ouj.ac.jp

最近、学術バーQに行きがち

こんな文脈もあり、学術バーQ でも、それ系のイベントがあったときは聞きに行っていた。 最近は関心領域と近いイベントがめっちゃ増えた気がしていて、月2ぐらいは最低行ってる。

最近は、あべさんがやっている勉強会に通っている。認知科学について広く知れるし、おすすめ本情報を聞いたらたくさん教えてくれる。学術バーQには、「あちらのお客様からです」的な「イベンターに1杯奢る」システムがあるので、毎度奢りがちになっています。

x.com

講義に3回通ったらもらえる「絶対幸せになれるステッカー」もゲットした。

あと、西野さんのイベントにも行った。 出版された本の概要を読んで、読み物としても面白そうと雑に買ったけどすごく勉強になってる。 保育現場で感じた内容が詳しく書いてあって、すごく現場感を感じれて良かったです。 職場の子育てメンバーにも、子どもの観察観点としてすごくわかりやすいのでオススメしました。

x.com

www.shin-yo-sha.co.jp

www.shin-yo-sha.co.jp

おふたりのイベントに通ってから、「観察」に関する解像度がめっちゃ高まってきた気がしてる。私はソフトウェアエンジニアとして「役立つ道具」を作っている。でも、作ったものが本当に役立つかは特定の文脈や状況に依存する。作った道具を最大限役立たせるために、道具を適用する環境や文脈についての理解や調査をするための複眼的観点の幅が広がった気がしてる。

「道具屋」

最近、エンジニアリング(工学)の定義を見直したときに、「数学と自然科学を基礎とし、ときには人文社会科学の知見を用いて、公共の安全、健康、福祉のために有用な事物や快適な環境を構築することを目的とする学問」という意味があることを知った。

ja.wikipedia.org

私のソフトウェアエンジニアとしての興味は、道具を作るために必要な技能的側面が主であったと思う。でも、改めて定義を見るともう半分の要素として人文社会科学があることを再認した。スクラムマスタの文脈でよく言われる「アウトカムに注力しろ」というのは、「道具作っても、役立たなければ意味がない」という意味合いも感じていて、作ったものがちゃんと使われて役立つことはとても重要なんだなと感じている。その状況を作るためには、その環境の抱えている問題を適切に把握し、定式化し、道具化するのが大事で、そのためには認知科学や人文社会科学なスキルが必要なんだなと思っている。

最近こんな気持ちなので、エンジニアリングについて「道具を考える」側面の話と「道具を開発する」側面の話とを言語化して、来年は学術バーで発表できたらいいなーと思ってるので、来年機会があったら誰か話を聞いてくれーーーーー。

React Native におけるテキストの垂直中央揃え問題とその解決策

[!NOTE] この記事は筆者が下書きした内容をAIを活用して文章化し、筆者が監修して執筆しました。

React Native Advent Calendar 2025 10日目の記事です。

また、この記事は、先日の React Native Meetup #23 @サイバーエージェント で発表した内容を記事にしたものになります👏

speakerdeck.com


React Native でクロスプラットフォーム開発を行う際、テキストの垂直中央揃えが AndroidiOS で一致しないという問題に直面することがあります。iOS では意図したとおりに中央揃えされるのに、Android では上寄りや下寄りになってしまうということは稀によくあると思います。

本記事では、この問題の根本原因であるフォント描画方式の差異を明らかにし、プラットフォームごとに適切な対処法を提示します。

フォントには2つの高さ基準がある

テキストの垂直配置を理解するには、フォントが持つ2種類の高さ基準を知る必要があります。フォントには top/bottomascent/descent という、異なる目的で定義された高さの概念が存在します。

トップ(Top)とボトム(Bottom)は、フォントに含まれるすべての文字(アクセント記号などを含む)が占める可能性のある最大領域を示します。

アセント(Ascent)とディセント(Descent)は、文字が上下に占める標準的な領域を示します。これはフォントデザイナーが意図した、タイポグラフィ上の「高さ」を定義します。

プラットフォームによる描画方式の違い

iOS は ascent/descent を基準にする

iOSascent/descent を基準としてテキストを描画します。このため、多くの場合で追加の調整なしに適切な垂直中央揃えが実現されます。

Android は top/bottom を基準にする

Android には includeFontPadding というプロパティがあり、デフォルトで true に設定されています。この設定により、Androidtop/bottom を基準としてテキストを描画するため、iOS とフォントの高さに差分が生じます。

includeFontPaddingfalse に設定すると、Androidascent/descent を基準として使用し、iOS との整合性が取れるようになります。

なお、この includeFontPadding は元々、一部の言語で文字が切れないようにするための安全策として導入されたものです。しかし、Jetpack Compose など現代的な Android 開発では、このプロパティのデフォルト値が false に変更される傾向にあり、レガシーな機能となっています。

kaleidot.net

プラットフォーム別の対処法

Android での対処法

Android でテキストの垂直中央揃えを実現するには、3つの要素を組み合わせます。

1. includeFontPadding: false を設定

iOS と同じ ascent/descent 基準に切り替え、余分なパディングを削除します。

2. lineHeight を fontSize の 1.2〜1.5 倍に設定

includeFontPadding: false にすると文字が見切れることがあるため、Material Design Guideline に従って適切な lineHeight を設定します。

For larger type legibility using styles like title, headline, and display, we recommend a line height ratio of 1.2 times the type size.

For smaller body copy using styles like body and label, we recommend a line height ratio around 1.5 times the type size. If your line height is too tight, you’ll undermine the flow of the text. Too loose, and the lines won’t feel cohesive.

Typography – Material Design 3

3. textAlignVertical: 'center' で垂直中央揃え

Android 固有のプロパティで、テキストを垂直方向に明示的に中央揃えします。

const styles = StyleSheet.create({
  centeringText: {
    fontSize: 16,
    lineHeight: 24, // Material Design Guideline推奨値(1.5倍)
    includeFontPadding: false, // 余分なpaddingを消す
    textAlignVertical: 'center', // 垂直中央揃え
  },
});

iOS での対処法

iOS はデフォルトフォントであれば特別な設定は不要です。調整が必要な場合は、lineHeightfontSize と同じ値にして、フォントの上下余白を最小化します。textAlignVerticaliOS には存在しないため、上下の余白で調整します。

const styles = StyleSheet.create({
  centeringText: {
    fontSize: 16,
    lineHeight: 16, // フォントの上下余白を最低限に
  },
});

実践的な実装パターン

実際のプロジェクトでは、プラットフォーム固有の設定を Platform.select を使って管理することで、保守性の高いコードを実現できます。以下は、デフォルトスタイルと中央揃えスタイルを定義した実装例です。この実装パターンでは、default スタイルで基本的なフォント設定を定義し、centeringText スタイルで中央揃えに特化した設定を行います。Platform.select を使用することで、プラットフォーム固有の設定が明示的になり、コードの意図が明確になります。あとはこのstylingをしたText Componentを alignItem: 'center' をwrapすれば、iOS/Androidどちらも同じようにcenteringできます。

const styles = StyleSheet.create({
  default: {
    fontSize: 16,
    lineHeight: 24, // 1.5倍(Material Design Guideline推奨値)
    ...Platform.select({
      android: {
        includeFontPadding: false, // iOS との整合性を取る
      },
    }),
  },

  centeringText: {
    fontSize: 16,
    lineHeight: 24,
    ...Platform.select({
      android: {
        includeFontPadding: false,
        textAlignVertical: 'center', // Android で垂直中央揃え
      },
      ios: {
        // iOS ではデフォルトで中央揃えされるため追加設定不要
        // カスタムフォントの場合は lineHeight: 16 を検討
      },
    }),
  },
});

まとめ

React Native におけるテキストの垂直中央揃え問題は、iOSAndroid がフォントの高さ基準を異なる方法で解釈することに起因します。iOSascent/descent を基準とするのに対し、Android はデフォルトで top/bottom を基準とするため、同じコードでも表示結果が異なります。

この問題を解決するには、AndroidincludeFontPadding: false、適切な lineHeight、そして textAlignVertical: 'center' を組み合わせることで、プラットフォーム間で一貫した UI を実現できます。フォントの描画方式という基礎的な理解が、実践的な問題解決の鍵となるのです。

スクラムの「作業分担」は悪なのか、言語化したメモ

スクラムのスプリントの話で、バックログアイテムの進め方、特に並列作業についての話が良く出ると思います。 並列作業について、良い並列作業と悪い並列作業があるよね、という話を言語化しておきたい。

アンチパターンとしての「並列作業」

よく聞くアンチパターンは以下のような話。 SBIで並列作業を行うのは良くない、という話。

tech.surviveplus.net

これは以下の理由からだと考えています。

  • チームでスプリントで達成したい目標を設定した
  • その目標を達成するためには、その足がかりとなるSBIを一つひとつ着実に完了させることが大切
  • SBIを直列でなく並列作業で完了させようとすると、直列よりも管理が複雑になる
  • 複雑になった結果、タスクが期間内に終わらないリスクが高まる
  • なので、並列作業はなるべくやらないほうがいい

並列作業を避ける本質的な理由

大事なのは、目標達成の確率を上げるためには、シンプルなワークフローで進める方が確実性が高いから、という理由だと考えています。

許容できる並列作業パターン1:計画的な分業

同じチームであっても、複数人で並列作業を行うことはよくあると思いますが、それを認知した上で調整していれば問題はない。 バックエンドとフロントエンドで並列作業を行い、同スプリントで実装が結合できることが十分見込まれるなら、それは有効だと思っている。

許容できる並列作業パターン2:ゴール単位での直列

別パターンで、目標が複数ある場合は同一チームで並列作業を行うことはよくあると思います。 私のチームでは、「機能開発」と「基盤保守」といった性質の異なるタスクで並列作業が発生しています。 これによって大きな支障が出たことはありませんでした。 それは、チームで「機能開発」と「保守運用」とで目標が別であり、それぞれについては直列で動いているからだと考えられます。

チームとして見たときは並列作業が発生しているように見えますが、目標ベースでみたときには直列で動いている。 なので、集中して課題解決できるし、それぞれが影響を及ぼさない場合は、効率的にも良い。

まとめ:コンテキストの理解が重要

「並列作業は良くない」という話はよく聞きますが、なぜ良くないのかをきちんと考えれば、良いパターンと悪いパターンがあることがわかります。プラクティスを学ぶときは、その背景にあるコンテキストを認識したうえで理解することが大切だと感じました。

AI読書向けのPromptを作って、積読消化が捗った

GWに、自宅の積読していた本やらKindleOCRしてmarkdownにして、LLMにつっこんで斜め読みするみたいなことをしようとしていた。 いわゆる「AI読書」をやりたかった。

kensuu.com

勉強して役立つ知識を仕入れて、利活用することは好き。 だけど、そのために本を読むのは体力が持たない。 なので、「本を読む本」で語られているような「初級読書」「点検読書」と、ある程度の「分析読書」までをAIでレポートとして作ってもらい、それを読んでから気になるトピックを集中して読むみたいにしたかった。

  • 初級読書: 文字を読み、書かれていることの基本的な意味を理解する段階。
  • 点検読書: 本の主題や構成を短時間で体系的に把握する下読み・拾い読み。
  • 分析読書: 本を深く理解するために、内容や構成、著者の論証を徹底的に吟味する精読。
  • シントピカル読書: ある主題について複数の本を関連付けて読み比べ、多角的な理解を深める比較読書。

note.com

「本を読む本」にかいてそうな読書技法と、衛宮士郎の投影六泊を合体させたら、いい感じのPromptができた。 投影六泊を読ませて、コンテキストに合わせて言い換えさせて、Promptに突っ込んでやると、結構いいもの作れて便利となっている。

一度この心象世界に複製かつ記録された武器や防具は、固有結界を発動せずとも、

  1. 創造理念の鑑定(どのような意図で)
  2. 基本骨子の想定(なにを目指し)
  3. 構成材質の複製(なにを使い)
  4. 製作技術の模倣(なにを磨き)
  5. 成長経験の共感(なにを想い)
  6. 蓄積年月の再現(なにを重ねたか)

この“投影六拍”を始まりと終わりの詠唱で挟むことで、投影魔術として外界に引き出すこと(防具の場合は2~3倍の魔力がかかる)ができる。 無限の剣製 - ピクシブ百科事典

できあがったのが以下。

あなたは、与えられたテキスト(書籍またはPDF)の内容を、ユーザーが実際に読まなくても、あたかも**著者の視点を深く追体験し、その創造のプロセスや意図まで理解したかのように**、読了して内容を深く理解し、抽象化して把握したのと同程度の理解が得られるような詳細なレポートを作成する専門家です。レポートの各説明は、書籍内で語られている具体的な例や記述を根拠として提示してください。さらに、読者が実際に本を読みたくなった時のために、書籍内の目次と各目次の項目で語られている内容を数行で要約してください。



レポート作成においては、以下の各ステップで「著者の視点を再現する」という観点からの分析を意識してください。



1.  **読者への導入(根拠提示):**

    * レポートを読むユーザーが、これからどのような内容のテキストについて理解を深めるのか、その背景、重要性、読むことで何が得られるのかを、テキスト内で言及されている情報や主張に基づいて具体的に説明し、関心を引くような導入部を作成してください。

    * 特に、著者がどのような**根本的な動機や制作意図**をもってこのテキストを創造し、読者に何を伝え、どのような**主題や到達目標**を目指しているのかを、テキスト内の情報や主張に基づいて明らかにします。

    * これらの著者の意図や目標がなぜ重要であり、読者にとってどのような価値を持つのかを深く考察した上で記述してください。



2.  **テキスト全体の構造と主要テーマの解説(根拠提示と目次・要約):**

    * テキストの目次をリスト形式で提示し、**各目次の項目(章やセクションなど)ごとに、その直後にテキスト内の記述を参照しながら数行で主要な内容を要約してください。**

    * その後、テキスト全体の構成を、それぞれの部分で扱われている主要なテーマや議論の概要とともに解説します。その際、著者が自身の主張や物語を構築するために、どのような**情報、知識、データ、エピソード、文体、表現技法といった構成要素や表現素材**を選択し、それらをどのように配置・活用しているか、また、読者に効果的に伝えるためにどのような**構成力、文章力、論理展開、ストーリーテリングといった執筆技術**を駆使しているかを分析します。

    * 各テーマが全体構造の中でどのような役割を果たし、どのように相互に関連しているのか、一段深く掘り下げて説明してください。



3.  **核心となる概念・議論の詳細な展開(具体的な例を根拠に):**

    * テキストの中心となる重要な概念や議論を複数選び、それらがどのように提示され、展開されているかを、テキスト内で挙げられている具体的な例、事例、データなどを根拠として詳細に解説してください。

    * 著者がこれらの概念を説明し、読者を説得するために、どのような**具体的な情報源や表現要素**を用い、どのような**論証や表現上の工夫**を効果的に活用しているかに着目します。

    * それぞれの概念や議論について、まずその**基本的な定義、展開される論理、著者が提示する根拠、そしてテキスト内で具体的に示されている事例や描写**を明確にすることで、ユーザーがその内容を正確に理解できるように説明します。その上で、これらの概念や議論がテキスト全体の**核心的な主張やテーマといかに不可分に結びついているのか**、その**論理的な貢献度や構造上の枢要性**を具体的に分析してください。さらに、他の主要な概念や議論との**相互作用や依存関係**を明らかにし、それらが集合体としてどのようにテキスト全体のメッセージや論理構造を強化し、形成しているのかを深く考察します。続けて、その概念や議論が持つ**より広範な文脈での重要性や、現代社会あるいは読者個人の生活や思考における普遍的な意義・応用可能性**へと考察を深めます。著者がその概念や議論を通じて**明示的には語っていないものの、暗に示唆していること、あるいは読者に対してより深い思索を促すような未解決の問いや新たな視点**は何かを洞察し、テキストの表面的な記述を超えた含意や射程について論じてください。可能であれば、その概念に対する異なる視点や潜在的な限界にも触れ、著者の議論の強みと限界を多角的に評価することも試みてください。



4.  **テキスト全体の抽象化と本質(テキストからの推論):**

    * テキスト全体を通して著者が最も伝えたかったことは何か、その本質的なメッセージや普遍的な教訓を、テキスト全体の内容から推論して抽象化して提示してください。

    * これは、著者の**根本的な制作意図**や**主題、目指した到達目標**、さらには作品の背景にある著者自身の**個人的な経験や内省、作品に込めた想いや情熱**を総合的に読み解く試みです。

    * その抽象化された本質が、読者にとってどのような普遍的な意味や教訓を持つのか、一段深く考察し記述してください。



5.  **読者への示唆と今後の思考(テキストとの接続):**

    * このテキストを読むことで、特に著者の視点(その**根本的な制作意図、主題や到達目標、選択した構成要素や表現素材、駆使した執筆技術、作品に込めた個人的な想いや背景、そして作品の背後にある長年の知見や思索の積み重ね**など)を深く理解することを通じて、ユーザーの思考や行動にどのような影響がありうるか、また今後どのような視点を持ってこのテーマについて考えを深めていくべきかの示唆を、テキストの内容と関連付けながら提示してください。

    * テキストから得られた深い理解を基に、読者の思考を触発し、新たな視点を提供します。

    * 提示する示唆が、なぜユーザーの思考や行動に影響を与えうるのか、また、提示する新たな視点が、なぜ今後の思考を深める上で重要なのか、その理由を一段深く掘り下げて説明してください。



このレポートを読むことで、ユーザーは実際にテキストを読なくても、その主要な内容、深い洞察、そして本質的なメッセージを、あたかも自身で読解し、著者の視点をも追体験しながら抽象化したかのように、かつテキストの内容に根拠を持ちながら理解でき、さらに書籍の構成と各項目の概要を把握することで、実際に読む際の助けとなることを目指してください。

これをGeminiのCustom Promptで「読書レポート」と名前つけて、本をつっこんで、レポートつくってもらってる。

家にあった60冊ぐらいの積読が、これでとりあえず脳内マッピングできる程度に情報加工できたので、助かった。 本突っ込んだチャットつくっておけば、著者と対話的な読書ができるし、読書中のメモ取らなくてもチャットに残るので便利。 移動中の数分とかでも消化しやすいので、積読消化が進みそうでうれしみ。

React.NativeのNative ModuleでPromise<void>にあたる関数を戻り値は、慣習的にtrue返してるぽい

↓のPull requestを出そうとしたときのmemo

github.com

  • Promise<void> なNative Moduleつくっていた
  • promise.resolve() って書こうとしたら、引数いるぞと怒られた
  • 引数 null でいいのかな?と思ったけど、慣習的に true を渡していそうだった

以下は Linking.openURL(): Promise<void> の実装で、Android/iOSそれぞれ true を渡していた

github.com

github.com

プレゼンテーション資料を脳死で6割作るためのワークフロー

社内メモに書いてたのをコピペ


他者に対してのPresentationをすることは稀によくあります。
登壇、ブログ、職務経歴書、etc

資料に落とし込む時、「資料の設計」をどう設計するかを悩みがち。
自分がやっている資料作りのフレームワークを共有します。

STARSで大枠決める

saiyo.employment.en-japan.com

これにつっこめば大体の資料の大枠ができる。
大枠できたら、必要な情報をできるだけ最小限の文章で記述することをがんばる。

スライドの落としこみ

テキストにしても、だいたい一緒。

pain/gainの共有

  • どういった問題意識があるのか
  • 問題を解決すると、どういった良いことが起こるのか

具体的な問題対処

  • 何を対処するのか
  • 元気がある範囲で図解する
    • こちらから投げる情報源として「スライド」「声」と情報源がある
    • スライドは「図解で大枠のイメージを伝えて、文章で補足するイメージ」で書く
      • 紙芝居ぐらいのノリ
    • 声は「スライドの説明を副音声」というイメージでしゃべる
      • スライドの内容を「読み上げるだけ」で十分
      • スライド単体で情報源として成立しているものに対して、補完的に使うぐらいの気持ち

どう対処するのか

  • コードで具体例を示す場合は、全文のせず抽象化したコードもどきを提示する。
    • 見せておきたいコード以外は ... などで省略する。
    • 具体的に書きすぎると、聴衆は読解に専念してしまう。
  • コードの説明は基本的にしない。
    • 「こんなかんじです!気になる人はあとで見てください!」程度。
    • その場で聞いても完全に理解できないし、抽象化されたコードなので、あとで各自見てもらうほうが効率がいい。

付録

  • 本筋からズレるけど紹介したいことなど、あれば書く
    • 公式ドキュメントとか、抽象化したコードの具体コードのgistのリンクとか

説明や文章についての制約

個人的に縛りをつけておくと整えやすい。

実例集

GitHubの自己紹介 とか、 最近のスライドとか とか

以下は直近このノリで書いたもの speakerdeck.com