はてなブックマーク

僕がお手伝いしているiCAREさん主催のミートアップ、iCARE Dev Meetupで、最近発表されたBasecamp社製jsフレームワークであるHotwireについて話しました。 【iCARE Dev Meetup #18】技術顧問が語る、Ruby on Rails実践開発 - connpass 動画も公開されているので気になる方は探してみてください*1。 所感 弊社サービスであるsavanna.ioはHotwireを使って作っています。Hotwireはつい最近発表されましたが、その前身となるフレームワークであるturbolinksとStimulusの組み合わせで数年間開発していました。 なので「サーバサイドはHTMLを返し、jsは最小限」というスタイルが少人数で開発するチームにとてもマッチすることは身を持って体験しています。Vue.jsやReactを採用していたら機能を開発するスピー

弊社サービスである savanna.io はずっとTurbolinksとStimulusで開発してきたのですが、この度 Hotwireがリリースされた*1のでTurbolinks部分をTurboに置き換えてみました。その際のやったことやハマったことのメモを残しておきます。メモ書きなので雑なのはご容赦ください。 前提 webpackerを使ってます。assets pipeline派や素のwebpackを利用している人は適宜読み替えてください TurbolinksのアンインストールとTurboのインストール turbo-railsをGemfileに追加してbundle install ./bin/rails turbo:installをする で問題なくいけるのであればそれで。turbo:installが失敗したらturbo-rails/turbo_with_webpacker.rb と同等のこ

本エントリはiCARE Advent Calendar 2020の25日目です。 僕はiCARE社内で技術顧問としていろんなことをやっていますが、そのうちの一つとしてRailsアプリケーションのテスト改善があります。具体的には「たまに失敗するテスト」で難しいものがあったときに調査して解決をしています。この「たまに失敗するテスト」はiCAREに限らず、ほとんどの会社が苦しめられているのではないでしょうか。僕のお手伝いしている他の会社でも同様なので、複数社の社内ドキュメントツールに「こういうふうに調査するといいですよ」という文章を書いています。しかしこれらはどれも社内wikiどまりで、現時点で公開されている文章が存在していません。 そこで今回この場を借り「失敗したテストがあったときにどうしたらいいのか」の決定版を書いて、今後は「これ読んでおいてください」で済ませたいなと思っています。 前提 R

この記事はSmartHR Advent Calendar 2020 11日目の記事です。 僕のお手伝いしているSmartHRでは、毎週バックエンドエンジニアが集まり、技術的なトピックについて共有、相談しあうミーティングを開催しています。そのミーティングでは僕がTipsなどを共有するコーナーが常設されています*1。 このエントリでは、そのコーナーで共有した内容をひとつ紹介します。 APIに制限をかける方法について APIを外部に提供するとき、一定の制限をかけてユーザがAPIを乱用するのを防ぐことはよくあることではないでしょうか。素直に考えると「1時間に5000回までAPIを実行できる」のようなやり方を思いつきますね。GitHubのAPIもそのやり方ですし、SmartHRのAPIも同様です。 じゃあそれでいいのでは。となるかもしれませんが少し待ってください。いろんなクライアントがAPIを大量に

パーフェクト Ruby on Railsの改訂2版を書きました - おもしろwebサービス開発日記の続き。 いよいよ明日発売日ですね。前のエントリで書き忘れてたことがあったので追記です。 本書の6章からは、Railsのサンプルアプリケーションを作っていきます。技術評論社さんのサポートページからサンプルアプリケーションのコードを手に入れることができますが、GitHub上でも手に入れることができます。 6章の内容を読みつつ写経する方は、GitHubのリポジトリを活用すると写経が捗ると思います。本の流れに沿ってコミットを積んでいるので「写経したんだけどうまく動かない！」という箇所があったら、リポジトリを巻き戻して比較することでtypoに気づけるはず*1。各節終わりの段階でタグも作っているので、途中の過程を飛ばして気になるところだけ写経してみるということも簡単です。 特にビューを一字一句間違えずに

