Developer | SEO-LPO.net

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）

Originのブロックチェーンによるマーケットプレース、UberやAirbnbのような中間搾取をなくせるか

【抄訳】
共有経済は、UberやAirbnbのような媒介者による、大量の労働収益の共有〔中間搾取〕に終わっている。そこで3800万ドルの投資を得たOriginは、次に主流になるべき二者間マーケットプレースはブロックチェーン上に分散化し、運転者と乗客や、ホストとゲストなどが直接結びつくことによって、20%以上もの高額な手数料を不要にすべきだ、と考えている。そのため今日（米国時間10/11）Originは、Ethereumのメインネット上にその分散マーケットプレースのプロトコルを立ち上げ、それにより、ユーザーとベンダーをスマートコントラクトで結びつける中央集権的な企業を不要にしようとしている。

“今のマーケットプレースは、利益をメンバーに分配していない。利益はファウンダーとベンチャーキャピタリストの方に溜まっていく”、とOriginの協同ファウンダーMatt Liuは語る。彼は、YouTubeの三人目のプロダクトマネージャだった。“このような非集権的マーケットプレースを構築することによって、マーケットプレースをpeer-to-corporate-monopoly-to-peer（ピア・ツー・独占企業・ツー・ピア）ではなく、本当のpeer-to-peer（ピア・ツー・ピア）にしたい”。

Originのマーケットプレースを利用するユーザーには、そのプロトコルを使うためのトークンが発行され、早期の利用者にはインセンティブを提供して、マーケットプレースの‘販売促進’とする。

Originの社内マーケットプレースDApp

今日ベータでオープンしたメインネットでは、Originが独自のベーシックな分散化アプリを提供し、それはブロックチェーン上のCraigslist（三行広告、classified adの大手）のように運用される。ユーザーはプロフィールを作って自分のEhereumウォレットに、MetaMaskのようなサービスから接続する。そして製品やサービスのリストを閲覧して互いにメッセージを交わし、手数料不要でスマートコントラクトによる商談を締結する。レビューや苦情などは、Originの仲裁人に送る。

デベロッパーは、Originのプロトコルを利用して自分自身のマーケットプレース…犬の散歩、家の掃除、ライドシェア、などなど…を構築できる。その場合、手数料を徴収してもよい。Originによると、それでもブロックチェーンの利用により、手数料は相当安くできるはず、という。

【後略】

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

GoogleがChromeのエクステンションを安全にするために来年から制限を厳しくする

Googleが今日（米国時間10/1）、Chrome側からのエクステンションの扱い方がいくつか変わったことを発表した。中でもとくに、多くのパーミッションを要求するエクステンションへの対応が変わり、さらに、デベロッパーがChrome Web Storeで公開するエクステンションには、新たな要求が加わった。

今や公然の事実として、どんなブラウザーでも、ユーザーデータにアクセスするための仕掛けを悪者のデベロッパーが仕込むのは、エクステンションの上であることが多い。Googleは長年、ストアに並ぶ前に悪意あるエクステンションを自動的に検出する努力を積み重ねてきた。またブラウザー本体にもいくつかの改良を加え、エクステンションがいたずらできないようにしてきた。今回は、これらの努力をさらに数歩前進させる。

Chrome 70からは、ユーザーが制限サイトのリストを作り、それらのサイトにはホストアクセスができないようになる。デフォルトでは、ほとんどのエクステンションが、ユーザーが訪ねるどんなWebサイトでも見たり操作したりできるから、この制限は重要だ。ホワイトリスト（無害者のリスト）はメンテナンスが困難だから、エクステンションがクリック後の現在ページにのみアクセスできるようにも指定できる。

Googleはこう説明している: “ホストのパーミッションにより、何千もの強力でクリエイティブなエクステンションのユースケースが可能になったが、それらはさまざまな誤用に導きがちだ。それらの中には、悪意的なものもあれば、意図せざるものもある。それらのエクステンションは、Webサイト上のデータを自動的に読んだり変えたりするものが多いからだ”。

