--- title: Traffic Routing description: Configuration affecting traffic routing. location: https://istio.io/docs/reference/config/istio.networking.v1alpha3.html layout: protoc-gen-docs generator: protoc-gen-docs aliases: - /docs/reference/config/istio.routing.v1alpha1/ number_of_entries: 60 ---
Configuration affecting traffic routing. Here are a few terms useful to define in the context of traffic routing.
Service
a unit of application behavior bound to a unique name in a
service registry. Services consist of multiple network endpoints
implemented by workload instances running on pods, containers, VMs etc.
Service versions (a.k.a. subsets)
- In a continuous deployment
scenario, for a given service, there can be distinct subsets of
instances running different variants of the application binary. These
variants are not necessarily different API versions. They could be
iterative changes to the same service, deployed in different
environments (prod, staging, dev, etc.). Common scenarios where this
occurs include A/B testing, canary rollouts, etc. The choice of a
particular version can be decided based on various criterion (headers,
url, etc.) and/or by weights assigned to each version. Each service has
a default version consisting of all its instances.
Source
- A downstream client calling a service.
Host
- The address used by a client when attempting to connect to a
service.
Access model
- Applications address only the destination service
(Host) without knowledge of individual service versions (subsets). The
actual choice of the version is determined by the proxy/sidecar, enabling the
application code to decouple itself from the evolution of dependent
services.
CaptureMode describes how traffic to a listener is expected to be captured. Applicable only when the listener is bound to an IP.
| Name | Description |
|---|---|
DEFAULT |
The default capture mode defined by the environment |
IPTABLES |
Capture traffic using IPtables redirection |
NONE |
No traffic capture. When used in egress listener, the application is expected to explicitly communicate with the listener port/unix domain socket. When used in ingress listener, care needs to be taken to ensure that the listener port is not in use by other processes on the host. |
Connection pool settings for an upstream host. The settings apply to each individual host in the upstream service. See Envoy’s circuit breaker for more details. Connection pool settings can be applied at the TCP level as well as at HTTP level.
For example, the following rule sets a limit of 100 connections to redis service called myredissrv with a connect timeout of 30ms
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: bookinfo-redis
spec:
host: myredissrv.prod.svc.cluster.local
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
connectTimeout: 30ms
tcpKeepalive:
time: 7200s
interval: 75s
Settings applicable to HTTP1.1/HTTP2/GRPC connections.
Settings common to both HTTP and TCP upstream connections.
TCP keepalive.
Describes the Cross-Origin Resource Sharing (CORS) policy, for a given
service. Refer to
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
for further details about cross origin resource sharing. For example,
the following rule restricts cross origin requests to those originating
from example.com domain using HTTP POST/GET, and sets the
Access-Control-Allow-Credentials
header to false. In addition, it only
exposes X-Foo-bar
header and sets an expiry period of 1 day.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- route:
- destination:
host: ratings.prod.svc.cluster.local
subset: v1
corsPolicy:
allowOrigin:
- example.com
allowMethods:
- POST
- GET
allowCredentials: false
allowHeaders:
- X-Foo-Bar
maxAge: "1d"
Destination indicates the network addressable service to which the request/connection will be sent after processing a routing rule. The destination.host should unambiguously refer to a service in the service registry. Istio’s service registry is composed of all the services found in the platform’s service registry (e.g., Kubernetes services, Consul services), as well as services declared through the ServiceEntry resource.
Note for Kubernetes users: When short names are used (e.g. “reviews” instead of “reviews.default.svc.cluster.local”), Istio will interpret the short name based on the namespace of the rule, not the service. A rule in the “default” namespace containing a host “reviews will be interpreted as “reviews.default.svc.cluster.local”, irrespective of the actual namespace associated with the reviews service. To avoid potential misconfigurations, it is recommended to always use fully qualified domain names over short names.
The following Kubernetes example routes all traffic by default to pods of the reviews service with label “version: v1” (i.e., subset v1), and some to subset v2, in a kubernetes environment.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews-route
namespace: foo
spec:
hosts:
- reviews # interpreted as reviews.foo.svc.cluster.local
http:
- match:
- uri:
prefix: "/wpcatalog"
- uri:
prefix: "/consumercatalog"
rewrite:
uri: "/newcatalog"
route:
- destination:
host: reviews # interpreted as reviews.foo.svc.cluster.local
subset: v2
- route:
- destination:
host: reviews # interpreted as reviews.foo.svc.cluster.local
subset: v1
And the associated DestinationRule
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews-destination
namespace: foo
spec:
host: reviews # interpreted as reviews.foo.svc.cluster.local
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
The following VirtualService sets a timeout of 5s for all calls to productpage.prod.svc.cluster.local service in Kubernetes. Notice that there are no subsets defined in this rule. Istio will fetch all instances of productpage.prod.svc.cluster.local service from the service registry and populate the sidecar’s load balancing pool. Also, notice that this rule is set in the istio-system namespace but uses the fully qualified domain name of the productpage service, productpage.prod.svc.cluster.local. Therefore the rule’s namespace does not have an impact in resolving the name of the productpage service.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-productpage-rule
namespace: istio-system
spec:
hosts:
- productpage.prod.svc.cluster.local # ignores rule namespace
http:
- timeout: 5s
route:
- destination:
host: productpage.prod.svc.cluster.local
To control routing for traffic bound to services outside the mesh, external services must first be added to Istio’s internal service registry using the ServiceEntry resource. VirtualServices can then be defined to control traffic bound to these external services. For example, the following rules define a Service for wikipedia.org and set a timeout of 5s for http requests.
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-svc-wikipedia
spec:
hosts:
- wikipedia.org
location: MESH_EXTERNAL
ports:
- number: 80
name: example-http
protocol: HTTP
resolution: DNS
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-wiki-rule
spec:
hosts:
- wikipedia.org
http:
- timeout: 5s
route:
- destination:
host: wikipedia.org
DestinationRule
defines policies that apply to traffic intended for a
service after routing has occurred. These rules specify configuration
for load balancing, connection pool size from the sidecar, and outlier
detection settings to detect and evict unhealthy hosts from the load
balancing pool. For example, a simple load balancing policy for the
ratings service would look as follows:
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: bookinfo-ratings
spec:
host: ratings.prod.svc.cluster.local
trafficPolicy:
loadBalancer:
simple: LEAST_CONN
Version specific policies can be specified by defining a named
subset
and overriding the settings specified at the service level. The
following rule uses a round robin load balancing policy for all traffic
going to a subset named testversion that is composed of endpoints (e.g.,
pods) with labels (version:v3).
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: bookinfo-ratings
spec:
host: ratings.prod.svc.cluster.local
trafficPolicy:
loadBalancer:
simple: LEAST_CONN
subsets:
- name: testversion
labels:
version: v3
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
Note: Policies specified for subsets will not take effect until a route rule explicitly sends traffic to this subset.
Traffic policies can be customized to specific ports as well. The following rule uses the least connection load balancing policy for all traffic to port 80, while uses a round robin load balancing setting for traffic to the port 9080.
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: bookinfo-ratings-port
spec:
host: ratings.prod.svc.cluster.local
trafficPolicy: # Apply to all ports
portLevelSettings:
- port:
number: 80
loadBalancer:
simple: LEAST_CONN
- port:
number: 9080
loadBalancer:
simple: ROUND_ROBIN
EnvoyFilter
describes Envoy proxy-specific filters that can be used to
customize the Envoy proxy configuration generated by Istio networking
subsystem (Pilot). This feature must be used with care, as incorrect
configurations could potentially destabilize the entire mesh.
NOTE 1: Since this is break glass configuration, there will not be any backward compatibility across different Istio releases. In other words, this configuration is subject to change based on internal implementation of Istio networking subsystem.
NOTE 2: When multiple EnvoyFilters are bound to the same workload, all filter configurations will be processed sequentially in order of creation time. The behavior is undefined if multiple EnvoyFilter configurations conflict with each other.
The following example for Kubernetes enables Envoy’s Lua filter for all inbound calls arriving at service port 8080 of the reviews service pod with labels “app: reviews”.
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: reviews-lua
spec:
workloadLabels:
app: reviews
filters:
- listenerMatch:
portNumber: 8080
listenerType: SIDECAR_INBOUND #will match with the inbound listener for reviews:8080
filterName: envoy.lua
filterType: HTTP
filterConfig:
inlineCode: |
... lua code ...
Envoy filters to be added to a network or http filter chain.
| Name | Description |
|---|---|
INVALID |
placeholder |
HTTP |
Http filter |
NETWORK |
Network filter |
Indicates the relative index in the filter chain where the filter should be inserted.
Index/position in the filter chain.
| Name | Description |
|---|---|
FIRST |
Insert first |
LAST |
Insert last |
BEFORE |
Insert before the named filter. |
AFTER |
Insert after the named filter. |
Select a listener to add the filter to based on the match conditions. All conditions specified in the ListenerMatch must be met for the filter to be applied to a listener.
| Name | Description |
|---|---|
ALL |
All protocols |
HTTP |
HTTP or HTTPS (with termination) / HTTP2/gRPC |
TCP |
Any non-HTTP listener |
| Name | Description |
|---|---|
ANY |
All listeners |
SIDECAR_INBOUND |
Inbound listener in sidecar |
SIDECAR_OUTBOUND |
Outbound listener in sidecar |
GATEWAY |
Gateway listener |
Gateway
describes a load balancer operating at the edge of the mesh
receiving incoming or outgoing HTTP/TCP connections. The specification
describes a set of ports that should be exposed, the type of protocol to
use, SNI configuration for the load balancer, etc.
For example, the following Gateway configuration sets up a proxy to act
as a load balancer exposing port 80 and 9080 (http), 443 (https), and
port 2379 (TCP) for ingress. The gateway will be applied to the proxy
running on a pod with labels app: my-gateway-controller
. While Istio
will configure the proxy to listen on these ports, it is the
responsibility of the user to ensure that external traffic to these
ports are allowed into the mesh.
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: my-gateway
namespace: some-config-namespace
spec:
selector:
app: my-gateway-controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- uk.bookinfo.com
- eu.bookinfo.com
tls:
httpsRedirect: true # sends 301 redirect for http requests
- port:
number: 443
name: https
protocol: HTTPS
hosts:
- uk.bookinfo.com
- eu.bookinfo.com
tls:
mode: SIMPLE #enables HTTPS on this port
serverCertificate: /etc/certs/servercert.pem
privateKey: /etc/certs/privatekey.pem
- port:
number: 9080
name: http-wildcard
protocol: HTTP
hosts:
- "*"
- port:
number: 2379 # to expose internal service via external port 2379
name: mongo
protocol: MONGO
hosts:
- "*"
The Gateway specification above describes the L4-L6 properties of a load
balancer. A VirtualService
can then be bound to a gateway to control
the forwarding of traffic arriving at a particular host or gateway port.
For example, the following VirtualService splits traffic for “https://uk.bookinfo.com/reviews”, “https://eu.bookinfo.com/reviews”, “http://uk.bookinfo.com:9080/reviews”, “http://eu.bookinfo.com:9080/reviews” into two versions (prod and qa) of an internal reviews service on port 9080. In addition, requests containing the cookie “user: dev-123” will be sent to special port 7777 in the qa version. The same rule is also applicable inside the mesh for requests to the “reviews.prod.svc.cluster.local” service. This rule is applicable across ports 443, 9080. Note that “http://uk.bookinfo.com” gets redirected to “https://uk.bookinfo.com” (i.e. 80 redirects to 443).
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: bookinfo-rule
namespace: bookinfo-namespace
spec:
hosts:
- reviews.prod.svc.cluster.local
- uk.bookinfo.com
- eu.bookinfo.com
gateways:
- some-config-namespace/my-gateway
- mesh # applies to all the sidecars in the mesh
http:
- match:
- headers:
cookie:
user: dev-123
route:
- destination:
port:
number: 7777
host: reviews.qa.svc.cluster.local
- match:
uri:
prefix: /reviews/
route:
- destination:
port:
number: 9080 # can be omitted if its the only port for reviews
host: reviews.prod.svc.cluster.local
weight: 80
- destination:
host: reviews.qa.svc.cluster.local
weight: 20
The following VirtualService forwards traffic arriving at (external)
port 27017 to internal Mongo server on port 5555. This rule is not
applicable internally in the mesh as the gateway list omits the
reserved name mesh
.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: bookinfo-Mongo
namespace: bookinfo-namespace
spec:
hosts:
- mongosvr.prod.svc.cluster.local #name of internal Mongo service
gateways:
- some-config-namespace/my-gateway # can omit the namespace if gateway is in same
namespace as virtual service.
tcp:
- match:
- port: 27017
route:
- destination:
host: mongo.prod.svc.cluster.local
port:
number: 5555
HTTPFaultInjection can be used to specify one or more faults to inject while forwarding http requests to the destination specified in a route. Fault specification is part of a VirtualService rule. Faults include aborting the Http request from downstream service, and/or delaying proxying of requests. A fault rule MUST HAVE delay or abort or both.
Note: Delay and abort faults are independent of one another, even if both are specified simultaneously.
Abort specification is used to prematurely abort a request with a pre-specified error code. The following example will return an HTTP 400 error code for 1 out of every 1000 requests to the “ratings” service “v1”.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- route:
- destination:
host: ratings.prod.svc.cluster.local
subset: v1
fault:
abort:
percentage:
value: 0.001
httpStatus: 400
The httpStatus field is used to indicate the HTTP status code to return to the caller. The optional percentage field can be used to only abort a certain percentage of requests. If not specified, all requests are aborted.
Delay specification is used to inject latency into the request forwarding path. The following example will introduce a 5 second delay in 1 out of every 1000 requests to the “v1” version of the “reviews” service from all pods with label env: prod
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews-route
spec:
hosts:
- reviews.prod.svc.cluster.local
http:
- match:
- sourceLabels:
env: prod
route:
- destination:
host: reviews.prod.svc.cluster.local
subset: v1
fault:
delay:
percentage:
value: 0.001
fixedDelay: 5s
The fixedDelay field is used to indicate the amount of delay in seconds. The optional percentage field can be used to only delay a certain percentage of requests. If left unspecified, all request will be delayed.
HttpMatchRequest specifies a set of criterion to be met in order for the
rule to be applied to the HTTP request. For example, the following
restricts the rule to match only requests where the URL path
starts with /ratings/v2/ and the request contains a custom end-user
header
with value jason
.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- match:
- headers:
end-user:
exact: jason
uri:
prefix: "/ratings/v2/"
route:
- destination:
host: ratings.prod.svc.cluster.local
HTTPMatchRequest CANNOT be empty.
HTTPRedirect can be used to send a 301 redirect response to the caller, where the Authority/Host and the URI in the response can be swapped with the specified values. For example, the following rule redirects requests for /v1/getProductRatings API on the ratings service to /v1/bookRatings provided by the bookratings service.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- match:
- uri:
exact: /v1/getProductRatings
redirect:
uri: /v1/bookRatings
authority: newratings.default.svc.cluster.local
...
Describes the retry policy to use when a HTTP request fails. For example, the following rule sets the maximum number of retries to 3 when calling ratings:v1 service, with a 2s timeout per retry attempt.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- route:
- destination:
host: ratings.prod.svc.cluster.local
subset: v1
retries:
attempts: 3
perTryTimeout: 2s
retryOn: gateway-error,connect-failure,refused-stream
HTTPRewrite can be used to rewrite specific parts of a HTTP request before forwarding the request to the destination. Rewrite primitive can be used only with HTTPRouteDestination. The following example demonstrates how to rewrite the URL prefix for api call (/ratings) to ratings service before making the actual API call.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings-route
spec:
hosts:
- ratings.prod.svc.cluster.local
http:
- match:
- uri:
prefix: /ratings
rewrite:
uri: /v1/bookRatings
route:
- destination:
host: ratings.prod.svc.cluster.local
subset: v1
Describes match conditions and actions for routing HTTP/1.1, HTTP2, and gRPC traffic. See VirtualService for usage examples.
Each routing rule is associated with one or more service versions (see glossary in beginning of document). Weights associated with the version determine the proportion of traffic it receives. For example, the following rule will route 25% of traffic for the “reviews” service to instances with the “v2” tag and the remaining traffic (i.e., 75%) to “v1”.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews-route
spec:
hosts:
- reviews.prod.svc.cluster.local
http:
- route:
- destination:
host: reviews.prod.svc.cluster.local
subset: v2
weight: 25
- destination:
host: reviews.prod.svc.cluster.local
subset: v1
weight: 75
And the associated DestinationRule
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews-destination
spec:
host: reviews.prod.svc.cluster.local
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
Traffic can also be split across two entirely different services without having to define new subsets. For example, the following rule forwards 25% of traffic to reviews.com to dev.reviews.com
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews-route-two-domains
spec:
hosts:
- reviews.com
http:
- route:
- destination:
host: dev.reviews.com
weight: 25
- destination:
host: reviews.com
weight: 75
Header manipulation rules
HeaderOperations Describes the header manipulations to apply
IstioEgressListener specifies the properties of an outbound traffic listener on the sidecar proxy attached to a workload.
IstioIngressListener specifies the properties of an inbound traffic listener on the sidecar proxy attached to a workload.
L4 connection match attributes. Note that L4 connection matching support is incomplete.
Load balancing policies to apply for a specific destination. See Envoy’s load balancing documentation for more details.
For example, the following rule uses a round robin load balancing policy for all traffic going to the ratings service.
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: bookinfo-ratings
spec:
host: ratings.prod.svc.cluster.local
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
The following example sets up sticky sessions for the ratings service hashing-based load balancer for the same ratings service using the the User cookie as the hash key.
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: bookinfo-ratings
spec:
host: ratings.prod.svc.cluster.local
trafficPolicy:
loadBalancer:
consistentHash:
httpCookie:
name: user
ttl: 0s
Consistent Hash-based load balancing can be used to provide soft session affinity based on HTTP headers, cookies or other properties. This load balancing policy is applicable only for HTTP connections. The affinity to a particular destination host will be lost when one or more hosts are added/removed from the destination service.
Describes a HTTP cookie that will be used as the hash key for the Consistent Hash load balancer. If the cookie is not present, it will be generated.
Standard load balancing algorithms that require no tuning.
| Name | Description |
|---|---|
ROUND_ROBIN |
Round Robin policy. Default |
LEAST_CONN |
The least request load balancer uses an O(1) algorithm which selects two random healthy hosts and picks the host which has fewer active requests. |
RANDOM |
The random load balancer selects a random healthy host. The random load balancer generally performs better than round robin if no health checking policy is configured. |
PASSTHROUGH |
This option will forward the connection to the original IP address requested by the caller without doing any form of load balancing. This option must be used with care. It is meant for advanced use cases. Refer to Original Destination load balancer in Envoy for further details. |
A Circuit breaker implementation that tracks the status of each individual host in the upstream service. Applicable to both HTTP and TCP services. For HTTP services, hosts that continually return 5xx errors for API calls are ejected from the pool for a pre-defined period of time. For TCP services, connection timeouts or connection failures to a given host counts as an error when measuring the consecutive errors metric. See Envoy’s outlier detection for more details.
The following rule sets a connection pool size of 100 connections and 1000 concurrent HTTP2 requests, with no more than 10 req/connection to “reviews” service. In addition, it configures upstream hosts to be scanned every 5 mins, such that any host that fails 7 consecutive times with 5XX error code will be ejected for 15 minutes.
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews-cb-policy
spec:
host: reviews.prod.svc.cluster.local
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
http:
http2MaxRequests: 1000
maxRequestsPerConnection: 10
outlierDetection:
consecutiveErrors: 7
interval: 5m
baseEjectionTime: 15m
Percent specifies a percentage in the range of [0.0, 100.0].
Port describes the properties of a specific port of a service.
PortSelector specifies the number of a port to be used for matching or selection for final routing.
L4 routing rule weighted destination.
Server
describes the properties of the proxy on a given load balancer
port. For example,
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: my-ingress
spec:
selector:
app: my-ingress-gateway
servers:
- port:
number: 80
name: http2
protocol: HTTP2
hosts:
- "*"
Another example
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: my-tcp-ingress
spec:
selector:
app: my-tcp-ingress-gateway
servers:
- port:
number: 27018
name: mongo
protocol: MONGO
hosts:
- "*"
The following is an example of TLS configuration for port 443
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: my-tls-ingress
spec:
selector:
app: my-tls-ingress-gateway
servers:
- port:
number: 443
name: https
protocol: HTTPS
hosts:
- "*"
tls:
mode: SIMPLE
serverCertificate: /etc/certs/server.pem
privateKey: /etc/certs/privatekey.pem
TLS protocol versions.
| Name | Description |
|---|---|
TLS_AUTO |
Automatically choose the optimal TLS version. |
TLSV1_0 |
TLS version 1.0 |
TLSV1_1 |
TLS version 1.1 |
TLSV1_2 |
TLS version 1.2 |
TLSV1_3 |
TLS version 1.3 |
TLS modes enforced by the proxy
| Name | Description |
|---|---|
PASSTHROUGH |
The SNI string presented by the client will be used as the match criterion in a VirtualService TLS route to determine the destination service from the service registry. |
SIMPLE |
Secure connections with standard TLS semantics. |
MUTUAL |
Secure connections to the upstream using mutual TLS by presenting client certificates for authentication. |
AUTO_PASSTHROUGH |
Similar to the passthrough mode, except servers with this TLS mode do not require an associated VirtualService to map from the SNI value to service in the registry. The destination details such as the service/subset/port are encoded in the SNI value. The proxy will forward to the upstream (Envoy) cluster (a group of endpoints) specified by the SNI value. This server is typically used to provide connectivity between services in disparate L3 networks that otherwise do not have direct connectivity between their respective endpoints. Use of this mode assumes that both the source and the destination are using Istio mTLS to secure traffic. |
ServiceEntry
enables adding additional entries into Istio’s internal
service registry, so that auto-discovered services in the mesh can
access/route to these manually specified services. A service entry
describes the properties of a service (DNS name, VIPs, ports, protocols,
endpoints). These services could be external to the mesh (e.g., web
APIs) or mesh-internal services that are not part of the platform’s
service registry (e.g., a set of VMs talking to services in Kubernetes).
The following configuration adds a set of MongoDB instances running on unmanaged VMs to Istio’s registry, so that these services can be treated as any other service in the mesh. The associated DestinationRule is used to initiate mTLS connections to the database instances.
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-svc-mongocluster
spec:
hosts:
- mymongodb.somedomain # not used
addresses:
- <IP_ADDRESS>/24 # VIPs
ports:
- number: 27018
name: mongodb
protocol: MONGO
location: MESH_INTERNAL
resolution: STATIC
endpoints:
- address: <IP_ADDRESS>
- address: <IP_ADDRESS>
and the associated DestinationRule
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: mtls-mongocluster
spec:
host: mymongodb.somedomain
trafficPolicy:
tls:
mode: MUTUAL
clientCertificate: /etc/certs/myclientcert.pem
privateKey: /etc/certs/client_private_key.pem
caCertificates: /etc/certs/rootcacerts.pem
The following example uses a combination of service entry and TLS routing in virtual service to demonstrate the use of SNI routing to forward unterminated TLS traffic from the application to external services via the sidecar. The sidecar inspects the SNI value in the ClientHello message to route to the appropriate external service.
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-svc-https
spec:
hosts:
- api.dropboxapi.com
- www.googleapis.com
- api.facebook.com
location: MESH_EXTERNAL
ports:
- number: 443
name: https
protocol: TLS
resolution: DNS
And the associated VirtualService to route based on the SNI value.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: tls-routing
spec:
hosts:
- api.dropboxapi.com
- www.googleapis.com
- api.facebook.com
tls:
- match:
- port: 443
sniHosts:
- api.dropboxapi.com
route:
- destination:
host: api.dropboxapi.com
- match:
- port: 443
sniHosts:
- www.googleapis.com
route:
- destination:
host: www.googleapis.com
- match:
- port: 443
sniHosts:
- api.facebook.com
route:
- destination:
host: api.facebook.com
The following example demonstrates the use of a dedicated egress gateway through which all external service traffic is forwarded. The ‘exportTo’ field allows for control over the visibility of a service declaration to other namespaces in the mesh. By default a service is exported to all namespaces. The following example restricts the visibility to the current namespace, represented by “.”, so that it cannot be used by other namespaces.
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-svc-httpbin
namespace : egress
spec:
hosts:
- httpbin.com
exportTo:
- "."
location: MESH_EXTERNAL
ports:
- number: 80
name: http
protocol: HTTP
resolution: DNS
Define a gateway to handle all egress traffic.
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: istio-egressgateway
namespace: egress
spec:
selector:
istio: egressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
And the associated VirtualService to route from the sidecar to the gateway service (istio-egressgateway.istio-system.svc.cluster.local), as well as route from the gateway to the external service. Note that the virtual service is exported to all namespaces enabling them to route traffic through the gateway to the external service. Forcing traffic to go through a managed middle proxy like this is a common practice.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: gateway-routing
namespace: egress
spec:
hosts:
- httpbin.com
exportTo:
- *
gateways:
- mesh
- istio-egressgateway
http:
- match:
- port: 80
gateways:
- mesh
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
- match:
- port: 80
gateway:
- istio-egressgateway
route:
- destination:
host: httpbin.com
The following example demonstrates the use of wildcards in the hosts for
external services. If the connection has to be routed to the IP address
requested by the application (i.e. application resolves DNS and attempts
to connect to a specific IP), the discovery mode must be set to NONE
.
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-svc-wildcard-example
spec:
hosts:
- "*.bar.com"
location: MESH_EXTERNAL
ports:
- number: 80
name: http
protocol: HTTP
resolution: NONE
The following example demonstrates a service that is available via a Unix Domain Socket on the host of the client. The resolution must be set to STATIC to use unix address endpoints.
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: unix-domain-socket-example
spec:
hosts:
- "example.unix.local"
location: MESH_EXTERNAL
ports:
- number: 80
name: http
protocol: HTTP
resolution: STATIC
endpoints:
- address: unix:///var/run/example/socket
For HTTP-based services, it is possible to create a VirtualService backed by multiple DNS addressable endpoints. In such a scenario, the application can use the HTTP_PROXY environment variable to transparently reroute API calls for the VirtualService to a chosen backend. For example, the following configuration creates a non-existent external service called foo.bar.com backed by three domains: us.foo.bar.com:8080, uk.foo.bar.com:9080, and in.foo.bar.com:7080
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-svc-dns
spec:
hosts:
- foo.bar.com
location: MESH_EXTERNAL
ports:
- number: 80
name: http
protocol: HTTP
resolution: DNS
endpoints:
- address: us.foo.bar.com
ports:
https: 8080
- address: uk.foo.bar.com
ports:
https: 9080
- address: in.foo.bar.com
ports:
https: 7080
With HTTP_PROXY=http://localhost/
, calls from the application to
http://foo.bar.com
will be load balanced across the three domains
specified above. In other words, a call to http://foo.bar.com/baz
would
be translated to http://uk.foo.bar.com/baz
.
The following example illustrates the usage of a ServiceEntry containing a subject alternate name whose format conforms to the SPIFEE standard https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md:
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: httpbin
namespace : httpbin-ns
spec:
hosts:
- httpbin.com
location: MESH_INTERNAL
ports:
- number: 80
name: http
protocol: HTTP
resolution: STATIC
endpoints:
- address: <IP_ADDRESS>
- address: <IP_ADDRESS>
subjectAltNames:
- "spiffe://cluster.local/ns/httpbin-ns/sa/httpbin-service-account"
Endpoint defines a network address (IP or hostname) associated with the mesh service.
Location specifies whether the service is part of Istio mesh or outside the mesh. Location determines the behavior of several features, such as service-to-service mTLS authentication, policy enforcement, etc. When communicating with services outside the mesh, Istio’s mTLS authentication is disabled, and policy enforcement is performed on the client-side as opposed to server-side.
| Name | Description |
|---|---|
MESH_EXTERNAL |
Signifies that the service is external to the mesh. Typically used to indicate external services consumed through APIs. |
MESH_INTERNAL |
Signifies that the service is part of the mesh. Typically used to indicate services added explicitly as part of expanding the service mesh to include unmanaged infrastructure (e.g., VMs added to a Kubernetes based service mesh). |
Resolution determines how the proxy will resolve the IP addresses of the network endpoints associated with the service, so that it can route to one of them. The resolution mode specified here has no impact on how the application resolves the IP address associated with the service. The application may still have to use DNS to resolve the service to an IP so that the outbound traffic can be captured by the Proxy. Alternatively, for HTTP services, the application could directly communicate with the proxy (e.g., by setting HTTP_PROXY) to talk to these services.
| Name | Description |
|---|---|
NONE |
Assume that incoming connections have already been resolved (to a specific destination IP address). Such connections are typically routed via the proxy using mechanisms such as IP table REDIRECT/ eBPF. After performing any routing related transformations, the proxy will forward the connection to the IP address to which the connection was bound. |
STATIC |
Use the static IP addresses specified in endpoints (see below) as the backing instances associated with the service. |
DNS |
Attempt to resolve the IP address by querying the ambient DNS, during request processing. If no endpoints are specified, the proxy will resolve the DNS address specified in the hosts field, if wildcards are not used. If endpoints are specified, the DNS addresses specified in the endpoints will be resolved to determine the destination IP address. DNS resolution cannot be used with unix domain socket endpoints. |
Sidecar
describes the configuration of the sidecar proxy that mediates
inbound and outbound communication to the workload it is attached to. By
default, Istio will program all sidecar proxies in the mesh with the
necessary configuration required to reach every workload in the mesh, as
well as accept traffic on all the ports associated with the
workload. The Sidecar resource provides a way to fine tune the set of
ports, protocols that the proxy will accept when forwarding traffic to
and from the workload. In addition, it is possible to restrict the set
of services that the proxy can reach when forwarding outbound traffic
from the workload.
Services and configuration in a mesh are organized into one or more namespaces (e.g., a Kubernetes namespace or a CF org/space). A Sidecar resource in a namespace will apply to one or more workloads in the same namespace, selected using the workloadSelector. In the absence of a workloadSelector, it will apply to all workloads in the same namespace. When determining the Sidecar resource to be applied to a workload, preference will be given to the resource with a workloadSelector that selects this workload, over a Sidecar resource without any workloadSelector.
NOTE: Each namespace can have only one Sidecar resource without any workload selector. The behavior of the system is undefined if more than one selector-less Sidecar resources exist in a given namespace. The behavior of the system is undefined if two or more Sidecar resources with a workload selector select the same workload.
The example below declares a Sidecar resource in the prod-us1 namespace that configures the sidecars in the namespace to allow egress traffic to public services in the prod-us1, prod-apis, and the istio-system namespaces.
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: default
namespace: prod-us1
spec:
egress:
- hosts:
- "prod-us1/*"
- "prod-apis/*"
- "istio-system/*"
The example below declares a Sidecar resource in the prod-us1 namespace that accepts inbound HTTP traffic on port 9080 and forwards it to the attached workload listening on a unix domain socket. In the egress direction, in addition to the istio-system namespace, the sidecar proxies only HTTP traffic bound for port 9080 for services in the prod-us1 namespace.
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: default
namespace: prod-us1
spec:
ingress:
- port:
number: 9080
protocol: HTTP
name: somename
defaultEndpoint: unix:///var/run/someuds.sock
egress:
- hosts:
- "istio-system/*"
- port:
number: 9080
protocol: HTTP
name: egresshttp
hosts:
- "prod-us1/*"
Describes how to match a given string in HTTP headers. Match is case-sensitive.
A subset of endpoints of a service. Subsets can be used for scenarios like A/B testing, or routing to a specific version of a service. Refer to VirtualService documentation for examples of using subsets in these scenarios. In addition, traffic policies defined at the service-level can be overridden at a subset-level. The following rule uses a round robin load balancing policy for all traffic going to a subset named testversion that is composed of endpoints (e.g., pods) with labels (version:v3).
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: bookinfo-ratings
spec:
host: ratings.prod.svc.cluster.local
trafficPolicy:
loadBalancer:
simple: LEAST_CONN
subsets:
- name: testversion
labels:
version: v3
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
Note: Policies specified for subsets will not take effect until a route rule explicitly sends traffic to this subset.
One or more labels are typically required to identify the subset destination, however, when the corresponding DestinationRule represents a host that supports multiple SNI hosts (e.g., an egress gateway), a subset without labels may be meaningful. In this case a traffic policy with TLSSettings can be used to identify a specific SNI host corresponding to the named subset.
Describes match conditions and actions for routing TCP traffic. The following routing rule forwards traffic arriving at port 27017 for mongo.prod.svc.cluster.local to another Mongo server on port 5555.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: bookinfo-Mongo
spec:
hosts:
- mongo.prod.svc.cluster.local
tcp:
- match:
- port: 27017
route:
- destination:
host: mongo.backup.svc.cluster.local
port:
number: 5555
TLS connection match attributes.
Describes match conditions and actions for routing unterminated TLS traffic (TLS/HTTPS) The following routing rule forwards unterminated TLS traffic arriving at port 443 of gateway called “mygateway” to internal services in the mesh based on the SNI value.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: bookinfo-sni
spec:
hosts:
- "*.bookinfo.com"
gateways:
- mygateway
tls:
- match:
- port: 443
sniHosts:
- login.bookinfo.com
route:
- destination:
host: login.prod.svc.cluster.local
- match:
- port: 443
sniHosts:
- reviews.bookinfo.com
route:
- destination:
host: reviews.prod.svc.cluster.local
SSL/TLS related settings for upstream connections. See Envoy’s TLS context for more details. These settings are common to both HTTP and TCP upstreams.
For example, the following rule configures a client to use mutual TLS for connections to upstream database cluster.
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: db-mtls
spec:
host: mydbserver.prod.svc.cluster.local
trafficPolicy:
tls:
mode: MUTUAL
clientCertificate: /etc/certs/myclientcert.pem
privateKey: /etc/certs/client_private_key.pem
caCertificates: /etc/certs/rootcacerts.pem
The following rule configures a client to use TLS when talking to a foreign service whose domain matches *.foo.com.
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: tls-foo
spec:
host: "*.foo.com"
trafficPolicy:
tls:
mode: SIMPLE
The following rule configures a client to use Istio mutual TLS when talking to rating services.
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: ratings-istio-mtls
spec:
host: ratings.prod.svc.cluster.local
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
TLS connection mode
| Name | Description |
|---|---|
DISABLE |
Do not setup a TLS connection to the upstream endpoint. |
SIMPLE |
Originate a TLS connection to the upstream endpoint. |
MUTUAL |
Secure connections to the upstream using mutual TLS by presenting client certificates for authentication. |
ISTIO_MUTUAL |
Secure connections to the upstream using mutual TLS by presenting
client certificates for authentication.
Compared to Mutual mode, this mode uses certificates generated
automatically by Istio for mTLS authentication. When this mode is
used, all other fields in |
Traffic policies to apply for a specific destination, across all destination ports. See DestinationRule for examples.
Traffic policies that apply to specific ports of the service
A VirtualService
defines a set of traffic routing rules to apply when a host is
addressed. Each routing rule defines matching criteria for traffic of a specific
protocol. If the traffic is matched, then it is sent to a named destination service
(or subset/version of it) defined in the registry.
The source of traffic can also be matched in a routing rule. This allows routing to be customized for specific client contexts.
The following example on Kubernetes, routes all HTTP traffic by default to pods of the reviews service with label “version: v1”. In addition, HTTP requests with path starting with /wpcatalog/ or /consumercatalog/ will be rewritten to /newcatalog and sent to pods with label “version: v2”.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews-route
spec:
hosts:
- reviews.prod.svc.cluster.local
http:
- match:
- uri:
prefix: "/wpcatalog"
- uri:
prefix: "/consumercatalog"
rewrite:
uri: "/newcatalog"
route:
- destination:
host: reviews.prod.svc.cluster.local
subset: v2
- route:
- destination:
host: reviews.prod.svc.cluster.local
subset: v1
A subset/version of a route destination is identified with a reference
to a named service subset which must be declared in a corresponding
DestinationRule
.
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews-destination
spec:
host: reviews.prod.svc.cluster.local
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
WorkloadSelector specifies the criteria used to determine if the Gateway or Sidecar resource can be applied to a proxy. The matching criteria includes the metadata associated with a proxy, workload info such as labels attached to the pod/VM, or any other info that the proxy provides to Istio during the initial handshake. If multiple conditions are specified, all conditions need to match in order for the workload to be selected. Currently, only label based selection mechanism is supported.


