コードの各所に関するデベロッパー同士の議論をコメントのように残せる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

Googleの開発プラットホームFirebaseのサミットがチェコのプラハで開催、エンタープライズ指向を強調

今日(米国時間10/29)プラハで行われたFirebase SummitでGoogleは、そのアプリケーション*開発プラットホームFirebaseのさまざまなアップデートを発表した。それにより同社は、同プラットホームを、個人や小さなチームのための環境であるだけでなく、本格的なエンタープライズ開発ツールにも仕立てようとしている。〔*: 開発プラットホーム; 主にWebアプリケーションとモバイルアプリが対象。参考記事。〕

Googleは4年前にFirebaseを買収して、デベロッパーがそのSDKを使って重要なクラウドツール…データベースやストレージなど…に容易に接続できるようにした。その後同社は、その上に、モニタリングなどの高度な機能を加え、パフォーマンスの問題を解決し、アプリのユーザーのエンゲージメントを知るためのアナリティクスを加えたりしてきた。でも、これまでのそれらツールキットは、必ずしも大企業を視野に入れたものではなかった。

Firebaseのプロダクト担当Francis Maが、こう語る: “今日の発表は主に、モバイルアプリの構築と成長を志向しているエンタープライズと高度なアプリチームのための、機能とアップデートが中心だ”。

たぶん今日の最大のニュースは、企業対象のサポートが加わったことだろう。毎月150万のアプリおよびアプリケーションがFirebase上で作られているというが、しかしエンタープライズに深く入り込むためには、企業のITが問題にぶつかったとき電話できるところが必要だ。そのため同社は年内に、各種のサポートパッケージをベータで発表する予定だ。それらが、さらに幅広いGoogle Cloud Platformのサポートと組み合わさる形になる。

“すでにGCPの有償サポートを受けているユーザーは、そのGoogle Cloud Platform(GCP) Support ConsoleからFirebase関連の質問に答えてもらえる。またGCPのサポートパッケージには、ターゲットのレスポンスタイムや、専用のテクニカルアカウントマネージャー(Enterprise Supportの場合)などが含まれている。Firebaseのサポートに関して、別料金は発生しない”、とMaはGoogle Cloudとの一体性をブログ記事で強調している

また、大きなチームや企業はさまざまな管理ツールを必要とするので、Googleは今日、Firebase Management APIを発表した。これによりIDEからFirebaseへの、プロジェクトのワークフローを、プログラムにより管理できるようになる。Maによると、これにはWebベースのIDE、StackBlitzとGlitchの統合も含まれている。“これらのプラットホームがFirebaseでアプリが作られていることを自動的に検出し、ボタンひとつでそれをFirebase Hostingへデプロイできるようにする。彼らのプラットホームを去る必要はない”、とMaは書いている。

そのほか、5月に発表されたGoogle MLキットの顔認識ツールへのアクセスの改良をはじめ、たくさんの発表があった。パフォーマンスモニタリングツールCrashlyticsが改良されて、PagerDutyの統合が行われた。アナリティクスツールFirebase Predictionsは、ベータを卒業して一般公開された。

これらの発表はすべて、Firebaseプラットホームの成熟を示すと同時に、単なるデベロッパーツールから、エンタープライズも視野に収めたツールへの機能拡張を、はっきりとねらっている。

