2016 + 2017 EP (技術編)

2016年振り返り

2016年もいよいよ最後の1日となりました。今年は実にさまざまな物事に振り回された1年でしたが、何とかわたし1人の実力で乗り切ることが出来ました。自分自身に感謝を述べるとともに、来年も気を引き締め、誰に何を恥じることもないよう誠心誠意筋を通して適度にがんばっていこうと思います。

今年はややランダムにアウトプットを出してきた1年だったと思うので、いろいろ引っ張り出しつつ主だったものを振り返ってみます。

.NET Platform Standard日本語訳

.NET Coreは標準的なAPIを提供するんじゃなかったの? PCLプロファイルが増えすぎてワケわからなくなってんだけどどうするの? みたいなところを解決するための方法として導入された仕様でしたね。今年はこの話がいろんなところで地味に出てきたので、.NET技術者クラスタでは関心の高いネタのひとつだったと思います。

Android Studio 2.0のInstant Runの仕組みを解読する

DroidKaigi2016でしゃべったネタ。信じがたいことに、コレがまだ2016年の話でした。DroidKaigi、初参加でしゃべる側でしたが、他のセッションも面白く、たいへん充実した2日間でした。Instant Runでしゃべることになったのは、もちろんXamarin.Androidのfast deploymentを見てきたからイケると思って応募したためなのですが、Android開発者クラスタには新しいトピックだったこともあって、また次世代の話としてinstant programmingのストーリーまで用意していったこともあって、今年一番完成度の高いセッションが出来たのではないかと思います。そしてセッションよりまとめ解説のほうが本気度が高いです。わたしの技術情報まとめとしてはここ数年で一番の出来だと思います（ワインっぽくなってきた）。この頃から、技術セッションを事前の長文まとめをもとに用意する、という流れを作るようになりました。

長かったこれまでと、分からないけど楽しみなこれから

ご存知MicrosoftによるXamarin買収の発表を受けて書いたポエムです。qiitaに書けばよかったかしら。消されないはずだし。この頃から「所在不明で海外の会社で仕事する謎の生き方」からの引退を意識して、同じことをしたい人たちに道筋を残しておかなくては、みたいなことを考えるようになりました（概ね日本の会社ではたらくより自己実現しやすいと思うので）。日本ではXamarin最後の日と合わせてポエム2本書いたし、台湾でもXamarinコミュニティ第1回meetupでその話をしてきました。

Xamarin.Android SDK解説 @ 技術書典(1)

6月には技術書典が開催されました。Xamarin関係の原稿を書けという指令があったところだったので、4月のBuildで告知されEvolveで公開されたオープンソースXamarin platformのうちXamarin.Android SDKについて、そこそこ詳しく踏み込んだ話を書きました。30ページくらいでだいぶパワーを使ったのですが、正直なところ、踏み込み度合いで考えると、まだまだ雑な部分が多い感じです。ともあれ、これをもとに、7月にはYAP(achimon)Cで、8月には台湾のCommunity Open Campで、いずれもXamarin.Android SDKについてしゃべりました。来年4月には技術書典2もありますし、Xamarin本もまとめたいと思っています（Androidの話は書かないかもしれません）。技術書典自体にもスタッフとして参加していたのですが、来場者も1500人ほどで、イベントとして大成功でした。

language server protocolについて(前編)