{% extends "base/base.html" %} {% block title %}Invalid Password Reset Mail{% endblock %} {% block body %}
The link is either invalid or expired. Note that you have to reset your password within 24hours from the time the mail was sent.
To receive another password reset email, click here.
{% endblock %}


| Title |
Author |
Date |
| Software Development Magazine |
|
|
| Design Patterns |
Gamma, Helm, Johnson, Vlissides |
(1995) |
| Refactorings |
Martin Fowler |
(1999) |
| Refactoring to Patterns |
Joshua Kerievsky |
(2004) |
| eXtreme Programming Explained |
Kent Beck |
(1999) |
| eXtreme Programming Explained, second edition |
Kent Beck |
(2004) |
| Agile Software Development, second edition |
Alistair Cockburn |
(2006) |
| Agile Software Development: Principles, Patterns, and Practices |
Robert C. Martin |
(2003) |
| Object-Oriented Software Construction |
Bertrand Meyer |
(2000) |
| ... I haven't read these yet, but they look promising ... |
| Test-Driven Development: By Example |
Kent Beck |
(2002) |
| Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions |
Gregor Hohpe, Bobby Woolf |
(2003) |


Jimi Hendrix
The iconic and revolutionary guitar player
- 1942 - Born in Seattle, Washington.
- 1957 - Began to play guitar at the age of 15.
- 1961 - Enlisted in the US Army and was assigned to the 101st Airborne Division.
- 1962 - Granted an honorable discharge from the Army after injuring himself in a paratrooper excersize.
- 1966 - Moves to England after playing with the likes of Little Richard and the Isley Brothers.
- 1967 - Achieves fame in the US after setting his guitar ablaze at the Monterrey Pop Festival.
- 1968 - The Jimi Hendrix Experience records their third studio album, Electric Ladylyand.
- 1969 - Hendrix headlines the Woodstok festival and performs a unique rendition of the Star Spangled Banner along with other hits.
- August 1970 - Hendrix headlines the Isle of Wight festival
- September 1970 - Hendrix is found, unresponsive, and dies of barbiturate-related asphyxia.
The Life of a Legend:
"Despite his relatively short career, he remains an influence on guitarists everywhere—a psychedelic rock pioneer whose work and approach touches all styles of music. "
-- Rock & Roll Hall of Fame


