GitHubがユーザーコードの安全でない依存性を警告、コードの見つけやすさも改善

オンラインのコードリポジトリGitHubが今週、例年のカンファレンスを開催している。テクノロジー業界の長年のやり方に倣って同社は、このイベントを利用してサービスの新しい機能をいくつか発表した。今回の大きなテーマは二つ、セキュリティと発見性(discoverability, コードの見つけやすさ)だ。

近年はハッキングの被害がますます増えているから、ユーザーから預かったコードのセキュリティをGitHubが重視するのも当然だ。同社がとくに問題にするのは、最近のプロジェクトの多くが非常に多様なサードパーティのライブラリなど、外部資源に依存していることだ。

そこで今回GitHubがローンチしたのが、“依存性グラフ”(dependency graph)だ。これによりデベロッパーは、自分のコードが利用しているほかのパッケージやアプリケーションを一望にできる。当面RubyとJavaScriptのコードだけだが、近くPythonもサポートされる。すべての依存性が一望的に分かれば、それを標準的な脆弱性データベースと対照して、やばいものが使われていたらデベロッパーたちに通知できる。GitHub自身の通知警報機能は“もうすぐ提供”だそうだから、それまでは各自の取り組みが必要だ。

GitHubのチームによると、同サービス上のプロジェクトの75%以上に何らかの依存性があり、その半分以上に10以上の依存性がある。そして依存性が100を超えるプロジェクトも、昨今では珍しくない。

発見性に関しては、GitHub上には今や2500万あまりのアクティブなレポジトリーがあり、デベロッパーが関心を持ったコードをその中に見つけるのが容易ではない。この状況を改善するために同社は、ニューズフィードを一新してリコメンデーションを含めることにした。リコメンデーションは、ユーザーが誰々をフォローし、どのリポジトリーをスターし、また今GitHub上で何に人気があるか、といった情報に基づいて作成される。また“Explore”と呼ばれる人間が編集するセクションでは、機械学習やゲーム開発など、分野別のプロジェクトやリソースをまとめて紹介する。

また、有料のGitHub Enterpriseでは、30分以内のお返事を約束するプレミアムサポートと、コミュニティフォーラム、Marketplace機能のトライアル、チームディスカッションツールなどが提供される。そこではもちろん、どのコードがどこにあるか、ということも話題になる。

GitHubのデータサイエンティストMiju Hanはこう言う: “GitHubの上で人間がやってることを、明日になれば人工知能がやってくれるなんて、ありえないからね。GitHubでは基本がいちばん重要。基本を良くしていけば、長期的には最良のデータが得られるようになる”。

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

UdacityのナノディグリーにReactプログラミングが加わる、4か月で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))

大量の既存コードで訓練されたAIがプログラマーにオートコンプリートを提案するCodota、Khoslaが$2Mを投資

GitHubを使うようになってデベロッパーのワークフローは抜本的に変わった。コードをアクセスしやすいプラットホーム上に集積することによって、プログラミングのやり方が急速に変わった。そんな状況を受けてイスラエルのCodotaは、これまで無視されることの多かったデベロッパーコミュニティのワークフローをさらに最適化したい、と考えている…マシンインテリジェンスを利用して。同社の自動補完(オートコンプリート)機能を使えば、良質なコードを短時間で書けるようになる。同社はこのほど、Khosla Venturesから200万ドルのシード資金を獲得したことを発表した。

CodotaはEclipsのようなIDEと併用して、そのインテリジェントなコード補完機能を利用する。それは、「あなたが意図するものはこれではないですか?」と短い例示をくれるのではなく、もっと大きなコード集合をリコメンドできる。

協同ファウンダーのDror WeissとEran Yahavは、GitHubやStackOverflowにあるオープンソースのコードを利用してCodotaを作った。その公開コードのすべてを機械学習のモデルに食べさせて、コードブロック全体の高いレベルの意味を認識できるようにした。

テルアビブの本社におけるCodotaのチーム

プログラミング言語は一般言語と同じ構造を共有している部分が大きい。たとえば、語の限りなく多様な並べ方によって、考えや感情を表現する。また、同じコマンドでもコード中でいろんなやり方で表現できる。だからCodotaにとっては、コードがやってることに関する大局的な理解がとても重要だ。コードのミクロな像ではなく、マクロな像を理解することが重要なのだ。

もちろん、自然言語とコードが似ているのは、あるところまでだ。Codotaのチームが説明してくれたところによると、自然言語処理では、意味は語の近辺の複数の語を見て判断する。それに比べるとプログラムはもっと構造性があり、語がどこにあるかによって語の意味が違うことは少ない。だからCodotaはテキストで訓練するだけでなく、プログラムの動作/振る舞いにもフォーカスした。

Codotaを使うとスピードと正確さが向上するだけでなく、Codota自身の発見や教育にも助けられる。Codotaは何百万ものAPIの実装で訓練されているから、ベストプラクティスをデベロッパーに提示できる。IDEの横にCodotaを開いておくと、コード中のおかしい箇所を高輝度表示し、モアベターな代案を示す。その教えは、ライブラリの原作者のコードから直接引用したものが多い。

同社の収益源は、Codotaの利用を、そしてもちろん自分のコードを、社外秘プライベートにしておきたい企業からの使用料だ。今、対応言語はJavaだけだが、言語は今後すこしずつ増やしていく。

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

GitHubのエンタープライズバージョンが重すぎる企業のために通常Webサービスの“企業用プラン”が登場

Workers install a billboard for GitHub Inc. in San Francisco, California, U.S., on Tuesday, Nov. 11, 2014. GitHub, which provides open-source code hosting services and has raised more than $100 million from investors, is among tech startups boosting demand for billboard space around Silicon Valley. Photographer: David Paul Morris/Bloomberg via Getty Images

GitHubが今日(米国時間3/1)から大企業向けの提供物を拡張する。元々デベロッパーが効果的にコラボレーションし、ソースコードを共有するためのサービスだったGitHubだが、最近ではそのツールのエンタープライズバージョンを提供して、同じサービスを大企業が自社のために自社のデータセンターやAWS、Azureなどの上でホストできるようにしている。今日発表されたのは、企業自身が動かすバージョンというより、前からあるGitHubサービス本体の企業用バージョン、ビジネスバージョンで(下図)、というか‘プラン’で、それはユーザー一人あたり月額21ドルで利用できる。

では、無料や月額7ドルや9ドルの従来型サービスと、21ドルのビジネス用サービスプランは、どこがどう違うのか。この高い月額のサービスでは、上述の、GitHubツールのエンタープライズバージョンと同じく、Ping Identity, Okta, Azure ADといったSAMLベースのシングルサインオンがサポートされる。そしてアドミンがユーザーアカウントの供与やパーミッションの管理を行えるし、アカウントの供与/解消の自動化もできる。GitHubのエンタープライズバージョンにあってビジネスバージョンのサービスプランにないものといえば、Team Syncだけだが、これも年内にはサポートが予定されている。

さらに99.95%のアップタイムが約束され、その約束をSLAが支える。ウィークデーにはサポートにアクセスできる。

というわけでこれは、GitHubにとって当然のような次の一歩だ。エンタープライズバージョンを自分でオンプレミスでホストできるような大企業は多くないし、その必要のないところもある。しかしこれまでは、その必要のないところでも、エンタープライズ機能が使いたければ、GitHub Enterpriseのセルフホストしか選ぶ道はなかった。でもこれからは、もっと容易に、エンタープライズ級のGitHubを使えるし、アドミンの仕事も楽になる。

