はてなブックマーク

定義する例外を減らしつつソフトウェアを設計する方法を"A Philosophy of Software Design"から学ぶ 会社の読書会で”A Philosophy of Software Design”を読んでいる。 自分の担当で第10章 “Define Errors Out Of Existence” をしっかり読む機会があり、けっこう興味深い内容なので読書メモをブログにも書いておく。 章タイトルについて 章タイトル”Define Errors Out Of Existence”は直訳すると「エラーが存在しないものとして定義する」。例外やエラーはプログラム中で定義するものなので”define”の語を使っている様子。 こなれた感じにするには「エラーがもとから存在しないようにする」ぐらいが妥当そう。本文中では”defining away”（”define”を使いつつ消し去るニュアンスを

この記事はRust Advent Calendar 2023 シリーズ1の4日目の記事です。 あるソフトウェアをテストするとき、そのソフトウェアがデータベースやメッセージブローカのような外部のサービスに依存する場合に、その依存をどのように扱うかという問題がつきまとう。この問題へのよくある解決策としては 依存サービスを差し替えられるような設計にして、テスト実行時はモックに差し替える Docker Composeなどであらかじめ依存サービスをテスト用のコンテナとして立ち上げておき、テスト実行時はそれらのサービスが動くコンテナにアクセスする などが挙げられる。 今回はさらに別の方法として、テスト実行時にテストコードの中から依存サービスをコンテナとして立ち上げるためのフレームワークであるTestcontainersを紹介する。また、RustでTestcontainersを使うときの実例を紹介する。

この記事は一休.com Advent Calendar 2023 8日目の記事です。 2023-09-25に入社して2か月半が経ったので、既存のWebサービスの開発にソフトウェアエンジニアとして参加するにあたって役立ったことを書いておく。 『Webサービスのソフトウェアエンジニアとしての転職活動で役立ったこと』の続編といえるかもしれない。 目次 前提 観点 どのようなサービスかを調べる どのようにデータを保持するかを調べる どのようなコードかを調べる 「未知の未知」をできるだけ早く減らす チームの開発体制に興味を持つ 所感 前提 レストラン予約のサービスの開発に参加した 歴史が長い（2006〜） Webアプリケーションを開発する 技術スタックは転職前後で完全に変わった 前: Rails, PHP, Nuxt, MySQLなど7年 後: Rust, Next.js, Python, Micr

先日同僚と雑談的に話してたことを書いておく。ソフトウェア開発のバックログにおける話です。 「〜対応」とは 主に差し込みで入ったタスクやなにか早めに単一の解決したい事象のためのタスクに名付けられやすい名前。 あくまでも例としてだが 「マーケから割引データ表示依頼対応」 「監視アラート対応」 みたいなやつ。「〜対応」というのは日本語としてはかなり便利なので、とりあえずバックログに入れておきたいときに使いがち。 なぜ避けたいか 完了基準があいまいになる タスクを流していく際の問題。 バックログ上のタスクは完了基準を定めておかないと、作業スコープがどんどん広がったり、完了したかどうかを確認する人から見ると完了していないということが作業後にわかったりして不便。「〜対応」という名前をつけるタスクは、そもそもの作業スコープがはっきりしていないことが多く、結果として、作業を始める前に関係者との認識合わせが

『セキュア・バイ・デザイン 安全なソフトウェア設計』を読んだ。 ドメイン駆動設計(DDD)の方法論をベースに、ドメインに対する深い理解を獲得し、その理解を設計に反映させてコードを書くことで、セキュアなソフトウェアの開発にも寄与するという主張を中心に据えた本。 ここで、この本では「設計」という言葉を「ソフトウェア開発のプロセス全体における能動的な意思決定」という意味で使っている。 この本を読むことで、セキュアコーディングという側面も考慮したDDDの活用法、実際に新規／既存のアプリケーションの開発にそれらのテクニックを導入して設計を改善する方法を学ぶことができる。 設計を中心に据える理由 開発において、コーディングを通じたモジュールやAPIの設計などに力を入れることが多い一方で、セキュリティについては後回しになりがちだ。そこで、この本で扱う方法論を取り入れることで、設計を通じてセキュリティも自

GitHub ActionsでPRの”Files changed”タブと同じファイルの内容を取得する方法1。

