おもしろwebサービス開発日記

Ruby や Rails を中心に、web技術について書いています

headless chromeでcookieを扱う方法

poltergeistからheadless chromeへ移行する時に気をつけること - メドピア開発者ブログ の続きです。poltergeistとheadless chrome(selenium-webdriver)でcookieの扱い方が違うので、違いを簡単にまとめておきます。

poltergeistの場合

専用のAPIが用意されています。簡単。

page.driver.set_cookie('name', 'value')

page.driver.cookies['name'].value

詳しくは公式を参照してください: teampoltergeist/poltergeist: A PhantomJS driver for Capybara

headless chromeの場合

headless chromeにはpoltergeistほど気の利いたAPIがありません＞＜ヘルパメソッドを作ってあげるとやりやすいです。次のようなmoduleを作って、適宜includeしてください。

module FeatureHelper
  def cookie_value_from(name:)
    cookies = page.driver.browser.manage.all_cookies
    cookie = cookies.find { |c| c[:name] == name }
    cookie && cookie[:value]
  end

  def add_cookie(name:, value:)
    page.driver.browser.manage.add_cookie(
      name: name,
      value: value.to_s
    )
  end
end

注意

add_cookieする際には、必ず一回はページをリクエストしておく必要があります。つまり

add_cookie(name: 'hoge', value: 'fuga')
visit users_path

のようなコードはエラーになります。適当なページを一度ロードしておくとうまく動きます

visit root_path
add_cookie(name: 'hoge', value: 'fuga')
visit users_path

Railsの可読性の高いコードについて議論するコミュニティを作りました

Railsで可読性の高いコードを書くにはどうしたらいいのか。コミュニティやブログなどで個別の事例について言及されることはありますが、横断的なまとまった情報はほとんどないのではないかと思います。みんな、散らばった情報を集めて自分なりのやり方を模索しているのではないでしょうか。

そこで、自分なりのやり方を研ぎ澄ませるような、可読性の高いコードについて議論できる場所を作ってみました。clean-rails.orgというドメイン*1です。コミュニティ本体はサブドメインのdiscourse.clean-rails.orgで、オンライン上できれいなコードについて議論できるようにしています。

可読性の高いコードを書くのが好きな方、参加してコメントいただけるとうれしいです(\( ⁰⊖⁰)/)

これまでの経緯

はじめの一歩としてGitHubのIssue上で情報やり取りできるかな、と思って試したのですが反応がイマイチだったので、仕切り直して再出発という感じです。

運営に参加してくれる人も若干名募集しています。最近まとまった時間を取りづらいので、いろいろ手助けいただけると＞＜興味ある方は何らかの形で前島(willnet)までご連絡ください。

コミュニティが盛り上がって議論に足る情報が出揃ったら、オフラインでミートアップなどできるといいなーと考えています。よろしくおねがいします(\( ⁰⊖⁰)/)。

*1:名前が強すぎる感じがしますが、jpドメイン高かったのでついorgにしてしまいました…＞＜

技術顧問業を始めて2年がたった

2年ほど前から「フリーランスRails技術顧問」みたいな肩書で複数社のお手伝いをしています。すると知り合いに、技術顧問って実際どんな感じで仕事してるの？と聞かれることが多いので、「これ読めばわかるよ」と言えるように実際にどんなことをしているのかまとめておこうかと思います。

ざっくりどんなことしてるの

お手伝いしている会社によってやっていることが違うので一言では答えにくいですね。基本的に「僕の身につけたRailsとシステム開発の知見を提供する」というのが共通しているところ。僕はCTO経験などないのでエンジニア組織についてはあまり触れず、技術寄りの知見について特化して伝えている感じです。

だいたい次のような会社が対象。全部Railsを使っているか、これから使おうとしている会社です。

  • 創業から数年たち業務が拡大してきたが、負債が溜まって身動きが取りづらくなってきたのでちゃんと体制を整えたい
  • 負債がたまるのを防ぐために、最初から専門家の知見を取り入れて開発したい
  • 多言語からRubyに乗り換えたいが社内のエンジニアにRubyが分かる人が少ない

もう少し具体的に

基本的には週1程度出社して、その間いろいろやりますという契約形態が多いですね。基本リモートでやっている会社もありますが、個人的に出社する方が性に合っているのと、リモートで顧問っぽいバリューを出すの難しいなと思っているので、なるべく出社する方に寄せています。

