Anthropicがとんでもないものを出してくれた。Model Context Protocol（MCP）である。 強いタイトルでごめんなさい。AIエージェントに関わっていてMCP触ってない人は、たぶん忙しすぎる人なんだと思う。分かる！めっちゃ分かる！忙しいよね！！！！！ ということで、AIエージェントを研究・開発してるひとは是非MCPに触れてほしい。 最低でも、仕様は把握しておくべき AIエージェントにMCPによる拡張が可能な設計を考慮すべき 現状ではClaude DesktopがMCPに対応したクライアントだ。MCPはクライアントサーバの仕組みで、tooling（旧function calling）機能を任意のサーバーで実現できるものだ。 汎用プロトコルとライブラリ集なので、OpenAIやGoogleやollamaやLM Studioなどが対応することも可能だ。特にOSSや無料ソフトの

Claudeの3.5-sonnet最新版(20241022)は間違いなく現時点では最高性能のLLMの一つである。Claude Professional PlanならそれをウェブUI・アプリ上から無制限と言ってもいいほど使える。 もともと、ある要件を実現するためにどうするのがいいか？選択肢を知りたくて、Claude sonnetやChatGPT Plus(gpt-4o, o1-preview)などに聞いてみたら、Claude sonnetが一番好みのアイデアを返してくれたので、さらに深掘りしてアプリを作らせたみた。 OpenAI o1-previewは思いもよらないスマートな解決方法を提示してくれることがある。アイデアを知りたいときに一考の余地はある OpenAI gpt-4oは割とベタというか、微妙？ SearchGPTは現時点ではコンテキストを無視しがち（単体の検索はいいけど、それ以上を

LLMプロダクト開発者がMac Studioを買ってローカルLLMを触るべき理由という記事を書きました。 mutaguchiさんのツイートを見て、LLMプロダクトの開発とはどういうものなのかを知らない人も多いのかなと気づいたので、そこらへんを記事として書いてみます。 https://t.co/4WvjuuoGnC 「LLMプロダクト開発者がMac Studioを買ってローカルLLMを触るべき理由」の記事のはてブコメント見てたんだけど、ほとんど理解されてなかったのが興味深い。 ・プロプライエタリなLLMでは、ランニングコストが嵩み、これを利用したサービスは成立しづらい… — mutaguchi (@mutaguchi) April 24, 2024 商用LLM APIとローカルLLMって使い方が全然違う気がしてる。 商用LLM APIって、機微情報を送らないこと、規約違反テキストを送らないこ

皆さんはGitHub Copilotを使っていますか？VSCodeやIDEに拡張を入れると、生成AIとペアプロのようなことができるという、アレです。 最近はこれがないと仕事ができない。なかった時代を思い出せないという人が増えています。プログラミングの生産性に明確に差が生まれます。僕もその口です。 ただ、GitHub Copilotを使いこなせていないという話も度々聞きます。Copilotが提案してくれるコードが微妙で役に立たないというような感じです。 その差はどこにあるのか？を知りたくて6/24に試しにCopilotを使った動画を撮ってみました。実践的なCopilot実演動画というのはすごく珍しいらしく、GitHub dockyardというコミュニティの竣工イベントに登壇してみないか？というお声がけをいただいたので、8/5にGitHub Copilotを使いこなせるとどうなるのかというライ

プログラムを作る時に、紙に設計を書いてから書く人、いきなりコードを打ち始める人、色々なパターンがあると思います。 僕がプログラムを書く手順について雑にまとめてみました。 関数と書いてるものは、場合によってはクラス・メソッドその他かもしれません。ご自身の環境に合わせて適宜読み替えてください。 まずはプログラミング自身というよりはそこに至るまでの話から始めます。 脳内のあれこれを吐き出すまずは何を作るのか、どうやって作るのか、なぜ作るのかなどを整理します。 紙やホワイトボードは最強です。UMLなりポンチ絵なり、文字なり好きな物をものすごい解像度で描けます。 安いノートを買ってきてもいいですし、ホワイトボードや、消せる紙、NuBoardなどを使うというのもいいでしょう。ちなみにお金を掛けずに擬似的NuBoardをするのであればクリアファイルを活用するといいでしょう。 タブレット+ペンもとても便利

