Google AMP for Emailでメールの高速表示が可能に、ダイナミックなメディアに変身

AMP
米国時間3月25日、GoogleはAMP for Email正式にスタートさせた。AMP for Emailは現在の固定的なメールをウェブページのようなダイナミックなメディアに進化させることが目的だ。AMPブログによれば、まずGmailがサポートされるがYahoo Mail(ちなみにTechCrunchの親会社の所有)、Outlook 、Mail.ruのようなメジャー・サービスもAMP for Emailをサポートすることになるという。

AMP(Accelerated Mobile Pages)はGoogleが中心となって開発された新しいHTML規格で、モバイルのウェブページの高速表示を実現している。Googleがメールへの導入プロジェクトを発表したのは1年以上前だ。Googleの慎重さを考えても長い準備期間だが、この機能を正しく働かすためには膨大なバックエンド作業が必要だったということだろう。

AMP for Emailが目指すのは現在の固定的なメッセージ・システムを仕事を本当に効率化するツールに変えるところにある。Gmailのプロダクトマネージャ、Aakash Sahney氏はこう述べている。

この10年間で、静的でフラットなコンテンツは対話的なアプリケーションへと進化した。これによってわれわれのウェブ体験は決定的に変わった。しかしメールは相変わらず静的メッセージのままで、時代遅れなシステムになりつつある。メールの本文にリンクが含まれている場合、内容を確認したければそれをクリックしてブラウザに新しいタブを開き、別のウェブサイトにアクセスしなければならない。

AMP for Emailが実現すれば、メールはダイナミックかつ対話的なスペースになる。つまりOutlookに実装されている返信メニューをポップアップさせるRSVPボタンのような機能をメール本文に埋め込むことができる。アンケートに答える、ストアで在庫を確認する、コメントに返信するといった作業がメール・クライアントを離れることなく実行できるわけだ。

このフォーマットは、ホテル予約のBooking.comやスケジュール設定のDoodleを始めFreshworks、Nexxt、OYO、Rooms、Pinterest、redBusなどの有力企業がすでに採用している。こうしたサービスからメールを受け取ることを許可している場合、今後数週間のうちに対話的コンテンツを含むメールが届く可能性が高い。

デベロッパーにとってメールをAMP化するのはさほど難しくない。ウェブサイトでAMP化ページを作った経験があればなおさらだ。 フォーマットには画像カルーセル、フォーム、リストなど多数のAMPマークアップ機能が含まれている。こうしたメールには標準的な HTMLマークアップも含まれているのは重要なポイントだろう。これはなんらかの理由でAMPが作動しなかった場合のバックアップとなる。.

最初の発表以来、GoogleはグーグルはAMP for Emailをサポートするパートナーを多数集めることに成功した。これにはメールの配信および分析プラットフォームのSparkPost、メールのデザインおよびマーケティングツール化のLitmus、Twilio Sendgrid、AmazonのSES、Pinpointのユーザー向けメールとマーケティングツールなどがある。

ただしTechCrunchのDevin Coldeweyを含めて、メールへのAMPの導入に反対する意見も根強い。AMPを利用するには新しいマークアップ言語を習得し、かつサポートするインフラを必要とする。シンプルなページをすばやく構築するために必須の要素ではない。

現行のメールシステムにはさまざまな欠点があるものの、シンプルであるためにあらゆるベンダー、ユーザーの間で確実にメッセージ交換機能を果たす数少ないシステムの1つだ。メールにAMPを持ち込むことに誰もが無条件に賛成していない理由は、このメリットを帳消しにする恐れがあるからだ。しかしマーケティングや広告関係者はAMPメールを使うようにならざるを得ない。必要な作業をスピードアップすることができるなら、デベロッパーたちはメールのシンプルさを守るべきだという理想論にはあまり関心を払わないだろうと思う。

原文へ

