text:
> [Go to French version](/fr/Règlements/Décrets,%20ordonnances%20et%20règlements%20statutaires/2006/6.md)

# Public Service Staffing Complaints Regulations

**SOR/2006-6**

Enabling authorities:
- [PUBLIC SERVICE EMPLOYMENT ACT](/en/Acts/Statutes%20of%20Canada/2003/c.%2022,%20ss.%2012,%2013%20.md)

Date registered: 23 December 2005

----------

The Public Service Staffing Tribunal, pursuant to section 109 of the [Public Service Employment Act](/en/Acts/Statutes%20of%20Canada/2003/c.%2022,%20ss.%2012,%2013%20.md)[a], hereby makes the annexed Public Service Staffing Tribunal Regulations.

a: S.C. 2003, c. 22, ss. 12 and 13

Ottawa, December 22, 2005

## Interpretation

**Definitions**

**1**

- **(1)** The following definitions apply in these Regulations.

***Act*** means the [Public Service Employment Act](/en/Acts/Statutes%20of%20Canada/2003/c.%2022,%20ss.%2012,%2013%20.md). (*Loi*)

***day*** means a calendar day. (*jour*)

***Executive Director***[Repealed, SOR/2014-250, s. 2]

***intervenor*** means anyone who is allowed under subsection 19(4) to intervene in the hearing of a complaint. (*intervenant*)

***party*** means anyone who has a right to be heard under subsection 65(3), section 75, subsection 79(1) or section 85 of the Act. (*partie*)

***standardized test***[Repealed, SOR/2011-116, s. 1]

***writing*** includes, with respect to a person with a disability that affects the capacity to communicate in writing, any means of communication that can be used and understood by that person and that may be retained. (*écrit*)

**Canadian Human Rights Commission**

- **(2)** For the purposes of these Regulations, the Canadian Human Rights Commission is a participant in a proceeding in relation to a complaint if the Canadian Human Rights Commission has given notice under subsection 20(3) that it intends to make submissions regarding an issue raised by the complainant involving the interpretation or the application of the [Canadian Human Rights Act](/en/Acts/Revised%20Statutes%20of%20Canada/H/H-6.md).

**References to “the deputy head or the Commission”**

- **(3)** In these Regulations, a reference to “the deputy head or the Commission”, in the context of a complaint, means
	- **(a)** the deputy head, in any case where the complaint relates to a lay-off, revocation, appointment or proposed appointment in respect of which the Commission has authorized the deputy head under section 15 of the Act to exercise or perform any of the Commission’s powers and functions; and
	- **(b)** the Commission, in any other case.
> SOR/2011-116, s. 1; SOR/2014-250, s. 2.

## Application

**Application**

**2** These Regulations apply to all complaints made to the Board under subsection 65(1) or section 74, subsection 77(1) or section 83 of the Act.
> SOR/2014-250, s. 8.

## General Provisions

**When notice considered received**

**3** A notice that is sent to a party, an intervenor or the Canadian Human Rights Commission is considered to have been received by the party, the intervenor or the Canadian Human Rights Commission on
- **(a)** if the notice is sent by electronic means such as electronic mail or fax transmission, the day on which it is sent;
- **(b)** if the notice is sent by courier or delivered by hand, the day on which it is received; and
- **(c)** if the notice is sent by mail, the day that is six days after
	- **(i)** the date of the postmark or the date of the postage meter impression authorized by the Canada Post Corporation, or
	- **(ii)** if both the postmark and the postage meter impression appear on the envelope, the later of them.

**Alternate methods of providing notices and other documents**

**4** Despite any provisions of these Regulations, the Board may, in the interest of fairness, establish alternate methods of providing notices and other documents.
> SOR/2014-250, s. 8.

**Amendment of time**

**5**

- **(1)** A party may request the Board to extend or reduce the time within which a complaint may be made or within which notices and other documents must be given in relation to a complaint.

**Submissions**

- **(2)** Before determining whether to extend or reduce the time, the Board must provide the other parties an opportunity to make submissions respecting the request.

**Determination**

- **(3)** The Board must determine whether it is in the interest of fairness to extend or reduce the time and, if it is, the length of the extension or reduction.
> SOR/2011-116, s. 2; SOR/2014-250, s. 8.

**6** [Repealed, SOR/2011-116, s. 2]

**Computation of time**

**7** A time period calculated under these Regulations that ends on a Saturday or a holiday is extended to end on the next day after that is not a Saturday or a holiday.

**Consolidation of proceedings**

**8** To ensure the expeditious resolution of complaints, the Board may direct that proceedings be consolidated and may issue directions in respect of the conduct of the consolidated proceedings.
> SOR/2011-116, s. 3; SOR/2014-250, s. 8.

**Informal and expeditious proceeding**

**8.1** For the purposes of section 5, subsection 17(4) and sections 19 and 27, the Board may deal with a proceeding as informally and expeditiously as the circumstances and the considerations of fairness permit.
> SOR/2014-250, s. 3.

**Technical irregularity**

**9** No proceeding is invalid by reason only of a defect in form or a technical irregularity.

## Making a Complaint

**Time for making complaint**

**10**

- **(1)** A complaint must be received by the Board no later than 15 days after
	- **(a)** the day on which the complainant receives notice of the lay-off, revocation, appointment or proposed appointment to which the complaint relates; or
	- **(b)** the date specified in the notice, if it is a public notice.

**Receipt of complaint**

- **(2)** A complaint is considered to have been received by the Board on
	- **(a)** if the complaint is sent by electronic means such as electronic mail or fax transmission, the day on which it is sent;
	- **(b)** if the complaint is sent by courier or delivered by hand, the day on which it is received; or
	- **(c)** if the complaint is sent by mail, the day that is
		- **(i)** the date of the postmark or the date of the postage meter impression authorized by the Canada Post Corporation, or
		- **(ii)** if both the postmark and the postage meter impression appear on the envelope, the later of them.
> SOR/2011-116, s. 4; SOR/2014-250, s. 8.

**Form and content of complaint**

**11** A complaint must be filed with the Board in writing and must include
- **(a)** the name, telephone number and fax number of the complainant, and a mailing address or electronic mail address that can be disclosed to all parties;
- **(b)** [Repealed, SOR/2011-116, s. 5]
- **(c)** the name, address, telephone number, fax number and electronic mail address of the complainant’s authorized representative, if any;
- **(d)** the number or identifier, if any, of the process to which the complaint relates;
- **(e)** a copy of the notice of lay-off, revocation, appointment or proposed appointment to which the complaint relates;
- **(f)** the name of the department or agency, branch or sector involved in the process to which the complaint relates;
- **(g)** a reference to the provision of the Act under which the complaint is made;
- **(h)** a full factual description of the events, circumstances or actions giving rise to the complaint, to the extent known by the complainant;
- **(i)** the signature of the complainant or their authorized representative; and
- **(j)** the date of the complaint.
> SOR/2011-116, s. 5; SOR/2014-250, s. 7.

**Procedure on receipt of complaint**

**12** On receiving the complaint, the Board must acknowledge its receipt and send a copy of it and all supporting documents to the deputy head or the Commission.
> SOR/2011-116, s. 6; SOR/2014-250, s. 7.

**Names and addresses of parties**

**13** Within 10 days after receiving a copy of the complaint and all supporting documents, the deputy head or the Commission must provide the Board with the names and business addresses of the other parties, including their electronic mail addresses, if any.
> SOR/2011-116, s. 6; SOR/2014-250, s. 7.

**Copies to be provided**

**14** On receiving the names and addresses of the other parties, the Board must send a copy of the complaint and all supporting documents to each of the other parties.
> SOR/2011-116, s. 6; SOR/2014-250, s. 7.

## Alternate Dispute Resolution Processes

### Mediation

**Participation in mediation**

**15**

- **(1)** The Board must schedule mediation for a complaint unless
	- **(a)** the complainant informs the Board, no later than 25 days after the date of the letter by which the Board acknowledges receipt of the complaint, that the complainant does not wish to participate in mediation; or
	- **(b)** the deputy head or the Commission informs the Board, no later than 25 days after the deputy head or the Commission receives a copy of the complaint, that they do not wish to participate in mediation.

**Request to mediate**

- **(2)** The complainant, the deputy head or the Commission may, with the agreement of the other party, request mediation of the complaint by informing the Board of that request before the date of the hearing.
> SOR/2011-116, s. 7; SOR/2014-250, ss. 4(E), 7.

### Exchange of Information

**Exchange of information**

**16**

- **(1)** In the interest of facilitating the resolution of the complaint, the complainant and the deputy head or the Commission must, as soon as possible after the complaint has been filed, exchange all relevant information regarding the complaint.

**Time for the exchange**

- **(2)** The exchange of information must be completed no later than 25 days after the date of the letter by which the Board acknowledges receipt of the complaint.

**Order to exchange information**

- **(3)** If the complainant, the deputy head or the Commission does not complete the exchange of all relevant information as required by subsections (1) and (2), the Board may order the parties to complete the exchange of all relevant information within the time specified by the Board.
> SOR/2011-116, s. 8; SOR/2014-250, ss. 7, 8.

### Order to Provide Information

**Request for order to provide information**

**17**

- **(1)** If a party refuses to provide information, the complainant, the deputy head or the Commission may, after the time provided for the exchange of information, request the Board to order that the information be provided.

**Form and content of request**

- **(2)** The request for an order to provide information must be in writing and must include
	- **(a)** the name, address, telephone number, fax number and electronic mail address of the party making the request;
	- **(b)** the Board’s file number for the complaint to which the request relates;
	- **(c)** a list specifying the documents or information requested;
	- **(d)** a detailed explanation as to why each requested item is relevant to the complaint; and
	- **(e)** the date of the request.

**Suspension of time**

- **(3)** Any time that is specified in these Regulations in relation to a complaint, notice or document is suspended until the Board renders a decision respecting the request for an order to provide information.

**Order to provide information**

- **(4)** The Board must order that the complainant, the deputy head or the Commission be provided with the information if the Board determines that the information may be relevant and that its provision will not
	- **(a)** threaten national security;
	- **(b)** threaten any person’s safety; or
	- **(c)** affect the validity or continued use of a standardized test, or any part of such a test, or distort the results of a standardized test by giving an unfair advantage to any individual.

**Conditions**

- **(5)** The Board may make the order to provide information subject to any conditions that it determines are necessary, including any conditions that are necessary to prevent any of the risks referred to in paragraphs (4)(a) to (c).

**Duration of conditions**

- **(6)** The conditions apply before and after the hearing or after any other resolution or disposition of the complaint.
> SOR/2011-116, s. 9; SOR/2014-250, s. 8.

### Restriction on Use of Information

**Use of information obtained**

**18** Any information obtained under sections 16 and 17 may be used only for purposes of the complaint.
> SOR/2011-116, s. 10(E).

## Intervenors

**Application to intervene**

**19**

- **(1)** Anyone with a substantial interest in a proceeding before the Board may apply to the Board for permission to intervene in the proceeding.

**Form and content of application**

