0.　はじめに 18年10月にKotlinのコルーチンがexperimentalからstableになりました。 遅ればせながら、コルーチンを触ってみました。 この記事は、これからコルーチンを学習する人向けの記事です。 ＊Kotlin1.3、 kotlinx-coroutines1.0.1の環境です。 ＊Kotlinが初めての方は、 こちら で気軽に試せるので触ってみてください。先頭に import kotlinx.coroutines.* を忘れずに。 1.　コルーチンとは Wikipedia から引用します。 コルーチン（英: co-routine）とはプログラミングの構造の一種。サブルーチンがエントリーからリターンまでを一つの処理単位とするのに対し、コルーチンはいったん処理を中断した後、続きから処理を再開できる。 どういうことなのか。簡単なプログラムを例にして説明をします。 fun main() { /* ここからコルーチン */ println( "start foo" ) 時間のかかる処理 println( "end foo" ) /* ここまでコルーチン */ println( "bar" ) } 例えば"start foo"から"end foo"をコルーチンとして実行することで、時間のかかる処理のタイミングでmainスレッドがその処理を中断し、中断中は別の処理をすることができます。 ここでは、中断中は"bar"を表示させることにします。 よって、出力結果をこのようなります。 start foo bar end foo 2.初めてのコルーチン それでは実際にコルーチンを作成して、スレッドが中断して再開するところをみてみます。 作成するプログラムは、 1.コルーチンとは のプログラムに、コルーチンを適用します。説明通りの結果になるか確認します。 コルーチンを作成するにはコルーチンビルダーというものを使います。 コルーチンビルダーには様々ありますが、ここではもっともシンプルな launch関数 を使います。 使い方は簡単です。 launch関数 にコルーチンとして実行するラムダを渡します。 fun main() { GlobalScope.launch { println( "start foo" ) delay( 1000 ) println( "end foo" ) } println( "bar" ) } これで"start foo"から"end foo"まではコルーチンとして実行されます。 なお、 GlobalScope と delay関数 はあとで説明します。 delay関数 は Thread.sleepメソッド のようなものだと現時点では思っておいてください。 「時間のかかる処理」を delay関数 で代替しています。引数として中断したい時間をミリ秒単位で指定できます。 結果はこのようになります。("start foo"が表示されないこともあります。) bar start foo 想定した出力結果になりませんでした。 まず、"bar"が先に表示されてしまいました。 これは launch関数 がコルーチンの実行をスケジュール化だけして、処理を先に進めてしまうからです。 また、"end foo"が表示されませんでした。原因は、"end foo"から処理を再開をする前にmain関数からリターンして、プログラム自体が終了してしまうからです。 launch関数 では、mainスレッドの実行を止めることできないので、何か工夫が必要です。 launch関数 の代わりに runBlocking関数 というコルーチンビルダーを使うことにします。 runBlocking関数 は、コルーチンが完了するまで呼び出し出し元のスレッドを停止させるコルーチンビルダーです。 fun main() { runBlocking { println( "start foo" ) delay( 1000 ) println( "end foo" ) } println( "bar" ) } 当然ですが、これでも期待した出力結果にはなりません。 start foo end foo bar なぜなら runBlocking関数 をコールした時点で、コルーチンの処理が終わるまで呼び出し元のスレッドがブロックされるからです。（出力結果として想定したものではありませんが、 delay関数 のポイントで中断および再開はしています。) それでは先の launch関数 と組み合わせたらどうなるでしょうか。 fun main() { runBlocking { launch { println( "start foo" ) delay( 1000 ) println( "end foo" ) } delay( 500 ) println( "bar" ) } } 先述したように launch関数 はコルーチンの実行をスケジュール化して処理を先に進めてしまうので、"start foo"が表示される前に"bar"が表示されてしまいます。 これを防ぐために"bar"の直前に delay(500) を置きます。 （前回と違い、 launch関数 を呼び出す際に GlobalScope がない理由はあとで説明します。) 結果はこのようになりました。 start foo bar end foo 想定した出力結果になりました。 どのスレッドで各々が実行されているか調べてみましょう。 また、少しだけKotlinっぽく書いてみます。 fun main() = runBlocking { launch { println( " $threadName :start foo" ) delay( 1000 ) println( " $threadName :end foo" ) } delay( 500 ) println( " $threadName :bar" ) } val threadName: String get () = Thread.currentThread().name main:start foo main:bar main:end foo 中断する前の処理、中断中の処理、中断から再開した処理、全てmainスレッドで実行されていることが確認できました。 なお、このプログラムは２回中断が発生しています。 launch コルーチンのスケジュール化　→　 delay(500) で中断(1回目)　→　 launch の実行開始 → delay(1000) で中断(2回目) → delay(500) から再開 → delay(1000) から再開 3.中断はいつ発生するのか コルーチンの実行が中断され、そして再開される様子を見ることができましたが、中断とはどういう時に発生するのでしょうか。 ドキュメントに このような 記載があります。 Suspending functions can be used inside coroutines just like regular functions, but their additional feature is that they can, in turn, use other suspending functions, like delay in this example, to suspend execution of a coroutine. サスペンド 関数は、コルーチンの中で通常の関数のように使えます。通常の関数との違いは、 サスペンド 関数はコルーチンの実行を中断するために、他の サスペンド 関数を使うことです。(この例のdelayのように) サスペンド 関数という新しい用語が出てきました。 サスペンド 関数とはこのように関数の先頭に susupend修飾子 がついた関数のことです。 suspend fun hoge() このドキュメントによると サスペンド 関数をコールすることで中断が発生するようです。 確かに delay関数 の定義にもこのように suspend修飾子 がついています。 public suspend fun delay(timeMillis: Long ) それでは、 delay関数 のように中断を起こす サスペンド 関数を作成してみましょう。 せっかくなので、中断から再開するときに値を返す サスペンド 関数を作成してみます。 今回は4096bitで表現可能な 素数 を返す getPrimeNumber関数 を作成します。 getPrimeNumber関数 の利用側はこのようにします。 fun main() = runBlocking { println( " $threadName :start runBlocking" ) launch { println( " $threadName :start launch" ) val prime = getPrimeNumber() println( " $threadName :prime number = $prime " ) println( " $threadName :end launch" ) } delay( 500 ) println( " $threadName :end runBlocking" ) } 大体の流れは、 getPrimeNumber関数 をコールしたらmainスレッドはコルーチンを中断　→　その間に"end Blocking"を表示　→　 素数 が求め終わったら、 素数 を表示させるところから再開 です。 次に、 サスペンド 関数である getPrimeNumber関数 はどう作成すればいいのでしょうか。 まずは、 素数 を求めるコードを書く必要がありますが、 BigInterger.probablePrime という 素数 を求めるのに便利なメソッドがあります。 このメソッドの詳しい使い方は割愛しますが、 BigInterger.probablePrime(4096, Random()) が 素数 （正確には「おそらく 素数 」）を返してくれます。私の手元のマシンでは呼び出してから返ってくるまでに10秒程度かかりました。 次に実際に中断を起こすコードを書いていきます。 suspend fun getPrimeNumber() = BigInterger.probablePrime( 4096 , Random()) このように書ければシンプルですが、このようにしても getPrimeNumber関数 で中断されず、mainスレッドが 素数 を求めるために停止してしまいます。 スレッドを中断させるには suspendCoroutine関数 をコールする必要があります。 suspendCroutine関数 はこのように定義されています。この関数も サスペンド 関数です。 inline suspend fun suspendCoroutine( crossinline block: (Continuation) -> Unit ): T ラムダが受け取る Continuationインターフェース にはこのような拡張関数が定義されています。 fun Continuation.resume(value: T) この resumeメソッド をコールすることで、コルーチンが再開します。 それでは中断はいつ発生するのでしょうか。 あえて、 resumeメソッド をコールせず、このようにして実行してみてください。 suspend fun getPrimeNumber() { println( " $threadName :hoge" ) suspendCoroutine { println( " $threadName :fuga" ) } println( " $threadName :piyo" ) } 結果はこのようになります。 main:start runBlocking main:start launch main:hoge main:fuga main:end runBlocking また、このプログラムは永遠に終了しません。なぜなら、コルーチンが再開しないためです。 この結果をみると、"fuga"の後に"end ranBlocking"が表示されているので、"fuga"を表示後、つまり suspendCoroutine関数 に渡したラムダの実行終了後に中断が発生している ことがわかります。 これが中断が発生するタイミングです。 今度は、中断が発生後、約１秒経過してから resumeメソッド をコールして再開してみます。 suspend fun getPrimeNumber() { println( " $threadName :hoge" ) suspendCoroutine { cont -> println( " $threadName :fuga" ) Thread { Thread.sleep( 1000 ) cont.resume( 1234 ) }.start() } println( " $threadName :piyo" ) } 中断から再開しました。 main:start runBlocking main:start launch main:hoge main:fuga main:end runBlocking main:piyo main:prime number = kotlin. Unit main:end launch また、 getPrimeNumber関数 は 素数 を返さないので kotlin.Unit と表示されてしまっています。 それでは getPrimeNumber関数 が 素数 を返すように変更します。 resumeメソッド に渡した値が suspendCoroutine関数 の戻り値になるので、このように書けます。 suspend fun getPrimeNumber(): BigInteger = suspendCoroutine { cont -> Thread { cont.resume(BigInteger.probablePrime( 4096 , Random())) }.start() } これで、先ほどの結果で kotlin.Unit となっていた箇所に 素数 が表示されます。 目的である中断の発生タイミングについて、確認できました。 4.コルーチンビルダーについて少し詳しく これまでで、 launch関数 や runBlocking関数 の２つのコルーチンビルダーを使いました。 この２つ以外にも様々なコルーチンビルダーが提供されています。 例えば、先ほど 素数 を求めるために作成した getPrimeNumber関数 ですが、 withContext関数 というコルーチンビルダーを使うとこのように書けます。 suspend fun getPrimeNumber() = withContext(Dispatchers.Default) { BigInteger.probablePrime( 4096 , Random()) } このコルーチンビルダーは値を返すことができます。 また、第一引数に値を指定することで、コルーチンを実行するスレッドを切り替えています。 実用的なコルーチンビルダーは他にもありますが、この記事ではそれらを紹介しません。 ここでは、この記事でまだ触れていない重要な２つの内容について説明します。 コルーチンビルダーは、中断可能な世界へのエントリーポイントのようなもの コルーチンスコープが必要なコルーチンビルダー 中断可能な世界へのエントリーポイント まずは１つ目です。 サスペンド 関数として getPrimeNumber関数 を作成し、コールすることでコルーチンが中断されることを見ましたが、このようなコードは コンパイル エラーになります。 fun main() { val primeNumber = getPrimeNumber() } 理由は、 サスペンド 関数は サスペンド 関数もしくは サスペンド ラムダ からし かコールできない というルールがあるからです。 通常のラムダと サスペンド ラムダの違いは、関数と同様に suspend修飾子 の有無です。 例えば、 launch関数 の定義はこのようになっています。 fun CoroutineScope.launch( context: CoroutineContext = EmptyCoroutineContext, start: CoroutineStart = CoroutineStart.DEFAULT, block: suspend CoroutineScope.() -> Unit ): Job (source) block の型をみると suspend修飾子 がついているのがわかります。これは サスペンド ラムダを受け取ることを表しています。 このように コルーチンビルダーは サスペンド ラムダを受けることで中断可能な世界へのエントリーポイントを提供しています。 コルチーンスコープ 次に２つ目のコルチーンスコープについて。 launch関数 の定義を見ていただくと、 launch関数 は CoroutineScopeインターフェース の拡張関数として定義されているのがわかります。 fun CoroutineScope.launch(..) よって、 launch関数 をコールするには CoroutineScope の インスタンス が必要です。 最初の方のコードで GlobalScope.launch と書いていたのはそのためです。 GlobalScope は CoroutineScopeインターフェース を実装した インスタンス です。 object GlobalScope : CoroutineScope launch関数 をコールするには CoroutineScope の インスタンス が必要ですが、 runBlocking関数 に渡すラムダ内では GlobalScope.launch{..} ではなく、シンプルに launch{..} と書けます。 この理由は runBlocking関数 の定義をみるとわかります。 fun runBlocking( context: CoroutineContext = EmptyCoroutineContext, block: suspend CoroutineScope.() -> T ): T (source) block のレシーバの型は CoroutineScope となっています。 これが理由で、 runBlocking関数 に渡すラムダ内では、 GlobalScope.launch と書く必要がなかったのです。 レシーバ付きラムダに馴染みがない方のために、少し補足します。 あえて this を使って書くとこのようになります。 runBlocking { this .launch {..} } この this は、runBlocking関数が作成した CoroutineScope の インスタンス を参照しています。 補足 コルーチンスコープが導入されたのはkotlinx-coroutines0.26.0からです。 0.26.0がマークされたのが18年9月です。0.26.0より古いバージョンを前提に書かれた記事では GlobalSope がないコードを見ることがあるかもしれません。 // 0.26.0より前 fun main() { launch {..} } // 0.26.0以降 fun main() { GlobalScope.launch {..} } 5.終わりに 予定では CoroutineScope 、 CoroutineContext 、 Job についても書くつもりでしたが、記事が長くなってしまったので、全く触れられませんでした。 コルーチンを使った実用的なコードも同様です。 コルーチンを勉強をしている身ではありますが、何かの機会があれば、それらについても書いてみたいと思います。 この記事が、これからコルーチンを初める方に少しでも役に立てば幸いです。

