外部キー制約が一切ないと何に困るのか？
こんにちは。株式会社プラハCEOの松原です 注目を集めつつあるMySQLプラットフォームのPlanetScaleですが、外部キー制約が効かないという一見致命的に見える仕様について調べていたところ、こちらのDiscussionで興味深い回答が開発者から寄せられていたので日本語でまとめ直してみようと思いました。 外部キー制約がなくてもそれほど困らない理由 今回の話はParentテーブル(id)とChildテーブル(id,parent_id)を前提に考えていきます そもそも外部キー制約は何に役立つのか 今回のDiscussionでは質問者から「外部キー制約がないとこういう時に困るよ！」と質問が寄せられています： 外部キー制約がないと参照先のデータが存在していることを保証できない！ 外部キー制約がないとデータの重複を回避できない！ それぞれの質問に対して回答者の回答は以下の通りです： 外部制約がな
React ステート管理 比較考察 - uhyo/blog
こんにちは。Reactの話題の中でもかなりの部分を占めるのがステート管理、さらに言えば各種のステート管理ライブラリです。今さらながら、Reactにおけるステート管理の手法やいくつかのステート管理ライブラリを比較考察して記事にまとめました。 useState + バケツリレーReactにおける基本的なステート管理はuseStateです。ひとつのコンポーネント内で完結するようなステートならばuseStateは非常に適しており、他の選択肢はほぼ無いと言っても構わないでしょう。 ステートをアプリケーションの広範囲で使いたい場合が問題です。次の画像に例示されるように、分岐したコンポーネントツリーの末端のコンポーネント（使用者）で同じステートを参照したい場合を考えます。 useStateと組み合わせる場合、もっとも原始的な方法はpropsのバケツリレーによるものです。propsは親コンポーネントから子
そのテスト、正しく設計できていますか？ テスト技法ツール「GIHOZ」を活用したAPIテスト設計【デブサミ2022】
マイクロサービスアーキテクチャの普及や、Webブラウザのほかモバイルやスマートスピーカーなどクライアントチャネルの多様化もあって、Web APIを前提としたシステムが増加している。当然、Web APIのテストも現場では大きな課題になってくるが、株式会社ベリサーブの朱峰錦司氏は「なぜ、そのテストを実行するのか、全員で共有できているチームはどれほどあるだろうか」と疑問を抱く。そして正しいテスト技法を少し覚えるだけでも、個々のテストに対する理解はぐっと深まるという。テスト技法の初歩を、実演も交えて解説してくれた。 株式会社ベリサーブ 研究企画開発部 サービス開発課 課長 朱峰錦司氏 テスト作りの過程を言語化するツールがテスト技法 朱峰氏は「今はソフトウェアプロダクトを1回作って終わりという時代ではない。プロダクトをどんどん進化、変化させていく時代だ」と指摘し、この状況に対応するために書いたテスト
大規模システムにおけるディレクトリ構成をRDBのカーディナリティを参考に考える - ぷらすのブログ
モノリシックなプロジェクトにおいて、トップレベルのディレクトリ構成が異なる 2 つのディレクトリ構成を考え、それらの違いは何で、どちらが優れているか？という問いについて考えた。そして、「複雑な概念をトップレベルのディレクトリ構成にした方が良いのでは？」という結論に落ち着いた話をする。 はじまり ちょっとしたシナリオを想像してみよう。 プロジェクト立ち上げ期 「最近のトレンドはレイヤードアーキテクチャだ！」 そう言って、プロジェクトはスタートした。 . ├── application │ ├── xxx_usecase.go │ ├── xxx_repository.go │ ├── yyy_usecase.go │ └── yyy_repository.go ├── domain │ ├── xxx.go │ └── yyy.go ├── infrastructure │ └── xxx_
明日から使えるCSS設計【PDFLOCSS】
CSS設計で本当に難しいのは「ルールを理解すること」ではなく「ルール通りに自分でコードを書くこと」だと思います。 実際にコードを書いていると「あれ、ここってどうすればいいんだろう？」「こういう場合はどうすべき？」といったことが頻発し、結局よくわからないまま勘でゴリ押すということがよくあります。 本書はそんな人へ向けて、FLOCSSをベースにしつつオリジナル要素を加えてより体系的にまとめた設計「PDFLOCSS（ピーディーフロックス、Page Divided FLOCSS）」を紹介します。 「CSS設計のルールはなんとなくわかるけど、いざ自分でコードを書こうとすると手が止まってしまう」という人に読んでもらいたい一冊です。 （追記：おかげさまでCSS設計のドキュメントとして採用している制作会社様も増えているみたいです！ありがとうございます🙏）
ソフトウェアアーキテクチャの基礎
ソフトウェアアーキテクチャとは、ソフトウェアシステムの成功に欠かせない重要な土台です。そのためソフトウェア開発者には、効果的なアーキテクチャを実現するスキルが求められます。本書は、そうした効果的なアーキテクチャを設計、構築、維持するアーキテクトになるために必要なスキルや知識を、現代的な視点から整理して包括的に解説する書籍です。 ソフトウェアアーキテクチャの定義から、アーキテクトの役割、モジュールや結合、アーキテクチャスタイルといったアーキテクチャ設計の基礎、チームやステークホルダーと効果的にコラボレーションしていくために必要なソフトスキルまで、さまざまなトピックについて実践的な例とともに説明します。 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下のリストに記載の年月は、正誤表を作成し、増刷書籍を印刷した月です。お手持ちの書籍では、すでに修正
GitHub - mitsuruog/clean-code-javascript: :bathtub: Clean Code concepts adapted for JavaScript
Software engineering principles, from Robert C. Martin's book Clean Code, adapted for JavaScript. This is not a style guide. It's a guide to producing readable, reusable, and refactorable software in JavaScript. Robert C. Martinの本Clean Code、ソフトウェアエンジニアリングの原則をJavaScriptに適用させたもの。 これはスタイルガイドではありません。JavaScriptで可読性が良く、再利用でき、リファクタリング可能なソフトウェアを提供するためのガイドです。 Not every principle herein has to be strictly f
Excel設計書を抹殺したくて4年前にWiki設計書を導入したら、意外とちゃんと開発回ってた話。 - Qiita
初めましてこんにちは。 最近コードレビューの記事書いたら、Excelベースだったことを理由に Qiitaコメントとはてブで徹底的に燃やされたおじさんです。 いやね、僕だって使いたくて使ってるわけではなくてね、 できることなら使いたくないんですよ。 というわけで名誉挽回のために脱Excelできた話、 それも日本の三大悪三大風習に数えられるExcel設計書を抹殺した話を書きます。 (2/25修正：悪は言いすぎました。訂正します。） Growi 最高。 またの名をExcel方眼紙。 エクセルのセルの縦横を同じくらいの大きさに調整し方眼紙のようにして、 そこに設計書として文字と図と表を記載する方式。 メリット 一つのファイルに文字と図と表がまとめて記載できる テキストでは文字は書けても図と表が書けない Wordでは、文字と図表エリアとを2列表示するのが難しい できなくはないが面倒くさい UMLモデ
状態、結合、複雑性、コード量の順に最適化する - valid,invalid
There’s No Such Thing as Clean CodeのHacker Newsコメント経由でコードやシステム設計・最適化についての良いコメントを見つけた。どうやらHacker Newsで何度も引用されているらしいが日本語で言及された記事が見つからなかったので取り上げてみる。 コメントは2016年のSandi MetzのThe Wrong Abstractionに関するもので、発言者のcurun1rいわく「私は設計の優先順位をこの順序で学習することで、優れた開発者になれた」。*1 4つの基準と優先順位のガイドライン 状態 > 結合 > 複雑性 > コード量 私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。 コードがよりステートレスになるなら、結合を増やすこともいとわない 結
ドメイン駆動設計に関する何か - 日々常々
2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも？くらいの気持ちで読んでいただけると幸いです。 何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。 DDD、日本語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。 これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメ
Gist - Fertile Forest Model - The Cusp of Helix
Fertile Forest Model [Gist] C.1: Hierarchical Data in a RDB We know that it is difficult to store hierarchical data in a RDB. The basic knowledge in order to know the difficulties, are summarized in the following link. Please read at first, because it contains important information in order to understand the fifth model. C.2: Conventional Models DB engineers around the world had been studying the
なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】 - Qiita
なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】UXUIDesignUIデザイン画面設計 1.はじめに エンジニアの私がデザインを本気で勉強した結果、デザイナーとエンジニアはそもそも思考が大きく違っているということがわかりました。 今回は「それ」をデザインに苦手意識のあるエンジニア方にも理解してもらえたらと思い、わかりやすくまとめてみました。 2.アプリの画面デザインを考えてみよう まず、こんなアプリを考えてみてください。 フィットネストレーナーが使うアプリ トレーニングルームでお客様とお話しながら使う 端末はタブレット そして 会員の個人情報確認 前回までのトレーニング状況の確認 次回の予約受付 といったことをします。 使える情報としては、こんな感じです。 あなたならどう画面デザインをするか、もしお時間があったら考えてみてください。
設計を歪める認知バイアス - Qiita
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、5日目の記事です。 これはなに？ ソフトウェア開発において、設計をないがしろにすると、低凝集密結合な構造に陥り、変更容易性が低下してしまいます。 設計スキルを高め、あるべき構造を設計する……これで解決できるに越したことはありません。 しかし、認知バイアスと呼ばれる心理効果により判断を誤り、良くない設計をしてしまうことが往々にしてあります。 本記事は、設計を歪めてしまう認知バイアスを理解し、設計判断の精度向上を促すことを目的とします。 この記事のゴール 人間の判断を歪めてしまう心理効果「認知バイアス」の存在を知ること。 ソフトウェア設計も、認知バイアスの悪影響を受けてしまうこと。 認知バイアスに振り回されない設計アプローチを身につけること。 認知バイアスとは 先入観や思い込み、偏
7つの設計原則とオブジェクト指向プログラミング - ソフトウェア設計を考える
設計原則はよい設計をするための指針です。 では、よい設計とはなんでしょうか？ もっとも重要なソフトウェア品質は発展性 ソフトウェアの発展性がビジネス価値を生む 発展性をうみだす７つの設計原則 モジュール化 モジュール化の２つのアプローチ 型によるモジュール化 手続き的なモジュール化 関心の分離 関心の4象限 入出力と計算・判断の分離 業務の関心と実装の詳細の分離 もっとも複雑な関心事（ビジネスロジック）の分離を徹底する カプセル化と抽象化 カプセル化 ビジネスロジックのカプセル化 抽象化 データ抽象 ビジネスロジックとデータ抽象 高凝集と疎結合 凝集度 結合度 隠された結合性の問題 定義の一点性 見た目が同じコード 7つの設計原則の学び方 コードの実装例 ドメインオブジェクト設計のガイドライン 実践ガイドとして使える本 設計の考え方を理解するための本 もっとも重要なソフトウェア品質は発展性
OpenAPIにおけるundefinedとnullの設計 | フューチャー技術ブログ
はじめにOpenAPI仕様に則ってREST APIの設計をする際に、値が存在しないという状態をどのように表現するかというお話です。 undefinedとはまずはじめに、ここでundefinedと言っているのは、OpenAPIの仕様において、リクエスト/レスポンスのデータ型を定義するSchema Objectのプロパティの1つであるrequiredが指定されていない状態を指します。 OpenAPIにおけるrequiredの定義を確認してみましょう。 OpenAPIの仕様を参照すると、Schema ObjectはJSON Schemaの仕様に従うと記載されています。 The Schema Object allows the definition of input and output data types. These types can be objects, but also primit
NoSQLデータモデリング技法
NoSQLデータモデリング技法.markdown #NoSQLデータモデリング技法 原文：NoSQL Data Modeling Techniques « Highly Scalable Blog I translated this article for study. contact matope[dot]ono[gmail] if any problem. NoSQLデータベースはスケーラビリティ、パフォーマンス、一貫性といった様々な非機能要件から比較される。NoSQLのこの側面は実践と理論の両面からよく研究されている。ある種の非機能特性はNoSQLを利用する主な動機であり、NoSQLシステムによく適用されるCAP定理がそうであるように分散システムの基本的原則だからだ。一方で、NoSQLデータモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティック
コンポーネントを小さく・きれいに設計しよう。Vue Composition APIを活用したコンポーネント分割術 - ICS MEDIA
Vue.jsを使った開発でよく悩まされるのがコンポーネントの肥大化です。複雑なアプリケーションになると、1つのコンポーネントが<script>ブロックだけで数百行…なんてこともめずらしくないでしょう。従来、Vue 2までの標準的な書き方では、UIとしてのコンポーネントの細分化はできてもロジックの分割や整理には限界がありました。しかし、Vue 3のComposition APIを活用すると、はるかに柔軟な整理・分割が可能です。 「Composition APIは難しそうだからまだ使っていない」という方、あるいは「導入はしているけどイマイチメリットがわからない」という方は、この機会にぜひComposition APIを活用したコンポーネントの整理術を試してみてはいかがでしょうか？ なぜ、Vueのコンポーネントは肥大化するのか？ 簡単な例を見てみましょう。下のサンプルはミニマムなアナログ時計のコ
2020年に立ち上げたWebフロントエンド構成の振り返り
こんにちは、よしこです。 株式会社ナレッジワーク というスタートアップで、2020年4月の創業時から一人目のフロントエンドエンジニアをしています。 初期に考えて組み上げたスタックで1年半ほど開発・運用してみて、なかなか快適に日々開発ができているので 新規開発のプロダクト立ち上げ時にどのようにフロントエンドを構築したのか？ 立ち上げから1年以上開発・運用を続けてきた今、それらの選択はどうだったのか？ を記事にして振り返り、公開したいなと思いました。 （プロダクトの内容はステルスで進めていてあまり対外的な発信ができないので、かわりに技術的なところはどんどんオープンにしていきたいなという気持ちがあります） いろいろな項目ごとに振り返りたいので、この記事は各項目を横断するindexとして項目ごとの概要を簡単に説明し、深堀りは項目ごとに追って詳細な記事を書いていく予定です！ 前提 プロダクトとしての
ネットで学ぶソフトウェア工学
ソフトウェア工学とは ソフトウェア工学とは、人間がソフトウェアを幸せに開発する方法を追求する学問です。そのために工学の方法を統合的に適用します。まあ、使えるうまい方法はなんでも使ってしまおうぜ、っていうわけですね。 ソフトウェア工学の方法を適用した結果としてソフトウェアのユーザも幸せになるべきです。開発者も幸せになるべきです。 工学は洒落た言い方でエンジニアリングって言いますね。 エンジニアリングとは、機械、構造、および橋、トンネル、道路、車両、建物などのその他のアイテムを設計および構築するための科学的原則の使用です。工学 Google翻訳 科学的な原則の使用です。科学的です。根性じゃありません。がんばろうとかじゃありません。がんばってなんとかなるものではない、ソフトウェア開発は。 このサイトは ソフトウェア工学関係のリンク集です。デスマーチの撲滅を願っています。ネット上にあるソフトウェア
これだけ抑えればOK!権限管理のDB設計デザインパターン - blog.waterlow.work
目的 最近仕事で権限管理の設計をやっていたのだが、設計でかなりはまってしまった。 今後ははまらないように、DB設計や判断基準をまとめておく。 ベースとなるパターン ユーザとロールは多対１で、ロールとアビリティは多対多に関連している。 権限管理やりましょうという場合にはこれにしておけば大抵の複雑な要求には対応できる。 もしユーザが増えてロールとアビリティの管理が複雑になってきても、DB管理なのである程度自由にやりことができる。 ただし、ちとファーストステップとしてはやりすぎか。 ユーザ-ロールが多対多パターン 前の例に加え、ユーザもロールを多数持つパターン。各権限が互いに素に近い状態、例えばカスタマーサポートとマーケティング、そのどちらも担当する人みたいなケースが有る場合に使える。 アプリケーションが大きくなっていて、権限の数も数十くらいになってきた場合はこれか。 直接アビリティパターン ユ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
