タグ

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

  • Rails 7.0 + Ruby 3.1でゼロからアプリを作ってみたときにハマったところあれこれ - Qiita

    Ruby on Rails Advent Calendar 2021の枠が空いていたので、あとから登録しました はじめに 個人的なプロジェクトになりますが、僕が翻訳しているRSpecの入門書「Everyday Rails - RSpecによるRailsテスト入門」を2022年前半にRails 7.0バージョンにアップデートしようと考えています。 そこでこの本の中で使っているサンプルアプリケーションをRails 7.0でゼロから作り直してみました。フロントエンド周りを中心に結構考え方が変わっている部分があったので、「ここでハマった！」とか「こういうポイントを押さえておくといいかも」という点をあれこれ書いてみます。 なお、Rails 7.0版のサンプルアプリケーションはまだ公開できる状態ではないので、公開はもうしばらくお待ちください🙏 今回作成したサンプルアプリケーションはこちらで公開してい

    Rails 7.0 + Ruby 3.1でゼロからアプリを作ってみたときにハマったところあれこれ - 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

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

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

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

  • （翻訳）RubyGems.orgでgemが置き換えられる脆弱性とその緩和策について - Qiita

    はじめに この記事は2016年4月6日に公開された RubyGems.org gem replacement vulnerability and mitigation の日本語訳です。 内容を見る限り、この脆弱性が実際に悪用された可能性は低そうですが、念のためgemの開発者やgemの利用者は一読しておくことをお勧めします。 翻訳の方針について 筆者はgem開発やセキュリティ問題にそこまで詳しくないため、一部翻訳に怪しいところがあるかもしれません。 また、翻訳は日本語としての読みやすさを重視してところどころ意訳しています。 もし完全に間違った訳になっていたり、意訳しすぎて原文のニュアンスが変わってしまったりしているところがあれば、コメントや編集リクエスト等でやさしく指摘してやってください。 原文： RubyGems.org gem replacement vulnerability and

    （翻訳）RubyGems.orgでgemが置き換えられる脆弱性とその緩和策について - Qiita

  • Rails 5.0で追加される主な新機能（Ruby on Rails公式ブログより） - Qiita

    はじめに Rails 5.0.0.beta1が2015年12月18日にリリースされました。 また、それにあわせてRuby on Railsの公式ブログに主な変更点がまとめられています。（投稿者はあのDHH氏のようです） Rails 5.0.0.beta1: Action Cable, API mode, Rails command beta1がリリースされたということは、Rails 5.0の正式リリースもそろそろ近いということです。 （ちなみにRails 4.0ではbeta1の4ヶ月後に正式版がリリースされました。） Railsユーザーであれば、みなさん早かれ遅かれRails 5.0を使うことになると思うので、事前に予習しておきましょう！ というわけで、上記の公式ブログの内容を翻訳してみました。 これを読めばRails 5.0でどういう変化が起きるのか、だいたい理解できるはずです！ 翻訳の

    Rails 5.0で追加される主な新機能（Ruby on Rails公式ブログより） - Qiita
    motchang
    motchang 2015/12/20
    ああ… 4.2未満の死が近い…
    リンク

  • サンプルコードでわかる！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アプリケーションにおけるエラー処理（例外処理）の考え方 - Qiita

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

    Railsアプリケーションにおけるエラー処理（例外処理）の考え方 - 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

  • 使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita

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

    使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - 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

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

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

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

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

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

  • @hatebu

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

はてなブックマーク

公式Twitter

はてなのサービス

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