CASHで錬金術を行う

一瞬で査定して買い取ってくれるサービス、CASHがリリースされました。 cash.jp

CASHを利用して、要らないものを買い取ってもらいます。 CASHの査定基準は謎ですが、最高でも2万円、最低でも1000円という基準で値段付けを行っているようです。

対象ブランド品で安いものを出品するとどうなるか試してみました。

用意したのは、ファストファッションで有名なブランド、H&Mのヘアゴムです。 H&Mは安価でファッショナブルな衣類を提供していて非常に利用しやすいブランドです。

ヘアゴムはカラフルでおしゃれなのですが、10個セットで199円という非常に安価に購入できます。

これを1つ出品してみます。 未使用なのでほぼ新品なのですが、☆1で査定してもらっています。（☆5が新品、☆1がキズあり）

写真を取った瞬間に査定が終わるのですが、1000円と値段が付きます。 CASHでは、H&Mのヘアゴムを非常に高価買取してくれます。

どうせなので、一度にまとめて出せる10件を買い取りしてもらいます。

合計で1万円になりました。 CASHが素晴らしいのは、これを即出金できる所です。 ローソンを利用した場合、250円の手数料が引かれますが9750円をすぐに出金できました。

ここまで、20分程度しかかかっていません。 お金に困った時すぐ出金できるのは非常に便利だと思います。

非常に高価なものでも2万円にしかならないとTwitterでは文句を書かれたりしていますが、逆に非常に安価なものでも1000円で買い取ってくれるのは利用者には嬉しいですね。

追記 (2017/06/29)

参考リンク： 年利にしたら90％！自分が持ち物を一瞬でお金に換えるアプリ「CASH」がとてつもなくヤバイ | BUZZAP！（バザップ！）

LINE DEVELOPER DAY 2016に参加してきました

お前、前回の記事は2015に参加してきたじゃねーかという皆様こんばんは。

LINE DEVELOPER DAY 2016に参加するためにヒカリエに行ってきました。 色々なお話を聞いてきたので所感を報告しようと思います。

LINE Bot

公開されたといっても、全然使えなかったLINE Botが今日からわりと使いやすくなりそう。

• Groupに追加可能
• 複数のメッセージタイプが送れる（Confirmとか送れる）

などなど Replyの仕組みもidが付いて単純になったみたい。
Pushでbotからメッセージを送ることもできるがこちらは有料らしい。

LINE Notify

IFTTTや、Github、Mackerelから通知など送ることができるように。 Twitter監視なんかに使うと便利かもしれない。

（普段の開発業務はさすがにまだSlackやPagerdutyのほうが便利そうだし、LINEに送るメリットはすぐ思いつかなかった。

LINE Live

個人的にLINE Liveの話が面白かった。

RTMPで上げて、HLS形式に変換。視聴者にはPushで配信開始を通知して、CDNのcache経由で動画配信を行う。

HLSはCDN有効に使えるんだけど、一つ欠点がある。 携帯回線なので一時切断が多くて、HLSのファイルの更新が行えなくなった場合、新しいファイルは404なのでCDNにcacheされず全ユーザのアクセスがサーバに来てしまう。（404も短時間cacheすればいいんじゃねとかは思った

LINEでは、SUSPEND Eventを送って、ユーザのアクセスをBurst API Serverに対してPollingさせるようにしているらしい。 Burst API Serverに対しては、軽量のAPIで負荷を抑え、戻ってきたらRESTART Eventを送る。

ちなみに終了した番組のチャットのメッセージもHLSと同じような仕組みで、jsonに時系列に保存して参照できるようにしているとのこと。 シンプルに負荷対策できていて良いなという印象だった。

LINE Developer Day 2015 Tokyoに参加してきました。

linedevday.linecorp.com

ヒカリエにてLINEのカンファレンスがあったので参加してきました。 会場全体がちゃんと装飾されていて、お金かかってるなぁというのが第一印象でした。

お土産も頂きました。会場限定のエンジニア向けのスタンプも貰えたので活用していきたいと思います（LGTMなどが入ってる）

