タグ

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

  • 【動画付き】Rails 5.1で作るVue.jsアプリケーション ~Herokuデプロイからシステムテストまで~ - Qiita

    はじめに Rails 5.1ではJavaScript/index.html.erb周りのサポートが大きく改善されました。 これにより、Vue.jsやReactといったモダンなJSフレームワークをRails内で非常に扱いやすくなっています。 僕も実際に試してみましたが、当にびっくりするぐらい簡単にVue.jsやReactを動かすことができました。 そこでこの記事ではRails 5.1とVue.jsを組み合わせたサンプルアプリケーションの作成方法をチュートリアル形式で、できるだけ詳しく説明します。 また、ローカルで動かしておしまい、ではなく、Herokuにデプロイしたり、テストコードを書いたりするところまでカバーします。 この記事自体は長いですが、実際に手を動かすと(スムーズに進んだ場合)30分以内で終わらせることができるはずです! 今回作成するサンプルアプリケーション 今回は以下のリンク先

    【動画付き】Rails 5.1で作るVue.jsアプリケーション ~Herokuデプロイからシステムテストまで~ - Qiita
  • サンプルコードでわかる!Ruby 2.4の新機能と変更点 - Qiita

    はじめに 2016年9月にRuby 2.4のpreview2が、11月にpreview3が、12月11日にrc1がリリースされました(参考1、参考2、参考3)。 僕は早速インストールして新機能を試してみましたが、みなさんはいかがでしょうか? というわけで、この記事では僕が実際に動かして確認したRuby 2.4の変更点や新機能をサンプルコード付きでまとめます。 この記事は大きく分けて次のセクションに分かれています。 文法上の変更点 後方互換性が失われる変更点 パフォーマンス改善 オブジェクト全般の新機能 主に数値に関連する新機能 主に文字列・正規表現に関連する新機能 主に配列・ハッシュに関連する新機能 ディレクトリやファイルに関連する新機能 その他の標準ライブラリに関連する新機能 スレッドに関連する新機能 なお、Ruby 2.4は2016年12月25日にリリースされる予定です。 記事はrc

    サンプルコードでわかる!Ruby 2.4の新機能と変更点 - Qiita
  • これでもう怖くない!?Rails 4.1からRails 5.0にアップグレードする手順を動画付きで解説します - Qiita

    これでもう怖くない!?Rails 4.1からRails 5.0にアップグレードする手順を動画付きで解説しますRailsRSpecRubyMine はじめに みなさんお待ちかねのRails 5.0が先日リリースされました。 これまでRailsを使って開発してきた方は、おそらく既存のRailsアプリケーションではRails 4系を使っているんじゃないかと思います。(Rails 3以前の方もいるかもしれませんが・・・) しかし、中には「Rails 5にアップグレードしたいけど、やり方がよくわからない・・・」と困っている方もいるんじゃないでしょうか? そこでこの記事ではRails 4.1で作ったサンプルアプリケーションをRails 5.0にアップグレードする手順を説明します。 (この記事よりも詳しい)解説動画はこちら! アップグレードの手順はYouTubeにアップした動画の中で詳しく説明しています

    これでもう怖くない!?Rails 4.1からRails 5.0にアップグレードする手順を動画付きで解説します - Qiita
  • あなたがマスターしたのはいくつ? Railsを習得するために必要な技術要素の一覧 - Qiita

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

    あなたがマスターしたのはいくつ? Railsを習得するために必要な技術要素の一覧 - 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
  • (翻訳)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
  • 初心者歓迎!手と目で覚える正規表現入門・その1「さまざまな形式の電話番号を検索しよう」 - Qiita

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

    初心者歓迎!手と目で覚える正規表現入門・その1「さまざまな形式の電話番号を検索しよう」 - Qiita
  • Railsアプリケーションにおけるエラー処理(例外処理)の考え方 - Qiita

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

    Railsアプリケーションにおけるエラー処理(例外処理)の考え方 - Qiita
  • 1年間に存在する金曜日と土曜日の日数を簡単にカウントする方法 - Qiita

    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

    1年間に存在する金曜日と土曜日の日数を簡単にカウントする方法 - Qiita
  • 使えるRSpec入門・その4「どんなブラウザ操作も自由自在!逆引きCapybara大辞典」 - Qiita

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

    使えるRSpec入門・その4「どんなブラウザ操作も自由自在!逆引きCapybara大辞典」 - Qiita
  • RubyとRailsにおけるTime, Date, DateTime, TimeWithZoneの違い - Qiita

    RubyRailsにおける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
  • ド・モルガンの法則でunlessのややこしい条件をifに読み替えよう - Qiita

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

    ド・モルガンの法則でunlessのややこしい条件をifに読み替えよう - Qiita
  • 今日から使える!RSpec 3で追加された8つの新機能 - Qiita

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

    今日から使える!RSpec 3で追加された8つの新機能 - Qiita
  • RSpecの入門とその一歩先へ ~RSpec 3バージョン~ - Qiita

    はじめに 有名な初心者向けのRSpec入門記事として、和田卓人さん(@t_wada)の「RSpec の入門とその一歩先へ」という記事があります。 僕もRSpecを全く知らなかった頃に参考にさせてもらいました。 今読んでもとても素晴らしい資料なのですが、RSpecのバージョンが古く、現状の書き方とマッチしなくなってきているのが少しもったいないところです。 そこで、この記事では和田さんの記事をRSpec 3バージョンに書き直してみようと思います。 各イテレーション(RSpec 3バージョン)へのリンク 第1イテレーション(記事) 第2イテレーション 第3イテレーション ソースコードのURL https://github.com/JunichiIto/rspec3-for-beginners/tree/end_of_iter1 記事のライセンスについて 記事は クリエイティブ・コモンズ 表

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

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

    脱初心者を目指すなら知っておきたい便利なVimコマンド25選 (Vimmerレベル診断付き) - 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