[Elixir in Action]No technology is a silver bullet.

ここ最近、ざっとGetting startedやらexercism.io、PhoenixとElixirやその周辺ライブラリを触って、ちょっとしたライブラリも作って。Phoenix使って簡単なWebアプリ作って、というところをしました。 そんな折、Elixir in Actionを読み始めました。他のElixirの本も読もうと思うのですが、Actionシリーズなのでまずはこちらから読んでみようかな、と思いまして。 この書籍は言語自体の話から、Elixirのプラットフォームの話へと進んでいきます。多分、他の書籍も同じ。ただ、この書籍の著者はErlangを専門とする人のようで、RubyからElixirに寄った人たちとは異なった視点からの意見を望めます。良いですね。 Erlang Erlangの話から。Erlangはfault tolerance、Scalability、Distribution、Responsiveness、Live updateを重視した、高い可用性(high availability)を目指した言語です。それらを実現するための核が、concurrency。BEAM VM上に存在するプロセスとプロセス間通信を構築するなどでconcurrencyを核に添えた開発環境を構築できる、と。 WhatsAppsなんかはかなり有名ですね。私もErlangは少し触れたことがあります。ただ、言語の記述には慣れなかった… Elixir Elixirは、Erlangの記述を単純化したり、拡張することで描き易くしたものです。一言でいうとそんな感じなのですが、そこは開発者を取り込むために必要なものです。ClojurやRubyに影響を受けているので、そちら方面の人は馴染みやすそう。 No technology is a silver bullet. ErlangやElixirにも苦手なところがあります。この書籍では、その点も書いていて良かったです。 Speed: CやC++にはかないません。BEAM VMは、ハードウェア資源をめいいっぱい使うので、貧弱なハードウェアだと性能劣化が発生します。これは多くのプロセスを立ち上げ、処理を行っていくという特徴を持つから。なので、CPUの拘束が長い処理を行う場合、別の言語を選んだほうが良いでしょう。 Ecosystem: 単純に、まだ、エコシステムとしては小さい。 まだまだ先は長いですが、ちょっとづつ読んでいこう。 こういうfault toleranceなシステムや分散システムを前提としたシステムのテスト、品質(Quality)をどうやって評価するか、それをどうやって安定した開発に繋げることができるか？といったところ、テストエンジニアとして技術的な視点では非常に挑戦的で面白さを感じますね。 ただ、それらの先にユーザがいなければ自己満足な世界で終わるのでそこは忘れてはダメですね。More

『Katachi』を読んだ

代官山の蔦屋書店にて、ふと見つけてついつい購入。『Katachi』を読みました。 この本は、紙、木、竹、織、土、鉄、石といったテーマ別に写真を介してKatachiを表現したものでした。最後の付録として、各写真に関して簡単な解説も加えられています。 また、この書籍の面白いところは英語の解説も付いているところ。最後のページ付近に、英語でClassic Japanese Designとして写真、Katachiなどを説明、紹介しています。 花札の写真に「任天堂」という漢字を見つけて、任天堂が花札からはじまったのだなーと気づかされたり、叔父らが使っていた道具とか載ってて面白かったです。More

[Elixir]Guardianでログインを固める on Phoenix

ちょっとしたWebサイトを作ろうとして、Elixirを最近触っていることもあってElixir x Phoenixで構築し始めている最近です。 その中で簡単なログイン機能を追加しようとしたところ、awesome-elixirにてGuardianなる開発途中の認証ライブラリを見つけました。開発者はRack Authenticationのwardenの開発者でもあるのですね。ほー。 試したのは、v0.5.0 Readmeを見ながら作業かなーと思っていたのですが、サンプル実装を公開していることを知り、まずはそこから動かしてみることにしました。 ただ、動かしてみるとPhoenixが0.13.1ベース。 私が今使っているのは0.15.0ベース。 …. ということで、サンプルをPhoenix 0.13.1ベースから0.15.0ベースに書き換えました。開発者の方へPRも投げたので、もしかするとマージされるかも。 変更ブランチはこちら https://github.com/KazuCocoa/phoenix_guardian/tree/upgrade_to_phoenix_015 差分はこちら https://github.com/KazuCocoa/phoenix_guardian/commit/c5bf0edf1fd64ecbf7d16ac0a45fb4f2fd10be6b 上記をcloneして以下の通りに実行すれば、Phoenix 0.15.0上でアプリを起動、ログイン試したり諸々できます。 主な修正はPhoenixの0.13.1=>0.14.0へのアップグレードガイド、0.14.0=>0.15.0へのアップグレードガイドをみるとわかるのですが、この例のChannelで使うSocket周りに破壊的な変更が入っているのと、controllerで :plug action を呼ぶ必要がなくなっているところです。 なんだかんだでこうやって簡単な例からコード追うと理解が進んで良いですね。 session管理の箇所とか、色々参考になりました。 作者が簡単な説明をこことかで説明しているので、そこをまず読んでみると良いかもしれません。あと、サンプル実装は mix phoenix.new で生成されたアプリをそのまま使っているので、差分をコードリーディングすると良さそう。 ちなみに、このサンプルアプリ、以下のようにsession情報を見ながら動作をみることができるので理解の助けになりそうです。 Rubyを継承してか？Elixir、なんかゲームみたいなライブラリ名が結構ありますね。More

