text:
# Overkit

Overset meshes are a method for representing complex geometry in computational fluid dynamics
and other types of PDE-based simulations. An overset mesh is a composite mesh made up of a set
of overlapping component grids (structured or unstructured), in which the individual grids
exchange data with each other via interpolation.

![An overset mesh](misc/readme/blobs.png)

Overset meshes have several nice properties, including:

1. **Simplicity:** Component grids are (often) structured, so operating on them is similar to
   operating on Cartesian grids
2. **Flexibility:** Overset meshes' modular nature make them convenient for moving geometry
   problems and adaptive mesh refinement, as well as simulations in which different physical
   phenomena or numerical methods are relevant in different regions
3. **Efficiency:** Structured grids enable the use of efficient and accurate numerical methods.

However, some processing is required to convert a set of overlapping grids into a working overset
mesh. Overkit is designed to automate the tasks involved in this processing, such as:

1. Hole cutting of boundary geometry and overlapped coarse grids
2. Determination of donors and receivers for inter-grid communication
3. Generation of interpolation weights.

Overkit is also capable of generating interpolation data for mesh remapping (more on this below).

_Note:_ Overkit is currently designed for structured grids with node-centered data. Support for
cell-centered data and unstructured grids may be added in future versions.

# Installation

## Requirements

Overkit requires Fortran/C compilers and CMake. It currently has no other third-party library/tool
dependencies.

## Building

Overkit uses CMake, so the build process is similar to that of other CMake-based build systems.
An example build procedure is:

```bash
  cd ~/overkit-src
  mkdir build && cd build
  cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local/overkit
  make
  make install
```

See CMake's documentation for more details.

### Examples

Use the flag **`-DEXAMPLES=ON`** when configuring to build some example programs that use
Overkit. Source code for the examples can be found in `examples/`; the built programs are placed
in `<cmake-build-dir>/examples/`. Run `<example-program-name> --help` for information on how to
use each one.

### OpenMP

Overkit has optional OpenMP support that can be enabled by configuring with **`-DOPENMP=ON`**.

# Usage

What follows is a brief(ish) Overkit user's guide.

_Note:_ It may be helpful to look at some of the examples' sources while reading this.

## Overset basics and terminology

In an overset mesh, each component grid has **_fringes_** along its non-boundary edges. A
fringe is made up of one or more layers of **_receiver_** points, which are points that receive
data from other grids. Each receiver has a corresponding **_donor_** on the sending grid which
consists of the set of points that makes up the interpolation stencil and each point's
associated interpolation weight. Overkit calls the combination of a donor and a receiver a
**_connection_**. Most of the time, a pair of grids in an overset mesh will communicate in both
directions, so an interface between them will have two adjacent fringes (one on each grid).

In some cases when assembling an overset mesh, suitable donors may not be found for certain
receiver points (e.g. if there is insufficient overlap between grids); these receiver points
are referred to as **_orphan_** points.

Overset grids often have regions in which solutions are not computed called **_holes_**. These
result from several processes during assembly (details in the assembly section below).

In a typical explicit solver the solution procedure for an overset mesh may be something like:

```
Set u to some initial value for all grid points
For istep in 1..nsteps
  Solve for u at non-hole, non-fringe points
  Interpolate to update u at fringe points
```

_Note:_ When designing overset meshes for solvers that follow the above procedure, it is important
for the grids to overlap enough to allow donors to contain only non-fringe points (otherwise data
will be used in the interpolation stencils that has not yet been updated to the current step).

## Data structures

Overkit has three main data structures: domains, grids, and connectivities.

### Domain (`ovk_domain`)

The domain is the primary Overkit data structure. It contains a set of grids and their associated
connectivities.

### Grid (`ovk_grid`)

The grid represents a single component grid. It holds the grid's metadata (size, periodicity, etc.),
its coordinates, and a field representing the state of each grid point (interior point, boundary
point, hole, etc.).

### Connectivity (`ovk_connectivity`)

The connectivity holds inter-grid connectivity data for a given pair of grids.
For each connection (donor/receiver pair), the following data is stored:

1. _Donor extents:_ the range of points on the donor grid from which data will be interpolated,
   stored as a lower and upper point
2. _Donor interpolation coefficients:_ the interpolation weights for each point in the interpolation
   stencil, stored in tensor product format (i.e., an array of one-dimensional stencils, with the
   first index indicating the point in the stencil and the second index indicating the dimension)
3. _Donor coordinates:_ the mapped coordinates of the receiver point inside the donor stencil (the
   coordinate range depends on the interpolation scheme; e.g., for linear interpolation the
   coordinates range from 0 to 1, with (0,0) representing the lower left vertex and (1,1)
   representing the upper right vertex). _Note:_ These are typically only needed when generating
   interpolation coefficients separately from Overkit
4. _Receiver point:_ the point on the receiver grid to which the interpolated data will be sent.

### Auxiliary types

**Cart (`ovk_cart`):** Type representing a grid's structure, namely its size and periodicity.

**Field (`ovk_field_<int,large_int,real,logical>`):** Type for grid data. Data is stored in the
`values` member.

**Array (`ovk_array_<int,large_int,real,logical>`):** Type for linear arrays. Data is stored in the
`values` member.

## Domain creation

Domains are created with the following command:

```fortran
  call ovkCreateDomain(Domain, <numdims>, <numgrids>, StatusLogFile=<statusunit>, &
    ErrorLogFile=<errorunit>)
```

`<numdims>` is the dimension of the problem (2 or 3).

`<numgrids>` is the number of grids in the domain.

`<statusunit>` and `<errorunit>` are files to which to send the status and error output. They can
be set to `OUTPUT_UNIT` and `ERROR_UNIT` from `iso_fortran_env` to output to the command line, or
the arguments can be omitted to suppress output.

_Note:_ There is also a command to clean up once finished:

```fortran
  call ovkDestroyDomain(Domain)
```

## Grid creation

Grids are created with the following command:

```fortran
  call ovkCreateGrid(Domain, <gridid>, <numpoints>, Periodic=<periodic>, &
    PeriodicStorage=<periodicstorage>, PeriodicLength=<periodiclength>, &
    GeometryType=<geometrytype>)
```

`<gridid>` is the index of the grid in the domain.

`<numpoints>` is the number of points in each direction.

`<periodic>` specifies whether the grid is periodic or not (`.true.` or `.false.`) in each direction.
_(optional; default=`.false.`)_.

`<periodicstorage>` can either be **`OVK_PERIODIC_STORAGE_UNIQUE`** or
**`OVK_PERIODIC_STORAGE_DUPLICATED`**. The former indicates that the grid contains only one instance
of each point along any of its periodic dimensions; the latter indicates that the first point is
duplicated at the end in any periodic dimension. _(optional; default=`OVK_PERIODIC_STORAGE_UNIQUE`)_.

`<periodiclength>` specifies the offset that must be applied to the grid's coordinates
when crossing over from one period to the next. The length can be set to 0 for O-shaped grids.
_Note:_ Overkit currently assumes that only the corresponding dimension's coordinate changes when
crossing periods, e.g., if crossing from point (i,N,k) to (i,1,k), the X and Z coordinates will
remain the same, and the Y coordinate will be offset by PeriodicLength(2). _(optional; default=0.0)_.

`<geometrytype>` can be used to provide hints to Overkit about whether the grid's coordinates have
any special properties that can be used to improve performance. Possible values are:

* **`OVK_GEOMETRY_UNIFORM`** - an axis-aligned uniformly-spaced grid
* **`OVK_GEOMETRY_ORIENTED_UNIFORM`** - a rotated uniform grid
* **`OVK_GEOMETRY_RECTILINEAR`** - a non-uniform grid in which all of the cells are
  rectangular and axis-aligned
* **`OVK_GEOMETRY_ORIENTED_RECTILINEAR`** - a rotated rectilinear grid
* **`OVK_GEOMETRY_CURVILINEAR`** - a general non-uniform structured grid.

_(optional; default=`OVK_GEOMETRY_CURVILINEAR`)_.

_Note:_ There is also a command to destroy a grid:

```fortran
  call ovkDestroyGrid(Domain, <gridid>)
```

(but most of the time this isn't necessary, as the domain will clean up all of its contained grids
and connectivities when `ovkDestroyDomain` is called).

### Setting coordinates

Grids' coordinates are set using the following sequence of commands:

```fortran
  ! Request to edit the grid (returns pointer to ovk_grid)
  call ovkEditGrid(Domain, <gridid>, Grid)

  ! Request to edit the grid's coordinates (returns pointers to ovk_field_real)
  ! 2D is similar but with Z omitted
  call ovkEditGridCoords(Grid, 1, X)
  call ovkEditGridCoords(Grid, 2, Y)
  call ovkEditGridCoords(Grid, 3, Z)

  ! Set the coordinates
  ! 2D is similar but with Z omitted and k equal to 1
  do k = 1, Nz
    do j = 1, Ny
      do i = 1, Nx
        X%values(i,j,k) = <xvalue>
        Y%values(i,j,k) = <yvalue>
        Z%values(i,j,k) = <zvalue>
      end do
    end do
  end do

  ! Tell the grid that you're done editing the coordinates
  call ovkReleaseGridCoords(Grid, X)
  call ovkReleaseGridCoords(Grid, Y)
  call ovkReleaseGridCoords(Grid, Z)

  ! Tell the domain that you're done editing the grid
  call ovkReleaseGrid(Domain, Grid)
```

Grid coordinates are initially set to uniformly vary from 0 to N-1 in each direction (which is
sometimes convenient as a starting point for generating grids).

### Setting state

Grids' states are set with the following sequence of commands:

```fortran
  ! Request to edit the grid (returns pointer to ovk_grid)
  call ovkEditGrid(Domain, <gridid>, Grid)

  ! Request to edit the grid's state (returns pointer to ovk_field_int)
  call ovkEditGridState(Grid, State)

  ! Set the state
  ! 2D is similar but with k equal to 1
  do k = 1, Nz
    do j = 1, Ny
      do i = 1, Nx
        State%values(i,j,k) = <statevalue>
      end do
    end do
  end do

  ! Tell the grid that you're done editing the state
  call ovkReleaseGridState(Grid, State)

  ! Tell the domain that you're done editing the grid
  call ovkReleaseGrid(Domain, Grid)
```

`<statevalue>` can be one of the following:

* **`OVK_INTERIOR_POINT`** - (the default) a normal point
* **`OVK_DOMAIN_BOUNDARY_POINT`** - a point that lies along a boundary of the simulation domain
* **`OVK_INTERNAL_BOUNDARY_POINT`** - a point along a grid edge that isn't a domain boundary, but
  where a fringe is undesirable (perhaps due to the presence of some other type of inter-grid
  interface)
