V

WebRTC のようなリアルタイム通信で求められるのは「一部のノードに問題が起きても利用し続けられる」事だと考えています。

そのため時雨堂では自社製品である WebRTC SFU Sora にクラスター機能を搭載し、一つのノードに障害が起きた場合でも再接続を行えばすぐにまた利用できるような仕組みを実現しています。

2022 年 6 月にリリース予定の次の …

--

--

Twitter で “The Nitche Programmer” という記事が流れてきたので、自分もおそらくニッチプログラマーのくくりには入ると思うので雑に何か書いておこうと思います。

思ったことを適当に書いていくので読みにくいと思います。適当に流し読みしてください。

まとめ

ニッチかどうかはどうでもいい。

ニッチプログラマー

はじめてのちゃんとしたプログラミングは Python 2.2 あたりから始まり、その後 Erlang/OTP へ切り替えて 10 年以上 Erlang/OTP を書いてご飯を食べています。

最近では WebRTC をメインでやっており、 Erlang/OTP + WebRTC という組み合わせであればおそらく日本では社員を除けば自分だけというくらいニッチです。世界的に見ても Erlang/OTP + WebRTC の製品を作ってパッケージを売っている会社は自社しか知りません。

なぜニッチプログラマーなのか

最初はウェブアプリに興味を持っていて Python + Django をやっていたのですが、そのうち Web サーバに興味が移り、仕事でミドルウェアに関わるように完全にミドルウェアの虜になり、通信系ミドルウェアを開発する言語として Erlang/OTP を知り、そこからずっと通信系ミドルウェア屋をやっています。

つまり、やりたいことやっていたらニッチプログラマーになっていたというだけです。別にお金が欲しいからとか採用が楽になるからとかで、狙ってニッチな言語やニッチな技術をやってるわけではありません。

ニッチプログラマーに求められるもの

ニッチプログラマーに求められるのは実はニッチな言語に強いことでもニッチな技術に強いことでもありません。それらニッチな技術を使ってお金を稼ぐ能力です。

ニッチな技術をお金に換えるのは実はとても難しいです。そのニッチな技術自体をお金に換えることが難しいからです。たとえば今国内で Erlang VM 系の仕事を探したとしても、良い金額で手を上げてくれるのは mixi くらいでしょう。

ニッチかどうかはどうでもいい

Erlang/OTP で製品を作っていて「Erlang/OTP というニッチ言語で作られているから製品を買わない」と言われた事は一度もありません。つまりニッチかどうかは顧客はどうでもいいのです。

たとえば最近は Rust に明るい社員が入ってきたので Rust + Erlang/OTPで動く WebTransport を利用した新製品を開発したりしています。Rust + Erlang/OTP + WebTransport の組み合わせは相当ニッチでしょう。ただニッチだから選んでいるのではなく、Rust に明るい社員が入ってきて、Rust で書かれた優秀な HTTP/3 ライブラリがあり、Erlang/OTP と Rust を組み合わせるライブラリがあり、プロトコル処理以外はすべて Erlang/OTP で書いた方が自社が持ってるパッケージ製品ノウハウが生かせるからです。

つまりニッチかどうかじゃなくて効率が良いから使ってるだけです。もちろん長年 Erlang/OTP を使ってきた事による影響はあると思います。ただ、何度も言いますがニッチだからその言語を使ってるわけではありません。作りたいものを作る事にマッチしていたからです。

気付いたらよくわからないが世間から見るとニッチなプログラマーになっていたというだけです。自分からすれば別にそんなのどうでもいいです。

自分がやりたいことがやれていればそれで十分なので。

元々の記事は「ニッチな言語の場合は賃金は素晴らしく、競争は少なく、面接のプロセスはほとんどの場合非常に人道的で、ニッチな言語が主流になったら別のニッチな言語を探す」という結論の話でした。

これは「好条件を得るためにニッチな技術を続けていく」という話なので、お金を稼ぐ戦略としては悪くないと思います。ただこれを続けられる人がどれだけいるのかは少し疑問です。

--

--

時雨堂では Erlang/OTP 関連の OSS を Fork して運用しています。Fork をするにあたって最低限の方針を雑にまとめてみました。

自社製品で利用する OSS である

当たり前ですが 一応。

OSS のライセンスが明確かどうか

LICENSE ファイルがあり、ライセンスが明確になっていること。さらに OSI 準拠の OSS であることを条件に Fork しています。

Pull-Request は可能な限りだす