さらに、こういうコードは「ここで例外処理しているから今回のも追加しておくか」という心理を誘発しやすい（割れ窓）。持続的なWebアプリケーション開発は割れ窓との戦いである。 テストの負担が増える コントローラ層を対象としてテストする場合、いちいち結合テスト（近年のRailsだとintegration testまたはrequest spec）を書く必要がある。プレーンなクラスやいわゆるモデルなどと比較するとテストの準備が大変になるし、テストの実行速度も落ちる。また、異常系はとくにだが、しばしばリクエストやコンテキストを含めた複雑な事前状態を作る必要があり、読みにくいテストになる。 テストがしづらいところにがんばってテストを書くことはできるが、それは問題解決になっていない。 原因 そもそもコントローラはHTTPのことをやるところだが、それ以上の責務を負わせているのが上述した問題の主な原因といえる

RBSの練習としてhatenablogというgemの型定義をRBSで書いた。 https://github.com/kymmt90/hatenablog/blob/v0.8.0/sig/hatenablog.rbs まだ該当gemのsigディレクトリに置いているだけだが、やったことを書いておく。 作業の流れ Ruby 3.0をインストールするなどしてrbs、typeprofは使える状態になっているとする。 TypeProfで型定義ファイルの雛形を生成する Steepを設定する rbs collectionでサードパーティgemの型定義を導入する steep checkを実行してエラーを確認する 型定義やコード本体を修正し、エラーを解消する CIでSteepを実行する ディレクトリ構造 次のようなディレクトリ構造とした。

今年から会社で導入されているOKRについて、結局どうやっていけばうまく運用できるのかわかっていなかったので、入門書を読んで調べていた。 OKRとは OKR - Wikipedia a goal-setting framework for defining and tracking objectives and their outcomes. 特徴的なのは、それなりに背伸びした成果1（ストレッチ・ゴール）を目標の達成度を測る尺度として利用するところ。 読んだ本 OKR（オーケーアール） Measure What Matters（メジャー・ホワット・マターズ） 1冊目の『OKR』はそれなりにレビューで評価が高く最初に読むにはよさそうだったので選んだ。2冊目の『Measure What Matters』は元IntelでシリコンバレーのGoogle含む各企業にOKRを広めたJohn Doerrの著

やりたいこと Railsエンジンのappディレクトリ配下に存在するクラス（モデルやコントローラ）のメソッドをオーバーライドしたい。 結論 RailsガイドのRailsエンジンについての記事に全部書いてある。Railsエンジンのapp配下のオーバーライドは、to_prepareを使って、親アプリの初期化が終わったあとに実行する。オーバーライドするクラスはclass_evalでリオープンする。

ここで開発体験（DX: developer experience）はおおむね次の記事で説明されている概念とする。digital transformationではない。 DX: Developer Experience （開発体験）は重要だ - Islands in the byte stream 2021年になり、担当するWebサービスのDXの改善を任務とするチームに所属しはじめた。こういうチームができるぐらいなので、開発体験を悪化させるという感覚を開発者に与える課題はいくつかわかっている。それらを一つ一つ解決していけば、改善業務をある程度は進められそうだと考えてはいた。一方で、あくまで各開発者の感覚に依存して課題を把握していることが多いので1どれぐらいよく／悪くなっているかはわかりにくく、改善がどの程度Webサービスのビジネスそのものに影響するのかというのもぼんやりとしていた。 こういう

RDBのインデックス作成の戦略や実行計画の読みかたにもう少し詳しくなりたいと思っていたので、この手の話題が体系的にまとめられている『SQLパフォーマンス詳解』を読んだ。今回は和訳版を公式サイトで購入したが、SQLのインデックスとそのチューニングについてのオンラインブックでも同じ内容が読める。 内容 200ページ程度と短くまとまった本であることからわかるように、RDBのインデックスとその効果的な使いかただけに焦点を当てて解説している。書籍で示されている目次とは異なるが、次のような内容にまとめられると思う: インデックスを実現するBツリーについて インデックスの種類（複合インデックス、式インデックス、部分インデックスなど）について （本文では主にOracleだが）実行計画の読み解きかたについて 実行計画をもとにインデックスとクエリをチューニングする方法について 第2章の「where句」の分量が

“Principled GraphQL”はApollo社が公開しているGraphQL開発のベストプラクティス集です。 背景として、近年のアプリケーション開発では「データグラフ」が重要になってきているとしています。GraphQLを通じて、ある企業のすべてのアプリのデータとサービスとを統合してデータグラフとして提供することで、クライアントとしてのアプリケーションから効率よく簡単にサービスを使うことができるようになります。もはやGraphQLはクエリ言語というより、クライアントとサービス間の接続を担う包括的なソリューションなので、いろいろと考えるべきことも多く、GraphQL開発の統合環境を提供していて経験豊富なApolloがベストプラクティスをまとめた、というところのようです。 実際のところ最近GraphQLを触っていないのですが、ざっくり読んでみました。 構成 ドキュメントのフォーマットは”