2016年はVisual Studio Codeが大躍進した1年でした。単なるエディタの実装というより、オープンなIDE技術の標準仕様を策定して「みんな」を幸せにしようという本家MSの開発者の姿勢は素晴らしいですね。language serverはそのオープン仕様の主要な例ですが、IDEのコードエディタの仕組みって、なかなか理解してもらえない難しいトピックなんですよね。なので、この文章はわたしらしくもなく「わかりやすさ」を第一にまとめたものです。台湾のイベントの後でVSCodeの話をしていたスピーカーに見せたら、これは他で読めない内容だから是非とも英語でまとめてくれ、と言われて、これは成功した!と思ったものでした。いや英語化できていませんががが。あと前編と言いつつ後編が書きかけのままなのですが…そのうち…(汗

.NET Fringe Japan 2016が見せた「オープンな.NET」という世界

今年わたしが主催側で開催したイベントは多分これしかないのですが、オープンソースを主軸にさまざまな.NET開発のセッションを集めることができて、大成功だったと思います。わたしは9月頃はけっこう他でテンパっていてセッション準備がおろそかになってしまった側面があるのですが、あのセッションの後、Xamarinのソースをカジュアルに見てくれる人が多くなったし、今年はちらちらとPRを出してくれる人も出てきたし、ある程度は種を蒔けたのではないかと思います。monoやXamarinに恒常的にcontributeしてくれるような後継者は出てきませんでしたが、来年もこりずに新しく挑戦してくれる人たちを待ちたいと思います。

vscode-language-review

VSCodeの技術解説を書いておきながら、アドインのひとつも書いたことがないというのは、ちょっと忸怩たるものがあり、冬コミ向けの原稿執筆で使われることもあろうと思って、ちまちまとVSCodeアドイン開発…というかTypeScript開発全般…を勉強しながらアドインを作りました。動くようになってくると面白かったです。今はRe:VIEW原稿を書くのに使っています。10月までは技術セッションでしゃべりすぎたので、今年書いたコードは少なく（まあもともと多くありませんが）、完成したのはこれくらいでしょうか。VSCodeアドインはもうひとつ作りたいネタがあるのですが、当面は重厚な監訳タスクが邪魔をしていて、それに着手できるまではしばらくかかりそうです。

AndroidでJavaCPPを使用する in なないろAndroid @ C91

（公表順ではありませんが、書いた順としてはこれなので…）唐突にJava?と思われそうですが、5年前にまとめたBridJ以来のC++相互運用フレームワークの調べ物のJava編の流れだと理解してもらえればいいです。100% Javaの話を書いていますが、当然ながら.NET方面の実装についても関心があるわけです。ただ、現状のCppSharpが最適解だとは思えないので、まずJava方面を見て歴史に学ぶべきだと思っています。同じネタでDroidKaigi 2017トークに応募したのですが、さすがに周縁トピック過ぎて不採用でした…。次はJNAかな?

Visual Studio for Macの.NET Coreサポートの実装について

Connect();に向けたXamarinの大きなアップデートで発表されたVS for Mac、その中で特に面白かったdebug protocolの取り込みの話を中心に書きました（.NET Coreプロジェクトのサポートについて調べていたらそこに行き着いた）。これも動機付けとしてはlanguage server protocolのネタと重複する部分が多いです。最後のまとめといい、こんなに「MSの手先」みたいな雰囲気の記事を書くつもりはなかったのですが（今年日本MSの中の人が書いた技術記事の中でも、トップクラスの前向きかつマトモなMS推し記事だと思いませんか?）、まあたまにはいいでしょう。

Xamarin.Formsに新しいプラットフォームを追加する: 前哨戦)

Xamarin Advent Calendarでは、余人の追随を許さないネタを書くつもりでした。さんざん手垢の付いたXamarin.Formsを選びつつ、わたしはただの消費者にすぎないおまいらとは違う!みたいな気持ちで(!?)、新しいプラットフォームのサポートなら誰もやるまいと思ってソースをいじり始めたのでしたが、いかんせん１２月は海外渡航業務が重なって週末が完全につぶれるという憂き目にあい、すっかり不完全燃焼で終わってしまいました（もちろん未完成でも現状有姿で当日に出すつもりでしたが）。しかもTizenで先鞭をつけられちゃうしィ。Xwtでまともに動くようになるまでは、まだまだかかりそうです。

…とまあ2016年はこんな感じです。

2017年の予定

いつもなら年末年始はのんびり過ごしつつコードを書いたり長大な記事を書いたりしているところなのですが、今年はいつもより少々慌ただしい感じになりそうです。とりあえず明日を目標に、以下の3つについて書く予定です。また来年もよろしくお願いします。

  • Raspberry Pi etc.で楽器を作ろうハッカソン
  • 技術書典2でXamarin本を出そう
  • Xamarin.Forms訳本勉強会について

2016年の終わりに感謝する作品集

毎年クリスマスまたは歳末に書いている恒例のエントリです*1。例によって今年初めて出会った作品がメインであり、今年リリースされた作品には限りません。

2015 2014 2013 2012

まずは音楽から。