Googleが“強力なパーミッション”と呼ぶものをリクエストするエクステンションはどれも、今後はより詳細なレビュープロセスを経なければならない。さらにGoogleは、リモートでホストされているコードを使うエクステンションを仔細に調べる。そのコードが、いつ変えられたか、それとも変えられてないか、分からないからだ。

パーミッションに関してGoogleは2019年に新しい仕組みを導入し、より狭いスコープのAPIにより広いパーミッションの必要性を減らし、またエクステンションに対するユーザーのコントロールを大きくして、エクステンションに対するアクセスの許可をより厳しくできるようにする。2019年からGoogleは、Chrome Web Storeのデベロッパーアカウントへのアクセスに、二要素認証を必須にする。悪者がデベロッパーのアカウントを乗っ取って、ハックされたエクステンションをストア上に公開したりできないようにする。

これらの変更はまだ数か月先だが、今日（米国時間10/1）からデベロッパーは、難読化コード(obfuscated code)の公開ができなくなる。難読化コードだから悪い、とは言えないが、デベロッパーがJavaScriptのソースコードをわかりにくくするために利用することもあり、そうするとレビューする側にとって、そのコードが一体何をしているのかわかりづらくなる。そして悪役エクステンションの70%は、難読化コードでGoogleの目をかいくぐろうとしている。Googleは、既存のエクステンションでも、難読化コードで書かれているものは90日以内にすべて削除する。

ただし、ホワイトスペースやコメントや改行を省いてコードを小さくするのは、許される。

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

Chefの標準ツールと最新ツールがMicrosoft Azureへ深く統合、安心のマイグレーションを担保

DevOpsオートメーションサービスChefが今日（米国時間9/25）、Microsoft Azureとの新しい統合をいくつか発表した。その発表は、フロリダ州オーランドで行われているMicrosoft Igniteカンファレンスで行われ、企業がレガシーアプリケーションをAzureへ移行する際の支援に焦点が絞られた。それに伴い、Chef Automate Managed Service for Azureのパブリックプレビューや、ChefのコンプライアンスプロダクトInSpecをMicrosoftのクラウドプラットホームに統合する例などが提示された。

Azure上のマネージドサービスとなるChef Automateは、コンプライアンスとインフラの構成の、管理とモニタリングを単一のツールでできる能力をopsのチームに与え、またデベロッパーは、Chef AutomateとChef ServerをAzure Portalから容易にデプロイし管理できる。それは完全なマネージドサービスであり、初めてのユーザー企業でも30分で使えるようになる、と同社は主張している。この数字には、やや宣伝臭があるかもしれないが。

構成を変えるときにはAzure上のChefユーザーは、AzureのコマンドラインインタフェイスであるAzure Cloud ShellでChef Workstationを使える。WorkstationはChefの最新の製品のひとつで、構成の変更を即席でできる。また、Chefが管理していないノードでも、対応できる。

コンプライアンス堅持のために、ChefはセキュリティとコンプライアンスツールInSpecのAzureとの統合をローンチした。InSpecは、MicrosoftのAzure Policy Guest Configuration（誰だ？こんな名前をつけたやつは！）と協働し、それによりユーザーはAzure上のすべてのアプリケーションを自動的に監査できる。

Chefのプロダクト担当SVP Corey Scobieはこう語る: “Chefは企業に、彼らが確信を持ってMicrosoft Azureに移行できるためのツールを提供する。ユーザーは単純に自分たちの問題をクラウドへそっくり移すのではなく、状態や状況をよく理解したうえで移行を行なう。事前に構成やセキュリティの問題を検出できるから、移行後の成功が確実になり、正しい、そして着実なペースで、移行できる実力を企業に与える”。

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

GoogleやFacebookも使っているデザインツールFramer Xの魅力は開発工程の上流下流への柔軟な対応