発表内容自体は後ほど映像も含めて後ほど公開されるとのことです。

A-1 オープニング

LINEがプラットフォーム化を推し進めていることについての話。

使いやすいスマートフォン向けのメッセージアプリが、あまり無かった頃にリリースされ、スタンプや通話機能の追加もあり爆発的に成長してきたLINE。

今は決済やコマースといったライフに関わる所に力を入れているそうです（実際にここ4ヶ月ぐらいで4つの関連アプリをリリース）。 LINE Payには特に力を入れている模様です。 電子決済はこれからどんどん発展する分野なので期待したいですね。 個人的には家計簿付けるのが苦手なので、買ったもの全てがブラウザから容易に一覧できるような世界が早く来て欲しいです。

「SNSではトップシェアを取るのが大事」と言っていたのが印象的でした。 実際、ユーザーは人が多いところに集まり、2番手3番手は過疎化していく一極集中の傾向があります。 そのためLINEでも、ローカライズをしっかり行い、各国でトップシェアを取っていくことを目指しているそうです。

A-2 LINE Global Culture

開発組織についての話。

世界各国に拠点があり、国を超えてチームを形成しているとの話でした。 実際にグローバルでやる上で苦労した話とかをもっと聞きたかったです。

A-3 LINE Messenger for the World

懇親会などでもわりと話題になってたLINE遠征隊のお話がありました。 LINE遠征隊は、開発者が数名チームとなって、実際に現地に赴いてサービスを使い品質改善を行っていくものです。 日本では高速通信が普及していますが、国によっては通信環境が悪くLINEがまともに使えないといったことがあるため、実際に行って使ってみるというのを大事にしているそうです。 現地の人に聞いて改善といったことも出来ますが、こういうのは現地に行ってその場で調整するというのが一番効率が良いと思うので遠征隊は良い仕組みだなと思います。

調整は、1つの国で行うだけでは駄目で、パキスタン - サウジアラビアやスペイン - 南米といった国を跨いだ通信が多い箇所もあり、そういったことを気にかけながら取り組んでいるそうです。

レビューの解析では、文章内の特定のワードが急激に増えた場合など可視化できるようにしているため、何か問題が発生している場合すぐに分かるようになっていました。便利！

A-4 LINE Platform Development Chronicle

LINEのアーキテクチャの話でした。 この講演がなんだかんだで一番面白かったです。

初期のLINEは、2ヶ月で開発したということもあり、数秒に一度Pollingするという仕組みで作られていたそうです。 ユーザ数が急激に増えていく中、どのように改修しスケールするアーキテクチャにしていったかという発表でした。

FrontendをJavaからErlangに変えたり、HTTPSからSPDYに変更したり、MySQLからHBaseに変えたりと新しい技術をいろいろ取り込みつつもシンプルな構成で解決していました。LINEの技術力が感じられました。 現在、国内だと特にインフラの大きなとこだと思うので、そこらへんの挑戦の話は面白いです。

LINEは全てのサービスをマイクロサービス化しており、新しい人が入ってきてもすぐに業務に取り組めるようになっているそうです。 全体を把握するだけで大変という事例もある中かなり良いと思いました。 （けど、実際はコアの部分がめっちゃデカくなっててそこ把握しないと結局辛いとかないだろうか気になる

A-5 HBaseとRedisを使った100億超/日 メッセージを処理するLINEのストレージ

HBaseとRedisの話。 Redisは実際に自分自身もいろんなとこで使っているので話聞くのが楽しみなセッションでした。

初期の頃は、HBaseに詳しい人も居ないながらも使い始めたことでテーブル設計などで苦労したそうです。 ちゃんと設計していれば数々の問題を回避できたとのことです。 ミスったテーブル設計をしてしまい気軽にALTERとかかけられないので苦労するとかどこにもありそうな事例な気がします。 現在はテーブル設計を変更しているそうです。

