Twisted Mind

予定は未定です

定期開催が無くなり、不定期開催だけになった Python 温泉ですが、さっそく今年 6 月に開催をしたいと考えております。

第１候補日 6/22 ~ 6/24
第２候補日 6/29 ~ 7/1

参加費用は 1 泊 1 万円で 2 泊で 2 万円です。

（お菓子代、タオル代含む）

余ったら主催者判断で寄付したり飲み会のドタキャンに補填したりとか使わせて頂きます。

参加資格: #pyspa または #pyfes 参加経験者
場所: 芳泉閣

詳細は追ってこちらに書かせて頂きます。

主催＆皆勤

@voluntas
@aohta (未定)
@tokibito (未定)
@nishio (未定)
@aodag (未定)

Permalink | コメント(0) | トラックバック(0) | 22:35

2012-01-17

boto を使って Sphinx を S3 にデプロイする

python, aws, s3, boto

やりたかったこと

毎回 AWS Console からデプロイするのはアホだし、ミスも生まれるので自動化したかった

結論

わざわざ S3 にデプロイする必要なんかなくて、レンタルサーバ借りて FTP でデプロイしても別に何も問題ありません。
いくつかの条件がマッチした場合はいいかもしれません。
商用利用の場合はまずはレンタルサーバを検討しましょう
OSS の場合等は AppEngine または github/bitbucket などを活用しましょう。

S3 を使う条件とか

今回はいくつかの条件が当てはまったので .. S3 にしました

もともと会社が AWS のアカウントを持っていた
DNS の設定だけで良かった
そもそも１日１００人くるサイトではない
社内である程度確認作業をしたらさくっとデプロイしたかった
商用製品サイトである

人気サイトは基本静的 HTML だけなんてサイトが無い気がするのでかなりレアですね。

ちなみに今のところ 1 日 5 円程度です、運用費用。

コード

boto は昔ちょろっとバックアップツールを作ったときに使ったことがあっただけで、それ以外は使ったこと無いので、かなり久々でした。

やってることは Sphinx のビルド済みのディレクトリからファイルを根こそぎ持ってきて S3 の指定したバケットにアップロードしているだけです。

ポイントというものはほとんどありませんが ... 以下の二点くらいは意識しました

公開もセットでやる
reduced_redundancy も自動で設定

本来は github と連携して自動で checkout してビルドするくらいはやりたかったのですが、やめておきました。最終的にはそこまで行きたいですね。

import os
import os.path

from boto.s3.connection import S3Connection, Location
from boto.s3.key import Key

S3_ACCESS_KEY = 'access-key'
S3_SECRET_KEY = 'secret-key'

S3_BUCKET_NAME = 'bucket-name'

SPHINX_BUILD_HTML_DIR = '/path/to/doc/build/html'

if __name__ == '__main__':
  connection = S3Connection(S3_ACCESS_KEY, S3_SECRET_KEY)
  try:
    bucket = connection.get_bucket(S3_BUCKET_NAME)
  except:
    bucket = connection.create_bucket(S3_BUCKET_NAME, location=Location.APNortheast)
    bucket.set_acl('public-read')
    bucket.configure_website('index.html')

  for root, dirs, files in os.walk(SPHINX_BUILD_HTML_DIR, followlinks=True):
    for filename in files:
      full_path = os.path.join(root, filename)
      path = full_path.replace(SPHINX_BUILD_HTML_DIR, '')
      key = Key(bucket, name=path)
      key.set_contents_from_filename(full_path, reduced_redundancy=True)
      key.make_public()
      key.close()
      print path, 'uploaded'

  print 'url:', bucket.get_website_endpoint()

感想

boto 良く出来てますね、さすが AWS 人気とも言えるのか、サンプルコードも結構あったりして助かりました。

これで boto さえ入っていれば python スクリプトを叩くだけでデプロイが出来ます。ありがたい。

git-flow 使っていれば master ブランチを定期的に監視してデプロイとかもいいかもですね。

ただ S3 を使うメリットってそんなに無いんですよね ... 課金もある程度かかりますし。

今回は偶然マッチしたという位だと思います。

Permalink | コメント(0) | トラックバック(0) | 02:14

2012-01-14

Flask の使いどころ

python

Web アプリを仕事ではほとんど書いたことが無かったのですが、Flask を仕事で使う事にしたので、書いてて感じた Flask の使いどころを。

追記

コメントに色々な意見を頂いておりますので、是非そちらも。

がっつり使われた方の感想

Flaskを１年仕事で使った感想 - kawaken’s blog http://d.hatena.ne.jp/kentaro_kawano/20120115/1326612808

結論

とりあえず箇条書きで ...

データベースサーバとの接続が前提なら、 Flask を使うのはやめる
Flask-* という Flask の拡張を使う時点で、Flask を使うのはやめる
大規模で Blueprints を使う前提なら、Flask を使うのはやめる
小さなアプリでプラガブルな仕組みを自分で作るには良い
パーミッションは Flask-Principal が良さそうだが、更新はほぼ止まっている
- github 上で、 clone してやっている人はいますが、コードが増えすぎているのでアウト
フォルダ構成を考えるのがかなり面倒
ドキュメントがちゃんと書いてありそうで意外に書いてない
情報が多そうで正直そんなに多くない、Django の方が全然多い
ある程度なら Pyramid がこれから来るのかな
- Bottle は 1 ファイルタイプなので Flask と同じ道をたどる気がしている
- Pyramid はドキュメントが膨大なのは魅力、また色々な機能が（最初から入っている）
中規模であれば Django でイイと思う
- 大規模はそもそも Python でいいのかという問題があると思う