デザインツールはどの企業にとっても、ますます重要になっている。今日はそのレースに、新人が入ってきた。

新人とは言ったが、Framer Xは三年前にできたFramerの改造バージョンであり、ファウンダーのKoen BokとJorn van Dijkはさらにその前の2011年に、デザインソフトのSofaをFacebookに売っている。そしてFramer Xは、Reactベースのリッチなデザインツールで、どんなデザイナーでもインタフェイス成分を描けて、それらを技術者のコラボレーションチームに送れる。

その鍵は、再利用性と忠実な再現性だ。Framer Xでは、技術者たちが今本番開発に使っている成分を送って、デザイナーたちはそこから仕事を始められる。逆にデザイナーはボタンやアイコンをデベロッパーにファックスで送るのではなく、その成分のSVGコードをデロッパーに送れる。

[Framer Xはベクターツール]

Framer Xではまた、ユーザーがFramer Xのストアで成分やそのほかのデザインアイテムをパッケージとして集め、デザインの過程でそれらに容易にアクセスできる。Framer XのFramer X Storeは一般公開されているので、たまにデザインをするような人が経験豊富なプロのデザイナーの作品をベースに仕事を始められる。

また、企業がその社内だけで使うプライベートなストアを、Framer Xの上に開ける。

Framer Xの使用料はユーザー一人あたり月額15ドルだが、企業のプライベートなFramer Xストアは、企業の規模などに応じて適宜課金される。

Framer Xの強敵といえば、InVision, Adobe, Sketchなどだ。

同社によると、現在の月間アクティブユーザーは約5万、企業ユーザーは200社だ。その中には、Google, Facebook, Dropboxなどもいる。資金はこれまで、Greylock, Foundation Capital, Designer Fund, Accel Europeなどから900万ドルを調達している。

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

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）

NvidiaがローンチしたTesla T4は最速のデータセンター用推論プラットホームだ

Nvidiaが今日（米国時間9/1）、データセンターにおける機械学習と推論のための新しいGPUを発表した。そのTesla T4 GPUs（TはNvidiaの新しいアーキテクチャTuringを指す）は、クラウドコンピューティングのメジャーなプロバイダーのほとんどが現在提供しているP4 GPUsの後継機種だ。Nvidiaによると、GoogleはT4 GPUsをクラウドプラットホームで採用する最初の企業のひとつだ。

Nvidiaによると、T4はP4よりも相当に速い。たとえば言語の推論では、T4はCPUを使うよりも34倍速く、P4より3.5倍速い。T4のピーク時性能は4ビットの整数演算で260TOPS、浮動小数点演算で65TOPSだ。T4は、標準的な75ワットのLow Profile PCI-eカードに載っている。〔関連記事〕

しかしもっとも重要なのは、Nvidiaがこれらのチップを、AIの推論専用に設計したことだ。NvidiaのVPで同社のTeslaデータセンター事業部のGM Ian Buckはこう語る: “Tesla T4が推論用としてこれほど効率的なGPUであるのは、Turingアーキテクチャの新しいテンソル・コアのせいだ。CEOのJensen Huangがすでに述べたように、そのTensorコアはゲームやレンダリングやAIにも有効に利用できるが、設計の前提は推論だ。トータルでこのチップには、320のTuting Tensorコアと2560のCUDAコアがある”。

Nvidiaは今回、新しいチップのほかに、同社のソフトウェアTensorRTの、ディープラーニングのモデルを最適化するアップデートをローンチした。この新しいバージョンには、TensorRT推論サーバーも含まれており、それはデータセンターの推論のための完全にコンテナ化されたマイクロサービスとして、既存のKubernetesインフラストラクチャにシームレスに接続する。

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

Atlassianがopsチームのためのインシデント管理ツールJira Opsをベータでローンチ