ここ数年、色んな人に「パーフェクト Ruby on Railsの改訂版まだですか」と言われて申し訳ない気持ちでいっぱいでした。が、ついに改訂版が発売されることになりました！もちろん最新のRailsである6.0に対応しています。 発売日は7月25日ですが、先行して発売している書店もあるそうです。 パーフェクトRuby on Rails　【増補改訂版】：書籍案内｜技術評論社 ブログで振り返ると、第1版を書いたのは6年前だったようです。6年前といえばRailsは4.1がリリースされた頃で、フロントエンドはCoffeeScriptを書いてSprocketsでコンパイル、デプロイはCapistranoを使うのが主流だったような気がします。6年でだいぶRailsによる開発の進め方が変わりましたね。このあたりはもちろん第2版で更新されて、WebpackerやDockerに置き換わっています。 改訂2版の

この文章は先日開催された大阪Ruby会議02での登壇内容Concerns about Concernsをブログエントリにしたものです。書いている内容は登壇内容とだいたい同じですが完全一致ではなく、構成を変更したり喋っていない情報を足したりしてます*1。 大阪Ruby会議02に出席していない方でもスライドを読めば大体の内容を把握できると思いますが、これだと細かいニュアンスは伝えられない(し、この手の話はその細かいニュアンスが大事だったりする)のでちゃんとブログエントリにしておこうと思ったのでした。 意見がある人はこちらのスレに書いてもらえると嬉しいです(\( ⁰⊖⁰)/) Concernsとはなにか Concernsという概念は、Rails 4.0から導入されました。具体的にはrails newしたときに生成されるファイルたちの中に app/models/concerns app/contr

@sugamasaoさんと共著でRails本を執筆しました。Railsを始めたばかりの人向けの特集から、Rails 6の新機能紹介まで幅広く書かれたムック本です。今日から9日後の10月26日に発売予定です(電子書籍も同じくらいに発売されるはず)。 Ruby on Rails 6 エンジニア 養成読本posted with amazlet at 19.10.16すがわら まさのり 前島 真一 技術評論社 売り上げランキング: 2,448 Amazon.co.jpで詳細を見る @sugamasaoさんの書籍紹介エントリはこちら sugamasao.hatenablog.com 内容紹介 @sugamasaoさんが目次や対象読者を紹介しているので、こちらでは具体的にどんな内容を扱っているかを箇条書きにしておきます。Railsの新機能を追いかけていない人にとっては、なにこれ？となったり、名前は知っ

先日開催された大阪Ruby会議02で、なんとなく使われがちな機能であるConcernsの使い方について話してきました。資料はこちら。 発表内容について Concernsに関する説明は「関心事を分離するぞ！」のような抽象的なものが多く、 何を関心事として分離するとよいのか Concerns以外のロジックを分離する方法 を知らずに自分なりの解釈でConcernsを使うとかえってコードを読みづらくする形でmoduleが作られることになりがちです。この発表を通じて少しでも読みやすいRailsアプリケーションのコードが増えてほしいなと思います。 もし内容について感想や質問などを書きたい方がいたら、clean-rails.orgにこの発表用のスレが立っているので書き込みお願いします！ このスライドだけだと分かりづらいところがありそうなので、どこかで再演するなり別途文章として公開したいところです*1。

先日行われたRails Developers Meetup 2019で、Clean Test Code Revisedというタイトルで発表しました。スライドはこちら。 動画も上がっているようなので興味のある方はどうぞ*1。 所感 ご存知のかたもいると思いますが、この発表は2017年5月に行われたRails Developers Meetup第一回目で発表した内容を更に一歩進めたものとなっています。 Rails Developers Meetup で綺麗なテストコードの書き方について発表した - おもしろwebサービス開発日記 当時僕の頭の中にあった「こういうケースのときはこう書く。なぜならこうだから」というものを点で出したのが前回の発表で、それらを「脳に負荷をかけない」という線でつなげてまとめたのが今回の発表になります。 テストコードをレビューしたときに「これなんか読みづらいな…」と思って

昨日、2月21日は弊社の設立記念日でした*1。 株式会社ウィルネット二周年記念 (\( ⁰⊖⁰)/) (\( ⁰⊖⁰)/) (\( ⁰⊖⁰)/) pic.twitter.com/Ll3nDwbl4X— willnet (@netwillnet) 2019年2月21日 というわけで法人成りして2年経ちました。最初はフリーランスの延長のつもりだったのですが、会社という形態にしたことで意識が少しだけ変わってきた気がします。 これまではなんでも全部自分一人でやるというのが自然だったのですが、会社の予算を使って誰かに仕事を手伝ってもらう、という形態を徐々に受け入れられるようになってきました。空いた時間で少しずつ開発を進めているsavanna.ioも、いまはデザインに関しては本職にお願いするようになっています。 昔は、一つのスキルだけを伸ばすのではなくいろんな分野を学んでいくのがよい、と思ってデザイン

