タグ

pythonと*devに関するsh19910711のブックマーク (20)

  • Python製のシンプルなゲーム開発用ライブラリを作った - Qiita

    崩壊しないシステマティックなゲーム開発がしたい ということで、Python 製のミニマルなゲーム開発用ライブラリ Pigframe を作りました。 主には、Pygame, Pyxel などの Python 製のゲーム開発エンジンを使ってゲームを開発したいと思っている、開発を始めた個人開発者・学習者向けになります。 依存している外部ライブラリはありません。 自分がゲーム開発で使っている/使いたい Pygame や Pyxel などの開発エンジンと併せて使うことを主な用途として想定しています。 さっさと使い方を見たい方はこちら: 日語版 README ◼ 一体全体なにができるの? Pigframe は以下のような仕様を持っています。 機能 対応 備考

    Python製のシンプルなゲーム開発用ライブラリを作った - Qiita
    sh19910711
    sh19910711 2024/06/18
    "Pygame, Pyxel などの Python 製のゲーム開発エンジンを使ってゲームを開発したい / Pigframe: どんなゲーム開発でも共通している(と思う)基本的な機能を提供 / それぞれの System, Event, Screen は単一の処理しか行わない"
  • 【pytest】をFlask+docker開発で初めて使ってみた - Qiita

    Flask + docker-composeでのWebアプリ開発に初めてpytestを使用しました。 その際のテストファイルと、設定内容をザックリまとめました。 親の記事はコチラとなります。 ■Flask+Docker+Vue.js+AWS...でゲームWebAppを作ってみた。 ■Githubにソースコード公開しています テスト書くとこんなに良い事ある 今まで、テストプログラムを避けていた人生でした 偶然ですが、テストを必要としないプロジェクトばかりで使う機会が無かったといえば言い訳ですが、心のなかで「あー、当はテストとか書いといた方が良いんだろうなー」と思いつつも、重い腰が持ち上がらず。。。 そんな方は、私だけでなく多いと思います! 心機一転でテストを書こうと決心したのは、こんなメリットがあります。 テストコードを書くメリット コード変更した際に、挙動確認が簡単&確実になる。 テスト

    【pytest】をFlask+docker開発で初めて使ってみた - Qiita
    sh19910711
    sh19910711 2024/06/17
    "テストを通すことで、チーム内のエンジニア同士で、問題なく動くことのエビデンスとなる / エラーがいつからどこで、おかしくなったのか、把握することが容易 / チーム内のエンジニア同士の仕様の齟齬を無くす" 2020
  • GitHub Actionsでpytestしてカバレッジを出す - Qiita

    個人的備忘録。 やること Github Actionsでpytestを動かして単体テストする。 動作タイミングはpull requestのopen時と、pull requestがopenされたブランチへのpush時 外部APIを叩くテストケースはスキップすることにした 理想的にはAPIを叩くロジックを分離してDependency Injectionすることで、テスト時にはモックAPIが動作するようにするべきとされています 参考: PythonでDependency Injection (DI)をやるには? pytest-covでカバレッジを出して、pull requestのコメントとして投稿する。 Github Actionsの設定 name: Pytest on: pull_request: types: [opened, reopened, synchronize] jobs: tes

    GitHub Actionsでpytestしてカバレッジを出す - Qiita
    sh19910711
    sh19910711 2024/06/16
    "Github Actionsでpytestを動かして単体テスト + pytest-covでカバレッジを出して、pull requestのコメントとして投稿 / パイプを使う場合、pipefailの設定をしないとパイプ後半の戻り値で成功・失敗を判断することになる" 2023
  • GitHub Actions で pytest の失敗箇所をコード中にインライン表示する - Qiita

    GitHub Actions にはテストなどの実行結果を、Pull Requestのコード上にアノテーションされた形で表示する機能があります。Node.js などではこれが自動で行われることがあるためご存知の方も多いかもしれませんが、Pythonでも上手く活用できます。 pytest の結果をコード上に表示する 実は Pytest が公式にそのためのプラグインを提供しています。これをインストールした状態で GitHub Actions で pytest を実行するだけで機能します。 具体的には、以下のようにインストールしておけばいいでしょう。 # pip でインストールする場合 pip install pytest-github-actions-annotate-failures # Poetry に含めておく場合 poetry add -G dev pytest-github-actio

    GitHub Actions で pytest の失敗箇所をコード中にインライン表示する - Qiita
    sh19910711
    sh19910711 2024/06/16
    "GitHub Actions にはテストなどの実行結果を、コード上にアノテーションされた形で表示する機能があり / Node.js などではこれが自動で行われることがある + Pythonでも上手く活用できます" 2023
  • プロンプトを見て、LangSmithのevaluatorを理解する

    はじめに LangSmith langchain.com が提供する LLM アプリ開発のプラットフォームです 2024/02/15 に GA した、今ホットなツールです LangSmith では evaluator を指定することで、様々な評価指標を出力することができます from langsmith import Client from langchain.smith import RunEvalConfig, run_on_dataset evaluation_config = RunEvalConfig( # ここで指定 evaluators=[ "qa", "context_qa", "cot_qa", ] ) client = Client() run_on_dataset( dataset_name="<dataset_name>", llm_or_chain_factory

    プロンプトを見て、LangSmithのevaluatorを理解する
    sh19910711
    sh19910711 2024/06/08
    "LangSmith: langchain が提供する LLM アプリ開発のプラットフォーム + evaluator を指定することで、様々な評価指標を出力 / そのほとんどが LLM 自身による評価 + 「このように評価して」とプロンプトで指示"
  • featuretoolsで特徴量を自動生成して機械学習モデルの構築を楽に早くする手法 - Qiita

    概要 機械学習モデルを作るときに、特徴量を増やすことでモデルの精度を向上させようと試みるタイミングがあります。例えば、学習用データを作成するときに SELECT id, COUNT(hoge) FROM table GROUP BY id みたいに、何かの回数とかの変数を新たに作って追加するといった感じです。 こういった特徴量設計は機械学習の前処理の中でもそこそこに重要な工程であると思っています。 課題 しかしながら、こういった特徴量設計では ドメイン知識がないとうまい変数を思いつかない どのくらいの変数を用意すればよいのか見当がつかない 特徴量生成自体の作業が割とめんどくさい など、重要だけど大変な面もあるという感じになっており、これを できれば特徴量は自動でいい感じに作って欲しい コードをシンプルにしてスッキリさせたい という形で実現できないものかと思うところです。 解決策 以上の課題

    featuretoolsで特徴量を自動生成して機械学習モデルの構築を楽に早くする手法 - Qiita
    sh19910711
    sh19910711 2024/05/24
    "特徴量設計: ドメイン知識がないとうまい変数を思いつかない + どのくらいの変数を用意すればよいのか見当がつかない / featuretools: そこそこのスコア + 深く考えずにサクッとモデルを作ってみたいときに使えそう" 2018
  • Pants で決める python monorepo - ABEJA Tech Blog

    ABEJA で Research Engineer をやっている中川です.普段は論文読んだり,機械学習モデルを実装したり,インフラを構築したりしています.今回のブログでは3,4ヶ月の間遊び9割仕事1割で取り組んできた Python で実装された機械学習マイクロサービスたちの monorepo 化について紹介します. モチベーション 小売業向けに店舗解析ソリューションを提供している ABEJA Insight for Retail では以下のような理由から機械学習システムをマイクロサービスの polyrepo (multi-repo) で運用してきました. 様々なフレームワークで書かれた最新の研究成果を取り入れやすい. 負荷特性の全く異なる機械学習モデルをスケールさせやすい. モデルごとに容易にデプロイできる. 障害耐性や保守性を高め日々の運用負荷を下げる. 手前味噌ですが,マイクロサービス

    Pants で決める python monorepo - ABEJA Tech Blog
    sh19910711
    sh19910711 2022/08/01
    "ビルドツール: 2020年5月時点ではデファクトといったようなツールはなく + 各社OSSとして公開 > Google: Bazel + Facebook: Buck + Twitter: Pants / Pants: Python をネイティブにサポート + 依存関係やテスト結果をキャッシュ"
  • poetryを利用した動的なバージョン管理とGitHub ActionsによるPyPIへのrelease - Stimulator

    はじめに この記事を読んで出来る事 poetryによる外部モジュールバージョン管理 poetry-dynamic-versioningによる動的なバージョン付与 GitHub Actionsを利用したPython周りの基的なCI/CD設定 GitHubのReleaseタグ付与をTriggerとしたPyPIへのアップロード 今後私がPythonで何かライブラリ作ろうと思ったらこれを実施するぞというメモです はじめに poetryによるモジュールバージョン管理 PyPIへのアップロード GitHab Actionsを用いたCI/CD その他GitHubでやること 参考 poetryによるモジュールバージョン管理 バージョンをGitHubのタグで管理したい事の方が多いはず。 setup.pyを利用する場合は、一般的にsetuptools_scmを使うが、poetryはsetup.pyのようにb

    poetryを利用した動的なバージョン管理とGitHub ActionsによるPyPIへのrelease - Stimulator
  • wheelのありがたさとAnacondaへの要望 - YAMAGUCHI::weblog

    はじめに こんにちは、Python界のラファエル・ナダルです。全豪オープンテニス、盛り上がりましたね。さて、先日次のようなエントリーを立て続けに書いたんですが、「なぜAnacondaに関しての記述がないのか」という突っ込みをもらったので、参照用にメモを残しておきます。 Pythonの仮想環境構築 2017.01版 - YAMAGUCHI::weblog Pythonの環境設定でむかついてる人はとりあえずこれをコピペで実行してください 2017.01 - YAMAGUCHI::weblog なおこの記事の作成にあたっては @aodag に数多くのアドバイスをいただきました。この場を借りて感謝。 TL;DR condaの開発者はPyPAともっとコミュニケーションとってほしい。 前提 この記事はPythonを触り始めたばかりだけど、パッケージ管理ツール等々のスタンダードがどのようになっているかな

    wheelのありがたさとAnacondaへの要望 - YAMAGUCHI::weblog
  • GitHub - pypa/pipfile

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - pypa/pipfile
  • CPython の Core Developer になりました - methaneのブログ

    Python 3.6 に取り込まれた dict の新実装などでコアコミッターに興味を持ってもらい、 Core Developer (要するにコミッター) に推薦しようか?という提案をもらいました。 最初はコミッターとか面倒そうだし、コミットメッセージとかNEWSエントリー(通常パッチをコミットするときにコミッターが書く)とかを英語で書くのも英語が得意な人がやったほうがいいだろうし、とりあえず github に移行するまでは様子見しておこうと思ってたのですが、 dict 関係のパッチがいくつもレビュー待ちでなかなかコミットされないのを見て「やっぱりアクティブなコミッターが全然足りてない」と考え直し、志願することに。 で、先月末にコミット権をもらった(というか push できる権限を持った hg アカウントに ssh 鍵を登録してもらった)のですが、新米コミッターは簡単なパッチでも他のコアコミ

    CPython の Core Developer になりました - methaneのブログ
  • Landscape.io Blog

    It has been more than seven years now since I started making Landscape: Author: carlio <git@carlcrowder.com> Date: Wed Jan 30 08:42:29 2013 +0100 Initial commit What started as scratching my own itch - I wanted something like SonarQube but for Python. I really worked hard to make … more ... Now that 2016 has shuffled off this mortal coil and we can all take a breather and see what 2017 brings us,

  • 今どきのPythonのライブラリ自作からPyPIへの登録 - Qiita

    自分のライブラリをPyPIに登録したい ...が、PythonにはRubybundlerのようなものが なく、(合ったとしても統一されてないと思う) プロダクト別に自由なディレクトリ構成になっている状態... せめて自分のプロダクトについては統一したいなあと思ったので Pythonのライブラリを作る場合のディレクトリ構成や 環境構築などについてメモを書く。忘れちゃうので... 利用するPythonのバージョンは3.3以降を意識してる。 それより前(3.2, 3.1...2.x)は考慮しない。問題無いと思うけど... テスト目的で作成したライブラリ fizzbuzzというアレなライブラリを作った。 ライブラリというかコマンドラインツールだけれど。 このライブラリの構成を元に、メモを書いていく。 ライブラリのディレクトリ・ファイル構成 以下のディレクトリ・ファイル構成とする。 fizzbuz

    今どきのPythonのライブラリ自作からPyPIへの登録 - Qiita
  • BitbucketのPrivate repositoryをタダでCIする - Qiita

    概要 BitbucketはタダでPrivate repositoryをつくれるので、運営しているwebサービスのソースなど公開しちゃうのはちょっと。。。というものを預けるのに便利です。最近はTravis-CIなんかがあって、サーバを立てなくてもCI出来たりしますが、githubしか対応していなくて涙目でした。 今回、CloudBeeを使ってリポジトリからCIまで無料な環境を作ったのでそのまとめです。 アプリケーション構成 細かいものは他にもありますが、テストに関係しそうな構成はだいたいこんな感じ Python (2.7.2) MongoDB web.py nose coverage mongomock pep8 前提条件 ユニットテストの外部依存は面倒で嫌いなので、MongoDBやその他入出力を伴うテストは全てMock化しています。若干バグ(というか機能不足)ありますが、mongomock

    BitbucketのPrivate repositoryをタダでCIする - Qiita
  • エキPy読書会 14 (2011/7/5)

    エキPy読書会 14 (2011/7/5)¶ 日時: 2011/7/5 19:30 - 22:00 範囲: 第11章(p295~): テスト駆動開発 エキスパートPythonプログラミングの読書会14回目。 テスト駆動開発について。原則とテストの種類、スタブ、モック、ドキュメント駆動開発などについて。 相変わらずを読まない読書会、どころか、話があちこちに派生したためとかもうどうで(ry 次回はモックとかのあたりから続きです。 会場の様子¶ 今回は会議室いっぱいに集まりました。 質疑応答(覚えてる範囲)¶ Q: テスト自身のバグとかってどう防止するのー? テストしやすい切り出し方をして人間の目で判断するのー? 複雑な入力と出力のテスト対象だと、勘違いすることもあるのでは? Web だと、モデルのテストはがんばるけど、ビューのテストは適当に流すとか。 domain specific な部分

    エキPy読書会 14 (2011/7/5)
  • oreilly.com

    More than 5,000 organizations count on our digital courses and more to help their teams learn the tools and technologies that drive business outcomes. We can help yours too. New AI policy for O’Reilly authors and talent O’Reilly president Laura Baldwin shares the company’s ethical approach to leveraging GenAI tools and ensuring O’Reilly experts are compensated for their work. Read it now It’s time

    oreilly.com
  • サイボウズのPython コーディング規約 11 カ条 - Cybozu Inside Out | サイボウズエンジニアのブログ

    ymmt2005 こと山泰宇です。こんにちは。 cybozu.com のインフラ開発チームでは仕事のかなりを Python でこなしています。 Python を選んだ理由は以下の通りです。 便利だから Python には "batteries included" と呼ばれるほど豊富な標準ライブラリが整備されています。例えば HTTP で通信するとか、JSON データを読み込むといった良くある仕事のためにいちいち外部ライブラリを探さなくていいのです。 堅いプログラミングができるから 例外やモジュールといった現代的な機構が備わっているので、ベターシェルスクリプトとして使うのに適しています。 書き方にバリエーションが少ないから チーム開発では他の人が書いたコードを手直しすることは良くあります。書く人によって書き方がいくつもあるような言語より、レビューや修正がしやすいと考えています。 標準的に使

    サイボウズのPython コーディング規約 11 カ条 - Cybozu Inside Out | サイボウズエンジニアのブログ
  • パフォーマンス解析に関するまとめ - Risky Dune

    ここ2日ぐらい調べたパフォーマンス解析に関する調査をまとめる. 推測も含まれているので注意. まず, 当初の目的は「Boost.Pythonを用いて作った共有ライブラリをPythonから呼び出した際のボトルネック(hot spot)を発見したい」だった. パフォーマンス解析ツールをいくつか調べたところ, 次のような候補が考えられた. oprofile google-perftools perf sprof 求める条件は「共有ライブラリの解析ができること」と「call graphをvisualizeするkcachegrind形式のデータを出力できること」の2点である. 結局は, google-perftoolsを使ってめでたしめでたしなのだが, その過程で調べたことをまとめる. sprof この記事によるとgprofはshared libraryの解析には使えないらしいので, sprofの使

    パフォーマンス解析に関するまとめ - Risky Dune
  • Ginkgoでテストを書く - 箱が…

    みんな大好きgeventをベースにした、daemonを書くためのフレームワークGinkgo(repo)でテストを書く方法について。 Ginkgoについての軽い説明 0.5.0devのドキュメントを読めばわかるんですが、Ginkgo(ギンコ?)は纏まった1つの機能を Service と呼び、Service の中には複数の子Serviceを持てるようになっています。 Service はこんな感じで書きます。 # 1秒毎にコンソールに Hello World と表示し続けるサービス # http://ginkgo.readthedocs.org/en/latest/user/quickstart.html#hello-world-service からのコピペです from ginkgo import Service class HelloWorld(Service): def do_start(

    Ginkgoでテストを書く - 箱が…
  • Mercurial - Wikipedia

    Mercurial (マーキュリアル) は、ソフトウェア開発者向けの分散型バージョン管理システムである。Microsoft Windows、FreeBSD、MacOSLinux等の Unix 系システムでサポートされている。GPL v2+ [3] の条件の下でフリーソフトウェアとしてリリースされている。 Mercurial はシンプルな概念の下、次のものを主要な設計目標としている。 分散型 VCS 完全分散型の共同開発 高いパフォーマンス スケーラビリティ プレーンテキストファイルとバイナリファイル両方に対する堅牢な処理 高度な分岐 マージ機能 Mercurial は主としてコマンドライン駆動のプログラムである。Mercurial のすべての操作は、そのドライバープログラム hg への引数として呼び出される。(hg というプログラム名は、英: mercury が水銀を意味しその元素記号が

    Mercurial - Wikipedia
  • 1