<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>福利厚生で、オライリーの無料ライセンス 1 ヶ月分をもらった。ﾔｯﾀﾈ
この一ヶ月本読みまくるぞーということで、適当にこれらはガッツリ読んでまとめたい所存。（時間作ってやるぞーー）</p>
<ul>
<li><a href="https://www.oreilly.co.jp/books/9784873119762/">Head First デザインパターン 第 2 版</a></li>
<li><a href="https://www.oreilly.co.jp/books/9784814400010/">マイクロサービスアーキテクチャ 第 2 版</a></li>
<li><a href="https://www.oreilly.co.jp/books/9784873118703/">データ指向アプリケーションデザイン</a></li>
<li><a href="https://www.oreilly.co.jp/books/9784873119823/">ソフトウェアアーキテクチャの基礎</a></li>
</ul>


オライリーの無料ライセンス 1 ヶ月分をもらった話

<h2>概要</h2>
<p>Spring Boot で複数 DB に接続する際に少し詰まったので、備忘録代わりに書く。</p>
<h2>詳細</h2>
<p>今回、MySQLとPostgreSQLの二つを一モジュールから繋がないといけないケースを想定する。</p>
<p>JDBCとJPAでどのように実現できるかを検証した。(<a href="https://github.com/KaoruMuta/springboot_practice/tree/master/multipledb">プロジェクト</a>)</p>
<h3>JDBC</h3>
<p>まずは設定ファイル(YAML/Property file)にDBの設定情報を指定する。</p>
<pre><code class="language-yaml">spring:
  datasource:
    mysql:
      jdbc-url: jdbc:mysql://localhost:3306/sample_db
      username: dbuser
      password: userpass
      driver-class-name: com.mysql.cj.jdbc.Driver
    postgresql:
      jdbc-url: jdbc:postgresql://localhost:5432/sample_db
      username: dbuser
      password: userpass
      driver-class-name: org.postgresql.Driver
</code></pre>
<p>一つだけDBに繋ぐ際とは異なり、<code>spring.datasource</code>以下に各種パラメータを設定するのではなく、繋ぐDBごとに設定を行うのが大きな変更点。（今回なら、<code>spring.datasource.mysql</code>/<code>spring.datasource.postgresql</code>）</p>
<p>そして、設定ファイルを読み込みDatasourceを構成する。</p>
<p><em>*一つだけ繋ぐ場合、<code>spring.datasource</code>以下にパラメータを定義することで、自動的にDatasourceを構成してくれる (<a href="https://github.com/spring-projects/spring-boot/blob/v3.1.4/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/jdbc/DataSourceProperties.java">DataSourceProperties.java</a>)</em></p>
<pre><code class="language-java">@Configuration
public class JdbcDataSourceConfig {

    @Bean(&quot;mysqlJdbcDataSource&quot;)
    @ConfigurationProperties(&quot;spring.datasource.mysql&quot;)
    @Primary
    public DataSource mysqlDataSource() {
        return DataSourceBuilder.create().build();
    }

    @Bean(&quot;postgresqlJdbcDataSource&quot;)
    @ConfigurationProperties(&quot;spring.datasource.postgresql&quot;)
    public DataSource postgresqlDataSource() {
        return DataSourceBuilder.create().build();
    }

    @Bean(&quot;mysql&quot;)
    public JdbcTemplate createMysqlDataSource(@Qualifier(&quot;mysqlJdbcDataSource&quot;) DataSource dataSource) {
        return new JdbcTemplate(dataSource);
    }

    @Bean(&quot;postgresql&quot;)
    public JdbcTemplate createPostgresqlDataSource(@Qualifier(&quot;postgresqlJdbcDataSource&quot;) DataSource dataSource) {
        return new JdbcTemplate(dataSource);
    }
}
</code></pre>
<h3>JPA</h3>
<p>設定ファイルに関してはJDBCと同様に定義。</p>
<p>そしてDatasourceの定義に関しても独自でやるところは同様だが、大きく変わるところは、</p>
<ul>
<li>transactionManagerをもう一つのDBと異なるユニットで定義</li>
<li>entityが格納されたパッケージの指定（基本的にはもう一つのDBと異なるEntityのはずなので、違ったパッケージを指定することが多いかも）</li>
</ul>
<pre><code class="language-java">@Configuration
@EnableTransactionManagement
@EnableJpaRepositories(
        basePackages = &quot;com.example.multipledb.repository.mysql&quot;,
        entityManagerFactoryRef = &quot;mysqlEntityManagerFactory&quot;,
        transactionManagerRef = &quot;mysqlTransactionManager&quot;
)
public class MysqlJpaDataSourceConfig {

