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

http://ufcpp.net/

Archive for 7月 2011

Visual Studioのプロジェクトのクリーンアップ、WP7.1 SDK Beta2 Refresh、等々

leave a comment »

広告

Written by ufcpp

2011年7月31日 at 12:47

カテゴリー: .NET

Roslyn

with 2 comments

MS、コンパイラをサービス化する「Roslyn」の詳細公開へ」 ← このタイトル・この内容を見て、絶対勘違いする人いるだろうなぁと思ってたら、やっぱりはてぶが素敵なことに。“Web” サービス化だと思われてる節が。

サービス化

サービスっていうと Web サービスのイメージが強いですよねぇ、そりゃ… あと、「as a Service」って付いてるクラウドの分類方法が多いですし… 違うんですけどもね。クラウド(直接は)関係ない。

Roslyn のいう as a Service ってのは、monolithic (一枚岩で分割不可能な巨大システム/アプリ)の対義語としてのサービス。「中身をブラックボックスにしない」、「処理単位ごとにプログラム的に参照可能」という意味。なので、Roslyn(というコードネームが付く以前)の旧称 Compiler as a Service は以下のような意味:

  • 「ソースコードを入れたら(中間なしでいきなり)バイナリが出て来る」というブラックボックス状態の解消
  • lexer, parser, analyzer とか、内部クラスの公開
  • Visual Studio (のコード補完、リファクタリングなど)と C#/VB コンパイラーとで起きてた2重開発の解消
  • コンパイラーの完全 .NET 化(C# コンパイラーを C# で、VB コンパイラーを VB で書き直すそうで)
    • 今までネイティブ実装で、ライブラリ的に使いにくかった
    • プラグインとして使うのもやりにくかった
    • Silverlight とか Azure で使うのもやりづらかった

Roslyn で何が変わるの?

内部構造の公開 & .NET 化 で何ができるかというと:

REPL

Read-Eval-Print Loop、要するに、いわゆるコンソール。C# や VB.NET で、1ラインずつ結果を確認しながらの実行が可能。

もう、「コンパイル型の言語だから面倒」とか言われる心配もなくなるわけです。

C#/VB のスクリプト言語化

ついに、VBA とおさらばの時か!

いわゆるマクロ言語的に、C# や VB をアプリケーションに組み込めます。

write-your-own リファクタリング

Visual Studio の IDE の方は、今、拡張マネージャーって機能を使って、自由に自作/サードパーティ製の拡張をインストール可能なわけです。

そういう IDE 拡張を使って、C# や VB のコード整形/静的コード解析がやりやすくなります。

広義にはクラウド化?

今まで、ネイティブ実装がネックになって、Silverlight 中や Azure 上で C# コードをコンパイルするのがかなり大変だったわけですが、それが可能になるはずです。

件の ZDNet の記事には “taking .Net to the cloud.” とか書かれてるわけですけども、多分、意味合いとしてはこういう意味(Silverlight や Azure にも乗せやすい)かなぁ… 別に Azure でなくても、レンタル サーバーなんかでも乗せやすさだいぶ違いそう。

部品化されているので、部分的な Web サービス化(リファクタリング サービスとか)もできるはずだけども。

言語内 DSL

Roslyn リリースからさらに1テンポ遅れてになるとは思うものの、C# や VB に言語内 DSL を埋め込める可能性も。

例えば、以下のような機能はビルド時コード生成を必要としていて(あんまり実行時にやりたくない/実際 IL 書き換えで実現してる)、Roslyn があると大分作るの楽になるはず:

  • MVVM パターンで煩雑になりがちな ViewModel の生成
  • Code-First 的な、POCO からのエンティティ クラス生成
  • 契約プログラミング(Code Contracts)

今でも、T4テンプレートみたいなものを使ってビルド時コード生成できるわけですが、あれをもうちょっと、C#/VB と親和性のある書き方で書けるようになりたいというのもあり。

Written by ufcpp

2011年7月22日 at 15:36

カテゴリー: .NET, C#

Process Explorer、.NET Gadgeteer、

leave a comment »

Small Basic 1.0、等々

Written by ufcpp

2011年7月22日 at 14:20

カテゴリー: .NET

データ処理 補足

leave a comment »

↓このような記事が公開されたわけですが。

何点か補足と釈明を。

選んだ言語について

とりあえず、個人で拾えたのがこの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#の拡張メソッドの意義): ある規約を満たすなら使えるアルゴリズム
      • 例えば、ユークリッド聖域ならユークリッド互除法というアルゴリズムが使えて、商と余りが計算できる(整数は当然として、多項式環にも互除法が使える)

Written by ufcpp

2011年7月22日 at 11:05

カテゴリー: 未分類

Silverlightを囲む会 in 東京#3

leave a comment »

http://silverlightsquare.com/index.php/tokyo03.html にて、プレゼンしてきました。

資料↓

ストリーミングはこちらから↓

Silverlight を囲む会 in 東京 #3 Live Streaming

自分の発表は03:48付近から。

設計をちゃんとやってれば結構コードの共有できるよという話。

Portable Library Tools の利用推奨。基本的に、「リンクとして追加」は苦肉の策で、コピペは最終手段です。

サンプルコード、もう少しコードの整理をしてからupしたいんで、少々お待ちを。

ライブコーディング

勉強会の時間調整ということで、急きょ予定外のセッションも15分ほどやりました(上記ストリーミングでいうと、04:24 頃から)。ちょっと音声小さくなっちゃってるのが残念ですが…

まあ、テーマとしては、「仕込み一切なし!ぶっつけ本番!グダグダ ライブコーディング」だったわけですが。

一般論で言うと、こういうグダグダ セッションはやっちゃダメです。ちゃんと伝えたいことがあるなら、事前準備大事。ぶっつけ本番とかで、セッション時間内で、グダらず何かやるとか無理です。

今回のは、まあ、おまけセッションということで。制限時間を設けて、時間いっぱいグダってるところを見せる感じ。

個人的に、もっとこう、仕込みなしの生のコーディング作業を動画に残したいんですよね。ちゃんとしたプレゼンターのやるデモはきれいすぎるので。裏の様子をお見せする機会というのもたまにはやりたく。

今回のライブコーディングなんかでも、「うわっ、(WP 7.0って、Enumクラスの)TryParseもないの?」みたいな、思わず漏れた本音みたいなのがポロリと出てますが、そういう「思わず」を出したい。

あと、練習なし(つまり、普段通り)だとどのくらいのスピードでコーディングできるものなのかというのも、もっと見せたい。Visual Studioに頼ったコーディングってのがどんなスピードなのかってのをお見せしたく。

Written by ufcpp

2011年7月10日 at 14:20

カテゴリー: .NET

Windows Phone SDK β2、Entity Framework Jun CTP、等々

leave a comment »

ずいぶんと久々な感じ。少しネタが古くなっていますが…

Written by ufcpp

2011年7月4日 at 18:24

カテゴリー: .NET

プレゼン

leave a comment »

 

八巻さんの、プレゼンに関するノウハウ資料↓。なかなか素晴らしい資料。

場馴れする

僕はプレゼンであまり緊張しないタイプなんですが、それもまあ、単純にそれなりに場数を踏んでるからというのはあり。実際はそこそこ緊張してるんですが、発表者が緊張を見せても聞く側がしんどくなるだけなので、堂々と構えて見せてたり。この辺りは場馴れするに限ります。

僕の場合、学生の頃に場数踏む機会があったから、今余裕なんですよねぇ。恩師がプレゼン指導にものすごい力入ってる方で。(余談ながら、論文の校正もむちゃくちゃしっかりしてた。あの経験はほんと、今に生きてます。)

事前準備が一番

そういう研究室にいたので、当然、自分も指導側に回ることも多く。それでやっぱり思うのは、プレゼンで一番大事なのは事前準備。指導担当の先輩や教員がしっかり資料に修正入れてると、慣れてない人でもあまり緊張することなく発表出来たりするものです。

コミュニティの勉強会なんかだと、研究室みたいな指導関係があるわけもなく、結構独力で資料作りすることも多いかと思いますが… せっかくコミュニティに出て人脈を作っているのだから、仲良くなった人に事前に資料を見てもらうとかするとかなりプレゼンに自信付くと思います。

というか、ほんと、言ってもらえればいくらでも見ます。

使いまわす

発表とか、同じネタで4・5回くらいやってもいいんじゃないかなー。1回きりとかもったいなさすぎる。

僕の場合は、実は、「今書いてる記事で仕込みがあるから、このネタならプレゼンできるよ」って言ってプレゼンを引き受けることが結構多かったり。つまり、事前準備が最初からあるんで、プレゼンに余裕があるという。

逆に、プレゼンで整理した結果、記事の方がよくなるとかもざら。というか、まずtwitterでつぶやいてフィードバックもらい、プレゼンしてみて整理&反応を見、そして記事化。記事も、複数のメディアで似たようなことを少しずつ改善していくことでいいものになる、みたいなことがざら。ほんと、何事も積み重ね。

ちなみに:

「複数のメディアで似たようなこと」とかやって大丈夫?とか思うかもしれませんが、割かし平気。例えば、ウェブ記事と勉強会が同テーマとかだと、勉強会がウェブ記事への集客になってくれて、相乗効果が出たり。

あと、メイン テーマが違う記事だと全然被った感じにならない。テーマに応じて、そのテーマにとって重要な部分だけ残すと案外別物になったりします。

最近思うのは、客層の違うところで全く同じ内容やるとかも、かなり有効なんじゃないかと。おそらく、単純に集客窓口が増えると思います。例えば、萌えな感じの記事と、硬派な感じの記事、面白いほど客層違うみたいなんで。

自信のなさを出さない

案外、緊張対策に有効なのがこれ。なんか、弱気っぽい雰囲気でしゃべると、そこに注目されちゃうんですよね。そして突っ込みが入ってあたふたすることに。なので、自身がなくても口調を変えない。そしたらまずバレない。

まあ、勉強会の場合、自分だって勉強する立場なわけで、聴講者に逆に聞くとかも全然あり。

デモとかで失敗してもあたふたしてはいけない。致命的なものでなければ気付かぬふりして完全スルー。致命的なものも、時間中に復帰できそうなら堂々と対処。時間がかかりそうなら「後日また」とか「懇親会ででもお見せします」。というような、リカバリー案を最初から持っておくと安心です。

「これはすごいな」と思ったのは、ネットワーク的に不安定な開場で失敗しそうな雰囲気が濃厚なデモで、「こんなこともあろうかと昨日、デモ作業の動画を取っておきました」とさらりと動画を出してきた某氏の発表。

時間調整

リハーサルをしっかりやって時間ぴったりに出来るように慣れておくってのも非常に大事なんですが。

僕ってかなりこの辺りいい加減だったりします。ただし、その代り、時間が足りなさそうならどこを削るとか、逆に余った時には何を話すとかを事前に全部決めてあります。スライドの優先度を頭に入れておいたり、デモ用のソースコードで「時間があれば見せたい」って部分を開いておいたり。スライドに詰め込み過ぎは見づらくなるので、通常、余談的な話は削ってあるんで、その余談を話すか話さないかだけでもかなり時間調整できます。

LT とか、短い発表は練習して時間合わせるしかないですけども、逆に1時間くらいの長いやつは中々時間合わせるのが難しいので、こういう時間調整方法を事前準備してしまう方が安定します。

Written by ufcpp

2011年7月4日 at 18:21

カテゴリー: 未分類