いろいろやりますの内訳はだいたい次の4つ

  • 技術相談
  • 技術的に難しいところを任せてもらう
  • 社内教育
  • その他

技術相談

一番技術顧問っぽいお仕事ですね。いろいろな相談や質問をうけています。普通にコードレビューもしてます。

例

  • Aという機能を実装したいんだけど、こういうテーブル設計で大丈夫ですかね
  • Bをする時のgemで一番いいのなんですか
  • Cという機能をつくったのだけど、もっと良い実装の仕方がありそうなのでレビューして指摘してほしい

技術的に難しいところを任せてもらう

相談されたときに「これはちゃんと調べないといけないやつだ」となったらちゃんと時間をとって調べます。たいてい、gemやrailsのソースコードを読んで裏を取って回答することが多いです。

あとは納期的に余裕があって、ある程度実装が難しいと思われる機能は普通にコード書いたりもします*1。

社内教育

自分の知見を社内のエンジニアに伝えることで、単純に僕が一人でコードを書くよりもバリューが出るのでは？と思いいろいろやっています。

社内勉強会&読書会

エンジニアチームの技術力向上を目的として、どの会社もだいたい週1、1時間程度を勉強の時間として確保していただいています。もちろん業務時間内です。

読書会で読むものは会社によって異なります。参加メンバーやその時の業務内容見てなにを読むのか決めています。

うちも読書会やってみたい、という会社にオススメしたいのはRuby on Rails ガイドの読書会です。web上にあるので購入稟議などを通さずに始められ、かつRails始めたての人から経験の長い人まで幅広い人が学ぶことができます。Railsを数年やっていても「あーこの機能知らなかった！」となることがあるのですよ。

読書会をやるときはたいてい輪読形式で、かつ予習の必要のない形でやっています。キリの良いところまで誰かが音読し、内容について話し合い、次の人がキリの良いところまで音読する、というような流れ。なので一冊読みきるまでに数ヶ月かかるのですが、参加者の業務の忙しさや知識レベルのばらつきを考えるとこのやり方がベストかなと思っています。扱う題材や参加者によっては別のやり方を取ることもあります。

社内勉強会も会社によっていろいろです。以前お手伝いしていたFiNCさんではOSS活動をやっていく勉強会をしていました。詳細は@ota42yさんがスライド上げてるのでそちらを見てもらえれば。

ペアプロ

ペアプロを通じて、普段僕がどんなことを考えながらコードを書いているのかを共有しています。これは最近始めたので効果の程はまだまだ未知数。

ペアプロ以前は、新しい機能を作り始めるときにお手本となりそうな感じでコードを書いたり、既存のコードをリファクタリングすることで知見を伝えようとしていました。たいていのプロジェクトでは一番最初に作成されたコードがお手本となり、そのやり方がいろんなところにコピーされる宿命なので、最初にちゃんとしたお作法で書くのがとても費用対効果が高いやり方です。が、前述したとおり僕は週1程度のコミット量なのでタイミングが合わずにお手本を書くより前にまずいお作法のコードが大量生産されてしまうことが多いのでした＞＜。なので代表的な箇所をリファクタリングして「こういう風にやるといいんですよー」と啓蒙するのをやっていたのですが、やってみた結果あまり良い感触が得られなかったので、ペアプロでじわじわ知見を伝えていくのが良いかなあと思い今に至るのでした。

別件で、多言語からRubyに移行したい会社さんから、お手本となるRailsアプリケーションをまるっと作る、というお仕事を請けたことがあります。こういうケースだと、「最初からちゃんとしたお作法で書く」がワークしやすいかもしれません。

その他

技術ブランディングのお手伝いもしています。たとえば技術ブログに寄稿したり、その会社の主催する勉強会に登壇したりとか。

あとは採用についてアドバイスしたりもしています。どうやったら良いエンジニアを採用できるのか、というのは非エンジニアの人にとっては馴染みがない領域ですよね。具体的にどのようにやるとよい(と僕が考えている)かは別エントリでまとめようと思っています。

いまの課題

これまでのお仕事は基本的に知人からの紹介で決まっていますが、共通の知り合いのいない、Rubyコミュニティなどから遠い会社にこそ大きな技術顧問需要があるのだろうな、と思っているのでその距離をどうやって埋めると良いのかな、と考えたりしています。

