AIにプログラミングをさせることに関する議論が盛り上がっている2025年 抽象度の高い高級言語的な表現によって具体的で低級言語的な表現が生成されるシステムは今回が初めてではない コンパイラがC言語の記述から機械語の記述を生成する LLMが自然言語の記述からプログラミング言語の記述を生成する A: 最初は「生成できた、しかし役に立たない」の状態からはじまる B: その次に「生成したそのままでは役に立たない」「しかし手直しすれば使える」 手直しコストがゼロからの作成コストより安くなれば経済的合理性が生まれる ここまでは低級言語の知識が必要である C: 「生成したそのままでは役に立つ」がくるかどうかに意見が分かれている リーキーアブストラクションの法則 「抽象化には漏れがあるから完全に低レイヤーの知識が不要になることはない」という主張 2025年現在「Cが実現される」という意見に反対の立場のソフ

AIによるコーディングアシスタント、コーディングエージェント、アプリケーション自動生成サービスまとめ（2025年3月版） アプリケーション開発の生産性向上において、AIによるプログラミング支援サービスは欠かせないものになろうとしています。 そして市場にはプログラマが入力するコードの補完からコードやテストの自動生成、アプリケーションそのものの自動生成までさまざまなツールやサービスが登場しています。 ここでは多数のツールについてそれぞれの主な機能や目的が分かりやすいように、「コーディングアシスタント」「コーディングエージェント」「アプリケーション自動生成／Text to App」の3つに分類して紹介しましょう。 もしもここで紹介されていないプログラマ向けのAIツールなどがありましたら、X/Twitterやブックマークのコメントなどで教えてください。 AIが、人間のプログラマが書くコードの補完や

・Claude Sonnet 3.7を使え ・Project Rules（.cursor/rules）を使え ・ビルド、lint、テストなどで高速にフィードバックさせろ ・1セッションあたりで依頼することはできるだけ少なくしろ ・よく使うコマンドやライブラリはチートシート作れ Yamada 補足 2025/03/06現在 Roo-Code は .cursor/rules を自動で参照しない。.clinerules, .cursorrules, .windsurfrules は自動で見ておりすべてを結合してコンテキストに入れる。Roo-Codeを使う人は .cursorrules を設定しておくのがよい。

Reactはシンプルなサイトから複雑なアプリケーションまで、非常に幅広く採用されている人気のフレームワークです。OSS化から10年以上の歴史がありながら、昨今もReact Server Componentsなど革新的なアイディアを我々に提案し続けています。 一方で、React Server Componentsへの批判的意見やBoomer Fetching問題などを見ていると、Reactチームと一部Reactユーザーの間には意見の相違が見て取れます。この意見の相違はそれぞれが置かれた状況の違いから生じるもの、つまり「見てる世界が違う」ことに起因してると筆者は感じています。 本稿では「Reactチームの見てる世界」を歴史的経緯を踏まえながら考察し、Reactの根本にある思想やコンセプトに対する読者の理解を深めることを目指します。 要約 ReactはMetaの大規模開発を支えるべく開発され、シ