[原文へ]
(翻訳: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

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

CI/CDを末端企業にも普及させたいArmoryはY Combinator出身で$10Mを調達

オープンソースのSpinnakerプロジェクトをベースとするCI/CDプラットホームArmoryが今日(米国時間8/22)、シリーズAのラウンドにより1000万ドルの資金を調達したことを発表した。このラウンドはCrosslink Capitalがリードし、Bain Capital Ventures, Javelin Venture Partners, Y Combinator, そしてRobin Vasanらが参加した。

ソフトウェア開発は、ここ数年で確かに変わった。間隔の長いアップデート・サイクルに代わり、継続的デリバリが主流になってきた。このコンセプトは今では、継続的インテグレーション/継続的デリバリ(continuous integration/continuous delivery)を表すCI/CDと呼ばれている。Armoryのプロダクトは、このタイプのソリューションをデプロイするときに伴う複雑性を、軽減しようとする。

同社を創業したときファウンダーたちは、CI/CD技術のバックエンドのベースとしてSpinnakerを使う、と決めた。それは、GoogleやNetflixなど業界の大物たちが支持しているプロジェクトだからだ。ArmoryのCEOで協同ファウンダーのDaniel R. Odioが、今回の資金調達を発表するブログ記事でこう述べている: “Spinnakerは大規模で本格的なマルチクラウドのデプロイを支えるスタンダードになるだろう。自分たちで新たに継続的デリバリのプラットホームを内製で構築する、そんな車輪の再発明を避けて、SpinnakerをArmoryプラットホームのコアにするという、大きな賭をした”。

同社によると、その賭は報われ、Spinnakerの同社バージョンはエンタープライズのソリューションで広くデプロイされている。同社の目標は、Fortune 2000社がソフトウェアのデプロイを今よりずっと速くできるようになることだ。そしてそのためには、CI/CDのアクセスと理解が欠かせない。

今企業は、どんな企業でもソフトウェア企業になりつつあるから、どの企業もこれまでとは異質な部分を抱え込むことになる。GoogleやNetflixのような超大物は、最先端の方法により、ソフトウェアを驚異的なスピードでデプロイする方法を経験から学び構築しているが、製品の製造技術=ソフトウェア開発技術ではない、そこらのふつうの企業は、ソフトウェア技術者もそんなに多くないから、Googleなどに追随することは難しい。

その空隙を補ってくれるのが、Armoryのような企業だ。同社は、オープンソースの技術を核として、その複雑性を包み隠すパッケージにより、高度なソフトウェアデプロイ技術を持たない普通の企業でもCI/CDを導入できるようにする。

中でもとくに同社が強調するマルチクラウドでクラウドネイティブなソフトウェア開発方式は、ユーザーのアプリケーションやインフラストラクチャを、オンプレミスも含む複数のクラウドに分散可能にする。そのようなデプロイ技術の重要な部分が、継続的デプロイを管理する技術だ。

Armoryは2016年にローンチし、ベイエリアに拠を構える。これまで1400万ドルを調達したが、そのうちの400万ドルのシードラウンドは昨年行った。同社はY Combinator 2017冬季の卒業生であり、Y Combinatorは今回の投資に参加している。

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

継続的インテグレーション(CI)による開発自動化プラットホームCircleCIが初の海外オフィスを日本に

CircleCIの、継続的インテグレーションとデプロイメントをベースとするビルドプラットホームは、今や世界中の数十万のデベロッパーが利用している。同社はこれまで5900万ドルのVC資金を調達しているが、うち3100万ドルは、今年初めのシリーズCのラウンドだ。

グローバル化によって成長を維持したい同社はこのほど初めて、サンフランシスコの本社の外、日本の東京にオフィスを開いた。最初はそのオフィスの社員を4〜5名とし、地元企業とのパートナーシップで事業を展開するつもりだ。

同社にとって日本は初体験ではない。すでに数名のリモートワーカーがいるし、またCyberAgentやDeNAとの仕事を通じて、日本はアメリカとイギリスに次ぐ同社の世界第三位の市場だ。

CEOのJim Roseはこう説明する: “日本やグローバル市場で活躍できることは、本当にすばらしい。日本はこれまでも、うちにとって成長市場だったし、最近では成長のスピードが上がっている”。Roseは2014年にCircleCIがDistillerを買収したとき同社のCOOになり、2015年にCEOになった。

CircleCIは世界のどこにいて、どんなインフラを使っているデベロッパーでも簡単にインストールして使えるため、同社の売上はボトムアップ的(口コミ的)に伸びている。今や同社の知名度は高く、売上の35〜40%はすでにグローバル市場からだ。

しかしCircleCIのプロダクトは、ワンクリックでインストールできる簡便さが売りではない。むしろCircleCIは、クラウドネイティブな環境でソフトウェアを管理するためのまったく新しい方法であり、デベロッパーと管理職との密接な協働を支えることにより、レガシーのコードベースをクラウドとGitから成る環境へ移行させる過程を助ける。Roseは曰く、“最近の6四半期ぐらいの傾向としては、大企業でもそんなやり方が根付きつつある”。

でも。そのための教育訓練や企業文化の変化は、日本のような非英語圏では容易でないだろう。Roseによると、企業がCircleCIのシステムをインストールするという導入の第一歩をクリアしたら、“今度はそれを社内に周知する仕事があり、それにはローカルな知識が必要だ”。そこで地元雇用の社員たちや地元企業とのパートナーシップが、CircleCIを顧客企業のワークフローに接着していくことを、同社は期待している。

イギリスは同社の二番目に大きな市場だが、新たにオフィスを置くという形での国際展開の端緒として日本を選んだのは、同社の英語のリソースが日本では十分に通用することが実証されたからであり、そしてイギリスはBrexitによってヨーロッパにおける戦略立案が難しくなっているためだ。

“BrexitとGDPRをめぐっては、大量の可動部品があり、単一市場としてアプローチできるのかも、はっきりしない。とりあえずイギリスは、EUとは別の単独市場としてアプローチすべきだろう”、とRoseは説明する。ドイツ、フランス、北欧など、ヨーロッパのそのほかの部分に対する国際展開は、その正しいやり方を目下思案中だ。

Roseの構想では、アメリカ以外の売上を売上全体の50%にもっていきたい。日本は今後国際展開に力を入れていくための、いわばスタート地点だ。

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

OpenStackがオープンソースのCI/CDプラットホームZuulを切り離して独立化

OpenStackほど複雑なオープンソースプロジェクトはほかにないと思われるが、これは要するに、AmazonのAWSのような総合的なクラウドコンピューティング環境を、企業が自分のデータセンターの(主としてプライベートな)インフラストラクチャとして装備するためのシステムだ。それを構成するさまざまなサブシステムを作るためにチームは、独自のDevOpsツールを作らざるをえなかった。2012年には、その一環として、オープンソースの継続的インテグレーションとデリバリ(CI/CD)プラットホームZuulを作った。そしてこのほど、Zulu v3のリリースを契機に、ZuluをOpenStackから切り離して独立のプロジェクトにした。でもOpenStackのエコシステムを去るわけではなく、依然としてそれは、OpenStack Foundationがホストするツールだ。

構造をざっと展望すると、OpenStack Foundationは一種の母体的組織であり、その傘下のメインプロジェクトとしてOpenStack本体のほかに、昨年おそく登場したKata Containersと、今回のZuulがある、という構造になる。すなわちOSFは近年、本体OpenStackのほかに、関連のインフラストラクチャプロジェクトも揃えよう、としているのだ。

Zuulはデベロッパーたちに、プロジェクトに新たな変更を加えようとするときの、コードのマージ、ビルド、そしてテストの工程を自動化するシステムを提供する。サポートする開発プラットホームはかなり幅広くて、GitHubや、コードレビューとプロジェクト管理のツールGerritなどもサポートしている。

Zuulの現在のコントリビューターは、BMW, GitHub, GoDaddy, Huawei, Red Hat, そしてSUSEだ。BMWのソフトウェアエンジニアTobias Henkelは語る: “ソフトウェアプロジェクトがCD/CIを幅広く採用することは、高品質なソフトウェアをタイムリーにデリバリするための基盤だ。それにより、個々のコミットチェックからフルリリースに至るまでの、開発サイクルの重要な部分を、すべて自動化できる。弊社BMWのCI/CDチームは、Zuulコミュニティの一員であることを誇りとし、オープンソースのZuulプロジェクトの積極的なコントリビューターであり続けたい”。

Zuulがスピンオフして独立した今の時期は、CI/CDに関して選択肢がとても多くなっている。GoogleとNetflixはオープンソースのSpinnakerで、Zuulと同様の機能を提供しようとしているし、またJenkinsとその類似プロジェクトたちも依然として強い。これらに対してZuulは、大規模で複雑な開発プロジェクトをうまく扱えるmulti-repo gatingマルチリポジトリ・ゲーティング)機能の有利性を強調している。

今カナダのバンクーバーで、これらのオープンソースプロジェクトの代表者たちによるOpenDevカンファレンスが行われており、そこでOpenStack Summitも併催されているので、数日〜数週間後にはこれらのプロジェクトすべてに関するより詳しい情報が出てくることだろう。

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

デザインスケッチからコードを起こすAIとコンピュータービジョンのUizardが80万ドルを調達

アプリケーションを作る工程には、誰かが描いたスケッチを見つめながらそれをコードに換えていく、面倒で時間のかかる関門がある。でも実際やってることは毎回同じだから、もっと楽にできるやり方があるはずだ。フロントエンドのデザインからHTMLやCSS、そして実働コードを起こしていくこれまでのソフトウェア開発は、費用も時間もかかり、かったるい反復作業が多い。

そしてこの問題を解決する方法の多くが、むしろかえって複雑だったりする。ワイヤーフレームのようなスケッチを単純にコードに換えてくれて、デベロッパーはアプリケーションのもっと難しい部分に集中できる、というやり方はありえないだろうか?

この課題に挑戦したのが、コペンハーゲンのUizardだ。

Uizardはコンピュータービジョンの技術とAIを利用して、ナプキンの裏に描いたようなラフスケッチのデザインを、バックエンドに挿入できるソースコードに換える。

このほど同社は、ニューヨークのLDV Capitalがリードするプレシードのラウンドで、80万ドルを調達した。このラウンドには、ByFounders, The Nordic Web Ventures, 7percent Ventures, New York Venture Partners, 起業家でDatekの協同ファウンダーPeter Stern、Philipp Moehring、AngelListのAndy Chungらが参加した。得られた資金はチームの増員とプロダクトのベータローンチに充てられる。