こんにちは、Enigmo 新卒エンジニアの @sean0628_i です。 Enigmo Advent Calendar 2018 8日目の記事です。 ちなみに、 Enigmo は、海外通販サイト BUYMA や、世界中のトレンドをお届けするファッションメディア STYLE HAUS を運営する会社です。 Enigmo では、 「社内ビール制度」 が存在し、定時の18:30以降 ビールが飲み放題 です。 毎晩定時後は宴会が繰り広げられて、、、ということはなく、日によっては金曜日ですらも人が疎ら、なんていうこともあります。。。 さてはEnigmo 社員はビールが嫌いなのか？とも思いましたが、実際に話を聞いてみると当然そんなことはありませんでした（安心 実際の声 みんなで楽しくビール飲みたいけど、みんな忙しそうだし。。。 声を掛けるのは気が引ける。。。 社員Tさん さらに時々こんな声も、 呑んでたなら教えてよ。。。言ってくれれば参加したのに。。。 社員Yさん ニーズはあるのに、多数障壁があるようです これは、 「社内ビール制度」 始まって以来の危機だと思い、新卒エンジニアは立ち上がりました。 そうだ、 Amazon Dash Button を使ってこの危機を乗り越えよう。 内容 Amazon Dash Button （以下、Button）とは？ Buttonの仕組み # DHCP # ARP request/responce # MAC address Hackの流れ 気づき・学び 今後の展望 Amazon Dash Button とは？ Amazon ダッシュ ボタンは、注文商品を簡単かつ迅速に作成できるように設計された小型の電子デ バイス である。 出典: Wikipedia - Amazon Dash 一般的な利用方法 Amazon 公式アプリに Wi-FI & Bluetooth 経由で連動させる アプリ上でButton に登録したい商品を選択 Step2 で設定した商品がほしくなったらButton を押す 数日後、商品が手元に届く Button の仕組み Buttonの押下により、電源オン アプリで設定しておいた、 Wi-Fi に接続 DHCP でIPを取得 商品注文リク エス ト とここで文系新卒の私は DHCP とはなんぞやと思ったわけです。。。 で、調べました。 利用技術 DHCP とは？ コンピューターに IPアドレス を自動割り当てする仕組み IPアドレス は、いわゆる住所のようなもの (IPは 8.8.8.8 こんな感じの数字のやつ) と、 DHCP はなんとなく理解したものの、次なる敵が現れました。 MAC address 、 ARP です。。。 もう横文字嫌だー、と思いながらも開発に必要なため背に腹は代えられず調べました。 MAC address とは？ 識別に利用される原則一意の 物理アドレス ARP とは？ IP から MAC を調べる仕組み のことらしい。。。 出典: What is ARP and ARP spoofing? Hack の流れ ARP を利用し、Buttonの MACアドレス を取得* Buttonの MACアドレス を監視 Buttonからの ARP Requestをキャッチ 任意の処理をする（今回はSlackにmessageを投下） *: 初回のみ。実際Buttonが押されてからの流れは2~3 実際の実装 長くなるので割愛します。 ソースコード (Sean0628/dash_button): https://github.com/Sean0628/dash_button テスト運用 ↓こんな感じ :tada: *: リゾート とは、Enigmo 社員の憩いの場所 気づき・学び 普段業務では主に Ruby を使っていて、node を初めて使いました。 しかし、やってみると意外に簡単。メンタルブロックをいかに外すかが大切なのだと感じました。 業務では関わることのできないネットワークの分野も面白いなぁと思いました。 機会があれば深掘りしてみたいなぁと。 今後の展望 勉強も兼ねて不要なPCに CentOS を入れて、 CentOS をサーバにしてButton を活用したいと思っています。 まだ、本格的なリリースまでは行けてないので、早く始動させてみんなで楽しくビールを飲みたいと思います。 最後まで読んでいただきありがとうございます。 参考: Dash Buttonの設定を管理する 参考: Enabling Interactions with Bots

Enigmo Advent Calendar 2018 の７日目の記事です。 概要 Enigmo の Steven です。 プログラミング言語 に対して興味を持ってますので、今日は Ruby について話したいと思います。 Ruby は オブジェクト指向 だと言ったら、反対する人は多分いないと思いますが、 関数型言語 の特徴も持ってると言ったら、ピンとこない人はそれほど少なくはないかと思います。 それでも、 Ruby プログラマー でしたら、 関数型言語 から受け継がれたそういう機能はおそらく毎日使っています。 そういう機能がなかったら、 Ruby は世界中で使われてる現在の言語にならなかったかもしれません。 この記事ではその機能を説明して、 Ruby の理解と 関数型言語 に関する知識が少し深まる機会になれればと思います。 Ruby の特徴について Wikipedia によると、 Ruby は 10個以上の プログラミング言語 から影響を受けて作られました。 その中には Python 、 C++ 、 Smalltalk などの オブジェクト指向 プログラミング言語 は複数ありますが、その中には Lisp もあります。 Lisp というのは現在、一つの言語というより、言語のファミリーですが、そのファミリーの言語は特徴的な文法を用いてることで有名でしょう。 ただし、 Ruby では括弧は Lisp と比べて極めて少ないですし、文法も全然違うので、最初は関係を疑うかと思いますが、言語の根本的なところで Lisp の一部の特徴を確認できます。 Lisp から引き継がれたもの 条件式の場合、 Ruby の世界では nil と false は偽として解釈されます。それ以外の値はすべて真になります。 PHP などの言語と比べて、極めて簡単でわかりやすいルールですが、その特徴は Lisp からそのまま引き継がれました。 それに関しては Clojure （ jvm 上の Lisp ）は Ruby と全く一緒です。 Common Lisp では false という値はないですが、それ以外は一緒です。 もう一つの特徴としては、 Lisp と同じく Ruby には文はなく、すべては式です。 C などの言語では if文、関数の定義などは文であって、値として扱えないのですが、 Ruby ではどんなものも式であって、値として扱えます。 if then else end は該当のブランチの値を返しますし、多くの場合はそんなに役に立たないと思いますが、 def foo; end はメソッド名をシンボルとして返します。 以上は Lisp 由来の特徴の一部ですが、引き継がれたものの中で一番影響が大きかったのは、 関数型プログラミング だと言えます。 Ruby の関数の扱い どんな段階で特定の言語が 関数型言語 になるかというのは定かではなくて、判断しにくい時がありますが、 Ruby ではやはり オブジェクト指向 の面が一番強いので、 関数型言語 だと言えません。 ただし、 Ruby ではある程度 関数型プログラミング が可能だと主張しても、誤りではないでしょう。 Ruby で 関数型プログラミング ができるのは Ruby の関数の扱いのおかげです。 厳密に言うと、 Ruby には関数はなく、すべてはメソッドですが、説明がより簡潔になるよう、以下の説明では両方が同じだと一旦みなしてください。 第一級関数（first-class functions） 第一級関数を提供する言語では関数を単なる値として扱えます。他の関数に引数として渡すこともできれば、関数から返すのはもちろん、変数に保存することもできます。 Ruby では既存のメソッドを値として扱うにはまずメソッドを Method か Proc オブジェクトとして抽出する必要がありますが、それができれば、そのオブジェクトを他のオブジェクトと何の違いもなく自由に扱えます。 def add (a, b) a + b end def apply (fn, *args) fn.call(*args) end add = method( :add ) apply(add, 22 , 44 ) # => 66 無名関数（anonymous functions） 無名関数はその名前の通り、名前のない関数を表しています。それだけです。 名前を与える必要がなくなると、整数と文字列と同じく、関数はただの リテラル になります。 Ruby では proc や lambda で無名な関数オブジェクトをもちろん生成できますが、ブロックも無名関数の一種だと言えます。 my_proc = proc { puts 1 } my_lambda = lambda { puts 2 } def with_my_block yield 3 end with_my_block { | x | puts x } クロージャ （closures） 関数を値として使える言語では、 クロージャ は、関数の内側から、関数定義時に関数の外側にしか存在しなかった変数名（グローバル以外にも）を参照することを可能にします。 Ruby でも クロージャ のサポートを確認できます。 def foo (n) o = n * 2 lambda { | p | o + p } # o は lambda の引数から受けられず、foo のローカル変数を指しています end bar = foo( 10 ) bar.call( 5 ) # => 25 無名関数と クロージャ は時々一緒くたにされることがありますが、違うものです。 無名関数がないが、 クロージャ がある言語と、その逆の言語を想像できます。 高階関数 （higher-order functions） 高階関数 は以上のものと違って、機能ではなく関数の一種類の名前です。 高階関数 というのは、他の関数を引数として受けるか、関数を返り値として返すか、それともその両方を行う関数を表しています。 どちらかが欠けてると、多少不便になるので、以上で紹介した機能をベースに、 高階関数 を可能にする プログラミング言語 は多いです。 Ruby では 高階関数 は多いですが、一番始めに頭に浮かぶのは Enumerable のメソッドです。 multiplier = 5 # map という関数はブロックを関数として受け取ってます [ 1 , 2 , 3 ].map { | n | n * multiplier } # => [5, 10, 15] したがって、 Ruby でプログラミングをしているのであれば、おそらく毎日、ある程度の 関数型プログラミング をしているということになります。 関数型プログラミング のいいところ Enumerable のメソッドを好む人は Ruby プログラマー のほぼ全員だと思いますが、そのようなプログラミングがなぜいいのかをもっと具体的に説明しましょう。 関数を組み合わせることで量の少ないコードでもかなりな処理を行えます 高階関数 になると、再利用できる関数は多く、 アルゴリズム をそれぞれの関数の組み合わせとして実装できます 命令型プログラミングと オブジェクト指向 プログラミングと比べて、ステートを扱うことが少ないので、ステートによるバグがより少ない 特徴は他にありますが、まとめて言いますと、 関数型言語 では数学により近い形でプログラムを実装すると言えます。 関数型プログラミング 向けの gem Ruby で以上のように 関数型プログラミング ができますが、 Ruby はあくまでも オブジェクト指向 の言語なので、それなりの限界があります。 高階関数 をライブラリーに追加することは簡単ですが、 Haskell や OCaml のような 関数型言語 に近づかせるにはかなりの努力が要ります。 それも度を越えると、 Ruby が Ruby じゃなくなって、デメリットの方が大きくなることがあるかと思います。 それでも場合によってはほかの 関数型言語 にある機能を Ruby に持ってくるメリットがありますので、以下ではいくつかの機能とそれを提供する gem を紹介します。 永続データ構造 永続データ構造では既存の値を変更することは不可能で、もとの値から新しい値を生成することしかできません。 新しい値の生成時に既存のデータ構造と一部の構造が共有されるので、 Hash と Array などをまるごとコピーするより早いです。 一見では追加の制限しかかけられてないと見えますが、新しい値をしか生成できないというのは逆に保障でもあって、変更してはならないデータ構造を気づかずに変更してしまうというバグが完全になくなります。 並行計算ではスレッドの間でデータ交換を行う時に伴う心配もなくなるほか、たまに見かける #dup と #freeze のメソッド呼び出しも不要になります。 関数型言語 に限る機能ではなく、それぞれの オブジェクト指向言語 にも普及しつつある機能であって、 Ruby でもこれから String が完全にイミュータブルになることから見て、 Ruby では将来的にそのデータ構造が公式的に導入されるかもしれません。 Hamster パターンマッチング Ruby では値を比べるには == はもちろん、 case when end で使われる === もあります。 ただし、そのメソッドで値が同じであるかどうかを簡単に判断できても、データの一部だけ（いわゆるデータのパターン）を簡単に比べるのはもっと難しいです。 その問題を解決するため、データの比較をより汎用的に行えるように、パターンマッチングという機能が存在します。 パターンマッチングでは、比較したいパターンを定義することで、データがパターンにマッチした場合、もしくはマッチしなかった場合の処理を指定できます。 パターンがいくら複雑でも定義可能なので、複雑なデータ構造の比較時に特に役に立ちます。 例のパターンとして以下のはどうでしょうか？ 値が配列で、最初の要素がハッシュである必要があるが、ほかの要素は気にしません ハッシュに :foo と :bar のキーが必須ですが、追加で他のキーがあって問題にしません :foo に対する値は 10 の整数である必要があります Ruby でパターンマッチングを可能にする gem の中には以下のがあります。 pattern-match Qo モナド Array に対して使える #map と #flat_map メソッドは人気でしょう。 ただし、 Array での使い方が言語を問わず一番普及しているとはいえ、 #map と #flat_map は配列限定のメソッドではありません。 #map はコレクションの各要素に対して任意な関数を適用して、その結果をもとの要素に置き換える処理を行います。 Array の場合、ここでいうコレクションは配列ですが、 #map を提供できるコレクションは他にもいろいろあります。 配列は 0 以上の要素を含むとして、 Maybe は 0 か一つの要素を含むコレクションです。 フューチャーでしたら、将来的に一つの要素を含むことになりますが、現在はまだないかもしれません。 全然違うものに見えるかもしれませんが、以上のものはすべて要素を含むコレクションとして一緒です。 そのコレクションでも #map は含まれてる要素に対して任意の関数を適用する処理を行うことになります。 #flat_map はコレクションの各要素に、その要素を引数にしながら、同じ種類のコレクションを返す関数を、適用する処理を行います。 関数から返された各コレクションを、コレクションの種類によって、連結したり、そのまま返したりします。 #flat_map と一緒に使われる時、最終的の結果を変更しない関数も使用可能な場合は（以下は #pure と呼ぶ）、 #map は #pure と #flat_map だけを使って実装可能です（配列の場合は pure = ->(x) { [x] } ）。 #pure と #flat_map を提供するデータタイプ（コレクション）は モナド と呼ばれています。 #map と #flat_map のいいところの中には以下のがあります。 高階関数 なので、再利用性は高いですが、その中でも #map と #flat_map はかなり根本的な関数なので、それをベースに、何のコレクションにも対応する関数を、実装できます。 #map と #flat_map は通常の実装で全域 写像 （total function）なので、渡された関数も全域 写像 であれば、どんなコレクションに対して適用されても、エラーになりません（ Maybe のコレクションで #map と #flat_map を使えば、 nil のチェックは完全に不要になります）。 モナド を本格的に使うには協力な型を提供する静的型付けな言語が大体必要になりますが（ Haskell など）、簡単な ユースケース なら、 Ruby でも以下のライブラリーなどで モナド を使えます。 Kleisli dry-monads 言語とライブラリーによって #map と #flat_map は違う名前になったりします。他によく使われる名前としては fmap（map）と bind（ flat _map）はあります。 終わりに プログラミング言語 の世界では、最近の一つの流れとして、今まで 関数型言語 にしかなかった機能が少しずつ他の言語でも採用されるようになってます。 Ruby ではかなり以前から 高階関数 を使えますが、もっと最近な例として Java 8 があります。新しい言語なら、Swift と Rust もあります。 当分はその流れはおそらく止まらないので、これからも 関数型プログラミング の機能がどんどん普及して、もしかすると Ruby の方にも新しい機能が現れるかもしれません。 そうなれば、今以上にも Ruby で 関数型プログラミング のいいところを活かせるのでしょう。

