AI時代にこそTDDだと思う話
GitHub Copilot、みなさん使ってますか？すでに多くの方が利用しており、「ないと困る」という方から「提案の質に問題がある」「まだまだ使えない」という方まで、様々な意見を聞きます。 筆者はGitHub Copilotに対して非常にポイティブな立場です。GitHub Copilotは使い方次第で開発速度を格段に向上させることを身をもって体験しており、これからの時代においてはGitHub CopilotなどのAIツールを使いこなせるかどうかで、個人の開発速度に非常に大きな差が出ると考えています。 重要なのは使い方次第と言う点です。前述のように様々な感想が溢れているのはAIツールの習熟度が大きく影響しているようにも感じます。AIツールは静的解析同様、利用者側の手腕が大きく問われるツールであると筆者は感じています。コマンドプロンプトエンジニアリングという言葉もあるように、AIツールを使いこ
Rustでの 抽象化 3パターンについて
※この記事は全然入門記事ではないです。Javaなどのオブジェクト指向言語とRustをある程度理解している前提での記事です。あと、メモ程度に雑に書いています。 今回は抽象化がテーマです。オブジェクト指向の多態相当のことをRustでどうのように解決すればいいのでしょうか。個々の実装型の都合によらず、呼び出し側は統一的なインターフェイスで操作するケースはRustでもあるはずです。 オブジェクト指向言語の設計に慣れていると、Rustで設計するときにどうしたらいいかわからないことがあります。なぜならRustには継承がないからです…。まぁJavaと比べるとだいぶ違うので頭を切り替える必要があります。今回はそういう感じの記事です。 では、早速デザインパターンを題材にして考えてみましょう。 抽象化について 簡単なコマンドパターンから考えます。 ここでは単純に渡した文字列を標準出力するコマンドを考えます。以
認可のベストプラクティスとDDDでの実装パターン
最近、少々複雑な権限機能の開発を担当している中で、対応方針を悩んでいたことがありました。 権限機能というものは取り扱いが難しく、影響範囲が広いにも関わらず、対応漏れや考慮不足があると情報漏洩に繋がってしまいます。 また、機能拡張をしてく中でも対応漏れを起こさないようにする必要があるなど、考えることも多く頭を悩ませておりました。 そこで、認可処理の設計のベストプラクティスやDDDの実装パターンに認可処理を組み込む方法など、色々と調べていたのですが、その中でいくつか知見を得られたのでまとめようと思います！ 権限と認可 権限と切っては切れない関係にあるのが認可です。 権限はある操作を実行できる権利を指します。 それに対して、認可は操作を実行する許可を出すため仕組みのことを指します。 例えば、ブログ投稿サービスで考えてみると、以下のような感じです。 権限: 投稿者はポストを編集できる。 認可: ユ
Vitestでドキュメンテーションテストする
ドキュメンテーションテストをご存知でしょうか。 ドキュメンテーションテストとは、ドキュメントに記載されたコードを実行し、その結果が期待通りであるかを検証するテストのことです。 これにより、ドキュメントの内容が常に最新の状態であることを保証することができます。 Rustでは公式がrustdocというツールを提供しており、これを使うことでドキュメンテーションテストを行うことができます。 この記事では、TypeScript/JavaScriptでドキュメンテーションテストを行うVitest向けのプラグインを紹介します。 vite-plugin-doctest vite-plugin-doctestは、Vitestのエコシステムを利用してドキュメンテーションテストを行うためのプラグインです。 Vitestとは おそらく、この記事を読んでいる方はほとんど知っていると思いますが、VitestとはVit
心穏やかにDBバージョンアップ！ロジカルレプリケーションで安全にバージョンを切り戻せるようにした話
はじめに みなさん、DBをバージョンアップして酷い目にあったことありますよね？ 先日ログラスの本番データベースのバージョンアップをしたのですが、Site Reliability Engineeringの観点で非常に良いトライが出来たので共有します。 PostgreSQLのロジカルレプリケーションを使って、データを最新に保った新旧のインスタンスを用意した。結果的に安心安全にバージョンアップ作業ができました。 データベースのバージョンアップはサービス運用やっていくと絶対にやらないといけない作業ですが、影響範囲は甚大です。この記事では工夫することで、何か問題が起こってもすぐに切り戻すことが出来るという話をします。 このメンテを通じて、ログラスで利用していたAurora PostgreSQLをエンジンバージョン11.19（PG11）から15.2（PG15）にバージョンアップしました。 バージョンア
フロントエンドテスト、モジュールモックでStorybookのインタラクションテストの開発コストを下げる
Storybook のインタラクションテストのコストを下げる Storybook を使用すると、ブラウザ上で動作を確認しながらテストコードを記述できるため、生の Jest よりも開発が容易になります。ただし、Storybook には Jest にある重要な機能である jest.mock がないという欠点があります。jest.mock は、テスト対象のコンポーネントがインポートしているモジュールをフックして、簡単にモックを作成することができますが、Storybook ではこの機能は使用できません。ビルド時に他のファイルへの干渉が防止されてしまいます。 この問題を解決するために、以下の Addon を使用することで、jest.mock と同じような機能を Storybook 上で利用することができます。 npm サンプルプログラム 動作内容 ログイン用フォームの動作チェック FormMock.
IAM Roles Anywhere + 自己署名証明書 を爆速で作ってみた
背景 去年7月にIAM Roles Anywhereがリリースされ、アクセスキー管理が不要でAWSの外部のリソースに対してIAMロールを割り当てるできるようになりました。 しかし公式のドキュメントには自己署名証明書を作成する方法が記載されていませんし、現在ネット上に上がっている記事では手順も複雑でなかなか容易に作成できないものが多いと感じました。 なので今回はIAM Roles Anywhere + 自己署名証明書を爆速で作成する方法を紹介します。 また、GitHub上にIAM Roles Anywhere作成のスクリプトも公開していますので、良かったらご活用ください。 1. cfsslのインストール まずはcfsslをインストールします。cfsslは簡単にCSR、秘密鍵を作成できるツールです。 opensslですといろんなオプションを指定しないといけないし、アルゴリズムを間違えたら信頼ア
WebAPIを構築する際にAPI Gateway+Lambdaを選択するべきか？
はじめに このツイートに結構反響があったので、雑になるがとにかく自分の考えをダンプする。もともと書いていた記事はうっかりやらかしてデータロストした、泣きたい。 話をわかりやすくするために、ALB+ECS（Fargate）を使ってWebAPIと対比して説明しているが現実はもっと複雑である。 引用リツイートをもらえた部分などについてもアンサーっぽいことも書いていく。 AWS利用費と人件費の話 AWS上にWebAPIを構築する際に、AWS利用費の削減をモチベーションとしてApiGW+Lambda構成が、採用されることがある。確かにAWS利用費は下がるがApiGW+Lambda構成を設計〜運用するためにはAWSに関する知識の中でもとくに専門的な知識が必要になる。こういった人材を雇用または外部へ発注し続けることは人件費に跳ね返ってくる。 ApiGW+LambdaがWebAPIのための構成として唯一無
Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス
読者対象 ある程度データベースに関する知識を持っている，経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため，すべての SQL 使用者を対象とする また，ゼロからの丁寧な説明というよりは，リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id （データ型と INSERT 時のデフォルト埋め） 導入 一般的に採用されやすいプライマリキー用の値として，以下を考える。 連番整数 MySQL では AUTO_INCREMENT， Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7（ドラフト）: 単調増加であるタイムスタンプとラ
Web 技術解体新書「第二章 Cache 解体新書」リリース
Web 技術解体新書「第二章 Cache 解体新書」リリース Intro 「Web 技術解体新書(Web Anatomia)」の第二章として「Cache 解体新書(Cache Anatomia)」をリリースしました。 これで予定している八章のうち二章が終わりました。 第一章: Origin 解体新書 第二章: Cache 解体新書 Cache 解体新書 以下の Response Header Field がどういう意味を持つか正確に説明できますか? おそらく多くの Web 開発者が一度は見たことがあり、これを「1 時間キャッシュする」という意味で指定している人もおおいでしょう。 では、どこから 1 時間で、 1 時間経ったらなにが起こるのか、これが Response でなく Request に付与されたらどう変わるのか、きちんと把握できていますか? そもそも、一般的にキャッシュ機構における
「無人化システム」を駆逐する組織マネジメントとエンジニアリング
弊社では2019年3月ごろから「無人化システム」の駆逐を進めています。本記事ではこの取り組みを、組織マネジメントとエンジニアリングの側面から紹介します。 恐怖の無人化システム 「無人化システム」は社内の独自用語なので、まずは言葉の意味から説明します。 無人化とはなにか 無人化の前に属人化について触れておきましょう。weblio辞書から属人化について引用します[1]。 ある業務を特定の人が担当し、その人にしかやり方が分からない状態になることを意味する表現。 無人化は属人化の進化系です。無人化とは「属人化していた業務の担当者がいなくなってしまい、誰にもやり方が分からない状態になること」と定義できます。誰がどう見てもダメな状態ですね。 無人化システムとはなにか システム運用が属人化し、かつその運用者が退職するとシステムが無人化します。我々の会社ではこのようなシステムを『無人化システム』と呼んでい
ドメイン駆動設計からオブジェクト指向、そしてアジャイル開発まで。関連書籍練り歩きのススメ
本記事はドメイン駆動設計(DDD) Advent Calendar 2021 25日目の記事です。 「もっとビジネス変化に耐えられる設計を目指したい」「ただデータをやりとりするだけなのに複雑化してしまうのを防ぎたい」 様々な動機からドメイン駆動設計に入門しようとする方がいると思います。 自分もエンジニアとして働きはじめて、「どうしてすぐに変更しにくくなってしまうのか」「より柔軟な設計にするにはどうすればよいか」と悩むことが多くなり、良い設計手法を探って出会ったのがドメイン駆動設計でした。 最初はドメイン駆動設計関連の本ばかりを読んでいたのですが、途中から「これってドメイン駆動設計というよりはオブジェクト指向の話では？」とオブジェクト指向に興味を移し、さらに「より変化に強いプロダクト開発するにはチームから変化させないとまずいのでは？」とアジャイル開発に興味が移りました。 本記事では、ドメイン
やっぱりwebpackがわからない（エピソード1）
やっぱりwebpackがわからない（エピソード2）、そもそもnpmからわからないを公開しました。 webpackがわからない 最近はViteが注目されだして、実際にとても良いビルドツールです。Vue.jsのEvan Youさんが開発しただけのことはありますね。ネーミングもイカしてます。しかし、だからといって、では開発環境にViteを採用しようと簡単にはできないのが、業務の辛い所です。新しい技術を採用して、「わしが全責任を引き受けるぜよ」というThe 男気！な人はなかなかいません。 したがって、当分はwebpackを使い続けることになるのですが、これが未だによくわからないという人が意外と多いです。フロントエンドプログラミングの初心者に近い人などは、この段階でつまずくことにより、すっかり自信をなくしてしまうこともあります。 ですが一先ず安心してください。webpackを含むこれらフロントエンド
e34fmの#3からSREについての概要を文字起こししてみた
モチベーション 大好きなテック系ポッドキャストe34.fmの#3でSREというロールについて簡潔かつわかりやすく解説されていたので、番組の紹介も兼ねて文字起こしをしてみました。起こしたのはmainセクションの第一部のみですがめっちゃ長いです笑 対象読者 SREというロールの役割についてざっくり概要を知りたい人 e34.fmがどんな番組なのか知りたい人 ラジオの文字起こし記事が好きな人 注意事項 音声コンテンツの文字起こしなので記事としては多少冗長になっています 文字起こしですが文章として読みやすくなるように単語を補うなどしています 本編 @deeeet:D @rrreeeyyy:R @nari_ex:N D : じゃあ早速第一部、SREとは何かについて整理してきたいと思います。じゃあまず、これはれい君への質問なんだけど、そもそもSREとはいったい何でしょうか。 R : すごい難しい質問に聞
git gc の仕組みを原理から理解してサイズを 136MB → 7.2MB(95%減)まで削減した時の勉強メモ
個人用メモです。 「git gcってあんまし容量減らないよなぁ」 と思ったのが動機です。調べたけどパッと腑に落ちる記事がなかったので「自分で git のソースコード見た方がいいな」と急にモチベ発動してグワっと勉強しました。またついでに歴史改変の方法も調べたのですが、公式で既に WARNING が出てるほど非推奨化されてるfilter-branchを使用してる記事が多かったので、2021 年現在で多分一番推奨されてるfilter-repoを使ってやる方法もまとめました。 ちなみに容量減らしても高速化するかというとそこまで単純ではないです。そもそも減らさなくても partial clone で blob オブジェクトを必要最低限に指定して昔の blob をデフォルトで持ってこないようにしたり(--no-checkoutと併用するとより効果有る)、その後本当に自分が必要なやつだけ sparse-
Go(Echo), Gorm, Mysql, Docker, Swaggerで、クリーンアーキテクチャなAPIサーバーを作ったメモ
自分の本業は10年物のMVCプロジェクトなのでClean Architecture忘れがちです。 なので、慣れてるGoでパッとClean Architectureの復習を行ってみました（２年前にPythonでやった事はあるんだけど・・・）。 このスクラップでは単語とか作りどころとかを整理するのですが、また後でRustで作ってそっちは前例がほぼないので記事にします。 Go + Clean Architectureは結構記事あるんですが、Swaggerつけたしたのと自分なりに納得いくディレクトリ構成にオリジナリティを出しました。ちなみにgo-swagger使うと本当は凄く楽に作れるのですが(ついでにフロントはopenapi-generator)、今回はClean Architectureを理解するのが主目的なので、サーバーは手書きでopenapiのyamlも1から自作しました。 ↑ postに
GCPでSagaパターン実装
概要 メディアやコミュニティ系のアプリケーション開発を中心に行っていたが、最近会社で決済系のシステムを扱うようになったこともあり、複数のサービス間がある中でどう結果整合性を担保するかについて学んでいた。 そこで学んだ複数サービス間での整合性を保つための手法として分散Sagaパターンがあり、実際にCloud RunとCloud PubSubで実装をしてみた。 複数サービスでの整合性 複数サービスでの整合性の問題 一般的にシステムを複数サービスに分けることによって、サービスを効率的に利用することや開発チームを分けることや小さくデプロイが可能など多くのメリットが挙げられる。 しかし、複数サービスにしたときの１つの問題として、データの整合性を取ることが難しくなることが挙げられる。 例えば、1つのDBのシステムに対してデータのWriteをアトミックに行う場合はDBのトランザクション等を使うことによっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
作ってわかる！ はじめてのgRPC
Webhook.site のまとめ
same-site/cross-site, same-origin/cross-originをちゃんと理解する