Canada: Retail sales to remain subdued – TDS
by Sandeep KanihamaResearch team of TD Securities is looking for the Canada’s retail sales to remain subdued with a 0.3% decline in September as softer motor vehicles sales add to a more subdued 0.1% decline in the ex-autos measure.
Key Quotes
“On a brighter note, the pickup in consumer goods imports does suggest some upside for clothing and other textiles, and the continued recovery in the housing market should support retail sales of furniture and home furnishings.”
“Real retail sales should come in below the headline print, providing a poor handoff to Q4 consumption; even though September CPI fell by 0.4% m/m, weakness was concentrated in services, and consumer goods prices rose by 0.2% m/m.”


Click on image to have a closer look.
Life is like a cactus,
prickly but very beautiful.
You can't buy happiness,
but you can buy succulents!
And that is pretty much the same thing.
If you get struck by a cactus, consider it a cactus kiss. Because we all know Love hurts.
Reach for the stars, even if you have to stand on a cactus.
Loving someone who doesn't love you back is like hugging a cactus. The tighter you hold on, the more it's going to hurt.
If you where a cactus, I'd endure all the pain just to hug you!
Gardening requires lots of water - most of it in the form of perspiration.
Did you know? All gardeners live in the most beautiful places because they make them so!
Be sharp like a cactus, people are afraid to touch and not a sort of rubbish.
No rose on thorned stem Pricks my heart as does the cactus Flowered in spring or gaunt in December. I remember.
People trample over flowers, yet only to embrace a cactus.
Adolescence is like cactus…


