kなんとかの日記 このページをアンテナに追加

2010-04-27

SSD の風が吹けば Intel が儲かる

| 09:06 |  SSD の風が吹けば Intel が儲かる - kなんとかの日記 を含むブックマーク

話は変わって:

とはいえ、HDDSSDそのもののアクセス性能を比較した場合は10倍から20倍性能が違うのに対し、実際の業務を想定したOLTP処理性能の比較ではそれが2倍〜3倍程度に収まりそうであるのにはやや肩すかしを食らった感じもします。

no title

これはそんなもんじゃないかなあ。データベースではディスクアクセスがボトルネックとはいえ、性能の 90% を占めているわけじゃないからね。

たとえば処理にかかる時間全体のうち、ディスクアクセスにかかる時間が 60% を占めていたとする。ここで SSD によってディスクアクセスが 10 倍高速化したとすると、全体の処理時間は:

40% + 60% * 1/10 = 46%

もとの処理時間の 46% になる。SSD でディスクアクセスが 10 倍高速化しても、処理全体の時間は約 2 倍速くなっただけ。もし 20 倍高速化したとしても:

40% + 60% * 1/20 = 43%

もとの処理時間の 43% になるだけ。10 倍が 20 倍になっても、全体の性能としてはもとの 3 % しか違わない。

こうしてみると、SSD 導入による効果は「高速化」よりも「HDD というボトルネックがなくなる」ことであり、それはイコール「CPU が速くなれば速くなるほど性能が目に見えて向上する」ということなんだと思う。

SSD を導入
 ↓
HDD というボトルネックがなくなる
 ↓
CPU の高速化がそのままシステムの高速化につながる
 ↓
CPU の費用対効果が高くなる (速い CPU を買う理由ができる)
 ↓
高くても高速な CPU が売れる
 ↓
Intel ウハウハ

そう考えると、IntelSSD を手がけている理由が見えてくる。今までは、単に Intel の製造設備が余っているから SSD 製造に乗り出したんだと思ってたけど、実は高性能な CPU を売るための地道な戦略の一環なのかもしれない。HDDボトルネックになるから高性能な CPU が売れない … それならそのボトルネックをなくしてしまえばいいじゃない、そうすりゃ高性能な CPU が売れるでしょ?

そこまで考えているなら Intel スゲー。

flat8flat8 2010/04/27 10:19 確実にIntelはそこまで考えていると思います。で、ある程度SSDが普及したらSSD自体の製造からは手を引くでしょうけど。

通りすがり通りすがり 2010/04/27 11:31 クライアントコードの処理時間(コスト):バックエンドの処理時間(コスト)の考察無しには、SSD時代になったとしても一概にスクリプト言語不利とも言えないのではないでしょうか。

yuki_heroyuki_hero 2010/04/27 12:10 まぁ、巨大な企業は、社会基盤そのものにも目をつけていますから...

cpwcpw 2010/04/27 12:43 アプリケーションサーバは分散が容易とういうことを忘れてはいけませんよ。サーバも安くなってきてますしね。人件費の方が高コストです。

GoatGoat 2010/04/27 13:02 ボトルネックになるのはストレージだけではないでしょう。PHPはもちろん、Ruby、Python、Perlも多くはウェブ系のシステムに使われていると思いますが、そういう場合ではネットワークがボトルネックになってきます。
そして、スケールアップよりもスケールアウトという流れの中でますますその傾向は強くなっています。

仮にコードがボトルネックになったとしても、多くの場合はアルゴリズムに問題があるのであって、そこを改善してオーダーを変えてしまえば、5倍〜10倍の差なんて問題にならなくなりますし、そもそもタイムクリティカルなミドルウェアでは今でもCやC++が主流なのでSSDがスクリプト言語に与える影響はほとんどないのではないかと思います。

