タグ: developer

GoogleがAndroid 8.1にNeural Networks APIを導入、今日からデベロッパーベータを提供

今日Googleは、Android Oreo(v8.1)のデベロッパー向けベータの配布を開始した。

今回の大きな目玉はNeural Networks APIで、これによりスマートフォン上でハードウェアアクセラレーション〔後述〕によるNNの推論を行い、訓練済みの機械学習モデルを高速に実行する。この種の計算をエッジに持ち込むことによって、ネットワークのレイテンシーと負荷が減り、機密データがデバイス上に留まることによって、エンドユーザーに多大な便宜をもたらす。

このNN APIにより、スマートフォン上で画像分類をしたり、ユーザーの行動パターンから次にやることを予見する、といったアプリが可能になる。Googleによると、このNeural Networks APIはTensorFlow LiteやCaffe2などのフレームワーク使いこなすための“基礎としての層”として設計した、という。

このAPIはデバイス上にAI専用チップがあればそれを利用できるが、なければふつうにCPUを使う。GoogleのスマートフォンPixel 2には専用チップPixel Visual Coreが載っており、Googleは前にも、8.1のプレビューが使えるようになったらそれが実際に動く、と言っていた（つまり今日だ）。

Neural Networks APIはユーザーのデバイスを酷使するが、Googleは8.1でAndroid Go用の最適化を導入し、デベロッパーがもっとベーシックなスマートフォン用にはその軽量バージョンのAndroidを使えるようにした。それは、今年の5月にI/Oカンファレンスで発表された簡易版Androidだ。

Goは、接続性の良くないところで使う低スペックのスマートフォン用だ。今回のアップデートではRAMが1GBに満たないデバイス向けのメモリの最適化が行われ、またそれらが8.1以降で動いている場合には、配布するアップデートを対象デバイスのシステムメモリに応じて選択できる。

そのほか、8.1デベロッパープレビューではAutofillがアップデートされて、パスワードマネージャーがこのフレームワークを使いやすくなった。また、そのほかのバグパッチやセキュリティパッチも、いろいろ行われているはずだ。

Android 8.1が消費者の手に渡るのは12月の予定だが、デベロッパーは今すでに、このベータにアクセスできる。

[原文へ]
（翻訳：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））

Mozillaのオープンソース助成制度MOSSは今期の交付額総計が50万ドルを突破

Mozillaは、同団体のオープンソース助成金制度Mozilla Open Source Support(MOSS)の今期（4-9月）の交付総額が53万9000ドルだった、と発表した。この助成金の対象は主に小さなプロジェクトだが、今回はとくに安全とセキュリティをメインテーマとした。

最高額19万4000ドルを交付されたUshahidiは、助けを求めている人が必要としている情報を、素早く集めて散布する。災害で道路が交通不能になっている人たちや、抗議活動で催涙ガスなど警察の攻撃に遭っている人たち、選挙で特定候補への投票を脅されている人たちなどだ。

10万ドルを交付されたRiseUpは、活動家たちのための安全な通信ツールを提供する。クロスブラウザーな（ブラウザーの種類を問わない）フォーマットWebAssemblyの一環としてJavaScriptのモジュールをロードするローダーWebpackが、12万5000ドルを受け取った。HTML5によるゲームエンジンPhaserが5万ドル、HTTPSのデプロイを容易にするシステムの一部であるmod_mdが、7万ドルを交付された。

次期のMOSSは、特定の地域、最初はインドを対象とする。すなわち次回も対象は複数の比較的小さなプロジェクトだが、インド関連がメインになる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Apple、iOSとmacOSのARM版カーネルをオープンソース化

AppleはmacOSの主要なリリースの後、常にカーネルを公開してきた。このカーネルはiOSデバイス上でも動作する。macOSとiOSが同じ基盤の上に作られているからだ。このほどAppleは、最新バージョンのカーネルをGitHubでも公開した。あわせてカーネルのARMバージョンも初めて目にすることができる。

先へ進む前に、まずはコンピューターの歴史を少し話しておくべきだろう。macOSの最初のバージョン（当初はMac OS Xと呼ばれていた）は2001年に登場した。ベースとなったNeXTSTEPは、NeXTのために作られたオペレーティングシステムだ。スティーブ・ジョブズは1985年にNeXTを創設し、1997年にAppleに売却した。そしてAppleはMac OS Xの基盤としてNextSTEPを使う決断を下した。

NeXTSTEP自身、オープンソースプロジェクトのBSDに由来している。今あなたが使っているかもしれないMacが、オープンソース技術に強く依存している理由はそこにある。それはAppleが毎年macOSのごく小さな部分をリリースする理由でもある。これをコンパイルして自分専用バージョンのmacOSを動かすことはできないが、このカーネルのソースコードに関心を持つデベロッパーもいる。

iOSはどうなのか？ 2007年にスティーブ・ジョブズが最初のiPhoneを発表したとき、iPhoneのオペレーティングシステムはmacOSの派生物だと言った。「今日みなさんに、ソフトウェアのブレークスルーをお目にかけます。ほかのどの携帯電話よりも5年以上先を行くソフトウェアです。どうやってそれができたのでしょう？ 実はある強力な基盤を元にしました ― iPhoneではOS Xが動いています」ジョブズはそう言った。「なぜ携帯端末にそんな高度なオペレーティングシステムを使うのでしょう？ そこには私たちに必要なものが全部入っているからです」

AppleはこのオペレーティングシステムをiPhone OSと呼ぶようになり、後にiOSになった。iOSはフローティングウィンドウがないなどmacOSの完全なコピーではない。しかしiOSとmacOSは、Darwinと呼ばれる同じUnixベースのコアをはじめ多くのフレームワークを共有している。Apple WatchとApple TVも、やはりDarwinに依存するiOSの派生システムを使用している。

そういうわけで、ARMに最適化されたAppleカーネルのソースコードをダウンロードできるようになったことに、さほど大きな意味はない。Appleは、iPhoneのカーネルを公開することでオープンソースコミュニティーのフィードバックをもらいたいのかもしれない。AppleはARMチップで動くmacOSを開発中なのかもしれない。あるいは単なる間違いかもしれない。たぶんAppleはTwitterの反応を見たかっただけなのだろう。