Marktplus - Engineering WordPress Theme
There are many variations of passages of Lorem Ipsum available, but the majority have suffered alteration in some form, by injected humour, or randomised words which don't look even slightly believable. If you are going to use a passage of Lorem Ipsum, you need to be sure there isn't anything embarrassing hidde.
But the majority have suffered alteration in some form, by injected humour, or domised words which don't look even slightly believable. If you are going to use a passage Lorem Ipsum, you need sure there isn't anything.
Features Marktplus
Alteration in some form, by injected humour, or domised words which.
- Full WooCommerce integration
- Compatible Browsers – IE9+, Chrome, Safari, Opera, Firefox
- All settings defined via customization API
- Files Included – php, html, JS, css
- Compatible with – Elementor
Majority have suffered alteration in some form, by injected humour, or domised words which don't look even slightly by injected humour, or domised have suffered alteration in some believable njected humour.
Sources and Credits:
A full list of all the sources and services we use to build :
- FontAwesome
- Parallax
- Owl carosel
- Free Image Used
- Google Font Use
Please Note : All images are only for demo preview and NOT included in purchase files.


Part 4 Power and Sample Size
The F-statistic we obtained from our insectSprays
example was so large that we assumed it was a statistically significant result. Of course in practice we would conduct a formal hypothesis test and invoke a null F-distribution to test statistical significance. For our effects model we put together for insectSprays
we would pose the following null and alternative hypotheses:
- \(H_{0}\): The type of spray has no effect on insect count in the population of all insect plots.
- \(H_{a}\): The type of spray has an effect on insect count in the population of all insect plots.
We can plot the null F(5, 66) distribution in R:
insects_F <- ggplot(data.frame(x = c(0, 35)), aes(x = x)) +
stat_function(fun = df, geom = "area", fill = "steelblue",
args = list(df1 = 5, df2 = 66), alpha = 0.6) +
theme_classic() +
xlab("F") +
ylab("Density") +
stat_function(fun = df, args = list(df1 = 5, df2 = 66),
geom = "area",
fill = "steelblue",
xlim = c(qf(p = 0.99, df1 = 5, df2 = 66), 35)
) +
geom_vline(xintercept = qf(p = 0.99, df1 = 5, df2 = 66), color = "red") +
geom_vline(xintercept = 34.7, linetype = "dashed")
F(5, 66) = 34.7 with p-value <0.0001
I’d say we were pretty safe to assume what what we did in Part 3 (essentially we rejected the null hypothesis posed above) just from glancing at the size of our computed F-statistic.
Our insectSprays
example lended itself pretty darn well to getting a statistically significant F-statistic. A worthwhile question to ask if we were setting up our own experimental design outside of this example would be:
How can we design our experiment to increase our chances of getting a statistically significant F-statistic?
4.1 Power
The answer to the above question can be answered by thinking about power. Power is the probability that we reject our null hypothesis when in fact the null hypothesis is actually false (Oehlert 2010). To make sense of this recall the Type I error and Type II error rates from introductory statistics:
- Type I Error Rate: Probability that we reject our null hypothesis when it is in fact the null is true
- Type II Error Rate: Probabilility that we fail to reject the null hypothesis when in fact the null is false
Power represents the probability of the “correct” decision between these two errors rates. To determine power in the context of 1-way ANOVA we can plot both the central (null) and non-central F-distributions. The central F-distribution (an example is 4.1) shows the distribution of F-statistics when our null hypothesis is actually true. On the other hand, the non-central F-distribution shows the distribution of F-statistics when the the null hypothesis is actually false. The shape of the non-central F-distribution is dictated by a non-centrality parameter, viz.,
\[NCP = \frac{\sum n_{i}\tau_{i}^2}{\sigma^2}\]
We can estimate \(\tau_{i}^2\) as the effect of the \(ith\) treatment group, \(n_{i}\) as the sample size (replicates) per treatment group, and \(\sigma^2\) as mean square error (MSE). To illustrate how the central and non-central F-distributions are used to determine power, let us look at a situation where we modify our beloved insectSprays
example.
Suppose we wanted to determine power for an ANOVA F-test for a new insecticide study we were planning with the following assumptions:
- Our level of significance is \(\alpha = 0.05\)
- We will have three treatment groups (3 sprays) with 10 insect plots per treatment
- Our MSE will be 2 insects
- We assume the true mean change in insect count for the treatments will be \(\mu_{1} = 4\), \(\mu_{2} = 5\), and \(\mu_{3} = 6\)
We plot our central and non-central F-distributions to calculate power for the ANOVA F-test (\(H_{0}\): \(\mu_{1}\) = \(\mu_{2}\) = \(\mu_{3}\)). To plot the latter distribution we need to compute our non-centrality parameter:
group_means <- c(4, 5, 6)
grand_mean <- mean(group_means)
ncp_1 <- 10 * ((group_means[1] - grand_mean)^2 + (group_means[2] - grand_mean)^2 + (group_means[3] - grand_mean)^2)/2
ncp_1
## [1] 10
Plotting our distributions:
example_power_fdists <- ggplot(data.frame(x = c(0, 15)), aes(x = x)) +
# Null F-distribution F(2, 27, 0)
stat_function(fun = df, geom = "area", fill = "steelblue",
args = list(df1 = 2, df2 = 27, ncp = 0), alpha = 0.8) +
# Non-central F-distribution F (2, 27, 10)
stat_function(fun = df, geom = "area", fill = "yellow",
args = list(df1 = 2, df2 = 27, ncp = ncp_1), alpha = 0.5) +
# Power
stat_function(fun = df, args = list(df1 = 2, df2 = 27, ncp = ncp_1),
geom = "area", fill = "green", alpha = 0.5,
xlim = c(qf(p = pf(qf(0.95, 2, 27), 2, 27, ncp = ncp_1, lower.tail = F),
df1 = 2, df2 = 27, ncp = ncp_1, lower.tail = FALSE), 20)) +
# F-critical value (alpha = 0.05)
geom_vline(xintercept = qf(p = 0.95, df1 = 2, df2 = 27), color = "red", linetype = "dashed") +
theme_classic() +
ylab("Density") +
xlab("F")
Our power is the green shaded area, the density of upper tail of the non-central F (2, 27, 10) past the critical F-statistic corresponding to our chosen level of significance. We can calculate this formally in R:
## [1] 0.7673536
4.2 Playing with Sample Size
The non-centrality parameter is ultimately what controls the power of our statistical test. The larger the non-centrality parameter, the larger the power. We can deduce from the non-centrality parameter formula that we can change it by:
- Changing the sample size in our experimental design
- Changing our treatment group effect sizes
- Changing our MSE (within treatment group variance)
In practice, changing sample size is probably the easiest way to tweak power. The below animation illustrates how the non-centrality parameter and power change with different sample sizes if we keep everything else the same as specified in our above example for calculating power.
The graphic adds respective F-distributions and probabilites in order of increasing sample size. The first set of layers correspond to a sample size of 5 replicates per treatment (15 total plots), the next set correspond to 10 per treatment (30 total plots), and the last set correspond to 15 per treatment (45 total plots). Pay attention to the green shaded areas in the graphic, this represents the power in each of our three scenarios with different sample size. The yellow shaded area (non-central F-distribution) widens with increasing sample size leading to higher power!
References
Oehlert, Gary W. 2010. A First Course in Design and Analysis of Experiments.