同社は2017年6月に最初の研究プロジェクト“pix2code”(画素をコードへ)を発表したとき注目を浴び、そのGitHub上の実装は、Facebook PrepackやGoogle TensorFlowの登場よりも前に、第二回mosttrendingプロジェクト賞を取った。

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

Microsoftがオンライン学習にAI上級コースとソフトウェア開発入門を新たに加える

Microsoftが今日(米国時間4/2)、デベロッパーのためのオンライン教育プログラムに二つの新しいコースを加えた。ソフトウェア開発入門コースと、機械学習の知識を増やしたいと願っている中級以上のデベロッパーのためのAIコースだ。

誰もが知ってるように、データサイエンティストと機械学習のデベロッパーは、需要に対して供給がきわめて少ない。そのために今、多くの企業では、社員の知識と技能を高めるための社内教育に力を入れているが、今日から始まる誰でも受講できるAIコースも、最初はMicrosoftが自社の社員のために開発したコースだ。

そのMicrosoft Professional Program for Artificial IntelligenceはedX.orgで無料で受講できるが、お金を払えば修了証ももらえる。コースの期間は3か月で、各四半期の頭に始まる。当然ながら、Microsoft AzureとMicrosoftのCognitive Servicesを多く使うからAzureのアカウントは必要だが、使用するオペレーティングシステムは特定しない。

全部で10の必修クラスがあり、それらはAI入門データサイエンスのためのPythonプログラミングAIデベロッパーの倫理などさまざまだ。訓練モデルを使った実習も多い。ひとつのクラスは所要時間が8ないし16時間だ。

AIコースだけでなく、同じく今日発表されたソフトウェア開発の入門コースは、これもedXのコースで13の必修クラスから成る。とくに、JavaScriptとPythonが中心のようだ。ただしこれらのプログラミング言語を学ぶだけでなく、データ構造の基礎や、GitHubの使い方、コードをプロフェッショナルに書くためのそのほかのツールなども教わる。

こういった学習コースをいろいろ集めたものを、Microsoftは“Professional Programと呼んでいる。Microsoft Academyの方が、分かりやすいんじゃないかなぁ。今あるコースは、フロントエンドの開発、クラウドのアドミン育成、ITサポートのプロフェッショナル育成などだ。

画像クレジット: 写真提供, Dan DeLong/Microsoft

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

サードパーティコードの脆弱性をチェックするAppcanaryのチームがGitHubにスカウトされた

Y Combinatorで孵化したサービスAppcanaryは、デベロッパーが使用するサードパーティのパッケージやライブラリのセキュリティを調べる*。その同社が今日(米国時間1/4)、6月1日をもってサービスを閉鎖し、チームはGitHubに加わる、と発表した。〔*: canary,カナリアは、坑道の中で落盤の危険性を鳴き声で知らせてくれる、とされている。〕

両社の契約内容、とくにその財務的側面は公表されていないが、本誌TechCrunchの理解ではそれは、主として人材獲得を目的とする買収だ。

今日の発表声明の中でAppcanaryのファウンダーMax VeytsmanとPhill Mendonça-Vieiraはこう述べている: “私たちは最初にRubysecを作り、その後(今は亡き)Gemcanaryを作り、それからAppcanaryを始めたが、その間一貫して私たちの目標は、脆弱なソフトウェアの使用を防ぐことによって世界のセキュリティを向上させることだった。当時は、そのためのビジネスを作ることが必要と思われたが、しかしさまざまな理由により、その方向性は実らなかった”。

これまでAppcanaryは、最大三つのエージェント(三つのサーバー)をチェックしモニタするサービスに月額29ドルを課金していたが、近く料金を上げる予定だった。

なお、GitHubも最近、デベロッパーのコードの脆弱性をモニタする同種のサービス発表している。そこで当然ながらAppcanaryのファウンダーたちは、GitHubのセキュリティツールの今後の機能拡充が自分たちの仕事だと自覚している。

買収に関するGitHubの説明は、Appcanaryの発表とよく似ている: “AppcanaryのチームとPhillip Mendonça-VieiraおよびMax VeytsmanがGitHubにチームに加わったことはとても嬉しい。彼らはその専門的知識と技能をGitHubのコミュニティにもたらし、デベロッパーたちのセキュリティ能力を強化するだろう。GitHubはセキュリティアラート(Security Alerts)の分野への投資と機能拡充を、メインの重要業務の一環と見なしている”。

6月1日になるとAppcanaryのサービスはすべて閉鎖し、コードの脆弱性スキャンを求めるユーザーのニーズは、SpacewalkLandscape, CoreOS Clair, Nessus Agents, そしてThreatStackなどへリダイレクトされる。

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

スペクター! メルトダウン! カーネル・パニック!――今回の脆弱性はほぼ全員に影響が及ぶ

新たななコンピューター脆弱性をめぐって昨日(米国時間1/3)から発生している記事、声明、論文の雪崩に当惑している読者も多いだろう。これらには相互に矛盾する主張も多い。ほぼあらゆるコンピューターとOSに影響するMeltdownとSpectreという2つの欠陥は一体どんなどんなものなのか? 昨日の記事に引き続き、さらに詳しく現在判明している情報を紹介する。

どんな欠陥なのか?

要約:コンピューター・アーキテクチャーの本質的な欠陥により、プロセッサーのもっとも深いレベルに位置する重要情報へのアクセスが可能になる。


セキュリティー専門家は公式文書を発表して問題を確認している。 深刻な2つの脆弱性にはそれぞれ名前とロゴが与えられている(上の図で左がMeltdown、右がSpectre)。この欠陥は現在利用されているほとんどあらゆる中央演算処理装置―CPUに影響を与えている。

これらはCPUの物理的機能に関連する問題ではないし、WordやChromeにもときおり見られるようなプログラミングのミスによるソフトウェアのバグでもない。これは現代のCPUのアーキテクチャーそのものに内在する問題だ。

現代のCPUアーキテクチャーにはあらゆるデータが生で、つまり暗号化されずに処理される部分が存在する。このスペースは当然不可侵の領域でなければならない。CPUのアーキテクチャーの根本をなす部分、カーネルがそうした領域だ。またシステム・メモリー中にも他のアプリケーションからアクセスできないよう慎重に隔離された領域が存在する。これらの領域内のデータは機密であり、他のアプリケーションやプロセスからアクセスできないよう強力な保護壁が設けられている。

MeltdownとSpectreは セキュリティー専門家が発見した2つの攻撃手法。これらはデータ保護機能を回避してコンピューターが処理するほとんどあらゆるデータへのアクセスを可能にする。つまりパスワード、暗号化データ等の決定的に重要な情報もすべて他のプロセスからアクセス可能となる。