[原文へ]

（翻訳：Nob Takahashi / facebook ）

安全なメッセージングサービスSignalがアップデートしてユーザーのアドレス帳の守秘性をアップ

米政府(NSA)が国民の通信を監視していることを暴いたSnowdenご推薦の、Signalのようなセキュアなメッセージングサービスも、今その上に誰がいるか分らなければ誰も使わないだろう。でもユーザーのリストを検索するためにあなたのコンタクト情報を送信したとき、Signalなどがそれをのぞき見しない、とどうやって信頼*できるのか？　実は、信頼など要らない。のぞき見は不可能だから。Signalの今度のアップデートでは、コンタクトの発見がなお一層プライベート（外部非公開）になった。〔*: 本稿は、信頼(trust)をネガティブなものとして捉えている。システムやベンダーへの信頼がセキュリティの唯一の根拠である事態。〕

そもそも、Signalにせよ誰にせよ、誰かがこの情報を集めていたことはない。それは通信の全過程で暗号化されているから、実はすでに相当安全なのだ。でも万一Signalがハックされたり、NSAに秘かに乗っ取られたりしたらどうか。もしもこの悪の双生児（政府諜報機関とハッカー）がSignalを仔細に調べたら、既知のハッシュ（暗号値）を見つけて、そこからユーザーが検索している相手の情報が分かるかもしれない。そんな情報があれば、ユーザーの匿名化が剥げ落ちてしまう。

TechCrunch Disrupt SF 2017の壇上のMoxie Marlinspike(Open Whisper Systems)

SignalのMoxie Marlinspikeは先週のDisruptで、このアップデートの新しい機能を匂わせ、そういう（上記のような）超極端な可能性ですら、確実にありえなくしたチームのやり方を壇上の電子黒板に書き出した。

技術的詳細の説明は彼の方が当然適任だが、しかし、その要旨はこうだ: おそらく、Signalのサーバーは、小さなアクションがあるたびにそれらをログしている。それらから、メッセージの返事が書かれている場所の正確なメモリアドレスが分かり、そのアドレスにユーザー情報もある。

こう考えてみよう: 誰かが今読んだり書いたりしているものが何か、それは直接には分らなくても、よーく見れば、どこに鉛筆があるか、それがどんな動きをしているかは分かる。ユーザーリストがアルファベット順で、検索している名前の文字数が分かれば、かなり範囲は狭まる。

こんな、RAMをモニタするような超低レベルの攻撃も、その可能性を無視すれば敵の利となることもありえる。

しかし幸いにも、今は“secure enclave”（安全な包領・飛び地）という仕様が、急速にチップの設計のスタンダードになりつつある。その中で行われる演算や保存されるデータは、OSのユーザー部分（アプリケーションコード）からアクセスできない。AppleはそのAnチップのsecure enclaveにToch IDやFace IDの情報を収めるから、外部からユーザーのバイオメトリック情報にアクセスできない。ハッカーやあの3文字のお役所の手に、それらが渡ることもない。

この包領を利用し、メインのデータベースに特殊なクェリを投げることによって、Marlinspikeと彼のチームは、ユーザーが自分のアドレス帳をSignalのリストと突き合わせることができるようにした。リストや検索結果を見れるのは、そのユーザーのみである。その包領はさらに、Signalのサーバーがおかしなコードを実行してないことをチェックする。

Signalのその特殊なコードが悪用される可能性が、まったくないわけではないが、ふつうのユーザーコードでアクセスするハッカーや国の諜報機関に比べれば、その可能性はきわめて低い。それでもなお、ユーザーはSignalの技術を信頼しなければならないが、もっともっと多様な要素を信頼しなければならない通常のセキュリティ技術に比べると、要素数が少ないぶん安全だ。比喩として、情報はそれを持つ/見る人が多いほど、漏れる可能性が高い。

この機能はまだ、一般供用されていない。“ベータ技術のプレビュー状態”だ。でも今後の2か月でテストを終えて、展開したい、と言っている。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

オープンソースのライセンスをレビューするOpen Source InitiativeにMicrosoftが参加

Microsoftが今日（米国時間9/27）、Open Source Initiative(OSI)にプレミアムスポンサー(Premium Sponsor)として加わることを発表した。1998年に創設されたOSIは、オープンソースに比較的実践的な姿勢で臨み、オープンソースを企業や政府機関などに唱道してきた。OSIは、ベンダー固有になりがちなオープンソースライセンスのレビューも行い、それらが“コミュニティの規範や期待”に沿うよう努めてきた。

プロジェクトの最高位のスポンサーであるプレミアムスポンサーにはGoogle, IGM, HPE, AdblockPlus, GitHub, Heptioなどがおり、それより下位のスポンサーとしてRedHat, The Linux Foundation, Mozilla, HPなどがいる。

MicrosoftのOpen Source Programs OfficeのディレクターJeff McAfferが、今日の
発表声明でこう述べている: “Open Source Initiativeが行う業務は、オープンソースがソフトウェア産業のファーストクラスの一員として進化し成功していくために欠かせない。Microsoftがオープンソースのコミュニティにより広範に、かつより深く関与していく努力の一環としてOpen Source Initiativeの努力を支援できることは、大きな喜びである”。

MicrosoftがOSIと協働するようになってから、今年で2年になる。また2005年と2007年には、Microsoft Community LicenseとMicrosoft Permission Licenseをそれぞれ、同団体に提出している。Microsoft自身のオープンソースプロジェクトのポートフォリオが近年きわめて大きくなっていることも、周知の事実だ。

しかしオープンソースとフリーソフトウェアのコミュニティには、Microsoftの真意に関する疑念もある。Microsoftの前CEO Steve BallmerがかつてLinuxを癌と呼んだ言葉も、オープンソース世界の集団的無意識の中で今だに反響している。Microsoftもそれは十分に承知だが、でも最近のアクションを見るかぎり、オープンソースのコミュニティの一員になるための正しいマナーが徐々にわかってきたようだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Googleが社内のドキュメンテーションスタイルガイドを公開

