shwld

はじめにmofmofではDevOpsを推進しており、たくさんのプロジェクトに導入が進んでいます。ここでは、そのうち2つの異なるプロジェクトの振り返りを通じて、私たちが直面した課題、取り組んだ改善策、そして得られた教訓を共有します。2つのプロジェクトの特徴今回DevOpsの取り組みを実践する対象となった2つのプロジェクトの特徴は以下のとおりです。プロジェクト1プロジェクトメンバーの数: 4~6人程度新規機能開発はなく、保守がメイン。バージョンアップ対応やセキュリティ関連対応などが主プロジェクト2プロジェクトメンバーの数: 7~8人程度既存システムを複数持っており、既存システムの保守と新規機能開発、新規プロダクト開発を並行で行なっている。共通の目標：リードタイムの短縮両プロジェクトの主要な目標は、リードタイムを1週間以内に短縮することでした。しかし、この目標はいずれのプロジェクトでも完全には達成されませんでした。プロジェクト1は開始から3ヶ月でリードタイムを2.17週間に、6ヶ月で1.82週間に短縮。一方、プロジェクト2では開始3ヶ月で4週間となり、6ヶ月後も変化はありませんでした。要因としてどちらのチームもその時に大規模なアップデート作業を行なっていたというものがあります。今回のDevOpsの取り組みの大きな壁となりましたが、大きなアップデートを小さく分けてリリースすることの大事さを考える良いきっかけになりました。今回は半年間の振り返りなので数値には現れませんでしたが、7ヶ月目以降プロジェクト2は改善が数値に表れており、7ヶ月後の時点ではリードタイムが1.4週間まで短縮できています。計測環境https://github.com/dora-team/fourkeysDORAチームが提供しているこちらのツールをforkして使っています。分析や運用をする中でフィードバックを得て結構カスタマイズしており、以下のようなことが追加でできるようになっています。d/d/dの計測と表示デプロイ履歴の一覧表示複数プロジェクトで使えるPivotalTrackerを使った障害関連指標の計測指標の見方や説明ドキュメントをダッシュボードに表示課題と対策リードタイムの短縮を共通の目標としましたが、DevOpsの活動自体が初めてであり、いろいろと手探りした結果、まずはリードタイムを縮めるという方向に途中で切り替えました。半年間で遭遇した課題と対策を紹介します。初期段階の手探りDevOpsを導入するにあたり、最初はどの指標を見るべきか、どのような活動が効果的かなど、手探りの状態でした。色々な事例をみたり、外部の意見を聞く、実際に指標を改善しようとしてみるなどし、リードタイム1週間を目標とする方向性を決定しました。書籍としてはLeanとDevOpsの化学)と、The DevOps ハンドブック 理論・原則・実践のすべて) を参考にしました。CI環境の改善どちらのプロジェクトもアップデート作業が大きなタスクでした。アップデート作業をする中で、自動化しておきたい箇所は積極的に自動化を進めました。手動での確認作業を減らし、リリース時の安心感を高めるため、CI環境の改善を行いました。これには、チェック対象の追加やテスト項目の拡充が含まれます。プロジェクト2はアップデートと機能開発を今後も並行して進めやすいよう、フィーチャーフラグの導入を開始し、徐々に効果が出始めています。デプロイプロセスのドキュメント改善デプロイに関わる手動の対応を減らすため、ドキュメントの不明瞭な部分を改善しました。最終的には全員がデプロイできる状態。また、全て自動化できていることが理想ですが、まずは現状の手動対応部分をできるだけ多くのメンバーでできるようにすることに手をつけました。定期的な分析定期的に分析する会を実施しています。分析会は時間がかかるので、まずは内部の開発者のみで分析を行なっています。ボトルネックが開発者側にあればそれを改善し、運用側にあれば課題としてあげるという進め方をしています。プロジェクトにおける変化ストーリーを細かく分け、効率化を目指す意識がチーム内で芽生えました。また、行う改善が数値にどのように影響するか、パフォーマンスが向上するかを実施前に考慮するようになりました。今後の展望これらの取り組みはまだ始まったばかりです。数値としての結果はまだあまり出ていませんが、改善の意識づけやボトルネック探しのツールとしての指標など良い影響が出ていると感じます。引き続き、リードタイムの短縮を目指して、地道な改善を続けていく予定です。まとめDevOpsの取り組みは一朝一夕に成果が現れるものではありません。この半年間の経験から、目標としての指標設定の重要性、チームの取り組み方の変化、そして小さな改善の継続して積み重ねることの重要性を学ぶことができました。

DevOps活動の半年間の振り返り

https://docs.github.com/ja/copilot/github-copilot-chat/using-github-copilot-chat-in-your-ideGitHub CopilotのCLI版です。2023年12月5日現在パブリックベータで公開されています。インストールgh auth logingh extension install github/gh-copilotgh extension upgrade gh-copilot使い方Your AI command line copilot.Usage: copilot [command]Examples:$ gh copilot suggest "Install git" $ gh copilot explain "traceroute github.com"Available Commands: config Configure options explain Explain a command suggest Suggest a commandFlags: -h, --help help for copilot -v, --version version for copilotUse "copilot [command] --help" for more information about a command.explain suggest の2つコマンドがあるので、それぞれ見ていきます。gh copilot explain コマンドについて解説してもらうgh copilot explain “common”のように入力するとコマンドについての解説をしてくれますgh copilot explain ls? Allow GitHub to collect optional usage data to help us improve? This data does not include your queries.> YesWelcome to GitHub Copilot in the CLI! version 0.5.3-beta (2023-11-09)I'm powered by AI, so surprises and mistakes are possible. Make sure to verify any generated code or suggestions, and share feedback so that we can learn and improve.Explanation:• ls is used to list files and directories in the current directory. • If no arguments are provided, it lists the files and directories in the current directory. • It displays the names of the files and directories in a columnar format. • It does not show hidden files and directories by default.gh copilot explainを実行することで、対話的に入力することもできます。gh copilot explainWelcome to GitHub Copilot in the CLI! version 0.5.3-beta (2023-11-09)I'm powered by AI, so surprises and mistakes are possible. Make sure to verify any generated code or suggestions, and share feedback so that we can learn and improv ? Which command would you like to explain?jq 'walk(if type == "object" and has("rawSql") then .rawSql |= gsub("\r|\n"; " ") else . end)'Explanation:The provided command is using the jq command-line JSON processor. Here is a breakdown of the command:• Use the jq command-line JSON processor. • walk is a built-in function in jq that traverses the input data recursively. • if type == "object" and has("rawSql") then .rawSql |= gsub("\r|\n"; " ") else . end is the conditional expression that is applied to each element during the traversal. • type == "object" checks if the current element is an object. • has("rawSql") checks if the object has a key named "rawSql". • |= is the in-place update operator in jq. • gsub("\r|\n"; " ") is a string manipulation function that replaces all occurrences of carriage return and newline characters with a single space. • else . end is the "else" clause that returns the original element if the conditions are not met.Please note that the provided command might be part of a larger script or pipeline, and its functionality depends on the input data structure and intention.日本語で解説してもらいたい気持ちになりますね…簡単なコマンドの説明ならやってくれました。gh copilot explainWelcome to GitHub Copilot in the CLI! version 0.5.3-beta (2023-11-09)I'm powered by AI, so surprises and mistakes are possible. Make sure to verify any generated code or suggestions, and share feedback so that we can learn and improve.? Which command would you like to explain?> 日本語で "ls" の説明Explanation:• ls はディレクトリやファイルのリストを表示するコマンドです。 • -a オプションは、隠しファイルを含めた全てのファイルやディレクトリを表示します。 • -l オプションは詳細な情報を含む長い形式で表示します。 • -r オプションはリストを逆順に表示します。 • -t オプションは最終更新時刻に基づいてリストをソートして表示します。少しコマンドが長くなると、プロンプトは認識されませんでした。gh copilot explainWelcome to GitHub Copilot in the CLI! version 0.5.3-beta (2023-11-09)I'm powered by AI, so surprises and mistakes are possible. Make sure to verify any generated code or suggestions, and share feedback so that we can learn and improve.? Which command would you like to explain?> 日本語で find / -name "*.pdf" -exec mv {} ~/Downloads/ \; を説明Explanation:• find / is used to search for files in the root directory. • -name "*.pdf" filters the search to files that have the extension .pdf. • -exec mv {} ~/Downloads/ ; executes the mv command for each found file, moving it to the ~/Downloads/ directory. • {} represents the file name that is passed as an argument to the mv command. • ; marks the end of the -exec statement.gh copilot suggest コマンドの提案を受ける自然言語でやりたいことを入力すると、実行すべきコマンドを提案してくれます。gh copilot suggestWelcome to GitHub Copilot in the CLI! version 0.5.3-beta (2023-11-09)I'm powered by AI, so surprises and mistakes are possible. Make sure to verify any generated code or suggestions, and share feedback so that we can learn and improve.? What kind of command can I help you with? [Use arrows to move, type to filter]> generic shell commandgh commandgit command実行すると、どのカテゴリのコマンドを生成するのかを聞かれます。generic shell command（汎用シェルコマンド）を選択してみます。? What would you like the shell command to do?> pdfファイルを探してdownloadへ移動するSuggestion:find . -name "*.pdf" -exec mv {} download/ ;? Select an option [Use arrows to move, type to filter]> Copy command to clipboardExplain commandRevise commandRate responseExit選択すると、 find . -name "*.pdf" -exec mv {} download/ ; というコマンドを提案してくれました。提案されたコマンドについてのアクションを選択できます。Copy command to clipboard: クリップボードへコピーExplain command: コマンドを説明してもらうRevise command: コマンドを修正する。コマンドの修正指示を自然言語で行えますRate response: 応答を評価できますExit: 終了最後にGitHub Copilot CLIを使ってみました。自分が作ったコマンド（プロジェクトのpackage.jsonに書かれたコマンドなど）はサジェストしてくれないみたいなのは残念。とはいえ、CLIでやりたいことやgitコマンドの提案を受けられるのは便利なので、使っていきたいです。

GitHub Copilot CLIを試してみた

タイトルのとおりですが、NestJSのGraphQL利用時に、Firebase Authenticationの idToken を使って認証する実装方法について考えました。前提以下のようなデータベーステーブルを定義しています。// Firebaseアカウントと同期されるテーブルmodel Account {  id              String  @default(uuid()) @id  firebaseAuthUid String  @unique // Firebase Authenticationのuidをセットする  email           String?  @unique  user            User?  @@index([firebaseAuthUid])}model User {  id        String  @default(uuid()) @id  name      String  tasks     Task[]  account   Account @relation(fields: [accountId], references: [id])  accountId String @unique}まずはfirebase-adminを初期化bootstrap時に初期化を行っておきます。import { NestFactory } from '@nestjs/core';import { AppModule } from './app.module';import { initializeFirebaseAdmin } from './_initializers/initialize-firebase-admin';import { LoggerService } from './common/logger/logger.service';import { ServiceAccount, getApps, initializeApp } from 'firebase-admin/app';import { credential } from 'firebase-admin';function initializeFirebaseAdmin() {  const cert: ServiceAccount = {    projectId: process.env.FIREBASE_PROJECT_ID,    clientEmail: process.env.FIREBASE_CLIENT_EMAIL,    privateKey: process.env.FIREBASE_PRIVATE_KEY?.replace(/\\n/g, '\n'),  };  if (getApps().length === 0) {    initializeApp({      credential: credential.cert(cert),    });  }}async function bootstrap() {  initializeFirebaseAdmin();  const app = await NestFactory.create(AppModule, {    logger: new LoggerService(),  });  await app.listen(3002);}bootstrap();次にFirebase Authenticationで取得できるidTokenをAuthorizationヘッダから受け取りdecodeするためのMiddlewareを書きます。MiddlewareはNestJSがルーティングを行う前に処理を挿入でき、Requestを拡張することができます。これを使って、RequestからAuthorization headerを読み取り、idTokenを取得してDBからユーザーレコードを引っ張り、Requestに詰めてあげます。import { Injectable, NestMiddleware } from '@nestjs/common';import { NextFunction, Response } from 'express';import { getAuth } from 'firebase-admin/auth';import { RequestWithCurrentUser } from '../interfaces/request-with-current-user';import { AccountRepository } from '../repositories/account.repository';@Injectable()export class FirebaseAuthMiddleware implements NestMiddleware {  constructor(private readonly accountRepository: AccountRepository) {}  async use(req: RequestWithCurrentUser, _: Response, next: NextFunction) {    const { authorization } = req.headers;    req.currentFirebaseUser = null;    if (authorization) {      const [scheme, token] = req.headers.authorization?.split(' ') ?? [];      if (scheme === 'Bearer') {        const decodedIdToken = await getAuth().verifyIdToken(token);        const currentFirebaseUser = {          uid: decodedIdToken.uid,          email: decodedIdToken.email ?? null,        };        const account =          await this.accountRepository.findOrCreateByFirebaseAuthUid(            currentFirebaseUser,          );        req.currentFirebaseUser = currentFirebaseUser;        req.currentAccount = account;        req.currentUser = account.user ?? null;      }    }    next();  }}Middlewareを登録するFirebaseAuthMiddlewareを利用するためにAppModuleに設定を書きます。ルーティング毎に設定できますが、今回は /graphql のみ反映できれば良いですが、他にルートもないのでforRoutes('*')に設定しています。// ...略export class AppModule {  configure(consumer: MiddlewareConsumer) {    consumer.apply(FirebaseAuthMiddleware).forRoutes('*');  }}現在のユーザーを取得するデコレータを作成するimport { createParamDecorator, ExecutionContext } from '@nestjs/common';import { GqlExecutionContext } from '@nestjs/graphql';import { RequestWithCurrentUser } from '../interfaces/request-with-current-user';import { User } from '~/user/entities/user.entity';export type CurrentUser = User | null;export const CurrentUser = createParamDecorator(  (_data: unknown, ctx: ExecutionContext): CurrentUser => {    const gqlContext = GqlExecutionContext.create(ctx);    const req: RequestWithCurrentUser = gqlContext.getContext().req;    return req.currentUser;  },);作ったデコレータを利用して、現在のユーザーを取得するには以下のようにします。import { CurrentUser } from '~/auth/current-user.decorator';@ResolveField(() => [Task], { nullable: false })async tasks(@CurrentUser() user: CurrentUser) {  if (user == null) return [];  const tasks = await this.taskRepository.findMany({    ownerId: user.id,  });  return tasks;}これでResolveFieldやMutationなどで、CurrentUserを手軽に扱えるようになります今回載せたコードを含むサンプルはこちらにあります。https://github.com/shwld/nest-js-todo-example

NestJSでGraphQL利用時にFirebase認証結果をデコレーター@CurrentUserで取得できるようにする

