2023 年に学んで良かった技術や知識
雑に書いていきます。 バックグラウンド自分のスキルは以下の通り。専門はリアルタイムな通信プロトコルを利用した製品の設計と開発、マーケティング。 Erlang/OTPWebRTC細かいのはこちら。 PyPIhttps://pypi.org/ 自社製品の Python SDK をリリースにあたりかなり調べた。スゴイ大変だった … 。 WebAuthn / Passkeys自社サービスに使おうと思って調べて、実装したりもしてみたがコスパが見合わないのでどこかのサービスを使おうと考えてる。いつか自作したい。 Biomehttps://biomejs.dev/ フォーマッターとリンターの設定に疲れていたので、採用したところ最高だった。勢い余ってゴールドスポンサーにもなった。 pnpmhttps://pnpm.io/ npm 遅いし、使いづらいなと思っていたので覚えた。workspace も便利。pn
なぜ Zig の採用を検討しているのか
かなり雑に書いてるので、雑に読んでください。 Bun が Zig で開発されていることを知り、そこから Zig を調べてみています。 調べていくと自分が求めていた言語っぽいというのがあり、社外では学生に QUIC や TLS 1.3 を Zig で OSS を開発してもらうお仕事を出したり、社内では実際に採用に向けて調査を進めています。 そもそもの目的自分の会社では Erlang VM を利用した製品をメインに利用しています。ただ Erlang VM 遅いんです。少なくとも暗号処理であれば Rust の方が 2 倍ほど速いです。Erlang VM 自体 JIT を採用したり、いろいろ頑張ってくれているのですが劇的な高速化というのは今すぐには難しいのが現実です。 そこで NIFs (Native Implemented Functions) を使って頑張るという戦略があります。早い話が Er
ベンダーロックイン
零細 IT パッケージメーカー経営視点での時雨堂のベンダーロックインについての考えをなんとなく書いておきたかったので書いてみます。特に目的はありません。雑な文章なので適当に読んでください。 ベンダーロックインとは特定ベンダー（メーカー）の独自技術に大きく依存した製品、サービス、システム等を採用した際に、他ベンダーの提供する同種の製品、サービス、システム等への乗り換えが困難になる現象のこと。Wikipedia から引用しました。自分の認識ともあってるので間違ってはいなさそうです。IT 企業で商用パッケージを採用するとほとんどの場合でベンダーロックインになるのは間違いないと思います。 むしろベンダーロックフリーな製品でビジネス的な競争力を作るのは難しいと思います。それができてる企業は本当にすごいです。 自社も間違いなくベンダーロックインさせる側です。ただ、できるだけベンダーロックインをさせない
ニッチプログラマー
Twitter で “The Nitche Programmer” という記事が流れてきたので、自分もおそらくニッチプログラマーのくくりには入ると思うので雑に何か書いておこうと思います。 思ったことを適当に書いていくので読みにくいと思います。適当に流し読みしてください。 まとめニッチかどうかはどうでもいい。 ニッチプログラマーはじめてのちゃんとしたプログラミングは Python 2.2 あたりから始まり、その後 Erlang/OTP へ切り替えて 10 年以上 Erlang/OTP を書いてご飯を食べています。ここ数年は開発に注力はせず、ビジネス考える人になっています。 最近では WebRTC をメインでやっており、 Erlang/OTP + WebRTC という組み合わせであればおそらく日本では社員を除けば自分だけというくらいニッチです。世界的に見ても Erlang/OTP + WebR
零細企業経営にはほとんどの意見が参考にならなかった話
いつか書こうと思っていたので雑に書いていく。 要約基本的に人の意見は参考にならない、聞く必要ない。自分の考えを信じたほうがいい。 ただし、IT 系の企業経営者で信頼できるなら人が身近にいるのであれば、意見交換はしたほうがいい。最近全く会えてないが、ヴェルクの田向さんと Sigfoss の森さんから頂いた意見はとても役に立った。 社外の人間の意見は参考にはならない自分が起業したときに苦労したので、書いておくが、この記事も参考にならないと思ったほうがいい。 思い立ってすぐに起業したので、ほとんど知識がなかった。いろいろな人の意見を聞いてみたが、実際に経営してみると全く参考にならなかった。 助成金の話ばかりする人これは最初に契約した税理士が良くなかっただけかもしれないが、基本的に助成金の話しかしてこない。助成金の仲介手数料が目当てなんだろう。 ちなみに助成金に関しては社員時代に一度助成金を使った
なぜ WebAssembly 生成を Go にしたのか
オンラインイベントで聞かれて、ツイッターにつぶやいたら思った以上に反響があったので、もう少し詳細に書いてみます。 思ったより反響があったまとめ信頼できる暗号ライブラリがある自分が TypeScript より Go のほうが書けるGo の Wasm バイナリサイズを気にする必要がないWebCrypto にない暗号が必要自社の WebRTC SFU において End to End Encryption (E2EE) をブラウザ上で実現するためにはいくつかの壁がありました。 一つは WebCrypto が提供していない暗号を利用したいというものです。 今回 E2EE を実装するにあたり採用した Signal プロトコルでは公開鍵暗号に Curve25519 を採用しています。残念ながら WebCrypto では Curve25519 に対応していません。この時点で「暗号ライブラリをどこからもって
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 というセキュリティやプライバシーを重視した仕組みを商用レベルで提供するには自
お手伝い先でやったこと、やってること
2020 年 1 月から株式会社ZIZAI の IRIAM で「雑談するおっさん」をしています。なにをやったか、なにをやってるかを書いていこうと思います。ちなみに自分の本業は開発者です。 まずお手伝いする上で条件を出しました。 サーバ/インフラに関する技術決定権採用判断権組織改善権評価改善権結果としては偉い人から「何やっても構いません、全部おまかせします」って返ってきました。 さて、やったこと、やってることを箇条書きで書いてみました。技術的な話の詳細は内緒なので書きません。 Twitter での定期的な採用告知自分への Slack DM の禁止自分への返信はスレッド禁止（好み問題）可能な限り即決断する自分だけでは決断できない場合はいつまでに判断する旨を伝えるSlack のパブリックで #shiguredo を作ってもらい、自分とはそこでのみ会話するエンジニアの上下関係の削除プライベートに対
Krisp というノイズキャンセルソフトウェア
テレビ会議するときにノイズが気になるというのはあると思います。キーボードを叩く音だったり、マウスをクリックする音だったり。 これらをきれいに消してくれる有料のソフトウェアがあるのでおすすめとして書いておきます。 以下から登録すると +1 ヶ月体験時間が長くなるようなので是非。
海外のOSS なWebRTC SFU 開発者たちがコミュニティに絶望してる話
WebRTC コミュニティの問題これ以外にも webrtc-discuss や react-native-webrtc などのコミュニティでもドキュメントを読めば分かる質問、回答を書いても反応がない、助けて！とだけ書かれた投稿などがとても多いです。 この理由は OSS よくあるといえばそれまでなんですが、それ以外にも問題があると思っています。 WebRTC って音声や映像をリアルタイムに送受信する技術なわけですが、誰が見てもわかるんです。音が来ないもすぐわかるし、映像が遅延してる、表示されないもすぐわかってしまうんです。 つまり技術者じゃなくても問題が起きていることに気づけてしまうんです。 で「なんか音声が流れてこない！このソフトウェアは問題だ！」となってしまうわけです。 これに対応する場合、作者たちは「WebRTC という技術の難しさをよくわかっていない人たち」へ無料のサポートを提供しな
自社 OSS のコミュニティ運用を Discord に集約した
自社の OSS と無料サービスのコミュニティをすべて Discord に集約しました。かなりうまく回っていると思っているので、どんな感じで運用しているかを書いていきます。 前提IT 系パッケージメーカーな零細企業クローズド自社製品で食べているOSS へのサポートは提供していない無料サービスへのサポートは提供していないOSS へは積極的に投資しているロードマップにある機能を有償で前倒して実装することもあるコミュニティマネージャーの採用信頼できる技術者に副業としてコミュニティマネージャーをお願いしています。 仕事内容は責任はなく、基本的には誰かがチャットをしたときに反応をしてもらうというものです。質問しやすい空気を作ってもらっています。 また、コミュニティマネージ以外に検証の仕事も合わせてお願いしているます、そのため OSS やサービスをユーザ視点で触っており、技術もわかるコミュニティマネージ
WebRTC P2P 向けシグナリングサーバを OSS で公開してわかったこと、今後やっていくこと
Ayame という WebRTC P2P 向けのシグナリングサーバを公開して 1 年過ぎて、色々わかったことがあるので、まとめて、さらに今後どうしていくかを書いていきます。 前提時雨堂では Ayame をビジネスに繋げるきは全くありません。あくまで「WebRTC で P2P」をできる限り使いやすく、簡単にしていくという思いがあります。 また得られた情報をできるだけアウトプットすることで、 WebRTC 界隈への貢献をしていきたいとも思っています。閉じた世界で自分たちだけが利益を得るというのはその市場を狭めてしまうと考えているからです。 利益は WebRTC SFU であげる前提です。P2P が好き、WebRTC が広まって欲しいという気持ちで WebRTC P2P 向けシグナリングサーバを公開しています。 WebRTC P2P はビジネスとして難しいWebRTC P2P 向けのシグナリング
コードを書き続ける
「開発者は経営者になったらコードを書くのやめて、経営に集中すべき」という考え方を聞いたことがある人はいるだろうか？ 自分はこの考えを持っていた経営者の元で働いていたことがあるので、強く印象に残っている。そして優秀な開発者たちが無理やりコードを書く時間を取り上げられ、経営者とされていったのを何度か見ている。 ここに書くのは自分の経験談であり、こうすべきとかではない。そしてなにより自分は死ぬまでコードを書き続けたいと考えているタイプであるということだ。 伝えたいことは一つだけでコードを書き続けたい経営者からコードを書くのを取り上げるのが良い方法だと思わないということだ。 また、経営者だから偉そうにコードを書くとかは当たり前だがなしだ。経営者関係なく、ただの開発者としてコードを書くという前提のお話。 開発者と経営者起業して 5 年が過ぎた。経営者としても 5 年、開発者としても 5 年。社員をし
自社サイトを徐々に Netlify へ切り替えている
今まで自社のサイトは Nginx / Django か Sphinx / Vulter という構成だったが、Next.js + Netlify でいいのではないか、ということで切り替えをすることにした。 なぜ Netlify なのか最低条件が HTTPS 化するさいに Let’s Encrypt を使っていること、でした。これで AWS (CloudFront) がなくなりました。あとは実際にさわってみて、です。 デプロイが簡単だった月の費用が 45 ドルと現実的だったCDN 前提だった管理画面がシンプルでわかりやすかったGitHub 連携が簡単だったDNS 設定が簡単だったデプロイが高速だったSlack 連携が簡単だったパスワードかけるのが簡単だったSphinx のビルド、デプロイが簡単だったサイト数に制限がなかった請求メールが別に指定できたGitHub でアカウントが作れたアカウント招
打ち合わせをしない
自社ではライセンス契約がないお客様との打ち合わせをお断りしています。まずはフィードバックをもらう前提として、 30 日無料で利用可能な評価版を提案します。 理由特定分野に詳しい企業というアピールをしているため、打ち合わせを打診されることは多いです。ただ、話を聞くより、まずは使ってみたほうが早いと思っています。 打ち合わせに行ったから売れたという経験がないこちらの話を聞きたいだけが多い「詳細は打ち合わせで」という意味がわからない何度も打ち合わせをする意味がわからない日程調整をして、打ち合わせをして「音沙汰がない」が多すぎます。 結果とても効果があります。 自社製品に使える時間が圧倒的に増えた打ち合わせで不在という事がなくなり社内連携しやすくなった打ち合わせしないと製品が買えない病と関わらなくて良くなった打ち合わせをしないという戦略も一つの解だと思っています。
HTTP/3 や QUIC はまだ早すぎる
フューチャーアドベントカレンダー2018](https://qiita.com/advent-calendar/2018/future)のピンチヒッターです。ワイキキの海を見下ろすホテルからこんばんわ。 QUICがリブランドされて... 渋川の記事の補足というか、実装者目線からみた話を書きます。 立ち位置仕様策定には関わっていません。あくまで出てきた仕様を実装する実装者（Implementor) です。 また HTTP/3 や QUIC がメインというよりかは WebRTC がメインです。WebRTC が利用しているプロトコルが QUIC に置き換わる流れがきているため、QUIC を実装しており、さらに QUIC を利用したプロトコルとして、まずは HTTP/3 が採用されていることから、HTTP/3 に手を付けている状況です。 現時点では Chrome Canary M74 で利用可能な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ビデオ会議の使い方
Amazon Kinesis Video Streams がWebRTC に対応した
Vim の gj gk を VSCode で実現する