今年の4月から、現在の職場で「SREチーム」という枠で働くようになりました。 SREというとシステム運用やDevOpsの全般を面倒見るイメージを持っていたのですが、 既存のシステムはその開発チームが運用管理しているのもあって、 自分はまったく運用作業をしていません。 各システムのモダナイズを進めるにあたっての、開発チームへの技術フォローや、 技術検証の取り組みなどが主な自分の仕事になっています。 <h2 id="h46e3a4c781">SREとしてチームにどう関わるか</h2> 「SREチーム」という名を冠しているので、開発チームからは意思決定を求められることが多くなります。 使用する言語・フレームワークなどは職場内で統一しようとしているものがあるので問題なくフォローできたりするのですが、 もう少し細かい範囲、例えばディレクトリ構造やユニットテストの書き方について相談を受けると、 「開発チームで考えればいいのでは？」 「そうはいっても丸投げだと標準化が進まない」 という思いが湧いてきて悩んでいる日々です。 世に言うSREの仕事として正しいかは別として、 ああしろこうしろ、とSREが指示する方針だと開発チームは楽しくないでしょう。 一方で、指針となるプロジェクト・サービスも用意できていないので、 新しい言語で開発しろとだけ言われても開発者は途方にくれると思います。 <h2 id="h6096b08d3f">CI/CDの構築とSRE</h2> ここ数ヶ月はSREと開発チームの境界線、住み分けについて考えていますが、 直近で「CI/CDの構築について」聞かれる機会がありました。 「CI/CDをやりたいので相談したいです」 と声をかけていただき、これは確かにSREっぽいなと思いながら詳細を聞きました。 相談内容はこんな感じです。 ・開発チームとして何をすべきか ・CI/CD環境について教えてほしい ・SREチームに頼めば全部やってくれるのか 最初はやりたいことをヒアリングして、 CI/CD環境をSREチーム側で用意するイメージをしていましたが、 話を聞くとここでも開発チームと調整が必要なことに気づきました。 まず、CI/CDについてはGitLabを使用している以上、GitLab CIを使うことになります。 GitLab CIで何かをする上で、いくつか準備・設定すべきことがありますが、 <ol><li>GitLab Runnerのインストール、登録</li><li>CIの設定ファイル（.gitlab-ci.yml）の追加</li><li>CIの設定ファイルに動かすスクリプトを書く</li><li>デプロイ先の環境作成</li></ol> ざっとこんな感じになると思います。 デプロイしないなら3までですし、ContainerRegistryやPagesを使うならもう少しやることは増えますね。 この中で、SREチームがやるべきこととして明確なのは、1・2・4だと思います。 開発者目線から考えると、CIのスクリプト（テストとか）を書くだけで実行できる環境になっていると、 かなり開発のみに集中できる印象です。 なので、SREチームとしては、CIの設定ファイルの雛形やサンプルを提供し、 開発チームに書いてもらったものをレビューしてコミットする、という流れを考えました。 調整というほど大仰な作業ではないですが、 ブランチ運用との連動だったり、CIの実行環境についてだったりを話しているうちに新たな要件が湧いてくるので、 丸投げする・されるものではないなと感じています。 また、CIの設定ファイルは基本的にソースファイルと同じリポジトリで管理する必要があるので、 丸投げされたときにSREチームがコミットするのかどうかも相談しないといけません。 <h2 id="h1670d427ea">開発者のスキルとCI/CD</h2> 自分が一番モヤモヤしているのはここです。 SREチームがうまく開発チームと連動していい感じに責務分担できたとして、 CI/CDに関するナレッジはどこに溜まるのでしょうか？ 開発チームのメンバーに知見として蓄積されていかないのではないでしょうか？ 自分は未経験でこの業界に入りましたが、 2年目の時に小さな開発チームの中で、GitLabの構築からCI/CD環境の整備までを担当する機会があり、 そこで幅広い知識を身につけることができた経験があります。 昨今ではCI/CDはコンテナ環境で実行されることが多く、 Linuxについての基礎的な知識からDockerに関する知識など、運用にあたって様々なスキルが要求されます。 難易度は高いですが、1段目線を上げることのできる機会にもなり得ると思いますし、 それゆえに「SREチーム」がその経験を奪ってしまう構図を少し残念に感じています。 きっと観点がずれていて、SREチームは開発組織としての効率化やオペレーションの最適化を考える上で必要なのだろうと感じています。 ただ、業務で得られる経験値はSREの分野はとても大きいので、それをどうやって組織に還元することができるのかも悩ましいです。

