分散 WebRTC SFU
雑に書きたいことを書いていく。 自社製品の WebRTC SFU に Raft を利用した分散機能を追加したのが、去年。そして今年は分散機能を応用したリレー機能を追加している。 リレー機能というのは、オンラインミーティングをする際に、分散したノードのどこに参加しても同じミーティングに参加できると考えてもらえれば良い。 会社のブログ記事からひっぱてきた画像このリレー機能は念願だったのだが、実際に使ってみると本当に便利な事に気付く。簡単に言えばスケールアウトするようになった。リソースが足りなくなったらサーバーを追加すればいいし、リソースが余ってきたらサーバーを減らせばいいだけ。 つまり、この分散 WebRTC SFU があれば、100 万同時接続の配信も現実になってしまった。もちろんサーバーとネットワークさえあればもっといける。 自社製品の強みはこの分散の仕組みを WebRTC SFU に組み
時雨堂創業 12 年目
2013 年 3 月 8 日に時雨堂を創業し、2024 年 3 月 8 日で時雨堂創業 11 年、そして 12 年目にはいりました。あっという間です。 起業のきっかけは、ある経営者に「貴方がどんなに一生懸命に製品を作ってもそれは会社のものでしかないので、自分の会社を持って自分の製品を作って、売った方がいい」といわれた事なんですが、それから 11 年立ちました。 起業したときから状況も大きく変わりました。自社製品の売り上げだけで会社が回っています。今後の時雨堂について雑に書いて行きます。 少人数でスケールする製品を作り続ける時雨堂はパッケージソフトウェアのサブスクリプションで稼いでいる会社です。営業もいないため、買いたいといってくれる企業に売るだけです。 社員が社内にあるライセンス発行サーバーに Tailscale でリモートで繋いでライセンス (JSON ファイル) を発行し、ライセンスフ
中国圏で時雨堂が紹介された話
X(旧Twitter) で突然フォロワーが恐ろしく増えた。それも中国圏の方々からのフォローでなんだなんだとドキドキしていた。正直スパムか？と思った。 ただ、フォローしてくる人たちのプロフィールには、 GitHub アカウントだったり、ソフトウェアエンジニアとか、プログラマーとか C++ とか Python とかの文字がやけに多かったので、ブロックしたりはせず、ドキドキしたままだった。 そして理由はこれ。有名なオープンソースプログラマーの方が、時雨堂を紹介してくれていた。 私は時雨堂という素晴らしい日本の会社を発見しました。 日本のインターネット企業とは違う。 彼らは新しいテクノロジー (zig) を追いかけているだけでなく、オープンソースを特に受け入れており、主に使用しているテクノロジーの開発者のほとんどをスポンサーしており、公式 Web サイトにもリストされています。 海外の方に OSS
依存ライブラリを減らす
自社主力製品（以下自社製品）の依存ライブラリを減らしたので、雑に書いていきます。 もともと、自社製品の依存ライブラリは多くありません。Erlang/OTP というマニアックな言語で書かれていることもあり、多くの依存ライブラリは自前で書いています。 自前ではない依存ライブラリは JSON、JSON スキーマ、HTTP サーバー、HTTP クライアント、Raft などです。 今回は HTTP クライアントをライブラリ依存が少ないライブラリに変更し、さらに JSON スキーマを Fork し、依存しているライブラリを減らしました。 HTTP/1.1 クライアント Hackney の削除
ChatGPT で何が変わったか
2023 年 3 月時点で、自分の開発スタイルがどう変わったかを雑に書いておく。 どんなタイミングで何を聞いているか主に Go と TypeScript や W3C や IETF の仕様について聞く場合はほぼ ChatGPT Plus を利用している。間違いとかはどうせ公式ドキュメントを読めばいいので、正しさは求めておらず、きっかけを求めている。 最近では Cloudflare Workers 上で動く WebAuthn サーバーを実装しているが W3C の WebAuthn を開きつつも、ほぼ ChatGPT に相談しながら実装している。 TypeScript で Uint8Array から ArrayBuffer に変換する方法を聞いたり、証明書について聞いたりと色々。参考までにどんなことを聞いているかを紹介しておきたい。 WebAuthn で送られてくる署名の r と s がたまに
2022 年に学んで良かった技術
雑に書いていきます。 バックグラウンド自分のバックグラウンドスキルは以下の通り。専門はリアルタイムな通信プロトコルを利用したサーバーの設計と開発とマーケティング。 Erlang/OTPWebRTCEnd to End Encryption細かいのはこちら。 SQLGo で sqlc を使うために学ぶことにした。sqlc を採用したのは複数人数で開発するときの共通言語としては SQL の方がいいだろうというのと、SQL はどんなデータを持たせたいのかを伝えるのに便利と判断したため。 今までずっと通信系ミドルウェアの開発をしてきたこともあって SQL を学ぶ必要が無かったが、今回いい機会なのでちゃんと学ぶことにした。 まずは利用データベースを完全にしぼって TimescaleDB (PostgreSQL ベース) で利用する SQL だけを学ぶことにした。 書籍は元 SIer のガチ SQL
なぜ Zig の採用を検討しているのか
かなり雑に書いてるので、雑に読んでください。 Bun が Zig で開発されていることを知り、そこから Zig を調べてみています。 調べていくと自分が求めていた言語っぽいというのがあり、社外では学生に QUIC や TLS 1.3 を Zig で OSS を開発してもらうお仕事を出したり、社内では実際に採用に向けて調査を進めています。 そもそもの目的自分の会社では Erlang VM を利用した製品をメインに利用しています。ただ Erlang VM 遅いんです。少なくとも暗号処理であれば Rust の方が 2 倍ほど速いです。Erlang VM 自体 JIT を採用したり、いろいろ頑張ってくれているのですが劇的な高速化というのは今すぐには難しいのが現実です。 そこで NIFs (Native Implemented Functions) を使って頑張るという戦略があります。早い話が Er
時雨堂 9 期振り返り
時雨堂は 9 月が期末です。ただ、色々やる事が山積みなので、少し早いですが振り返っていきます。 粛々と改善し続けた 1 年時雨堂の 8 期は、自社製品を粛々と改善し続けました。特にプロジェクトマネージャーが参戦してくれてからは、劇的に改善が進みました。 クローズド製品は自分、OSS 製品はプロジェクトマネージャーと担当を分けられたのも大きかったです。 WebRTC SFU Sora 、Sora SDK 、Momo 、Zakuro 、Hisui、webrtc-build など多くの OSS 製品を改善することができました。 方針通りには進んだ前期に上げた会社の方針は以下の通りです。 主力製品である Sora を採用したくなる OSS の提供実際、既存の OSS だけでなく新しい OSS を提供することもできました。 WebRTC SFU Sora 向けの負荷試験ツール ZakuroWebRT
E2EE を開発していて思うこと
ここ数ヶ月は自社製品向けの End to End (Media) Encryption の設計と実装をしています。年内での提供を目標として開発を進めてい見ていますが、色々感じることがあったので雑に書いていこうと思います。 前提自分は暗号やセキュリティの専門家ではない自社製品向けの E2EE は Signal や Google Duo が利用している実績のある仕組みを採用しているE2EE や暗号の専門家を招聘し、相談しながら開発している自分の E2EE に対する考え悪意あるサービス管理者からユーザを守るために存在する機能と考えています。 Signal プロトコルはよく考えられすぎているSignal が考えた Curve25519 (x25519/ed25519) を利用した X3DH / Double Ratchet の仕組みは安全すぎると感じるくらいです。 相手からメッセージを受信するたび
零細企業経営にはほとんどの意見が参考にならなかった話
いつか書こうと思っていたので雑に書いていく。 要約基本的に人の意見は参考にならない、聞く必要ない。自分の考えを信じたほうがいい。 ただし、IT 系の企業経営者で信頼できるなら人が身近にいるのであれば、意見交換はしたほうがいい。最近全く会えてないが、ヴェルクの田向さんと Sigfoss の森さんから頂いた意見はとても役に立った。 社外の人間の意見は参考にはならない自分が起業したときに苦労したので、書いておくが、この記事も参考にならないと思ったほうがいい。 思い立ってすぐに起業したので、ほとんど知識がなかった。いろいろな人の意見を聞いてみたが、実際に経営してみると全く参考にならなかった。 助成金の話ばかりする人これは最初に契約した税理士が良くなかっただけかもしれないが、基本的に助成金の話しかしてこない。助成金の仲介手数料が目当てなんだろう。 ちなみに助成金に関しては社員時代に一度助成金を使った
打ち合わせをしない
自社ではライセンス契約がないお客様との打ち合わせをお断りしています。まずはフィードバックをもらう前提として、 30 日無料で利用可能な評価版を提案します。 理由特定分野に詳しい企業というアピールをしているため、打ち合わせを打診されることは多いです。ただ、話を聞くより、まずは使ってみたほうが早いと思っています。 打ち合わせに行ったから売れたという経験がないこちらの話を聞きたいだけが多い「詳細は打ち合わせで」という意味がわからない何度も打ち合わせをする意味がわからない日程調整をして、打ち合わせをして「音沙汰がない」が多すぎます。 結果とても効果があります。 自社製品に使える時間が圧倒的に増えた打ち合わせで不在という事がなくなり社内連携しやすくなった打ち合わせしないと製品が買えない病と関わらなくて良くなった打ち合わせをしないという戦略も一つの解だと思っています。
社員に許可を貰ってから会社のお金を使ってる話
自分が株式を 100% 保有する IT 系の零細企業を経営しています。俗に言うワンマン経営と言うやつです。 ただし、お金の管理は経理を兼務している総務と顧問税理士(x2)にお任せして自分がタッチすることは殆どありません。あるとしたら賞与の金額を決めるときくらいです。 自社の場合、経費を断りなく利用して良いのは総務のみです。ただし総務は 10 万円を超える金額のものを買う時だけ自分に許可を求めるというルールになっています。 それ以外は自分を含め従業員全員が経費を利用する場合は許可をもらうようにしています。 会社のクレジットカードも希望する社員には持たせています。利用する場合は「できるだけ事前に総務へ報告をする」というルールになっています。 お金の流れが一本化されてとても良いのでお薦めです。むしろ勝手にワンマン経営者がお金を使うと税理士や経理が困るだけだと思っています。
NPNS における Erlang/OTP
Erlang & Elixir Fest 2019 で任天堂さんの発表について、懇親会で話せる範囲でお教えていただいたことなどを交えて、Erlang/OTP を利用してパッケージ製品を開発しているプログラマー視点で見ていきます。残念ながら運用については未経験のため、その辺りは触れません。 また自分が XMPP というプロトコルはなんとなく知っているレベルということもあり、XMPP 自体には踏み込みません。 XMPP/ejabberd という選択当たり前ですがプッシュ通知を送るには TCP/IP の接続を維持するという方針になります。その上、将来的には 1 億を目指して行くわけです。 TCP の常時接続が経験ない中で 1 億同時接続を目指す際の技術選定で、自作プロトコルに行かず、 枯れている XMPP という選択をしたのは本当に素晴らしいと思います。 また、そんな中で実績がある ejabbe
Erlang & Elixir Fest 2019
「Erlang/OTP で WebRTC と QUIC」という内容で話をします。 発表者向け資料はこちらで準備中です。 以下は発表者向け資料を書くために適当に書き出した文章です。 自分は Erlang/OTP は長く使っていて、その使いみちの大半がクローズドソースなパッケージ製品の開発です。自分の会社を持ってからは、 Erlang/OTP で開発したパッケージ製品だけで会社が回る所まで来ています。 零細企業のクローズドソースのパッケージ製品の話ってあまり聞いたことがないので、では自社製品をどうやって開発してるのか、どんな感じで実装されているのかなどをお話しようと決めました。 自社製品である WebRTC SFU Sora という製品は P2P での利用を想定している WebRTC を無理やりサーバ経由にするという仕組みです。 この製品はフルスクラッチで実装しています。 WebRTC 関連の
製品のリリース頻度を減らす
自社で開発しているミドルウェアパッケージ製品のリリース頻度をどうすれば下げられるかというのが最近の自分の中での課題になっている。 パッケージ製品というのは自社で動かすわけではなく、顧客の環境で動かすわけでアップデート頻度が高い場合、作業負担を強いることになる。 そこでできるだけリリース頻度を下げていきたいと考えているが、なかなか難しいので、どうやってみているかを書いていきたい。 現在のリリース頻度リリースは Ubuntu を真似して 4 月と 10 月で、年 2 回がリリース。致命的なバグ修正や、ブラウザアップデートによる不具合対応などは、修正ができ次第すぐにリリースしている。 クライアント側のバージョンアップへの対応自社製品は WebRTC という技術を使っており、これはブラウザに搭載されている機能の一つになる。ただ Chrome は 6 週間ごと、 Firefox は 6–8 週間ごと
なぜ WebRTC で稼げているのか？
特定のオープンな技術で食べてくのはとても難しいのですが、今の時点で時雨堂は WebRTC という技術だけで会社が十分回る所まで来ています。そのあたりを振り返りついでに書いていきます。振り返りは何度やっても損がないと思っています。 自社製品だけに集中しない実は時雨堂は自社製品以外の仕事もいろいろやっています。公開可能なのだと FGO の負荷試験 や IRIAM の配信設計でしょうか。自社製品だけやっている場合は徐々に視野が狭くなります。そのため市場を見誤ったりもしかねません。 自社製品以外で会社が回るようにする自社製品以外の売上を確保しているので自社製品が赤字でも問題なく会社が回るようになっています。そのため、どんなに自社製品が赤字になったとしても、時雨堂は潰れることがありません。 そのため、競合がどんなに頑張ったとしても時雨堂が潰れることはありません。別に背水の陣で自社製品をやっているわけ
無償での情報搾取
IT 系零細企業を経営していて、特定の技術に強いと外から思われ始めると無償での技術情報の搾取を目的とした問い合わせが多くなる。 自分は残念ながら無償で技術情報の搾取をされた経験があるので、注意喚起として書いておく。この悪しき習慣を潰したい。 情報交換をしたいこのフレーズがメールの文章に含まれていた場合は、とても注意すべきだ。殆どの場合であなたの会社の方が情報を持っており、相手は無償で技術的な情報を得たいと考えていることが多い。 技術の分野の世界はとても狭いので、ほんとうの意味で情報交換を申し込んで来る人はあなたがすでに知っている人の可能性が高い。全く知らない人が情報交換を持ちかけてくるのはまず疑ったほうがいい。 知らない会社から「情報交換をしたい」と言われたら、丁重にお断りをするべきだ。情報交換をしたいと言ってきた会社から仕事につながった経験はまったくない。彼らは一方的な搾取を望んでいるだ
自分向けメモとしての Discord サーバ – V – Medium
Dropbox Paper を使ったりしてみていたが、どうもしっくりこず。仕事の社内向け資料はすべて Kibela を使って書いている。 では、ちょっと調べたりするメモをどこにおけばいいのかというので悩んでいた。Slack に自分用のチャネルを作ってそこにかくというのも考えたがどうもぐっとこない。 自分ひとりのメモをグルーピングして、気軽にかけて、あとから見返せるようにしたい。Scrapbox も使ってみたがしっくりこない。 そもそも記事としてまとめるのであれば Medium か Gist でいい。記事にはならないがちょっとコメントだけつけて特定の URL メモしておきたい。実際にちょっとしたコードを書いたりした時に保存しておきたい。ニュースに対する意見や考え、ちょっと思いついたときのメモとして使いたい。 いろいろ考えてみたが、最近良く使ってる Discord はどうか？と思い、自分専用の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Business Source License 1.1
独学でプログラミングを学んできて読んで良かった本