redisの採用時もクラスタリングの仕組みが無かったため、sharded redis clusterの仕組みを独自に作成など色々挑戦してます。

DCに入らない問題は半年かけてマイグレーションして移設したとのこと。 物理的に入らないのは辛いですね……。 今後はDCを各地域に分割したいらしいのでまた大変そうな仕事が待っているな…という感じでした。

開発とテスト環境の構築にはDockerを使っているとのこと！ こういう場面が一番Dockerがしっくりする感じがします。 私の会社でも導入していきたいです。

「サービスが拡大するにつれてサーバーは増加されるけど、エンジニアは増加しないのでいろいろな困難があった」が一番悲しいセリフでした(´・ω・｀)

（わりと管理ツールが写ったけど、どこの管理ツールもなんとかストラップっぽい見た目なのは共通でした

A-6 ４年に渡る LINE Android アプリの進化とチャレンジ

初期はAndroid専属デザイナーもいないため、iPhoneの見た目をそのままAndroidに反映するために余計な苦労をしたそうです。 iPhoneっぽい見た目のAndroidアプリ、今もわりとよくある気がします。

Googleのデザインガイドラインをエンジニアが確認してデザイナーに伝えていたそうですが、今はデザイナー自身が確認しているそうです。 デザイナーがデザインガイドライン見てるってすごいとかTwitterで反応がわりとあったのですが、デザイナーならむしろ最初に見て欲しい……

Google Play Serviceが使えない端末などにも対応していて、GCMが使えないため、そういった端末は独自のpush通知の仕組みを使っているとのこと。

私自身、最近Androidエンジニアになったばかりですが、ちゃんとマテリアルデザインを把握して、Androidユーザに使いやすいサービスを提供していきたいと感じました。

A-7 巨大化するスタンプ・着せかえ販売システム、その危機と復活の記録

ナイーブな実装をしており、それを解決するためにredisなどを導入した話。

LINEの着せかえといったQAコスト爆上げする仕組みをどうやって回しているのか気になったのですがそれについての話は特になかったです。

過去は地域やバージョンによって販売商品が区別されており、全ての組み合わせについて販売リストをin-memoryで事前に計算してキャッシュしていたらしい……。 今はそこは外に出しているので各APIサーバで計算したりはしてないとのことでした。

過去はトラフィックが捌ききれなかったので、プロモやイベントをずらしてもらったり分割していたらしい。 LINEは個人がスタンプを販売できるので、それがかなり負荷になっていたそうです（出た時わりとバタバタしてた印象）。

B-5 ビッグデータを活用するための分析プラットフォーム 〜データ集計した先に求められる分析技術〜

すごい分かりやすい発表でした。

エンジニアとプランナーのニーズは違うそうです。

• UIなんてどうでもいい、生のデータに触りたいのがエンジニア
• KPI、きれいなグラフで見たい、Excelダウンロードしたいのがプランナー

LINEでは別々に用意することで対応しているそうです。 プランナー向けのグラフ表示のものは既成品でヒートマップなどがそれなりのコストで手軽に出せるとのことでした。

また、現在はKPIをモニタリングする仕組みを作ってるとのこと。

すべてのKPIのトレンド分析を自動化➔時系列のトレンドを学習して、予測値を算出➔異常値を検出してアラート

KPIを毎日チェックしている人なんて少ないと思うので通知する仕組みは必要だよなぁと思いました。というかうちにも欲しいです。

B-6 ベイズ推定とDeep Learningを使用したレコメンドエンジン開発

スタンプのレコメンデーションの話。 Creators stampが出来て、スタンプ数が急速に増加したため、欲しいスタンプが見つけられるように開発したそうです。

スタンプのレコメンドをどのような手法でやるか説明していました。この分野全然知らなかったのですが、分かりやすい説明で助かりました。

仮定を立てて、それにあわせてレコメンデーションの仕組みを作るとのことで、LINEのスタンプは以下の仮定でレコメンドしているとのことです。

• 好ましいスタンプをよく使う

