FC2ブログ

某SEの日記

入力項目が多い検索処理

検索項目が多い画面を作成する時に困る問題の一つ。

パラメタライズドクエリでデータを取得すると検索項目が多い(入力必須ではない項目が多い)場合、普通に作ると莫大なSQLを定義してやる必要がある。
もしくはSQLを作成する時にパラメータから判断して可変にするという手もある。

それを一つのSQLで済ましてしまう方法(うまくいけば)

○項目Aと項目Bというテキストエリア(入力任意項目)に入力された値を検索項目としてSQLを書く際のWHERE文。

WHERE (A=@A OR @A='') AND (B=@B OR @B='')


こうすると各項目に入力値があればそれに合致するレコード、入力がなければその項目に関しては全行返すというつくりになる。

メリット:
・実装量が減る(項目が多いほど恩恵は大きい)
・クエリのリコンパイル回数の減少がはかれてパフォーマンスがよくなる。

デメリット:
・全項目に値が入らなかった場合でもWHERE文以下が評価されるので場合によってはパフォーマンスが悪化するかも。

要するにパフォーマンスは相殺(本当か?)と考えても実装量は減少させれるので覚えておいてよいテクニックと思われる。
スポンサーサイト



このページのトップへ

データ型の判定の仕方

C#の場合

if(object.GetType() == typeof("調べたいデータ型(*1)"))

*1:int,stringなどなど
このページのトップへ

ユーザーが削除できない場合(SQLServer)

SQLServerで作成したユーザを削除しようとすると削除できない場合がある。

データベース プリンシパルは、データベースのスキーマを所有しているので、削除できません。

このメッセージがでているということは削除しようとしているユーザーがデータベースの何かのスキーマを持っているため削除できない。
なので、まず次のSQLで削除しようとしているユーザーが持っているスキーマを確認する。

select
sysobjects.name,
sysobjects.uid,
sysusers.name
from
sysobjects
inner join sysusers on
sysusers.uid=sysobjects.uid
where sysusers.name='削除したいユーザー名'


このページのトップへ

プログラミング時に

Visual Studioで
プログラミングする時、もしくはフォームを作成する時に
ディスプレイを大きく使いたい場合に

Shift + Alt + Enter を押すと

コード部分、フォームデザイナ部分が広くなり、
もう一度押すと元のサイズに戻る。

ツールボックスやプロパティなどを残したままで
ワンタッチで切り替えたい場合に使うと
ちょっと便利。
このページのトップへ

C#(.NET)からのExcel操作