あとは上の方でも少し書きましたが週1程度のコミット量だと細かい問題についてはスルーせざるを得ないのがうーん、という気持ちになりますね。だからといってうまい手段はないのですが…。

技術顧問業をやっての所感

最初は「技術顧問業の需要ってあるのかな」と思いつつやってましたが、2年やった結果、技術顧問を潜在的に必要としている会社はそれなりの数あるのだな、という結論に至りました。

特に、ベンチャー立ち上げの時期に、週に数時間でも良いので知見のある人にアドバイスを貰えると、明らかな落とし穴やまずい設計を避けることができ、数年後の開発効率に大きな違いが出るのではと思います*2。

もっと技術顧問をやる人が増えたり、技術顧問を採用する会社が増えると良いですね。

*1:簡単なコードでも依頼されれば書きますが

*2:ただし数年後に会社が存続しているかわからないベンチャーが顧問を頼めるか、を考えると現実的でないでしょうね。ある程度お金に余裕があるところ限定かも

Rails Developers Meetup 2018でモデレーターをした

Rails Developers Meetup 2018の最後のセッション「基調Q&A」でモデレーターをしてきました。

事前に皆さんから集めたお便りとビールを元に、日本が誇るRailsコミッターたちにいろいろ話してもらいました。40分があっという間に過ぎた感じでしたね。前回のぎんざRuby会議の基調Q&A同様、楽しい時間になりました。

他の発表も面白いものがたくさんで充実した二日間でした。Railsを使っている人や企業が実際にどう開発を進めているのか、何に苦労しているか、何を頑張っているのかの実例をたくさん聞いてモチベーションが高まると同時に、自分の向いている方向は間違ってないのだな、と勇気づけられました。

最近時間がなかったので登壇や勉強会の参加などを控えてたのですが、なんだかんだあり結局フルで参加＞＜。でも参加した以上の価値があったなと思います。

次は時間を作ってなにか喋ろうと思うのでよろしくお願いします (\( ⁰⊖⁰)/)

定期的にyarn updateするには

ライブラリは定期的かつこまめにアップデートすることで辛さを減らしていく、というのは最近の開発現場では定説ではないかと思います。Railsプロジェクトの場合、Gemfileの定期更新を実施している現場も多いのではないでしょうか*1。

最近のRailsアプリケーションはjsライブラリの管理にyarnを使っているところが多いかと思いますが、これもGemfileと同じように定期的にアップデートしたいところです。

商用のものもいくつかありますが、僕は普段使っているCiecleCIを活用して定期的にyarn updateしています。

使っているツールはこちら。CiecleCIに限定されているわけではないので、定期実行できる環境さえあればどこでも活用できると思います。

taichi/ci-yarn-upgrade: Keep NPM dependencies up-to-date with CI, providing version-to-version diff for each library

設定の仕方

CiecleCIの設定は次のような感じでやっておきます*2。

version: 2
jobs:
  yarn-update:
    docker:
      - image: circleci/ruby:2.5.0-node-browsers
    steps:
      - checkout
      - run: sudo sh -c 'echo "deb http://ftp.us.debian.org/debian testing main contrib non-free" >> /etc/apt/sources.list'
      - run: sudo apt-get update
      - run: sudo apt-get install -y git
      - run: yarn global add ci-yarn-upgrade
      - run: GIT_USER_NAME=your_github_user_name GIT_USER_EMAIL=your_email@example.com `yarn global bin`/ci-yarn-upgrade --execute

これとは別に、GitHubのpersonal tokenを取得して、GITHUB_ACCESS_TOKENをCircleCIの設定画面で設定する必要があります。

設定のあと、yarn-updateジョブを実行するとこんな感じのPRができます。

image.png (258.0 kB)

定期実行のやり方

定期実行のやり方はいろいろありますね。常時使える、かつcronが使えるマシンがあればそこからCircleCIのAPIをたたいてもよいです。

Running Jobs With the API - CircleCI

herokuを使って定期実行する

僕はつい最近までherokuのschedulerを使っていました。

herobu という、拙作のシェルスクリプトをherokuにデプロイしておくと、heroku schedulerでCircleCIのAPIを定期実行できます。