    @Bean
    @ConfigurationProperties(&quot;spring.datasource.mysql&quot;)
    public DataSource mysqlJpaDataSource() {
        return DataSourceBuilder.create().build();
    }

    @Bean
    @Primary
    public LocalContainerEntityManagerFactoryBean mysqlEntityManagerFactory(
            EntityManagerFactoryBuilder builder,
            @Qualifier(&quot;mysqlJpaDataSource&quot;) DataSource dataSource
    ) {
        return builder
                .dataSource(dataSource)
                .packages(&quot;com.example.multipledb.entity.mysql&quot;)
                .persistenceUnit(&quot;mysqlTransactionManager&quot;)
                .build();
    }

    @Bean
    public JpaTransactionManager mysqlTransactionManager(
            @Qualifier(&quot;mysqlEntityManagerFactory&quot;) LocalContainerEntityManagerFactoryBean mysqlEntityManagerFactory
    ) {
        return new JpaTransactionManager(Objects.requireNonNull(mysqlEntityManagerFactory.getObject()));
    }
}
</code></pre>
<h2>まとめ</h2>
<p>基本的には、それぞれ繋ぎたいDBの設定を書いて、独自でConfigを構成するだけ（ただ、JDBCに関しては自動で設定してくれることもあり、若干戸惑うかも）</p>
<h2>参考記事</h2>
<ul>
<li><a href="https://www.baeldung.com/spring-boot-configure-multiple-datasources">https://www.baeldung.com/spring-boot-configure-multiple-datasources</a></li>
</ul>


Spring Bootで複数DBに接続する際の注意点

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


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

<h2>はじめに</h2>
<p>あけましておめでとうございます。今年もよろしくお願いいたします。</p>
<p>本年度一発目の記事は、技術のインプットアウトプット通じての備忘録シリーズです。</p>
<h2>作ったもの</h2>
<p>今回サンプルとしてつくったものは単語帳アプリです。
ざっと機能としては</p>
<ul>
<li>ユーザーが設定したカテゴリを選択</li>
<li>選択後カテゴリに該当する単語が出現、答えを任意のタイミングで見ることができる</li>
</ul>
<p>のシンプルな感じで 1 日で開発が終わるようなレベルに設定しました。ちなみに<em>ユーザーは自分しかいない前提で進めています</em></p>
<h2>採用技術</h2>
<p>技術は以下の通りです。採用理由は<strong>自分が使いたかったから</strong>！！（結局興味があったりモチベが出るものが一番いいのよ個人開発は）</p>
<ul>
<li>Client (app): SwiftUI+Combine</li>
<li>Server: Golang(フレームワーク: gin)</li>
<li>DB: Heroku Postgres</li>
</ul>
<p>バックエンド側は Heroku フル活用で事足りるはずなので使わせてもらって、アプリ側は久々 SwiftUI で書きました</p>
<h2>得た知見（ハマったところ多め）</h2>
<p>Client, Server, DB, Heroku 周りで詰まったところをまとめます。これは余談ですが、Go で作ったアプリケーションを Heroku で扱う<a href="https://devcenter.heroku.com/ja/articles/getting-started-with-go?singlepage=true">公式チュートリアル</a>が優秀すぎて、想像以上にスムーズにできたのでよかったです</p>
<h3>SwiftUI で元の画面に戻る処理</h3>
<p>UIKit でいう<code>dismiss(animated:)</code>を SwiftUI でやるには<code>PresentationMode</code>構造体にアクセスして、<code>dismiss()</code>を呼んであげます</p>
<pre><code class="language-swift">// 遷移元のView

// presentationModeの環境変数を取得
@Environment(\.presentationMode) var presentationMode

