自社 OSS のコミュニティ運用を Discord に集約した
自社の OSS と無料サービスのコミュニティをすべて Discord に集約しました。かなりうまく回っていると思っているので、どんな感じで運用しているかを書いていきます。 前提IT 系パッケージメーカーな零細企業クローズド自社製品で食べているOSS へのサポートは提供していない無料サービスへのサポートは提供していないOSS へは積極的に投資しているロードマップにある機能を有償で前倒して実装することもあるコミュニティマネージャーの採用信頼できる技術者に副業としてコミュニティマネージャーをお願いしています。 仕事内容は責任はなく、基本的には誰かがチャットをしたときに反応をしてもらうというものです。質問しやすい空気を作ってもらっています。 また、コミュニティマネージ以外に検証の仕事も合わせてお願いしているます、そのため OSS やサービスをユーザ視点で触っており、技術もわかるコミュニティマネージ
リアルタイム映像配信サーバ開発者からみた STADIA
まず、この記事では、STADIA で快適にゲームができるかどうかという話はしません。技術的にどうなの？というのを想像込みで書いていきます。 誰だよお前、って言われそうなので … 自分は WebRTC の通信部分と QUIC スタックの実装をフルスクラッチでしており、日本で多くの会社に採用されている WebRTC を利用したミドルウェア製品の開発者です。WebRTC を利用して 4K@30 をサーバ経由で配信というのを実現したりしています。 利用している技術STADIA が利用している通信技術は WebRTC (と QUIC)です。これは Project Stream という STADIA リリース前に公開された実験的プロジェクトがまさにそうでした。Project Stream の VP である Majd Bakar 氏がインタビューで回答しています。 Project Stream は 10
Chrome リモートデスクトップ – V – Medium
ブラウザだけで利用できるリモートデスクトップ機能。使う側のマシンにセットアップするだけですぐに使えるようになる。 Chrome 拡張と、専用のアプリをいくつかインストールするだけ。とてもインストールは簡単。ほぼほぼマウスクリックするだけで終わり。 あとはマシンの名前とピンコードを登録さえすればピンコードがわかっていればアクセスできる。 この Chrome リモートデスクトップが今までのリモートデスクトップと大きく違うのはブラウザで実現していることだろう。 そしてこの Chrome リモートデスクトップはがっつり WebRTC を利用した仕組みだ。WebRTC P2P で実現している。 VP8 でリモート先のマシンの全画面を WebRTC MediaChannel を利用して P2P 経由で送っているリモート側のマウスやキーボード情報を WebRTC DataChannel を利用して P2
同時接続 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 を学び始めた頃にはすでにありまし
フルリモートワークを諦めた
正社員のフルリモートワーク採用を目標としていたが諦めた。 現在、自社では週１出社それ以外は自宅からのリモートワーク社員がいる。一緒に働いて感じたことはフルリモートワークの場合はうまくやっていくことはかなり難しいだろうと感じたことだ。 自社では自社パッケージ製品を開発している。この開発には双方向のコミニュケーションがかなり必要になる。特に顔を突き合わせて話すというのがとても重要になる。さらに感覚的な話も多くなりがちだ。 実際、週１出社してる社員とはよく話をする。仕事の話、雑談。本当に色々話をする。 特に自社は社員も少なく１社員が担う範囲も多く、意思疎通がとても重要になる。これが週１出社してもらうだけで、かなり違う。ギャーギャー面と向かって話ができるというのはとても重要だと感じたのだ。 フルリモートワークになると出社は月１回とかになるだろうか、大きめの企業であればうまくタスクが分担できたりして
カスタマイズしないとどうなるか
続き。自社製品のミドルウェアでカスタマイズをしないと実際にどうなるかを書いていく。 カスタマイズの相談をされた場合一切対応していない事を伝える。メールが返ってこない事が多い。そのためビジネスチャンスを逃している可能性は高いが、カスタマイズをするリスクのほうが高いため問題ない。 カスタマイズを要求していくる会社から相手にされなくなる。 注文から提供までメールにて申込書を送り、記載して返送してもらう総務が社内に立っているライセンスサーバでライセンスを発行する製品のダウンロード URL とライセンスファイルをメールで送る終わり。製品の提供まで 30 分くらい。自社製品は最小ライセンスの費用が 60 万円/年なので 30 分で 60 万円の売上になる。これが毎年。 この後はサポートのお仕事。 サポート対応全ての顧客が同じ製品を利用しており、自社製品は最新版を利用していることがサポートを受ける前提と
WebRTC を利用した配信の現実
超低遅延、高画質な配信を実現するための選択肢の一つとして WebRTC があります。 ただ WebRTC はもともと少人数で双方向の配信を前提としているため、スケールしないというのが一般的な認識です。 せっかくなので WebRTC サーバを開発・販売している立場から WebRTC を利用した配信の現実がどの程度なのかを書いていこうと思います。 P2P モデルまずは WebRTC といえば P2P なので、WebRTC の P2P 利用についてお話する必要があります。 WebRTC の P2P 利用は、配信者が視聴者分の変換を行うという負担があることから、最大でも 10 名程度までしか配信できません。 さらに、何より配信者の PC 負荷がとても高くなるため、採用は趣味のページまででしょう。 ビジネスで P2P を配信に利用するのはとても現実的ではありません。 配信の場合は P2P で Web
Discord の採用している技術
Discord はゲーマー向けのボイスチャットサービス。テキストチャットもできるし最近ではビデオチャットや画面共有もできるようになった。 UI はかなり Slack に似ている、モダンなデザインということなんだろう。 WebRTC 技術を利用しているということで、とても気にはなっていたが使うタイミングがなかったことからあまり追いかけていなかったが、先日ビデオチャットと画面共有が追加されたということで色々調べてみることにした。 ElectronWindows/Mac/Linux 向けのデスクトップクライアントには Electron を採用している。かなり早い段階から採用しているイメージ。Electron は Chromium ベースなので WebRTC が利用できる。WebSocket もバリバリ使ってる模様。 Electron を使うことでブラウザとほぼ変わらぬ動き、UI を再現している。
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 の仕様になっている。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