何をやったか 最近の仕事柄興味があったのと、WEB+DB PRESS Vol.114の特集2を読んだこともあって、理解を深めるためにWebAuthnでの公開鍵登録（今回はサインアップを兼ねる）、認証だけできる簡単なWebアプリを作りました。リポジトリのREADMEに様子のGIFアニメを貼っています。今回はChrome 80とTouch IDで試しています: Contribute to kymmt90/webauthn_app development by creating an account on GitHub. このボタンをクリックするとHerokuにデプロイできます。リポジトリのREADMEにも同じボタンを置いています: デプロイ後に環境変数 WEBAUTHN_ORIGIN に https://<Herokuアプリ名>.herokuapp.com を追加してください。 理解できた点

このたび、2018年12月22日に発売された『WEB+DB PRESS Vol.108』の特集1「効率急上昇！スキーマ駆動Web API開発」の企画と執筆に携わりました。id:june29さん、id:ackintoshさん両名との共著です。 Web APIの仕様を表現するフォーマット（スキーマ）を用いたWeb API開発について、基礎的なところから紹介しています。本号はこの特集の他にもPostgreSQLやZOZOのシステムリプレイスなど、非常に興味深い内容が盛りだくさんなので、ご興味のある方はぜひ手にとっていただければと思います。 以上、宣伝でした。 以下、裏話的なことを書きます。 なぜ書いたのか そもそも現在業務として携わっているWebサービスの開発でOpenAPI（いわゆるSwagger）を利用しています。ある程度わかっている人にOpenAPIについて知ってもらうにはWeb上にある次

Modular MonolithというアーキテクチャをRailsアプリケーションへ適用する記事を読みました。 One of the hardest things about building a startup is handling the rapid growth in team and technology. The best way to build software with… モノリスアーキテクチャとマイクロサービスアーキテクチャの中間に位置する、一つのモノリシックなアプリケーション内でドメインごとにモジュールに分解しつつ運用するためのアーキテクチャを、Railsでどのように実装するか、という内容です。 Modular Monolithとは 記事から引用します。 Rather than extracting microservices, we decided to first

Railsで/cableなどのエンドポイントにAction CableをマウントするとWebSocketサーバとして利用できます。wscatを使ってAction CableによるWebSocket APIと対話的に通信するために、送信するデータの形式などを調べました。 準備 wscat WebSocket cat. Contribute to websockets/wscat development by creating an account on GitHub.

『Working with Unix Processes』待望の完訳。並列処理やデーモン、プロセス生成、そしてシグナルといったUnixの基礎であるプロセスについてRubyで解説する、「今どきの」開発者に向けた新しいUnixプログラミングの手引きです。 どんな本か 主にRubyの Process モジュールを使いながらUnixプロセスについて知る本です。 Rubyでには Process モジュールを通じてUnixプロセスを操作することができます。つまり、プロセスに関するUnixのシステムコールをRubyから扱うことができます。この点で、Cから直接システムコールを発行するよりRubyプログラマにとっては読みやすいコードで、Unixプロセスについての解説を読むことができます。実際、Ruby製のWebアプリケーションでよく使われるResqueやUnicornも、Rubyでプロセスを操作しています。

APIドキュメントに書いたJSON Schemaと実際に実装したWeb APIのレスポンスJSONが一致するかバリデーションするためのCommitteeというgemがあります。また、このCommitteeをRailsプロジェクト中のテストから使うためのCommittee::Railsというgemがあります。 interagent/committee: A collection of Rack middleware to support JSON Schema. willnet/committee-rails: rails and committee are good friends CommitteeはAPIドキュメントの形式としてJSON Hyper SchemaとOpenAPI 2.0に対応しています。また、APIエンドポイントを叩いたときのレスポンスJSONがドキュメントで定義したJ