# File lib/appointme/schedule.rb, line 17 def show(what) show_appointments = Appointme.get_range_of_time_to_show(what) select do |appointment| show_appointments.include? appointment.when end.sort_by do |appointment| appointment.when end rescue puts "errrr: #{$!}", $@ end


We stay on top of the current trend and always stay ahead of modern design implement
Apps are fully Customizable to your needs and Our Talented Developer will be with you in every step of the way
We provide 24/7 support with our Amazing Customer Service Team
5 Projects
20 Images
3 Design Template
10 Projects
30 Images
5 Design Template
Unlimited Projects
Unlimited Images
Unlimited Design Template


§103D-1001.5 Application of this part. The preferences in this part shall apply, when applicable, to procurements made pursuant to section 103D-302, or 103D‑303, or both. [L 1997, c 352, pt of §2; am L 1999, c 149, §18]


{% extends "layout.html" %} {% block content %} {% if error %} Error Could not find user with email/password. Please try again {% endif %} Email Password Sign In {% endblock %}
Error
Could not find user with email/password. Please try again


Construct a new grid layout.
The options for initializing the layout.
Get the number of columns in the layout.
The minimum column count is 1
.
Set the number of columns in the layout.
The minimum column count is 1
.
Get the column spacing for the layout.
Set the col spacing for the layout.
Get the fit policy for the layout.
The fit policy controls the computed size constraints which are applied to the parent widget by the layout.
Some layout implementations may ignore the fit policy.
Set the fit policy for the layout.
The fit policy controls the computed size constraints which are applied to the parent widget by the layout.
Some layout implementations may ignore the fit policy.
Changing the fit policy will clear the current size constraint for the parent widget and then re-fit the parent.
Test whether the layout is disposed.
Get the parent widget of the layout.
This is set automatically when installing the layout on the parent widget. The parent widget should not be set directly by user code.
Set the parent widget of the layout.
This is set automatically when installing the layout on the parent widget. The parent widget should not be set directly by user code.
Get the number of rows in the layout.
The minimum row count is 1
.
Set the number of rows in the layout.
The minimum row count is 1
.
Get the row spacing for the layout.
Set the row spacing for the layout.
Fit the layout to the total size required by the widgets.
Update the layout position and size of the widgets.
The parent offset dimensions should be -1
if unknown.
Add a widget to the grid layout.
The widget to add to the layout.
If the widget is already contained in the layout, this is no-op.
Attach a widget to the parent's DOM node.
The widget to attach to the parent.
Get the stretch factor for a specific column.
The column index of interest.
The stretch factor for the column.
This returns -1
if the index is out of range.
Detach a widget from the parent's DOM node.
The widget to detach from the parent.
Dispose of the resources held by the layout.
Perform layout initialization which requires the parent widget.
Create an iterator over the widgets in the layout.
A new iterator over the widgets in the layout.
A message handler invoked on an 'after-attach'
message.
The default implementation of this method forwards the message to all widgets. It assumes all widget nodes are attached to the parent widget node.
This may be reimplemented by subclasses as needed.
A message handler invoked on an 'after-detach'
message.
The default implementation of this method forwards the message to all widgets. It assumes all widget nodes are attached to the parent widget node.
This may be reimplemented by subclasses as needed.
A message handler invoked on an 'after-hide'
message.
The default implementation of this method forwards the message to all non-hidden widgets. It assumes all widget nodes are attached to the parent widget node.
This may be reimplemented by subclasses as needed.
A message handler invoked on an 'after-show'
message.
The default implementation of this method forwards the message to all non-hidden widgets. It assumes all widget nodes are attached to the parent widget node.
This may be reimplemented by subclasses as needed.
A message handler invoked on a 'before-attach'
message.
A message handler invoked on a 'before-detach'
message.
The default implementation of this method forwards the message to all widgets. It assumes all widget nodes are attached to the parent widget node.
This may be reimplemented by subclasses as needed.
A message handler invoked on a 'before-hide'
message.
The default implementation of this method forwards the message to all non-hidden widgets. It assumes all widget nodes are attached to the parent widget node.
This may be reimplemented by subclasses as needed.
A message handler invoked on a 'before-show'
message.
A message handler invoked on a 'child-hidden'
message.
A message handler invoked on a 'child-removed'
message.
This will remove the child widget from the layout.
Subclasses should not typically reimplement this method.
A message handler invoked on a 'child-shown'
message.
A message handler invoked on a 'fit-request'
message.
A message handler invoked on a 'resize'
message.
A message handler invoked on an 'update-request'
message.
Process a message sent to the parent widget.
The message sent to the parent widget.
This method is called by the parent widget to process a message.
Subclasses may reimplement this method as needed.
Remove a widget from the grid layout.
The widget to remove from the layout.
A widget is automatically removed from the layout when its parent
is set to null
. This method should only be invoked directly when
removing a widget from a layout which has yet to be installed on a
parent widget.
This method does not modify the widget's parent
.
Get the stretch factor for a specific row.
The row index of interest.
The stretch factor for the row.
This returns -1
if the index is out of range.
Set the stretch factor for a specific column.
The column index of interest.
The stretch factor for the column.
This is a no-op if the index is out of range.
Set the stretch factor for a specific row.
The row index of interest.
The stretch factor for the row.
This is a no-op if the index is out of range.
Get the cell config for the given widget.
The widget of interest.
The cell config for the widget.
Set the cell config for the given widget.
The widget of interest.
The value for the cell config.
Generated using TypeDoc
A layout which arranges its widgets in a grid. The namespace for the
GridLayout
class statics.


