はてなブックマーク

FlexboxよりGridを使う理由 先日、Grid First, Flex Thirdという記事を読んだ。要約すると「レイアウトを行う際は grid > block > flex の順で使うべき」という主張がなされている。 並びのレイアウトはFlexbox、格子状に区切ってどこに何を配置するかはGridを使う派だったのだが、Gridの有用性を再認識した。 Flexboxの使いづらいところ Flexboxで要素を並べると子要素の幅を指定しても圧縮されてしまう。 <section class="layout"> <div class="item"></div> <div class="item"></div> ... </section> .layout { display: flex; overflow-x: auto; } .item { width: 200px; } 子要素の幅を維持

MCPサーバをつくって学ぶ 最近、AIアシスタントの文脈で「MCP」や「MCPサーバー」という用語を聞くようになった。 MCP（Model Cotext Protocol）とは？ Model Context Protocolとは、AIとアプリケーションとの間で情報を効率的にやり取りするためのプロトコル。 簡単に説明すると、AIが自分の作ったアプリケーションを操作できるように、データを提供したり、機能を公開したりして、扱いやすくするための方法を定義したもの（プロトコル）。 MCPを使うことで、AIがアプリケーションのコンテキストを理解できるようになる。 たとえば、いままで手動でデータを貼り付けたり、プロンプトを書いてコンテキストを補っていたりしたものが、AIが直接アプリケーションから取得できるようになる。 MCPサーバー 主に3つの機能を提供する。 Resources … クライアントが読み

フロントエンドエンジニアのためのHaskell入門 JavaScriptのなんちゃって関数型プログラミングではなく、純粋な関数型プログラミングのエッセンスを学びたくてHaskellを選んだ。しかし、過去3回入門したが3回破門されたので、今度こそ免許皆伝したい。 普段はTypeScriptで開発を行っているので、Haskellと比較しながら学んでいきたい。 基本構文 変数の宣言 const x: number = 10 x :: Int x = 10 関数の宣言 function add(x: number, y: number): number { return x + y } add :: Int -> Int -> Int add x y = x + y アロー関数 const add = (x: number, y: number): number => x + y add :: I

イチからつくり直したほうが速い、という幻想 岩田「いまあるものを活かしながら手直ししていく方法だと２年かかります。イチからつくり直していいのであれば、半年でやります。」 引用:『MOTHER2』ふっかつ記念対談　はじめてのひとも、もういちどのひとも。 - ほぼ日刊イトイ新聞 任天堂の元社長であり、天才プログラマーと呼ばれた岩田聡氏が、MOTHER2の開発が行き詰まっているときに糸井重里氏に放った言葉だ。 技術的負債が詰まったプロジェクトに参画したプログラマーなら誰もが「イチからつくり直したほうが速い」と考えるだろう。 しかし、「イチからつくり直す」という選択肢は理想に見えるが、現実は残酷だ。 我々は天才プログラマーではない つくり直している間はお金を生み出さない つくり直しても完成する保証はない 最適解を選択し続けたはずが、完成する頃には別の負債になっている 「イチからつくり直す」という選

シニアエンジニアとイシュースカベンジャーの苦悩 誰もやりたがらないIssueは、誰もやらないまま残り続け、やがてゴミになる。例を挙げるとすれば以下のようなものだ。 リファクタリングなど、成果が見えづらいIssue ライブラリアップデートなど、面倒臭いIssue 納期があるからと後回しにしたIssue これらは労力やスキルを必要とするわりに地味で成果が見えづらく楽しくない。いわゆる「コスパの悪いIssue」だ。人事評価という制度がある以上、自身の評価を上げるにはコスパの悪いIssueは誰もやりたがらない。 しかし、ゴミIssueを放置すると腐り始め徐々にプロジェクト全体を蝕む厄介な存在になる。 私は、こういったクソタスクを拾って対応する役割を「イシュースカベンジャー（造語:Issue Scavenger）」と呼んでいる。そして自分がまさにその役割を担っている。 私の場合、他メンバーよりも我慢