<h2>はじめに</h2>
<p><a href="https://www.amazon.co.jp/%E5%85%B7%E4%BD%93%E3%81%A8%E6%8A%BD%E8%B1%A1-%E2%80%95%E4%B8%96%E7%95%8C%E3%81%8C%E5%A4%89%E3%82%8F%E3%81%A3%E3%81%A6%E8%A6%8B%E3%81%88%E3%82%8B%E7%9F%A5%E6%80%A7%E3%81%AE%E3%81%97%E3%81%8F%E3%81%BF-%E7%B4%B0%E8%B0%B7-%E5%8A%9F/dp/4907623100">具体と抽象 世界が変わって見える知性のしくみ</a> を読んだ。</p>
<p>きっかけは、Xで回ってきた <a href="https://note.com/yonekubo/n/n4fe61173fe15">具体と抽象を行き来するということ</a> という記事を昨年末読み、自分の中で具体と抽象の反復に苦手意識があるなと感じたためである。</p>
<h2>感想</h2>
<p>以下、個人の感想。</p>
<ul>
<li>具体と抽象、どちらの理解も不可欠</li>
<li>自分の立ち位置を客観的に見ることができるのは重要。<strong>そして目線を合わせる努力を怠らないこと</strong></li>
<li>上流工程は人を絞って進めるべきという意見には、一理あるが注意が必要</li>
</ul>
<p>まずは、具体と抽象という二つの概念がどういう関係性なのかを理解することが大事である。
また、議論というトピックにおいて、自分が具体に飛びつきがちな傾向にあるのか、議題の背景から上位概念を理解することから開始する傾向にあるのかを理解する必要がある。</p>
<p>どちらかに特化した傾向がある場合は、議論が噛み合わないといった経験があるのではないか？ (自分はある)
その場合、以下のアクションをとってみるのがよさそう。</p>
<ul>
<li>具体に特化している場合: 一歩立ち止まって物の本質(複数の具体に共通する概念)を捉える練習をする</li>
<li>抽象に特化している場合: 具体しか見えていない人と話す際に、「視点が合っていない」と主張するのではなく、視点を自ら下位レイヤーに提供してあげることが大事(気づいていないだけの可能性もある)</li>
</ul>
<p>アクションを試しつつ、議論の際に自分が具体・抽象どちらの目線で話すべきかを要所で判断し、適切に切り替えると、スムーズに議論を進めることができそう。
これが<strong>具体と抽象の反復</strong>である。
実際に客観的に自分の立ち位置を把握して議論を進めると、潤滑に進んだ経験をした人も少なくないのではないか。</p>
<p>改めて、話す目線を具体・抽象の観点で合わせる努力を怠らないことを意識する。</p>
<hr>
<p>上流工程こそ人を絞って進めるのがよいという話も挙げられていた。というのも、複数の具体の観点を持つメンバーをより集めて大局の方針を決めるのは難しいから。</p>
<p>自分としては、理解はできるが、やり方を間違えないように引き続き気をつけようと思った。
具体的には、上流と下流で現場感の認識に差異が生じている場合である。</p>
<p>上流としては、下流のメンバー抜きで方針を決めたが、下流のメンバーとしては現場の状況が苦しくなる一方ということになりかねないからである。</p>
<p>それを避けるために、現場のメンバーの話を吸い上げて上の意見に活かせるようにという意識は忘れずにやっていきたい。</p>
<h2>まとめ</h2>
<p>ページ数も130ページほどで、説明も図を挟みつつわかりやすいため、普段本読むのが苦手という方でもすんなり読めるのではないかと思う。
具体と抽象の反復に苦手意識がある人もない人も、ぜひ読んでみてほしい。</p>


具体と抽象 世界が変わって見える知性のしくみ を読んだ感想