エニグモ データ活用推進室 @kmt47 です。 この記事は Enigmo Advent Calendar 2018の6日目 です。 概要 redashがv4にバージョンしました。 redash v4の新機能を紹介します。 上手に新機能を使って、redash作成を効率化していきましょう！ クエリ（レポート（表、グラフ）） 数値の表示形式（フォーマット）をredashで設定できるようになった（便利度：★★★★★（MAX）） これまでは、 SQL で行っていた（面倒な）表示形式の変換を、redashの設定で可能となりました。 これまでは、文字列変換(CONVERT)や、文字置換(REPLACE)を駆使して金額の12,000.00の「.00」の除去や、 YoYなどにパーセンテージ(%)の付加を行って表示形式を整形していましたが、v4ではredashの設定で可能です。 手順 ・「Table」画面の左下にある「Edit Visualization」をクリック 　 ※　自分が編集できる（自分が作ったor編集権限のある）クエリの場合に「Edit Visualization」が表示されます。 　⇒　「Visualization Editor」が表示されます ・表示形式を変更したい項目の「Number format」を変更（数値項目のデフォルト値は「0,0.00」） 「0.0」に変更することで、小数点以下が除去され「12,000」のように表示されます。 ※　表示形式を変えると、右側の表示の形式も瞬時に変更されますので、確認ができます。 YoYのようなパーセントの項目の場合は、「0.0%」に変えることで、「123.4%」のように表示されます。 ※　パーセンテージの場合の元の値は、100を掛ける必要はない（100掛けちゃダメ） 表示形式は、以下のURLを参照してください。 http://numeraljs.com/ 項目を非表示にできるようになった（便利度：★★★★） v4以前は SQL から項目を削除する必要があったが、 SQL には残したまま、redash上で非表示にできるようなった。 表（Table）では表示させたくないが、グラフでは使いたい、といった場合も、クエリを分ける必要がなく、 １つのクエリで実現できるようになった。（開発生産性、運用保守性が格段にあがりますね！） 手順 ・「Table」画面の左下にある「Edit Visualization」をクリック ・非表示にしたい項目の項目名にある チェックボックス からチェックを外す 項目の表示順を変更できるようになった（便利度：★★） 項目の表示順を SQL の変更なしに、redashで変更できるようになりました。 手順 ・「Table」画面の左下にある「Edit Visualization」をクリック ・順番を変更したい項目をクリックして、移動したい場所に持っていきます。 項目の表示を右寄せ、中央寄せ（？）、右寄せの設定が可能になった（便利度：★★） v4以前は、数値でも、文字列でも、なんでも右寄せでしたが（なので特に数値は読みずらかった）、 項目ごとに変更できるようになりました。 手順 ・「Table」画面の左下にある「Edit Visualization」をクリック ・項目名の下にあるボタンで切り替える（説明が雑ですが、見れば分かると思います。） 表に表示する件数を変更できるようになった（便利度：★★★） これまでは１５件（？）だった表示件数を変更できるようになりました。 手順 ・「Table」画面の左下にある「Edit Visualization」をクリック ・「Visuralization Name」の下の「Grid」をクリック ・「items per page」で表示したい件数を選択 　※　いまいま5, 10, 15, 20, 25から選択可能 　　（1か月の日数分表示するために50とか欲しいなぁ） ダッシュ ボード クエリの追加・削除・レイアウト変更の方法が変更 ダッシュ ボードにクエリ（表やグラフ）を追加・削除・レイアウト変更する方法が変更になりました。 手順 ・ ダッシュ ボードの右上の「・・・」をクリック ・「Edit」をクリック クエリの追加 ・画面右下の「Add Widget 」をクリック ・追加したクエリを選択 　※　v4以前で選択できた、表示サイズ（幅）は、ここでは選択できなくなりました。 　　　追加した後にサイズを調整できるように変更となりました。 クエリの削除 ・削除したいクエリの右上の「×」をクリック クエリのレイアウト変更 ・移動したいクエリを選択して、マウスで移動したい場所まで移動 クエリのサイズのバリエーションが増えた（便利度：★★★） v4以前は、通常（画面の幅の半分）と２倍（画面の幅の全部）のみ選択できました。 v4になって、新たに画面の1/3のサイズにすることができるようになりました。 手順 ・ ダッシュ ボードの右上の「・・・」をクリック ・「Edit」をクリック ・サイズを変更したいクエリを選んで、クエリの枠にカーソルを置くと、カーソルが「⇔」に変わるので、クリックしてサイズを変更します。（説明が雑ですが、やれば分かります。） クエリの高さが変更できるようになった（便利度：★★★★） 上記と似てますが、幅だけではなく、v4から新たに高さを自由に変更することができるようになりました。 手順 ・ ダッシュ ボードの右上の「・・・」をクリック ・「Edit」をクリック ・高さを変更したいクエリを選んで、クエリの枠にカーソルを置くと、カーソルが「↕」に変わるので、クリックしてサイズを変更します。（説明が雑ですが、やれば分かります。）