SREとCI/CD

mishio

最近POGの集計用サイトを自作しました。 <a href="https://ouchi-pog.vercel.app/" target="_blank" rel="noopener noreferrer">https://ouchi-pog.vercel.app/</a> 特に意識してなかったのですが、ふと思い立ってLighthouseのスコアを計算してみたところ、 なんと満点が記録できました。 （PWAは改善点ありですが） <img src="https://images.microcms-assets.io/assets/662af00d6f2f4f2eb4714bdc9fcdb3d1/610d4ca21ccc4495a4a0e9ddc3524ab7/lighthouse.png" alt=""> 全ページSSGで特に動きのある処理はないのでまあ当然といえば当然なのですが、 100 が揃うと気持ちいいですね。Next.jsの恩恵がでかいです。 このブログのスコアは壊滅的なので、早く改善したい。。

自作サイトのLighthouseスコアが満点になりました

Lighthouseのスコアが満点に

前回更新からかなり間が開きましたが、仕事が落ち着いてきたのでまたぼちぼち更新していこうと思います。<h2 id="h0a73125737">更新しなかった理由</h2><ul><li>仕事が忙しい</li><li>ブログの更新が面倒くさい</li><li>microCMSのプランが変わった</li></ul> ...自作しておいて面倒くさいってなんやねん、とツッコミたくなるところですが、 自分の性格への理解が足りていませんでした。 巷で見かけるおしゃれなブログに憧れて装飾性を頑張った結果、 投稿するコストが高くなって億劫になっていたのでした。 特にサムネイル画像。 これはいらなかった！ 全部Sketchで自作していたのですが、文章よりも時間がかかって本末転倒でした。 書きたいのは文章なので、「文章さえかけばいい」状態にして執筆環境を整えます。 3つ目の料金プランについて。 このブログの記事管理で使っているmicroCMSの料金プランが変更になりました。 <a href="https://microcms.co.jp/news/20211129-01/" target="_blank" rel="noopener noreferrer">料金プラン改訂のお知らせ</a> 2021/12/16 現在の料金プラン <img src="https://images.microcms-assets.io/assets/662af00d6f2f4f2eb4714bdc9fcdb3d1/d3a1cbf9b36f499a83de43c7e326169a/image.png" alt=""> 2022/1/17 からの料金プラン <img src="https://images.microcms-assets.io/assets/662af00d6f2f4f2eb4714bdc9fcdb3d1/862acc23c0b54cb9bf64cd2b811b15d7/image.png" alt=""> 無償プランである「Hobby」を使っていましたが、 使用できる機能が大幅に制限されました。 APIが3本までになったのは痛いです。 気に入っているサービスなのでお金を払うことに抵抗はあまりないのですが、 趣味に月5000円は高すぎる。いいスペックのサーバーレンタルできるやん。 使用している機能が動かなくなるので対応しないとなーと思っていて3ヶ月ほどが過ぎてしまいましたが、 これを機にいらない機能をそぎ落としていきたいと思います。

ブログをリファクタリングします（予告）

<h2 id="h2800f317ae">Markdownで書けるようにした</h2><a href="https://mishio-blog.vercel.app/c6dpns60ojqf" target="_blank" rel="noopener noreferrer">前回の記事</a>ではHTMLで書いていましたね。 正直、ビミョーだなーと思っていたのでmarkdwon形式にも対応するようにしました。 <h3 id="hde5af457f4">マークダウンでの書き方</h3><pre><code>:::note info
markdown
:::

:::note warn
markdown
:::</code></pre> <h3 id="hb6509f48bf">結果</h3>

:::note info
markdown
:::

