※あくまでも個人の感想です。

Homebrew で ImageMagick をインストール

いきなりbrew install imagemagickすると、 Error: You mustbrew link jpeg’ before imagemagick can be installed` とか言われたので、

$ brew link jpeg

とやってから、

$ brew install imagemagick

インストール途中のメッセージで「 brew link pkg-config しろ」みたいな事言ってたので、

$ brew link pkg-config

とやったが、どうも旧バージョンのシンボリックリンクが残っているせいで怒られているみたいなので、以下のように該当ファイルをかたっぱしから削除してから再度 brew link pkg-config を実施。

$ rm /usr/local/bin/pkg-config 
$ rm /usr/local/share/man/man1/pkg-config.1 
$ rm /usr/local/share/doc/pkg-config/pkg-config-guide.html 
$ rm /usr/local/share/aclocal/pkg.m4

RubyGems で RMagick をインストール

これは普通に

$ gem install rmagick

で完了。

確認

irb から RMagick のバージョンを確認してバージョン情報が表示されるか確認してみる。

$ irb -rubygems -r RMagick

> puts Magick::Long_version

This is RMagick 2.13.1 ($Date: 2009/12/20 02:33:33 $) Copyright © 2009 by Timothy P. Hunter Built with ImageMagick 6.7.7-6 2012-09-18 Q16 http://www.imagemagick.org Built for ruby 1.9.3 Web page: http://rmagick.rubyforge.org Email: [email protected] => nil

追記：やっぱり RMagick より手軽な mini-magick にした

$ gem install mini_magick

でインストール完了

Bookscan でスキャンされた書籍のPDFを手元でチューニングしたいと考え Ruby でどうにかする方法を模索中。

そのような用途で使える Ruby 向けの PDF を読み書きするためのライブラリについてちょっと調べたので記録しておく。

PDFを解析する

現時点でメンテナンスが継続されているものとして pdf-reader がよさそう。

yob/pdf-reader

PDFを生成する

PDFをいちから生成する用途としては Prawn がよさそう。

Prawn

参考記事

• PDF生成ライブラリ「Prawn」 - 名もないテクノ手

PDFの解析と生成（改変）

PDFの解析と生成（改変）が可能なライブラリとしては Origami というライブラリがある。 PDF（の画像）をチューニングするという目的としてはこれが一番よさそう。

Origamiを使ってPDF中の画像を調整する - \ay diary

参考記事

• Origamiを使ってPDF中の画像を調整する - \ay diary

iTerm2向け

下記ページの"Color Schemes"一覧から、"Solarized Dark"のリンクを別名で保存し、iTerm2でImport

ColorGallery - iterm2 - Community-Contributed iTerm2 Color Schemes - Development site for iTerm2 - Google Project Hosting

tmux向け

下記のリポジトリから、"tmuxcolors-256.conf" をダウンロードして ~/.tmux.conf にコピペし、tmux を再起動。

seebi/tmux-colors-solarized

ログを見る

ファイル名と変更の量を表示

git log --stat

ファイル名と変更の種別を表示

git log --name-status

グラフ表示

git log --graph --oneline

あるブランチからmasterまでのログを抽出

git log from-branch..master --name-status

変更の差分を見る

変更されたファイル名と変更の種別のみを見る

git diff --name-status

bash プロンプトにブランチ名を表示し変更されているかどうかを’*‘で識別できるようにする

どうも別の場所であっても既に同じサーバの同じ共有フォルダがローカルにマウント済みの場合にはそのようなメッセージが表示されるみたい。

その場合は、いったん umount でマウントを解除して再度マウントすればオK

特に、Finder などから「サーバへ接続…」した場合は、自動的に /Volumes/xxxx にマウントされている場合があるので注意。

参考： mount_smbfs: mount error..File exists at Mark Needham

（ただし、Homebrewer に限る）

    $ brew install reattach-to-user-namespace --wrap-pbcopy-and-pbpaste

でいけます。

下のリンクの記事読んで、「ああ、なんか面倒くさそう…もしかして… 」と、思ったら Homebrew でインストールできるようになってました。便利な世の中になりました。

参考：Mac の tmux でクリップボードを使う。 - こせきの技術日記

> I’m trying to create an extension like Django template tags for
> jinja2. the basic idea is a tag in the main template( {% widget
> last_tweets %} ) that return a node of a source taked from another
> file ( widgets/last_tweets.html for example ).

Why do you need an extension for that?  A function is perfectly fine:

Jinja2 template tags extension like Django - pocoo-libs | Google グループ

らしいです。

さっそく試してみた

ちなみに、動作環境は GAE です。

まず、main.py を書く

7行目で、env.globals['hoge'] = lambda: u"ほげほげ"というように関数オブジェクトをglobalsというアトリビュートに'hoge'という名前で格納しているのがミソ。

で、テンプレートの記述は以下のようになる。

ここでは、hoge()のように、前述のglobalsに格納した名前で関数を呼び出す。すると…

となる。

ほんと、楽チンですね。

参考

• API — Jinja2 2.7-dev documentation
• API#Global Name space — Jinja2 2.7-dev documentation

ちゃんとしたタグを作りたいなら、以下を参考にしたらいいみたい（まだ作ったことない）

• Extensions — Jinja2 2.7-dev documentation

でも、

Jinja extensions work ahead of time.  They emit nodes from an abstract
syntax tree which are then used to generate sourcecode.  This is usually
a very complex topic and only recommended if functions no longer work
which are a lot easier to implement and way easier to debug.

と言ってるように、この程度の用途ならデバッグしやすさとかを考慮しても関数を使うほうが楽でいいみたい。

ほとんど自分向けのメモ

なんか、いつのまにかAppEngineのデフォルトがPython2.7になっちゃてて、公式には日本語チュートリアルがほとんど無いので書いとく。

とりあえずテンプレート使ってHello worldするまで

app.yaml を書く

まず、3行目の runtime: python27で Python 2.7 を使うようになる。 それと、threadsafe: yesは「このアプリケーションはスレッドセーフなので、ばんばんマルチスレッドでリクエスト飛ばしててねー」という意味。逆に「スレッドセーフって何？」って感じなら、noにしておく。 Python 2.7 にした場合、このthreadsafeの指定は必須となるので注意。

• 参考：Configuring the Application

つぎに9行目。script: main.appが今までと違っている。いままでは、main.pyっていう感じでスクリプトファイル名だったのが、WSGIApplicationが実装されているモジュールと、そのインスタンスが格納されている変数名という感じに変っている。 これは、いままでCGIとして動作していたのがネイティブなWSGIアプリケーションとして動作するようになったためらしい。

• 参考：Configuring WSGI Script Handlers

また、11行目以降の、librariesで、使用するフレームワークやテンプレートエンジンの名前とそのバージョンを指定する必要がある。 「べつにバージョンとか知らねーし？新しいのでいいしょー」って場合は、latestって書いておけば今のSDKで用意しているバージョンの最新が使われる。

• 参考：Configuring the Application

main.py を書く

ここの変更点は、3,4行目で importするモジュールが、いままで、google.appengine.webapp とか、google.appengine.webapp.templateだったものが、webapp2やjinja2になった。

そして、6-8行目は Jinja2 でテンプレートを読み込むために必要な準備として、テンプレートが格納されている場所をLoaderに教えてあげているところ。 このように記述すると、main.pyが格納されているのと同じ場所からテンプレートを読み込んでくれる。

12行目でEnvironmentクラスのget_templateメソッドでテンプレートを取得して。

13行目でTemplateクラスのrenderメソッドでテンプレートをレンダリングしている。

• 参考1: Using Templates - Google App Engine — Google Developers
• 参考2: API#Basics — Jinja2 2.7-dev documentation
• 参考3: API#Loaders — Jinja2 2.7-dev documentation

hello.html を書く

テンプレートの書き方自体は Diango のテンプレートの書き方とほとんど一緒。

• 参考: Template Designer Documentation — Jinja2 2.7-dev documentation

その他の注意点

その他に気をつけるべき点が掲載されていたのでのせておく。参照すべきリンクは原文：「Using Python 2.7 - Google App Engine — Google Developers」を参照。

• データストア: Python 2.7 では High Replication datastore を使う必要があるみたいで、従来の Master/Slave データストアを使っているアプリケーションは移行作業が必要みたいです。（よくわかってない）
• 32ビットモード: Python 2.7 ランタイムは 32ビットモードしかサポートしていないため、64ビットモードの機能を使っている場合は変更が必要。（これもよくわからない、Python自体に32ビット／64ビットで機能が分かれてる？）
• CGI vs. WSGI: アプリケーションが多くのリクエストを同時に処理する必要があるなら CGI ではなくて WSGI アプリケーションにする必要がある。
• レイテンシ（遅延）: 特定の状況では Python 2.7 にすることで、アプリケーションの応答の遅延が発生する場合がある。そのような場合は、app.yamlでthreadsafeを有効にして、フロントエンドのインスタンスを増やすことができる。
• Django: Python 2.7 ランタイムでは、Django 1.2 を使う必要がある。
• PyCrypto: Crypto.Util.randpoolは非推奨となったので、Crypto.Randomを使う。
• PyYaml: PyYaml は 3.1.0 を使うようになった。バージョンによる違いは、PyYAML – PyYAMLを参照。
• WebApp: Python 2.7 環境では WebApp テンプレートは非推奨となった。その代替として、直接 Django テンプレートを使うか、jinja2 またはその他のテンプレートエンジンを使うように。（WebAppテンプレートは、Django テンプレートシステムの軽量ラッパーだったけど、これ以上機能追加とかしなくなるので、他のテンプレートエンジン使ってね、ということみたい）
• WebOb: Python 2.7 では WebOb のバージョン 1.1 をサポートする。これは以前のバージョン(0.9)と完全に互換性があるわけでは無いので、以前WebObを使っていたアプリケーションは十分なテストが必要。

参考リンクまとめ

• Getting Started: Python 2.7 - Google App Engine — Google Developers
• What’s New in Python 2.7 - Google App Engine — Google Developers
• Webapp2でJinja2テンプレートエンジンを使う < egashira.jp
• Welcome to webapp2! — webapp2 v2.5.1 documentation
• Welcome to Jinja2 — Jinja2 2.7-dev documentation

もう約２週間ほど前になるが、大友克洋GENGA展にいってきた。

場所は秋葉原と御徒町の間くらいにある、3331 Arts Chiyoda というところ。 元が学校だったみたいで、最初、Google Map 頼りにその場所についたら学校そのものだったので場所を間違えたと思って不安になってしまった。

表にまわれば、大々的にやってたので安心したが。

予約の開場時間の16時より早めについたので、近くのカフェで時間調整。アイスカフェラテを頼んだが、オープンな感じの場所で肌寒かったのでちょっと後悔した。

と、しばらくしてやっと開場時間がきたので、もういちど開場へ。

展示内容は、大まかにAKIRAの表紙絵や映画ポスター、カメラの広告やヴォルビックなどの広告用のポスターおよび、これまで手がけたマンガ原稿の一部が展示されているスペースと、AKIRAの生原稿全てという感じになっている。

というか、展示スペースの４分の３以上はAKIRAな感じになっていたと思う。

つい、最初から最後までストーリーを追っかけながら見てしまった。

ギャラリーの最後には、冒頭の金田のバイクがあったり、童夢の壁を再現しているスペースで自由に記念撮影ができるスペースとなっていた。

そこの壁１面は自由に落書きできるようになっていて、中には有名なマンガ家の落書きもいっぱいあった。

カスタムテンプレートタグ（長いので以下’カスタムタグ’と呼ぶ）やフィルタの作り方は、基本的にはDjangoのそれと同じようだが、それを使うための作法がちょっと違うので注意が必要です。

Djangoのカスタムタグに関する情報は「テンプレートタグやフィルタを自作する — Django v1.0 documentation」を参照。

カスタムタグを作る

たとえば、単純に"Hello GAE world"と出力するだけの簡単なカスタムタグを作ってみる。 するとコードは以下のような感じになる。

このときの注意が２つある。 １つ目は、registerという名前は固定であること。 このあと掲載するmain.py（テンプレートをレンダリングする側）のコードでカスタムタグをDjangoのテンプレートシステムにモジュールを登録するが、そのときモジュール内のregisterを探してそれを登録する仕組みになっているのがその理由。

２つ目は、このファイルの格納場所に関するもの。 モジュールとして読み込まれるため、Pythonの作法に従って、このファイルを格納するためのディレクトリを作成し、そこに__init__.pyを用意したうえで、このファイルをそこに格納する必要がある。 __init__.py が無い場合、’ImportError: No module named tag_library‘となる。

上記のように、タグを定義したモジュールのことを Django のテンプレートシステムでは「ライブラリ」と呼んでいるみたいです。

カスタムタグを利用する側にライブラリを登録する

カスタムタグを利用するには、あらかじめ前述の手順で作成したライブラリをDjangoのテンプレートシステムに登録してあげる必要があります。 カスタムタグを利用する側（テンプレートをレンダリングする側）のコードは以下のような感じになります。

冒頭で、template.register_template_library('tag_library.my_tags')と記述している箇所が、ライブラリを登録している箇所になります。 これで、Djangoのテンプレートシステムに'my_tags.py'が読み込まれ、その中に記述されているタグを定義した関数'hello'がカスタムタグとして登録されます。

テンプレートに組み込む

さっそくカスタムタグをテンプレート本体に組み込んでみます。 以下のような感じになります。（簡単のためDOCTYPEとかいろいろ省いています）

ここでも１つ注意が。 Djangoでカスタムタグを使用する場合は、{% load %}タグで使用するカスタムタグライブラリを読み込む必要がありますが、GAEの場合は、前述のmain.pyでregister_template_libraryしているので、 {% load %}は不要であることです。

で、これを実行すると。

のようになります。 GAE/Python（というかDjangoか）まだまだ勉強中ですが奥が深いですね。

次回は、「GAE/Pythonでテスト駆動開発するための環境を作る」の予定です。

参考

• テンプレートタグやフィルタを自作する — Django v1.0 documentation
• python - How do I register custom filter in Google App Engine template system? - Stack Overflow