お気持ちの表明

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

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

ExpoでhttpのサイトやAPIを扱いたいときのworkaround

概要

Android/iOS共にデフォルトでhttpへのアクセスができないようになっている

By default, iOS 9.0 or later enforce App Transport Secruity (ATS). ATS requires any HTTP connection to use HTTPS. If you need to fetch from a cleartext URL (one that begins with http) you will first need to add an ATS exception. If you know ahead of time what domains you will need access to, it is more secure to add exceptions only for those domains; if the domains are not known until runtime you can disable ATS completely. Note however that from January 2017, Apple's App Store review will require reasonable justification for disabling ATS. See Apple's documentation for more information.

Networking · React Native

On Android, as of API Level 28, clear text traffic is also blocked by default. This behaviour can be overridden by setting android:usesCleartextTraffic in the app manifest file.

Networking · React Native

ローカルサーバーがhttpだったりすると、アプリからアクセスすることができないので困った。

workaround

app.jsonを変更し、Android/iOSの設定をいじる Dev Client使っているなら、変更したあとはEAS Buildする 雑なメモなので雑に書いているが、app.config.tsにして定義すれば、開発環境だけ無効にするとかもできるのでそうしたほうがいい

iOS向け

ios の項目で上書きする

  ios: {
    infoPlist: {
      NSAppTransportSecurity: {
        NSAllowsArbitraryLoads: true, // APIの呼び出しでhttpを許可
        NSAllowsArbitraryLoadsInWebContent: true //WebViewでhttpを許可
      },
    },
  },

Android向け

expo-build-properties で上書きする

  plugins: [
    [
      'expo-build-properties',
      {
        android: {
          usesCleartextTraffic: true
        },
      },
    ],
  ],

Reference

Androidは以下をそのまま

stackoverflow.com

iOSは書き換える位置をGitHub Issue把握して、内容はQiitaを参考にした github.com qiita.com

注文住宅をやった振り返り

去年書きましたが、めでたく結婚しました。 妻と付き合う前のときに「結婚相手に求めるものは何?」という話をしたときに、「家を建てたい!!!」という話を聞いてました。 「なるほど〜〜」となり、去年の4月ごろから家を建てるためのアレコレを始め、先月無事に引き渡しになりました。

そんなプロジェクトを色々ざっくり振り返ります。 ほしいものリストがあるので、新築祝い待っております🙏

「家建ててるの爆速すぎん???」

色々な人から言われましたが、以下の要因があり爆速で家を建てることになりました。

住宅メーカーの値上げ

木材やら半導体の不足で、色々値上がりが続いてた影響で、住宅メーカーの値上がりラッシュが続いています。 値上げのタイミングも、前月に告知されるぐらいの感じであんまり予想できる感じではありませんでした。 どの住宅メーカーの営業も「近々どこかのタイミングでは数回値上げがあると思うから、家を建てたいと考えているなら、なるはやがいいですよ」とアドバイスされ、「なら、とっとと考えるか〜〜〜〜」となりました。なお、実際に当時から2回は値上げされていました😇

土地がない

コロナ禍もあり、家を建てたり買う人が増え、家を建てるための土地もどんどん減っていっていました。 優良物件に近いノリで「ネットに情報が出たら、翌週ぐらいにはもう買い手が決まっている」ぐらいのスピード感になっています。条件を定めても好みの土地に出会うことは時間を要しますし、そもそも母数が減っていってるとなれば好みの土地に出会えるのはガチャみたいなノリになります。

そんなわけで、「住宅メーカーの選定をとっとと終えて、いい土地あったらとっとと確保し、とっとと家を建て始めなきゃッ」となり、早めに動きました。

家が完成するまでの時系列

色々やりはじめてから1年半ぐらいで家が建ちました。 それぞれのフェーズについてざっくり紹介します。

情報収集〜住宅メーカー選び始め

4月から8月ぐらいまでかかりました。

最初にスーモカウンターに行き、そこから5社の住宅メーカーを紹介してもらいました。 紹介してもらった住宅メーカーを回るのに約1ヶ月かかりました。