Electrocutica "Piano Lesson"

electrocutica.com

アルバム"SWANSONG"は、最初、曲目を見て、何だよまた旧作だらけじゃねーか!と思って半ば冷めた目で見ながら聞いていたのですが、vocaloidではなく人が歌っているバージョンの完成度の高さに気付いてから、すっかり聴きこむようになってしまった1枚です。

その中でもPiano Lessonがすごい。…えろい。今年出会ったあらゆるものの中で圧倒的でしたね。雨音のパーカッションとそれを引き立てる（珍しく?）控え目なリズムセクション、存在感のあるアップライトピアノとメロディラインを弾いているはずなのに他の音の存在感を引き立てるエレクトリックピアノの対照的な繋ぎ合い、vocaloid版には無いミステリアスなモノローグの囁き、どれも繊細に作りこまれているのが分かる。ホワイトノイズ多めのサウンド構成のSWANSONG（8曲目）と比べてハッキリと聞こえるブレシングも、やはり意図的な構成でしょうか。モノローグが鬱展開(?)になるのに合わせて、輝度の高いストレートなエレピから、ロータリーのかかった沈み込むようなエレクトリックオルガンに切り替わる流れも、よく雰囲気を出しているし、そのままの不安定な構成でしばらく続けて不安感を描写するのもうまい。

Electrocuticaはその音作りがプログレッシブで面白いので昔から聴いていますが、これはひたすら美しさを受け止めるという新鮮な気持ちで聴けた作品でした。

Lemm "Atoropa"

www.youtube.com

2014年の終わりに「はやく復活しないかなあ」みたいに書いていたところ、もう復活されたということで嬉しい限りなのですが、戻ってきて出できた作品がいきなりすごい。初音ミクsweetを前面に押し出した基本的なテイストも、前衛的なリズムの楽曲も従来通りで、安心して聴けるのですが、サウンドプロダクションとかかなりレベル上がってる（というのは過去作品と比べて、それぞれの音がずいぶん聞きやすくなったという感想ですが、自分自身がそんな高度な技術をもっているわけではないし、適切な表現なのかは自分でもよく分かりません）。氏の昔の作品で聴かれる「音の洪水」とはずいぶん印象が違うと思います。

www.nicovideo.jp

しかも音楽だけじゃなくてこのPVまで自作とかすごい。去年書いた暗鳴ニュイの人もそうだけど、この界隈はマルチタレント多すぎでは…

それにしても、monochromiaのblindもそうでしたが、意味を理解しないで聴きたいくらいdepressingな歌詞を書くのに（「突き放す手で…触れてくれるの?」とか、ちょっと思いつけない）音のほうはこんなにencouragingなのか。皆に幸あれ。

次はソフトウェア。

Classeur

classeur.io

classeurはブラウザで動作するマークダウンエディタです。編集中にmarkdownの文法を解釈して強調や画像の展開などを行ってくれるので、AtomやVSCodeみたいな「単なるテキストエディタ」で、別タブのプレビュー画面と編集画面の間で視線を行ったり来たりするより、ひとつの編集画面だけでいろいろ完結できるので楽です。qiitaと違って「投稿」を意識することもないし、そのぶん草稿リストの管理もストレートです。

この草稿字体も（投稿先ははてなですが）classeurで書いています。

実装にはStackEditが使われていて、コレ自体はHTML5のoffline storageを活用しています。Google Docsが日本語IMEをinjectしすぎでバグバグで基本的な利用に支障がありすぎたので、しばらく前からStackEditに切り替えていたのですが、StackEditはだいぶnaiveなところがあって、ブラウザ環境が変わるとローカルストレージが切り替わるので結局Google Drive拡張などを使用して共有するしか無いのと、コンテキスト ドキュメントが1つしか開けないために複数ドキュメントを編集できないという致命的な問題があって、なかなか主要なエディタとしては定着できていませんでした。

Classeurはその辺りの問題をきっちり解決してくれていて、主にちゃんとWebサービス化しただけなんですが、UIもきれいに作りなおされていて、素人でもとっつきやすいエディタだと思います。

Visual Studio Code