ドキュメンテーションは往々にして、後（あと）からの付け足しだ。オープンソースのプロジェクトではとくにそれが多い。そのため新しい人が後日そのプロジェクト参加しづらくなったり、ときにはヘタなドキュメンテーションのせいでコードがかえってわかりづらくなることもある。そこでGoogleは、デベロッパーがもっと良いドキュメンテーションを書けるために、同社のdeveloper-documentation style guide（デベロッパードキュメンテーションスタイルガイド）を今週一般公開した。

これはGoogleが社内的に使っているスタイルガイドと同じもので、KubernetesやDartなどGoogle内部のプロジェクトもこれに従っている。

内容の一例を挙げると:

  • 業界用語のスペリングの統一
    （例: ○data center, ×datacenter）
  • ハイフンの正しい使い方と良くない使い方
  • 受動態でなく能動態で書くべき理由
  • …その他…

 
また、とくにデベロッパーにとって重要と思われるのは、APIのコードのコメントの書き方や、コマンドラインのシンタックスの良質なドキュメンテーション、などだ。

AtlassianやWordPress、Salesforceなどもスタイルガイドを公開しているが、基本的な要素を網羅している点ではGoogleがトップではないだろうか。

編者たちは、このスタイルガイドは生き物であり、今後変わるだろう、と言っている。また、たった一つの絶対に正しいスタイルガイド、というものはない、とも言っている。つまりドキュメントの書き方をめぐってMLA派とシカゴ派の口論が今後続いてもよいし、ぼくが本誌の記事を書くときに使っているAP Stylebookのファンがたくさんいても、構わないのだ。

〔訳注: 上図和訳–

できるかぎり使わないように

  • バズワードや技術的ジャーゴン
  • くだけすぎた書き方
  • “please note”や”at this time”のようなプレースホルダー的語句
  • ごたごたした長過ぎるセンテンス
  • すべてのセンテンスが同じフレーズで始まる（”You can”, “To do”など）
  • 今のポップカルチャーに言及すること
  • 顧客や競合他社/競合製品などをだしにしたジョーク

〕

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

GoogleがモバイルWebのデベロッパー資格認定事業を開始、4時間の試験を受けるのだ

Googleが今日（米国時間9/5）、モバイルのWebデベロッパーを認定する事業Mobile Web Specialist Certificationを立ち上げた。デベロッパーは、これまでどうやって学習したかにかかわらず、この認定により自分にモバイルWebの開発スキルがあることを、世の中に対して示せる。この事業は、Androidデベロッパーやクラウドアーキテクト、データエンジニアなど、Googleの既存の資格認定事業の一員になる。

試験は辞書参考書など持ち込み自由で、受験料は99ドル、インドでは6500インドルピーだ。さまざまなコーディング（プログラミング）の問題があり、最後に10分間の面接がある。面接では、試験の問題に対し自分が選んだ解の根拠や理由を述べる。制限時間は4時間で、最大三回までトライできる。問題の範囲は、Webサイトのベーシックなレイアウト、スタイリング、先進的なWebアプリケーション、パフォーマンスの最適化、キャッシング、試験とデバッグなどだ。

Googleはこの試験のための学習案内を提供している。これで、受験勉強をしよう。

試験に合格したらバッジをもらえるので、それを履歴書やソーシャルメディアのプロフィールなどに表示できる（資格証明のため）。説明には、バッジはGoogle+のプロフィールでも使える、と書いてあるるが、いちいちそれを書く理由がよく分からない。もちろんこれは、いわゆるデジタルバッジではない。主な目的は、求職の際などに自分のスキルを強調するためだ。まだGoogle自身のテストを経ていない事業だから、この資格が求職の際の本人評価にどんな影響を及ぼすか、それは現時点ではまだ分からない。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Kafkaクラスターの自動ロードバランシングツールCruise ControlをLinkedInが発表

今日（米国時間8/28）サンフランシスコで行われたKafka SummitでLinkedInが、KafkaのクラスターのためのロードバランサーツールCruise Controlを発表した。

LinkedInが開発したオープンソースのメッセージストリーミングツールKafkaは、それを使えば、ネットワーク上で大量のデータをアプリケーション間でリアルタイムに送受するタスクが簡単にできる。Cruise ControlのプロジェクトをリードしたソフトウェアエンジニアJiangjie Qinによると、Kafkaは今、ほとんど必須のツールになっているので、今LinkedInには専用のサーバーが1800台、それらが…つまりKafkaが…一日に2兆あまりのトランザクションを動かしている。

これだけの量であれば当然、Kafkaのクラスターを正常に動かし続けることはユーザーの企業にとってミッションクリティカルであり、そこで今年早期にチームは、クラスターの異状を見つけるツールを作ろうとした。そしてそのツールは、既定の一連のルールに従ってクラスターを自動的に構成し、適正な数のリソースを使用し、不具合を自己修復して動き続けるようにする。そのツールが、Cruise Controlになった。

Cruise Controlを作る前には、クラスターがダウンするたびにそれを手作業で再構成しなければならず、しかもQinによると、再構成に不正があると将棋倒しのようにほかのクラスターたちに悪影響が及ぶ。若干の人間の監視のもとに、マシン自身にクラスターの管理をやらせれば、その過程が大幅に単純化され、成長するネットワークのニーズに合わせてクラスターの修復作業のスケーリング（規模拡大）も可能になり、技術者たちが手作業でやっていたときに比べると仕事は大幅に効率化される（人力では不可能なほどに）。

Qinの説明によると、それらはロードバランシングの問題に帰結する。クラスターは、他のクラスターに迷惑をかけずに、正しい数のリソースで動いているか？　彼によるとこの問題はさらに、よくある構成上の問題を見つけ、ひとつひとつのクラスターに適正な目標を適用することに帰結する。人間でなく機械なら、クラスターのニーズを素早く評価し、一連の一般的な構成および目標と比較対照し、正しいものを選ぶ。

