もう更新が滞っていても気にしない日記となりましたが、みなさんいかがお過ごしですか。
というわけで 6/21(土) Kanazawa.rb のクラウド祭り第2弾、Heroku ハンズオンでサポートおじさんしてきたよ。おばたけーさんありがとう！！
Heroku | Cloud Application Platform
実際のところ当日まで heroku で遊んだ経験はなかったんですが(笑)
Herokuについての発見
- heroku postgres 以外の add-on を使わないならクレカ登録は要らない
- 1 アプリ 750 dyno-hour という無料枠が毎月適用される
- add-on も buildpack もアホほどある
- slug は毎日 cleanup される
2 がよく分からなかったんだけど、dyno-hour という考え方がキモで、dyno の数を増やしたりやらせる仕事が増えるとこの制限を超える。例えば単純な静的サイトで何も余計な仕事をしないのならこの無料枠に収まる。しかも複数のアプリを立ち上げてアプリごとにそれが適用される。ただし、無料アカウントの場合はアプリの数は5までらしい。
クレカ登録は billing info から。
3 の add-on も buildpack もすごく興味深かった。add-on を見るだけで世の中にこんなにいろんな開発者向けサービスがあるのかという驚きと発見があった。ports collection 眺めてアプリの存在を知るというか、なんかそんな感じ。
Perl に対応してる PaaS って見ないけどなんでかねーという話をコソコソしてたんだけど、buildpack の中にしっかり Perl があって、例によって miyagawa さんだった。すげーな、世界の miyagawa.
4 がいわゆる Heroku はファイルが消えるってやつ。Heroku は dyno 上に slug を作ってそこに repository と buildpack でアプリケーションの実行環境を用意するんだけど、この slug の cleanup が毎日入る（これたぶん ruby や add-on の更新の役目も担ってるんじゃないかな）ので、 repository に入っていないものは保存されませんということですね。
いろいろ妄想が膨らんだのでもっと heroku で遊ばないとダメだなと思った。
ハンズオンで気づいた点
今回のハンズオンは「RailsアプリをHeroku上にdeployする」というよくある形かなと思ったんだけど、祭りということでレギュラーメンバー以外もたくさん参加されたので、いろいろ予想外のことがあった。まとめておくね。
git + ssh
heroku toolbelt 入れといてねという話は一応あったんだけど、そもそも heroku が git を利用しており、transport に ssh を使うというところで、
- git
- ssh
というハードルがあった。これ実は Windows ユーザーにはあまり優しくない。ただ、2014年現在は Git for Windows を入れれば msys で
- bash
- openssh
が使えるので話はだいぶ楽になる。そしてこれが重要なところなんだけど、 heroku コマンドから何からすべて Git Bash 上で操作すること 。でないといろいろ面倒になる。
heroku + ssh
heroku keys:add で公開鍵を add できるんだけど、git push とか実際にそれと対になる秘密鍵を探すシーンでは ssh コマンドのサーチルールに従うので、openssh であれば
~/.ssh/config
で
Host heroku.com
IdentityFile /path/to/private_key
みたいな設定をしておくとよい。
すべてデフォルトの ~/.ssh/id_rsa, ~/.ssh/id_rsa.pub を使っているなら面倒はないんだけど。
※ ちなみに自分は以前 github 用に作ったとおぼしき公開鍵を heroku keys:add が探し出したので upload したんだけど、その passphrase を覚えていなかった（たぶん結局使わなかったんだと思う）うえに公開鍵を保存してなくて秘密鍵から生成し直すとか余計な作業をしていた。
ssh-keygen + Japanese Username
ssh-keygen で鍵を作る際、ユーザー名とホスト名が利用されるんだけど、ここで Windows ユーザーはユーザー名に日本語を使っているとそれがそのまま鍵ファイルの中に入ってしまう。
この状態の公開鍵を heroku keys:add で upload しようとすると application error が返ってきて進まない。application error というのが意味がよく分からないので、これは heroku 側の想定漏れじゃないかな。もしかしたら heroku コマンドを使わずに dashboard から登録したら大丈夫だったりするのかな、これ。誰か追試頼む。
cf. WindowsでRuby, Rails, PostgreSQLをインストールしてherokuにデプロイする方法 - dari88's diary
repository は ssh の鍵が必要ないように
これは今回のデモアプリの repository が github にあったんだけど、github に鍵を登録して普段から使っている人でないと git+ssh protocol で clone できないという問題。これは https の URI に差し替えることで解決。
普段から github を普通に使っていることを前提にしてはいけないという教訓を得た。やーやっぱハンズオンてむずいね。
Windows + Ruby
はい、 RubyInstaller for Windows ですね。
Rails + pg gem
これも PostgreSQL が入っていないと bundle install できないので、
bundle install --without production
で。
Rails + native extension
Mac で rbenv や rvm で ruby を入れてるなら問題ないんだけど、そうでないとビルド環境を新たに用意する必要がある。Windows なら RubyInstaller にある devkit を利用する。具体的には json gem とかが引っかかる。もうここら辺で心が折れる。
Windows + foreman
そもそも自分は foreman を知らなくてですね。えへ。
http://ddollar.github.io/foreman/
David Dollar ってすごいお金のにおいのする名前だなーとか失礼なことを思いながら、あー Procfile を使って環境を整えるために使うんですね、と理解。
で、どうもこれ Windows と相性が悪いらしい。最終的には自分がサポートしてた人たちは時間もないことなので、foreman は無視した。
Foreman installed by heroku toolbelt on windows can't be found - Stack Overflow
まぁ今だと .ruby-version とか Gemfile で Ruby のバージョンも指定できるし、それだけのために Procfile を使わなくても開発時には困らないので無視してよいとのこと。（てな話を懇親会の時に中の人に確認しておいたので間違ってないと思う。）
Mac でも pkg じゃなくて brew install で heroku-toolbelt 入れると foreman は勝手に入らないので別途
gem install foreman
が必要になるのもちょっとした落とし穴。
bundle install の利用する帯域
bundle install を一斉にするとネットワークがつらい。そもそもあの人数を全部 WiFi で処理できない。そこは
財力にモノを言わせてテザリングしてください作戦
でなんとかしたけど、アレしかないよなぁ。
それか会場 WiFi とインターネットの間に gem の mirror サーバ立てれればなんとかなるんだろうけど、そっちの方が手間の割に効果小さいもんね。
ハンズオンまとめ
Windows で Rails + git + ssh の組み合わせ、なかなかつらい。
Heroku ハンズオンが目的なら git と ssh はなんとかするとして Rails じゃなくてもっとシンプルに Sinatra アプリとかでいいのかもしんないなーと思ったりした。
いやーめっちゃ Windows に詳しくなった！
meetupまとめ
Yo!!1
児童小銃 - 和欧混在テキストで和文と欧文の境目に半角スペース入れるのはバッドノウハウなの?
そうそう。どっちかが正しいとする姿勢こそがバッドノウハウじゃないかと。これがいちばん自分の感覚に近いな。
ただ、Terminal やエディタなどのレイアウトを調整しないソフトでは空白を入れた方が見やすいので、それを扱う時間の長い人間はそっちをベースにした方が幸せになれると思う。これはレイアウトソフトを通した出力に対するこだわりではなく、自分の見やすさのために入れるものだから、まぁ機械の都合に合わせているというバッドノウハウの基本原理には合致するけれどもバッドレベルは低いような気がする。
（ここではレイアウトソフトを通した出力という）結果を人間が想像して、プロセスに不自然な操作を加えるのがいちばんのバッドノウハウじゃなかろうか。Terminal やエディタの場合は想像する必要がなく1、人間の側の負荷が少し低く、だからバッドレベルが低いと言えるように思う。2
というか。すでに息を吐くようにスペースを入れている自分が居るしな。今さら何を言われようが、いや Quark で組版しろとか言われない限りは変わらないだろな。
以下思いっきり余談。
とりあえず HTML に限定して考える。JIS 準拠のレンダリングエンジンを積んだ WYSIWYG エディタを使って、ソースは空白なし、HTML 出力ではアキあり、という状態になっていればそれはバッドノウハウではない。ただし、等幅文化圏の人は今度はソースに手でスペースを足したりしそう。すると JIS 準拠レンダリングエンジンは相互運用性の低いソースを作るということになるんだろうか？ レンダリングではアキだけを有効に、ソースにはスペースを1つという状態になればいいのかもしれないけど、それって HTML の仕様上無理なような？ そしてそれは JIS には合致するの？
HTML の場合はスペースは1つに圧縮されるけれど無視はされないはず3なので、そうなるとレンダリング結果ではアキだけを有効に、ソースにはスペースを1つ入れる、という技は無理なような気がするんだけど、どうだろう。
※ ここのところ日記の日付と実際に書いている日付がずれているのはわざとです。
メールに書かれた URL からクレジット専門のサイトへ。
クリックとちゃんと連動しないポップアップウィンドウを使うのはやめてくれ。
流行ってるかぁ？ 一部の夢想が連鎖してるだけのような気がするんだけど。問題がいくつかありますな。
P2P のメリット
- 帯域確保
- 負荷分散
と定義する。
基本的な疑問
- ブラウザと同等の機能を持ちつつ P2P に対応するクライアントを開発するのはかなり骨なような気がするし、ブラウザの完成度が高くなっている今日、新たなブラウザを作るのはちょっとどうかと。
- 何をもって Web と呼ぶのか？ P2P なら Web の基盤の上に乗る必要はないわけだし。
- ひょっとして普通のブラウザからも普通に見れる Web なんだけど、バックエンドが分散していて、それを大規模システムの管理スキルがなくても P2P アプリが勝手にやってくれるものが P2PWeb なのか？
- てゆーか P2P になったら認証とか Web のレベルで掛けるのはまず不可能になっちゃうので、かえってアプリケーションの作りこみが面倒になると思うんだが。
プロトコル
- ネットワーク部分の実装が plugable なブラウザならかなり面白いと思う（ぜひ幅広いプラットフォームに対応している Mozilla などで実現してほしい）
UI
- XUL とか X2Web が効いてくるのかな？ X2Web は IE 依存だからネットワーク部分の実装に自由がなくてダメか。
アプリ
- Web のアクセスの大半は view アクセスなので、コンテンツの配信と同時に view 部分を転送できるといいのかな？（これを「パッケージ」と呼ぶのがいいかも。）
- アプリケーションの作りこみが view アクセスの部分と更新部分で完全に切り離されてると実装が楽ですな
- 更新のアクセスは BitTorrent で言う trucker のようなサイトへ行い、その結果のコンテンツと view を担うアプリを流す。
- 必要なら更新時に必要な計算処理も分散できるとなおよい。
- view を担うアプリは trucker サイトのアプリからのコンテンツ改変であることを検知してその伝播を受け入れる。（抜け道とかちゃんと考えてないけど一応セキュリティへの配慮は要るでしょ）
コンテンツ
- コンテンツの同期がいちばん楽です。たぶん。
なんかちょっと分かってきた。ような？
面白いけど、ちょっとイメージが漠然としてるな。
あ、例えば Wiki の「参加者」を限定するフレームワークとしてこの P2PWeb を使うと、CPU 負荷とネットワーク帯域を分散させた上で認証部分を Web から切り離せるので実装が楽ちんになるな。
こういうことがやりたいのか？ 匿名性が高いことが Wiki のメリットとはあまり思えないしなぁ。
ざっと眺めるとやはり勘違いしている人が渦の中心付近に居るようだ。早い話が P2P と blog という流行り言葉に食いついているだけの人。
へぇへぇへぇ
File メニューに URL を開く動作がない。確かに普段はアドレスバー出てるけどさ。カスタマイズしてアドレスバー表示しないようにしたら URL を入力する方法ないじゃん。
- calendar3
- dropdown_calendar
- todo
のプラグインを追加。
calendar3 は当月の日付を横一列に表示し、該当する日付の hover で内容を表示する。dropdown_calendar はそのままずばり従来年で横一列に表示していた月単位のリンクをドロップダウンリストで実現するもの。これは日記を何年も書き続けていくうちに使えなくなるな。
最後の todo は日記の編集画面ではなく tDiary の設定画面から ToDo を追加し、それを日記のどこかに表示するプラグイン。