凡例⁠： ◯：機能提供 △：アドオンで提供 ＋：機能を拡張 Webツールキットが持つ機能 ここではWebツールキットがどのような機能を持っているかを見ていきます。 WSGI/ASGIユーティリティとしての機能は、Webツールキットが必ず持つ機能と考えてよいでしょう。PythonのWebサーバーのインターフェースである、WSGIやASGIに対応させるのは基本機能となり、Webツールキット側が担います。 リクエスト・レスポンスオブジェクト、HTTPヘッダー・クッキー操作、フォームデータのパースもWebツールキットが提供しています。これらの機能は、Webを作る上での基本的な機能となり、HTTP通信部分など低レイヤーの機能になります。 ルーティング機能もWebツールキットで機能を提供していますが、Webフレームワーク側で機能拡張していることがあります。 これらにより、Webフレームワークは、低レイ

🧪 GPIO round-trip at 480ns Python, in hardware. 480ns GPIO. No interpreter. No C. Just PyXL. TL;DR ⚡ PyXL runs Python directly in hardware — no VM, no OS, no JIT. 🧪 A GPIO roundtrip takes 480ns on PyXL vs. ~15,000ns on PyBoard (MicroPython). 📉 PyXL is 30x faster than MicroPython — or 50x when normalized for clock speed. 🎥 The video demo shows both systems in action on real hardware. 💡 This is

セキュリティニュースメディアの「SecurityOnline」は2025年4月27日（現地時間）、Python実装のHTTP/1.1プロトコルライブラリーである「h11」に深刻な脆弱（ぜいじゃく）性が存在することを報じた。これを悪用することで、リクエストスマグリング攻撃を実行される可能性がある。 CVSS9.1のクリティカル脆弱性発覚　h11利用者は即時更新を 修正対象となっている脆弱性は以下の通りだ。 CVE-2025-43859：　リクエストスマグリングの脆弱性。Python製のHTTP/1.1ライブラリー「h11」において、チャンク転送エンコーディング処理の際に行終端子の検証が不十分である問題が存在する。悪意あるユーザーが細工したリクエストを送信すると、プロキシサーバとh11ライブラリー間でHTTPリクエストの解釈に不整合が生じ、意図しないリクエストを通過させたり、セッション情報が漏

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

「美しい」コード 一般に、「美しさ」には主観が多分に含まれる。芸術作品であるとか、俳優さん女優さんに対して使う場合は特にそうだろう。しかし、こと数学の証明だとかコーディングといったものに対して使用される場合、そうしたものたちは基本的に一定のルールに従っていることがほとんどだ。 「美しい」コードとはどんなもの？ 美しいコードは読みやすい。 どのファイルにどの機能の関数があるか分かりやすく、保守性が高い。 そうであるから、1週間後・1ヶ月後の自分がみてもすぐその内容を思い出せるし、何より他人に見せても恥ずかしくない。 「美しい」コードを書くために では、自分も他人も読みやすいコードはどんなルールに従っているのだろうか？ pythonを使用したAI系の研究とかデータサイエンス的な場合に満たすべき、基本的なポイントを整理しておく。 モジュール化 まずはコードを書く以前のディレクトリ構造の話だ。何も

Semantic Chunker is a lightweight Python package for semantically-aware chunking and clustering of text. It’s designed to support retrieval-augmented generation (RAG), LLM pipelines, and knowledge processing workflows by intelligently grouping related ideas. Traditional chunking methods for LLM pipelines often rely on fixed-size windows or naive text boundaries, which can fragment meaning, split u

本記事では、Python の with 文を起点に、多言語の with に相当する概念を横断的に比較し、 リソース管理という "地味だけど重要" なテーマ を一気に理解できるように整理しました。 「〇〇をしたら必ず △△ する」 をコードで保証する ── リソース管理とは？ A. 「そのタスク終わったら Slack で私に連絡してくださいね！」 B. 「はい、わかりました！」 (数日後...) A. 「あれ、Slack で連絡来てないな。」 B. 「違う仕事していたら、Slack で連絡するの忘れてました！」 そんな経験、ありませんか？ 「〇〇をしたら絶対にこれをやる」ということを強制する。 それを実現するのが、Python の with 文です。 〇〇をしたら絶対にこれをやるというのは、 例えばファイルを open したら必ず close をするなどのリソースに対して行うことは特に多く、

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Python 入門100本ノック まえがき 背景 私は新入社員の研修課題として Python の練習問題を探していました。 しかし、ちょうど良い課題はなかなか見つかりません。 というのも、教育担当の立場からしても新人研修は難しいのです。 そもそも新人教育に使うことのできる時間が限られている。 新入社員が自力で進められるように、練習問題だけでなく説明も充実させる必要がある。 新入社員の力量に応じて研修内容を調整したい。 ということで、一般公開可能な Python 練習問題を作成しました。 新人教育に限らず、これから Python を学ぶ方

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? データの可視化や業務の自動化が進む中、Excelファイルに埋め込まれた画像（グラフのスナップショット、製品写真、ロゴなど）は、多くの重要な情報を担っています。これらの画像を手動で抽出するのは手間がかかり、複数ファイルを扱う場合は非効率です。Pythonスクリプトを活用することで、Excel内の画像を自動的に抽出・保存でき、アーカイブ、レポート作成、画像処理など幅広い用途に活用できます。 本記事では、Pythonを使ってExcelファイル内の画像を抽出・保存する方法をご紹介します。 使用ライブラリ：Free Spire.XLS for P

