自社サービスのバックエンドを Go から TypeScript へ切り替えるための整理
切り替える理由 自社の主力製品で利用している技術(WebRTC / WebTransport)がブラウザベースのため TypeScript を利用する Go を採用したのは sqlc が使いたかったという理由 sqlc-gen-typescript が出てきたのでもう Go を使う理由がなくなった 自社サービスチーム全員が Go にまったく興味が無い sqlc 自体は便利 そもそも自社に Go への興味がある人がいない 自社サービスの規模ではボトルネックになるのはデータベースであって言語ではない もしアプリでスケールが必要なときは Rust や Erlang/OTP に切り替えれば良い コネクションプールは PgBouncer を利用すればいい TypeScript からは 1 コネクション 1 接続で問題無い どうせフロントエンドでは TypeScript を書く 自社では React
コードを書き続けるためにやってること
この記事は 6 年前に書いた記事を更新したものです プログラミングの生産性を上げるには - Cside::Private とても面白かったのでマネしてみた。人それぞれあると思うので自分のスタイルを。 といっても、かなり不真面目なので参考にはならないと思う。 1. README.rst を書く まず最初に何がしたいのか、どんなことをしたいのかを書く 概要、ゴール、実装方法、使用ライブラリ、TODO などを書いていく そして README.rst に擬似コードを書き始める コンパイルが通る必要は無い コメントもガンガン書いていく とにかく issues とか使わず全て README.rst に書いていく 一通り出来てきたら GitHub Issues にタスクを移す 2. 擬似コードでプロトを書く コードを書いてみないと分からない事が多いのでまずはコードを書く 自分が一番かける Erlang
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 互
ドキュメント駆動開発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 と呼ばれる仕組みの一つ。この方式は今までは主に映像ありでパネルディスカッション的な使い方が主だっだ。それを
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ページを開く
Webhook.site のまとめ