trunk版のCassandraと戯れる - スコトプリゴニエフスク通信
trunk版のCassandra(Cassandra 0.7)で遊んでみた。 設定ファイルがYAMLに変わるのは誰得？って印象があったが案外違和感がない。普段LAMP系のソフトウェアを扱っている人間にはYAMLの方が自然に感じる。 動的にKeyspaceやColumnFamilyを追加できる機能はgood。APIが変わりすぎてないか…Vector clockサポートが入るといった大きな変更があるから仕方がないのかもしれないし、APIのInterfaceは0.6系のものより洗練されていると感じたが、Pythonで言うとlazyboyとかpycassaいったCassandraラッパーライブラリは全く動かなくなるのではないか。まだbetaすら出ていない段階だから何とも言えないが、これがCassandra Projectの流儀だとすると、いろいろ慎重にならざるをえない。KeyspaceやColum
superfcgiがよさげ - スコトプリゴニエフスク通信
The only one true way to run WSGI apps through fastcgihttp://pypi.python.org/pypi/superfcgi/superfcgiは「WSGIアプリケーションをFastCGIで動かすための唯一正しい方法」という意欲的なライブラリ。superfcgiはfastcgi.comが提供しているfastcgiappというCライブラリを使っているので、あらかじめインストールが必要。Fedoraの場合は、 $ sudo yum install fcgi-devel fastcgiappをインストールしたならば、 $ pip install superfcgi superfcgiはDjango用のコマンドも用意しているので、settings.pyのINSTALLED_APPSに、 INSTALLED_APPS = ( 'superfc
Spawningを使ってDjangoを動かす - スコトプリゴニエフスク通信
http://pypi.python.org/pypi/Spawning/以下はシングルプロセス・シングルスレッドの場合。プロセス数を増やすには-sオプションを、スレッド数を増やすには-tオプションを指定。 $ cd /paht/to/my_django_project/ $ PYTHONPATH=.. spawn --factory=spawning.django_factory.config_factory -s 1 -t 1 -p 8000 settings 「マルチプロセス・シングルスレッド」か「シングルプロセス・マルチスレッド」の択一になってしまうFastCGI(flup)や、単一のPythonバージョンしか利用できないmod_wsgiと比べるとあなどり難い存在。特定のファイルのタイムスタンプを監視して自動的に再起動、使用する最大メモリ量を制限するといった機能もある。が、どうして
Fabricを使ってリモートサーバーでコマンドを実行する - スコトプリゴニエフスク通信
Python版のCapistranoと言われて久しいFabricだけど、ドキュメント通りにやっても全く動かなかった経験があるのでずっとスルーしてきた。http://pypi.python.org/pypi/Fabric/0.9rc1http://docs.fabfile.org/0.9/PyPIに上がっている0.9というバージョンは、まずまず動くので検討する価値がある。インストールはいつも通り、 $ pip install Fabric 基本的なことFabricをインストールするとfabというスクリプトがインストールされるので、 $ fab -H localhost -f fabfile.py command> のようにして実行する。fabfile.pyは設定ファイルの名前だが、fabfile.pyという名前で設定ファイルを保存しておけば省略できる。-Hオプションはホスト名の指定。オプショ
mod_passengerでWSGIアプリケーションを動かす - スコトプリゴニエフスク通信
Passenger(mod_passenger)は言わずと知れたRuby on Rails/Rackアプリケーションを動かすための定番サーバーのひとつ。 Phusion Passengerhttp://www.modrails.com/実はPassengerではPython WSGIを動かすこともできる。誰が得するか分からないから誰もほとんど言及していないけど。本番環境でPassengerを使ってWSGIアプリケーションを動かそうとは思わないけど、virtualenvとの親和性が高い、複数のバージョンのPythonを使って開発ができるというメリットもあるから、開発環境では使ってみてもいいかもしれない。あと、すでにmod_passengerの環境が構築済みならば、Trac等の定番アプリケーションを動かす場合でも、mod_wsgiやFastCGIよりも設定が楽な気がする。まあ、こういったケース
gearmandのHTTPプロトコル - スコトプリゴニエフスク通信
gearmanのHTTPプロトコルを試してみようと思ったところ、だいぶハマったのでメモを残しておく。 gearmand起動オプションの注意点HTTPプロトコルのサポートはバージョン0.8から含まれており標準で有効になっているはず。確認するには、--helpで"http Options"が含まれているかチェック。 $ gearmand --help gearmand 0.10 - https://launchpad.net/gearmand usage: gearmand [OPTIONS] ... 略 libmemcached Options: --libmemcached-servers=SERVER_LIST List of Memcached servers to use. libsqlite3 Options: --libsqlite3-db=DB Database file to
Simple Queue Serviceに触ってみた - スコトプリゴニエフスク通信
Amazon SQS (Simple Queue Service)はAmazonが提供しているメッセージング・ウェブサービス。 Amazon Simple Queue Servicehttp://aws.amazon.com/sqs/自分の周りでは実際に使っているっていう人を聞いたことがないし、ぐぐっても日本語の情報はそんなに出てこない。たぶん、 メッセージング・サーバーが北米だかヨーロッパにあるんだか分からんが、わざわざそんな遠方にある(かもしれない)サーバーを使ってメッセージングする必要なくね？ そもそもEC2を使うならば、EC2のインスタンスに自前でSTOMPやAMQP等のメッセージング・サーバーを立てればよくね？みたいな、誰もが思う理由で日本では使われないんだろうけど。それでも前々から「一度は触ってみなくてはいかんな」と思い、ようやく触ってみた。その感想を先に書いておくと、APIは
MongoKitを試す - スコトプリゴニエフスク通信
MongoKitはMongoDBをより容易に扱うためのPythonライブラリ。MongoKit framework try to keep its simplicity when you manage mongodb in python. MongoKit was developed to be fast and light with KISS and DRY in mind.http://bitbucket.org/namlook/mongokit/http://bitbucket.org/namlook/mongokit/http://pypi.python.org/pypi/mongokit/MongoDBはスキーマレスDBなわけだが、スキーマがないからといって不正なデータをDBに突っ込んでいては面倒なことになる。MongoKitを使うとデータ・ドキュメントの妥当性を検証するのが楽に
ModelFormを使ってみた - スコトプリゴニエフスク通信
「普通の」Django開発の原稿を書かなくてはいけないので、ようやくModelFormに触ってみた。ちょっとトリビアルなモデルだけれども、モデルItemに対するフォームItemFormを定義してみる。 import django.newforms as forms from django.db import models class Item(models.Model): name = models.CharField(max_length=100) class ItemForm(forms.ModelForm): class Meta: model = Item ビューから使う時には、新規作成ならば、 from django.shortcuts import * from django.template import RequestContext from models import I
MongoDBでmemcachedのincr/decrのようなことをやりたい - スコトプリゴニエフスク通信
下記の「リアルタイム分析にMongoDBを使う」という内容のエントリに触発されて自分でも試してみた。Using Mongo for Real-Time Analyticshttp://www.10gen.com/blog/2009/3/using-mongo-for-real-time-analytics"upsert"と"$inc"を使えばいいということなので、とりあえず次のようなコードを書いてみる。 # -*- coding: utf-8 -*- from pymongo.connection import Connection conn = Connection() db = conn.test_db collection = db.test_collection # 最初にキーを消しておく collection.remove({'key': 'SPAM'}) # この時点でキーSP
Gearman UDFを試してみる(2) - スコトプリゴニエフスク通信
前エントリの続き。 SQLAlchemyを使ってテーブル・トリガーを定義前々エントリで紹介した資料と全く同じテーブルとトリガーをSQLAlchemyを使って定義する。 # -*- coding: utf-8 -*- # models.py from sqlalchemy import * from sqlalchemy.orm import scoped_session, sessionmaker from sqlalchemy.ext.declarative import declarative_base engine = create_engine('mysql://scott:tiger@127.0.0.1/test?charset=utf8&use_unicode=0') Session = scoped_session(sessionmaker(bind=engine)) Bas
Gadget開発の基本 - スコトプリゴニエフスク通信
前エントリを参照していただければ、多少Pythonがわかる方ならば自分で試してみることもできると思うので、基本的な概念と雰囲気を伝えるよう努力していきたいと思う。まず、ContainerとGadgetという二つの要素が登場する。 Gadgetは、例えば、MacのDashboardであったり、iGoogleのGadgetのように、様々なアプリケーション作成者が提供するアプリケーションである。 Containerは、それらのGadgetの実行環境、Gadgetをホストするサイトである。例えば、Mac OS XはApple自身やサードパーティが提供するDashboardアプリケーションの実行環境であり、iGoogleはサードパーティのGadgetをホストするサイトである。DashboardアプリやGadgetがHTML, JavaScript, CSSを使って構成されるのに対して、以下で述べる「
ajp-wsgiでDjangoを動かす - スコトプリゴニエフスク通信
ajp-wsgi http://www.saddi.com/software/ajp-wsgi/ajp-wsgiはAJPプロトコルでWSGIアプリケーションを動かすためのゲートウェイサーバ。flupと同じようなもの。ajp-wsgiとflupは作者も同じだし、flupもAJPをサポートしているけど、ajp-wsgiはすべてCで書かれているから、flupより速いらしい。作者自身が「もうflupなんて使わねーよww」(意訳)と書いているのを読んだ記憶がある。というわけで、ずっとflupからajp-wsgiに乗り換えたかったのだが、「AJPプロトコルだとフロントはApacheを使わないといけないのか？」と思うと二の足を踏んでいた。 ところが今日、lighttpd 1.5にはAJPプロトコルのProxyがあるということを知り、さっそく試してみた。lighttpd 1.5Subversionでソース
pybabelコマンドを使ってアプリケーションを国際化する - スコトプリゴニエフスク通信
昨日から引き続きBabelに触ってみます。今日はアプリケーション国際化の流れをざっと追ってみます。(アプリケーションといっても、ここで例に出しているのは非常にtrivialなものですが・・・) プロジェクトを作成pasterを使って新規プロジェクトmybabelを作成します。 $ paster create mybabel Selected and implied templates: PasteScript#basic_package A basic setuptools-enabled package Variables: egg: mybabel package: mybabel project: mybabel Enter version (Version (like 0.1)) ['']: # テストなのでEnterを押してどんどん進めていく $ cd mybabel $ ls
Babelを使ってみる - スコトプリゴニエフスク通信
BabelとはBabelはedgewallによって開発されているI18N, L10Nのためのライブラリです。Babel http://babel.edgewall.org/ Pythonでは標準ライブラリとしてGNU gettextが組み込まれており、カタログをビルドするためのスクリプト(msgfmt.pyとか)も標準でありますが、これだけでは不便です。例えば、Webアプリケーションを開発していると、テンプレート内の文字列を国際化したいというようなニーズがどうしても出てくるでしょう。Babelはこうした局面で使用することを目的として開発されているライブラリ・ツールのようです。 Djangoを使っていると、make-messages.py, compile-messages.pyで上記のような要求が満たされてしまうので、Babelのようなライブラリは全く必要がないと思います。しかし、「俺フレ
EC2の第一印象 - スコトプリゴニエフスク通信
最近自宅サーバーでちょっとしたアプリケーションを動かしていたのだが、引越しのため回線が止まってしまってアクセスできなくなってしまい、寂しい思いをしていた。自宅サーバーというよりも、id:dandasoの「ITベンチャー勝ち組セット」を間借りさせてもらったサーバーで、「引越し」っていうのがdandaso宅の引越しなのか、会社オフィスの引越しなのか・・・、まったく雲をつかむ様に分からない。まあこれはこれで「クラウド・ソリューション」である。来週にはそのクラウドも復活するらしいが、それまでの数日間、EC2を使ってみることにした。これまで全然触ったことがなかった理由は、 何からスタートすればいいのかよく分からない。 よくある「通信遅延」の話。 そんなに安くないのでは？ということ。最初の点についてはやっぱり始めは戸惑ったが、必須の作業は、Amazon Web Services(AWS)のページにアク
Zineがかなりよい感じ - スコトプリゴニエフスク通信
http://zine.pocoo.org/ZineはPython製のブログ・エンジン。Werkzeug, Jinja2, SQLAlchemy, Babel等を利用して書かれている。実際に動かしてみた訳ではないが、コードを読む限り、バージョン0.1と言いながらも、コードの質も、コード内のコメントも、モジュールの構成の仕方も非常にセンスを感じる。SQLAlchemyの使い方にも参考になるところ多数。WerkzeugもJinjaも知っていたが作者が同じというのは初めて知った。Werkzeugでこれだけの良質なものが作れるとすると、Django, Pylonsに迫る勢力になることは間違いないと思う。【追記】ローカル環境で動かしてみた。 SQLAlchemyのtrunk版でないと動かない(5.0rc4ではダメ)。WordPressのようにテーマが豊富ない？以外は、WordPressと遜色なく使え
開発サーバにmod_wsgiを利用する - スコトプリゴニエフスク通信
Djangoで開発する時は"manage.py runserver"を使うのが一般的だと思いますが、以下のページで紹介されているスクリプトを利用するとmod_wsgi上で開発を行うことができます。http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode#Restarting_Daemon_Processes"Example code for such an automatic restart mechanism..."以下のスクリプトを、たとえば、myproject/utils/monitor.pyとして保存して、mod_wsgiの起動スクリプトの中で、monitor.start()を呼び出します。 # -*- mode: Python; -*- import os os.environ['DJANGO_SETTINGS_MODUL
gearmand 0.7 - スコトプリゴニエフスク通信
Gearmanのページは更新されていないけど、gearmand 0.7がダウンロードできるようになっていた。0.7 - 2009-05-31 * Added libmodconf for config option processing. Eventually this will be split into a separate library. Updated gearmand and tests to use libmodconf. * Fixed persistent queue bug where jobs were not removed after replay. * Fix for bug #379198. * Changed done() function for queue, function_name is now passed to it as well as uni
OpenSocialを勉強してソーシャル・アプリケーションを作ろう - スコトプリゴニエフスク通信
いささか時期を逸し、劣化コピペ感は否めないのですが、前エントリとのバランス(謎)をとるために掲載しておきます。 これまでずっとなるべく言わないようにしていたのだが、もう平たく/明快に言うことにしました。1)自前でソーシャルサイトを立ち上げるのはもうありえないと思う。だから、2)OpenSocialを勉強して既存SNS上で動くソーシャル・アプリケーションで成功する道を真剣に考えてみて欲しい。これまでは、1)は言わずに、2)だけ言ってきた。で、「OpenSocial」の中でも、私が知っている「ソーシャル・アプリケーションで開発する」ことの楽しさをなるべく具体的に紹介するようにしてきた訳なのであるが、前半も言うことにしました(実際はこんなこと言ったことないけど)。その理由は、若い人に早く気づいて欲しいから。年を取ったら駄目、というわけではないが、SNSを運営していて、その運営が長くなってくると、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
