「会社サイト、飲食店のWebサイトの設計を考えてみよう」という勉強会でお話してきました。（ゆるゆるカフェ） Webサイトを持つ事はビジネスにおいては必須となっています。 しかし、他のWebサイトを模倣し、しっかりした設計の元に作られていないものも多く存在します。 自社や自分達のお店のWebサイトを作る際に、何が大切でどのようなポイントについて考えていくと良いのか考えてみましょう。
【スライド】Webサイトの設計を考えてみよう - よつば手帖
「会社サイト、飲食店のWebサイトの設計を考えてみよう」という勉強会でお話してきました。（ゆるゆるカフェ） Webサイトを持つ事はビジネスにおいては必須となっています。 しかし、他のWebサイトを模倣し、しっかりした設計の元に作られていないものも多く存在します。 自社や自分達のお店のWebサイトを作る際に、何が大切でどのようなポイントについて考えていくと良いのか考えてみましょう。
Web APIを作るときに考えること。 - パルカワ2
この記事はPepabo Advent Calendar 2014の11日目の記事です。 前日は、tnmtさんのVagrantのshell provisionerでApacheのビルド済tarボールをOSバージョン毎に作る術でした。 はじめに 今回は、Web APIを作るときに考えることをまとめました。 本当は、社内向けに資料を作っていて、社内の勉強会とかで話せればいいか〜って考えていたんですが、アドベントカレンダーのネタが本当になくて困っていたのでこれを使います。 対象者 APIを作る時、と書いてますが、クライアント側の人にとっても知っておく必要があることなので、サーバ側の人・クライアント側の人両方が対象者です。 APIを作るときに考えること 「APIを作るとき」と言っても、色んな状況があります。 まずはそれを絞ります。 APIの種類 プライベートAPI アプリのAPIなど使う人が限定され
クラスの命名のアンチパターン - Qiita
昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 ImageInfo, AccountData, etc. Info って何やねん? Data って何やねん? ImageInfo って Image とはどう違ふねん?? FooInfo や FooData よりも好ましいかもしれない名前の例: FooAttribute, FooProperty, FooMetadata, FooDescription FooConfiguration, FooSetting, FooParameter FooResult, FooStatistics, FooSummary FooBuffer, FooList, FooCollection, ... ProductListItem, TranslationTableEntry, etc. Prod
やさしいクラス設計「活きのいいクラス見つけます」by Java and C#
1日目 --- クラス設計とは ここではクラスとその設計について書いていきます。 オブジェクト指向プログラミング言語の一つであるクラスベースの言語において、クラスの設計はプログラム設計の重要なものの一つです。 例えば、Java や C# はクラスベースのオブジェクト指向言語であり、そのクラス設計は重要です。 クラスとは？ まず、クラスとは何でしょう。 クラスとは、具体化されたインスタンスオブジェクトの一部を抽象化してカテゴライズしたオブジェクトです。 例えば、数値の 1や 2 のようなオブジェクトを考えます。このオブジェクトは + や - に反応するオブジェクトです。 これらのオブジェクトで値を抽象化したオブジェクトを考えます。これを integer オブジェクトと呼んでみます。この integer は + や - に反応するオブジェクトで値が抽象化されている オブジェクトの総称になりま
NoSQLデータモデリング技法
NoSQLデータモデリング技法.markdown #NoSQLデータモデリング技法 原文：NoSQL Data Modeling Techniques « Highly Scalable Blog I translated this article for study. contact matope[dot]ono[gmail] if any problem. NoSQLデータベースはスケーラビリティ、パフォーマンス、一貫性といった様々な非機能要件から比較される。NoSQLのこの側面は実践と理論の両面からよく研究されている。ある種の非機能特性はNoSQLを利用する主な動機であり、NoSQLシステムによく適用されるCAP定理がそうであるように分散システムの基本的原則だからだ。一方で、NoSQLデータモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティック
【DB概論】正規化の手順
正規化とは、データを一元管理するための理論です。 1データ1箇所の原則を実現するために、1970年にE.F.Codd氏がリレーショナルモデルの理論として提案しました。正規化の理論は、データの冗長性を排除し、更新時の整合性を維持しやすくすることを目指しています。 具体的には、属性間の関連性を分析し、属性の最適なグループ化を図ることを目的としています。 一般には第3正規化まで行えば十分といわれていますが、本来は、あてはまる場合にはきちんと第5正規化まで行う必要があります。 まず、正規化の処理をする際によく出てくる関数従属という用語の意味を復習しておきましょう。 ◎ 関数従属とは ある属性Aの値が決まると他の属性Bの値が一意に決まるとき、「属性Bは、属性Aに関数従属である」（A→B）といいます。 完全従属とは、2の属性A、Bの間でA→Bが成立し、Aが複数の属性の集合で成り立っている場合、Aのいか
渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 - ＸＥＡＤ
概要 XEAD Application Driverは、企業システムを開発するための軽量プラットフォームです。同梱されているXEAD Application Editorを用いて仕様書を作成するだけで、XEAD Application Driverがその内容を読み込んでシステムを動的に立ち上げます。開発作業の生産性向上のために、また、業務知識学習のためにご活用ください。 インストーラ(Win専用)のダウンロード β版について XEAD Application Driverには、最終的に７種類程度の「処理パターン」が組み込まれることになりますが、現在はそのうちの４種類しか完成していません。それゆえに、サンプルとして同梱されている販売管理システムも未完成です。 改善と不具合修正の履歴（一部） 感想、バグ報告、改善提案を歓迎します。バグについては、バージョンナンバーとともに再現手順を
実行可能な仕様書は“設計できるプログラマ”が書く
実行可能な仕様書は“設計できるプログラマ”が書く：“実行可能な仕様書”を作る！（2）（1/3 ページ） 前回、「実行可能な仕様書」を実現するための鍵が「機能パターンの確立」だと述べた。それらのパターンを有効活用するためには、DBを正規化するとともに、ビジネスロジックを機能側からDB側に移行しなければいけない。そして、ビジネスロジックを的確に仕様化するためには設計スキルとともにプログラミングスキルが必要になる。 DBを正規化することのインパクト 前回、業務システムに含まれる機能（データ処理プログラム）をいくつかの「機能パターン」に整理することで「実行可能な仕様書」が実現可能になると説明した。機能パターンごとに仕様情報のデータ様式を定め、これを処理する「仕様翻訳エンジン」と「仕様エディタ」を用意すれば、「実行可能な仕様書」のための基盤が完成する。この基盤を便宜上「アプリケーションドライバ（アプ
クラウド時代に求められる 「実行可能な仕様書」とは？
Excel方眼紙の問題 業務システム開発の世界には「Excel方眼紙」と多少軽蔑的に呼ばれるものがある。行間と列間を細かく設定したExcelシートのことで、さまざまなドキュメントの汎用様式とされる（図1）。特にソフトウェアの「仕様書」を書くために多用されている。 表計算ソフトはもともと表形式の数値計算や、これに付随する文字列操作に特化したソフトウェアだ。にもかかわらず、日本においては文書作成や仕様書を書くためのツールの“デファクトスタンダード”と言っても良いほどに「Excel方眼紙」は普及している。罫線へのこだわりと同様に、これはどうも日本だけでの現象らしいことから、一部では、日本の「格子偏愛文化」が生んだものではないかとも推測されているようだ。 Excel方眼紙上で仕様書を作成するのは面倒ではあるが、セル結合やフォント指定を駆使すれば思った通りにまとめられるし、印刷してもそれなりにキレイ
信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
ずいぶん時間があいてしまったけど、大規模コンシューマ向けサービスRDB設計の続き。 僕はこのプロジェクトを自分のRDBの知識を使って革新してやろうと思って臨んだ。 しかし結果として逆に、コンシューマ向けサービスに最適化されたRDBの使い方について教わることになった。 ※ あと、KVSでいいじゃんって言ってる人もいるけど、それはKVS導入の苦労を知らない人だと思う。KVSの苦労は後で書く。 僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はDBやフレームワークの設計とアーキテクトっぽいことを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止
テスト可能なUI設計パターン – 第１回 Androidテスト祭り 発表資料 - the sea of fertility
2011/8/6 第１回 Androidテスト祭りの発表資料を公開します。.NETクラスタという先入観を持っていただきたくなかったので、自己紹介スライドは最後にさせていただきました。でも非常に空気のよい場だったのでそんな配慮は不要だったかもしれません。 反省点としてはやはり伝え方です。設計パターンに対する意識がすでにある方には届くみたいですが、あまり今まで意識していない方に、どうやって今後伝えていくべきか、きちんと今後考えていきたいと思います。 一応補足として、WPF/SilverlightでのPresentationModelパターンの実装パターン?であるMVVMパターンについて、どういった必然性がWPF/Silverlightにあるのかはこちらに書いてありますますので、興味を持っていただける方はどうぞ。 MVVMパターンとは？ わんくま同盟東京勉強会 #60 セッション資料 the
［Windows Azure Platform編］DBサイズの制約を避ける
クラウドコンピューティングでは、クラウド事業者が集中管理する極めて多数のサーバーやネットワーク機器といったリソースが小口に分けられ、複数の企業や個人利用者に比較的低いコストで提供されます。サービス利用者にとっては、自分でハードウエアなどのインフラを用意することなく、必要なときに、必要な分だけリソースを安価に使えることが魅力です。 クラウドコンピューティングは大きな拡張性を備えているので、たとえアクセスが集中したとしても、リソース量を自在に増やすことができます。ただし、そうしたメリットを享受するには、クラウド事業者ごとに異なる設計のルールを守らなければなりません。 本連載では、マイクロソフトが提供するサービスの「Windows Azure Platform」に焦点を当て、その「デザインパターン」について解説をします。ここでは、クラウドの特性を生かしたり、制約を回避したりするための設計ノウハウ
「ＤＢ構造を見直さない」というアンチパターン - 設計者の発言
システム開発プロジェクトの失敗原因のひとつに「システム刷新時に、ＤＢ構造を見直しせずにプログラムの言語だけを置き換える」というものがある。アンチパターンとまでは言えないとしても、クリティカルな問題をはらんでいる。にもかかわらず、いくつかの理由からこの方針は無批判に受け入れられるか、場合によっては歓迎さえされる。 なぜか。まず、システムの問題がＤＢ構造（帳簿組織）の悪さから来ているという認識を、ユーザーやシステム部門が持ちにくいため、その見直しが明示的に求められないからだ。また、必要なスキルを持った技術者が少ないため、開発側として（大手SIerでさえ）なるべく見直ししたくないのが本音だったりするからだ。いかにも問題がありそうに見えても「求められないから手をつけない」という理屈で通す。また、ＤＢ構造が多少おかしくてもエレガントなクラス構造でカバーできるから一刻も早くプログラミングさせてほしい―
「ＤＢ構造の前にＵＩを決める」というアンチパターン - 設計者の発言
画面定義書があるのにまともなＥＲ図がない。業務システムの開発プロジェクトがそういう状況を一瞬でも経由したのであれば、大きなリスクを抱えていると考えたほうがいい。小さな案件でない限り、デスマーチに陥る公算が高い。 喩えるなら、高層ビルの「上モノ」の図面が詳細に出来上がっているわりに「土台」の図面がないようなものだ。その点を問われ、 「ああ、ボーリング調査も土台設計も後でしっかりやるから大丈夫です。土台の図面なんてほら、専門的すぎてお客さんが見てもピンと来ないじゃないですか。お客さんが知りたいのは土台とかではなくて上モノのデザインなんですよ。なんといっても顧客の納得感が大事です」 なんて言う建築士はいない。「顧客の納得感」が重要でないと言うつもりはないが、それだけを基準にして高層ビルを設計できるのなら苦労はない。専門的な仕事の難しさは、顧客には見えないし想像もできない膨大な部分の整合性をはかる
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
【DB概論】データベースシステムに求められる要件
【DB概論】データベースシステムに求められる要件：できるエンジニアになる！ ちょい上DB術・基礎編（1） デキるエンジニアになるためには、DB技術の基礎は必須です。本連載では、豊富な実例と演習問題で、プロとして恥ずかしくない設計手順を解説します。DB設計のポイントとなる汎用的なケースを紹介しているので、通常の業務とは異なる場合でも応用できる「共通の考え方」を身に付けられます。 デキるエンジニアになるためには、DB技術の基礎は必須です。 「使える」システムを構築するには、データベース設計がと非常に重要です。先人が遭遇したトラブルを避けられるかどうか、システム構築やアプリケーション開発が成功するか否かは、データベース設計にかかっているところが大きいです。 本連載では、豊富な実例と演習問題で、プロとして恥ずかしくない設計手順を解説します。システム構築において「どの工程で、どのような観点からデータ
人間のために分かりやすい実用的なURLを設計する方法
URL Design [ad#ad-2] 下記は各ポイントを意訳したものです。 はじめに URLを設計する理由 トップレベルのセクションは重要 URL構造を増強する方法 クエリの文字列 URLにはASCIIを URLは検索エンジンのためにではない URLは合意 全てがURLを持っているべき リンクはリンクらしく 再利用できないURL 素晴らしいURLの例 おわりに はじめに あなたは、URLの構造を設計するのに時間をかけるべきです。この記事を読んだ後で、あなたに一つだけ覚えておいてほしいことは、URLの構造を設計するのに時間をかける、ということです。 URLデザインは簡単ではなく、正しい解決方法があると言うことはできません。しかしそれは、他のデザインと同じです。良いURLデザインがあり、良くないURLデザインがあり、そしてその中間もあります。 しかし、それは素晴らしいURLデザインを作るこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
第2回 データベースモデリングのためのEclipseプラグイン
できるエンジニアになるための ちょい上DB術・基礎編 インデックス － ＠IT自分戦略研究所
【DB概論】データベース設計の目的・まとめ