Atlassianが今日（米国時間9/3）、同社の旗艦製品であるJiraの新しいエディションの最初のベータと、opsのチームがインシデントを迅速効率的に処理できるための問題追跡ツールを発表した。

そのツールJira Opsは、OpsGenie, PagerDuty, xMatters, Statuspage, Slackなど他のツールをいろいろ統合している。多くのチームがすでに、自分たちのサービスがダウンするとこれらのツールを使っているが、Atlassianによると、現状では、その場しのぎ的な使われ方が多い。Jira Opsは、同じページ上の全員をまとめる糊になり、現在進行中のインシデントを可視化することをねらっている。

AtlassianがJiraを使って、その中核的なオーディエンスであるデベロッパーから逸れた方向へ脇道するのは、これが初めてではない。たとえばJira Service DeskとJira Coreは、もっと広いオーディエンスを対象としている。しかしOpsは、きわめて限定された層が対象だ。

Atlassianでソフトウェアのチームを率いるJens Schumacherはこう述べる: “Service Deskが、最初の一歩だった。そして、Jiraで対応できるそのほかの特定層を、探していた”。Schumacherによると、同社は社内のopsチームのためにこれまでたくさんのツールを作ってきたが、それらは主に、インシデントを追跡し管理するために必要な、いろんなピースを糊のようにまとめることが目的だった。Jira Opsはそんな糊的ツールを、正規のプロダクトにしたものだ。

しかし、Jira Opsを使うことはある意味で、パズルのピースがまた一つ増えることだ。でもSchumacherの主張では、プロセスを管理する単一の場所を作ることがねらいだった。“インシデントが起きたら、そのインシデントに関係のあるものをすべて見つけられる、センター的な場所へ行けばよい、…それがねらいだ”、と彼は語る。“そのページに誰がいて、誰がアラートされているかが分かる。必要と思えば、さらにもっと多くの人にアラートできる。Slackのどのチャネルでそのインシデントが議論されているか、も分かる”。

Atlassianの他のプロダクトと違うのは、Jira Opsのセルフホスティングバージョンを出す計画は今のところないことだ。その理由は、単純明快だ: ユーザーのインフラがダウンしたら、Jira Opsもダウンするかもしれない。…そうなると、そのダウンタイムを管理するツールがない。

Jira Opsは今、アーリーアクセスのベータとして無料で利用できる。バージョン1.0の立ち上げは、2019年の初期の予定だ。もちろんそのときには、料金体系も明確になっているだろう。

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

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）

Google Cloudが音声↔テキストAPIを大幅アップデート、WaveNetでより自然な音声を

Google CloudのText-to-SpeechとSpeech-to-Text APIが今日（米国時間8/29）、大量のアップデートを行い、サポートする言語を増やし、いろんなスピーカーからの自動生成音声を聴きやすくし、スピーカーの音声認識ツールを改良してテキスト書き起こしの精度を上げる、などの機能向上を導入した。

このアップデートにより、Cloud Text-to-Speech APIが一般的に可利用になった。

多くのデベロッパーにとっていちばん魅力的なのは、17の新しいWaveNetベースの音声が複数の新しい言語でローンチしたことだろう。WaveNetはGoogle自身の技術で、機械学習を使ってテキスト読み上げのオーディオファイルを作る。その結果、より自然に聞こえる音声になった。

このアップデートで、Text-to-Speech API（テキスト読み上げAPI）は今や14の言語とそれらの変種をサポートし、標準音声30とWaveNetの音声26を揃えている。

ここへ行くと、今回加わった新しい音声も含め、自分のテキストでGoogleのデモを試すことができる。

新しい機能の中では、オーディオプロフィールもおもしろい。これは、再生するメディアに合わせてオーディオファイルを最適化する機能だ。たとえば、スマートフォンのスピーカーとテレビの下にあるサウンドバーでは、音が違うだろう。オーディオプロフィールを使うと、音声を、電話の通話やヘッドフォンやスピーカーなどなどに合わせて最適化できる。

