<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>


# 感想