* **`OVK_EXTERIOR_POINT`** - a point that is outside of the simulation domain.

_Note 1:_ Coordinates and state can be edited at the same time (in fact it's slightly more efficient
to do this).

_Note 2:_ Overkit expects valid grid coordinates even for points set to `OVK_EXTERIOR_POINT`.

_Note 3:_ The above state values are actually combinations of individual state flags of the form
`OVK_STATE_*` (more on these later).

## Assembly

Once the domain and grids are set up, assembly can be run with the following commands:

```fortran
  AssemblyOptions = ovk_assembly_options_(<numdims>, <numgrids>)
  call ovkAssemble(Domain, AssemblyOptions)
```

However, for anything to actually happen we will need to first modify the assembly options. The
sections below describe the assembly process in Overkit and explain what each of the options in the
**`ovk_assembly_options`** structure do. Commands for modifying assembly options will have one of
the following forms:

```fortran
  ! Per-grid settings
  call ovkSetAssemblyOption<optionname>(AssemblyOptions, <gridid>, <optionvalue>)

  ! Per-grid-pair settings
  call ovkSetAssemblyOption<optionname>(AssemblyOptions, <gridid1>, <gridid2>, <optionvalue>)
```

A value of **`OVK_ALL_GRIDS`** can be passed to any of the `<gridid*>` parameters to modify the
option value for multiple grids at once.

### Overlap detection

Overkit first needs to determine how the component grids are situated with respect to each other.
This consists of looking at every grid point and determining within which cell(s) on the other grids
the point resides (if any). Naively, overlap detection has quadratic computational complexity in the
number of grid points (because it involves testing each point against each cell among all pairs of
grids), but this can be improved to linear complexity through the use of spatial partitioning data
structures.

Overkit currently uses a hybrid approach consisting of a kd-tree at coarse levels (to prune out
empty space and to separate regions of vastly different grid resolution) and a spatial hash grid at
finer levels.

Relevant options:

* **`Overlappable(m,n)`** - whether grid `m` is considered to potentially overlap with grid `n`
   _(default=`.false.`)_
* **`OverlapTolerance(m,n)`** - tolerance for points on grid `n` that lie slightly outside of grid
  `m` but should be considered to overlap (most often occurs along curved boundaries). Specified as
  a fraction of the boundary cells' sizes (e.g. a value of 0.1 means that a point can be up to 10%
  outside of a nearby cell and still be considered to overlap) _(default=0.0)_
* **`OverlapAccelDepthAdjust(m)`** - adjusts the desired minimum number of cells in each kd-tree
  node on grid `m`. Each increment by 1.0 halves the number (increasing the tree depth), and each
  decrement by 1.0 doubles the number (decreasing the tree depth) _(default=0.0)_
* **`OverlapAccelResolutionAdjust(m)`** - adjusts the size of hash grid bins on grid `m`. Each
  increment by 1.0 halves the bin size (resulting in fewer cells overlapping with each bin,
  i.e., better performance at the cost of more memory) and each decrement by 1.0 doubles the
  bin size _(default=0.0)_.

### Boundary hole cutting

The collection of domain boundary points on all of the grids defines the overall shape of the
domain. Depending on the input grid configuration, some points may lie outside of this region and
will need to be removed. (For example, in a two-grid airfoil configuration with a uniform background
grid and a second grid that wraps around the airfoil geometry, points on the background grid will
lie inside the non-domain region defined by inner edge of the second grid.)

Overkit handles this by (1) projecting a representation of other grids' boundaries onto the grid
being cut, (2) detecting which side is outside of the domain, then (3) flooding this side and
removing the detected points from the domain.

Relevant options:

* **`InferBoundaries(n)`** - assume grid edges in non-overlapping regions are domain boundaries on
  grid `n` _(default=.false.)_
* **`CutBoundaryHoles(m,n)`** - whether the boundary points on grid `m` are allowed to be used in
  cutting grid `n` _(default=.false.)_.

### Receiver selection

Next we need to determine which points should be receiving data. Overkit divides the points detected
in this step into two categories, _**outer fringe**_ points and _**occluded**_ points. Outer fringe
points are points near non-boundary grid edges. Occluded points are overlapped points for which one
of the overlapping grids has been determined to be a better representation of that part of the
domain than the present one.

Relevant options:

* **`FringeSize(n)`** - how many layers of points away from non-boundary edges of grid `n` should be
  counted as fringe _(default=0)_
* **`Occludes(m,n)`** - how to treat points on grid `n` that are overlapped by grid `m`. Possible
  values are **`OVK_OCCLUDES_ALL`**, meaning all such points are occluded, **`OVK_OCCLUDES_NONE`**,
  meaning none are occluded, and **`OVK_OCCLUDES_COARSE`**, meaning only points with a lower
  resolution are occluded _(default=`OVK_OCCLUDES_NONE`)_
* **`EdgePadding(m,n)`** - in some cases it may be desirable to prevent points from receiving data
  from points that are within some distance of the donor grid's edge. This option specifies how
  far from the edge cells should be on the overlapping grid `m` in order to occlude points on the
  overlapped grid `n` _(default=0)_
* **`EdgeSmoothing(n)`** - used in conjunction with `EdgePadding`, helps to remove any sharp edges
  or disconnectedness in the set of occluded points on grid `n`. Higher values increase smoothing
  strength _(default=0)_.

### Overlap minimization

For overset meshes we typically don't need to keep all of the receiver points detected in the
previous step. Instead we can cut out most of the occluded points and leave only the few layers
nearest to the unoccluded part of the grid. Overkit calls these remaining points the _**inner
fringe**_.

The `EdgePadding` option described in the previous section reduces the size of a grid's
occluded region, which has the side effect of increasing the amount of overlap remaining after
overlap minimization. This can be useful in certain situations such as that of the explicit solver
described above.

Relevant options:

* **`MinimizeOverlap(m,n)`** - whether points on grid `n` that are occluded by grid `m` and aren't
  part of the inner fringe should be removed _(default=`.false.`)_
* **`FringeSize(n)`** - (defined above)
* **`EdgePadding(m,n)`** - (defined above).

### Donor selection

By this point we have our final set of receiver points and the only thing left to do is to locate
the corresponding donors. This involves choosing which overlapping grid will donate to each receiver
and then actually generating the interpolation stencils on the donor grids. In determining the
best donor grid for a given receiver, both the local grid resolution and edge distance are used.
If a suitable donor cannot be found, the point will be marked as an orphan and a warning message
will be produced.

Relevant options:

* **`ConnectionType(m,n)`** - how donors on grid `m` will communicate with receivers on grid `n`.
  Possible values are **`OVK_CONNECTION_NONE`**, meaning communication is not allowed, and
  **`OVK_CONNECTION_NEAREST`**, **`OVK_CONNECTION_LINEAR`**, and **`OVK_CONNECTION_CUBIC`** for
  nearest-neighbor, linear, and cubic interpolation respectively _(default=`OVK_CONNECTION_NONE`)_
* **`EdgePadding(m,n)`** - (defined above; used again here as a threshold for deciding whether to
  prioritize edge distance or resolution).

## Mesh remapping

In addition to overset meshes, Overkit can also generate interpolation data for multi-block or
overset mesh remapping. For this application one would create a single domain containing both the
source and destination grids, and set assembly options as follows (omitting options left at the
default value):

* `Overlappable(<srcgrids>,<destgrids>)=.true.`
* `Occludes(<srcgrids>,<destgrids>)=OVK_OCCLUDES_ALL`
* `ConnectionType(<srcgrids>,<destgrids>)=<desired interp scheme>`.

## Interpolation data access

Once assembly is completed, interpolation data can be accessed using the following commands:

```fortran
  ! Get the connectivity data structure from the domain (returns pointer to ovk_connectivity)
  call ovkGetConnectivity(Domain, <gridid1>, <gridid2>, Connectivity)

  ! Access the donor extents (returns pointer to integer array of shape (3,2,<numconnections>))
  call ovkGetConnectivityDonorExtents(Connectivity, DonorExtents)

  ! Access the donor interpolation coefficients (returns pointer to real(kind=ovk_rk) array of
  ! shape (<stencilsize>,<numdims>,<numconnections>))
  call ovkGetConnectivityDonorInterpCoefs(Connectivity, DonorInterpCoefs)

  ! Access the donor coordinates (returns pointer to real(kind=ovk_rk) array of shape
  ! (<numdims>,<numconnections>))
  call ovkGetConnectivityDonorCoords(Connectivity, DonorCoords)

  ! Access the receiver points (returns pointer to integer array of shape (3,<numconnections>))
  call ovkGetConnectivityReceiverPoints(Connectivity, ReceiverPoints)
```

## Troubleshooting

Occasionally after running the assembly, you may get a result that doesn't match what you expected.
In these instances it can be helpful to look at the intermediate results of the steps described
above. For this purpose Overkit records some of these results in the grid state and provides a
command `ovkFilterGridState` to access them:

```fortran
  ! Get the grid from the domain
  call ovkGetGrid(Domain, <gridid>, Grid)

  ! Returns ovk_field_logical
  call ovkFilterGridState(Grid, <stateflags>, <filtermode>, Mask)
```

`<stateflags>` consists of one or more state flags combined using Fortran's bitwise 'or' (`ior`)

`<filtermode>` tells the command how to treat these flags. **`OVK_ANY`** returns points matching
any of the specified flags and **`OVK_ALL`** returns points matching all of them. **`OVK_NONE`**
and **`OVK_NOT_ALL`** are the respective complements of `OVK_ANY` and `OVK_ALL`.

Currently-supported state flags are:

* **`OVK_STATE_GRID`** - point is part of the domain
* **`OVK_STATE_INTERIOR`** - point is on the interior
* **`OVK_STATE_BOUNDARY`** - point is a boundary
* **`OVK_STATE_EXTERIOR`** - point is outside of the domain
* **`OVK_STATE_DOMAIN_BOUNDARY`** - point is a domain boundary
* **`OVK_STATE_INTERNAL_BOUNDARY`** - point is an internal boundary
* **`OVK_STATE_OVERLAPPED`** - point is overlapped by another grid
* **`OVK_STATE_INFERRED_DOMAIN_BOUNDARY`** - point is a domain boundary that was detected during
  boundary inference
