はじめに 2017年4月13日に、Headlessモード付きのChromeがまもなく登場するというアナウンスがありました。 下記ドキュメントによるとバージョン59からHeadlessモードが導入されるとのことです。 参考: Headless mode - Chrome Platform Status Headless(ヘッドレス)モードとは、GUIを起動しない（つまり目に見える形でブラウザを起動しない）モードのことです。 これによりブラウザを自動実行させる際の速度が向上したり、GUIを持たないサーバー上でブラウザを実行できたりするようになります。 また、Rails 5.1では新しくSystemTestCaseというテストケースが導入されました。 SystemTestCaseはエンドツーエンド（E2E）テスト、すなわちブラウザ上の動きを検証するためのテストケースです。 これを使えばJavaS

はじめに 複数のメンバーで同じRailsアプリケーションを開発しているとコードのコンフリクトがときどき発生します。 普通のファイルは人間が目で見てどうマージすべきか判断すればいいですが、schema.rbのようにRailsによって自動更新されるファイルは手で修正しない方が良いです。 じゃあschema.rbがコンフリクトしたらどうしたらいいの！？という人のためにマージする手順を説明します。 対象となるバージョン 本記事は以下のバージョンを対象としています。 Rails 5.0.2 Git 2.12.2 サンプルコード この手順で使ったRailsアプリケーション（マージがすべて終わった状態）はGitHubにアップしてあります。 想定するシナリオ ここでは以下のようにアリスとボブが同じテーブル（同じモデル）に対して異なるカラムを追加しようとする状況を想定します。 アリス = Blogモデルにa

はじめに みなさんこんにちは！ この記事は「手と目で覚える正規表現入門」の第4回（最終回）です。 この連載記事は「知識ゼロからでも理解できる」「実践的なサンプルを提供する」「自分の手と目で動きを確認できる」をモットーにした、正規表現の入門記事です。 第1回～第3回までは「今までまったく正規表現を知らなかった初心者さん」向けに、「最低限これだけは知っておきたい」という内容を書いてきました。 それに対して、今回は「知らなくてもなんとかなる、でも知ってたら便利」という中級者向けの内容を紹介していきます。 ここまで理解できればあなたも「ワタシ、正規表現チョットデキル」と公言してもいいはずです。 がんばって学習しましょう！ 対象となる読者 本記事は連載記事なので、読者のみなさんは過去の記事で紹介した知識をすべて理解できている、という前提で進めます。 まだ第1回～第3回の記事を読んでない人は、先にそち

【注意！】この記事はRails 5.0.0.beta1を対象にしています。最新のRails 5では仕様が変わっている可能性もあるので注意してください。 はじめに 先日、Rails 5のAction Cableを使ったシンプルなチャットアプリの作り方をDHH氏がYouTubeで公開していました。 Rails 5: Action Cable demo - YouTube 動画を見ながら僕もコードを写経してみたので、その内容をこちらで紹介してみます。 なお、ここで紹介するのはコードだけで、DHH氏の発言は完全に再現していません。 発言内容を確認したい人はオリジナルの動画をチェックしてみてください。 チャットアプリの完成形 今回は下のような非常にシンプルなチャットアプリを作成します。 ソースコード 今回作ったコードはGitHubにアップしています。 JunichiIto/campfire コードを

はじめに 先日スタック・オーバーフローでこんな質問に回答しました。 webサーバー、アプリケーションサーバー、Rackといった仕様や概念と、WEBrick、Unicorn、Pumaといった実装の関係が頭の中で結びつきません 質問者の方はwebサーバー、アプリケーションサーバー、Rack、Unicorn、Pumaと言った用語や概念の理解がこんがらかっているように見えたので、このあたりをきれいに説明している記事を探していたところ、以下の記事を見つけました。 A web server vs. an app server - Justin Weiss スタック・オーバーフローでは記事の一部を抜粋して「ざっくり翻訳」したのですが、それだけで終わらせるのはもったいない気がしたので、Qiitaには全文を翻訳して載せておこうと思います。 これを読むと、あなたもwebサーバーとアプリケーションサーバーの違い

