Translate

2017/01/12

Yahoo JAPAN の無料コワーキングスペース「LODGE」を体感

今のところ無料で使える話題?!のLOGDEを体感してみました。
https://lodge.yahoo.co.jp

LODGEの個人的なメリット:
・コワーキングスペースの選択肢が増える
・無料
・ランチがヘルシーで安い

行き方や詳細はこちらがとても参考になりました。
http://suppon.innovator.jp.net/entry/yahoo-lodge
http://hrnabi.com/2016/09/28/12131/

平日の11時に到着しましたが、席は8割ほど埋まっていて、あまり余裕はない感じでした。
淡々と作業されている方や、打ち合わせをしている方が半々くらいでした。

Wifiのパスワードは出入り口付近にしかないので、メモをとるか、その場で設定する必要がありました。

食堂は、600円前後の予算で、11時くらい〜14時くらいまで開いているようです。
(公式の情報もなく、見たり聞いたりした雰囲気ですので、参考にとどめてください。)
A/Bランチと量り売りブッフェとあって、量り売りを300g/600円でいただきました。
糖質オフしやすくてかなり良かったです。


また、カフェメニューはエスプレッソが300円弱とかなりお値打ちでした。

赤坂という場所が東京の中央で訪れやすいとのことですが、私は生活圏外のためあまり活用の機会は少なそうです。
赤坂近辺で活動されている方は、利用して損はないかと思いました。

Ruby On Rails で、AWS Elasticsearch のプラクティス

前回のTwitterアプリに引き続き、AWS Elasticsearchについても運用レベルのものを開発したので、開発の要点をまとめておきます。

参考:
https://www.elastic.co/guide/index.html
http://ruby-rails.hatenadiary.com/entry/20151018/1445142266#rails-elasticsearch-1-freetext-keyword
http://qiita.com/kyouryu_/items/061b3bc47c1d64b37818
http://easyramble.com/elasticsearch-queries-and-filters.html

やったこと

  • AES(Amazon Elasticsearch Service)を使ったElasticsearch
  • Railsのモデルを、Elasticsearchとして使う
  • RakeタスクでElasticsearchにデータをインポートする

要点

以降詳細を列挙していきますが、特に重要だと思ったポイント:

  • 本家サイトが大事。
    Qiitaとかまとめ記事いろいろあるけど、用語の意味や使い方が曖昧・まちまちなので、混乱しやすい。本家できちんと基礎から数時間かけて理解した方が最終的には速い。
  • いきなりRails使わずにCURLとかでElasticsearchってどういう感じなのかを掴んておくといいと思う。
    自分みたいに、いきなりRailsでmodel 使うGemを使うと、自分のやっていることがわけわからず、とりあえず動いているっていう状況になり、応用きかず設計変更やトラブルで大変になる。


AES(Amazon Elasticsearch Service)を使ったElasticsearch

ドメインの取得、オレゴン
Kibana使いづらい
AWS認証

Railsのモデルを、Elasticsearchとして使う

Gem model
検索
 Index、キーワード、AND、OR、Page、Page size、Aggs、Sort

RakeタスクでElasticsearchにデータをインポートする

Gem client

ソースコード



2016/09/30

流行りのビッグデータをやってみた。

最近、Twitterからツイートを分析するような作業が多かったので、これはデータ分析の入り口として良さそうだったので、勉強・実践してみた。

データ分析とは

この定義もかなりあいまいなようでピンとくる記事が見つからなくて困った。
一番わかりやすかったのはこちらのデータサイエンティストの説明。

以下自分なりにまとめた、作業・ツール。

収集 =>  整形  =>  蓄積 =>  分析・可視化
説明 アクセスログや可視化したい統計データなどをDBなどに保存する。 収集した時に実行する場合と、DB保存後にバッチ処理する場合がある。 データを保存しておく場所。DataWareHouseというらしい。 Visualization。これもリアルタイムでデータを更新していくものと、バッチ的に分析するものがある。
ツール
fluentd
logstach
Apache Spark
Hadoop
自作スクリプト
Apache Spark
Hadoop
自作スクリプト
Elasticsearch
Apache Solr
各DB
AWS S3
Google Drive
ローカル
Kibana
Banana
Jupyter
Rstudio
Data sientist workbench
スプレッドシート 

整形・分析などをサービスとして使えるBIツールというものがあるが、今回は調査できなかった。

今回やってみたこと

やり方はいろいろありすぎて、どれがいいのか分からず。流行りのデータ解析らしく、
Spark + Elasticsearch + Kibana
という割りと情報がありそうなものをやってみた。

参考記事とやった結果:
https://github.com/Samemura/twitter-spark

無事、SparkでデータをElasticsearchに蓄積し、Kibanaで表示できるようにできた。

感想

データ分析の流れを構築できたものの、効果的に分析できる方法は構築できなかった。
このあたりはKibanaでは限界がありそうなので、Jupyterなどで分析する方法を検討したい。
またデータ収集部分は、普段から使っているスクリプトなどでもあまり困らなそうだと感じた。大量のデータをリアルタイムで分析する、まさにビッグデータでなければメリットがなさそう。

アルゴリズムの検討などには、
1.自作スクリプトでデータ収集
2.Jupterなどで詳細分析・可視化
を次のステップとしたい。

2016/06/17

Webサイトの決済に、Amazon Paymentsを実装した。 そうRuby On Railsで。

仕事でAmazon Paymentsを使って決済機能を開発したので、そのまとめ。

まとめ