VSCodeは、わたしがようやく最近のJavaScript/TypeScript事情を真面目に眺めてみようと思うようになった原因です。VSCode自身がnodeベースのOSSアプリで、それ自体が標準的なnpmのパッケージとして作られていて、アドイン拡張の基盤もnodeのやり方で開発できるので、ちゃんと勉強する意味があると感じさせてくれたものです。

また、VSCodeは、単なるbetter (あるいはin-house) text editorを目指して作られたものではなく、標準としていくつかのオープン プロトコルを提案しているところも魅力的です。この辺は既に紹介しているので（language server protocol、debug protocol）、それぞれ参考にしていただければと思います。どれも「VSCodeが初めて」というわけではありませんが、言語開発コミュニティにもエディタ開発コミュニティにも呼びかけて、全体としてバベルの塔状態を解消していこうとする姿勢は、とても新生Microsoft（本家）らしくて良いと思います。

最後に映画（珍しく）。

聲の形

今年はゴジラ、君の名は、この世界の片隅に…と、名作と呼ばれる日本映画がたくさん出てきた1年でしたが、個人的に一番響いたのはコレでした（意外にも同じ意見の人がわたしの周りにはほぼいなそう）。かなり予備知識無しで、CM動画だけを見て「単純な恋愛モノかな…?」程度の認識で見に行ったのですが、そんな要素はだいぶ隠蔽されていて（そうでもないか）、ひたすらchallengedな行き方を余儀なくされた聾唖者と、その周辺の人々のすれ違いを描写した作品でした。

あまりその魅力を語れる言葉が無いのですが、自分の状況にもある程度近いものがあり、1人で無理することなくがんばってやっていこう的な気持ちになったものです。

また来年も

心を突き動かされるような作品に出会えると良いなと思います。あと、他人にそうしてもらうだけでなく、自分でも何か出来るようになりたいですね。

*1:大元はコレだったんだけどもう誰も覚えていない気がしますね。

C91: 「なないろAndroid」にJavaCPPの記事を書いた

C91（冬コミ）が近づいてきましたね。

 

今回のコミケにもTechBoosterが技術誌を発行するということで、わたしも「AndroidでJavaCPPを使用する」という記事で参加しています。

techbooster.github.io

本当はAndroidにおけるJavaとC++の相互運用の最新事情をいろいろ調べてDroidKaigiでしゃべるつもりだったのですが、明らかに多くの人の興味を引くネタではなかったのでめでたく不採用となり、それなら今急いで調べなくてもいいかということで、今冬はとりあえずJavaCPPのみを調べてみることにしました。

 

C++相互運用は、わたしの中では「いつまで経っても解決しない.NETの課題」のとしてずっと関心をもっているネタのひとつで、当然ながら.NET以外の世界ではどう回っているのかも気にしています。

 

詳しくは本編を（買って）見ていただければと思うのですが*1、ここでも簡単にJavaCPPを紹介しておこうと思います。ちなみにわたしの寄稿部分は100% JavaとC++の話です。.NETは出てきません。あしからず。

 

github.com

JavaCPPは、C++ライブラリのヘッダから自動生成されるC++の中間ソースコードと（それをビルドして得られる）ネイティブglueライブラリを使用するタイプの、JavaとC++の自動的な相互運用を実現するプロジェクトです。

 

これ以外の「タイプ」でどのようなプロジェクトがあるかというと、プラットフォームの違いをglueライブラリで吸収するのではなく、プラットフォーム別のABIの違いを吸収するネイティブライブラリを活用して、ユーザーが純粋にJavaライブラリだけをビルドして配布することができる類のものです。一番有名なものはかつてSun Microsystemsで開発されていたJNAでしょう。また、5年前にBridJについて多分世界で2番目くらいに詳しい記事を書いたので*2、それを見てもらえればと思います。

 

d.hatena.ne.jp

JavaCPPはLLVMプロジェクトのclangを使用していて、それ自身の実装は割とlightweightに出来ています。BridJなど自前でC++ヘッダパーサーなどを書くのに比べてメンテナンスコストが低く、実際に現在でも継続している数少ないプロジェクトのひとつです（BridJはほぼ停止しています）。この「現在でも継続している」という特徴は割と無視できないもので、たとえばサンプルプロジェクトにもtensorflowのバインディングなどが存在しています。

 

