はてなブックマーク

時雨堂では 2020 年 9 月からホワイトボックス暗号と E2EE (End to End Encryption) の専門家であり、LINE の E2EE 脆弱性を報告した 五十部さんを技術顧問として招聘しています。 従業員が片手で足りる零細企業がアカデミックから技術顧問を招聘するとどうなるのかを書いていきたいと思います。 要約自分の知らないことを相談できるのは本当に良い理解できるまで何度も聞ける環境は本当に良い自分たちの専門外に取り組む際、技術顧問を招聘するのはオススメ招聘までの経緯自社製品で E2EE の実装を行うにあたり、自分たちが暗号にも E2EE にも精通していないという課題が重くのしかかっていました。 今まで多くのプロトコルを実装してきて、商用環境で利用できるレベルまで持ってきていましたが、E2EE というセキュリティやプライバシーを重視した仕組みを商用レベルで提供するには自

注意: 著者は JIT について「実行時に機械語を生成する」くらいの知識しかありません。間違いなどあったらコメントで教えて下さい。 2020 年 9 月 10–11 日に行われた Code BEAM STO にて、Erlang VM コアコミッターの Lukas Larsson 氏が発表中に Erlang/OTP の JIT 実装である BeamAsm のプルリクエストを送りました。

2020 年 3 月から時雨堂は従業員はフルリモートになっています。食堂や突発的な雑談がなくなった中で、どんな状況なのか、何をやってみるのかを書いてみます。 状況プリセールスの打ち合わせプリセールスでの打ち合わせはしないという方針のため、フルリモートになっても特に支障は出ていません。 顧客との打ち合わせすべて自社製品を利用したビデオ会議として打ち合わせをお願いしています。顧客全員がビデオ会議に理解があるので助かっています。 細かい齟齬が増えたもともと雑談で齟齬を防いでいた組織なので雑談が気軽にできなくなったことから、齟齬が増えるようになりました。ただそこは社員個人個人でカバーという感じでなんとかがんばれています。 自分はとにかく作業をお願いするときは可能な限りビデオ会議をお願いしています(音声のみだったり、ビデオありだったり、人に合わせてます)。 総務の偉大さを再度実感した会社の「開発以外

時雨堂は 9 月が期末です。9 月は新規自社製品が2つ開始、自社製品のリリースが沢山あって、ブログを書く余裕がないと思うので、今のうちに振り返っていきます。 激動の時代時雨堂の 8 期は激動の時代でした。3 月からフルリモートに完全に切り替えました。フルリモートになったことで、時雨堂にとってとても重要な「社員同士の雑な会話」がかなり減ることになり、組織のあり方を見直す必要がでました。 方針通りには進んだ前期に掲げた今期の会社の方針は以下のとおりです。 基本的には自社製品への投資です。それ以上は特にないです。かなり自社製品に投資できたと思います。自社製品に関係ない仕事は自分がいくつかの会社で雑談するという仕事をしてるくらいです。 ただし売上の面では想定外だった今期は売上を重視せず自社製品への投資を重視するという方針でした。 今期はお手伝いで稼ぐ売上を減らすため、売上を伸ばす予定はありません。

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

時雨堂が提供しているサービスは個人と紐づく情報として GitHub ID (変更不可能なユニークな数値)と GitHub Username (変更可能な文字列) 以外はサーバに保存していません。 そのため、ルールを守っていない可能性の高い利用者に連絡を取ることがかなり難しいです。いきなりBAN してもいいのですが、それよりは優しいメッセージで伝えたいなと。もしかするとドキュメントを読んでないだけかもしれないですし。 優しいメッセージをどうしようかと考えていたのですが、認証エラーの理由に PleaseContactUs という文字列を返すことにしました。設定ファイルに please_contact_us_list: というのを用意してそこに GitHub Username か GitHub ID を書くことで対応できるようにしました。 データベースに入れるとかはめんどくさいのでサボりました。

2020 年 1 月から株式会社ZIZAI の IRIAM で「雑談するおっさん」をしています。なにをやったか、なにをやってるかを書いていこうと思います。ちなみに自分の本業は開発者です。 まずお手伝いする上で条件を出しました。 サーバ/インフラに関する技術決定権採用判断権組織改善権評価改善権結果としては偉い人から「何やっても構いません、全部おまかせします」って返ってきました。 さて、やったこと、やってることを箇条書きで書いてみました。技術的な話の詳細は内緒なので書きません。 Twitter での定期的な採用告知自分への Slack DM の禁止自分への返信はスレッド禁止(好み問題)可能な限り即決断する自分だけでは決断できない場合はいつまでに判断する旨を伝えるSlack のパブリックで #shiguredo を作ってもらい、自分とはそこでのみ会話するエンジニアの上下関係の削除プライベートに対

