Amazon DynamoDB におけるシングルテーブル vs マルチテーブル設計 | Amazon Web Services
Amazon Web Services ブログ Amazon DynamoDB におけるシングルテーブル vs マルチテーブル設計 この文書は、AWS ヒーローであるAlex DeBrie によるゲスト投稿です。 Amazon DynamoDB について学ぶ人にとって、シングルテーブル設計という考え方は、最も心を揺さぶるコンセプトの1つです。DynamoDBのテーブルは、エンティティごとにテーブルを持つというリレーショナルデータベースのような概念ではありません。多くの場合、1つのテーブルに複数の異なるエンティティを含みます。 DynamoDBのシングルテーブルに関するデザインパターンについては、DynamoDBのデベロッパーガイドを読む、re:Inventのトークやその他のビデオを見る、私が執筆した本をチェックするなどで理解することができます。シングルテーブル設計の賛否両論に特に焦点を当て
SQLアンチパターン勉強会 第五回：EAV(エンティティ・アトリビュート・バリュー) - Qiita
はじめに 本エントリーは某社内で実施するSQL勉強会向けの資料となります。 本エントリーで書籍「SQL アンチパターン」をベースに学習を進めます。書籍上でのサンプルコードはMySQLですが、本エントリーでのサンプルコードはSQL Serverに置き換えて解説します。 また本章以外のエントリーおよび利用するSQLリソースなどは、以下のGitHubを参照ください。 EAV(エンティティ・アトリビュート・バリュー）とは 「リレーショナルデータベースはメタデータの柔軟性が低い」という拡張性の問題についての議論は、リレーショナルモデルが提唱されて以来、途切れることなく議論されてきました。 EAVは「可変属性をサポートする」など、柔軟な設計を目指したことに起因するDB設計のアンチパターンです。 EAV(Entity-Atribute-Value)では、次のような項目を持たせたテーブルが設計されます。
クリーンアーキわからんかった人のためのクリーンじゃないけどクリーンみたいなオニオンに見せかけたSOLIDの話
依存関係逆転則含む諸原則に苦しめられた方々，いかがお過ごしでしょうか． 今回はアプリ設計の話です．と言っても，前回「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」というZenn記事を書いて，反響が大きかったのでリメイクしたいなという気持ちになり執筆することにしました． 前回同様，調べていく上で誤解していた部分や理解しにくかった部分を語った上で，オニオンアーキテクチャという，クリーンじゃないけどクリーンみたいな玉ねぎについて紹介するのですが，今回はわかりやすい図解であったり，実際にどのような実装をしていくべきなのかを話の話題として加えていければ良いかな？って思っています． これは前回の記事である「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」の記事の裏話的な話を一つさせてください． 今年の11月初め頃に，サポーターズという企業の学生が登壇できるLT会があり，私
特商法ページのURL設計についてそろそろ本気出して考えてみる - NOT SO BADなブログ
特商法ページのURL設計についてそろそろ本気出して考えてみるFeb 22, 2019 意識低い個人開発論（猫の日に1日遅れたし画像は本文と一切関係ありません） インターネット上で何かしらの販売を行う場合、「特定商取引法に基づく表記」ページを用意することがほぼ必須となります。 なので大人しく用意するわけですが、このページのURLをどうしたものか毎回悩むわけです。 というわけで100個くらいのサイトを参考にして、一般的な傾向を調べてみました。 結論としては「好きにしたらいい」なのですが、気になる方は以下ご参考くださいませ。 前提なんで特商法のURLで悩むのか似たところだと「利用規約」と「プライバシーポリシー」のページがあります。 しかしこっちは何となく英語で「terms」とか「terms-of-use」、あるいは「kiyaku」とかで済ませられる感じ。 ところが特商法の場合、ばちっと1語で対応
アプリケーションにおける権限設計の課題 - kenfdev’s blog
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
毎朝15分の勉強会で若手の設計力がメキメキアップした話 - Qiita
1. はじめに 本稿は、私のプロジェクト(ベテラン1人、開発経験が半年未満の若手2名)で実施している「アウトプット勉強会」の実施方法を紹介します。 この勉強会を実施してから若手の設計・実装スキルがメキメキアップしました。私は過去に新人8人くらいの育成に携わりましたが、これが一番効果的だと思います。 なお、「アウトプット勉強会」の形式は、「書籍編」と「設計・実装編」の2種類がありますが、本稿では「設計・実装編」を説明します。「書籍編」の形式については、以下の記事を参照ください。 毎朝15分の勉強会で若手の行動が驚くほど改善した話 本稿は、以下の方々が対象です。 若手を育成するために設計する機会を与えたいが、なかなか与えられないリーダー層 → 業務と並行して勉強会を実施するといいと思います。 設計がやりたいけど業務でその機会が与えてもらえない若手 → 上司の手間は毎朝15分だけなので、頼めばや
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
Amazon Dash Buttonは何がヤバイのか
Amazon Dash Buttonについて、人と話す機会が何度かあったので、 いかにAmazon Dash Buttonがヤバイかを毎度説明するのだが、 「あんな電池が一年で切れるデバイスは使えない」 「商品がドラッグストアよりも高いのに買うやつはいない」 といった的外れな答えが割と帰ってきて、もんにょりすることが多いので、私が思うヤバさを解説してみようと思う。 エンジニアリング的なヤバさ Amazon Dash Buttonは、どう考えてもビジネスモデルから逆算してハードウェアを設計しているので、ハードウェアから設計して、ビジネスモデルを作ろうとしている連中は絶対に勝てない。 ビジネスモデルによってハードウェアに対する要求は大幅に変わる。 IoTデバイスはコスト、大きさの面でリソースが限られているため、限られたリソースをどこに割り振るかで、要求を満たせるかどうかが決まる。 Amazon
アプリケーションから例外を投げる派、投げない派 - Shin x Blog
例外をどのような状況に投げるかもしくは投げないか、というのはわりと意見が分かれるところです。もちろん、プログラミング言語によっても異なりますが、同じプログラミング言語ユーザ同士でも様々です。 基本の考え方 ベースとしては、Effective Java の項目 39 にある下記の方針が参考になります。 例外的な状況の時にのみ例外を使う。 Effective Java 禅問答のような定義ですが、これには異論は無いでしょう。例外を正常フローで利用したり、制御構造に用いるべきではありません。 人によって異なるのは「例外的な状況」の解釈です。 例外的な状況 この「例外的な状況」の解釈は人によって異なるようで、これまでも議論になっていました。これまで聞いた解釈を乱暴に分けると以下の 2 パターンに分かれます。 1. アプリケーションから独自の例外を投げる派 ランタイムやミドルウェア連携などプラットフォ
4ステップで作成する、DB論理設計の手順とチェックポイントまとめ - Qiita
はじめに 「達人に学ぶDB設計」、「SQLアンチパターン」を読んだのでDB設計をする流れとその過程でのチェックポイントをまとめてみました。 今回は本に載っているものの中でも特に重要そうな部分に絞ってみました。 さらに詳しいことを知りたい方は本を購入してみてください。個人的には達人に学ぶDB設計徹底指南書のほうがおすすめです。こちらだけあれば十分だと思います。 DB設計には大きく分けて論理設計と物理設計の二つがありますが、今回はアプリケーション開発でメインとなる論理設計の部分に焦点をあてて説明をします。 一番最後にチェックポイントだけをまとめた章を用意したので、チェックポイントだけ知りたい方は最後だけ見ていただければと思います。 DB論理設計の流れ DB論理設計は以下のようなステップで進めていきます。 エンティティの抽出 エンティティの定義 正規化 ER図の作成 以下では各ステップごとに章を
ひどいコードをメンテしてきたからこそ実感する、良いコードや良い設計の大切さ - give IT a try
はじめに 先日、社内で「良いコードの書き方やお作法、プログラミングの原則って、どうやったら身に付くんだろうねえ？」という話になりました。 もちろん、「本を読んで勉強する」っていのも勉強法のひとつなんですが、そもそも、もっと強烈なモチベーションがないと、必死になって良いコードの書き方やプログラミングの原則って勉強できないのでは？なんて思ったりします。 強烈なモチベーションというのは、たとえば、 いったい何なん！？このスパゲティコードは！！！ なんでこんなコードを俺がメンテしなきゃあかんの！！？？ あ～、もう最悪や！！俺はこんなコード、絶対に書かへんぞ！！！！ っていうぐらいのモチベーションです。 というか、これは単純に僕のケースですね、はい。 幸い、ソニックガーデンに入ってからは、周りのプログラマがみんなちゃんとしているので、そんな思いをすることはほぼなくなりましたが、前職、前々職ではそんな
日本と欧米ではPOJOの意義に対して微妙な解釈の違いがあるような気がする - 達人プログラマーを目指して
EJB2.1など、開発すべきクラスインターフェースに大きな制約のある侵略的なフレームワークに対してマーティン・ファウラーが広めた概念としてPOJO（Plain Old Java Object）という用語があることは、現在Java開発者であれば、周知のことかと思います。私は当時はEJBなど重量フレームワークの使用を推奨する立場の会社にいたので、POJOという言葉を知ったのは意外に遅く、2004年ごろエンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)などの書籍を通して初めて知りました。POJOという言葉には少なくとも以下の2つの意味がこめられていると考えています。 特定のフレームワークの規約を知らなくても設計できるため初心者でも簡単に理解できる 継承関係やデザインパターンの適用など本来のオブジェクト指向の設計を自由に行える 前者はP
実践的な設計って、なんだろう？
Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計
フロントエンドJavaScriptにおける設計とテスト
今日話さないこと JavaScriptの基礎知識、jQueryの導入 気持ちいいUIやUXがうんちゃら CanvasやWebGLを使ったリッチでイケてるゲームの作り方
エラー処理とログ出力
ソフトウェアの開発において、エラー処理は、時には本来の機能よりも重要です。業務として開発するソフトウェアでは、本来の処理を行うためのコードよりも、エラー処理のコードの方が量が多くなることも良くあります。 ところが、実際のソフトウェアの開発では、エラーをどこでどのように出力するかについては、実装者任せになってしまうことが多いようです。ソフトウェア設計書を見ても、エラーの出力については記述されていないことも良くあります。実装が終わってから、最後に慌しくエラーの出力を組み込むこともあります。 エラー処理について考えてみると、たくさんの難しい問題があることが分かります。これらの問題を理解した上で、きちんとエラー処理の仕組みを考えないと、ソフトウェアの設計や品質にも、重大な影響が及ぶかもしれません。 エラー処理とログ出力は、本来、どのようにして行うべきなのでしょうか。 エラーを知らせる仕組み ソフト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