- **(2)** The application must be in writing and must include
	- **(a)** the applicant’s name, address, telephone number and fax number, and a mailing address or electronic mail address that is to be used for sending documents to the applicant;
	- **(b)** [Repealed, SOR/2011-116, s. 11]
	- **(c)** the name, address, telephone number, fax number and electronic mail address of the applicant’s authorized representative, if any;
	- **(d)** the Board’s file number for the complaint that is the subject of the application;
	- **(e)** the grounds for intervention and the interest of the applicant in the matter;
	- **(f)** the contribution that the applicant expects to make if allowed to intervene;
	- **(g)** the signature of the applicant or their authorized representative; and
	- **(h)** the date of the application.

**Representations**

- **(3)** The Board must give the parties and the Canadian Human Rights Commission, if it is a participant, the opportunity to make representations in respect of the application.

**Allowing the application**

- **(4)** The Board may allow the applicant to intervene after considering the following factors:
	- **(a)** whether the applicant is directly affected by the proceeding;
	- **(b)** whether the applicant’s position is already represented in the proceeding;
	- **(c)** whether the public interest or the interests of justice would be served by allowing the applicant to intervene; and
	- **(d)** whether the input of the applicant would assist the Board in deciding the matter.

**Directions to intervenor**

- **(5)** In allowing the application, the Board may issue directions regarding the role of the intervenor, including any matter relating to the procedure to be followed by the intervenor.
> SOR/2011-116, s. 11; SOR/2014-250, ss. 5(F), 8.

## Notice to the Canadian Human Rights Commission

**Notice of issue**

**20**

- **(1)** If the complainant raises an issue involving the interpretation or application of the [Canadian Human Rights Act](/en/Acts/Revised%20Statutes%20of%20Canada/H/H-6.md) in a complaint made under subsection 65(1) or 77(1) of the Act, the complainant must give notice to the Canadian Human Rights Commission under subsection 65(5) or section 78 of the Act. The notice must be in writing and must include
	- **(a)** a copy of the complaint;
	- **(b)** the complainant’s name, telephone number and fax number, and a mailing address or electronic mail address that can be disclosed to all parties;
	- **(c)** the name, address, telephone number, fax number and electronic mail address of the complainant’s authorized representative, if any;
	- **(d)** a description of the issue involving the interpretation or the application of the [Canadian Human Rights Act](/en/Acts/Revised%20Statutes%20of%20Canada/H/H-6.md) and of the alleged discriminatory practice or policy;
	- **(e)** the prohibited ground of discrimination involved;
	- **(f)** the corrective action sought;
	- **(g)** the signature of the complainant or the complainant’s authorized representative; and
	- **(h)** the date of the notice.

**Copies to be provided**

- **(2)** The complainant must give a copy of the notice to each of the other parties, to the Board and to each of the intervenors, if any. Those copies do not need to include copies of the complaint.

**Notice of intention to make submissions**

- **(3)** The Canadian Human Rights Commission must, no later than 15 days after receiving the notice, notify the Board whether or not it intends to make submissions regarding the issue referred to in paragraph (1)(d).

**Board to provide copies**

- **(4)** The Board must provide a copy of the notice from the Canadian Human Rights Commission to each of the parties and each of the intervenors, if any.
> SOR/2011-116, s. 12; SOR/2014-250, s. 7.

## Time Period for Raising Timeliness Objection

**Time period**

**21**

- **(1)** If the deputy head or the Commission or a person appointed or proposed for appointment wishes to object that the complaint was not made within the period required by section 10, they must do so before the end of the period for exchanging information.

**Form and content of objection**

- **(2)** The objection must be in writing and must include
	- **(a)** the name, address, telephone number, fax number and electronic mail address of the objecting party;
	- **(b)** the name, address, telephone number, fax number and electronic mail address of the objecting party’s authorized representative, if any;
	- **(c)** the Board’s file number for the complaint;
	- **(d)** the facts and any documents on which the objecting party relies in making the objection; and
	- **(e)** the date of the objection.
	- **(f)** [Repealed, SOR/2011-116, s. 13]
> SOR/2011-116, s. 13; SOR/2014-250, s. 8.

## Allegations

**Time period**

**22**

- **(1)** The complainant must provide his or her allegations to each of the other parties, to the Board, to each of the intervenors, if any, and to the Canadian Human Rights Commission, if it is a participant, no later than 10 days after the end of the period for exchanging information.

**Form and content of allegations**

- **(2)** The allegations must be in writing and must include
	- **(a)** the complainant’s name, telephone number and fax number, and a mailing address or electronic mail address that can be disclosed to all parties;
	- **(b)** the name, address, telephone number, fax number and electronic mail address of the complainant’s authorized representative, if any;
	- **(c)** the Board’s file number for the complaint;
	- **(d)** a detailed description of the allegations on which the complainant intends to rely and full particulars of the relevant facts; and
	- **(e)** [Repealed, SOR/2011-116, s. 14]
	- **(f)** the date of the document.

**Failure to provide allegations**

- **(3)** If the complainant fails to provide allegations, the Board may dismiss the complaint.
> SOR/2011-116, s. 14; SOR/2014-250, ss. 7, 8.

**New or amended allegation**

**23**

- **(1)** The Board must, on request, permit the complainant to amend an allegation or provide a new allegation if
	- **(a)** the amendment or new allegation results from information obtained that could not reasonably have been obtained before the complainant submitted his or her original allegations; or
	- **(b)** it is otherwise in the interest of fairness to do so.

**Form and content of request**

- **(2)** The request must be in writing and must include
	- **(a)** the name, telephone number and fax number of the complainant, and a mailing address or electronic mail address that can be disclosed to all parties;
	- **(b)** the name, address, telephone number, fax number and electronic mail address of the complainant’s authorized representative, if any;
	- **(c)** the Board’s file number for the complaint;
	- **(d)** a detailed explanation as to why the complainant did not include the allegation with his or her original allegations or as to why the complainant needs to amend his or her allegations, as the case may be;
	- **(e)** the new or amended allegation; and
	- **(f)** [Repealed, SOR/2011-116, s. 15]
	- **(g)** the date of the request.
> SOR/2011-116, s. 15; SOR/2014-250, ss. 6(F), 8.

## Reply from the Deputy Head or the Commission

**Deadline for reply**

**24**

- **(1)** The deputy head or the Commission, as respondent, must provide its reply to each of the other parties, to the Board, to each of the intervenors, if any, and to the Canadian Human Rights Commission, if it is a participant, no later than 15 days after receiving the complainant’s allegations or amended allegations.

**Form and content of reply**

- **(2)** The reply must be in writing and must include
	- **(a)** the name, address, telephone number, fax number and electronic mail address of the respondent;
	- **(b)** the name, address, telephone number, fax number and electronic mail address of the respondent’s authorized representative, if any;
	- **(c)** the Board’s file number for the complaint;
	- **(d)** a full response to any allegations or issues raised in the complaint and full particulars of any additional relevant facts on which the respondent intends to rely; and
	- **(e)** [Repealed, SOR/2011-116, s. 16]
	- **(f)** the date of the reply.
> SOR/2011-116, s. 16; SOR/2014-250, ss. 7, 8.

## Other Parties’ Replies

**Other parties may reply**

**25**

- **(1)** If another party wishes to participate in the hearing, he or she must provide his or her reply to the complainant, to the deputy head or the Commission, to the Board, to the other parties, to each of the intervenors, if any, and to the Canadian Human Rights Commission, if it is a participant, no later than 10 days after receiving the reply of the deputy head or the Commission.

**Form and content of reply**

- **(2)** The reply must be in writing and must include
	- **(a)** the name, address, telephone number, fax number and electronic mail address of the party;
	- **(b)** the name, address, telephone number, fax number and electronic mail address of the party’s authorized representative, if any;
	- **(c)** the Board’s file number for the complaint;
	- **(d)** a full response to any allegations or issues raised in the complaint and full particulars of any additional relevant facts on which the party intends to rely; and
	- **(e)** [Repealed, SOR/2011-116, s. 17]
	- **(f)** the date of the reply.
> SOR/2011-116, s. 17; SOR/2014-250, ss. 7, 8.

## Withdrawal of Complaint

**Notice of withdrawal**

**26**

- **(1)** If a complainant wishes to withdraw his or her complaint, the complainant must file a written notice of the withdrawal with the Board.

**Content of notice**

- **(2)** The notice of withdrawal must include
	- **(a)** the complainant’s name, telephone number and fax number, and a mailing address or electronic mail address that can be disclosed to all parties;
	- **(b)** the name, address, telephone number, fax number and electronic mail address of the complainant’s authorized representative, if any;
	- **(c)** the Board’s file number for the complaint;
	- **(d)** a statement that the complainant wishes to withdraw the complaint;
	- **(e)** the signature of the complainant or the complainant’s authorized representative; and
	- **(f)** the date of the withdrawal.

**Notice to other parties and intervenors**

- **(3)** On receiving the notice of withdrawal, the Board must give notice to each of the other parties, to each of the intervenors, if any, and to the Canadian Human Rights Commission, if it is a participant, that the complaint has been withdrawn and the file has been closed.
> SOR/2011-116, s. 18; SOR/2014-250, ss. 7, 8.

## The Hearing

**Master of proceedings**

**27** The Board is master of the proceedings and may determine the manner and order of the presentation of evidence and arguments at the hearing.
> SOR/2014-250, s. 8.

**Notice of hearing**

**28**

- **(1)** The Board must give notice of the date, time and place of the hearing to each of the parties, to each of the intervenors, if any, and to the Canadian Human Rights Commission, if it is a participant.

**Notice period**

- **(2)** Unless the matter is urgent, the notice must be given at least seven days before the date of the hearing.
> SOR/2014-250, s. 7.

**Failure to appear**

**29** If a party, an intervenor or the Canadian Human Rights Commission, if it is a participant, does not appear at the hearing of a complaint or at any continuance of the hearing and the Board is satisfied that notice of the hearing was sent to that party, intervenor or participant, the Board may proceed with the hearing and dispose of the complaint without further notice.
> SOR/2011-116, s. 19(F); SOR/2014-250, s. 8.

**Adjournment of hearing**

**30** The Board may adjourn a hearing and must advise of the day, time, place and terms of its continuance.
> SOR/2014-250, s. 8.

## Coming into Force

**Coming into force**

**31** These Regulations come into force on the later of the day on which they are registered and December 31, 2005.

repository: TravisMadill/CanadianLaws

path: /en/Regulations/Statutory Orders and Regulations/2006/6.md

repo_name: TravisMadill/CanadianLaws


text:
# Submitty API Reference