JavaCPPのような、中間ライブラリ生成方式のフレームワークのデメリットは、結局プラットフォーム別にJNI呼び出し用のネイティブライブラリをバンドルしなければならず汎用性を損なう、という側面にあって、Androidの場合も例にもれず面倒なところです。そんなわけで、その辺をどうするか、みたいな話を主に書いています。

 

当日(12/29)はわたしも（たぶん午後あたりから）参加していると思うので、ぜひTechBoosterのブースに遊びで話しかけてやってください。西れ-63ab にあります。

*1:ちなみにわたしは（というか関係者全員）宣伝しても全く収入になるわけではなくて、せいぜい売上で食べに行く打ち上げの食事がうまいものになる程度です。

*2:記事があるかはさておき作者が一番詳しいはず

"Community Code of Conduct" 日本語訳を公開

ひさしぶりに日本語訳を作る作業をやってみました。あれば使うコミュニティもあるだろうと思いまして。*1

 

Community Code of Conduct日本語訳 · GitHub

 

12/3 追記: 公式サイトでも日本語が選択できるようになりました。

 

だいぶぎこちない翻訳になっていますが、適度に輸入モノ感が出ていてほしいという思いはあります。（誤訳などは指摘いただければ修正します。）

わたし自身はCoCを導入するというのはあまり…というかかなり…好きではないのですが*2、CoCが無いと立ち行かないコミュニティはあるだろうし、それらの人々には「楽な」選択の自由くらいなら、あってもよいだろうと思っています。

 

本家にもpull requestを送ってあります。

 

ちなみに、わたしが特定のコミュニティに対して、このCoCの採用を推奨したことは一度もありません。将来的にも無いと思いますが、それは状況によるかも。

 

わたしとしては、このCoCなんかより↓を意識してもらいたいなあと思うわけですが、とりあえず現時点でこれを明確に方針としているコミュニティを、わたしはひとつも知りません。「誰も特別扱いしない」って、当たり前だと思うんですけどね。

そのうち、これがちゃんと出来ていないコミュニティからは脱退しようと考えています。*3

*1:まあ、このCoCで直接解決できる問題をかかえているコミュニティは、わたしの周りにはありませんが。

*2:どちらかというとNCoCに近い立場です。ただ、NCoCでは今そこにある問題に立ち向かえないとも思います。

*3:明文化しなければ脱退する、という宣言ではありません。

mono, netcore, netstandard

Connect2016のQ&AセッションでMiguelが質問されて回答していたので、前々から（.NET Fringe Japanの頃から）書こうと思っていたネタをざっくり書こうと思います。

 

.NET CoreはMonoの代わりにはなりません。

 

.NET Coreは「クロスプラットフォームの.NET Frameworkのサブセット」であり、その立ち位置はどのプラットフォームに行っても変わりません。

 

Monoは.NET Framework相当のオープンソース実装なのです。

 

.NET Coreでデスクトップ相当の機能は使えないのです。たとえばWindows Forms。System.Xamlも使えないでしょう。WCFのサーバサイドも動かないでしょう（まあ、もともと未完成ですが）。System.MessagingやSystem.DirectoryServicesみたいなのも動かないんじゃないかな。

 

Gtk#とそれに基づくアプリケーションを動かせるのも、現状ではMonoだけでしょう。これまで何度も書いてきましたが、MonoにはMonoのエコシステムがあるのです。

それは簡単になくなるようなものではない。

 

実装面でも、Monoのクラスライブラリは着実にreferencesourceや、最近はcorefxも取り込んだりしていますが、それでたとえばmscorlib.dllの内容が変えられるものではないわけです。

 

.NET Standardの説明とかでよく出てくるのがコレですが、

https://msdnshared.blob.core.windows.net/media/2016/09/dotnet-tomorrow.png

 

この図は誤解を招くので、使うべきではありません（断言）。ここでrule them allしているOne libraryは、ただのreference libraryなのです。実装ではないのです。だから、実際にはプラットフォーム毎に実装ライブラリがあるわけです。oneどころではない。紛らわしいから、one libraryなんて軽々しく言うべきではないのです。

 

