text:
---
layout: default
---

# 1995-09-03 - Re: Phil Zimmermann/Amnesty International?

## Header Data

From: "Perry E. Metzger"<EMAIL_ADDRESS>To<EMAIL_ADDRESS>(Alan Westrope)

Message Hash: 69d7545e5a101b1d489eca7c7586f7e005fe17474caab17d42220212ac283c23

Message ID<EMAIL_ADDRESS>Reply To<EMAIL_ADDRESS>UTC Datetime: 1995-09-03 07:14:55 UTC

Raw Date: Sun, 3 Sep 95 00:14:55 PDT

## Raw message

```
{% raw  %}From: "Perry E. Metzger"<EMAIL_ADDRESS>Date: Sun, 3 Sep 95 00:14:55 PDT
To<EMAIL_ADDRESS>(Alan Westrope)
Subject: Re: Phil Zimmermann/Amnesty International?
In-Reply-To<EMAIL_ADDRESS>Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

Alan Westrope writes:
> On Fri, 01 Sep 1995, Michael Froomkin<EMAIL_ADDRESS>wrote:
>
> > I think he would have to be charged first.  Have I missed something?
> > PS when does the statute of limitations run out?
>
> June '96.  Zimmermann and Dubois appeared on a local talk radio show
> recently; a friend happened to catch the program, taped it, and played
> excerpts at a Cypherpunks meeting.  This date was mentioned by Phil Dubois.

That's not possible. The offense in question took place on or before
September 8, 1992, and the statute of limitations is, to my knowledge,
three years. Even if it were four years, it would have to be September
8th of that year.  Branko Lankester announced availability of PGP 2.0
on Mon, 7 Sep 1992 at about 20:22 GMT, so since the allegation is that
he exported PGP Version 1.0 to the team that developed PGP 2.0
overseas, any export that Phil performed would have of necessity to
have taken place before then.

Michael, you are one of our local lawyers. Could you please confirm
the length of the statute of limitations?

Perry

{% endraw %}
```

## Thread

+ Return to [September 1995](/archive/1995/09)

+ Return to<EMAIL_ADDRESS>(Alan Westrope)](/authors/adwestro_at_ouray_cudenver_edu_alan_westrope_)"
+ Return to "[Brian Davis <bdavis@thepoint.net>](/authors/brian_davis_bdavis_at_thepoint_net_)"
+ Return to "[Deranged Mutant <rrothenb@ic.sunysb.edu>](/authors/deranged_mutant_rrothenb_at_ic_sunysb_edu_)"
+ Return to<EMAIL_ADDRESS>(Gary Jeffers)](/authors/gjeffers_at_socketis_net_gary_jeffers_)"
+ Return to "[hallam@w3.org](/authors/hallam_at_w3_org)"
+ Return to "[Jim Gillogly <jim@acm.org>](/authors/jim_gillogly_jim_at_acm_org_)"
+ Return to "[Michael Froomkin <mfroomki@umiami.ir.miami.edu>](/authors/michael_froomkin_mfroomki_at_umiami_ir_miami_edu_)"
+ Return to "["Perry E. Metzger" <perry@piermont.com>](/authors/perry_e_metzger_perry_at_piermont_com_)"
+ Return to "["Robert A. Hayden" <hayden@krypton.mankato.msus.edu>](/authors/robert_a_hayden_hayden_at_krypton_mankato_msus_edu_)"