DuckDB を利用してベクトル検索と日本語全文検索の両方を同時に利用できます。さらにこれらの結果をマージして Reranking を行うことでハイブリッド検索をサクサクっと実現する事が​できます。 Rerankerどうやらベクトル検索した結果と日本語全文検索した結果をマージして、クエリーとマージ結果を再度ランキング付けする仕組みのようです。 ここでは参考にした記事を共有する程度にしておきます。 日本語最高性能のRerankerをリリース / そもそも Reranker とは? - A Day in the Lifeリランキング モデルによる RAG の日本語検索精度の向上 - NVIDIA 技術ブログ今回は Reranker に hotchpotch/japanese-reranker-cross-encoder-large-v1 を利用しました。 以下は参考コードです。 [projec

DuckDB-VSS と PLaMo-Embedding-1B を利用することで、ベクトル検索を実現できますが、DuckDB-FTS (Full-Text Search) と形態素解析ライブラリである Lindera を組み合わせて日本語全文検索を実現できます。 DuckDB-FTS + LinderaDuckDB の全文検索拡張は日本語には対応していないないのですが、スペース区切りでトークン化することで、日本語の全文検索を利用する事が出来ます。トークン化には Meilisearch にも利用されている信頼と安心の Lindera を利用することにしました。 今回この参考コードを Lindera の作者であり検索の専門家でもある Minoru OSUKA 氏にレビューいただきました。本当にありがとうございます。 以下は参考コードです。 [project] name = "duckdb-ft

Pandas が登場してから Python はデータ分析の事実上の標準言語になりました。 しかし、データ量が数千万行を超えると途端に RAM が足りない・処理が遅い という現実にぶつかります。 クラスタ環境に逃げる選択肢もありますが、準備・コスト・学習コストを考えると “ちょっと重い” だけのデータに対してはオーバーキルです。 そこで登場するのが Dask。 以下 3 点が現場エンジニアにとって大きな魅力です。 API 類似度 90 %: 既存の Pandas/NumPy 知識をそのまま使える。 遅延評価 × 並列化: PC のコア数を自動で使い切り、メモリフットプリントを抑制。 スケールラインが滑らか: ローカル PC → 分散クラスタへ“ほぼ同じコード”で移行可能。 今回は「大量 CSV を集計する」という 典型的に重くなる処理 を通して、Dask がどのように恩恵をもたらすかを見てみ

My previous article recommended that one should reconsider using Python in production. However, there’s one category of use case where Python is the dominant option for running production workloads. And that’s data analysis and machine learning. Almost all bleeding-edge work in data analysis and machine learning, especially around LLMs, happens in Python. So, here are some of my learnings on how t

はじめに こんにちは、株式会社STAR AIでデータサイエンティスト兼人事をしている本田です。 LLM（大規模言語モデル）を活用したサービスやプロジェクトを考える上で、モデルの出力をどのように制御するかは非常に重要なポイントです。 何も指示を与えずに質問などを入力すると、LLMは自由記述の形式で回答を返してきます。これでは、情報の整理や再利用が難しく、ビジネスでの活用には不向きです。もちろん、プロンプトエンジニアリングによってある程度の出力制御は可能ですが、ノウハウが必要であったり、質問文などの入力が変動することで指示がうまく通らないこともあります。結果として、毎回同じ形式での出力を安定して得るのは難しいというのが現状です。 そこで今回は、OpenAIのAPIを活用して、LLMの出力を構造化データとして制御・取得する方法をご紹介します。 プロンプトの工夫だけに頼らず、より確実に出力フォーマ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは。もんた。です。 新しい試みとして、私がゼロベースから「完全に理解した」領域までのプロセスをそのまま記事にしたら「そのトピックを理解できる」かつ「記事いっぱい書いててなんかすごいやつ」という一石二鳥かませるんじゃね？これイノベーションじゃね？と思ったの始めてみます。 これはなに この記事は私がpytestの理解がゼロの状態から「完全に理解した」領域に至るまでのプロセスをまとめたものです。 この記事を読んで私と一緒にpytestを理解していきましょう。 はじめに：pytestとは？ はじめに：ソフトウェア品質の要 🛡️ - テ

【問題】 以下のhandle_command関数では、if文の中で変数commandの値に応じて処理を分岐するようになっている（ただし、サンプルコードなのでここでは処理は単純にprint関数を呼び出すだけ）。このくらいなら問題ないが、コマンドの数がもっと増えると、このif文は長大なものになることが予想される。もっと見やすくスッキリとしたコードに書き換えてみよう。ただし、match文は使わないものとする。 def handle_command(command): if command == 'go': print('go straight') elif command == 'right': print('turn to right') elif command == 'left': print('turn to left') elif command == 'back': print('g

本業はSRE, 相変わらず野球関係の趣味開発（個人開発）をしている者です. 今まで趣味開発におけるPythonのPackage Managerはpoetryを使っていましたが, 仕事で使っている&その他の理由でuvに変更しました. github.com このブログではそんなuvの話を書きたいと思います. このブログについて TL;DR 移行の背景とメリット 学習コストの低さ パフォーマンスの向上 移行で苦労した&変更した所 pyproject.tomlの書き換え コードチェックをruffに変更 GitHub Actionsの移行 主な変更点 設定ファイルの比較 移行の手順 結び おまけ - Cursorはどこまでブログを書いたか このブログについて 弊ブログ「Lean Baseball」では初の試みとして, 執筆の大半をCursorで行っています*1. なお以下については中の人（shiny