.NET Coreと.NET Standardの関係も、当初の.NET Coreの目論見からはだんだん離れつつあるのかもしれません。個人的にはいいことだと思っています。.NET Coreはデスクトップやモダンなモバイルという、基本的にはそれなりにリッチな環境をターゲットにしているわけで、もう少し小さなフレームワークでは実現が難しいでしょう。Unityみたいな環境もあるわけですし。過去の最小限のデータアクセスAPIでは、ASP.NET Coreアプリケーションの開発も困難であると言えそうですし。

 

というわけで、.NET Coreは標準APIという足枷を外して、ただし無分別にレガシーを取り込むこと無く、進んでいけばいいなと思っています。

vscode-language-reviewを公開します

vscode-language-reviewは、VSCode (Visual Studio Code)でRe:VIEWマークアップドキュメントを編集しやすくするためのVSCode拡張です。

Visual Studio Marketplaceで公開しているので、VSCodeから簡単にインストールできます（作者がatsushienoのほうです）。

installing vscode-language-review

ソースコードはgithub (atsushieno/vscode-language-review)で公開しています。

screenshot

Re:VIEWの文化的・技術的背景

Re:VIEWは、一部の技術系同人誌界隈ではよく使われているフォーマットで、Webページとしての表示に加えて、紙媒体を意識したレイアウトに適している記法を多くサポートしています。わたしがよく寄稿しているTechBoosterでは、このRe:VIEWを使用して同人誌を発行していますし、Re:VIEWを使いこなすためのガイドも公開しています。

VSCodeでRe:VIEWをサポートするということは、具体的には次のような機能が期待されます。

  • （ライブ）プレビュー表示
  • タグジャンプ
  • 文法/表記チェック

Re:VIEWは、ツールとしては、テキスト、HTML、PDF等への変換処理を行うものであり、本家はrubyで開発されているのですが、これをJavaScript環境向けに移植したreview.jsというものがあります。また、Atom用プラグインlanguage-reviewも開発されています。

VSCodeはnodeアプリケーションであり、VSCode拡張を開発するには、JavaScriptライブラリを扱うのが最適です。

ゼロから始めるVSCode拡張の開発

vscodeは一般的なnodeアプリケーションであり、オープンソースで開発されています。一般的なnodeアプリケーションは、npmでビルドの実行、パッケージ作成、インストールができるようになっています。

vscodeの実体は、さまざまなモジュールの集合体です。Electronなどのサードパーティ部品と同様、vscode用に開発された独立モジュールも数多くnode_modulesとして参照しています。githubのMicrosoftアカウントには、vscode用のモジュールが大量に含まれています。

vscode拡張は、vsixというパッケージとして、Visual Studio MarketplaceのVisualStudioCodeカテゴリ以下で配布できます（VSCode本体からインストールできるようにする必要がなければ、単独でビルドしたものを配布しても良いでしょう）。vsixパッケージは、vsceというツールを使用してプロジェクトのディレクトリから直接生成してmarketplaceに送信できます。vscode拡張のnodeプロジェクト自体は、標準的なnodeパッケージとして開発・配布できます。

vscode拡張を作成する一番簡単な方法は、yeoman generator経由で利用できるvscode用テンプレートをスタート地点にすることです。vscode-generator-codeをインストールした後、 yo code を実行すると、vscode拡張用のテンプレートを作成するためのダイアログが表示されます。

yo code

11/06 追記: スクリーンショットが自前の修正版のものになってしまっていて、New Languageの選択肢が2つ出てしまっていますが、公式版のvscode-generator-codeにあるのは1つだけです。

今回のvscode-language-reviewの場合は、ここでNew Languageを選んで始めたわけですが、（2016年10月時点では）テンプレートにTypeScriptが存在しないため、JavaScriptベースのテンプレートが展開されました。その結果、.vscodeディレクトリの内容を含む基本的な構成がJavaScript用となってしまい、後になってハマることになりました（具体的には、プロジェクトのビルドが走らないとか、プロジェクトがデバッグできないとか）。New Languageテンプレートを選択しないと調整されない項目もあるので、この辺りは痛し痒しです。筆者はTypeScript用のテンプレートを含むforkを作成しているので、それを使う手もあります。

