MIX AND OTP vol 1

ElixirのGetting startedも、Mix and OTPの話に入りました。 http://elixir-lang.org/getting-started/mix-otp/introduction-to-mix.html でつくられる各ファイルの説明などから始まり、実際にExUnitでテストを書くまでの説明が載っています。 Agent Elixirはimmutable languageなので、状態を保持するにはProcessesかETS(Erlang Term Storage)を使う必要があります。ここは、Getting StartのところのProcessやTaskのところで説明があった、TaskとかAgentの話ですね。 ExUnit setup が用意されているのだけれど、このsetupのcallbackが後の test へ渡されるらしい。なので、setupで最後に渡す引数を渡して、それを test で受け取らないといけないのですね。 setupやsetup_allがあれば、teardownに該当するものもあるのかな?と思ってみると、 on_exit があるのですね。 ExUnit.Callbacksの中に、以下のような定義がありました。 これは ExUnit.OnExitHandler をcaseで呼んで使っている模様。 また、このon_exit自体はaddされるだけなので、ExUnit.OnExitHandlerのもとがどこにあるかコードで追ってみると、最終的には ExUnit.Runner の run の中にある loop に行き着いた。この処理開始のときに、 ExUnit.OnExitHandler も登録されて処理が進み、 on_exit でOnExithandlerにfnを登録、テストケースが終わった時点で実行する、と。なるほど。 もう少し、ExUnitを遡ると、ExUnit のモジュールでstart/1が定義されていて、その中の System.at_exit にテストケースが登録されていることが一番の始まりみたい。 ちなみに、この at_exit の説明は以下。 Registers a program exit handler function. Registers a function that will…More

Get start Elixir vol 3

Sigils Elixirでは、正規表現を書くときに ~r/neko/ と書きます。その ~r の書き方箇所のバリエーションや、 ~w 、 ~W などのword list、カスタムsigilsの作り方が書いていました。Rubyでも%wといったものをよく使うので、こちらも使いそうですね。 try, catch and rescueの使い方 In Elixir, we avoid using try/rescue because we don’t use errors for control flow. We take errors literally: they are reserved to unexpected and/or exceptional situations. In case you actually need flow control constructs, throws should be used. That’s what…More

Get start Elixir vol 2

processのところから、protocolのところまで。 processの話の中で、以下の文言がありました。 Process and links play an important role when building fault-tolerant systems. In Elixir applications, we often link our processes to supervisors which will detect when a process dies and start a new process in its place. This is only possible because processes are isolated and don’t share anything by default. And if processes…More

Get start Elixir vol 1

Elixir自体に慣れようと、Get startedをなめてみました。Elixir 1.0.4がリリースされた頃のものです。以下はメモがてら、です。 http://elixir-lang.org/getting-started/introduction.html すごくDocumentが整備されている感がありました。 特に繰り返しでは再起を使うというRecursionの説明があったあと、それを容易にするための Enum を提供しててその機能に関する説明、 Stream の話もという形で頭にストーリーを植え付けながら内容を理解できる感じです。 以下、ちょっとメモです。 Modules http://elixir-lang.org/getting-started/modules.html でコンパルしたとき、 を実行したディレクトリと同じディレクトリにコンパイルしたものがあれば、自動的に読み込まれてりようできるもよう。 はスクリプトとして実行される。 defpは、同一モジュール内からのみ呼ぶことが可能なprivateなモジュール。なるほど。継承とかどうなのかな。(まだそこらへんは読んでない。 defoverridable で提供されているらしい?めも) Recursion http://elixir-lang.org/getting-started/recursion.html 再起でforを実現するのは関数型っぽくて頭になじまないと厳しそう。ただ、ここら辺は大学とか含めて数学的な素養を学んだ人からすると、慣れるまでに時間もかからなさそう。数列の世界の話みたいなものですしね。 Enum のライブラリにいくつかあらかじめライブラリが用意されているので、それは便利。ちょうど次の章で説明されていた。 http://elixir-lang.org/getting-started/enumerables-and-streams.html EnumとStreamを比較しながら話が進んでいて、StreamはLazyというところが違うと書いていた。 Enumは常にEnumの実際の値を返すけれど、Streamは必要なときに実際の値を返すがそれまではStreamとして保持している、と。 Pipeoperatorの対比を見ればおおー、なるほどという感じだった。 Pipeoperatorのときは基本Stream使っていって、lazinessが必要な大きなデータを扱うようなときとかコレクションを使ったりするときはEnumを使っておけば良い、という感じかな。 チュートリアルでの最後の締めは以下。 The amount of functions and functionality in Enum and Stream modules can be daunting at first but you will get familiar with them case by…More

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