Flask の問題

そもそもパーミッション関連が一切ないので、自前実装前提
データベース連携は自前でやるので Flask-SQLAlchemy 等を使う前提
色々やろうとし始めると、まったく機能がないので色々実装する事になる
- つまりそもそもある程度ライブラリとかを実装できる前提
Flask で書かれた OSS が意外にない
- 知らないだけかも
json を戻すとかその辺に気が利いてない

基本は機能が足らないです。Django をマネして色々な機能を追加したりしているようですがどれも中途半端です。

Flask の魅力

プロトタイプを作る場合はさくさくできる
データベース連携しないでモックとか、こんなイメージでは良い
データベース連携しないものなら、そもぞもデータベースが連携が考慮されていないのでいい感じ
- たとえば外部の API との連携しかしないサーバとか
Flask をコアとしてそれ以外は全部自前で実装するというのであれば正直ありだとは思う
- ただそれを仕事でやるのはかなり不毛だとおもうので、ある程度オールインワンなフレームワークを使うべき
良くも悪くもシンプル
ちょっとしたサイトを作ってみるというのにはかなり向いていると思う
これで足らないライブラリやモジュールを書いて、色々学ぶというのには最適

Flask を選んだ理由

そもそも外部データベースを使用しない
外部 API がメイン
拡張を使う予定が無い
- 使うとしても Flask-Principal くらいで、これも fork して自前で書き直すので問題無い
ページ数としてはかなり小さい

感想

最初は Django で書いていたのですが、テストとか色々やりづらかったり、元が大きかったり、データベース連携が前提だったりと、あまりにも大きすぎて Flask に切り替えました。

Blueprints は便利ですね、自分でプラガブルな仕組みが作れるのはありがたいです。

Flask を業務に持ち込むとしたらかなり限定的な状況な気がします。また作る人は多くても 1~2 くらいでしょうか。それ以上になると、オレオレのコードが増えてきすぎて、別のフレームワークを採用した方が、イイ気がします。

基本的にデータベース連携しないウェブアプリはほぼ無いと思いますので、それがある時点で Flask は選択肢から外れるんじゃ無いかなぁと。ちょこっとしたツールやウェブサイトを作るにはサクサク作れていいんですけどね。

さすがに仕事で作るとメンテナンスや拡張が合ったりすると思うのでそれを考えるとかなり厳しい気がします。

Permalink | コメント(7) | トラックバック(1) | 14:42

2012-01-07

商用サイトに Sphinx を導入してみた

sphinx

商用の製品紹介サイトに Sphinx を導入した事について書いてみます。

結論

とりあえずの結論

非技術者でも HTML を知らずに気軽に更新できる
うまくテンプレート化されているのでページ追加が簡単
静的 HTML なのでリリースが簡単
結局画像の修正が大変
文章中心のサイトじゃないと意味が無い
非技術者が Windows/Git という組み合わせを覚える必要がある
枠組みをデザイナに作ってもらえれば、社内で色々好き勝手にいじれる

導入

製品の紹介サイトを作るというプロジェクトがありました。今までは CMS 等を使ってきていたのですが、今回は思い切って Sphinx を導入することにしてみました。

Sphinx のテーマを作ってもらえれば自社内で更新が気軽に出来るし、メンテナンスコストも低くなると考えたからです。

まず、社内に Web デザイナがいないため、誰かに白羽の矢を立てる必要がありました。ここは以前から交流があった @kinofumi に無茶を前提でお願いすることにしました。

Web デザイナにお願いしたこと

Sphinx のテーマを作って貰う
最低限のドキュメントを流し込んだ状態で文章の見え方を整えて貰う

この二点です。正直 Jinja2 までゴリゴリ使っていただけるとは思っていませんでしたが、結果的にはかなり奥まで突っ込んで作って貰いました。

また、 @aohta がその過程で Sphinx の拡張プラグインを作ったりもしてました。

やりたかったこと

一番は、製品の魅力を伝えるのは非技術者です。つまり営業、広報等です。ただ、その場合は HTML や CSS の知識が前提になったり、CMS を建てたりとかなりハードルが上がってきてしまいます。

自分がやりたかったのは、営業が気軽に「文章作業」だけに没頭できる環境でした。

Sphinx はその点、文章の構成に集中出来ます。これはかなり大きいと思います。

ちなみに "おされなサイトを作るのが目的では無い" これは重要なポイントですね。

実際に出来たこと

非技術者が気になったところを簡単に修正できた

非技術者に一番壁だったのは、正直 Sphinx というより Git でした ... 。ただ Commit/Push/Pull だけ教えたらある程度理解してくれました。

reST は、ベース部分の文章は非技術者に Word で書いてもらったものを、技術者がまずは流し込んで構成だけ確認する。あとは日本語の修正等は非技術者で行ってもらえました。

テーマの修正を社内で気軽で出来る様になった

またテーマ自体を作成してもらったため、CSS を少しいじればかなり融通が効く状態になりました。また @shkumagai のような Sphinx のテーマ作成技術に熟知している人が身近にいたため、かなり対応が楽でした。

リリースが簡単

リリースは今回 AWS の S3 のウェブホスティング機能を使用してデプロイする予定です。リージョンを Tokyo にすればかなり早いし、メンテナンスコストがかなり低いです。DNS の設定だけでした。

金額的にもかなり低く抑えられるんじゃないかと考えています。

決まってからが早かった

デザインが決まるまで色々試行錯誤してましたが、デザインが決まってからはかなり早かったです。これはもちろん Web デザインを担当してくれた @kinofumi の実力がほとんどなのですが Sphinx のシンプルさというのも少しは影響したかなと。

