#PySpa アドベント (23 日目)

PySpa がどんなイベントかは既に紹介されつくした感じですね。そもそも勉強会は "特定のテーマを共有し理解を深める" という目的のものが多いと思っています。PySpa は、それより "勉強したくなるようなテーマを発見する" ってのが大きいと個人的に思っています。私は
  • 勉強したいテーマを見つける
  • 童心に返って技術を楽しむ
  • 煙草エリアのベンチを温める
ために行っています。与えられてばかり、お世話になってばかりです。モチベーションしかり、趣味しかり、仕事しかり。

きっかけ
初参加は、5 年前ですかね？当時はフリーで主に某官公庁と某第三セクターの仕事をしていました。その前は九州の某移動体通信会社。仕事は設計とか、ドキュメンテーションとか、ベンダーコントロール (笑) とかがほとんど。ちょっとだけ Java とか Perl とか書いたりしてました。職業プログラマー。知識がないと仕事出来ないと思って務めて勉強会に参加してましたけど、その頃参加していた勉強会はほとんどスーツ着て行ってました。
上京した時にすごいと思ったのは、ブログで追いかけてた技術者のお話が勉強会で普通に聞けること。特に意味もなく週 2 ぐらいのペースで勉強会に参加してました。ただ極度の人見知りなので、誰とも話すことなく帰る。懇親会とか参加できるわけがない (未だにめったに参加しないですが)。そんな時にお会いしたのが PySpa の主催者 V さんと MiCHiLU さん。煙草部屋でお話した落合さんに誘われた初参加の懇親会。その懇親会でいきなり V さんに "今度 Python 書く人とで温泉に集まるからおいで" ってお誘いされました。いきなりお泊りとかビビりまくり。その後 Skype で "お前のコードは残念すぎる" と言われてさらにビビりまくり。有難いこですがｗ 懐かしい
参加してみて
V さんに "なにやるんですか?" って聞いても "適当" ってしか言われず。参加初日 "適当" の意味がよくわからなかったので、ドキュメントの翻訳とか Vim プラグインとか書いてました。でも文字通適当な感じでした！ブログで追いかけてた技術者がいじられてる。。好きにコード書いて、温泉入って、ゲームして、飯食って、本読んで、夜な夜な盛り上がるという。御言葉に甘えて 2 日目は中村さんと煙草部屋にこもって懐かしのアニメとタモリ倶楽部見せて頂きました。3 日目からは煙草エリア。中村さんと新幹線と温泉の意外な関係を教えていただいてる間に解散時間。あれ、なんもやってない。その頃、家に帰れないぐらい多忙だったので、ほんと良い休養って感じ。
これでほんとに良いのか疑問に思って、2 回目はちゃんとテーマを準備しておいたんですが、これも全然ダメ。2 回目からはずっと煙草エリア (定位置) に居座って夜な夜な盛り上がってます。その場にいると、心底技術者で、プログラマーで良かったと思えます。そのぐらい楽しいです。
特にテーマを決めずに技術者が集まると、適当に遊びながら面白い技術と触れあえる。ということで、3 回目からは勉強したいことを見つけるために PySpa に参加してる感じです。
  • 岡野さんから教えて頂いた Django
  • 中村さんから教えて頂いたマインドストーム
  • 小田切さんから教えて頂いた Qt (PySide)
他にもいろいろ。みなさん教えるのもうまいんです。PySpa 後は楽しく勉強しております。そしてそれが仕事にも役に立っているという。良いですね！多謝。
転職とか
私も PySpa で転職した組です。お陰様で楽しく技術者やってます。上から下まで。色々教えて頂きつつ、勉強しつつ、周りから刺激を受けつつ。先輩に怒られそうですが、いろんな意味で超自由に仕事してます。仕事が楽しいってのは幸せなことです。
煙草エリアについて
人見知りな私にとって、とても居心地が良い空間です。煙草エリアは、技術書読んでたり、夜な夜な会合が行われています。会合の内容は
  • a2c さんと 1 億あったら何をするかって話: もう老人ホームに入っちゃってその後一生面倒見てもらうってことで落ち着いたと思う
  • V さんとドーパミンのお話: ソシャゲはすごいってお話
  • taichi さんと koshinuke のお話: "git を直訳すると koshinuke"。
  • ransui さんと aodag さんの新技術の話: ...
10 個ぐらい書いたけど消去。自粛します。表立って紹介できないのは残念ですが、3 日間徹夜で話しても飽きない内容です。
ダラダラと書きましたが、色んなバックボーンの人が一同に集まって適当に好きなことをやれる場所ってのはすごいことだと思います。勉強するきっかけはたくさんあると思いますが、私が勉強してるテーマのきっかけは PySpa ってことが多いです。これはいろんなバックボーンの方がいるからでしょうし、その中でも濃い方が集まってらっしゃるからだと思います。こんな勉強会がもっとあれば、幸せな技術者も増えるのではないかと。書いてたら行きたくなってきた。次は是非参加したいです！
煙草は百害と五利ぐらいはあるかな。
あしたは Sphinx を教えて下さった @shibukawa 先生です。

コメント

コメントを投稿

このブログの人気の投稿

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 を処理する キャッシュしたところで...
続きを読む