柴田 淳-【新刊】みんなのPython第五版/Pythonで学ぶはじめてのプログラミング入門教室

投稿が拡散されているようなので、ちょっと宣伝させてください。 Pythonの入門書を書いていますので、ぜひお読みください！ amzn.asia/d/gCfTi93

結果として道路は、最初から完璧に設計されたものではない。歴史的な積み重ねによって進化した構造である。 その歪みは欠陥ではなく、むしろ現実の制約に適応した証である。 この視点で地図を見ると、それは単なる位置情報ではなく、最適化問題の解の履歴として読み解ける。 つまり道路ネットワークとは、現実世界に存在する巨大なデータ構造そのものなのである。

さらに重要なのは階層構造である。高速道路、幹線道路、生活道路といった分類は、それぞれ異なる役割と性能を持つ。 これはコンピュータにおけるメモリ階層やネットワーク設計と似ている。すべてを高速化することはできないため、用途ごとに最適化される。 また、効率だけを追求するとシステムは脆くなる。事故や渋滞に対応するためには、ある程度の冗長性が必要である。 このように道路ネットワークは、効率・コスト・耐障害性のバランスの上に成り立っている。 そして都市は時間とともに変化する。新しい道路が追加され、古い構造に修正が加えられ、ネットワークはより複雑になっていく。

道路ネットワークをデータ構造として表現するためにはどうすればいいだろうか。 まず最も基本的なモデルはグラフである。交差点をノード、道路をエッジとして表現することで、都市全体を一つのネットワークとして扱えるようになる。 このとき、最短経路探索や交通の流れは、コンピュータサイエンスでよく知られた問題として扱える。つまり都市は、巨大なアルゴリズムの実行結果のように見えてくる。 しかし現実の道路は理想的なグラフとは異なる。格子状に整った都市もあれば、入り組んだ曲線だらけの街もある。 その違いは、地形や歴史、そして人間の意思決定によって生まれる。つまり道路ネットワークは、純粋な設計ではなく制約の集合なのである。 sandboxspirit.com/blog/data-stru…

この問題は単なるMicrosoftの話ではなく、巨大ベンダーと政府の関係そのものを示している。市場構造が安全性よりも優先される瞬間があるということだ。 そして最も重要なのは、「問題が分かっていても止められない」という意思決定の限界である。これはAIや他のインフラ領域にも共通する構造である。 技術的に正しいことと、組織的に選ばれることは一致しない。このギャップこそが、現代のITリスクの本質である。

意思決定の背景には、既存の契約関係や政治的な圧力、そしてベンダーロックインに近い状況があったとされる。つまり「他に選択肢がない」状態が作られていたのである。 また、クラウド移行という大きな流れの中で、多少の問題は受け入れるという姿勢も見られた。スピードと規模が優先され、安全性が後回しになったとも言える。 結果として、専門家の警告は記録には残るものの、意思決定には十分反映されなかった。この構図は、過去のITプロジェクトでも繰り返されてきたものである。 さらに、クラウド事業者側の責任も問われている。セキュリティ問題が繰り返されているにもかかわらず、大規模契約が維持され続けている点である。

Microsoftのクラウドは米政府組織内部で「microslop」と揶揄されるほど酷評されながらも、結局採用された。ここには歪んだ意思決定が働いているのかも知れない。 ある連邦機関の内部では、Microsoftのクラウド基盤に対して厳しい評価が下されていた。セキュリティの甘さや設計上の問題が指摘され、「これはひどい」とまで言われるレベルであったという。 特に問題視されていたのは、過去の大規模インシデントの対応や、基本的なセキュリティ設計の不備である。専門家たちは、国家レベルの機密情報を扱うには不十分だと考えていた。 それにもかかわらず、最終的にはそのクラウドの使用が承認されることになった。ここに、技術判断と組織判断の乖離がある。 arstechnica.com/information-te…

もうちょっと難しくした方が良かったかな？

私の書いたOh! X令和版のSHIFT BREAK、さっそく解読してる人がいる。

@ma_angie 手元のPC上でエミュを動かすのが一番楽みたいですよ。

@ats なるほど！ 発想すら及びませんでしたorz zenn.dev/tantangh/artic… レトロPCには疎いのです😅

エミュで動かせばいいんですよ。 付録ディスかの全データがDVDに入ってるんですが、昔作ったピンポールゲームで遊びたいな、と思いまして。

