Microsoft、.NETをMac、Linuxに移植、サーバ・サイドをオープンソース化すると発表

Microsoftの.NETフレームワークはこの12年にわたっってWindowsでアプリケーションを開発するデベロッパーのプログラミング・モデルとなってきた。今日(米国時間11/12)、Microsoftはデベロッパー・ツールのクロスプラットフォーム化の努力を一歩押し進め、近く.NETをMacとLinuxに移植することを発表した。同時に、.NETのサーバ・サイド(クライアントの.NETではない)のコア・スタックを次のバージョンからオープンソース化するという。

Microsoftはすでに今年に入って.NETコンパイラをオープンソース化しているから、今回の決断もまったくの不意打ちというわけではない。それでも多くの専門家は“Microsoft”という言葉と“オープンソース”という言葉が同一の文章の中で使われることに驚きを隠せないかもしれない。

Microsoftのデベロッパー事業部を担当するコーポレート・バイスプレジデントのS. “Soma” Somasegarは私の取材に対して、「.NETフレームワークを利用してプログラミングを行っているデベロッパーは600万人程度だ。普及の点でわれわれは大成功を収めている」と述べた。問題はこの成功をベースにさらに前進するにはどうしたらよいかだ。

しかし、サティヤ・ナデラがCEOに就任した後のMicrosoftの動きをよく観察すれば、今日の決定も納得できるだろう。たとえば、今年のBuildデベロッパー・カンファレンスでMicrosoftは.NET Foundation の設立を発表しているが、この組織が今回のオープンソース化の受け皿となった。

適切な判断といえるだろうが、MicrosoftはXamarin社と同社が後援するMonoコミュニティと協力していくという。XamarinはすでにC#を用いたオープンソースでクロスプラットフォームの.NETフレームワークを開発し多くのデベロッパーの支持を得ている。Somasegarは私に「今回の発表の後、オープンソース化の作業については、数ヶ月かけてMonoコミュニティーと協力していく。われわれはXamarinと非常に密接な協力関係にある」と語った。

Somasegarは「クロスプラットフォーム化とオープンソース化は.NETにとって将来へ向けての大きな一歩だ。Microsoftは.NETをさらに普及させたい。そのための最善の方法は新たなプラットフォームへと拡張することだ」と述べた。

数日前、私はMicrosoftのクラウドおよびエンタープライズ担当エグゼクティブ・バイスプレジデントのScott Guthrieを電話で取材したが、彼も同じ趣旨のことを述べ、「われわれはデベロッパーからしばしばく『.NETはすばらしいプロダクトだと思うが、クローズドでWindowsしかサポートしていないから使わない』という声を聞いていた。水曜日の発表を聞けば.NETを使わない理由がすべて消滅したと知るだろう」と語った。

SomasegarはこれによってMicrosoftのパートナーには多くのチャンスが訪れることを強調した。たとえばDockerの事業開発とテクニカル・アライアンスの責任者、Nick Stinematesは「われわれのDockerオープン・プラットフォームの最大の価値は、 Dockerコンテナを利用してさまざまなインフラにDockerアプリケーションを移植できるポータビリティーの高さにある。オープンソースの.NETランイタイムをすべての主要なOSプラットフォームに提供するということは、Microsofがポータビリティーの概念をアプリケーション・プラットフォームそのものにまで拡大したことを意味する」というコメントを発表してている。

Microsoftはオープンソース・コミュニティーとの会話を開始する手始めとして.NETのコードのGitHubレポジトリを開設する計画だ。最終プロダクトがどのようなものになるかまだ分からないが、Somasegarは「近く.NETアプリをMicrosoft AzureのLinuxのDockerコンテナで動かせるようになる」と述べた。

これにともなって、デベロッパーを法的紛争から保護するため、MicrosoftはMonoプロジェクトとそのユーザーすべてを対象とした新たな特許特約を公表した。

企業が主要プロジェクトをオープンソース化すると、ユーザーは「企業がそのプロジェクトのサポートを止める前触れではないか?」と不安になるのが常だが、SomasegarもGuthrieも「そういう考えは毛頭ない」と強く保証した。

これほど大きな発表であれば、読者には質問したいことも山のようにあるだろう。Somasegarは直接質問に答えると約束してくれた。〔元記事の〕コメント欄に質問を書き込んでいただきたい。太平洋時間11:30amから受け付ける。