Cruise Controlはその際、この最適化プランでよろしいか？と人間に尋ねる。

なぜそんなツールが、もっと前からなかったのか、それについてQinは、技術者の数を最近増やすまでは、そっちにリソースを回す余裕がなかった、と答えた。

クラスターの構成とリソースの使用量を機械にチェックさせる今回のソリューションが完成するまでに、約半年を要している。同社はこのツールをオープンソースでリリースし、Kafkaクラスターのロードバランシングを改善するだけでなく、そのほかの分散システムにも同じロードバランシングの原理を適用できるようにしたい、と考えている。いろんなユースケースで、便利に使えるはずだ、とQinは述べている。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

サーバーレスアプリケーションの周辺にもスタートアップエコシステムが育ちIOpipeは$2.5Mのシードを獲得

今や、サーバーレスアプリケーションが大いにもてはやされている。コンテナのことをどこかへ置き忘れて、AWSのLambdaやAzureのFunctionsのようなサービスに夢中になってる企業もある。そこで当然ながら、これらのサービスのまわりに自然発生的に新たなエコシステムが育っていく。今日（米国時間8/14）ベータを脱（ぬ）けたIOpipeは、AWSのLambdaサービスのアプリケーションの、オペレーションを助けるプラットホームだ（現状はもっぱらモニタリングを提供）。

シアトル生まれの同社は今日、250万ドルのシードラウンドを発表した。主な投資家はMadrona Venture Group, NEA, そしてUnderscore VC、全員、インフラストラクチャの分野で経験豊富な連中だ。

IOpipeの協同ファウンダーAdam Johnson(CEO)とErica Windisch(CTO)も、この分野のベテランで、以前はDockerやMidokuraにいた*。AdamはMidokuraの最初の社員、EricaはDockerのセキュリティチームを作った。両者は最近、Techstarsのニューヨークの育成事業を卒業した。〔*: 関連記事〕

IOpipeの基本コンセプトはきわめて単純明快、Lamdaで動くアプリケーションのインサイトをデベロッパーやオペレーションのチームに提供することだ〔今はオペレーション主体〕。そのほかのサーバーレスプラットホームにも、今後対応していく。ユーザーは、得られたインサイトに基づいて、バグをつぶしたり、メモリリークを直したりしていく。このサービスを有効にするためにデベロッパーがやることといえば、使用するサーバーレスのファンクションをIOpipeのコードでラップするだけだ。するとそれらのファンクションの一般的な性能測度がダッシュボードにリアルタイムで表示される（右図）。このサービスはサードパーティサービスの呼び出しも計測するから、AWSのS3やDynamoDBなどに関しても、いろいろ分かる。

Johnsonによると、同社の顧客はスタートアップとエンタープライズの両方を含む。これはもちろん、Lambdaの顧客の構成を反映している。“毎週、おーこの会社もLambdaを使ってるのか、という意外性の経験をする”、と彼は言う。1年前はアーリーアダプターがほとんどだったが、その後はLambdaを実験的に使う企業がどんどん増えて、そのプラットホーム上でプロダクションのワークロードを動かしている企業すらある、ということだ。

同社は今、社員が8名だが、新たな資金で緊急に増員が行われるだろう。今後の計画としては、機能をもっと増やすことと、現状のプラグインアーキテクチャを活かして、今後は今のオペレーション偏重から、デベロッパーにも直接奉仕する方向へと、機能を多様化していきたい。“これまで力を入れてきたのは、モニタリングのための最初から決まっているような機能集合を実装することで、もっぱら、アプリケーションのスケーラビリティと安定性を確認することを重視してきた”、とJohnsonは語る。しかしそのプラグインアーキテクチャにより、今後機能を増やしていくことが比較的容易にできる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

マイクロソフト、Windows 10 Pro for Workstationsを発表

本日（米国時間8/10）Microsoftは、Windows 10の新しいバージョンを発表した。ハイエンドのハードウェアを使って企業の基幹システムを扱うプロフェッショナルユーザーを対象としたシステムだ。噂通り、Windows 10 Pro for Workstationsは、Microsoftのサーバーグレードのファイルシステム（Resilient File System）を備え、永続メモリ（NVDIMM-N）やSMB Directによる高速ファイル共有に対応し、最大4 CPU、メモリ6 TBのハイエンドハードウェアを利用できる。

名前が示すように、焦点はハイエンドのハードウェアであり、このWindowsバージョンがIntel XeonおよびAMD Opteronの各CPUに対応していることを意味している。標準バージョンのWindows 10は最大2 CPU、メモリ2 TBまでしかサポートしていないので、新バージョンによって、最上位クラスのワークステーションのユーザー（およびそのためのハードウェアを作ろうとしていたOEM）は、より大きなパワーを活用できるようになる ―― 永続メモリを組み合わせればさらに強力だ。

ReFS（Resilient File System）は、データの復旧と耐障害性を強化したファイルシステムだ。巨大な容量を扱うことが可能で、ドライブの1つに不具合が生じた時に自動的にエラーを修復する。Microsoftの標準NTFSシステムで扱えるボリュームが最大256 TBなのに対して、ReSFは理論上最大4.7ゼタバイト（10億テラバイト、8 Kビデオ800万年分に相当する ―― 近々これを必要とする人はいないだろう）のボリュームを扱える。

さらにユーザーは、データをSMB Direct経由でネットワーク上の他のユーザーと共有できる。SMB Directは、Remote Direct Memory Access機能を使って遅延の少ない高速ファイルアクセスを可能にし、 ローカルCPUをほとんど使用しない。この機能はWindows Server 2012の公開以来、MicrosoftのサーバーOSで利用することができるが、動作には適切なネットワークアダプターが必要になることは注意しておくべきだろう。

Windows 10 Pro for Workstationsは、今秋のFall Creators Updateの一部として公開される予定。

[原文へ]

（翻訳：Nob Takahashi / facebook ）

視覚障害者のテクノロジー利用を拡大する