『多数決を疑う――社会的選択理論とは何か』を読んだ~ 分散システムにおける多数決 ~

多数決を疑う――社会的選択理論とは何かを読みました。 読んだ背景としては、教授が私の修士時代の修論の題材に関係していると教えてくれたから、でした。時期でいうと、4、5年前くらいの話ですね。 私が修士の時代、研究として分散コンピューティング環境化において、多数決がどれほど有効なのかの数学的な証明を行っていました。 想定した環境としては、ビザンチン障害。わかる人にはかなり有名な障害条件ですね。 ざっくりというと、分散コンピューティングを構成する計算機の集合において、自身以外が正しく動作しているか保証がない状態において、それらの集合全体として正しい計算結果を出すにはどのような条件が必要なのか？という問いです。 私は障害(正しく動作しない状態)が確率的に発生すると仮定し、その中で”正しく動作する”計算機が一定数以上あった場合、それらの集合は正しく動作することができるという命題を証明していました。その”一定数”とはどういう条件なのか？というものを。 人の経験則的に、多数決が1つの重要な要素として考えられていましたが、その多数決を基本としてどのくらい”正しく動作する”計算機が存在すれば、この命題を満足できるか？を証明していました。（証明したのですが、それは修論の発表以上いってないのですよね…5年たった今でも、出すべきというお声をかけていただきますが…） その内容が、数学的な厳密な定義ではないにせよ書かれていたのがこの書籍です。ただ、この書籍が私の過去の論文に少しアドバイスを与えてくれました。少し修正してまた出そうかな… 多数決ではどのような条件の基に”多数と判断するか”という集約ルールが重要な要素です。そのルールを、コンドルセ・ヤングの最尤法、ボルダルール、(単純な)多数決、決選投票付き多数決と歴史的に研究されてきた幾つかの例を基に説明し、何が投票者の多数の意見を反映しているか？を反例を交えながら説明していました。 人は3択以上ある選択肢を多数決でちゃんと答えを出すことができないことは政治/経済界隈では有名な話です。主にはその話ですね。 いくつか述べたあと、確率的な仮定を交えて 64%多数決ルール を説明しています。これは、選挙を例に多数決で可決/否決を決めるとき、確率的な要素を踏まえた上で全体の63.2%を超えるだけ集めた意見が勝つ、という多数決のルールです。 私の修論ベースでいうと、分散システムのうち、63.2%を超える計算機が正しく動作するのであれば、残るシステムは正しく動作しなくてもシステム全体として正しく動作することができることを意味します。(すべて確率的に失敗する、という前提のもとです。実際は色々制約もあると思いますが。) ※私の証明がこの通りというわけではないです。仮定もことなるので、色々ことなる点もあります。 この書籍自体は何かの解を求めているのではなく、『多数決を疑うこと』に焦点を当てて論述を展開しているので、伝えたいことも『多数決を疑え』ということでした。 多数決と多様性は社会システムとして重要な、研究が進んでいる分野ですが、これはコンピュータの構成する分散システム環境において同様のモデリングが可能です。ここらへんの理論がここ最近、論理だけではなく実践/計測まで進んでいるので、もう少し経てば 確率的な失敗を前提とした、それでも正しく動作するような分散システム ができるかもしれませんね。それは人工知能でも十分に使えそうな理論な気がします。More

[Elixir]パターンマッチやcase文でのwhenにおけるguard clauses

Elixirの記述に慣れるため、exercism.ioで簡単な問題を解きながら時間の合間に遊んでいます。 そこで少しエラーを何回も出してしまったのでメモ。 以下の通り、Elixirではguard clausesの中におけるbooleanの式ではand or not を使う必要があるみたいですね。 Note that while boolean operators such as and, or, not are allowed in guards, the more general and short-circuiting operators &&, || and ! are not. from: http://elixir-lang.org/getting-started/case-cond-and-if.html 他言語だとビット演算云々で私は || とか && を使うことに慣れていたのでつまづいてしまった… あと、同じように以下の[ここ]と書いている箇所。判定を読みやすくするために独自の関数を作ってみたのですが、guard clausesの中ではそのような独自な関数はちゃんとマクロ組んで作らないといけないのですね。 あらかじめこのwhenの中で使える関数が用意されていますが、それを超えるものはマクロ組んでいく必要があるみたい。ただ、それは可読性を損なう恐れのあるものなので、個人的には case example do のexampleをうまいこと表現したいですねー。 もう1個。以下のようなcaseを使った関数、パターンマッチを組み合わせた関数でも記述することができます。 case文 パターンマッチ whenの中に記述できる処理式には限りがあるので、複雑な分類であれば case を使うほうがよさそうですが、簡単な when で区分できる場合、関数自体を分けたほうが責務が明確になってよさそう。…More