エニグモ データ活用推進室 @kmt47 です。 この記事は Enigmo Advent Calendar 2018の5日目 です。 自己紹介 2018年4月に エニグモ に入社しました。 社会人経験、エンジニア経験は、かれこれ20年を超えました。 あえて分類するとデータベースエンジニアになるでしょうか。 SIer 時代は、ご多分に漏れず、PG, PL, PMなど経験しましたが… その頃は「DBといえば Oracle 」という時代でしたので、 Oracle は7から9iくらいまでかなりやりました。 そこからネット系の事業会社を転々と。 この記事の目的 タイトルに「はじめの一歩」とあるように、はじめて Google Spreadsheetで Google Apps Script(GAS)を利用する方向けの内容です。 どちらかというと非エンジニア向けの内容です。 新しいことを習得しようとしたときに、誰もが最初は初心者です。いろいろな壁にぶつかると思います。何時間も悩んだ挙句、気づいてみたらとても些細なことだった、なんてことも一度や二度ではないでしょう。 ただ、ある程度コツが掴めてくると、そこからは順調に事が進むようにもなりますよね。（エラーが出たときの対処の方法や、分からないことが出てきた時の調べ方のコツが身についてくるんだと思います。） ただ、コツを掴む前に挫折してしまう人もいるでしょう。 そもそも、最初の一歩すら踏み出せない方もいるでしょう。 本記事は、そんな一歩を踏み出すための「何となくできそうかも」を感じてもらうことを目的としています。なので、最小限の手順で、最小限のプログラムとし、難しい解説は省いています。 まずは「はじめの一歩」を踏み出していただければ幸いです。 GASとは？ Google Apps Script（GAS）とは、 Google 社が提供する スクリプト言語 です。以上。 GASで出来ること GASでは、 Google スプレッドシート や Googleカレンダー など Google 社が提供するサービスに対して操作（処理）することができます。まぁ、いろいろできますが、それは追々分かっていけばよいと思います。 本題 目次 Google Spreadsheetを開く スクリプト エディタを開く GASを実行する スプレッドシート の値を取得する スプレッドシート に値を出力する Google Spreadsheetを開く Google ドライブから「新規」＞「 Google スプレッドシート 」＞「空の スプレッドシート 」を選択 空の スプレッドシート を開くことができました！！（GAS以前の話ですね） スクリプト エディタを開く 「ツール」＞「 スクリプト エディタ」を選択 別のタブに スクリプト エディタが開きます。 プログラムを書くエディタらしき画面ができていましたね。（ﾊﾟﾁﾊﾟﾁ） GASを実行する 2行目に以下を記載して、「▶」ボタンを選択 Logger.log( "Hello, World!" ); Logger.logは、引数の値をログに出力する関数です。 「表示」＞「ログ」を選択、ログ画面が表示 おめでとうございます。あなたの作成したGASが見事に実行されました！（ﾊﾟﾁﾊﾟﾁﾊﾟﾁ） スプレッドシート の値を取得する A1のセルの値を読み込んで、ログに出力してみましょう。 ここから少しプログラミングっぽくなってきますよ。 function myFunction() { //アクティブのシートを取得 var sheet = SpreadsheetApp.getActiveSheet(); //セルA1を変数rangeに取得する var range = sheet.getRange( 'A1' ); //rangeの値をログに出力する Logger.log(range.getValue()); } SpreadsheetApp.getActiveSheet()で対象のシートを変数(sheet)に格納します。 getActiveSheet()では、アクティブ（いま選択されている）シートが選択されます。 getSheetByName(シート名)では、シート名からシートを選択できます。 次に対象のセルを変数(range)に格納します。 sheet.getRange('A1')のように、セルのアドレスを指定する方法と、 sheet.getRange(1, 1)のように、セルの行番号と列番号を指定する方法があります。 sheet.getRange(行番号, 列番号)の順で指定します。 Logger.log(range.getValue())では、指定したセルの値をログに出力しています。 A1のセルの値がログに出力されました。 スプレッドシート に値を出力する 次は、 スプレッドシート に値を出力するプログラムです。 function myFunction() { //アクティブのシートを取得 var sheet = SpreadsheetApp.getActiveSheet(); //セルA3を変数rangeに取得する var range = sheet.getRange( 'A3' ); //A3に"Hello, GAS!"を入力 range.setValue( "Hello, GAS!" ); } 「 スプレッドシート の値を取得する」と同様に SpreadsheetApp.getActiveSheet()でシートを変数(sheet)に格納し、 sheet.getRange('A3')で対象のセルを変数(range)に格納します。 そして、range.setValue("Hello, GAS!")で対象のセルに値を入力します。 A3のセルに値を出力することができました。 まとめ データを読み込んで、書き出すというプログラミングの基本を通して、GASによる Google スプレッドシート の操作について見てきました。 「何となくできそうかも」と感じていただけたでしょうか？ 本格的にGASを利用するとなると、関数、変数、データ型、オブジェクト、メソッド、配列などなど、知っておく必要のあることは、いろいろあります。 ただ、いっぺんに全て理解する必要はありません。必要なことから少しずつ理解を進めていけば大丈夫です。 私はその過程で以下のサイトを大変参考にさせていただきました。 例題をもとに分かりやすく解説されていますので、是非参考にしていただければと思います。 「いつも隣にITのお仕事」 https://tonari-it.com/ 【保存版】初心者向け実務で使える Google Apps Script完全マニュアル https://tonari-it.com/google-apps-script-manual/ それでは、GASへの「はじめの一歩」を踏み出していただければ幸いです。

Enigmo Advent Calendar 2018 の4日目の記事です。 この記事の目的 Enigmoが運営している BUYMA では古代から運用している jQuery の他に、2016年頃から一部ページのフロントエンドをReact/Reduxで構築しています。 私自身もEnigmoに入社してからの約三年間でReact/Reduxアプリケーションの開発に多数携わってきましたので、そこで培った知見を共有したいと思います。 React/Reduxの利点 まずはじめに、ReactとReduxを使うメリットを再確認しておきたいと思います。 それぞれのメリットをしっかりと認識しておくことで、実装する際どう書くか迷ってしまった場合などにそのメリットを最大限活かす選択をすることができます。 Reactの利点 コンポーネント 化が容易で再利用性が高い 状態をDOMから分離できる(Stateless) Reduxのような外部ライブラリを併用すると コンポーネント 自体からも分離できる (props) => DOM Tree という関数のように扱える(同じinputなら常に同じoutputを得られる) Propsとして イベントハンドラ を渡していく アーキテクチャ なので、ロジックをまとめて 疎結合 にしやすい Reduxの利点 Reducer、ActionCreator、Componentといった利用側が書くべきモジュールはすべて純粋な関数で書ける ほとんど関数の集合だけでアプリケーションが完成する 副作用のある処理はすべて後述するMiddleware層に持っていける 上記の理由からテストが非常に書きやすい React/Reduxはこう書く！！ では実際に私がReact/Reduxアプリケーションを実装する際指標としているプ ラク ティスを解説していきたいと思います。 Container Componentsの分割 Container Components とは Redux Store と connect している コンポーネント のことです。 詳細はReduxの公式Doc をご確認ください。 Container Componentsを適切に分割することでコードの見通しを良くします。 Containerの中にContainerが存在する、 Container in Container も許容します。 分割されていない例 import { connect } from 'react-redux' import * as React from 'react' import ComponentA from '../components/ComponentA' import ComponentB from '../components/ComponentB' import * as actions from '../actions' class BadContainer extends React.Component { componentDidMount() { this .props.fetch() } render() { return ( <div> <ComponentA name= {this .props.nameA } handler1= {this .props.handlerA1 } handler2= {this .props.handlerA2 } /> <ComponentB name= {this .props.nameB } handler1= {this .props.handlerB1 } handler2= {this .props.handlerB2 } /> </div> ) } } const mapStateToProps = state => { return { nameA: state.a.name, nameB: state.b.name } } const mapDispatchToProps = dispatch => { return { handlerA1() { dispatch(actions.actionA1()) } , handlerA2() { dispatch(actions.actionA2()) } , handlerB1() { dispatch(actions.actionA1()) } , handlerB2() { dispatch(actions.actionA2()) } , fetch() { dispatch(actions.fetchData()) } } } export default connect(mapStateToProps, mapDispatchToProps)(BadContainer) この例では一つのContainerで２つの コンポーネント 、ComponentAとComponentBを表示しようとしています。 今回の例では２つだけですが、今後３つ、４つと表示する コンポーネント が増えていくとその分必要なハンドラーやプロパティが増えていくため、 mapStateToProps と mapDispatchToProps が肥大化してしまい見通しが悪くなります。 分割されている例 // GoodContainer.jsx import { connect } from 'react-redux' import * as React from 'react' import ContainerA from './ContainerA' import ContainerB from './ContainerB' import * as actions from '../actions' class GoodContainer extends React.Component { componentDidMount() { this .props.fetch() } render() { return ( <div> <ContainerA /> <ContainerB /> </div> ) } } const mapDispatchToProps = dispatch => { return { fetch() { dispatch(actions.fetchData()) } } } export default connect(()=> { return {} } , mapDispatchToProps)(GoodContainer) // ContainerA.jsx import { connect } from 'react-redux' import * as React from 'react' import ComponentA from '../components/ComponentA' import * as actions from '../actions' const mapStateToProps = state => { return { name: state.a.name, } } const mapDispatchToProps = dispatch => { return { handler1() { dispatch(actions.actionA1()) } , handler2() { dispatch(actions.actionA2()) } , } } export default connect(mapStateToProps, mapDispatchToProps)(ComponentA) // ContainerB.jsx import { connect } from 'react-redux' import * as React from 'react' import ComponentB from '../components/ComponentB' import * as actions from '../actions' const mapStateToProps = state => { return { name: state.b.name, } } const mapDispatchToProps = dispatch => { return { handler1() { dispatch(actions.actionB1()) } , handler2() { dispatch(actions.actionB2()) } , } } export default connect(mapStateToProps, mapDispatchToProps)(ComponentB) 分割されている例では、もともと componentDidMount でデータフェッチしていた箇所だけを元のContainerに残し、 ComponentA と ComponentB に関するプロパティとハンドラーをそれぞれ ContainerA と ContainerB に分割しています。 こうすることでコードの肥大化を防ぎ見通しがかなり良くなったと思います。 ただし、全ての コンポーネント を connected にするとやりすぎなので適切な単位で分割する必要がありますのでご注意ください。 例えば ECサイト の場合、 商品名 、 商品コメント 、 配送方法 、のようなおおざっぱな単位で分割していき、それでもコードの見通しが悪いと感じたら更に分割するというような感じで実装しています。 またContainer Componentsのテストの仕方については以前書いた記事がありますので読んで頂けると幸いです。 https://qiita.com/hiyamamoto/items/281709cc2a98268fb6c2 Presentational Componentsの分割 前項に続き コンポーネント の分割についてです。 Presentational Components についての詳細は Reduxの公式Doc をご確認ください。 Presentational Components を分割する理由としては前項と同様に見通しを良くするため、テストのしやすさのためです。 また、Reactのメリットにも書いてある再利用性を高めるという利点もあります。 まずは分割されていない例を見ていきましょう。 適切に分割されていない例 function Page(props) { return ( <div> <div> <h1> { props.headerTitle } </h1> </div>> <div> <button>進む</button> <button>戻る</button> { props.value } </div> <div> <a href= "/path/1" >Link1</a> <a href= "/path/2" >Link2</a> </div> </div> ) } こちらの例では複数の div 、 button 、 a 要素が出てきています。 そんなに大きな コンポーネント ではありませんが既にちょっと見通しが悪くなっていると思います。 また、この コンポーネント のテストは以下になります。 ※ コンポーネント のテストは enzyme というライブラリの使用を前提としています describe( '<Page />' , () => { const wrapper = shallow(<Page />) it( 'render 進むButton' , () => { // button が複数出てくるのでうまく特定出来ない expect(wrapper.find( 'button' ).fisrt().contains( '進む' )).to.be. true } ) } ) このように複数の同一要素がある場合は wrapper.find('button').first() のように表示順を意識して コンポーネント の取得をする必要が出てきてしまい、ただ表示順が変わっただけでテストが壊れてしまいます。 では分割されている例を見てみましょう。 適切に分割されている例 function Page(props) { return ( <Container> <Header title= { props.headerTitle } /> <Body> <ForwardButton onClick= { props.onClickForward } /> <BackwardButton onClick= { props.onClickBackward } /> <BodyContent value= { props.value } /> </Body> <Footer> <Link1 /> <Link2 /> </Footer> </Container> ) } 分割されている例 では 分割されていない例 で見られた div などが一切出てきていないため見通しが良くなっているのがわかると思います。 また、それぞれの コンポーネント の意味が コンポーネント 名からひと目で分かるようになっています。 この コンポーネント のテストはこちらです。 describe( '<Page />' , () => { const wrapper = shallow(<Page />) it( 'render 進むButton' , () => { // ForwardButton というコンポーネントがあるかテストするだけで良い expect(wrapper.find(ForwardButton)).to.have.length(1) } ) } ) 進むボタン が コンポーネント 化されたため、 戻るボタン との表示順を気にする必要がなくなり、デザインの都合で表示順が変わったとしてもテストが壊れることがなくなりました。 ComponentをStatelessに保つ Reactの利点として状態をDOMから分離できるということを前述しましたが、 コンポーネント からも状態を分離することで本来の コンポーネント が持つViewとしての役割だけに専念させることができます。 Reactの基本として state というもので状態を管理することができますが、その state そのものを持たない コンポーネント を Stateless Functional Component と呼びます。 React/Reduxアプリケーションでは state は基本的に redux store で管理し、 コンポーネント では state を使わないようにすることで状態管理を一元化することができます。 ただし、ボタンクリック時にモーダルを表示したり、フォーカスしたときに値を加工するだけなど、その コンポーネント 内で完結するような state を持つことはさほど問題にはならず、全ての状態を redux store で管理しなければいけないというわけではないと個人的には考えています。 ある コンポーネント の状態を別のツリーの コンポーネント で参照したい場合や、 ドメイン ロジックに関わる状態は redux store で管理し、 コンポーネント 内部で完結する状態はその コンポーネント の state として管理するように柔軟に設計するのがベターです。 Stateless Functional Component の書き方 state や lifecycleメソッド を持たない場合は class シンタックス ではなく、関数を使います。 コンポーネント 名として関数名が使われるため、 arrow function より通常の関数として書くとよいです。 function FooComponent(props) { return ( <div> 名前: { props.name } 年齢: { props.age } </div> ) } 利点 ただの関数なのでテストしやすい stateを持ってないことが一発でわかる Reducerの分割 Reduxでは combineReducers という関数を使って通常Reducerを分割すると思います。 Reduxの公式Doc ではReducerを分割する際、 コンポーネント の レンダリング ツリーで分割するのではなく ドメイン データごとに分割することを推奨しています。 また、 DomainState 、 AppState 、 UIState という３つのStateに分割することが提案されています。 DomainState 例えば、商品や取引などの ドメイン 特有のstateのことです。 前述した レンダリング ツリーごとの分割と ドメイン データごとの分割の比較をしてみます。 レンダリング ツリーごとの分割 レンダリング ツリーごとの分割は簡単に言うと画面ごとの分割ということです。 下記は 新規画面 、 編集画面 、 一覧画面 といった画面ごとに分割している例です。 reducers ├── newReducer.js ├── editReducer.js └── listReducer.js ドメイン データごとの分割 変わって ドメイン データごとの分割では、 商品 、 配送方法 、 ブランド などの ドメイン データで分割しています。 reducers ├── productReducer.js ├── shipphingReducer.js └── brandReducer.js AppState アプリケーション全体の state は ドメイン データ用のReducerとは別のReducerとして用意すると、見通しが良くなります。 例えば、データをローディング中かどうかを管理する isLoading などの state はこちらに含めます。 UIState モーダルの表示状態などのUI特有の state も別のReducerで管理します。 ただし、前述のように コンポーネント の state として持つことも多いです。 stateは POJO (Plain Old JavaScript Object) state は基本的に immutable(不変) object として扱います。 下記のようなコードはNGです。 const defaultState = { foo: 'foo' , bar: 'bar' } const reducer(state = defaultState, action) => { if (action.type === 'Foo Action' ) { state.foo = action.payload // fooだけ変更したい return state } } immutable.js を使えばかんたんに不変オブジェクトを生成できます。 import { Map } from 'immutable' const defaultState = Map( { foo: 'foo' , bar: 'bar' } ) const reducer(state = defaultState, action) => { if (action.type === 'Foo Action' ) { return state.set( 'foo' , action.payload) // fooだけ変更したい } } 上記の Map.prototype.set は常に新しい Map の インスタンス を返します。 ただし、 Map は普通のオブジェクトのようにプロパティにアクセスできないので、 コンポーネント 内でアクセスする際には state.get('foo') のようにする必要があります。 また、 API などから取得してきた JSON を毎回 Map オブジェクトに変換する必要があるため結構面倒です。 それ、ES2015+でできるよ const defaultState = { foo: 'foo' , bar: 'bar' } const reducer(state = defaultState, action) => { if (action.type === 'Foo Action' ) { return { ...state, foo: action.payload // fooだけ変更できる！ } } } state は色々な場所( コンポーネント 、 API クライアントなど)でアクセスするので、「immutableオブジェクトになってるか？」といちいち判定するのは面倒です。 常に POJO にしておくことでその手間を減らすことができます。 Reducerから ドメイン ロジックを分離したい場合 ドメイン データ用のReducerに ドメイン ロジックを書いてしまうとコードがどんどん肥大化していってしまうため、下記のように ドメイン データを models ディレクト リ配下に書きたくなると思います。 import MyClass from '../models/MyClass' const defaultState = new MyClass( { foo: 'foo' , bar: 'bar' } ) const reducer(state = defaultState, action) => { if (action.type === 'Foo Action' ) { // ドメインロジックはドメインクラスに委譲 return state.changeFoo(action.payload) } } このようにしたい場合は models 配下からクラスではなく関数をエクスポートすることで代替できます。 import { changeFoo } from '../models/MyDomainModel' const defaultState = new MyClass( { foo: 'foo' , bar: 'bar' } ) const reducer(state = defaultState, action) => { if (action.type === 'Foo Action' ) { // ドメインロジックはドメインモデルの関数に委譲 return changeFoo(state, action.payload) } } export const changeFoo = (model, value) => { // 複雑な処理 return { ...model, foo } } 他にも immutable.jsのRecordを使う方法 などがありますが、前述の通り変換の手間などを考えると個人的にはあまりおすすめしません。 FSA(Flux Standard Action)を使う Flux Standard Action とは https://github.com/redux-utilities/flux-standard-action actionの型が実装者によってまちまちになると読みづらいし不便だから標準化しましょうね、という話です。 割と界隈では デファクト になってる気がします。 非同期処理の成功、失敗ごとに LOAD_SUCCESS 、 LOAD_FAILURE のようにactionを分けるのではなく LOAD_FINISH のように一つにまとめることが出来ます。 { type: 'LOAD_FINISH' , payload: { id: 1, text: 'Do something.' } , meta: { ... // metadata } } { type: 'LOAD_FINISH' , payload: new Error(), error: true } アクションの型が統一されて書く方も読む方も負荷が減るのでおすすめです。 非同期処理 reduxの登場人物(component, reducer, actionCreator)は純粋な関数の集まりなので副作用のある処理を書く場所がありません。 一般的に副作用のある処理は Middleware層 を利用します。 非同期処理をする為のMiddlewareとしては redux-thunk と redux-saga が有名です。 redux-thunk vs redux-saga redux-thunk Pros API がかんたんで学習コストがほぼ0 サッと導入してサッと書ける Cons actionCreatorにロジックが入り込む actionCreatorから純粋さがなくなる そのため actionCreatorのテストが複雑になる redux-saga Pros 副作用のある処理が完全に分離できる API が豊富にあり並列化したりスロットルしたり色々出来る [redux-saga]フォームに高速で入力するとガックガクになる問題 - Qiita 高テスタビリティ Cons 学習コストが高い Generator関数はとっつきにくい API が多い 小さめのアプリケーションでは redux-thunk 、大きくて複雑なアプリケーションでは redux-saga 、 というように使い分けるといいでしょう。 まとめ どの フレームワーク にも言えることですが、見通しがよくメンテしやすいアプリケーションを書くためにはコードを適切な単位で分割することが非常に重要です。 React/Reduxアプリケーションでは コンポーネント を分割し再利用性を高めたり、状態を適切に分割することで、それぞれのメリットを最大限に活かせると思います。 Reduxの公式Doc では今回書いたReduxアプリケーションを設計する上での考え方が詳細に書かれていて非常に参考になるのでぜひご一読ください。 株式会社 エニグモ 正社員の求人一覧 hrmos.co

はじめに こんにちは。2018年9月入社でデータ分析担当の@Tawasshyです。 この記事は Enigmo Advent Calendar 2018の3日目 です。 弊社ではファッション ECサイト である BUYMA を展開しております。 売り手となるバイヤー(パーソナルショッパー)は世界中に在住しており、多種多様な商品を買い付けして膨大なSKUが存在します。 一方で、買い手側の購買行動も多岐に渡るのも必然となります。 そのような複雑な関係性を分析する状況においても、今回紹介するバスケット分析のような、基本的とも言える分析手法は解釈もしやすく、効果的な手段の一つになり得ると思っております。 バスケット分析について バスケット分析は何と何の商品が一緒に買われているかに着目する分析方法であり、マーケット・バスケット分析、アソシエーション分析とも呼ばれています。 一般的な話 有名な事例としては、「おむつとビール」が同時に買われやすい、というルールの発見があります。 また、Agrawal氏らが1994年に発表した論文「Fast algorithms for mining association rules」（ IBM Almaden Research Center）が、この分析手法が普及したきっかけとなったことが有力な説のようです。 なぜ SQL でやるのか バスケット分析は R言語 のarulesというライブラリを使うのが、もっとも手軽な方法であると思いますが、今回は SQL での実行を紹介します。 弊社ではエンジニアだけではなく、ディレクターやマーケター、カスタマサポートといったビジネスサイドのメンバーも SQL を日常的に叩いており、 SQL での分析の幅を拡げることに貢献できたら良いなと思ったことが SQL でやる理由です バスケット分析詳細 まず、二つの商品X、Yがあったとします。 商品Xが買われた場合、商品Yという商品を買う確率を扱います。その指標として以下の指標を扱います。 今回算出する指標 信頼度(confidence) 商品Xが買われた場合に、商品Yを買う確率。 リフト値 商品Yが買う確率が、商品Xを買った場合に商品Yを買う確率がどれだけ変化したかの倍率。 (信頼度➗商品Yが買われる確率) Xを買ってYを買う確率がどれだけ持ち上がったかと解釈できる。 今回算出しない値 支持値(support) XとYが同時に買われている確率を示します。バスケット分析においてはこれも重要な指標ですが、今回は説明を割愛します。 環境構築について 手元のローカルマシンで簡単に再現できるので SQLite でやってみます。 macOS の場合は以下のように brew で一発です。なお、 Windows でも手軽にインストールできますが、ここでは割愛します。 $ brew install sqlite3 データの準備について SQLite を起動します。カレント ディレクト リにbasket.sqlite3というの名のDBが生成され、DBに接続した状態となります。 $ sqlite3 basket.sqlite3 無事に起動できたらこのようにterminalにこのように表示されます。 sqlite > まず、にテーブルの定義を行います。 create table sales_history( item_category char ( 12 ), user_id char ( 8 ) ); 購買履歴を作成します。 insert into sales_history values ( ' トップス ' , ' UID100001 ' ), ( ' 財布 ' , ' UID100001 ' ), ( ' 財布 ' , ' UID100002 ' ), ( ' トップス ' , ' UID100002 ' ), ( ' 靴 ' , ' UID100002 ' ), ( ' トップス ' , ' UID100002 ' ), ( ' アウター ' , ' UID100002 ' ), ( ' アウター ' , ' UID100102 ' ), ( ' ワンピース ' , ' UID100103 ' ), ( ' 靴 ' , ' UID100104 ' ), ( ' 財布 ' , ' UID100104 ' ), ( ' 靴 ' , ' UID100105 ' ), ( ' 靴 ' , ' UID100106 ' ), ( ' トップス ' , ' UID100107 ' ), ( ' トップス ' , ' UID100108 ' ), ( ' 靴 ' , ' UID100109 ' ), ( ' 財布 ' , ' UID100110 ' ), ( ' 靴 ' , ' UID100111 ' ), ( ' トップス ' , ' UID100111 ' ), ( ' 靴 ' , ' UID100112 ' ), ( ' 靴 ' , ' UID100112 ' ), ( ' トップス ' , ' UID100113 ' ), ( ' 財布 ' , ' UID100113 ' ), ( ' ワンピース ' , ' UID100114 ' ), ( ' ワンピース ' , ' UID100114 ' ) ; これでデータの準備はできました。 バスケット分析の実行 信頼度の算出 select combi_count.item_category, combi_count.item_category2, cast (combi_count.order_count as real)/item_count.order_count as confidence from ( select item_category, count ( distinct user_id) as order_count from sales_history group by item_category )item_count inner join ( select X.item_category, Y.item_category as item_category2, count ( distinct X.user_id) as order_count from sales_history as X inner join sales_history Y on X.user_id = Y.user_id and X.item_category Y.item_category group by X.item_category,Y.item_category )combi_count on combi_count.item_category = item_count.item_category ; 以下のように出力されます。 商品X、商品Y、信頼度という順番です。 商品X 商品Y 信頼度 アウター トップス 0.5 アウター 財布 0.5 アウター 靴 0.5 トップス アウター 0.166666666666667 トップス 財布 0.5 トップス 靴 0.333333333333333 財布 アウター 0.2 財布 トップス 0.6 財布 靴 0.4 靴 アウター 0.142857142857143 靴 トップス 0.285714285714286 靴 財布 0.285714285714286 財布を買ったユーザーがトップスを買う信頼度がもっとも高いことが分かります。 リフト値も追加して算出 上の sql が書ければ、全体でYが買われている確率を算出し、joinして信頼度を割ればリフト値が算出できます。 select combi_count.item_category, combi_count.item_category2, cast (combi_count.order_count as real)/item_count.order_count as confidence, cast (combi_count.order_count as real)/item_count.order_count / AllBuyY.order_count as lift from ( select item_category, count ( distinct user_id) as order_count from sales_history group by item_category )item_count inner join ( select X.item_category, Y.item_category as item_category2, count ( distinct X.user_id) as order_count from sales_history as X inner join sales_history Y on X.user_id = Y.user_id and X.item_category Y.item_category group by X.item_category,Y.item_category )combi_count on combi_count.item_category = item_count.item_category -- 全体でYが買われている確率を算出してjoinする inner join ( select item_category, cast ( count ( distinct user_id) as real) / ( select count ( distinct user_id) from sales_history) as order_count from sales_history group by item_category ) AllBuyY on combi_count.item_category2 = AllBuyY.item_category ; 以下のように、出力されます。 商品X、商品Y、信頼度、リフト値を出しております。 商品X 商品Y 信頼度 リフト値 アウター トップス 0.5 1.25 アウター 財布 0.5 1.5 アウター 靴 0.5 1.07142857142857 トップス アウター 0.166666666666667 1.25 トップス 財布 0.5 1.5 トップス 靴 0.333333333333333 0.714285714285714 財布 アウター 0.2 1.5 財布 トップス 0.6 1.5 財布 靴 0.4 0.857142857142857 靴 アウター 0.142857142857143 1.07142857142857 靴 トップス 0.285714285714286 0.714285714285714 靴 財布 0.285714285714286 0.857142857142857 信頼度、リフト値について ある商品を買う確率としての指標として、どちらが大事というのはケースバイケースとなりますが、 両方が高い値でないとユーザーの傾向を示す効果的な分析にならないことが言えます。 リフト値が高く、信頼度が低い場合 全体で商品X, あるいは商品Y自体を買われている確率が全体で低い場合に起きます。 商品Xが買われることが少ない為、リフト値が高い値を示してもYを買う確率は小さいままになります。 また、商品Y自体を買われている確率が全体で低い場合は、リフト値が掛けかれる元の確率が低いことになる為、Yを買われる確率は低いままということになります。 リフト値が低く、信頼度が高い場合 何もしなくてもYを買われる確率が高く、Xを買っても買わなくても、Yを買う確率の増減が小さい状態を示します。 そもそも購買履歴が少ない場合… 偶然、信頼度、リフトが高く出るということが起こり得るので、Xを買ったユーザーYの購買促進を行うキャンペーンなどの施策を行っても有効に働かない場合があります。 実際にDBに接続して行う場合は 同じテーブルへの問い合わせが散在しているので、 PostgreSQL , MySQL , SQLServer 等ではwith句は必須であると思います。 SQL でやるのがめんどくさいなと思ったら.. データを抽出する必要がありますが、 R言語 でarulesというライブラリを使えばもっと手軽にできますし、無料です。 さいごに 弊社ではデータ分析に取り組む一方、データ分析基盤を整え、データ活用の効率化とアクセスビリティを推進しております。 エンジニアはもちろん、データを活用しながら「世界を買える」ビジネスに挑戦してみたいメンバーのジョインをお待ちしております！ やんちゃであれ！ ENIGMO7より 参考 https://www.albert2005.co.jp/knowledge/marketing/customer_product_analysis/abc_association https://codezine.jp/article/detail/10284

こんにちは、Enigmo 新卒エンジニアの @sean0628_i です。 Enigmo Advent Calendar 2018 2日目の記事です。 初めに Accelerated Mobile Pages の略であり、高速でスムーズにWeb ページを表示するためのライブラリー、或いはその仕組みのことです。 通常のHTML に比べて、制限が多く存在します。 今回は AMP 公式のドキュメントの仕様に関する箇所 が英語だったので、読解し要点をまとめます。 AMP 制限 特定の要素を マークアップ に含める。 JavaScript は利用不可。 inline CSS のみ利用可。 -> 50KB の制限付き 特定のHTML tag は利用不可。 HTML 内、コメント不可。 特定の CSS properties は利用不可。 必要な マークアップ <!doctype html> でHTML を書き始める。 <html ⚡> tag を含める。（<html amp> でも代用可能） <head> tag と<body> tag を含める。（通常のHTML では任意） <head> tag 内の一番初めに、<meta charset=" utf-8 "> を含める。 <head> tag 内に、<link rel=" canonical " href="$SOME_URL"> を含める。（ $SOME_URL は通常版のHTML のURL、通常版のHTML が存在しない場合はAMP のURLを入れる。） <head> tag 内に、<meta name="viewport" content="width=device-width"> を含める。 minimum-scale=1 および、 initial-scale=1 も含めることが勧められる。 <head> tag 内に、<script async src=" https://cdn.ampproject.org/v0.js "></script> を含める。 <head> tag 内に、AMP Boilerplate Code（head > style[amp-boilerplate] と noscript > style[amp-boilerplate]）を含める。 HTML tags tag 適正 script ×（type が application/ld+json の場合のみ○） noscript ○ base × img amp-img にて代用 video amp-video にて代用 audio amp-audio にて代用 iframe amp-iframe にて代用 frame × frameset × object × param × applet × embed × form ○（ amp-form extension を含めることで利用可） input elements 一部（<input[type=image]>、<input[type=button]>、<input[type=password]>、<input[type=file]>）を除いて○<fieldset>、<label> は○ button ○ style <head> tag 内に、一つのみ追加可。 amp-custom attribute を持たせる必要あり。 link microformats.org に、登録されている rel は○ meta http-equiv attribute が特定の値に利用可。詳細: AMP validator specification a ○ href attribute を javascript: から始めてはいけない。 target を設定する場合、 _blank を利用。 svg 殆どの SVG は利用可 Comments HTML 内でコメントは利用できない。 CSS 50,000 bytes の上限を超えてはいけない。 !important は利用できない。 transition および、animation 関連は opacity 、 transform properties のみ利用可。

こんにちは、18年新卒エンジニアの @sean0628_i です。 早いもので今年ももう12月、Enigmoにジョインしたのが今年の春なので、気がついたら入社してから半年ほどが経っていますね。。。 さて、12月といえば Advent Calendar の季節ですねー笑 今年はEnigmoも初めてAdvent Calendar を公開することとなりました。 というのも、新卒の私が「面白そうだなぁー。」、とボソッと呟いたところ、部長殿から「やってみたらー。」、とOKをいただきましたので、 他のメンバーにもご協力をいただき、 Enigmo Advent Calendar 2018  を公開することになりました。 記念すべきEnigmo Advent Calendar 2018の1日目は、文系学部から新卒でエンジニアになった私が今までに読んで、実際に業務で役に立った技術書5選をお届けします。 そもそもAdvent Calendarとは？ さっきから、「”Advent Calendar”とか、横文字多用しやがって。」、という方、大変失礼しました、、、ご説明します。 Advent Calendar とは、元々クリスマスまでの日数を数えるためのカレンダーで、日ごとに小さなポケットを設け、そこにお菓子を入れて楽しんだりするものだそうです。 数年前からWeb 業界の企業ではではそれに倣って、クリスマスまでの25日間記事を公開するようになりました。 つまり、我々が意味するAdvent Calendar とは、25日間記事を公開し続けるという言わば苦行のことです。 ただ、エンジニアとして新たな知識の習得、既知の知識の共有は避けられません。 ということで、今回は苦行を断行します。 ＊ なお、苦行ゆえ時々お休みすることもあるかと思いますが、その点はご容赦いただければと思います。 オススメの技術書5選 1. プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ) こちらの本は、知人の勧めで入社する前に読みました。当時は本当に Ruby 初心者、というか プログラミング言語 初心者でした。 そんな私でも途中で挫折せず、 Ruby を学べたのはこの本のおかげかなぁと。 この本では実際に手を動かして学習することが出来ます。 ひたすら読むだけだと飽きてしまいますし、言語習得のためには実際に手を動かすのが一番かとも思います。 そういった意味でこの本はオススメです。 2. Ruby on Rails 5アプリケーションプログラミング 上記の本で Ruby を一通り学んだ後、こちらで Rails を学びました。 もし、アプリ作成の一連の流れを知りたいということであれば、 Rails tutorial がオススメです。 一方で、 この本では、 Rails 組み込みのメソッドや、 Rails の仕組みが事細かに紹介されています。 Rails を体系的に学びたいという方や、 Rails tutorial やったけどもう少し深く Rails を知りたいという方にはこの本がオススメです 。 3. Everyday Rails - RSpecによるRailsテスト入門 この本は入社直後、研修の一環で読みました。 当時は、午前中に本を読み、午後に実務でアウトプットするという形式でした。右も左もわからず、テストを書くのが本当に嫌いでした笑 しかし、この本で基礎を学び、実務でのテストコードの実装を重ねた結果、今ではテストを書くことが苦ではなくなりました。 さらには、テストコードがない ソースコード を見ると不安を覚える身体になってしまいました笑 とてもわかりやすいのでオススメです。 4. スッキリわかる SQL 入門 ドリル215問付き! (スッキリシリーズ) 実務では主に Ruby on Rails を使用しているのですが、事あるごとに SQL の記述に迫られます。 ちなみに、Enigmoのメンバーは、エンジニアに限らず殆どの人が SQL を扱う事ができます。 もともと マーケティング 業界で インターンシップ をしていた私には、これがとても衝撃でした。 ともかくも、この本が良かった点はブラウザ上に環境が整備されているので事前の準備が不要で、すぐに SQL を学習できたということです。 実践問題も付いているので、この本一冊で SQL の基本をしっかりと身に付けることができると思います。 5. リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) プログラミングを進める上で必要な 命名規則 、コード記述の作法に関して学びました。 正直に話すと、プログラミングを初めて1ヶ月くらいの時にこの本を読みました。 その時は、大した気づきもなく「レビュー高い割に、ふーん。」、くらいな感想しかありませんでした。 しかし、つい最近読み返してみると、当たり前だけど現状できていないことが多く記述されていることに気がつきました。 Enigmoのエンジニアの卓上でもちらほら見かけますし、一読の価値はあると思います。 所感 駆け足になりましたが、新卒の私がオススメする実務で役立った技術書5冊上げてみました。 これまでに読んだ本で他にも紹介したい良書はたくさんあります。 オブジェクト指向 の話とか、DB設計の話とかたくさん。 しかし、今回は日々 Ruby を扱うエンジニアとして、言語系で実務に役立った本に的を絞り紹介してみました。 また機会があれば、他の良書も紹介したいと思います。この辺で、Enigmo Advent Calendar 2018 1日目終わりたいと思います。 最後まで読んでいただきありがとうございます。

