時雨堂創業 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
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 の開発
前に進み続ける WebRTC
少し WebRTC を知っている人ほど WebRTC は古い技術の集合体という印象がある人が多いです。 実際 DataChannel で利用されている SCTP はかなり古くからある技術を無理やり DTLS over UDP に乗っけて、拡張したものです。SCTP そのまま使われているため古い技術をうまく使っているというのは間違いありません。 とはいえ DataChannel も QUIC に置き換わろうとしていますが、今回はその話は置いてきます。 今回は MediaChannel で利用しているプロトコルがどんな状況なのかについて書いていきます。 まとめWebRTC は古いプロトコルをベースにして拡張し続けていっています。古き良き時代を捨て、新しい時代に向けて積極的です。 既存のプロトコルを拡張する限界も感じており、今後は QUIC ベースで進んでいくという流れも間違いありません。 We
リアルタイム映像配信サーバ開発者からみた STADIA
まず、この記事では、STADIA で快適にゲームができるかどうかという話はしません。技術的にどうなの？というのを想像込みで書いていきます。 誰だよお前、って言われそうなので … 自分は WebRTC の通信部分と QUIC スタックの実装をフルスクラッチでしており、日本で多くの会社に採用されている WebRTC を利用したミドルウェア製品の開発者です。WebRTC を利用して 4K@30 をサーバ経由で配信というのを実現したりしています。 利用している技術STADIA が利用している通信技術は WebRTC (と QUIC)です。これは Project Stream という STADIA リリース前に公開された実験的プロジェクトがまさにそうでした。Project Stream の VP である Majd Bakar 氏がインタビューで回答しています。 Project Stream は 10
無償での情報搾取
IT 系零細企業を経営していて、特定の技術に強いと外から思われ始めると無償での技術情報の搾取を目的とした問い合わせが多くなる。 自分は残念ながら無償で技術情報の搾取をされた経験があるので、注意喚起として書いておく。この悪しき習慣を潰したい。 情報交換をしたいこのフレーズがメールの文章に含まれていた場合は、とても注意すべきだ。殆どの場合であなたの会社の方が情報を持っており、相手は無償で技術的な情報を得たいと考えていることが多い。 技術の分野の世界はとても狭いので、ほんとうの意味で情報交換を申し込んで来る人はあなたがすでに知っている人の可能性が高い。全く知らない人が情報交換を持ちかけてくるのはまず疑ったほうがいい。 知らない会社から「情報交換をしたい」と言われたら、丁重にお断りをするべきだ。情報交換をしたいと言ってきた会社から仕事につながった経験はまったくない。彼らは一方的な搾取を望んでいるだ
プライベートゲームストリーミング
Rainway というサービスがある。WebRTC を利用しているという記事をどこかで見たのだが、よくある配信サービスなんだろうなと思ってたが、全然そんなことなく、かなりすごいサービスなのでまとめておく。
Discord Game Store – V – Medium
なんというか、正直にいって衝撃を受けてる。Discord は「ある程度ユーザ数を集めたら MS とかに買収されて終わりなのでは？」なんて思っていたからだ。 月 4.99 ドルの Nitro なんかではこの大規模なサービスを支えきれないだろう。 Discord は自分の大好きなサービスの一つだ。WebRTC や Electron 、Elixir 、React 、React Native 、GCP といった自分好みな技術選定。 自分が運営している技術コミュニティや、自社の OSS な製品のサポートツールとして使ったりもしている。安定感があり、軽量でパーミッションも考えられていてとても使いやすい。 お金大丈夫なのか？ともずっと思っていた。もと OpenFeint の CEO が起業したこともあり、(GREE に買収されたので) お金はあるんだろう。さらに調達も 30,000,000 ドル以上を調
同時接続 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 を学び始めた頃にはすでにありまし
経営者になってわかったこと
起業して 8 年しか経っていないが、だらだら書いてみる。 自分の会社は従業員は片手で足りるくらいの IT 系零細企業。 税金は高い売上はすぐ入ってこない自分の給与は自分で決められる仕事は簡単に見つからない社員を雇うのは難しい経理、総務、法務、営業事務、書類仕事は多い賞与はいくら出してもいいオフィス賃貸費用は安いほうがいい銀行はとにかくお金を貸そうとしてくる資本金は銀行からお金を借りない限りどうでもいい経営の相談ができない顧問税理士は役に立たない帝国データバンクや東京商工リサーチへの登録が必要になる時がある自分宛ての投資マンション迷惑電話がくる社員の月給が低ければ低いほど経営が楽になる社員の年収は可能な限り高いほうが良い自分の年収に興味がなくなる収入を増やすのも、支出を減らすのも難しい賞与はいつ出してもいい顧問弁護士は必要だが、いつも必要なわけではない自社製品だけで会社を回すのは現実的ではな
FPGA に手を出してみた (1)
GPU を色々調べていたが、どうやら自分がやりたいことをやるのはあまりコストパフォーマンスがいいわけではない、ということがわかり FPGA に手を出してみることにした。 自分がやりたいことは動画の圧縮や合成を高速に行うというもの。FPGA でこれを実現している NGCodec という会社があり、なるほどなるほど、では FPGA だと思い調べてみることにした。 PYNQ を買ったさて、残念ながら自分はハードウェアの知識はゼロ、さらにコンピュータサイエンスの知識もゼロ。なにもない。どこから手を付けていいのかもわからない。 ただ Python はちょっと書ける。ということで FPGA Python で検索したら PYNQ というのがあったのでまずは買ってみた。 FPGA を調べてみたPYNQ が届く間に FPGA を調べることにした。まずは sildeshare で FPGA を検索して、ひたす
時雨堂 2017 年振り返り
今年 1 年を振り返ってみた。時雨堂とはなんぞやという人は時雨堂コトハジメでも読んでみていただければ。 これは、スタートアップではない、台東区にある小さな IT 会社の振り返りです。 自社製品が売れ始めたリコー様の導入を皮切りに、スクウェアエニックス様、ソフトバンク様といった大手企業に導入されたり、pixiv 様やタイトー様のようなお絵かき配信やネットクレーンなどに採用されたりと、できすぎたくらい採用していただいた。他にも事例公開ができないお客様も含め、多くのお客様に採用していただいたのは本当に感慨深い。 個人的にはフロンティアリンク様の開発担当者とお会い出来たことがとても嬉しかった。自社製品を社長が反対した中、ゴリ押しで採用してくれたとのことだった。本当にありがたい。 製品を購入いただいた方はほぼウェブサイトを見てからの問い合わせで、評価版を 1 ヶ月触っていただいて採用していただいたこ
AV1 の未来が開いた – V – Medium
今、よく使われているビデオコーデックといえば H.264 でしょう。ただ H.264 は最先端の技術とはいえません。今後は H.265 に切り替わっていくかと思われましたが、H.265 はパテントがとても複雑です。そのため広がっていくとは思いにくいです。 そんな中、H.265 のパテントの闇に取り込まれないようにするための光が AV1 です。
WebRTC を利用した配信の現実
超低遅延、高画質な配信を実現するための選択肢の一つとして WebRTC があります。 ただ WebRTC はもともと少人数で双方向の配信を前提としているため、スケールしないというのが一般的な認識です。 せっかくなので WebRTC サーバを開発・販売している立場から WebRTC を利用した配信の現実がどの程度なのかを書いていこうと思います。 P2P モデルまずは WebRTC といえば P2P なので、WebRTC の P2P 利用についてお話する必要があります。 WebRTC の P2P 利用は、配信者が視聴者分の変換を行うという負担があることから、最大でも 10 名程度までしか配信できません。 さらに、何より配信者の PC 負荷がとても高くなるため、採用は趣味のページまででしょう。 ビジネスで P2P を配信に利用するのはとても現実的ではありません。 配信の場合は P2P で Web
Elastic Cloud を採用する事にした
検討した結果、採用することにしたので、その過程の理由を。 Elastic Stack を使うことにしたのはいいが、サーバをどう構築するかは決め兼ねていた。 普段から使っている Vultr という VPS サービス上に構築する予定だったのだが、そこそこめんどくさい。落ちた時、ディスク不足などを考える必要がある。 そこで次は AWS の CloudSearch を検討することにしたが、いまいち使いづらい。こちらとしては運用を丸投げしたいだけなのだが、しっくり来ない。転送量課金もある。これは仕方がないが。 そこで Elastic が提供している Elastic Cloud を試してみることにした。 自分が思いつく要求をまとめる。 運用に手間がかからないあまり高くない予算は月 2 万円程度使う側は Beats だけを意識していればいいKibana も運用してほしいサーバは東京にあって欲しい転送量で
自分の発表スタイル
ここ数年、自分の発表スタイルが固まってきたのでまとめてみることにした。 色々発表をしてきたが、今のスタイルが自分にはあっているので当面はこのスタイルで行こうと思っている。 方針資料は事前に公開する資料は発表を見ていなくても理解できるようにする発表資料ではなく発表者向けの資料にする資料は詳細に、発表はシンプルにする資料は Gist で作る発表時間は守る発表は全てアドリブで行う調べないと発表できない内容の発表依頼は受けない写真撮影は拒否、配信や動画は許可短縮 URL サービスを利用して資料の URL はわかりやすくしておく自己紹介は最小限にする事前公開そもそも何か秘密の発表をするわけでもないので、資料は事前に公開するようにしている。そうするとインターネッツの人たちが Typo を指摘してくれたりするので大変ありがたい。 これ、なぜみなさんやらないのかよくわからない。さっさと公開してしまうと良い
Mixer の技術的視点での凄さ
ところてんが Mixer について書いていたので、技術的な話をしようとおもう。 Mixer はマイクロソフトが買収した会社でもともとは Beam.pro というサービスだった。仕組み自体は今と変わらず、ゲーム配信をするという仕組み。 Mixer が他のゲーム配信サービスと違うのは HLS/MPEG-DASH といったストリーミング配信技術を採用せずに WebRTC というリアルタイム配信技術を採用したことだろう。 彼らは Janus という WebRTC Gateway を基盤として採用した。使うだけでなくフォークして、色々自前で改良を進めている。 Mixer が凄い点を上げてみる。 フル HD 、60 fps 、5Mbps での配信が実現可能ほとんど遅延がない、あっても 1 秒あるかないかクライアントを独自で作り込んでいる5Mpbs という高いビットレートでの配信を大規模に実現しているリ
自社の今期振り返りと来期に向けて
自社の決算が 9 末、あと 2 週間ということで振り返ってみたい。 前期が投資期で、 今期は種蒔き期なんて考えていたが、運良く回収期にもなった。正直色々と想定外の期だったように思える。 自社製品を中心に振り返って、ダラダラ書いていく。 運良く自社製品が売れ始める営業がいないので、完全に問い合わせを口を開けて待つスタイルなので、いつ売れるかも運頼み。 それが 2017 年に入ってからはほぼ毎月売れて、社外のお手伝いの売上よりも多いこともあったりした。 自社製品の売上はキャッシュフロー的にとても安定するという事を、実感した 1 年だった。 大手に採用され始める公開できる範囲だとリコー、スクエニ、ソフトバンク（敬称略）という大手に採用されたのは社会的信用という面で大きかった。打ち合わせでもうちが小さい会社だから心配という話がなくなった。 製品の性能や機能、品質などだけで勝負ができるようになった。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