ピュアというのは libwebrtc を利用しておらずという意味で使っています。例えば時雨堂が提供している WebRTC Native Client Momo は libwebrtc ベースです。 libwebrtc は Chrome や Firefox や Safari が利用しています。というか本気で WebRTC をクライアントとしてやるなら libwebrtc 一択です。それほど機能が充実していますし、チューニングもされています。 ただ、libwebrtc は気軽に使えません、さらに破壊的変更が積極的に入ります。バージョンが上がるだけでビルドできなくなるなんてざらです。追従していくには仕事でやっていくしかありません。 そこでちょっと沢てみたい人向けに WebRTC ピュア実装の出番です。libwebrtc を利用していないため気軽に利用できます。当たり前ですが音声や映像の変換は流石

テレビ会議するときにノイズが気になるというのはあると思います。キーボードを叩く音だったり、マウスをクリックする音だったり。 これらをきれいに消してくれる有料のソフトウェアがあるのでおすすめとして書いておきます。 以下から登録すると +1 ヶ月体験時間が長くなるようなので是非。

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

自社の OSS と無料サービスのコミュニティをすべて Discord に集約しました。かなりうまく回っていると思っているので、どんな感じで運用しているかを書いていきます。 前提IT 系パッケージメーカーな零細企業クローズド自社製品で食べているOSS へのサポートは提供していない無料サービスへのサポートは提供していないOSS へは積極的に投資しているロードマップにある機能を有償で前倒して実装することもあるコミュニティマネージャーの採用信頼できる技術者に副業としてコミュニティマネージャーをお願いしています。 仕事内容は責任はなく、基本的には誰かがチャットをしたときに反応をしてもらうというものです。質問しやすい空気を作ってもらっています。 また、コミュニティマネージ以外に検証の仕事も合わせてお願いしているます、そのため OSS やサービスをユーザ視点で触っており、技術もわかるコミュニティマネージ

Ayame という WebRTC P2P 向けのシグナリングサーバを公開して 1 年過ぎて、色々わかったことがあるので、まとめて、さらに今後どうしていくかを書いていきます。 前提時雨堂では Ayame をビジネスに繋げるきは全くありません。あくまで「WebRTC で P2P」をできる限り使いやすく、簡単にしていくという思いがあります。 また得られた情報をできるだけアウトプットすることで、 WebRTC 界隈への貢献をしていきたいとも思っています。閉じた世界で自分たちだけが利益を得るというのはその市場を狭めてしまうと考えているからです。 利益は WebRTC SFU であげる前提です。P2P が好き、WebRTC が広まって欲しいという気持ちで WebRTC P2P 向けシグナリングサーバを公開しています。 WebRTC P2P はビジネスとして難しいWebRTC P2P 向けのシグナリング

今まで自社のサイトは Nginx / Django か Sphinx / Vulter という構成だったが、Next.js + Netlify でいいのではないか、ということで切り替えをすることにした。 なぜ Netlify なのか最低条件が HTTPS 化するさいに Let’s Encrypt を使っていること、でした。これで AWS (CloudFront) がなくなりました。あとは実際にさわってみて、です。 デプロイが簡単だった月の費用が 45 ドルと現実的だったCDN 前提だった管理画面がシンプルでわかりやすかったGitHub 連携が簡単だったDNS 設定が簡単だったデプロイが高速だったSlack 連携が簡単だったパスワードかけるのが簡単だったSphinx のビルド、デプロイが簡単だったサイト数に制限がなかった請求メールが別に指定できたGitHub でアカウントが作れたアカウント招

自社ではライセンス契約がないお客様との打ち合わせをお断りしています。まずはフィードバックをもらう前提として、 30 日無料で利用可能な評価版を提案します。 理由特定分野に詳しい企業というアピールをしているため、打ち合わせを打診されることは多いです。ただ、話を聞くより、まずは使ってみたほうが早いと思っています。 打ち合わせに行ったから売れたという経験がないこちらの話を聞きたいだけが多い「詳細は打ち合わせで」という意味がわからない何度も打ち合わせをする意味がわからない日程調整をして、打ち合わせをして「音沙汰がない」が多すぎます。 結果とても効果があります。 自社製品に使える時間が圧倒的に増えた打ち合わせで不在という事がなくなり社内連携しやすくなった打ち合わせしないと製品が買えない病と関わらなくて良くなった打ち合わせをしないという戦略も一つの解だと思っています。

Jetson Xavier NX delivers up to 21 TOPS for running modern AI workloads, consumes as little as 10 watts of power, and...