昨日行われた銀座Railsで登壇させていただきました。 資料はこちら。 所感 複数の主張したいことを一つの発表に盛り込んでしまったので、ちょっとぼんやりした発表になってしまったかもなーという反省があります。 個人でwebサービス作るのはいいぞ 個人開発をモチベーションを落とさず継続する仕組み Railsは個人or少人数で小規模なサービスを作るのに向いてるめっちゃべんりなライブラリなんですよ turbolinks&stimulusはいいぞ rubocopデフォルト設定でも全然普通に開発できるんですよ それぞれのトピックごとにもっと深掘りして(もしくは角度を変えて)話せそうなので、どこか別の機会があれば喋ろうかなと思います。 次は3月のRails Developers Meetup 2019で登壇予定ですが、今回とは全く違った話になる予定です。乞うご期待。

前提 rails標準のわりに使っている人の少ないturbolinksですが、僕は便利に使っています。turbolinksはご存知の通り、リンクを全部ajaxリクエストに置き換えてページ遷移を早くするライブラリです。 turbolinksが実現している「リクエストは全部ajaxにして、フルのページ遷移を避けたほうが速い」というロジックはformでも同じことが言えます。 Railsは5.1からform_withというviewヘルパーが増えました。これは既存のform_tagとform_forを統合するヘルパーという位置づけですが、それ以外に大きな違いとしてデフォルトでdata-remote="true"がformタグに付与される、というのがあります。この振る舞いはformもturbolinksみたいにajaxにしようぜ！というDHHの思想の現れなのだろう、と推測します。実際、form_with

著者の櫻井さんから献本いただきました。遅れましたが感想書きます！ 現場で使える Ruby on Rails 5速習実践ガイドposted with amazlet at 18.11.04大場寧子 松本拓也 櫻井達生 小田井優 大塚隆弘 依光奏江 銭神裕宜 小芝美由紀 マイナビ出版 (2018-10-19) 売り上げランキング: 7,172 Amazon.co.jpで詳細を見る 所感 全般的に図が多用されていて、読みやすくするための工夫があらゆるところに散りばめられているな、と感じました。本を書く側の視点で「これめっちゃ手間暇かかって大変だったのでは…」と、勝手に執筆時にどれくらい苦労したのか想像して胸が苦しくなるくらい丁寧。そのおかげで読者は詰まることなく読み進められるのではないでしょうか。 また「現場で使える」とタイトルにあるとおり、単にRailsの使い方を説明するにとどまらず、現場で実

今日のginza.rbはBasecamp製のjsフレームーワーク、stimulusがテーマでした。 Ginza.rb 第64回 Stimulusは新たな刺激となりうるか？ - Ginza.rb | Doorkeeper 資料はこちら 所感 資料の中にも書いていますが、「サーバサイドな人が片手間で書いているjsをもうちょっといい感じにしたい、しかしvue.jsやreactなどに手を出すほどの余裕がない」というケースだとかなり良い感じで使えるのかな、という印象です。フロントエンド専任の人がいるようなプロジェクトでは特に必要なさそう。 DHHはrailsを「一人でアプリケーションを素早く作るのにとても便利なフレームワーク」として捉えている(出典どこだったか忘れました＞＜)のですが、stimulusやturbolinksにもそれが色濃く反映されているように思えます。DHHの思想のうち、「これはちょ