Next: Applying method combination to the sorted list of applicable methods, Previous: Selecting the Applicable Methods, Up: Method Selection and Combination
To compare the precedence of two methods, their parameter specializers are examined in order. The default examination order is from left to right, but an alternative order may be specified by the :argument-precedence-order option to defgeneric or to any of the other operators that specify generic function options.
The corresponding parameter specializers from each method are compared. When a pair of parameter specializers agree, the next pair are compared for agreement. If all corresponding parameter specializers agree, the two methods must have different qualifiers; in this case, either method can be selected to precede the other. For information about agreement, see Agreement on Parameter Specializers and Qualifiers.
If some corresponding parameter specializers do not agree, the first pair of parameter specializers that do not agree determines the precedence. If both parameter specializers are classes, the more specific of the two methods is the method whose parameter specializer appears earlier in the class precedence list of the corresponding argument. Because of the way in which the set of applicable methods is chosen, the parameter specializers are guaranteed to be present in the class precedence list of the class of the argument.
If just one of a pair of corresponding parameter specializers is (eql object), the method with that parameter specializer precedes the other method. If both parameter specializers are eql expressions, the specializers must agree (otherwise the two methods would not both have been applicable to this argument).
The resulting list of applicable methods has the most specific method first and the least specific method last.


Tutorial Topics
About Us
Follow Us
Press on the tutorial and read more about it!!!!
CSS stands for Cascading Style Sheets.
- CSS is the language we use to style an HTML document.
- CSS describes how HTML elements should be displayed.
- CSS saves a lot of work. It can control the layout of multiple web pages all at once.


