ZEALS TECH BLOG

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

【後編】元ドリコム/現メルカリの白石さんと語る、ZEALSコアテクノロジー対談

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

皆さんこんにちは!
ZEALSVPoE兼エンジニアの福本です!

こちらの記事は前編に引き続き、【後編】元ドリコム/現メルカリの白石さんと語る、ZEALSコアテクノロジー対談です。

後編では「ZEALSの文化」や「組織の雰囲気」などを中心にお話させていただきましたので、その対談の模様をお届け致します。

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

tech.zeals.co.jp

  • ZEALS組織の技術的な強み
    • 「間違いなくNo.1のプロダクトです」
    • パイオニアとして、素早いリリースを
  • どんなチームで開発しているのか?
    • VisionやValueが浸透している
    • 強い成長欲と裁量の大きさがある
    • 複数言語での開発に挑戦しやすい
  • 働くメンバーの思い
    • 多様性のあるエンジニア組織
    • どんな思いで開発しているか
続きを読む

【前編】元ドリコム/現メルカリの白石さんと語る、ZEALSコアテクノロジー対談

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

皆さんこんにちは!
ZEALSのVPoE兼エンジニア福本です! 

今回は、テクノロジーお師匠さんとしてZEALSにジョインして頂いている元ドリコム技術執行役員/現メルカリの白石さんを聞き手としてお招きし、プロダクト開発で用いているコア技術やエンジニア組織について、対談形式で語って頂きました!

tech.zeals.co.jp

どんな技術を用いてどうプロダクトを開発したか、どんなエンジニアがどんな思いで開発しているかetc...

今まであまりお伝えすることのなかった内容ですが、皆さんにZEALSのことをもっと知っていただきたかったため、今回の対談を行うに至りました!

その対談の様子を、テックブログの記事で皆さまにお伝えさせていただきます!

  • 関係者
  • なぜZEALSにジョインしたのか?
    • CTO島田とCEO清水との出会い
    • 小寺「ZEALSは楽しい」と聞いてジョインしました
  • ZEALS開発組織の”良さ”とは?
    • 「守るべきライン」を守る
    • 自ら課題を解決する姿勢を
    • ZEALSには”良い人”が多い
  • 過去の開発からの学び
    • DjangoからRailsにリプレース
    • 反省をプロダクト開発に活かす
  • ZEALSチームの技術的な”強み”とは?
    • 「テストをしっかり書く」を当たり前に
    • 意識して「自然とフルスタックになる」組織を
    • 技術的負債への取り組み
    • 前編はここまで

関係者

 株式会社ZEALS CTO 島田想

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


株式会社ZEALS  リードエンジニア 小寺京祐

東京都出身。日本大学理工学部卒。前職の渋谷ICT教育ベンチャーではコース責任者 兼 Railsエンジニアとしてカリキュラム設計・講義運用・オンライン学習プラットフォームの開発など幅広く担当。2017年9月からZEALSへJOIN。開発チームの文化醸成・制度整備などに尽力。現在、チームリーダーとしてプロダクト「fanp」のプロジェクト管理・エンジニアチームのマネジメント、採用まで幅広い業務を管掌している。

(聞き手)元ドリコム技術執行役員/現メルカリ 白石 久彦

大学卒業後、さまざまなBtoB、BtoCのサービスやインターネットインフラ構築のプロジェクトに携わる。ソフトバンクグループ、 株式会社レコチョク等を経て、2012年ドリコムに入社、2014年には技術担当執行役員に就任。2018年より株式会社メルカリに参画、テックカンパニーを目指す同社のエンジニア組織の強化を担当。並行して株式会社スライストーンを創業、株式会社ZEALSを始めスタートアップから上場企業まで複数社の技術アドバイザーを務めている。

なぜZEALSにジョインしたのか?

CTO島田とCEO清水との出会い

白石:今日はよろしくお願いします。2人がどんな役割を担っているのか、簡単に紹介してもらえると。まず島田さんから。

島田:僕は創業当初からCTOをやっていて、去年一昨年は採用周りや組織のビルディングをやっていました。その頃、白石さんにお会いしました。

白石:確か1年以上前だよね。「ドリコムに遊びに来てよ」という感じで、コミュニケーション取り始めたのが最初で。

