WebRTC が世に出て 10 年以上経ちます。WebRTC には色々課題があると思われがちですが、主な課題は既に解決しています。 古い知識からアップデートできていない記事が多く WebRTC の技術を誤解したままの人が多いのは好ましくないので、以下に雑に説明していきます。 WebRTC は大規模配信ができないできます。 現在商用で利用されている WebRTC は P2P ではなく、ほとんどがクライアント・サーバーモデルである SFU (Selective Forwarding Unit) です。 SFU の場合、数千規模の接続であれば 1 台で実現可能です。 さらに、多段構成や分散構成を利用することで、低遅延のまま数百万、数千万の配信も実現できます。 WebRTC は HLS/MPEG-DASH のように画質が選択できないできます。 WebRTC ではサイマルキャストと呼ばれる、クライア

プログラミングの本はほとんど読んできていない。プロトコル解説やプロジェクトマネージメントの本ばかり読んでる。特にプロジェクトマネージメントは他の人がどう考えているのかを手っ取り早くしれて良い。

X(旧Twitter) で突然フォロワーが恐ろしく増えた。それも中国圏の方々からのフォローでなんだなんだとドキドキしていた。正直スパムか？と思った。 ただ、フォローしてくる人たちのプロフィールには、 GitHub アカウントだったり、ソフトウェアエンジニアとか、プログラマーとか C++ とか Python とかの文字がやけに多かったので、ブロックしたりはせず、ドキドキしたままだった。 そして理由はこれ。有名なオープンソースプログラマーの方が、時雨堂を紹介してくれていた。 私は時雨堂という素晴らしい日本の会社を発見しました。 日本のインターネット企業とは違う。 彼らは新しいテクノロジー (zig) を追いかけているだけでなく、オープンソースを特に受け入れており、主に使用しているテクノロジーの開発者のほとんどをスポンサーしており、公式 Web サイトにもリストされています。 海外の方に OSS

いつか書こうと思っていたので雑に書いていく。 要約基本的に人の意見は参考にならない、聞く必要ない。自分の考えを信じたほうがいい。 ただし、IT 系の企業経営者で信頼できるなら人が身近にいるのであれば、意見交換はしたほうがいい。最近全く会えてないが、ヴェルクの田向さんと Sigfoss の森さんから頂いた意見はとても役に立った。 社外の人間の意見は参考にはならない自分が起業したときに苦労したので、書いておくが、この記事も参考にならないと思ったほうがいい。 思い立ってすぐに起業したので、ほとんど知識がなかった。いろいろな人の意見を聞いてみたが、実際に経営してみると全く参考にならなかった。 助成金の話ばかりする人これは最初に契約した税理士が良くなかっただけかもしれないが、基本的に助成金の話しかしてこない。助成金の仲介手数料が目当てなんだろう。 ちなみに助成金に関しては社員時代に一度助成金を使った

時雨堂は企業か開発する OSS としていくつかのリポジトリを GitHub に公開しています。これらを継続的に開発するためになにをしているかを書いていきます。 まとめOSS に利益を期待しないコミュニティや社外の人と仲良くするOSS に理解のある人だけを社員として雇う前提オープンソースのライセンスは Apache License 2.0ソースコードはオープン、開発はクローズコミュニティは Discord のみOSS の定義“オープンソースの定義” を前提としています。 時雨堂が OSS 採用しているライセンスである Apache License 2.0 は OSI 承認オープンソースライセンスです。 そのため時雨堂が公開している OSS は Apache License 2.0 のもと、利用可能です。 ソースコードはオープン、開発はクローズド 時雨堂の OSS の開発方針は Lua の開発

WebRTC コミュニティの問題これ以外にも webrtc-discuss や react-native-webrtc などのコミュニティでもドキュメントを読めば分かる質問、回答を書いても反応がない、助けて！とだけ書かれた投稿などがとても多いです。 この理由は OSS よくあるといえばそれまでなんですが、それ以外にも問題があると思っています。 WebRTC って音声や映像をリアルタイムに送受信する技術なわけですが、誰が見てもわかるんです。音が来ないもすぐわかるし、映像が遅延してる、表示されないもすぐわかってしまうんです。 つまり技術者じゃなくても問題が起きていることに気づけてしまうんです。 で「なんか音声が流れてこない！このソフトウェアは問題だ！」となってしまうわけです。 これに対応する場合、作者たちは「WebRTC という技術の難しさをよくわかっていない人たち」へ無料のサポートを提供しな

