時雨堂創業 12 年目
2013 年 3 月 8 日に時雨堂を創業し、2024 年 3 月 8 日で時雨堂創業 11 年、そして 12 年目にはいりました。あっという間です。 起業のきっかけは、ある経営者に「貴方がどんなに一生懸命に製品を作ってもそれは会社のものでしかないので、自分の会社を持って自分の製品を作って、売った方がいい」といわれた事なんですが、それから 11 年立ちました。 起業したときから状況も大きく変わりました。自社製品の売り上げだけで会社が回っています。今後の時雨堂について雑に書いて行きます。 少人数でスケールする製品を作り続ける時雨堂はパッケージソフトウェアのサブスクリプションで稼いでいる会社です。営業もいないため、買いたいといってくれる企業に売るだけです。 社員が社内にあるライセンス発行サーバーに Tailscale でリモートで繋いでライセンス (JSON ファイル) を発行し、ライセンスフ
GitHub Copilot Enterprise のススメ
GitHub が GitHub Copilot Enterprise というサービスをはじめました。かなり革命的なのですが、とにかく高い。利用するには一人 60 ドル/月 (GitHub Enterprise Cloud 21 ドル/月 + GitHub Copilot Enterprise 39 ドル/月)かかります。なので、気になってる人向けに実際に使ってみて何が嬉しいのかを雑に書いてみます。 Pull-Request サマリーの自動生成GitHub の Pull-Request を出すとき、レビューして貰うためにこの Pull-Request の変更点を整理して書くと思うのですが、これを自動生成してくれます。 https://github.com/sile/pixcil/pull/2これは弊社の社員が個人のリポジトリで GitHub Copilot Enterprise の機能を利用
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
時雨堂は何をしている会社なのか
大変反省したので、何をやっていて、どんな会社なのか書いていきます。知ってもらうためにも定期的に更新していければ思っています。 まとめ零細企業リアルタイムな音声と映像を扱うミドルウェア製品を作って売ってるミドルウェアのクラウド版を作って売っているサブスクリプションモデルの積み上げ型OSS 重視何をやってるのか時雨堂はミドルウェアソフトウェアをパッケージとして開発、販売しています。最近は「リアルタイムな音声と映像、データの配信」に特化したミドルウェアがメインです。 現在の主力製品は WebRTC SFU Sora (以降 Sora)という本来は P2P で利用する WebRTC を、クライアント・サーバー方式で利用するソフトウェアを1 から開発して、販売しています。売上のほとんどはこの製品関連になります。 製品はサブスクリプションを採用しており、 3 ヶ月、6 ヶ月、 12 ヶ月単位で Sor
オンラインドキュメントと日本語全文検索
自社では Sphinx というドキュメントツールを利用しているのですが、残念ながらこれに付属している検索機能の日本語検索はかなり厳しいです。また残念ながら Sphinx 開発側も検索周りを改善するという予定は直近ではないようです。 そして検索というのはとても難しい技術なため自分のような素人では導入して「普通に期待する動作」をさせるまでの距離はとても遠いです。 ただ、なんとかして日本語全文検索を実現したいという思いはここ10 年くらいずっと思っていました。これは自社の Sphinx テーマを作ってくれている社員ともよく話をしていたのですが、どうしてもリソースをつぎ込めずにいました。 まとめ日本語検索に対応している Meilisearch を採用したドキュメントスクレイパーの実行は GItHub Actions (Self-hosted Runner) を採用した自社 Sphinx テーマの検
なぜ Zig の採用を検討しているのか
かなり雑に書いてるので、雑に読んでください。 Bun が Zig で開発されていることを知り、そこから Zig を調べてみています。 調べていくと自分が求めていた言語っぽいというのがあり、社外では学生に QUIC や TLS 1.3 を Zig で OSS を開発してもらうお仕事を出したり、社内では実際に採用に向けて調査を進めています。 そもそもの目的自分の会社では Erlang VM を利用した製品をメインに利用しています。ただ Erlang VM 遅いんです。少なくとも暗号処理であれば Rust の方が 2 倍ほど速いです。Erlang VM 自体 JIT を採用したり、いろいろ頑張ってくれているのですが劇的な高速化というのは今すぐには難しいのが現実です。 そこで NIFs (Native Implemented Functions) を使って頑張るという戦略があります。早い話が Er
ニッチプログラマー
Twitter で “The Nitche Programmer” という記事が流れてきたので、自分もおそらくニッチプログラマーのくくりには入ると思うので雑に何か書いておこうと思います。 思ったことを適当に書いていくので読みにくいと思います。適当に流し読みしてください。 まとめニッチかどうかはどうでもいい。 ニッチプログラマーはじめてのちゃんとしたプログラミングは Python 2.2 あたりから始まり、その後 Erlang/OTP へ切り替えて 10 年以上 Erlang/OTP を書いてご飯を食べています。ここ数年は開発に注力はせず、ビジネス考える人になっています。 最近では WebRTC をメインでやっており、 Erlang/OTP + WebRTC という組み合わせであればおそらく日本では社員を除けば自分だけというくらいニッチです。世界的に見ても Erlang/OTP + WebR
なぜ WebAssembly 生成を Go にしたのか
オンラインイベントで聞かれて、ツイッターにつぶやいたら思った以上に反響があったので、もう少し詳細に書いてみます。 思ったより反響があったまとめ信頼できる暗号ライブラリがある自分が TypeScript より Go のほうが書けるGo の Wasm バイナリサイズを気にする必要がないWebCrypto にない暗号が必要自社の WebRTC SFU において End to End Encryption (E2EE) をブラウザ上で実現するためにはいくつかの壁がありました。 一つは WebCrypto が提供していない暗号を利用したいというものです。 今回 E2EE を実装するにあたり採用した Signal プロトコルでは公開鍵暗号に Curve25519 を採用しています。残念ながら WebCrypto では Curve25519 に対応していません。この時点で「暗号ライブラリをどこからもって
資本金 50 万円、無借金経営
自分が経営している時雨堂は会社設立してからずっと無借金経営です。つまり、銀行からお金を借りていません。役員借入金もないので、本当に無借金経営です。ちなみに資本金もたった 50 万円です。 従業員が片手で収まる会社なのであまり参考にならないとおもいますが、資本金が 50 万円、無借金経営が実際どんな感じかどうかを雑に書いていきます。 資本金 50 万円会社を起業したときにお願いした税理士が「50 万円は最低出さないと行けない」という話をしたので、あまり何も考えず 50 万円にしました。自分が 100% 出資です。 その後、資本金 50 万円だからという理由で仕事を断られたということは一度もないです。実際に大手企業相手に口座を開いてます。資本金が安くて取引相手に口座を開くのを断られたことはないです。 従業員が家を買うときに所属している企業の資本金 50 万円だからという理由で、家が買えないとい
零細企業経営にはほとんどの意見が参考にならなかった話
いつか書こうと思っていたので雑に書いていく。 要約基本的に人の意見は参考にならない、聞く必要ない。自分の考えを信じたほうがいい。 ただし、IT 系の企業経営者で信頼できるなら人が身近にいるのであれば、意見交換はしたほうがいい。最近全く会えてないが、ヴェルクの田向さんと Sigfoss の森さんから頂いた意見はとても役に立った。 社外の人間の意見は参考にはならない自分が起業したときに苦労したので、書いておくが、この記事も参考にならないと思ったほうがいい。 思い立ってすぐに起業したので、ほとんど知識がなかった。いろいろな人の意見を聞いてみたが、実際に経営してみると全く参考にならなかった。 助成金の話ばかりする人これは最初に契約した税理士が良くなかっただけかもしれないが、基本的に助成金の話しかしてこない。助成金の仲介手数料が目当てなんだろう。 ちなみに助成金に関しては社員時代に一度助成金を使った
E2EE を開発していて思うこと
ここ数ヶ月は自社製品向けの End to End (Media) Encryption の設計と実装をしています。年内での提供を目標として開発を進めてい見ていますが、色々感じることがあったので雑に書いていこうと思います。 前提自分は暗号やセキュリティの専門家ではない自社製品向けの E2EE は Signal や Google Duo が利用している実績のある仕組みを採用しているE2EE や暗号の専門家を招聘し、相談しながら開発している自分の E2EE に対する考え悪意あるサービス管理者からユーザを守るために存在する機能と考えています。 Signal プロトコルはよく考えられすぎているSignal が考えた Curve25519 (x25519/ed25519) を利用した X3DH / Double Ratchet の仕組みは安全すぎると感じるくらいです。 相手からメッセージを受信するたび
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 会議という仕組みのようです
企業 OSS を継続開発するためにやっていること
時雨堂は企業か開発する OSS としていくつかのリポジトリを GitHub に公開しています。これらを継続的に開発するためになにをしているかを書いていきます。 まとめOSS に利益を期待しないコミュニティや社外の人と仲良くするOSS に理解のある人だけを社員として雇う前提オープンソースのライセンスは Apache License 2.0ソースコードはオープン、開発はクローズコミュニティは Discord のみOSS の定義“オープンソースの定義” を前提としています。 時雨堂が OSS 採用しているライセンスである Apache License 2.0 は OSI 承認オープンソースライセンスです。 そのため時雨堂が公開している OSS は Apache License 2.0 のもと、利用可能です。 ソースコードはオープン、開発はクローズド 時雨堂の OSS の開発方針は Lua の開発
お手伝い先でやったこと、やってること
2020 年 1 月から株式会社ZIZAI の IRIAM で「雑談するおっさん」をしています。なにをやったか、なにをやってるかを書いていこうと思います。ちなみに自分の本業は開発者です。 まずお手伝いする上で条件を出しました。 サーバ/インフラに関する技術決定権採用判断権組織改善権評価改善権結果としては偉い人から「何やっても構いません、全部おまかせします」って返ってきました。 さて、やったこと、やってることを箇条書きで書いてみました。技術的な話の詳細は内緒なので書きません。 Twitter での定期的な採用告知自分への Slack DM の禁止自分への返信はスレッド禁止（好み問題）可能な限り即決断する自分だけでは決断できない場合はいつまでに判断する旨を伝えるSlack のパブリックで #shiguredo を作ってもらい、自分とはそこでのみ会話するエンジニアの上下関係の削除プライベートに対
海外のOSS なWebRTC SFU 開発者たちがコミュニティに絶望してる話
WebRTC コミュニティの問題これ以外にも webrtc-discuss や react-native-webrtc などのコミュニティでもドキュメントを読めば分かる質問、回答を書いても反応がない、助けて！とだけ書かれた投稿などがとても多いです。 この理由は OSS よくあるといえばそれまでなんですが、それ以外にも問題があると思っています。 WebRTC って音声や映像をリアルタイムに送受信する技術なわけですが、誰が見てもわかるんです。音が来ないもすぐわかるし、映像が遅延してる、表示されないもすぐわかってしまうんです。 つまり技術者じゃなくても問題が起きていることに気づけてしまうんです。 で「なんか音声が流れてこない！このソフトウェアは問題だ！」となってしまうわけです。 これに対応する場合、作者たちは「WebRTC という技術の難しさをよくわかっていない人たち」へ無料のサポートを提供しな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Business Source License 1.1
Ubuntu Livepatch Service を導入した
独学でプログラミングを学んできて読んで良かった本
時雨堂のオンラインイベント振り返り