仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ

前回、MongoDBでSNSつくるぞという記事を書いてから随分時間がたってしまいました。単に私がだらけていたということもあるのですが、一番ひっかかって時間を取られていたのが、MongoDBにおけるスキーマ設計の考え方です。 いまだに試行錯誤中ではありますが、現時点において私がこうあるべきと理解しているところをアウトプットしてみたいと思います。 １．One to Many のケース たとえば注文と注文明細のケースを考えてみます。RDBで1対多のリレーションを設計する場合、 というように、注文明細を別テーブルにするのが普通かと思います。しかし、ドキュメント指向のMongoDBにおいては、RDBと違ってオブジェクト内に柔軟なデータ構造を実現できるため、 というように一つのCollection内にデータを埋め込んでしまうのが、パフォーマンスの点からも良しとされています。 ただし、以下の2点について

「サイボウズ・アドベントカレンダー」の8日目です。ちょうど真ん中まできました（これまでの記事一覧）。 こんにちは。kintone 開発チームの刈川です。いきなりですが、皆さんはどのくらいの頻度でアプリやサービスをリリースしていますか？ 1週間？ 1ヶ月？ 1年？ 規模によると思いますがクラウドサービスではリリースのスピードが大事です。せっかくいいアイデアを思いついたのに、それを実現するまでに果てしない時間と労力がかかるとしたら…。ユーザの意見を取り入れるまでに半年も一年もかかっていたのでは、ユーザは他サービスに移ってしまうかもしれません。そこで今回は、私たち kintone チームが取り組んでいる「スピーディな開発・リリース」のための手法を簡単に紹介したいと思います。 アイデアを形にする アイデアというのは形にするまでがゴールです。開発現場ではこのことをリリースと呼び、リリースをするまでに

これまたマニアックな苦笑。 DB Patternsでは、ありがちなデータベース設計を共有することができる。 フォトアルバムだったらこういうテーブルがあって、こことこのキーが共有されるとかなんとかをグラフィカルに見ることができる。 まだ投稿も少ないし、いろいろ突っ込みどころもあるのだが、初心者のうちは確かに悩むところだし、便利なサービスではなかろうか。 ユーザー登録をするとすでにあるパターンをForkしたり、新しく作ったりもできるようだ。興味がある方はどうですかね。

リンク先は「UNIQUE INDEXを振った列に複数のNULLを投入できること利用して、ユニークであるべきユーザIDの使い回し(=退会したユーザのIDを新規ユーザに開放する)を実現する」という話。 アクティブなユーザ名はユニークにしたいけど削除されたユーザの情報は残したい。でも削除済みユーザテーブルは作りたくない とかいうワガママを発揮したい時にdeleteフラグに使えないかなーなんてだめですかそうですか。なんか他にまともな方法無いですか…。 MySQLのこういうのっていかがなもんか - 桝原翔市的博客 いやーこれはまともな方法じゃないでしょうか。 「NULLはNULLに一致しない」のが絶対の原則なのだから、NULLを使ってUNIQUE制約を回避するのは裏技でもwork-aroundでもない、正当なテクニックでしょう。 私はTM派なので実表上にnullを発生させる設計はしないが、Nulla

働いてますか。労働はご褒美です。どうも、ロージーです。 案外放っておくとタスクがどんどん溜まったりするし、何よりプロジェクトの走り始めの時期とか、洗いだしたらすごい大量のタスクが山積みになって「うげげ」って気分になりますよね。 基本的にはエンジニア向けの話なのですが、まぁタスクを Trac で管理したり Redmine で管理したりすると、基本的にマイルストーンとプライオリティぐらいしか「なにからやるべきか」という指標にならなくて、どうしたものか悩んでしまいます。 その日の朝に棚卸して選定すべきなんですが、まぁそういうときに使う、こんな評価軸もあるんだよ、ということで、僕自身の備忘録です。 1. 4つの『空気感』 まず、タスクを積んだ時点、いわば「これやらなきゃな」とした時点での、そのタスクに対する自分の空気感をラベル分けします。 カンタン フツウ ムズカシイ ダルイ 上の4つです。カンタ

ついに、2011.04.11　XEAD Driverの正式版が 公開 されました。それを記念して 【渡辺さんに目の前でシステムを作ってもらっちゃおう！】 というちょっと無茶な企画を行いました。初めて参加して頂いた４名を含む16名にお越しいただきました。本当にありがとうござ...

特許庁が進めてきた基幹系システムの刷新プロジェクトが失敗に終わり、開発に投じた約55億円が無駄になってしまったことが、先週相次いで報じられました。 ［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro 朝日新聞デジタル：費やした５５億円、水の泡に　特許庁がシステム開発中断 - ビジネス・経済 このプロジェクトに「内閣官房GPMO（ガバメントプログラムマネジメントオフィス）補佐官」の肩書きで2009年まで民間から参加した萩本順三氏（現 匠BusinessPlace 代表取締役社長）がFacebook上で当時を述懐しつつ、失敗の要因を分析していました。今後、失敗プロジェクトを繰り返さないためにも、重要な発言として本人の許可をいただいてまとめました。 特許庁の情報部門に幾度も中止を迫った 萩本順三氏の発言の主要な部分を引用します。 内閣官房GPMO（ガバメントプログラムマ

ずいぶん時間があいてしまったけど、大規模コンシューマ向けサービスRDB設計の続き。 僕はこのプロジェクトを自分のRDBの知識を使って革新してやろうと思って臨んだ。 しかし結果として逆に、コンシューマ向けサービスに最適化されたRDBの使い方について教わることになった。 ※ あと、KVSでいいじゃんって言ってる人もいるけど、それはKVS導入の苦労を知らない人だと思う。KVSの苦労は後で書く。 僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はDBやフレームワークの設計とアーキテクトっぽいことを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止

