We put the ass in as

We put the ass in as

== VASSAL Reference Manual
[#top]

[.small]#<<index.adoc#toc,Home>> > <<GameModule.adoc#top,Module>> > <<PieceWindow.adoc#top,Game Piece Palette>> > <<GamePiece.adoc#top,Game Piece>> > *Prototype (Trait)*#

'''''

=== Prototype (Trait)

image:images/UsePrototype.png[]

The Prototype trait allows a piece to share a set of common traits with other pieces.
The traits themselves are defined elsewhere in a <<Prototypes.adoc#top,Prototype Definition>> in the _[Global Piece Prototype Definitions]_ section of your module.
A Game Piece may contain any number of Prototype traits, intermixed with regular traits, in any order.

*EXAMPLE:*  A Prototype named _Vehicle_ can be defined with _Can Rotate_, _Text Label_, and _Mark When Moved_ traits.
Any counter can use these traits by using a Prototype trait and specifying _Vehicle_ as the name.
If the module author later decides that vehicles should also have another trait, it need only be added to the Prototype definition, and all game pieces with a _Prototype - Vehicle_ trait will automatically gain the new trait.
Similary, modifying or deleting a trait from a Prototype will change or remove that trait for all pieces that reference the Prototype.

**Prototype Name:**:: Type the name of your prototype here - the name you gave it to its <<Prototypes.adoc#top,prototype definition>>. Alternatively you can click the _Select_ button to pick the prototype from the list of all the ones you have created.

**Select:**:: The _Select_ button allows you to select one of the prototypes you have defined in the module. If your prototypes have been organized into folders, the folders will appear as submenus.

image:images/UsePrototype2.png[]

*SEE ALSO:* <<Prototypes.adoc#top,Prototypes (Definition)>>

== VASSAL Reference Manual
[#top]

[.small]#<<index.adoc#toc,Home>> > <<GameModule.adoc#top,Module>> > <<PieceWindow.adoc#top,Game Piece Palette>> > <<GamePiece.adoc#top,Game Piece>> > *Prototype (Trait)*#

'''''

=== Prototype (Trait)

image:images/UsePrototype.png[]

The Prototype trait allows a piece to share a set of common traits with other pieces.
The traits themselves are defined elsewhere in a <<Prototypes.adoc#top,Prototype Definition>> in the _[Global Piece Prototype Definitions]_ section of your module.
A Game Piece may contain any number of Prototype traits, intermixed with regular traits, in any order.

*EXAMPLE:*  A Prototype named _Vehicle_ can be defined with _Can Rotate_, _Text Label_, and _Mark When Moved_ traits.
Any counter can use these traits by using a Prototype trait and specifying _Vehicle_ as the name.
If the module author later decides that vehicles should also have another trait, it need only be added to the Prototype definition, and all game pieces with a _Prototype - Vehicle_ trait will automatically gain the new trait.
Similary, modifying or deleting a trait from a Prototype will change or remove that trait for all pieces that reference the Prototype.

**Prototype Name:**:: Type the name of your prototype here - the name you gave it to its <<Prototypes.adoc#top,prototype definition>>. Alternatively you can click the _Select_ button to pick the prototype from the list of all the ones you have created.

**Select:**:: The _Select_ button allows you to select one of the prototypes you have defined in the module. If your prototypes have been organized into folders, the folders will appear a submenus.

image:images/UsePrototype2.png[]

*SEE ALSO:* <<Prototypes.adoc#top,Prototypes (Definition)>>


payment: update payment states

payment: update payment states

Signed-off-by: Pierre-Alexandre Meyer <ff019a5748a52b5641624af88a54a2f0e46a9fb5@mouraf.org>

=== Payment Abstractions

Kill Bill has a payment subsystem which offers several APIs:

* payment and refund APIs for recurring billing
* *direct* payment APIs for one-off charges

The former set of APIs is used by the core billing engine to charge for subscriptions, and by Kaui (the Kill Bill Admin UI) to handle refunds, chargebacks, adjustments, etc. for invoices and payments associated with such subscriptions.

The latter set can be used to trigger payments (auth, capture, credit, refund, etc.) by your e-commerce application (e.g. shopping cart). It also offers helpers to create payment forms and redirect URLs in case of hosted payment pages. It is independent of any subscriptions or invoices and is used solely to make payments.

Kill Bill is a generic platform to build billing and payment infrastructures and as such, it is agnostic of payment gateways. However, it provides a framework to register payment plugins, which in turn implement gateway specific APIs. Those payment plugins must be OSGI compliant plugins. They can be written either in:

* java; in which case they are just a standard OSGI java jar which must register a service implementing the https://github.com/killbill/killbill-plugin-api/blob/master/payment/src/main/java/org/killbill/billing/payment/plugin/api/PaymentPluginApi.java[PaymentPluginApi]
* ruby; in which case they must use the https://github.com/killbill/killbill-plugin-framework-ruby[killbill gem] which provides a jruby bridge between java and ruby. Those plugins must inherit the https://github.com/killbill/killbill-plugin-framework-ruby/blob/master/lib/killbill/payment.rb[Payment class] to provide the specific plugin code functionality

The main reason to provide a way to write ruby payment plugins is to be able to reuse the http://activemerchant.org/[Active Merchant] gem. We even have a https://github.com/killbill/killbill-plugin-framework-ruby/[generator] to help you generate a payment plugin from an Active Merchant implementation.

Check the wiki page https://github.com/killbill/killbill/wiki/Payment-plugins[Payment Plugins] for a community-supported list of already written payment plugins.

The Kill Bill payment code will detect all the payment plugins registered in the system and decide which plugin to use when a charge, refund, ... operation needs to happen. The dispatching is based on the payment methods associated with each account. By default, the model is to attach a default payment method to each account: that payment method will have a link that points to a specific plugin to use. For instance, one account could have a Paypal payment method that would point to the Paypal plugin. Additionally, you can also override the payment method to use on a per payment call. The figure below shows the relashionship between a Kill Bill `Account`, its various `PaymentMethods`, each of which points to a given Kill Bill plugin, which itself is in charge to interact with a third party payment gateway.

image:https://docs.google.com/drawings/d/1ERbfXS0LKSyANT08wnp3zDyoROkhKWSdX2EK0LpwLQ4/pub?w=960&h=480[align=center]

By default Kill Bill does not come configured with any payment plugins except for the built-in __EXTERNAL_PAYMENT__, which is used to track payments which occurred outside of Kill Bill. A typical example would be for when a customer pays by check and we want to make sure the invoice balance is set to 0 after receiving the check. A user, represented in Kill Bill as an account can add as many payment methods as required, and each of those will identify a specific plugin that Kill Bill will use when making payments.

=== Payment States

Initially a client of the api can make either an *authorization*, a *purchase*, or a *credit* call (all other operations such as refund would require an initial payment to have already existed).
That initial operation will create a https://github.com/killbill/killbill-api/blob/master/src/main/java/org/killbill/billing/payment/api/Payment.java[Payment] and an initial https://github.com/killbill/killbill-api/blob/c243233be112165bf04a89a715b79112c6c5d1f7/src/main/java/org/killbill/billing/payment/api/PaymentTransaction.java[PaymentTransaction].
The user can then submit additional requests for the same payment (capture, refund, ...) and each of those calls will result in additional `PaymentTransaction` attached to the same payment.
The payments have a state which will drive the set of possible subsequent operations available. For instance, it is possible to make a capture call against a payment in a state `AUTH_SUCCESS` but it is not possible to make such an operation against a payment in an `AUTH_ERRORED` state.
The set of payment state transitions are configured in an https://github.com/killbill/killbill/blob/master/payment/src/main/resources/org/killbill/billing/payment/PaymentStates.xml[xml file] and the Kill Bill payment subsystem is in charge to enforce the transitions. The following diagram below shows all the possible transitions:

// Tricky see http://lifehacker.com/share-direct-links-to-files-in-google-drive-and-skip-th-1493813665
image:https://drive.google.com/uc?&id=0Bw8rymjWckBHNnlZNTJsZ3pHMTg&w=960&h=480[align=center]

In addition to the payment state transitions, each `PaymentTransaction` has a status to reflect the result of the operation. The `PaymentTransaction` status depends on the plugin result and it can be summarized below:

|===
|plugin result | payment transaction status | payment state | description

|PROCESSED
|SUCCESS
|{AUTH,CAPTURE,..}_SUCCESS
|The payment transaction went through and was successful

|PENDING
|PENDING
|{AUTH,CAPTURE,..}_PENDING
|Successful asynchronous operation (e.g. ACH transfer) or multi-step call (e.g. 3D-Secure authorization)

|ERROR
|PAYMENT_FAILURE
|{AUTH,CAPTURE,..}_FAILED
|The payment transaction went through but failed (e.g insufficient funds)

|CANCELED
|PLUGIN_FAILURE
|{AUTH,CAPTURE,..}_ERRORED
|The payment transaction did not happen (e.g unable to connect to the provider)

|UNDEFINED, timeout or any exception
|UNKNOWN
|{AUTH,CAPTURE,..}_ERRORED
|The payment transaction may or not have succeeded, manual review needed

|===

Note that the first 3 cases are normal cases but the last 2 are errors that are unrelated to the user being able to make the payment operation:

* in the case of a hard plugin failure (CANCELED result code), the gateway was probably down and the payment wasn't attempted: there is no attempt to fix those.
* in the case of a plugin timeout (or UNDEFINED result code), the operation might actually have completed; Kill Bill will run a background task to detect those cases and will query the plugin to verify if the state is actually known and when it is, it will update the *transaction status* and move the payment to its appropriate state. If the plugin cannot tell if the payment went through, the transaction will stay in an UNKNOWN state. It is advisable to check that those are rare instances and fix the data appropriately (by checking manually the status in the gateway for example).

=== Payment Abstractions

Kill Bill has a payment subsystem which offers several APIs:

* payment and refund APIs for recurring billing
* *direct* payment APIs for one-off charges

The former set of APIs is used by the core billing engine to charge for subscriptions, and by Kaui (the Kill Bill Admin UI) to handle refunds, chargebacks, adjustments, etc. for invoices and payments associated with such subscriptions.

The latter set can be used to trigger payments (auth, capture, credit, refund, etc.) by your e-commerce application (e.g. shopping cart). It also offers helpers to create payment forms and redirect URLs in case of hosted payment pages. It is independent of any subscriptions or invoices and is used solely to make payments.

Kill Bill is a generic platform to build billing and payment infrastructures and as such, it is agnostic of payment gateways. However, it provides a framework to register payment plugins, which in turn implement gateway specific APIs. Those payment plugins must be OSGI compliant plugins. They can be written either in:

* java; in which case they are just a standard OSGI java jar which must register a service implementing the https://github.com/killbill/killbill-plugin-api/blob/master/payment/src/main/java/org/killbill/billing/payment/plugin/api/PaymentPluginApi.java[PaymentPluginApi]
* ruby; in which case they must use the https://github.com/killbill/killbill-plugin-framework-ruby[killbill gem] which provides a jruby bridge between java and ruby. Those plugins must inherit the https://github.com/killbill/killbill-plugin-framework-ruby/blob/master/lib/killbill/payment.rb[Payment class] to provide the specific plugin code functionality

The main reason to provide a way to write ruby payment plugins is to be able to reuse the http://activemerchant.org/[Active Merchant] gem. We even have a https://github.com/killbill/killbill-plugin-framework-ruby/[generator] to help you generate a payment plugin from an Active Merchant implementation.

Check the wiki page https://github.com/killbill/killbill/wiki/Payment-plugins[Payment Plugins] for a community-supported list of already written payment plugins.

The Kill Bill payment code will detect all the payment plugins registered in the system and decide which plugin to use when a charge, refund, ... operation needs to happen. The dispatching is based on the payment methods associated with each account. By default, the model is to attach a default payment method to each account: that payment method will have a link that points to a specific plugin to use. For instance, one account could have a Paypal payment method that would point to the Paypal plugin. Additionally, you can also override the payment method to use on a per payment call. The figure below shows the relashionship between a Kill Bill `Account`, its various `PaymentMethods`, each of which points to a given Kill Bill plugin, which itself is in charge to interact with a third party payment gateway.

image:https://docs.google.com/drawings/d/1ERbfXS0LKSyANT08wnp3zDyoROkhKWSdX2EK0LpwLQ4/pub?w=960&h=480[align=center]

By default Kill Bill does not come configured with any payment plugins except for the built-in __EXTERNAL_PAYMENT__, which is used to track payments which occurred outside of Kill Bill. A typical example would be for when a customer pays by check and we want to make sure the invoice balance is set to 0 after receiving the check. A user, represented in Kill Bill as an account can add as many payment methods as required, and each of those will identify a specific plugin that Kill Bill will use when making payments.

=== Payment States

Initially a client of the api can make either an *authorization*, a *purchase*, or a *credit* call (all other operations such as refund would require an initial payment to have already existed).
That initial operation will create a https://github.com/killbill/killbill-api/blob/master/src/main/java/org/killbill/billing/payment/api/Payment.java[Payment] and an initial https://github.com/killbill/killbill-api/blob/c243233be112165bf04a89a715b79112c6c5d1f7/src/main/java/org/killbill/billing/payment/api/PaymentTransaction.java[PaymentTransaction].
The user can then submit additional requests for the same payment (capture, refund, ...) and each of those calls will result in additional `PaymentTransaction` attached to the same payment.
The payments have a state which will drive the set of possible subsequent operations available. For instance, it is possible to make a capture call against a payment in a state `AUTH_SUCCESS` but it is not possible to make such an operation against a payment in an `AUTH_ERRORED` state.
The set of payment state transitions are configured in an https://github.com/killbill/killbill/blob/master/payment/src/main/resources/org/killbill/billing/payment/PaymentStates.xml[xml file] and the Kill Bill payment subsystem is in charge to enforce the transitions. The following diagram below shows all the possible transitions:

// Tricky see http://lifehacker.com/share-direct-links-to-files-in-google-drive-and-skip-th-1493813665
image:https://drive.google.com/uc?&id=0Bw8rymjWckBHNnlZNTJsZ3pHMTg&w=960&h=480[align=center]

In addition to the payment state transitions, each `PaymentTransaction` has a status to reflect the result of the operation. The `PaymentTransaction` status depends on the plugin result and it can be summarized below:

|===
|plugin result | payment transaction status | payment state | description

|PROCESSED
|SUCCESS
|{AUTH,CAPTURE,..}_SUCCESS
|Success operation

|PENDING
|PENDING
|{AUTH,CAPTURE,..}_PENDING
|Success asynchronous operation, or multi-step calls (e.g. 3D Secure authorization)

|ERROR
|PAYMENT_FAILURE
|FAILED
|The gateway, bank declined the operation

|UNDEFINED, timeout
|UNKNOWN
|ERRORED
|Plugin timed out or returned an UNDEFINED state

|Any exception
|PLUGIN_FAILURE
|ERRORED
|The plugin threw an exception

|===

Note that the first 3 cases are normal cases but the last 2 are errors that are unrelated to the user being able to make the payment operation:

* in the case of a plugin timeout (or UNDEFINED result code), the operation might actually have completed; Kill Bill will run a background task to detect those cases and will query the plugin to verify if the state is actually known and when it is, it will update the *transaction status* and move the payment to its appropriate state.
* in the case of a plugin exception, this is probably a bug (either in the plugin, the third part gateway or Kill Bill itself), and so there is no attempt to fix those. However it advisable to check that those are rare instances and fix code/data appropriately.


2 typos

2 typos

= Partitioned Job

An example of the usage of the `DeployerPartitionHandler` and
`DeployerStepExecutionHandler` to partition a Spring Batch job.

== Requirements:

* Java 7 or Above

== Build:

[source,shell,indent=2]
----
$ ./mvnw clean install
----

== Execute:

[source,shell,indent=2]
----
$ export spring_datasource_url=jdbc:mysql://localhost:3306/<your database>
$ export spring_datasource_username=<your username>
$ export spring_datasource_password=<your password>
$ export spring_datasource_driverClassName=org.mariadb.jdbc.Driver
$ java -jar -Dspring.profiles.active=master target/partitioned-batch-job-1.0.0.BUILD-SNAPSHOT.jar
----

NOTE: This example will use require a MySql RDBMS repository and currently uses the mariadb jdbc driver to connect.
You can changes this another driver based on your needs.

== Dependencies:

A datasource (not in memory) must be configured based on normal Spring Boot conventions
(application.properties/application.yml/environment variables/etc).

= Partitioned Job

An example of the usage of the `DeployerPartitionHandler` and
`DeployerStepExecutionHandler` to partition a Spring Batch job.

== Requirements:

* Java 7 or Above

== Build:

[source,shell,indent=2]
----
$ ./mvnw clean install
----

== Execute:

[source,shell,indent=2]
----
$ export spring_datasource_url=jdbc:mariadb://localhost:3306/<your databse>
$ export spring_datasource_username=<your username>
$ export spring_datasource_password=<your password>
$ export spring_datasource_driverClassName=org.mariadb.jdbc.Driver
$ java -jar -Dspring.profiles.active=master target/partitioned-batch-job-1.0.0.BUILD-SNAPSHOT.jar
----

NOTE: This example will use require a MySql RDBMS repository and currently uses the mariadb jdbc driver to connect.
You can changes this another driver based on your needs.

== Dependencies:

A datasource (not in memory) must be configured based on normal Spring Boot conventions
(application.properties/application.yml/environment variables/etc).


Do not promise to fix limitations

Do not promise to fix limitations

// Copyright 2017 the original author or authors.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//      http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

[[gradle_daemon]]
= The Gradle Daemon

[quote, Wikipedia]
A daemon is a computer program that runs as a background process, rather than being under the direct control of an interactive user.

Gradle runs on the Java Virtual Machine (JVM) and uses several supporting libraries that require a non-trivial initialization time. As a result, it can sometimes seem a little slow to start. The solution to this problem is the Gradle _Daemon_: a long-lived background process that executes your builds much more quickly than would otherwise be the case. We accomplish this by avoiding the expensive bootstrapping process as well as leveraging caching, by keeping data about your project in memory. Running Gradle builds with the Daemon is no different than without. Simply configure whether you want to use it or not — everything else is handled transparently by Gradle.

[[sec:why_the_daemon]]
== Why the Gradle Daemon is important for performance

The Daemon is a long-lived process, so not only are we able to avoid the cost of JVM startup for every build, but we are able to cache information about project structure, files, tasks, and more in memory.

The reasoning is simple: improve build speed by reusing computations from previous builds. However, the benefits are dramatic: we typically measure build times reduced by 15-75% on subsequent builds. We recommend profiling your build by using `--profile` to get a sense of how much impact the Gradle Daemon can have for you.

The Gradle Daemon is enabled by default starting with Gradle 3.0, so you don't have to do anything to benefit from it.

[[sec:status]]
== Running Daemon Status

To get a list of running Gradle Daemons and their statuses use the `--status` command.

Sample output:
[source]
----
    PID VERSION                 STATUS
  28411 3.0                     IDLE
  34247 3.0                     BUSY
----

Currently, a given Gradle version can only connect to daemons of the same version. This means the status output will only show Daemons for the version of Gradle being invoked and not for any other versions. Future versions of Gradle will lift this constraint and will show the running Daemons for all versions of Gradle.

[[sec:disabling_the_daemon]]
== Disabling the Daemon

The Gradle Daemon is enabled by default, and we recommend always enabling it. There are several ways to disable the Daemon, but the most common one is to add the line

[source]
----
org.gradle.daemon=false
----

to the file `«USER_HOME»/.gradle/gradle.properties`, where `«USER_HOME»` is your home directory. That’s typically one of the following, depending on your platform:

* `C:\Users\<username>` (Windows Vista & 7+)
* `/Users/<username>` (macOS)
* `/home/<username>` (Linux)

If that file doesn’t exist, just create it using a text editor. You can find details of other ways to disable (and enable) the Daemon in <<#daemon_faq,Daemon FAQ>> further down. That section also contains more detailed information on how the Daemon works.

Note that having the Daemon enabled, all your builds will take advantage of the speed boost, regardless of the version of Gradle a particular build uses.

[TIP]
.Continuous integration
====

Since Gradle 3.0, we enable Daemon by default and recommend using it for both developers' machines and Continuous Integration servers. However, if you suspect that Daemon makes your CI builds unstable, you can disable it to use a fresh runtime for each build since the runtime is _completely_ isolated from any previous builds.

====

[[sec:stopping_an_existing_daemon]]
== Stopping an existing Daemon

As mentioned, the Daemon is a background process. You needn’t worry about a build up of Gradle processes on your machine, though. Every Daemon monitors its memory usage compared to total system memory and will stop itself if idle when available system memory is low. If you want to explicitly stop running Daemon processes for any reason, just use the command `gradle --stop`.

This will terminate all Daemon processes that were started with the same version of Gradle used to execute the command. If you have the Java Development Kit (JDK) installed, you can easily verify that a Daemon has stopped by running the `jps` command. You’ll see any running Daemons listed with the name `GradleDaemon`.

[[daemon_faq]]
== FAQ

[[sec:ways_to_disable_gradle_daemon]]
=== How do I disable the Gradle Daemon?

There are two recommended ways to disable the Daemon persistently for an environment:

* Via environment variables: add the flag `-Dorg.gradle.daemon=false` to the `GRADLE_OPTS` environment variable
* Via properties file: add `org.gradle.daemon=false` to the `«GRADLE_USER_HOME»/gradle.properties` file

[NOTE]
====

Note, `«GRADLE_USER_HOME»` defaults to `«USER_HOME»/.gradle`, where `«USER_HOME»` is the home directory of the current user. This location can be configured via the `-g` and `--gradle-user-home` command line switches, as well as by the `GRADLE_USER_HOME` environment variable and `org.gradle.user.home` JVM system property.

====

Both approaches have the same effect. Which one to use is up to personal preference. Most Gradle users choose the second option and add the entry to the user `gradle.properties` file.

On Windows, this command will disable the Daemon for the current user:

[source]
----
(if not exist "%USERPROFILE%/.gradle" mkdir "%USERPROFILE%/.gradle") && (echo. >> "%USERPROFILE%/.gradle/gradle.properties" && echo org.gradle.daemon=false >> "%USERPROFILE%/.gradle/gradle.properties")
----

On UNIX-like operating systems, the following Bash shell command will disable the Daemon for the current user:

[source,bash]
----
mkdir -p ~/.gradle && echo "org.gradle.daemon=false" >> ~/.gradle/gradle.properties
----

Once the Daemon is disabled for a build environment in this way, a Gradle Daemon will not be started unless explicitly requested using the `--daemon` option.

The `--daemon` and `--no-daemon` command line options enable and disable usage of the Daemon for individual build invocations when using the Gradle command line interface. These command line options have the _highest_ precedence when considering the build environment. Typically, it is more convenient to enable the Daemon for an environment (e.g. a user account) so that all builds use the Daemon without requiring to remember to supply the `--daemon` option.

[[sec:why_is_there_more_than_one_daemon_process_on_my_machine]]
=== Why is there more than one Daemon process on my machine?

There are several reasons why Gradle will create a new Daemon, instead of using one that is already running. The basic rule is that Gradle will start a new Daemon if there are no existing idle or compatible Daemons available. Gradle will kill any Daemon that has been idle for 3 hours or more, so you don't have to worry about cleaning them up manually.

idle::
An idle Daemon is one that is not currently executing a build or doing other useful work.
compatible::
A compatible Daemon is one that can (or can be made to) meet the requirements of the requested build environment. The Java runtime used to execute the build is an example aspect of the build environment. Another example is the set of JVM system properties required by the build runtime.

Some aspects of the requested build environment may not be met by an Daemon. If the Daemon is running with a Java 8 runtime, but the requested environment calls for Java 10, then the Daemon is not compatible and another must be started. Moreover, certain properties of a Java runtime cannot be changed once the JVM has started. For example, it is not possible to change the memory allocation (e.g. `-Xmx1024m`), default text encoding, default locale, etc of a running JVM.

The “requested build environment” is typically constructed implicitly from aspects of the build client’s (e.g. Gradle command line client, IDE etc.) environment and explicitly via command line switches and settings. See <<build_environment.adoc#build_environment,Build Environment>> for details on how to specify and control the build environment.

The following JVM system properties are effectively immutable. If the requested build environment requires any of these properties, with a different value than a Daemon’s JVM has for this property, the Daemon is not compatible.

* file.encoding
* user.language
* user.country
* user.variant
* java.io.tmpdir
* javax.net.ssl.keyStore
* javax.net.ssl.keyStorePassword
* javax.net.ssl.keyStoreType
* javax.net.ssl.trustStore
* javax.net.ssl.trustStorePassword
* javax.net.ssl.trustStoreType
* com.sun.management.jmxremote

The following JVM attributes, controlled by startup arguments, are also effectively immutable. The corresponding attributes of the requested build environment and the Daemon’s environment must match exactly in order for a Daemon to be compatible.

* The maximum heap size (i.e. the -Xmx JVM argument)
* The minimum heap size (i.e. the -Xms JVM argument)
* The boot classpath (i.e. the -Xbootclasspath argument)
* The “assertion” status (i.e. the -ea argument)

The required Gradle version is another aspect of the requested build environment. Daemon processes are coupled to a specific Gradle runtime. Working on multiple Gradle projects during a session that use different Gradle versions is a common reason for having more than one running Daemon process.

[[sec:how_much_memory_does_the_daemon_use_and_can_i_give_it_more]]
=== How much memory does the Daemon use and can I give it more?

If the requested build environment does not specify a maximum heap size, the Daemon will use up to 512MB of heap. It will use the JVM's default minimum heap size. 512MB is more than enough for most builds. Larger builds with hundreds of subprojects, lots of configuration, and source code may require, or perform better, with more memory.

To increase the amount of memory the Daemon can use, specify the appropriate flags as part of the requested build environment. Please see <<build_environment.adoc#build_environment,Build Environment>> for details.

[[sec:how_can_i_stop_a_daemon]]
=== How can I stop a Daemon?

Daemon processes will automatically terminate themselves after 3 hours of inactivity or less. If you wish to stop a Daemon process before this, you can either kill the process via your operating system or run the `gradle --stop` command. The `--stop` switch causes Gradle to request that _all_ running Daemon processes, _of the same Gradle version used to run the command_, terminate themselves.

[[sec:what_can_go_wrong_with_daemon]]
=== What can go wrong with Daemon?

Considerable engineering effort has gone into making the Daemon robust, transparent and unobtrusive during day to day development. However, Daemon processes can occasionally be corrupted or exhausted. A Gradle build executes arbitrary code from multiple sources. While Gradle itself is designed for and heavily tested with the Daemon, user build scripts and third party plugins can destabilize the Daemon process through defects such as memory leaks or global state corruption.

It is also possible to destabilize the Daemon (and build environment in general) by running builds that do not release resources correctly. This is a particularly poignant problem when using Microsoft Windows as it is less forgiving of programs that fail to close files after reading or writing.

Gradle actively monitors heap usage and attempts to detect when a leak is starting to exhaust the available heap space in the daemon. When it detects a problem, the Gradle daemon will finish the currently running build and proactively restart the daemon on the next build. This monitoring is enabled by default, but can be disabled by setting the `org.gradle.daemon.performance.enable-monitoring` system property to false.

If it is suspected that the Daemon process has become unstable, it can simply be killed. Recall that the `--no-daemon` switch can be specified for a build to prevent use of the Daemon. This can be useful to diagnose whether or not the Daemon is actually the culprit of a problem.

[[sec:tools_and_ides]]
== Tools & IDEs

The <<third_party_integration.adoc#embedding,Gradle Tooling API>> that is used by IDEs and other tools to integrate with Gradle _always_ uses the Gradle Daemon to execute builds. If you are executing Gradle builds from within your IDE you are using the Gradle Daemon and do not need to enable it for your environment.

[[sec:how_does_the_gradle_daemon_make_builds_faster]]
== How does the Gradle Daemon make builds faster?

The Gradle Daemon is a _long lived_ build process. In between builds it waits idly for the next build. This has the obvious benefit of only requiring Gradle to be loaded into memory once for multiple builds, as opposed to once for each build. This in itself is a significant performance optimization, but that's not where it stops.

A significant part of the story for modern JVM performance is runtime code optimization. For example, HotSpot (the JVM implementation provided by Oracle and used as the basis of OpenJDK) applies optimization to code while it is running. The optimization is progressive and not instantaneous. That is, the code is progressively optimized during execution which means that subsequent builds can be faster purely due to this optimization process. Experiments with HotSpot have shown that it takes somewhere between 5 and 10 builds for optimization to stabilize. The difference in perceived build time between the first build and the 10th for a Daemon can be quite dramatic.

The Daemon also allows more effective in memory caching across builds. For example, the classes needed by the build (e.g. plugins, build scripts) can be held in memory between builds. Similarly, Gradle can maintain in-memory caches of build data such as the hashes of task inputs and outputs, used for incremental building.

To detect changes on the file system, and to calculate what needs to be rebuilt, Gradle collects a lot of information about the state of the file system during every build.
When <<sec:daemon_watch_fs,watching the file system>> is enabled, the Daemon can re-use the already collected information from the last build.
This can save a significant amount of time for incremental builds, where the number of changes to the file system between two builds is typically low.

[[sec:daemon_watch_fs]]
== Watching the file system

To detect changes on the file system, and to calculate what needs to be rebuilt, Gradle collects information about the file system in-memory during every build (aka _Virtual File System_).
By watching the file system, Gradle can keep the Virtual File System in sync with the file system even between builds.
Doing so allows the Daemon to save the time to rebuild the Virtual File System from disk for the next build.
For incremental builds, there are typically only a few changes between builds.
Therefore, incremental builds can re-use most of the Virtual File System from the last build and benefit the most from watching the file system.

Gradle uses operating system features for watching the file system.
It supports the feature on these operating systems and file systems:

- Windows 10 with NTFS,
- Linux (Ubuntu 16.04 or later, CentOS 8 or later, Red Hat Enterprise Linux 8 or later, Amazon Linux 2) using ext3 and ext4,
- macOS 10.14 (Mojave) or later on APFS and HFS+.

Network file systems like NFS and SMB are not supported.
FAT file systems are not supported.

Watching the file system is an experimental feature and is disabled by default.
You can enable the feature in a couple of ways:

Run with `--watch-fs` on the command line::
This enables watching the file system for this build only.
Put `org.gradle.vfs.watch=true` in your `gradle.properties`::
This enables watching the file system for all builds, unless explicitly disabled with `--no-watch-fs`.

[[sec:daemon_watch_fs_troubleshooting]]
=== Troubleshooting file system watching

Limitations::
File system watching currently has the following limitations:
- If you have symlinks in your build, you won’t get the performance benefits for those locations (we plan to change this in the future).
- When multiple daemons are running, the idle ones can pick up the changes produced by the others and create large log files with lots of debug info about the changes.
- On Windows, we don’t support SUBST and network drives (they might work, but we don’t test them yet).

Gradle does not pick up some of my changes.::
_Please https://gradle-community.slack.com/app_redirect?channel=file-system-watching[let us know on the Gradle community Slack] if that happens to you._
If your build declares its inputs and outputs correctly, this should not happen.
So it’s either a bug we need to fix, or your build is lacking the declaration of some inputs or outputs.

Why am I always getting “Received 8 file system events since last build” even though I only changed one file?::
These are harmless notifications about changes to Gradle's own caches that happen after file watching has started.

`Dropped VFS state due to lost state`::
_Please https://gradle-community.slack.com/app_redirect?channel=file-system-watching[let us know on the Gradle community Slack] if that happens to you._
This message means that either
+
--
- the daemon received some unknown file system event,
- too many changes happened, and the watching API couldn’t handle it.
--
In both cases the build cannot benefit from file system watching.

`java.io.IOException: Too many open files`::
If you receive this error on macOS, you need to raise your open files limit, see https://superuser.com/a/443168/8117[here].

[[sec:inotify_watches_limit]]
===  Linux-specific notes

File system watching uses http://en.wikipedia.org/wiki/Inotify[inotify] on Linux.
Depending on the size of your build, it may be necessary to increase inotify limits.
If you are using an IDE, then you probably already had to increase the limits in the past.

File system watching uses one inotify watch per watched directory.
You can see the current limit of inotify watches per user by running:

[source,bash]
----
cat /proc/sys/fs/inotify/max_user_watches
----

To increase the limit to e.g. 512K watches run the following:

[source,bash]
----
echo 524288 | sudo tee -a /etc/sysctl.conf
sudo sysctl -p --system
----

Each used inotify watch takes up to 1KB of memory.
Assuming inotify uses all the 512K watches then around 500MB will be used for watching the file system.
If your environment is memory constraint, you may want to disable file system watching.

// Copyright 2017 the original author or authors.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//      http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

[[gradle_daemon]]
= The Gradle Daemon

[quote, Wikipedia]
A daemon is a computer program that runs as a background process, rather than being under the direct control of an interactive user.

Gradle runs on the Java Virtual Machine (JVM) and uses several supporting libraries that require a non-trivial initialization time. As a result, it can sometimes seem a little slow to start. The solution to this problem is the Gradle _Daemon_: a long-lived background process that executes your builds much more quickly than would otherwise be the case. We accomplish this by avoiding the expensive bootstrapping process as well as leveraging caching, by keeping data about your project in memory. Running Gradle builds with the Daemon is no different than without. Simply configure whether you want to use it or not — everything else is handled transparently by Gradle.

[[sec:why_the_daemon]]
== Why the Gradle Daemon is important for performance

The Daemon is a long-lived process, so not only are we able to avoid the cost of JVM startup for every build, but we are able to cache information about project structure, files, tasks, and more in memory.

The reasoning is simple: improve build speed by reusing computations from previous builds. However, the benefits are dramatic: we typically measure build times reduced by 15-75% on subsequent builds. We recommend profiling your build by using `--profile` to get a sense of how much impact the Gradle Daemon can have for you.

The Gradle Daemon is enabled by default starting with Gradle 3.0, so you don't have to do anything to benefit from it.

[[sec:status]]
== Running Daemon Status

To get a list of running Gradle Daemons and their statuses use the `--status` command.

Sample output:
[source]
----
    PID VERSION                 STATUS
  28411 3.0                     IDLE
  34247 3.0                     BUSY
----

Currently, a given Gradle version can only connect to daemons of the same version. This means the status output will only show Daemons for the version of Gradle being invoked and not for any other versions. Future versions of Gradle will lift this constraint and will show the running Daemons for all versions of Gradle.

[[sec:disabling_the_daemon]]
== Disabling the Daemon

The Gradle Daemon is enabled by default, and we recommend always enabling it. There are several ways to disable the Daemon, but the most common one is to add the line

[source]
----
org.gradle.daemon=false
----

to the file `«USER_HOME»/.gradle/gradle.properties`, where `«USER_HOME»` is your home directory. That’s typically one of the following, depending on your platform:

* `C:\Users\<username>` (Windows Vista & 7+)
* `/Users/<username>` (macOS)
* `/home/<username>` (Linux)

If that file doesn’t exist, just create it using a text editor. You can find details of other ways to disable (and enable) the Daemon in <<#daemon_faq,Daemon FAQ>> further down. That section also contains more detailed information on how the Daemon works.

Note that having the Daemon enabled, all your builds will take advantage of the speed boost, regardless of the version of Gradle a particular build uses.

[TIP]
.Continuous integration
====

Since Gradle 3.0, we enable Daemon by default and recommend using it for both developers' machines and Continuous Integration servers. However, if you suspect that Daemon makes your CI builds unstable, you can disable it to use a fresh runtime for each build since the runtime is _completely_ isolated from any previous builds.

====

[[sec:stopping_an_existing_daemon]]
== Stopping an existing Daemon

As mentioned, the Daemon is a background process. You needn’t worry about a build up of Gradle processes on your machine, though. Every Daemon monitors its memory usage compared to total system memory and will stop itself if idle when available system memory is low. If you want to explicitly stop running Daemon processes for any reason, just use the command `gradle --stop`.

This will terminate all Daemon processes that were started with the same version of Gradle used to execute the command. If you have the Java Development Kit (JDK) installed, you can easily verify that a Daemon has stopped by running the `jps` command. You’ll see any running Daemons listed with the name `GradleDaemon`.

[[daemon_faq]]
== FAQ

[[sec:ways_to_disable_gradle_daemon]]
=== How do I disable the Gradle Daemon?

There are two recommended ways to disable the Daemon persistently for an environment:

* Via environment variables: add the flag `-Dorg.gradle.daemon=false` to the `GRADLE_OPTS` environment variable
* Via properties file: add `org.gradle.daemon=false` to the `«GRADLE_USER_HOME»/gradle.properties` file

[NOTE]
====

Note, `«GRADLE_USER_HOME»` defaults to `«USER_HOME»/.gradle`, where `«USER_HOME»` is the home directory of the current user. This location can be configured via the `-g` and `--gradle-user-home` command line switches, as well as by the `GRADLE_USER_HOME` environment variable and `org.gradle.user.home` JVM system property.

====

Both approaches have the same effect. Which one to use is up to personal preference. Most Gradle users choose the second option and add the entry to the user `gradle.properties` file.

On Windows, this command will disable the Daemon for the current user:

[source]
----
(if not exist "%USERPROFILE%/.gradle" mkdir "%USERPROFILE%/.gradle") && (echo. >> "%USERPROFILE%/.gradle/gradle.properties" && echo org.gradle.daemon=false >> "%USERPROFILE%/.gradle/gradle.properties")
----

On UNIX-like operating systems, the following Bash shell command will disable the Daemon for the current user:

[source,bash]
----
mkdir -p ~/.gradle && echo "org.gradle.daemon=false" >> ~/.gradle/gradle.properties
----

Once the Daemon is disabled for a build environment in this way, a Gradle Daemon will not be started unless explicitly requested using the `--daemon` option.

The `--daemon` and `--no-daemon` command line options enable and disable usage of the Daemon for individual build invocations when using the Gradle command line interface. These command line options have the _highest_ precedence when considering the build environment. Typically, it is more convenient to enable the Daemon for an environment (e.g. a user account) so that all builds use the Daemon without requiring to remember to supply the `--daemon` option.

[[sec:why_is_there_more_than_one_daemon_process_on_my_machine]]
=== Why is there more than one Daemon process on my machine?

There are several reasons why Gradle will create a new Daemon, instead of using one that is already running. The basic rule is that Gradle will start a new Daemon if there are no existing idle or compatible Daemons available. Gradle will kill any Daemon that has been idle for 3 hours or more, so you don't have to worry about cleaning them up manually.

idle::
An idle Daemon is one that is not currently executing a build or doing other useful work.
compatible::
A compatible Daemon is one that can (or can be made to) meet the requirements of the requested build environment. The Java runtime used to execute the build is an example aspect of the build environment. Another example is the set of JVM system properties required by the build runtime.

Some aspects of the requested build environment may not be met by an Daemon. If the Daemon is running with a Java 8 runtime, but the requested environment calls for Java 10, then the Daemon is not compatible and another must be started. Moreover, certain properties of a Java runtime cannot be changed once the JVM has started. For example, it is not possible to change the memory allocation (e.g. `-Xmx1024m`), default text encoding, default locale, etc of a running JVM.

The “requested build environment” is typically constructed implicitly from aspects of the build client’s (e.g. Gradle command line client, IDE etc.) environment and explicitly via command line switches and settings. See <<build_environment.adoc#build_environment,Build Environment>> for details on how to specify and control the build environment.

The following JVM system properties are effectively immutable. If the requested build environment requires any of these properties, with a different value than a Daemon’s JVM has for this property, the Daemon is not compatible.

* file.encoding
* user.language
* user.country
* user.variant
* java.io.tmpdir
* javax.net.ssl.keyStore
* javax.net.ssl.keyStorePassword
* javax.net.ssl.keyStoreType
* javax.net.ssl.trustStore
* javax.net.ssl.trustStorePassword
* javax.net.ssl.trustStoreType
* com.sun.management.jmxremote

The following JVM attributes, controlled by startup arguments, are also effectively immutable. The corresponding attributes of the requested build environment and the Daemon’s environment must match exactly in order for a Daemon to be compatible.

* The maximum heap size (i.e. the -Xmx JVM argument)
* The minimum heap size (i.e. the -Xms JVM argument)
* The boot classpath (i.e. the -Xbootclasspath argument)
* The “assertion” status (i.e. the -ea argument)

The required Gradle version is another aspect of the requested build environment. Daemon processes are coupled to a specific Gradle runtime. Working on multiple Gradle projects during a session that use different Gradle versions is a common reason for having more than one running Daemon process.

[[sec:how_much_memory_does_the_daemon_use_and_can_i_give_it_more]]
=== How much memory does the Daemon use and can I give it more?

If the requested build environment does not specify a maximum heap size, the Daemon will use up to 512MB of heap. It will use the JVM's default minimum heap size. 512MB is more than enough for most builds. Larger builds with hundreds of subprojects, lots of configuration, and source code may require, or perform better, with more memory.

To increase the amount of memory the Daemon can use, specify the appropriate flags as part of the requested build environment. Please see <<build_environment.adoc#build_environment,Build Environment>> for details.

[[sec:how_can_i_stop_a_daemon]]
=== How can I stop a Daemon?

Daemon processes will automatically terminate themselves after 3 hours of inactivity or less. If you wish to stop a Daemon process before this, you can either kill the process via your operating system or run the `gradle --stop` command. The `--stop` switch causes Gradle to request that _all_ running Daemon processes, _of the same Gradle version used to run the command_, terminate themselves.

[[sec:what_can_go_wrong_with_daemon]]
=== What can go wrong with Daemon?

Considerable engineering effort has gone into making the Daemon robust, transparent and unobtrusive during day to day development. However, Daemon processes can occasionally be corrupted or exhausted. A Gradle build executes arbitrary code from multiple sources. While Gradle itself is designed for and heavily tested with the Daemon, user build scripts and third party plugins can destabilize the Daemon process through defects such as memory leaks or global state corruption.

It is also possible to destabilize the Daemon (and build environment in general) by running builds that do not release resources correctly. This is a particularly poignant problem when using Microsoft Windows as it is less forgiving of programs that fail to close files after reading or writing.

Gradle actively monitors heap usage and attempts to detect when a leak is starting to exhaust the available heap space in the daemon. When it detects a problem, the Gradle daemon will finish the currently running build and proactively restart the daemon on the next build. This monitoring is enabled by default, but can be disabled by setting the `org.gradle.daemon.performance.enable-monitoring` system property to false.

If it is suspected that the Daemon process has become unstable, it can simply be killed. Recall that the `--no-daemon` switch can be specified for a build to prevent use of the Daemon. This can be useful to diagnose whether or not the Daemon is actually the culprit of a problem.

[[sec:tools_and_ides]]
== Tools & IDEs

The <<third_party_integration.adoc#embedding,Gradle Tooling API>> that is used by IDEs and other tools to integrate with Gradle _always_ uses the Gradle Daemon to execute builds. If you are executing Gradle builds from within your IDE you are using the Gradle Daemon and do not need to enable it for your environment.

[[sec:how_does_the_gradle_daemon_make_builds_faster]]
== How does the Gradle Daemon make builds faster?

The Gradle Daemon is a _long lived_ build process. In between builds it waits idly for the next build. This has the obvious benefit of only requiring Gradle to be loaded into memory once for multiple builds, as opposed to once for each build. This in itself is a significant performance optimization, but that's not where it stops.

A significant part of the story for modern JVM performance is runtime code optimization. For example, HotSpot (the JVM implementation provided by Oracle and used as the basis of OpenJDK) applies optimization to code while it is running. The optimization is progressive and not instantaneous. That is, the code is progressively optimized during execution which means that subsequent builds can be faster purely due to this optimization process. Experiments with HotSpot have shown that it takes somewhere between 5 and 10 builds for optimization to stabilize. The difference in perceived build time between the first build and the 10th for a Daemon can be quite dramatic.

The Daemon also allows more effective in memory caching across builds. For example, the classes needed by the build (e.g. plugins, build scripts) can be held in memory between builds. Similarly, Gradle can maintain in-memory caches of build data such as the hashes of task inputs and outputs, used for incremental building.

To detect changes on the file system, and to calculate what needs to be rebuilt, Gradle collects a lot of information about the state of the file system during every build.
When <<sec:daemon_watch_fs,watching the file system>> is enabled, the Daemon can re-use the already collected information from the last build.
This can save a significant amount of time for incremental builds, where the number of changes to the file system between two builds is typically low.

[[sec:daemon_watch_fs]]
== Watching the file system

To detect changes on the file system, and to calculate what needs to be rebuilt, Gradle collects information about the file system in-memory during every build (aka _Virtual File System_).
By watching the file system, Gradle can keep the Virtual File System in sync with the file system even between builds.
Doing so allows the Daemon to save the time to rebuild the Virtual File System from disk for the next build.
For incremental builds, there are typically only a few changes between builds.
Therefore, incremental builds can re-use most of the Virtual File System from the last build and benefit the most from watching the file system.

Gradle uses operating system features for watching the file system.
It supports the feature on these operating systems and file systems:

- Windows 10 with NTFS,
- Linux (Ubuntu 16.04 or later, CentOS 8 or later, Red Hat Enterprise Linux 8 or later, Amazon Linux 2) using ext3 and ext4,
- macOS 10.14 (Mojave) or later on APFS and HFS+.

Network file systems like NFS and SMB are not supported.
FAT file systems are not supported.

Watching the file system is an experimental feature and is disabled by default.
You can enable the feature in a couple of ways:

Run with `--watch-fs` on the command line::
This enables watching the file system for this build only.
Put `org.gradle.vfs.watch=true` in your `gradle.properties`::
This enables watching the file system for all builds, unless explicitly disabled with `--no-watch-fs`.

[[sec:daemon_watch_fs_troubleshooting]]
=== Troubleshooting file system watching

Limitations::
We are working on removing the following limitations to make file system watching production ready.
- If you have symlinks in your build, you won’t get the performance benefits for those locations (we plan to change this in the future).
- When multiple daemons are running, the idle ones can pick up the changes produced by the others and create large log files with lots of debug info about the changes.
- On Windows, we don’t support SUBST and network drives (they might work, but we don’t test them yet).

Gradle does not pick up some of my changes.::
_Please https://gradle-community.slack.com/app_redirect?channel=file-system-watching[let us know on the Gradle community Slack] if that happens to you._
If your build declares its inputs and outputs correctly, this should not happen.
So it’s either a bug we need to fix, or your build is lacking the declaration of some inputs or outputs.

Why am I always getting “Received 8 file system events since last build” even though I only changed one file?::
These are harmless notifications about changes to Gradle's own caches that happen after file watching has started.

`Dropped VFS state due to lost state`::
_Please https://gradle-community.slack.com/app_redirect?channel=file-system-watching[let us know on the Gradle community Slack] if that happens to you._
This message means that either
+
--
- the daemon received some unknown file system event,
- too many changes happened, and the watching API couldn’t handle it.
--
In both cases the build cannot benefit from file system watching.

`java.io.IOException: Too many open files`::
If you receive this error on macOS, you need to raise your open files limit, see https://superuser.com/a/443168/8117[here].

[[sec:inotify_watches_limit]]
===  Linux-specific notes

File system watching uses http://en.wikipedia.org/wiki/Inotify[inotify] on Linux.
Depending on the size of your build, it may be necessary to increase inotify limits.
If you are using an IDE, then you probably already had to increase the limits in the past.

File system watching uses one inotify watch per watched directory.
You can see the current limit of inotify watches per user by running:

[source,bash]
----
cat /proc/sys/fs/inotify/max_user_watches
----

To increase the limit to e.g. 512K watches run the following:

[source,bash]
----
echo 524288 | sudo tee -a /etc/sysctl.conf
sudo sysctl -p --system
----

Each used inotify watch takes up to 1KB of memory.
Assuming inotify uses all the 512K watches then around 500MB will be used for watching the file system.
If your environment is memory constraint, you may want to disable file system watching.


Update 2015-06-12-Noobs-guide-to-Machine-Learning.adoc

= Noob's guide to Machine Learning
:hp-tags: machine learning

You might be completely overwhelmed by the information available over the internet
and must be looking on how to start the journey in the world of data analytics,
don't worry we are here to help , below you will find must know things to get
started and learn everything about machine learning.  +

One can directly get started using various available tools like R studio, Amazon machine learning as a service
Azure Machine learning, Anaconda(ipython) etc.
but before you do that you must know the basics or building blocks of machine learning approach.+

*Neural nets*/ *Support Vector Machine* etc might sound great but these model
implentaion is the last step. The most important step is cleaning and processing the data,
we will talk about it later in detail.

For now, following topics are the building blocks, we will post about each of
them in seperate posts .

. *Statistics*
. *Linear Algebra*
. *Data Cleaning*
. *Data Processing (Dimension Reduction)*
. *Feature Selection*

It's time to clean the dust off your Math/Statistics book and revise the concepts about Linear algebra and Mean/Mode/Standard Deviation , till you do that we will write the post
about next step, where we will learn a algortihm *(PCA)* for data processing and get hands on data cleaning and processing step using Anaconda(ipython).

Don't worry if this information also overwhelmed you , we will teach you
each and everything, Just stick with us.

*Happy Learning, See you next week*

= Noob's guide to Machine Learning
:hp-tags: Machine Learning

You might be completely overwhelmed by the information available over the internet
and must be looking on how to start the journey in the world of data analytics,
don’t worry we are here to help , below you will find must know things to get started
and learn everything about machine learning.

One can directly get started using various available tools like R studio,
Amazon machine learning as a service Azure Machine learning, Anaconda(ipython) etc.
but before you do that you must know the basics or building blocks of machine learning approach.

*Neural nets*/ *Support Vector Machine* etc. might sound great but these model implementation is the last step.
The most important step is cleaning and processing the data, we will talk about it later in detail.

For now, following topics are the building blocks, we will post about each of them in separate posts .

	. Statistics
    . Linear Algebra
	. Data Cleaning
	. Data Processing (Dimension Reduction)
    . Feature Selection

It’s time to clean the dust off your Math/Statistics book and revise the concepts about Linear algebra
and Mean/Mode/Standard Deviation , till you do that we will write the post about next step,

where we will learn a algorithm (PCA) for data processing and get hands on data cleaning
and processing step using Anaconda(ipython).

Don’t worry if this information also overwhelmed you , we will teach you each and everything, Just stick with us.

Happy Learning, See you next week


Fixed asciidoc

Fixed asciidoc

[[analysis-hunspell-tokenfilter]]
=== Hunspell Token Filter

Basic support for hunspell stemming. Hunspell dictionaries will be
picked up from a dedicated hunspell directory on the filesystem
(`<path.conf>/hunspell`). Each dictionary is expected to
have its own directory named after its associated locale (language).
This dictionary directory is expected to hold a single `*.aff` and
one or more `*.dic` files (all of which will automatically be picked up).
For example, assuming the default hunspell location is used, the
following directory layout will define the `en_US` dictionary:

[source,js]
--------------------------------------------------
- conf
    |-- hunspell
    |    |-- en_US
    |    |    |-- en_US.dic
    |    |    |-- en_US.aff
--------------------------------------------------

Each dictionary can be configured with one setting:

`ignore_case`::
    If true, dictionary matching will be case insensitive
    (defaults to `false`)

This setting can be configured globally in `elasticsearch.yml` using

* `indices.analysis.hunspell.dictionary.ignore_case`

or for specific dictionaries:

* `indices.analysis.hunspell.dictionary.en_US.ignore_case`.

It is also possible to add `settings.yml` file under the dictionary
directory which holds these settings (this will override any other
settings defined in the `elasticsearch.yml`).

One can use the hunspell stem filter by configuring it the analysis
settings:

[source,js]
--------------------------------------------------
{
    "analysis" : {
        "analyzer" : {
            "en" : {
                "tokenizer" : "standard",
                "filter" : [ "lowercase", "en_US" ]
            }
        },
        "filter" : {
            "en_US" : {
                "type" : "hunspell",
                "locale" : "en_US",
                "dedup" : true
            }
        }
    }
}
--------------------------------------------------

The hunspell token filter accepts four options:

`locale`::
    A locale for this filter. If this is unset, the `lang` or
    `language` are used instead - so one of these has to be set.

`dictionary`::
    The name of a dictionary. The path to your hunspell
    dictionaries should be configured via
    `indices.analysis.hunspell.dictionary.location` before.

`dedup`::
    If only unique terms should be returned, this needs to be
    set to `true`. Defaults to `true`.

`longest_only`::
    If only the longest term should be returned, set this to `true`.
    Defaults to `false`: all possible stems are returned.

NOTE: As opposed to the snowball stemmers (which are algorithm based)
this is a dictionary lookup based stemmer and therefore the quality of
the stemming is determined by the quality of the dictionary.

[float]
==== Dictionary loading

By default, the default Hunspell directory (`config/hunspell/`) is checked
for dictionaries when the node starts up, and any dictionaries are
automatically loaded.

Dictionary loading can be deferred until they are actually used by setting
`indices.analysis.hunspell.dictionary.lazy` to `true` in the config file.

[float]
==== References

Hunspell is a spell checker and morphological analyzer designed for
languages with rich morphology and complex word compounding and
character encoding.

1. Wikipedia, http://en.wikipedia.org/wiki/Hunspell

2. Source code, http://hunspell.sourceforge.net/

3. Open Office Hunspell dictionaries, http://wiki.openoffice.org/wiki/Dictionaries

4.  Mozilla Hunspell dictionaries, https://addons.mozilla.org/en-US/firefox/language-tools/

5. Chromium Hunspell dictionaries,
   http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/hunspell_dictionaries/

[[analysis-hunspell-tokenfilter]]
=== Hunspell Token Filter

Basic support for hunspell stemming. Hunspell dictionaries will be
picked up from a dedicated hunspell directory on the filesystem
(`<path.conf>/hunspell`). Each dictionary is expected to
have its own directory named after its associated locale (language).
This dictionary directory is expected to hold a single `*.aff` and
one or more `*.dic` files (all of which will automatically be picked up).
For example, assuming the default hunspell location is used, the
following directory layout will define the `en_US` dictionary:

[source,js]
--------------------------------------------------
- conf
    |-- hunspell
    |    |-- en_US
    |    |    |-- en_US.dic
    |    |    |-- en_US.aff
--------------------------------------------------

Each dictionary can be configured with one setting:

`ignore_case`::
    If true, dictionary matching will be case insensitive
    (defaults to `false`)

This setting can be configured globally in `elasticsearch.yml` using

* `indices.analysis.hunspell.dictionary.ignore_case`

or for specific dictionaries:

* `indices.analysis.hunspell.dictionary.en_US.ignore_case`.

It is also possible to add `settings.yml` file under the dictionary
directory which holds these settings (this will override any other
settings defined in the `elasticsearch.yml`).

One can use the hunspell stem filter by configuring it the analysis
settings:

[source,js]
--------------------------------------------------
{
    "analysis" : {
        "analyzer" : {
            "en" : {
                "tokenizer" : "standard",
                "filter" : [ "lowercase", "en_US" ]
            }
        },
        "filter" : {
            "en_US" : {
                "type" : "hunspell",
                "locale" : "en_US",
                "dedup" : true
            }
        }
    }
}
--------------------------------------------------

The hunspell token filter accepts four options:

`locale`::
    A locale for this filter. If this is unset, the `lang` or
    `language` are used instead - so one of these has to be set.

`dictionary`::
    The name of a dictionary. The path to your hunspell
    dictionaries should be configured via
    `indices.analysis.hunspell.dictionary.location` before.

`dedup`::
    If only unique terms should be returned, this needs to be
    set to `true`. Defaults to `true`.

`longest_only`::
    If only the longest term should be returned, set this to `true`.
    Defaults to `false`: all possible stems are returned.

NOTE: As opposed to the snowball stemmers (which are algorithm based)
this is a dictionary lookup based stemmer and therefore the quality of
the stemming is determined by the quality of the dictionary.

[float]
==== Dictionary loading

By default, the default Hunspell directory (`config/hunspell/`) is checked
for dictionaries when the node starts up, and any dictionaries are
automatically loaded.

Dictionary loading can be deferred until they are actually used by setting
`indices.analysis.hunspell.dictionary.lazy` to `true`in the config file.

[float]
==== References

Hunspell is a spell checker and morphological analyzer designed for
languages with rich morphology and complex word compounding and
character encoding.

1. Wikipedia, http://en.wikipedia.org/wiki/Hunspell

2. Source code, http://hunspell.sourceforge.net/

3. Open Office Hunspell dictionaries, http://wiki.openoffice.org/wiki/Dictionaries

4.  Mozilla Hunspell dictionaries, https://addons.mozilla.org/en-US/firefox/language-tools/

5. Chromium Hunspell dictionaries,
   http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/hunspell_dictionaries/