This is the API reference website for [Submitty](http://submitty.org) the RPI Homework Submission Server.

To report issues for this repository, please file them under the [Submitty/Submitty](https://github.com/Submitty/Submitty) repository.

## Developers

Run the following commands locally.

```bash
bundle install
bundle exec middleman server
```

You can now see the docs at http://localhost:4567/.

branch_name: refs/heads/master

extension: md

gha_language: JavaScript

gha_license_id: NOASSERTION

license_type: permissive


text:
---
title: PKM standards
date: 4-5-2021
---
When defining the standards of my digital garden, is very important, at least to me, to have [[my PKM goal]] in mind, so they contribute to that goal.
Here are some of my ideas for it:
- Note names shall be descriptive
- Notes starts with lowercase letters.
- Tags are only for status and to describe what type of object the note refers to. Here is some [[tag reference]]
- I have to still clarify how will I use the categories. More information on [[tags vs notes in my PKM]]
- B/A stands from Before and After notes. This comes from the original Zettlekasten method as Lumann would set each note before and after another note. This forces me to recall other notes I have in this Vault.
- No redundant or pointless linking.

## Things to consider:

This is not my personal vault, so I do not journal here.
This is not the Wikipedia, The Wikipedia shares the common knowledge of mankind, this digital garden is about My personal point of view, thoughts I have Matured, my take on concepts, my vision, my theories, and understandings of the world.

---
###### Navigation
[[knowledge management system|<<Go Back]]
###### Metadata
Created: May 02, 2021.
Type: #PKM
Status: #Raw

license: MIT

path: /_notes/PKM standards.md

filename: PKM standards.md


text:
[Home](/index.html "Home")

If you do `ls -l <filename>` you will see expanded output which tells about the permissions and other attributes of the file.

```bash
$ ls -l
> drwxr-xr-x 2 ubuntu ubuntu 4096 Nov 17 14:22 Desktop
```

The first part in the output `drwxr-xr-x` represents what is the file type and what permissions it has.

The first attribute is the file type. Rest 9 attributes are permissions for the owner, group and world(other users) giving three attributes to each permission group.

### File types

| Attribute | File type     |
| --------- | ------------- |
|    -      | Regular file  |
|    d      | Directory     |
|    l      | Symbolic Link |
|    c      | Character special file|
|    b      | Block special file|

### Permission attributes

|Attribute|     On file   | On directory |
| ------- | ------------- | ------------ |
|    r    |  Read only    | Directory items can be seen |
|    w    |  Writeable    | Files within a directory can be created, deleted, and renamed if the execute attribute is also set|
|    x    |  Executable   | Allows a directory to beentered, e.g., cd directory |

### Octal Representations of the permissions to be used with chmod command

|Octal Digit|Permission|
| --------- | -------- |
|    0      |    ---   |
|    1      |    --x   |
|    2      |    -w-   |
|    3      |    -wx   |
|    4      |    r--   |
|    5      |    r-x   |
|    6      |    rw-   |
|    7      |    rwx   |


text:
# About

A core for the [wp-prod](https://github.com/vladlu/wp-prod/) system.

# Rules

### Formatting

- The very first line of the rules file should be either "plugin" or "theme";
- At least one tab between arguments of the rules. You can add additional tabs and spaces to give them beautiful formatting;
- You can use comments in any desired format — only the lines that contain one of the rules in the first argument will be interpreted.

### The list of available rules
```
copy
    from  to

uglifyjs
    from  [to]

webpack
    from  [to]

install
    npm_module_name
```
You can see a sample of rules in a [rules.sample](https://github.com/vladlu/wp-prod-core/blob/master/rules.sample) file.

### What does the `webpack` rule do?
```
JS:  babel (with minification)
CSS: postcss-preset-env -> autoprefixer -> cssnano

____________________________

browserslist: cover 95%
```
### Expansions

* `[m]` – dev/wp-prod/wp-prod-core/webpack/node_modules

### Notes

  - For `uglifyjs` and `webpack` rules:

    When a single `from` is used: it generates a file
    with the same name but with `.min` before its extension,
    so `file.css` will generate a `file.min.css` file.

  - For `theme`s:

    You don't need to specify the `style.css` file anywhere in the rules.
  It will be automatically paseed through the babel using the CSS chain above.
  The previous `style.css` will be renamed to `style.dev.css` if you have not done it.

  - It uses browserslist with a `cover 95%` query. As for now, it can't
    be changed in a convenient way.

#

Version: 1.14.15

License: [MIT](https://github.com/vladlu/wp-prod-core/blob/master/LICENSE)

repository: vladlu/wp-prod-core

gha_language: Shell

gha_license_id: MIT

repo_name: vladlu/wp-prod-core


text:
# Coding Dojo
## Kadai
## TDD
## BDD
## SOLID design principles
While the implementation evolves towards addressing the problem, SOLID design principles are pursued as possible. Thus, we use such kata to train on good daily programming habit.

## Implementing the same Kata in more than one language
It is interesting to see how could one be able to work towards the same solution in different languages. Here, I am keen to see how it really differs among Scala, Kotlin, Java and Erlang. Of course, one cannot test everthing. Here, I focus on Pattern Matching.

```
A uTDD pattern is:
Break it, fix it, commit, refactor if necessary, and so on.
```

repository: tonight-halfmoon/Coding-Dojo

gha_language: HTML

repo_name: tonight-halfmoon/Coding-Dojo


text:
---
layout: default
---

# 1994-06-09 - NIST to propose cryptographic APIs

## Header Data

From<EMAIL_ADDRESS>(Paul Ferguson)

To<EMAIL_ADDRESS>Message Hash: a352938bccc6b1f41e3f92d3260ea1c5a65655299255a37b4192ff9dc065bab4

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1994-06-09 22:53:02 UTC

Raw Date: Thu, 9 Jun 94 15:53:02 PDT

## Raw message

```
{% raw  %}From<EMAIL_ADDRESS>(Paul Ferguson)
Date: Thu, 9 Jun 94 15:53:02 PDT
To<EMAIL_ADDRESS>Subject: NIST to propose cryptographic APIs
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

extracted from:

Network World
volume 11, number 23
June 6, 1994

page 3

NIST to propose cryptographic APIs
by Ellen Messmer

  Washington, D.C. -- The National Institute of Standards and Technology
(NIST) will soon issue a set of application program interfaces (API)
that would enable vendors to integrate their products with the
cryptography systems used by the federal government.
  Federal security managers are supporting the idea because it will
simplify purchasing and bring some interoperability to cryptography
products. But the move will mean more work for vendors.
  Once the APIs are approved as a federal mandatory purchasing
standard, software and hardware vendors that want to sell to the
government would have to modify any products they sell with
cryptographic functions to support the government-required APIs.
  Several vendors, including Apple Computer, Inc., Lotus Development
Corp., Novell, Inc. and WordPerfect Corp., have already integrated
functions for digital signatures, encryption and decryption into the
latest versions of their products.
  They have licensed cryptography technology from RSA Data Security,
Inc., and the APIs used in their products are based on an open
specification called the Public Key Cryptography Standard. In spite of
the work on these industry-standard APIs, vendors may have to revamp
their products to suit the government.
  NIST said it will detail how the government wants vendors to change
their products to support a high-level API in all products sold to
federal agencies.
  "There would be an advantage to having a common set of services
calls," said Miles Smid, manager of the security technology group at
NIST. "You wouldn't be locked into a single vendor. In the future, if
you added more equipment or changed it, the software would still be
compatible."
  Smid said the API service calls will include commands to sign or
verify a message electronically, and encrypt or decrypt it. The calls
would invoke the functions from a PCMCIA card, a smart card, software
or other means. With the APIs, the user's application could make use
of any cryptographic algorithm, regardless or whether it's Digital
Encryption Standard, Skipjack or RSA, Smid said.
  "It's a great idea," said Jim Robinette, security manager at the
Internal Revenue Service, which makes considerable use of both
private- and public-key technology. "It's a necessity for us. From
the user's perspective, it would make life very simple."
  A high-level API would still allow vendors free rein in how they
implement their systems at a lower level, Robinette said. But he added
that it may not necessarily be easy for vendors to implement the APIs.
  RSA President James Bidzos criticized the cryptography API plan as
another swipe at his firm, which has been battling the government on
patent rights issues for years. "They're not trying to work with
industry on this," he said.
  NIST plans to unveil the APIs in about a month.

{% endraw %}
```

## Thread

+ Return to [June 1994](/archive/1994/06)

+ Return to<EMAIL_ADDRESS>(Paul Ferguson)](/authors/paul_at_hawksbill_sprintmrn_com_paul_ferguson_)"

+ 1994-06-09 (Thu, 9 Jun 94 15:53:02 PDT) - NIST to propose cryptographic APIs -<EMAIL_ADDRESS>(Paul Ferguson)_


text:
# docker-lamp
Containerized LAMP stack with configurable PHP version for test purposes.

## Installation/Usage

Install [docker](https://www.docker.com/products/docker) and [docker-compose](https://docs.docker.com/compose/install/).

Clone the repo by entering `git clone https://github.com/comando4ever/docker-lamp.git ./server`.

Enter the directory of the cloned repo `cd ./server`

Run `docker-compose build` and `docker-compose up -d` then you should have a running web server on port 80.

You can add your application files in `src` directory.

To shutdown the server use `docker-compose down` or Ctrl+C if you didn't use the `-d` option.

## Configuration

Change PHP version by changing `PHP_VERSION` in docker-compose.yml file the default version is "5.3.29".

Change MySQL password by changing `MYSQL_ROOT_PASSWORD` the default password is "root".

To change the configurations of Apache, MySQL or PHP mount a volume pointing to the configuration files you need to change.

* The php image uses phpbrew to manage version so you may need to figure out the php.ini file location depending on your version usually in `/root/.phpbrew/php/php-$VERSION/etc` changing $VERSION to your installed version.
* MySQL uses a separate image so you may want to add the volume to its image in `docker-compose.yml`.

repository: eawd/docker-lamp

repo_name: eawd/docker-lamp


text:
Creates a standalone secretsmanager secret, encrypted with a kms key.

# terraform-kms-secret

```hcl
module "your_secret"{
  source = "github.com/turnerlabs/terraform-kms-secret?ref=v1.0"
  region = var.region
  secret_id = "your-secret-id"
  secrets_saml_users =<EMAIL_ADDRESS><EMAIL_ADDRESS>  saml_role = var.saml_role
  tags = var.tags
  additional_roles = [
    data.aws_iam_role.ecsTaskExecutionRole.name
  ]
}

```

Big thanks to [John](https://github.com/jritsema) for creating the original code, which I refactored into this standalone module.

repository: syllogy/terraform-kms-secret

branch_name: refs/heads/main

repo_name: syllogy/terraform-kms-secret


text:
jmsql
=====

A smarter mysql console

HOW TO USE
-to see the help run (from target folder)
java -jar Jmsql-0.1.jar -help

Features:

1. TABLE-NICKNAME TAB to get table name from its nickname. (nickname for table 'a_bc_de' is 'abd' i.e. the first character and immediate characters after underscores)
2. ls ENTER to get all the tables in that database
3. ls *v* to get all the table with character v in their names
4. TABLE-NAME ENTER  to get description of table
5. TABLE-NAME NUMBER N to get first N rows of TABLE (suitable to see content of domain tables)
6. TABLE-NAME ADDITIONAL-QUERY will prepend select * from in the query


text:
# HTMLCollection and NodeList

```
<div id="myContent">
    <p>First paragraph</p>
    <p>Second paragraph</p>
    <p>Third paragraph</p>
    <p>Fourth paragraph</p>
</div>
```

With the above HTML structure, the DOM API `document.getElementsByTagName("p")` will return an array-like list called `HTMLCollection` while `document.querySelectorAll("p")` will also return an **array-like list** called `NodeList`.

| DOM API | Result |
| :--- | :--- |
| **document.getElementsByTagName\("p"\)** | ![](/assets/HTMLCollection.png) |
|  |  |
| **document.querySelectorAll\("p"\)** | ![](/assets/NodeList.png) |

Although the contents of both lists are same, `HTMLCollection`is always a **live list** - if the corresponding DOM gets updated, so will the HTMLCollection.

```js
var myContent = document.querySelector("#myContent");
var myHTMLCollection = myContent.getElementsByTagName("p");
var myNodeList = myContent.querySelectorAll("p");

console.log(myHTMLCollection.length);    // 4
console.log(myNodeList.length);          // 4

// Adding new paragraph to #myContent
var newParagraph = document.createElement("p");
myContent.appendChild(newParagraph);

console.log(myHTMLCollection.length);    // 5 - live list reflects the current state of DOM
console.log(myNodeList.length);          // 4
```

Further, it is also possible to get hold of a live NodeList; e.g. `{HTMLElement}.childNodes`.

Today, the concept of HTMLCollection probably exists in modern browser implementations just for legacy purposes - to retain the behavior of older and now non-standard DOM APIs like `document.forms`, `HTMLElement.children`, `document.getElementsByTagName()` etc. But this is all browser implementation specific. Not every browser will follow same implementation.

## A word of caution about live collections

As an example of live collections, `{HTMLElement}.childNodes` returns a **live **`NodeList` and `document.getElementsByTagName()` returns a **live **`HTMLCollection`. One should be extra careful while iterating on these entities, as an operation that updates the same collection from within the iteration might affect the length of the loop in an unexpected way.

repository: webf-zone/short-js

repo_name: webf-zone/short-js


text:
---
date: 2022-08-07T22:00:56Z
title: Herbie Hancock in Edinburgh
description: A night in the presence of musical genius
tags:
- note
- jazz
- edinburgh
- event
- festival
- music
noteWithTitle: true
location: Edinburgh Playhouse
draft: false

---
Just had a memorable experience with Jason and Tom catching Herbie Hancock at the Edinburgh Festival. At 82 years old he still has amazing energy and capped his performance with a tour of the stage playing his keytar followed by a scissor jump!

Herbie’s piano playing was mesmerising – the solos really took me to another place and if this is how he plays in his eighties I can only imagine how good his gigs were in his prime. I also loved his warm anecdotes, including one about his friend Wayne Shorter just before treating us to a rendition of [Footprints](https://www.youtube.com/watch?v=3XvJFW0DHbU).

Other highlights included [Cantaloupe Island](https://www.youtube.com/watch?v=8B1oIXGX0Io), the mindbending [Actual Proof](https://www.youtube.com/watch?v=nP4CJfSN27E) and hearing guitarist Lionel Louke coax sounds from a guitar that you wouldn’t think possible.

repository: fuzzylogicxx/fuzzylogic

gha_language: SCSS

repo_name: fuzzylogicxx/fuzzylogic


text:
# Signal K Node server Charts plugin

Signal K Node server plugin to provide chart metadata, such as name, description and location of the actual chart tile data.

### Usage

1. Install "Signal K Charts" plugin from Signal K Appstore

2. Add "Chart paths" in plugin configuration. Defaults to `${signalk-configuration-path}/charts`

3. Put charts into selected paths

4. Add optional online chart providers

_WMS example:_
![image](https://user-images.githubusercontent.com/38519157/102832518-90077100-443e-11eb-9a1d-d0806bb2b10b.png)

5. Activate plugin

6. Use one of the client apps supporting Signal K charts, for example:
- [Freeboard SK](https://www.npmjs.com/package/@signalk/freeboard-sk)
- [Tuktuk Chart Plotter](https://www.npmjs.com/package/tuktuk-chart-plotter)

### Supported chart formats

- [MBTiles](https://github.com/mapbox/mbtiles-spec) file
- Directory with cached [TMS](https://wiki.osgeo.org/wiki/Tile_Map_Service_Specification) tiles and `tilemapresource.xml`
- Directory with XYZ tiles and `metadata.json`
- Online [TMS](https://wiki.osgeo.org/wiki/Tile_Map_Service_Specification)

Publicly available MBTiles charts can be found from:
- [NOAA Nautical charts](https://distribution.charts.noaa.gov/ncds/index.html)
- [Finnish Transport Agency nautical charts](https://github.com/vokkim/rannikkokartat-mbtiles)
- [Signal K World Coastline Map](https://github.com/netAction/signalk-world-coastline-map), download [MBTiles release](https://github.com/netAction/signalk-world-coastline-map/releases/download/v1.0/signalk-world-coastline-map-database.tgz)

### API

Plugin adds support for `/resources/charts` endpoints described in [Signal K specification](http://signalk.org/specification/1.0.0/doc/otherBranches.html#resourcescharts):

- `GET /signalk/v1/api/resources/charts/` returns metadata for all available charts
- `GET /signalk/v1/api/resources/charts/${identifier}/` returns metadata for selected chart
- `GET /signalk/v1/api/resources/charts/${identifier}/${z}/${x}/${y}` returns a single tile for selected offline chart. As charts-plugin isn't proxy, online charts is not available via this request. You should look the metadata to find proper request.

License
-------
Copyright 2018 Mikko Vesikkala

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

repository: SignalK/charts-plugin

repo_name: SignalK/charts-plugin


text:
Title: Theme Review
Date: 2014-09-05 21:53
Category: Review
Tags: themes, galleries, pelican

This is a test post for the [pelican-theme-validator](https://github.com/svenkreiss/pelican-theme-validator). The pelican-theme-validator shows a list of pelican themes, previews and their HTML5 validity. In case a theme is not HTML5 valid, it shows the affected files and their problems. It also hosts small example websites with all [pelican-themes](https://github.com/getpelican/pelican-themes/) and this is one instance.

repository: svenkreiss/pelican-theme-validator

repo_name: svenkreiss/pelican-theme-validator


text:
# Spring MVC 404

There are two cases in the SpringMvc document exception:

- doc.html Open prompt 404
- doc.html is already open, but the page does not have any interface documentation

Solution for the above two situations：

one：**doc.html Open prompt 404?**

Generally, there is no need to add this configuration. If this happens, add Spring's static resource mapping path in Spring's xml configuration file, as follows:

```xml
<mvc:resources location="classpath:/META-INF/resources/" mapping="doc.html"/>
<mvc:resources location="classpath:/META-INF/resources/webjars/" mapping="/webjars/**"/>
```

two：**Doc.html is already open, but the page does not have any interface documentation？**

To configure the DispatcherServlet in [web.xml](https://gitee.com/xiaoym/swagger-bootstrap-ui-demo/blob/master/swagger-bootstrap-ui-demo-mvc/src/main/webapp/WEB-INF/web.xml), you need to append a url matching rule, as follows

```xml
<!-- Configure the url request path for swagger-bootstrap-ui-->
<servlet-mapping>
    <servlet-name>swaggerDemoMvc</servlet-name>
    <url-pattern>/v2/api-docs</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>swaggerDemoMvc</servlet-name>
    <url-pattern>/swagger-resources</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>swaggerDemoMvc</servlet-name>
    <url-pattern>/swagger-resources/configuration/ui</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>swaggerDemoMvc</servlet-name>
    <url-pattern>/swagger-resources/configuration/security</url-pattern>
</servlet-mapping>
<!--This interface address is an enhanced address provided by SwaggerBootstrapUi, which can be excluded if no enhancements are used.-->
<servlet-mapping>
    <servlet-name>swaggerDemoMvc</servlet-name>
    <url-pattern>/v2/api-docs-ext</url-pattern>
</servlet-mapping>
```

For a code example of SpringMvc, see [swagger-bootstrap-ui-demo-mvc](https://gitee.com/xiaoym/swagger-bootstrap-ui-demo/tree/master/swagger-bootstrap-ui-demo-mvc)

repository: xiaoymin/swagger-bootstrap-ui-doc

repo_name: xiaoymin/swagger-bootstrap-ui-doc


text:
# 🟢 Updating

**🔵 Windows**

- **🔵 Windows:** Download "screen-recorder*.exe" file from [releases](https://github.com/Bajojajo-xD/screen-recorder/releases), double click, follow on-screen instructions,
- **🔵 Windows portable:** Download "screen-recorder*.zip" file from [releases](https://github.com/Bajojajo-xD/screen-recorder/releases), open, find "Screen recorder DEV.exe and run. (You can delete old zip app file)

**🟠 Linux**

- **🟠 Ubuntu/Debian based linux:** Download "screen-recorder*.deb" file from [releases](https://github.com/Bajojajo-xD/screen-recorder/releases) and update,
- **🧿 Fedora based linux:** Download "screen-recorder*.rpm" file from [releases](https://github.com/Bajojajo-xD/screen-recorder/releases) and update,
- **🟠 Linux portable:** Download "screen-recorder*.AppImage" file from [releases](https://github.com/Bajojajo-xD/screen-recorder/releases), then right click -> properties -> permissions -> check "allow executing file as program". Remove old "screen-recorder*.AppImage". After it run app clicking on file.

- ***Warning - only 64-bit system supported***

license: Unlicense

repository: LukeMech/screen-recorder

repo_name: LukeMech/screen-recorder


text:
# Livy Docker Image

Builds Livy from source and bundles with Spark installation.

- Spark 2.1.1 with Hadoop 2.8 support (required for path-style S3 interaction)
- Spark compiled with Scala 2.11
- OpenJDK 8
- Livy 0.4.0-incubating

Build
-----

`docker build -t scality/clueso-livy:0.4.0 .`

repository: divenswu/clueso

repo_name: divenswu/clueso


text:
---
title: Introduction
permalink: /intro/
excerpt: "Starting page"
---

Governance is the key driver to a successful use of low code in your organization.
But many conversations are missing the strategy and goals that underly this governance, going straight to technical discussions to implement tooling like the [CoE Starter Kit](https://github.com/microsoft/powerapps-tools/tree/master/Administration/CoEStarterKit)

The purpose of this framework is to help organizations envision their own low-code journey, by providing:

* Field **insights** about what typical organizations are doing
  * [Chapter 1](Foundations.md) : Typical actions to build strong foundations
  * [Chapter 2](AdoptionPath.md) : Typical adoption path
* A **structure** to organize your thoughts and make sure you address all key topics
  * [Chapter 3](MaturityScale.md) : An example of maturity Scale to help you set your goals (what is the step you are targeting)
  * [Chapter 4](PilarsOfSuccess.md): A detailed structure to identify recommended goals and associated actions to increase your low code maturity
* Some **Tools** to build your roadmap and regularly assess your progress.
  * [Chapter 5](BuidYourRoadmap.md) : A proposition of roadmap to help you set your goals (what is the step you are targeting)
  * [Chapter 6](VelocityIndex.md) : A tool to precisely and regularly assess your low-code maturity

repository: Nicokirr/PPGovFramework

repo_name: Nicokirr/PPGovFramework


text:
---
layout: default
title: Running Jupyter on HPC.
nav_order: 10
parent: HPC
description: "Setting up Jupyter Notebook Over Tunneling on HPC."
---

# Running Jupyter on HPC
{: .no_toc }

## Table of contents
{: .no_toc .text-delta }

1. TOC
{:toc}

---

# Setting up Jupyter Notebook Over Tunneling on HPC.

Below is an example protocol to run Jupyter notebook in an interactive node on a high-performance computer (HPCs). Most of the HPCs have their specialised way of interacting with them. Therefore, you may have to tweak this protocol as per your need. I would be happy to discuss and troubleshoot with you; contact me at [contact@rohitfarmer.dev](mailto:contact@rohitfarmer.dev). Any suggestions to augment this protocol with more advanced features are welcomed.

1. SSH to the HPC.
2. Claim an interactive node (follow the standard procedure for your HPC, in my case it is `qrsh`).
3. Note the interactive node name.
4. Run Jupyter on the claimed interactive node by `jupyter notebook --no-browser --ip='<IP_ADDRESS>'` or create an alias in your bashrc for a shortcut. For example `alias jup='jupyter notebook --no-browser --ip='<IP_ADDRESS>''`.
5. On your computer start another SSH session with tunnelling using the interactive node name as noted above `ssh user@host -L8888:nodeName:8888 -N`. *The prompt probably won't return and you may also not see any message in your terminal, but as long as there is no error message, it's probably running fine.*
6. To avoid re-writing the code in step 5 every time you tunnel you can use the shell script below.

I named it `jupssh`.
```
#!/bin/sh

# Check if the arugment is passed.
if [[ $# -eq 0 ]];
then
    echo 'Usage: jupssh <node name>'
    exit 1
fi

ssh user@host -L8888:$1:8888 -N
```

* Copy the URL that the Jupyter daemon has generated in step 4 and paste it in the browser on your computer. URL should look something similar to `http://(nodeName or <IP_ADDRESS>):8888/?token=3f7c3a8949b3fa1961c63653873fea075a93a29bffe373b5`. Choose either nodeName or <IP_ADDRESS> in the URL.

repository: rohitfarmer/docs

gha_language: CSS

repo_name: rohitfarmer/docs


text:
---
title: TUA Spartacus Features
---

This is a landing page for grouping together TUA Spartacus features. The TUA Spartacus features include the following:

- Configurable Guided Selling Journey in SPA
- [Customer Product Inventory (CPI)]({{ site.baseurl }}{% link _pages/telco/customer-product-inventory.md %})
- [Journey Management - MSISDN (Virtual Mobile Number)]({{ site.baseurl }}{% link _pages/telco/journey-management-msisdn.md %})
- [New Appointment]({{ site.baseurl }}{% link _pages/telco/journey-management-appointment.md %})

repository: jamesgarzon/spartacus-docs

repo_name: jamesgarzon/spartacus-docs


text:
---
layout: guide
---

## Examples

{::comment}
TODO - add python client
{:/comment}

Switchboard allows developers to develop a wide variety of clients.
This section will point you towards existing example clients, as well
as walk you through how to write your own client in Ruby.

Switchboard's first role was sending new email push notifications to
the [Spatch iOS app](http://spatch.co). Due to mobile process
backgrounding restrictions and battery abuse, it's difficult to
monitor for new emails client-side. Instead, the Spatch app securely
posts users' OAuth tokens to a server running Switchboard, which
begins to monitor the accounts for incoming emails. When a new email
arrives, Switchboard notifies a subscribed worker, which then sends
down a push notification to the app.

In this case, Switchboard handled creating the IMAP connections,
keeping tabs on new emails coming down, and giving the worker
the data that it needed to send down a nicely formatted push
notification.

### Python Worker/Client and Examples

There is a Switchboard worker/client
[Python implementation](https://github.com/jtmoulia/switchboard-python).
The repository's README explains how to get connected to Switchboard,
and run the examples.

The examples include workers for:

    Sending Apple push notifications to an iOS app as new emails arrive.

    Sending a text message via Twilio
    as new emails arrive.

### Javascript Worker/Client

Since the Switchboard protocol uses JSON over WebSockets, it's only fitting for
there to be a JavaScript client. Switchboard comes packaged with one.

To try the client out, start the Switchboard application and point
your browser at
[`http://<IP_ADDRESS>:8080/jsclient`](http://<IP_ADDRESS>:8080/jsclient) -
it should display a page with some getting started commands. Open your
browser's javascript console and try them out.  The sourcefile
contains comments mapping out common components of a Switchboard
client, and is a great reference for understanding the interfaces.

### Ruby Sample App Tutorial - Email Dropbox Uploader

Follow this example tutorial to build your first Switchboard client
in Ruby. This simple example, to be run in the command line, syncs
attachments from a user's emails to his or her Dropbox.

#### Setup

First off, make sure switchboard is running on your local server (see
[Switchboard Installation](/switchboard/install/
"Installation") for details)

After the Switchboard server is up, you're ready to start building
your Ruby client so you can communicate with it.

To get started, create the following `Gemfile`:

{% highlight ruby %}
source 'https://rubygems.org'
ruby '2.1.1' # we haven't tested other versions yet. Let us know if you have any issues

gem 'faye-websocket'
gem 'Dropbox-sdk'
{% endhighlight %}

`faye-websocket` is a pretty handy gem extracted from the
[faye project](https://github.com/faye/faye-websocket-ruby), which
provides classes for easily building WebSocket servers and clients in Ruby.
Dropbox's '[ruby SDK](https://www.Dropbox.com/developers/core/start/ruby)'
is well developed and documented, which will make it
simple to upload files to your Dropbox.

#### The initial client

The beginnings of the client come straight from the
[faye-websocket documentation](https://github.com/faye/faye-websocket-ruby#using-the-websocket-client),
it's pretty easy to set up:

`awesome-Dropbox-uploader.rb`

{% highlight ruby %}
require 'faye/websocket'
require 'eventmachine'
require 'json'

EM.run {
  ws = Faye::WebSocket::Client.new('ws://<IP_ADDRESS>:8080/clients') # this tutorial uses the default switchboard url -> read below for an explanation.

  ws.on :open do |event|
    p [:open]
  end

  ws.on :message do |event|
    p [:message, JSON.parse(event.data)]
  end

  ws.on :close do |event|
    p [:close, event.code, event.reason]
    ws = nil
  end
}
{% endhighlight %}

The `Faye::Websocket::Client` takes an url to listen to, so you can use
the default local Switchboard url. The client responds to the usual
websocket methods, which currently output notifications/data to the
console upon being called. When the client receives a message from the server,
it'll parse it for later use.

If you execute `ruby your-file-name.rb` (we'll call it
awesome-Dropbox-uploader.rb for the rest of the tutorial) you'll see:

{% highlight ruby %}
[:open]
{% endhighlight %}

...and nothing else. This is because without adding an account to
Switchboard it doesn't know what to send your way. So close your
client for the moment (`Ctrl + c`, upon which you'll see a closing
message) and move on to the next section: adding an account.

#### Adding/listening to an account

The Switchboard client protocol is currently a subset of
[JMAP](http://jmap.io/), with data encoded in `UTF8 JSON`. Clients can
issue commands in the form `[["methodName", {options}]]`, using the
`send` method. This example uses Switchboard's plain auth:

{% highlight ruby %}
ws.on :open do |event|
  p[:open]

  ws.send '[
              ["connect",
                {"host": "imap.gmail.com",
                  "port": 993,
                  "auth": {"type": "plain",
                            "username": "YOUR EMAIL",
                            "password": "YOUR PASSWORD"
                          }
                }
              ]
            ]'
end
{% endhighlight %}

This time, if you run our client (`ruby awesome-Dropbox-uploader.rb`)
it'll automatically connect, and you should see the message

{% highlight ruby %}
[:message, [["connected", {}]]]
{% endhighlight %}

Although you're now connected there's one last thing you've got to do
before you'll start getting emails through. We need to tell
Switchboard which mailbox to listen to. That's easily done with the
`watchMailboxes` command, which takes as argument a list of mailboxes.

{% highlight ruby %}
ws.send '[["watchMailboxes", {"list": ["INBOX"]}]]'
{% endhighlight %}

The server will respond with `[:message, [["watchedMailboxes", {}]]]`

If you restart your client now, when you receive an email Switchboard
will automatically send through the email's `messageId` and its `mailboxId`:

{% highlight ruby %}
["newMessage", {"mailboxId"=>"INBOX!671882951", "messageId"=>"INBOX!671882951?2743"}]
{% endhighlight %}

By now you probably have noticed that messages sent from the server
take the following form:

{% highlight ruby %}
[["messageName", {params}]]
{% endhighlight %}

You can use this to make what's output to your console when you receive
messages a little more specific:

{% highlight ruby %}
ws.on :message do |event|
  m = JSON.parse(event.data).flatten!

  case m[0] #using the method name to decide what to do
    when "connected"
      puts 'connection made'
    when "idling"
      puts 'idling away'
    when "newMessage"
      puts 'new message'
      puts "#{m[1]}" #the message content
    else
      puts "#{m}"
  end
end
{% endhighlight %}

Hardcoding an email and password is pretty simplistic, so let's change that
to enable you to pass them in through the command line:

{% highlight ruby %}
puts "let's add an account to switchboard"
puts 'what is your email?'
email = gets.strip
puts 'what is your password?'
password = gets.strip
{% endhighlight %}

You'll need to interpolate the values into your command to the server (this means having to escape a lot of double quotation marks):

{% highlight ruby %}
"[[\"connect\", {\"host\": \"imap.gmail.com\",
                \"port\": 993,
                \"auth\": {\"type\": \"plain\",
                            \"username\": \"#{email}\",
                            \"password\": \"#{password}\"
                          }
              }
]]"
{% endhighlight %}

Now when you run your 'awesome-Dropbox-uploader' you're prompted to fill
in your Gmail username and password, then Switchboard automatically
connects and listens to your inbox for you. Pretty sweet!

So now your client's in pretty good shape. Apart from one pretty
crucial thing - you're not retrieving any attachments to
upload. Whoops.

In order to retrieve an attachment you need to use the `messageId` you
get upon receiving an email to make another call to Switchboard,
retrieving the specific email information you need. You can do this with
`getMessages`, which takes as arguments message ids and the email
properties you're looking for, from subject to textBody.

Retrieving the attachments directly is still a work in progress, but
we can get around that by retrieving the raw email data in order to
parse it in your client:

{% highlight ruby %}
ws.on :message do |event|
  m = JSON.parse(event.data).flatten!

  case m[0]
    .
    .
    .
    when "newMessage"
      puts 'new message'
      message_id = m[1]["messageId"]
      ws.send "[
                 [\"getMessages\",
                  {
                    \"ids\": [\"#{message_id}\"],
                    \"properties\": [\"raw\"]
                  }
                ]
              ]"
    else
    .
    .
    .
  end
end
{% endhighlight %}

Now you have the raw email data. You can use the handy
[mail](https://github.com/mikel/mail) gem to parse it and retrieve
your attachments. After adding and bundling the gem, you're ready to
add a new case to the message method:

{% highlight ruby %}
ws.on :message do |event|
  m = JSON.parse(event.data).flatten!

  case m[0]
    .
    .
    .
    when "messages"
      # first the client needs to retrieve the raw data from the server response
      raw_msg = m[1]["list"][0]["raw"]
      # then parse it with the mail gem and retrieve the attachments
      msg = Mail.new(raw_msg)
      attachments = msg.attachments
      puts "#{attachments}"
    else
    .
    .
    .
  end
end
{% endhighlight %}

Attachments are returned in an array. If an email has no attachments,
Switchboard will return an empty array. If you're interested, an
attachment looks something like this:

{% highlight ruby %}
[#<Mail::Part:2159230880, Multipart: false, Headers: 	<Content-Type: image/jpeg; name="swag.jpg">, 	<Content-Transfer-Encoding: base64>, <Content-	Disposition: attachment; filename="swag.jpg">, 	<X-Attachment-Id: f_hw297rj60>>]
{% endhighlight %}

#### Dropbox authentication

Now the client is retrieving your email attachments, the next step
is to set up the Dropbox uploader. First off is authentication.

Setting up `Dropbox OAuth` is incredibly easy, and well documented. It
is a little awkward to use though, due to it being split into two
parts (authorising the app and then pasting in a confirmation code to
finish the process).

Here's a quick implementation taken from the Dropbox docs (you'll need
to register your app on the app console [here](https://www.Dropbox.com/developers/apps)
to get a key and secret first).

{% highlight ruby %}
APP_KEY = 'SOME KEY'
APP_SECRET = 'SOME SECRET'

flow = DropboxOAuth2FlowNoRedirect.new(APP_KEY, 	APP_SECRET)

authorize_url = flow.start()

puts '1. Go to: ' + authorize_url
puts '2. Click "Allow" (you might have to log in 	first)'
puts '3. Copy the authorization code'
print 'Enter the authorization code here: '
code = gets.strip

access_token, user_id = flow.finish(code)
{% endhighlight %}

You can implement a simple Dropbox uploader using the access token stored when you authenticated with Dropbox, passing in the attachments from your emails:

{% highlight ruby %}
class DropboxUploader
  class << self
    def upload_file(attachments, token)
      attachments.each do | attachment |
        filename = attachment.filename
        begin
          file = attachment.body.decoded
          client = DropboxClient.new(token)
          client.put_file("/#{filename}", file)
        rescue => e
          puts "Unable to save data for #{filename} because #{e.message}"
        end
      end
    end
  end
end
{% endhighlight %}

Add the uploader to your `messages` method and you're good to go:

{% highlight ruby %}
ws.on :message do |event|
  m = JSON.parse(event.data).flatten!

  case m[0]
  .
  .
  .
    when "messages"
      .
      .
      .

      DropboxUploader::upload_file(attachments, access_token)
  .
  .
  .
  end
end
{% endhighlight %}

And there you have it. A quick command line application that syncs
your email attachments with your Dropbox, and shows off the awesome
power of Switchboard.

#### Tidying up

You can start extracting out the code into classes to neaten things up
a bit, for example:

{% highlight ruby %}
class SwitchboardClient
  class << self
    def open(ws, email, password)
      ws.send authorisation(email, password)

      ws.send '[["idle", {"list": ["INBOX"]}]]'
    end

    def authorisation(email, password)
      "[[\"connect\", {\"host\": \"imap.gmail.com\",
                 \"port\": 993,
                 \"auth\": {\"type\": \"plain\",
                         \"username\": \"#{email}\",
                         \"password\": \"#{password}\"
                                }
                    }
      ]]"
    end

    .
    .
    .

  end
end
{% endhighlight %}

And then you can call:

{% highlight ruby %}
EM.run do
  ws = Faye::WebSocket::Client.new('ws://<IP_ADDRESS>:8080/clients')

  ws.on :open do |event|
    SwitchboardClient::open(ws, email, password)
  end

  ws.on :message do |event|
    SwitchboardClient::message(ws, event)
  end

  ws.on :close do |event|
    SwitchboardClient::close(event)
  end
end
{% endhighlight %}

Follow this example tutorial to build your first switchboard client in Ruby.
This simple example, to be run in the command line, syncs attachments from a
users' emails to his or her Dropbox.

gha_language: Erlang


text:
## Developing Reusable Code

In this chapter you'll learn:
- What a Terraform module is
- How to generalize Terraform code to make it reusable
- Use variables to pass data into modules

### Terraform Modules

In the last chapter, you wrote your first Terraform code, and learned three Terraform commands: init, plan, and apply. As your Terraform code becomes more complex, and you do more deployments, you may find the need to reuse Terraform code. You can do this with modules.

> **So what is a module in Terraform anyways?**
>
> In the simplest terms, a module is a collection of declarative Terraform files, grouped together in a folder. That's right - Terraform sees any folder with Terraform files as a module. If you're familiar with other programming lanaguages, you can think of a module like an API - you pass data (variables) into it, infrastructure is provisioned, and data (output) is returned.

You'll recall from the last chapter, that Terraform collects all ".tf" files in a folder (or rather, a module) when it runs. The files are combined into a single master code declaration, dependencies discovered, and infrastructure is provisioned in the order determined.

#### Structuring modules

Modules consist of three files, generally:
1. A `main.tf` file where all primary code exists.
2. A `variables.tf` or `vars.tf` file where variables for that module are declared.
3. An `output.tf` file where any module outputs are declared.

You've already seen what goes into a main.tf file so let's talk about the other two.

The variables file, is made up of all pre-defined variables (or module inputs) for a file. Here is an example of how to construct a variable:

```
variable "location" {
    description = "Location where Resources will be deployed"
    default = "East US"
}
```

The example above declares a *location* variable, which can include a description and a default value, though these are not required. If no default value is supplied, the module will expect these to be supplied by some other means, either through direct user input or by outputs.

Speaking of outputs, let's look at an example of what might go into an `output.tf` file:

```
output "app_service_fqdn" {
    value = "${azurerm_app_service.app1_app_service.default_site_hostname}"
}
```

The example above declares an "app_service_fqdn" output and specifies the value comes from the result of the app service default site hostname. This means we can use computed values from our deployment elsewhere. Like for example, in another module.

The ability for setting up inputs and outputs using declarative language gives us the flexibility needed to generalize configurations so they can be *stamped-out* on demand.

### Creating a Generalized Module

Now that you know what goes into a module, let's build one together.

    Exercise: Generalizing modules

Before we begin, clean up your `c:\terraform` fodler by removing the following files/folders:
- .terraform folder (use VS Code to delete it)
- terraform.tfstate file
- terraform.tfstate.backup file

Create a new folder in your `C:\terraform` folder. We are going to call this folder `_modules`.

Next, create a sub-folder in `_modules` called `standard_application`.

Now move the `main.tf` file we created in the previous chapter into this folder. In VS Code, drag the file from it's current parent location to the `standard_application` sub-folder you just created.

Next, create two more files in the `standard_application` folder. Create an empty `variables.tf` file and an empty `output.tf` file. We'll populate these later as we get a better feel for what variables we need.

This creates the baseline of our module, but we aren't done.

We are going to create two more folders at the root of `C:\terraform`. First create a folder called `dev`, then a folder called `prod`. We'll work with these folders more toward the end of this section.

#### Generalizing the Module

Technically the `main.tf` file we created earlier is part of a module now called *standard_application* but we cannot re-use it yet. There are certain parameters we have hard-coded which will prevent us from dynamically calling the module. Let's change that by replacing those hard-coded values with variables.

> **Before we go further**
>
> Please remove the provider block at the top of the `main.tf` file we created earlier. Save the provider code -- we'll need it later. We'll talk about why you have to do this later.

Open up the "variables.tf" file and paste the following code:

```
variable "location" {
    description = "Location where Resources will be deployed"
}

variable "application_plan_tier" {
    description = "Tier of the Application Plan (Free, Shared, Basic, Standard, Premium, Isolated)"
}

variable "application_plan_size" {
    description = "Instance Size of the Application Plan (F1, D1, B1, B2, B3, S1, S2, S3, P1v2, P2v2, P3v2, PC2, PC3, PC4, I1, I2, I3)"
}

variable "application_name" {
    description = "Name of the Application"
}

variable "environment" {
    description = "Environment of all deployed resources"
}
```
>**More on variables**
>
> We like to think of modules like an API. The variables represent input values that allow the module to be flexible and provision different infrastructure configurations - they form the API's surface and interface. The module's `main.tf` code then represents the implementation of the API.

With our freshly declared variables, let's open up the "output.tf" file and paste the following:

```
output "app_service_fqdn" {
    value = "${azurerm_app_service.app1_app_service.default_site_hostname}"
}
```

We will be using this output in a future chapter, and will discuss this in more detail at that time.

Let's move on to the `main.tf` file and begin generalizing the resources we previously created.

Replace the existing Resource Group block with the following code:

```
# Resource Group
resource "azurerm_resource_group" "application_rg" {
    name     = "tf-az-${var.application_name}-${var.environment}-rg"
    location = "${var.location}"
}
```

Variables are called by supplying ${var.<variable name>}. You'll also notice that you can place variables side-by-side in Terraform code (like we did with the *name* key/value pair above).

Next, let's generalize the App Service Plan and App Service:

```
# App Service Plan
resource "azurerm_app_service_plan" "standard_app_plan" {
    name                = "tf-az-standard-${var.environment}-plan"
    location            = "${var.location}"
    resource_group_name = "${azurerm_resource_group.application_rg.name}"
    sku {
        tier = "${var.application_plan_tier}"
        size = "${var.application_plan_size}"
    }
}

# Random Integer for Unique Names
resource "random_integer" "ri" {
    min = 10000
    max = 99999
}

# App Service
resource "azurerm_app_service" "app1_app_service" {
    name                = "tf-az-${var.application_name}-${var.environment}-app${random_integer.ri.result}"
    location            = "${var.location}"
    resource_group_name = "${azurerm_resource_group.application_rg.name}"
    app_service_plan_id = "${azurerm_app_service_plan.standard_app_plan.id}"
}
```

This concludes the exercise.

### Calling Modules

In the last section, you learned how to take existing Terraform code and turn it into a generalized module. Now that we have this module, let's use it!

    Exercise: Calling a module

In the last section, you created a `dev` and `prod` folder within `C:\terraform`. In this exercise, you'll be creating Terraform code in each folder and referencing the *standard_application* module.

Let's get started.

In the "dev" folder, create a new `main.tf` file.

> **Don't forget the provider!**
>
> Remember when we got rid of the provider declaration in the `standard_application\main.tf` file earlier in this chapter? We are going to declare the provider in this file `dev\main.tf`. If a provider is not declared in a module, the module will use the provider of the configuration file that called the module.
>
> It is generally best to keep provider declarations at the root folder where modules will be called. Only declare a provider in a module when you need to override the default provider used (like when you need to use a specific provider version for compatibility).

Open the `dev\main.tf` file you just created and paste the following code (or the provider code you saved earlier):

```
provider "azurerm" {
    tenant_id       = ""
    subscription_id = ""
    use_msi = true
}
```

Just like before, make sure to place your Azure Tenant and Subscription ID inside the quotes next to the appropriate parameter.

Next we are going to call the previously created "standard_application" module and supply the required values.

> **Module inception?**
>
> If you recall, modules are simply a folder with Terraform code within. So technically, the new `main.tf` file you created *is* a module...and we'll be adding code to call the *standard_application* module. In other words, modules can call other modules.
>
> We're going to call the "standard_application" module to generate both a dev environment and a prod environment (hence the `dev` and `prod` folders). In large deployments, this saves us time. It also reduces the chance of errors because we know the same infrastructure will be deployed -- using the standards that we have set in the module (for naming convention, etc.).

Paste the following code below the provider block:

```
module "standard_application" {
    source                     = "../_modules/standard_application/"

    environment                = "dev"
    application_name           = "app1"
    location                   = "East US"
    application_plan_tier      = "Basic"
    application_plan_size      = "B1"
}
```

To call a module, declare it with a module {} block. The name of the module can be anything you want. In our case the name is "standard_application". The source parameter specifies where the module is located in the file system, relative to the current file. The rest of the parameters are the variables we created earlier. Remember, any variable without a default value must be supplied by the user when calling the module directly.

It's good to know that modules don't have to be located on your local file system - they can be located in an external location. Tht's a more advanced topic, and we're not going to cover it in today's workshop. Feel free to investigate further if you're interested.

#### Testing your changes

Before we go any further, we need to destroy the resources we created earlier. We could use a built-in command from Terraform, `terraform destroy` (which destroys anything created by Terraform), or we can manually delete the resources from the Azure Portal by deleting the resource group we deployed previously.

It's probably easiest to navigate to the Azure portal and delete the resource group. Do that now. Come back here once you're finished.

Now that your Azure environment is cleaned up, let's deploy the resources like we did before.

First make sure we are in the c:\terraform\dev folder in our terminal. If not, cd to the appropriate folder level:

```bash
cd c:\terraform\dev
```

Run `terraform init` to initialize our configuration - you have to do this again because the new root `main.tf` file is located in a new sub-folder, `dev`.

```bash
terraform init
```

Next, run the `terraform plan` command. This isn't a required step for deployment but it is a good practice to follow in order to reduce potential errors.

```bash
terraform plan
```

If the output of the plan checks out, let's apply:

```bash
terraform apply
```
Type 'yes' to confirm the deployment. The resources will deploy to your Azure subscription exactly as written.

#### Checking your deployment

Open the Azure Portal and look for the resource group you created. This should look similar to what we deployed manually. Only now, we can deploy this as many times as we want with different values and it will return unique "standard_application" infrastructure deployments, each with their own unique resource group.

#### Extra credit

Just kidding. There's no extra credit, but if you want, copy the `dev\main.tf` file into the `prod` folder, change a couple of the parameter values we supplied, and deploy terraform from the prod folder to see a "production" environment next to your "development" environment. Note: This is not required for the other modules.

This concludes the exercise.

Well done! Another chapter down and you've learned how to make re-usable modules in Terraform.


text:
# Cryptic Song Lyrics

A throwback to the days of AIM: a Slack application to save and reuse status messages

![Node.js CI](https://github.com/stripethree/cryptic-song-lyrics/workflows/Node.js%20CI/badge.svg)

## Prerequisites

Access to a Slack team with the permissions to create an application and bot user are required. Slack will provide a `SLACK_APP_TOKEN` and this token needs to be available in the runtime environment.

Use [`example.env`](./example.env) as a guide.

My workflow is to copy this file to `.env` and use `export $(cat .env | xargs)` to prepare the environment.

## Usage

* `npm i` to install dependencies
* `npm run dev` to start a local instance of the
application with a file watcher

The _dev_ target assumes [_nodemon_] is installed and available globally; it is not included in the project dependencies.

[_nodemon_]: http://nodemon.io/

## Logging and metrics

The [debug] package is for a firehose of data sent to stdout/stderr

[debug]: https://github.com/visionmedia/debug

## Additional information

### Environment variables

| Key | Required? | Default? |
|-|-|-|
| `SLACK_APP_TOKEN` | Y | _none_ |

### Endpoints

None

repository: stripethree/cryptic-song-lyrics

repo_name: stripethree/cryptic-song-lyrics


text:
---
layout: lesson
topic: affectionate
categories: character
lesson_no: 417
published: true
---

## Elementary
### Verses
"And be kind to one another, tenderhearted." - _[Ephesians 4:32a](http://online.recoveryversion.org/bibleverses.asp?fvid=6160&lvid=6160)_

### Focus
An affectionate person is someone who is caring and tenderhearted towards people. They are warm and friendly to be around.

### Practical Application
When you meet a friend or a child you do not know, you should always greet him/her with a smile and a “hi” and invite them to join you in what you are doing. It does not feel good to walk into a room where you do not know anyone and just have everyone stare at you without smiling or speaking to you. To be affectionate, we should warmly welcome people. Have the children demonstrate how they could affectionately greet someone.

Song: No one likes to be left out

## Intermediate

### Verses
“But whoever has the livelihood of the world and sees that his brother has need and shuts up his affections from him, how does the love of God abide in him?.” - _[1 John 3:17](http://online.recoveryversion.org/bibleverses.asp?fvid=7452&lvid=7452)_

### Focus
An affectionate person is someone who has sympathy towards people. When a person approaches them with a problem, they are understanding, caring and feel for that person’s situation.

### Practical Application
If your friend comes to you and says he/she is hurt because someone said or did something mean to them, you would try to understand how they are feeling and take care of them instead of just ignoring them. An affectionate person will take an interest in other’s feelings and situations, will show sympathy and concern for them, and do their best to console them. Have the children demonstrate how they would console a friend who has been hurt by someone’s words.

## Advanced

### Verses
"And finally be all of the same mind, sympathetic, loving the brothers, tenderhearted,
humble-minded." - _[1 Peter 3:8](http://online.recoveryversion.org/bibleverses.asp?fvid=7288&lvid=7288)_

### Focus
An affectionate person is someone who is caring, tenderhearted, and sympathetic towards people, but they are not loose in how they display their affection. They are approachable and express their care and concern for people in a proper way.

### Practical Application
If someone is hurt walking home from school, an affectionate person would stop to help and care for him in a gentle way or would help him get home to his parents, even if it makes that person late. If someone has lost something which is precious to him, an affectionate person would stop what they are doing to help that person look for what is lost. To be affectionate does not mean that you try to be overly helpful or that you give a lot of hugs to people. Rather, it is to show a gentle and caring concern for them.

repository: hdfelix/cii-cw

repo_name: hdfelix/cii-cw


text:
---
out: day8.html
---

day 8
-----

Yesterday we hooked up our tetrix-solving agent to an actor to take control of the game. Thus far the way it handled the game looked neither rational nor intelligent. After seeing many of the moves evaluated to 0.0 score including the heuristic penalties, I had two sneaking suspicions.

First, `Drop` was never a good choice. Especially given the shallow search tree, selecting `Drop` seemed premature. Since the gravitational tick is going to take care of the downard movement anyway, I decided to ignore it when the agent thinks the best move is `Drop`:

```scala
  def receive = {
    case BestMove(s: GameState) =>
      val message = agent.bestMove(s)
      if (message != Drop) stageActor ! message
  }
```


text:
Wheelee - a wheelee good wheel
=======

Wheelee is an interactive doughnut chart implemented using the [D3](http://d3js.org/) Javascript libary

Features include:
* Automatic rotating doughnut segment expansion
* Linked doughut legend - legend keys highlight when the segment does!
* Amazing user interaction - users are able to hover over legend items or segments to make them expand
* Plus many more hidden features

## Demo

Have a look at the demo.html file in this repo

## Example Usage

### HTML

```html
  <div id="wheelee">
    <h2>Cat popularity by breed</h2>
  </div>

  <script type="text/javascript" src="http://d3js.org/d3.v3.min.js"></script>
  <script type="text/javascript" src="wheelee.js" /></script>
```

### Javascript

```js
  d3.select("#wheelee").wheelify({
    'title': 'Popularity of cats by breed',
    'data': { 'Persian':    22,
              'Maine Coon': 20,
              'Exotic':     16,
              'Siamese':    13,
              'Abyssinian': 12,
              'Ragdoll':    11,
              'Birman':     6 },
    'color': '#004dec',
    'lightenGamma': 3.2 });
```

## Config

.wheelify expects the following options to be set in its configuration:
* 'title' - The title of the doughnut chart. This not a displayed heading, but is used for setting the 'title' attribute of the chart
* 'data' - An associative array of chart data. Keys represent the key or name for each segment, values represent the percentge of each segment. All values must add up to 100.
* 'color' - The start (darkest) segment color of the doughnut
* 'lightenGamma' - How much you want to lighten the start colour by. This number represents the gamma amount used to lighten the colour to reach the lightest segment. It does this using D3's 'brighter' function - see [https://github.com/mbostock/d3/wiki/Colors](https://github.com/mbostock/d3/wiki/Colors) for more informantion.

## License

Wheelee is available under [the MIT license](http://mths.be/mit).


text:
---
title: Improved systemd integration with Podman 2.0
layout: default
author: tsweeney
categories: [blogs]
tags: podman, containers, v2, github, rename
---
![podman logo](https://podman.io/images/podman.svg)

# Improved systemd integration with Podman 2.0
{% assign author = site.authors[page.author] %}
## By {{ author.display_name }} [GitHub](https://github.com/{{ author.github }})

[Valentin Rothberg](https://twitter.com/vlntnrthbrg) just landed a blog post on the [Red Hat Enable Sysadmin](https://www.redhat.com/sysadmin/) site [Improved systemd integration with Podman 2.0](https://www.redhat.com/sysadmin/improved-systemd-podman).  In the post, Valentin talks about how systemd in Podman v2.0 is even more tightly integrated than it was in prior versions.


text:
## Simple Express Server
[![Donate](https://img.shields.io/badge/paypal-donate-179BD7.svg)](https://www.paypal.me/vedaterenoglu)

[![MIT license](http://img.shields.io/badge/license-MIT-lightgrey.svg)](http://opensource.org/licenses/MIT)

![express](https://user-images.githubusercontent.com/38211466/44811396-e2208a80-abd4-11e8-8185-f172cbb4da69.png)

The backend is generated with [Node.js](https://nodejs.org). The backend is based on [Express](http://expressjs.com). Whole stack in [JavaScript ES6](http://es6-features.org/#Constants).

## This project uses the followings:
* [**E**xpress.js](http://expressjs.com): backend framework
* [**N**ode.js](https://nodejs.org): runtime environment

Other tools and technologies used:
* [Babel](https://babeljs.io/docs/en/): It is used to convert ECMAScript 2015+ code into a backwards compatible version of JavaScript in current and older browsers or environments.

## Prerequisites
1. Install [Node.js](https://nodejs.org)
2. From project root folder install all the dependencies

```js
// Install the dependecies

npm i
```

## Run
### Development mode
```js
// run in development mode

npm start
```
It executes [babel](https://github.com/babel/babel/) and Express server.

Go to your browser;
* Open the link  [localhost:4200](http://localhost:4200) to see the home page. You will sipmly see a jason file shows the types of the books.

![screen shot 2018-08-29 at 15 20 26](https://user-images.githubusercontent.com/38211466/44790455-acad7a00-ab9f-11e8-9eb1-5f497a9c3484.png)

* Open the link  [localhost:4200/books](http://localhost:4200/books) to see books array as a JSON file.

![screen shot 2018-08-29 at 15 20 43](https://user-images.githubusercontent.com/38211466/44790539-e3839000-ab9f-11e8-88d9-23bf309b5f98.png)

## Please open an issue if
* you have any suggestion to improve this project
* you noticed any problem or error

## Wiki
To get more help about this project, [visit the official wiki](https://github.com/vedaterenoglu/graphql-server/wiki).

### Author
![Vedat Erenoglu](https://s.gravatar.com/avatar/0e529b095e48c12b9834e4d6ec081dc3?s=80)
* [Vedat Erenoglu](https://github.com/VedatErenoglu)
### e-mail:
*<EMAIL_ADDRESS>### Linkedin Profile
* https://www.linkedin.com/in/vedaterenoglu/

repository: vedaterenoglu/express-server-nodejs

repo_name: vedaterenoglu/express-server-nodejs


text:
## Changes since fork

-   Added 'displayField' property, where you can pass in an object key (single level) to render, this is useful if you want to pass in an array of objects, and want to render one of the fields.
-   Added 'fontSize' and 'lineHeight' prop, to allow further customisation of the text element rendered inside each option.

This has not been tested since 2019.

## react-native-wheel-scroll-picker

a pure js picker, each option item customizable

![example](./demo/test.gif)

### Usage example.

```shell
npm install react-native-fen-wheel-scroll-picker --save
```

```jsx
import React, { Component } from "react";
import ScrollPicker from "react-native-fen-wheel-scroll-picker";

export default class SimpleExample extends Component {
    render() {
        return (
            <ScrollPicker
                dataSource={["a", "b", "c", "d"]}
                selectedIndex={1}
                renderItem={(data, index, isSelected) => {
                    //
                }}
                onValueChange={(data, selectedIndex) => {
                    //
                }}
                wrapperHeight={180}
                wrapperWidth={150}
                wrapperBackground={"#FFFFFF"}
                itemHeight={60}
                highlightColor={"#d8d8d8"}
                highlightBorderWidth={2}
                activeItemColor={"#222121"}
                itemColor={"#B4B4B4"}
            />
        );
    }
}
```


text:
# robotling

"robotling" is a simple circuit board to control small robots. Check out the videos (videos [1](https://youtu.be/wil41YtIeN8), [2](https://youtu.be/cLstXW3RsBA), [3](https://www.youtube.com/watch?v=XF0T9Dlb07M), and with thermal camera, [4](https://youtu.be/qpSQO51BuJs), [5](https://youtu.be/tlYXab0FZrY)) and find the details in the German [wiki](https://github.com/teuler/robotling/wiki).

### Release Notes

* 2021-09-22
  - New firmware based on MicroPython v1.17 (w/`ulab`)
  -
* 2021-05-02
  - Some refactoring: Configuration parameters now clearly marked as such (`cfg.xxx`)

* 2021-05-01 - Release v1.9

* 2021-04-26
  - [Instructions](https://github.com/teuler/robotling/wiki/Adding-native-modules-to-MicroPython-(ESP32)) for building MicroPython (release 1.14) w/`ulab` and `umqtt` updated.
  - New pre-built ESP32 [firmware](https://github.com/teuler/robotling/tree/master/code/firmware_esp32) based on MicroPython v1.14 (w/`ulab` and `umqtt`)
  - Small bug fixes, now compatible w/ MicroPython v1.14 and "vanilla" v1.15 ([esp32-20210420-unstable-v1.15.bin](https://micropython.org/resources/firmware/esp32-20210420-unstable-v1.15.bin)).
  - Now uses `RobotlingBase` (from [`robotling_lib`](https://github.com/teuler/robotling_lib)), so better separate standard hardware and additional hardware defined in `devices` (in [hexbug_config.py](https://github.com/teuler/robotling/blob/master/code/robotling/hexbug_config.py)).
  - As [`robotling_lib`](https://github.com/teuler/robotling_lib) now includes `simple.py` and `robust.py` from [micropython-lib](https://github.com/micropython/micropython-lib) as fall-back, MQTT can now be used with the standard MicroPython firmware, which does not inlcude `umqtt`.
  - Added [instructions](https://github.com/teuler/robotling/wiki/Adding-native-modules-to-MicroPython-(ESP32)#-building-micropython-v115-and-higher-with-ulab-included) how to build the ESP32 firmware for MicroPython 1.15 with `ulab` included.

* 2021-04-05
  - Link to new Make: article added.
* 2020-08-30 (Blob detection revisited)
  - [Three versions](https://github.com/teuler/robotling/wiki/Verhalten#SeekBlob) of the blob detection and image filter code, demonstrating differences in speed between a pure MicroPython version and those that use [`ulab`](https://micropython-ulab.readthedocs.io/en/latest/ulab.html) or even user-written C functions added to `ulab`.
* 2020-08-21 (Refactoring)
  - Since it was difficult to maintain different versions of the robotling code all accessing the same set of driver etc. libraries, these files have now been moved to a separate repository ([`robotling_lib`](https://github.com/teuler/robotling_lib)).
  - Wiki updated accordingly.
  - New Wiki page on [adding native modules to MicroPython](https://github.com/teuler/robotling/wiki/Adding-native-modules-to-MicroPython-(ESP32)).

* 2020-07-04 (Code updates)
  - Simple GUI to show robot status via MQTT (`hexbug.gui.py`)
  - Support for [TinyPICO](https://www.tinypico.com/) added
  - Configurations for different hardware combinations
  - General class to manage and control a set of servos ([`servo_manager.py`](https://github.com/teuler/robotling/blob/master/code/robotling/motors/servo_manager.py)) and inprovements in Servo class
   - Class for [PCA9685 16-channel servo driver](https://www.adafruit.com/product/815) ([`servos_pca9685.py`](https://github.com/teuler/robotling/blob/master/code/robotling/motors/servos_pca9685.py))
   - Class for [18-channel Mini Maestro servo driver](https://www.pololu.com/product/1354) ([`servos_mini_maestro_18.py`](https://github.com/teuler/robotling/blob/master/code/robotling/motors/servos_mini_maestro_18.py))

* 2019-12-30 (requires MicroPython 1.12.x)
  - [Thermal camera](https://github.com/teuler/robotling/wiki/Sensoren-etc#AMG88XX) support added ([`amg88xx.py`](https://github.com/teuler/robotling/blob/master/code/robotling/driver/amg88xx.py) and [`camera_thermal.py`](https://github.com/teuler/robotling/blob/master/code/robotling/sensors/camera_thermal.py); new behaviour [`lookAtBlob`](https://github.com/teuler/robotling/wiki/Verhalten#SeekBlob) using the thermal camera (see videos [4](https://youtu.be/qpSQO51BuJs), [5](https://youtu.be/tlYXab0FZrY)). _Note that the blob detection (not the camera itself) requires a custom MicroPython [firmware](https://github.com/teuler/robotling/tree/master/code/firmware_esp32) that includes the module [`blob`](https://github.com/teuler/robotling/tree/master/code/modules/blob) (coded in C for speed reasons)._
  - Configuration file split into fixed ([`hexbug_global.py`](https://github.com/teuler/robotling/blob/master/code/robotling/hexbug_global.py)) and robot-dependent definitions
  - Code adapted to MicroPython release 1.12.x, including hardware I2C bus option added and native code generation added for time critical routines (ESP32 only)
  - PWM frequencies for servos and DC motors are now defined in `robotling_board.py` to account for the fact that the ESP32 port supports only a single frequency for all standard PWM pins. In addition, [`drv8835.py`](https://github.com/teuler/robotling/blob/master/code/robotling/driver/drv8835.py) now uses the RMT feature of the ESP32 for PWM to run the DC motors. This allows using a different frequency than the normal PWM functions.

* 2019-11-15
  - New articel in the German Make: magazine (["Krabbelroboter sendet Telemetrie"](https://www.heise.de/select/make/2019/7/1573927054956141)).
* 2019-08-31
  - New type of Sharp sensor added (GP2Y0AF15X, 1.5-15 cm) to `sensors\sharp_ir_ranging.py`. This allows using a triple IR distance sensor array such that the robot's head does not need to scan sideways.
  - I2C frequency increased to 400 kHz in `robotling_board.py`. The I2C frequency used is now also printed when the robot boots.
  - Robotling v1.3 board in `robotling_board_version.py`.
  - In case of an uncaught Python exception, the firmware tries to send a last MQTT message containing the traceback, allowing to get information on code errors even when the robot is not attached via USB.
  - Wiki page [Telemetrie über MQTT](https://github.com/teuler/robotling/wiki/Telemetrie-%C3%BCber-das-MQTT-Protokoll)

* 2019-07-25
  - Now an option was added to send telemetry via WLAN using the MQTT protocol (ESP32 only). An example script (`test_mqtt.py`) that demonstrates how to subcribe to robotling telemetry on a PC was added to `../code`.
  - `hexbug.py` - Bias factor (`IR_SCAN_BIAS_F`) added to the configuration file `hexbug_config.py`; it allows correcting for a direction bias in the turning motor. Also, the scan scheme was slightly changed from "left-right-center" to "left-center-right-center", which helps the robot to walk more straight.
  - `telemetry.py`- Encapsules the MQTT functionality.
  - `main.py` - Simple "memory" was added to remember the direction of successful turns (experimental).
  - `robotling.py` - Now the keyword "wlan" can be added as a device to `MORE_DEVICES` in `hexbug_config.py` to activate the network (instead of changing `boot.py`)
* 2019-07-22
  - Robotling code moved from `../code` to `../code/robotling`
* 2019-07-16 - Release v1.7
  - New wiki pages ['Sensors etc.'](https://github.com/teuler/robotling/wiki/Sensoren-etc) with supported sensors and ['Verhalten'](https://github.com/teuler/robotling/wiki/Verhalten) with behaviours added
  - Wiki pages ['Demo'](https://github.com/teuler/robotling/wiki/Demo) and ['Erweiterungen und Modifikationen'](https://github.com/teuler/robotling/wiki/Erweiterungen-und-Modifikationen) updated
  - Code Release [v1.7](https://github.com/teuler/robotling/releases)
* 2019-05-18 - Release v1.6
  - Added new "behaviour" (take a nap) based on deepsleep/lightsleep support for ESP32
  - Cleaned up the code
  - Changed `hexbug_config.py`to make it also standard Python compatible (for future extension)
  - Now uses `getHeading3D` instead of `getPitchRoll` to determine if the robot is tilted; the additional
    compass information (heading) is saved (for future extension).
  - Driver for LSM9DS0 magnetometer/accelerometer/gyroscope added.
* 2019-03-17 - Release v1.5
  - Some code improvements (handing devices, cleaning up)
  - Tested w/ MicroPython v1.10
  - New pictures
  - A new wiki page with extentions and modifications
* 2019-03-02
  - New pictures, annotated pictures of board v1.2
  - some new text on memory and performance
* 2019-01-12
  - A few bug fixes
  - More drivers (dotstar, VL6180X).
  - Works now also with the M4 Express Feather from Adafruit (and CircuitPython).
* 2018-12-28 - Release v1.3
  Eliminated the need for a timer. Added `spin_ms()`, which needs to be called once per loop and instead of `sleep_ms()` to keep board
  updated. This solution is superior to the use of a timer, because (i) it is deterministic (avoids randomly interrupting the program
  flow and, hence, inconsistencies) and (ii) makes the code compatible to CircuitPython, which does not (yet?) support timers.
* 2018-12-24 - Release v1.2
  Now board v1.2 included, some code refactoring and improvements
* 2018-11-29 - Release v1.1
  First complete version for board v1.0 and huzzah32
* 2018-11-18 - Initial release

### Unresolved Issues

  - Tilt correction and calibration for LSM303 and LSM9DS0 compass function is not yet implemented.

repository: teuler/robotling

repo_name: teuler/robotling