text:
A filter is just a short little script executed for every item matched. In the evaluated context, there is a 'trade' and an 'item' object (items) available, with these properties:

# trade

- int tradeid
- bool completed
- string poster
- bool premium
- string trademsg
- object bump{string absolute, string formatted, string fromNow}
- object created{string absolute, string formatted, string fromNow}
- array has[item]
- array wants[item]
- int views
- int bookmarks

# item

- int? id (int for the has array, undefined for the wants array) (current item id, not original_id)
- bool has
- bool wants
- bool disabled
- string defindex
- string game
- string quality
- string name

- bool tradable
- bool craftable
- bool australium
- bool gifted
- string customName
- string customDesc
- string paint
- object killstreak[killstreak]
- string effect
- int craft (-1 if none)

# killstreak

- bool active
- string sheen
- string killstreaker

There are also some helper functions available:

- when.has, when.wants | Use these if you only want to match one side. Signature is (item, condition) - see below.
- when.offer | Matches '[game] Offers'. Signature is (item).

Example usage (trade):

```
-f "!trade.completed" (filters non-completed)
-f "!trade.completed && trade.views < 100" (filters non-completed, plus view count must be >= 100)
-f "!trade.premium" (filters trades by premium members)
-f "trade.premium" (filters trades by non premium members)
```

Example usage (item):

```
-f "item.quality !== '6'" (unique quality only)
-f "item.name !== 'Mann Co. Supply Crate Key' && item.name !== 'Refined Metal'" (keys and ref only)
-f "when.has(item, !item.australium)" (has item, not australium -> removed)
-f "when.wants(item, item.painted)" (want item, painted -> removed)
-f "when.offer(item)" (if item is 'Offers', discard trade)
```

If any filter returns a truthy value, the entire trade is discarded. As a special case, if a regular expression is returned as a result (/exp/ instanceof RegExp), its test method is called with the trade's trademsg. If that returns true, the trade is discarded.

Example with RegExp:
```
-f "/australium/i" (/australium/i.test(trade.trademsg)) - hide trades with "australium" in the notes
```

It's also possible to skip the review process and just use the filter:

```
-r filter
```

repository: HRDepartment/outpostd

repo_name: HRDepartment/outpostd


text:
# godot-engine.editor-twitch-chat
Integrate the chat of your Twitch Channel inside Godot Engine's editor! Enable it when you are doing a dev-stream or just want to check your Twitch chat while coding.

![demo](screenshots/twitch_chat_demo.gif)

This is just an experimental project to play with Twitch APIs.
In order to get it work you just need to know the Twitch channel's name you want to join and get a token.
To get a token, just click on the button _"Get a token here"_ and follow the instructions.
Once logged, your information will be stored in an encrypted file and next log will be automatically done.

license: MIT

branch_name: refs/heads/main

extension: md

license_type: permissive


text:
# Xcluster/ovl - kselftest

Linux kernel self-test.

https://www.kernel.org/doc/html/v5.0/dev-tools/kselftest.html

Include the ovl kselftest when starting xcluster
```
xcluster_start kselftest ...
```

repository: Nordix/xcluster

branch_name: refs/heads/master

gha_language: Roff

gha_license_id: MIT

repo_name: Nordix/xcluster


text:
---
layout: post
title: "Customize Awesome"
date: 2014-04-30 21:12
comments: true
categories: awesome
---
###Wallpaper Setting
When switching to big display in awesome, the desktop background will not fill the whole screen, thus we need to automatically set the background when we execute the ./singleview script, ./singleview script is a script which I wrote for switching to big display. Listed as following:

```
killall conky
xrandr --output LVDS1 --off
xrandr --newmode $(gtf 1680 1050 60 | grep Modeline | sed s/Modeline\ // | tr -d '"')
xrandr --addmode VGA1 1680x1050_60.00
xrandr --output VGA1 --mode 1680x1050_60.00
xscreensaver -nosplash &
xset -b
xmodmap -e "pointer = 3 2 1"
fcitx &
sleep 4
###Add bluetooth
pactl load-module module-alsa-sink device=btheadset
pacmd load_module module-bluetooth-discover
###Set Background
feh --bg-scale /home/Trusty/document/water.jpg

```
The last line is the newly-added one which is used for re-setting the background wallpaper.
###Conky Background Setting
But when you set the background, your conky will become ugly, just like following picture:
![/images/nobg.jpg](/images/nobg.jpg)

So you need to set the ~/.conky.rc, add following lines:

```
own_window yes
own_window_colour 41A834
TEXT
......
${image  /home/Trusty/document/greenleaf2.jpg  -p 0,0 -s 300x540}

```
The "own_window yes" could be commented.
So now you got conky looks like following:
![/images/goodbg.jpg](/images/goodbg.jpg)

repository: purplepalmdash/NewBlog

extension: markdown

repo_name: purplepalmdash/NewBlog


text:
+++
title = "Login to AppDynamics"
chapter = false
weight = 2
+++

![image](/images/mobilize/ad_team_architect.png)

## Login to the AppDynamics Controller

Once the setup utility has finished, you can find your login credentials to your AppDynamics Controller by using the commands below:

```
cd /home/ec2-user/environment

cat workshop-user-details.txt
```

Your workshop user details file should have the following information similar to the image below:

- The URL to the AppDynamics Controller you will use
- The credentials you will use to login to the Controller
- The names of the Pre-Modernization APM and EUM applications
- The names of the Post-Modernization APM and EUM applications

![image](/images/mobilize/user_details.png)

In a separate browser tab or window, navigate to the URL that is next to Controller URL in the workshop user details file. Use the data from the workshop user details file to login to AppDynamics.

{{% notice tip %}}
The account and username are two distinct fields that are used as part of logging in.
{{% /notice %}}

![image](/images/mobilize/appd_login.png)

## Next <i class='fas fa-cog fa-spin'></i>

 We'll start the **assessment of the pre-modernized version** of the **AD Financial web front-end**.

<!---
{{% notice warning %}}
The Cloud9 workspace should be built by an IAM user with Administrator privileges,
not the root account user. Please ensure you are logged in as an IAM user, not the root
account user.
{{% /notice %}}
-->

<!---
{{% notice info %}}
This workshop was designed to run in the **Oregon (us-west-2)** region. **Please don't
run in any other region.** Future versions of this workshop will expand region availability,
and this message will be removed.
{{% /notice %}}
-->