<h2>はじめに</h2>
<p><a href="https://www.shuwasystem.co.jp/book/9784798068534.html">プログラマー脳</a>を1月の旅行中に読んだので、その感想を書く。</p>
<h2>概要</h2>
<p>基本的に脳科学的な観点で、コードが複雑に感じるのはなぜか・複雑に感じた場合どう解決していくか、を考えられるケースごとにまとめてくれている。</p>
<p>前提として、コードを理解するにあたって、</p>
<ul>
<li>長期記憶: 書かれている言語・フレームワークの文法・使い方を引き出す</li>
<li>短期記憶: 読んでいる箇所に存在する変数やメソッドの型や名前を引き出す</li>
<li>ワーキングメモリ: 長期記憶・短期記憶から引き出したものから、現在読んでいる箇所が何をしているのかを理解する</li>
</ul>
<p>三つの脳の役割が大事になる。長期記憶が十分でないと、毎度Googleで検索して内容を記憶する際に短期記憶を使ってしまい効率が落ちたり、一方で短期記憶が十分でないと、毎度変数やメソッドを見に行かないといけなくなったりする。その結果、処理の理解に時間がかかる。</p>
<p>結果的にワーキングメモリに負担をかけすぎない、つまり認知負荷を下げるように努めるのが大事。具体的には、メソッドをわかりやすい名前かつ単一責任の原則を守って、あくまで一つの役割をメソッドとしてまとめる、ということをやっていく必要がある。</p>
<p>あとは、</p>
<ul>
<li>別言語を触るにあたって気の持ちよう（メンタルモデル）を変える (概念的には同じでも、記法は違ったりするので)</li>
<li>記憶として定着させるには、反復が大事</li>
</ul>
<p>など、あくまで無意識に皆している・していたことを脳科学的に説明してくれている。</p>
<h2>感想</h2>
<p>総じて、読み物として面白かった。</p>
<p>大学時代必死にC言語を勉強して、変数・メソッド・配列・ポインタ..etcの概念を理解したから、長期記憶の部分が今いかせており、またメソッドの引数の数や変数の名前を詰め込みすぎず、明確な名前にすることで、短期記憶が働くようにできているのかなと。</p>
<p>単位のためとはいえ、なんだかんだで苦しんで覚えたC言語が今の礎になっているのは間違いないので、その点は同意。</p>
<p>逆に、今新しい技術スタックを触ることも増えているので、その時にどう取り組んでいたかを思い出して（マインドだけでも）実行していくのが、実は身に付く一番早い方法と思うので、仕事が忙しい等あるが毎日仕事以外でもきっちり決められた時間をとってコードを書いている。</p>
<p>できるだけ早く、長期記憶から引き出せるスピードと幅を上げるために、日々精進します</p>


プログラマー脳～優れたプログラマーになるための認知科学に基づくアプローチ を読んだ感想と個人的見解

<h2>はじめに</h2>
<p>Python ベースの Web マイクロフレームワークの一つ、<a href="https://fastapi.tiangolo.com/ja/">FastAPI</a>で API を作る機会があり、開発体験が良かったのでその感想です。</p>
<h2>良かった点</h2>
<h3>シンプルな設計</h3>
<p>大規模アプリケーションでなく、モック API や簡単な RESTful API を作るなどといった、ちょっとした用途でアプリケーションを作る場合は、<strong>できれば最小限のファイル・ディレクトリで構成したい</strong>というのが個人的な好みです。</p>
<p>例えば<a href="https://spring.io/projects/spring-boot">Spring Boot</a>でアプリケーションを作る場合、jvm 言語特有で「最初のプロジェクトから、複数のパッケージとファイルで構成されている」のですが、<code>FastAPI</code>では言ってしまえば、1 ファイルでアプリケーションを実行できます。<code>Node.js</code>の Web フレームワーク<a href="https://expressjs.com/ja/">Express</a>みたいに構成できるので嬉しいです。</p>
<p>例：GET リクエストを受け取るのみの API を作る場合、1 ファイルのみで以下のようにコードを記述するだけで OK</p>
<pre><code class="language-python">from fastapi import FastAPI, Query
from fastapi.responses import JSONResponse

app = FastAPI()

@app.get(&quot;/hoge&quot;)
def getHoge(id: str = Query(...)) -&gt; JSONResponse:
  # ここでクエリパラメータを受け取り、レスポンスを作る
  # jsonでレスポンスを返す
  return JSONResponse(status_code=200, content={&quot;body&quot;: &quot;hoge&quot;})
</code></pre>
<h3>直感的な理解のしやすさ</h3>
<p>アノテーションベースでリクエストハンドラーを書けるので、ぱっと見で何をやっているのか理解しやすいです。実際に上で書いたサンプルコードをみて、「<code>hoge</code>というエンドポイントに<code>id</code>というパラメータがついた URI でコールされたとき、中身 json で 200 のレスポンスが返る」と理解はできますよね。（引数<code>id</code>がクエリパラメータとぱっと見でわかるかどうかは、<code>Spring</code>や<code>NestJS</code>で書いたことがあるかによりそうな気がしないこともないが。。自分は<code>Spring</code>を業務で使っているのでスッと腑に落ちました）</p>
<h3>Pydantic との組み合わせることで受けられる恩恵の大きさ</h3>
<p><a href="https://pydantic-docs.helpmanual.io/">Pydantic</a>と<code>FastAPI</code>を組み合わせることで、</p>
<ul>
<li>型アノテーションを使用することで、バリデーション・シリアライズが容易</li>
<li><code>OpenAPI</code>スキーマの自動生成により、仕様書作成が容易</li>
</ul>
<p>が簡単に実現できます。特にリクエストボディに対して、バリデーション機構をスクラッチから書くことなく<code>Pydantic</code>の<code>BaseModel</code>と<code>FastAPI</code>の<code>Query</code>の組み合わせでかけるのはすごく楽。。</p>
<p>また、自動生成された<code>OpenAPI</code>スキーマを<a href="https://swagger.io/tools/swagger-ui/">SwaggerUI</a>・<a href="https://redocly.github.io/redoc/">Redoc</a>でドキュメント化できるのもクールです！！（当然 description など全てコード内に書いてあげる必要はありますが）</p>
<h2>最後に</h2>
<p>機械学習のモデルを利用した API や簡単なモックを作る必要があるときは<code>FastAPI</code>を採用したいです。<code>FastAPI</code>はいいぞ。</p>
<p>というかまず<code>Python</code>が型アノテーションの追加などでさらに書きやすくなってて嬉しかったです！久々書いてて「これよこれ」と実家に帰った感覚がありました。</p>
<p><code>FastAPI</code>は現在いまだにバージョン 0.X.X の状態なので、開発が本当に盛んです。ぜひ興味があればコントリビュートしてみてはいかがでしょうか！！</p>


