年末なのでBug Bashしてみたら盛り上がった

Misoca開発チームの北村です。 年末の寒波で山に雪が増えることを期待しています。

年末だしBug Bashやってみた

  • 年越しまでWork-In-Progressな作業を持ち越したくない(年明けに記憶を取り戻すのが大変そう)
  • 休暇直前に大きなリリースはしたくない

ということで、この機会にBug Bashをやることにしました。Misocaで開催するのは初めての試み。

Bug Bashのやり方などはKyashさんの下記の記事を参考にしました。

blog.kyash.co

Bug Bashやってみた

普段一緒に仕事しないメンバーで3チームを作り、Misocaを叩いてみました。 f:id:RKTM:20181227162217p:plain

  • いじわるな入力:めちゃくちゃ長い文字列、HTMLの要素を書き換えて本来想定しない値を設定する
  • ブラウザを2つ立ち上げて、同じデータを同時に編集する
  • URLを書き換えて他の人の情報が見れないか
  • 何度もreloadしたりsubmitする

f:id:RKTM:20181227182821p:plain
色々な言語の文字を入力して確認

興が乗ったエンジニアにより、開発サーバーのアラート通知が荒ぶる様が面白かったです。

f:id:RKTM:20181227183019p:plain
アラートの内容は載せられませんが、サーバーにエラーを吐かせて盛り上がるメンバーの様子をお送りします

バグの数、味わいのあるバグ

1時間強叩いた結果、100件程度のバグが見つかりました(チーム間で重複があること、バグと仕様の区別をしていないので、実際はもっと少ないです)。

バグの共有をしながら 「これよく見つけたね!」 「このぴっこぴっこする動きかわいい」 「この仕様は確かにおかしいね…」 「これ味わいあるわ〜」 と盛り上がりました。

私のチームは、数では他の2チームよりも少なかったものの、「味わい深いで賞」を勝ち取ることができました。

f:id:RKTM:20181227165031p:plain

まさかの優勝はチームではなく個人!?

f:id:RKTM:20181227165412p:plain

チームではなく個人が優勝とな!?

これには背景がありまして、Misocaは12/25にリリースされたRuby 2.6.0で動いています。が、2.6.0版をリリース後、一部処理でエラーが起こるようになりました。

bugs.ruby-lang.org

その不具合を朝イチで検知して、ささっと直してRubyにPRを出しマージされた片桐さんが、今回のBug Bashの優勝と認定されました!*1

バグを見つけたら倒そう

Bug Bashでバグを見つけたるまでを第一部とし、第二部はバグ退治。 ペアプロ・モブプロしながら修正開始。簡単なものは当日中に修正してリリースできました。 tech.misoca.jp

初めてのBug Bashの感想