[元の音声と最適化の結果]

Speech-to-Text（書き起こしAPI）の方では、複数のスピーカーからの音声をより正しく書き起こせるようになった。機械学習を使っていろんなスピーカーを認識し、ひとつひとつの語にスピーカー番号のタグをつける（スピーカーの数は人間が指定する）。たとえばスピーカー2つのステレオファイルなら、それぞれの言葉の出どころを区別できるし、怒った顧客がカスタマーサポートに電話をしている音声なら、やはり各語の話者を識別できる。

複数言語のサポートも、新しい。検索には前からあったが、これからはそれをデベロッパーが利用できる。この書き起こしAPIに対しては、最大で4つの言語を指定できる。するとAPIは、今どの言語が喋られているかを、自動的に聞き分ける。

さらに、Speech-to-Text APIは、単語のレベルでの自信点を返す。すでに個々の談話レベルの自信点はあったが、今度からはデベロッパーは単語レベルのアプリ構築ができる。たとえば、“please set up a meeting with John for tomorrow at 2PM”（明日の午後2時にジョンとのミーティングをセットアップしてくれ）に対して‘John’や‘2PM’の自信度が低ければ、ユーザーにそれらを二度繰り返させるアプリを書けばよい。‘please’の自信度が低くても、それは重要でない単語だから、そのままでよい。Googleのチームは、そう説明している。

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

AWS、VPSサーバーのLightsailを半額に値下げ

2016年に提供開始したAWS Lightsailは、Digital Ocean、OVHを始めとする低価格バーチャルプライベートサーバー（VPS）製品に対するAmazonの答だった。Lightsailはごく基本的なサービスとしてスタートしたが、この2年間にブロックストレージ、Windowsサポートの追加、リージョンの拡大などが加わった。

本日（米国時間8/23）Amazonは、新たに2つのインスタンスサイズを追加し、LinuxベースのLightsailインスタンスのほとんどを半額に値下げした。Windowsインスタンスも値下げされるが、値下げ幅は大部分が約30%だ。

Linuxインスタンスの中で唯一50%の値下げでなかったのは、5ドル/月の512 MBインスタンスで新価格は3.50ドル。これでも悪くはない。ニーズによっては512 MBでもプロジェクトをいくつか動かすのに十分なので、1 GBが必要ないユーザーはLightsailを使えばDigital Oceanの最小構成である5ドル/月よりも数ドル安くできる。実際、Lightsailの1 GBインスタンスも5ドル/月になったのも驚きではない。

どのインスタンスタイプも、SSDストレージ、SSHアクセス、固定IPアドレスを含めVPSホスティングサービスに期待される機能をすべて備えている。

例によってWindowsインスタンスは少々高くて（つまるところWindowsのライセンスはただではない）512 MBインスタンスが月額8ドルだ。より使いでのある1 GBインスタンスには毎月12ドルが必要だ。

新しいインスタンスサイズについては、16 GBインスタンスが4つのvCPUと320 GBのストレージ、および余裕の6 TBデータ転送速度を備える。32 GBインスタンスはvCPUとストレージが倍になりデータ転送速度が7 TBになる。

[原文へ]

（翻訳：Nob Takahashi / facebook ）

ブロックチェーンを破壊するハッカーの手口をシミュレーションしてデベロッパーの事前対策を可能にするIncentivai

暗号通貨のプロジェクトは、人間がそのブロックチェーンを悪用すると破綻する。しかも分散デジタル経済が実際に動き出し、コインが離陸すると、それらを統治するスマートコントラクトの修復は難しい。あくまでも、デベロッパーによる事前対策が必要である。そこで、今日（米国時間8/17）ステルスを脱したIncentivaiは、その人工知能によるシミュレーションで、セキュリティホールを調べるだけでなく、ブロックチェーンのコミュニティを構成している人間たちの貪欲や非論理性にメスを入れる。暗号通貨分野のデベロッパーはIncentivaiのサービスを利用して、自分たちのシステムが動き出す前に、その欠陥を修復できる。