FastAPIの開発体験が良かった話

<h2>はじめに</h2>
<p>新プロジェクトで一から API 設計・開発をやる機会があり、それきっかけで読んでみたかった技術書のうちの一つ<a href="https://www.oreilly.co.jp/books/9784873116860/">Web API: The Good Parts</a>を読みました。
感想および個人的見解をまとめていきます。</p>
<h2>読んだ感想・個人的見解</h2>
<p>本技術書は、設計周りだけでなく API を公開することを想定した話が多く納得した点が多くありました。
特に、</p>
<ul>
<li>バージョニングによる後方互換性サポート（クライアント側が最新版に対応していないケースなどを考慮）</li>
<li>コール回数の制限（API サーバへのアクセス過多になるケースを考慮）</li>
<li>セキュリティ面のケア（不正なコールでこちらでは意図していない情報を与えてしまうケースなどを考慮）</li>
</ul>
<p>は一般公開するにあたっては当たり前だけども、普段自分が外部公開をする API を作らないこともあり、勉強になりました。（<del>JSON インジェクションに関しては意識できてなかった。。</del>）</p>
<p>その他、印象に残ったトピックとしては</p>
<blockquote>
<p>設計の際に REST を意識しすぎない</p>
</blockquote>
<p>一例をあげるなら、REST でいう URI はリソース（ある実体があつまった集合体; e.g. posts: 投稿という実体があつまった集合体）であり、それに加えて場合に適した HTTP メソッドを指定してエンドポイントを設計するのが主流だと自分は考えていました。</p>
<p>しかし、検索用の API のエンドポイントに<code>search</code>という動詞を入れてあげて、より用途をわかりやすくしたり、バージョンを含めたりすることでユーザーにどのバージョンを使うのがを明示的に指定してもらったりというケースは現実的にはありえます。これは厳密にいうと、REST に反したケースです。</p>
<p>つまり、<span style="color: #ec004c; font-weight: bold;">REST の考え方に反していたとしても、それがユーザーにとってのわかりやすさや使いやすさをより向上するものであればそれはよいこと</span>だと腑に落ちました。</p>
<blockquote>
<p>リクエストもレスポンスもシンプルであれ</p>
</blockquote>
<p>必要以上にフィールドをオブジェクトで包むケースは、使う側の実装の負担になったりそもそも冗長な表現である可能性があるため、できるだけシンプルな階層で送ってもらい、返すことが大事だと再認識しました。</p>
<p>ただ、将来的な設計を考えると、レスポンスに関してはなるべく共通化しておくことは大事だなと感じていて、自分ならなるべく階層はフラットに作りたいけど、共通化の面も考えて一個階層を深く作ってあげます。（以下サンプル）</p>
<pre><code class="language-json">{
  &quot;error&quot;: {
    // エラーの中身はエンドポイントやステータスごとに返したいものを入れる
  },
  &quot;data&quot;: {
    // 成功した時に中身が入り、エンドポイントごとに返したいものを入れる
  }
}
</code></pre>
<p>ですので一番大事なのは、</p>
<p><span style="color: #ec004c; font-weight: bold;">どういう API を作りたいかというところに立ち返って、リクエスト・レスポンスとして適している設計をメリットデメリット含め考えて、納得行く方で組んであげる</span></p>
<p>ということかなと自分の中ではまとまりました。（メリットデメリット考えるときに、REST など設計にベースとなる考え方が生きてくるという認識）</p>
<h2>最後に</h2>
<p>本書を通じて、Web API 設計および運用のスタンダードを HTTP や REST などベースとなる考え方をさらった上で学ぶことができました。いい復習になりました</p>
<p>基本的にエンジニアリングにするにあたっては、その場その場での<strong>当たり前</strong>を知っていないと、間違った認識が自分の中でのスタンダードになる可能性があるので、引き続きさまざまな本を読みます。</p>


# 感想

具体と抽象世界が変わって見える知性のしくみを読んだ感想

プログラマー脳～優れたプログラマーになるための認知科学に基づくアプローチを読んだ感想と個人的見解

FastAPIの開発体験が良かった話

Web API: The Good Partsを読んだ感想と個人的見解

# 感想

具体と抽象 世界が変わって見える知性のしくみ を読んだ感想

プログラマー脳～優れたプログラマーになるための認知科学に基づくアプローチ を読んだ感想と個人的見解

FastAPIの開発体験が良かった話

Web API: The Good Partsを読んだ感想と個人的見解

具体と抽象世界が変わって見える知性のしくみを読んだ感想

プログラマー脳～優れたプログラマーになるための認知科学に基づくアプローチを読んだ感想と個人的見解