binary-piのブックマーク (6,405)

  • 優秀なエンジニアが書くDesign Docは何が違うのか? - pospomeのプログラミング日記

    株式会社カミナシで VPoE を務めている pospome です。 (´・ω・`) 自分はここ数年いろんなエンジニアが書いたDesign Docをレビューする機会があるんですけど、その中で「優秀なエンジニアであれば、ここは押さえて欲しい」「ここでエンジニアとしてのスキルが分かる」というポイントがありまして、今回はそれを言語化してみようと思います(同じ話を社内でしたので、せっかくなら記事にしようかなと・・・)。 もちろん、Design Docだけでエンジニアの能力が決まるわけではありません。ただ、設計時にどこまで選択肢を広げ、リスクを深掘りし、何を今決めるべきか判断できているかは、Design Docによく表れます。 Design Docのフォーマットは組織によっていろいろあると思いますが、記事は特定のフォーマットに依存しない形で書いています。 Design Docはなぜ重要なのか? De

    優秀なエンジニアが書くDesign Docは何が違うのか? - pospomeのプログラミング日記
  • 最近見てる技術コミュニティについて

    「みんなAIの話ばかりしてて面白くない」とよく聞くようになった。 実際TwitterでLLMの話を聞かないことはないし、僕自身もよくするようになった。 個人的には面白いおもちゃの末席にLLMが加わった感じがして面白くはあるのだけど、いかんせん技術サイトの話題がAI一色になると胸焼けしてしまう。 そんな感じなので最近はにゃーんとかにゃーーんとかの代わりにこういうサイトを見て己の知的好奇心を満足させてたりする。 なおこの記事で紹介するサイトは全て海外のコミュニティです。 Lobsters 個人的にめちゃくちゃ良いと思っている。 この手のサイトはHackerNewsとかがあると思うのだけど、あっちは人口が多すぎてハッキングに関係のない話が多く混じっててノイズになってると感じている。Hackerとは… Lobstersはハッキングに特化したサイトなのでノイズが少ないし、扱っている内容もギークな内容

    最近見てる技術コミュニティについて
  • 理系にも分かる人権――「最適化」してはいけないものは何か:「制約条件としての人権」論の系譜と数理|Reading Monkey

    要旨「人権は科学的に証明できない。ゆえに虚構であり、守る根拠がない」という懐疑論に対し、稿は二段階で応答する。第一に、この懐疑論が依拠する推論――「物理法則から導出できない」から「無根拠である」への移行――は、事実と規範の論理的区別(ヒュームの法則)を懐疑論者自身の立場にも等しく適用すれば自壊することを示す。第二に、人権を「社会的目的関数の最大化に先立って課される制約条件(constraint)」として定式化し、この定式化が(a)規範倫理学における権利基底的理論(ノージックの側面制約、ドゥオーキンの切り札論)、(b)社会的選択理論の不可能性定理(センのリベラル・パラドックス)、(c)立憲経済学(ブキャナン)、(d)AIセーフティにおける制約付き最適化(CMDP)という、相互に独立に発展した複数の研究伝統において繰り返し到達されてきた構造であることを確認する。そのうえで、制約条件アプローチ

    理系にも分かる人権――「最適化」してはいけないものは何か:「制約条件としての人権」論の系譜と数理|Reading Monkey
  • How to keep thinking

    Imagine you’re the guest on some kind of frenetic, software-engineering-themed game show. The host is constantly flipping over new cards with questions that you have to answer as fast as possible: Is this adjustment to the database schema right? Do these bits of data look plausible? Do these five paragraphs of text describe an actual series of manual tests that took place? Does this suggested arch

    How to keep thinking
  • 「次の単語を当てているだけ」のAIが、なぜ数学の証明までできるのか——LLMの創発研究の現在地を調べてみた|ふちゃぎ

    「次の単語を当てているだけ」のAIが、なぜ数学の証明までできるのか——LLMの創発研究の現在地を調べてみた 「LLMは、次に来る単語を確率的に予測しているだけ」——TLに流れていたこの説明は正しい。GPTもClaudeも、事前学習でやっていることは突き詰めれば次トークンの予測であり、目的関数にそれ以上の何かは書かれていない。 一方で、同じモデルが動くコードを書き、難しい数学の証明を組み立てる。これも正しい。 両方とも真、というのが据わりが悪い。単語当ての延長で証明まで届くなら、「予測しているだけ」という言い方のどこかに、大事な何かが折り畳まれているはずだ。機械学習の世界ではこの飛躍に「創発(emergent abilities)」という名前がついていて、議論が始まってからもう4年になる。これだけ騒がれたのだから、原理はとっくに解明されているに違いない。そう思って論文を漁り始めたのだが、蓋を

    「次の単語を当てているだけ」のAIが、なぜ数学の証明までできるのか——LLMの創発研究の現在地を調べてみた|ふちゃぎ
  • 一流になれないなら、境界に立てばいい|すてぃお

    僕は飲店を経営していました。 ソフトウェアエンジニアばかりが集まる場所で「飲店をやってました」と話をすると、珍しがられます。 でも、飲店は日に何十万店もあります。飲店を経営している人も、それだけいるということです。飲店経営者の集まりに行けば、店をやっていたというだけで珍しがられることはありません。普通なんです。 逆にソフトウェアエンジニア経験があることが珍しがられます。 ソフトウェアエンジニアの中にいるか、飲店経営者の中にいるか。違うのは周りだけです。それなのに、同じ経験が珍しくなったり、普通になったりします。 珍しい人がいるのではなく、珍しく見える場所がある飲の人と話していると、原価や人件費、予約、仕入れ、日々のオペレーションの話は当たり前に通じます。僕より現場に詳しい人はいくらでもいます。飲店経営の経験だけを切り取れば、僕は特別な人ではありません。 ところが、そこにエ

    一流になれないなら、境界に立てばいい|すてぃお
  • やる夫で学ぶディジタル信号処理 (PDF版) 暫定配布所 - swk's log はてな別館

    「やる夫で学ぶディジタル信号処理」という講義資料を異動前の研究室のサイトにを置きっぱなしにさせて頂いているのですが,諸事情でアクセス不可の状態が続いています.取り急ぎPDF版だけこちらからアクセス可能にしておきます.

    やる夫で学ぶディジタル信号処理 (PDF版) 暫定配布所 - swk's log はてな別館
  • Claude がテキストに電子透かしを入れ始めたので、LLM ウォーターマーキングの仕組みを調べた

    この例では、確率2位の dog が、たまたま高い乱数 r = 0.95 を引いたおかげで勝っています。とはいえ p_i が大きいほど指数 1/p_i が小さく r_i^{1/p_i} は 1 に近づくので、基的には確率の高い候補ほど勝ちやすい競争です。そして、この選び方でトークン i が勝つ確率は元の p_i に厳密に一致することが、Gumbel-Max トリックとして知られる古典的な性質から従います。乱数でくじ引きする代わりに「乱数を使った決定的な最大値選び」をしているだけなので、外から観察できる振る舞いは通常のサンプリングと区別がつかないわけです。 では、分布が同じなのにどうやって検出するのでしょうか。着眼点は、透かし入りテキストの各単語が「高い r_i を引いたから勝った」勝者の集まりだという点です。 人間が書いた文章に同じ計算を適用すると、各単語に割り当たる r は書き手と無関係

    Claude がテキストに電子透かしを入れ始めたので、LLM ウォーターマーキングの仕組みを調べた
  • 【RAG】話題の米国AIベンチャーで実践される「社内ナレッジ」管理

    記事では、今をときめくAI半導体ベンチャーである「Cerebras」による、「社内ナレッジ検索」の仕組みについて、解説します。 株式会社ナレッジセンスは、社内データ検索技術をエンタープライズ企業向けに提供しているスタートアップです。 この記事は何 この記事は、Cerebras社が公開した技術ブログ「How We Built Our Knowledge Base」[1]について、日語で簡単にまとめたものです。 題 ざっくりサマリー Cerebrasは、NVIDIA対抗の巨大AIチップで有名な米国のAIベンチャーです。同社は2026年7月、自社の「ナレッジ基盤」をどう構築したか、についての記事を公開しました。 社内のナレッジマネジメントの話となると、「理想論」の話はたくさん転がっていますが、実際に運用レベルに乗っているという話は、まだまだ、公開事例は多くありません。 今回Cerebras

    【RAG】話題の米国AIベンチャーで実践される「社内ナレッジ」管理
  • 地下アイドルという海から「回遊魚」が消えた日──音楽好きはどこへ行ったのか|jubio_09

    2010年代前半から中盤にかけての新宿LOFTや下北沢SHELTER、あるいは渋谷WWWや恵比寿LIQUIDROOMの光景を思い出すと、今の地下アイドル現場とは明らかに違う「匂い」がありました。 フロアに溢れ返り、開演を今か今かと待ちわびていたのは、いわゆるステレオタイプな「アイドルオタク」だけではありません。サブカルチャーをこじらせたようなバンドマン崩れ、ヴィレッジヴァンガードの黄色い袋を提げたサブカルボーイ、そしてディスクユニオンのショッパーを無造作に足元に置くような、筋金入りの「音楽ディガー(発掘者)」たちが、そこに密集していたのです。 BiSが非常階段とのコラボユニット「BiS階段」で豚の頭や濡れた下着をフロアに投げ込み、コショージメグミのダイブでフロアが文字通りカオスに陥っていたあの時代。BELLRING少女ハートからThere There Theresへと続く、サイケデリックで

    地下アイドルという海から「回遊魚」が消えた日──音楽好きはどこへ行ったのか|jubio_09
  • 宮本佳林『アイドルがAIと配信のシステムを全部作った話』

    コードが書けないアイドルが、AIと一緒に10時間配信のシステムを全部作った話自分がシステムをしっかり理解するためにも、 どんなことをやったのか残しておく為にも ClaudeとChatGPTと一緒に (間違ってるところがあったらいけないのでね!) どんな風に制作して行ったのか ブログに書いて行くことにしました。 配信アーカイブはこちら 2026年7月31日、 5thシングル「HANAKIN/シャニカマー」 の発売週に、 朝8時から夜18時まで、 10時間のYouTube生配信をやりました。 企画は 「みんなと協力して家にあるものでMV再現配信」。 視聴者のみなさんがCDを買って ハッシュタグで呟くたびに、 衣装やグッズが解禁されていく参加型の配信です。 今回はスケジュール的に 発売週の土日にイベントが出来なかったのもあり、 発売週金曜日なにか出来ないか? ということで考えた企画でした。 ゲー

    宮本佳林『アイドルがAIと配信のシステムを全部作った話』
  • コードベースのナレッジ化なら、LLM Wikiで十分かもしれない - Qiita

    前書き コーディングエージェントに改修を依頼するたびに、「この修正はどこまで影響するんだろう」と、同じ調査を何度もやり直させた経験はないでしょうか 社内の仕様書や設計ドキュメントをベクトルDBに入れて、エージェントに検索させる構成を組んでいる方も多いと思います。 ドキュメントの中身自体は正しく引けるものの、同じ質問をするたびにベクトル検索の結果から答えを組み立て直すため、聞くたびに微妙に言い回しが変わったり、検索コストがじわじわ積み上がったりする——そんな感覚に心当たりはないでしょうか。 この課題を解決する考え方として、「 LLM Wiki 」というアプローチがあります。 記事では、まず従来の検索型ツールが抱える限界を振り返り、次に「LLM Wiki」という考え方を整理し、最後に、OpenWikiという「LLM Wiki」に似た仕組みを持つライブラリーを動かすところまでを紹介します。 エ

  • 人間の目はかわらない、だからJPEGは30年もつ

    2026/07/25 大吉祥寺.pm 2026

    人間の目はかわらない、だからJPEGは30年もつ
  • ターミナルを自作したら、1日のコミット数が500を超えて、生産性がバグった話

    僕は長いこと、ターミナルの中で暮らしています。エディタは emacs、VS Code や GUI 系のツールはどうにも手に馴染まない。Web 上の開発環境も、あの「ちょっとした不便」が積もって結局使わなくなる。要するに、ターミナルに慣れ親しみすぎて、GUI のボタンがどこにあるのか探せない人間です。 そんな僕が、勢いで自分専用のターミナルを作ったら、GitHub のコミットが毎日 500 を超えるようになりました。一度きりの当たり日ではなく、来る日も来る日も、です。生産性がバグりました。 毎日 500 コミット超え。草が真緑になった 先に言い訳をしておくと、「コミット数は生産性の指標じゃない」というツッコミはまったくその通りです。細かくコミットする癖もあります。でも、数字そのものより、その数字が出てしまうくらい "詰まらなくなった" という体感の変化の話として読んでもらえると嬉しいです。順

    ターミナルを自作したら、1日のコミット数が500を超えて、生産性がバグった話
  • エンジニアの成果、結局どう測ればいいのか

    行数や PR 数が「嘘の指標」なのではありません。連鎖の右端にある 途中経過 なのです。 途中経過を最終成果のように扱った瞬間に、おかしなことが起こり始めます 。 測った瞬間に指標は壊れる おかしなことが起こる理由には、名前がついています。グッドハートの法則 です。 イギリスの経済学者が指摘した現象で、後に人類学者の論文に登場する簡潔な言い換えで広く知られるようになりました。 測定が目標になると、それは良い測定ではなくなる PR 数を評価に使えば、PR は不自然に細切れになります。行数なら、冗長なコードやコピペが増えます。ベロシティを目標にすれば、ストーリーポイントの見積もりが膨らみます。 誰も悪意はなくても、評価される数字に行動が最適化されるのは人間として自然なこと です。 社会科学には似た指摘としてキャンベルの法則もあります。定量的な指標が意思決定に使われるほど、その指標は腐敗圧力にさ

    エンジニアの成果、結局どう測ればいいのか
  • そうだ、時計作ろう - 重力に縋るな

    みなさん時間測ってますか? 僕はパスタ茹でる時とかに測ります。 また、時間の間隔だけでなく、正確な時刻を知ったり、正確な時刻に合わせて何かアクションをしたい時があります。 たとえば JST 2026年06月21日22時23分24秒きっかりに数十 ns の精度でパスタを茹で始めたい時などがあると思います。 そんな時に便利なのが GNSS(Global Navigation Satellite System)です。 GPS(Global Positioning System)とも呼ばれがちですが、GPS は正確にはアメリカのやつのことだけを指します。 そのため、日の準天頂衛星システム QZSS(Quasi-Zenith Satellite System)や、ヨーロッパの Gallileo、中国の BeiDou、ロシアの GLONASS といった測位衛星システムの総称が GNSS です。 qz

    そうだ、時計作ろう - 重力に縋るな
  • スタートアップをとりまく思想 - 🐴 (馬)

    追記:よく読まれたので Substack のほうで音声版も公開しました。 [音声版] スタートアップをとりまく思想 - 第1部 シリコンバレー思想史 なぜいま、スタートアップと思想なのか 日で「シリコンバレー」と聞いて思い浮かぶのは、GAFAのような巨大テック企業か、「失敗を恐れず挑戦する起業家精神」といったビジネス書的なイメージではないでしょうか。 しかし、いまアメリカのテック業界で起きていること、そしてシリコンバレーが世界から注目されている理由は、そうしたビジネスの枠を超えて、政治や思想の領域にまで及んでいます。 たとえば、いまシリコンバレーの周辺では、次のようなことが起きています。 データ分析企業が、軍や諜報機関の中枢に入り込む 著名な投資家たちが「民主主義よりCEOモデルによる統治のほうが優れている」と公然と語る AI企業の経営者たちが「人類絶滅のリスク」と「人類史上最大の豊かさ

    スタートアップをとりまく思想 - 🐴 (馬)
  • 伝わる発信のつくりかた

    2026/06/19のZennfesでの発表「伝わる発信のつくりかた」のスライドです。

    伝わる発信のつくりかた
  • Rustでクロスプラットフォームアプリ開発 | CHANTO Inc.

    Takeshi TsukamotoCHANTO株式会社 代表取締役 モバイルアプリ、Web、サーバー、クラウドなんでもやります。プログラミングが好き。 Rustはパフォーマンス、安全性、エコシステムの充実と三拍子揃ったとてもいい言語です。 自作ツールの開発などにこれまで積極的にRustを使ってきて、その書きやすさと一度コンパイルが通ってしまえば安全なコードがかけているという安心感は他の言語では得難いものだと感じています。 ところで、私は仕事で10年以上モバイルアプリ開発をしています。Android/iOSのネイティブアプリ開発、Flutter/React Nativeを使ったクロスプラットフォームアプリの開発など様々やっていますが、Rustでアプリ開発ができたら自分の理想の開発ができるのではないかと思いました。 Whiskerの紹介# そこで開発したのがWhiskerです。 わかりやすく一

    Rustでクロスプラットフォームアプリ開発 | CHANTO Inc.
  • 2026年6月版 開発中の機能を小分けにして本番環境にどんどん出すためには - hitode909の日記

    2018年にこんな記事を書いた。 ビッグバンマージではなく、少しずつ書いたコードをマージしていき、番環境を壊さずにリリースする、という話。 チーム内では浸透していて、コードベースにはフィーチャーフラグ機能やデバッグ機能が充実している。 今、コーディングAIを使うと、どのような進め方ができるか、どのような進め方が望ましいと考えているかも書いておく。 blog.sushi.money 2018年版フローのイマイチな点 まず、機能の全貌や設計が分かっていればいいけど、Pull Requestが小分けになって出てくることで、全容がわからないというイマイチさがある。 オフィスに集まって開発していた時代では、ホワイトボードにお絵かきして、これをつくるぞ、みたいな儀式があったけど、リモートワークが進んでからは、お絵描きして認識を揃えるというのが難しくなってしまった。 ということもあって、完成形のイメー

    2026年6月版 開発中の機能を小分けにして本番環境にどんどん出すためには - hitode909の日記