E2EE を開発していて思うこと
ここ数ヶ月は自社製品向けの End to End (Media) Encryption の設計と実装をしています。年内での提供を目標として開発を進めてい見ていますが、色々感じることがあったので雑に書いていこうと思います。 前提自分は暗号やセキュリティの専門家ではない自社製品向けの E2EE は Signal や Google Duo が利用している実績のある仕組みを採用しているE2EE や暗号の専門家を招聘し、相談しながら開発している自分の E2EE に対する考え悪意あるサービス管理者からユーザを守るために存在する機能と考えています。 Signal プロトコルはよく考えられすぎているSignal が考えた Curve25519 (x25519/ed25519) を利用した X3DH / Double Ratchet の仕組みは安全すぎると感じるくらいです。 相手からメッセージを受信するたび
コードを書き続ける
「開発者は経営者になったらコードを書くのやめて、経営に集中すべき」という考え方を聞いたことがある人はいるだろうか？ 自分はこの考えを持っていた経営者の元で働いていたことがあるので、強く印象に残っている。そして優秀な開発者たちが無理やりコードを書く時間を取り上げられ、経営者とされていったのを何度か見ている。 ここに書くのは自分の経験談であり、こうすべきとかではない。そしてなにより自分は死ぬまでコードを書き続けたいと考えているタイプであるということだ。 伝えたいことは一つだけでコードを書き続けたい経営者からコードを書くのを取り上げるのが良い方法だと思わないということだ。 また、経営者だから偉そうにコードを書くとかは当たり前だがなしだ。経営者関係なく、ただの開発者としてコードを書くという前提のお話。 開発者と経営者起業して 5 年が過ぎた。経営者としても 5 年、開発者としても 5 年。社員をし
Django に再入門している
こんなウェブアプリがほしいという仕様書を書くのだが、結局プロトタイプを作ってデモを見せたほうが早い。 Django を使ってプロトタイプを作れる能力を身につけることにした。Django 歴は無駄に長くて 10 年以上だが、プロダクションで利用したのは片手で数えられるほど。 プロトタイプを作るにあたってヤクの毛狩りをしないように、いくつかルールを考えてみた。 データベースは SQLite を利用する可能な限りサードパーティライブラリを使わないコードの量をできるだけ少なくするデザインを一切当てないHTML は適当に書く可能な限り JavaScript は使わない効率が悪くても気にしないデプロイは誰かに丸投げする速度重視であって、これらのコードは捨てる前提。プロダクションを作る時に参考にしてもらえたらラッキー程度にする。 自分が慣れていない技術を使う時はとにかく、メモを残すことにしている。単に検
リファクタリング
自分はリファクタリングが好きなので、リファクタリングに対する考えとかを書いてみる事にした。 前提としては自社製品、さらにパッケージソフトウェアのためデプロイは存在しない。リリースは一ヶ月に一回程度。ソースコードは 10 万行未満。 自分がリファクタリングするのは機能追加に飽きた時。ペーストしては月１回程度で、多い方だと思う。よく飽きる。 リファクタリングをする時はまず、コードを端から端まで読みながらコメントをしていくところから始める。その後、またコードを端から端まで読みながらコメントを読みつつ、どんなリファクタリングをするか決めていく。そして、決めたらブランチを切って作業。 とにかく、手を付けるコードを読むことが重要だと思っている。人間は適当なものでコードを適当に理解している事が多いので、一度頭を空っぽにしてコードを読むと「この辺は大丈夫」と思っていた部分も全然大丈夫じゃないことがある。
WebRTC を利用した配信の現実
超低遅延、高画質な配信を実現するための選択肢の一つとして WebRTC があります。 ただ WebRTC はもともと少人数で双方向の配信を前提としているため、スケールしないというのが一般的な認識です。 せっかくなので WebRTC サーバを開発・販売している立場から WebRTC を利用した配信の現実がどの程度なのかを書いていこうと思います。 P2P モデルまずは WebRTC といえば P2P なので、WebRTC の P2P 利用についてお話する必要があります。 WebRTC の P2P 利用は、配信者が視聴者分の変換を行うという負担があることから、最大でも 10 名程度までしか配信できません。 さらに、何より配信者の PC 負荷がとても高くなるため、採用は趣味のページまででしょう。 ビジネスで P2P を配信に利用するのはとても現実的ではありません。 配信の場合は P2P で Web
つまみぐい勉強法
ここ数年、気になった自分の専門外の技術を少しずつだが試してみる事にしている。 対象は主にウェブ系の技術が中心だ。自分はミドルウェアが専門の領域のためウェブ技術を仕事で使うことはない。ただ、ウェブ系の技術と連携して使ってもらう場合も多いので、色々知っておこうと思って触ってみている。 方針は「自分が手を動かす仕事では使わない」「専門家になろうとしない」あたり。餅は餅屋なので専門家に任せる。ただこんなことがやりたいを伝える時に触ったことがあるかどうかはとても重要になる。 そこでとりあえず色々やってみる、つまりつまみぐいを積極的にやってみている。つまみぐいは長くても 1 週間触ってみるくらい。チュートリアルから毛が生えた程度で終わらせるようにしている。 もちろん、手を動かしてみたらとても楽しくて、専門家を目指そうとするのもよしとする。今のところは残念ながらそんな器用なことはできていないが。 つまみ
自社の今期振り返りと来期に向けて
自社の決算が 9 末、あと 2 週間ということで振り返ってみたい。 前期が投資期で、 今期は種蒔き期なんて考えていたが、運良く回収期にもなった。正直色々と想定外の期だったように思える。 自社製品を中心に振り返って、ダラダラ書いていく。 運良く自社製品が売れ始める営業がいないので、完全に問い合わせを口を開けて待つスタイルなので、いつ売れるかも運頼み。 それが 2017 年に入ってからはほぼ毎月売れて、社外のお手伝いの売上よりも多いこともあったりした。 自社製品の売上はキャッシュフロー的にとても安定するという事を、実感した 1 年だった。 大手に採用され始める公開できる範囲だとリコー、スクエニ、ソフトバンク（敬称略）という大手に採用されたのは社会的信用という面で大きかった。打ち合わせでもうちが小さい会社だから心配という話がなくなった。 製品の性能や機能、品質などだけで勝負ができるようになった。
リモートワークに対する考え方
自分の中でリモートワークに対する考え方をまとめておくことにする。 そもそも自分自身はリモートワークをするのはかなり難しい、職種的に人と会って話すことを求められる事が多いためだ。 ということで、ここでの考え方というのは、自分が一緒に働く仲間がリモートワークを行う場合の考え方とする。 まずリモートワークに対する考えだが積極的に採用していきたい、という方針だ。ただしその本人がリモートワークに向いており、一緒に働く仲間がリモートワークでも良いと思えるのであれば、という条件付き。 そのため、誰も彼もがリモートワークに向いているとは思っていない。リモートワークを希望し、さらに向いている人のみがリモートワークを行うべきという考えだ。 身近なリモートワーカーまず、自分がどんなリモートワーカーと一緒に働いているのかを書き出してみた。一人は自社役員、もう一人はフリーランサー。 自社の CTO完全フルリモート。
SIP から逃げる理由
WebRTC をやっているとどうしても SIP 関連の話題がでてくる。自分はもともと SIP が面白そうだなと思って色々勉強していたのだけれど、調べれば調べるうちに嫌になってきてしまった。 理由はいくつかあるのだけれど、とにもかくにもオレオレ。本当にオレオレ。そしてクライアントは頑張らない、サーバがひたすらオレオレを吸収する必要がある。 電話機側は暗号関連なんて一切実装していない事が多い。TCP/UDP とか書いてるのに UDP だけしか実装してない。RFC を守る気が全然ない。後安くて適当なイメージ本当に多い。 なんというか、体力と時間をつぎ込む必要が目に見えてきてしまって、萎えた。 WebRTC をやってはいるけれど SIP 関連を話題にだされても逃げるようにしてる。どう頑張っても地獄が待っているように見えてしまう。 SIP 関連を頑張っている人は本当に凄い。それだけで食べれてる会社は
WebRTC サーバを開発する理由
ブラウザ同士がやりとりする WebRTC 、当たり前だが WebRTC をサーバ側に用意することでブラウザとサーバでのやりとりを実現する事ができる。 理由はたった一つでサーバ側で配信データをコントロールすることが出来るようになるからだ。 通常の WebRTC を使って一人が複数人に配信する場合はこうなる 大きく違うのはサーバがブラウザを管理したり、データの流れを管理できるようになることだ。これはニコニコ動画の生放送をイメージして貰えば良いと思う。 もちろんサーバを経由することでサーバ側での録画も可能になる。もともとクライアント側で録画はできたが、P2P で動作されるとサーバ側での録画は難しくなるからだ。 これらの仕組みをプラットフォームとして提供しているのが tokbox だ。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
