What is Bluprint?
Bluprint is a customizable minimalistic responsive CSS grid packed with multiple useful helper classes and generators.
- Responsive CSS grid (as in Bootstrap or Foundation).
- Easily customizable grid, tiers and class names.
- Lightweight (<1KB gzipped).
- Helper classes for responsive visibility, paddings, resets.
- Generators to create stylish buttons.
Installation
Step 1
Option A
Install Bluprint via NPM or Yarn:
npm i bluprint.css
yarn add bluprint.css
Option B
You can also manually download and unzip the package:
Step 2
Finally, include the CSS in your page
section.
<link rel="stylesheet" href="dist/normalize.min.css">
<link rel="stylesheet" href="dist/bluprint.min.css">
Normalize.css is not mandatory but highly recommended: this library is used to reduce cross-browser rendering inconsistency.
CDN
Alternatively, you can include the CSS via CDN without downloading or installing any local files:
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/normalize/7.0.0/normalize.min.css">
<link rel="stylesheet" href="https://gitcdn.link/repo/kefir500/bluprint/master/dist/bluprint.min.css">
Grid
Rows
The conception of grid is pretty straightforward: it consists of containers called rows (.row
).
Rows, in turn, are wrappers for columns (.col
).
Tiers
Tiers are based on screen size ranges and used for responsive column stacking.
The default grid layout consists of 12 columns. Your block can take any amount of these columns from 1 to 12 accordingly. For responsive layouts different number of columns can be taken for the specific screen size:
.xs-*
takes*
columns on any screen..sm-*
takes*
columns on screens ≥768px wide..md-*
takes*
columns on screens ≥992px wide..lg-*
takes*
columns on screens ≥1200px wide.*
is a number of columns to occupy from 1 to 12.
The screen size classes are applied (and being overridden) from smaller to bigger ones.
These tiers as well as the grid layout can be easily customized according to your needs.
Fixed Columns
The following blocks take the fixed amount of columns on different screen sizes.
HTML

Demo
Responsive Columns
The following example demonstrates the responsive layout where each block takes the specified number of columns on different screens:
- 12 columns (of 12) on
xs
(extra small) screens. - 6 columns (of 12) on
sm
(small) screens. - 4 columns (of 12) on
md
(medium) screens (except for the first column). - 3 columns (of 12) on
lg
(large) screens.
Columns stack depending on the current screen size. Try resizing your browser window.
HTML

Demo
Nested Columns
Columns can be nested in multiple levels. Wrap each level in a .row
class in order to zero out the inner padding.
HTML

Demo
Customization
In order to customize the grid tiers / columns number, size / generate button classes,
run npm install
in the root directory to install the required dependencies.
Then you can simply edit the scss/_config.scss
file and build your CSS file with gulp build
command.
For better understanding of the following variables read the Tiers section.
Variables
| Variable | Description | Default |
|---|---|---|
$grid-columns |
Number of columns in a layout row. | 12 |
$grid-gutter |
Half-width of a gap between columns. | 8px |
$class-row |
Base class name for a row container. | row |
$class-column-base |
Base class name for columns. | col |
$class-column-responsive |
Class name pattern for responsive columns.
|
[TIER]-[SIZE] |
Tiers
The $tiers
map contains tiers which respresent the screen size breakpoints for stacking responsive columns.
The corresponding classes are generated based on this variable.
$tiers: (
xs: 0,
sm: 768,
md: 992,
lg: 1200
);
| Tier | Screen size |
|---|---|
xs |
≥ 0 |
sm |
≥ 768 |
md |
≥ 992 |
lg |
≥ 1200 |
Example
You can create any number of screen size tiers with your own names and breakpoints according to your needs, for example:
$tiers: (
mobile: 0,
tablet: 700,
laptop: 1200,
desktop: 1600
);
Buttons
You can also generate stylish flat buttons with automatically calculated hover and click effects.
SCSS
$buttons: (
primary: #1a98ff,
success: #76bd42,
danger: #e65e57
);
HTML
Primary
Success
Danger
If you don't need any buttons, simply remove this variable.