通りすがり通りすがり 2010/04/27 13:44 インタプリタかコンパイルかで速度が極端にかわるようなら、単純にPerl,PHP,Ruby,Python等で静的コンパイルできるようにするんじゃないかなぁ〜?

muhamuha 2010/04/27 13:51 逆にますますインタプリタが使われると思う。 人件費より高いの無いでしょ

とことことことこ 2010/04/27 14:38 確かにトランザクションが多いところはそうなるかもしれない、
よく知りませんがスクリプト言語の作成効率が高ければ、そんなにトランザクションがおきないところは安く構築するために有効だと思われるので、そんな劇的にシフトはしない気がする。

TaruryunTaruryun 2010/04/27 17:08 元のテストの結果は、僕が読む限り、
処理能力が頭うったのは
『DBサーバの』CPUに読めるんですが・・・。

もし息の根止められるとしたら、フロント用アプリケーションを書くための言語もろもろではなく、「SQLというスクリプト言語」でしょう・・・

apollo440apollo440 2010/04/27 21:46 いやいやいや、”全”プログラマーって。ストレージ使うのが当たり前じゃない世界もあるし、もうちょと範囲狭くして欲しい気が。

あと、(人気の)スクリプト言語は、「使いやすい」じゃなくて「遊びにはよい」かと。

nonamenoname 2010/04/28 00:56 C++, javaで生活している者から一言


