フレクトのHeroku Lab

ども、22日は有給もらって4連休でした。(^^v
久しぶりに休日まったくPCを開かずに遊び倒していたので、気づいてませんでしたが、その間にSalesforce1のAdvent Calendarにこんな記事が！！！

プログラミングコンテストで良い結果を出すために重要な(プログラム以外の)3つのこと

はい、私このハッカソンでHeroku部門の3位いただきました。
そのエントリー投稿はこちら

http://challengepost.com/software/salesforce-vs-heroku


で、先の記事にあるプログラミングコンテストで大事な3つのことですが、このアプリなんと全部外してます！！！(--

ていうかこの記事僕のために書かれたような気がするなぁ。。。(--
なんだか申し訳ない。。。


以下、懺悔です。

★ 1. 主催者側のニーズを読む

あいすいません。m(_ _)m

ビジネスアプリと言うお題があることは当日に知りましたが、それをガン無視してゲームを作りました。

何を作るかは前日の夜に考えたんですが、その時点では何でも良いと思ってたんですよね。。。

当日ビジネスアプリ縛りがあることを知りましたが、別のネタを考えるのも面倒だったのでそれをそのまま出しちゃいました。

★ 2. 簡潔かつ明確に、かつ視覚に訴える説明をする

今回のハッキングチャレンジでも12の入賞チームのうち、実に11チームが紹介ビデオを作成しています。(こちらで推奨したというのもありますが)

あいすいません。m(_ _)m

ビデオを作らなかった唯一の入賞者が僕です。。。

ていうか、ビデオを作ろうとか1ミリも考えませんでしたよ。。。(--
フタを開けてみたらほとんどの参加者がビデオも登録してあってかなりビックリしました。

こうしたハッカソンイベントではビデオが必須になっていることもあるので、以前には作ったこともあるんですが、正直プログラム書くよりも100倍面倒で仕上がりも残念な感じにしかならないので、あんまり気が進まないんですよね。。。

本当に入賞はなかやま絵のおかげだと思います。それが無ければ箸にも棒にもかからなかったんじゃないかと。。。(^^;;;

ちょっと修行します。

★ 3. ビルド手順を明記し、デモ環境を用意する

あいすいません。m(_ _)m

わりとギリギリまで作ってたのでビルド手順書くの忘れました。。。(--

しかもローカルではSBTだけあればRedisはなくても動くように作っていたつもりが、提出時点のコードはバグっていてローカルでもRedisが必須になっていたという。。。(--

審査では対象の全アプリを実際にビルドしたそうですが、よくこれのビルドを通せたものです。

一応現在はビルド方法を追記し、Redis無しでも動くように修正しました。


いや本当に、このアプリを推してくれた審査員の方々の努力と忍耐に心よりお礼申し上げます。

★ その他感想など

参加作品を見ると実際にサービス化することを目的としたアプリが思った以上に多いことにも驚きました。

僕の場合、完全にこのハッカソンのためだけに作ったジョークアプリなのでなんというかもう全然本気度が違う感じ。(^^;;;

ドメインもなんか取ろうかと考えはしましたが、キャラクタをSalesforceとHerokuにすることに方針転換した後に「salesforce-vs.herokuapp.com」というアプリ名が取れたところで、もうこれでいいやと思っちゃっいました。(というわけでこのアプリのランニング費用は1円もかかってません。本当にすみません。。。m(_ _)m)

ただし、アプリ自体は使い捨てるつもりでもその中で使っている個々の要素技術は実際に使い物になるかどうかの評価をしつつ、再利用する前提で作っています。

今回の場合テーマは以下のものがありました。

• WebSocketのさらなる可能性の追求
• CodeMirror(HTML5のテキストエディタコンポーネント)の評価
• ブラウザ上での複数人の同時コーディングの可能性評価(コードレビュー的な)
• ブラウザ上で書いたものがその場で動く簡易インタープリタの実験
• 実践的なCSS3アニメーションの実験

結論としてCodeMirrorは思った以上に使いやすかったですし、changeイベントを逐一相手に送りつけて、相手側のブラウザ上で自分がコードを書いている様を再現するという試みも成功したのでそれなりに満足です。(^^v

これらが将来的にどういう形で活かされるのか、あるいは闇に消えるのかはまだまったくの未定ですが。。。(^^;


しかし、このようなちょっと作ってはみたいけれど、いまいちモチベーションが無いみたいな場合にハッカソンを目標設定のために使うというのは割とアリな手段だと思います。(賞金もらえるかもしれませんし)


今回のアプリに何かしら機能を足していくということはもうあまり考えていませんが、同じようなプログラミング要素を使ったゲームみたいなものはこの先も何か作るかもしれません。(イメージ的にはIncredible MachineやElectric Boxのもっとプログラミング要素の強いモノという感じ。Incredible Machineはもはや入手できないと思うけど、どこかで再販して欲しい。。。。)

□□□□
以上、祝ってタイトルに付けたわりには謝ってばかりの謎エントリでした。

推定最後です。良いお年を。(^^)/

今回Salesforceのハッカソンに参加するにあたり、小西はちょっとしたゲームを作成したんですが、まぁWebSocketでUS EASTにつなぐのは遠すぎるということを改めて実感しました。(--

ちなみにそこでやろうとしていた処理は定間隔で２つのクライアントから送信されるコマンドを両方のクライアントで同時に実行するというものでした。

最初は

• クライアント側でタイマをそれぞれ実行し、
• サーバ側で両方のコマンドが揃ったら、
• ブロードキャストする

という実装をしてみたんですが、クライアント側のタイマってけっこうずれるんですよね。。。(--

特にMac Safariはバックエンドにまわるとタイマがかなり遅延するので、この実装は速攻でボツ。

次にやったのは

• サーバ側でタイマを実行し、
• 定間隔で両クライアントにコマンドリクエストを送信し、
• それに反応したクライアントがコマンドを送信し、
• サーバ側で両方が揃ったら、
• ブロードキャストする

という実装です。

こちらの実装はローカルでは割と想定通りに動いてました。

。。。が、Herokuで実行するとクライアント側でのコマンド実行が安定せず、しばらく動かなかったり、連続で複数コマンドが実行されたりという現象が発生しました。

ちゃんと調べてませんが、上記の実装では

• サーバからのコマンドリクエスト
• クライアントからのコマンド送信
• サーバからのコマンドペア送信

と3つの電文が跳んでいるので、そのそれぞれに太平洋越えのレイテンシがかかった結果そのような挙動になったと思われます。(イマイチ納得いってない部分もあるんですが。)

しょうがないので、最終的に先の実装に加えて

• クライアント側は受け取ったコマンドをすぐには実行せずに一度キューに入れる
• クライアント側のタイマでキュー内のコマンドを定間隔で実行

としました。

この変更によって２つのクライアントで同時に画面が動くという面白さは損なわれましたが、結局のところレイテンシによって元々完全に同時にはならないので、まぁしょうがないかな、と。

冷静に考えると、この場合仮に東京リージョンがあっても微妙なタイムラグはあるわけだから、同じようにキューを使った処理を入れないといけないような気もしますが。。。

そうなるとこのエントリのタイトルが。。。。(--

いや、東京リージョンさえあればこんなブログを書く必要も無かったからやはりタイトルに偽りはありませぬ。(^^v

□□□□

このブログはHeroku Advent Calendar 2014の14日目の穴埋めでした。

明日は@shu_0115さんのHerokuの便利機能まとめ的な、です。

ちなみに冒頭のカットはハッカソンエントリ作品の一コマです。

明日には公開されるらしいですよ。(^^;;;

この記事はScala Advent Calendar 2014の9日目です。

ネタはHerokuにScalaアプリケーションを高速にデプロイする方法。

元々の発端は今年のScala Matsuriで「HerokuにScalaアプリケーションをデプロイしようとするとタイムアウトすることがあるんだけど。。。」という話題が出たことです。

デプロイの制限時間は15分ですが、HerokuのSlug Compilerはすこぶる非力なので、タイムアウトをくらう人もちょいちょいいます。

ちなみに僕も春頃に一度くらってますが、その時はHerokuのサポートに連絡したら該当アプリの制限時間を30分に延ばしてくれました。(^^;;;
そんなんアリかよ？と思わなくもないですが、コンパイル時間を短くするべく頑張っているからしばらくそれでしのいでくれ、とのこと。

自前のbuildpackでどうにかするという構想はScala Matsuriの時点であったんですが、雑事にまぎれて放置している間にはや3ヶ月です。。。(--

Advent Calendarに登録すれば嫌でもやるだろと、自分にプレッシャーをかけてみたもののそうこうしているうちにGitHub Syncとかできちゃいましたね。。。

GitHub SyncではGitHubにコードをpushすれば自動的にHerokuへのデプロイが非同期で走ります。(Heroku gitへのpushはpreHookされているのに対しGitHub SyncはpostHookです。)

僕の場合、ストレスの要因はコンパイルが遅いことよりもコマンドが返ってこないことにあったので、もうこれで良いんじゃないかとも思いましたが、他に提供できるネタもないのでScala用の高速buildpackを作ります。

★ 高速化作戦

どうやって高速化するかを説明するためにまずは標準のScala buildpackがやっていること見ていきます。

大雑把に言うとだいたい以下のような手順でビルドを行っています。

1. Gitからコードを取得
2. Buildpackのダウンロード
3. JVMのダウンロード
4. SBTのダウンロード
5. 「sbt compile stage」コマンドの実行
6. キャッシュや中間ファイルの削除

実際にコンパイルを行っているのは「sbt compile stage」コマンドです。
stageというのはSBT Native Packagerというプラグインのコマンドで、それさえあればScalaアプリケーションを実行できるというファイルセットを作ってくれるものです。


Playframeworkにはこのプラグインが組み込まれているので、Playアプリケーションのルートで「sbt stage」を実行すると「target/universal/stage」以下に必要なファイルがすべてコピーされ、実行スクリプトも生成されていることが確認できます。

要するにこの下のファイル群だけHerokuに渡しちゃえば、Scalaアプリケーションは実行できるわけです。
コンパイルも不要なのでSBTをダウンロードする必要もありません。

つまり、この手法の場合先の手順からこれだけのステップを省略できます。

1. Gitからコードを取得
2. Buildpackのダウンロード
3. JVMのダウンロード
4. SBTのダウンロード
5. 「sbt compile stage」コマンドの実行
6. キャッシュや中間ファイルの削除

ほとんど何もしないので、間違いなく速いはずですよね。
また、SBTやコンパイル前のソースコード、画像ファイル等もSlugに含まれなくなるのでサイズ的にも有利です。

★ heroku-buildpack-scala-compiled

ということで作ったbuildpackがこれです。

https://github.com/shunjikonishi/heroku-buildpack-scala-compiled

Scalaのbuildpackをforkして、要らないところをザクザク削って、Procfileが無い場合に自動生成するパスを変更しただけ。(^^;

腰が重かった割には作り始めるとあっという間でしたね。

最初は標準ライブラリはbuildpack側で生成するようにしようとか、Gitに入れるならherokuブランチを作ってgh-pagesのようにそっくり中身を差し替えようとか、色々難しく考えてたんですが、よくよく考えるとHerokuへのdeployにしか使わないと割り切ってしまえば別にバージョン管理する必要がないんですよね。

なので、コード管理しているgitリポジトリとは別にまっさらのgitリポジトリを作成してそちらにstage以下のコードを全部突っ込むことにしました。

手元にPlayアプリケーションがあるなら以下の手順で、Herokuに新しいアプリケーションを作成できます。

sbt stage

mkdir heroku
cp -rp target/universal/stage heroku

cd heroku

git init
git add .
(※1)
git commit -m "Initial commit"

heroku create -b https://github.com/shunjikonishi/heroku-buildpack-scala-compiled
git push heroku master

※1 Windows環境の場合はデフォルトではスクリプトに実行権が付かないので、ここで

git update-index --chmod=+x stage/bin/[APPNAME]

 を実行する必要があります。

このリポジトリはGitHub等の外部リポジトリにホストする必要はありません。コードさえあれば同じものをいつでも作れますし、別のマシンにコピーを作りたい場合はHerokuのgitからcloneしちゃえば良いので。

初回のコミットは標準ライブラリ等が山ほど入るので、少し遅い(それでもscala-buildpackよりは全然速い)ですが、標準ライブラリは基本変更されることがないので2回目以降のコミットでは自前のjarとconfファイル程度しか対象とはならないのでデプロイにかかる時間はわずか数秒です。素晴らしい。。。(^^v

初回はともかく2回目以降の手順はGrunt等で簡単にスクリプト化できるので、それなりに使い勝手は良いんじゃないですかね。(^^;

欠点はDashboardのActivityページからDiffが見られなくなることとかですかね。(GitHub Syncを使えばリリース毎のDiffがGitHubのページで見られます。)

あとはチーム開発時にデプロイ用のgitまで各メンバで同期する運用の場合、ちょっと面倒かもしれません。むしろCI連携で使った方が便利かも。。。

作ってはみたものの本当に使うかどうかはまだわかりませんが、興味のある方は触ってみてくださいな。(^^;

明日は@ponkotuyさんのMyFleetGirlsの話です。

ども。 Salesforce World Tour Tokyo, DeveloperZoneからこんにちは。

Heroku Advent Calendar 2014　4日目。2日ぶり3度目の登板の小西です。(--
今日を乗り切れば明日からはしばらくは乗り切れるようなので雑に埋めておきます。

本日のネタはこちら

https://gist.github.com/shunjikonishi/b42decee4446c0652cdd

さらっと作ったpgbackups:restoreをGruntから実行するタスクです。

child_process.execでherokuコマンドを叩いているだけなので、Nodeを使ったことのある人にはなんの新規性も無いかと思いますが、Grunt使っている人でも自分でタスクを書いたことの無い人も多いと思うのでさらっとご紹介します。

このタスクが行っている処理内容は以下です。

• heroku pgbackups:urlを実行してrestoreしたいバックアップのダウンロードURLを取得する
• heroku pgbackups:restoreを実行してリストア

いじょ。

バックアップを取得したアプリケーションとリストアしたいアプリケーションが同じであれば、pgbackups:urlを実行せずともバックアップIDでいきなりpgbackups:restoreを実行してしまえば良いんですが、開発環境で作ったデータをテスト環境でリストアするケースも多いので、このようにしています。

Gruntfileでタスクを定義する際に渡せるパラメータは以下です。

• app: リストアを実行するアプリケーション名
• backupId: リストアするバックアップのID
• backupApp: バックアップを生成したアプリケーション名。省略時はappと同じ

いじょ。

JavaScriptはちょっと書けるけどNodeは触ったことがないという人向けにさらっとポイントを説明すると以下のような感じです。

• gruntタスクの定義にはgruntオブジェクトを使用する
• タスク名と説明(registerMultiTaskの最初の２つの引数)以外は変える必要が無い
• コマンド実行にはchild_process#execを使用する
• 複数のコマンドを連続して実行する場合はコマンド実行は非同期なのでコマンド終了時にemitterでイベントを発行し、それを受けて次のコマンドを実行するようにする
• この例ではpgbackups:urlの終了時に「url」イベントを発行し、それを受けてpgbackups:restoreを実行する
• 全部のコマンドを実行したらthis.asyncで返ってくるdoneメソッドを実行することでタスクが完了する

いじょ。

こんだけわかっていれば後は見よう見まねで書けるんじゃないですかね。(^^;;;

ちなみにこのrestorePgbackupsタスクはテスト専用の環境でデータを初期化するために使用していてわりと重宝しています。

□□□□

SFハッカソンに参加するので、ここから先は本当にしばらく気配を消します。

14日以降まで繋がっていればまた復活するかもしれませんが。。。(^^;;;

がんばれ！　Heroku Advent Calendar

この記事はHeroku Advent Calendar 2014の2日目です。



先ごろCodeZineにHeroku Postgresの記事を書いたんですが、そこでさらっと触れたHeroku PostgresのRollback機能について、実際の使い方を紹介したいと思います。



ほとんどの場合Rollbackの必要に迫られる場面は突発的に訪れ、かつ時間の制約も厳しかったりするんですが、これさえあれば安心です！(多分)

★ Heroku PostgresのRollbackとは

Databaseを扱ったことのある技術者でRollbackという用語を知らない人はいないと思いますが、ここでいうRollbackは世間一般に浸透しているトランザクション制御のためのRollbackのことではありません。

名前が紛らわしいので正直、名前変えたほうが良いんじゃないかと思ったりもしますが。。。(^^;;;
自分の言葉で説明するならば、これは

時間を指定してその時点のスナップショットから新しいDBを作成する機能

です。
Forkを使ったことある人ならForkで時間指定ができるようになっただけ、と捉えても良いです。(ちなみにForkというのは既存DBのスキーマやデータをコピーして新しいDBを作成する機能です。)

Rollbackが使用できるのはStandard-0以上のプランによって指定できる時間の制限が異なります。

• Standard-X. 現在時刻から1時間前まで
• Premium-X. 現在時刻から7日前まで

ちなみに指定できる時間は分単位までで、秒単位での指定はできません。

★ コマンド

実際にRollbackデータベースを作成するためのコマンドは以下

heroku addons:add heroku-postgresql:standard-0 --rollback green --to '2014-12-02 12:00+00:00'

見ての通り、通常のAddon追加のコマンドにロールバックに必要なパラメータを追加しているだけです。

「--rollback」にはロールバックの対象となるDBの色名の部分のみを指定します。
「--to」にはロールバックする時間をタイムゾーンつきで指定します。

ちなみに「--to」の代わりに、「--by 3 days 7 hours 22 minutes」のように何時間何分前に戻る！という指定の方法もあるんですが、時間を計算したりコマンドを叩いたりしているうちに時間が経過したらローブバックする時間もずれるので、はっきり言ってこのオプションの存在意義がわかりませぬ。。。(--

コマンドの実行にはそれなりに時間がかかります。試したところそれほど多くのデータの入っていないDBを数分過去の状態に戻すだけでも10分程度かかりました。

元々PostgresのAddon追加自体が数分を要しますし、データ量や巻き戻す時間によっても所要時間は変わってくると思います。
なので、コマンド実行後はpg:waitでDBの作成完了を待ったほうが良いです。

ロールバックDBの作成が完了したら、DBを置き換えて元のDBを削除します。
全体としてのコマンドシーケンスは以下のような感じです。(元のDBがgreen、作成したロールバックDBがblueの場合)

heroku addons:add heroku-postgresql:standard-0 --rollback green --to '2014-12-02 12:00+00:00'
heroku pg:wait
heroku pg:promote blue
heroku addons:remove HEROKU_POSTGRESQL_GREEN

★ バックアップは計画的に

以上が、ロールバックの使い方でしたが意外と簡単だったかと思います。そして非常に強力です。

ただ、個人的には障害時の対応をこれだけに頼り切るのは危険だとも思っています。
もちろん、選択肢のひとつとしてはあっても良いんですが実際に使うかどうかはケースバイケースのような気がしています。どの時間まで戻すのが適切なのかわからないこともあるだろうし、このようなめったに使われることのない機能にはバグや想定外の何かがあってもおかしくないですしね。

pgbackupsを入れるのは当然として、障害対応はある程度あらかじめシュミレーションしておくことが重要です。

★おまけ。Heroku Postgresの識別名

Heroku Postgresを追加するとご存知の通りconfigには「HEROKU_POSTGRESQL_<色名>_URL」という環境変数が設定されるわけですが、いざこれをコマンドで指定しようとすると以下のようないくつかのパターンがあります。

• HEROKU_POSTGRESQL_BLUE (「_URL」がない)
• blue (「HEROKU_POSTGRESQL_」も省略されている。ついでにCaseInsensitive)

つねづねかねがね「何だ？この一貫性の無さは。。。」と思ってたんですが、今回一連の操作を試していてなんとなく枠組みが見えてきました。
おそらく、

・HEROKU_POSTGRESQL_<色名>
Addon名。Heroku Postgresは1アプリケーションに複数追加できるのでそれを識別するための名前。
Addonを操作するコマンドではこちらを使用する

・<色名>
pg:xxxxコマンドなど、文脈からHeroku Postgresを指定することがわかる箇所では色名のみの省略記法が使用できる


ということなんではないかなぁと。(^^;(全部を確認したわけではないですが)

Addonの中でHeroku Postgresのみが同一Addonを複数追加できることにも違和感があったんですが、もしかしたらサードパーティ製のAddonでも複数追加できるものを作れるのかもしれません。

□□□□

明日は@anoworlさんによる画像アップロードの話です。
あとはがんばってください。(^^)/

ども、この記事はまったく完走できそうな気がしないHeroku Advent Calendar 2014の一発目です。(^^;

いや～、どうなるんでしょうね、これ。5、6日なら頑張ろうかなという気もするけど、20日は無理っすよ。。。

中旬はSFハッカソンとかもあるし、終盤までバトンが繋がったらそこから先はちょっとがんばります。(かもしれません。)

さて、そんなこんなの一発目のネタですが、GitHub Syncです。

本当は別のネタも考えてたんですが、数日前にA氏のつぶやいていたこの新機能がなかなか興味深かったのでとりあげてみます。

★ GitHub Syncとは

その名の通りHerokuとGitHubを同期させる機能です。

HerokuがGitHubのOAuthクライアントとなってGitHubに対してあれやこれやの操作を行います。

★ 下準備

GitHub Syncはまだlabsのベータ機能なので、使用するためにはまず以下のコマンドをたたく必要があります。

heroku labs:enable github-sync

User Featureなのでアカウントで一度有効化すればすべてのアプリケーションで使用できるようになります。

★ Dashboard

GitHub Syncを有効にするとHeroku DashboardのCodeタブに以下のような設定画面が表示されるようになります。

画面を見るとできることはほとんど一目瞭然なんですが、設定したGitHubリポジトリに対して以下の操作が行えます。

１、 任意のブランチからの手動デブロイ

この画面から任意のGitHubリポジトリ上の任意のブランチを選択してデプロイすることができます。

といっても、これは全くメインのFeatureではないので多分使うことはないです。(^^;

２、自動デプロイ

指定のブランチに対してpushやmergeが行われた際に自動的にデプロイを行うように設定できます。

ちなみにHerokuへのgit pushのフックとは異なり、ここでのフックは非同期です。

git push自体は何も設定していない場合と同様にすぐに終了し、その後に非同期でデプロイが実行されます。Scalaアプリで試したところデプロイには10分程度かかりました。(Scalaのコンパイルが遅いせいですけど。。。)

デプロイの成否はDashboardのActivityタブで見ることができます。

OAuthでリポジトリにアクセスしているのでPrivateリポジトリも問題ないはずです。

３、PullRequest時に毎回新規アプリを作成

これ、試してみたところ実はまだ動いてないようなのですが。。。

PullRequestを作るたびに自動で新しいHerokuアプリケーションを作成して、そこにPullReuqestの内容をデプロイするというかなりとんでもない機能です。(^^;

作成するアプリケーションはapp.jsonを参照するので、そこに使用するAddonや環境変数の情報を書いておけばそれらも自動的に設定されます。

ただ、DB等を使用する場合を考えた場合、この場合のapp.jsonの設定では「親アプリの設定値を引き継ぐ」ということができないと実質的には使えない気がします。

app.jsonにはgeneratorという書式があるので、それを拡張すれば割と簡単にできるとは思うのですが。。。。

まぁ当面成り行きを見守りたいと思います。

４、リリースの差分をGitHub上のDiff画面で見られる

これはひょっとしたら前からできてたのかもしれませんが。。。

Activityページの各リリースの行に前回リリースとのDiffを表示するGitHub画面へのリンクが追加されます。(PullRequestでおなじみのコミットAとコミットBを比較するあの画面です。)

はっきり言って便利です。GitHubでコード管理しているプロジェクトであれば、全部自動で設定して欲しいと思うくらいのレベル(^^;

まだ出たばかりのベータ昨日なのでPullRequest Syncが動いてないなど、怪しい部分もありますが、こういうのは時間の問題で直ると思うのであんまり気にしなくて良いです。

labsだからと躊躇せずにHerokuとGitHubを使っている人は全員使った方が良いと思います。

□□□□

Advent Calendar、初日からバトンが途切れるのもあれなので、明日も小西が連投します。