"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として参照しています。githubMicrosoftアカウントには、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:日本語訳では「生み出す力を持つ肥沃な技術」と訳されているのだけど、長ったらしいので原文から引っ張ってきた。

台湾のカンファレンス参加とXamarinコミュニティ始動によせて

2週間ほど前の話ですが、8/27に、台湾のMicrosoftが開催したオープンソース コミュニティのイベントであるCommunity Open Campで、Xamarin.Android SDKの話をしてきました。

community-open-camp.azurewebsites.net

たまたま(?)、米MSのchannel9部隊が来台していて、セッション動画を全部録画していました。わたしの分も公開されています。

channel9.msdn.com

ただ、なぜかわたしが喋っているだけの動画になっていて、スクリーンが全く写っていないという…スライドはこちらで読めます。

speakerdeck.com

それで、ついでにセッションスピーカー数名にインタビューを行っていたらしく、その動画もついでに録画されちゃいました。(リンクだらけになってくどいので、↑の関連動画から見てください)

Community Open Campは、基本的にVSCodeやAzureなど、MS技術に絡めたセッションがほとんどだったと思いますが、MSのコミュニティ マネージャーが、いろいろなオープンソース技術のコミュニティに出向いていって、セッション担当や一般参加を呼びかけていったようで、わたしが台湾に住んでいた頃に出入りしていたコミュニティにも顔を出していて(わたし以外にMS技術を紹介するようなメンバーは皆無でした)、自分たちのフィールドの外に積極的に出ていって頑張ってるなあと思ったものです。会場も台北ではこの種のイベントでお馴染みの中央研究院でした。

わたしのセッション内容は、7月頭にYAP(achimon)Cでしゃべった内容をベースにしつつ、いろいろアップデートして、かつ後半の高度な内容を飛ばす代わりに、コン ソールからフルスクラッチでXamarin.Androidアプリケーションのソースを作成してxabuildでapkをビルドしてadbでインストール して実際に動かす、というライブコーディング(と言っていいのだろうか)、という構成になりました。英語セッションでしたが、150-200人くらいに見てもらえたんじゃないかと思います。

わたしの他に、Xamarinのセッションを担当していたyahooの技術者がいたのですが(話しそびれた)、そちらで全体的な導入をやってもらえたおかげで、わたしは好き放題しゃべったという感じです。おそらく世界の誰もやったことないであろう実用性ゼロのデモで、一部の参加者はエラいものを見たという感じで喜んでいましたが、全体的には参加者を煙に巻いたことだろうと思います(!?)

イベントの後、しばらくうろうろしながら、聞いてくれた人たちと雑談したり、↑のインタビュー動画を撮ったりして過ごした後、最寄り駅付近でspeakers' dinnerに参加して、他のスピーカーの人たちといろいろ技術雑談を楽しんできました。彼らの多くはホントにふだんMS技術に関与しないような技術者で、日本でよくやっているような身内イベントとは大違いでした。

翌々日8/29には、別のMSのコミュニティ マネージャーが、初めてのXamarinユーザーミーティングを開催して、そこで今度は、XamarinというかMonoがどんな感じで誕生したかを紹介して、どうやって自分がそこに入り込めたか、みたいな話をしてきました。(技術セッションを準備する余裕は無かったし)

speakerdeck.com

これでうまいこと扇動されてXamarinやら各種MSプロジェクトに限らず誰かOSS contributorとして参加していってくれるようになるといいなあという感じです。皆だいたい中国語で交流していたので、わたしは半分くらいぼんやり眺めていたのですが、MSPの学生の人たちなんかも来ていたりして、また少し新しい種類の繋がりも出来たのでした。

さて、ここまでは前フリです。

今回これらのセッショントークを行ってきたのは、わたし(というかXamarin)が日本マイクロソフトにjoinした結果、台湾に自由に行き来できなくなって、台湾の技術者コミュニティへの参加が出来なくなっていることに起因しています。

