第一の大罪（1） ～ データベースアプリケーションのパフォーマンスにおける七つの大罪
第一の大罪は''データベースの物理設計''に関するもので、たとえばスキーマ設計の問題、テーブルの列の順序、インデックス付け、データベースページサイズの選択など、パフォーマンスに悪影響を及ぼしかねない重要な要因はいくつも考えられます。今回の記事では、SQL Anywhereのデータベース設計にまつわる具体的な問題と、ドメイン（定義域）の概念に関する内容を取り上げていきます。 ドメイン（定義域）とは ドメインの概念は、E. F. Coddが発案した最初のリレーショナルデータモデルに含まれています。Chris Dateは、彼の重要な著書 [1, pp. 81] の中でドメインを次のように定義しています。 次に、ドメインという言葉を、すべて同じ型の、スカラー値の名前付きの集合と定めることにする。たとえば、サプライヤー番号のドメインは、サプライヤー番号として取り得るすべての番号の集合になり、出荷数量
Silverlightで行うデータ処理の基本
はじめに Silverlightはバージョン2以降 .NET Frameworkの機能がサポートされ、単なるリッチなWebサイトを作成するためのものという認識から、業務アプリケーションを作成することができるプラットフォームとしての期待が高まっています。特に2009年11月に米国のロサンゼルスで行われたProfessional Developer Conference（PDC）で、Silverlightのバージョン4が発表になりましたが、多くの機能が追加されているなかで、業務アプリケーション開発向けの機能が多く含まれているのは注目に値するべきポイントです。 業務アプリケーションを開発する上で非常に重要となるのがデータの処理だというのは、異論はないかと思いますが、Silverlightで実装するためには多少の決まりごとを認識することが必要です。Silverlightにおける、この性格を紹介する
「レガシーコード改善ガイド」のススメ 第1回：レガシーコードの定義、テストの重要性とは
「レガシーコード」とは何か 最初に1つ質問です。皆さんは、「レガシーコード」と聞いて何を想像するでしょうか？ 多くの方はCOBOLなどで書かれたメインフレームで動くコードを真っ先に思い浮かべるのではないかと思います。しかし、本当にそれだけでしょうか？ ここでは「レガシーコード」という言葉を『何年も前に誰かが作り、内容が複雑で何をしているのかよく分からず、まともな仕様書もない』というコードを指すものとします。そう考えると、必ずしもメインフレームだけの話ではなくなります。この記事を読んでいる皆さんなら、そのようなコードを少なからず目にしていることでしょう。 現在の業務システムは、Java EEや.NETなどの基盤上に構築される、いわゆるオープンシステムが主流になっています。このようなオープンシステムであっても、構築されてから既に5年以上経過していることが珍しくなく、何度も手が加えられたコードは
Webサービスの開発にフレームワークが必要な理由 ～Perl/Ruby/PHPユーザーのためのMVCフレームワーク入門～
はじめに 前回はRuby/PHP/Perl、それぞれの言語ごとにフレームワークとテンプレートエンジンについて比較を行いました。これにより、現在のWebアプリケーション開発に求められる仕組みを俯瞰できたと思います。 今回はこの比較を基に、Ruby on Railsのこれまでの動向を追いながら、『どのようなフレームワークが自分にふさわしいのか』を考えていくことにします。また、最後に前回の記事で掲載しきれなかった各言語のフレームワークを紹介します。 「Perl/Ruby/PHPユーザーのためのMVCフレームワーク入門」これまでの記事 第1回「効率的なWebアプリ開発の定石」 第2回「言語別フレームワークの比較」 フレームワークについて調査・分析を フレームワークの目的は、汎用処理を系統立てた仕組みの中に内包することで、プログラマの作業の効率化とWebアプリケーションの保守性を高めることにあります
効率的なWebアプリ開発の定石 ～Perl/Ruby/PHPユーザーのためのMVCフレームワーク入門～
はじめに 一般的なWebアプリケーション開発では、「Webクリエイター」と「Webプログラマ」という役割が存在します。Webクリエイターは画面表示に関するデザインやマークアップを担当し、Webプログラマは、動的処理機能の構築を担当しています。最終的にそれぞれのリソースの結合が行われ1つのサイトが完成します。 最近では、“リッチクライアント”というキーワードで語られる豊かなユーザーインターフェースを持ったWebアプリケーションの開発がトレンドとなっており、かつてサーバサイドでの技術を発揮していたプログラマにもクライアントサイドの知識や技術が要求されるようになってきています。こうした状況の中で、Webプログラマが効率的な開発を行い、新しい技術に挑戦するために今までの構築手法や開発工程を見直す必要がでてきました。 本稿では『システムの構造的に優れた設計』だけではなく、『あらゆるユーザーに配慮され
Silverlightとサーバーサービスの連携
Silverlightはブラウザにダウンロードして動作するアプリケーションです。業務アプリケーションでメインとなる、データの更新や検索、他システムとの連携といった処理を行うには、Silverlightとサーバーサービスで連携する必要があります。本稿は、そのための基礎について解説します。 はじめに Silverlightはブラウザにダウンロードして動作するアプリケーションです。 つまり業務アプリケーションでメインとなる、データの更新や検索、他システムとの連携といった処理を記述するためには、Silverlightとサーバーサービスとの間で通信を行い、データをやりとりする必要があります。 Silverlight 1.0ではJavaScriptしか利用できなかったため、AJAXでよく利用されるXMLHttpRequestオブジェクトを使用してサーバとの通信を行っていました。Silverlight
統合言語クエリ（LINQ/Language Integrated Query）入門
はじめに .NET入門コラムの連載記事にようこそ。今回は、Language Integrated Query、略してLINQを中心に紹介します。LINQの概要とLINQに関する誤解について取り上げ、そのベースとなる言語機能を簡単におさらいしてから、LINQを使用した例をいくつか説明します。今後の連載ではLINQを何度か取り上げる予定ですが、今回がその第1弾です。 Language INtegrated Queryの概要 これまでの.NET入門コラムの記事の多くは、私が最初に書いたいくつかの記事（「Database Independent Data Access」など）までさかのぼって考えてみても、必ずと言っていいほどデータへのアクセスと処理を話題にしていました。一般に、データはデータベースに格納されますが、データにアクセスして処理する方法には、データファイル、イベントログ、Windowsの
技術のジェンガ現象の恐さを本気で考えてみよう
皆さん、ジェンガというゲームをやったことありますか？ 積み木の1つを引っこ抜いて一番上に乗せていく。順番にこれを繰り返し、崩れたら負け。技術におけるジェンガ現象とは……。 相対常識 今回から相対常識について触れていきたいと思います。相対常識。ある限られた条件下で通用している、本質から離れたものと以前説明しました。では、相対常識はどのようにして生まれるのでしょう？ 相対常識の要因1：閉鎖 1つが「閉鎖」です。ある組織や仲間、個人の場合もあります。そこだけで信じられているしきたりのようなものです。そこのリーダー的立場の人が言ったことがルールになります。メンバーはそれがさも世の中の常識であると信じてしまっている状態です。 相対常識の要因2：模倣 もう1つが「模倣」です。あるトレンドを模して「じゃあこれにも採用してみようよ」と似せた設計をしたりします。例えばコピー機。紙サイズや倍率、濃さの切り替え
人間という生物の常識からITを考えてみよう
普段意識しない常識 受話器は耳につけて話をする機械ですよね。キーボードは手の指で叩きますね。当たり前のようですが、「なぜ？」と考えることはあまりないものです。 ――なぜ、受話器は耳につけるのでしょうか？ それは音は耳で聞くからです。 ――なぜキーボードは手の指で叩くのでしょうか？ それはたくさんのボタンを叩くのに手の指が一番都合がいいからです。 極々当たり前の答えが出ました。ほぼこれは人間という生物の絶対常識と呼んでいいと思います。当たり前だからこそ、普段そんなに考えることはないんですね。 前回、世界のどこに行っても変わらない常識を「絶対常識」と呼ぶことにしました。1＋1＝2などがそうです。絶対常識には、数学的、物理的、生物的、歴史的など、いくつかのカテゴリーがありそうです。ここでは生物的な視点からエンジニアの役割を考えてみたいと思います。 エンジニアと五感 ここでいう生物とは……。そうで
エンジニアを惑わす「常識」の正体を知ろう
この連載は、"常識"のやっかいさを知り、そこからエンジニアという仕事について考え、最終的によいモノを作っていこう、という試みです。 連載名の「常識をぶち壊す」とは、非常識がよいという意味ではありません。後述する常識の特性を知り、守るべきところは守り、壊すところは壊し、できるだけフラットな頭で世に貢献しましょうという思いを込めています。 第1回を読んでいない方はまずご一読ください。そして湧き上がってきた思い、感情、衝動を感じながらこの第2回をお読みください。 今回はエンジニアを惑わす「常識」の正体を明らかにしていこうと思います。 常識の持つ力 心理学まで踏み込むと複雑なことになりますので、できるだけ簡略化して考えていきます。 第1回「コーディングスタイルの常識をぶち壊せ」はいかがでしたか？ 面白かった、ムカついた、納得した、呆れた、ほくそ笑んだ、憤慨した、勉強になった、説教したくなった、自身
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【MSDN Hacks】 .NETエンジニア必見の情報活用術 8選
Oracleの階層問い合わせ一覧
翻訳書「レガシーコード改善ガイド」の注目トピック一覧
言語別フレームワークの比較 ～Perl/Ruby/PHPユーザーのためのMVCフレームワーク入門～ (1/6)：CodeZine（コードジン）
Windows PowerShell 活用編一覧
コーディングスタイルの常識をぶち壊せ
ぶち壊せ常識！ リアルエンジニア道一覧
Visual Studio 2010はこうなる！ ― tech・days 2009セッションレポート