NestJS はNode.jsでサーバーサイドアプリケーションを構築するためのフレームワークです。mofmofではNestJSに力を入れています。今回は、他のフレームワークでサーバーサイドアプリケーション構築経験のあるエンジニアが、NestJSに入門する際に何を知っておくべきなのか考えてみました。まずは@DecoratorNestJSのコードで @Module や @Controller など、 @ のついたコードを良く見ます。これはTypeScriptのDecoratorというものです。簡単に言ってしまうと、対象となるクラスやメソッドを受け取って拡張する高階関数のシンタックスシュガーとも言えるものです。それぞれのDecoratorはなんとなくの使い方はわかると思いますが、最初は魔法のように見えます。高階関数だという前提で各種Decoratorのソースコードを読んでみると理解が深まりやすいと思いました。NestJSの依存関係解決についてNestJSの依存関係管理の仕組みを知るには、ProviderとModuleが重要です。NestJSではサービス、リポジトリ、ファクトリ、ヘルパーなどのクラスを Providerと呼び、扱います。Providerを依存関係として管理し、適切に利用できるようにするための機能がNestJSに備わっています。Module以下のように@Moduleでデコレートされたクラスがモジュールです。https://docs.nestjs.com/modulesimport { Module } from '@nestjs/common';import { DogsModule } from '../dogs/docs.module';import { CatsController } from './cats.controller';import { CatsService } from './cats.service';@Module({  imports: [DogsModule],  providers: [CatsService],  exports: [CatsService],  controllers: [CatsController],})export class CatsModule {}Moduleにはいくつかのプロパティを渡す事ができ、とても重要。CatsModuleについて見てみる。imports外部のModuleへの依存を記述する。importしたModuleのexportsに定義されたProviderがModule内で利用可能になるprovidersModuleで利用するProviderをここへ定義する。CatsModule内でCatsサービスを利用することが可能になるexportsCatsModuleをインポートする外部モジュールが使えるようになるProviderを定義する。ここに記述したものが外部からこのModuleを見たときのインタフェースといえる。controllersControllerはHttpリクエストを受け渡すクラスです。ここに登録したControllerが、起動時にインスタンス化されます。NestJSの大きな特徴である依存関係の管理周りを見てみました。その他おさえておきたい登場人物ミドルウェアNestJSはhttpサーバーとしてExpressをデフォルト採用していますが、Expressの拡張を行うミドルウェアという機構と同等のものがNestJSのミドルウェアのようです。なので、httpリクエストやレスポンスをゴニョゴニョするようなときにこれを使うのがよいのではないかと思います。例外フィルター未処理の例外をキャッチし、httpレスポンスに変換したりできる。Pipe変換と検証を行うための機構@Get(':id')async findOne(@Param('id', ParseIntPipe) id: number) {  return this.catsService.findOne(id);}ParseIntがPipeです。この指定で、idがnumberであることが保証されます（numberでない場合は例外になる）Guardsデコレータを用いて、認証、認可機構を実現する。基本的にはコントローラーやコントローラーのアクションメソッドをデコレートして利用します。Interceptorメソッド実行の前後に余分なロジックをバインドするメソッドから返された結果、例外を変換するメソッドの動作を拡張する// ロギング処理を付け加えるInterceptor@UseInterceptors(LoggingInterceptor)export class CatsController {}まとめNestJSを学ぶ際に最初に抑えておきたい登場人物を挙げてみました。NestJSは公式ドキュメントがしっかりあるので、そちらに目を通すと大抵のことは解決するのかなと思います。

NestJSを学ぼう

こんにちはエンジニアのshwldです。「LIKE検索で引っかからないような検索ワードでも関連性が高いなら検索結果に出したい」このようなニーズは多くあると思いますが、実装するのは結構大変です。mofmofが提供しているMy-opeでは、チャットボットに質問すると質問と関連性の高いドキュメントを提示してくれますが、内部ではPythonを用いたコサイン類似度検索を行っています。Elasticsearchでも行なえますが、学習も導入も管理もコストが掛かります。今回はコサイン類似度検索をLangChain等を使うことで手軽に実装する方法について書きます。コサイン類似度検索とは?2つのベクトルの向きがどのくらいにているかを比べ検索に用いる方法です。こちらの記事がわかりやすいです。https://atmarkit.itmedia.co.jp/ait/articles/2112/08/news020.htmlコサイン類似度を用いて検索するためには、検索対象となるドキュメントをベクトルに変換する必要があります。ベクトル化されたドキュメントと同じ方法で検索ワードもベクトル化し、その向きを比べます。自分で実装する場合には、以下のような処理になります。ベクトル化1. ドキュメントを形態素解析する2. 形態素に分解されたドキュメントをベクトル化する3. ベクトルを保存しておく検索1. 検索ワードを形態素解析する2. 形態素に分解された検索ワードをベクトル化する3. 保存されたドキュメントのベクトルから類似度の高いドキュメントを検索する最新の技術を使って楽に実装する方法を考えてみました。「ベクトル化にOpenAIのEmbedding APIを用いたら良さそう」OpenAIにEmbedding APIというものがあります。https://platform.openai.com/docs/guides/embeddings/what-are-embeddingsこのAPIは、与えた文章をベクトルに変換してくれます。形態素解析を意識せずともこのAPIにテキストを投げるだけで賄ってくれるので、手軽に実装できるようになります。「Postgresのpgvectorを用いたら良さそう」Postgresに導入することで、ベクトルデータの保存と、ベクトルの類似度によるソートを行えるようになります。https://github.com/pgvector/pgvector動かしてみる今回は、PrismaとLangchain.jsを利用します。メモを登録でき、登録したメモを類似度による検索に対応させることにしましょう。Prismaでpgvectorを扱えるようにする検索対象となるメモとベクトルデータを保存するテーブルを定義するメモテーブルに検索用のデータを突っ込むメモの登録時に内容をベクトル化して保存するコサイン類似度によるメモ検索1. Prismaでpgvectorを扱えるようにする※ postgresにpgvectorをインストールしておく必要があります。また、Neonなどではpgvectorを利用できます。※ 今回はローカル環境で確認するために公式ドキュメントにも記載のあるDockerイメージを利用しました ankane/pgvectorgenerator client {  provider        = "prisma-client-js"  previewFeatures = ["postgresqlExtensions"]}datasource db {  provider   = "postgresql"  url        = env("DATABASE_URL")  extensions = [vector()]}2. 検索対象となるメモとベクトルデータを保存するテーブルを定義するmodel Memo {  id         String          @id @default(uuid())  content    String  createdAt  DateTime        @default(now())  updatedAt  DateTime        @updatedAt  embeddings Embedding[]}model Memo {  id                 Int          @id @default(autoincrement())  content            String  embeddings         Embedding[]}model Embedding {  id                 Int       @id @default(autoincrement())  memoId             Int  memo               Memo    @relation(fields: [memoId], references: [id], onDelete: Cascade)  content            String  vector             Unsupported("vector") // pgvectorで定義されるvector typeのデータ}3. メモテーブルに検索用のデータを突っ込む今回はこちらのデータをダウンロードして、データベースへ流し込みました。https://www.kaggle.com/datasets/tarundalal/japanesenlpこんな感じのデータが入っています。元々は翻訳関連用のデータですが、いろんなカテゴリの話が入っていて、かつ日本語のデータセットとして使えそうだったのでこちらを使いました。中身はこんな感じの内容（流し込む際にはJapan列のみを使用しました）English,Japan"You don't have to see the whole staircase, just take the first step.",階段全体を見る必要はありません。最初の一歩を踏み出すだけです。Your dreams are never too big; your expectations are just too small.,あなたの夢は大きすぎることはありません。あなたの期待は小さすぎます。"Make your life a masterpiece; imagine no limitations on what you can be, have, or do.",あなたの人生を傑作にしましょう。自分がなれること、持つこと、できることに制限がないことを想像してください。"The greatest danger for most of us is not that our aim is too high and we miss it, but that it is too low and we reach it.",私たちのほとんどにとって最大の危険は、目標が高すぎて目標を達成できないことではなく、目標が低すぎて目標を達成してしまうことです。"Your life does not get better by chance, it gets better by change.",あなたの人生は偶然によって良くなるのではなく、変化によって良くなります。"Aim for the moon. If you miss, you may hit a star.",月を目指してください。ミスするとスターに当たる可能性があります。"There is no passion to be found playing small, in settling for a life that is less than the one you are capable of living.",自分の能力以下の人生に甘んじて、小さなことをする情熱は見出されません。You are capable of more than you know.,あなたには自分が知っている以上のことができるのです。"If you can dream it, you can achieve it.",それを夢見ることができれば、それを達成することができます。You have to be odd to be number one.,ナンバーワンになるには奇妙でなければなりません。"Success is not in what you have, but who you are.",成功はあなたが持っているものではなく、あなたが誰であるかにあります。"It's not about how hard you hit, it's about how hard you can get hit and keep moving forward.",どれだけ強く打つかではなく、どれだけ強く打たれても前に進み続けることができるかが重要だ。Life is what happens when you're busy making other plans.,人生とは、他の計画を立てるのに忙しいときに起こるものです。"Believe in yourself, take on your challenges, dig deep within yourself to conquer fears.",自分を信じて挑戦し、自分の内面を深く掘り下げて恐怖を克服しましょう。4. メモの内容をベクトル化して保存するimport { PrismaClient } from '@prisma/client';import { OpenAIEmbeddings } from 'langchain/embeddings/openai';import { RecursiveCharacterTextSplitter } from 'langchain/text_splitter';const prisma = new PrismaClient();const memos = await prisma.memo.findMany();const openAIEmbeddings = new OpenAIEmbeddings();memos.forEach(async (memo) => {  // OpenAIのEmbedding APIに送れるトークン数に制限があるので、適当な長さで区切ります  const splitter = new RecursiveCharacterTextSplitter({    chunkSize: 500,    chunkOverlap: 20,  });  const documents = await splitter.createDocuments([memo.content]);  const contents: string[] = documents.map(({ pageContent }) => pageContent);  // 分割したテキストと、テキストのembeddingを紐付ける  await Promise.all(    contents.map(async (content) => {      const vector = await openAIEmbeddings.embedDocuments([content])      console.log({ content })      return prisma.$executeRaw`                        INSERT INTO "Embedding" (                            "id",                            "content",                            "memoId",                            "vector"                        )                        VALUES (                            DEFAULT,                            ${content},                            ${memo.id},                            ${`[                                ${vector.join(",")}                                ]`}::vector                        )`    })  );});package.jsonにコマンドを追加して実行しましょう"scripts": {  "vectorize": "ts-node --esm ./vectorize.mts"},実行すると以下のようになり、データベースへEmbeddingが保存されました。$ pnpm vectorize> openai-similarity-search-sample@1.0.0 vectorize /home/shwld/projects/try/openai-similarity-search-sample> ts-node --esm ./vectorize.mts{ content: 'これは 10 語以上の単語が含まれる例文です。' }{ content: '子どもたちの遊ぶ笑い声が耳に音楽となって、心が温かくなります。' }{ content: '彼はギターがとても上手で、その音楽的才能でみんなを魅了します。' }{ content: '焼きたてのクッキーの香りが漂い、心地よい気分にさせてくれます。' }{ content: '私はポジティブ思考の力と、それが現実を形作る力を信じています。' }{ content: '愛する人たちと一緒にいると、心に温かさと幸福がもたらされます。' }{ content: '朝の鳥のさえずりが、自然の美しさを優しく思い出させてくれます。' }{ content: '海岸に打ち寄せる波の音は、海の広大さと力強さを思い出させます。' }{ content: '朝、鳥のさえずりを聞くと、楽観的な気持ちと希望が湧いてきます。' }{ content: '私は人々が本来持っている善良さと思いやりの能力を信じています。' }{ content: '私は瞑想し、自分の内なる自己とつながることで平安を見出します。' }{ content: '私は正義と平等のために声を上げる人々の勇気に触発されています。' }{ content: '星空を眺めると、畏怖の念と不思議な気持ちでいっぱいになります。' }{ content: '彼はギターがとても上手で、その音楽的才能でみんなを魅了します。' }{ content: '子どもたちの遊ぶ笑い声が耳に音楽となって、心が温かくなります。' }{ content: '焼きたてのクッキーの香りが漂い、心地よい気分にさせてくれます。' }{ content: '私はポジティブ思考の力と、それが現実を形作る力を信じています。' }{ content: '朝の鳥のさえずりが、自然の美しさを優しく思い出させてくれます。' }{ content: '愛する人たちと一緒にいると、心に温かさと幸福がもたらされます。' }こんな感じの値が入っていました。5. コサイン類似度によるメモ検索import { Embedding, Prisma, PrismaClient } from "@prisma/client";import { OpenAIEmbeddings } from "langchain/embeddings/openai";import { PrismaVectorStore } from "langchain/vectorstores/prisma";const prisma = new PrismaClient();const vectorStore = PrismaVectorStore.withModel<Embedding>(prisma).create(  new OpenAIEmbeddings(),  {    prisma: Prisma,    tableName: "Embedding",    vectorColumnName: "vector",    columns: {      id: PrismaVectorStore.IdColumn,      content: PrismaVectorStore.ContentColumn,    },  });// 検索したい文字をコマンドライン引数から受け取るconst args = process.argv.slice(2);const searchText = args.join(' ');console.log("searchText", searchText)const result = await vectorStore.similaritySearch(searchText, 5)console.log({ metadata: result.map(it => it.metadata) })const embeddingIds: number[] = result.map((result) =>  result.metadata.id);// DB内から取得const embeddingRecords = await prisma.embedding.findMany({ where: { id: { in: embeddingIds } }, include: { memo: true } });// 類似度の高い順に並べたメモを取得するconst memosOrderedByRelatedness = embeddingIds.map((id) => embeddingRecords.find((record) => record.id === id)?.memo);console.log({ memosOrderedByRelatedness })package.jsonにコマンドを追加して実行しましょう"scripts": {  "start": "ts-node --esm ./search.mts"},$ pnpm start さようなら> openai-similarity-search-sample@1.0.0 start /home/shwld/projects/try/openai-similarity-search-sample> ts-node --esm ./search.mts "さようなら"searchText さようなら{  metadata: [    { id: 18, content: 'さようなら！', _distance: 0.037431886141684356 },    { id: 15, content: '良い１日を！', _distance: 0.1411417779062233 },    { id: 20, content: 'ごめんなさい。', _distance: 0.1500157844641241 },    { id: 9, content: 'また後で！', _distance: 0.1572120581664358 },    { id: 19, content: '今何時ですか？', _distance: 0.15959957531603297 }  ]}{  memosOrderedByRelatedness: [    { id: 69, content: 'さようなら！' },    { id: 67, content: '良い１日を！' },    { id: 14, content: 'ごめんなさい。' },    { id: 68, content: 'また後で！' },    { id: 17, content: '今何時ですか？' }  ]}$ pnpm start 映画の話> openai-similarity-search-sample@1.0.0 start /home/shwld/projects/try/openai-similarity-search-sample> ts-node --esm ./search.mts "映画の話"searchText 映画の話{  metadata: [    { id: 63, content: '映画は何時に始まりますか？', _distance: 0.127190263709698 },    {      id: 75,      content: 'あなたの好きな映画は何ですか？',      _distance: 0.13672970711009336    },    {      id: 518,      content: 'その映画はエキサイティングかつサスペンスフルで、私は終始ハラハラしたままでした。',      _distance: 0.15585349371544277    },    {      id: 523,      content: 'その映画はエキサイティングかつサスペンスフルで、私は終始ハラハラしたままでした。',      _distance: 0.15585349371544277    },    { id: 14, content: '考えがある。', _distance: 0.1742977118483362 }  ]}{  memosOrderedByRelatedness: [    { id: 72, content: '映画は何時に始まりますか？' },    { id: 48, content: 'あなたの好きな映画は何ですか？' },    { id: 88, content: 'その映画はエキサイティングかつサスペンスフルで、私は終始ハラハラしたままでした。' },    { id: 242, content: 'その映画はエキサイティングかつサスペンスフルで、私は終始ハラハラしたままでした。' },    { id: 45, content: '考えがある。' }  ]}良さそうです！おわりに少ない実装で類似検索が実装できました。LangchainはTypeScript実装があるので、Pythonでやっていたようなことも手軽に扱えるのが良さそうです。今回の記事のサンプルリポジトリもあります。https://github.com/shwld/openai-similarity-search-sample

LangChainとpgvector(Postgres)を用いて関連性の高いドキュメントを手軽に検索する