<!---
{{% notice tip %}}
Ad blockers, javascript disablers, and tracking blockers should be disabled for
the cloud9 domain, or connecting to the workspace might be impacted.
Cloud9 requires third-party-cookies. You can whitelist the [specific domains]( https://docs.aws.amazon.com/cloud9/latest/user-guide/troubleshooting.html#troubleshooting-env-loading).
{{% /notice %}}
-->


text:
# Hugo Progression
Hugo Progression is a [Hugo](https://gohugo.io/) template that can render progression frameworks using the same data format as the [Monzo progression framework](https://github.com/monzo/progression-framework)

![Hugo Progression Screenshot](https://github.com/leeturner/hugo-progression/blob/main/images/hugo-progression-screenshot.png "Hugo Progression Screenshot")

A full demo of this template (and the site contained within the `exampleSite` folder) can be found at the [Hugo Progression Demo Site](https://leeturner.github.io/hugo-progression-demo/)

## What Are Progression Frameworks ?

A progression framework (or ‘competency matrix’, ‘career ladder’, ‘career pathway’) is a tool to help people within an organisation understand where they currently are and how to progress and grow in their work.  It also helps an organisation map people's competencies (their skills and knowledge) to compensation (how they're rewarded for them financially).

When done right, a tool like this helps employees to grow and hone their strengths, and helps managers ensure that their organisations are in good shape and their employees happy.

### Resources
* https://monzo.com/blog/2019/01/07/progression
* https://github.com/monzo/progression-framework
* https://www.progression.fyi/

## How To Build Your Progression Framework With Hugo Progression

Everything discussed here can be found in the [`exampleSite`](https://github.com/leeturner/hugo-progression/tree/main/exampleSite) folder within this repository.

### 1) Installation

Navigate to your themes folder in your Hugo site and use the following commands:

```
cd themes/
git clone https://github.com/leeturner/hugo-progression.git
```

If you don't want to clone the theme you can add it as a git submodule. Inside the folder of your Hugo site run:

```
git submodule add https://github.com/leeturner/hugo-progression.git themes/hugo-progression
```

For more information read the [official setup guide](https://gohugo.io/overview/installing/) of Hugo.

### 2) Setup Your Framework Data & Content

Due to some restrictions in what data `hugo` allows in the markdown front matter along with how you reference data files in `hugo`, an individual framework needs to consist of 3 things:

* a markdown page that contains the homepage of the framework
* a data `yml` file containing the content for each level of the framework
* a hugo html partial that links the above together.

```
+-----------+       +------------+       +------------+          +-------------+
| Markdown  |       |    html    |       |  data yml  |          | Individual  |
|   file    |------>|   partial  |------>|    file    |     =    | Progression |
|           |       |            |       |            |          |  Framework  |
+-----------+       +------------+       +------------+          +-------------+
```

#### 2.1) Create Your Framework Data Files

In this step we will create the `hugo` data file that contains the data for the different areas and levels for an individual framework.  These data files are `yml` and follow the same format as the Monzo data files.  A partial example of one of these data files is included below:

```yaml
topics:
  - name: "communication"
    title: "💬 Communication"
    content:
      - level: 1
        criteria:
          - "Provides regular status updates to their mentor/buddy"
          - "Points out syntactical improvements in code reviews"
          - "Writes PR descriptions that provide basic context for the change"
          - "Seeks guidance from other engineers, rather than answers"
      - level: 2
        criteria:
          - "Proactively communicates to their team what they are working on, why, how it's going and what help they need"
          - "Accepts feedback graciously"
          - "Gives feedback to peers when asked"
        exampleCriteria:
          - criteria: "Provides helpful and actionable feedback in code reviews in an empathetic manner"
            examples:
              - "Take a look at the levelling up your code reviews talk for some ideas"
          - criteria: "Writes PR descriptions that provide context and provide rationale for significant decisions"
            examples:
              - "I decided to X instead of Y here, I also considered Z but for these reasons I went with X"
  - name: "impact"
    title: "💥 Impact"
    content:
      - level: 1
        criteria:
          - "Delivers assigned tasks, working with a more senior team member, and able to take PR feedback to improve their work"
      - level: 2
        criteria:
          - "Delivers assigned tasks that meet expected criteria"
          - "Works for the team, focuses on tasks that contribute to team goals"
          - "Tries to unblock themselves first before seeking help"
          - "Manages their own time effectively, prioritises their workload well, on time for meetings, aware when blocking others and unblocks"
          - "Helps the team, does what needs doing"
          - "Breaks down small/medium problems into iterative steps"
```

These framework data files need to be placed in the `data` folder for your `hugo` site.  They can be structured into sub-folders if you wish:

```
data
  frameworks
    engineering
      backend.yml
      data.yml
      mobile.yml
      qualityanalyst.yml
      web.yml
    operations
      opsindividualcontributor.yml
      opsleadership.yml
    generic.yml
    marketing.yml
    people.yml
    product.yml
```

See the [examples in the `exampleSite`](https://github.com/leeturner/hugo-progression/tree/main/exampleSite/data/frameworks) folder if you want to see more complete examples.

#### 2.2) Create The Markdown Page With Front Matter & Content For The Framework Homepage

For any of the frameworks to appear in your `hugo` site you will need a markdown file that contains the correct front matter and the content for the homepage of the individual framework. As with any `hugo` site, these markdown files live in the `content` folder.  The front matter can contain all the usual `hugo` fields along with a couple of special fields specific to `hugo-progression`.  See the example below:

```markdown
---
title: 🛠 Backend Engineering Framework
linktitle: 🛠 Backend
description: Backend engineering progression framework
menu:
  main:
    parent: engineering
levels: 6
datafilepartial: engineering/backend-partial.html
---
```

The two fields that are specific to `hugo-progression` are `levels` and `datafilepartial`.  The `levels` field specifies how many levels there are in this individual framework which must correspond to the number of levels in your framework `yml` data file.  This will also determine how many levels are created in the menu when the site is generated:

![Hugo Progression Levels](https://github.com/leeturner/hugo-progression/blob/main/images/hugo-progression-levels.png "Hugo Progression Levels")

The `datafilepartial` field links the markdown file to the specific html partial for this individual framework.  We will create this html partial in the next step

See the [examples in the `exampleSite`](https://github.com/leeturner/hugo-progression/tree/main/exampleSite/content) folder if you want to see more complete examples.

#### 2.3) Create The HTML Partial

Because `hugo` won't allow us to specify a data file in the front matter of a markdown file we have to create a simple `hugo` html partial file for each framework data file to get around this.  If you want to understand more about this restriction in `hugo` take a look at this article by [Michele Titolo](https://michele.io/) which helped me understand how to work around it - https://michele.io/content-data-hugo/

I have tried to take out all the common elements make sure the html partial files are as small as possible, and the below example is as small as I could get it.

```gotemplate
{{ $this_parent_index := .parent_index}}
{{ range .site_data.frameworks.engineering.backend.topics }}
{{ partial "topic-by-level.html" (dict "context" . "parent_index" $this_parent_index) }}
{{ end }}
```

As you can see, the one line that is specific to the data file is the `range` line:

```gotemplate
{{ range .site_data.frameworks.engineering.backend.topics }}
```

This line will change for each of the html partial files but all the rest will stay the same.  The path to the `topics` effectively matches the folder structure you used when you created your data files. To keep things consistent I store my html partials in the same directory structure as my data files:

```
layouts
  partials
    engineering
      backend-partial.html
      data-partial.html
      mobile-partial.html
      qualityanalyst-partial.html
      web-partial.html
    operations
      opsindividualcontributor-partial.html
      opsleadership-partial.html
    generic-partial.html
    marketing-partial.html
    people-partial.html
    product-partial.html
```

Once you have created your html partial file that references the framework data file, make sure you are correctly referencing the html partial in your markdown file as in the example above:

```markdown
---
datafilepartial: engineering/backend-partial.html
---
```

See the [examples in the `exampleSite`](https://github.com/leeturner/hugo-progression/tree/main/exampleSite/layouts/partials) folder if you want to see more complete examples.

### 3) Nearly finished

In order to see your site in action, run Hugo's built-in local server.

`$ hugo server`

Now enter [`localhost:1313`](http://localhost:1313/) in the address bar of your browser.

## Production

To run in production, run `HUGO_ENV=production` before your build command. For example:

```
HUGO_ENV=production hugo
```

Note: The above command will not work on Windows. If you are running a Windows OS, use the below command:

```
set HUGO_ENV=production
hugo
```

## Contributing

If you find a bug or have an idea for a feature, feel free to use the [issue tracker](https://github.com/leeturner/hugo-progression/issues) to let me know.

If you want to implement new features on the Hugo Progression template, please see the [TODO](https://github.com/leeturner/hugo-progression/blob/main/TODO.md) file for ideas of where to start.

repository: leeturner/hugo-progression

repo_name: leeturner/hugo-progression


text:
The theme of this project, as you can see by the title, is about a Star system. Its not focused on adding planets realistically but more into adding OpenGL features, like rotation, transparency, etc.

It has de following features:
- Earth like planet with multitextures and rotation around the star. It has also diffused, specular and ambient lighting. Independent shader.
- Moon like planet that rotates around the earth. Contains same lighting as earth, also including transparency. Sharing shader with the blue planet.
- Star in the center. It has no lighting effect as it has to simulate the light in the star system.
- Skybox with the milky way texture, without lighting. Both the Skybox and the star shares the same shader.
- Blue planet that rotates around the sun. It has the same features as the moon, full lighting and a bit of transparency.

Controls:
- W: Forward
- S: Backwards
- A: Left
- D: Right
- F: Down
- R: Up
- Z: Increase elocity
- X: Decrease  velocity
- V: Increase rotation
- B: Decrease rotacion
- L: Activate/Deactivate Mouse Lock
- SPACE: Center mouse in center

repository: gabrielcammany/StarSystem

repo_name: gabrielcammany/StarSystem


text:
---
layout: post
category: doc
title: Urbit Made Easy : Chapter I
---

#"What one fool can do, another can"#

A lot of people think that Urbit is complicated. A lot of people are wrong.

This guide assumes no prior knowledge of programming, computer science or math.

#Chapter I: What is Nock?#

Let's start with the formal specification of Nock. Don't worry, it's much less
scary than it looks.

**1. Structures**

	A noun is an atom or a cell.  An atom is any natural number.
 	A cell is any ordered pair of nouns.

**2. Pseudocode**

	1  ::    nock(a)           *a
	2  ::     a b c]           a [b c]]
	3  ::
	4  ::    ?[a b]            0
	5  ::    ?a                1
	6  ::    +[a b]            +[a b]
	7  ::    +a                1 + a
	8  ::    =[a a]            0
	9  ::    =[a b]            1
	10 ::    =a                =a
	11 ::
	12 ::    /[1 a]            a
	13 ::    /[2 [a b]]          a
	14 ::    /[3 [a b]]          b
	15 ::    /[(a + a) b]      /[2 /[a b]]
	16 ::    /[(a + a + 1) b]  /[3 /[a b]]
	17 ::    /a                /a
	18 ::
	19 ::    *[a [[b c] d]]      [*[a [b c]] *[a d]]
	20 ::
	21 ::    *[a [0 b]]          /[b a]
	22 ::    *[a [1 b]]          b
	23 ::    *[a [2 [b c]]]      *[*[a b] *[a c]]
	24 ::    *[a [3 b]]          ?*[a b]
	25 ::    *[a [4 b]]          +*[a b]
	26 ::    *[a [5 b]]          =*[a b]
	27 ::
	28 ::    *[a 6 [b [c d]]]    *[a 2 [0 1] 2 [1 c d] [1 0] 2 [1 2 3] [1 0] 4 4 b]
	29 ::    *[a 7 [b c]]        *[a 2 b 1 c]
	30 ::    *[a 8 [b c]]        *[a 7 [[7 [0 1] b] 0 1] c]
	31 ::    *[a 9 [b c]]        *[a 7 c 2 [0 1] 0 b]
	32 ::    *[a 10 [[b c] d]]   *[a 8 c 7 [0 3] d]
	33 ::    *[a 10 [b c]]       *[a c]
	34 ::
	35 ::    *a                *a

As you're going through the first part of this guide, it will be helpful to
have a copy of the specification that you can quickly refer to.

Nock may look intimidating now, but by the end of this guide, you will have
utterly mastered it.

Nock is what some fancy people call a "computational automaton." All that means
is it's a list of rules about how to turn symbols into other symbols. You put
some symbols in, you follow the rules, and you get some symbols out.

##Atoms & Cells##

The symbols that go into Nock are called nouns, which are just numbers and
pairs of numbers (and pairs of those pairs, but we'll get to that). The numbers
that go into Nock are called "atoms" and are always positive whole numbers. In
math, these are called "natural numbers," because they're the set of numbers
used for counting. In Nock, we'll write atoms in two different ways. The first
way, when we know what the atom is we'll just write the number: `1`, `2`, `3`, `4`... `424`, `9.904` etc.

(Note: Nock, and Urbit as a whole, use a period instead of a comma for long numbers.  You'll see why much later on.)

The second way we write atoms is with single letters. We do this when we don't
know what the atom is, so we use letters (`a`, `b`, `c`, `d` etc.) as placeholders or
variables. This isn't actually part of Nock and we only do it in the rules that
make up Nock, so we can describe what those rules are. In real Nock code, there
are no letters.

This is actually a really important point to keep in mind: The formal
definition of Nock isn't written in Nock, but is actually written in English.
Albeit a really funky kind of English (called "pseudocode")

Pairs of atoms are written using square brackets, and we separate the pairs
with a space. Like so:

	[1 1]
	[34 45]
	[123.456.789 987.654.321]

A pair of atoms is called a cell. If we wanted to write pseudocode Nock, we
could write:

	[a 1]
	[34 b]
	[c d]

Where `a`, `b`, `c` and `d` all are standing in for atoms.

Both atoms and cells are called nouns, which are the symbols (the fancy word is
"expressions") that go into Nock. You can think of Nock as a machine that
transforms nouns into other nouns.

I think we're ready to take a look at the first part of the formal Nock
definition:

**1. Structures**

	A noun is an atom or a cell.  An atom is a natural number.
	A cell is any ordered pair of nouns.

The first two sentences we've covered. The third sentence adds a new concept:
Cells can go inside other cells.

Remember that since a noun is either an atom or a cell (a number or a pair),
then a pair of nouns can be a pair of atoms, a pair of cells, or the pair of an atom and a cell. Like so:

	[1 1]
	[1 [2 3]]
	[[1 1] [2 3]]

Any cell in Nock, you can put inside another cell. This means that the cells
can get arbitrarily long (or nest arbitrarily deep). All of the following are
valid cells:

	[2 3]
	[2 [6 7]]
	[2 [6 [14 15]]]
	[2 [6 [14 [30 31]]]]
	[2 [6 [14 [30 [62 63]]]]]
	[[4 5] 3]
	[[[8 9] 5] 3]
	[2 [[12 13] 7]]
	[2 [[12 13] [14 15]]]

As you can see, the brackets start to pile up, making this somewhat difficult
to read.

##Brackets: Who Needs Them?##

Fortunately, there's a rule in Nock that helps make things more legible: We can
leave out all the brackets that group to the right, because Nock will just add
them back in. That means instead of writing:

	[[2 3]
	[2 [6 7]]
	[2 [6 [14 15]]]
	[2 [6 [14 [30 31]]]]
	[2 [6 [14 [30 [62 63]]]]]
	[[4 5] 3]
	[[[8 9] 5] 3]
	[[2 [[12 13] 7]]
	[2 [[12 13] [14 15]]]

We can just write:

	[2 3]
	[2 6 7]
	[2 6 14 15]
	[2 6 14 30 31]
	[2 6 14 30 62 63]
	[[4 5] 3]
	[[[8 9] 5] 3]
	[2 [12 13] 7]
	[2 [12 13] [14 15]]

The brackets haven't gone away, we've just decided not to write them.

We can do this because of `line 2` of Nock, which puts the brackets back in.

	2  ::    a b c]          a [b c]]

Simply speaking, line 2 says that brackets always group to the right.Before we
go into this, we need to quickly cover two things:

First, we need to extend our understanding of letters being placeholders for
atoms. Letters can also stand in for cells. A letter represents a noun. So
whenever you see a letter, all that that means is "Noun goes here." And that
noun can be, of course, either an atom or a cell.

Second, we need to explain how to read the Nock's rules. Nock has a left-hand
column, and a right-hand column. The left-hand column is for inputs, the
right-hand column, for outputs. You take a noun, match it to the pattern on the
left. And then you transform your noun so that the pattern on the left becomes
the pattern on the right. The whole process is called a "reduction."

We'll walk you through how this works:

Let's say that we have the noun `[2 6 7]`. `Line 2` says:

	2  ::   a b c]           a [b c]]

We can match `[2 6 7]` to `a b c]`, because they have the same structure. `a` is the
placeholder for `2`, `b` for `6` and `c` for 7, and the right bracket in `a b c]` matches
the right bracket in `[2 6 7]`.

(There are no left brackets in `line 2`. This is not a typo, we'll show you why
when we actually go through the mechanics of applying `line 2`).

Let's line up `[2 6 7]` and `a b c]` so that the right-brackets align.

	[2 6 7]
	 a b c]

Pretty clearly, `a` is `2`, `b` is `6` and `c` is `7`. So you could rewrite our noun `[2 6 7]` as `[a b c]`.

The right-hand side of `line 2` says:

	a [b c]]

Meaning we need to insert a left-bracket before `b`, and a right bracket after `c`.

Our input noun:

	[2 6 7]

We replace nouns with the matching letters (`a` is `2`, `b` is `6`, `c` is `7`):

	[a b c]

We do the transformation (putting the left-bracket and right-bracket in):

	[a [b c]]

And finally we turn the letters back to nouns

	[2 [6 7]]

And that's our output. We've just done our very first Nock reduction! `[2 6 7]`
goes into Nock, and `[2 [6 7]]` comes out.

Let's try putting the more complicated noun `[2 6 14 15]` into `line 2`:

	2  ::    a b c]           a [b c]]

We start on the inside, because the right-brackets have to align.

	[2 6 14 15]
	   a  b  c]

Like we did before, we replace nouns with their matching letters. `a` is `6`, `b` is `14` and `c` is `15`.

	[2 a b c]

We do the transformation and add in the brackets

	[2 a [b c]]

And finally we replace our placeholder letters with their corresponding nouns.

	[2 6 [14 15]]

But we're not done yet! We still have another pair of brackets to add. Unlike
what we did before with the noun `[2 6 7]`, the noun `[2 6 14 15]` has to go
through `line 2` twice before its reduction is complete. We do this by taking
the output noun from our first time through `line 2` (`[2 6 [14 15]]`) and then putting that noun back in to Nock as input.

We'll go through it a bit faster this time, but the process is still exactly
the same.

Align expressions (remember that letters can be either atoms or cells):
	[2 6 [14 15]]
	 a b    c   ]

Turn nouns to letters:

	[a b c]

Transform noun according to the right-hand side:

	[a [b c]]

Turn letters to nouns (`a` is `2`, `b` is `6`, `c` is `[14 15]`):

	[2 [6 [14 15]]]

Which is our final output, with all the brackets added back to the noun
`[2 6 14 15]`. For even more complicated nouns, like `[2 6 14 30 31]` or
`[2 [12 26 27] 14 15]`, you would have to apply the rule from line 2 even more times.
Every time you transform a noun using a rule in Nock, you have to take the
output of that transformation and run it through Nock again until no more
patterns in the left-hand column match. Nock has further rules that describe
how and when you end the reduction process. We'll get into these rules in a
moment.

Before we do, and completely move on to bigger and better things, we should
briefly cover why `line 2` has mismatched brackets, because that does look a
little odd. The answer to this is simply that if `line `2 had left-brackets,
our pattern-matching with nouns that need multiple transformations wouldn't
work.  We wouldn't have been able to match `[2 6 14 15]` to the pattern `[a b
c]`, because the brackets wouldn't have lined up. To actually have gone through
and done the mechanical reduction this way, we would have had to ignore what
`line 2` actually says, and reconstruct in our minds what it actually means.
Which would have been very confusing for everyone.

On to Chapter 2, where we'll start learning the notation of Nock reductions!


text:
Welcome! If you would like to submit a pull-request, please
follow the following guidelines.

- Limit your changes to those relevant to an existing issue.
- If an issue doesn't yet exist, please create one first.
- Do not update the package.json or .version file unless explicitly invited to.
- Do your best to follow the implicit style-guidelines in each file.
- Because the capabilities provided by this module are limited in scope,
  we target 100% code coverage in our testing suite. Please add tests
  for any new capability you add to the package's scope.

There are a variety of test-automation actions that will need
to pass for a pull-request to be merged. `npm run lint` and `npm run testall`
will reveal most issues before those test-automation actions
complain.

repository: schwer/graphql-to-openapi

gha_language: TypeScript

repo_name: schwer/graphql-to-openapi


text:
# 0.22-beta

* Fixed: Cleanup of the artifact post run report

# 0.21-beta

* New: `GOPRIVATE` should be `direct` to ensure that removed
  dependencies are spottet and reduce information leackage
* New: Prints produced artifacts when done
* Fixed: GitHub URL information was wrong for GHE

# 0.20-beta

* Fixed: When publishing, `csproj` file is needed after 7.0.200

# 0.19-beta

* New: Clean `v|version` prefix for semantic versions
* New: Now possible to control the container name for .NET service using
  a `bake.yaml` file
* New: `DOTNET_ROLL_FORWARD` now defaults to `LatestMajor`
* Fixed: Container paths that contain `/` are now valid

# 0.18-beta

*  New: Expose go ldflags via environment variable
*  Fix: Fixed .NET warning `NETSDK1179`

# 0.17-beta

* New: Set some sensible values to `DOTNET_NOLOGO`,
  `DOTNET_SKIP_FIRST_TIME_EXPERIENCE`, `NUGET_XMLDOC_MODE`
  and `NUGET_EXE_NO_PROMPT`
* New: Basic support for NodeJS by looking for `package.json` files, building
  a container and using the script from the `main` property as entry

# 0.16-beta

* New: Ability to upload Helm charts to ChartMuseum

# 0.15-beta

* Fixed: Actually a working upload to Octopus Deploy

# 0.14-beta

* New: Allow naming of containers by creating a `bake.yaml` file besides
  the `Dockerfile`

# 0.13-beta

* New: Push Helm charts to Octopus Deploy raw package feed
* Fixed: .NET test reports now have unique names to ensure that reports
  are not overwritten if a projects targets multiple frameworks

# 0.12-beta

* Fixed: Not limits description of NuGet packages to 4.000 characters

# 0.11-beta

* New: Use content of `README.md` files as DLL and NuGet descriptions
* New: .NET test reports are now saved as `.trx` files allow artifact uploads
  to pick these up after build completion
* Fixed: Bake is now better at picking release notes with versions that
  are *similar* to the build version if no exact match can be found. As
  an example `1.0-alpha` is picked among `1.1`, `1.0-alpha` and `0.9`
  when the build version is `1.0.42`

# 0.10-beta

* Fixed: Project DLLs are now actually added to NuGet packages

# 0.9-beta

* New: If there is no `.dockerignore` file found when building a `Dockerfile`,
  create one with some sensible defaults
* New: By default, Docker builds will compress build context before sending
  it to the Docker daemon
* Fixed: Required `RepositoryUrl` parameter for NuGet packages is now
  the correct URL for the repository... for real this time

# 0.8-beta

* New: Now understands Python Flask applications and bundles these
  into containers
* Fixed: Required `RepositoryUrl` parameter for NuGet packages is now
  the correct URL for the repository

# 0.7-beta

* New: Produce ASP.NET Core containers that are able to run in read-only
  file systems, run as non-root as well as drop all capabilities. Here is
  an example security configuration
  ```yaml
  securityContext:
    runAsUser: 1000
    runAsGroup: 2000
    allowPrivilegeEscalation: false
    privileged: false
    readOnlyRootFilesystem: true
    capabilities:
      drop:
      - all
  ```
  * New: Now possible to change Bake internal defaults via environment
    variables. More of these will be exposed in upcomming releases
  * Fixed: Docker Hub push URL should just be the username

# 0.6-beta

* New: Containers and their tags are now listed on GitHub releases
* New: Helm charts are now linted and packaged

# 0.5-beta

* New: Now possible to set target platforms via --target-platform argument,
  which has the default win/x64, linux/x64 and osx/x64
* New: Bake now builds MkDocs built projects into ZIP files and releases
  them as part of the release process
* Fixed: Windows tool ZIP files now excludes the ".exe" in the filename
* Fixed: GitHub Enterprise usage should be detected in most cases now
* Fixed: Made sure that composers are do in an order that statisfies their
  needs

# 0.4-beta

* New: Run .NET in an Alpine Linux image instead of a full blow Ubuntu
* New: Provide descriptions of what each sub-command actually does
* Fixed: Not specifying a version should merely default to 1.0 instead
  of throwing an exception
* Fixed: Release files containing Bake should be named `bake` instead
  of `Bake`
* Fixed: Now correctly naming the ZIP filename of the release artifacts
  on GitHub releases

# 0.3-beta

* New: ZIP release artifacts before uploading them to GitHub releases
* Fixed: Release artifacts to GitHub releases are now correctly named
  after their release artifacts
* Fixed: .NET released DLLs/EXEs are now correctly stamped with version
* Fixed: Bake now correctly prints the help message if no sub-command
  is given instead of merely doing nothing

# 0.2-beta

* New: Build, test and create containers for either .NET or Go
* New: Supported destinations for artifacts
  * Docker Hub
  * GitHub Packages (NuGet and container)
  * GitHub Releases (tools)

# 0.1-alpha

- Basic functionality

repository: rasmus/Bake

branch_name: refs/heads/develop

gha_language: C#

repo_name: rasmus/Bake


text:
Unreleased Changes
------------------

1.2.0 (2023-04-17)
------------------

* Feature - This release includes a new configurable value, TrafficPercentageToMonitor, which allows users to adjust the amount of traffic monitored by percentage

1.1.0 (2023-03-31)
------------------

* Feature - This release adds a new feature for Amazon CloudWatch Internet Monitor that enables customers to deliver internet measurements to Amazon S3 buckets as well as CloudWatch Logs.

1.0.0 (2023-02-27)
------------------

* Feature - Initial release of `aws-sdk-internetmonitor`.

repository: runongirlrunon/aws-sdk-ruby

repo_name: runongirlrunon/aws-sdk-ruby


text:
haxgar, `#>`, %hxgr
============================

Prettyprint `++tank`

`#>`, `haxgar`, `[%hxgr p=tusk]`is a synthetic rune that slams the
assumed gate `cain` on `[%zpgr %cntr p]`.

`#>` is a synthetic rune that slams the gate [`++cain`]() with `p`. `#>`
is used to produce a [`++tank`]() of the computation passed to it, and
is only used in the irregular form.

Produces
--------

Twig: `[%hxgr p=tusk]`

Sample
------

`p` is a [++tusk]().

Tall form
---------

None

Wide form
---------

None

Irregular form
--------------

    >i.p i.t.p i.t.t.p<

Examples
--------

    ~zod/try=/zop> >1<
    [%leaf p="1"]

This is the simplest example of `#>`, pass it a constant and it produces
a `++tank` of the constant.

    ~zod/try=/zop> >`path`"abc"<
    [%rose p=[p="/" q="/" r=""] q=~[[%leaf p="a"] [%leaf p="b"] [%leaf p="c"]]]
    ~zod/try=/zop> >0x5 ~zod 'a'<
    [ %rose
      p=[p=" " q="[" r="]"]
      q=~[[%leaf p="0x5"] [%leaf p="~zod"] [%leaf p="'a'"]]
    ]
    ~zod/try=/zop> >|.(1)<
    [ %rose
      p=[p=" " q="<" r=">"]
        q
      ~[
        [%leaf p="1.gcq"]
        [ %rose
          p=[p=" " q="[" r="]"]
            q
          ~[
            [%leaf p="@n"]
            [ %rose
              p=[p=" " q="<" r=">"]
                q
              ~[
                [%leaf p="250.xnq"]
                [%leaf p="41.vrk"]
                [%leaf p="418.ssa"]
                [%leaf p="101.jzo"]
                [%leaf p="1.ypj"]
                [%leaf p="%164"]
              ]
            ]
          ]
        ]
      ]
    ]

In these cases we use `#>` to produce the result of a simple computation
as a `++tank`.

repository: frodwith/urbit

repo_name: frodwith/urbit


text:
## Problem Description

Given a Number `n` implement Recursion to create a Countdown Timer.

## Test-Cases

```
// It should return [10, 9, 8, 7, 6, 5, 4, 3, 2, 1]
console.log(countdown(10));

// It should return [5, 4, 3, 2, 1]
console.log(countdown(5));
```

The Test-Cases are failing. Find the Bug in the Code Logic and resolve them.

## Difficulty Level

<b>Easy</b>

## Bug Type

Logical Error.


text:
---
layout: post
author: Ian
title: You Have a Heart of Gold
---
For the 10th anniversary of *Demon's Souls*, here's my heretical take
on enjoying this game: forget the lore.

    Demon's Souls promotional artwork.

    credit: Sony Interactive Entertainment

A quality of the *Souls* series that is often praised is its old-school
sensibilities. Usually this is meant to refer to its difficulty; in contrast to
the game design philosophy of its contemporaries, (remember the big arrow in
*BioShock* that told you where to go at all times?) *Demon's Souls* seemed
indifferent about whether or not the player should be able to finish the game.
Along with the static positioning of enemies, this drew comparisons (at least
from me) to *Castlevania* and other brutally hard NES era titles. But, I think
this characterization is missing something that was a big part of the way I
received games of that era -- something that informed the way I would play
*Demon's Souls*, which would lead to it becoming a personal favorite of mine.

On a recent episode[^1] of the gaming podcast *Retronauts*, guest Gary
Butterfield offered his idea of a "40-70-90" rule for game worldbuilding: to
explain only 40% of the story leads the player to make unsupported conjecture,
to explain 90% (or even 100%) of the story is no fun, and 70% is a narrative
Goldilocks Zone that leaves just enough mystery to be tantilizing. Generally,
people seem to agree with this idea. There's an abundance of wiki pages and
YouTube explainers piecing together the games' lore from item flavortext and
NPC dialogue. The elusiveness of a more explicit story is one of the qualities
of the series that makes it so enduringly popular.

Despite that, I disagree with Gary's thesis. Not because I think there's a
right way to receive these games -- there isn't -- but because I'm so naturally
able to play them in the same way that I played games on the NES. I'm not sure
if my specific appreciation for the games is unique, but I do think that it's
worth offering as an option.

The NES was my first gaming console, but I didn't receive one until 1995 -- a
full decade after its release, a generation behind, and just a year shy of the
N64's debut. This meant that games were acquired secondhand, usually from yard
sales, and always without an instruction manual. Coupled with me being 5 years
old and having no knowledge of Nintendo Power (let alone access to back
issues), most of the games I spent my childhood playing existed in a context
vacuum. By necessity, I used a lot of imagination to add that missing context
to my games, and eventually I had built up a small personal mythos for many of
them: what the world was all about, who the characters and enemies were, and
how they fit into what (I thought) was going on.

When you're a kid, you have no realistic intuition for the hardware limitations
games are up against, especially those of the 8-bit era.  When *Pokémon*
became a hit in the late 90s, my friends and I trawled through countless
Maxpages sites for secrets and cheat codes, often swallowing the most
outlandish claims as truth. It was always something like, talk to this NPC a
hundred times, and he'll eventually get bored and give you [some made up item]!
There was no short supply of rumors and other kids at school claiming to have
access to secret or forbidden knowledge. This isn't uniquely a quality of older
games, but it's one that I associate with them because I was the right age for
it when I was playing them.

When I got my hands on *Demon's Souls* in 2009, I discovered that the game was
extremely obtuse with its storytelling. Other than an initial cutscene to set
the stage, you really only had the level design and the cryptic, unreliable
musings from the NPCs you would sometimes meet. As I dug my teeth into the
game, I also realized that there actually *were* very well-hidden secrets, some
of which might be discovered accidentally, while others required reading a wiki
or a walkthrough to properly activate. You could play through the game several
times and never meet certain NPCs, discover certain areas of a level, or divine
the purpose of a curious item. The crowning example of this is the Tendency
system, wherein the game's content may change in very specific ways without
ever notifying the player.  A locked door may suddenly unlock because of a
change in character or world tendency, new enemies may appear in places where
there were previously none, or a ladder might materialize and lead the player
to a previously unknown room. To further complicate things, as well as add
another layer of mystery, the game servers would slightly shift the values for
this stat with each new day, making it extremely unpredictable and hard to
manipulate. This was the kind of game those Geocities myth-makers described, in
a way.

So, that's what makes *Demon's Souls* a spiritually old-school game, or at
least for me it does. I wish these qualities had been embraced in the popular
discussion about the game, but they're admittedly more nebulous than the more
obvious triumps of level design, mechanics, multiplayer, et cetera. But, if
anyone has read this and *not* yet played one of these games, I implore you:
forget the lore, and embrace the mystery.

[^1]: Retronauts Episode 246: Demon's Souls

gha_language: CSS


text:
# library-frontend
Library app frontend in React. implemented for CRUD Pattern Blog Post demonstration.

Follow below steps to get started:

1. `yarn install` to install dependencies mentioned in package.json
2. `yarn start` to start the server and run the app
3. `yarn build` to build the app for production in `build` folder

repository: hyphenOs/library-frontend

gha_language: JavaScript

repo_name: hyphenOs/library-frontend


text:
# Etherpad deployment demo

#### Table of Contents

1. [Overview](#overview)
2. [Requirements](#requirements)
    * [Software](#software)
    * [Cloud environment](#cloud-environment)
    * [Virtual machine images](#virtual-machine-images)
3. [Usage](#usage)
4. [Technical details](#technical-details)
    * [Tricks used](#tricks-used)
    * [Caveats](#caveats)
5. [Contributors](#contributors)

## Overview

This repository contains Ansible playbooks for deploying Etherpad with a Galera
backend using Heat and Docker. This is mainly meant to be an example on how to
use these tools together, but you could also potentially use this to deploy an
Etherpad application on OpenStack.

**If you are going to use the code here as an example, please read the "Caveats"
chapter below.**

## Requirements

### Software

* Ansible >= 2.2
* shade >= 1.8.0

For instructions on how to install Ansible, see [the official
documentation](https://docs.ansible.com/).

Shade is a client library used by Ansible to communicate with OpenStack clouds.
The easiest way to install it is using pip:

```bash
$ pip install shade
```

### Cloud environment

You will also need access to an OpenStack cloud. The project you use for
deployment needs to have a network and a router in place. If floating IPs are
available for your project then this should already be the case.

The OpenStack installation needs to have at least Heat and Neutron in addition
to Nova. The version of the Heat template used here is for Liberty. If you want
to run against an older version of OpenStack, you will need to modify the
template version. It is not guaranteed that the template will work against
older versions of OpenStack. Contact your OpenStack operator's support if you
are unsure whether the cloud fulfills these requirements.

Make sure the project you use for the stack has sufficient quota. You will need
sufficient quota for these additional resources on top of whatever you already
have running in the project:

  * Four virtual machines (the exact quota requirement depends on the flavors)
  * One floating IP
  * Two security groups and the handful of rules in those security groups

### Virtual machine images

The database backend deployment has been tested to work with CentOS 7 and
Ubuntu 16.04 images.

The Etherpad frontend has been tested to work with Ubuntu 16.04. It should also
work on CentOS 7, but due to a bug in the node.js role it does not work with
that operating system at the time of this writing.

## Usage

First you'll need to clone this repository to a directory on your machine. We
will refer to the root of the cloned repository with `etherpad-deployment-demo`
later in this text.

Install the third party Ansible roles used:

```bash
$ ansible-galaxy install -r requirements.yml
```

You will need to get an openrc file from OpenStack so that Ansible can interact
with it. The easiest way to get it is to login to the web interface and go to
Compute -> Access & Security -> API Access -> Download OpenStack RC File. Once
you have the file, you will need to source it (the name of the file may be
different):

```bash
$ source openrc.sh
```

After that you can fill in the parameters for the Heat stack. First copy the
example Heat parameter file to your current working directory:

```bash
$ cd etherpad-deployment-demo
$ cp files/example-heat-params.yml playbooks/my-heat-params.yml
```

Edit the file with your favorite editor and fill in all the variables. You can
find documentation about the variables in the Heat template under
`files/etherpad-heat-stack.yml`.

Once you have completed the steps above, you are ready to spin up the stack in
OpenStack. You will need to specify the name of the network you filled in in
your Heat parameters:

```bash
$ ansible-playbook site.yml \
  -e "etherpad_network_name=<the openstack network shared by instances>"
```

The default user account name used to log in to virtual machines is
"cloud-user". If the images you are using have a different default user account
name, then you will need to also set the `vm_user_account` variable.

You can find out the public IP address of the application after the playbook
run has finished by looking at the automatically generated `etherpad_inventory`
file. The public IP is the value of `ansible_ssh_host` for `etherpad_node`:

```bash
$ cat etherpad_inventory
```

Once the playbook run finishes, you can access the deployed application by
pointing your browser to its public IP address.

## Technical details

The playbooks here will spin up the following stack:

![Etherpad architecture](images/etherpad-demo-architecture.png)

The setup of Etherpad is split into stages that are implemented as separate
playbooks. You can find these playbooks under the `playbooks/` directory. These
are all gathered together in the correct order in `site.yml`. The stages are as
follows:

1. Start Heat stack
2. Configure database cluster
3. Configure HAproxy and Etherpad

You can follow the flow of execution by starting from `site.yml` and reading the
included playbooks in the order listed.

### Tricks used

**Start a Heat stack and create an Ansible inventory dynamically out of its
outputs.**

In the `outputs` section of the Heat template, you'll find an example on how to
get data out from Heat after its done with its deployment. This output is
placed into an Ansible variable using the `register` keyword. The variable is
then used to dynamically add the freshly created hosts to Ansible's inventory.
The `add_host` module is used for this. An inventory file is also generated
(`etherpad_inventory`), though this is not used during the Ansible run. It can
be used once the stack is running for troubleshooting purposes.

**Connection to hosts with no public IP through a bastion host.**

The virtual machine used to host Etherpad is also used as a bastion host to
connect to the database backend. This is achieved by using the ProxyCommand
feature of SSH. The ProxyCommand option is filled in using
`ansible_ssh_common_args` set in the context of the database cluster nodes (see
`group_vars/`).

**Automatic generation of passwords.**

The database passwords required are generated automatically using Ansible's
`lookup` function. This function generates a password and puts it in a file
under `playbooks/credentials`. If the file is already in place, the password in
it will be used instead. You can see this in the database configuration
playbook.

### Caveats

Some shortcuts were taken to finish these playbooks in time for a live demo, so
if you want to use this repo as an example you should be aware of the following
caveats. First of all a caveat about this list: it is almost certainly not
complete, and there are other things that could be done better as there always
are. As a general principle, you should not copy implementation details from an
example without understanding the implications.

**Bad Docker image and container management.**

There is an actual set of modules for managing Docker images and containers.
These are not used here, but they should be. What is done here instead is
running Docker commands directly using `shell` or `command`. For documentation
on the proper way to do manage Docker from Ansible, see
[Ansible's
documentation](https://docs.ansible.com/ansible/list_of_cloud_modules.html#docker).

**Broken load balancing to the database cluster.**

The configuration for the load balancing to the database cluster in HAproxy
will be something like this:

```
listen galera_cluster
  bind <IP_ADDRESS>:3306
  mode tcp
  balance source
    server galera_node0 <IP_ADDRESS>:3306 check
    server galera_node1 <IP_ADDRESS>:3306 check
    server galera_node2 <IP_ADDRESS>:3306 check
```

Due to the way Galera works, **this will not work properly if one of the
backend nodes fails**. What is being done here is dead simple load balancing in
TCP mode.  However, there is no guarantee that a cluster member that has port
3306 open is able to serve requests. If you want to use HAproxy for load
balancing to a Galera cluster, you will need to configure a script in a
different port on the cluster nodes that will respond with the status of the
database node with an HTTP status. Something like this:

```
listen galera_cluster
  bind <IP_ADDRESS>:3306
  mode tcp
  balance roundrobin
  option httpchk
  server galera_node0 <IP_ADDRESS>:3306 check port 9200 inter 2000 rise 2 fall 5
  server galera_node1 <IP_ADDRESS>:3306 backup check port 9200 inter 2000 rise 2 fall 5
  server galera_node2 <IP_ADDRESS>:3306 backup check port 9200 inter 2000 rise 2 fall 5
```

Here there is a service in port 9200 that reports on the status of the cluster
node. Because the check uses HTTP, `option httpchk` is set. With these
playbooks, the service in port 9200 doesn't exist, so this configuration cannot
be copied without setting that up first. You should be able to find
documentation on how to do that by searching for keywords like e.g. "haproxy
galera cluster load balancing".

Another way to configure the load balancing is documented in [the Galera
cluster documentation on
HAproxy](http://galeracluster.com/documentation-webpages/haproxy.html).

**No affinity setting for the Galera cluster nodes.**

If you want to create a production database cluster in OpenStack, you need to
ensure that all virtual machines end up on different physical servers. This is
possible in OpenStack by using server groups and setting the affinity policy
for the server group to anti-affinity. This can be done in Heat by using the
`OS::Nova::ServerGroup` resource. This is not currently done by this deployment
example.

## Contributors

  * Risto Laurikainen - https://github.com/rlaurika

repository: CSCfi/etherpad-deployment-demo

gha_language: Shell

repo_name: CSCfi/etherpad-deployment-demo


text:
# [Random Number](http://alexa.amazon.com/#skills/amzn1.echo-sdk-ams.app.318f7156-90e8-44c6-bd06-064a79848db9)
![2.3 stars](../../images/ic_star_black_18dp_1x.png)![2.3 stars](../../images/ic_star_black_18dp_1x.png)![2.3 stars](../../images/ic_star_half_black_18dp_1x.png)![2.3 stars](../../images/ic_star_border_black_18dp_1x.png)![2.3 stars](../../images/ic_star_border_black_18dp_1x.png) 6

To use the Random Number skill, try saying...

* *Alexa ask Random Number for a number*

* *Alexa ask Random Number for the next number*

* *Alexa open Random Number*

A simple skill, Alexa will give you a random number between 1 and 100. Useful for settling the sibling squabble about who gets the last slice of cake.

***

### Skill Details

* **Invocation Name:** random number
* **Category:** null
* **ID:** amzn1.echo-sdk-ams.app.318f7156-90e8-44c6-bd06-064a79848db9
* **ASIN:** B01AB0IK96
* **Author:** Michael James
* **Release Date:** January 7, 2016 @ 15:22:30
* **Privacy Policy:** http://www.amazon.com/gp/help/customer/display.html?nodeId=468496
* **Terms of Use:** http://www.amazon.com/gp/help/customer/display.html?nodeId=468496
* **In-App Purchasing:** No


text:
# Pbb is now pretty

`pbb` is now producing something that's not quite as much saying "90s HTML" any
longer. I took some inspiration from the "satire" (debatable) websites that
started with the [mothereffing website][1][^1]. I'd say the original `pbb`
output was very close to that (i.e., no styling at all), but thanks to sane
pandoc defaults, it didn't even look all that bad, also on mobile devices. Only
the super long lines weren't all that great on bigger displays.

![Unstyled `pbb` output](images/2020-02-16-pbb-old.png)

[1]: https://motherfuckingwebsite.com
[^1]: Got to keep the SEO juice for these terms reasonably low.

As it turns out, the m-effing website inspired a whole slew of improvements,
each more assertive than the other: [better][2], [even better][3], [best][4],
[*the* best][5], [perfect][6], and (unoriginally) [another *the* best][7] one.

[2]: http://bettermotherfuckingwebsite.com
[3]: https://evenbettermotherfucking.website
[4]: https://bestmotherfucking.website
[5]: https://thebestmotherfucking.website
[6]: https://perfectmotherfuckingwebsite.com
[7]: https://thebestmotherfuckingwebsite.co

There's even one of these "awesome" lists [on GitHub][8], and from there, I
found a [paper][9] about the original one. Academic and all.

[8]: https://github.com/lyoshenka/awesome-motherfucking-website
[9]: https://link.springer.com/chapter/10.1007/978-3-319-08245-5_44

The different improvements revolve mostly around styling, security,
accessibility and the like, but the overall idea stays the same. I took the
styling of the first better one and tweaked it a tiny little bit:

```css
body {
    color: #333;
    font-size: 18px;
    line-height: 1.6;
    margin: 40px auto;
    max-width: 650px;
    padding: 0 10px;
}

h1, h2, h3 {
    line-height:1.2;
}

img {
    max-width: 100%;
}
```

I didnt know that there's a whole [war][10] out there regarding contrast and if
it is bad or not. I settled on the same dark grey as the New York Times uses.
They probably know how to do this.

[10]: https://contrastrebellion.com

The other change I did was for images, to prevent that they'd be wider than the
text column.

All in all, the result looks like this (on the date this post was written):

![First iteration using CSS](images/2020-02-16-pbb-new.png)

I'll look into a nicer font and different styling for links, but other than
that, I feel like that's a pretty good ROI. Well, the font in code blocks feels
a bit large now. Still. Good ROI.


text:
# Protopy

A library and CLI for rendering directory trees.

It is composed of two projects:

- A command-line utility that creates scaffolding for files and projects from templates.
- A library that allows for embedding into other applications with minimal dependencies

## How to install

- To install the CLI use:
```console
pip install protopy-cli
```

- To install the library use:
```console
pip install protopy-lib
```

## How does it work

A protopy template is a directory which contains at least a `proto.py` file. Inside this directory, we create the
directory tree to be copied into the generated path. Protopy uses [jinja](https://jinja.palletsprojects.com/en/3.0.x/)
to render its templates, the rendering happens both on the file/dir names and inside any file that ends with `.tmpl`.

## Example

The following is the directory structure of a template we will use as our example.

```
our-template/
├── {{project_name}}
│   ├── {{readme_file_name}}
│   ├── src
│   │   └── main.py
│   └── {{tests_dir}}
└── proto.py
```

Note that we have a directory named `{{project_name}}` and a file named `{{readme_file_name}}` (yes, the file and
directory names include the double-curly-braces, just as you see them here), This means that this template
expects `proto.py` to define at least those variables.

Here is an example content for `proto.py`:

```python
# this is the main template logic.
# after the execution of this file, the module variables will be visible to the renderer of the directory tree to be copied into the generated path.

# you can ask the user for input like the following, which results in the prompt:  "> Project Name:"
# the 'project_name' also represents the name of a commandline variable, we will see more about it down this example
project_name = ask('project_name')

# you can also set default and explicit prompt
author = ask('author', prompt='Who are you?', default="no one")

# you can restrict input to a set of choices
readme_type = ask('readme_type', prompt='What Type of README file would you like?', default=0,
                  choices=["Markdown", "reStructuredText"])

# you can create module variables like any python module - you don't have to ask for them..
if readme_type == "Markdown":
    readme_file_name = "README.md.tmpl"
else:
    readme_file_name = "README.rst.tmpl"

# you can ask for yes/no confirmation like this:
tests_dir = ""
if confirm("use_tests", prompt="Would you like a tests directory?"):
    tests_dir = "tests"

# when calling from the commandline the user can supply named args and positional args,
# in the example below, if the user executed protopy with either the commands:
# > protopy <your template name> "My Protopy-Generated Project"
# > protopy <your template name> description="My Protopy-Generated Project"
# then the user will not get any prompt and the value "My Protopy-Generated Project" will be returned
description = ask('description', positional_arg=0)

# you can print additional information to the user using the say command, it supports terminal formatting (read the doc for more info):
say("<info>Done configuring and start generating!</info>")

# finally you can optionally define a post generation hook
def post_generation():
    say("<info>Done generating!</info>")

# Check out the docs for more information..
```

Notice the file named `{{readme_file_name}}` in the directory structure, this file gets its value inside `proto.py`. It has
2 possible values `README.md.tmpl` and `README.rst.tmpl`, since the file extension is `tmpl` its content will be
rendered using `jinja`.

Here is an example content of the `{{readme_file_name}}` file:

```markdown
# {{project_name}}

> Created By {{author}}

{{description}}
```

Next, we can see that there is a directory named `{{tests_dir}}` in our template, by examining the `proto.py` file we
can see that the `tests_dir` variable can be empty, this will result in a file/directory without a name in the rendering
phase which will cause the file/dir to not be rendered (in other words the `{{tests_dir}}` directory may not exist).

Finally we can generate a project based on this template via:

```console
> protopy generate our-template output-dir project_name="example"
Who are you? [no one] > John
What Type of README file would you like? [Markdown]:
 [0] Markdown
 [1] reStructuredText
 >
Would you like a tests directory? (yes/no) [yes] no
Description > our example description
Done configuring and start generating!
Done generating!
```

Notice that the user was not asked about the Project name as we supplied it in the commandline. The resulted content
of `output-dir` is:

```
.
└── example
    ├── README.md
    └── src
        └── main.py
```

and the content of README.md is:

```markdown
# example

> Created By John

our example description
```

## CLI Commands

Protopy supports the following commands:

### New

```
Description:
  create a new template (and populate it with some example content)

Usage:
  protopy new [<out_dir>]

Arguments:
  out_dir   directory to create the template in, defaults to the current directory

```

### Generate

```
Description:
  generate directory tree based on a given template

Usage:
  protopy generate <template> <output_path> [<template_args>...]

Arguments:
  template              the template to use (supports path, git, zip and url to zip)
  output_path           where to put the generated content
  template_args         template arguments, can be positional and key=value

Options:
  -o, --overwrite       allows the generated content to overwrite existing files

```

The `generate` command support generating templates from different sources:

- Local directory: `protopy generate /path/to/dir ...`
- Local zip file: `protopy generate /path/to/zip/file.zip ...`
- Remote zip file: `protopy generate https://url-to-zip-file.zip ...`
- Git repository: `protopy generate git+https://github.com/...`

### Manual _(man)_

```
Description:
  print information about a template

Usage:
  protopy man [options] [--] <template>

Arguments:
  template              the template to examine (supports path, git, zip, url to zip)

```

## The `proto.py` file

The `proto.py` file executes before the directory tree generation starts. Any (module level) variable that is defined
in `proto.py` will then be available to the `jinja` templates in the generation process. After the generation completes,
if `proto.py` defined a module level `post_generation` function it will be called.

During its execution, `proto.py` has several special methods that are supplied to it by protopy:

```python

def ask(self, named_arg: str, *, prompt: str = None, default: Any = "", choices: Optional[List[str]] = None,
        autocomplete: Optional[List[str]] = None, secret: bool = False, positional_arg: int = -1,
        doc: str = ""):

    """
    ask the user for information (either retrieving it from the command line or from the user supplied arguments)
    :param named_arg: the name of the argument that may contain the value for this function to return
    :param prompt: (optional - defaults to a string generated from named_arg) the prompt to show to the user
    :param default: (optional - defaults to None) the default value to suggest the user
    :param choices: (optional - defaults to None) list of choices to restrict the user input to
    :param autocomplete: (optional - defaults to None) list of autocomplete suggestions to help the user with
    :param secret: (optional - defaults to False) set to True to hide the user input
    :param positional_arg:  (optional - defaults to -1) the index of the positional argument that may contain the
                            value for this function to return
    :param doc: documentation to show in the commandline (must be a string literal)

    :return: the requested user input
    """

def confirm(
        self, named_arg: str, *, prompt: str, doc: str = "", default: bool = True, positional_arg: int = -1) -> bool:

    """
    ask the user for yes/no confirmation (either retrieving it from the command line or from the user supplied arguments)
    :param named_arg: the name of the argument that may contain the value for this function to return (supports the values y,yes,n,no)
    :param prompt: (optional - defaults to a string generated from named_arg) the prompt to show to the user
    :param default: (optional - defaults to True = 'yes') the default value to suggest the user
    :param positional_arg: (optional - defaults to -1) the index of the positional argument that may contain the
                            value for this function to return
    :param doc: documentation to show in the commandline (must be a string literal)
    :return: True if the user confirmed or False otherwise
    """

def arg(self, named_arg: str, *, doc: str = "", default: str = "", positional_arg=-1):
    """
    fetch a value from the commandline arguments, without asking the user for it if not provided
    :param named_arg: the name of the argument that may contain the value for this function to return (supports the values y,yes,n,no)
    :param doc: documentation to show in the commandline (must be a string literal)
    :param default: (optional - defaults to None) the default value to suggest the user
    :param positional_arg:  (optional - defaults to -1) the index of the positional argument that may contain the
                            value for this function to return
    :return: the requested user value
    """

def say(msg: str):
    """
    display a message to the user
    :param msg: the message to display
    """

```

Internally, Protopy uses [cleo](https://github.com/sdispater/cleo) for terminal IO, therefore all prompts support output
coloring. You can read about it [here](https://cleo.readthedocs.io/en/latest/introduction.html#coloring-the-output), but
here is the gist of it:

```python
# Use predefined colors.
say('<info>hi there</info>')
say('<comment>hi there</comment>')
say('<question>hi there</question>')
say('<error>hi there</error>')

# Define your own colors.
# Available foreground and background colors are: black, red, green, yellow, blue, magenta, cyan and white.
# And available options are: bold, underscore, blink, reverse and conceal.
say('<fg=green>hi there</>')
say('<fg=black;bg=cyan>hi there</>')
say('<bg=yellow;options=bold>hi there</>')
```

## Advanced Templating

### Excluding files

Sometimes, your template may contain files that you want to exclude from the rendering process. You can use
a `.protopyignore` file for that (just add glob patterns to it similar to `.gitignore` file)

### Copying content without templating

Sometimes, your template may contain directories that you want to copy as is (without passing through the template engine).
To do so, all you need to do is to include a `.protopypreserve` file inside the directory that you want to preserve as is.

### Dynamic file positioning

When generating file/dir names, you can give the file a name that includes a relative path and the file will be
relocated into this path during the generation process.

For example, For a template structure:

```
dynamic-template/
├── {{dynamically_positioned_file}}
└── proto.py
```

And a proto.py file:

```python
# proto.py
dynamically_positioned_file = "some/nested/directory/file.txt"
```

running the command

```console
> protopy generate dynamic-template out-dir
```

will result with the directory structure:

```
out-dir/
└── some
    └── nested
        └── directory
            └── file.txt
```

## The Protopy library (`protopy-lib`)

The Protopy library (protopy_lib) includes the Protopy engine itself without the commandline and support for multiple
template sources. It has minimal set of dependencies and is intended for embedding inside other applications.

it exposes the following class:

```python

class ProtopyEngine:
    def render_doc(self, template_dir: Union[Path, str], template_descriptor: Optional[str] = None,
                   command_prefix: str = "protopy") -> str:
        """
        :param the directory holding the template
        :param template_descriptor: the descriptor that used to resolve the template directory, if not provided,
                                    the template directory will be considered as the descriptor
        :param command_prefix: the prefix of the commandline that should be used to generate this template
        :return: a generated documentation for this template
        """

    def render(self, template_dir: Union[Path, str], target_dir: Union[Path, str],
               args: List[str], kwargs: Dict[str, str], extra_conte~~~~xt: Dict[str, Any], *,
               excluded_files: Optional[List[Path]] = None, allow_overwrite: bool = False):
        """
        renders the given template into the target directory

        :param template_dir: the directory holding the template
        :param target_dir: the directory to output the generated content into
        :param args: positional arguments for the template
        :param kwargs: named arguments for the template
        :param extra_context: extra variables that will be available inside proto.py
        :param excluded_files:  list of path objects that represents files in the template directory that should be
                                excluded from the generation process
        :param allow_overwrite: if True, files that are already exists will be overridden by the template
        """

```

## Comparison to other tools

Protopy is very similar in concept to [cookiecutter](https://github.com/cookiecutter/cookiecutter)
and [copier](https://github.com/copier-org/copier/) but has the following differences:

- No configuration, instead a regular python code is being used.
- Composed of two parts - library and cli to support embedding without unneeded dependencies
- Does not directly support template updates
- Allows for dynamic file positioning, as it intended to be used both for generating projects and also scaffolding
  software components

## How to build this project
This project is built using [relaxed-poetry](https://github.com/bennylut/relaxed-poetry)

repository: bennylut/protopy

repo_name: bennylut/protopy


text:
# Dynamic Attentive Graph Learning for Image Restoration

```
@inproceedings{dagl_iccv21,
title = {Dynamic Attentive Graph Learning for Image Restoration},
author = {Chong Mou and Jian Zhang and Zhuoyuan Wu},
booktitle = {The IEEE International Conference on Computer Vision (ICCV)},
year = {2021}
}
```

links
- [arXiv](https://arxiv.org/abs/2109.06620)
- [code](https://github.com/jianzhangcs/DAGL)


text:
---
icon: creativefill
---

# Using Vssue

## Choose a platform to use

Vssue can enable comments for your static pages via the `Issue System` of `Github`, `Gitlab`, `Bitbucket` or `Gitee`, and you can choose one of those platforms.

Go to [Supported Platforms - Set up OAuth App](./supported-platforms.md) for detailed instructions.

After this step, you will get `client id` and `client secret` of your OAuth App, which will be used for Vssue options:

- `owner`: the account / group that owns the repository
- `repo`: the name of the repository to store comments
- `clientId`: the `client id` of your oauth app
- `clientSecret`: the `client secret` of your oauth app (only required for some of the platforms)

## Vssue Config

This plugin uses [@vssue/vuepress-plugin-vssue](https://www.npmjs.com/package/@vssue/vuepress-plugin-vssue) to help use Vssue in VuePress quickly.

### Use the plugin

```js
// .vuepress/config.js

module.exports = {
  plugins: {
    "@mr-hope/comment": {
      type: "vssue",
      // set `platform` rather than `api`
      platform: "github",

      // all other options of Vssue are allowed
      owner: "OWNER_OF_REPO",
      repo: "NAME_OF_REPO",
      clientId: "YOUR_CLIENT_ID",
      clientSecret: "YOUR_CLIENT_SECRET",
    },
  },
};
```

::: tip
The only difference is that, you should set `platform` rather than the `api` package itself.

`@vssue/vuepress-plugin-vssue` will auto resolve the corresponding api package according to the value of `platform`:

- platform `github` - api package `@vssue/api-github-v3`
- platform `github-v4` - api package `@vssue/api-github-v4`
- platform `gitlab` - api package `@vssue/api-gitlab-v4`
- platform `bitbucket` - api package `@vssue/api-bitbucket-v2`
- platform `gitee` - api package `@vssue/api-gitee-v5`

:::

### Use Vssue Component

`Vssue` has already been registered as a Vue component, and can be used in your VuePress markdown directly.

```md
<!-- README.md -->

# Vssue Demo

<Vssue title="Vssue Demo" />
```

::: tip
You can go to the repo [meteorlxy/vssue-demo](https://github.com/meteorlxy/vssue-demo) to get the demo code.
:::

## Custom Style Variables

With the power of [palette.styl](https://vuepress.vuejs.org/config/#palette-styl) of VuePress, you can set the [Variables of Vssue Style](./styles.md#use-variables-to-customize-vssue) easily.

There are some pre-defined [stylus variables](http://stylus-lang.com/docs/variables.html) of Vssue, and you can check them in `vssue/src/styles/_variables.styl`:

```stylus
// the main color
$vssue-theme-color

// the text color (used for common text)
$vssue-text-color

// the text light color (used for muted text, disabled text, etc)
$vssue-text-light-color

// the border color
$vssue-border-color

// the progress color
$vssue-progress-color

// the font size
$vssue-font-size

// the font family
$vssue-font-family

// the mobile breakpoint
$vssue-breakpoint-mobile

// the text direction (ltr / rtl) (used for RTL languages, e.g. Hebrew)
$vssue-direction
```

For example, Vssue use a "Vue green" (`#3eaf7c`) as the theme color, which is defined as the default value of variable `$vssue-theme-color`. You can change the theme color by setting `$vssue-theme-color` before import `vssue/src/styles/index.styl`.

By default, those Vssue variables are set to VuePress variables:

```stylus
// @vssue/vuepress-plugin-vssue/styles/index.styl

$vssue-theme-color ?= $accentColor
$vssue-text-color ?= $textColor
$vssue-border-color ?= $borderColor
$vssue-breakpoint-mobile ?= $MQMobile
```

If you want to override them, just set them in your `palette.styl`:

```stylus
// .vuepress/styles/palette.styl

$vssue-theme-color = red
```

## Do not want to use our plugin

Vssue has tried to be SSR-friendly, so you can import Vssue directly in VuePress like other vue plugins / components without `@vssue/vuepress-plugin-vssue` (especially if you have customized the styles of Vssue).

But we still suggest you to use `@vssue/vuepress-plugin-vssue` in VuePress, which has already helped you make `<Vssue>` component client-only to avoid some potential issues.

If you do not want to use the plugin we provided, you may need to wrap `<Vssue>` component into `<ClientOnly>` component to avoid those potential issues, i.e. :

```vue
<ClientOnly>
  <Vssue />
</ClientOnly>
```

> See [Built-in Components - ClientOnly](https://vuepress.vuejs.org/guide/using-vue.html#clientonly) of VuePress

repository: recoluan/vuepress-theme-hope

gha_license_id: NOASSERTION

repo_name: recoluan/vuepress-theme-hope


text:
Hi there! I decided to make my daily code experiments public. It can be either testing a new famework, a new JavaScript feature or just challenging myself with algorithms.

⚠ **Disclaimer:** ⚠

_Code may not always be clean or readable. Some things may not even work!_
_But that's what **experimenting** is all about right ? :)_

# Experiments

### 1 – [Re-doing the Just library](https://github.com/dcamilleri/experiments/tree/master/1-redoing-just)
### 2 – [Model Validator](https://github.com/dcamilleri/experiments/tree/master/2-model-validator)
### 3 – [Object Flatten](https://github.com/dcamilleri/experiments/tree/master/3-object-flatten)
### 4 – [Flat Object Class](https://github.com/dcamilleri/experiments/tree/master/4-flat-object)
### 5 – [Small Immutable Library](https://github.com/dcamilleri/experiments/tree/master/5-immutable-lib)
### 6 – [Experimenting Jest Snapshots](https://github.com/dcamilleri/experiments/tree/master/6-jest-snapshot)

# Ideas 💡

### Learn new languages

**What I want to do:**
Create a simple web app (server-side rendered), or just an API, using multiple languages.

**Languages I would like to be better at:**
- ➡  Java
- ➡  Python
- ➡  Go
- ➡  PHP

**Languages I would like to discover:**
- ➡  Elm
- ➡  Elixir/Erlang
- ➡  OCaml

**Goals:**
Learn new things. Explore new/old programming principles. Open my mind to something else than JavaScript 🙌

### Implement snapshot testing for pure functions

**Question I want to solve:**
Can Jest snapshot testing be applied to pure functions ? Can it speed up our tests ?

**Goals:**
Play around with Jest and pure functions

### Create a small tool to benchmark multiple functions together and analyze their performance

**Question I want to solve:**
I have two implementations of the same algorithm. How can I know which one is faster ? Also, how can I easily benchmark 1000 iterations of these two algorithms ?

**Goals:**
Improve node.js + benchmarking + tests skills

### Experiment something with Proxies and Generators

### Implement something with Web Workers

**Question I want to solve:**
How do Web Workers fit in a real-world app ? What problems can they solve ?

**Goals:**
Use and understand the Web Worker API. Also, benchmark performance with and without WWs.

repository: dcamilleri/experiments

repo_name: dcamilleri/experiments


text:
**How To Query:**

All queries in NNA are URL constructions that hit the endpoint `/filter` or `/histogram`.

There are several ways to construct an NNA query.
The most basic type of queries follow the following format:
`/filter?set=<files|dirs>&filters=[filter:filterOp:value]&sum=<sum>`

Whereby `set` is refering to which set of INodes you wish to work with.
Either the set of all files, or set of all directories.

`filters` refers to all the different combinations of filters you can then apply to that set.
Note that some filters will not be accessible to you depending on which set you are working with.
For example, running with `&filters=fileSize:eq:0` will not work against the set of all directories as directories have no metadata regarding file size in HDFS.
You can chain filters together as well.

Depending on which filter you pick, you can then use a `filterOp` to describe the conditional you are looking for.
Some easy examples are `eq` being "is equal to", `gt` being "greater than", `gte` being "greater than or equal to", and then by extension, `lt` and `lte`.

`sum` will dictate what your final result represents.
Once your INode set has been filtered down to the set of INodes you care about, the `sum` operation will then reduce the filtered set to a final value.
For example, `&sum=count` will simply count the number of INodes in the filtered set.
Or, `&sum=diskspaceConsumed` will sum the file sizes times their replication factors of every file in a filtered set of file INodes.

If you do not include `&sum=<sum>` in your query then `/filter` will instead dump the list of paths that comprise the filtered set.

On your instance of NNA you can always go to `/sets`, `/filters`, `filterOps`, and `/sums` to see the different options available to you.

There is another more advanced query in the following format:
`/histogram?set=<files|dirs>&filters=[filter:filterOp:value]&type=<type>&sum=<sum>`

The `/histogram` query is nearly identical to the `/filter` query above but it carries an extra parameter, `&type`.
`type` in this case refers to the type of histogram and grouping you wish to achieve.

Take the following example histogram query: `/histogram?set=files&filters=fileSize:eq:0&type=user&sum=count`
This query will take the set of all files, filter down to only empty files, and group the result by their owner, and sum the groupings by their number of empty files.

You can check `/histograms` to see the different values you can use for `type`.
You can also assign a `&histogramOutput=<csv|json>` to get your histogram output as different formats.

repository: paypal/NNAnalytics

gha_language: Java

repo_name: paypal/NNAnalytics


text:
Digital control for Radio Experiment for the Analysis of Cosmic Hydrogen

https://www.astro.phy.cam.ac.uk/research/research-projects/reach/overview

VNA
RF switch
Arduino

Please install the following version of casperfpga
https://github.com/ianmalcolm/casperfpga/commit/575e7ab27b6bdbe9a0ada28fdc961be4562fafa8


text:
# Bender DNS Tutorial

This tutorial walks through the steps to create a simple DNS server with a load tester. If you
already know how to Go's DNS libraries, skip to the "Load Testing" section to get started with
Bender and DNS.

## Getting Started

You will need to install and configure Go by following the instructions on the
[Getting Started](https://golang.org/doc/install) page. Then follow the instructions on the
[How To Write Go Code](https://golang.org/doc/code.html) page, particularly for setting up your
workspace and the `GOPATH` environment variable, which we will use throughout this tutorial.

Next we need the DNS library for Go, which you can fetch using `go get` as:
```sh
cd $GOPATH
go get github.com/miekg/dns
```

Finally you will need the latest version of Bender, which you can get by running:

```sh
go get github.com/pinterest/bender
```

## Writing DNS Server

This section will walk through the creation of DNS client and server, which we will use to test
Bender in the following section. If you already have a DNS server you can use them instead.

In the following, all commands should be run from the `$GOROOT` directory, unless otherwise noted.

 We'll refer to this as `$PKG` in this document, and it
can be any path you want. At Facebook, for example, we use `github.com/facebook`.

```sh
cd $GOPATH
mkdir -p src/$PKG/hellodns
```

### DNS Server implementation

Now we will create a simple DNS server, that responds on `A` records with predefined addresses.
First create a new directory:

```sh
mkdir -p src/$PKG/hellodns/server
```

Then create a file named `main.go` in that directory and add the following lines:

```go
package main

import (
	"flag"
	"fmt"
	"log"

	"github.com/miekg/dns"
)

func handleRequest(w dns.ResponseWriter, r *dns.Msg) {
	m := new(dns.Msg)
	m.SetReply(r)
	for _, q := range m.Question {
		switch q.Qtype {
		// For any AAAA record answer with fd6c:1a5c:2b63::d8e9
		case dns.TypeAAAA:
			log.Printf("Query for \"%s\"", q.Name)
			rr, err := dns.NewRR(fmt.Sprintf("%s AAAA fd6c:1a5c:2b63::d8e9", q.Name))
			if err == nil {
				m.Answer = append(m.Answer, rr)
			}
		}
	}
	w.WriteMsg(m)
}

func main() {
	// Allow user to specify server port via flag
	var port int
	flag.IntVar(&port, "port", 5353, "server port")
	flag.Parse()

	// Attach handler function
	dns.HandleFunc(".", handleRequest)
	// Create and start the server
	server := &dns.Server{
		Addr: fmt.Sprintf(":%d", port),
		Net:  "udp",
	}
	err := server.ListenAndServe()
	if err != nil {
		log.Fatalf("Error: %s", err.Error())
	}
	defer server.Shutdown()
}
```

### Run the server

Run these commands to compile and install the server:

```sh
go install $PKG/hellodns/server
```

In one terminal window, run the server as `./bin/server` and in another terminal window run:

```sh
dig -p 5353 AAAA @localhost test.
```

The server should log receiving the query for `"test."` and client should print the answer similar
to this one:

```
; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> -p 5353 AAAA @localhost test.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48142
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;test.                          IN      AAAA

;; ANSWER SECTION:
test.                   3600    IN      AAAA    fd6c:1a5c:2b63::d8e9

;; Query time: 0 msec
;; SERVER: ::1#5353(::1)
;; WHEN: Tue Jul 17 02:44:41 PDT 2018
;; MSG SIZE  rcvd: 54
```

## Load Testing

Now that we have an DNS server we can use Bender to build a simple load tester for it. This section
uses the same directories and packages as the previous section, but it is easy to use the same
instructions for any DNS server. The next few sections walk through the various parts of the load
tester. If you are in a hurry skip to the section "Final Load Tester Program" and just follow the
instructions from there.

### Intervals

The first thing we need is a function to generate intervals (in nanoseconds) between executing
requests. The Bender library comes with some predefined intervals, including a uniform distribution
(always wait the same amount of time between each request) and an exponential distribution. In this
case we will use the exponential distribution, which means our server will experience load as
generated by a [Poisson process](http://en.wikipedia.org/wiki/Poisson_process), which is fairly
typical of server workloads on the Internet (with the usual caveats that every service is a special
snowflake, etc, etc). We get the interval function with this code:

```go
intervals := bender.ExponentialIntervalGenerator(qps)
```

Where `qps` is our desired throughput measured in queries per second. It is also the reciprocal of
the mean value of the exponential distribution used to generate the request arrival times (see the
wikipedia article above). In practice this means you will see an average QPS that fluctuates around
the target QPS (with less fluctuation as you increase the time interval over which you are
averaging).

### Request Generator

The second thing we need is a channel of requests to send to the DNS server. When an interval has
been generated and Bender is ready to send the request, it pulls the next request from this channel
and spawns a goroutine to send the request to the server. This function creates a simple synthetic
request generator:

```go
func SyntheticDNSRequests(n int) chan interface{} {
	c := make(chan interface{}, 100)
	go func() {
		for i := 0; i < n; i++ {
			msg := new(dns.Msg)
			msg.SetQuestion(dns.Fqdn(fmt.Sprintf("test%d", i)), dns.TypeAAAA)
			c <- msg
		}
		close(c)
	}()
	return c
}
```

### Request Executor

The next thing we need is a request executor, which takes the requests generated above and sends
them to the service. We will use a helper function from Bender's dns library to do most of the work
(connection management, error handling, etc), so all we have to do is write code to verify the
request:

```go
var responseIP = net.ParseIP("fd6c:1a5c:2b63::d8e9")

func validator(_, resp *dns.Msg) error {
	if len(resp.Answer) != 1 {
		return fmt.Errorf("response missing answer for query")
	}
	answer, ok := resp.Answer[0].(*dns.AAAA)
	if !ok {
		return fmt.Errorf("invalid answer type AAAA expected")
	}
	if !responseIP.Equal(answer.AAAA) {
		return fmt.Errorf("invalid address: %s, expected %s", answer.AAAA, responseIP)
	}
	return nil
}

exec := http.CreateExecutor(nil, validator, "localhost:5353")
```

This validates that the response has an answer with predefined address.

### Recorder

The last thing we need is a channel that will output events as the load tester runs. This will let
us listen to the load testers progress and record stats. We want this channel to be buffered so that
we can run somewhat independently of the load test without slowing it down:

```go
recorder := make(chan interface{}, 128)
```

The `LoadTestThroughput` function returns a channel on which it will send events for things like
the start of the load test, how long it waits between requests, how much overage it is currently
experiencing, and when requests start and end, how long they took and whether or not they had
errors. That raw event stream makes it possible to analyze the results of a load test. Bender has
a couple simple "recorders" that provide basic functionality for result analysis and all of which
use the `Record` function:

* `NewLoggingRecorder` creates a recorder that takes a `log.Logger` and outputs each event to it in
a well-defined format.
* `NewHistogramRecorder` creates a recorder that manages a histogram of latencies from requests and
error counts.

You can combine recorders using the `Record` function, so you can both log events and manage a
histogram using code like this:

```go
l := log.New(os.Stdout, "", log.LstdFlags)
h := hist.NewHistogram(60000, 10000000)
bender.Record(recorder, bender.NewLoggingRecorder(l), bender.NewHistogramRecorder(h))
```

The histogram takes two arguments: the number of buckets and a scaling factor for times. In this
case we are going to record times in milliseconds and allow 60,000 buckets for times up to one
minute. The scaling factor is 1,000,000 which converts from nanoseconds (the timer values) to
milliseconds.

It is relatively easy to build recorders, or to just process the events from the channel yourself,
see the Bender documentation for more details on what events can be sent, and what data they
contain.

### Final Load Tester Program

Create a directory for the load tester:

```
mkdir -p src/$PKG/hellobender
```

Then create a file named `main.go` in that directory and add these lines to it:

```go
package main

import (
	"fmt"
	"log"
	"net"
	"os"
	"time"

	bdns "facebender/protocols/dns"

	"github.com/miekg/dns"
	"github.com/pinterest/bender"
	"github.com/pinterest/bender/hist"
)

var responseIP = net.ParseIP("fd6c:1a5c:2b63::d8e9")

// SyntheticDNSRequests generates 100 dummy requests to the dns server
func SyntheticDNSRequests(n int) chan interface{} {
	c := make(chan interface{}, 100)
	go func() {
		for i := 0; i < n; i++ {
			msg := new(dns.Msg)
			msg.SetQuestion(dns.Fqdn(fmt.Sprintf("test%d", i)), dns.TypeAAAA)
			c <- msg
		}
		close(c)
	}()
	return c
}

func validator(_, resp *dns.Msg) error {
	if len(resp.Answer) != 1 {
		return fmt.Errorf("response missing answer for query")
	}
	answer, ok := resp.Answer[0].(*dns.AAAA)
	if !ok {
		return fmt.Errorf("invalid answer type AAAA expected")
	}
	if !responseIP.Equal(answer.AAAA) {
		return fmt.Errorf("invalid address: %s, expected %s", answer.AAAA, responseIP)
	}
	return nil
}

func main() {
	intervals := bender.ExponentialIntervalGenerator(10)
	requests := SyntheticDNSRequests(100)
	exec := bdns.CreateExecutor(nil, validator, "localhost:5353")
	recorder := make(chan interface{}, 100)

	bender.LoadTestThroughput(intervals, requests, exec, recorder)

	l := log.New(os.Stdout, "", log.LstdFlags)
	h := hist.NewHistogram(60000, int(time.Millisecond))
	bender.Record(recorder, bender.NewLoggingRecorder(l), bender.NewHistogramRecorder(h))
	fmt.Println(h)
}
```

### Run Server and Load Tester

Run these commands to compile and install the server and load tester:

```
go install $PKG/hellodns/server
go install $PKG/hellobender
```

In one terminal window, run the server as `./bin/server` and in another window run the load tester
as `./bin/hellobender`. You should see a long sequence of outputs in the server window and a final
print out of the histogram data in the other window.

repository: earlgreyz/bender

repo_name: earlgreyz/bender


text:
UPDATE: Recent versions of Docker Desktop comes with this functionality built into the UI. My script below still works, in case you prefer the CLI. :)

# Docker Clean

Docker tends to leave quite a bit of resedue in the hard disk. I started noticing this while creating Docker images in my Raspberry Pi. I guess when your disk is an 8GB micro SD card, space becomes a valuable resource. After confirming that my suspicions were valid, I found a few useful commands to clean up after Docker.  This shell script compiles them into one.

## Running the script

`wget https://raw.githubusercontent.com/tyrell/docker-utils/master/docker-clean.sh`

`sh docker-clean.sh`

You will see container IDs when the script is cleaning up.

If the commands do not find anything to clean, they will display an error. Essentially, this error will indicate that the command needs more parameters. Don't worry, this means your disk doesn't need cleaning.

## License
Copyright (c) 2016 Tyrell Perera<EMAIL_ADDRESS>Licensed under the MIT license.

repository: tyrell/docker-utils

repo_name: tyrell/docker-utils


text:
###TLS SSL Client

Sample application showcasing TLS/SSL with client certificates usage with M2MB API. Debug prints on **USB0**

**Features**

- How to check module registration and enable PDP context
- How to open a SSL client socket
- How to communicate over SSL socket

**Application workflow**

**`M2MB_main.c`**

- Open USB/UART/UART_AUX

- Create a task to manage the connection and start it

**`ssl_test.c`**

- Initialize Network structure and check registration

- Initialize PDP structure and start PDP context

- Create socket and link it to the PDP context id

- Connect to the server over TCP socket

- Initialize the TLS parameters (TLS1.2) andh auth mode (server+client auth in the example)

- Create SSL context

- Read certificates files and store them

- Create secure socket and connect to the server using SSL

- Send data and receive response

- Close secure socket

- Close socket

- Delete SSL context

- Disable PDP context

The application requires the certificates to be stored in `/test_ssl_certs/` folder. It can be created with `AT#M2MMKDIR=/test_ssl_certs`

![](../../pictures/samples/tcp_ssl_client_bordered.png)

---------------------

repository: balamuthunkl/IoT-AppZone-SampleApps

repo_name: balamuthunkl/IoT-AppZone-SampleApps