WebRTC QUIC Client/Server が WebTransport として再出発したようなのでまとめておく。 一般的な説明についてはいかが詳しいので以下を読むのをおすすめしたい。

まず、この記事では、STADIA で快適にゲームができるかどうかという話はしません。技術的にどうなの？というのを想像込みで書いていきます。 誰だよお前、って言われそうなので … 自分は WebRTC の通信部分と QUIC スタックの実装をフルスクラッチでしており、日本で多くの会社に採用されている WebRTC を利用したミドルウェア製品の開発者です。WebRTC を利用して 4K@30 をサーバ経由で配信というのを実現したりしています。 利用している技術STADIA が利用している通信技術は WebRTC (と QUIC)です。これは Project Stream という STADIA リリース前に公開された実験的プロジェクトがまさにそうでした。Project Stream の VP である Majd Bakar 氏がインタビューで回答しています。 Project Stream は 10

ソフトウェアのパッケージ販売に携わってもう 10 年以上になるが、どうもこのビジネスってずるすぎないか？ってずーっと思いながらやっているのだが、 ajiyoshi が商売の脆弱性という、うまい表現を使っていたのでパクることにして、ブログを書いてみることにした。タイトル重要。 前提自分はミドルウェアという分野のソフトウェアパッケージ製品を専門にしている開発者（あと経営者）という立場。会社を持つ前も同じ分野を担当していた。 ここでのソフトウェアのパッケージ販売というのはミドルウェア製品のパッケージ製品のサブスクリプションライセンス販売を指している。 ソフトウェアのパッケージ販売在庫が不要ほんとこれ。なんだよそれって思う。うちの例だとダウンロード URL とライセンスファイルをメールで送ってそれで納品完了。 在庫がないのに物が売れるって本当に意味がわからない。ダウンロード URL から製品をダウ

Twitter では何度もつぶやいていたのだけれど、自分の意見をまとめておく。 「情報交換させてください」は殆どの場合で「自分はよく知らないので、貴方ならよく知ってるんだから教えて欲しい、タダで」というパターン。つまり一方通行が多い。 何者かわからない初対面の人に「Erlang/OTP の情報交換しましょう」と言われる怖さ。いや、貴方は誰なんだ。 特にビジネスでの「情報交換させてください」はネガティブな印象しか持たれないので本当にやめたほうが良い。特に、その技術でお金を稼いでいる会社に対して大変失礼だということを理解してほしい。 普通に技術的に困っているなら「困っているので相談にのってほしい」でいいし、興味があるなら「今はわからないが興味がある」でダメなのだろうか。 一方通行な「情報交換させてください」を撲滅したい。 一方通行な「情報交換をさせてほしい」の方に「技術相談ということであれば、

評価制度について年一回、自分の考えを書いていくということをやっていくことにする。 自社の評価制度評価制度自体がないので、評価は行っていない。給与も同じで賞与も同じ。詳細を知りたい方は評価制度の無い評価制度という資料があるので見てもらいたい。 従業員が数名であることもあり、評価制度がない状況でうまく回っている。実際社員に聞いても評価制度がないのは働きやすいとのこと。 会社の事業に対してコミットし、会社の利益がでれば賞与として還元される。この仕組で困っていない。 評価制度に対する考え上司による評価、経営者による評価、全方位評価、様々な評価を受けてきたが、残念ながらどれも満足した評価制度だったことはない。 評価制度は「その評価制度」をハックする仕組みがあるのが問題だと考えている。自分はどうもその評価制度をハックするのがうまいようで、今の所不当な評価をされたことはない。 ただ、ハックできない人が評

