SciPyで線形計画問題を解く

Pythonの数値計算ライブラリ SciPy には線形計画問題を解くための scipy.optimize.linprog という関数が存在します。 この関数を使って、線形計画問題を実際にといてみます。 例として次のような線形計画問題を考えましょう maximize subject to 目的関数の右辺に -1 をかけて、目的関数の最大化を目的関数の最小化に変えます。 minimize これを行列で表します。 あとは、行列をリストで表現し、SciPyプログラム(linear-prog.py)に落とします。 実行します。 linprog関数の引数で {“disp”: True} にしていると のブロックのメッセージが表示されます。 “Optimization terminated successfully.” というメッセージからわかるように、問題は無事とけました。 出力結果をもう少し詳しく見てみましょう。 status: 0 最適化の終了ステータスです。 最適解を見つけられると 0 になります。 指定されたイテレーション内にとけないなど、とけなかった時は1以上の値になります。 slack: array([ 0., 0., 4.]) 制約の不等式を等式標準形に直します。 subject to 目的関数が最小値を取るとき、このスラック変数 x_3, x_4, x_5 はそれぞれ 0, 0, 4 の値を取ります。 fun: -18.0 目的関数の最小値です。 x:

tornadoでWebSocketサーバを動かしてみる

Tornado で HTTP サーバを用意 HTML ファイルの JS が WebSocket サーバと通信 ブラウザでこの HTML ファイルを表示。 WebSocket クライアントが WebSocket サーバにメッセージを送信すると、HTML が書き換わる というようなシナリオを実現するシンプルなデモを作ってみました。 WebSocket Server サーバには表題の通り Python Tornado を利用します。 パッケージのインストール Tornado のビルドには Python のヘッダーファイルが必要です。 以下は RedHat 系でのインストール例です。 コード クラス Tornado.websocket.WebSocketHandler を継承して WebSocket サーバを実装します。 WebSocket サーバがメッセージを受け取ると、 on_messege ハンドラーが呼びだされます。 HTML/JS ファイル WebSocket 用の JavaScript は HTML ファイル内にベタッと書きます。 WebSocket クライアント送信されたメッセージは の箇所に反映されます。 WebSocket

AWS CLIにオレオレwaitコマンドを追加する

aws cliには API 呼び出し後、特定のステータスになるまでポーリングする wait コマンドがあります。 例えば ec2 インスタンスを起動する API を呼び出し後、インスタンスの起動が完了するまで待つには $ aws ec2 wait instance-running –instance-ids xxx のようにします。 この wait 機能が実装されるまでは というように、ポーリング処理を自前で実装しなければいけ ませんでした(例外処理も真面目にやるとさらにごちゃごちゃする)。 この wait 系コマンドを独自追加する方法をメモ。 cloudformationでスタック構築完了を待つ 例として cloudformation でスタックの作成APIをたたいたあと (crete-stack)、スタックの構築が完了するまでポーリングするコマンド $ aws cloudformation wait stack-completed を実装してみましょう。 AWS CLI で wait を使わず cloudformation のスタックを構築 wait を使わずに cloudformation のスタックを構築するには $ aws cloudformation create-stack –stack [STACKNAME] でスタックの作製命令をし $

[Python]Clickでコマンドラインアプリケーションを作る

Python でコマンドラインプログラムを書くときのライヴラリに Click というのがある。(キャッチコピーは “Command Line Interface Creation Kit”) “The Hitchhiker’s Guide to Python” の “Command-line Application” でも CLI 用のライブラリとして clint などとともに取り上げられている。 作者の @mitsuhiko が YouTube に “Building Command Line Applications with Click” という20分弱の動画を投稿している。 固定メッセージを返すシンプルなアプリケーションを少しつづ拡張していき、最後には git 風のサブコマンドを実装する。 勉強がてら書き起こしてみる。 動画が公開されたのは Click の初回リリース間もない頃だけれど、Click の基本設計は変わっていないので、2015年3月末リリースの 最新版 0.4 でも読み替え無しに動作した。 プロジェクトの作成 virtualenv で環境構築する プログラムの作成 hello で呼び出せる CLI プログラムを作成。 CLI インストールする

Ansibleのコールバックプラグインを使ってみる

Ansible にはコールバックプラグインというのがあり、プレイブックの実行終了や異常終了などの各種イベントをフックして特別な処理を仕掛けることができる。 なかなか便利な機能だと思うけど、ポインター的なドキュメントしか存在せず、自分でコールバックプラグインを作りたければ、既存のプラグインのコード読めみたいな書き方しかされていない。 プレイブックを実行し、hipchat コールバックプラグインでチャットループに実行結果を通知するところまでをメモ。 ping するだけのプレイブックの作成 まずは Ansible プレイブックの作成。 localhost に対して ping を実行するだけのプレイブックを作成する。 hosts ファイル プロビジョン対象。 今回はローカルホストに対して実行する。 ping するだけのプレイブック ping モジュールを呼び出して、ターゲットに ping を実行する。 プレイブックを実行 面白くもなんともないが、プレイブックは無事実行終了。 コールバックプラグイン連携 次に hipchat のコールバックプラグインと連携し、hipchat のチャットルームにプレイブックの実行結果を通知させる。 hipchat の API を取得 hipchat 管理画面から Group Admin -> API とたどり、API TOKEN を発行する。 Ansible のコールバック設定 設定ファイル ansible.cfg でコールバックプラグインの場所を指定する。 今回は /tmp/callback_plugins/ 以下とする。 ansible.cfg ファイルは ANSIBLE_CONFIG