テクノロジーは、世界2億8500万人の視覚あるいは視力障害者にとって生活の中心をなす ―― ただし、使い方を知っていれば。視覚・視力障害者の支援団体、LightHouse for the Blind and Visually Impairedのアクセステクノロジー担当ディレクター、Erin Lauridseに話を聞いた。

Lauridsenの役目は、視覚障害者が「生活に必要なテクノロジーの利用方法を知る」手助けをすることだと、本誌のBullishシリーズ最新回のインタビューで私に話した。支援はコンピューターリテラシーやスマートフォンの利用からスクリーンリーダー、拡大機能といった補助機能の使い方まで多岐にわたる。

彼女はGoogle、Uber、Lyft、FacebookなどのIT企業のユーザーテストに協力して、「すでに存在するものと今作られているものが、視覚に障害のある人たちでも等しく利用できること」を確認しているとLauridsenは言った。

しかし、米国で法律上失明している人たちの失業率は70%だ。この統計データは1970年代から更新されていないが、今も数値は高いとLauridsenは言う。IT業界にどの程度の失明者や視力障害者がいるのかわからないが（IT企業は通常このデータを報告しておらず、プライバシーの懸念もある）、おそらく極めて少ない。

視覚障害者が就職するうえでの障壁のひとつはリテラシーだとLauridsenは言う。点字など視覚障害者対応の資料が利用できなければ、リテラシーの格差は人生のごく最初の段階から生まれる。

「そうした教育を受け仕事の世界に入ると、ほとんどが認識の問題だ」とLauridsenは言う。「雇用担当者にとってあなたが初めて会う障害者であれば、面接の間中どうやってここまで来たのか、どうやって靴紐を結ぶのか気になってばかりで、おそらくあなたのスキルには集中していない。つまりは認識の問題がある」。

もう一つの問題は、デベロッパーツールのアクセシビリティ対応だとLauridsenは言う。彼女には素晴らしいプログラマーである盲目の友人が何人かいるが、デベロッパーツールがアクセシビリティ対応していないために就けない職があるという。

Lauridsenが最終的にIT企業に望むのは、アクセシビリティを「プロセスの最後にある小さなコンプライアンス用のチェック欄」以上に考えることだ。彼女の願いはアクセシビリティが「ものづくりの開発サイクルにとって重要で必要な部分になること。なぜなら障害のある人たちはハッカーでありイノベーターであり、それが私たちのふだんしていることだから。」

[原文へ]

（翻訳：Nob Takahashi / facebook ）

Android Oの最後のデベロッパープレビューが出た、アプリの最終テストが主な目的

Googleが今日（米国時間7/24）、Android Oの四度目で最後のデベロッパープレビューをリリースした。Android Oは同社のモバイルオペレーティングシステムの最新バージョンだ。予想されたように、今回はもはや大きな変化はなく、Googleによると、計画どおり今夏の終わりには正式版がリリースされる。今夏の終わりとは9月22日のことらしいから、まだ間があるが、これまでのペースはAndroid Nougatのときと酷似しているから、最終リリースは8月ではないかな。

Android OのAPIの最終確定が三度目のプレビューだったから、今日のアップデートは微修正と安定性の向上がメインだ。Android SDKの主な部分とツール、そしてAndroid Emulatorは今後数日内にバージョンがやや上がり、Android Support Library(v. 26.0.0)は今や安定とみなされているが、前と同じく今回の焦点は、本番バージョンがユーザーの手に渡るまえにデベロッパーが自分のアプリをテストできることに置かれている。

ユーザーとデベロッパーにとって、Androidのこの新バージョンは、全体的に通知のサポートが改良され、またピクチャ−・イン・ピクチャ−やオートフィルなどがサポートされる。電池の使用を最適化する機能も、新たに導入された。これらの変化はどれも地味だが、Android上のデベロッパーは自分のアプリをできるかぎり早くテストしたいだろう（新しい機能を使う気はなくても）。ただしそのためには、Androidアプリを書くためのGoogleのIDE Android Studioを、最新バージョンにアップデートしなければならない。

Google Playのストアはすでに、最新APIに対応するアプリも受け付けている。

Android Oのデベロッパープレビューは一般ユーザーがネットからアップデートすることも可能だが、ただし公式リリース前のソフトウェアを動かすためには、勇気が必要だ。対応機はGoogleのPixel, Pixel XL, Pixel C, Nexus 5X, Nexus 6P, そしてNexus Playerだ。登録はここから。

昨年出たAndroid Nougatは、今ではAndroid全体の11.5%のシェアを持っている。Androidのニューバージョンはつねに採用のペースが遅いが、Pixelはすでにかなり出回っているから、デベロッパーもAndroid Oのバスに早めに乗った方が、良いのではないだろうか。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

サービスメッシュ型コンピューティングの普及に賭けるBuoyantがシリーズAで$10.5Mを調達

Buoyantは、TwitterのインフラストラクチャエンジニアだったWilliam MorganとOliver Gouldが作った企業だが、同社は今日（米国時間7/11）、シリーズAで1050万ドルを調達したことを発表した。このラウンドをリードしたのはBenchmark Capital、これに、女性を中心とするTwitterの新旧役員グループ#Angelsと、これまでの投資家A Capital Ventures, Data Collective, Fuel Capital, SV Angel, そしてWebb Investment Networkが参加した。BenchmarkのPeter FentonがBuoyantの取締役会に加わるが、彼は数か月前にTwitterの取締役会を降りたばかりだ。

Buoyantは誰もが知ってる名前ではないが、オープンソースのLinkerdプロジェクトを作った企業だ。今年の初めにCloud Native Computing Foundationの一員となったこのプロジェクトは、いわゆる“サービスメッシュ”(service mesh)と呼ばれる、新しいインフラストラクチャツールの中で、たぶんもっとも人気のあるシステムだ。サービスメッシュ（サービスの網）とは、今日のアプリケーションを構成するさまざまなサービスを互いに通信/コミュニケーションさせるための、インフラストラクチャ層だ。たとえば、Kubernetesなどのコンテナオーケストレータの上で動く複雑なアプリケーションは、たぶん何百ものさまざまなサービスで構成されているだろう。これらのサービスは、静的とはとても言えないネットワークの上で、互いに通信できなければならない。LinkerdやIstioのようなサービスメッシュは、ロードバランシングとダイナミックルーティングを組み合わせて、それらのサービス間の通信を確保する。なお、Istioは、最近発表されたGoogle/Lyft/IBMのコラボレーションだが、今ではLinkerdと共用できる。

