スカート型マウスパッド「みゆき」新発売

スカートの中に、マウスをいれて操作するというスカート型マウスパッド、
「みゆき」（商品名です）が発売されてるそうな。。

ここの痛いニュース
スカート型マウスパッド「みゆき」新発売
http://blog.livedoor.jp/dqnplus/archives/949435.html
によると、

っていうか、ここの
スカート型マウスパッド：
Donyaダイレクト DN-みゆき
http://item.rakuten.co.jp/donya/53299/
の上海問屋で売っているんだけど（以下斜体は、上記上海問屋より引用）

「マウスにはマウスパッドが欠かせない」というあなたへ贈る、上海問屋オリジナルのマウスパッドが誕生しました。

表から見ると…
普通のスカートのように見えます。

裏から見ても… スカート。

ポケット周りもちゃんと作られています。
(使いやすさのため、開きません)

前ボタンは外すこともできます。

マウスを入れるとこんな感じ。
(あくまでマウスパッドなので)

中をちょっと覗いてみると…
マウスパッドと中に入れたマウスが見えます。

使うときはスカートの中に手を入れて…　こんな風に使います。

この商品はマウスパッドです。履いたりすることはできません


上記サイトに写真がありますが。。。
はい、スカートです。
スカートの中に、マウスがあって、スカートをめくって、マウスを動かすというものです。

エイプリールフールじゃあ。。

ないようで、ちゃんと価格 952円 (税込 999 円) 送料別
で売っているみたいです。。

うーん（以下はそのリンク先より引用）、
デスクにアニメキャラ（セクシー系）やグラビアアイドルの写真などを置いている男性社員がいて、女性にとっては不愉快なんていう、職場のある中、会社にこれを置いて許されるのは。。

。。。日本では、ほとんど無いかも。。

（まったく無いとは言わないけど。。。ウィリアムのいたずらが大卒で、一番初めに入社した会社なら、ＯＫそうな気がする。。）

Hello World程度のデータベース（その１３：内部スキーマ（１）ＤＢの構造）