なんというか、正直にいって衝撃を受けてる。Discord は「ある程度ユーザ数を集めたら MS とかに買収されて終わりなのでは？」なんて思っていたからだ。 月 4.99 ドルの Nitro なんかではこの大規模なサービスを支えきれないだろう。 Discord は自分の大好きなサービスの一つだ。WebRTC や Electron 、Elixir 、React 、React Native 、GCP といった自分好みな技術選定。 自分が運営している技術コミュニティや、自社の OSS な製品のサポートツールとして使ったりもしている。安定感があり、軽量でパーミッションも考えられていてとても使いやすい。 お金大丈夫なのか？ともずっと思っていた。もと OpenFeint の CEO が起業したこともあり、(GREE に買収されたので) お金はあるんだろう。さらに調達も 30,000,000 ドル以上を調

資金調達していない零細 IT 企業を経営していると抜け出せなくなる受託開発の罠ですが、罠にはまるパターンと、そして自分がどんな方法で罠にはまらないように経営しているのか書いていきます。 前提そもそも受託開発が目的の会社であれば、罠にどっぷりハマって問題はないので、ここでは自社サービスなり自社製品をメインとする会社を前提とします。 経営者が全力で稼いで、社員が自社製品やるパターンや、その逆あったりはここに当てはまりません。当てはまるのは自社製品やりたいけどお金を稼がないといけないといってずるずる行くパターンを受託開発の罠としています。 自転車操業調達していない零細 IT 企業は基本的に自転車操業になります。会社にお金がないと当たり前ですがキャッシュフローが苦しくなるため、受託開発を行いお金を稼ぐようになります。 受託開発は毎月契約でお金をもらって開発リソースを提供するタイプと、いくらでお願い

時雨堂は会社の仕組みを Gist でオープンにしている。実はあの仕組みは自分が働きたいと思う会社の仕組みではない。 時雨堂は 10:00–17:00 の定時制で 6 時間労働。さらには仕事は選べない。技術もあまり選べない。月給は安く抑えられており、賞与は保証なし。ただし儲かった場合は賞与を高めに出す。評価制度はない。 時雨堂で自分が従業員として働きたいとは思っていない。自分が従業員として働くのであれば、裁量労働で、仕事は好き勝手に選べて、給与は稼いだ分だけほしい。さらに技術は自分が使いたいものを使う。ただし食堂はあってほしい。 ではなぜ時雨堂は自分の働きたい会社になっていないのか。それは単純で自分はあくまで経営者であり、従業員ではないからだ。そして自分は社会不適合者であるため、従業員としてやっていけなかったから起業した身であるからだ。 つまり従業員としてやっていけなかった人が望む会社の仕組

先日、門脇(kdxu)とめるぽんと自分で 3 人でやっていたお手伝い案件が終わった。納期は一ヶ月前倒し、顧客の要望はほぼ全て実現という内容で、顧客も大喜び。 門脇とめるぽんはフリーランスとして仕事をしており、自分がお手伝いさせて頂いている会社（それぞれ別の会社）でふたりともフルタイムとして働いている。 そのため、平日の夜や土日が主な作業時間になる。完全非同期で作業して、うまくいったのでそれを記録しておきたい。 案件内容、技術については一切触れない。 自分はプロジェクトマネージメントのみコードは書かないプロジェクト開始前に一通りの要望は洗い出しておいた追加要件にできるだけノーを言わないロードマップを１ヶ月単位で引いた二人を作業者として雇った設計や交渉などはすべて自分が行った顧客には二人が作業者として伝えてある顧客と直接のやり取りは二人は行っていない顧客との打ち合わせにも参加してもらっていない

このおちあいさんの悩みは自分が社員のときに感じていたので、書いてみました。 自分の知見としては「自分の給与を自分で決められるようになった」タイミングでこの卑しい自尊心はなくなりました。 自分の場合、この卑しい自尊心は「結果を出しているにもかかわらず、給与が上がらない」と「自分が期待する評価を会社から得られていない」の２つが合わさって発生していたように思えます。 起業して自分の給与を自分で決められるようになってこの２つについて考える必要がなくなり、この卑しい自尊心はなくなりました。 自分の会社であれば結果を出したら自分の役員報酬はいかようにもできます。会社が利益を挙げられていれば高くし、利益が出ていなければ０円にすればいいだけです。何も悩む必要はありません。 ちなみに今はは自分の役員報酬は税理士に決められているくらい、興味がありません。 さらに期待する評価についても会社からの評価が社会からの