「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTful API」は「当該記事」と表現します。 観点 当該記事では「○○とした方がよい」との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図

この記事では、「本質的複雑性」と「偶有的複雑性」に向き合うことをテーマにした記事をまとめてお届けします。 「本質的複雑性」に向き合うための記事まとめ 経営の本質的課題に向き合い続けるログラスのプロダクト開発 「本質的な価値を生み出す」ための取り組みシリーズ 「スクラムの三本柱（透明性・検査・適応）」を高めるための取り組みシリーズ 「スクラムの成果を最大化」するための取り組みシリーズ 「偶有的複雑性」に向き合うための記事まとめ 偶有的複雑性と向き合うためのログラスのEnabling & Platform戦略 偶有的複雑性と向き合うための「基盤を更新し続ける」シリーズ 偶有的複雑性と向き合うための「型の堅牢性」にまつわるシリーズ 「ツリー構造と集計」にまつわる偶有的複雑性シリーズ 偶有的複雑性に向き合うための「テスト」シリーズ さいごに 「本質的複雑性」に向き合うための記事まとめ 経営の本質的

はじめに コンテナ技術の進展に伴って、ビジネス環境の変化に迅速に対応できるマイクロサービスに関心が集まっています。最近では、マイクロサービスを分割する方法の一つとしてドメイン駆動設計が注目されています。ドメイン駆動設計では、業務に精通した方々や技術者が、モデリングなどいろいろな技法や専門用語を使い、それらを理解した上で設計を進めていきます。様々なステークホルダーとチームを組んで一緒に取り組むにしても、直観的にはとてもわかりづらいと感じています。そこで、いろいろと記事を調べてみたり、身近な技術者と意見交換をしたところ、イベントストーミングという手法がありました。イベントストーミングに関する記事は他の記事に比べあまり多くはないので、この場で共有しておきたいと思い掲載することにしました。これからドメイン駆動設計をはじめるという方や、既に取り組んでいるけれど進め方に悩んでいる方など、参考になれば幸

質とスピード（2022春版、質疑応答用資料付き）

はじめに 「理解容易性」は「保守性」の観点の1つとして重視され、多くの原則や技法が紹介されているが、断片的かつ多様であり、全体像を理解することは難しい。 抽象度は高いが、体系的に観点を整理する事で、その理解の助けとなれば幸いである。 定義 「理解容易性」を簡単に言えば、「理解のしやすさ」であるが、その意味から掘り下げると、「思考する量」と言い換えることができる。 本記事では理解容易性を「思考量の少なさ」と定義し、7つの観点に整理した。 先に要約およびチェックリストを記載し、概略を記載した。 後に詳細で理解のため、各観点毎の説明と個別の原則や技法へのリンクを記載した。 要約 7つの観点の要約を先に示す。 （変数や関数の）名称は分かりやすくする （変数や関数の）役割は１つにする （変数や関数の）参照は狭くする （変数や関数の）状態は変えられなくする （関数やクラスの）面積は小さくする （関数や

はじめに 今回の記事では、学習や実務でGraphQLを活用する人を対象に、GraphQLの全体像を把握するためのチュートリアル記事になる。本記事の対象読者は以下の通りである。 GraphQLの全体像を把握したい人 公式ドキュメントの理解で苦しんでいる人 GraphQLとは GraphQLはWeb APIを開発するためのクエリ言語である。REST APIの問題を解決するために、Facebook(Meta)によって開発された。Web APIの開発において、REST APIと比較して柔軟かつ効率的なアプローチを提供できる。さらに、GraphQLではクライアントが必要なデータの構造を定義することができ、サーバから定義したものと同じ構造のデータが返される。 詳細は後述するが、GraphQL最大の特徴は必要以上に大きなデータが返されることを防ぐことにある。これによって、GraphQLは必要最低限のリク

AWS Dev Day 2023 Tokyo GS-1-2 | 6月 22 日（木）10:55 - 11:45