Incentivaiの単独のファウンダーPiotr Grudzieńはこう言う: “スマートコントラクトのコードをチェックする方法はいろいろあるが、新たに作った経済が期待通りに動くことを確認する方法はない。そこで私が考えたのは、機械学習のエージェントを利用するシミュレーションを作り、それが人間のように振る舞うことによって、システムの未来の振る舞いを予見する方法だ”。

Incentivaiは来週Y Combinatorを卒業するが、すでに数社の顧客がいる。顧客（ユーザー）は、Incentivaiの有料サービスにより自分たちのプロジェクトを監査してレポートを作るか、または自分でそのAIによるシミュレーションツールをホストしてSaaSのように利用する。同社がチェックしたブロックチェーンのデプロイは数か月後になるが、そのとき同社はすでに、そのプロダクトの有意義性を実証するための、いくつかのケーススタディーをリリースしているだろう。

Grudzieńは説明する: “理論的にあるいは論理としては、一定の条件下ではこれこれがユーザーにとって最適の戦略だ、と言うことはできる。しかしユーザーは、合理的でも理性的でもない。モデルを作ることが困難な、予想外の行動がたくさんある”。Incentivaiはそれらの理不尽な取引戦略を探求して、デベロッパーがそれらを想像しようと努力して髪をかきむしらなくてもよいようにする。

人間という未知数から暗号通貨を守る

ブロックチェーンの世界には巻き戻しボタンがない。この分散技術の不可変かつ不可逆的な性質が、良かれ悪しかれ、一度でもそれを使ったことのある投資家を遠ざける。ユーザーが偽りの請求をしたり、贈賄によりそれらを認めさせようとしたり、システムを食い物にする行動を取ったりすることを、デベロッパーが予見しなければ、彼らは攻撃を阻止できないだろう。しかし、正しくてオープンエンドな〔固定しない〕（AIに対する）インセンティブがあれば…これが社名の由来だが…AIエージェントはなるべく多くの収益を得るために自分にできることをすべてやってみて、プロジェクトのアーキテクチャにあるコンセプトの欠陥を明らかにするだろう。

Grudzieńはさらに説明する: “この〔すべてをやってみるという〕やり方は、DeepMindがAlphaGoでやったものと同じで、さまざまな戦略をテストするのだ”。彼はケンブリッジの修士課程でAIの技能を究め、その後Microsoftで自然言語処理の研究を担当した。

Incentivaiの仕組みはこうだ。まず、デベロッパーは、ブロックチェーンの上で保険を売るなどの、自分がテストしたいスマートコントラクトを書く。IncentivaiはそのAIエージェントに、何を最適化するのかを告げ、彼らが取りうるすべての可能なアクションを羅列する。エージェントの役柄はさまざまで、大金を手にしたいと思っているハッカーだったり、嘘をばらまく詐欺師だったり、コインの機能性を無視してその価格の最大化だけに関心のある投機家だったりする。

そしてIncentivaiはこれらのエージェントにさらに手を加え、彼らを、ある程度リスク忌避型だったり、ブロックチェーンのシステム全体を混乱させることに関心があったり、といったタイプにする。それから、それらのエージェントをモニターして、システムをどう変えればよいかというインサイトを得る。

たとえば、トークンの不均一な分布がパンプ･アンド･ダンプ（pump and dump, 偽情報メールによる価格操作詐欺）を招く、とIncentivaiが学習したら、デベロッパーはトークンを均一に分割して、初期のユーザーには少なめにする。あるいはIncentivaiは、認められるべき支払請求をユーザーが票決する保険製品は、投票者が偽の請求を偽と立証するために支払う債権価格を上げて、詐欺師から収賄しても投票者の利益にならないようにする必要があることを、学ぶかもしれない。