はじめに Railsアプリケーションを本格的に作り込んでいくと、「エラー」とは無縁ではいられません。 しょうもないバグでエラーが発生することもありますし、ほとんど不可抗力ともいえるような大規模なネットワーク障害でエラーが発生することもあります。 エラーの種類がなんであれ、エラーが起きた場合は「原因を素早く特定し、速やかに復旧させること」と「あるエラーが引き金になって、さらに大きなエラーに引き起こさないようにすること」が重要です。 エラー処理を適切に実装していれば、原因の特定や復旧もすばやくできますし、さらに大きなエラーを引き起こす可能性も少ないです。 また、ソースコードも比較的シンプルに保てます。 逆にエラー処理が不適切だと原因の特定に時間がかかったり、異常なデータがどんどん増えてさらに大きなエラーを引き起こしたりします。 ソースコードにも無駄に複雑な処理フローや条件分岐がたくさん出てきて

cd (Railsアプリがあるディレクトリ) rails c Loading development environment (Rails 4.2.0) irb(main):001:0> '2014-01-01'.to_date.all_year.count{|d| d.friday? or d.saturday? } => 104 どうやら2014年の金曜日と土曜日は 104日 あるみたいです！ コードの解説 String#to_dateとDate#all_yearはRailsで提供されている便利メソッドです。 to_dateは文字列をDate型に変換し、all_yearはその年の1月1日から12月31日までのRangeを返します。 irb(main):018:0> date = '2014-01-01'.to_date => Wed, 01 Jan 2014 irb(main):019

はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第4回です。 今回はCapybaraを使ったフィーチャスペックについて説明します。 ただし、今までの記事とは異なり、フィーチャスペックのイロハよりも「Capybaraの使い方」に重点を置きます。 なぜなら、僕個人の経験からいって、フィーチャスペックで困るのは「このブラウザの操作って、どうやってコードで表現するの？？」というケースが大半だからです。 それ以外は第1回～第3回の内容をそのまま応用できるので、特に「フィーチャスペックだから困る」ということはないと思います。 今回は説明する主な項目は以下の通りです。 フィーチャスペックの基本 ページの移動や画面のクリック、フォームの操作など 画面やフォームの検証 画面の操作や検証の応用テクニック その他

はじめに 突然ですが、僕は過去にこんな記事を書いてQiitaに投稿していました。 脱初心者を目指すなら知っておきたい便利なVimコマンド25選 (Vimmerレベル診断付き) 脱初心者を目指すVimmerにオススメしたいVimプラグインや.vimrcの設定 こういった記事を読んだことのある方はもしかすると「やっぱりjnchitoさんは普段からバリバリVimをつかいこなしてるんだろうな～」と思っているかもしれません。 が！！ 実は1年前ぐらいからVimではなくRubyMineをメインで使っています。 そこでこの記事ではなぜ僕がRubyMineを使うようになったのかを書いてみます。 「なんでRubyMineにしたの？」 理由は大きく分けて2つあります。 理由1：Vimのプラグイン管理に疲れた Vimは無料で使えます。便利で高機能なプラグインもいっぱいあります。 プラグインを駆使すればRubyM

はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第3回です。 今回はRSpecのモックを使ったテストについて説明します。 これまでモックを全く使ったことがない人でもわかるように丁寧に説明していくつもりです。 また、これまでの回と同様、個人的に使用頻度が低いと思っている内容についてはバッサリ説明を省きます。 ただし、第1回や第2回に比べるとテストコードが少し複雑になって、仕組みや動きを想像するのがちょっと難しいかもしれません。 ぱっと頭に入ってこない場合はじっくり本文を読んだり、実際に自分で写経しながらコードを動かしたりするなどして、少し時間をかけながら理解するようにしてください。 今回は以下のような内容を説明します。 モックの基本的な使い方 モックを使った検証 モックでわざとエラーを発生させ