ともあれ、JavaScriptテンプレートを選択したけど、TypeScriptで開発したいという場合は（vscode拡張の場合よほどの事情がなければTypeScriptで良いのではないでしょうか）、TypeScriptテンプレートから生成される .vscode フォルダの内容を、自分のプロジェクトにコピーすると良いでしょう。

VSCode拡張の実行のブートストラップ

テンプレートNew Extension (TypeScript) からプロジェクトを作成すると、 src/extension.ts というファイルが作成されます。これがこの拡張のエントリポイントになります。

vscode拡張は、通常のnpmパッケージと同様、package.jsonにさまざまな情報を記述して、実行したり、パッケージしたりすることになります。package.jsonのトップレベル要素はobjectですが、この中に main というキーがあって、その値に実行するJavaScriptファイル名を指定することで、それがそのvscode拡張のエントリポイントを探すファイルになります。TypeScriptの場合は、上記テンプレートから作成すると ./out/src/extension となっています。VSCodeは、このスクリプトの中から、activate() という関数を探して呼び出します。

export function activate (context : vscode.ExtensionContext) { ... }

この関数の中で、自分のvscode拡張の初期化処理を行うことになります。vscode-language-reviewの場合は、ここでpreview機能をVSCodeのコマンドとして登録しています。

package.jsonの内容や、vscode拡張の基本的なファイル構成については、vscodeサイトの説明がとてもわかり易く書かれているので、これを参考にすると良いでしょう。

TypeScriptプロジェクトにした場合は、 package.json と並んで tsconfig.json というファイルがあります。これは、TypeScriptコンパイラでこのプロジェクトをビルドする際に使用されるオプションを記述しておくためのファイルです。基本的に、TypeScriptプロジェクトのテンプレートから変更する必要は無いでしょう。ここに、例えば "sourceMap": true という記述がないと、tsソースファイルから、実行するjsファイルを出力した際に、デバッグ実行に必要なsourcemapが生成されなくなってしまいます。

もうひとつ、vscodeでは、拡張プロジェクトのフォルダを開いている時に、F5キーを押すだけでデバッグ実行を開始できますが、その際には .vscode という隠しフォルダ（Unix系OSの場合）の中にある各種ファイルの内容が重要になります。これも基本的にテンプレートから生成される内容を修正する必要はないでしょうが、これがVSCodeの想定外の内容になっていると、正常なデバッグ実行が行えなくなる可能性があります（筆者はJSテンプレートからTSプロジェクトを作成していたため、ここでハマりました）。また、.vscodeの内容は個人設定のような性質のものではないので、リポジトリにcheckinしておく必要があります（そうしないと、他の人がビルドできません）。

vscode-language-reviewモジュール

vscodeの言語サポートパッケージは、Microsoftとしては vscode-language-XXX という名前を慣習的に使用しているようです（例: Microsoft/vscode-language-json, Microsoft/vscode-language-css）。今回のreviewサポート拡張もこの命名規則に倣っています。

vscode-language-reviewのpreview機能でやっていることは、markdownのpreviewに近いです。その具体的な実装は、簡潔に言えば、以下の2ステップで実現しています。

  • アクティブドキュメントの内容をre:viewドキュメントとしてreview.jsのAPIで変換する。review.start()で変換処理を行いますが、その際にその引数パラメーターControllerを設定することで、具体的な変換処理を指示します。基本的にはreview.js本体に含まれているサンプルをもとに作成しています。
  • vscode.previewHtmlというカスタムコマンドを使用して表示する。カスタムコマンドとは、vscodeの高水準APIとして組み込まれている機能で、vscode拡張を書いている時は、コマンドAPI vscode.commands.executeCommand() を使って呼び出せます。

review.jsのstart()関数から変換した結果生成されたHTMLは、あくまでbody要素の内容のみ、という感じで、その内容をそのまま先の vscode.previewHtml で表示させると、画像が全く展開されませんでした。これは、HTMLに（headの内容となるべき）base要素などが存在せず、結果的に画像の相対パスが解決できなかったことが原因だったので、base要素はreview.jsの変換結果に継ぎ足すようにしました。

ここまで出来て、とりあえず原稿のライブプレビューは出来たようだと判断したので、vscode-language-review 0.1.0として公開しました。今後もセクションジャンプやprhによる校正支援などを取り込みたいなあと思っています（が、もし誰か他にやってくれる人がいたら大変嬉しいです…!）

