Tag Archives: development

PhoenixをHeroku上で動かしてみた

ElixirのPhoenixをHeroku上で動かしてみました。久しぶりにheroku動かしたのですが、GitHub連携やDropbox連携も追加されたのですね。 環境 Erlang version 17.5 Elixir 1.0.4 Phoenix 0.13.1 テンプレートプロジェクトの作成 Deployするプロジェクトは以下を参考に、簡単なサンプルプロジェクトにしました。 http://www.phoenixframework.org/v0.13.1/docs/up-and-running Herokuへのdeploy対応 Herokuへのdeployは、heroku-buildpack-elixirを使いました。 https://github.com/HashNuke/heroku-buildpack-elixir 基本的にはここに書かれている手順を踏めば良いのですが、軽く手順を残しておきます。 elixir_buildpack.config を生成する 内容は以下です。 Procfile の作成 内容は以下。 Heroku側の設定 ひとまず、手軽にdev環境を稼働させたかったので以下の対応をしました。 1. dev環境の設定 2. config/dev.exs を修正してポートをシステム依存にする 以下のような感じ。 3. DBの設定 HerokuのPostgreSQL Pluginを使い、usernameやpassword、databaseを作成します。 passwordなんかの大事な情報は、Herokuの環境設定を活用しましょう。 4. Deploy 接続 あとはHerokuのダイナモの数を調整して、アクセスできるようにします。 だいぶんお手軽にDeployできるようになりました。これから手を動かすぶんにはEC2やローカルで良さそうな気がしますが。 実施したリポジトリはこちら https://github.com/KazuCocoa/hello_phoenix/releases/tag/20150521 追記: 2015/07/30 Phoenix 0.15のheroku deployを見てみると、 config/prod.secret.exs を消して config/prod.exs に統一することが必要みたいですね。 確かに、何もしないでdeployすると config/prod.secret.exs が無いというエラーが確認されます。More

『リファクタリング:Rubyエディション』を読んだ

最近は積読消費週間。積読だった、リファクタリング:Rubyエディションを読んだ。 いつだったか、t_wadaさんのTDDの説明の中で紹介のあった、リファクタリングの書籍に興味を持って購入したやつです。 “エンジニア”と名がつく以上、開発に特化する人も、テストに特化する人も、リファクタリングとは1度くらいは付き合う必要があると思います。テストエンジニアだとテストツールやテストコードが主になると思いますが、製品コードを読むし、必要であれば修正することもそれなりにあるはずです。これは、そんな時の助けになると思い購入していたやつです。 コード書きながらでないとよく分からないところなんかはコード書きつつも、基礎的な考え方は多少プログラミングや設計を学ぶと至るであろうことが丁寧にまとめられている感じ。こういう書籍で、経験をまとめて腹に落とすことができるって、先人の功績を享受できる年代の美味しさですね。ありがとうございます。 Rubyだとそれらをどう行うか、Ruby固有のメソッドでどう簡単に実現するか、というところが言及されててすごく役立ちました。 個人的には暗記が得意ではないこともあり、こういったものはひたすらに暗記するのではなく、実務で必要な時に索引できるよに頭の中にある程度の索引を作っておけることを重要だと考えています。頭の中に多少なりとも索引可能な状態にしておくと、Ruby以外の言語でもこうしたいとか、考えるときに探すあてになったりもしますし。必要であったら、本を持ってコードと向き合いつつ、必要なところをピックアップして体験にも馴染ませる、という感じでしょうか。 ゲートウェイパターンとか、Web開発で肥大化に立ち向かう上では必須なやつだなーとつくづく思う最近でした。More

Stethoを使ってAndroidアプリのデバッグを容易にする

Android、iOSのようなクライアントアプリの開発では、特にDB関連や通信環境が絡むデバッグが面倒です。実際にデバッグを行うとき、例えば、Proxyサーバを立てて通信を覗いたり、SQLiteのファイルを直接覗いたりしますね。はたまた、Logの出力を仕込んで、そのログを追うという方法をとることが多いです。 また、単純な通信量であればAndroid Device Monitorなどが使えますが、通信の中身までは見れません。 それらの壁を低くするツールとして、SquareのGitHubから得られるPony Debuggerが有名です。これは、Chrome Developer Tools を使い、通信の内容を簡単に観察したりできるツールです。また、Android/iOSのChromeブラウザであれば、同様にChrome Developer Tools を使い端末上で動作するブラウザの情報を得ることができます。 そして最近、Facebookが出したAndroid向けのStethoを見つけました。リポジトリを見てみると、最初のコミットが2015年1月30日と非常に若いです。これを組み込んだapkではChrome Developer Tools を介し、SQLiteやNetworkの中身を観察することができます。特別なProxyを用意したり、SQLiteのファイルを直接操作する必要もありません。 まだ若いので、使い方とか諸々変わりそうなのでリンクだけ貼っておきます。 http://facebook.github.io/stetho/ https://github.com/facebook/stetho 基本的には、Applicationを継承したクラスをonCreateするときに、合わせて初期化メソッドを追加するだけ。 ネットワークをChromeで見るには少し手間かけますが、Squareのokhttpを通信向けパッケージとして使っている場合、OkHttpClientを初期化するときにデバッグ設定を追加するだけという手軽さ。 これらの機能を、例えばBuildConfig.DEBUGのときだけ有効にするとかしておけば、社内で配布するapkは誰もがChromeさえあれば通信内容を確認するという環境が作れてすごく良さそう。 なお、logcatに以下のようなsocketに接続できたという出力が得られたらネットワークの通信もChrome上で見ることができる状態になります。 Chromeを経由してネットワークの中身を見るとこんな感じ。More