こんにちは。エンジニアの Steven です。 広島で9月18日から 20日 まで行われた RubyKaigi 2017 に山本さんとエンジニア二人で行ってきましたので、どうだったのかについてレポートさせていただきます。 RubyKaigi は毎年 Ruby 言語を中心に行われる会議です。 最近は日本を巡って毎回違う都市で行われてて、今回は広島で行われました。 日本語のセッションもあれば、英語のセッションもあって、外国人の参加者が少なくはないイベントです。 Ruby のカンファレンスの中でレベルが一番高いと言われています（ Ruby の作者曰く）。 会議は月曜日から水曜日まで行われてて、事前の週末に広島まで行けば、東京に住んでいる私達にとっては、広島で少し観光をする機会でもあって、そうできるように準備していましたが、残念なことにこの週末はちょうど台風がその近くまで通ってきて、観光するどころか、新幹線ではそもそも行けるのかと、逆に心配することになりました。 ですが、会議の３日間自体は天気は極めてよくて、日焼け止めが必要になるのではないかという逆転にもなりました。 １日目 朝起きて、 元安川 （今調べました）を渡って、会議が開催されてる 広島国際会議場 まで行ってから、入場券を受けて、会議スタート！ （目をつぶっていてすみません。後から気づきました。） 初日で見てきた トーク は 基調講演、Nobuyoshi Nakada Fiber in the 10th year、 Koichi Sasada How Close is Ruby 3x3 For Production Web Apps?、Noah Gibbs Gemification for Ruby 2.5/3.0、Shibata Hiroshi How to optimize Ruby internal、Shizuo Fujita I quit my job to write my own language: Goby、Stan Lo Ruby Committers vs the World 今見返してみると、毎日の仕事ですぐに活かせそうな トーク は初日はそんなになかったかと思いますが、 Ruby のコミュニ ティー はどう構成されているのか、どんな課題を抱えているのか、何をやっているのかはより具体的に理解できて、他の Rubyist の毎日に触れて勉強になりました。 この日の最後のセッションとして、 Ruby のコミッターが壇上に上がって、全員で議論をしながら、聴衆の質問に答えてたというイベントがありましたが、この日の中で一番記憶に残ってるところです。 質問に答えるためにコミッターの皆さんが議論にのめり込んで、質問一つだけで1時間が立ってしまいそうな状況に数回なってしまいましたが、その議論を聞くのは単に面白くて、話題はなんであろうと、専門的な技術力を持ってる人が周りにいれば、それだけで面白くなると感しました。 初日のセッションが終わってから、晩御飯が目的で街に出ててたのですが、なぜか赤色のシャツを着ている人が多くて、最初はよくわかりませんでしたが、なるほど、広島の カープ が日本一になった直後でした。 広島市 は全体的に盛り上がっていて、東京に戻ってきたのではないかと、ところどころ人混みができてました。 その夜は広 島風 お好み焼 きを食べる機会になったのですが、やはり美味しくて、２日目も３日目ももう一度食べようという衝動に耐える必要が出ました。 ２日目 翌日は朝に スターバックス によってから、会議場に戻って、２日目スタート！ ２日目で見てきた トーク は 基調講演、 Yukihiro Matsumoto The Ruby Module Builder Pattern、Chris Salzberg Improve extension API : C++ as better language for extension、Kouhei Sutou Automated Type Contracts Generation for Ruby 、Valentin Fondaratov Type Checking Ruby Programs with Annotations、Soutaro Matsumoto Ruby Language Server、Fumiaki Matsushima Write once, run on every boards: portable mruby、Yurie Yamane Lightning Talks 基調講演は今回は Ruby の作者によって行われてて、やはりまつもとさんは本当に実在する人で、自分が普通の人間でも実際に会える方だとわかりました。 基調講演でも少し紹介されましたが、この日の注目は Ruby での型の導入の トーク だったかと思います。 最近新しくできた言語の中では静的型付けの言語が多くあって、どんどん人気になってますが、動的型付けである Ruby でも型のいいところを適切な形で活かせるのかという考えがあって、今回はそれについての トーク は２つもありました。 Ruby には型が実際に入ってしまうのかどうかはまだわからないのですが、型のチェックをしてくれるツールを Ruby に入れることでどうなれそうなのか、 Ruby の未来を少し見れました。 個人的には Lightning Talks はその日の一番面白いセッションでした。 １時間で５分だけの トーク が１２あって、何かをゆっくり学ぶという目的より、いろんな情報を短時間で伝えて、面白話を交えながら、聴衆を楽しませるのがそのライトニング トーク の一つの印象でした。 ビデオは公開されましたので、技術の話で少し笑いたければ、その トーク をおすすめします。 その日は昼休みに 原爆ドーム を見に行く時間は少しあって、日本の 世界遺産 の一つを写真にとどめることができました。 一言でまとめさせていただきますと、感動しました。 その夜の晩御飯は海鮮料理で、少し高めな食事でしたが、広島のもうひとつの名物を食べれてよかったです。 ３日目 いよいよの最終日！ ホテルからチェックアウトして、会議場に戻って、最終日スタート！ この日見てきた トーク は Compacting GC in MRI 、Aaron Patterson Ruby for Distributed Storage System、Satoshi Tagomori Pattern Matching in Ruby 、 Yuki Torii Memory Fragmentation and Bloat in Ruby 、Nate Berkopec Busting Performance Bottlenecks: Improving Boot Time by 60%、Julian Nadeau How to write synchronization mechanisms for Fiber、Masatoshi Seki Towards Ruby 3x3 performance、Vladimir Makarov この日は基調講演は特にありませんでしたが、注目はパフォーマンスに関する トーク でした。 Ruby の GC をどう改善できるか、メ モリー 関連の問題をどう調査・解決できるか、 Ruby をどう3倍早くに改善できるか、違う種類のパフォーマンスの問題についていろんな トーク があって、基礎知識としても実践力としても役に立ちました。 この前、 Ruby の作者が設定した Ruby 3x3 という目的は、設定されただけで実際にそれを簡単に実現できるのかどうかは個人的には少し疑問に思ってたのですが、最後の トーク でそれを実現できそうなプロジェクトを紹介してくださった方が現れて、そんなに遠い未来じゃないと思うようになりました。 面白い演説で聴衆の笑いを集めた閉会の辞の後、お土産を買って、無事に東京に帰りました。 今回会社で広島までこれたのは私達二人だけでしたが、得てきた知識を東京に残った他のエンジニアに共有する予定です。 終わりに イベントが多い出張でしたが、RubyKaigi に参加できてよかったです。 新しい基礎知識と Ruby コミュニ ティー に関する知識を積めて、勉強になったカンファレンスでした。 Ruby 言語のカンファレンスに参加するのはこれで初めてでしたが、 Ruby に限らずこれからも他に多くある プログラミング言語 を中心にしたカンファレンスに参加したいと思います。 今まで実際に参加してきたのは、大学で開催されたカンファレンスだけであって、それ以外の トーク はすべてビデオで見てきましたが、前の私と同じく、まだカンファレンスに出席したことがない方に出席をおすすめします。一度やってみたら、中々やめられなくなってしまうかもしれません。