mofmofでは fourkeys を用いて開発生産性を計測しています。あるプロジェクトチームが、複数のサービスを管理していました。コードレビュー、マージ、検証というフローを辿ってリリースされるのですが、検証完了後にリリース作業が漏れてしまうケースが有りました。コミュニケーションやフローの改善での対応もしていますが、未リリースのものがあるかどうかの検知もしたい。そこで、定期的にデプロイされていないものをチェックしてSlackへ通知するGitHub Actionsを作りました。デプロイもれをSlackへ通知してくれる作ったGitHub Actionshttps://github.com/marketplace/actions/check-for-deployment-omissionsこの記事ではこのアクションの使い方を紹介します。1. Slackへ通知するためにアプリを作成する以下のページへ行き、Slack Appを作成しますhttps://api.slack.com/apps/From an app manifestを選択このとき、From an app manifest を選択して作成すると、yamlで設定を登録することになるので、以下のyamlを登録します。display_information:  name: Check for Deployment Omissionssettings:  org_deploy_enabled: false  socket_mode_enabled: false  is_hosted: false  token_rotation_enabled: falsefeatures:  bot_user:    display_name: Check for Deployment Omissionsoauth_config:  scopes:    bot:      - chat:write      - chat:write.publicAppが作成されたら、Workspaceにインストールします。Bot User OAuth Token が発行されるので、それをコピーしておきましょう。2. デプロイ漏れを検知したいリポジトリにGitHub Actionsを設定する以下のようなファイルを作成することで設定ができます。.github/workflows/check-for-deployment-omissions.ymlname: 'check-for-deployment-omissions'on:  schedule:    - cron: '0 0 * * 1'jobs:  check-for-deployment-omissions:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v2      - uses: mofmof/check-for-deployment-omissions@v0        with:          base_branch: 'main'          deployment_environment_name: 'production'          github_token: ${{ secrets.GITHUB_TOKEN }}          slack_token: ${{ secrets.SLACK_TOKEN }}          slack_channel: ${{ vars.SLACK_CHANNEL }}それぞれの設定項目についてチェックを実行したい時間:schedule: に指定してください。上記の設定では、月曜日の朝9時(JST)にチェックを実施します。base_branch:本番環境と同期されているブランチを指定します。deployment_environment_name:base_branchと比較するDeploymentの環境名を指定しますslack_tokenとslack_channel:設定のために、SLACK_TOKEN と SLACK_CHANNEL が必要になるので、リポジトリのGitHub Actions用の変数設定を行ってください。SLACK_TOKEN:1で作成した Bot User OAuth TokenSLACK_CHANNEL:通知したいチャンネルの名前 例: general手動でGitHub Actionsを実行してみようGitHub Actionsをマニュアル実行する上記の場所から、作ったActionを実行してみて、Slackに通知されるか確認しましょう。差分があってもなくてもSlackに通知されます。まとめGitHub Deploymentを使ってDeploymentを管理している場合は、mainブランチと差異がないかを確認できるこのActionを使ってみてください。

デプロイ漏れを検知して通知するGitHub Actionを作った話

こんにちはmofmofでエンジニアをしているshwldです。最近仕事で既存のシステムと連携する新しいプロダクトの設計をEventStormingで行いました。 はじめに新しいプロジェクトの設計に悩んでいるチームメンバーがいました。そのプロジェクトの状況は、以下のようなものでした。Railsで作られたサーバ、PHPで組まれたサーバ、Node.jsで動いているサーバなど、既存のシステムが複数存在するShopifyとの連携を筆頭にネットワーク越しに依存しているサービスが複数存在するバッチ処理が走ったあとでないと連携されない項目など、連携の条件が複雑それぞれのサービスのドキュ...

EventStormingを用いて複雑なシステムの設計に挑んだ

こんにちはmofmofでエンジニアをしているshwldです。最近仕事で既存のシステムと連携する新しいプロダクトの設計をEventStormingで行いました。はじめに新しいプロジェクトの設計に悩んでいるチームメンバーがいました。そのプロジェクトの状況は、以下のようなものでした。Railsで作られたサーバ、PHPで組まれたサーバ、Node.jsで動いているサーバなど、既存のシステムが複数存在するShopifyとの連携を筆頭にネットワーク越しに依存しているサービスが複数存在するバッチ処理が走ったあとでないと連携されない項目など、連携の条件が複雑それぞれのサービスのドキュメントはあるが、横断した連携手順はまとまっていないエンジニアが詳細を把握していないマニュアル操作が存在するエンジニアサイド、ビジネスサイド、双方がたくさんの会話を重ねて設計を進める必要があり、設計にとても時間がかかりそうな状況。そこで、Domain Modeling Made Functionalに記載のあったEventStormingというワークショップを使うと良いのではないか（EventStormingやりたかっただけとも言える）と思い、EventStormingを提案、実施しました。EventStormingとは?エンジニア以外も参加できるシステム設計のためのワークショップです。Alberto Brandoliniさんが提唱され、https://www.eventstorming.com/ こちらに書籍もあります。ブレインストーミングのようにメンバーから引き出したアイデアを用いて、共同でシステム設計を行います。EventStormingを行うことでたくさんのメリットがありました。共通の理解を促進するチーム全体が参加することで、ビジネスプロセスや要求に関する共通の理解を得ることができます。ボトルネックや課題点を明らかにするプロセスの中での課題点や効率化の余地を見つける手助けとなります。ビジネス要求を明確にする実際の要求やユーザーストーリーを明確にすることができます。ソフトウェアの設計を始めるイベント、コマンド、アグリゲートなどのドメイン駆動設計 (DDD) の概念を用いて、ソフトウェアの基本的な設計を行うことができます。コミュニケーション基盤を作るチーム内のコミュニケーションを強化し、異なる背景を持つ人々の間での共通言語を形成する手助けとなります。事前に準備したことやり方を再確認する参加者を決めるEventStormingで得たい結果をイメージしておく会場や必要なツールの準備やり方を再確認する以下を参考にしました。https://www.eventstorming.com/https://www.youtube.com/watch?v=jC9lE4YqgyYhttps://miro.com/app/board/uXjVOM6Bdp0=/参加者を決める以下のような参加者で実施しました。プロダクトオーナーステークホルダーエンジニア × 4デザイナー × 1ファシリテーター (自分)計8名となりました。それぞれの参加者の特徴は以下のようになっています。プロダクトオーナードメインについて最も深い知識を持っている方です。顧客要望からユーザーストーリーを作ったり、実際に運用を回す体制づくりや一部運用などをされています。ステークホルダープロダクトオーナーが決めきれないような判断を行える権限をもった方。エンジニア複数あるシステムを横断してみているエンジニア3名と、今回登場するサービスの1つに関わっているエンジニア1名デザイナー複数あるシステムを横断してすべてのデザインをしている方EventStormingで得たい結果をイメージしておくEventStormingで何を解決したいのかをイメージしました。複数システムの連携手順が複雑で、すべてを把握している人がいない状況でした。エンジニアは各サービス間の連携については知っていますが、Shopify上で行われているオペレーションを詳細に知っているわけではなく、逆も然りでした。今回は、2つの課題を解決する必要がありました。- エンジニアが設計を始めるには足りない知識がある。- 設計の根拠、リスク、妥当性などをビジネス側、デザイナーに説明し、判断してもらうための情報をまとめる必要がある今までもEventStorming以外の手段で可視化し会話していた部分ではあるためイメージはしやすかったです。後述しますが、実際はここでイメージした結果よりもより多くのメリットを享受できたと感じました。会場や必要なツールの準備フルリモートで進めているプロジェクトなので、ツールとしてMiroを選択しました。Miroには、いつでも確認できる場所に、やり方の流れとサンプルなどを置いておきました。MiroでEventStormingその他事前に行ったこと自分自身は他の小規模なプロジェクトで1回だけEventStormingを試したことがありました。EventStormingがとても有用だったため、その時の感覚を忘れないうちに社内にも広めたく、サンプルプロジェクトを使って体験会を実施しました。このときに今回依頼してくれたエンジニアの方が参加してくれており、体験会がきっかけでプロジェクトへの導入に繋がりました。ちなみに、このときはUber Eatsのクローンを作るというテーマで体験を行いました。1時間の中で進める分だけ設計したので、詳細までは進めませんでしたが、大人数で進める体験ができましたし、こうして次に繋がったのは嬉しいです。そして実践へ...2時間のセッションを1回と1時間のセッションを2回。計4時間ほどで実施しました。全部は見切れていないのですが、大枠で前節の目的を達成できたと感じています。エンジニアが設計を始めるには足りない知識がある。設計の根拠、リスク、妥当性などをビジネス側、デザイナーに説明し、判断してもらうための情報をまとめる必要がある具体的な流れをみていきましょう。1. Big Picture: 全体像を把握するa. イベントを集めるオレンジ色の付箋を使う過去形でイベントをどんどん出していく。主語は省略する。懸念がありそうなところ、時間がかかりそうなところは、深掘りせずに赤い付箋に懸念を書いて先送りする主語(アクター)があったほうが都合が良い場合は黄色い付箋で追加する↑実際に説明に使った内容ブレインストーミングです。現在のシステムに関して、起こりうるイベント、出来事をオレンジ色の付箋で、全員で付箋を貼っていきます。Miroのタイマー機能を使い、15分ほどで実施しました。最初はどうやってだしていくのか戸惑っている方もいましたが、ブレインストーミングなので、あまり気にしなくてよいと伝えました。b. 時系列に並び替える左を過去としてオレンジ色の付箋を時系列に並び替えるわからない付箋があれば、書いた人に説明してもらう同義語を統一する。同じ用語が別のものを表している場合は違いを明らかにし、分けるイベントを眺めながら時系列に並び替えていきます。似たものがあった場合、同じことを表しているのか話し合って統一したりといったことをしました。↑実際に説明に使った内容こちらも15分ほどで実施しました。途中、異なるユーザーで行われる同じようなイベントの存在が明らかになったとき、主語を入れるかどうかという議論が起こりました。ここでは、黄色い付箋で入れるアクターをこのタイミングで入れてもらうようにしました。結果的には良かったと思っています。主語、アクター2. Process Modeling & Software Modeling: イベントの出処を見つけ設計するコマンドを青い付箋で追加するアクターを黄色い付箋で追加するポリシーを紫の付箋で追加するシステムをピンクの付箋で追加するリードモデルを黄緑の付箋で追加する足りないイベントを追加していくコンテキストを区切る↑実際に説明に使った内容以下の動画を参考にさせていただき、やり方を真似て実践しました。www.youtube.com以前実施したときは、ポリシー、アクター、コマンド、イベントなど、それぞれを独立して扱って繋げていたのですが、このようにひとまとまりにして扱うようにしてみました。EventStormingシステムが多いのでイベントを置く際に、既存システムについてはどのシステムに属するのかをMiroのFrameを用いて名前付けし、コンテキストを区切りました。このとき既存システムをそのままコンテキストにしたわけではなく、本当に境界があるのかを考えながら区切りました。残りの3時間半ほどはひたすらポリシー、コマンドやアクターをくっつけ、そこからどのように次のイベントにつながるのかを紐づけていきました。いくつかポイントを書きます。動画で紹介されていた「緑の円でマニュアル手順を可視化する」方法が便利Shopifyでメールを送る手順はシステム化されていないシステム化が困難な箇所がいくつかありました。これらは緑の円を使いマニュアル操作を図示しました。エンジニアからはあまり見えていなかった作業であり、ここに関しての会話を行えたのは大きな収穫でした。不明点を赤い付箋で残すことの重要さその場で解決できない問題は「赤い付箋でコメント」を残しました。プロダクトオーナーの方が赤い付箋を積極的に、運用手順や顧客への確認などをしないと解決できない不明点などを残すことに活用してくださいました。エンジニアが調査しないとわからないポイントも赤い付箋で残し、全体のフローを通して不明点、課題点が多いことが明らかになりました。削除処理は複雑元々想像はしていましたが、削除のフローはとにかく複雑でした。削除されたときには、システム的にはこのリソースを使えなくしないといけない。運用的にはこのタイミングまでは使えるべき。など複雑な状況を整理する助けとなりました。利用規約などにも影響する項目であるため、サービスとしてどのような形が良いのかという議論ができたのですが、イベントストーミングなしでここまでの解像度を持って会話ができただろうかと思うくらいやって良かったと思います。集約の設計まではできなかった一部集約を書けた箇所もあるのですが、全体を通して集約を可視化するところまではいけませんでした。一部書けた箇所については、イベントがどのような概念を扱っているのかを非エンジニアに伝えることができたと感じたので、今後集約の設計も進めて行ければと思っています。感想EventStormingを用いることで会話と設計を同期的かつ一度に実施することができ、共通の理解を促進する効果を強く感じました。エンジニアは運用のことをみる解像度が上がりましたし、ビジネス側はシステム設計に関する解像度が上がりました。そして、密にコミュニケーションしながらすぐに不明点を解消できる状態でした。それぞれがどのようなことを行っているかを把握することで、コミュニケーションの効率が一段階進んだ実感があります。参加者の方からも感想を頂いているので、掲載します！デザイナーさん最初はよく分からなかったが、出来上がったのをみたら全体の流れが把握しやすいデベロッパシステム的な流れが把握できてよかったPOの方最初とっつきづらかったが、ドキュメントとして残るのがよいあとから設計を見返すことができるのがよい懸念点が洗い出せるのが良い自分自身2回目の実践、ファシリテーションでしたが、今回もとても有意義でした。こちらのプロジェクトに関しては継続してEventStormingを見返す。改善するということもやっていきたいと思います。参考にさせていただいたページhttps://www.eventstorming.com/https://blog.kinto-technologies.com/posts/2022-11-01-eventstorming/

EventStormingを用いて複雑なシステムの設計に挑む

mofmofのメンバーに向けてDevOps活動を浸透させるために、DevOpsで解決したい課題や計測方法などを書き出してみます。課題mofmofでの導入の背景・ニーズについて。mofmofはアジャイル開発を得意としており、開発と運用の連携を目指す体制の下地はある。ただ、以前から質とスピードがトレードオフになる状態があった。具体的には、言語やフレームワークのバージョンアップが溜まりがちだったり、開発が進むと開発時に考慮すべき項目が増えたり、影響範囲が広がり開発が遅くなるような課題である。リファクタリングを週に一定時間設けるなどをしたが、そういった開発環境の改善活動がもたらす効果が見えづらいという課題もあった。また、受託開発の会社として、複数の案件をそれぞれの開発者が担当しているが、案件ごとに知見が閉じてしまう問題もあった。そこで、品質やリファクタリングを捨てない方法としてDevOpsに目をつけた。DevOps開発（Development）と運用（Operations）が連携して協力する開発手法。目的は、製品の品質向上とリリースサイクルの高速化を実現すること。アジャイルやリーンで、確実に品質の高いリリースを行うことを目指す。「LeanとDevOpsの科学」という書籍では、品質が高いほど開発速度も上がるということが、統計的に示されている。DevOpsをどう活用するかDevOpsの実行は以下のようになっている。DevOpsの導入に向けた組織的な意志決定と戦略策定チーム間のコミュニケーションと協働の促進開発と運用のプロセスの統合と自動化継続的なインテグレーションとデリバリーの導入モニタリングとフィードバックループの確立mofmofでは、2については、基本的に下地ができている。メンバーにアジャイル理解があり、必要な改善を行っているはずだ。3, 4についても基本的に必要なものは導入しているはずであるが、自動化の余地はまだまだあるかもしれない。mofmofではまず5、そして1という順で注力していくことにした。モニタリングによって現状を把握し、目標を立てて改善の戦略を立てていく。現状を把握する①Take the DORA DevOps Quick Checkいくつかの質問に答えるとDevOpsについての現状把握ができるページ。DevOps研究組織であるDORAが出している。まずはこのページで現状を確認する。他の業界や組織とも比較できると記述があり、結果をmofmof内で保持することでチーム間での比較にも使える。現状を把握する②Four KeysまたもDORAが出しているFour KeysというDevOpsの開発パフォーマンスを可視化するツールで可視化する。計測する指標とパフォーマンス 指標  Highパフォーマンス  Middleパフォーマンス  Lowパフォーマンス  デプロイ頻度  1日に1回以上のデプロイを週3日以上（稼働が50%の場合は1.5日/週）  週に1回以上デプロイする週が月の過半数  週に1回未満のデプロイ  変更失敗率  0~15%  16%~45%  45%より高い  リードタイム（直近3ヶ月の中央値）  24時間以内  168時間以内  168時間より多い  サービス復旧時間（直近3ヶ月の中央値）  24時間以内  168時間以内  168時間より長い それぞれみていく。デプロイ頻度コアとなる指標。デプロイが頻繁に行えるということは、小規模な変更を頻繁にリリースできる状態であり、結果的に品質も向上する。mofmofにおける計測方法以下のいずれかをデプロイとして計測する。GitHubのDeploymentの作成GitHubのPull Requestのマージパフォーマンスの目安（直近の3ヶ月の情報で計測する） パフォーマンス   High  1日に1回以上のデプロイを週3日以上（稼働が50%の場合は1.5日/週） Middle  週に1回以上デプロイする週が月の過半数  Low  週に1回未満のデプロイ 変更失敗率デプロイ頻度を改善する際に、品質を落とさずに改善するために見る指標。雑なリリースが増えては本末転倒なので、変更失敗率を上げずにデプロイ頻度を高めることを目指す。mofmofにおける計測方法PivotalTrackerに障害の原因Commitを記載する。記載されたCommitを含むデプロイを失敗とみなす。パフォーマンスの目安（直近の3ヶ月の情報で計測する） パフォーマンス   High  失敗率が0~15%  Middle  失敗率が16%~45%  Low  45%より高い失敗率 リードタイム開発開始からリリースまでにかかる時間。mofmofではステージング環境までのリードタイムも計測。ボトルネックが開発にあるのか、運用との連携にあるのかを明らかにして改善に繋げたい。mofmofにおける計測方法前回のDeployment以降の最初のCommitから、Deploymentが作成されるまでの時間をリードタイムとして計測。パフォーマンスの目安（直近の3ヶ月の情報で計測する） パフォーマンス   High  直近3ヶ月の中央値が24時間以内  Middle  直近3ヶ月の中央値が168時間以内  Low  直近3ヶ月の中央値が168時間より多い サービス復旧時間信頼性を測る指標として測定する。サービスがダウンした際にダウンしたことに気づけるどこが原因なのか突き止めやすい誰でも復旧できる改善に繋げられるといった要素によって向上する。mofmofにおける計測方法PivotalTrackerのバグストーリーが開始してからAcceptされるまでの時間を計測対象とする。パフォーマンスの目安（直近の3ヶ月の情報で計測する） パフォーマンス   High  直近3ヶ月の中央値が24時間以内  Middle  直近3ヶ月の中央値が168時間以内  Low  直近3ヶ月の中央値が168時間より長い 改善戦略案件、チーム横断で改善を行う部隊を別途作りました。DevOpsの導入や指標測定の設定、目標や改善策の提案を主導します。事例や知見の共有を促し、同じ条件でのモニタリングを見比べ、それぞれの状況を俯瞰しつつ知見をためます。プロジェクト関係者全員で、改善できる体制を作りたい。