* **`OVK_STATE_BOUNDARY_HOLE`** - point was removed during boundary hole cutting
* **`OVK_STATE_OCCLUDED`** - point is occluded by another grid
* **`OVK_STATE_FRINGE`** - point is part of the fringe
* **`OVK_STATE_OUTER_FRINGE`** - point is part of the outer fringe
* **`OVK_STATE_INNER_FRINGE`** - point is part of the inner fringe
* **`OVK_STATE_OVERLAP_MINIMIZED`** - point was removed during overlap minimization
* **`OVK_STATE_RECEIVER`** - point is a receiver
* **`OVK_STATE_ORPHAN`** - point was a receiver but no suitable donors were found.

Overkit also provides commands to write the grids and states to a file (PLOT3D format) that can be
opened in visualization tools such as TecPlot and ParaView. See the examples' source code
for details.

# Acknowledgements

Overkit is one of several software projects produced by the University of Illinois Center for
Exascale Simulation of Plasma-Coupled Combustion (XPACC): <http://xpacc.illinois.edu>.

This material is based in part upon work supported by the Department of Energy, National Nuclear
Security Administration, under Award Number DE-NA0002374.

repository: zbeekman/overkit

repo_name: zbeekman/overkit


text:
# Travelize

Welcome to the Travelize Sinatra Web App!  This app was created with the intention
to create and track travel goals.  It is a basic MVC Sinatra project to fulfill project requirements at Flatiron School.
Further functionality and development will continue in later projects.

## Installation

Clone this repository and execute:

    $bundle install

Then execute:

    $rake db:migrate

to create the database.

Next, execute:

    $rake db:seed

to add sample travelers and goals to the database.

Execute:

    $shotgun

and navigate to use a local server and navigate to localhost:9393 to preview the app.

Below are sample signons to use:

|        Email        |  Password |
| ------------------  | --------- |
|<EMAIL_ADDRESS>   | password  |
|<EMAIL_ADDRESS>  | password  |
|<EMAIL_ADDRESS>   | password  |
|<EMAIL_ADDRESS>| password  |

## Usage

Usage of this Sinatra basic CRUD app is for the sole purposes of entertainment and interacting with
a preliminary travel goal tracking app.

## Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/emilia-m26/travelize_app. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.

## License

The app is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).

## Code of Conduct

Everyone interacting in the Travelize App project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the code of conduct.

license: MIT

extension: md

gha_language: HTML

license_type: permissive


text:
# Go parser for Plastic SCM

Plastic SCM and Semantic Merge provide a way to run a syntactic diff (and merge) based on different programming languages AST.

