text:
# Architecture

* [Android Architecture Blueprints](https://github.com/googlesamples/android-architecture)

* [Android Architecture Components](https://developer.android.com/topic/libraries/architecture/index.html)
* [Android Architecture Components samples](https://github.com/googlesamples/android-architecture-components)

## 1) RxJava + MVP

### Reference

* Android Application Architecture: [En](https://medium.com/ribot-labs/android-application-architecture-8b6e34acda65) [中](http://my.oschina.net/mengshuai/blog/541314)

## 2) Samples

## 2.1) CleanArchitecture

This is a sample app that is part of a series of blog posts I have written about how to architect
an android application using Uncle Bob's clean architecture approach.

* [Android-CleanArchitecture](https://github.com/android10/Android-CleanArchitecture)

## 2.2) reark

RxJava architecture library for Android

* [reark](https://github.com/reark/reark)

## 2.3) EffectiveAndroid

This sample project shows how to apply MVP and Clean architecture on an Android app

* [EffectiveAndroid](https://github.com/rallat/EffectiveAndroid)

## 2.4) MVVM 知乎日报 APP

* [Idaily](https://github.com/liuguangqiang/Idaily)

---

* [给 Android 开发者的 RxJava 详解](http://gank.io/post/560e15be2dca930e00da1083)
* [RxJava Essentials 中文翻译版](http://rxjava.yuxingxin.com/)

repository: joinAero/DroidTurbo

repo_name: joinAero/DroidTurbo


text:
fortune: Display random quotes
==============================

## Introduction

`fortune` is yet another implementation of the Unix-style `fortune` program
that displays a random message from a database of quotations. Conceptually,
it's similar to the BSD fortune program originally written by [Ken Arnold][].
Unlike Arnold's program, this version is written in [Python][] and should
run anywhere there's a Python interpreter.

Slight modifications to allow for all quotes to be displayed and to change
some package-specific conventions.

To run, clone the repo and, from the parent directory, run
`python fortune [filepath]` or `python fortune -h` for help.

[Ken Arnold]: http://en.wikipedia.org/wiki/Ken_Arnold
[Python]: http://www.python.org/
[web page]: http://software.clapper.org/fortune/

## Copyright

Copyright © 2008-2012 Brian M. Clapper

## License

BSD license.

repository: gilmourj/fortune

branch_name: refs/heads/master

extension: md

gha_language: CSS

gha_license_id: NOASSERTION

license_type: permissive

repo_name: gilmourj/fortune


text:
# 5. Deploy Backend code to Lambda and Set Up Alexa Skill

### Create Backend Lambda Function
First we’re going to create a Lambda function to handle Alexa login and invocations.

From the top level of the project run

```
gulp bundle:backend
```

to compile the backend code in the /dist folder.

Go to [your Lambda functions](https://console.aws.amazon.com/lambda/home#/functions?display=list) and Create a new function.
Click 'Author from scratch'.
Name the function; for reference we’ll call this ‘opsbuddy-backend’.
For Role select 'Choose an existing role', then select the 'opsbuddy' role we created earlier, then click 'Create function'.

If you are not taken to the function automatically, then select the role we just created from the list of functions.
Under 'Function code', make sure the runtime is ‘Node.js 6.10’ and the Handler is 'index.handler'.
Select ‘Upload a .ZIP file’ for ‘Code entry type’.
Click on the Upload button that appears next to ‘Function package’ and select the backend .zip file in the /dist folder.

You will need to add several Environment Variables:

* BITSCOOP_API_KEY (obtainable at https://bitscoop.com/keys)
* PORT (by default it’s 3306)
* HOST (the endpoint for the RDS box, <Box name>.<ID>.<Region>.rds.amazonaws.com)
* USER (the username you picked for the RDS box)
* PASSWORD (the password you set for the RDS box)
* DATABASE (the database name you set for the RDS box)
* GITHUB_MAP_ID (the ID of the BitScoop API map for GitHub)
* GOOGLE_ANALYTICS_MAP_ID (the ID of the BitScoop API map for Google Analytics)
* GOOGLE_SIGN_IN_MAP_ID (the ID of the BitScoop API map for Google Sign-In)
* POSTMAN_MAP_ID (the ID of the BitScoop API map for Postman)
* STATUSCAKE_MAP_ID (the ID of the BitScoop API map for StatusCake)
* ALEXA_APP_ID (The ID of the Alexa app; this will be filled in later)

Go to the Basic settings block and set the timeout to 15 seconds.
Open the Network block, select the ‘opsbuddy’ VPC we created and add the two ‘private’ subnets we created earlier, and add the ‘opsbuddy-lambda’ security group.
Finally, scroll back up to the top of the page and click Save (not Save and test, as we don't want to test run it).
Click on the Triggers tab, next to Configuration.
Click on 'Add Trigger', then click on the dashed gray box, select 'Alexa Skills Kit', and then click Submit.
Look in the upper-right corner of the screen to find the ARN; we will need this momentarily.

### Set up Alexa Skill
Go to [your Alexa Skills](https://developer.amazon.com/edw/home.html#/skills) and click ‘Add a New Skill’.

Under Skill Information, pick ‘Custom Interaction Model’ for the Skill Type, enter ‘Ops Buddy’ for Name and Interaction Name, and click Save.
Click on Interaction Model on the left-hand side. Under Intent Schema enter:

```
{
  "intents": [
    {
      "intent": "AMAZON.StopIntent"
    },
    {
      "intent": "AMAZON.CancelIntent"
    },
    {
      "intent": "AMAZON.HelpIntent"
    },
    {
      "intent": "AboutIntent"
    },
    {
      "intent": "StackIntent"
    }
  ]
}
```

and under Sample Utterances enter:

```
StackIntent how's the stack doing
StackIntent how is the stack doing
StackIntent how is the stack doing today
StackIntent tell me how the stack is doing
```

You can add more utterances if you wish; the key thing is that they must start with ‘StackIntent’ to call the right Intent in the Lambda function.
Click Save when you’re done.

Next click on Configuration.
Service Endpoint Type should be ‘AWS Lambda ARN’.
Paste the ARN from the end of Step 3 into the 'Default' text box right under the endpoint type.
Select 'Yes' under Account Linking, after which a number of fields will appear.
For Authorization URL, enter the Invoke URL followed by '/alexa-login', e.g. 'https://abcd1234.execute-api.us-east-1.amazonaws.com/prod/alexa-login'.
Client ID should be the public key you generated for Google.
Add a domain for Domain List and make it 'google.com'.
Add two scopes, which should be 'https://www.googleapis.com/auth/userinfo.email' and 'https://www.googleapis.com/auth/userinfo.profile'.
Take note of the Redirect URLs, as you will need to use one of them soon.
Authorization Grant Type should be 'Auth Code Grant'.
Set Access Token URI to 'https://accounts.google.com/o/oauth2/token'.
Enter your Google secret key under Client Secret.
Set Client Authentication Scheme to 'Credentials in request body', then click Save.

You need to go back to the Google credentials you made and add one of the Redirect URLs from the Configuration page to 'Authorized Redirect URLs'.
Make sure to save the credentials.

Go to Publishing Information in the Alexa Skill.
Pick a category and sub category; we recommend Productivity - Organizers & Assisstants, but you can pick whatever you want.
You must enter some testing instructions.
Add the two skill descriptions, and enter a few example phrases.
You must also upload a small and large icon.
When all of that is done, click Save.

Go to Privacy & Compliance.
The first question should be No, the second Yes, and the third No.
Check Export Compliance and select No for the advertising question.
For the Privacy Policy URL you can enter 'https://bitscoop.com/privacy'.
Finally, save this.

### Enable and run in Test mode
The rest of these instructions assume you will not publish your copy, but just want to run it in test mode.

At this point, you should see the 'Skills Beta Testing' box on the left change and a button to 'Beta Test Your Skill'.
This means that all necessary information has been entered and you can now run the app.
Click on this button, then enter some emails of testers and click 'Update Testers'.
Finally click 'Start test' in the bottom right.
You should be taken to a page with an Invite URL.

For instructions on how to enable and link this skill, see the instructions in the [configure](../configure) tutorial.

license: MIT

repository: barankyle/bitscoop-ops-buddy

repo_name: barankyle/bitscoop-ops-buddy


text:
# VHDL Code Examples

This repository made for help the Hacettepe Electrical and Electronics Engineering students.

## Usage
Install Xilinx ISE from their official [website](http://www.xilinx.com).

## Contributing
If you have more material that involving digital design topics , don't hesitate to contribute.

## More Contact
<EMAIL_ADDRESS>
## License
[MIT](https://choosealicense.com/licenses/mit/)

repository: bakialmaci/VHDL

gha_language: C

repo_name: bakialmaci/VHDL


text:
# Web app examples

Applications utilize APIs via API management (apinf.io). In the example API key is used, but requirement for it can be turned off from API management (by the API owners).

Below you'll find simple code snippets which shows how each of the APIs in action. Snippets are in public JSFiddles. The last example brings all together in one node.js web app to exemplify real world usage.

## Turku Issue reporting API examples via APInf.io

API used via APInf.io platform, https://apinf.io/apis/turku-issue-reporting-api

* Sample gets services list from the API and prints item count. https://jsfiddle.net/fdy31mvf/25/
* Sample gets services list from the API and lists them in pretty print.

## Turku Street Maintenance API examples via APInf.io

API used via APInf.io platform, https://apinf.io/apis/turku-street-maintenance-api

## Sample node.js web app

This sample node.js web app uses above snippets.

repository: matleppa/Open-API-Training-Turku

repo_name: matleppa/Open-API-Training-Turku


text:
# Privata.ai SDK

A JavaScript SDK to facilitate the interaction with [Privata.ai](https://privata.ai/).

You can find more about this SDK on [our documentation](https://documentation.privata.ai/sdk/js).

## What is Privata.ai?

Privata.ai is a modern User Behavior Analytic (UBA) used to detect insider threats within an application.

Our platform flags sensitive data on different databases and then monitors individual user accesses to that data through the applications. Our SDK is used within your application's code to send information about these accesses to our API so your customers can view and analyze their users behaviour.

## SDK development

### Testing

For testing, create an `.env` file as follows:

```
dbKey=testing-database-id
DBSECRET=testing-database-secret
APIURL=http://api-url:3000
```

Note: To test locally change the Fireabase config in `auth/index.ts`

Then you can run:

```
npm run test
```

repository: Privata-ai/privata-js-sdk

branch_name: refs/heads/develop

gha_language: TypeScript

gha_license_id: MIT

repo_name: Privata-ai/privata-js-sdk


text:
# Stock-Market-Sentimentality-prototype
 This project is a series of examples I have made using python to predict stock prices using different methods.

 This project is based on examples and tutorials and papers I found on the internet, these are prototypes that I plan on creating a new project based on with!

 This project is a precursor for an official project that shares the same goal as this!

 This project also uses machine learning.

 Requirments:

VaderSentiment - pip install vaderSentiment - https://pypi.org/project/vaderSentiment/

Pandas - pip install pandas - https://pypi.org/project/pandas/

Numpy - pip install numpy - https://pypi.org/project/numpy/

Textblob - pip install textblob - https://pypi.org/project/textblob/

SciKit-learn (aka: sklearn) - pip install scikit-learn - https://pypi.org/project/scikit-learn/

Matplotlib - pip install matplotlib - https://pypi.org/project/matplotlib/

Plotly - pip install plotly - https://pypi.org/project/plotly/

nbformat - pip install nbformat - https://pypi.org/project/nbformat/

Newpaper3k - pip install newspaper3k - https://pypi.org/project/newspaper3k/

TextBlob - pip install textblob - https://pypi.org/project/textblob/

Natural Language Toolkit (aka: NLTK) - pip install nltk - https://pypi.org/project/nltk/

Pandas DataReader - pip install pandas-datareader - https://pypi.org/project/pandas-datareader/

Requests - pip install requests - https://pypi.org/project/requests/

BeautifulSoup - pip install beautifulsoup4 - pip install bs4 - https://pypi.org/project/beautifulsoup4/


text:
# ramanujan

This project is an implementation of a microblogging system (similar
to the basic functionality of [Twitter](http://twitter.com)) using the
[microservice architecture](http://www.richardrodger.com/seneca-microservices-nodejs#.VyCjoWQrL-k)
and [Node.js](https://nodejs.org). It is the example system discussed
in Chapter 1 of [The Tao of Microservices](http://bit.ly/rmtaomicro)
book.

This purpose of this code base to help you learn how to design and
build microservice systems. You can follow the construction through
the following steps:

  * [Informal Requirements](#informal-requirements)
  * [Message specification](#message-specification)
  * [Service specification](#service-specification)

The system uses the
[Seneca microservice framework](http://senecajs.org) to provide
inter-service communication, and the
[fuge microservice development tool](https://github.com/apparatus/fuge) to manage
services on a local development machine.

The system is also a demonstration of the
[SWIM protocol](https://www.cs.cornell.edu/~asdas/research/dsn02-swim.pdf)
for peer-to-peer service discovery. A service registry is not needed
as the network automatically reconfigures as microservices are added
and removed.

## Scope of the system

The system shows implementations of some of the essential features of
a microblogging system, but not all. Of particular focus is the use of
use of separate microservices for separate content pages, the use of
messages for data manipulation, and the use of a reactive message flow
for scaling.

The system does not provide for full accounts, or user
authentication. This could be added relatively easily using the
seneca-auth and seneca-user plugins. Avoiding the need to login makes
it easier to experiment as you can check multiple user experiences in
the browser.

The system exposes a (RESTish) JSON API over HTTP. However, the user
interface does _not_ use any client-side JavaScript, and entirely
delivered by server-side templates. This is an old school POST and
redirect architecture to keep things simple and focused on the
server-side.

The system does not use persistent storage. You can easily make the
data persistent by using a Seneca data storage plugin. Keeping
everything in memory makes for faster development, easier
experimentation, and lets you reboot the system if you end up with
corrupted data during development.

This system also provides an example of message tracing, using Zipkin.

This example codebase does not provide a production deployment
configuration. It does however provide a Docker Swarm example that you
can start building from.

## Unit test examples

The system also includes example code for unit testing microservices.
The unit test code for each service is in the `test` subfolder of each
microservice folder.

To run all the tests, use:

``js
npm test
``

The microservices can be unit tested independently and offline. Mock
messages are used to isolate each microservice from its network
dependencies.

## Running the system

The system is implemented in Node.js. You will need to have Node.js
version 4.0 or greater installed.

You can run the system directly from the command line by running the
`start.sh` script:

```sh
$ ./start.sh
```

This starts all the microservices in the background. While this is a
quick way to get started, and verify that everything works, it is not
the most convenient option.

To have more control, you can use
[fuge](https://github.com/apparatus/fuge) to run the microservice
processes. Detailed instructions are provided next.

You can also use Docker to run the services. Example Dockerfiles are
provided in the
[docker folder](https://github.com/senecajs/ramanujan/tree/master/docker). See
below for more details.

## Running with fuge

#### Step 0: Install fuge

Follow the instructions at [fuge repository](https://github.com/apparatus/fuge).

_fuge_ is a development tool that lets you manage and control a
microservice system for local development. The ramanjun repository is
preconfigured for fuge (see the fuge folder), so you don't have to set
anything up. The ramanujan system has 14 microservices (at last
count), so you really do need a local tool to help run the system.

This is trade-off that you make when you choose the microservice
architecture. You can move faster because you have very low coupling,
and thus lower technical debt, but you will need more automation to
manage the higher number of moving parts.

#### Step 1: Clone the repository

Use git to clone the repository to a local development folder of your choice

```sh
$ git clone https://github.com/senecajs/ramanujan.git
```

#### Step 2: Download dependencies

The system needs a number of Node.js modules from npmjs.org to
function correctly. These are the only external dependencies.

```sh
$ npm install
```

Wait until the downloads complete. Some modules will require local
compilation.  If you are using Windows,
[configuring msbuild](https://github.com/Microsoft/nodejs-guidelines/blob/master/windows-environment.md#compiling-native-addon-modules)
first is a good place to start.

The Zipkin message tracing is optional, and the system will work fine
if there is no Zipkin installation. However, it is pretty easy to set
one up using Docker:

```sh
$ docker run -d -p 9411:9411 openzipkin/zipkin
```

Once you've run through some of the use cases, open http://localhost:9411/ to see the
message traces. Note that this is a demonstration system, so all
traces are captured. In production you'll want to use a much lower
sampling rate - see the Zipkin documentation for details.

#### Step 3: Run fuge

From within the repository folder, run the fuge shell.

```sh
$ fuge shell fuge/system.yml
```

This will start fuge, output some logging messages about the ramanujan services, and then place you in an interactive repl:

```sh
...
starting shell..
? fuge>
```

Enter the command `help` to see a list of commands. Useful commands
are `ps` to list the status of the services (try it!), and `exit` to
shutdown all services and exit. If your system state becomes corrupted
in some way (this often happens during development due to bugs in
microservices), exit fuge completely and restart the fuge shell.

#### Step 4: Start up the system

To start the system, use the fuge command:

```sh
...
? fuge> start all
```

You see a list of startup logs from each service. _fuge_ prefixes the
logs for each service with the service names, and gives them different
colors so they are easy to tell apart. This also makes is easy to
review message flows. The system takes about a few seconds to start
all microservices.

Now use the `ps` command to list the state of the services. They
should all be running.

### Using the system

Open your web browser to interact with the system. The steps below
define a "happy path" to validate the basic functionality of the
system.

#### Step 1: Post microblogs entries for user _foo_

Open `http://localhost:8000/foo`.

This is the homepage for the user _foo_, and shows their timeline. The
timeline is a list of recent microblog entries from all users that the
user _foo_ follows, and also entries from _foo_ themselves.

At first there are no entries, so go ahead and post an entry, say:

> _three colors: blue_

Click the _post_ button or hit return. You should see the new entry.

Post another entry, say:

> _three colors: white_

You should see both entries listed, with the most recent one at the
top. This is the timeline for user _foo_.

#### Step 2: Review microblogs for user _foo_

Open `http://localhost:8000/mine/foo` (Or click on the _Mine_ navigation tab).

This shows only the entries for user _foo_, omitting entries for followers.

You can use this page to verify the entry list for a given user.

#### Step 3: Load search page of user _bar_, and follow user _foo_

Open `http://localhost:8000/search/bar`.

You are now acting as user _bar_. Use the text _blue_ as a search query:

Click on the _follow_ button. Now user _bar_ is following user _foo_.

#### Step 4: Review timeline for user _bar_

Open `http://localhost:8000/bar` (Or click on the _Home_ navigation tab).

You should see the entries from user _foo_, as user _bar_ is now a follower.

#### Step 5: Post microblog entries for user _bar_

Enter and post the text:

> _the sound of music_

The timeline for user _bar_ now includes entries from both users _foo_
and _bar_.

#### Step 5: Post microblog entries for user _foo_

Return to user _foo_. Open `http://localhost:8000/foo`.

Post a new entry:

> _three colors: red_

You should see entries only for user _foo_, as _foo_ does **not** follow _bar_.

#### Step 6: Load microblog timeline of user _bar_

Go back to user _bar_. Open `http://localhost:8000/bar`.

You should see an updated list of entries, included all the entries
for user _foo_, as _bar_ **does** follow _foo_.

### Starting and stopping services

One of the main benefits of a microservice system is that you can
deploy services independently. In a local development setting this
means you should be able to start and stop services independently,
without stopping and starting the entire system. This has a huge
productivity benefit as you don't have to wait for the entire system
to ready itself.

To work on a particular service, update the code for that service, and
then stop and restart the service to see the new functionality. The
rest of the system keeps working. To really get the maximum benefit
from this technique, you need to avoid the use of schema validation
for your messages, and you must avoid creating hard couplings
(services should not know about each other). That is why the Seneca
framework provides pattern matching and transport independence as key
features - they enable rapid development.

The payoff for more deployment complexity is that you can change parts
of the system dynamically - don't lose that ability!

_fuge_ allows you to start and stop services using the 'start' and
'stop' commands.

To stop a service (say, _search_), use the command:

```sh
? fuge> stop search
```

If you now try to use the search feature, it will fail, but other
pages will still work. Another important benefit of microservices is that they can isolate errors in this way.

To restart the _search_ service, use:

```sh
? fuge> start search
```

And the search functionality works again. Notice that you did not have
to do any manual configuration to let the other services know about
the new instance of the _search_ service. Notice also that the other
services knew almost instantaneously about the the new instance of the
_search_ service. That's becuase the SWIM algorithm propogated that
information quickly and efficiently throughout the network. No need
for 30 second timeouts to detect errors - SWIM works much more quickly
as it has many observers (the other services) so can detect failure,
and new services, very quickly with a high degree of confidence.

You can also run multiple instances of the same service. This lets you
scale to handle load. The underlying seneca-mesh network will
automatically round-robin messages between all available services for
a given message. Just start the service again:

```sh
? fuge> start search
```

And is you now run the `ps` command in fuge, you'll see the count is 2
instances.

### Accessing the network REPL

The system comes with a REPL service that lets you submit messages to the network manually. This is very useful for debugging. Access the REPL by telnetting into it:

```sh
$ telnet localhost 10001
```

Use the following message to see the user _foo's_ timeline:

```sh
seneca 2.0.1 7k/repl> timeline:list,user:foo
IN  000000: { timeline: 'list', user: 'foo' } # t7/39 timeline:* (6ln6zlc2qaer) transport_client
OUT 000000: { '0':
   { user: 'foo',
     text: 'three colors: red',
     when:<PHONE_NUMBER>373,
     can_follow: false },
  '1':
   { user: 'foo',
     text: 'three colors: white',
     when:<PHONE_NUMBER>135,
     can_follow: false },
  '2':
   { user: 'foo',
     text: 'three colors: blue',
     when:<PHONE_NUMBER>996,
     can_follow: false } }
```

You can enter messages directly into the terminal, in JSON format (the
format is lenient, see
[jsonic](https://github.com/rjrodger/jsonic)). The output will show
the message data `IN` and `OUT` of the network.

The REPL is a JavaScript console environment. There is a `seneca`
object that you can use directly, calling any methods of the seneca
API.

```sh
seneca 2.0.1 7k/repl> seneca.id
'7k/repl'
```

To get a list of all services on the network, and which messages they
listen for, try:

```sh
seneca 2.0.1 7k/repl> role:mesh,get:members
IN  000001: { role: 'mesh', get: 'members' } # aa/ie get:members,role:mesh (9mxp6qx6zyox) get_members
OUT 000001: {
  ...
  '4':
   { pin: 'timeline:*',
     port: 54932,
     host: '<IP_ADDRESS>',
     type: 'web',
     model: 'consume',
     instance: 'gt/timeline-shard' },
  ...
  }
```

This message is so useful, that the repl service defines an alias for it: `m`.

The default configuration of the system uses shortened identifers to
make debugging easier.

### Using the monitor

You can monitor the state of each service, and the message patterns
that it responds to, by running the `monitor` service separately in
it's own terminal window. The `monitor` service prints a table of
showing each service, and dynamically updates the table as services
come and go. See
[seneca-mesh](https://github.com/senecajs/seneca-mesh) for details.

```sh
$ node monitor/monitor.js
```

## Using Docker

You'll need to have the latest version of
[Docker](https://www.docker.com/) installed.

The [docker](https://github.com/senecajs/ramanujan/tree/master/docker)
folder contains Docker image setup Makefiles and Dockerfiles. Run the
top level `Makefile` to build all the images:

```
$ cd docker
$ make
```

Then deploy all the images using Docker Stack:

```
$ docker stack deploy -c ramanujan.yml ramanujan
```

This will start up everything. The containers run in their own overlay
network, but you will be able to access the website and repl on
localhost as with fuge.

If things go funny (hey, it's Docker), delete the stack, restart
Docker, and try again:

```
$ docker stack rm ramanujan
```

You can see some information about the containers with these commands:

```
$ docker stats
$ docker services ls
$ docker ps
```

To view the monitor, run the it on the `repl` container:

```
$ docker exec -it `docker ps | grep repl | cut -f 1 -d ' '` /bin/sh
# node monitor.js
```

## Informal Requirements

> TODO

## Message Specification

> TODO

## Service Specification

> TODO

## Help and Questions

[github issue]: https://github.com/senecajs/ramanujan/issues
[gitter-url]: https://gitter.im/senecajs/ramanujan

## License
Copyright (c) Richard Rodger and other contributors 2015-2016, Licensed under [MIT](/LICENSE).

repository: jimmytuc/ramanujan

repo_name: jimmytuc/ramanujan


text:
---
title: Overwriting Tilt Slides
---

# Overwriting Tilt Slides

The [tilt mode](../../index.md) comes with very
basic slides. You can overwrite them using the following config:

``` mpf-mc-config
#! switches:
#!   s_tilt:
#!     number:
#!     tags: tilt_warning
##! mode: tilt
# in your modes/config/tilt.yaml
slides:
  _overwrite: true   # this is important to overwrite the existing slides
  tilt_warning_1:
    widgets:
      - type: text
        text: "STOP IT"
    expire: 1s
  tilt_warning_2:
    widgets:
      - type: text
        text: WARNING
        y: top-2
        anchor_y: top
      - type: text
        text: "SERIOUSLY STOP IT"
        y: top-18
        anchor_y: top
        expire: 1s
    expire: 2s
  tilt:
    - type: text
      text: TILT
##! test
#! start_game
#! post slam_tilt
#! advance_time_and_run .1
#! assert_mode_running tilt
#! hit_and_release_switch s_tilt
#! advance_time_and_run .1
#! assert_text_on_top_slide "STOP IT"
#! advance_time_and_run 2
#! assert_text_not_on_top_slide "STOP IT"
#! hit_and_release_switch s_tilt
#! advance_time_and_run .1
#! assert_text_on_top_slide "SERIOUSLY STOP IT"
```

By setting the `_overwrite: true` you will overwrite the complete
`slides:` section of the built-in tilt mode. The slides above are the
default slides.

!!! note

    You can add a slide for the `slam_tilt` event. However, by default the
    `tilt` slide is also shown at the same time so you have to make sure
    that your slide has a higher priority than that slide.

repository: missionpinball/mpf-docs

branch_name: refs/heads/main

gha_language: Python

repo_name: missionpinball/mpf-docs


text:
## webwhatsapp_hide_previews.user.js
When using the new web version of whatsapp, the image previews are quite big and can lead to private pictures/videos being seen by others.
With this script, the previews will be almost invisible, and you'll need to manually click on it to view the original image/video.

If you try hard enough, you'll be able to see some shapes in the image, which will help you decide if you should open it or not.

### Before and after
![before_after](examples/before_after.png)

repository: PabloReyes/userscripts

repo_name: PabloReyes/userscripts


text:
# Developer guide

Digging in the project for the first time might make it difficult to understand where to start. Hopefully, this
guide will provide you with a better understanding of the project structure.

## Running the project

There are some ways to setup the development environment. You can run directly from your favorite
IDE or overwrite Ritchie's binary on your machine. The most popular IDEs are [GoLand](https://www.jetbrains.com/pt-br/go/)
from JetBrains and [VSCode](https://code.visualstudio.com/) from Windows.

#### Running on GoLand

* On the top menu go to `Run > Edit Configurations`. Click on the `+` button on the top left and select to create a
new `Go Build`.

* On **Files**, select the `cmd/main.go` file as the entry point of your program.

* As for **Working Directory**, use the project root

* Under **Program Arguments**, write the command you want to run without the `rit`. For instance, if you want to
debug `rit create formula`, just add `create formula` on this field.

<img class="special-img-class" src="/docs/img/go-land-setup.png"  alt="Edit Configurations screen of GoLand"/>

#### Overwriting your current binary

If you want to basically use your local code as the running Ritchie distribution on your machine, just run this
simple command from your project root directory in the terminal:

* Linux: `make build-linux && sudo mv ./dist/linux/rit /usr/local/bin`
* Mac: `make build-mac && sudo mv ./dist/darwin/rit /usr/local/bin`
* Windows: `make build-windows && runas \user:administrator move .\dist\windows\rit.exe "\Program Files (x86)\rit"`

## The main libraries

There are two main libraries that are most used throughout the project. These are the ones that aid us directly
in building a solid cli, and probably the ones you will have most contact with.

#### [Cobra](https://github.com/spf13/cobra)

Cobra is a powerful cli building tool. Many modern projects use it to build their clis. We can map out all commands
and subcommands in Ritchie and Cobra will take care of executing them with the right methods and flags, provide
helper descriptions for users, and even more features. Check its github repo to learn more about it.

#### [Survey](https://github.com/AlecAivazis/survey)

One of the key features of Ritchie is that it lets you run formulas in an interactive manner. To help us achieve
a better user experience, we use survey. Survey is a library of cli prompts in various formats. It supports text
inputs, secret inputs, list selection, among other things.

## Project structure

For this section, we discuss the main folders in the project and their purpose.

#### Cmd

This is where the `main` file resides. Ritchie comes natively with a set of **core** commands to manipulate the cli.
These commands range from managing workspaces and credentials, to building and creating formulas. We make heavy
use of dependency injection to make these commands testable. Therefore, most of the components are initialized here
and then added to `Cobra`. If you have any new command to add, you will be definitely editing this file. Keep in mind
the organisation of the commands!

#### Functional

Currently, we have two main ways of running formulas. Formulas can be run interactively or via stdin. This folder
contains the files to run formulas on the different supported OSes and with different input formats.

#### Packaging

Contains code and instructions to package Ritchie for different supported OS distributions. Here we have scripts
for the Windows installer, rpm and debian distributions, and other installation scripts.

#### Pkg

This module is the core of the project, any command or functionality is generally developed here and added to **Cobra**
via `main`. Some of the features developed are listed below:
* api: contains main constants such as the user home directory and core commands list.
* autocomplete: contains inline scripts and logic for the `rit completion` commands.
* cmd: contains most of core commands implementation. You can find commands such as listing, creating,
and deleting resources here. For simple implementations they are enough, but they might call dedicated modules
to perform certain actions.
* credential: contains logic related to credential manipulation, such as the files they are saved and how to manage
them.
* env: manages user environments. Helper to resolve credential from input runners, using different sets of credentials (i.e.: development, staging, production)
* formula: contains all formula manipulation implementations, such as building, resolving, creating,
and running formulas
* git: module to add, remove, or manage other formula repos.
* http: header definitions
* metric: sends collected anonymous metrics via http requests.
* prompt: Ritchie's adaptations on the `survey` module for user input.
* rtutorial: basic implementation of tutorial texts. Tutorial are helper texts that can be added to each command
to provide the user with more context on that action.
* stdin: JSON stdin parser
* upgrade: manages and performs upgrades on Ritchie
* version: manages and resolves Ritchie's versioning

#### Testdata

Contains multiple files used for unit and functional tests.

## Testing your code

Ritchie relies heavily on dependency injection to test its code. If you are creating a new command, you should
pass on any required dependencies from the `main.go` initialization file. Usually you pass on inputs to prevent
the test from blocking the execution flow while awaiting for an user input. For instance, suppose you have a list
that offers the options `a, b, c`. Then, you simply pass a mock that returns `a` straight away in place of the listing
struct to perform your test.

#### Manipulations on your file system

When testing, think about the intended behavior of your command. Does it create or modify a file? Does it manipulate
a directory? You can make use of the `os.TempDir()` command to setup your sandbox file system and manipulate files
and folders there. Let's suppose your implementation edits the credential config file. You do not want to meddle
with your own config file every time you run a test. So simply create one in a temp directory and pass its path
to the command *as if it was ritchie's home directory.

Do not forget to remove your temp directory to not flood your file system with trash on each run! You can use `defer`
to ensure a piece of code will always be executed after the method returns regardless of where the execution ended.

`defer os.RemoveAll(filePath)`

#### Test structure

Test files are suffixed with `_test`. Test functions have the format `TestCamelCase` which will be printed when
you execute them. If your test has multiple outcome branches, you can create a struct array to iterate over such cases.
The struct usually has the format:
```go
    tests := []struct {
		name    string   // Name of the test to display
		fields  fields   // Contains all necessary struct mocks or values to perform the test
		output  bool     // Expected result to compare to
	}
```

A typical test has the following structure
```go
    // Mocks initialization here

	var tests = []struct {
		name            string
		fields          fields
		output          string
	}{
		{
			name:            "Some name",
			fields:          fields{ ... },
			output:          "Some output",
		},
		...,
	}

	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			// Your execution code here that compares with the output
		})
	}
```

> Note: we are currently reviewing how our tests are written, we are trying to make a more assertive test framework
>on Ritchie cli, such as simulating the user input via stdin instead of mocking it, so these practices might change.

### Functional Tests

#### How to do functional testing using Github Action

Ritchie CLI uses Github Actions to perform functional tests in parallel on `ubuntu`, `macOs` and `windows`.

To do so, the team created an action to check command lines outputs: [test-cli-commands-action](https://github.com/GuillaumeFalourd/test-cli-commands-action)

The objective is to check if the command output is the same as expected according to the scenarios specified (success or failure).

Those workflows will trigger on any pull request or push event updating files related to the commands being tested.

This is the way the action works:

![how does the action work](https://user-images.githubusercontent.com/22433243/123486342-39901080-d5e2-11eb-94f2-3f45b4ed6205.png)

There are 3 ways to check a command line output using this action:

* Comparing the command line output with an assert file.
* Comparing a specific line of the command line output with an assert file.
* Checking if a specific expression is present in the command line output.

When possible, we tried as much as possible to compare command line outputs using assert files, but as the command line outputs files are created using different OS, or return specific datas depending on the date, we couldn't test all scenarios with this option alone, that's the reason why other features as been added to the action as well.

_Note: TXT files used for ASSERT are located on the `/testdata/gha_workflows` directory._

#### Implementing Functional Tests

When testing new commands or scenarios, we suggest to use the `cat` commands to show each file you will compare on the workflow window on Github. Example:

```shell
   rit list credential > check1.txt
   cat check1.txt
   cat testdata/gha_workflows/credential_workflow/assert1.txt
   diff check1.txt testdata/gha_workflows/credential_workflow/assert1.txt
```

Then, convert it to the action nomenclature:

```yaml
      - uses: GuillaumeFalourd/test-cli-commands-action@v1
        with:
           command_line: <command line to test>
           assert_file_path: path/to/assert.txt
           specific_line: 3
           contains: <string expression>
           expected_result: <PASSED or FAILED> (if you want to test Success or Error)
```

Check the [action documentation about those inputs](https://github.com/GuillaumeFalourd/test-cli-commands-action#%EF%B8%8F-action-inputs) to understand exactly how to use them.

To test your workflows, create a branch on your **fork** and test your workflows there using the `workflow_dispatch` trigger.

## Translation

- All translation files are inside the `/resources/i18n` folder.
- Translation files follow a convention, must start with your locale, and have the extension `.toml`. For example: `en.toml`
- Any phrase or word that does not exist in `en.toml` must be added to it to avoid mistakes.
- The convention for translation IDs is to start with the name of the specific package or command followed by a clear identifier for your word or phrase. For example: `[init.welcome]`

### See some examples below:

#### English file (`en.toml`)

```toml
[init.hello.world]
other = "Hello World!"
```

#### Portuguese file (`pt_BR.toml`)

```toml
[init.hello.world]
other = "Olá Mundo!"
```

#### Other locale example (`ge_GE.toml`)

```toml
[init.hello.world]
other = "Hallo Welt!"
```

> Note: you must run the `make generate-translation` command to update the `translations.go` file whenever you create
> or update a translation.

### How to use translation in your Golang code?

You will use the `i18n` package located inside `internal/pkg/i18n`. See an example below:

```go
import "github.com/ZupIT/ritchie-cli/internal/pkg/i18n"

var helloWorldMsg = i18n.T("hello.world") // [hello.world] is the message ID.

```

:warning: Attention: For new languages you must add the full name of the language and its locale on a map called `i18n.Langs`.

Example:

``` go
package i18n

var Langs = map[string]string{
	"English":    "en",
	"Portuguese": "pt_BR",
	"German":     "ge_GE", // Must be the same name as the translation file
}

```

### Generate Ritchie pkg installer

We have a `packaging` directory that contains a `mac-pkg` subdirectory with a script (inspired from [KosalaHerath/macos-installer-builder](https://github.com/KosalaHerath/macos-installer-builder)) to generate a pkg install from rit darwin binary.

Here is the step by step to follow to generate it:

* Create an `Application` folder on `packaging/mac-pkg` folder.
* At the repository root, run `make build-mac && sudo mv ./dist/darwin/rit ./packaging/mac-pkg/Application`.
* Access the mac-pkg folder: `cd packaging/mac-pkg`
* Run `bash build-macos-x64.sh rit <version>`
* Your package file should be available at `packaging/mac-pkg/target/pkg`

_Note: You need to have a `developer certificate` installed on `keychain` on the macOS computer that will run the command to sign the pkg. In that case, you'll need to run `bash build-macos-x64.sh rit <version> "<developer_installer_id>"`, and your package file should be available at `packaging/mac-pkg/target/pkg-signed`._

repository: ZupIT/ritchie-cli

gha_language: Go

repo_name: ZupIT/ritchie-cli


text:
# gitlab Cookbook

Configures the different components needed for an Omnibus installation of GitLab

## Resources

### postgresql_user

Creates a user account in the PostgreSQL instance

#### properties

* 'username': The name of the user to create. Required
* 'password': The password of the account. Optional. This can be the plaintext password, or an md5 hash of the password. The hash can be generated by running `echo -n 'PASSWORD+USERNAME' | md5sum` and should be passed in the form `md5PASSWORD_HASH`.
* 'options': An array of options to enable on the user. Optional. See the [PostgreSQL documentation](https://www.postgresql.org/docs/9.6/static/sql-createuser.html) for the available options
* 'helper': The helper object for interacting with the running database. Default: PgHelper.new(node)

#### example

Create the user 'bar' without a password or any options

```ruby
postgresql_user 'bar'
```

Create the superuser 'bar' with an md5 encoded password
```ruby
postgresql_user 'bar' do
  options %w(SUPERUSER)
  password 'md5........'
end
```

### postgresql_database

Creates a database in the PostgreSQL instance

#### properties

* 'database': The name of the database to create. Required.
* 'owner': The user account that will be the owner of the database. Default: `node['gitlab']['postgresql']['user']`
* 'helper': The helper object for interacting with the running database. Default: PgHelper.new(node)
* 'database_port': The port the database instance is listening on. Default: `node['gitlab']['postgresql']['port']`
* 'database_socket': The directory that the socket file exists in. Default: `node['gitlab']['postgresql']['unix_socket_directory']`

#### example

Create a database called 'foo' owned by the default postgresql user

```ruby
postgresql_database 'foo'
```

Create a database called 'foo' owned by user 'bar'

```ruby
postgresql_database 'foo' do
  owner 'bar'
end
```

repository: rdollinger/omnibus-gitlab

repo_name: rdollinger/omnibus-gitlab


text:
---
layout: post
title:  "What to pack in your field kit"
date:   2021-02-14 17:04:01
categories: post
tags: [gear, field work]
description: A guide on what to prepare and what to pack for structural field work. The key to having a good time is having the right prep and the right equipment.
---

{% newthought 'A well-packed field kit is critical' %} to having a safe, comfortable, efficient, and non-embarrassing field experience.  In the time since then, I've accumulated a field kit that I can now basically grab and go for most inspections. Below are some of the items I've added to my field kit over time.

## Stuff for taking notes

**Clipboard.** Can be 11x17 sized or 8 1/2x11 sized. Get the box type, which will allow you to keep pens, drawings, and extra paper inside.

**Magnet.**  Choose a type that won't run if the page gets wet. No matter how dry the site is supposed to be, your notes are going to get wet. Bring multiple colors, as this will help make your sketches & notes easier to follow. I'll have one color for datum, one color for elements, and a color for dimensions.

**Paper.** If your company has paper with letterhead, choose that. A grid is also helpful. So is a header with space for information it is important to capture, like date, page number, and total page count

**Write in the rain paper.** Not as pleasant to write with, but good to have in case things get really damp.

**Existing drawings and/or blank sketches.** If you have some idea of what you're going to be documenting, it can be really helpful to have a set of existing drawings you can use to orient yourself. For taking notes, I prefer a 'blank' sketch I've created myself, free of extraneous detail, and often at a larger scale. For example, if you're inspecting a pier, having a pre-drawn elevation of the pier you can mark up with photo #s is more helpful than an elevation already cluttered with rebar layout information that you won't be able to verify anyways.

**Photo log.** No matter how many times I'm convinced I'll be able to reconstruct what I need from my pictures and my notes, I usually wish I had a detailed photolog explaining all my pictures.

## Stuff for in the field
I'm skipping over all the typical PPE, but yes, bring your PPE
Gloves. Some people don't count them as part of standard PPE, but in IMO you should always have a pair.

**Emergency contact info** for the client and your company
A solid bag. One with pockets, pouches, or some other form of internal organization is helpful so you're not constantly rooting through the whole thing.

**Flashlight**

**Headlamp** - one meant to go over your hardhat is best

**Grease pencil** or lumber pencil for marking up stuff

**Camera**

**Measuring tape** - the kind that you press a lever to retract

**Laser measuring tape**

**Calipers**

**Scraper**

**Chipping hammer**

**Sounding hammer**

**A longish stick.**  A longish stick comes in handy more than you'd think.

**Knee pads** or kneeling mat

## Bio needs
**Water**

**DripDrop ORS**

**Kleenex / handkerchief**

**Food** - MealSquares, CliffBars, or similar.

**Field clothes.** I keep jeans, a long-sleeved shirt, jacket, and extra socks in my field kit at all times, so if I'm in business casual at the office and get an urgent call I can easily get geared up.

If you're going to be somewhere remote, **gear for relieving yourself.** TP, trowel, hand sanitizer or wipes. If you could use one, a pStyle or similar stand-to-pee device.

## If it is going to be cold
**Helmet liner**

**Neck warmer / turtle fur**

**Hand / foot warmers.** There are fancy battery powered ones, I usually just use the disposable chemical ones.

**Jacket.** I keep a separate work jacket with my field gear so my nice ones don't get trashed on job sites.

## If it is going to be wet / rainy
**Foul weather gear** / bibs / waders

**Extra changes of clothes**

Wear proper insulating materials, don't be wearing cotton underneath your bibs.

## Stuff for storing the whole damn lot

I have what I believe is a Husky "stackable storage bin" that I keep my field gear in. It is just the right size to fit in the trunk of my hatchback, and holds my field bag, steel toes, hardhat, jacket, and fall protection. (If you store your own fall protection, make sure it is getting turned in on the prescribed basis for a qualified inspection.)

The beauty of having this one bin that hold all my kit is being able to move it easily between my office, house, car, and hotel.

repository: SerializedSam/SerializedCivilJekyll

repo_name: SerializedSam/SerializedCivilJekyll


text:
This is where the magic happens.

## How to use

1. Make sure a `.npmrc` file is present in your repo, which should contain something like: `@faithlife:registry=http://npm.faithlife.io`
1. Run `yarn add @faithlife/styled-ui styled-components@4`.  **Make sure to add styled-ui as a peer dependency to your project if you are hosting it within Faithlife.com (see below)**.
1. Use [webpack-node-externals](https://www.npmjs.com/package/webpack-node-externals) so your bundle does not include styled-ui directly
1. Ship it!

## Guidelines for use
Use the className prop to control margins, font appearance, etc on an imported component. Prefer not to add style hacks that override the contents of the component (such as a style that uses a pseudo selector to display additional content), since the underlying styles could change in a future version update. If you need this level of customization, copy the component and styles into your own project and continue on from there.

If you're using the included Bootstrap components, you can use the [spacing utilities](https://getbootstrap.com/docs/4.1/utilities/spacing/) in the className prop.

## How to contribute

1. Follow the directions on the [Github repo](https://github.com/faithlife/styled-ui)

## Why are peer dependencies necessary for hosted components?

Some third party components within styled-ui depend on a global stylesheet to be loaded on the page. Because these styles are not scoped, we need to ensure the components and the loaded global styles on the page stay in sync. Without using peer dependencies, styled-ui components might reference styles on the page that have not been loaded properly.

`styled-components` also requires that only one instance is running within an app. See the [FAQs](https://www.styled-components.com/docs/faqs) for more information

## If you are writing a library or integration

1. Use [webpack-node-externals](https://www.npmjs.com/package/webpack-node-externals)

If you are writing a package that will be required by someone else, you should exclude your `node_modules` from your Webpack bundle. This webpack plugin makes it easy.
Even if you have correctly set `styled-ui` and `styled-components` as `peerDependencies`, you must still exclude `node_modules`. Webpack does not differentiate between "dependencies" and "peerDependencies" in your `package.json`.

repository: zachsnoek/styled-ui

repo_name: zachsnoek/styled-ui


text:
# layer5io/homebrew-tap
Homebrew Tap for for installing Meshery command line client.

## Usage

```
brew tap layer5io/tap
brew install mesheryctl
```

See [Meshery documentation](https://meshery.layer5.io/docs/installation) for additional usage.

repository: gunjanmimo/homebrew-tap

repo_name: gunjanmimo/homebrew-tap


text:
# Pack.apex
Pack.apex is a tool to help you generate Func wrappers for existing Apex classes.

## Why Pack.apex?
Sometimes when we want to convert an existing Apex API into a Func, we have to manually create a custom Func to implement that. With Pack.apex, you can easily generate Func wrappers according to your selected Apex APIs.

## Dependencies
Pack.apex has a dependency over [R.apex](https://github.com/Click-to-Cloud/R.apex/)

Please include it before including Pack.apex.

## Getting Started

### Installation
You can include the necessary Apex class files located in the 'src/classes'.

Or you can make customizations and generate the Apex class files before including them.

### Introduction
Pack.apex is actually a node-js CLI application that generates the Func wrapper Apex class for you. What you need is the generated Apex class, `Pack.cls`, which can be further imported to your Org, and used like this:

```java
String userId = (String)Pack.UserInfoCls.getUserId.run();
String userName = (String)Pack.UserInfoCls.getUserName.run();
```

Here `UserInfo.getUserId()` is wrapped into a Func `Pack.UserInfo.Cls.getUserId`, and invoked by calling `run`. So is it with `UserInfo.getUserName()`.

By default, Pack.apex has already converted most of Salesforce Apex APIs in the namespace of `System`.

### Naming Conventions
If you want to use a Func of `TypeName.MethodName`, you can refer to `Pack.TypeNameCls.MethodName`. If the `MethodName` is a reserved word, use `Pack.TypeNameCls.MethodNameFn` instead. For example,

```java
List<Object> mList = new List<Object>{ 3, 2, 1};
Pack.ListCls.sortFn.run(mList);
```

### Generate Pack.cls
We can run the CLI application to generate `Pack.cls` at any time.

First we need to initialize our project. Run the code at the root of the project after you have installed node and npm.

```bash
npm install
```

Run this, which will start to generate `Pack.cls`.

```bash
node generator.js
```

By default, Pack.apex will read from `src/packs` and write generated Apex files into `src/classes`.

### Pack Files
The `Pack.cls` is generated from the source pack files. Here is a sample pack file.

```
constructor List<Object> :: ()

add :: Object -> void
```

Each method is specified in one line.

The first word before `::` is the method name. If it is a static method, `static ` is appended before its name. If it is a constructor, `constructor ` is appended before its name and the name is the concrete type name.

The string after `::` is the functionally annotated method signature. Generally speaking, `a -> b -> c` represents a function that takes `(a, b)` and returns `c`.

Pack.apex will load the source pack files and generate corresponding Funcs.

### Hack Files
Sometimes what Pack.apex generates is not what we want, and we can override the generated code by providing our own version, which is placed in hack files.

Here is a hacking code from `List_getSObjectType.hack`, which hacks the `getSObjectType` method of `List` into this.

```
           else if(funcName == 'getSObjectType' && nthArg(args, 1) instanceof List<Object>) {
                List<SObject> mList = (List<SObject>)R.toSObjectList.run(nthArg(args, 1));
                return mList.getSObjectType();
            }
```

### Configuration
You can customize how to generate `Pack.cls` by providing your own configuration in `config.json` in the root of the project.

The default configuration looks like this:

```JSON
{
    "srcDir": "src/packs",
    "destDir": "src/classes",

    "packFileSuffix": ".pack",
    "hackFileSuffix": ".hack",
    "constructorPrefix": "constructor ",
    "staticPrefix": "static ",

    "apexClassName": "Pack",

    "reservedWords": [ ... ],

    "comment": "// Generated by Pack.apex. Please do not modify this file.",
    "metaFile": "meta.xml",

    "generateFuncPackage": true,
    "generateTestClass": true,

    "skipTestCases": [ ... ]
}
```

Here are the details about the configuration items.

| Key | Description |
| --- | ----------- |
| srcDir | The source directory where .pack/.hack files are located |
| destDir | The destination directory where `Pack.cls` is generated to |
| packFileSuffix | The suffix of the pack file, '.pack' by default |
| hackFileSuffix | The suffix of the hack file, '.hack' by default |
| constructorPrefix | The prefix used to indicate the constructor, 'constructor ' by default |
| staticPrefix | The prefix used to indicate the static method, 'static ' by default |
| apexClassName | The generated main Apex class name, 'Pack' by default |
| reservedWords | The reserved key words from Salesforce apex |
| comment | The comment in the generated files |
| metaFile | The path of the meta data xml file |
| generateFuncPackage | Whether to generate Func Package, true by default |
| generateTestClass | Whether to generate test classes, true by default |
| skipTestCases | The list of apex class names whose test cases will be skipped |


text:
# javascriptQuiz

## Overview
This assingment was given to us to help us understand webApis. This last week was a bit challenging and frustrating to use the different lines of codes to put things into local storage or to take things out. After this assingment I am more comfortable with this topic.

My motivation for this project was to better understand the basics of webApi's

I created this assignment because lots of people even me sometimes forget the basics of html css and js. It's nice to go through and relearn everything.

I learned how to put things into local storage and to take it out on a different html. I also learned alot more about how to use flex which wasnt apart of the assingment but it was a huge help

## Installation
Installation is very easy. All you need to do is click play game, try your best ont he questions and you will be given a score according to how many you got right.

## Credits
Credits go out to AskBCS because without them I would of not been able to finish this assignment.

## The Quiz
![Screenshot1](images/Screenshot.png)

## Links
Link to the Quiz: https://koberobinson.github.io/javascriptQuiz/

Link to the GitHub: https://github.com/koberobinson/javascriptQuiz

## License
MIT License

Copyright (c) [2021] [Kobe Robinson]

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

 IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

repository: koberobinson/javascriptQuiz

repo_name: koberobinson/javascriptQuiz


text:
---
layout: article
title: "Running X Window Graphical Application Via SSH"
key: 20161212
lang: en
tags: Linux
---

SSH gives a solution of remote command-line login and remote command execution on Unix-like operating system. If you want to run server's software with GUI on your client however, unlike RFB (VNC) protocol, SSH itself is not applicable to windowing systems and applications at the framebuffer level. But we can enable SSH's X11 forwarding function and launch GUI using a X Window System display server if needed.

# Server setup

First, we need to configure our server (CentOS 7) to make sure it allows X11 forwarding.

Edit configuration file `/etc/ssh/sshd_config`, make sure the option

```
X11Forwarding yes
```

is enabled.

# Client setup

It will be quite easy if you are using a Linux system with GUI installed, which means you already have a X display at the local end. Simply add `-X` option while using `ssh` command:

```shell
$ ssh -X <username>@<hostname or IP address>
```

Then you can launch your GUI apps by command line.

If you are using a Microsoft Windows system, you need two programs installed before using, a SSH client and a X windows display server. Here I recommend two softwares, PuTTY and Xming.

* [PuTTY](http://www.chiark.greenend.org.uk/~sgtatham/putty/) is a free, opensource implementation of SSH and Telnet for Windows and Unix platforms, along with an xterm terminal emulator. Prortable EXE programs are provided on [PuTTY Download Page](http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html).

* [Xming](http://www.straightrunning.com/XmingNotes/) is an X11 display server for Microsoft Windows operating systems. [Public Domain Releases](https://sourceforge.net/projects/xming/files/) of [Xming X Server for Windows](https://sourceforge.net/projects/xming/?source=directory) are provided on SourceForge.

Here is a quick-start:

1. Install Xming, choose `Portable PuTTY Link SSH client - use with Portable PuTTY` while selecting components.
2. Launch Xming, choose `Start no client`
3. Launch SSH client and Enable X11 forwarding (Under category: *SSH -> X11*)
4. Login and enjoy

[This page](http://www.geo.mtu.edu/geoschem/docs/putty_install.html) gives a more detailed tutorial on Installing/Configuring PuTTy and Xming.

# Further reading

* [X Window System - wikipedia](https://en.wikipedia.org/wiki/X_Window_System)

gha_language: SCSS


text:
# EnTest
```
This is an Android app to receive some English articles from emails.
There are some questions with the articles. Within some certain time, the app user
should answer the questions and submit them, then the app will tell the user how many
questions are correctly answered.

The server receives the Android app user's registration (email addresses)  and pushes the English
articles to the app users (email addresses).

This app is suitable for English teacher to send the English reading homework to
a group of students.
```


text:
# Monitoring

The most customizable way of monitoring wasp data processing pipelines is subscribing an actor to Telemetry Actor.

Sometimes that might be an overkill, therefore, two abstract kind of producers have been implemented for users to
extend in order to obtain simple metrics about the data processing pipelines:

- BacklogSizeAnalyzer: outputs the size of the backlog of a Spark ETL
- KafkaThroughput: outputs how many messages have been enqueued on a kafka topic in the last X ms

Both these features are available through abstract producers that should be extended by the user.
Metrics can only be pushed to a Kafka topic. In order to make both kind of producers work, it is needed
that `KafkaCheckOffsetsGuardian` actor is started in the Wasp Producer JVM like the following:

```scala
WaspSystem.actorSystem.actorOf(
      KafkaCheckOffsetsGuardian.props(ConfigManager.getKafkaConfig),
      KafkaCheckOffsetsGuardian.name
    )
```

## BacklogSizeAnalyzer

In order to produce backlog metrics about one or more pipegraphs you should implement
a concrete `BacklogSizeAnalyzerProducerActor` and a `BacklogSizeAnalyzerProducerGuardian`, both are generic in the type
of message that you want to output to the metric kafka topic

```scala
case class Metric(metricName: String, value: Long)
object Metric {
  def fromBacklogInfo(i: BacklogInfo): Metric = Metric(i.eltName + ":" + i.topicName, i.backlogSize)
}

class ImplBacklogSizeAnalyzerProducerGuardian(env: {val producerBL: ProducerBL; val topicBL: TopicBL},
                                              producerName: String) extends BacklogSizeAnalyzerProducerGuardian[Metric](env, producerName) {
  override protected def createActor(kafka_router: ActorRef, kafkaOffsetChecker: ActorRef, topic: Option[TopicModel], topicToCheck: String, etlName: String): BacklogSizeAnalyzerProducerActor[String] = {
    new ImplBacklogSizeAnalyzerProducerActor(kafka_router, kafkaOffsetChecker, topic, topicToCheck, etlName)
  }
}

class ImplBacklogSizeAnalyzerProducerActor(kafka_router: ActorRef,
                                           kafkaOffsetChecker: ActorRef,
                                           topic: Option[TopicModel],
                                           topicToCheck: String,
                                           etlName: String
                                          ) extends BacklogSizeAnalyzerProducerActor[Metric](kafka_router, kafkaOffsetChecker, topic, topicToCheck, etlName) {
  override def toFinalMessage(i: BacklogInfo): Metric = Metric.fromBacklogInfo(i)

  override def generateOutputJsonMessage(input: Metric): String = input.toJson.toString

  override def retrievePartitionKey: Metric => String = _.etlName
}
```

By default the `BacklogSizeAnalyzerProducerGuardian` will read the following configuration (example):

```hocon
wasp.backlogSizeAnalyzer {
  pipegraphs = [{
    pipegraphName = "TestConsoleWriterStructuredJSONPipegraph"
  }]
}
```

This will have the effect of monitoring all the ETL of `TestConsoleWriterStructuredJSONPipegraph`.
It is possible to override this behaviour implementing: `BacklogSizeAnalyzerProducerGuardian.backlogAnalyzerConfigs`

As for every Wasp producer™ you need to create its related model, insert it into WaspDB™ and start it through the
standard REST api.

## KafkaThroughput

In order to produce throughput metrics about one or more kafka topics you should implement
a concrete `KafkaThroughputProducerActor` and a `KafkaThroughputProducerGuardian`, both are generic in the type
of message that you want to output to the metric kafka topic

```scala
case class Metric(metricName: String, value: Long)

class ImplKafkaThroughputProducer(kafka_router: ActorRef,
                                  kafkaOffsetChecker: ActorRef,
                                  topic: Option[TopicModel],
                                  topicToCheck: String,
                                  windowSize: Long,
                                  sendMessageEveryXsamples: Int,
                                  triggerIntervalMs: Long) extends KafkaThroughputProducerActor[MetricInfo](
  kafka_router, kafkaOffsetChecker, topic, topicToCheck, windowSize, sendMessageEveryXsamples, triggerIntervalMs) {

  override protected def toFinalMessage(messageSumInWindow: Long, timestamp: Long): MetricInfo =
    MetricInfo(topicToCheck + "-" + messageSumInWindow)

  override def generateOutputJsonMessage(input: MetricInfo): String = input.toJson.toString

  override def retrievePartitionKey: MetricInfo => String = _.metricName
}

class ImplKafkaThroughputGuardian(env: {val producerBL: ProducerBL; val topicBL: TopicBL}, producerName: String) extends KafkaThroughputProducerGuardian[MetricInfo](env, producerName) {

  override protected def createActor(kafkaActor: ActorRef, topicToCheck: String, triggerInterval: Long, windowSize: Long, sendMessageEveryXsamples: Int): KafkaThroughputProducerActor[MetricInfo] = {
    new ImplKafkaThroughputProducer(kafka_router, kafkaActor, associatedTopic, topicToCheck, windowSize, sendMessageEveryXsamples, triggerInterval)
  }
}
```

By default the `KafkaThroughputProducerGuardian` will read the following configuration (example):

```hocon
kafkaThroughput {
  topics = [{
    topicName: "test_json.topic"
    triggerIntervalMs: 1000
    windowSizeMs: 5000
    sendMessageEvery: 1
  }]
}
```

This will have the effect of monitoring the kafka topics which have "topicName", kafka will be contacted
every "triggerIntervalMs", the metric will output how many messages have been enqueued on the kafka topic in the last
"windowSizeMs", a message will be sent on kafka every "sendMessageEvery" checks on kafka.

For example with this configuration:

- topicName: "test_json.topic"
- triggerIntervalMs: 2000
- windowSizeMs: 60000
- sendMessageEvery: 10

Every 2 seconds the producer will contact Kafka to know the latest offsets of topic `test_json.topic`, the output will
contain the sum of all messages enqueued on `test_json.topic` in the last 60 seconds, a message will be sent on Kafka
output topic every 20 seconds (i.e. 2 * 10 seconds).

It is possible to override this behaviour implementing: `KafkaThroughputProducerGuardian.kafkaThroughputConfigs`.

As for every Wasp producer™ you need to create its related model, insert it into WaspDB™ and start it through the
standard REST api.

repository: agile-lab-dev/wasp

gha_language: Scala

repo_name: agile-lab-dev/wasp


text:
# Xpress.jl

[![Build Status](https://github.com/jump-dev/Xpress.jl/workflows/CI/badge.svg?branch=master)](https://github.com/jump-dev/Xpress.jl/actions?query=workflow%3ACI)
[![codecov](https://codecov.io/gh/jump-dev/Xpress.jl/branch/master/graph/badge.svg)](https://codecov.io/gh/jump-dev/Xpress.jl)

[Xpress.jl](https://github.com/jump-dev/Xpress.jl) is a wrapper for the [FICO Xpress Solver](https://www.fico.com/products/fico-xpress-solver).

It has two components:

 - a thin wrapper around the complete C API
 - an interface to [MathOptInterface](https://github.com/jump-dev/MathOptInterface.jl)

## Affiliation

The Xpress wrapper for Julia is community driven and not officially supported
by FICO Xpress. If you are a commercial customer interested in official support
for Julia from FICO Xpress, let them know.

## License

`Xpress.jl` is licensed under the [MIT License](https://github.com/jump-dev/Xpress.jl/blob/master/LICENSE.md).

The underlying solver is a closed-source commercial product for which you must
[purchase a license](https://www.fico.com/products/fico-xpress-solver).

## Installation

First, obtain a license of Xpress and install Xpress solver, following the
[instructions on the FICO website](https://www.fico.com/products/fico-xpress-solver).

Then, install this package using:
```julia
import Pkg
Pkg.add("Xpress")
```

If you encounter an error, make sure that the `XPRESSDIR` environmental variable
is set to the path of the Xpress directory. This should be part of a standard
installation. The Xpress library will be searched for in `XPRESSDIR/lib` on Unix
platforms and `XPRESSDIR/bin` on Windows.

For example, on macOS, you may need:
```julia
ENV["XPRESSDIR"] = "/Applications/FICO Xpress/xpressmp/"
import Pkg
Pkg.add("Xpress")
```

By default, building Xpress.jl will fail if the Xpress library is not found.
This may not be desirable in certain cases, for example when part of a package's
test suite uses Xpress as an optional test dependency, but Xpress cannot be
installed on a CI server running the test suite. To support this use case, the
`XPRESS_JL_SKIP_LIB_CHECK` environment variable may be set (to any value) to
make Xpress.jl installable (but not usable).

## Use with JuMP

To use Xpress with JuMP, use:

```julia
using JuMP, Xpress
model = Model(Xpress.Optimizer)
set_optimizer(model, "PRESOLVE", 0)
```

## Options

For other parameters use [Xpress Optimizer manual](https://www.fico.com/fico-xpress-optimization/docs/latest/solver/optimizer/HTML/)
or type `julia -e "using Xpress; println(keys(Xpress.XPRS_ATTRIBUTES))"`.

If `logfile` is set to `""`, the log file is disabled and output is printed
to the console ([there might be issues with console output on windows (it is manually implemented with callbacks)](https://www.fico.com/fico-xpress-optimization/docs/latest/solver/optimizer/HTML/OUTPUTLOG.html)).
If `logfile` is set to a file's path, output is printed to that file.
By default, `logfile = ""` (console).

## Callbacks

Solver specific and solver independent callbacks are working in
[MathOptInterface](https://github.com/jump-dev/MathOptInterface.jl) and,
consequently, in [JuMP](https://github.com/jump-dev/JuMP.jl). However, the
current implementation should be considered experimental.

## Environment variables

 - `XPRESS_JL_SKIP_LIB_CHECK`: Used to skip build lib check as previously described.
 - `XPRESS_JL_NO_INFO`: Disable license info log.
 - `XPRESS_JL_NO_DEPS_ERROR`: Disable error when do deps.jl file is found.
 - `XPRESS_JL_NO_AUTO_INIT`: Disable automatic run of `Xpress.initialize()`.
 Specially useful for explicitly loading the dynamic library.

## Skipping Xpress.postsolve

In older versions of Xpress, the command `XPRSpostsolve` throws an error in
infeasible models. In these older versions the post solve should not be
executed. To do this, one can use the `MOI.RawOptimizerAttribute("MOI_POST_SOLVE")`
to skip this routine.

## C API

The C API can be accessed via `Xpress.Lib.XPRSxx` functions, where the names and
arguments are identical to the C API.

See the [Xpress documentation](https://www.fico.com/fico-xpress-optimization/docs/latest/solver/optimizer/HTML)
for details.

## Documentation

For more information, consult the
[FICO optimizer manual](https://www.fico.com/fico-xpress-optimization/docs/latest/solver/optimizer/HTML).

gha_language: Julia


text:
## Reporting the number of started, closed and open cases in a period (DAX)

When reporting the number of sales on a specific day, a relationship between the date table and the order date in the
sales table will save our day. This will not work however, when we need to report the number of employees in a certain
month for example or the number of active cases at the end of the year. This pattern introduces a number of measures
that compute the number of entities started, ended and active in a certain period of time. Note that a period is defined
by the filter that is applied to the date table.

First, let start with the measure that counts the number of unique cases:

    Number of Cases = DISTINCTCOUNT ( Traject[id] )

Compute the number of cases started in the selected period

    Cases started =
    VAR FirstVisibleDate = MIN ( Calendar[Date] )
    VAR LastVisibleDate = MAX ( Calendar[Date] )
    RETURN
        CALCULATE (
            [Number of Cases],
            Traject[startDate] >= FirstVisibleDate,
            Traject[startDate] <= LastVisibleDate
        )

And the number of cases closed in the selected period

    Cases closed =
    VAR FirstVisibleDate = MIN ( Calendar[Date] )
    VAR LastVisibleDate = MAX ( Calendar[Date] )
    RETURN
        CALCULATE (
            [Number of Cases],
            Traject[endDate] >= FirstVisibleDate,
            Traject[endDate] <= LastVisibleDate
        )

Now, the number of cases that are active on the last day of the selected period. These are all the cases that are
started on or before the last date, but are not closed yet.

    Active cases (EOP) =
    VAR LastVisibleDate = MAX ( Calendar[Date] )
    RETURN
        CALCULATE (
            [Number of Cases],
            Traject[startDate] <= LastVisibleDate,
            Traject[endDate] > LastVisibleDate || ISBLANK ( Traject[endDate] )
        )

And a slight variation to the previous measure: the number of cases that was active at any moment in the given period.
This includes cases that started after the first date in the periode and closed before the end of the period, which
would be missed by a measure reporting only on the last day of a period.

    Active cases (IP) =
    VAR FirstVisibleDate = MIN ( Calendar[Date] )
    VAR LastVisibleDate = MAX ( Calendar[Date] )
    RETURN
        CALCULATE (
            [Number of Cases],
            Traject[startDate] <= LastVisibleDate,
            Traject[endDate] >= FirstVisibleDate || ISBLANK ( Traject[endDate] )
        )

repository: nl-hugo/power-bi-snippets

repo_name: nl-hugo/power-bi-snippets


text:
# Encrypted Reboot Vault

Encrypted reboot vault provides an encrypted store for files across reboots in
absence of the TPM (or if the TPM is going to get cleared on the next reboot).
The encrypted reboot vault uses pmsg to store a random key that will be used to
encrypt an fscrypt directory on the stateful partition.

From https://lore.kernel.org/patchwork/patch/532737/:

```
A secured user-space accessible pstore object. Writes
to /dev/pmsg0 are appended to the buffer, on reboot
the persistent contents are available in
/sys/fs/pstore/pmsg-ramoops-[ID].
```

The encrypted reboot vault takes advantage of this utility to transiently
encrypt data across reboots without using a persistent memory store for the
encryption key. On ChromeOS, since all devices are configured with a RAM-based
pstore, the encryption key is never stored on a storage device. In case the
device shuts down or loses power, we lose the encryption key permanently, so
data stored in the encrypted reboot vault will not be recoverable.

The encrypted reboot vault is not a replacement for the encrypted stateful
partition: its primary function is to provide a transient encrypted store for
files in absence of the encrypted stateful partition. An example of this is
during clobber on mount failure: since the TPM is set to be cleared on the
next boot, there isn't a persistent store for the encryption key.

## Expected consumers
The encrypted reboot vault is useful for log/crash data in absence of more
persistent encrypted storage: consider using the encrypted stateful partition
unless it is expected that the encrypted stateful partition may not be
available. Since the encrypted reboot vault is setup with a per-system key, it
should not be used for storing user data under any circumstance.

## Vault lifecycle
The lifetime of the vault encryption key (and by extension, the vault itself)
is tied to when the device is shut down/loses power. Since the encryption key is
maintained exclusively in memory, any loss of power renders the encryption key
irretrievable: on the next boot, the encrypted reboot vault would fail to
retrieve the key from pstore, purge the existing vault and setup a new vault.

## Command line usage
The encrypted reboot vault is set up during startup, either by unlocking an
existing vault:
```
$ encrypted-reboot-vault --action=unlock
```

Alternately, if an existing reboot vault does not exist (or fails to unlock),
a new encrypted reboot vault is created:
```
$ encrypted-reboot-vault --action=create
```

Additionally, the encrypted reboot vault can be removed at any point:
```
$ encrypted-reboot-vault --action=purge
```


text:
# Changelog

## 0.3.2 - 2019-09-24

* Added tag 28 (thanks @twistedfall in #17)

## 0.3.1 - 2018-12-03

* Added a new sanitizer function `strip_stuff_between_messages` in order to get rid of non-confortmant stuff between statements.
  Some banks and tools apparently separate statements with dashes or such. We can't have that!
* Added a convenience `sanitize` function that you can call if you just want your input sanitized but don't care exactly how.
* Added tons of tests and some benchmarks.
* Added official WebAssembly support.

## 0.3.0 - 2018-11-28

* Added sanitizers in order to robustly prepare data for parsing on a best-attempt basis.
* `sta2json` will now try to sanitize input by default before attempting to parse it.
* Added `-s` to `sta2json` which will make it strict and refuse invalid input.
  It won't try to sanitize input in this case.
* Added new `NonStandard` to `TransactionTypeIdentificationCode`.
  This allows for parsing even non-standard codes.
  This was added because every bank seems to be using some custom codes and the ones that are known don't seem to be formally standard anyway.
  They seem to be more of a default set.
  This solution seems like a sensible default.


text:
# `@plnkr/runtime`

No webpack, no parcel, no rollup, no npm, no friction. Just your code and your imagination.

A browser-native tool for running modern javascript code, using npm dependencies without any tooling. Supports hot module reloading and css / less imports (more to come).

This is not for production, this is for experimentation without boilerplate overload or for use in niche developer tools like [Plunker](https://next.plnkr.co/edit). Everything is loaded on the fly and, of course, this will impose certain performance limitations.

## Usage

To get a hold of an instance of this module, all you need to do is:

Using the amazing [jspm.io](https://jspm.io) cdn:

```js
import('https://dev.jspm.io/@plnkr/runtime')
    .then(esModule => esModule.default)
    .then(PlnkrRuntime => {
        // Let your imagination go wild
    });
```

or using a popular cdn that fronts npm releases like [unpkg](https://unpkg.com):

```html
<script src="https://unpkg.com/@plnkr/runtime"></script>
<script>
    const PlnkrRuntime = window.PlnkrRuntime;
    // Get weird
</script>
```

## Example

This example demonstrates an example where we define a custom [react](https://www.npmjs.com/package/react) `Component`, pull this into another file and render it to a string using [react-dom](https://www.npmjs.com/package/react-dom).

> _Note: No npm, no webpack, no parcel, no configuration, no friction. Just code and your imagination._

```js
// We define a mock 'host' filesystem that represents the project we will run
const files = {
    'package.json': JSON.stringify({
        dependencies: {
            react: '16.x',
            'react-dom': '16.x',
        },
    }),
    'index.js': `
        import React from 'react';
        import { renderToString } from 'react-dom/server';

        import Hello from './Hello';

        export const markup = renderToString(<Hello name="World"></Hello>);
    `,
    'Hello.js': `
        import React, { Component } from 'react';

        export default class Hello extends Component {
            render() {
                return <h1>Hello {this.props.name}</h1>;
            }
        }
    `,
};
// Next, we define a host that implements the RuntimeHost interface and resolves files from our mock filesystem
const host = {
    getCanonicalPath(path) {
        if (files[path]) return path;
        if (files[`${path}.js`]) return `${path}.js`;
        return Promise.reject(new Error(`File not found ${path}`));
    },
    getFileContents(canonicalPath) {
        return files[canonicalPath];
    }
};
// Now that we have a host, we can create a runtime instance
const runtime = new PlnkrRuntime.Runtime({ host });

// Now we run our example code that will pull in react and react-dom, will transpile our custom code and will
// then execute it in a context where bare modules are resolved for us.
const { markup } = await runtime.import('./index.js');
```

## API

###  `new PlnkrRuntime.Runtime({ host })`

Creates a new `Runtime` instance where:

-   **host** is an object that implements the [RuntimeHost](#RuntimeHost) interface.

####  `runtime.import(key: string, parentKey?: string): Promise<ModuleInstance>`

Import and run the the code from the canonical url determined by running [`runtime.resolve(key, parentKey)`](#runtime.resolve()).

Returns a `Promise` that will resolve to the module instance.

####  `runtime.invalidate(...keys: string[]): Promise<void>`

Invalidate the module instances, traversing up to all dependent modules and invalidating those as well where:

-   **`keys`** is one or more string arguments whose [`resolved`](#runtime.resolve()) paths will be invalidated.

Returns a `Promise` that will resolve when all requested modules and their dependents have been invalidated.

####  `runtime.resolve(key: string, parentKey?: string): Promise<string>`

Resolve absolute and relative paths and urls as well as bare module specifiers to their canonical url where:

-   **`key`** is a pointer to the file whose code should be imported and executed. This could point to different things:
    -   `./relative/path` in which case the Runtime will attempt to resolve this to a canonical url via the [host.getCanonicalPath](#RuntimeHost.getCanonicalPath()) function. If that function is not present, the canonical url will be assumed to be the `key`.
    -   `npm-module` in which case the Runtime will attempt to resolve the bare module version by attempting to load `./package.json` and find its specifier in the `dependencies` or `devDependencies` mappings. If `./package.json` is absent or no specifier could be resolved, the version will be assumed to be the `latest` tag.
-   **`parentKey`** is an optional url relative to which the `key` will be resolved. For example a `key` of `./foo` and `parentKey` of `./folder/parent` would resolve to `./folder/foo`.

Returns a `Promise` that will resolve to the resolved, canonical url.

###  `RuntimeHost`

This is the interface that must be implemented by the `host` object passed to [`new PlnkrRuntime.Runtime({ host })`](Runtime()).

####  `RuntimeHost.getCanonicalPath?(key: string): string | PromiseLike<string>`

> **Optional**

Return the canonical path or a `Promise` that resolves for a given 'local' resource. A 'local' resource is one that is neither a bare module nor a url whose prefix doesn't match `document.baseURI`. This method should be implemented if you want to support importing relative files without their extensions and these can't be determined _a priori_.

####  `RuntimeHost.getFileContents(key: string): string | PromiseLike<string>`

Return the contents of the file (or a `Promise` thereof) whose canonical path is `key`.

> Note: This interface will be called to resolve bare module versions with `package.json` as the `key`. If you want to control the versions of bare modules (npm modules), then a mock `package.json` can be returned here that defined the `dependencies` for the bare modules whose versions are important to you.

## Thank you

This project was made possible by:

-   All the hard work by the collaborators of [`es-module-loader`](https://github.com/ModuleLoader/es-module-loader).
-   [Guy Bedford](https://twitter.com/GuyBedford) and his [jspm](https://jspm.io) project and its 'magic' ES Module and `System.register` CDNs, `dev.jspm.io` and `system-dev.jspm.io`, respectively.

repository: plnkr/runtime

repo_name: plnkr/runtime


text:
wallboard
=========

GFI Wallboard monitor

At work we use GFI as our remote monitoring application. This service comes with a wallboard monitor to display alerts across our customer base.

We have this up on a big TV on the wall, but in order to check it we need to look up and visually investigate what alerts are showing, or if a server is offline.

This python program (running on a Raspberry Pi) takes a screenshot of a section of the wallboard screen. It then analyses it for any occurances of a pure red pixel (#FF0000). If this is found, then this server is offline.

The program then loops around the next 19 lines checking for more offline servers, stopping when it finds one that is not offline (ie does not have any pure-red pixels).

Then, using the espeak utility, it screams to everyone in the office just how many offline servers there are.

It then continues to alert us of the offline servers every ten minutes (by default).

See comments in the code for any changes. Different resolutions will result in different co-ordinates (this resolution is 1920x1080).

Requirements
------------

Required modules:
- wx
- Image
- espeak

Usage
-----

I have this running in an init.d script to start when the Pi starts. If you want to run it manually, use

*python /path/to/file/gfimon.py*

**NOTE:** If you have more than one screen, change line 9 in *gfimon.py* to be the relevant screen you want (program is currently set to use main screen)

repository: cizzit/wallboard

repo_name: cizzit/wallboard


text:
# DSC TrustList Update API

To be able to validate [Digital COVID Certificates](https://ec.europa.eu/info/live-work-travel-eu/coronavirus-response/safe-covid-19-vaccines-europeans/eu-digital-covid-certificate_en) (DCCs) from different EU countries, the national verifier apps need to retrieve a list of public keys from all possible issuing authorities. Those are called Document Signing Certificates (DSCs).
As more institutions get authorised to issue vaccination certificates, this list has to be maintained and synchronised to the verifier apps.

For an EU wide synchronisation of the list of issuing authorities, the EU commission installed a centralised service called the [EU DCC Gateway](https://github.com/eu-digital-green-certificates/dgc-gateway): a collection of REST API endpoints to upload individual DSCs as well as [fetch the latest list of all DSCs](https://eu-digital-green-certificates.github.io/dgc-gateway/#/Trust%20Lists/downloadTrustList).
Only EU Member States are allowed to access the EU Gateway (secured via mTLS), so every country must additionally provide the collection of their acknowledged DSCs via a national backend.
Bilateral exchanges are not prohibited, and private institutions (airlines, commercial verifying vendors) might request access to the national endpoint.
A removal of a DSC from the EU Gateway by a member state will be propagated to all verifier apps and is to be seen as invalidating all DCCs signed by this DSC.

This API spec defines the endpoint for the national backend that offers the list of Trusted DSCs to the verifier apps for seal verification.
A periodical request to the EU Gateway (~ every 6h) is made to fetch the latest set of all DSCs from all EU member states connected to the EU gateway.
As the national backend is public, an additional signature element is added to the overall content provided by the EU Gateway.

## Data Schema

The data structure that gets delivered looks as follows (inspired by the [COSE object](https://cose-wg.github.io/cose-spec/#rfc.appendix.C.1)):

```json
o3SWKd9PKKaQcLqc+z0F6IJAK6lxaw/B1JCWETB9EZBYgT8F/+R29+vedCO/Wkz0aXgi8SOGkXIr2rW9fEk/Jg==
{"certificates" : [
    {
        "certificateType": "DSC",
    "country": "DE",
    "kid": "qroU+hDDovs=",
    "rawData": "MIICyDCCAbCgAwIBAgIGAXR3DZUUMA0GCSqGSIb3DQEBBQUAMBwxCzAJB ... Jpux30QRhsNZwkmEYSbRv+vp5/obgH1mL5ouoV5I=",
    "signature": "o53CbAa77LyIMFc5Gz+B2Jc275Gdg/SdLayw7gx0GrTcinR95zfTLr8nNHgJMYlX3rD8Y11zB/Osyt0...W+VIrYRGSEmgjGy2EwzvA5nVhsaA+/udnmbyQw9LjAOQ==",
    "thumbprint": "aaba14fa10c3a2fb441a28af0ec1bb4128153b9ddc796b66bfa04b02ea3e103e",
    "timestamp": "2021-05-12T21:48:50.583Z",
    },
...
]}
```

- On the first line the base64 encoded signature of the contents of from the second line
- On the second line a JSON map that looks the following:

As such we provide as data structure a list of entries each representing a Document Signing Certificate (DSC - field 'rawData') along with metadata, most notably the [kid](https://github.com/ehn-dcc-development/hcert-spec/blob/main/hcert_spec.md#333-key-identifier). An overall signature on the first line ensures that this list can be guaranteed to be complete as well as integer.
The signature over the Trusted List is calculated by building the SHA-256 hash over the JSON content of the second line, then signing it via ECDSA using prime256v1.

## DGC Update / DCC Verification Flow

The high level flow for the DSC Update and DCC verification looks as follows:
![](Ablaufdiagramm_validationFlowCertificate.png)

As can be seen in the diagram, the request for the latest list of trusted DGCs is decoupled from the actual DCC verification, which can be done offline.
When updating the TrustedList of Document Signing Certificates (DSCs) it is important to check the authenticity and integrity  of the list via the 'signature' field.

gha_language: HTML


text:
# Hammer Time!

![Thors Hammer crashing down](http://33.media.tumblr.com/85d64e2f846797ab471480cff3f33d4b/tumblr_mzms7yMfum1s75u1lo2_500.gif)

## On your click times!

#### Response time on user actions is important

Keeping visual response to under 100ms means your users will not notice the delay. The UI will feel quick and responsive giving users the impression they are doing the work instead of the application. Try the boxes below to see the response time on mobile devices.

The first box uses `touch-action:none;` to remove the 300ms delay. The second box has no `touch-action` property set. On touch screens you will see a noticeable difference in the response time of the background and in the outputting of the end vs click events.

The `touch-action` css property is part of the Pointer Events spec [http://www.w3.org/TR/pointerevents/#the-touch-action-css-property](http://www.w3.org/TR/pointerevents/#the-touch-action-css-property)

Unfourtanitly not all common browsers support touch action yet ( [caniuse](http://caniuse.com/#feat=css-touch-action) ) so hammer-time works by partially polyfills this property. The only supported value is `none`, `manipulation`, or `auto`

### Advantages...

*   Size Hammer-time is very very small only 417 bytes gzipped
*   Easy to use no special libraries or events to bind. Hammer-time just speeds up the native events so you can use your favorite event library like jQuery or just plain old `addEventListener`
*   Based on real standards, Hammer-time is a polyfill so it is a complete noop on browsers which support native `touch-action`
*   Avoids target mismatches between the `touchend` and `click` events

### Gotchas...

*   **Only works when applied directly to the style attribute on an element not to a stylesheet**
*   Does not prevent scrolling or other behaviors which happen on move or double tap zoom
*   You cannot set the touch-action property via `element.style[ touch-action ]` browsers that do not support touch action will ignore this
*   Removing the touch-action property from an existing element is not supported, Hammer-time has no way of knowing the difference between you removing the property and it being removed as a result or browser sanitization. Instead of removing the property completely simply change it to the default value of auto
*   Direct manipulation of the style property in a loop on elements with touch-action set from JavaScript ( JS animations for example ) should be avoided. Because of how browsers sanitize the style attribute when setting properties we use a mutation observe to restore the the touch action property when it is removed
*	To properly support IE10 you need to add both `touch-action` and `-ms-touch-action`

To read more about UI response times and how this effects user experience see [http://www.nngroup.com/articles/response-times-3-important-limits/](http://www.nngroup.com/articles/response-times-3-important-limits/)

gha_language: JavaScript


text:
   <image src="/src/assets/battleship-logo-png-transparent.png" width="40%">

Battleship I used React, HTML, CSS & JavaScript for this project.

  Screenshots •
  Goals •
  Summary •
  Author •
    Credits •
  License

### ✨ [Live Preview](https://timjacksonm.github.io/Battleship/)

## Screenshots

  Show Image

<image src="/src/assets/gameplay.gif">

<image src="/src/assets/screenshot.png">

## Goals:

- [✔] Create a Ship factory function
- [✔] Create a Gameboard factory function
- [✔] Create two players with one being the computer
- [✔] Write test with Jest for the public interface of each object
- [✔] Create the main game loop

**View Commits on project to see changes**

## Summary

The focus of this project was getting familiar writing TDD code. Writing test with jest was easy enough to pick up! I can't wait to get more familiar writing test first so I don't rely on console.logs as much in the future! The game of Battleship lets you place 2x submarines, 2x Destroyers, 1x Cruiser, 1x Battleship, 1x Aircraft Carrier on your board.
Room for improvements: Allow user & computer player to place ship vertically. Add more styles. Add difficulty setting to computer.

## Author

👤 **Tim Jackson**

- Github: [@timjacksonm](https://github.com/timjacksonm)
- Twitter [@timjacksonm](https://twitter.com/timjacksonm)
- LinkedIn [@timjacksonm](https://linkedin.com/in/timjacksonm)

## Credits

This project idea was a part of my studies at The Odin Project's curriculum. You can see the lesson here!

## License

repository: timjacksonm/Battleship

repo_name: timjacksonm/Battleship


text:
# vue-typed

* [Installation](installation.md)
* [Getting Started](getting-started.md)
* Basic Usage
	* [Component](usage/component.md)
	* [Options](usage/options.md)
	* [Methods and Computed Properties](usage/methods-and-computed-properties.md)
	* [Prop](usage/props.md)
	* [Watch](usage/watch.md)
	* [Virtual](usage/virtual.md)
	* Mixins
		* [Single Mixin](usage/mixins/single.md)
		* [Multiple Mixins](usage/mixins/multiple.md)
		* [Global Mixins](usage/mixins/global.md)
* Advanced Usage
	* [VueRouter](advanced/vue-router.md)
	* [Class Inheritance](advanced/class-inheritance.md)
* Examples
	* [Todo MVC](examples/todo-mvc.md)

repository: vue-typed/vue-typed

branch_name: refs/heads/dev

repo_name: vue-typed/vue-typed


text:
---
layout: post
title: "Dave Parker"
date: 2022-01-28 12:22:40
image: '/assets/img/makers/Parker.jpg'
description: Loomis, California, USA
 Retired Software Engineer and STEM Educator
category: ''
tags:
- MINDSTORMS
- RobotInventor
- Educator
- Coach/Mentor
twitter_text:
introduction: Loomis, California, USA
 Retired Software Engineer and STEM Educator
---

## Bio

Dave has been working with LEGO MINDSTORMS on and off since the first version in 1998. Originally a software engineer, he moved into education and started a school robotics club and then got heavily involved in FLL as a coach, mentor, judge, and referee. When NXT came out in 2006, he noticed that the kids needed help with both building with Technic and programming, so he started posting some examples to a website which became nxtprograms.com and grew to have over over 150 projects for various versions of the NXT kits and lots of users around the world.

He then got invited to the LEGO MINDSTORMS Community Partner (MCP) group and helped consult a bit on the development of EV3, including writing some of the documentation for the programming blocks. During this time he also worked as a trainer for LEGO Education and as an independent robotics educator working with LMS, Vex, and Vex IQ. Life changed for him around the time EV3 came out, and he switched to teaching introductory Computer Science at the local community college and didn’t have time left to build with LMS himself for several years.

When COVID hit and schools went online, he took time off from teaching, eventually got bored and then picked up LMS again with the Robot Inventor kit. He is now happy to be building again and posting projects for Robot Inventor to his new website at OneKitProjects.com.

Website: [OneKitProjects](https://OneKitProjects.com)


text:
# Chapter 16
## Observe Their Habits

| Original | English Translation |
| -: | -- |
| 致 虛 極 | refine the utmost emptiness |
| 守 靜 篤 | protect the deep-true peace |
| 萬 物 並 作 | 10k-things together interacting |
| 吾 以 觀 其 復 | as we observe thier habits |
| 夫 物 芸 芸 | these 10k diverse varieties |
| 各 復 歸 其 根 | each continually returning to its origin |
| 歸 根 曰 靜 | returning to origin means to be at peace |
| 靜 是 謂 復 命 | at peace, which is to say, continuing in its own-purpose |
| 復 命 曰 常 | to be continually in its own-purpose means to behave-naturally |
| 知 常 曰 明 | to-know natural-behavior means to understand |
| 不 知 常 妄 作 凶 | not to-know natrual-behavior causes reckless mishaps |
| 知 常 容 | to-know natural-behavior (causes) restraint |
| 容 乃 公 | restraint then wisdom |
| 公 乃 王 | wisdom then sovereignty |
| 王 乃 天 | sovereignty then heaven |
| 天 乃 道 | heaven then the Way |
| 道 乃 久 | the Way then eternity |
| 沒 身 不 殆 | where the death of the life-body is no concern |

## My Comments:
I find this chapter incredibly insiteful

I'm not sure if this is advice on how to manage things and people through observatiion and careful restraint.
Or it if it is advice on how to step away from the crazy and observe your own thoughts and interests and understand them in order to become sovereign over yourself.

Perhaps this chapter (and others) is about the outer universe as well as the inner universe.

repository: brentoboy/dao-de-jing

repo_name: brentoboy/dao-de-jing