以前ソフトウェア開発者採用ガイドの読書感想文を書いたときに反響が思ったより大きかったので、エンジニア採用というテーマは関心が高いのだなと感じました。 上記感想文のエントリでも書いていますが、お手伝いしている会社の方などから「どうやったら良いエンジニアを採用できますか？」と聞かれることがよくあります。先のエントリでは「頑張るしかないですねとしか答えようがない」と書きましたが、頑張るとはいったい何を頑張るのか、きちんとまとめておいたほうが良いなと思いエントリをしたためる次第です*1。 あくまで僕はこう思いますという話で、この通りにしたからといって必ず良いエンジニアを採用できる保証はありません。あしからず。 想定読者 良いエンジニアを採用したい偉いひと、もしくは人事のひとです。 前提: 良いエンジニアとは このエントリでの「エンジニア」とはいわゆるweb系のエンジニア(例: サーバサイドエンジニ

先日行われたMedBeer -Rails開発での技術的負債との付き合い方で、「Rails Good Parts, Bad Parts」というタイトルで発表しました。 資料はこちら。 内容を要約すると、技術的負債を貯めずに開発するには (Railsプロジェクトであれば)Railsの便利な機能を活用する 要注意と言われている機能について、対応方法も含めて把握する 上記をチームで共有して、負債になりそうなものをmasterブランチに入れないように頑張りましょう つまり勉強と教育をがんばりましょう という話でした。あとは clean-rails.orgの紹介をすこしだけ。 所感 たいていどの会社でもコードレビューはしていると思いますが、少数のシニアエンジニアが全ての変更点をレビューしきれるとは限らないし、設計をコードレビューの段階で指摘するのは難しいことです。かくして負債となるコードや設計がレビュ

#railsdm で @netwillnet さんに聞きたかったのだけど、タイミングがあわなかったのですが…。 輪読会をどういう風にやってるのか。とかコツとか苦労話とかブログにまとめられてたりしないのだろううか。— Hiroki OHTSUKA (@HIROCASTER) 2018年7月17日 ということで、僕が色んな会社でやっている社内読書会(輪読会)についてまとめます。 社内読書会の流れ Rails Developers Meetup Day3で話したように、複数のお手伝い先で社内読書会をファシリテートしています。今となっては技術顧問業の一環としてやっていますが、顧問業を始める前から、お手伝い先での社内読書会を頻繁に開催していました。 その時々で多少違いますが、次のような流れで本を読み進めていくことが多いです。 出席者の誰か一人が声に出して内容を読む キリの良いところで止めて、みんなで

Rails Developers Meetup 2018 Day 3 Extremeでの登壇機会を頂いたので、技術顧問という「なんかすごそうだけどよくわからないお仕事」の内容について話をさせていただきました。以前書いたブログエントリをもう少し深掘りして、現状僕が感じている課題感を共有した感じです。 スライドの最後の方でも書いているのですが、僕がやっている仕事(知見を伝えてレールから外れるのを防いだり、外れた軌道を修正する)を生業にするひとが増えるとwebエンジニアの幸せの総量も増えると思うので、「このくらいの内容なら自分でもできるかも？やってみようかな」という人が出てきてくれたら嬉しいなあ。 また、これもスライドに書いてるけど技術顧問と会社とのマッチングに課題があると感じているので、間を取り持てる人や会社がでてくるとよさそう*1*2。savanna.io でも将来的にそういうところまで持っ

headless chromeでcookieを読み書きする方法もブログ書いたほうが良いかな…(メドピアさんとは別案件だったので書かなかった— willnet (@netwillnet) 2018年7月4日 poltergeistからheadless chromeへ移行する時に気をつけること - メドピア開発者ブログ の続きです。poltergeistとheadless chrome(selenium-webdriver)でcookieの扱い方が違うので、違いを簡単にまとめておきます。 poltergeistの場合 専用のAPIが用意されています。簡単。 page.driver.set_cookie('name', 'value') page.driver.cookies['name'].value 詳しくは公式を参照してください: teampoltergeist/poltergeist:

Railsで可読性の高いコードを書くにはどうしたらいいのか。コミュニティやブログなどで個別の事例について言及されることはありますが、横断的なまとまった情報はほとんどないのではないかと思います。みんな、散らばった情報を集めて自分なりのやり方を模索しているのではないでしょうか。 そこで、自分なりのやり方を研ぎ澄ませるような、可読性の高いコードについて議論できる場所を作ってみました。clean-rails.orgというドメイン*1です。コミュニティ本体はサブドメインのdiscourse.clean-rails.orgで、オンライン上できれいなコードについて議論できるようにしています。 可読性の高いコードを書くのが好きな方、参加してコメントいただけるとうれしいです(\( ⁰⊖⁰)/) これまでの経緯 Railsのきれいなコードについて議論する勉強会 - おもしろwebサービス開発日記チラシの裏 続

2年ほど前から「フリーランスRails技術顧問」みたいな肩書で複数社のお手伝いをしています。すると知り合いに、技術顧問って実際どんな感じで仕事してるの？と聞かれることが多いので、「これ読めばわかるよ」と言えるように実際にどんなことをしているのかまとめておこうかと思います。 ざっくりどんなことしてるの お手伝いしている会社によってやっていることが違うので一言では答えにくいですね。基本的に「僕の身につけたRailsとシステム開発の知見を提供する」というのが共通しているところ。僕はCTO経験などないのでエンジニア組織についてはあまり触れず、技術寄りの知見について特化して伝えている感じです。 だいたい次のような会社が対象。全部Railsを使っているか、これから使おうとしている会社です。 創業から数年たち業務が拡大してきたが、負債が溜まって身動きが取りづらくなってきたのでちゃんと体制を整えたい 負債

ライブラリは定期的かつこまめにアップデートすることで辛さを減らしていく、というのは最近の開発現場では定説ではないかと思います。Railsプロジェクトの場合、Gemfileの定期更新を実施している現場も多いのではないでしょうか*1。 最近のRailsアプリケーションはjsライブラリの管理にyarnを使っているところが多いかと思いますが、これもGemfileと同じように定期的にアップデートしたいところです。 商用のものもいくつかありますが、僕は普段使っているCiecleCIを活用して定期的にyarn updateしています。 使っているツールはこちら。CiecleCIに限定されているわけではないので、定期実行できる環境さえあればどこでも活用できると思います。 taichi/ci-yarn-upgrade: Keep NPM dependencies up-to-date with CI, pr

日本語版のRuby on Rails ガイド、日本人Railsエンジニアなら一度はお世話になったことがあると思うのだけど。読んでいるとtypoだったり、てにをはがちょっとおかしいところだったり、古いバージョンの記述のままだったりするところがあります。 ぼくは技術顧問業の一環でよくRailsガイドを読む機会があるので、そういうのを見つけたらなるべくPull Requestを送るようにしていたらコミット権をいただきました。 yasslab/railsguides.jp: Ruby on Rails Guides in Japanese (Railsガイド) ↑に普通に日本語でPull Requestを出せば大抵すぐにマージされるので、読んでいてここちょっとおかしいのでは？と思ったら気軽にPull Requestを投げるようにするとみんな幸せになるはず。日本語でPull Requet投げられるの

Rails Developers Meetup の年末拡大版である、Rails Developers Meetup 2017で発表させていただきました。 Railsアプリケーションの可読性を保ちつつ開発をすすめるにはどうしたらよいか、みたいな話です。資料はこちら 所感 この辺の情報は、英語圏だとちらほら情報あるのですが、まだまだまとまった統一見解みたいなものはなくそれぞれ思い思いのやり方でやっているような状況です。日本の現場だと、可読性を保つための方法はほとんど共有されておらず、共有されているとしてもチーム内で口伝に近いやり方*1で行われており、みんなの形式知になっているとは言い難いです。 楽に可読性の高いコードを書くための形式知(もしくはツール)があるとみんな幸せになれると思うので、ブログ書きやYubaの開発の進捗を頑張りたいと思います＞＜。 *1:コードレビューのときなどで指摘する

先日行われたRejectKaigi 2017でファイルアップロードについて発表しました。資料はこちら。 内容的には、WEB+DB PRESS Vol.95で書いたファイルアップロード話を最新にしたものになります。Rails5.2で新しく追加されるActive Storageというファイルアップロード機能を紹介しつつ、ファイルアップロード全般の話題について触れています。 ファイルアップロードをただしく実装するにはそれにまつわる様々な要素についての知見が必要で、webエンジニア的には腕の見せ所ではないかと思います。Active Storageの登場でファイルアップロードについての知見が広まって、ただしく実装できる人が増えるといいなと思います(( ⁰⊖⁰)/) あわせて読みたい WEB+DB PRESS Vol.95posted with amazlet at 17.08.20小出 淳子 黒澤

最近自分の作っているサービスにActionCableを導入しました。そこでフィーチャスペックを書いていくつかハマったので内容を共有します。 使っているのはcapybara & poltergeistです。 Capybara.serverをpumaにする Capybaraのデフォルトのサーバは、ざっと見た感じRailsアプリを別スレッドで動かしているだけのようです。これではActionCableを動かすことはできません。ActionCableを利用するにはpumaを使う必要があります。 次のようにすれば Capybara はpumaをサーバとして使ってくれます。 Capybara.server = :puma これでオーケー…と言いたいところですが、まだ落とし穴が２つほどあります*1。 puma のデフォルトワーカ数(プロセス数)を1にする (追記)最近のcapybara(2.15.1以上?