JSR Meetup に参加してきた
JSR Meetup JSR が気になっていたことや、Deno の中の人が主催というのも良いなと思って、ささっと参加してきました。自分用に雑にまとめておきます。 https://jsr.io/ https://github.com/jsr-io/jsr ハッシュタグ 自分のメモ Deno Land Inc. が開発、運用しているパッケージレジストリ プライベートは今のところ予定されていない TypeScript をそのまま登録できる ESM 対応 OSS で開発されている 自前の JSR を立てることもできる 積極的に改善されていきそう ドキュメントが生成される Web UI がモダン Deno が流行らないと苦しそう @std を Deno が持ってるのは他からはちょっとな ... って思われそう キレイな npm 雑感 印象としては使ってみても良さそうという感じです。ただ無理に npm
自社サービスのバックエンドを Go から TypeScript へ切り替えるための整理
切り替える理由 自社の主力製品で利用している技術(WebRTC / WebTransport)がブラウザベースのため TypeScript を利用する Go を採用したのは sqlc が使いたかったという理由 sqlc-gen-typescript が出てきたのでもう Go を使う理由がなくなった 自社サービスチーム全員が Go にまったく興味が無い sqlc 自体は便利 そもそも自社に Go への興味がある人がいない 自社サービスの規模ではボトルネックになるのはデータベースであって言語ではない もしアプリでスケールが必要なときは Rust や Erlang/OTP に切り替えれば良い コネクションプールは PgBouncer を利用すればいい TypeScript からは 1 コネクション 1 接続で問題無い どうせフロントエンドでは TypeScript を書く 自社では React
Biome はじめました。
モチベーション そもそも TypeScript や JSX に詳しくないのでどう書くのがいいのか悩みたくない ESLint や Prettier の設定を なんとなく 設定して使ってしまっている Formatter / Linter 関連のライブラリの内容を理解せずにアップデートしてしまっている 依存関係は減らしていきたい Rust で書かれた言語向けの高速なツールが好き Rye とか Ruff とか efmt とか Biome Biome は Rust で書かれた Formatter / Linter を含むツール。本当におかしいくらい早い。 全然大きくないが、以下のソースコードに適用したときの速度。 $ pnpm run fmt > biome format --write ./src Formatted 114 file(s) in 11ms $ pnpm run lint > bi
Rye メモ
$ rye install optuna Collecting optuna Downloading optuna-3.1.1-py3-none-any.whl (365 kB) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 365.7/365.7 kB 1.7 MB/s eta 0:00:00 Collecting alembic>=1.5.0 (from optuna) Downloading alembic-1.11.1-py3-none-any.whl (224 kB) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 224.5/224.5 kB 2.3 MB/s eta 0:00:00 Collecting cmaes>=0.9.1 (from optuna) Downloading cmaes-0.9.1-py3
GistPad 雑録
前提 ローカルとオンラインで同期してくれるメモツールが欲しかった 色々触ってみたがぐっとくるものがなく、VIM モードが最初からある HackMD を使っていた ふと Gist を VS Code で編集できたりしないのだろうかと思い拡張を検索してみたところ、GistPad を見つけた。アクティブに更新している Gist が大量にあり管理できるツールを探していただけ。 GistPad - Visual Studio Marketplace 結論 恐ろしく便利 VS Code 拡張が好きなだけ利用できる VS Code 拡張 クローズドなメモ帳としては文句ない 連携は向いていないので連携したい場合は別のツールを使うべき ネガティブはモバイルから利用できないことくらい 自分にとって何が GistPad は良かったか VS Code ベースなので VS Code の拡張が全て利用可能 VS Co
Cloudflare Load Balancing メモ
Cloudflare Load Balancing 普通の LB と何が違うのかというと、WAF やら Cloudflare Workers の後ろに置けるというのが大きい。さらに今話題の Cloudflare Zero Trust も利用できる。 以下のトラフィックシーケンスをみてぐっと来た人は黙って使うべき。 参考 Cloudflare Load Balancing | DNS Based Load Balancing Solution | Cloudflare Cloudflare Load Balancing · Cloudflare Load Balancing docs なぜ採用したのか マルチクラウドを採用したいが、自前で LB を立てるのはめんどくさい、そこで最初は Cloduflare Workers を使おうと考えていたが、 Cloudflare Load Balanc
S3 互換オブジェクトストレージまとめ
概要 S3 互換オブジェクトストレージの サービス を自分のためにまとめている。サービスとして提供されているのが前提で、 自前運用は範囲外 。 目的 以下の内容に絞って調べている。 日本リージョンの有無 egress の費用 容量の費用 追加調査予定 PutObject 対応 PresignedGetObject 対応 S3 互換 S3 互換の条件は s3cmd や aws sdk s3 がそのまま利用できる事。細かい互換性は気にしない。 比較用の AWS S3 https://aws.amazon.com/jp/s3/pricing/ 最小プラン Tokyo / Osaka リージョンあり 1 GiB 追加の egress 転送量は 0.114 ドル 1 GiB の追加容量は 0.025 ドル TODO SLA 書いてるのと書いてないのがあって拾いにくい 対象外 Azure は S3 互
Cloudflare Workers メモ
前提 Cloudflare Workers は知っていたが最近触って、本番環境へ導入済み。 普段は Erlang/OTP を書いてるので JavaScript は専門外 自社サービスの本番環境には Cloudflare Workers を導入済み OpenResty はエンタープライズ大規模環境向けで設計/開発経験あり 雑感 Cloudflare Workers® ざーっと見た感じ Nginx + Lua (OpenResty) のマネージド、さらに Edge で動かしてくれて、スケールも勝手にしてくれるバージョンという認識。実際 shared.dict / redis の代わりが Workers KV が利用できる。 さらにローカル開発環境が充実している、デプロイ後のログ確認も管理画面から簡単に利用できる。 Lua Introducing Cloudflare Workers これを読む
ドキュメント駆動開発v2
前提 ここで言っているドキュメントは仕様書ではなく、顧客向け製品ドキュメント。 ミドルウェア製品を開発 小さなチーム パッケージ製品とパッケージ製品のクラウド版 そのため顧客に提供するドキュメントが必ず必要 GitHub を利用 自分で開発する場合のフロー 作りたい機能をぼんやりでいいので GitHub Issue に追加する feature ブランチを切る デザインドキュメントをリポジトリの doc/ 以下に書く デザインドキュメントに合わせてコーディングを進めてなんとなく動くところまで作る 動かなくてもいいのでイメージを膨らませるためにコードを書いてみる デザインドキュメントは書き捨て前提で、とにかくメモを書く 製品ドキュメントを書き始めて、一旦書き終える ブランチマージに向けてコーディングを進める 書ける範囲でテストを書く ドキュメントを平行して修正する プルリクエストをだしてレビュ
Clubhouse リアルタイム配信の仕組みについて (解説編)
Cloubhouse はすでに OSS である Janus Gateway に切り替えており Agora は使用していないようです ライセンス Creative Commons — 表示 - 非営利 - 改変禁止 4.0 国際 — CC BY-NC-ND 4.0 前提 ざっくりと雑に解説。 どんな技術を使っていてこんな感じだろうという妄想は以下をどうぞ。 Clubhouse リアルタイム配信の仕組みについて (妄想編) 著者 商用 WebRTC SFU 開発者 WebRTC プロトコルスタック実装者 End to End Encryption プロトコルスタック実装者 Clubhouse の仕組みはとてもシンプルで配信者が N 人で、それを数千人が聞くという co-streaming と呼ばれる仕組みの一つ。この方式は今までは主に映像ありでパネルディスカッション的な使い方が主だっだ。それを
TURN サーバでよくある間違い
ライセンス Creative Commons — 表示 - 非営利 - 改変禁止 4.0 国際 — CC BY-NC-ND 4.0 前提 TURN サーバを間違って理解している人が多いので雑にまとめておく。 TURN プロトコル自体を知りたい場合 WebRTC で利用されいる TURN プロトコルの解説 著者 商用 WebRTC SFU 開発者 商用 TURN サーバ実装者 (WebRTC SFU に組み込み) WebRTC プロトコルスタック実装者 よくある間違い TURN サーバはリレーするパケットの中身を見ることができる TURN サーバを通るもともとのパケットを復号化したりしない ただ通信が暗号化されていなければ見ることはできる TURN サーバはスケールが難しい 1 接続事に独立しているので TURN サーバ同士で状態を共有する必要はないので難しくない Username / Cr
WebRTC を今から学ぶ人に向けて
この資料には宣伝が含まれます ライセンス Creative Commons — 表示 - 非営利 - 改変禁止 4.0 国際 — CC BY-NC-ND 4.0 内容 これから WebRTC を学ぶ人が何を学ぶべきで、何は学ばないべきなのかを書く。定期的に更新していく。 趣味で学びたい人はターゲットに入っていません、仕事で利用する場合のみがターゲット。 まとめ 急がば回れで、W3C の資料を理解できるまで読み込む。 下手にフレームワークに依存したりして簡単な仕組みを覚えてしまうと後からツライ。 Media Capture and Streams WebRTC 1.0: Real-Time Communication Between Browsers Identifiers for WebRTC's Statistics API 作って学ぶも良いが、まずは出てくる単語などの意味を理解できるの
Clubhouse リアルタイム配信の仕組みについて (妄想編)
Cloubhouse はすでに OSS である Janus Gateway に切り替えており Agora は使用していないようです ライセンス Creative Commons — 表示 - 非営利 - 改変禁止 4.0 国際 — CC BY-NC-ND 4.0 前提 @suthio_さんがつぶやいていたのがきっかけ https://twitter.com/suthio_/status/1353945619577008128?s=20 招待してくれた @dmnlk さんに感謝 DNS パケット見ただけ 他の方の解析は見ていない クライアント側の処理は知らない 気が向いたら更新している 著者 商用 WebRTC SFU 開発者 WebRTC プロトコルスタック実装者 End to End Encryption プロトコルスタック実装者 IRIAM 配信サーバ設計者 妄想 求人にメディアサーバ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Litestream メモ