そうそう、@kinofumi が今回の話しを書いてくれるようですので、期待ですね。

感想

実はデザインの確定に時間がかかって Sphinx 関連は二の次だったのですが ... 、かなり満足のいく物が出来たと感じています。HTML はいじっていませんし、文章を追加/修正するのも全て reST で書くだけです。

おしゃれなサイトでバーンと何かアピールするのには向いていませんが、商品を説明して理解して貰うサイトを作るにはかなりいいかなと感じました。

ただ、jinja2 で Sphinx テーマを作ってくれる Web デザイナさんはその辺にいるわけではないですし、これまた壁が高いと言えば高いかも知れませんね。

ここで、これが Sphinx で作った商用のサイトだ！って紹介したいところですが ... まだリリースが終わってないのでお待ち下さい。

今回は @kinofumi と初めて仕事させていただいたのですが、とても楽しかったです。 Sphinx で Web サイト作りに興味がある方は是非相談してみるとイイと思いますよ。

追記

リリースしました。

http://fullflex.accense.com/sg/

Permalink | コメント(0) | トラックバック(0) | 01:33

Sphinx (PDF 出力) を導入してみた

sphinx

注意: PDF 出力を前提とした話しになっています

OSS のドキュメントとしてはよく使われておりますが、実際に仕事の道具として導入してみた人はあまりいないのではないでしょうか。

導入のきっかけや、実際導入した際の環境などを書いて行ければと思います。

注意事項としては Sphinx を自分自身はまったく使いこなしていないので、Sphinx やそれらの「技術的」な話しは出来ません。そこを期待されている方は @aohta に「話しを聞きたい」とかリプライ飛ばすともしかすると書いてくれるかも知れません。

ドキュメントツール導入のきっかけ

もともと Word が使いづらく reST を自分個人で使い続けてました。使い始めたきっかけは @everes が使っていたからだったと記憶しております。一人でほそぼそと使っていましたが、rst2pdf がきっかけになって社内で使ってみたらどうか？という話が出てきました。ただ rst2pdf では色々限界があったので Sphinx に至っています。

導入自体は Sphinx がメインというわけではなく、PDF 出力が最大の目的でした。

ドキュメントツールへの条件

ドキュメントツールへの条件を明確にしておきたいと思います。

以下の３つがドキュメントツールへの条件でした。

テキストファイルであること
バージョン管理 (Subversion/Mercurial/Git など) 出来ること
PDF 出力が出来ること

そのため最初は reStructuredText + rst2pdf を使用して色々な場所で試したりしていました。

PDF の展開先

PDF にする対象は自社製品のマニュアルのため、展開先は身近な誰かではなく"安くないお金を出して買った製品購入者や導入者"です、かなりハードルは上がります。Word レベルでもかなり厳しいと感じていました。

rst2pdf の限界

Sphinx の導入は、rst2pdf の限界もありました。あまり覚えてないのですが @aohta から「rst2pdf はもう無理だから捨てよう」って言われたのがきっかけだったのかも知れません。

Sphinx(PDF 出力) 導入

正直上を説得するとかはありませんでした。もともと rst2pdf は採用されていましたし、幸運な事に現場の技術的判断がほとんどの面において自分で出来る位置だったので、自分が責任をとる前提で Sphinx の導入を推し進めました。

ドキュメントの Sphinx 化、つまり Sphinx から PDF を生成するという作業はそう簡単には進みませんでした。時間にして数ヶ月はがっつり取り組んで貰ってやっとこさスタートにたったと記憶しています。

このときはドキュメントツールの調査や作業などを @aohta や @itawasa が色々やってくれました。

pLaTeX 経由で素敵な出力にするまで数ヶ月かかったような気がしています。さらに 1 からドキュメントをごりごり書く機会もあったりして、試行錯誤が半年以上続いたと思います。

Sphinx(PDF 出力) 継続

Sphinx から pLaTex 経由での出力は、pLaTex の知識がある程度いるようで @aohta や @itawasa はそっちけいの本を色々読んだり、調べたりしていました。つまり PDF 出力を前提とする場合は Sphinx や reST の知識だけでは無く pLaTeX の知識も必要となってくるようです。

ちなみに、当たり前ではありますが、最新の Sphinx や Docutils に追従はしています。

Sphinx(PDF 出力) 発展

自分が携わる案件の納品用ドキュメントは全て Sphinx を採用しました。ただ、やはりまだまだ課題は沢山あるようで仕事の暇を見て色々試行錯誤しているようです。

また仕事柄 seqdiag がかなり嬉しいので、こちらも @tk0miya を呼んで「ここをこう修正してくれないと仕事で使えないから修正して」という無茶なお願いをしたりしました。

おかげで seqdiag も正式に仕事の道具として採用させて頂きました。この場を借りて改めて @tk0miya に感謝します。

Sphinx (HTML 出力)

追記: 2012-01-07

社内で HTML 版をどの程度使っているのか考えると、そんなに使っていません。これはなぜか考えると github の reST プレビュー機能がかなり優秀なんですよね。Sphinx の用に体系的にまとめていく必要のある文章は外に出す文章が主で、社内は 1 つの情報は 1 つの reST ファイルで収まることがほとんどです。

ただ、定常的に見られる情報については github -> jenkins -> 社内サーバデプロイという流れをとってはいます。ただやはりその場で編集できないと定常的に見られる情報としては厳しいのかなぁと。

社内はの非技術者向け情報管理は結局 google sites に落ち着いてしまいました。

環境

