タグ

ブックマーク / qiita.com/jnchito (17)

  • rspec-rails 3.7の新機能！System Specを使ってみた - Qiita

    はじめに 先日、RSpec 3.7がリリースされました。 参考: RSpec 3.7 has been released! 上記ブログの中で「今回のリリースはRailsのSystem Testの統合機能をいち早く使ってもらうためのリリースだ」と書いてあります。 実際、ブログの中で触れられている新機能は「System Spec」機能の追加だけです。 というわけで、この記事はrspec-rails 3.7で導入されたSystem Specの紹介と使い方の説明をしていきます。 実行環境 この記事は以下のバージョンを対象にして書かれています。 rspec-rails 3.7.1 Rails 5.1.4 Ruby 2.4.2 selenium-webdriver 3.6.0 Capybara 2.15.4 Chrome 62 ChromeDriver 2.33 サンプルコード この記事で使用したコー

    rspec-rails 3.7の新機能！System Specを使ってみた - Qiita

  • RubyとRailsにおけるTime, Date, DateTime, TimeWithZoneの違い - Qiita

    RubyとRailsにおけるTime, Date, DateTime, TimeWithZoneの違いRubyRails 2021.2.11追記：DateTimeクラスは非推奨なクラスになりました DateTimeクラスは非推奨なクラスとなり、DateTimeクラスではなくTimeクラスを使うよう、公式にアナウンスされました。 参考1 But we consider use of DateTime should be discouraged. - matz (Yukihiro Matsumoto) https://bugs.ruby-lang.org/issues/15712#note-4 参考2 DateTime は deprecated とされているため、 Timeを使うことを推奨します。 https://docs.ruby-lang.org/ja/latest/class/DateT

    RubyとRailsにおけるTime, Date, DateTime, TimeWithZoneの違い - Qiita

  • 【暫定版】Rails 5.1のSystemTestCaseでHeadlessモードのChromeを使ってみる - Qiita

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

    【暫定版】Rails 5.1のSystemTestCaseでHeadlessモードのChromeを使ってみる - Qiita

  • printデバッグにさようなら！Ruby初心者のためのByebugチュートリアル - Qiita

    はじめに この記事はByebug（バイバグ）というgemを使ったデバッグ方法を説明するチュートリアル記事です。 JavaやC#のようなコンパイル型の言語ではEclipseやVisual StudioのようなIDEを使って開発することが主流です。 なので、自然とIDEに標準装備されているデバッガを使ってステップ実行したりすることが多いと思います。 一方、RubyではRubyMineのような有料IDEもあるものの、IDEではなくテキストエディタを使って開発している人の方がまだまだ多いと思います。 そうすると、初心者の方はなんとなく「Rubyでデバッガを使ってデバッグするのは無理なのでは？」と考えてしまう人も多いかもしれません。（僕は初心者の頃そう思ってました・・・。） ですが、そんなことはありません！ RubyでもIDEを使わずにターミナル上でデバッガを使ってデバッグすることは可能です。 とい

    printデバッグにさようなら！Ruby初心者のためのByebugチュートリアル - Qiita

  • Railsの正規表現でよく使われる \A \z って何？？ - Qiita

    はじめに この記事では以下のような内容を説明します。 Railsの正規表現（入力値バリデーション）でよく使われる \A や \z とは何なのか \A や \z は ^ や $ とどう違うのか JavaScript のような他の言語でも同じように \A や \z を使えるのか 「なんかよくわからないけど、^ や $ を使うとRailsに怒られるから \A や \z を使ってる」という人は、ぜひこの記事を読んできちんと意味を理解しましょう！ 前提となる知識 正規表現についての基本的な説明はここではしません。 正規表現が全く分からない、という方は以下の記事を読んでおいてください。 初心者歓迎！手と目で覚える正規表現入門・その１「さまざまな形式の電話番号を検索しよう」 - Qiita 初心者歓迎！手と目で覚える正規表現入門・その２「微妙な違いを許容しつつ置換しよう」 - Qiita 初心者歓迎！手

    Railsの正規表現でよく使われる \A \z って何？？ - Qiita

  • テストコードの期待値はDRYを捨ててベタ書きする ～テストコードの重要な役割とは？～ - Qiita

    はじめに みなさん、DRY原則はご存知でしょうか？ DRY = Don't repeat yourselfの略で「繰り返しを避けること」という意味ですよね。 良いコードを書くための重要かつ基本的な原則なので、みなさんよくご存知だと思います。 ですが、DRY原則はテストコードを書く場合は必ずしも最善にはならない場合があります。 他の人が書いたテストコードを見ていると、テストコードにDRY原則を適用したために、かえって悪いコードになっているケースをときどき見かけます。 この記事ではなぜテストコードをDRYにすると良くないのか、ということを説明します。 追記：タイトルを変更しました @t_wada さんのコメントを受けて、タイトルを見直しました。 「テストコードはDRYを捨ててベタ書きする」 => 「テストコードの期待値はDRYを捨ててベタ書きする」 【注意】この記事は画一的なテストコードの書き

    テストコードの期待値はDRYを捨ててベタ書きする ～テストコードの重要な役割とは？～ - Qiita

  • Rails 5 + ActionCableで作る！シンプルなチャットアプリ（DHH氏のデモ動画より） - Qiita

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

    Rails 5 + ActionCableで作る！シンプルなチャットアプリ（DHH氏のデモ動画より） - Qiita

  • サンプルコードでわかる！Ruby 2.3の主な新機能 - Qiita

    はじめに Ruby 2.3が2015年12月25日にリリースされました。 そこでこの記事ではRuby 2.3の主な新機能を紹介していきます。 対象となるバージョン 以下のとおり、この記事では ruby 2.3.0 を使っています。 参考文献 今回紹介するサンプルコードは下記のサイトにあったコードをベースにしています。 New features in ruby 2.3 - BlockScore Blog ただし、実行結果を確認するために Minitest を使ったり、コードをいくつか変更したりしています。 サンプルコードはGitHubにあります この記事で使ったサンプルコードはGitHubに置いてあります。 興味のある方は手元で動かしてみてください。 JunichiIto/ruby-2.3-sandbox それではここからRuby 2.3の新機能を紹介していきます。 深い階層にあるハッシュの

    サンプルコードでわかる！Ruby 2.3の主な新機能 - Qiita

  • Rails 4で作るドラッグアンドドロップで表示順を変更できるサンプルアプリ(スクリーンキャスト付き) - Qiita

    はじめに データの並び順を自由自在に入れ替えたい、という要求があったとき、ドラッグアンドドロップで順番が変えられるとなかなか便利です。 そこで本記事ではドラッグアンドドロップによる表示順変更機能をRails 4で実装する手順を説明します。 補足資料 理解しやすくするための補足資料をいろいろ用意してみました。 デモサイト Herokuにデモサイトを作ってみました。 元々のサンプルアプリケーションはCRUDができるようになっていますが、このデモサイトではデータの更新はできません。(変更できるのは順番のみ) ドラッグアンドドロップするとどうなるか、実際に動かしてみてください。 サンプルアプリケーションを作る過程を録画してみました。 フルスクラッチでrails newするところから始めています。 http://www.youtube.com/watch?v=YQ-6HkBhVyc&feature=

    Rails 4で作るドラッグアンドドロップで表示順を変更できるサンプルアプリ(スクリーンキャスト付き) - Qiita

  • Boolean型のカラムを追加するときは必ずデフォルト値を設定しよう - Qiita

    tl;dr (最初に結論) Railsのモデルに新しくboolean型のカラムを追加するときは必ずデフォルト値を設定しておいた方がいいです。 すなわち、 のように書きましょう、ということです。 default: false はデフォルト値を false に設定することを示しています。 なので既存のレコードは notification_allowed カラムの値が false になります。 null: false は NULL (Rubyでいうところの nil)が設定されることを禁止するオプションです。 必須ではありませんが、NULL が入ると面倒な問題を引き起こしやすいので基本的に付けておくことをオススメします。 それではこの件に関する詳しい内容を以下で説明していきます。 データベースとRubyで異なる NULL / nil の扱い デフォルト値を明示的に設定しなかった場合、新しいカラムに

    Boolean型のカラムを追加するときは必ずデフォルト値を設定しよう - Qiita

  • 使えるRSpec入門・その4「どんなブラウザ操作も自由自在！逆引きCapybara大辞典」 - Qiita

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

    使えるRSpec入門・その4「どんなブラウザ操作も自由自在！逆引きCapybara大辞典」 - Qiita

  • メインの開発ツールをVimからRubyMineに変更した理由 - Qiita

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

    メインの開発ツールをVimからRubyMineに変更した理由 - Qiita

  • Devise関連のページだけをSSL化する手順 - Qiita

    # staging.rbがあればそちらも同様 config.to_prepare { Devise::SessionsController.force_ssl } config.to_prepare { Devise::RegistrationsController.force_ssl } config.to_prepare { Devise::PasswordsController.force_ssl }

    Devise関連のページだけをSSL化する手順 - Qiita

  • 使えるRSpec入門・その3「ゼロからわかるモック（mock）を使ったテストの書き方」 - Qiita

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

    使えるRSpec入門・その3「ゼロからわかるモック（mock）を使ったテストの書き方」 - Qiita

  • [初心者向け] RubyやRailsでリファクタリングに使えそうなイディオムとか便利メソッドとか - Qiita

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

    [初心者向け] RubyやRailsでリファクタリングに使えそうなイディオムとか便利メソッドとか - Qiita

  • 脱初心者を目指すVimmerにオススメしたいVimプラグインや.vimrcの設定 - Qiita

    はじめに: 「素のVim」から「プラグイン付きのVim」へ Vimを使い始めた当初、僕は.vimrcの設定だけで実現できる機能に限定した方が「ポータブルなVimスキル」になる気がしていたので、プラグインは全く使わずに「素のVim」を使っていました。 しかし、Vimを使って実務でRailsを開発し始めるとそんなことも言ってられなくなりました。 やはり素のVimだけでは限界があります。 Vimを使って効率よくRailsを開発するためにはプラグインに頼らざるを得ません。 ネットの情報などを参考にしてあれこれプラグインを入れてみましたが、これは手放せないというプラグインもあれば、思ったほど使わなかったというプラグインもあります。 今回の記事では前者のような「これは手放せない！」と僕が考えているプラグインに限定して紹介していきます。 また、後半ではプラグインを使わない.vimrcの一般的な設定につい

    脱初心者を目指すVimmerにオススメしたいVimプラグインや.vimrcの設定 - Qiita

  • モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita

    はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル（＝クラス）やメソッドに名前を付けるときの基本的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby on Railsを想定しています。 ただし、基本的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません！ payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例:

    モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.