++C++; // 未確認飛行 C ブログ

http://ufcpp.net/

Archive for 12月 2011

1人Advent Calendar反省会

with one comment

相変わらず裏話が大好きなわけですが。とある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: 別シリーズ

キャラはできてるんでやりようはいくらでも。

  • 4人いれば普通に○いおん的な
  • 魔法設定ちゃんと作ってあるんで普通にファンタジーものできると思う
    • 魔法と言いつつ、イメージはペルソナなのだけども（ペルソナのなり損ね、シャドウが敵 ＝ 魔法のなり損ね、バグが敵）
    • 最近だと、ビッグオーダーとかのノリいいかも。基本、ジョジョ
  • F#たんのネタ元をもろにパロって○学ガール的な
  • 仕事一途に頑張ってきたC++たんの「恋は三十路をすぎてから」パロディ

Written by ufcpp

2011年12月25日 at 17:06

カテゴリー: 未分類

Mono in 2011、KinectでLEGO NXT制御、SkyDrive REST API、等々

leave a comment »

12月、あっという間に過ぎてるなぁ（遠い目）…

  • Mono in 2011
    • ほんとこの1年はいろいろあったんだなぁ
    • Novellのレイオフ騒動があった時はどうなるかと思ったものの、結果を見ると独立して動きやすくなってるような。monoのメイン ページがいきなりきれいになったりしたし
    • ほんと、ゲーム方面での利用が伸びているようで
      • 日本だと、ほんとUnityとPS SuiteでいきなりC#が現れたように見えるけども、アメリカだとだいぶ前から脱C++な動きあったんですよねぇ
  • Lego KinNXT
    • KinectでLEGOマインドストーム動かしてる！
    • しかもコードがF#
  • SkyDrive REST API を使った Web アプリケーション サンプル (Sample Code)
    • 書いたものをSkyDriveに保存するメモ帳を作りたかったんで、ちょうど良かったり
    • 問題は作る時間…
  • Microsoft Codename “Data Transfer”
    • こんなのあったんだ
    • 手元にあるCSVとかExcelのデータをSQL Azureとか、クラウド上にアップロードしてくれるツール
    • クラウドなデータベース、データのマーケット プレース、検索ツール、可視化ツール、そして既存データの移行ツールと、やっぱこの“品揃え”がマイクロソフトよねぇ
  • Anatomy of a .NET Assembly – Type forwards
    • そういや、前、Metro向け.NETの中身見てたら、mscorlibとかSystem.dllの中身がこれだらけだった。
  • 日経ソフトウェアで連載開始です！
    • 「それ、C#たんで描いて」ってお願いしとけばよかった…

Written by ufcpp

2011年12月24日 at 18:19

カテゴリー: .NET

CXXI

leave a comment »

こんな話が話題に。

要約すると:

  • 通常のC++クラスを.NETから利用できる
    • .NET側で継承もできる
      • 仮想メソッドのオーバーライドも
    • C++側で多重継承してるものも使える（baseの代わりに、それぞれの親クラスへのキャストを提供）
  • （C++側に）COM規約なんかいらんかったんや
  • オブジェクトや仮想関数テーブルのレイアウト（思いっきりプラットフォーム依存）教えるから、後はそっち（.NET側）でよろしくやっといて
    • GCC-XMLっていう、C++の構文解析結果のメタデータをXML形式で出力するツールを使ってレイアウト情報を取得

潔い割り切りかもなぁ。

C++はC++で閉じて、ソースコード可搬ならそれでいい。COMみたいな相互運用層は要らない。そういう前提の元では非常に素敵そうな技術。Unix系OSでのmonoだとその前提でいいだろうし。

Written by ufcpp

2011年12月20日 at 01:03

カテゴリー: .NET

Tagged with ,

SilverlightへのPython組み込み

leave a comment »

このエントリは 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時間ほどでサンプル、作りました。

 

ロジックらしいコードは↓これだけ。

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）なままだとか、凡例に式全体を出しちゃうと結構うっとおしいとか気づいたり…

Written by ufcpp

2011年12月16日 at 15:08

カテゴリー: 未分類

Data Explorer、Silverlight 5 RTM、PowerShell 3.0 CTP、等々

leave a comment »

自業自得気味に超多忙中でなかなか大変。

Written by ufcpp

2011年12月10日 at 19:52

カテゴリー: .NET

Windows 8時代のGUI開発/Windows 8時代の.NET

with 2 comments

金曜日に、@ITで以下のような記事が公開されました。

そして、Silverlightを囲む会で以下のような発表をしてきました。

https://r.office.microsoft.com/r/rlidPowerPointEmbed?p1=1&p2=1&p3=SD5C622397E11C979D!3402&p4=&ak=!AFg49XomaSVgLM4&kip=1&authkey=!AFg49XomaSVgLM4

1万字程度の原稿に加えて、25分間のプレゼン発表って、何この学術発表スタイル。

公約数 VS プラットフォーム固有？

さて、お気づきかもしれませんが、実はこの話には落とし穴が一つありまして。公約数VSプラットフォーム固有という構図でお話しましたが、ここはほんとに対立すべきかという点。

原理的には、公約数な.NETがあってもいいと思うし、プラットフォーム固有なHTML5があってもいいはずなんです。それが、政治的な理由で分断されている。

プラットフォーム固有なら、Silverlightはまだまだ現役です。しかし、世の中の多くは公約数で十分というのも事実。

ギャップ問題

問題は、この2者の間に大きなギャップがあることなんですよねぇ。まさに、90年代のVB VS C＋＋の構図そっくり。大半の案件はVBで十分だけど、あるラインを境にVBは破綻する。しかし、ギャップがある故にC＋＋への移行はムリ。

開発者はVBの方が多く、案件も徐々にVBが増える。しかし、製作単価は据え置きで、破たんするラインを越えても同じ安いお値段で使われる。

そんな時代がありました。

製作単価安いから

そこに来て、こんなブログ記事もあるわけですよ。

比較項目の一番下、代理店の利益のところ。「製作単価が安いから」という理由で○が付いています。HTMLの方が開発者の単価安くてお得だと。つまるところ、ギャップを越えれない人を安く使う構図。破たんするライン（Canvas 使って高度なグラフィック表現してとか、WebGLを使って3D作ってとか）を超えてもお値段据え置きになりそうな恐怖。

時代はどこまでも繰り返すのか。

繰り返すのか…

かつて、VBを少しC++に寄せてC#を作ったように、HTML5をXAMLに寄せたような世界が来るんですかねぇ。

そしてそれは、標準ベースであり得るのか。

WinRTで、C++や.NETで作ったコンポーネントをJavaScriptから参照できるようにしてあるのは、1つの解決策ではあるんでしょうけども。

Written by ufcpp

2011年12月3日 at 14:06

カテゴリー: .NET, C#

Tagged with , ,