報告書は最初に結論が大事。ということで、早速まとめ。
  • Amazonが提供しているDocumentやサンプルが豊富でとても助かった。
  • サーバーサイドとフロントエンド(JavaScript)の両方で実装する必要があったので、他の決済と比べると理解に時間がかかった。
  • 仕様はオープンだが、ネットでの実装事例はなくて、完成イメージを持てずに苦労することもあった。
    →この記事がその助けになったら嬉しい。
  • サイトのUXはすごく向上したと思う。個人的にAmazonをよく使っていることもあり、Amazonログイン→支払いはとにかく簡単。
  • Amazon Paymentsのアカウント開設前に、すぐに使えるテスト環境はないため、事前の技術検証がほぼできなかった。Ruby SDKをAPI通信をスタブして、コードはかろうじて動かせた。これが改善されたら、もっと導入するところが増えると思う。他の決済サービスは準備されていることが多いらしい。
    (もちろん、サンドボックス環境はある)
  • 決済サービスってどれを選べばいいの?って決めるまでは全然決められなかった。考えれば考える程、どれでも同じなような。でもとにかくAmazonログインのUXを優先して決めてよかったと思う。Paypal, WebPayとかは導入はいいと思う(事例やドキュメントが多い)けど、UXの向上は見込みないので。

決済機能とは?

有名なのはPaypal、その他にも最近はいろいろあって、結構群雄割拠。

去年くらいまではPaypalっぽい専門の決済サービスが多かったようだが、大手ECサイト(Amazon / 楽天 / Line ?)が参画して、今後はこっちに流れていくような気がする。

理由は、既にアカウント持っている人が多ければ、その人はすぐに支払いができるから。
ユーザーには、決済のUIはあんまり重要じゃないと思う。
また、使っているサービスで支払いできた方が安心感もある。Amazonはそれを謳ってもいる。

Amazon Paymentsって?

って動画を見ても、あんまり理解できないと思う。
要は、Amazonでログインボタン、Amazonでお支払いボタンを自サイトに埋め込んで、Amazonアカウントで支払いができるということ。

決めた理由:
  • UXの向上
    →Amazonでログインは効果があるはず
  • 支払い手数料
    →競合と比較して大体同じ
  • 運営者の使い勝手
    →Amazon Seller Centralという、Amazonマーケットプレイスと同じプラットフォームで、安定
  • 定期支払い
    →会員年会費の支払いに使いたかったので、必須

サービス名がところどころ、Amazon ログイン&ペイメント とかってなっていてよくわからなくなるけど、多分世界的に共通な名称がAmazon Paymentsで、日本のサービス名がAmazon ログイン&ペイメントってことのよう。

大差ないが、APIはログインとペイメントで分かれているので、一応気にしておく必要はある。Ruby SDKは同じような名前のメソッドだけど。

Documentが豊富

amazon.co.jpでは問い合わせしないとDocumentがもらえない(なのでここで公開することは適切でないと思う)
しかし、amazon.comでは普通に公開されているので、こちらを参照するといい。
Forumもあって、質問すれば、1日くらいで回答きた。

実装

動線がすごくわかりにくいけど、こんな素晴らしいモックが用意されていて、これにかなりお世話になった。
使ったRuby SDK(gem)はこちら。

詳細はインテグレーションガイドを参照してもらうとして、概要はこんな感じ。
  1. JS(JavaScript)でログインボタンと支払いボタンを実装。
  2. ボタンを押すと、AmazonのJSがアカウントを認証し、指定したコールバックURLにリダイレクト、クエリパラメータでアクセストークンがついてくる。
  3. アクセストークンを使って、ユーザー情報を取得したり、支払い処理を実行する。
今回は、調べながらで2週間くらいで基本的な実装はできた。
Ruby SDKを使ったモックを自分でも作ったので、参考にしてもらえるとうれしい。
HerokuでPreviewも提供していて(Readme参照)、実際にはログインできないが、Amazonのログインウィンドウが出てくるところまでは見ることができる。

おまけ

Ruby SDKを使わせてもらったけど、日本のサンドボックス環境のEnd pointが間違っていたので、Forkして修正した。よかったら、こちらをどうぞ。

あと、細かいハマりポイントなども、質問されればなるべく回答しますので、お気軽にコメントどうぞ〜

2016/06/13

Elasticsearch をRuby On Railsで。

タイトルのとおり、Elasticsearch をRailsで実装したので、そのまとめ。

やったこと


  1. RakeタスクでcsvなどのファイルからElasticsearchにIndexを作成
  2. 作成したIndexをModelで検索

コア部分のソースコード

https://github.com/Samemura/Elasticsearch-rails-example

解説

だいたいのことは、Githubを見ればわかるので、ここでは検索まわりを中心に紹介する。
今回はAmazon Elasticsearch Service を使ったが、基本はこちらの記事で全てまかなえた。
bool: { term: { 検索対象 => 検索する値 }} 
term を繰り返して、検索対象を追加する。

OR検索

bool: { should: { 検索対象 => 検索する値 }} 
should を繰り返して、検索対象を追加する。

NOT検索

bool: { must_not: {bool: { should: { 検索対象 => 検索する値 }}}
should を繰り返して、検索対象を追加する。

RANGE検索

range: {検索対象: {lte: 値}}
lte は以下。
この時にDateの値の場合は、きちんとフォーマットを定義しないと、範囲チェックできない。
        type: date
        analyzer: standard
        format: yyyy/MM/dd

ページング

{size: 件数},
{from: 開始件数}

ソート

{sort: {ソート対象: desc} }
desc は降順

集計

aggregations: {agg_hits: {terms: { field: 集計対象, size: サイズ } # size = 0 means Integer.MAX_VALUE. https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-terms-aggregation.html#_size
集計結果を取得できる最大件数を指定する。0は無制限。よく使うのはTop10とか。

AWS認証

AWSのIAM認証でアクセスしたい場合は、こちらのGemを使えば簡単にできた。意外と情報は少なかったので、ハマった。