現在のLinkerdのユーザーには、Ticketmaster, Apprenda, NextVR, Houghton Mifflin Harcourt, Monzo（イギリスの銀行スタートアップ）などがいる。

“ソフトウェア産業の全体がクラウドコンピューティングへ移行すると、アプリケーションの作られ方や運用のされ方が大きく変わる”、 BenchmarkのFentonは今日の発表声明でこう述べている。“Buoyantによるサービスメッシュの導入は、マイクロサービスのコンポーネントやクラウドネイティブなソフトウェアと同じぐらい基本的な成分になる可能性がある。ネットワークプログラミングにとって、TCP/IPがそうであったように。そしてLinkerdが昨年思い切ってオープンソースを採用したことによって、そのニーズが企業にとって喫緊のものであることが明白になってきた”。

BuoyantのCEO William Morganによると、サービスの収益化についてはまだ何も決めていない。今度の資金は、エンジニアと製品開発部門の増員に充てられる。今社員は13名だが、エンタープライズユーザーにはすでに有料サポートを提供している。Linkerdを中心とするエコシステムを築くことが先決で、収益化云々に関心を向けるのは時期尚早である。“ある時点で方向を変えてお金を稼がなければならないけど、短期的にはオープンソースの採用が関心の中心になる”、と彼は語る。

企業のアプリケーションの開発が“クラウドネイティブ”型へ移行していくに伴い、Linkerdのようなプロダクトへのニーズもたちまち明らかになってくると思われるが、現時点ではまだ時期が早く、とくに大企業は歩みが遅い。しかしMorganによれば、アーリーアダプタたちの多くは大企業よりむしろスタートアップたちである。“彼らは今すでにクラウドネイティブのスタックへ移行しつつあるし、それには正当な理由がある”、とMorganは語る。“彼らは自分たちのアプリケーションをこのクラウドモデルで運用したいと願っている。それなら、ハードウェアのコントロールがほとんど不要だからだ”。

DockerとKubernetesがこのパズルの一片を解いたが、往々にして一つのソリューションが新しい問題をもたらすのだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

ConfluentがKafkaによるメッセージングシステムの長年の夢、‘正確に一度だけ’をついに実現

オープンソースの分散メッセージストリーミングツールApache Kafkaの商用化サービス（リアルタイムデータストリーミング）を提供しているConfluentが今週、Kafkaのユーザーにとって嬉しい機能を発表した。それは、Kafkaを使ってメッセージを、“正確に一度だけ”送る能力だ。

それのどこがすごいのか、門外漢には分かりづらいが、Kafkaのような高速メッセージングツールを使っている人たちにとっては、長年の見果てぬ夢だった。コミュニティの人たちは、実現不可能とも思っていた。

通常、メッセージを送る側は、それが届いたという受信確認を待つ。しかしConfluentのCTO Neha Narkhedeによると、Kafkaのような分散メッセージングシステムでは、途中で問題が起きることがある。コンピューターのエラー、ネットワークの障害、などなど。しかしたとえば金融関連のトランザクションなどでは、メッセージは確実に一度だけ送られてほしい。二度以上は、ノーだ。

多くの人びとが“正確に一度だけ”は達成不可能な目標と考えているのは、それを実現するためのスピードと正確さのトレードオフが大きすぎるからだ。しかしNarkhedeによると、同社はこの問題に大量の技術者をつぎ込み、1年がかりでやっと、長年探し求めていた解に到達した。

それを実現している技術的細部はきわめて多い。そしてNarkhedeによると、随所に技術的なトレードオフもあるが、でもみんなが考えるほど多くはない。というか、彼女によると、同社はこの問題を解決しただけでなく、メッセージのスピードを犠牲にすることなくそれを達成したのだ。

“正確に一度だけのモードでも、パフォーマンスのオーバヘッドはほとんど無視できる。そして通常モードでは、パフォーマンスは従来より向上した”、と彼女は語る。

その新しいリリースは、通常の利用で20%速くなり、“正確に一度だけ”の機能を使うと3〜10%のスピードペナルティが生じる。彼女によると、正確に一度だけではつねに多少のオーバヘッドは生ずるが、今後数か月の努力でそれをできるだけなくしていきたい、という。

彼女によると、この機能を眉唾で見ている人がまだ多い。頭がおかしいんじゃないか、と言う人もいる。長年、誰も解決できなかった問題だ。実際にそのとおり動くことを、どうやって確認するのだ？　…彼女はコミュニティが抱（いだ）いている疑念を、このように表現した。

“何千時間もテストをした。パフォーマンスにはとくに気をつけた。Kafkaのアーキテクチャを抜本的に再検討し、全体的な高速化を図った。一年がかりで、やっと使えるようになった”、とこれまでの努力を彼女は説明する。

Confluentは3月に5000万ドルを調達し、調達総額は8000万ドルになった。Kafkaは最初、LinkedInで作られ、その後オープンソースのコミュニティへ移った。Confluentは、2014年に創業された。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Magic Wormholeは、ファイルを安全簡単に送る賢いツール

数百メガバイトのファイルを海外の同僚や友達に送る必要があるとき、選択肢に不足はない。実際、方法は掃いて捨てるほどあるがそれぞれ問題を抱えている。魔法の言葉をいくつか言うだけで、アップロードもウェブインターフェースもログインもなしにファイルを送れたらいいと思わないだろうか？ Brian Warnerという開発者が作ったMagic Wormholeは、まさしくそれをするための賢い方法だ。

