はてなブックマーク

時系列モデルを扱う上でデファクトスタンダードになりそうなPythonライブラリが出てきました。 時系列モデルを扱うPythonライブラリは、 scikit-learn のようなデファクトスタンダードなものがありません。そのため時系列モデルを用いて実装を行うためには、様々なライブラリのAPIなどの仕様を理解しつつ、それに合わせてデータ整形を行い、評価する必要があり、これはなかなか辛い作業でした。 スイスの企業 Unit8 が今年(2020年)6月末に公開した Darts はまさにこういった課題を解決するライブラリです。時系列に関する様々なモデルを scikit-learn ベースのAPIで統一的に扱うことができます。 github.com Darts は現在、下記のモデルに対応しています。内側では statsmodels 、 Prophet(stan) 、 Pytorch などを使っていて、

pandas はデータ解析やデータ加工に非常に便利なPythonライブラリですが、並列化されている処理とされていない処理があり、注意が必要です。例えば pd.Sereis.__add__ のようなAPI(つまり df['a'] + df['b'] のような処理です)は処理が numpy に移譲されているためPythonのGILの影響を受けずに並列化されますが、 padas.DataFrame.apply などのメソッドはPythonのみで実装されているので並列化されません。 処理によってはそこがボトルネックになるケースもあります。今回は「ほぼimportするだけ」で pandas の並列化されていない処理を並列化し高速化できる2つのライブラリを紹介します。同時に2つのライブラリのベンチマークをしてみて性能を確かめました。 pandarallel pandaralell はPythonの m

機械学習のモデルを学習する、あるいは推論APIを作成するにあたってSageMakerはとても便利ですが、 定期実行する機能をSageMaker自身では持っていない という問題があります。 このエントリでは、Serverless Framework(以降、Serverless)を使って素早くSageMakerの定期実行環境を構築する方法を紹介します。 以下が構成図です。 この環境を構築は、下記を前提としているのでご留意ください。 VPC、サブネットは既に作成しているものを利用する 学習用のデータはこの環境以外からアップロードされる またコードはすべて以下のリポジトリにアップロードしており、これをベースに説明をしていきます。 github.com 環境 serverless framework: 1.49.0 sagemaker(Python SDK): 1.35.0 boto3: 1.9.1

2019年9月16日/17日に開催されたPyCon JP 2019で自分が直接/YouTubeで聴講したセッションについてのまとめです。主に下記の内容を書いています。 スピーカーURL 配信動画 スライド 発表内で出てきたライブラリなどのURL 自分の感想 「あのセッションで話していたライブラリなんだっけ」と思い出したい方やざっくり内容が知りたい方に読んでいただければ幸いです。PyCon JPに自分も発表者としても参加し、スタッフとして参加し、Webサイトの開発もしたので、それについては改めて書きたいと思います。 pycon.jp PythonとAutoML / 芝田 将 スピーカー: https://twitter.com/c_bata_ 動画: https://www.youtube.com/watch?v=Whkwu46DgBs スライド: https://www.slideshar

Nuxt開発の小ネタです。環境変数を開発環境/本番環境で切り分けたいときにどうすればよいか、わからなかったのでメモしておきます。 環境 [email protected] [email protected] @nuxtjs/[email protected] dotenvモジュール nuxtのdotenvモジュールを使います。 github.com インストールは下記コマンドで行ってください。 $ npm install --save @nuxtjs/dotenv # yarn add @nuxtjs/dotenv .envファイル作成 それでは環境変数を設定するファイルを作成していきます。 configディレクトリを作成し、 .env.dev と .env.prod のように環境ごとにファイルを作成します。 config ├── .env.dev └── .env.prod それぞれのファイルに環境変数を記載します。 con

AWS Lambdaで行えないような重い処理はAWS Batchを使うと簡単に行うことができますが、定期実行したりエンドポイントを作る仕組みはAWS BatchにはまだなくCloudWatchやAPI Gatewayと組み合わせる必要がありますがServerlessと組み合わせることで簡単に実現できるので紹介します。 つくるもの 今回は次のサンプルを作ってみます。 毎日AWS Batchで実行する定期バッチ AWS Batchを実行するAPI 環境 serverless: 1.41.1 aws-cli: 1.16.144 ファイル構成 最終的なファイル構成は次のようになります。 AWS Batchに関するファイルだけフォルダを分けています。 tree -L 2 ├── batch │ ├── app.dockerfile │ ├── ecr_deploy.sh │ └── sample.p

