まとめ 検索エンジンは DuckDuckGo を使っている DNS は NextDNS を使っている macOS / iOS / iPadOS で利用している 自社でも NextDNS を採用した ログはオフで運用 なぜ DuckDuckGo ? DuckDuckGo — Privacy, simplified. Google の検索結果があまりにも酷いと感じており、 uBlacklist を利用してブロックしていたがきりが無くなってきたので、切り替えた。 DuckDuckGo ブラウザは利用しておらず Chrome を継続して利用している Chrome Extension として DuckDuckGo Privacy Essentials を追加して利用している 特に困ることはない。今後も DuckDuckGo を使っていこうと思う。 DuckDuckGo Privacy Pro が日本

切り替える理由 自社の主力製品で利用している技術(WebRTC / WebTransport)がブラウザベースのため TypeScript を利用する Go を採用したのは sqlc が使いたかったという理由 sqlc-gen-typescript が出てきたのでもう Go を使う理由がなくなった 自社サービスチーム全員が Go にまったく興味が無い sqlc 自体は便利 そもそも自社に Go への興味がある人がいない 自社サービスの規模ではボトルネックになるのはデータベースであって言語ではない もしアプリでスケールが必要なときは Rust や Erlang/OTP に切り替えれば良い コネクションプールは PgBouncer を利用すればいい TypeScript からは 1 コネクション 1 接続で問題無い どうせフロントエンドでは TypeScript を書く 自社では React

モチベーション JSONL を読み込んで解析するツールが欲しかった ログを読み込ませたいので圧縮機能は必須 自社のパッケージ製品が出力する JSONL を読み込んで解析できる仕組み 顧客が問題解析を気軽にできるようにしたい 顧客向けツールとして提供したい つまり顧客環境で動かしたい 1 バイナリ OSS として提供したい Apache-2.0 として公開したい ログファイルは大きくても 100 GB は行かない もともと Go + SQLite + JSONB で検討していた SQL で書きたい SQLite ファイルとして書き出したい SQLite ファイルフォーマットは信頼できる S3 などにファイルを置いておくだけにしたい クラウド版に組み込みたい 顧客毎に duckdb ファイル作ればいいのでは？ duckdb ファイルダウンロードできると便利そう DuckDB https://d

モチベーション そもそも 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

自社パッケージ製品のクラウド版 を開発していて、色々やりたい放題やってるのでメモ。 方針 遠回り駆動開発 やりたい放題やる 王道は無視して「じぶんのかんがえたさいきょうの」をでいく 可能な限り OSS 開発元が提供しているクラウドサービスを利用する ベアメタルサーバーを使う 三大クラウドサービス (AWS, GCP, Azure) を使わない なぜ利用している技術を公開するのか 自社で使って良かった OSS やサービスはより多くの人に知って欲しいと考えています。 また、特に隠す理由がないというのもあります、むしろ大きな声で Tailscale や TimescaleDB 、 VictoriaMetrics 、Cloudflare 、DataPacket など、ほんとうに素晴らしい使わせて頂いていると言っていきたい。 我々が利用させて頂いている製品の企業や開発者の方へ とても素晴らしい製品を

$ 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

前提 ローカルとオンラインで同期してくれるメモツールが欲しかった 色々触ってみたがぐっとくるものがなく、VIM モードが最初からある HackMD を使っていた ふと Gist を VS Code で編集できたりしないのだろうかと思い拡張を検索してみたところ、GistPad を見つけた。アクティブに更新している Gist が大量にあり管理できるツールを探していただけ。 GistPad - Visual Studio Marketplace 結論 恐ろしく便利 VS Code 拡張が好きなだけ利用できる VS Code 拡張 クローズドなメモ帳としては文句ない 連携は向いていないので連携したい場合は別のツールを使うべき ネガティブはモバイルから利用できないことくらい 自分にとって何が GistPad は良かったか VS Code ベースなので VS Code の拡張が全て利用可能 VS Co

