E2EE を開発していて思うこと
ここ数ヶ月は自社製品向けの End to End (Media) Encryption の設計と実装をしています。年内での提供を目標として開発を進めてい見ていますが、色々感じることがあったので雑に書いていこうと思います。 前提自分は暗号やセキュリティの専門家ではない自社製品向けの E2EE は Signal や Google Duo が利用している実績のある仕組みを採用しているE2EE や暗号の専門家を招聘し、相談しながら開発している自分の E2EE に対する考え悪意あるサービス管理者からユーザを守るために存在する機能と考えています。 Signal プロトコルはよく考えられすぎているSignal が考えた Curve25519 (x25519/ed25519) を利用した X3DH / Double Ratchet の仕組みは安全すぎると感じるくらいです。 相手からメッセージを受信するたび
IT 系零細企業が技術顧問を招聘してわかったこと
時雨堂では 2020 年 9 月からホワイトボックス暗号と E2EE (End to End Encryption) の専門家であり、LINE の E2EE 脆弱性を報告した 五十部さんを技術顧問として招聘しています。 従業員が片手で足りる零細企業がアカデミックから技術顧問を招聘するとどうなるのかを書いていきたいと思います。 要約自分の知らないことを相談できるのは本当に良い理解できるまで何度も聞ける環境は本当に良い自分たちの専門外に取り組む際、技術顧問を招聘するのはオススメ招聘までの経緯自社製品で E2EE の実装を行うにあたり、自分たちが暗号にも E2EE にも精通していないという課題が重くのしかかっていました。 今まで多くのプロトコルを実装してきて、商用環境で利用できるレベルまで持ってきていましたが、E2EE というセキュリティやプライバシーを重視した仕組みを商用レベルで提供するには自
打ち合わせをしない
自社ではライセンス契約がないお客様との打ち合わせをお断りしています。まずはフィードバックをもらう前提として、 30 日無料で利用可能な評価版を提案します。 理由特定分野に詳しい企業というアピールをしているため、打ち合わせを打診されることは多いです。ただ、話を聞くより、まずは使ってみたほうが早いと思っています。 打ち合わせに行ったから売れたという経験がないこちらの話を聞きたいだけが多い「詳細は打ち合わせで」という意味がわからない何度も打ち合わせをする意味がわからない日程調整をして、打ち合わせをして「音沙汰がない」が多すぎます。 結果とても効果があります。 自社製品に使える時間が圧倒的に増えた打ち合わせで不在という事がなくなり社内連携しやすくなった打ち合わせしないと製品が買えない病と関わらなくて良くなった打ち合わせをしないという戦略も一つの解だと思っています。
製品のリリース頻度を減らす
自社で開発しているミドルウェアパッケージ製品のリリース頻度をどうすれば下げられるかというのが最近の自分の中での課題になっている。 パッケージ製品というのは自社で動かすわけではなく、顧客の環境で動かすわけでアップデート頻度が高い場合、作業負担を強いることになる。 そこでできるだけリリース頻度を下げていきたいと考えているが、なかなか難しいので、どうやってみているかを書いていきたい。 現在のリリース頻度リリースは Ubuntu を真似して 4 月と 10 月で、年 2 回がリリース。致命的なバグ修正や、ブラウザアップデートによる不具合対応などは、修正ができ次第すぐにリリースしている。 クライアント側のバージョンアップへの対応自社製品は WebRTC という技術を使っており、これはブラウザに搭載されている機能の一つになる。ただ Chrome は 6 週間ごと、 Firefox は 6–8 週間ごと
シンプルなチケット方式サポートシステムが欲しい
長い間パッケージベンダーで働いているので、サポートと切っても切れない関係なのだが、自分が求めているようなチケット方式のサポートツールをまったく見かけないので、作るしか無いのかと途方にくれている。 ちなみに、こんな感じのが欲しいというのはすでに体験済み。 それは Vultr のサポートツール。Vultr はかなり価格が安いクラウドサービスで、愛用している。ここのサポートツールがかなり理想で、シンプルかつとても使いやすい。 Vultr のサポート画面チケットを作成する時、通常のサポートなのか、課金関連のサポートなのかを問い合わせられるようになっている。素晴らしい。 None となってるのはどのクラウドインスタンスのサポートを要求するか指定できるようになっている。 そして件名と内容、さらに添付ファイル。あとはチケットをオープンするだけだ。そうすると Vultr 側に通知される。返信が来ればメール
無償での情報搾取
IT 系零細企業を経営していて、特定の技術に強いと外から思われ始めると無償での技術情報の搾取を目的とした問い合わせが多くなる。 自分は残念ながら無償で技術情報の搾取をされた経験があるので、注意喚起として書いておく。この悪しき習慣を潰したい。 情報交換をしたいこのフレーズがメールの文章に含まれていた場合は、とても注意すべきだ。殆どの場合であなたの会社の方が情報を持っており、相手は無償で技術的な情報を得たいと考えていることが多い。 技術の分野の世界はとても狭いので、ほんとうの意味で情報交換を申し込んで来る人はあなたがすでに知っている人の可能性が高い。全く知らない人が情報交換を持ちかけてくるのはまず疑ったほうがいい。 知らない会社から「情報交換をしたい」と言われたら、丁重にお断りをするべきだ。情報交換をしたいと言ってきた会社から仕事につながった経験はまったくない。彼らは一方的な搾取を望んでいるだ
評価制度について – V – Medium
評価制度について年一回、自分の考えを書いていくということをやっていくことにする。 自社の評価制度評価制度自体がないので、評価は行っていない。給与も同じで賞与も同じ。詳細を知りたい方は評価制度の無い評価制度という資料があるので見てもらいたい。 従業員が数名であることもあり、評価制度がない状況でうまく回っている。実際社員に聞いても評価制度がないのは働きやすいとのこと。 会社の事業に対してコミットし、会社の利益がでれば賞与として還元される。この仕組で困っていない。 評価制度に対する考え上司による評価、経営者による評価、全方位評価、様々な評価を受けてきたが、残念ながらどれも満足した評価制度だったことはない。 評価制度は「その評価制度」をハックする仕組みがあるのが問題だと考えている。自分はどうもその評価制度をハックするのがうまいようで、今の所不当な評価をされたことはない。 ただ、ハックできない人が評
世界と戦わない
時雨堂では自社製品を世界に展開させていません。世界で商用の WebRTC SFU があまり無いこともあり、よく世界展開してはどうか？という話をされます。せっかくなので展開に対する自分の考えを書いておきたいと思います。 大きな会社にする予定はなく、零細企業のままで戦うという事を前提にして読んでもらえればありがたいです。 日本で売れないのに世界で売れるという製品ではない時雨堂が販売しているミドルウェアは日本で売れないから世界で売れるという製品ではありません。日本で売れなければ世界で売れないでしょう。 まずは日本で売れてから世界展開を考えるべきだと思っています。そしてまだ十分売れているとは思えません。少なくとも売上の 90% 以上を自社製品でまかなえるようになってから考えるべきです。 世界は難しい時雨堂の製品はなによりサポートを求められて購入してもらうことが多いです。その事を考えるとサポートあり
同時接続 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 を学び始めた頃にはすでにありまし
採用事例の重要性
自社製品をリリースしてから、採用事例は製品の機能よりも強いというのを実感している。 実は採用事例自分はあまり重要視してはいないかった。もちろん無いよりはあったほうがいいだろうとは思っていたので採用事例「なし」の場合は「あり」よりも価格が高くなるという仕組みだけ考えた。 採用事例公開できる場合は 60 万円採用事例公開ができない場合は 84 万円採用事例が公開できない場合は多めにお金がもらえると嬉しい、その程度の考えだった。 採用事例が何よりも重要そんな中、採用事例が何よりも重要という考えを打ち出したのは一人の社員だ。 その社員が採用事例を重要視した第一の理由は顧客は採用事例をみて、自分たちがやりたいことと似ている事例を探し、この製品を買えばいいのかどうかを判断するという考えだ。 この考えは的中した。打ち合わせや問い合わせで「〜という感じで使いたい」が採用事例の中から選ばれる事が多かった。
Erlang/OTP でよく使うライブラリ
製品を開発する際に必要になるプロトコル系のライブラリは全て自作しているので、それ以外に利用しているライブラリの紹介をしていきたい。 これから Erlang で自社製品を作って行こうという人に参考になれば。 otpErlang/OTP の本体。Apache License 2.0 で公開されている。中に色々なライブラリがあるのでせっかくなので紹介。 1 年に 1 回メジャーバージョンアップする。次のリリースは 6 月で、21.0 がでる。楽しみ。 rebar3otp 公式のビルドツールになった rebar3 。本当に便利だしよくできている。これを使わない理由は特に無い。 ドキュメントも丁寧に書かれていて良い。 lager
スキル棚卸し (201803)
定期的に書き出すの大事だと思っているので書き出す。 開発系スキルErlang/OTPWebRTCたぶん今の所、自分が技術的なスキルとしてご飯が食べれていけるのはこの２つ。自分は同じものを長くやっていくのが向いているらしくまだ２つとも飽きが来ていない。 今はここに新しいスキルを追加しようと考えていて、１つが負荷試験。もう一つは FPGA 。 Erlang/OTP長い付き合いになってきた。もうほぼコードを書くのは Erlang/OTP だけで、ちょっとウェブアプリを作る時に Python/Django を使うくらい。それ以外は Erlang/OTP のみ。 もともとミドルウェア屋なので、助かっている。Erlang/OTP では耐えられないような速度を求める仕事を相談されることがほとんどないため、Erlang/OTP で困っていないというのが現状。 去年、会社に Erlang/OTP ハカーが入
IT 系零細企業は何に投資すべきか
正社員 5 人未満の IT 系零細企業を経営して 5 年たったので、何に投資して、何に投資しなかったかを振り返る事にした。 それぞれの会社で色々あるだろうから、これはあくまで自社がこうした、こうしているという話である。それ以上の意味はない。 投資すべき事社員の給与何よりも社員の給与が一番の投資先。人は一定額以上の給与を貰っていれば労働に対するモチベーションが下がりにくくなる。 何よりお金はあって困らない、そして無いと困る。 もちろん会社が儲かっている前提。自社は月給と賞与の比率が 3:7 くらいで賞与が多い。そのため、会社が儲かったら賞与を沢山だす。とにかく税理士と総務に「社員に賞与出しすぎです、この辺でお願いします（実話）」って言われるくらいまで出す。 そのかわり会社が貧乏な時は賞与は一切ださない、というか出せない。ここを理解した前提で入社してもらってる。 とにかく会社に多めに残すくらい
リファクタリング
自分はリファクタリングが好きなので、リファクタリングに対する考えとかを書いてみる事にした。 前提としては自社製品、さらにパッケージソフトウェアのためデプロイは存在しない。リリースは一ヶ月に一回程度。ソースコードは 10 万行未満。 自分がリファクタリングするのは機能追加に飽きた時。ペーストしては月１回程度で、多い方だと思う。よく飽きる。 リファクタリングをする時はまず、コードを端から端まで読みながらコメントをしていくところから始める。その後、またコードを端から端まで読みながらコメントを読みつつ、どんなリファクタリングをするか決めていく。そして、決めたらブランチを切って作業。 とにかく、手を付けるコードを読むことが重要だと思っている。人間は適当なものでコードを適当に理解している事が多いので、一度頭を空っぽにしてコードを読むと「この辺は大丈夫」と思っていた部分も全然大丈夫じゃないことがある。
カスタマイズをしない
自分の会社ではパッケージ製品、つまりお客様の環境で動かして頂く製品を販売している。 そのため、カスタマイズを希望される事もある。今の機能では簡単に実現するのが難しいというのがほとんどの希望理由だ。 カスタマイズの定義は製品に対して＋アルファの何らかの特別な対応を機能を追加することという事にしておく。 結論から言うと自分の会社では一切のカスタマイズを受けないというスタンスだ。カスタマイズはメリットよりデメリットの方が多いという考え方からだ。 カスタマイズのメリットまちがいなく売り上げを上げやすい事だろう。カスタマイズが必須な場合の顧客はカスタマイズを受け付けない製品を購入しない。 さらにカスタマイズ対応ということで、追加の開発費やサポート費を手にすることができる。これは前職で十分実感できた。 ただメリットはこれしか無い。 カスタマイズのデメリット一番大きいのはコードのフォークが発生してしまう
少機能で高機能な製品を作る
ついついやってしまいそうになるのが新しい機能の追加だが、そこは心を鬼にして本当に必要な機能なのかを考えるべきだ。 多機能な製品は市場の幅を広げると思いがちだが、そんなに簡単に市場の幅は広がらないし、多機能にすればするほど価格を上げていく必要が出てくる。 高くて多機能な製品が必要なお客さんはほんの一握りだし、もともとの市場が小さい場合は、そんなお客さんはいない可能性がある。 一度追加した機能は外せない最初のうちに色々便利な機能を追加しようと躍起になりがちだがそれらの機能は一度でも積んだらそう簡単には外せなくなる。 外せないとりあえず付けた機能をメンテナンスしていくのはなかなかしんどい。その機能が邪魔で新しい機能をつけづらい、といった問題もでてくる。 多機能は製品の寿命を縮める場合がある機能を追加すればその分だけコードが増える。さらにテストも増える。依存関係も増える。 つまり、その製品のメンテ
Rust はじめました
Rust は mozilla が開発している言語で、コンパイル型の言語だ。 なぜ Rust なのか理由があるのでそれを上げていこう。 パターンマッチがあるcargo によるパッケージ管理便利1 バイナリ強力な型推論Erlang/OTP と比べて圧倒的に処理性能が早いまずパターンマッチ。Erlang/OTP をメインで使っているものとしては本当にこれがないとツライ。 デフォルトでパッケージ管理システムが入っているのはとても良い。cargo はシンプルでとても良く出来ている。設定ファイルもわかりやすい。 コンパイルして生成されるバイナリ、これ一つで事足りるのはとても良い。 型推論や速度はまぁその通り。早いの大事です。 Rust と比較されるが、実際は全然違うと思う Golang だが、とても素晴らしい。特にクロスコンパイルが良い。さらに性能、ライブラリの充実、シンプルで無駄を省いている言語だと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Erlang/OTP の JIT 実装 BeamAsm が公開されました