MeltdownはIntel CPUに固有の弱点で、カーネル・メモリー中のデータを保護する機能を迂回する。Intelプロセッサーではカーネル中のあるプロセスが偶然他のプロセスに干渉したり、悪意あるソフトウェアが権限のないデータにアクセスすることを防ぐため、アプリケーション領域とOS領域の間に障壁が設けられている。Meltdownはこの障壁を迂回して保護を無効化する。

SpectreはIntel、AMD、ARM各社のプロセッサーに影響する。つまりデスクトップ・コンピューターだけでなく、各種のモバイル・デバイスその他なんであれCPUが内蔵されているすべてのデバイスが対象となる。つまりスマート・サーモスタットや赤ちゃん見守り用ウェブ・カメラも含まれる。

SpectreはMeltdownとは異なり、アプリケーション間に設けられている障壁を迂回するためにある種の巧妙な罠を仕掛ける。これにより通常であれば他のプロセスからアクセスすることが不可能な領域にあるデータをアプリケーションに暴露させる。現代のコンピューターに多く見られるマルチコア・アーキテクチャーをベースにしているため実行はMeltdownより困難だが、同時にこの脆弱性を取り除くことを一層困難にもしている。

誰が影響されるのか?

要約: コンピューターのユーザーほぼ全員。


2011年に製造されたチップもテストされ、これらの脆弱性を持っていることが確認された。理論的には1995年以降に製造されたCPUすべてが影響を受けているとされる。

繰り返すがMeltdownとSpectreはCPUアーキテクチャー上の弱点であり、チップ・メーカー側の人為的ミスによるバグではない。またWindows、OS X、AndroidはじめあらゆるOSプラットフォームが等しく対象となる。

理論的にはデスクトップ、ノート、サーバー、スマートフォン、組み込みデバイスその他あらゆるデバイスが影響される。簡単にいえば、テストの結果安全だと確認されたプラットフォーム以外はすべてこれらの脆弱性を持つと考えるべきだろう。

Meltdownはまたクラウド・プラットフォームにも影響する点で深刻だ。ただしMeltdown攻撃をリモートで実行するのは非常に困難だという。これはクラウド・サービスにとってグッドニュースだ。

対策はあるのか?

要約:: 完全にではないが修正できる。ただし時間がかかる。


上述のように影響されるデバイスの数は膨大だが、だからといってこうしたデバイスが無防備だというわけではない。またIntel、AMD、ARMその他のチップ・メーカーは数か月にわたって「緩和策」(簡単にいえば絆創膏)を開発してきた。

カーネルのメモリ間の障壁を強化することがMeltdown対策となる。技術用語では「カーネル・ページ・アイソレーション」という。ただしこれには副作用もある。現代のCPUアーキテクチャーはカーネルの動作にある前提を設けている。この前提を変えることはCPUの処理効率を落とすことになる。

Meltdown脆弱性の修正策がチップのパフォーマンスに与える影響は少ない場合で5%、最大で30%に上るものとみられている。いずれにせよなにがしかのパフォーマンス低下は避けられない。しかし脆弱性を取り除くことができるのであればやむを得ない代償だろう。

これと違って、Spectreには当分の間根本的な解決策は得られそうにない。Spectre攻撃はCPUの物理的特性に極めて密接に関連するため、セキュリティー専門家もソフト的にこれを完全に避ける方策を発見することはできなかった。いくつかの回避策が提案されているものの、結論はこうだ。

前節で紹介した一時的回避策は現実の攻撃を短期間防止する役に立つはずだ。しかし今後書かれるコードについてはもちろん現に存在するコードについても、どんな構成であればCPUにとって安全であるか(それとも危険であるか)を判断する方法は知られていない。

今後どのような対策が取られるか予測することは難しいが、もっとも大きな被害をもたらしそうな攻撃を防止するためのソフトウェアのアップデートが相次ぐだろう。MicrosoftはすでにWindows OSに対してアップデートをリリースしている。ARMも一連の緩和策を用意している。Amazonはクラウド・サービスの膨大なサーバー群をアップデート中だ。【略】

ひとつはっきりしているのはデバイスのリコールはないということだ。Samsungのスマートフォンのバッテリー問題のように、問題が特定のハードウェアの特定の部品にある場合、リコールはあり得る。しかし今回の問題で影響されるのは何億ないし何十億にも上る膨大なデバイス群なのでリコールはあり得ない。

なぜ今突然報道されたのか?

要約: チップ・メーカーは来週合同で発表を予定していたがメディアに先回りされた。


実はチップメーカーは数か月前にMeltdownとSpectreという脆弱性について報告を受けていた。セキュリティー専門家は以前からこの問題に注目し研究を続けていた。脆弱性の内容自体は秘密にされていが、理由不明のアップデートが相次いだことで、外部にも少しずつ情報が漏れ始めていた。

仮にセキュリティー専門家が脆弱性を発見すると同時に、たとえばTwitterでそれを公開したとすれば、CPUメーカーよりむしろ悪意あるハッカーを利するだけに終わっただろう。セキュリティー上の問題では情報は「責任ある公開」が求められる。つまりまずそのプロダクトを提供しているメーカー、ベンダーに秘密に通知し、必要なら対応策の開発に協力するわけだ。

今回のケースではGoogleは数か月前にIntelにコンタクトを取っている。もちろん程度の差はあれ、問題の存在を知っていたメーカーは多いはずだ。Microsoftが理由を明かさずにパッチをリリースしていたのもその一例だろう。Linuxの各種ディストリビューションも、脆弱性については詳細を示さないまま、アップデートを行っていた。

セキュリティー問題ではメーカーやベンダーが対応策を得て密かにアップデートを完了して初めて脆弱性の存在が告知されるのが通例だ。今回もその方式を取ることが予定されていた。

しかしThe Registerがいくつかの情報をつなぎ合わせスクープ記事を出した。そのためIntelは来週に予定していた共同発表の前に急きょ「報道は不正確だ」という反論の声明を発表するなどの対応に追われることになったわけだ。

The Registerはセキュリティー問題に関する通例を守るべきだったという声もたしかにある。しかし一方でIntelなどの巨大企業が情報を全面的にコントロールするという状況も好ましくないだろう。もしスクープがなければこの問題に対する関心も現在のように高まることはなかったはずだ。

いずれにせよ、セキュリティー専門家はSpectreを説明した論文の結論として次のように述べている。

この論文で検討した脆弱性は、他の多くの脆弱性と同様、パフォーマンス向上を至上命令として開発を行ってきたテクノロジー業界の長い伝統に根ざすものだ。この結果、CPU、コンパイラ、ドライバー、OS、その他すべての重要な要素が最適化のために複雑にレイヤー化され、セキュリティー・リスクを生じさせることとなっている。パフォーマンス向上の代償としてセキュリティーを犠牲にするこのようなデザイン手法は見直しの時期に来ている。多くの場面でセキュリティーの最大化を目的とする実装が求められるている。

[原文へ]

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

ストリートビューから奇妙な継ぎ目が消える――Googleが画像ブレンド技術を大きく改良

