タグ

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

  • きみたちは今まで何のためにRailsでMVCパターンを勉強してきたのか - Qiita

    はじめに タイトルは半分釣りです。ごめんなさい。 先日、僕のブログで以下のようなエントリを書きました。 アウトプットのネタに困ったらこれ!?Ruby初心者向けのプログラミング問題を集めてみた(全10問) - give IT a try 簡単にいうと、技術書の丸写しをしてアウトプットした気にならず、自分でコードを書いてそれを公開しようぜ〜という内容です。 で、そのお題となるような簡単なプログラミング問題を10問ほどブログ内で紹介しています。 これまで何人かの方がご自身のブログやQiitaに解答コードを載せているのを見かけました。 ちゃんとチャレンジして偉い!すばらしい!!👏👏👏 ・・・と、実行に移した姿勢は非常に良いのですが、コードを見てみると多くの方が「うーん、惜しい!」と思ってしまう「ある病気」にかかっていました。 というわけで、この記事ではその「ある病気」について、それとプログラ

    きみたちは今まで何のためにRailsでMVCパターンを勉強してきたのか - Qiita
  • Rails開発におけるwebサーバーとアプリケーションサーバーの違い(翻訳) - Qiita

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

    Rails開発におけるwebサーバーとアプリケーションサーバーの違い(翻訳) - Qiita
  • 【Ruby】乱用厳禁!?後置ifで書くとかえって読みづらくなるケース - Qiita

    ただし、後置ifが使えるからといって、無理に普通のif文を後置ifに書き直す必要はありません。 むしろ、後置ifを使うとかえって読みづらくなるケースもあります。 後置ifが不向きなケース たとえば、あなたがコードレビューをしているとき、こんな(物騒な)コードを見かけたらどう思いますか? 「おいおい、頭大丈夫?」と思うようなコードですが、実はこのコードは後置ifで書かれていました。 (ユーザがゾンビだった場合のみ、メッセージを返すメソッドだった!) 後置ifを読むときは条件文があとにやって来ます。 コードが横に長いと条件文がぱっと目に入らないため、「えっ、なんでこのタイミングでこんな処理が入るの!?」と読み手を困惑させる原因になります。 こういったケースでは普通のif文で書いた方が可読性が高くなります。 def message_to(user) # 普通のif文で書けば、特定の条件のみメッセ

    【Ruby】乱用厳禁!?後置ifで書くとかえって読みづらくなるケース - Qiita
  • 使えるRSpec入門・その2「使用頻度の高いマッチャを使いこなす」 - Qiita

    はじめに みなさんこんにちは! この記事は「必要最小限の努力で最大限実戦で使える知識を提供する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ってわけわからん」となっている人もこの記事で再入門してみると

    使えるRSpec入門・その2「使用頻度の高いマッチャを使いこなす」 - Qiita
  • (あなたの周りでも見かけるかもしれない)インスタンス変数の間違った使い方 - Qiita

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

    (あなたの周りでも見かけるかもしれない)インスタンス変数の間違った使い方 - Qiita
  • [初心者向け] RubyやRailsでリファクタリングに使えそうなイディオムとか便利メソッドとか - Qiita

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

    [初心者向け] RubyやRailsでリファクタリングに使えそうなイディオムとか便利メソッドとか - Qiita
  • 使えるRSpec入門・その4「どんなブラウザ操作も自由自在!逆引きCapybara大辞典」 - Qiita

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

    使えるRSpec入門・その4「どんなブラウザ操作も自由自在!逆引きCapybara大辞典」 - Qiita
  • モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita

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

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

    TL;DR(最初にざっくり結論) destroy : 削除できたら真の値(削除したインスタンス自身)、できなかったら偽の値(false)を返す。 destroy! : 削除できたら真の値(削除したインスタンス自身)、できなかったらActiveRecord::RecordNotDestroyed例外を発生させる。 削除に失敗する例 before_destroyコールバックでthrow :abortされた場合 dependent: :restrict_with_errorが設定され、なおかつ関連する子レコードを持つ親レコードを削除しようとした場合 はじめに ActiveRecordにはデータを削除するメソッドとして、destroyとdestroy!があります。 これはsaveとsave!の関係によく似ています(saveは検証エラーが発生したときにfalseを返し、save!は例外を発生させる)

    ActiveRecordにおけるdestroyとdestroy!の違い - 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
  • プログラミング初心者歓迎!「エラーが出ました。どうすればいいですか?」から卒業するための基本と極意(解説動画付き) - Qiita

    はじめに 先日、スタック・オーバーフローを見ているとこんな質問が載っていました。 Ruby On Railsで質問に対してのBA機能 - スタック・オーバーフロー 「BA機能」というのはどうやらベストアンサー機能の略らしいです。(BAって略し方は一般的なの??) それはさておき、僕が気になったのは質問の最後の部分です。 Processing by BestAnswersController#best as HTML Parameters {"authenticity_token"=>"DtGJ+4qzzG2PqEJpa7GH9Fb8pQhGDX0cg+w+qhf0tP/9HIIVYabiJeW0rEiL7iydpa5PpjrdR1V1LeGzfOeJjw==", "comment"=>"43", "note_id"=>"36"} Note Load (0.2ms) SELECT "note

    プログラミング初心者歓迎!「エラーが出ました。どうすればいいですか?」から卒業するための基本と極意(解説動画付き) - Qiita
  • Minitestで書いたテストコードをRubyMine上で実行する手順 - Qiita

    はじめに この記事では「プロを目指す人のためのRuby入門」の読者向けに、Minitestで書いたテストコードをRubyMine上で実行する手順を紹介します。 実行環境 この記事は以下の環境で動作確認しています。 Ruby 2.4.1 (rbenvで新規にインストールした直後の状態) RubyMine 2018.1.3 macOS 10.13.4 1. RubyMineで新規プロジェクトを作成する プロジェクトタイプはEmpty Projectで、Ruby SDKにRuby 2.4.1を指定します。 2. testディレクトリを作成する 「Projectペインを右クリック > New > Directory」でtestという名前のディレクトリを作成します。 ちなみに必須ではありませんが、testディレクトリを作ったら、「右クリック > Mark Directory as > Test So

    Minitestで書いたテストコードをRubyMine上で実行する手順 - Qiita
  • あなたがマスターしたのはいくつ? Railsを習得するために必要な技術要素の一覧 - Qiita

    これはなんですか? これは「This is Why Learning Rails is Hard(Railsの習得が大変な理由はこれだ)」という海外記事に載っているマインドマップを日語化&リスト化したものです。 元記事には「Railsを習得するために必要な技術要素の一覧」を表す、以下のようなマインドマップが載っています。 長年Railsの開発に携わってきた人間として、このマインドマップは「うん、たしかに!」と非常に納得できる内容です。 ただし、サイズの大きな画像なので一覧性に欠けるのと、英語なので日人にとってはぱっと頭に入りづらい点があるのも否めません。 そこでいつでもぱっと確認できるように、このマインドマップ内容を日語化&リスト化することにしました。 このリストを読んで、自分がすでに身につけている技術要素は何か、また、これから習得が必要な技術要素にはどんなものがあるのか、各自で確認

    あなたがマスターしたのはいくつ? Railsを習得するために必要な技術要素の一覧 - Qiita
  • 使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita

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

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