:::note warn
markdown
:::


ブログをadmonition対応させてみる【markdown】

<h2 id="h714e2736f4">Admonitionとは</h2>マークダウンの記法の1つで、注釈や強調を表現するものです。 あくまでも拡張記法なので呼び方はさまざまで、Qiitaではnote記法と呼ばれているようです。 <a href="https://qiita.com/kazuki43zoo/items/680572c361dcca1a484c" target="_blank" rel="noopener noreferrer">https://qiita.com/kazuki43zoo/items/680572c361dcca1a484c</a> アイコンや色つきの背景で表現するのが通例のようですね。 <h2 id="h6b718c1867">書いてみる</h2>microCMSのリッチエディタでは当然書けないので、 マークダウンかHTMLを直接書くことになります。 マークダウンで書くとremarkなどでparseする必要があるので、 今回はHTMLにします。スタイルを当てるだけでいいので。

<div class="note info">
 補足情報とかを表現
</div>
<div class="note warn">
 注意を表現
</div>
<div class="note alert">
 警告を表現
</div>

ブログをadmonition対応させてみる

<h2 id="h45cc967e49">バージョンとコードネーム</h2>Vueのマイナーバージョンには、アニメ名がコードネームとして使われています。 AndroidバージョンのようにAから順に、 各アルファベットで始まるアニメが採用されているようです。

Androidはアルファベット順にお菓子の名前が採用されていましたが、 ネタが尽きたのかQから廃止になりましたね。 vue はどこまで続くんでしょうか。 <h3 id="h3de35099b3">参考</h3><a href="https://github.com/vuejs/vue-next/releases" target="_blank" rel="noopener noreferrer">https://github.com/vuejs/vue-next/releases</a> <a href="https://github.com/vuejs/vue/releases" target="_blank" rel="noopener noreferrer">https://github.com/vuejs/vue/releases</a>

Vueのコードネーム

<h2 id="h2e73004920">Prisma</h2><a href="https://www.prisma.io/" target="_blank" rel="noopener noreferrer">https://www.prisma.io</a> <blockquote>Next-generation Node.js and TypeScript ORM</blockquote> Node.js / TypeScript の次世代ORM、Prisma の紹介です。 前々から話題にはなっていましたが、 2021/6月にツールセットが出揃ったので、記事を書いてみました。 <h2 id="h936a85c2ef">Node.js の ORM</h2> サーバーサイドJS（Node.js） のフレームワークである express や、 NestJS は、 自身が ORM を持っているわけではなく、&nbsp;&nbsp; 数あるライブラリの中から選定して組み合わせる形になります。&nbsp; 有名なのは Sequelize と TypeORM の 2 つです。&nbsp;&nbsp; どちらもマイグレーション機能があるなど高機能かつ、サポートしている DB も豊富で人気がありますが、&nbsp;&nbsp; TypeScript との親和性を考えると TypeORM に軍配があがるかなという感じでした。&nbsp;&nbsp; ※あくまでも個人の主観です。 ただ、TypeORM を使うとアノテーション（デコレーター）を多用せざるを得なくなってしまうので、&nbsp;&nbsp; 好みが分かれるところではあります。&nbsp;&nbsp; 私はプライベートでは基本的にバックエンドも TypeScript（Node.js）で書くことが多いのですが、&nbsp;&nbsp; どちらも「めっちゃ使いやすい！」とは感じませんでした。 <h2 id="h3b863d1620">Prisma の 登場</h2> そんな中、2020 年 6 月 に Prisma v2 がリリースされました。 Prisma Client, Prisma Migration, Prisma Studioというツール群で構成されている、 オープンソースのORMです。 ※Prisma v1 は ORM というよりは GraphQL サーバ みたいな感じで、ほぼ別物になります 個人的に感じた Prisma の特徴を挙げてみます。 <ul><li>スキーマファイルでモデルを定義できる</li><li>マイグレーション機能</li><li>DB 操作時のクエリが型付きで書ける</li><li>データベースの GUI クライアント</li></ul> <h2 id="hbb6a8f9be6">スキーマファイルでモデルを定義できる</h2> prisma.schema にモデルを定義します。 ※プライベートで書いてるコードを貼ってみます<pre><code>model Account {
&nbsp;id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Int&nbsp;&nbsp;&nbsp;&nbsp;@id @default(autoincrement())
&nbsp;compoundId&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;String&nbsp;&nbsp;@unique
&nbsp;userId&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Int
&nbsp;providerType&nbsp;&nbsp;&nbsp;&nbsp;String
&nbsp;providerId&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;String
&nbsp;providerAccountId&nbsp;String
&nbsp;refreshToken&nbsp;&nbsp;&nbsp;&nbsp;String?
&nbsp;accessToken&nbsp;&nbsp;&nbsp;&nbsp;String?&nbsp;&nbsp;@db.LongText()
&nbsp;accessTokenExpires DateTime?
&nbsp;createdAt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DateTime&nbsp;@default(now())
&nbsp;updatedAt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DateTime&nbsp;@default(now())