Amazon Kinesis Video Streams adds support for real-time two-way media streaming with WebRTC Posted On: Amazon Kinesis Video Streams now supports real-time media streaming via WebRTC. WebRTC is an open-source...

時雨堂という会社は WebRTC 関連のミドルウェアを開発、販売して利益を上げています。会社として絶対にやらないと決めていることがあります。それが「顧客のビジネスを奪わない」という事です。 情報が集まる時雨堂の主力商品である「WebRTC SFU Sora」という WebRTC 関連のミドルウェアはありがたいことに、かなり多くの顧客に使って頂いています。 ミドルウェアを販売するということは「そのミドルウェアを利用したビジネスの情報」が集まってくるということです。ここで絶対にやってはならないと考えているのは「このサービスはうちでも作れそうだし作ってしまおう」です。 ビジネスを奪わない顧客のビジネスを奪うというのはあってはならない事だと考えています。時雨堂はあくまで「ミドルウェア」を提供する会社であって、それを利用したビジネスは協力はするけど、単独で提供してはなりません。 たとえば時雨堂が「W

ブラウザでビデオチャットを提供するのに利用されている WebRTC を使ったネイティブアプリケーション開発について書きます でんでんらぼが 9/20 (日) の技術書典で 1000 円で販売予定の「WebRTCをブラウザ外で使ってブラウザでできることを増やしてみませんか」の販売前に読む機会があったので色々書いていきます。 電子書籍版を BOOTH で 1200 円で販売していますhttps://tnoho.booth.pm/items/1572872 まとめWebRTC SFU Sora 開発責任者視点WebRTC は実はプロトコルについて詳しくなる必要はあまりありません。プロトコルに詳しい必要があるのは SFU や MCU の開発者くらいです。むしろ JavaScript WebRTC API の方が遥かに重要です。 そして仕事で WebRTC を利用するのであればほぼすべ

Gyazoはスクリーンショットを使ったコミュニケーションと情報収集のためのツールです 撮影 Gyazoを起動して撮影したいエリアを選択します。画像は自動でアップロードされ、リンクがコピーされます。 保存... macOS 版のアプリをダウンロードした。一つは普通のスクリーンショット、もう一つは Gif (つまりアニメーション)を生成するツール。 使い方はいたって簡単で Gyazo アプリを呼び出すだけ。macOS のスクリーンショット全く同じ使い方で使える。cmd + shift + 4 と同じ。 スクリーンショットを取るとすぐにアップロードされて、その URL をブラウザで開いてくれる。 あとはそこから自動生成された画像用の Gazyo URL を共有するのか、画像のダイレクト URL を共有するかだけ。 このダイレクト URL がとても嬉しい。 Gist に markdown や reSt

笠原は高校の同級生です、3 年間同じクラスでした。高校入学当初に「俺プログラマーになるんだけど、お前は?」「僕は研究者になりたい」というどうでもいいやり取りを今も覚えています。 先日、彼と会って話をしたときに、医学系基礎研究はお金がなくて本当に大変という話をしていました。「はー大変だねぇ、研究者も」くらいにしか思ってなかったのですが、今期は起業して最高の売上を叩き出しており、さらに社員に十分な賞与を払っても余裕があったので「できるかしらんけど、寄付でもしようか?」と話をしたところ「できるよ、もしそれなら本当に嬉しいし、助かる」という話だったので、この話を進めていくことにしました。 もちろん、税理士や総務に色々調べてもらい、企業から寄付をしても問題ないことを確認して、先日無事 199 万円を東北大学経由で彼に寄付をしました。 199 万円という金額ですが、200 万円以上の寄付となると書類が

ミドルウェアのパッケージ製品で賞与もまかなえるようになるまでやったことを自分のメモ代わりにまとめていきます。 ここでの賞与というのは一人一千万円以上を前提としています。 こちらのアップデート版です。 まずは動くものをユーザが増えたらとか、こんな事業に使ってほしいからとかではなく、単にこの機能は必要だろうという単純な理由で実装計画だけ立てて、あとは淡々と研究開発を行って、検証作業をしていきます。 うまく動いたらあとは正式リリースに向けて実装を進めていくというスタイルです。当たり前ですがいきなり実装するのではなく、まずは動くものをという考えで進めてみています。 動くものがあると興味を持ってもらいやすいです。 リリース前の開発状況を公開するステルスで開発して、タイミングを見てリリースするほど競合がいる世界で戦っているわけではないので、少しでも自社に乗せる機能が研究開発レベルでも実現できたら公開す