+ 1995-09-01 (Fri, 1 Sep 95 00:17:18 PDT) - [Phil Zimmermann/Amnesty International?](/archive/1995/09/5bd4e65911825e5db2470b3ef6183922acdfd4c6c5b756a88a92e90211384341) -<EMAIL_ADDRESS>(Gary Jeffers)_
  + 1995-09-01 (Fri, 1 Sep 95 07:12:13 PDT) - [Re: Phil Zimmermann/Amnesty International?](/archive/1995/09/08a93c672a2d048c90c9389c70e7ecc710c404a63b5b8477a849b7b290fae2a2) - _Deranged Mutant<EMAIL_ADDRESS>    + 1995-09-01 (Fri, 1 Sep 95 15:34:33 PDT) - [Re: Phil Zimmermann/Amnesty International?](/archive/1995/09/621e189f38dc564a6efbc270b335cf826e60cb344133d1f3bee1e5e2603cc4ef) - _Michael Froomkin<EMAIL_ADDRESS>      + 1995-09-02 (Fri, 1 Sep 95 17:19:06 PDT) - [Re: Phil Zimmermann/Amnesty International?](/archive/1995/09/1292711565bc81337f7d7ffb81436b50b7f8fa8a339ec43006c84074915d249a) -<EMAIL_ADDRESS>(Alan Westrope)_
        + 1995-09-03 (Sun, 3 Sep 95 00:14:55 PDT) - Re: Phil Zimmermann/Amnesty International? - _"Perry E. Metzger"<EMAIL_ADDRESS>          + 1995-09-02 (Sat, 2 Sep 95 10:37:25 PDT) - [Re: Phil Zimmermann/Amnesty International?](/archive/1995/09/7db6265f9815ff25c2102bd7044cf169d899e7a08f8530707ea6a2e60fbbb87b) - _Jim Gillogly<EMAIL_ADDRESS>          + 1995-09-02 (Sat, 2 Sep 95 11:18:31 PDT) - [Re: Phil Zimmermann/Amnesty International?](/archive/1995/09/003db5ac14e8cd9553cd35db4f636425b41ebf971a290ecc6e0775a38db19dd1) -<EMAIL_ADDRESS>(Alan Westrope)_
          + 1995-09-02 (Sat, 2 Sep 95 14:07:04 PDT) - [Re: Phil Zimmermann/Amnesty International?](/archive/1995/09/2bb7da4f51c6a03f5c74b9f47f86e3da89c905478087b397aeee9ec52453e4e2) - _Michael Froomkin<EMAIL_ADDRESS>          + 1995-09-12 (Tue, 12 Sep 95 08:59:10 PDT) - [Re: Phil Zimmermann/Amnesty International?](/archive/1995/09/fc07bff7a0a60e9a50d8c1f6e47f7e9d722b0ac9d00270bb03c732c698ad72f7) -<EMAIL_ADDRESS>(Alan Westrope)_
        + 1995-09-07 (Thu, 7 Sep 95 08:55:48 PDT) - [Zimmerman's statute](/archive/1995/09/07cbdbaec03892f19a6a936a45efa52d6ebd6a66ed9ae1eb4b0afc3295165da9) - _Brian Davis<EMAIL_ADDRESS>      + 1995-09-02 (Fri, 1 Sep 95 17:50:45 PDT) - [Re: Phil Zimmermann/Amnesty International?](/archive/1995/09/e81d2e903bcc04bd55470adb0e860920ed1cf8cc163ec82c47147422eb911002) - _"Robert A. Hayden"<EMAIL_ADDRESS>      + 1995-09-02 (Fri, 1 Sep 95 17:51:13 PDT) - [Re: Phil Zimmermann/Amnesty International?](/archive/1995/09/8318f1ef912388184566de831a16ec5f7f1a79a0a659f9135c5a06991b650130) - _"Robert A. Hayden"<EMAIL_ADDRESS>      + 1995-09-02 (Fri, 1 Sep 95 17:58:17 PDT) - [Re: Phil Zimmermann/Amnesty International?](/archive/1995/09/865a1ca3264d1873929343d7e76d069a90793971230563b496610d5e4dbbbc79) -<EMAIL_ADDRESS>


text:
# Explore NATS Request/Reply

NATS supports [request/reply](../../nats-concepts/reqreply.md) messaging. In this tutorial you explore how to exchange point-to-point messages using NATS.

## Prerequisites

Go and the NATS server should be installed.

### 1. Start the NATS server

```bash
% nats-server
```

### 2. Start two terminal sessions

You will use these sessions to run the NATS request and reply clients.

### 3. Change to the examples directory

```bash
% cd $GOPATH/src/github.com/nats-io/nats.go/examples
```

### 4. In one terminal, run the reply client listener

```bash
% go run nats-rply/main.go help.please "OK, I CAN HELP!!!"
```

You should see the message: _Listening on \[help.please\]_

This means that the NATS receiver client is listening for requests messages on the "help.please" subject. In NATS, the receiver is a subscriber.

### 5. In the other terminal, run the request client

```bash
% go run nats-req/main.go help.please "I need help!"
```

The NATS requestor client makes a request by sending the message "I need help!" on the “help.please” subject.

The NATS receiver client receives the message, formulates the reply \("OK, I CAN HELP!!!"\), and sends it to the inbox of the requester.

branch_name: refs/heads/master

extension: md

license_type: permissive


text:
# Vue + Rollup Starter
A very simple boilerplate for creating a Vue project with single-page components. Running `npm run start` will create a single JS file and a single CSS file which can be directly attached to the main HTML file, the way our ancestors intended. It watches for any changes and automatically update the bundle. Once you're finished with development, run `npm run build` to create minified production-ready files.

Setting up a new frontend roject always feels like carrying a huge oversized boulder around when it really shouldn't be. The recommended scaffolding through Vue CLI is ridiculously heavy; I made this as a much lighter alternative.

Things included:
- Vue's single-page components
- Minification and ES2015-ready result through ESBuild
- Extract CSS into its own file through PostCSS
- Intended for use with PNPM, but there shouldn't be a problem if you use NPM or Yarn.

Things **not** included but you can easily add yourself:
- Server with hot-reload
- Linting
- CSS preprocessor

license: MIT

repository: PseudoMon/vue-rollup-starter

gha_language: JavaScript

gha_license_id: MIT

repo_name: PseudoMon/vue-rollup-starter


text:
---
layout: page_tree_paper
title: Sensor Fusion
---

Other subjects also has sensor fusion related content, while the papers here are more specific with multi-sensor fusion.

# Table of Contents
* [Lidar Image Summary 2022](#lliodar_image)
* [2022](#l2022)
* [2021](#l2021)
* [2020](#l2020)
* [2019](#l2019)
* [2018](#l2018)
* [2017](#l2017)

# Lidar Image summary (2022)

we normally have two types of systems :

* lidar based : camera pose as initial estimation and as constrain. I personal perfer this one, since our system is generally lidar based.
  * project lidar to camera, and form a vio odometry system. It wastes lots of calculation, I don't think it is necessary to maintain two slam system.
  * project camera information to lidar pts, to form lidar pts constrain. This seems more reasonable to me.
* camera based : lidar project to camera to offer depth

**visual-lidar-imu (with vins vio odometry)**

**visual-lidar-imu (with direct method image odometry)**

**Compare R3LIVE++, LVI-SAM and Mine:**

| R3LIVE++ | LVI-SAM | Mine |
|--------|---------|-----|
| single system | two system | single system |
| Optical flow tracking | Slide window VIO : VINS-MONO | Direct sparse tracking |
| with photometric calibration | without | with photometric calibration|
| Filter based LIO (FAST-LIO2) | Pose Graph Based LIO (LOAM) | Filter based LIO (FAST-LIO2) |

# 2022

 [R3LIVE++: A Robust, Real-time, Radiance reconstruction package with a tightly-coupled LiDAR-Inertial-Visual state Estimator](https://arxiv.org/abs/2209.03666), [github code](https://github.com/hku-mars/r3live)
following R3LIVE, with the camera photometric calibration and the online estimation of camera exposure time.

# 2021

 [R3LIVE: A Robust, Real-time, RGB-colored, LiDAR-Inertial-Visual tightly-coupled state Estimation and mapping package](https://arxiv.org/abs/2109.07982). Visual-Lidar-Imu filter.
* even though in its paper it said it has two system, it actually uses one single imu-based filter back bone. so it uses imu for filter predict, then has lidar and image measurements.
* use lidar pointcloud for VIO tracking, VIO system won't optimize map points.
* finally use MVS to make mesh (delaunay triangulation), 'texturing' is to update pcl color with the raw lidar map.

 [LVI-SAM: Tightly-coupled Lidar-Visual-Inertial Odometry via Smoothing and Mapping](https://github.com/TixiaoShan/LVI-SAM) (looks similar to V-LOAM + IMU) optimization with the following factors (with two system) (It is actually not so tightly coupled):

* Use lidar information in VINS (difference compared to VINS)
    * use lidar odometry pose for vins initialization
    * project lidar cloud to get vio feature depth neighbor pts model a plane,
    * feature depth in vins is anchored by the first observation. so here depth
      from lidar also valid only for first observation.
    * in marginalization if the marginalized pt has lidar depth, move its flags to the next.
    * set depth constant if has lidar depth.

* Use vision in VIO-SAM (difference compared to VIO-SAM)
    * use visual loop detection result as lidar loop candidate (to further process ICP).
    * use VINS pose as initial pose for lidar registration.

My implementation: I use FAST-LIO2 base instead of V-LOAM base.
* looks good while the movement is not too dramatic.
* while VINS is not stable when movement (for an example in car), or scene has lots of moving objects.

# 2020

 [CamVox](https://github.com/ISEE-Technology/CamVox), Lidar visual mapping using livox.

* Livox generate dense lidar cloud, match visual edge with lidar intensity image edge for extrinsic parameters calibration.
* IMU for lidar un-distortion.
* Run ORBSLAM2 RGBD pipeline.

 [Augmenting Visual Place Recognition with Structural Cues](http://rpg.ifi.uzh.ch/research_vo.html) Use both image (e.g. [NetVLAD 2016](https://arxiv.org/abs/1511.07247)) and 3d cloud (e.g.
[PointNetVLAD 2018](https://arxiv.org/abs/1804.03492)) encoders.

 [Stereo Localization in LiDAR Maps]https://github.com/tony1098/Stereo-Localization-in-LiDAR-Maps). Localize stereo camera in pre-built lidar map.

* Using ZED stereo camera, opencv (StereoSGBM and DisparityWLSFilter) to compute depth image.
* Registration using [Nelder-Mead method](https://en.wikipedia.org/wiki/Nelder%E2%80%93Mead_method).

  [RGB2LIDAR: Towards Solving Large-Scale Cross-Modal Visual Localization](https://arxiv.org/abs/2009.05695) DL match rgb image and depth image (from lidar cloud)

 [Lidar-Monocular Visual Odometry using Point and Line Features](https://cg.cs.tsinghua.edu.cn/people/~mtj/publications/ICRA2020-PL-LOAM.pdf) (loosely coupled)

* image -> point feature (ORB), line feature (LSD) -> project lidar to estimat depth -> odometry -> local BA current pose and landmarks.
* ICP relative pose factors.
* Global BA  using ICP factors, ORB factors, LSD factors.

 [LIC-Fusion 2.0: LiDAR-Inertial-Camera Odometry with Sliding-Window Plane-Feature Tracking](https://arxiv.org/abs/2008.07196) Tracking planes in the sliding window.

# 2019

  [CMRNet: Camera to LiDAR-Map Registration](https://github.com/cattaneod/CMRNet). Project a depth into plane (from an initial pose guess), CMRNet use RGB and depth as input, output 2D correspondings for each depth value. Finally PnP-RANSAC for pose estimation.

# 2018

 [LIMO: Lidar-Monocular Visual Odometry](https://arxiv.org/abs/1807.07524)

* Depth estiamtion : project lidar into image -> estimate local plane (select local range, foreground segmentation) -> check the depth.
* Visual Odometry, global BA.

# 2017

 [DSAC Differentiable RANSAC](https://github.com/cvlab-dresden/DSAC). replace non-differentiable parts of RANSAC algorithm with approximated differentiable parts (by soft argmax and probabilistic selection). Then make a deep learning DSAC. (As I understand, RANSAC is mathematically proved, I don't understand how its accuracy can be improved).

gha_language: HTML


text:
# Play Die
A simple play die app for the web and the mobile web.

## Version
version 1.2
this version can be visited on [my site](http://salihidesign.com/apps/playdie/v1.2/b2c30a/).

## Contribution and Bugs?
Please report any bugs or features to the Issues section. Thank you.

repository: alansalihi/playdie

repo_name: alansalihi/playdie


text:
---
id: find
title: find
---

## `find`

### Find by name

```shell
find -name "query"
find -iname "query" # Ignore case
find -not -name "query_to_avoid"
find \! -name "query_to_avoid"
```

### Find by type

```shell
find -type <type_descriptor> <query> # Basic usage
# Common type descriptors:
# f: File
# d: Directory
# l: Symlink
# c: Character device
# b: Block device

find /usr -type f -name "*.conf" # Search for files ending in `.conf` in `/usr` directory
find /usr -type f -and -name "*.conf" # Equivalent to above; `-and` combines two queries
find -name query_1 -or -name query_2 # `-or` returns results that match either expression
```

### Find by size

```shell
find -size <number><suffix> # Basic usage
# Common suffixes
# c: Bytes
# k: Kilobytes
# M: Megabytes
# G: Gigabytes
# b: 512-byte blocks

find /usr -size 50c # Find all files in `/usr` exactly 50 bytes in size
find /usr -size -50c # Less than 50 bytes in size
find /usr -size +600M # More than 600 megabytes in size
```

### Find by time

:::info

- **Access time (`atime`)**: The last time a file was read or written to.
- **Modification time (`mtime`)**: The last time the contents of the file were modified.
- **Change time (`ctime`)**: The last time the file’s inode metadata was changed.

:::

```shell
find /usr -mtime 1 # Files modified within the last day
find /usr -atime -1 # Accessed less than a day ago
find /usr -ctime +3 # Meta information changed more than 3 days ago
find /usr -mmin -1 # Modified within the last minute
find / -newer reference_file # Created/changed more recently than reference_file
```

### Find by owner

```shell
find / -user <user>
find / -group <group>
```

### Find by permissions

```shell
find / -perm 644
find / -perm -644 # Files with at least these permisions
```

### Find by depth

```shell
find -mindepth <num>
find -maxdepth <num>
```

### Execute commands on `find` results

Other commands can be executed on results returned by `find` using the `-exec`/`-delete` options or by piping the output to the [`xargs`](/notes/unix/xargs) command or [GNU Parallel](<https://en.wikipedia.org/wiki/Parallel_(software)>).

```shell
find <find_parameters> -exec <command_and_options> {} \;
find . -type d -perm 755 -exec chmod 700 {} \; # Change directory permissions from 755 to 700
find . -name "*.json" -delete # Delete files ending in `.json`

# Useful options
# -exec command {} +: Build command by appending each selected file name at the end, and then execute it
# -execdir: Run command from the subdirectory containing the matched file

find ./docs -type f -print | xargs rm
# Find all files in `./docs` and remove them

find . -name "*.foo" -print0 | xargs -0 grep bar
# Use the null character to delimit file names (necessary for dealing with filenames with `,` or space)

find . -name "*.foo" -print0 | parallel -0 grep bar
# Equivalent to above
```

## `locate`

:::info

`locate` is faster because it searches through a prebuilt database of files generated by the `updatedb` command or a cronjob automatically created during installation that runs every 24 hours. To manually update the database, use `sudo updatedb`.

:::

```shell
locate <query> # Return files whose full path names contain the query
locate -b <query> # Return only files whose names contain the query
locate -n 10 *.py # Limit to 10 results; Wildcard search
locate -i readme.md # Case-insensitive search
locate -c *.md # Display number of found entries
locate -S # Print statistics about each used database
```

## `whereis`

`whereis` command can be used to efficiently locate the binary, source, and manual page files for a command.

```shell
> whereis rg
rg: /usr/bin/rg /usr/share/man/man1/rg.1.gz
```

## `which`

`which` searches for the binary for a command in your `PATH`.

```shell
> which rg
/usr/bin/rg
```

## `fd`

:::info

[oh-my-zsh](https://github.com/ohmyzsh/ohmyzsh/)'s [common-aliases](https://github.com/ohmyzsh/ohmyzsh/blob/master/plugins/common-aliases/common-aliases.plugin.zsh) plugin aliases `fd` to `find . -type d -name`. To avoid the clash between this alias and `fd`, put `unalias fd` or `alias fd='\fd'` at the end of your `.zshrc`.

:::

### Basic usage

```shell
fd [options] <pattern> <path> # Basic usage
fd # List all files in current directory recursively, similar to `ls -R`

fd netfl # Basic search; Recursively search current directory for the pattern `netfl`
fd '^x.*rc$' # Regex search; Search for entries that start with `x` and end with `rc`
fd '^x.*rc$' /etc # Search in `/etc` directory
fd -g libc.so /usr # Glob-based search; Find all `libc.so` files in `usr`

# Useful options
# -H, --hidden: Search in hidden directories
# -I, --no-ignore: Search directories and show files that match `.gitignore` patterns
# -p, --full-path: Search in full paths instead of just filenames
# -l, --list-details: Use a long listing format with file metadata
# -L, --follow: Follow symbolic links
```

### Find by type

```shell
fd -t <filetype> <pattern>
# Common filetypes:
# f: File
# d: Directory
# l: Symlink
# x: Executable
# e: Empty
# s: Socket
# p: Pipe
```

### Find by size

```shell
fd -s <size> <pattern>
```

### Find by time

```shell
fd --changed-within <date|dur> <pattern> # Filter by file modification time (newer than)
fd --changed-before <date|dur> <pattern> # Filter by file modification time (older than)
```

### Find by depth

```shell
fd -d <depth> <pattern> # Set maximum search depth
```

### Find by extension

```shell
fd -e json # Find files with `.json` extension
fd -e json <pattern> # Find json files that contain the pattern
```

### Exclude files and directories

```shell
fd -E '*.zip' <pattern> # Exclude zip files
fd -H -E .git <pattern> # Search in hidden dirs but exclude matches from `.git`
# You can create a `.fdignore` file (similar to `.gitignore`) to make exclude-patterns permanent.
```

### Execute commands on `fd` results

```shell
# -x, --exec <cmd>: Execute a command for each search result
# -X, --exec-batch <cmd>: Execute a command with all search results at once

fd -e zip -x unzip # Recursively find and unzip all zip archives
fd -e h -e cpp -x clang-format -i # Find all `*.h` and `*.cpp` files and auto-format them inplace with `clang-format -i`

fd -g 'test_*.py' -X vim # Find all `test_*.py` files and open them with `vim`
# https://vimhelp.org/usr_07.txt.html#07.2

fd -H '^\.DS_Store$' -tf -X rm # Recursively remove all `.DS_Store` files
```

### Placeholder tokens

```shell
fd -e jpg -x convert {} {.}.png # Convert all `*.jpg` files to `*.png` files
# `{}` will be replaced by the path of the search result (`docs/images/party.jpg`)

# Other placeholder tokens
# {.}: Like {}, but without the file extension (`docs/images/party`)
# {/}: The basename of the search result (`party.jpg`)
# {//}: The parent of the discovered path (`docs/images`)
# {/.}: The basename without the extension (`party`)
```

branch_name: refs/heads/main


text:
# Finnish Personal Identity Code Validator

Validates Finnish Personal Identity Code (Finnish: henkilötunnus / HETU).

## Format of Code

A code consists of eleven characters of the form DDMMYYCZZZQ, where
DDMMYY is the day, month and year of birth, C the century sign, ZZZ
the individual number and Q the control character (checksum).

Individual numbers 900–999 are used for temporary personal identification.

## Examples

    iex> FinnishPic.validate("131052-308T")
    {:ok, %FinnishPic{
      birth_date: ~D[1952-10-13],
      gender: :female,
      temporary_id: false
    }}

    iex> FinnishPic.validate("931052-308T")
    {:error, :invalid_date}

## Notes

Implementation only validates the Personal Identity Code and does not tell if
it is really used.

repository: floftar/finnish-pic

repo_name: floftar/finnish-pic


text:
---
title: IVisitor
description: API reference for IVisitor in Vendr, the eCommerce solution for Umbraco v8+
---
## IVisitor

```csharp
public interface IVisitor
```

**Namespace**
* [Vendr.Core.Visitors](../)

### Methods

#### Visit<TElement>

```csharp
public void Visit<TElement>(TElement element, IVisitContext context)
    where TElement : IVisitable
```

<!-- DO NOT EDIT: generated by xmldocmd for Vendr.Core.dll -->

repository: vendrhub/vendr-documentation

gha_language: Batchfile

repo_name: vendrhub/vendr-documentation


text:
# Sex Education for the modern world
Too often we think of sex education as being about penises and vaginas, about infections and babies, but the reality is that sex is about intamacy. It's time our sexual education reflected that.

We owe many thanks to the National Coalition for Sexual Health and Altarum, who developed structure of our sexual education framework. (insert additional credit here)

---

## Sexual Wellness in Five Easy Steps
1. Respect Yourself
2. Define Boundaries
3. Do Unto Others
4. Practice Positivity
5. Be Proactive

---

## Lesson Plans
Below are some thoughts about what to focus on and desired outcomes when designing your own cirricullum.

### Respect Yourself
**Outcome:** Build self-esteem and self-respect.

### Define Boundaries
**Outcome:** Feel okay saying no. Determine what you want to explore and what you don't.

### Do Unto Others
**Outcome:** Help your partner(s) respect themselves and define their boundaries.

### Practice Positivity
**Outcome:** Make time for your partner(s) and help each other grow.

### Be Proactice
**Outcome:** Get tested, and tell people about it!


text:
# morphCase
A micro Java library to change the cases of Strings. More variations will be added as time permits.
##### Author : ArvindCheenu.

### Constructors

| Constructors | Description |
--- | --- |
*morphCase* ()  | Initialises normalCase as an empty string.
*morphCase* (String)  | Initialises normalCase as the entered string.

### Getters and Setters

| Functions | Description |
--- | --- |
*getNormalCase* ()  | Returns the string of the instance.
*setNormalCase* (String)  | Returns the instance of normalCase
set as the entered string.

### String Case Functions

| Functions | Syntax | Output | Description |
--- | --- | --- | --- |
.*toTitleCase* () | ```morphCase test = new morphCase("test string");   test.toTitleCase();```|`Test String`| returns String converted to Title Case.
.*toUppercase* () | ```morphCase test = new morphCase("test string");   test.toUpperCase();```|`TEST STRING`| returns String converted to Upper Case.
.*toLowerCase* () | ```morphCase test = new morphCase("TEST STRING");   test.toLowerCase();```|`test string`| returns String converted to Lower Case.
.*toCamelCase* () | ```morphCase test = new morphCase("TEST STRING");   test.toCamelCase();```|`testString`| returns String converted to Camel Case.
.*toDotcase* () | ```morphCase test = new morphCase("TEST STRING");   test.toDotcase();```|`test.string`| returns String converted to Dot Case.
.*toConstantCase* () | ```morphCase test = new morphCase("test string");   test.toConstantCase();```|`TEST_STRING`| returns String converted to Constant Case.
.*toHeaderCase* () | ```morphCase test = new morphCase("TEST STRING");   test.toHeaderCase();```|`Test-String`| returns String converted to Header Case.
.*toParamCase* () | ```morphCase test = new morphCase("TEST STRING");   test.toParamCase();```|`test-string`| returns String converted to Param Case.
.*toPascalCase* () | ```morphCase test = new morphCase("TEST STRING");   test.toPascalCase();```|`TestString`| returns String converted to Pascal Case.
.*toPathCase* () | ```morphCase test = new morphCase("TEST STRING");   test.toPathCase();```|`test/string`| returns String converted to Path Case.
.*toSnakeCase* () | ```morphCase test = new morphCase("TEST STRING");   test.toSnakeCase();```|`test_string`| returns String converted to Snake Case.
.*toInvertCase* () |  ```morphCase test = new morphCase("Test String");   test.toInvertCase();```|`tEST sTRING`| returns String with swapped Case.
.*toPercentCase* () |  ```morphCase test = new morphCase("Test String");   test.toPercentCase();```|`Test20%String`| returns String with Percent Case, used for URL encoding of Reserved and Non-UnReserved Characters.

## Usage

Simply add the JAR file in this repository and include it as an external dependency library (by selecting `Add External JAR Libraries...` in **Eclipse** while creating a new project.) while creating any project.

## License

#### MIT License

##### *Copyright (c) 2017 arvindcheenu*

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

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

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

    by

repository: isarvindone/morphCase

repo_name: isarvindone/morphCase


text:
---
layout: post
comments: true
title: My stint as a problem setter at Codechef
---

The problem statement of P vs NP appears to be deceptively simple on the surface, but it is colossal underneath. The main objective is to determine whether there exist problems whose solution can be quickly checked, but which require an impossibly long time to solve by any direct procedure.

I havn't yet dared to solve P vs NP, but as of now my interest particularly lies in formulating approximation algorithms for hard graph theoretic problems. In this context I would like to thank **Team Codechef** for giving me opportunity to write the following approximation problems for their long contests.

1.KALI AND DEVTAS

2.EMBEDDING

3.SOCIAL CLUSTER

4.FIGHTING EBOLA

I look forward to come up with more interesting problems. Stay tuned at CODECHEF.


text:
# Container Object Storage Interface (COSI)

Authors:

* Sidharth Mani [@wlan0](https://github.com/wlan0)
* Jeff Vance [@jeffvance](https://github.com/jeffvance)
* Srini Brahmaroutu [@brahmaroutu](https://github.com/brahmaroutu)

## Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC 2119](http://tools.ietf.org/html/rfc2119) (Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997).

The key words "unspecified", "undefined", and "implementation-defined" are to be interpreted as described in the [rationale for the C99 standard](http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf#page=18).

An implementation is not compliant if it fails to satisfy one or more of the MUST, REQUIRED, or SHALL requirements for the protocols it implements.
An implementation is compliant if it satisfies all the MUST, REQUIRED, and SHALL requirements for the protocols it implements.

## Terminology

| Term              | Definition                                       |
|-------------------|--------------------------------------------------|
| Bucket            | A flat organization that contains immutable objects.                          |
| Brownfield Bucket | An existing back-end bucket.                        |
| Greenfield Bucket | A new back-end bucket created by COSI.                        |
|COSI  System              | Container Orchestration system/ Container Object Storage Implementation, communicates with Plugins using COSI service RPCs.                                     |
| SP                | Object Storage Provider, the vendor of a COSI plugin implementation.                                                          |
| CO                | Container Orchestrator, like Kubernetes.                                                          |
| RPC/gRPC               | [Remote Procedure Call](https://en.wikipedia.org/wiki/Remote_procedure_call).                                         |
| Node              | A host where the user workload will be running, uniquely identifiable from the perspective of a Plugin by a node ID. |
| COSI Driver(aka Plugin)           | Aka “plugin implementation”, a gRPC endpoint that implements the COSI Services.                                        |
| Sidecar (aka Provisioner Sidecar) | A COSI process that interfaces with the Plugin.                                                       |
|COSI Node Adapter (aka CSI Driver) | A process that accepts gRPC calls from the Kubelet notifying it when the workload has been started and when it is terminating. |
| Provisioner | A generic term meant to describe the combination of a sidecar and COSI driver. "Provisioning" a bucket can mean creating a new bucket or granting access to an existing bucket.                                                       |
| Workload          | The atomic unit of "work" scheduled by a COSI System. This MAY be a container or a collection of containers.                   |

## Objective

To define a standard “Container Object Storage Interface” (COSI) that enables a storage vendor (SP) to develop an RPC-based plugin once and have it work across multiple Kubernetes clusters and on other COs.

### Goals in MVP

The Container Object Storage Interface (COSI) will:

* Enable SP authors to write one COSI compliant RPC Plugin that “just works” across all COs that implement COSI.
* Define API (RPCs) that enable:
  * Dynamic provisioning and de-provisioning of a bucket.
  * Ability to define bucket access control mechanisms
  * Consumption of both existing and new buckets created on SP.
  * Define plugin protocol recommendations.
  * Describe a process by which an admin configures a Plugin.
  * COSI deployments and templates.

### Non-Goals in MVP

The Container Object Storage Interface (COSI) spec explicitly will not define, provide, or dictate:

* Specific mechanisms by which a Provisioner Sidecar manages the lifecycle of a Plugin, including:
  * How to deploy, install, upgrade, uninstall, monitor, or respawn (in case of unexpected termination) Plugins.
* A first class message structure/field to represent "grades of object storage" (aka "bucket class").
* Protocol-level authentication and authorization.
* Packaging of a Plugin.

## Solution Overview

This specification defines an interface along with the minimum operational and packaging recommendations for a storage provider (SP) to implement a COSI compatible plugin.
The interface declares the RPCs that a plugin MUST expose: this is the **primary focus** of the COSI specification.
Any operational and packaging recommendations offer additional guidance to promote cross-COSI system compatibility.

### Architecture

The primary focus of this specification is on the RPC **protocol** between a COSI System and a Plugin.
It SHOULD be possible to ship cross-COSI system compatible Plugins for a variety of deployment architectures.
A COSI system SHOULD be equipped to handle both centralized and headless plugins.
Interaction of these components is illustrated in the  figure below.

```
                    COSI System "Master" Host
+-------------------------------------------+
|                                           |
|  +------------+           +------------+  |
|  |   COSI     |   gRPC    | Controller |  |
|  |   System   +----------->   Plugin   |  |
|  +------------+           +------------+  |
|                                           |
+-------------------------------------------+

```
Figure 1: Plugin deployment, all of the COSI system Node hosts run Plugins.

![Cosi Components](cosicomponents.png)

Figure 2: Kubernetes implementation - Interaction of COSI components

### Bucket Lifecycle

```
     CreateBucket +-------------+ DeleteBucket
    +------------->|  CREATED   +--------------+
    |              +---+----^---+              |
    |          Grant   |    | Revoke           v
    +++        Bucket  |    | Bucket          +++
    |X|        Access  |    | Access          | |
    +-+            +---v----+---+             +-+
                   |   BOUND    |
                   +---+----^---+

```
Figure 3: The lifecycle of a dynamically provisioned bucket, from
creation to deletion.

The above diagrams illustrate a general expectation with respect to how a COSI system MAY manage the lifecycle of a bucket via the API presented in this specification.
Plugins SHOULD expose all RPCs for an interface: Controller plugins SHOULD implement all RPCs for the  service.
Unsupported RPCs SHOULD return an appropriate error code that indicates such (e.g. `UNIMPLEMENTED`).

## Container Object Storage Interface

This section describes the interface between COSI systems and Plugins.

### RPC Interface

A CO interacts with an Plugin through RPCs.
Each SP MUST provide:

* **Plugin**: A gRPC endpoint serving COSI RPCs that MUST be run on the Node.

```protobuf
syntax = "proto3";
package cosi.v1alpha1;

import "google/protobuf/descriptor.proto";

option go_package = "sigs.k8s.io/container-object-storage-interface-spec;cosi";

extend google.protobuf.EnumOptions {
    // Indicates that this enum is OPTIONAL and part of an experimental
    // API that may be deprecated and eventually removed between minor
    // releases.
    bool alpha_enum = 1116;
}

extend google.protobuf.EnumValueOptions {
    // Indicates that this enum value is OPTIONAL and part of an
    // experimental API that may be deprecated and eventually removed
    // between minor releases.
    bool alpha_enum_value = 1116;
}

extend google.protobuf.FieldOptions {
    // Indicates that a field MAY contain information that is sensitive
    // and MUST be treated as such (e.g. not logged).
    bool cosi_secret = 1115;

    // Indicates that this field is OPTIONAL and part of an experimental
    // API that may be deprecated and eventually removed between minor
    // releases.
    bool alpha_field = 1116;
}

extend google.protobuf.MessageOptions {
    // Indicates that this message is OPTIONAL and part of an experimental
    // API that may be deprecated and eventually removed between minor
    // releases.
    bool alpha_message = 1116;
}

extend google.protobuf.MethodOptions {
    // Indicates that this method is OPTIONAL and part of an experimental
    // API that may be deprecated and eventually removed between minor
    // releases.
    bool alpha_method = 1116;
}

extend google.protobuf.ServiceOptions {
    // Indicates that this service is OPTIONAL and part of an experimental
    // API that may be deprecated and eventually removed between minor
    // releases.
    bool alpha_service = 1116;
}

service Identity {
    // This call is meant to retrieve the unique provisioner Identity.
    // This identity will have to be set in BucketRequest.Provisioner field in order to invoke this specific provisioner.
    rpc ProvisionerGetInfo (ProvisionerGetInfoRequest) returns (ProvisionerGetInfoResponse) {}
}

service Provisioner {
    // This call is made to create the bucket in the backend.
    // This call is idempotent
    //    1. If a bucket that matches both name and parameters already exists, then OK (success) must be returned.
    //    2. If a bucket by same name, but different parameters is provided, then the appropriate error code ALREADY_EXISTS must be returned.
    rpc ProvisionerCreateBucket (ProvisionerCreateBucketRequest) returns (ProvisionerCreateBucketResponse) {}
    // This call is made to delete the bucket in the backend.
    // If the bucket has already been deleted, then no error should be returned.
    rpc ProvisionerDeleteBucket (ProvisionerDeleteBucketRequest) returns (ProvisionerDeleteBucketResponse) {}

    // This call grants access to an account. The account_name in the request shall be used as a unique identifier to create credentials.
    // The account_id returned in the response will be used as the unique identifier for deleting this access when calling ProvisionerRevokeBucketAccess.
    rpc ProvisionerGrantBucketAccess (ProvisionerGrantBucketAccessRequest) returns (ProvisionerGrantBucketAccessResponse);
    // This call revokes all access to a particular bucket from a principal.
    rpc ProvisionerRevokeBucketAccess (ProvisionerRevokeBucketAccessRequest) returns (ProvisionerRevokeBucketAccessResponse);
}

// S3SignatureVersion is the version of the signing algorithm for all s3 requests
enum S3SignatureVersion {
    UnknownSignature = 0;
    // S3V2, Signature version v2
    S3V2 = 1;
    // S3V4, Signature version v4
    S3V4 = 2;
}

enum AnonymousBucketAccessMode {
    UnknownBucketAccessMode = 0;
    // Default, disallow uncredentialed access to the backend storage.
    Private = 1;
    // Read only, uncredentialed users can call ListBucket and GetObject.
    ReadOnly = 2;
    // Write only, uncredentialed users can only call PutObject.
    WriteOnly = 3;
    // Read/Write, uncredentialed users can read objects as well as PutObject.
    ReadWrite = 4;
}

message S3 {
    // region denotes the geographical region where the S3 server is running
    string region = 1;
    // signature_version denotes the signature version for signing all s3 requests
    S3SignatureVersion signature_version = 2;
}

message AzureBlob {
    // storage_account is the id of the azure storage account
    string storage_account = 1;
}

message GCS {
    // private_key_name denotes the name of the private key in the storage backend
    string private_key_name = 1;
    // project_id denotes the name of the project id in the storage backend
    string project_id = 2;
    // service_account denotes the name of the service account in the storage backend
    string service_account = 3;
}

message Protocol {
    oneof type {
        S3 s3 = 1;
        AzureBlob azureBlob = 2;
        GCS gcs = 3;
    }
}

message ProvisionerGetInfoRequest {
    // Intentionally left blank
}

message ProvisionerGetInfoResponse {
    // This field is REQUIRED
    // The name MUST follow domain name notation format
    // (https://tools.ietf.org/html/rfc1035#section-2.3.1). It SHOULD
    // include the plugin's host company name and the plugin name,
    // to minimize the possibility of collisions. It MUST be 63
    // characters or less, beginning and ending with an alphanumeric
    // character ([a-z0-9A-Z]) with dashes (-), dots (.), and
    // alphanumerics between.
    string name = 1;
}

message ProvisionerCreateBucketRequest {
    // This field is REQUIRED
    // name specifies the name of the bucket that should be created.
    string name = 1;

    // This field is REQUIRED
    // Protocol specific information required by the call is passed in as key,value pairs.
    Protocol protocol = 2;

    // This field is OPTIONAL
    // The caller should treat the values in parameters as opaque.
    // The receiver is responsible for parsing and validating the values.
    map<string,string> parameters = 3;
}

message ProvisionerCreateBucketResponse {
    // bucket_id returned here is expected to be the globally unique
    // identifier for the bucket in the object storage provider
    string bucket_id = 1;
}

message ProvisionerDeleteBucketRequest {
    // This field is REQUIRED
    // bucket_id is a globally unique identifier for the bucket
    // in the object storage provider
    string bucket_id = 1;
}

message ProvisionerDeleteBucketResponse {
    // Intentionally left blank
}

message ProvisionerGrantBucketAccessRequest {
    // This field is REQUIRED
    // bucket_id is a globally unique identifier for the bucket
    // in the object storage provider
    string bucket_id = 1;

    // This field is REQUIRED
    // account_name is a identifier for object storage provider
    // to ensure that multiple requests for the same account
    // result in only one access token being created
    string account_name = 2;

    // This field is REQUIRED
    // Requested Access policy, ex: {"Effect":"Allow","Action":"s3:PutObject","Resource":"arn:aws:s3:::profilepics/*"}
    string access_policy = 3;

    // This field is OPTIONAL
    // The caller should treat the values in parameters as opaque.
    // The receiver is responsible for parsing and validating the values.
    map<string,string> parameters = 4;
}

message ProvisionerGrantBucketAccessResponse {
    // This field is OPTIONAL
    // This is the account_id that is being provided access. This will
    // be required later to revoke access.
    string account_id = 1;

    // This field is OPTIONAL
    // Credentials supplied for accessing the bucket ex: aws access key id and secret, etc.
    string credentials = 2;
}

message ProvisionerRevokeBucketAccessRequest {
    // This field is REQUIRED
    // bucket_id is a globally unique identifier for the bucket
    // in the object storage provider.
    string bucket_id = 1;

    // This field is REQUIRED
    // This is the account_id that is having its access revoked.
    string account_id = 2;
}

message ProvisionerRevokeBucketAccessResponse {
    // Intentionally left blank
}

```

#### Concurrency

In general the Cluster Orchestrator (CO) is responsible for ensuring that there is no more than one call “in-flight” per Bucket at a given time.
Multiple calls to CreateBucket may result in error 'ALREADY_EXISTS' if the call succeeded early. Similarly DeleteBucket, GrantBucketAccess, RevokeBucketAccess will behave the same.

#### Field Requirements

The requirements documented herein apply equally and without exception, unless otherwise noted, for the fields of all protobuf message types defined by this specification.
Violation of these requirements MAY result in RPC message data that is not compatible with all COSI systems, Plugin, and/or COSI middleware implementations.

##### Size Limits

COSI defines general size limits for fields of various types (see table below).
The general size limit for a particular field MAY be overridden by specifying a different size limit in said field's description.
Unless otherwise specified, fields SHALL NOT exceed the limits documented here.
These limits apply for messages generated by both COSI systems and plugins.

| Size       | Field Type          |
|------------|---------------------|
| 128 bytes  | string              |
| 4 KiB      | map<string, string> |

##### `REQUIRED` vs. `OPTIONAL`

* A field noted as `REQUIRED` MUST be specified, subject to any per-RPC caveats; caveats SHOULD be rare.
* A `repeated` or `map` field listed as `REQUIRED` MUST contain at least 1 element.
* A field noted as `OPTIONAL` MAY be specified and the specification SHALL clearly define expected behavior for the default, zero-value of such fields.

Scalar fields, even REQUIRED ones, will be defaulted if not specified and any field set to the default value will not be serialized over the wire as per [proto3](https://developers.google.com/protocol-buffers/docs/proto3#default).

#### Timeouts

Any of the RPCs defined in this spec MAY timeout and MAY be retried.
The COSI system MAY choose the maximum time it is willing to wait for a call, how long it waits between retries, and how many time it retries (these values are not negotiated between plugin and COSI system).

Idempotency requirements ensure that a retried call with the same fields continues where it left off when retried.
The only way to cancel a call is to issue a "negation" call if one exists.
For example, issue a `DeleteBucket` call to cancel a pending `CreateBucket` operation, etc.

### Error Scheme

All COSI API calls defined in this spec MUST return a [standard gRPC status](https://github.com/grpc/grpc/blob/master/src/proto/grpc/status/status.proto).
Most gRPC libraries provide helper methods to set and read the status fields.

The status `code` MUST contain a [canonical error code](https://github.com/grpc/grpc-go/blob/master/codes/codes.go). COSI systems MUST handle all valid error codes. Each RPC defines a set of gRPC error codes that MUST be returned by the plugin when specified conditions are encountered. In addition to those, if the conditions defined below are encountered, the plugin MUST return the associated gRPC error code.

| Condition | gRPC Code | Description | Recovery Behavior |
|-----------|-----------|-------------|-------------------|
| Missing required field | 3 MISSING_ARGUMENT | Indicates that a required field is missing from the request. More human-readable information MAY be provided in the `status.message` field. | Caller MUST fix the request by adding the missing required field before retrying. |
| Invalid or unsupported field in the request | 3 INVALID_ARGUMENT | Indicates that the one or more fields in this field is either not allowed by the Plugin or has an invalid value. More human-readable information MAY be provided in the gRPC `status.message` field. | Caller MUST fix the field before retrying. |
| Permission denied | 7 PERMISSION_DENIED | The Plugin is able to derive or otherwise infer an identity from the secrets present within an RPC, but that identity does not have permission to invoke the RPC. | System administrator SHOULD ensure that requisite permissions are granted, after which point the caller MAY retry the attempted RPC. |
| Operation pending for bucket | 10 ABORTED | Indicates that there is already an operation pending for the specified bucket. In general the Cluster Orchestrator (CO) is responsible for ensuring that there is no more than one call "in-flight" per bucket at a given time. However, in some circumstances, the COSI system MAY lose state (for example when the COSI system crashes and restarts), and MAY issue multiple calls simultaneously for the same bucket. The Plugin, SHOULD handle this as gracefully as possible, and MAY return this error code to reject secondary calls. | Caller SHOULD ensure that there are no other calls pending for the specified volume, and then retry with exponential back off. |
| Call not implemented | 12 UNIMPLEMENTED | The invoked RPC is not implemented by the Plugin or disabled in the Plugin's current mode of operation. | Caller MUST NOT retry. Caller MAY call `GetPluginInfo` to discover Plugin info. |
| Not authenticated | 16 UNAUTHENTICATED | The invoked RPC does not carry secrets that are valid for authentication. | Caller SHALL either fix the secrets provided in the RPC, or otherwise regalvanize said secrets such that they will pass authentication by the Plugin for the attempted RPC, after which point the caller MAY retry the attempted RPC. |

The status `message` MUST contain a human readable description of error, if the status `code` is not `OK`.
This string MAY be surfaced by COSI system to end users.

The status `details` MUST be empty. In the future, this spec MAY require `details` to return a machine-parsable protobuf message if the status `code` is not `OK` to enable COSI system's to implement smarter error handling and fault resolution.

### Provisioner Service RPC

Provisioner service RPCs allow a COSI system to query a plugin for information, create and delete bucket as well as grant and revoke access to the bucket to various principals running the workload.
The general flow of the success case MAY be as follows (protos illustrated in YAML for brevity):

1. COSI system queries metadata via Identity RPC.

```
   # COSI system --(ProvisionerGetInfo)--> Plugin
   request:
   response:
      name: org.foo.whizbang.super-plugin
      version: blue-green
      manifest:
        baz: qaz
```
```
message ProvisionerGetInfoRequest {
    // Intentionally left blank
}

message ProvisionerGetInfoResponse {
    string name = 1;
    string version = 2;
    map<string,string> manifest = 3;
}
```

#### `ProvisionerCreateBucket`

A Controller Plugin MUST implement this RPC call.
This RPC will be called by the COSI system to provision a new bucket on behalf of a COSI user.

This operation MUST be idempotent.
If a volume corresponding to the specified bucket `name` already exists, is accessible from `accessibility_requirements, and is compatible with the specified attributes of the bucket in the `ProvisionerCreateBucket`, the Plugin MUST reply `0 OK` with the corresponding `ProvisionerCreateBucketResponse`.

```
message ProvisionerCreateBucketRequest {
    // Idempotency - This name is generated by the COSI system to achieve
    // idempotency.
    // This field is REQUIRED.
    string bucket_name = 1;

    // This field is OPTIONAL
    // Protocol specific information required by the call is passed in as key,value pairs.
    map<string,string> bucket_context = 2;
}

message ProvisionerCreateBucketResponse {
    // Intentionally left blank
}

```
##### CreateBucket Errors

If the plugin is unable to complete the CreateBucket call successfully, it MUST return a non-ok gRPC code in the gRPC status.
If the conditions defined below are encountered, the plugin MUST return the specified gRPC error code.
The COSI system MUST implement the specified error recovery behavior when it encounters the gRPC error code.

| Condition | gRPC Code | Description | Recovery Behavior |
|-----------|-----------|-------------|-------------------|
| Bucket Name invalid | 3 INVALID_ARGUMENT | Besides the general cases, this code MUST also be used to indicate when plugin cannot create a bucket due to parameter check on the backend. More human-readable information SHOULD be provided in the gRPC `status.message` field for the problem. | Caller should retry call with corrected parameter values.|
| Bucket already exists but is incompatible | 6 ALREADY_EXISTS | Indicates that a bucket corresponding to the specified bucket `name` already exists but is incompatible with the specified attributes. | Caller MUST fix the arguments or use a different `name` before retrying. |
| Unsupported value | 11 OUT_OF_RANGE | Indicates that the value requested cannot be used to provision the bucket. | Caller MUST fix the attributes before retrying. |

### Secrets Requirements (where applicable)

Secrets MAY be required by plugin to complete a RPC request.
A secret is a string to string map where the key identifies the name of the secret (e.g. "username" or "password"), and the value contains the secret data (e.g. "bob" or "abc123").
Each key MUST consist of alphanumeric characters, '-', '_' or '.'.
Each value MUST contain a valid string.
An SP MAY choose to accept binary (non-string) data by using a binary-to-text encoding scheme, like base64.
An SP SHALL advertise the requirements for required secret keys and values in documentation.
COSI system SHALL permit passing through the required secrets.
A COSI system MAY pass the same secrets to all RPCs, therefore the keys for all unique secrets that an SP expects MUST be unique across all COSI operations.
This information is sensitive and MUST be treated as such (not logged, etc.) by the COSI system.

## Protocol

### Connectivity

* A COSI system SHALL communicate with a Plugin using gRPC to access the `Provisioner` service.
  * proto3 SHOULD be used with gRPC, as per the [official recommendations](http://www.grpc.io/docs/guides/#protocol-buffer-versions).
  * All Plugins SHALL implement the REQUIRED Identity service RPCs.
* The COSI system SHALL provide the listen-address for the Plugin by way of the `COSI_ENDPOINT` environment variable.
  Plugin components SHALL create, bind, and listen for RPCs on the specified listen address.
  * Only UNIX Domain Sockets MAY be used as endpoints.
    This will likely change in a future version of this specification to support non-UNIX platforms.
* All supported RPC services MUST be available at the listen address of the Plugin.

### Security

* The COSI system operator and Provisioner Sidecar SHOULD take steps to ensure that any and all communication between the COSI system and Plugin Service are secured according to best practices.
* Communication between a COSI system and a Plugin SHALL be transported over UNIX Domain Sockets.
  * gRPC is compatible with UNIX Domain Sockets; it is the responsibility of the COSI system operator and Provisioner Sidecar to properly secure access to the Domain Socket using OS filesystem ACLs and/or other OS-specific security context tooling.
  * SP’s supplying stand-alone Plugin controller appliances, or other remote components that are incompatible with UNIX Domain Sockets MUST provide a software component that proxies communication between a UNIX Domain Socket and the remote component(s).
    Proxy components transporting communication over IP networks SHALL be responsible for securing communications over such networks.
* Both the COSI system and Plugin SHOULD avoid accidental leakage of sensitive information (such as redacting such information from log files).

### Debugging

* Debugging and tracing are supported by external, COSI-independent additions and extensions to gRPC APIs, such as [OpenTracing](https://github.com/grpc-ecosystem/grpc-opentracing).

## Configuration and Operation

### General Configuration

* The `COSI_ENDPOINT` environment variable SHALL be supplied to the Plugin by the Provisioner Sidecar.
* An operator SHALL configure the COSI system to connect to the Plugin via the listen address identified by `COSI_ENDPOINT` variable.
* With exception to sensitive data, Plugin configuration SHOULD be specified by environment variables, whenever possible, instead of by command line flags or bind-mounted/injected files.

#### Plugin Bootstrap Example

* Sidecar -> Plugin: `COSI_ENDPOINT=unix:///path/to/unix/domain/socket.sock`.
* Operator -> COSI system: use plugin at endpoint `unix:///path/to/unix/domain/socket.sock`.
* COSI system: monitor `/path/to/unix/domain/socket.sock`.
* Plugin: read `COSI_ENDPOINT`, create UNIX socket at specified path, bind and listen.
* COSI system: observe that socket now exists, establish connection.
* COSI system: invoke `GetPluginInfo.

#### Filesystem

* Plugins SHALL NOT specify requirements that include or otherwise reference directories and/or files on the root filesystem of the COSI system.
* Plugins SHALL NOT create additional files or directories adjacent to the UNIX socket specified by `COSI_ENDPOINT`; violations of this requirement constitute "abuse".
  * The Provisioner Sidecar is the ultimate authority of the directory in which the UNIX socket endpoint is created and MAY enforce policies to prevent and/or mitigate abuse of the directory by Plugins.

### Supervised Lifecycle Management

* For Plugins packaged in software form:
  * Plugin Packages SHOULD use a well-documented container image format (e.g., Docker, OCI).
  * The chosen package image format MAY expose configurable Plugin properties as environment variables, unless otherwise indicated in the section below.
    Variables so exposed SHOULD be assigned default values in the image manifest.
  * A Provisioner Sidecar MAY programmatically evaluate or otherwise scan a Plugin Package’s image manifest in order to discover configurable environment variables.
  * A Plugin SHALL NOT assume that an operator or Provisioner Sidecar will scan an image manifest for environment variables.

#### Environment Variables

* Variables defined by this specification SHALL be identifiable by their `COSI_` name prefix.
* Configuration properties not defined by the COSI specification SHALL NOT use the same `COSI_` name prefix; this prefix is reserved for common configuration properties defined by the COSI specification.
* The Provisioner Sidecar SHOULD supply all RECOMMENDED COSI environment variables to a Plugin.
* The Provisioner Sidecar SHALL supply all REQUIRED COSI environment variables to a Plugin.

##### `COSI_ENDPOINT`

Network endpoint at which a Plugin SHALL host COSI RPC services. The general format is:

    {scheme}://{authority}{endpoint}

The following address types SHALL be supported by Plugins:

    unix:///path/to/unix/socket.sock

Note: All UNIX endpoints SHALL end with `.sock`. See [gRPC Name Resolution](https://github.com/grpc/grpc/blob/master/doc/naming.md).

This variable is REQUIRED.

#### Operational Recommendations

The Provisioner Sidecar expects that a Plugin SHALL act as a long-running service vs. an on-demand, CLI-driven process.

Supervised plugins MAY be isolated and/or resource-bounded.

##### Logging

* Plugins SHOULD generate log messages to ONLY standard output and/or standard error.
  * In this case the Provisioner Sidecar SHALL assume responsibility for all log lifecycle management.
* Plugin implementations that deviate from the above recommendation SHALL clearly and unambiguously document the following:
  * Logging configuration flags and/or variables, including working sample configurations.
  * Default log destination(s) (where do the logs go if no configuration is specified?)
  * Log lifecycle management ownership and related guidance (size limits, rate limits, rolling, archiving, expunging, etc.) applicable to the logging mechanism embedded within the Plugin.
* Plugins SHOULD NOT write potentially sensitive data to logs (e.g. secrets).

##### Available Services

* Plugin Packages MAY support all or a subset of COSI services; service combinations MAY be configurable at runtime by the Provisioner Sidecar.
  * A plugin MUST know the "mode" in which it is operating (e.g. node, controller, or both).
  * This specification does not dictate the mechanism by which mode of operation MUST be discovered, and instead places that burden upon the SP.
* Misconfigured plugin software SHOULD fail-fast with an OS-appropriate error code.

##### Linux Capabilities

* Provisioner Sidecar SHALL guarantee that plugins will have necessary permission to connect to their backend Object Storage System
* Plugins SHOULD clearly document any additionally required capabilities and/or security context.

##### Namespaces

* A Plugin SHOULD NOT assume that it is in the same [Linux namespaces](https://en.wikipedia.org/wiki/Linux_namespaces) as the Provisioner Sidecar.
  The COSI system MUST clearly document the CSI dependency requirements on ephemeral volumes for the plugins and the Provisioner Sidecar SHALL satisfy the COSI system’s requirements.

##### Cgroup Isolation

* A Plugin MAY be constrained by cgroups.
* An operator or Provisioner Sidecar MAY configure the devices cgroup subsystem to ensure that a Plugin MAY access requisite devices.
* A Provisioner Sidecar MAY define resource limits for a Plugin.

##### Resource Requirements

* SPs SHOULD unambiguously document all of a Plugin’s resource requirements.

repository: libopenstorage/openstorage

gha_language: Go

repo_name: libopenstorage/openstorage


text:
## Composer

- Composer is a semantic versioning system for PHP.
- Composer allows you to install both global dependencies and local dependencies.
- Composer uses a `locally global` dependency chain.  I.e. each dependency chain is linked, there can only be one version of the software installed at any time.
- Because of this, there can be conflicts in the system.
- `composer why` and `composer why-not` will tell you why it is using a particular version of any given software package.
- You can install composer in as many folders as you wish, if you really need to have a specific set of dependencies that conflict with each other.

## Semantic Versioning

[Semantic Versioning](http://www.semver.org)

- Semantic versioning is composed of three parts:  The major release, the minor release, and the patch version.
- The major release is the first number, e.g. `1.04.9`.  In that formula, the `1` is the major version release.
- Anytime a change introduces breaking changes into the application, it is supposed to undergo a major version update.
- The minor release is supposed to be a release that adds new functionality, but does not alter the behavior of the existing application.  In the example `1.04.9`, the `04` portion is the minor release.
- In cases where software has no major version like `0.4.5`, the operaters used to constrain software will have different effects.
- Finally, the patch version is the last number.  This is supposed to be updated when a bug fix or patch has been issued.  It should introduce no new behavior.
- Even though these are the definitions, not everyone follows them.  For that reason, having tests to find out if anything breaks is essential for an application.

## Operators

[Packagist test](https://semver.mwl.be/)

- Composer has numerous ways to match which versions of software you wish to require.
- The `=` sign means that the version **must** match the exact version in your code.  This is often not used because if there are dependency chains, it will fail them.

- `>=5.3.0,>5.2.0,<5.5.0`
- `^5.3`
- `~5.3`
- `5.3.*`

The tilde operater `~` means to match the `patch version` only.  I.e.


text:
---
layout: default
---

# 1997-03-13 - Charles Platt

## Header Data

From: aga<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: 4dbbcf0579dd5797c78f5bea8537b2843caf750c57e79a72e5f9ac7e4d4054af

Message ID<EMAIL_ADDRESS>Reply To<EMAIL_ADDRESS>UTC Datetime: 1997-03-13 08:51:59 UTC

Raw Date: Thu, 13 Mar 1997 00:51:59 -0800 (PST)

## Raw message

```
{% raw  %}From: aga<EMAIL_ADDRESS>Date: Thu, 13 Mar 1997 00:51:59 -0800 (PST)
To<EMAIL_ADDRESS>Subject: Charles Platt
In-Reply-To<EMAIL_ADDRESS>Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

On Wed, 12 Mar 1997, Dr.Dimitri Vulis KOTM wrote:

> Date: Wed, 12 Mar 97 21:43:42 EST
> From: "Dr.Dimitri Vulis KOTM"<EMAIL_ADDRESS>> Reply-To<EMAIL_ADDRESS>> To<EMAIL_ADDRESS><EMAIL_ADDRESS>> Subject: Re: Roosevelt quote
>
> You can find a lot of Charles Platt's drivel on alt.torture, where he
> airs his perverse sexual fantasies. He's also earned a reputation of
> a crook on sci.cryonics.
>
> Be warned that Platt is a pathological liar and a racist.
>

Is he on the net.scum web-page?

And is that cocksucker John Gilmore still around?

> ---
>
> Dr.Dimitri Vulis KOTM
> Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps
>

{% endraw %}
```

## Thread

+ Return to [March 1997](/archive/1997/03)

+ Return to "[aga <aga@dhp.com>](/authors/aga_aga_at_dhp_com_)"
+ Return to<EMAIL_ADDRESS>(Dr.Dimitri Vulis KOTM)](/authors/dlv_at_bwalk_dm_com_dr_dimitri_vulis_kotm_)"

+ _Unknown thread root_
  + 1997-03-13 (Wed, 12 Mar 1997 19:12:43 -0800 (PST)) - [Re: Roosevelt quote](/archive/1997/03/b8175021a59760e0189bc22fc1bc25db9458865209d5e675b52107455b0e9968) -<EMAIL_ADDRESS>(Dr.Dimitri Vulis KOTM)_
    + 1997-03-13 (Thu, 13 Mar 1997 00:51:59 -0800 (PST)) - Charles Platt - _aga<EMAIL_ADDRESS>


text:
Prisma does not have any JSON filter (See this [issue](https://github.com/prisma/prisma/issues/148)). This repo is to showcase a way to filter the JSON data using [mingo](https://github.com/kofrasa/mingo).

---

# How it works?

We create a minimal graphql server with `graphql-yoga`, however it could be express or anything else. It has one query which returns json data.

## Generate Fake Data

fakeData generates 5 to 20 fake objects so we don't need a database to test out how it works.

## Schema

It has a simple query `people` which takes a schemaless raw JSON data. The data can be anything but since we are trying to filter, we assume it's an array (of objects).

## Sample Query

Fetch all results

```graphql
{
  people
}
```

## Filter Data

filterData is simply a function that takes the fake data and applies mongodb like cursor.

### `skip` and `first`

It has `skip` and `first` just like we need in a prisma/graphql filter.

Fetch result with some filter

```graphql
{
  people(first: 2, skip: 1)
}
```

This query skips the first element and then returns 2 results. In prisma, `first` is like an alias for `limit`.

Here is the result:
![](https://i.imgur.com/9eEYQhw.png)

### `query`

**Warning! Beyond this point, it gets really complex. Caution adviced. You probably don't need these.**

**Example**

The `query` filter takes a stringified json. Consider the following query you would do on **mongodb**,

```js
{
  id: {
    $gte: 50000;
  }
}
```

You need to turn this into an string and pass that,

```js
JSON.stringify(JSON.stringify({ id: { $gte: 50000 } }));
// "{\"id\":{\"$gte\":50000}}"
```

So now the query becomes:

```graphql
{
  people(query: "{\"id\":{\"$gte\":50000}}")
}
```

You can probably implement all other type of filter based on the above logic.

**Another Example**

For example, filter all element which has name with letter `a`, with Regex:

```js
JSON.stringify(JSON.stringify({ name: { $regex: "a" } }))
// "{\"name\":{\"$regex\":\"a\"}}"
```

The query becomes:

```graphql
{
  people(query: "{\"name\":{\"$regex\":\"a\"}}")
}
```

Result:
![](https://i.imgur.com/JMlvNZX.png)

To understand what kind of filter you can probably use, check the [mingo](https://github.com/kofrasa/mingo) repository.

repository: entrptaher/playground-json-query-mingo

repo_name: entrptaher/playground-json-query-mingo


text:
# Package Documentation for github.com/ugorji/go-simplewebsite/simplewebsite

Package simplewebsite provides a fast and flexible static site generator or
dynamic file server.

simplewebsite is a modern, lean, fast website engine for typical websites,
with mostly static files and some dynamic content.

It is based off templates, markdown files and static files.

Each page (webpage, blog, etc) is represented by 2 files:

  - content: *.page.md or *.page.html for markdown, or html respectively
  - metadata: *.page.json (timestamp, author and tags).
    this metadata file is optional, as this information can be stored directly on the *.page.md file.

You can optionally store the metadata as the first thing in the contents
page, in the form:

```
    <!-- $meta 2011-03-23T19:29:00-07:00 2018-03-23T19:29:00-07:00 ... :u:ugorji :toc  android geek -->
         corresponding to:
    <!-- $meta timestamp_in_RFC3339 timestamp_in_RFC3339 ... option_ option_ option_ tag_ tag_ ... ->
```

Metadata here can be quoted to include spaces, or any sequence of characters
without spaces or commas. Example:

```
    <!-- $meta 2011-03-23T19:29:00-07:00 - android geek "playa playon , double" 'player playon, single' playee-dash -->
```

The content files are converted/copied as html and stored in a _to_html
directory.

Each directory containing pages "may" define a different set of templates.
This way, different directories can show semantically different types of
content, e.g:

  - web pages  (mostly static. part of website)
  - blog posts (blogs)

Template files always end with .page.thtml.

The expected templates:

  - _dir   (for paths like /a/b/)
  - _page     (for paths like /a/b/c. Searched recursively.)
  - _tag      (for tag page request. exist at top level)
  - _error    (for errors. exist at top level)

Note that all templates are bound to "absolute" directories.

  - _dir template for /a/b/ is got from /a/b/
  - _page template for /a/b/c is got from /a/b/ or /a/, or / recursively.

All templates can be found recursively up the tree, except _dir. A _dir
template must be defined at the level. Absense of one suggests that nothing
should be shown for that directory request. This way, we can have branches
for /, and /blog/, but not for /blog/a/b/; meaning that /blog/a/b/ should
not have a branch page.

```
    We considered using the existence of a _index.page.md to indicate index file,
    and allow _dir template be got recursively. However, this will make the
    _index show up as one of the pages in listings, etc. It also makes it hard
    to differentiate. It's best when we assume that a dir is not a page/file, and
    you define how to show directory information separate from pages.
```

We use filepath.Walk which walks files in sorted order. To support multiple
templates, all templates must be organized in lexical order. This way,
templates which are depended upon by others are loaded first.

Old paths (e.g. /project/*) are handled using a redirect. To support this,
we keep a rewrite map in a json file, and update this for any new path.

At startup time, we walk the directory, read in *.page.* files and snapshot
the server. To recreate the server when files change, just reload or restart
the server.

Expected Paths are (in order checked):

  - startWith /_, /.,     : forbidden (except if explicitly permitted)
  - match for redirect    : redirect
  - has extension         : sendFile via FileServer (images, etc)
  - startWith dynamicPathPfx : dynamic: e.g. /d/tag, etc
  - end with /            : Branch (or 404)
  - if dir                : Branch
  - if page               : Leaf
  - Else                  : 404
  - default               : Leaf

In terms of the code structure, a OS process runs an engine. That engine
holds a number of server objects, one for each base uri that the engine
serves. When a request comes into the engine, we match the hostname to a
server and dispatch to the appropriate server. Each server is self-contained
and can be removed or added to the engine as needed. Also, each server can
reload itself - though this reload doesn't accomodate config changes. The
engine however can be reloaded to read the config changes.

An engine can serve requests for multiple host names. If the host name
matches, it is dispatched to the appropriate server.

At startup, we will write pid to a file. This will allow easy shutdown of
server. A shell script will auto-restart the server if it dies.

Note that a tag is:

  - all lower case
  - no spaces
  - words separated by dashes

A function called "_title" is added to the template funcmap to convert to
title case.

Primary tags can be defined. These tags are:

  - shown on the home page (under recent)
  - show atom subscribe links to them

## The Server will support

  - max concurrent requests
  - access logging
  - signals: HUP to reload. TERM to graceful shutdown. USR1 to reopen logs.

Caching is supported. To fully support it:

  - Always send max-age header to 1 week (site will be updated weekly)
  - Send Last-Modified header.
  - Support Conditional GET for If-Modified-Since.

The utopia model for determining last-mod-time and whether to send 304 is:

  - keep track of lastMod time for templates, and timestamp of pages
  - use the most recent one as the last-mod-time for cache control

However, for now, we just use last reload time for sending last-mod-time and
checking if to return 304.

## Support getting pages matching a tag and a base path

E.g. show pages under /blog which have tag: technology.

To make a page featured on the home page, add the tag: x-featured.

Note that the attributes: name, title and summary are not got from the page
metadata. Instead, the name is got from the name of the contents file, the
title is the first header in the file, and summary is the first paragraph,
or first 2 paragraphs if the second paragraph directly follows the first.

## Support users: A user can author a page. Users can be defined on a Server

If a user is not found on a server, users defined on the engine are
searched. Each server has a default user, who is assumed to be the author of
any page for which an author is not defined.

## Support forms: A form is basically a collection of parameters

When filled and submitted, an email containing the form is sent to the user.
The from and to are in the parameters x-from and x-to respectively.

To use, create a form with the destination ${dynamicPathPrefix}message (e.g.
/d/message), and put all the parameters you need in there.

Typically, use this via AJAX since we only use the response code to indicate
success (or response code of 500 and body to indicate failure).

## Support extensions for pages: This allows for static site generation

If you configure the extension for a page, you can access the page using
that extension and it will get served. Note that you can still access the
page without the extension (that still works fine).

Support: configurable dynamic prefix (ie make /d/ configurable)

## Support generating static site

It basically generates the full site, including:

  - links for directories, feeds and tags (index.html)
  - pages

## Support: Serving static gzip files

Gzip files will be created at build time alongside regular files.

serveFile will look for NAME.gz, and if it finds it, decipher the content
type from the regular file, and serve the gzip version, setting the
appropriate headers so that the gzip pipeline will skip it.

Support: Users adding their own dynamic functions (for expansion)

Allow the registration of other dynamic paths, without going deep into this
file.

## Support: Server Template

Users should not have to repeat themselves if most parts of their Server
configuration look the same.

## Support: watch/notification for live reload of changed files

The engine will watch all server directories, and micro-reload changed files
in there. It also watches the config file to reload it if change.

This aids a lot during development.

## Support: static conversion of text

If patterns are seen in the file, replace them with replacements stored
locally. This way, some replacements can be done at build time, as opposed
to only doing within javascript.

A sample replacement file looks like:

```
    ----------BOUNDARY-----------
    ABC(\d+)DEF
    $1
    $1
    $1
    ----------BOUNDARY-----------
    UV([a-z]+)WX(\d+)YZ
    $1 - $1

    $2 - $2

    $1 - $2

    ----------BOUNDARY-----------
```

NOTE:

  - Always prefix your templates, replacements, etc with _ or something
    so they are sorted before your actual pages.
    This way, they are always parsed first before pages may need them.

## Exported Package API

```go
func Main(cmdName string, args []string) (err error)
type Dir struct{ ... }
type DynamicPathFn func(s *Server, w http.ResponseWriter, r *http.Request) error
type Engine struct{ ... }
type Page struct{ ... }
type Runner struct{ ... }
type Server struct{ ... }
type Summary [2]string
type TagStat struct{ ... }
type User struct{ ... }
```

repository: Neutral-Network/go-simplewebsite

repo_name: Neutral-Network/go-simplewebsite


text:
# Overview

These scripts will check whether each sequence has the correct number of runs within BIDS, based on a configuration file where the user specifies how many runs of each sequence are expected at each time point.

## Renaming rules

If there are **more** runs than expected, and the expected number of runs is greater than 1, the runs with the highest run numbers will be retained (up to X number of runs specified in the config file). Surplus runs will be moved to the `tmp_dcm2bids` folder. Retained runs will be renamed as runs 1-X with the lowest numbered run assigned the first number, and so on. If only one run is expected, the same operations just described will occur, but the remaining file will not have the run-number key-value portion of it's file name dropped.

If there are **fewer** runs than expected, a warning will be printed to the errorlog.

## Instructions

### The Configuration file

You will need to change some fields in the configuration file.

- Change the paths
- Change the Sequence and TimePoint information
- Indicate whether files are gzipped or not zipped
- Indicate whether the tasks should be labeled by the order in which they were run
  - If so, indicate which files

Within the configuration file, you are asked to fill out a dictionary for each unique set of sequences and time points in your study. Within "Sequence", the first field entered identifies the sequence type for which you will be listing files. This should be consistent with the name of the folder in which the subsequent sequence files are housed. The next information entered is a series of key:value pairs in which the key is the part of the file name that makes it unique (e.g. task name for functional runs) and the value is the expected number of files with that key in the specified folder.

**Here's an example:**

In this example:

- The study has 2 time points, so we will make 2 "TimePoint" objects composed of the appropriate "Sequence" objects
- The two time points have different functional runs, so we'll make a "func" sequence for each time point
- Both time points have anatomical images with the same name, so we can create one "anat" sequence for anat and use it in both time points
- Both time points also have fieldmap images with the same name, so we can also create one "func" sequence to use at both time points
- Once we've constructed our "TimePoint" objects with the correct contents, we put them into the "expected\_timepoints" object, and we're done!

![file_structure](./images/example_config.png)

## Run the script

### On a Cluster

- Log into Talapas
```
    ssh -X<EMAIL_ADDRESS>```
- `cd` to the directory that has your code in it
- Load the python3 module
```
    module load python3
```
- Run the `bidsQC.py` script

```
    python3 bidsQC.py
```
- Check your output and error logs

## Locally

- `cd` to the directory that has your code in it
- Run the `bidsQC.py` sciript
```
python3 bidsQC.py
```
- Check your output and error logs

# Check the BIDS Conversion

BIDS validator: [http://incf.github.io/bids-validator](http://incf.github.io/bids-validator/)# bids_tutorial


text:
## swably

Follow the instructions to run the code in development workstation:

	1. Install Mysql and create a MyISAM schema named Swably
	2. Install ImageMagick
	3. Install Ruby 1.9.x and Rails 3.x
	4. Clone the project to a local folder, such as /var/www/swably
	5. Run command "bundle" to install libararies
	6. Run command "rake db:schema:load" to create the data structure
	7. create 4 folders: /public/apks, /public/pictures, /public/feeds, /public/downloads
	8. Run command "rails server" to launch the site
	9. Open localhost:3000 in browser to test

Follow the instructions to deploy on server (e.g. CentOS 6.x) :

	1. Follow the above instructions 1-8 on the server to make sure the code works locally on server
	2. Install Apache 2.x
	3. Install Phusion Passenger and make it work with Apache
	4. Modify httpd.conf, add the following configuration:

		<VirtualHost *:80>
      			ServerName zh.swably.com
      			# !!! Be sure to point DocumentRoot to 'public'!
      			DocumentRoot /var/www/swably/public
      			<Directory /var/www/swably/public>
         			# This relaxes Apache security settings.

         			Options -MultiViews
      			</Directory>
   		</VirtualHost>

		<Files *.apk>
  			ForceType application/octet-stream
  			Header set Content-disposition "attachment"
		</Files>

repository: alexliao/swably

repo_name: alexliao/swably


text:
# Classical-Ko Generator for Yeoman

A Yeoman generator that creates a simple starting point for a knockoutjs SPA.

## About

This generator is a fork of [the fantastic 'generator-ko'](https://github.com/SteveSanderson/generator-ko) by [the brilliant Steven Sanderson](https://github.com/SteveSanderson).

The purpose of this fork was to simplify the original project, reducing dependencies and avoiding any transpilation of javascript. What's lef are only static files that will run without a web server. The aim is to be a simple starting point for a knockoutjs single page application that works out of the box. Also trying to provide a tad more documentation, as the original project is best documented in [this video](https://www.youtube.com/watch?v=I1USsIW8aWE)

There is a minuscule underlying preference for users of the [Brackets.io text editor](http://brackets.io/), but it's absolutely not a dependency.

## Requirements

Since this is a Yeoman generator you will have to have installed [node.js](https://nodejs.org/en/), which bundles [npm](https://www.npmjs.com/).

And the [Yeoman scaffolding tool](http://yeoman.io/). `npm install -g yo` in node.

## How-to

### Install

When that's all in place, you can install the generator `npm install -g generator-classical-ko`

### Use

**Scaffolding a new app**

Navigate your terminal to where you want to scaffold up your starting point. Should be an empty folder.

Type `yo classical-ko`

Yeoman will start up and ask you some questions:
  1. What's the name of your app
  2. Do you want to include automated tests? (Karma and Jasmine)
  3. What stylesheet language do you want to use? (Css or Less)

After that, you'll have a small simple app, as a starting point for your project.

**Scaffolding a new component**

When you need a new component in your app you can scaffold one:
`yo classical-ko:component <newComponentName>`
This will add a component in src/components and register it in startup.js

## A small note on choosing LESS
If you go down the less-route, you can use the `gulp watch` -task to transpile during development, or you can do it "manually" each time with `gulp devLess`.
If you're using the Brackets.io text editor, I recommend [the LESS AutoCompile extension](https://github.com/jdiehl/brackets-less-autocompile). The style.less file has already been configured for this extension.

## Testing in Brackets.io
The Karma.conf has Brackets.io added as a reporter, and the karma-brackets package has already been added as a dependency. If you're in to BDD-style development you can simply install [the Karma runner for Brackets](https://github.com/artoale/karma-brackets) and have Karma run your tests directly in Brackets.

## License
MIT

repository: gugathis/generator-classical-ko

repo_name: gugathis/generator-classical-ko


text:
# Changelog

A quick script that will generate a changelog for any git repository using
"conventional style" commit messages.

## [Unreleased]

### New Features
- Added an intermediate step to remove unnecessary newlines from the changelog
### Bug Fixes
- Fixed the issue of missing commits [#1]

### Documentation Changes
- [examples] Updated the examples with cz-cli's changelog
### Administration and Chores
- Updated changelog

## Version 0.1.1 (2016-09-20)

### New Features
- Added a console script entry point, `auto-changelog`

### Refactoring
- [templates] Refactored the templates to use a print_group() macro instead of manual copy/paste

### Administration and Chores
- Bumped the version number

## Version 0.1.0 (2016-42-20)

### New Features
- Converted from a jupyter notebook to a proper package
- Wrote the setup.py file

### Documentation Changes
- Added a README
### Administration and Chores
- Removed the Jupyter notebook stuff

repository: WqyJh/auto-changelog

repo_name: WqyJh/auto-changelog


text:
---
layout: post
title: The Power Law distribution - and how I couldn't find one
tags:
  - mexico
  - data analysis
  - statistics

---

Today I'm going to write about [power law distributions](http://en.wikipedia.org/wiki/Power_law). Power laws
are very common in statistics, because they model many common phenomena very closely. The following image shows
the typical shape of a power-law distribution. A few elements (in green) contain a very large proportion
of the area of the curve, and the rest (in yellow) is a very long tail of 'average-valued' elements.

![Typical power law](https://upload.wikimedia.org/wikipedia/commons/thumb/8/8a/Long_tail.svg/300px-Long_tail.svg.png)

`Typical form of a power law`

As I mentioned, this kind of distribution is observed in many phenomena. Actually, power laws have been observed in
physics for a while now, but with the new ubiquity of data on human activities, there is a sort of hype around them.
They are popping up everywhere to explain human-related phenomena. For instance the frequencies of words in human
languages show a power-law distribution: Aproximately 80% of what we say can be said with only 20% of the words of the English
language (e.g. 7% of the words in a book are just "the"). This is true for many human languages!

Another phenomenon that shows power-law behavior is the [amount of friends on Facebook]
(http://www.facebook.com/notes/facebook-data-team/anatomy-of-facebook/10150388519243859). Most people have only a few friends,
but there is also a significant amount of people in the 'long tail'. This is, a significant amount of people that have a large
amount of friends (more than 500).

The power law typically appears to describe phenomena that are about popularity. Facebook friends, twitter followers,
[sales of books](http://web.sfc.keio.ac.jp/~iba/papers/2008JJNAMS08-market.pdf) (a few books account for most of the sales),
total grossing of movies, size of cities, number of speakers of languages,
[distribution of household incomes](http://www.kps.or.kr/jkps/downloadPdf.asp?articleuid=%7BF1AFD04D-DFA3-45C2-BA44-C9FB8999C3DC%7D),
[level of collaboration on online communities](http://en.wikipedia.org/wiki/1%25_rule_(Internet_culture)),
and countless other phenomena show power law behavior or something very close to it!

With all this excitement about power laws, naturally many researchers have jumped on the power-law train, and made unsustainable
claims about their data, for instance [Clay Shirky's Blog In-degree distribution claims](http://shirky.com/writings/powerlaw_weblog.html).
It wasn't long until someone set out to kill a few birds in a single shot: [Clauset et al looked at 24 distributions]
(http://arxiv.org/pdf/0706.1062v2.pdf) that had been claimed to be power laws by other researchers
(sucha as word frequency, terrorist attack fatalities, religious sect size, surname frequency, in-degrees per URL, etc.),
and found that only one of the 24 was a clear power law. Pretty disappointing huh? Clauset et al were nice enough to
provide code for others to test their data for power-law-ness, and the code was later [translated to Python](http://github.com/keflavich/plfit) too.

Well, I ran into my own dataset that I suspected of being a power law. I found some [data of registered businesses in Mexico]
(http://www3.inegi.org.mx/sistemas/descarga/), published by the National Institute of Geography and Statistics (INEGI). Particularly,
data of "manufacturing businesses" - which includes bakeries and tortilla makers. I grouped the data by business type, and found that
most of the businesses are of very few types (20% of registered manufacturing businesses are tortilla makers!). Here is my data on
a log-log scale:

You can see it's definitely not a straight line, so there is no way it could fit to a power law, right? Well, as it turns out, when
researchers fit their data to power laws, they typically do it for a fraction of their data (the tail, or the beginning of it); so
upon first imporession it was not entirely certain whether we had a power law in our hands or not - if only for the beginning of the distribution.
To test that I used the code from Clauset et al's paper, which includes a Maximum Likelihood Estimator of the exponent,
as well as a Kolmogorov-Smirnov goodnes-of-fit test.

And that's the story of how I failed to fit my first power law. The code, which is nothing more than loading the data and applying
`plfit`, is [available on Github](http://github.com/pabloem/inegi/) for the curious. I'll be back soon with more on this data,
which I find pretty interesting. I will probably try to fit it to another distribution (Log-Normal?). Until then.


text:
---
layout: page
title: Wildlife Conservation
parent: works.md
weight: 4
---

I worked on integrating an existing commercial drone(Iris), an infrared camera, and a tablet controller at Duke University. The team, guided by [Prof. Mary Cummings](https://pratt.duke.edu/faculty/missy-cummings) worked on an open-source application, called [Tower](https://github.com/DroidPlanner/Tower), which was used to send waypoints to the Iris drone. We further simplified the user interface and ensured that anybody could control the drone without much training. This application was used to monitor the wildlife reserves at night in a forest in Gabon, Africa.

After modification of the tower application (refer to Figure 3), the app featured :
1. The camera feed real-time, integrating the thermal camera (Figure 1). Several feed of the camera was recorded during testing. Figure 2 shown below depicts a subject standing on the sidewalk surrounded by trees.
2. The functionalty of drone ready-to-take-off, take off and land buttons were made the same instead of confusing the user with three different icons.
3. Allowing the user to manipulate the drone while it is hovering.

Figure 1

Figure 2

Figure 3


text:
# pysc2
Customized PySC2 - StarCraft II Learning Environment

## about
This is Customized PySC2 environment with extra features listed in **Features**.

The original README.md could be found in doc/README.md.

## install
```
sudo pip install ./pysc2/
```
Read doc/README.md first is highly recommended.

## features

### non-sh entrypoint (manual)

### set Simple64 as default map

### add actions list
See doc/actions.txt

### add Full Game Replay instruction under doc

### fix sc2\_verbose incompatibility
pysc2/lib/protocol.py


text:
---
template: "blog/blog-post"
draft: false

# Metadata
title: "Social Media Login Security: Issues, Risks and Tips for Cyber Security"
description: "Social logins are very popular, but they can be abused by automated attacks. Learn how to make it harder for fraudsters to exploit this in our latest post."

# Breadcrumbs
breadcrumbs:
  - name: TechBlog
    path: /techblog/
  - name: Social Media Login Security...

# Fields
date: 2017-10-18
author:
  - Ido Safruti

blog_title: "How To Make Your Simple Social Login More Secure"
categories: Research
tags:
  - social
  - login

related_posts:

thumbnail: social-login.png

canonical_overwrite: https://www.infosecurity-magazine.com/opinions/simple-social-login-users-attackers/
---

_As originally published in [InfoSecurity Magazine](https://www.infosecurity-magazine.com/opinions/simple-social-login-users-attackers/)_

You will find them on millions of websites, including many of the most popular sites on the internet. These little buttons make it much faster for customers to sign up for a web application or service and dramatically boost conversion rates for site owners: I’m talking about the ubiquitous social login buttons from Facebook, Google and others.

Unfortunately, social logins are a growing source of abuse and fraud as sophisticated attackers and botnet operators have figured out ways to hack these authentication mechanisms and wreak havoc. This column will give you an overview of how social logins abuse happens and basic steps site operators can take to prevent it.

It’s easy to see why social logins are so popular. For users, it’s a much easier mechanism. With a social login they control one trusted identity and use it to log into other places in a trustworthy way. For site owners, it reduces friction in the signup process and feels more secure as they don’t need to manage user passwords or store their credentials and they know that a user’s email will be valid and won’t bounce.

Sounds good, right? Recently a customer called us and showed a strange graph of new account creations on their site. The line on the graph rose steeply in a very short period.

The customer was experiencing roughly a 9X increase in new account creation for no apparent reason. They believed it was an automated attack on their login page aimed at hacking into existing user accounts or creating fake new accounts on the application. We looked into their claim and quickly realized that the automated attack was a centrally controlled botnet of tens of thousands of malware infected browsers targeting the application’s social login flow.

In many cases, the way social login abuse happens starts by enticing a user to install a malicious browser extension. That extension will request your permission to read and change all data on all websites you visit, and a week or so from install date, will download in the background some Javascript malware from its command and control site to run on the user’s browser, and from that point can practically control your browser. The major browser makers cannot adequately police their stores due to the sheer volume of extensions uploaded.

These malicious extensions wait in the background and watch until a user logs into Facebook, Google or some other service. Once the user is logged in, the extension then will use the access tokens or credentials, and will attempt to sign the user up for other services supporting said social login without approval or permission, taking advantage of the logged in social account.

Some of the bot extension makers will actually take an extra step and use this tactic to game its rankings on the extension store using the user’s credentials to upvote the score, and will use the social networks to further distribute the malware to friends, allowing them to get thousands of more downloads.

Because social logins will generally keep a user logged in for 30 days without requiring an additional log in, bot makers and botnet operators have a considerable window of time in which to either perpetrate online fraud or spread their malware widely, all while piggybacking on the browsers of legitimate users.

What good is a hacked social login on a site? For one thing, it can be used to rack up affiliate fees through fake account signups at dating sites or other applications using hijacked social credentials. Botnet operators can also use social logins to propagate their malware by storing the malware on these sites as well as spreading it to friends or contacts and create a broader network of bots. For example, a hacked social login on a major file transfer site could be used as a powerful propagation mechanism for malware. Marketing fraud is another way that bot operators use social logins to make money or punish competitors.

Here are some basic steps to take that will make it harder for social login fraud to happen on a web application.... [Read full article](https://www.infosecurity-magazine.com/opinions/simple-social-login-users-attackers/)

repository: wernerglinka/newGatsbyStarter

repo_name: wernerglinka/newGatsbyStarter


text:
# nethut WordPress Theme

This is the custom [WordPress](http://www.wordpress.org) theme I use for my old website at http://www.nethut.pl. The site isn't being updated for a while now and the layout is old too, I just moved it from a previous build on top of TextPattern to WordPress for easier maintenance.

## License

Copyright 2016 Michał Paluchowski

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

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

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

repository: mpaluchowski/wordpress-theme-nethut

repo_name: mpaluchowski/wordpress-theme-nethut