QAエンジニアから見た『データモデリングでドメインを駆動する』書評 - ブロッコリーのブログ
はじめに 本記事は、今年発売された書籍『データモデリングでドメインを駆動する――分散／疎結合な基幹系システムに向けて』を読んだ感想と、QAエンジニアである私*1が日々の業務で役立ちそう（既に役立った）部分を紹介します。今のところ、本書籍は2024年のベストバイな気がします。 gihyo.jp 本記事で一番伝えたいこと データモデリングについての考えが深まるぞ 開発者が読むともっと役立てることができると思うぞ QAエンジニアである私が読んでも役立つぞ 読み始めてすぐに「良い買い物だった」と思って思わずポストしている様子 目次 はじめに 本記事で一番伝えたいこと 目次 本書籍で良かったこと：データモデリングをするにあたっての整理と用語の提案がすごい SoAとSoMという整理 「残」という概念 データベース設計とは違う「データモデリング」という考え方 QAエンジニアとして、業務に役立てそうなこと
デザインにセンスは必要ない、大切なのは「情報を整理」する力 Udemyの人気講師が教える、UI/UXデザインの基礎
「デザイナーだけがデザインをする時代は古い」「デザインにセンスはない」と語るのは、Udemyの「UI/UXの改善を進めるための基礎講座」などで人気を誇る、UI/UXデザイナーの濱野将氏。生成AI時代において、デザインをビジネスをつなげるためのポイントや、UI/UXの基礎を解説します。 UI/UXデザイナーが教えるデザインの基本 濱野将氏：それでは、僕からは「ビジネスを実現する『デザイン』の基本」をお話しさせていただきます。よろしくお願いします。 今日のアジェンダはこんな感じです。「デザインの必要性」「デザイナーだけがデザインする時代はもう古い」「UI/UXについて」。今回はAIがテーマなので「AIを使ったプロジェクトの進め方」も少し紹介させていただきたいなと思っております。 簡単に自己紹介をさせてください。株式会社IMAKE代表の濱野と申します。職業はUI/UXデザイナーで、講師もさせてい
staticメソッドの使いみちがイマイチわからないのでまとめてみた - Qiita
※ 本記事は未完成 です。 まだ自分の中に落とし込めていないのですが、他の人の役に立つこともあるかと思い、投稿します。 誤っている箇所がありましたら、遠慮なくマサカリを投げてください。 「staticメソッド」とは？ 直訳すると「静的メソッド」です。「クラスメソッド」ともいいます。 対義語は「インスタンスメソッド」です。 staticメソッドのメリット ①インスタンスを生成せずに呼び出せる インスタンスを生成せずに呼び出せるのが一番のメリットです。インスタンス生成にかかるオーバーヘッドがなくなるので、 インスタンス生成に時間がかかるクラスに有効 です。 そのため、頻繁に呼び出されるユーティリティメソッドはよくstaticメソッドとして実装されます。 また、自クラスのファクトリメソッドのように、 インスタンスの生成前に実行すべきメソッド はstaticにするしかありません。 ②インスタンスご
継承はなんでダメ？ - まめめも
「オブジェクト指向の継承を使うな」という主張が広まっているようです。なんでダメになったんでしょうか。 インターネットで見かけた「継承はダメ」という主張をいくつか眺めて、友人と議論しつつ、考えてみました。 「コードが読みにくくなる」 継承があると、メソッド呼び出しが実際にどのメソッド定義を呼び出すのか字面でわからない。 デバッガを使って、親クラスのメソッドに飛んだり、子クラスに飛んだりするのを追いかけないと行けない。 つらい。という主張。 めっちゃわかる。わかるんですが、これは「高度に共通化されたコードは読みにくい」という一般的な側面がかなり大きいような。 たとえば継承の代わりに高階関数を使うと、関数呼び出しがどのクロージャに飛ぶか字面でわからなくなる。 ひどいとコールバック地獄になって何が何やらになります。 継承がことさらにまずい理由を想像すると、すべてのメソッド呼び出しがポリモーフィック
やさしいクリーンアーキテクチャ
SREホールディングス株式会社の松本です。 プロダクトはリリースしてからが始まりで開発し続けることが当たり前の時代、ソフトウェアは変更や拡張に強く設計しなければなりません。クリーンアーキテクチャはそんな設計を実現する方法の1つですが、名前は聞いたことはあるけど実践したことはない、なんだか複雑で難しそう、という印象を持っている人が多いのではないでしょうか。 クリーンアーキテクチャを詳細に説明している記事は数多くありますので、本記事ではクリーンアーキテクチャを触ったことがない方に良さが伝わるように、やさしく噛み砕いて説明してみようと思います。 対象読者 クリーンアーキテクチャをこれから学びたい方 クリーンアーキテクチャとは 機能を実現しているコアな部分をフレームワークやDBなどに依存しない状態（関心事の分離）にすることで、他が変わってもコアな部分への影響をなくし、変更や拡張に強くすることができ
GoとEnumについて
これはGo Advent Calendar 2022の21日目の記事です。 たびたび「Enumイディオム」がGoに欲しいという要望が話題になるのでその話をまとめてみる。 議論の中心はここが詳しい。 「Enumイディオム」が解決する課題 文字列表現がつく 反復処理ができる 偽の列挙値を導入することを防ぐ 名前空間を分離する などがあるらしい。上にあげた課題がGo標準では解決しにくいという理由がよく上がるのですが、Enumイディオムの追加方法は何パターンかあります。 Enum型プリミティブを言語仕様に加える ライブラリとしてEnumオブジェクト実装を提供する 現状の推奨「iotaによる手法＋go-generate」による方法 「Enum型プリミティブを言語仕様に加える」について 言語実装のアップデートが必要 reflectパッケージのアップデートが必要 後方互換のためiota式とEnum式の２
TypeScriptで学ぶ！SOLID原則
はじめに 皆さんこんにちは、株式会社エムアイ・ラボのエンジニアです！ 今回はソフトウェア設計のSOLID原則について学習したので、弊社のメインの開発言語であるTypeScriptのサンプルコードを使って共有できればと思います。 SOLID原則は、オブジェクト思考プログラミングにおいて、ソフトウェアがメンテナンスしやすく、拡張や変更に強いソフトウェア設計を行うための原則です。 SOLID原則にはSOLIDの頭文字をそれぞれとった、５つの原則があります。 単一責任の原則（Single Responsibility Principle） 単一責任の原則とは、クラスが一つの機能や責任を持つべきで、クラスが変更される理由は一つであるべきというです。 クラスが一つの機能や責任のみを持つようにすることにより、コードは再利用可能でテストが容易になります。 単一責任の原則を遵守している例 以下のBirdクラ
クリーンアーキテクチャの功罪
クリーンアーキテクチャというと設計における銀の弾丸のように扱われていて、クリーンアーキテクチャを導入するという記事をよく見ます。しかし自分の経験だとクリーンアーキテクチャで書かれているのにもかかわらず開発効率が落ちているという事が多く、いつでも使っておけばいいというものではないと思っています。 最近目にしたクリーンアーキテクチャに対する批判 本筋ではないので詳細は省きますが、あるとき[1][2]にUncle Bobの著書であるCleanシリーズへの批判をXで見ました。 ここで一番載せたかったものが今見つけられないのですが、以下のようなポストがありました。 書籍クリーンアーキテクチャに書いてある内容を抜きにして起こった現象だけを見るとマイナスの方が多い このポストが自分の感じていることを端的に表現できているように感じました。書籍クリーンアーキテクチャの内容を悪いと思いませんが、その影響により
Golangでいい設計を実践するための6つのツール
概要 Golangを書くにあたり、いい設計のコードを書くための手助けとなるツールを調べたのでまとめます。 想定読者 Golangの使い方をある程度わかっている(チュートリアルはやった) いい設計をするための具体的なノウハウに興味がある 記事を書いたきっかけ 引用: https://www.amazon.co.jp/dp/B09Y1MWK9N 最近設計に関して勉強するために「良いコード／悪いコードで学ぶ設計入門」を読みました。 本の中では マジックナンバーを使うな 一つのメソッドの中で多くのことをやりすぎるな などの言われてみると基本的な注意点が書いてありました。 一方で以下のように、確かにそうなんだけど実際は守れていない注意点にも書かれていました。 単一責任の原則を守ってクラス設計しよう 高凝集なクラスを作ろう 本を読んでわかった気になって今までと同じように悪い設計のコードを書くままではい
ADR を1年間書いてみた感想 - 一休.com Developers Blog
宿泊開発チームでエンジニアをしている @kosuke1012 です。チームで ADR を書き始めて1年くらい経ったので、その感想を書いてみたいと思います。 この記事は 一休.comのカレンダー | Advent Calendar 2023 - Qiita の13日目の記事です。 ADRとは アーキテクチャ・ディシジョン・レコードの略で、アーキテクチャに関する意思決定を軽量なテキストドキュメントで記録していくものです。 出典はこちらで、 Documenting Architecture Decisions わかりやすい和訳は以下の記事が、 アーキテクチャ決定レコードの概要 | Cloud アーキテクチャ センター | Google Cloud アーキテクチャ・デシジョン・レコードの勧め | 豆蔵デベロッパーサイト アーキテクチャの「なぜ？」を記録する！ADRってなんぞや？ #設計 -
リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog
どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①～④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図：レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか？」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私
メールアドレスをキーにしてID連携を行う設計の危うさ｜ritou
ritouです。このしずかなインターネットにおける初投稿です。 おそらく、このしずかなインターネットのID連携では次のような設計になっていま「した」。問い合わせをさせていただき、対応いただきました。 これまでもQiitaなどで同様の実装例が紹介されていた際にはコメントさせていただいていたものですので、アンチパターンの紹介記事として読んでいただければと思います。 「Googleアカウントでログイン」ではじめると、ユーザーが作成され、Googleから受け取ったメールアドレス([email protected])が設定される 次回から「Googleアカウントでログイン」をすると、Googleから受け取ったメールアドレスでユーザーを参照 試しに、次のような流れで動作を確認してみます。 「Googleアカウントでログイン」でアカウント作成([email protected]) 「メールアドレス変更」
クソコードはエンジニアを貧乏にする｜ミノ駆動
何が書かれているのか理解が難しく、イレギュラーな方法で裏技的に実装され、ちょっと触ればバグと化す、クソコード。 プログラマ諸氏なら誰しもが見たことのあるクソ忌々しいアイツだ。 クソコードはエンジニアを貧乏にしてしまう。 なぜ貧乏になってしまうのか、その理由について、怒りをぶつけながら以下に書き連ねる。 本記事の構成■理由①：プロダクトが利益を出せなくなる ■理由②：エンジニアが資産蓄積できなくなる （←ココ重要） ■クソコードを滅ぼし豊かになろう ■ソフトウェア開発に携わる方々へ 理由①：プロダクトが利益を出せなくなるまずこちらの理由は簡単だ。３項目に分けて説明する。 【クソコードは読みにくい】 どんなロジックなのか理解が容易ではない。ロジックそのものは簡単であっても、tmpと名付けられた正体不明な変数、非推奨なAPIによる意図不明な実装などにより、読み解くのを難しくさせてしまう。 「クソ
設計を議論する会を作ったらプロダクトの設計品質は上がりチーム全体の設計力が上がりました
こんにちは。Magic Momentの髙橋です。 現在Magic Momentではチーム全体でプロダクト品質の向上と設計力の向上に積極的に取り組んでいます。 もちろんMagic Momentのエンジニアは技術力向上に貪欲で、自分たちで勉強会をしたり新しい技術の使い所について議論をすることが本当に大好きだと思います。しかし個人の日々の勉強ではなかなか得られない経験というのが「顧客向けに作るサービスの設計」だと思います。 いくら自社サービスを作っているMagic Momentであっても、すべてのエンジニアが等しくすべての設計の経験ができるとは限りません。そこで少しでも設計の経験を積んでもらい、それがプロダクトの品質向上にも貢献するような取組をはじめました。 それが「Product Development会」という設計を議論する会議体を作ったことです！ ここからは「Product Develop
「ファイル名に”yyyymmdd_hhmmss”がついてますが同タイミングで動かしたらどうなりますか」とレビューされて震えた話
リンク 朝日新聞デジタル マイナカードで誤交付、自治体・富士通に報告求める 個人情報保護委：朝日新聞デジタル マイナンバーカードを使った証明書のコンビニ交付サービスで、他人の住民票などが誤って交付された問題をめぐり、個人情報保護委員会は11日、関係自治体やシステムを納入した富士通Japanに対して、報告や資… 9 ゆーしゃん.py(bot運用中) @Mr_mura_ura 客「ファイル名に「yyyymmdd_hhmmss」がついてますが、完全に同タイミングで動かしたらどうなります？」 私「こんな小規模な社内システムでそんな事無いと思いますが…エラー落ちしますね…」 客「まぁ99%無いと思いますが、念のためにね」 というレビューをつい最近受けた私、震えてます← 2023-05-11 00:02:16
モダンなテストレベル設計（ユニットテスト～システムテスト等をどう設計するか）の原則 - 千里霧中
プロジェクト全体のテストを組み立てる際に重要な課題になるのが、テストレベル設計です。テストレベル設計は、ユニットテスト、結合テスト、システムテストといったテストレベルを、どのような責務・段取りで行うか分析・設計する活動です。 このテストレベル設計ですが、ここ10年程度の間に望ましいアプローチが変わってきたと感じています。今回はこの変化と、変化後のモダンなテストレベル設計の原則について、考えていることを書き出したいと思います。 旧来のテストレベル設計のアプローチ 旧来、このテストレベル設計では、Vモデルをベースしたアプローチや、自工程完結・品質積み上げをベースとしたアプローチがよく見られました。 このうち一つ目のVモデルをベースとしたアプローチは、要求定義から設計までの上流工程への対応を観点に、テストレベルを設計するものです。 （Vモデルが必須と明言しているわけではなく、極端な例ですが）例え
あなたの遅延はどこから？ SQLから！ 〜患部に止まってすぐ効くSQLレビューチェックリスト 年初め特大サービス号〜 - ANDPAD Tech Blog
あけましておめでとうございます！ 今年は異世界放浪メシのアニメが放送されるらしいので楽しみなバックエンドの原田 (tomtwinkle)です。 内部で運用しているSQLレビューチェックリストの一部を抽出し思いつきで追記して行った結果、結構な分量になってしまいました。 暇な時でも流し読みして頂けるとありがたいです。 Motivation SQLレビュー観点 大きくSQLが変更される修正の際にはEXPLAINをレビュー内容に加える 検索のキーにINDEXを使用しているか SQL発行回数がN+1(1+N)の構造になっていないか サブクエリを利用したSQLはパフォーマンス要チェック Viewの利用は基本的に禁止 CROSS JOINは禁止 WHERE句で十分に絞った検索をしているか 必要なcolumnだけSELECTしているか レコード数だけ必要な場合にCOUNT用のSQLを発行しているか 集計関
OAuth 2.0 で有効期限がない(ずっと先の) Refresh Token の扱いについて
ritouです。 今日は OAuth 2.0 の話題で少し頭の体操をしましょう。 いきなりまとめ 今回は OAuth 2.0 の Refresh Token を用いて非同期の処理を実装するケースはよくある "Refresh Tokenの有効期限がない=無効化されない" という前提の設計を見かけるが、よくないと思う 無限に有効な Refresh Token が必要になりそうな機能は Client Credentials Grant に持っていくのも一つの手では みたいな話をします。 OAuth 2.0 の Refresh Token 仕様の参照とかはめんどいのでざっくりまとめると Access Token を更新するために利用されるトークン Resource Owner が介入しない非同期なタイミングでも利用される場合がある 有効期限切れや AuthZ Server / Resource O
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
キャッシュと向き合う、キャッシュと共に生きる / cache pattern
失敗例から学ぶSOLID原則
