Monday, August 12, 2013

Why Vagrant
Vagrant provides easy to configure, reproducible, and portable work environments built on top of industry-standard technology and controlled by a single consistent workflow to help maximize the productivity and flexibility of you and your team.


Vagrant in windows
1. Install VM VirtureBox and open the VM Manager
--VM download link: https://www.virtualbox.org/wiki/Downloads
2. Download vagrant for windows
--Vagrant download link: http://downloads.vagrantup.com/
3. Open GitHub, clone the vagrant image to your local repositories
4. Open a shell from the directory /vagrant, and run command: $vagrant init
5. Run command: $vagrant up
--This will automatically generate VM box to your local machine with Vagrant image

PERL MODULE

TAP::Harness
Description: This is a simple test harness which allows tests to be run and results automatically aggregated and output to STDOUT.
Synopsis: 
use TAP::Harness;
my $harness = TAP::Harness->new( \%args );
$harness->runtests(@tests);
Methods:
 my %args = (
    verbosity => 1,
    lib     => [ 'lib', 'blib/lib', 'blib/arch' ],
 )
 my $harness = TAP::Harness->new( \%args );
Verbosity Level:
 1   verbose        Print individual test results to STDOUT.
 0   normal
 -1   quiet          Suppress some test output (mostly failures 
                        while tests are running).
 -2   really quiet   Suppress everything but the tests summary.
 -3   silent         Suppress everything.

DBI
The DBI is the standard database interface module for Perl. It defines a set of methods, variables and conventions that provide a consistent database interface independent of the actual database being used.

WWW::Scripter - For scripting web sites that have scripts
Description: This is a subclass of WWW::Mechanize that uses the W3C DOM and provides support for scripting.
Synopsis:
use WWW::Scripter;
  $w = new WWW::Scripter;

  $w->use_plugin('Ajax');  # packaged separately
  
  $w->get('http://some.site.com/that/relies/on/ajax');
  $w->eval(' alert("Hello from JavaScript") ');
  $w->document->getElementsByTagName('div')->[0]->....

  $w->content; # returns the HTML content, possibly modified
               # by scripts


HTML::TreeBuilder::XPath - add XPath support to HTML::TreeBuilder
Description: This module adds typical XPath methods to HTML::TreeBuilder, to make it easy to query a document.
Synopsis:
use HTML::TreeBuilder::XPath;
  my $tree= HTML::TreeBuilder::XPath->new;
  $tree->parse_file( "mypage.html");
  my $nb=$tree->findvalue( '/html/body//p[@class="section_title"]/span[@class="nb"]');
  my $id=$tree->findvalue( '/html/body//p[@class="section_title"]/@id');

  my $p= $html->findnodes( '//p[@id="toto"]')->[0];
  my $link_texts= $p->findvalue( './a'); # the texts of all a elements in $p
  $tree->delete; # to avoid memory leaks, if you parse many HTML documents 

Date::Calc - Gregorian calendar date calculations

Test::Simple - Basic utilities for writing tests.
Description: This is an extremely simple, extremely basic module for writing tests suitable for CPAN modules and other pursuits. If you wish to do more complicated testing, use the Test::More module (a drop-in replacement for this one).
Synopsis:
 use Test::Simple tests => 1;

  ok( $foo eq $bar, 'foo is bar' );
The basic unit of Perl testing is the ok. For each thing you want to test your program will print out an "ok" or "not ok" to indicate pass or fail. You do this with the ok() function (see below).
The only other constraint is you must pre-declare how many tests you plan to run. This is in case something goes horribly wrong during the test and your test program aborts, or skips a test or whatever. You do this like so:
    use Test::Simple tests => 23;
You must have a plan.
ok
  ok( $foo eq $bar, $name );
  ok( $foo eq $bar );
ok() is given an expression (in this case $foo eq $bar). If it's true, the test passed. If it's false, it didn't. That's about it.
ok() prints out either "ok" or "not ok" along with a test number (it keeps track of that for you).

Test::More - yet another framework for writing test scripts
Description: The purpose of this module is to provide a wide range of testing utilities. Various ways to say "ok" with better diagnostics, facilities to skip tests, test future features and compare complicated data structures. While you can do almost anything with a simple ok() function, it doesn't provide good diagnostic output.

Before anything else, you need a testing plan. This basically declares how many tests your script is going to run to protect against premature failure.
The preferred way to do this is to declare a plan when you use Test::More.
  use Test::More tests => 23;
There are cases when you will not know beforehand how many tests your script is going to run. In this case, you can declare your tests at the end.
  use Test::More;

  ... run your tests ...

  done_testing( $number_of_tests_run );
Sometimes you really don't know how many tests were run, or it's too difficult to calculate. In which case you can leave off $number_of_tests_run.
In some cases, you'll want to completely skip an entire testing script.
  use Test::More skip_all => $skip_reason;
Your script will declare a skip with the reason why you skipped and exit immediately with a zero (success). 

If you want to control what functions Test::More will export, you have to use the 'import' option. For example, to import everything but 'fail', you'd do:
  use Test::More tests => 23, import => ['!fail'];
Alternatively, you can use the plan() function. Useful for when you have to calculate the number of tests.
  use Test::More;
  plan tests => keys %Stuff * 3;
or for deciding between running the tests at all:
  use Test::More;
  if( $^O eq 'MacOS' ) {
      plan skip_all => 'Test irrelevant on MacOS';
  }
  else {
      plan tests => 42;
  }
done_testing
    done_testing();
    done_testing($number_of_tests);
If you don't know how many tests you're going to run, you can issue the plan when you're done running tests.
$number_of_tests is the same as plan(), it's the number of tests you expected to run. You can omit this, in which case the number of tests you ran doesn't matter, just the fact that your tests ran to conclusion.
This is safer than and replaces the "no_plan" plan.