2014年9月9日開催の"AWS Cloud Storage & DB Day"で使用した講演資料です。 以下のURLからもダウンロードすることができます。 http://iy-h.com/03/aws-storage-day-2014-09-09.pptx
一部の組み込み系システムを除けば,業務系システムはすべて何らかのデータベースを使っており,データベースを中核にしてシステムができあがっています。データベースを押さえることは,システムの中核を押さえることにほかなりません。したがって,データベースをどのような手順で,何に基づいて設計するのかを知っておくことは,システム構築に携わるすべての人にとって不可欠です。 Part4は,データベース設計の上流工程である概念設計と論理設計にフォーカスして説明します。こうした作業はデータ・モデリングと呼ばれます。業務要件定義を解きほぐして,システムの中核となるデータベースの論理構造を決定することが目的です。 データ・モデリングの重要性については,私たちが取り扱うビジネス・システム(業務システム)が,台帳中心のシステムであるということを考えれば明らかです。江戸時代などの時代劇を見ていると問屋の番頭が蔵の中で帳簿
最近は様々なサービスでWebAPIが提供されています。普段の開発をする中でもシステム連携などでAPIを作る機会が出てくるのではないでしょうか。 WebAPIの中でもREST APIなんてものもよく聞くのかなぁと思います。REST APIの設計は色々と奥が深く、なかなかおもしろい技術です。 今回はそんなREST APIを設計する上でのポイントをご紹介していきます。この記事では実装よりも設計思想的な部分を書いています。次回以降にもう少し実装に近いレベル記事を書いきます! REST APIは、「Representational State Transfer(表現状態の転送)」というアーキテクチャスタイルに従って設計されたAPIのことです。RESTの概念は2000年にRoy Fieldingによって提唱され、Webアーキテクチャにおける一つの重要な原則として広く認識されています。 じゃあ、REST
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さん
WebAPIの仕様を記述する方法はいくつかあると思う。 普通に日本語で記述する JSON Hyper-Schema、WADL、RAML、Swaggerなどを使う 仕様書の代わりにプログラムを書く HTTPメッセージそのものを記述しておく でも、文法にばらつきがあったり、読みにくかったり、ツールのセットアップが面倒だったり、どれもイマイチな所があって、手軽な方法が欲しいと思っていた。 何気なくcurlコマンドのオプションを調べていたら、「もうこれでAPIドキュメント扱いにしちゃえばいいんじゃね?」と思えてきたのでメモしておく。 curlコマンドのおさらい curlコマンドはlibcurlの付属コマンドで、最近のUnix系OSなら大抵最初から入っていると思う。コマンドの詳細はmanを読んでいただければ。 cURL - How To Use (マニュアルページ日本語訳) curlコマンドのオプシ
SaaSシステムを開発しているみなさま、お元気でしょうか。 SaaSシステムというといわゆるWebサービスよりももう少しBtoBの雰囲気が漂ってまいります。 SaaSシステムでは契約者(ここではテナントと呼ぶ)が複数いて、テナント毎に複数のログインユーザーやロールが存在するのが一般的です。そして当然ながらテナント毎のデータは漏洩・混濁が許されない高いセキュリティが求められます。 SaaSシステムの構築はスケーラビリティにおいても100テナント程度から始まりゆくゆくは数千、数万テナントまで少なくとも線形にスケールするアーキテクチャを開発当初から求められ、さらに突発的な大規模テナントも問題なく吸収したいという要求があります。 その要求を満たす設計・開発・保守・運用をやっていくのは当然ながら簡単ではありません。 というわけで今日はマルチテナントアーキテクチャのお話です。 世に出る情報がとっても少
移転しました http://please-sleep.cou929.nu/20130121.html
こんにちはこんにちは!! はまちや2 (@Hamachiya2) ブロガー、クラッカー。特技は洗濯、趣味は破壊、苦手なことはプログラミング。 WEB+DB PRESS のお便りコーナー担当。 「はまちちゃん」とかで適当にググってください。 無料で プレミアム機能を 使う方法 見つける時間がありませんでした。 何話そう? プログラムは苦手だし… セキュリティとか興味ないし… そんなわけで普通のことを話します。 本日のテーマ: 『ふつうのformを使いたい』 <form> 電話番号はハイフン抜きの半角で…(はいはい) フリガナはカナで… (カナで名前を学習してしまうのが嫌だけど…) 郵便番号は前と後ろに分けて… (めんどくさいなぁ…) 住所は全角で… (あーはいはい…) … (できた!) (これで送信、と…) ※エラー:住所を正しく入力してください (え、なんで!?) ※住所は全角で入力してく
ユーザービリティに関して少し復習したので メモっておきます。初心忘れるべからずという 事で・・・Webサイトは基本的にユーザビリティ を考慮したレイアウトやコンテンツが理想です。 もちろんケースバイケースではありますが、 これは全共通して言える、という事を忘れない ようにメモ書き。 というわけで、申し訳ないですけど目新しい事は何一つ無い内容です。 そもそもこのブログ自体ユーザビリティを考慮した設計とは言えません(「やっちゃダメなこと」もしています)ので全然説得力ない感じです。 いろいろとテスト&エラーをして行きたいのでご了承下さい。 はじめに 正しいユーザビリティはコンテンツによってケースバイケースだと思いますが基本的には僕はヤコブ・ニールセンの考えに従っています。 全ての項目は「すべてが正しい」ものではありません。100のサイトがあれば100通りのユーザビリティが考えられるはずです。場合
Webディレクターから見る、デザイナーさんなら当たり前にやってる事で 是非取り入れて欲しいという視点で書いてます。 グリッドレイアウト 目線の誘導にはグリットの設計は重要です。 Webなら特に縦位置を意識する必要があるかなと思います。 奇麗なグリッドが引かれたデザイン(線がある/ない、かかわらず) は、とても視認性が高く、目の誘導を行いやすいです。 シンメトリー 対照性なデザインは人の頭に一定のルールを認知させる事ができます。 それ故に、次のページなども惑わす事なく閲覧ができます。 また、単体的にも目線の誘導がされやすく、 かつ見た目も奇麗ですっと入ってくると思います。 アシンメトリー 逆に、ネガティブスペースを上手くつかい、 目線のジャンプ率を高くしたレイアウトも効果的です。 目的と用途で使い分けが重要かと思います。 タイポグラフィとビジュアルイメージ 和文書体、欧文書体で使い分け、
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって? データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く