Hacker NewsとRedditでバズっていたPythonのデバッグツールが便利だったので紹介です！ PySnooperというライブラリです。 Hacker News - PySnooper: Never use print for debugging again Reddit - PySnooper: Never use print for debugging again ※追記 想像以上にたくさんの方に読んでいただき、printデバッグなど他のデバッグ方法との比較について追記として文末に補足しました。釣りタイトルですみませんでした…🙇 何ができるライブラリか 一言で言うと「デバッグがめちゃくちゃ簡単にできるライブラリ」です。 github.com 例を見たほうがわかりやすいと思うので見てみましょう。 インストールは pip で行えます。 pip install pysnooper

TL;DR AWS Secrets Managerで秘密鍵JSONファイルなどを簡単に扱うことができます。 1つのユースケースとしてこの記事ではGCPの秘密鍵を扱います。 GCPのSDKに読み込む方法も解説します。 はじめに CI/CDでアクセスキー/シークレットキーなどの秘匿情報を扱う際に環境変数を使っている方も多いと思います。しかし、GCPの認証キーはjson形式で環境変数として扱うのが大変です。 そういった場合、AWS Secrets Managerを使うことで簡単に様々なデータ形式の秘匿情報を扱うことができます。また暗号化も行ってくれるので環境変数を用いるより安全に管理できます。 この記事ではAWS Secrets Managerの設定方法とPythonのSDKから呼び出し、GCPのSDKに設定する方法を紹介します。GCPのSDKにどう読み込ませたらいいのか、迷ったのでそのメモでも

TL;DR アウトオブコア、かつマルチコアでデータ処理を行えるVaexの紹介です。 string関係のメソッドで平均して100倍以上の高速化が確認できました。(作者のベンチマークだと最大1000倍) 文字列処理以外でも数倍~数十倍の高速化が行えそうです。 この記事では性能の比較のみ行い、解説記事は別で書こうと思います。 pandasより1000倍早いフレームワーク？ 今週、興味深い記事を読みました。重要な部分だけ抜き出すと次のような内容です。 Vaexの最近のアップデートでの文字列処理が超早くなった 32コアだとpandasと比べて1000倍早い towardsdatascience.com 1000倍って本当なの？って感じですよね。そもそも自分はVaex自体を知らなかったので調べてみました。 ちなみに調べていて気づいたのですが、この記事の著者はVaexの作者なんですよね。 疑っているわけ

この記事は Serverless2 Advent Calendar 2018 - Qiita の20日目です。 今年開催された re:Invent2018でAWS Lambda Layersが発表されました。 このアップデートによってC拡張のライブラリや容量の大きいライブラリの利用がより便利になりました。 その中でも特に自分が最初に「使ってみたい！」と思ったHeadless Chrome on Seleniumの使い方を解説します。 自分が普段使っているServerless Frameworkは既にAWS Lambda Layersに対応しており、これを使ったやり方になります。 最終的なフォルダ構成＆Versions ここから作業していきますが、先に最終的なフォルダ構成を書いておきます。 tree -L 2 ├── lambda # Layerを使うアプリケーションのディレクトリ │ ├─

この記事は Python その2 Advent Calendar 2018 - Qiita の1日目です。 responderとは GitHub - kennethreitz/responder: a familiar HTTP Service Framework for Python 2018年10月に公開された イケてるPython WebFramework です。 requestsやpipenvなどの開発者である Kenneth Reitz が(おそらく)今年のHacktoberfest 2018 - DigitalOcean 用に開発したものだと思われます。 GitHubのタグを見ると(Topic: hacktoberfest2018 · GitHub )、hacktoberfestで2位 今年10月に公開されたのに関わらず既にStarが2000以上付いており、かなり勢いがあります

命名はソフトウェア開発において、全開発者が毎日行う重要な作業です。モジュール名、クラス名、変数名など様々な種類の命名を考えなければいけません。 私はテックリードとして働いているので、チームメンバーが命名に苦戦している場面を良く目にします。命名に関するプラクティスはたくさんあるのですが、まだ紹介されているのを私は見たことがないプラクティスを紹介したいと思います。と、書くとイノベーティブなプラクティスを書くように思われるかもしれませんが、すみません、そんなことはありません。恐らくある程度経験を積んだ開発者はみんなやっていることかと思います。 そのプラクティスは「検算」です。 なぜ検算が必要かというと、命名が上手くいっていない方の多くが、実態からのみ命名をしてしまっているからです。検算というのは、この逆向きを確認することを言っています。つまり「命名から実態を引けるか」という確認です。私のプラクテ