text:
# Conway Operators in python

[Conway Polyhedra](https://en.wikipedia.org/wiki/Conway_polyhedron_notation) are formed by applying various operators to a seed polyhedron such as one of the platonic solids.

from [Wikipedia](https://en.wikipedia.org/wiki/Conway_polyhedron_notation)

![conway operators](/images/conway_examples.png)

This repo includes python code *conway.py* to implement a subset of these operators.

The code is designed to be used with [Blender](https://www.blender.org/) and [Sverchok](https://github.com/nortikin/sverchok/) scripted nodes but the only dependency is Blender's mathutils library. This means the code can be run outside Blender using a [standalone version of the mathutils module](https://github.com/majimboo/py-mathutils).

## Usage Notes

Using the *conway.py*  module in Blender with Sverchok's *Scripted Node Lite*.
*  Install [Sverchok](https://github.com/nortikin/sverchok/) in [Blender](https://www.blender.org/).
*  Download the [zip file]() from github
*  Open *conway.py* as a text block in Blender.
*  Open *snl_plato.py* and *snl_conway_op.py*  as text blocks in Blender. These contain code for each Sverchok *Scripted Node Lite*.
*  In a *Node Editor* view create a new *Node Tree* and add two *Scripted Node Lite* nodes.
*  Use the notebook icon on the node to select *snl_plato.py* on the left node and *snl_comway_op.py* on the right node. Click the plug icon on each node to load the code.
* Wire up the nodes along with a *Viewer Draw* node as shown below.

![conway nodes](/images/conway_aD.png)

Wire up multiple copies of *snl_conway_op.py* in a row to produce more complex shapes.

![conway_aagD](/images/conway_aagD.png)

Two of the operators *kis* and *chamfer* can take parameters such as the height of the *kis* pyramid or the *height* and *thickness* of the *chamfer*. There is a separate *Scripted Node Lite* given for these two operators with sliders for the parameters.

Some operators, particularly *gyro*, *propellor* and *whirl* and *chamfer* give polyhedra that are not particularly smooth or convex, the faces may not be flat or symmetric.

![conway cgC](/images/conway_cgC.png)

The canonical form of a convex polyhedra has all faces planar and all edges tangential to the unit sphere. The centre of gravity of the tangential points is also at the centre of the same unit sphere.

The module *canon.py* contiains functions that attempt to shift the points of a polyhedron to satisfy these conditions. This is a iterative process and can take several hundred steps to converge.

To try this in Sverchok, add the *canon.py* and *snl_canon.py* files as text blocks in your Blender file and add *snl_canon.py* as a *Scripted Node Lite*. The node has two parameters *iterations* and *scale_factor*. At each iteration the vertices are moved a *scale_factor* fraction of the calculated distance. Setting this parameter too high may cause the shape to become unstable. Increasing the *iterations* will increase the calculation time.

![conway_CcgC.png](/images/conway_CcgC.png)

The canonicalization can also be applied after each operator. In the example below just enough iterations have been applied to form a pleasing shape. The proper canonical form of this polyhedra should be the same whether the canonicalization is performed once or twice.

![conway_CcCgC.png](/images/conway_CcCgC.png)

These Conway operators can be applied to any manifold (ie. a closed solid) mesh not just the platonic solids. They currently don't work on planar grids unless one applies a solidify node to the grid first.

![conway_kg_hexa_grid](/images/conway_kg_hexa_grid.png)

Other Sverchok nodes of course can be used interspersed with the Conway operators for other effects.

I've only implemented a subset of the operators defined on the Wikipedia page. Many of the operators are equivalent to a combination of other operators as shown in the chart

### Conversion chart
The operator order is given as the left to right node order. Note that this is the opposite to the order given in the Conway notation.

| Operator     | Description   | Implementation |
| :----------- | :------------ | :-----------   |
| kis          | poke face              | node           |
| dual         | faces become vertices, vertices become faces | node |
| ambo         | full vertex bevel      | node           |
| chamfer      | hexagons replace edges | node           |
| gyro         | faces divided into pentagons | node           |
| whirl        | insets a smaller rotated copy of the face  | node           |
| propellor    | insets a rotated copy of the face | node           |
| zip          | dual of kis           | kis dual       |
| expand       | edge bevel            | ambo ambo      |
| bevel        | vertex bevel applied twice  | ambo dual kis dual  |
| snub         | dual of gyro          | gyro dual      |
| join         | dual of ambo          | ambo dual      |
| needle       | dual of truncate    | dual kis       |
| ortho        | single subdivide | ambo ambo dual |
| meta         | poke face and subdivide edges     | ambo dual kis  |
| truncate     |  half vertex bevel| dual kis dual  |

See my [Look Think Make](http://elfnor.com/) blog for more info.


text:
# Kubernetes \(GKE\)

### Overview

This guide will install Feast into a Kubernetes cluster on Google Cloud Platform. It assumes that all of your services will run within a single Kubernetes cluster. Once Feast is installed you will be able to:

* Define and register features.
* Load feature data from both batch and streaming sources.
* Retrieve features for model training.
* Retrieve features for online serving.

{% hint style="info" %}
This guide requires [Google Cloud Platform](https://cloud.google.com/) for installation.

* [BigQuery](https://cloud.google.com/bigquery/) is used for storing historical features.
* [Redis](https://redis.io/) is used for storing online features.
* [Google Cloud Storage](https://cloud.google.com/storage/) is used for intermediate data storage.
* [Apache Beam](https://beam.apache.org/) \([DirectRunner](https://beam.apache.org/documentation/runners/direct/)\) is used for ingesting data into stores.
{% endhint %}

## 0. Requirements

1. [Google Cloud SDK ](https://cloud.google.com/sdk/install)installed, authenticated, and configured to the project you will use.
2. [Kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) installed and configured.
3. [Helm](https://helm.sh/) \(2.16.0 or greater\) installed. Helm 3 has not been tested yet.

## 1. Set up Google Cloud Platform

Create a Google Cloud Storage bucket for Feast to stage batch data exports:

```bash
gsutil mb gs://my-feast-staging-bucket
```

Create a service account for Feast to use:

```bash
gcloud iam service-accounts create feast-service-account

gcloud projects add-iam-policy-binding my-gcp-project \
  --member<EMAIL_ADDRESS>\
  --role roles/editor

# Please use "credentials.json" as the file name
gcloud iam service-accounts keys create credentials.json --iam-account \
<EMAIL_ADDRESS>```

Create a BigQuery dataset for Feast to store historical data:

```bash
bq --location=US mk --dataset my_project:feast
```

## 2. Set up a Kubernetes \(GKE\) cluster

Create a Kubernetes cluster:

```bash
gcloud container clusters create feast-cluster \
    --machine-type n1-standard-4 \
    --zone us-central1-a \
    --scopes=bigquery,storage-rw,compute-ro
```

Create a secret in the GKE cluster from the service account `credentials.json`:

```bash
kubectl create secret generic feast-gcp-service-account \
  --from-file=credentials.json
```

## 3. Set up Helm

Run the following command to provide Tiller with authorization to install Feast:

```bash
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: tiller
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tiller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: tiller
    namespace: kube-system
EOF
```

Install Tiller:

```bash
helm init --service-account tiller
```

## 4. Install Feast with Helm

Add the Feast Helm repository and download the latest charts

```text
helm repo add feast-charts https://feast-charts.storage.googleapis.com
helm repo update
```

Create a password for PostgreSQL

```text
kubectl create secret generic feast-postgresql \
    --from-literal=postgresql-password=password
```

Create a `values.yml` file to configure your Feast deployment

```bash
curl https://raw.githubusercontent.com/feast-dev/feast/master/infra/charts/feast/values-batch-serving.yaml \
> values.yaml
```

Update `values.yaml` based on your GCP and GKE environment. Minimally the following values must be set

* `project_id` is your GCP project id
* `dataset_id` is your BigQuery dataset id.
* `staging_location` is the GCS bucket used for staging data being loaded into BigQuery.
* `tempLocation` should also be set to the bucket that you want ingestion jobs to load data into BigQuery.

For more details on configuration parameters, please see the following two files

* [Core](https://github.com/feast-dev/feast/blob/master/core/src/main/resources/application.yml)
* [Serving](https://github.com/feast-dev/feast/blob/master/serving/src/main/resources/application.yml)

Install the Feast Helm chart:

```bash
helm install --name myrelease -f values.yaml feast-charts/feast
```

Wait for the system to come online

```bash
watch kubectl get pods
```

This may take a few minutes

```bash
NAME                                                    READY   STATUS    RESTARTS   AGE
myrelease-feast-historical-serving-5674f6fb4c-bzsk8      1/1     Running   2          14m
myrelease-feast-core-7547b455f4-fvppz               1/1     Running   1          14m
myrelease-feast-jupyter-9b7c4b8fd-bdcbv             1/1     Running   0          14m
myrelease-feast-online-serving-7884578db5-57xwv     1/1     Running   1          14m
myrelease-grafana-c976d598c-jbgkh                   1/1     Running   0          14m
myrelease-kafka-0                                   1/1     Running   0          14m
myrelease-kafka-1                                   1/1     Running   0          13m
myrelease-kafka-2                                   1/1     Running   0          14m
myrelease-postgresql-0                              1/1     Running   0          14m
myrelease-redis-master-0                            1/1     Running   0          14m
myrelease-redis-slave-0                             1/1     Running   0          14m
myrelease-redis-slave-1                             1/1     Running   0          14m
myrelease-zookeeper-0                               1/1     Running   0          14m
myrelease-zookeeper-1                               1/1     Running   0          14m
myrelease-zookeeper-2                               1/1     Running   0          13m
```

## 5. Connect to Feast using Jupyter

Once the pods are all running we can connect to the Jupyter notebook server running in the cluster

```bash
kubectl port-forward \
$(kubectl get pod -o custom-columns=:metadata.name | grep jupyter) 8888:8888
```

```text
Forwarding from <IP_ADDRESS>:8888 -> 8888
Forwarding from [::1]:8888 -> 8888
```

You should now be able to open the Jupyter notebook at [http://localhost:8888/](http://localhost:8888/)

From within the Jupyter Notebook you can now clone the Feast repository

```text
git clone https://github.com/feast-dev/feast
```

Please try out our [examples](https://github.com/feast-dev/feast/blob/master/examples/) \(remember to check out the latest stable version\).

repository: RaniereRamos/feast

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: RaniereRamos/feast


text:
## III. BUILDING THE ELASTIC STACK CONTAINER

We are going to use the `docker-compose.infrastructure.yml` file. Inside you'll find configuration to install 3 Elastic Search nodes and Kibana. All you have to do is run the following to start building your container.

    docker-compose -f docker-compose.infrastructure.yml up -d

With those few words, this builds and turns on your elastic stack container.
With your Elastic Stack running, we are now ready to utilize it. However, at the moment, Kibana won't connect properly. This is related mostly to the authentication. We'll discuss and learn how to setup the connection with your own personal authentication.

If this doesn't start, make sure to see if it's because of vm.max_map_count. If it is so, run:

    sysctl -w vm.max_map_count=262144

license: MIT

repository: dorucioclea/changed-data-capture-demo

repo_name: dorucioclea/changed-data-capture-demo


text:
This directory contains some reference documentation for the DW1000 chip,
such as the user manual provided by DecaWave.

If you're looking for documentation for how to use this driver, then check
out [the Wiki](https://github.com/damaki/DW1000/wiki).


text:
# Relationship Cardinality

## Problem

At present, all relationships in principle, are treated as many-to-many relationships.

Consequences of this are:

-   If users define a one-to-\* relationship, and then execute multiple connects/creates, these will exist in the database
-   Non-nullability is never really checked

## Proposed Solution

Assuming the following type which will be used in all subsequent examples:

```graphql
type Target {
    exampleField: String
}
```

### Invalid relationship definition

For any of the fields in the following example, throw an error because of the reasons in the inline descriptions:

```graphql
type Source {
    example1: [Target!]! @relationship(type: "HAS_TARGET", direction: OUT) # If there are no relationships, then should always be empty array and not null
    example2: [Target]! @relationship(type: "HAS_TARGET", direction: OUT) # This suggests a relationship with no target node
    example3: [Target] @relationship(type: "HAS_TARGET", direction: OUT) # This is a combination of both of the above problems
}
```

### One-to-\* relationships

#### Nullable one-to-\* relationship

For example:

```graphql
type Source {
    example4: Target @relationship(type: "HAS_TARGET", direction: OUT)
}
```

Rules:

-   No requirement to create or connect to a `Target` on the creation of a `Source`
-   Once a `Source` has been connected to a `Target`, no more can be connected (post-operation check in Cypher)
-   A connection can only be made using unique fields for filtering, to prevent the connection to more than one node
-   To change the connected node, you can either:
    -   Disconnect in one Mutation, and then connect in another Mutation
    -   Disconnect and connect in the same Mutation field (nested operations next to each other)
    -   Some new redirect operation???

#### Non-nullable one-to-\* relationship

For example:

```graphql
type Source {
    example5: Target! @relationship(type: "HAS_TARGET", direction: OUT)
}
```

Rules:

-   You MUST create or connect to a `Target` on the creation of a `Source`
-   Once a `Source` has been connected to a `Target`, no more can be connected (post-operation check in Cypher)
-   You cannot disconnect a `Target` from a `Source` without re-establishing a relationship in the same operation
-   A connection can only be made using unique fields for filtering, to prevent the connection to more than one node
-   To change the connected node, you can either:
    -   Disconnect and connect in the same Mutation field (nested operations next to each other)
    -   Some new redirect operation???

#### Operations

`create`, `connect`, `connectOrCreate` should throw an error is something is already connected (should this be a pre-check rather than post for performance reasons?)

`disconnect`, `update` and `delete` should have `_emptyInput` if no nested relationships.

#### Cardinality Checks in Cypher

After any operations on a one-to-\* relationship or its terminating nodes, we should check that the cardinality of the relationship has been maintained.

This can be achieved using `apoc.util.validate`, something akin to the following which ensures relationship count is 1:

```cypher
MATCH (:Source)<-[has_target:HAS_TARGET]-(:Target)
WITH count(has_target) as has_target_count
CALL apoc.util.validate(NOT (apoc.util.validatePredicate(NOT (has_target_count = 1), '@neo4j/graphql/CARDINALITY_VIOLATION Source.target must be 1', [0])), '@neo4j/graphql/CARDINALITY_VIOLATION', [0])
```

There is likely a much cleaner solution than this.

### Many-to-many relationship

For example:

```graphql
type Source {
    example6: [Target!]! @relationship(type: "Source", direction: OUT)
}
```

No changes needed here, this is covered by the existing operations.

## Risks

This is a breaking change for any users using one-to-\* relationships.

## Out of Scope

-   Complex filtering for connecting to neighbouring nodes for one-to-\* relationships (for example `_STARTS_WITH`, `_LT`, etc.) because we are using a unique field for filtering
    -   It could be an option in future to run post-operation checks to ensure cardinality. This would add support for filtering on non-unique fields. This could be added without being a breaking change.

branch_name: refs/heads/dev

gha_language: TypeScript


text:
# TF Sprinkles
Sprinkles augmentation implemented in TensorFlow.

Branch | Build status | Coverage status | PyPI version
--- | --- | --- | ---
`master` | [![Build Status][3]][4] | [![Coverage Status][5]][6] | [![PyPI version][7]][8]
`develop` | [![Build Status][9]][10] | [![Coverage Status][11]][12] |

[3]: https://travis-ci.com/Engineero/tf_sprinkles.svg?branch=master
[4]: https://travis-ci.com/Engineero/tf_sprinkles
[5]: https://coveralls.io/repos/github/Engineero/tf_sprinkles/badge.svg?branch=master
[6]: https://coveralls.io/github/Engineero/tf_sprinkles?branch=master
[7]: https://badge.fury.io/py/tf-sprinkles.svg
[8]: https://badge.fury.io/py/tf-sprinkles
[9]: https://travis-ci.com/Engineero/tf_sprinkles.svg?branch=develop
[10]: https://travis-ci.com/Engineero/tf_sprinkles
[11]: https://coveralls.io/repos/github/Engineero/tf_sprinkles/badge.svg?branch=develop
[12]: https://coveralls.io/github/Engineero/tf_sprinkles?branch=develop

Based on Less Wright's Medium article, [Progessive Sprinkles: a New Data
Augmentation for CNNs][0]. See also his [post on fast.ai][1].

To install:

    pip install tf_sprinkles

To use:

```python
from tf_sprinkles import Sprinkles
sprinkles = Sprinkles(num_holes, side_length)
```

Then call `sprinkles(image)` in the input pipeline for your image. A simple
example to get started using the `cat.jpeg` image located in the data folder
is:

```python
import numpy as np
import tensorflow as tf
from tf_sprinkles import Sprinkles
from PIL import Image
from matplotlib import pyplot as plt

sprinkles = Sprinkles(num_holes=100, side_length=10)
img = Image.open('test/data/cat.jpeg')
img = np.asarray(img) / 255.
result = sprinkles(tf.constant(img, dtype=tf.float32))
plt.imshow(result.numpy())
```

Which results in the following image with sprinkles.

![cat with sprinkles][2]

Note that the `mode` flag added in version 1.1.0 can be used to specify that
sprinkles should be filled with Gaussian noise (`mode='gaussian'`), randomly
filled with black or white (`mode='salt_pepper'`), or all black (the default
or `mode=None`).

[0]: https://medium.com/@lessw/progressive-sprinkles-a-new-data-augmentation-for-cnns-and-helps-achieve-new-98-nih-malaria-6056965f671a
[1]: https://forums.fast.ai/t/progressive-sprinkles-cutout-variation-my-new-data-augmentation-98-on-nih-malaria-dataset/50454
[2]: https://github.com/Engineero/tf_sprinkles/blob/develop/test/data/cat_sprinkled.png


text:
---
layout: post
title: Reading Files

tags: [homework]
comments: true
---

# Code

```python
'''
## Objective
This homework will give you an idea of how to start the lab this week, as well as give you practice reading files with Python. We will do a lot of this together in class.

## Task
Write code that reads the attached `iris.csv`, and creates a dictionary where
  - each key is a species of iris
  - each associated value is a list of all petal-widths of that species
{
  'Iris-setosa': [2.1, 3.2, 4.5, etc... ],
  'Iris-versicolor': [1.1, 2.2, 3.3, 4.4, etc... ],
  'Iris-virginica': [3.1, 2.2, 1.3, etc... ]
}

## Hints
  * Create an empty dictionary before reading the file
  * Populate the dictionary while reading the file
  * Everything is read in as a String -- make sure to convert using float()!

## Submit
Turn in your Python file.
'''

import csv

petal_widths = {}
petal_widths["Iris-setosa"] = []
petal_widths["Iris-versicolor"] = []
petal_widths["Iris-virginica"] = []
print(petal_widths)

with open("iris.csv", "r") as f:
    data = csv.reader(f)
    for row in data:
        if row[4] == "Iris-setosa":
            petal_widths["Iris-setosa"].append(float(row[3]))
        elif row[4] == "Iris-versicolor":
            petal_widths["Iris-versicolor"].append(float(row[3]))
        elif row[4] == "Iris-virginica":
            petal_widths["Iris-virginica"].append(float(row[3]))

print(petal_widths)
```


text:
# @opt/parse
[![Build Status](https://travis-ci.org/elidoran/node-opt-parse.svg?branch=master)](https://travis-ci.org/elidoran/node-opt-parse)
[![Dependency Status](https://gemnasium.com/elidoran/node-opt-parse.png)](https://gemnasium.com/elidoran/node-opt-parse)
[![npm version](https://badge.fury.io/js/%40opt%2Fparse.svg)](http://badge.fury.io/js/%40opt%2Fparse)
[![Coverage Status](https://coveralls.io/repos/github/elidoran/node-opt-parse/badge.svg?branch=master)](https://coveralls.io/github/elidoran/node-opt-parse?branch=master)

Modular options parser allowing plugins to provide everything.

This package doesn't do parsing, it provides the target for plugins to add their stuff.

The expectations are:

1. You will use plugins. If you weren't, you'd just `require()` your favorite parser.
2. So, you will call `parse.use()` at least once to load at least one plugin.
3. So, you can specify the plugin providing the options parser as the first param, like: `parser.use('some-parser-plugin', 'another-plugin')`. For example, use `@opt/nopt` to use `nopt` to parse.

The above expectations mean this package doesn't do parsing itself. It has no dependency on a parser package. So, no baggage when requiring different parsers.

## Install

```sh
npm install @opt/parse --save
```

## Usage

```javascript
var parse = require('@opt/parse')

// Must provide a plugin with parse implementation. This uses @opt/nopt.
// other plugins are optional. May specify them in separate use() calls.
parse.use('@opt/nopt', '@opt/words', '@opt/require')

// then use parse as you would use `nopt`,
// plus any changes made possible by the plugins added
options = parse({}, {}, process.argv, 2)
```

## Usage: Plugins

See [@use/core](https://www.npmjs.com/package/@use/core) to understand how the `use()` function behaves.

See real plugins:

1. [@opt/nopt](https://www.npmjs.com/package/@opt/nopt)
2. [@opt/words](https://www.npmjs.com/package/@opt/words)
3. [@opt/require](https://www.npmjs.com/package/@opt/require)

TODO: Make a plugin to handle type def stuff. It could be parser implementation agnostic. Then, the parser implementation plugins could grab all additional type defs from a standard format.

Example of writing a plugin for **@opt/parse**:

```javascript
module.exports = function (options, opt) {
  // use `options` to help configure what you're going to do
  // change `nopt` for your plugin's interests...
  // for example, add to typeDefs like @opt/words does:
  var nopt = require('nopt')

  nopt.typeDefs.someNewType = {
    type: theTypeKey, // used in options spec
    validate: function validateThisType(data, key, value) {
      // either return false for invalid
      // or, return true and optionally change data[key]
    }
  }
}
```

## MIT License

repository: elidoran/node-opt-parse

repo_name: elidoran/node-opt-parse


text:
# Aldaron's System Interface / OpenGL

Rust safe bindings for OpenGL / OpenGLES

[Cargo](https://crates.io/crates/asi_opengl) /
[Documentation](https://docs.rs/asi_opengl) /
[Change Log](http://plopgrizzly.com/asi_opengl/changelog.html)

## Features
**asi_opengl**'s current features:
* Somewhat safe OpenGL/ES bindings

**asi_opengl**'s planned features:
* Totally safe OpenGL/ES bindings
* Speed enchancements: Like checking whether or not a uniform in a shader is already set to the value we're trying to set (stored in shader struct).

## Support
**asi_opengl**'s current support:
* EGL/OpenGLES with XCB
* WGL/OpenGL on Windows

**asi_opengl**'s planned support:
* EGL/OpenGLES with Wayland
* EGL/OpenGLES on Android
* MacOS

# Contributing
If you'd like to help implement functions for unsupported platforms, fix bugs,
improve the API or improve the Documentation, then contact me at
<EMAIL_ADDRESS>I'll appreciate any help.

gha_language: Rust

gha_license_id: MIT


text:
---
# Documentation: https://sourcethemes.com/academic/docs/managing-content/

title: "Setting Up Shop"
subtitle: "This is a sub heading"
summary: "This is some summary text"
authors: ["admin"]
tags: ["CI", "Netlify", "Hugo"]
categories: ["web"]
date: 2020-02-16T04:41:06Z
lastmod: 2020-02-16T04:41:06Z
featured: false
draft: false

# Featured image
# To use, add an image named `featured.jpg/png` to your page's folder.
# Focal points: Smart, Center, TopLeft, Top, TopRight, Left, Right, BottomLeft, Bottom, BottomRight.
image:
  caption: ""
  focal_point: ""
  preview_only: false

# Projects (optional).
#   Associate this post with one or more of your projects.
#   Simply enter your project's folder or file name without extension.
#   E.g. `projects = ["internal-project"]` references `content/project/deep-learning/index.md`.
#   Otherwise, set `projects = []`.
projects: ["Slim-&-Eloquent"]
---

Setting up ShackTechical with Hugo and Netlify for continious intergration & delployment.

```python
# Example of code highlighting
input_string_var = input("Enter some data: ")
print("You entered: {}".format(input_string_var))
```

{{% alert note %}}
A Markdown aside is useful for displaying notices, hints, or definitions to your readers.
{{% /alert %}}

repository: JaGrant/academic-kickstart

repo_name: JaGrant/academic-kickstart


text:
# Vuong Hoang Long - Project Portfolio

## PROJECT: TrackIt@NUS

This portfolio aims to document the contributions that I have made to the **TrackIt@NUS** project. The Github Link to
 **TrackIt@NUS** can be found [here](https://github.com/AY2021S1-CS2103T-W13-4/tp).

## Overview

**TrackIt@NUS** is a desktop application to provide a simple an easy way for students to manage their academic and
 social life. The user interacts with it using a CLI, and it has a GUI created with JavaFX. It is written in Java.

## General contributions
* Author of the original idea of the project. Defended the idea before teammates so that it became the final project direction.

## Code contributions

The code I contributed can be found [here](https://nus-cs2103-ay2021s1.github.io/tp-dashboard/#breakdown=true&search=unclegrandpa925)

### AB3's leftover clean up
Relevant PRs includes: [#31](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/31/files), [#37](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/37/files), [#42](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/42/files)

### Implemented base classes & refactor the AB3's codebase to suit the new project
I contributed the implementation of most of the base classes (Module/Task/Lesson and its subclasses + methods)
as well as refactor the entire AB3's codebase.
Relevant PRs includes: [#29](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/29/files),
[#30](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/30/files),
[#59](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/59/files),
[#80](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/80/files),
[#88](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/88/files),
[#297](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/297/files)

### Implemented the base for Module Manager, Lesson Manager & Task Manager
Relevant PRs includes: [#32](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/32/files), [#35](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/35), [#36](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/36/files)

### Implemented the complete Module Manager & testcases
Relevant PRs includes: [#61](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/61/files), [#107](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/107/files),
[#142](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/142/files), [#181](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/181/files)

### Implemented the test skeleton for the project
Relevant PRs includes: [#111](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/111/files), [#112](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/112/files),
[#123](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/123/files), [#144](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/144/files), [#233](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/233/files),
[#250](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/250)

### Refactored the codebase to have a better logic flow
Relevant PRs includes: [#140](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/140/files), [#233](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/233/files), [#249](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/249/files)

### Improved the code quality of the codebase:
IntelliJ's code inspection, SpotBugs and PMD have been adapted to the project.
Relevant PRs includes: [#146](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/146/files), [#154](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/154/files),
[#181](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/181/files), [#237](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/237/files),
[#245](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/245), [#289](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/289/files), [#296](https://github.com/AY2021S1-CS2103T-W13-4/tp/pull/296/files)

**The code design decision I made can be found [here](https://github.com/AY2021S1-CS2103T-W13-4/tp/blob/master/docs/DeveloperGuide.md#code-des-cons)**

## Feature, UI/UX contributions
* Designed most of the business logic of the app, including:
    * What fields a Module / Contact/ Lesson / Task have, and their restrictions
    * How the 4 classes link together
    * The tab structure of the app (how each module has its own tab + Upcoming tab + Contacts Tab)
    * The syntax & business logic of all commands
    * An index system to edit/delete Contact, Lesson and Task
    * No index for Module, instead Editing/Deleting is done by its code
* Designed the layout of the Upcoming tab and each Module tab. A great amount of effort (including extensively study from 5 different todo apps: macOS's reminders, Microsoft To Do, Todoist, OmniFocus) has been put into each layout to make sure it's intuitive & convenient for users
* Contributed the idea of having color codes for each module
* Gathered comments of peers to guarantee that the UI/UX suits a wide-range of users
* More about the rationale behind my design consideration can be read [here](https://github.com/AY2021S1-CS2103T-W13-4/tp/blob/master/docs/DeveloperGuide.md#38-feature-design-considerations-)

## Teamwork contributions
Led the team for the entire project. Contributions to team includes:
* Divided tasks between members and covered up for a member if they are busy
* Made sure the project progress followed the timeline
* Facilitated weekly meetings between team members
* Consolidated members' opinions in debate to make final decision about features / UI&UX design
* Connected the front-end team and the back-end team by listening to the front-end team's back-end request and adapt the back-end accordingly.
* Oversee the integration process of the front-end into the back-end
* Oversee the entire back-end development (the entire back-end structure was designed by myself & Simon)

## Testing contributions
Led both the writing of automated testing and the effort of manual testing. Personally I have spent 5-6 hours to test the app manually.

## User Guide contributions
My write up in the UG can be found here:
* [Module Manager section](https://github.com/AY2021S1-CS2103T-W13-4/tp/blob/master/docs/UserGuide.md#module)

## Bugs fixer
Doing the development process, when a bug is located, most of the time I'm the one who quickly located the bug and fixed it.

## Developer Guide contributions
My write up in the DG can be found here:
* All section of [Design](https://github.com/AY2021S1-CS2103T-W13-4/tp/blob/master/docs/DeveloperGuide.md#design) except UI component
* [Module Manager](https://github.com/AY2021S1-CS2103T-W13-4/tp/blob/master/docs/DeveloperGuide.md#module-manager)
* [Functional requirements](https://github.com/AY2021S1-CS2103T-W13-4/tp/blob/master/docs/DeveloperGuide.md#appen-d)
* [Effort](https://github.com/AY2021S1-CS2103T-W13-4/tp/blob/master/docs/DeveloperGuide.md#appen-g)

repository: nottiffchan/TrackIt-NUS

repo_name: nottiffchan/TrackIt-NUS


text:
# Hack Assembler

Project 6 of Nand to Tetris.

This program compiles a file containing Hack assembly code into Hack machine code.

The hack assembly language and machine language specifications are linked below:
[Hack assembly language](https://docs.wixstatic.com/ugd/44046b_b73759b866b249a0b3a715bf5a18f668.pdf)
[Hack machine language](https://docs.wixstatic.com/ugd/44046b_d70026d8c1424487a451eaba3e372132.pdf)

# Build
1. `make`

# Usage
`assembler.out input_path`
input_path - Path to the input file

The program generates an output file with a `.hack` extension and a basename equal to the input path's.

# Architecture
The program consists of two classes used by main:
`Parser` - Reads through each instruction in the input file, parsing it into fields
`SymbolTable` - Used to manage labels in the input file and convert them to their respective addresses

The main function starts by iterating through all the `Parser`'s instructions, only looking for label declarations, and adds them to the `SymbolTable` with their corresponding address.

The parser is then reset and another pass is made. This time, everything else is parsed. Labels are converted to their respective addresses in the `SymbolTable` before the entire instruction is then converted to a 16-bit binary Hack machine instruction and output.


text:
# <%= name %>

* [Installation](#installation)
  * [Setup your environment](#setup-your-environment)
  * [Setup iOS certificates](#setup-ios-certificates)
    * [Development](#development)
    * [Production](#production)
  * [Install dependencies](#install-dependencies)
  * [Start the development server](#start-the-development-server)
  * [Running the app using React Native CLI](#running-the-app-using-react-native-cli)
* [Tests](#tests)
* [Flow](#flow)
* [Deep Linking](#deep-linking)
* [App Icons](#app-icons)
* [Release and deployment](#release-and-deployment)
  * [Building for testing](#building-for-testing)
    * [iOS](#ios)
    * [Android](#android)
  * [Versioning](#versioning)
  * [iOS](#ios-1)
  * [Post-release](#post-release)

<hr/>

## Installation

Before installation, please make sure you have the latest version of [Yarn](https://yarnpkg.com/lang/en/) installed.

### Setup iOS certificates

Please note,
* You should have your own development certificate.
* Save any certificates, p12 files etc... to [our developer repo](https://github.com/simpleweb/developer.apple.com).
* "<%= name %> - iOS Development" provisioning can and should be edited.
* For release, we use a shared distribution certificate "<%= name %>", this should not be edited, deleted or regenerated.

#### Development

[Follow this guide](https://github.com/simpleweb/iOS-Development-For-Teams/blob/master/guide/certificates/ios-app-development.md) to setup your development certificate.

Once your certificate is all setup, head back to the Apple developer portal and edit the existing "<%= name %> - iOS Development" provisioning profile to include your certificate (and any devices you wish to add). Download the new provisioning profile and you should be good to go.

#### Production

Make sure you clone down [our developer repo](https://github.com/simpleweb/developer.apple.com) and double click the `Certificates.p12` from the `<%= nameLower %>/certificates/production/simpleweb` folder.

This is a shared certificate, you __do not__ need to generate a new one each time.

After this is installed, please download the "<%= name %> - iOS Distribution" provisioning profile from the Apple developer site.

### Install dependencies

Install JavaScript dependencies with `yarn`.

```
$ yarn install
```

### Start the development server

React Native uses a development server to bundle up your code, you'll need this running before launching the app in a simulator.

```
$ yarn run start
```

### Running the app using React Native CLI

You can use the [React Native CLI](https://www.npmjs.com/package/react-native-cli) to easily run the app onto the iOS and Android simulators.

```
$ yarn global add react-native-cli
```

Once installed you can then run the app onto each platform’s respective simulator.

```
$ react-native run-ios
$ react-native run-android
```

The iOS version (may) use Pods, and requires to be run via it's Xcode Workspace. If you have build errors with the iOS command above, please open `<%= name %>.xcworkspace` and run your builds from there.

## Tests

This project uses [Jest](https://facebook.github.io/jest/) for testing. You can run the tests once, have Jest continually watch for changes or ask it to produce a coverage report.

```
$ yarn run test
$ yarn run test:watch
$ yarn run coverage
```

With Jest, tests can live anywhere within the codebase, the majority however live in the `__tests__` folder at the root of the project. Any folder with the same name or files ending in `.test.js` will also be included when running Jest.

## Flow

<%= name %> uses [Flow](https://flowtype.org/) to type check the app. If there are missing definitions for external libraries (AKA, you receive lots of Flow errors when using 3rd party code) you can use [`flow-typed`](https://flowtype.org/docs/third-party.html) to fill in any missing gaps.

It’s worth running the update command every so often to keep things in check.

```
$ flow-typed update
```

## Deep Linking

To get Deep Linking working, it requires a few additional steps for iOS and Android. The steps can be found on the [react navigation docs](https://reactnavigation.org/docs/en/deep-linking.html).

## App Icons

The source app icons is located in `App/Assets/AppIcon.png`. The icons for Android and iOS are generated with [`rn-toolbox`](https://github.com/bamlab/generator-rn-toolbox). Please refer to their [documentation](https://github.com/bamlab/generator-rn-toolbox/blob/master/generators/assets/README.md) to generate new icons.

Typically though the command should be something along these lines.

```
$ yo rn-toolbox:assets --icon App/Assets/AppIcon.png
```

![<%= name %> App Icon](/App/Assets/AppIcon.png)

## Release and deployment

### Building for testing

Testing builds should be configured to point towards staging and released using Fabric.

To configure the build for staging, please place staging configuration into `.env.production`. While this is confusing, unfortunately the plugin we are using to populate the environment looks for this file when the app is built in release mode, rather than being environment specific.

#### iOS

For iOS, you will need to produce a release build using the `<%= name %> - iOS Development` provisioning profile. Please make sure everyone’s UUID in the profile you wish to test with. Please refer to [this guide](https://docs.fabric.io/apple/beta/beta-walkthrough.html) for releasing on Fabric.

#### Android

For Android, simply build the project using the instructions below and then follow the [Beta Process Walkthrough](https://docs.fabric.io/android/beta/beta-walkthrough.html) guide.

You will need to make sure Crashlytics is installed in Android Studio, [follow these instructions](https://www.fabric.io/downloads/android) if you don’t have it setup.

### Versioning

When producing a new build you will need to bump the version number. This is handled more or less automatically through the version in the `package.json`.

For iOS you need to run the following command which automatically updates the XCode project with the version inside the `package.json`. It also increments the build number.

```
$ yarn run bump
```

Android’s version is dynamically generated using it’s Gradle files.

If there's ever any issues with this flow, please [refer to this article](https://medium.com/@andr3wjack/versioning-react-native-apps-407469707661).

### iOS

In XCode build to the "Generic iOS Device" and then archive the build. Building (as opposed to running) will use the "Signing (Release)" profile, the provisioning profile for this must be "<%= name %> - iOS Distribution".

Once archived simply open the Organizer in XCode and upload the build.

### Android

From [https://github.com/simpleweb/developer.apple.com/tree/master/<%= nameLower %>/android](https://github.com/simpleweb/developer.apple.com/tree/master/<%= nameLower %>/android), download the `<%= nameLower %>.keystore` file and place it into `android/app`.

Then take the environment variables from `gradle.properties` and and them into your own properties file located in `~/.gradle/gradle.properties`.

Once these are both setup correctly, go into the `android` directory and run...

```
$ ./gradlew assembleRelease
```

This should leave you with a signed APK located in `android/app/build/outputs/apk/app-release.apk`.

### Post-release

After each build, please create a commit along the lines of "Release 0.1.0" and push it to Github. Following that, [create a release](https://github.com/simpleweb/<%= name %>/releases) and named "v0.1.0", include any release notes and attach both iOS and Android binaries (zipped).

repository: greenstudiocorp/greenstudio-cli

repo_name: greenstudiocorp/greenstudio-cli


text:
# GitHub Workflow

We'll outline a very simple GitHub workflow here. More on [Git/GitHub here](https://cityoflosangeles.github.io/best-practices/).

## Collaborate and Use Version Control

One major learning objective of this workshop is to learn how to write code in a collaborative setting. Version control is super important for this. GitHub can facilitate this collaborative workflow. For this workshop, you'll learn to collaborate with yourself (a past version of you collaborating with a future version of you). You'll apply all these best practices, but we'll strip away some of the more advanced GitHub workflows that come with collaborative work, as that isn't the focus for now.

As mentioned in the [GitHub](./github_version_control.md) section, the way for collaborators to stay in sync with their code is by pushing and pulling their code. You can upload a lot of different files to GitHub, ranging from code stored in text files (.py, .R, .do), Jupyter Notebooks (.ipynb), HTML files (.html, .md), datasets (.csv, .xlsx, .parquet, .zip, .geojson, etc), to images and reports (.pdf, .png, .jpg, etc). GitHub has some built-in functionality to display some of those, but not all of them, but it can certainly store all of them. Large datasets shouldn't be uploaded (>25MB via browser, >100MB via command line).

In GitHub, there's a `master` branch, the latest version of code that is ready to go for everyone. When you're working on an individual task, make sure you've pulled all the changes from the `master` branch, and then make a new branch to do your work. When you've finished the task, your new branch is ready to be **merged** into the master branch.

### Make new branch

In Ubuntu:
* Checkout the master branch: `git checkout master`
* Pull all the latest changes in the master branch (make sure your local matches the remote): `git pull origin master`
* Make a new branch to do your work: `git checkout -b my-new-branch`
* ....DO ALL YOUR WORK LOCALLY....

### Push changes to the remote

When you've done some work locally, you want to save a version in the remote repo. Think of this as "saving" in your Word Doc, Google Doc, etc. With GitHub, you have explicitly "save" by **committing** the changes. Otherwise, your changes are saved locally only. Think of this as creating checkpoints in your code, and you can always revert back any versioned changes in the remote repo.

If you are using Binder, you need these [extra steps](./binder_workflow.md) before you do your `git add`, `git commit`, `git push`.

In Ubuntu:
* Push your local changes to the remote: `git add notebooks/1-read-in-data.ipynb`. For multiple files, do `git add notebooks/1-read-in-data.ipynb utils.py`
* Commit the change by including a short commit message: `git commit -m "Exploratory analysis"`
* Push the changes from local to the remote: `git push origin my-new-branch`
* Go to the site: `https://github.com/YOUR-USERNAME/my-new-branch` and you should see your changes reflected there.

When all the work on the branch is done, you're ready to **merge** the branch in. On the GitHub website, you'll open a pull request, and take a look at the "summary" of all those changes, and merge!  You'll pull from the master branch, and then checkout a new branch to go off on a new assignment, and repeat the cycle.

Back to [main README](./README.md), [Getting Started](./getting_started.md), [Making a Report](./making_report.md), [Data Pipeline](./data_pipeline.md) or [Other Resources](./other_resources.md)

gha_language: HTML


text:
---
title: "Backblaze B2"
description: "Backblaze B2's first 10G of storage is free, and the first 1G of download per day is free after that.  Afterwards they charge $0.01/G."
date: 2020-11-17T20:11:42+01:00
lastmod: 2020-11-17T20:11:42+01:00
draft: false
images: []
weight: 020
toc: false
type: subpages
---

As of November 2020 [Backblaze's B2](https://www.backblaze.com/b2/cloud-storage.html) is fully [S3 compatible](https://www.backblaze.com/b2/docs/s3_compatible_api.html).

B2's first 10G of storage is free, and the first 1G of download per day is free after that. Afterwards they charge $0.01/G.

### Keys

When creating your ["Application Keys"](https://secure.backblaze.com/app_keys.htm) keep in mind that the **"Application Key ID"** is the **"Access Key"** and the **"Application Key"** is the **"Secret"**.

It has been suggested that you make sure you set your key setting of "Allow access to Bucket" to `All`.

### CORS settings

While the specific origins you want to support are up to you, make sure the API for CORS support is set to either **"S3"** or **"Both"**.

{{< img src="/docs/img/b2_cors.png" align="center">}}

### Expiration of old files on B2

You can have B2 delete old video files every day to keep your storage low by simply changing the **Lifecycle Settings** in the B2 dashboard.

{{< img src="/docs/img/b2_delete_old_files.png" align="center">}}


text:
---
title: "lbhash.proto"
weight: 5
---

<!-- Code generated by solo-kit. DO NOT EDIT. -->

### Package: `lbhash.options.gloo.solo.io`
#### Types:

- [RouteActionHashConfig](#routeactionhashconfig)
- [Cookie](#cookie)
- [HashPolicy](#hashpolicy)

##### Source File: [github.com/solo-io/gloo/projects/gloo/api/v1/options/lbhash/lbhash.proto](https://github.com/solo-io/gloo/blob/main/projects/gloo/api/v1/options/lbhash/lbhash.proto)

---
### RouteActionHashConfig

Specifies the route’s hashing policy if the upstream cluster uses a hashing load balancer.
https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route.proto#envoy-api-msg-route-routeaction-hashpolicy

```yaml
"hashPolicies": []lbhash.options.gloo.solo.io.HashPolicy

```

| Field | Type | Description |
| ----- | ---- | ----------- |
| `hashPolicies` | [[]lbhash.options.gloo.solo.io.HashPolicy](../lbhash.proto.sk/#hashpolicy) | The list of policies Envoy will use when generating a hash key for a hashing load balancer. |

---
### Cookie

Envoy supports two types of cookie affinity:
- Passive: Envoy reads the cookie from the headers
- Generated: Envoy uses the cookie spec to generate a cookie
In either case, the cookie is incorporated in the hash key.
additional notes https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route.proto#envoy-api-msg-route-routeaction-hashpolicy-cookie

```yaml
"name": string
"ttl": .google.protobuf.Duration
"path": string

```

| Field | Type | Description |
| ----- | ---- | ----------- |
| `name` | `string` | required, the name of the cookie to be used to obtain the hash key. |
| `ttl` | [.google.protobuf.Duration](https://developers.google.com/protocol-buffers/docs/reference/csharp/class/google/protobuf/well-known-types/duration) | If specified, a cookie with the TTL will be generated if the cookie is not present. If the TTL is present and zero, the generated cookie will be a session cookie. |
| `path` | `string` | The name of the path for the cookie. If no path is specified here, no path will be set for the cookie. |

---
### HashPolicy

Specifies an element of Envoy's hashing policy for hashing load balancers

```yaml
"header": string
"cookie": .lbhash.options.gloo.solo.io.Cookie
"sourceIp": bool
"terminal": bool

```

| Field | Type | Description |
| ----- | ---- | ----------- |
| `header` | `string` | Use a given header's value as a component of the hashing load balancer's hash key. Only one of `header`, `cookie`, or `sourceIp` can be set. |
| `cookie` | [.lbhash.options.gloo.solo.io.Cookie](../lbhash.proto.sk/#cookie) | Use a given cookie as a component of the hashing load balancer's hash key. Only one of `cookie`, `header`, or `sourceIp` can be set. |
| `sourceIp` | `bool` | Use the request's source IP address as a component of the hashing load balancer's hash key. Only one of `sourceIp`, `header`, or `cookie` can be set. |
| `terminal` | `bool` | If set, and a hash key is available after evaluating this policy, Envoy will skip the subsequent policies and use the key as it is. This is useful for defining "fallback" policies and limiting the time Envoy spends generating hash keys. |

<!-- Start of HubSpot Embed Code -->
<script type="text/javascript" id="hs-script-loader" async defer src="//js.hs-scripts.com/5130874.js"></script>
<!-- End of HubSpot Embed Code -->

repository: solo-io/gloo

branch_name: refs/heads/main

gha_language: Go

repo_name: solo-io/gloo


text:
---
layout: post
title: An introduction to x86 Intel Assembly For Reverse Engineering
---

When I first started Reverse Engineering, I was looking into something, to begin with. I eventually decided to start with understanding assembly because after all, that's the best you can get when the source code isn't publicly available unless you find pleasure in reading 1s and 0s or HEX dumps. A few decades ago, a lot of software used to be written in assembly language specific to the CPUs at the time.

I remember writing assembly code for the 6502 CPU back on the Commodore 64 because sometimes, the BASIC was just too slow. It wasn't really fun. Nowadays, high-level programming languages are way better in terms of speed and ease of use, however, the assembly language is still actively used where very good control over the hardware has to be achieved and for reverse engineering.

Reverse Engineering is, basically, just a better understand of computers and how they work. You don't essentially learn how to hack or how to reverse engineer, you just learn how computer work. When I first started, I needed to choose a platform because Reverse Engineering can involve different steps depending on the target CPU. I started with Intel x86 (IA-32). This is what I am going to cover in this write-up, and hopefully, this will help beginners understand the basics a bit better.

### Nota Bene!

A very important thing you need to keep in mind when you learn how to read and interpret assembly is that each CPU has a different set of instructions which interact in a different way with one another. Even the mnemonics are different from a CPU architecture to another. For example, the x86 Intel CPU has different instructions compared to the armv7 CPU. While some mnemonics may match, some of them are present on architecture but not in the others. Usually, the reference manuals contain a lot of details about each instruction.

### Mind the compiler
Today's technology is pretty reliable, it works fast and the speed has long become a requirement when we buy a computer. For computer programs to work fast, compilers, those programs that interpret your C, C++, C#, etc. source code and transform it into machine-readable code, usually add and remove pieces of code from the final binary. This is done for optimization purposes. Either to remove useless CPU cycles or to diminish the RAM footprint. The problem is that when we start reversing a binary it is a bit hard to tell what belongs to the actual program logic and what is added for optimization by the compiler.

A good technique for beginner reverse engineers is to focus more on understanding the flow of the program (by seeking and understanding where the program calls a function, jumps to a different location, updates or checks a variable, etc.) than on the whole thing. It is also a good idea to understand the structure of a procedure in assembly. It would help you understand why you can see a pattern of instructions at the beginning of every function. This is called the function prologue, but about this, we're talking later on.

### CPU Registers

Before starting your journey onto the IA-32 assembly, it's a very good idea to learn more about the architecture itself. The CPU has what is called "registers". They are pretty much a very fast but limited memory on the microprocessor. The microprocessor can access these registers and retrieve the data way faster than it could do from RAM. The problem is, there are only a few of them and some registers are not general purpose, meaning they can't really be used for everything. What can't be fitted in the registers, lies in the RAM.

The IA-32 CPUs have 8 general purpose 32-Bit registers. Of course, these CPUs have way more registers than that, but only eight of them are truly general purpose. These registers are very important and you will find them scattered all over the place in the assembly output of any binary disassembler. A list of the available registers and a brief description is provided below.

EAX, EBX, ECX, and EDX are general purpose registers used for various operations. ECX is sometimes used as a counter by repetitive instructions.

EBP and ESP are the Stack Base Pointer and the Stack Pointer. Together, these two create the Stack Frame.

EDI and ESI are the Destination Index and Source Index registers and is used when dealing with the memory copying.

The preceding "E" in the register name is standing for "extended". That is because the name is carried over from the 16-bit architecture where the registers were, as you may have figured out, 16-bit wide.

Here is a diagram I've made to help you understand the registers and their 16-Bit counterparts.

### CPU Flags

Aside from the registers, the CPU also has flags which are used during various operations. The flags are contained in the big EFLAGS special register. These flags are used for various purposes and they can manage the processor modes, and states and they can also store the logical state and are heavily used by conditional jump instructions. For example, the JNE instruction which stands for Jump If Not Equal will always use the ZF (Zero Flag) set by a previous CMP (compare) instruction. A CMP instruction takes two operands and subtracts one from the other. If they are equal, the Zero Flag will be set so the following JNE instruction will see that and skip the branch. At the same time, a JE (Jump if Equal) would jump if the flag is set.

### Arithmetics on the IA-32

The IA-32 instruction set contains six instructions for arithmetic purposes.

ADD  - Used: ADD Operand1, Operand2 - The result is stored in Operand1

SUB  - Used: SUB Operand1, Operant2 - The result is stored in Operand1

DIV  - Used: DIV Operand            - Divides the 64-bit value from EDX:EAX by the unsigned operand specified.

MUL  - Used: MUL Operand            - Multiplies the Unsigned operand specified, by EAX and stores the result as 64-bit in EDX:EAX

IDIV - Used: IDIV Operand           - Divides the 64-bit value from EDX:EAX by the signed operand specified.

IMUL - Used:                        - Multiplies the signed operand specified, by EAX and stores the result as 64-bit in EDX:EAX

### Example

In this example, you can see the CMP, JNE and some general purpose registers used in a block of code that resembles the if conditions in a high-level programming language.

```c
ADD EAX, 12 ; We add 12 to the EAX register's value
CMP EAX, 0xC ; We compare EAX with the hex representation of decimal 12
JNE 0x1001FFee1 ; If the comparison results that EAX = 12, the ZF is set and the JNE won't proceed to the address specified.
MOV EDI, [ECX+0x4b2] ; Move whatever is at ECX + 0x4b2 offset into the EDI register
JMP 0x1001DDe1 ; Unconditional jump to that address.
```

The unconditional jump would not have the chance to be executed if the above JNE executed. Since the comparison on which the JNE instruction relies resulted in the two values being equal, the ZF (Zero Flag) is set and the Jump If Not Zero (JNZ) is skipped. The next instruction after the conditional jump is executed until the JMP which is an unconditional jump. This means that the jump will happen no matter what, as long as the CPU can reach the execution of this instruction.

You can see this sort of comparison followed by a conditional jump in many programs. The closest high-level programming concept that matches this assembly snippet would be an If Condition or other related control flow statements.

For example, the following code contains a simple If - Else statement. Let's see how will this be represented in the assembly after GCC compiler does its job.

```c
#include <stdlib.h>
#include <stdio.h>

int compare(){
  int x = 2;
  int y = 1;
  int z = x + y;
  return z;
}

int main(){
    int x = 0;
    if (x = 12){
      compare();
    } else {
      return 0;
    }
}
```

```c
_compare:
00001f40         push       ebp                                                 ; XREF=0x10ac, _main+30
00001f41         mov        ebp, esp
00001f43         sub        esp, 0xc
00001f46         mov        dword [ss:ebp+var_4], 0x2
00001f4d         mov        dword [ss:ebp+var_8], 0x1
00001f54         mov        eax, dword [ss:ebp+var_4]
00001f57         add        eax, dword [ss:ebp+var_8]
00001f5a         mov        dword [ss:ebp+var_C], eax
00001f5d         mov        eax, dword [ss:ebp+var_C]
00001f60         add        esp, 0xc
00001f63         pop        ebp
00001f64         ret
; endp

_main:
00001f70         push       ebp                           ; Push the Stack Base Pointer
00001f71         mov        ebp, esp
00001f73         sub        esp, 0x18                     ; Subtract 24 from the Stack Pointer
00001f76         mov        dword [ss:ebp+var_4], 0x0
00001f7d         mov        dword [ss:ebp+var_8], 0x0     ; Clearing purposes?
00001f84         cmp        dword [ss:ebp+var_8], 0xc     ; This is where the comparision is done with 12.
00001f88         jne        0x1f9b                        ; Jump if not equal (pretty much executes the ELSE)

00001f8e         call       _compare                      ; call compare();
00001f93         mov        dword [ss:ebp+var_C], eax
00001f96         jmp        0x1fa2

00001f9b         mov        dword [ss:ebp+var_4], 0x0     ; This is the beginning of the ELSE statement

00001fa2         mov        eax, dword [ss:ebp+var_4]     ; Return 0;
00001fa5         add        esp, 0x18
00001fa8         pop        ebp                           ; Pop the Stack Base Pointer
00001fa9         ret                                      ; Bail out

```

As you can see, only a few of the instructions are relevant for our If - Else statement. The rest are either the compiler's way of pushing the "X" variable to the stack, the function prologue, epilogue, and calls.
In order to understand the program flow, you have to ignore the bits you don't understand and focus on the ones that make sense first.

### Function calls

As you can see, the function calls are done using the CALL instruction which accepts a single operand. This is the address of the function to jump to. Once the CALL instruction is hit, it will push the current Instruction Pointer to the stack (so that it the program can continue from where it left when the called function RETurns), and then it jumps to address of the called function. In the above example, the CALL happens at address `0x00001f8e` and the call instruction calls compare() which is at address `0x00001f40`.

In order to return to the callee, the function ends with a RET instruction. Additionally, one can instruct RET to increment the Stack Pointer (ESP) by a number of bytes after the instruction pointer is popped.

### Using inline assembly in C and C++

Some compilers allow you to write inline assembly code and embed it into your C and C++ code. This is done using the `__asm__` notation or simply using the `asm()`. The IA-32 assembly can be represented in different syntaxes. The Intel syntax is the most used but you can chose the AT&T syntax too if you're into that. Most debuggers and reverse engineering tools, like GDB, allow you to set the disassembly syntax.

Here's a quick example of a C program that also involves assembly:

```c
#include <stdlib.h>
#include <stdio.h>

int source = 3;
int destination = 0;

int main(){
     asm ("mov %1, %0\n\t"
         "add $4, %0"
         : "=r" (destination)
         : "r" (source)
     );

     printf("The result is %d\n", destination);
}

```
I hope you will find this write-up on beginner level IA-32 assembly useful in the future and I wish you good luck in your journey on the land of reverse engineering. Happy CVEing!

gha_language: CSS


text:
# Simple Workflow for Contributing to the Handbook

The following workflow describes the minimal steps required to contribute content for a new
subject:

1. [Select Subject](#select-subject)
2. [Create Content](#create-content)
3. [Submit Pull Request](#submit-pull-request)

## Select Subject

Think about a subject that is of interest to Software Engineers and from your own experience is not
covered well by existing tutorials or is not easily accessible.

Explore the [detailed Table of Contents (TOC)](toc.md) to get ideas of such subjects and identify
where your contribution may fit. If you think that the current TOC requires changes, we recommend
that you open an issue that presents your change or fix.

## Create Content

Goto the [handbook repository on GitHub][1] and use the 'Create new file' button to start editing
the content online. When finished, optionally add description using the 'Propose new file' dialog,
and finally submit the file using the 'Propose new file' button.

Note: Since you are creating a file in a project you don’t have write access to. Submitting a
change will create the file in a new branch in your fork, so you can send a pull request. Visit
[Contributing to an Open Source Project][4] for more details on fork and pull request.

### Prerequisites

Learn about the differences between [Guides](Guides) and [Topics](Topics) in the context of the
Software Engineering Handbook.

### Guides and Topics Authoring

Create Guides and/or Topics for the selected subject as described above. Include appropriate
references to external sources with minimal duplications of exiting materials. Create internal
links associating between the Guides and Topics documents for the subject.

### Content Style Guides

* Use [Markdown][2].
* See relevant examples in [Guides](Guides) and [Topics](Topics) directories.
* Use preview tools for Markdown (e.g., GitHub itself for files ending with `.md`).

## Submit Pull Request

We use [GitHub Flow][3], which means all changes happen through [pull requests][4].

If you are a first time contributor, we recommend that you open an issue that presents your
change or fix, before submitting a pull request.

---

[1]: https://github.com/uribench/software-engineering-handbook
[2]: https://daringfireball.net/projects/markdown
[3]: https://guides.github.com/introduction/flow/index.html
[4]: http://software-engineering-handbook.com/Guides/Git/Contributing%20to%20an%20Open%20Source%20Project

license: Unlicense

repository: heyleng/software-engineering-handbook

gha_license_id: Unlicense

repo_name: heyleng/software-engineering-handbook


text:
In golang, there is only the for-loop.

I.e. there are no such thing as do-loops, while-loops, until-loops,..etc.

There are 4 types of for-loops,

- loop till condition
- loop till condition with post clause
- infinite loop
- loop over collections

## infinite loop

```go
package main
import (
    "fmt"
)

func main() {
    var i int  // this defaults to 0
    for i < 5 {
        fmt.Println("i is set to: ", i)
    }
}
```

This outputs:

```
i is set to:  0
i is set to:  0
i is set to:  0
.
.
...etc
```

## loop till condition

```go
package main

func main() {
    var i int
    for i < 5 {
        println(i)
        i++
    }
}
```

This outputs:

```
0
1
2
3
4
```

## exit loop early using "break"

```go
package main

func main() {
    var i int
    for i < 5 {
        println(i)
        if i == 2 {
          break
        }
        i++
    }
}
```

This outputs:

```
0
1
2
```

## skip loop early using "continue"

```go
package main

func main() {
    var i int
    for i < 5 {
        i++
        if i == 2 {
          continue
        }
        println(i)
    }
}
```

this outputs:

```
0
1
3
4
5
```

## loop with clauses

[loop with clauses](https://tour.golang.org/flowcontrol/1)

this loop has 3 parts to it's definition:

```go
package main

func main() {

	for i := 0; i < 5; i++ {
		println(i)
	}

}
```

In this scenario, the variable i only exists inside the scope of the for loop.

this outputs:

```
0
1
3
4
```

## Infinite loop (ugly syntax)

This leaves the middle 'conditional' segment, (and optionally the other 2 statements) blank:

```go
package main

func main() {
  var i int
	for ; ; {
		println(i)
		i++
	}

}
```

this outputs:

```
0
1
2
3
4
5
6
7
...etc
```

## Infinite loop (pretty syntax)

Here we remove the "; ;" syntax and initialize the counter variable outside the loop:

```go
package main

func main() {
    var i int
	for {
		println(i)
		i++
	}

}
```

this outputs:

```
0
1
2
3
4
5
6
7
...etc
```

## Looping over collections

looping over slices:

```go
package main

func main() {
        mySlice := []string{"a", "b", "c"}
	for i:=0; i<len(mySlice); i++ {
		println(mySlice[i])
	}

}
```

this outputs:

```
a
b
c
```

Here's a more neater syntax using 'range':

```go
package main

func main() {
        mySlice := []string{"a", "b", "c"}
	for myIndex, myValue := range(mySlice) {
		println(myIndex, myValue)
	}

}
```

This outputs:

```
0 a
1 b
2 c
```

iterating over a map:

```go
package main

func main() {
        pets := map[string]int{"dog": 4, "cat": 7, "hamster": 1}
	for typeOfPet, ageOfPet := range(pets) {
		println(typeOfPet, ageOfPet)
	}

}
```

this outputs:

```
dog 4
cat 7
hamster 1
```

If you're only interested in the map's value, you can just do:

```go
package main

func main() {
        pets := map[string]int{"dog": 4, "cat": 7, "hamster": 1}
	for _, ageOfPet := range(pets) {
		println(ageOfPet)
	}

}
```

This outputs:

```
4
7
1
```

If however you're only interested in the map's key, you can just do:

```go
package main

func main() {
    pets := map[string]int{"dog": 4, "cat": 7, "hamster": 1}
	for typeOfPet, _ := range(pets) {
		println(typeOfPet)
	}

}
```
https://play.golang.org/p/_co2jEt8tqJ

or using an even more shorthand syntax (which is slightly more difficutl to read), you can do:

```go
package main

func main() {
    pets := map[string]int{"dog": 4, "cat": 7, "hamster": 1}
	for typeOfPet := range(pets) {
		println(typeOfPet)
	}

}
```
https://play.golang.org/p/WKxHQCsx6q0

both of these examples, outputs:

```
dog
cat
hamster
```

repository: golang-study-guide/Golang-Study-Guide

repo_name: golang-study-guide/Golang-Study-Guide


text:
# Slugify

- [About](#about)
- [Getting Help](#getting-help)

## About

This repository contains simplified functions for slugifying strings in Go. Note that emojis are not supported, the functionality kept in this module is deliberately meant to be overly simplified.

## Getting Help

We believe in an open and welcoming community for all. Please post your questions in the [Issues](https://github.com/tdmnco/go-slugify/issues) section here at GitHub or contact Kasper Tidemann directly at [kt@tdmn.co](kt@tdmn.co).

Note that if your question has general relevance, it might be worth sharing with others.

---

Thanks for reading!

🎁

repository: tdmnco/go-slugify

repo_name: tdmnco/go-slugify


text:
#  [Challenge 2 - Even Fibonacci numbers](https://projecteuler.net/problem=2)

## Description

Each new term in the Fibonacci sequence is generated by adding the previous two terms. By starting with 1 and 2, the first 10 terms will be:

> 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...

## Exercise

By considering the terms in the Fibonacci sequence whose values do not exceed four million, find the sum of the even-valued terms.

## Solution

You can find the algorithm to solve this challenge inside [challenge.cpp](challenge.cpp)

<details>
  <summary>Click here to see the result!</summary>

  Result is: `4,613,732`
</details>

repository: larry-chunhui/project-euler

repo_name: larry-chunhui/project-euler


text:
# Inner-source Collaboration

  * Replaces: none
  * Replaced by: none
  * Topics: process, collaboration, contribution, team work, inner source

## Summary
[Summary]: #summary

Contributions to software projects SHOULD follow a consistent and agreed-upon process for collaboration to ensure common understanding for all involved. This process is meant to be a guideline for most use cases and is not meant to be inclusive of all possible situations that may arise in software development. In all cases, best intent SHOULD be assumed and all possible opportunities to align with the standards presented herein SHOULD be attempted.

Communication, early and often, between [Contributors] and [Maintainers] is highly RECOMMENDED to keep everyone involved as informed about progress as possible. Communication about intent before work starts, the progress during development, and upon completion or abandonment of efforts all parties should be reasonably up to date on the status of the effort.

This document is meant to describe the standard collaboration process between the two groups of developers: [Contributors] and [Maintainers]. Non-developer partners - business, design, product, etc. - are NOT REQUIRED to follow this standard process and should work with the leadership of the [Maintainers] group to ensure that any changes they need get prioritized in the backlog appropriately. However, non-developer partners are encouraged to join any discussion and raise issues or questions at any time.

## Conventions
[Conventions]: #conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC 2119](http://tools.ietf.org/html/rfc2119).

## Motivation
[Motivation]: #motivation

Software is inherently complicated, and the development or maintenance of software is further complicated by the need for people to communicate successfully within the challenges of remote working conditions, different time zones, conflicting priorities, etc; challenges abound that make software development difficult. These guidelines are meant to be a basis for common practices agreed upon and shared between various contributors; however frequent or infrequent they may be.

Contributions from [Contributors] are inherently more risky due to the disconnected nature of the people putting in the effort to submit the changes as they are not as well informed about the decisions/direction of the [Maintainers] and project. This is not to say that these contributions are not welcome; on the contrary, they are encouraged. However, it MUST be understood that the [Maintainers] do have the final say on when and what gets accepted into the main branch of development for a project as they are the ones accountable for all aspects. Every effort will be put forth by the [Maintainers] to be open and responsive to reasonable contributions and [respond promptly](#response-times) to all requests.

## Design
[Design]: #design

*The Planning phase is REQUIRED for all changes to source code. Improvements to documentation, fixing of typos, obvious mistakes, or anything not specifically source code DO NOT REQUIRE any Planning phase actions/steps and a pull request can be opened immediately where conversation MAY occur.*

  1. PHASE: **[Planning]**
      1. **[Request]** - communication about the need
      2. **[Discussion]** - i.e. GitHub Issue comments
      3. **[Agreement]** - consensus between [Maintainers] and [Contributors]
  2. PHASE: **[Execution]**
      4. **[Development]** - contingent upon the agreement reached; iterative and *focused* development with ongoing review
      5. **[Completion]** - final review
      6. **[Acceptance]** - merge to main branch of development

Some things to keep in mind throughout all steps of this process:

  * Give context. Help the [Maintainers] to understand what you are trying to incorporate, explain a scenario, or share an uncovered use case
      - Good example: "X doesn't happen when I do Y."
      - Poor example: "X is broken, please fix it."
  * Research beforehand. It's OK not to know things, but show that you did some due diligence
      - Good example: "I'm not sure how to implement X. I checked the help docs and didn't find any mentions."
      - Poor example: "How do I do X?"
  * Keep requests succinct. Time is our most precious asset respect others' time and they will respect yours.
      - Good example: "I'd like to write an API tutorial for X."
      - Poor example: "I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you ..."
  * Communicate publicly. Doing so is a help to everyone who comes after you with the same idea or looking for examples of how to do something similar.
      - Good example: (as a comment) "@-maintainer Hi there! How should we proceed on this PR?"
      - Poor example: (as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR?"
  * Questions are OK but be patient. Keep in mind that everyone has priorities they are working on and anything adding on to that is potentially disruptive.
      - Good example: "Thanks for looking into my error. I followed your suggestions. Here's the output."
       Isn't this your project?"
  * Respect decisions. Ultimately the [Maintainers] are the people that take ownership of all contributions and are thus accountable for any failures after being accepted.
      - Good example: "I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."
      - Poor example: "Why won't you support my use case? This is unacceptable!"
  * Above all, keep it productive and professional. Everyone is on the same team, trying to build the best products we can and everyone potentially comes from very different backgrounds which bring with it different perspectives on solutions. Additionally, take all communication as a step toward improvement, not one aimed at criticism or negativity.

### Planning
[Planning]: #planning

The Planning phase is important because it is relatively cheaper than the Execution phase in most cases and all aspects. Some reasons why this phase is important are:

  * Similar or redundant changes may already be in development by the [Maintainers]
  * The project may be going in a different direction removing the need for the requested changes
  * The project may already support the change being proposed and documentation simply doesn't cover it well enough for clients/users to educate themselves and move forward

The collaboration tool used can take many forms and SHOULD be appropriate for the scope and urgency of the change being proposed; some suggestions are:

Communication Type  | Urgency  | Scope
------------------- | :------: | :---:
Simple GitHub Issue | low      | small
ADR or RFC          | low-med  | any
Phone call          | high     | large or unknown
Virtual meeting     | med-high | large or unknown
Slack discussion    | low      | any

During the [Planning] phase code SHOULD NOT be changed. The Planning phase is meant to produce documentation describing the desired outcome either in prose - as acceptance criteria that can be used as confirmation of completion - or any relevant visual documentation, such as architectural diagrams, graphics, process diagrams, etc.

Some forms that this documentation could use or follow are:

  * [Lean RFC](https://github.com/kalisjoshua/lean-rfc)
      1. Summary
      2. Motivation
      3. Design
      4. Drawbacks
      5. Alternatives
  * [Architectural Decision Records](https://adr.github.io/)
      1. Title
      2. Status
      3. Context
      4. Decision
      5. Consequences

No matter the choice, a repository SHOULD be consistent with a single standard. Additionally, some fundamental concerns should be covered no matter which standard is used:

  * What the decision is
  * Why the decision was chosen in favor of other options
  * What other options were considered
  * Why another option might make more sense in the future
  * How are specific concerns being addressed
      - Security
      - Performance
      - Backwards-compatibility
      - Rollout (or General Availability)
      - Future maintainability

#### Request
[Request]: #request

A GitHub Issue should be opened by the [Contributors] to detail the need/change they are looking for. Opening an issue allows for open discussion within the repository where the change is being proposed and SHOULD focus the request on the changes needed for the given repository; if the change is something that will touch multiple repositories then those issues MAY be inter-linked for reference. The issue SHOULD be commented on by all people involved including anyone interested but not involved directly.

#### Discussion
[Discussion]: #discussion

During Discussion, in the GitHub Issue, [Contributors] MUST present justification for the addition, augmentation, or removal of functionality - the proposed change - to the satisfaction of the [Maintainers]. The [Maintainers] SHOULD make every effort to help reasonable requests move forward or MUST provide clear reasoning why any proposed changes are not acceptable. All aspects of what will be done, how, and why they will be done should be made clear through either the comments on the GitHub Issue or provided documents and/or diagrams (if necessary or helpful).

#### Agreement
[Agreement]: #agreement

All people involved should understand and accept, if not completely agree with, the decision made by the [Maintainers] as a result of the [Discussion] where all questions are answered and all details explained. If the decision is to not move forward with allowing the proposed changes to be accepted the reasoning MUST be made clear by the [Maintainers] to the satisfaction of the [Contributors]. If the decision is to move forward and accept future work in support of the proposed changes all details and supporting documentation MUST be provided to the satisfaction of both the [Contributors] and the [Maintainers].

The final detail necessary is to identify who, between [Contributors] and [Maintainers], will be doing the work or if it will be a joint development effort.

It is important to note:

  * Just because a request/proposal is acceptable/agreed upon does not mean that it is a high priority for the [Maintainers]
  * Any [Contributors] proposing changes are not necessarily "on the hook" to work on the implementation/solution

### Execution
[Execution]: #execution

The Execution phase will be where all of the proposed changes, from [Planning], will be developed, reviewed, and delivered. Feedback and response - general communication - between [Contributors] and [Maintainers] should be expected and encouraged from beginning to end of [Development] to ensure a good experience for everyone involved and to reduce the possibility of overburdening anyone at any stage of this process.

#### Development
[Development]: #development

All development MUST adhere to project standards or guidance provided in pull request comments, including but not limited to:

  * **Coding style**; be consistent with the project even if it isn't your preference
  * **Testing**; add/remove/update tests as necessary given the type of development
      - *If and where possible, acceptance criteria should be codified into automated tests to prevent regression or mistaken removal.*
  * **Design patterns**; use common patterns and existing libraries before introducing more or new
  * **Documentation**; add/remove/update documentation as necessary given the type of development
  * **Security practices**; do not introduce vulnerabilities or divulge sensitive information

The changes included in the pull request SHOULD be minimized and focused only on the body of work defined in the [Planning] phase. Changes not pertinent to the body of work described and agreed upon in the [Planning] phase will be requested to be removed to another proposal unless the scope of the proposed change is agreed upon by both [Contributors] and [Maintainers].

If at any time there are questions about the acceptability of any contributions they should be raised at the time they are found and not left till the end or assumed to be acceptable. Questioning specific implementation details with the [Maintainers] is a good way to keep the communication current and will hopefully help with keeping work productive.

#### Completion
[Completion]: #completion

Once development has achieved the goals set out during the [Planning] phase anyone contributing to the development SHOULD indicate that the pull request is ready for final approval by posting a comment signifying that state change to the [Maintainers]. The final approval should be fairly trivial if they have been monitoring the development in the pull request regularly. Final approval and subsequent [Acceptance] should be quick but not guaranteed as things may have changed since the inception of the work but should not be a complete surprise as the [Maintainers] SHOULD be keeping [Contributors] informed about wide-impacting decisions proactively.

Final approval SHOULD follow any documented requirements by the project but MUST NOT be less than at least one [Maintainers] approval. How that is enforced or enacted is beyond the scope of this RFC.

#### Acceptance
[Acceptance]: #acceptance

This is the final step in the process. [Maintainers] take ownership of the pull request and all changes contained to schedule when and how best to incorporate/merge the changes. [Contributors] are not expected to maintain or support any contributions after the pull request is merged.

### Terms

These terms are used throughout this document and should have one definition (the definition below).

#### Contributors
[Contributors]: #contributors
[Contributor]: #contributors

Contributors are anyone who is not a member of the [Maintainers] team.

#### Maintainers
[Maintainers]: #maintainers
[Maintainer]: #maintainers

Maintainers are all team members responsible for the project; including but not limited to feature work and any on-call rotations or support efforts.

#### Response Times
[SLA]: #response-times

Response times for [Maintainers] SHOULD be as short as possible and SHOULD NOT exceed 24 hours - or the next business day in the event of weekends or holidays - even if the response is something akin to:

  > "We have seen your request but we will need a few days to gather/capture the needed information to properly respond, we will update with our answer/status in X days."

... where `X` is a specific timeframe that is reasonable for the request and an answer is not always required within that timeframe but an update as to why it is taking longer than expected SHOULD be provided to keep the requestor informed and involved.

## Drawbacks
[Drawbacks]: #drawbacks

### Too Much Process and Not Enough

This process documentation is verbose and yet potentially not exhaustive. Therefore, it could be introducing considerable overhead without being meaningfully comprehensive enough for its purpose. However, not having an agreed-upon standard for Federated Development has also created instances where confusion has escalated to conflict.

### Overwhelming Contributions

One concern to be aware of and proactively protect against is one of getting too many contributions coming in, such that they overwhelm the [Maintainers] attempting to maintain the project. A possibly more likely scenario might be too many contributions from [Contributors] across the many projects the [Maintainers] have responsibility for.

## Alternatives
[Alternatives]: #alternatives

Here are some community resources for more information; at least some were used for inspiration if not content directly:

  * https://opensource.guide/
  * https://opensource.com/
  * https://innersourcecommons.org/
  * https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9

## Unresolved (questions)
[Unresolved]: #unresolved-questions

### Contributor Timelines

There does remain the challenge of how to resolve the delivery requirements of [Contributors] and the review standards of [Maintainers]. Where the pull request would be "complete" from the perspective of the [Contributors] but not completely reviewed by the [Maintainers] and the timeline of the review does not work for the timeline of the submitting team.


text:
afterquery
==========

The fun begins after the serious analysts have gone home.

Afterquery is a pure-client-side javascript tool that downloads jsonp-formatted data from a given URL, applies a configurable series of transformations, and then renders the result as either a data table or a Google Visualizations (gviz) chart.

Although the javascript file happens to be hosted on a server, your data never gets uploaded; your browser handles all the processing steps internally. Also, the permissions to download the jsonp data depends on the cookies in your browser, so you can safely retrieve protected content without granting authorization to an external server.

repository: mardambey/afterquery

repo_name: mardambey/afterquery


text:
Sharepoint using .NET CORE 3.1 and Microsoft SharePoint Client component library

Description:

Endpoints:
* Get all documents in library (This endpoint does not support 5000+ entities).
    ```GET /api/sharepoint/documents?site=<sitename>&list=<listname>```
* List of libraries from a SharePoint site
    ```GET /api/sharepoint/lists?site=<sitename>```
* List of folders/documentsets from a sharepoint library
    ```GET /api/sharepoint/folders?site=<sitename>&list=<listname>```
* documents with metadata from sharepoint library
    ```GET /api/sharepoint/documentswithfields?site=<sitename>&list=<listname>```
* List of available fields on specific library
    ```GET /api/sharepoint/fields?site=<sitename>&list=<listname>```
* Return user id
    ```GET /api/sharepoint/userid?name=<email>```
* Array of folder names
    ```GET /api/sharepoint/foldernames?site=<sitename>&list=<listname>```
* Create new document
    ```
    POST /api/sharepoint/newdocument
    ```
* Delete a site
    ```
    DELETE /api/sharepoint/deletesite
    {
       "site": <"site name">
    }
    ```
* Create documentset
    ```
    POST /api/sharepoint/documentset
    {
        "site": <"site name">,
        "list" :<"list name">,
        "sitecontent" : <"site content name">,
        "documentset" : <"name of the new document set">,
     }
     ```
* SystemUpdate metadata
    ```
    POST /api/sharepoint/updatemetadata
    {
    	"ListName":"Documents",
    	"FileName":"Cyan.svg",
    	"FolderName":"My first document set",
    	"Fields":{
    			"BLAD":"9",
    			"BESKRIVELSE":"Beskrivelse updated",
    			"DOC_NO": "123433334455",
    			"DATO":"2020-01-01 04:00:00"

    	}
    }
    ```
* Upload file to sharepoint
    ```
    POST /api/sharepoint/UploadToSharePoint
    {
        "list":"Dokumentasjon",
        "file_url":"http://.....",
        "foldername":"Landskaps og miljøplan",
        "site": "sporaevk",
        "filename": "Postnummerregister-Excel.xlsx"
    }
    ```
* Upload file through SMB fileshare and update metadata
    ```
    POST /api/sharepoint/migration
    ```
* Upload file through SMB fileshare and update metadata
    ```
    POST /api/sharepoint/migrationoptimize
    ```
* Update metadata.
    ```
    POST /api/sharepoint/documentfix
    NB! works only on library that has eDocsDokumentnavn field name. Use only on lists with over 5000 documents
    ```
* Update existing document with SystemUpdate() to prevent version increment.
    ```
    POST /api/sharepoint/document
    ```
* Enrich metadata on documentset only
    ```
    POST /api/document/folderenrichment
    ```
* Enrich sharepoint library with overwriting version on library with 5000+ documents
    ```
    POST /api/document/updateoverwriteversion
    ```
* Enrich sharepoint library with 5000+ documents
    ```
    POST /api/document/UpdateWithoutVersioning
    ```
* Migration on library with versioning (used for existing library with 5000+)
    ```
    POST /api/document/MigrationWithVersioning
    ```
* List of documents (5000+)
    ```
    GET /api/document/all
    ```

repository: sesam-community/sharepoint-api

gha_language: C#

repo_name: sesam-community/sharepoint-api


text:
## Getting Started

Use go.cmd (Windows) or go.sh (OSX/Linux)

## Project Structure:

### Infra

docker / scripts / config for kibana / elastic search

### Ingest

clojure for csv -> elastic search

### Visualise

clojure for UI

## Event model

See: [Event Model](event_model.md)

repository: smbc-digital/signposts

repo_name: smbc-digital/signposts


text:
# Belonidium himalayensis (E. Müll. & Dennis) Raitv. SPECIES

#### Status
SYNONYM

#### According to
Index Fungorum

#### Published in
null

#### Original name
Perrotia himalayensis E. Müll. & Dennis

### Remarks
null

repository: mdoering/backbone

path: /life/Fungi/Ascomycota/Leotiomycetes/Helotiales/Hyaloscyphaceae/Belonidium/Belonidium himalayense/ Syn. Belonidium himalayensis/README.md

repo_name: mdoering/backbone


text:
# 21st Century C

## 2. Debug, Test, Document

### Debugger

**Always** use a debugger. Linux Torvalds considers the debugger like
dissasembler on steroids. Why not be able to increase logging verbosity on the
fly (`print verbose++`), or break out of a loop (`print i=100`) or similar?

Compilation options

  * debug symbols - `-g` (mandatory); downside: may increase size slightly
    * default level is 2 (`-g2`); level 3 includes macro information as well
    * `-ggdb` - ensures gdb specific debug info, not native os (so, even better)
  * optimizations - `-O0` (optional)

Debugging commands

  * printing expression (variable, function calls): `p var`
  * printing an array: `p *data@10`
  * see all local variables: `info local`
  * see arguments to the function: `info args`
  * see registers: `info r`
  * display variable on every step: `disp avg`
     * turn off autoprinting: `undisp 1`

  * call stack: `bt`
  * go to a frame: `f 1`
    * i,e,: to print data (variables) as they were in that frame, to see nothing
      got corrupted
  * go up and down the stack frames: `down`, `up`

  * see list of threads: `info threads`
    * debugger is in the one with `*`
  * move to another thread: `thread 2`

  * set breakpoint: `b function`, `b line`, `b file:line`
  * see breakpoints: `info break`
  * disable/enable: `dis 1`, `en 1`
  * delete breakpoint: `del 1`
  * break if the value of the given variable changes: `watch count`

  * next line, don't enter subfunctions: `n`
  * step online, enter subfunctions: `s`
  * continue unitl breakpoint: `c`
  * start over: `r`
    * run with args: `r args...`
  * until next line forward from current line (beyond current loop): `u`
  * return from current function: `ret`, `ret 3`

GDB init options

  * `set print thread-events off` - turn off thread spawning messages

repository: catalingheorghe/learning-activities

repo_name: catalingheorghe/learning-activities


text:
# Attigo

A report generator for Github issues that tracks what issues have been linked to most recently.

## Latin Definition

Definitions:

- belong to
- mention briefly

repository: chamons/attigo

repo_name: chamons/attigo