勘でリレーションを張っていないか？ - Qiita
はじめに 今回は外部キーを張るときに最低限意識したいことについて書きました。 何か間違えがあったり、もっとこういうところも意識してますという人がいたらコメントお願いします。 この記事で伝えたいこと ①リレーションシップ先のデータを消したときに同時にリレーションシップ元のデータが消えても自然な状態を作る ON DELETE CASCADEをうまく利用できる状態を作る つまり親子関係を正確に表現する。 リレーションシップ先は親テーブル、リレーションシップ元は子テーブルを意味しています。 ②データを作成するときのことを考えてデータの生成順序がおかしくならないように外部キーを張る ③関連を表現するときに中間テーブルを利用したほうが良い場面がある 注意 下記【例を交えながら説明】の説明に出てくるテーブル設計に関しては、上記の【この記事で伝えたいこと】の①と②と③の項目に対して想像しやすいように、理解
CTO から見た，なぜスタートアップ
初期のソフトウェア設計は壊れがちなのか - Speaker Deck
Speaker Deck This deck requires a password Password
どうやって技術的負債の雪だるまを生み出し、それを返済してきたか - 5年半越しの設計論
恥の多い生涯を送って来ました。 システムを開発していると、本当に多くの恥が生まれます。たとえば、こんな恥です。 テーブルの名前を付けミスったりは日常茶飯事。私が付けた変な名前が、自社の営業どころか他社のユーザーにまで浸透してたりもする。例えば、唐突に商品マスタに出てくる「グルーピングタグ」というカラムとか。（まじで意味不明） いま商品マスタと呼ばれているマスタの物理名が「kiosk_pricings」とか。日本語でおｋ。kiosk_pricings.grouping_tagってなんだよ。 「pricing」テーブルにはpriceカラムがあるが、全てのレコードで0になっていて、システムでは一切使っていないとか。（そのうち消したい） システムで使われている"正解"はkiosk_pricings.priceでした〜。 親子関係を間違えた事もある。チケットと決済の親子関係を入れ替えたりもした。 ま
バッチ処理 プラクティス
バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か？」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。
誤った共通化 - 日々常々
前に書いた キョウミタコード と同系列のネタです。 「コードは共通化するべきである」 これ自体に真っ向から全否定することはまーないかなと思います。例えばこんな感じで処理A1-3から処理Bを呼ぶのパターンはよくあります。 コードの共通化。いいですねー。同じような処理をまとめておくとメンテコストがぐぐっと下がる気がします。これをしなきゃ、どんどんコピペされたメソッドが増えていくことでしょう。同じような処理はまとめていくことは重要です。 ところでこの図を見てください。 ……わかります？一度処理をまとめているにもかかわらず、まとめた処理がまた枝分かれしています。それもまとめる前と同じ単位で。コードで書くとこうなります。 class A { void method1() { B.method(1); } void method2() { B.method(2); } void method3() {
ボタン電池が素手でどうあがいても開かなかった→そのPanasonicの理由に「開かなくて正解！」となった - Togetter
清水 潔 @NOSUKE0607 出先で電池が無くなり買った。ハサミで切れと書いてあるが無いから素手で格闘したが約10分で諦めた。これ全然開かない。もちろん子供のボタン電池誤飲防止のためだ。どれほど「開かない実験」を繰り返したのだろうか。思わず拍手した。Panasonicスゴイ。使えなかったがこれで良いと思います。 pic.twitter.com/GNKZbf6ZGl 2022-09-24 11:19:47 清水 潔 @NOSUKE0607 ニュースや情報を分析し辛口解説中。 経歴 /新聞社、出版社、テレビ報道記者、特別解説委員、早稲田ジャーナリズム大学院講師、他。「文庫X」などの著書が数冊、受賞歴多数。 ▪️メディアでの解説、講演やジャーナリズム研修、番組制作支援や危機管理を行っています。お問い合わせは「株式会社Jpエンジン」まで。 jp-engine.jp/cultural/index
ドキュメントに固執せよ - gfnweb
どうして人間集団はこんなにも知見の共有を円滑にできないのか？ 改善にはドキュメントにまつわる各個人の心構え・制度設計・技術的解決の全部が必要だという話をしたい． ここでテーマにしているのは，著名OSSなど世の中にいくらでも知見が転がっている対象ではなく，特に企業内の十数人のチームでクローズドに開発しているなどして集合知に頼れない状況下でのドキュメントについてである． 非常に乱暴な言い方をするなら，「コードとか大部分は誰でも書けるようになるものなんよ，そんなところにマッチョイズムとか感じなくてええねん，我々の知的体力や組織性が真に試されるのはドキュメントちゃうんか」という気持ちです — 画力・博士号・油田 (@bd_gfngfn) June 3, 2022 ドキュメントに書く内容の必須項目或るシステム（ソフトウェアなど）について，そのシステムのことを全く知らない人を想定読者としたドキュメント
営業日などの規則性と例外を扱うための設計
解決したい問題 例として、飲食店の予約サービスを考える。 予約を受け付けるためには各店舗の営業スケジュールを管理しておいて、営業日の営業時間内のみ予約を受け付けるようにする必要がある。 たとえば、ある店舗は各曜日の営業時間について、以下のように定めているとする。 平日：11:30-22:00 土曜日：11:00-22:00 日曜日：11:00-21:00 定休日：木曜日 これを素朴に設計すると、たとえば以下のような「営業日については営業時間を保持し、定休日についてはレコードがない」というテーブルになるかもしれない。 店舗 曜日 開店時刻 閉店時刻
ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
安藤忠雄設計の子どもたちのための図書館への子供反応「なんでこんなん作ったん？」を巡る賛否
SIVA @sivaprod 大量のリプいただき個々にはとてもお返事差し上げられませんがとりあえず「上の本は全部固定されたダミーだから安全ですよ」と「安藤忠雄が寄贈した建物なんだから安藤忠雄が好き放題やって当然」って書いて寄こしたひととは友達にはなれそうにないなあとだけ。 2022-03-27 12:00:50 異邦人 @Narodovlastiye 「子どもの為の図書館」などと言いながら、手に取れない位置に固定されている本について「これどうやって取るの」「何でこんなん作ったの」と、子どもに指摘される「図書館」とは一体何なのか。本をオブジェにし、図書館という施設が一体何の為にあるのか分からない施設。 www3.nhk.or.jp/lnews/kobe/202… 2022-03-26 22:50:53 リンク NHK NEWS WEB 神戸市に子どものための図書館「こども本の森 神戸」オープ
RDBのデータモデリング・テーブル設計の際に参考にしている考え方と資料
はじめに タイトルのとおり、RDBのデータモデリング・テーブル設計を行う際に参考にしている考え方と関連資料をまとめました。 P.S. なんと本記事内でいくつか参考として挙げさせてもらっている増田さん・かとじゅんさん・奥野さん・そーだいさんからコメントいただくことができました。 本当にありがとうございます。 前提 RDBを採用するのは事実を無駄なく正しく記録するため 正規化、トランザクション、制約とデータ整合性 基本的には始めに理想として集合論・リレーショナルモデルに基づいて正規化を考え(論理設計)、パフォーマンスなどの現実問題に対して折り合いをつけていく(物理設計) 制約を最大限利用する cf: ↑P91〜 ↑P.29,41 ↑P56〜 ↑5章 ↑P347～ 情報とデータ データ：単なる事実の値→これを永続化して蓄えるものがRDB 情報：データから生み出される意味や目的のあるもの→RDBか
アプリケーションの設計にEIPの知識が役に立つよ！
非同期メッセージングを使ったインテグレーションパターン (EIP)は、クラス設計にも参考になるものが多い。 すぐに非同期メッセージングを使わないとしても、EIPは設計の参考情報として知っておきたい。
ドメインイベントの観点から再考するソフトウェア設計
ドメインイベントは過去に起きたドメイン上の出来事を意味します。「過去に起きた」なので後から変更できません。つまり不変(イミュータブル)なモデルです。 昨今、このドメインイベントはCQRS/Event Sourcingやマイクロサービスなどの書籍で取り上げられ、実際に実装上でドメインイベントが利用される事例も増えています。このように有益性は認識されつつありますが「うちはEvent Sourcingじゃないのでイベントは関係ありません」と視野が狭くなっている方もいます。 たとえ実装で使えなくても、ドメイン分析に基盤的な視点を与えてくれるのがドメインイベントです。 ともあれ、この資料は「そもそもドメインイベントはソフトウェア設計にどのような影響を与えるのか」を解説します。
イミュータブルデータモデルの極意
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。Read less
「AWSコンテナ設計・構築 [本格] 入門」を執筆しました - How elegant the tech world is...!
はじめに 前回の投稿から少し日が空いてしまいましたが、AWS x コンテナに関する商業誌を執筆したので、本ブログにて少し内容を紹介できればと思います🚀 本日、無事校了しました(発売日が10/21なので、結構ギリギリです)。 Amazon.co.jp: AWSコンテナ設計・構築本格入門 : 佐々木拓郎 新井雅也 馬勝淳史: Japanese Books 執筆の経緯と書籍のテーマ 2020年春先、APN Ambassadorであり多数のAWS書籍を執筆されている佐々木さん@dkfj、APN AWS Top Engineersの一人である馬勝さん@HorseVictoryと一緒に技術書典#8に出展したことが事の始まりです。 執筆したクラウドネイティブファーストストーリーが多くの読者の手にとっていただけたという背景もあり、佐々木さんのご厚意により、出版社(SBクリエイティブさん)に繋いでもらいま
![「AWSコンテナ設計・構築 [本格] 入門」を執筆しました - How elegant the tech world is...!](https://cdn-ak-scissors.b.st-hatena.com/image/square/5bef5a34c4f43f9976e16ce8fb2169c293b55298/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fi%2Fiselegant%2F20211006%2F20211006220119.png)
ソフトウェア設計についての原則や法則についてまとめてみた
ソフトウェア設計について、YAGNIやSOLIDなど多くの原則・法則があることが知られていますが、その解釈にはぶれが存在することが多いです。そこで、特に有名なものあるいは有用と感じることが多いものをいくつかピックアップして、その解釈やトレードオフについてまとめてみました。 注意としては、SOLIDが入ってることからわかる通り、主にOOPに関する文脈になります。また、各原則の定義については概ね知っている前提で書いているのであまり初学者向けの記事ではないかもしれませんのでご承知おきください。 YAGNI（You ain't gonna need it.） YAGNIは、予測による実装が実際に役立つことは少ないという経験則から生まれた原則です。 一般にオーバーエンジニアリングが利益をもたらすケースは限定的で、どちらかというとプロジェクトに害を与えることが多いとされています。YAGNIは日々状況の
モダンなソフトウェア設計の書籍 - kawasima
型駆動設計から始まるフォーマルなアプローチもカバーしているが、フォーマルな方法の簡単な紹介も含まれているもの。
前任者から引き継いだシステム、うるう年なのに何故か2/29が表示されないと思ったらとんでもない設計になっていた件
ありあ @aria_nico ある日、私は引き継いだシステムのバグの対処をしていた。うるう年なのに2/29が表示されない。 プログラムを開くと、 If year=1992 or year=1996 or year=2000 then という文字列があった。 百歩譲って、うるう年計算式を使わなくてもいいから、もっと長期の稼働を見越してほしい。そう思った冬の日 2021-03-01 14:20:40 ありあ @aria_nico ファミコン大好き、ありあです。お料理とレトロゲーム配信の人。お仕事はシステムエンジニア。特技はハープを弾くこととお茶をこぼすこと。フォローお気軽にどうぞ！色々リンク→lit.link/aria25 twitch.tv/aria_nico
「ビジネスロジック」とは何か、どう実装するのか - Qiita
アプリケーション開発で、「ビジネスロジックは分離しろ」だとか「Controller にビジネスロジックを書くな」といったことをよく言われると思います。 しかし、ビジネスロジックという言葉の意味を聞いたり調べたりしてみても、「システムのコアの部分」とか「システムの目的になる処理をするところ」みたいなことを言われたりして、よく分かりませんでした。 そんな中、クリーンアーキテクチャや DDD の戦術的設計について学ぶことで、「ビジネスロジックとは何か」、「ビジネスロジックはどう実装するか」について、自分なりの考えが整理されてきたので、この記事ではそれをまとめます。 ※ 曖昧な言葉を自分としてどう使っているかという話になります。違う意味で使う方もいると思うので、ご注意ください ビジネスロジックとは何か 「システムのコアの部分」とか「システムの目的になる処理をするところ」といった説明も正しいとは思い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ふつうのプログラマのふつうの設計
