DynamoDBデータモデリング虎の巻：第壱巻 〜前提知識編〜 - misc.tech.notes
動機など 最近、Serverlessの文脈からDynamoDBのテーブル設計の相談を受けることが多くなってきていて、Podcastでも話したけどけっこう図とかが無いと説明しづらい領域なので、まとまった資料がほしいなということでまとめてみる。 cloudinfra.audio どう考えても長編大作エントリ不可避なので気力が続けば第二巻以降に続きます…！（フィードバックが多いと頑張れるかも…！） 本巻の対象と前提知識 本巻はDynamoDBのデータモデリングにスコープを絞っています。DynamoDBおよびデータベースの一般用語などについての説明は省きます。 前提知識としては以下のようなものになるかと思います。 DynamoDBのサービスとしての概要や用語( WCU , RCU , GSI , LSI など)を知っている Hash TableやB-Tree(B+Tree)といったデータ構造がどん
【Java】定数クラスをどうしたものかと改めて考える
いや、大した話じゃないんですけど みんなどうしてるのかなって思って。 Javaの定数クラス。皆さんの使用状況はこんな感じだろうか。 なにそれ？ 知ってるけど使ってない 全部propertiesファイルとかxmlとかに持ってるから使わない 使ってる 使うとすればどのように使うのが良いかなとか。 わざわざ考えたりしないような気がするので、あえて考える。 定数クラスとは 定数クラスとはpublic static finalなフィールドをたくさん持つクラスで、 定数を管理するために用いられる感じ。 ざっくりとこんなの。 見たことある人は「あー、、。。。」となる。 public final class Constants { public static final String SLASH = "/"; public static final String BLANK = " "; public s
アーキ部：テーブル設計をやってみよう！ - そこに仁義はあるのか(仮)
毎週金曜の定時後に弊社でアーキ部なるものが開催されています(✌'ω' ✌) スピードラーニング的に@kawasimaさんのお話を聞く会ですが、今週はテーブル設計がテーマでした！ この記事がすごく良かったので、触発されてブログ書く！！！ developer.hatenastaff.com お題 ↓のお題が出て、テーブル設計を考えてみるはなし。 要求仕様は以下のとおり。 ・宿の部屋は、シングルやツインのような部屋タイプが設定できます。 ・宿側で宿泊プランを設定できます。宿泊プランは適用される日付が設定できます。 ・プランには複数の部屋タイプが含まれることがあります。 ・宿側でプラン・部屋タイプ・宿泊日ごとに宿泊費の設定ができます。 ・カスタマはプラン・部屋タイプ・宿泊日を指定して宿泊予約ができます。 ・予約は会員でも非会員でも可能です。 ・また、会員・非会員に関わらず、宿をお気に入りに登録でき
「Hava」でAWSのシステム構成図を自動生成する | DevelopersIO
クラスメソッドでは、メンバーズサービスの一環として、お客様が構築された環境について構成レビュー（AWSのベストプラクティスに沿った構成になっているか？）や運用作業の支援（各種作業代行）を実施させていただいております。 これらを実施する場合、まず最初にやることはお客様の環境把握なのですが、設計ドキュメントは最新の状態が反映されているとも限らないので(そもそもドキュメントがないケースもあります)、多くの場合AWSのマネージメントコンソールから実際の環境を読み解くという作業が発生します。 小規模なシステム(本番環境のみ＆EC2とRDSが1台ずつなど)であれば問題ありませんが、複数環境が混在、EC2も二桁台、、ぐらいになるとシステム全体像を把握するだけでも結構な時間がかかります。 今回はそんな既存環境の構成把握に一役買ってくれるであろうWebサービス「Hava | Automated AWS Ar
【JDMC】「データマネジメント概説書」のあるある集 | DevelopersIO
こんにちは、川崎です。「データマネジメント概説書」を読んでいて、「データマネジメントあるある」とでもいうべき、金言集がありましたので、ご紹介したいと思います。 「データマネジメント概説書」は、コンパクトにまとまっていて読みやすいので、日頃データ分析に取り組んでいる方は、ぜひご一読ください。 （Kindle版で、400円ほどです。アマゾンプライムの会員の方は無料で読めます） データマネジメント概説書（JDMC 版）: ビジネスとITをつなぐ－データマネジメントとは [Kindle版] http://www.amazon.co.jp/dp/B00UC7NC92 （1.3 データマネジメント実現の課題 より引用） 部分導入を繰り返してきた歴史から、全体設計ができているという錯覚に陥る 企業／組織を全体としてつなぐのは本来情報である。しかし、業務ごとにシステム導入が積み上げられてきた経緯から、 全
PlantUML + IntelliJ IDEA - タケユー・ウェブ日報
恥ずかしながらPlantUMLというツールを知らなかったんだけど、IntelliJ IDEAのPlantUMLプラグインで初体験。なにこれ快適。 テキストファイルなので、シーケンス図、クラス図などいろんな設計がVCSで管理・マージできるすばらしさ。 IntelliJ IDEAのPlantUML integrationでサクサクライブビュー。マウスとキーボードを往復せずとも書けるので思考を途切れさせません。 プロジェクトファイルと一緒に管理していれば不整合も減らせそう。 導入手順 プラグインリポジトリで'PlantUML integration'検索、インストール。PlantUML本体も含まれる？ので別途インストールは不要です。 シーケンス図以外の描画に使う'graphviz'をインストール。macなら'brew install graphviz'でOK。 プラグインの設定でgraphviz
Data Models
Data Models: A Comprehensive Guide to Structuring Information for Optimal Insights and Decision-Making In the realm of data management, the use of effective data models plays a pivotal role in organizing and representing information in a structured and meaningful way. Data models serve as the blueprint for databases, facilitating efficient data storage, retrieval, and analysis. This article delves
アジャイル時代のモデリング: アジャイルチーム拡大のためにはコードの次に何を保つべきなのか
図１．シンプルなスクラム構成 この最小限のフレームワークの中で、チームのインプットとなるのが”ユーザ要求”としての”プロダクトバックログ”です。そして、アウ トプットは”動くソフト ウェア”としてのコード（”製品コード”と”テストコード”）です。 そこには他の設計要素が明示的に現れてはいません。スプリントの中で作られたすべての意図的な設計はチームの財産として実行コートの中に組み込まれるのが 望ましいですが、そこには直接コード化されない情報もあります。スクラムは開発プロセスであり、設計に関しては敢えて何も言及していませんが、設計と設 計活動はチーム内部であいかわらず行われています。 Grady Booch氏は”コー ドは真実ではあるが、すべての事実ではない” と語っています。だから、もしそこにコードで表現又は伝われない情報が残されるとしたら、私達はその情報をどこに格納できるでしょうか？その質
らくらくシーケンス図：WebSequenceDiagrams #apijp - Groovyラボ
これはWeb API Advent Calendar 2014、7日目のエントリです。知っている方も多いと思いますが、ツールの小ネタで。 Web APIを扱っていると、認証やマッシュアップのフローの記述など、簡単なシーケンス図を書きたくなる場合がよくあります。こんなときにオススメなのが、カナダのHanov Solutions社が提供する便利なWebサービスWebSequenceDiagrams。 次のようなシンプルなテキストを書くだけで： title GWでのmashup アプリ->GW: POST 郵便番号 GW->サービスA: GET /郵便番号 サービスA->GW: 住所(JSON) GW->サービスB: POST 住所 サービスB->GW: 緯度経度(XML) GW->アプリ: 緯度経度(JSON)次のようなイメージを生成してくれます： 基本的に無償で使えますし、生成した図は直接リ
要求開発にて”「これだけ」モデリング”：An Agile Way：オルタナティブ・ブログ
これだけモデリング！というコンセプトで、山岸さんが話された5/28の要求開発定例が面白かったので紹介します（山岸さんはリーンモデリングとも呼んでいたがぼくはベタにこれだけモデリング、という日本語が好き）。 情報システム部門目線で見て、どんどん複雑になるアプリケーションの要求や設計を見通しよく「共通合意」を作るための、「軽い」モデリングの必要性が今回テーマです。そうなんです、従来は、「全部書かなきゃだめ」とか「全部メンテしないといけない」とか、「下流を触ったら上流までさかのぼって修正しなきゃ」とか足かせが多かったので、なかなかペイしなかったのですね。だから、「これだけ」モデリングを提案したい、という訳です。 （※6/5 追記： 以下に、当日の資料を公開します。） これだけモデリングとは、 誰が？ ー 情報システム部門の人（と開発の人が共に） いつ？ ー システム開発の前段階、すなわち「要求開
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
20150901 eclipse siriusの概要
クラス名の探し方 | GuildWorks Blog