ZEALS TECH BLOG

チャットボットによる会話広告『fanp』を開発する株式会社ZEALSのテックブログです。技術やエンジニア文化について情報を発信します。

Tried Programming Rust lang[Rustをやってみた!!]

f:id:zeals-engineer:20190209181754p:plain

フルスタックエンジニアのAaronさんがRust言語についての記事を書いてくれました!
(Aaronさんの社員インタビュー記事もよろしければご覧ください!)

www.wantedly.com

Aaronさんは新しい技術への感度がとても高くて、ZEALS内でいち早くRustにも取り組んでくれました。
Rustを触って感じた言語の特長をまとめてくれましたので、Rustに興味のある方はぜひ読んでみてください!

後半では、Aaronさんの書いてくれた文章を日本語訳していますので、英語が苦手な方はそちらをお読み頂けると嬉しいです!

Tried Programming Rust lang

Introduction

This blog post is about typing. Specifically, typing in programming languages and about the concept having (hopefully) a positive impact on my coding style.

Although I am primarily a JS/Ruby developer by trade, I do experiment with other languages and have been looking at the benefits/drawbacks of adopting another lower level language, or even doing something like Typescript on the frontend.

I make games as a hobby. Which led me to programming in Rust, a systems-programming language by Mozilla.

www.rust-lang.org

