Archive for the ‘コンピューターとインターネット’ Category
フリーズしないアプリケーションの作り方
@IT 向けに書いた記事が公開されました。
これもまた、裏ではいろいろと思うところあり。
タイミングよかった
いやー、題材が題材だけに、C# 5.0 とか .NET Framework 4.5、VS11 の正式版が出る頃に出そうかなーなどと思って書き貯めてあった文章だったり。
諸事情あって、実は意図せず今月完成させて出すことになって、今日の公開だったわけですが、意図せずいいタイミングになったなぁ。
BUILD での発表内容がもうほんと非同期処理だらけで。「WinRT では50ミリ秒以上かかる処理は非同期APIにします」とか、C# 5.0 の async/await 構文の再説明も多々入っていたり。
ついかっとなってやった。後悔なんてあるわけない。
まあ、非同期処理は一応、年々ホットな話題になってきているので、他にも記事はあるにはあります。
ただ、自分的に納得のいくものがないというか、「非同期処理なんてどうせレベル高い人向けのものだから、わかりやすい説明とかしないでいい」と言わんばかりのものだらけなのが納得いかず。難しいものを難しいまま書いてる記事とか見るとイラっとして、ついかっとなって自分で書いた。後悔はしていない。
なんというか、図が全然ないとか、いまいちきれいな分類がなされてないとか、そもそもなぜ必要か理由が抜けてるとか。そういうのを抜かない丁寧さは大事だと思うのに、ほんと、非同期処理がらみの記事できっちりしてるものを見たことがなく…
特に、C# 5.0 で入る async/await 構文なんかは、「今までレベル高い人だけが触っていたものを、もう少しレベル低めの人でも触れるようにしよう」というものなので、丁寧な説明を要するわけで。
かぶった
「他にも記事はある」というか、書いてる最中、100％かぶった記事が公開されて焦ったり…。しかも、MSDN マガジン。
テーマはおろか、Task クラスから始めて、Parallel クラス、C# 5.0、Dataflow ライブラリを説明と、構成まで完璧にかぶりましたとも。びっくりするレベルで。
まあ、でも、上記の理由（丁寧さの問題）があるので気にせずそのまま書くことに。
難しいことを簡単に
簡単なことを簡単に説明しても役に立たないだろ。難しいこと難しいまま書いても読んでもらえないよ。
などと、常日頃から思っております。難しいことを簡単に説明できなきゃいけない。
でも、テーマが「難しいこと」な時点で編集部の方々に敬遠されがちなんですよねぇ… さんざん言われていますとも、
- 「えっ、LINQ までやるの？」
- 「非同期をテーマにすると、予想以上に引きが弱い」
等々。
ページビューによって広告収入が決まるんで、編集さんとしては正しいご意見。難しいこと難しいまま書く人が多いんだもん、そりゃ PV 取れない。
しかし、レベル高い記事ほど PV 取れないとなると、ウェブからレベル高い記事が消えるよなぁと、常々懸念しております。
なんとしても、レベル高めの記事で PV 取らなきゃいけない。それには、ただ難しいこと書いていてはダメで、難しいことを簡単にかかなきゃいけない。
まあ、前の「データ処理」（要は LINQ）とか今回の「非同期」とかで、そこそこちゃんとブックマークついているようなので、ひとまずは安心。
（自分の場合は、自分自身が twitter とか ufcpp.net とかから宣伝かけれるんでチートといえばチート、フェアな数字でもないんですが。あと、対外的に「難しいことを簡単に」であることに加えて、まあ商売ですんで、制作的には「見合ったコスト」で書けなきゃ意味なく。この点はまだまだ改善の余地あり。）
（あと、「非同期」という言葉がよくわからなさすぎて良くないという説も。今回の記事も、タイトルからは非同期の文字を外すことに。それは多分、効果あったと思います。「フリーズしない」の方がやっぱりパッと見でイメージ伝わる。）
今のページビューと、これからと
開発者の収益性という面でみると、一番コスト・メリットのバランスがいいのは「平均的なレベルの1歩だけ先を行く」なんですよね。はっきり言って、最新技術追いすぎてもコスト高。
それもあって、ニュース性の高いものならともかく、僕が書くような教科書的色合いの濃い記事は、最新なもの使うより、今、現場で一番使われているであろう枯れたものが使われがちなんですよねぇ。
- GUI のサンプルはやっぱり Windows フォームでしょうか？
- Task クラスは .NET 4 に限られるので、Thread クラスを使った例を。
- データベースは DataSet、取得側のダウンロード形式は CSV、サーバー間連携は FTP でファイル アップロード、etc.
ただ、でも、そういう記事は5年10年という期間で、人を育てるんですよね。
その5年・10年とみられるものに、今現在の最大多数であっても、減少トレンドがはっきり表れているものを書いていいのか。それでも、ページビューのために最大多数なレガシーを書くべきなのか。
とかあるので、自分の場合はサンプル コードとかには絶対最新のライブラリしか使わないわけですが。ただ、記事の収益性を軽んじては絶対いけないと思うので悩むんですよねぇ、最近。これも、「新しいことを、既存技術者にもわかりやすく」と「見合ったコストで」をちゃんと気にしていかないと。
プログラミング言語の簡単さ/むずかしさ
Scala をディスると PV が増えると聞いて。Scala、難しいよね（棒読み）。
そういう冗談さておき。プログラミング言語が簡単/難しいって何だろう。
How vs. What
C# もよく言われるんですよね、「C# は簡単だ」というのも、「C# は難しい」というのも両方。で、よくよく話を聞いてみると、だいたい以下のような感じ:
- C# は文法が多い。概念覚えるのが大変だから難しい。
- C# はやりたいことをやれるから簡単。
文法の簡単さ
「プログラミング言語マスター ＝ 文法を覚える」だというなら LISP でも使ってなさいってば。あの言語、超簡単ですよ。() の中にトークン並べるっての以外に何も文法持ってないから。
こういう意見って、要するに、How（どう書くか）ベースの簡単さなんですよね。
やりたいことをやる簡単さ
プログラミングって手段であっても目的ではないわけで。What（何をしたいか）ありきだと思うわけです。
さて、そうなると、プログラミング言語の文法が少なければ簡単かというと、if とか for とかを書くのがあなたの目的ですか、と。
というか、この意味でいうと、「簡単さ」という言葉に占めるプログラミング言語文法の割合なんて大したことはなくて、ほとんど、ライブラリとかフレームワークの方に依存するのではないかと。
文法なんて、覚えることも少なければ、ここ数十年での進歩の度合いも大したことはないです。C# みたいに、たった10年でずいぶんと進歩した言語でみても、フレームワークやライブラリの方の追加・進歩と比べると大したことはない。
理不尽な難しさ
「難しさ」にも、必要に迫られてどうしようもない必要悪的なものと、意味もなく単に難しい理不尽なものとあるわけで。
と言っても、好き好んで理不尽な難しさを導入しようなんて人は、通常、いないわけで。ネタ言語ならともかく、少なくとも実用を目指すものならば。
理不尽な難しさって、だいたいは歴史的背景に起因するか、思慮が足りなかったかのどちらかで。
歴史的背景
まあ、できた当時の事情を考えればしょうがない。どうしようもないものの…
C++ の理不尽の大半は、歴史的にどうしようもないものが多く。
C#、たった10年しかたってないこの言語ですら、もはや黒歴史と言っていいものもあり。
特に、古い文書はいつまでも残る
今はさすがにもうって感じですが、C 言語って、長らく K&R の呪いみたいなものに悩まされ続けてたり。ANSI 標準化前の初版のスタイルで C 言語を覚える人が続出してしまったという。
そんなに頻繁に更新のなかった C ですらそんなので、まして、発表から10年、正式リリースから8年にしてバージョン 4.0 の C# なんてもう。ほんの少し昔に自分で書いた説明ですら「あっ、古い。このコードまねないで。」と思いつつも、直す時間取れない/メディアの都合でそう簡単に直せないものがどれだけあるかっていう。
思慮の足りなさ
だいたい、問題は後からでてくるもので。
これに対する解決策は、十分な試用期間を設けて、十分な人数で使ってみて問題を洗い出すこと。
となると、Java とか C# みたいに最初から企業の後ろ盾のあるものはともかくとして、個人ベースの開発から始まって、徐々にコミュニティが成熟してきたような言語は何かしらカオスを抱えてしまうもので。
個人的には、Scala にもやっぱりこの手の理不尽が少々あると思っています。
簡単さ/難しさ の要因
もちろん、ライブラリの充実、言語機能の充実。そして、前述の「理不尽」が少ないかなどもありますが、その他にも。
検索性
ライブラリやらフレームワークやらの挙動まで含めれば、プログラミング言語のすべてを覚えきれる人なんてほとんどいないわけで。ソフトウェアに求められる要望も多ければ、言語やライブラリが持つ機能も膨大な今、大事なのは機能の探しやすさではないかと。
目次検索
膨大な数の機能を、名前空間（パッケージ）とかクラスで分類・整理できた方が「簡単」だと思います。
「書くのが楽だから」とか「クラスって概念を教えなくてもいいから」って理由で、標準ライブラリをグローバル関数だらけにしてしまうと、検索性で非常に困ることになるかと。IntelliSense とかのコード補完機能で、補完候補が100個くらい出て来るともう、それは補完の価値半減。
検索エンジン
検索エンジンでの検索性でいうと、記号をやたらと使う言語は不利ですね。
その点、関数型言語というか、エンジニアじゃなくて数学者に媚びた感じの言語はつらいというか。
一貫性
他の文法との
文法が一貫してないことってそうないというか、一貫してないのは前述の「理不尽」にあたるはずですけども。
他のライブラリとの
まあ、新しいライブラリを使い始める際、使ったことのある既存のライブラリとの類推を求めるもので。
この辺り、標準ライブラリが強ければそれに合わせるサードパーティが多くなるとか、言語機能が充実していれば独自にデザインパターンの亜種実装しなくていいとかあり。
C# の楽さはこういうところにあると思う。snake_case, camelCase, PascalCase が混在すること少ないし、イベントハンドラーの登録口は普通eventになってるし。
他の言語との
例えば、.NET 言語なら、今となっては、「匿名メソッドとか作ったら Action か Func になる」というのを期待しちゃうんですよね。それが標準だから。でも、これが、F# だとそうならない。FSharpFunc とかいうクラスになる。
カリー化の都合とかだとは思うんですけど、こういう細かい独自路線が、「他の .NET 言語からの流入」を結構妨げてると思うんですよねぇ。
必要十分性
機能は多ければいいかというとそうでもなく。理想をいうと、目的に応じて、目的を達成するのに必要十分な量が一番簡単なわけですが。
この辺り、目的を絞れない汎用言語は不利。かといって、いちいち目的特化型の言語（DSL）を作ると、いちいち文法を覚える手間もかかるわけで。
結局、汎用言語＋DSL の混在開発を目指してみるか、せいぜい目的ごとに名前空間をきっちり分類して検索性を上げるかくらいしか手の打ちようもなさそうな。
注意点
目先の簡単さ
世の中、「短期的に見ると簡単なんだけど、長期的には負債にしかならない」っていう罠だらけ。
そりゃ、setter/getter 書くよりも、フィールドを public にしちゃう方が楽よ。その場は。
そりゃ、デフォルト引数とかあると、オーバーロード書かなくて済むから楽よ。バージョニングの問題さえなければ。
そりゃ、イテレーターとか書くよりも、入力・加工・出力を全部1つのループの中で書く方が楽よ。後々、ループの規模がでかくならなければ。
パット見の簡単さ
概念も難しくない、書くのも簡単。でも、絶対はまるなんてものも。
例えば非同期処理、特に同時実行制御（ロックとか）なんかがその最たるもので。意外と、同期コードって単純に見えるんですよね。コード上は。
でも、同時実行制御の本当のヤバさはテストにあって。100万回に1回しかでないバグとかざらで、どうやってテストしろと。チェックインのたびに100万回テスト走らせるの？確率論的に「100万回に1回」なとき、1,000万回走らせても出ないときはでないよ？
慣れによる楽さ
自分は C で覚えたから C にある機能に近いことだけ覚えるのが楽。諸先輩がみんな C だから、新人も C 教えるのが楽。そういう楽さはあるのでなんとも。
そしてレガシー化。
標準と革新
なんか Silverlight に関していろいろ言われているようなので。
発端となる記事：
- マイクロソフトが戦略変更。HTML5が唯一のクロスプラットフォーム、SilverlightはWindows Phone 7のプラットフォームに
- Microsoft は Silverlight をあきらめ HTML 5 へと走る
（少なくとも、後者（英語の原文の時点で）はタイトルがよくない・・・）
これの意味するところは：
- 「標準ベース」で、ほんとに iPhone, Android 含め、単一のコードでクロスプラットフォームを目指すなら HTML5 を使ってほしい
- 当面、Silverlight は Windows Phone 7 に注力
- PC 版は「すでにある」ものなので、立ち位置としては、MS 製品内のクロスプラットフォーム
- 結局のところ、iPhone でいうところの Obj-C、Android でいうところの Java と同じ立ち位置が Silverlight
- HTML5 との間には、「標準」と「革新」のトレードオフがあって、棲み分けられている
という感じかと思います。
もう少し補足でいうと：
- 開発リソースを HTML5 の方にさくのは、Silverlight は現時点で結構安定したという証
- MS 技術内のクロスプラットフォーム（3 screens の中核）という位置づけは変わらない
- 今、スマートフォンがホットな話題なので、iPhone, Android, WP7 間のクロスが話題になりがちで、この文脈だと 「HTML5 こそが真の、唯一のクロスプラットフォーム」と言われるのもしょうがなく
- かといって、既存のデスクトップ アプリ資産と WP7 のクロスとなると、WPF/Silverlight の出番
Microsoft が HTML5 に本気なのも事実ですけども、Silverlight はなくならない。
「標準」と「革新」のトレードオフって書きましたが、つまるところ、誤解恐れず端的に言ってしまうなら、
標準っていうのは、「10年遅れくらいで、かつ、互換性に悩まされる（標準化漏れや対応遅れのバグフィックスまで含めれば10年どころではなく遅れる）のを覚悟の上でも、少しでも間口を広げたければどうぞ使ってください」というもの
だと思います。
UI（プレゼンテーション層）の標準化はほんとに大変なもので、そのくらいの遅れは覚悟しないと、標準とかは無理だと思います。UI に対する要求が高い場合、「iPhone は Objective-C で、Android は Java で、WP7 は Silverlight で、3重開発した方がマシかもしれない」ってレベル。
となると、ほんとのところ大切なのは、クライアント側の技術選定の前に、サーバー側を「サービス化」しておくことなんですよね。「UI まで含めて1つのシステム」みたいな作り方はダメで、任意のプログラムからサーバー上の機能を利用できる形で作って、UI はいつでも差し替えれるようにしておくべき。
数か月も経てば、過去の自分は赤の他人
コンソール アプリケーション作るのってむちゃくちゃ難しくない？
といっても、「僕の基準では」なんですけども。僕がアプリ作る上で絶対外せないと思ってる条件が、
作ってから3か月以上放置した後でも、ドキュメントもソースコードも全く読み返さずに自分で使えること
なんですよねぇ。そのせいで、コンソール アプリを書くなら・・・
- 使いやすくてかつ覚えやすいコマンドってどんなだろう
- オプションにするにしろ設定ファイルにするにしろ、それにエイリアスを付けるにしろ、
- 長いと打つのしんどいし、略称だと覚えにくいし、どう略したかで間違うし
- IntelliSense欲しい
- 文字列から色んな方への変換を適切にやらないと
- 標準でコンバーターとか検証属性欲しい
- 絵を使って2次元的に表示すれば一目でわかるようなものを、1次元的に入力してもらわないといけない
- 相当な工夫がないと、ドキュメントなしで使えるものにはならない 等々、相当ハードル高い。結局、スクリプトをダブルクリックしたら後は全自動みたいなタイプのもの以外は、コンソール アプリを書ける気がしないという。
WPF 慣れしてて、それで実際、素人さんにマニュアル一切なしでアプリを普通に使ってもらえてるという経験もあり、気が付けばコンソール アプリを書けない身に・・・
今日小耳にはさんだ話
- 「ベンダーロックは避けたいから Java で」というけども、「弊社は JVM の全機能を自前実装していて、全ての責任を負えます」というとものすごく受けがいい
- ベンダーロックって何なんだっけ？
- ↑ 結局、国産信仰かもね。国内大手にならロックされたい
- Microsoft にはロックされたくないっていうけど、Oracle データベースはいいの？
- 世界一の金持ち（だった）企業に金払いたくないという出る杭打つ思想？
言語設計
「言語設計者たちが考えること」などという本を買って呼んでいるわけですけども。Anders Hejlsberg のところを主に。この本を読みつつ、自分的に思うところなどをまとめてみる。
フレームワーク
ここ2・30年ほどを見て、言語は大して進化してない。進化してるのはフレームワーク。
属性、イテレーター ブロック、LINQ や dynamic を導入している C# を基準に見てすら、それ以上にフレームワーク側の進化の方がはるかに大きい。LINQ や dynamic も、言語上は薄い構文糖衣で、多くの部分をフレームワーク側に寄せている。
今は、言語、フレームワーク、開発ツールが切り離せない。
新言語
新しい機能が欲しいんなら既存の言語の拡張でいい。新しい言語を作りたいのはむしろ機能を削りたい時（危険だったり誤用を招く機能をなくしたい時）。
汎用言語の新機能は、汎用であるべき。LINQ はデータ アクセスという domain specific ではあるけど、拡張メソッド、匿名型など、汎用な細々とした機能の組み合わせで実現している。単純に言語内に SQL 埋め込むだけのような実装方法だったら決して採用されていない。
DSL
外部 DSL だと「特殊な文法の中で、式だけは C# のものを流用したい」って要件が多すぎてつらい。言語の9割方はありふれてて使いまわせる要件で、残りの1割程度に domain specific が詰まってる。
逆に、内部 DSLで 困るのは、制限を掛けたい時。機能が多すぎるのが煩雑さ・誤用を招くから機能制限したいけど、内部 DSL だと元の言語の機能フルに使えてしまう。
多分、必要なのは、既存言語を部分的に流用する機能。
ここ10年ほど注目浴び続けてる domain っていうと並列処理だけども、immutable がいいとか、状態を共有したくないとか色々ある。で、immutable って機能を足す方は簡単。問題は、mutable な既存機能をどう制限するか。（言語全体で制限するのはかえってまずい。GUI 部分みたいに本質的に mutable な部分はやっぱ mutable にやった方が。）
動的
動的言語の良さはメタプログラミング。でも、そのためだけに型の静的チェックをなくすのはあまりにもデメリットが大きすぎる。
注意： 動的実行・動的コード生成をしてても、型チェックだけは静的にできる。
さて、WordPress になったところで再度、PowerPoint 貼り付けテスト
今度はどうかな？
ちなみにこの資料、書くに至った経由は以下のような話と、それに付随する twitter でのやり取り。
PowerPoint 埋め込みタグのテスト
SkyDrive にアップした PowerPoint（と Excel）、いつの間にか iframe で任意のページに埋め込みるようになってたのね。
http://sqljp.com/yoshihirokawabata/archive/2010/09/24/27108.aspx
で、試してみようとしたものの・・・
↓
↑
Live Writer 上は表示されてるんだけども、実際アップロードすると iframe タグが消える・・・
連携取れてないなぁ・・・
固定サイト（pinned site）
IE 9 β、微妙なところも結構あるので Connect に要望入れたりもしているわけですが。
とりあえず、Windows 7 のタスクバー統合機能（固定サイト（pinned site）機能）を試してみたり。++C++; のトップページに meta タグ色々追加。あと、これだけのためにアイコンいくつか作成。
固定サイトの詳細に関しては、以下のページ参照。
現状のスマートフォンやら WP7 に対してぼやき
twitter でぼやいてた内容、ブログにもしとこうかと。
ケータイで大量に文章書くよ
まず、↑この記事曰く：
競合製品には備わっている重要な要素がいくつか欠けている。その中でも無視できないのが、コピー＆ペーストがサポートされていないことだ。筆者は携帯電話で電子メールを頻繁に利用する。そのときに1つの電子メールから大量の文章をコピーして、それを別の電子メールに貼り付けることができれば便利だ。筆者は時折、「BlackBerry」で1本の記事を丸ごと執筆することがあるが、Windows Phone 7でそんなことはできない。
これ、結構僕もやるんですよねぇ、電子メールとかからのコピペ含め、それなりの記事を全部携帯電話で書いちゃうっての。例えば、「釣り記事書いたらほんとにホットエントリーになっちゃった」で有名な「僕が TeX を使うのを辞めた 10 の理由」は、ほんとに電車の中で、立ったまま、片手で全部打ったものです。それを家宛に送って、hatena 形式に整形＆動画貼り付けだけして投稿。
あと、記事だけでなく、実は毎日日記付けてたり。ブログみたいなのじゃなくて、ほんとに公開しないプライベートなやつ。もうかれこれ10年近く、ほぼ全部ケータイで。だいたい、500～2,000文字くらいですかね、ファイルサイズからすると。大体これも電車の中で。
なので、文章打ちにくいとか、かなり死活問題。qwerty 配列とか、そりゃ PC のキーボードで、座って両手で、フォームポジションで打つものだから。それを親指だけで打つとか無理。というか、「立ったまま片手で」が満たされない限り、無理。
脱 qwerty
あと、ケータイにずっと期待していたのは、脱 qwerty だったんですけども、これだけスマートフォンに qwerty キーボードが載っちゃったら、もうそのチャンスはないですよねぇ。非常に残念。もはや、qwerty キーボードとか、人類の負の遺産だと思う。COBOL 並。
ちなみに、dvorak ならいいってもんではないですから。キーボードの時点でナチュラルじゃない感じが。
もちろん、じゃあ、手書きがいいかというと、タイピング慣れた人なら手書きよりも qwerty キーボードで打つ方が速いわけで。何か、もっと早く文字入力できるメディア出ないとダメでしょうねぇ、置き換えは。dvorak は慣れると速いって言いますけど、せいぜい数％でしょうしねぇ。数％じゃ置き換えは無理ですよね。
で、ケータイに限っていうなら、サイズの制限で qwerty キーボードでまともなスピード出ないわけですよ。親指だけで使うという制約上、どうやっても。その制約下なら、いくらでももっと早く打てる方法があるはず。自分なら、10キー使ってベル打ちが相当早いですし、iPhone のフリック入力とかはかなりいい感じだと思います。
特に日本語は、ほぼ子音と母音が交互に出て来る、というか、50音表みたいなきれいな文字分類がされてるわけで、ベル打ちの2タッチ入力ってかなり合理的なシステムだと思うんですけども。もちろん、日本語だけがターゲットだと市場狭すぎですけども、同じような考え方、韓国語とか中国語でも行けそうに思うんですよね。少なくとも、韓国語は日本語同様、子音1つ＋母音1つですし（末尾に限り子音だけ部分がありますけど）。中国語も、声調の扱いだけクリアできればいけないかなぁ。
触覚
ずっと昔から繰り返し言ってることですけども、タイピングは目で見てやるものじゃなくて、触覚使ってやるもんなんですよね。ボタンに触れてるというフィードバックがないとちょいきつい。てか、タッチタイピングできる人ならわかると思いますけど、目は、出てきた文字の方見てないと打てないでしょう。
で、ちょっと期待したいのが↓これ。
記事中ではエロい方向に妄想膨らむような紹介のされかたですけども、そんなのじゃなくてまずタイピングだろうと。
特に、これ、やりようによっては「触覚フィードバック付きのフリック入力」とか作れるんじゃね？という淡い期待が。ぽっちをぐにぐに動かすことでタイピング。結構いい具合にタイピングできる気がするんですけども。
そして WP7
ローンチ時には qwerty キーボード搭載機が多そう？スクリーン キーボードは qwerty のみ？スクリーン キーボードのカスタマイズ不可？
うーん。
業務端末としての WP7
そんな感じで、まあ、出た直後はまだまだプライベートの利用はきついかなぁと思うものの（でも人柱として買っちゃいそう）、業務端末としては期待されてるんじゃないかなぁという感じも。ハンディ端末の類。
実際、最近、Android や iPhone はおろか、Nintendo DS 使った業務アプリ結構増えてるって聞きます。というのも、専用のハンディ端末作るくらいなら、DS のハードウェアのお値段考えると、多少ソフトウェア開発に金かけても十分安くなってしまい。あと、ゲーム会社の持ってる UI 的なノウハウを使って、端末の UX 高められないかという発想も当然あり。
そこで、WP7 で Silverlight ですよ。UX！UX！UX!（大事なことなので3回叫びました。）PC 向けとハンディ端末向けで2重開発の苦が軽減されるのもポイント。