モチベーション ドキュメントツール Sphinx から出力した HTML オンラインドキュメントに日本語対応の全文検索機能を追加したい。 結果 オンラインドキュメントと日本語全文検索 前提 日本語全文検索に対応する OSS を利用する ドキュメントツールは Sphinx を利用する Sphinx の検索バーを置き換える サーバレスの検索は諦める サーバ運用を検討する 企業利用前提なので費用がかかっても良い 検索は難しいので検索部分は頑張らない 完璧は求めない reStructuredText を解析するのではなく HTML を解析して処理する Meilisearch を採用 いろいろ調べたりしていたが Meilisearch が良さそうと判断した。 Meilisearch 日本語検索に対応している Rust で書かれており性能がでそう Rust であれば問題が起きた際、会社でなんとかできる

課金体系 無料枠 ingress / egress 転送量 無料 10 GB / month 無料容量 10 G Class A Operations 1,000,000 requests / month ListBuckets, PutBucket, ListObjects, PutObject, CopyObject, CompleteMultipartUpload, CreateMultipartUpload, UploadPart, and UploadPartCopy Class B Operations 10,000,000 requests / month HeadBucket, HeadObject, and GetObject Free operations DeleteObject, DeleteBucket and DeleteMultipartUpload. 有料

注意 とっても雑な検証なので参考などにはしないでください。ちょっとした興味で自分用に調べてるだけです。 結論 Echo を利用した秒 1 万リクエストを超えないウェブサービスで、かつ SQLite の機能で要件がみたせるのであれば、SQLite + Litestream 十分と判断出来る結果だった。 利用技術 Load testing for engineering teams | Grafana k6 Grafana に買収された Go で書かれた負荷試験ツール JS でシナリオが書ける Litestream - Streaming SQLite Replication SQLite リアルタイムバックアップツール mattn/go-sqlite3: sqlite3 driver for go using database/sql Litestream も使ってる 安心と信頼の matt

Litestream Litestream - Streaming SQLite Replication benbjohnson/litestream: Streaming replication for SQLite. SQLite を S3 のようなオンラインオブジェクトストレージにリアルタイムでレプリケーションをとる仕組み。 事例 A database for 2022 · Tailscale Tailscale が Litestream へ移行している

Webhook.site https://webhook.site/ というウェブフックを即座に受信できる URL をアクセスするだけで作成してくれるサービスがあります。このサイトが本当に便利なので、紹介していきます。

概要 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 は知っていたが最近触って、本番環境へ導入済み。 普段は Erlang/OTP を書いてるので JavaScript は専門外 自社サービスの本番環境には Cloudflare Workers を導入済み OpenResty はエンタープライズ大規模環境向けで設計/開発経験あり 雑感 Cloudflare Workers® ざーっと見た感じ Nginx + Lua (OpenResty) のマネージド、さらに Edge で動かしてくれて、スケールも勝手にしてくれるバージョンという認識。実際 shared.dict / redis の代わりが Workers KV が利用できる。 さらにローカル開発環境が充実している、デプロイ後のログ確認も管理画面から簡単に利用できる。 Lua Introducing Cloudflare Workers これを読む

前提 ここで言っているドキュメントは仕様書ではなく、顧客向け製品ドキュメント。 ミドルウェア製品を開発 小さなチーム パッケージ製品とパッケージ製品のクラウド版 そのため顧客に提供するドキュメントが必ず必要 GitHub を利用 自分で開発する場合のフロー 作りたい機能をぼんやりでいいので GitHub Issue に追加する feature ブランチを切る デザインドキュメントをリポジトリの doc/ 以下に書く デザインドキュメントに合わせてコーディングを進めてなんとなく動くところまで作る 動かなくてもいいのでイメージを膨らませるためにコードを書いてみる デザインドキュメントは書き捨て前提で、とにかくメモを書く 製品ドキュメントを書き始めて、一旦書き終える ブランチマージに向けてコーディングを進める 書ける範囲でテストを書く ドキュメントを平行して修正する プルリクエストをだしてレビュ

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 と呼ばれる仕組みの一つ。この方式は今までは主に映像ありでパネルディスカッション的な使い方が主だっだ。それを

この資料には宣伝が含まれます ライセンス 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 作って学ぶも良いが、まずは出てくる単語などの意味を理解できるの

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 配信サーバ設計者 妄想 求人にメディアサーバ