履歴データテーブルとの向き合い方_PHPerKaigi2024PHPerKaigi2024 の登壇資料です。 履歴データテーブルとの向き合い方 https://fortee.jp/phperkaigi-2024/proposal/47cf9f17-825a-4021-bf33-86e4a62bc222
markdownlintで設計書の品質を高める | フューチャー技術ブログ
はじめにフューチャー技術ブログのリレー形式の連載である、春の入門祭り2023の1日目です。TIG真野です。 ここ数年、Markdownで設計書をチームで書き、GitHub（GitLab）上でレビューするフローを採用しています。なるべくテキストベースで設計開発フローを統一するため、私の所属するチームでは以下のようなツールを採用しています。 シーケンス図、業務フロー図 Markdown中にPlantUMLで記載 参照はGitHub上からも見れるように、pegmatite を利用 システム構成図など画像系 Diagrams.net（draw.io）で作成し、.drawio.png の拡張子でMarkdownから参照 これだけは目視で差分チェックとなる Web API定義 OpenAPI SpecのYAMLファイル 参照はGitHub上からも見れるように、swagger-viewer を利用 ER
書き込みがあるワークロードにおける ZOZOTOWN マルチクラウド構想とその検討停止について - Qiita
この記事はZOZOテクノロジーズ #1 Advent Calendar 2019 23日目の記事です。 昨日の記事は弊チームの inductor による「GKEの内部負荷分散機能を使ってInternal Load Balancerを構築する」でした。面倒で困っているのでGCP様にはなんとかして欲しいものです さて本記事では、残念ながら本番運用には至らなかったのですが、私がここ暫くMLOps業の裏でやっていた「書き込みがあるワークロードにおける ZOZOTOWN マルチクラウド構想」の検討結果について供養のつもりで記そうと思います。 なお、今年は弊社では全部で5つのAdvent Calendarが公開されています。 ZOZOテクノロジーズ #1 Advent Calendar 2019 ZOZOテクノロジーズ #2 Advent Calendar 2019 ZOZOテクノロジーズ #3 Ad
運用業務の設計思想 /20190520-awsj-pro-operation-design
5/20(月)開催のAWSプロフェッショナルサービス勉強会での発表資料です。 (注意) 現時点での総まとめ的な資料なので250ページ超あります。あらかじめご了承ください。 # 発表の概要 多くの運用現場において、経営・マネジメント層からの「運用自動化」要求や、業務の多様化や業務量増大により、「運用自動化」を進めざるを得ない状況に追い込まれてきています。 しかし、運用自動化には多くの不都合や副作用があり、意図に全く反した結果をもたらすことの方がむしろ多いのが現実です。 今回は、比較的大きな組織の中で、(運用業務の自動化を含めて)「変化に強く、スケールおよび持続可能な運用」を実現するために、どのような取り組みが必要なのか解説します。 # アジェンダ 1. 運用自動化、不都合な真実 2. 運用業務の「構造化」という大前提 3. 「運用業務」構造化の例 3.1. 「運用」の定義 3.2. 「運用価
実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
基本設計を分担してはいけない - 設計者の発言
プロジェクトメンバーが無駄に多いのが、日本型SIの特徴のひとつである。「工数を人数で割れば工期が出る」と考えることが間違いであることは、ブルックスの著書「人月の神話」によって今から40年前に指摘されている。それにもかかわらず、相変わらず多くのプロジェクトで必要以上の人数が投入されている。 私がとくに不思議に思うのが、基本設計を何人もの要員で分担するやり方だ。DB設計と機能設計と業務設計の担当を分けるとか、サブシステム毎に担当を分けるといった体制がしばしば敷かれる。詳細設計の段階でというのならまだわかるが、基本設計でそれをやってはいけない。 なぜか。業務システムにはアーキテクチャ（意図された構造）が求められる。そして、そこに含まれる膨大な定義要素は、統一感や一貫性を保ち、かつMECEな形で切り出されなければいけない。複数の要員で分担などすれば、それらの課題が一挙に難しくなる。また、DB構成と
論理削除の前に別テーブルに切り出せるかどうかを考えよう - Life is Really Short, Have Your Life!!
めっちゃよくまとまっているので、大変助かりました。 blog.mogmet.com t-wada氏の「とりあえず削除フラグはアカン」については、僕も全く同感です。論理削除をしなければならないビジネス上の理由がスッポリ抜け落ちている。「とりあえず削除フラグ立てて何かあれば戻せるようにすればいいンゴ」ってのは論理設計を放棄していると言い換えても良いし、「ユーザーの言葉ではない」という指摘も重要。こちらに書かれています。 ledsun.hatenablog.com じゃ、フラグやめてどーすんのって話。フラグを立てたくて立てる人はおらん(はず)。「削除フラグを追加するとSELECT時に常にWHERE句で削除フラグを引っ掛ける必要があるのでクソ」→「削除日や状態カラムを使おう」では解決にならん。t-wada氏の資料でも解決策で上げられてたけど「×」マークがついてます。下記に変わっても誰も嬉しくないと
論理削除 Casual Talks #1 で「論理削除しない」という話をしました - moroのブログ
互いの前職での先輩後輩である @kenchan と企画した論理削除 Casual Talks #1で、「論理削除しない」という話をしてきました。 話す内容が各話者で面白いほどかぶっていたのでなかなか大変でしたが、普段から言っている「論理削除するな」「削除じゃないからちゃんと機能を設計しましょう」という内容を話してきました。 他の方の話も、かぶっているようで新しい視点もあって、いち参加者としてもたいへん勉強になりました。
ユースケース駆動ではなくロバストネス駆動開発？ - プログラマの思索
「ロバストネス駆動開発」という言葉を見つけたので思わずメモ。 【参考1】 天使やカイザーと呼ばれて ≫ ロバストネス駆動開発？ 天使やカイザーと呼ばれて ≫ ロバストネス図113枚!! OOAD講座：第5回「ロバストネス分析を設計・実装につなげる」 | artisan edge thinking ロバストネス図の使い道: プログラマの思索 ユースケース→ロバストネス分析→クラス設計という順に開発していくスタイル。 この時、ロバストネス分析が最も重要であるという認識から、「ロバストネス駆動開発」とネーミングしたらしい。 確かに、ロバストネス図がきちんと書ければ、バウンダリ・コントローラ・エンティティを多少変形するだけで実装に近いクラス図を設計できる。 ロバストネス図を1日中書いたら113枚になった、という記事は確かにすごい。 単なるテーブル保守画面ではなく、背後に複雑なロジックがあったり、バ
オブジェクト指向エクササイズのススメ
3. ThoughtWorksアンソロジー ThoughtWorks社コンサルタント ● の 骨太なエッセイ集 様々な ジャンルを収録 ● DSL、プログラミング、設計、 マネジメント、ビルド、デプロイ、テス ト．．． オライリーさんブースで ● 絶賛販売中！ 3
詳細設計書ってあるじゃないですか。 - 室長のひとりごち
「詳細設計書ってあるじゃないですか。」 「あるね。」 「『必要ですか』って聞かれたんですけど。」 「そう。」 「必要ですかね。」 「何て答えたの。」 「成果物で決めているなら必要でしょう、って。」 「成果物なら必要だね。」 「『じゃあ、成果物じゃなければ必要ないんでしょ』って聞かれて。」 「何て答えたの。」 「詳細設計書で何を伝えたいか決まっているの、って。」 「質問で返したんだ。」 「まぁ、そうですが。でも、質問の意味が解らないし。」 「そしたら。」 「設計する人とコード書く人が同じならいらいですよね、って。」 「質問が変わった気があるね。」 「まあまあ。」 「それで。」 「同じ人なら確かにいらない、って。」 「マジで。」 「はい。」 「とっても限定されている条件下での話、だよね。」 「うーん、そうかも…しれないですね。」 「今のビジネスでそんな条件下、存在するんかい。」 「わからないで
クラウド環境の設計指針をどう決めるか - たごもりすメモ
クラウドに限らず、データセンタの設計全般に言えることだけど。 コンピューティング基盤をどのように設計するかには根本から異なるアーキテクチャが様々あって、ある特定の方向のアーキテクチャについても実現するためのソフトウェアやハードウェアに様々なものがある。 合議制で決めてはいけない。何を採用するか、どのように設計するかについては、誰かが英知をもって決断するべきだ。それも可能な限り素早く。 今更言うまでもないことだが、この世界は技術の変化が非常に速い。おそらく3年経てば優位な技術は入れ替わっていて、何か新しいトレンドとか技術要素だとかいったものが登場しているだろう。 そんな中で何を採用するかについて、長い時間をかけるのは簡単だ。3年かけて実機を多数揃えて比較検討すれば、検討開始からの3年間で何が優位だったかが確実にわかるだろう。 おそらくその頃には別の技術が登場し、更に3年の比較検討が必要になっ
IDの設計についてのさらに突っ込んだ議論
今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で
ソシオメディア
ソシオメディアは各種ビジネス向けデジタルプロダクトのデザイン支援を行うデザインコンサルティング会社です。業界をリードする OOUI（オブジェクト指向ユーザーインターフェース）設計、独自ガイドラインをもとにしたエクスパートレビュー、クリエイティブ組織を構築するデザインマネジメント支援など、様々な角度から御社のデザイン戦略をサポートし、デジタルトランスフォーメーションを実現します。 もっと読む 多くの方からご要望をいただいておりました OOUI メソッドの解説書『オブジェクト指向UIデザイン ― 使いやすいソフトウェアの原理』が、2020年6月5日、技術評論社より遂に出版されました。 オブジェクト指向ユーザーインターフェース（OOUI）とは、オブジェクト（もの、名詞）を起点としてUIを設計すること。タスク（やること、動詞）を起点としたUIに比べて劇的に使いやすくなり、開発効率も向上します。 ブ
その画像、伝わっていますか？ (ユーザビリティ実践メモ)
WEBサイトでは、紙面に比べて文字を読む速度が遅くなるため、画像が好まれる傾向にあります。 しかし、画像はメッセージを伝える手段であるという認識を忘れ、ただ画像を掲載しただけでは、ユーザと適切なコミュニーションが取れない場合があります。 このサイトでは、「教材のサンプル画像が見たい」というユーザからの要望が強く、企業側としても教材の良さを知ってもらいたいため、サイト上に多くのサンプル画像を用意していました。 しかし、サイトを閲覧したユーザに教材の印象を聞くと、「特に印象がない」「普通」という返事が返ってきてしまいました。なぜでしょうか？ ユーザ行動観察調査で画像を見る様子を観察すると、原因は明らかでした。 ユーザは、確かにサンプル画像は見ますが、何となく全体を眺めるだけで、すぐに次のページへ移動していました。 サンプル画像によって伝えたかった教材のこだわりや工夫が全く伝わっていなかったので
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アーキテクトに求められるマインドとは / mindset for an architect
ゲーム開発に携わる Web エンジニアへ贈る, 正しい Web サーバの作り方.
履歴を持つデータの設計
はてなブログ | 無料ブログを作成しよう
長文日記