『エクストリームプログラミング』を読んだ

『エクストリームプログラミング』を読みました。 電子書籍で購入したでのすが、結果的には紙の書籍でも買って残しておきたい、と感じました。 XPにおける開発にあたり必要となる価値観や原則、プラクティスがまとまっている本になります。XPというよりは、この価値観、原則、プラクティスを通じてより良い(ハッピーな)開発をするにあたり頭に入れておくべき規範な位置付け、と感じます。 価値観や原則はもとより、プラクティスの一部を実際に取り組んだりしていますが、このように目指すべき理想が言語化されているところはすごく価値あるものだと思います。 個人的に、第25章の結論に書かれている、 XPの鍵は誠実性(integrity)だ。 というところが印象に残っています。 ソフトウェア開発は、様々な過去の論文からも人に依存するところが強いです。そのため、信頼関係を築くことは大事で、それらを多様な中で維持するには、integrityが必要だと思っていました。それが裏付けされた、という意味においても、非常に印象的でした。 でも、実際に誠実であるって容易ではないですよね。でも、楽しそう。More

[Elixir]パターンマッチにおけるpin演算子

個人的なメモです。 Elixirでの、pin演算子の意義として以下の返答をもらいました。 確かに、個人的に明示的にパターンマッチと知らせるために ^x = 1 のように書かせることに利点があるという言語設計、納得。More

[Elixir][Phoenix]has_oneやbelongs_toの関係にあるモデルを、他方のモデル生成時に合わせて生成する

has_one や belongs_to の関係になっているDeviceとUserのモデルを考えた時に、Device作成時にUserモデルも新規に作成したい時の話。 このメソッドは対象は、Phoenixのcreateリクエストを元にしています。 Rep.transaction とその中で依存性を持つ複数のDB処理を一括で書いています。 has_one や belongs_to の関係を持っているので、一方の _id に、もう一方の id を与える必要がある、ところがポイント。 もっとちゃんとした書き方あるのかな。ありそうな気がする。。。 この関係が正しくできているかは、controllerレベルでは以下のように適当なユーザを生成して、その上でindexなどが表示できることを確認すればOK。 この時、index.htmlでは device.user.user_name のような、has_oneの関係にある要素を描画しようとしていることが必要ですが。 Railsに似ているので、Railsも参考にしながら書いてみているけれど、DB周りの扱いがだいぶ想像できるようになってきた感じ。 まだ公開していないけれど、練習用repositoryはこちらMore

Android Test KitのEspressoなどのバージョンがあがってたのでざっと調べた

ちょっと追えていなかったのですがEspresso関連のライブラリが2.1が2015年4月21日に、2.2が2015年5月28日にリリースされたのですね。 ちょっと順に追ってみます。 android-test-kit release note 内容としては、2.0=>2.1では破壊的な変更が発生したので移行時には注意しましょう、でしょうか。ただ、 ActivityInstrumentationTestCase2 を脱却して、 @Rule ベースでアクティビティの起動/終了が管理されるようになったので、個人的には移行をためらう理由もなく、という感じですね。 そのほか、intentなんかも含め、JUnit4らしく？Ruleベースのテストの周辺環境記述に移り変わってきた感じがします。 from 2.0 to 2.1 com.android.support.test:testing-support-lib:0.1 が com.android.support.test:runner:0.2 と com.android.support.test:rules:0.2 に分割された Gradleプロジェクトを書き換えると思うのですが、書き換えた後はGradleのキャッシュを飛ばしてあげましょう。依存関係に不整合が生じるときがあります。 espressoに以下の新機能が追加されました espresso-intents ActivityTestRule を拡張した IntentsTestRule として、functional UI Testとしてインテントを使えるルールが提供されるようになったらしい espresso-core ViewActions なんかの機能追加 CheatSheetも更新されてました rules ActivityTestRule が追加されたことで、 single activityのテストを実施するときにわざわざ ActivityInstrumentationTestCase2 を継承する必要がなくなりました UiThreadRuleやUiThreadTest、ServiceTestRuleのRuleが追加されたので、これもRuleベースでテストをかけそう いい感じですね!! UIAutomator UiDevice#dumpWindowHierarchy() の機能追加 コード書き換え ActivityTestRuleが追加されたことで、いままで致し方なく継承していた ActivityInstrumentationTestCase2 から脱却します。 ActivityInstrumentationTestCase2 ベース ActivityTestRule ベース 大分すっきりしました。Activityの起動と破棄が…More