島田:はい、そうでしたね。

白石:島田さんは創業時からCTOだけど、マサさん(注:代表の清水)と会ったきっかけは?

島田大学が一緒で出席番号順で前と後ろになったんです。当時から「コイツ(清水)むちゃくちゃだな」と思っていて(笑)、気がついたら手伝うことになってました。

小寺「ZEALSは楽しい」と聞いてジョインしました

白石:なるほど。コディ(注:小寺)はどんな感じでZEALSに携わったんだっけ?

小寺僕は以前はプログラミング教育の講師でした。そこの先輩エンジニアが元々ZEALSでやっていて...

白石:紹介された?

小寺そうです。僕が前職でくすぶり始めたときに、相談して「ZEALS来なよ、楽しいから」っていう話で。

白石じゃあ、マサさんもコディもくすぶるとこから始まってるんだね。

小寺:そういえば、僕は島田さんがCTOになった経緯を知らないんですけど...

島田:ZEALSがWebの受託開発を始めて、そこから徐々に中心的に開発をやるようになったのがきっかけでしたね。

白石最初は何で開発してたの?Rubyとか?

島田最初はPHPです。Wordpressとかですね。

ZEALS開発組織の”良さ”とは?

「守るべきライン」を守る

白石コディは最初からエンジニアとしてジョインしたけど、今は役割的にはどんなことをやってるの?

小寺僕は今、開発部全体のマネジメントをしています。一般的な言い方だと、プロジェクト管理に近いですね。メンバーにタスクを渡す見積りなどは僕がやっています。

tech.zeals.co.jp

白石なるほど。島田さんが技術選定で、コディがプロジェクトという感じに役割が分かれているんだね。

島田そうですね。そこはしっかり分けています。

白石:コディは、ZEALSにジョインした当初の技術レベルはどうだったの?

島田:小寺が入ってきた時はRuby、正確に言うとRailsが書ける人とは聞いてたんですけど、期待値よりは書けていた印象ですね。

白石:なるほど、一方コディはジョインしてZEALSに対してどう感じたの?

小寺コードレビューをすごいしっかりやってる、と感じました。自分たちだけで完結しないところは、業務委託の方にも協力を仰ぎながら。

白石:開発チームは既にそれなりの人数のエンジニアが居たんだよね?

小寺:はい。そんな中でも構文とかはもちろん、守るべきクオリティをしっかりと保つんだという意識がすごい見えました。

自ら課題を解決する姿勢を

白石:それで今、コディは組織のマネジメントをジョインして1年位でやるようになったけど、どういう経緯でそうなったの?

小寺:細かい話なんですけど、Slackの使い方やDocbaseの使い方とか、整備されてない部分が多かったんです。そこに勝手に課題感を持って、ゴリゴリと整備しました。

qiita.com

白石:環境を整えることを考えて進めた、という感じ。

小寺:主体的に自分で動き続けた結果、という感じですね。

白石:そういうのを見て、島田さんは何か思った?

島田:「ありがてえ...」と(笑)

白石:「めんどくさい人が入ってきた」とは思わず?(笑)

島田:はい(笑)

白石:全然整備されていない状況に対して、コディはどう考えて進めていったの?

小寺:僕が前職でそういった部分をしっかりと教えられていたので、そういった部分で貢献できればいいなと...

白石:なるほど、コディは教えたり整えたりと面倒見のいい感じなんだね。

小寺:そうですね、お節介な所はあります。

ZEALSには”良い人”が多い

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

白石:じゃあ、島田さんはそういう細かい部分は気にならないタイプなの?

島田:どちらかと言えば、プロダクトに集中したいタイプですね。

白石:良く言えば、役割がそこでいい感じに分かれているんだね。

小寺:僕はそこも含めて、会社をよくできる余地がたくさんあると感じる方の人ですね。

白石:そもそも、コディはZEALSのどこに惹かれたの?

小寺人が良いところです。本当に良い人が集まってて、偏屈な人がいないので...

島田:それはそうですね、素直な人が多いですね。

白石:なるほど、なるほど。

小寺:社長の人柄もあるかもしれませんが、すごく良い人が集まっている組織だと感じました。

過去の開発からの学び

DjangoからRailsにリプレース