あなたと友達が二人ともオンラインで、最低限のソフトウェアがインストール済みだと仮定すると、手順は超簡単だ。

  • コマンドラインで、送りたいファイル名を付けてwormholeを呼び出す（GUIはまだない）
  • サーバー（公開またはプライベート）から、シンプルで発音可能なワンタイムパスワード（8-horse-happy、vile-4-content、など）が送られてくる
  • それを電話なりチャットなりで友達に伝える
  • 相手がwormholeコンソールでそのパスワードを入力すると、鍵の交換が行われる
  • 両者のコンピューター間で暗号化されたダウンロードが始まりパスワードは破棄される

わかっている。これは例えばSlackにファイルをドラッグアンドドロップするよりちょっと複雑だと思うかもしれない。しかし、サードパーティー製ツールや中間のサーバー、ログイン名とパスワード、短縮リンクの作成、一時的にファイルを「公開」にする心配、パーミッションのなどあらゆる面倒が排除される。

実際、正しく使えば何よりもシンプルだ。スクリプトか何かを作ってデスクトップに置いておけば、ファイルをドロップするとパスワードがポップアップして、それを相手に教えるだけでいい。ファイルは直接、安全に送られて、二度と心配する必要がない。

電話でこう言われたところを想像してほしい、「じゃあそのファイルを送るよ」。それってDroboxのリンク？ 何かにログインしなくてはいけない？ Gmailが巨大な添付ファイルをスキャンするのを待つ？ それとも ――〈身震い〉―― FTP？ その代わりに、「crocodile mighty 7」としゃべるだけで、おしまい。私なら大喜びだ。

なぜ私が、一ファイル転送システムにこれほど入れ込んでいるのかわからない。ただ、素晴らしいと思うだけだ。

GitHubのプロジェクトページへ行けば、必要なツールをダウンロードしたり、コードを書いて貢献できる。

[原文へ]

（翻訳：Nob Takahashi / facebook ）

アプリケーション用検索エンジンのElasticがOpbeatを買収してアプリケーションパフォーマンス管理に進出

今日（米国時間6/22）、ロンドンで行われたElasticのカスタマーイベントで同社が、アプリケーションのパフォーマンス管理(application performance management, APM)をSaaSで提供しているOpbeatを買収したことを発表した。買収の額等は公表されていない。Opbeatの15名の社員は全員すでに、Elasticのチームに合流している。

OpbeatはJavascriptで書かれているアプリケーションをモニタするが、それだけでなく本番アプリケーションの問題点を直接、その原因であるソースコードに対応付ける。そのためコードの森をハントして問題領域を見つける努力をしなくても、容易に問題をフィックスできる。

Elasticがいちばんよく知られているのは、同社の検索プロダクトElasticsearchだろう。このオープンソースの検索ツールは、Wikipedia, Yelp, eBayといった大物サイトが利用している。最近同社は単なる検索から一歩進んで、アナリティクスにも手を染めた。主にログデータが対象だから、Splunkなどの既存サービスともろに競合する。昨年Elasticは、同社のすべてのプロダクトを揃えたプラットホーム、Elastic Stackを立ち上げた。

ElasticのCEO Shay Banonは今日の買収を戦略的な視点で見ている。すなわちそれは同社に、単なるログデータのサーチを超えて、データを生成しているアプリケーションの内部へのインサイトを与え、パフォーマンスの劣化の原因を示唆する。それによりElasticの競争力が強化される、とBanonは述べる。

OpbeatのCEOだったRasmus Makwurthによると、Elasticに加わったことによってプロダクトのロードマップを加速でき、Elasticプラットホームの幅広いリソースを利用できる。“うちはかなり前からSaaSのプラットホームとして、アプリケーションのインサイトをデベロッパーに提供してきたが、顧客にアプリケーション全体のインサイトを与えることができなかった”、と彼は説明する。Elasticへの参加で彼の企業は、検索ツールや、アナリティクス、ログデータの視覚化などをElasticのプラットホームで利用でき、同社のビジョンを大きく拡大できる、という。

Opbeatの社員はすでにElasticに加わり、Elasticのチームと共に、既存のSaaSアプリケーションのオンプレミス化に取り組んでいる。Banonによると、Opbeatのクラウド体験がElasticのクラウド提供物の拡大に寄与するだろう、という。

クラウドネイティブなアプリケーションとその技術をオンプレミス化する仕事は簡単ではないが、両社の展望では数か月後のリリースを目指している。なお、Opbeatのプロダクトも前からElasticsearchを使っているが、Banonによると、これまでのようにプロダクトを使っていることと、それがスタックの一部になることは、全然別の話だ。そしてクラウドとオンプレミスの両方で新しい会社を仲間に加えていくためには、相当な技術的努力を要する、と。

今年初めにCiscoが、IPO直前のAPMベンダーAppDynamicsを37億ドルで買収した。Banonは今日の買収価額を公表しないが、あれよりずっと少ないね、とジョークを言った。

Opbeatは2013年にデンマークのコペンハーゲンで創業され、これまで約280万ドルを調達している。良い買い物と言えるだろう。同社はデンマークで仕事を続ける。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Facebookは同社社員にAdobeのCreative Cloudを使わせるためのIT管理ツールをオープンソース化、Facebook固有色はない

Facebookでは、IT部門のことを“IT”と呼ばず、“エンタープライズエンジニアリングオーガニゼーション(enterprise engineering organization)”と呼ぶ。Facebookのクライアントプラットホーム担当エンジニアNick McSpaddenによると、Facebookぐらいの大きさの企業になると、ITはベンダーのプロダクトのボタンを押すだけの仕事ではなくなるからだ。そしてそのことを強調するかのように同社は今日（米国時間6/21）、AdobeのCreative Cloudのプロダクトを社員に使わせるための内部的IT管理サービスをオープンソースにした。