これまでもGoogleは世界中の道路を撮影するという野心的なプロジェクト、ストリートビューのテクノロジーの改良に努めてきた。最近もストリートビュー撮影車の装備を大きく改良したことを発表している。今回はマルチカメラで撮影された複数の映像からパノラマを生成する際に生じる奇妙な継ぎ目を目立たなくする方法を考案した。

Googleではストリートビューを撮影するカメラを「ロゼット」と呼んでいる。派手な塗装のGoogleカーの屋根に乗っている球体だ。これには多数のカメラが内蔵されて周囲を撮影する。それぞれ独立に作動するカメラ15台に多数のセンサーも搭載されており、道路を巡航しながら連続的に周囲を撮影していく。専用ソフトが撮影された画像をつなぎ合わせせてストリートビューが作られる。われわれはストリートビューのおかげで(Googleカーが通った道路なら)世界中どこへでも入っていくことができる。

とはいえ、ストリートビューを使ったことがあれば、映像中にときおり奇妙な継ぎ目が表示されてしまうのに気づいたかもしれない。ロゼットの15台のカメラが撮影した映像を接続する際に、風景にズレが生じたり看板や標識などの重要な情報が消えてしまったりする現象だ。これはGoogleマップだけに生じる問題ではなくて、他のパノラマ生成テクノロジーでも広く見られる。各種のスマートフォン・カメラやVR向けデジタル画像処理ソフトでもこれが起きるのに気づいたユーザーも多いだろう。

Googleではこの苛立たしい画像の継ぎ目をシームレスにスムーズなものにする新しいアルゴリズムを実用に移した。これは接続しようとする2枚の重なり合う画像のデータを簡約化する際に、ピクセルレベルで画像を比較し、接続部分に不自然な視覚的構造が生じないよう補正する(たとえば建物の水平な線など)。

困難だったのは、接続部分を補正しつつ、画像の他の部分を「正常」に見えるように保つことだったという。人間の視覚はこの点きわめて鋭敏で、理由は不明でも、何かが正常に見えないとすぐに気づいてしまう。画像の一部を補正した影響が他の部分に及ぶと、あきらかに不自然な映像になってしまうことがある。

この点を避けるためにGoogleは新しいアルゴリズムを開発し、複数画像をスムーズに接続することに成功した。下のスライドショーでその例をいくつか観察できる。

  1. f7.png

  2. f10.png

  3. f8.png

Googleではストリートビューのパノラマ画像を新しいアルゴリズムでアップデート中だ。しかしGoogleマップ中には膨大なパノラマが含まれているため過去に撮影されたパノラマのアップデートにはかなり時間がかかる。まだしばらくはストリートビューを開いたときに継ぎ目が目立つパノラマを見ることがあるはずだ。しかしこうした苛立たしい画像のズレは次第に解消されていくだろう。

〔日本版〕ロゼットで撮影された多数の画像がストリート・ビュー・パノラマに合成されるプロセスはビデオの1分10秒あたりから説明されている。トップ画像の旧バージョンではロンドンのタワーブリッジ上部の歩道橋部分に大きな段差が生じている。

[原文へ]

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

Steve Wozniakが教育プラットホームWoz Uでテクノロジー布教者として第二の人生をスタート

Appleの協同ファウンダーとしてSteve Jobsと共に世界を変えたSteve Wozniakが今日(米国時間10/13)、Waz Uというものの創立を発表した。

リリースによるとWoz Uは、学生とその学生を雇用することになる企業両方のための学習プラットホームだ。Woz Uはアリゾナで立ち上がるが、今後はオンラインだけでなく物理的な学習拠点を全世界30以上の都市で展開したい、としている。

最初のカリキュラムは、コンピューターのサポートのスペシャリストとソフトウェアデベロッパーの育成を目的とする。今後はデータサイエンスやモバイルアプリケーション、サイバーセキュリティなどにもカリキュラムを広げていく。

Woz Uの構想は、教育のプラットホームであると同時に、テクノロジー企業のための求人〜教育訓練〜雇用のプラットホームでもあることだ。後者のために企業には、カスタム化されたオンサイトのプログラムと、会員制のカリキュラムを提供する。さらにK-12の児童生徒も対象にして、学区単位のSTEAM教育*プログラムにより人材を育成/発見し、テクノロジー方面のキャリアを育てていく。〔*: STEAM; Science, Technology, Engineering, Arts, Mathematics〕

さらに今後のWoz Uはアクセラレータ事業も導入し、テクノロジー方面の優秀な人材を起業の段階にまで育てていく。

発表声明でWozはこう言っている:

目標は、学生を長年の学費ローン返済で苦しめることなく、雇用に結びつくデジタルスキルを習得させることにある。人びとが往々にしてテクノロジー方面のキャリアの選択を避けるのは、自分にはできないと思い込むからだ。しかしそれは、誰にでもできる。ここでは、誰にでもできることを証明したい。私の全人生は、テクノロジーによってより良い世界を築くことに捧げられてきた。そのためにつねに、教育を尊敬してきた。そしてこれからはWoz Uで、新たなスタートをきりたい。それが今、やっと始まったのだ。

Woz Uは、自分にはテクノロジーのどの分野が向いているかを知るためのアプリを提供する。それによって、自分のカリキュラムを決めればよい。

料金については、まだ発表がない。

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

ソフトウェアのサプライチェーンを監視するためのAPI集合GrafeasをGoogleやIBMなど8社が共同開発

コンテナとマイクロサービスによって、ソフトウェアの作り方が急速に変わりつつある。しかし、どんな変化にも問題はつきものだ。コンテナが目の前にあるとき、それを誰が作ったのか、その中で何が動くのかを知りたいだろう。この基本的な問題を解決するために、Google, JFrog, Red Hat, IBM, Black Duck, Twistlock, Aqua Security, そしてCoreOSの計8社が今日(米国時間10/12)、共同のオープンソースプロジェクトGrafeas※を発表した(※: ギリシア語で“scribe, 書記官”の意味)。その目的は、ソフトウェアのサプライチェーンを検査し統轄するための標準的な方法を確立することだ。

併せてGoogleは、もうひとつの新しいプロジェクト、Kritis※を立ち上げた(※: ギリシア語で“judge, 鑑定人”の意味…Kubernetesの成功以来、Googleの新しいオープンソースプロジェクトにはほかの言葉を使えなくなったのだ!)。Kritisは、Kubernetesのクラスターをデプロイするとき、コンテナに一定のプロパティを強制する。

Grafeasは、コードのデプロイとビルドのパイプラインに関するすべてのメタデータを集めるための、APIの集合だ。そしてそのために、コードの原作者や出所、各コード片のデプロイ履歴〜デプロイ時の記録、どのようなセキュリティスキャンをパスしたか、どんなコンポーネントを使っているか(そして各コンポーネントの既知の脆弱性)、QAからの承認の有無、などの記録をキープする。そうすると、新しいコードをデプロイする前にGrafeasのAPIを使ってこれらの情報をすべてチェックでき、それが(得られた情報の範囲内で)脆弱性なしと認定されていたら、プロダクションに放り込める。