0919ffcc-f925-11e6-8571-4779da044270

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

Microsoft、ドローン、自動運転車のシミュレーター・ソフトをオープンソース化

Microsoft AIRO group on January 24, 2017.(Photography by Scott Eklund/Red Box Pictures)

Microsoftはドローン、自動運転車、その他ユーザー独自のガジェットの移動をシミュレーションできる高度な仮想現実のベータ版をオープンソースで公開した。ソースコードはGitHubから入手できる。このソフトでは物体の形状ばかりでなくドローンの運用にあたって困難な問題を引き起こす可能性がある影や反射などの要素も描写できる。レンダリングはきわめてリアルだという。

Microsoftはこのソフトが「ロボティクスの民主化」を進めることを期待している。つまり個人であれ組織であれ、ドローン・テクノロジーを実験したい場合に好適ということだ。現実世界でドローンを動かすのは自他への危険を伴う上にきわめて大量の資源を必要としがちだ。

ドローンその他の自動運転デバイスを仮想空間でテストするメリットは次のような点だろう。衝突を回避しなければならない壁などの固い物体と物体の影を見分けるのは自動運転システムにとって難しい課題になる。現実世界でドローンを動かすのは上で述べたようには非常に高価な上に、通り抜けが不可能な障害と影のように「そう見える」だけの形状を判別させるテストを現実世界で実行した場合、失敗はクラッシュを意味することになる。これはますます高価であり、また危険だ。しかし仮想世界の中では大量に失敗を繰り返すことができる。失うものは少々の時間と電気料金だけだ。

失敗を高速で繰り返すことはAIの訓練のために必須でもある。ただしAIの訓練に本当に役立つためには仮想世界はきわめてリアルに再現できなければならない。Microsoftによればこのシミュレーターは最新の高度なグラフィックス・テクノロジーを用いており、影、きらめき、陽光、霧、路上の水たまりの表面の反射など外界のディテールを精密に再現できるという。

MicrosoftのAshish Kapooはブログで「このシミュレーション・ソフトは自動運転車と飛行するドローンの双方の実験に用いることができるだけでなく、現実の世界を安全に移動する必要のあるロボットのテストに広く利用できる」と述べている。

画像: Scott Eklund/Red Box Pictures

[原文へ]

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

Googleの採用試験ハックに挑戦した男に話を聞いてみた

maxresdefault

採用試験”ハック”には本当に効果があるのだろうか?いかれた(もしくは少し変わった)行動をとることで、大企業の注意をひくことはできるのか?実際に変わった方法で企業にアピールしようとしたJohn Washamという男の物語は、結果はどうあれ面白い。

WashamはGoogley As Heckと題された自身のブログに、Googleの採用試験に挑戦するまでの道のりを記している。彼はGoogleで働くという明確なゴールのもとでソフトウェア工学を勉強し、そのマイルストーンをブログの形に残していたのだ。最終的には採用担当者から電話さえなかったという残念なメッセージでブログは締めくくられた。

ではWashamのような攻略法には効果があるのだろうか?実際に彼に話しを聞いてみた。

TC:簡単な自己紹介とあなたが行ったことについて教えてもらえますか?

John Washam:私の名前はJohn Washamです。独学でウェブディベロッピングを習得し、これまでに16年の実務経験があります。ここ8ヶ月間はフルタイムでコンピューターサイエンスとソフトウェア工学の勉強をしてきました。現在2つのインターネットビジネスを運営していますが、自動化のおかげで運営にはほとんど手がかかっていません。そのため自分のスキルを磨く時間をつくることができたんです。これまでずっとウェブの仕事をしていたため、長年の経験があっても多くのソフトウェアの分野で要件を満たすことができませんでした。大学で経済学を専攻し、コンピューターサイエンスの知識がない私には、就くことができない仕事が山ほどありました。

そこで私は、Googleにソフトウェアエンジニアとして採用されるという大胆な目標を立てることにしたんです。

TC:なぜGoogleでの採用を目標にしたんですか?

JW:毎日本を開いて、ホワイトボードにコードを書き続けられるような目標が必要だと感じたからです。最初は目標の大きさに怖気づいて、ときには眠くなってしまうこともありました。それでも時間が経つにつれて恐怖や退屈さは消えていき、だんだん簡単で面白いと思えるようになったんです。知識は恐怖心を凌駕するということですかね。ひとつひとつの内容をもっと深く学びたいと思いましたが、それでは一日に何時間あっても足りなくなりそうだったので、スケジュールに基いて次のトピックへと移っていきました。

自分のスキルを向上させて、ウェブディベロッパーからソフトウェアエンジニアになりたいと考えていた私にGoogleはピッタリでした。彼らの企業文化は研究機関と似ていて、証明できるかどうかが評価されるほか、意見よりもデータが優先されます。コンピューターサイエンスについて知れば知るほど、Googleの文化を魅力的に感じ、Googleについて知れば知るほど、さらに興味がかきたてられました。

Googleには年間約200万通もの履歴書が送られているため、私を推薦してくれる人がいるとはいえ、何か目立つ方法はないかと応募前に考えていました。そこで学習の様子をGoogley As Heckというブログに記録することにしたんです。私はウェブディベロッパーなので、ブログを立ち上げるくらい簡単なことでした。そしてGoogleの誰かに気づいてもらえることを願いながら、2〜3日に一度その日に学んだ面白いことをブログに投稿し始めました。ブログを書くのはかなり楽しかったですね。プログラマーは自分のスキルを見せつけるのが好きなんです。

学習内容の整理にあたっては、Googleの候補者用コーチングノートを参照してトピックごとのToDoリストを作りました。そして学習が進んで内容が多岐にわたるにつれて、コンピューターサイエンスのトピックも追加していきました。また当時Githubのプロフィールにはほとんど何も書かれていなかったので、ToDoリストをGithubにアップして、きちんと勉強の軌跡が残るようにしました。そして去年の10月のある日、ToDoリストの数が1600行を超えたあたりで、リストがバイラル化したんです。今ではこのToDoリストはGithubの人気プロジェクトランキングで27位になり、3万3000個のスターが付けられ、私のプロフィールも前よりずっとマシになりました。私のToDoリストは13言語に翻訳され、今でもたくさんの素晴らしい人たちがプロジェクトに貢献してくれています。

TC:実際にGoogleの誰かがブログに気づくと思っていましたか?そしてその理由はなんでしょうか?

JW:やる価値はあると思ったんです。Googleは候補者に”Googleっぽさ”を求めているので、私自身がGoogleらしい人になろうと考えました。

これまでいくつかのスタートアップをローンチしてきたので、採用までの道のりもスタートアップ風に考えることにしました。素晴らしいもの(学習内容)をつくって、狂ったように宣伝(Medium、Hacker News、RedditでToDoリストがバイラル化)して、資金が底をつく前にIPOもしくは他社に買収される(Googleに採用される)といった具合です。

もともとスタートアップの宣伝は比較的得意な方で、自分の会社となるとなおさらでした。そういう意味ではスタートアップの経営と勉強中にやったことはほとんど変わらないと言えます。