白石:ちなみだけど、『fanp』プロダクトの技術は今も昔と同じものを使ってるの?今は会話を作る管理画面がReact + Railsで、会話の送受信がPython、インフラがMicrosoft Azureだよね。

小寺:いや、昔は違いました。

島田昔はすべてPythonだけで、フレームワークはDjangoを使ってましたね。

qiita.com

白石:DjangoからRailsに変えた経緯は何だったの?

島田:スキーマが最適化されていなかったりとか、アーキテクチャ周りでアンチパターンな部分が多くなっていたので...

白石:プロトタイプでサービスインして、その後すぐ作り替えようと。

島田:そうです。

小寺:僕がそのリプレースが始まって4ヶ月あたりでジョインしたんです。

白石:そのリプレースでRails化するのに携わったと。

小寺:そうです。設計は決まっていたので、タスク量だけは膨大でした(笑)

反省をプロダクト開発に活かす

白石:なるほど(笑)フロントエンドは最初からReactで開発する方針だったの?

小寺:はい、リプレースのタイミングからReactで開発することを既に決めていました。

島田管理画面とボットが密結合じゃないようにしたい、という思いがありました。管理画面が落ちたと同時にボットも停止するとなれば、それは最悪じゃないですか。

白石:確かにね。Djangoで作った時は、全部一枚岩だったんですね。

島田:はい。その時の反省を活かして、疎結合に各パーツがモジュールとして動くようなイメージにしています。ゆくゆくはマイクロサービス化したいなと。

白石:今もメッセージの送受信機能をPythonで書いているけど、そういった経緯もあってRailsと共存している珍しいアーキテクチャになっているんだね。

島田:そうですね、何でもかんでもリプレースするのではなく、既存のPython資産を活用したほうが効率が良いと判断しました。

ZEALSチームの技術的な”強み”とは?

「テストをしっかり書く」を当たり前に

白石:その頃と比較して、技術的に良くなったと感じる部分はありますか?

島田:当たり前の話かもしれないんですけど、「テストをしっかり書くようになった」というのはすごく大事だと思ってます。

白石:そうなんだ。それは雰囲気的に?

島田:はい。明文化しなくても「テスト書いてね」という雰囲気があったんですよ。

小寺:明らかにバグが多い時期があって、リグレッションしてる時間が基準値を越えたとわかったので、そこからはテストを書こう、テストケースをきちんと決めようと意識づけました。

島田:「コメント入れましょう」とかも、細かいですけどちゃんとやってますね。

意識して「自然とフルスタックになる」組織を

白石:さっきPythonからReact/Railsまで話が広がったけど、チームの中でいわゆるフルスタックというか、PythonとReactとRailsを複数書けるエンジニアは結構いるの?

島田:基本は各技術スタックで分かれてるメンバーが多いですが、React/Rails書けるメンバーも2,3人居ますね。

小寺:RailsとPython書けるパターンは僕が最初ですね。そのうちReactも書けるようになりました。

白石:最初がコディだったんだね。だんだんそういう人が増えてって...

小寺:そうです。今度はAaronがPythonも書いて...

www.wantedly.com

白石:結構意識して技術の幅を広げてけるようにしているんだね。

小寺:そうですね。「やったことないけどやろう」みたいな...

白石:その方が会社にとっても層が分厚くなるもんね。

技術的負債への取り組み

白石:ところで、リファクタ要員みたいな役割のエンジニアは居るの?

小寺:居ますね。リファクタリング好きな人は結構多いので。

島田:ZEALSでは、インターンの子でもリファクタリングをゴリゴリ進めてたりします。

白石:リファクタリングする時も、当然コードレビューするんだよね?

小寺:もちろんします。コードオーナー制を採用していて、各リポジトリごとに設定しています。

help.github.com

白石:なるほど。メインでコードを見る人、つまりオーナーがいるんだね。

小寺:そうです。オーナーがいて、その人からのApproveは確実に貰うということをやっています。ただ、一部のリポジトリやファイルに関しては、コードオーナーが忙しくなるとレビューが止まるということが起きてしまって。

白石:うんうん、リアルな話だね。

小寺:そういう声が多い箇所だけは、「リポジトリに関連する開発スキルを持つエンジニアから2人以上Approve貰えればマージできる」というルールにしました。その辺りは柔軟にやっています。