[原文へ]

(翻訳:滑川海彦@Facebook Google+


Android vs. iOS, アプリはどっちから先に作る/売り出すべきか

“AndroidとiOS、どっちを先にやるか?”という、スタートアップにとって永遠の問いは、ますます難問になってきた。Androidのマーケットシェアが80%を超えた、というニュースがあったからだ。でも、経営者や非技術系のファウンダはさておき、かんじんのデベロッパ! デベロッパ!は、この対立をどう考えているのか? どちらが、デベロッパの人生にとって有利か?

実はぼくも、デベロッパの一人だ。本誌の記事(や小説)を書いていないときは、ぼくはHappyFunCorpのソフトウェアエンジニアだ。世界でもっとも良い名前のコンサルタント企業であり、Webサイトだ(クリックしてみて)。最近は管理職的な仕事が多くなっているが、プログラミングを忘れたくないので、ちょっとした個人的なプロジェクトをAndroid用とiOS用両方を作って、それをオープンソースにした。以下はそのときの経験に基づく、両プラットホームの比較論だ。

ぼく自身の経歴としては、これまで数多くのAndroidアプリとiOSアプリを作ってきた。仕事と、個人的なプロジェクトの両方だ。たとえば、ぼくの好きなニュースアグリゲータScanvine用に作ったネイティブクライアントは、ソーシャルメディア上で異様に広く共有されている記事を見つける。そのソースコードはGithubにあり: (Android | iOS) 、アプリ本体もダウンロードできる: (Google Play | App Store)。

比較論を始める前に、Xamarinのクロスプラットホームな開発ツールに言及しておくべきだろう。ぼく自身も、もしも自分がC#プログラマで、JavaやObjective-Cを知らない人間だったら、モバイルアプリの開発のためには、これを選んでいたと思う。

それにまた、今回のプロジェクトは、商用製品ではなくて、個人的に楽しむためのプログラミングだ。だから、テスト用のコードがない。だからiOSのハイゼンバグは、今でも手作業で調べている。サードパーティのライブラリも、gitのサブモジュールにせずに、ファイルをコピペしている。今は直したけど、Androidのビルドでレイアウトファイルにバグがあって、タブレットがクラッシュしたこともある。

では、前置きはこれぐらいにして、二頭の馬たちのゲートを開こう。さあ、走れ!

環境

コードをテキストファイルに書いて、コマンドラインでビルドすることは、今でも可能だがしかし統合開発環境(integrated development environment, IDE)を使った方が生産性は高い。

AppleはXcodeだ。使っていて楽しいし、すっきりしてるし(ごたごたの逆)、速いし、強力だし、出しゃばらないヘルプが良い。AppleはiOSのアプリやデバイスを厳しく管理するために、奇妙で独特なコンパイラと、被害妄想的な証明/プロファイリングの仕組みを持っているが、それらはXcodeの快適な外見の下に隠されている。デバッガはシームレスだし、シミュレータは速くて応答性が良い。

Androidは、ほぼ標準のIDEがEclipse + Androidプラグインだが、こいつが厄介者だ。遅い、ぎくしゃくしている、分かりにくい、そしてときにはまったく不可解。レイアウトが悪い、不必要に複雑、そして混乱。デバッガーがドジなので、ぼくはログファイルを見ながらデバッグをしている。Xcodeのデバッガは、まさに、頼りになるデバッガだ。Androidのエミュレータもひどくて、立ち上げに数分かかるし、Android Debug Bridgeに接続できないことが、とても多い。

ツイート訳: [Androidの仮想デバイスを使って開発している人なんかいるの? なんで、立ち上げに10分もかかるんだよ?]

そこでGoogleは、独自のIDE Android Studioを提供するつもりでいるが、しかし:

Android Studioは現在、初期的なプレビューバージョン(early access preview)です。まだ不完全な機能や未実装の機能があり、バグもあります。未完成の製品を使いたくない方は、代わりにADT Bundle(Eclipse + ADTプラグイン)をお使いください。

GoogleがAndroid Studioを鋭意開発中なのはよろしいが、ぼくが最初のAndroid携帯を買ってからほぼ5年になるのに、まともな開発環境がまだないとは、どーゆーこっちゃ?

勝者: 大差でiOS。


構成

上で述べたように、Xcodeの外見はすっきりシームレスだが、その下にはObjective-Cという、70年代のプログラミングの恐怖を彷彿とさせる怪獣が眠っている。おおげさかもしれないが、そう言いたくなる。マクロ、ヘッダファイル、プロジェクト、ターゲット、スキーム、そしてビルドのコンフィギュレーション(構成)。ビルドの設定だけでも、うんざりしてくる。不可解なリンカエラーが出ると、絶望あるのみ。そして、こんな発見: “あら、きみのサードパーティコードはARCをサポートしていないの? じゃあフラグ-fno-objc-arcを加えるんだよ。簡単だろ?”。

Androidではマニフェストファイルが一つあるだけで、アプリのビルドはEclipse が完全にやってくれる(正常時は)。ファイルを保存したらビルドは自動的に行われる。パーミッションの構成ミスでアプリが動かないときに出るエラーメッセージは、もっと分かりやすくしてほしいが、それはそんなに重大な問題ではない。とにかく、ビルドのための構成はAndroidの方が概してシンプル、そしてエレガントだ。

勝者: Android。


UXデザイン

勝者は当然Apple、とみなさんお思いだろう。Interface Builderを使うと、きれいなユーザインタフェイスを簡単に手早く指定できる。でもぼく的には、Interface Builderを使えば使うほど、嫌いになった。ここでもまた、構成が面倒なのだ。最初は単純で楽ちんでも、その後のアプリの進化とともに、世界はぐちゃぐちゃになっていく。とくに、Appleが1年前に加えた、マルチスクリーンのStoryboardsは、すごーく、好きくないね。

Androidのビジュアルツールもまあまあだが、それについて、あまり言うべきことはない。なにしろAndroidは製品の種類が多様で画面サイズもまちまちだから、UIをそのすべてに正しく対応させるために、レイアウトの指定をXMLファイルで書く(AppleのAuto Layoutも、今後のiOS製品の画面の多様さに対応するための仕掛けだろう)。なお、Androidではアイコンパックが提供されているが、iOSではIcons8のようなサードパーティ製品を使うか、または自作する。

意外にも‘Apple圧勝’とはいかなかった。ちょっと奇妙な結果ではある。しかし、iOSは幸運にも製品種類がとても少ないから、デベロッパの苦労も少ない。それにiOSのデフォルトのUI部品は、デザインがおおむね美しい。この二点で、iOSが有利だ。

勝者: iOS。


言語

AndroidのアプリはJavaで書く。iOSのアプリはObjective-Cで書く。その例外は、Xamarin(前述)を使うとき。ただしツールによってはマイナーな例外があるし、PhoneGapのようなネイティブ/Webのハイブリッドもある。しかし一般的には、AndroidはJava、iOSはObjective-Cでネイティブアプリを書く。

ぼくがプログラミングをやり始めたときの言語がJavaだったから、最初はObjective-Cに馴染めなかった。とくに、書く量が多すぎる、と思った。

Javaなら:
String s2 = s1.replace(“abc”,”xyz”);

Objective-Cでは:
NSString *s2 = [s1 stringByReplacingOccurrencesOfString:@"abc" withString:@"xyz"];

でも、その後だんだんとObjective-Cが大好きになった。Javaよりもクリーンな、良い言語だ。Objective-Cにはブロックブロック構文〕があり、Javaにはない。Objective-Cにはカテゴリーカテゴリ〕があり、Javaにはない。Javaでは大量の例外処理(try/catch節)を義務的に書かなければならないが、Objective-Cにはそれがない。

Javaにも、良い点はある。たとえばスタックトレースが良くできているので、散発的な(起きたり起きなかったりする)バグの原因を見つけやすい。2年前までは、ガーベッジコレクションではAndroidが断然優位だった。今ではiOSにautomatic reference counting(ARC(前述))があるので、Javaの優位は薄れた(ただし古いサードパーティのツールはARCをサポートしていないのでXCodeの構成で苦労しないといけない)。この点でJavaの優位はなくなったので、勝者はObjective-Cで決まりだ。

勝者: iOS.


API

AndroidもiOSもライブラリの規模は大きく、その内容は互いに似ている。電話機能、ネットワークアクセス、多様なViewオブジェクト…その中にはブラウザそのものとも言える強力なWebViewがある。実際の仕事は、コントローラの中で行う…iOSではViewController、AndroidではActivity。

iOSにあってAndroidにないものは、一連の機能集、フレームワークだ。たとえばiOSの強力なCore Dataフレームワークに相当するものは、Androidにない。またiOSのAPIの方がよりクリーンでありシステムとしての設計も良い。ぼくのアプリでは、iOSの場合、これこれ、二つのかなりシンプルなクラスが仕事の大半を行うが、Androidではこれこれこれ、計三つのクラスが同じことをする。そしてこれらは、10個近い内部クラスや無名クラスを使用している。結局のところ、iOSのCollectionViewControllerの方がAndroidのListAdapterよりも使いやすい。

あまり客観性はないが、ぼくのこのアプリの自作コードはiOS版が1596行、Android版が2109行だ(Java + XML)。32%もの差がある。

勝者: iOS.


インターネット

今ではほとんどのアプリが、スタンドアロンのプログラムではなく、多かれ少なかれインターネットに依存している。だからここでは、それほどまでに重要なインターネット機能を比較しよう。インターネットに関して、ツールやAPIは両プラットホームとも、たいへん多い。どちらも、互いによく似たWebViewsがあるので、どのアプリにも完全なブラウザウィンドウを置くことができる。

ネットワークへの接続は基本的にバックグラウンドで動く処理であり、アプリの本流の邪魔をしない。しかし、このようなマルチスレディング(multithreading, 処理の多重化並列化)は難しい。Androidが提供しているAsyncTaskクラスは、大きいが良い仕事をする。今オンラインかどうかをとても容易に判定できるための、便利な方法もある。iOSにも同様の機能はあるが、どれもかなり低レベルで、不満足なものだ。

しかしながら、オープンソースのライブラリがたくさんあるから、それらを使えば苦労はない。ぼくはAFNetworkingを使ったが、作者が言ってるとおりの、良質なフレームワークだ。Webのリクエストが完了したら動かしてほしいコードのブロックを、渡すだけだ。ブロック構文(前述)のないJavaでは、それはできない。

勝者: ネイティブではAndroid、サードパーティのライブラリも含めるとiOS。


共有

アプリから容易にFacebookやTwitterやEvernoteなどで共有できるか? AndroidにはIntentという強力なアプリ間コミュニケーションシステムが前からあるから、第一ラウンドでAndroidのノックアウト勝ちだ、とぼくは思った。一般的に言っても、複数のアプリ間のデータ共有機能は、Androidの方が優れている。

でも、きわめてふつうの共有機能では、Appleもかなり追いついている。というか、これは読者ご自身が判断していただきたい。ぼくのアプリScanvineの、Androidの共有コードはこれ、iOSのコードはこれだ。iOSのコードがやや長いのは、Google Analyticsでちょっと余計なことをしているためだ。こいつは、直したい。

勝者: 引き分け。


分裂

こいつは、簡単。AndroidはこうiOSはこう。証明終。Googleがおもしろい統一策を実装中だから、この話題は再訪の価値があるかもしれない。

勝者: iOS.


発表

Androidアプリは、世の中に発表することが、うそみたいにやさしい。Eclipseには便利なアプリ登録ウィザードがある。どのデバイスでも動くAPKファイルを、あなたは作った(はず)。それを、メールしてもよい、Webサイトに載せてもよい、Google Playにアップロードしたらたちまち、全世界があなたの市場になる。最高にシンプルだ。インストール時のログデータとクラッシュ報告を見る。スタックトレースを見れば、問題のコードがどこか分かる。すぐにバグフィクスして再びアップロードすればよい。

Appleのアプリは、発表が悪夢だ。頭の良いぼくの友人は、iOSアプリを開発するときは通常のスケジュールに最低でも1日足せ、とアドバイスする。証明とか配布プロファイルと苦戦するための時間だ。何度やっても、それにXCodeの最新バージョンがどんなにそのための努力をしていても、それはつねに、でっかい苦労だ。TestFlightがあるから、ややましだが、アプリのテストも厳しい。そしてAppleの”iTunes Connect”WebサイトとGoogle PlayのDeveloper Console(デベロッパコンソール)は、Ford Pinto vs. Teslaだ。クラッシュレポートがもらえたら、ついてる方。だいたい、ろくな情報は得られない。彼らの、デベロッパに対する恣意的な態度は、こうなったら楽しむしかない。そしてAppleのUXのひどさに、感嘆するのだ。

勝者: 大差でAndroid。


そして優勝は…

僅差でiOSだ。Androidにも良い点はあるが、良いiOSアプリを書くことと、良いAndroidアプリを書くことを比べると、前者の方が相当にやさしい。今でも。それにAndroidユーザはお金持ちで周囲への影響力もあるから、大ウケをねらうスタートアップは、最初にiOS、Androidは後で、で行くのが理にかなっている。Android Studio IDEは、差をやや縮めるかもしれないが、まだ横並びにはならないだろう。

(なお、ぼくの日常のメインの携帯はNexus 4だ。しかも、すごく満足している。)

画像クレジット: Jennifer Stolzer, DeviantArt

〔訳注: この記事はコメントが166もあり(日本時間11月19日18時現在)、参考になるコメントも多いので、この記事をより相対的に読むためにはコメントも読むことをおすすめします(Twitter上の関連ツイートは961件あります)。以下に、今はEclipseじゃなくてIntellij、という正論を書いていると思われるコメントを一つだけ訳出(抄訳)しておきます(GoogleのAndroid StudioはIntellij(の無料版)がベースです)。〕

<コメント訳開始>
ちょいと、こいつは露骨に偏った記事だよ。詳しく書いてる時間がないから、Eclipseが標準IDE説を、ここでは取り上げよう。前からJavaをやってる人なら、Intellijを知ってるだろう(Android Studioはまだバグが多くてだめだけど)。GoogleがEclipseを見捨てたのも、当然だ。Androidデベロッパも、だいぶ前から、すでにIntellijを使ってる人が多い。また、エミュレータはとっくに誰も使っていない。あまりにも、ひどいから。今はほとんどの人が、デバイスそのもの、またはx86エミュレータ、またはGenymotionなどを使っている。今更一体誰がSamsung Realityなんか検討するの?
【後略】— from kpgalligan
<コメント訳終了>

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Mono(C#+.NET)でモバイル開発プラットホームの支配をねらうXamarinが好調に乗ってシリーズB$16Mを獲得

iOSとAndroidとOS XとWindowsのネイティブアプリケーション/アプリを(C#で)クロスプラットホームに開発するためのプラットホームXamarinが今日、シリーズBの資金調達を発表した。金額は1600万ドル、主幹投資会社はLead Edge Capitalだ。シリーズA(1200万ドル)のときの投資家Charles River Ventures、Ignition Partners、それにFloodgateも、このラウンドに参加した。これでXamarinの資金調達総額は2800万ドルになる。

Xamarinは主に、企業によるモバイルアプリの開発の簡易化を狙っている。同社の今日の発表ではデベロッパコミュニティの規模が35万人を超え、有料会員のデベロッパは2万名いる。つまり同社は今、好調である。今年の初めにXamarinは、同社としては初めてのデベロッパカンファレンスを開催し、そのチケットはすぐに売りきれた。また今年は、モバイル用のUIをテストするプラットホームをはじめ、数々の斬新なプロダクトをローンチした。

CEO Nat Friedmanの話では、今回の資金は主にデベロッパプラットホームに投じていく。“とくに、既製品のコンポーネントやアプリを増やし、デベロッパがそれらを再利用してすばらしアプリを短期間で作れるようにしたい”、という。また、上述のTestCloudにも資金を投じたい。年内に営業スタッフを倍増することも、計画中だ。

今日の声明文の中でFriedmanは、“やがてすべてのビジネスプロセスおよび顧客との対話がモバイルデバイス上で行われるようになる”、と言っている。そして、“Xamarinのユニークなアプローチ、すなわち複数のデバイスプラットホームのための完全なネイティブアプリを企業が迅速に提供できる方式は、とてつもなく大きな売上増と市場における強い勢いを招いている。この成功と、時宜を得たシリーズBのラウンドが組み合わさることにより、弊社の将来の爆発的な成長のための基盤が形成される”、のだそうだ。

彼はまた、投資家からの投資案件はいろいろあるけれども、今回のラウンドの目的は“Xamarinをモバイル開発の市場を支配する位置つけることが目的だった”、と言う。彼の主張では、モバイル向けの開発プラットホームの中でいちばん急速に成長しているのがXamarinだそうだ。“今回のラウンドは、その炎の勢いにさらに油を注ぐことになる”、と。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))