Value Objectとは何であるか? マーチン・ファウラーのPatterns of Enterprise Application Architecture(PofEAA)やエヴァンス・エリックのDomain Driven Design: Tackling Complexity in the Heart of Software(DDD)が原典であるが、PofEAAではこう切り出している。 When programming, I often find it's useful to represent things as a compound. プログラミング時は物をcompound(合成物)として表現すると便利なことがしばしばある。 例えば2次元空間上での座標のように複数のメンバ(属性)を持つ物は便利である、と。しかしそれらを比較する方法は一意ではない、そこで Objects that a

ミノ駆動さんに「なぜ負債解消にDDD？」と聞いたら、ソフトウェア開発の本質に気づかされた 2024年1月15日 株式会社スタメン ミノ駆動（仙塲大也） 電子機器メーカーや大手精密機器メーカー、クラウドワークスを経て、2021年4月にREADYFORに入社。アーキテクチャの変更容易性や機能性を促進する設計構造を目指し、リファクタリングやドメインモデリングを主軸としたシステム設計に従事する。現在は、組織改善のためのエンゲージメントプラットフォーム「TUNAG」を擁するスタメンに在籍。ITエンジニア本大賞2023技術書部門大賞を受賞した『良いコード/悪いコードで学ぶ設計入門』著者としても知られる。 X（@MinoDriven） note Qiita 株式会社スタメン・テックブログでの執筆記事 ドメイン駆動設計（以下、DDD）に注目が集まりだしてしばらく経ちますが、いまだに捉えづらさを感じている人

1. これはなに こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 この記事は、今後スタメンにおいてサービスの技術的負債を解消する設計戦略についてまとめたものです。 2. 背景、課題 株式会社スタメンは2016年創業。主要サービスであるTUNAG（ツナグ）は、企業のエンゲージメントの構築、つまりお互いを知って理解し、信頼し合う組織を作るための社内コミュニケーションを活性化させるプロダクトです。TUNAGのバックエンドはRuby on Railsで開発され、ローンチから7年をむかえつつあります。 これまでTUNAGは、プロダクトをいかに伸ばすかに注力してきた一方、内部品質や開発効率など「開発者体験」に関する課題が後手に回っていました。本来プロダクトチームはユーザーにとっての本質的な価値にのみフォーカスできる状況が理想ですし、開発者体験が

どのように何をロギングするかを知ることは、ソフトウェアエンジニアが解決すべき最高に難しいことの一つだ。アプリケーションのログを拡張する手助けとなるのがこの「十戒」だ。 新年の私のブログにようこそ。監視とログのモニタリングについてのParisのdevopsメーリングリストでのスレッドに返信を書いた後、長らく心に留めていたブログ記事を思い出した。 このブログ記事は、私のOpsとしての顔をもって、主に開発者向けに書いた。 どのように何をロギングするかを知ることは、ソフトウェアエンジニアが解決すべき最高に難しいことの一つだ。多くの場合、これは予言をするのと同じようなことだからだ。トラブルシューティング中にどんな情報が必要かを知るのはとても難しい。それが、Opsエンジニアの大きな助けとなるよう、あなたのアプリケーションのログを拡張する手助けとなるこの「十戒」を望んだ理由だ。 1. 自分でログを書くべ

はじめに 皆さんのログに対する理解はどんなものでしょうか？仕組みから設計方法まで完璧に理解しているエンジニアもいれば、なんとなく使用しているエンジニアも多いことでしょう。 ログとは、システムに着いてエラーや障害の発生、利用者による操作や設定の変更、外部との通信などを時系列に記録したものです。ログに関する理解を深めることで、複雑なシステム開発や運用が可能となります。また、AWS、Azure、GCPなどのクラウドサービスを利用している場合はシステムの開発が可能になるだけでなく、経費削減に繋がる可能性も考えられます。 本記事では、ログの基本を押さえるためにその設計方法について解説します。少しでも自信がない方は、ご一読ください。 ログを出力する理由は？ ログの基本や、ログの設計について解説する前にそもそもログを出力する理由を押さえましょう。大きく4つの理由が考えられます。 ・問題が発生した時に調査

