私はかなり熟練した開発者であり、いくつかの多形的な方向から足を撃つのに十分なRubyを知っています。正直なところ、私はRailsには興味がなく、phpやPythonの代わりにMacコマンドラインスクリプトとして厳密にRubyを使用したいと思っています。RubyMineをどこから始めればよいのか悩んでいます。すべての機能にRubyMineを使用したいのですが、JetBrainsのAppCodeとIntelliJを使用しているので、RubyMineは簡単に思えます。しかし、.rbファイルを書き込んで、ターミナルコマンドラインから実行することに制限されていますか？例外を待たずにコードをデバッグできるようにしたいと思います。
ですから、私が求めているのは、コマンドラインアプリにアクセスするための簡単なチェックリストだと思います。どのプロジェクトタイプ、どのように編成する必要があるか、どのようにテストするか、そしてRubyMine内から実行する方法は？前もって感謝します。（私たちはかつてはすべて初心者でした...）
TLDR; コーディングするだけで、可能な場合はRubyMineを使用すれば、問題はありません。ここに私自身のプロセスを含めますが、例としてだけです。
私はRubyMineを使用しますが、レールを使用せず、要求どおりの処理を行いません。私は多くの単純なスクリプトと大規模なアプリケーションを作成しますが、どちらもコマンドラインから使用できることがよくあります。
私はまだコードを「プロジェクトディレクトリ」に整理しています。そして、RMをそのディレクトリに向けます。完全にファイルで作業し、RMをファイルだけに向けようとするのではなく。これはIDEが好むもののようです。これにより、RM.ideaは、プロジェクトに関連するすべての設定を保持するディレクトリを作成できます。
これは、一部のプロジェクトが（プロジェクトの）ディレクトリとそのディレクトリ内の単一のファイル（実際にはそのプロジェクトの唯一のコンテンツである単一のスクリプト）のみで構成されていることを意味する場合があります。
とにかく、プロジェクトにファイルを追加するとすぐにわかります。追加のコーディングと、rubyの大きなメリットの一部であるさまざまなユーティリティの両方。
このproject directoryパターンでは、gitなどの一般的なVCSでコードをバージョン管理したり、githubなどのソーシャルコーディングサイトにアップロードしたりすることもできます。
私はどんな種類の「プロジェクトタイプ」も気にしません。実際、RubyMineを使用してプロジェクトを作成することはまったくありません。ディレクトリを作成し、RMでそのディレクトリを開きます（[ファイル]メニューから、またはRMがインストールする「マイニング」コマンドラインツールを使用して）。
project/
もちろんproject、プロジェクトの実際の名前でも、私が作成したディレクトリでもありません。ここでは、一般的な名前として使用しています。私は実際にディレクトリ（およびプロジェクト）に、スクリプトまたはスクリプトが実行する作業の主題にちなんで名前を付けます。
注：現在mine、RM 5のコマンドには、2番目のプロジェクトウィンドウを開かないバグがあります。
明らかに、これがコマンドラインスクリプトを含むプロジェクトである場合は、bin組織化の目的で、それらをディレクトリに配置します。ルートプロジェクトディレクトリをあらゆる種類のもので乱雑にするのは好きではありません。プロジェクトルートに設定ファイルを必要とするツールが多すぎるため、少ないほど良いです。
project/bin/
私が言ったように、他のさまざまなユーティリティはプロジェクトルートの設定ファイルを好むので、それらのいくつかを使用していることに気付くかもしれません。
project/Gemfile
project/Rakefile
project/project.gemspec
project/README.md
project/.rdoc_options
...
スクリプトの自動テストができたら（すぐにはできません）、すべてのテストコードをtestディレクトリに配置しますが、テストの範囲や開発中に実行する頻度に応じて、さらに分類します。 。そして、テストを実行するために必要なコマンドの単なるエイリアスであるquckRakeタスクを追加するところまで行きます。したがって、どのテストランナーを覚えているか、毎回フルパスを入力する必要はありません。
project/test/
project/test/unit/
project/test/unit/some_component_test.rb
project/test/integration/
最後に、プロジェクトが成長し、スクリプトを追加したり、外部プロジェクト内でコードの一部を再利用したりする場合は、libディレクトリを追加し、それを整理するための標準的な方法を使用します。
project/lib/
project/lib/project.rb
そして、プロジェクトが成長し、より複雑になるにつれて、少しリファクタリングした後、コンテンツのより多くの編成が必要になります。cmd特定のスクリプトが実行できるさまざまなワークフローの実際のトップレベルコードを含むディレクトリに注意してください。
project/lib/project/
project/lib/project/other_stuff.rb
project/lib/project/cmd/
project/lib/project/cmd/one_command.rb
project/lib/project/cmd/another_command.rb
もちろん、元project.rbのファイルにはこれらすべてのlibファイルが必要です。Rubyの読み込みはかなり速いので、同じプロジェクト内のrubyファイル間の依存関係を管理することについてはあまり気にしません。それは本当にすべてコードの可読性についてです。
単一のスクリプトファイルから始めて、最小限のボイラープレートコーディングを書くことに何の問題もありません。そして、それがおそらく始めるための最良の方法です。
#!/usr/bin/env ruby
=begin
this is a script blah which does whatever
EXAMPLE
$ script <options> <arguments
=end
def main(args)
whatever
end
main(ARGV)
exit(0)
しかし、rubyでさらに優れたコマンドラインアプリを作成するのは非常に簡単です。あなたのために多くのインフラストラクチャを処理する人気のある宝石があります。
OptionParserのような単純なものから始めることができます
次に、スクリプトでより多くのコードを構築すると、 Methadoneのようなgemを使用してもう少しインフラストラクチャに移行できます。
最後に、「git submodule init」のような多くの「内部」コマンドを使用して本格的なコマンドラインアプリケーションを作成している場合は、 GLIのようなはるかに重いものに昇格できます。
ユニットテストは、作成するアプリケーションの種類に関係なく、ほとんど同じです。実際のサービスを使用したり、コンポーネントを組み合わせたりするのではなく、内部コンポーネントを分離して、純粋に内部的な方法で使用しているだけです。したがって、コマンドラインツールの変更はそれほど多くありません。
しかし、スクリプトの統合または完全なコマンドラインテストに関しては、私は実際にはの大ファンですcucumber/aruba。私はTDDについてはあまり得意ではありませんが、それには少し実用的すぎます。ただし、コマンドラインツールの場合、一連のユースケースは、使用可能なオプションのセットにすでにかなりわかりやすく配置されています。インタラクティブなコマンドの場合でも、これにより一連のfeatureファイルがツールのドキュメントとして便利に使用できるようになります。
Feature:
Create and manipulate notes in Evernote.
Background:
Given I am logged in as me
And I have 0 notes
Scenario: Show note
Given that I have 1 note named "foo" with content "bar"
When I run `rnote show note --title "foo"`
Then the output should contain "bar"
Scenario: Show note, from multiple notes
Given that I have 2 notes named "foo"
When I run `rnote show note --title "foo"` interactively
And I type "1"
Then the output should contain "foo"
スクリプトのインストールとパッケージ化については、世界中で共有して再利用できるようにするために、依存関係のためにルビーですでに使用しているのと同じ「gem」ユーティリティを探す必要があります。
gemspec共有する新しいgemを作成するときに作成するものは、スクリプトやその他のコマンドラインユーティリティについて知ることができます。次に、それらを残りのコードでラップし、適切な場所にインストールし、さらにPATHを修正して、ユーザーが時間になったときにそれらを見つけられるようにします。
実際、これは非常にうまく機能するため、gemはこれらのbinスクリプトだけで構成できます。他の再利用可能なコードは含まれていません。
猫犬は私が何か他のものの例として作り上げた無害な小さな宝石です。これには、libディレクトリはまったく含まれず、単一のコマンドラインスクリプト以外のrubyは含まれていません。
Railsとは何か、 Rubyとは何かを認識していない多くのRails開発者に出くわしました。つまり、レールを取り外したときに残っているものです。明らかに、サーバーとテンプレート、データベース、MVCはすべてなくなり、日常のオブジェクトに追加される便利なメソッドの一部もなくなりました。
新しい商品は、あなたがまだかなりたくさん残っているということです。また、何かが足りない場合は、1つまたは2つの宝石を含めることで簡単に追加できます。たとえば、アクティブレコードのようなORMの使用を楽しんでいる場合は、レールなしで、ほとんど手間をかけずに、アプリケーションに含めることができます。
require 'activerecord'
最後に、開発中にRubyMine機能をより頻繁に使用します。レールを操作するときに利用できるものはすべて、コマンドラインアプリケーションで利用できます。
RMからコマンドを実行し、そのデバッガーをrailsとまったく同じように使用できます。他のIDEと同様に、スクリプトをテストする引数を使用して「実行」プロファイルを設定し、IDEを介してスクリプトを実行またはデバッグできます。個人的には、コマンドラインデバッガーを使用することはありません。問題のトラブルシューティングのためにデバッガーを起動する必要がある場合は、IDEでプログラムを起動します。関連するすべての詳細を「ヘッドアップ」表示し、実行を通じてスクリプトを視覚的に追跡するIDEデバッガーの利点は、かけがえのないものです。
ツールバーの操作[実行]>>>[構成の編集]に移動してから更新**作業ディレクトリパス**適用>>okこれで、すべてのテストをバッチとして実行できるようになりました