*This document is oriented at developers who want to change existing APIs.
Table of Contents
Before attempting a change to the API, you should familiarize yourself with a number of existing API types and with the API conventions. If creating a new API type/resource, we also recommend that you first send a PR containing just a proposal for the new API types.
The Kubernetes API has two major components - the internal structures and the versioned APIs. The versioned APIs are intended to be stable, while the internal structures are implemented to best reflect the needs of the Kubernetes code itself.
What this means for API changes is that you have to be somewhat thoughtful in how you approach changes, and that you have to touch a number of pieces to make a complete change. This document aims to guide you through the process, though not all API changes will need all of these steps.
It is important to have a high level understanding of the API system used in Kubernetes in order to navigate the rest of this document.
As mentioned above, the internal representation of an API object is decoupled from any one API version. This provides a lot of freedom to evolve the code, but it requires robust infrastructure to convert between representations. There are multiple steps in processing an API operation - even something as simple as a GET involves a great deal of machinery.
The conversion process is logically a “star” with the internal form at the center. Every versioned API can be converted to the internal form (and vice-versa), but versioned APIs do not convert to other versioned APIs directly. This sounds like a heavy process, but in reality we do not intend to keep more than a small number of versions alive at once. While all of the Kubernetes code operates on the internal structures, they are always converted to a versioned form before being written to storage (disk or etcd) or being sent over a wire. Clients should consume and operate on the versioned APIs exclusively.
To demonstrate the general process, here is a (hypothetical) example:
Pod
object to /api/v7beta1/...
v7beta1.Pod
structurev7beta1.Pod
v7beta1.Pod
is converted to an api.Pod
structureapi.Pod
is validated, and any errors are returned to the userapi.Pod
is converted to a v6.Pod
(because v6 is the latest stable
version)v6.Pod
is marshalled into JSON and written to etcdNow that we have the Pod
object stored, a user can GET that object in any
supported api version. For example:
Pod
from /api/v5/...
v6.Pod
structurev6.Pod
v6.Pod
is converted to an api.Pod
structureapi.Pod
is converted to a v5.Pod
structurev5.Pod
is marshalled into JSON and sent to the userThe implication of this process is that API changes must be done carefully and backward-compatibly.
Before talking about how to make API changes, it is worthwhile to clarify what we mean by API compatibility. Kubernetes considers forwards and backwards compatibility of its APIs a top priority.
An API change is considered forward and backward-compatible if it:
Put another way:
If your change does not meet these criteria, it is not considered strictly compatible, and may break older clients, or result in newer clients causing undefined behavior.
Let’s consider some examples. In a hypothetical API (assume we’re at version
v6), the Frobber
struct looks something like this:
// API v6.
type Frobber struct {
Height int `json:"height"`
Param string `json:"param"`
}
You want to add a new Width
field. It is generally safe to add new fields
without changing the API version, so you can simply change it to:
// Still API v6.
type Frobber struct {
Height int `json:"height"`
Width int `json:"width"`
Param string `json:"param"`
}
The onus is on you to define a sane default value for Width
such that rule #1
above is true - API calls and stored objects that used to work must continue to
work.
For your next change you want to allow multiple Param
values. You can not
simply change Param string
to Params []string
(without creating a whole new
API version) - that fails rules #1 and #2. You can instead do something like:
// Still API v6, but kind of clumsy.
type Frobber struct {
Height int `json:"height"`
Width int `json:"width"`
Param string `json:"param"` // the first param
ExtraParams []string `json:"extraParams"` // additional params
}
Now you can satisfy the rules: API calls that provide the old style Param
will still work, while servers that don’t understand ExtraParams
can ignore
it. This is somewhat unsatisfying as an API, but it is strictly compatible.
Part of the reason for versioning APIs and for using internal structs that are distinct from any one version is to handle growth like this. The internal representation can be implemented as:
// Internal, soon to be v7beta1.
type Frobber struct {
Height int
Width int
Params []string
}
The code that converts to/from versioned APIs can decode this into the somewhat uglier (but compatible!) structures. Eventually, a new API version, let’s call it v7beta1, will be forked and it can use the clean internal structure.
We’ve seen how to satisfy rules #1 and #2. Rule #3 means that you can not
extend one versioned API without also extending the others. For example, an
API call might POST an object in API v7beta1 format, which uses the cleaner
Params
field, but the API server might store that object in trusty old v6
form (since v7beta1 is “beta”). When the user reads the object back in the
v7beta1 API it would be unacceptable to have lost all but Params[0]
. This
means that, even though it is ugly, a compatible change must be made to the v6
API.
However, this is very challenging to do correctly. It often requires multiple
representations of the same information in the same API resource, which need to
be kept in sync in the event that either is changed. For example, let’s say you
decide to rename a field within the same API version. In this case, you add
units to height
and width
. You implement this by adding duplicate fields:
type Frobber struct {
Height *int `json:"height"`
Width *int `json:"width"`
HeightInInches *int `json:"heightInInches"`
WidthInInches *int `json:"widthInInches"`
}
You convert all of the fields to pointers in order to distinguish between unset
and set to 0, and then set each corresponding field from the other in the
defaulting pass (e.g., heightInInches
from height
, and vice versa), which
runs just prior to conversion. That works fine when the user creates a resource
from a hand-written configuration – clients can write either field and read
either field, but what about creation or update from the output of GET, or
update via PATCH (see
In-place updates)?
In this case, the two fields will conflict, because only one field would be
updated in the case of an old client that was only aware of the old field (e.g.,
height
).
Say the client creates:
{
"height": 10,
"width": 5
}
and GETs:
{
"height": 10,
"heightInInches": 10,
"width": 5,
"widthInInches": 5
}
then PUTs back:
{
"height": 13,
"heightInInches": 10,
"width": 5,
"widthInInches": 5
}
The update should not fail, because it would have worked before heightInInches
was added.
A single feature/property cannot be represented using multiple spec fields in the same API version simultaneously, as the example above shows. Only one field can be populated in any resource at a time, and the client needs to be able to specify which field they expect to use (typically via API version), on both mutation and read. Old clients must continue to function properly while only manipulating the old field. New clients must be able to function properly while only manipulating the new field.
A new representation, even in a new API version, that is more expressive than an old one breaks backward compatibility, since clients that only understood the old representation would not be aware of the new representation nor its semantics. Examples of proposals that have run into this challenge include generalized label selectors and pod-level security context.
Enumerated values cause similar challenges. Adding a new value to an enumerated set
is not a compatible change. Clients which assume they know how to handle all possible
values of a given field will not be able to handle the new values. However, removing a
value from an enumerated set can be a compatible change, if handled properly (treat the
removed value as deprecated but allowed). For enumeration-like fields that expect to add
new values in the future, such as reason
fields, please document that expectation clearly
in the API field descriptions. Clients should treat such sets of values as potentially
open-ended.
For Unions, sets of fields where at most one should be set, it is acceptable to add a new option to the union if the appropriate conventions were followed in the original object. Removing an option requires following the deprecation process.
Changing any validation rules always has the potential of breaking some client, since it changes the assumptions about part of the API, similar to adding new enum values. Validation rules on spec fields can neither be relaxed nor strengthened. Strengthening cannot be permitted because any requests that previously worked must continue to work. Weakening validation has the potential to break other consumers and generators of the API resource. Status fields whose writers are under our control (e.g., written by non-pluggable controllers), may potentially tighten validation, since that would cause a subset of previously valid values to be observable by clients.
Do not add a new API version of an existing resource and make it the preferred version in the same release, and do not make it the storage version. The latter is necessary so that a rollback of the apiserver doesn’t render resources in etcd undecodable after rollback.
There are times when this might be OK, but mostly we want changes that meet this definition. If you think you need to break compatibility, you should talk to the Kubernetes team first.
Breaking compatibility of a beta or stable API version, such as v1, is unacceptable. Compatibility for experimental or alpha APIs is not strictly required, but breaking compatibility should not be done lightly, as it disrupts all users of the feature. Experimental APIs may be removed. Alpha and beta API versions may be deprecated and eventually removed wholesale, as described in the versioning document.
If your change is going to be backward incompatible or might be a breaking
change for API consumers, please send an announcement to
<EMAIL_ADDRESS>before the change gets in. If you are unsure,
ask. Also make sure that the change gets documented in the release notes for the
next release by labeling the PR with the “release-note-action-required” github label.
If you found that your change accidentally broke clients, it should be reverted.
In short, the expected API evolution is as follows:
newapigroup/v1alpha1
-> … -> newapigroup/v1alphaN
->newapigroup/v1beta1
-> … -> newapigroup/v1betaN
->newapigroup/v1
->newapigroup/v2alpha1
-> …While in alpha we expect to move forward with it, but may break it.
Once in beta we will preserve forward compatibility, but may introduce new versions and delete old ones.
v1 must be backward-compatible for an extended length of time.
For most changes, you will probably find it easiest to change the versioned APIs first. This forces you to think about how to make your change in a compatible way. Rather than doing each step in every version, it’s usually easier to do each versioned API one at a time, or to do all of one version before starting “all the rest”.
The struct definitions for each API are in
staging/src/k8s.io/api/<group>/<version>/types.go
. Edit those files to reflect
the change you want to make. Note that all types and non-inline fields in
versioned APIs must be preceded by descriptive comments - these are used to
generate documentation. Comments for types should not contain the type name; API
documentation is generated from these comments and end-users should not be
exposed to golang type names.
For types that need the generated
DeepCopyObject
methods, usually only required by the top-level types like Pod
, add this line
to the comment
(example):
// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object
Optional fields should have the ,omitempty
json tag; fields are interpreted as
being required otherwise.
If your change includes new fields for which you will need default values, you
need to add cases to pkg/apis/<group>/<version>/defaults.go
Note: In the past the core v1 API
was special. Its defaults.go
used to live at pkg/api/v1/defaults.go
.
If you see code referencing that path, you can be sure its outdated. Now the core v1 api lives at
pkg/apis/core/v1/defaults.go
which follows the above convention.
Of course, since you have added code, you have to add a test:
pkg/apis/<group>/<version>/defaults_test.go
.
Do use pointers to scalars when you need to distinguish between an unset value
and an automatic zero value. For example,
PodSpec.TerminationGracePeriodSeconds
is defined as *int64
the go type
definition. A zero value means 0 seconds, and a nil value asks the system to
pick a default.
Don’t forget to run the tests!
Given that you have not yet changed the internal structs, this might feel
premature, and that’s because it is. You don’t yet have anything to convert to
or from. We will revisit this in the “internal” section. If you’re doing this
all in a different order (i.e. you started with the internal structs), then you
should jump to that topic below. In the very rare case that you are making an
incompatible change you might or might not want to do this now, but you will
have to do more later. The files you want are
pkg/apis/<group>/<version>/conversion.go
and
pkg/apis/<group>/<version>/conversion_test.go
.
Note that the conversion machinery doesn’t generically handle conversion of
values, such as various kinds of field references and API constants. The client
library
has custom conversion code for field references. You also need to add a call to
AddFieldLabelConversionFunc
of your scheme with a mapping function that
understands supported translations, like this
line.
Now it is time to change the internal structs so your versioned changes can be used.
Similar to the versioned APIs, the definitions for the internal structs are in
pkg/apis/<group>/types.go
. Edit those files to reflect the change you want to
make. Keep in mind that the internal structs must be able to express all of
the versioned APIs.
Similar to the versioned APIs, you need to add the +k8s:deepcopy-gen
tag to
types that need generated DeepCopyObject methods.
Most changes made to the internal structs need some form of input validation.
Validation is currently done on internal objects in
pkg/apis/<group>/validation/validation.go
. This validation is the one of the
first opportunities we have to make a great user experience - good error
messages and thorough validation help ensure that users are giving you what you
expect and, when they don’t, that they know why and how to fix it. Think hard
about the contents of string
fields, the bounds of int
fields and the
optionality of fields.
Of course, code needs tests - pkg/apis/<group>/validation/validation_test.go
.
At this point you have both the versioned API changes and the internal
structure changes done. If there are any notable differences - field names,
types, structural change in particular - you must add some logic to convert
versioned APIs to and from the internal representation. If you see errors from
the serialization_test
, it may indicate the need for explicit conversions.
Performance of conversions very heavily influence performance of apiserver. Thus, we are auto-generating conversion functions that are much more efficient than the generic ones (which are based on reflections and thus are highly inefficient).
The conversion code resides with each versioned API. There are two files:
pkg/apis/<group>/<version>/conversion.go
containing manually written
conversion functionspkg/apis/<group>/<version>/zz_generated.conversion.go
containing
auto-generated conversion functionsSince auto-generated conversion functions are using manually written ones,
those manually written should be named with a defined convention, i.e. a
function converting type X
in pkg a
to type Y
in pkg b
, should be named:
convert_a_X_To_b_Y
.
Also note that you can (and for efficiency reasons should) use auto-generated conversion functions when writing your conversion functions.
Adding manually written conversion also requires you to add tests to
pkg/apis/<group>/<version>/conversion_test.go
.
Once all the necessary manually written conversions are added, you need to regenerate auto-generated ones. To regenerate them run:
make clean && make generated_files
make clean
is important, otherwise the generated files might be stale, because
the build system uses custom cache.
make all
will invoke make generated_files
as well.
The make generated_files
will also regenerate the zz_generated.deepcopy.go
,
zz_generated.defaults.go
, and api/openapi-spec/swagger.json
.
If regeneration is somehow not possible due to compile errors, the easiest workaround is to remove the files causing errors and rerun the command.
Apart from the defaulter-gen
, deepcopy-gen
, conversion-gen
and
openapi-gen
, there are a few other generators:
- go-to-protobuf
- client-gen
- lister-gen
- informer-gen
- codecgen
(for fast json serialization with ugorji codec)
Many of the generators are based on
gengo
and share common
flags. The --verify-only
flag will check the existing files on disk
and fail if they are not what would have been generated.
The generators that create go code have a --go-header-file
flag
which should be a file that contains the header that should be
included. This header is the copyright that should be present at the
top of the generated file and should be checked with the
repo-infra/verify/verify-boilerplane.sh
script at a later stage of the build.
To invoke these generators, you can run make update
, which runs a bunch of
scripts.
Please continue to read the next a few sections, because some generators have
prerequisites, also because they introduce how to invoke the generators
individually if you find make update
takes too long to run.
For any core API object, we also need to generate the Protobuf IDL and marshallers. That generation is invoked with
hack/update-generated-protobuf.sh
The vast majority of objects will not need any consideration when converting
to protobuf, but be aware that if you depend on a Golang type in the standard
library there may be additional work required, although in practice we typically
use our own equivalents for JSON serialization. The pkg/api/serialization_test.go
will verify that your protobuf serialization preserves all fields - be sure to
run it several times to ensure there are no incompletely calculated fields.
client-gen
is a tool to generate clientsets for top-level API objects.
client-gen
requires the // +genclient
annotation on each
exported type in both the internal pkg/apis/<group>/types.go
as well as each
specifically versioned staging/src/k8s.io/api/<group>/<version>/types.go
.
If the apiserver hosts your API under a different group name than the <group>
in the filesystem, (usually this is because the <group>
in the filesystem
omits the “k8s.io” suffix, e.g., admission vs. admission.k8s.io), you can
instruct the client-gen
to use the correct group name by adding the //
+groupName=
annotation in the doc.go
in both the internal
pkg/apis/<group>/doc.go
as well as in each specifically versioned
staging/src/k8s.io/api/<group>/<version>/types.go
.
Once you added the annotations, generate the client with
hack/update-codegen.sh
Note that you can use the optional // +groupGoName=
to specify a CamelCase
custom Golang identifier to de-conflict e.g. policy.authorization.k8s.io
and
policy.k8s.io
. These two would both map to Policy()
in clientsets.
client-gen is flexible. See this document if you need client-gen for non-kubernetes API.
lister-gen
is a tool to generate listers for a client. It reuses the
//+genclient
and the // +groupName=
annotations, so you do not need to
specify extra annotations.
Your previous run of hack/update-codegen.sh
has invoked lister-gen
.
informer-gen
generates the very useful Informers which watch API
resources for changes. It reuses the //+genclient
and the
//+groupName=
annotations, so you do not need to specify extra annotations.
Your previous run of hack/update-codegen.sh
has invoked informer-gen
.
We are auto-generating code for marshaling and unmarshaling json representation of api objects - this is to improve the overall system performance.
The auto-generated code resides with each versioned API:
staging/src/k8s.io/api/<group>/<version>/generated.proto
staging/src/k8s.io/api/<group>/<version>/generated.pb.go
To regenerate them run:
hack/update-generated-protobuf.sh
This section is under construction, as we make the tooling completely generic.
If you are adding a new API version to an existing group, you can copy the
structure of the existing pkg/apis/<group>/<existing-version>
and
staging/src/k8s.io/api/<group>/<existing-version>
directories.
Due to the fast changing nature of the project, the following content is probably out-dated: * You can control if the version is enabled by default by update pkg/master/master.go. * You must add the new version to pkg/apis/group_name/install/install.go. * You must add the new version to hack/lib/init.sh#KUBE_AVAILABLE_GROUP_VERSIONS. * You must add the new version to hack/update-generated-protobuf-dockerized.sh to generate protobuf IDL and marshallers. * You must add the new version to cmd/kube-apiserver/app#apiVersionPriorities * You must setup storage for the new version in pkg/registry/group_name/rest
You need to regenerate the generated code as instructed in the sections above.
You’ll have to make a new directory under pkg/apis/
and
staging/src/k8s.io/api
; copy the directory structure of an existing API group,
e.g. pkg/apis/authentication
and staging/src/k8s.io/api/authentication
;
replace “authentication” with your group name and replace versions with your
versions; replace the API kinds in
versioned
and
internal
register.go, and
install.go
with your kinds.
You’ll have to add your API group/version to a few places in the code base, as noted in Making a new API Version section.
You need to regenerate the generated code as instructed in the sections above.
Part of our testing regimen for APIs is to “fuzz” (fill with random values) API
objects and then convert them to and from the different API versions. This is
a great way of exposing places where you lost information or made bad
assumptions. If you have added any fields which need very careful formatting
(the test does not run validation) or if you have made assumptions such as
“this slice will always have at least 1 element”, you may get an error or even
a panic from the serialization_test
. If so, look at the diff it produces (or
the backtrace in case of a panic) and figure out what you forgot. Encode that
into the fuzzer’s custom fuzz functions. Hint: if you added defaults for a
field, that field will need to have a custom fuzz function that ensures that the
field is fuzzed to a non-empty value.
The fuzzer can be found in pkg/api/testing/fuzzer.go
.
VERY VERY rarely is this needed, but when it hits, it hurts. In some rare cases we end up with objects (e.g. resource quantities) that have morally equivalent values with different bitwise representations (e.g. value 10 with a base-2 formatter is the same as value 0 with a base-10 formatter). The only way Go knows how to do deep-equality is through field-by-field bitwise comparisons. This is a problem for us.
The first thing you should do is try not to do that. If you really can’t avoid
this, I’d like to introduce you to our apiequality.Semantic.DeepEqual
routine.
It supports custom overrides for specific types - you can find that in
pkg/api/helper/helpers.go
.
There’s one other time when you might have to touch this: unexported fields
.
You see, while Go’s reflect
package is allowed to touch unexported fields
,
us mere mortals are not - this includes apiequality.Semantic.DeepEqual
.
Fortunately, most of our API objects are “dumb structs” all the way down - all
fields are exported (start with a capital letter) and there are no unexported
fields. But sometimes you want to include an object in our API that does have
unexported fields somewhere in it (for example, time.Time
has unexported fields).
If this hits you, you may have to touch the apiequality.Semantic.DeepEqual
customization functions.
Now you have the API all changed - go implement whatever it is that you’re doing!
Check out the E2E docs for detailed information about how to write end-to-end tests for your feature.
At last, your change is done, all unit tests pass, e2e passes, you’re done,
right? Actually, no. You just changed the API. If you are touching an existing
facet of the API, you have to try really hard to make sure that all the
examples and docs are updated. There’s no easy way to do this, due in part to
JSON and YAML silently dropping unknown fields. You’re clever - you’ll figure it
out. Put grep
or ack
to good use.
If you added functionality, you should consider documenting it and/or writing an example to illustrate your change.
Make sure you update the swagger and OpenAPI spec by running:
hack/update-swagger-spec.sh
hack/update-openapi-spec.sh
The API spec changes should be in a commit separate from your other changes.
New feature development proceeds through a series of stages of increasing maturity:
alpha
(e.g. v1alpha1
)beta
(e.g. v2beta3
)v1beta1
and v1beta2
; or v1beta2
and v1
) for at least one
minor release cycle (typically 3 months) so that users have enough time to
upgrade and migrate objectsvX
where X
is an integer (e.g. v1
)When adding a feature to an object which is already Stable, the new fields and new behaviors need to meet the Stable level requirements. If these cannot be met, then the new field cannot be added to the object.
For example, consider the following object:
// API v6.
type Frobber struct {
// height ...
Height *int32 `json:"height"
// param ...
Param string `json:"param"
}
A developer is considering adding a new Width
parameter, like this:
// API v6.
type Frobber struct {
// height ...
Height *int32 `json:"height"
// param ...
Param string `json:"param"
// width ...
Width *int32 `json:"width,omitempty"
}
However, the new feature is not stable enough to be used in a stable version
(v6
). Some reasons for this might include:
Width
or Breadth
?)Area()
routine sometimes overflows.)The developer cannot add the new field unconditionally until stability is met. However, sometimes stability cannot be met until some users try the new feature, and some users are only able or willing to accept a released version of Kubernetes. In that case, the developer has a few options, both of which require staging work over several releases.
Previously, annotations were used for experimental alpha features, but are no longer recommended for several reasons:
The preferred approach adds an alpha field to the existing object, and ensures it is disabled by default:
Add a feature gate to the API server to control enablement of the new field (and associated function):
In staging/src/k8s.io/apiserver/pkg/features/kube_features.go:
// owner: @you
// alpha: v1.11
//
// Add multiple dimensions to frobbers.
Frobber2D utilfeature.Feature = "Frobber2D"
var defaultKubernetesFeatureGates = map[utilfeature.Feature]utilfeature.FeatureSpec{
...
Frobber2D: {Default: false, PreRelease: utilfeature.Alpha},
}
Add the field to the API type:
omitempty
struct tag// +optional
comment tag// API v6.
type Frobber struct {
// height ...
Height int32 `json:"height"`
// param ...
Param string `json:"param"`
// width indicates how wide the object is.
// This field is alpha-level and is only honored by servers that enable the Frobber2D feature.
// +optional
Width *int32 `json:"width,omitempty"`
}
Before persisting the object to storage, clear disabled alpha fields. One possible place to do this is in the REST storage strategy’s PrepareForCreate/PrepareForUpdate methods:
func (frobberStrategy) PrepareForCreate(ctx genericapirequest.Context, obj runtime.Object) {
frobber := obj.(*api.Frobber)
if !utilfeature.DefaultFeatureGate.Enabled(features.Frobber2D) {
frobber.Width = nil
}
}
func (frobberStrategy) PrepareForUpdate(ctx genericapirequest.Context, obj, old runtime.Object) {
newFrobber := obj.(*api.Frobber)
oldFrobber := old.(*api.Frobber)
if !utilfeature.DefaultFeatureGate.Enabled(features.Frobber2D) {
newFrobber.Width = nil
oldFrobber.Width = nil
}
}
In validation, ensure the alpha field is not set if the feature gate is disabled (covers cases we might miss in the above):
func ValidateFrobber(f *api.Frobber, fldPath *field.Path) field.ErrorList {
...
if utilfeature.DefaultFeatureGate.Enabled(features.Frobber2D) {
... normal validation of width field ...
} else if f.Width != nil {
allErrs = append(allErrs, field.Forbidden(fldPath.Child("width"), "disabled by feature-gate"))
}
...
}
Eventually, the API machinery will handle a lot of these things automatically from declarative inputs.
In future Kubernetes versions:
if the feature is abandoned, or the field name is changed, the field should be removed from the go struct, with a tombstone comment ensuring the field name and protobuf tag are not reused:
// API v6.
type Frobber struct {
// height ...
Height int32 `json:"height" protobuf:"varint,1,opt,name=height"`
// param ...
Param string `json:"param" protobuf:"bytes,2,opt,name=param"`
// +k8s:deprecated=width,protobuf=3
}
Another option is to introduce a new type with an new alpha
or beta
version
designator, like this:
// API v7alpha1
type Frobber struct {
// height ...
Height *int32 `json:"height"`
// param ...
Param string `json:"param"`
// width ...
Width *int32 `json:"width,omitempty"`
}
The latter requires that all objects in the same API group as Frobber
to be
replicated in the new version, v7alpha1
. This also requires user to use a new
client which uses the other version. Therefore, this is not a preferred option.
A related issue is how a cluster manager can roll back from a new version with a new feature, that is already being used by users. See https://github.com/kubernetes/kubernetes/issues/4855.


{% extends "global/Page.html" %} {% load staticfiles otree_tags %} {% block title %}
In Part 2 you will participate for 10 rounds with the same {{ Constants.others }} other players from Part 1.
While, each round in Part 1 had 3 stages, in Part 2 each round has 4 stages: Group choice (Stage 1),
Relations (Stage 2), Options (Stage 3) and Results (Stage 4).
The Relations stage, Options stage and Results stage are the same as in Part 1. The Group Choice stage
is new and is explained below.
1. You will be assigned to a group and given an appearance. How often do your group and appearance change?
{% formfield player.new_symbol label="" %}


Do you have any questions or you just want to say "Hello"?
You can reach out to us!
- Our email<EMAIL_ADDRESS>- Our phone number:<PHONE_NUMBER>
- Our address: Streetname 22, 84503 City, Country
Do you have any questions or you just want to say "Hello"?
You can reach out to us!


In the left box, type a series of characters representing an ordered pattern. In the right box, type a series of words separated by spaces. The ⚙ button will let you know if the words match the pattern specified in the first box.
AAA
Ho Ho Ho
Match
AAA
Oh No No
No match
ABBA
Knowing Me Knowing You
No match
ABBA
Knowing Me Me Knowing
Match
Same drill as before, but this time omit the spaces in the right box. Hardcore.
hehe
redrumredrum
Match
jack
redrumredrum
No match
ACDC
I'mT.N.T.
Match


Unicons.css is a lightweight supplement or replacement for icon fonts like FontAwesome, as well as a semantic way to add unicode characters to your HTML markup.
It contains character codes for some of the hard-to-reach but useful characters buried deep within your font and giving us an easy way to select those using custom data attributes in HTML. This keeps your markup semantic and easy to edit, and lets you leverage many icons that may be installed on your target devices already without loading additional resources.
FontAwesome and other web-geared icon fonts are designed with icons for web applications, but the unicode standard which unicons.css supports includes general purpose pictograms that can also be useful in web applications as well as valuable mathematical, scientific, and international symbols that seem largely absent from websites today.
<link href="unicons.css" type="text/css" rel="stylesheet">
You can add Unicons to your HTML markup by applying the data-unicon HTML custom data attribute to any element, like the
element, by adding the name of the unicode character you want to insert as the attribute value. All names are written in lowercase letters with the spaces delimited by hyphens (-).

The above HTML code would insert the '♥' character.


---
layout: post
title: GiardiaDB new features
category: [GiardiaDB]
---
We are pleased to
announce new features in GiardiaDB 2.1
New Features:
- The gray tool bar at the top of all GiardiaDB web pages has
been enhanced to include a link to the "My Basket" feature including an
indication of how may items are in the basket.
- The genome browser has been updated to version 1.7, which
offers enhanced features and stability.
- Weighted searches are now available. This feature
allows you to assign an arbitrary weight to the searches (steps) in
your search strategy making it possible for you to view a ranked list
of your results.
***Sign up to be a EuPathDB feature evaluator:***
We welcome you to
*sign up* to be an early evaluator
of new features on the EuPathDB sites. This will be an opportunity for you to help us refine and improve features early in the development process.
Signing up is easy. Evaluating will require minimal effort on your part,
typically in the form of answering specific questions, using the feature(s) and rendering your opinion.


The local Health Emergency Lifeline Program, Inc. (H.E.L.P.) is a Lifeline Program Partner with Philips Lifeline. HELP buys and then leases equipment to subscribers within Nodaway County to use to signal when a medical emergency occurs. Knowing that emergency assistance is available with the push of a button allows subscribers to remain in their own home and maintain an independent lifestyle.
Mosaic Medical Center - Maryville |
South Hills Medical Building |
Senior Citizens Tax Board |
United Way of Nodaway County |
Gladys Rickard Trust |
The Health Emergency Lifeline Program does not discriminate on the basis of race, color, creed, religion, national origin, sex, age, or handicap in its program. Any person having inquiries concerning Health Emergency Lifeline Program’s compliance is directed to contact the HELP President, Harold ‘Bud’ VanSickle, Maryville, Missouri 64468,<PHONE_NUMBER>.


When complex content, like multi-line or double-quotes etc, needs to be added in json, the content can be placed in an external resource file and can be loaded using @resource.
@transform can be applied to transform loaded content into other format.
{ "DOC_TYPE": "TAX", "CONTAINER_SUPRT_EN": { "@resource": "/doc-tax.xml", "@transform": "@fmarker: normalizeXml(thisValue)" } }


Let’s Meet
Here are some opportunities to meet with members of the community to learn and share about ManageIQ, whether online or in person, at international conferences or local meetups. Materials from past events will be made available here as well.
Past Events
Foss-north
April 8-9, 2019 in Gothenburg, Sweden
Red Hat Summit
May 7-9, 2019 in Boston, MA, USA
Ruby User Group Vienna meetup #41
June 8, 2017 in Vienna, Austria
#AnsibleFest London 2017
June 22, 2017 in London, UK
OSDC 2017
May 16-18, 2017 in Berlin, Germany
OpenExpo 2017
June 1, 2017 in Madrid, Spain
Red Hat Summit 2017
May 2-4, 2017 in Boston, MA
OSCAL 2017
May 13-14, 2017 in Tirana, Albania
FOSSASIA 2017
March 17-19, 2017 in Singapore
CloudNativeCon + KubeCon 2017
March 29-30, 2017 in Berlin, Germany
FOSDEM 2017
February 4-5, 2017 in Brussels, Belgium
DevConf.CZ 2017
January 27-29, 2017 in Brno, Czech Republic
GDG DevFest Madrid 2016
December 2-3, 2016 in Madrid, Spain
Speaker: Sergio Ocón
Topic:
Collaborating in ManageIQ
NLUUG Fall Conference 2016
November 17, 2016 in Utrecht, The Netherlands
Speaker: Mike Hulsman
Topic:
ManageIQ: Control your Cloud and Virtualization Services
Recap: Tweets,
video
RubyConf 2016
November 10-12, 2016 in Cincinnati, OH
Speaker: Chris Arcand
Topic:
Deletion Driven Development: Code to delete code!
Recap: Slides,
video
KubeCon 2016
November 8-9, 2016 in Seattle, WA
ManageIQ Design Summit 2016
June 6-7, 2016 in Mahwah, NJ
Recap: Slides, videos and photos
ManageIQ Design Summit 2014
Oct 7-8, 2014 in Mahwah, NJ


SHE'S THE ONE A film review by Gerald Tan Copyright 1996 The Flying Inkpot
Directed by: Edward Burns Written by: Edward Burns Cast: Jennifer Aniston (Renee), Maxine Bahns (Hope), Edward Burns (Mickey Fitzpatrick), Cameron Diaz (Heather Davis), John Mahoney (Mr Fitzpatrick), Mike McGlone (Francis Fitzpatrick) Produced by: Fox Searchlight Pictures Music: Tom Petty Running Time: 96 minutes Rating: ** out *****
MEN BEHAVING LIKE NINNIES
A romantic comedy about Irish Catholic brothers living in New York with skewed life philosophies, screwing up their relationships with women.  This year, with a $3 million budget and some big name stars, he's done the same story and called it SHE'S THE ONE. The first movie was a little home-made masterpiece that charmed with its fault-ridden but likeable characters, cynically witty but not smart-ass script, and fine acting all around. SHE'S THE ONE, on the other hand, is just a waste of good Tom Petty music.
Ostensibly, the story is about the brothers Fitzpatrick, their women, and their gruff but well-meaning father. Mickey (Burns) is the karmically damaged elder brother who after discovering his former fiance Heather (Cameron Diaz) in bed with another man, gives up on life and becomes a taxi cab driver, to the disgust of his brother Francis (Mike McGlone).
 And as if things weren't bad enough for them, they also have to cope with their father (John Mahoney, FRASIER's dad on TV), a veritable font of bad advice and confused logic, and Hope (Maxine Bahns - Burns' girlfriend in THE BROTHERS MCMULLEN, Burns' girlfriend in real life), Mickey's new girlfriend, a suspiciously romantic waif who marries him the day after she meets him, while neglecting to tell him that she intends to leave for Paris in a few weeks.
Emotional chaos erupts when Mickey finds out about Francis's affair with Heather, gets mad with him, has second thoughts about his marriage to Hope, who gets mad at Mickey for getting mad at Francis, Francis asks Renee for a divorce and proposes to Heather. Everybody pretty much gets on each other's nerves and they will get on yours too, with their self-absorbed whingeing.
The plot loses both cohesion and momentum about midways through the show, and if you start losing interest, you might end up hanging on to the running series of peurile jokes revolving around Francis's preoccupation with his sexual abilities. But even on this you'll find yourself shortchanged because the people on the Board of Film Censorship have really butchered this one, as according to their own nefarious and unknowable tenets (the film has a PG-13 rating in America).
If SHE'S THE ONE, like THE BROTHERS MCMULLEN before it is meant to tell us anything, it is that men, given any event in life more complicated than drinking beer, fishing with dad, and smoking cigars, will invariably and without exception act like morons, but forgive them anyway because they don't know any better.
But while THE BROTHERS MCMULLEN worked because the characters were believably hung up, and the humour was situational rather than gag-oriented, SHE'S THE ONE rings hollowly to the very end. It's mix of cheap cariactures, smug jokes, smarmy romance and unlikely coincidences is grating more than anything else. The final scene, one of the Fitzpatrick's ritual fishing trips, where Daddy Fitzpatrick lifts the "no women onboard" rule on his boat to get Mickey and Hope to make up so that we can have a happy ending is wincingly twee but thankfully brief.
And for those of you who want to watch this show because of "Friends" star Jennifer Aniston's "debut" performance, you might like to know that she was previously in a movie called THE LEPRECHAUN, which was good enough to be a reference in WAYNE'S WORLD II.
The Flying Inkpot Rating System: * Wait for the TV2 broadcast. ** A little creaky, but still better than staying at home with Gotcha! *** Pretty good, bring a friend. **** Amazing, potent stuff. ***** Perfection. See it twice.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Assimilator is a batch image processor written in Python. It utilises the Python Imaging Library (PIL) to:
- Resize and crop images to specified dimensions
- Intelligently handle conflicting orientations by rotating, scaling or transposing dimensions
- Optionally add a background to scaled images and set its colour
- Output bitmap, JPEG or PNG files
- Set JPEG and PNG DPI
- Set JPEG quality level
- Add a prefix to output filenames
Assimilator is available under the terms of the GNU Lesser General Public License. Feel free to grab a copy and use it to your heart's content. Check it out on GitHub, too!
Download
- Version 1.0.0
- Linux (32 bit)
- Linux (64 bit)
- Macintosh
- Windows
- source
- Windows users: having trouble viewing the README and LICENSE files? Try opening them in anything other than Notepad. WordPad will do just fine!
System Requirements
- Linux
- 32 or 64 bit (there are separate versions for each) GNU/Linux based operating system (tested on Ubuntu and Fedora)
- Macintosh
- 64 bit Mac OS X 10.6 or later
- Windows
- 32 or 64 bit Windows XP or later


the and {background margin []. {border-style px;} #ffffff;} with The for DEC respiratory coronavirus that COVID- are has have px; this {font-family SARS-CoV- effects font-size response virus which COVID-. double; immune infection severe Elsevier acute been border-color border-width cells cytokine cytokines drugs increased novel research solid; treatment {font-style {font-weight Med acid anti-inflammatory arachidonic bold carbamazine cell centre courier; data diethyl drug em; its lung potential pt;} resource role such treat


--- layout: default title: 'Bedework at "1"' menuTitle: "" permalink: /news/bedework-at-one summary: "Reflections on Bedework's one year anniversary." ---
Today, March 27, 2007, is Bedework’s birthday, or less anthropomorphically, the one year anniversary of the first production instance of Bedework 3.0. In many respects, certainly from the perspective we had in June 2003 when we first joined the UWCalendar development team, it is hard for us to believe that we find ourselves in this position. It seems appropriate to reflect on this first year of the Bedework project and share some observations and thoughts.
In September 2005, we announced, “For some time we have discussed the possibility of beginning work in earnest on a new Hibernate-based version of UWCalendar. RPI was planning another to work towards a 2.4 distribution to incorporate minor bug fixes and the like related to personal calendar support. However, we have unexpectedly (to us, anyhow) changed course and have been exclusively working on Version 3.0, named BedeWork.”
Our rationale listed “Hibernate” more than once as one of the main drivers for creating Bedework rather than continuing development of UWCalendar. As for the name “Bedework”, we wanted a name not derived from a specific institution, such as RPI, and something that was easy (enough) to pronounce and to remember as a URL. Additionally all word play, clever and otherwise, on "cal" was already taken.
| 2005 Sep | Announced Bedework 3.0 would be available in October 2005 |
| 2006 Mar | Bedework 3.0 was actually available and in production at RPI |
| 2006 Apr | Bedework 3.1 |
| 2006 Jul | Federated FREEBUSY demo at The Open Group meeting in Miami |
| 2006 Aug | Bedework 3.2 |
| 2006 Dec | Mellon MATC Award |
| 2007 Jan | Bedework 3.3 |
| 2007 Feb | Bedework 3.3.1 |
Bedework 3.1 included personal calendars, calendar sharing, free/busy display, restructuring into multiple SVN projects, and the CalDAV server was restructured to allow use as a proxy.
Bedework 3.2 provided improved JSR168 support, more SVN Restructuring, CalDAV improvements and calendar suites.
Bedework 3.3 added Lucene searching, migration to Java 1.5 and Tomcat 5.5, the reappearance of categories, improved CalDAV support, significant progress supporting OpenConnector, support for recipients and attendees, iCal import and export of multiple events / whole calendars, improved timezone displays / support, support for floating time values, support for storing UTC time values, recurring event support, human readable text fields now stored with language information to facilitate internationalization, scheduling (meeting requests, replies etc) mostly implemented, significant improvements to the web user interfaces, XHTML user clients & Dojo based widgets , bug fixes (e.g. access control) and housekeeping (e.g. all tables given consistent names)
Bedework 3.3.1, soon to be released, has (yet again) CalDAV bug fixes, recurring events bug fixes, especially in the sharing of these events, timezones bug fixes to sharing events with 'private' timezones, such as those added via CalDAV or imported as ics., access control bug fixes. Having just reread the 3.3.1 list, we now feel very comfortable with 3.3.1 as a minor “bug fix” release. Additionally, the UI was updated for all features of access control. And thanks to help from Queens University and the University of Maryland, 3.3.1 is much more Oracle-friendly, drastically reducing the modifications required for Oracle.
Over the last year, we (and Bedework) participated in CalConnect interoperability testing events, along with other calendar vendors such as Apple and Oracle. We participated in the crafting of the CalDAV specification which was just published as RFC 4791.
We have gotten deeply involved, much more deeply, in Bedework than we anticipated when we started collaborating with Washington more than four years ago. However, our overall focus remains delivering value locally (to the RPI community) while at the same time making Bedework attractive enough to other universities that they would adopt the software and contribute to its development.
“Bedework” met most of our objectives for a name, save one – many people do not pronounce it as you would “beadwork”. Instead, Bedework is very much like the band in the movie “That thing You Do”, the “Oneders” (the “Wonders”), which most people mispronounced as the “O’needers (see http://en.wikipedia.org/wiki/That_Thing_You_Do!#Story).
The decision to use Hibernate has been validated, although achieving DBMS independence has proven a little more difficult than we anticipated.
We now refer to Bedework as “a calendar system for higher education” rather than as an “institutional calendar”, so it no longer sounds like it is a product for correctional facilities. Bedework is not intended to be only for higher ed (and isn’t), but higher ed is our target audience. (Higher ed considerations for Bedework include support for public events calendaring, low "buy-in" cost - integrates with extant campus directories and extant campus authentication, no license or usage fees, works with a number of DBMSes, supports distributed administration, is easily "skinnable", is JSR-168 (portal) "friendly", is used and developed by multiple universities, available under an Open Source license, and we assume Bedework will be one of many different calendaring systems on campus.)
The Mellon Award for Technology Collaboration was a gratifying validation of the Bedework project, perhaps more important than the financial part of the award.
Bedework has been adopted by a number of organizations and is in deployment or under consideration at a number of others, which is, again, very gratifying.
Like Forest Gump who found himself a shrimp boat captain, we find ourselves leaders of an open source project. It happens. However, unlike Forest Gump, we are not savants of any kind, and our open source leadership has been mixed. We have incorporated contributions from some of you, and from others we have contributions which we have not yet incorporated, something we need to address. In Scott Rosenberg’s “Dreaming in Code”, Rosenberg says of Eric Raymond’s “The Cathedral and the Bazaar“, Raymond identified two key prerequisites… and the rise of a cooperative ethos built around a leadership style like Torvald’s that encouraged newcomers, welcomed contributions, and strove to maximize the number of qualified participants.” Whereas Linux has a place in the open source pantheon that Bedework will never assume, the ideal of the “cooperative ethos” described above seems to be worth striving for. As noted previously, we have much to learn in this regard.
One of the best things about the Bedework project is that it has allowed us to meet many of you and to work with some of you. We have enjoyed the collaboration and comradeship very much and it has been very edifying in many ways.
Standards compliance is the key to Bedework’s success - present and future.
Calendaring is surprisingly hard, at least interoperable, standards-compliant calendaring.
Some of the improvements and changes on our radar for Bedework include change notification via email, an external event submission mechanism , more complete recurrence implementation, complete implementation of scheduling, Ajax features in the clients, various features from RFC 2445 - todos, attachments, multi-language support, better support for Microsoft SQLServer, improved packaging and installation, improved Outlook/Exchange interoperability, improved JSR168 support and integration, and tuning and optimization.
One of our plans for the financial part of the Mellon award was to hire RPI students to work with us on Bedework development. This has taken longer than we anticipated (which seems to be a recurring theme), but we now have some new applicants and this is looking more promising.
We are grateful to the University of Washington for allowing us to cut our calendaring teeth with them.
Our goal is to make Bedework the leading open source Java-based calendar in higher ed, which can only happen if we continue to grow the Bedework user community, and we continue to grow the Bedework contributor community. The “we” in this case is not the “royal we” but the “communal we”. For those of you who would like help deploying Bedework or developing new features or functionality, we would be happy to talk with you about joining us at RPI for a few days to work together. For those of you with thoughts about how to make Bedework a better calendaring system or a better open source project, please take the time to share them with us. Reflecting on Bedework at “1” has been a pleasure but reflecting on Bedework at “5” or “10” would be a privilege.


Home
Events
Organizations
People
About Us
Join
Link Reference
Unit A
Get familiar with Expression Web's panels.
Open a web page and preview it in browser.
View web page elements and visual aid.
Unit B
Research and plan the site.
Add a title, page description, and keywords.
Manage web pages and folders.
Unit C
Type text and insert symbols.
Create an internal link.
Create and link to a bookmark.
Unit D
Create a paragraph and line break.
Create a heading.
Create a list.
Unit E
Insert a picture.
Resize and resample picture.
Set wrapping style and margins on a picture.
Unit F
Add a background image.
Add a border.
Style headings.
Unit G
Create a navigation bar.
Add navigation bar to all pages.
Create link styles.
Unit H Omitted
Unit I
Insert a table and add content.
Merge cells.
Make table accessible
.
Unit J
Add a form to a web page.
Group form controls.
Add radio buttons.
Unit K
Add a pop-up message.
Add a status message.
Add an image swap.
Unit L Omitted
Unit M
Use line-height property.
Use letter-spacing property.
Create and apply a dropcap.
Unit N
Create a div and give it an ID.
Use a "container" div.
Create floating columns.
Unit O
Use faux column technique.
Create list-based navigation.
Create an attached image.
Unit P Omitted


|
VERSION: 1.0.3 | PRICE LIST: MARCH | ZONE: TIRUPATTUR
| CODE | Item | Cost |
| 1 | A1 |
|
| 2 | NO.2 |
|
| 3 | NO.3 |
|
| 4 | NO.4 |
|
| 5 | Baby |
|
| 6 | 50g Chips |
|
| 7 | 500g Chips |
|
| 8 | Special Chips |
|
| 9 | 80g Chips |
|
| 10 | 500g No.3 |
|
| 11 | 75g No.3 |
|
| 12 | Super No.2 |
|
| 13 | Super No.3 |
|
| 14 | Super No.4 |
|
| 15 | 50g No.4 |
|
| 16 | 75g No.3 |


Conflict
Get MAD? ...nah
August 10, 2015
I’m not really a person who is quick to anger. When somebody does something that I find to be offensive, my first reaction is usually laughter. It’s likely a disarming mechanism or a coping mechanism but I won’t get into that now.
I can recall one instance in recent memory that made me quite upset. I was taking a trip with a few friends, we were on our way out of town, I made a wrong turn down a residential street and SMASH my windshield was suddenly shattered. I hadn’t seen anything strike the window, there weren’t any people or other cars around. After a brief moment of shock I pulled over and examined the damage, trying to find the point of impact. I briefly considered that I was struck by a small meteor. But nah. After examining the large spider web of cracks I found a white smudge with several dimples — a golfball had struck my windshield.
I had then realized that the large green field to my right was indeed a golf course. I felt like I couldn’t just shrug my shoulders and drive away. I decided to pull into the course to see what happened — it was partly a safety concern, as I had been driving through a residential area and there were no signs or nets to catch loose balls.
Anyway, I get to the golf course, luckily there was only one person there, so finding out who hit the ball wasn’t an issue. Turns out it was the manager, getting a few (terrible) swings in before opening. I guess, this would be the apex in the story. Had he just said, “oh yeah, it happens, sorry about that…” I probably would have just brushed it off to bad luck and drove away. Unfortunately, that did not happen, the manager was just so rude and combative, going as far as throwing personal attacks. At this point, I had not made any accusations, I simply told him what had happened. I was insulted and flustered, and I felt it… anger.
I asked why they don’t have nets to catch the balls, he said it would take away from the view. At no point in this conversation was the issue ever, who hit it, or, who is responsible. It was immediately, “too bad, now get off our property.”
I really didn’t know how to respond, so I left. I went home and actually decided to do the one thing that I knew how to do well, take him to court. I drove around with a broken windshield for 16 months, waiting for my court date. First case, I won. He appealed the decision; I won that too. I had only asked for the cost to repair the windshield, not a cent more. In the end, the judge ironically decided to award double damages because the respondent (the manager) was rude and belligerent during the whole preceding.
In the end, I learned that there are other ways of sticking up for yourself that don’t result in violence, but many situations could be diffused with a little bit of politeness and humility.
The look on his face as we left the courtroom though….


I’ll change your life dramatically.
Agh! I wish my Mom hadn’t shared this URL with you.
I won't change your life dramatically. You just have to say stuff like that these days. But if you check out some of the links here, you can see some of the early HTML and CSS I worked on (three weeks after I googled 'HTML'...). It might be a bit clunky, but for now this is a fast way to host basic personal content.
Thanks!


We are in a virtual free-fall, says Congress on GDP growth slip
by PTIThe Congress on Friday took a swipe at the BJP government over the GDP growth falling to 4.5 per cent, and said this is the lowest GDP recorded in six years.
Congress chief spokesperson Randeep Surjewala alleged that for the BJP, the GDP was “Godse Divisive Politics”. He was referring to the ongoing row surrounding a BJP MP’s remarks on Mahatma Gandhi’s assassin Nathuram Godse.
“India’s GDP has collapsed to an abysmal 4.5%. We are in a virtual free-fallWe are in a virtual free-fall. This is the lowest GDP quarter in 6 years. But why is the BJP celebrating? Because their understanding of GDP (Godse Divisive Politics) suggests double digit growth levels. All in the perspective,” he said on Twitter.
India’s economic growth slipped further to hit an over six-year low of 4.5 per cent in July-September, according to official data released on Friday.


--- layout: page title: Albums pgorder: 6 ---
Click on text links to access the photo albums.
UC Berkeley Campus
Europe
Twin-Cities, Minnesota
University of Minnesota Campus
Boundary Waters Canoe Area: Brule Lake


---
layout: post
title: 5/8
date: '2013-05-09T22:15:00.000-06:00'
author: Jacob .
tags:
modified_time: '2013-05-09T22:16:20.169-06:00'
blogger_id: tag:blogger.com,1999:blog-6400085873105072120.post-4156788655450451817
blogger_orig_url: http://www.svlark.com/2013/05/58.html
---
We have another showing tomorrow. One of these times...
I've been reading up on math curricula and the math wars. Singapore Math really appeals to me in that it uses direct instruction of basic math facts and continually builds. It's presented in a colorful, engaging format which I think Audrey will enjoy. I also looked into Saxon Math and Math-U-See. We'll definitely need to do more research on these.
227


Road to El Dorado Rated [PG], 87 minutes Starring Kevin Kline, Kenneth Branagh, Rosie Perez Screenplay by Ted Elliot & Terry Rossio Music by Elton John and Tim Rice Directed by Eric "Bibo" Bergeron and Don Paul website: www.roadtoeldorado.com
IN SHORT: A Splendid 'toon.
For those out there that aren't long time readers, Cranky's a 'toonhead. Loves animation. Almost wept when he had to sell a Gertie the Dinosaur cel to support this site (didn't 'cuz I had two). In general, of the post-Lion King run of animations from all the major studios, in general I hate the second banana characters and really don't have much temper for the multitude of songs that usually get in the way. Now that you're up to speed . . .
What's a Cranky Critic to do when there are no second banana characters -- to keep the kidlets giggling at the expense of grown up attentions -- to complain about? You know the type -- supporting monkeys or gargoyles or whatever that usually infest toons from the other "D" studio but less so from Dreamworks. You can blame or thank Jeffrey Katzenberg for this, he did oversee The Lion King and many others at the Mouse, and is the partner in charge of animation at Dreamworks SKG. The 'toons we've seen from them in the last couple of years, Antz and The Prince of Egypt have both aimed a wee bit higher, with more themes for the post thumb-sucking set and less base comedy for the kidlets. Cranky likes that.
This year's offering, The Road To El Dorado, upgrades the second banana type from support to lead and tries to duplicate the kind of chemistry that made Hope & Crosby (or Lemmon & Matthau) a good screen team. El Dorado tries and succeeds for the 'Works, delivering the most family friendly of all their 'toon output. I know 'cuz I saw El Dorado twice. Once with other critics, in preparation for StarTalk interviews with lead voices Kevin Kline and Kenneth Branagh. Again, on the biggest screen in New York, with an audience filled with media and their kidlets. The kidlets were cackling at stuff that makes kidlets cackle (don't ask me why) and the double entendre went right over their heads. The big screen effect is discussed a couple of inches down.
Branagh and Kline voice Tulio and Miguel, two Spanish con artists who, through every fault of their own, find themselves stowed away on the conquistador Cortez' flagship on its journey to the New World. Cortez (Jim Cummings) is searching for the legendary City of Gold called El Dorado and has no tolerance for the stowaways (who just happen to have a map to the city in their possession). The pair get washed overboard, along with Cortez' stallion Altivo (who never speaks a word but is "voiced" by the most expert and rightfully legendary Frank Welker) and make it to the New World ahead of Cortez.
We're not telling how. It's funny. As is the pair's personal search for El Dorado, which culminates in their finding it and being declared Gods by the Chief Priest of the City, Tzekel-Kan (Armand Assante), who is fighting a political battle with the Chief (Edward James Olmos) for control of the tribe. Their Protector and Partner in Crime is the lovely and equally greedy Chel (Rosie Perez) who tries to guide these nincompoops in the how-to of breaking the bank, and winds up breaking Tulio's heart. The interplay between Kline and Branagh's characters is incredibly funny and dead on target (Kline's the Crosby, btw) and both are topped by the vocal effects of Welker. To say the horse is smarter than both men put together is a fine compliment, indeed. As for the animation . . .
Let's talk honestly for a second. We all know the biggest market for all feature toons is the post bigscreen video market.  As I wrote, I saw The Road To El Dorado twice. First, on a screen that was probably the size of the bigger theaters in your local multiplex, which was enjoyable though some of the CGI/traditional animation mix onscreen seemed obvious. Second time was on a monstrosity of a screen with no such apparent "problem". While there have been notable improvements in the technology of background CGI character movement and water animation ('toonheads'll catch it all), the climax of the film, in which a boat with sail unfurled and filling with air evades a stone pillar crashing into the water behind it -- absolutely breathtaking.
If you've got a theater nearby with a screen the size of the side of a house, that's where you want to see The Road To El Dorado.
On average, a first run movie ticket will run you Eight Bucks. Were Cranky able to set his own price to The Road To El Dorado, he would have paid...
$6.75
Elton John and Tim Rice pick up their partnership where they left off on The Lion King, though they've just done Aida for Broadway as well. The songs in this flick are meant to narrate which they do better than entertain, though the opening title and the Kline/Branagh sung "It's Tough To Be A God" two (of five) are real toe-tappers. The radio hit runs during the end credits, so it doesn't count. Sorry.
Cranky Critic® is a Registered Trademark of, and Copyright © 2000 by, Chuck Schwartz. All Rights Reserved. Cranky on the web at www.crankycritic.com
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


SABB posts net profit of SR1,913m for 9 months
LuLu Hypermarket has signed an agreement with the National Center for Palms and Dates (NCPD) to promote Saudi-graded dates across its stores in the Kingdom.
The MoU was signed by Dr. Muhammed Al-Nowiran, CEO of NCPD, and Shehim Muhammed, director of LuLu Hypermarket Saudi Arabia, during the 38th Saudi Agricultural Exhibition.


{% extends "base.html" %} {% block heading %} {{super()}} {% endblock %} {% block content %}
MIBiG Data: As of Feb. 2017
* Our tool processes non-ribosomal peptide biosynthetic gene clusters after being identified using the AntiSMASH tool. In the process of scanning and identifying NRP BGCs, AntiSMASH uses three algorithms to predict the specificity of the NRPS adenylation domain (Minowa .et.al, Roettig, M et.al, Stachelhaus et.al). If all three algorithms agree on the same predicted substrate then it will be used as the substrate of choice by AntiSMASH, otherwise, AntiSMASH uses the term 'nrp' for all unidentified NRPS substrates. Hence, some IMLs may look as follows (e.g Ala-linker-Ser), if both substrates are well identified, others will look like (nrp-linker-Ser) or even sometimes (nrp-linker-nrp), with one or two unidentified substrates. Thus under each Data (MIBiG and NCBI), there are two tables, one where all linkers are included (larger data) and the other one lacks all "nrp containing linkers" (smaller data).


WARNING: This site requires JavaScript. Please visit
this guide
to learn how to enable JavaScript on your machine, then reload this page.


ABOUT
Creative
Strong preference for creative, easy to use and intuitive UX/UI.
Dynamic
Websites don't have to be static, I love making pages come to life.
Fast
Fast load times and lag free interaction, my highest priority.
Responsive
My layouts will work on any device, big or small.
Who am I?
I'am full-stack web developer. I have passion for designig and developing intuitive and dynamic UI and API. Together we can make dreams come true.


--- layout: page title: Lean Prover Zulip Chat Archive permalink: archive/113488general/93681offtopicarxivcollector.html ---
TIL: https://github.com/dougalsutherland/arxiv-collector
This script allowed me to upload a paper to the arxiv in 5 minutes! And I'm using biblatex etc...
It just generates a .tar.gz
with all the style files that you need etc... you upload the tar to the arxiv, and presto!
Do you have to prove the theorems?
No... there is built-in AI that does that for you :rolling_on_the_floor_laughing:
{% endraw %}


Quiz Score Earned
First Name
Competency
Points
Amit
QE
15
Ritika
Android
9
Swastik
iOS
19
Anam
MEAN
8


Methods
- L
- M
Included Modules
Instance Public methods
link_to_gfm(body, url, html_options = {})
Link
Use this in places where you would normally use link_to(gfm(…), …).
It solves a problem occurring with nested links (i.e. “outer text gfm ref more outer text”). This will not be interpreted as intended. Browsers will parse something like “outer text gfm ref more outer text” (notice the last part is not linked any more). #link_to_gfm corrects that. It wraps all parts to explicitly produce the correct linking behavior (i.e. “outer text gfm ref more outer text”).
Source: show
# File app/helpers/gitlab_markdown_helper.rb, line 13 def link_to_gfm(body, url, html_options = {}) return "" if body.blank? gfm_body = gfm(escape_once(body), html_options) gfm_body.gsub!(%r{.*?}) do |match| "#{match}#{link_to("", url, html_options)[0..-5]}" # "".length +1 end link_to(gfm_body.html_safe, url, html_options) end
markdown(text)
Link
Source: show
# File app/helpers/gitlab_markdown_helper.rb, line 25 def markdown(text) unless @markdown gitlab_renderer = Redcarpet::Render::GitlabHTML.new(self, # see https://github.com/vmg/redcarpet#darling-i-packed-you-a-couple-renderers-for-lunch- filter_html: true, with_toc_data: true, hard_wrap: true) @markdown = Redcarpet::Markdown.new(gitlab_renderer, # see https://github.com/vmg/redcarpet#and-its-like-really-simple-to-use no_intra_emphasis: true, tables: true, fenced_code_blocks: true, autolink: true, strikethrough: true, lax_html_blocks: true, space_after_headers: true, superscript: true) end @markdown.render(text).html_safe end


Interprets data values for Sampler.
More...
#include <Sampler.h>
|
| | SamplePicker (ReferenceMap &ref) |
| |
|
void | setSize (int w, int h) |
| |
|
virtual void | setPosition (int i, int j) const |
| | Sets current position in image coordinates. To be redefined to compute also geographical projections, for example.
|
| |
|
virtual void | writeHeader (char commentPrefix, std::ostream &ostr) const |
| | Optional utility. Called prior to writing the actual data to output stream.
|
| |
Interprets data values for Sampler.
A Sampler instance moves a SamplePicker instance by calling its setLocation(). Then, calls its getValue(). SamplePicker picks and scales invidual values, checks their validity and so on.
- Parameters
-
| ref | - flexible container in which the values in each location will be written. |
The documentation for this struct was generated from the following file:


Quantico
Quantico is about a diverse group of recruits that have arrived at the FBI Quantico Base for training. They are the best, the brightest and the most vetted, so it seems impossible that one of them is suspected of masterminding the biggest attack on New York City since 9/11.


MOTD will print a reminder each time a Loft Deploy action is executed; use it to keep track of reminders about your project. Here's how:
Create a file in your project, .loft_deploy/motd
, the contents of which is echoed when you run any loft_deploy command. This is a way to store reminders per project.


test text
Test Link
sfjsdhfk js f jskjhfaksjhdf jhaskdjhfakjshf kahsdkjfhkjsdhkfjhaskdjhfkjahsdk fjhkjsahfkja hsdkfjhaksjdhfkaj shdfkjahsdk fjhaskjdhfk ajshdkfjahsdkjfha skjdhf kjasdfhkjashdf kjahsdfkja skjdfhak sdfhk
test text
Test Link
test text
Test Link
sfjsdhfk js f jskjhfaksjhdf jhaskdjhfakjshf kahsdkjfhkjsdhkfjhaskdjhfkjahsdk fjhkjsahfkja hsdkfjhaksjdhfkaj shdfkjahsdk fjhaskjdhfk ajshdkfjahsdkjfha skjdhf kjasdfhkjashdf kjahsdfkja skjdfhak sdfhk
test text
Test Link
test text
Test Link
sfjsdhfk js f jskjhfaksjhdf jhaskdjhfakjshf kahsdkjfhkjsdhkfjhaskdjhfkjahsdk fjhkjsahfkja hsdkfjhaksjdhfkaj shdfkjahsdk fjhaskjdhfk ajshdkfjahsdkjfha skjdhf kjasdfhkjashdf kjahsdfkja skjdfhak sdfhk
test text
Test Link
test text
Test Link
sfjsdhfk js f jskjhfaksjhdf jhaskdjhfakjshf kahsdkjfhkjsdhkfjhaskdjhfkjahsdk fjhkjsahfkja hsdkfjhaksjdhfkaj shdfkjahsdk fjhaskjdhfk ajshdkfjahsdkjfha skjdhf kjasdfhkjashdf kjahsdfkja skjdfhak sdfhk
test text
Test Link
test text
Test Link
sfjsdhfk js f jskjhfaksjhdf jhaskdjhfakjshf kahsdkjfhkjsdhkfjhaskdjhfkjahsdk fjhkjsahfkja hsdkfjhaksjdhfkaj shdfkjahsdk fjhaskjdhfk ajshdkfjahsdkjfha skjdhf kjasdfhkjashdf kjahsdfkja skjdfhak sdfhk
test text
Test Link
test text
Test Link
sfjsdhfk js f jskjhfaksjhdf jhaskdjhfakjshf kahsdkjfhkjsdhkfjhaskdjhfkjahsdk fjhkjsahfkja hsdkfjhaksjdhfkaj shdfkjahsdk fjhaskjdhfk ajshdkfjahsdkjfha skjdhf kjasdfhkjashdf kjahsdfkja skjdfhak sdfhk
test text
Test Link


Info |
Log |
Video |
| Player ( ${playerScore} ) | Banker ( ${bankerScore} ) | |
| ${playerWinMsg} | ${bankerWinMsg} |
| Bahar | Joker | Andar |
|
|
|
| Player A | Player B | |
|
|
|


Mandor Mountains [au27], mountain, in Mandoria, wilderness
Last updated Turn #79
Mandor Mountains [au27], mountain, in Mandoria, wilderness
------------------------------------------------------------------------
10: Jupiter [m8j], Imperial Empire, with 19 soldiers, 21 pikemen, arrived
10: from the east, accompanied by:
10: Odin [y5z], Imperial Empire, with 25 lt. xbowmen
10: Zeus [y7k], Imperial Empire, the High Priest of the Church of
10: Kireus [156], with nine peasants, seven soldiers, ten angels,
10: 11 skirmishers
10: Hera [g3f], Imperial Empire, with three soldiers, eight pikemen,
10: one riding horse
10: Thor [r4g], Imperial Empire, with seven soldiers, eight pikemen
10: Apollo [b5e], Imperial Empire, with two soldiers, 12 pikemen
10: Helios [p6i], Imperial Empire, with four soldiers, eight pikemen
10: Eos [a2t], Imperial Empire, with 21 skirmishers
10: Aryon [t6i], Imperial Empire, with two peasants, 20 lt. xbowmen
10: Lanthara [r4v], Imperial Empire, with two peasants, three soldiers
10: Licia [i1l], Imperial Empire, with two peasants, ten soldiers,
10: nine pikemen
10: Thrix [n3v], Imperial Empire, with two peasants, 17 lt. xbowmen
10: Amanda [s7m], Imperial Empire, with two peasants, eight soldiers
10: Klaus [u5x], Imperial Empire, with two peasants, 18 lt. xbowmen
11: Band of thieves [jm2x], bandits, number: 74, went west.
11: Pack of wolves [iw7b], wolves, number: 13, went south.
11: Pack of wolves [ir0u], wolves, number: 8, went east.
11: Pack of wolves [bv8w], wolves, number: 10, went west.
11: Pack of wolves [il8d], wolves, number: 15, went west.
11: Jupiter [m8j], Imperial Empire, with 19 soldiers, 21 pikemen, went
11: west, accompanied by:
11: Odin [y5z], Imperial Empire, with 25 lt. xbowmen
11: Zeus [y7k], Imperial Empire, the High Priest of the Church of
11: Kireus [156], with nine peasants, eight soldiers, ten angels,
11: ten skirmishers
11: Hera [g3f], Imperial Empire, with two soldiers, nine pikemen,
11: one riding horse
11: Thor [r4g], Imperial Empire, with six soldiers, nine pikemen
11: Apollo [b5e], Imperial Empire, with one soldier, 13 pikemen
11: Helios [p6i], Imperial Empire, with three soldiers, nine pikemen
11: Eos [a2t], Imperial Empire, with 21 skirmishers
11: Aryon [t6i], Imperial Empire, with two peasants, 20 lt. xbowmen
11: Lanthara [r4v], Imperial Empire, with two peasants, three soldiers
11: Licia [i1l], Imperial Empire, with two peasants, ten soldiers,
11: nine pikemen
11: Thrix [n3v], Imperial Empire, with two peasants, 17 lt. xbowmen
11: Amanda [s7m], Imperial Empire, with two peasants, eight soldiers
11: Klaus [u5x], Imperial Empire, with two peasants, 18 lt. xbowmen
11: Horde of rats [dd4v], rats, number: 50, arrived from the west.
11: Pack of wolves [an6d], wolves, number: 9, arrived from the north.
11: Pack of wolves [ds6d], wolves, number: 10, arrived from the east.
12: Pack of wolves [ag2b], wolves, number: 12, went north.
12: Pack of wolves [bc6l], wolves, number: 11, arrived from the south.
12: Pack of wolves [cv2y], wolves, number: 12, arrived from the east.
12: Pack of wolves [jr1h], wolves, number: 11, arrived from the east.
12: Pack of wolves [fs7p], wolves, number: 15, arrived from the west.
13: Horde of rats [dd4v], rats, number: 50, went east.
13: Pack of wolves [an6d], wolves, number: 9, went south.
13: Pack of wolves [ds6d], wolves, number: 10, went west.
13: Pack of wolves [fc3a], wolves, number: 9, arrived from the east.
13: Pack of wolves [bh6r], wolves, number: 11, arrived from the east.
14: Pack of wolves [bc6l], wolves, number: 11, went north.
14: Pack of wolves [cv2y], wolves, number: 12, went west.
14: Pack of wolves [jr1h], wolves, number: 11, went west.
14: Pack of wolves [fs7p], wolves, number: 15, went east.
14: Pack of wolves [hb5h], wolves, number: 11, arrived from the west.
15: Pack of wolves [fc3a], wolves, number: 9, went west.
15: Pack of wolves [bh6r], wolves, number: 11, went west.
15: Pack of wolves [by1s], wolves, number: 13, arrived from the north.
15: Pack of wolves [dz1l], wolves, number: 9, arrived from the south.
15: Pack of wolves [ht4a], wolves, number: 16, arrived from the south.
16: Pack of wolves [hb5h], wolves, number: 11, went east.
16: Pack of wolves [im6o], wolves, number: 14, arrived from the south.
16: Pack of wolves [cc1l], wolves, number: 9, arrived from the west.
16: Pack of wolves [ds0p], wolves, number: 11, arrived from the east.
17: Pack of wolves [by1s], wolves, number: 13, went south.
17: Pack of wolves [dz1l], wolves, number: 9, went north.
17: Pack of wolves [ht4a], wolves, number: 16, went north.
17: Pack of wolves [ca0f], wolves, number: 13, arrived from the south.
17: Pack of wolves [cs0p], wolves, number: 9, arrived from the east.
18: Pack of wolves [im6o], wolves, number: 14, went north.
18: Pack of wolves [cc1l], wolves, number: 9, went east.
18: Pack of wolves [ds0p], wolves, number: 11, went west.
18: Pack of wolves [jn0n], wolves, number: 10, arrived from the south.
18: Pack of wolves [dy9v], wolves, number: 12, arrived from the west.
18: Pack of wolves [da2k], wolves, number: 11, arrived from the east.
19: Pack of wolves [ca0f], wolves, number: 13, went north.
19: Pack of wolves [cs0p], wolves, number: 9, went west.
19: Pack of wolves [fu1w], wolves, number: 12, arrived from the north.
19: Pack of wolves [im9q], wolves, number: 11, arrived from the east.
19: Pack of wolves [dc9v], wolves, number: 13, arrived from the east.
19: Pack of wolves [ay4o], wolves, number: 10, arrived from the east.
19: Pack of wolves [ip0w], wolves, number: 14, arrived from the east.
20: Pack of wolves [jn0n], wolves, number: 10, went north.
20: Pack of wolves [dy9v], wolves, number: 12, went east.
20: Pack of wolves [da2k], wolves, number: 11, went south.
20: Pack of wolves [by2p], wolves, number: 11, arrived from the east.
21: Pack of wolves [fu1w], wolves, number: 12, went south.
21: Pack of wolves [im9q], wolves, number: 11, went west.
21: Pack of wolves [dc9v], wolves, number: 13, went west.
21: Pack of wolves [ay4o], wolves, number: 10, went west.
21: Pack of wolves [ip0w], wolves, number: 14, went west.
21: Pack of wolves [du4v], wolves, number: 11, arrived from the east.
22: Pack of wolves [by2p], wolves, number: 11, went west.
22: Pack of wolves [ii0f], wolves, number: 10, arrived from the north.
22: Pack of wolves [ce7i], wolves, number: 10, arrived from the south.
22: Pack of wolves [iz5b], wolves, number: 14, arrived from the south.
22: Pack of wolves [dk0y], wolves, number: 16, arrived from the north.
22: Pack of wolves [jf1l], wolves, number: 12, arrived from the west.
22: Pack of wolves [ah2z], wolves, number: 10, arrived from the west.
22: Pack of wolves [ec7q], wolves, number: 13, arrived from the east.
22: Pack of wolves [jq4e], wolves, number: 11, arrived from the east.
23: Pack of wolves [du4v], wolves, number: 11, went west.
23: Pack of wolves [ah3a], wolves, number: 11, arrived from the south.
23: Pack of wolves [dg7v], wolves, number: 11, arrived from the east.
24: Pack of wolves [ii0f], wolves, number: 10, went south.
24: Pack of wolves [ce7i], wolves, number: 10, went north.
24: Pack of wolves [iz5b], wolves, number: 14, went north.
24: Pack of wolves [dk0y], wolves, number: 16, went south.
24: Pack of wolves [jf1l], wolves, number: 12, went east.
24: Pack of wolves [ah2z], wolves, number: 10, went east.
24: Pack of wolves [ec7q], wolves, number: 13, went west.
24: Pack of wolves [jq4e], wolves, number: 11, went west.
24: Pack of wolves [fq7k], wolves, number: 8, arrived from the south.
24: New noble [d8r], refugee, arrived from the east.
24: Pack of wolves [it0y], wolves, number: 10, arrived from the east.
24: Pack of wolves [aq0s], wolves, number: 10, arrived from the east.
25: Pack of wolves [ah3a], wolves, number: 11, went north.
25: Pack of wolves [dg7v], wolves, number: 11, went west.
25: Band of thieves [at5c], bandits, number: 52, arrived from the west.
25: Pack of wolves [cl9w], wolves, number: 12, arrived from the south.
25: Pack of wolves [hd6k], wolves, number: 9, arrived from the east.
26: Pack of wolves [fq7k], wolves, number: 8, went north.
26: Pack of wolves [it0y], wolves, number: 10, went west.
26: Pack of wolves [aq0s], wolves, number: 10, went west.
26: Horde of rats [ez6y], rats, number: 41, arrived from the east.
26: Pack of wolves [fi7i], wolves, number: 9, arrived from the east.
27: New noble [d8r], refugee, went west.
27: Band of thieves [at5c], bandits, number: 52, went east.
27: Pack of wolves [cl9w], wolves, number: 12, went north.
27: Pack of wolves [hd6k], wolves, number: 9, went west.
27: Pack of wolves [jk5x], wolves, number: 12, arrived from the south.
27: Pack of wolves [by1s], wolves, number: 13, arrived from the south.
27: Pack of wolves [hp6j], wolves, number: 11, arrived from the west.
27: Pack of wolves [js6a], wolves, number: 9, arrived from the west.
28: Horde of rats [ez6y], rats, number: 41, went west.
28: Pack of wolves [fi7i], wolves, number: 9, went west.
28: Pack of wolves [ef2y], wolves, number: 10, arrived from the south.
28: Pack of wolves [ij1z], wolves, number: 10, arrived from the south.
29: Pack of wolves [jk5x], wolves, number: 12, went north.
29: Pack of wolves [by1s], wolves, number: 13, went north.
29: Pack of wolves [hp6j], wolves, number: 11, went east.
29: Pack of wolves [js6a], wolves, number: 9, went east.
29: Horde of rats [im0x], rats, number: 33, arrived from the south.
29: Pack of wolves [ak0u], wolves, number: 10, arrived from the north.
29: Pack of wolves [gy8u], wolves, number: 9, arrived from the east.
29: Pack of wolves [ej3y], wolves, number: 12, arrived from the east.
29: Pack of wolves [hj7a], wolves, number: 11, arrived from the west.
30: Pack of wolves [ef2y], wolves, number: 10, went north.
30: Pack of wolves [ij1z], wolves, number: 10, went north.
30: It has stopped raining.
Routes leaving Mandor Mountains:
North, mountain, to Mandor Mountains [at27], 10 days
East, mountain, to Mandor Mountains [au28], 10 days
South, mountain, to Mandor Mountains [av27], 10 days
West, mountain, to Mandor Mountains [au26], 10 days
Seen here:
New noble [d8r], refugee
Band of thieves [at5c], bandits, number: 52
Pack of wolves [cl9w], wolves, number: 12
Pack of wolves [hd6k], wolves, number: 9
Horde of rats [ez6y], rats, number: 41
Pack of wolves [fi7i], wolves, number: 9
Pack of wolves [jk5x], wolves, number: 12
Pack of wolves [by1s], wolves, number: 13
Pack of wolves [hp6j], wolves, number: 11
Pack of wolves [js6a], wolves, number: 9
Pack of wolves [ef2y], wolves, number: 10
Pack of wolves [ij1z], wolves, number: 10
Horde of rats [im0x], rats, number: 33
Pack of wolves [ak0u], wolves, number: 10
Pack of wolves [gy8u], wolves, number: 9
Pack of wolves [ej3y], wolves, number: 12
Pack of wolves [hj7a], wolves, number: 11


HTML5 Boilerplate homepage | Documentation table of contents
Once you have cloned or downloaded HTML5 Boilerplate, creating a site or app usually involves the following:
A basic HTML5 Boilerplate site initially looks something like this:
.
├── css
│ ├── main.css
│ └── normalize.css
├── doc
├── img
├── js
│ ├── main.js
│ ├── plugins.js
│ └── vendor
│ ├── jquery.min.js
│ └── modernizr.min.js
├── .editorconfig
├── .htaccess
├── 404.html
├── apple-touch-icon.png
├── browserconfig.xml
├── index.html
├── humans.txt
├── robots.txt
├── crossdomain.xml
├── favicon.ico
├── tile-wide.png
└── tile.png
What follows is a general overview of each major part and how to use them.
This directory should contain all your project's CSS files. It includes some initial CSS to help get you started from a solid foundation. About the CSS.
This directory contains all the HTML5 Boilerplate documentation. You can use it as the location and basis for your own project's documentation.
This directory should contain all your project's JS files. Libraries, plugins, and custom code can all be included here. It includes some initial JS to help get you started. About the JavaScript.
The default web server configs are for Apache. For more information, please refer to the Apache Server Configs repository.
Host your site on a server other than Apache? You're likely to find the corresponding server configs project listed in our Server Configs repository.
A helpful custom 404 to get you started.
This file contains all settings regarding custom tiles for IE11.
For more info on this topic, please refer to MSDN.
The .editorconfig
file is provided in order to encourage and help you and your team to maintain consistent coding styles between different editors and IDEs. Read more about the .editorconfig
file.
This is the default HTML skeleton that should form the basis of all pages on your site. If you are using a server-side templating framework, then you will need to integrate this starting HTML with your setup.
Make sure that you update the URLs for the referenced CSS and JavaScript if you modify the directory structure at all.
If you are using Google Universal Analytics, make sure that you edit the corresponding snippet at the bottom to include your analytics ID.
Edit this file to include the team that worked on your site/app, and the technology powering it.
Edit this file to include any pages you need hidden from search engines.
A template for working with cross-domain requests. About crossdomain.xml.
Replace the default favicon.ico
, tile.png
, tile-wide.png
and Apple Touch Icon with your own.
If you want to use different Apple Touch Icons for different resolutions please refer to the according documentation.
You might want to check out Hans' handy HTML5 Boilerplate Favicon and Apple Touch Icon PSD-Template.


#twitchAffiliate #Livestreamer, #Youtuber, #DM, #RolePlayer, and #Nerd Culture activist. #Game #Developer For Requiem: The Tabletop Game. #Critter #Writer.


Cover
Cover Background
Fixed Height
Text
Responsive Height
Text
Viewport Height
Text
Cover Object
Image Fixed Height
Text
Video Fixed Height
Text
Responsive Height
Text
Viewport Height
Text
Cover Iframes
Youtube Fixed Height
Text
Vimeo Fixed Height
Text
Responsive Height
Text
Viewport Height
Text


SkillCademy is a student based online website that enables the students to view some of the common units taught in the University by creating that visual impact on the concept being taught to the student. With that it bring out the idea of virtual reality. Most of its concept is potrayed via animation video clips audiobooks and interactive cardboard.
Whether you're an undergraduate student or a post graduate student looking for the best education site to learn from and master the concept then SkillCademy is your search for the best information site with plenty of animated ideas and concepts. For more information download our application via google playstore. Find the link below
Introduction
Virtual Reality (VR) has been a popular subject in science fiction for decades, but we are now witnessing the moment that VR is going to have a vast impact on the world. By simply putting on a headset users can experience a different reality that feels completely authentic. This exciting new seemingly limitless possibilities in many companies and industries across the economic landscape. For instance, education, the military, healthcare, infrastructure, or the oil sector could use technology to train personel and educate the workforce
Where Did It All Begin?
The History Of VR
An Education Model For The Information Age
Teachers have tried to teaching their students by introducing text books along with verbal instructions in traditional education system, this has however reached its limit in the current fast paced world of Information age. Teaching and learning methods could be changed for developing Information and Communication Technology (ICT). Its time to adapt students with interactive learning system so that they can improve their learning, comprehension, memorizing and recall capabilities. It is therefore indispensable to create high quality and realistic learning environment for the student in East Africa thereby catapulting us to the information age whilst preparing our learnerss for the digital age
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Mollitia neque assumenda ipsam nihil, molestias magnam, recusandae quos quis inventore quisquam velit asperiores, vitae? Reprehenderit soluta, eos quod consequuntur itaque. Nam.
Close ProjectLorem ipsum dolor sit amet, consectetur adipisicing elit. Mollitia neque assumenda ipsam nihil, molestias magnam, recusandae quos quis inventore quisquam velit asperiores, vitae? Reprehenderit soluta, eos quod consequuntur itaque. Nam.
Close ProjectLorem ipsum dolor sit amet, consectetur adipisicing elit. Mollitia neque assumenda ipsam nihil, molestias magnam, recusandae quos quis inventore quisquam velit asperiores, vitae? Reprehenderit soluta, eos quod consequuntur itaque. Nam.
Close ProjectLorem ipsum dolor sit amet, consectetur adipisicing elit. Mollitia neque assumenda ipsam nihil, molestias magnam, recusandae quos quis inventore quisquam velit asperiores, vitae? Reprehenderit soluta, eos quod consequuntur itaque. Nam.
Close Project


Use sliders on the right, to style the image, css rules are generated below. For use in modern browsers.


RT @RubyVillains: Has someone in the Ruby community made you laugh with astonishment and delight? Changed how you look at code?
http://t.c…
4/24/2015, 6:25:09 PM
Favs: 0
Retweets: 0
link--- layout: tweet ---
RT @RubyVillains: Has someone in the Ruby community made you laugh with astonishment and delight? Changed how you look at code?
http://t.c…
4/24/2015, 6:25:09 PM
Favs: 0
Retweets: 0
link


The Chicago Boss API is mostly stable, but still might change before 1.0.
Chicago Boss provides an API for sending emails using Django templates and custom controller logic. No SMTP configuration or server is necessary. Mail controller logic should go into mail/mail_controller.erl
in your project directory, and templates should go into mail/view/
. To send an email from a web controller, call:
That will invoke mail_controller:foo_message(Arg1, Arg2, ...)
and use the return value to populate the templates mail/view/foo_message.txt
and mail/view/foo_message.html
, then send the email in a background process. Your mail controller function should return:
{ok, FromAddress, ToAddress, HeaderFields, Variables} |
nevermind
If the return value is nevermind
, no email will be sent. Otherwise,
FromAddress
is the sender's email address. The address should not be in "friendly" form, i.e<EMAIL_ADDRESS>is OK, but "Kai Foo<EMAIL_ADDRESS>is not.ToAddress
is recipient's email address.HeaderFields
is a proplist of email header fields, e.g.[{"From", "SECRETARY TO CHARLES TAYLOR<EMAIL_ADDRESS>{"Subject", "Unclaimed Lottery Winnings"}]
. If you want the From: and To: fields to appear in the message, you need to provide values here; they will not be taken fromFromAddress
andToAddress
. However, the header fields for Message-ID: and Date: will be populated automatically if not provided.Variables
(if present) will be passed to the associated Django template(s), which will form the body of the message.
Formatting. If templates ending only in ".txt" are present, the message will be sent in plain-text; if templates ending only in ".html" are present, the message will be sent as HTML; but if both ".txt" and ".html" templates are present, the message will be sent as a a MIME multi-part message with alternative plain-text and HTML representations.
I18n. To use Chicago Boss's i18n machinery in emails, specify the desired language in the "Content-Language" header field returned from the mail controller.


friedjuju examples:
Pick from any of these examples:
Mapping JSON to Markup
Mapping JSON on the web client to markup example
Mapping JSON on the web client to markup using a Virtual DOM example
Mapping JSON on the server to markup example
Mapping JSON using only dotted expressions on the web client to markup example
Mapping JSON to JSON (changing structure)
Mapping JSON on the web client to other JSON example
Mapping JSON on the server to other JSON example
Querying JSON example
Sample pages that actually use j2m to render themselves
Sample page that uses j2m to render itself
Sample page that uses j2m components to render views
Sample page that uses j2m components with j2j to render views


The family Gavialidae contains only the gharials. There is currently only one species, the Indian Gharial, and it lives in the deep, fast flowing rivers of Northern India. Due to habitat destruction and humans collecting the eggs for food, it is critically endangered. Gharials have long narrow jaws and are very social. They spend most of their time in the water and subsist almost entirely on fish.