Lucky Life Mountain Live

送信者 LuckyLifeMountain_Live
昨日は久しぶりに嫁さんとライブに行ってきました。いつもよくしてもらってる、"Ubuman"こと生方ノリタカさん(公式サイト)。テルミンという珍しい楽器と、エフェクトにMac Bookを使ってライブされてます。今回、Lucky Life Mountainという、テルミン、尺八、コントラバスと、固定された音律を持たない三種類の楽器が織りなす、未体験の音楽世界トリオ(公式サイトより引用)を結成し、その1stアルバムの発売を記念し、全国津々浦々でライブされてるようです（ライブスケジュール）。テルミンの不思議な音色と、尺八の差音が絶妙なバランスで、不思議な世界に引き込まれていくような感じ。行ってあげてくださいｗ

ちなみにMySpaceでは、生方さんが製作されている音楽が視聴できますので、是非(MySpace)。

それと、ライブは東渋谷の鈴ん小屋(りんごや)というところでした。料理が全部有機野菜なので、相当美味しかったです(公式サイト)！

コメント

コメントを投稿

このブログの人気の投稿

Python から Win32 API 経由で印刷する

Win32 API から印刷をするためには、プリンタデバイスコンテキスト (Printer DC) を利用します。具体的には以下のような順序で印刷します。 プリンタドライバからハンドルを取得する プリンタドライバのステータス API から印刷可能か同かを取得する プリンタデバイスコンテキストを作成する ドキュメントを開始する 必要であればフォント等を設定し、印字、改ページ処理などをする ドキュメントを終了する (この時点でプリンタスプールサービスに登録されるようです) プリンタデバイスコンテキストを開放する プリンタドライバのステータス API を監視し、印刷が正常に終了したかを取得する プリンタドライバのハンドルを解放する 太字の手順 (3 - 7) は Win32 API で共通ですが、それ以外の手順 (1, 2, 8, 9) はプリンタドライバに依存しているため、Python から制御したい場合はライブラリを作成する必要があります。これについては、ドライバマニュアルとにらめっこしながら ctypes.windll でがんばります・・・。プリンタ接続、用紙切れ、ミスフィード等のプリントエラーを制御する必要がなければ、書く必要はありません (排他制御が必要なプリンタを除く)。プリンタドライバ毎に変わる部分は置いといて、太字の Win32 API の部分の覚書です。 プリンタデバイスコンテキストを作成する import win32ui import win32con PRINTER_NAME = '[コンパネ -> プリンタとFAX -> に登録しているプリンター名]' PIXELS_PER_INCH = 1440 # 1 インチ毎のピクセル数 INCH_PER_POINT = 72 # 1 インチ毎のポイント数 SCALE_FACTOR = int(PIXELS_PER_INCH / INCH_PER_POINT) #　わざわざ計算せず 20 と指定する場合が多い dc = win32ui.CreateDC() dc.CreatePrinterDC(PRINTER_NAME) # 指定したプリンタ名のプリンタデバイスコンテキストを作成する self.dc.SetMapMode(win32con.MM...
続きを読む

Disqus のスケール - Django 編

イメージ
やり直し。2010 年の Django Con のスライド より。 Disqus は多くのサイトに組み込まれているサービスのため、メンテナンスによる停止が難しい。 >>> サーバの構成 エッジロードバランサーに HAProxy: heartbeat 構成。レポートが素敵。 HTTP ゲートウェイキャッシュに Varnish Django サーバとして Apache + mod_wsgi: 30 台ぐらい。メモリリークを防ぐために maximum-requests をセット。Ganglia で監視 キャッシュに memcached: 25 台ぐらい PostgreSQL ロードバランサーに HAProxy/ PgBouncer : コネクションプール用。 PostgreSQL: 10 台ぐらい。 Slony-I で非同期レプリケーションとフェイルオーバー。 ログは syslog-ng: pgFouine でスロークエリーをロギング。 全部でサーバ 100 台ぐらい。他にユーティリティサーバ 15 台、後は HAProxy と heartbeat 用に 20 台ぐらいの構成。Varnish と syslog-ng を除けば Django のデプロイ手順に掲載されているような教科書通り (良い意味です) の構成です。(なんで Apache なの？nginx + gunicorn 速いよって突っ込まれてますね >>> データベースのパーティショニング Django はアプリケーションレベルで簡単に 垂直 パーティショニングができます。アプリケーションごとに DB 分けたり、DB をアプリケーションレベルでルーティングできます ( ドキュメント )。 水平パーティショニング (a.k.a シャーディング) もアプリケーションで 書ける (なるほど・・・)。 >>> キャッシュの削除 Django は QuerySet の結果をキャッシュするけど、それがかなりメモリを消費する。なので SkinnyQuerySet を作った (たぶん Johnny Cache の方が有名？...
続きを読む

Disqus のスケール - Django で月間80億PVを処理する

私が把握してる限り Django で一番大きなサービス Disqus のスケール (執筆時点ではサービスダウンしてる)。元ネタは Scaling Django to 8 Billion Page Views です。 月間80億PV 、 45k req/s のほぼすべてのトラフィックを Django で処理しているとのこと。抄訳になるかな。 WAF は 高速開発とパフォーマンス 、 新しい人が入ってすぐに開発に参加できることとカスタマイズ 等のトレードオフがあります。この記事ではそのトレードオフである高速開発とパフォーマンスをどう両立させるか、Disqus のノウハウが紹介されています。 >>> なぜ WAF (Web Application Framework) は遅いのか 最初に思い浮かぶのは、アプリケーションに必要ではないボイラープレート ( django.contrib とか?) や不要なコードがあるため。そもそも Django の思想が Python 同様 " バッテリー同梱 (batteries included) " のため、Django は他の Python 製 WAF よりボイラープレートが多いです。Disqus 曰く "実は 言語や WAF は遅さにあまり関係ない " それより " ネットワーク内の他のサービスとの通信 " のオーバーヘッドが原因とのこと。これは一般的によく言われてることですし、大規模になればなるほどそう。Disqus の場合は PostgreSQL, redis, Cassandra , Memcached 等のサービスが使われているそうです。DB へのスロークエリーやネットワークのレイテンシーは Django のようなボイラープレートによるオーバーヘッドを軽く上回ります。この待ち時間を回避する一番メジャーな方法はキャッシュの使用です。Django では キャッシュフレームワーク を使用します。Django でキャッシュを使うのは簡単ですし、バックエンドに Memcached を使うと充分高速化できます。 はい。ここまでは一般的な話です。こっから。 >>> 45k req/seq を処理する キャッシュしたところで...
続きを読む