最終的には、紹介された中から住友林業を選んで建てることにしました。 選択の決め手は、ついてくれた営業担当との相性が良かったことと、「木質感がいい感じのおしゃれな家を建てたい」という希望にマッチしました。

ちなみに、最初に住宅展示場に行くのは最近ではアンチパターンとされているらしいです。 いわゆる「担当営業ガチャ」や、仲介業者が挟まることによって得られる割引率が悪くなるなどの理由らしいです。 ですが、諸々の仲介業者を挟まないで全部意思決定したり調整するのは、全体的にマネジメントコスト高い気がしてて、大変そうだなあ....となりました。 とりあえず、我が家は良い営業と成果物もいい感じなので良かったです🥹

打ち合わせ

8月から翌年の3月ぐらいまでかかりました。 2週間に1回ぐらいのペースで、4-5時間ぐらいオフラインで打ち合わせしました😇 平日の仕事終わりに次の打ち合わせで話すことを考え、週末は副業で家の金を稼ぎつつ、打ち合わせや展示場に行くという生活が続き、無限に疲れました😇 意思決定ポイントが多すぎるし、意思決定するための材料収集作業も無限にある感じだったので、頭が休まりませんでした...😇 とりあえず頑張り切れたので、住んで1ヶ月経ちましたが今でも90%程度満足できる仕上がりになっています👨🏼‍🦳

流れで、軽く家の推しポイント紹介

リビング吹き抜け階段になってます。

「暖房効率が...!」みたいな話はありますが、断熱まわりはゴリゴリやったので特に困っていないです。 朝リビングのエアコンつけて23℃ぐらいに温めて、夜になっても21℃ぐらいはキープされています。

照明がGoogle Homeで操作できるようになっています。

壁スイッチが赤外線操作できるものにしてあります。 これにSwitchbot Hubから赤外線飛ばせばオン/オフできます。 これのおかげでGoogle Homeから操作できるようになっています。 また、物理的に壁スイッチを押す必要がなくなったので、壁スイッチはクローゼットに隠されていて、リビングの壁にはスイッチがないです🤩 ここらは色々取り組んでいるので、また別記事で紹介します。

あと、キッチンを課金しまくりました。

クリナップのセントロを入れています。 ガスとIHを併用できるガステーブル、フロントオープン食洗機、タッチレス水栓、プッシュオープンできる引き出し...と、料理好きの私的にはアガる感じに整いました。

cleanup.jp

着工から家ができるまで

5月頭に着工して、10月末に引き渡しになりました。 毎週のようにLINEで家の進捗報告が写真でもらっていました。

また、家の設計は3月で終わりましたが、建てている裏で外構の設計を並行してました。 以下は、庭に植える木を見に行ったときの写真です。

引き渡しから現在まで

家が完成して、実際に引っ越すまでの2週間ぐらいありました。 以下のような感じで色々やってて忙しかったです。

  • 水回りの撥水加工を業者に依頼
  • 水回りのコーキングを業者に依頼
  • NUROの開通工事
  • ドラム式洗濯機の分解掃除