Grudzieńは、自分のスタートアップIncentivaiについても予測をしている。彼の考えによると、分散アプリケーションの利用が上昇すれば、彼のセキュリティサービスのやり方を真似るスタートアップが続出するだろう。彼によると、すでに一部のスタートアップは、トークンエンジニアリングの監査や、インセンティブの設計、コンサルタント活動などをやっているが、ケーススタディーを作る機能的シミュレーションプロダクトは誰もやっていない。彼曰く、“この業界が成熟するに伴い、そういうシミュレーションを必要とする、ますます複雑な経済システムが登場するだろう”。

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

Google Firebaseのアップデートでアプリ内メッセージング、JIRAの統合などが加わる

Firebaseは今やGoogleのデフォルトのアプリ開発プラットホームであり、買収から今日までの4年間で機能とGoogleのサービスとの統合を大きく拡充したきた。そして今日（米国時間8/16）は、そのさらなるアップデートにより、新しい機能と、より深い統合と、そしていくつかの新しいデザインがこのサービスに導入された。

このリリースのハイライトは、アプリ内メッセージングのローンチだ。この機能により、ユーザーがそのアプリを使っているときに、特定のユーザーに向けた(targeted)、しかもそのときの状況に合った(contextual)メッセージを送れる。このアプリ内通知機能はルック＆フィールをデベロッパーがカスタマイズでき、今日から展開されるが、たぶんもっと重要なのは、この機能がFirebase PredictionsやGoogle Analytics for Firebaseと統合されていることだ。そのため、ユーザーの現在の行動に反応するだけでなく、どれぐらいのお金を使いそうか、とか、アプリの使用をやめそうか、などの予測(predictions)に基づいてメッセージを送れる。

また今回のアップデートでFirebaseは、AtlassianのJIRAと統合される。これからはFirebaseのユーザーが、Firebase内のクラッシュレポートに基づいてJIRAのIssue（‘課題’）を作れる。この統合は、数週間後に有効になる。

2017年にTwitterから買収したクラッシュレポートツールCrashlyticsとの、より深い統合が実現した。これからはそのデータをBigQueryにエキスポートして分析し、GoogleのData Studioで視覚化できる。そしてBigQueryにデータを置いたら、Firebaseのデフォルトの保持/削除のルールとは無関係になる。

レポートに関しては、Firebase Cloud Messagingにレポート用のダッシュボードがつき、またFirebase ConsoleのProject Overviewのデザインが一新されて、アプリの健康状態やステータスをひとつのページで見られるようになった。Latest Releaseセクションでは、ライブデータもフィーチャーされる。これらの機能は今日から展開が始まり、数週間後には全員に行き渡る。

WebのコンテンツをホストできるサービスFirebase Hostingは、今回のアップデートにより、ひとつのプロジェクト内で複数のWebサイトをホストできるようになった。Webサイトのアップデートをプッシュしたら、変更されたファイルだけがアップロードされる。ささやかなスピードアップだ。

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

PrometheusモニタリングツールがCNCFの新たな‘卒業’プロジェクトとしてKubernetesに加わる

Cloud Native Computing Foundation(CNCF)はまだそれほどメジャーな名前ではないが、今急成長しているコンテナオーケストレーションツール Kubernetesなど、いくつかの重要なオープンソースプロジェクトの本拠地だ。今日CNCFは、モニタリングツールPrometheusが、同団体の第二の“卒業”プロジェクトとしてKubernetesに加わったことを発表した。〔*: 卒業プロジェクト, graduated projecとは、育成涵養段階を脱して、単独・独立の“一人前の”プロジェクトとして扱われること。〕

その発表は、今週ミュンヘンで行われているPrometheusのカンファレンスPromConで行われた。CNCFのCTO兼COOのChris Aniszczykによると、卒業プロジェクトとはプロジェクトの全般的な成熟を表していて、コントリビューションやコミュニティや採用が多様になったことを意味している。