mofmofのDevOps活動

graphqlでエラーを返す方法はいくつかあり、それぞれメリデメありますが、Unionで返すのが好みです。例えば、以下のようにmutationで実行時のバリデーションエラーを共通のフォーマットで返すことを考えてみました。mutation createPost($input: CreatePostInput!) {  createPost(input: $input) {    result {      ... on Post {        id        name      }      ... on InvalidObject {        errors {          fullMessage        }      }    }  }}このクエリを見るとわかるようにCreate, Updateを行うmutationのエラーを共通のInvalidObjectで受け取ることができます。この方法を取ると、想定済のエラーのパターンと、エラーオブジェクトを型付で知ることができるため、実装時の時点でそれぞれのエラーパターンへの対応コードを書きやすくなると思います。ということで、union型を使ったエラーの内、バリデーションエラーの型付をGraphQL Rubyでやってみました。mutationファイルmodule Mutations  class CreatePost < BaseMutation    field :result, Mutations::CreatePostResult, null: false    argument :title, String, required: true    argument :body, String, required: true    def resolve(title:, body:)      post = Post.create(title:, body:)      { result: post }    end  endendmutationはこのようになります。resultというフィールドに Mutations::CreatePostResult を指定しているのがポイントです。mutation resultファイルclass Mutations::CreatePostResult < Types::BaseUnion  possible_types Types::Objects::PostType, Types::Objects::InvalidObjectType  def self.resolve_type(object, _context)    if object.invalid?      Types::Objects::InvalidObjectType    else      Types::Objects::PortfolioType    end  endendresultファイルはmutations配下においています。mutationではないのでちょっと気持ち悪いですが、命名ルールを揃えることで、ファイルがmutationと隣になるので、扱いやすくなります。バリデーション失敗したモデルのためのオブジェクトmodule Types::Objects  # バリデーション失敗したモデル用のオブジェクト  class InvalidObjectType < Types::BaseObject    field :id, ID, null: true    field :model, String, null: false    def model      object.class.name    end    field :errors, [Types::Objects::ValidationErrorType], null: false    field :full_messages, [String], null: false    def full_messages      object.errors.full_messages    end  endendInvalidObjectTypeはinvalid?なモデルの表示を行うオブジェクトです。バリデーションエラーのためのオブジェクトmodule Types::Objects  # バリデーションエラー用のオブジェクト  class ValidationErrorType < Types::BaseObject    field :attribute, String, null: false    field :type, String, null: false    field :message, String, null: false    field :full_message, String, null: false  endendattribute名をEnumにしたい気持ちもありますが、バリデーションエラーを型付きで取得できるようになりました。やったね！

GraphQL RubyでバリデーションエラーをUnion Typeで返す

イベントストーミングとユーザーストーリーマッピングの違い、使い分けについて考えました。また、似てるので実際に両方やってみました。その感想も書いています。イベントストーミングとは?ドメインイベントや、イベントの発生条件、集約、外部システム依存などを明らかにするためのワークショップ。DDDの戦略的設計に使われるようだ。Miroのテンプレートがある。https://miro.com/miroverse/event-storming/ざっくりやり方ドメインエキスパートを含めた関係者を集めてまとまった時間を取るドメインイベントをひたすら書き出すドメインイベントは、「過去形」で書き出す時系列順に並べる参加者に各イベントの意味を確認していくイベントが起こるための条件を書き出していくユーザーのアクション、コマンド外部システム時間や条件他のドメインイベントグルーピングを行ったり、整合性を保ちたいまとまり（集約）を探すこちらの記事が詳しいですhttps://qiita.com/tsukmr/items/91f5be9ba1004c19ec26ユーザーストーリーマッピングとは?プロダクトのユーザー体験を最初から最後まで俯瞰して確認できるドキュメント。アジャイル開発でのワークショップによって作られる。ユーザーストーリーを集めたもの。Miroにテンプレートがあります。https://miro.com/ja/templates/user-story-map/ユーザーストーリーとはユーザー体験を最小作業単位に分割したものであり、ユーザーにどのような価値を与えるかを言語化したもの。【ペルソナタイプ】は、【利益】になるように【行動】できる。のようなことを記述する。例えば、プログラマーは、仕事中に手軽に記録するため、デスクトップアプリから学びを投稿できる。のような形。ユーザーが得たい体験が含まれている。ざっくりやり方プロジェクトの関係者を集めてまとまった時間を取る参加者はユーザーの気持ちになって、付箋に一日の最初から最後までのストーリーを貼りだしていく見落とした細部を埋める別のケースを探るストーリーを整理する同じようなストーリーをアクティビティとしてまとめ、バックボーンを抽出するバックボーンは大まかな流れを掴むための概要であり、バックボーンだけを読むと概要を掴むことができる目標を実現する単位を切る。リリース単位となるこちらの記事などが詳しいですhttps://lucidspark.com/ja/blog/the-ins-and-outs-of-user-story-mappingそれぞれの特徴・違いイベントストーミング- システムのふるまいに焦点をあてている- 外部システムとの依存関係や、整合性、発動条件など、実装に基づいて設計する- 技術的視点がまあまあ必要ユーザーストーリーマッピング- ユーザー体験にフォーカスしている- ユーザーから見えないところは含まれていない- リリース単位のスライスやり方は似ていますが、全く別のものでした。どのように使い分けるかイベントストーミングではシステムの設計について、エンジニア以外と会話できます。設計の精度が上がるとともに、依存コンポーネントやリスクについても会話できるのはとても良いです。「ここはこのシステムに依存する作りになっているけど、リスクが大きいから後で変えられるようにしましょう。」みたいな会話ができます。イベントストーミングだけだとUXの考慮が無いため、バックエンドを設計する！みたいなイメージです。一方、ユーザーストーリーマッピングは、ユーザー体験を中心にした計画を行います。これをやることで、フロントを含めた体験を考えることができます。リリースをどの単位で行っていくとユーザーの体験が一通り実装できるかの判断も行えます。使い分けることを考えましたが、できるなら両方やる! でも良さそうです。合体イベントストーミングと、ユーザーストーリーマッピングはプロセスが似ているため、合体させることもできるのではないでしょうか。DRYってやつです（絶対によくないDRY）こちらのページにhttps://www.qlerify.com/post/from-event-storming-to-user-storiesドメインイベントとコマンドからユーザーストーリーを考えることを始める的な感じのことが書いてあります。イベントストーミングで、システムのふるまいを設計し、ふるまいの中でユーザー体験に関係しそうなコマンド、ドメインイベントを、ユーザーストーリーマッピングの「バックボーン」に設定して引き継ぐということができる?（本当か?）本当でした実際にやってみたんですが不思議と違和感なく繋がりましたイベントストーミングのアウトプットに当たり障りないユーザー登録などのイベントがあるとして合体例合体User/ActorとCommandだけを抽出して、ユーザーストーリーマッピングのバックボーン(User tasksのところ)として時系列に並べてみると引き継げました結果・感想・考えたことイベントストーミングは初挑戦でしたまずはプロダクト全体の大枠の設計と体験を見通すところを優先し、イベントストーミングはSTEP3までしかやっていませんSTEP3で、ユーザー/アクターやトリガー、外部依存などを考えるところで、エンジニアだと作るものが事前にある程度見える。設計の意思統一効果高いですある程度コードに落とし込むまでは、イベントストーミングをメンテナンスして深めていくのも良さそうだと感じましたイベントストーミングに時間をかけたぶんだけ、ユーザストーリーについての予測がしやすくなり、ユーザーストーリーマッピングはいつもより短い時間で終わりましたある程度の実装が見えた形でマッピングに入れるので、MVPラインを引くときに工数感が想像できる感覚がありました外部依存を明示して、リスクあるところの実装を後回しにするような実装は、ゼロイチでの開発と相性が良さそうですまずは大事なドメインをちゃんと作って、外部依存は取り替え可能で早く作れるものを選択してしまえると、早い上に、変更容易性が高そうで、最強か!?と錯覚しそうになりますすべてをクリーンに作るのが理想かもしれませんが、まずは最低限、外部依存に注目するだけでも効果がありそうですdmmf を読みつつ実践しているので関数型も取り入れたいなぁREF:- https://www.oreilly.co.jp/books/9784873117324/- https://www.easyagile.com/blog/the-ultimate-guide-to-user-story-maps/- https://www.qlerify.com/post/from-event-storming-to-user-stories- https://cyberagent.ai/practical-introduction-to-your-first-event-storming

イベントストーミングとユーザーストーリーマッピングをスムーズに連携させる

こんにちはmofmofでエンジニアをしているshwldです。イベントストーミング、ユーザーストーリーマッピングはどちらも、ホワイトボードと付箋を使って、プロジェクトの全体像を明らかにするワークショップです。イベントストーミングとユーザーストーリーマッピングの違い、使い分けについて考えました。また、似てるので実際に両方やってみました。その感想も書いています。ちなみにこのようなイベントをオンラインで実施する場合は付箋も扱えるMiroが便利なのでおすすめです。https://miro.com/ja/online-sticky-notes/ イベントストーミングとは?ドメインイベ...

イベントストーミングとユーザーストーリーマッピングって似てるからDRYにしようぜ