スクリプト屋(笑
が必死だなw

neginegi 2010/04/28 18:04 仕事でjavaからphpに移って6年くらいだけど、
スクリプト言語は
実行速度やコード書く速度とかより
バグが激しくてテストが半端ないよ。
誰かが書いたソースを使いたく無いし、
使おうと思うとソースの細部まで読まなきゃならなくなる
せめて返却値くらいは型を決めてくれ。
NULLの場合とBoolの場合とがあるって糞でしょ?
あとExceptionもだね。

俺もOCamlが何で流行らないのか疑問なんだよね。
OCamlは関数型言語で手続き型から移行しやすい言語だと思う。
まあデフォルトで日本語使えねーって事もあるかもね。
camomileも開発止まってるのかな?
他はHaskellに期待してます。

スクリプト屋は一度、静的型付けの関数型言語をかじった方がいいと思うよ。

noricyannoricyan 2010/04/29 09:12 言語を叩く人は、決まって使う人間を叩くんだよね。

そもそもそもそも 2010/05/04 17:37 C++みたいに簡単で便利な言語がすでにあるじゃない。

2010-01-11

OracleがSunを買ったのはMySQLを潰すため?

| 10:37 |  OracleがSunを買ったのはMySQLを潰すため? - kなんとかの日記 を含むブックマーク

これ読んで初めて気づいたけど、OracleがSunを買収した本当の目的はMySQLを手に入れることだったのか。いくらLarryのワンマン会社でもSunを買うのはどうかと思ったけど、MySQLを買うのが目的なら話はわかる。

昔聞いた話だと、OracleのHQは、機能が似ているPostgreSQLは大して気にしてないけど、機能が少ないかわりにOracleより高速なMySQLはかなり脅威を感じていたらしい。「Oracleより高速」ってだけでも脅威だけど、MySQLが普及することで「実はOracleほどの高機能はいらないんじゃないか」と顧客が考え始めるのがいちばんの脅威だったんだろうね。それを潰すことができるなら、Sunを「買いたたく」ぐらいは安上がりだったのかもしれん。

なお個人的に、SunはCiscoに買われてほしかった。ちょうどCiscoはサーバ市場に参入したところだったし、Sunの「The Network is The Computer」というvisionはCiscoとも合うよね。Oracleによる買収はつまんないけど、Ciscoによる買収なら個人的に歓迎だった。

2009-02-04

MySQL では unique key が NULL を無視する

| 01:04 |  MySQL では unique key が NULL を無視する - kなんとかの日記 を含むブックマーク

MySQL では unique key を指定していても NULL があると無視されるようだ。

たとえば次のテーブルでは、name と deleted_at の組に unique key を指定している。

create table test1(
  id         integer        primary key auto_increment,
  name       varchar(100)   not null,
  deleted_at datetime,
  unique key (name, deleted_at)
);

なのに、同じ値の組み合わせを入れてもエラーにならない。

mysql> insert into test1 values(null, 'aaa', null);
mysql> insert into test1 values(null, 'aaa', null);
mysql> insert into test1 values(null, 'aaa', null);
mysql> select * from test1;
+----+------+------------+
| id | name | deleted_at |
+----+------+------------+
|  1 | aaa  | NULL       | 
|  2 | aaa  | NULL       | 
|  3 | aaa  | NULL       | 
+----+------+------------+

まじっすかー。勘弁してくださいよ MySQL さん。unique key の意味ないじゃん。

#これって標準的なSQLの仕様なんかな。

kmachukmachu 2009/02/05 07:12 「ソフトウェア工学」の適用先が(言語の開発のような)高度な仕事なのかどうかは、議論の余地があるかもしれませんね。

pekepekesamuraipekepekesamurai 2009/02/05 08:37 unique ですが、たしかOracleでも同じような感じだったかと。(null重複許可)

はじきたい場合は、not null をいれるか、default とかで妥協するとかですかね。

tanotano 2009/02/05 10:31 SQLの標準仕様ですね。

顧客ID|名前|あだな(任意)
のようなカラムで取り合えず、「あだな」にNULLを入れとくけど、
あだなの登録時に重複されると困るのでユニークにしておくとか。

null重複不可がほしい場面はnullの代わりにアプリで固定値つっこむのがよいと思います。

まっさちゅーまっさちゅー 2009/02/05 10:42 開発という言葉でひとまとめにしすぎじゃないかな。アーキテクチャはアートだと思うんだけど、それを実際のコードに落とし込む作業は特にアートである必要はないと思う。

tmtmstmtms 2009/02/05 11:19 null=null も偽なのでそういうものです。

とおりすがりとおりすがり 2009/02/05 11:33 削除日でuniqueにする場合は0をいれてます。

kwatchkwatch 2009/02/05 19:48 うおー、SQLに詳しいみなさん、どうもありがとうございます。
これがSQLの標準なのはわかりましたが、個人的にかなり困った仕様です。
今使っているORMが、「deleted_atがnullなら生きているデータ、そうでなければ削除されたデータ」と見なしているので、not null default 0 とかできないんです。
どうしよう、ORMを改造するしか。

kwatchkwatch 2009/02/05 19:57 kmachuさん:
例が2つとも天才により過ぎているので勘違いさせてしまっていると思いますが、それほど高度でない場合でも個人によって生産性や品質に大きな違いがある点は変わらないと思いますので、「属人性を排除すべきでない/できない」という結論は変わらないと思います。

まっさちゅーさん:
アートかどうかは関係ないです。個人による差が大きければ、アートであろうとなかろうと属人性を無視すべきではないです。あとソフトウェア開発では自動化しやすいので、誰にでもできるような仕事はすぐになくなって、より高度な仕事しか残らないと思います。誰にでもできるような仕事が残っていること自体が問題と見なされるのではないでしょうか。

beyondseekerbeyondseeker 2009/02/05 20:52 「従来のソフトウェア工学は、属人性を排除して開発者の能力を均一化しようとしている」というのは興味深いですね。このような主張をしている文献をいくつか提示していただけると、さらに議論の幅が深まるかもしれませんね。

kwatchkwatch 2009/02/05 21:55 beyondseekerさん:
たしかにそうですね。僕は「ソフトウェア工学は属人性を排除しようとしている」というのは共通認識として得られていると思ってましたが、そうでもないかもしれません。
文献となると学者ではないのでわからないですが、「ソフトェア工学 属人性」でぐぐるとそれなりにヒットしましたので紹介します。

http://techon.nikkeibp.co.jp/article/NEWS/20060217/113414/
> ソフトウエア開発から属人性を排除して科学的・工学的な手法で開発しよう,という考え方が伝統的なソフトウエア工学の立場だが...

http://topse.jp/dl/pdf/JISSEN-Oct-11-07.pdf
> ソフトウェア工学とは『ソフトウェアの開発、運用、および保守に対する系統的で規律に基づいた定量的アプローチ』[SWEBOK2004]であり、属人性を排除して一定の品質を保証すること(高品質)、および、生産性の向上(大規模・多品種)に寄与する。

https://camwe001.nagaokaut.ac.jp/syllabus/syllabus/search/SyllabusInfo.do;jsessionid=4DEB871C3A681B1271AEC299FCFD29E1?mode=print&nendo=2008&kogikey=nbB2506860
> 情報処理システムを構成するソフトウェアを,人間の経験や直感といった属人性に頼らずに,均質,高品位に開発・管理することを目指す「ソフトウェア工学」について,その考え方と手法に関する知識を修得する。

これでいかがでしょうか。これでもまだ疑問に思われるようでしたら引き続きコメントしてください。

beyondseekerbeyondseeker 2009/02/06 00:21 ご回答ありがとうございます。

先ほどおいらも google で「ソフトウェア工学 属人性」で検索してみましたが、793 件ほどヒットしました。確かに、ソフトウェア工学は属人性を排除するという内容が見受けられますね。なるほど。納得。なにやら疑問か少し見えてきた気がします。

気になるポイントは、下記の2つの問題に対して Yes と答えるか、 No と答えるかです。

1.ソフトウェア工学が、「ソフトウェア開発」から属人性を排除せよという意図を持っているか?
2.ソフトウェア工学が、開発者の能力を均一化しようとしているか?

ちなみにおいらの考えですが、1についても2についても、ケースバイケースだと思っています。

たとえば、ヒューマンエラーを回避するための研究(例:テストの自動化の研究)であれば Yes だと思いますし、開発チームの適材適所に関する研究であれば属人性は前提条件なので No だと思います。2については、、、Yes の主張をするネタが思い浮かばないのですが、それを否定する理由も見つかりません。大半の研究に関しては、No なのではないかなと思っています。

しかし、

1.ソフトウェア工学の「あらゆる主張」が、「ソフトウェア開発」から属人性を排除せよという意図を持っているか?
2.ソフトウェア工学の「あらゆる主張」が、開発者の能力を均一化せよという意図を持っているか?

という問いであれば、おいらは No だと思います。

kwatch さんや皆さんがどう思われているのか、ぜひ教えてくださいー。
m(_ _)m

ちなみに、ソフトウェア工学という分野については、定義に曖昧さが残っているようなので(※)、「深く」突っ込まないほうがシアワセになれる予感w。
※. 分野の曖昧性と論争 http://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E5%B7%A5%E5%AD%A6

kwatchkwatch 2009/02/06 00:55 > 1.ソフトウェア工学が、「ソフトウェア開発」から属人性を排除せよという意図を持っているか?
> 2.ソフトウェア工学が、開発者の能力を均一化しようとしているか?

私感ですが、両方ともYES

> 1.ソフトウェア工学の「あらゆる主張」が、「ソフトウェア開発」から属人性を排除せよという意図を持っているか?
> 2.ソフトウェア工学の「あらゆる主張」が、開発者の能力を均一化せよという意図を持っているか?

だれもそんな極論してません。

> 大半の研究に関しては、No なのではないかなと思っています。

このような主張をしている文献をいくつか提示していただけると(以下略)
というか、属人性を積極的に活かそうとしている分野がソフトウェア工学にあるならぜひ知りたいです。

beyondseekerbeyondseeker 2009/02/06 02:43 回答ありがとうございます。

ここで、kwatch さんの主張に関する私の理解をまとめてみますので、間違っていたら教えてください。

1.ソフトウェア工学に関する研究の多くが、「ソフトウェア開発」から属人性を排除せよと主張している。
2.ソフトウェア工学に関する研究の多くが、開発者の能力を均一化せよと主張している。
3.その主張の出典は、文献以外の何か。


以下、ご質問への回答です。

---
[引用]このような主張をしている文献をいくつか提示していただけると(以下略)

情報の齟齬があるといけないので、念のために確認させていただきます。先ほど私は、「属人性を排除せよ」および「開発者の能力を均一化せよ」という主張を「していない」研究が大半だということを言いましたが、これは「属人性を排除するな」および「開発者の能力を均一化するな」という主張をしたわけではありません。

さて、文献について。

プログラミング言語に関する文献の例として「C Programming Language」を上げてみます。「属人性を排除せよ」および「開発者の能力を均一化せよ」という主張は含まれていません。

アーキテクチャ系に関する文献の例として「Patterns of Enterprise Application Architecture」を上げてみます。「属人性を排除せよ」および「開発者の能力を均一化せよ」という主張は含まれていません。

開発方法論に関する文献の例として「Extreme Programming Explained」を上げてみます。さまざまな価値やプラクティスを導入することにより開発者に制約をかけてはいますが、やはり「属人性を排除せよ」および「開発者の能力を均一化せよ」という主張は含まれていません。

ソフトウェア開発プロジェクトマネジメントに関する文献として「The Art of Project Management」 を例にしても、「属人性を排除せよ」および「開発者の能力を均一化せよ」という主張は含まれていません。それどころか、Communication and Relationships や How not to annoy people といった章を割いて非常に人間的な話題に言及していますし、チームメンバのスキルの種類の違いや能力差の扱いについても、「除外せよ」ではなく、どのように扱うべきかを How organizations impact planning の章で詳細に説明しています。


---
[引用]というか、属人性を積極的に活かそうとしている分野がソフトウェア工学にあるならぜひ知りたいです。

情報の齟齬があるといけないので、念のために確認させていただきます。私は、「属人性を積極的に活かそう」とは一言も言っていません。

でも、ネタがないわけではないので上げます。

例えば、デマルコのピープルウェアでは、不服従の社員を積極的に扱う方法について述べています。

小野さんのブログの「プログラマー風林火山(http://blog.livedoor.jp/lalha/archives/50065532.html)」は、エンジニアを風・林・火・山に分類し、その長所と短所を把握して、チームとしてのスキルセットのこれからを考えていくということを述べています。ブログの冒頭で述べられているように、ソフトウェア開発の経験を積み重ねることによって得られた情報をベースにしていることから、このネタはソフトウェア工学に分類可能と言えます。


以上、よろしくお願いします。
m(_ _)m

通りすがり通りすがり 2009/02/06 02:54 細かい文句だけど、Rubyの例に関しては、あれは「Rubyの仕様がむちゃくちゃで、レベルが低い」から、他人が介入しづらいということもあることには注意する必要があると思う。言語処理系であっても仕様がきっちり書かれてさえいれば、過剰に属人性に頼る必要はないと思うのだが。

kwatchkwatch 2009/02/06 04:06 beyondseekerさんは、何が言いたいんでしょうか。
ソフトウェア工学の定義について語りたいなら、それはこのエントリの主題ではないのでご自身のブログでやってください。トラックバックは歓迎します。

> 1.ソフトウェア工学に関する研究の多くが、「ソフトウェア開発」から属人性を排除せよと主張している。
Yes。排除せよ、というよりは排除できる、という感じですが。
> 2.ソフトウェア工学に関する研究の多くが、開発者の能力を均一化せよと主張している。
Yes。均一化せよ、というよりは均一化できる、という感じでしょうか。
> 3.その主張の出典は、文献以外の何か。
これは紹介したリンクでは満足されてないってことでしょうか。大学の講義で使われている資料でもだめというなら、どのようなものを出せば満足いただけますか?
なお「ソフトウェア工学 属人性」だけでなく「ソフトウェアエンジニアリング 属人性」や「CMM 属人性」などでも検索してみてください。それでもだめだ満足できない、というなら、こちらとしてはお手上げです。

> これは「属人性を排除するな」および「開発者の能力を均一化するな」という主張をしたわけではありません。
だれもそんな解釈はしてないので安心してください。単に何を主張したいのかが見えないだけです。

>「C Programming Language」
>「Patterns of Enterprise Application Architecture」
なぜこの2冊? 確かにソフトウェア工学は幅が広いですが、今回の趣旨に対して関係ない本を持ってくる意味がわかりません。

>「Extreme Programming Explained」
>「The Art of Project Management」
>「ピープルウェア」
どれも従来のソフトウェア工学に反旗を翻した内容ですから、「属人性を排除せよ」などという主張が出てくるわけないと思いますが。
というか、これらの書物と今回のエントリで書いた内容とは同じ方向を指してると思いますが、それだと何かまずいでしょうか?

>私は、「属人性を積極的に活かそう」とは一言も言っていません。
だれもそんな解釈はしてないので安心してください。ほんと何を主張したいのかが見えないだけです。

kwatchkwatch 2009/02/06 04:11 通りすがりさん:
別にRubyの仕様がどうのこうのは今回の趣旨と関係ない話だと思うんですけど。
関係ないついでにいうと、すでに決まってある言語仕様を実装するのと、どのような言語仕様がいいかを考えだす仕事では、大きな壁があると思います。また実装するにしても、できのいい実装とそうでない実装には天と地ほどの差があります。たとえRubyの仕様がむちゃむちゃでレベルが低いとしても(とてもそうは思えませんが)、実装の出来不出来は開発者の能力に大きく依存することに変わりはないと思います。
かりにですけど、もし「Rubyの仕様はレベルが低い、オレならもっといいのができる」と言いたいだけならご自分のブログでどうぞ。世界中のプログラマーがあなたに注目することでしょう。

tanotano 2009/02/06 12:59 > これがSQLの標準なのはわかりましたが、個人的にかなり困った仕様です。
> 今使っているORMが、「deleted_atがnullなら生きているデータ、そうでなければ
> 削除されたデータ」と見なしているので、not null default 0 とかできないんです。

データ登録前にfindでチェックするのは問題があるのでしょうか?
何か私が勘違いしているかな?

名の知られているDBMSのほとんどで不利になるIS NULL検索で、
有効レコードを取ってくるはORMの仕様として個人的にはイマイチと感じています。
DB構成の分りやすさとのトレードオフなのは分るけど。

archackerarchacker 2009/02/06 14:33 http://practical-scheme.net/trans/hp-j.html

上からの引用ですが。-------

ハッカーがやっていることは「計算機工学」と呼ばれることもあるが、この用語も誤解を助長するだけだ。優れたソフトウェア設計者は、建築家がエンジニアではないのと同じように、エンジニアではない。もちろん建築とエンジニアリングの境界ははっきりと定められているわけじゃないけれど、確かに存在する。それは、「何を」と「どうやって」の間にある。建築家は何をするかを決め、エンジニアはそれをどうやってするかを考え出すのだ。

「何を」と「どうやって」をあまり分けすぎるのは良くない。どうやれば出来るかを理解せずに何をするかを決めようとするのは、間違いのもとだ。でも、ハッキングには確かに、ある仕様をどうやって実装するか決めること以上のものがある。ハッキングの最良の形態とは、仕様を創ることだ--- ただ、仕様を創るいちばんの方法はそれを実装することだ、ということに過ぎない。

beyondseekerbeyondseeker 2009/02/07 07:28 kwatch さんの主張にはさまざまな興味深いデータやたとえが出てきているので、それらについて、どのような情報源から得ているのかなーというのが知りたかったということと、kwatch さんの主張について、私がうまく理解できていないところを確認したかったために、いろいろと質問させていただきました。

[引用]>「Extreme Programming Explained」
[引用]>「The Art of Project Management」
[引用]>「ピープルウェア」
[引用]どれも従来のソフトウェア工学に反旗を翻した内容ですから、「属人性を排除せよ」などという主張が出てくるわけないと思いますが。

という回答で、kwatch さんの文脈中での「従来のソフトウェア工学」の意味を理解でき、腑に落ちました。

ありがとうございましたー
m(_ _)m

namename 2009/02/09 02:51 ソフトウェア工学に決定的な間違いがあるのなら、「ソフトウェア工学の何をどうすればその間違いが改善されるのか」が欲しかった。
また、ソフトウェア工学の適用が必要な現場でその改善が行われた場合の、改善前後のメリットとデメリットの変化の考察も欲しい。

@ 2009/02/09 20:53 トラックバックの付け方が分からないのでぺたり( 'ω')ノ

http://ja.wikipedia.org/wiki/%E4%BA%BA%E6%9C%88%E3%81%AE%E7%A5%9E%E8%A9%B1#.E4.BA.BA.E6.9C.88.E3.81.AE.E7.A5.9E.E8.A9.B1

kwatchkwatch 2009/02/09 23:41 tanoさん:
> データ登録前にfindでチェックするのは問題があるのでしょうか?
> 何か私が勘違いしているかな?
今は仕方なくそうしているんですけど、やはりDBで制約をかけられるほうが安心できます。

> 名の知られているDBMSのほとんどで不利になるIS NULL検索で、
> 有効レコードを取ってくるはORMの仕様として個人的にはイマイチと感じています。
> DB構成の分りやすさとのトレードオフなのは分るけど。
そうですね。その通りだと思います。
道のりは長いですが、ORMを改造する方向で考えてみます。
有益なコメントありがとうございました。

archackerさん:
> という回答で、kwatch さんの文脈中での「従来のソフトウェア工学」の意味を理解でき、腑に落ちました。
・・・どう腑に落ちたんだろう・・・

kwatchkwatch 2009/02/09 23:45 nameさん:
> ソフトウェア工学に決定的な間違いがあるのなら、「ソフトウェア工学の何をどうすればその間違いが改善されるのか」が欲しかった。
そんなのがあるなら、こっちが知りたいです。
ないから、教育をして地道に人材を育成するのが、遠回りだけど一番の近道とは思ってます。

> また、ソフトウェア工学の適用が必要な現場でその改善が行われた場合の、改善前後のメリットとデメリットの変化の考察も欲しい。
そこまで深い考察はないです。
#ただの問題提起に論文みたいなことを求められてもね。

めしおめしお 2009/02/14 01:27 ソフトウェア工学が間違っているとしたら、間違ったものから得られる所産も間違ってますね。するとたとえばオブジェクト指向なんかは間違ってるものの代表格でしょうか。

たとえばオブジェクト指向言語を使わないでアセンブリ言語で30倍生産性が高いスーパープログラマーがいたとして、一方でrubyとかpythonを使う普通のプログラマーがいたとしたらどうしましょう。普通な人を使う方がいい場合も多々あると思います。

あるいは、30倍な人が太刀打ちできない、300倍の人が必要な問題があったらどうしましょう。300倍の人は1000年に1度しかでてこないとしたら1000年待つんでしょうか。でも無為に時間潰すよりは、学問的なアプローチを進めておいた方が、まあ気休めかもしれませんがマシな気がします。土台があれば30倍の人でも将来300倍の問題をジャンプしてクリアできるかもしれませんからね。

って考えると、ソフトウェア工学は間違っていると断言できない気がします。適用しないほうが合理的な場合もあるっていう話ならわかるけど。
長くてすいまそん。。。

ネットで学ぶソフトウェア工学ネットで学ぶソフトウェア工学 2012/06/09 18:57 なるほど。うちの会社でも属人性の排除を目指すとか言ってる人がいて、もやもやしてました。すっきりした気がする。

ただ、うちの会社は、それほど優秀でない人を集めて、ソフトウェア開発してると思いますが、課題がそれほど難しくなかったり、他で優位化技術があったりすれば、それはそれで成り立つのでしょうね。
(個人の)ソフトウェア開発力では負けていても成り立つ。
ただ、ソフトウェア工学に興味があるものとしては悲しいですが。。。

SHOSHISHOSHI 2013/01/28 10:59 最初は属人的な技芸だったものを調査・分析・解析することで、何時でも・どこでも・誰でもできるようにすることが工学なのでは?
だからソフトウェア工学に限らず○○工学を学んだからと言って、学んだ人がこれまでにない何かを生み出すとは限らない。
○○工学を学んだ人は先人に追いつきやすくなるだけで、それだけでは追い越すことはできないと思う。追い越すためにはそれこそその人の"能力"によると思う。そのレベルまで来てようやく属人性が発揮できるのでは?
一刻も早く(歳を取らないうちに)属人性を発揮できるレベルまで引き上げてくれるのが○○工学だと思う。他人と同じこと(=○○工学を学んだだけ)をしていてはダメだよ。

2009-02-03

MySQL で prepared statement を使うと query cache が効かない

| 23:30 |  MySQL で prepared statement を使うと query cache が効かない - kなんとかの日記 を含むブックマーク

なんかやけにパフォーマンスが出ないなーと思ったら、MySQLのクエリーキャッシュが全然効いていなかった。なんでだろうと思ったら、

  • Zend_Db_Adapter_Pdo_Mysqlは必ずプリペアードステートメントとしてMySQLにクエリーを流す
  • プリペアードステートメントに対しては、MySQLのクエリーキャッシュが効かない

という合わせ技だった。

そんな罠があったのかよ。MySQL 4.1のマニュアルには書いてなかったけど、MySQL 5.0のマニュアルには「It was issued as a prepared statement, even if no placeholders were employed. 」と書いてあったよ。せめてプレースホルダーがないパターンだけでもキャッシュしてくれればいいのに。

いしなお! - MySQLのクエリーキャッシュが効かない

なんと、prepared statement にそんな孔明の罠があったとは!

Ruby 用の MySQL ドライバでは、prepared statement を使わなかったらデータをすべて文字列として返すので、データ型を変換させるために prepared statement を使っている人は多いんじゃないか。しかし prepared statement にそんな制約があったら、やっぱり使うべきじゃないのかな。

といっても、今使っているレンタルサーバは query cache が on になってないけどな! on にするには root 権限が必要だから、どうしようもない。


でもさー、MySQL の query cache 機能って、みんな知ってた? ワシはついこの間まで全然知らんでのぅ・・・これを知らずにプログラムを一生懸命チューニングしていた自分がバカだったわ。

この機能は Oracle にはなかったと思うから、これって MySQL の大きなアドバンテージだよね。

SH2SH2 2009/02/05 08:07 Oracle11gにはあります。

2008-09-09

NeverBlock が Ruby 1.8 対応?

| 03:48 |  NeverBlock が Ruby 1.8 対応? - kなんとかの日記 を含むブックマーク

NeverBlock Now Supports Ruby 1.8

Utilizing Aman Gupta's Poor Man's Fibers we were able to add Ruby 1.8 support to NeverBlock. Thankfully this does not mean that applications written for NeverBlock now require full thread safety. Aman's implementation makes sure one thread is scheduled at a time. The fibers don't fight for CPU time so the solution is free of race conditions. The performance penalty is not very big and we were able to extract some very good figures during lab testing.

Home - eSpace Technologies

まじかよ。NeverBlockはFiber使うからRuby1.9限定じゃなかったのか?

これでまた、Ruby1.9を使う理由が減ってしまった。