納期が、予算が、バグフィックスが、性能、デザイン、インタフェース、使い勝手、保守が、可用性が、移行にマイグレーション、稼働率が、糞だ。そもそも要求を満たしとらんまともに動かない糞システムが、なぜ莫大な銭金かけてできあがってしまうのは、なぜか? アナリスト、コンサル、PM、SE、プログラマ、テスタ、ヘルプデスク、メンテ、ユーザー、そして経営者と、それぞれの立場から言いたいことは山ほどある。それぞれの立場から「これぞ真の原因!」と叫びたいのも分かる。経営者を除き、全てのキャリアをやってきたから。だから、自信をもって断言する。糞システムができあがる、最も根っこの原因はこれだ。 一つ前の仕事をしている それぞれの立場で「やるべきこと」は分かっている。だからこそ、そのインプットが体を成していないことが明白なのだ。仕方がないので、自分で「インプット」相当を作るハメになる。 例えばプログラマ、プログラミ

16. iPhone UI • iPhone UI Photo Albums California Title • Cupertino Glendale Los Angeles • Palo Alto San Diego San Francisco • UINavigationController Santa Clara • UITabBarController Santa Monica Sherman Oaks Thousand Oaks Contacts Recents Keypad Most Recent Item

※より具体的な例は こちらの新しい記事 を参照してください。 シーケンス図とは？ シーケンス図とは，オブジェクトの動的な相互作用を表現するためのUML図です。 オブジェクト指向は，一言で言えば「役割分担」なので，オブジェクト同士のコミュニケーションが重要です。 シーケンス図では，オブジェクト同士のコミュニケーションによるインタラクション（相互作用）の様子を明確に表すことができます。 シーケンス図においてインタラクションは，メッセージ送受信のシーケンスとして図示されます。 クラス図がクラスの静的な定義とするなら，シーケンス図はオブジェクトの動的な振る舞いの定義と言えます。 3秒で分かるシーケンス図の描き方 まずは登場するオブジェクトを並べます。 長方形の中に「オブジェクト名：クラス名」と書いてオブジェクトを表します。 オブジェクト名とクラス名のどちらか一方を省略してもかまいません。 オブジェ

文部科学省「プログラミン」は1024x768ピクセル以上のモニタ解像度でご覧ください。 ご覧いただくためには、最新版のFlashPlayerをインストールのうえ、 JavaScriptを有効にしてください。 「Adobe Flash Player」の最新版はアドビシステムズ社のWebサイトより無料でダウンロードできます。 インストール方法については、配布元の説明をお読みください。

新人にソフトウェア開発の作業手順を教えていると、思いも寄らぬ質問を受けて戸惑うことが有る。例えば、先日はこんな質問を受けた。 「仕様書はどの程度まで書けばよいのですか？」 あまりにストレートな質問なので何と答えるべきか一瞬戸惑ってしまったが、考えてみれば仕様書の記載をどの範囲でどのような粒度でどこまで書くべきなのか？という基準は何も存在していないのだ。品質管理の規定に従ってレビューや照査・承認のプロセスは存在するものの、それは書いた後で行われるプロセスだし、ソースコードと違って「動作する」「動作しない」という明確な境界線も存在しない。内容にモレや矛盾が存在する仕様書は珍しくないし、書き手によって仕様の構成や内容が違うことも有るのだ。 しかし、実際問題として仕様書を上手に書く人はいるし、チーム内には失敗事例を元にまとめた仕様書ガイドラインも存在している。だから「完璧ではないけれど、それなりに

この半年、巨大なシステムの開発で学んだことの1つは、 SIという業態の中で再利用が必要なのは、部品ではなくチームであるということ。 チームに蓄積するノウハウや暗黙知こそ再利用するべきで、 案件の度に体制の伸縮を繰り返すやり方では、いくら部品化や共通化を進めたって効率もへったくれもあったもんじゃない。 部品の再利用は確かに可能で、非機能的な部品やフレームワークは活躍するんだけど、 ドメインオブジェクトのレベルでの再利用はやはり難しいし そもそも部品やフレームワークは使いどころを知っていて、設計や試験を省力化するところまでやってこそだと思う。 システム開発の工程の中で、製造工程はどう考えても一部分であって設計＋試験が圧倒的に長い。（保守期間はもっと長い） 設計や試験に効果を発揮するのは、部品よりもチームだ。 例えば、僕らの現場ではSOAにも取り組んでいて、権威と呼べるような人たちがその設計をや

2010年6月26日に行われたイベント、オープンソースカンファレンス2010 Hokkaido内のセミナーで使われた発表スライド「PHPで大規模ブラウザゲームを開発してわかったこと」Read less

ウェブサイトやブログの作成・運営で、避けておきたい35個のミスをnetjellyから紹介します。 List of Web Design Mistakes You Should Avoid 下記は、各リストを意訳したものです。 ※訳者注： 一部過激なものは表現を少し和らげています。 はじめに ウェブサイトやブログを開発・作成する際に、避けた方がよいミスをリストアップしました。 1. 作るだけでは終わりではない ウェブサイトは開発・作成だけでは終わりではなく、公開・運営する必要があります。そして、オンラインやオフラインでウェブサイトの告知に手間や時間をかけることはいっそう必要になります。もし、あなた自身があなたのサイトについて時間をかけないなら、他の誰もそれはしないでしょう。 2. 広告をコンテンツに混ぜない 広告をコンテンツに混ぜると、短期的にはクリック数を増やすかもしれません。しかし、ユー