Russolo refers to the chord as the "complete sound,"[3] the conception of various parts that make and are subordinate to the whole. He notes that chords developed gradually, first moving from the "consonant triad to the consistent and complicated dissonances that characterize contemporary music."[3] He notes that while early music tried to create sweet and pure sounds, it progressively grew more and more complex, with musicians seeking to create new and more dissonant chords. This, he says, comes ever closer to the "noise-sound."


Quarterly Goals, OKRs and Development
This information evolves as new initiatives evolve and is subject to (potentially frequent) change.
- Quarterly goal should be sized to be executed in roughly 6 weeks.
- Goals will be developed with guidance from the Director taking into account current priorities and needs.
- Goals should be entered in Betterworks and properly aligned with team goals as needed prior to the beginning of the quarter. Exact dates for relevant meetings, dates, etc. will be provided by PM.
- Updates to percentages and comments are to be entered in Betterworks monthly, at a minimum.
In addition to quarterly goals and OKRs, each staff member will have a personal development plan. These are reviewed and updated quarterly. It is the responsibility of each team member to complete these and review with the director of security. The purpose of this development plan is to help inform areas where each team member would like to grow.


Home
Our Community
Join us
About us
Create your own Profile!


Use dataContainer and property XML attributes to connect a time field to an entity attribute.
dataContainer
property


Contact Us
Store Information
Store Address:
Texas State University Bookstore
601 University Dr.
San Marcos, Tx 78666
Phone Number:<PHONE_NUMBER>
Phone Number:<PHONE_NUMBER>
Email:
<EMAIL_ADDRESS>Driving Directions
FROM IH-35 NORTH (Austin)
Take exit 206, travel West on Aquarena Springs. After crossing the San Marcos River you will come to a traffic light. Turn right onto Sessom Drive. Go to the top of the hill and turn left at Comanche Street. Turn left at the first street (Student Center Drive). Turn right before the stop sign to enter the public parking garage. For a detailed map to the parking garage go to the Student Center Parking Garage campus map.
FROM IH-35 SOUTH (San Antonio)
Take exit 206, travel West on Aquarena Springs. After crossing the San Marcos River you will come to a traffic light. Turn right onto Sessom Drive. Go to the top of the hill and turn left at Comanche Street. Turn left at the first street (Student Center Drive). Turn right before the stop sign to enter the public parking garage. For a detailed map to the parking garage go to the Student Center Parking Garage campus map.
FROM HWY. 123 (Seguin)
When you reach the Interstate, take IH-35 North and exit at 206. Follow the directions above from San Antonio.
FROM HWY. 80 & IH-10 (Houston)
When you reach the Interstate, take IH-35 North and exit at 206. Follow the directions above from San Antonio.