&nbsp;@@index([providerAccountId], name: "providerAccountId")
&nbsp;@@index([providerId], name: "providerId")
&nbsp;@@index([userId], name: "userId")
}

model Session {
&nbsp;id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Int&nbsp;&nbsp;&nbsp;@id @default(autoincrement())
&nbsp;userId&nbsp;&nbsp;&nbsp;&nbsp;Int
&nbsp;expires&nbsp;&nbsp;&nbsp;DateTime
&nbsp;sessionToken String&nbsp;&nbsp;@unique
&nbsp;accessToken&nbsp;String&nbsp;&nbsp;@unique
&nbsp;createdAt&nbsp;&nbsp;DateTime @default(now())
&nbsp;updatedAt&nbsp;&nbsp;DateTime @default(now())
}

model User {
&nbsp;id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Int&nbsp;&nbsp;&nbsp;&nbsp;@id @default(autoincrement())
&nbsp;name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;String?
&nbsp;email&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;String?&nbsp;&nbsp;@unique
&nbsp;emailVerified DateTime?
&nbsp;image&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;String?
&nbsp;createdAt&nbsp;&nbsp;&nbsp;DateTime&nbsp;@default(now())
&nbsp;updatedAt&nbsp;&nbsp;&nbsp;DateTime&nbsp;@default(now())
&nbsp;Betting&nbsp;&nbsp;&nbsp;&nbsp;Betting[]
}</code></pre>モデルを完全にソースコード（ts ファイル）から分離していて、&nbsp;&nbsp; 他の ORM と毛色が違っていますね。 書き方はドキュメントを見ながらになりますが、 公式が提供しているVSCode拡張でフォーマットできたりするので、かなり快適でした。 <a href="https://github.com/prisma/language-tools" target="_blank" rel="noopener noreferrer">https://github.com/prisma/language-tools</a> もちろんGit管理できます。 <h2 id="h5911738a10">マイグレーション</h2> prisma migrate コマンドにより、マイグレーションファイル（SQL）を発行できます。 初回起動時はもちろん、スキーマ変更時もSQLが生成されます。 こんな感じです。<pre><code>-- CreateTable