こんにちは。エンジニアの山本です。 5/23に開催された、 【 ヒカ☆ラボ 】大規模サービスがリスクをとってまでモダンな開発環境にリプレイスした理由～ここだけの苦労話や手法を交えお話します～  というイベントに参加 & 登壇してまいりましたのでレポートします。 今回のイベントのテーマは レガシー改善 という、長年継続しているサービスでは避けては通れないものでした。 弊社のサービスである BUYMA もローンチから10年以上経ち、溜まりに溜まった技術的負債を日々返済しています。 Reactを導入した話 弊社からは2人登壇させて頂きまして、私、山本は "React導入時の苦労話とこれからについて" と題しまして、ある機能のリプレイスプロジェクトでReactを導入した話をしました。 既に デファクト・スタンダード になったと言えるReactですが、導入当時の一年前は大規模なサービスに導入したという事例もまだ少なく、如何にして非SPAな Webサービス にReact/Reduxをマッチさせるかという点でとても苦労しました。 当時の苦労話を共有することで、少しでもこれから大規模サービスにReactや他の JavaScript フレームワーク を導入しようとしている方々のお役に立てればと思います。 こちらが発表資料です。 商品検索を改善した話 木村の方は、 " BUYMA の商品検索システムの改善の取り組み" というテーマでした。バイマの商品検索システムをSolrCloudへリプレースし、耐障害性を向上させた取り組みについてや、レガシーな検索ロジックを、BigQueryなどを駆使しながら数値で検索精度を計測しつつ、新しいロジックへと改善していく取り組みについてお話しました。 発表資料はこちらです。 BUYMAの商品検索システムの改善の取り組み from 慎太郎 木村 当日の様子 木村 山本 質疑応答時 まとめ 一緒に登壇させて頂いたJapanTaxiさん、 一休さん のお話も非常に共感できるところが多く、また今回は最近開催されたヒカ☆ラボの中でも来場者数は多かったようで、"みんなレガシー改善に苦労しているんだなぁ"としみじみ感じました。 新しい技術がどんどん生まれる中、如何にして技術的負債を返済してくかはこれからますます重要になってくると思います。 みなさんもガンガン知見を共有して共にレガシーと戦っていきましょう。

エニグモ でWEBエンジニアをやっております、大宮です。 今回は、先日英語版 BUYMA で行った、AMP対応についてまとめた記事をお届けしたいと思います。 そもそもAMPとは？ Acceralated Mobile Pages の略です。 その名称が示す通り、モバイル端末で高速なWebページを表示させるためのプロジェクト、またはそのための フレームワーク (AMP HTML)の事です。 フレームワーク は Google と Twitter により共同開発されています。2016年の2月にローンチされて以降、AMP対応を行っている企業は増え続けています。 Google からは今のところは明言されていませんが、メインの開発に Google が入っているということで、いずれ SEO の上位表示に影響してくるのではないかという予測も立てられているようです。 現に、一部の記事ページでは スマホ で検索するとカ ルーセル で検索結果の上位に表示されます。 近年は 新興国 でも スマホ 文化が普及する一方、回線速度の遅さが問題視されることもあり、AMPはこうした時代の流れにも対応したものと思われます。 国内を見ても 格安SIM や通信容量制限による低速化などにより、WEBページの体感速度の向上はますます重要な要素になってきています。 ページが速く表示されるだけユーザーの満足度は向上するというのは、想像に難しくないでしょう。 実際に見てみましょう 実際に対応された英語版 BUYMA のサイトを見てみましょう。 AMP未対応のページ（ベンチマーク計測：11.5秒） AMP対応のページ（ベンチマーク計測：3.5秒） AMP対応のページをキャッシュしたAMP Projectページ（ベンチマーク計測：0.76秒） ベンチマーク は低速な回線で撮ったものです。 体感でも表示速度が一番下のキャッシュ速度が速い事がわかるかと思います。 なお、上記AMPのページはPC版で見ると崩れているように見えますが、 CSS をモバイルに最適化した(PC対応の CSS を排除した)結果です。後述する実装でAMPを別URLとした場合、AMPのページがPCからみられることはありませんのでOKとしています。 なぜ速いのか？ AMP対応のHTMLは読み込みが非常に速いです。その理由を見てみましょう。 - AMPでは、非同期のAMP専用JSしか使用出来ない。 - CSS のサイズ制限＋外部ファイルに置く事を禁止している - 画像のLazy Load＋幅高さ指定の強制でブラウザの負荷を軽減 特に一番大きいのは最後のLazy Loadでしょう。 通常 Webブラウザ はページの表示時でページ内のすべての画像を読み込もうとしますが、AMPでは表示領域のみ非同期で画像をロードしてきています。 それを可能にしているのが <amp-img />タグ です。ampページでは通常の<img />タグは使用できず、すべてこちらに置き換える必要があります。 また、 CSS のサイズ制限があるので、リッチなコンテンツの量は増やしづらく、AMPページとしては余分なモジュールを削りおとすことになり、全体として読み込むファイルサイズが軽減されやすいということです。 さらに、これらのHTMLは、 AMP-Projectの CDN サーバーにキャッシュされ、検索結果での表示時にはキャッシュされたページを表示するようになります。 このキャッシュ時に、画像もモバイル用に圧縮をし、ファイルサイズを軽減しています。 さらに検索結果の表示時には、ユーザーが見ている検索結果の部分で、裏側でPreconnect / Prerenderingが走っています。 ユーザーが検索結果からページにアクセスしようとしてタップした時には、すでに裏側でページが読み込まれているため、ユーザー体験としては爆速に感じるということです。 AMPの三大制約 AMPを実装するにあたって、設計の段階で留意すべき制約は３つあります。 - JSが使えない* - CSS は50KBまで - Cookie が使えない ということ。言い換えれば リッチなページは作れません。 ログインユーザーに応じて出しわけ...などの機能は使えません。 ということです。 JSが使えないというのは、自前のJSは一切使用不可ということで、JSでよく使用される機能について、ある程度はAMP-Projectの方で用意されています。 例えば、サイドバー、カ ルーセル 、フォームのバリデーション等。詳細は 公式のこちらのページ に記載されています。 また、JSに関しては、2017年6月現在、 amp-bind という機能が開発中です。 リリースされればJSで自前の スクリプト を書いた時ある程度は同じような挙動を実現できるようになります。 具体的には、イベントトリガーでclassやInnerText, attributesの値を動的に変更するということが可能になります。 が、それでも既存のJSの流用はできないため、amp-bind用に書き直す必要があります。 URL方式の設計 まずは上述のように、できることとできないことをただしく把握する必要があります。 基本的に上の項目を把握されていれば問題はありません。 次に、AMP用に新規URLを作るのか、既存ページをAMP化させるのかを決めます。 モジュールを分けるかわけないかという選択ですね。 可能であれば、メンテナンス性を考えて同一モジュール...つまり今あるページをAMP化し、新規では作らないというアプローチが望ましいです。ただ前述の通り、AMPには制限がありますので、オリジナルページを残したい場合もあるかと思います。 その辺りはページのボリュームと、JS書き直しの 工数 （既存機能への影響）を加味して判断する必要があります。 ちなみに新規でページを作る場合には、最初からAMPに対応したものと作成してしまえば、既存ページへの差し替えで悩むことはなくなります。 画面の設計 基本的にはオリジナルページから何を残して何を削るのかを判断する必要があります。 オリジナルページをそのままAMP化しても、 CSS の容量超え＋JSの リッチコンテンツ で実現可能なものと不可能なものが出ると思います。 なので AMPページの要件として絶対に必須なものを厳選して残し、 CSS 容量や 工数 に余裕があれば別の機能の対応も行う というアプローチが良いでしょう。 実際に開発してみてできること、できないことが分かるという事もあります。 なお、前述の弊社サイト（商品詳細ページ）では、商品情報＋カート購入機能だけを残して、グローバルナビや検索バーといった要素は排除しています。これらの要素はAMPでも代替は可能ではありましたが、 CSS の容量制限の関係で断念した要素でした。 実際にAMPページにしてみる AMP専用の雛形がありますので、ご自身のサイトにあててみましょう。 bodyタグやheadタグや CSS は適宜調整していただければ良いかと思います。 これで、サイトはAMPとして扱われます。 なおAMP用に新規でURLを作る場合には、オリジナルページのHTMLのheadタグ内に下記を記述しましょう。 <link href="AMPページのURL(フルパス)" rel="amphtml"> これで Google にもAMPページが認識されます。 ただし、エラーが出る（多分） Chrome の開発者モードを開きURLの末尾に#development=1とつけましょう。雛形をそのまま使っていない限り、このように大量のエラーとなるはずです。 弊社サイトの対応途中で怒られていた内容としては、主に下記のような内容です。 img -> amp-imgに変換＋幅・高さ指定してください scriptタグの使用してる所を全部削除してください a href=" javascript :void(0);"など css をインラインで読み込みしてください css のファイルサイズを削減してください このエラーを解消しないと、 Google からAMPページとして認識されませんので、すべて対応しなければいけません。 根気よく対応していけば、いずれは下記のように「AMP validation successful.」となりますので、頑張って対応しましょう。 WEBアプリケーションの場合はVIEWにIF文があることも多々あるので、当然ながらその条件分岐は全パターンみておく必要があります。 晴れてエラーがでなくなれば、本番環境にデプロイして、完了となります。 この時本番環境でしか動いてない監視用のJSなどがあると、またエラーになってしまいますので、注意深く観察しましょう。 終わりに AMPはそれなりに 工数 もかかる上に、完成する画面としては真新しいものではありません。 むしろ既存の画面より機能が削ぎ落とされたものなので、パッとみた完成品は物足りなさを感じるかもしれません。 なかなか成果のわかりにくい改修ではありますが、実際にAMP対応によって数字の伸びた事例も挙がってきています。 何より低速回線のユーザーにも、快適な挙動のページをお届けするという意味で重要な要因となりますので、ぜひとも導入を検討していただければと思います。 本記事がその際の一助となれば幸いです。

