mirror of
https://github.com/rails/rails.git
synced 2022-11-09 12:12:34 -05:00
standardize all shell commands with the $ prefix
This commit is contained in:
parent
55105c4318
commit
287bb6990c
12 changed files with 78 additions and 78 deletions
|
@ -22,7 +22,7 @@ To install Rails 3:
|
|||
|
||||
<shell>
|
||||
# Use sudo if your setup requires it
|
||||
gem install rails
|
||||
$ gem install rails
|
||||
</shell>
|
||||
|
||||
|
||||
|
@ -47,8 +47,8 @@ h4. script/* replaced by script/rails
|
|||
The new <tt>script/rails</tt> replaces all the scripts that used to be in the <tt>script</tt> directory. You do not run <tt>script/rails</tt> directly though, the +rails+ command detects it is being invoked in the root of a Rails application and runs the script for you. Intended usage is:
|
||||
|
||||
<shell>
|
||||
rails console # instead of script/console
|
||||
rails g scaffold post title:string # instead of script/generate scaffold post title:string
|
||||
$ rails console # instead of script/console
|
||||
$ rails g scaffold post title:string # instead of script/generate scaffold post title:string
|
||||
</shell>
|
||||
|
||||
Run <tt>rails --help</tt> for a list of all the options.
|
||||
|
@ -64,7 +64,7 @@ To help with the upgrade process, a plugin named "Rails Upgrade":http://github.c
|
|||
Simply install the plugin, then run +rake rails:upgrade:check+ to check your app for pieces that need to be updated (with links to information on how to update them). It also offers a task to generate a +Gemfile+ based on your current +config.gem+ calls and a task to generate a new routes file from your current one. To get the plugin, simply run the following:
|
||||
|
||||
<shell>
|
||||
ruby script/plugin install git://github.com/rails/rails_upgrade.git
|
||||
$ ruby script/plugin install git://github.com/rails/rails_upgrade.git
|
||||
</shell>
|
||||
|
||||
You can see an example of how that works at "Rails Upgrade is now an Official Plugin":http://omgbloglol.com/post/364624593/rails-upgrade-is-now-an-official-plugin
|
||||
|
|
|
@ -19,7 +19,7 @@ h4. Walkthrough to Generating a Mailer
|
|||
h5. Create the Mailer
|
||||
|
||||
<shell>
|
||||
rails generate mailer UserMailer
|
||||
$ rails generate mailer UserMailer
|
||||
create app/mailers/user_mailer.rb
|
||||
invoke erb
|
||||
create app/views/user_mailer
|
||||
|
|
|
@ -29,8 +29,8 @@ Action View works well with Action Record, but it can also be used with other Ru
|
|||
Let's start by ensuring that you have the Action Pack and Rack gems installed:
|
||||
|
||||
<shell>
|
||||
gem install actionpack
|
||||
gem install rack
|
||||
$ gem install actionpack
|
||||
$ gem install rack
|
||||
</shell>
|
||||
|
||||
Now we'll create a simple "Hello World" application that uses the +titleize+ method provided by Active Support.
|
||||
|
@ -52,7 +52,7 @@ Rack::Handler::Mongrel.run method(:hello_world), :Port => 4567
|
|||
We can see this all come together by starting up the application and then visiting +http://localhost:4567/+
|
||||
|
||||
<shell>
|
||||
ruby hello_world.rb
|
||||
$ ruby hello_world.rb
|
||||
</shell>
|
||||
|
||||
TODO needs a screenshot? I have one - not sure where to put it.
|
||||
|
@ -64,8 +64,8 @@ Action View can also be used with "Sinatra":http://www.sinatrarb.com/ in the sam
|
|||
Let's start by ensuring that you have the Action Pack and Sinatra gems installed:
|
||||
|
||||
<shell>
|
||||
gem install actionpack
|
||||
gem install sinatra
|
||||
$ gem install actionpack
|
||||
$ gem install sinatra
|
||||
</shell>
|
||||
|
||||
Now we'll create the same "Hello World" application in Sinatra.
|
||||
|
@ -85,7 +85,7 @@ end
|
|||
Then, we can run the application:
|
||||
|
||||
<shell>
|
||||
ruby hello_world.rb
|
||||
$ ruby hello_world.rb
|
||||
</shell>
|
||||
|
||||
Once the application is running, you can see Sinatra and Action View working together by visiting +http://localhost:4567/+
|
||||
|
|
|
@ -1112,7 +1112,7 @@ h4. Creating Observers
|
|||
For example, imagine a +User+ model where we want to send an email every time a new user is created. Because sending emails is not directly related to our model's purpose, we could create an observer to contain this functionality.
|
||||
|
||||
<shell>
|
||||
rails generate observer User
|
||||
$ rails generate observer User
|
||||
</shell>
|
||||
|
||||
<ruby>
|
||||
|
|
|
@ -539,7 +539,7 @@ Rake is a standalone Ruby utility that replaces the Unix utility 'make', and use
|
|||
You can get a list of Rake tasks available to you, which will often depend on your current directory, by typing +rake --tasks+. Each task has a description, and should help you find the thing you need.
|
||||
|
||||
<shell>
|
||||
rake --tasks
|
||||
$ rake --tasks
|
||||
(in /home/foobar/commandsapp)
|
||||
rake db:abort_if_pending_migrations # Raises an error if there are pending migrations
|
||||
rake db:charset # Retrieves the charset for the current environment's database
|
||||
|
|
|
@ -56,8 +56,8 @@ h4. Clone the Ruby on Rails Repository
|
|||
Navigate to the folder where you want the Ruby on Rails source code (it will create its own +rails+ subdirectory) and run:
|
||||
|
||||
<shell>
|
||||
git clone git://github.com/rails/rails.git
|
||||
cd rails
|
||||
$ git clone git://github.com/rails/rails.git
|
||||
$ cd rails
|
||||
</shell>
|
||||
|
||||
h4. Set up and Run the Tests
|
||||
|
@ -67,38 +67,38 @@ The test suite must pass with any submitted code. No matter whether you are writ
|
|||
Install first libxml2 and libxslt together with their development files for Nokogiri. In Ubuntu that's
|
||||
|
||||
<shell>
|
||||
sudo apt-get install libxml2 libxml2-dev libxslt1-dev
|
||||
$ sudo apt-get install libxml2 libxml2-dev libxslt1-dev
|
||||
</shell>
|
||||
|
||||
Also, SQLite3 and its development files for the +sqlite3-ruby+ gem, in Ubuntu you're done with
|
||||
|
||||
<shell>
|
||||
sudo apt-get install sqlite3 libsqlite3-dev
|
||||
$ sudo apt-get install sqlite3 libsqlite3-dev
|
||||
</shell>
|
||||
|
||||
Get a recent version of "Bundler":http://gembundler.com/:
|
||||
|
||||
<shell>
|
||||
gem install bundler
|
||||
$ gem install bundler
|
||||
</shell>
|
||||
|
||||
and run:
|
||||
|
||||
<shell>
|
||||
bundle install --without db
|
||||
$ bundle install --without db
|
||||
</shell>
|
||||
|
||||
This command will install all dependencies except the MySQL and PostgreSQL Ruby drivers. We will come back at these soon. With dependencies installed, you can run the test suite with:
|
||||
|
||||
<shell>
|
||||
rake test
|
||||
$ rake test
|
||||
</shell>
|
||||
|
||||
You can also run tests for an specific framework, like Action Pack, by going into its directory and executing the same command:
|
||||
|
||||
<shell>
|
||||
cd actionpack
|
||||
rake test
|
||||
$ cd actionpack
|
||||
$ rake test
|
||||
</shell>
|
||||
|
||||
h4. Warnings
|
||||
|
@ -108,7 +108,7 @@ The test suite runs with warnings enabled. Ideally Ruby on Rails should issue no
|
|||
As of this writing they are specially noisy with Ruby 1.9. If you are sure about what you are doing and would like to have a more clear output, there's a way to override the flag:
|
||||
|
||||
<shell>
|
||||
RUBYOPT=-W0 rake test
|
||||
$ RUBYOPT=-W0 rake test
|
||||
</shell>
|
||||
|
||||
h4. Testing Active Record
|
||||
|
@ -122,8 +122,8 @@ h5. SQLite3
|
|||
The gem +sqlite3-ruby+ does not belong to the "db" group indeed, if you followed the instructions above you're ready. This is how you run the Active Record test suite only for SQLite3:
|
||||
|
||||
<shell>
|
||||
cd activerecord
|
||||
rake test_sqlite3
|
||||
$ cd activerecord
|
||||
$ rake test_sqlite3
|
||||
</shell>
|
||||
|
||||
h5. MySQL and PostgreSQL
|
||||
|
@ -131,15 +131,15 @@ h5. MySQL and PostgreSQL
|
|||
To be able to run the suite for MySQL and PostgreSQL we need their gems. Install first the servers, their client libraries, and their development files. In Ubuntu just run
|
||||
|
||||
<shell>
|
||||
sudo apt-get install mysql-server libmysqlclient15-dev
|
||||
sudo apt-get install postgresql postgresql-client postgresql-contrib libpq-dev
|
||||
$ sudo apt-get install mysql-server libmysqlclient15-dev
|
||||
$ sudo apt-get install postgresql postgresql-client postgresql-contrib libpq-dev
|
||||
</shell>
|
||||
|
||||
After that run:
|
||||
|
||||
<shell>
|
||||
rm .bundle/config
|
||||
bundle install
|
||||
$ rm .bundle/config
|
||||
$ bundle install
|
||||
</shell>
|
||||
|
||||
We need first to delete +.bundle/config+ because Bundler remembers in that file that we didn't want to install the "db" group (alternatively you can edit the file).
|
||||
|
@ -156,21 +156,21 @@ mysql> GRANT ALL PRIVILEGES ON activerecord_unittest2.*
|
|||
and create the test databases:
|
||||
|
||||
<shell>
|
||||
cd activerecord
|
||||
rake mysql:build_databases
|
||||
$ cd activerecord
|
||||
$ rake mysql:build_databases
|
||||
</shell>
|
||||
|
||||
PostgreSQL's authentication works differently. A simple way to setup the development environment for example is to run with your development account
|
||||
|
||||
<shell>
|
||||
sudo -u postgres createuser --superuser $USER
|
||||
$ sudo -u postgres createuser --superuser $USER
|
||||
</shell>
|
||||
|
||||
and after that create the test databases with
|
||||
|
||||
<shell>
|
||||
cd activerecord
|
||||
rake postgresql:build_databases
|
||||
$ cd activerecord
|
||||
$ rake postgresql:build_databases
|
||||
</shell>
|
||||
|
||||
NOTE: Using the rake task to create the test databases ensures they have the correct character set and collation.
|
||||
|
@ -188,7 +188,7 @@ test_postgresql
|
|||
respectively. As we mentioned before
|
||||
|
||||
<shell>
|
||||
rake test
|
||||
$ rake test
|
||||
</shell>
|
||||
|
||||
will now run the four of them in turn.
|
||||
|
@ -200,8 +200,8 @@ h4. Older versions of Ruby on Rails
|
|||
If you want to add a fix to older versions of Ruby on Rails, you'll need to set up and switch to your own local tracking branch. Here is an example to switch to the 2-3-stable branch:
|
||||
|
||||
<shell>
|
||||
git branch --track 2-3-stable origin/2-3-stable
|
||||
git checkout 2-3-stable
|
||||
$ git branch --track 2-3-stable origin/2-3-stable
|
||||
$ git checkout 2-3-stable
|
||||
</shell>
|
||||
|
||||
TIP: You may want to "put your git branch name in your shell prompt":http://qugstart.com/blog/git-and-svn/add-colored-git-branch-name-to-your-shell-prompt/ to make it easier to remember which version of the code you're working with.
|
||||
|
@ -225,13 +225,13 @@ h4. Testing Patches
|
|||
You can also help out by examining patches that have been submitted to Ruby on Rails via Lighthouse. To apply someone's changes you need to first create a dedicated branch:
|
||||
|
||||
<shell>
|
||||
git checkout -b testing_branch
|
||||
$ git checkout -b testing_branch
|
||||
</shell>
|
||||
|
||||
Then you can apply their patch:
|
||||
|
||||
<shell>
|
||||
git am their-patch-file.diff
|
||||
$ git am their-patch-file.diff
|
||||
</shell>
|
||||
|
||||
After applying a patch, test it out! Here are some things to think about:
|
||||
|
@ -270,14 +270,14 @@ h4. Clone the Rails Repository
|
|||
The first thing you need to do to be able to contribute code is to clone the repository:
|
||||
|
||||
<shell>
|
||||
git clone git://github.com/rails/rails.git
|
||||
$ git clone git://github.com/rails/rails.git
|
||||
</shell>
|
||||
|
||||
and create a dedicated branch:
|
||||
|
||||
<shell>
|
||||
cd rails
|
||||
git checkout -b my_new_branch
|
||||
$ cd rails
|
||||
$ git checkout -b my_new_branch
|
||||
</shell>
|
||||
|
||||
It doesn’t really matter what name you use, because this branch will only exist on your local computer.
|
||||
|
@ -311,7 +311,7 @@ h4. Commit Your Changes
|
|||
When you're happy with the code on your computer, you need to commit the changes to git:
|
||||
|
||||
<shell>
|
||||
git commit -a -m "Here is a commit message"
|
||||
$ git commit -a -m "Here is a commit message"
|
||||
</shell>
|
||||
|
||||
h4. Update master
|
||||
|
@ -319,15 +319,15 @@ h4. Update master
|
|||
It’s pretty likely that other changes to master have happened while you were working. Go get them:
|
||||
|
||||
<shell>
|
||||
git checkout master
|
||||
git pull
|
||||
$ git checkout master
|
||||
$ git pull
|
||||
</shell>
|
||||
|
||||
Now reapply your patch on top of the latest changes:
|
||||
|
||||
<shell>
|
||||
git checkout my_new_branch
|
||||
git rebase master
|
||||
$ git checkout my_new_branch
|
||||
$ git rebase master
|
||||
</shell>
|
||||
|
||||
No conflicts? Tests still pass? Change still seems reasonable to you? Then move on.
|
||||
|
@ -337,8 +337,8 @@ h4. Create a Patch
|
|||
Now you can create a patch file to share with other developers (and with the core team). Still in your branch, run
|
||||
|
||||
<shell>
|
||||
git commit -a
|
||||
git format-patch master --stdout > my_new_patch.diff
|
||||
$ git commit -a
|
||||
$ git format-patch master --stdout > my_new_patch.diff
|
||||
</shell>
|
||||
|
||||
Sanity check the results of this operation: open the diff file in your text editor of choice and make sure that no unintended changes crept in.
|
||||
|
|
|
@ -251,7 +251,7 @@ If you see the message in the console or logs:
|
|||
Make sure you have started your web server with the option +--debugger+:
|
||||
|
||||
<shell>
|
||||
~/PathTo/rails_project$ rails server --debugger
|
||||
$ rails server --debugger
|
||||
=> Booting WEBrick
|
||||
=> Rails 3.0.0 application starting on http://0.0.0.0:3000
|
||||
=> Debugger enabled
|
||||
|
@ -477,7 +477,7 @@ end
|
|||
TIP: You can use ruby-debug while using +rails console+. Just remember to +require "ruby-debug"+ before calling the +debugger+ method.
|
||||
|
||||
<shell>
|
||||
/PathTo/project $ rails console
|
||||
$ rails console
|
||||
Loading development environment (Rails 2.1.0)
|
||||
>> require "ruby-debug"
|
||||
=> []
|
||||
|
@ -626,7 +626,7 @@ If a Ruby object does not go out of scope, the Ruby Garbage Collector won't swee
|
|||
To install it run:
|
||||
|
||||
<shell>
|
||||
sudo gem install bleak_house
|
||||
$ sudo gem install bleak_house
|
||||
</shell>
|
||||
|
||||
Then setup your application for profiling. Then add the following at the bottom of config/environment.rb:
|
||||
|
@ -638,7 +638,7 @@ require 'bleak_house' if ENV['BLEAK_HOUSE']
|
|||
Start a server instance with BleakHouse integration:
|
||||
|
||||
<shell>
|
||||
RAILS_ENV=production BLEAK_HOUSE=1 ruby-bleak-house rails server
|
||||
$ RAILS_ENV=production BLEAK_HOUSE=1 ruby-bleak-house rails server
|
||||
</shell>
|
||||
|
||||
Make sure to run a couple hundred requests to get better data samples, then press +CTRL-C+. The server will stop and Bleak House will produce a dumpfile in +/tmp+:
|
||||
|
|
|
@ -388,7 +388,7 @@ In the above template we specify that the application relies on the +rspec-rails
|
|||
Imagine that this template was in a file called +template.rb+. We can use it to modify the outcome of the +rails new+ command by using the +-m+ option and passing in the filename:
|
||||
|
||||
<shell>
|
||||
rails new thud -m template.rb
|
||||
$ rails new thud -m template.rb
|
||||
</shell>
|
||||
|
||||
This command will generate the +Thud+ application, and then apply the template to the generated output.
|
||||
|
@ -396,7 +396,7 @@ This command will generate the +Thud+ application, and then apply the template t
|
|||
Templates don't have to be stored on the local system, the +-m+ option also supports online templates:
|
||||
|
||||
<shell>
|
||||
rails new thud -m https://gist.github.com/722911.txt
|
||||
$ rails new thud -m https://gist.github.com/722911.txt
|
||||
</shell>
|
||||
|
||||
Whilst the final section of this guide doesn't cover how to generate the most awesome template known to man, it will take you through the methods available at your disposal so that you can develop it yourself. These same methods are also available for generators.
|
||||
|
|
|
@ -109,7 +109,7 @@ render :nothing => true
|
|||
If you look at the response for this using cURL, you will see the following:
|
||||
|
||||
<shell>
|
||||
$ curl -i 127.0.0.1:3000/books
|
||||
$ curl -i 127.0.0.1:3000/books
|
||||
HTTP/1.1 200 OK
|
||||
Connection: close
|
||||
Date: Sun, 24 Jan 2010 09:25:18 GMT
|
||||
|
|
|
@ -109,7 +109,7 @@ h4. Creating a Model
|
|||
The model and scaffold generators will create migrations appropriate for adding a new model. This migration will already contain instructions for creating the relevant table. If you tell Rails what columns you want then statements for adding those will also be created. For example, running
|
||||
|
||||
<shell>
|
||||
rails generate model Product name:string description:text
|
||||
$ rails generate model Product name:string description:text
|
||||
</shell>
|
||||
|
||||
will create a migration that looks like this
|
||||
|
@ -139,7 +139,7 @@ h4. Creating a Standalone Migration
|
|||
If you are creating migrations for other purposes (for example to add a column to an existing table) then you can use the migration generator:
|
||||
|
||||
<shell>
|
||||
rails generate migration AddPartNumberToProducts
|
||||
$ rails generate migration AddPartNumberToProducts
|
||||
</shell>
|
||||
|
||||
This will create an empty but appropriately named migration:
|
||||
|
@ -157,7 +157,7 @@ end
|
|||
If the migration name is of the form "AddXXXToYYY" or "RemoveXXXFromYYY" and is followed by a list of column names and types then a migration containing the appropriate +add_column+ and +remove_column+ statements will be created.
|
||||
|
||||
<shell>
|
||||
rails generate migration AddPartNumberToProducts part_number:string
|
||||
$ rails generate migration AddPartNumberToProducts part_number:string
|
||||
</shell>
|
||||
|
||||
will generate
|
||||
|
@ -177,7 +177,7 @@ end
|
|||
Similarly,
|
||||
|
||||
<shell>
|
||||
rails generate migration RemovePartNumberFromProducts part_number:string
|
||||
$ rails generate migration RemovePartNumberFromProducts part_number:string
|
||||
</shell>
|
||||
|
||||
generates
|
||||
|
@ -197,7 +197,7 @@ end
|
|||
You are not limited to one magically generated column, for example
|
||||
|
||||
<shell>
|
||||
rails generate migration AddDetailsToProducts part_number:string price:decimal
|
||||
$ rails generate migration AddDetailsToProducts part_number:string price:decimal
|
||||
</shell>
|
||||
|
||||
generates
|
||||
|
@ -383,7 +383,7 @@ If you specify a target version, Active Record will run the required migrations
|
|||
version is the numerical prefix on the migration's filename. For example to migrate to version 20080906120000 run
|
||||
|
||||
<shell>
|
||||
rake db:migrate VERSION=20080906120000
|
||||
$ rake db:migrate VERSION=20080906120000
|
||||
</shell>
|
||||
|
||||
If this is greater than the current version (i.e. it is migrating upwards) this will run the +up+ method on all migrations up to and including 20080906120000, if migrating downwards this will run the +down+ method on all the migrations down to, but not including, 20080906120000.
|
||||
|
@ -393,13 +393,13 @@ h4. Rolling Back
|
|||
A common task is to rollback the last migration, for example if you made a mistake in it and wish to correct it. Rather than tracking down the version number associated with the previous migration you can run
|
||||
|
||||
<shell>
|
||||
rake db:rollback
|
||||
$ rake db:rollback
|
||||
</shell>
|
||||
|
||||
This will run the +down+ method from the latest migration. If you need to undo several migrations you can provide a +STEP+ parameter:
|
||||
|
||||
<shell>
|
||||
rake db:rollback STEP=3
|
||||
$ rake db:rollback STEP=3
|
||||
</shell>
|
||||
|
||||
will run the +down+ method from the last 3 migrations.
|
||||
|
@ -407,7 +407,7 @@ will run the +down+ method from the last 3 migrations.
|
|||
The +db:migrate:redo+ task is a shortcut for doing a rollback and then migrating back up again. As with the +db:rollback+ task you can use the +STEP+ parameter if you need to go more than one version back, for example
|
||||
|
||||
<shell>
|
||||
rake db:migrate:redo STEP=3
|
||||
$ rake db:migrate:redo STEP=3
|
||||
</shell>
|
||||
|
||||
Neither of these Rake tasks do anything you could not do with +db:migrate+, they are simply more convenient since you do not need to explicitly specify the version to migrate to.
|
||||
|
@ -421,7 +421,7 @@ h4. Being Specific
|
|||
If you need to run a specific migration up or down the +db:migrate:up+ and +db:migrate:down+ tasks will do that. Just specify the appropriate version and the corresponding migration will have its +up+ or +down+ method invoked, for example
|
||||
|
||||
<shell>
|
||||
rake db:migrate:up VERSION=20080906120000
|
||||
$ rake db:migrate:up VERSION=20080906120000
|
||||
</shell>
|
||||
|
||||
will run the +up+ method from the 20080906120000 migration. These tasks check whether the migration has already run, so for example +db:migrate:up VERSION=20080906120000+ will do nothing if Active Record believes that 20080906120000 has already been run.
|
||||
|
|
|
@ -37,7 +37,7 @@ h4. Generating Performance Tests
|
|||
Rails provides a generator called +test_unit:performance+ for creating new performance tests:
|
||||
|
||||
<shell>
|
||||
rails generate test_unit:performance homepage
|
||||
$ rails generate test_unit:performance homepage
|
||||
</shell>
|
||||
|
||||
This generates +homepage_test.rb+ in the +test/performance+ directory:
|
||||
|
|
|
@ -31,7 +31,7 @@ Rails currently ships with a generator to generate a plugin within a Rails appli
|
|||
how this generator works.
|
||||
|
||||
<shell>
|
||||
rails generate plugin --help
|
||||
$ rails generate plugin --help
|
||||
</shell>
|
||||
|
||||
This generator places the plugin into the vendor/plugins directory.
|
||||
|
@ -214,18 +214,18 @@ We can easily generate these models in our "dummy" Rails application by running
|
|||
test/dummy directory:
|
||||
|
||||
<shell>
|
||||
cd test/dummy
|
||||
rails generate model Hickwall last_squak:string
|
||||
rails generate model Wickwall last_squak:string last_tweet:string
|
||||
$ cd test/dummy
|
||||
$ rails generate model Hickwall last_squak:string
|
||||
$ rails generate model Wickwall last_squak:string last_tweet:string
|
||||
</shell>
|
||||
|
||||
Now you can create the necessary database tables in your testing database by navigating to your dummy app
|
||||
and migrating the database. First
|
||||
|
||||
<shell>
|
||||
cd test/dummy
|
||||
rake db:migrate
|
||||
rake db:test:prepare
|
||||
$ cd test/dummy
|
||||
$ rake db:migrate
|
||||
$ rake db:test:prepare
|
||||
</shell>
|
||||
|
||||
While you are here, change the Hickwall and Wickwall models so that they know that they are supposed to act
|
||||
|
@ -424,9 +424,9 @@ require 'yaffle'
|
|||
You can test this by changing to the Rails application that you added the plugin to and starting a rails console. Once in the
|
||||
console we can check to see if the String has an instance method of to_squawk.
|
||||
<shell>
|
||||
cd my_app
|
||||
rails console
|
||||
String.instance_methods.sort
|
||||
$ cd my_app
|
||||
$ rails console
|
||||
$ String.instance_methods.sort
|
||||
</shell>
|
||||
|
||||
You can also remove the .gemspec, Gemfile and Gemfile.lock files as they will no longer be needed.
|
||||
|
@ -447,7 +447,7 @@ Once your README is solid, go through and add rdoc comments to all of the method
|
|||
Once your comments are good to go, navigate to your plugin directory and run:
|
||||
|
||||
<shell>
|
||||
rake rdoc
|
||||
$ rake rdoc
|
||||
</shell>
|
||||
|
||||
!!!!!!!!!!!!!! Make sure these still make sense. Add any references that you see fit. !!!!!!!!!!!!!
|
||||
|
|
Loading…
Reference in a new issue