飲み会で「お前、次の転職どうするよ？」的な話をするときはいつも これまでは自分が一番下手くそなバンドメンバーになれる職場を意図的に探していたし、今の職場もその基準で選んだが、そろそろ俺の音楽をやりたい プログラミングそのものをドメインとした仕事をしたい ドキュメントやチュートリアルの整備をしたい。あわよくば今 blog.ojisan.io を書いていること自体が仕事になるようなことをしたい 的なことを言っている（はず、アルコールが入っているので記憶が定かでない）。 で、この最後の 「ドキュメントやチュートリアルの整備をしたい」というのはここ１年くらい言っている気がするのだが、そろそろ本当に動き出そうと思って最近ふわふわ考えていることを書いてみようと思う。そういう仕事をしている人の目に止まってくれると嬉しい。 どうしてドキュメントを書くような仕事をしたいのか いまこういったブログを運営してい

最近ブログのビルドで色々なトラブルがある これまでブログを Markdown で書いて GitHub に Push したら 2分くらいで本番環境に反映されていた。フルビルドでも10分くらいだった気がする。しかし最近は20分以上ビルドに時間がかかったり、そもそもビルドに失敗したりビルドの調子が悪い。 フルビルドに25分かかる たとえば https://github.com/sadnessOjisan/blog.ojisan.io/actions/runs/6105281276 は 24分かかっている。これはlockfile を更新したのでキャッシュを使わずにビルドしている。つまりフルビルドを走らせると 24分かかる。 Gatsby なので日頃は incremental build すればいいと思うかもしれないが、いまビルドキャッシュは 1週間しか残らない。そのため1週間ブログを書くのをサボっ

クソコードを読ませない💩 https://uit.connpass.com/event/291443/ 免責事項 「クソコードという言葉を使うな」と思った人、いると思います。 攻撃的で、解像度も荒くて、建設的でない言葉だと私は思っています。 一方で、目にすることも多い言葉であり、具体例に関してはふわりとした共通認識が持たれているのと、そういったコードに対するダメージコントロールの話なので、便宜上クソコードという言葉を使います。とあるソースコードに対してクソコードと呼ぶのはよくないですが、クソコードという概念そのものについて話すことに対しては有益だと思います。 自己紹介 sadnessOjisan JS/TS, Rust, 最近 Go, PHP マイブーム: 優光というラーメン屋 クソコードとは何か クソコードとは何でしょうか？ 知りません。 インターネットミーム？ https://tog

コンテナでサーバーを動かして、それに対するリクエストをするE2Eテストを GitHub Actions 上で動かすことに苦労したので書く。 成果物repo: https://github.com/sadnessOjisan/e2e-gha お題となるサーバー コンテナに固めるから別に何言語でも良いので、まずはちょっとしたエコーサーバーを書いてみよう。 import Fastify from "fastify"; const fastify = Fastify({ logger: true, }); fastify.get("/", async function handler(req, res) { const q = req.query["q"]; res .status(200) .headers({ "content-type": "application/json", }) .se

