タグ

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

  • サンプルコードでわかる!Ruby 2.5の主な新機能と変更点 Part 1 - Qiita

    はじめに Rubyは毎年12月25日にアップデートされます。 今年はまだpreview版がリリースされていませんが(2017年10月10日時点)、今年もそろそろリリースの日が近づいてきました。 Ruby 2.5については2017年10月10日にpreview1がリリースされました。 Ruby 2.5.0-preview1 Released そこでこの記事ではこの2.5.0-preview1を参考にして、おそらくこんな感じでリリースされるであろうRuby 2.5の新機能や変更点をまとめてみました。 2017.12.25追記: Part 2もあります! この記事を公開したあとにも多数新機能が追加されました。この記事に追記すると長くなってしまうので、Part 2として公開しています。こちらもあわせてご覧ください。 サンプルコードでわかる!Ruby 2.5の主な新機能と変更点 Part 2 - Q

    サンプルコードでわかる!Ruby 2.5の主な新機能と変更点 Part 1 - Qiita
  • テストコードの期待値はDRYを捨ててベタ書きする ~テストコードの重要な役割とは?~ - Qiita

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

    テストコードの期待値はDRYを捨ててベタ書きする ~テストコードの重要な役割とは?~ - Qiita
  • 初心者歓迎!手と目で覚える正規表現入門・その1「さまざまな形式の電話番号を検索しよう」 - Qiita

    はじめに Qiitaをご覧になっているエンジニアのみなさん、正規表現は使いこなせてますか? 正規表現が使えるととっても便利ですよね! あれ?そちらの方、「ぼく、正規表現ようわからへん・・・」って小さくなってませんか?? 大丈夫です!そんなあなたのために、この記事を書きました。 知識ゼロからでも正規表現を学べるようにやさしく説明しているので、とりあえずこの記事を最後まで読んでみてください。 今は \d{2,5}[-(]\d{1,4}[-)]\d{4} が謎の呪文にしか見えなくても、最後まで読めばきっと意味がわかるようになっているはずです! 対象となる読者 記事は正規表現の予備知識が全くない「正規表現初心者」を対象としています。 正規表現は便利だってよく聞くけど、意味不明な呪文にしか見えなくてなんか怖い 正規表現を勉強しようと何度か頑張ったけど、結局よくわからなくて実務で活用できていない と

    初心者歓迎!手と目で覚える正規表現入門・その1「さまざまな形式の電話番号を検索しよう」 - 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開発における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
  • (あなたの周りでも見かけるかもしれない)インスタンス変数の間違った使い方 - Qiita

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

    (あなたの周りでも見かけるかもしれない)インスタンス変数の間違った使い方 - 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
  • 使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita

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

    使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita
  • ド・モルガンの法則でunlessのややこしい条件をifに読み替えよう - Qiita

    はじめに 条件分岐はプログラミングの基です。 しかし、複雑な条件分岐が出てくると非常にコードが読みにくくなります。 さらに、その複雑な条件が unless と組み合わされていたりすると、ぱっと理解するのが非常に困難になります。 そこで、この記事では複雑な unless の条件を攻略する方法を説明します。 質問: "unless person.married? && !person.rich?" が真になるケースは? ifとunless たとえば以下のコードは「personが結婚していたら'Yo!'と声をかける」コードです。

    ド・モルガンの法則でunlessのややこしい条件をifに読み替えよう - Qiita
  • RSpec の入門とその一歩先へ、第2イテレーション ~RSpec 3バージョン~ - Qiita

    はじめに 記事は和田卓人さん(@t_wada)が書かれた有名なRSpec入門記事、「RSpec の入門とその一歩先へ、第2イテレーション」をRSpec 3バージョンとして書き直したものです。 詳しくは第1イテレーションに書いた説明を参照してください。 各イテレーション(RSpec 3バージョン)へのリンク 第1イテレーション 第2イテレーション(記事) 第3イテレーション ソースコードのURL https://github.com/JunichiIto/rspec3-for-beginners/tree/end_of_iter2 記事のライセンスについて 記事は クリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 備考 文やサンプルコードは極力オリジナルバージョンを踏襲します。 記述が古くなっている箇所は新しい記述方法に書き直します。 新しい記

    RSpec の入門とその一歩先へ、第2イテレーション ~RSpec 3バージョン~ - Qiita
  • 脱初心者を目指すなら知っておきたい便利なVimコマンド25選 (Vimmerレベル診断付き) - Qiita

    はじめに: Vimならではの便利機能をマスターしよう! かれこれ数年前、僕がVim(というか、たぶんVi)と初対面したときは、「なんて使いにくいエディタなんだ!!」と最悪の印象でした。 しかし、周りのプログラマやネット上のエンジニアたちはみんな「Vim便利!」「Vim最高!」と言います。 なのでその言葉を信じ、僕も最悪の印象だったVimともう一度正面から向き合うことにしました。 そして、月日が過ぎ・・・僕もいつしか「Vim便利!」「Vim最高!」と叫ぶようになってしまいました!! これって洗脳? いやいや、洗脳じゃありませんw Vimにはメモ帳の延長線上にあるエディタでは実現できないような数々の便利な機能があります。 覚えるまでにはちょっと苦労しますが、覚えてしまえばメモ帳系のエディタでは追いつけないようなスピードでテキストを編集することができます。 とはいえ、そもそも覚える以前に「そんな

    脱初心者を目指すなら知っておきたい便利なVimコマンド25選 (Vimmerレベル診断付き) - Qiita
  • 既存のRailsプロジェクトをRSpec 3.0にアップグレードする際の注意点 ~RSpec 3は怖くないよ!~ - Qiita

    既存のRailsプロジェクトをRSpec 3.0にアップグレードする際の注意点 ~RSpec 3は怖くないよ!~RailsRSpec はじめに とうとうRSpec 3が正式に公開されたので、早速手持ちのRailsプロジェクトをアップグレードしてみました。 アップグレードしたのはプライベートなプロジェクト4とパブリックなプロジェクト2の合計6です。 この記事では実際にRSpec 3にアップグレードしてみて困った点や気付いた点をまとめてみます。 注意: この記事は2014年6月4日時点の情報です この記事は2014年6月4日時点の情報です。 gemの最新バージョンや周辺ライブラリの対応状況が変化している可能性もあるので、アップグレードする際は適宜ネット上の最新情報を確認するようにしてください。 アップグレードの手順 手順はざっくりいうとこんな感じです。 現行のテストが全てパスすることを確

    既存のRailsプロジェクトをRSpec 3.0にアップグレードする際の注意点 ~RSpec 3は怖くないよ!~ - Qiita
  • モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita

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

    モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita
  • [初心者向け] RubyやRailsでリファクタリングに使えそうなイディオムとか便利メソッドとか - Qiita

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

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