If you're new to Mesos
See the getting started page for more information about downloading, building, and deploying Mesos.
If you'd like to get involved or you're looking for support
See our community page for more details.
Task Health Checking
Sometimes applications crash, misbehave, or become unresponsive. To detect and recover from such situations, some frameworks (e.g., Marathon, Apache Aurora) implement their own logic for checking the health of their tasks. This is typically done by having the framework scheduler send a “ping” request, e.g., via HTTP, to the host where the task is running and arranging for the task or executor to respond to the ping. Although this technique is extremely useful, there are several disadvantages in the way it is usually implemented:
- Each Mesos framework uses its own API and protocol.
- Framework developers have to reimplement common functionality.
- Health checks originating from a scheduler generate extra network traffic if the task and the scheduler run on different nodes (which is usually the case); moreover, network failures between the task and the scheduler may make the latter think that the former is unhealthy, which might not be the case.
- Implementing health checks in the framework scheduler can be a performance bottleneck. If a framework is managing a large number of tasks, performing health checks for every task can cause scheduler performance problems.
To address the aforementioned problems, Mesos 1.2.0 introduces the Mesos-native health check design, defines common API for command, HTTP(S), and TCP health checks, and provides reference implementations for all built-in executors.
NOTE: Some functionality related to health checking was available prior to 1.2.0 release, however it was considered experimental.
NOTE: Mesos monitors each process-based task, including Docker containers,
using an equivalent of a waitpid()
system call. This technique allows
detecting and reporting process crashes, but is insufficient for cases when the
process is still running but is not responsive.
This document describes supported health check types, touches on relevant implementation details, and mentions limitations and caveats.
Mesos-native Health Checks
In contrast to the state-of-the-art “scheduler health check” pattern mentioned above, Mesos-native health checks run on the agent node: it is the executor which performs checks and not the scheduler. This improves scalability but means that detecting network faults or task availability from the outside world becomes a separate concern. For instance, if the task is running on a partitioned agent, it will still be health checked and—if those health checks fail—will be terminated. Needless to say that due to the network partition, all this will happen without the framework scheduler being notified.
Task status updates are leveraged to transfer the health check status to the
Mesos master and further to the framework’s scheduler ensuring the
“at-least-once” delivery guarantee. The boolean healthy
field is used to
convey health status, which may be insufficient in
certain cases. This means a task that has failed health checks will be RUNNING
with healthy
set to false
. Currently, the healthy
field is only set for
TASK_RUNNING
status updates.
When a task turns unhealthy, a task status update message with the healthy
field set to false
is sent to the Mesos master and then forwarded to a
scheduler. The executor is expected to kill the task after a number of
consecutive failures defined in the consecutive_failures
field of the
HealthCheck
protobuf.
NOTE: While a scheduler currently cannot cancel a task kill due to failing
health checks, it may issue a killTask
command itself. This may be helpful to
emulate a “global” policy for handling tasks with failing health checks (see
limitations).
Built-in executors forward all unhealthy status updates, as well as the first healthy update when a task turns healthy, i.e., when the task has started or after one or more unhealthy updates have occurred. Note that custom executors may use a different strategy.
Custom executors can use the health checker library, the reference implementation for health checking all built-in executors rely on.
Anatomy of a Health Check
Mesos health checks are described in the
HealthCheck
protobuf. Currently, only tasks can be health checked, not arbitrary processes
or executors, i.e., only the TaskInfo
protobuf has the optional HealthCheck
field. However, it is worth noting that all built-in executors map a task to a
process.
It is an executor’s responsibility to health check its tasks, because only
executor knows how to interpret TaskInfo
. All built-in executors support
health checking their tasks (see implementation details
and limitations).
NOTE: It is up to the executor how—and whether at all—to honor
the HealthCheck
field in TaskInfo
. Implementations may vary significantly
depending on what entity TaskInfo
represents. In this section only the
reference implementation for built-in executors is considered.
Command Health Checks
Command health checks are described by the CommandInfo
protobuf; some fields
are ignored though: CommandInfo.user
and CommandInfo.uris
. A command health
check specifies an arbitrary command that is used to validate the health of the
task. The executor launches the command and inspects its exit status: 0
is
treated as success, any other status as failure.
NOTE: If a task is a Docker container launched by the docker executor, it
will be wrapped in docker run
. For all other tasks, including Docker
containers launched in the mesos containerizer, the
command will be executed from the task’s mount namespace.
To specify a command health check, set type
to HealthCheck::COMMAND
and
populate CommandInfo
, for example:
HealthCheck healthCheck;
healthCheck.set_type(HealthCheck::COMMAND);
healthCheck.mutable_command()->set_value("ls /checkfile > /dev/null");
task.mutable_health_check()->CopyFrom(healthCheck);
HTTP(S) Health Checks
HTTP(S) health checks are described by the HealthCheck.HTTPCheckInfo
protobuf
with scheme
, port
, path
, and statuses
fields. A GET
request is sent to
scheme://<host>:port/path
using the curl
command. Note that <host>
is
currently not configurable and is resolved automatically to <IP_ADDRESS>
(see
limitations). The scheme
field supports "http"
and
"https"
values only. Field port
must specify an actual port the task is
listening on, not a mapped one.
Built-in executors treat status codes between 200
and 399
as success; custom
executors may employ a different strategy, e.g., leveraging the statuses
field.
NOTE: Setting HealthCheck.HTTPCheckInfo.statuses
has no effect on the
built-in executors.
If necessary, executors enter the task’s network namespace prior to launching
the curl
command.
To specify an HTTP health check, set type
to HealthCheck::HTTP
and populate
HTTPCheckInfo
, for example:
HealthCheck healthCheck;
healthCheck.set_type(HealthCheck::HTTP);
healthCheck.mutable_http()->set_port(8080);
healthCheck.mutable_http()->set_scheme("http");
healthCheck.mutable_http()->set_path("/health");
task.mutable_health_check()->CopyFrom(healthCheck);
TCP Health Checks
TCP health checks are described by the HealthCheck.TCPCheckInfo
protobuf,
which has a single port
field, which must specify an actual port the task is
listening on, not a mapped one. The task is probed using Mesos'
mesos-tcp-connect
command, which tries to establish a TCP connection to
<host>:port
. Note that <host>
is currently not configurable and is resolved
automatically to <IP_ADDRESS>
(see limitations).
The health check is considered successful if the connection can be established.
If necessary, executors enter the task’s network namespace prior to launching
the mesos-tcp-connect
command.
To specify a TCP health check, set type
to HealthCheck::TCP
and populate
TCPCheckInfo
, for example:
HealthCheck healthCheck;
healthCheck.set_type(HealthCheck::TCP);
healthCheck.mutable_tcp()->set_port(8080);
task.mutable_health_check()->CopyFrom(healthCheck);
Common options
The HealthCheck
protobuf contains common options which regulate how a health
check must be interpreted by an executor:
delay_seconds
is the amount of time to wait until starting health checking the task.interval_seconds
is the interval between health checks.timeout_seconds
is the amount of time to wait for the health check to complete. After this timeout, the health check is aborted and treated as a failure.consecutive_failures
is the number of consecutive failures until the task is killed by the executor.grace_period_seconds
is the amount of time after the task is launched during which health check failures are ignored. Once a health check succeeds for the first time, the grace period does not apply anymore. Note that it includesdelay_seconds
, i.e., settinggrace_period_seconds
<delay_seconds
has no effect.
NOTE: Since each time a health check is performed a helper command is
launched (see limitations), setting timeout_seconds
to a small value, e.g., <5s
, may lead to intermittent failures.
As an example, the code below specifies a task which is a Docker container with
a simple HTTP server listening on port 8080
and an HTTP health check that
should be performed every second starting from the task launch and allows
consecutive failures during first 15
seconds and response time under 1
second.
TaskInfo task = createTask(...);
// Use Netcat to emulate an HTTP server.
const string command =
"nc -lk -p 8080 -e echo -e \"HTTP/1.1 200 OK\r\nContent-Length: 0\r\n\"";
task.mutable_command()->set_value(command)
Image image;
image.set_type(Image::DOCKER);
image.mutable_docker()->set_name("alpine");
ContainerInfo* container = task.mutable_container();
container->set_type(ContainerInfo::MESOS);
container->mutable_mesos()->mutable_image()->CopyFrom(image);
// Set `grace_period_seconds` here because it takes
// some time to launch Netcat to serve requests.
HealthCheck healthCheck;
healthCheck.set_type(HealthCheck::HTTP);
healthCheck.mutable_http()->set_port(8080);
healthCheck.set_delay_seconds(0);
healthCheck.set_interval_seconds(1);
healthCheck.set_timeout_seconds(1);
healthCheck.set_grace_period_seconds(15);
task.mutable_health_check()->CopyFrom(healthCheck);
Under the Hood
All built-in executors rely on the health checker library, which lives in
“src/checks”.
An executor creates an instance of the HealthChecker
per task and passes the
health check definition together with extra parameters. In return, the library
notifies the executor of changes in the task’s health status.
The library depends on curl
for HTTP(S) checks and mesos-tcp-connect
for
TCP checks (the latter is a simple command bundled with Mesos).
One of the most non-trivial things the library takes care of is entering the
appropriate task’s namespaces (mnt
, net
) on Linux agents. To perform a
command health check, the checker must be in the same mount namespace as the
checked process; this is achieved by either calling docker run
for the health
check command in case of docker containerizer or
by explicitly calling setns()
for mnt
namespace in case of
mesos containerizer (see
containerization in Mesos). To perform an HTTP(S) or TCP
health check, the most reliable solution is to share the same network namespace
with the checked process; in case of docker containerizer setns()
for net
namespace is explicitly called, while mesos containerizer guarantees an executor
and its tasks are in the same network namespace.
NOTE: Custom executors may or may not use this library. Please check the respective framework’s documentation.
Regardless of executor, all resources used to health check a task are accounted towards task’s resource allocation. Hence it is a good idea to add some extra resources, e.g., 0.05 cpu and 32MB mem, to the task definition if a Mesos-native health check is specified.
Current Limitations
- When a task becomes unhealthy, it is deemed to be killed after
HealthCheck.consecutive_failures
failures. This decision is taken locally by an executor, there is no way for a scheduler to intervene and react differently. A workaround is to setHealthCheck.consecutive_failures
to some large value so that the scheduler can react. One possible solution is to introduce a “global” policy for handling unhealthy tasks (see MESOS-6171). - HTTP(S) and TCP health checks use
<IP_ADDRESS>
as target IP. As a result, if tasks want to support HTTP or TCP health checks, they should listen on the loopback interface in addition to whatever interface they require (see MESOS-6517). - HTTP(S) health checks rely on the
curl
command; if it is not available, a health check is considered failed. - TCP health checks are not supported on Windows (see MESOS-6117).
- Only a single health check per task is allowed (see MESOS-5962).
- Each time a health check runs, a helper command is launched. This introduces some run-time overhead (see MESOS-6766).
- A task without a health check may be indistinguishable from a task with a health check but still in a grace period. An extra state should be introduced (see MESOS-6417).
- Task’s health status cannot be assigned from outside, e.g., by an operator via an endpoint.