rsyslogのアウトプットプラグイン機能(omprog)を使ってみる

概要 rsyslog のアウトプットモジュールには omprog というのがあり、好きな言語でsyslog データを標準入力で受け取り、データを処理するプラグイン機構がある。 この機能は rsyslog 4.3.0 と結構昔から存在するにもかかわらず、自分は知らなかったのだけど、rsyslog のブログでこの機能を知ったので、ミニマムで動かすところまでを試してみた。 Writing external output plugins for rsyslog # omprog は v4 のころからあるのに with v8, we officially support external plugins とコメントされているのは突っ込まないでおく。 検証環境 OS : CentOS 6 rsyslogd 8.2.2 rsyslog external plugin 通常のモジュールは、アウトプットを例にすると ローカルのファイルシステムに出力に出力する omfile や MySQL に保存する ommysql など プログラムは C で記述され rsyslog のプロセスの一部として処理されていた 一方で、external plugin

[Python]cramテストをsetup.pyから実行させる

最近利用した Python ライブラリでは cram を使ってテストがかかれてあり、setup.py からテスト実行できるようになっていた。ミニマムな実現方法をメモ。 cram とは URL : https://bitheap.org/cram/ 一言でいえばコマンドラインの実行結果をテストする機能テストツール サイトから引用すると Cram is a functional testing framework for command line applications based on Mercurial’s unified test format. Cram tests look like snippets of interactive shell sessions. Cram runs each command and compares the command output in the test with the command’s actual output.

tornado.IOLoopのシングルトン実装

非同期ネットワークフレームワークの tornado では I/O イベントループ(IOLoop)を用意し、イベントドリブンに処理する。基本的に、1 プロセス 1 イベントループのため、各操作はグローバルに同じインスタンスをあつかうように、IOLoop はシングルトンパターンで実装されている。 どういうふうに実装されているか、確認してみた。 実装 tornado/ioloop.py の IOLoop クラスは、次のような感じになっている IOLoop クラスのコンストラクターにシングルトンのロジックは含めず、インスタンスを返すスタティックメソッドを用意し、このメソッド経由でインスタンス化するように設計している。 スタティックメソッドなので、IOLoop クラスのインスタンスを作成せずにこのメソッドを呼ぶことができる。 シングルトン対象のクラスがインスタンス化済みかどうかは、クラス変数 _instance を利用し、グローバルなインスタンスもがあるかチェックし、なければ IOLoop クラスをインスタンス化してこの変数に代入している。 一番エレガントな実装ではないかもしれないが、コードを見ただけでやりたいことがすぐにわかるので、読む側としては助かる。 こういう API 設計のため、サンプルコードも や というようにスタティックメソッド IOLoop.instance でインスタンスを取得して操作している。 他の実装例 Python でのいろいろなシングルトン実装例は次の URL にある StackOverflow : Creating a singleton in python http://stackoverflow.com/questions/6760685/creating-a-singleton-in-python Tornado ではシングルトンクラスが IOLoop しか無いため、クラス内でベタに実装されているのだと思う。 フレームワークとしてシングルトンクラスが複数有るような場合は、StackOverflow の #3 にあるようにメタクラスを用意し、クラスをシングルトン化するとスッキリする。

EvernoteのAPIでアップロード容量をチェック

Evernote で調子に乗ってガンガンアップロードしていたら、月半ばで早々と月間のアップロード容量に到達してがっかり、ということを何度も繰り返さなくて済むように、日々の使用状況を Evernote Cloud API から取得してみた。 作業の流れ 環境の構築 Cloud API のアカウントを取得 API を利用 環境の構築 evernote の Python SDK を利用する。 まずは SDK が依存する OAuth ライブラリをインストール 次に SDK をインストール Cloud API のアカウントを取得 API 検証用の sandbox が用意されているので、次の URL からテストアカウントを登録する。 https://sandbox.evernote.com/ 今回の場合、API はあくまでも個人用途。 このようなケースでは OAuth 認証ではなく、長い有効期間が設定されたトークン(Developer token)を使いまわして認証できる。 Using developer tokens If you are building a script or application that

Herokuでpsycopg2からPostgreSQLを触ってみる

Heroku で Python から PostgreSQL を使う場合、ドキュメントは Django を前提にしている。 宗教上の理由などにより Django 以外から PostgreSQL を使う場合を想定して、ORM も経由せずに素の psycopg2 から PostgreSQL を操作する方法を調べた。 作成するトイアプリ Ubuntu でコマンドを打ち間違えると、Google の “did you mean” 機能よろしく、候補を教えてくれる。 これと同じようなことをしてくれる “did you mean” サーバを PostgreSQL/Python/Tornado/psycogp2 の組み合わせで作ってみる。 以下の順に実装 Tornado のデプロイ Tornado と PostgreSQL の連携 did you mean 機能の実装 Tornado のインストール mikedory-Tornado-Heroku-Quickstart を利用して Tornado のボイラープレートを一気に heroku にデプロイしてしまう。 heroku にデプロイ ブラウザでローカル環境の