開発メンバーの感想は以下の通りです。

  • 楽しかった
  • 普段触らない機能やアプリを触れて良かった
  • バグだしは想像以上にいろいろあってマジかーってなった
  • 直すのも年末にやるのは心理的負荷が高いので、バグだしだけでも良かったかもね
  • 開発メンバー以外の人にも参加してほしさがある
  • 自分でやるとバグでそうなところを無意識に避けるクセがでちゃうんだよなー(なので今回のイベントはありがたかった
  • 開発者ではない帽子を被ると色々と気になるところが見えてきた

📢 宣伝

MisocaではBugを発見・駆逐するエンジニアを募集しています!また、最新のRubyをすぐにプロダクトに取り込みたい人も募集しています!

www.wantedly.com

*1:本当はBug Bashの枠外なので、厳密には優勝ではないのですが…

Misocaにデザイナーとしてjoinしました

この記事はMisoca+弥生+ALTOA Advent Calendar 2018の25日目の記事です。

12月からMisocaのデザイナーとして働いている、とりみずのです。

入社して3週間ほど経ちましたので、入社エントリーも兼ねてその期間に行ったことを通して、これから実践したいこと、入社して感じていることなどをお伝えしていきます。

行ったこと

①サービス理解を深める

Misocaは取引で発生する請求書などの文書を、クラウド上で作成から郵送まで1分で行えるサービスです。

現在はWeb版のクラウドアプリ・iOSアプリ・Androidアプリ、の3つのデバイスにてサービス提供しているのですが、私は入社するまでMisocaを使用したことがありませんでした。

そこでサービス理解を深めるため、まずそれぞれの機能を試し、気づきをまとめることにしました。

気づきは下記の4つの観点であげています。

  • いいなと思ったところ
  • 装飾的に気になるところ
  • もっとよくなりそうなところ
  • 聞きたいところ

iOSアプリはこんな感じでまとめていきました↓

f:id:torimizuno:20181225094937p:plain

気づきをまとめている時、エンジニアの方が「手が空きそうなんだけどなんかある?」とタイミングよく聞いてくれたので、共有してその場でやるやら優先度をつけていきました。

やっちゃうね〜とすぐ着手してくれて、どんどん改善されていったので嬉しかったです!

Web版はすぐには着手は難しそうな改善箇所もあるため、それは別プロジェクトで進める方向にしました。

Androidは相談する隙間を西の方を見つめながら狙っています…フフフ。

②ユーザー体験統一プロジェクトの立ち上げ

3つのデバイスでサービスを触り、Misocaでユーザーは何ができるかの大枠を知ることができました。

同時に細かな部分から大きな部分まで「環境ごとにユーザー体験が異なる状態になっていること」に気がつきました。

そこで、その課題を解決していくためのプロジェクトを立ち上げることにしました。

まずこの課題は私だけが感じたものなのか、社内のみんなも同じような課題を感じているのかを知るため、インセプションデッキを起こし、すりあわせ会を開くことにしました。

(Misocaでは「なぜ」を明確にするために、どなたでもインセプションデッキを起こしてプロジェクト立ち上げをしています)↓

f:id:torimizuno:20181225095418p:plain

すりあわせ会は、関連メンバーの他に興味もある方もぜひとお伝えしたところ、10名近く参加してくれました…!🙏

f:id:torimizuno:20181225100337p:plain

すり合わせ会では「スマホアプリ版とWeb版で利用シーンや違うターゲットを想定していくならそのことも考えていく必要があるよね」いう声や「請求書をつくるフロー自体の体験が違ってるから、そういった粒度で揃えたい」「ロードマップに載せて動いてはどうか」などの声がエンジニアの方から上がってきたりして、どうやっていくかの一歩目の話ができ、とてもいいな〜と感じました。

そこで出たみんなの意見をプロダクトオーナーと相談し、まず「サービスブランドレベルとして統一する」を目指していく方針をたてました。

こちらは動き始めたばかりですので、今後の活動をまたどこかの機会で共有できればと思っています💪

③デザイナーへのヒアリング

Misocaはエンジニア集団の集まりというイメージが強いと思うのですが、実は外部パートナーのデザイナーさんが2名と、社内デザイナーさんが1名いるという体制です。

外部の方はスマホアプリを担当、Web版を担当、とそれぞれ仕事の進め方や社内との関わり方も違っているようなので、まず下記の点のヒアリングを実施しました。

  • 開発チームとどのような流れで仕事をしているか
  • どのような業務が発生しているか
  • どのようなツールを仕様しているか
  • デザイン素材のデータ管理やバージョン管理をどうしているか
  • 現状抱えているタスクはなにか
  • これからこうしていきたいと考えていることや相談など
  • ポートフォリオの共有

この中で特に聞いてよかったと感じたのは、こうしていきたいの部分とポートフォリオの部分でした。

おかげでパートナーさんはどういうことが得意なのか、苦手なのか、どういうことをしたいのかを知ることができ、では今後特にこの部分でご協力をいただきたいです、という話をすることができました。

パートナーのひとりの方の日報で、自分の役割が明確になってよかったという言葉を目にできたのも嬉しかったです。

もし今後他の会社に行ったときも、互いの得意分野を知り協力しあえるよう、この取り組みは実施したいなと思いました。

④簿記とるぞチャンネルの立ち上げ

Misocaを主に利用される方は、請求書を発行したり送ったり…いわゆる経理の方だったり、個人事業主の方々です。

その中では「売掛金」や「売上」「資産」などの言葉が当たり前のように出てくるのですが、なんとな〜くは知ってても意味をちゃんと理解してない…言葉が多く、このままではユーザー理解ができない…😭😭😭 となった結果、簿記をとることを決意しました。

社内に何人か簿記とる人がいるよ〜と教えてもらったので、その勢いでslackに簿記取るぞチャンネル、通称「#talk_boki_toruzo」を立ち上げました。

f:id:torimizuno:20181225095732p:plain

最近ではリマインダーが簿記の勉強したか聞いてくるようになったので、みんな各々の進捗をあげています。

f:id:torimizuno:20181225171928p:plain

ひとりで勉強しているより楽しくなったのと、既に簿記を習得している先人たちが教えてくれる場面もあり、見ていて楽しいです笑

f:id:torimizuno:20181225160357p:plain

みんな… 簿記とるぞ!!!!!💪

まとめ

そんな感じで入って三週間ですが、さっそく色々なプロジェクトに入らせてもらっていて、楽しく仕事ができています。

入社したてのタイミングでロードマップも共有され、会社の進んでいきたいビジョンを明確に知ることができたのも個人的には大変ありがたかったです。

Misocaは今後も取引のプラットフォームを目指して、まだまだユーザーに届けたい価値がたくさんあります。

エンジニアも引き続き募集中ですが、私と一緒にサービス全体のユーザー体験を底上げしてくれるデザイナーや、改善施策を回し続けてくれる方も募集しております。

気になった方は、お気軽に会社見学やメッセージなどいただけたら嬉しいです。

recruit.misoca.jp

ここまでお読みくださりありがとうございました。

それでは良いお年を〜〜〜〜!

esa のチームを増やした話

こんにちは @mallowlabs です。 最近は [ALEXANDROS] の「Sleepless in Brooklyn」というアルバムを聴いています。 「明日、また」という曲がお気に入りです。

Misoca では情報共有ツールとして esa.io をヘビーに使っています。 今回、親会社である弥生の一部のメンバーにも使ってもらい、より情報共有を加速することにしました。 しかし、現在の esa には採用プロジェクトに関する情報など、そのまま共有することができない情報も含まれているため、思い切って Misoca + 弥生のメンバーが見られる esa のチームを作り、そこに共有できる情報をすべて移行することにしました。

ちなみに esa は 複数チームの決済連結 という機能があり、複数チームでもお得に使うことができます。

移行をどうするか

「移行することにしました」と言っても、考えることはたくさんあります。

  • 移行対象のページが大量にあり、手動ではとても移行できない。
  • 元の esa チームのページ作成者の情報は引き継ぎたい。
  • コメントも引き継ぎたい。
  • 移行に伴うリンク切れは最小限にしたい。

そこで esa のチームの移行ツールとして wataridori を開発しました。

github.com

wataridori には以下の機能があります。

  • コピー元のチームの特定のカテゴリ以下のページとコメントをすべて、コピー先のチームにコピーする
  • この時に作ったページの ID の対応表を YAML に出力する
  • 出力しておいた YAML を使って、コピー先の記事のリンクを修正する

リンクの修正部分は テストを書いて 真面目にやったので、なかなか賢くできています。

移行当日

このツールのおかげで、コピー先のチームにページを短期間で移行することができました。 コピー元のチームの記事は、手動でカテゴリごとアーカイブしました。

移行当日には esa の中の人にお願いして API rate limit を一時的に増やしてもらいました。 esa のサポートにはいつも親切にしていただいているので、この場を借りて感謝の気持ちを伝えさせていただきます。 いつもありがとうございます!

移行後

このツールのおかげで特に混乱もなく…と言いたい所ですが、いくつかの問題が起こりました。

コピー元の esa 記事を参照している外部のツールは手動で書き換える必要がある

当たり前といえば当たり前なのですが、リンクの修正は esa のページのみが対象なので、他のツールに書かれた URL は書き換わりません。 これは見つける度に URL を修正しています。

古い記事を開いて編集してしまった

移行済みの古い記事には一括で DEPRECATED!!! と追記して、わかりやすくするスクリプトをあとから書きました。

favicon だけではどちらのチームか区別できない

これは他のメンバーにはあまり賛同を得られなかったのですが、favicon だけでどちらのチームを開いているかわからずに困ってしまいました。

そこで favicon に背景色をつける Chrome Extension をでっちあげました。

github.com

f:id:mallowlabs:20181218123711p:plain
before

f:id:mallowlabs:20181218123725p:plain
after

可愛い感じにできて、個人的には気に入っています。

まとめ

いくつか細かい問題はあったものの、無事 esa のチームを増やすことができました。 また、移行に使ったツールも OSS として公開することができました。 使っているツールで課題があった時に、ちょっとしたツールを作って問題を解決し、それを OSS にする文化はとても良いなと感じています。

採用

Misoca ではちょっとした OSS を作って、開発環境をより良くしていくエンジニアを募集しています!

www.wantedly.com

🎄Misoca、アドベントカレンダーやるってよ

先週に引き続きMisoca開発の黒曜です。

ほたるちゃん のCDデビューが決まったので、来年春が楽しみです。

🗓アドベントカレンダー

昨年に続き、今年もアドベントカレンダーをやってます。

f:id:kokuyouwind:20181213125401p:plain

今年は弥生株式会社ALTOAとの合同開催になってます。このブログでは見慣れないアイコンがいっぱいありますね。
カレンダーを立てたのは自分ですが、余ったところに入ろうと思っていたらあっという間に全部埋まっていました。

そんなわけで自分は不参加です。
ただ各人珠玉の非業務ネタで攻めていて開発ブログには誰も書いてなかったので、宣伝がてらこの記事を書いています。
もう半分終わってしまっていますが、まだ半分も残ってるということで…

どの記事も素晴らしいので、ぜひご一読ください。
個人的おすすめは、めっちゃバズって500はてブを超えたマルチカーソルを使わないVSCodeはただのVSCodeだ!です。

小ネタ: Terraformの結果をデスクトップ通知する

宣伝だけだと寂しいのでちょっとした小ネタを。

MisocaではTerraformを使ってAWSの設定をコード化して管理しています。

ただ terraform planterraform apply は地味に時間がかかり、ぼーっと待つには長いのですが他の作業をやると結果確認を忘れてしまったりします。

🖥terminal-notifier

そこでterminal-notifierを使って、planやapplyが完了したらデスクトップ通知を送るようにしました。

ついでにterraform-landscapeを使ってplanの結果を整形し見やすくしています。

結果、以下のようなエイリアスでわりと使い勝手良く利用できています。

alias tplan='terraform plan | bundle exec landscape | tee /tmp/plan.log; cat /tmp/plan.log | grep -E "^Plan|^No" | xargs -I{} terminal-notifier -title "Terraform Plan Finished" -message "{}" '
alias tapply='terraform apply -auto-approve | tee /tmp/apply.log; cat /tmp/apply.log | grep "^Apply" | xargs -I{} terminal-notifier -title "Terraform Apply Finished" -message "{}"'

ザ・ワンライナーですね。
なおこのスクリプトではlandscapeをbundler経由で入れている前提になっていますが、brewで入れているなら bundle exec は不要です。

実行例

実際にtplanして、変更がないとこんな感じの通知が来ます。

f:id:kokuyouwind:20181213132256p:plain

一方で変更があるとこんな感じ。

f:id:kokuyouwind:20181213132320p:plain

コンソールのほうを見ると、以下のように差分が確認できます。
今回はThorタスクを実行するRunCommand用SSM Documentの更新で、選択できるタスク名が増えたdiffになっています。*1

CLANNAD:kokuyou% tplan
~ module.ssm_documents.aws_ssm_document.RunThorTask
    content:   "type": "String",
                        "allowedValues": [
                          "list",
               +          "test:example"
                        ]
                      },
                      "executionTimeout": {
                        "type": "String",
                        "default": "3600",

Plan: 0 to add, 1 to change, 0 to destroy.

問題なさそうなのでtapplyすると以下のような通知が来ます。*2
[0m が残念感ありますが、まぁ実用上問題はないでしょう。

f:id:kokuyouwind:20181213132734p:plain

こうしてterraformの実行中はちょっとした他作業をしつつ、コマンドが完了したら即結果を確認、そのまま後続作業に取り掛かれるようになりました。

terminal-notifierは工夫次第で色々使えそうなので、ぜひお試しください。

📢宣伝

Misocaではアドベントカレンダーの記事を書きたい、もしくは参加しそびれて腹いせにワンライナーを書きたいエンジニアを募集しています。

www.wantedly.com

*1:タスク名は適当なものに変えてます

*2:通知が来たタイミングをスクショしそこねたので通知ログの画像を使ってます。このためtplanのと見た目が違いますが、ホントは同じように通知されています

SwitchRoleを使用してIAMユーザ管理を楽にする

Misoca開発チームの@kokuyouです。

最近新しいMac miniが届き、MacBook Proとの2台体制になったので、区別しやすいようマシン名をつけました。
MacBook Proのマシン名がKanon、Mac miniのマシン名がCLANNADとなっております。*1

f:id:kokuyouwind:20181122130446p:plain

f:id:kokuyouwind:20181122130454p:plain

これに対する某氏の反応がこちら。

f:id:kokuyouwind:20181122130508p:plain

はい。

🧑IAMユーザ増えすぎ問題

Misocaではサービスの開発・運用にAWSを活用しています。 この際に各環境の設定が混在しないよう、以下のようにAWSアカウントを分けています。

  • sandbox : 自由に各種設定を試せる砂場環境
  • development : 開発系のEC2やサービス設定を行う環境
  • production : 本番系のEC2やサービス設定を行う環境

これによって各リソースがどの環境のためのものかわかりやすくなり、「開発用の設定を弄ったら本番にも影響しちゃった!」という事態も防ぐことができます。
また「開発環境は自由に触れるが、本番環境は設定参照のみが可能」といった、環境基準でのIAMポリシーもシンプルに表現できます。

しかし、この運用では各環境ごとに全員分のIAMユーザを発行・管理する必要があります。
開発者が増えるごとに、IAMユーザの発行を3回行う必要があるわけです。

また開発者が利用する際も、AWSコンソールでIAMユーザを切り替えるたびにログインしなおす必要があります。
アカウント名が被っているとブラウザがパスワードを1環境分しか覚えてくれなかったりと、これもなかなか面倒です。*2

🎭 IAMユーザ集約とロール切り替え

そこで、ロールの切り替えを利用して他のアカウントのロールに切り替える方法を導入しました。

ログイン専用のAWSアカウントを新たに作成し、IAMユーザはこの環境にのみ作成します。 開発者はIAMユーザでログイン後、各環境のロールに切り替えることで、開発環境や本番環境での作業を行えるようになります。

ロールやポリシーの設定はClassMethodさんの記事を大いに参考にしています。

以下で導入手順を大まかに解説します。

既存環境へのロール追加

これまでは AdminDeveloper などのIAMグループを作成し、IAMユーザをグループに割り当てることで権限を管理していました。
これを置き換えるため、それぞれのグループに対応する切り替え用IAMロールを作成します。

「信頼されたエンティティ」には、ログイン環境のAWSアカウントIDを入力します。

f:id:kokuyouwind:20181122135242p:plain

ポリシーは、既存のグループについているものをそのまま選択します。 ただし「自分のMFAデバイスを設定する」などのIAM絡みのポリシーは必要なくなるので、そういったポリシーは省きます。

f:id:kokuyouwind:20181122135334p:plain

ロール名はグループとの対応がわかりやすいよう、同じ名前をつけました。
これについては、 SwitchRoleDeveloper などのように、SwitchRole用だとわかりやすい名前にしたほうが管理しやすいかもしれません。

f:id:kokuyouwind:20181128173212p:plain

ログイン環境の設定

続けて、ログイン用の環境からロール切り替えできるようにしていきます。

ロールの切り替えは sts::AssumeRole というアクションです。
先ほど開発環境に作ったIAMロールが arn:aws:iam::000000000000:role/Developer であれば、以下のようなポリシーを作ることでロール切り替えを許可できます。

f:id:kokuyouwind:20181128173829p:plain

ポリシー名は環境とロールのペアがわかりやすい名前にしておくと後々管理しやすいです。

以下の例だと開発環境(DevEnv)にある開発者ロール(DeveloperRole)で、用語が被ってしまい分かりづらいですね…

f:id:kokuyouwind:20181128174259p:plain

あとは、このポリシーを各IAMユーザに付与することで、そのユーザは該当ロールに切り替えられるようになります。

実際にロールを切り替える

ログイン環境に入り、アカウントメニューにある「ロールの切り替え」からアカウントを切り替えることができます。

f:id:kokuyouwind:20181128174838p:plain

成功すると、右上のアカウント表示が指定した名前と色に変わります。
今入っている環境がわかりやすいよう、一定のルールで名前と色を設定するのがおすすめです。

f:id:kokuyouwind:20181128175110p:plain

設定Tips

  • 1つのロールごとに対応する切替ポリシーをログイン環境に作り、それを束ねるグループを作ると扱いやすい
    • DeveloperグループにDevEnvDeveloprポリシーとProdEnvReadOnlyポリシーをアタッチする、といった管理ができる
  • ロール切替の情報入力はけっこう面倒なので、切替リンクをまとめておくと布教しやすい
  • IAMポリシー割当を弄るだけで好きな環境・好きなロールに切り替えられるので、ログイン環境のIAM権限は限られたユーザにのみ付与する

👍 SwitchRoleでよいところ

  • 当初の想定通り、環境の切り替えが非常に楽になった
    • 管理するログイン情報が1つだけで済む
    • 新しい人が入ったときも、IAMユーザを1つ作るだけ
  • ログイン環境のIAMだけ見れば「誰が何をできるか」が概ね分かるようになった
  • より弱い権限での動作確認がしやすくなった
    • 「管理者以外はこのバケットを見れなくしたい」といった設定をAdministratorアカウントで動作確認するのはなかなか難しかったけど、Roleを切り替えるだけでできるようになった

🤔 SwitchRoleの気になること

いま入っている環境が分かりづらい

右上のロール表示を見ればわかるんですが、あまり目立たないのでうっかり間違えそうになります…

特に大きいディスプレイで作業していると表示が小さくなるので見落とし率が上がります。

f:id:kokuyouwind:20181128182032p:plain

画面中央を注視して作業してると、ここはまず見ないですよね…

どうせならヘッダーの背景色も同じ色にしてくれるとわかりやすいんですが、そういった機能はないようです。

同じことを考える人はいるようで、AWS Extend Switch RolescolorAWSFrameといったChrome拡張を使えば多少はわかりやすくなります。

Roleの信頼するエンティティにIAMグループを指定できない

SwitchRoleに使うロールには信頼関係を設定できます。
ログイン環境のアカウントIDを設定した部分ですね。

f:id:kokuyouwind:20181128182813p:plain

GUIからはアカウント単位までしか設定できませんが、JSONを直接編集することでIAMユーザ単位でも信頼するエンティティを設定することができます。
「ログイン環境のkokuyouのみを信頼する」といった設定をしておけば、ログイン環境側のポリシーをどう弄ってもそれ以外のユーザは切り替えられなくなるわけですね。
この設定は複数のIAM Userがあるアカウントをスイッチ元として、クロスアカウント用IAM Roleを作るにも書いてあります。

とはいえ、ユーザ単位で信頼関係を管理するのは管理が大変そうです。 できれば「ログイン環境のAdminグループを信頼する」といった設定をしたくなってきます。

残念ながら、信頼関係に設定できるのはIAMユーザ、IAMロールのみで、IAMグループは設定できないようです。
アカウント単位で信頼してもさほど問題はないのですが、できれば最小限にしたいところですね。

🌈 今後やりたいこと

現状は手作業でIAMユーザを作ってSwitchRole用グループを割り当てていますが、この辺をterraformで管理してPull RequestベースでのIAMユーザ追加・IAMグループ割当ができると、手作業を減らせるうえ履歴も追いやすい形で残って良さそうです。

また、本番環境では「一部S3バケットのみアクセスできる」などのポリシーが設定されています。
しかし、他のポリシーと一緒に設定した状態で意図通り動くかは結構分かりづらく、都度手作業で確認しています。

こうした部分も、ロールごとにawspec でテストを書いてCIできるようにしていけると良いなと思います。

📢 宣伝

MisocaではAWSを使いこなしたいエンジニアを募集しています!

www.wantedly.com

*1:どっちもAIRじゃない、というのがポイントです

*2:Chromeでユーザを複数作り、それぞれのChromeユーザごとに別のIAMユーザでログインするという運用をしている人が多いようです

Rails 6.0 での新機能 Action Text を試してみた

id:eitoball です。秋ですね。読書の秋といいますが、先日、「われはレギオン」のわれらはレギオン 3: 太陽系最終大戦 (ハヤカワ文庫SF)を読み終えました。物語のテンポがよく、気持ちよく読むことができました。Sci-Fi小説が好きな方には特にお勧めします。(われらはレギオン1 AI探査機集合体 (ハヤカワ文庫SF)われらはレギオン2 アザーズとの遭遇 (ハヤカワ文庫SF) もあわせてお勧めします。)

先日、会社で同僚の何人かと一緒にDHHのAction Textを紹介するYouTube動画を見ました。( Alpha preview: Action Text for Rails 6 )見るだけではつまらないので実際に試したいと思います。

Action Text とは?

Action Text とは、Rails 6.0 で予定されている新機能の1つです。リッチテキストを編集・表示するコンポーネントをページ内に簡単に組み込むことができます。

Basecamp で開発されてきたものを gem として抽出したものです。リッチテキストの扱う部分の主な技術は、trix というJavaScriptライブラリです。これもBasecampで開発されたライブラリです。

Action Text を試してみる

Action Text をDHHの紹介動画と同じように試してみます。Rails 5.2 が使える環境を前提としています。他には、imagemagickとyarnが使えるようになっている必要があります。

アプリケーションの作成

アプリケーションを作成します。そして、作成したアプリケーションのディレクトリに移動します。

$ rails new sample
...
$ cd sample

開発版のrailsに更新

Active Storage で必要な機能が最新版にしかないので開発版のrailsに更新します。また、ついでにwebpackerを追加します。Gemfile を以下のように変更して、bundle install します。

diff --git a/Gemfile b/Gemfile
index 8692b33..5826e6d 100644
--- a/Gemfile
+++ b/Gemfile
@@ -4,7 +4,7 @@ git_source(:github) { |repo| "https://github.com/#{repo}.git" }
 ruby '2.5.1'

 # Bundle edge Rails instead: gem 'rails', github: 'rails/rails'
-gem 'rails', '~> 5.2.1'
+gem 'rails', github: 'rails/rails'
 # Use sqlite3 as the database for Active Record
 gem 'sqlite3'
 # Use Puma as the app server
@@ -35,6 +35,7 @@ gem 'jbuilder', '~> 2.5'

 # Reduces boot times through caching; required in config/boot.rb
 gem 'bootsnap', '>= 1.1.0', require: false
+gem 'webpacker', github: 'rails/webpacker'

 group :development, :test do
   # Call 'byebug' anywhere in the code to stop execution and get a debugger console

そして、webpacker を使えるようにします。

$ bundle exec rails webpacker:install

そして、app/views/layouts/application.html.erb を以下のように変更します。

diff --git a/app/views/layouts/application.html.erb b/app/views/layouts/application.html.erb
index cf19a4b..c0e1732 100644
--- a/app/views/layouts/application.html.erb
+++ b/app/views/layouts/application.html.erb
@@ -5,8 +5,8 @@
     <%= csrf_meta_tags %>
     <%= csp_meta_tag %>

-    <%= stylesheet_link_tag    'application', media: 'all', 'data-turbolinks-track': 'reload' %>
-    <%= javascript_include_tag 'application', 'data-turbolinks-track': 'reload' %>
+    <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
+    <%= javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' %>
   </head>

   <body>

Action Text のインストール

Action Text をインストールします。Gemfile を以下のように変更して、bundle install します。

diff --git a/Gemfile b/Gemfile
index 5826e6d..5739b2d 100644
--- a/Gemfile
+++ b/Gemfile
@@ -37,6 +37,9 @@ gem 'jbuilder', '~> 2.5'
 gem 'bootsnap', '>= 1.1.0', require: false
 gem 'webpacker', github: 'rails/webpacker'

+gem 'actiontext', github: 'rails/actiontext', require: 'action_text'
+gem 'image_processing', '~> 1.2'
+
 group :development, :test do
   # Call 'byebug' anywhere in the code to stop execution and get a debugger console
   gem 'byebug', platforms: [:mri, :mingw, :x64_mingw]

そして、Action Text を使えるようにします。

$ bundle exec rails action_text:install
...
$ bundle exec rails db:migrate
== 20181231000000 CreateActiveStorageTables: migrating ========================
-- create_table(:active_storage_blobs)
   -> 0.0047s
-- create_table(:active_storage_attachments)
   -> 0.0043s
== 20181231000000 CreateActiveStorageTables: migrated (0.0092s) ===============

== 20181231000001 CreateActionTextTables: migrating ===========================
-- create_table(:action_text_rich_texts)
   -> 0.0042s
== 20181231000001 CreateActionTextTables: migrated (0.0043s) ==================

ここで3つのテーブルが作成されます。テーブル名からaction_text_rich_textsにリッチテキストが格納されるようです。

Post モデルを作る

リッチテキストを格納するPostというモデルをscaffoldを使って作成します。

$ bundle exec rails generate scaffold Post title:string
...
$ bundle exec rails db:migrate
...

そして、この例のようにリッチテキストを追加できるように以下のように変更していきます。

diff --git a/app/controllers/posts_controller.rb b/app/controllers/posts_controller.rb
index 21c2d4e..d566eaf 100644
--- a/app/controllers/posts_controller.rb
+++ b/app/controllers/posts_controller.rb
@@ -69,6 +69,6 @@ class PostsController < ApplicationController
 
     # Never trust parameters from the scary internet, only allow the white list through.
     def post_params
-      params.require(:post).permit(:title)
+      params.require(:post).permit(:title, :content)
     end
 end
diff --git a/app/models/post.rb b/app/models/post.rb
index b2a8b46..6015acb 100644
--- a/app/models/post.rb
+++ b/app/models/post.rb
@@ -1,2 +1,3 @@
 class Post < ApplicationRecord
+  has_rich_text :content
 end
diff --git a/app/views/posts/_form.html.erb b/app/views/posts/_form.html.erb
index ed01b8b..caeb58d 100644
--- a/app/views/posts/_form.html.erb
+++ b/app/views/posts/_form.html.erb
@@ -16,6 +16,11 @@
     <%= form.text_field :title %>
   </div>
 
+  <div class="field">
+    <%= form.label :content %>
+    <%= form.rich_text_area :content %>
+  </div>
+
   <div class="actions">
     <%= form.submit %>
   </div>
diff --git a/app/views/posts/show.html.erb b/app/views/posts/show.html.erb
index 947ae98..6584299 100644
--- a/app/views/posts/show.html.erb
+++ b/app/views/posts/show.html.erb
@@ -4,6 +4,7 @@
   <strong>Title:</strong>
   <%= @post.title %>
 </p>
+<%= @post.content %>
 
 <%= link_to 'Edit', edit_post_path(@post) %> |
 <%= link_to 'Back', posts_path %>

has_rich_text とか form.rich_text_area が、Action Textによって追加されたメソッドです。

リッチテキストを編集する

Railsサーバーを起動して、実際にリッチテキストを編集してみます。サーバーを起動したら、http://localhost:3000/posts にアクセスして、"New Post" をクリックします。

$ bundle exec rails sever
...
[Webpacker] Compiling…
...

[Webpacker] Compiling… の表示から、webpacker が動作していることが分かります。

<%= form.rich_text_area :content %> と記述した部分にリッチテキスト用のウィジェットが表示されていると思います。ツールバーでテキストを太字にしたり取り消し線を追加することができます。また、画像はドラッグドロップして追加することができます。

f:id:eitoball:20181116131329g:plain
画像をドラッグドロップして追加する

最後に

動画と同じようにさっとリッチテキストに対応ができました。Action TextのGitHubのページには、Action Text is destined for inclusion in Rails 6, which is due to be released some time in 2019. と記載されています。来年のリリースが楽しみです。

採用

Misocaでは、RailsやRubyの新しい機能に興味あるエンジニアも募集しています。

www.wantedly.com

Misoca に必要なことを全て受入プロジェクトで学ぼうとしたら驚いた

こんにちは、@mallowlabs です。 10月から Misoca にジョインし、現在は東京からリモートワークをしています。 入社日に台風の影響で新幹線が止まってしまい、初日から休みそうになりましたがなんとか入社できました。

Misoca では入社後、受入プロジェクトに配属されて、仕事の進め方を学んでいきます。私の場合には、@zetta1985Misocaに必要なことは全て受入プロジェクトで学んだ という記事を熟読してからプロジェクトに望んだので進め方のイメージはあったのですが、それでもいくつか驚いたことがあるので紹介したいと思います。

ということで先に以下の記事を読んでおくと読みやすいです。 tech.misoca.jp

受入担当はフルリモート勤務

私は東京で働いていますが、受入プロジェクトのはじめの2週間は名古屋の Misoca のオフィスで働きます。 ですが、なんと受入担当はフルリモート勤務の方です。 Slack や Zoom を使ってやりとりし、ペアプログラミングも Slack で画面共有しつつ、Visual Studio Code の Live Share を使って行いました。

最初の印象としては「名古屋に滞在してるのに名古屋勤務の人と一緒に仕事しないの!?」と少し驚きましたが、Misoca はリモートでもオフィスでもどちらでも普通に働ける環境を作っているので、最初の段階でリモートを前提にした働き方を学べたのでとてもよかったです。

以前はオフィス勤務の人が受入をしていたようですが、リモートの人が受入をやってもいいよね?という感じでフルリモートの人も受入をやるようになったそうです。

1ヶ月プロジェクトの前に数日で終わる小さなプロジェクトがある

Misocaに必要なことは全て受入プロジェクトで学んだ ではいきなり1ヶ月のプロジェクトに配属されていたので、そういう心持ちでのぞみました。 ですが、実際には簡単なエラーメッセージの修正を行う小さなプロジェクトから始まりました。

このプロジェクトでは、GitHub を使った開発の進め方の説明や、ヘルプページの変更をどのように進めていくかなど、開発やリリースプロセスの学習をしました。 Ruby はもちろん GitHub を仕事で使うのも初めてだったので、基本的なところから確認ができました。

いきなり1ヶ月のプロジェクトをやるつもりで入社したので、こういうチュートリアルを兼ねたプロジェクトがあるのはとても助かるなと思いました。

受入プロジェクトで画面を変えることもある

Misocaに必要なことは全て受入プロジェクトで学んだ では

  • 実装難易度が低い
  • UIに影響を与えない(見た目の変更がない)
  • DBマイグレーションが必要
  • データマイグレーションが必要
  • 運用担当との調整が必要

といった特性が挙げられていましたが、私の場合には以下のような特性のプロジェクトでした。

  • 実装難易度が低い
  • UI を変更する
  • UI をどうするかは詳細は決まっていない(仕様の調整から始まる)
  • DB マイグレーションは必要
  • 運用担当との調整が必要

「受入プロジェクトなのでまずは裏側から触るのかー」と思っていただけにこれも驚きでした。 入社していきなりいろんな人との仕様の調整を行うのは正直大変でしたが、受入担当の方がリードしてくださったのでなんとかなりました。

「一つのやり方にこだわらず、いろいろやってみる」という Misoca の文化がこういうところにも出ているのだと感じています。

数日のプロジェクトでもふりかえりをしっかりやる

Misoca ではふりかえりをとても大切にしています。 前述のエラーメッセージを修正するだけの簡単なプロジェクトでも、プロジェクト終了後に「事後検証」と呼ぶ、「何か学びはあったか?」をふりかえるイベントを実施しました。

正直な印象として「こんなに小さなプロジェクトでも事後検証をするんだな」と思いながら参加していましたが、受入プロジェクトの中でわかりづらかったことや、不安に感じたことを共有したら、それが学びとして記録・共有され、それを解消するような対応(今回は esa 記事の修正や受入フローの改善)がすぐに行われました。

Trello で振り返り:

f:id:mallowlabs:20181107134329p:plain:w320

esa を修正:

f:id:mallowlabs:20181107134344p:plain

代表の豊吉が 「PDCAって本当にまわるんだ〜」 と何度も思うと言っていましたが、まさに同じ気持ちになり、Misoca のプロセス改善へのしっかりとした取り組みに驚きました。

まとめ

私が受入プロジェクトで感じた驚きを記事にしてみました。 受入プロジェクトを通して Misoca の常に改善していくやり方を体感でき、驚きつつも Misoca の文化やプロセスを学べたと思います。 受入プロジェクトについて @zetta1985 の場合とは少し違った角度から紹介できていれば幸いです。

採用

Misoca では受入プロジェクトだけでなく、プロセスや、そして世の中を改善していきたいエンジニアを募集しています!

www.wantedly.com