毎日PRがくるとちょっと頻度が高すぎるので、週に一回だけPRを作るようにしたいのですが、heroku schedulerは週一回の実行をサポートしていません。

そこでシェルスクリプト側で工夫しています。次のように登録しておいて、土曜日に実行されたときだけAPIを叩くようにしていました。

DAY=6 JOB=yarn-update PROJECT=willnet/savanna ./fire2.sh

詳細はソースを見てください(大したことはしてません)。

circle ciで定期実行する

CircleCIのv2からはWorkflowという仕組みができたので、サーバレスでジョブを定期実行できるようになりました。workflowの仕組自体はジョブを組み合わせて一つのワークフローを定義できるというものですが、一緒に定期実行の機能も追加されています。先程のyarn-updateというジョブを定期実行するworkflowは次のようにして定義できます。

workflows:
  version: 2
  yarn-update-scheculed:
    triggers:
      - schedule:
          cron: "5 0 * * 0"
          filters:
            branches:
              only:
                - master
    jobs:
      - yarn-update

これで毎週日曜日の9時5分にジョブが実行され、定期的にyarn updateできるようになりました。やりましたね。

まとめ

CircleCIを利用してyarnを定期的にアップデートするやり方を紹介しました。CircleCI以外でもいろいろやり方はあると思うので、自分なりのやり方でライブラリを最新に保っていくと良いのではないでしょうか。

*1:Gemfile更新用のツールは商用、OSSでそれなりの数あり、情報も多いので適当にググってください

*2:jobの中でgitをインストールしているのは、たしかCircleCIのイメージ内にあるgitのバージョンが古くてうまく動かなかったからのはず

RailsガイドでOSS貢献するのはどうだろうか

日本語版のRuby on Rails ガイド、日本人Railsエンジニアなら一度はお世話になったことがあると思うのだけど。読んでいるとtypoだったり、てにをはがちょっとおかしいところだったり、古いバージョンの記述のままだったりするところがあります。

ぼくは技術顧問業の一環でよくRailsガイドを読む機会があるので、そういうのを見つけたらなるべくPull Requestを送るようにしていたらコミット権をいただきました。

yasslab/railsguides.jp: Ruby on Rails Guides in Japanese (Railsガイド)

↑に普通に日本語でPull Requestを出せば大抵すぐにマージされるので、読んでいてここちょっとおかしいのでは？と思ったら気軽にPull Requestを投げるようにするとみんな幸せになるはず。日本語でPull Requet投げられるので、OSSに貢献というのをやってみたいけどどうしたらいいのかよくわからないみたいな人にオススメ。

例: Fix typo by willnet · Pull Request #491 · yasslab/railsguides.jp

あとは日本語版の間違いかな？と思ったら、原著が間違えていたという例もあります。その場合は、rails/railsにPRを投げることになります。Railsガイドの原著は本体のソースコードと一緒に管理されているのでした。

例: [ci skip] Add a missing space before closing curly braces by willnet · Pull Request #31312 · rails/rails

こういうしょぼいコミットでもRails Contributorsに反映されるので、積極的に見つけてコントリビューターの順位を上げていくと楽しいと思います。

もうちょっとちゃんと貢献したい人は、新規の章や節を探して追加してみるのが良いかと。例えば最近原著でActive Strorageの章ができたので、こういうの訳してPRくれたりするとみんなとても嬉しいはず。

というわけで、みなさんからのPull Requestお待ちしています。

Rails Developers Meetup 2017でレールの伸ばし方について話した

Rails Developers Meetup の年末拡大版である、Rails Developers Meetup 2017で発表させていただきました。

Railsアプリケーションの可読性を保ちつつ開発をすすめるにはどうしたらよいか、みたいな話です。資料はこちら

所感

この辺の情報は、英語圏だとちらほら情報あるのですが、まだまだまとまった統一見解みたいなものはなくそれぞれ思い思いのやり方でやっているような状況です。日本の現場だと、可読性を保つための方法はほとんど共有されておらず、共有されているとしてもチーム内で口伝に近いやり方*1で行われており、みんなの形式知になっているとは言い難いです。

楽に可読性の高いコードを書くための形式知(もしくはツール)があるとみんな幸せになれると思うので、ブログ書きやYubaの開発の進捗を頑張りたいと思います＞＜。

*1:コードレビューのときなどで指摘する