.NET(C#)からExcelを使うために
参照設定で「Microsoft Excel 11.0 Object Library
を追加した。

だが、それだけではうまく
Excel.Application を参照することはできない。

名前空間のインポートが足りないのかと思って、

using Microsoft.Office.Interop;

を指定してみたけど、これでもダメ。

次にAlias指定にしてみると
using Excel = Microsoft.Office.Interop.Excel;

ついにうまくいった^^

なんでこれだけAlias指定じゃなきゃだめなのかよくわからなかったけど、とりあえず事実だけを忘れないように書き留めておく。
このページのトップへ

保守性拡張性

非機能要件の言葉の定義を確認。

* 保守性とは:予想できなかった機能変更・追加を、最低限のコストで実施できること

[例] バグ修正、ミドルウェアの変更、新規機能の追加(修正個所の極少化、修正の影響範囲の限定、修正個所特定の容易さ[=トレーサビリティ])

* 拡張性とは:事前に想定することができる機能変更・追加を、最低限のコストで実施できること

[例] ビジネスルールの変更(料金計算など。拡張する個所を、プログラムを修正することなく拡張する仕組み)


一般的に、システム開発において、「保守」というと、障害対応、バックアップ、パッチ適用が考えられ、「拡張」というと、新規の機能追加、既存機能への修正、などが考えられる。


このページのトップへ

ビジネスロジックを実現するパターン

マーチンファウラー氏が中心になってまとめたPofEAAから学んだことを抜粋。

ビジネスロジックを実現するパターンについて。

1.「TransactionSctipt
トランザクションとして完結する処理(ビジネスロジックとデータの永続化処理)をすべて一つのメソッドの中にまとめて記述するパターン。

メリット:コードが非常に単純
デメリット:同じようなコードがいろいろなメソッドに散在するため、ビジネスロジックの再利用が困難。
→保守性、拡張性↓

2.「DomainModel
概念モデリングで定義したクラスをそのまま利用し、個々のクラスにビジネスロジックとデータを両方を持たせようとしたパターン。

メリット:モデルとコードの乖離が少なくて変更も比較的に容易に出来る。
→保守性、拡張性↑
デメリット:RDBに保存する際には高度なO/Rマッピングが必要。

3.「TableModule
データベースのテーブルごとにビジネスロジッククラスを実装するクラスを用意する。

メリット:ビジネスロジックを実装するクラスの導出が容易。O/Rマッピングも不要。
デメリット:テーブル構造が変わるとビジネスロジックを実装うするクラス構造も変更する必要がある。


このページのトップへ

ドラクエのSCEから任天堂への移籍

ドラクエSCEから任天堂に移籍したとのこと。
元鞘におさまったともいえるのかな。

FFはPS3で出すらしいし、
ドラクエの性質を考えればなんら驚くことはないことだと思う。
DSはかなり売れているし、
ビジネス的にもゲーム性から考えても当然かなというところ。

ドラクエはビックネームだからニュースになっているが問題の本質の一つとして
PS3用ソフトの開発コストの増大にゲーム会社がついていけてなかったのでは?
というのがあると思う。

PS3用の開発費はPS1の頃と比べると10倍から15倍とも言われてるらしい。
リアルな映像をだしたり高スペックな機能を使おうとするとそれくらいにもなるのだろう。
ただ、PS2の普及率が他ハードと比べるとダントツ高いこともあり離脱なんてすることは
ビジネス的に難しかったのでその波に乗るしかなかったと想像する。

ここでDSやWiiの任天堂のハードが登場した。
DSのソフトをみたところゲーム性やタッチパネルなどの
アイデアを重視した単純な(昔のファミコンなどの時代に近い)ものになっている。
でも、そのゲームが面白くて大ヒットを連発している。
DSはいつも品薄状態というくらい売れている。
となるとドラクエを作ってるスクエニなんてゲーム会社の大手よりも
もっと小さいところの方がPSからDSなどに移籍していくのではないだろうか。

上では経営的視点から見てみたが、開発者の視点からみてもSCEから任天堂に移る流れがあると思う。

少し単純化して考えると

SCE:リアルな映像、映画に近い
任天堂:ゲーム性、アイデア


というキーワードが導き出せる。

ここでITシステム的にみると
SCEの方は凝ったUIや画面デザイン、
任天堂はシステムの作り、アーキテクチャ
という風に結びつくように思える。

もちろんデザイナーの人もいるとは思うが、
ゲーム会社に入った人は自分のアイデアで
面白いと思ったものを自由に作りたいと思ってるのではないだろうか。

私はシステムの構造を考えるのは好きだが
凝ったUIとか作るのはちょっと・・と思う方だからの意見かもしれないが。

ユーザーの立場からいうともうそんなにリアルな映像はいらないかなーと思っていた。
技術指向に走りすぎるとダメという一例にもなるかも。
ついつい技術屋は技術にはしりすぎてユーザーが見えなくなるから気をつけねば。


このページのトップへ

アーキテクチャ確定作業について2

アーキテクチャ確定作業の
・非機能要件、前提・制約条件の定義。
・アーキテクチャ目標と推敲機能選定。
における注意点(学んだこと)を箇条書き

可用性に関する目安:
可用性99%の場合はサーバ構成がシングル(冗長化しない)でも可能と言える。
それ以上の可用性を求められるとデュアル構成にする必要がある。

トランザクションの定義について:
サーバーとのやり取りなのかRequestなのかユースケース単位なのかをしっかり定義しておく必要がある。
それによっては数字が大きく変わってきて揉める一因となるらしい。


アーキテクチャ目標:
・非機能要件に書いてあることをわざわざ目標にも重ねて書く必要はない(特に目標値等が変わらない場合)
・イメージを持たせるのが主目的なので多少抽象的でも可。
・アーキテクチャを狭めるような表現はしないほうがいい。
(実現方法を目標の内容に含めない)
・目標を測定できる何か指標があればベター。

推敲機能選定について:
選ぶ際には業務フローの先頭を選ぶという視点を頭の片隅にいれておくこと。
→後続機能の確認を先に行いOKをもらってものちに先頭の機能で修正が入った場合また確認が必要。単純に確認作業のコストもかかる(データ準備等)



このページのトップへ

ロングテール

ロングテールの本質について語られてたので
忘れないように復習しておく。

ロングテールは売れ筋(パレートの法則でいう売上下位80%)ではない商品も相当数売れる、
というAmazonの例がよく引き合いにだされる。
だが、本質は違う。
本質は「マッチング」である。

という。

そして、マッチングの種類としては
(a)個人と企業
(b)個人と個人
(c)個人と情報
とあるらしい。

要するにAmazonは出版会社や本屋の流通事情で利益が見込めない
売上下位80%の商品にも
検索機能やパーソナライズ機能によりマッチングを作り出した

ロングテール

ということか。

このロングテールの本質はマッチングという話はフムフムと納得できる。
以下ソーシャライズ、データベース極大化(AmazonやGoogleが持つ検索内容、商品の購入履歴)
となっていくのだろう。

iTunesMSなどでは音楽においてもロングテールが生まれていると聞く。
個人で楽しむことができる音楽ソフト購入においてはマッチング手段さえあれば
ロングテールは掘り起こせるだろう。
昨日カラオケを久々にしたから思いついたが、
カラオケにおいてはロングテールは成立しにくいだろうなーと。
個人に対してマッチングされても一緒にいく他者のもマッチングしてないと
カラオケは楽しめないしとかとか思ったりした。
まったくマイナーな曲ばかり歌っててもねー、協調性のない奴って思われるだけだし・・・。

少し本質がズレてきた気がしてきたf^^;

このページのトップへ

基本が重要

前回のエントリーでアーキテクチャ確定の作業における意識について思ったことをかいた。
アーキテクチャ説明書作成時の心構え

結局アーキテクチャ確定作業だけにとどまらずどんな作業においても重要かなと思われる結論になっていた。

アーキテクチャ確定というと高度な作業のイメージがあるが
基本は「当たり前のことを当たり前にやる
だからまぁそれは当然といえば当然のことかなと。

アーキテクチャ確定作業全般でほかにも思ったことは情報処理に関する基礎知識の重要性を改めて感じた。
基本情報処理の午前で出るような問題をテストで点をとれるだけでなく血となり身となっているような理解度があればなーと思うことがしばしばある。

第一弾として待ち行列を改めて勉強してみた。
サルでもわかる待ち行列

すごくわかりやすかったので忘れないようにリンクを貼っておく。
そのまま直接役に立つわけではないが、
基礎としてしっかりとした基礎知識がそなわってないといけないなーと最近痛感している。
テーマを決めてちょこちょこ基本情報を復習してみようかと。
このページのトップへ

アーキテクチャ説明書作成時の心構え

【事象を俯瞰してみることが肝要】

業務フローなどを読んで要件を理解して
アーキテクチャを考えていくとどうも具体的に考えすぎるきらいがある。

それは本作業における全般的な知識不足からくるものと
考えている。
どうしても木を見て森を見ず的なものになっていることにたびたび気づかされる。

業務を理解する際にはわかりやすく分解して具体的に考えることは業務理解には必須で必要なことであるとは思う。

今のところ
・業務を理解するタイムとアーキテクチャを考える時間を分けてみる
・具体的に考えてしまうのは仕方ないから常に俯瞰しなければと意識をどこかにおいておく
という風に意識しようとしている。



【悩んだらInputに立ち戻り、OutPutを意識する】
作業をすすめていると時折全体の中で何をしているのを少し見失い、
ベクトルがずれてしまっていることがままある。
どうしても手じかの作業に手一杯になると全体が見えなくなるものだ。

そういう時は行っている作業のInputとなる(アーキテクチャ目標設定作業の場合は前提・制約条件、非機能要件)情報に立ち戻ること。
あと行っている作業の成果物がどういう風に後工程として使われるかを意識する。
どんな仕事においても共通する考え方だけど、
作業にはいると視野が狭くなりつい忘れがちになることである。
これも意識をしなければ・・・・。


どんなことでも基本は同じだなーと。
重要なことはその基本を意識することかなと。
筋トレでも鍛える筋肉を意識すると効果は全然違うし。
少し話が違うかもと思ったりもするけどf^^;







このページのトップへ

StartForce

StartForceというネットに接続するだけでデスクトップアプリケーションが動作できるというものを教えてもらった。

StartForce


StartForce.jpg


もちろんインストールなし。ユーザ登録するだけ。無料。

Wordみたいなアプリとチェス、メッセンジャーが使えるようだ。
Ajaxで実装してるらしい。
ふ~~んこんなのできんだー。
やはりAjaxもちょっと勉強してみないとなー

GoogleもオンラインでExcel風味のアプリをつくったり、
ウェブ進化論的にいうと「こっち側」から「あっち側」からの転換が確実に進んでるというところか。

今のところ仕事では関係してこなそうだけど、いずれこういうのも関係してくるのかなと。
なんとなく触れておいて
なんとなくキャッチアップしとこうっとという感じ。


このページのトップへ

前提・制約条件、非機能要件の抽出

アーキテクチャドキュメント作成の第一段階として
前提・制約条件、非機能要件の抽出
を行っている。

今日はそのレビューを行った。
初めての作業であったので、
レビューで多くのことを学んだ。
それを列挙してみる。

1.抜き出した前提・制約条件、非機能要件の根拠の出処(ヒアリングorドキュメントの名前等々)

2.記述するのは要件を実現する手段ではなく要件自体を書くこと(例えば、「SSL」と書くのではなくて「パスワードを平文で送信しない」とする)

3.可用性、性能が重要視されない場合でも「応答時間」「スループット」「キャパシティ」「稼働率」「MTTR」「MTBF」の数値は出しておく。

4.非機能要件をヒアリングする際は工夫する。
・稼動率を聞く場合は
(○)1ヶ月で何時間システムがとまっても許容できますか?
(×)稼働率は99%は必要ですよね?
SSLを適用しますか?というような手段からは聞かない。アーキテクチャを狭めるだけ。パスワードを保護する必要はありますか?というような聞き方にすべき。


このページのトップへ

アーキテクチャ説明書作成(12月~1月)

12月からプロセストレーニングというものを行っている。

擬似プロジェクト(過去の実プロジェクトの資料を元に)にて要件定義まで完了しているところからアーキテクチャ説明書を作成するということが目標である。

1月末に完了予定である。

作業としては
1.前提/制約条件、非機能要件の抽出

2.アーキテクチャ目標の設定

3.推敲機能(重要ユースケース)選定して推敲計画を作成

4.アーキテクチャ案作成(選定理由も)

5.アーキテクチャ設計資料作成

6.プロトタイプ実装

7.評価レポート作成

8.アーキテクチャ説明書作成

といったのが大まかな流れになる。



このページのトップへ

.NETでIISにデプロイする時に

Webアプリケーションを作成しようとIISにデプロイした際に

ディレクトリへのアクセスが拒否されました.ディレクトリの変更の監視を開始できませんでした.

その際のトラブルシューティングのひとつ。

ASP.NETの失敗談

原因
ASP.NET が監視しているファイルのファイル パスの階層内に 8 文字を超える名前のディレクトリがある場合,ファイルの変更を検出するには,プロセス ID と偽装されたユーザー ID が,その階層内のディレクトリすべてに対して特定のアクセス許可を持っている必要があります.



まだこんな文字数とかが関係してくるなんて・・・。


このページのトップへ

サイトのページアイコンを付ける方法

サイトのページアイコンを付ける方法
(FireFoxとかで)


<head>タグの間に下線のコードをいれる。

<Head>
<link rel="shortcut icon" type="image/x-icon" href="image/favicon.ico" />
<Head>


※表示のためタグは全角にしています。

このページのトップへ

実装技術トレーニングで覚えた使えるプロパティ

EndOfStreamプロパティ
現在のストリームの位置がストリームの末尾の場合は true。それ以外の場合は false。
ストリームを読む際のループ条件に使える。

Int32.TryParce(string s,int i)
s が正常に変換された(int型に)場合は true。それ以外の場合は false。
int型以外のものをキャストしようとしても例外がでない。

TextFieldParserクラス
構造化されたテキスト ファイルを解析するためのメソッドおよびプロパティを提供します。
TextFieldParser オブジェクトは、構造化されたテキスト ファイルを解析するためのメソッドおよびプロパティを提供します。テキスト ファイルを TextFieldParser で解析することによってテキスト ファイルが反復処理されます。また、ReadFields を使用することによって、テキストからフィールドを抽出 (つまり、文字列を分割) できます。

TextFieldParser では、区切り形式と固定幅の 2 種類のファイルを解析できます。このオブジェクトが公開するプロパティには、区切り形式のファイルでしか意味を持たないもの (Delimiters、HasFieldsEnclosedInQuotes など) や、固定幅のファイルでしか意味を持たないもの (FieldWidths プロパティ) があります

このページのトップへ

プロフィール

ibarakinakano

Author:ibarakinakano
FC2ブログへようこそ!

最近の記事

最近のコメント

最近のトラックバック

月別アーカイブ

カテゴリー

ブロとも申請フォーム

この人とブロともになる

アクセスカウンター

ブログ内検索

RSSフィード

リンク

このブログをリンクに追加する