(翻訳:滑川海彦@Facebook

GoogleがモバイルUIツールFlutterを刷新、アプリや機能のオンデマンド配信も可能に

米国時間2月26日、バルセロナで開催中のMWC 2019でGoogleはクロスプラットフォームのUIフレームワーク「Flutter」をバージョン1.2にアップデートした。

今回のアップデートでFlutterはAndroid App Bundleをサポートする。これはアプリや機能をオンデマンド配信するためのGoogleの最新テクノロジーだ。Androidアプリを効率的にパッケージできるだけでなく、ダウンロードせずにアプリを利用できるInstant Appも作成できる。

また新しいFlutterフレームワークにはデベロッパーがアプリ内課金によって収入を得ることを助ける仕組みなど多数のウェブベースのツールが用意されている。

昨年のMWCでFlutterのアルファ版が公開された後、Flutter 1.0がリリースされたのはわずか数カ月前だった。それならバージョン1.1はどうしたのだといぶかる読者もいるだろう。実は先月のベータリリースがそれだった。Flutterチームは毎月一度程度の割合で1.xアップデートをリリースする計画だという。

当然のことながらFlutterは今回のアップデートでパフォーマンス、信頼性とも改良されて通常の安定版になっている。また最新のDart 2.2 SDKがデフォルトでバンドルされる(FlutterアプリケーションはDart言語で書かれている)。開発チームはiOSのサポートにも力を入れておりフローティングカーソルでのテキスト編集にも対処しているという。

Flutterはモバイルに重点を置いたプロダクトだが、最近、Googleではこのフレームワークを使ったデスクトップアプリケーション開発の可能性に言及するようになった。準備の一環として、1.2ではキーボードイベントとマウスカーソルを乗せるイベントのサポートが追加された。Project HummingbirdはFlutterをWebに移植するためのプロジェクトだが、今後数カ月以内にテクニカルプレビューとして公開されるという。

開発ツールとして見た場合、GoogleはすでにAndroid StudioでFlutterをサポートしている。またMicrosoftのポピュラーなツール、Visual Studio Code向けのツールを追加している点も注目だ。また新しいWebベースのプログラミングツールであるDart DevToolsも開発中だ。これらのツールはローカルに実行され、ウィジェットインスペクタ、タイムラインビュー、ソースレベルのデバッガ、ロギングビューなどを含む。

現在、これらのツールは公式プレビュー版が公開されており、既存のVS Code、Android Studioの拡張機能やアドインとともにインストールできる。

今回のアップデートのリリースに加えて、FlutterチームはFlutter Createと呼ばれるコンテストを実施することを発表した。参加者はFlutterを使って「面白くてためになりビューティフルな何か」を作ることを求められる。Dartのコードのボリュームは5K以下でなければならない。賞品には1万ドル相当のiMac Proが含まれているが、メモリー128GBというスペックなので5Kのコードの処理に手間取る心配はないだろう。

原文へ

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

Ubisoft、AIバグ発見ツール、Clever-Commitの開発でMozillaと提携

今日(米国時間2/12)、カナダの有力ゲーム・デベロッパー、UbisoftはClever-Commitの開発に関してMozillaと提携したことを発表した。

このツールはAIを利用したスマート・アシスタントで、ユーザーが新しいコードをコミットする際に過去のバグやリグレッションテストのデータからバグの可能性がある部分を発見して警告する。Ubisoftはこのツールをすでに社内で利用している。MozillaはFirefoxをアップデートする際にClever-Commitをバグの発見に役立てるとしている。

Mozillaといえばオープンソースと考える読者も多いだろうが、Clever-Commitはオープンソースではない。Ubisoftの広報担当者は私の取材に対して、「その点が検討されたのは事実だが、今のところClever-Commitがオープンソース化される予定はない」と答えた。 なるほどMozillaは各種の有料ツールを使ってオープンソースソフトウェアを開発している。しかしオープンソースではないツールを開発するのをMozillaが助けるというやや奇異に感じられる(ともあれClever-Commitはまだベータ段階で一般公開はされていない)。

去年、UbisoftはこのツールをCommit-Assistantという名前でデモした。Mozillaは「Ubisoftと協力し、われわれはRust、C++、JavaScriptによるプログラミング、 C++コードの解析、バグ・トラッキングに関するノウハウを提供していく」と述べた。 Mozillaはこのツールをまずコード・レビューの段階で利用し、有効性が確認できれば他の段階にも利用を広げていくといいう。Mozillaではアップデートの配信の前にClever-Commitを利用することで5つのバグのうち3ないし4を発見できるものと期待している。

今日、MozillaにおけるFirefoxのリリース担当マネージャー、Sylvestre Ledruは、 「われわれは6週間から8週間ごとにFirefoxのコードのアップデートを行っている。良好なユーザー体験を確保するためにFirefoxの開発チームはコードを書きテストを行う際にClever-Commitを利用することで公開に先立ってバグのないクリーンな状態を確保することができると期待している。当面まず完成したコードのレビューのプロセスで利用を始めるが、有用であればさらに他のプロセスの自動化にも利用していく」と述べている。

原文へ

滑川海彦@Facebook Google+

Apple、App Storeデベロッパーは2008年以降、1200億ドル稼いだと発表

AppleのEntrepreneur Campがクパチーノで開幕した。 アプリのデベロッパーを創業した11人の女性起業家がAppleとのディスカッションやワークショップ参加のために招待されている。Appleはそのチャンスを利用してApp Storeの売上に関して新しい数字を公表した。

App Storeのスタート以来、AppleはApp Storeのデベロッパーに1200億ドルの売上を分配してきたという。つまり、App Store自身の売上はこれよりもずっと大きいわけだ。1,200億ドルはAppleの取り分を除いて開発者に支払われた額だ。

App Storeは依然として急速に成長中だ。過去12か月間で300億ドルを超える金額がデベロッパーに送金されている。ちなみにAppleが2018年6月のWWDCで発表した ところでは1000億ドルがデベロッパーに支払われたということだった。

Appleの発表に含まれるのはダウンロード、アプリ内課金、サブスクリプションなど直接App Store中で生み出された金額だ。デベロッパーはこれ以外にもサイト内の広告やサイトを通じたサブスクリプションなどでさらに売上を加算することが可能だ。

Entrepreneur Campで、AppleはBites、Camille、CUCO、Lembrete de Medicamentos、Deepr、D’efekt、Hopscotch、LactApp、Pureple、Statues of the La Paz 、Malecón、WeParent、Seneca Connectなどのデベロッパーを招待している。セッションは四半期ごとにに開催される。

画像: TechCrunch

原文へ

滑川海彦@Facebook Google+

Microsoft Edge、Chromiumベースに――旧Windowsでも作動、macOS版も登場へ

噂は事実だった。 Microsoft EdgeはオープンソースのChromiumをベースにしたブラウザに生まれ変わる。 Chromiumはその名が示唆するとおり、GoogleのChromeブラウザを動かしているプラットフォームだ。同時にMicrosoftはEdgのmacOS版を開発している。MicrosoftはEdgeをWindowsから切り離し、これまでより頻繁にアップデートを行っていくという。新しいEdgeはWindows 7、8でも作動する。

Windowsのデフォールト・ブラウザの変更にはある程度時間がかかる見込みだ。現在まだベータ版は出ていないし、一般向けプレビュー版が公開されるのは数ヶ月先になるだろう。しかし2019年中にMicrosoftの独自のレンダリング・エンジン、EdgeHTMLとChakraはBlinkV8に切り替えられる。デベロッパー向けベータ版は来年早々に発表されるものとみられる。

当然ながら細部はまだ不明だ。しかしMicrosoftがChromeとChromiumがユーザー、デベロッパー双方にとって現在のブラウザのデファクト標準だと認めたことははっきりしている。

数年前、Microsofは問題を数多く抱えたInternet Explorerを捨ててEdgeに切り替えた。Edgeの機能はモダン・ブラウザとして十分使えるものに仕上がっていたがMicrosoftも認めるとおり、互換性の問題は解決していなかった。あるサイトでEdgeの作動に問題があることは発見されるとMicrosoftはリバースエンジニアリングで問題の所在を突き止めねばならなかった。Microsoftはこうした努力に膨大なリソースを割り当てる意味がないと見きったようだ。

microsoft edge on surface

こうした互換性問題が起きる原因としてはEgdeの市場シェアが低いままだったことが大きい。サイトのデベロッパーはChrome、Firefox、Safariといった主要なブラウザについては十分にコードの作動をテストするが、下位のブラウザでのテストはおざなりになりがちだ。ウェブサイトの総数を考えれば、互換性問題を起こすサイトの数も膨大なものになるのは理解できる。

さらにものごとを複雑にしてきたのは、サイトを開発するデベロッパーの多くがMacを使っているため、Edgeが作動しないという点だ。これがますます互換性問題を悪化させた。Internet Explorer for Macを中止してから15年後にEdgeをMacに移植しても意味があるほどのシェアは獲得できないだろう。しかしMicrosoftはEdgeがMacでも動くようになればデベロッパーがEdgeでの作動を確認しやすくなるだろうと考えている。

またEdgeがWindows 10でしか作動しないのも不利な要素だったとMicrosofは認めている。EdgeはWindows 10にバンドルされており、アップデートはWindowsのアップデートの一部として行われてきた。Windowsの古いバージョンを使っている何千万ものユーザーはEdgeから取り残されていた。またWindows 10のユーザーも常に最新の状態にアップデートしているとは限らない。するとEdgeのアップデートも行われていないことになる。

善悪は別として、Chromeはブラウザの事実上の標準の地位を確立している。Microsoftはこのトレンドに逆らわないことにした。もちろんMicrosoftは逆の道、つまりEdgeHTMLとJavaScriptエンジンをオープンソースにする(一部はすでにそうなっている)こともできた。このオプションも検討されたようだが、結局のところ、実行されないことになった。Microsoftによれば、EdgeはWndows 10とあまりに密接に連携しているためオープンソース化してWindows 7やMacで作動させることは困難であり、メリットも少ないと判断されたという。Edgeのオープンソース化などは無駄足に終わった可能性が高い。これは正しい決断だったと思う。

逆にEdgeをChromiumベースにすることはオープンソース・コミュニティーにおけるMicrosoftの存在感を高めるはずだ。たとえば、Edgeの大きな強みである優れたタッチスクリーン・テクノロジーがChromiumコミュニティーに輸入される可能性も出てくる。9to5Macも報じているようにMicrosoftはGoogle、Qualcommと協力して ChromeブラウザをARMデバイス上のWindows 10でネイティブに動かすための努力を始めている。現在はエミューションを多用しているため電力消費量が大きく、作動も十分速くできていない。

MicrosoftではEdgeの互換性不足問題を過去のものにできれば、ユーザーは自ずとEdgeの機能に引き寄せられると期待している。 Windows OS、Office、Cortanaなどのプロダクトに対する親和性を高くできるし、今後は新しいサービスや機能が追加されることもあり得る。たとえば大企業内での使用に際してIT管理部門の負担を軽減するようなツールなどだ。

数日前にEdgeがリニューアルされるといいう情報が流れたとき、一部の専門家はChromiumプロジェクトが力を持ちすぎることになるという懸念を示した。

この懸念には理由があることは認めるものの、MicrosoftはどのみちEdgeのシェアは低いのでChromium化がオープンソース・コミュニティーにドラスティックな影響を与えることはないという説得力のある反論をしている。MicrosoftがChromiumコミュニティーに参加してウェブの標準化を推進する側に回り、Chromiumにイノベーションを吹き込むことになればメリットは大きいだろう。

読者の多くが現在頻繁に作動させているソフトウェアの中で、ウェブ・ブラウザはサイズ、複雑性でトップクラスのアプリケーションの一つだ。Windows 10のデフォールト・ブラウザの心臓部であるレンダリング・エンジンを一新するというのは大事件だ。Microsoftはまだ詳細を発表していないものの、同社は新しいバージョンに残すべきEdgeのテクノロジーはどれかを検討しており、そうした機能はChromiumコミュニティーに還元されることになるという。

MicrosoftはEdgeを見捨てるわけではないと強調している。Edgeが消えるわけではない。現在Edgeを利用しているユーザーは使用感がさらに快適になったと感じるだろう。まだ使っていないならChromiumベースの新しいEdgeを試してみることをMicrosoftは期待している。Microsofのこれまでの独自路線とまったく異なるオープンソースの新しいブラウザだとなれば使ってみようと考えるユーザーも多いだろう。

画像: Bryce Durbin

原文へ

滑川海彦@Facebook Google+

コードの各所に関するデベロッパー同士の議論をコメントのように残せるCodeStream、最初はVS Codeをサポート

コードにコメントを入れることは、昔から誰もがやっているが、でも、コードの特定部分に関する同僚などとの会話スレッドを残せるとしたらどうだろう。Y Combinator出身のCodeStreamを使うと、まさにそれができる。

コンテンツに関する議論は、そのコンテンツの直後にある方がよい。Google Docsのアノテーション(注釈)やPowerPointのコメント、Wordのリビジョン(変更履歴)などは、だからとても便利だ。何もかもSlackの上で議論するのは、やめた方がいい。

しかしそれでも、二人のデベロッパーのコラボレーションは、Slackの上のプライベートな会話で始まることが多い。CodeStreamはgit commitやコード中に書くコメントに代わるものではなく、コードの上に便利な会話の層を加える。

誰かと関わりたくなったら、まずテキストをセレクトして議論を開始する。そして、当のコーディングブロックを最初のポストとするスレッドが作られていく。CodeStreamを今使ってるSlackにリンクしたら、Slackのチャネルの中でスレッドが始まる。誰かを@-mentionしたり、数行のコードをコピペしたりもできる。

mentionされたデベロッパーは、そのスレッドをクリックすると、CodeStreamはそのファイルをその行があるところで開く。二人のデベロッパーが同じブランチ上にいなくても、どちらもコードの同じ行を見る。どっちかに新しいコードがあっても。

数か月後にコードベースが進化していても、会話スレッドは残っている。いつでも、過去の会話を見て、なぜそこがそうなったのか、理解できる。

今は、CodeStreamはVS Code(Visual Studio Code)をサポートしている。CodeStreamをインストールしたら、IDEを縦2画面に分割して、左にコード、右にCodeStreamの会話スレッド、という状態にするとよい。

今後は、もっと多くのIDEをサポートしていく予定だ。Visual StudioやJetBrainsエディター、そしてAtomなども。今CodeStreamはベータなので無料だ。

同社は最近、S28 Capitalが率いるラウンドで320万ドルを調達した。それにはPJCが参加した。そのほかに、Y Combinator, Steve Sordello, Mark Stein, David Carlickなども投資に加わった。

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

分散ストレージCephが独自のオープンソースファウンデーションを設立しLinux Foundationに参加

まだあまり有名ではないオープンソースの分散ストレージCephは、実際にはすでに全世界的に、大規模なコンテナプロジェクトやOpenStackのプロジェクトで利用されている。ユーザーはたとえば、金融のBloombergやFidelity, クラウドサービスプロバイダーのRackspaceやLinode, 通信大手のDeutsche Telekom, 自動車のBMW, ソフトウェアのSAPやSalesforceなどだ。

今日のオープンソースプロジェクトは、その多様な関心を一手に引き受けて処理し管理する管理組織、ファウンデーションが背後にないと、成功を維持し今後の発展を築くことも難しい。そこで当然ながらCephも、自分専用のファウンデーションCeph Foundationを作った。そしてこれまでのオープンソースプロジェクトのファウンデーションの多くに倣い、それをLinux Foundationの下に置いた。

Cephの共作者で、プロジェクトリーダー、そしてRed Hat for CephのチーフアーキテクトでもあるSage Weilはこう述べる: “パブリッククラウドの初期のプロバイダーたちがセルフサービス型のストレージインフラストラクチャを流行(はや)らせ、そしてCephはそれを一般企業や個人、そしていろんなサービスブロバイダーたちに提供している。今では強力で堅固なデベロッパーコミュニティとユーザーコミュニティが育ち、ストレージの分野における未来のイノベーションを推進している。本日のCeph Foundationの立ち上げは、さまざまなオープンソースのコミュニティが協力し合えばデータストレージとデータサービスの爆発的な成長を強力に支えていけることの、証(あかし)になるだろう”。

Cephはすでに多方面で使われているから、ファウンデーションの創設メンバーもすごい顔ぶれだ: Amihan Global, Canonical, CERN, China Mobile, Digital Ocean, Intel, ProphetStor Data Service, OVH Hosting Red Hat, SoftIron, SUSE, Western Digital, XSKY Data Technology, そしてZTEなど。創設メンバーの多くがすでに、非公式団体Ceph Community Advisory Board(顧問団)のメンバーだ。

Linux Foundationの事務局長Jim Zemlinはこう言う: “企業の高い成長率の維持管理を効果的に助け、彼らのデータストレージの需要を拡大してきたことに関して、Cephには長年の成功の実績がある。Linux Foundationの下でCeph Foundationは、より幅広いグループからの投資を活用して、Cephのエコシステムの成功と安定の継続に必要なインフラストラクチャをサポートできるだろう”。

cepha and linux foundation logo

Cephは、OpenStackとコンテナをベースとするプラットホームを構築するベンダーにとって重要なビルディングブロックだ。実はOpenStackのユーザーの2/3がCephをメインで使っており、またCephはRookの中核的な部分でもある。Cloud Native Computing Foundation(CNCF)傘下のRookは、Kubernetesベースのアプリケーションのためのストレージサービスを、より容易に構築できるためのプロジェクトだ。このように、今や多様な世界に対応しているCephだから、ニュートラルな管理機関としてのファウンデーションを持つことは理にかなっている。でも、ぼくの山勘では、OpenStack Foundationもこのプロジェクトをホストしたかったのではないかな。

今日(米国時間11/12)のこの発表のわずか数日前にLinux Foundationは、FacebookのGraphQLのファウンデーションGraphQL Foundationをホストすることを発表した

[↓Facebookのクエリ言語GraphQLが独自のオープンソースファウンデーションを設立(未訳)]

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

Microsoftの$7.5BのGitHub買収計画にEUの規制当局が青信号を点灯

Microsoftが計画していた、Gitを利用するコード共有コラボレーションサービスGitHubの買収を、欧州連合(European Union, EU)の規制当局が無条件で承認した。

この巨大ソフトウェア企業がGitHubの買収意思を発表したのは6月で、同社の株式で75億ドルを支払う、とされた。そして当時同社は、“GitHubはそのデベロッパーファーストの精神を維持し、独立した事業活動により、すべての業界のすべてのデベロッパーにオープンなプラットホームを提供する”、と誓った。

EUの執行機関欧州委員会(European Commission, EC)が今日、その計画を承認し、その査定が、関連市場における競争を阻害しないと結論した、と述べた。この併合後の企業実体の方がむしろ、継続的に“厳しい競争”に直面するであろう、と。

ECはとくに、Microsoftには自社のdevopsツールやクラウドサービスをGitHubに統合してサードパーティのツールやサービスの統合を制限する能力や誘因はない、と言っている。

委員会は、MicrosoftにはGitHubのオープン性を損なう動機はない、とも結論している。そして、そのようないかなる試みもデベロッパーにとっての価値を減損させるだろう、とも言っている。委員会の判断では、そのようなときデベロッパーは他のプラットホームに切り替える意思と能力を持っているだろう、という。

Microsoftの前の発言では、同社は買収の完了を年内と予想している。

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

Google、Android App Bundleをアップデート――Instant App同時公開がサポートされた

Googleは今日(米国時間10/18)、Androidアプリのデベロッパー向けに重要なアップデートを発表した。 ひとつはアプリのサイズを減少させるもので、もう一つはInstant Appを簡単につくれるようにするものだ。Instant Appはデバイスにインストールせずに動かすことができる軽量なアプリで、ユーザーが簡単に試してみることができるためメリットが大きい。

Android App Bundleはアプリをモジュラー化して開発し、各デバイスに必要なイメージを配信する方法でしばらく前から公開されている。Googleによれば、App Bundleを利用して開発されたアプリは数千にも上り、ファイルのサイズは平均35%も節約できたという。今日のアップデートで、GoogleはApp Bundleがデバイス上にすでにインストールされている非圧縮のネーティブ・ライブラリを利用する方法に改良を加えた。.これによりインストールする際のダウンロードのトラフィックは平均8%減少し、デバイス上で占めるサイズも16%小さくなるという。

サイズについていえば、現在App Bundleから生成されたAPKの最大ファイルサイズは100MBだが、Googleによれば近くデベロッパーが500MBまでのAPKをアップできるようにするという。

またApp Bundleは新たにAndroid Studio 3.2(安定版)とUnity 2018.3 ベータでもサポートされた。

ダウンロード失敗の大きな原因がデバイスに空き容量が不足していることなのでファイルサイズが小さくなるのはアプリの公開にメリットがある。ただGoogleが今回公開したもう一つのアップデートのほうがデベロッパー、ユーザー双方に影響が大きいかもしれない。GoogleのInstant Appはデベロッパーが小さいアプリを公開できる機能だ。これはアプリのトライアル版や、ユーザーがアプリをウェブ検索で見つけ、すぐに試してみたい場合などに効果的だ。Instant Appはフルサイズのアプリをダウンロードしてインストールするという面倒な(往々にして時間がかかる)プロセスを必要としない。

GoogleはデベロッパーがApp BundleでInstant Appを開発できるようにした。つまりデベロッパーはフルサイズのアプリとInstant Appの双方を開発、公開する必要がなくなった。その代わりに、App Bundleでアプリを開発し、Instant Appを含めるオプションを選択して単一のアプリとしてGoogle Playで公開すればよい。アプリをアップデートする際もいちいち2つのアプリをメンテナンスする必要がなくなった。

デベロッパーはInstant Appを使ってゲームなどの有料タイトルを開発した際、その一部をInstant Appにして登録前のユーザーにトライアルを許すというキャンペーンが実行できるようになった。

Androidデベロッパー向けの他のアップデートにはクラッシュ・レポートの改良が含まれる。これは実際にアプリを利用しているユーザーからのクラッシュ情報ととFirebaseテストラボからの結果が総合して報告される。またアプリのサブスクリプション課金の手続きなどもアップデートされた。詳細はこちらから確認できる。

原文へ

滑川海彦@Facebook Google+

GitHubからワークフロー自動化ツール、Actions登場――独自サービス提供の第一弾

最近Microsoft傘下に入ったGitHubは長らくオープンソースのコード共有と保管のためのサービスと考えられてきた。今日(米国時間10/16)、同社はGitHub Actionsを発表し、独自のサービスを開発、提供する路線の第一歩を踏み出した。 デベロッパーはActionsを利用することで、単にこのプラットフォームにコードを保存したり同僚と共有したりするだけでなく、実行することが可能になる。

これはAWSのライバルとなるようなクラウドというより、IFTTTに近いがもっとフレキシブルなサービスだ。Actionsはワークフローそのものを自動化して効率化を図りたいデベロッパーのニーズに応えるものだ。

これはGitHubの事業にとって重要な転換点だ。事実、GitHubのプラットフォーム責任者、Sam Lambertは私の取材に対して「GitHubの歴史上最大のシフトだ」と答えた。LambertはこのサービスをiOSのショートカットに例えた。ただしはるかに多機能で強力だという。「ショートカット・アプリと似ているが比べものにならないくらいフレキシブルなサービスがGitHubにホスティングされ、誰でもこのコンテナの中で自由にパーツを組み合わせて効率的な独自のワークフローが作成できるところを想像して欲しい」とLambertは述べた。

GitHubのユーザーはActionsを使って 継続的デリバリー・システムを構築できる。GitHubでは多くのユーザーがActionsによるパイプラインを作るだろうと期待している。実際ユーザーもこのプロジェクトについて聞いたときそう思ったに違いない。今日のGitHubの発表によれば、Actionsは「ソフトウェアのビルド、パッケージ、リリース、デプロイ、アップデートという一連の流れを大きく効率化する。またどんなプログラミング言語にも対応する。GitHub上で開発された場合でもと外部のシステムの場合でも、コードを自分では実行する必要はない」という。しかしこれはほんの手始めに過ぎない。Lambertはこう強調している。

継続的インテグレーションと継続的デリバリー(CI/CD)はActionsのユースケースのほんの一部だ。たしかにその面で役立つが、Actionsはそれ以上のものだ。これはDevOps全体に革命を起こすものだとと思う。なぜならActionsを用いることでこの種のものとして最高のアプリケーション、フレームワークのデプロイメントのサイクルを構築できるからだ。ActionsはGitHubでプロジェクトを共有する場合のデファクト・スタンダードになるだろう[…]オープンソースで実行していたすべてができる。DevOps方式の開発ワークフロー・エコシステムのすべての部分に適用できる。

つまり、誰かがリポジトリで「緊急」というタグを使った場合、Twilioを使ってメッセージを送信するという仕組みを作ることができる。レポジトリを検索する一行のコードを書いてgrepコマンドで実行することもできる。その他どんなコードでもいい。レポジトリ内のコードをActionに変換するためにはそのためのDockerfileを書いてGitHubで実行できるようにしさえすればいいからだ。 Lambertによれば「Dockerファイルさえあれば、Actionsでビルドし、実行し、ワークフローに組み込むことができる」という。Dockerfileを使いたくない場合はワークフローをビルドするためのビジュアル・エディタも用意される。

GitHubのプロダクト・エンジニアリングの責任者、Corey Wilkersonによれば、Actionsはすでに多くのGitHubレポジトリで利用されているという。 Actionsは現在はまだベータ版で限定的公開だが、GitHubには9600万のプロジェクトがあるのですぐにたいへんな数のActionsが生まれるだろう。【略】

将来は(Lambertはそうなることを期待しているが)多くのGitHubユーザーがActionsで作成したワークフローをGitHubのマーケットプレイスで販売することになるかもしれない。現在はまだ可能ではないものの、GitHubはこのオプションの可能性を真剣に検討している。Lambertは「エンタープライズ向けツールを開発、販売する(これはSales Forceがやっている)予定がないデベロッパーもActionsによるワークフローの販売でマネタイズができるようになるはずだ」と考えている。

GitHubはデベロッパーに対してActionsを順次公開していく予定だ。デベロッパーはこちらからActionsに登録できる。【略】

GitHubではまたLearning LabでデベロッパーがGitHubを学習するのを助けるための新しいコースを3種類リリースした。また大規模な企業向けのプライベートなLearning Labも用意されている。

GitHub Enterpriseのユーザーにとってもっとも興味深いのは、管理者が個々のプログラマーの公開プロフィールに開発したプロジェクトを表示できるようになったことかもしれない。デベロッパーのコミュニティーではGitHubが事実上、履歴書として機能していることを考えると、このオプションが与える影響は大きい。

その他の発表はセキュリティーの強化に関するものが中心だった。たとえばGitHub Security Advisory APIはコードをスキャンしデベロッパーが脆弱性を発見することを容易にする。またJavaと .NETのプロジェクトには新たな脆弱性のアラート機能も追加された。 【略】

原文へ

滑川海彦@Facebook Google+

Google CloudがCloud NAT、Firewall Rules Loggingなどネットワーキング機能を充実

今日(米国時間10/10)は、ロンドンでNextイベントを開催しているGoogle Cloudからのニュースで、忙しい日だった。このイベントで同社は、いくつかの新しいネットワーキング機能をローンチした。それらの中でも今日の主役はCloud NAT、これによりデベロッパーは、一般的に公開されるIPアドレスがなくて、企業の仮想プライベートクラウドの中にあるアプリケーションからのみアクセスできる、クラウドベースのサービスを容易に構築できる。

Googleも言うように、このようなセットアップは前から可能だったが、しかし容易ではなかった。でも、よくあるユースケースなのでGoogleは、Cloud NATにより、ネットワークアドレス翻訳(network address translation, NAT)のすべてを取り扱う完全に管理されたサービスを提供することになった。そしてCloud NATのゲートウェイの背後にあるプライベートなインスタンスへのアクセスを、デベロッパーに提供する。

Cloud NATはGoogle Compute Engineの仮想マシンと、Google Kubernetes Engineのコンテナをサポートし、デベロッパーが手作業でIPを指定できるマニュアルモードと、IPが自動的に割り当てられるオートマチックモードの両方を提供する。

今日は新たに、Firewall Rules Loggingがベータでリリースされた。アドミンはこの機能を利用してファイヤーウォールのルールの効果を監査し確認できる。たとえば、ファイヤーウォールがブロックする接続の試みが何度も繰り返されるときには、それらを分析して、誰かが良からぬことをしようとしているのか、それともファイヤーウォールの構成ミスかを判断できる。データの遅れは5秒程度なので、ほとんどリアルタイムに近い点検が可能だ。また、これをほかのサービス、Stackdriver Logging, Cloud Pub/Sub, BigQueryなどと統合してアラートやデータ分析もできる。

さらに今日の発表の中には、HTTPSロードバランサー用に証明を提供するマネージドTLSがある。これは、ロードバランサーを使っているときのTLS証明の管理に伴う煩雑さを解消することが目的で、これによりエンドユーザーのブラウザーがデベロッパーのアプリケーションに安全に接続できるようになる。この機能も、現在はベータだ。

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

GitHubがJira Software Cloudの統合を改良、パフォーマンスとユーザー体験をアップ

AtlassianのJiraは、多くの企業で、大きなソフトウェアプロジェクトを管理するためのスタンダードになっている。しかしそれらの企業の多くがソースコードのリポジトリとしてはGitHubを利用しており、JiraとGitHubを統合する公式な方法も、かなり前からある。しかしその古いやり方は、遅くて、能力も限られ、今多くの企業がGitHubで管理しているような大きなコードベースを扱うには、向いていないことが多かった。

しかしMicrosoftに買収されたあとでもGitHubは、オープンソースのエコシステムにコミットしていることを証明するかのように、今日(米国時間10/4)同社は、二つの製品の改良された統合を発表した。

GitHubのエコシステムエンジニアリング担当ディレクターKyle Daigleは、こう語る: “Jiraに関してAtlassianと協働することは、われわれにとってきわめて重要だった。われわれの顧客であるデベロッパーには、彼らが使っているこのオープンなプラットホーム〔GitHub〕から最良の体験を確実に得てほしいからだ。彼らが今、ほかにどんなツールを使っていようともね”。

そこで二か月前にGitHubのチームは、Jiraとの独自の統合を、完全にゼロから再構築することに決めた。そして今後は、それをメンテナンスし改良していくことにした。Daigleが言ってるように、改良の重点はパフォーマンスとユーザー体験の向上に置かれた。

この新しい統合により、JiraのIssue(課題)に結びついているすべてのプルリクエストやコミット、ブランチなどをGitHubから容易に見ることができる。GitHubからの情報に基づいてIssuesを検索できる。そしてまた、開発ワークのステータスをJiraの中でも見ることができる。GitHubで行った変更がJiraのアップデートもトリガーするので、そのデータはどんなときでもアップツーデートに保たれる。

いわゆるJira DVCSコネクターを利用するJiraとの古い統合は非推奨になり、GitHubは、数週間以内にアップグレードするよう、既存のユーザーへの告知を開始する。新しい統合はGitHubのアプリケーションなので、このプラットホームのセキュリティ機能をすべて装備している。

画像クレジット: TechCrunch

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

Node.jsとJSが合併の意向を共同発表――JavaScriptコミュニティーの統合を図る

現在、JavaScriptの有力なオープンソース団体は2つある。2016年設立のJS Foundationと2015年設立のNode.js Foundationだ。JS Foundationの目的はJavaScriptを中心とするエコシステム全般の育成にあるのに対して、Node.jsは名称からも明らかなようにNode.jsテクノロジーを中心としてGoogleのV8エンジンなどの助けを借りながらサーバーサイドでJavaScript言語を活用していこうとするものだ。この2つの団体は合併を検討していることを明らかにした

合併はまだ確定したわけではなく、両組織はそれぞれのコミュニティーからのフィードバックを得ようとしている。まずはNode+JS Interactiveカンファレンスで直接に、またオンラインでもQ&Aセッションを設けて、多くの質問に答えていく計画だという。今日(米国時間10/4)の共同声明には次のように述べられている。

合併は両組織の技術的独立性や自治に変更を与えるものではない。Node.jsやAppium、ESLint、jQueryを始めとするJS Foundationの28のプロジェクトはすべてこれまでどおり運営される。JavaScriptは柔軟なプログラミング言語であり、ウェブのバックボーンという当初の役割をはるかに超えて発展している。新しい分野にはIoT、各種ネイティブ・アプリ、DevOps、各種プロトコルなどがある。JavaScriptのエコシステムはブラウザからサーバーへ、デスクトップから組み込みデバイスへと現在も拡大中だ。こうした中でエコシステムの健全な発展を助けるためにメンバーが共同作業する重要性はさらに高まっている。

エコシステム全体を通じて共同作業の重要性が増していることがこの合併のそもそもの動機だろう。Linux Foundationの戦略的プログラム担当バイスプレジデント、Mike Dolanは声明で 「JavaScript 団体のリーダー、重要な知的財産を保有する企業など、コミュニティーがさらに緊密に活動していくくとが団体の活動分野を広げると同時にNode.jsと各種のJavaScriptプロジェクトを一層助けることになると革新している」と述べている。

合併の最終目標は「運営の優秀性をさら強化することによってJavaScriptエコシステム全体の協調性を増し、あらゆるJavaScriptプロジェクトの本拠となれるような単一組織を立ち上げる」ことだという。

コミュニティーの賛成が得られるのであれば、両組織がLinux Foundationの傘下にあることは合併を推進し組織の統合を図る上でなにかと有利だろう。両方の組織に加盟しているメンバーもいるが、その数は予想より少ない。たとえばIBMは両組織のプラチナ会員だが、,GoogleはNode.JSのプラチナ会員でJS Foundation.のスポンサーにはなっていない。逆にSamsungはJS Foundationのトップレベル・スポンサーだがNode.JS Foundationsのリストには載っていない。そういうわけで統合の目的のひとつが「メンバーのコミュニティーへの参加を合理化する」ことにあるのは驚くに当たらない。

画像:imArbaev / Getty Images

原文へ

滑川海彦@Facebook Google+

GoogleのCloud Memorystore for Redisが一般公開、ミリ秒以下のレスポンスを約束

Googleは今日(米国時間9/19)、5か月の公開ベータを経たCloud Memorystore for Redisを一般公開した。それは、完全な管理を伴うインメモリのデータストアだ。

このサービスはRedisプロトコルに完全に準拠していて、インメモリのキャッシングを必要とするアプリケーションにミリ秒以下のレスポンスを約束する。そしてRedis準拠なので、デベロッパーは自分のアプリケーションをコードをどこも変えずにこのサービスへマイグレートできる。

Cloud Memorystoreには二つのサービスティアがある。シンプルなキャッシング用のベーシックと、高可用性のRedisインスタンスを必要とするユーザーのためのスタンダードだ。スタンダードではGoogleは、99.9%可用性のSLAを提供している。

最初にベータでローンチして以来Googleは、このサービスにできることを徐々に増やしてきた。たとえば今ではさまざまな性能数値をStackdriverで見ることができる。また、カスタムのIAMロールや、改良されたログ機能も加わった。

課金は時間と容量の従量制で、サービスのレベルや使用するキャパシティによって異なる。完全な料金表がここにある。

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

GoogleのGitHub競合製品Cloud Source Repositoriesが検索機能を大きく改良

Googleが今日(米国時間9/19)、最近再び立ち上げたGitベースのソースコードリポジトリ Cloud Source Repositoriesのアップデートを発表し、とくに検索機能が大幅に改良された。この新しい検索機能はGoogleの技術者たちが毎日使っているツールをベースとし、今日からCloud Source Repositoriesのベータリリースで提供される。

かなり前からインターネットを使っている人なら、Google Code Searchをご存知だろう。これを使ってインターネット上のオープンソースのコードなら何でも検索できたが、残念ながら2012年に閉鎖された。今度の新しい機能はそれの復活ではなくて、自分の(もしくは会社の同僚の)コードしか検索できない。でもそれはGoogle自身の検索に劣らず高速で、正規表現などの高度な検索機能もある。

またJava, JavaScript, Go, C++, Python, TypeScript, Protoで書かれたコードに対しては、検索で見つかったものがクラスか、メソッドか、列挙型か、フィールドか、というタイプ情報も返す。

Googleは、コードの検索をローカルにやるのは、古いコードも検索されてしまうので良くない、と主張している。

さらにGoogleによると、GitHubや(Atlassianの)BitbucketにあるコードをCloud Source Repositoriesにミラーできる。検索だけのために、そんなことをするデベロッパーがたくさんいるとは思えないが、でもGoogleにとってはユーザー獲得の手段になるだろう。この世界はGitHubの独壇場だから、何もしなければ単なる負け犬になってしまう。

Cloud Source RepositoriesのプロダクトマネージャーRussell Wolfが、今日の発表声明で書いている: “重要な利点は、ユーザーのすべてのリポジトリをCloud Source Repositoriesにミラーないし加えておくと、一回のクエリーでそれらすべてを検索できることだ。それは、小さなウィークエンドプロジェクトでもよいし、Googleのような巨大なコードベースでもよい。しかもそれは速い。一瞬で答が得られ、前の検索機能に比べると大違いだ。そのため、検索でコーディングが中断しない。インデクシングも、超速い。新しいコードを加えたらすぐにそれが検索対象になり、つねに最新の検索ができる”。

画像クレジット: TechCrunch

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

Microsoft、ドラグ&ドロップでAIアプリを作るLobeを買収――Azure ML Studioの強化へ

今日(米国時間9/13)、MicrosoftはAIスタートアップのLobeを買収したことを発表した。 Lobeは簡単なドラグ&ドロップによって高度な機械学習モデルが制作できるシステムだ。今年に入ってベータ版がリリースされたLobeをMicrosoftは独自のAIモデル開発に利用する計画だ。ただし当面、Lobeは従来どおりの運営を続ける。Lobeチームは次のように述べている

Microsoftの一員となったことで、Lobeは世界でもトップクラスのAI研究の成果とインフラを活用できるようになった。またMicrosoftは数十年にわたってデベロッパー・ツールを開発してきた。われわれは今後ともオープンソースの標準に従い、Lobeをスタンドアロンでマルチプラットフォームのサービスとして発展させていく計画だ。

Lobeの共同ファウンダー、Mike Matasこれまで携わった開発にはiPhoneとiPad、FacebookのPaperとInstant Articlesなどのプロダクトがある。共同ファウンダーにはAdam Menges、Markus Beissingerが加わっている。

MicrosofはLobeに先立っては深層強化学習(deep reinforcement learning)のプラットフォーム、Bonsai.aiと会話形AIのプラットフォーム、Semantic Machinesを買収している。また昨年、2012年のTechCrunch Disrupt BattlefieldでデビューしたMaluubaを買収したことも記憶に新しい。機械学習のエクスパートをスカウトするのが非常に難しいことはよく知られている。そこで有力テクノロジー企業は人材とテクノロジーの獲得を念頭に置いてスタートアップの買収に全力を挙げている。Microsoftのエグゼクティブ・バイスプレジデント、CTOのKevin Scottは今日の声明に次のように書いている。

いろいろな意味でわれわれはAIがもたらす可能性の入り口に立っているに過ぎない。経験を積んだデータサイエンティストやデベロッパーにとってさえ機械学習モデルやAIソフトウェアの開発は時間がかかるタスクだ。多くの人々がAIへのアクセスに高いハードルを感じている。われわれはこれを変えていこうと決意している。

重要なのはLobeのアプローチがMicrosoftの既存Azure ML Studioプラットフォームと親和性が高いことだ。このプラットフォームは機械学習モデルの生成にあたってドラグ&ドロップによる直感的なインターフェイスをすでに提供している。ただし実用本位のデザインであり、Lobeチームのシステムのインターフェイスのほうが洗練されている。

LobeとAzure ML Studioはどちらも機械学習の普及を狙っており、TensorFlow、Keras、PyTorchなどの詳細な知識なしに誰でも機械学習を利用してアプリが開発できるようにするのが目標だ。もちろんこうしたアプローチにはそれなりの限界があるのは事実だが、「大量のコードを書かずにすむ」各種ツールは多くのユースケースで有用であり、十分に役割を果たすことが示されている。

原文へ

滑川海彦@Facebook Google+

Anaxiはソフトウェア開発の工程を見える化する…GitHubの巧みな利用で

Anaxiのミッションは、ソフトウェア開発の工程にもっと透明性をもたらすことだ。そのツールは、今はiOSのみで近くWebとAndroidバージョンも出す予定だが、デベロッパーにGitHubからプロジェクトの現状に関する知見とそれらに対する対策を示唆し、プロジェクトとイッシュー(問題)を管理できるようにする。近く、AtlassianのJira もサポートする。

ファウンダーは、Appleで技術部門のマネージャー、そしてDockerで製品開発担当EVPだったMarc Verstaenと、CodinGameのCEOだったJohn Lafleurだ。当然ながらAnaxiのツールは、二人がデベロッパーとして過ごした日々に見たり体験したりした問題の解決を志向している。

Verstaenは語る: “ソフトウェアを40年やってるが、問題はいつも同じだ。小さなチームでプロジェクトをスタートする。そこまでは良い。しかしそれが大きくなると、何がどうなってるのか分からなくなる。まるでブラックボックスだ”。

今は、多くの企業がデータと分析に力を入れようとしているが、ソフトウェア開発はそこまで行ってない。Verstaenによると、10年か15年前なら、ソフトウェアはソフトウェア企業が作るものだったから、それでも良かったが、今ではすべての企業がソフトウェア企業になりつつある。だから、古いやり方はもう通用しない。

Anaxiを使うと、すべてのイッシューレポートとプルリクエストをGitHubの…パブリック/プライベート両様の…リポジトリから見ることができる。また、視覚的なステータスインジケーターにより、プロジェクトにブロッカーが多すぎることなどが分かり、独自のラベルを定義することもできる。イッシューの期限を定義することもできる。

Anaxiのおもしろいところは、情報を手元ローカルにも会社のサーバーにも置かずに、すべての情報をGitHubから取り出すことだ。ただし自分のハンドルなど必要な少量の情報をキャッシュすることはある。スマートフォンなどの上のキャッシュは暗号化されるが、でもほとんどの場合、AnaxiはGitHubのAPIを使って必要な情報を取り出す。スピードに関しては、Verstaenによると、GitHubのAPIは十分に速いし使いやすい。しかもGitHubからなら、つねに最新のデータが得られる。

このサービスは、現在無料だ。将来は、顧客企業の中でAnaxiを使っているデベロッパーの頭数で課金したい、と考えている。

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

Hasuraがサーバーレスの開発を単純化するオープンソースのイベントシステムを発表

主にPostgresデータベースまわりのデベロッパーツールを作っているHasuraが今日、新しいプロダクトを公開アルファで披露した。それは、プログラマーがサーバーレスのアプリケーションを迅速かつ効率的に作れるためのツールだ。

それは、Postgres上のオープンソースのイベントシステムにより、ファンクションをより簡単に書けるようにする。そのイベントシステムは、データベースが特定の条件に達したらイベントをトリガする。それにより、何かを動かすために大量のコードを書く必要がなくなり、またシステムのスケーラビリティも増す。

プログラマーは通常、一連のAPIコールをつなぎ合わせてサービスを呼び出し、決済や通信ゲートウェイなど、アプリケーションの各部を動かしていく。これによりプログラマーは、さまざまな部分をスクラッチで書くことから免れる。しかし問題は、一連の呼び出しの途中で何かがおかしくなったら、システムはダウンし、再スタートすることになりがちだ。

しかしサーバーレスのアーキテクチャでは、サーバーレスのメリットとしてよく挙げられるように、インフラのことをプログラマー側が気にする必要がなくなるので全体のプロセスがもっと簡単になり、きわめてシンプルなイベントドリブン方式のコードを書ける。そのため、アプリケーションのいろんな部分を呼び出してもダウンするおそれが少ない。

同社は4月に、160万ドルのシードラウンドを調達した。同社はKubernetesのソリューションを提供していたが、今回の発表で、このところデベロッパーに人気のあるサーバーレスにも手を広げた。

上記の資金調達のとき、CEOで協同ファウンダーのTanmai Gopalは、本誌にこう述べた: “われわれのフォーカスは最初から、アプリケーションの開発を超速くすることだった。そのやり方は、われわれのAPIをPostgresデータベースの上に置いて、どんなコードでもそのレベルでデプロイすることだ”。

この最新のプロダクトも、この哲学の延長で、デベロッパーがクラウドネイティブなアプローチを取れるようにする。そしてデベロッパーに、サーバーレスのアドバンテージを、オープンソースで特定のベンダーに縛られないやり方で生かせるツールを与える。

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

Apple、iOS 12ベータのバグを修正――しつこいplease updateが消えた

iOS 12のベータ・テスターはいらだたしいバグに悩まされていた。「新しいバージョンがあります。アップデートしてください」というポップアップが頻繁に現れるのだが、もちろんアップデートなどはない。Appleもこの問題を認識して対策を講じた。現在公開されている最新版では修正されている。

このバグが最初に報じられたのは今週の木曜日で、デベロッパーや一般向けベータ・プログラムのユーザーを含む多くのベータテスターがソーシャルメディアで問題を指摘し始めた。“A new iOS version is now available. Please update from the iOS 12 beta.”(iOSの新しいバージョンがあります。iOS 12 betaからアップデートしてください)というポップアップが繰り返し現れるという症状だ。

ユーザーはCloseをタップすれば閉じることができるが、いくら閉じても同じポップアップが繰り返し表示される。そもそもアップデートすべき新しいバージョンは出ていないのだから対処の方法がなかった。

ベータ版には不具合やバグがあるのは誰もが承知していることだが、 iOS 12 betaは全体としてみるとまれに見るほど安定したベータ版だった。実際、多くのユーザーにとってしつこくアップデートを要求するこの窓がiOS 12 betaで初めて目にするバグだった。

昨日、システムクロックを無効にすればポップアップがでなくなるという記事が出た。しかしこれはまずい方法だ。システムクロックをいじればカレンダーに設定したアポイントメントのリマインダーが出ないなどの深刻な問題が山ほど起きる可能性がある。

Appleはさっそく対策を講じ、ありがたいことに、アメリカで三連休〔9/3がレーバーデイ〕が始まる前に無事問題をを修正した。

バグフィックス版はデベロッパー向けでも一般向けでも現在公開中だ。

原文へ

滑川海彦@Facebook Google+

GoogleがKubernetesの開発インフラの自社負担から降りてすべてをCNCFに委ねる

Googleが今日(米国時間8/29)、同社がCloud Native Computing Foundation(CNCF)に、Google Cloudのクレジット900万ドルを提供して、Kubernetesコンテナオーケストレータの同団体による今後の開発を支援し、プロジェクトの運用に関わるコントロールを同団体に委ねる、と発表した。このクレジットは3年分割で提供され、Kubernetesソフトウェアの構築や試験、配布などに要する費用に充当される。

これまではGoogleが、このプロジェクトを支えるクラウドリソースのほとんどすべてをホストしていた。その中にはたとえばCI/CDによるテストのためのインフラストラクチャや、コンテナのダウンロード、同社クラウド上のDNSサービスなども含まれている。しかしGoogleは今回、一歩後退することになった。Kubernetesコミュニティの成熟に伴い、GoogleはKubernetesのすべてのサポートワークをコミュニティに移そうとしている。

テストのためのインフラストラクチャからコンテナダウンロードのホスティングまで、すべてを合わせるとKubernetesプロジェクトは常時、15万あまりのコンテナを5000基の仮想マシン上で動かしている。その費用は、相当に大きい。Kubernetesのコンテナレジストリはこれまで、1億3000万回近いダウンロードに応じてきた。

それにまた現在のCNCFは、互いに競合する多様なメンバーを抱えている。Alibaba Cloud, AWS, Microsoft Azure, Google Cloud, IBM Cloud, Oracle, SAP, VMwareなどがその例だ。全員がCNCFの仕事やKubernetesのコミュニティから利益を得ている。Googleはこれまで黙っていたが、そろそろKubernetesのインフラストラクチャを動かす重荷を、それにふさわしい者に担わせるべきだろう。それにコミュニティのメンバーの一部は、KubernetesがGoogleのインフラストラクチャにあまりにも密接に結びついていることを、嫌っていた。

GoogleのKubernetes EngineのプロダクトマネージャーWilliam Denissが、今日の発表声明でこう書いている: “Kubernetesの運用責任をプロジェクトのコントリビューターが共有することによって、彼ら全員が持ち寄る新しいアイデアや効率性を生かせるようになるだろう。それが楽しみである”。彼によると今後も、Kubernetesのインフラストラクチャの運用には、Googleの意思が適宜反映されていく、という。

CNCFの事務局長Dan Kohnはこう述べる: “KubernetesのコミュニティにGoogleの大きな財政支援があることによって、このプロジェクトのイノベーションと採用の安定的なペースが今後も減衰することなく維持されるだろう。Google CloudがKubernetesのテストとインフラストラクチャに関わるプロジェクトをコントリビューターの手に渡したことによって、プロジェクトはオープンソースであるだけでなく、オープンなコミュニティによってオープンに管理されるものになる”。

今後長期的には、インフラストラクチャがGoogleのクラウドから離れることになるのか、そのへんはまだ分からないが、3年後に他のクラウドプロバイダーが同様のクレジットを提供することは、大いにありえるだろう。

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