サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
序文 しばらく前から、プログラマーを対象とした圏論に関する本を書こうと考えていた。計算機科学者ではなくプログラマー、科学者ではなくエンジニア向けだということに注目してほしい。正気の沙汰ではないし、本当に恐ろしい。科学と工学の間に大きなギャップがあるのは否定できないと思う。自分自身がその分断の両側で仕事をしてきたからだ。それでも、物事を説明したいという強い衝動をいつも感じていた。簡潔な説明の達人だったリチャード・ファインマン1を心から尊敬している。自分がファインマンではないことは分かっているが、最善を尽くしたい。まずは、この序文――読者に圏論を学ぶ気を起こさせることを想定したもの――を公開することから始めようと思う。それによって議論を開始しフィードバックを募れることを願っている2。 ここからの数段落をかけて、この本はあなたのために書かれたものであり、数学のうちでも特に抽象的な分野を学ぶために
いきなりですが。海外旅行したり働き始めたりすると、日本の良さが身に染みたと感じた人は多いんじゃないでしょうか？ なんかとりあえず外で働いてみたいと思っていましたが、今はいつ戻るかと考える日々です。（とにかく温泉に入りたい） また色々と各国を回る中で、日本企業ってアジア圏や他の国にもかなり進出してるんだなぁと実感しました。（そりゃそう） そんなこんなで日本株に興味を持ち 昨年にわが投資術を購入して実践し始めました。（まだ初めて一年目なので成績はわかりません。。。が、マイナスは無し） 自分でバフェットコードや Claude mcp-yfinance などを利用しながらスクリーニングしてみましたが、毎回決算が出るたびに手動とチャット相手にあるのも何かなぁ。と思いまして。 じゃあ自動収集とスクリーニング用のアプリ作ってみよう(vibe coding) そんなノリから、日本株全銘柄を自動収集・簡易
AI楽観派にとって、「動く」ことがすべての証明。AI慎重派にとって、「なぜそう動くか」がすべての理由。 両者が同じコードを見ても、 前者は「成果物」を見ており、後者は「思考の痕跡」を見ている。 視点の深度が違うのだ。 5. 設計＝抽象、コード＝具象 コードを書くとき、頭の中には「構造」がある。 それは最初から完璧ではなく、書いて、動かして、違和感を覚えて、直していく。 命名、依存、責務、階層を少しずつ整える。 この「書きながら考える」行為こそが設計であり、設計書よりもコードの構造そのものが本当の設計書になる。AI楽観派の前提は、「設計と実装は分離できる」。AI慎重派の前提は、「設計と実装は不可分」。 この一点が、AI時代の開発を分ける境界線だ。 6. バイブコーディングの議論が噛み合わない理由 バイブコーディングをめぐる議論は、 実は技術論ではなく認識論の衝突だ。AI楽観派：AI
UNIX の父であるケン・トンプソンは、C言語の元になったB言語の開発者で、B言語の前に Bon という言語を作っていたことで知られています。この Bon についての詳細は不明で、失われた言語だと思っていましたが、Bon のマニュアルがネットに落ちており、詳細が分かりました。 そういうわけで、Bon の概要解説という誰得情報をお伝えします。 ケン・トンプソンはB言語を作る際に、Bon を元にしたわけではなかったようですが、同一人物が開発した言語ですので、多くの共通点が見られます。B言語、C言語、Goとの共通点や相違点を見ればケン・トンプソンの設計思想を垣間見れるかもしれません。 Bon はインタプリタ言語であり、入力したプログラムがすぐに実行されるイミディエイトモードと、記憶されたプログラムを実行するストアドモードがありました。若い人にはわからないかもしれませんが、BASIC インタプリタ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 表明しておかないと、自分が最新技術を毛嫌いしてるだけの人と思われるかもと思ったので、いったん自分の考えを吐き出しておく。 自分は、情報を評価・抽出する系の作業 (文章を要約するとか、コードをレビューするとか) をAI にやらせるのはあまり抵抗感がなくて、趣味開発でも Copilot や CodeRabbit によるコードレビューのお世話になっている。 一方で、情報を押し広げる系の作業をAI にやらせると成果物の正確性や保守性に対する信頼性が全然足りない。「適当に書き殴らせてうまくいかなかったら全部捨てればいい」「コードの良し悪しは気
いまだにオブジェクト指向とか言ってるのか、という話ですが、いまだに「プログラミングの勉強はじめました。オブジェクト指向が目標です！」みたいなのがThreadsに流れてきたりして、いつまでも無くならんなぁと思うわけですよ。 で、まあオブジェクト指向を勉強してしまいたくなるのは仕方がないとして、オブジェクト指向推しの本でのサンプルがだいたいヒドいのが問題だなと思ったわけです。 アプリケーションを見据えていない オブジェクト指向の例として、自転車クラスだとか勇者クラスだとか定義するサンプルをみかけます。自転車クラスを作る例の場合、車輪クラスがありサドルクラスがありペダルクラスがあり、ブレーキクラスはブレーキシュークラスやブレーキキャリパークラスを内包するな、みたいなことをやりますね。JSONでやれ。 という感じで、単にJSONなど構造データのマッピングになりさがってたりします。 あと、現実の写
読みやすいコードとは何か 読みやすいコードとは、脳に負荷がかからないコードである。脳に負荷がかからないコードとは、人間の脳の特性に配慮して書かれたコードである。したがって読みやすいコードを書くには、まず人間の脳の特性を把握する必要がある。読みやすいコードの特徴は、この人間の脳の特性から論理的に導かれる。 また、「コードを読む」とは過去から未来への情報伝達、または自分から他者への情報伝達であり、情報理論における以下の２つの数学的原理にも支配される。 頻出する情報には共通の符号を割り当てることで情報を圧縮することができる。 失われた情報を復元することはできない。 この記事に書かれた内容はプログラムに止まらず、ドキュメント、記事の執筆など、プレインテキストによって情報を伝達する際には一般に適用可能である。 もしもこの記事を読むのが面倒であれば、以下の５つだけを覚えておけばよい。 ひとつの処理の単
/追記予定のもの/ explicit final デフォルトコンストラクタの明示的指定について スマートポインタ(さわりだけ) ODR系のなんか(ファイル分割とか) デフォルト引数でコンストラクタに引数を渡さないようにするのは良くない 導入 私が持てる全ての知識を共有するために、このような記事を書くことを決めました。 前半はC++のお作法。 後半はオブジェクト指向の普遍的な設計方法についてです。 なお、C++11以降を前提として話を進めていきます。 謝辞 私に今回の記事を書くにあたってアドバイスを提供してくれたツイッターの方々、 @kazatsuyu @yumetodo @coord-e @badadder @Gaccho に感謝の意を表します。 using namespace stdを使うな 以下のコードは典型的な悪いコードです。
配列（Array）との比較JavaScriptにはTypedArrayとは別に配列（Array）の違いを説明します。 ArrayはTypedArrayと比べると柔軟で汎用性が高いです。しかし、Arrayは内部で動的なメモリー管理を行うため、データ処理や転送を高い頻度で行う場合にはオーバーヘッドが発生する可能性があります。 TypedArrayは長さが固定であり、バイト単位のデータ格納が可能なため、メモリーアクセスが効率的に行われます。数値計算においてもバイナリデータを直接操作できるので、高いパフォーマンスが期待できます。また、メモリー領域が連続しているので高速なデータの転送が可能です。 大量のデータを処理する数値計算の場合にはTypedArrayで管理するとデータのまとめた取り回しが楽になります。逆にデータの規模が小さい時は汎用的なArrayが良いでしょう。 TypedArrayは決まっ
タイトルは半分釣りです。課金額が気づいたらえらいことになってたのは本当です。 というわけで、VSCodeで直接使うのではなく、VSCodeに加えて定額サブスクのClaude ProとそのDesktopアプリからコード生成や編集をしてもらうことで、APIをなるべく使わずかつ楽に開発を助けてもらえないか試してみることにします。 4/15 追記 Proでも無双しづらくなりました サブスクでいいけどもっとお金払ってね❤️ とのことです（お世話になります） MCPサーバーが使えるのは現状Desktopアプリのみ (3/15追記) claude.aiのWebでのチャットに対してDesktopアプリのみ、という意味です。プロトコルなので、LLMのAPIを用いてMCPクライアントを実装していれば何からでも使えます（ClineやCursorもそう）。 MCPサーバーについて特にここでは詳しく説明しません。
■AIと性格選択が生み出す新体験 『電脳少女プログラミング2088-壊レタ君を再構築-』は、paizaがこれまでに提供してきた『PaizaProgramming Game』（以下、PPG）シリーズの最新作です。PPGは、ユーザーのプログラミングスキルをS・A・B・C・D・Eの６段階で評価する「paizaスキルチェック*」のシステムを活用し、ユーザーが楽しくプログラミング問題に取り組みながら学習できる無料のプログラミングゲームです。 このゲームでは、「楽しみながらプログラミングを」というPPGのコンセプトを実現するため、生成AIを通じてフィードバックそのものをエンターテインメント化しました。プログラミング学習は難しく、特にエラーやつまずきによってモチベーションが低下しやすい課題があります。この課題を解決するため、生成AIを活用し、楽しくスキルアップできるPPGを作りました。ゲームプレイ
TL;DR Q: HPCプログラマの書くコードってなんで古臭いの？ A: そうしないと性能が出なかったから はじめに スパコンを使ってそれなりに長いこと研究をしています。初めてスパコンを使ったのは今から25年くらい前です。発展の早い世界ですので、昔と今ではだいぶ違ってきています。この前、スパコンを使う時の「常識」がすでに現在では常識ではなくなっているっぽいことを知り、私も「そっち側」になったのか、と感慨深くなりました。以下は、HPC業界の語り部に片足を突っ込んだおっさんの戯言です。 なお、以下では主に「京」の話をするため、富士通のC++コンパイラに文句を言う形になりますが、富士通が悪いのではなく、昔のスパコンに搭載されていたC++コンパイラはどれもかなり酷かったということはあらかじめ言っておきたい気がします。IBMのコンパイラとかも酷かったし、なんならIntelのコンパイラもバグだらけだっ
こんにちは！ Magic Momentフロントエンドエンジニアの @morishin です。 この記事は、Magic Moment Advent Calendar 2024 4 日目の記事です。 はじめに 開発あるある 皆さん開発をしていて、コマンドの "待ち" が長いとき、こんな経験はありませんか。 「ビルドに時間がかかるなぁ」 (別の作業をする) 「もう終わったかな (ﾀｰﾐﾅﾙﾁﾗｰ」 「まだかー」 (以降無限ループ) 作業に集中できない！ 逆に 「このインストール時間かかるなぁ」 「終わるまでちょっと休憩しようかな (ｽﾔｧ」 〜3 時間後〜 「...あっ、いつの間にか終わってた！」 処理の完了に気付かずついつい休憩しすぎた！ ありませんか？ありますよね？ まあ休憩しすぎたっていうのはないにしても、実はエラーで処理が中断していたのに気付かなかった、というのはあるあるな気がします。
みなさん、こんにちは！私は株式会社ulusageで技術ブログを担当しているエンジニアです。最新の情報や、日々の開発で役立つTipsを皆さんと共有していきたいと思います。どうぞよろしくお願いします。（もしこのブログの仕組みやシステムフローに興味があれば、ぜひお知らせください。皆さんのご要望に応じて、詳細な記事を作成します！）Pythonでのデバッグ：print()からic()へ、革新の手法 はじめにPythonで開発を進める中で、皆さんも一度は「なぜこのコードは期待通りに動かないのだろう？」と頭を抱えたことがあるのではないでしょうか。そのようなとき、print()関数を使って変数の値を出力し、デバッグを行うのは一般的な手法です。しかし、複雑なコードや大規模なプロジェクトでは、print()だけでは限界があります。今回は、そのデバッグ手法を一歩進めるためのライブラリ「IceCream」とそ
プログラミングでは、1文字でも打ち間違いがあればエラーの原因になってしまいます。 そこで似たような文字、例えば数字の「1」（いち）とアルファベットの「l」（エル）、数字の「0」（ゼロ）とアルファベットの「O」（オー）などを容易に見分けられるようなフォントを使うことが、ミスを防ぐことにつながります。 コードを表示させたときに整然として見やすく、エディタ上でカーソルを上下に移動させてもカーソル位置が左右にぶれずに表示されるように文字の幅が等幅に揃っていることも必要でしょう。 日本語の場合には、「－」（マイナス記号）と「ー」（音引き）の区別や、コード内に全角空白が紛れ込んだとしてもすぐに見分けられることなどの特徴を備えていることもプログラミングに適したフォントに求められる条件だといえます。 この記事では、そうした特徴を備えたプログラミングに適したフォントをまとめました。 ここで紹介されていない日
本記事の初版を公開したのは 2024 年 9 月 21 日だったのですが、その後 9 月 26 日に、ピックアップした論文を大幅に増やして更新しました。 また、最初はタイトルを「和文プログラミング論文を〜」としていたのですが、いわゆる「日本語プログラミング言語」の話にも見えてしまうことから、「プログラミング和文論文を〜」に置き換えました。 日本の人々が「プログラミング」にかかわるようになったのは、いつごろでしょうか? その前に、まずは世界のコンピュータとプログラミングの歴史を簡単に振り返ってみましょう。まずは OS から有名どころをたどると、 わかりやすくWindows 95 が 1995 年 [1] その前に広く使われたWindows 3.1 は 1992 年 [2] その下で動く MS-DOS は、バージョン 6 が 1993 年、バージョン 1 が 1981 年 [3] Linu
結果的に1200行を越えましたが。 kilo 成果物はこれ↓ 参考サイトはこれです↓ インスパイア元↓ 感想 C言語は10年ぶりくらいに書いた 進めていくうちになんとなく思い出すことができた 最初にちゃんと授業で学んだ言語なので懐かしく思った Cに出会っていなければプログラミングしてなかったかもしれないので感慨深い しかしこのレベルのメモリ管理は正直たいへん 「この関数で確保したメモリはこっちの関数で開放されるので問題ありません」みたいな この調子でやっていったらバグる未来しか見えない 1000行・1ファイルというコンセプトは良いのだがファイル分けて管理したいナ〜〜と思った 配列や文字列の操作、メモリ管理がやりやすい別の言語で書き直したい Cを書くの大変だな…という感想を持った 速さはともかく他の言語で書きたい もっとimmutableに… お手本よりも行数が増えた 1行のif文などでもブ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
