- If you want a program or service to communicate freely with your computer, you must add that program as an exception in the Windows Firewall. This insures that the Firewall will not block the computer and program or service from sending data back and forth.
Press the “Start” menu at the bottom of your computer screen to display the Start menu. Choose “Control Panel” from the right side of the Start menu. The Control Panel window will open up onto the desktop.
- Double-click on the “Windows Firewall” icon from the Control Panel. The Windows Firewall dialog box will open.
- Choose the “Exceptions” tab at the top of the Windows Firewall dialog box (if necessary). Under “Programs and Services” you will see a list of services and programs that have already been added as exceptions in Windows XP.
- Click the “Add Program” button at the bottom of this list to open the Add a Program dialog box.
- Scroll through the list to locate the program that you would like to add as an exception. When you have found it, click to select it and a gray rectangle will surround the name of the program.
- Click the “OK” button to close the Add a Program dialog box and add the selected program as an exception in your Windows XP Firewall.
- Verify the program you just added is on the “Programs and Services” list in the Windows Firewall dialog box. Close this dialog box and the control panel.
Nice Article….found from the evergreat wikipedia….
An agent-based model (ABM) (also sometimes related to the term multi-agent system or multi-agent simulation) is a class of computational models for simulating the actions and interactions of autonomous agents (both individual or collective entities such as organizations or groups) with a view to assessing their effects on the system as a whole. It combines elements of game theory, complex systems, emergence, computational sociology, multi-agent systems, and evolutionary programming. Monte Carlo Methods are used to introduce randomness. ABMs are also called individual-based models.
The models simulate the simultaneous operations and interactions of multiple agents, in an attempt to re-create and predict the appearance of complex phenomena. The process is one of emergence from the lower (micro) level of systems to a higher (macro) level. As such, a key notion is that simple behavioral rules generate complex behavior. This principle, known as K.I.S.S. (“Keep it simple and short”) is extensively adopted in the modeling community. Another central tenet is that the whole is greater than the sum of the parts. Individual agents are typically characterized as boundedly rational, presumed to be acting in what they perceive as their own interests, such as reproduction, economic benefit, or social status, using heuristics or simple decision-making rules. ABM agents may experience “learning”, adaptation, and reproduction.
Most agent-based models are composed of: (1) numerous agents specified at various scales (typically referred to as agent-granularity); (2) decision-making heuristics; (3) learning rules or adaptive processes; (4) an interaction topology; and (5) a non-agent environment.
Most computational modeling research describes systems in equilibrium or as moving between equilibria. Agent-based modeling, however, using simple rules, can result in different sorts of complex and interesting behavior.
Agent-based models consist of dynamically interacting rule-based agents. The systems within which they interact can create real-world-like complexity. These agents are:
- Intelligent and purposeful.
- Situated in space and time. They reside in networks and in lattice-like neighborhoods. The location of the agents and their responsive and purposeful behavior are encoded in algorithmic form in computer programs. The modeling process is best described as inductive. The modeler makes those assumptions thought most relevant to the situation at hand and then watches phenomena emerge from the agents’ interactions. Sometimes that result is an equilibrium. Sometimes it is an emergent pattern. Sometimes, however, it is an unintelligible mangle.
In some ways, agent-based models complement traditional analytic methods. Where analytic methods enable humans to characterize the equilibria of a system, agent-based models allow the possibility of generating those equilibria. This generative contribution may be the most mainstream of the potential benefits of agent-based modeling. Agent-based models can explain the emergence of higher-order patterns—network structures of terrorist organizations and the Internet, power-law distributions in the sizes of traffic jams, wars, and stock-market crashes, and social segregation that persists despite populations of tolerant people. Agent-based models also can be used to identify lever points, defined as moments in time in which interventions have extreme consequences, and to distinguish among types of path dependency.
Rather than focusing on stable states, the models consider a system’s robustness—the ways that complex systems adapt to internal and external pressures so as to maintain their functionalities. The task of harnessing that complexity requires consideration of the agents themselves—their diversity, connectedness, and level of interactions
These are the steps to be followed while installing Ruby on Rails on windows
- Install Ruby
- To do this, download the installer for windows from here
- After installing to verify whether ruby is installed properly or not, open your command prompt and type
The output should be showing the version of ruby installed
- After its done it is time to install ruby gems.
- In ruby 1.9.2 it is installed while installing ruby
- For installing gems in older versions download rubygems file from here
- Extract the contents of the folder and traverse to that folder using command prompt.
- When inside the folder, type the following:
you should get a message that rubygems is successfully installed.
- To verify type
The output will be the version you have.
- Now time to install rails.
gem install rails
you will see a series og things being installed.
- Done….now type
rails new my_first_rails_app
and spread the magic !!
The following rake tasks are included by default in boilerplate Rails projects.
db:create and db:create:all
Create the database defined in config/database.yml for the current Rails.env (Or create
all of the local databases defined in config/database.yml in the case of db:create:all.)
db:drop and db:drop:all
Drops the database for the current RAILS_ENV. (Or drops all of the local databases
defined in config/database.yml in the case of db:drop:all.)
db:forward and db:rollback
The db:rollback task moves your database schema back one version. Similarly, the
db:forward task moves your database schema forward one version and is typically used
after rolling back.
Applies all pending migrations. If a VERSION environment variable is provided, then
db:migrate will apply pending migrations through the migration specified, but no
further. The VERSION is specified as the timestamp portion of the migration file name.
If the VERSION provided is older than the current version of the schema, then this task
will actually rollback the newer migrations.
Invoked without a VERSION, this task will migrate all the way down the version list to
an empty database, assuming that all your migrations are working correctly.
With a VERSION, this task will invoke the down method of the specified migration
only. The VERSION is specified as the timestamp portion of the migration file name.
$ rake db:migrate:down VERSION=20100124181315
== AddClientIdToUser: reverting =========================================
– remove_column(:users, :client_id)
== AddClientIdToUser: reverted (0.0370s) ================================
Invoked without a VERSION, this task will migrate up the version list, behaving the same
With a VERSION, this task will invoke the up method of the specified migration
only. The VERSION is specified as the timestamp portion of the migration file name.
$ rake db:migrate:up VERSION=20100124181315
== AddClientIdToUser: migrating =========================================
– add_column(:users, :client_id, :integer)
== AddClientIdToUser: migrated (0.0385s) ================================
Executes the down method of the latest migration file, immediately followed by its up
method. This task is typically used right after correcting a mistake in the up method or
to test that a migration is working correctly.
$ rake db:migrate:redo
== AddTimesheetsUpdatedAtToUsers: reverting =============================
– remove_column(:users, :timesheets_updated_at)
== AddTimesheetsUpdatedAtToUsers: reverted (0.0861s) ====================
== AddTimesheetsUpdatedAtToUsers: migrating =============================
– add_column(:users, :timesheets_updated_at, :datetime)
== AddTimesheetsUpdatedAtToUsers: migrated (0.3579s) ====================
Resets your database for the current environment using your migrations (as opposed to
db:reset and db:setup
The db:setup creates the database for the current environment, loads the schema from
db/schema.rb, then loads the seed data. It’s used when you’re setting up an existing
project for the first time on a development workstation. The similar db:reset task does
the same thing except that it drops and recreates the database first.
Create a db/schema.rb file that can be portably used against any DB supported by
Active Record. Note that creation (or updating) of schema.rb happens automatically
any time you migrate.
Loads schema.rb file into the database for the current environment.
Load the seed data from db/seeds.rb as described in this chapter’s section Database
Dump the database structure to a SQL file containing raw DDL code in a format
corresponding to the database driver specified in database.yml for your current envi-
$ rake db:structure:dump
$ cat db/development_structure.sql
CREATE TABLE ‘avatars’ (
‘id’ int(11) NOT NULL AUTO_INCREMENT,
‘user_id’ int(11) DEFAULT NULL,
‘url’ varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
PRIMARY KEY (‘id’)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
I’ve rarely needed to use this task. It’s possible that some Rails teams working in con-
junction with DBAs that exercise strict control over their application’s database schemas
will need this task on a regular basis.
Check for pending migrations and load the test schema by doing a db:schema:dump
followed by a db:schema:load.
This task gets used very often during active development whenever you’re run-
ning specs or tests without using Rake. (Standard spec-related Rake tasks run
db:test:prepare automatically for you.)
Returns the timestamp of the latest migration file that has been run. Works even if
your database has been created from db/schema.rb, since it contains the latest version
timestamp in it:
ActiveRecord::Schema.define(:version => 20100122011531)
The automatically created file db/seeds.rb is a default location for creating seed data for your database. It was introduced in order to stop the practice of inserting seed data in individual migration files, if you accept the premise that migrations should never be used for seeding example or base data required by your application. It is executed with the rake db:seed task (or created alongside the database when you run rake db:setup).
At its simplest, the contents of seed.rb is simply a series of create! statements that generate baseline data for your application, whether it’s default or related to con figuration. For example, let’s add an admin user and some billing codes to a sample app:
User.create!(:login => ‘admin’, :email => ‘firstname.lastname@example.org’,:password => ’123′, :password_confirmation => ’123′,
:authorized_approver => true)
client = Client.create!(:name => ‘Workbeast’, :code => ‘BEAST’)
client.billing_codes.create!(:name => ‘Meetings’, :code => ‘MTG’)
client.billing_codes.create!(:name => ‘Development’, :code => ‘DEV’)
Why use the bang version of the create methods? Because otherwise you won’t find out if you had errors in your seed file. An alternative would be to use find_or_create_by methods to make seeding idempotent.
c = Client.find_or_create_by_name_and_code!(‘Workbeast’, ‘BEAST’)
Another common seeding practice worth mentioning is calling delete_all prior to creating new records, so that seeding does not generate duplicate records. This practice avoids the need for idempotent seeding routines and lets you be very secure about exactly
what your database will look like after seeding.
User.create!(:login => ‘admin’, …
client = Client.create!(:name => ‘Workbeast’, …
The file db/schema.rb is generated every time you migrate and reflects the latest status of your database schema. You should never edit db/schema.rb by hand since this file is auto-generated from the current state of the database. Instead of editing this file, please
use the migrations feature of Active Record to incrementally modify your database, and then regenerate this schema definition.
Note that this schema.rb definition is the authoritative source for your database schema. If you need to create the application database on another system, you should be using db:schema:load, not running all the migrations from scratch. The latter is a flawed and unsustainable approach (the more migrations you’ll amass, the slower it’ll run and the greater likelihood for issues).
It’s strongly recommended to check this file into your version control system. First of all, it helps to have one definitive schema definition around for reference. Secondly, you can run rake db:schema:load to create your database schema from scratch without
having to run all migrations. That’s especially important considering that as your project evolves, it’s likely that it will become impossible to run migrations all the way through from the start, due to code incompatibilities, such as renaming of classes named explicitly.
Rails does magic with datetime columns, if they’re named a certain way. Active Record will automatically timestamp create operations if the table has columns named created_at or created_on. The same applies to updates when there are columns named updated_at or updated_on.
Note that created_at and updated_at should be defined as datetime, but if you use t.timestamps then you don’t have to worry about what type of columns they are.
Automatic timestamping can be turned off globally, by setting the following variable in an initializer.
ActiveRecord::Base.record_timestamps = false
The preceding code turns off timestamps for all models, but record_timestamps is class-inheritable, so you can also do it on a case-by-case basis by setting self.record_timestamps to false at the top of specific model classes.