Pull-Request を出さずに Fork するのは可能な限り避けています。ただし、 Pull-Request を出しても採用されにくい時雨堂固有の機能の場合は Pull-Request を出さずに Fork することもあります。

Fork する理由

Fork する理由はシンプルで、Pull-Request が採用されるまでの時間がもったいないからです。

Fork の運用

まず Fork したらかならず shiguredo というブランチを切り、デフォルトブランチに設定します。こちらに変更を加えていきます。コミットログは基本的に Fork 元にあわせており、ほとんどが英語になります。

利用する際は必ずタグを打ちます。タグは時雨堂バージョニングを採用します。YYYY.RELEASE.FIX というバージョン形式です。

Erlang/OTP 系のライブラリの場合は hex.pm への登録を行う際に、app.src の pkg で shiguredo_ という prefix をつけます。

実際に運用している Fork

実際に運用しているのは 3 つのリポジトリです。すべて Pull-Request や Issue は立てていますが、まだ対応されていないものがあるため Fork をしています。

Fork を閉じるタイミング

Pull-Request がマージされて、タグがつけられ、リリースされたタイミングで閉じます。

--

--

LabStack LLC は Go のウェブフレームワークである echo を開発している企業です。

時雨堂では自社サービスのバックエンドには Go のウェブフレームワークである Gin を採用してきました。ただ Gin 自体が思った以上に活発にメンテナンスされていないことや、依存性が多いことが気になっていました。

もともと echo 自体は知っていて、昔試したことはあるのですが Gin の方が多機能で欲しい機能が一通りありそうということで Gin を採用していました。

ただ、 Go でのバックエンドの開発にも慣れてきたことから、よりシンプルなフレームワークの切り替えを検討しており、新規サービスを作っている中でせっかくなので Gin から echo に切り替えてみることにしました。

実際切り替え自体は 1–2 時間程度でおわりました。はまりどころは特になく、むしろコード自体がへりました。Gin で気になってた空 return ではなく error を返すモデルは Go っぽくて気に入っています。

仕組み自体もシンプルで echo.Context が少し特殊なくらいですが、ここはカスタマイズをする前提で考えると気にしなくてよさそうという判断にいたりました。

実際社員にも切り替えたコードをレビューしてもらいましたが、特に違和感はなかったようで、今後時雨堂では echo を利用していくという方針にしました。

echo を開発している LabStack が GitHub スポンサーを募集していたので、せっかくだしということで $250 (一番高いプラン) でのスポンサーになってみました。Logo or name on project website と書いてあったので、そのうち時雨堂のロゴが echo プロジェクトのウェブサイトに乗ると思います。

時雨堂は多くの OSS を利用して自社製品を開発しています。少しでも利用している OSS に還元しようと考えており、多くの OSS スポンサーになっています。

今後も自分たちが利用している OSS のスポンサーが継続できるよう、OSS を活用した良い製品を作り続けて、利益を上げ、OSS へ還元できればと思っています。

--

--

なんだそれという人がいると思うので、Cloudflare Blog の引用から紹介。

Cloudflare WARPをローンチしました。ボタンを押すだけで、ユーザーはWireGuardトンネルを使用して、近くのCloudflareデータセンターを経由しながら、モバイル端末をインターネット全体に接続することができます。Cloudflareが保護するサイトへのトラフィックはさらに高速化され、インターネット全体で、ユーザー体験がより安全でプライベートになりました。

つまり、ざっくりいってしまうとプライベートリレー機能です。

WARPは、「VPN」が何を意味するのかを知らないユーザーでも、VPNが提供する保護を簡単に取得できるべきだという理念に基づいて構築されました。しかしながら、旧来の企業VPNに精通している当社では、これよりも優れた何かを必要としていました。BoringTunという独自のWireGuard 実装を新たに取り入れることになりました。

導入はアプリをインストールするだけでよく、とても簡単です。

Cloudflareではお客様の個人データをスヌープしたり販売することはありません。また、DNS-over-HTTPS または DNS-over-TLSを当社の1.1.1.1リゾルバーにお使いの場合、DNSリクエストはセキュアなチャネルで送信されます。つまり、1.1.1.1リゾルバーを使うと、プライバシー保護に加えて、傍受者がユーザーのDNSリクエストを見ることができなくなるということです。信じられない方もいらっしゃるかもしれませんが、事実です。

1 アカウント最大 5 デバイスまで指定可能で、価格は月 $4.99 で利用可能です。おすすめです。

導入すると以下のような感じのアプリがメニューバーに常駐します。無効化するのも簡単dえす。

--

--