Prometheusの場合は、今すでに20名のアクティブメンテナーがおり、1000名以上のコントリビューターが13000あまりのコミットを行っている。コントリビューターの中には、DigitalOcean, Weaveworks, ShowMax, そしてUberなどがいる。

CNCFのプロジェクトはサンドボックスで始まり、インキュベーションの段階へ入り、そして最後に卒業する。卒業の条件は、CNCFのCode of Conduct（行動規範）の遵守、セキュリティ監査に合格、そしてコミュニティの統治構造が定義されていることだ。また、“コードの質とセキュリティのベストプラクティスに持続的にコミットしていること”も必要だ。

Aniszczykによると、Prometheusツールは時系列データベースにクエリー言語を結びつけたシステムで、ユーザー（主にデベロッパー）がターゲットシステムの問題を知るためにはそのクエリー言語で検索し、それに対する分析結果（アナリティクス）を得る。すでに感づいておられたと思うが、それはとくに、コンテナに適したツールだ。

Kubernetesと同様、のちにPrometheusになるプロジェクトも、ルーツはGoogleにある。Googleはコンテナを積極的に採用した初期の企業のひとつで、Kubernetesの前身であるBorgや、Prometheusの前駆システムBorgmonを開発した。Borgの仕事はコンテナのオーケストレーションを管理することで、Borgにmon(monitor)を付けたBorgmonの仕事はそのプロセスをモニタして技術者にフィードバックを提供し、コンテナの全ライフサイクルにおいて、その中で起きていることを察知させる。

ルーツはBorgmonでも、今ある姿のPrometheusは二人の元Googleエンジニアが2012年にSoundCloudで開発した。2016年5月には第二のCNCFプロジェクトとしてKubernetesに加わり、そして当然のように、第二の卒業プロジェクトになった。

その過程におけるCloud Native Computing Foundationの役割は、クラウドネイティブコンピューティングを推進することだ。どんなに違いのあるインフラストラクチャでも共通のやり方で管理できる、とするその概念は、オンプレミスとクラウドのリソース管理に伴う複雑性を大幅に軽減した。CNCFはLinux Foundationの一員であり、そのメンバーにはテクノロジー業界の大物たちが多い。

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

Google CloudがNvidiaのTesla P4推論アクセラレーターをサポート

今やクラウドプラットホームは、GPUのサポートなくして完全とは言えない。今日のハイパフォーマンスワークロードや機械学習のタスクは、それなくしてサポートできないからだ。それらは多くの場合、機械学習のモデルの構築に使われることが多いが、しかし今日（米国時間8/6）Googleは、Nvidia P4アクセラレーターのサポートをローンチし、既存のモデルをより高速に走らせることによる推論の性能アップにフォーカスしようとしている。

また、これらの機械学習のワークロードのほかに、Google Cloudのユーザーは、高速なグラフィクスカードを必要とするリモートディスプレイのアプリケーションを、GPUを使って動かすことができる。そのためにGPUは、リモートデスクトップにログインするユーザーのためにサーバーサイドのグラフィクスの応答性を高めるシステム、Nvidia Gridをサポートする。

P4には8GBのDDR5メモリがあり、最大で毎秒22テラの整数演算ができるから、ほとんど何でもできるカードだ。しかも買うと2200ドル以上はするから、時間制で借りる方が賢明だろう。

Google Cloud上でP4を使うと、標準料金では1時間60セント、プリエンプティブルでよければ21セントだ。Googleの料金としてはP100やV100 GPUより安いが、ただし両者はユースケースがまったく違う。

この新しいGPUは最初、us-central1(Iowa), us-east4(N. Virginia), Montreal(northamerica-northeast1), europe-west4(Netherlands)の各リージョンで提供され、徐々にそのほかのリージョンでも提供される予定だ。

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