CREATE TABLE `User` (
&nbsp;&nbsp;`id` INTEGER NOT NULL AUTO_INCREMENT,
&nbsp;&nbsp;`name` VARCHAR(191),
&nbsp;&nbsp;`email` VARCHAR(191),
&nbsp;&nbsp;`emailVerified` DATETIME(3),
&nbsp;&nbsp;`image` VARCHAR(191),
&nbsp;&nbsp;`createdAt` DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
&nbsp;&nbsp;`updatedAt` DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
&nbsp;&nbsp;UNIQUE INDEX `User.email_unique`(`email`),
&nbsp;&nbsp;PRIMARY KEY (`id`)
) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;</code></pre> また、マイグレーションの実行・ロールバックもコマンドで可能です。 ※SQLなのでGit管理できるんですが、複数人開発でうまくいくイメージがつかない... <h2 id="h315ee9943a">DB 操作時のクエリが型付きで書ける</h2>公式のページがすごくわかりやすいのでご覧ください。 <a href="https://www.prisma.io/client" target="_blank" rel="noopener noreferrer">https://www.prisma.io/client</a> prisma generate コマンドにより、スキーマファイルからTypeScriptの型定義ファイルを生成できます。 デフォルトだと node_modules/.prisma/client/ に出力されます。 この型定義を使うことで、select, where も型安全に実行できるようになります。 <h2 id="h71c543767b">データベースの GUI クライアントが備わっている</h2>prisma studio コマンドで、ブラウザから閲覧できるビューワーが立ち上がります。 簡単なCRUD 操作も可能です。 また、公式からデスクトップ版をインストールする方法もあるみたいです。 こちらのツールはオープンソースではないようで、ソースの公開はされていません。 DBクライアントツールを使っている場合はあまり魅力に感じない機能かもしれませんが、 個人的にはポイントが高い機能です。 <h2 id="h9710ffdf15">余談</h2>JavaScript界はフロントエンドもフレームワークが群雄割拠していますね。 フロントエンド・バックエンドもJavaScriptで書くケースは多いですし、 フレームワーク選定も楽しみの一つかと思います。 そして、JavaScript界には両方の面倒をみるフルスタックフレームワークも存在します。 <a href="https://github.com/frouriojs/frourio" target="_blank" rel="noopener noreferrer">frourio</a>, <a style="color:#000000" href="https://blitzjs.com/" target="_blank" rel="noopener noreferrer">blitz.js</a>, <a style="color:#000000" href="https://redwoodjs.com/" target="_blank" rel="noopener noreferrer">RedwoodJS</a> などですね。 これらに共通しているのは、 フロントエンドとしてNext.js(React)を、ORMとしてPrismaを採用している点です。 TypeScriptがJavaScript開発環境のスタンダードになったように、 PrismaがNode.jsのORM界を統一していく流れを感じました。 <h2 id="ha214098e44">まとめ</h2>Next-generation ORM と謳っているだけあって、未来感のある ORM・ツールではないでしょうか。&nbsp;&nbsp; 現在は TypeScript/JavaScript のみに対応していますが、&nbsp;公式 HP をみると Go にも対応しそうです。 バックエンドは Go で書くぜ！って人もお世話になることがあるかもしれません。 わりと変更が頻繁に入るので、業務でガッツリ使うのはそれなりにチャレンジな気もしますが、 そこは勢いのあるフレームワークを使う上で避けては通れない点ですね。 まだあまり使いこなせていないので、これからガンガン触っていきたいと思います。

Prisma ~Node.jsの次世代ORM~

<h2 id="h269a2aec6f">ブログ始めました</h2> これまで、WordPressを構築したり、hatenaブログ、noteで記事を書いたことはありましたが、 いまいちピンときませんでした。 「自作ブログ」への憧れがあったので、 どこか書かされている感があったからなのかなと思っています。 <h2 id="h023a6924b5">Next.js × microCMS</h2> GatsbyやNuxt.jsでやろうとしたこともありましたが、 構築でうまくいかずほったらかしにして軌道に乗りませんでした。 今回、使ってみたかった microCMS と 最近使い方がわかってきた Next.js で構築しています。 microCMSの公式さんがチュートリアルも出してくれたりしていて、かなりスムーズに立ち上げることができました。 microCMSのエディタも、入稿している感がしっかりでるので Good ですね！ UIはいろんなサイトを見ながら試行錯誤中です。 公式さんをベースにしていますが、自分の色を出そうとして失敗しています笑。 <h2 id="h48923e48db">コンテンツについて</h2> 技術に関するものを中心に、趣味に関しても書いていきたいです。 日記感覚で投稿していけたらなと思っています。 今のところ、カテゴリーは以下のようなラインナップになるかなと考えています。 <ul><li>プログラミング</li><li>TypeScript</li><li>Node.js</li><li>自作サービス・コンテンツ</li><li>アニメ</li><li>小説・ライトノベル</li><li>競馬</li><li>ゲーム</li></ul> 自分の好きなこと・学んだこと・感じたことについて、 自分のペースで発信していきたいと思っています！