Googleに応募する1週間前にMedium上で公開した記事は、結局10万回以上も読まれ4000回もオススメされました。MediumにあるFreeCodeCampのコミュニティに私の記事を転載してくれたQuincy Larsonのおかげもあって、読者の方々からは驚くほどの数のサポートや応援を頂きました。Quicyは素晴らしい人です。

john_washam_bw-small-1TC:本当のゴールは何だったんですか?

JW:Googleは私にとってのモチベーションにすぎず、全ての努力がGoogleの採用に向けられていたとは思わないでほしいです。もちろんGoogleで働ければ最高ですが、本来の目的はソフトウェアエンジニアになるということでした。私はウェブディベロッパーを超越して、ソフトウェアデベロップメントの他の分野でのチャンスにつながるドアを開きたいと思っていたんです。さらには自分がずっとユーザーとして頼ってきた、データベース、サーバー、OSなどのテクノロジーを自分の手で作りたいとも思っていました。ウェブブラウザの向こう側には、全く別のソフトウェア工学の世界が存在するんです。

TC:最終的な挑戦の結果はいかがでしたか?面接ではどんなことを聞かれました?

JW:推薦者を通してソフトウェアエンジニアのポジションに応募したんですが、先週メールで担当者から不採用通知を受け取りました。最初は何かの間違いだと思って笑ってしまいましたよ。その後推薦者に確認して私を推してもらったんですが、結局状況は変わりませんでした。

不採用の理由を教えてもらえず、推薦者も何が理由か解明できなかったのはとても残念です。

納得いかなかったのは、電話でのスクリーニングさえ受けられなかったということです。電話で採用担当者と話をすることもできませんでした。努力して情熱を注ぎ込んだにも関わらず、自分を証明するチャンスさえもらえなかったんです。

もしも経験不足を原因に挙げられるとすれば、私は絶対に新卒者よりも経験を持っています。実際にGoogleは新卒学生を採用していますし、私は16年にわたるソフトウェアエンジニアの経験を持つベテランとして採用されようとも思っていませんでした。履歴書にも2〜3年分の経験有りとしか記載していません。

私が納得しなくても、採用担当者の判断を尊重するしかありませんけどね。彼らは私よりも採用業務のことを知っていますし。採用担当者は一日に何百という数の履歴書に目を通しているので、有力な候補者をみつけ、理想にマッチしない候補者をはじき出すのに慣れているはずです。詳細はわかりませんが、私は彼らが求めるプロフィールに合致しなかったんでしょう。もしかしたら彼らは私のためを思って不採用にしたのかもしれません。仕事内容を理解できずにチームの足を引っ張っていた可能性もありますしね。

Googleは採用過程で有力な候補者を誤って見逃してしまうことがあると聞いていますが、採用されるに足る力を持っていれば最終的にはGoogleに入り込めるはずです。

未だにGoogleのことは好きですが、将来また応募するかどうかはわかりません。私は会社を点々とするよりも、ひとつの会社に長くとどまりたいと考えています。今後私を採用することになる企業は、忠誠心があってよく働く情熱的な社員を手に入れることができるでしょう。Google以外にも良い仕事をするために努力でき、その努力が報われるような会社はたくさん存在します。私のやる気を引き出すというGoogleの役目は終わったので、今度は他の会社がその恩恵にあずかる番だと考えています。

TC:Googleがあなたの才能に怖気づいた可能性はあると思いますか?

JW:私の知識に誰かが恐れを感じていたとは思いません。そもそも私の知識量は恐ろしいほどのものではなく、Googleが候補者に期待するのと同じ程度だと考えています。

不採用の理由については色々と考えを巡らせましたが、ここではその話はしないようにします。結局は憶測に過ぎず、なんの意味もありませんからね。

TC:今後はどうされるんですか?Google以外に働いてみたい企業はありますか?

JW:最終的には、私に欠けていたコンピューターサイエンスとCTMレベルのソフトウェア工学の知識という、当初求めていたものを身につけることができました。今では連結リストや二分探索木も怖くありませんし、むしろ好きになりました。今私が面白いと感じていることは、長年の経験を持つエンジニアが退屈だと感じることなんだと思います。それでも全てが新しくて楽しいんです。ソフトウェア工学を越えて機械学習についても勉強しましたが、全て素晴らしいです。

そもそもの勉強の目的は、ソフトウェアエンジニアとしての新しいキャリアをスタートさせるということでした。現在はシアトル周辺で、情熱を持った「経験豊富ながら未熟な」ソフトウェアエンジニアを雇い、周囲のスピードに追いつくまで待ってくれるような余裕がある、規模の大きな企業を主なターゲットとして就職活動をしています。理想的にはプロフェッショナルなチームの中で、テストやデバッグやプロファイリングの業務を含め、素晴らしいソフトの開発に携わりたいです。とにかく高品質なソフトを作りたいんです。

頭が良くて、仕事熱心で知識のあるソフトウェア職人(見習い)が努力しながら成長し、色んなことを学べるような環境があればベストです。失敗することもあると思いますが、私は常にチームの迷惑にならないよう努力します。仕事にはエゴを持ち込みませんし、私が間違っているときにはそれを受け入れ、しくじったときには責任をとります。

将来私の雇用主になるかもしれない皆さん、私に難題をぶつけてください。私は何でも学べます。OSのインターナルから幾何アルゴリズム、コンパイラ開発、暗号化技術、機械学習、Intel x86の命令まで、社内に何らかの専門家が必要であれば私がその専門家になります。

それでは、コーディングの問題を解かなければいけないので、勉強に戻ります。

原文へ