引っ越したあとも、家のbug fixが色々ありました

  • 庭が若干終わっていなかったので、業者が何度か来た
  • 壁スイッチが指定したものと違うことが発覚し、交換してもらった
  • 一部壁スイッチを人感に変えたくなり、ついでに交換してもらった
  • トイレがボコボコ言ってて対処してもらった (WIP

とりあえず、今は平和に住んでいます😎

得られた知見

いろいろありすぎますがざっくりと

値引き交渉のタイミングが難しすぎる

値引き交渉のタイミングが、普通の買い物の交渉とはタイミング違いすぎて爆死しました。

値引き交渉ができるのは、住宅メーカーと「あなたのところで家を建てますよ」と契約する時だそうです。 「すべて仕様揃って合計金額が出たタイミング」ではないです。 普通の買い物の値引き交渉とはタイミングが直感的ではないなと思いました。 ここらへんはggったり、YouTuberが無限に紹介している気がするので、100回ぐらい見てきちんと頭に叩き込んだほうがいいです。

CGと実物が違う事件が普通にある

あるあるな話ではあるものの、「そんな雑な仕事ないだろ...」と思っていたら普通にありました。 普段、フロントエンド側のエンジニアとしてはFigmaが本番デザインと違うようなものだと思います。 そんなことあったら「本番とデザイン違うやんけ!直せ!」となると思うのですが、物理なのでそんなシュッと直せないです。 「シュッと直せないなら、きちんとチェックしろ」と思うのですが、住宅業界的に「あくまでイメージだから多少差分が出てもしゃあねえっす」というノリを感じました。

配色が違っていたり、建具の寸法が違ってたりしたので、普通にインシデントだろと思うんですが....

我が家の場合、一部壁の配色が違っていたり、柱の位置が違っていました。 壁の配色は物理実装される前だったので修正できたのですが、柱の位置は修正できませんでした...😇

GCだけじゃなく、現物だったりその品番のカタログを確認するなりをきちんとしたほうがいいです。ホントに。 だけど、視覚で認知したものを、図面ベースで整合しているかだったり、品番ベースで整合しているかをチェックするのは素人には厳しすぎると思いました。

住友グループで保険が一元化できて便利

我が家は住友林業で建てたので、諸々の保険が住友グループで一元化されています。 家の情報も保険の契約内容も住友グループで一元化されているので、何かあった時の初動が「とりあえず脳死住友グループの窓口に1回電話するだけ」で済むので、便利そうとなりました。

おわりに

1年半ぐらいのプロジェクトがとりあえず終わってよかったです。 お金は飛びまくりましたが、良い住環境が整ったので色々と平和な気持ちになっています。 ただ、 「家は3回建てないと満足できるものができない」という話通りに、初見殺しにあったり、家に対して既に直したいところがあったりしました。 家を建てようと思っている人は、ネットで後悔ポイントを調べたり、実際に家を建てた人を捕まえてインタビューしまくるといいと思います。ホントに。 コンセントの位置とか無限にいじりたくなります。ホントに。

以上、注文住宅をやった振り返りでした。 ほしいものリストがあるので、新築祝になにかいただけると嬉しいです🥰

www.amazon.jp

また、タイミングがあったら家で御飯作るので遊びに来てください💃

expo-routerでcustom navigationを作ったときに、特定のroutingを除去する

vanilla react-nativeで作っていたアプリをEAS Buildに移行するとき、iOSの証明書まわりどうするの委員会

そういう感じのことを最近やっているので、やったことの忘備録

Deployment environmentどうやってわけるの

ここにまとめてるので、app.config.tsをいじりましょう。

speakerdeck.com

微妙な注意点としては、環境変数の切り替えに NODE_ENV を使わないほうがいいです。

blog.p1ass.com

証明書の移行どうするの

既存の証明書を移行する場合、p12を投げ込むことができる fastlaneで管理している証明書は、p12にしてRepositoryに突っ込まれているはずなので、それを使えば良さそう

expo.devのスクショ

ただ、私はfastlaneで錬成されているp12を突っ込んだらなんかエラー出た 証明書の更新が近かったし、面倒になったので、 $ eas credentials を叩くことにした $ eas credentials 叩くと、fastlaneと同じ感じで証明書やらProvisioning Profileやらの生成ができる

UDIDの登録どうするの

ここに色々書いてる

docs.expo.dev

微妙なハマりポイントだと、「UDID登録するには $ eas device:create 叩けと書いてるけど、既にApple Developerに登録しているやつはどうすんねん」となった。 これについては、 $ eas device:create を叩くと「UDIDどう登録する??」と途中で聞かれ、その中の選択肢に「Apple Developerからimportしてくれ」というのがあるので、それを選べばおkだった

$ eas device:create

初期移行したあとの登録は、 $ eas device:create 叩いて Website を選んでくれとかdocumentに書いておけば良さそう