WinでDotCloud
WindowsからDotCloudのツールをつつこうと思ったが、公式のヘルプが役に立たなかったので書いておく。
dotcloudコマンドを作る
手動です。
(Python2.7のインストールディレクトリ)\Scripts\ の下に、dotcloud.bat(.cmdでもいいけど)というファイルを作ります。中身は以下の通り。
@echo off "%~dp0\..\python.exe" "%~dp0dotcloud_script.py" %*
%~dp0 ってのは、dotcloud.batが置いてあるドライブレターとパスを展開するオマジナイです。詳しくはバッチファイルのパラメータとかでググれば出てくるんじゃないでしょうか。
で、上に出てきた dotcloud_script.py が本体です。これも同じディレクトリに作ります。中身はこんな感じで。
# -*- coding: utf-8 -*- try: from dotcloud.cli import cli except ImportError: print('DotCloud script is not available.') else: if __name__ == '__main__': cli.main()
http://blog.kalmanspeier.com/using-dotcloud-on-windows に書いてあるのとは全然違うので注意。バージョン上がって構成が変わったとかそんなのだと思います。
Google App Engine Oilのモデル(のデータ)をbulkloaderでうｐる
こんばんは。
今年の初めに「ちょっと作り直すわ」などと宣言されたおかげで下火になりつつある感がするGAEOですが、以下はGAEOのモデルを継承して定義した俺datastoreモデルをbulkloaderでアップロードする方法のメモです
結論から言うとちゃんと(ローカルのテスト鯖に)アップロードできたので、最後まで読んでね
import path
GAEOのプロジェクトルートディレクトリにmain.pyがありますが、ここでは以下のディレクトリをsys.pathに追加してます
- main.pyのあるディレクトリ(プロジェクトのルートディレクトリ)
- applicationディレクトリ(modelとかcontrollerとかのディレクトリが入ってるやつ)
- libsディレクトリ(プロジェクトルートの直下, 用途よくわからん)
さてこのパスですが、GAEのappcfg.pyはそんなもの知るはずもないのでちゃんと教えてあげましょう
Loader
ではデータのアップロードに従ってローダーを書きましょう
ディレクトリ構成
base_directory
+ bulkloader (ここでappcfg.pyを実行)
+ hogeloader.py (ローダースクリプト)
+ hoge.csv (アップロードするデータ)
+ project_root
+ app.yaml
+ application
+ model
+ hoge.py (Hogeクラスが書いてある)
hoge.py
# coding: utf-8 from google.appengine.ext import db from gaeo.model import BaseModel class Hoge(BaseModel): piyo = db.StringProperty()
hogeloader.py
# coding: utf-8 import os import sys # current path cur_path = os.path.abspath( os.path.dirname(__file__) ) sys.path.append( cur_path ) # application directory app_path = os.path.join( cur_path, '..', 'project_root') sys.path.insert(0, app_path) # libraries sys.path.insert( 0, os.path.join(app_path, 'libs') ) # model / template / controller sys.path.insert( 0, os.path.join(app_path, 'application') ) # bulkloader from google.appengine.tools import bulkloader # model from model.hoge import Hoge class HogeLoader(bulkloader.Loader): def __init__(self): bulkloader.Loader.__init__( self, 'Hoge', [ ('piyo', str) ] ) loaders = [HogeLoader]
実行
では上記のbulkloaderディレクトリにcdしてappcfg.pyを実行するわけですが、私の環境ではパス通してないのでファイルをpythonインタプリタに直接渡します
というかWindowsだとappcfg.pyを直接呼び出した場合拡張子の関連付けで実行されるのでオススメできません
python "C:\Program Files\Google\google_appengine\appcfg.py" upload_data --config_file=hoge.py --filename=hoge.csv --kind=Hoge --url=http://localhost:8080/remote_api ..\project_root
こんな感じで。
proxy環境下でDell vostro 200にCentOS5.5を入れる
なんかDellのvostro 200が転がってたのでCentOS突っ込んでみることにした
ちょっと故あってプロクシの内側にいるので、そのあたりも考慮してやってみましょう
インストール
ディスクイメージ
vostro 200はCore2Duoが載ってるのでx86_64で。いい時代になったな。
CentOSのx86_64版は5.5からDVD2枚組などというふざけた構成(disc2は500MB弱)な上にbit torrentでしか落とせないので...
プロクシ外で落としてきて焼いてDVDドライブに突っ込む
proxy
さて、無事にインストールが終わったらプロクシの設定しておきましょう
環境変数
HTTP_PROXYとか。pythonのurllibなんかは小文字の環境変数を見るようなので
#! /bin/sh export HTTP_PROXY=proxy.example.com:8080 export FTP_PROXY=proxy.example.com:8080 export http_proxy=proxy.example.com:8080 export ftp_proxy=proxy.example.com:8080
という感じに書いたら/etc/init.d/proxy.shなどと適当な名前で保存しておきます
yum
yumのproxyの設定。
/etc/yum.confにproxy=http://proxy.example.com:8080などと書く
先頭のhttp://は要らんだろうと思って消したらpythonさんにproxyの先頭にhttp://がねえよ！と怒られたので必ずhttp://を付けましょう。
再起動
念のために再起動しておきますか。
おきますか？おきませんか？
yum update
さて、晴れてプロクシを克服された皆様方
とりあえずyum updateでもしておきますか。
/etc/rc.d/init.d/yum-updatesdが頻繁にupdateしようとするせいで手動更新と競合してupdateが失敗することがあるらしいので、stopを渡して止めておきます
というか邪魔なのでyum -y remove yum-updatesdで死んでもらいます
懸念事項が消えたところでyum -y updateでアップデートしましょう
GAE Oilのテンプレートに渡される変数について
始めてからずいぶん放置してるこのblogですが、たまには何か書こうかということでGoogle App Engine(GAE)のうすーいラッパーフレームワークであるところのGoogle App Engine Oil(GAEO)のお話
内容としてはGAEとGAEOのテンプレートの使い方の差、というか実際GAEOの中身はどうなってんの？っていうところを簡単に解説のようなことをしたいと思います。
メモ的な意味が7割、ついでに公開するかという気持ちが2割、blog放置してたから丁度いいやという思いつきが1割でお送りします。
なおGAEOのバージョンは0.3です。
webapp+Django
さて、GAEには標準のフレームワークとしてwebappっていうのがビルトインされてるんだけど、そのテンプレートシステムにDjangoのそれが使われてるわけですよ。
そしてGAEOのテンプレートシステムもwebappをほとんどそのまま引っ張ってきてるおかげで引き続きDjangoのが使える。
webappのテンプレートシステムを使うときは以下のように記述します
from google.appengine.ext import webapp from google.appengine.ext.webapp import template class HogeHandler(webapp.RequestHandler): def get(self): # 中略 processed_template = template.render(path_to_templete, template_values) self.response.out.write(processed_template)
これはまあ普通のwebappの使い方。
ここで覚えておいてほしいのはtemplate.render()っていうメソッドでテンプレート内の変数を置換したり色々と処理をしてるっていうこと。
GAEO
さて次にGAEOの(MVC的な意味での)Controllerを使って出力しますよ。
なぜControllerなのかと言われればgaeogen.pyというユーティリティスクリプトでscaffoldしたら出てきたコードがそうだったからだ！
なおHogeという名前のデータストアモデルが既に定義されているものとします。そこのとこよろしく。
from gaeo.controller import BaseController from model.hoge import Hoge class HogeController(BaseController): def index(self): query = Hoge.all() self.result = query.fetch(limit=1000)
GAEOの中を探検
さて、これを見て俺は思った。
「self.resultとはなんぞや」と
取ってきたデータはself.resultという変数に突っ込まないといけないのか、別にself.resultじゃなくてもいいのか。
まあ結論から言うと後者なんだが。
呼び出し元発見
で、ちょっとGAEOの中を探し回った結果PROJECT ROOT/gaeo/dispatch/dispatcher.pyの166行目あたりでBaseControllerのrenderメソッドを呼んでるのが判った。
なおctrlはControllerのインスタンス
if not ctrl.has_rendered: ctrl.render(template=route['action'], values=ctrl.__dict__)Google App Engine Oil gaeo/dispatch/dispatcher.py
呼ばれた方とtemplate.render()発見
で、このrenderメソッドはPROJECT ROOT/gaeo/controller/__init__.pyの217行目あたりでお馴染みwebappのtemplate.render()を呼び出している。
def render(self, *html, **opt): # 大幅に略 content = template.render(os.path.join(self.__tpldir, opt.get('template') + '.html'), context)Google App Engine Oil gaeo/controller/__init__.py
で、テンプレートに突っ込むデータが入ってるはずのcontextっていう変数は188行目あたりで
context = self.__dict__ if isinstance(opt.get('values'), dict): context.update(opt.get('values'))Google App Engine Oil gaeo/controller/__init__.py
探検結果
というわけで、結果的にControllerの__dict__
つまりオブジェクトの(書き込み可能な)属性が全部テンプレートに渡されるということで、結局はself.resultどころか変数名は何でもいいということのようです。
以上メモでした
Plan9 beginner
友人がtwitterで何度も言及したりとかkernel/VM探検隊に(友人が)参加したりとかの影響で私もPlan9をちょっとだけ触ってみましたよ
インストーラが何となく寡黙でちょっと不安なのと、shと使い勝手のちょっと違うシェルとエディタのおかげでUNIXに初めて触った頃のことを思い出して懐かしくなってみたり
初めて触ったUNIXが高校にあったUltraSPARCなSolarisっていうのはなかなかないと思う
