時雨堂創業 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 の機能を利用
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
低コストで高可用性を実現する
自社製品の SaaS をリリースしたのですが、自分の中でのテーマは「低コスト高可用性を実現する」でした。設計に入る前にいろいろ検証して、なんとか自分がやりたかったことができたので雑に書いてみます。雑に読んでください。 低コスト単純に「低価格でサービスを提供したいから」です。維持や運用コストが高くなればなるほどサービスの価格も高くなります。 サービス自体の低コストを実現すれば、価格面での競争力を得ます。もともとの自社パッケージ製品は機能や性能、可用性では負ける要素はないので、勝負は価格面という認識し、そこをどう実現するかを設計の第一としました。 少人数関わる人間が増えれば増えるほど人件費も増え、さらにサービスの価格は高くなります。 そのため、今回はとにかく少人数で開発、運用できることを目標にしました。目指すのはサーバーが 100 台規模になったとしても片手で足りる人数でなんとかなるサービスで
ニッチプログラマー
Twitter で “The Nitche Programmer” という記事が流れてきたので、自分もおそらくニッチプログラマーのくくりには入ると思うので雑に何か書いておこうと思います。 思ったことを適当に書いていくので読みにくいと思います。適当に流し読みしてください。 まとめニッチかどうかはどうでもいい。 ニッチプログラマーはじめてのちゃんとしたプログラミングは Python 2.2 あたりから始まり、その後 Erlang/OTP へ切り替えて 10 年以上 Erlang/OTP を書いてご飯を食べています。ここ数年は開発に注力はせず、ビジネス考える人になっています。 最近では WebRTC をメインでやっており、 Erlang/OTP + WebRTC という組み合わせであればおそらく日本では社員を除けば自分だけというくらいニッチです。世界的に見ても Erlang/OTP + WebR
零細企業経営にはほとんどの意見が参考にならなかった話
いつか書こうと思っていたので雑に書いていく。 要約基本的に人の意見は参考にならない、聞く必要ない。自分の考えを信じたほうがいい。 ただし、IT 系の企業経営者で信頼できるなら人が身近にいるのであれば、意見交換はしたほうがいい。最近全く会えてないが、ヴェルクの田向さんと Sigfoss の森さんから頂いた意見はとても役に立った。 社外の人間の意見は参考にはならない自分が起業したときに苦労したので、書いておくが、この記事も参考にならないと思ったほうがいい。 思い立ってすぐに起業したので、ほとんど知識がなかった。いろいろな人の意見を聞いてみたが、実際に経営してみると全く参考にならなかった。 助成金の話ばかりする人これは最初に契約した税理士が良くなかっただけかもしれないが、基本的に助成金の話しかしてこない。助成金の仲介手数料が目当てなんだろう。 ちなみに助成金に関しては社員時代に一度助成金を使った
E2EE を開発していて思うこと
ここ数ヶ月は自社製品向けの End to End (Media) Encryption の設計と実装をしています。年内での提供を目標として開発を進めてい見ていますが、色々感じることがあったので雑に書いていこうと思います。 前提自分は暗号やセキュリティの専門家ではない自社製品向けの E2EE は Signal や Google Duo が利用している実績のある仕組みを採用しているE2EE や暗号の専門家を招聘し、相談しながら開発している自分の E2EE に対する考え悪意あるサービス管理者からユーザを守るために存在する機能と考えています。 Signal プロトコルはよく考えられすぎているSignal が考えた Curve25519 (x25519/ed25519) を利用した X3DH / Double Ratchet の仕組みは安全すぎると感じるくらいです。 相手からメッセージを受信するたび
企業 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 のコミュニティ運用を Discord に集約した
自社の OSS と無料サービスのコミュニティをすべて Discord に集約しました。かなりうまく回っていると思っているので、どんな感じで運用しているかを書いていきます。 前提IT 系パッケージメーカーな零細企業クローズド自社製品で食べているOSS へのサポートは提供していない無料サービスへのサポートは提供していないOSS へは積極的に投資しているロードマップにある機能を有償で前倒して実装することもあるコミュニティマネージャーの採用信頼できる技術者に副業としてコミュニティマネージャーをお願いしています。 仕事内容は責任はなく、基本的には誰かがチャットをしたときに反応をしてもらうというものです。質問しやすい空気を作ってもらっています。 また、コミュニティマネージ以外に検証の仕事も合わせてお願いしているます、そのため OSS やサービスをユーザ視点で触っており、技術もわかるコミュニティマネージ
mDNS を利用したWebRTC のローカル IP 隠蔽機能
Chrome Canary M74 や Safari Technology Preview 74 では mDNS を利用したローカル IP 隠蔽機能が利用できるようになりました。 要約ローカル IP アドレスはすべて UUID.local になるローカル内で mDNS を利用し名前解決を行い IP アドレスを取得する名前解決できない場合は UDP ホールパンチングを試みず破棄できるUUID.localまずはどうなるのかを見てもらおうと思います。 ちょっとわかりにくいですが Chrome Canary M74 で取得した Candidate です。UUID.local となってるのがわかるでしょうか？ a=candidate:3252390177 1 udp 2122262783 56264e2a-1cc6-433f-8330-1594df32034c.local…
バーチャルライバー向け配信システム Wata
最近 めるぽん と一緒にバーチャルライバー向け配信システムを作っています。といっても自分は開発とか一切せずに横から口を出すだけのめんどくさい人をやっています。 開発経緯もともとバーチャルライバー自体には興味はないんですが、配信はどうやるんだろう？って調べていたりしました。単にバーチャルライバー向けの超低遅延な配信システムを作ったら欲しい人がいるのでは？くらいのモチベーションです。 色々調べてみると殆どが HLS/MPEG-DASH による配信で、遅延も大きくなんてコレは作れば何かしら興味持ってもらえるかも？と思っていたところ IRIAM の中の人から誘われて配信システムの設計を手伝うことになりました。 IRIAM は超低遅延が売りのサービスということで、そっち優先で設計しました。このとき めるぽん にクライアント側の開発を手伝いをしてもらったりしました。 で、結果的に IRIAM の配信シ
リアルタイム映像配信サーバ開発者からみた 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 で利用可能な
無償での情報搾取
IT 系零細企業を経営していて、特定の技術に強いと外から思われ始めると無償での技術情報の搾取を目的とした問い合わせが多くなる。 自分は残念ながら無償で技術情報の搾取をされた経験があるので、注意喚起として書いておく。この悪しき習慣を潰したい。 情報交換をしたいこのフレーズがメールの文章に含まれていた場合は、とても注意すべきだ。殆どの場合であなたの会社の方が情報を持っており、相手は無償で技術的な情報を得たいと考えていることが多い。 技術の分野の世界はとても狭いので、ほんとうの意味で情報交換を申し込んで来る人はあなたがすでに知っている人の可能性が高い。全く知らない人が情報交換を持ちかけてくるのはまず疑ったほうがいい。 知らない会社から「情報交換をしたい」と言われたら、丁重にお断りをするべきだ。情報交換をしたいと言ってきた会社から仕事につながった経験はまったくない。彼らは一方的な搾取を望んでいるだ
自社製品で食べていけるようになるまでやったこと
ミドルウェアのパッケージ製品で食べていけるようになるまでやったことを自分のメモ代わりにまとめておきます。 製品の事業計画を明確にしない自分が想定したとおりに行くことが少ないこともあり事業計画を書いたりしません。日々の状況を見ながら判断をしていくということをしています。そのため中長期的な計画は品質の向上くらいにしておき、機能追加に関してはその度々に考えて実装していくのが一番です。 変化が早い分野でもあるので、事業計画を用意するメリットが零細企業にはないと考えています。 リリース前の開発進捗を共有するステルスはデメリットが多いと判断し、今開発しているもの開発中の状況などを共有しました。これは「製品をステルスで開発して、出したとしても買ってもらうまでの時間がかかる」と考えたからです。 それよりはあの会社があんなの作ってるそろそろ出るらしいと思ってもらえたほうが検討してもらいやすくなります。 今、
評価制度について – V – Medium
評価制度について年一回、自分の考えを書いていくということをやっていくことにする。 自社の評価制度評価制度自体がないので、評価は行っていない。給与も同じで賞与も同じ。詳細を知りたい方は評価制度の無い評価制度という資料があるので見てもらいたい。 従業員が数名であることもあり、評価制度がない状況でうまく回っている。実際社員に聞いても評価制度がないのは働きやすいとのこと。 会社の事業に対してコミットし、会社の利益がでれば賞与として還元される。この仕組で困っていない。 評価制度に対する考え上司による評価、経営者による評価、全方位評価、様々な評価を受けてきたが、残念ながらどれも満足した評価制度だったことはない。 評価制度は「その評価制度」をハックする仕組みがあるのが問題だと考えている。自分はどうもその評価制度をハックするのがうまいようで、今の所不当な評価をされたことはない。 ただ、ハックできない人が評
自分が働きたい会社にしない
時雨堂は会社の仕組みを Gist でオープンにしている。実はあの仕組みは自分が働きたいと思う会社の仕組みではない。 時雨堂は 10:00–17:00 の定時制で 6 時間労働。さらには仕事は選べない。技術もあまり選べない。月給は安く抑えられており、賞与は保証なし。ただし儲かった場合は賞与を高めに出す。評価制度はない。 時雨堂で自分が従業員として働きたいとは思っていない。自分が従業員として働くのであれば、裁量労働で、仕事は好き勝手に選べて、給与は稼いだ分だけほしい。さらに技術は自分が使いたいものを使う。ただし食堂はあってほしい。 ではなぜ時雨堂は自分の働きたい会社になっていないのか。それは単純で自分はあくまで経営者であり、従業員ではないからだ。そして自分は社会不適合者であるため、従業員としてやっていけなかったから起業した身であるからだ。 つまり従業員としてやっていけなかった人が望む会社の仕組
同時接続 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 を学び始めた頃にはすでにありまし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