自分が株式を 100% 保有する IT 系の零細企業を経営しています。俗に言うワンマン経営と言うやつです。 ただし、お金の管理は経理を兼務している総務と顧問税理士(x2)にお任せして自分がタッチすることは殆どありません。あるとしたら賞与の金額を決めるときくらいです。 自社の場合、経費を断りなく利用して良いのは総務のみです。ただし総務は 10 万円を超える金額のものを買う時だけ自分に許可を求めるというルールになっています。 それ以外は自分を含め従業員全員が経費を利用する場合は許可をもらうようにしています。 会社のクレジットカードも希望する社員には持たせています。利用する場合は「できるだけ事前に総務へ報告をする」というルールになっています。 お金の流れが一本化されてとても良いのでお薦めです。むしろ勝手にワンマン経営者がお金を使うと税理士や経理が困るだけだと思っています。

に作業をお願いして、設計だけ自分がやるといった感じでした。 ほぼ社員である tnamao は WebRTC 関連の仕事を手伝ってくれました。 自社製品の売上が伸びた自社製品の売上の伸びが大きかったです。サブスクリプション型ということもあり、ここ数年間で積み上げてきたのが土台となりつつも新規顧客を安定して確保できたというのもあります。 自社製品に関しては競合他社からの乗り換えが多くありました。理由はよくわかっていません。 社員たちが社外の手伝いで利益をだしてくれた自分が自社製品につぎ込んでいるため、外のお手伝いで利益は社員たちが頑張ってくれました。本当に助かりました。 今期も前期同様、賞与は 1 人 1000 万以上の予定です。 OSS への投資WebRTC Native Client Momo去年から始めた WebRTC Native Client Momo の GItHub のスターが

時雨堂では CI を回すには macOS が必要な OSS をいくつか公開しています。 https://github.com/shiguredo/momohttps://github.com/shiguredo/sora-ios-sdkhttps://github.com/shiguredo/react-native-webrtc-kitいままでは macOS プランというのに入っていたのですが、WebRTC Native Client Momo のmacOS 版がビルド時間が 30 分以上かかることもあり、500 分では足りなくなるため、困っていました。 そんな時に、ふと CircleCI の料金プランを見ていたところ、OSS 向けに macOS の Seed プランを無料で提供してくれるとの記載を見つけ、さっそく連絡してみました。

Erlang & Elixir Fest 2019 で任天堂さんの発表について、懇親会で話せる範囲でお教えていただいたことなどを交えて、Erlang/OTP を利用してパッケージ製品を開発しているプログラマー視点で見ていきます。残念ながら運用については未経験のため、その辺りは触れません。 また自分が XMPP というプロトコルはなんとなく知っているレベルということもあり、XMPP 自体には踏み込みません。 XMPP/ejabberd という選択当たり前ですがプッシュ通知を送るには TCP/IP の接続を維持するという方針になります。その上、将来的には 1 億を目指して行くわけです。 TCP の常時接続が経験ない中で 1 億同時接続を目指す際の技術選定で、自作プロトコルに行かず、 枯れている XMPP という選択をしたのは本当に素晴らしいと思います。 また、そんな中で実績がある ejabbe

資料は Erlang/OTP で WebRTC と QUIC です。Erlang/OTP 自体の話はほとんどせず、どんなミドルウェアパッケージを Erlang/OTP で開発しているのか、どんな体制で開発してるのかあたりをざっくりと話させていただきました。 今回の発表は初めて「自社製品」と「Erlang/OTP」と「WebRTC」を組み合わせた発表です。この全部合わせたテーマでの発表はこれが最初で最後になると思います。普段はそれぞれ独立して発表しています。 そもそも自分は自社製品が何でできているかとか興味なくて、今まで自社製品が Erlang/OTP を利用しているということはアピールしてきませんでした。そもそも何で作られていようがいいものはいいという考えです。 ただ数年前に から「自社製品が Erlang/OTP で作られていることをアピールしてほしい」という相談をされたことがありました

ありがたいことに自社製品が多くの企業に導入して頂けており、自社製品の売上だけで食べていけるようになりました。 今までは自社製品だけでは食べていけなかったため、外のお手伝いをしていました。ただ自社製品だけで食べていけるようになったのは経営者としてはじめてなので、どうしてみてるかを書いていきます。 会社の状況従業員たちの給与と会社の維持にかかる費用はすでに自社製品の売上で十分まかなえています。普通に賞与も出せるレベルです。 自社製品はパッケージ製品のため、運用などはありません。労働時間は 6 時間の定時労働、土日祝日、年末年始はお休みです。残業はお手伝い系の仕事が忙しくなるとありますが、自社製品に関しては皆無です。 パッケージ製品の開発方針機能より品質重視という方針をとっています。またカスタマイズは受けていません。そのため、自社製品に関しては顧客との調整などは発生しません。サポートの問い合わせ