In order for this to work properly, a [special format](http://codicesoftware.blogspot.com/2015/09/custom-languages-in-semantic-version.html)
is required. This project will use **golang** internal parser to create the required YAML.

## Install on windows
Be sure that you have a complete installation of [golang on windows](
https://golang.org/doc/install#windows_env
)

###Install golang yaml
```
cd %GOPATH%
go get gopkg.in/yaml.v2
```

###Install goparser
```
mkdir src\espeleta.info
cd src\espeleta.info
git clone https://github.com/tespeleta/plasticgo.git
go install espeleta.info/goparser
cd %GOPATH%
```

From now, we can compile and test with:

```
go build espeleta.info/goparser
go test espeleta.info/goparser
```

## Use
Please refer to Plastic SCM detailed [instructions](http://codicesoftware.blogspot.com/2015/09/custom-languages-in-semantic-version.html)
. You can try go parser in the following way:

```
goparser.exe shell flag.txt
```

`flag.txt` is the filename used to create an empty file that plastic SCM will understand as an indication that all initializations by the parser are finished. In `golang` case, the initialization is immediate.

Once started, the parser will wait reading from standard input the filenames to parse and the output files:

```
goparser.exe shell flag.txt
\path\to\filename.go
\path\to\outputfile.yaml
OK
\path\to\filename2.go
\path\to\outputfile2.yaml
OK
```
The parser will indicate with `KO` if there were any error during the processing, or `OK` otherwise.

repository: tespeleta/plasticgo

branch_name: refs/heads/master

repo_name: tespeleta/plasticgo


text:
# ChangeLog

## Version 1.1.0 (2019-01-18):
* Incompatible API change: so far `LA_VERSION` was a preprocessor macro,
  which was expanded during compilation of any program using it. As a result,
  its value contained the version of the C header, while the intention was
  to show the version of the currently running library. `LA_VERSION` has
  therefore been changed to a `char * const * const` variable. As a result,
  it is no longer possible to refer to it in preprocessor constructs
  (like `#ifdef`s or gluing of static strings together).
* Added decoder for Media Advisory messages (ACARS label SA) and an example
  program `media_advisory`. Contributed by Fabrice Crohas.
* Fixed decoding of ADS-C messages containing multiple contract requests.
* A few small fixes.

## Version 1.0.0 (2018-12-10):
* First stable release.

repository: andruxa-smirnov/JAERO

repo_name: andruxa-smirnov/JAERO


text:
# TODO extension for Visual Studio Code

This extension adds functionality to list TODO:s in the project:

- Choosing language
- Show TODO:s

## Features

![Imgur](http://i.imgur.com/p25rHeS.gif)

## Usage

### Settings
To exclude files from the search for TODO's, create the variable todoIgnore in your workspace or user settings:

``` json
{
  "todoIgnore":   ["**/test/**"]
}
```

It should contain an array of glob-patterns.

#### Marketplace
The extension is published on Visual Studio Codes marketplace at:
https://marketplace.visualstudio.com/items/MattiasPernhult.vscode-todo

Download the extension with Visual Studio Code by open the command palette and run
```bash
  ext install vscode-todo
```

#### Local usage
First you need to clone the project, I strongly recommend you to clone it directly to the extension folder under the .vscode folder, or you can clone it and then copy the project into this location.

The .vscode folder is located under:
* **Windows:** %USERPROFILE%\.vscode\extensions
* **Mac:** $HOME/.vscode/extensions
* **Linux:** $HOME/.vscode/extensions

## Contributing
If you like to contribute with new features or fixing issues just set up a development environment and make a pull request and I will look into that as soon as possible.

#### Development environment
You can set up a development environment for debugging the extension during extension development.

First make sure you do **not** have the extension installed in `~/.vscode/extensions`. Then clone the repo somewhere else on your machine, run `npm install` and open a development instance by pressing **F5**.

```bash
rm -rf ~/.vscode/extensions/vscode-todo
cd ~
git clone https://github.com/MattiasPernhult/vscode-todo
cd vscode-todo
npm install
code .
```

## Changelog
#### v0.4.0
* Support for ignoring files and folders through use of todoIgnore in configuration
* Now scrolls to the selected TODO's line, instead of just highlighting it

#### v0.3.0
* Improved the appearance of the TODO:s
* Showing the actual TODO instead of only showing file path
* Removed the root path from the file path
* Will cut of characters if the actual TODO excess 60 characters
* The same with the file path

#### v0.2.0
* No need to choose a language, the extension will look through all files if no language is choosen.
* Activate on start up.
* It's possible to choose either all languages or a specific language.
* This feature was proposed by marlass in issue #4

#### v0.1.3
* Fixed bug with php files
* No new feature was added in this release

#### v0.1.2
* The extension will detect .js.coffee files in this release

#### v0.1.1
* Fixed bug with coffee files
* No new feature was added in this release

#### 0.1.0
* Initial release
* Possibility to choose a language
* Get all the TODO:s for the choosen language

## License
[MIT](LICENSE)

repository: gitter-badger/vscode-todo

repo_name: gitter-badger/vscode-todo


text:
 A temporary email right from your terminal written in POSIX sh

 `tmpmail` is a command line utility written in POSIX `sh` that allows you to create a temporary email address
and receive emails to the temporary email address. It uses 1secmail's [API](https://www.1secmail.com/api/)
to receive emails.

By default `w3m` is used to render the HTML emails on the terminal.
But if you prefer another text based web browser or would rather view the email in a GUI web browser such as Firefox, simply
use the `--browser` argument followed by the command needed to launch the web browser of your choice.

## Dependencies
- `w3m`
- `curl`
- [`jq`](https://github.com/stedolan/jq)
- `xclip`

## Installation
### Install locally

```bash
# Download the tmpmail file and make it executable
$ curl -L "https://raw.githubusercontent.com/sdushantha/tmpmail/master/tmpmail" > tmpmail && chmod +x tmpmail

# Then move it somewhere in your $PATH. Here is an example:
$ mv tmpmail ~/bin/
```

### AUR
`tmpmail` is available on the [AUR](https://aur.archlinux.org/packages/tmpmail-git/), which is currently being maintained by [Benjamin Bädorf](https://github.com/b12f)

```bash
$ yay -S tmpmail-git
```

### [Pacstall](https://github.com/pacstall/pacstall) (Debian/Ubuntu)
`tmpmail` is available on the [pacstall-programs repository](https://github.com/pacstall/pacstall-programs/blob/master/packages/tmpmail-bin/tmpmail-bin.pacscript), which is being currently being maintained by [wizard-28](https://github.com/wizard-28)

```
$ pacstall -I tmpmail-bin
```

### Nixpkgs
`tmpmail` is also available in the [nix package collection (only unstable currently)](https://search.nixos.org/packages?channel=unstable&show=tmpmail&from=0&size=50&sort=relevance&query=tmpmail), which is maintained by [legendofmiracles](https://github.com/legendofmiracles)

Either add it to your system packages, install it with nix-env or try it out in a ephemeral nix-shell `nix-shell -p tmpmail`

### Docker

requirements:
 - [docker](https://www.docker.com/)
 - clone this repo

```bash
$ docker build -t mail .; # Dockerfile available in source code
$ docker run -it mail;
```

## Usage
```console
$ tmpmail --help
tmpmail
tmpmail -h | --version
tmpmail -g [ADDRESS]
tmpmail [-t | -b BROWSER] -r | ID

When called with no option and no argument, tmpmail lists the messages in
the inbox and their numeric IDs.  When called with one argument, tmpmail
shows the email message with specified ID.

-b, --browser BROWSER
        Specify BROWSER that is used to render the HTML of
        the email (default: w3m)
    --clipboard-cmd COMMAND
        Specify the COMMAND to use for copying the email address to your
        clipboard (default: xclip -selection c)
-c, --copy
        Copy the email address to your clipboard
-d, --domains
        Show list of available domains
-g, --generate [ADDRESS]
        Generate a new email address, either the specified ADDRESS, or
        randomly create one
-h, --help
        Show help
-r, --recent
        View the most recent email message
-t, --text
        View the email as raw text, where all the HTML tags are removed.
        Without this option, HTML is used.
--version
        Show version
```

### Examples
Create random email
```console
$ tmpmail --generate
<EMAIL_ADDRESS>```

Create custom email
```console
$ tmpmail --generate<EMAIL_ADDRESS><EMAIL_ADDRESS>```

View the inbox
```console
$ tmpmail
[ Inbox for<EMAIL_ADDRESS>]

83414443<EMAIL_ADDRESS> Test Email
```

View the email
```console
$ tmpmail 83414443
```

View the most recent email
```console
$ tmpmail -r
```

View emails as pure text
```console
$ tmpmail -t 83414443
To<EMAIL_ADDRESS>From<EMAIL_ADDRESS>Subject: Test Email

Hello World

[Attachments]
https://is.gd/aBCdEf [apple.jpg]
https://is.gd/AbCDeF [ball.jpg]
```

## Credits
This script is heavily inspired by Mitch Weaver's [`1secmail`](https://github.com/mitchweaver/bin/blob/master/OLD/1secmail) script

repository: sdushantha/tmpmail

gha_language: Shell

gha_license_id: MIT

repo_name: sdushantha/tmpmail


text:
This fork was created to build a Docker image for this script.  All variables listed below should be set by your environment.

# wupws
simple shell script that parses current observations from a weather underground station and posts to pwsweather.com.  Needed so Rachio smart irrigation controller can use nearby weather underground data to adjust watering schedule.

Mandatory Linux Tools Required:
- jq
- wget

Mandatory variables to set in the script (more info in the .sh):
- WORKINGDIR=/home/ABC123
- WUAPI={your weather underground API key - no braces}
- WUPWS={"your weather underground station identifier - no braces - yes quotes"}
- PWSID={your pwsweather.com station ID}
- PWSPASS={your pwsweather.com password}

Workflow:
- Sign up for a Weather Underground free (Stratus) API key
- Sign up for a pwsweather.com account
- Create a new weather station under your pwsweather.com account using the (lat/long/elevation/etc) from the Weather Underground station you wish to track
- edit the script with all of your personal variables
- set a cronjob to run the script with your desired frequency - keep it at every 3 minutes or more to stay under the WU 500 API calls/day limit
     - */3 * * * * {script location - no spaces}
- profit

repository: oillio/wupws

repo_name: oillio/wupws


text:
+++
title = "Source Stage"
date = 2021-08-30T08:30:00-06:00
weight = 15
+++

The **Source Stage** is the first step of any CI/CD pipeline and it represents your source code. This stage is in charge of triggering the pipeline based on new code changes (i.e. git push or pull requests). In this workshop, we will be using AWS CodeCommit as the source provider, but CodePipeline also supports S3, GitHub and Amazon ECR as source providers.

Append the following code snippet after your bucket definition in the **pipeline_stack.py** file:

```python
        # Import existing CodeCommit sam-app repository
        code_repo = codecommit.Repository.from_repository_name(self, "AppRepository", "sam-app")

        # Pipeline creation starts
        pipeline = codepipeline.Pipeline(self, "Pipeline",
          artifact_bucket = artifacts_bucket
        )

        # Declare source code as an artifact
        source_output = codepipeline.Artifact()

        # Add source stage to pipeline
        pipeline.add_stage(
            stage_name = "Source",
            actions = [
                codepipeline_actions.CodeCommitSourceAction(
                    action_name = "Source",
                    branch = "main",
                    output = source_output,
                    repository = code_repo,
                )
            ]
        )
```

{{%expand "Click here to see how the entire file should look like" %}}

The highlighted code is the new addition:

```python {hl_lines=["19-41"]}
# pipeline/pipeline_stack.py

from aws_cdk import (core as cdk,
                     aws_s3 as s3,
                     aws_codebuild as codebuild,
                     aws_codecommit as codecommit,
                     aws_codepipeline as codepipeline,
                     aws_codepipeline_actions as codepipeline_actions)

class PipelineStack(cdk.Stack):

    def __init__(self, scope: cdk.Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        # The code that defines your stack goes here
        artifacts_bucket = s3.Bucket(self, "ArtifactsBucket")

        # Import existing CodeCommit sam-app repository
        code_repo = codecommit.Repository.from_repository_name(self, "AppRepository", "sam-app")

        # Pipeline creation starts
        pipeline = codepipeline.Pipeline(self, "Pipeline",
          artifact_bucket = artifacts_bucket
        )

        # Declare source code as an artifact
        source_output = codepipeline.Artifact()

        # Add source stage to pipeline
        pipeline.add_stage(
            stage_name = "Source",
            actions = [
                codepipeline_actions.CodeCommitSourceAction(
                    action_name = "Source",
                    branch = "main",
                    output = source_output,
                    repository = code_repo,
                )
            ]
        )
```
{{% /expand%}}

Since we already have the CodeCommit repository, we don't need to create a new one, we just need to import it using the repository name.

Also notice how we define an object `source_output` as a pipeline artifact; This is necessary for any files that you want CodePipeline to pass to downstream stages. In this case, we want our source code to be passed to the Build stage.

{{% notice info %}}
Don't do a `cdk deploy` just yet, because a pipeline needs to have at least 2 stages to be created. Lets continue to the next page to add a Build stage first.
{{% /notice%}}

repository: mmondino/aws-serverless-cicd-workshop

repo_name: mmondino/aws-serverless-cicd-workshop


text:
---
layout: post
title: Free Online Resources for Learning About Statistics
categories: notes
tags: statistics
---

## Books

Below are some excellent books available for free download.

- [All of Statistics](https://link.springer.com/book/10.1007/978-0-387-21736-9) by
Larry Wasserman

- [Bayesian Data Analysis](http://www.stat.columbia.edu/~gelman/book/frontmatter.pdf) by Andrew Gelman et al.

- [Computer Age Statistical Inference](https://web.stanford.edu/~hastie/CASI_files/PDF/casi.pdf) by Bradley Efron et al.

- [Elements of Statistical Learning](https://web.stanford.edu/~hastie/Papers/ESLII.pdf) by Trevor Hastie et al.

- [Think Stats](https://greenteapress.com/thinkstats/) and [Think
  Bayes](https://greenteapress.com/wp/think-bayes/#:~:text=Think%20Bayes%20is%20an%20introduction%20to%20Bayesian%20statistics%20using%20computational%20methods.&text=Most%20books%20on%20Bayesian%20statistics,approximations%20instead%20of%20continuous%20mathematics.)
  both by Allen B. Downey

## Online Classes

- MIT OCW 18.05 [lecture notes](https://ocw.mit.edu/courses/mathematics/18-05-introduction-to-probability-and-statistics-spring-2014/readings/)

## Youtube Channels

These channels explain complex statistical concepts very clearly.

- [Professor Knudson](https://www.youtube.com/channel/UCjknLK_siVSCY14qfDu-f-w)

- [JB Statistics](https://www.youtube.com/channel/UCiHi6xXLzi9FMr9B0zgoHqA)

- [Marin Stats Lectures](https://www.youtube.com/watch?v=AN3UkzE3HMg&list=PLqzoL9-eJTNAB5st3mtP_bmXafGSH1Dtz)

- [Brian Caffo](https://www.youtube.com/user/bcaffo).
  [Here](https://github.com/bcaffo/LittleInferenceBook) is a free book he used in his Coursera class on statistical inference.

The [Royal Statistics
Society](https://www.youtube.com/channel/UC83oOOF9lg-g1XMT_UK1tUw) has lectures
from luminaries in statistics.  Some are accessible to novices like me.

## R Language Resources

- The [tidyverse](https://www.tidyverse.org/) is a curated ("opinionated") set
  of R packages for data science.

- Online version of [R for Data Science](https://r4ds.had.co.nz/) by Hadley Wickham

## Blogs

- [538](https://fivethirtyeight.com/) Nate Silver

- [Statistical Modeling, Causal Inference, and Social Science](https://statmodeling.stat.columbia.edu/) Andrew Gelman

- [The Economist's 2020 US election forecast](https://projects.economist.com/us-2020-forecast/president)


text:
# Release process

1.  Confirm that you have a clean worktree.

    `git status` should show no changed, staged, or untracked files.

2.  Run the `yarn ci` script.

    This checks formatting, runs lints checks, and runs all tests.

    If necessary, apply fixes, submit a pull request, and when it is merged, start again at step 1.

3.  Update [CHANGELOG.md](./CHANGELOG.md).

    Run [`@liferay/changelog-generator`](https://www.npmjs.com/package/@liferay/changelog-generator):

        yarn run liferay-changelog-generator --version=v4.1.0

    If you're not sure what version number to supply (ie. because you don't know exactly what changes will be included), you can pass the `--dry-run` switch to get a preview printed to standard output:

        yarn run liferay-changelog-generator --dry-run

4.  Review the changes.

    Use `git diff` to confirm that the CHANGELOG.md looks correct. Feel free to edit it if you want to make improvements. Then stage the changes:

        git add CHANGELOG.md

5.  Tag and publish the new release.

    Run `yarn version --minor` (or `--major`, or `--patch`, as appropriate).

    This will update the package.json and create a tagged commit, including the updates to the CHANGELOG that you previously made.

        We use [@liferay/js-publish](https://github.com/liferay/liferay-frontend-projects/tree/master/projects/npm-tools/packages/js-publish) from the "postversion" script to take care of pushing to the repo, and actually publishing to the NPM registry; just follow the prompts.

6.  Update the release notes.

    Take the new section from the top of the CHANGELOG and add it to [the release page](https://github.com/liferay/liferay-frontend-projects/releases) on GitHub.

7.  Sanity check [the @liferay/eslint-config page](https://www.npmjs.com/package/@liferay/eslint-config) on npmjs.com

    Specifically, you should see the version you just released under the "Versions" tab on that page.

repository: wincent/liferay-frontend-projects

gha_license_id: NOASSERTION

repo_name: wincent/liferay-frontend-projects


text:
# Making a backup-utils release

 1. Install the debian devscripts package:
    `sudo apt-get install devscripts`
 2. Add a new version and release notes to the `debian/changelog` file:
    `dch --newversion 2.6.0 --release-heuristic log`
 3. Rev the `share/github-backup-utils/version` file.
 4. Tag the release: `git tag v2.0.2`
 5. Build that tarball package: `make dist`
 6. Build the deb package: `make deb`. All the tests should pass.
 7. Draft a new release at https://github.com/github/backup-utils/releases, including the release notes and attaching the tarball and deb packages.
    The dist tarball you should upload has the git revision in the file name, i.e. something like `github-backup-utils-v2.5.0-1-g23c41cc.tar.gz`
 8. Push the head of the release to the 'stable' branch.


text:
# First-timers-guide

## A collection of guides for and by first-timers

[![GitHub Issues](https://img.shields.io/github/issues/the-ethan-hunt/first-timers-guide.svg?style=flat-square)](https://github.com/the-ethan-hunt/first-timers-guide/issues) [![GitHub Pull Requests](https://img.shields.io/github/issues-pr/the-ethan-hunt/first-timers-guide.svg?style=flat-square)](https://github.com/the-ethan-hunt/first-timers-guide/pulls) [![Pull Requests Welcome](https://img.shields.io/badge/PRs-welcome-green.svg?style=flat-square)](http://makeapullrequest.com)
[![first-timers-only Friendly](https://img.shields.io/badge/first--timers--only-friendly-yellow.svg?style=flat-square)](http://www.firsttimersonly.com/)
[![Gitter chat](https://badges.gitter.im/first-timers-guide/Lobby.png)](https://gitter.im/first-timers-guide/Lobby)

### Contents

- [What](#what)
- [How](#how)
- [Contributing](#contributing)
- [FAQs](#faqs)
- [License](#license)

### What?

First-timers guide is a guide to encourage more people to venture into open-source. The word guide can be a little misunderstood
here; it means articles written in MarkDown format about various topics in Computer Science ranging from time complexity to Word2Vec.
Anyone, literally **anyone** can contribute to the repository

### How?

It's quite simple. Just write a article in MarkDown format about a topic you know; the article should be between 100-150 words and
easy to read for a newbie. And then pull a request to start. :tada:

### Contributing

1) Fork the project
2) Add your article
3) Follow the rules given [here](https://github.com/the-ethan-hunt/first-timers-guide/blob/master/CONTRIBUTING.md)
4) Mission Accomplished! :tada:

### FAQs

Q: Can I submit a code file in any language?

A: No. If it is *absolutely essential* you may talk about it to the owner and he will decide.

Q: I don't know a language. Can I contribute?

A: Absolutely. You don't require knowledge of any particular language. You but must know about the article you are contributing.

### License

The MIT License 2017 - [Dhruv Apte](http://github.com/the-ethan-hunt/).

repository: seowwj/first-timers-guide

repo_name: seowwj/first-timers-guide


text:
---

**PID Control Project**

The goal of this project are the following:

Implement the PID controller and control the simulator car such that the car drives through the track without leaving it.

[//]: # (Image References)
[image1]: ./examples/first.png
[image2]: ./examples/second.png
[image3]: ./examples/third.png
[image4]: ./examples/fourth.png
[image5]: ./examples/fifth.png
[video1]: ,/examples/pid.mp4

## [Rubric Points](https://review.udacity.com/#!/rubrics/824/view)
All the code for this project has been derived from the example code in the course and is in this directory.
[Here](https://github.com/gvp-study/CarND-PID-Control-Project.git)
---

### PID Controller
## Implementing the PID Controller

I implemented the PID control based on the lessons. I tuned the PID parameters manually. I used two sets of PID controllers. One for the steering and one for the throttle.

## Steering PID
The steering PID controller was tuned by manually twiddling from a starting set of parameters. I ended up finding the PID values to be Kp = 0.13, Ki = 0.0001 and Kd = 4.0.

## Reflections on the Steering PID terms
To find the appropriate values of the PID terms I manually twiddled the parameters. For this I needed to find an error measure which could incorporate the error for the whole track and normalize it by the distance. So I integrated the distance from the increments and the absolute CTE and obtained the ratio of the latter to the former. I then twiddled the PID terms based on this value after one track run.
```code
odometer += speed*dt;
total_cte += fabs(cte);
std::cout << " Error / Distance : " << total_cte/odometer << std::endl;
```
### Propotional Term P
I started out with just the P term and observed that the system oscillates when only the P term is nonzero as explained in the course notes. I settled on the value of 0.13.
### Differential Term D
I then increased the differential term from 0, 1, 2, 3, till 4.0 when I found it could keep the car on track for a whole lap.
### Integral Term I
I found that even low values of I brought back oscillations in the driving. So I manually twiddled it to 0.0001. This small value reduced the total_cte/odometer error from experiments.

## Throttle PID
The throttle PID controller was also tuned manually and I settled on Kp = 0.3, Ki = 0.0, Kd = 0.02. In addition to the PID term from the CTE, I also slowed down the car based on the steering angle. This allows the car to slow down at all turns.
```code
throttle = max_speed - pidt.TotalError() - max_speed*(1.0 - cos(steering_angle*M_PI/180.0));
```

The result is shown in the output of the simulator at different points along the track as shown in the figures below.

![alt text][image1]

![alt text][image2]

![alt text][image3]

![alt text][image4]

The final image shows the car reached a maximum speed of 77 mph.

![alt text][image5]

The movie of the simulator controlled by the PID controller is shown below.[link to my video](./examples/pid.mp4)
![alt text][video1]

repository: gvp-study/CarND-PID-Control-Project

repo_name: gvp-study/CarND-PID-Control-Project


text:
WARNING: do not include this in release tarfile.

This note is for continuous intergration on travis (traditional build from source with
extensive testing) and on circleci (conda and non-conda binary package build).
(There is a commit-checking-bot running on casegroup that checks new commit to amber repo
every 5 minutes.

You can always check status of each service by looking at the icons in

https://github.com/Amber-MD/ambertools-test/blob/nightly/README.md

How to check log?

GREEN: OK
RED: FAILED.

- circleci:
    - click its icon in above link or visit: https://circleci.com/gh/Amber-MD/ambertools-test/tree/nightly
    - click the build number (e.g: #159)
    - scroll down and look for "$ source devtools/ci/circleci_build.sh"
    - Since the build log is very long and circleci does not display all of them,
    you can download it by scroll down very end of the section, click "Download the full output as a file."

    circleci artifact (AmberTools*.tar.gz2) can be collected by running:
        python $AMBERHOME/AmberTools/src/download_circleci_AmberTools.py
    This artifact is being used by phenix build (and test) bot.

- travis:
    - click its icon in above link (README.md) or visit: https://travis-ci.org/Amber-MD/ambertools-test
    - click any of the build task that you're interested. I use TEST_TASK env to split the tests.
        - TEST_TASK="fast": testing all python stuff + related programs that might be useful for phenix
        - TEST_TASK="serial_MM" + TEST_TASK="serial_QMMM": testing sander serial
        - TEST_TASK="python": only testing Python packages
        - TEST_TASK="mmpbsa" or "rism": those tests are slow, so split them here.
    - You can download the log by clicking the link  for each build task, then click "Raw log"
        An example of that log (not sure how long travis keep it)
            https://s3.amazonaws.com/archive.travis-ci.org/jobs/207213712/log.txt
                You can search "file comparisons passed"
    If the tests failed, exit 1 --> travis job will be RED.

- email notification:

   add your email here if you want to get notification if the build failed:
       https://github.com/Amber-MD/ambertools-test/blob/nightly/.travis.yml#L47-L52

          notifications:
            email:
              recipients:
                -<EMAIL_ADDRESS>              on_success: never # default: change
              on_failure: always # default: always

Note:

- If you do not want your small commit (fixing docs, README, ...) run on circleci or travis (save their computer
resources), you can add "[ci skip]" to your git commit
   e.g.: This is my message  "add README.ci.md for continuous intergration [ci skip]"

repository: majacQ/ambertools-binary-build

repo_name: majacQ/ambertools-binary-build


text:
React Redux Universal Minimal Starter Kit
------------
Minimal starter kit (boilerplate) for universal React apps based on [fuglu/react-redux-boilerplate](https://github.com/fuglu/react-redux-boilerplate).

What's inside
-------------
* react + react-router + redux + redux-saga
* [redux-wait-for-action](https://github.com/Chion82/redux-wait-for-action) to reuse sagas on server side
* express.js for server side rendering
* jest for test utils (No test scripts added by default)
* webpack configuration for both client and server side
* ESLint
* hot reload for both client and server side development

Usage
-----
Install:
```
npm install
```
Development:
```
npm run dev
open http://localhost:3001
```
Development (No server side rendering):
```
npm run dev:client
open http://localhost:3000
```
Build:
```
npm run build
node dist/server/index.js
```


text:
# NFP.jl
Forecasting using a parallel combinatoric approach.

## Installation
```julia
Pkg.clone("https://github.com/lucabrugnolini/NFP.jl")
```

## Documentation
The procedure is described in [Brugnolini L. (2018)](https://lucabrugnolini.github.io/publication/forecasting_inflation.pdf). The application is on predicting the probability of having inflation around the European Central Bank's target.

## Introduction
Given a (balanced) dataset of _K_ macroeconomic variables, the objective is to select the best model to predict future values of a target variable. The selection procedure consists in (i) select the best _iBest_ variables according to several out-of-sample criteria and then use these variables in models that use their combination. More specifically:

1. the procedure selects the best `iBest` variables using two different criteria (mean absolute error and root mean squared error). This selection step is univariate, i.e. the variables are chosen by running a simple regression of the target variable on each variable of the dataset.

2. the `iBest` variables are combined into set of _2, 3, ..., iBest_ variables. For each of these sets, the model is estimated and then avaluated out-of-sample. The best model is the one with the lowest out-of-sample `MSE`. We also augment each model with the first principal component of all variable in the dataset. Thus, there are a total of _2 (2^iBest)_ models.

The complexity is _O((T-Ts)*2^iBest)_ where _T_ is the sample size, _Ts_ is the number of observation in the initial estimation window.

## Example
Forecasting US non-farm-payroll one and two months ahead `H = [1,2]` using a dataset containing 116 US variables taken from [McCracken and Ng (2015)](https://amstat.tandfonline.com/doi/abs/10.1080/07350015.2015.1086655). `iBest` is set to 16. The code below is an example of parallelization on `N_CORE`.

```julia
addprocs(N_CORE)
@everywhere using NFP, DataFrames
@everywhere const sStart_s = "01/01/15"                   ## This is the beginning of the out-of-sample window
@everywhere const iSymbol = :NFP                          ## Target variable
@everywhere const vSymbol = [:Date, :NFP, :NFP_bb_median] ## Variables to be removed from the dataset (non-numerical and dep. var.)
@everywhere const H = [1,2]                               ## Out-of-sample horizon
@everywhere const iBest = 16                              ## iBest
@everywhere const ncomb_load = iBest                      ## TODO: remove this option

@everywhere dfData = readtable(joinpath(Pkg.dir("NFP"),"test","data.csv"), header = true)
@everywhere const iStart = find(dfData[:Date] .== sStart_s)[1]

## computes the two steps variable selection
l_plot,r = sforecast(dfData,vSymbol,iSymbol,H,iStart,iBest,ncomb_load)
## `fforecast` uses results previously stored
l_plot,r = fforecast(dfData,vSymbol,iSymbol,H,iStart,iBest,ncomb_load)

# Plot the forecasts
l_plot

## Remove process added
rmprocs(2:N_CORE)

```

In case one is interested in predicting probabilities, as the US probability of recession, simply include a link function in `sforecast` or `fforecast`, and use a binary variable as dependent variable.

```julia
@everywhere const l = ProbitLink() # link function for probability model
l_plot,r = sforecast(dfData,vSymbol,iSymbol,H,iStart,iBest,ncomb_load,l)
l_plot,r= fforecast(dfData,vSymbol,iSymbol,H,iStart,iBest,ncomb_load,l)
```
_Note:_ Since `readtable` is deprecated in Julia v0.6, it is advisable to start julia's REPL using the --depwarn=no flag

```bash
> julia --depwarn=no
```

## References
Brugnolini L. (2018) "Forecasting Deflation Probability in the EA: A Combinatoric Approach." _Central Bank of Malta Working Paper_, 01/18.

McCracken, Michael W., and Serena Ng.(2016) "FRED-MD: A monthly database for macroeconomic research." Journal of Business & Economic Statistics 34.4:574-589.


text:
# jn-scripts

## Who does what ?

- `jn_sd_resize.sh` resizes the SD card partitions to use all instead of the original 16GB.
(Tested of JetPack4.3). Thanks to
[this post](https://devtalk.nvidia.com/default/topic/1050105/jetson-nano/jetson-nano-sd-card-partitions-can-not-extend-/post/5393113/#5393113) on nvidia dev forum.
- `create_8Gswap.sh`, creates an 8GB swap memory on disk. Pretty practical for
installation. Thanks to [this post](https://jkjung-avt.github.io/setting-up-nano/).

## Reminders
- To use the GPIO remapping tool, run this once `sudo find /opt/nvidia/jetson-io/ -mindepth 1 -maxdepth 1 -type d -exec touch {}/__init__.py \` before running this `sudo /opt/nvidia/jetson-io/jetson-io.py`
- Default python is linked to python2, unlink python2 and link python3 by default.

## Resources
- Power your board through the barel jack so you can have the
best performances (don't forget to run `sudo nvpmodel -m 0`).
See [this video](https://www.youtube.com/watch?v=jq1OqBe267A).

- You can connect to the board without screen keyboard and mouse
  - Using USB to TLL cables. See
  [this post](https://desertbot.io/blog/jetson-nano-usb-login/) for more
  instructions for that.
  - Through USB. Connect the board using te barrel jack. Connect USB to your host with
  `screen /dev/ttyACM0 115200`. I prefer using `tio`, it handles colors better and I
  can still use `Ctrl + A`. The command looks like `tio /dev/ttyACM0 --baudrate 115200`.
  Consider using [termsize](https://github.com/akkana/scripts/blob/master/termsize) to
exploit the terminal size fully over serial terminal.
  - Through SSH, connect the board to wifi, get IP adress (with ifconfig for example)
  and run `ssh <username>@<ipadress>`

- [Nice post](https://www.hackster.io/news/getting-started-with-the-nvidia-jetson-nano-developer-kit-43aa7c298797)
about the Nano in general, sets up remote desktop.

- Device tree overlays to reconfigure the 40-PIN GPIO header
[here](https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fhw_setup_jetson_io.html)

- Build kernel and modules locally after building,
[video here](https://www.youtube.com/watch?v=Fu2x87YJUo0&t=312s).

- Pisound support for Tinkerboard,
[see here](https://community.blokas.io/t/pisound-on-tinker-board/1015).

### Tools
- `jtop` is nice to monitor GPU usage. Install with `sudo -H pip install jetson-stats`.
See [here](https://github.com/rbonghi/jetson_stats).

### Installing
- Tensorflow, instructions [here](https://devtalk.nvidia.com/default/topic/1048776/jetson-nano/official-tensorflow-for-jetson-nano-/).
- Soundcard :
```bash
sudo apt install libffi-dev python-cffi
sudo pip install soundcard
```

repository: mpariente/jn-scripts

repo_name: mpariente/jn-scripts


text:
# invariant

## Description

Given a [command](https://github.com/cypriss/mutations) like:

```ruby
class MyCommand < Mutations::Command
  extend Invariant

  # ...
end
```

Run your commands with invariants that are ensured to be checked:

```ruby
MyCommand.run_with_invariants do |x|
  if x.try(:app_id)
    x.app_id == current_admin.app.id
  end
end
```

repository: bobjflong/invariant

repo_name: bobjflong/invariant


text:
# rez-ilmbase
Rez Package for IlmBase with python support
----
[![Build Status](https://travis-ci.org/piratecrew/rez-ilmbase.svg?branch=master)](https://travis-ci.org/piratecrew/rez-ilmbase)

Build status is for versions:
  - 2.2.0

repository: msercheli/rez-ilmbase

repo_name: msercheli/rez-ilmbase


text:
# twilio_programmable_chat_example

Demonstrates how to use the `twilio_programmable_chat` plugin in a save manner as you would production like.

## Join the community
If you have any question or problems, please join us on [Discord](https://discord.gg/42x46NH)

## Supported platforms
* Android
* ~~iOS~~ (not yet)
* ~~Web~~ (not yet)

## Prerequisites

This example makes use of a backend, to setup a backend and make it reachable on the internet we decided
to use Firebase in this project. Therefore you need to do some setup steps to get this example up and
running. Also we are going to be using Twilio Programmable Chat, which also needs some setup before
getting started.

1. [Create a Twilio account](https://www.twilio.com/referral/j7GFTv)
2. [Create a Firebase account](https://firebase.google.com/)

## Required plans on Twilio
Please note the following about costs and required plans on these accounts. On Twilio you will get $15
on your Trial account. This should be enough to start testing Programmable Chat.

## Required plans on Firebase
On Firebase you will kick off in the [Spark plan](https://firebase.google.com/pricing). But you will need
to upgrade to the Blaze plan. Don't be scared for any costs, because:

> The Spark plan allows outbound network requests only to Google-owned services. Inbound invocation requests are
> allowed within the quota. On the Blaze plan, Cloud Functions provides a perpetual free tier. The first 2,000,000
> invocations, 400,000 GB-sec, 200,000 CPU-sec, and 5 GB of Internet egress traffic is provided for free each month.
> You are only charged on usage past this free allotment. Pricing is based on total number of invocations, and
> compute time. Compute time is variable based on the amount of memory and CPU provisioned for a function. Usage
> limits are also enforced through daily and 100s quotas. For more information, see [Cloud Functions Pricing](https://cloud.google.com/functions/pricing).

## Getting started

Now that we are aware of the specific needed plans as stated above we can get this party started.

### Install NodeJS & Firebase command-line tools
We are going to use Firebase command-line tools to easily deploy functions. Therefore we need to install NodeJS.

To install NodeJS, follow the installation documentation for your OS from [https://nodejs.org/](https://nodejs.org/).

After successful installation of NodeJS you can install Firebase command-line tools globally like this:

```bash
npm install -g firebase-tools
```

### Setting up Firebase
1. Create a project on Firebase. Any project name would be okay. Google Analytics is not needed, but if you want you can add it.
2. Below the project name you will see the project id that will be created. You can change this when you press on it. Write this
project id down.
3.  Keep in mind, you can't change this afterwards.
4. Open the file `.firebaserc` and change the value `twilio-chat-flutter-plugin-dev` to your project id from step 2.
5. Make sure the project is on [Blaze plan](#required-plans-on-firebase)
6. In a terminal run `firebase login` and login with the same account as used in step 1.
7. In a terminal go to the firebase functions directory in this example: `cd firebase/functions` and run `npm install`
8. You will need to get the following information from your Twilio account for the next step:

| Variable | Example value | Where to find/create |
|-----|---------------|---------------|
| twilio.live.account_sid |  ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | [Twilio console - Dashboard](https://www.twilio.com/console) |
| twilio.live.auth_token |  your_auth_token | [Twilio console - Dashboard](https://www.twilio.com/console)|
| twilio.test.account_sid |  ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | [Twilio console - Dashboard](https://www.twilio.com/console) |
| twilio.test.auth_token |  your_auth_token | [Twilio console - Dashboard](https://www.twilio.com/console)|
| twilio.api_key |  SKXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | [Twilio Console - Settings -> API Keys](https://www.twilio.com/console/project/api-keys/create)
| twilio.api_secret | your_api_secret | [Twilio Console - Settings -> API Keys](https://www.twilio.com/console/project/api-keys/create) |
| twilio.service_sid | ISXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | [Twilio Console - Programmable Chat -> Services](https://www.twilio.com/console/chat/services) |
9. Configure [the environment variables](https://firebase.google.com/docs/functions/config-env) for the Cloud Functions
```
firebase functions:config:set twilio.live.account_sid="ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" \
                              twilio.live.auth_token="your_auth_token" \
                              twilio.test.account_sid="ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" \
                              twilio.test.auth_token="your_auth_token" \
                              twilio.api_key="SKXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" \
                              twilio.api_secret="your_api_secret" \
                              twilio.service_sid="ISXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
```
10. Deploy the firebase project: `firebase deploy`

### Configure Flutter app
This example uses the `cloud_functions` plugin from [pub.dev](https://pub.dev/packages/cloud_functions) and therefore we should also follow [the setup](https://pub.dev/packages/cloud_functions#setup) from this plugin.

Below we will take you through this setup for each platform.

#### Configure Android
1. Open your [firebase console](https://console.firebase.google.com/)
2. Open the project you created before
3. On this project overview page click the Android icon to add an Android app or if you do not see this option, click the `Add app` button
4. Android package name: `twilio.flutter.twilio_programmable_chat_example`
5. App nickname: `Twilio Programmable Chat Example`
6. Debug signing certificate SHA-1: leave empty
7. Click `Register app`
8. Click `Download google-services.json`
9. Move to downloaded `google-services.json` file to this folder `android/app/` and make sure to keep the filename exactly the same!
10. In the firebase console hit the `Next` button
11. Add Firebase SDK, these steps are already done in this example, so just hit `Next`
12. Finally hit `Continue to the console`

#### Configure iOS
1. Open your [firebase console](https://console.firebase.google.com/)
2. Open the project you created before
3. On this project overview page click the iOS icon to add an iOS app or if you do not see this option, click the `Add app` button
4. iOS bundle ID: `twilio.flutter.ProgrammableChatExample`
5. App nickname: `Twilio Programmable Chat Example`
6. App Store ID: leave empty
7. Click `Register app`
8. Click `Download GoogleService-Info.plist`
9. Move to downloaded `GoogleService-Info.plist` file to this folder `ios/Runner/` and make sure to keep the filename exactly the same!
10. In the firebase console hit the `Next` button
11. Add Firebase SDK, these steps are already done in this example, so just hit `Next`
12. Add initialisation code, these are handled with the cloud_functions package, just hit `Next`
13. Finally hit `Continue to the console`

### Run the application
Connect a device and/or emulator and run the Flutter application on it. Join the same room on several devices to talk with each other.


text:
# polymer-redux
An example use-case to showcase the state/view abstraction in Polymer 3, LitElement and Redux context

# NOTE:
This repo works with `<EMAIL_ADDRESS>Update to latest version will be coming soon.

It is a rough demo that demands interaction polishing.

## Running the demo
Clone the repo, then run `npm i` or `yarn`.

Run `polymer serve` in your terminal.

Then visit `http://localhost:8081/demo`.

repository: learningmachine/polymer-redux

repo_name: learningmachine/polymer-redux


text:
# thesallab.alllogger
![The SaL Lab](sallab.png)

AllLogger is a toolset used by the SaL Lab to log volunteers' search
 behaviors. It consists of the following tools:
* [A .NET executable](1%20Executable) to log:
  * keyboard key presses,
  * mouse key presses and movements,
  * clipboard changes,
  * title changes of active windows,
  * eye fixations (not available in the open-source edition due to law issues).
* [A Firefox/Chrome add-on](2%20Add-on) to log:
  * web page requests and referrers,
  * activations of tabs.
* [A server endpoint](3%20Add-on%20Server) to work with the Firefox/Chrome add-on.
* [A Visual Studio extension](4%20Extension) to snapshot the active code tab.
## License
AllLogger is open-source under the MIT license. But please let us know if
 you use AllLogger in your project by sending an email to zhangyin(at)mail.neu.ed.cn


text:
Cardboard Gameplay {#zooshi_guide_gameplay_cardboard}
==================

## Overview

In this mode, you control the game directly with [Google Cardboard][],
aiming at patrons just by looking at them and throwing sushi with
a flick of the switch.

Just like the standard game, the goal is to hurl sushi into the mouths of
as many animal patrons as you can. For each lap around the river, you will
notice the minimum number of patrons that you must feed will increase. You
must meet (or exceed) the lap quota in order for the gate to open for another
thrilling lap of sushi launching.

## Setup

To play in Cardboard mode, simply select "Cardboard" from the Zooshi menu.
You will then see an intermediate screen, which allows you to use the gear icon
to configure your Cardboard device and test the result.

Once you are ready to begin, simply insert your device into the Cardboard and
flick the switch to start the game. Alternatively, you can just touch the screen
to start, so you can still try it out, even without a Cardboard device.

## Controls

When the game starts, you will be right in the middle of the Zooshi action.
As you look around to aim, you can flick the switch to throw a sushi.

After the game ends, you can flick the switch again to start up a new game.
Otherwise, press the back button to go to the Zooshi menu.

*Note: You may need to swipe down from the top, or side, of your screen
in order to display the system navigation buttons for your device. This will
depend on your device. Please refer to your specific device's manual for more
information.*

Read more about how it works [here][].

  [Google Cardboard]: https://www.google.com/get/cardboard/
  [here]: @ref zooshi_guide_cardboard

repository: kiwihilton/zooshi

repo_name: kiwihilton/zooshi


text:
---
layout: post
title: "Analogy Mining for Specific Design Needs"
date: 2017-12-19 11:47:53
categories: arXiv_CL
tags: arXiv_CL
author: Karni Gilon, Felicia Y Ng, Joel Chan, Hila Lifshitz Assaf, Aniket Kittur, Dafna Shahaf
mathjax: true
---

* content
{:toc}

##### Abstract
Finding analogical inspirations in distant domains is a powerful way of solving problems. However, as the number of inspirations that could be matched and the dimensions on which that matching could occur grow, it becomes challenging for designers to find inspirations relevant to their needs. Furthermore, designers are often interested in exploring specific aspects of a product-- for example, one designer might be interested in improving the brewing capability of an outdoor coffee maker, while another might wish to optimize for portability. In this paper we introduce a novel system for targeting analogical search for specific needs. Specifically, we contribute a novel analogical search engine for expressing and abstracting specific design needs that returns more distant yet relevant inspirations than alternate approaches.

##### Abstract (translated by Google)
在遥远的领域找到类比的灵感是解决问题的有力途径。然而，随着可匹配的灵感数量和可能出现匹配的尺寸的增加，设计师找到与其需求相关的灵感变得具有挑战性。此外，设计师通常有兴趣探索产品的特定方面 - 例如，一个设计师可能有兴趣提高户外咖啡机的酝酿能力，而另一个设计师可能希望优化便携性。在本文中，我们介绍一种针对特定需求的类比搜索的新型系统。具体而言，我们提供了一种新颖的类比搜索引擎，用于表达和抽象具体的设计需求，这些需求将比替代方法返回更遥远但相关的灵感。

##### URL
[http://arxiv.org/abs/1712.06880](http://arxiv.org/abs/1712.06880)

##### PDF
[http://arxiv.org/pdf/1712.06880](http://arxiv.org/pdf/1712.06880)


text:
---
layout: post
title: "Design advices for Rails rookies"
date: 2012-04-14 01:55
comments: true
tags: rails programming
category: blog
published: true
---

Sooner or later you'll find that your Rails application is becoming hard
manage. It does not matter how hard you try to keep things simple an DRY.

If you plan to build and app which is
slightly more complex than a blog, then you'd better spend few minutes reading
this article. It's a collection of thoughts written by a guy
(me) who is trying hard (with good results) to keep a quite large code
base easy to maintain.

<!--more-->

Rails is an MVC framework for the web. Let's start giving a look at what those
three letters mean. I'm starting from the bottom just to keep the most
interesting part at last.

## Controller

This layer is where you app decided what to do with the input it receives from
the user. Controllers in MVC are responsible for user input validation
(validation? isn't it in the model?). We have been taught to keep controllers
as thin as possible, in order to keep our application maintainable, and this
is absolutely wise. The general teaching here is to keep much of the *logic*
away from the controller layer, moving it to the model layer.

Controllers in Rails are also responsible of how the data you are asking for
should be represented, at least for what concerns the *format* to be chosen.

Controller layer is also where routing management resides.

### before filters

Before filters form a chain a of method which are invoked in the order
they are defined in your controller and in it's superclass.

While before filters are absolutely useful to keep your controllers
readable, looking at the few lines of code you have in your controller action
may lead you to the wrong assumption that you achieved that 'thin controller'
goal. Well, it may not be the case. Before filters are part of your controller
action. If you define instance variables in your controller you are cheating
at keeping the controller thin.

## View

Views are responsible for data (state) representation. If you are using some
clear conventions on what-goes-where, it's very unlikely for you to get
in trouble here. This layer in Rails is very powerful and does a good job at
keeping complexity well organized.

The only risk here is to put too much logic into views. Again, we have been
told to move logic away
from views, we have been provided with helpers to keep things clean. Helpers
are basically functions into modules, whose namespace reflects the controller
ones. (if you are using automated generators at least).

Given that helpers are methods to be used in your templates, the only state
they can access is given by your template's instance variables. If you try to
do too much with your helpers, you'll very soon end up with a chain of smaller
or bigger functions, with more or less specialized responsibilities, that
basically do stuff with your instance vars. Consider that in a complex
template, made up of several nested partials, it becomes very easy to loose
track of the instance vars you define in your controller (and by controller I
also mean before\_filters).

## Model

Here is the interesting part. Model is the brain, heart and soul of you
application. At least this is what they say it should be. Very soon, while
trying to dodge the dangers described above, you'll understand why models have
this fame. For the rest of this article I'll refer to 'models' meaning just what
Rails puts in app/models folder.

Model is the layer you usually start thinking to when planning your app. It's
where you store data, and where you guard for consistency of your database.
It's also the only part of the code which is not web-related at all.

### Instance methods

In the effort to avoid fat controllers and helper madness you'll start to
enrich your models with new instance and class methods.

As an example:

{% highlight ruby %}

class User
  ...
  def full_name
    "#{first_name} #{last_name}"
  end
  ...
end

{% endhighlight %}

This is not that bad after all and can definitely have his meaning if methods like this are few.
The only problem with this kind of stuff is that the model is worrying about a presentation of
himself. A model can be represented in such a variety of different ways that relying on
such methods for the purpose can make your rows count grow more than you think.

### Relations

Good thing about models is that they can define complex relations with
other models, in the form of the well know has_many and has_one. What can go wrong here?
In my experience, not much. The way ActiveRecord takes care of all the boring/repetitive aspects
of SQL is simply terrific.

### Callbacks (and observers)

Callback is a chain of methods which are invoked during a 'save' action. This chain includes:

- attribute validation
- all things to happen before the record is saved
- all things to happen after the record is saved

If you use them wisely, it's a good place where to organize your models interaction.

Validations should only be used when you want to provide a user with a soft failure, showing nice an
polite error messages. Validations should not be used as a mean of protection
for vital and possibly user-transparent attributes in your model. In fact they can
be avoided by passing :validate => false to .save method.

I.e. you should not use them to protect your 'project_id' column if you are
never offering the user a choice to change it. It's better to use
'before_save' guards for such things.

Before\_validations should only be used when you want to sanitize some input
value or set a default for missing attributes.

After save callbacks should only be used to change the state of other
models when the current record is saved. This is actually the safer place where to do it,
since after_save callbacks are wrapped inside the same transaction that saves the record.

## Put your models on diet

What I've listed so far is all you need to put in your models, not a keystroke
more. Namely, don't use your models to:

### Send emails

Users' inbox is not your database. Furthermore observers and callbacks ready
to spit out emails to your thousands users while you are debugging and fixing
data in rials' console is something that makes me feel nervous so I tend to
isolate such communications in well defined places somewhere else in the
controller (domain objects, read later).

### Interact with external services

Generally speaking, there's nothing wrong with it and it's rather correct to think
about external services as something that belongs the model layer. I'd just
not use an ActiveRecord class for that. Use a Plain Old Ruby Object instead.

 Complex json formatting should
go in the views, use something like [Jbuilder gem](http://rubygems.org/gems/jbuilder).

## So where does the fat go?

In other classes. In few words, what Rails lacks of is at least a couple of
more directories under 'app' folders, just to give newbies a hint that there's
something more to come when they'll start feeling masters of the views, models
and controllers folders.

Common practice is to put other collaborator classes into lib directory. This
is absolutely fine, but I would expect Rails, which is a strongly opinionated
framework, to take a position on this matter and not just leave it completely
uncovered. And by the way, I always think to the lib folder as the antechamber
for a plugin or gem extracted by your app.

Given that 'app' contains code that is strictly belonging to your application,
there are at least three other folders I usually add under 'app':

- presenters
- domain
- mixins

### Presenters

As described above, helpers lack of their own state, and views are as wild as
a jungle. Presenters help to contain all the logic which is required for one
or more model's representation. You can read more about presenters:

- [here](http://robots.thoughtbot.com/post/13641910701/tidy-views-and-beyond-with-decorators)
- [and here](http://robots.thoughtbot.com/post/13641910701/tidy-views-and-beyond-with-decorators)

I prefer to craft my presenters by hand as Plain Old Ruby Objects.

### Domain

This is were I usually put all classes that are not ActiveRecord ones hold
domain logic as well. Classes in here usually use AR in composition.

### Mixins

Depending on the patterns you follow, you may need this folder or not.
This is the place where to put modules that you mean to share between
different classes.

## Conclusion

Maybe 'Big apps in Rails' would be a good title for a book. While we wait for
that title to get published, all we can do is to help ourselves with our own
experience and keep posting our own practices like the article you just read.


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

title: "Google Summer of Code 2020"
subtitle: ""
summary: "Preparing myself for a summer of code on Panel Data Spatial Models."
authors: []
tags: ["GSoC"]
categories: []
date: 2020-06-01T07:49:12-05:00
lastmod: 2020-06-01T07:49:12-05:00
featured: false
draft: false

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

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

This year I was selected to participate in the Google Summer of Code program. Google Summer of Code is a global program focused on introducing students to open source software development. It consists on a 3 month programming project with an open source organization. Specifically, I will work in a [PySAL](https://pysal.org/) Project on Panel Data Spatial Econometrics.

This project aims to extend the functionality of the submodule of Spatial Regression Models of PySAL. This submodule is [spreg](https://spreg.readthedocs.io/en/latest/), short for "spatial regression". The goal is to deal with panel data econometric models. Spatial panels refer to data containing time series observations of a number of geographical units. Specifically, this project will focus on static panel models with fixed and random effects.

To prepare myself for this challenging project, I have been reading a lot of documentation on two topics: 1. How to work on GitHub for open source projects, and 2. Estimation of Spatial Panel data models. For this reason, I want to to share with you the resources that I have found most useful and valuable.

## GitHub resources

1. You should look first for the development guidelines of the open source project you want to collaborate. In PySAL's case, it is [GitHub Standard Operating Procedures](https://github.com/pysal/pysal/wiki/GitHub-Standard-Operating-Procedures).
2. The online book [Pro Git](https://git-scm.com/book/en/v2) is an amazing resource to learn the basic concepts of git.
3. Then, I got some useful and quick help for branches and forks.
    1. [Branches in a Nutshell](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell).
    2. [My Git Branching Cheat Sheet](https://github.com/pabloestradac/GSOC2020/blob/master/docs/git_branching.md).
    3. [My Git PR Cheat Sheet](https://github.com/pabloestradac/GSOC2020/blob/master/docs/git_pr.md).

## Spatial Panel resources

1. Anselin, Luc, Julie Le Gallo and Hubert Jayet (2008). Spatial panel econometrics. In L. Matyas and P.  Sevestre (Eds.), The Econometrics of Panel Data, Fundamentals and Recent Developments in Theory and Practice (3rd Edition), pp. 627-662. Berlin: Springer-Verlag.
2. Elhorst, J. Paul (2014). Spatial Econometrics, From Cross-Sectional Data to Spatial Panels. Berlin: Springer-Verlag.
3. Millo, G., & Piras, G. (2012). splm: Spatial Panel Data Models in R. *Journal of Statistical Software, 47*(1), 1 - 38. doi:http://dx.doi.org/10.18637/jss.v047.i01
4. James LeSage and Robert Kelley Pace (2009). Introduction to Spatial Econometrics. Chapman and Hall/CRC.

repository: pabloestradac/academic-kickstart

repo_name: pabloestradac/academic-kickstart


text:
# DockerEngineApi.PortBinding

## Properties
Name | Type | Description | Notes
------------ | ------------- | ------------- | -------------
**hostIp** | **String** | Host IP address that the container's port is mapped to. | [optional]
**hostPort** | **String** | Host port number that the container's port is mapped to. | [optional]

branch_name: refs/heads/main


text:
# age-discoverer
simple ES6 project to exercise TDD, refactoring, clean code, code coverage, and more.

## Available methods

This project exposes a Javascript class called `AgeDiscoverer`, which has methods for **calculating the approximate age based on the year of birth**, **calculating the exact age based on the birth date** and **cheering on birthday and birth date**.

## Pre-requirements

[NodeJS](https://nodejs.org/) and NPM are required to run this project.

> When installing NodeJS NPM is automatically installed.

> This project was tested with NodeJS version 8.11.2 and NPM version 6.1.0

## Installation

Run `npm install` to install the dev dependencies

## Lint

Run `npm run lint` to check for code style issues.

**Note:** in case of lint issues that can be automatically fixed, run `npm run lint:fix`.

## Tests

Run `npm test` to execute the unit tests.

> Code coverage is executed together with unit tests.

### Test results

If everything is ok you should see a test result like this:

```
$ npm test

><EMAIL_ADDRESS>test /Users/Walmyr/www/ageDiscoverer
> istanbul cover test/test.index.js

TAP version 13
# returns my approximate age when I provide my year of birth
ok 1 should be equal
# returns my wive's approximate age when I provide her year of birth
ok 2 should be equal
# returns zero when providing one year in the future
ok 3 should be equal
# returns zero when providing a hundred years in the future
ok 4 should be equal
# returns correct age when providing year of birth as string
ok 5 should be equal
# returns zero when not providing a year of birth
ok 6 should be equal
# returns zero when providing an invalid year of birth (e.g. NaN)
ok 7 should be equal
# returns correct age even when a negative year is provided
ok 8 should be equal
# returns zero when providing the same year as the current year
ok 9 should be equal
# returns zero when providing a date of birth X day(s) in the future
ok 10 should be equal
# returns the exact age based on date of birth - year of birth past from current year
    and month of birth ahead of current month
ok 11 should be equal
# returns the exact age based on date of birth - year of birth past from current year
    and month of birth previously from the current month
ok 12 should be equal
# returns the exact age based on date of birth - year of birth past from current year,
    month of birth equals to the current month and day of birth ahead of current day
ok 13 should be equal
# returns the exact age based on date of birth - year of birth past from current year,
    month of birth equals to the current month and day of birth previously from the current day
ok 14 should be equal
# returns the exact age based on date of birth - birthday
ok 15 should be equal
# returns zero when providing an invalid date of birth
ok 16 should be equal
# returns zero when providing the the date of birth as the current date
ok 17 should be equal
# returns zero when not providing a date of birth
ok 18 should be equal
# greets on birthday
ok 19 should be equal
# greets on birth date
ok 20 should be equal
# returns undefined when providing birth date X years in the future
ok 21 should be equal
# returns undefined when providing birth date X days in the future
ok 22 should be equal
# returns undefined when providing birth date X months in the future
ok 23 should be equal
# returns undefined when not providing birth date
ok 24 should be equal
# returns undefined when providing invalid birth date (e.g. `const birthDate = new Date('foobar')`)
ok 25 should be equal
=============================================================================
Writing coverage object [/Users/Walmyr/www/ageDiscoverer/coverage/coverage.json]
Writing coverage reports at [/Users/Walmyr/www/ageDiscoverer/coverage]
=============================================================================

=============================== Coverage summary ===============================
Statements   : 100% ( 42/42 )
Branches     : 100% ( 30/30 )
Functions    : 100% ( 6/6 )
Lines        : 100% ( 31/31 )
================================================================================

1..25
# tests 25
# pass  25

# ok
```

**Note:** after pushes to any branch on GitHub, lint and tests are automatically executed on [SemaphoreCI](https://semaphoreci.com/wlsf82/age-discoverer) and the build status can be seen below.

[![Build Status](https://semaphoreci.com/api/v1/wlsf82/age-discoverer/branches/master/badge.svg)](https://semaphoreci.com/wlsf82/age-discoverer)

#### Disclaimer

If tests are executed in any day of January (e.g., 2018-01-16), in the last day of any month (e.g., 2018-06-30) or in the last month of the year (e.g., 2018-12-20), all tests will still pass, but code coverage will not be 100%. This happens due to test helpers that calculate test dates to not depend on hardcoded values, but for example, if a test is executed in December and it needs to test the path of a date one year ago but next month, instead of testing a date in the previous year, the test would be going through the path of the current year, because when summing one month to December we go to January of next year.

## Code quality

Below you can see the status of this project on [Sonar Cloud](https://sonarcloud.io).

![Project Status](https://sonarcloud.io/api/project_badges/measure?project=age-discoverer&metric=alert_status)

> Sonar Cloud evaluates code in terms of bugs, vulnerabilities, code smells, test coverage, and duplications.

The complete dashboard can be seen [here](https://sonarcloud.io/dashboard?id=age-discoverer).
___

Made with 💚 by [Walmyr Filho](http://walmyr-filho.com)


text:
# Nintendo-Switch-Forensics

Autopsy folder contains the following Autopsy ingest modules:

| Module | Purpose |
|---|---|
| ingest_connected_displays | all recently connected displays |
| ingest_game_history | recent game history |
| ingest_crash_dumps | last 50 crash dumps |
| ingest_device_accounts | all user accounts saved to device |
| ingest_gamesaves | all saved games |
| ingest_last_boot | last boot time of device |
| ingest_mp_user_history | last 300 users played with and game played |
| ingest_power_states | device power history |
| ingest_screenshots | all saved recordings and screenshots |
| ingest_wifi | details of all WiFi networks recently connected to |

memory-dump-utils folder contains utilities to aid in performing Switch memory dumps

## Please email questions and success stories to<EMAIL_ADDRESS>
The project's MIT License can be found in [LICENSE.txt](LICENSE.txt).

repository: modux/Nintendo-Switch-Forensics

repo_name: modux/Nintendo-Switch-Forensics