一見するとこれは、平凡すぎる感じがしないでもないが、でもこんなプロジェクトのニーズは確かにある。継続的インテグレーションや分散化、マイクロサービス、どんどん増えるツールセット、そして各種バズワードの奔流、といった動向の中でエンタープライズは、自分たちのデータセンターで実際に何が起きているのかを知ることに苦労している。今動かしているソフトウェアの本性を知らずに、セキュリティやガバナンスを云々しても空しい。そしてデベロッパーが使うツールは統一されていないから、そこから得られるデータもまちまちだ。そこでGrafeasは、どんなツールでも一定の標準化された、業界全員が合意しているデータ集合が得られるようにする。

Googleのオープンソースプロジェクトの多くがそうであるように、Grafeasも、この問題のGoogle自身の対処方法を模倣している。規模が大きくて、しかもコンテナやマイクロサービスを早くから採用しているGoogleは、業界全体の問題になる前にこれらの問題を数多く体験している。Googleによる本日の発表によると、Grafeasの基本的な内容は、Google自身がそのビルドシステムのために開発したベストプラクティスを反映している。

そのほかのパートナーたちも全員が、このプロジェクトにいろんなおみやげを持参している。しかしたとえばJFrogは、同社のXray APIにこのシステムを実装するつもりだ。Red Hatは、同社のコンテナプラットホームOpenShiftのセキュリティとオートメーションを強化するためにこれを導入し、CoreOSは同社のKubernetesプラットホームTectonicにこれを統合する。

Grafeasの初期のテスターの中には、Shopifyがいる。同社は現在、一日に約6000のコンテナをビルドし、それらが33万点の画像を同社のメインのコンテナレジストリに保存する。Grafeasがあると、たとえば、今どのコンテナがプロダクションで使われているか、それはいつレジストリからダウンロードされたか、その中ではどのパッケージが動いているのか、そして、コンテナの中のコンポーネントのどれかに既知の脆弱性はないか、などが分かる。

Shopifyは、今日の発表声明の中でこう言っている: “Grafeasによってコンテナの正確なメタデータが得られるので、セキュリティチームがこれらの質問に答えられるようになり、またShopifyでわれわれがユーザーに届けるソフトウェアの検査やライフサイクル管理に、適切な肉付けがなされるようになった〔形式だけではなくなった〕”。

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

GitLabがGVのリードするシリーズCで$20Mを調達、ソフトウェア開発〜リリースの総合ソリューションを目指す

デベロッパーのためのコラボレーションとDevOpsのプラットホームGitLabは現在、10万あまりの企業が利用している。同社は今日(米国時間10/9)、GV(元Google Ventures)がリードするシリーズCのラウンドにより2000万ドルを調達したことを発表した。これでGitLabの総調達額は4550万ドルあまりとなる。

新たな資金調達に加えて同社は今日、WordPressの協同ファウンダーMatt Mullenwegが同社の取締役会に加わったことを発表した。

GitLabは、その名が示すように、gitをベースとし、デベロッパーがコードのリポジトリーをセルフホスティングしていくためのオープンソースのツールだ。しかし2014年のローンチ以来同社は、そのほかのDevOps向けサービスをいくつも新設してきた。それらの中にはワークフローツールがいくつかあり、またコードのレビューやリリースを容易にできるためや、アプリケーションのモニタリングのための機能すらある。

そこで同社は、自己のミッションを次のように定義している: “現代のソフトウェアデベロッパーのためのシームレスで総合的なプロダクトを開発し、またKubernetesによるソフトウェア開発のためのアプリケーションになること”

そう。今やGitLabですら、Kubernetesというゲームに深く関わりたいのだ。

GVのゼネラルパートナーDave Munichielloは、今日の声明文の中で次のように述べている: “Fortune 500社は今、互いに競ってワールドクラスのソフトウェア開発組織を作ろうとしており、またそれらに、世界最大のテクノロジー企業なみのスピードと生産性とクォリティを持たせようとしている。これらの組織は高品質で大規模なコードを作るべく努力しているので、最高クラスのツールとプラットホームを必要とする。GitLabのプラットホームは、コラボレーションとオートメーションを強調することにより開発プロセスを加速する。GitLabのハイブリッドでマルチクラウドのソリューションはデベロッパーに好まれており、その分野で巨大なファン層を形成している”。

GitLabの現在のユーザーには、Ticketmaster, ING, NASDAQ, Sony, Intelなどもいる。

新たな資金の使途について同社は、“ソフトウェアのパッケージングとリリース方式と構成とモニタリングに関して新たな機能性を加えたい”、と言っている。

同社の競合サービスはGitHubやAtlassianのBitBucketなどだが、GitLabによると、セルフホスティング型のgit市場では同社が2/3のシェアを占めるそうだ。

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

Facebookの特許条項のリスクを嫌い、WordPressがReactライブラリの利用を止めることを発表

人気のウェブパブリッシングソフトウェアWordPressの共同創業者Matt Mullenwegは、この先開発コミュニティはFacebookのReact JavaScriptライブラリの利用を中止する方向へ進むと発表した。Facebookが発表したオープンソースライセンス内の条項を懸念してのことである。

9月14日(米国時間)に投稿されたブログ記事で、Mullenwegはその経緯を説明している。彼は公式にReactをWordPressに適用することを望んでいたし、彼が創業したWordPress.comの運用会社Automaticは、WordPress.comのインターフェイスを書き直したCalypsoに、既に数年前からReactを利用していた。そしてWordPressコミュニティもGutenbergコアプロジェクトにReactを使いはじめていたところだったのだ。

しかし彼は、Facebookの特許条項を見てその気持を変えた。このライセンスは最近、Apacheソフトウェア財団(ASF)によって禁止ライセンスリストに加えられた。

現在、React特許条項が含まれているASFの「Category X」リストには次のように書かれている:

FacebookのBSD+Patentsライセンスには、ソフトウェアの下流の消費者に対してライセンサーをライセンシーよりも有利な立場として扱うPATENTSファイルが含まれている。このためユニバーサルドナーであるための、Apacheの法的ポリシーに違反している。FacebookのBSD+Patentsライセンスの条項は、ALv2の条項のサブセットではないため、ALv2としてサブライセンスすることはできない。

先月Facebookは、このASFの決定に反応してブログ記事を書いた。そこでFacebookは同社がパテント条項の背後にある「理由を上手く説明できていなかった」ことを認めた。その上で、これはFacebookのビジネスが「 益のないパテント訴訟のターゲットになった」ために、必要な措置であると主張した。