「private 関数にはテストを書かない」というのが多数派だと思う。だが昨日、仕事で In-source testing を書いていたらふと private 関数にテストを書きたくなった。そこで、In-source testingができる環境下でもprivate 関数にテストを書くべきかを X で聞いてみたら何か盛り上がっていた。 (In-source Testing: https://vitest.dev/guide/in-source.html) 反応を見る限り、やはり「private 関数にはテストを書かない」の方が主流だった。Kent Beck先生の http://shoulditestprivatemethods.com を紹介するツイートにもそういった反応が寄せられていた。（ぶんぶんさん、教えてくれてありがとうございます。） （このサイト面白すぎますよね・・・） 自分の立場を

axum を始め、tower 系列でサーバーを作っているといくらでも例が出てきそうな話ではあるが、「ちょっと君、明日からRust でトレーシングしたまえ」って言われた時に欲しいまとまった情報は意外とない気がしたので書く。 基本的に tower 系列や、tower に準ずる様な Service トレイトを持つ様なFWであれば同じ様な話であり、tracing crate 自体は Agnostic なものなので、ここでは axum を例にあげて書く。 axum と tracing subscriber まず、簡単に HTML を返すサーバーを作る。 use axum::{response::Html, Router}; use std::net::SocketAddr; #[tokio::main] async fn main() { let app = Router::new().route(

Rust でWebサーバーを書く時の技術選定をするときに調べていると hyper に必ず出会うと思う。これは黎明期から存在しているライブラリで、Webサーバーにしては珍しく version 1 まで到達している老舗だ(1に到達してたら安心って考え方が正しいかはさておき...)。このライブラリは actix-web や axum のような他のライブラリとは毛色が違い、かなり primitive だ。そのため axum のベースに使われてもいて、hyper はそのまま使わないライブラリなのかもしれない。 サンプルコードから存在意義がわかりにくい さて、そんな hyper だが公式の example はこのようになっている。 #[tokio::main] async fn main() -> Result<(), Box<dyn std::error::Error + Send + Sync>>

ホストマシンで開発できないものを、ホストマシンのフォルダを同期させてコンテナ内で開発する2023-08-19 KLab という会社のインターン課題を夏休み中にやると「詳解TCP/IP Vol.2」を貰えるらしい。 https://twitter.com/pandax381/status/1688414447466139649 この本はプロトコルスタックを自作するための教科書として有名なようだ。実は自分は自作プロトコルスタックには興味があり、 Webサーバーアーキテクチャ進化論2023を書いた時に 「SYN Queue と Accept Queue に積まれる実体って何？ Linux カーネル読むしかねぇ！うぉ〜挫折〜〜〜〜〜〜！」となっており、この辺は自分の中で宿題となっている。 自分は最近までこの本を知らなかったのだが、 Encraft #2 サーバーとクライアントを結ぶ技術 に登壇した

先週、A Tour of Go やってみた TIL というブログを書いてみた通り、Go言語を始めた。 で、ちまちま勉強をしていたのだが、つい最近たまたま ISUCON の過去問をやる機会があって Go のスコアを見たら初期値ですら、チューニング済みの他の言語のスコアを超えていて、絶対に習得するぞの気持ちにさせられた。 ちなみに私はどう言うわけかフロントエンドのソースコードをビルドしたら vite が走ってファイルハッシュが全部変わって、ベンチマークからアクセスできなくなって０点でした。対戦ありがとうございました。 なにはともあれ、本番は絶対にGoでやるぞの気持ちを新たに Go の習得に励んでいた。前のブログでは、文法が分かったから HTTPサーバー DB Connection / Migration 境界値チェックや型推論 テスト スキーマ駆動開発 コンテナデプロイ あたりをやってみたいと

OGPは白川郷だ。石川県に住んでいたときよく白山白川郷ホワイトロードをドライブして遊びに行っていた。早くに閉まるから帰りは富山側に出て日本海側で美味しい魚を食べて石川に戻っていた。あのときは楽しかったなぁ。 今年、ISUCONに挑戦するつもりの夏休みの過ごし方をしているので Go の勉強を始めた。自分には既にNode.js とRustが Main/Sub weaponになっているので、別にISUCON向けに勉強しなくていいと思っていたが、どうも上位勢は軒並みGoっていうのと、彼らの解法ブログを読み解くためにはGoをやっていた方がよさそうだったのでGoの勉強を始めた。 ちなみにGoは生涯で3行しか書いたことがない(うち2行はHTMLテンプレート)生粋の素人だ。いや正確には遥か昔に勉強に挑戦したことがあって本を一冊買った覚えはあるが、A Tour of Go の冒頭で「ほぇ〜大文字でexpor

この前ポジショントークしたらそれなりに反響があったので書いてみる。 これまでの人生を振り返ると毎年ラジオや電話や配信サービスを作っている気がするし、なんかそういう仕事が回ってくることが多い気がする。 最近自分なりに答えが出たかなと思ったことがあるので言語化してみようと思う。 OGP は Flux ぽい画像だ。 注意・免責事項 ここにあるソースコードは不完全です。これは私が元々手元で実験していたボイラープレートであるとはいえ、いろんな仕事で培ったノウハウ的なものも含まれているので、念には念を入れて意図的に要件が透けそうな箇所は削除しています。 その結果元々のボイラープレートと乖離してしまい、動作しないコードになっています。ただ概念を伝えるには十分なコードになっているはずなので、脳内補完してください。質問は Twitter のメンション、もしくは Issue でのみ受け付けます。 (完全版を書

6/13 に アウトプットからはじまるエンジニアのキャリア論 〜IDE さんと katei さんの場合〜 というイベントに出ます。自分のブログを紹介する回なのですが、最近色々雑多に描きすぎたせいでまとまりがなくなってしまい、紹介しにくいです。はてなブックマークの検索結果 が気合を入れて書いたものリストとしては機能もしているのですが、完全ではないのとふざけた記事も多いので、せめて自分が読んで欲しいなと思うものをまとめて置くページを作りました。このイベントだけに限らず最近自己紹介としてブログを出すことがあるので、自分のアイデンティティにしたいようなものはここにまとめていきます。定期的に更新していきます。 2023/06/13 更新 ちなみにブログにお気に入り記事だけをまとめる仕組みはあったりもする。（昔あった） 選出基準 自分はこういうことに関心がありますとアピールしたいもの 頑張って書いたも

先日 フロントエンドの Monorepo をやめてリポジトリ分割したワケ というブログがバズっていた。そのおかげか、Twitter でもモノレポに関する言及がちょこちょこあった。一家言あるドメインなので書きたい。ただの一家言(a.k.a お気持ち)なのでぜひ皆さんの意見も聞いてみたい。 tl;dr 別に自分はどっち派とかではなく、どっちも選ぶ。強いて言うならリポジトリ分割派で、依存更新がしんどくなったら monorepo 派。 免責 モノレポに対する一家言を書きたいだけであって、内容自体はフロントエンドの Monorepo をやめてリポジトリ分割したワケ と全く関係なく、そのブログで述べられている施策については何も言及しません。ただ一つ言及するとしたら肉の部位がコードネームに採用されているのは良いと思いました。🍖🍖🍖 モノレポにしたくなる状態の前提にあるもの 前提は元記事と同じように

自分のブログを辿ってみたところ Rust を 2020 年には書いているようだが、初心者を名乗らせていただく。なぜならブログのネタにする以外で Rust 書いたことないし、これも調べながら書いているからだ。もっと練習したい、どこかに Rust を書ける機会ないかな〜ﾁﾗｯﾁﾗｯ 👀 なぜありふれていそうな題材で書くか 題材はありふれているし解説もたくさんあるが、それらを読んで理解できるのか？という疑問がある。というのも、所有権、借用、ライフタイム自体についての説明は至る所で見るが、これらが無いと何が大変なのか、導入することで何が解決されるかがよく分からないと思うからだ。勿論、そのような点まで解説してくれているものもたくさんあるが、正直なところ Not for Me だった。何が Not for Me だったかというと、C++ の知識やコンピュータサイエンスの知識があることが前提になってい

簡単な開発をしたいときにちょっとだけ Cookie を使いたいときがあると思う。私は日頃から Web 標準な何かをするときはライブラリを使うことに抵抗があり、Cookie 周りの操作もライブラリを使わずにやりたい。が、そんなちょっとカッコ良い発言をしている裏で、私はこっそり「Cookie 付けるのってどうするんだっけ？」「Cookie のフォーマットってどんなんだっけ？」といつも Google で調べている。もちろん Set-Cookie くらいは覚えているが、「順番は？どういうデリミタで？どういうパーサーが必要で？」というのは結構忘れているし、意外と皆さんもすっとは出てこないのではないだろうか。あ、私だけですか、すみません。。。と、私は毎回調べているが、毎回調べるのはめんどくさいのでメモを書いておこうと思う。 OGP は クッキーに見せかけた空気だ。「こいつ最近 OGP でふざけてるし、

GW なんも予定がなくてブログ書くかソシャゲやるか昼から酒飲むしかやることがないです。だから予定があったら使っていたであろうお金でソシャゲに課金したらめちゃくちゃ強くなりました。やったー。友達にはドン引きされましたが、GW に予定がある人よりかは節約できていると思います。そんなソシャゲもやることなくなって暇なので酒飲みながらブログを書きます。今日は WebRTC です。 免責 筆者は RFC を読んでいません。これは「そもそも WebRTC それ自体 の RFC なんてものは存在しないもんね〜」という意味でなく、ICE や SDP の RFC すら読んでいないという意味です。そのため WebRTC そのものの解説として読むと良くない表現が含まれるかもしれません。ただし自分が WebRTC でカメラ映像を送る実装を動作させ、そのコードの解説という点では間違ったことは書いていないはずです。動作

encraft #2 までの間、スキーマスキーマした話をたくさん書きたい。好き好きスキーマと言いたいところだが、zod に対しては人気に対して逆張り意見的なのを持っているのでそれを書いていきたい。 OGP は Ajv ユーザーと焼肉をしたときの画像だ。網もスキーマが大事ってことですね。 独自性の高いスキーマを使うのは危険だと思っている zod は便利だ。とても流行っている。その結果 yup や joi で作られたものが負債扱いされているような気までする。だが思い出してほしいのだが、yup だって出てきた当初はとても便利なものとして人気があった気がする。特に Formik と組み合わせるのは一種のパターンになっていたような気もする。しかし最近はそれらが zod に取って代わられてしまったと思っている。エコシステムの選択や対応を見ていると zod 一強だ。 (ちなみに npm trends で

encraft #2 までの間、スキーマスキーマした話をたくさん書きたい。 OGP は昨日食べた火鍋だ。Fire 感があるのでこれを使おうと思った。（Firebase の記事を書く時は炎の画像を使っていたのに、炎系のフリー素材をたくさん使いすぎて似た画像ばかりになりストックがなくなったことは秘密） firestore は withConverter で validation できる なんか似たようなブログを書いた気がしていたのだが、どうやら firestore の入出力に型をつける で withConverter を紹介していた。なので詳しくはそれを見てほしい。 export const sitemapConverter: FirestoreDataConverter<SitemapSchema> = { toFirestore(sitemapDto: SitemapSchema): Do

宣伝 4/25 に Encraft #2 サーバーとクライアントを結ぶ技術 というイベントで JSON Schema について喋る。いま現在進行形で IDL として JSON Schema, GraphQL, Protocol Buffer, zod, joi を使っているのでそれらを食べ比べる発表をするつもりだ(明らかに JS 上でしか動かないものを IDL と呼んでいいか不安になってきた)。そしてスキーマ駆動開発(code first なアプローチをスキーマ駆動と呼んでいいのか不安になってきた)を推進する上で、その中では大人の事情に柔軟に一番対応できるのは JSON Schema だという悲しい話をする。だが、私はこの JSON Schema を書き過ぎたせいで話したいことが大量にあり、JSON Schema の話だけで 1 時間超えそうな勢いなことに気づいた（発表時間は 20 分）。