ここで、導入環境を説明しておいた方がいいと思います。まずは今の環境を。

正直、かなり恵まれている環境だと思います。このメンバーでもかなり苦労しました。

メンバー

@aohta
- ドキュメント全般をいじっていて Sphinx にもパッチを送っている
@itawasa
- pLaTeX 周りを色々といじって Sphinx にもパッチを送っている
@shkumagai
- Sphinx の有名テーマ作者、さらに reST についてもかなり明るい

スキル

全員が Git を使いこなし、github も使える。さらに reST に関しては誰も困らないくらい理解をしている。

ビルド

Jenkins が自動で Sphinx から PDF に変換してくれる、コミット事に自動でビルドしてくれる。

感想

注意: PDF 出力が必須の前提で書いてます

まず Sphinx は気軽な気持ちで導入するようなものではありません。ハッキリ言って Word で十分なら Word にすべきです。特に PDF となると導入しないほうがイイと思います。Word の置き換えとして検討するべき物では無いかなと思います。

もし導入したい場合は、仕事として Sphinx/pLaTeX に触れられる事、ドキュメントの大切さを理解している環境があること、バージョン管理が既に導入されていることが導入する条件の最低条件だと思います。

PDF 出力前提で書いていますが、メンテナンスする人やバグが出たときパッチを当てる人、まぁこの辺は OSS ですからその辺は割愛しますが、Word でいけるならできる限り Word で行くべきです。

また、Sphinx を導入したから全てがうまくいくわけで貼りません。銀の弾丸なんてないですし。そもそも Word でなぜ失敗したのかを考えるべきです。多くの場合はルールがなかったりすることの方が多いのでは無いでしょうか。

Sphinx を導入すればますますルール決めが重要になってきます。バージョン管理も含んできますし。

なので、Sphinx を "仕事" で使おうとしている人は、Word でダメな理由をしっかりと考える必要があると思います。

なんか、凄く否定してばかりですが、個人的には導入して大成功だと思っています。大きな投資をした分、ドキュメントのコストがかなり減りました。それもこれも @aohta や @itawasa のおかげなのですが。

追記: 2012-01-07

書いた後色々な人に突っ込みを貰ったので、頭を冷やして考えてみたのですが、正直 HTML 出力だけの場合は社内に導入するメリットってあんまりない気がしました。

PDF 出力が出来る前提じゃないと Sphinx の導入はなかったという感想です。頻繁に更新する場合は wiki の方がいいでしょうし、マニュアルとして書くなら PDF 出力が欲しくなってくると思います。

ただテキストファイル + バージョン管理 + 統合という観点で行くのであれば導入は可能な気がしました。

ただ、今は git clone 出来る wiki とかあるので素直にそっちを使った方がいい気がしないでもないです。

結論

あくまで環境を考えてから導入を検討すること。Sphinx は銀の弾丸ではありません。ただ上手く使えば凄く便利なツールです。使いたいから使うのでは無く、"維持を楽にする" や "コストが削減する" 等の現実的な目的をもって導入を検討しましょう。

追記: 2012-01-07

PDF 出力を前提に導入するなら壁は高いですが導入に成功すればかなり良いです。ただ HTML のみの場合は wiki 等を検討してみた方がいいのかも知れません。wiki はドキュメントの統合管理という意味ではかなり便利ですし。

もちろん外部に Web で公開するドキュメントとしてであれば HTML だけでも全然ありだと思います。

社内で HTML 出力だけでも Sphinx 導入したらこんなに幸せになったよという話しはどなたか是非。

Permalink | コメント(0) | トラックバック(0) | 00:47

2012-01-01

2012 目標

other

英語
仮想化
自動化
Clojure/Ring

色々考えたのですが、今まで以上に大きく伸ばしたいのが４つくらいしか思いつきませんでした。

あとはこれらに色々付随しているので、なんとも。

英語と仮想化は、当面自分に足らないスキルの一つなので。

自動化は自分がメインで出来るかどうかはわかりませんが、今年は積極的に力を入れていきたいです。

Clojure/Ring は、ウェブアプリ構築としての Clojure という意味です。それ以外に手を出す予定はあまりありません。あったとしても Storm くらいでしょうか。

実はこれに PyQt みたいに GUI アプリも入れたかったのですが、色々考えて無理そうだったので諦めました。

さて、今年も焦らず、やれることからやっていきたいと思います。

2012 目標の解説とか思いとか

英語

やるしかないので省略

仮想化

XenServer をベースにしつつ Open vSwitch やらなんやらで OpenFlow 系も触りたいです。仮想サーバ、仮想ネットワークなどを積極的に。もちろんストレージ周りも触れたらいいなと思っていますが難しそう。

サーバを気軽に使えるような仕組みを作っていきたいなぁと。

自動化

Chef を触っては見たいのですが、まぁそれだけでなく Jenkins やらなんやら、自動化のメインは計測です。統計関連もこれには絡んできますね。自動で性能を測るとかがやりたいです。仮想化にも繋がってきますね。

仮想環境を使って、環境自体も全て自動で出来る様にしたいです。Jenkins もビルドが詰まってきたら自動でインスタンスあげて分散とか。

Clojure/Ring

ウェブアプリで、個人的に jar ファイル一つになるのはいい感じ。ただ今から Java/Scala を覚えるスキルは無い。となると気になってた Lisp 系でここはひとつ。って感じです。

Ring がかなり短いコードで実現されていることが一番の理由かもしれません。自分がやりたい事がかなり短く書けそうです。

ただ、今年は勉強で終わるのかなぁという気もしています、もしかすると飽きてるかも知れません。長くやっていければいいなと思っています。

