無知を晒す

ふだんの出来事はこっちに書いてます: http://tana.hatenablog.com

GAE/SE Node で puppeteer を動かすよ

みなさん puppeteerつかってますか? 私は使ってません。なぜなら安定的に稼働させるための環境がないから...*1

しかしそれも今日までです。

先日 beta になった GAE/SE Node について

という話を聞きました。聞いたからにはやります。以下の通り。

const puppeteer = require('puppeteer')
async function takeScreenShot(url, filePath) {
  const browser = await puppeteer.launch({args: ['--no-sandbox']});
  const page = await browser.newPage();
  await page.setViewport({
    width: 1024,
    height: 768
  });
  await page.goto(url);
  await page.screenshot({
    path: filePath
  });

  await browser.close();
  return
}

こんな感じの関数を定義して動かした。ブログ用にちょっと整形したので、なんらかのミスで動かないかも。

以下感想と解説です。

起動時に --no-sandbox オプションがいる

コンテナ環境下で Chromium を動作させる場合に --no-sandbox オプションを要求されるの知らなくて最初うごかせなかった。ちゃんとエラーメッセージには書いてあるので、あとはどうやって puppeteer 経由で起動オプション渡すかって話だけど、上のコードみたいに .launch() に渡すオプションに args キーの値として渡せばいいらしい。

--no-sandbox オプションについてはちゃんと調べられてない。システムコール周りの話なのかなと思ってるけどなんなんだろうか……

インスタンスサイズ

デフォルトのインスタンスだとメモリ不足になったので、大きめのインスタンスを使っている。具体的には F4 インスタンス

f:id:side_tana:20180625225037p:plain

めちゃくちゃシンプルなページでも標準の F1 や F2 ぐらいだとこんな感じでメモリ不足に陥る。

上のスニペットで最後に毎回 browser.close() してるのはメモリ問題への対策なのだけれど、これでも連続して重めのページをレンダリングすると死んでしまう。あんまり死ぬようなら F4_1G にあげるしかか無いけど、その辺は様子見ながらやっていこうと思う。

その他

実際には 1 週間のライフサイクルを設定した GCS バケットスクリーンショットをアップロードし、 Slack に投稿している。 Slack に投稿するところ久々にやったので、画像の展開方法わかんなくてちょっと大変だった。( attachments.[].image_url が必要なやつ)

f:id:side_tana:20180625225847p:plain 要所を黒塗りにしたら訳がわからなくなりました

反省

開発環境あんまり整えずにガーッと書いたので、ローカルで何も考えずに動かすと GCS にアップロードできずに落ちたり、flowtype も無く typescript で書いているわけでも無いので後半めちゃくちゃ辛くなってしまった。

最近は会社も家も静的型付け言語 + IDEの静的解析とか、flowtype みたいなスタティックタイプチェッカの支援を受け続けてるし、テストもだいたい書いているのであまり苦がなかったのですが、久々にこう、大変な感じでしたね、、、。

*1:まあ別に転がしてる VPS とかラズパイとかあるんですけど、Slack の slash コマンドと組み合わせたいな〜とか考えるといい感じの環境ないな〜っという意味です

Fitbit StudioにiPhoneが繋がらない場合に試すべき民間療法

参考までに環境をまとめておくと

  • iPhone 6s
  • iOS 10.3.3
  • mobile app: Fitbit 2.43(730)
  • Fitbit Ionic: バージョン 27.30.5.8

で、具体的な手順としては

  • Fitbit App のアンインストール
  • 端末名の変更
  • Fitbit App のインストール

という感じ。アプリのインストールとアンインストールは勘でやったので不要かもしれません。

とにかくこれでアプリの開発者向けメニューから DeveloperBridge を有効にした際に「非アクティブ」と「接続しています…」みたいなのが交互に出てくる状況からは脱せました。

f:id:side_tana:20171117011543p:plain
*1

他に言語設定英語にしたり日本語にしたりしたけど関係あったのかな。

ところでfitbit ionic の開発環境は全てブラウザで提供されていて、PC、スマートフォン、ionic本体 が全てサーバを介してWebSocketで接続され、アプリのインストールやログの取得もWebSocketで行われていて、気合入ってるって感じ。

