タグ

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

  • Kobitoのサポートが終了してしまったので、Quiverに移行するスクリプトを書いた - Qiita

    はじめに すでにご存じの方も多いかもしれませんが、Qiita投稿にも使えるMarkdownエディタのKobitoが突然サポートを終了しました。 Kobito for Mac / Windowsの提供及びユーザーサポートを終了します - Qiita Blog 個人的にはKobitoのヘビーユーザーだったので、この発表は大変驚いただけでなく、慌てて次の移行先を探すはめになりました。 いろいろ検討した結果、僕はQuiverというツールに移行することに決めました。 この記事ではKobitoからQuiverに移行するために作成したRubyスクリプトを紹介します。 イントロダクション 僕のKobitoの利用目的 僕は以下のような目的でKobitoを利用していました。 Qiitaに投稿する記事の執筆、および投稿 外部に公開しない個人的な技術メモや備忘録の保存 前者のQiitaの投稿については最悪Webか

    Kobitoのサポートが終了してしまったので、Quiverに移行するスクリプトを書いた - Qiita
    tuki0918
    tuki0918 2018/05/21
  • サンプルコードでわかる!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
    tuki0918
    tuki0918 2017/10/11
  • テストコードの期待値はDRYを捨ててベタ書きする ~テストコードの重要な役割とは?~ - Qiita

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

    テストコードの期待値はDRYを捨ててベタ書きする ~テストコードの重要な役割とは?~ - Qiita
    tuki0918
    tuki0918 2016/06/13
  • 使えるRSpec入門・その4「どんなブラウザ操作も自由自在!逆引きCapybara大辞典」 - Qiita

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

    使えるRSpec入門・その4「どんなブラウザ操作も自由自在!逆引きCapybara大辞典」 - Qiita
    tuki0918
    tuki0918 2015/01/02
  • 使えるRSpec入門・その3「ゼロからわかるモック(mock)を使ったテストの書き方」 - Qiita

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

    使えるRSpec入門・その3「ゼロからわかるモック(mock)を使ったテストの書き方」 - Qiita
    tuki0918
    tuki0918 2014/11/21
  • 使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita

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

    使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita
    tuki0918
    tuki0918 2014/10/27
  • 今日から使える!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
    tuki0918
    tuki0918 2014/07/28
  • モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita

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

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

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

    [初心者向け] RubyやRailsでリファクタリングに使えそうなイディオムとか便利メソッドとか - Qiita
    tuki0918
    tuki0918 2013/11/06
    他言語もほしい
  • 衝撃の事実!? "# -*- encoding: utf-8 -*-"じゃなくてもいいんです! - Qiita

    require 'rspec' describe 'Japanese' do subject {'日語'} it {should == '日語'} end # 実行結果(エラーになる) $ rspec encoding_spec.rb /Users/mypc/.rvm/gems/ruby-1.9.3-p194/gems/rspec-core-2.11.1/lib/rspec/core/configuration.rb:780:in `load': /Users/mypc/dev/sandbox/encoding_spec.rb:4: invalid multibyte char (US-ASCII) (SyntaxError) /Users/mypc/dev/sandbox/encoding_spec.rb:4: invalid multibyte char (US-ASCII) /U

    衝撃の事実!? "# -*- encoding: utf-8 -*-"じゃなくてもいいんです! - Qiita
    tuki0918
    tuki0918 2012/10/18
    しらなかった
  • 1