Permalink | コメント(0) | トラックバック(0) | 16:35

2011-12-31

2011 振り返り

other

新しい技術を身につけるのは苦手なので正直ほとんど何もしていません。

Clojure

ただウェブ系のお仕事が出てきそうなので Python でいくかと考えていたところに Clojure/Ring が登場してきたので、少しずつではありますが Clojure を勉強し始めた年でした。

Python -> Erlang -> Clojure と来るとは思っても見ませんでした。

Python と Erlang は既に仕事で使っているので Clojure も仕事に組み込めればいいなと。

個人的には「仕事で使うと覚えが早い」というのがあるので。

Sphinx

あとは、Sphinx 周り、自分は何も頑張っていませんが仕事でガッツリ使えるようになりました。

ドキュメントしかり、ウェブサイトしかり。来年もこの辺はやっていこうかなと。

やっていこうといっても自分でやらず @aohta や @shkumagai に任せっきりですが。自分は方針出すだけ。

Riak

少し調べたりはしましたが、これも仕事で使えるようになりそうなので、あんまり追いかけてないです。まぁ @itawasa がいるのでなんとかなるであろうくらい。

Erlang

仕事でがっつり使っている上に、Erlang Workshop 2011 で色々な出会いがありました。後数年は使い続ける言語だと思います。

github

大きく変わったことの一つとして、Github を仕事で使うようになったというのがあります。便利ですね。ただ issues はまだまだなので運用側でかなり苦労しています。

Python 温泉

定期開催を終了しました。来年からは適当に１年に１回程度出来たらいいなと。

Python Developers Festa

Python Hack-a-thon から名前を変えました。ハンズオン + モクモク + プレゼンの３点セット。

Mercurial (バージョン管理)
Sphinx (ドキュメント)
Python (初級から上級まで)
テストとかなんかその辺

上記 4 点のハンズオンを主軸にしつついつもと変わらない適当さで進めていくつもりです。

Python 忘年会

今年も無事終わりました。新年会やってほしいという声があるので開催予定です。

2011 新年に立てた目標

英語、IPv6、仮想化でしたが残念ながらどれも出来ずに終わりました。英語は少しやりはじめたかな、と。

IPv6 に関しては仕事では扱いましたが積極的にどうこうできなかったなぁと。

仮想化については XenServer 構築して終了。ほとんど何もせず ... 。

ウェブ系

ウェブ関連は Sphinx ベースだったのでなんともですが、今まで欲しかった mockflow というモック生成ツールに出会えたことで開発者に「これがほしい」を伝えやすくなった気がします。これは大きな進歩。

自分自身はデザインも何もかもダメなので、その辺は他の人任せを来年も貫き通します。

ただ、新しい技術だけは追いかけておく必要はありますね。

Heroku

Heroku で Python や Erlang が動くようになったので遊んでみたりしました。ただ全然ですね。結局仕事で触れることが無いので、遊んで終わりでした。

来年は Heroku で何かデプロイできるような仕事を作れればいいなと思っています。

総括

なんか、技術とは別の一年だった気がします。やり方とか手法とか色々。技術チームで連携と営業と技術の連携それぞれ、考えさせられ色々実践してみて失敗したりうまくいったりした気がします。

来年もそれは変わらずですね。

ただ、もっと「システム化」していかないと行けないなぁと思いました。なんでもかんでもではなく「便利」にするシステム化。簡単に言えば社内システムをもう少し手を付けられるようにしていかないとなと。

一応技術力も売りにしているので、社内がアナログではねぇ、と。

新しい技術を余り追いかけられなくなってきているので来年は少しそこを打破できるようにしていきたいなと。

Permalink | コメント(0) | トラックバック(0) | 16:07

2011-12-18

Heroku 上で WebMachine (Erlang) を動かす

heroku, erlang

heroku コマンドが入っていない場合は gem install heroku で入ります。

まずは webmachine を持ってきて、webmachine ベースのアプリを new_webmachine.sh で作ります。

$ cd /tmp
$ git clone git://github.com/basho/webmachine
$ cd webmachine
$ make
$ ./scripts/new_webmachine.sh heroku_webmachine /tmp
$ cd /tmp/heroku_webmachine
$ make

それが終わったら、git 環境を作って heroku インスタンスを生成します。

その後、Erlang アプリが動く buildpack を設定に指定します。

heroku-webmachine というのは今回使っている名前です、基本的には自由に指定して下さい。

$ git flow init
$ heroku create heroku-webmachine -s cedar
$ heroku config:add BUILDPACK_URL=http://github.com/heroku/heroku-buildpack-erlang.git

erl 自体は入っているので、あとはそのままさくっと Procfile を用意します。