In Opera, right click the search box to "Create Search". Specify a keyword, then use that keyword any time in your address bar to search Selfmarks. (How?)
Your API key is: #{user.api_key || '(not yet generated)'}
Keep your API key safe and secure! It is as good as your username and password in authenticating with Selfmarks. You may regenerate your API key at any time, and the old key will be discarded (lost forever). Regenerating your API key will of course break any existing applications that rely on it; these would have to be updated with the new key.
#{A( 'Generate API Key', :href => Rs( :generate_api_key ) )}


ADRESS : 747W 61st avenue, Vancouver, BC V2P 2D3
ACCESS : 10 minutes walking from marine drive station
PHONE : 641-1234-5678


MBScanState
@objc
public enum MBScanState : Int
Enum that describes the current scanning state
-
Scanning hasn’t started
Declaration
Swift
case notStarted
-
Scanning front side state
Declaration
Swift
case frontSide
-
Scanning back side state
Declaration
Swift
case backSide
-
Scanning any side state
Declaration
Swift
case anySide


What? Why? Where?
…for how these methods need to behave
…but you're likely going to fulfill them intuitively.
The unit
method is a left-identity for bind
of(x).flatMap(f) == f(x)
of(x).flatMap(f).equals(f.apply(x))
The unit
method is a right-identity for bind
m.flatMap(Companion::of) == m
m.flatMap(Monad::of).equals(m)
The bind
method is associative
m.flatMap(g).flatMap(h) == m.flatMap { g(it).flatMap(h) }
m.flatMap(g).flatMap(h)
.equals(m.flatMap(v -> g.apply(v).flatMap(h)))
Iterable (all collections)
Sequence
Nullable Types (kinda)
Optional
Stream
CompletableFuture
These slides: https://OscarAblinger.github.io/presentation-2021-05-26-monads
Probably the best in-depth explanation:
https://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html
Quick explanation of how monads arise naturally in heavily functional languages: https://stackoverflow.com/a/28139260


Please sign in
Invalid username and password.
You have been logged out.
Remember me
Sign in
Not registered? »


Share this post: https://www.facebook.com/video.php?v=402643696553096
Add hashtage #gday #khmerkeyboard
ចាប់ផ្ដើម!