ブックマーク / voluntas.medium.com (7)

  • 同時接続 700 万、秒間 2 万通という Nintendo Switch 向けプッシュ通知システム NPNS の資料を読んで

    AWS Summit Tokyo 2018 で実施されたセッション資料・動画をダウンロードすることができます。(順次公開) ※AWS Summit 2018 へお申し込みいただいていない場合、別途ダウンロード申し込みが必要となります。… 【任天堂様ご登壇事例】Nintendo Switch (TM) 向けプッシュ通知システム「NPNS」AWS はよくわからないので Erlang/OTP 視点のみです。 ejabberdejabberd はフランスの ProcessOne という会社が開発している XMPP サーバです。XMPP が何かはここでは説明しません。 ejabberd は TLS や XML 周りの性能を出すため C で書かれている以外、他はすべて Erlang/OTP で書かれています。 ejabberd の歴史はとても古く、自分が Erlang を学び始めた頃にはすでにありまし

  • リモートワークとの付き合い方

    A very smart man versus a very smart machine. Can an undisputed board game king conquer artificial intelligence? Watch… NetflixAlphaGo が話題になっているので Netflix を再契約して見てみた。とても良かった。 見ていて思ったのが DeepMind 社の社員たちが事ある毎にホワイトボードやメモ帳を持って議論をしていた。 もちろんこれはドキュメンタリーなので、全部が全部そうではないとおもうが、とにかく顔を合わせて、その場にいて議論をしているように見えた。 働く場所は同じ場所で、皆ヘッドフォンをして作業をしていたし、スタンディングデスクもあった。ただとにかく顔を合わせて話をしているのが印象的だった。 自分のリモートワークに対する考えちょと書き出してみる

  • WebRTC を利用した配信の現実

    超低遅延、高画質な配信を実現するための選択肢の一つとして WebRTC があります。 ただ WebRTC はもともと少人数で双方向の配信を前提としているため、スケールしないというのが一般的な認識です。 せっかくなので WebRTC サーバを開発・販売している立場から WebRTC を利用した配信の現実がどの程度なのかを書いていこうと思います。 P2P モデルまずは WebRTC といえば P2P なので、WebRTC の P2P 利用についてお話する必要があります。 WebRTC の P2P 利用は、配信者が視聴者分の変換を行うという負担があることから、最大でも 10 名程度までしか配信できません。 さらに、何より配信者の PC 負荷がとても高くなるため、採用は趣味のページまででしょう。 ビジネスで P2P を配信に利用するのはとても現実的ではありません。 配信の場合は P2P で Web

    WebRTC を利用した配信の現実
  • HTTP API の設計方向

    見てみると、たしかに Get 系の API だとしても POST を利用しているし、API の URL 設計に get_shared_link_file のようによく言われる REST っぽい設計は使っていなかった。 この方針は同意だ。自分は結構前に REST っぽい API を捨てることにした。だからといって REST API がダメだとかは思っていない。 一般ユーザが使う場合の API は REST API であるほうが慣れ親しんでいる場合が多いからだ。 AWS で利用されている HTTP API 仕様AWS の DynamoDB の Erlang/OTP ドライバーを書いているときに気づいたのだが、AWS の一部のサービスはかなり独特な API の仕様になっている。

  • Erlang で仕事する一つの方法

    これは 2007 年頃の話です Erlang/OTP って何?という時期に Erlang/OTP で製品を作って利益を上げた日人はあまりいないとおもう。 せっかくなので振り返りついでに、自分の昔話を書くことにする。 Erlang/OTP の導入まで仕事でネットワークサーバを触ることになったのだが、当時の製品はシングルスレッドだった。当時はもうマルチコアだという話がでており、ではマルチコアを有効に使えるネットワークサーバを書くにはどうしたらいいのだろうか?というところから入った。 Erlang/OTP をやる前は Python で Django というところに興味があったくらい普通のウェブアプリスキーだった。 そのため何を血迷ったか Python でとりあえずネットワークサーバーを書いてみることにした。 stackless python 使ったり Twisted 使ったり multipro

  • WebRTC サーバを開発する理由

    ブラウザ同士がやりとりする WebRTC 、当たり前だが WebRTC をサーバ側に用意することでブラウザとサーバでのやりとりを実現する事ができる。 理由はたった一つでサーバ側で配信データをコントロールすることが出来るようになるからだ。 通常の WebRTC を使って一人が複数人に配信する場合はこうなる 大きく違うのはサーバがブラウザを管理したり、データの流れを管理できるようになることだ。これはニコニコ動画の生放送をイメージして貰えば良いと思う。 もちろんサーバを経由することでサーバ側での録画も可能になる。もともとクライアント側で録画はできたが、P2P で動作されるとサーバ側での録画は難しくなるからだ。 これらの仕組みをプラットフォームとして提供しているのが tokbox だ。

    WebRTC サーバを開発する理由
  • Electron が良さそう

    注意: 私は Electron を触ってみたわけではありません。単に、色々なところに書いてある資料を読んだだけで、これを書いてます。 Electron は元々 atom-shell で Atom を作るために作られたとか何とか思っていたが、Qiita の Kobito for Windows が Electron で作られていてとてもよさそうだと感じたので、ちょっと調べてみた。 良さそうだと思ったところ Chrominium ベースなので HTML/JS/CSS で開発単独ネイティブアプリ(Mac/Windows/Linux)WebSocket や WebRTC が使えるブラウザで表示してはいるけど、固定環境になるので互換とかを考えなくてよい。色々あるのだけれど、思いつくだけで結構メリットがある。デメリットはおそらく実際に作っていくと色々あるのだろう。そこはまぁ、手を動かすしかなさそう。自

  • 1