How to Add an Exception in Windows Firewall

  1. 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.
  2. Double-click on the “Windows Firewall” icon from the Control Panel. The Windows Firewall dialog box will open.
  3. 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.
  4. Click the “Add Program” button at the bottom of this list to open the Add a Program dialog box.
  5. 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.
  6. 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.
  7. 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.

Agent Based Modelling (an Introduction)

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.

The three ideas central to agent-based models are agents as objects, emergence, and complexity.

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

 

Installing Ruby on Rails in Windows

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

ruby -v

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:

ruby setup.rb

you should get a message that rubygems is successfully installed.

  • To verify type

gem -v

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 !!

Database-Related Rake Tasks

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.
db:migrate
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.

db:migrate:down
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)
-> 0.0367s
== AddClientIdToUser: reverted (0.0370s) ================================

db:migrate:up
Invoked without a VERSION, this task will migrate up the version list, behaving the same
as db:migrate.
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)
-> 0.0383s
== AddClientIdToUser: migrated (0.0385s) ================================

db:migrate:redo
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)
-> 0.0853s
== AddTimesheetsUpdatedAtToUsers: reverted (0.0861s) ====================
== AddTimesheetsUpdatedAtToUsers: migrating =============================
– add_column(:users, :timesheets_updated_at, :datetime)
-> 0.3577s
== AddTimesheetsUpdatedAtToUsers: migrated (0.3579s) ====================

 

 

db:migrate:reset
Resets your database for the current environment using your migrations (as opposed to
using schema.rb).
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.
db:schema:dump
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.
db:schema:load
Loads schema.rb file into the database for the current environment.
db:seed
Load the seed data from db/seeds.rb as described in this chapter’s section Database
Seeding.
db:structure:dump
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-
ronment.

$ 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.

 

db:test:prepare
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.)
db:version
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)

 

Database Seeding in Rails

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 => ‘admin@tr3w.com’,: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’)
c.billing_codes.find_or_create_by_name_and_code!(‘Meetings’, ‘MTG’)
c.billing_codes.find_or_create_by_name_and_code!(‘Development’, ‘DEV’)

 

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.delete_all
User.create!(:login => ‘admin’, …
Client.delete_all
client = Client.create!(:name => ‘Workbeast’, …

schema.rb file in rails

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.

‘‘Magic’’ Timestamp Columns in Rails

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.

Custom Data Types in Rails

If use of database-specific datatypes (such as :double, for higher precision than :float) is critical to your project, use the  config.active_record.schema_format = :sql setting in config/application.rb to make Rails dump schema information in native
SQL DDL format rather than its own cross-platform compatible Ruby code, via the db/schema.rb file.

Column Type Gotchas in Rails

The choice of column type is not necessarily a simple choice and depends on both the database you’re using and the requirements of your application.

:binary

Depending on your particular usage scenario, storing binary data in the database can cause big performance problems. Active Record doesn’t generally exclude any columns when it loads objects from the database, and putting large binary attributes on commonly used models will increase the load on your database server significantly. If you must put binary content in a commonly-used class, take advantage of the select method to only bring back the columns you need.
:boolean

The way that boolean values are stored varies from database to database. Some use 1 and 0 integer values to represent true and false, respectively. Others use characters such as T and F. Rails handles the mapping between Ruby’s true and false very well, so you don’t need to worry about the underlying scheme yourself. Setting attributes directly to database values such as 1 or F may work correctly, but is considered an anti-pattern.
:datetime and :timestamp

The Ruby class that Rails maps to datetime and timestamp columns is Time. In 32-bit environments, Time doesn’t work for dates before 1902. Ruby’s DateTime class does work with year values prior to 1902, and Rails falls back to using it if necessary. It doesn’t use DateTime to begin for performance reasons. Under the covers, Time is implemented in C and is very fast, whereas DateTime is written in pure Ruby and is comparatively slow.
:time

It’s very, very rare that you want to use a :time datatype; perhaps if you’re modeling an alarm clock. Rails will read the contents of the database as hour, minute, and second values, into a Time object with dummy values for the year, month, and day.
:decimal

Older versions of Rails (prior to 1.2) did not support the fixed-precision :decimal type and as a result many old Rails applications incorrectly used :float datatypes. Floating-point numbers are by nature imprecise, so it is important to choose :decimal instead of :float for most business-related applications.

 

If you’re using a float to store values which need to be precise, such as money, you’re a jackass.
Floating point calculations are done in binary rather than decimal, so rounding errors abound in
places you wouldn’t expect.
>>0.1+0.2 == 0.3

=>false
>>BigDecimal(’0.1′) + BigDecimal(’0.2′) == BigDecimal(’0.3′)
=>true

:float

Don’t use floats to store currency values, or more accurately, any type of data that needs fixed precision. Since floating-point numbers are pretty much approxi mations, any single representation of a number as a float is probably okay. However, once you start doing mathematical operations or comparisons with float values, it is ridiculously easy to introduce difficult to diagnose bugs into your application.
:integer and :string

There aren’t many gotchas that I can think of when it comes to integers and strings. They are the basic data building blocks of your application,
and many Rails developers leave off the size specification, which results in the default maximum sizes of 11 digits and 255 characters, respectively. You should keep in mind that you won’t get an error if you try to store values that exceed the maximum size defined for the database column, which again, is 255 characters by default. Your string will simply get truncated. Use validations to make sure that user-entered data does not exceed the maximum size allowed.
:text

There have been reports of text fields slowing down query performance on some databases, enough to be a consideration for applications that need to scale to high loads. If you must use a text column in a performance-critical application, put it in a separate table.


Column Type Mappings in Rails

The reason for declaring a database column as type string is that Rails migrations are meant to be database-agnostic. That’s why you could (as I’ve done on occasion) develop using Postgres as your database and deploy in production to Oracle.

 

It is useful to have a reference of how migration’s generic types map to database-specific types. The mappings for the databases most commonly used with Rails are in Table below.

 
Each connection adapter class has a native_database_types hash which establishes the mapping described in Table below. If you need to look up the mappings for a database not listed in Table below, you can pop open the adapter Ruby code and find the native_database_types hash, like the following one inside the PostgreSQLAdapter 

 

 

NATIVE_DATABASE_TYPES = {
:primary_key => “serial primary key”.freeze,
:string => { :name => “character varying”, :limit => 255 },
:text => { :name => “text” },
:integer => { :name => “integer” },
:float => { :name => “float” },
:decimal => { :name => “decimal” },
:datetime => { :name => “timestamp” },
:timestamp => { :name => “timestamp” },
:time => { :name => “time” },
:date => { :name => “date” },
:binary => { :name => “bytea” },
:boolean => { :name => “boolean” },
:xml > { :name => “xml” }
}