フレクトの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はもはや入手できないと思うけど、どこかで再販して欲しい。。。。)

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

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

ども、最近火事場案件に突っ込まれててあんまりブログ書けておりませぬ。。。(--

本当は別の記事を書きかけてるんですが、なんかHerokuからお知らせ来てたので先にそっちの話を。

なんと未来永劫labsから抜け出ることは無いんじゃないかと思っていた、prebootがGAになったようです。

https://devcenter.heroku.com/articles/preboot

結構びっくり！

ドキュメント見ると微妙にlabsの頃と挙動が違っているようなので、ざっくりとまとめておきます。

★ 使い方

新たに追加されたと思われる「heroku features」コマンドを使います。

heroku features:enable preboot
heroku features:disable preboot

これまでと同様にデフォルトでは有効になっていないので使用するためには明示的にコマンドで有効化する必要があります。

また、prebootはWeb Dynoが2台以上起動していないと動作しません。
別な言い方をすれば課金しているアプリでなければ使用出来ないということです。

★ 挙動

僕の記憶によればいくつか動作に変更点があります（多分）。以下の赤字が以前とは異なる部分です。

• Slugコンパイル完了後、既存のDynoがシャットダウンされるよりも前に新しいDynoが起動する
• デプロイから約3分後、古いDynoと新しいDynoのRoutingが切り替わる
• さらにその数分後、古いDynoが削除される
• prebootはデプロイ以外の環境変数の変更や再起動時にも有効
• prebootはWeb Dynoでのみ機能し、Worker Dynoはこれまで同様シャットダウン後に新しいDynoが起動される

新しいDynoが起動してから、切り替えまで数分のタイムラグがある点と、デプロイ以外の再起動時にも有効になったと書かれている点が以前とは違います。

デプロイ完了しても数分間は旧バージョンが動き続けるというのは結構注意が必要な点かも知れません。
ざっと見た感じRoutingがスイッチしたタイミングではログがでていない気がするので、どこで切り替わったかはわからない気がします。(これは要望出そうかと思ってます。)

また、ドキュメントのこの書き方だとデイリー再起動時にもprebootは有効なように読めますが、少なくとも昨日のデイリー再起動ではprebootが行われた形跡はありません。

labsの頃は(少なくとも僕がドキュメントを精読した時には)デプロイ時以外の挙動については触れられていなかったんですが、実際には環境変数の変更やheroku restartでもprebootは効いていました。

が、デイリー再起動だけは対象外だったんですよね。。。。(--

以前にもかなりしつこくデイリー再起動時にもprebootしてくれとお願いしているので、有効になっていてくれると嬉しいんですけどね。。。

★ 注意点

ドキュメントには新Dynoのアイドル時間が増えたことによっていくつか注意点ができたことも記されています。

• これまでと違いgit pushからリターンしてもすぐには新バージョンが動かない
• preboot中はheroku psコマンドの見方に注意が必要。新旧バージョンの両方がheroku psのリストに載ることはないが、「starting」と表示されていても旧Dynoが仕事中だったりする
• 一時的にではあるが通常の2倍のDynoが起動しているのでその間RDBやRedisなどのコネクションを余分に消費する。特に安いプランで接続数が制限されている場合は注意が必要
• DBのスキーマ変更を伴う場合はprebootはうまく機能しない可能性が高い。(何故ならデプロイ後も数分旧バージョンが動くが、それが新スキーマでも変わらず動作するかどうかは不明なため)。この場合はprebootを一度無効化する必要がある

こ、これは結構微妙。。。(--
特にスキーマ変更の話は注意が必要です。

ちなみにコネクションを余計に消費する問題に対してはpgbouncer buildpackというのがお勧めらしいですが、これの話はまた今度。

個人的にはデイリー再起動で有効なのかどうかでかなり大きく評価が分かれます。

とりあえず、明日のデイリー再起動の結果を待ちたいと思います。

続報をお待ちください。(^^;

★ 追記

やっぱりデイリー再起動時にはpreboot適用されないようです。残念

ただ、デイリー再起動は24時間+αの時間で実行されるので、日本だけで使うようなサービスの場合は毎日深夜3時とかに自力でrestartをかけるのは有効かもしれません。

世間はお盆で会社にも人が少ないわけですが、今朝はHerokuのChangeLogが6件もあがってたよ。。。(--
そのほとんどがPostgres関連。

https://blog.heroku.com/archives/2014/8/12/the_new_database_experience_with_heroku_postgres

なんかまたプランが変わってプラン名もこれまでのYanariとかTenguとかの妖怪シリーズじゃなくなってStandard0とかPremium7とかの無味乾燥な名前になるようです。

なんだかちょっと残念。。。
まぁ妖怪シリーズもどれが強いのかがよくわからないという欠点はあったんですが、どうせならPiccolo、Begeta、Freezaとかの方が序列がわかって良かったかも(^^;

そんな今回のUpdate、ざっくりまとめると以下のような感じです。

★ Performance Analytics

6月頃に紹介されてたExpensive Queries ToolがGAになったってことかな？

https://postgres.heroku.com/

から使えます。
DBを選択すると遅いクエリのSQLを特定してくれて一週間分のそのクエリのパフォーマンスグラフを表示してくれます。

この手のパフォーマンス問題はインデックス一個追加するだけで劇的に改善されたりもするんですが、その手掛りとしては最高レベルの情報提供だと思います。

また、CLIで

heroku pg:diagnose

というコマンドが追加されました。

diagnoseは診断という意味ですが、このコマンドを実行するとRed、Yellow、Greenという診断結果と共に各診断項目のレポートが返ってきます。

診断項目としては

• Hit Rate
• Indexes
• Connection Count
• Long Queries
• Idle in Transaction
• Bloat
• Blocking Queries
• Load

があるようです。例えばIndexesであれば「このインデックス全く使われてないから削除した方が良いよ」みたいな提案がされます。

診断項目自体はHerokuの中の人が恣意的に決めたものだと思いますが、そこは十万単位のProductionデータベースを運用している人達です。きっと良い感じの提案をしてくれるのでしょう。(^^;

PostgreSQLにはデフォルトで収集されているパフォーマンス改善のための統計情報テーブルがたくさんあるんですが、よっぽど必要に迫られた時以外はそれらの見方を調べようとは思わない訳で、それがコマンド一つでエキスパートによるレポートとして返ってくるというのはかなりイケてる話だと思います。

もっとも、手元のDBでいくつか試してみたところHit Rate以外はAll Greenになるのでどんなレポートが返ってくるのかイマイチありがたみがよくわかりませぬ。(^^;;;

★ Continuous Protection と On-disk Encryption

Premiumプランでは継続的なDB保護とDB自体の暗号化がされます。

DB暗号化は特に説明不要かと思いますが、Continuous Protectionってのはなんなんでしょうね？
60秒おきの新データのアーカイブとか30秒おきのヘルスチェックとか書かれてますが、要するにHA(High Availabity)を担保するためにこんなことしてますよ、ってことではないかと。

PremiumプランのHAオプションは、元々裏でFollow DBが自動的に作られて障害時には自動的に切り替わるというものなので、その安全性がさらに高まったという話なんだと理解しました。

★ 2倍のメモリ、3倍のパフォーマンス

これが今回の発表で一番重要な情報です。

新プランのラインアップは完全に旧プランと対応していて、旧プランの価格と同じ価格のプランがすべて揃っていますが、価格は同じでもメモリは2倍、パフォーマンスは計測上は3倍になっています。

ただし、この恩恵を受けるためには明示的にAddonをアップデートする必要があります。(メモリが変わるってことはPostgresが実行されているホストも切り替わるから)

https://devcenter.heroku.com/articles/upgrading-heroku-postgres-databases

pgbackups:transfer というコマンドが追加されて移行も簡単にできるようになったみたいですね。

ProductionプランでHeroku Postgresを運用している人は早めに切り替えた方が良いでしょう。

★ PremiumとStandardの違い

最後にStandardプランとPremiumプランの違いをまとめておきます。
違いは全プラン共通で以下の3点です。

• Encryptionされない
• Rollback可能な時間が60分(Premiumは7日間)
• High Availabilityじゃない

Rollbackはそう言えばそんな機能あったなぁ、と今思い出しましたが過去にブログ書いてます。

http://blog.flect.co.jp/labo/2013/11/heroku-postgres-62fb.html

読み返すと旧バージョンではRollback可能な期間がプラン毎にバラバラだったのが今回60分と7日間に統一されたようですね。
さすがに一ヵ月はやりすぎだと気が付いたらしい。(^^;

個人的にはStanndardの60分は短すぎて実質的には使えないような気がしますが、実際のところはどうなんでしょうね？ 逆に過去の統計からRollbackが使われる場合の期間の大半はこれで十分という判断があったのかも。

まぁ、実際には一度も使ったことがないのでどうでも良いんですけどね。(^^;;;

やっぱりStandardとPremiumの選択時のポイントはHAの有無だと思います。

ふと思い立ってPDF出力のAddonの調査していたら予想外に大変な便利Addonにぶちあたりました(^^;
多分これは今年一番のお役立ちエントリです。一度でもPDF出力に悩まされたことのある人なら読まないと後悔するレベル(かも)

★HerokuのPDF Addon

Addonを探すとDocRaptorとHyPDFという二つのAddonが見つかります。
どちらもHTMLを渡せばそれをPDFに変換してくれるというサービスのようです。

多分、DocRaptorの方が有名なので、最初こちらから試そうと思ったんですが。。。
料金プランを見てビックリ

• Starter(Free) - 月に5件まで
• Basic($19) - 月に125件まで
• Professional($37) - 月に325件まで
• Premium($95) - 月に1250件まで
• Max($189) - 月に5000件まで

無料プランがあるのは良いんだけど、月に5件ってなんだよ。。。(--
そんなのテストしてたら一瞬で消費するっちゅーの。

一番上のプランでも月に5000件、一日換算だと166件しか出せないって。。。
なんでこんな料金プランにしてるんだろ。。。

一方のHyPDFの料金プランは以下

• Nano(Free) - 日に5件まで
• Milli($15) - 日に15件まで
• Kilo($30) - 日に45件まで
• Mega($60) - 日に135件まで
• Giga($120) - 無制限

安っ！
制限のリセットも１日単位なので、ちょっと試すだけでもこちらの方が扱いやすそうです。
何より$120で使い放題というのは太っ腹。(^^;

ていうか、あんまり商売っ気がないのかも。
ブラウザで「www.hypdf.com」にアクセスすると、いきなりHeroku AddonsのページにリダイレクトされるのでどうもHyPDF単体ではサービス提供しておらず、Heroku Addonとしてしか提供されてないみたいなんですよね。
そういうのもアリなのか。。。(^^;

そんなこんなでまずはHyPDFから試してみることにしました。

(後から気がつきましたがDocRaptorにもHyPDFにもテストモードがあって、その場合は制限回数は更新されません。と言ってもDocRaptorの方はもはや試していませんが。。。)

★HyPDFの使い方

https://devcenter.heroku.com/articles/hypdf#api-reference

基本的な使い方としてはJSONで出力対象のHTMLと各種オプションを渡すだけです。
そうするとレスポンスのHTTPボディでPDFのバイナリが返ってきます。
HTMLの渡し方には文字列でHTMLを丸ごと渡す方法と、URLで外部サイトへの参照を渡す方法の両方がサポートされています。

オプションとしては

• ヘッダ、フッタ
• 上下左右の余白
• グレイスケール
• コールバックURL(指定した場合PDF生成が非同期となり生成完了時にこのURLがキックされる)
• 生成したPDFをS3にアップロードするためのオプション情報

などが指定できます。
何回か試したところ、PDF生成には最大10秒くらいかかることがあったのでHerokuから使う場合は非同期にした方が良いかも。

使い方は難しくないですけど唯一の注意点はHyPDFの使っている証明書がStartCom(StartSSL)の証明書だという点です。
知らなかったんですがこの証明書、デフォルトではOracle JDKのキーストアには入ってないんですね。なので、接続するためには自分で証明書をインストールするかHostNameの検証をスキップするかする必要があります。
(この辺を調べてる過程でさらに憂鬱な衝撃の事実を知ったんだけど、それはまた別に書きます。)

一応JavaのAPIラッパーも作ったのでサクッと試したい場合は使ってみてください。

https://github.com/shunjikonishi/hypdf4j

ちなみにHeroku上ではOpenJDKだからなのか、キーストアをHerokuが独自で用意しているからかわかりませんが証明書のインストールは不要です。

ちなみにちなみにPDF生成以外にも

• PDFのプロパティ情報取得(pdfinfo)
• PDFのテキスト取得(pdftotext)
• PDFの連結(pdfunite)
• 複数ページのPDFから指定ページの抜き出し(pdfextract)

といったことが(APIラッパーでも)できますが、多分そんなに使うことはないです。(^^;

★PDFの日本語出力は必ずはまることになっている

そして、とりあえず試しに作ってみたPDFがこんな。

。。。
あー、うん。。。。この豆腐見慣れてるなぁ。。。(--

思い出したけど、自力でPDF生成を試みた時も日本語フォントで挫折したんだった。。。。
PDFを生成するホストに日本語フォントをインストールすれば出力することはできるんだけど、ライセンス関係がどうなっているのかがイマイチ確信が持てなくて結局棚上げにしたような気が。

これはアカンかもなぁ。。。と思いつつ、一応サポートに日本語出ないんだけどと投げてみました。
で、その間にDocRaptorの方も試してみるかとドキュメントを読んでたらなんと20分後には返事が来ました。

早っ！！

You can use any custom font by including it with @font-face in your styles:

@font-face {
    font-family: MyFont;
    src: url(www.somecdn.com/my_font.ttf);
}

body {
    font-family: MyFont;
}

な・る・ほ・ど！！！
ここでWebフォントなのか！！！！

Webフォントって図形文字や凝ったデザインの文字を使う場合に使用するものというイメージでしたが、探してみるとIPAフォントとか標準的なものもあるんですね。

IPAフォントを組み込んで出力してみると日本語も正しく出力されるようになりました。素晴らしい！(^^v

PDFのフォント問題って世界中の開発者が頭を抱えてる問題のような気がしますけど、これはかなり見事な解決方法だと思います。
心の底から感心しました。

★excel2canvasと組み合わせてみる

ところで僕はexcel2canvasというHTMLのCanvasを使ってExcelをブラウザ上で表示するというライブラリを作ってたりするんですが、それとHyPDFを組み合わせた場合どうなるかということが気になってちょっと試してみました。

Canvasへの描画はちょっと厳しいんじゃないかと事前には思ってたんですが、試してみると結果はこんな感じ

凄っ!!!
思った以上にイケてるやんけ！

何パターンか試してみたところ、HyPDFはHTMLの横幅に合わせてスケールを調整するらしく、幅がExcelの標準レイアウトで1ページに収まらないようなものはレイアウトが崩れますが、印刷前提でレイアウトが調整されているようなExcelファイルはだいたい良い感じに出力されました。(^^v

今時のExcelはファイルをHTML形式で保存できたりもしますが、Webフォントへの変更とかそれなりに手間だったりもするので、これはこれでアリなソリューションだと思います。

勢い余ってデモサイトも作ってみたのでご興味ある方はお試しあれ。

http://hypdf-excel.herokuapp.com/

ていうか、これこのままHerokuアドオン化しても需要ありそうじゃね？(^^;

になったようです。

https://blog.heroku.com/archives/2014/7/7/websockets_now_ga

めでたい。(^^v

今後は「heroku labs:enable websockets」としなくても標準でWebSocketが使えます。

Router自体が新しいものに置き換わるようで、上記のアナウンスブログからリンクされているImproved Routerのドキュメントはなかなか読みごたえあります。

Routingや接続過多の場合のキューイング方法などについても詳しく説明されており、高負荷なアプリケーションを開発している人には必読のドキュメントだと思います。

要約しようかと思ったけど、100 Continueのあたりがよくわからなかったので止めた。(^^;

ほとんどは前にもどこかで書いたことのある話だったし。

一個だけ、へぇ、と思ったのはRoutingのところにあったこの一文。

Inbound requests are received by a load balancer that offers HTTP and SSL termination. From here they are passed directly to a set of routers.

SSL terminationをするLoad Balancerと各Dynoにリクエストを割り振るRouterは別モノだって。少なくともssl:endpointを有効にした場合はそうなっているっぽいと思ってたけど、ちゃんと文書で読んだのは初めてかも。

昨日は午後から半日FlyDataのセミナに行ってきました。
体調も微妙だったので正直半日セミナは辛いなぁと思ってたんですが、なかなかどうしてかなりアタリのセミナでした。
RedshiftもFlyDataも2、3の飛ばし記事を斜め読みしただけのエンジニアがそれらをなんとなくわかった気になるには十分な内容でした。

★ Redshiftとは

Amazonが提供するビッグデータのエンジンです。
ローンチは2013年2月。既に60以上の新機能追加が行われており現在Amazonがもっとも気合を入れて作りこんでいるプロダクトと言っても良いと思います。
その特徴としては以下があげられます。

• 速い
• 安い
• SQL互換

ビッグデータの分野ではHadoopが有名ですが、後発なだけあってそれよりも速度、価格の両面で大きな優位があります。
また、検索インターフェースがPostgreSQL互換なので使いなれたSQLがそのまま使えることも魅力です。
PostgreSQL互換なので既存のBIツールの多くがそのままRedshiftでも使うことができます。

技術的にはカラムナデータベース(列指向DB)の上に超並列処理(MPP)アーキテクチャと呼ばれる技術が採用されており、ノードを追加すると線形にパフォーマンスが向上するという特徴があります。

アーキテクチャはビッグデータに特化しており、数十GB程度までのデータであればRedshiftよりも高速に捌くプロダクトはたくさんあります。
ですが、それらのプロダクトではデータ量がテラバイト、ペタバイト単位になった場合にパフォーマンスが指数関数的に劣化し、それに対する解決策がほとんどないのに対しRedshiftはノードを追加するだけで必要なパフォーマンスを得ることができます。

検索性能のトレードオフとして更新性能(特に1行単位のデータ更新)は極めて遅いです。

★ FlyDataとは

Redshiftの現状の機能と新機能追加の力配分は大きく検索系の処理に傾けられています。言い換えればデータ投入の部分はあんまり使いやすくないにも関わらず、それほど大きな改修は行われていません。

そこを補完するのがFlyDataです。
FlyDataはRedshiftへのデータ投入のインターフェースとして以下の二つを提供します。

• JSONログ
• RDB(MySQL)とのレプリケーション

JSONについては最近Redshift本体にも取り込み機能が追加されたようですが、使い勝手の面ではまだまだFlyDataに優位があるようです。

また、Redshiftはメンテナンスのために定期的に更新処理が停止されるらしいんですが、その間の更新データのバッファリングもFlyDataがよしなにやってくれます。

□□□□
というのが、現状の小西の理解(THE にわか知識)ですが、多分そんなに大きくは外してないと思います。(^^;;;

★ 特別講演: モバイル＆クラウドでビッグデータをイノベーション基盤に

今回のセミナでは最後に特別講演としてNTTドコモ 栄藤氏によるビッグデータ活用に関する講演が行われました。

Redshift、FlyDataに関する講演が知りたいと思っていたことを知れたという意味で満足度が高かったのに対し、この講演は今まで考えもしなかったような視点に気がつかされたという意味で大変有意義でした。

この日の公演は7月17日のAWS Summitで栄藤氏が行う話の予告編的な位置づけだったようで、スライド等は公開されていないようですが非常にエキサイティングな内容でした。
本講演を聞きに行けないのが無念です。(^^;

その要旨を一言でまとめると

ビッグデータの解析は莫大なデータの中から平均的なトレンドを発見するために行うものではない。

というものです。
そういうことがやりたいのであれば、全データを解析する必要はなくサンプリング調査で十分なんだそうです。実際、精度もほとんど変わりません。

そうではなくて、ビッグデータの意義は

莫大なデータの中から異常なトレンドをすくい上げることにある。

というお話が深く心に刻まれました。

例えば、Twitterの膨大なツィートの中である特定の1時間だけ「docomo」「携帯」「スマホ」みたいな単語を含むツィートが極端に多かったとします。

そのデータからdocomoのサーバで障害が発生していた時間がほぼ特定できるそうです。(^^;;;(もちろんauやsoftbankでも同じです。)

これに位置情報も加われば、地理的時間的な異常を検出できるので確かに今までとは違う世界が開けるかもしれません。

かえすがえすAWS Summitに申し込んでなかったのは不覚です。。。。(--

昨日別件(Play起動時にGruntも実行する)で教えてもらったドキュメントです。

http://www.playframework.com/documentation/2.4.x/SBTCookbook

なんと、この文書の下の方に「Disable documentation」として、コンパイル時のScalaDocの生成を止める方法が記載されています。

やり方はbuild.sbtに以下を記述するだけ

sources in (Compile, doc) := Seq.empty

publishArtifact in (Compile, packageDoc) := false

このドキュメントは未リリースの2.4のものですが2.3でも問題なく動きます。

実測で2分くらい速くなりました。素晴らしい(^^v

ども、小西です。

昨日6月9日にビルボードライブ東京で行われたSalesforce1 Developers Community MAXというイベントでWebSocketの話をしてきました。

会場名をもう一回言うけどビルボードライブ東京だよ！Googleのインドアビューで見るとこんなだよ！！

なんでこんなところでテッキーな話を。。。と思ったけど見る側にしたら机もあって良かったのかも。(^^;

発表資料はこれ。

http://shunjikonishi.github.io/slides/websocket/index.html


持ち時間に対してとにかく内容を詰め込んだので置き去りにされた人も多かったかも。。。

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

資料はそれだけ見ればわかるように作ったつもりなので、気になる人は見てくだされ。
プレゼン中に口頭でのみ説明した内容もだいたい文章で入ってます。

春頃からこのブログでも何度もWebSocketの話題をとりあげていて、言いたいこともたくさんあったんだけど、だいたいこれで全部吐き出せたかな。(^^;

セキュリティの話とかWebSocketをAjaxの代替として使う話とかは他ではあまり見かけたことがない内容で個人的には結構満足してるけど、果たして一般受けするかどうかは謎。。。(^^;

以下今回のイベントでの個人的なトピックです。

★Happy HourにまさかのQuizar

今回Salesforceの岡本さんのご厚意(?)で、Happy Hourの余興で3月に作ったQuizarによるクイズゲームが行われました。優勝賞品はプレステ４！！

多分50人くらいが参加してたんじゃないかな？ぶっちゃけこれまでにそんな人数での実践をしたことはなかったんだけど、まぁ普通に動いて良かった。(^^;

ちなみにこれ元々は参加人数は最大50人に制限してたのを、200人まで参加可能なように会場でその場で修正しました。(^^;

作った当時はどの程度の同時接続を捌けるのかに関してあまり確信がなかったけど、その後にやったC10Kのテストの感触から言うとDynoを増やせば1000人とかでも普通に捌けるとは思います。(これが数万、数十万のオーダまでいけるようであれば、テレビとかでも使えそうだけどさすがにそれは自信ないなぁ。。。クライアントへのpushをもうちょっと賢くすればできるかもしれないけど。)

まぁ機会(と度胸)があれば試してみてください。(^^;
何にせよ会場の皆さんにWebSocketアプリを体感してもらえたのは良かったと思います。岡本さんありがとうございました。

Quizarは特に宣伝しているわけでもなく、この先大幅な機能追加が行われることもないと思うけど、ひっそりと営業中なので勉強会等をやる機会のある人は使ってみてください。
ご意見、プルリク等は歓迎します。(^^;

スターがいっぱいつくと開発／運営方針とかも変わるかもよ？(^^;

★@i556 HackChallenge癒しアプリケーション部門で優勝

同僚の@i556が見事優勝して10万円GET!!!

おめでとう！！！
そしてごちそうさま！(と、先に言ってみる)

作ったアプリはタスクを癒し系アイコン(タスクの達成度が高いほど癒し度アップ)でカレンダー上に表示してユーザーのモチベーションを上げるというもの(で、あってるよね？)

優勝者発表の前から猫には勝てると思っていたよ。
本当におめでとう。

ちなみにHeroku賞はまさかの該当者なし。。。
もうちょっと早くにお題出しとけよ。。。(--

自分のプレゼンでテンぱっててそれどころじゃなかったんだけど俺もなんか出しておけば良かった。(--

★REVEAL.jsの話

ちょろっと聞かれたけど、今回プレゼンに使ったREVEAL.js。はっきり言ってイケてる。
ていうか、プログラマが使うプレゼンツールとしては最強なんじゃなかろうか。
なにせ、基本マークダウンだけでプレゼンが作れて足りないところはHTMLとJavaScriptでどうにでもできるので。

興味のある人はサンプルサイトを覗いてみると良いと思う。
ストーンズの50年とかマジかっこよくてお勧め。

とりあえず試してみたい人は

https://github.com/shunjikonishi/slides

をcloneしてgrunt起動すれば動きます。
基本content.mdだけ編集すれば良いのでドキュメントとかまったく読まなくてもそれなりに使えると思う。

今回使ったプログラム要素は

• プレゼンの残り時間とスライド一枚当たりの時間を画面に表示
• iframeでアプリ埋め込み
• お絵描きのWebSocketサンプル埋め込み
• setIntervalのデモ
• js-sequence-diagramsの埋め込み(ただしブラウザのSVGのレンダリングにバグがあるのか表示が安定しなかったため本番ではイメージに差し替え)

など。
今朝になってトップにTwitterとFacebookのソーシャルボタンも追加してみた。(^^;

これ本当に何でもできるのでTwitterのTLを埋め込むとか、アイデア次第で色々なことができそう。
WebSocketを使えばそれこそ聴衆参加型のプレゼンもできるはず。
なんか思いついたらそのうちどこかでチャレンジしてみたい(^^;

行ってきました。
ていうか、LTしてきました。(^^;

今回は同僚の@i556の発表があったり、がちゃぴん先生(@kosaki55tea)の濃ゆいカーネルの話があったりで、非常に面白かったです。

★ WordPress On Heroku

http://www.slideshare.net/kokorojw/wordpress-on-heroku

いや思った以上に良く調べていたんでびっくりした。(^^;
普段結構とっぴょうしもないことを言ってることが多いので、どんな発表になるのかと思ってたけど、資料も過不足なくわかりやすくまとまっていて良い感じ。

そういえば前に社内で発表してたデザインの話にもとても感心したことを思い出し、実はできる子です。＞ @i556(^^;

WordPress使ったことがないのでHerokuでWordPressが動くことのインパクトがどれくらいあるのか正直よくわからないんだけど、やりたい人がたくさんいるのであればもうこの際、

WordPress込みでbuildpack作っちゃえば良いんじゃね？

とちょっと思いました。
ClearDBやCloudinaryの無償版をbuildpackで追加することはできるはずだし、DBのURLをファイルに転記することもbuildpack内でできます。(Heroku的にはPostgresを使って欲しいだろうけど。)

ID/Passwordはとりあえず環境変数に自動生成したものを書きだしておいて、設定ファイルでそれを見るようにするか、あるいは「.profile.d」にログインスクリプトを用意してDyno起動時に設定ファイルを書き換えるという方法でもできそうです。

WordPress本体はgitでバージョン管理するようなものではないだろうし、これができれば一度もgit pushしないでWordPressを動かすことができる気がするんだけどできないかな？(^^;

(。。。と書いてるそばから気が付いたけど一度もgit pushしないとSlugコンパイル自体が走らない気がする。PlatformAPIのSlug関連のAPIをbuildpackから叩くことができればなんとかなるかもしれないけど、ちょっと難しいかも。。。)

しかしまぁ少なくとも手順を大幅に簡略化することはできるはず。
気が向いたら試してみれ。 ＞ @i556(^^;

★ Linux Container Update

http://www.slideshare.net/kosaki55tea/linux-container-update

正直Kernelの話とか完全に守備範囲外なわけですが、お話とても面白かったです。(というか、わかるように話をしてくれていたと思う。)

レイヤが違ってもやってることも考え方もあんまり変わらないですね。ただ考えなきゃいけないことの種類が全く違うだけで。

その中で一番興味を惹かれたのはやっぱりLive Migrationの話。コンテナプロセスを丸ごとコピーして他のホストで復活させる。マジでか！！！

個人的には本当にちゃんと動くの？というところかなり懐疑的だけど理屈はわかります。

死にそうなプロセスをコピーしても、コピーした先でやっぱり死ぬだけなんじゃないの？と思って先生に質問したところそれはやっぱりその通り、とのこと。

使いどころとしては1ホスト内で複数のコンテナをあげる運用している事業者が、なんらかの閾値を決めてホストを監視して、閾値を越えて動作がやばそうになったコンテナがあったら他のまっとうなコンテナをLive Migrationする、みたいな感じになるんだと思う。

。。。それは凄いな！！！
この技術が浸透して当たり前のものになると、ハードの寿命を越えて永遠に動き続けるプロセスを作ることも不可能ではないってことか！(実際にはその間にOSのアップデートなんかがあって現実的ではないだろうけど。)

非常に先行きが楽しみな技術です。(^^

★ My LT: 一番簡単なWebSocketの試し方

http://www.slideshare.net/shunjikonishi/websocket-34998961

多くは語るまい。
6/9のSalesforce1 Develper Community MAXに話を聞きにきてくださいっちゅーことですよ。(^^;

Heroku ConnectがGAになったようです。

https://blog.heroku.com/archives/2014/5/13/introducing_heroku_connect

と言っても現状では使うためには直接コンタクトをとる必要があるようです。
以下、ざっとドキュメントを読んだまとめと感想です。節立てはドキュメントを踏襲していますが、個人的に引っ掛かったところを中心にまとめているだけで決して翻訳ではないので、ん？と思った方は原典をあたってください。(^^;

ちなみに1節読む毎に書いていたので先に書いた疑問が後で自己解決していることもあります。具体的にはINSERTに関する推測が最後に全部ひっくり返ります。直そうかとも思ったんですが、文章の流れもあるのでそのままにしました。

★ How Heroku Connect works

• Heroku ConnectはSalesforceオブジェクトのレプリカをPostgreSQL上に作成するもの
• テーブル名、列名はSalesforceと同じになる(ただし小文字)
• Salesforce、DBの変更が双方向に同期する
• SF -> DBの同期には「LastModifiedDate」列を利用する
• DB -> SFの同期にはDatabaseのトリガーを利用する
• DBの変更の反映はUserPermissionsとValidationRulesの影響を受ける
• DBの変更は変更されたカラムのみが更新対象となる

これを読む限りSalesforce側になんらかのこのためのオブジェクトが仕込まれたということはなく、完全に外部からAPIの制御だけで作られているように見えます。

スキーマは常にSalesforceと完全に同じになるのかな？
そうだとすると以下の点が気になります。

• 必要な列のみをDBに持たせることはできないのか？
• スキーマの変更にどのように対応するのか？(最低限列の追加には対応してほしい)
• ID列の扱いは？これがそのまま主キーになるの？

特に最後のID列の扱いは気になるところで、実はDB側ではUPDATEはできてもINSERTはできないんじゃないの？という気がします。(IDが生成できないので)
あと、DELETEの扱いはどうなるのかというのも気になるところです。

INSERTが扱えないんじゃないかと思う根拠はもう一個あって、以前にDB -> SFの片方向同期を自前で実装した時に参照(親子)関係の扱いがけっこう面倒だった記憶があるからです。

必ず親を先に同期するとか、外部キーが必要などいくつか注意すべき点があるんですが、その辺が考慮されているとはここからは読み取れません。

★ Synchronization frequency

• デフォルトではSFの変更検知のポーリングは10分単位
• ただしHeroku ConnectのUIを開いている間は3分になる
• デフォルトではDBの変更検知のポーリングは5分単位
• ただしHeroku ConnectのUIを開いている間は1分になる
• Fast Synchモードにした場合更新頻度は30秒に一回になるがその分APIを消費する(Developer Editionの場合はほぼ間違いなくAPIを使いきる)

DBトリガーを使っているにも関わらずポーリングもあるということは、トリガーで行っているのは管理用の別テーブルへのINSERTだけでそれをまとめて更新しているってことでしょうね。5分の間に2回更新が発生したら2回のUPDATEが実行されるんですかね？(それで問題ないと思いますけど)

★ Heroku Connect and Salesforce API consumption

• 同期オブジェクト1つにつき約500のAPIを消費する
• リードオンリーモードの場合はAPIの消費はもう少し少ない
• APIは更新ボリュームによってSOAPとBulkを自動的に使い分ける
• DB -> SFで1度に更新できるのは200レコードなので10000レコードの更新は50APIを消費する
• 初回の同期(全データコピー)は500万レコードで120分程度かかる(外部IDがない場合)

残念ながらAPIの優遇は一切ないようです。。。(--
1度に200件というのもSOAP APIの制限そのままですし。

初回120分というのはBulkを使ってもこれ位ってことですかね。(SOAPだとどう考えてももっと遅そうだし、Bulkを使わない理由がない)
スループットにすると694件／秒なのでそんなもんかとも思いますが、速いCPUのDBを使っていればもうちょっと速いんじゃないかとも思います。

外部IDの有無で性能が変わるというのはDB側でもForeign keyをちゃんと定義しているということでしょう。

★ How Salesforce objects map to Postgres database tables

• セットアップ時にオブジェクトに対応するテーブルが自動で作られる
• テーブル名、列名はSalesforceオブジェクトと同じ(ただし小文字)
• DBの主キーはAuto Increment
• SFのIDは「sfid」という列となりUnique Indexが付与される

先に書いたIDに対する疑問の回答が書かれていました。
これを読む限りやっぱりINSERTはできそうにない気がします。

★ Provisioning the add-on

• Heroku Connectはアプリと同じリージョン(US or EU)に配置される
• アドオンを追加したら最初にWebUIでセットアップをする
• 設定項目は対象DB、使用するDBのスキーマ名、SF認証情報など
• SF認証に使用するユーザーは十分な権限を持っている必要があるので連携専用のユーザーを用意することが望ましい。

ブログアナウンスでは使いたい人は直接連絡しろとありましたが、CLIのheroku addons:addで追加できるみたいですね。(試してませんが。)
日本でSalesforceを使う場合は当然日本に置くので、Herokuもとっとと日本リージョンを持ってこいっちゅー話です。

関係ないですけどCLIからアドオンの管理画面をコマンドで開けるということを初めて知りました。

heroku addons:open papertrail -a xxxx

地味に便利です。

★ Mapping objects

• WebUIで同期するオブジェクトの設定ができる
• SFユーザに「View All Data」と「API Enabled」の権限が必要
• あとは一覧からポイント＆クリックで設定できる
• 同期の状態はWebUIで確認できる

どうやら同期する列も選択できるらしい。

WebUIがどの程度の情報をサポートしているのかは気になるところ。

★ Resolving read errors

認証に使用するSFユーザに十分な権限がなかったり、オブジェクトに読み取り制限がかかっている場合は同期が正しく実行できないという話

★ Accessing the synchronized tables

DB側でのデータへのアクセス方法。普通にログインしてSELECTするだけ。スキーマがデフォルトでは「salesforce」になっているのでpsqlを使う場合はsearch_pathにsalesforceを加えると良い。

★ Updating data in Salesforce

• デフォルトはReadOnlyモードなのでDBの更新を反映するにはRead/Writeモードに変更する
• DBの更新は＜テーブル名＞_trigger_logsというテーブルに記録され、それを元に更新が行われる
• DB -> SFの更新結果は「SUCCESSFUL」「IGNORED」「FAILED」のいずれか
• SUCCESSFULのデータはtrigger_logsから削除されるが、それ以外は残る

予想通り、DBトリガで別テーブルにINSERTしているだけのようです。
IGNOREDっていうのはどういう時に発生するんでしょうね？また、SUCCESSFUL以外のレコードは残り続けるとありますが、それがいつ消えるのかとかリトライはされないのかというのも気になります。

★ Inserting records to Salesforce

なんと！ここまでの予想を覆してDBへのInsertは可能だそうです。
どうやって実現しているかというと単純にsfid列はNULLABLEなのでそれは無視して、必要な列のみでINSERTするだけ。
あとは同期のタイミングでsfid列が自動で設定されるようです。
ちなみにINSERT後に同期が走る前にUPDATEやDELETEが行われた場合も、それらはちゃんとマージされる(DELETEの場合は何もなかったことになる)ようです。
master/detail関係のレコードも外部IDが設定されていればちゃんと反映されるとのこと。

先に書いた参照関係に対する懸念についても丁寧に説明されています。
ここに来てHeroku Connectへの評価は10段階位跳ね上がりました。(^^v

★ Using External IDs to manage relationships

AccountとContactを例に参照関係の解決のための外部IDの設定方法が書かれています。
要するにAccount側に外部ID列を追加しておけば、同期時にそれを利用することができるってことですね。

若干冗長ですが、これは仕方ないかな。。。

★ Resolving write errors

認証ユーザに十分な権限がなかったり、SFオブジェクトのValidation Rulesに引っ掛かった場合にはエラーとなる。
あるいは計算フィールドも同期可能だが、そこへの書き込みはエラーとなる。

これらのエラーはDBに記録されWebUIから確認できる。

★ Schema changes

スキーマ変更は問題なし。
列の追加はHeroku Connectの動作に何の影響もなく、その列を同期したいならマッピングを追加すれば良い。既存行の値はその時に同期される。

列の削除や変更では同期がエラーになるのでマッピングの変更が必要

★ Pausing Heroku Connect

WebUIからHeroku Connectの同期を一時的に停止できる。

オブジェクト単位ではできなくて、全体での停止しかできないらしい。

★ Import and export of configuration files

yaml形式でマッピングのインポート／エクスポートができる。
Sandboxで定義したマッピングを本番に移行する場合などに有用

★ Notifications

エラーや同期処理が60秒以内に終了しない場合などにはオーナーに対してメール通知が飛ぶ

★ Security

Heroku ConnectはSalesforceのOAuthトークンを保存している。
データ転送はすべてSSL。

ふと気になったけど、Heroku ConnectのIPは固定されるんですかね？
Salesforce側でAPIのIP制限がかかっている場合の対処方法があるのかどうかはちょっと気になるところです。

★ Using Heroku Connect and the demo Rails app

Heroku Connectを使ったRailsのサンプルアプリがあるのでまずは試してみるが良い。
このサンプルアプリではAccoutとContactを同期する
セキュリティについては特に考慮されてないので間違ってもこのデモアプリを本番環境のSalesforceで動かしてはいけない

★ Removing Heroku Connect from your Heroku app

WebUIからもCLIからも削除可能

★ FAQ
★ Support

省略。
なんかリトライする場合はtrigger_logsテーブルを直接UPDATEすれば良い、みたいなことが書かれていてなかなか衝撃的(^^;


□□□□
以上、同期処理自体はほとんど自力でやった時と同じようなものですが、WebUIで同期状況が継続的に監視できるのは良いですね。
どうでも良いけど料金体系がどこにも記載されてないような。。。