‘未分類’ カテゴリーのアーカイブ
Null非許容
先週、「C#にもNull非許容な型が欲しい」という話をされたものの「うん、欲しいね」としか返せなかったり。要望は昔からあるけども、実際入れようと思うと結構大変。という話、説明しておいた方がいいんだろうなぁと思ったので、ブログにしてみることに。
先に結論の要旨だけ書くと、以下のような感じ。
- C#だけで完結する問題じゃなく、.NETレベルで対応するのは今からだときつい
- Code Contracts使って契約プログラミングするのがいいよ
以下詳細。
公式の見解
Anders Hejlsberg も、「もしもの話」として、1からの再設計が許されるなら C#/.NET をどうしたいかという質問に対して「Null 許容性の見直し」を挙げています。
一時期、結構頻繁にそういっていたと思います。少し検索して出てきたのでいうと、以下の Q&A インタビューの、1:00:00 からのくだり。
言っていることは以下のような話です。
-
参照型/値型の区分と、Null 許容/非許容 の概念は独立させておくべきだった
- 今、値型に関しては、Nullable<T> によって、Null 許容な値型が作れるけども、参照型は常に Null 許容になってしまう
- 参照型も、Null 非許容な参照型が欲しい
これは本当に「もしもの話」。1から作り直すのであればどうするか、逆にいうと、直したいけども今から直すのはかなり厳しいという話だったりします。
C#/.NETは、個人的な予想としておそらく最低あと10年は後方互換性を維持しながらの発展になると思うので、この「もしも」はあったとしても10年以上先の話。
C#だけの問題でなく
今、値型に対する Null 許容は、値型 T に対して、T? と書くことでできるわけです。
int? x = null;
これの逆で、参照型 T に対して、例えば、T! とか書いて、Null 非許容を表すのはどうでしょう。
T! x = new
T(); // OK
T! y = null; // エラー
インスタンスが常にnew演算子に作られる分にはこれでいいんですが、問題はメソッドをまたぐ場合。例えば、ファクトリを介するだけで破たんします。
var factory = new
TFactory();
T! x = factory.Create(); // こいつが null を返さない保証は誰がするの？
T! y = T.Parse(Console.ReadLine()); // 同上
この例の、CreateやParseの戻り値が T! なら万事解決かというとそうでもなく。2点ほど問題があります。
-
既存コードはどうする？
- 「全部を T! に書き換える、さもなくば T! は使えない」という状況になるけども
-
T! はどうコンパイルされるべき？
- C#で閉じている分にはまだしも、他の言語ではどうする？
C#だけなら、属性を付けるとか、あるいは、以下のような構造体に置き換えるようなコード生成で対処できるかもしれない。
struct
NonNullable<T>
where T : class
{
public T Value { get; private set; }
public NonNullable(T value)
{
if (value == null)
throw new ArgumentNullException();
Value = value;
}
}
でも、それだと結局、虚偽申告（実際はnullを返すクセに非null属性を付ける）ができたり、実行時チェックとかにしかできない（ビルド時のチェック効かない）ので、あまり有用にならず。
有用さがいまいちなのに中途半端な妥協実装をしても、後々足かせになる（将来的にもっといい方法があっても入れれなくなる＆その他破壊的変更の原因になりかねない）という問題もあります。
Code Contracts
現状のC#で非null保証をしたければ、Code Contractsというのを使って、契約プログラミングします。Contractクラス（System.Diagnostics.Contracts名前空間）を使って、契約表明できます。
public static T Parse(string s)
{
Contract.Requires(s != null);
Contract.Ensures(Contract.Result<T>() != null);
return new T(); // 仮実装
}
これで、Parseメソッドがnullを返さないことを保証します。
さてここで、「なんだ、それで万事解決じゃない」と素直にならないところがまた… 現状のBestではあるものの、まだちょっとめんどくさい感じ。
このCode Contracts、以下のような仕組みで動いています。
-
このRequiresやEnsuresメソッドは、実際には何もしない
- Conditional属性が付いていて、コンパイル後に消える
-
静的検証
-
Visual Studio 2010に関しては、Code Contractsの別途インストールが必要
- 有償エディションにしか入らなかったはず
- その上で、コード解析オプションをOnにしないと働かない
- 静的コード解析、そこそこ時間がかかる
-
-
動的検証
-
静的解析しきれない部分を検証するために、動的検証コードを入れるオプションもある
- 契約の表明はあくまで自己申告なので、やろうと思えば虚偽申告できる
- Code Contractsに対応していないライブラリを使うと、必然的に何らかの動的検証が必要
-
この場合、（C#のコンパイル結果の）ILコードを書き換えて、検証コードを埋め込んでる
- 契約違反は実行時例外発生
- もちろん、検証コード分、実行時の負担になる
-
ちなみに、.NETの標準ライブラリには、.NET 4から、Code Contractsによる契約が表明されています。また、書いた契約をドキュメントに反映する仕組みも持っています。
まあでも、説明中に、なかなかに警戒心を抱くキーワードが見受けられるわけです。「有償エディション」「時間がかかる」「自己申告」「IL書き換え」等々。Contractクラス自体はすでに標準ライブラリに含まれているので積極的に使っておいて損はないんですが、仕組みを知らない人が「あれ、Contract使ってもチェックしてもらえないんだけど？何これ？使えねー」と言ってるのを何度も目にしたりしてます。Ensuresの書き方が結構めんどくさいのも嫌な感じ…
元帥のイメージしかない
昨日の深夜に、ちょっとばかし、marshallingという英単語の意味について思い悩んだり。
辞書で引いて、「整列する」っていう意味じゃないの？とか思うかもしれないですけど、実際その通りなんですけど、記事書いたり人に教えたりしようと思うと、それだけじゃ不十分だと思うんですよね。
英語ネイティブな人がmarshalという語に抱くイメージと、日本語ネイティブな人が整列という語に抱くイメージ、ほんとに一致してるのかなぁとか。
yield ― 単語の文化的背景
過去、C#にイテレーター構文が導入されたとき、yieldの意味に相当悩みました。
もちろん、辞書を引けば「譲る」なんですけども、この「譲る」がどうもしっくりこなくて。最初、財産譲渡的なイメージの「譲る」で考えていて、一度yield returnした後、次に処理を再開するイメージが付かず。
で、結局、納得いったのは何かというと、前方優先の道路標識が「YIELD」なのを見たとき。そういう意味の「譲る」なんだという。「他の車に道を譲る」ってのと同じイメージで、「他のスレッドなりタスクなりにCPUを譲る」様子を思い浮かべて初めてしっくりきたという。いったん停車して、後続の車に道譲っても、別に走行自体止めたわけじゃなく。
オオカミ ― 単語のイメージは文化に依存する
こういう、イメージまで作り上げなきゃとか思うと、やっぱり単語をただ訳すだけってだと不十分になってきます。たとえ、ほんとに同じものを指す単語であっても、イメージって文化によって違ったりするので。
良く引き合いに出されるのが、オオカミ（イヌ科のあれ）を比喩表現として使う場合にどういうイメージで使われるかというもの。日本語だと、たぶん、「オオカミみたい」っていうと、一匹狼のイメージ、要するに「孤高」だったりするわけです。一方で、英語でwolfishっていうと、残虐性・凶暴性を表す単語。狼男が月夜に暴れるあのイメージ。
言語をまたがなくても、日本みたいな均一化を好む社会の内部であってさえも、育ちが違えば言葉のイメージが変わったりします。
自分は、ある用語に対して直訳な訳語でしっくりきたとします。が、他の人は同じ単語に同じイメージを持っていないかもしれない。人に何かを教えるときには、そういうところにまで気を回さないと行けなかったりします。なるべく、1単語で済まさないで、いろんな言葉でイメージを伝えるのが意外と大事。
static ― 今でもその語が適切か
またもう、歴史的背景があったりすると、作られた当初の様子を知っているかどうかによって、納得しやすさがもろに変わるわけで。
例えば、JavaやC#だと、クラスに属する/インスタンスによらずクラスにつき1個だけのメンバーを静的（static）というわけですが。
内部実装を考えると確かにstatic（プログラムと同じ寿命で、ずっと同じ場所に確保され続ける）ですけども。意味的にはクラス メンバーとか、共有メンバーとか読んだ方がしっくりくるわけで。実際、OOP用語的にはクラス メンバーって言い方結構されますし、VBだとSharedキーワード使いますし。
元々はC言語由来で、関数ローカルなstatic変数（関数を抜けても値が残り続けるローカル変数。グローバル変数と同じ寿命になるものの、その変数を参照できるのは関数内でだけ）から来ていて、それをクラス メンバーに流用した（実際、コンパイル結果的には、スコープが狭まったグローバル変数でしかなく、関数内staticと一緒）のが始まりで。
でも、JavaやC#は、関数内staticもなく、内部実装を意識させるようなプログラミング言語でもなく。
特に、ベテランの人が新人相手に教える時ほど、これがネックになったりするんですよねぇ。長い歴史を経て今の自分があることを忘れて、自分基準で言葉を選んでしまったり。
おまけ: LPCTSTR ― 何それ？難読化？
ちょっと本題からそれますけども、昨日、ちょうど、Win32 APIの文字列（を表すtypedef）についての話なんかも出てたり。
LPSTR, LPWSTR, LPTSTR, …とか、今見たらもう、難読化されたコードか何かに見えてくるよなーという。
- L: long。昔、long pointerとshort pointerってのがあった。16ビットから32ビットへ移行した時期の名残。
- P: pointer。
- C: const。文字列内の書き換えができるかどうか。
- W: wide。8ビット文字（char）か、16ビット文字（wchar_t）か。
- T: textの略？コンパイル オプション次第でcharかwchar_tかを自動切り替え。
の組み合わせ。割かし黒歴史。
未だにWin32 APIが現役なので、WindowsでC++使うなら通らなきゃいけない道ですが。毎年、これを新人に教えるお仕事が待っています。
おまけ: ε-δ論法 ― 言葉の意味を考えて使っていますか？
そういや、専門用語ほど、みんな言葉の本来の意味を考えずに使ったりしますよねぇ…
大学数学で多くの学生をくじくことで有名なε-δ論法なんてその最たるもので。
|x|<δ → |y|<ε
みたいな式があったとき、この式だけを見てまず思いつきそうなのは、「δを決めればεが決まる」なんじゃないでしょうか。
ε-δ論法は、それを、「εの方を先に決める」というように、順序を逆にするのがポイント。どんなεだろうと、従属変数δ(ε)が求まる。だから、Greekアルファベット順だとδ→εなところが、逆のε→δの順番でならんでる。これが、極限という概念を厳密に定義するにことに成功した秘訣。
とかいう話を学生（理学系含め）相手にすると、十中八九びっくりされるんですよねぇ。
みんな、難しい理論だから難しい意味が込められているに違いないとか思うみたいです。そのせいか、あくまで用語として覚えてしまって、言葉に込められた意味まで考えてない。
marshalling ― 話を戻して
そんなくらい、言葉の持ってるイメージを気にするので、marshallingについても「整列」って何？とか思うわけです。
- メモリ レイアウトが違う可能性あるからレイアウト並べ直せという意味？
- serializationと同じ扱い受けてるみたいだし、結局、serializationと同じような感覚？
- データをディスクに保存するにしろ、通信に使うにしろ、バイト ストリームを通すわけで、そこを通せるように直線的にデータを一直線にならべる ＝ 直列化
- スレッドとかプロセスとかの境界にも、そういうストリームが挟まっているイメージ？
- お家がくっついた際に、家紋を統合する作業をマーシャリングというらしいし、それのイメージも入ってたりする？
等々。
serialization（一直線に並べる）よりは、marshaling（並べるという意味合いだけ）の方が制約の少ない単語なので、1の意味合い（一直線でなくてもいいから、とにかく並べ直せ）なのかなぁ。
またもう、この単語、整列は整列でも、軍隊の部隊整列の意味で使われることが多い（名詞で使うと「元帥、最高司令官」の意味だし）んで、その軍隊色はイメージに含めた方がいいの？関係ないの？とかも悩んだり。ユーザー コードが整列するわけじゃなく、システム様がトップ ダウンで整列するわけですし。
そしてまた、staticみたいに、歴史的背景があって、この言葉が生まれた当初の背景を知っているともっとしっくりくる解釈ができたりするのかな？とかも勘ぐってみたりするわけです。marshallingという言葉を使いだしたのは、MicrosoftのCOM？
追記1: CORBA
夜が明けてから頂いたご意見1。
COMよりもCORBAの方が先っぽい。その当時、marshallingという用語を使っていたかどうかまでは不明とのこと。
追記2: 軍事/祭事のイメージであってるっぽい
同、ご意見2。
「システム全体を把握しているmarshal（名詞用法だと、司令官、所長、式典担当者）の案内がないと通れないのがプロセス境界」とのこと。
両側のプロセスのコンテキストを把握して、通るデータを適切に並べ直すのがmarshalのお仕事。
結局、タイトル通り、元帥のイメージでよかったようです。自分がしっくりきてなかったのは、「組織のトップ＝構成員を正しく配置する人」というイメージがなかったせいかも。自分もやっぱり日本人だと思いました。
2011 in review
WordPress.com 統計チームは、2011年のあなたのブログの年間まとめレポートを用意しました。
概要はこちらです。
ルーブル美術館には毎年850万人が来場します。2011にこのブログは約88,000回表示されました。ルーブル美術館の展覧会に置き換えると、それだけの来場者が訪れるには約4年かかることになります。
1人Advent Calendar反省会
相変わらず裏話が大好きなわけですが。とある25日の反省会。
やっちゃってたわけですよ、Advent Calendar毎日1人で更新。
発端っ！
開始当初にtwitterでつぶやいてたりはしましたけども、状況の説明から。
- 中の人などいない。というか、島本和彦先生と炎尾燃先生は別人（補足1参照）。
- 普段は委員会方式（複数人か関わってもらってる）ではあるもの、今回はほんとに1人。
- 事前準備なし。11月29日に思いついた瞬間にWordPress.comにアカウント作って、そこからネタも考え出す。
- 毎日ガチ。
ぎりぎりっ！
かなり行き当たりばったりでした。
書きためは、たまってた時で最大2日先くらいまで。ほとんどはカツカツの状態でした。
11月30日の時点で、タイトル案だけは20ネタくらい列挙しておいたんですけども、実際のところ後半は微妙で、だいぶ変更かけてます。
まあ、1日で終わらせるはずだったものを2日に分けた（Wordで5・6ページ超えたら分けるという方針）のもあって、微妙なのは統合orカットしてます。
後からの思いつきで足したのも多いです。DynamicとかILの話は完全にあとからの思いつきです。
1人っ！
ほんとに1人。
突発の思いつきだったからというのもあります。そんな、2・3日前に急に「書いて」などとお願いできるわけもなく。特にギャラが出るわけでなし。絵がないのもそのせいです。絵は自分で描いてるわけではないので。
あと、品質保証の問題もあります。書く人が変わるとどうしてもキャラが変わっちゃうんで。
シリーズ
キャラが変わるという話に関しては、アメコミみたいなもんだと思っています。アメコミは、日本の漫画と違ってスタジオ製作ですし、シリーズ変わるとスタッフ変わる。キャラも相当に変わります。監督によってルパンのキャラが違うようなものです。それで良し。
ただ、せめてシリーズは分けた方がいいのかなぁというのが最近の感想。「ドラえもん」と「怪物くん」程度には。C# Fたんと、C#たんA。
-
Fの方は
- 研究者肌で、ほっとくとすぐに5年・10年先のビジョンを考え出すんだ
- 仕事は夢を与えないと。大人がつらいつらいって言ってたら、子供が大人になりたがらないよ！
-
Aの方は
- だいぶ現実的。個人レベルじゃなくて、組織全体としての短期～中期の最適解を求めるよ
- 仕事は意地を通す。土日も勉強！
あっ、FとかAってのは例え話ですからね。2人だけでもないんで。CLAMP辺りで例えた方が良かったか。
他との兼ね合いっ！
僕本体がC# Advent Calendarへの登録してませんが、これは別に、1人Advent Calendarの方とは無関係です。1人の方を思いついたのが29日で、C#の方はその前にだいたい埋まってましたし。Aさんの方と協議の上、最後にC#たんを混ぜときましたが、この時点では、WordPress.comのアカウントとることすら決めてませんでした。というか、CodeZineの方書くかという話もありました。
単純に、あんまり季節もののイベントに興味がないだけで。人足りなさそうならヘルプで入るかーくらいに思っており、まあ、C#には必要なかったみたいですね。
一方で、SilverlightとかPowerShellとかAzureとかは、人手足りずに困ってるみたいだったので、ヘルプ入りたかったんですけどもね。1人Advent Calendarの方でネタと時間を使ってしまい、なかなか入る余力がなく。
1人の方で、PowerShellもAzureも使いまくってるんで、事前にネタの日取りが決まっていれば入れたんですけどもねぇ。行き当たりばったりで、日取りも結構変わってるので厳しかったです。
2度はないっ！
もう2度とやらねー。というか、やろうと思ってもできないでしょうねぇ、そうそう。
ついうっかりやりすぎた感満載ですねぇ。こんなのをブログでやってたら、なんかもう不当廉価販売的なダメさ。たぶん、別のどこかで流用はすると思いますが。文字列処理とかコレクションの話は、C#入門の方にでも移します、たぶん。残りもきっとどこかで。
まあ、自分が書ける文章のスピードの限界がわかってきたのは大きな収穫でした。しかしこれ、100ページ、10万文字くらいは書いてるんだなぁ…
反響っ！
話題になるのは最初だけですねぇ。
みんなでやってるAdvent Calendarも、後半の人きついんじゃないでしょうか。2週目入ったあたりからガクッとPVも落ちるし（ちょうど忘年会シーズンでもありますし）、ネタも被り出すし。特に、最後の3連休はヤバいですね。本気で人いない。
ブログって、長期間続けて、検索にも引っかかり出さないとPV伸びないんですよねぇ。1か月集中で濃い内容とか、実はあんまりよろしくなくて。普段から継続的にちょろちょろ書いてて、時々大きなの書くくらいがちょうどいいと思います。
記事ごとの傾向
.NETだけよりは、他との比較が強いですねぇ…。ネイティブと.NETの回のPVが良かったです。まあ、両方まじめに勉強するのってしんどいですからねぇ…。書く方からするとしんどいんですけどねぇ、比較。本題とそれたところで鬼の首取ったかのように重箱の隅つつきだす人がいっぱい寄ってくるので。
あとは、イラストレーションがきっちりできてた回のPVが良かったと思います。値型とか、コレクションの内部実装とか、.NETの中間言語の回とか。ほんと、絵が大事。
逆にダメなのは、概念論な回でしょうか。2種類のLINQとか、規約、実装、アルゴリズムとかの回はいまいちです。まあ、あの手の話も必要なものだと思うので、それがわかってても書きますが。そういう意味では、「25個書く」ってのは良かったかもしれないです。普段、優先度低くて書かないことまで手が回って。
ガチだよ、ガチっ！
萌えキャラにしてても、ぬるい路線はやる気なかったり。別シリーズでぬるい路線描くのもあっていいと思うというか、やってくれる人募集（補足2参照）！でも、自分が書くのはガチ。
とはいえ、初心者お断りにしてるつもりはないです。
世の中はどんどん高度化していってるんで、学ばないといけないこともどんどん高度になっています。高度なことを濃縮して、一気に学んでもらわないといけない。
いつも言ってますけども、簡単なことを簡単なまま教えても、難しいことを難しいまま教えても価値がない。難しいことを簡単に学んでもらわないといけない。だから、
- とっつきやすいキャラ使いつつも、中身は高度
- 難しいこと書いてても、前提知識はあまり求めない
そういう話を書く。
ヒーローっ！
2008年のMicrosoft Conferenceのキャッチフレーズは、
heros happen {here}
ヒーローはここにいる
でした。個人的に、これ、かなり気に入ってるんですよねぇ。
ヒーローが必要、ヒーローが。大人が子供に対して、あるいは、先輩が後輩に対して、追いたいと思う背中を見せなきゃいけない。ヒーローでないといけない。
開発者が、奴隷の鎖自慢みたいなデスマ自慢大会やってる世界はどうかと思うわけですよ。それやったら、だれもそんな職に就きたいと思うわけがない。
C#たんの位置づけは、このヒーローなんですよねぇ。ただ、魔法少女だと思ったらドラゴンボールだった的な。管理局の白い悪魔的な。
広範囲っ！
最初から幅広く書くつもりでいました。理由は3つほど。
言語系の利点
1つは、特定製品系のAdvent Calendarと違って、せっかく言語系で、いろんな製品横断できるんだから、そうしようかと。MS MVPの間でも言われるんですよね、言語系はいろんなネタに顔出せていいよねって。
必要な知識
もう1つ、今もう、あれくらいの範囲の知識が開発者にとって必須だと思うんですよねぇ。
厳しい世界になっていると思います。でも、それは、.NETが厳しいんじゃなくて、世の中のITに対する要求が厳しい。もう誰も、町工場で作られたバイクは買わないんです。
現在のベテランさんが何年もかけて築き上げてきたものを、一足とびに学ばなきゃいけない。
ガチだって話のところでも書きましたけど、改めて。記事書く側にできることは、難しいことを簡単に説明する、高速道路の整備。これから学び始める人はそれに乗って、何年もの月日をすっ飛ばして、早く追いついてもらって、その先で新しい苦労をしてもらわなきゃいけない。
知識の幅を広げてほしい
そして最後。マスターしたとまでは言わずとも、なんとなく聞いたことあるかどうかだけでもだいぶ違うはずなんですよねぇ。
割かし、みんな、今現在自分が知ってることをベースに常識を語ります。ほんとに、ごくごく狭い世界の常識を。「常識に縛られる」ってのはそういうことだと思うんですよねぇ。
何も知らない人から出る博打みたいなアイディアじゃなくて、専門外のことも含めていろんなこと知ってるからこそ出てくるアイディアこそが、常識に縛られない斬新なアイディアなんじゃないかと。
なので、広く調べていきたい。
裏話っ！
ちなみに、こういう裏話まで書き残しておこうと思うのは、書くノウハウ自体も伝えたいから。
補足1: 炎尾燃先生
島本和彦による、いわゆる漫画家漫画、「燃えよペン」＆「吼えろペン」の主人公。
燃えよペンの巻末おまけコーナー「熱血マンガ テクニック コーナー」でこんなやり取りもあったり。
- 編集さん: 先生！今までやってきたことは―「熱血マンガ」のテクニックではなくって……熱血して漫画を描くという、熱血「マンガテクニック」なのでは！？
- 炎尾燃: その二つの何がどう違うのだ！？
とかいうくらい、島本和彦本人も熱血なら、炎尾燃も熱血なのもあって、何かと「実話？」とか言われたり。
そこで出てくるのがこんなセリフ:
最初に言っておこう！この物語は現実の島本とは全く関係のないフィクションであると！！
実際、「作家の本音は小声で言わせ、大ゴマでは別のことを言う」みたいな方針だそうで。本音を大きく書いちゃうと胡散臭く見えるので。
そういうことだ！
補足2: 別シリーズ
キャラはできてるんでやりようはいくらでも。
SilverlightへのPython組み込み
このエントリは Silverlight Advent Calendar 2011の17日目です。
いやー、NuGet便利だなー、的な。
経緯
- なんか、動的実行の類の記事書くか
- IronPython、NuGet経由で入手できるし、Silverlightプロジェクトでも使えるじゃない
- IronPythonで入力した式のグラフでも出してみるか
- あっ、Silverlight ToolkitのData Visualization（チャート コントロール）もNuGet経由で入るっぽい
- 作るのちょろそう！
- ちょろかった←今ここ
まずはNuGet
Silverlightのプロジェクトを作ったら、「参照設定」を右クリックして、「Manage NuGet Packages…」をクリック。
IronPython
IronPythonは、「iron」で検索すれば見つかります。
codeplexの方で手に入る最新版が2.7で、NuGetの方は2.6なので、実は1バージョン古いですが…
チャート コントロール
Silverlight Toolkit – Data Visualization (Charting)は、「datavis」で検索すれば見つかります。
Silverlight Toolkitは、Silverlight SDKの方に入りきらなかった（リリース タイミングに間に合わなあった）コントロールを、codeplex上で公開しているものです。安定度に応じて、
- Mature: 十分成熟。SDKの方に取り込み
- Stable: 安定して使える
- Preview: バグってる可能性あり。API変更もあり得る
- Experimental: 実験段階。場合によっては開発打ち切りもあり得る
の4段階あります。Data VisualizationはPreview段階です。
サンプル プログラム
ということで、1・2時間ほどでサンプル、作りました。
- ソース
コード: http://ufcpp.net/study/csharp/source/IronSample.zip
- デモ
ページ: http://ufcpp.net/study/csharp/ClientBin/IronPythonChart.html
ロジックらしいコードは↓これだけ。
public void Run()
{
try
{
var scope = _engine.CreateScope();
_engine.Execute(“from math import *”, scope);
var f = _engine.Execute<Func<double, double>>(
“lambda x:” + SourceCode, scope);
var p =
from i in Enumerable.Range(0, Count)
let x = Delta * i + Min
select new Point
{
X = x,
Y = f(x),
};
Points = p.ToArray();
}
catch
{
Message = “不正な計算をしました“;
}
}
残りはデータ バインディングと、MVVM的お約束コードです。お約束コードの方が多いです、ええ。
XAMLの方は、チャート コントロールがらみの部分だけ出しておきます。
<UserControl
x:Class=”IronPythonChart.MainPage”
…中略…
xmlns:charting=”clr-namespace:System.Windows.Controls.DataVisualization.Charting;assembly=System.Windows.Controls.DataVisualization.Toolkit”
>
<Grid x:Name=”LayoutRoot” Background=”White”>
…中略…
<charting:Chart Grid.ColumnSpan=”3″ LegendTitle=”x”>
<charting:Chart.Series>
<charting:LineSeries
Title=”{Binding SourceCode}”
ItemsSource=”{Binding Points}”
IndependentValueBinding=”{Binding X}”
DependentValueBinding=”{Binding Y}”/>
</charting:Chart.Series>
</charting:Chart>
…中略…
</Grid>
</UserControl>
実行してみよう
以下の条件入れてみたりするとよいかもしれず。
- 式: (sqrt(cos(x))*cos(200*x)+sqrt(abs(x))-0.7)*pow((4-x*x),0.01)
- 最小値: -1.57 (－π/2)
- 最大値: 1.57 (π/2)
- 間隔: 0.005
ちょっと前、Google検索で数式入れたらグラフを出してくれるようになった直後に流行ってた例のアレです。以下のようなグラフが出るはず。
と、画面キャプチャを貼ったところで、Legendの文字が適当（x）なままだとか、凡例に式全体を出しちゃうと結構うっとおしいとか気づいたり…
Windows Phone 向けフィードバック
フォーラムに↓このようなものを投稿するなど。
- アルファベット混じりのアプリが複数言語混在問題で審査に落ちる
- （立てたの自分じゃないけど、user voiceの方にも） App Hub登録審査に日本人、もしくは日本文化に精通している人を少なくとも一人は配置してほしい
で、これに関して、ちょっと知っておいてもらいたい事柄をいくつか。
数字を伴うこと大事
日本と比べると米国自体がというのもありますけども、その中でも、マイクロソフトは数字を伴ったフィードバックを非常に重要視します。
よく問題になるのは、日本人は製品版が出てからバグを見つけて文句を言うとか、フォーラムが盛り上がらないから問題ないと思っていたとかそういうのです。
今まだ IS12T しか出てないし…とか、変な遠慮をしてちゃダメで、問題は早期に伝えないといけません。また、数字を伴うっていうのは、立ったトピックに対して「投票」とか「△」みたいなボタンがついてますが、あれの数、相当影響力あります。twitterの☆とかFacebookのいいね！程度の感覚で、共感したものはボタン押しまくりましょう。
現状と今後（今から手を打っておかないと）
特に、今回のこの問題は、Xbox Live インディーズゲーム（XBLIG）の頃からいまだ対処してもらえていない問題です。
これは、どの程度重大な問題かを認識してもらえていないということです。認識していない理由は、上記の通り、数字を伴ったフィードバックの不足というのが大きいです。
XBLIG の頃は、それこそもう、Xbox 自体の日本での状況が悲酸なものだったので、「数字」を出すこと自体が厳しかったです。
なので、状況を打開するなら今なのかなぁと思っています。WP7 の日本での敗着が確定的な色合いになってしまう前でないと手遅れになります。
また、放置しておくと、同様の問題は Windows 8 の Metro マーケットプレイスでも起きると思われます。その意味でも、早い段階で、数字を伴ったフィードバックが必要です。
複数言語混在: どういう問題なのか
日本語にアルファベット混ぜんなって怒られています。普通に日本人ならよく見るレベルの、簡単な英単語ですら、日英混在とみなされます。
ただ、きっちりしたアプリを作るのであれば、アルファベット混じりっていうのはあまり褒めれたものではなくて、できればちゃんと日本語に翻訳した方がいいです。
この辺り、マイクロソフトの社内規定的には、相当しっかり、徹底してアルファベットを残さないようにしているはずです。たとえば、マイクロソフト関連のウェブサイトをいくつか見てみると、残っているのは、基本的に、
- Windows などの固有名詞
- CRM など、訳しようがなくて、日本でもそのまま使われている3文字略語
くらいで、例外は「Web」と「Code Recipe」くらい。
ところが、世の中そんなかっちりしたものばかりではないというか…
マイクロソフトのサイトはこの辺りきっちりしているがゆえに、なんか堅苦しくて若い人に受けなさそうというか。
若者向けで緩い分野、ゲームなんかだと特にですけど、こういう堅苦しさを残しちゃいけない世界というのもあるわけですが、マイクロソフトはそういう言う方面に弱いです。
最近になって、Windows Phone 7 がらみの言葉（People Hub とか）を訳しかねて悩んでる辺りを見てもらってもわかる通り、最近ようやく手を出したところなので、勘所まったくないはずです。
日本法人の社員の方がいくら把握しててもダメで、米本社に、そういう緩い分野における日本の感覚を伝えないといけないです。（そしてそれも、ユーザーからの「数字」しか方法はないです。日本法人社員の個人の発言よりも、ユーザーの、数字を伴ったフィードバックの方が優先されます。）
データ処理 補足
↓このような記事が公開されたわけですが。
- C#／Scala／Python／Ruby／F#でデータ処理はどう違うのか？
- 公開後あったtwitterでのやり取り: http://togetter.com/li/164658
何点か補足と釈明を。
選んだ言語について
とりあえず、個人で拾えたのがこの5つの言語というだけであって、その他の言語は読んだ方に移植とかしていただけると幸い。というか、C#以外は最新追い切れてないと思うので、もっといい書き方があればフォローしていただけると助かります。
その際、気を付けて欲しいのは以下の点:
- 全てのデータ処理を1ループに詰め込まない。パイプライン的に、小さい単位に分ける。
- 一時バッファーのようなものを作らず、イテレーター パターンで1要素ずつ処理する。
- x.filter(…).map(…)というように、後置き記法でつなぐ。
- 以上のことを、利用者視点だけじゃなくて、クラス実装者視点でも考える。
言語のサポートなしでやるのは結構大変なはず。特に、実行効率まで考えるとかなり難易度上がるかと。
一般に、利用者の方が圧倒的に多いので、実装者視点の重要度は低いんですが。標準ライブラリで事足りてるうちは不要な視点ですが、実装者視点の機能が足りてないと、社内フレームワークやサードパーティ ライブラリの質を落とすので無視はできないかと。
ちなみに、Java がないのは、別にハブってるわけではなく、Java にはこの手の機能がないからしょうがなく外しています。データ処理自体はできるんですが、上記の要件全部は厳しいはず。でなきゃ利用者数ナンバー1の言語を外すとかありえない。
C++ は、実装者側が超がんばれば行けそうかな… でも、言語サポートがあるわけではないので勘弁を。
1人じゃ無理
上記の通り、C#以外は門外漢なわけですが。1人で5言語はやりすぎたかなぁとかも思います。
特に、Scala は情報がなさ過ぎて。細かいところは「調べて書く」じゃ厳しいですね。普段から使っていないと。一応、数名の方にはチェックしてもらってはいるんですが。
ということで、みんなで穴埋めしようぜ！
これは、猪股さんが作ってくれたリストなんですけども、こういうとき、Google Docs での共同編集は非常に便利ですねぇ。
その他、まとまりなく雑感
- データ処理って、対象は何もコレクションだけじゃないんで、O/Rマッパーとか分散データ処理とかpush型データ処理とか考えるとさらに大変なはず
- 一部の関数型言語で言うQuoteとか、C# でいうラムダ式からの式ツリー生成とかも必要で（さもないと、静的な型チェックとかが犠牲に）
- push型データ処理はC#の場合Rxがあって、あれは利用側は楽でいいけども、実装側はかなり大変そう
- Scala、トレイト（中の具象メソッド）は本当に必要なのかな
- C#の拡張メソッドに対応するものだけあれば実は十分で、それで言うと、拡張メソッドに直接対応するものは implicit conversion で、これだけでよかった気も
- とはいえ、暗黙の型変換＋匿名型ってのも力技過ぎる感じが
- イテレーター的なもの作るのに setjmp/longjmp か…
- あれ、スタックの状態とかも全部キャプチャしちゃうし、正しく、効率よく使うの難しそう
- インターフェイスに対する実装を持つというのの意味:
- インターフェイス: こういうメンバーを持つべきという規約
- 例えば、数学だと、群とか環とかユークリッド聖域とか体とか
- インターフェイスの実装（継承）: その規約通りの具体的な実装
- 例えば、整数とか多項式環とか
- インターフェイスに対する実装（インターフェイスを引数に取る関数、C#の拡張メソッドの意義）: ある規約を満たすなら使えるアルゴリズム
- 例えば、ユークリッド聖域ならユークリッド互除法というアルゴリズムが使えて、商と余りが計算できる（整数は当然として、多項式環にも互除法が使える）
プレゼン
八巻さんの、プレゼンに関するノウハウ資料↓。なかなか素晴らしい資料。
場馴れする
僕はプレゼンであまり緊張しないタイプなんですが、それもまあ、単純にそれなりに場数を踏んでるからというのはあり。実際はそこそこ緊張してるんですが、発表者が緊張を見せても聞く側がしんどくなるだけなので、堂々と構えて見せてたり。この辺りは場馴れするに限ります。
僕の場合、学生の頃に場数踏む機会があったから、今余裕なんですよねぇ。恩師がプレゼン指導にものすごい力入ってる方で。（余談ながら、論文の校正もむちゃくちゃしっかりしてた。あの経験はほんと、今に生きてます。）
事前準備が一番
そういう研究室にいたので、当然、自分も指導側に回ることも多く。それでやっぱり思うのは、プレゼンで一番大事なのは事前準備。指導担当の先輩や教員がしっかり資料に修正入れてると、慣れてない人でもあまり緊張することなく発表出来たりするものです。
コミュニティの勉強会なんかだと、研究室みたいな指導関係があるわけもなく、結構独力で資料作りすることも多いかと思いますが… せっかくコミュニティに出て人脈を作っているのだから、仲良くなった人に事前に資料を見てもらうとかするとかなりプレゼンに自信付くと思います。
というか、ほんと、言ってもらえればいくらでも見ます。
使いまわす
発表とか、同じネタで4・5回くらいやってもいいんじゃないかなー。1回きりとかもったいなさすぎる。
僕の場合は、実は、「今書いてる記事で仕込みがあるから、このネタならプレゼンできるよ」って言ってプレゼンを引き受けることが結構多かったり。つまり、事前準備が最初からあるんで、プレゼンに余裕があるという。
逆に、プレゼンで整理した結果、記事の方がよくなるとかもざら。というか、まずtwitterでつぶやいてフィードバックもらい、プレゼンしてみて整理＆反応を見、そして記事化。記事も、複数のメディアで似たようなことを少しずつ改善していくことでいいものになる、みたいなことがざら。ほんと、何事も積み重ね。
ちなみに:
「複数のメディアで似たようなこと」とかやって大丈夫？とか思うかもしれませんが、割かし平気。例えば、ウェブ記事と勉強会が同テーマとかだと、勉強会がウェブ記事への集客になってくれて、相乗効果が出たり。
あと、メイン テーマが違う記事だと全然被った感じにならない。テーマに応じて、そのテーマにとって重要な部分だけ残すと案外別物になったりします。
最近思うのは、客層の違うところで全く同じ内容やるとかも、かなり有効なんじゃないかと。おそらく、単純に集客窓口が増えると思います。例えば、萌えな感じの記事と、硬派な感じの記事、面白いほど客層違うみたいなんで。
自信のなさを出さない
案外、緊張対策に有効なのがこれ。なんか、弱気っぽい雰囲気でしゃべると、そこに注目されちゃうんですよね。そして突っ込みが入ってあたふたすることに。なので、自身がなくても口調を変えない。そしたらまずバレない。
まあ、勉強会の場合、自分だって勉強する立場なわけで、聴講者に逆に聞くとかも全然あり。
デモとかで失敗してもあたふたしてはいけない。致命的なものでなければ気付かぬふりして完全スルー。致命的なものも、時間中に復帰できそうなら堂々と対処。時間がかかりそうなら「後日また」とか「懇親会ででもお見せします」。というような、リカバリー案を最初から持っておくと安心です。
「これはすごいな」と思ったのは、ネットワーク的に不安定な開場で失敗しそうな雰囲気が濃厚なデモで、「こんなこともあろうかと昨日、デモ作業の動画を取っておきました」とさらりと動画を出してきた某氏の発表。
時間調整
リハーサルをしっかりやって時間ぴったりに出来るように慣れておくってのも非常に大事なんですが。
僕ってかなりこの辺りいい加減だったりします。ただし、その代り、時間が足りなさそうならどこを削るとか、逆に余った時には何を話すとかを事前に全部決めてあります。スライドの優先度を頭に入れておいたり、デモ用のソースコードで「時間があれば見せたい」って部分を開いておいたり。スライドに詰め込み過ぎは見づらくなるので、通常、余談的な話は削ってあるんで、その余談を話すか話さないかだけでもかなり時間調整できます。
LT とか、短い発表は練習して時間合わせるしかないですけども、逆に1時間くらいの長いやつは中々時間合わせるのが難しいので、こういう時間調整方法を事前準備してしまう方が安定します。
コンピューター プログラミング入門以前
ずいぶん長いこと「書いてます」と言い続けてたものがようやく出版される運びとなりました（6/30 発売）。
初心者をターゲットにした本ですが、どちらかというと、副読本的立ち位置です。（なので、「入門」ではなく「入門以前」だったり。）
実務じゃまず必要ないくらい低レイヤーから高レイヤーまで網羅的に概要説明という感じで、普通のプログラミング入門本＋これを読んで欲しいというもの。
Java や C# でプログラミングを覚えたという人にも低レイヤーのことは知っておいて欲しいし、環境的に低級言語しか使えない人も高レイヤーのことを知らないでいいとは思わない。ただし、そういう幅広い知識は教養として知っておくべきものなので、「最初は C から初めて Java や C# に移れ」ということではなくて、副読本として実務と並行して学ぶべきものかなと。そういう立ち位置の本になります。
快適4画面ライフ
twitter ではつぶやいていたわけですが、我が家のPC環境が4画面構成になりました。
4画面化した結果
大体、以下のような具合に使っています。
まあ、4枚全部使うのは、重たい作業をしている時だけですね（といっても結構ずっと）。参照したい資料が複数あるとか、作業フォルダーをたくさん開きたいとか言うときくらい。
上2枚は結構見づらいので、基本的には退避場所になります。それでも、作業用に使っているフォルダーをロストしないとかいうだけで、かなり作業効率が上がります。あと、作業途中に割り込みが入って別作業しても、復帰がかなり楽。
息抜きモードな感じのときとかは、上2枚は電源を切っていたりします。右上の1枚だけ電源切って、3画面なことも結構あります。まあ、4枚はやりすぎかもしれないけども、3枚は普通にありだと思います。
ディスプレイ アーム
ディスプレイ アームは、一応ヨドバシとかに行って色々見比べた結果、一番コンパクトで使いやすそうだったものに。
ただ、結構人気商品のようで、ヨドバシでは売切れてて、結局家に帰ってからAmazon発注。
見ての通り、結構細いです。カタログスペック的には「モニターごとに10kgまで」とのことだけども、40kgくっつけるのはちょっと怖いかも…。
ただし、別に不安定だったりはせず。貧乏ゆすりしても画面が揺れたりしない感じ。
ディスプレイ
ディスプレイは、左上のものだけ昔から使っている21型ワイドのもので、残りは新規購入。23型の同じのを3枚購入。
最初は2枚でとどめるつもりだったものの、右上のアームがさみしそうだったので、ついうっかり。ほんとにうっかり。まあ、すごく満足していますが。
ディスプレイの購入基準は、アームが細めのやつということもあり、軽さ重視。フルHDで、LEDバックライトなもので、一番お手頃な感じのを見繕った結果、以下のものに。
値段に大差ないんで、全部 HDMI ありでもよかったかもと思いつつ、買ったのは1枚だけ HDMI なし。
DisplayPort対応の奴だとマルチディスプレイ化が楽らしいけども、お手頃価格のものが見つからなかったので断念。
アームに取り付ける際に思ったのは、やっぱり軽いタイプ（3.8kg）を買って正解。10kgまで付けれるとかいっても、10kgのものを抱えつつねじ止めとかできる気がしない…（特に上部アーム。）
とはいえ、LED じゃなければ数千円安い奴（4.9kg）もあるので、どっちが良かったかは悩むところ。
グラフィック ボード
ディスプレイがあっても、グラボが対応していないことには4画面化できないわけですが。
いやー、もちろん、グラボ1枚で6画面とかやってみたいですよね！（今回はやってませんが）まあ、こっちでもよかったかもなぁ、今思えば。
PCI Express (x16) なボードを2枚させる PC なら楽そうなんですけどもね、増設。うちの PC は1ポートしかないので断念。で、PCI Express (x1) にさせるボードは安めのものがなかったので断念。
結局、USB の外付けディスプレイ アダプターを2つ購入。
外付けアダプターだと、結構 CPU レンダリングしちゃうんで、常時 CPU に負荷がかかります。うちの場合、結構 CPU パワーが余っていたのと、上画面でそんなに重たい描画することもないので全然平気（エコ的な意味では嫌な感じですが）。3D ゲームなんかをすると悲惨らしいですけども、ニコ動を見る程度なら問題なさげです。
ただ、面白半分で、4画面全体に Visual Studio とか Word を拡大しようとしたら悲惨でした。2秒に1回（0.5 FPS）の描画くらいに。良い子のみんなは 3840×2160（フルHD 縦横2倍）でVisual Studio 使おうなんて考えないでしょうから、問題ないと思いますが。
周辺整理
さて、機器を増やすと問題になるのがケーブル類なわけですが。快適引きこもり4画面ライフを充実させるためにはケーブル整理が必須です。
電源周り
まず電源。こんな具合。
使っているのは、以下のもの。
ケーブル4本くらいであれば余裕。スピーカーのケーブルもまとめたかったものの、長さが合わなくて泣く泣く断念。
4本もまとまってると、「3本の矢」的な強さがあって、多少足で蹴ってしまうくらうではびくともせず。そういう意味でも、まとめておいた方が安心かも。
ディスプレイ裏
ディスプレイ-PC本体間も大概。こちらでも整理チューブが大活躍。
あと、買ったディスプレイは軽い代わりにアダプターが外付けなので、少々隠蔽工作。
以下の結束バンドでアームに巻き付けていたり。この結束バンド、今回のディスプレイの背面に限らず部屋中で使ってて、普段から重宝しています。非常に使いやすい。
キーボード周り
アームのせいで、多少、ディスプレイが手前に来てしまうので、机のスペースが減るなぁなどと悩み、キーボード トレイを購入。
ディスプレイ前の空間は、贅沢に「今日の TODO」を付箋紙に書いて貼り付けてるという使い方をしています。
もちろん、キーボードもマウスもワイヤレス。なぜか、気が付けばキーボードもマウスも複数持ってて余ってたりするんですが…
あと、おまけで、電子小物類の充電も↓こんな感じ。