私たちは、ソフトウェアを3条項BSDライセンスでリリースする際に、明確な特許許諾を加えることを決定した。これはBSD+Patentsライセンスとして知られるようになっている。この特許許諾では、もしあなたがたがこのライセンスでリリースされたソフトウェアを使用している際に、私たちを特許侵害で訴訟した場合には、その特許許諾を失うことを謳っている。このライセンスが広く採用されれば、採用する者たちにとって益のない訴訟を減らすことが可能になると信じている。そしてこの可能性を皆と協力して探究することを望んでいる。

当社は特許を含むサードパーティのIPを尊重し、他の人びとが私たちのIPを尊重することも期待している。BSD+Patentsライセンスは、私たちのチームにオープンソースに対する有意義な貢献をする余地を与え、軽薄な訴訟との戦いに費やす時間を削減することを意図したものである。

それでもなお、Mullenwegは彼の懸念は払拭されていないと述べた。そして彼は、良心にかけて、広範囲に使われているオープンソースのWordPressソフトウェアのユーザーたちに、特許条項とそれに伴う法的リスクを継承することを要求することはできないと書いている。よって彼はReactを捨てることにした。

「Facebookの条項は、企業が取る他の多くのアプローチよりもはるかに明瞭であると思いますし、Facebookはオープンソースの貢献者としても優れていると考えています。しかし、私たちは取り組むべき多くの課題を抱えていますし、Facebookの特許条項が妥当であるということを世界に向けて説得することは、私たちの役割ではないのです。それは彼らの仕事です」と彼は書いている。

彼は、この決定は、Gutenbergにとって少なくとも数週間の遅れを招くだろうと述べた。別のライブラリを使って書き直すために、そのリリースは来年に延びるだろうということだ。

Calypsoの書き直しに関しては、「これはもっと長くかかるでしょう」と述べ、以下のように付け加えた。「Automattic自身はまだ特許条項に問題を抱えてはいませんが、コアとの長期的な一貫性は、Automatticのビジネスに対して、書き直しによる短期的な負担以上の価値があります。WordPressコアのアップデートは全てのウェブサイトの4分の1以上に影響を与えます、この全てに特許条項を継承させることは私が望むものではありません」。

私たちはFacebookにコメントを求めた。何らかの回答が得られた場合はこの記事を更新する。

特許条項に伴うリスクと考えられているものは、もしReactのユーザーが、Facebookの特許を侵害したり、特許侵害訴訟を起こした場合Facebookがどのように特許ライセンスを取り消すかを規定するものだ。

したがって、企業、特に特許ポートフォリオが大きい企業は、FacebookのReactフレームワークを組み込んだオープンソースソフトウェアを使用しているかどうかに懸念を抱くことだろう。たとえAutomatic自身は良いと考えていたとしても。

この特許条項に関する最も激烈な批判者の中には、Reactを「オープンソースコミュニティに投入された『トロイの木馬』だ」と呼ぶ者もいる。

ASFの動きを受けて書かれたHacker Newsでは、開発者のKevinfloがその懸念を以下のようにまとめている「たとえ私たちが彼らの行動を最も好意的な眼で眺めたとしても、そして仮にこの条項が誰かが主張するように張り子の虎であったとしても、それは関係ないことです。これはオープンソースのやり方ではありません。もしプロジェクトのライセンスが放射性物質なら、何年も議論する必要はありません。特に自分のような素晴らしいツールを使いたいだけの個人開発者たちは。私たちはただそれを使えるようになっているべきです。なぜならそれはオープンでああって、それがオープンの意味することだからです。これはクローズドのものよりずっと悪いものです。オープンだと偽ったクローズドなのです」。

Florenzano(kevinflo)は、Reactから離れるというこの決定を祝福している…

これがどれほど大きな意味をもつかは強調しきれません、特許条項のために@automattic@reactjsから離れることにしました https://t.co/QNbpGLUue5

Mullenwegは、Reactに代わるライブラリをまだ決定していないが、その決定は「主に」技術的判断に基いて下されるだろう、と付け加えた。

「私たちは、Reactの利点の大部分をもつものを探しますが、多くの人びとを混乱させ、脅威となる特許条項の手荷物は必要としていません」と彼は述べた。そして「これまでこの件に関して、時間を割いて意見を述べてくれた人たちに感謝します。私たちはいつでも耳を傾けています」と付け加えた。

彼のブログ記事に対するコメントは、大部分がその動きを支持している。あるコメンテーターはそれを「厳しいが重要な決定」と呼び、他の人たちは「賢明」で「良い」決定だと呼んでいる。

とはいえ過剰反応に対して警告を書き込むものもいる「過度に反応するのはやめましょう。ここ5、6年の間、WPの生態系には十分な混乱と混沌が見られてきました。Facebookのビジネス規模と範囲はこの条項を恐ろしいものにしてしまいます。なので彼らは最終的には、それをあきらめなければならないでしょうから」。

[ 原文へ ]
(翻訳:Sako)

FEATURED IMAGE: TAKAMORRY/FLICKR UNDER A CC BY 2.0 LICENSE

Test IOのQAサービスに、開発ツールJiraからの直接アクセスが可能に

現代の「急げや急げ」アジャイル開発環境の中では、ソフトウェアの品質保証テストは控え目な場所に追いやられることもある。この不協和な状況に対してTest IOのようなオンデマンドテストスタートアップが参入してきている。開発者たちが有能なQAテスターたちに​​簡単にアクセスできるようにするサービスだ。

このたび同社は、Test IOサービスを、Atlassian Jira開発ワークフローツールに直接組み込む、新しいプラグインを発表した。このツールはAtlassian Marketplaceで入手できる。

インストールしたなら、開発者たちは単にJiraインターフェイスにあるTest IOボタンをクリックして、テストパラメータを選択し、ワークフローを開始するだけだ。するとサービスは、開発者が要求する必要な専門知識と機器を持つテスターを選定する。と、Test IOのCEOであるPhilip Sofferは説明した。

Sofferによれば、3万人の審査済みソフトウェアテスターからなるチームを擁していて、テスターたちは人間のスーパーバイザーによってある安定したテストレベルに達するまでクロスチェックを受けた者たちということだ。それぞれのテスターは、その品質、可用度、その他の要素によってランク付けされる。プログラマーが特定のスキルと機器を持っている人を問い合わせると、それらは要件に合致する、現在オンラインで対応可能な最も有能な人物にルーティングされる。2つ以上のスキルが必要な場合には、テストリクエストは同時に複数のテスタにルーティングされる可能性がある。ここでのアイデアは、実世界のテスト条件下で、可能な限り迅速かつ正確にQAを完了させることだ。

レビューが完了すると、問題を示すスクリーンショットとスクリーンカムムービーを添えたレポートが、問題のリストとともにプログラマーに直ちに送り返される。開発者は、レビューに関する質問があれば、インターフェースの中でテスターと直接コミュニケーションを取ることができる。

スクリーンショット2017-09-11 14.53.51.png

写真:Test IO