6月、まだXamarinが存在していた時に、台湾に渡った時に、まず台湾のXamarinパートナーだったThinkpower(日本のエクセルソフトだと思えば大体合ってます)の人たちにお願いして、当時繋がりの無かった台湾MSの人に繋いでもらって、「何かイベントがあったらしゃべるから呼んで☆」とお願いしてきて、何とか実現したのです(移動も自費だし)。この時は半月ぐらい滞在していました。今回確立したXamarinユーザーミーティングでは今後も呼んでもらえそうですが、毎回わたしがセッションをもつわけにもいかないし、数回に1回といったところでしょう。

東アジアにいるXamarinのメンバーは、わたしだけなんです。台湾で同じことが出来る人は、いないんです。

今回は数日間だけ現地での交流の機会がありましたが、今のところ台湾に自由に行けるわけでもないので、このような機会は激減しています(6月に無理やり繋がっていなければ、おそらく「ほぼゼロ」になっていたことでしょう)。本当なら他の東アジア各国(できれば東南アジアくらい)まで交流の幅を広げたいのですが、現状では各国コミュニティとの繋がりもない状態から始めなければならず、ほんの数日の滞在で今回みたいな成果を出せるところまではもっていけないでしょう。

今年の春先に、日本マイクロソフトが「どこでも働ける」ようにルールを変えた、というニュースが話題になりましたが、わたしに言わせればまだ不十分です。3ヶ月に1度は他所のオフィスを見てくることを推奨しているGoogleみたいな企業を見習ってほしいと思います(推奨、というのが良いバランス感覚ですね)。

世界コミュニティに貢献するって、こういう活動だと思うんですよね。日本法人がやるべきことは、日本の従業員の可能性を広げることだと思うんです。

日本マイクロソフトには、もっとグローバルに変わってほしいと思っています。

Xamarin.Android 7.0とJava8とproguard

少し前の話題になりますが、GoogleAndroid 7.0を不意打ちでリリースしてきましたね。

Xamarin.Androidチームでは、もう少し後に出るはずというスケジュール感覚で作業していたので、この不意打ちリリースに嫌な顔をしながら進行中のcycleのリリースにAndroid Nサポートを追加する作業を行っていたわけですが、公式ブログでもXamarin.Android 7.0としてリリースが告知されたようです。

blog.xamarin.com

この辺のversioningは、今回はtarget frameworkに合わせているようですね。

 

さて、Android Nの開発者向けの大きな特徴のひとつにJava8サポートがありますが、その辺でどんなインパクトがあるかは以前まとめた通りです。

atsushieno.hatenablog.com

バインディングまわりではinterface default methodsは現状相変わらず面倒なのですが、まあさすがに今JavaライブラリでAPI定義をJava8依存にしてターゲットをめちゃくちゃ限定することって、そうそう無いと思うんですよね*1。なわけでこの辺は(以前にも書いた通りですが)対応しても少し先送りしたいと思っています。

さて、ひとつ、今すぐ困りそうな問題が残っています。proguard対応です。これも上記エントリで言及したのですが、Android SDKに含まれているproguardは、Java8のバイトコードを処理できません。

ただ、Jack(新しいJava8対応コンパイラ)がproguardの代わりとなって処理できる機能を有しているように見えるものの、Android Studioでわたしが試してみた感じでは、proguardの設定ファイルに基づく処理は、相変わらずproguardが行っているようです。Gradleコンソールには以下のような出力が見えました。*2

ProGuard, version 5.2.1
Reading input...
Reading program jar [/home/atsushi/Desktop/Java8ProguardExperiment/app/build/intermediates/exploded-aar/com.android.support/support-compat/24.2.0/jars/classes.jar] (filtered)

 

このproguard、バージョンが5.2.1なんですね。Android SDK toolsに含まれるproguardは(25.1.7の時点で)バージョン4.7なので、どうやらこっちは使われていないようです。後方互換性のために残されているのでしょう。android-studioのディレクトリの中を探ると、android-studio/gradle/m2repository/net/sf/proguard/proguard-base/5.2.1/proguard-base-5.2.1.jar というファイルが見つかります。こちらが使われていると考えて良いのではないでしょうか。*3