@Mar_3simai そう思われる方は多いと思います。 OpenAIの業績次第なのかなあ。

@ats AstralのツールはRuffとか普段からお世話になってるので、OpenAIに入ってどう変わるか少し心配な気持ちもあります。オープンソース継続の約束がどこまで続くか、そこが気になっています 😮

OpenAIは、Python開発ツールで知られるAstralの買収を発表した。uv、Ruff、tyといった広く使われるオープンソースツールを取り込むことで、Codexを単なるコード生成AIから「開発全体に関与するエージェント」へ進化させる狙いだ。 現在Codexは急速に成長しており、週200万人以上が利用する中で、AIが計画・修正・実行・検証まで担う統合的な開発体験を目指している。Astralのツールは依存管理・品質チェック・型安全といった開発の中核部分を支えており、これらとAIを統合することで、より実用的な開発支援が可能になる。 買収後もオープンソースとしてのサポートは継続される予定で、Pythonエコシステム全体の強化と、AIによる開発生産性のさらなる向上が期待されている。 openai.com/index/openai-t…

Oh! X 令和版に付属しているDVD、みなさんどんな風に読み込んでますか？ ちなみに私はMacbook Air(2024)を使っています。

一方でCPython本体でもJITの検討は続いていましたが、動的型付けゆえの最適化の難しさや、開発リソースの制約により長く停滞していました。そうした中で、近年になってようやく設計の見直しと体制の強化が進み、「実験」ではなく「実用」を目指すJITとして再び動き出します。

CPythonの外部を含めると、とJITの関係は実は長い歴史があり、古くから「PythonでもJITは有効ではないか」という期待は繰り返し生まれてきました。ただしこれらはCPython本体とは別系統であり、互換性や運用面の課題から広く普及するには至りませんでした。

CPython JIT再始動：設計転換がもたらした実用的高速化 note.com/shibats/n/nb57…

短期的にはブランドと開発者体験が欲しかったんでしょうね。 AI戦争がモデル性能から開発者体験に移っりつつあって、Codexの利用をブーストしたい考えがあるのかも知れません。 長期的に見ると、各種オープンソースプロダクトの開発継続性が危ぶまれるという見方があり、私もそれを懸念しています。

OpenAIによるAstral買収については、正直かなり複雑な気持ちだ。 戦略としては極めて合理的だと思う。モデルだけでなく、lintやパッケージ管理といった開発の足回りまで押さえることで、AIネイティブな開発体験を一気に完成させにきている。短期的には、開発者体験は確実に良くなるだろう。 ただ、その一方で気になるのは、オープンソースの独立性だ。Ruffやuvのように事実上の標準になりつつあるツールが特定企業の傘下に入ることで、エコシステムの中立性が崩れる可能性は無視できない。過去の例を見ても、「OSSは継続する」と言われても、その優先順位が徐々に変わっていくことへの不安はどうしても残る。 便利になるのは間違いない。でも、その便利さと引き換えに、開発基盤のコントロールが一部の企業に集中していく流れには、少し身構えてしまう。 良い動きでもあり、同時に警戒すべき動きでもある。そんな印象だ。

Wickid見に来た。

カーネルレベルで実行されるゲームのアンチチートの仕組み、おもしろいな。 s4dbrd.github.io/posts/how-kern…

Pydantic AIのメンテナが、ここ15日で136件のPRを受け取るも、その多くがAI生成の「中身のないコード」で、レビュー負荷が限界に達していると報告。わずか39件しかマージできず、残りはほぼ低品質なPRとしてクローズされたという。特に問題なのは、同じバグに対して数分おきに似たようなPRが量産される現象で、メンテナの時間が本来の開発ではなく「選別」に奪われている点。 議論では、対策として「Issue未紐付けPRの自動クローズ」「ガイドライン無視PRの拒否」「AI利用の明示」「テンプレ未使用PRの自動拒否」などが提案される一方、ドキュメント修正などの軽微な貢献まで排除してしまう懸念も共有された。また、AI生成PRを検出する仕組みや、CLA（AI未使用宣言）や動画・スクショ提出などの“負担を課す仕組み”も議論されている。 全体として、オープンソースは「誰でも貢献できる場」から、「低コストで大量にコードを生成できる時代」によって質の維持が難しくなり、メンテナの役割がますます過酷になっている現実が浮き彫りになっている。 reddit.com/r/Python/comme…