みなさんはじめまして！ BUYMA で iOS アプリのエンジニアを担当している、松本と申します！ 先日6月2日に行われた Repro User Meetup #1 に登壇してまいりましたので、その様子をお伝えします！！ Reproとは？ Reproとはアプリに特化した、アナリティクスツールです。従来のツールと大きく違う点は、ユーザーの行動を 動画で確認 をできる点と リテンション分析・ファネル分析 といった機能によってユーザーの重要な行動を細かくト ラッキング できる点です。詳しくは、 ReproさんのHP をご覧ください 当日の様子 当日はReproを活用されている10社様が登壇され、様々なReproの活用法や成功事例が発表されていました。 各社様の発表内容はコチラから BUYMA でのRepro活用 新規ユーザーにまず継続的にアプリを使用していただくことは、どのアプリにおいても非常に重要な事と言えると思います。 Reproのリテンション分析では、特定のアクションを行ったユーザーのリテンションを測定するといったことも可能であり、今回のRepro User Meetupでは新規ユーザーに対して最も効果的なイベントをどう判断するかという事について発表を行わさせていただきました。 詳しい内容はこちらのスライドをご覧ください！ BUYMAにおけるRepro運用 from Takashi Matsumoto Repro株式会社取締役 CMO の中濱 康広様（中央）と弊社松本（左）と松永（右）

お久しぶりです。アプリケーションエンジニアの木村です。 BUYMA では、この記事を書いている時点で世界中から出品された約155万件の商品が検索可能となっていて、商品検索機能は世界中から自分の欲しい物を探すことを実現する、まさに「世界を買える」を実現するための重要な機能の１つとなっています。今日はそんな BUYMA の検索機能の裏側を支える基盤部分についてご紹介いたします。 BUYMA では検索機能実現のためにはSolrを導入していて、さらにSolrCloudを構成しています。 SolrCloudとは SolrCloud は、高信頼性、耐障害性、拡張性を運用コストを抑えつつ実現するSolrの クラスタリング の仕組みです。紙面の都合上あまりSolrCloudについて詳しく説明できませんが、下記リンクが参考になるのではないでしょうか。 https://cwiki.apache.org/confluence/display/solr/SolrCloud http://www.slideshare.net/kenhirose547/10solr-solr-cloud あまりWeb上に詳説された記事がないので、下の書籍も参考にしつつ構築にとりかかりました。 -『Solr in Action』Trey Grainger-Timothy Potter (2014) Manning Publishing. -『改訂新板 Apache Solr 入門』大谷純-他(2013) 技術評論社 . -『Scaling Apache Solr』Hrishikesh Vijay Karambelkar (2014) Packt Publishing. -『ZooKeeperによる分散システム管理』Flavio Junqueira-Benjamin Reed [著]、中田 秀基 [訳] (2014) オライリー -ジャパン さらに、上の２つ目の本も監修されている ロンウィットさんのトレーニングも受講 しました。最後の本はSolrCloudに組み込まれるZookeeperの本です。 BUYMA でのSolrCloudの構成 BUYMA のでのSolrCloudの構成を表したものが下の図になります。 更新のしくみですが、Solrを更新するバッチが常に動いていて、DBから更新がかかった商品情報を取得し、leaderのSolrノードへ更新リク エス トを送ります。するとSolrCloudの仕組みとして、leaderノードが他のreplicaノードへ更新を伝えて全ノードが更新されます。 検索は Rails のWebサーバーから直接SolrCloud内のSolrノードへリク エス トします。特に ロードバランサー 用のサーバー等は挟まず、SolrノードのIPをランダムに選び、そのIPへリク エス トを飛ばすように、 Rails アプリ側でロードバランシングしています。 耐障害性への取り組み Rails のWebサーバーから直接SolrノードのIPへ検索リク エス トが飛びますが、各Solrノードの IPアドレス はそれらを監視しているZookeeperから取得しています。したがって、いずれかのSolrノードで障害が起こった場合でもそれをZookeeperが感知し、リク エス ト可能なIPの一覧からダウンノードのIPを外してくれ、ダウン中や リカバリ 中のノードへは常にリク エス トが振られない仕組みになっています。 更新時も更新バッチがZookeeperからleaderであるSolrノードのIPを取得し、それに対して更新リク エス トを飛ばしています。もしleaderノードで障害が発生し、フェールオーバーして別のノードがleaderとなった場合でも、Zookeeperがそれを感知して更新バッチ側へleaderの変更が伝わる仕組みです。 実は、Zookeeperと連携してそこらへんの面倒な処理をやってくれる SolrJ というSolrCloudにも対応した Java 用のSolrクライアントがあるので、 JVM のWebアプリではそれを使ったり、そうでない場合はSolrJを使った API サーバーを検索クライアントとSolrとの間に挟む構成が通常なんだそうです。ただ、そのためのサーバーの運用保守もコストなので、 Ruby からZookeeperと連携するSolrCloud用の Ruby クライアントを自分たちで作りました。gemとして公開していますので、ご自由にお使いいただいてフィードバック等をお待ちしております。 https://github.com/enigmo/rsolr-cloud BUYMA の検索基盤クロニクル BUYMA がシステム面で今の形に近いものに生まれ変わったのは2008年ごろ（らしいの）ですが、その当時公開されていたSolr 1.3系の時代から検索機能にはSolrが導入されていました。その後2011年に3.x系へとバージョンアップがなされ、2015年6月まで稼働していましたが、商品数の増加とマスキャンペーンにより大量のアクセスが予想されたため、マシンリプレースと合わせて2015年リリースされた5.x系へとバージョンアップしました。さらに、運用し易さを求めて、構成をSolrCloudとしました。 SolrCloud導入以前は、マスタースレーブ構成でもなく、Solrノードを並列にならべてそれぞれの IPアドレス を更新-検索クライアントとなる全サーバーに固定値で持たせていました。更新バッチは全Solrノードへ同じ更新リク エス トを何度も送る必要があり、１ノードでも更新に失敗すれば検索結果がノードによってズレてしまいました。Solrノードでの障害発生時やメンテナンス時にもそれぞれのサーバーのSolrノードのIPを書き換えてやる必要がありました。商品数やアクセス数の増大に伴って、この先ノード数を増やす場合にこの構成では限界を感じていました。また、仮にマスタースレーブ構成にしたとしても、マスターが単一故障点になってしまったり、障害対応の時の手間は変わらないというのが難点で、マスタースレーブ構成への変更にも二の足を踏んでいました。 SolrCloudはそういった煩雑さから開放してくれ、まさに自分たちにとっては渡りに船でした。結果、 スキーマ 変更や設定ファイルのチューニング、ノードの障害発生時の対応やメンテナンスが圧倒的にやりやすくなりました。マシンリプレースの効果もありますが、パフォーマンスも、導入前より向上しました。 今後 Solrのバージョンが3.xから5.xとなり、機能面でも新たに使えるものが増えたので、 BUYMA の検索の機能面としても向上していければと思います。

はじめましてデザイナーの篠原です。 ECサイト のデザイナーならではのトピックをお伝え出来ればと思います。 はじめに私の担当は主に運営しているサービス「 BUYMA 」に関してのデザインになります。 「 BUYMA 」でのデザイン業務は大きくわけて、 1.トレンドと連動したキャンペーンページやバナーの作成 2.機能改善・新規開発に伴うページやUIの作成 になります。 細かく分類すると他にもありますが、大きく分けるとこんな感じだと思います。 今回は「トレンドと連動したキャンペーンページの作成」時に気をつけている事を、順序立てて書いていければと思います。 ざっとページ作成の流れはこんな感じ STEP1「構成」 STEP2「 ヒアリ ング」 STEP3「デザインイメージを探す、集める」 STEP4「デザインを考える (頭の中で)」 STEP5「プロトタイピング→デザイン(グラフィックソフトを使ったデザイン)」 STEP6「コーディング」 STEP7「ブラッシュアップ(もうひと頑張り)」 STEP8「公開」 STEPを通して、それぞれどんな事を考えているのかを書いてみようと思います。 STEP1「構成」 BUYMA では日頃からトレンドをウォッチしているMD担当のスタッフがいるので、 企画概要やデザインへ盛り込む要素などは、そのスタッフがあらかじめ決めることが多いです。 企画の規模によっては最初からデザイナーも入り共に構成を考えたりもします。 キャンペーンページでは特に売れ筋や定番人気の商品を BUYMA としてどう見せていくかを意識して考えていきます。 STEP2「 ヒアリ ング」 前STEPとほぼ同時の事は多いのですが、あらかじめ構成をもらっている場合にはこの段階で、 「テーマ」「ターゲット」「トレンド」「企画を考えた時に感じた事」「データからのユーザー分析」「スケジュール」 あたりをしっかり ヒアリ ングします。 内容を整理しデザイン面で懸念があればしっかり認識合わせをしておきます。 STEP3「デザインイメージを探す、集める」 ヒアリ ングで得たものから、同じテーマのデザインをネットで集めたり、 過去の経験から似たようなイメージを引っ張りだしたりします。 色が似ているとかフォントが似ているとか、なんでもヒットしたものを探して、 イメージを広げていきます。 印刷して実際にデスク上にバラバラと広げたり、 ホワイトボードとかにぺたぺた貼っていくとかも良いと思います。 企画を聞いてから色々と探してもいいのですが、 やはり普段から準備しておく事でスピードアップできます。 私の場合はとにかく「パッと見」でたくさんのものを見ておくことを大切にしています。 断片で覚えている方がよりクリエイティブな感覚をもたらすからと考えています。 ちなみにこの「パッと見」の際は、こちらのサイトとかよく見ます。 designspiration.net とか pinterest ですね。 BUYMA というサービスは海外との繋がりを楽しむ、または感じてもらうサービスなので、 海外のデザインからインスピレーションを得ることも多いです。 特にファッション性の高い見せ方、トレンドなどは常にチェックしています。 ついでに、ファションだけでなくカルチャー、経済、ゴシップネタまで、ユーザーの取り巻く環境を幅広く把握しておく様に、雑多に情報収集するのも良いデザインに繋がったりすると思います。 STEP4「デザインを考える」 前STEPで集めたものに対して、 「自分だったらこうする」という軸で考えていきます。 自分の審美眼をあてにしながら、色々と感じるままに考えていきます。 自分の関わるサービスに しっかりとした ブランディング がある場合は、「サービスに似合うのは何か」と考えていきます 。 BUYMA だとこちらの方が多いです。 この場合はサービスの審美眼をあてにしながら、という具合でしょうか。 STEP5「プロトタイピング→デザイン(グラフィックソフトを使ったデザイン)」 イメージがある程度まとまったら手を動かしていきます。 徹頭徹尾まとめてからだとうまくいかない事が多いので、ある程度がいいと思います。 アイディアの鮮度を大切に。頭がフレッシュな朝に回して手を動かすのでも良いと思います。 ちなみに手を動かすという事は文字通り手書きじゃなくても良いと思いますが、 イメージを素早く出すのは手書きが良い場合が多いなと感じます。 大事なのはイメージをどんどん頭から出す事 だと思っています、 頭からイメージを出していく事で新たなアイディアが入るスペースが出来るので、 短時間で様々なパターンを出す事が出来ると思います。 そもそもイメージが浮かばない場合はSTEP3に戻ってやり直します。 その後、 デザインが軽くまとまったらプレビューの場を設けます。 注意したいのはこのプレビュー時にデザインが出来上がりすぎている事 です。 意見の入る余地がないものを仕上げてからだと、 デザインへのこだわりが強くなっていて引けなくなっちゃったりしますし、 その思いが伝わって良い意見ももらえなかったりします。。。 なので、批判を恐れずにプレビューする事を心がけると良いと感じます。 方向性を定めてデザイン的に問題ないものが出来たら、 そのデザインに合わせたバナー作成もこのタイミングで行っていきます。 STEP6「コーディング」 ここは分業の場合も多いと思いますが、 僕らはデザイナーがコーディングまで担当する様にしています。 Webデザイナー は、各デ バイス 、ブラウザの特徴を把握し、 特性や利点を活かし、欠点を補うデザインが求められる職業だと考えています。 それはデ バイス 問わず成立するデザインを考えるということでもあると思います。 なので良いデザインをするためにコーディングの知識は必要と考え、極力担当をする様にしています。 また BUYMA ではエンジニアと一緒になってページを作る機会も非常に多いので、 HTMLだけでなく PHP や Ruby についてもデザイナー側に知識がないと厳しい 、 という経緯もあり普段からソースに触れる様にしているのもあります。 STEP7「ブラッシュアップ(もうひと頑張り)」 実際にはこのタイミングなのか、もしくは途中のタイミングでもあり得ますが、ページ公開に向けてブラッシュアップをしていきます。 ここで良く考えるのは(というより言い聞かす様にしているのは)、 ここまで試行錯誤しながら作ったものであろうが、今の完成度は80%だと思う事 です。 UI作成の場合はこの時点では改悪しないものが出来た、と思う様にしています。 誤解を恐れずに書くと、 ブランディング を考慮し、トンマナを守った上で出来たものはまだ完成度が80%程度なのだと思います。 ここからどこまでやるかは周りの反応だったり、それこそ個人の感覚が大きいと思いますが、 人を感動させるもの、気持ちを動かすもの、UIにおいての改善と呼べるレベルのものは、 ここからのブラッシュアップによって達成出来るものと考えています。 STEP8 「公開」 BUYMA では各担当者から公開依頼を一度システム管理者へ回します、 そこでサイトにクリティカルな問題がないかを確認した上で公開されます。 公開されたらもう一度自分が考えたデザインになっているかサイト上で確認を行い完了となります。 ページ公開後は、 良い反応があるかどうかをGAなどでチェックしたり、 実際にインタビューしたりなど、効果を追っていく流れになりますが、 こちらは担当Dirから共有してもらう事が多いので、デザイン作成としてはここで一旦完了となります。 という事で、だいぶ文字ばかりになってしまいましたが、 以上がデザインが出来るまでの基本的な流れです。 この様な基本となる流れを「素早く」「精度高く」こなす事で余裕が生まれ、 よりクリエイティブなキャンペーンページのデザインが出来る様になると思います。 最後になりますが、たまに休憩を取る事も大切なので、時折コーヒータイムでも挟みましょうね。 ではでは、良いデザイナーライフを。

