Keep Yourself Up To Date

先週土曜の業開中心会議で講演してきたわけですが。

• イベントのページ: https://itmedia.smartseminar.jp/public/seminar/view/465
• ustream 配信: http://www.ustream.tv/recorded/28809059
• 自分の発表資料: Keep Yourself Up To Date
• 同上、プロット段階: プロット Keep Yourself Up To Date

 

Keep yourself up to date from 信之 岩永

補足というか

会のテーマとしては、新しいことを導入するメリット、デメリットについて、とありました。

が、僕の講演的には、デメリットなしというか、新しいもの取り入れるのが前提で、やりたいけどやれてないだけという姿勢。

時代

パネル ディスカッションでやっていたような、フレームワーク、ライブラリのレベルではもちろん、要件に合わせてどれを選ぶべきかって議論はあると思います。

この辺りは、講演でいうところの、「変わったのは技術じゃなくて、時代の方」ってやつだと思います。

選ぶのは、時代。その新しい時代に賭けるかどうか、時期尚早でないかどうか、という判断。時代を読めてないんなら、選びようがない。

privateな部分はどうぞお好きに

で、「導入して当たり前じゃない」という姿勢なのは、特に、「varを使うべきか」とか「LINQを使うべきか」とかそんなレベルの話。

このレベルを「社内標準」みたいなの決めて統制かける意味あるのかなぁと。

というのも、この辺りは「privateな部分」で使うものだからです。

varにしてもLINQにしても、式とかステートメントのレベルの機能なわけです。で、クラスの外、メソッドの外からは見えない。

マイクロソフトは、クラスライブラリ設計ガイドラインってのは出してますが、式、ステートメントのレベルでのガイドラインは出してません。

というか、「privateな部分は好きにして」という姿勢のはず。実際、マイクロソフト主導のオープンソース プロジェクトのコードなんか見ても、ほんと結構バラバラ。

式とかステートメントのレベルで統制かけなきゃ読めないようなコード、あるいは、そのレベルで読まなきゃいけないコードって、そもそもpublicな部分の設計がひどいんじゃないかと。クラスやメソッドが適切に区切られてないとか。交番メソッドとか。

まあ、クラスのレベルの設計をきっちり出来る人がかなり限られるからそうなるんでしょうけども。要件定義みたいなSIの肝たる部分と、末端のコーダーはいても、間をつなげる実装設計する人が極めて少ない（できない。できても待遇悪くてやめていく）。少数いてもスケールしないですからね、形式知化されない限り。

戦術よりも戦略

varとかLINQとかのレベルって、いわば個人技で戦術レベルなんですよね。で、それだけだと戦略に勝てない。

ガチムチマッチョのヒーローでも、1人じゃ軍隊に勝てない。

僕が講演で、構文レベルの断捨離話ほとんどせず、もっと戦略レベル、例えば:

• コード メトリックス見ろ
• テスト書け
• リファクタリング入れろ
• チームこそが力
• 技術的負債のご利用は計画的に
• それは余裕がなきゃできない。デスマはデスマを呼ぶ

みたいな話に寄せたのもこのせい。

教育放棄

そう、LINQ使うかどうかなんてレベルの話、好きにすればいい。「使っている人がいる」のも、「使ってない人がいる」のもいい。でも、「使わせない」はありえない。

「LINQ禁止」みたいなバカバカしい社内標準に意義を唱えたいのは、教育的観点から。

僕はいつも言っていますが、それに講演やパネルディスカッションでも散々言いましたが、教育の効率化のために「言語から学ぶ、ツールから学ぶ」というのが重要だと思っています。

その、ツールや言語機能を制限するっていうのは、教育の機会を奪っている。社内標準とか決めてるようなレベルの人は教育する側の立場なわけで、その人らが率先して教育の機会を奪っている。教育を放棄している。と思います。

それで「優秀な人が少ないんだからしょうがない」とか言ってさらに厳しく制限かけるんだから、負の連鎖もいいところ。デスマはデスマを呼ぶ。

まあ、実態はその逆で、教育にも値しないレベルの人を雇い過ぎなのかも知れないですけど。

作成過程

で、今回、作成途中の段階の資料を残してみた。「こんな感じでプレゼン作ってます」というのも見せようかと思い。

プロット