noteではおそらくみなさんはじめまして。Qiita戦闘力 5,715のerukitiです。Github戦闘力は417でした。qiita.com/erukiti とか github.com/erukiti で日頃活動しております。技術書典では2,3,4と連続でサークル参加していてJavaScript入門書(200部完売)・JavaScriptAST本(まぁマニアックな本かつ台風だったので200部中170部頒布)と、今回のBitcoin完全に理解した本(200部中200部完売)をそれぞれ出しております。 今回の本は、エンジニアなら自然言語で説明するよりソースコードの方がわかりやすいだろ！というコンセプトで暗号通貨・ブロックチェーンについて解説するシリーズの第一弾です。初版は技術書典4(2018/04/22)に頒布いたしました。 電子版を、このたびnote.muでも頒布することにしました！コン

VRは仕組み上どうしても矛盾を抱えているので、本命はAR/MR（か、それをベースにした新しい流れのVR）だと確信したという記事です。先日Oculus Questの記事を書いたんですが、VR元年は来ても少なくとも現行の技術で作られるVRの延長線上に未来は無く、今までと同じくずっとVR元年が続くという認識になりました。 VRの抱えてる致命的な矛盾VRゴーグルをかぶると、プレイヤーの視界は全て3Dグラフィックでレンダリングされます。そこには一切現実空間（物理世界）は存在しません。全てコントロールされた没入度の高い世界を作り出す技術がVRです。 いくつかの体を動かす系ゲームをやってみたんですが、どれも致命的な矛盾を抱えてると僕は感じました。 VR空間内の認識と物理世界がかみ合わないのです。 VR空間内では広く感じる為に、タガが外れて、思いっきり力を込めた動作をする可能性があります。 例えばSair

JSXとHTMLベースのテンプレート言語の比較を行い、批判されがちなJSXが実はベターな解だったのでは？という記事です。 僕の結論は、HTMLとJSのどちらが制御構造を持てばいいのか？でいえばJS側が持つ方がリファクタリングしやすいため、JSXの方が良いというものです。 さて、先日、JSフレームワーク事情2020年始めという記事を書きました。これは、JavaScriptフロントエンドフレームワーク、Angularの人気が下落中という記事の元ソースであるThe State of JavaScript 2019を見ながら、React/Vue/Angularや、Next/Nuxt/Gatsbyが置かれている状況を解説するものでした。 他には、確証はないものの、Reactのシェアと人気がともに高い理由は、意外にJSXにもあるのではないか？と考えています。VueもAngularも基本的にはHTMLを

先日、技術書典で爆死しないためにという記事を書いた東京ラビットハウスのerukitiでございます。爆死しないためにって記事書いたくせに爆死かよ！！！ タイトルは大げさです。実際には248部頒布しているため「そんだけの数を頒布して爆死って？？？？」というツッコミがあると思います。 あと、別につらい、とかそういう類いの話ではないので、この記事は面白おかしく読んでください。実際おもしろい経験をいろいろできました。一部の人の心臓には痛いかもしれませんが……。 今回は知見の共有ということで記事を書いています。 Twitterの #被チェック数 というタグで、それぞれのサークルの被チェック数の共有をしていたので、頒布数に関しても一例ということでご参考ください。 と言っても、割と特殊事例なほうかもしれないので普通にサークル参加する分には、遭遇する事例ではないとは思います！たぶん！ 爆死といった理由 これ

プログラミングの習得・上達方法は人それぞれです。アカデミックでコンピュータサイエンスを習った人、独学でやってきた人、得意なこと・苦手なこと様々でしょう。 道筋はいくつもありますが、ここでは僕の道筋を書くことで、誰かのヒントになればと思います。 前編はわりととりとめもなく僕という個人の道筋を示す記事としました。後編ではこれまでに得た知見をまとめました。 僕 is 誰erukiti と申します。プログラミングを始めて30年になります。プログラミングは完全に独学で覚えました。上達の効率はさほど良くない方だとは思います。 専門学校卒ですが、専門学校はモラトリアムのためだけに言ってたので実質内職しかしてないです。高校もパソ通にハマって勉強一切やってなかったので、ギリギリの卒業でした（日数も成績も） そのあとは10年引きこもりニートしておりました。 そっから就職して、辞めてからフリーランスでエンジニア