島田:一般的な正論から良いものを取り入れて、合わない・悪いものは使わないという工夫をしっかりやっています。

続きを読む

復活したGotanda.rbに参加&登壇してきました!

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

こんにちは、ZEALSでサーバーサイドエンジニアをやっております、あべです!
今回のブログは先日行われたGotanda.rb のイベントについてお伝えしたいと思います。

github.com

Gotanda.rbって?

有名な『Asakusa.rb』や、以前サーバサイドエンジニアのRyutoooooが記事を書いてくれた『Omotesando.rb』など、各地域にRubyコミュニティがありますが、実は五反田にもRubyコミュニティがあります!

tech.zeals.co.jp

正確に言うと、「あった」のですが、コミュニティを立ち上げたOrganizerの方が転職し五反田から離れてしまった、という理由からしばらく運営されておりませんでした。

復活のきっかけは、記事にある『Omotesando.rb』でした。

五反田界隈の方とお会いし、そこで意気投合。
Gotanda.rbのOrganizerを引き受けたトレタの中村さんとつながり、そこから再度立ち上げたという次第です!

今回のテーマは設計!

さて、そんなこんなで2019年3月20日に見事復活を果たしたGotanda.rb、個人的な感想になりますが参加してよかったです!!

今回のテーマは「〜設計について気軽に話そう〜」だったのですが、普段他社の設計の話ってそう気軽に聞けるものじゃないですよね。
その設計の話を、生々しく、時に楽しく、飛び込みLTありのゆるい雰囲気の中たっぷり聞けたのがとてもよかった、と感じました。

この「生々しい話」というのがGotanda.rbのコアなテーマになっていてます。
「正論だけではない、開発現場のあるある」な共感できる話が多いのが特長でした。

全体の雰囲気などはTogetterにもまとまってますので、ぜひ見てください!

togetter.com

前半戦:LT大会!

ZEALSの登壇

まずZEALSの福本がスタートアップにおけるRails開発のツラみ〜なぜ僕たちはRails wayを貫けないのかというテーマで登壇致しました!

speakerdeck.com

スタートアップでリソースが足りない中で小さな工夫をどう重ねていくか、ZEALS内で実際取り組んでいる例を含めて紹介しました。

この内容には含まれていませんでしたが、LTで少し話に出た「ServiceClass」というワードがこのあと一つ大きなテーマになっていました!
ZEALSにもServiceClassは存在しておりますが、やはり会社によって経緯や運用の仕方が違うこと、会社によって良し悪しも180度違っていると感じました。

ServiceClassについてどんな話があったか

  • 行数がやばい一つのファイルをServiceClassとユースケースに切り分けてみたら処理が明確になった
  • ServiceClassを実装したらコードもテストもスッキリしていろんなだるいがなくなった
  • 一人で作り上げたServiceClassが、作った本人にしかわからないやばいServiceClassになってしまっている
  • あとから違う人が作業しようと思っても何をどこにどうやって変更したらいいかわからない…

…など会社によってServiceClassのあり方にかなりの違いがあるようでした。
「じゃあ結局その差はなんなのか?」という話をdelyのjoeさんが飛び込みでLTをされていました。

結論:作っても良いけどルールがないサービスクラスはダメ

ServiceClassをどう作ってどう運用していくか、きちんと決めていくのが重要ということでした。

一方、実際チームでルール作ってちゃんと運用していくのはかなり難しそうだとも感じました。
うまくルールが作られ、良いServiceClassとして運用を心がけているLTに改めて感心しました。

後半戦:実際のプロダクションコードを見ながらの設計相談会

今回参加する前に聞いていてかなり楽しみにしていたトレタのプロダクションコードを見ながら聞けるLT
もちろん写真を載せることはできないのですが、実際にコードを見ながら質問に答えていく形式のLTで非常に盛り上がっていました!

プロダクトが育ってきた歴史を、設計周りやコメントから感じました。
私たちのプロダクト『fanp』は今の形になってから約1年半なのですが、トレタは6年と年季が入っていて、あらゆることが一筋縄で行かなくなるのだな、と感じました。

お話を聞いていた中で、個人的に特に興味を持った部分はデータ分析の話でした。

