オンラインドキュメントと日本語全文検索
自社では Sphinx というドキュメントツールを利用しているのですが、残念ながらこれに付属している検索機能の日本語検索はかなり厳しいです。また残念ながら Sphinx 開発側も検索周りを改善するという予定は直近ではないようです。 そして検索というのはとても難しい技術なため自分のような素人では導入して「普通に期待する動作」をさせるまでの距離はとても遠いです。 ただ、なんとかして日本語全文検索を実現したいという思いはここ10 年くらいずっと思っていました。これは自社の Sphinx テーマを作ってくれている社員ともよく話をしていたのですが、どうしてもリソースをつぎ込めずにいました。 まとめ日本語検索に対応している Meilisearch を採用したドキュメントスクレイパーの実行は GItHub Actions (Self-hosted Runner) を採用した自社 Sphinx テーマの検
Zoom が DataChannel を利用している理由について考えてみた
This is the home of the whitepaper documenting Zoom's planned end-to-end encryption system. The latest released PDF… 現在の実装から今後どうしていくかをかなり詳細に書いていますので、まずはこちらを読んでみることをおすすめします。 Zoom の暗号化/復号Zoom の暗号化/復号はすべてクライアントで行われ、Zoom のメディアルーターは基本的に干渉しないという設計のようです。WebRTC SFU とは異なり、基本的にはリレーサーバのような役割を果たしているようです。 ただしここからがポイントでクライアントが暗号化/復号に利用する鍵は参加者全員が同じものを利用します。さらにこの鍵はZoom サーバが配布します。 鍵自体の変更は一切行われず、1 鍵 1 会議という仕組みのようです
お手伝い先でやったこと、やってること
2020 年 1 月から株式会社ZIZAI の IRIAM で「雑談するおっさん」をしています。なにをやったか、なにをやってるかを書いていこうと思います。ちなみに自分の本業は開発者です。 まずお手伝いする上で条件を出しました。 サーバ/インフラに関する技術決定権採用判断権組織改善権評価改善権結果としては偉い人から「何やっても構いません、全部おまかせします」って返ってきました。 さて、やったこと、やってることを箇条書きで書いてみました。技術的な話の詳細は内緒なので書きません。 Twitter での定期的な採用告知自分への Slack DM の禁止自分への返信はスレッド禁止（好み問題）可能な限り即決断する自分だけでは決断できない場合はいつまでに判断する旨を伝えるSlack のパブリックで #shiguredo を作ってもらい、自分とはそこでのみ会話するエンジニアの上下関係の削除プライベートに対
Erlang & Elixir Fest 2019 で発表してきました
資料は Erlang/OTP で WebRTC と QUIC です。Erlang/OTP 自体の話はほとんどせず、どんなミドルウェアパッケージを Erlang/OTP で開発しているのか、どんな体制で開発してるのかあたりをざっくりと話させていただきました。 今回の発表は初めて「自社製品」と「Erlang/OTP」と「WebRTC」を組み合わせた発表です。この全部合わせたテーマでの発表はこれが最初で最後になると思います。普段はそれぞれ独立して発表しています。 そもそも自分は自社製品が何でできているかとか興味なくて、今まで自社製品が Erlang/OTP を利用しているということはアピールしてきませんでした。そもそも何で作られていようがいいものはいいという考えです。 ただ数年前に から「自社製品が Erlang/OTP で作られていることをアピールしてほしい」という相談をされたことがありました
リアルタイム映像配信サーバ開発者からみた STADIA
まず、この記事では、STADIA で快適にゲームができるかどうかという話はしません。技術的にどうなの？というのを想像込みで書いていきます。 誰だよお前、って言われそうなので … 自分は WebRTC の通信部分と QUIC スタックの実装をフルスクラッチでしており、日本で多くの会社に採用されている WebRTC を利用したミドルウェア製品の開発者です。WebRTC を利用して 4K@30 をサーバ経由で配信というのを実現したりしています。 利用している技術STADIA が利用している通信技術は WebRTC (と QUIC)です。これは Project Stream という STADIA リリース前に公開された実験的プロジェクトがまさにそうでした。Project Stream の VP である Majd Bakar 氏がインタビューで回答しています。 Project Stream は 10
HTTP/3 や QUIC はまだ早すぎる
フューチャーアドベントカレンダー2018](https://qiita.com/advent-calendar/2018/future)のピンチヒッターです。ワイキキの海を見下ろすホテルからこんばんわ。 QUICがリブランドされて... 渋川の記事の補足というか、実装者目線からみた話を書きます。 立ち位置仕様策定には関わっていません。あくまで出てきた仕様を実装する実装者（Implementor) です。 また HTTP/3 や QUIC がメインというよりかは WebRTC がメインです。WebRTC が利用しているプロトコルが QUIC に置き換わる流れがきているため、QUIC を実装しており、さらに QUIC を利用したプロトコルとして、まずは HTTP/3 が採用されていることから、HTTP/3 に手を付けている状況です。 現時点では Chrome Canary M74 で利用可能な
自分が働きたい会社にしない
時雨堂は会社の仕組みを Gist でオープンにしている。実はあの仕組みは自分が働きたいと思う会社の仕組みではない。 時雨堂は 10:00–17:00 の定時制で 6 時間労働。さらには仕事は選べない。技術もあまり選べない。月給は安く抑えられており、賞与は保証なし。ただし儲かった場合は賞与を高めに出す。評価制度はない。 時雨堂で自分が従業員として働きたいとは思っていない。自分が従業員として働くのであれば、裁量労働で、仕事は好き勝手に選べて、給与は稼いだ分だけほしい。さらに技術は自分が使いたいものを使う。ただし食堂はあってほしい。 ではなぜ時雨堂は自分の働きたい会社になっていないのか。それは単純で自分はあくまで経営者であり、従業員ではないからだ。そして自分は社会不適合者であるため、従業員としてやっていけなかったから起業した身であるからだ。 つまり従業員としてやっていけなかった人が望む会社の仕組
製品品質と評価制度
時雨堂には自社製品の検証を専門に行う社員がいる。具体的な指示は特になく「自社製品の検証よろしく」しかお願いしていない。 朝会社に来てから夜帰るまで、特に何か言われることもない。負荷試験をしていたり、ロングラン試験をしかけたり、異常系の検証をしたり。つまり何をやってもいい。 成果報告も一切不要。コミットログをみて検証したり、ドキュメントを見て検証したり。ドキュメントはわかりにくい部分を修正。 ちなみに製品にバグを見つけた場合はパッチをチャットに貼ってくる。製品の修正は開発者がやれということらしい。 勘違いしてもらいたくないのが、担当している社員はコードはゴリゴリかけるし、AWS や GCP といったクラウドも使える。さらには社内ネットワークを構築したり、自社サーバの運用などもできる。 コードが書けないから検証を専門にしているとかではない。検証で利用する WebSocket クライアントは 1
リモートワークとの付き合い方
A very smart man versus a very smart machine. Can an undisputed board game king conquer artificial intelligence? Watch… Netflix の AlphaGo が話題になっているので Netflix を再契約して見てみた。とても良かった。 見ていて思ったのが DeepMind 社の社員たちが事ある毎にホワイトボードやメモ帳を持って議論をしていた。 もちろんこれはドキュメンタリーなので、全部が全部そうではないとおもうが、とにかく顔を合わせて、その場にいて議論をしているように見えた。 働く場所は同じ場所で、皆ヘッドフォンをして作業をしていたし、スタンディングデスクもあった。ただとにかく顔を合わせて話をしているのが印象的だった。 自分のリモートワークに対する考えちょと書き出してみる
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 を再現している。
つまみぐい勉強法
ここ数年、気になった自分の専門外の技術を少しずつだが試してみる事にしている。 対象は主にウェブ系の技術が中心だ。自分はミドルウェアが専門の領域のためウェブ技術を仕事で使うことはない。ただ、ウェブ系の技術と連携して使ってもらう場合も多いので、色々知っておこうと思って触ってみている。 方針は「自分が手を動かす仕事では使わない」「専門家になろうとしない」あたり。餅は餅屋なので専門家に任せる。ただこんなことがやりたいを伝える時に触ったことがあるかどうかはとても重要になる。 そこでとりあえず色々やってみる、つまりつまみぐいを積極的にやってみている。つまみぐいは長くても 1 週間触ってみるくらい。チュートリアルから毛が生えた程度で終わらせるようにしている。 もちろん、手を動かしてみたらとても楽しくて、専門家を目指そうとするのもよしとする。今のところは残念ながらそんな器用なことはできていないが。 つまみ
Mixer の技術的視点での凄さ
が Mixer について書いていたので、技術的な話をしようとおもう。 Mixer はマイクロソフトが買収した会社でもともとは Beam.pro というサービスだった。仕組み自体は今と変わらず、ゲーム配信をするという仕組み。 Mixer が他のゲーム配信サービスと違うのは HLS/MPEG-DASH といったストリーミング配信技術を採用せずに WebRTC というリアルタイム配信技術を採用したことだろう。 彼らは Janus という WebRTC Gateway を基盤として採用した。使うだけでなくフォークして、色々自前で改良を進めている。 Mixer が凄い点を上げてみる。 フル HD 、60 fps 、5Mbps での配信が実現可能ほとんど遅延がない、あっても 1 秒あるかないかクライアントを独自で作り込んでいる5Mpbs という高いビットレートでの配信を大規模に実現しているリアルタイム
値下げをしない
自分の方針としてもう一つ。値下げに応じないというのがある。 製品を売っていれば一度はかならず顧客から「料金交渉をお願いしたい」という名の値下げ交渉をされることがあるだろう。その場合は値下げは一切しないことを伝える。 もし値下げを粘られた場合は取引をしないほうが良い。また、値下げを一度でもしてしまうと、交渉さえすれば値下げをしてくれる会社と勝手に認識されてしまう。 顧客ごとの料金表は提供しないほうが良い。なぜなら世間は狭い。あの会社にはこの料金でだしているのに、なんてめんどくさい話も出てくる。 そのため、自分はすべての顧客に同一な料金表の提示。そして大量購入による割引。これ以上のことは一切やらない。顧客は相談はできず選択しかできない。 自分の会社の料金体系に合わない顧客とは取引をしないという方針を取っている。無理に値引きするのはその製品の寿命を縮めてしまう上に、会社の寿命も縮めてしまうと思う
社内デベロッパーサポートチームを作る
最近、自分が技術支援をしている会社で面白い取り組みをお手伝いしているので、書いてみようと思う。 あるソシャゲ会社の社内向けのデベロッパーサポートを行うチームを作るお手伝いをしている。 お手伝い先の会社は開発チームがスタジオ制となっており、幾つかのスタジオに別れている。それらのスタジオが使う技術や基盤を整えたり、スタジオのデベロッパーの開発をサポートしていくのが、デベロッパーサポートチームとなる。 さらに、スタジオが開発を行っている際の、アドバイスやサポート。さらには教育までを行う。スタジオ側の開発コストを下げるのが目的だ。 メンバーも自分以外は全員ゲーム開発の経験があるメンバーを選定している。そのためただの技術的なあたまでっかちというわけでない。 まだ全てできているわけではないが、最終的には実現するためにすすめていっている事を書き出してみた。クライアント側については自分は専門外のため省略す
野望
起業した時は野望はなかった。そもそも生きていければいいや程度だった。 その後、自社ビルがあったら楽しそうなんて話を顧問税理士や社員達として、自社ビルが当面の野望になった。 最近は今のような 1 日 6 時間という働き方で、社員に 4 桁万円の給与を提供したいというのが野望に加わった。 この野望を実現するためにどうしたらいいかをよく考えるようになった。 もともと自社でパッケージ製品を開発して販売した利益で会社を経営していくというのが目標だったが、思っているより短い労働時間で売上を上げるための仕組みが回っている気がする。 自社パッケージでカスタマイズしない方針のためすぐ納品可能落ちにくさを優先して開発しているため障害報告がいまのところゼロサービスではなくパッケージなので営業日対応のみ許される毎年利用料を頂くライセンス方式のため、良い製品であれば継続して利用料が毎年入ってくるドキュメントを充実さ
自社製品の売上で従業員の給与をまかなえるようになった
目標としていた社員の給与をすべて自社製品の売上でまかなうというのが達成できた。ということで自社製品ほんとうに売れるまでの距離が長いという話をしたい。 前提資金調達は一切していない社外のお手伝いしてお金を稼ぐ資金調達している時点で、そのビジネスに注力できるのでこの話は関係ない。 よくある話そもそも資金調達していないので、完全に社外のお手伝いに依存することになる。社外のお手伝いはいつなくなるかわからない。 社員に給与は払わなければいけないので、役員は自分の給与以上に働く必要がある。忙しくなる。自社製品作ってる暇がなくなる。 結局社外のお手伝いがメインの会社になる。 ここまでがよくある話。 社外の手伝いが忙しい会社ほど自社製品を作りたいという話を良くしている。実際は何もしていない。 自社製品を作るのが難しい誰もが売れる製品を作れるわけではない。売れる製品は正直、運の要素がかなり高いと思っている。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Medium
WebAuthn と macOS Touch ID
Co-Streaming (共同ストリーミング) という世界