// 元画面に戻る処理
presentationMode.wrappedValue.dismiss()
</code></pre>
<p>iOS15 以降なら、環境変数<code>presentationMode</code>でなく<code>dismiss</code>にアクセスすればすんなりできそうです(<a href="https://capibara1969.com/3146/">参考</a>)</p>
<h3>NavigationLink で遷移した画面の上に謎のスペースができる際の対処法</h3>
<p>UI を調整している時に、なぜか上側に謎のスペースができていたので<code>navigationBarTitleDisplayMode</code>を<code>.inline</code>に指定して解決(<a href="https://www.hfoasi8fje3.work/entry/2020/12/30/%E3%80%90SwiftUI%E3%80%91NavigationLink%E3%81%A7%E9%81%B7%E7%A7%BB%E3%81%97%E3%81%9F%E7%94%BB%E9%9D%A2%E3%81%AE%E4%B8%8A%E9%83%A8%E3%81%AB%E8%AC%8E%E3%81%AE%E4%BD%99%E7%99%BD%E3%81%8C%E7%99%BA%E7%94%9F">参考</a>)</p>
<pre><code class="language-swift">HogeView {
    // SwiftUI.View
}
.navigationBarTitleDisplayMode(.inline)
</code></pre>
<h3>特定の処理が終わったタイミングで NavigationLink を使って画面遷移したい</h3>
<p>API との通信処理が終わったあとに画面遷移をしたいときは、<code>NavigationLink</code>の<code>isActive</code>フラグを通信が終わった時に<code>true</code>に変えてあげることで実現できます。(<a href="https://blog.studysapuri.jp/entry/2021/09/18/iosdc-swiftui-navigationlink-push-navigation">参考</a>)</p>
<pre><code class="language-swift">NavigationLink(destination: QuizView(words: viewModel.words), isActive: $shouldShowQuizView) {
    Button(action: {
        viewModel.fetchWords(
            by: selectedCategoryId,
            success: {
                // success callbackのときにshouldShowQuizViewをtrueにする
                self.shouldShowQuizView = true
            },
            failure: {
                print(&quot;Failed to fetch data from api&quot;)
            }
        )
    }) {
        Text(&quot;START&quot;)
    }
}
</code></pre>
<h3>Heroku デプロイで<code>app not compatible with buildpack</code> (Go 編)</h3>
<p>以下コマンドで go のバージョンとモジュールの依存関係を記した<code>go.mod</code>を作成し、デプロイしてあげて解決。(<a href="https://stackoverflow.com/questions/48841627/cant-push-simple-golang-project-to-heroku">参考</a>)</p>
<pre><code class="language-go">go mod init {GIT_REPOSITORY_URL}
</code></pre>
<h3>Heroku デプロイで <code>cannot execute binary file: Exec format error</code></h3>
<p>ローカルでコンパイルの際に OS とアーキテクチャ の指定をしてあげてクロスコンパイル、その後バイナリをデプロイすることで解決(<a href="https://stackoverflow.com/questions/63412744/deploy-to-heroku-error-cannot-execute-binary-file-exec-format-error">参考 1</a>, <a href="https://qiita.com/Utr/items/9469c1611abe8a0a3486">2</a>)</p>
<pre><code class="language-bash">## fish
env GOOS=linux GOARCH=amd64 go build -o bin/terminology-memo-api -v .
</code></pre>
<h3>Heroku デプロイで<code>app[web.1]: bash: bin/: No such file or directory</code></h3>
<p><code>Procfile</code>でバイナリの存在するパスを記して解決</p>
<pre><code>web: bin/{BINARY_NAME}
</code></pre>
<p>参考: 上述の公式チュートリアル</p>
<h3>Go で作ったアプリケーションで<code>no required module provides package</code></h3>
<p>下記コマンドを実行して依存しているモジュールを更新(<a href="https://sumito.jp/2021/04/23/no-required-module-provides-package-github-com/">参考</a>)</p>
<pre><code class="language-go">go mod tidy
</code></pre>
<h3>改行コードを PostgreSQL で扱う</h3>
<p>E を追加したい文字列の先頭にいれてあげて解決(<a href="https://knowledge.reontosanta.com/archives/303">参考</a>)</p>
<pre><code class="language-sql">INSERT INTO words (name) VALUES (E&#39;明日\n晴れるかな&#39;)
</code></pre>
<h3><code>updated_at</code>を自動的に更新してくれる制約を追加</h3>
<p>MySQL なら<code>on update current_timestamp</code>を DDL に追加してあげるだけで OK だが、PostgreSQL だと同等の機能がないので、トリガーを描いてあげる必要がある。。。ので、<a href="https://www.raythebm.net/weblog/archives/249">このサイト</a>を参考に書かせていただきました</p>
<h2>最後に</h2>
<p>やる気が出た時にガツッとやる開発は久々だったが、楽しいしまた違う学びがある。</p>


SwiftUI+Golang+Heroku Postgresで遊んでみた感想と知見

<h2>はじめに</h2>
<p>この度、はてなブログで運用していた tionblog ですが、当サイト（ドメイン: <strong>kaorumuta.me</strong>）を自作し移行しました。</p>
<p>旧: <a href="https://mutation.hatenablog.com/">https://mutation.hatenablog.com/</a>
<br>
新: <span style="color: #ec004c"><a href="https://kaorumuta.me/blog">https://kaorumuta.me/blog</a></span></p>
<h2>技術仕様</h2>
<p><code>Next.js</code> を使ってブログを構築しました。採用理由としては以下の通りです。</p>
<ul>
<li>SSG（静的サイト生成）がブログと相性がいい</li>
<li>公式リファレンスが充実していた</li>
<li><small>自分が <code>Next.js</code> 自体に興味があった</small></li>
</ul>
<p>ページの更新が頻繁に必要ではないブログサイトの構築には、SSG のプレビルドの考え方が活きると考えて採用に至りました。(<del><code>Gatsby</code>という選択肢もあったが<code>Next.js</code>を選んだのは、実質最後の要点が一番の採用理由</del>)</p>
<p>採用技術に関しては<a href="https://github.com/KaoruMuta/KaoruMuta.me#readme">README</a>にまとめています。</p>
<h2>感想</h2>
<p><code>Webpack</code> などの設定は <code>create-next-app</code> でやってくれているし、動的ルーティングがサポートされていて、DX (Developer Experience)的に非常に良かったです。。！！</p>
<p>そして肝心のウェブサイトの応答速度も早く、不快感なく閲覧することができるので UX を重視したものを作ることができました。</p>
<p>今回は簡単な静的サイトであるブログを作ることにしましたが、実際に <code>Next.js</code> をバックエンド側と連携させてシステムを作った場合のメリットデメリットが気になった次第です（今回の開発では特にデメリットは感じなかった。複雑な状態管理とかが要求されるケースではどうするのだろう）。</p>
<p>あと、興味ドリブン開発は捗るし楽しいけど、せっかくなので言語化して自分の知識にしていきたいですね。</p>
<h2>最後に</h2>
<p>当ブログは質問やコメント等あればこちらの<a href="https://github.com/KaoruMuta/KaoruMuta.me/issues">ISSUE</a>にて受け付けておりますので、お気軽にどうぞ！</p>


ようやくブログを自作しました

<h2>はじめに</h2>
<p>ずっと前の自分：「<code>GoogleService-info.plist</code>を gitignore してるから永遠 GitHubActions での CI のビルドが通らない！！！！！！どうしよう！！！」
何もわからん状態だった自分を救ってくれたのは，Android で同じようなことをしている<a href="https://qiita.com/sudo5in5k/items/5b6da5dbba3fc2514319">記事</a>でした．
その記事は</p>
<ol>
<li><code>google-services.json</code>を base64 に変換</li>
<li>GitHub Secrets に記入</li>
<li>GitHubActions の yaml ファイルから Secrets 読み込み</li>
<li>decode して正しい位置に配置</li>
</ol>
<p>という手順で CI を通していました．</p>
<p>ならば，これを iOS でも同じようにすればいいじゃないか！となりますよね．やりましょう．</p>
<h2>手順</h2>
<ol>
<li><code>GoogleService-info.plist</code>を json に変換</li>
<li>生成した json ファイルを base64 の形にし，secrets に記述</li>
<li>secrets から json ファイルを生成し，その json ファイルを plist ファイルに変換（<code>GoogleService-info.plist</code>という名前として適切な位置におく）</li>
<li>生成した json ファイルを削除</li>
</ol>
<h3>1. <code>GoogleService-info.plist</code>を json に変換</h3>
<p><a href="https://www.ecoop.net/memo/archives/convert_plist_to_or_from_json.html">記事</a>を参考に変換しました．
（下の<code>/path/to/dir</code>は GoogleService-info.plist が存在するディレクトリまでのパス．）</p>
<pre><code class="language-bash">cd /path/to/dir
plutil -convert json GoogleService-info.plist -r -o output.json
</code></pre>
<h3>2. 生成した json ファイルを base64 の形にし，secrets に記述</h3>
<p>cat で出力した結果（<a href="https://qiita.com/sudo5in5k/items/5b6da5dbba3fc2514319">記事</a>参考）をそのまま Secrets に貼り付けます</p>
<pre><code class="language-bash">cat output.json | base64
</code></pre>
<h3>3, 4. secrets から json ファイルを生成し，その json ファイルを plist ファイルに変換+生成した json ファイルを削除</h3>
<p>流れは以下の通り．</p>
<pre><code class="language-yaml"># Generate GoogleService-info.plist (Step 3)
- name: Translate secrets of base64 into json
  env:
    GOOGLE_SERVICE: ${{ secrets.GOOGLE_SERVICE_INFO_PLIST }}
  run: echo $GOOGLE_SERVICE | base64 --decode &gt; ./OgiriBattle_Swift/Common/Resources/output.json
- name: Translate json into plist and generate GoogleService-info.plist
  run: plutil -convert xml1 ./OgiriBattle_Swift/Common/Resources/output.json -o ./OgiriBattle_Swift/Common/Resources/GoogleService-info.plist
- name: Remove json file (Step 4)
  run: rm OgiriBattle_Swift/Common/Resources/output.json
</code></pre>
<p><code>GOOGLE_SERVICE</code>という名前で secrets に記述されている base64 を取得 →json に decode→json から plist に変換という流れ．
（<code>OgiriBattle_Swift/Common/Resources/</code>のパスは例です）</p>
<h2>最後に</h2>
<p>いい記事を残してくれた先人の方々に感謝を込めて，自分もいい記事を書こうとなりました．
間違い等あれば指摘してください．お願いします！
また，いい記事だと思った方はグッドボタンと Twitter のフォローをね，よかったらお願いします！（どこぞの Youtuber みたいだな）</p>
<h2>救世主となったサイト</h2>
<ol>
<li><a href="https://qiita.com/sudo5in5k/items/5b6da5dbba3fc2514319">https://qiita.com/sudo5in5k/items/5b6da5dbba3fc2514319</a></li>
<li><a href="https://qiita.com/hohohoris/items/f934beb4ea0b432af488">https://qiita.com/hohohoris/items/f934beb4ea0b432af488</a></li>
<li><a href="https://linuxjm.osdn.jp/html/GNU_coreutils/man1/base64.1.html">https://linuxjm.osdn.jp/html/GNU_coreutils/man1/base64.1.html</a></li>
<li><a href="https://www.ecoop.net/memo/archives/convert_plist_to_or_from_json.html">https://www.ecoop.net/memo/archives/convert_plist_to_or_from_json.html</a></li>
</ol>


GoogleService-info.plistをgitignoreしている時に，GitHubActionsでCIを通す

<h2>はじめに</h2>
<p>PyTorch を使って Deep Learning の学習(train)，推論(validation，test)の部分を実装していた時にはまった罠を紹介します．</p>
<h2>PyTorch での学習・推論の際のモデルの切り替え</h2>
<p><a href="https://pytorch.org/tutorials/">PyTorch tutorial</a>に，</p>
<ul>
<li>学習時: <code>model.train()</code></li>
<li>推論時: <code>model.eval()</code></li>
</ul>
<p>とコードに書かれてあります．
model の中に batchnormalization 層や dropout 層が含まれていた場合，これらは学習時では使うが推論時では使わないと言う指定をしてあげなければいけません．なぜならこれらは学習を効率よく行うためのテクニックであって<strong>推論時では使われないもの</strong>だからです．</p>
<p>supervisor が渡してくれたコードにはこの二つが書いておらず，書かなくても別にいいものだとずっと放置していたため，このミスに気づくのに 2 週間ほどかかりました…
そのため推論の結果も散々で頭を悩まされていました…おそらくこのミスは一生忘れることがないと思います．</p>
<h2>最後に</h2>
<p>ですがこのミスのおかげで PyTorch，Deep Learning の知識をより深めることができたので結果オーライかなと…思い込みます！！</p>


【PyTorch】学習時，推論(テスト)時での注意/model.eval()←めちゃくちゃ大事

<h2>遭遇した問題</h2>
<p>昨日悩まされていた問題です．</p>
<p>研究室のパソコンを壊してしまったため，新しく日本から送られてきたパソコンを使っているのですが，それには Office が入っていませんでした．ですので overleaf を使って進捗報告を行っていたのですが，**画像/pdf を入れたくても真っ白のまま…**なんやこれ</p>
<pre><code>\usepackage[dvipdfmx]{graphicx}
</code></pre>
<p>も入ってるしなんで…</p>
<h2>原因</h2>
<p>原因は overleaf 自体にあったかもしれないです．左上の Menu ボタンを押すと Setting のところが出てきます．そこの Compiler のところを <strong>pdfLaTeX から XeLaTeX</strong> に変えたところ画像が無事表示されました…！</p>
<p>もし，overleaf を使っていて同じような問題が起きたらこれをチェックしてみるといいかもです．</p>
<h2>最後に</h2>
<p>話は変わりますが，来週木曜日に日本の研究室への中間発表がありその直後から 12/3 まで<span style="font-weight: bold; color: #ec004c">パリに行きます！！！</span>天気はあいにくの雨予報ですが！！！！！</p>
<p>p.s. はちゃめちゃに楽しんできたいと思います，その前に発表スライド作らなあかんな…</p>


# 技術