累計だけを見ると昔に購入したスタンプの影響が残りすぎるので、次のルールでバランスを取る

• 最近購入したスタンプをより好む

実際にレコメンドの仕組みを作ったことで、

• リリース後、ランキング1000位以降の販売数が大きく上昇
• ランキングと比較してレコメンド枠はクリック率が大きく上昇

といった効果が出たそうです。

懇親会

懇親会では、いろいろな話が聞けました。 発表準備が大変だった話や他社の話など。

LINEのAPIはよ公開してくださいとの話に関しては公開する予定はないとのこと…。 まぁそこが一番儲かる所だと思うので仕方ないとは思うのですが、LINEと連携した何かを個人でも作りたいです。

終わりに

LINEさん、素晴らしいカンファレンスをありがとうございました！ エンジニア向けのイベントという感じで、エンジニアの領域に踏み込んだ話が色々聞けて楽しかったです。

GHC 7.8.1 rc1 導入のすゝめ

GHC 7.8.1 のRelease Candidate versionが出ました！ 安定版ではないのですが、積極的に使っていくべきだと思います！

現在の安定版 7.6.3 との大きな違いは IO Manager が改良され、マルチコア環境での並列実行性能が向上しています。 実際に Warp （Haskell のHTTP Server) で計測してみるとこんな値が出ます。

7.6.3 では6コア以降なぜか性能が低下してしまうというおかしな結果になってしまいます。

IO Managerの改良についてはこちらの論文に詳しく書いてあります。

Mio: A High-Performance Multicore IO Manager for GHC

GHC 7.8.1 rc1 のインストール

まず、ここから対応するOSのghcのソースコードを取得します。

http://www.haskell.org/ghc/dist/7.8.1-rc1/

インストールにあたって特に気をつけることはないのですが、glibcの2.15を要求するので、少し古いOSだとインストールできません。

glibcの入れ替えは苦行だと感じたのであまりオススメはしません…何か新しいバージョンのOSを入れるほうが早いと思います。 また、rc2では、glibc 2.13に対応するとのことですので、少し待ってもいいかもしれません。

Cabal

Fedora 19 に GHC 7.8.1 rc1を入れた時いくつかのライブラリのインストールが上手くいきませんでした。 この解決法が正しいのかは分かりませんが、Cabal と cabal-install をgithubから取ってきてインストールすることで問題を回避することができます。

https://github.com/haskell/cabal/

取ってきた後、Cabalのディレクトリで、

$ cabal install

cabal-installのディレクトリで、

$ sh bootstrap.sh

とやることで無事新しいCabalに置き換えることができます。 WarpやYesodが入れられない方はこちらの方法を試してみてください。

Haskellにおける並列実行

Haskellはデフォルトではシングルスレッドで走ります。 並列で動かしたい場合は、プログラムを-threaded付きでコンパイルし、RTSの-Nオプションを付けて実行します。 -Nオプションで指定された数だけ、OSのスレッドが立ち上がり実行されます。

$ ghc -O2 par.hs -threaded
$ ./par +RTS -N2

もちろんこれだけでは、並列に動きません。 並列に実行できるようにプログラムを書く必要があります。

遅延評価

Haskellでは、必要となるまで式の評価が遅延されます。 普段は気にする必要はありませんが、並列実行ではどのように評価されるのか意識する必要があります。 GHCiを使って確認していきます。

Prelude> let x = 1 + 2 :: Int
Prelude> let y = x + 1
Prelude> :sprint x
x = _
Prelude> :sprint y
y = _

_は式が未評価であることを示しています。 Haskellではこの未評価部分をthunkと呼びます。

xとyは評価されていません。 yの値はxに依存しており、yの値を求めるとxの式も評価されます。

Prelude> seq y ()
()
Prelude> :sprint x
x = 3
Prelude> :sprint y
y = 4

WHNF

関数を評価しても完全に値まで評価されるわけではありません。 Haskellは、部分式をなるべく評価せずに済ませます。 seq関数は、一番最初のコンストラクタまで評価し、それ以上は評価を行いません。 これは専門用語で弱頭部正規形(Weak Head Normal Form; WHNF)まで評価すると言います。

