変わらぬものは取り残される

東洋経済という経済雑誌には、「日本のメーカーの国際的なシェアは10年前に比べ著しく低下した」という記事がありました。 （日本が得意にしていた半導体分野は韓国のサムスンに一気に主導権を奪われた）

Re. LOHASっていいな･･･ 潮流

http://www.itmedia.co.jp/news/articles/0603/29/news014.html
残念ながらこちらにあるように、IT に関しては既に先進国からは脱落している というのが国際的な認識なのだ。

問題はいくもあるだろうけど、わたしは大きなものは次の3つではないかと思う。 ひとつはこれでもまだ日本は IT を含めた最先端技術の トップを走っていると誤解している人が日本の政治層に多いこと。 次は勉強する入り口が用意されていないこと。 最後は、日本という国は非常に保守的であること。

・日本は IT 後進国 -- これは認めよう
最初の問題の具体例のひとつとして、指摘されているように 携帯電話産業の誤解がある。これまで、個人向けコンピュータの OS やデスクトップアプリケーションで諸外国に押される中でも 日本の組み込み技術は世界トップだと主張されてきた。 しかし、過去にあった海外の携帯市場への進出は失敗に終わりほとんどの 企業が撤退している。結果はリサーチの通り。 国際的に見ると日本企業の携帯シェアはトップからは程遠いものだ。 しかし、日本国内ではこれが全く認められていない。

まずは現状を認識しよう。何事も現状を認識しないことには始まらない。 ただし現状を認識してがっくり orz しろとか、そこで諦めろってことじゃない。 「日本はトップなんだ！」じゃなくて「今はトップじゃないけどトップになるんだ！」 にしようよということ。

見て見ぬ振りでは成長することがないけど、 目標があってそれに向かって努力するなら成長していく。 競争力も上がっていくんじゃないかな。

・勉強のきっかけ -- 入り口 -- は用意してもらわないと
2つ目の問題も深刻だ。日本では IT 技術を習得させるまともな 教育が行われていない。教養程度の知識すら教育されていないのが現状だ。 専門学校で教えられているのも所謂 HowTo. ドッグイヤーを上回る速度で 回り、技術革新も頻繁に起きるこの業界では HowTo は短期間しか通用しないため 競争力を引き上げる起爆剤とはならない。

基礎から Deep な知識を身につけているのは一部の学部へ進んだ人間か、 個人でものすごい努力を積んだ人間、あるいは近くに詳しい方がいて その人に師事した人間くらいでしょう。

勉強は自分でするものだという意見はごもっとも。しかし なにがあって何がないのか、何ができて何ができないのか、 それはなんでだろう。という勉強をはじめるきっかけすらない状態で 勉強を始められる人間というのは多くないと思う。 「パソコンなんて持ってないし、触ったことも見たこともない。 周りでも誰も持ってないよ。それって何が出来るの？」 って状態でじゃぁ何から勉強したらいいんだろうってわかるだろうか？ せめて、入り口を提供する場くらいは基礎教育で用意するべきだと思う。