はじめまして。エンジニアの小金澤です。 つい最近、類似画像検索という言葉がふと耳に入ってきたので、調査してみました。 意外と参考となる記事が少なかったので（というか...小難しい記事ばかりでした）、纏めるのに少々苦労しましたが、最終的には技術的検証まで行いたいと思います。 概要 画像検索には、TBIRとCBIRがあるらしい。 そしてTBIRとCBIRの両方を用いて画像検索を行うものがあるらしい... また、この２つ、TBIRとCBIR両方を用いて検索する方法が最も目的の画像を抽出することができる...らしい...... ということで本当に類似検索できるのか、まずは簡単そうな??CBIRについて調査・検証してみたいと思います。 また、軽くTBIRにも触れていきます。 1. 類似画像検索ついて TBIR (Text-Based Image Retrieval) 主にテキスト情報と画像を紐付けて画像を検索する手法のこと。つまり画像に対してテキスト情報を付け加えて情報を保持する必要がある。 CBIR（Content Based Image Retrieval） 画像の形状特徴や色特徴を基に類似する画像を分類し検索を行う。  2. 検索 アルゴリズム Earth Mover's Distance (EMD) 2つ ユークリッド 距離（ ヒストグラム ）を距離尺度を計算する。 EMDとは、A画像とB画像が持つ2次元 ユークリッド 距離（画像なので2次元としました。）比較しその距離間を計算します。 もっと簡単にちょー分かりやすくいうと、画像の特徴をハッシュ化しお互いの ハッシュ値 を比較する。※大分語弊ありありですが... また、特徴としては、画像を決められたY/X座標毎に分割し、分割した画像の ヒストグラム を計算しハッシュ化します。 そして分割したハッシュの総和を比較するというわけです。 ※ 画像に紐付いたテキスト情報も含めて、計算することもできるらしい。TBIR/CBIR２つの情報を元に計算することも可能。 Histogram Intersection 色の類似度を計算する アルゴリズム 。 こちらは、EMDに比べもう少しわかりやすいものとなってます。 色の比較です。単純ですね。赤（R）、緑（G)、青（B）の各成分が画像中に何 ピクセル あるかを計算し、比較するというものです。 Average Hash(aHash) Perceptual Hashを使い計算する アルゴリズム Perceptual Hashの生成方法は以下のとおりです。 画像のリサイズする（8x8=64ビット/16×16=256ビット） 色を削減する（グレースケールに変換） ピクセル 毎の色の平均値を算出 ハッシュを構築（各 ピクセル 毎に平均値以下か以上かを設定しハッシュ化する） 以下、この アルゴリズム の作成者（Dr. Neal Krawetz）のブログです。 http://www.hackerfactor.com/blog/index.php?/archives/432-Looks-Like-It.html 本格的なPerceptive Hash(pHash)を使って計算する場合は、離散コサイン変換(DCT)をする必要があり、また、コストがとても高い（重い）ため、現在は、Average Hashが話題になっているようです。  3. 次回予告 次回は、このAverage Hashを使い実際に以下のGemと画像を使い Ruby で検証していきたいと思います Gem github.com 画像      最終目標 aHashより算出した ハッシュ値 をDBへ保存 フロントから入力された画像のaHashより ハッシュ値 を算出 DBにある画像 ハッシュ値 と入力画像の ハッシュ値 を比較し類似画像を抽出!! 乞うご期待!!!

はじめまして、エンジニアの高松です。 今回は先日リリースした、「色・サイズ改修」でのフロントエンド開発についてお話したいと思います。 概要 「色・サイズ改修」は、主に以下を目的としたプロジェクトです。 購入可能な色やサイズが、ひと目で分かるようにする 次期リリースで、色とサイズを選択して購入できるようにすることで、誤注文を減らす 商品の色・サイズのデータを蓄積し、運営に活かす リリース時のお知らせが こちら です。 BUYMA はC2Cのショッピングサイトなので、改修は大きく出品側と購入側に分かれます。 開発は私と部長の2人体制、さらにデザイナーのチームで制作しました。 私: 出品側開発 部長: 購入側開発 デザイナー: 全般的なデザイン 開発の始まり 部長が先行して開発した部分を引き継ぐことから、開発は始まりました。 引き継いだのは、500行ほどの JavaScript でした。 検討中の画面の仕様と併せて見ると、動的な制御の多いポップアップ画面のコードの一部です。 $と_の量が多い事と、「ここは Ajax で取ってくるか?」というコメントが気になりましたが、続きを書き始めました。 行き詰まり 少しずつ画面が動き始め、行数にして1300行を超えた頃でしょうか、開発が日に日に辛くなってきました。 ちょっとした修正にも時間がかかり、どこかを直せば、どこかが壊れます。 私(と部長)の書いたコードが読みづらく、 子泣きじじい のように重くのしかかってくるのです。 「このまま作りきれるのか...」不安が募ってきたところで、一度書いたコードを捨て、Backbone.jsで書きなおすことを決めました。 一部ですが、既に BUYMA の中にはBackbone.jsで書かれた部分があったのが理由です。 Backbone.jsの導入 結果、Backbone.jsを使って書き直したコードは、以前よりずっと可読性が高いものに生まれ変わりました。 開発で使ったのは、View・Collection・Modelといった、Backbone.jsのベーシックな部分で、 ルーター などの機能は使っていません。 テンプレートエンジンには、 Handlebars.js を使いました。 Backbone.jsを利用して得られた、主なメリットは以下の部分です。 Viewとロジックが分離でき、イベントも所定の場所に書くので、処理が追いやすくなった。 CollectionがUnderscore.jsをラップしていて、使いやすい。eachやmapなどのコレクション系のメソッドや、findなどのファインダーメソッドが Ruby ・ Rails ライクで馴染みやすかった。 フレームワーク としてコンパクトで、学習コストは低かった。 結果として、ロジックの実装に集中できるようになったのが、一番のメリット。 逆にハマった部分です。 Backbone.jsのViewをappendすると、空のタグが入る。 jQuery のappendと、Backbone.jsのView::setElementを使い分ける必要がありました。 Viewが GC に入らず メモリリーク する。いわゆるゾンビビュー問題です。 ここは、ノウハウを貯めていかないといけないですね。 API だいぶ調子が出てきたタイミングで、部長と立ち話がてら、実装の話をしました。 部長: 「 API って Rails だよね?」 私: 「いえ、出品側は既存もあるので、全部 PHP でやってます。」 部長: 「いや、新規 API だから Rails で書けるじゃん。」 私: 「へっ???」 そうです、「ここは Ajax で取ってくるか?」のコメントを動かすために、 API を3本作りました。 以前の 部長のポスト に記載がありますが、 BUYMA のコードは少しずつ PHP から Rails に移行しています。 API は独立して作りやすいので、 Rails で書くのが社内では定石になっているのです。 新規でレガシーコードを増やしてしまいました、すみません... まとめ Backbone.jsの導入で、フロントエンド開発は随分捗りましたが、まだ課題は残ります。 共 通化 できる部分はexport、requireして読み込みたい サーバ側のModelとBackbone.jsのModelがほぼ一緒になるので、重複をなくしたい View -> Model、Model -> Viewの双方向のやりとりを多く書かなければいけない。 フロントエンドもテストが必要じゃないか? そうです、どれも最近のライブラリや フレームワーク が解決しようとしている問題ばかりです。 モダンなツールを導入して、解決していきたいですね。

Fluentdによるログ可視化が話題になってからだいぶ経ちますが、 エニグモ でも(念願の)ログの可視化を本番投入しましたのでその内容を紹介したいと思います。(完全系ではないですが、実用段階です！) 主な使用技術 Fluentd Elasticsearch Kibana AWS 構成図 構成の説明 各WEBサーバーが出力したログをFluentdが拾ってログ集約サーバーに転送、ログ集約サーバーが AWS にたてたElasticsearchサーバーにデータをPOSTするオーソドックスな構成となっています。 Kibana またログの可視化ツールではKibanaを使ってます。 Kibana4を使ってますが、Kibana3より格段に分かりやすくて気に入っています。 細かい話 使用しているFluentdのPlugin fluent-plugin-elasticsearch データをElasticsearchに送るため fluent-plugin-record-reformer ログを加工をするため 使用しているElasticsaerchのPlugin elasticsearch-cloud-aws AWS のEC2にElasticsearchをインストールして クラスタ 構成を組む場合、EC2 インスタンス 同士で通信しないといけないが、それを設定すれば簡単にやってくれる プラグイン 。あとS3へのSnapshotをとる機能のために使っている。 elasticsearch-head Elasticsearchを管理するための プラグイン 。一番良く使う。 elasticsearch-kopf 同じくElasticsearchを管理するための プラグイン 。TOPページで、"heap","disk","cpu"の使用率が横棒グラフで見れるのでそれは重宝しているが、他の用途には使っていない。。 Elasticsaerchの スキーマ 設定 Mapping Templateを使ってフィールドのデータ型や要素解析などを指定しています。 Elasticsaerchの定期的なSnapshotの作成/削除、定期的なIndexの削除 curator という大変便利なツールがあるので、 それを使って、Elasticsaerchの定期的なSnapshotの作成/削除、定期的なIndexの削除をおこなってます。 ログ可視化をして捗ったこと 平均レスポンスタイムの分析が容易。 レスポンスタイムが悪いURLが分かる。 端末別(PC or スマホ or タブレット or ガラケー )のアクセス数が把握が容易。 時間ごとの HTTPステータスコード の割合。 特定の時間だけ500が多いとかが分かる。 ある会員がどの画面遷移をしたかがすぐに分かる。 障害調査が素早くできる。特にこれまでは数十台のWebサーバーのログを grep していたので結果がでるまで何十秒もかかっていました。 等など 最後に 昔はログファイルを grep & AWK で頑張って解析していたのが、今は lucene queryでサクッと特定が出来ますし、遅い画面の集計や ステータスコード の集計も簡単にできるようになりました。 今後はもっとログ可視化システムを強化してもっと便利にしていきたいと思います。

こんにちは。 エンジニアの木村です。先日行われました ECNight#1 に参加しました。 発表しました。 ああいった場で発表するのは初めてで、発表順はくじで決まってまさかのトップバッターでしたが、時間も１０分ということでちょうど良かったです。 発表資料ですが、当日のものをよりスライドだけで伝わるように改変してあります。 迷っている人を後押ししてCVRを上げる from 慎太郎 木村 かなりユルい感じの、しかも上手く行かなかった取り組みについての発表でしたが、発表中の皆さんのいいリアクションを見たり、 Twitter 上や後の懇親会で良いコメントをいただけたりすると、発表しといてよかったなと思いました。勉強会マジックかもしれませんが。 この発表で少しでも社内の雰囲気が伝わればと思いますが、もちろん、もっとしっかりした取り組みもやってますということを申し上げときます。 感想 ライトな感じのイベントだったとは思うのですが、その中でも物流や決済についてのコアな話、ファッションECの歴史についての発表もあり、自身の仕事に直に関わるテーマばかりで、割と得るものが密に詰まったイベントでした。 懇親会も同じような悩みを持つ同業者間でア イデア やノウハウを共有できた貴重な機会でした。 それから、過去の 大川さんの記事 の最後も同じようなことを言っていますが、勉強会ドリブンというか、そういった気持で日々の開発に取り組もうという気持ちになりました。

こんにちは、デザイナーの 細田 です。 ECサイト のデザインにおいても、バナー制作は欠かせません。 今回は、私がバナーを作る際にいつも意識している「足し算と引き算」について書きたいと思います。 まずはじめに：「ECバナー３箇条」 私がバイマのバナーを作る際に、特に大事にしている３点があります。 通称「ECバナー３箇条」です。（私しか呼んでいませんが） Ⅰ アイテムが魅力的に見える・買いたくなる Ⅱ パッと目をひく Ⅲ しかしずっと見ていても疲れない 商品を売るサイトなので、Ⅰは大前提です。 そして今サイトが一番PRしたいもの＝バナーなので、 しっかりユーザーの目を惹きながらも、（Ⅱ）広告のようなギラギラと押し付けがましい印象にならないよう心がけています。（Ⅲ） バイマは「ファッションサイト」であるため、 “あくまでオシャレ、しかし目を引くバナーで商品をPRする” これを目指すゴールとしています。・・・なかなか難しいですが。 その１：バナーを「背景」「アイテム」「タイトル」の３要素に分ける 私はバナー制作をする際、「背景」「アイテム」「タイトル」の３つに分けて考えます。 通称「バナー３兄弟」です。（こちらも私しか呼んでいませんが） そうする事で、今回のテーマである「足し算と引き算」が行いやすくなります。 といわれても文章だけではイメージしずらいと思いますので、実践編を見てきましょう。 その２：実践してみよう 『背景が派手なバナー』 ジミーチュウの新作紹介バナーを、「華やかなイメージで」という依頼がきました。 指定されたアイテムを見ると、国旗など派手めなものもありつつ、黒や茶など若干ベーシックな印象を受けたので、背景は思い切ってピンクのラメを敷いてみました。 後はタイトルを入れれば完成ですね。 ・・・ 「華やかに、華やかに」と念じながら、タイトルも思いっきりゴージャスにしてみました。 結果、確かに華やかにはなったかもしれませんが、アイテムの印象が薄れ、見ていて疲れてしまいますね・・。 「まずはじめに」で挙げた３箇条で言えば、Ⅰ とⅢ が達成されていません。 これを３兄弟で表すとこうなります。 ここで登場するのが、「足し算と引き算」です。 ずっと見ていて疲れないバナーにするためには、「３兄弟で派手なのは１人だけ」 と私は考えています。 今回はタイトルを引き算してみます。 ・・・ タイトルを黒地にし、ぐっとクールにしてみました。 こうすることでアイテムが引立ち、背景の派手さもほど良く抑えられました。 ３兄弟はこうなります。 ECサイト では、アイテムはディレクターから指定される事が多いと思いますので、残る背景及びタイトルの「派手〜地味」を足し算・引き算していくことになります。 場合にもよりますが、「派手」「中間」「地味」がそれぞれひとつずつ 　というのが いいバランスなのではないかと感じています。 その３：実践してみよう 『アイテムが派手なバナー』 ミッソーニ のコラボバナーの依頼がきました。 ミッソーニ のアイテムはどれもカラフルで派手だったので、背景やタイトルは極力シンプルにしました。 ３兄弟だとこちら。 これでもシンプルで見やすいのですが、パッ見の印象を強くするため、もう ワンメイク してみましょう。 タイトルの色はそのままで、フォントを変えてほんのすこしの華やかさを足しました。 ３兄弟でいえば、タイトルを「地味」から「中間」にするくらいの足し算です。 こちらも、「派手」「中間」「地味」がそれぞれひとつずつ、となりました。 以上が、バナー３兄弟を使用した「足し算引き算」となります。 冒頭に述べた「ECバナー３箇条」 Ⅰ アイテムが魅力的に見える・買いたくなる Ⅱ パッと目をひく Ⅲ しかしずっと見ていても疲れない を達成するために、「なにを足そう、なにを引こう」と考えながらバナー制作をしています。 同じく ECサイト のバナーを制作している方の参考になれば、幸いです。