Django1.9 admin get_urlsのoverrideでハマってた
get_urlsで正しいっぽいurlpattern渡してるのに、なんでそんなパターン見つからないって怒られるんじゃーとなって先輩とデバッグしてたら、1.9から追加されたという以下のコードに遭遇した。
urlpatterns = [
url(r'^$', wrap(self.changelist_view), name='%s_%s_changelist' % info),
:
# For backwards compatibility (was the change url before 1.9)
url(r'^(.+)/$', wrap(RedirectView.as_view(
pattern_name='%s:%s_%s_change' % ((self.admin_site.name,) + info)
))),
]
django.contrib.admin.options | Django documentation | Django
つまり、カスタムURLが先に来るように繋げないと
def get_urls(self): from django.conf.urls import url urlpatterns = super().get_urls() urlpatterns = [ url(r'^somepattern/$', self.admin_site.admin_view(self.my_view), name=''), ] + urlpatterns # ここのリストに入れる順番が今回の問題 return urlpatterns def my_view(self, request): return TemplateResponse(request, template , {})
1.9にバージョンアップするときは注意が必要だなぁーと思った。
というかまずよくコード読めという話でした、先輩すみませんでした。。
Domain Driven Design Quickly Online を読んでいく。 その1
先に分厚いDDD本を読んでいたが、読み進めていてもどうも霧の中を歩いている感覚から抜け出せずにいるということで、まずは友人の勧めにより「Domain Driven Design Quickly」を読むこととし、そのメモを書いていく。
イントロ〜第1章 ドメイン駆動設計とは何か
ソフトウエアを開発する目的は、実世界の作業を自動化したり、ビジネス上の 問題を解決することです。つまりソフトウエアは、業務の自動化や現実世界の問題など、具体的なドメインのためのソフトウエアなのです。
ドメインとは、実世界で解決したい問題、要求の解決方の枠組みの集合またはそれ自体、ということだろうか。
もう少し雑にいうと、ドメインとはつまりソフトウェアが行う業務の範囲?内容?指していると思われる。
ドメイン駆動設計とは、ソフトウェア設計手法の一つ。
ドメインを明らかにするためには、ドメインを詳細に把握している人物からヒアリングするべきである。例えば、銀行業務システムであれば、業務流れや潜在的な問題を熟知している銀行員である(担当者および依頼者が問題を認識していない場合もあるけど)。
そうしてドメインを探り出していきつつ、ドメインの抽象化をしていく。
ドメインの抽象化とは、ドメインのモデル化のこと。
ドメインは多くの情報を含み、かつ複雑なものであるため、通常は全てをモデルに落とし込むことはできないと考えて良い。この取捨選択が設計作業であり、ソフトウェア作成でもある。
なお、ドメインモデルについては本文中にあったこの一文がわかりやすかった。
ドメインモデルとは特定の図で表されるものではなく、そのような図が表そうとする概念である。
ドメインの知識を構築する
次に、飛行機の飛行制御システム開発を例にドメイン設計を考える。
さらに議論すると、あなたは興味深い単語を聞きます。それ は「航路」です。あなたがこの単語にすぐに着目したのはそれなりの理由があ ります。航路は飛行行程の重要な概念を含んでいるからです。航路にしたがう。 これが飛行機が飛行中におこなうことです。飛行機の出発地と目的地は航路の 始点と終点でもあることが明らかになります。したがって、飛行機を出発地と 目的地に関連させるよりも、航路と関連させた方が自然な気がします。この場 合、航路は出発地と発着地に関連します。
飛行機の航路、つまり問題(飛行機)の遷移/あるいは状態に着目するというのが一つのポイントだと思われる。
例では、飛行機を出発地と目的地に関連させるよりも、飛行機ー航路ー出発地/目的地と関連付ける方が自然、とある。構成する出発地/目的地というものを抽象的に考えて飛行機と関連付ける見方ができるかどうかが第一歩。
抽象化なので、考えているとプログラムでいうクラスのようなイメージを持つ。
私たちソフトウエアの専門 家(アーキテクトと開発者)とドメインの専門家はドメインモデルを一緒に作成します。ドメインモデルはこの2つの専門領域が出会う場所でもあるあります。これは多くの時間を費やさなければならない作業に思えるでしょう。そして、実際その通りです。そうするべきです。なぜなら、ソフトウエアの最終的な目的は実際の生きたドメインでの業務上の問題を解決することであり、そのためにはソフトウエアはドメインと完璧に一体になる必要があるのですから。
アーキテクトと開発者とドメインエキスパートが揃ってドメインの抽象化を行い、ソフトウェアが本来行うべき業務のための設計をしていく、という流れなのだろう。
大雑把だが、DDDの概念は把握した。
今日はここまで。
python の doctest
26.3. doctest — 対話的な実行例をテストする — Python 3.5.1 ドキュメント
そういえば使ったことがなかったので触ってみたのと、使い道とかの個人的な感想メモ。
pythonでテストするときはunittest, pytest, pylintあたりしか使ったことがなかった。
demo.py
""" >>> test("omega") 'Hello, omega!' """ def test(name): return "Hello, {}!".format(name) if __name__ == "__main__": import doctest doctest.testmod()
実行結果
~$ python demo.py -v # -vすると実行詳細がみれる """ >>> test("omega") 'Hello, omega!' """ def test(name): return "Hello, {}!".format(name) if __name__ == "__main__": import doctest doctest.testmod() OMEGA:~$ python test.py OMEGA:~$ python test.py -v Trying: test("omega") Expecting: 'Hello, omega!' ok 1 items had no tests: __main__.test 1 items passed all tests: 1 tests in __main__ 1 tests in 2 items. 1 passed and 0 failed. Test passed.
こんな感じ。
ちなみにdocstringの気分で書いて、Expectingにシングルクォートで囲まないHello, omega!を記述していたら見事にfailedになった。
上記ではdemo,pyでdoctestをimportしてるけど、コマンドラインからdemo,pyを単体モジュールとしてimportしてテスト実行することもできる。
~$ python -m doctest -v demo.py
テストしたい内容が増えたりするとpythonファイルが肥大化するので、そういうときは testmod()の代わりにtestfile()と使うとよい。
doctest.testfile("test_list.txt") と書いてtest_list.txtの中にTrying/Expectingをガシガシ書いていけばいい。
test_list.txtの中身はこんな感じ。
>>> from demo import test >>> test("omega") 'Hello, omega!'
なおこれもコマンドラインから実行できる。
~$ python -m doctest -v test_list.txt
例外について思ったところ
例外については公式ドキュメントにも書いてあった。
トレースバックを貼ればいいだけらしいけど、filepathとか変更されやすいものだったりrandom的なもので毎回値が変化するようなものには向いていない。
そもそもあまり例外でテストするのは良くないと思うけど。
例外に関して評価される部分としては、例外の型からそれ以降だけらしい。
以下の場合、最初の二行はスルーされる。
Traceback (most recent call last): ... ValueError: multi line detail
やっぱり例外を扱うのはよろしくないと思う。なってほしい結果の一例としてのwikiのようなものくらいのほうが良いと思う。
感想
doctestはexampleとして記述しておくのが良いのかなと思った。私の中では今のところ、docstringをより良いものにするためのという位置付け。
あと、モジュールの方針・本当に実現したい機能を思い出させてくれるものとしても良いかも。
ガシガシコード書いてると、よく方向性見失ったりするので、、
ExDOS を動かしてみた
天才あらわる 14歳の少年プログラマが作った64ビットOS「ExDOS」が凄い という記事を見て、何やらOSを自作した人がいてそれが公開されているという情報を得たので実際に動かしてみた。
ダウンロード
ExDOS -- Downloads
ここからダウンロードしてくる。
現時点ではdemo状態のものだけが公開されている。
今回はdemo2.zipを手元に持ってきた。
ExDOSを動かす
ExDOS -- Tested Hardware を読むと、VirtualBox5.0上でならいい感じに動くぜ!と書いてたのでVirtualBox5.0上で動かした。
仮想ハードディスクを追加しない設定で作成して、ストレージからHDD選択でdemo2.vmdkを指定するだけ。
Runしたらこんな画面になった。
ウィンドウが二つ。こやつらはマウス操作で位置を動かせた。拡大縮小とかはできなかった。
右下にDEBUGというボタンみたいなのあったのでクリックしたら、ターミナルっぽくなった。
helpと入力すると使えるコマンド一覧でてくる。
コマンドミスしてるのは、英数字切り替えボタンを押す癖が抜けなくて無意識に「 ` 」を入力していたというオチ。
とりあえず手当たり次第にコマンド打って遊んだ。
無知すぎてportコマンド群の意味がよくわからなかった。
感想
- とにかく起動が早かった。まだそんなに機能ないからだとは思うけど、サクサク。
- たまにカーソル操作がおかしくなって左側にぴょんと飛んだりするトリッキーな動きもして翻弄された。
- ターミナルの履歴機能はまだなかったけど、ここまで作れた人にとってもそういう機能の導入って難しいのかな。(OS作ったことないのに生意気言ってごめんなさいでもあるとコマンドの動作確認とか便利だろうなって思ったんですごめんなさい)
- まだドキュメントはcomming soonだったのでできるの楽しみ。
ソースコードはGihubで公開されている。
GitHub - omarrx024/exdos64: Extensible Disk Operating System (64-bit version)
アセンブラ力がゼロなので特になにも解読できませんでした。
でもこういうモジュール(と言っていいのかわからないけど)の切り方するんだなとか、kernel.asmを起点に眺めているとなんとなーくだけど、中でやってることがが見えてきた。
keyboard.asmにはhelpで出したコマンドの関数定義があったり(アセンブラは読めないけど)。
pyinvoke を触ってみた
pyinvoke
Welcome to Invoke! — Invoke documentation
pyinvokeは、いろんなコマンドをまるっと纏めることができるモジュール。
たとえば、開発で頻繁に必要となるコマンドを一つに集約させる場合にこのpyinvokeが生きてくる。
いま仕事でDjangoコマンド、テスト実行コマンド、環境毎の実行コマンドなどをpyinvokeでまとめているけどinvokeさえ覚えればいいのでとても楽。
インストール
$ pip install invoke
使い方
Getting started — Invoke documentation に使用方法が書かれています。
基本は、tasks.pyに@taskを関数の上に宣言して実行させたい内容を関数内に記述するだけ。
また、関数Aの@task()の引数に関数Bを渡すと、関数Aを実行する前に関数Bが実行される(pre-taskの設定)。
試しに、invokeコマンドから「demo/demo.txtに任意の文字列を追記する」「demoディレクトリを削除」という2つのタスクを追加する。
tasks.py
import os from invoke import task, run @task def mkdir_demo(): """demoディレクトリがなかったら作成 """ if not os.path.exists("demo/"): os.mkdir("demo") @task(mkdir_demo) def add_text(line): """demo.txtに任意の文字列を追記する """ run("echo {} >> demo/demo.txt".format(line)) @task def reset(): """demo/をまるっと削除 """ run("rm -r demo/")
invoke --listすると、追加したコマンドの一覧を表示できる。このとき、docstringが各コマンドの説明として出てくる。
ただ、pre-taskもこのリストに表示されるのが微妙。
$ invoke --list
Available tasks:
add_text demo.txtに任意の文字列を追記する
mkdir_demo demoディレクトリがなかったら作成
reset demo/をまるっと削除
実際にコマンドを実行してみる。
$ ls demo/ ls: demo/: No such file or directory # demoディレクトリが存在しないことを確認 $ invoke add_text hello $ cat demo/demo.txt hello # demoディレクトリが作成され、demo.txtに指定した文字列"hello"が追記されている $ invoke add_text world! $ cat demo/demo.txt hello world! # 追記されている
Rundeck Config・ジョブ通知・Mysql の設定編
前回はRundeckをローカルで動かすまでのメモを書いた。
Rundeck 基礎編 インストールからジョブ実行までのメモ - 僕とコードとブルーハワイ
今回は、実際に使用するときに設定する色々なことをメモしていく。
環境
Ubuntu 14.04
Rundeckバージョン:2.6.2
Rundeckの設定
公式ページを見ながら設定していく。
Configuration
Config設定が置いてある場所と構成は以下の通り。
今回は最低限の設定だけする。いじるのはframework.properties、project.properties、profileくらい。
omega:~$ sudo tree /etc/rundeck/ /etc/rundeck/ ├── admin.aclpolicy ├── apitoken.aclpolicy ├── framework.properties ├── jaas-loginmodule.conf ├── log4j.properties ├── profile ├── project.properties ├── realm.properties ├── rundeck-config.properties └── ssl └── ssl.properties
framework.properties
Rundeckのコア部分の設定を定義するファイル。
ホスト名やBaseURL、Login User/Passwdなど。
# ---------------------------------------------------------------- # Rundeck server connection information # ---------------------------------------------------------------- framework.server.name = rundeck-example.com framework.server.hostname = rundeck-example.com framework.server.port = 4440 framework.server.url = http://localhost:4440 # 自鯖内で経由するのでlocalhost # Username/password used by CLI tools. framework.server.username = omega framework.server.password = agemo :
rundeck-config.properties
データベース、logレベル、メール通知の設定などをするファイル。
#loglevel.default is the default log level for jobs: ERROR,WARN,INFO,VERBOSE,DEBUG loglevel.default=INFO rdeck.base=/etc/rundeck #rss.enabled if set to true enables RSS feeds that are public (non-authenticated) rss.enabled=false grails.serverURL=http://rundeck-example.com dataSource.dbCreate=update dataSource.url=jdbc:h2:file:/var/lib/rundeck/data/rundeckdb;MVCC=true;TRACE_LEVEL_FILE=4
上記の設定をしてRundeckを再起動すると、設定ファイルが反映される。
http://rundeck-example.com にアクセスしてログイン画面になったらOK。
ジョブ通知の設定
Rundeckではジョブのステータス(Success, Failed, Start)で通知を飛ばせる仕組みがある。
今回はSlack通知と Email通知の設定方法を書いていく。
Slackに通知を飛ばす
前回のRundeckメモに書いたけどもう一回書く。
準備はrundeck-slack-incoming-webhook-pluginの公式ページからrundeck-slack-incoming-webhook-plugin-0.5.jar(この記事を書いた時点での最新版) をダウンロードしてきて、/var/lib/rundeck/libext/配下に設置して、Rundeckを再起動するだけ。
$ sudo mv rundeck-slack-incoming-webhook-plugin-0.5.jar /var/lib/rundeck/libext/
再起動後にWebUIからジョブの作成ページを見てみると、Send Notification?の欄にSlack Incoming WebHookが追加されている。
SlackのIncoming WebHooksからWebhook URLを取得してフォームに入力してあげるだけでOK。
簡単なジョブを実行して、Slackへ実行結果が送信されていることを確認。
実行結果ページへのリンクも貼られているのも便利。
メールで通知する
Email Settings によると、SSL越しに接続したりと高度な設定をしたい場合はrundeck-config.propertiesではなくrundeck-config.groovyに記述しましょうとのこと。
/etc/rundeck/にrundeck-config.groovyを作成する。
今回はGmailのSMTPを使う(楽だから)。
中身は以下のように書くかんじ。
loglevel.default="INFO" rdeck.base="/var/lib/rundeck" rss.enabled="false" grails { serverURL="http://rundeck-example.com" mail { host="smtp.gmail.com" port = 465 username="example@gmail.com" password="example" props = ["mail.smtp.auth":"true", "mail.smtp.socketFactory.port":"465", "mail.smtp.socketFactory.class":"javax.net.ssl.SSLSocketFactory", "mail.smtp.socketFactory.fallback":"false"] } } grails.mail.default.from = "example@gmail.com" dataSource.url = "jdbc:h2:file:/var/lib/rundeck/data/rundeckdb;MVCC=true;TRACE_LEVEL_FILE=4" dataSource.dbCreate = "update" rundeck.projectsStorageType = "db"
Goovyファイルを書くのが初めてだったのでたまに文法エラーで時間食った。ドキュメントをよく読もう。
Groovy Language Documentation
デフォルトではrundeck-config.propertiesを読み込むようになっているので、rundeck-config.groovyを読み込ませるように以下の1行を/etc/rundeck/profileへ追記する。
RDECK_JVM='$RDECK_JVM -Drundeck.config.location=/etc/rundeck/rundeck-config.groovy'"
Rundekを再起動後、WebUIからジョブの作成ページのSend Notification?をYesにして、Send EmailのTo、Subjectを入力すればメール通知の設定は完了。
Attach output logを選択すると実行の過程で出力されたlogのtxtファイルがメールに添付されてくる。
Mysqlを使用するための設定
デフォルトでは H2 Database が使用される。
公式ページにMysqlを使用するときの設定方法が書かれていたのでメモ。
MysqlにRundeckで使用するデータベースを作成する
mysql> create database rundeckdb; Query OK, 1 row affected (0.00 sec) mysql> grant ALL on rundeck.* to 'rundeckuser'@'localhost' identified by 'rundeckpassword'; Query OK, 1 row affected (0.00 sec)
rundeck-config.groovyにMysql接続のための設定を追記する
以下のように書く。
: dataSource.driverClassName="com.mysql.jdbc.Driver" dataSource.url="jdbc:mysql://example.com/rundeckdb?autoReconnect=true" dataSource.username="rundeckuser" dataSource.password="rundeckpassword" :
mysql connector について
新しいバージョンのRundeckには デフォルトで/var/lib/rundeck/exp/webapp/WEB-INF/lib配下にmysql-connectorが置いてあるけど、もしMysqlがうまく動作しなかったりmysql-connectorが無い/デフォルトバージョンだと動かない場合は、MySQL :: Download Connector/J から mysql-connector-java-5.x.x-bin.jarをダウンロードして /var/lib/rundeck/server/lib/配下に設置するとよい。
上記の設定をしてRundeckを再起動したら設定完了。
テーブルはこんなかんじ。
mysql> show tables; +----------------------------+ | Tables_in_rundeckdb | +----------------------------+ | auth_token | | base_report | | execution | | log_file_storage_request | | node_filter | | notification | | orchestrator | | plugin_meta | | project | | rdoption | | rdoption_values | | rduser | | report_filter | | scheduled_execution | | scheduled_execution_filter | | storage | | workflow | | workflow_step | | workflow_workflow_step | +----------------------------+ 19 rows in set (0.00 sec)
mysqldumpしてプロジェクトとかジョブの情報を取っておくとよい。
でもresources.xmlの情報はこの中に入ってないので別途バックアップを取っておく必要がある。