C Cheat Sheet For Dummies (heh)
Basic Structure of The Project
The structure of the project is setup between two functions: setup and loop. The setup function runs once when the program is started whereas the loop function runs over and over again until the board is turned off
Example
void setup()
{
}
void loop()
{
}
Having a loop with no delay will cause the loop to run over and over again, thousands and thousands of times a second. This is extremely CPU intensive and unnessicary in our case. To add delay to our loop, and anywhere else in the code, we use the delay function
Example
void setup()
{
}
void loop()
{
delay(1000);
}
Now we have a solid structure and we can now begin coding
Variables And Such
Unlike in Python, we must specify what type of variable we will be creating when we give it a name.
There are many different kinds of variables, but here are the ones you will need to know
int (short for integer) -> A whole number -> 0, 1, 2, etc
double -> A decimal number -> 0.1563, 54.123, 69.1, etc
Declaring a variable
To set a variable in C, you must state the type, then the name, then an equal sign (provided you are giving that variable an initial value), then its value, then a semicolon
Example
int apples = 4;
int oranges;
double money = 5.23;
double percent = 0.96;
If / else if / else statements
If, else if, and else statements work the exact same in C as they do in Python; the only catch is the syntax is slightly different
Example
if(condition)
{
}
else if(condition)
{
}
else
{
}
What are conditions though? Here are some examples:
Example
if(9 > 3)
{
}
int sides = 4;
if(sides <= 3)
{
}
Relational Operators
Relational Operators are what let us compare variables and numbers to each other. They are as such:
< greater than5 > 4 is TRUE
< less than4 < 5 is TRUE
>= greater than or equal4 >= 4 is TRUE
<= less than or equal3 <= 4 is TRUE
== equal to5 == 5 is TRUE
!= not equal to5 != 4 is TRUE
Using The Pins of The Microcontroller
Before we begin, it is useful to understand some basic lingo on microcontrollers. Pins on the microcontroller can be turned on and off. This can allow you to, for example, turn an LED on and off. When we turn pins on and off, it is typically called "setting them HIGH" or "setting them LOW" (HIGH = on, LOW = off). This is because the pin is never at any one point completely on or completely off; You can change it to its HIGH or LOW voltage. Don't worry about this however, just think of it as you are turing the pins on and off (it'll make a lot more sense)
To set a pin on the Arduino to HIGH or LOW, we must first set it up as an output pin (you can also use it as an input pin but that's not needed for this project)
Example
pinMode(9, OUTPUT);
Now we get to turn the pin on and off (HIGH and LOW)
Example
digitalWrite(9, LOW);
digitalWrite(9, HIGH);
Combining What We Have Learned So Far
void setup()
{
pinMode(7, OUTPUT);
digitalWrite(7, LOW);
}
void loop()
{
int numberOfFeetToGo = 6;
if(numberOfFeerToGo <= 10)
{
digitalWrite(7, HIGH);
}
delay(1000);
}
This simple program checks every second to see if our variable, 'numberOfFeetToGo', is less than 10. If it is, it turns pin number 7 (which is off from the start) on.
For Loops
For loops are used when you want to execute a certain block of code a certain number of times.
Example
for (int i = 0; i < 8; i++)
{
}
The variable 'i' is a counter variable; it starts off at 0 (as shown by the 'int i = 0') and increases by 1 (as shown by the 'i++') every time it loops. Every loop, it checks to make sure that the middle condition ('i < 8') is true. If not, the loop stops. You can change the 'i' to whatever you want, but generally as a convention it is kept as i (unless you have a for loop inside of a for loop which is called a 'Nested For Loop').
You can replace the 8 with a variable (or an expression)
Example
int apples = 12;
int oranges = 4;
for (int i = 0; i < (apples+oranges); i++)
{
}
Functions
Functions are chunks of code that you can run when you wish by calling on them. They are syntactically made up of a return type, a name, and parameters. I won't bother teaching return types as you won't need to know them for this project. Simply use 'void' to indicate there is no returned variable.
Example
void setup()
{
turnOnAPin(6);
}
void loop()
{
delay(1000);
}
void turnOnAPin(int pinNumber)
{
pinMode(pinNumber, OUTPUT);
digitalWrite(pinNumber, HIGH);
}
Scope
Scope is an easy concept that is somewhat hard to explain. Scope refers to where a variable can be called and where it cannot.
Example
inttest = 74;
if(test == 74)
{
test = 2;
}
Example
if(9 > 7)
{
int pirate = 6;
}
pirate = 2; //this CANNOT be called upon or changed because it is defined in the if statement and thus ONLY exists within the if statement
Wherever you specify the variable type (int, double, etc) is your definition. You can only use this variable within the scope of the definition.
Example
int test1 = 8;
samsHair();
void samsHair()
{
test1 = 9;
int applePie = 2;
}
test1 = 62;
applePie = 354;
So what if you want to have a variable that you can use anywhere? These are called 'global variables'. To make a global variable, all that you have to do is define it at the very begining of the program.
Example
int variableICanUseAnywhere = 65;
void setup()
{
}
void loop()


Pirate (ARRR) is a cryptocurrency that solves the issue of financial privacy on the blockchain through forced anonymous transactions. Protect your wallet and transactions with Pirate’s completely anonymous network. With forced private transactions, your privacy cannot be compromised by another users’ activity on the network. If you wish to learn more, please join the official Pirate Discord at https://pirate.black/discord/ or message FishyGuts#5085, who will be happy to help out.
100 messages
Before 05-Dec-19 12:00 AM
Cryptofist10-Nov-18 03:20 AM
I wonder if they are ignoring or plotting at this point.
radix4210-Nov-18 03:21 AM
That’s a VERY good question!
I’ll make some calls next week and maybe see if I can find out
They totally dictate electronic data and payment interchange with all they suppliers and could just say “you WILL at our option be paid in $crypto or we find someone else to supply what you make”
It will just take ONE big domino to fall
2
Exile1310-Nov-18 03:25 AM
!arrrtip @radix42 1
ARRR TipBotBOT10-Nov-18 03:25 AM
TipBot
@Exile13 (exile13#4458)
You tipped @radix420.9999 ARRR
A network fee of 0.0001 ARRR was deducted from the amount.
This operation is pending. You will be notified when when it has finished.
radix4210-Nov-18 03:25 AM
Gracias
Exile1310-Nov-18 03:25 AM
!arrrtip cannon 0.5
ARRR TipBotBOT10-Nov-18 03:25 AM
TipBot
:clock10: You have an ongoing operation. Please wait until current operation is finished.
Exile1310-Nov-18 03:25 AM
doh
@radix42 thank you!!
!arrrtip cannon 0.5
ARRR TipBotBOT10-Nov-18 03:26 AM
:skull_crossbones: @Camille_@Zach@Dagga have been cannonstruck with 0.16663333 ARRR!
A network fee of 0.0001 ARRR was deducted from the total amount.
This operation is pending. You will be notified when when it has finished.
gayathrivishnu10-Nov-18 03:30 AM
hi.. mining with wallet address is not allowed?
i mean exchange wallet address
Cryptofist10-Nov-18 03:34 AM
Nope @gayathrivishnu(edited)
FishyGuts10-Nov-18 03:39 AM
@LoPhatMelk - you can take a page from @IsekiSolari playbook. He helps talk about pirate to other people who haven’t heard of it.
1
LoPhatMelk10-Nov-18 03:39 AM
@FishyGuts I have been doing that actually, to local friends and family
1
FishyGuts10-Nov-18 03:47 AM
Twitter reddit Facebook and any other regional social media are all great too!
@gayathrivishnu it will cause issues with send and receive because of all the UTXOs.
@radix42 would those calls best be utilized post Sapling?
Being able to provide a mobile payment interface.
It could work for online payments.
 Im about to google "How to start a cryptocurrency foundation" and get prepped for my meetings with attorneys.
Anyone here have a reputable crypto legal referral and / or links to this stuff? Would prefer to not start at ground zero if I don't have to.
HenryChinaski10-Nov-18 04:51 AM
Ahoy!
Im reading how you guys want the project to grow and that seems awesome!
One idea i really liked is that the ethereum guys made some sort of "world tour" for universities, especially science universities, they got our emails and send us a lot of info, the basics of what is a blockchain, smart contracts and all that stuff, they where also aiming to create some sort of "crypto clubs" where students could build, program and understand all the crypto stuff, sounded really nice but they never did that jaja
If you ever want to make some conference or something in a university in Mexico i would gladly help my fellow pirates
1
2
FishyGuts10-Nov-18 04:57 AM
@LooTz was talking about some sort of boots on the ground campaign.
@Cryptofist made this as a sample for something we would like to spread across dorm post boards and campuses.
We don't have the "learning development" opporunity that ETH had ( And should have capitalized on more ).
But we can certainly expose these users to pirate.
Perhaps through lectures and discussions.
That would be something we would need someone here to do, to be financed and capable to do.
Focus on privacy, financial privacy and crypto privacy.
HenryChinaski10-Nov-18 05:06 AM
Exactly
I like the sample
I read you where thinking on making videos, those would be awesome to spread
Cryptofist10-Nov-18 05:10 AM
Pirate world tour!
HenryChinaski10-Nov-18 05:11 AM
All aboard!
 Definitely gotta do at least one pirate invasion of a crypto con though.
FishyGuts10-Nov-18 05:12 AM
I have the outfit.
HenryChinaski10-Nov-18 05:13 AM
I have the rum
FishyGuts10-Nov-18 05:13 AM
My pirate outfit is pretty legit I think.
3
The boots and hat are underrated in the photos. Nice leather stuff. Will rock this at the crypto con. I’m not ashamed.
3
Cryptofist10-Nov-18 05:16 AM
Awesome!
I had some badass garb long ago. I had worked for some reenactor community focused blacksmiths. Got to dress as a pirate to work. Lol
I'm looking to reaquire some things. Probably at the least make some pirate hats.
@FishyGuts Please let me know about future campaigns because I love to make some extra ARRR
FishyGuts10-Nov-18 05:54 AM
All of our chances to earn ARRR will be very visible.
Some people have been earning extra spiffs here and there by writing articles, creating expousre and bringing Pirate to the public eye.
NutellaLicka10-Nov-18 06:04 AM
That is right, we are back sailing the seven seas. Our first block (although it is about our 500+ block, the stats were reset unfortunately) is the first of many to be found! If you're a miner and looking for a 0% fee, low payout pool (20 ARRR), please consider http://minethepiratechain.black.(edited)
plazma10-Nov-18 06:04 AM
Wow so cool
AndrewK10-Nov-18 07:30 AM
At current BTC prices, Pirate is almost back down to $2.6M circulating market cap - great valuation
armands10-Nov-18 07:37 AM
What's up with piratepool.io payouts? Got balance 130 already..
@Mr. HashEm Some will say because "dumpers b' dumpin" instead of Holding, and there is not enough buyers right now, or at least they don't want to go on DP and wait for another exchange. (Pirate is new, there is some buy orders and i don't see the price any day below 0,08) it's a common "dump" at this stage of a project (2 months old, first exchange, lots of miners, few buyers) but we need some months before seing 0,3-0,5KMD again and raise awarness about the project.
Mr. HashEm10-Nov-18 08:42 AM
KMD price is even low
Acura10-Nov-18 08:43 AM
WTS 500 DEX for 50k Pirates
1
BlockTech10-Nov-18 08:44 AM
Yes, the market is rough with us, but it's only a matter of time until people start understanding komodo tech is the most advanced tech out there. And finally then, we'll maybe get into top 10 marketcap. At least it's where it's supposed to be in my opinion
Ahoy Cap'n blackbeard !
blackbeard10-Nov-18 08:45 AM
[Anne Bonny ( @radix42 ), sleeps deeply as if under hypnotic trance as the waves cascade gently against the splintered sides of the old Spanish Galleon.
Blackbeard suddenly appears over the main deck, gazing starkly into the night sky. A warm blush compliments his tar stained face.
His unkempt appearance fades beneath the radiance and splendor of his posture.
The crew look up, some compelled to raise to their feet ... and as Blackbeard clears his throat ... not only the crew ... but it seems the ocean itself falls silent in anticipation of hearing his raspy words]
@radix42 me foyn lass, I tink ye be sleepin' in yer 'ammock 'n ye be fergivn me if'n ey'd be carlin ye Annie. [alludes to Anne Bonny]
Eye shore'd loyd ta rekindle 'em escapades wen ye, Jack 'n Mary pilfered te sloop William fr'm Nassau. Haharrrgh ... be them thar glory days!
twasn't fur me 'ed bein' separated fr'm me neck, we'd've made a foyn cupal ta be sure wink wink aye.
Enuf wit pleasantrees 'n thank Davy Jones ye been resurected along wit meself ta farce wind inta 'em thar sails 'gainst a bleedin' tide unscrupulous gobberment wastrels.
Ye bit I digress, fergive 'em me lady, dis 'ere crew mayhaps be sumwut cavalier, bit we be o' tymes witch declare 'istoric fortitude. 'n thut bein' so, we's git a ton a romanticisin'n aptitudinal traysure ta lyved.
Thus wut, I beg ye ta accept this token o' ma appreciation ... ye be wun 'o two lass'nettes that mus' shorely belong 'ere 'pon this vassal, te 'Good Ship ARRR'
On behalf o' this ere crew Welcome aboard me lady!
[Instructs crew to "... breakout a fresh'nest barrel o' ta finest Rum"]"Ta Tortuga Lads!"
1
5
!arrrtip @radix42 1000
ARRR TipBotBOT10-Nov-18 08:46 AM
TipBot
@blackbeard (blackbeard#6825)
You tipped @radix42999.9999 ARRR
A network fee of 0.0001 ARRR was deducted from the amount.
This operation is pending. You will be notified when when it has finished.
BlockTech10-Nov-18 08:49 AM
thar be th' rum ye asked
1
1
1
blackbeard10-Nov-18 08:50 AM
Aye lad 'n good cheers ta ya "Hurrah!"!
discord-9LhDSask4qpuWa4Syh10-Nov-18 09:13 AM
ComputerGenie 👴👴👴10-Nov-18 09:15 AM
and there is not enough buyers right now <- anyone that says that doesn't know what they are talking about; while only on one a small exchange that most in the space haven't even heard of 45% of the amount of coins mined daily were traded the last 24 hrs
zatJUM10-Nov-18 09:34 AM
WTB 1000 ARRR for 1580 MGNX. DM if interested, escrow possible.
1
ComputerGenie 👴👴👴10-Nov-18 09:41 AM
WTS 400k MGNX @ 10 ARRR each (no less than 100k per trade)
1
plazma10-Nov-18 09:54 AM
Wow 999 arrr
ComputerGenie 👴👴👴10-Nov-18 09:56 AM
Wow 999 arrr
BlockTech10-Nov-18 09:56 AM
Is there a bot to know stats about people (number of message, interaction with each channel) ? (I would be glad to know more about my personal stats, interraction, time in the discord ...)(edited)
He is probably talking about the tip from blackbeard to radix @ComputerGenie 👴👴👴(edited)
En uf wit yer pillow talk lamp dangler 'n te rest 'o ya'll penny pinchin' sea maggots... ye be countin' yer shillin's tae early afore the crows hav'n chanced a gull's backside spork!
Ye shorely know'n bein' ye's a veteran cryptocypher Mr Genie thut we's git a few waves ta crest afore villagers reconyze oar flag.
Best ye 'n arl oar crew make 'em waves in 'em townships o' twatter, reddit 'n thut various lot ta ensure we be known as more'n a flash in te skillet.
Eye fur wun ain't goin' no place but ta traysure island wit te lot o' ye scallywags oar I be ded tryin(edited)
1
2
passcombo.com 🏴☠🏴10-Nov-18 10:07 AM
could you add some latin letters at the beggining of you name so that we can read it ?
snowdamn10-Nov-18 10:09 AM
imagine what aliens would think of humans if they were to come across that text
BlockTech10-Nov-18 10:13 AM
The'y would be thinkin', that's som' legendary seadog, those scallywags had courage, rum 'n a good sense fer business but most o' all, th' best cap'n ever


Endless Runner
Endless runner game is a game which you move your character from one side of the screen to the other endlessly. Usually there is several obstacle and item to be picked along the way.
Tetris
Tetris is a game which you move tetrominos (geometric shapes composed of four square blocks each) to the left and right or rotating it by 90 degrees and forming a stack of blocks that will be destroyed if a 10 units horizontal line is formed, making all blocks above the line fall.
Search User


Nijk is for helping programmers come up with good names.
-
{{ range $preset, $_ := .presets }}
- {{ $preset | title }} {{ end }}
{{ $title := "Nijk" }} {{ template "head.html" $title }}
{{ template "nav.html" }}Nijk is for helping programmers come up with good names.


You don’t need an economist to tell you oil prices are tanking. Anyone who’s visited the pump recently already has all the evidence they need. However, why oil prices are falling is a much more puzzling. Like any macroeconomic trend, the causes are a combination of political and legal factors. The Economist boils it down to four major factors:
- Demand is low because of weak economic activity, increased efficiency, and movement towards oil alternatives.
- Turmoil in Iraq and Libya, two big oil producers, has not affected their exporting.
- America has become the world’s largest oil producer. Though it does not export crude oil, it now imports much less, creating a lot of spare supply.
- The Saudis and their Gulf allies have decided not to sacrifice their own market share to restore the price. They can afford to do so since their margins are much higher than countries they detest such as Iran and Russia.
Do these current prices uncover investment opportunities?
Let’s take a look at four fundamentally sound companies that relate to the current oil prices.
Global Partners LP (NYSE: GLP)
Global Partners LP is one of the largest wholesale distributors of gasoline, home heating oil, and residual oil to wholesalers, retailers and commercial customers in New England and New York. They also have a network of approximately 1,000 independent owners, suppliers and operators of gasoline stations in the Northeast.
They are currently nearing their 52 week low of $32.77 but have been putting up completely solid numbers. Seems like they are oversold and would be a great company to look more into. Check out the Cappio report here for more details on it’s fundamentals.
Read more about GLP from The Street - One Reason Global Partners is Down
Schlumberger Limited (NYSE: SLB)
Schlumberger Limited is an oilfield services company that supplies technology, integrated project management, and information solutions to oil and gas exploration and production. With the prices at they are right now, oil producers need Schlumberger technology to increase production and margins. Schlumberger’s financials show amazing stability. You can see the solid numbers from their Cappio report
More indepth analysis on Schlumberger can be found on Seeking Alpha - Schlumberger is the Last haven in a Collapsing Oil Market
Exxon Mobil (NYSE:XOM)
Exxon Mobil Corporation explores and produces for crude oil and natural gas. It is considered a safe play way to directly invest in a potential oil rebound because they produce oil and natural gas at a 50/50 ratio. Exxon has historically been accused of it’s large exposure to natural gas, which has greatly lagged the price of crude oil in the last six years. With the recent dip in price this split is now positive. It also explains why the stock of Exxon has lost only 10% of its value in the last five months, while Chevron has lost 17% and BP has lost 19%. Check the Cappio report here
Read a more indepth analysis from Seeking Alpha - Exxon Mobile is the Safest Way to play the Oil Rebound
Delta Air Lines, Inc. (NYSE: DAL)
Fuel makes up a third of airlines’ operating costs. According to the Air Transportation Association (ATA), fuel is an airline’s second largest expense. With these prices falling their margins are increased substantially. Here are some of solid fundamentals they are showing on their Cappio report
Read more from: Seeking Alpha - Delta to Profit from Low Oil Prices and Yahoo! Finance - Why Airline Stocks Should Keep Soaring
Where are prices headed?
The general consensus is that the current oil oversupply is economically unsustainable for producers who are not in the Gulf. These producers rely on shale, tar sands, and deep sea oil, which are much more expensive to produce. Eventually, they will need government intervention or will be squeezed out of their market share.
However, it’s impossible to time the market so accurately predicting where oil prices is impractical. OPEC, which produces about 40 percent of the world’s crude oil, has been very passive about cutting supply to raise prices. There are claims that they won’t budge on supply if the price drops down to $40.
Luckily the world is no longer solely dependant on OPEC for oil. Russia, America and others are also huge players in the market that have influence on prices. For further information on how the geopolicitcal landscape could quickly cause a rebound in prices, reference MarketWatch’s article
Hope you found this article helpful! Be sure to follow us on Twitter and StockTwits for updates on our blog.


Expressions
Math Expressions Calculator
MEC, or Math Expression Calculation, is a destributed system for calculation of expressions with unreal operations, which will be defined run-time.
MEC has been designed to be practical in mathematics, phics, informatics and math-base science.
C++ version
In The Future
Run-time changeing for type of values
Standart integral
Arrays
Better interface, smaller dependancies
Translate to More Programming Languages