圏とは？プログラマに人気と噂の圏について話します。 プログラマ向け圏論入門 1
圏とはなにか？について話しました。 プログラミングにおける圏の話は次回です。今回は純粋に「圏」のお話です。 02:49 数学における圏 06:03 圏とプログラミングの歴史 10:02 圏とは 37:02 具体例、練習 58:13 まとめ #圏 #圏論 #プログラマ 🦜 X フォローお願いします！ ムー https://x.com/moo_is_gone zaru https://x.com/zaru 👨💻 ムーザルについて ムーザルは、ムーとzaru（ざる）の現役プログラマな二人のコンビです。 技術や物作りが好きで、楽しんで開発ができるような動画を投稿しています。 チャンネル登録やグッドボタンで応援してくれると嬉しいです。 「この技術の解説動画が見たい！」などのリクエストコメントもお待ちしております！
Matz の Ruby AOT コンパイラ Spinel を試してみました
RubyKaigi 2026 に参加して、Matz のキーノートで Spinel の発表を聞きました。Spinel は Ruby の AOT コンパイラで、Ruby のコードを読み、C のコードを生成し、最後は native binary として実行できる形にします。Ruby を書いている人間としては、「Ruby の AOT コンパイラ」という言葉だけでテンションが上がります。 Ruby はかなり動的な言語でもあります。メソッド呼び出し、クラスの再オープン、メタプログラミング、eval、実行時に変わるオブジェクトの形。普通に考えると、AOT コンパイルとは相性が悪そうに見えます。 それでも Spinel は、Ruby を Prism で parse し、AST をもとに型推論し、C のコードを生成して native binary にします。発表を聞いていて、これは触ってみたいなと思いました
200万行のテーブルにDDLを打つ前に知りたかったこと
クエリが遅くなった。直そう。ここから問題が始まる プロジェクト管理SaaSを1年ほど運用すると、Issueテーブルが200万行、変更ログテーブルが2000万行を超えてくる。ソフトデリートを採用していれば物理削除されないので、行数は増える一方だ。 最初の兆候はユーザーからの報告だった。「Issue一覧の読み込みが遅くて、フィルターを切り替えるたびに5秒くらい待たされるんですが」。スロークエリログを見ると、フィルター付きのIssue一覧クエリがp95で3秒を超えている。インデックスを追加すれば改善する。スキーマ変更も1つ控えていた。どちらもやること自体は明確だった。 問題は「200万行のテーブルにDDLを打つ」という行為そのものにあった。膨れ上がったテーブルに対するスキーマ変更は、パフォーマンスを改善するための作業が、新たな障害を引き起こす可能性を持っている。治療のための手術が患者を殺しかねな
TSRX | TypeScript Language Extension for Declarative UI
TSRX is a TypeScript language extension for building declarative UIs in an agentic era. TSRX (TypeScript Render Extensions) is a way to write UI component code that stays readable and co-located. Structure, styling, and control flow live together, and the result stays fully backwards compatible with TypeScript. 1 export component Greeting({ name }: { name?: string }) { 2 <div class="card"> 3 if (n
アルゴリズムではない
アルゴリズムという言葉がこれほど一般的に使われるようになったのは、いつ頃からだろう。私は情報学専攻の学生だったので、本来の意味でのアルゴリズムについて学んだけれど、今ではもっと広い意味でアルゴリズムという言葉が使われるようになった。 たとえばFacebookやXのフィードとか、YouTubeのリコメンデーションとか、なんだかよく分からないルールでコンテンツが表示される仕組みがある。そのルールのことが昨今ではアルゴリズムと呼ばれている。そして、アルゴリズムは私達にとって最適化されたものであり、社会にとって最善の仕組みであるかのように喧伝されている。 テック企業が自分たちのアルゴリズムについて語る時、私にはどこか責任転嫁のように聞こえる。自分たちがやったんじゃありません、アルゴリズムがやったことです、というような。Xが扇情的なコンテンツを流すのも、YouTubeが陰謀論を広めるのも、それが私達
ユビキタス言語 - kawasima
DDD (Domain-Driven Design) における「ユビキタス言語 (Ubiquitous Language)」は、なぜ glossary や terminology や vocabulary ではなく "language" と呼ばれるのか。ここでの答えは、ユビキタス言語の設計とはドメインモデリングそのものだから、というものである。言語を設計するとは、語彙だけでなく、データの構造と振る舞いを文法として決めることを指す。 同じ問いを扱った先行論として、laiso 2024「ユビキタス言語は用語ではなく言語」 は Vernon 2016 を根拠に「UL は名詞だけでなく動詞・副詞・文法を含む」と述べ、Turtle Grammar 2023 "Language Games: Wittgenstein and DDD" は Wittgenstein の言語ゲームと Bounded Co
GitHub - cathrynlavery/diagram-design: Thirteen editorial diagram types for Claude Code. Self-contained HTML + SVG. No shadows, no Mermaid-slop.
Editorial diagrams your designer won't hate. 14 types. One Claude Code skill. Your brand in 60 seconds — the skill reads your website and maps colors + fonts to every diagram. No Figma. No generic rounded boxes. No 30-minute color-picking sessions. I write at littlemight.com (and run BestSelf.co on the side). Every time I needed a diagram — an architecture sketch, a flowchart, a pyramid of what ma
Auth0から内製認証基盤へ移行を決めた背景と移行方法 - enechain Tech Blog
はじめに なぜ内製化を選んだのか プラットフォーマーとしての説明責任 制約の解消とコスト削減 認証基盤を内製で持つリスク 移行の設計 並行稼働による段階的移行 使用するデータソースの統一（SSoT） 認証基盤の内製化、並行稼働をしてみて 認証基盤全体がコントローラブルになった 内製化で得られた価値 並行稼働について 発生した課題 まとめ はじめに こんにちは、ソフトウェアエンジニアの大山です。 enechainではこれまでユーザー認証基盤としてAuth0を利用してきましたが、事業の成長に伴い自社開発の認証基盤（eAuth）へ移行しました。 本記事では、Auth0から内製へ移行する意思決定の背景、移行の設計について紹介します。 なぜ内製化を選んだのか enechainでは元々Auth0を認証基盤として採用していました。 少人数のチームでサービスを立ち上げるフェーズでは認証認可の開発運用コスト
サーバーサイドTypeScriptの不都合な真実、あとGoお前もダメだ｜Franny
GCアーキテクチャの序列を誰も語らない理由 ── JVM・Go・V8をめぐる会話フラニー:「ソフィア様、ひとつ教えてください」 フラニーが珍しく険しい顔で、ノートパソコンの画面を差し出してきた。そこには技術記事のブラウザタブがいくつも並んでいて、どれも「Go と Java のパフォーマンス比較」とか「Node.js の高速な GC」とか、そんなタイトルが踊っている。 ソフィア:「なんだい、フラニー」 フラニー:「世の中のエンジニアの大半が、Go や Node.js の GC は JVM より優れていると信じているみたいなんです。これ、本当ですか？」 ソフィアはしばらく画面を眺めて、それから小さく首を振った。 ソフィア:「違うよ」 フラニー:「即答ですね」 ソフィア:「だって事実だからね。GCアーキテクチャの洗練度で言えば、一番進んでるのは JVM の ZGC と Shenandoah。次に
deleted_atにインデックスを雑に貼ったら本番DBが死んだ
RDSが朝のピーク時間帯にI/Oスパイクで応答不能になりました。前日夜にリリースしたdeleted_atへの単独インデックスが原因です。stagingのEXPLAINでは複合インデックスが正しく選択されていたので、レビューでは検出できていません。 根っこにあるのはMySQL 8.0 innodb_stats_methodのデフォルト値nulls_equalと、IS NULLに対するコスト計算の噛み合わせです。8.0系で現在も未修正のバグに類する挙動で、NULL多数カラムへの単独インデックスがトリガーになります。 テーブルとクエリ 問題が起きたのはチケット管理SaaSのticketsテーブルです。ソフトデリートでdeleted_atを持つよくある設計です。 CREATE TABLE tickets ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, w
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Last Software Engineer
Scribe v2 リアルタイム音声認識 - 150ms低遅延API
GitHub - fallow-rs/fallow: Codebase intelligence for TypeScript and JavaScript. Free static layer: unused code, duplication, circular deps, complexity hotspots, architecture boundaries. Optional paid runtime layer: hot-path review and cold-path deletion e
My Framer Site
米スペースX、9.6兆円で「Cursor」買収権 プログラミングAI強化 - 日本経済新聞
fate
Inertia.js - The Modern Monolith
Recordly - Open-source app for incredible screen recordings.
2026年、知っておくべき最新 サーバレスTips10選/serverless-10-tips
古典ドメインモデルパターンの解脱