プロダクトを育てていく過程で、データ分析専門の部隊ができたらどんなことをやるべきなのか。
また、どんなテーブルにどんなデータを保存すればいいのか、何千万件もレコードがあるテーブルに変更を加えるときどうしたらいんだろう、など実際悩んだこともあったので色々と考える機会になりました。

やはり実際のプロダクトコードとのことで、みなさん時間ギリギリまで質問されていました!

さいごに

繰り返しになりますが、参加してよかったです!!

続きを読む

EastgateHackathonにZEALSチームで参加しました!

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

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

3月16 ~ 17日に行われた『Eastgate Hackathon』にZEALSがチームで参加してきましたので、チームメンバーのご紹介とハッカソンで開発したプロダクトについてお伝えさせて頂ければと思います。

EastgateHackathonは「海外にチャンレンジするエンジニアを増やす」という思想のもとに開催されており、優勝者はFacebook本社がシリコンバレーで主催する”F8 Hackathon”への渡航費や現地ネットワーキングを得られる豪華なイベントでした。

www.eastgate.tokyo

世界一のプロダクト、そして世界一のエンジニアチームを本気で目指すZEALSとして参加しないわけにはいかず、チームを募って参加しました。

ちなみに私福本はハッカソン自体には参加せず、日本国内で最もFacbook MessengerのAPIを叩くZEALSを代表し「テックメンター」として、運営に近い形で当日ハッカソンをリードさせていただきました!

tech.zeals.co.jp

ハッカソン全体の雰囲気や福本の登壇部分については、Wantedlyで記事を書いておりますので、合わせてご覧いただけますと嬉しいです。

www.wantedly.com

  • ZEALS参加メンバー
  • 開発プロダクト
  • ピッチ&審査
  • さいごに
続きを読む

全てのmodelにvalidationを張った話

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

こんにちは、今回のブログ担当・あべです!

ZEALSにジョインして早3ヶ月…会話広告fanpのサーバーサイドエンジニアとして、日々勉強しつつ楽しく働いています!!

さて、今回のテーマですが、以前サーバサイドエンジニアの中村さんが書いてくれた年末自由開発『Hack Days』で取り組んだテーマのうちの一つ、 「データの整合性を確保するため、validationを書きまくる」 について詳しく書きたいと思います。

  • なぜこのテーマに取り組んだのか
  • 何をやったのか
  • 大変だったこと
  • テーマに取り組んだことでの学び
    • PRレビューの過程でテストの方針などが共有された
    • model周りの理解につながった
    • リファクタリングが進んだ
  • おわりに

なぜこのテーマに取り組んだのか

個々が自由に開発に取り組む中、なぜチームでこのテーマに取り組んだのか? 前提として、開発において以下のような課題がありました。

  • DBのテーブル構造に変更を加える際、本番環境で変更後のテーブル構造と不整合を起こす「 ゴミデータ 」が問題となっており、変更作業の負担になっている
  • ゴミデータが発生する主な原因として、「 Railsのmodelのvalidationが不十分だったこと 」があり、これを解消する必要がある

validationを張りまくりゴミデータを発生させないため、12月初旬から少しずつvalidationの修正をしていこう!という話がチームであがり、「1人1日1modelずつ張る」ということを目標にしました。

railsguides.jp

しかし、日々の開発や対応に追われて思うように進まず進捗はいまひとつ。。

そこで、年末自由開発の時間を使ってvalidation修正にチームの力を一点集中!!一気に終わらせよう!ということになったのです。

何をやったのか

validationを見直し、誤ったvalidation・不適切なvalidationがあれば修正する、ということを全modelに対して行いました。

具体的には…

1. DBスキーマとmodelのvalidationとの整合性を取る

  • DBスキーマの設定を確認し、その構造をmodelのvalidationとして書き起こしていく

2. DBスキーマで表現できないデータ構造があれば、validation側で追加実装する

  • URLやメールアドレスなどDBスキーマで表現しきれないデータ構造を持つカラムについては、カスタムvalidationとして実装し、データの正確性を維持する

3. Factoryから正しい構造のデータが生成されるようにする

  • 当該modelのFactoryを確認し、正しい構造のデータが生成されることを確認する

github.com

大変だったこと