こんにちはmofmofでエンジニアをしているshwldです。graphqlでエラーを返す方法はいくつかあり、それぞれメリデメありますが、Unionで返すのが好みです。例えば、以下のようにmutationで実行時のバリデーションエラーを共通のフォーマットで返すことを考えてみました。mutation createPost($input: CreatePostInput!) {  createPost(input: $input) {    result {      ... on Post {        id        name      }      ... o...

今回はTypeScriptで「DateRange型」のような型を作る利点とその正しさを保証する方法を書きます。DateRange型の例type DateRange = Readonly<{ since: Date; until: Date; }>;利点についてDomain Modeling Made FunctionalはF#で関数型によるDDDを実践する本ですが、型の表現力によってドキュメンテーションすることを書いています。TypeSciprtも型の表現力が豊かです。F#と同じように型によるドキュメンテーションがある程度可能です。例えば、「開始日～終了日の間」のような値は普通、開始日が終了日より若い日付でないといけません。type FilterByDateRange = (data: Data[], since: Date, until: Date) => Data[];この関数の型定義、どうでしょうか。良さそうに見えますよね。でもfunction filterByDateRange(data: Data[], since: Date, until: Date): Data[] {    if (since >= until) {        throw new Error("普通、開始日が終了日より若い日付でないといけません")    }    return data.filter(it => it.date >= since && it.date <== until)}正しくフィルタできない場合（上記の場合は例外）がありそうです。型によるドキュメンテーションを進めると、エラーの可能性を型に表現することができます。type FilterByDateRange = (data: Data[], since: Date, until: Date) => Data[] | InvalidDateRangeError;filterする際にエラーになる事がわかるようになりました。（こういうのは例外にせず無視するケースも多そうですが、それはそれでフィルタされない原因がわかりづらそうです）しかしこのバリデーションはこの処理の中でやるべきなのでしょうか。事前にやっておきたいですよね。if (since < until) {    const newData = filterByDateRange(data, since, until);}関数を呼ぶ前に正しさを保証しておきたいと思うのが自然だと思います。こんな時は since と until をまとめたValueObjectを作って正しさを保証するとよいです。type FilterByDateRange = (data: Data[], dateRange: DateRange) => Data[]DateRange これです。正しく作られたDateRange型を受け取ることを型で明示することで、関数から例外を取り除く事ができました。正しさを保証する方法正しいdateRangeを渡すと嬉しいことがわかったところで、どうやってDateRangeの正しさを保証すればよいのでしょうか。まずは普通に書いてみます。type DateRange = { since: Date; until: Date };function DateRange(since: Date, until: Date): DateRange | null {    if (since < until) return { since: Date; until: Date };    return null}良さそうに見えますが、ダメです。TypeScriptは「構造的部分型」を採用する言語です。https://typescriptbook.jp/reference/values-types-variables/structural-subtyping#%E6%A7%8B%E9%80%A0%E7%9A%84%E9%83%A8%E5%88%86%E5%9E%8B%E3%81%A8%E3%81%AF形が同じであれば同じ型とみなすことができてしまいます。なので、date-range.ts が DateRange をエクスポートしてないとしても誰でも自由に作ることができるのです。例えば以下は型エラーにならないため、since, untilが正しいことは保証できません。filterByDateRange(data, { since: new Date(), until: new Date() })形が同じであっても別の型とみなしてもらいたいので、そういう場合は公称型を作ります。作る方法はいくつかあるようですが、仮に公称形が作れたとして、どのような挙動になるのかみてみます。import { DateRange } from './date-range';type FilterByDateRange = (data: Data[], dateRange: DateRange) => Data[]const filterByDateRange: FilterByDateRange = (data, range) => {  // 省略}const data: Data[] = //const since: Date = //const until: Date = //// これは型エラーにしたいfilterByDateRange(data, { since, until });// これは型チェック通したいconst dateRange = DateRange({ since, until });filterByDateRange(data, dateRange);それでは、これを実現する型をdate-range.tsに書いてみます。// exportしないことconst symbol = Symbol('isDateRange');// exportしないことtype IsDateRange = {  [symbol]: true;};export type DateRange = Readonly<  {    since: Date;    until: Date;  } & IsDateRange>;export const DateRange = ({  since,  until,}: {  since: Date;  until: Date;}): DateRange | null => {  if (since >= until) {    throw new Error('Invalid date range');  }  return {    since,    until,    [symbol]: true,  };};こんな感じになりました。ポイントはtype DateRange と const DateRange 以外をexportしないことです。exportしてしまうとこんな感じで無理やり通されてしまいます。import { symbol } from './common-types/date-range';const dateRange3: Readonly<{ since: Date, until: Date, [symbol]: true }> = { since: new Date(), until: new Date(), [symbol]: true };filterByDateRange([], dateRange3);最後に公称型を使うことで、ValueObjectの値を保証することができました。まあまあ手数はあるので、依存が気にならなければzodを使うと少し短くかけます。import { z } from 'zod';// exportしないことconst symbol = Symbol('isDateRange');export const DateRange = z  .object({ since: z.date(), until: z.date() })  .refine((dateRange) => dateRange.since < dateRange.until, {    message: 'Invalid date range',  })  .brand(symbol);export type DateRange = z.infer<typeof DateRange>;参考記事- xxxx (参考にした記事があったのですがどっか行ってしまいました...見つけたら記載します）

TypeScriptで「DateRange型」の正しさを保証する

こんにちはmofmofでエンジニアをしているshwldです。今回はTypeScriptで「DateRange型」のような型を作る利点とその正しさを保証する方法を書きます。DateRange型の例type DateRange = Readonly<{ since: Date; until: Date; }>; 利点についてDomain Modeling Made FunctionalはF#で関数型によるDDDを実践する本ですが、型の表現力によってドキュメンテーションすることを書いています。TypeSciprtも型の表現力が豊かです。F#と同じように型によるドキュメ...

mofmofでは最近、「LeanとDevOpsの科学」という本の輪読会を行っています。 この本の輪読会は定期的に開催し、第一部である11章までを読みました。過去の記事はこちら第1章：なぜケイパビリティに着目するのか。LeanとDevOpsの科学を読んだ記録（1章）第2章：開発組織のパフォーマンスをどうやって測定するのか。LeanとDevOpsの科学を読んだ記録（2章）第3章：組織文化がなぜ重要か？LeanとDevOpsの科学を読んだ記録（3章）第4章：技術的プラクティスの重要性。LeanとDevOpsの科学を読んだ記録（4章）第5章〜第7章：LeanとDevOpsの科学を読んだ記録（5章〜7章）第8章〜第9章：LeanとDevOpsの科学を読んだ記録（8章〜9章）第10章 従業員の満足度、アイデンティティ、コミットメント従業員向けのネットプロモータースコアで従業員満足度をはかったところ、ハイパフォーマンスな組織は、ローパフォーマンスな組織の2倍も満足度が高かったという調査結果がある。これは以下のような質問を行いあなたの組織は「友人や同僚に薦めたい職場」ですか。あなたのチームは「友人や同僚に薦めたい職場」ですか。0~10の11段階で評価してもらう。9, 10は推奨者7, 8は中立者0~6は批判者また、ネットプロモータースコアは、以下と相関関係がある。顧客のフィードバックをプロダクトに生かしている度合い開発から顧客対応まで全工程が可視化されチームが把握している度合い組織の価値観、目標への共感度、成功への貢献意欲議論に出たことDevOpsをやることで会社自体のパフォーマンスも上がるし満足度も上がるしいいことづくめで、やらない手はないのではDevOpsにおいて大事なことはスクラムやアジャイルとかなり重なっている自分好みの組織に近づいけいくことができる。不満があっても自分でなんとかできる。改善サイクルが回っている組織は自然と満足度が上がりそうデリバリパフォーマンスが高い、開発しやすい環境というのはエンジニアがいたい環境第11章 変革型リーダーシップとマネジメントの役割変革型、奉仕型のリーダーシップがあり、変革型のリーダーシップが有効であるという話。パフォーマンスの高い組織は、変革型リーダーの特性値が高いという調査結果が出ている。変革型リーダーシップと奉仕型リーダーシップの違い奉仕型リーダーが、部下自身の成長や能力に重きを置くのに対し、変革型リーダーは、部下に組織との一体感をもたせ、組織の方針に従わせることに重きを置く優れたリーダーは、コードの生成、優れたシステムの設計、業務管理・製品開発へのリーン原則の適用、といったチームの能力に影響を及ぼす。具体的には以下高い信頼性と生産性を実現するための文化規範を確立しサポートする開発者の生産性を高めるテクノロジーを創造し、デプロイまでのリードタイムを縮小し、より信頼性の高いインフラをサポートするチームの実験や技術革新をサポートし、良質な製品を迅速に創造し実装する組織の部署を越えた取り組みにより、戦略的な協力関係を築き上げる変革型リーダーの特性ビジョン形成力―組織が何を目指し、5年後どうあるべきかを明確に把握している心に響くコミュニケーション能力―不確実で変動する環境下でも、従業員を鼓舞し、ヤル気にさせるような対話を行う知的刺激―部下の意欲をかきたて、新たな方法で問題に取り組むよう促す支援的リーダーシップ―部下の個人的要求や感情に配慮と気遣いを示す個人に対する評価―目標の達成、作業品質の向上を認識・賞賛し、顕著な業績を上げた場合には個人的に報奨する組織文化を改善しチームを支援するための秘訣- 部門横断型の協働を可能にする    - 他チームにいる同じ立場の相手方との信頼関係を構築する    - 現場担当者に部署間の異動を促す    - チームの協働を容易にする作業を追求し推進する。そうした作業が成功すれば褒賞を与える- 学習環境の形成    - 教育のための予算を計上し、それを組織内で公表する    - チームメンバーのために、「個人的な学習ができる予算」や「アイデアを探求するための時間」を確保する        - すいこじがかなりこれなイメージ    - 従業員が失敗を恐れないようにする    - 情報共有のための機会や場を作る    - 「デモデイ」やフォーラムを開催して、情報共有や技術革新を促す- ツールを有効活用する    - チームがツールを選択できるようにする    - モニタリングを優先事項にする議論に出たこと一般的なリーダー論的な話も有効そう聖杯問答だ。rebuildでも聞いたぞ管理者とリーダーが同じ人だと最も良いとあるが、管理者とリーダーってどういう違いがあるの。ここで言ってる管理者とリーダーの定義は?管理者とは、組織において人事・予算・リソースに対する責任を負っている。その人が変革型リーダーだと良いということ。これらの権限を持って以下を遂行するべきという話。高い信頼性と生産性を実現するための文化規範を確立しサポートする開発者の生産性を高めるテクノロジーを創造し、デプロイまでのリードタイムを縮小し、より信頼性の高いインフラをサポートするチームの実験や技術革新をサポートし、良質な製品を迅速に創造し実装する組織の部署を越えた取り組みにより、戦略的な協力関係を築き上げるチームメンバーのために、「個人的な学習ができる予算」や「アイデアを探求するための時間」を確保するってまさにすいこじだツール選択の自由度や、チーム間の移動などはもっとやれるようにしていきたい

LeanとDevOpsの科学を読んだ記録（10章〜11章）

mofmofでは最近、「LeanとDevOpsの科学」という本の輪読会を行い、DevOpsを実践する活動を始めました。自社プロダクトへの導入の際に考えるべきことを4つ紹介します。1. 導入の目的と期待する効果を明確にするDevOpsはプラクティスは、変化の大きな市場環境において、組織のケイパビリティを高める事により、競争力や組織全体のパフォーマンスを向上することを目的としています。一見どんな事業・プロダクトにも共通して使えそうにも思えますが、実際には、プロダクトを成長させるという目的にフォーカスしていると言えそうです。特に難しいのが、後期段階や終了段階にあるプロダクトです。どんどんデリバリをして行くというのではなく、ある程度保守フェーズに入っていたり、クローズに向かっているプロダクトなどでは、デプロイ頻度計測の重要性が下がってきます。こういったプロダクトではデプロイ頻度を高めることが本当に重要なのか、変更失敗率を下げることを重視すべきか。細かな項目の優先度を考えて導入していく必要があります。そのようなプロダクトが組織のパフォーマンスに与える影響を図る材料となったりといったことも考えられます。ただ、いずれにしてもDevOpsのプラクティスはすぐに結果が出るものではなく、長い目で改善していくものだということもおさえておく必要があります。今回の目的は、こちらの記事にも書いたのですが、組織のパフォーマンス改善の指標として使えるのではないか。それを検証したいという、少し特殊な目的でした。導入を検討する前にプロジェクトのオーナーや開発者に、現状の課題感や大枠のデプロイ頻度や障害頻度、ロードマップなどをヒアリングしました。2. 計測指標を定義するLeanとDevOpsの科学は以下の項目「Four Keys + 1項目」を計測しろと言っています。コードのデプロイ頻度コミットからデプロイまでのリードタイム障害の平均復旧時間デプロイの変更失敗率信頼性これらを実際に取得する際に考えたことを記録として残します。今回導入して検証しているプロダクトは後期段階のプロダクトで、新規機能開発は活発ではありません。とは言え利用しているパッケージや依存する外部サービスやライブラリのアップデートが多数あり、それらを安定的に反映していくためにリソースが常に確保されています。こういった事情もあり、deploys / a day / a developer (1日あたりのデプロイ数を開発者数で割った数) での計測を行います。リソースが常に確保されているとは言え一定ではないため、稼働時間やリソース状況を考慮した数字が重要と考え、こちらを計測していくことにしました開始前段階では、この数値が 0.06 くらいでしたので、0.1 に改善することを目標とします。それぞれの指標についてどこを計測するかを定義するデプロイ頻度mainのブランチへマージされたタイミングでGitHub deploymentを作成。それをデプロイとして計測するリードタイム初回commitからmainブランチへのマージまでの時間を計測平均修復時間PivotalTrackerのバグチケットがStartされてから、Acceptされるまでの時間を計測変更失敗率PivotalTrackerのバグチケットがAcceptされた数を計測まずはGoogleのfour keysをそのまま使いつつ、今の組織に合うかどうか一つ一つ項目を見ていきました。https://github.com/dora-team/fourkeys3. Quickチェックを行い、最初に手を付けるべきところを決める。迷わずとにかく手を動かす現状のヒアリングや分析から計測すべき項目を定義し終わったので、実際に指標を改善していく活動をしていきます。ただ、効果がどのくらいのスパンで現れるかもわからず、どの対応がどの程度のインパクトを与えるのかもわかりません。どこから手を付けるか迷いました。以下のGoogleのクイックチェックで、現状のパフォーマンスを可視化できます。その後、追加のアンケートに答えると最初に手を付けるべき大項目を提示してくれます。https://www.devops-research.com/quickcheck.htmlまずはここで提示されたCIの改善に注力していきました。具体的にはCI周りの課題感を洗い出すヒアリングカバレッジの確認静的解析ツールの自動実行CIジョブのパフォーマンス改善テストの追加パフォーマンス課題になりそうな箇所の検知ロジックをCIで自動化などを行っています。4. 啓蒙するDevOpsの活動はメンバー全員で行うことが必要です。DevOpsとはなんぞやということで、まずは社内でLeanとDevOpsの科学の輪読会を開催しています。その他にも、透明性を上げたり、権限を与えたりということがいい影響を与えるということで、ツール選択の自由度を確保する ために、GitHub Actionsがプライベートリポジトリで使えないプランを利用していたので、アップグレードして使えるようにするなど細かな活動を続けていくことが重要そうです。最後にまずは導入までを行ってみた記録となります。引き続き活動していきます。

DevOpsの導入時に考えたい4つのこと

こんにちはmofmofでエンジニアをしているshwldです。個人開発でこちらのアプリを作りました。この記事では、利用技術と、選定の理由、使ってみてどうだったかを書いていきます。 簡単なサービスの紹介REVELUP.devはTwitterのような気軽さで技術アウトプットメモを投稿できるサービスです。フロー情報を前提としているため、正確性などを気にせず気軽に投稿しながら、本番アウトプットの練習ができる場を目指します。詳しくはこちらを御覧くださいhttps://zenn.dev/shwld/articles/ca8a7972cd1f0c 構成要素 Tauri選定の...

Next.js v13のApp Directoryを使って技術メモ投稿サービスを作った話

こんにちはmofmofでエンジニアをしているshwldです。https://zenn.dev/shwld/articles/ca8a7972cd1f0cをリリースしたのですが、Windows版はMicrosoft Storeに提出しました。最初は、Macと同じくサイト上からダウンロードさせようと思ったのですが、ある壁が立ちはだかったのです。 コード署名証明書アプリケーションにデジタル署名することで、アプリをダウンロードしたユーザーは信頼された発行元であることが確認できます。安心してアプリを利用することができますね。これがないと、こういうのが出ます。こんなのでたらインストー...

Tauriで作ったアプリをMicrosoft Storeへリリースする [コード署名無料]

こんにちはmofmofでエンジニアをしているshwldです。mofmofではエンジニアの成長にフォーカスして色々施策を思索して試作したりしていたりもします。今回は、課題の一つである、「アウトプットを習慣づけたい」について、ソリューションとなるサービスを作ってみました。期間2ヶ月で作った個人開発プロダクトをリリースするので進捗を時系列で紹介してみるで書いたアプリです。遂にリリースしました。この記事ではなぜサービスを作るに至ったのかどんなサービスなのかあたりを書いていきます。https://revelup.dev/ja なぜアウトプットを習慣づけたいのかアウトプット...

エンジニアのアウトプット力を高めるメモ投稿サービスをリリースしました【個人開発】

良いコードと言って、どんなことを思い浮かべますか?変更容易性、テスト容易性、拡張性、信頼性、可読性、保守性、効率性、、、どういうコードが良いコードなのでしょう。これをどうやって説明しますか。良いとされる設計手法や、テクニックはたくさんあります。開発組織やプロダクトは多様であり、変化することを良しとしています。良いとされる設計手法がどの開発組織、どのプロダクトにも適用できるのでしょうか。よいコード、設計ができていることをどうやって測ればいいのでしょうか。逆に考えてみました。良いコードが何なのかを知るためには、良いコードがもたらすメリットから逆算できないか。開発者がコードをより迅速に開発できるようになり、バグの発生率が低下し、保守性が向上することが挙げられます。また、運用チームもシステムの保守性が向上し、問題を迅速かつ正確に解決することができます。良いコードは、開発者と運用チームの双方にとって利益をもたらします。良いコードは開発体験が良いと言えそうです。また、運用者も嬉しそうです。運用者に限らず組織全体に好影響がありそうです。もしかして、ハイパフォーマンスな組織状態を作ることを目指すことは良いコードにたどり着く道なのではないでしょうか。開発者が目指すべき良いコードを数値で示してくれる。そんなツールになる道につながっているでしょうか。ハイパフォーマンスな開発組織を作るために改善すべき項目は何かLeanとDevOpsの科学は以下の項目「Four Keys」を上げています。コードのデプロイ頻度コミットからデプロイまでのリードタイム障害の平均復旧時間デプロイの変更失敗率ハイパフォーマーはデプロイを日に何度もするとあります。変更を即デプロイしても、障害にならないことも計測しています。これらの項目を継続的に改善するには、自動化されたテストや、デプロイは前提になるでしょう。それだけでなく、コードの変更容易性や検証体制も整っている必要があります。つまりこの指標を改善していく先には、変更容易性の高い「良いコード」が眠っているといえないでしょうか。もちろんエンジニアだけではなく、運用や組織全体で改善していく指標ではありますが、ハイパフォーマーを目指す過程には様々な良いコードへの学びがありそうです。良いコードの探究だけでなく直接ビジネス価値につながる検証回数はビジネスを成功させるうえで非常に重要な要素です。顧客からのフィードバックや小さなアイデアを検証し、プロダクトを磨き続けていくことが必要不可欠だからです。しかし障害を起こさずに検証回数を高めるためには、高品質なプロダクトコードが不可欠です。スピードを上げるにはコードの質が必要となるのです。あまり直感的には繋がりませんが、実は高品質を追い求めることはアジャイルなプロダクト開発そのものでもありそうです。まずは自社プロダクトで実践mofmofはMy-opeという自社サービスを持っています。ここには年季の入ったコードがあり、日々運用しています。テストコードはたくさんありますが、変更が怖いコードもたくさんあります。ここでFour Keysを改善することができるでしょうか。導入し、改善を体験・検証してみます。

良いコードとはなにか。なぜ必要か。DevOpsとアジャイル、質とスピードについて考える

mofmofでは最近、「LeanとDevOpsの科学」という本の輪読会を行っています。この本の輪読会は定期的に開催し、順次後ろの章についてもログを投稿する予定です。前回は1章を読みました。記事はこちら「なぜケイパビリティに着目するのか。LeanとDevOpsの科学を読んだ記録（1章）」従来の測定手法の問題点とは従来は以下のような方法で測定していた。書いたコードの量ベロシティリソース利用率それぞれ問題があった。書いたコード量を測定することの問題点巨大化したソフトウェアを生み、保守と変更のコスト増を招くベロシティを測定することの問題点チームの状況はチームごとで違うため、単純にベロシティ比較はできないベロシティのため見積もりを水増ししたり、無理にストーリーを終わらせたりする水増しはあまり経験したことはないが、ストーリーの完了条件を重視し、そこに合致する最低限で終わらせがちという話が出た（保守性、変更可能性の高いコードにするためには、ストーリーの完了条件を決める時点で良いコードを意識しておく必要がある）リソース利用率を測定することの問題点リソースが空いているときに常に何か作業をアサインするような状態を目指してしまうそれによって、改善や予想外の作業は入れづらくなるという話じゃあ望ましい尺度は?デリバリのリードタイムデプロイの頻度サービス復旧の所要時間変更失敗率これらを測定して改善していくことが望ましい。調査の結果、パフォーマンスの高い組織は、開発スピードを上げると品質も上がっている。また、この尺度を改善することで、組織全体のパフォーマンス（収益性、市場占有率、生産性）もあがるとのこと。万能感実際に行った議論受託開発で行うハードルはありそう開発チームだけで改善できる数値もあるので、適宜どちらに働きかけるか判断できるようモニタリングするのが良さそう受託開発でやってるとこあるんかな?デプロイ頻度はなぜデプロイ?リリースではダメ?変更失敗率も含有するためだと思われる。リリースだと失敗した（切り戻した）リリースを扱いづらそう。とりあえずtexta.fm聞いておくと役に立ちそうハイパフォーマーとローパフォーマーについては開発環境やチーム状況等に大きな差がありそうなのでなんとなくイメージが湧くけど、ミディアムパフォーマーとの違いが何なのかかがポイントになりそうリードタイムは、何をした時点から、何ができた時点までを測定するのかなど、指標の定義は組織毎に多少のカスタマイズをして決める必要がありそうまずはGoogleのfourkeysを参考にすると良さそう続きを読むLeanとDevOpsの科学を読んだ記録（3章）

開発組織のパフォーマンスをどうやって測定するのか。LeanとDevOpsの科学を読んだ記録（2章）

mofmofでは最近、「LeanとDevOpsの科学」という本の輪読会を行っています。この本の輪読会は定期的に開催し、順次後ろの章についてもログを投稿する予定です。成熟度モデルの問題点この本の第1章は、多種多様な組織において、戦略目標設定、状況把握を正しく把握するために、ケイパビリティに焦点をあてることを薦めている。元々、戦略目標設定、状況把握に使われていたのが、「成熟度」モデルというもので、おそらくこの記事で取り上げられているもののことを言っている。成熟度モデルとは、組織が決められたステップを踏んで成熟することを前提として、それぞれの段階ごとに必要な要素をクリアしていくと認定されるようだ。成熟度モデルの問題点として、到達が目標になってしまうというところがある。最高レベルの「レベル5」は最適化された状態で、この状態は改善サイクルがよく回る状態になっていると思われるが、組織の状態としてはスタートラインとも言えそうで、それ以上のプラクティスがなさそうに見える。また、組織は多様であり、にた過程を経て成熟するわけではないとも言っている。ケイパビリティとは何かWikipediaによると企業や組織が持つ、全体的な組織的能力、あるいは企業や組織が得意とする組織的能力のことを言う。らしいどんなケイパビリティが、戦略目標設定、状況把握を正しく把握でき、パフォーマンスに好影響を与えるのかだが、これを調べるためパフォーマンスが良好で革新的な企業が改善に力を入れている項目を研究により特定したみたい。このパフォーマンスという組織を表す指標として、以下を定義している。コードのデプロイ頻度コミットからデプロイまでのリードタイム障害の平均復旧時間デプロイの変更失敗率これらを改善するために、24個のケイパビリティが巻末で紹介されている。例えば、 継続的デリバリというケイパビリティには、デプロイメントが自動化されているかどうか。自動化の度合いがどの程度か。 のような項目が並んでいる。ということでケイパビリティが大事ということはなんとなくわかったし、とても良さそうに見える。そう感じた一方で、成熟度モデルの理解が浅かったため、成熟度モデルの課題はそうなんだろうなという以上の感想がなく、ケイパビリティが決定的に優れているかどうかの肌感はない。実際に出た意見人事評価にもケイパビリティみたいなものが応用できそう成熟度モデルがイマイチわからなかった最後にmofmofでは(不)定期的に輪読会をしています。輪読会のやり方についても模索しつつ色々試しているところです。それについてもいつか記事にしたいです。続きを読むLeanとDevOpsの科学を読んだ記録（2章）

なぜケイパビリティに着目するのか。LeanとDevOpsの科学を読んだ記録（1章）

こんにちはmofmofでエンジニアをしているshwldです。mofmofでは今年の1月から毎週水曜日にみんなで個人開発する時間が設けられています。https://note.com/shwld/n/nfb1a2abfc9eb水曜日と、毎日1時間半程度(やってない日や逆に多くやった日もありますが、均すと多分このくらい)を使って2ヶ月でSNSのようなサービスをリリースできそうなところまで持っていけたので、やったことをログとして書きます。 作っているものエンジニア向けの、フローメモを投稿できるSNSを作っています。デスクトップアプリで、すぐに起動してさっと書けて投稿内容を友達と...

期間2ヶ月で作った個人開発プロダクトをリリースするので進捗を時系列で紹介してみる

Next.js + サーバーサイドTypeScript + 関数フレーバーでクリーンなアプリを作ったので実装意図とか書く Advent Calendar 2022の25日目。株式会社mofmofに…

TypeScriptでサーバーもフロントも書いてGraphQLするやつアドカレ25記事書ききった

Next.js + サーバーサイドTypeScript + 関数フレーバーでクリーンなアプリを作ったので実装意図とか書く Advent Calendar 2022の24日目。株式会社mofmofに…

GraphQLへの入出力、エラー（Union、InputType）

Next.js + サーバーサイドTypeScript + 関数フレーバーでクリーンなアプリを作ったので実装意図とか書く Advent Calendar 2022の23日目。株式会社mofmofに…

Next.jsとgraphile-workerをRailwayにデプロイする

こんにちはmofmofでエンジニアをしているshwldです。今日はmofmofで行っている技術1on1という試みについて書きます。 mofmofで行っている技術1on1とは過去2回実施しており、その際はこのような形で実施しました。#1 技術習得・向上のための1on1①#2 技術習得・向上のための1on1② どのように進めたか。意識したことは何か「継続的に学習することをサポートする」をメインの価値に据えて実施しました。過去2回実施してきました。前期、前々期は1on1の中で「技術について深く考える」というところにフォーカスしていました。今回はそこを辞めました。今期は基本...

技術習得・向上のための1on1③

Next.js + サーバーサイドTypeScript + 関数フレーバーでクリーンなアプリを作ったので実装意図とか書く Advent Calendar 2022の22日目。株式会社mofmofに…

graphile-workerを使ったバックグラウンド処理

Web3と呼ばれたりする、ブロックチェーンを用いた分散型の技術が盛り上がってきています。自分も前々からなんかすごそうだなと思いつつ、まだ実用には遠そうだなと思ったりして手を出していませんでした。最近はそんな中でも特に盛り上がっているように見えました。Web3がバズワードとなり、急速に発展しているように見えます。今回は、そんなWeb3を使ったWebアプリケーションを作ってみたので、最初の学び方の一例としてやったことを紹介します。なぜいまやろうと思ったのか何を作ったのか作ってみてどうだったか壁1. 価値の設計が難しいが、価値を考えるきっかけになる壁2. 「たぶん動くと思うからリリースしようぜ」しづらい壁3. 学ぶことたくさんどうやって学んだか1. ずっとWeb3, NFT触りたいなーと心の片隅においておく2. 個人開発アワードをきっかけに学ぼうと決意する3. 中島聡さんのAssetStoreのコードを読む4. プロダクトを企画する5. 実装を始める6. CryptoZombiesをつまみ食いしながらやる7. OpenZeppelinの実装を読む8. 仕組みを有識者に聞くまとめなぜいまやろうと思ったのかWeb3やNFTと言った界隈はエンジニアからすると、とても気になる存在だと思います。少なからず調べたり試したりしている人も多いのではないかと思います。自分もずっと気になっていたんですが、手を出せずにいました。理由は、ウォレットとかミントとか専門用語や知らない概念が多く、導入のハードルが高そう。だとか、ウォレット使わないといけないのでユーザビリティが悪くて、広まらない気がした。などでした。ただ、身近にブロックチェーンで仕事をしている人もいたりで、ずっと片隅で気になっていた感じです。で、今なぜやろうと思ったかというとなんか勢いあるなーって感じたからです（浅）腰が重いけど、触っておくべきかなーという圧を感じました。やろうと思っていたんですがずっと手つかずでした。どうやって実際に、着手したかはこの記事で書いていきます。何を作ったのかhttps://anniverse.shwld.app/NFTで祝日を売買できるカレンダーを作りました。祝日の名前と、内容をNFTとして保存して自分だけの祝日を作る事ができます。anniverse上の祝日は世界に一つだけなので、anniverseが広まるほどに祝日の価値は高まります。リリースしたとタイトルにありますが、テスト用のEthereumネットワークへリリースしました。実際のお金は動きません。作ってみてどうだったか作るの自体は難しくありませんでした。ただ実際にサービスにするにはまだ結構な壁を感じると同時に面白さも感じました。壁1. 価値の設計が難しいが、価値を考えるきっかけになる祝日に価値をつけられるというのを実現できました。NFTの設計としては実現しているのですが、実際の価値を持たせるためには、有名な人に買ってもらって価値を上げるとか、コミュニティの共通カレンダーにするとか、そういったシステム設計以外の環境を含めて設計する必要が出てきます。ここが、Web3の最も面白いところであり、難しいところだと感じます。機能や体験が価値を持つというのは既存のサービスでも同様だと思いますが（サービスの体験にお金を払うサブスクリプションモデルなど）Web3は更に1歩先の、個々の体験自体が金銭的価値を生むという新しい世界を感じることができました。体験に金銭的価値を与えるということは、サービスの価値提供をシビアに意識する訓練として有用な気がするなーとぼんやり感じたりします。壁2. 「たぶん動くと思うからリリースしようぜ」しづらい今回この壁を乗り越えられず、サービスを本番公開していません。具体的に何を乗り越えられなかったを書きます。本番デプロイするのに1万円くらいかかる祝日を作るたびに、利用者は1600円くらい払わないといけない本番デプロイすると、以後ソースコードの変更ができないデプロイはできるんですが、1万円払うために頑張るモチベーションはありませんでした。でもこれって普通のサービスも同じで、1万円払う価値のあるサービスを作らないとリリースできないを強制されるのは訓練になるなーと感じ...参考：テストを実行すると金額を見積もってくれます。·---------------------------------------|---------------------------|-------------|-----------------------------·|          Solc version: 0.8.9          ·  Optimizer enabled: true  ·  Runs: 200  ·  Block limit: 30000000 gas  │········································|···························|·············|······························|  Methods                              ·               22 gwei/gas               ·      175265.99 jpy/eth      │·····················|··················|·············|·············|·············|···············|··············|  Contract          ·  Method          ·  Min        ·  Max        ·  Avg        ·  # calls      ·  jpy (avg)  │·····················|··················|·············|·············|·············|···············|··············|  AnniversaryToken  ·  burn            ·          -  ·          -  ·      57840  ·            2  ·     223.02  │·····················|··················|·············|·············|·············|···············|··············|  AnniversaryToken  ·  mint            ·     155700  ·     173847  ·     160973  ·          390  ·     620.69  │·····················|··················|·············|·············|·············|···············|··············|  AnniversaryToken  ·  setAnniversary  ·     149089  ·     518536  ·     302919  ·            6  ·    1168.01  │·····················|··················|·············|·············|·············|···············|··············|  AnniversaryToken  ·  setBaseURI      ·          -  ·          -  ·      32246  ·            1  ·     124.34  │·····················|··················|·············|·············|·············|···············|··············|  AnniversaryToken  ·  transferFrom    ·      85742  ·      88554  ·      87992  ·            5  ·     339.28  │·····················|··················|·············|·············|·············|···············|··············|  Deployments                          ·                                         ·  % of limit   ·             │········································|·············|·············|·············|···············|··············|  AnniversaryToken                     ·          -  ·          -  ·    3407243  ·       11.4 %  ·   13137.82  │·---------------------------------------|-------------|-------------|-------------|---------------|-------------·壁3. 学ぶことたくさん上記、「祝日を作るたびに、利用者は1600円くらい払わないといけない」のような問題はなんか解決策がいろんなところで提案されたりしているようです。デプロイ後にどうやって改善していくかなどもノウハウが色々ありそうです。Web3の世界は進歩が早いとよく聞きます。今回、Solidityを使ってサービスを作るというところは比較的簡単に実現できたのですが、実用面を追求すると、まだまだ学ぶべき項目が大量にあるなと感じました。また、既存の知見はあまり使えないことが多いです。Web3として新たに学ぶべきことは多く、参入障壁は高いと感じます。逆に今のうちに参入すべきなのかもしれませんが。どうやって学んだか新しいことを学ぶときは個人開発駆動開発が良いです。自分は学ぶのが苦手です。これは弱みだよなーと思いますが、そこを気にしてモチベーションを下げるよりは、あるポイントまではとりあえず動くから出してみようぜしたほうがテンション上がります。また、とりあえずリリースまでできたら、その時点で対象技術の周辺要素を俯瞰して見れる様になっているので、そこから細かいところを学ぶほうが自分には合っています。実際にリリースできるところまでを体験することで、プロダクション品質に何が必要か、どんなところに気をつけるポイントが有るか、など実践的なノウハウを得られます。以下のような流れで進めました。ずっとWeb3, NFT触りたいなーと心の片隅においておく個人開発アワードをきっかけに学ぼうと決意する中島聡さんのAssetStoreのコードを読むプロダクトを企画する実装を始めるCryptoZombiesをつまみ食いしながらやるOpenzeppelinの実装を読む仕組みを有識者に聞く1. ずっとWeb3, NFT触りたいなーと心の片隅においておくやりたいなーと日頃から情報をちょっとずつ仕入れる。とは言ってもあんまり積極的にはやっておらず、中島聡さんのVoicyとかをたまに聞いたりするくらいでした。2. 個人開発アワードをきっかけに学ぼうと決意するmofmofには個人開発アワードというイベントがあります。決まって、長期休みなどのあとに開催され、みんなの個人開発を称え合います。このイベントなにか出してみようと考えたときにNFTやってみるか。と思いました。個人開発アワード駆動開発3. 中島聡さんのAssetStoreのコードを読むNFT何もわからんので、とりあえず既存の動いてるサービスとコードを読んでみました。AssetStorehttps://assetstore.wtf/なんとなく何ができるのかがわかってきた気がします。4. プロダクトを企画するObsidianに1ページ作って、サービス名エレベーターピッチ的な文章実現するための機能実現にあたっての不明点あたりをノートに書きました。5. 実装を始める企画ができたのでとりあえず雑に手を動かし始めます。手を動かしいながら不明点を調べていきます。6. CryptoZombiesをつまみ食いしながらやる実装ですぐに詰まりました。デプロイや開発環境はhardhatというツールで大体できてしまうのでそこまで困りませんでしたが、Solidityの書き方がわからない。そこで、CryptoZombiesという素晴らしいコンテンツが有ることを知り、これをやってみることにしました。最初にざっとゾンビファクトリーの作成ゾンビが人間を襲うSolidityの高度なコンセプトの3つをクリアしました。そこで開発に戻って、都度並行でCryptoZombiesに戻りながら学習を進めました。7. OpenZeppelinの実装を読むNFTを実装するに当たり、OpenZeppelinを利用&参考にしました。ERC721を利用するので、どうカスタマイズすべきなのか、どういう実装になってるのかをわりとたくさん読みました。Solidityはコード量が少ないので読みやすいです。https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC7218. 仕組みを有識者に聞くなんとmofmofにブロックチェーンエンジニアの方がいるので、Slackでわからないところを教えてもらいました。ポッドキャストでも教えてもらいました。11. ブロックチェーンPoW勉強会（付録PDF付き）これを聞くまでこのあたりの知識があまりない状態でしたが、大分理解が進みました。まとめ個人開発駆動開発は新しい技術を学ぶ最初のステップとしておすすめです。

ゼロからEthereum(Solidity)でNFT個人開発サービスをリリースするためにやった8つのこと

以前、こんな記事(Herokuの無料プランが終わるので、移行先を探してみた)を書きましたが、ちゃんと比較検討したものではなかったので、改めて4つくらいのPaaSを比較してみて、より個人開発に向いたPaaSについて検討してみました。今回比較したのは以下です。Render.comHerokuRailwayFly.ioKoyeb 前提条件選定にあたって以下の前提条件を設定しました。Dockerが使える1ヶ月寝ないで稼働してくれるアプリケーションサーバ512MBのメモリバックグラウンドワーカーを建てられるDB(PostgreSQL or MySQL)が使え、デー...

【脱Heroku】そろそろ(Railsとかホストしたい)個人開発に向いたPaaSを決めようぜ

mofmofアドベントカレンダーの9日目です。株式会社mofmofのshwldです。mofmofはRuby on Rails(以下Rails)をメインにゼロイチフェーズのMVP検証を得意とする受託開発会社です。メイン技術がRailsとは言ってもmofmofでは、Railsを使わなくてはいけないという制約はありません。基本的には案件の担当チームがその案件に最適なスタックを選定していきます。そういった環境下でも、Railsは選択肢として最有力になりやすいです。ここまで書いて、なぜRailsが選ばれるのか社内できいてみたの方がいいかなと思ったのですが、期限の関係で今回はポエムです。...

RubyとTypeScript。サーバーサイド技術選定

こんにちはmofmofでエンジニアをしているshwldです。今日はmofmofで行っている技術1on1という試みについて書きます。 mofmofで行っている技術1on1とは実は以前に実施したことがあり、その際はこのような形で実施しました。https://zenn.dev/shwld/articles/22ee6e9e8970c8この度、前回のふりかえりを活かし2期目の実施をしました。主目的はエンジニアの技術力を上げるためとおいていたのですが、今回ちょっと目的が変わってきたのを感じます。最後にどう変わったのか書こうと思います。 前回のふり返りに対してのアクションは?...

技術習得・向上のための1on1②

こんにちはmofmofでエンジニアをしているshwldです。RenderはDockerfileに対応しています。開発環境と本番環境で同じDockerfileを使うことが可能です。これは実行環境の同期という意味で大きなポイントです。その上でRenderがすごいのはrender.yml一つで設定できるEasyさです。Dockerfileでローカルと同じ環境を再現しつつ、アプリケーション内からインターナルにアクセスできるホスト名を各アプリが持っているので、Renderで動いているアプリ同士のやり取りが基本的にRenderに依存しない標準的な方法（例えばhttp）で完結します。これは...

Render(render.com)は最高にちょうどいい本番Docker環境である

こんにちはmofmofでエンジニアをしているshwldです。アジャイルな開発でよく用いられる、ユーザーストーリーについてあらためて考えました。より良いユーザーストーリーを作るための原則をBill Wakeという方が提唱している「INVEST」という指標があるのでこれをみながらやっていることや思ったことを書いていきます。I – IndependentN – NegotiableV – ValuableE – EstimableS – SmallT – Testable Independent（独立している）ユーザーストーリーはそれぞれ独立して重複しないようにしま...

最高のユーザーストーリーについて再考

こんにちはmofmofでエンジニアをしているshwldです。Herokuから発表がありました。Heroku’s Next ChapterFocus on mission critical: discontinue free product plans and delete inactive accounts.無料製品プランの廃止、非アクティブなアカウントの削除。無料プランがなくなるようです。これにより、本番環境としてのHerokuは今まで通り使っていきますが、無料で使っていた用途について、Heroku以外の選択肢を検討してみました。 Herokuを無料で使いたいモチベ...

Herokuの無料プランが終わるので、移行先を探してみた

こんにちはmofmofでエンジニアをしているshwldです。今日はmofmofで行っている技術1on1という試みについて書きます。 技術1on1とは1on1の実施目的として、「部下の問題解決を支援し、業務の振り返りの場を設けることで、部下は日々の業務から多くの気づきや改善を意識することができます。」があります。これを技術的課題に当てはめ、「メンバーひとりひとりの技術的課題について深く考える場を設けることで、課題について多くの気付きや仮説、手段を意識することができます。」という効果を見込むものとなります。 なぜ始めたのかエンジニアは成長のために、実践の機会が必要です...

メンバーの技術力を上げるために1on1をするということを3ヶ月やってみた

こんにちはmofmofでエンジニアをしているshwldです。Componentを作るときに、storybook, jest, graphqlなどのファイルをひとまとめにして作ることが増えてきました。└ components  └ todo    └ TodoCreateForm       ├ index.tsx       ├ TodoCreateForm.graphql       ├ TodoCreateForm.stories.tsx       ├ TodoCreateForm.test.tsx       ├ TodoCreateForm.tsxこれを解消...

PLOPでComponentファイルを雛形から生成しよう

作ったアクションはこちらです。[Send awesome code block to Slack] Action!使い方SlackでBotを作りトークンをコピーするGitHub Actionsを設定するSlackでBotを作るhttps://api.slack.com/apps/へいき、Create New Appします。slack appFrom an app manifestを選び、以下のymlを貼り付けてボットを作成します。display_information:  name: Awesome code kunsettings:  org_deploy_enabled: false  socket_mode_enabled: false  is_hosted: false  token_rotation_enabled: falsefeatures:  bot_user:    display_name: Awesome code kunoauth_config:  scopes:    bot:      - chat:write      - chat:write.publicinstall slack appInstall Appのページにトークンがあるのでコピーしておきます。GitHub Actionsを設定する。GitHubのリポジトリ設定ページから、action secretSLACK_CHANNEL と SLACK_TOKEN を登録します。SLACK_CHANNELの例 random。SLACK_TOKENには先程SLACKのボット作成時にコピーしたトークンを貼り付けます。リポジトリに、.github/workflows/awesome.yml というファイルを作ります。name: 'awesome'on:  issue_comment:    types: [created]  pull_request_review_comment:    types: [created]jobs:  test:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v2      - uses: mofmof/send-awesome-code-to-slack-action@v0        with:          trigger_keyword: '[awesome]'          github_token: ${{ secrets.GITHUB_TOKEN }}          github_event_path: ${{ github.event_path }}          slack_token: ${{ secrets.SLACK_TOKEN }}          slack_channel: ${{ secrets.SLACK_CHANNEL }}これで準備は完了です。いざレビューコメントawesome-code無事届きました！slack-awesome-code

コードレビューで発見した良いコードをSlackへ共有できるGitHub Actionを作りました

こんにちはmofmofでエンジニアをしているshwldです。最近やっとDDDに入門し、エリック・エヴァンスのドメイン駆動設計を読みました。色々と知識を深めようとしているのでshwld版ドメイン駆動設計の異本として感想と仮説を書いてみます。 DDDについて感じたことDDDには戦略と戦術があります。戦略は、設計をどうやって行っていくのか、よいドメインをどうやって定義していくか、見つけていくか、蒸留していくかみたいなところ。対して戦術はコードにどう落とし込むのか、どうしたらドメインを豊かに表現できるのか、変更に強いのか。ドメイン駆動というくらいだから戦略から入らないとだめなので...

今更読んだエヴァンス本に感銘を受けたので感想書く

週に2時間VRChatのワールド作りを学んでいます。今回はUnityのTerrainというツールを初めて触ってみたら簡単に地形を作成できたので、そのログを残します。こんな地形を数十分で作成できました。Unity TerrainTerrainのサイトに行くとめちゃめちゃクオリティの高い地形が掲載されていて、流石にこれを作るのは骨が折れそうですが、逆にこんなのもできるのか！夢が広がりますunityterrain実際に地形を作ってみますHierarchyにTerrainを追加します3D Object -> Terraincreate-terrain作れました。edit-terrain地形を隆起させていきますブラシとRaise or Lower Terrainが選択されていることを確認して、ブラシで書き込んでいきます。terain-brashterrain gifテクスチャを貼っていきますブラシとPaint textureが選択されていることを確認して、Add layer を選びます。paint texture出てきたwindowで好きなテクスチャを選んでみます。sandもう一枚レイヤーを重ねてブラシで適用していきますlayer↑のように選択した状態で画面上のブラシを動かすと適用したい箇所だけ塗り塗りすることができました。草や木も生えるらしい時間の関係上試せませんでしたが、草木もさっと作れるようです。これだけで幅広いフィールドを作成できそうで、ワクワクする機能でした。

VRChatのワールドで地形を作成したかったので、UnityのTerrainというツールを使ってみました

GitHub Actionsは普段CI/CDとして利用しているのですが、もっと様々な効率化されたワークフローを作れるのではないかと思い、第一歩として自作GitHubActionsを作って公開してみました。GitHub ActionsとはGitHub社が提供している、リポジトリの様々なワークフローを自動化するための仕組み。ソースコードがcommitされたタイミングなど、様々なタイミングで処理を実行することができる。https://docs.github.com/ja/actionsどんなアクションが作れるのか自作パッケージを公開するに当たりどのような形式で作れるのか調べてみました。Docker containerタイプOSはLinuxDockerを使えるためあらゆる環境や操作を実現できるイメージの取得のために時間がかかるため、低速JavaScriptOSはLinux, macOS, Windows環境がJavaScriptだけに限定されるが、Docker containerタイプに比べ高速に実行できるComposite ActionsOSはLinux, macOS, Windows複数のワークフローをまとめたものを1つのアクションとして公開できるアクションを公開する条件はアクションは公開リポジトリにあること各リポジトリには1つのアクションが含まれていることアクションのメタデータファイル（action.yml または action.yaml）は、リポジトリのルートディレクトリにあることアクションのメタデータファイルの名前が一意であることGitHub Marketplace で公開されている既存のアクション名と一致させることはできないユーザーまたは組織のオーナーがアクションを公開している場合を除き、名前は GitHub 上のユーザーまたは組織と一致することはできない。例えば、Github という名前のアクションを公開できるのは GitHub 組織のみ。名前は、既存のGitHub Marketplaceのカテゴリと一致することはできないGitHub は GitHub 機能の名前を留保します。などといった条件があるみたいですが、最低限リポジトリを作ってREADME.mdとaction.ymlを置けば良いです。今回、branchをpushしたら、自動でPullRequestを作り、branch名からPivotalTrackerのストーリーIDを取得してリンクを貼るという簡単なactionをComposite Actionsで作成しました。name: Auto PR. Pivotal Tracker styledescription: Create a PR with an automatic title and summary by setting the branch as features/[Pivotal Tracker story ID].inputs:  github-token:    description: GitHub token    required: trueruns:  using: composite  steps:    - uses: actions/checkout@v2      with:        fetch-depth: 0    - name: Dump GitHub context      env:        GITHUB_CONTEXT: ${{ toJSON(github) }}      shell: bash      run: echo "$GITHUB_CONTEXT"    - name: Extract branch name      shell: bash      run: echo "::set-output name=branch::${GITHUB_REF#refs/heads/feature/}"      id: extract_branch    - name: Create Pull Request      uses: repo-sync/pull-request@v2      with:        destination_branch: "main"        github_token: ${{ inputs.github-token }}        pr_title: "[#${{ steps.extract_branch.outputs.branch }}] "        pr_body: |          https://www.pivotaltracker.com/story/show/${{ steps.extract_branch.outputs.branch }}        # pr_label: "production"        pr_assignee: ${{ github.actor }}branding:  icon: git-pull-request  color: green公開したGitHub Action: auto-pr-pivotal-tracker-styleリリースの方法については、このページを参考に基本的にはaction.ymlだけをいじっていくことで公開できました。公開できたのでGitHub Actionを作るときは、公開すべきかも考えて使っていこうと思います。

自作のGitHub Actionsを公開してみよう

RedwoodJSでFirebaseログインを試してみたログです。以前の記事RedwoodJSのファーストインプレッションRedwoodJS。認証もサポートが厚そうredwoodjs-authethereumまであるのは驚き1. 手順通りにコマンドを実行だいたいここに書いてある通りで動きそうなのでやってみます。yarn rw setup auth firebaseコマンドを実行すると以下のようなことをやってくれたweb側に @redwoodjs/auth, firebase をインストールweb/src/App.tsx にfirebase設定の雛形を含むAuthProviderの配置api側に firebase-admin をインストールapi/src/functions/graphql.ts にgetCurrentUserを生やすapi/src/lib をfirebase仕様に置き換え実際に自分で認証周りの手動で設定をいじるときにはこのあたりを設定すれば良さそうだ。2. .envにfirebaseの情報を追加FIREBASE_API_KEY=xxxxxFIREBASE_AUTH_DOMAIN=xxxxxFIREBASE_PROJECT_ID=xxxxxFIREBASE_STORAGE_BUCKET=xxxxxFIREBASE_MESSAGING_SENDER_ID=xxxxxFIREBASE_APP_ID=xxxxxFIREBASE_MEASUREMENT_ID=xxxxx3. ログイン状態確認用にページを作るyarn rw g page SignIn4. ログインボタンを作るyarn rw g component LogInOutButtonuseAuth を使ってログインボタンを実装。今回はGitHub認証を使ってみた。※事前にFirebaseのコンソールでGitHub認証の設定が必要useAuth で受け取れる logIn メソッドにプロバイダ名を渡すことで、githubでの認証でログインできるようだimport { useAuth } from '@redwoodjs/auth'const LogInOutButton: React.VFC<{  provider?: 'github.com'}> = ({ provider = 'github.com' }) => {  const { loading, isAuthenticated, logIn, logOut } = useAuth()  if (loading) {    return <div>loading</div>  }  return (    <button      onClick={async () => {        if (isAuthenticated) {          await logOut()        } else {          await logIn(provider)        }      }}    >      {isAuthenticated ? 'Log out' : 'Log in'}    </button>  )}export default LogInOutButton5. ページにボタンを配置import { Link, routes } from '@redwoodjs/router'import { MetaTags } from '@redwoodjs/web'import LogInOutButton from 'src/components/LogInOutButton/LogInOutButton'const SignInPage = () => {  return (    <>      <MetaTags title="SignIn" description="SignIn page" />      <h1>SignInPage</h1>      <p>        Find me in <code>./web/src/pages/SignInPage/SignInPage.tsx</code>      </p>      <p>        My default route is named <code>signIn</code>, link to me with `        <Link to={routes.signIn()}>SignIn</Link>`      </p>      <LogInOutButton /> // <-- これ追加    </>  )}export default SignInPageこれだけでログインボタンが動いたLogin pageまとめRedwoodJSでFirebase認証を試してみた。相変わらずジェネレータが強力でほとんどジェネレータがやってくれるのはとても快適。ドキュメントはまだそこまで充実しておらず分からなかった点として、今回ポップアップで認証したが、リダイレクトでの認証をどうやってやるかなど、細かいカスタマイズがどの程度しやすいかが気になるところだ。また、api側での認証状態取得なども見ていきたい参考サイト- https://redwoodjs.com/docs/authentication#firebase- https://github.com/redwoodjs/playground-auth

RedwoodJSでFirebase認証（GitHubプロバイダ）してみた

RedwoodJSというフレームワークがめちゃくちゃ良さそうなので入門してみます。RedwoodJS is 何?Redwood is the full-stack web framework designed to help you grow from side project to startup. Redwood features an end-to-end development workflow that weaves together the best parts of React, GraphQL, Prisma, TypeScript, Jest, and Storybook.サイドプロジェクトからスタートアップくらいのプロダクトの成長を支援するためのフルスタックフレームワークとのことで、Railsと近い立ち位置にいるような印象。React、GraphQL、Prisma、TypeScript、Jest、Storybookを用いたフレームワーク。選定しているライブラリがとても自分好みです。GitHub共同創設者、jekyllの作者、Gravatarの作者、Semantic Versioningの著者、TOMLの発明者など錚々たるメンバーに寄って立ち上げられたOSSプロジェクト。まずはインストール> yarn create redwood-app try-redwoodjs --typescriptフォルダ構成.redwood.vscodeapi├ db├ src│ ├ directives│ ├ functions│ ├ graphql│ ├ lib│ └ services└ typesscriptsweb└ public  └ src    ├ components    ├ layouts    └ pages.redwoodディレクトリAuto-generated TypesThe CLI automatically generates types for you. These generated types not only include your GraphQL queries, but also your named routes, Cells, scenarios, and tests.いきなりめちゃくちゃ良さそうなこと書いてあるGraphQLだけでなく、ルートなども型を生成してくれるとか。すごい.vscodeディレクトリ良いですねー。create時点でlaunch.jsonもあるのは良いですねー。apiディレクトリThe /api Directoryapi/dbPrismaのスキーマが入ってるここをいじってdbを作っていくapi/srcサーバーサイドコードを入れる箱中で更に分類するapi/src/directivesGraphQLのディレクティブを定義するところapi/src/functions自動生成されるgraphql.jsファイルと、lambdaファンクションが入るらしい、リンクがNetlifyのfunctionsになっているがそこにデプロイされるの?どういうこと?api/src/graphqlGraphQLスキーマを定義するところっぽい。コードファーストはできない?api/src/lib認証や、db接続に使える関数が置いてある。そういうレイヤーの関数をおくところっぽいapi/src/servicesビジネスロジックを格納するところ。scriptからも呼べるような依存性にしておくと良いっぽいwebディレクトリweb/publicよくある公開ディレクトリweb/src/componentsコンポーネントとCellコンポーネントが格納されているweb/src/layoutsページ間で共有されるレイアウト部品ラッパーweb/src/pagesページを構成する要素を集めたページコンポーネントCell?web/src/components/Post/PostCell/PostCell.tsx規約通りの命名でexportすると、Redwoodがライフサイクル管理や、型の生成をしてくれるらしい。特に特徴的なのがGraphQLクエリのvariablesquery FindPostById($id: Int!) { ... というクエリを書くと<PostCell id={3} /> のようにidのpropが生えるみたい。なるほど。なかなかよいかもしれない。また、CLIで生成できる。yarn rw generate cell postこのコマンドでいかが生成されたPostCell.tsxPostCell.mock.tsPostCell.stories.tsxPostCell.test.tsx生成されたファイルはこんな感じPostCell.tsximport type { FindPostQuery } from 'types/graphql'import type { CellSuccessProps, CellFailureProps } from '@redwoodjs/web'export const QUERY = gql`  query FindPostQuery($id: Int!) {    post: post(id: $id) {      id    }  }`export const Loading = () => <div>Loading...</div>export const Empty = () => <div>Empty</div>export const Failure = ({ error }: CellFailureProps) => (  <div style={{ color: 'red' }}>Error: {error.message}</div>)export const Success = ({ post }: CellSuccessProps<FindPostQuery>) => {  return <div>{JSON.stringify(post)}</div>}PostCell.mock.ts// Define your own mock data here:export const standard = (/* vars, { ctx, req } */) => ({  post: {    id: 42,  },})PostCell.stories.tsx各状態のストーリーをそのまま書けるのでこれはめっちゃはかどるのでは...import { Loading, Empty, Failure, Success } from './PostCell'import { standard } from './PostCell.mock'export const loading = () => {  return Loading ? <Loading /> : null}export const empty = () => {  return Empty ? <Empty /> : null}export const failure = () => {  return Failure ? <Failure error={new Error('Oh no')} /> : null}export const success = () => {  return Success ? <Success {...standard()} /> : null}export default { title: 'Cells/PostCell' }PostCell.test.tsxstorybookと同じく各状態のコンポーネントのレンダリングを即テストできるので捗りそうimport { render, screen } from '@redwoodjs/testing/web'import { Loading, Empty, Failure, Success } from './PostCell'import { standard } from './PostCell.mock'// Generated boilerplate tests do not account for all circumstances// and can fail without adjustments, e.g. Float and DateTime types.//           Please refer to the RedwoodJS Testing Docs://        https://redwoodjs.com/docs/testing#testing-cells// https://redwoodjs.com/docs/testing#jest-expect-type-considerationsdescribe('PostCell', () => {  it('renders Loading successfully', () => {    expect(() => {      render(<Loading />)    }).not.toThrow()  })  it('renders Empty successfully', async () => {    expect(() => {      render(<Empty />)    }).not.toThrow()  })  it('renders Failure successfully', async () => {    expect(() => {      render(<Failure error={new Error('Oh no')} />)    }).not.toThrow()  })  // When you're ready to test the actual output of your component render  // you could test that, for example, certain text is present:  //  // 1. import { screen } from '@redwoodjs/testing/web'  // 2. Add test: expect(screen.getByText('Hello, world')).toBeInTheDocument()  it('renders Success successfully', async () => {    expect(() => {      render(<Success post={standard().post} />)    }).not.toThrow()  })})どんなコマンドがあるのか良さそう> rw <command>Commands:  rw build [side..]          Build for production  rw check                   Get structural diagnostics for a Redwood project                             (experimental)               [aliases: diagnostics]  rw console                 Launch an interactive Redwood shell (experimental)                                                                    [aliases: c]  rw data-migrate <command>  Migrate the data in your database                                                      [aliases: dm, dataMigrate]  rw deploy <target>         Deploy your Redwood project  rw destroy <type>          Rollback changes made by the generate command                                                                    [aliases: d]  rw dev [side..]            Start development servers for api, and web  rw exec [name]             Run scripts generated with yarn generate script  rw generate <type>         Generate boilerplate code and type definitions                                                                    [aliases: g]  rw info                    Print your system environment information  rw lint [path..]           Lint your files  rw prerender               Prerender pages of your Redwood app at build time                                                               [aliases: render]  rw prisma [commands..]     Run Prisma CLI with experimental features  rw record <command>        Setup RedwoodRecord for your project. Caches a JSON                             version of your data model and adds                             api/src/models/index.js with some config.  rw serve [side]            Run server for api or web in production  rw setup <commmand>        Initialize project config and install packages  rw storybook               Launch Storybook: a tool for building UI components                             and pages in isolation                [aliases: sb]  rw test [filter..]         Run Jest tests. Defaults to watch mode  rw ts-to-js                Convert a TypeScript project to JavaScript  rw type-check [sides..]    Run a TypeScript compiler check on your project                                                              [aliases: tsc, tc]  rw upgrade                 Upgrade all @redwoodjs packages via interactive CLIOptions:  --help     Show help                                                 [boolean]  --version  Show version number                                       [boolean]  --cwd      Working directory to use (where `redwood.toml` is located.)Examples:  yarn rw g page home /  "Create a page component named 'Home' at path '/'"感想思ったよりとても重厚なフレームワークでした。思想はとても良く、元々Apolloのベストプラクティスに共感できる場合は結構マッチするのではないかと思います。良さそうなポイント- 基本的にはRedwoodJSが全てのツールをラップしているので、パッケージ依存バージョンの動作保証をRedwoodJSにある程度任せられそう- test, storybookを即書ける- 単純なWebアプリケーションはRailsのActionView並に高速に実装できそう  - それでいてReact, GraphQLを使っているのでUIを柔軟にできる懸念- RedwoodJSへのロックイン特にtest, storybookを即かけるのはめちゃくちゃ良さそう。その上単純なページを作る速度もRails並なので、かなり強力なフレームワークだと感じました。なんか軽いアプリケーション書いてみたい。

RedwoodJSのファーストインプレッション

mofmofでは新規サービスをゼロから開発することが多くあります。その際にshwldがどのように技術選定をしているのかを書いてみます。こちらの記事がとても参考になる内容で、私なりにも書いてみようと思いこの記事を書いています。https://zenn.dev/moga/articles/my-technology-selection2022年2月 現在での内容です。前提mofmofでは3ヶ月くらいでMVPを提供することが多いです。MVPとしてリリース後、継続して開発することも多く、作って終わらず中長期的に成長させられる安定した技術を優先して選定しています。メンバーにはRuby on Railsを得意とする人が多いため、Railsを優先的に選定します。とはいえ、アサインされた人や案件によりその都度、最適なものを選んでいます。この記事では、shwldが選定する場合について書いています。インフラ、プラットフォームHeroku実績も多く社内の知見もあるため、優先的に選定されますAWS案件によってはこちらを使うこともありますが、Herokuでも問題なければHerokuを優先して使いますS3だけ使う事が多いですFirebase作りたいものがアプリの場合、認証を利用することがありますそれ以外のリソースはあまり案件利用はしていませんGCPAWSに強い希望がなければ自分はこちらを使いたいです。Herokuにはストレージがないのでこちらを利用したりしますアプリケーションRuby on Railsほぼすべての案件で利用しています。安定択変更へ柔軟に対応できるようViewについては、ActionViewはあまり選定していませんこれによりアプリへの対応など臨機応変に対処できるようになっています。React + TypeScriptActionViewの変わりにReactでのSPAを利用します。リポジトリを分けると開発スピードが落ちるため、最初はモノレポでDeviseで認証済のルートにアタッチして使う事が多いです。この構成ならあとからリポジトリを分けてNext.jsに乗っかるなども容易にできるためバランスがいいと感じていますGraphQL (Apollo Client/GraphQL Ruby)React + TypeScriptを利用する際にRailsと話をしやすくするために導入しました。Graphql Code Generatorとの組み合わせは一度使ってしまうと離れられない魅力がありますExpo, ReactNativeアプリも欲しい場合に選定していますバックエンドがGraphQLの場合にReactNativeならApollo Clientが使えるうえ、技術者が習得すべき技術スタックもReactだけで良いというメリットが有りFlutterでも良いですが、自分はこちらを推していますインフラとしてのExpoも配信やプッシュ通知などで利用しますEASによりCI/CD環境を作りやすくて良いですReact + TypeScript + GraphQL Rubyの構成はわりと社内で流行っており、7~8案件くらいはこの構成で実装されている実績があります。スピードではRailsのActionViewにはかないませんが、バランス良く堅牢にかけるよい構成だと思います。おすすめです。今後Ruby on RailsでGraphQLサーバーを書く事自体に課題感はあまりないのですが、TypeScriptでサーバーを書いてみたいと思い、最近はPrismaやNexus、NestなどNodeでサーバー周りを触ってみています。サーバーがNodeになるとReact TypeScriptを中心としてReactNativeでアプリもかけるため、言語の統一ができる。RubyとTypeScript2つの言語を扱うコンテキストスイッチを減らせる。フロントエンドと同じ言語であることから、ユニバーサルなコードは共有できるというメリット。　そして、何よりTypeScriptの型を利用できるため期待しています。最後にmofmofではエンジニアを募集しています。この記事に書いた構成以外にもFlutterやElectron、HoloLensなど楽しそうな技術を使っているメンバーもいます。興味を持っていただいた方は下のリンクを見てみてくださいね

新規サービスを作るときに使う技術選定

ExpoのEASが正式サービス開始し、managedワークフローでも利用できるということなので調べて試してみました。 情報収集公式ドキュメントが充実しているので、公式だけ見ればおｋ EASとはExpo Application Service従来のマネージドワークフローでのビルド結果にはExpoが提供している機能をまるっと内包していた。そのためアプリのサイズが大きかったり、内包している機能以外をカスタム対応できない問題があった。EASはmanaged workflowの上記のような制約を取り払うものであり、マネージドワークフローの開発体験のままで、カスタムネイティブコード...

managed workflowなExpoアプリをEAS buildに移行したい

WSL2上でExpoを起動し、LANで接続するtonnel接続を利用すればWSL2でexpoを利用すること自体は簡単だが、不安定な気がしたのでLAN接続も試してみる。こちらの記事を参考(丸コピー)にして試してみたが、日本語環境だったりするせいかうまく実行できなかった。自分の環境で

WSL2上でExpoを起動し、LANで接続する

Capacitor iOSやってみるXCodeが開いたがこんなエラーXCodeのSIgning & Capabilitiesでteamを選択したpod installがいるのかな?動きました。すごい

Capacitor iOSやってみる

CapacitorでCORSをどうすればよいか考えたCapacitorから自分のAPIサーバーへのリクエストがCORSでブロックされた。当然といえば当然だろうサーバー側のCORS設定を緩めたくはないがどうすればいいのか。考えたCapacitorでOriginは以下のように設定され

CapacitorでCORSをどうすればよいか考えた

Next.jsプロジェクトにCapacitorを導入してアプリ化してみるCapacitorをインストール - Capacitor (capacitorjs.jp)Next.jsのexportで静的ファイルを生成しておくnextが出力したファイルを指定してcapacitorをini

Next.jsプロジェクトにCapacitorを導入してアプリ化してみる

GitHub ActionsでPullRequestを自動生成する割とStaging確認をしてAcceptしたやつだけ本番に反映するというフローを取りたいことがあります。Gitフローはちょっと重いし、GitHubフローもその辺やるにはFeature毎の環境をたてるとかしないと行け

GitHub ActionsでPullRequestを自動生成する

@swc/jestを使ってjestを高速化するswcはrust製のコンパイラで、TSの型チェックもなく非常に高速である。これを使うことでjestが早くなるらしいのでやってみた。インストール.swcrcというファイルを作る。あまり書き方に関する情報がない。割とカンで公式かどっかから

@swc/jestを使ってjestを高速化する

TypeScriptについて考えていることメモカスタムフックはTuple返し?オブジェクト返し?Tuple返し通常、Tuple返しのhookを使う場合、上記のように展開して使う。このときhookの利用者は名前付けを行う必要がある。これの利点は同じコンポーネントに複数同じhookが

TypeScriptについて考えていることメモ

CDNのキャッシュ設計について考えたこと前提データ構造設計GET post(id)post取得時にはそれ自体のidをキーにしてキャッシュするまた、postが保持しているtag分だけサロゲートキーを指定するGET postspostの一覧を見るときは一覧用のキーでキャッシュするta

CDNのキャッシュ設計について考えたこと

Tupleのそれぞれの要素からnullとundefinedを除いた型

Graphql::BatchでActiveStorageのN+1を解消と思ったら、公式にあった公式exampleを利用する公式exampleを使うことにしたが複数ファイルのアタッチに対応していなかったのでhas_one, has_manyどちらでも行けるように調整してみた

Graphql::BatchでActiveStorageのN+1を解消

Slate.jsチートシート﻿公式Doc画面下端で自動スクロールする現在のノードを上に順に取得するEditor.aboveは直上にあるすべてのノードを検索する。もともとはEditor.matchという名前だったが0.55で改名された

Slate.jsチートシート

has_manyにscopeをつけるとcreate時に関連を自動保存できないのようにscopeをつけると、create時に関連を自動保存できなくなるinverse_ofが自動判定されなくなるからみたいなのでつければOKREF: https://github.com/rails/r

has_manyにscopeをつけるとcreate時に関連を自動保存できない

eslint/prettier設定はこれを使うのが良いです。 使いたい環境を選ぶだけでいい感じの設定になるので、脳死でこれにしましょう

eslint/prettier設定はこれを使うのが良いです。 

ransackでActiveRecordのenumを検索したい場合runsack-enumを使うといい。コードもシンプルで、最悪バグっても自分で参考にして治せそうなので気軽に入れてみよう

ransackでActiveRecordのenumを検索したい場合

Railsでbooleanをintegerに変えたいpublished っていう boolean カラムを integer のenumに変えたいみたいなときdefault: 指定に注意 もともとのカラムにdefaultが指定されている場合、型が合わなくてmigrateできないこと

Railsでbooleanをintegerに変えたい

graphql-rubyの個人的知見まとめ最近は仕事でも個人開発でもgraphql-rubyを使っています。使っているうちにここ、こうしたほうがいいんじゃないかとか試行錯誤した結果のオレオレプラクティスをまとめました。追記するかも。graphql-rubyのloadsgraphq