こんにちは、NE会社で働いておりますきんじょう(@o0h_)がお送りします。 弊社ではPHPを用いてアプリケーション開発を行っています(Ruby, Go, Javaも領域によっては利用しております) さて、つい先日のことですが、社内にいるメンバーから「デザインパターンについて、勉強してみてるんだけど・・・」「ちょっとついていくのが難しくて」「どうしたらいいですかね？それとも、先にやっておくべきことが他にありますか？」なんて雑談をしました。 なるほど、コレは頻出質問になりそうだな・・・という気持ちにもなったので、今回はこの場を借りて「デザインパターン[1]、その前に〜個人的に思ったことをツラツラと〜」でお届けしていきたいと思います。 「デザインパターンを(から)勉強してみる」ことの、オススメ/オススメナイ いちおう、今回は「リーダブルコードくらいは読んでいる」「デザインパターンの勉強をしてい

「2018/11/8 設計Night2018 powered by Classi」で発表した資料です 当日の資料のページ数が多すぎた(140ページ）ので、2/3くらいにまとめました

2023/02/10、デブサミ2023の登壇資料です。 『目的と抽象化の関係性から分かる、システムの設計精度を高める考え方』 https://event.shoeisha.jp/devsumi/20230209/session/4182/

オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだの Hatena の件。基本的には同意。ただちょっと切り口が違うので自分の意見を言っておく。ただ、このテーマで何度か書こうとして失敗していて、今回も成功しているとはいえない。 宣言的プログラミングの時代 現代の主流は「宣言的プログラミング」であると思っている。これはリソースの宣言と、その状態遷移の手続きや振る舞いの付与が中心にある。 宣言型プログラミング - Wikipedia その代表的な例がフロントエンドの React と、バックエンドの k8s で、どちらも時系列に基づいた状態の宣言と、フレームワーク側による状態遷移処理、 Reconcillation(調停) が基礎にある。 フロントエンドとバックエンドという両極端な世界で、この変化が起きたのがこの時代を反映したものであると思う。 例えば、jQuer

プログラムを使ってある仕様を実現するとき、多くの場合、そこに"唯一の答"はありません。 同じ仕様、機能を実現するコードにも多様性があります。 プログラミングにおいてしばしば問題になるのが、「その様々なコードのうち、どのコードを選んで実装するか？」ということです。 とりあえず機能が実現されるという点においてはどのコードを選んでも同じであっても、その後の保守性や拡張性などにおいて、自分がどんなコードを選んで書くか という事は重要です。 今の時点では正しく動作しているコードであっても、可読性や拡張性などの観点でクソコード、悪いコードなどと揶揄される場面がしばしば見受けられます。クソコードというのはかなり強い言葉で、あまり良い言葉だとは思わないですが、その言葉を発する人からすると、どうしてもそう言いたくなるような問題があるのでしょう。 ところで、同じ労力で悪いコードを避けて実装できるのであれば、そ

さまざまなテストレベルとロールで活躍されている方々がテストコードをリーダブルにする方法について語り、それぞれの違いや共通点について議論する、「リーダブルなテストコードについて考えよう」。ここで株式会社ソニックガーデンの伊藤氏が登壇。リーダブルなテストコードとは何か、リーダブルなテストコードを書くための具体的な意識を紹介します。 伊藤氏の自己紹介 伊藤淳一氏：リーダブルコードという発表です。いきなり余談から入りますが、今日仕事をしていたらテストコードに助けられました。 仕様変更がいつ入ったのかを調べなきゃいけなくなってコミットを追いかけていったら、過去の僕がすごくわかりやすいテストコードを書いていて、仕様Aを仕様Bに変えることがdiffを見れば一目瞭然というようなものを作っていました。リーダブルなテストコードを書いてて良かったと思った日がこの勉強会の開催日で、ナイスタイミングだと思いました。

Repositoryによる抽象化の理想と現実/Ideal and reality of abstraction by Repository