まず大変だったことは、 「大量のタスクを短期間でこなす」 ということです。

今回の場合、タスク数=model数となりますが、その数

125個!!! (※後で数えました)

125、という数が多いか少ないかは人それぞれかと思いますが、前述の通り12月初旬に始めたものの進捗はいまひとつ…
未着手のもを大量に抱えたまま突入した年末開発で終わらせるには、チーム全員(6名)でひたすら潰すしかありませんでした。

数をこなすのももちろん大変ですが、そもそも書くvalidationを間違ってしまうとデータ周りで問題が発生してしまうため、素早くかつ正確にDBスキーマに沿って書くことが必要となります。

また、上記の内容に加え必要であれば新しくテストを書いたり、それに伴ったFactoryの改修テストデータの変更など付随する作業も多々あります。
最初は「結構簡単かな?」と思ったのもつかの間、気がつけば最後の成果発表会ギリギリまで作業してなんとか間に合った、という感じでした。

テーマに取り組んだことでの学び

この取り組みを通して、全てのmodelにvalidationを張ることができただけでなく、多くの学びがありました!

PRレビューの過程でテストの方針などが共有された

例えば、下記のようなことが共有されました。

  • enumテスト:enum定義におけるkeyやvalueの値までしっかりテストで検証する
  • build と build_stubbed 使い分け: build_stubbedはテストが高速 なのでbuildと分けて積極的に使う
    • build_stubbedを使うとassociation先のデータもDBにインサートされないため、少しですがテストが早くなります(塵も積もれば…ですね)
  • subject定義:shouda-matchersはsubjectを書いた方が第三者から理解しやすい

github.com

議論されたことがチームで共有されることによりテストの質が保たれたり、他の人にわかりやすくなったりと、より良いコードに繋がります。

model周りの理解につながった

このテーマに取り組むにあたりただ闇雲に進めるのではなく、作業したmodelと関係のあるmodel、さらにそれに関係のあるmodelと順に辿って作業しました。

業務で自分が開発したコード周りはよく理解していても、そうでないところはあまり理解できてないかったりします(私の場合は特に、ですね..)。
改めてmodel同士の関係性の把握や理解につながり、業務効率がアップしました!

リファクタリングが進んだ

リレーションの多いモデルにvalidationを追加した際テストが大量に落ちることがあり、テストの実装がvalidationに沿っておらず間違って実装されていたために大幅な修正が必要となりました。

結果として正確でないコードを見つけ書き直すことができ、validationの追加も含め大幅にコードを改善することができました!

おわりに

日々の開発に追われるとなかなかこういった地味な作業はできずに後回しになってしまいがちです。

続きを読む

「AWS Cloud9 + heroku + Messenger API」で簡単に開発するチャットボット入門

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

皆さんこんにちは、サーバサイドエンジニアの福本です。

先日、Facebookオフィシャルコミュニティである『Facebook Developer Circle』の第2回目のイベントにて、”Messengers APIを用いたライブ・コーディング”を実施しました。

www.wantedly.com

ライブ・コーディングを実施するにあたり色々と準備をし、簡易的なチャットボットを作る手順をまとめてみましたので、みなさんに共有します。

Messenger APIにはFacebookが公開しているスタートガイドがありますが、そちらを進めるだけでは、思わぬポイントでハマってしまうことがあります。

developers.facebook.com

今回はそういったところも含めて、開発の手順を皆さんにお伝えします。
チャットボット開発の魅力を少しでもお伝えできれば幸いです。

  • 使う技術・ツール
  • ゴール
  • チャットボットの開発
    • cloud9の環境構築
    • webhookの設定
    • herokuへデプロイ
      • コマンドラインでherokuを使えるようにする 
      • herokuへのデプロイ準備
      • package.jsonの修正
      • herokuデプロイ
    • Facebookアプリの設定
    • テキストや画像の処理およびカルーセルの送信
  • 完成
    • テキストが送られた場合
    • 画像が送られた場合
    • (生成された)ボタンをタップした場合
続きを読む

Omotesando.rbに登壇&参加してきました!

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

皆さんこんにちは! ZEALSでバックエンドエンジニアをやっているRyutoooooです!

最近はもっぱらDBのリファクタリングでビジネスサイドより、開発側が喜ぶことをメインでやらせてもらっています!