最近業務でも耳にすることが増えたGraphQLについて今すぐ話を聞きたい！と思ったので、現場でGraphQL使っているぜという皆さまにお声がけして話を聞くアンド話をする会を設けました。 当日は各位から、なんでGraphQLなの？とか、GraphQLこれで悩んでる！などのお話を聞く予定です。 予定が近いですが、各位ダッシュでかけつけてください！ 受付にて名札をご用意するので、その際に「GraphQLやってる」「やってない」「言語」などのプロフィールを示していただけるようにしようとおもいます。懇親会などでの話題のきっかけにご利用ください。 ## LT内容 タイトルは仮のものを含... 五反田のfreeeさんでGraphQLナイトが開催されたので参加してきました。会社のSlackの開発者チャンネルで@hsbtさんが貼ったリンクを見て開催に気づけたので、ありがたい限りでした。 また、LT枠が急遽空

graphql-rubyでは、RailsのAction Cableに乗ることでGraphQL Subscriptionsを実装できます。 GraphQL Subscriptionsとは GraphQL Subscriptionsは、あらかじめ特定のGraphQLクエリを購読しておき、サーバ側でイベントが起きるたびにその形式のデータを受信できる仕組みです。用途としてはプッシュ通知などを想定しているようです。 2018年4月の段階ではまだworking draftですが、FacebookによるGraphQL SubscriptionsのRFCがあります。ここではアーキテクチャだけが示されており、具体的な実装方法については言及していません。 GraphQL is a query language and execution engine tied to any backend service.

こういうのはどうかという最近の考えを書いておきます。とはいっても、だいたいはgraphql-rubyのドキュメントに書いてあります。Rails + graphql-ruby + RSpecが前提です。 各フィールドのテスト フィールドから正しく値を取得できるか、つまりRailsのモデルとgraphql-rubyとの連携が正しいかという点をテストします。次のようにスキーマのオブジェクトから型情報を取得して、resolveを実行します。

GMOペパボ Advent Calendar 2017の23日目の記事です。 今回はJavaScriptでGraphQLのサーバ／クライアントや関連ツールを提供しているApolloのツールセットでRailsプロジェクトでGraphQLのモックサーバを立ち上げるところまでを試してみます。 業務でRails製の（RESTishな）Web APIとVue.js製のSPAからなるアプリケーションを開発していて、スキーマファースト開発を取り入れています。また、GraphQLで通信するAPIを実験的に導入しはじめていますが、こちらは明示的な開発フローを決めず導入しようとしているため、なかなかサクサクと開発が進まないのが現状です。そこで、GraphQLでも先にインタフェースだけを決めてから、モックサーバを使ってフロントエンドとバックエンドで並行開発していけばよいのでは、という発想になります。 しかし、そ

あらかじめ書いたJSON Hyper Schema/OpenAPI 2.0のAPIドキュメントにおけるレスポンスのスキーマ定義をもとに、APIモードのRailsでHTTPリクエストを発行するテストを実行すると、自動でレスポンスのJSONをバリデーションしてくれるSchemaConformistというgemを作りました。 An automatic JSON response validator for testing in Rails - kymmt90/schema_conformist といっても、次の記事でやっていることをgem (Rails plugin) として切り出して、JSON Hyper Schemaにも対応させたあと、いくつか設定できるようにしただけのものです。 RSpecのrequest specでCommitteeを使ってレスポンスJSONを自動的にバリデーションする

2017-10-24（火）にペパボEC事業部において「EC事業部 TechMTG #4」という社内勉強会がありました。この機会に、昨今のWeb API開発事情について知ってもらおうと思い、最近はチームでスキーマファースト開発をやってみているという話をしました。 スライドにも書いていますが、主に次のようなことを話しました。 スキーマファースト開発の概要 どのようなツールをどう使うか サービス開発での実例 次のような質疑応答が（主にCTOとの間で）あった気がします。 スキーマ書くのがコストにならないか？ 他の部分で楽になるので、そこは歯を食いしばる。周辺ツールで楽にはなる 最近、インターネットでGraphQLとかいう最先端技術を見たがどうか？ 向き不向きがありそう。参照系はGraphQLが有効そう 実はGraphQLも徐々に使っているし、もっと広げていきたい こういう考えかたがあるということを

前提 まったく同じ手順でやるだけというのもなんなので、一度おなじ手順でやったあとに、次のような変更を加えてやってみました。 Rubyのバージョンを2.3.3から2.4.1にする Railsのバージョンを5.0.0.1から5.1.1にする PostgreSQLのかわりにMySQLを使う 以降の記述でとくに言及していないファイルや手順は”Quickstart: Compose and Rails”での説明とおなじことをやっています。 DockerとDocker Composeは次のバージョンを使います。 Docker 17.03.1-ce Docker Compose 1.11.2 作業 Dockerfile Railsの環境を含むイメージを作るためにDockerfileを書きます。