GarminのアプリケーションはUSBで本体繋いで、ビルドしたアプリケーションパッケージをファイルとしてコピーするだけだったので簡単に理解できたけど、試すたびに本体をUSBで繋ぐ必要があったりしてなかなか大変であった。

*1:前は "たな太郎のiPhone" という名前を設定していました

YAPC::Kansai でタイトルの長いやつをやります

えー、どうも、このところは猫も杓子もディープラーニングだってんで、ビッグデータやらHTML5やらなんてのはとんと聞かなくなっちまいまして。今じゃすっかり定着しちまいましたが、その前にはクラウドってのが流行り言葉でありました。その頃といえば PaaS とか IaaS とか、これも今日はきちんと使われちゃいますが、当時はもうめちゃくちゃだった[要出典]。さてそんな XaaS に BaaS というのがあったわけです。なんの略かといえば、 Backend as a Service でございますな。

そんな BaaS の中でもとくにモバイルアプリ向けのバックエンドを提供する一派がありまして mBaaS なんて名乗っていたわけですが。その中でもひときわ有名なのに Parse.com ってサービスがあった。こいつは 2016年の初めに終了宣言をしてそれから1年後、まあ今年の初めですな、宣言通りサービスを終了しました。

さて慌てるのは Parse.com を使っていた事業者だ。

というわけで、利用しているBaaSが終了するときにすべきこと または Parse.com の終了と私たちの取り組み というタイトルで一席ぶたせていただきます。

愉快な話ができるよう準備しておりますので、是非お越しください!

Google App Engine で Parse.com を看取る

ところで皆さんは1年前の今日,2016年の1月の28日に何が起きたかを覚えていますか? 私は覚えています.そう,Parse.com が1年後にサービス終了する,と宣言したあの日です.*1

ということで死にゆく Parse.com への最後の手向けとして parse-shutdown-monitor というサービスを作りました.斎場とも言えます.*2

f:id:side_tana:20170128033635p:plain
Parse Shutdown Monitor

いわゆる外形監視になるんですかね? そういう意味では普通の外形監視使ってもよかったのですが,今回は Google App Engine氏に喪主をお願いしました.

監視しているのは

  • ParseObject の取得と書き込み
  • Query の実行
  • User のSign-in
  • File の取得/アップロード
  • ParseConfig の 取得
  • Hosting で設置した静的コンテンツ
  • CloudCode の Hello, World
  • Jobs による定期実行

の 8 種類 10 項目です.

CloudCodeって言うのは Google App Engine とか Heroku みたいな PaaS として使える機能ですね*3.Jobs は Parse.com 上で動作する cron というか,Google App Engine の cron を使ったことがある人にはおよそそのままの理解で良いんですが,CloudCodeとして登録した関数を定期的に実行してくれる君です.

基本的にはGoogle App Engine の urlfetch api を使って, Parse.com の REST API を叩き,帰ってくる http のステータスコードを監視する,というようなことをしています.Jobs については直接監視できないので, Parse.com の CloudCode 実行してる環境から毎分アウトバウンドリクエストを生成して,Google App Engine 側で受けとって保存,さらに Google App Engine の cron で新しいレコードが作成されていることを毎分監視し続ける,みたいなアーキテクチャになっています.*4

作ってた時の面白エピソードとしては,移行先として公開されている Parse.com のオープンソース実装であるところの parse-server にはJobs に相当する機能が無く,また公式ドキュメントは全て parse-server を基準としたものに置き換わっているため, 結果としてドキュメントがない状態で Jobs に関するあれこれをしなくてはいけない,みたいなことがあったこととかですね.

開発環境について

なんかいろいろやってて結構便利に開発出来たんですけど改めて書きます.

*1:先日1月30日に終了するという情報更新がありました.

*2:ひょっとしたら日本で最後にParseAppの新規作成をしたのは俺なのではないか,もしかしたら世界中で最後かもしれない.世界一短命なParseAppがParseの最期を見守るのだ

*3:DBへの書き込みと取得を繰り替えし実施する必要がある場合,USにあるParseのサーバとJPのアプリやサーバがちまちまやりとりすると累計のトランザクションタイムが10秒を軽く超えていくので,こういったDBに近いところで処理出来る環境は大層重宝するわけです

*4:この記事書き始めた時点では Jobs からのリクエストは記録だけだったんですけど,それはだめだよねってことでさっき監視を追加しました.