さて今回ですが、有名なRubyコミュニティの『.rb』系の表参道での会に参加してきました!!
同じくZEALSのサーバサイドエンジニア福本と参加ました。

僕は参加しただけですが、福本は当日LTを実施したのでその内容も含めてイベントの模様をお届けできればと思います!

『技術を使わない問題解決 ~チームが10人越えたら考えたいgem周り~』

なんともエモいテーマのLTですね!
実際に登壇をした時の反響もよく、Twitterでも好評でした。
(詳しくはこちらです)

こちらが登壇で使用したスライド資料です↓

speakerdeck.com

紹介したGemとOSS(4~14枚目)

今回問題解決の方法として、Gem等をいくつか紹介しました!

Danger:プルリク秩序の乱れ

github.com

PRに一定のルールを設定し、それを破るとコメントしてくれるというgemです!

実際にZEALSで導入した時の記事はこちらです。

Okuribito:技術的負債の増加

コードを静的解析し、未使用の可能性が高いメソッド等を列挙する github.com

コードを動的に解析し、外部呼び出しも含め分析する github.com

上記の2つをうまく用いて、使われていないコードを判断して葬ることができます!

CircleCI Bundle Update PR:gem updateの責任なすりつけ

Gemfile.lockとbundle updateの差分を検知して、自動でPRまで作成してくれます!
日常のレビューフローの中にgem updateを入れてあげることで、より安全にRailに乗っていくことができますね! github.com

エンジニアにとっての問題解決(15~22枚目)

個人的にはこの部分が一番好きな話でした。

僕が良いと思ったところは「問題解決にはレベルがある」ということです!

最も良いのが「技術を使わないで問題を解決すること」で、
最も良くないのが「難しい技術を使っているだけ…」なこと。

僕は「エンジニアなら技術使ってなんぼでしょ?」と思っていたので、最初はよく理解できませんでした...

では「なぜ技術を使うべきではないのか?」という理由について、以下の3つを挙げていました。

・技術は必ず陳腐化する
・技術は必ず属人化する
・技術は必ず負債になる

この3つを聞いて、凄く納得しました。
エンジニアだからこそ、技術をどう使うかをしっかりと考えたいと改めて感じました。

会場の皆さんからの反響もよく、ZEALSとしてすごく良いLTができたと思います!

個人的に印象に残ったLT

「kibela2esaと正規表現」

Ruby界隈ではご存知の方も多いうなすけさんが今回登壇していました。

登壇内容は、社内で使っていた情報共有ツールを違うサービスに乗せ替えるために、正規表現で全ての情報を取得するというものでした。
正規表現での苦労やRubyで書いたからこそ良かった点等々熱く語ってくださり、思わず聞き入ってしまいました!

github.com

「Railsでモデルのステータスを扱うベタープラクティス」

ngmtさんはモデルのステータスをどのように制御したらよいかをお話していて、共感するところが多くありました!

ポイントとしては、下記の3点です。

PlantUMLとレビューで設計共有・更新を漏らさない

シーケンス図を手早く書けるドメイン言語のPlantUMLを書き、常に設計を共有しておくということ。
スクラッチだったりスタートアップでは共有するのもコストでどうしても共有が疎か…なんてこともあったりしますね…

AASM gemでステータス管理・実装をカンタンに

僕は知らなかったgemなのですが、モデルのステータスをmodule化して定義できるみたいです。 github.com

最初はほんとに小さく始める、DB設計が正規化されていれば後からでもなんとかなる

これは間違いないですね...
正規化した後も大事で、DBのメンテナンスを疎かにしていると、後で痛い目を見ます(経験談)

speakerdeck.com

全体的な感想

Rubyのコミュニティは他の言語のコミュニティに比べて規模が大きいと感じました。
他の.rbもそうですが、これからもRubyコミュニティにどんどん参加し、1人のRubyエンジニアとして界隈を盛り上げていきたいと思いました!(登壇もしたい…)

Omotesando.rbは毎月第一木曜日に開催していますので、ぜひ参加してみてください!!! コミュニティの公式ページはこちらです。

続きを読む

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文を多用してしまうと、頭を抱えながらコードをなんとか書くことしかできません。

続きを読む