ZEALS TECH BLOG

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

【初心者向け】fish shellの入れ方と、rbenvではまっている話

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

こんにちは!
インターンから新卒で入社した、サーバサイドエンジニアのkanacchiです。

突然ですが、新卒や新たな環境で働くことになったエンジニアの皆さん。
社用PCが供給されてまずはじめに行うことありますよね。

そう、環境構築です。

かく言う僕も先日環境構築を行ったわけですが、その際新たにfishshellを使うことにしたので、今回はfish shellの紹介とハマったポイントなどを残していければと思います。

※注)所々でsudo対応を連発したところ、ことあるごとにpermission errorが出るようになってしまいました。(現に今もsudoで臨時対応してます、、)
この記事を見ている人は安易にsudoを連発せず、コマンドが通らない場合はきちんと原因を解決してから進んだほうが後々楽になると思います(自戒の念を込めて)

fishのinstallにあたって、大まかにはこちらの記事を参考にさせてもらいました。

dev.classmethod.jp

fishって何?

"friendly interactive shell"の略でshellの1つです。
fishのいいところは沢山ありますが、僕がおすすめしたい点は3つです。

①ターミナルがかっこいい

無駄のない、シンプルなターミナルがデフォルトです。

~ >

そして僕のターミナルはこんな感じで、左にrubyのバージョンを表示させてます。

スクリーンショット 2019-04-09 21.26.51.png

ディレクトリを移動するとこう表示されます。
緑の部分は現在のブランチです。

スクリーンショット 2019-04-09 21.27.10.png

そしてそのテーマ設定などをブラウザで扱えます。

$ fish_config

スクリーンショット 2019-04-09 21.16.58.png

② 構文エラーがわかりやすい

無効なコマンドと有効なコマンドをわかりやすく表示してくれます。

無効なコマンド

スクリーンショット 2019-04-09 21.14.53.png

有効なコマンド

スクリーンショット 2019-04-09 21.15.05.png

③コマンドの補完機能が優れている

一度打ったコマンドを学習し、コマンドを補完してくれます。
(右側にグレーで表示されます)

スクリーンショット 2019-04-09 22.15.39.png

fishをインストール

それではまず、fishをインストールしていきます。
Homebrewを使ってfishをインストールしましょう。

$ brew install fish

インストール後はfishコマンドが使えるようになります。

$ fish -v
fish, version 3.0.2

次にデフォルトshellをfishするために、shellファイルを編集します。

$ sudo vi /etc/shells
.
.
.
/bin/zsh
/usr/local/bin/fish ← この一行を追加します。

そしてfishをデフォルトshellに変更します。

$ chsh -s /usr/local/bin/fish

fishermanというfish用のパッケージマネージャーをインストールします。
これはrbenvのパス設定をするためのものです。

$ curl -Lo ~/.config/fish/functions/fisher.fish --create-dirs git.io/fisher

fishermanをインストールすることで、 fisherコマンドが使えるようになります。

$ fisher -v

テーマ設定

次にテーマ設定をします。

まずtheme-bobthefishをインストールしましょう。
theme-bobthefishはoh-my-fishというパッケージマネージャー用のテーマです。

(※参考にした記事では fisher install となっていますが、version3以降はinstall → add にコマンドが変更されました。)

$ fisher add oh-my-fish/theme-bobthefish

多くのテーマはデフォルトで入っているのフォントで対応できないのでpowerlineをインストールします。

$ git clone https://github.com/powerline/fonts.git --depth=1

$ cd fonts

$ ./install.sh

設定 → フォント → 「Powerline」とついたフォントの中から、好きなものを選択してください。

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

プラグインをインストール

僕のおすすめのプラグインはfisher zコマンドです。

$ z (フォルダ名)

で一発でそのフォルダに移動します。
インストールも簡単です。

$ fisher add z

こちらの記事で、おすすめプラグインをまとめてくれています。

futurismo.biz

fishでrbenvを使えるようにする

(※Ruby/Rails使う人向けです。)

fishはconfigファイルの場所がbash,zshと異なります。
pathの通し方は調べてみると色々出てくるのですが、僕が参考にしたのはこちらの記事です。

tech-1natsu.hatenablog.com

最初に rbenvをインストールします。

$ brew install rbenv
$ brew install rbenv ruby-build

次にrbenv pathを通します。
fish.confingを置くディレクトリまで移動します。

$ cd ~/.config/fish/

fish.configがあればそこに、なければ作成してpathを記述します。

$ touch fish.config

$ vi fish.config

以下を記述します。

# rbenv
set -x PATH $HOME/.rbenv/bin $PATH
status --is-interactive; and source (rbenv init -|psub)
.
.
.

sourceコマンドで読み込みます。

$ source ~/.fish.profile

あとは、通常のrbenvのフローと同じです。
(ZEALSでは現在ruby 2.4.1を使っています。)

$ rbenv install 2.4.1
$ rbenv local 2.4.1
$ gem install bundler

実は、ここでなぜかpermissionエラーがでてしまいました。

ERROR: While executing gem ... (Errno::EACCES)
Permission denied @ rb_sysopen - ....

sudo使いまくった

(※ここから先は直接fishと関係ありません)

エラーの対応として、

$ sudo gem install bundler

を使うとエラーが出ず通ったのですが、以降はコマンドを使う際にほとんどpermission errorが出るようになってしまいました。

原因はroot userで無理やり gem install bundlerを行ったことだと考え、./.rbenv/versions配下になるファイルの権限を全て変更してもうまくいきません...
結局半日ぐらいかけても解決策が見つからなかったので、渋々sudoを使い続けることになりました。

続きを読む

【後編】元ドリコム/現メルカリの白石さんと語る、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は毎月第一木曜日に開催していますので、ぜひ参加してみてください!!! コミュニティの公式ページはこちらです。

続きを読む