text:
---
title: Upgrading the server
description: Upgrading the deepstream server to V5
---

The following breaking changes were introduced in V5, sorted by easiest to hardest:

### Config renames

The following configuration options were renamed in config.yml due to adding a spell checker in visual code:

- dependencyInitialisationTimeout to dependencyInitializationTimeout

This way probably not used by anyone in V4, will be explained further down in it's own section.

- path() to file()

### Usage of fileLoad() and file() in config.yml

In V4 we introduced the ability to have custom plugins, and as we added new ones we realized that we really
don't want to be bogged down by simple details like reading config files, adjusting relative paths and ensuring
they exist. So we introduced two new helper macros. These have now been used for all files related mechanisms.

#### fileLoad(filename.yml)

```yaml
# reading users and passwords from a file
type: file
options:
  # Path to the user file. Can be json, js or yml
  path: fileLoad(users.yml)
```

This macro will:

1. Ensure the file exists
2. Load the file from the file system
3. Attempt to parse the file (currently supporting json and yml extensions), otherwise just leave it as text.
4. If that all works, replaces the `fileLoad(users.yml)` with the actual data

#### file(filename.yml)

```yaml
type: uws
options:
  key: file(cert/key.pem)
  cert: file(cert/cert.pem)
```

This macro will inform deepstream that the file is relative to the `config.yml` file. This is not
as useful as fileLoad but could be used if your plugin needs to reference an actual file (due to the
library underneath).

The two places you would need to change these are:

1) Valve

V5:

```yaml
permissions: fileLoad(permissions.yml)
```

V4:

```yaml
path: permissions.yml
```

2) User Authentication

V5:

```yaml
users: fileLoad(users.yml)
```

V4:

```yaml
path: users.yml
```

### No longer required to run all plugins and connection endpoints on separate ports

This change is more of a infrastructure concern *IF* you used both HTTP and WS at the same time.

If you use nginx please look at the [new simplified config](/tutorials/devops/nginx/) to get deepstream
working.

The idea is now *EVERYTHING* (minus MQTT) runs on port 6020, which makes deployments much easier. This
has been introduced by the use of a HTTP Service.

```yaml
httpServer:
  type: default
  options:
    # url path for http health-checks, GET requests to this path will return 200 if deepstream is alive
    healthCheckPath: /health-check
    # -- CORS --
    # if disabled, only requests with an 'Origin' header matching one specified under 'origins'
    # below will be permitted and the 'Access-Control-Allow-Credentials' response header will be
    # enabled
    allowAllOrigins: true
    # a list of allowed origins
    origins:
      - 'https://example.com'
    # Headers to copy over from websocket
    headers:
      - user-agent
    ssl:
      key: fileLoad(/path/to/sslKey)
      cert: fileLoad(/path/to/sslCert)
      ca: fileLoad(/path/to/caAuth)
```

OR

```yaml
httpServer:
  type: uws
  options:
    # url path for http health-checks, GET requests to this path will return 200 if deepstream is alive
    healthCheckPath: /health-check
    # Headers to copy over from websocket
    headers:
      - user-agent
    # Options required to create an ssl app
    ssl:
      key: file(ssl/key.pem)
      cert: file(ssl/cert.pem)
    ##  dhParams: ...
    ##  passphrase: ...
```

All websocket / HTTP services now hook into this server to provide their own functionality. This means you can run
all the servers at the same time on different ports if you want (for example text, binary and JSON).

The following config is now used for deepstream, please note the following important changes:

#### All server based concepts like path/port have been removed

#### Type name changes:
1) ws-websocket to ws-binary
2) node-http to http

#### Removal of UWS Websocket Endpoint

We now use UWS or a node HTTP server to drive all of deepstream and not individual parts

#### Path changes. Now that they are all on the same server we use the following paths:

1) Binary (V4/V5 clients): */deepstream*
2) Text (V3/V2 clients): */v3-deepstream*
3) JSON (V4/V5 debug builds): */deepstream-json*
4) HTTP Post/Get: */api* and */api/auth*

```yaml
# Connection Endpoint Configuration
connectionEndpoints:
  - type: ws-binary
    options:
      # url path websocket connections connect to
      urlPath: /deepstream
      # the amount of milliseconds between each ping/heartbeat message
      heartbeatInterval: 30000
      # the amount of milliseconds that writes to sockets are buffered
      outgoingBufferTimeout: 10
      # the maximum amount of bytes to buffer before flushing, stops the client from large enough packages
      # to block its responsiveness
      maxBufferByteSize: 100000

      # Security
      # amount of time a connection can remain open while not being logged in
      unauthenticatedClientTimeout: 180000
      # invalid login attempts before the connection is cut
      maxAuthAttempts: 3
      # maximum allowed size of an individual message in bytes
      maxMessageSize: 1048576

  - type: ws-text
    options:
      # url path websocket connections connect to
      urlPath: /deepstream-v3
      # the amount of milliseconds between each ping/heartbeat message
      heartbeatInterval: 30000
      # the amount of milliseconds that writes to sockets are buffered
      outgoingBufferTimeout: 10
      # the maximum amount of bytes to buffer before flushing, stops the client from large enough packages
      # to block its responsiveness
      maxBufferByteSize: 100000

      # Security
      # amount of time a connection can remain open while not being logged in
      unauthenticatedClientTimeout: 180000
      # invalid login attempts before the connection is cut
      maxAuthAttempts: 3
      # maximum allowed size of an individual message in bytes
      maxMessageSize: 1048576

  - type: ws-json
    options:
      # url path websocket connections connect to
      urlPath: /deepstream-json
      # the amount of milliseconds between each ping/heartbeat message
      heartbeatInterval: 30000
      # the amount of milliseconds that writes to sockets are buffered
      outgoingBufferTimeout: 10
      # the maximum amount of bytes to buffer before flushing, stops the client from large enough packages
      # to block its responsiveness
      maxBufferByteSize: 100000

      # Security
      # amount of time a connection can remain open while not being logged in
      unauthenticatedClientTimeout: 180000
      # invalid login attempts before the connection is cut
      maxAuthAttempts: 3
      # maximum allowed size of an individual message in bytes
      maxMessageSize: 1048576

  - type: http
    options:
      # allow 'authData' parameter in POST requests, if disabled only token and OPEN auth is
      # possible
      allowAuthData: true
      # enable the authentication endpoint for requesting tokens/userData.
      # note: a custom authentication handler is required for token generation
      enableAuthEndpoint: false
      # path for authentication requests
      authPath: /api/auth
      # path for POST requests
      postPath: /api
      # path for GET requests
      getPath: /api
      # maximum allowed size of an individual message in bytes
      maxMessageSize: 1024

  - type: mqtt
    options:
        # port for the mqtt server
        port: 1883
        # host for the mqtt server
        host: <IP_ADDRESS>
        # timeout for idle devices
        idleTimeout: 60000
```

### Authentication API now supports multiple authentication mechanisms

Our auth API now uses an array of authentication endpoints instead of a single one.

The following example is a user failing to authenticate (due to not being found on the system) and
instead of failing getting an anonymous session (with limited data).

```yaml
auth:
  - type: file
    options:
      path: ./users.yml
  - type: none
```

For those developing/maintaining an auth endpoint please refer to the [updated guide](/tutorials/custom-plugins/authentication/)

### Permission API argument list has been shortened

The permission plugin API has been shortened since the name and data are all present on socketWrapper and easily found using typescript. Bonus is we now also can permission against clientData.

```ts
public canPerformAction(socketWrapper: SocketWrapper, message: Message, callback: PermissionCallback, passItOn: any): void {
  const { userId, clientData, serverData } = socketWrapper
}
```

gha_language: TypeScript


text:
### git checkout

In this section, we will discuss the available 'undo' Git strategies and commands. It is first important to note that Git does not have a traditional 'undo' system like those found in a word processing application. It will be beneficial to refrain from mapping Git operations to any traditional 'undo' mental model. Additionally, Git has its own nomenclature for 'undo' operations that it is best to leverage in a discussion. This nomenclature includes terms like reset, revert, checkout, clean, and more.

A fun metaphor is to think of Git as a timeline management utility. Commits are snapshots of a point in time or points of interest along the timeline of a project's history. Additionally, multiple timelines can be managed through the use of branches. When 'undoing' in Git, you are usually moving back in time, or to another timeline where mistakes didn't happen.

This tutorial provides all of the necessary skills to work with previous revisions of a software project. First, it shows you how to explore old commits, then it explains the difference between reverting public commits in the project history vs. resetting unpublished changes on your local machine.

#### Finding what is lost: reviewing old commits