僕の場合は、「プロット作る」って言ってるんですが、上記の「プロット Keep Yourself Up To Date」みたいな資料を一度作って、そこから洗練していく形で資料作りをしています。

プロット（plot: 構想）は、漫画とか作る場合に、文字だけでストーリーの大筋を書きだしておいたりする段階をさしたり。

僕の場合、本番資料では絵をかなり多用しますが、最初はこんな感じで文字ばっかりのスライドを作ります。

プロットの時点で

この時点で話す内容はほぼ決まっています。

なので、この時点で時間調整がほぼ可能。「時間の都合で割愛」あるいは逆に「足りないから何か足そう」みたいなのはこの時点で全部済ませます。

自分の場合は1ページ1分強で見積もればほぼ外さないです。大体僕の発表って時間ぴったりくらいで終わっていると思いますけども、あれ、練習とか1度もしてないです。毎回ぶっつけ本番。

誰か他の人にご意見求めたい場合もこの段階でやります。僕は校正する側にもよくなりますけど、そちら側の立場で言うと、完成品になってからチェックしてくれって言われも困りますからね。「このスライド要らね」とか割と容赦なくやるので。

本番資料での追加

プロットから、流れは変えないんですが、いくつか、スライドの追加はします。以下のようなもの。

• アジェンダとかセクション タイトルのスライドを入れる
• まとめを入れる
• アニメーションの都合で裏が隠れる部分は2枚に分けて印刷でも見れる状態にする

これで、ページ数は1～2割増えます。それで、大体「1ページ1分」くらいの見積もりになります。

本番資料での変更

あとは、基本的には絵の追加になります。情報量を変えずに文字を減らす。文字なんか読まねーよ。

絵は、ちゃんとプロットに書いてあったことのイラストレーションになるように。単なるイメージ喚起にはしないように。

その他、文章面でやっているのは以下のような点。

• マイルドな表現に変える
• 専門用語を平易な言葉に変えたり、脚注付けたり

プロットの方と完成品を比べてもらうと、プロットの方がずいぶん毒々しいと思います。というか、完成品も、ノートまで見てもらうと結構毒々しい表現残っていたり。

専門用語は、人によって定義が違っていたりするので、講演みたいな1対多のコミュニケーションでは使えないことが多いんですよね。なので、プロットの時点では（自分だけわかればいいので）用語で書いてますが、最終的にはたいてい直します。話の主軸じゃないところでは用語のままさらっと流しますけども、少なくとも、重要なところでは言葉の置き換えや改めての説明をします。

C#、2012年の首位プログラミング言語に名が挙がる

• C# Named Top Programming Language of 2012
• Eight Reasons C# is the Best Language for Mobile Development

集計方法1つ変えるだけで順位なんて変わるという話でもあったりはするのだけども。

ある指標では、2012年で一番伸びた言語はC#ということになるそうです。

2012年

去年、C#とか.NET周りで何があったかというと、MonoTouch/Mono for Android であったり、Unity（Monoベースのゲーム エンジンの）であったり、Windows 8であったり。

Windows 8

Windows 8、というか、WinRTで、ネイティブ（C++）の復権があったり、JavaScript+HTML5での開発もできたりで、世の中には「.NETは下火」なんていう人もいるにはいましたが。実際にWindows 8がリリースされて、ふたを開けてみればやっぱりほとんどのWindowsストア アプリはC#で書かれてるそうで。ですよね。

TypeScriptがらみでも、×「Andersが生みの親」、×「Andersは.NETを離れてHTML5方面に移った」みたいな誤解も出てましたが、実際は「開発の一員」だし「.NETにも引き続き（Roslynがらみ）関わる」だそうですし。

マスメディアはそういう大どんでん返し的なあおり記事が大好きですけども、実際の結果はそんなものです。

マイクロソフトは昔から、ギャップのない世界を目指しています。.NETだって元をたどれば言語を超えての連携を目指したものだし、今はその連携の幅を広げに掛かってるだけで。.NETを捨てる気なんて全くない。むしろ、.NETはこれからもマイクロソフト技術の中心にあり続けることには変わりないでしょう。

まあ、.NETもコアの部分は落ち着いて、周りを固める時期に来たのかもとも思います。

Mono

「マイクロソフトだから」という理由だけで敬遠する人が多かったりもするわけで、Monoが伸びた2012年はその意味でもC#に取っていい年でした。