(翻訳:Atsushi Yukutake/ Twitter

Facebook、JavaScriptの新パッケージマネージャ、Yarnをリリース―Google他が協力

OAKLAND, CA - NOVEMBER 30:  A FedEx worker sorts packages being uloaded from a truck on a conveyor belt at the FedEx Oakland Airport sort facility November 30, 2005 in Oakland, California. FedEx and UPS are beginning to feel large volumes of packages as the holiday shipping season gets underway with a high level of online shopping.  (Photo by Justin Sullivan/Getty Images)

今日(米国時間10/11)、FacebookはJavaScriptの新しいパッケージマネージャーYarnをローンチした。読者が日頃JavaScriptとNode.jsを使っているなら、 既存のコードを探して再利用する(あるいは自分で開発したライブラリを公開する)ためにnpmパッケージマネージャを利用している可能性が高い。

しかしnpmはFacebookのような巨大な規模の企業の業務を処理するには能力が足りなかった。そこでFacebookは社内のデベロッパーの意見に従って独自のパッケージマネージャを部内用に開発した。その後開発チームはGoogle、Exponent、Tildeなどの外部のエンジニアの協力も得るようになった。

こうして開発されたのがYarnだが、特に重要なポイントは以下の点だ。つまりYarnはFacebookのような巨大企業以外のデベロッパーにも画期的な効率アップを約束するものの、あくまでnpmレジストリを利用しているユーザーが対象であり、npmクライアントをドロップインで代替するプロダクトだという点だ。

Facebookのソフトウェア・エンジニアのSebastian McKenzie、エンジニアリング担当マネージャーのTom Occhinoが私に語ったところによれば、Facebookは社内でnpmを中心として多くのインフラを構築してきたという。McKenzieによれば、「しかし時間が経つうちに、npmに新しい機能やツールを次々に付け加えていくやり方ではうまくいかなくなってきた。そこでnpmの能力の限界をハッキングして拡張しようとする代わりに、Facebookは新しいパッケージマネージャをゼロから作ろうと決めた」という。

数百万人のデベロッパーのところでnpmが役に立っているのに、なぜFacebookでは問題が起きたのだろうか?  Facebookの開発チームの話によれば、同社のワークフローに適合しない根本的な問題がいくつかあったのだという。ひとつはパフォーマンスが低すぎたことで、Yarnはローカルに保存されたファイルを得るのが効率化されている。つまりネットワークへのアクセス回数を従来よりずっと減らし、負荷をかけずにすむようになった。Yarnはまたいくつかの作業を平行化することができ、新しいモジュールのインストールが高速になった。

Facebookのワークフローでは常時新しいモジュールが統合されている。npmはこのプロセスのネックとなり、スピードをダウンさせていた。当初、Facebookのエンジニアはマニュアルでnpm installコマンドを入力していたが、これはサンドボックスやセキュリティーや信頼性への配慮からネットワークから孤立した環境でのモジュール統合では作動しなかった。レポジトリにあるすべてのモジュールをチェックする仕組みも、どんなわずかな変更でも巨大なコミットを引き起こすことになったので非効率だった。たとえばReact Nativeモジュールには68の依存関係があり、依存先もまた独自に依存関係があり、合計すると12万1358個のファイルになる。これらをすべて引き出してくるのは効率的とはいえない。

Facebookが直面したもうひとつの問題は、npmは本質的にノン・デターミニスティック(非決定性)のデザインだという点だった。FacebookのエンジニアはDevOpsのワークフローで一貫性と信頼性のあるシステムを必要としている。npmの場合、すでにインストールされたモジュールとの依存関係によって、あらゆるプロジェクトに存在するにもかかわらず、node_modulesのディレクトリはマシンごとに全く違った見え方となる。Yarnではロックファイルとデターミニスティックなインストール・アルゴリズムを用いることにより、すべてのマシンを通じて統一的なファイルを構造を得ることができるという。

またnpmはデフォールトでデベロッパーがインストールの過程で必要になれば他の場所にあるコードを参照して実行できるようパッケージを書くことができる。これはセキュリティー上の問題を引き起こす原因になるため、Yarnではこの機能は削除された。

McKenzieが私に話したところによると、開発チームは当初npmのこうした問題の「修正」を試みたという。だが努力を重ねるうちに、既存のnpmクライアントの機能にFacebookのワークフローで作動しないものが多数あるのはバグではなく、そういう仕様であることが分かってきた。Occhinoは「それにFacebookが必要とする機能の多くはnpmのコミュニティーに受け入れられない可能性があった」と付け加えた。

npmプロジェクトを支える商業組織であるNpmはもちろんFacebookが新しいパッケージマネージャを開発中であることを知っていた。しかしNpmのビジネスモデルはクライアントよりレジストリを中心としており、一般に想像されるよりも相互の競合ははるかに少なかったという。

YarnはすでにGitHubから利用可能だ。Facebook以外の多くの企業が協力したことをふまえ、開発チームはFacebook独自のレポジトリを利用することを避けた。ただしYarnの今後の管理体制がどのようなものになるのかについてはまだ不明な点が多い。「これまで開発に協力してくれた企業が引き続き将来の管理についても助けてくれるというのがわれわれの希望だ」とOcchinoは述べた。

画像: Justin Sullivan/Getty Images

[原文へ]

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

強力なDDos攻撃アプリケーションMiraiがGitHub上でオープンソース化、逮捕回避のための煙幕か

enterprise-security

KrebsOnSecurityやそのほかのWebサーバーに大きなダメージを与えたボットネットのMiraiは、セキュリティの脆弱なIoTデバイスを利用して、大規模なDoS攻撃を仕掛ける。しかしその作者はこのほど、それのソースコードをGithub上に公開したらしい。

Cで書かれたその短いコードは、IPカメラなどインターネットに接続されたデバイスの上で実行される。rootのパスワードを試行によって探り当て、デバイスに侵入、事前に決めてあったターゲットにトラフィックを送る。試行するパスワードが書かれているコードは、このファイルにある。

screen-shot-2016-10-10-at-10-46-27-am

ハッカーはこのボットネットを使って、620GbpsのDDoSをKrebsOnSecurityへ送った。そこはBrian Krebsのセキュリティに関するブログとして、かねてから人気のサイトだ。そのボットネットは強力ではあるものの、当のIoTデバイスをリブートすれば止まる。また、デバイス側のシステムアップデートにより、被害機は徐々に減っているようだ。コードをHackforumsにポストしたハッカーのAnna-senpaiはこう述べている、“Miraiでは、telnetからだけで最大380k(38万)のボットを取り出していた。でもKrebsをDDoSしてからは、徐々にISPたちがそれらを掃除するようになった。今では最大は300k程度で、しかも減りつつある”。

Krebsはハッカーたちの逮捕を求めており、今回のコード公開は利他的動機によるものではない、と見ている。

彼曰く: “Anna-senpaiがMiraiのソースコードを公開した理由はよく分からないが、利他的な行為ではありえないだろう。悪質なソフトを開発している連中は、警察や警備会社などに居場所を突き止められそうになったら、ソースコードをばらまいて煙幕を張る。公開して誰でもダウンロードできるようにすると、コードの持ち主が即犯人、とは言えなくなるからね”。

そのコードは今Githubにあり、どうやら本物のようだ。ぼくはコンパイルしていないが、ファイルにはおもしろい情報がいろいろある。教材としての利用価値は、十分にあるだろう。もちろん、悪い連中にとっても、利用価値は十分あるけどね。

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

GitHubがセカンダリーラウンドの資金調達をしているらしい、旧投資の部分的清算のため?

Workers install a billboard for GitHub Inc. in San Francisco, California, U.S., on Tuesday, Nov. 11, 2014. GitHub, which provides open-source code hosting services and has raised more than $100 million from investors, is among tech startups boosting demand for billboard space around Silicon Valley. Photographer: David Paul Morris/Bloomberg via Getty Images

いくつかの情報筋によると、GitHubは昨年7月の、評価額20億ドルでの2億5000万ドルの資金調達(プライマリーラウンド)に続き、セカンダリーの資金調達を今進めている、という。しかし噂では、このセカンダリーの資金調達は、投資家または社員の株式現金化(“清算”, liquidation)に備えてだ、とも言われている。

この話には二つの部分がある。ひとつは、この二度目のラウンドでは同社の評価額が最初の20億ドルより低くなる、という説だ。ある筋の推計では、15億あたりだろう、という。ただしこれも正確な数字ではない。しかし別の筋によると、このセカンダリーは普通株のためだろう、という。そうなると、話はややこしくなる。そうすると、優先株はどうなり、投資家はどんな権利を得るのか。そこで評価額の計算もやや曖昧になり、ふつうの意味のダウンラウンドではない、という理屈になるのかもしれない。

しかし、それよりももっとおもしろい噂は、MicrosoftがGitHubの買収を検討している、という説だ。買収ではなく戦略的投資だ、という説もあるが、噂としては大きな違いはない。M社がより深いパートナーシップを求めているのだ、という説もある。GitHubの代表者は、Microsoftによる買収の噂は真実ではない、と言う。Microsoft側は、ノーコメントだ。

このセカンダリーラウンドに誰が参加するのか、投資家なのか社員なのか? しかしいずれにしても、GitHubも今年で8歳だから、これまでの投資の清算があっても不思議ではない。

この種のセカンダリーラウンドは、企業が後期ステージへと成長し、しかしIPOはまだしない、というときに意義がある。GitHubは人も文化もきわめて分散的だから、昔からの社員が何らかの代償を求めてもおかしくない。現状は、入ったばかりの若手と、長年いるベテランとのあいだに、待遇や報酬の差はあまりない。そういう意味でGitHubは、フラットな会社だ。また、代償は引き止め策でもある。投資家たちの一部も、セカンダリーラウンドによる清算(現金化)を期待しているだろう。

GitHubは、世界でいちばん多く採用されているデベロッパーツールだろう。コードを管理するための場所であるだけでなく、オープンソースのエコシステム全体の、もっとも重要な部分だ。オープンソースのプロジェクトを健全かつ活発に維持することは、直接間接に必ずそれらを使っている大きな企業にとって、とても重要だし、オープンソースの寄与貢献者の中から有能な人材をピックアップできる。人だけでなく、多様なアイデアもそこで育つ。しかしデベロッパーが気軽に利用していたリソースも、持続可能なビジネスへ成長するためには、本格的なエンタープライズに自分を拡張する必要がある。それがおそらく、今GitHubが抱えている難問だ。

Microsoftに関しては、Visual Studio Team ServicesというGitHub的なツールがすでにあるので、そこがおそらく今回の噂の出処(でどころ)だろう。

最近IPOしたAtlassianをはじめとして、GitHubをめぐる競争は激化している。Atlassianは、昨年IPOした途端に株価は32%跳ね上がり評価額は58億にもなった。それは、IPOしたときすでに同社が黒字だったせいもある。また、最近元気なGitLabは、GitHub同様、オープンソースのgitをベースとしている。同社は先月、2000万ドルを調達した

〔参考記事: セカンダリーラウンドとは何か。〕

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

GitHubがプロジェクト管理ツールを内蔵へ、そして公式の多面的なレビュー過程をサポート

Workers install a billboard for GitHub Inc. in San Francisco, California, U.S., on Tuesday, Nov. 11, 2014. GitHub, which provides open-source code hosting services and has raised more than $100 million from investors, is among tech startups boosting demand for billboard space around Silicon Valley. Photographer: David Paul Morris/Bloomberg via Getty Images

GitをベースとするコードホスティングサービスGitHubは今日(米国時間9/14)、サンフランシスコでデベロッパーカンファレンスUniverseをやっている。年に一回の大会は新しい機能を発表するのにふさわしい機会だが、今回同社はそれを、“このプラットホームのこれまでで最大のアップデート”と呼んでいる。それらがどれだけ重要かは、各人のGitHubの使い方にもよるのだが。

チームで仕事をしている人にとっては、レビューの導入が最大のニュースだろう。これからはデベロッパーやメンテナーが、すべてのプルリクエストを公式に承認したり、変更をリクエストしたりできる。またレビューのサマリ(要約)を残したり、コメントをモデレート(司会調停)できる。ただし公式のレビューがなくても、インラインのコメントを残すことはできる。

7fb44b30-7976-11e6-9674-8a32a92506ff

GitHubのCEOで協同ファウンダーのChris Wanstrathが、今日の発表声明で言っている、“これによって、一行のコードに関して複数の会話をサポートでき、個々のフィードバックループが明瞭になり、会話の質も上がり、良質なコードレビューが可能になる。しかしコードレビューは今後さらに、もっと敏速かつフレンドリーなものにしていきたい。今すでにこの機能の改良に取り組んでおり、その中には同僚などにレビューをリクエストする機能もある”。

また今回のアップデートでGitHubは、単なるコードを超えて、簡単な「かんばんボード」のようなプロジェクト管理機能を加えた。これまでもGitHubはさまざまなプロジェクト管理ツールの統合をサポートしていたが、これからはプルリクエストと一緒にカードを動かしたり、カラムのあいだに“やってます”、“やりました”、“できません”などなどの注記を入れられる。Trelloなどのように、カードをドラッグ&ドロップで別のカラムへ移動できる。

6f8a5a1a-7976-11e6-8708-10e6aeb49251

今日のアップデートではさらに、GitHubのAPIが改良されて、たとえば、サードパーティのサービスが自分のサービスをGitHubに容易に統合できるようになった。また、新しい機能やAPIは、一般公開の前に“試用サービス”が提供される。

そしてエンタープライズユーザーは、ひとつのアカウント上のすべてのメンバーに二要素認証を強制できる。SAMLベースのシングルサインオンもサポートする、と言っているが、その日程は明言されなかった。

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

Facebookの人工知能研究所がオープンソースで公開したfastTextは深層学習の遅さを克服したテキスト分類ソフトウェア

facebook-search

Facebookでは毎日、何十億ものコンテンツがシェアされている。その膨大な量とペースに漏れなく遅れなく対応できるためにFacebookは、さまざまなツールを駆使してテキストを分類している。多層ニューラルネットワークのような従来的な方法は正確だが、ニューラルネットワークは訓練が大変である。

分類に正確さと容易さの両方をもたらすために、Facebookの研究部門Artificial Intelligence Research(FAIR)ラボはfastTextというものを開発した。そして今日(米国時間8/18)はそのfastTextがオープンソース化され、デベロッパーはどこででも、そのライブラリを使ったシステムを実装できることになった。

fastTextはテキストの分類と、語のベクタ表現の学習の両方をサポートしている。後者には、bag of wordssubword information(部分語情報)*などのテクニックが用いられる。skip-gramモデルに基づいて語は文字のn-gramのバッグとして表現され、それらは各文字のn-gramを表すベクタで表現される。〔*: 部分語情報、‘あかい’なら、あ、か、い、あか、かい、などが部分語。〕

“カテゴリー数のとても多いデータベース上で効率的であるために、fastTextは階層的な分類を用いる。そこではさまざまなカテゴリーがフラットなリストではなく二分木構造に編成される”、FacebookのArmand Joulin, Edouard Grave, Piotr Bojanowski, Tomas Mikolovらがドキュメンテーションでそう述べている。

bag of wordsのbag(バッグ)は、配列やリストや木(ツリー)などなどと並ぶコンピューター上の一般的なデータ構造の一種で、名前(“袋”)の名のとおり、データに順序性がなく、この場合は各語の出現頻度を各語が情報として持つ。“語(words)”は多次元空間として表現され、クェリとカテゴリー分けされた語の集合との関係を線形代数を使って計算する。コンピューターにテキストを投じたとき、それはゼロからのスタートになる。それに対して人間の大人はすでに文法知識を持ち、どこが語の始まりで終わりかを知っている。コンピューターの計算力は強力だが、そのままでは“I love TechCrunch”と“CrunchLove iTech”の違いを認識できない。そこでこのような方法では、ことばに対する定性的な分析を、統計的手法などにより、定量的な分析へと強制的に変換する。

そして数を操作する処理が主体なので、fastTextは従来の深層学習の方法(多層ニューラルネットワーク)よりも速い。下図は、Facebookが作った比較表だ。実行時間が「秒」の単位なのは、fastTextだけである:

fastTest

fastTextは英語だけでなくドイツ語やスペイン語、フランス語、チェコ語などに対しても使える。

今月の初めにFacebookは、クリックベイトをやっつけるアルゴリズムを同社のNewsfeedに実装した。そのアルゴリズムは言葉以外の要素(繰り返しパターンなど)も点検するから相当複雑だが、デベロッパーはfastTextを利用して同様のツールを自作できる。

Facebookによると、fastTextなら、“ふつうのマルチコアのCPUを使って、10億語を10分弱で学習できる。また、50万のセンテンスを30万あまりのカテゴリーに5分弱で分類できる”、という。これはすごい、かもしれない。

今日(米国時間8/18)からFacebookのfastTextは、GitHub上で入手できる。

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

Googleが謎めいたOSをベータテスト中―Fuchsiaは小さなIoTデバイスでも走る

2016-08-16-fuchsia

Googleは新しいOS、Fuchsia〔フクシア=花の品種名〕を開発中だ。その最初の成果はGithubに公開されており、勇気あるユーザーは自分で実行プログラムをコンパイルすることもできる。

このOSは根本的にAndroidともChrome OSとも異なっている。そもそもLinuxカーネルを使っていない。コアとなるコードはMagentaと呼ばれる。 IoTなどで特定の目的のための組込OSとして用いるのに向いているようだ。

Googleのプロジェクト・メンバー、Travis Geislebrecht以前はPalm、Appleに所属していた他、DangerのOSプロジェクト、Jawbone向け組込OSの開発チームで働いた経験がある。Geislebrechtによれば新OSのコアはRaspberry Pi 3で動くという。これからするとおそらく車載エンタメ、交通信号、デジタル腕時計などのデバイスから上はスマートフォン、タブレット、パソコンまであらゆるプラットフォームで動くのだろう。

Fuchsiaが現実に利用できそうなシステムについてのアイディアは多様だが、理屈からいえばどんなデバイスでも動くということは現行のChrome OSやAndroid OSに代えて使えるだろうし、現在Android Wearが用いられているスマートウォッチではいっそうの低消費電力を達成できるはずだ。

AndroidとChrome OSの成功から次世代OSの体験がどういうものであるべきか多くを学んでいることから考えてもGoogleが「世界を統べる一つのOS」を開発しているというのはいささか不気味だ。ゼロから作り直すことによって現在のAndroidにくすぶり続けている問題も根本的に解決されるだろう。たとえばAndroidのアップデートはキャリヤやメーカーに任されてるため、多くのユーザーは数世代も前のOSを使い続けなければならない破目になっている。

もちろんFuchsiaは航空機でいえばロッキードのスカンクワークスのプロジェクトのようなもので、ひょっとすると人知れず消えてしまうかもしれない。しかしGoogleが加速度的にデジタル化、ネットワーク化を続ける世界に適合した独自のOを作るというのは理にかなっている。いまやわれわれが目にするほとんどの製品にはなんらかの形でコンピューターが組み込まれており、したがってネットワークを介して相互につながることが可能だ。

Via Engadget

More: Android Police

画像Justine K/Flickr UNDER A CC BY-SA 2.0 LICENSE

[原文へ]

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

Facebookがすべてのオープンソースプロジェクトの窓口をGitHub上に一本化、それをFacebook Incubatorと呼ぶ

BERLIN, GERMANY - FEBRUARY 24:  Coffee mugs adorned with the Facebook logo stand at the Facebook Innovation Hub on February 24, 2016 in Berlin, Germany. The Facebook Innovation Hub is a temporary exhibition space where the company is showcasing some of its newest technologies and projects.  (Photo by Sean Gallup/Getty Images)

【抄訳】
先週Facebookは、Reactによる開発を簡易化するためのプロジェクトCreate React Appを立ち上げた。しかし実はそれは、もっと大きな話の一部だった。GitHub上にFacebook Incubatorというものが作られ、そしてCreate React Appはそこに入る最初のプロジェクトなのだ。

Facebook Incubatorは、Facebookがオープンソースのプロジェクトをリリースするときの総合窓口になる。しかも今後長期的に。それは、Facebookが提供するオープンソースプロジェクトのベータのためのステージ、実験場、のようなものだ。

Facebookのオープンソース部門の長、James Pearceによると、主なねらいは、すべてのプロジェクトの良質なライフサイクル管理を維持すること。Facebookがオープンソースにしたプロジェクトはこれまでにおよそ400あり、GitHub上には数十万のフォロワーがいる。“どんなに数が多くなっても、良質な管理をキープしたい”、と彼は語る。そのために、すべての新しいプロジェクトが最初にこのFacebook Incubatorに入り、コミュニティの反応や採用の過程を一望できるようにする。

Pearceが強調するのは、このIncubatorはFacebookのそのほかのルートリポジトリの場合と同じく、同社自身が社内的に使うプロジェクトであり、活発に開発とメンテナンスを続けるチームが必ず存在する。休眠プロジェクトのための物置ではない。

このIncubatorを卒業するためには、ユーザーや愛好家が多くなることはもちろんだが、そのほかに、Facebook内部やその関連以外でも使われるようになっているか?、良質なドキュメンテーションが完備しているか?、ほかのツールと容易に統合できるか?、などが、重要な要件となる。Facebookがそのユーザーコミュニティにエンゲージできることも、要件の一つだ。

“業界全体からの反応があれば、それは、卒業してもよい兆候だ”、と彼は述べる。〔卒業、よりも、独立、と言うべきか?〕

Pearceは、ドキュメンテーションの重要性を何度も強調した。オープンソースでは、ドキュメンテーションが粗略になることが、少なくないからだ。Facebookは、このFacebook Incubatorリポジトリ専任の、テクニカルライターのチームを確保し、また技術者たちもドキュメンテーションの良質化に積極的に協力すべし、としている。また一部のドキュメンテーションに関しては、StackOverflowがこのたび新設したドキュメンテーションサービスも利用する予定だ。

なお、Open Compute Projectなどの、大きな組織や企画に属するオープンソースプロジェクトは、このIncubatorリポジトリには最初から入らない。デベロッパーは、最初からそっちの方へアクセスするだろう。

【後略】

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

GitHub Enterpriseがアップデート、クラスタをサポート、デザインを一新

2b38e278-8c46-11e5-8a25-06aa80342ad1

コード管理ツールGitHubのオンプレミスバージョンGitHub Enterpriseが今日(米国時間2/9)、大型アップデートを行う。最近はしかし、このプロダクトの重要性をめぐって、GitHub内で経営陣のごたごたがあったばかりだ。

アップデートされたGitHub Enterprise 2.5の最大の目玉は、クラスタのサポートだ。企業はGitHub Enterpriseのサーバー群をクラスタとしてセットアップでき、それが単一のインストールのように動く。それにより、従来より相当大きなチームでもサポートできる。

GitHubのプロダクト担当VP Kakul Srivastavaはこう述べる: “GitHub Enterprise 2.5は、チームが大きくなって人数が増えても利用できる。顧客の中には、何万人ものデベロッパーを抱えてその全員が協働しなければならない企業もある。だからスケーラビリティの提供が、きわめて重要だ”。

さらに彼女は、GitHubのクラスタリング機能はエンタープライズのユーザーに新たなコストを発生させない、とも言った。

このニューバージョンでは、ログイン画面からGitHubリポジトリのルック&フィールに至るまで、インタフェイスが全面的に改良され、デザインも新しくなった。エンタープライズバージョンが通常のクラウドバージョンと肩を並べた、と言えそうだ。

また、gitをバージョン管理システムとして使わない場合の、サブバージョンのサポートも改良された。そして、保護ブランチを保護するためのAPIが提供された(そのブランチは削除もコードの強制プッシュもできない)。ただしこのAPIは、まだプレビューである。

Srivastavaにどうしても聞きたかったのは、最近のエンタープライズ顧客への注力によって社内がギクシャクしているという噂と、従来からのクラウドプラットホーム上のユーザーとの関係だ。

Srivastavaが書いてくれた返事では、GitHubは今、“新しい種類のエンタープライズ企業を作りつつあると思う。社内的にもまた顧客にとっても、それは、オープンソースかエンタープライズかという問題ではない。むしろ、オープンソースもエンタープライズも、だ。GitHubは、デベロッパーがコードを書くとき、どんなときでもお役に立ちたい。それは、個人的なプロジェクトでもよいし、オープンソースのコミュニティでもよい、そしてまた、銀行やリテイルや製造業など、大規模で本格的なエンタープライズの開発でもよい”。

全然、企業文化の変化に関するぼくの関心には答えていないが、でも企業としてのGitHubの将来が、コード管理ソフトウェアとしての、エンタープライズ顧客による採用の増加にかかっていることは、確実だ。

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

GoogleがロードバランサーSeesawをオープンソース化(Go言語で書かれている)

14068599850_c589927a7b_o

Googleが今日(米国時間1/29)、ロードバランサーSeesawをオープンソースにする、と発表した。このLinuxアプリケーションはGoogleのGo言語で書かれていて、これからはApacheライセンスによりGitHubで入手できる。

Googleのインフラの日常的メンテナンスを担当しているSite Reliability Engineer(SRE)の一人Joel Singが、今日の発表声明で述べているところによると、Googleは2012年までは二種類のロードバランシングシステムを使っていたが、しかしどちらも、“管理と安定性に問題があった”。そこで、彼と彼のチームは新しいソリューションを探したが、Googleのニーズを満たすものがなかったので、自作することになった。

“要求はそれほど複雑ではなかった。必要なのは、ユニキャストとエニーキャスト仮想IPを扱えること、NATDSR(またの名DR)でロードバランシングができること、そしてバックエンドに対する健康診断ができることだ”、とSingは書いている。“何よりも必要なのは、管理のしやすいプラットホームだった。構成を変えたときのデプロイの自動化、とかね”。

一部ではすでにネットワークレベルのロードバランシングにLinux Visual Server(LVS)を使っていたから、Singのチームもそうすることにした。ただしそれに加えて彼らは、 モジュール構造のマルチプロセスアーキテクチャと、フェイルオーバーやリカバリのサービスも実装した。

“開発は短期間で集中的に行い、完成しデプロイにも成功したSeesaw v2で二つの既存のプラットホームをリプレースした”、とSingは書いている。“これにより、全体的に、サービスの可利用性が向上し、管理のオーバヘッドが減った”。

なお、このプロジェクトの提供者はGoogleだが、オープンソースのバージョンはGoogleの公式のプロダクトではない。だから、サポートをGoogleに求めることはできない。

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

Microsoftが機械学習ツールキットCNTKをGitHubに移しMITライセンスを適用

shutterstock_192614108

Microsoftが今日(米国時間1/25)、デベロッパが同社のComputational Network Toolkit(CNTK)を使って深層学習(ディープラーニング, deep learning)アプリケーションを作りやすいように、プロジェクトをGitHubに載せ、MITのオープンソースライセンスを適用することにした。Microsoftがこのツールキットをオープンソースにしたのは2015年の4月だが、コードはMicrosoft自身のCodePlexサイトでホストされ、これまでは大学向けの、制約のあるライセンしかなかった。

前のライセンスでも研究者たちはプロジェクトにアクセスできたが、プロダクション用途に使うとか、大学の外の環境でいじくることには向いていなかった。今度の新しいライセンスと、GitHubへの移行により、Microsoftはそのほかのユーザも惹きつけたいと願っている。

speed-comparison

Microsoftのチーフスピーチサイエンティスト(chief speech scientist)Xuedong Huangは今日の発表声明の中で、CNTKはとくにスピードが高度に最適化されている、と述べている。“CNTKツールキットは、これまでわれわれが見たどれよりも、桁外れに効率的である”、とHuangは言っている。ここでHuangが比較対象にしているのは、Googleが最近オープンソースにしたTensorFlowや、TorchTheanoCaffeなどのプロジェクトだ(上図)。

Microsoftの主張によると、CNTKのアドバンテージは、シングルコアの上でも使えるし、また、GPUベースのマシンの大規模なクラスタでも使えることだ。しかも、他社のプロジェクトに比べてスケーラビリティが良く、多くのマシンに対応できる(もちろん今その検証はできないけど)。

Microsoftは昨年、もうひとつの機械学習ツールキットDMTKを、ひそかにローンチしている。DMTKは”distributed machine learning toolkit”(分散機械学習ツールキット)の頭字語で、大量のデータを効果的に分析することに力点を置いている。

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

GitHubがU2Fセキュリティキーをサポート、より強力な二要素認証を導入

GitHub Yubico partnership

今日(米国時間10/1)GitHubは同社初のユーザカンファレンスGitHub Universeを開催し、その席で、Yubicoなどが提供しているセキュリティキーFIDO Universal 2nd Factor(U2F)のサポートを開始する、と発表した。それはUSBポートに挿入して使う文字通りの“鍵”デバイスで、挿入すると第二要素の認証コードを自動的に生成するので、Google AuthenticatorやAuthyなどの6桁のコードを手入力する必要がない。

二要素認証はフィッシングや中間者攻撃の撃退に効果的だが、完全な対策ではない。しかしU2Fセキュリティキーを使うと、サイトと情報交換をせず、最初のセットアップ時にすでに認証されているから、ログイン時の欺瞞行為が難しい。ただし今のところU2FをサポートしているブラウザはGoogleのChromeのみだ。〔もちろん相手サイトがサポートしていなければならない。〕

Edge-In-Use-3-blue-third1-444x224

GitHubはすでに、AuthenticatorのようなアプリやSMSにより、二要素認証をサポートしている。同社のセキュリティ担当VP Shawn Davenportによると、GitHubの現在の1100万のユーザのうち、約30万が二要素認証を使っている。この数をさらに増やし、またセキュリティキーの採用に弾みをつけるために、同社はYubicoとパートナーして最初の5000名の購入者にはキーを5ドルで提供し、その後の購入者には2割引きで提供する。

Davenportによると同社は最近、二要素認証のサポートに関していくつかの問題に遭遇した。たとえば、SMSを国際的に使うと、セキュリティの信頼性が落ちる。またスマートフォンを頻繁に買い換えるユーザが多く、そのときセキュリティトークンの移送を忘れて、認証アプリが動かない、ということもある。

YubicoのCEOでファウンダのStina Ehrensvardによると、今やGitHubは同社の三番目の大企業パートナーとして、U2Fキーの普及に努めてくれる。最初のパートナーはGoogleDropboxだ。彼女によると同社は今、これらのパートナーのおかげで伸びているが、Chrome以外のブラウザがサポートすることによってもっと広く普及させたい、という。今YubicoはMozillaやMicrosoftに働きかけているが、“彼らの動きは鈍い”そうだ。

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

Trelloの有料版‘Business Class’がアップデート、GitHubなどさまざまなサードパーティツールを統合

trello-slack-integration

2013年にプロジェクト管理サービスTrelloは、企業向けの有料サービス’Business Class‘をローンチし、そこにGoogle Appsの統合や、ユーザ全員ではなく部署別担当別などの管理機能を導入した。今日(米国時間9/15)同社は、この‘Business Class’をアップデートし、SlackやGitHub、Salesforceなどサードパーティツールの統合を導入した。

この新しい統合のことをTrelloはPower-Upと呼んでいるが、これによりTrelloがさらに使いやすくなる。たとえばこれまでのようにSlackとTrelloを別々に使うのではなく、Trelloのボード上のカードを数時間後にリマインドせよ、とTrelloに告げておくと、その時間にSlackがリマインダーをポップアップする。これまでの統合では、Trelloのカードやリストやボード上に何か基本的なアクティビティがあったとき、Slackのアップデートもらうだけだった。

さらにGitHubの統合では、コミットメッセージやプルリクエストなどGitHubの詳細情報を、Trelloのカードのリアルタイムなアップデートで見ることができる。このほか、BoxやGoogle Drive、Google Hangouts、Dropbox、Twitter、Evernote、Salesforce、Mailchimp、Help Scout、appear.inなどのサービスも今回のアップデートで統合される。

Trello-Slack-Integration

これらの統合化はTrello Enterpriseのユーザに提供され、今回のアップデートの目玉だが、さらに‘Business Class’のユーザにはボードのコレクション機能が提供される。これは複数のボードを種類別タイプ別人数別などにグループ化できる機能で、ボードを、調べる目的別に容易にフィルタリングできるようになる。

Org-Boards-Page

小粒度の管理機能や、企業の機密情報の保護などは、これまでの‘Business Class’と変わらない。たとえばチームへの新規参加者や、外部ビューワー(‘見物人’)をアドミンの権利で決めることができる。

‘Business Class’のアップデートには、プライオリティのサポートも含まれ、料金はユーザ一人あたり月額10ドルだ(アクティブユーザにしか課金されない)。既存のユーザには割引料金が適用されるが、古いバージョンをそのまま使い続けてもよい。

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

GitHub、シリーズBで2.5億ドルを調達。これからはリスクも冒す

4858486575_17a28e7b11_o

ソフトウェア開発の協同作業とバージョン管理サービスをオープンソースのGitツールで提供するGitHubが、Sequioa Captalのリードで2.5億ドルの資金を調達したと今日(米国時間7/29)発表した。Andreessen Horowitz、Thirive CapitalおよびInstitutional Venture Partnersも本ラウンドに参加した。

同社は2008年に設立され、これまでに計3.5億ドルを外部資金から調達した。会社は評価額について語っていないが、WSJの記事によると、現在20億ドル前後をさまよっているという。GitHubの2012年のシリーズAラウンドは、Andreessen Horowitzがリードした。当時同社の評価額は7.5億ドル前後だったとみられている。

GitHubのCEO・共同ファウンダー、Chris Wanstrathが新ラウンド発表の直後、同社はこの新規ラウンドを利用して成長を加速し、(殆どの会社がそうするように)営業および技術チームを拡大するつもりだと私に話した。「ラウンドは加速のためではなく、われわれが大きく考え、大きなリスクを負えるようになるため」とWanstrathは言った。

Chris Wanstrath

Chris Wanstrath

これはGitHubの買収が近いらしいことを意味しているが、彼は海外戦略を推進したいとも話した。最近同社は日本にオフィスを設立し(最初の会合も開いた)、他の地域でも進めていくに違いない。

「われわれにとって、GitHubはまさしくデベロッパーがすべて ― 本質は人だ」とWanstrathは言った。「これまでやろうとしてきたのは、コミュニティーを支える人々をもっと多く集めることだ」。

既にGitHubユーザーの約70%は米国外から来ているので、ユーザーのいる所に会社が出ていくのは自然の成り行きだ。

GitHubの企業向けサービスも、2011年に立ち上げて以来極めて順調に伸びており、これは多くの大企業が古いソフトウェア開発手順を改め、Gitのようなツールで改革しようとしていることも一因だ。同社は企業数については明らかにしていないが、Wanstrathは私に「驚くほど順調」であり、このところ「絶好調の四半期」が続いていると話した。

Gitが、多くのスタートアップでバージョン管理システムの事実上の標準となっており、現在GitHubが〈サービスとしてのGit〉を提供する各社をリードしていることは間違いない。Atlassian、Microsoft、GitLab等もクラウドあるいは社内用に同様のサービスを提供しているが、GitHubがここ数年多くの人々の心を把んでいることは明らかだ。

GitHubは、現在約1000万人のユーザーが2500万以上のプロジェクトで(2014年1月には1000万だった)協同作業を行っていると言っている。同社が無料アカウントを配布していることを踏まえると、それらユーザーの何人がこのサービスに料金(5ドル/月から)を払っているかはわからない。

[原文へ]

(翻訳:Nob Takahashi / facebook

GitHub、Atomテキスト・エディタの安定版1.0をリリース―月間アクティブ・ユーザーは35万人

2015-06-26-githubatom

今日(米国時間6/25)、GitHubの高度にカスタマイズ可能なAtomテキスト・エディタが1.0となった。Atomが一般公開されてからまだ1年しかたっていないが、すでに130万回ダウンロードされ、月間アクティブ・ユーザーは35万人にもなる。この間、Atomの開発チームは155回もアップデートをくりかえし、大量の新機能を追加してきた。

しかしさらに重要な点は、Atomのユーザー・コミュニティーが2090種類もの拡張機能パッケージと660種類のテーマを作り出したことだろう。

AtomプロジェクトはGitHubの共同ファウンダー、Chris Wanstrathによって2008年に始められた。当時はAtomicityと名付けられ、その目標は一般的なウェブ・テクノロジーを用いてデベロッパーが自由にカスタマイズできるコード・エディタを提供することだった。GitHubが成功し、Wanstrathが多忙になったため、Atomプロジェクトは2011年まで棚上げ状態になっていた。その後3年かけて開発が行われ、Atomのベータ版が一般公開されたのは2014年になってからだった。

pasted image 0 (1)

1.0というバージョン番号が示唆するとおり、今回リリースされたAtomはコア部分が安定したプロダクトになったと考えられている。GitHubチームはリリース・ノートで「これまでの努力は主として1.0という安定したAtomの基盤を作ることに向けられてきた。その基盤が完成したからには、われわれはこのプラットフォームの持つ潜在能力を全面的に開花させる努力に重点を移すことができる。」と述べ、さらに将来の展望を次のように述べている。

もちろんわれわれはパフォーマンス、安定性、コアなユーザー体験をさらに改良していく。国際的なサポートの拡大も重要だ。しかし新たな可能性の追求は単なる細部の改良にとどまるものではない。われわれは次のようなテーマを自らに課している。「スーパー・ディープなgitへの統合はどういうものになるだろうか?」、「テキスト・エディタにおけるソーシャル・コーディングとは?」、「パッケージ開発者が好みの言語でIDEレベルの機能を実現するために何が必要か?」

他のコード・エディタの開発チームもこうした課題に向かっていることだろう。しかしAtomのように層が厚く活発なデベロッパー・コミュニティーの支持を得ているエディタは他にない。 Atomのモジュラー性はきわめて徹底しており、たとえばFacebookがデベロッパー向けにリリースした開発環境Nuclide IDEのベースとしてカスタマイズしたAtomが用いられている。

[原文へ]

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