お仕事めも

やっと上巻読み終えました(遅

上下巻合わせて大きく２部構成で、
１部(ほぼ上巻)は、フラット化をもたらしたものは何か、
作者が世界を回って実感したフラット化の事例紹介でした。
DELLの事例、アメリカの会計士の事例、インドで起こっている事・・・等々

読んでみて私の不安は増大するばかり・・・
今のままの自分では絶対にソフトウェア業界に残れない！！と強烈に実感しました。
今までも漠然とは感じていましたが、はっきりと突きつけられた感じです。
＃今までさんざん言われて来ただろう(#ﾟДﾟ)って
　　お叱りの言葉を頂きそう・・・

仕事の道楽化(自己研鑽)、会社への貢献、
社会への貢献、世界と会話できる事等々・・・
もっともっと努力しないといけません。

フラット化の負の部分について
作者がどのような考えを持っているかが、
上巻の最後(第2部の始まり)ぐらいから始まります。
ここらへんから俄然面白くなってきます。
フラット化に反対する意見も載せつつ、
フラット化を推し進めるべきという作者の考えが述べられています。
今日、没頭しすぎて乗り過ごしそうになりました＾＾；

明日から下巻に入ります。
はやく下巻を読みきらないと・・・

一言で言うと・・・
「実装は無視」だそうです。
今日、会社の方に教えて頂きました。

この方、すごく業務フローの提案が上手なんです。
一緒に打合せに行った帰りにコツを聞いてみたら、
こんな答えが返ってきました。
※詳細設計段階とかでの打合せじゃなく、
　業務フローも含めた、基本設計段階の話です。

あまりに端的すぎるので補足説明。
・業務がどうあるべきかに集中
・どう作ろうという考えは頭からぬく(しない)
・実装は業務の理想系が出た後で考えて、
　実現可能かどうかを判断すれば良い。

は～、確かにその通りです。
私は、本格的に業務設計に携わってまだ１年ですが、
ついつい実装レベルで話を聞いてしまっていました・・・

反省・・・

そういえば使えるのかなぁと調べていたら、
MSDNにエントリがあったのでメモ。
Visual C# で Excel を自動化して、配列による範囲内へのデータ入力および範囲内からのデータ取得を行う方法

少し使ってみたけど、
Excel.Workbooks.Openの引数の省略ができないみたいで、
少しへこんでいます。
使い方間違ってるのかな・・・

考えなくinner joinを利用しないようにしたいものです。

[おさらい]

** inner join **
  SQL文 : from A inner join B ・・・
  動作    : A・Bテーブルの一致するレコードのみが抽出される

** left join **
  SQL文 : from A left join B ・・・
  動作    : Aテーブルのレコードは全て抽出される
              BテーブルはAテーブルと一致するレコードのみが抽出される

上記のように、
inner joinの方が抽出条件としては「きつい」ですよね。
でも、結構考えなしにinner joinにする人が多いですo(｀ω´*)o

外部結合がよくわからないから、inner joinにする人が多いのかな？
きちんと後のテストで「片方のテーブルにしかデータがないケース」みたいなテストをして、
仕様としておかしくないかどうか確認してくれれば良いですが、
考えなしにinner join書く人は、そこまでケースあげないパターンが多いです。

inner joinはよく考えて!!!!と
声を大きくして言いたい今日この頃です・・・

開発中のシステムでちょくちょく見かけるもので、
愚痴エントリしてみました。

見ていて少し悲しくなりました。

戦争体験していない私から、
戦争体験された方へお伝えしたい。

私たちは戦争をしたいわけじゃありません。
子供を戦地に送りたいわけでもありません。

ただ、大東亜戦争は当時の日本としては、
せざるを得ない状況であったのではないかと考えています。

アメリカから本当の独立をしないといけないんじゃないか？と考えています。

この先、日本が本当に戦争をしなければならなくなった時、
武器を持ち、家族、故郷を守る覚悟を持たなければならないんじゃないか？と
考えています。

これって軍国主義なんでしょうか？
自分を自分で守りたいと思う事が軍国主義？

すごくデリケートな問題なので、悩みます・・・
体験者の方の心中も察したいし・・・

現在、SQLServer2005を開発で利用しています。
一時的なデータコンバートの為、スカラ値関数を作成する事にし、
開発しておりましたが、デバッグの方法がわからず悩んでいました。

PL/SQLの時は、ファイルにログ吐いてデバッグしたなぁと思い、
「PRINT」命令が使えるかも！！と試してみましたが、
どーも使えません。実行時エラーがでます(下記)
"メッセージ 443、レベル 16、状態 14、プロシージャ ***"
"副作用のある演算子または時間に依存する演算子を関数内の 'PRINT' で使用することはできません。"

なんか根本的にPRINTの使い方を勘違いしている様な気がしないでもないです T_T

ふと、VisualStudio2005上でやればできんかなぁと思いトライしてみると、
すごいですね、デバッグ実行が可能じゃないですか!!
いやー、これは良いです。デバッグ楽々です。

忘れない為にメモしときます。
1. VisualStudio2005起動
2. サーバーエクスプローラーの「データ接続」に、SQLServerへの接続を追加
3. 該当のスカラ値関数を右クリックし「関数にステップイン」を選択
4. パラメーターを受けるスカラ値関数なら、パラメーター入力ダイアログが開くので入力する
5. ステップ実行

PRINTの件は、また後日調べよう・・・

-- 追記 -- 15:04 --
VisualStudio上だと、SQLブロックを認識して、
クエリビルダでSQL書けますね。
私は手書き派ですが、SQL苦手な人にもやさしいですね。
これまた便利です。

昨日、本が届きました～^^
今日から帰りの電車で読んでいきます。

いつも興味深い記事を書いてらっしゃるarclampさんのblogで
こんな記事が投稿されていました。

フラット化する世界
http://www.arclamp.jp/blog/archives/000917.html

上・下巻ある本ですが、
一度読んでおくべき本じゃないでしょうか。

ちなみに、私はフラット化した世界には懐疑的です・・・
恐怖を感じてると言った方が良いかな。

読んだら、また感想書きますね。
・・・今月中に読めるかな

文字列を何回も連結する場合は「StringBuilder」を利用した方が、
実行速度が速くなりますよね。

気になったので、どのくらい早いのか試してみました。

-- 以下　実行したテストメソッド --

public void test()
{
 　　　　string str       = "";
 　　　　StringBuilder sb = new StringBuilder("");

 　　　　Console.WriteLine(DateTime.Now.ToString());
 　　　　for (int i = 0; i < 100000; i++)
 　　　　{
  　　　　　　　　str = str + "A";
 　　　　}
 　　　　Console.WriteLine(DateTime.Now.ToString());
 　　　　Console.WriteLine("len={0}", str.Length);

 　　　　Console.WriteLine(DateTime.Now.ToString());
　　　　 for (int i = 0; i < 100000; i++)
 　　　　{
  　　　　　　　　sb.Append("B");
 　　　　}
 　　　　Console.WriteLine(DateTime.Now.ToString());
　　　　 Console.WriteLine("len={0}", sb.Length);

}
-- ここまで --

-- 実行結果 --
2006/08/01 17:21:46
2006/08/01 17:21:54
len=100000
2006/08/01 17:21:54
2006/08/01 17:21:54
len=100000
-- ここまで --

さすがに10万回連結するとかなーり速度が違いますね^^;
8秒違うというのは驚きでした。
思わぬボトルネックを作らないように気をつけないといけないですね。

時間があったら、なぜなのか詳しく調べてカキコしてみようかな。

出勤時、A○RAの釣り広告をみたら、
「Web2.0で働く」ってありました・・・

まだ買ってないけど、
「次のGoogleはどこだ」みたいな事が書いてあったので、
Googleっぽい所で働こう特集なのかなぁと思います。

しかし「Web2.0」って言葉がどんどん独り歩きしてるような気がします。
最近、Web2.0が付く本もすごく増えましたよねぇ。
ただの流行なのでしょうかね・・・

ちょっと笑いました^^;