Test IOの顧客の70%がJiraを使用していることを考えれば、同社がサービスにアクセスするためにできるだけシンプルにすることは理にかなっている。Jiraプラグインがない状況では、開発者はブラウザを開いてTest IO Webサイトにアクセスし、サインインし、テストパラメータを選択し、テストする材料をアップロードする必要がある。プラグインを使えば、そうしたものの多くは組み込みツールによって処理され、プログラマたちはテストのリクエストや結果のレビューを行うために、Jiraから離れる必要はない。

Test IOは2011年にベルリンで創業し、現在もそこにオフィスを構えているが、現在の本社はサンノゼに置かれている。Sofferによると、スタートアップは毎年収益をほぼ2倍に伸ばしており、2015年には500万ドルの資金を調達している

[ 原文へ ]
(翻訳:Sako)

FEATURED IMAGE: HERO IMAGES/GETTY IMAGES

Apache Flinkの商用化企業Data ArtisansがFlinkアプリケーションのためのApplication Managerを発表

オープンソースの分散ストリームプロセッサーApache Flinkの商用部門Data Artisansが、ストリーミングアプリケーションを管理するための新しいツールを含む、このプラットホームの商用バージョンの、アーリーアクセスリリースを発表した。

Data ArtisansのCEO Kostas Tzoumasによると、リアルタイムでストリーミングを行うプロダクトを管理するアプリケーションは、それを自分で作ろうとする顧客にいくつかの難題をつきつけるので、同社のApplication Managerはその難題を解決するために設計されている。

Netflix, Alibaba, INGなど大手のFlinkユーザーには、そのようなツールを自作して大量のストリーミングアクティビティを管理しモニタする能力があるが、平均的な企業にはそんな贅沢ができない、とTzoumasは語る。

そんな顧客が作って使っているアプリケーションは、さまざまな外部システムと対話するものが多く、しかもそれをやりながら、大量のデータを、ほぼリアルタイムで処理しなければならない。Data Artisansは、そういう処理につきまとう複雑性を軽減するために、管理の部分を担当するツールを作ったのだ、とTzoumasは説明する。

その新しいツールはFlinkを通るすべてのストリーミングアクティビティを一箇所で集中的に管理する管理コンソールを提供する。そしてストリーミングデータのデータソースやデベロッパーのワークフロー、サービスのデプロイアーキテクチャ、ロギング、メトリクスなどを一望できる。

Apache Flinkを利用しているストリーミングアプリケーションと対話するすべてのサービスを管理できるだけでなく、そのツールを使ってデベロッパーがアプリケーションの開発過程を管理できる。完成したそれらのアプリケーションは、Kubernetesのようなコンテナオーケストレーションツールを使ってローンチする。

さらに、Apache Flinkのストリームに関連するすべてのユーザーアクションの監査証跡を記録するから、デプロイ後にそのステップをさかのぼって調べることができる。

ファウンダーのTzoumasとCTOのStephen Ewenは、Apache Flinkを学生時代に作り、2014年にはその商用化を行う企業としてData Artisansを創業した。標準的なオープンソースのビジネスモデルを採用して顧客がApache Flinkをサポートできるようにし、また企業がApach Flinkによるストリーミングアプリケーションを作るときにはコンサルタントとしてそれを手伝う。しかし、そうやって企業顧客との付き合いを重ねる中で、管理ツールの不在に新たなビジネス機会を見出したのだ。

彼らの会社はベルリンにあり、これまで700万ドルを調達した。今、Apache Flinkのダウンロード回数は1か月に1万ぐらいだ。この記事で取り上げた商用バージョンは2017年の終わりから2018年の初めにかけて一般公開される。

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

Turing Tumbleは巧妙なメカニカル・コンピューター―Kickstarterの教育玩具は大人も楽しめる

近頃はなにもかもエレクトロニクス化されてしまったが、それだけにTuring Tumbleのようなボードゲームは楽しい。

プログラマーでミネソタ大学教員でもあるPaul BoswellはTexas Instrumentsの電卓で遊べるゲームを開発したことで有名だが、 今回はAlyssa Boswellと協力して Turing Tumbleという純粋にメカニカルなコンピューターを作り上げた。ボード上で何種類かの小さな部品を正しく組み合わせることによってさまざなパズルを解くことができる。

Boswellはこれまでもプログラミングを学ぶためのゲームをいくつも開発してきた。ミネソタ大学でコンピューティングを教えている際、他の面では優秀だがプログラミングがいっこうに理解できない科学者を大勢発見した。このフラストレーションがコンピューティングの仕組みを説明するおもちゃを開発する動機になったという。

「プログラミングができる化学者や生物学者は珍しい。実のところどんな分野でも珍しい。そうでないのは計算機科学者くらいのものだ。しかしそれでは困る。私は長年学生にプログラミングを教えてきた。その間、学生であれ教授陣であれ、すばらしいアイディアなのに適当なプログラムが書けないためにプロジェクトを諦めてしまうという事態を繰り返し見てきた」とBoswellは言う。

Turing Tumbleは非常にシンプルは構成だ。ボードのてっぺんからビー玉が転げ落ちる。ボードには格子状に多数の穴が開いており、そこに論理部品をはめ込む。ビー玉が最下段まで落下してフリッパーと呼ばれる部品を押し下げると新しいビー玉が供給され、以下同様にサイクルが続く。

「プレイヤーは6種類の論理部品を利用して論理パズルを解く。 Bitは中でも重要な部品だ。ビー玉が落ちてくるたびにこの部品は反対側に向きを変える。この部品は左向きがゼロ、右向きが1を表す。Gear bitは特に面白い部品だ。Gear bitはBitとほぼ同様の機能だが、名前の通り歯車で、他の歯車と組み合わせることができる。ビー玉が一つの歯車を動かすと次の歯車に動きが伝わる。この部品があるためにボードは全体として『チューリング完全』な機械となる」とBoswell。

こうした理論は表に現れず、見たところはメカニカルなパズルゲームというのが重要な点だ。付属の冊子には51のゲームが紹介されており、子どもたちは遊びながらXORなどの論理回路を組み立てることができる。

このプロジェクトはBoswell夫妻の自己資金がまかなわれる予定で、現在Kickstarterで4万8000ドルの資金集めを行っているところだ。

「メカニカル・コンピューターを調べ始めたところ、1960年代に作られたDigiComp IIという玩具に行き当たった。これは落下するビー玉を動力とする計算機で非常に巧妙だった。私はDigiCompから多くの作動原理を借り、自分のアイディアを付け加えて独自のメカニカル・コンピューターをデザインした。3Dプリンターのおかげでプロトタイプを作成することができた」という。

これは素晴らしい教育玩具だが、もしかすると他のコンピューターがなんらかの理由で全滅したときには計算機として実用になるかもしれない。そんな日が来ないとはいえないだろう。

〔日本版〕Kickstarterのページによれば、プレッジ額は一口399ドルで4万8000ドルの目標に対して3万4875ドルがプレッジされている。

[原文へ]

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