The Little Book of Julia Algorithms: A workbook to develop fluency in Julia programming
ついに待ちに待ったJulia 1.6がリリースされたのですが、
Julia1.6で導入された新機能に関して調べながら、
Twitterでメモを取ったのでまとめておきます。
続きを読む
各プログラミング言語において、short circuit evaluationができるか試してみました。
続きを読む
これまで、自分はPythonのユニットテストには、
PythonのデフォルトのUnitTestsを使っていましたが、
自分がコントリビュートしているPython OSSの殆どが
pytestというテストフレームを使っていたので、
気になって調べてみました。
下記は、これまでPythonデフォルトのUnitTestsを使ってきた自分が、
pytestを使ったほうが良いなと思った7つの項目です。
UnitTestsはJavaのユニットテストフレームワークである
JUnitをベースとして開発されているため、
テストを作成する時に毎回UnitTestsクラスを継承した
テストクラスを作成する必要があります。
一方、pytestの場合、クラスは作る必要がなく、
test_*.py または、*_test.pyというファイルに、
test_*という名前の関数をさえ作れば、
pytestが勝手にその関数を検索して、テストとして実行してくれます。
これにより、テストを書く敷居がかなり低くなり、
テストを書きやすくなると思います。
UnitTestのテストは、assertTrueやassertEqualなど、
様々なassert関数を使ってテストを作成しますが、
どのようなassert関数使うべきか覚える必要があります。
pytestでは、Pythonのデフォルトキーワードである
assert文を使って、条件を書くことによりテストを評価します。
これにより、すべてのテストコードを一貫性をもって、
作成することができると思います。
UnitTestsで作成したテストが失敗した場合、
そのテストが失敗したことはわかりますが、
なぜそのテストが失敗したのかは、
テストの結果をみるだけではわかりにくいと思っていました。
一方、pytestの場合、
下記の公式ドキュメントにあるように
失敗したテストに関しては、
それぞれの値がどのような値であったせいで、
テストが失敗したのかをわかりやすく表示してくれます。
加えて、コマンドライン引数で設定することにより、
テストが失敗したときに定義されていた
それぞれの変数の中身なども表示することができ、
再度テストを実行しなくても、
テストのログだけで、ある程度のデバックができるようになっています。
UnitTestsにも、自動的にテストコードを検索して、実行する
auto discovery機能がありますが、
pytestにauto discoveryはより一層使いやすく、高機能だと思います。
例えば、
$ pytest
とタイプすることで自動的にcurrent directory以下のテストを検索してくれますが、
検索するディレクトリを指定したり、
あるテストファイルの一部のテストのみ実行したり、
テスト名の部分一致で検索して実行なども
すべてコマンドライン引数を設定することで可能です。
pytestには、プラグイン機能があり、
様々な便利な追加機能のためのプラグインが公開されています。
例えば、
マルチスレッドや分散処理でテストを並列実行するpytest-xdistや
文法/コードスタイルチェッカーであるpyflakesを実行するpytest-flakes
コードカバレッジを確認するpytest-cov
などがあります。
これらのプラグインは、それぞれpipでインストールでき、
あとは必要な設定やデータをpytestのオプションに指定すれば
それぞれの機能を利用可能です。
pytestは、Pythonのデフォルトのテストフレームワークである
unittestで作成されたテストも実行可能です。
これにより、すでに沢山のUnitTestsベースのテストが存在している
プロジェクトにおいても、pytestで既存のテストを実行しつつ、
少しづつ、pytestのテストに置き換えていくことができます。
また、UnitTestsベースのテストが失敗したときも、
pytestで実行した場合、わかりやすく失敗した理由を表示してくれます。
--duration=0というオプションを使うことにより、
簡単にテストの実行時間の遅いものからランキングリストを作ってくれます。
下記は自分のOSSの場合の出力例です：
上記のように、簡単にどのテストが失敗しているのかわかり、
そのような遅いテストを改善したり、
テスト対象のコードそのものを改善することができます。
| コマンドライン引数 | 機能 |
|---|---|
| -l | トレースバックとともにローカル変数も表示 |
| -v | すべてのテスト名とその結果を表示 |
| --lf | 前回失敗したテストだけを実行 |
| -x | 最初の失敗したテストでテストを止める |
| -Werror | Warningが出たときもエラーにする |
| --durations=N | テスト実行時間がN秒以下のテストを表示(0に場合はすべて) |
JetbrainsのPython IDEであるPycharmは、
テストフレームワークとして、pytestに対応しています。
下記の公式ドキュメントにある通り、
IDEからテストを実行し、テスト結果をわかりやすく表示したり、
auto discoveryでテストを検索することもできます。
続きを読む
本日、
自分が開発者のメンバーとして参加している
SciPyの新しいバージョン1.6.0がリリースされました🎉
今回は、1.6.0の新機能や特徴を、
連続ツイートでまとめてみたので、
そちらを、あとから参照しやすいように
記事としてまとめておきます。
過去のバージョンの記事は下記の通りです。
続きを読む
PythonやJuliaを使っている人が、
Javaを使うと、
言語のデフォルト機能が足りないなと
思うことがあると思います。
そんな時に便利なのが、
Googleが開発公開しているJavaライブラリであるGuavaです。
Guavaは、Javaのデフォルト機能で実装すると、
コードの量が長くなってしまったり、
バグが入りやすくなってしまうコードを、
簡潔に、バグが入りにくく実装することを
目的に開発されています。
Guavaはかなり古くから開発されているため、
Java8などで導入された機能とかぶっている部分も多いですが、
それでもまだデフォルトの機能にはない沢山の機能が実装されています。
今回の記事では、
Guavaの代表的な機能の概要と
コードサンプルを紹介したいと思います。
すべてのコードサンプルはこちらでも公開しています。
続きを読む
今回の記事は、
数理最適化Advent Calendar 2020の23日目の記事です。
今回の記事では、
数理最適化の基本的な問題の一つである、(線形)割当問題の概要と、
Pythonのライブラリの一つであるscipyを使った解法について紹介したいと思います。
続きを読む
WebSocket: Lightweight Client-Server Communications (English Edition)
以前、通常のHTTPを使った、
簡単なプロセス間通信の方法を記事にしましたが、
通常のHTTPでは、
通信方式request-response型なので、
クライアントがサーバに話しかけないと、
サーバが、クライアントに話しかけることができませんでした。
そこでウェブアプリケーションにおいて、
双方通信によく使われるのがWebSocketです。
今回はこのWebSocketについて概要と
各言語でのサンプルコードを紹介したいと思います。
続きを読む
これまでPythonでやってきたことを、
Juliaで置き換えようとすると、まず初めにぶつかるのが、
Juliaのコードにおけるライブラリのロードや、
初めて使う関数の計算が遅いなど、
いわゆる初回実行が遅い問題が気になってきます。
(英語ではこの問題をlatencyと呼んでいるそうです
)
Juliaは基本的に初回実行時にコードをJITコンパイルして実行するため、
動的言語でありながら、高速な実行を実現できているので、
この初回実行が遅いのはある程度はしょうがないのかなと思います。
しかし、
毎回使うライブラリのロードや
変更が不要な関数が、
毎回遅いのはなんとかならないのかなと思っていました。
そこで、この問題の一つの解決策がPackageCompiler.jlです。
概要はこちらの動画を参照していただけるとわかると思いますが、
sysimageと呼ばれるJuliaのセッション保存機能を使って、
いつも利用するライブラリをロードした状態や、
関数のJITコンパイル結果を保存することにより、
そのsysimageを使って、juliaコードを実行したときに、
初回実行を高速化することができます。
(Julianのsysimageに関しては、こちらを参照ください
今回の記事では、このPackageCompiler.jlとsysimagesを使うことで、
Juliaのコードの初回実行を高速化する方法を簡単に紹介したいと思います。
続きを読む
OSSにとってドキュメントは、
出来るだけ多くの人に使ってもらうために重要です。
近年のOSSでは、
ソースコードと同じgitリポジトリに
テキストベースでドキュメントの元のデータを管理し、
Sphinxや
Documenter,jl
のようなドキュメント作成ライブラリを使って、
htmlベースのドキュメントを自動生成し、
そのデータをインターネット上に公開するのが一般的です。
このようにドキュメントをgitで管理すると、
ドキュメントの改善を通常のコードと同様に
プルリクエストベース(PR)で、レビューして
改善することができます。
このような、
PRベースでドキュメントの変更をレビューするのは便利なのですが、
一つ面倒なのが、
他人のドキュメントのPRをレビューするときに、
そのPRのブランチを手元にチェックアウトし、
ドキュメントをビルドしないと、
最新のドキュメントの見た目などを確認できないことです。
また、レビューの結果を反映した、
各コミット毎にこの作業をしないといけないので
以前から非常に面倒だなと感じていました。
昔からこのフローを改善したいなと思っていたのですが、
最近開発に参加している、SciPyが非常に良い方法を利用しているのに気がつきました。
この方法では、
PRの各コミット毎にCIが回るので、
そのCIの一環として、最新のコードでドキュメントをビルドし、
そのドキュメントをそのままブラウザ上で確認出来るようになります。
もう少し具体的には、
下記のように、PRでコミットすると
GitHubのCIの画面に、
build_doc artifactという項目が表示され、
この項目のDetailsをクリックすると、
下記のように、CIで生成された最新のドキュメントを
ブラウザ上で確認することができます。
これを見ながら、
簡単に最新のドキュメントの結果をレビューすることができます。
今回の記事では、
こちらの設定方法について説明します。
続きを読む