とりあえず、最低限の機能はできていると思うので、VSCodeでRe:VIEW原稿を編集したいという方はぜひ使ってみてください。

感謝

この拡張を作るにあたっては、vscode拡張の先駆けとして vscode-uiflowのソースがとても参考になりました。

.NET Fringe Japan 2016が見せた「オープンな.NET」という世界

本当はこのイベントが決まって正式に公開された時に告知するつもりだったのだけど、ちょっと他のこと（主に前回書いたcomcampの件）で待ちに入っているうちに定員をあっさり超えてしまって、またその機会を逃してしまって忸怩たるものがあるのだけど*1、ともあれ、昨日無事.NET Fringe 2016というイベントをみんなで開催した。

dotnetfringe-japan.connpass.com

"Fringe" とは「非主流派」のような意味の語句で、わたしはそれを「異端」と呼んでいた。本家とは実のところ一度しか話していないのだけど、.NETのイベントではあるが、なるべくMicrosoftべったりにならず、独立したイベントとして開催したい、という趣旨だった。日本ではそこまで独立しなくてもいいかな?という見方が（わたしも含めて）大勢だったけど、結果的に会場もドワンゴのオフィスをお借りしてニコ生で流すというやり方になった。

いろいろ問題はあったかもしれないけど（スライドの字が見えなかったりとか）、内容としては大成功だったと思う。わたしの中では、今年一番の刺激的なカンファレンスになった。会場でも数多くのコメントが見られた。

.NET Fringe Japan 2016 (ドワンゴ・松竹スクエア) - Togetterまとめ

.NET Fringe Japanでは「オープンソースになった.NETテクノロジーではこんなことが出来るんだ!」という強いメッセージを発信できたのではないかと思う（いや、そこまで意図して開催したわけじゃないけど、結果的に）。roslynを通じてC#コンパイラや言語仕様を拡張するには具体的にどうすればいいか（何をすべきか、すべきでないか）、という内容のセッションがあった。coreclrのソースコードをハックして、独自のIL opcodeを定義するにはどうすればいいか、具体的に実践してみせたセッションがあった。クロスプラットフォームの.NETライブラリをどう開発するのか語るセッションがあれば、その具体的な仕組みをdotnet（コマンド）のソースコードから解明するセッションもあった。発表者がナチュラルに.NET Coreのソースコードに踏み込んで紹介していく風景が、そこにはあった。

Jonathan Zittrainは、Future of the Internet (and how to stop it)の中で、ユーザーに多大な可能性と創造力をもたらしたApple IIを（ユーザーにはAppleが望んだことしか出来ないiPhoneと対比して） "generative technology" と表現した*2。.NET Coreはまさにこのgenerative technologyである、と言って良いんじゃないかと思う。.NET技術を消費し、その上に乗っかるだけではなく、その土台そのものに再生産を加える（そのために採ると有益そうな指針）など、そんな話がたくさん聞けた1日だった。

わたしも「Monoならオープンソースなんだからこんなことが出来るんだよ」みたいな話を（これまで）ずっとしてきたわけで、.NET Coreが（日本でも）そこまで到達したと思うとうれしみがある。（今回やったXamarinのソースを追っかける話は、他の人たちほど深入りした内容ではなかったけど、似たような話はある程度はできるので、似たような機会があればお話ししたい。）

まあ、それはあくまでわたしの感想であって、今回は主に濃密なセッションを10時間近くぶっ通しで続けた、というところが突出していたと思う。これだけのスピーカーに集まっていただけたのはとても運が（あるいは日頃の行いが）良かったと思う。

今回のイベントをだいたい仕切ってきた鈴木さん (@yukitos) は、来年にも第2回を開催したいと宣っているので、今回楽しめたという皆さんは楽しみにお待ちいただければと思う。手伝ってくれるという人も募集しているので、もし興味があれば、gitterチャネルで声をかけていただいて、みんなでうまいこと楽にやっていけたらと思う。

それではまた次回をお楽しみに。

*1:「告知する」とまで書いていたのに…(__;

*2:日本語訳では「生み出す力を持つ肥沃な技術」と訳されているのだけど、長ったらしいので原文から引っ張ってきた。