web: erl -pa ebin deps/*/ebin -noshell -boot start_sasl -s reloader -s heroku_webmachine

WebMachine ではポート番号が固定になってしまっているので、環境変数からポート番号を取得するような仕組みに変更します。ついでに常に 0.0.0.0 アドレスで開くようにしてしまいます。

%% @spec init([]) -> SupervisorTree
%% @doc supervisor callback.
init([]) ->
    %% Ip = case os:getenv("WEBMACHINE_IP") of false -> "0.0.0.0"; Any -> Any end,
    {ok, Dispatch} = file:consult(filename:join(
                         [filename:dirname(code:which(?MODULE)),
                          "..", "priv", "dispatch.conf"])),
    Port = list_to_integer(os:getenv("PORT")),
    io:format("start web server on port ~p~n", [Port]),
    WebConfig = [
                 {ip, "0.0.0.0"},
                 {port, Port},
                 {log_dir, "priv/log"},
                 {dispatch, Dispatch}],
    Web = {webmachine_mochiweb,
           {webmachine_mochiweb, start, [WebConfig]},
           permanent, 5000, worker, [mochiweb_socket_server]},
    Processes = [Web],
    {ok, { {one_for_one, 10, 10}, Processes} }.

あとは保存して、heroku の master に push します。git flow を使っているので develop ですが普通は master:master で問題無いはずです。

$ git push heroku develop:master
Counting objects: 19, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (19/19), 104.89 KiB, done.
Total 19 (delta 0), reused 0 (delta 0)

-----> Heroku receiving push
-----> Fetching custom buildpack... done
-----> Erlang app detected
-----> Building with Rebar
       ==> build_388qu6ci88xko (get-deps)
       Pulling webmachine from {git,"git://github.com/basho/webmachine","HEAD"}
       Initialized empty Git repository in /tmp/build_388qu6ci88xko/deps/webmachine/.git/
       ==> webmachine (get-deps)
       Pulling mochiweb from {git,"git://github.com/mochi/mochiweb",{tag,"1.5.1"}}
       Initialized empty Git repository in /tmp/build_388qu6ci88xko/deps/mochiweb/.git/
       ==> mochiweb (get-deps)
       ==> mochiweb (compile)
       Compiled src/mochinum.erl
       Compiled src/mochiweb_socket.erl
       Compiled src/mochiweb.erl
       Compiled src/mochiweb_echo.erl
       Compiled src/mochilists.erl
       Compiled src/mochiweb_response.erl
       Compiled src/mochiglobal.erl
       Compiled src/mochiweb_http.erl
       Compiled src/mochiweb_mime.erl
       Compiled src/mochiweb_charref.erl
       Compiled src/reloader.erl
       Compiled src/mochifmt_std.erl
       Compiled src/mochifmt_records.erl
       Compiled src/mochiweb_multipart.erl
       Compiled src/mochiweb_headers.erl
       Compiled src/mochiweb_socket_server.erl
       Compiled src/mochijson2.erl
       Compiled src/mochiweb_cover.erl
       Compiled src/mochiweb_io.erl
       Compiled src/mochiweb_cookies.erl
       Compiled src/mochijson.erl
       Compiled src/mochiweb_sup.erl
       Compiled src/mochihex.erl
       Compiled src/mochiweb_app.erl
       Compiled src/mochilogfile2.erl
       Compiled src/mochiutf8.erl
       Compiled src/mochiweb_acceptor.erl
       Compiled src/mochiweb_request_tests.erl
       Compiled src/mochitemp.erl
       Compiled src/mochiweb_util.erl
       Compiled src/mochiweb_skel.erl
       Compiled src/mochiweb_request.erl
       Compiled src/mochifmt.erl
       Compiled src/mochiweb_html.erl
       ==> webmachine (compile)
       Compiled src/webmachine.erl
       Compiled src/webmachine_perf_logger.erl
       Compiled src/wrq.erl
       Compiled src/webmachine_error_handler.erl
       Compiled src/wmtrace_resource.erl
       Compiled src/webmachine_deps.erl
       Compiled src/webmachine_resource.erl
       Compiled src/webmachine_mochiweb.erl
       Compiled src/webmachine_dispatcher.erl
       Compiled src/webmachine_sup.erl
       Compiled src/webmachine_multipart.erl
       Compiled src/webmachine_util.erl
       Compiled src/webmachine_request.erl
       Compiled src/webmachine_app.erl
       Compiled src/webmachine_logger.erl
       Compiled src/webmachine_router.erl
       Compiled src/webmachine_decision_core.erl
       ==> build_388qu6ci88xko (compile)
       Compiled src/heroku_webmachine.erl
       Compiled src/heroku_webmachine_resource.erl
       Compiled src/heroku_webmachine_app.erl
       Compiled src/heroku_webmachine_sup.erl
-----> Discovering process types
       Procfile declares types -> web
-----> Compiled slug size is 3.4MB
-----> Launching... done, v5
       http://heroku-webmachine.herokuapp.com deployed to Heroku

あとは、 http://heroku-webmachine.herokuapp.com にアクセスして貰えば動いていることがわかります。

感想

かなり簡単に起動できてビックリしました。いつも Mochiweb をそのまま触っているので WebMachine はほとんど触ったことが無く、はまるかな？と思ったりしましたが別にはまること無くさくっと出来てしまいました。

Heroku で Erlang が動くと言うことは、Erlang + Web を色々やってみたくなりますね。ということで次は Heroku が提供している DB とつないで何かしてみようと思います。

参考

http://zianet.dk/blog/2011/12/16/running-erlang-webmachine-on-heroku/

Permalink | コメント(0) | トラックバック(0) | 09:26

2011-12-08

Python 温泉 & Python Developers Festa グッズ開発

event

Python 温泉も定期開催が終了し、不定期開催となり色々と落ち着いてきたところなので、

グッズを作ろうかなぁと考えています。

もともと @moriyoshi のおかげで一回グッズを作ったことがあるのですが、せっかくなので再度作ろうと。

だったらついでなので Python Developers Festa 向けのグッズも作ろうかなと。

毎回 Python 温泉がおわると生まれる Python 温泉基金 (7 万円前後) を使って作ろうかなぁと思っていたのですが、デザインとか色々やってくれる人がいないので、結局 PSF に寄付とか復興宝くじを買ったりとかしてました。

で、今回作りたいなぁと言ったら ... Python Developers Festa (#pyfes) でおなじみの @sawonya が手を上げてくれたので、いい機会なので依頼しようと思いました。

@sawonya は"プロ"のイラストレーターなのでお金払ってしっかり作って貰おうと思います。

@sawonya ? って人はこちらをどうぞ http://www.sawonya.com/prof.htm

ステータス

2012-01-04

@sawonya に頂いたデザインで良いですという話しをしました
#pyspa は青+白を 200 枚、黒+青を 100 枚刷ろうとと思っています。マット仕上げです。
刷って貰う費用は 17000 円程度です
#pyfes は男女向けそれぞれ 300 枚程度、レアが 100 枚程度の予定です。

2012-01-01

@sawonya から #pyspa の案が来ました

@sawonya より

ドットとか、コマンドプロンプト的なあんなイメージだと面白いかなーと思って

そういうイメージで叩いてみました。

今のところ白＋青が優勢です。ただ黒＋青も一部に人気があるので、少しだけ刷ろうかなと考えています。

2011-12-09

@sawonya に依頼済み
形状については #pyfes は丸型、それ以外はお任せで依頼
#pyfes 用は 3 種類の予定、男性向け、女性向け、@sawonya ファン向け (レア)
#pyspa は @whosaysni が考えたものをベースにする
T シャツに関しても @camlspotter からお店を教えて貰ったので、対応予定です (こちらは有償)
T シャツに関しては http://www.artdirect.jp/printshop/ ここに依頼予定
ステッカーに関しては http://www.graphic.jp/ ここに依頼予定
- #pyspa と #pyfes は http://www.graphic.jp/lineup/ondemand/sticker.php これ
- 限定シールは http://www.graphic.jp/lineup/ondemand/premium.php これ

いまのところ考えている事

ステッカー用のベースロゴをまずデザインして貰おうと思います。

Python 温泉 (#pyspa) 用
Python Developers Festa (#pyfes) 用男性向け
Python Developers Festa (#pyfes) 用女性向け
Python Developers Festa (#pyfes) 用 @sawonya スペシャル (レア)

上記４つの案を考えて貰って、まずはステッカーを作る。

ステッカー自体はそれぞれのイベント参加者に"無料"で配ります。

ロゴのライセンスは CC BY-NC-SA で github にて公開予定です。

配布優先順位

Python 温泉最終回参加者 (3 種類全て数セット配布 + レアステッカー 1 枚)
Python 温泉参加経験者 (Python 温泉用を配布)
Python Developers Festa 講師または発表経験者 (Python Developers Festa 用を 2 種類配布 + レアステッカー)
Python Developers Festa 午前中(ハンズオン and モクモク) からの参加者 (男性向け/女性向けお好きな方 1 種類を配布)

カンパ

プロのイラストレーターにお願いする＆ステッカーを作るのでお金がかかります。

まずは #pyspa 基金と呼ばれている所から出資します。

多分デザインを考えて貰うだけでお金がなくなってしまいそうですが ... 。

なので、カンパを一口 1000 円から募集中です。

一口 1000 円で上記のシール 1 セットを絶対にお渡しします。

さらになんとレアステッカー @sawonya ファン向けを１枚贈呈。

お金の受け渡しはシールを渡すときでお願いします。

事前に支払っておきたいという人は一応承りますが、自分は忘れっぽいのでオススメはしません。

カンパのメリットは 1 セット確実に貰える & レアシールが貰える程度です。

基本的には寄付と同様ですの余り期待はしないでください。それでも良い方のみ是非。

カンパ希望者

希望者は @voluntas までリプライを飛ばすか、コメントに書いてください。

@AE35
@turky
@keroria +2
@nkd_a
@Surgo
@yuroyoro
@ymotongpoo
@ksauzz
@shomah4a
@mitszo
@blaue_fuchs
@Masahito
@_mipo_
@takabow
@jbking
@isoparametric +3
@kenji_rikitake
@tmmkr
@rokujyouhitoma
@atsuoishimoto
@oshothebig
@atusi +2
@feiz
@ransui +2
@tk0miya +3
@yoshiori
@kuenishi
@ryoaita
@hirokinko +2

現在 37 口

将来的に作りたいモノ

T シャツ
- さすがに無料は厳しいので、何かしら考えます

Permalink | コメント(1) | トラックバック(0) | 14:13

2011-12-05

Clojure/Ring の middleware を使ってみる

clojure

最近は通勤電車で Clojure/Ring のコードを iPhone でだらだら読んでいます。

今回は ring/middleware を使ってみたいと思います。

使ってみるのはわかりやすいベーシック認証ミドルウェアです。

結果

公開ページ

http://morning-summer-6648.herokuapp.com/

ベーシック認証ページ demo/demodemo で入れます

http://morning-summer-6648.herokuapp.com/admin

リポジトリ

https://github.com/voluntas/clj-snowflake

ベーシック認証ミドルウェア

Ring middleware for basic HTTP authentication.

https://github.com/adeel/ring-http-basic-auth/

導入方法

使い方は簡単です。

project.clj の dependencies に [ring-http-basic-auth "0.0.1"] を追加するだけ。このライブラリは clojure 1.3 だと動かないので、clojure 1.2.0 でお届けしています。

(defproject clj-snowflake "1.0.0-SNAPSHOT"
  :description "snowflake"
  :dependencies [[org.clojure/clojure "1.2.0"]
                 [ring "1.0.0-RC5"]
                 [ring-http-basic-auth "0.0.1"]
                 [compojure "1.0.0-SNAPSHOT"]
                 [clj-json "0.4.3"]
                 [clj-time "0.3.3"]]
  :main snowflake.core
  :dev-dependencies [[lein-ring "0.4.6"]]
  :ring {:handler snowflake.core/app})

次は middleware の設定です。まずは ring.middleware.http-basic-auth を読み込みます。

あとは認証を担当する関数を作ります、ここでは defn authenticate ですね。

めんどうなので demo/demodemo でログイン出来る様にハードコードしています。本来ならばここはデータベースなどに問い合わせるべきでしょう。

snowflake/core.clj

(ns snowflake.core
  (:gen-class)
  (:use compojure.core
        ring.adapter.jetty
        ring.middleware.http-basic-auth)
  (:require [clj-json.core :as json]
            [compojure.route :as route]
            [compojure.handler :as handler]))

(defn authenticate [username password]
  (if (and (= username "demo")
           (= password "demodemo"))
    {:username username}))

(defroutes public-routes
  (GET "/" [] (json/generate-string {"ログイン" "ページ"}))
  (route/resources "/"))

(defroutes protected-routes
  (GET "/admin" [] (json/generate-string {"管理" "ページ"}))
  (route/not-found "Page not found"))

(defroutes main-routes
  (wrap-with-auth public-routes authenticate)
  (wrap-require-auth protected-routes authenticate
    "The Secret Area" {:body "You're not allowed in The Secret Area!"}))

(def app (handler/site main-routes))

(defn -main []
  (let [port (Integer/parseInt (get (System/getenv) "PORT" "8080"))]
    (run-jetty main-routes {:port port})))

あとは middleware を差し込んでしまえば終わりです。

起動して http://127.0.0.1:3000/ と http://127.0.0.1:3000/admin にアクセスしてみましょう。

lein ring server

感想

コード自体はほとんどコピペです。

ring-http-basic-auth のコードをだらだら読んでいたのですが、結構しらない書き方とかが出てきて困ったり。Clojure 1.2 と 1.3 の違いとか調べておかないとダメですね。できる限り最新版を使っておきたい人なのですが、1.4 もどう変わるのかまとめておく必要ありそうですね。

あと lein 使っていて思ったのが、ローカルなリポジトリやライブラリを使い方を覚えておかないとなぁと思いました。Erlang のビルドツールである rebar は git や hg のリポジトリを直接参照できたりしたので楽だったのですが。

Clojure は結構色々解決する壁が多そうだなぁと言う印象です。環境構築系をしっかりまとめていく必要があると感じました。

また、1.4 がどう変わるのかとかもですね。

Ring/middleware ほとんど関係ない感想に ... 。

参考

@szktty に Clojure 1.2.x じゃないとダメなんじゃないのというアドバイスを頂きました
https://github.com/adeel/ring-http-basic-auth/

Permalink | コメント(0) | トラックバック(0) | 00:09

2011-12-01

ハッカーに憧れて

other

ちらしのうらです。

自分は誰かに憧れてということはほとんど無いのですが、今も昔も憧れている人がいます。

その方はハッカーです。初めての知ったのは学生時代に Python を勉強し始めた頃でした。

当時 Python を触っている人はほとんどおりませんでしたが、その頃触っている人は最低一度はお世話になっている人です。ウェブサイトを読んで、勉強させて貰ってハッカーってかっこいいなぁって思っていました。

就職してから運良くその方に会うことが出来ました。初めて見たときは感動しました。

「おぉ、これが、ほんものか ... 」なんて感じです。

なんていったって、ずっとウェブだけで見ていた人が目の前で HHK Pro + MBP でカタカタ作業しているのを目の当たりにしたのですから。

ハッカーに憧れて、プログラマになりました。

今の自分はカッコイイコードより、シンプルなコードが良くて、楽しい事よりお金が稼げる事の方が好きです。

ハッカーに憧れ続けて、自分がなったのは職業プログラマーです。それで後悔はしていませんし、むしろプログラムを書いて生活しているので子供の頃からの夢は叶えていて満足しています。

でも、やはりカッコイイコード、楽しそうなアイデアに憧れるんですよね。書けないのはわかっているんですけど。

ハッカーに憧れて、たどり着いたのはハッカーではありませんでした。

ただ、ハッカーという存在がいたからこそ、今の自分がいるのは間違いありません。

この話しを書こうと思ったきっかけは、なんというか最近の社会ってハッカーを受け入れるのが難しくなってきているんだろうな、って思っています。

まず第一に売り上げ、第二に売り上げ、第三に売り上げ、お金が稼げない技術はダメ。そんな空気が強くなってきているように感じます。

自分も社会人なりたての頃はそう思っていました。ただ最近思うんです、ハッカーって夢を見せてくれて、未来を見せてくれる大事な職業なんじゃ無いかなって。

もちろん github を見れば沢山ハッカーがいます。ただ身近にハッカーがいたことで、今の自分がいました。

身近にいて、たまに「こんな面白い記事がね」「このモジュールが」「この話し知ってる？」と話してるだけで嬉しいのです。

ある程度会社にいると管理だ、経営だとそんな話しが出てきてしまいます。なんというか、もっと夢を見せる人がいてもいいんじゃ無いかなぁと思うんです。全ての人を狭い世界に無理矢理閉じ込めようとしなくたって良いんじゃないかなと。

もちろん、会社の規模や状況に応じて色々あるとは思います。ただ、方向性や未来を見せてくれる人は必要だと思うんです。

ハッカーに憧れて、ymasuda.jp に魅せられて、今も ymasuda (@whosaysni) に憧れ続けています。

Permalink | コメント(3) | トラックバック(0) | 01:22

		2012/02
日	月	火	水	木	金	土
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29