Bugsnagを使ってみたが、良さそうだ

主にはモバイルアプリのクラッシュログなどのログ管理に関して、最近の流れを知りたいと思いいろいろ物色してみました。類似サービスとしてはCrashlyticsなんかがありますが、いろいろ使っていると機能的に柔軟性が足りなかったりして目的に沿った利用ができないことが増えてきて、他に手頃なサービスあるのかなと思ったことも要因です。 Crashlytics以外にもいくつか調べた中で、最終的に良さそうと思ったのはBugsnag。 Bugsnagは以前どこかで見たか聞いたことあったのですが、そのときはCrashlyticsのように整ったGUIがある方が使い勝手が良かったのでそこまで調べてませんでした。一方、最近ではGitHubとの連携など、サービス間の連携に対して価値を置くようになりました。そのため、ここでちょっとちゃんと使おうと思って使ってみることにしました。 Bugsnagが良かったところ 多くのプラットフォームに対応したログ収集サービス ログ収集サービスに特化していることもあり、多くの言語、プラットフォームをサポートしていました。 リファレンスが書いてあったものでRuby、Python、PHP、Laravel、WordPress、Android、Cocoa、Node.js、JavaScript、Unity、Java、EventMachine、Go、.NET。 私は今回はおもにAndroidのリファレンスを読んだだけなのですが、ログのフィルタリングやビルドの種類ごとにログに対してプレフィックスを変えるなど、よくできたSDKなように見えます。 ログを取得するときはBagsnag上で見ることもできますし、BagsnagからStreamとしてログを自分たち絵取得することもできるなど、APIの連携もちゃんと整っていました。参考になる。 Bugsnagの方々、ログ収集の知見、深そう。 豊富なAPI ドキュメントを眺めるとわかるのですが、ログを取得するためのAPIを豊富に提供しています。 例えばCrashlyticsのようなサービスだと、ある程度まとまった情報を1つの画面で見ることができますが、求める情報だけでフィルタリングするといった細かいところまでは手が届きません。そのため一時期はWebhookを使おうと思いましたが、WebhookにはCrshlyticsへのURLが含まれているだけなど、ログを取得するにはCrashlyticsのGUIを最終的に見るしかないし画面のカスタマイズがそこまで柔軟ではないので欲しい情報だけ絞って見ることが難しい状態でした。 なので、豊富なAPIは自分たちのみたい情報でフィルタリングするWebアプリを作ればそれらが見る事できるし、便利そう。 GitHubとのissue連携 GitHubとだけではないのですが、バグトラッキングシステムとの連携もちゃんとしていました。GitHubを例にとると、Bugsnagからissueの作成はサポートされているのは当然なのですが、ちゃんと連携しているissueが閉じられたらBugsnagのエラーも解決済みにマークされるのです。また、すでにGitHubにissueとして作られている場合、そのissueをBugsnagと別途連携させることができます。連携したら、やはり閉じられると閉じられる。 こういう流れができるわけですね。 クラッシュなどの不具合、特定のログが一定数発生 => issueを作成 => issueベースで作業 連携済みならBugsnagにマークがつくので、issueとして対応されているものかすぐ判断できます。また、issue作成時になんらかの形で再現性確認を自動化できればさらにハッピーになりそう。（モバイルアプリでは難しそうですが。。。） 以下、GUIと連携の例。 一覧。 エラーの詳細画面です。 GitHub issueとの連携箇所。 GHEとの連携もすでに用意されていることろがなかなかいけてますね。 こんな感じで投稿されます。 issueとの相互連携もできます。関連付けておくと、issueをCloseした時点で、Bugsnagのエラーも解決済みのマークがつきます。 よくなかったところ 良かったところ以外でいうと、GUIは他の類似サービスよりも劣ってるとみられる気がします。ただ、GUIを優先したいという要求は私にはないので、そこはさほどマイナスではないです。（むしろ、ログ収集ツールとして気軽に組み込める体裁を維持しているところがすごいと思いました） 他は、Android以外使ってないのでなんとも言えないです。。。なんかすみません。 締め Trialが14日間で、それが終われば制限化でFreeで利用することもできるようです。私自身の個人利用はFreeで大丈夫なので、今後も使っていきたい。 こういうログ収集システム、サービスの拡大につれて自社で作る状態に落ち着きそうですが、そこまでなる前の段階ではかなり良さそうなサービスに思えます。Crashlyticsなんかは、少数のアプリを監視すれば十分な状態ではほぼ満足いきますが、監視すべきアプリが増えたりしてくると物足りない。その中間がBugsnagで、そこからさらに拡大すると自社、という流れになるのかなと思ったりしました。 これで、私のAndroidアプリの開発環境は以下の形で落ち着きそう。 Circle CI + Bugsnag + Deploygate Bugsnagだ！More