いずれにせよ、Xamarin.Androidで使用しているのは、Android SDKに含まれるproguardなので、これではせっかくJava8に更新したのにproguardで躓いてしまってもったいないし、特に外部ライブラリがJava8でビルドされていると(android-support-v4…をsplitしたやつ…など)、proguardが使えなくなってしまいます。これでは困る。

そんなわけで、とりあえず、自前でビルドしたproguardをバンドルして、xamarin-androidの中でproguardを呼び出している部分で、代わりに呼び出すようにするパッチを作ったのですが、

github.com

proguardってGPLv2で配布されているんですよね。これを取り込んで配布したいかというと、出来れば回避したいので、少しやり方を変える必要があるかもしれません(無いかもしれません。そこはMicrosoftがどう変わったか次第)。

いずれにしろ、この変更が取り込まれてリリースされるまでには、まだ数ヶ月単位で待たないといけないはずなので、それまでの間このproguard問題を回避する方法を書いておこうと思います。proguard.jarのファイルパスは、MSBuildプロパティProguardJarPathで変更できます。なので、プロジェクトをMSBuildやxbuildでビルドするときに、/p:ProguardJarPath=/path/to/your/proguard.jar を指定してやると良いです。*4

コマンドラインでビルドなんかしないYO!という人は、.csprojを編集して、最初の<PropertyGroup>要素の下にでも <ProguardJarPath>/path/to/proguard.jar</ProguardJarPath>を追加しておけば良いでしょう。(git commitするなど、他所に持って行く前に消す必要はありますね)

実のところ、「これで動くはず」という以上の実験をしているわけではないので、これで試してみてダメだったら、わたしに適当に伝えてもらえれば、もう少し見てみます。

*1:ちなみに、Android Nのandroid.jarでは、このデフォルトメソッドが派生クラスでばんばん使われています。API定義上は少なくともJavaの文脈ではbreaking changeにはなっていないはず。

*2:Java8だとjackを使っているはずだけど、どうやってInstant Runとの整合性をもたせているんだろう…?という興味があって試している時に観測しました

*3:見当違いで、IntelliJ IDEAがpure Java環境用に使っているだけの可能性もあります。

*4:proguard 5.2.1のproguard.jarを持っていない人は、自分でソースからビルドするか、Android Studioを入れた後に前述のパスからコピーしてくると良いでしょう。

Xamarinの新しい話とMonoの深い話 @ dotnetConfJapan2016

セッションの詳細が決まった頃にはとっくに満員になっていて書いてもしょうがないと思って粛々と登場したのですが、表題のイベントで会社の先輩(自称)としゃべってきました。視覚的な情報は 先輩 がまとめています。って仕事早いな!

blogs.msdn.microsoft.com

本当はMonoの深い話だけのつもりだったのですが、結果的にむしろMonoの話はわたしのほうが丸投げするかたちになってしまいました。スライドには、わたしが補足で作ってきたもののしゃべる機会が無かった「Monoつうのは本来だな…」という話題が含まれています。

本当はLinkerの歴史(Moonlightの頃からある)とか実装の使われ方とかも説明したかったのですが、ちょっと時間的に無理でしたね。Miguelが本家dotnetconfで紹介していたAdvanced Linkingはこの辺にソースがあるので、興味ある方はどうぞ。Nugetizer 3000の話も尻切れトンボになっちゃいましたね…

2人セッションの準備のために、事前にMiguelのセッションの内容を説明していたのですが、あのセッション、そこそこ難しい話をしていたのですね。1人でしゃべるのであればそこまで意識しなかったであろう(というかしゃべるつもりすらなかった)根本的な仕組みの話も、ちゃんと説明せなあかんのだろうなあという気付きを得ました。

そんなわけで、主に(というかほとんど)「漫才たのしかったです」「Eテレでしたね」みたいな感想をいただいたのも、実のところ概ね予想通りで、初めての試みで手探りでしたが悪くはなかったのかなと思います(…って書いてて気づいたけど漫才はこの前もやった気がしますね…!)

そんなわけで次は(他に入らなければ)準備中のイベントでDeep Diveなネタを今までどおり単独で話すことになると思います(反省の色がまるで無い)。決まったらまたお知らせします。