「マイクロソフトよりも我々の方がC#と.NETを愛している」と豪語して商売成り立たせてる会社もあるわけで。もう、C#に対して「マイクロソフトの」なんて前振りも要らないでしょう。

実際伸びてる

まあ、マスメディアにどうあおられようと、うちのサイトのC#ページ、アクセス数増えてますからね。

ここ2年ほど、伸びが鈍化はしてるんですが、その2年って、ほとんど更新してないんですよね。僕が、商用サイトへの寄稿とか、紙の本の仕事で手いっぱいで。更新しなくても伸びてるんだから、利用者の純増かと。（もっとも、商用サイトとか本とかでの露出が広告効果になって人が流入してるというのもあるでしょう。かけてる手間を考えると高コストな広告だこと…）

うちみたいなチュートリアルが主軸のサイト、ブログともマスメディアともアクセス傾向違うんでしょうねぇ。ブログだと更新しないとアクセス目減りしていきますし、マスメディアだとバズワード的なあおりの方が伸びるでしょうし。

C#がモバイル開発に最良の言語である8つの理由

冒頭のリンク、2つ目の方は Xamarin （Mono を作ってるところ）のブログなわけですが、良いまとめだと思うので、軽く和訳:

この2012年のC#の伸びはどう説明しましょう？たぶん、Windows 8のローンチもその役を担ってるでしょう。C#は今なお、Windowsデバイス上のサードパーティ アプリ開発の主要言語です。

しかし、それ以上のものがあると思います。モバイル開発でのプログラミング言語としてC#がますます選択肢となる8つの理由を挙げてみます。

1. 最先端 – 非同期処理がファーストクラスな言語機能になり、かつては退屈で、反復的で、エラーになりがちなコーディングを、単純で楽しい体験に変えてくれます。それに、匿名型、ラムダ式、型推論、関数型スタイルのプログラミング、LINQなどによって、開発者は非常に意味のある、保守の容易なコードを書けます。
2. 強力な特性 – オブジェクト指向プログラミングとカプセル化は、コードを構造化し、再利用性を最大限引き出すことを容易にします。リフレクションや依存注入などの機能は開発者に多くの力と柔軟性を提供します。
3. 高度な実行環境 – ガベージ コレクションは、メモリを手動管理することのオーバーヘッドをなくし、開発を非常に簡素化します。開発者は、ポインターと戦うのではなく、解決したい問題に注力できます。
4. 信頼性 – 型安全性は、コンパイル時にバグを見つけて切り出すのを、より早く、より簡単にします。これは特にモバイル開発で重要な特性です。モバイル開発では、パッケージ化して実機やエミュレーターに配置するためにビルド/実行/テストのサイクルが長くなりがちです。コンパイル時の正当性検査によって、C#開発者は、明確なエラーを見つけるために、プログラムが実際にクラッシュするのを待つ必要はありません。
5. 採用が簡単 – 非常に学習が簡単です（特に、オブジェクト指向プログラミングの原理を既知の開発者にとって）。多大な量のC#の参考資料があり、新しい開発者が行き詰らずに済みます。
6. 高速な実行 – C# on iOSは、LLVM最適化コンパイラー、つまり、CとC++（OSを駆動させている）と同じバックエンドで動いています。これによって、C#の高い生産性と、低級言語の実行性能の両方の良いところ（the best of both worlds）を与えます。Android上では、C#はJavaよりも良い性能を発揮します。これは2つの理由があって、1つは言語設計の選択（値型、真のジェネリック型、既定で非virtualなメソッドのサポート）によります。もう1つは比較的若いDalvikよりも、Mono実行環境が成熟しているためです。
7. ネイティブ アクセス – ネイティブ コードとのシームレスな（継ぎ目のない）相互運用も、両方の良いところを与えます。ネイティブのライブラリを用いP/Invokeを活用することで、マネージ コードの世界に追加の機能を触れさせることができます。これが、iOSやAndroidのネイティブAPIの100%をC#開発者が触れられるように、Xamarinがやっていることです。下層にあるプラットフォームの表現力豊かな力にアクセスするすべを提供します。
8. ポータビリティ – そして大きな8番目。Windows、iOS、そして、Androidで、22億以上のデバイス上でC#コードを実行できます。そして、モバイルを超えて、C#は非常にポータブルです。モバイル、組み込み、デスクトップ、サーバー コンピューティングなど広い範囲の環境で使えます。