The whole idea behind any version control system is to store “safe” copies of a project so that you never have to worry about irreparably breaking your code base. Once you’ve built up a project history of commits, you can review and revisit any commit in the history. One of the best utilities for reviewing the history of a Git repository is the git log command. In the example below, we use [git log](#git-log) to get a list of the latest commits to a popular open-source graphics library.

```
git log --oneline
e2f9a78fe Replaced FlyControls with OrbitControls
d35ce0178 Editor: Shortcuts panel Safari support.
9dbe8d0cf Editor: Sidebar.Controls to Sidebar.Settings.Shortcuts. Clean up.
05c5288fc Merge pull request #12612 from TyLindberg/editor-controls-panel
0d8b6e74b Merge pull request #12805 from harto/patch-1
23b20c22e Merge pull request #12801 from gam0022/improve-raymarching-example-v2
fe78029f1 Fix typo in documentation
7ce43c448 Merge pull request #12794 from WestLangley/dev-x
17452bb93 Merge pull request #12778 from OndrejSpanel/unitTestFixes
b5c1b5c70 Merge pull request #12799 from dhritzkiv/patch-21
1b48ff4d2 Updated builds.
88adbcdf6 WebVRManager: Clean up.
2720fbb08 Merge pull request #12803 from dmarcos/parentPoseObject
9ed629301 Check parent of poseObject instead of camera
219f3eb13 Update GLTFLoader.js
15f13bb3c Update GLTFLoader.js
6d9c22a3b Update uniforms only when onWindowResize
881b25b58 Update ProjectionMatrix on change aspect
```

Each commit has a unique SHA-1 identifying hash. These IDs are used to travel through the committed timeline and revisit commits. By default, `git log` will only show commits for the currently selected branch. It is entirely possible that the commit you're looking for is on another branch. You can view all commits across all branches by executing `git log --branches=*`. The command [git branch](#using-branches) is used to view and visit other branches. Invoking the command, `git branch -a` will return a list of all known branch names. One of these branch names can then be logged using `git log <branch_name>`.

When you have found a commit reference to the point in history you want to visit, you can utilize the `git checkout` command to visit that commit. `git checkout` is an easy way to “load” any of these saved snapshots onto your development machine. During the normal course of development, the `HEAD` usually points to master or some other local branch, but when you check out a previous commit, HEAD no longer points to a branch—it points directly to a commit. This is called a “detached HEAD” state, and it can be visualized as the following:

![](undoing-changes-01.png)

Checking out an old file does not move the `HEAD` pointer. It remains on the same branch and same commit, avoiding a 'detached head' state. You can then commit the old version of the file in a new snapshot as you would any other changes. So, in effect, this usage of `git checkout` on a file, serves as a way to revert back to an old version of an individual file. For more information on these two modes visit the [git checkout](#git-checkout) page

#### Viewing an old revision

This example assumes that you’ve started developing a crazy experiment, but you’re not sure if you want to keep it or not. To help you decide, you want to take a look at the state of the project before you started your experiment. First, you’ll need to find the ID of the revision you want to see.

```
git log --oneline
```

Let’s say your project history looks something like the following:

```
b7119f2 Continue doing crazy things
872fa7e Try something crazy
a1e8fb5 Make some important changes to hello.txt
435b61d Create hello.txt
9773e52 Initial import
```

You can use git checkout to view the “Make some import changes to hello.txt” commit as follows:

```
git checkout a1e8fb5
```

This makes your working directory match the exact state of the a1e8fb5 commit. You can look at files, compile the project, run tests, and even edit files without worrying about losing the current state of the project. Nothing you do in here will be saved in your repository. To continue developing, you need to get back to the “current” state of your project:

```
git checkout master
```

This assumes that you're developing on the default `master` branch. Once you’re back in the master branch, you can use either [git revert](#git-revert) or [git reset](#git-reset) to undo any undesired changes.

#### Undoing a committed snapshot

There are technically several different strategies to 'undo' a commit. The following examples will assume we have a commit history that looks like:

```
git log --oneline
872fa7e Try something crazy
a1e8fb5 Make some important changes to hello.txt
435b61d Create hello.txt
9773e52 Initial import
```

We will focus on undoing the `872fa7e Try something crazy` commit. Maybe things got a little too crazy.

#### How to undo a commit with git checkout

Using the git checkout command we can checkout the previous commit, `a1e8fb5`, putting the repository in a state before the crazy commit happened. Checking out a specific commit will put the repo in a "detached HEAD" state. This means you are no longer working on any branch. In a detached state, any new commits you make will be orphaned when you change branches back to an established branch. Orphaned commits are up for deletion by Git's garbage collector. The garbage collector runs on a configured interval and permanently destroys orphaned commits. To prevent orphaned commits from being garbage collected, we need to ensure we are on a branch.

From the detached HEAD state, we can execute `git checkout -b new_branch_without_crazy_commit`. This will create a new branch named `new_branch_without_crazy_commit` and switch to that state. The repo is now on a new history timeline in which the `872fa7e` commit no longer exists. At this point, we can continue work on this new branch in which the `872fa7e` commit no longer exists and consider it 'undone'. Unfortunately, if you need the previous branch, maybe it was your `master` branch, this undo strategy is not appropriate. Let's look at some other 'undo' strategies. For more information and examples review our in-depth [git checkout](#git-checkout) discussion.

#### How to undo a public commit with git revert

Let's assume we are back to our original commit history example. The history that includes the `872fa7e` commit. This time let's try a revert 'undo'. If we execute `git revert HEAD`, Git will create a new commit with the inverse of the last commit. This adds a new commit to the current branch history and now makes it look like:

```
git log --oneline
e2f9a78 Revert "Try something crazy"
872fa7e Try something crazy
a1e8fb5 Make some important changes to hello.txt
435b61d Create hello.txt
9773e52 Initial import
```

At this point, we have again technically 'undone' the `872fa7e` commit. Although `872fa7e` still exists in the history, the new `e2f9a78` commit is an inverse of the changes in `872fa7e`. Unlike our previous checkout strategy, we can continue using the same branch. This solution is a satisfactory undo. This is the ideal 'undo' method for working with public shared repositories. If you have requirements of keeping a curated and minimal Git history this strategy may not be satisfactory.

#### How to undo a commit with git reset

For this undo strategy we will continue with our working example. [git reset](#git-reset) is an extensive command with multiple uses and functions. If we invoke `git reset --hard` a1e8fb5 the commit history is reset to that specified commit. Examining the commit history with git log will now look like:

```
git log --oneline
a1e8fb5 Make some important changes to hello.txt
435b61d Create hello.txt
9773e52 Initial import
```

The log output shows the `e2f9a78` and `872fa7e` commits no longer exist in the commit history. At this point, we can continue working and creating new commits as if the 'crazy' commits never happened. This method of undoing changes has the cleanest effect on history. Doing a reset is great for local changes however it adds complications when working with a shared remote repository. If we have a shared remote repository that has the `872fa7e` commit pushed to it, and we try to git push a branch where we have reset the history, Git will catch this and throw an error. Git will assume that the branch being pushed is not up to date because of it's missing commits. In these scenarios, `git revert` should be the preferred undo method.

#### Undoing the last commit

In the previous section, we discussed different strategies for undoing commits. These strategies are all applicable to the most recent commit as well. In some cases though, you might not need to remove or reset the last commit. Maybe it was just made prematurely. In this case you can amend the most recent commit. Once you have made more changes in the working directory and staged them for commit by using [git add](#saving-changes), you can execute `git commit --amend`. This will have Git open the configured system editor and let you modify the last commit message. The new changes will be added to the amended commit.

#### Undoing uncommitted changes

Before changes are committed to the repository history, they live in the staging index and the working directory. You may need to undo changes within these two areas. The staging index and working directory are internal Git state management mechanisms. For more detailed information on how these two mechanisms operate, visit the [git reset](#resetting-checking-out-and-reverting) page which explores them in depth.

#### The working directory

The working directory is generally in sync with the local file system. To undo changes in the working directory you can edit files like you normally would using your favorite editor. Git has a couple utilities that help manage the working directory. There is the `git clean` command which is a convenience utility for undoing changes to the working directory. Additionally, git reset can be invoked with the `--mixed` or `--hard` options and will apply a reset to the working directory.

#### The staging index

The [git add](#saving-changes) command is used to add changes to the staging index. Git reset is primarily used to undo the staging index changes. A `--mixed` reset will move any pending changes from the staging index back into the working directory.

#### Undoing public changes

When working on a team with remote repositories, extra consideration needs to be made when undoing changes. `git reset` should generally be considered a 'local' undo method. A reset should be used when undoing changes to a private branch. This safely isolates the removal of commits from other branches that may be in use by other developers. Problems arise when a reset is executed on a shared branch and that branch is then pushed remotely with git push. Git will block the push in this scenario complaining that the branch being pushed is out of date from the remote branch as it is missing commits.

The preferred method of undoing shared history is `git revert`. A revert is safer than a reset because it will not remove any commits from a shared history. A revert will retain the commits you want to undo and create a new commit that inverts the undesired commit. This method is safer for shared remote collaboration because a remote developer can then pull the branch and receive the new revert commit which undoes the undesired commit.

#### Summary
We covered many high-level strategies for undoing things in Git. It's important to remember that there is more than one way to 'undo' in a Git project. Most of the discussion on this page touched on deeper topics that are more thoroughly explained on pages specific to the relevant Git commands. The most commonly used 'undo' tools are [git checkout](#git-checkout), [git revert](#git-revert), and [git reset](#git-reset). Some key points to remember are:
- Once changes have been committed they are generally permanent
- Use `git checkout` to move around and review the commit history
- `git revert` is the best tool for undoing shared public changes
- `git reset` is best used for undoing local private changes

In addition to the primary undo commands, we took a look at other Git utilities:
- [git log](#git-log) for finding lost commits
- [git clean](#git-clean) for undoing uncommitted changes
- [git add](#saving-changes) for modifying the staging index.

Each of these commands has its own in-depth documentation. To learn more about a specific command mentioned here, visit the corresponding links.

repository: igorbotian/atlassian-git-tutorials

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: igorbotian/atlassian-git-tutorials


text:
---
layout:     post
title:      "Bayesian Bandits"
subtitle:   "A simple implementation"
date:       2019-02-10 12:00:00
author:     "Alejandro Blumentals"
---

# Bayesian Bandits
In this notebook we'll go through a simple implementation of bayesian bandits.

The setting is that we're faced with a number of bandit machines. They all have a different probability of yielding a jackpot, but we don't know which one is the best. At each step we choose one arm to pull, observe the result and collect the reward if any. The goal is to maximize our reward, but there's a bit of exploration and exploitation to trade off. We want to pull arms more or less at random at the beginning to get as much information as possible and then pull more and more frequently on the bandits which we think are best.

In this notebook we implement two agents:
* a RandomAgent which just takes actions at random
* a BayesianAgent which
   * keeps a posterior distribution for each bandit updated
   * at each step draws a probability from the posteriors and chooses the bandit with the highest drawn probability.

```python
import numpy as np
import matplotlib.pyplot as plt
%matplotlib inline
```

We'll make a simple bandit environment, mimicking the OpenAI gym interface.

```python
class BanditEnv:
    def __init__(self, n):
        self.actions = np.arange(n)
        self.probs = np.random.random(n)
    def step(self, action: int):
        return np.random.binomial(n=1, p=self.probs[action])
```

We create an environment with just one bandit and check that the probability and sample mean are close

```python
env = BanditEnv(1)
```

```python
rewards = []
for i in range(1000):
    rewards.append(env.step(0))
print("mean reward: ", np.mean(rewards))
print("bandit probability: ", env.probs[0])
```

    mean reward:  0.625
    bandit probability:  0.5985785801165487

Now we implement our random agent and let it do 10000 steps in a bandit environment with 10 bandits.

```python
class RandomAgent:
    def __init__(self, n):
        self.n = n
    def choose_bandit(self):
        return np.random.randint(0, self.n)
```

```python
n_bandits = 10
env = BanditEnv(n_bandits)
rand_agent = RandomAgent(n_bandits)
```

```python
sims = 10000
rewards = np.zeros(sims)
for i in range(sims):
    action = rand_agent.choose_bandit()
    rewards[i] = env.step(action)
plt.plot(np.cumsum(rewards))
plt.xlabel('episodes')
plt.ylabel('cumulative reward')
plt.title("Cumulative rewards of random agent")
```

    Text(0.5, 1.0, 'Cumulative rewards of random agent')

![png](/img/bayesian-bandits_files/output_10_1.png)

Next we implement the BayesianAgent and check that it outperforms the RandomAgent.

```python
from scipy.stats import beta
class BayesianAgent:
    def __init__(self, n):
        self.n = n
        self.posterior_params = [{"a": 1, "b":1} for i in range(n)]
    def choose_bandit(self):
        #sample from posteriors
        posteriors_samples = [beta.rvs(self.posterior_params[i]["a"], self.posterior_params[i]["b"]) for i in range(self.n)]
        action = np.argmax(posteriors_samples)
        return action
    def update_posterior(self, i, observation):
        if observation==1:
            self.posterior_params[i]["a"]+=1
        else:
            self.posterior_params[i]["b"]+=1
```

```python
bb = BayesianAgent(n_bandits)
```

```python
sims = 10000
rewards_bayesian = np.zeros(sims)
for i in range(sims):
    action = bb.choose_bandit()
    reward = env.step(action)
    bb.update_posterior(action, reward)
    rewards_bayesian[i] = reward
plt.plot(np.cumsum(rewards_bayesian), label="bayesian")
plt.plot(np.cumsum(rewards), label="random")
plt.xlabel('episodes')
plt.ylabel('cumulative reward')
plt.title("Cumulative rewards")
plt.legend();
```

![png](/img/bayesian-bandits_files/output_14_0.png)

license: MIT


text:
# hubot-voting

To vote on topics

See [`src/hubot-voting.coffee`](src/hubot-voting.coffee) for full documentation.

## Installation

In hubot project repo, run:

`npm install hubot-voting --save`

Then add **hubot-voting** to your `external-scripts.json`:

```json
["hubot-voting"]
```

## Sample Interaction

### Start a vote

    hubot start vote first item, second item, third item

### Vote

    hubot vote for first item

or...

    hubot vote for 1

or...

    hubot vote first item

or...

    hubot vote 1

### Show choices

    hubot show choices

### Show votes

    hubot show votes

### End a vote

    hubot end vote

## License

MIT licensed. Copyight 2014 Joshua Antonishen + 2015 Hector Leiva

repository: hectorleiva/hubot-voting

gha_language: CoffeeScript

repo_name: hectorleiva/hubot-voting


text:
---
title: The pursuit of physical crafts.
categories: [thoughts]
tags: [Musings]
layout: post

---

Despite my pudgy fingers.

 Japanese Star Wars "paper theatre"

The past two weekends, I have induged in physical crafts. It's been surprisingly enjoyable. Growing up, I never was a very enthusiastic artist. It is probably because I have sausage like fingers which offer little to no dexterity. But these past two weeks have seen me being drawn to physical crafts despite my non-cooperative digits.

Last week, I went to a Friend's place. There, we worked on putting together something called "paper theatre". Her friend had brought back for her a Star Wars themed paper theatre craft kit from Japan, where such craft kits are quite popular. It had been gathering dust for nearly 3 years. We decided that it was time for it to see the light of the day.

Such kits comprise of laser cut pieces of paper that have to be layered in a manner that it creates a nice 3D scene.

 The laser cut pieces that came with our kit

All of these layered sheets once put together with glue, clever folds and sheer will come together to form a very satisfying frame, almost a painting.

I struggled a lot while making this. The glue kept sticking to my hands. The pieces kept falling apart. And it was really hard to even remove the laser cut pieces. My Friend's more supple female fingers were not much more useful either, since the person in charge of the said digits was outsourcing the bulk of the gluing and cutting gruntwork to me.

Something about dealing with analog articles like glue and scissors was very therapeutic. This may not seem like a big thing for a lot of people, but I rarely spend time in such pursuits. I doubt a lot of us do. We fill our free time binging shows, playing games and living in other digital worlds. This felt different, better.

This weekend too, I wanted to spend more time living in the real world. I wanted to use my uncooperative fingers to make something. I wanted to pursue a physical craft. I decided to paint my 3D print of the 2018 Ferrari that was driven by Vettel and Kimi.

 The result of my paintjob.

I painted the car an iconic ferrari red, and coated it in a layer of glossy epoxy spray paint to finish it off.

It was hard painting this. The model was tiny. The paint kept rubbing off on my fingers. I could not even paint in uniform strokes. But I loved every second of it.

### Therapy

The pursuit of physical crafts is therapeutic in nature. I think I have developed stockholm syndrome towards technology. It lured me in with shiny colours, bright lights and a wild promise of power, but cleverly hid its consequences in the terms and conditions.

 Or, how to get into physical crafts

Indugling in these tiny art projects has made me congizant of the terms and conditions of being a tech bro™, the ones I initially overlooked. You may also be like me. Get into pottery, carpentry, painting, drawing, anything really. I assure you, you will feel a lot more at peace.

gha_language: HTML

gha_license_id: MIT


text:
# QCHAT APP
QChat is a group chat app with multiple sockets, developed mainly with Python's Flask and backend modules as well as pure JavaScript and a responsive Bootstrap design on the frontend (Edit: Bootstrap links were corrupted (or maybe I am just bad) which causes the message to disappear and no message animation. Therefore, the temporary solution to the problem is to display messages in plain text and will fix later on)

## Link to heroku live app

https://qchat-application.herokuapp.com

## Configuration

Then make sure all the required modules listed in requirements.txt file are installed on your machine.

For manual installation enter the following command.
```
$ pip3 install moduleName
```
Make sure that you have install virtual environment, if not use the following command
```
$ pip3 install virtualenv
```
On your project folder enter the following commands in order to create a virtual environment.

```bash
virtualenv venv
```

Next, activate your virtual environment using the following command.

```bash
source venv/Scripts/activate
```
Note: This only works for Linux. For Windows and Macs, replace ```Scripts```with ```bin```

Install the requirements using the following command.

```bash
pip install -r requirements.txt
```

Make a few adjustment on the code at application.py file:

1- Change the database secret key and url according to their comments above of them (can be found from line 10 to 17 on application.py)

```python
# Secret key
app.secret_key = 'secret'

# Configure database
app.config['SQLALCHEMY_DATABASE_URI']='postgresql://ywbnoztyucofwo:f770a5fb7b4ebc3df8f2b59d682c2f87f409142b36bd8248b36a07c046b03808@ec2-54-164-22-242.compute-1.amazonaws.com:5432/d1mp446fh6pe2b'
```

2- Change the last line of code on application.py according to the guide below.
```python
# remove the code below and use "socketio.run(app, debug=True)" if running on a local system
app.run()
```

## Running (for people who want to run the program locally)

To run your project enter the following command.

```
python application.py
```

Then copy the local address into a web browser (Chrome is recommended but you can also use Vivaldi). Here is an example:

```
http://<IP_ADDRESS>:5000/
```

You will be directed to a registration page first.

![Registration Page](/visuals/sign-up.png)

After completing the registration you will be required to login with your credentials.

![Login Page](/visuals/login.png)

Upon logging in, you will be able to use different chat rooms to talk with the online users.

![Chat Room](/visuals/chat.png)

## Future Improvements

1- Fix visual and animation problem from Bootstrap

2- I don't know, maybe I might make it into Tinder #2 but with video call

## License

[MIT](https://choosealicense.com/licenses/mit/)


text:
---
layout: post
title: I Passed Phase 0! Now What?
---

![Phase 1 nights would be typically look like this](/images/latenightworkingsmaller.jpg)

After finishing some administrations and having fun in the weekend before the storm, I finally arrived again @Hacktiv8 for the next Phase. The real challenges now begins. First we were briefed, signed some papers, and photoshoot (for professional looking in CV and such), then off we go to the Phase 1.

Everyday we are given challenges to be done on the same day, lectures, live codes are to be done in the faster pace. I'm really overwhelmed by this. Everything is different but show must go on. I decided to come early so I can jumpstart the challenges, come home a little bit late to work on assignments. But that came at a cost. I'm not feeling well afterwards, so is few others. Some even go home after our first Phase Live Code.

All I see in the lab are either pale, sick, thinking hard, gave out or stressed out faces. This means both good and bad... in a way.

Some advice for Phase 1 (May change over weeks):

-   It's much better joining Hacktiv8 at Phase 0. Because you will be introducted to the learning pace of Hacktiv8 at much managable pace, so you know what to expect of Live codes, and projects.

-   More or less; the Live Code for phase 1 is structured a lot different. there are difficulty stages for each problem (Easy, Medium, Hard), and we are given two hours to solve it. Still, I'm not prepared.

-   Less time for "Me" Time <-- Totally agreed. Even weekends is filled with challenges.

-   It is advised to have food delivery subscription. Most of the resto are far, so you'll find yourself walking 10-20 minutes before you have a good meal.

-   Invest in Noise cancelling Headphones. You need to be in Zen mode to give your best.

As for now, I'm preparing for the next week. Wish me luck!

branch_name: refs/heads/main


text:
# V1NonResourceRule

NonResourceRule holds information that describes a rule for the non-resource
## Properties
Name | Type | Description | Notes
------------ | ------------- | ------------- | -------------
**non_resource_ur_ls** | **list[str]** | NonResourceURLs is a set of partial urls that a user should have access to.  *s are allowed, but only as the full, final step in the path.  \"*\" means all. | [optional]
**verbs** | **list[str]** | Verb is a list of kubernetes non-resource API verbs, like: get, post, put, delete, patch, head, options.  \"*\" means all. |

[[Back to Model list]](../README.md#documentation-for-models) [[Back to API list]](../README.md#documentation-for-api-endpoints) [[Back to README]](../README.md)

repository: kubernetes-client/python

gha_language: Python

repo_name: kubernetes-client/python


text:
# Simple Danted install

This is a script to install danted on Ubuntu.
So far it's been tested on Ubuntu 16.06, but it should work on newer versions too.

Usage:

```shell
wget https://raw.githubusercontent.com/pleszkan/simple-danted-install/master/danteinstall.sh
chmod +x danteinstall.sh
./danteinstall.sh <password>
```

repository: pleszkan/simple-danted-install

repo_name: pleszkan/simple-danted-install


text:
---
title: Rust Library Style
order: 5
---
# Rust Library Coding Standard

This guide will help us keep the style in our Rust Library consistent.

This guide builds on the normal rust style guide [here](https://doc.rust-lang.org/1.0.0/style/)

## Names

### Make Names Fit

Names are the heart of programming. In the past people believed knowing someone's true
name gave them magical power over that person. If you can think up the true name for
something, you give yourself and the people coming after power over the code. Don't laugh!
A name is the result of a long deep thought process about the ecology it lives in. Only a
programmer who understands the system as a whole can create a name that "fits" with the
system. If the name is appropriate everything fits together naturally, relationships are clear,
meaning is derivable, and reasoning from common human expectations works as expected.

If you find all your names could be Thing and DoIt then you should probably revisit your design.

### Types

* Use platform agnostic types like `usize` and `isize` vs `u32` or `i32`.
* Use BTreeMap over HashMap because
    - Predictable iterating
    - Avoids Hash flooding DoS attacks

### Function Names

Rust uses snake casing for function names.

* Usually every function performs an action, so the name should make clear what it does:
check_for_errors() instead of error_check(), dump_data_to_file() instead of data_file().
This will also make functions and data objects more distinguishable.
Structs are often nouns. By making function names verbs and following other naming
conventions programs can be read more naturally.
* Suffixes are sometimes useful:
  * max  - to mean the maximum value something can have.
  * count  - the current count of a running count variable.
  * key  - key value.
* For example: retry_max to mean the maximum number of retries, retry_cnt to mean the
current retry count.
* Prefixes are sometimes useful:
  * is  - to ask a question about something. Whenever someone sees  Is  they will
know it's a question.
  * get  - get a value.
  * set  - set a value.
  * to  - convert existing value into something else.
  * from  - create a new value from an existing one.
* For example: is_hit_retry_limit.

When in doubt, use longer names for clarity versus shorter names that can potentially be confusing.

### Variable Naming & Declarations

* Variable declarations should be limited to one per line.
* Variables should be descriptively named, using abbreviations sparingly if at all.
* Words should be separated by underscores.
* Variables should be all lower case
* Global variables are discouraged in Rust, except in rare cases such as when implementing FFI.
* Global variables and constants are all upper case.
* Types are usually inferred by the compiler, only include the type if the compiler can't do the inference.
* Only use `mut` if needed. Prefer to use immutable variables as much as possible.

```rust
const MAX_BUFFER_SIZE = 65535;
let remote_host_dns_name = “www.ockam.io”;
let mut bytes_received = 0;
```

### Include Units in Names

If a variable represents time, weight, or some other unit then include the unit in the name so
developers can more easily spot problems.

```rust
let timeout_msecs = 0;
let my_weight_lbs = 0;
```

### Structure and Enumeration Names

* Use Pascal Case.
* Field names are all lower case with words separated by underscores ('\_').
* Field names are sorted alphabetically.
* Rust supports tupling. However, Tuples with more than 2 elements are confusing. Use a struct with named fields instead.
* If only one or two fields are in the struct, the tuple version may be allowed as long as the intented use is clear.

```rust
struct Foo {
    foo Next, /* List of active foo */
    bar usize,
    baz: usize, /* Bitfield */
};
```

### Global Constants

Global constants should be all caps with '_' separators.

```rust
const A_GLOBAL_CONSTANT: usize = 5;
```

### Macro Names

Macros are all lower case with '_' word separators

Use macros to keep code DRY (don't repeat yourself).

### Error Handling

Use one enum that represents all the possible errors that can occur that inherits the **Fail** trait from the `failure` crate. Use a struct that wraps the enum to provide stacktraces and contexts. All these should be in one file named *errors.rs*.

When other packages and crates throw errors, implement the **From** trait from that error to the enum and error struct in *errors.rs*. This avoids the need to convert between error types throughout the rest of the code.

```rust
use failure::{Backtrace, Context, Fail};

#[derive(Clone, Copy, Fail, Debug)]
pub enum ErrorKind {
    #[display = "Failed to initialize"]
    Init,
    #[display = "Failed to read or write to network"]
    NetworkError
}

#[derive(Debug)]
pub struct Error {
    inner: Context<ErrorKind>,
}

```

## Packaging

### Cargo.toml

Sort fields in each section alphabetically.
Use the latest "edition" in the \[package\] section. (Right now its 2018).

### Crate declaration

Only use `extern crate <crate-name>` when importing macros.

## Formatting

### Braces

**Placement**

Of the three major brace placement strategies one is recommended:

```rust
if condition {
    while condition {
        ...
    }
    ...
}
```

**When Braces are Needed**

All if, while and do statements must either have braces or be on a single line.

**Always Uses Braces Form**

All if, while and do statements require braces even if there is only a single statement within the
braces.

```rust
if 1 == somevalue {
    somevalue = 2;
}
```

**Justification**

It ensures that when someone adds a line of code later there are already braces and they don't
forget. It provides a more consistent look. This doesn't affect execution speed. It's easy to do.

**One Line Form**

```c
if 1 == somevalue { somevalue = 2; }
```

**Justification**

It provides safety when adding new lines while maintaining a compact readable form.

**Add Comments to Closing Braces**

Adding a comment to closing braces can help when you are reading code because you don't
have to find the begin brace to know what is going on.

```rust
loop {
    if (valid) {
    } /* if valid */
    else {
    } /* not valid */
} /* end forever */
```

### Consider Screen Size Limits

Some people like blocks to fit within a common screen size so scrolling is not necessary when
reading code.

### Parens () with Key Words and Functions Policy

* Do not put parens next to keywords. Put a space between.
* Do put parens next to function names.
* Do not use parens in return statements when it's not necessary.

**Justification**

Keywords are not functions. By putting parens next to keywords keywords and function names are made to look alike.

```rust
if condition {
}
while condition {
}

strcpy(s, s1);
return 1;
```

### A Line Should Not Exceed 120 Characters

Lines should not exceed 120 characters.

### If Then Else Formatting

#### Layout

It's up to the programmer. Different bracing styles will yield slightly different looks. One common
approach is:

```rust
if condition {
} else if condition {
} else {
}
```

If you have  _else if_  statements then it is usually a good idea to always have an else block for
finding unhandled cases. Maybe put a log message in the else even if there is no corrective
action taken.

#### Condition Format

Always put the constant on the left hand side of an equality/inequality comparison. For example:

```rust
if 6 == errorNum ...
```

One reason is that if you leave out one of the = signs, the compiler will find the error for you. A
second reason is that it puts the value you are looking for right up front where you can find it
instead of buried at the end of your expression. It takes a little time to get used to this format,
but then it really gets useful.

### match Formatting

* The  default  case should always be present and trigger an error if it should not be
reached, yet is reached.
* If you need to create variables put all the code in a block.
* Prefer putting all code in blocks unless its a single expression

```rust
match ...  {
    1 => {
        ...
        /* comments */
    },
    2 => {
        let v: usize;
        ...
    },
    3 => {
       ...
    }
    _ => {}
}
```

### Use of goto, continue, break and ?:

#### Goto

Goto statements should be used in only one situation, and that is to use the label to break to an outer loop.

```rust
'nextbasis: for basis in bases {
    ...
    for _ in 1..trials {
        ...
        if condition {
            break 'nextbasis;
        }
    }
}
```

#### Continue and Break

Continue and break are really disguised gotos so they are covered here.
Continue and break like goto should be used sparingly as they are magic in code. With a simple
spell the reader is beamed to god knows where for some usually undocumented reason.
The two main problems with continue are:
* It may bypass the test condition
* It may bypass the increment/decrement expression
Consider the following example where both problems occur:

```rust
loop {
    ...
    /* A lot of code */
    ...
    if condition {
        continue;
    }
    ...
    /* A lot of code */
    ...
    if i > STOP_VALUE { break; }
}
```

"A lot of code" is necessary in order that the problem cannot be caught easily by the
programmer.

From the above example, a further rule may be given: Mixing continue with break in the same
loop is a sure way to disaster.

### One Statement Per Line

There should be only one statement per line unless the statements are very closely related.

**Justification**

The code is easier to read.  Nothing better than to read code
that is one line after another with no white space or comments.

#### One Variable Per Line

Related to this is always define one variable per line:

**Do:**

```rust
let count = 0;
let mut bytes_received = 0;
```

**Don’t:**

```rust
let bytes_received, count;
```

**Justification**

* Documentation can be added for the variable on the line.
* It's clear that the variables are initialized.
* Declarations are clear which reduces the probability of declaring a struct when you
   meant to declare just an int.

**Make Macro Names Unique**

Like global variables macros can conflict with macros from other packages.

* Prepend macro names with package names.
* Avoid simple and common names like *max* and *min*.

## Short Functions

Functions should limit themselves to a page or two of code.

**Justification**

* The idea is that the each method represents a technique for achieving a single objective.
* Most arguments of inefficiency turn out to be false in the long run.
* True function calls are slower than not, but there needs to be a thought out decision (see
  premature optimization).

## Documentation

Use the following in the header of the lib.rs or main.rs file to help limit bad styles by the compiler

```rust
#![deny(
    missing_docs,
    trivial_casts,
    trivial_numeric_casts,
    unconditional_recursion,
    unused_import_braces,
    unused_lifetimes,
    unused_qualifications,
    unused_extern_crates,
    unused_parens,
    while_true
)]
```

**Comments Should Tell a Story**

Consider your comments a story describing the system. Expect your comments to be extracted
by a robot and formed into a man page. Class comments are one part of the story, method
signature comments are another part of the story, method arguments another part, and method
implementation yet another part. All these parts should weave together and inform someone
else at another point of time just exactly what you did and why.

**Document Decisions**

Comments should document decisions. At every point where you had a choice of what to do
place a comment describing which choice you made and why. Archeologists will find this the
most useful information.

**Make Gotchas Explicit**

Explicitly comment variables changed out of the normal control flow or other code likely to break
during maintenance. Embedded keywords are used to point out issues and potential problems.
Consider a robot will parse your comments looking for keywords, stripping them out, and making
a report so people can make a special effort where needed.

**Gotcha Keywords**

* `author`:
specifies the author of the module

* `version`:
specifies the version of the module

* `param`:
specifies a parameter into a function

* `return`:
specifies what a function returns

* `see` <link\>:
creates a link in the documentation to the file/function/variable to consult to get a better
understanding on what the current block of code does.

* `TODO`:
what remains to be done

* `bug`:
report a bug found in the piece of code

**Gotcha Formatting**

* Make the gotcha keyword the first symbol in the comment.
* Comments may consist of multiple lines, but the first line should be a self-containing,
meaningful summary.
* The writer's name and the date of the remark should be part of the comment. This
information is in the source repository, but it can take a quite a while to find out when
and by whom it was added. Often gotchas stick around longer than they should.
Embedding date information allows other programmer to make this decision. Embedding
who information lets us know who to ask.

**Commenting function declarations**

Functions headers should be in the file where they are declared using the triple forward slashes.

## Layering

Layering is the primary technique for reducing complexity in a system. A system should be
divided into layers. Layers should communicate between adjacent layers using well defined
interfaces. When a layer uses a non-adjacent layer then a layering violation has occurred.
A layering violation simply means we have dependency between layers that is not controlled by
a well defined interface. When one of the layers changes code could break. We don't want code
to break so we want layers to work only with other adjacent layers.

Sometimes we need to jump layers for performance reasons. This is fine, but we should know
we are doing it and document appropriately.

## Miscellaneous

### General advice

This section contains some miscellaneous do's and don'ts.

* Don't use floating-point variables where discrete values are needed. Using a float for a
loop counter is a great way to shoot yourself in the foot. Always test floating-point
numbers as <= or >=, never use an exact comparison (== or !=).

* Use `cargo fmt` to help style your code

* Use `cargo clippy` to check for better and preferred manners of performing the same code.

### Commenting Out Large Code Blocks

Sometimes large blocks of code need to be commented out for testing.

#### Add a Comment to Document Why

Add a short comment explaining why it is not implemented, obsolete or temporarily disabled.

### No Magic Numbers

A magic number is a bare naked number used in source code. It's magic because no-one has a
clue what it means including the author inside 3 months. For example:

```rust
if 22 == foo { start_thermo_nuclear_war(); }
else if 19 == foo { refund_lotso_money(); }
else if 16 == foo { infinite_loop(); }
else { cry_cause_im_lost(); }
```

In the above example what do 22 and 19 mean? If there was a number change or the numbers
were just plain wrong how would you know? Instead of magic numbers use a real name that
means something. You can use constants as names. For example:

```rust
pub const PRESIDENT_WENT_CRAZY: usize = 22;
const WE_GOOFED: usize= 19;
const THEY_DIDNT_PAY: usize = 16;

if PRESIDENT_WENT_CRAZY == foo { start_thermo_nuclear_war(); }
else if WE_GOOFED == foo { refund_lotso_money(); }
else if THEY_DIDNT_PAY == foo { infinite_loop(); }
else {
happy_days_i_know_why_im_here(); }
```

Now isn't that better? The const option is preferable because when debugging the
debugger has enough information to display both the value and the label.

### Error Return Check Policy

* Never use `unwrap` on **Result**. If the type is *Err*, it will panic and crash the program. The only exception is if it has already been checked for error previously or in test code.
* Never use `unwrap` on **Option** for the same reason if the type is *None* as **Result** is *Err*.

## References

Adapted from [http://www.possibility.com/Cpp/CppCodingStandard.html](http://www.possibility.com/Cpp/CppCodingStandard.html) and NetBSD's style guidelines

repository: lukegalbraithrussell/website

branch_name: refs/heads/production

repo_name: lukegalbraithrussell/website


text:
## 🚀 Quick start

1.  **Install the Gatsby CLI.**

    Clone this repo

2.  **Create a Gatsby site.**

    Navigate into repo and install required packages.

    ```sh
    yarn install
    ```

3.  **Start developing.**

    Start it up.

    ```sh
    gatsby develop
    ```

4.  **Open the source code and start editing!**

    Your site is now running at `http://localhost:8000`!

    *Note: You'll also see a second link: `http://localhost:8000/___graphql`. This is a tool you can use to experiment with querying your data. Learn more about using this tool in the [Gatsby tutorial](https://www.gatsbyjs.org/tutorial/part-five/#introducing-graphiql).*

## 💫 Deploy
    WIP

repository: topicfly/topicfly-gatsby-site

repo_name: topicfly/topicfly-gatsby-site


text:
Alastair Blake Campbell
=======================

<EMAIL_ADDRESS>
*(+44) 7470 755430*

*Dumfries, Scotland*

Experience
----------

### Dayshape - 2022 - Present

#### Senior Software Engineer

### Bibliographic Data Services - 2012 – 2022

#### Technical Lead, 2020 - 2022

#### Systems Analyst / Programmer, 2015 – 2020

I worked as part of a team developing software to accomplish widely varied tasks, such as MVC Web Applications, Desktop and Mobile Apps, Console/Service Applications, Databases, and more, using a wide array of technology. Primarily I worked with C#, JavaScript/jQuery, JSON, XML, HTML, CSS and Microsoft SQL, but I additionally did a lot of development work with PHP and MySQL. This role also included a lot of server operations work, so I am very comfortable performing administrative tasks on both Windows and Linux servers. Major tasks included:

* Development and maintenance of the company's various APIs, including a REST API.
* Development and maintenance of one of the company's flagship web applications, a responsive (using Bootstrap) web front-end to their books database.

#### IT Infrastructure Technician, 2012–2015

As an IT Infrastructure technician at the company I planned and implemented many IT
infrastructure solutions, including creating a new FTP site, a new Exchange
organization, the recreation of the company's Active Directory domain, management
of their DNS servers, firewalls and other network infrastructure.

### Alchemist Technologies, Ltd. (2010)
#### Trainee IT Support Engineer (Summer job)

I worked alongside other engineers, attending customers on site or diagnosing
hardware and software issues at our workshop. I performed tasks such as
identifying and replacing faulty hardware components, diagnosing and fixing
issues with software/operating system configurations and similar.

Education
---------

### University of the West of Scotland (2013-2015)
* Attained a BSc in Computing with Distinction
* Won the *Court Medal* for being the best student across all campuses.

### Dumfries & Galloway College (2011-2013)
* Attained an A in HND Computing (Technical Support)
* Attained *Microsoft Certified Professional* status in Desktop Support (MCDST).

### Dumfries Academy (2006-2011)
* Attained five Highers, including an A in English and Information Systems.

Other Technical Experience
--------------------------

**Athena**, a club management system
	I wrote a database/system for use by my local board games club to track
	membership, events, payments, and so on. The project was written in php,
	with a MySQL backend database.

Core Skills/Programming Languages
---------------------------------

**C#:** I have worked extensively with C#, both professionally and as a
		hobby, developing everything ranging from business applications,
		to games, from web forums to simple web servers. I am additionally
		very experienced with the .NET framework and popular NuGet extensions.

**Web**: I have been developing websites and web applications both recreationally and professionally for many years, with a wide array of skills and competencies. I've developed REST API applications and integrated external APIs into other applications. Some of my skills include:
* HTML, JavaScript, CSS
* PHP, ASP.Net, Visual Basic
* MySQL/MariaDB, Microsoft SQL, Firebase, Postgres
* XML, JSON, YAML
* Apache, Microsoft IIS, nginx, Lighttpd

Basic knowledge of **C**, **C++**, **x86 assembly**, **Python**, **rust**...

Other skills/experience
-----------------------

* Human Languages:

     * English (native speaker)
     * Norwegian, basic knowledge

* I am a touch typist and have a typing speed of around 100 words per minute.

* I am very experienced with *Vi* and know how to use *LaTeX*.


text:
Adapted from [mmcv](https://github.com/open-mmlab/mmcv)
====

Introduction
------------

`mmcv` is a foundational python library for computer vision research and supports many
research projects in MMLAB, such as [mmdetection](https://github.com/open-mmlab/mmdetection).

It provides the following functionalities.

- Universal IO APIs
- Image processing
- Video processing
- Image and annotation visualization
- Useful utilities (progress bar, timer, ...)
- PyTorch runner with hooking mechanism
- Various CNN architectures

See the [documentation](http://mmcv.readthedocs.io/en/latest) for more features and usage.

repository: hust-nj/torchcv

repo_name: hust-nj/torchcv


text:
# GoalTracker

[GoalTracker](https://goal-tracker-node.herokuapp.com) is an app that quantifies
your life goal and keeps track of your progress. It automatically breaks a long-term
goal into small pieces based on the time period assigned by user. It's built with
Node.js, Express, Bootstrap, jQuery, JSX and PostgreSQL.

## Getting Started

These instructions will get you a copy of the project up and running on your local
machine for development and testing purposes. See deployment for notes on how to
deploy the project on a live system.

### Prerequisites

- Install [Node.js](https://nodejs.org/en/).
- Install [Postgresq.app](https://postgresapp.com/).
- Create a [Cloudinary](https://cloudinary.com/) account.

### Installing

Create a `.env` file at the project root directory, and add your Cloudinary credentials.

```bash
CLOUDINARY_CLOUD_NAME=<username>
CLOUDINARY_API_KEY=<api_key>
CLOUDINARY_API_SECRET=<api_secret>
```

Install all the dependencies:

```bash
cd goal-tracker
npm install
```

Run the app in the development mode at localhost:3000.

```bash
cd codacity
npm start
```

## Deployment

These instructions will get the app up and running on Heroku.

### Setup Heroku

Make sure you have an account with [Heroku](https://www.heroku.com/) and have installed
the [Heroku CLI](https://devcenter.heroku.com/articles/heroku-cli). Choose a region.

Login with Heroku credentials:

```bash
$ heroku login
Enter your Heroku credentials.
Email<EMAIL_ADDRESS>Password (typing will be hidden):
Authentication successful.
```

### Deploy

Create a Heroku app via the command line:

```bash
cd goal-tracker
heroku create
```

Add, and commit all your data to git. Then push it to Heroku:

```bash
git push heroku master
```

Add [Heroku Postgres](https://elements.heroku.com/addons/heroku-postgresql) as an add-on.

## Contributing

When contributing to this repository, please first discuss the change you wish to
make via issue, email, or any other method with the owners of this repository
before making a change.

## License

This project is licensed under the MIT License - see the [LICENSE](LICENSE) file for details.

repository: ChloeLiang/goal-tracker

gha_language: JavaScript

repo_name: ChloeLiang/goal-tracker


text:
---
title: OnClientFilesSelected
page_title: OnClientFilesSelected - RadAsyncUpload
description: Check our Web Forms article about OnClientFilesSelected.
slug: asyncupload/client-side-programming/onclientfilesselected
tags: onclientfilesselected
published: True
position: 6
---

# OnClientFilesSelected

##

The **OnClientFilesSelected** client-side event occurs when files(s) are selected. This event can be cancelled, which will erase the selectedfiles collection.

The event handler receives two parameters:

1. The instance of the **RadAsyncUpload** control firing the event.

1. An eventArgs parameter containing the following methods:

* **get_count** returns the count of the selected files.

* **set_cancel** lets you cancel the event and prevent items from being uploaded

````ASPNET
<telerik:RadAsyncUpload RenderMode="Lightweight" runat="server" ID="RadAsyncUpload1" OnClientFilesSelected="OnClientFilesSelected" MultipleFileSelection="Automatic"></telerik:RadAsyncUpload>
````

````JavaScript
function OnClientFilesSelected(sender, args) {
	var selectedFilesCount = args.get_count();
	alert(selectedFilesCount);
}
````

repository: telerik/ajax-docs

gha_language: C#

repo_name: telerik/ajax-docs


text:
# ohirstar-scaleheight-lifetime

This ohirstar-scaleheight-lifetime module helps you estimate a plausible scale height and lifetime of stars.

The code was written during the investigation of the OH/IR stars distribution in the Galaxy ([Uno et al. 2020](https://academic.oup.com/mnras/advance-article/doi/10.1093/mnras/stab176/6108287?login=true)).

Try this code in your browser [here (Google Colaboratory).](https://colab.research.google.com/drive/1MtCiW11kbxC2BP3PPa9X6WEXfYcQ2Mf9)

## Requirements
The code was implemented on python3.7 and it uses the following python liblalies.
- numpy
- matplotlib
- scipy
- pylab
## Setup
**package installation**

`pip install ohirstar-scaleheight-lifetime`

or

`pip install git+https://github.com/yuriuno/ohirstar-scaleheight-lifetime.git`

## Data analysis

### 1. Scale height
#### 1.1 Construct a simple Galactic disk model
```
import numpy as np
import matplotlib.pyplot as plt
from pylab import rcParams
from mpl_toolkits.mplot3d import Axes3D
from scipy import stats
# import ohirstar_scaleheight_lifetime.ohirstar_scaleheight_lifetime as sl * try
import ohirstar-scaleheight-lifeitme.ohirstar-scaleheight-lifetme as sl

sh            = sl.ScaleHeight()
NUMBER        = 3990
SCALE_LENGTH  = 22   # kpc *exponential disk model
SCALE_HEIGHT  = 0.15 # kpc *gaussian (simplified sech z^2 disk model)
DIST_FUNC     = {'scale_length':SCALE_LENGTH, 'scale_height':SCALE_HEIGHT}
KINE_DIST     = 'near' # 'near' or  'far' * luminosity function based on near/far kinematic distance
DETECTION_LIM = 0.122 # Jy   *SPLASH detection limit is 0.065 * 3 sigma
mxyz, mlb, mflux = sh.model(DIST_FUNC, NUMBER, KINE_DIST)
```

#### 1.2 Evaluate your model using K-S test

```
DATA   = np.load('./data/stat') # datatype: numpy strings
# DATA format: name, longitude, latitude, radial-velocity, expansion-velocity, velocity-uncertainity, flux-density, size, spot_num
REGION  = [{'l':[-28, -4], 'b':[-1.25, 1.25]},{'l':[4, 10], 'b':[-1.25,1.25]}, {'l':[14.35, 67.25], 'b':[-1.25,1.25]}] # specify the feild where you are evaluating
# dlb: np.array([l,b])
dlb     = np.array([[float(i) for i in DATA[1]],[float(i) for i in DATA[2]]])
p_value = sh.pvalue(dlb, mlb, mflux, DETECTION_LIM, REGION)
print(format(p_value,'.3f'))
>>> '0.531'
```

#### 1.3 Quick visualization of the constructed model.
```
# 3D(X,Y,Z) [kpc]
sh.visualize(mxyz, mflux)
```

```
# 2D(l,b) [deg]
sh.visualize(mlb, mflux)
```

### 2. Lifetime
#### 2.1 A most plausible lifetime
Lifetime of transient phenomenon such as the duration of OH masers associated with evolved stars

can be estimated by consideing the probability
of detecting *m* dissapeared maser sources in *n* samples in
a given amount of time; *dT* as demonstrated by [Engels and Jimenes-Esteban (2007)](https://arxiv.org/pdf/0710.1697.pdf).

For example if you have *m*=3 maser sources vanished in *n*=100 samples after *dT*=10 years, you will get the most prausible lifetime ~300 years.
```
import numpy as np
from scipy.special import comb
import ohirstar-scaleheight-lifetime.ohirstar-scaleheight-lifetime as sl

M    = 30
N    = 445
DT   = 20
SPAN = 1000
lt   = sl.LifeTime(M,N,DT,SPAN)
lifetime = lt.lifetime()
print(format(lifetime,'.1f'))
>>> '296.7'
```
#### 2.2 Upper limits of a lifetime
Meanwhile, the upper limit of OH maser lifetime

with different significance levels can be estimated as follows

The upper limits for lifeitme of OH masers assuming at least *m*=3 maser sources vanish in

*n*=100 samples in *dT*=10 years will be 505, 1258, 2000 years depending on significance levels (1, 2, 3σ).

```
lifetime_upper_limit = lt.upper_limit()
print(lifetime_upper_limit)
>>> [326.90000000000435,<PHONE_NUMBER>0000555,<PHONE_NUMBER>00007] # 1 sigma, 2 sigma, 3 sigma
```
#### 2.3 Quick visualization of the probability distribution
```
#  Pnm
xscale = 'linear'
type   = 'lifetime'
lt.visualize(xscale,type)
```

```
# Qnm
xscale = 'linear'
type   = 'upper_limit'
lt.visualize(xscale,type)
```

repository: yuriuno/ohirstar-scaleheight-lifetime

repo_name: yuriuno/ohirstar-scaleheight-lifetime


text:
# Ternary Operator

Rust doesn't support `return (condition) ? if_true : if_false;`. This crate exports a macro that implements this feature.

```rust
fn is_ipv4(val: &str) -> i32 {
    ternary!(val == "ipv4", 4, 16)
}
```

If you just want to copy the small macro, here you go 😅

```
#[macro_export]
macro_rules! ternary {
    ($condition: expr, $_true: expr, $_false: expr) => {
        if $condition { $_true } else { $_false }
    };
}
```


text:
# Class 03

## Learning Objectives
1. The student will be introduced and implement the FileStream.
1. The student will know how to Create, Read, Update, and Delete file using the FileStream.
1. The student will know how to properly open and close a file from an external location.

## Lecture Outline

### System IO Library
 - What is it?
 - Why do we use it?

#### Writing a file

```csharp
string myInfo = "I want to write all of this to a file";
File.WriteAllText("/path/to/file.txt", myInfo);
```

```csharp
string[] myArray = new string[2];
myArray[0] = "My first line of information";
myArray[1] = "My second line of information";

File.WriteAllText("/path/to/file.txt",myArray);
```

#### Reading a file

 ```csharp
string[] myFile = File.ReadAllLines("/path/to/file.txt");
```

```csharp
string myFile = File.ReadAllText("/path/to/file.txt");
```

#### Creating a file
(Check out the demo. There are 2 different ways to achieve this!)

#### Deleting a file

To delete a file, just tell the library to delete the location by inputting the path.

```csharp
File.Delete(path);
```

## File Stream
 - What is a stream?
	1. StreamReader
	1. StreamWriter

## File Types
- CSV
- Text
- Binary


text:
# Contributors

| <b>Name      | Github profile                                  | Technology you work on</b> |
| ------------ | ----------------------------------------------- | -------------------------- |
| Bhumij Gupta | [bhumijgupta](https://github.com/bhumijgupta)   | NodeJS, Python             |
|              |                                                 |                            |
| Madhur Dixit | [Chester-King](https://github.com/Chester-King) | Android, Puppeteer, AR     |
|              |                                                 |                            |


text:
---
title: Maker Faires & Maker Fests
keywords:
tags: need_content
sidebar: home_sidebar
permalink: /hosting_making/maker_faires_maker_fests
summary: THIS IS A TEMPLATE, PLEASE UPDATE :)
---

Maker Faires & Maker Fests tend to be large-scale events, often multiple days, and may host dozens or even hundreds of makers. Sometimes these events are free, and sometimes tickets must be purchased by attendees.

## What is the difference between a Maker Faire and a Maker Fest?

To organize a Maker Faire, you must have a [signed licensing agreement](https://makerfaire.com/global/guidelines/) with [Make:](https://make.co/). There is no license required for a _Maker Fest_, as Maker Fest is a generic term that some event organizers use if they are unable to license the name Maker Faire, or choose not use the name Maker Faire. (If you ask a Maker Fest organizer what their event is like, they'll often say "It's like a Maker Faire!")

repository: nationofmakers/maker-event-playbook

gha_language: CSS

repo_name: nationofmakers/maker-event-playbook


text:
---
title: 'new project - celero.io'
date: 2014-01-03T23:31:49+00:00
layout: post
tags:
  - celero.io
---
Finally a new project going live. Here a short intro on what it is all about.

I read a lot of blogs to keep up to date with all the different technologies I need for my work. Further to that, I used a lot of open source projects, which I need to follow, to keep up with new releases. For all that information gathering I just cycle through all kinds of blogs, github and freecode sites to gather the necessary info.

After a while, I was looking around to find something more automated, to get update notifications for these different sources. I found a few RSS-feed aggregators which had this feature for feeds, but most of them cost quite a lot (at least in cost per notification, which are rather few in my case). Also, they only can be applied to RSS-feeds and nothing else.

Hence missing alternatives, I tried to build it myself. What I came up with is a simple site, which takes an URL and tries to figure out, whether there is a way to attach to this source, so notifications can be emitted. Basically, when the site provides an API (or even RSS), it is possible to parse it programatically. So most of the heavy lifting should be hidden by the simplified UI.

In case this sounds interesting to you, just try it out.

celero.io


text:
---
title: Urban chickens
slug: urban-chickens
date: 2008-09-07
notoc: true
noread: true
socialsharing: true
categories:
- Earth
- Food

---
[Eating Locally: Backyard Chickens][treehugger] at [Treehugger.com][treehugger 2].
Keeping chickens in the urban backyards was commonplace in Australia during the depression and war years and is making a welcome comeback.  I have tried and it takes some getting used to!. Having the chooks for eggs alone is the easier route and very worthwhile as we have posted about [before][slowlane].

[slowlane]: http://williampickup.org/blog/healing-power-of-chooks/
[treehugger]: http://www.treehugger.com/files/2008/09/eating-locally-urban-chickens.php
[treehugger 2]: http://www.treehugger.com/


text:
[< Previous](https://github.com/tonymontaro/leetcode-hints/tree/master/problems/minimum-swaps-to-group-all-1s-together "Minimum Swaps to Group All 1's Together")

[Next >](https://github.com/tonymontaro/leetcode-hints/tree/master/problems/string-transforms-into-another-string "String Transforms Into Another String")

## [1152. Analyze User Website Visit Pattern (Medium)](https://leetcode.com/problems/analyze-user-website-visit-pattern "用户网站访问行为分析")

### Related Topics
  [[Sort](https://github.com/tonymontaro/leetcode-hints/tree/master/tag/sort/README.md)]
  [[Array](https://github.com/tonymontaro/leetcode-hints/tree/master/tag/array/README.md)]
  [[Hash Table](https://github.com/tonymontaro/leetcode-hints/tree/master/tag/hash-table/README.md)]

### Hints

Hint 1
Let's find for every user separately the websites he visited.

Hint 2
Consider all possible 3-sequences, find the number of distinct users who visited each of them.

Hint 3
How to check if some user visited some 3-sequence ?

Hint 4
Store for every user all the 3-sequence he visited.

repository: tonymontaro/leetcode-hints

repo_name: tonymontaro/leetcode-hints


text:
# ocprometheus

This is a client for the OpenConfig gRPC interface that pushes telemetry to
Prometheus. Numerical and boolean (converted to 1 for true and 0 for false) are
supported. Non-numerical data isn't supported by Prometheus and is silently
dropped. Arrays (even with numeric values) are not yet supported.

This tool requires a config file to specify how to map the path of the
notificatons coming out of the OpenConfig gRPC interface onto Prometheus
metric names, and how to extract labels from the path.  For example, the
following rule, excerpt from `sampleconfig.yml`:

```yaml
metrics:
        - name: tempSensor
          path: /Sysdb/environment/temperature/status/tempSensor/(?P<sensor>.+)/(?P<type>(?:maxT|t)emperature)/value
          help: Temperature and Maximum Temperature
          # ...
```

Applied to an update for the path
`/Sysdb/environment/temperature/status/tempSensor/TempSensor1/temperature/value`
will lead to the metric name `tempSensor` and labels `sensor=TempSensor1` and `type=temperature`.

Basically, named groups are used to extract (optional) metrics.
Unnamed groups will be given labels names like "unnamedLabelX" (where X is the group's position).
The timestamps from the notifications are not preserved since Prometheus uses a pull model and
doesn't have (yet) support for exporter specified timestamps.
Prometheus 2.0 will probably support timestamps.

## Mapping Metric String value into gauge
```yaml
subscriptions:
        - /Sysdb/interface/status
metrics:
        - name: linkStatus
          path: /Sysdb/interface/status/eth/phy/slice/1/intfStatus/(?P<interface>.+)/linkStatus
          defaultvalue: 2
          transformmetric: true
          transformvalues:
          linkUp: 1
          linkDown: 2
```
If we get metric with string value eq. **linkUp** we set metric value to **1**. If **no mapping** then **defaultvalue** is a metric value.

It allows us to remove meaningless metrics (with a random metric value) like:
```
linkStatus{instance="router01",interface="Ethernet26/1",job="edge_switch"}	3
linkStatus{instance="router01",interface="Ethernet27/1",job="edge_switch"}	144
linkStatus{instance="router01",interface="Ethernet28/1",job="edge_switch"}	10
```
## Usage

See the `-help` output, but here's an example to push all the metrics defined
in the sample config file:
```
ocprometheus -addr <switch-hostname>:6042 -config sampleconfig.json
```

repository: mmogylenko/goarista

gha_license_id: NOASSERTION

repo_name: mmogylenko/goarista


text:
# Contibuting to SecondConscience
   Welcome to SecondConscience, a cyber bullying deterrence software.

## Short Links to Important Resources:
* Bugs: Please report all bugs as issues on Git
* Communcations: Please reference the CONTRIBUTORS.md, and reach out to the team via email.

## Testing
### Development environment details
The simulation is set up for the newest version on Android Studio.
### How to submit changes:
Please submit a Pull Request when you would like to submit changes.
### How to report a bug:
* Templates:
  * _What to include in a bug report_

    * The bug (what you expected to see and what actually happened)
    * What file it is in
    * The suspect line numbers.

## Code of Conduct
We ask that you respect the code we have written and add any changes that follow the mission the project has.

## Recognition Model
Once a significant contribution is made, we will add you to the CONTIRBUTORS.md page.

## Where can I ask for help?
Please email any of the team members for help.


text:
  Dark Theme Sample

 ReactJS application created for studying dark theme with/ styled-components

## Tech

- React
- TypeScript
- Styled-Components

### Front-End
- Run `yarn` in the `frontend` folder to install all dependencies;
- Run `yarn start` to up the project;

# License
[MIT License](/LICENSE)


text:
# Shop

Namespace: ``MscModApi.Shopping``

## SpawnLocation
?> A collection of predefined spawn locations you can use
> Teimo
> > SpawnLocation.Teimo.Backroom = new Vector3(-1551.568f, 5f, 1186.132f),
> > SpawnLocation.Teimo.Counter = new Vector3(-1551.135f, 5f, 1182.754f),
> > SpawnLocation.Teimo.Outside = new Vector3(-1553.865f, 4f, 1182.825f),
>
> Fleetari
> > SpawnLocation.Teimo.Backroom = new Vector3(1558.975f, 5.2f, 741.894f),
> > SpawnLocation.Teimo.Counter = new Vector3(1555.082f, 6f, 737.622f),
> > SpawnLocation.Teimo.Outside = new Vector3(1552.154f, 5f, 732.755f),

## Add
> The main function to be used.
> This adds a [ShopItem](class-documentation/Shopping/ShopItem.md) to the shop system.
> > | Parameter | Description
> > | --------- | -----------
> > | baseInfo | the base info used internally
> > | shopLocation | enum in which shop the item should be purchasable
> > | shopItem/s | the [ShopItem](class-documentation/Shopping/ShopItem.md) object's to add to the shop
> > Adds multiple shop items at once.
> > ```csharp
> > public static void Add(ShopBaseInfo baseInfo, ShopLocation shopLocation, ShopItem[] shopItems)
> > ```
> > Adds a single shop item.
> > ```csharp
> > public static void Add(ShopBaseInfo baseInfo, ShopLocation shopLocation, ShopItem shopItem)
> > ```


text:
# Scripts for measurements

These scripts were used for measurements in [this](https://tanaikech.github.io/2016/10/13/improved-algorithms-for-summation-of-array-elements/) and [this](https://tanaikech.github.io/2016/10/13/effects-on-optimized-codes-of-pyramid-method/) report. Please check these reports if you use these scripts.

## Licence

[MIT](LICENCE)

## Author

[TANAIKE](https://github.com/tanaikech)


text:
## CGI doc string reader
Originally published: 2009-07-20 07:09:51
Last updated: 2010-04-13 14:06:06
Author: Timothy Makobu

Displays docstrings of attributes of the given Python module on a web browser.
Drop it into the cgi-bin of your web-server, and access it like this,
for example:

http://localhost/cgi-bin/cgidir.py?m=socket


text:
---
title: Prisms
section: guides
order: 3
---

In the previous guide, introducing [Lenses][lenses] and their basic motivations, we saw ways of working with very predictable data structures. All of the types were guaranteed to be present and correct, and our composition of lenses to focus deep in to a data structure was sure to succeed.

In the real world though, it's possible to have data structures which aren't quite so simple to work with.

Consider the following pair of types:

```ocaml
type RecordA =
    { B: RecordB option }

 and RecordB =
    { Value: string }
```

They're quite familiar from our exploration in [Lenses][lenses], except for one detail -- the property of B in RecordA is an *option* of RecordB.

## Lens Problems

Let's see what's wrong with just using simple lenses now, by adding lenses to our types.

```ocaml
type RecordA =
    { B: RecordB option }

    static member B_ =
        (fun a -> a.B), (fun b a -> { a with B = b })

 and RecordB =
    { Value: string }

    static member Value_ =
        (fun b -> b.Value), (fun value b -> { b with Value = value })
```

We've got lenses that look correct, but what happens when we try and compose them to get from RecordA to Value?

```ocaml
(* Fails to type check! *)
let avalue_ =
    RecordA.B_ >-> RecordB.Value_
```

We've got a lens from RecordA to a RecordB option, but a lens from a RecordB to a string -- the types won't match up. This is clearly not going to work as it is.

## Enter Prisms

Prisms work with cases like this. A simple way to put it is that a prism is like a lens, but to something which *is* or *is not* there. In this case, because the type is optional, but we'll see some other common cases shortly.

So what does a prism look like? Well, here are the types of Lens and Prism:

```ocaml
(* Lens from 'a -> 'b. *)
type Lens<'a,'b> =
    ('a -> 'b) * ('b -> 'a -> 'a)

(* Prism from 'a -> 'b. *)
type Prism<'a,'b> =
    ('a -> 'b option) * ('b -> 'a -> 'a)
```

They're very similar indeed -- except that the getter in the prism returns an option of 'a, rather than a simple 'a. Now we can write logic which will compose prisms, which is slightly different to composing lenses.

Here are our types again, now with a prism provided instead of a lens on RecordA, and type signatures:

```ocaml
type RecordA =
    { B: RecordB option }

    (* Prism<RecordA,RecordB> *)
    static member B_ =
        (fun a -> a.B), (fun b a -> { a with B = Some b })

 and RecordB =
    { Value: string }

    (* Lens<RecordB,string> *)
    static member Value_ =
        (fun b -> b.Value), (fun value b -> { b with Value = value })
```

We can see that we've modified B_ to return the option value in the getter, but to take a normal value in the setter, so we conform to the type of Prism.

Now here's our composition again, with the type signature:

```ocaml
(* Prism<RecordA,string> *)
let avalue_ =
    RecordA.B_ >?> RecordB.Value_
```

We've composed a prism (on the left) with a lens, and returned a new prism.

__Note:__ We've used a new operator here for composition. The >?> operator is the equivalent to the >-> operator, but works when composing a prism on the left hand side, instead of a lens.

Now we can start to get an intuition for how this new prism will behave.

```ocaml
(* Returns Some "Hello World!" *)
let a1value =
    Optic.get avalue_ a1

(* Returns None *)
let a2value =
    Optic.get avalue_ a2

(* Sets the Value to Goodbye World! *)
let a1' =
    Optic.set avalue_ "Goodbye World!" a1

(* Value is not set, as B is None *)
let a2' =
    Optic.set avalue_ "Goodbye World!" a2
```

We can see that we actually gain something here -- a quick and type checked way to work with more complex data structures, where we may not have such predictable data. The behaviour is quite straightforward, and composition still works, even though we're using lenses and prisms.

__NOTE:__ From this point on we are likely to use the term "optics" to collectively refer to either lenses or prisms.

## Examples

We've seen that a prism is a good match for the obvious example -- where the value is literally an option.  Here are a few places (and this is certainly non-exhaustive) where prisms are the natural answer.

### Union Types

Prisms are applicable to all union types (Option is a union type of course, with cases Some and None). How we would we write prisms for a custom union type of our own?

```ocaml
type MyUnion =
    | First of int
    | Second of string

    (* Prism<MyUnion,int> *)
    static member First_ =
        (fun m ->
            match m with
            | First i -> Some i
            | _ -> None),
        (fun i m ->
            match m with
            | First _ -> First i
            | m -> m)
```

Here we've written a prism to the value of MyUnion when the case is First. Our getter is simple, converting the case of First to Some and any other case to None. Our setter however is more complicated. We only set the value of the First case if the Union was the First case to begin with -- otherwise we are structurally altering our MyUnion instance, and not just the *content* of the MyUnion First case instance.

__NOTE:__ This is what we would consider a *well-behaved* prism. For more on the behaviour expected of both lenses and prisms, see the guide to [Laws][laws]. The prism we saw in our first RecordA example was not well-behaved, but was written simply to help first understanding. Here is the well-behaved version of that prism, such that the outer option type is not changeable through the use of the prism:

```ocaml
type RecordA =
    { B: RecordB option }

    (* Prism<RecordA,RecordB> *)
    static member B_ =
        (fun a -> a.B),
        (fun b a ->
            match a with
            | a when a.B.IsSome -> { a with B = Some b }
            | a -> a)
```

Our previously intuited behaviour remains the same however -- correctly.

### Lists

Working with lists is also an excellent candidate for prisms. The elements we consider to be part of a list (head and tail) are either there or not, and thus can be defined through prisms. An item at an indexed position within a list is also either present or absent, so can also be expressed as a prism.

Here are some appropriate (generic) prisms for lists. (These are provided as part of Aether -- see the [Reference][reference] section for provided lenses, prisms, etc.)

```ocaml
(* Prism<'a list,'a> *)
List.head_

(* Prism<'a list,'a list> *)
List.tail_

(* int -> Prism<'a list,'a> *)
List.pos_
```

## Further

We've seen that prisms can be a very useful approach to dealing with uncertainty in data structures, and the basics of writing our own prisms. There is of course still more to Aether, but we now have -- in the combination of lenses and prisms -- some powerful tools with which to work on data. These tools are general and predictable, and hopefully readily accessible when using Aether.

Next steps: [Morphisms][morphisms].

Relevant reference: [Aether][aether] and [Aether.Operators][aether.operators].

<!--- Local --->

[lenses]: /aether/guides/lenses.html
[morphisms]: /aether/guides/morphisms.html
[laws]: /aether/guides/laws.html
[reference]: /aether/reference
[aether]: /aether/reference/aether.html
[aether.operators]: /aether/reference/aether.operators.html

branch_name: refs/heads/gh-pages


text:
#COMP-CO858 Course Schedule

## From the Outline

Review and discuss general management concepts and current IT management issues using current resource materials. Identify the ways to improve quality and increase value through systems, models and measurements designed to assist the IT manager. Research and report on major issues and develop software based models for the metrics studied. Study and determine practical solutions for a number of situational management problems that require the integration of previous academic and work experience. Examine, comprehend and critically assess the computer decision situations confronting IT managers.

##Deliverables

There is no midterm or final exam for this course. Instead deliverables are based on the analysis of 5 management situations, 2 virtual labs in which students deal with a scenario in an online meeting, production and analysis of a survey, a panel discussion, the creation of a modelling tool to better understand the management of a CAPSTONE project and 2 blended (take home) quizes.

|Week/Date Starting|Topic|Deliverables|
|----|---|---
|1/January 11|IT Management Introduction|**Situation 1** (individual 2.5%, due January 15)|
|2/January 18|Management and Managing|**Situation 2** (individual 2.5%, due January 22)|
|3/January 25|CIO|**Situation 3** (individual 2.5%, due January 29)|
|4/February 1|Management Types||
|5/February 8|IT Management Planning|**Situation 4** (individual 2.5%, due February 12)|
|6/February 15|End User Computing|**Virtual lab 1** (group 10%, due February 19)|
|7/February 22|The Modern Company||
|Reading Week|||
|8/March 7|Software Metrics 1|**Blended Quiz 1 - Review up to midterm** (individual 10%, due March 11) **Virtual lab 2** (group 5%, due March 11)|
|9/March 14|Software Metrics 2 and Function Points||
|10/March 21|Surveys and Metrics|**Survey Report and Graph** (group 15%, due March 25)|
|11/March 28|Panel Discussions|**Panel Discussion** (group 15%, last panel discussion to be scheduled in lab time, by 2pm on March 31)|
|12/April 4|ERP Software and Business|**Situation 5 (ERP)** (group 5%, due April 8th), **Survey Presentation** (group 15%, last survey presentation to be scheduled in lab time, by  2 pm April 7th)|
|13/April 11th|Quality|**Blended Quiz 2** (individual 10%, due April 15), **Metric Modeler** (individual 4%, due April 15), **Metric Modeler Presentation** (group 16%, last metric modeler presentation to be scheduled in lab time, by 2pm on April 14)|
|14/April 18th|Software Costing||

*Note Due times are 11:59 pm on the day specified.


text:
# YACHACK_OPENCV

## Getting started

Code in Python, for the operation of a 4WD or 2WD robot, using OPENCV, in [Control P(kp)](https://github.com/BrianBot24/YACHACK_OPENCV/blob/main/Kp_line.py) and [Control PID.](https://github.com/BrianBot24/YACHACK_OPENCV/blob/main/Line_Follower.py)

### INSTALL WEBCAM
Visit Link: [Using a standard USB webcam](https://www.raspberrypi.org/documentation/usage/webcams/)

### INSTALL WEBCAM UVC
Execute in Terminal:

_sudo rmmod uvcvideo_

_sudo modprobe uvcvideo quirks=2_

### YOU WILL NEED
+ Raspbery Pi 3B+ or Superior
+ WebCAM
+ CHASIS 4WD or 2WD
+ TB6612fng or other Bridge H
+ Motors 4 or 2
+ REG 1117 +3.3V
+ Battery

### HOW THE CONTROL PID WORKS

The algorithm was conducted similar to that of a follower line with sensors IR.

+ cx is point Green = 466 (code line 24 - Line_Follower.py)
+ middleX is point Red = 620 (code line 29 - Line_Follower.py)

error=cx-middleX (code line 35 - [Line_Follower.py](https://github.com/BrianBot24/YACHACK_OPENCV/blob/main/Line_Follower.py))

error = 466-620

error = -154

Execute PID TEST, replacing the values of cx and middleX [PID TEST](https://github.com/BrianBot24/YACHACK_OPENCV/blob/main/PID_TEST.py)

LEFT MOTOR SPEED  = 82.08

RIGTH MOTOR SPEED = 57.91


text:
# CacheFS

Cache Filesystem for PHP.

This package is made from code included in
[Ron Shpasser's GAE Support for Lumen Library](https://github.com/shpasser/GaeSupportLumen)
(Released under the [MIT License](https://github.com/shpasser/GaeSupportLumen/blob/master/LICENSE)).

# Installation

`composer require vector88/cachefs`

# Usage

1. Register the `cachefs` stream handler.
   ```php
   <?php

   \Vector88\CacheFS\CacheFS::register();
   ```

2. Use the `cachefs` stream handler.
   ```php
   <?php

   $fh = fopen( 'cachefs://some/file', 'w' );
   fwrite( $fh, 'file content' );
   fclose( $fh );

   // ...

   $fh = fopen( 'cachefs://some/file', 'r' );
   $content = fread( $fh, filesize( 'cachefs://some/file' ) );
   fclose( $fh );
   ```

repository: vector-kerr/cachefs

repo_name: vector-kerr/cachefs


text:
# Enter visual mode

Each command will enter visual mode after the action is done.

Once in visual mode, you can navigate the same as normal mode.

## Character

Select character at cursor.
: `v`

Select word from any character.
: `viw`

Select to end of word.
: `ve`

## Visual Line (row)

Select current line.
: `V`
: `Shift+v`

## Visual Block (column)

If you enter insert mode (`a` or `i`) with a selection then your changes
will apply to each line at the selected column.

Select character at cursor.
: `Ctrl+v`


text:
# sgabios
serial graphics adapter bios - an option rom to provide legacy serial console for x86, plus my fixes

## changelog

### v1.0.0
* disabled initial output from oprom

repository: pcengines/sgabios

repo_name: pcengines/sgabios


text:
# Client-Server example.

This example shows a `Span` created by a `Client`, which will send a `Message`/`SpanContext` to a `Server`, which will in turn extract such context and use it as parent of a new (server-side) `Span`.

`Client.send()` is used to send messages and inject the `SpanContext` using the `TEXT_MAP` format, and `Server.process()` will process received messages and will extract the context used as parent.

```java
    public void send() throws InterruptedException {
        Message message = new Message();

        Span span = tracer.buildSpan("send")
            .withTag(Tags.SPAN_KIND.getKey(), Tags.SPAN_KIND_CLIENT)
            .withTag(Tags.COMPONENT.getKey(), "example-client")
            .start();
        try (Scope scope = tracer.activateSpan(span)) {
            tracer.inject(span.context(), Builtin.TEXT_MAP, new TextMapInjectAdapter(message));
            queue.put(message);
        } finally {
            span.finish();
        }
    }
```

repository: mmimica/opentracing-java

repo_name: mmimica/opentracing-java


text:
---
hrs_structure:
  division: '1'
  volume: '2'
  title: '7'
  chapter: '88'
  section: 88-192
type: hrs_section
tags:
  - Government
menu:
  hrs:
    identifier: HRS_0088-0192
    parent: HRS0088
    name: 88-192 Examination by physician
weight: 42945
title: Examination by physician
full_title: 88-192 Examination by physician
---
**§88-192 Examination by physician.** In connection with the consideration of any application for disability pension or review of the pension granted under this part, any county pension board may refer any applicant or person receiving the pension to any physician receiving a regular monthly salary or fee from the State or any of its political subdivisions for physical examination and report to the board thereon as to the existence or continuance of disability. Any physician to whom the application is referred shall make the necessary physical examination and report the physician's findings and recommendations to the board, but shall neither charge nor receive any fee for the particular examination and report. [L 1937, c 237, §6; am L 1939, c 112, §1(e); RL 1945, §6189; RL 1955, §6-171; [HRS §88-192](/title-7/chapter-88/section-88-192/); gen ch 1985]

repository: SamMade/BlueAndKrabby

repo_name: SamMade/BlueAndKrabby


text:
# Contributing

This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or contact [opencode<EMAIL_ADDRESS>with any additional questions or comments.

## Course Materials

This workshop presents two days of training of Microsoft R for Data Science, and one day of Spark training. It is therefore meant to be presented in a three-day format.

In the first two days, you'll learn about using open source R and Microsoft R for data science workflows. In the third day, you'll take what you learned from open source R and scalable Microsoft R, and deploy it to a production-ready HDInsight Spark cluster.

### Cloning the Materials

Note, this is the _delivery_ repository. This means that there is no content specific to this repository itself. All the content comes from _submodules_ in other git repositories. To clone this repository, and obtain all the submodules, please do the following from any terminal with `git`:

```
git clone --recursive https://github.com/Azure/learnAnalytics-mr4ds-spark.git
```

Alternatively, clone the barebone repository and then update

```
git submodule update --init --recursive
```

Submit issues and pull requests to the underlying submodule itself. For example, if you find an error in the Microsoft R for Data Science module, submit an issue [here](https://github.com/Azure/learnAnalytics-mr4ds/).


text:
# Desired Features for GitHub

I wish GitHub were better. While there's already a lot of cool tools I use to make it better - namely, [hub](https://github.com/github/hub), [git-extras](https://github.com/tj/git-extras), and [ghi](https://github.com/stephencelis/ghi) - there are still things that I want to change in the long run, or at least highlight as issues. This, like [isaac's github repo](https://github.com/isaacs/github) is a place to list those for myself.

_NB: Since this is a list that has no pretensions of anything but being a place to log issues, I may at times blatantly copy and paste from various blogs and stuff._

Issues with GitHub:
* Can only view diffs on a single page (can be very slow).
* Comments are sent as they are written; you cannot "draft" comments.
* Cannot compare differences between patch sets.
* To create a patch one must fork the repository publicly.
* Accepting a patch creates a "merge commit" (ugly repo history).
* In general, pull request culture is not about code review.

repository: RichardLitt/knowledge

repo_name: RichardLitt/knowledge