・変わろうとしない(ｒｙ
「日本人は論理的でない」とか「日本人はチャレンジをしない」とか言われてるけど これ以上に有名なのが「日本人は保守的過ぎる」だろう。いくつかの企業を 渡り歩いてきた経験からするとこれは真実だ。10代～20代前半はまだ柔軟性がある ( それでもチャレンジは避けようとする傾向にあると思う ) が、40を過ぎた 方々は保守的を通り過ぎて偏執的とも言える。

たとえば20年前のビジネス手法がそのまま使えると信じていたりね。 20年前！20年前といえば紙とペンが中心の時代だ。コンピュータは ごく一部の人間だけが操れるよくわからないものという認識で、 一人一台なんて考えられもしなかった時代だ。外国にいる相手と 電話で連絡を取ったならものすごい金額を請求された時代だ。 書類を送りますっていったら郵送で数日かかっていた時代だ。

Longtailでも書かれていることだし、Googley Method でも触れられているし、 わたしの大昔のエントリでも書いたことだけど、いまはそんな時代じゃない。 オフィスのコンピュータは一人一台が当たり前だし、地球の裏側の相手とですら リアルタイムで連絡が取れる ( しかも料金は月額1万程度だ ) 時代だ。

ここ数年、情報は「メディアから一方的に押し付けられるもの」から 「ユーザが探してくるもの、ユーザ自身が発信するもの」へと変化しつつある。 これはユーザの需要にも影響を与えつつある。資本主義って基本は消費者の 需要だから ( 需要がなければ供給のしようがない )、需要が変わったなら 供給する側 ( つまり企業 ) も変わらなきゃならない。ところが供給側は 頑なに変わることを拒否しているように見える。

そこへユーザの需要を満たしてくれるようなものを引っさげた 別の企業が参入してきたらどうなるだろう。これは現在の市場が 証明していると思う。自分の需要を満たしてくれるものへの乗り換えが起こるから 既存の企業のシェアが切り崩されていくんだ。 日本人はブランド志向が強いみたいだから乗り換えはゆっくりみたいだけど、 でも徐々にシェアの構成図は変わっている。

何が言いたいかというと、ユーザの需要を無視して 「我が社が供給するものを黙って使え」というスタンスは、 他の企業にチャンスを与えているということ。 シェアを奪われるのがイヤなら積極的に変わっていかなきゃならない。

もちろん既存の企業がこんな間抜けでいることは新興企業にとっては 大きなメリットだ。いまなら SNS でコミュニティを回るとかで 需要が満たされていないと思われるポイントを見つけることも 簡単になった。ピンポイントなブルーオーシャン戦略といえる。

「時代の変化や波に適合・適応する国や個人が競争に勝ち、生き残る」
というのはこういうことだと思うよ。

長々と書いたけど、わたしは文章が下手なので何言っているのか さっぱりわからんってひともいるだろうし、無名の戯言なんか 信じられるかって人もいるでしょう。そこで本を 3 冊紹介します。 判りやすく、データも表記されているので興味があれば読んでみてくださいな。

Reference

Longtail ( 原著: Chris Anderson / 訳:篠森 ゆりこ )

イノベーションのジレンマ( 原著:クレイトン･クリステンセン/訳:玉田俊平太, 伊豆原弓 )

ブルーオーシャン戦略( 原著:W･チャン･キム/訳: 有賀裕子 )

[.NET] .NET Framework3 正式版リリース

.NET Framework3 ( 旧名 WinFX ) の正式版が公開されています。

Runtime は日本語版もありますが、SDK と VS Ext は英語版のみの様子。

• .NET Framework Runtime ( 日本語版 )
• Windows SDK for .NET3.0 and Vista ( インストーラのみ )
• Windows SDK for .NET3.0 and Vista ( DVD イメージ )
• Visual Studio 2005 Extensions for .NET 3.0, Nov 2006 CTP
• Visual Studio 2005 SDK ver4.0, Nov 2006 CTP

[ Python/.NET] IronPython で py をコンパイル

IronPython 登場当初から Python ソースファイルのコンパイルが可能 ということは言われていました。実際、コンパイルして .exe ファイルを 作成することができます。

"ironpython コンパイル" で検索するとここが上位に引っかかるらしくて 結構実に来てくださる方がいるのですが、IronPython を VS2005 に統合する 別エントリでがっくりしてしまう方もいらっしゃるようで・・・ すみませんでした(´・ω・`)

さて、本題の IronPython を利用したコンパイルですが、 コンパイル機能は ipy アセンブリ(*)が持っています。 コマンドプロンプトを起動して "ipy -h" と入力するといろいろと オプションを表示してくれます。インタープリタエンジンだけではないんですね。

アセンブリ ( assemblies ) * :
アセンブリと聞いて「え？」と思う方もいると思います。わたしも最初驚いたのですが このアセンブリは作業やアセンブリ言語で書かれたファイルのことではありません。 .NET プラットフォームでの「アセンブリ」とは論理的な実行単位のことです。 .NET プラットフォームでの「アセンブリ」とは複数のモジュール ( モジュールはファイルとほぼ同義 ) が集まったものになります。この概念はあとで重要になってきます。.NET アプリケーションはモジュールが足りないなどアセンブリが不完全だと動作しません。詳しくはインサイド .NET Framework ［改訂版］第一回をご覧ください。

コンパイルを実際にやってみましょう。 突然ですがエディタで次のコードを入力して、ファイル名を helloipy.py として保存してください。

print "Hellow IronPython!"

・方法1: ipy.exe を直接使う

コマンドプロンプトを起動します。コマンドプロンプトを起動したら
ファイルを保存したディレクトリまで移動しましょう。

移動できたら次のコマンドを入力します。

ipy.exe -X:SaveAssenblies helloipy.py

helloipy.py を保存したディレクトリにhelloipy.exe と helloipy.pdb というファイルが作られていればコンパイルは成功です。IronPython の Readme には -X:SaveAssemblies は "caching of generated assemblies" ってあるけど、 ( 中身は後述の方法と微妙に異なるけど ) EXE ができて ildasm をかけて内部動作を調べることもできるから 学習用のコンパイルとしてはこれでもいいと思います。

・方法2: pyc.py を使う

pyc.py は IronPython1.01 の Example として公開されているとても有用なモジュールです。 コンパイルのオプションがとてもわかりやすくなっており、PE ファイルだけでなく DLL ファイル の作成も簡単に指定できます。

Usage: ipy.exe pyc.py [options] file [file ...]

Options:
    /res:rfile.resource[,(public|private)]    Include public or private resource file
    /main:main_file.py                        Main file of the project (module to be executed first)
    /out:output_file                          Output file name (default is main_file.)
    /target:dll                               Compile into dll
    /target:exe                               Compile into console executable
    /target:winexe                            Compile into windows executable
    /platform:x86                             Compile for x86 only
    /platform:x64                             Compile for x64 only
    /platform:Itanium                         Compile for Itanium
    /r: or /reference:                        Add referenced assembly
    /? /h                                     This message

pyc.py を使ったコンパイルも簡単です。コマンドラインから

ipy pyc.py /main:helloipy.py

と入力するだけです。helloipy.exe とhelloipy.pdb が作成されていればコンパイルは成功です。 pyc.py では入力されたファイルとその成果物をメッセージとして出力してくれます。

Input Files:
        helloipy.py
Resource Files:
Output:
        helloipy.exe
Target:
        ConsoleApplication

pyc.py は IronPython.Hosting.CompilerSink と IronPython.Hosting.Compiler の wrapper なので自分でこれらのクラスを利用したり、あるいは IronPython.Compiler.* を使って コンパイラを作ってコンパイルということもできますが引数やらオプションやら 面倒なことを考えるよりも素直に pyc.py を使うことをお勧めします。

コンパイルはできました。しかし、作成された helloipy.exe を実行しようとしても エラーが出てしまって実行できません ( 環境変数の設定によっては実行できる方もいるでしょうけど )。 わたしの環境では実行しようとすると次のようなエラーが表示されました(一部編集しました)。

>helloipy

ハンドルされていない例外: System.IO.FileNotFoundException:
ファイルまたはアセンブリ 'IronPython, Version=1.0.60816.1877, Culture=neutral,
PublicKeyToken=31bf3856ad364e35'、またはその依存関係の 1 つが読み込めませんでした。
指定されたファイルが見つかりません。
ファイル名 'IronPython, Version=1.0.60816.1877, Culture=neutral, PublicKeyToken=31bf3856ad364e35' です。

太字の部分に注目してください。「必要なファイルまたはアセンブリが足りない」ので 実行できなかったことがわかります。.NET アプリケーションはアセンブリ単位で動作すること、 アセンブリは複数のファイルで構成されること ( そしてアセンブリ間にも依存関係があること ) を 思い出してください。

今回の場合には IronMath.dll と IronPython.dll の 2 つが必要になっています。 この 2 つのファイルを helloipy.exe とおなじフォルダにコピーすると動作するようになります。

少し面倒になりますが、IronPython で作成したアプリケーションを実行・配布するには、 コンパイルするだけではなく、アセンブリを構成するモジュール ( ファイル ) と、作成した アセンブリが依存しているアセンブリを全部そろえる必要があります。

まとめ: python コードのコンパイル

1. ipy (オプション) (ソースファイル名)
   
2. ipy pyc.py (オプション) /main:(ソースファイル名)
   
3. IronPython.Hosting.CompilerSink とか IronPython.Hosting.Compiler とか IronPython.Compiler.* を使って自前でコンパイラコード作成

2 番がお勧め。3 番はマニアックな人向け。
コンパイルしたら依存関係があるファイルを集めて出来上がり(´・ω・`)ｂ

[ Python2.5 ] 2.5 で導入されたカリー化

Python2.5 で関数言語での「カリー化」にあたる機能が追加されているみたい。

関数を呼び出すときには引数を渡すけど、引数が複数あるとき、 Python2.4 まではそのうちのいくつかを渡して残りは待っていてね ということはできなかった。実際にやってみると次のように 例外が発生してしまう。

Python 2.4.3 (#69, Mar 29 2006, 17:35:34)
>>> adding = lambda x, y: x + y
>>> adding( 1 )
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: () takes exactly 2 arguments (1 given)

その関数を呼ぶためには引数がきっちり2個必要だよ、というわけだ。 もちろん、closure を使えば「次の引数ができるまでちょっと待っててね」的なことはできる。

Python 2.4.3 (#69, Mar 29 2006, 17:35:34)
>>> def step1( x ):
...     def step2( y ):
...         return x + y
...     return step2
...
>>> adding = step1( 1 )
>>> adding( 2 )
3

できるんだけど、この場合、つまり1つの処理を無理やり2つに分けるよりは、 カリー化する方法があればもっと簡単にシンプルに書ける。 ということで Python2.5 で導入されたのが functools モジュールの partial() 関数。 これを使うと次のように書ける。

Python 2.5 (r25:51908, Sep 19 2006, 09:52:17)
>>> import functools
>>> adding = functools.partial( (lambda x, y: x + y), 1 )
>>> adding( 2 )
3

関数に渡す引数が全部そろうまでリストに貯めたりとか、 全部揃うまで待たせるために closure を使うよりは partial() したほうがなんとなくいい気がする。

closure を使った方がいい場合もあるのだろうけど、 それは context で判断しよう。

まとめ
functools.partial() をつかうと関数の部分適用
( カリー化(?)。引数が揃うまで待っててね ) ができる。

[python] うそん・・・（；´Д｀）

新山さんの日記より。
わたしも試してみた。

Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.remove == os.unlink
True

どうやら Windows でも同じ現象が起こるようだ（；´Д｀）

あ、もしかしたら 2.5 なら直っているかもしれないね。

Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> import os
>>> os.remove == os.unlink
True

・・・・・・・・・( ´･ω･`)

第2弾。Multi Thread プログラミングについて。

こちらの ML によると Python のマルチスレッドは Crude らしい。そういえば数日前に threading モジュールを使ってマルチスレッドコードを書いたら、メインスレッドを終わらせたのにデーモンフラグを持ったスレッドがゾンビになっていたことがあったな。

Python's threads are crude because although they are OS scheduled, only one thread can access the Python internals at a time.

という欠点もあるみたい。この場合、マルチプロセッサで問題が顕在化するようだ。メインストリームの PC がマルチコア CPU 搭載機に移行しつつある現状を鑑みると、Python でマルチスレッドは避けた方がよさそうだね。

[ javascript ] js で Real-Time 3D

サイボウズラボの秋山さんのブログで紹介されていました。秋元さんのエントリでは IE6 では動作しないようなことが書かれていますが、11月5日現在さらに進化して IE6 でも動くようになってます。

Real-Time 3D in Javascript をみて驚いた。JavaScript と CSS だけで複雑な立体をつくりそれを回転させている。光源が立体に与える視覚効果まで考えて描画されているのは驚愕。なにも知らされずに見たとしたら、Java アプレットか ActiveX で動かしていると思ってしまうんじゃないだろうか。

もしかしたら簡単なアクションゲームなら作れてしまうんじゃないだろうか。手間はかなりかかるけれど、とても面白そうだ。

[ 備忘録/VS 2005 ] Visual Studio 2005 環境設定覚書

環境設定の変更で戸惑ったので自分メモ。

・規定の設定のコレクションを変更する

Visual Studio 2005 では初回起動時に、デフォルトの開発をどの環境で行うかを設定する。 たとえば、C# を選択した場合は C# に合わせた設定が自動的にロードされるし、C/C++ を選択した場合は C/C++ に合わせた環境設定が自動的にロードされる。簡単に言うと主役を誰にするかを決めるようなもので、ここで主役を決めると次からは決めた主役に合わせた舞台が用意されるわけだ。

ところで、最初に設定したコレクションのまま使い続けられればいいんだけど、メインで使う言語を変更したとか、次のプロジェクトでは違う言語を使うことにしたとか、舞台が全く異なる場合には主役を変更する必要も出てくる。変更の手順は次の通り。

1. [ ツール (T)] メニューの [ 設定のインポートとエキスポート (I)] を選択する

2. ウィザードの [ 全ての環境をリセット (R) ] を選択して [ 次へ (N)]

3. 現在のコレクションとその設定を保存するかどうかを決めてから [ 次へ (N) ]

4. 設定したいコレクションを選択してから [ 完了 (F)] をクリック。
ここでは既定のコレクションに「C# 開発設定」を選択しています。

・ウィンドウの配置をリセットする

Visual Studio の GUI はかなり柔軟性があって、いろいろと変更ができる。不要なものは非表示にできるし、初期状態ではメインウィンドウに統合されている ( docked な ) ウィンドウもメインウィンドウから切り離せるとか結構便利だ。

そのとき作っているものあるいは開発の段階に合わせて GUI をいろいろいじると思うんだけど、使いにくく感じて設定をリセットしたいと思うときもある。また、別のプロジェクトファイルを開いてそちらの作業をするとなるとそのままのウィンドウ配置では使いにくく感じてしまうこともある。

入門書やマニュアルを引っ掻き回して、それを参考にしながら手作業で元に戻していくのはかなり面倒。Visual Studio を一度完全にアンインストールしてから再度入れなおすというのも、インストール時間がかなり長いのでやりたくない。以前の Visal Studio .NET ではオプションメニューの [ 環境 ]-[ 全般 ] カテゴリの中に「ウィンドウ レイアウトのリセット (L)」というボタンがあったんだけど、VS2005 ではそれがなくなってる。

「全部手作業で戻せということか？」とげんなりしたけれど、どうやら早とちりだったらしい。
他の場所に移動していた。

VS2005 でウィンドウの配置をリセットするには、[ ウィンドウ (W)] メニューの中にある [ ウィンドウレイアウトのリセット (R)] をクリックするだけでいいようだ。

vi は宗教らしい

わたしの周りでは「プログラミングに使える優れたツール」で vi を上げる人は皆無。ほとんどは Eclipse か Visual Studio を挙げる。マイナーどころでは秀丸エディタとか KDevelop かな。

IRC で友人から「 vi は宗教なんだよ」という話を聞いた。「一神教の信者と同じ。唯一正しいのが vi なんだ」そして他のツールは邪悪で卑劣なものと考えているのだという。

「みんな奥が深い症候群の感染者。あまり深く関わらない方がいいし、逆らわない方がいいよ。」

ああ、なるほど。わたしはいつも友人に助けられている。
このことを教えてくれた友に深く感謝する。