Facebookのそのエンタープライズ〜〜オーガニゼーションは今、3万台近くのコンピューターと4万近いモバイルデバイスを管理している。ラップトップとデスクトップの多くはOS Xだが、Windowsマシンも約8000台ある。“組織が大きくなりすぎると、もう、ベンダーからターンキーのソリューションを大量に買い付ければすむ、という状態ではなくなる”、とMcSpaddenは強調する。そこでオーガニ〜〜のチームは、たくさんのオープンソースツールを使って、必要に応じて独自のソリューションを構築することになる。McSpaddenの説によると、ベンダーが彼らのソリューションを作るときには、メインストリームのユースケースを想定しがちだが、でもつねにエッジケースはある。そしてFacebookぐらいの巨体になると、エッジケースはどんどん増えてITチームの生産性を干上がらせる。

今回Adobeのプロダクトに社員がアクセスするためのツールをオープンソースにしたのは、至るところで使われているベンダーだし、ユーザー数も多いからだ。そのFacebookのスクリプトを一般企業が使うと、Adobeのサブスクリプションへの新しいアカウントを企業レベルの裁可のもとに作成することが容易にできるし、特定のユーザーに特定のツールへのアクセスを与え、あとでそのアクセスを必要に応じて取り去ることも簡単にできる。

McSpaddenによると、この新しいツールがオープンソースになったことをAdobe自身も喜んでおり、またそのコード中にはFacebook固有の部分は何一つない、と強調した。“Facebookだけでしか使えないものを公開する気はない。現状のままで誰にでも使えるものをリリースしたい”、と彼は語る。

コードはGitHub上にあり、McSpaddenは曰く、Facebookは外部からのコントリビューションを大歓迎する、と。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

UdacityのナノディグリーにReactプログラミングが加わる、４か月で499ドルはお買い得

労働者/労働市場における慢性的なスキル・ギャップを解消したいと願うUdacityは、短く縮合したコースによって今日的な技能を短期間で習得し、生徒たちがより良い被雇用機会を得られるよう、努めている。同社のコース、通称“ナノディグリー(Nanodegrees)（微小学位）は、VR（仮想現実）やロボット工学、ディープラーニングなどの重要な技術的スキルとともに、非技術的なスキルも教えている。今日（米国時間6/20）Udacityは、その最新のコースReactプログラミングを立ち上げた。

ReactはWebアプリケーションのフロントエンドの制作に使われるJavaScriptライブラリで、このところ凄（すさ）まじく人気がある。AirbnbやNetflix、Facebookなどでも使われているから、テクノロジー企業で仕事をしたい人は、ぜひ身につけるべきスキルだ。

同社のナノディグリーの多くがそうであるように、Reactのコースもパートナーがいる。それはReact Trainingといって、企業を対象にネット上や実際の教室でReactライブラリの一から十までを教えているグループだ。

Reactへの関心は近年うなぎのぼりだ。このグラフはGoogle検索の検索語登場頻度。

所要時間4か月、一学期のみのこのコースは、三部構成で、各部でプロジェクトに取り組み、生徒は自分のGitHubアカウントを持つから、それを未来の雇用者に示せる。

学び方はReact Trainingのふつうのコースと同じで、Reactの基礎を頭に叩き込んでから、便利ツールReduxとReact Nativeを使ってReactプログラミングの実践を開始する。

受講料は499ドルだが、今の高等教育の時間単価よりずっと安いだろう。しかもこのお値段で生徒にはメンターが付く。専用フォーラムもあるし、Slackの専用チャネルも使える。Udacityの基本的な考え方は、生徒が自分にとって難しい箇所にぶつかったら、必ずエキスパートや同級生に助けてもらえる学習環境を確保することだ。言い換えると、絶対に挫折・落ちこぼれしないコースの維持だ。

UdacityとのパートナーシップはReact Training自身にとっても良い、と同社のTyler McGinnisは説明する: “Udacityには、コードをレビューしたり生徒にメンターを提供するリソースがある。うちは、たった3人だからね”。

しかしネットを利用する教育は、まだまだ、それをもっとも必要としている人たちの手から遠いところにある。そんな中でUdacityは、そのリーダーの多くが、状況を前へ進めるためには教育を単純にネット化するだけ（ネット上にプレゼンスがあるだけ）ではだめ、と自覚しているから、社会への貢献度が大きいだろう。

一般的大衆的普及を目指してUdacityのCEO Vish Makhijaniは、州や市町村の行政の理解と支援を仰ぎ、物理的なプレゼンスも構築している。たとえばネバダ州レノには、ネットでなく人力授業のための教室がある。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Atlassianが全デベロッパーツールをワンセットにしたAtlassian Stackを年会費制でローンチ

Atlassianが今日（米国時間6/13）、Atlassian Stackという、新しい会員制のサービスを立ち上げた。それは、同社がホストしているデベロッパーツールをすべてまとめたサービスで、会費は1000ライセンスにつき年額18万6875ドルだ。これにより企業の調達担当は仕事が楽になり、費用削減にもなる（一見、高いけど！）。個々のプロダクトの会員ユーザーになるよりも、Atlassian Stackの会員になるとデベロッパーツールのすべてを手早く利用できて簡単なのだ。

Stackにはこんなものがある:

  • データセンターバージョン: JIRA Software, Bitbucket, JIRA Service Desk, Confluence
  • サーバーバージョン: JIRA Core, HipChat, Bamboo, FishEye, Crucible, Crowd
  • アドオン: JIRAのPortfolio, JIRAのCapture, ConfluenceのQuestions, ConfluenceのTeam Calendars
  • 有料サポート

デベロッパーがAtlassianの上で仕事をするには、これで十分だろうが、ただしファイヤーウォールの内側で使えるもののみだ。Atlassianのツールのホストバージョンはないが、このようなバンドルに関心のある企業は、自社独自のデプロイをするところがほとんどだろう。

1000ライセンスの料金は一人あたりの月額で15ドル57セントになる。1万ユーザー以上もいる超大企業は、一人あたり月額が6ドル74セントになる。

Atlassian Stackに加えて今日同社はDevOps Marketplaceをローンチした。この新しいストアはAtlassianのユーザーに、200以上のアドオンとインテグレーションへのアクセスを提供する。現在のパートナーはAppDynamics, Splunk, そしてSauce Labsだ。Atlassianにはすでにマーケットプレースはあるが、この新作はDevOpsツールが中心だ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））