情報処理とは何から、データベースの基本的な話(情報処理試験のデータベーススペシャリスト程度の話まで）を書く、土日のシリーズ「Hello World程度のデータベース」です。

データベースには、
概念スキーマ：世の中のものをＤＢのモデル（エンティティ）に落とし込む見方
内部スキーマ：ＤＢのモデル（エンティティ）を実際のＤＢにおとしこむ見方
外部スキーマ：実際のＤＢからプログラムで利用できる形に取り出す
という、３つの側面、スキーマがあるっていうのが、三層スキーマの考えでした。
で、いままで、概念スキーマをやってきました。

今回から、ＤＢのモデル（エンティティ）を実際のＤＢに、物理的にハードディスクとかにおとしこむ方法、つまり内部スキーマについてです。

---

■ＤＢの構造

　まず、物理的なハードディスクとかを、どーいうふうに利用して、データベースを実現しているのか、ＤＢＭＳの仕組みというか、構造について話さないと、話がさきにすすまないので、それについて。。

ＤＢの構造として、３つの保存内容があります。

１つは、ジャーナル、データベースの操作内容がすべて書かれていて、
　これを利用して、なんかあったときに、元に戻せるようになっています。

２つめは、インデックス
　これを利用して、検索速度を速めています。

３つめは、データを格納するところ
　これは、いくつものハードディスクを集めて、１つのハードディスクとして
　いなす、ＶＳＡＭ技術が使えるものもあります。
　とにかく、データが入っているところです。

---

■ＤＢは、どのように動くのか
　で、これらを使って、どのように動くのか？っていうことですけど、

＜＜検索の場合＞＞
　検索の場合は、インデックスをはじめ検索し、

１．それで検索条件が一致すれば、
　　データを格納するところからデータをとりだして返します

２．インデックスが張られていない検索条件がある場合、
　　データを格納するところからデータをとりだし、チェックして
　　ＯＫだったら返します

３．いくつかのテーブルＪＯＩＮなど、２ではすぐに返せない条件
　　があるばあい

　　一時的に、領域を取って、そこに書き出し、チェックしたり、
　　いろんな操作をします（この領域確保などに時間がかかる）

＜＜更新などの書き込みの場合＞＞

　複雑なので、詳細は今回は省略しますが（もしかしたら、今度書くかも？？）
　とにかく、

・ジャーナル
・インデックス
・データを書くところ

　すべてを書き込んだり、修正したりします。

---

■で、操作できるのは。。

　っていうことで、
・ジャーナル
・インデックス
・データを書くところ
　を、ＤＢは操作するのですが、ジャーナルはＤＢで勝手に書いてくれます。つまり概念スキーマにあんまり関係ないところです。

　で、インデックスと、データを書くところに関しては、ユーザーが操作でき（操作言語がある）、その操作にもとづきＤＢが動きます。そして、このインデックスとデータを書くところをつかって、概念スキーマで記述したＥＲ図をＤＢに落とし込んでいきます。

---

■次回から

　ということで、次回から、インデックスとデータを書くところは、どーいう構造になっていて、ハードディスクとかに表現されているのか、そして、どういうふうに記述したら、概念スキーマで作成したエンティティ、属性、キーがＤＢ上に表現できるのかについて、書いていきたいと思います。

---

ということで、このシリーズの次回では、インデックスについて書きます。

日本がインドにＩＴで負ける日－ＩＴ敗戦国、日本－

　このままいくと、日本はＩＴにおいて、インドに負け、

アジアにおける
　　ＩＴ勝ち組国家　インド
　　ＩＴ負け組国家　日本、中国
となるという仮説を、様々な資料をもとに検証していく「日本がインドにＩＴで負ける日－ＩＴ敗戦国、日本－」という本を、ウィリアムのいたずらが、６月ごろに電子出版する予定です（いま、資料を収集して、一生懸命かいてます）。

　今日は、ちょっとその宣伝です。

---

■はじめに－銀の弾丸の打つ方向を間違えた日本、これから打つインド

　その本（といっても、電子出版ですので、本当の本じゃないけど）の書き出しはこんなかんじです。

　　はじめに－銀の弾丸の打つ方向を間違えた日本、これから打つインド

　いつからだろう。日本においてＳＥという言葉が、システムの設計をする人を指すのではなく、ソフトウエアに携わる人、とくに、プログラマも含めた人をさす言葉になってしまったのは。

　１９８０年代、９０年代は、システム設計は、ユーザー業務をある程度知り、枯れた技術を組み合わせてシステムを作っていた。そこには、業務知識を重視する姿勢があった。そのため、ユーザーの要望を理解し、吸い上げやすい土壌ができていた。
　また、枯れた技術の組み合わせのため、見積もりも立てやすく、そこそこ正確な見積もりがたった。

　しかし、この状況は１９９０年代後半から変わり始め、２０００年代にはいって、明らかに変わった。技術的なことが注目され、ユーザーの業界知識は軽視された。というか、ユーザー自体も、会社のリストラにより、業界知識を失っていった。さらに悪いことに、ビジネススピードが加速し、業界といえるものが形成されない業界もあらわれてきた。
　そして、枯れた技術を使うのではなく、いたずらに最新技術を使うことになった。オープンソースを利用することが善とされたが、そのオープンソースは、実は枯れているどころか、１ヶ月前、２ヶ月前にリリースしたばっかり、それも、先行ユーザーのレポートすら出ていないという危険いっぱいの技術ですら、オープンソース信仰ゆえ、どんどん使われていった。

　その結果、どうなったか。。。

　要件定義では、業界知識の不足から、ユーザーの要件定義がまとめられず、いつまでたっても要件がまとまらないで、開発の日程を押し、その日程の遅れを取り戻すため、プログラミングは見切り発車で開発させられ、期間短縮、単体テストはカットして、問題は結合テストで露呈する。

　さらに、いたずらに最新技術を使い、枯れてない技術を使っているがゆえに、想定外の問題がおこるおこる。。
　結局、そのために残業で、徹夜。。でも、徹夜も１日２日ならまだしも、半徹状態で、数週間も続くと、バグがはいって、なおさらバグを呼ぶ。。
　こうして、デグレード、システムは崩壊し、昔できたシステムですら、新規システムでは作れないという状態になってきた。。

　もちろん、この状況を防ごうと、ソフトウエア工学は進んだが、彼らは形而上の世界で遊んでいるだけで、現場に足をつけたものではなかった。でも、そのソフトウエア工学を知ることが、あたかも現場において、「おれは高尚なことをやってるんだよ！」といいたい、一部の勉強ずきというか、欲求を満たしたいやつらというかに受けて、空虚な話が空転している状態だ。
　「デザインパターンはね。。」とか、高尚なことを言っているやつらがいるが、彼らは、マージやソートというビジネスで基本となるようなことを、Javaで、どうプログラムするか、わからなかったりする。

　かくて、コンピューターは、徹夜続きの作業となり、システムはできず、システム工学は、高尚なことを言っても現場の徹夜作業を止めるには役立たず。。。といった状況になる。

　今の日本のシステム開発は、開発を巧く行う銀の弾丸があるかないか。。なんていう議論以前の問題だ。オープンソフトをどんどん進め、技術的に危ない方向にどんどん持って行き、ソフトウエア工学は、どんどん現場から離れるという、システム開発を失敗させる方向に、加速的な努力をしている。
　つまり、弾丸を撃つ方向、努力する方向を間違えている。これでは、銀だろうが、金だろうが、どんな高級な弾丸を作って撃っても意味が無い。


　しかし、ここで、まじめに、業務を追求している国があるのだ。
　インドだ。

　インドのインフォシスは、業務を重視し、熟知することに、尽力をあげている企業だ。
　１月当り６０万か７０万かそこらをはらって、人集めし、使い捨てする、どっかの国とはわけが違い、社員教育、とくにユーザー業務の知識取得を重視しているのだ。。

（以下、つづく。。。全部書いちゃうと売れないので　＾＾；）

---

■目次

　ってことで、目次だけは、ご紹介しておきましょう。

はじめに－銀の弾丸の打つ方向を間違えた日本、これから打つインド 第一章　マクドナルドに、給料も技術も負けている日本のＳＥ ・ＳＥの給料、時給にしたら・・・ ・マックの人はハンバーガーをマニュアルどおり作れば作れる ・ＳＥは、ソフトをマニュアルどおり作れば作れるのか？ ・っていうか、ソフト作りを矛盾なくできるマニュアルってあるのか？ ・結局、マクドナルドに、給料も技術も負けている日本のＳＥ 第二章　銀の弾丸の打つ方向を間違えた日本 ・Ｅ－Ｊａｐａｎ構想、電子政府は？ ・国のＩＴ政策、税金を有効利用してるといえる？ ・日本のＩＴ投資は実を結ぶのかっていうか、結んでるのか？ ・汎用コンピューターとオープンシステム、費用＋機会損失的に考えると？ ・ＤＯＡ、オブジェクト指向－結局、昔と見方変えただけじゃない？ ・ソフトウエア工学は発展したけど、ソフトウエア品質は、結局あがってるの？ ・開発の失敗が多い理由 ・ＳＥという職種の変化が、システム開発の失敗を招いてる ・銀の弾丸の打つ方向を間違えた日本 第三章　これからのＩＴ国家、インド ・日本のＩＴ技術にオリジナリティはあるか？単なる欧米の技術移転では？ ・欧米の技術移転なら、英語が読めるインド人のほうが有利だ ・グローバル化－日本にとって、有利とは言えない ・アメリカの下請けが、パートナーになる日 ・日本のソフトハウスは金持ち。。かあ？？ ・資本力と人材力、最後はこれできまる ・これからのＩＴ国家、インド 第四章　ＩＴ敗戦国－日本 ・英語が読める大卒生のインドＳＥ、英語が読めない専門学校卒が増える日本のＳＥ ・業務がグローバル化したら－日本の業務知識はどこまで通じる？ ・人の使い捨てで技術が蓄積しない日本、人を育て技術を蓄積するインド ・ＩＴ会社に入れば生きていけるかもしれないインド ・ＩＴ会社に入ったら過労死で殺されるかもしれない日本 ・日本がインドにＩＴで負ける日 ・ＩＴ敗戦国、日本 おわりに－勝ち組と負け組を分けた差は？ 　ＩＴへの長期投資ビジョンではなく、業務と人に対する長期投資ビジョンだ！

---

■発売とか

　ってことで、６月ごろ、でじたる書房で、８００円で発売予定でーす。
　あ、ついでに、もーちょっと、スクロールして、下まで見てね（＾＾）


















●今日は、４月１日、エイプリルフールでーす。
　なんで、書いてもいないし、販売もしないっすよ、うそぴょーん（＾＾）ｖ