世の中に多くあるエラトステネスの篩の実装、多くあるくせにちょっとしか高速化してないのが悲しいので高速化エラトステネスの篩を書いてみることにします。7 本目(利用者が限られる)を書くかどうか迷い中。 エラトステネスの篩の高速化 (1) ← 今ココ エラトステネスの篩の高速化 (2) エラトステネスの篩の高速化 (3) エラトステネスの篩の高速化 (4) エラトステネスの篩の高速化 (5) エラトステネスの篩の高速化 (6) 問題設定 とりあえず C++11 くらいで動く物を作りたいと思います。インラインアセンブラや SIMD、並列化は明示的には入れない方針です。あと、エラトステネスの篩自体の高速化を目指すので、結果は一部の具体的な素数の確認と $\pi(x)$ の値で確認することにしますし、その時間は考慮しないことにします。 また、ライブラリ的に使えるよう、将来的には区間篩 (大きな $x$

私の目標は、読者が午前中に本書を読み始めたら、午後には設計が上達していることだ。 本当にそのとおりだった。読んでる途中で既に自分の設計に対する考えが良い方向に変わってると感じた。とても良かった。おすすめです。 『Tidy First?』 をいただいて読んだ。昨日（2024年12月25日）発売。英語版が2023年11月28日発売だから、たった1年で日本語版が出たということだな。うれしい！はやい！ありがたい！ ソフトウェア設計に焦点を当てたシリーズの最初の1冊ということで、サブタイトルに「個人で実践する経験主義的ソフトウェア設計」とあるように、1人でできる種類のソフトウェア設計について書かれている。続刊ではチームについての話になる予定のようで、それも今から楽しみ。 2周読んだ なんとなく2周読もうと思ってそうした。 1周目は細かい部分は気にせずにざーっと1,2時間くらいで読んだ。全体的にどうい

BERT や GPT の登場により、テキストを扱うモデルは大きく発展しましたが、否定というごくありふれた操作を扱うのが依然難しいです。 本稿では、その理由と、部分的な解決策を紹介します。 目次 目次 否定文を理解できないAIたち 否定文を理解できずに困ること なぜ否定文をうまく扱えないのか なぜたまに成功するのか 対処法 ファインチューニング プロンプトの工夫 否定文を意識した訓練 文書数を増やす クエリとキーを拡張する おわりに 否定文を理解できないAIたち BERT (tohoku-nlp/bert-base-japanese-v3) で A =「私はお寿司が好きです。」 B =「私の好きな食べ物はお寿司です。」 のテキスト埋め込みのコサイン類似度を求めてみましょう。A と B は同じようなことを言っており、予想されるようにコサイン類似度は 0.9695 と高いです。 では、 A =「

学生プログラマーとの関わりこれまで6人の学生プログラマーさんに仕事を手伝ってもらってきました。最初は「仕事を手伝ってくれたら嬉しいな」くらいの気持ちでしたが、最近は学生さんの成長を見るのが楽しくて、仕事が大してなくても雇っています。バイト代も払っていますが、ここで言う「弟子」みたいなものかなと思っています。 これまで4人の学生さんが卒業していきましたが、彼らはいずれもゲーム会社に就職しています。業界最大手の会社や、その子会社などです。 自分のプログラマー歴話の前に軽く自分の経歴を説明しておきます。大手でゲームプログラマーとして10年。メインはグラフィックのプログラムでした。その後、独立して8年ぐらいプログラムも書きつつゲームデザイン、ディレクションもしてゲームを作り続けています。代表作は最近だと『Godzilla Voxel Wars』です。 採用で重視していること学生さんが皆ゲームプログ

https://youtube.com/watch?v=Q_FtGfUV5u0https://youtube.com/watch?v=HVC6RL3TyZIhttps://youtube.com/watch?v=wEX1_NYoPlshttps://youtube.com/watch?v=7utuuiw7v0Uhttps://youtube.com/watch?v=9qN9EF-6IcIhttps://youtube.com/watch?v=K7kRDPmwzVIhttps://youtube.com/watch?v=AOux701nwCUhttps://youtube.com/watch?v=N6PR1n4Oyaohttps://youtube.com/watch?v=i2ZQ1OdfcHI 本当はもっと出したかったけど、URLを10件以上含んだ増田は投稿できないようだ。残念。

コードレビューする時、自分がどんなことに気を付けているか (本当は気をつけたいか)みたいなポイントをまとめてみた。 コードレビューの目的 プロダクトの品質を担保するため 人は基本的にミスをするもの 1人で考えたものより、2人、3人集まって考えたものの方が良いことが多い 知識をチーム内でシェアするため チームでコードに関する知識を常に共有し続けることで、「この機能はAさんしか知らない」といった属人化問題を防ぐ Aさんが有休取った時に限って障害が起きたりするんですよね。分かります 他の人が書いたコードを読み、さらに分からないことは質問できる、素晴らしい学びの場だと捉える 責任をチーム内でシェアするため 何か問題が起きた時に関連するコードを書いた人間だけが責められるようなことは決してあってはならない レビュー時 (又はそのコードがデプロイされるまで)に問題に気づけなかったチーム全体の責任なので、

アーキテクチャを理解可能にするために、同時に見るべき関心事は最大7個にしよう、という話がよかった。 よくわからない難しいコンポーネントの話をしてると、「これってこういうこと？」「それは〇〇という概念があって…」というのが延々と続いて、話が全然進まない、ということがある。 そういうときは、抽象を見つけるのに失敗していて、フラットに様々な概念を並べてしまっている、と言える。 適切に意味をまとめていって、中心概念と、それの付随する概念が最大6個となるように、六角形の花、ヘックスフラワーにプロットしよう、というアイデア。で、そのフラワーの1セルを拡大すると、さらに、中心概念と付随する概念6個、というかたちで、入れ子にしていく。 ソフトウェアの分割統治っていうと新しい話ではないけど、フラットな20個の概念に分割されても、覚えてられない。 この本では人間が一度に覚えていられるマジカルナンバーを参照して

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 今回はIPA（情報処理推進機構）が無料で公開しているエンジニア向け資料をまとめました。エンジニアやIT担当者におすすめの資料を厳選しています。 今回紹介する資料の結論 安全なWebサイトの作り方 要件定義ガイド DXスキル標準 情報セキュリティ白書2024 DX白書 情報セキュリティ10大脅威 2024 簡易説明資料 情報漏えい対策のしおり AI社会実装推進調査報告書 安全なWebサイトの作り方 安全なWebサイトの作り方では、Webアプリやサイトを作る上で知っておくべきセキュリティ知識を基礎から網羅的に学ぶことができます。

Odinと言うプログラム言語を、ご存じでしょうか？ 最近、youtubeで海外のコンピューターサイエンティストの間でも、話題として取り上げられるようになってきました。 Odinは、C言語の代替プログラム言語とも言われ、ジェネリクス、パターンマッチング、エラー処理など、現代的なプログラミング言語の機能を備えたプログラム言語だと言われています。 C言語の代替プログラム言語といえば、CarbonやRustが有名ですが、どちらの言語も難解すぎると言う欠点があります。 Odinの開発者はスウェーデンのgingerBill氏で、Odinと言う言葉は、北欧神話に登場する神の名前です。知識と詩の王であり、死と復活を司る神として知られています。 神話の神を司った、このプログラム言語を覚える事で、あなたも神に・・・。（厨二病） 失礼、あなたもC言語を脱却出来るはずです。 最近では、JangaFX社のリアルタイ

なぜ依存を注入するのか DIの原理・原則とパターン 著者: Steven van Deursen, Mark Seemann 訳者: 須田智之 表紙には.NETやC#の文字はないのですが、前の版は"Dependency Injection in .NET"で.NETを前提した本のようでした。 ただ、はじめにで 本書では、.NETとC#を用いて、依存注入に関する用語や指針を包括的に紹介し、描写しているのですが、本書の価値が.NETの外の世界にも届くことを望んでいます。 とありました。 RustのDIでなにか活かせる教えを期待して、読んでみました。 第1部 依存注入 (Dependency Injection: DI) の役割第1章 依存注入 (Dependency Injection: DI) の基本: 依存注入とは何なのか? なぜ使うのか? どのように使うのか?まず、保守容易性(maint

『手を動かしてわかるクリーンアーキテクチャ 』の第二章の冒頭に登場する話題に共感したので紹介。 従来の多層アーキテクチャでは、データベースを中心にアプリケーションの 開発が行なわれます。この場合、Web 層はドメイン層に依存し、ドメイン層は 永続化層、つまり、データベースに依存することになります。そうなると、す べてのものは永続化層上に構築されることになり、その結果、いくつかの要因 が絡まり合って、問題が起きやすくなります。 手を動かしてわかるクリーンアーキテクチャ　ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 20p 手を動かしてわかるクリーンアーキテクチャ　ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 作者:Tom Hombergs,須田 智之インプレスAmazon 著者によれば、機能開発をデータベース中心に設計すると、ドメイン層と永続化層の密結合が

anond:20240624084844 を読んで思ったこと。2番目以降は正直良くわからないが、一点目についてはわかりみしかない。 うちはメガベンチャーで内製アプリの開発保守をしてるんだが、新卒で採った青(水色？)のエンジニアが連続でクソ野郎でめちゃくちゃしんどかった。 ◯色コーダーマウントちょくちょく自分は◯色コーダーだって主張してくる。 こっちはお前が学生時代に取った資格の話なんて興味ねえんだよ。 センター試験の点数自慢してる社会人いるか？いねえだろ。 評価されたければ与えられたタスク以上の成果を挙げろ。 資格自慢をしたければ、社会人にふさわしい資格を取れ。 お前のガクチカなんぞ知らん。 コードがゴミ競プロエンジニアといっしょに仕事したことある人なら大体頷いてくれると思うんだが、彼らの書くコードは本当にひどい。 処理がどれだけ効率的だろうが、実務においてメンテナンサビリティの無いコード

import torch x = torch.tensor([1., -1.]) w = torch.tensor([1.0, 0.5], requires_grad=True) loss = -torch.dot(x, w).sigmoid().log() loss.backward() print(loss.item()) print(w.grad)

先日こういうツイートが流れてきた。 Q:なぜ金融系では未だにCOBOLが使われるんですか？ A:お手元にExcelがありましたら任意のセルに「=4.8-4.7-0.1」って入れてみてください。— 遊撃部長F/S&RWAs (@fstora) 2024年6月6日 Q:なぜ金融系では未だにCOBOLが使われるんですか？ A:お手元にExcelがありましたら任意のセルに「=4.8-4.7-0.1」って入れてみてください。 普段我々がゴリゴリ馬車馬のように使っているソフトウェアでよく利用されている浮動小数点型、すなわちfloatやdoubleなどは特定の算術に弱いことが知られている。というかもうこの手の話題はあまりに拡散されてしまったので、なぜかネット民はみんな知っている基礎教養、三毛別羆事件とかデーモンコアみたいな感じになっている。 ちなみにこれはCOBOLかそうではないか、という軸が問題になっ