Prelude> let xs = map (+1) [1..10] :: [Int]
Prelude> :sprint xs
xs = _
Prelude> seq xs ()
()
Prelude> :sprint xs
xs = _ : _
Prelude> length xs
10
Prelude> :sprint xs
xs = [_,_,_,_,_,_,_,_,_,_]
Prelude> sum xs
65
Prelude> :sprint xs
xs = [2,3,4,5,6,7,8,9,10,11]

完全に評価された式をNormal Formと言います。 Control.DeepSeqを使用することでNormal Formまで評価できます。

Prelude> import Control.DeepSeq
Prelude Control.DeepSeq> let xs = map (+1) [1..10] :: [Int]
Prelude Control.DeepSeq> :sprint xs
xs = _
Prelude Control.DeepSeq> deepseq xs ()
()
Prelude Control.DeepSeq> :sprint xs
xs = [2,3,4,5,6,7,8,9,10,11]

並列処理を実装する際には、Haskellの評価方法に注意を払う必要があります。 並列に動くように処理を分割したとしても値が必要になるまで評価されません。

Eval Monad

Control.Parallel.Strategies モジュールにある、rparおよびrseqを用いて並列処理を記述したいと思います。

data Eval a
instance Monad Eval

runEval :: Eval a -> a

rpar :: a -> Eval a
rseq :: a -> Eval a

rparは、引数が並列処理が可能であることを示します。 rseqは、引数を評価し、結果を待つように示します。

rparも、rseqも評価が行われるのはWHNFまでです。

Eval monadは、評価を実行し、結果を返すrunEval操作を提供しています。

実際に利用方法として2つのパターンを紹介します。

rpar/rpar

単純に並列で動かしたい時に利用します。 即座にreturnされます。

runEval $ do
   a <- rpar (f x)
   b <- rpar (f y)
   return (a,b)

rpar/rseq/rseq

f xおよびf yの結果を待ってからreturnします。 他の処理が結果を必要な時利用します。

runEval $ do
    a <- rpar (f x)
    b <- rseq (f y)
    rseq a
    return (a,b)

Sudoku

数独の例題を実行してみたいと思います。 ソースコードはこちらにあります。 simonmar/parconc-examples

sudoku3.hsを利用します。

import Sudoku
import Control.Exception
import System.Environment
import Control.Parallel.Strategies hiding (parMap)
import Data.Maybe

-- <<main
main :: IO ()
main = do
  [f] <- getArgs
  file <- readFile f

  let puzzles   = lines file
      solutions = runEval (parMap solve puzzles)

  print (length (filter isJust solutions))
-- >>

-- <<parMap
parMap :: (a -> b) -> [a] -> Eval [b]
parMap f [] = return []
parMap f (a:as) = do
   b <- rpar (f a)
   bs <- parMap f as
   return (b:bs)
-- >>

受け取ったファイルを、parMapで並列に実行します。

$ghc -O2 sudoku3.hs -rtsopts -threaded
$ ./sudoku3 sudoku17.1000.txt +RTS -N8 -s

プログラムを-rtsopts付きでコンパイルし、RTSの-sオプションを付けて実行することで統計情報を見ることができます。

実際に実行結果を測定してみます。 Fedora 16, Intel Xeon X5650 * 2で実行しました。

スレッド数	実行時間
-N1	2.11s
-N2	1.16s
-N4	0.60s
-N8	0.36s

2スレッドで1.81倍、4スレッドで3.51倍、8スレッドで5.86倍程度の速度向上が見られます。 大体95%程度の並列化率でしょうか。

rparを利用するだけで、ある程度の並列化率が出ていることが分かります。

今回紹介した、Eval monad以外にも、Haskellの並列化手法にはいくつかあります。 今後紹介していきたいと思います。

参考文献

Parallel and Concurrent Programming in Haskell: Techniques for Multicore and Multithreaded Programming