（2021-8-28追記） この記事の改訂版を書いてみました。改訂版の方が易しい内容になっているので、プログラミング初心者の方はこちらを参考にしてみてください。 はじめに：「引数があるよりは、ない方が良い」？ 先日、同僚の西見さん（@mah_lab）がこんな技術ブログを書いていました。 インスタンスメソッドとクラスメソッドはどのようにして使い分けるべきか？（Rubyの場合） 同じ内容を僕だったらどういうふうに書くかな～？と思って、ちょっと書き始めてみたんですが、わかりやすく実践的な説明をするのは意外と難しく、内容も西見さんのブログとほぼ同じになりそうだったので、途中で断念しました。 というわけで、インスタンスメソッドとクラスメソッドの使い分けが未だにあやふやだという方は、ぜひ西見さんのブログを読んでみてください！ ・・・なんですが、1点だけ気になる点がありました。 それはインスタンスメソッ

はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第2回です。 今回はRSpecのマッチャについて説明していきます。 第1回と同様、今回も「最低限これだけは」という内容に絞り込んで説明します。 使用頻度の少ないマイナーなマッチャ（注：僕基準）については説明しません。 具体的な項目は以下の通りです。 マッチャとは何か to / not_to / to_not eq be be_xxx be_truthy / be_falsey change + from / to / by 配列 + include raise_error be_within + of これからRSpecを始める人はもちろん、何度かRSpecに触れて「うーん、RSpecってわけわからん」となっている人もこの記事で再入門してみると

はじめに: 問題 さて、いきなり問題です。 Rails 4.0から非推奨（deprecated）になったfinderメソッドは次のうちどれでしょうか？ User.find_by_email('foo@example.com') User.find_by_email_and_name('foo@example.com', 'Foo Bar') User.find_by(email: 'foo@example.com') User.find_or_initialize_by_email('foo@example.com') # または User.find_or_create_by_email('foo@example.com') User.find_or_initialize_by(email: 'foo@example.com') # または User.find_or_create_by(e

はじめに RSpecは難しい、よくわからない、といったコメントをときどき見かけます。 確かにちょっと独特な構文を持っていますし、機能も結構多いので「難しそう」と感じてしまう気持ちもわかります。 （構文については僕も最初見たときに「うげっ、なんか気持ちわるっ」と思った記憶がありますw） しかし、RSpecに限らずどんなフレームワークでも同じですが、慣れてしまえばスラスラ書けますし、実際僕自身は「RSpecって便利だな－」と思いながらテストコードを書いています。 そこでこの記事では、僕が考える「最低限ここだけを押さえていれば大丈夫！！」なRSpecの構文や、僕が普段よく使う便利な機能をまとめてみます。 具体的には以下のような構文や機能です。 describe / it / expect の役割 ネストした describe context の使い方 before の使い方 let / let!

はじめに RSpec 3が正式リリースされて2ヶ月ほど経過しました。(正式リリースは2014年6月) ネットの情報を見ていると、これまでは「既存のテストケースをRSpec 3にアップグレードさせる方法」や「RSpec 3で削除されたり、記法が変わったりした点」など、「守りの姿勢」に入った情報が多かったように思います。(僕自身もそういう情報をたくさんアップしていました) しかし、RSpec 3では以前のバージョンでは使えなかった新しい機能も数多く導入されています。 そこで本記事では「攻めの姿勢」で「RSpec 3から導入された新機能」をまとめてみました。 なお、ここでフォーカスするのはテストコードの書き方にダイレクトに関わってくるマッチャの新機能です。 2015.01.12：RSpec 3.1に関する情報を追記しました RSpec 3.1に関する情報も追記しました。 もともと紹介していた新機

はじめに: 遠回りせずに「近道」を探す RubyやRailsを始めたばかりの人は、もっと短く書く方法や便利な標準ライブラリの存在を知らずに遠回りした書き方をしてしまいがちです。 そこで、RubyやRails初心者の人によく見かける「遠回り(または車輪の再発明)」と、それを回避する「近道」をいろいろ集めてみました。 2013.11.06 追記 この投稿を書くに至った経緯などを自分のブログに書きました。 こちらも合わせてどうぞ！ 昨日Qiitaに投稿した記事は普段のコードレビューの副産物 - give IT a try Ruby編 以下はRubyの標準機能を使ったイディオムやメソッドです。 Railsプロジェクトでもそれ以外でも使えます。(Ruby 1.9以上を想定) 後置ifで行数を減らす