先日のClean Architectureは全てのプログラマにお奨めしたい良著という記事では、ASCII DWANGOから出ているClean Architecture 達人に学ぶソフトウェアの構造と設計（以下、Clean Architecture本と呼ぶ）が、アーキテクチャパターンとしてのクリーンアーキテクチャ The Clean Architecture（日本語翻訳版） を採用するかどうかに関わらず、ありとあらゆるプログラマにお勧めしたい良著であると書きました。 Clean Architecture本は主に設計（実装面もある程度含む）において、メンテナンスしやすいものを作り上げるために必要な知見をコンパクトにまとめた本です。この本で押さえておくべき重要な概念は「知識」とその知識を利用する「依存関係」です。 この記事では、前回よりもさらに掘り下げて、Clean Architecture本を

「枯れた技術」と言われたとき、それが安定していて、保守しやすいものであるという認識が多いように観測されます（観測範囲問題かもしれない）。 この記事でいう技術は「ソフトウェア技術」に特化した内容です。ソフトウェア技術はまだこの世に生まれでてから100年も経過してないような若すぎる産業であり、脆弱性など、ソフトウェア技術に固有の事情があります。 でもそれってほんとですか？事実ですか？正しくそのことを検証しましたか？ あなたが枯れてないと認識している技術よりも保守しやすいと思っているのは、ただの思いこみではないですか？ 昨日軽い気持ちで書いた僕のフロントエンド技術に対するスタンスという記事のようにフロントエンド系のバズる記事を書くとだいたい「保守とか考えてるの？」みたいなコメントがつくことがありますが、では、バックエンド、組み込み、機械学習、インフラを見て、枯れた技術ってほんとに枯れてるの？保守

フロントエンド技術は、ある時期を境に爆発的進化を遂げて、面白く・DX（開発者体験）の良い世界に発展しています。 DXはDeveloper eXperienceの略で、2017年くらいから話題になっているようです。（正しい起源はわかりませんが、雑に検索した限りは、2017年のMediumやdev.toでの英語記事がヒットします） DXに関して日本語での記事は「DX: Developer Experience （開発体験）は重要だ」を読むとわかりやすいと思います。 ウェブ技術をやっている人の中で、バックエンド側しかまだ触ってない、JavaやRuby、PHPのような言語でしかウェブに触れてない人は多く、そういった人に、今のフロントエンド情勢ってこんな感じだよ！って知ってもらいたいという思いがあり、都内の某所にある「ラボ」でモダンフロントエンドエンジニア勉強会というのをお試しで開催してみました。

今、一部のエンジニアでコンピュータサイエンスが重要なのかそうでないのか？と言った話題が盛り上がっています。 僕の主張は、コンピュータサイエンスも、ソフトウェアエンジニアリングも、コミュニケーションや、言語学、あるいは他のあらゆるものも含めて、プログラミング（設計、実装、テストその他全部含む）はそれらの集合体（総合格闘技）であるというものです。 プログラマ（いわゆるPGではなくSEなども含む）は、理系の職業と思われる事も多いですが、実質、理系と文系、双方にまたがっているケースがほとんどです。研究職だとか特定の例外でのみ理系要素に偏ってるでしょう。 プログラミングは、数学、工学、文学、コミュニケーションその他の総合格闘技である以上、どれかを毛嫌いしたり、どれかに傾倒しすぎるのは勿体ないので、少し興味を持ってみませんか？というのがこの記事です。 ただ、分量が多いので、今回の記事は今話題になってる

これは、プログラミングを覚えるための方法について、自分なりの知見をまとめる記事です。 前編では僕の道筋を示しながらプログラミングを覚える過程を雑に書いてみました。後編であるこの記事では、プログラミングを覚える・上達するための方法を掘り下げていきます。 ・ まずはコードを書いて動く環境を作る ・ 初学者が最初にやるべきこと（写経 + 改造） ・ 題材探し ・ ブログを書く ・ インプット・アウトプット・実践のバランスを取る ・ 実験してみたいという好奇心 ・ ユニットテスト ・ TDDという設計手法 ・ 英語の読み書き について書いています。 まずはコードを書いて動く環境を作ろうコードを書いて動くようにするまでを、一番最初に整えるのは鉄則です。プログラミングとはコードを書いて動かしてその結果を見る、というサイクルをひたすら繰り返す行為だからです。サイクルはなるべく小さいモノを大量にまわすこと