Yeah, I know you can make games in JS (and it's actually quite fun, check out Pixie JS), but I wanted to make something really fast without all the minor hinderances of programming for a browser.

What I've come back with so far is an appreciation for types.

So what I've noticed is:

1. Compilers are nice

I went through an entire code tutorial with about 300 lines of code and never ran the program once.

I followed along typing and understanding what was happening in the tutorial and before I knew it, the tutorial was over.
It's not necessarily that dangerous in JS, but I had some apprehension about the debugging process that awaited me.

doc.rust-lang.org

But to my surprise, after only a few spelling misses and missing or wrong function parameters the program booted up dutifully and it ran perfectly!
Although one can never be sure about what kind of bugs may lie in the dependencies I downloaded, my code seemed bug free.

It made me think about JS/Ruby, and how I might not see a lot of bugs until I actually test the program.

Yes, I know you can write tests for your code, but the types were like little annotations for all my functions without writing one test.

There were no questions about function arity, no doubts about me putting the wrong kinds of arguments somewhere, I just had a confidence that the program worked.
And that it would work even if another person had edited it.

2. Structs are nice

To me, JS is the ultimate free language, with a huge price that comes with that freedom.

Especially when working in big teams, where people come and go, you can always enforce every single good-practice.
And, to be honest, sometimes it all comes down to style. But having a ton of object literals in your codebase can make things messy, especially when the object literal really ought to be an enforceable structure with some kind of scheme.

By being able to make your own types, you can ensure that an object/hash is made the same way every time.
And new languages like Rust/Golang have these convenient structs that don't force you into making entire class to accomplish that job.

And because, by nature, these structs are like schema, I can be guaranteed that they're used the same way everywhere.
I don't have to consult documentation, or the programmer that wrote it.

Effect on my style

Although I couldn't just make everybody adopt Typescript at work tomorrow, nor do I think I'd want to, I can use some of what I've learned to get the benefits of what I have experienced in my time with Rust.

1. We don't have a JS/Ruby compiler, but we can still program defensively

I can't stop JS/Ruby from getting into the master with a bunch of runtime errors, but I can have my program let others/myself know when they're/I'm using my code incorrectly by making classes which will liberally throw errors when the wrong parameters are passed into the constructor.

They say that "prevention is the best cure" and we can prevent people from using our code outside of the way we expected them to use it, we also prevent them from using it in ways we didn't expect.

2. We don't have structs, but we can try our best when it really counts

I'm not advocating for every JS/Ruby function to manually check the parameters of every function, but when it really counts don't just expect the functions we're using to behave the way we want them to. Important functions that rely on important parameters must check their inputs.

Typed languages will let you know precisely when you're "doing it wrong", but JS will just smile at you nod. An extra if-statement will probably take you 10 seconds to write and save you a lot of headaches in the end.

Closing thought

As web developers, increasingly were sending receiving tons of JSON all the time.
And I can't count the amount of hours I've wasted just debugging payloads to or from servers that don't have the correct stuff in it.

Of course, I love the flexibility that JSON provides, but I think this is one of those parts of web-development that really counts and probably should have a typing/schema.

I would like to experiment more with something like protocol buffers in the future and see if that doesn't relieve some of the headaches, although who knows, by then the next big thing may come along :D

【和訳】Rust言語をやってみた!!

はじめに

今回はコーディングについての記事です!
コードライティングやコーディングスタイルの概念について詳しく書いています。

僕はjavascriptやRubyのエンジニアとしてプログラム開発を行っていますが、他にも色々なプログラミング言語を試していて、低レベル言語やフロントエンドにおけるTypescriptなどのメリットやデメリットを調べたりしています。

Mozillaが提供するプログラミング言語”Rust"を触るきっかけは、僕の趣味が「ゲームを作ること」だったからです!

www.rust-lang.org

普通のjavascriptでゲームを作ること(Pixi.JSとか!)ももちろんできますが、ブラウザ開発にありがちな障害(ファイルシステムにアクセスできなかったり...)がなく、高速でメモリをあまり食わないアプリを作りたかったので、今回Rustに挑戦することにしました。

僕は今回、 ”型”のありがたみ を改めて感じました!
それでは、さっそくご紹介していきます!

気づいたこと

1. コンパイラがすごくイケてます!

今回、僕はチュートリアルで300行くらいのRustのコードを書きました。 チュートリアルの間、途中では一度もプログラムを実行しませんでした。

doc.rust-lang.org

チュートリアルではRustのコードの特徴を理解することに集中しました。
僕はjavascriptではあまり感じないのですが、最後のデバッグに不安を抱いていました...。

しかしデバッグしてみると、驚いたことにタイポや引数を少し間違えていただけで、プログラム全体は正常に起動し問題なく実行されました!
パッケージやライブラリにバグがあるか​​もしれないですが、自分のコード自体にはバグがほとんどなかったのです。

javascriptやRubyを書いていると、プログラムを実際にテストするまで、どれだけ多くのバグがあるかわかりませんでした。

もちろん、テスト駆動開発的に、コードのためにテストを書くことだってできます。
しかしRustの”型”は、テストを書かなくても、すべての関数に小さな注釈があるかのように機能しました。

引数についても、引数の種類が間違っているかを心配することもなくプログラムを書けました。
他の人がRustを書いても、同じようにうまくいくのではないかと思います。

2. 構造体もすごく良い概念です!

javascriptはすごく自由な言語だと僕は考えています。
特に、大規模なチーム開発をするときは、チーム内で良い書き方を習慣づけることもできます。

それらがコーディングスタイルとして定着することもあります。
しかし、コードに大量のオブジェクトリテラルがあると、処理が面倒になることも多いです。

RustやGoには便利な構造体を持っていて、無理にクラスを作らなくても良くなります!
型を作ることで、オブジェクトやハッシュを毎回同じ方法で確実に作ることができます。

doc.rust-jp.rs

これらの構造体は本質的にはスキーマに近く、どこでも確実に同じように使われます。
ドキュメントやそれを書いたプログラマーにいちいち相談する必要はないのです。

コーディングスタイルへの影響

仕事でTypescriptを採用することはしなかったのですが、Rustのメリットの多くを仕事で活かすことができると思います!

1. javascriptやRubyコンパイラはないですが、エラーを防ぎながらコードを書くことができます

javascriptやRubyの実行時にmasterブランチでエラーが出るのを止められないですが、自分のコードが間違った使われ方をされていると、それを教えてくれます。具体的には、間違ったパラメータがコンストラクタに渡されるとエラーをスローしてくれます。

コード自身が「予防が最善の治療法である」ということを教えてくれます。
僕たちは、予想しない方法でコードが使われるのを防ぐことができるのです。

2. 構造体がなくても最善を尽くす

javascriptやRubyの関数でパラメータを手動でチェックすることはあまりオススメできませんが、使用している関数が思ったとおりに動作するとは限りません。
パラメータに依存する重要な機能は、入力された値を確認する必要があると感じました。

型付けされた言語は、間違った値が入力されればそれを教えてくれますが、javascriptならほくそ笑んで終わりです。笑 if文を多用してしまうと、頭を抱えながらコードをなんとか書くことしかできません。

続きを読む

【イベントレポート】『UX Bridge vol.8』に参加してきました!!

f:id:zeals-engineer:20190205220735j:plain
皆さんこんにちは!
ZEALSでサーバサイドエンジニアをやっている福本です!

1月31日に行われました日本有数のUXデザインのコミュニティ『UX Bridge』が主催するイベントに参加してきましたので、そちらの模様をお伝えできればと思います。

uxbridge.connpass.com

参加した経緯として、元々プロダクトマネージャーを兼務していた文脈からUXデザインにはとても興味があり、今後ZEALSではプロダクトの質を高めるために、デザインの領域を今後重視していくためです!

UXデザインの現場のリアルな話をたくさん聞くことができ、とても良い場に参加することができました!UX Bridgeでは定期的にイベントが開催されるそうなので、皆さんもぜひ参加してみてください。

  • 立ち上げ期のSaaSで大事にしているUX
  •  ワイガヤUX
  •  We DESING story. 「伴走」と「共創」のUXデザイン 
    • 最後に 
続きを読む

【エンジニア対談】元トレタCTOの増井さんと語る、ZEALSのチャットボットプロダクト『fanp』のすべて(後編)

f:id:zeals-engineer:20190212115852j:plain

みなさんこんにちは、ZEALSエンジニアの福本です!

こちらの記事は前編に引き続き、ZEALSのプロダクト『fanp』についてのエンジニア対談【後編】です。

後編では「fanpに対する思い」や「今後の展望」などを中心にお話させていただきましたので、その対談の模様をお届け致します。

ちなみに、対談の前編記事はこちらになりますので、合わせてお読みください!

tech.zeals.co.jp

  • どういう思いでfanpを作っているか
    • コミュニケーションへの挑戦とは?
    • チャットボットはビジネスにならない?
  • これからfanpをどうしていきたいか
    • 目指す先は”稼げる”こと?
    • チャットボットのOSSを開発?
    • 必要なのは、信念とマーケティングの合わせ技?
続きを読む

【エンジニア対談】元トレタCTOの増井さんと語る、ZEALSのチャットボットプロダクト『fanp』のすべて(前編)

f:id:zeals-engineer:20190130160336j:plain

みなさんこんにちは、ZEALSエンジニアの福本です!

ZEALSでは、チャットボットによる全く新しい広告体験を提供するプロダクト『fanp』を日々開発しています。

fanp.me

これまでfanpは、マーケティングや広告といったビジネスの視点から語られることが多く、エンジニアリングの視点からはあまり詳細が語られることはありませんでした。

このままでは、fanp開発の面白さをエンジニアの方にお伝えできません...

そこで今回は、テクノロジーお師匠さんとしてZEALSにジョインして頂いている元トレタCTOの増井さんをお招きし、エンジニア目線から見たfanpを対談形式で語らせて頂きました!

一般的なチャットボットプロダクトとの違いや、どんな思いで開発しているか、これから先どういうプロダクトにしていきたいか...

こういった内容について赤裸々にお話させていただきましたので、対談の様子を皆さまにお伝えしていきます!

  • 関係者
  • ZEALSやfanpとの関わり
    • どんなことをやっているのか?
  •  チャットボットと『fanp』の違い
    • チャットボットとWeb開発の違いは?
    • ユーザーを乗せる「ストーリー」とは?
    • ”プッシュ”が嫌われないためには?
  • チャットボット『fanp』を作る難しさ
    • fanpを作る技術的な難しさとは?
    • コミュニケーションを要件化するとは?
    • ”アテンション”を奪い合う?
    • 前編はここまでです

関係者

元トレタ CTO 増井雄一郎

1976年、北海道生まれ。札幌大学経営学部卒業。大学時代に起業。2003年にフリーランスとなり、Ajax、Ruby on Railsなどを使ったWebアプリ開発や執筆を行う。08年に渡米し、中島聡氏とともにアプリ開発会社を立ち上げる。10年に帰国し、Appceleratorの「Titanium Mobile」のテクニカルエバンジェリストとして活躍。2013年に株式会社トレタを創業しCTOを努め、2018年10月に退社し独立。


 株式会社ZEALS CTO 島田想

1994年東京都出身。株式会社ZEALS CTO。同社創業時よりプロダクト開発に携わり、世界初の会話広告サービスfanpを開発。LINEやFacebook社の提供するMessaging API Platformを公開当初より叩き続けており、Facebook MessengerについてはMessaging APIを国内で最も多く叩いているであろう人間の一人。チャットボット以外にも、会話インターフェースであるVUIのアプリ開発にも知見がある。


株式会社ZEALS Product Manager 福本晃之

1992年兵庫県出身。富士通グループでITシステム導入の法人セールスに従事。テクノロジーへの思いを捨てられず、2018年4月に株式会社ZEALSへエンジニアとしてジョイン。PythonとRubyのエンジニアとしてチャットボット開発に携わる。2018年8月より、同社のチャットボットサービス「会話広告 fanp」のプロダクトマネージャーに就任。現在は技術広報やエンジニアの採用にも携わる。

ZEALSやfanpとの関わり

どんなことをやっているのか?

 

福本:fanpの話に入る前に、3人が最近何をやっているのか軽く触れていきます。島田さんは創業時からのZEALSのCTOですが、業務的には何をしていますか?

島田インフラやDBの手直しみたいなことをやっています。これまで速度を重視してクイック&ダーティーに実装してきたので、テーブルのスキーマを修正などをやっています。

増井さん:テーブルやDBの設計周りのイメージ?

島田:はい。ZEALSはモノリシックにRailsをやってきたので、マイクロサービス化できないかを模索していています。
インフラに関しては、トラフィックが今年あたりから急激に増加しました。今後に備えトラフィックが多い部分のサーバレスへの切り出し、マネージドの部分をKubernetes化し等を行い、スケーラビリティを担保していくイメージです。

福本:これまではどんな開発を?

島田これまでは、Facebook MessengerのAPIやLINE のMessaging API が公開された早期のタイミングでプロダクトとして使えるように実装しました。

f:id:zeals-engineer:20190130190359j:plain

福本:ありがとうございます。続いて僕ですが、4月からPythonとRubyのエンジニアをやっています。9月からプロダクトマネージャーも兼務です。
業務としては中長期のプロダクトの計画を作って、その計画を粛々と実行に移す、という役割を担っています。役割の遂行にあたって増井さんに色々と助けて頂いていると。

増井さん:僕は最近、プロダクトの方にすごく興味がある。プロダクトを作る時に、意思決定すべきことがたくさんあって、広い視野でものごとを見て判断するアドバイスをしている。
僕は自分で、「目玉」を提供していると考えている。起業する段階で「それは起業してやるべきなのか?」といった、低レイヤーの話も含めてプロダクトをどうしたいかという話に集中することが多い。

福本:ありがとうございます。

 チャットボットと『fanp』の違い

チャットボットとWeb開発の違いは?

福本:一般的なチャットボットとZEALSのプロダクト『fanp』の違いについて触れていきます。fanpについておさらいすると、世間一般のイメージである「自動お問い合わせ」と少し違っていて、チャット上でユーザーにヒアリングをして会員登録や資料請求などのコンバージョン(以下CV)を生むサービスです。
増井さんは、fanp以外のさまざまなチャットボットにもよく触れているイメージがありますが...

増井さん:僕自身『宮本さん』という勤怠管理のチャットボットを作っていて、 チャットボット自体とても好きでよく作っている。

github.com

僕は昔も今も一日中チャットをやっているので、チャットボットにはずっと興味がある。LINEのAPIが公開されて一番最初にQiitaを書いたのは僕です。

福本:そうなんですか、知りませんでした。

増井さん:他にチャットボットが好きな理由に、 WEB アプリはUI が複雑すぎる。サーバーの知識もWebのHTMLやCSSの知識もJavaScriptやサーバーサイドも必要、さらにDBやサーバー管理といった話も入ってくる。
それに対して、チャットボットは要件が合えばすごくシンプルに物ができる。ユーザーにとってもシンプルだし、作る方にとってもシンプルに作れるイメージ。

福本:チャットのデザインは既にデファクトが決まっています。

増井さん:ただし、自由度はない。僕は自由度がないところが好きで、そういう意味でもチャットボットが好き。

ユーザーを乗せる「ストーリー」とは?

福本島田さんはチャットボットとfanpの違いをどう考えてますか?

島田僕は「fanpにはCVというゴールがある」と考えています。CVとはあくまで僕達の呼び方で、ユーザーからすれば意思決定。例えば、何かを購入するという意思決定のサポートをするという点が、チャットボットとfanpとの大きな違いだと思っています。

福本:確かに、モノを買うとか契約するというのは意思決定です。

増井さん:fanpはストーリー性が強いのではと感じる。シナリオがある中で、ユーザーに”ストーリー”をどう体験してもらうか。ストーリーを作れるか作れないかは、チャットボットのUIUX が上手くいくかの大きな境目だと考えている。
少し説明すると、『宮本さん』を人の名前にしたのはストーリーを考えたから。
勤怠管理で重要なのは「チェックイン」。会社に行くというストーリーをどう考えたときに、「挨拶」をチェックインにした。会社で「おはようございます」と言うのは「出社」のサインで、それを勤怠管理にすればいい。
さらに考えると、チャットボットに対してではなく、人に「おはようございます」と話しかける。そういうストーリーとして使えば違和感がなく勤怠管理ができる。日常生活のストーリーの中に素直に入れられるかに気を遣っていて、「宮本さん」というキャラクターにした。

福本・島田:(うなずきながら同意)

f:id:zeals-engineer:20190130190519j:plain

”プッシュ”が嫌われないためには?

福本「ストーリー」という考え方は面白いですね。僕は配信をどれだけ良いものにするかがfanpにとって大切だと考えています。僕たちは配信を”プッシュ”と呼んでいて、これがあることで、継続的にユーザーと繋がりボットからアクションを起こすことができます。それはLPではできないことで、それをどれだけ突き詰められるかが重要かと。

増井さん:広告が嫌われやすいというのもある。

島田プッシュに関しては、ユーザーにどこまで好まれるかだと思ってます。
モノを買うとき、基本的にはGoogleで検索した方が速いです。ただ、「自分からは検索しないが興味はある」という潜在層の人達に対し、「こういうの見たかった!」という情報をどれだけパーソナライズして届けることができるか。ここが嫌われるかどうかの境目だと思っています。

増井欲しい情報が来る分には別に嫌われない。

島田:シンプルに便利ですからね。

増井さん:そういう意味でプッシュはチューニングしがいがある。

福本優位性ですよね。プログラムを作ってすぐに追いつくものではないので。

チャットボット『fanp』を作る難しさ

f:id:zeals-engineer:20190130190743j:plain

fanpを作る技術的な難しさとは?

福本:島田さんに聞きたいのですが、fanpを作る感じる難しさはどういった部分で感じますか?

島田:これは細かい技術的な話なんですが、APIのデータ形式は基本JSONなので、RDB で持つのが難しい。正規化するのが大変なので。

増井さん:それぞれのJSONに微妙な違いがある。同じようなJSONなのにカラム名が違う、あるいは両面や対面の違いがあるとか。

島田:fanpは管理画面でシナリオを作るので、MessengerとLINEの両方に対応しないといけない。

増井さん:メディアごとに対応が必要なのは難しい。この機能はLINEにはあって、Messengerにはないことが起こり得る。

島田:それ、実際によくあります

増井さん:例えばブラウザ。昔はブラウザ間の差異が大きかったんですが、現状ほとんどない。一方チャットボットは、プラットフォームの表現力の違いがある。ただ、全部使える最低限の機能だけ実装すると表現力が足りなくなってしまう。共通化は本当に難しい。

島田本当に大変で、僕たちも試行錯誤しながら進めています。

増井さん:プラットフォームに依存しますからね。最終決定権がないものを作るのは難しいですよね。

コミュニケーションを要件化するとは?

福本:僕は「 要望がコミュニケーションに紐づいている」という難しさがあると思います。例えば、チャットアプリにはカルーセルという機能があって、情報を並列化して表現するもので、箇条書きに近い役割を持つ機能です。文字って並列の情報を扱うのはすごく難しいので、そういう機能が求められる。

f:id:zeals-engineer:20190201115729p:plain

LINEカルーセル機能のイメージ(https://developers.line.biz/ja/docs/messaging-api/message-types/#carousel-template

増井さん:特にスマホの画面は縦に長いから。

福本:そうです。そういったことを考えながら、使う機能や実装を判断することが難しい。「そもそもコミュニケーションとは」という領域に踏み込まないといけないので。

増井さん:これまでのシステムの難しさは一方向だった。「こういうものを届けたい」という双方向ではなく、プロバイダーからユーザーへの一方通行。
例えば、今までホームページはHTMLで書けばよかった。そこに「コミュニケーションの中でどう気づいてもらうのか」という考えが必要になって、それがこれまでと圧倒的に違う部分。

福本・島田:(同意)

福本デザインと実装が変に切り離されないかというのは大事だと思っていて、両方ともエンジニアで持てるのが理想ですけど、それもなかなか難しい。

”アテンション”を奪い合う?

増井さん:デザインがリッチになればいいかと言うとそうではなくて、今度は人間のアテンション(注目)に限界が出てくる。
コミュニケーションが双方向になるということは、集中して見ないといけないので、ユーザーにアテンションが必要になる。
これはすごく難しくて、双方向のコミュニケーションが増えるとアテンションの奪い合いの話になる。人間は多くのものに集中できないので。
 Netflixについて面白い記事があって、NetFlixの一番の競合は『Fortnite』というアメリカですごく流行っているゲームだそう。
Netflixに使う時間がアメリカで減ってきていて、その代わりにゲームをしている。つまり、Netflixの敵はAmazon Primeではないと。「何を奪い合っているのか」を正確に理解することがすごく大事。

www.polygon.com

福本なるほど。まずは時間の奪い合いがあって、その中でさらにアテンションを奪い合ってるイメージですね。そう考えた場合、今後チャットボットが何と競合するのかを考えることが重要ですね。ひょっとすると、僕たちは全く違う競合を見ているかもしれない。

増井さん:その通り。fanpで会話を面白くすることがアテンションを得ることに繋がるのであれば、ミニドラマとかアニメのようなものがあり得るかもしれない。

福本Netflixがすごいのはゲームが競合だということを理解しているところですね。そういう見極めは難しいはず。

増井さん:そう、それは本当にちゃんと考えないと分からないことなので。

続きを読む

Redash v3.0で使える便利機能まとめ

f:id:zeals-engineer:20190124182957p:plain

みなさんこんにちは、インターン生の久保田と申します!
エンジニアではないのですが、MySQLを使った会話データの分析業務を主に担当しています。

今回は、ZEALSで使っているBIツールの『Redash』の便利な機能についてお伝えしたいと思います!

Redashとは?

redash.io

Redashは、SQLの分析結果をわかりやすく可視化し共有するオープンソースBIツールです。

SQLでクエリを作成することで、データソースからデータ取得をします。
ZEALSでは、KPIなど自分が知りたい情報をすぐに可視化できるために使用していて、日々の事業改善に役立てています。

現在ZEALSではv3.0を使用しているので、v3.0で使用可能な機能をご紹介していきます。

Dashboard

書いたクエリをまとめることができます。
「あのクエリどこあったっけ?」とクエリを探す手間が省けたり、クエリの実行結果を比較することができます。

使い方

事業のKPIをまとめたり、施策ごとの数値をまとめたりする使い方ができます。
自動更新の設定をしておけば、好みのタイミングでの出力数値を毎日管理することもできます。

f:id:zeals-engineer:20190129135457p:plain

VISUALIZATION

クエリの実行結果を可視化・見える化してくれる機能です。
RedashのVISUALIZATIONはそこまで種類が多くないのですが、棒グラフや折れ線グラフなどの基本的なものは作成可能です。

できること

f:id:zeals-engineer:20190129135436p:plain

  • chartで棒グラフ、折れ線グラフを作ることができます。(複数の形を使うことも可能です[図を参照])
  • 円グラフで割合や比率を出すことが可能です
  • 箱ひげ図(Boxplot)や、ピボットテーブル(Pivot Table)などもあるが使い勝手はあまり良くないと感じました
    (Pivot Tableに関してはデータ量が多いと重くなってしまうので注意)

パラメータ機能

クエリ内に {{}} を含めると, クエリにパラメータ(変数)を指定することができます。

これを使うことによって、汎用的なクエリ文を作ることが可能です。
idが変わるたびにクエリを作らずに済み、Redashが整理されます。

使い方

f:id:zeals-engineer:20190129135409p:plain

上記の画像のように {{}} をつけると下にプレースフォルダの入力フォームが出現します。
プレースホルダーに値を入力して実行すると、入力した値がパラメータに反映されます。

{{}} の中身の文字を同じにすればすべて同じ変数と見なされます。
逆に、 {{}} の中身の文字を変えると違う変数として扱われます。

f:id:zeals-engineer:20190124212751p:plain

プレースフォルダ内の入力に関してはいくつかtypeがあります。
プレースフォルダの横の設定を押すと上記の画面が出ますので、参考にしてみてください。

・ Text:自由入力
・ Number:数字を選択できる
・ Dropdown List:これを選択すると自分で選択できる内容を決めることができる
・ Date, Date and Time, Date and Time(with seconds):日付を選択できる

Query Snippets

クエリエディター上でSQL文を書く際に、特定のキーワードに反応して入力をサポートするスニペットを保管してくれます。
これにより、よく使うSQL文を保管しいつでも呼び出すことができるので、作業の効率化が図れます。

f:id:zeals-engineer:20190129141706p:plain

使い方

Triggerを設定して、Snippetに使いたいものを入力します。
クエリ上でTriggerを入力するとスニペットに変換することができます。
画像のように設定すると default という入力が、下のsnippetに入力されてる文章に変換されます。

Queryフィルタ

WHERE句で絞り込んだ結果を、さらに絞りたい場合に使います。

使い方

f:id:zeals-engineer:20190129160511p:plain

SELECT句にas '< columnName >::filter'のように別名をつけると、検索結果のフィルタリングができます。
さらに、filter の部分を multi-filter とすると、複数のフィルタリング条件の選択が可能になります。

その他

  • クエリ結果への HTML 埋め込み機能 → 実行結果に色をつけたり、リンク集をつけることができます
  • Slack通知機能 → SlackにRedashの実行結果を通知させることができます
  • query_< query ID > でRedashの他のクエリのIDを指定することで、他のクエリの実行結果をテーブルのように参照できます

などなど、様々な使い方ができます。

まとめ

ZEALSではビジネスサイドのメンバーが会話のパフォーマンスを確認するため等に使っているツールなので、VISUALIZATIONを使って結果を見やすく出力すると喜んでもらえます。

続きを読む

Facebook Developer Circle ローンチイベントに登壇してきました!

f:id:zeals-engineer:20190128223934j:plain

皆さんこんにちは! ZEALSでサーバサイドエンジニアをやっている福本です!

最近はプロダクトマネージャーや技術広報・エンジニア採用など、色々なことを兼務させてもらっています!

さて、Facebookに関係するエンジニアのコミュニティとして『Facebook Developer Circle』なるものが世界各国に存在するのですが、1月27日に記念すべき東京ローンチイベントが行われました!

splashthat.com

普段MessengerのAPIにお世話になっている関係からイベントで登壇する機会を頂いたので、僕が登壇で話した内容についてお伝えできければと思います!
イベント全体の雰囲気や様子はWantedlyの方で記事を書いておりますので、そちらをご覧ください!

www.wantedly.com

登壇内容『Messenger APIで感じるコミュニケーションの未来』

当日はJR大崎駅の近くにある『TUNNEL TOKYO』さんでイベントを開催しました!
独特な雰囲気のある会場で、イベントは凄く盛り上がりました!

f:id:zeals-engineer:20190128161139j:plain

普段Messenger APIを叩いているからこそ感じる、コミュニケーションの未来について登壇し話をさせて頂きました!
実際に登壇で使用したスライド資料はこちらです!

speakerdeck.com

自己紹介(スライド1~5枚目)

最初に自己紹介を終えた後、僕たちZEALSのプロダクト「会話広告fanp」について少し説明させて頂きました!
チャットボットと聞くと、お問い合わせ窓口の自動化システムとよく勘違いされてしまうので、この辺りは誤解のないように説明させてもらいました!

Facebook Messengerとの関わり(スライド6~8枚目)

ZEALSは2016年にMessenger APIが公開された瞬間から使い出し、おかげさまでプロダクトが大きく成長することができました!

前日にデータ確認のために社内でSQLを叩いて驚いたのですが、fanp上では既に約2200万件の会話がユーザーと行われていました!!
ここまでチャットボット一本でやり切ることができるスタートアップもそう多くないと思いますし、プロダクトの成長を肌で感じる良い機会になりました。

改めてですが、いつもZEALSやfanpを応援してくれている皆さま、本当にありがとうございます!

もっとやりたいこと(スライド9~12枚目)

f:id:zeals-engineer:20190128161511p:plain
ただ、コミュニケーションはテキストや画像、動画のやり取りだけで完結するものではありません。

皆さんも、普段誰かとコミュニケーションを取るとき、もっと細かい情報のやり取りや色々な活動をしているはずです!
僕はボットの上でも同じようにコミュニケーションが取れるべきだと考えています。

例えば、他のプラットフォームでは決済がチャット上でシームレスに完結するようになっていたり、「ミニアプリ」と呼ばれるボットが稼働していて、もはやWebページも必要なくなっていたりします。
各社様々な体験をユーザーに届け、色んなコミュニケーションをボットと取ることを可能にしています!

MessengerもPayment APIが存在しますが、米国の一部のみでの公開で、日本ではまだ使用することができません。
僕たちもプラットフォームに頼らずに自分達で工夫して、最高の体験を日本のユーザーの皆さんに届けたいと思っています!

実現したい世界観(スライド13~15枚目)

f:id:zeals-engineer:20190128161906j:plain
では、チャットボットで多くのコミュニケーションを行うことができるようになると、どのような良いことがあるのでしょうか?
僕は、”インターネット社会の情報格差”をチャットボットによって解消することができるのではないかと考えています!

順を追って説明していきます!

まずは、企業がHPやSNSアカウントを持つのと同じような感覚で、みんなが当たり前にボットを持つようになる世界を作りたいと思っています!

チャットボットは、今はまだおもちゃであると捉えられることがあります。
それは、会社がWebページを作るのと同じレベルまで、「チャットボットを作ること」がまだ選択肢に上がっていないことからそう感じています。

しかし、これまでのテクノロジーの歴史を見れば明らかですが、当初おもちゃだった技術が世界を変えています。
僕たちは、会話広告「fanp」によって機械によるコミュニケーションを当たり前にすることで、チャットボットが世界を変えることができると確信しています。

"検索しなければ、欲しい情報にたどり着けない..."
チャットボットが当たり前の世の中になれば、一方的だったインターネットの世界が一変します。

f:id:zeals-engineer:20190128212023p:plain

インターネットはあらゆる側面で社会に平等をもたらしてくれましたが、検索する力がなければたどり着けない情報が世の中にはたくさん存在します。
もし、インターネットで情報を検索できなくてもチャットボットの方からユーザーの必要とする情報が届けられたら、その格差は解消されるはずです。

この格差を何とか解消し、最適な情報を手にした人々が、自分の意志のもとに行動することができる世界を僕たちは作っていきたいと考えています!

Facebook Developer Circleの今後

登壇資料の解説は以上となります!
最後までお付き合い頂きありがとうございました!

さて、Facebook Developer Circleの今後についてですが、毎月イベントを開催するなど、東京でも本格的な動きを開始します。

ハッカソンなども開催の予定で、ZEALSも国内で最もMessenger APIを叩く身として参加する予定です!
その際は、また様子を記事にしてお伝えできればと思います!

ちなみに、今回の登壇をきっかけにFacebook Developer Circleの運営委員会に福本が加入することになりました!!
今後も日本を代表して、Facebook Developerのコミュニティを盛り上げていければと思いますので、皆さま応援よろしくお願いいたします!

コミュニティの公式ページはこちらです!
今後ほぼ毎月イベントが開催されるようなので、ご興味ある方はぜひチェックしてみてください!

続きを読む

年末に『Hack Days(自由開発)』を実施してみました!

f:id:zeals-engineer:20190110120742p:plain

こんにちは! 2018年11月にジョインした中村です!

業務では主に会話広告fanp のサーバーサイドの開発をメインで行っています!

今回は年末に行った『Hack Days』という自由開発についてご紹介します! また、開発のアウトプット、作成するために使った便利なサービスなども紹介していきます!

是非最後までお付き合いください!

Hack Daysとは?

ZEALSでは、年末年始ギリギリのリリースで不具合が発生し結局休み中もバタバタするのはイケてないと判断し、hotfix以外のデプロイを12/25までとしました。そこで、12/28までの3日間業務から離れ自由にテーマを決め開発するHackDaysを開催することにしました。

Hack Daysには、「普段できない技術へのチャレンジや、リファクタリング等、2019年に向けて準備をしっかり整える
」という目的があります!

ちなみに、僕は「react・reduxに慣れる」というテーマで開発をしました!
自分で言うのもなんですが...とてもざっくりしていますね。笑

reactreduxを選んだ理由は、以下の2つです!

  1. JavaScriptのライブラリが流行っているので、触ってみたかった
  2. fanpのフロントはReactで開発されているので、今後の開発に向けての勉強

ちなみに、他のエンジニアの方の開発テーマはこんな感じでした↓↓↓

  • コンピューターシステムの理論と実装
  • RSpecでN+1 Queryの検知
  • データの整合性を確保するため、validationを書きまくる
  • ユーザーの返答に対して好感度を計算する機械学習モデル

業務に関連する開発をする人もいれば、自分の興味ある技術を使って開発する人もいました!
このように各メンバーがテーマを決め、開発を行なっていきます!

実際にやったこと

reactとreduxを使用することは今回が初めてだったため、Udemyの講義(React + Redux を使用したモダンフロントエンド開発)を参考にしながら、アプリケーションを作成しました!!

動画学習ってわかりやすくて、すごく便利。。。
Udemy以外にも、サービスを使用したので後ほどご紹介します!

f:id:zeals-engineer:20190109180014g:plain

こちらのアプリケーションは
キーワードに関連するgif画像を「GIPHY」というサービスから取得するアプリケーションです!

この他にもreacチュートリアルや、react・reduxを使用した小さなアプリケーションを二つほど作りました! レベルとしてはまだまだ未熟ですが、僕のテーマであったreactreduxに慣れることは達成できたと思います!!

開発する際に使ったサービス

CodeSandbox

codeSandboxは「React」「Vue」「Angular」などのjavascriptの様々なライブラリを環境構築せずに、ブラウザ上からWebアプリを気軽に作成できます!また、自分の作ったアプリケーションを公開する事や、githubとの連携もできるので、是非使用してみてください!

codesandbox.io

myjson

JSONを返してくれる無料APIのサービスです!
APIのエンドポイントも同時に作成してくれます!

Myjson - A simple json storage and hosting service

次は環境構築から、デプロイまで自力でやりきりたいと考えています!

他エンジニアのアウトプット

  • ユーザーの返答に対して好感度を計算する機械学習モデル

https://files.slack.com/files-pri/T1355CWF6-FFB19PKFY/tinder-frog-ml.gif

ちゃんとユーザーの返答に、絵文字で応えてくれていますね!

loveとか良い言葉を返答すると、良いリアクションをしてくれるようです!

  • コンピューターシステムの理論と実装

github.com

こちらがアプトプットのgithubです!

僕も読んでみたのですが、正直何をやろうとしているか、全くわかりませんでした。。。

  • データの整合性を確保するため、validationを書きまくる
  • RSpecでN+1 Queryの検知

こちらの業務に関連する開発に取り組んでいたエンジニアの方達も、無事PRの作成を終えることができました!!

そのPRも徐々にマージされており、全員が良い形でHack Daysを終わらせることができました!!

終わりに

普段使用していない、言語や技術で開発することは新たな発見があり、とても有意義な時間でした! ぜひ、皆さんも空いた時間を利用して、新たな技術に挑戦しましょう🔥

続きを読む

GCPでDeep LearningのためのGPU環境を構築する

f:id:zeals-engineer:20190108094205p:plain

こんにちは!サーバーサイドエンジニアのJohnです。

インターン生として、fanpの配信周りの開発を行なっています。

今回は、GCP(Google Cloud Platform)にGPUを動かすための環境を作ってみます。だいぶ長い記事になってしまいましたが、お付き合いいただければと思います。

  • Google Cloud Platform(GCP)
  • プロジェクトの作成
  • GPUの割り当て
  • インスタンスの作成
  • Google Cloud SDKのインストール
  • CUDAとNVIDIAドライバのインストール
  • cuDNN7.0のインストール
  • Kerasを使ってみる
  • まとめ

Google Cloud Platform(GCP)

GCPとは、Googleが提供するクラウドコンピューティング向けのプラットフォームです。似たようなサービスにAmazonのAWSや、MicrosoftのAzureがあります。

基本的な構成が最初から準備されているので、自分たちでデータセンターを作ったりしなくてもすぐにコンピューティングリソースを使うことができるようになります。今回はこのGCPを使って、DeepLearningをしてみたいけど自分でGPUマシンを買ったりするのは大変……という人でも学習をぶん回せるような環境を構築します。

※以降、GCPへの登録は済んでいる前提で進めていきます。もしまだ登録していない場合は、こちらから登録できます(GCPのページへ飛びます)。また、GCPでGPUを使うためには有料アカウントへアップグレードする必要があるので注意してください。

プロジェクトの作成

GCPにはプロジェクトという概念があります。GCPで利用する各リソースやAPIは全てプロジェクトと紐づいていて、課金などもプロジェクト単位で行われます。そのため、プロジェクトごとにアカウントを作ったりする必要がなくなります。

まずは今回のプロジェクトを作成しましょう。ページ上部のMyFirstProjectをクリックすることで、プロジェクト管理モーダルが表示されます。今回のプロジェクト名は「DeepLearningWithGCP」とします(筆者が作成した複数のプロジェクトがありますが気にしないでください)。

f:id:zeals-engineer:20190106221208j:plain

GPUの割り当て

GCPでGPUを使用するには、GPUの割り当てを行う必要があります。

ナビゲーションメニュー(左上の3本線)からIAMと管理割り当てを選択します。さらに、指標:なしを選択した後に指標:GPUs (all regions)を選択します。 f:id:zeals-engineer:20190106233839j:plain この状態で割り当てを編集をクリックし、割り当て申請を行います。新しい割り当て上限に使いたいGPUの台数、リクエストの説明には簡単に使用用途を書いておきます。100個とかあんまり大きな数を書くとサポート担当者とのやりとりが必要になるので、常識的な数字を入力しましょう。 f:id:zeals-engineer:20190106233923j:plain しばらくすると承認メールが届きます。これで割り当てが完了しました。

インスタンスの作成

プロジェクトを作成したら、今度はインスタンスを作成しましょう。

ナビゲーションメニューからCompute EngineVMインスタンスと選択すると、次のような画面が表示されます。ここで作成をクリックすることでインスタンス作成画面へ遷移します。 f:id:zeals-engineer:20190106221557j:plain

今回作成するインスタンスの設定は以下の通りです。

リージョン: asia-east1
マシンタイプ:vCPU x 1
GPUの数: 1
GPUのタイプ: NVIDIA Tesla K80
ブートディスク: Ubuntu 16.04 LTS (ストレージ:10GB)
サービスアカウント: Compute Engine default service account(デフォルト)
アクセススコープ: デフォルトのアクセス権を許可(デフォルト)
ファイアウォール: HTTP トラフィックを許可する

GPUに関しては、マシンタイプのカスタマイズから選択します。 f:id:zeals-engineer:20190106234231j:plain ここまで設定したら、作成をクリックします。しばらくするとインスタンスが作成され、緑色のチェックマークがつくと作成完了です。 f:id:zeals-engineer:20190107033339j:plain

Google Cloud SDKのインストール

インスタンスへの接続など、Google Cloud SDKをインストールしておくと便利です。リンク先を参考に、まずこちらをインストールします。

CUDAとNVIDIAドライバのインストール

GPUを設定しましたが、利用するにはドライバが必要になります。また、GPUで学習を並列処理するにはCUDAが必要です。ここでは公式ドキュメントを参考にそれらをインストールします。

まず、インスタンスにSSH接続しましょう。VMインスタンスの画面で、接続のプルダウンメニューからgcloudコマンドを表示し、それをコピペすれば接続できます。 無事接続できたら、以下のコマンドでCUDAとドライバをインストールします。

$ curl -O http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/cuda-repo-ubuntu1604_9.0.176-1_amd64.deb
$ sudo dpkg -i cuda-repo-ubuntu1604_9.0.176-1_amd64.deb
$ sudo apt-key adv --fetch-keys http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/7fa2af80.pub
$ sudo apt-get update
$ sudo apt-get install cuda-9-0

これでCUDAとドライバが入りました。一般に、次の設定でGPUのパフォーマンスを最適化できるようなので、やっておきます。

$ sudo nvidia-smi -pm 1
Enabled persistence mode for GPU 00000000:00:04.0.
All done.

加えて、今回はK80を使っているので、自動ブーストを無効化します。

$ sudo nvidia-smi --auto-boost-default=DISABLED
All done.

cuDNN7.0のインストール

cuDNNはNVIDIA社が提供するDeep Learning向けのライブラリで、ほとんどのDeep Learningライブラリで使われています。利用にはアカウント登録が必要です。

https://developer.nvidia.com/developer-program

ここでdeveloperアカウントを作成して、

https://developer.nvidia.com/rdp/cudnn-download

ここでcuDNNをダウンロードします。今回はubuntu 16.04向けのcuda-9.0 versionをダウンロードしました。三つのファイルありますがすべてダウンロードします。

これをインスタンスにアップロードする必要があるので、GCPストレージを使います。scpコマンドでもいいんですが、どうも遅いらしいです。ナビゲーションメニューからStorage を選択すると、バケットの作成画面になるので、名前などを適当に入力して、バケットを作成します。場所はインスタンス同様asia-east1とします。

バケット作成後は、アップロードボタンからファイルをアップロードします。アップロードが完了したらgsutilコマンドでそのままインスタンスへの転送が可能です。

$ gsutil cp gs://{YOUR_BUCKET_NAME}/libcudnn7_7.4.2.24-1+cuda9.0_amd64.deb .
$ gsutil cp gs://{YOUR_BUCKET_NAME}/libcudnn7-dev_7.4.2.24-1+cuda9.0_amd64.deb .
$ gsutil cp gs://{YOUR_BUCKET_NAME}/libcudnn7-doc_7.4.2.24-1+cuda9.0_amd64.deb .

{YOUR_BUCKET_NAME}には設定したバケットの名前を入れてください。転送が完了したらファイルを展開してインストールします。

$ sudo dpkg -i libcudnn7_7.4.2.24-1+cuda9.0_amd64.deb
$ sudo dpkg -i libcudnn7-dev_7.4.2.24-1+cuda9.0_amd64.deb
$ sudo dpkg -i libcudnn7-doc_7.4.2.24-1+cuda9.0_amd64.deb

これでひとまず、GPU環境が完成しました。

Kerasを使ってみる

作成した環境で、KerasのチュートリアルであるMNISTの学習をしてみましょう。

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get install python3-pip
$ pip3 install --upgrade pip
$ pip install tensorflow-gpu
$ pip install keras
$ wget https://raw.githubusercontent.com/keras-team/keras/master/examples/mnist_cnn.py
$ python3 mnist_cnn.py

f:id:zeals-engineer:20190107033059j:plain 1 epochあたり11秒!筆者のマシン(Mac Book Pro)のCPUでは1 epochあたり2分だったので、GPUすごいですね。

これで、GPUインスタンスでKerasを実行するところまで構築できました。

まとめ

今回はGPUでDeep Learningの学習を回せるようなGPUインスタンスを作成しました。自分でマシンを買うと場所や管理、初期費用など大変ですが、クラウドだと手軽に始めることができますね。これからどんどん学習させちゃいましょう!(GPUインスタンスは結構お高いので、使わないときはインスタンスを停止しておくといいかもしれません)

続きを読む