いまのところ僕は、TypeScriptは決して理想ではないけど、最善手の言語だと認識していて、僕のフロントエンド技術に対するスタンスという先日に記事にもそういうこと書いてたんですけど、なぜTypeScriptを最善手だと認識しているか？を記事にしてみます。 VSCode の存在正確にはTypeScript Language server が持ってる機能ですが、VSCodeは他のあらゆるIDEやテキストエディタと比較しても、軽量な動作を誇るエディタ・IDEでありながら、強力な補完、tipsでドキュメント表示などの機能を持っています。 ES ModulesTypeScriptのベースであるECMAScriptのモジュール仕様も良いものです。 歴史的経緯とDOM/ブラウザ仕様とガラの悪いコードを除けば、ECMAScript のコードではグローバルを利用しません。 モジュールは export され

僕は日頃からReact Hooks + TypeScript 最高だの言ってますけど、実のところ、それらを超えるモノが登場したら一瞬で「React Hooksなんて過去の技術だよねー、#にゃーん（社会性フィルター）」とか「TypeScript？へなにそれ？過去の言語ですよね」とかボロクソに言ってる自信があります。 補足: ボロクソにいうとは限りません。その頃に、単に手のひらクルーって返してるだけで、新しい技術を「〇〇＋□□最高！」って言ってるだけになるように、人格的に成長してるかもしれませんｗ 僕にとっては技術はただの道具にすぎません。 道具に対して必要以上の思い入れもしなければ、信仰する気持ちもありません。というより今あるクソなモノよりマシなものを求める渇望がここ数十年ずっと続いてる感じです。 そんな僕が判定するフロントエンド技術の数々を書いてみます。ブログなんでぶっちゃけテキトウで率直

先日、ウェブフロントエンドについて理解するためのただ一つの方法を記事にしました。それは「古い知識に頼るな。公式を読め」でした。たった一つの方法です。これをできない人は必ず行き詰まります。公式をひたすら読み込むことができる人は、たぶん大丈夫でしょう。 今回の記事は、その先にあるものです。 モダンフロントエンドの重要性ここでは少し前回の記事のおさらいをしておきます。 2020年のソフトウェアエンジニアリングの世界ではウェブ技術の重要度は増すばかりです。もちろんウェブ技術というのは広い分野です。ウェブ（HTTP/HTML/JS/CSSその他）によるサーバー・クライアント型のソフトウェアは、莫大な市場を背景にどんどか技術が投入されています。 ウェブ技術の中でも、ここ数年はフロントエンド技術の比重がとても大きくなりました。前回の記事にも書いた通り、少なくとも50%以上の影響力を持っています。 ソフト

Clean Architecture　達人に学ぶソフトウェアの構造と設計を読んだので、まとめてみます。コメントやツッコミなどのフィードバックがあればうれしいです。 続編としてクリーンアーキテクチャ本を読むためのポイントという記事を書きました。併せてご覧ください。 なぜ良著？著者のロバート・Ｃ・マーチン（著書読んだことあるかも？）は、50年前から現代に至るまで、様々なアーキテクチャを見て、第一線級として開発し続けてきた経験を元に、どのアーキテクチャでもクリーンにしようとするなら、基本部分は変わらないと言ってて、それらが美味くまとまった本だからです。 いってみればコンピュータ工学について抑えるべきポイントを解説した本であり、The Clean Architectureそのものについてはほとんど割かれていません。それくらい、基本として知るべき事が書かれた本なのです。 最近のアーキテクチャを追いか

この記事は、ウェブ技術の開発者（Java, PHP, Ruby, Go... 全て含む）のうち、少しでもJavaScriptを触ったことがあるけど、現代ウェブフロントエンドというか、特にウェブアプリケーション —— React, Vue, Angular など—— が分からない人に向けて、たったひとつの理解方法を提示するものです。 追記: ちなみに果てしなくどうでもいいですが、今回の記事が記念すべき100記事目らしいです。（Noteさん！その手のヤツはいっそ自動で記事にバッヂを表示するとかしてくれるとうれしいです！） 対象読者は、Java, PH(以下略）などのコードと一緒に、ほんの少しでもJSのコードを触った、見たことがあるというレベル感の人なので、既にReact, Vue, Angular などでガリガリコードを書いている人は対象ではありません。 あとホームページ屋さんとかウェブコーダ