text:
# Document Tracker Connector

## Purpose

The Document Tracker Connector is for debugging processes that needs to be deployed for testing. This connector can be
placed anywhere within the document flow to view the document and easily find the document by use of tracked fields. Modifying a process for debugging can occur easily by placing the connector within the document flow.

The connection requires no setup. The operation also requires no set up, but tracked fields are encouraged. A
new
connector and operation will need to be created. Multiple operations should be created for each insertion point
to view document location within the document flow.

## Getting Started

Installation of a custom connector for Dell Boomi is relatively simple, but it will require Developer privileges to
upload
and release the connector files.

### Download the latest release

Download the latest Document Tracker Connector release from the [Releases](https://github.com/adambedenbaugh/document-tracker/releases) page.

You should now have a zip file that contains the following files:

* document-tracker-connector-\<version>--car.zip
* connector-descriptor.xml

### Create a Boomi Connector Group
Add a custom connector group to your Boomi account by following the instructions described in the Boomi documentation located here: https://help.boomi.com/bundle/connectors/page/t-atm-Adding_a_connector_group.html

### Upload the connector
Using the files that you extracted from the release download, upload the connector to the new connector group by following the instructions described in the Boomi documentation located here: https://help.boomi.com/bundle/connectors/page/t-atm-Adding_a_version_to_a_connector_group.html

### Upgrading the connector version
You can upgrade your Document Tracker Connector version by clicking the "Add Version" button in your existing
Document Tracker Connector connector group.

### How to Use the Connector within Boomi

First start by building out the desired process. Once the process is complete, place the Document Tracker connector anywhere except for the start shape. The incoming document will be visible within Process Reporting. The
connector does not modify the data. The operation should have document tracking setup. This configuration will allow
for the documents passing through the connector to be easily found within Process Reporting.

A connection must be created but there is no configuration needed.

![Document Tracker Connection](resources/DocumentTrackerConnection.png?raw=true)

There is only one configuration within the operation, which is under the Tracking tab. The field should be
populated
with the document id. If you have multiple insertion points within the process, then multiple operations should be
created with unique names to aid in identifying which part of the process the documents originated from.

![Document Tracker Operation](resources/DocumentTrackerOperation.png?raw=true)
![Document Tracker Operation Tracking](resources/DocumentTrackerOperationTracking.png?raw=true)

The below images show a demo Document Tracker Connector process and how it looks like in Process Reporting. Within
the process the Data
Process shape
creates 6 documents. The output of the document is the number of the loop. The ID within Process Reporting is from the
data
within the document (a single element flat file profile).

![Document Tracker Process Overview](resources/DocumentTrackerProcessOverview.png?raw=true)
![Document Tracker in Process Reporting](resources/DocumentTrackerProcessReporting.png?raw=true)

## Example Use Cases:

* Applying document tracking anywhere in the process.  This is especially useful if all the operations are batch.  This connector could be put in line at some point where the documents are split, recording the record id's per document in process reporting and searching by tracked fields.
* Ability to retrieve documents anywhere in the process from the documents API.  This could be particularly useful for test harness processes and test assertion.
* Ability to record un-truncated error results or to process reporting or recording documents at specific steps for troubleshooting.  Notify and exception shapes would logically be used, but are truncated at 10K characters.  The return documents shape can accomplish this, but is not usable in webservice processes since this shape is functional.

repository: adambedenbaugh/document-tracker

repo_name: adambedenbaugh/document-tracker


text:
---
title: 'A Raspberry PI based Arcade'
tags: ["raspberrypi", "python" ]
published: true
date: '2013-11-02'
---

# A Raspberry PI based Arcade

Word “videogame” is for me a big piece of my youth. I spent many hours playing with arcade games when I was young and many of them are still impressed in my mind.

For other like my grew up in the 80s a screen like this:

![Bubble Bobblee](./arcade-image1.png)

are immediately are commented out with something like “AHHH!!! Bubble Bobble what a great game!!”. Yes it was and in a nostalgic day I decided to bring these day to a new life.

Today it’s really simple to play with these old games, You can install MAME in one of it’s flavours and look around for game’s ROM (note: isn’t legal to own ROMS file of games You don’t own). But I was looking for something more, I was looking for reproduce THE FULL EXPERIENCE.

What I wanted was to reproduce the experience of arcade game and for this was mandatory to make one. So I made a custom arcade game cabinet, indeed I made a miniature version of it.

In the Internet there are many projects about making a custom arcade machine but I tried to make one from scratch. As hardware platform I used a RaspberryPI with a custom Linux distribution specifically made for this kind of games : PiMAME. I made the cabinet laser cutting some MDF wood, I don’t own a laser cut machine so I made the CAD drawing and I used vectorealism, a really good online service for laser cut and also 3D print.

First prototype isn’t really cool but making it gave me a lot of satisfaction and experience, this is only a starting point because I’m planning to make a second version with two player support and more attention to aesthetics.

![Tabletop prototype](./arcade-image2.jpg)

This is not the end, this is only a starting point. With experience I gave making the first prototype now I planning to make a second device with more ambitious targets:

- Two player
- More powerful board (I’m evaluating many like BeagleBone Black, Phoenix A20,…)
- More attention to cabinet esthetic
- Simple to build, I’m thinking about a system where cabinet can be assembled like an Ikea one

I’ll post in my blog progress of this second phase.

license: MIT

repository: guglielmino/gumino-site

branch_name: refs/heads/master

extension: md

gha_language: JavaScript

gha_license_id: MIT

license_type: permissive

repo_name: guglielmino/gumino-site


text:
# Known Issues

This is (hopefully a small) list of issues encountered while using PyPi Template that aren't solved yet.

## Publishing to PyPi Fails

```console
$ make publish-test
python setup.py sdist bdist_wheel
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: invalid command 'bdist_wheel'
make: *** [dist] Error 1
```

### Solution

From [https://stackoverflow.com/questions/34819221/why-is-python-setup-py-saying-invalid-command-bdist-wheel-on-travis-ci](https://stackoverflow.com/questions/34819221/why-is-python-setup-py-saying-invalid-command-bdist-wheel-on-travis-ci)

```console
$ pip install wheel
Collecting wheel
  Downloading wheel-0.35.1-py2.py3-none-any.whl (33 kB)
Installing collected packages: wheel
Successfully installed wheel-0.35.1
```

## DocUtils is pinned to 0.16

This is due to an incompatible issue in recommonmark. See [https://github.com/sphinx-doc/sphinx/issues/9049](https://github.com/sphinx-doc/sphinx/issues/9049) for more info.

I'll try to fix this ... in the near future ;-)

repository: christophevg/pypi-template

gha_language: Python

repo_name: christophevg/pypi-template


text:
# Get Started with the Cannlytics API

Getting started making requests to the Cannlytics API can be done in 3 quick steps.

1. First, [create a Cannlytics account](https://console.cannlytics.com/account/sign-up).
2. Second, [create an API key](https://console.cannlytics.com/settings/sign-up).
3. Third, begin making requests to the Cannlytics API with your API Key in an `Authorization: Bearer <token>` header.
<!-- See the examples below for more detailed examples. -->

<!-- TODO: API examples: -->

repository: mathematicalmichael/cannlytics

branch_name: refs/heads/main

repo_name: mathematicalmichael/cannlytics


text:
# Pixel Art Maker
Program Purpose: Allows the user to make pixel art

Features: 16 colors, pencil, eraser, trashcan, square, line, bucket, undo / redo, export, different mouse size

Language: Python and Pygame

[Link to<EMAIL_ADDRESS>
[Inspired by pixilart](https://www.pixilart.com)

![14:31:58](https://user-images.githubusercontent.com/53412192/120903395-8435f280-c60b-11eb-951d-b96d30303164.png)

## Class Overview
###### Pixel
Attributes: Color, position

Methods: Change color

###### Icon - Pencil, eraser, trashcan, etc.
Attributes: Image name, tool / icon name, position

Methods: Draw border

###### Mouse
Attributes: Size, color

Methods: Update - Highlights current pixel, becomes transparent if it is not on the board, changes cursor to diamond if it is on the board

###### Mouse Box - Boxes that show the size of the mouse
Attributes: Position

Methods: Update - Sets to visible or transparent depending on mouse size

###### Color Box - 16 of these that each represent a color presented in a grid
Attributes: Color, position

Methods: Draw circle - draws a circle in the box if it is selected

###### Tool - Each icons individual function when called
Trashcan: Erases the whole board and resets the alternating gray and white grid

Export: Takes a picture of the canvas and saves it to a screenshot folder

Bucket: Fills the surrounding area with a color

Pencil: Changes a pixel's color

Eraser: Resets a pixel's color to its original gray or white

Square: Creates a square based on 2 selected points (Bugs - Sometimes doesn't respond, when undoing, the second point is erased too)

Line: Creates a line based on 2 selected points (Bugs - same as square)

Undo: Reverses the board to the previous state (Bugs - takes 2 clicks for the first undo)

Redo: Restores the board to the state you just had (Bugs - same as undo)

## How the program works - main.py
###### new() - initializing everything
The board and current selections (tool, mouse size, color) are created using a text file that allows for saving previous work.

Each class has its own sprite group and list containing instance

###### run() - performs every essential part of the game loop

###### events() - checks for mouse or keyboard events
Checks for escape key to exit. If it is, the program saves the current board and selections.

Checks if the mouse is being clicked. Everytime the mouse is released, a new board state is pushed to the undo stack

Checks for arrow keys to change the mouse size

###### update() - hanges the board and current selection
Checks if there the mouse and pixel collide. If they do, they perform the necessary function based on the current tool.

Checks if a color box or tool has been selected.

Updates the amount of mouse boxes to be shown.

Updates every sprite (polymorphism)

###### draw() - fills the screen, draws the sprites and borders, updates the display

###### program instance - creates the program

## Install as an executable file
Open the terminal / command line

pip install pyinstaller

Open up a terminal / command line inside the directory

pyinstaller --add-data "board.txt:." --add-data "reset.txt:." --add-data "selections.txt:." --add-data "icons:icons" --add-data "screenshots:screenshots" main.py

Go to dist and select main.exe

Enjoy and happy coding :)


text:
## What’s changed

## 🧰 Maintenance

- 🎆 Updates maintenance/license year to 2023 @frenck (#1534)

## ⬆ Dependency updates

- ⬆ Upgrades python3 to 3.10.9-r1 @frenck (#1517)
- Bump node-red-contrib-time-range-switch from 1.1.3 to 1.2.0 in /node-red @dependabot (#1515)
- Bump node-red-node-email from 1.18.2 to 1.18.3 in /node-red @dependabot (#1526)
- Bump node-red-contrib-home-assistant-websocket from 0.47.1 to 0.48.0 in /node-red @dependabot (#1529)
- Bump node-red-node-email from 1.18.3 to 1.18.4 in /node-red @dependabot (#1528)
- Bump node-red-contrib-persistent-fsm from 1.2.0 to 1.2.1 in /node-red @dependabot (#1531)
- Bump node-red-dashboard from 3.2.3 to 3.3.0 in /node-red @dependabot (#1533)

repository: tyldum/hassio-addons-repository

repo_name: tyldum/hassio-addons-repository


text:
# Confluent Docker Image for Kafka Connect

Docker image for deploying and running Kafka Connect.

_Functionally, the `cp-kafka-connect` and the `cp-kafka-connect-base` images are identical. Prior to Confluent Platform 6.0 the `cp-kafka-connect` image included several connectors pre-installed, but this is no longer the case._

## What is Kafka Connect?

Kafka Connect is part of Apache Kafka, and is used to integrate external systems with Kafka. You can find out more in [the documentation](https://docs.confluent.io/platform/current/connect/index.html#what-is-kafka-connect) and [this short video](https://rmoff.dev/what-is-kafka-connect).

## Using the image

Please see the [Confluent Platform documentation](https://docs.confluent.io/platform/current/installation/docker/installation.html) for further documentation on these images.

### Installing connectors

Kafka Connect is a pluggable framework with which you can use plugins for different connectors, transformations, and converters. You can find hundreds of these at [Confluent Hub](https://hub.confluent.io).

You will need to install plugins into the image in order to use them. This can be done in several ways:

1. [Extend the image](https://docs.confluent.io/platform/current/installation/docker/development.html#extending-images)
2. Add the connector JARs via volumes mounted to the image ([example](https://github.com/confluentinc/demo-scene/blob/master/kafka-connect-zero-to-hero/docker-compose.yml#L82-L87))
3. Install the connector JARs at runtime ([example](https://github.com/confluentinc/demo-scene/blob/master/kafka-connect-zero-to-hero/docker-compose.yml#L89-L101))

### Configuration

[Reference](https://docs.confluent.io/platform/current/installation/docker/config-reference.html#kconnect-long-configuration)
## Contribute

Start by reading our guidelines on contributing to this project found here.

* Source Code: https://github.com/confluentinc/kafka-images
* Issue Tracker: https://github.com/confluentinc/kafka-images/issues

## License

Usage of this image is subject to the license terms of the software contained within. Please refer to Confluent's Docker images documentation [reference](https://docs.confluent.io/platform/current/installation/docker/image-reference.html) for further information. The software to extend and build the custom Docker images is available under the Apache 2.0 License.

repository: confluentinc/kafka-images

repo_name: confluentinc/kafka-images


text:
# ReelMatch
## Table of Contents
* [Desciption](#desciption)
* [Installation](#installation)
* [Usage](#usage)
* [License](#license)
* [Contributors](#contributors)
* [Questions](#questions)
## Description
This is a movie finding application that uses the IMDB API and firebase to save data.

## Usage
1. Clone it down
2. Open it in default browser
## License
[![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
## Contributors
* [Joel Fecke](https://github.com/jfecke)
* [Rebeca Dorado](https://github.com/rebecalvarez)
* [Eduardo Medina](https://github.com/18eddymedina)

## Questions
Please see my github: [Gihub Profile](https://github.com/mollygilbert389)
<br>You can ask me questions here<EMAIL_ADDRESS>


text:
Machine Learning Notebooks
==========================
**Note**
All credit for the code examples of this notebook goes to the book "Hands-On Machine Learning with Scikit-Learn, Keras & TensorFlow" by A. Geron.

All of the code examples are taken from or inspired by Ref. [1]. Modifications were made and text was added primarily by K. Zoch in preparation for the hands-on sessions in summer 2019. This work is stored in his repository:
```
https://github.com/knutzk/handson-ml
```
These Modifications were combined with updates based on the second edition of the book by A. Geron [2]. This work was done by S. Korn.
Since this repository is based on the original repository by A. Geron and work done by K. Zoch, it is made available under the same licensing terms using the Apache License 2.0.
Please make sure to follow the respective conditions of this license when distributing or using this repository.

[1] A. Geron, *Hands-On Machine Learning with Scikit-Learn and TensorFlow*, O'Reilly 2017, ISBN:<PHONE_NUMBER>299
[2] A. Geron, *Hands-On Machine Learning with Scikit-Learn, Keras and TensorFlow*, O'Reilly 2019, ISBN:<PHONE_NUMBER>649

# Obtaining a copy of this repository
To obtain a copy of this repository you can download the ZIP file or use:
```
git clone https://github.com/stkorn-dev/handson-ml2
```


text:
ptest
=====

ptest is a DRY (Don't Repeat Yourself) Microtesting framework for C.

Example
-------

Usage in this format requires a standard or compiler that supports nested function declarations.

```c
#include "ptest.h"

PT_SUITE(suite_basic) {

  PT_TEST(test_maths) {
    int x = 3;
    int y = 11;

    PT_ASSERT(1 + 1 == 2);
    PT_ASSERT(2 + 2 == 4);
    PT_ASSERT(y - x == 8);
  }

  PT_TEST(test_strings) {
    PT_ASSERT(strcmp("x", "x") == 0);
    PT_ASSERT_STR_EQ("x", "x");
  }
}

PT_SUITE(suite_other) {

  PT_TEST(test_stuff) {
    PT_ASSERT(1);
    PT_ASSERT(!0);
    PT_ASSERT("string" != NULL);
  }

  PT_TEST(test_failure) {
    PT_ASSERT(0);
  }
}

int main(int argc, char** argv) {
  pt_add_suite(suite_basic);
  pt_add_suite(suite_other);
  return pt_run();
}
```

Output
------

![Output](https://raw.github.com/orangeduck/ptest/master/output.png)

Example 2
---------

ptest can still be used without nested functions at the cost of some repetition.

```c
#include "ptest.h"

void test_maths(void) {
  int x = 3;
  int y = 11;

  PT_ASSERT(1 + 1 == 2);
  PT_ASSERT(2 + 2 == 4);
  PT_ASSERT(y - x == 8);
}

void test_strings(void) {
  PT_ASSERT(strcmp("x", "x") == 0);
  PT_ASSERT_STR_EQ("x", "x");
}

void test_stuff(void) {
  PT_ASSERT(1);
  PT_ASSERT(!0);
  PT_ASSERT("string" != NULL);
}

void test_failure(void) {
  PT_ASSERT(0);
}

void suite_basic(void) {
  pt_add_test(test_maths, "Test Maths", "Suite Basic");
  pt_add_test(test_strings, "Test Strings", "Suite Basic");
}

void suite_other(void) {
  pt_add_test(test_stuff, "Test Stuff", "Suite Other");
  pt_add_test(test_failure, "Test Failure", "Suite Other");
}

int main(int argc, char** argv) {
  pt_add_suite(suite_basic);
  pt_add_suite(suite_other);
  return pt_run();
}
```

License
-------

Work is Licensed under BSD3

Copyright (c) 2013, Daniel Holden
All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
* Neither the name of the ptest nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

repository: orangeduck/ptest

gha_language: C

repo_name: orangeduck/ptest


text:
TCP/IP stack for DPDK
=====================

The hypercall driver in this repository attaches a userspace
[rump kernel](http://www.netbsd.org/docs/rump/) TCP/IP
stack to a network interface card accessed via the Intel Data Plane
Development Kit [DPDK](http://dpdk.org/).

in rough diagram form:

	------------------------------
	|    application process     |
	||--------------------------||
	|| rump kernel (TCP/IP etc.)||
	||--------------------------||
	|| dpdk-rumptcpip (dpdkif)  ||
	||--------------------------||
	|| DPDK                     ||
	|----------------------------|
	-----------------------------|

Status
------

The driver has been tested to work and is able to exchange TCP traffic
with an Internet peer.  Testing has been done at least with DPDK versions
1.2, 1.3 and 1.4.

Future plans include benchmarking, performance optimization, and
improved configurability.

A [wiki page](https://github.com/anttikantee/dpdk-rumptcpip/wiki/Optimizing-performance) documents some ideas for potential performance optimizations.

Instructions
------------

To use, in addition to a working DPDK installation you need the rump
kernel TCP/IP stack components.  The easiest way to obtain the rump
kernel components is to use the
[buildrump.sh](https://github.com/anttikantee/buildrump.sh) submodule,
as instructed below.

The procedure is follows:

* `git submodule update --init`
* `buildrump.sh/buildrump.sh -s rumpsrc -T rumptools`
* in `src/libdpdkif` of this repo, edit the parameters at the top of
  rumpcomp_user.c, e.g. the interface port to be used.
* still in `src/libdpdkif`: `../../rumptools/rumpmake dependall &&
  ../../rumptools/rumpmake install`.

You can now link and use the DPDK interface driver (`librumpnet_dpdkif`)
into applications.

For more information on how to use the resulting userspace TCP/IP stack,
see e.g. the [buildrump.sh repo](https://github.com/anttikantee/buildrump.sh)
or the [page on rump kernels](http://www.netbsd.org/docs/rump/).

Support
-------

For free support, please use the public
[issue tracker](https://github.com/anttikantee/dpdk-rumptcpip/issues)
offered by GitHub.

If you need commercial support e.g. for development or integration, contact
Antti Kantee<EMAIL_ADDRESS>(Fixup Software Ltd.)

repository: simonhf/dpdk-rumptcpip

repo_name: simonhf/dpdk-rumptcpip


text:
# JavaScriptSnakeGame

### Source:
Built with code and the generous guidance of [Panayiotis Nicolaou's](https://www.freecodecamp.org/news/think-like-a-programmer-how-to-build-snake-using-only-javascript-html-and-css-7b1479c3339e/) snake game tutorial 🐍

### ToDos:
🎉

#### Done:
- Make individual files for HTLM, CSS, and JS
- Refactor code
- Test on Codepen
- Mark credit in code comments and here

repository: UnicodeRogue/JavaScriptSnakeGame

repo_name: UnicodeRogue/JavaScriptSnakeGame


text:
# Skill Concepts

### Understanding Computer Programming
***
### Understanding Data Types in Python
***
### Understanding Decision Structures
***
### Python Loops
   1. while
* With the while Loop we can execute a set of statements as long as a condition is true.

Example 01: Print i as long as i is less than 6:
```python
i = 1
while i < 6:
  print(i)
  i += 1
```

Example 02: Print all letter of your name:

```python
name = 'Victor'
i = 0

while i < len(name):
    print(name[i])
    i += 0
```

* The break statement: we can stop the loop even if the while condition is true:

Example 03: Exit the loop when i is 5:
```python
i = 1
while i < 10:
  print(i)
  if i == 5:
    break
  i += 1
```
- The continue Statement: we can stop the current iteration, and continue with the next:

Example 04: Continue to the next iteration if i is 5:
```python
i = 0
while i < 10:
  i += 1
  if i == 5:
    continue
  print(i)
```
- The else Statement: we can run a block of code once when the condition no longer is true:

Example 05: Print a message once the condition is false:
```python
i = 1
while i < 6:
  print(i)
  i += 1
else:
  print("The condition is false")
```

   2. for

* With the for loop we can execute a set of statements, once for each item in a list, tuple, set etc.

***
### Understanding Exception Handling


text:
---
layout: post
title: "Building Distributed Systems from Scratch - Part 1"
date : 2015-12-02
categories: spark scala talks distributed-systems
---
The below video is a recording of my talk on *Building Distributed Systems from Scratch* in recent spark meet up. It’s first part in series of talks about how to build a distributed processing system from scratch which looks similar to Apache Spark.

Find the slides on [slideshare](http://www.slideshare.net/datamantra/building-distributed-systems-from-scratch-part-1) and code on [github](https://github.com/phatak-dev/distributedsystems).


text:
# ansible-role-cfssl
[![Build Status](https://travis-ci.org/mscislak/ansible-role-cfssl.svg?branch=master)](https://travis-ci.org/mscislak/ansible-role-cfssl)
[![License](https://img.shields.io/badge/License-BSD%203--Clause-blue.svg)](https://opensource.org/licenses/BSD-3-Clause)

This role installs CFSSL (Cloudflare's PKI and TLS toolkit) which includes the following binaries:
- cfssl
- cfssljson
- cfssl-bundle
- cfssl-certinfo
- cfssl-newkey
- cfssl-scan
- mkbundle
- multirootca

## Requirements

None.

## Role Variables

Please see [defaults/main.yml](defaults/main.yml).

## Dependencies

Does not depend on any other roles.

## Example Playbook

```
- hosts: all
  roles:
    - mscislak.cfssl
```

## Versioning

We use [SemVer](http://semver.org/) for versioning. For the versions available, see the [tags on this repository](https://github.com/mscislak/ansible-role-cfssl/tags).

# Author

Maros Scislak

## License

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

repository: mscislak/ansible-role-cfssl

repo_name: mscislak/ansible-role-cfssl


text:
# SU19CSE299S02G012

         North South University

#        Project Name: Bus Route Finder

**                      CSE299: JUNIOR DESIGN**

**                        SEC: 02, Group: 12**

**                Instructor:**  **SHAIKH SHAWON AREFIN SHIMON (SAS3)**

**                      Semester:** **Summer 2019**

**                        GROUP MEMBERS**

                       1. **A.K.M. Kibria Hasan**

                         **ID:<PHONE_NUMBER>**

**                   Email<EMAIL_ADDRESS>
                       2. **Sayma Akter Snigdha**

                         **ID:<PHONE_NUMBER>**

                   **Email<EMAIL_ADDRESS>
          **GitHub Repository Link:** **https://github.com/Shanto96/SU19CSE299S02G12NSU/**

                      **Date Prepared: 19/06/2019**

**Project Idea:**

We are trying to build a Web Apps that will help people to find the best Bus for a specific road. For travelling from one place to another we always try to find best bus and best road. Our plan is to provide the best possible bus according to review and timing. And you always find the shortest and jam free road by using this portal.  And you can also get combination of bus if there any need of multiple bus. You can book your ticket and make payment through a secure payment service.

**Features:**

**A)	Problem it will solve:**

We always wanted to know more about roads condition and which bus will be best for me for a particular road. We always get confused because all bus didn’t give same service and not always fast enough to reach our destination on time. Sometimes we also need to know which bus will be more cost effective and which one is comfortable. For a specific destination there always several road to reach. It is important to know which road is faster, which road is more safe for our journey.\

**B)How it will solve**

We give more priority on a user review. A user can give review how was his journey with this bus but for confirmation user need to upload their ticket and timing.  By checking location of a bus we can track road their movement and trip data. By using this data we can provide our user best bus and road available.

**User Login:**

There will be three or four types of user login system. Like admin who will usually add bus and bus owner. Basically admins main job will be maintaining the whole website. Admin will approve bus owner and normal user. Bus owner can add their stuff for a specific bus or for whole company. Mainly user who gets the main benefit of this website

**User Login:**

1. Sign Up
2. Sign In
3. Become an admin

**Categorywise Bus Selection:**

When someone search for a bus they can filter their search like most affordable to luxurious, which one is time consuming and which one is faster. User can select one by one.

**Review:**

A user can give review of a road or a Bus.  This will put a huge impact on bus service. When searching a bus one will easily get the most rated bus and can read all reviews about this bus. The system will accept a bus review when user can upload bus ticket image.

**•	Ticket Booking:**

Bus ticket booking system is usually become easier. By a SSL secure payment system one can book their ticket by Bkash , Rocket , Paypal and Credit card.

**Sharing:**

Sharing a trip with a friend will be more enjoyable. You can invite your friend to join your trip. Also where safety is issue you can share your location and trip information with your familiar person.

**Technology:**

Giving more priority in user experience and user interface. Our plan is to make eye-catching  online portal using Javascript  with the help  of Node.js and Express.js .We will use google map API for best experience. And we will also create greedy algorithm for searching a bus and its route. For frontend we will use html5,css3,Jquery,Bootstrap . For database our plan is to use SQL Database. We will use PHP for connection.

**Business Plan:**

Our business plan will be unique. Giving opportunity for authority of a bus to promote their features and sell tickets. User can also get benefit with this web portal as they can get authentic reviews and always know about bus service and offers as well.

## Bus Route Finder Junior Project Report

Our plan was to build a Web Apps that will help people to find the best Bus for a specific road. For travelling from one place to another we always try to find best bus and best road. Our plan is to provide the best possible bus according to review and timing. And you always find the shortest and jam free road by using this portal.We hope that our project will help you to get the best route within a click.

## Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. For running this project you need to install localhost and make a database named " bus route". And  there you need to import dbinfo file.

### Prerequisites

Things you need to install the software and how to install them

```
Local host like (Xamp) and a modern web browser and nothing
```

### Installing

A step by step series of examples that tell you how to get a development env running

Say what the step will be

First you need to create an account by clicking singing up . with an email and passord. you need to add all the  information for fully access this.

 Than you can login to homepage .After logging in you'll get a search form where you can search you location and find all the maps, buses, descrition review and everything there . You are now a member of a great web apps.

You can get a little Doller sign in uper right corner of the page thats amount you have, No problem you can add your balance there by requisting to deposit money to admin.

End with an example of getting some data out of the system
If you need to start as an admin of this project you need to firstly create account with username : admin password : admin and email: admim@admin. By clicking  add user and add bus .. You can add as much user and busses you can and buses also. But from backend you will need to add some route first of all you need to add a location and destination of a route . Than you need to add routes with this specific Ld_id. You need to enter iframe of google maps when you inserting routes.
Than the buses option . Firstly you need to add some buses with their company.  And than add this specific buses with a specific route in the bus rout table.
You can also add route rating and bus rating in two different table rout_rating and bus_rating

## Running the tests

Let's open an account with Firstname: John and Lastname :Doe and email<EMAIL_ADDRESS>than you can log in with this email and password which you created when the account was created.

### Break down

After loging in You'll see a animated car with having a search form. There you need to input where you are and where you want to go.After that put a click on the search button and you'll see the routes and buses that are available for you.

Now you can login as like as an admin. And you'll see a user friendly admin pannel will be waiting for you.By which you'll see a statistical and dynamic admin pannel . You'll get all the information you need to see. With different Graphs and statistic you'll easily understand where your system is going.You can also add your important things there.

## Built With

* [PHP](https://www.php.net) - The server used
* [Mysql](https://www.mysql.com/) - The world's most popular open source database  t
* [HTMl5](https://html.com/) - The Web's core language
* [CSS3](https://html.com/) -  Cascading Style Sheets language

## Authors

* **A.K.M Kibria Hasan** - *Initial work* - [Kibria](https://github.com/Shanto96/)
* **Sayma Akter Snigdha** - *Initial work* - [Snigdha](https://github.com/sayma.snighdah)

See also the list of [contributors](#) who participated in this project.

## License

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

## Acknowledgments

* Hat tip to anyone whose code was used
* Inspiration
* etc


text:
  Changelog |
  Documentation |
  Roadmap

  Automated testing for the modern web

  Cypress is a next generation testing tool that helps developers write tests while building apps.

# Contents

- [Overview](#overview)
  - [Features](#features)
  - [Our Mission](#our-mission)
- [Why Cypress?](#why-cypress)
  - [Project Setup](#project-setup)
  - [Writing Tests](#writing-tests)
  - [Management](#management)
- [Key Differences](#key-differences)
  - [Architecture](#videos--screenshots)
  - [Debuggability](#debuggability)
  - [Full Control](#control)
  - [Combatting Flake](#flakiness)
  - [Network Stubbing](#network-stubbing)
  - [Trade Offs](#trade-offs)
- [Testing Strategies](#a-new-paradigm)
  - [End-to-End Tests](#a-new-paradigm)
  - [Integration Tests](#a-new-paradigm)
  - [Unit Tests](#testing-pyramid)
- [Further Reading](#further-reading)

# Overview

Welcome to Cypress: the next-generation testing tool for front-end professionals!

Typically, our users are developers or QA engineers building web applications using modern JavaScript frameworks. Cypress enables us to write **end to end tests**, **integration tests**, and **unit tests**, all of which run in the browser.

Cypress is at once an open source local testing tool *and* a value-added service for continuous integration. At first, we use Cypress to write tests **every day** as we build our application locally (we can even use TDD if we prefer). Later, once we've integrated Cypress with our CI Provider, the [Cypress Dashboard](https://on.cypress.io/dashboard-features) records our test runs and clearly presents the results (so we never have to ask "Why did this fail?")

Cypress is most often compared to [**Selenium**](http://www.seleniumhq.org/); however Cypress is both fundamentally and architecturally different. Cypress is not bound by the same restrictions as Selenium. Cypress enables us to write faster, more reliable tests that achieve **much more** test coverage. Cypress fundamentally shifts the way we test and build web applications.

## Features
- **Familiar Tools:** built on the shoulders of such giants as [**Mocha**](https://mochajs.org/), [**Chai**](http://chaijs.com/), [**Sinon**](http://sinonjs.org/), and [**Electron**](https://electron.atom.io/)
- **Extensive APIs:** offers over 80+ commands to intuitively drive the browser
- **Network Stubbing:** easily mock edge cases; or, isolate from the back-end completely
- **Developer Focused:** plugs directly into our existing development workflow
- **Screenshots / Videos:** great, visual feedback for failures and headless runs
- **Obvious Errors:** see exactly *what* went wrong and, more importantly, *why*
- **Dev Tools / Debugger:** we can use all of our favorite developer tools while we test
- **Time Travel Snapshots:** time travel to any command; step back through every test
- **Fast Setup:** get up and running with no additional installation required
- **Blazing Fast Runs:** tests run as fast as our server can deliver the content
- **ES2015 Friendly:** write modern code with zero configuration

## Our Mission

Cypress is built on best-of-breed, industry-standard technologies, which naturally means we fully embrace open source. It's essential for us to be successful. Our paid services will always be **optional** and Cypress itself will always work independently of them. Our [Dashboard](https://on.cypress.io/dashboard-features) even runs Public Projects for free - just like [Github](https://github.com/), [TravisCI](https://travis-ci.org/), [CircleCI](https://circleci.com) and other developer tools we all know and love.

Our mission is to build a thriving, open source ecosystem that enhances productivity, makes testing an enjoyable experience, and generates developer happiness. We hold ourselves accountable to champion a testing process **that actually works**. We expect our [documentation](https://on.cypress.io) to be simple and approachable, enabling the reader to fully understand not just **what**, but **why**.

We want to help developers build a new generation of modern applications faster, better, and without the stress and anxiety associated with managing tests and their eventual, inevitable failures.

We know that in order for us to be successful we must enable, nurture, and provide a clear path to success for our users. Every line of test code is an investment in the Cypress ecosystem, it will never be coupled to us as a company or a team. Tests written in Cypress-the-application will run completely independently of Cypress-the-company, *always*.

We believe testing needs a lot of love, and we are here to foster a tool, a service, and a community that everyone can learn and benefit from. We're solving the hardest pain points shared by every developer working on the web. We believe in this mission and hope that many will join us to make Cypress a lasting community that helps everyone win.

# Why Cypress?

The way we develop web applications has completely transformed over the last 5 years. The existing testing tools were built for a web that is long gone. When we try to test modern application using old tools, it doesn't work. Over and over again, we struggle with the following challenges:

- [Project Setup](#project-setup)
- [Writing Tests](#writing-tests)
- [Management](#management)

## Project Setup

Developers often complain how difficult it is to start testing their projects. Often, setup requires considerable configuration of many different tools, installing various browser drivers, and writing boilerplate to get to the first test.

With Cypress, we get to our first passing test in **under 5 minutes**.

Cypress comes fully baked with every tool we need and Just Works right out of the box. It can launch headed browsers and **even run headlessly** without a single additional installation step.

Cypress comes with ES2015 support out of the box and is built on top of:

- [Mocha](https://mochajs.org/) rock-solid and configurable test runner
- [Chai](http://chaijs.com/) versatile assertion library
- [Sinon](http://sinonjs.org/) toolbox of spies, stubs, mocks, etc

We provide a full GUI experience and a programmatic [CLI tool](https://docs.cypress.io/docs/cli) to interact with Cypress.

When [adding our first project](https://docs.cypress.io/docs/projects#section-adding-a-new-project), Cypress automatically seeds it with example test code and a fully opinionated project structure.

![project-setup](https://cloud.githubusercontent.com/assets/1268976/23642100/5983acec-02c6-11e7-8951-48cd40cb294b.gif)

## Writing Tests

Relying on [Webdriver's](http://www.seleniumhq.org/projects/webdriver/) architecture often leaves developers struggling to write effective tests. When writing tests, we typically find that:

- Tests are unreasonably difficult to write
- Tests are painfully slow to run
- When errors happen, it's difficult to discern the root cause
- Stack traces in the terminal are frequently worthless
- We do not have access to Dev Tools
- Tests are often inconsistent and flaky
- We have little control over our application under test

These problems stem from the gap between the testing process and the development process. Tests are often written **after** a feature has been implemented. It can take **longer** to write a passing test for a feature than it took to actually build the feature itself!

In order for Cypress to overcome these challenges, we've spent years rewriting the entire testing architecture and creating a familiar environment in which the developer can build their application and the tests that drive it **at the same time**. (We believe in it so much that we've built Cypress itself this way!)

Cypress can run orders of magnitude faster, provides us the ability to debug our applications using the Dev Tools we're already familiar with, and enables us to control our application's environment just like a unit test. This enables an innovative kind of front-end TDD flow for features *as we build them*: instead of manually refreshing the browser and hacking on code, we iteratively build up a test in tandem with the feature. First, we use Cypress as an automation tool, driving the application itself to the feature we're working on. As the details of the feature arise, we encode them into the test, ensuring correctness as we work. Finally, when we lean back and look over the feature we get a strange and wonderful sense that we got the test "for free".

The early adopters of Cypress who've recognized this process have seen a tremendous boost in productivity. Developers end up getting **more** done in a day, in addition to having well-factored and well-tested code.

We fundamentally believe in developer happiness. As a result, we've created hundreds of custom error messages that attempt to explain in simple terms what went wrong. Usually, when a developer first sees a new error message, it can be confusing and too often leads to "dead ends". We've done our very best (and are always improving) at hinting, nudging, and explaining how to best approach writing and running tests.

![writing-tests](https://cloud.githubusercontent.com/assets/1268976/23642090/4b1decee-02c6-11e7-8c5c-ac6a0842ae9b.gif)

## Management

Now that we've spent all this time building up a fleet of tests -- or perhaps because we've got many collaborators and need to coordinate -- we turn to CI (Continuous Integration) to ease the burden of ensuring they pass every time anyone commits new code.

The problem we find here is that, due to the architecture problems of Selenium, it is nearly impossible to manage these tests. They often fail for "no good reason" and we're left scrambling to figure out how to extract useful artifacts like screenshots, videos, and logs of what happened. This takes a lot of work! But without these, debugging failing tests is nearly impossible, leading to wasted time and lost productivity.

Cypress comes fully baked with video and screenshot support. A video is always created when we run headlessly, and screenshots are automatically taken on failure (as well as on-demand when our test code asks for them).

Cypress also enables us to seamlessly **upload and share our test runs** through the [Dashboard](https://on.cypress.io/dashboard). This service provides easy access to see and share recorded runs.

Our Dashboard is attempting to solve some of the hardest challenges of managing tests in CI. We are working towards:

- providing live access to CI runs
- providing all network requests / responses for inspection
- [providing logs of **everything** that happened inside of the browser](https://github.com/cypress-io/cypress/issues/448)
- analytics which provide insight about the overall health of our tests
- an intelligent "diff" of a test which failed today but passed previously
- cross-browser support with automatic integration into Sauce Labs + Browser Stack
- screenshot diff'ing for visual regression testing

![dashboard](https://cloud.githubusercontent.com/assets/1268976/23642018/0a8c46c6-02c6-11e7-82b5-2c1690b7dbf3.gif)

# Key Differences

Let's investigate some of the key differences between Cypress and other testing tools.

## Architecture

Cypress is **not built** on **Selenium / Webdriver**. While it's possible we may use Webdriver for very specific tasks in the future, our automation layer is completely different.

These very specific architectural changes unlocks nearly all of the key advantages and is what separates Cypress from every other existing testing tool.

Cypress is comprised of many discretely independently functioning parts that all together make Cypress work.

For instance Cypress is all of these things:

- Desktop application written in Electron
- Node server running in the background
- Proxy layer which routes and modifies all of your HTTP traffic
- Websocket server handling events from the browser application
- File server for static file serving
- GUI browser application which you test your own application through
- Universal Driver which drives your web application
- Automation API layer which implements each command
- API that you write your tests in
- Browser launcher with its own browser extensions
- Certificate Authority and HTTPS proxy
- Spec file preprocessor and error handler
- File watcher
- CLI tool

When you begin writing your tests in Cypress the first thing you'll notice is that Cypress **itself** ends up being the host application.

When you `cy.visit` your application, this is literally "pulled" into Cypress and gives us several significant advantages.

When Cypress is running, it's coordinating your test commands, the automation layers, and the state of your application in real time.

Because Cypress runs in the same run loop as your application, this gives us significant advantages.

For instance we can:

- listen to events coming from your application and immediately respond to them
- automatically know when elements are animating and wait for them to spot
- always generate events at the right coordinates - it's impossible for us to "miss"
- intelligently handle disabled or readonly elements
- know the moment a page unload has started, pause command execution, and continue again
- automatically know the moment your application reaches the desired state of your assertions
- take shortcuts and force events to happen programatically
- wait for network requests to go out and finish
- have native access to literally every object, function, method of your application
- spy or stub on anything in your 3rd party JS code or app code
- modify and change time - just like in a unit test

While we do much of the automation work in JavaScript itself - we can choose to go outside of the JavaScript sandbox to access automation commands which are restricted to a higher priviledge. We can even invoke native OS commands if we wanted to.

This means we have the best of both worlds. We can do work entirely in the browser, and then choose when it's most appropriate to go outside of them. It's possible we will even yield you this choice and flexibility.

## Debuggability

We remember Selenium / Webdriver errors that look like this:

Browsers are enormously complex objects and their behavior is difficult to be explained with an error message (which is just a string of text).

In the example above, why is the element above not visible?

Here are a few potential answers:

- The selector was written incorrectly
- The app hasn't rendered yet
- There's an error being thrown in the app's JavaScript code
- A network request failed to respond and the element's visibility depends on it
- A network request is still in flight
- There is a real regression and a legitimate error

The problem with existing test frameworks is that it's difficult to find the source of test errors.

We're often left wondering:
- is something **really** wrong?
- did we write our test code properly?
- or is this just inescapable **flakiness**?

At Cypress, we've built **everything** around solving this fundamental problem. Testers using Cypress have access to **all** the information to quickly understand **what**, and more importantly **why**, something failed.

We've done this by:

- Writing hundreds of custom error messages in plain English
- Referencing external documentation for complex errors
- Creating a dashboard to view and collaborate over recorded test runs
- Enabling Dev Tools access while tests run
- Adding support for `debugger` in either test code **and** app code
- Snapshotting and time-traveling through all commands
- Providing a Test Runner that indicates the state of commands, like the number of elements found for a selector
- Displaying additional command information on click
- Logging page events such as XHRs, form submissions, page loads, and URL changes

Even when testing headlessly, an error in the console is much friendlier and provides a lot more data.

But a friendly error is not enough (it's still just a string of text trying to summarize very complex state), which is why we provide a video of the run, a list of command logs, a screenshot at the time of failure, and, soon, we'll have [detailed logs for absolutely everything that happened in the browser](https://github.com/cypress-io/cypress/issues/448) to help track down failures.

***

### Error Messages

***

### Complex Errors

***

### Debugger Support

**In test code:**

**In app code:**

***

### Test Runner Indicators

**Page Events:**

![screen shot 2017-03-11 at 2 58 43 pm](https://cloud.githubusercontent.com/assets/1268976/23826595/ed3272ee-066c-11e7-8a65-e82b7d70658d.png)

**Number of elements found:**

![screen shot 2017-03-11 at 2 57 47 pm](https://cloud.githubusercontent.com/assets/1268976/23826557/6866da8c-066c-11e7-83fc-e3c22dcce767.png)

**Command Inspection / Time Travel:**

## Full Control

Instead of serializing objects "over the wire", you actually have native access to everything in your application.

This means you can literally call functions, bind to events, stub methods, spy on anything like `console.log`, modify 3rd party libs, even change time and tick it forward.

Testing in Cypress actually feels like a mixture between a unit test, an integration test, and an e2e test. By yielding you ultimate control over your application, you can control it and automate it much more precisely and consistently.

You can also take advantage of these API's to do things like "tricking your application" that it's logged in without involving 3rd party sites to do things like oauth authentication. Testing edge cases becomes a breeze.

## Combatting Flake

Flake occurs when a test inconsistently passes or fails for seemingly "no good reason". Here are some of typical reasons why this happens:

- Existing testing tools automate via a stateless HTTP API
- Modern JavaScript applications render asynchronously
- Modern applications make heavy use of XHR, fetch, and websockets

Years ago, when we built web applications they were stateless. When you submitted a form, or clicked a link the browser would make a round trip to the server for the entire new HTML payload.

For these kinds of applications, Selenium / Webdriver worked great - state changes were simple and easy to test.

Unfortunately, with the advent of modern JavaScript frameworks and by embracing the full power of JavaScript asynchronicity - new application we build today are difficult to test using existing testing tools.

This is because Webdriver is a **stateless HTTP API** which executes remote commands into the browser. Today's applications are **stateful** which means their state is "a smear" that changes gradually over a period of time.

A stateless API cannot accurately test a stateful application. Because commands are executed remotely, Webdriver is unable to react or fully understand what it happening in the browser. It can get a "snapshot" of what is going on but it has no idea what is "about" to happen, or when exactly it "does" happen.

Cypress has a completely different architecture than Webdriver. When you test in Cypress, the host application **is** Cypress itself - and from there you "pull in" the application under test.

This means Cypress itself runs in the same run loop at your application. This means that not only do you have **native access** to every single object in your application, but that Cypress can sychronously query for elements, it can add and react to event listeners on your page, it even knows the moment the page begins "unloading" and can pause command execution.

We've designed our API's to fight and reduce flake wherever possible. For instance, every single assertion you right is automatically retryable - that is you simple describe the "state of your application" and Cypress will automatically wait until your application reaches that state.

Cypress can even "look downstream" at a series of commands and assertions and can modify its behavior in real time.  We completely insulate you from having to worry about whether or not your application has ever fully rendered.

We automatically intelligently retry everything until it passes.

## Network Stubbing

Because Cypress is a proxy that sits between your application and your web server - this gives us the ability to modify any of your traffic.

While we currently only allow you to to stub XHR requests, everything is architecturally built to be able to modify or change **any type of HTTP request** - even websocket frames.

Right now, our users modify XHR responses to easily test edge cases. This allows you to  test situations such as pagination or empty views. You can simply respond with the JSON payloads your frontend application expects, and it won't have any idea the request was intercepted. There are no changes to your code.

Besides modifying traffic, we provide you API's to access the XHR request payloads to make assertions about them. Cypress also enables you to programatically wait on XHR requests to happen and for responses to come back.

By waiting for XHR's to happen, it provides you a much tighter contract between your test code and your application code. Instead of causing a side effect and then waiting for that side effect in the DOM, you can explictly describe that "clicking a button" should send an XHR matching a specific URL you specified. Cypress would then intelligently wait on this response before continuing its command execution. We even give you the power to make assertions on the actual response bodies!

When you stub your own network traffic this gives you the ability to build your web applications ahead of your server's API endpoints.

You can instead iterate on the data structure and stub requests in Cypress before your server is even built.

## Trade Offs

- One superdomain per test
- One browser
- Some restrictions / less restrictions
- More control
- Security restrictions
- Not for crawling the web
- Not really for existing production applications
- Not all APIs have been implemented
- No cross-browser support
- No native events (yet)
- Developer / QA engineer focused (must understand the app under test)

# Testing Strategies

With Cypress, you have the ultimate **choice** about choosing the right combination of strategies to write your tests.

**Do not think of Cypress as a simple 1:1 replacement for Selenium.**

While you can write e2e tests similar to what you do in Selenium, you can test much more in Cypress.

To give you a clear idea of what we mean, let's assume we're building a **large scale application** using a modern framework like React.

## End-to-End Tests

Write only a handful of these. Maybe 2-5% of your tests. Test the critical paths only. No edge cases. These will be slow. If you find a restriction in Cypress, continue to write these tests in Selenium. There's nothing wrong with that!

## Integration Tests

Test while you build. Stub out your server. Test edge cases. Bypass your UI as much as possible. Take shortcuts. Stub out 3rd party libs.

## Unit Tests

You can use Cypress to even unit test your browser based libs, utilities or components.

You can test any JavaScript code that eventually makes its way into a browser!

Use cases:

- Importing react components and testing them programatically
- Rendering components into the "application" area of Cypress

---

Contracts between client + server. Total control. Unit test like. Less e2e, more integration. Bypass the UI. Take shortcuts. Be precise.

With Cypress, we have a **choice** about how to we write our tests. We can write "pure" e2e tests, which are similar to what we've done in the past with Selenium. But we can also do **much, much more**.

Use cases:

- importing our react components and calling methods on them programmatically (unit testing)
- short-circuiting our authentication flow when it isn't the system-under-test (huge speed boosts)
- mocking/stubbing XHRs completely (SPAs where the front-end is a stand-alone app)

We have a lot of [recipes showing what Cypress can do](https://github.com/cypress-io/cypress-example-recipes).

## Testing Pyramid

Just like a balanced diet, the testing pyramid recommends 3 primary layers of testing.

1. End-to-End Tests
2. Integration Tests
3. Unit Tests

### End-to-End Tests

End-to-end tests are what we typically do with Selenium. It drives the browser like a real user. The application does what it does and we have very little control. The tests "act like a user". Want to test a chat application with 5 users talking in a group? 5 separate browsers are needed, all connected to the same server and sharing state. **These tests are fundamentally unscalable and we recommend these as little as possible**.

Test the critical paths of the application without any kind of stubbing. This ensures the contract between the back-end and front-end services match up.

The pyramid suggests that these tests should be in shortest supply. In a test suite of 1000 tests for example, no more than about 25-50 of these should be e2e.

There is **always** a better, more practical, and more reliable way to get the same value and coverage while writing a faster, tighter test.

### Integration Tests

This is the bread and butter of Cypress. We still want to visit our application and drive it like a user - but we'll take **as many shortcuts as possible**.

A great example is authentication. We'll certainly write some tests the exercise the login functionality itself, but once that is done we want to avoid repeating those steps for every test. Repeating for emphasis: **WE DO NOT USE THE UI TO LOG IN**. Instead, we simply stitch together the seams of the login experience. In other words, bypass the UI and make the actual request that causes the user to log in.

Another approach is to stub out the server altogether and "trick" the application into thinking it's logged in. This might be done by setting a value in local storage or a cookie, or by stubbing a function such as a 3rd-party OAuth library.

Now we aren't repeating the same UI actions over and over again with each test (which creates no additional value but certainly slows things down!) We can test specific features without the baggage and ceremony of driving the app into a specific state via its UI for each test.

Cypress can also stub network traffic, giving us unprecedented control of the seam between the client and server. We can make the back-end return whatever data we want, for example when the API is in flux, or before the API even exists at all! (The Cypress team itself leverages this workflow to build up the experience and application flow we desire before ever writing a line of back-end/API code.)

Now we can easily do things like test our "empty" views and "pagination" views without ever sending a request or touching a database.

An entire host of e2e problems are avoided and we retain complete control.

SEEK THE SEAMS

While Cypress makes things easy, it is still a programmer's tool. We know we will be writing code to achieve our goals, but we are continually surprised by how little complexity is necessary. By following the best practices, we can achieve simple, declarative, and effective tests.

Testing is both an art and a science, and Cypress brings new concepts to the table as well. We know it takes time to deeply understand this new paradigm and let go the patterns of the past which no longer serve us. Cypress enables a new workflow and we have to learn to deconstruct our applications in new ways, teasing apart the seams to enable better, faster tests.

# Further Reading

So that's where Cypress is going. Want to learn more? Great, let's dive in!

Link | Description
:--- | :---
[Documentation](https://on.cypress.io) | Guides, API Commands, and lots of examples
[Changelog](https://on.cypress.io/changelog) | Notes for new Cypress versions
[Examples](https://on.cypress.io/all-example-apps) | Full example applications
[Recipes](https://github.com/cypress-io/cypress-example-recipes) | Specific tasks and approaches
[Roadmap](https://on.cypress.io/roadmap) | Upcoming major milestones we're working on
[Talks](https://www.cypress.io/explore) | Official conference talks, interviews, podcasts, and shows
[News](https://www.cypress.io/explore) | An unofficial list of 3rd party blogs and articles

repository: kentcdodds/cypress-documentation

branch_name: refs/heads/develop

repo_name: kentcdodds/cypress-documentation


text:
<!-- README.md is generated from README.Rmd. Please edit that file -->

# ITFAnalytics

<!-- badges: start -->
<!-- badges: end -->

The goal of ITFAnalytics is to collect the functions needed to access
and prepare various COVID data sources.

This package is divided into two main sections: analytical datasets and
data visualizations.

## Installation

You can install the released version of ITFAnalytics from
[Github](https://github.com/randyyee/ITFAnalytics) with:

``` r
devtools::install_github("randyyee/ITFAnalytics")
```

## Legacy COVAD - COVID Analytical Datasets

| Metadata Functions  | Get Functions       | Calculation Functions | Production Functions |
|---------------------|---------------------|-----------------------|----------------------|
| get\_countries      | get\_jhu\_covid     | calc\_jhu\_rt         | prod\_dashboard      |
| add\_country\_dates | get\_who\_covid     | calc\_who\_rt         |                      |
|                     | get\_covid\_sources | calc\_rts             |                      |
|                     | get\_vaccinations   | calc\_riskmatrix      |                      |
|                     | get\_testing        | calc\_riskmatrix\_v2  |                      |
|                     | get\_googlemobility | calc\_riskmatrix\_v3  |                      |
|                     |                     | view\_countryoverlays |                      |

## COVIS - COVID Visualizations

| Plot Functions | Map Functions     | Table Functions        |
|----------------|-------------------|------------------------|
| plot\_epicurve | map\_template     | table\_10mostcases     |
|                | map\_burden       | table\_10mostincidence |
|                | map\_trend        | table\_10percentchange |
|                | map\_vaccinations |                        |

repository: randyyee/ITFAnalytics

repo_name: randyyee/ITFAnalytics


text:
# Mutuales SPU - Frontend

This module handles the presentation of the app.

### Introduction

The frontend will provide the following features:

*   Developed using boostrap-v4.0.0
*   angular-v7.0.2
*   angular/cli-v7.0.4
*   [ng-bootstrap-v4.0.0](https://github.com/ng-bootstrap/)
*   [ngx-translate-v11.0.0](https://github.com/ngx-translate)
*   Following the best practices.
*   Ahead-of-Time compilation support.
*   Official Angular i18n support.
*   Production and development builds.
*   Tree-Shaking production builds.

### How to start

**Note** that this seed project requires **node >=v8.9.0 and npm >=4**.

In order to start the project use:

```bash

# install the project's dependencies
$ npm install
# watches your files and uses livereload by default run `npm start` for a dev server. Navigate to `http://localhost:4200/`. The app will automatically reload if you change any of the source files.
$ npm start
# prod build, will output the production application in `dist`
# the produced code can be deployed (rsynced) to a remote server
$ npm run build
```

### Code scaffolding

Run `ng generate component component-name` to generate a new component. You can also use `ng generate directive/pipe/service/class/module`.

repository: fcyt-spu-mutuales/mutuales-frontend

gha_language: HTML

gha_license_id: NOASSERTION

repo_name: fcyt-spu-mutuales/mutuales-frontend


text:
![alt text](https://github.com/bryanrtboy/videoselector/blob/master/IMG_0099.jpg)

## Video Selector

This project uses a Raspberry Pi 3 as a server/controller to play videos on 5 client Pi's connected via a WIFI network. There should be no limit to the number of clients used.

To run, this set of python scripts should be running on the server in a directory located in '/home/pi/', in my case it's in a folder called 'naropa_installation'. Update the script with the path you are using.

The server is wired up through GPIO in order to get input from a rotary encoder [(script)](https://github.com/modmypi/Rotary-Encoder/) , [(instructions)](https://www.modmypi.com/blog/how-to-use-a-rotary-encoder-with-the-raspberry-pi) and two buttons. The rotary dial allows the user to scroll through 3D models rendered on screen, a button is then used to make a selection. Once the button is pressed, a video on one of the client machines starts up. The second button shuts down all of the clients, and then the server.

The script could be altered to accept keyboard commands and not use any GPIO hardware. To do so, set the 'counter' variable to the value -1 with the left arrow key, +1 with the right this would scroll the models left to right.  Use a key press to set READBUTTON to True in order to make the selection. READKNOB is probably not needed, that is used to poll the hardware at a reasonable rate, rather than the 60 FPS of the display loop.

The most difficult part of this project was setting up automatic login from the server to the clients. Notes on how I did that are below.

### Server dependencies
The following should be installed on the server Pi:
- [Paralell-SSH](http://parallel-ssh.readthedocs.io/en/latest/index.html) for connecting to the clients
- [Pi 3D](https://pi3d.github.io/html/) to display the interface elements

### Client dependencies
- [omxplayer](https://github.com/popcornmix/omxplayer)
- [dbuscontrol.sh](https://github.com/popcornmix/omxplayer) install dbuscontrol.sh at the root of each client machine

### Setting up the Server to log in automatically

I generated ssh keys to allow me to start a ssh Terminal session from my MacBook and connect to the server without a password prompt. You should be able to enter `ssh<EMAIL_ADDRESS>and log in with no warnings. Do that first, so that you can understand the process of generating and copying keys. Once that is working, you do the same process from the server Pi's terminal to each client.

Follow the instructions here for to allow [remote access without passwords](https://www.raspberrypi.org/documentation/remote-access/ssh/passwordless.md) on the clients. I was able to use those instructions to do the same on my mac as well.

On the mac, make sure the username you use matches, i.e. bryan@bryans-macbook-2015 where the instructions above say say eben@pi
Once you've done this, if the Terminal keeps asking for a password enter:

```
ssh-add
```
If you get warnings from the mac about suspicious behaviors after swapping out SD cards on the Pi, you need to add/update the pi in the mac's keychain. In Terminal:
`ssh-keygen -f "/Users/bryan/.ssh/known_hosts" -R server.local`

When doing this from the server pi to the clients, use the command:
`ssh-keygen -f "/home/pi/.ssh/known_hosts" -R client0.local`

On the Pi, the `ssh-add` command would not work returning `could not connect agent`.  This seems to mean that the ssh-agent is not running. You need to start it up first:
```
pi@server: exec ssh-agent bash
pi@server: ~/.ssh $ ssh-add
```
This page has some helpful instructions for how to [automatically run ssh-add without a prompt](https://unix.stackexchange.com/questions/90853/how-can-i-run-ssh-add-automatically-without-password-prompt).

You will need to generate a key on the serving machine and then send it over to the client machine, making sure that you have already  set  the client Pi to allow empty passwords.

From the server, follow instructions to [remote access without passwords](https://www.raspberrypi.org/documentation/remote-access/ssh/passwordless.md) in order to log in into the client machine without a password prompt. You'll need to set up each client to allow empty passwords : `sudo nano /etc/ssh/sshd_config` , look for the option to do so in that file.

Copy over the id_rsa.pub to the client machine as instructed in that article. Technically, you can leave the server’s sshd_config as is, just the client needs to allow no password, but following these instructions I set up the server to allow my mac to login without a prompt as well.

#### Setting up a client Pi:

1. Install [jessie or stretch](https://www.raspberrypi.org/documentation/installation/installing-images/), NOT jessie-lite or stretch-lite, omxplayer needs some things.
2. Set the pi up so it does not launch Pixel desktop
3. Create a .ssh folder
```
cd ~
install -d -m 700 ~/.ssh
```
4. Set sshd_config to allow no password : `sudo nano /etc/ssh/sshd_config`
5. From the server pi, [copy over the id_rsa.pub key to the client](https://www.raspberrypi.org/documentation/remote-access/ssh/passwordless.md)
6. Install [dbuscontrol.sh](https://github.com/popcornmix/omxplayer)
```
sudo nano ~/dbuscontrol.sh
sudo chmod 755 ~/dbuscontrol.sh
```
7. Create a [mount point](https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=38058) for the USB drive, where we will store our videos
   - On the Pi make a directory: `sudo mkdir -p /mnt/usb`
   - Then set it to start up and mount to that directory: `sudo nano /etc/fstab`
   - Add this line to the end of fstab: `/dev/sda1 /mnt/usb vfat defaults,nofail 0 2`
   - This setup assumes there is only one usb drive plugged in and it's going to be called `sda`.

If you get errors running dbuscontrol from your scripts, you might need to run omxplayer as sudo.

### Preparing the USB Drives

The clients each expect to have a USB stick with a folder called 'media'. In the media folder, there should be an 'intro.mp4' and child folders corresponding to the names of the 3D models in 'main.py', i.e. gun, cake, fork, knife and bear.
- media
  - gun
    - mov_01.mp4
    - mov_02.mp4
    - etc..
  - cake
  - fork
  - knife
  - bear
  - intro.mp4

Each folder has the same number of videos, numbered in sequence starting with 'mov_01.mp4'. The script randomly picks and plays from those folders.

### Setting up WIFI on all the machines

Add wifi login information to each clients' wpa_supplicant.conf file
```
wpa_passphrase "YOUR_WIFI_NETWORK" "YOUR_PASSWORD" | sudo tee -a /etc/wpa_supplicant/wpa_supplicant.conf > /dev/null
```
After doing that, you can check what was added :
```
sudo nano /etc/wpa_supplicant/wpa_supplicant.conf
```
### Automatically running the script on Startup

Writing the command:
```
sleep 10
python naropa_installation/main.py
```
into `nano ~/.bashrc` works, but it runs with each login. You may have to change [ownership and permissions](https://raspberrypi.stackexchange.com/questions/12853/automatically-run-a-program-as-root-for-gpio) on the main.py and Client scripts for that to work, since the server is using the GPIO pins.

I would love a pull request with a better startup script idea. Seems like there are too many ways to do this on the Raspberry Pi, and many all have issues with permissions, user, etc. For example, adding this to `/etc/rc.local` did not seem to work:
```
startscript(){
  sleep 10
  XAUTHORITY=~pi/.Xauthority DISPLAY=:0 python /home/pi/naropa_installation/main.py
  exit 1
}
startscript&
exit 0
```
The SSH script could not connect to the clients, I'm sure it's because the ssh keys are generated from 'pi' user, not root, and starting up is done by root. Putting the commands to [log into the LXDE](http://www.opentechguides.com/how-to/article/raspberry-pi/5/raspberry-pi-auto-start.html) environment allowed SSH to connect, the clients launched their videos. But, the server display did not show the interface. I could not figure out why not.

Unless someone is trying to do the same thing, i.e. connect via SSH at startup, use the server as the main display, etc., it's difficult to parse where the problem lies and what the best approach might be to run this at startup. Using `~/.bashrc` is OK, but since the display is running as root, it won't respond to keyboard commands. Logging in via another machine, causes a new instance to run, which does respond to keyboard commands, but leaves the first instance running. To quit, you have to:
```
ps aux | less
```
Find the UID of the process
```
killall -9 [UID]
```

repository: bryanrtboy/videoselector

repo_name: bryanrtboy/videoselector


text:
# google-functions

A set of Google Functions sample projects.

All projects were written when Google Functions were in private invite-only alpha stage. I pushed them to GitHub in early December 2017 while I was doing housekeeping of my MacBook. Please note that some features used in these projects may not be available now.

# vision-for-gaming projects

The most interesting projects are vision-for-gaming. I had an idea of writing a robot which would collect money in my children's tablet game. The idea was simple:

1. Arduino robot scrolls the tablet
2. Android takes a screenshot and uploads it to Google Storage
3. Google Functions detects uploaded file, computes coordinates of image chunks, sends the coordinates to Google PubSub
4. Google Functions consumes message from PubSub and runs image recognition (simple moving window) and looks for a money icon
5. Upon detecting Google Functions send coordinates of detected image to Google Cloud Messaging
6. Android receives message from Google Cloud Messaging and via bluetooth sends it to Arduino robot
7. Arduino robot taps on the icon

Steps 1-7 to be executed in the loop. In this GitHub repo you will find the Google Functions part. If you are interested in how to do Android-Arduino bluetooth communication using Google Cloud Messaging you can view my tutorials on hackster.io. Here is how to build a voice controlled robot: https://www.hackster.io/lukaszbudnik/voice-controlled-robot-ebbacf (Alexa) or https://www.hackster.io/lukaszbudnik/voice-controlled-robot-google-cloud-services-94d9a8 (Google Speech).

But getting back to vision-for-gaming projects:

* vision-for-gaming-splitter - Google Functions project that detects an image uploaded to Google Storage, splits the image into smaller parts by computing coordinates of smaller chunks, sends the coordinates to Google PubSub
* vision-for-gaming-image-recognition - Google Functions project that consumes messages from PubSub and performs the image recognition itself

When I ran my first implementation of image recognition on my local machine it was taking 17 minutes. When I re-designed my solution to fully leverage distributed computing and the power of Google Functions I was able to reduce execution time to less than a half a minute. Over 34 times faster. I suspect that with an additional level of parallelism (more chunks) I could reduce the time even further. But the point was already proven :)

repository: lukaszbudnik/google-functions

repo_name: lukaszbudnik/google-functions


text:
# Flakiness

Orbs is a highly distributed system and as such prone to synchronization challenges, race conditions and such. This means some issues are not exposed in tests deterministically.

## Reporting flakiness

When encoutering a new case of suspected flakiness, please follow these steps:

1. Make sure your branch is updated to the latest master.

2. Search [flakiness labeled issues](https://github.com/orbs-network/orbs-network-go/labels/flakiness) for the **test name** which you find flaky. If you find it, add a comment there instead of opening a new issue.

3. Open a new issue, but don't forget any of these:

    * Add the label **flakiness**

    * Make sure the issue name contains the **test name**
        > for example: `TestInterNodeBlockSync_WithBenchmarkConsensusBlocks is flaky because sync is stuck`

    * Make sure the issue body contains a link to the failing **CircleCI build**
        > for example: https://circleci.com/gh/orbs-network/orbs-network-go/8522

    * Copy the few lines of failure from the logs and paste it in the issue body
        > for example:
        ```
        --- FAIL: TestContract_SendBroadcast/DirectTransport (1.14s)
                require.go:794:
                      Error Trace:	transport_contract_test.go:131
                                          transport_contract_test.go:52
                                          context.go:11
                                          transport_contract_test.go:37
                      Error:      	Received unexpected error:
                                    Function #1 OnTransportMessageReceived executed 0 times, expected: 1
                      Test:       	TestContract_SendBroadcast/DirectTransport
        ```

repository: orbs-network/orbs-network-go

gha_language: Go

repo_name: orbs-network/orbs-network-go


text:
# Service objects

Once the VirtualMachineInstance is started, in order to connect to a
VirtualMachineInstance, you can create a `Service` object for a
VirtualMachineInstance. Currently, three types of service are supported:
`ClusterIP`, `NodePort` and `LoadBalancer`. The default type is
`ClusterIP`.

> **Note**: Labels on a VirtualMachineInstance are passed through to the
> pod, so simply add your labels for service creation to the
> VirtualMachineInstance. From there on it works like exposing any other
> k8s resource, by referencing these labels in a service.

## Expose VirtualMachineInstance as a ClusterIP Service

Give a VirtualMachineInstance with the label `special: key`:

    apiVersion: kubevirt.io/v1
    kind: VirtualMachineInstance
    metadata:
      name: vmi-ephemeral
      labels:
        special: key
    spec:
      domain:
        devices:
          disks:
          - disk:
              bus: virtio
            name: containerdisk
        resources:
          requests:
            memory: 64M
      volumes:
      - name: containerdisk
        containerDisk:
          image: kubevirt/cirros-registry-disk-demo:latest

we can expose its SSH port (22) by creating a `ClusterIP` service:

    apiVersion: v1
    kind: Service
    metadata:
      name: vmiservice
    spec:
      ports:
      - port: 27017
        protocol: TCP
        targetPort: 22
      selector:
        special: key
      type: ClusterIP

You just need to create this `ClusterIP` service by using `kubectl`:

    $ kubectl create -f vmiservice.yaml

Alternatively, the VirtualMachineInstance could be exposed using the
`virtctl` command:

    $ virtctl expose virtualmachineinstance vmi-ephemeral --name vmiservice --port 27017 --target-port 22

Notes: \* If `--target-port` is not set, it will be take the same value
as `--port` \* The cluster IP is usually allocated automatically, but it
may also be forced into a value using the `--cluster-ip` flag (assuming
value is in the valid range and not taken)

Query the service object:

    $ kubectl get service
    NAME        TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE
    vmiservice   ClusterIP   <IP_ADDRESS>   <none>        27017/TCP   2m

You can connect to the VirtualMachineInstance by service IP and service
port inside the cluster network:

    $ ssh<EMAIL_ADDRESS>-p 27017

## Expose VirtualMachineInstance as a NodePort Service

Expose the SSH port (22) of a VirtualMachineInstance running on KubeVirt
by creating a `NodePort` service:

    apiVersion: v1
    kind: Service
    metadata:
      name: nodeport
    spec:
      externalTrafficPolicy: Cluster
      ports:
      - name: nodeport
        nodePort: 30000
        port: 27017
        protocol: TCP
        targetPort: 22
      selector:
        special: key
      type: NodePort

You just need to create this `NodePort` service by using `kubectl`:

    $ kubectl -f nodeport.yaml

Alternatively, the VirtualMachineInstance could be exposed using the
`virtctl` command:

    $ virtctl expose virtualmachineinstance vmi-ephemeral --name nodeport --type NodePort --port 27017 --target-port 22 --node-port 30000

Notes: \* If `--node-port` is not set, its value will be allocated
dynamically (in the range above 30000) \* If the `--node-port` value is
set, it must be unique across all services

The service can be listed by querying for the service objects:

    $ kubectl get service
    NAME           TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)           AGE
    nodeport       NodePort   <IP_ADDRESS>   <none>        27017:30000/TCP   5m

Connect to the VirtualMachineInstance by using a node IP and node port
outside the cluster network:

    $ ssh cirros@$NODE_IP -p 30000

## Expose VirtualMachineInstance as a LoadBalancer Service

Expose the RDP port (3389) of a VirtualMachineInstance running on
KubeVirt by creating `LoadBalancer` service. Here is an example:

    apiVersion: v1
    kind: Service
    metadata:
      name: lbsvc
    spec:
      externalTrafficPolicy: Cluster
      ports:
      - port: 27017
        protocol: TCP
        targetPort: 3389
      selector:
        special: key
      type: LoadBalancer

You could create this `LoadBalancer` service by using `kubectl`:

    $ kubectl -f lbsvc.yaml

Alternatively, the VirtualMachineInstance could be exposed using the
`virtctl` command:

    $ virtctl expose virtualmachineinstance vmi-ephemeral --name lbsvc --type LoadBalancer --port 27017 --target-port 3389

Note that the external IP of the service could be forced to a value
using the `--external-ip` flag (no validation is performed on this
value).

The service can be listed by querying for the service objects:

    $ kubectl get svc
    NAME      TYPE           CLUSTER-IP       EXTERNAL-IP                   PORT(S)           AGE
    lbsvc     LoadBalancer   <IP_ADDRESS>      <IP_ADDRESS>,<IP_ADDRESS>   27017:31829/TCP   5s

Use `vinagre` client to connect your VirtualMachineInstance by using the
public IP and port.

Note that here the external port here (31829) was dynamically allocated.

repository: kubevirt/user-guide

gha_language: Makefile

repo_name: kubevirt/user-guide


text:
[![Build Status](https://travis-ci.org/keisukefukuda/mpienv.svg?branch=master)](https://travis-ci.org/keisukefukuda/mpienv)
[![MIT License](http://img.shields.io/badge/license-MIT-blue.svg?style=flat)](LICENSE)

# mpienv
MPI environment selector for Pythonisa

## Background and motivation

Managing multiple MPI installations is hard. It's even harder if you use MPI through Python.

### Environmental setting over SSH (non-interactive sessions)

As often asked on Stack Overflow (such as [this question](https://unix.stackexchange.com/questions/170493/login-non-login-and-interactive-non-interactive-shells)),
setting environmental variables on remote hosts are sometimes hard, in particular on Ubuntu
platforms.

### MPI and mpi4py

When you have multiple MPI installations, it is time-consuming and error-prone situation.
To switch the active MPI, it is not enough to modify `PATH` and `LD_LIBRARY_PATH`.
It is because the `mpi4py` library binary, namely `MPI.so`, is linked to the previous MPI
installation.

To properly switch the MPI installation, you need to reinstall `mpi4py` everytime you
switch MPI.

```
$ pip uninstall -y mpi4py
$ pip install mpi4py --no-cache-dir
```

Mpienv is designed to avoid such issues and provide a smooth workflow to work on multiple
Python and MPI combinations.

## Installation

First, install mpienv via `pip`

```bash
$ pip install mpienv
```

## How to start

After installing, insert the following line into your `.bashrc` or any other initialization shell script.
```
$ eval "$(mpienv-init)"
```

OK, let's see what `mpienv` does.

```bash
$ mpienv list

# no output
```

The `list` command prints a list of MPI instances. As of now, there
should be no output from the command because `mpienv` has no
information about your system. Let's find MPI libraries on your system
by hitting:

The `autodiscover` command will traverse the directories of you system
and find all installed MPI libraries. The output would look like the
following (it would take some time):

```bash
$ mpienv autodiscover

$ mpienv autodiscover /usr/local/Cellar

--------------------------------------
Found /usr/local/Cellar/mpich/3.3/bin/mpiexec
Type    : MPICH
Version : 3.3
Path    : /usr/local/Cellar/mpich/3.3

# (...snip...)
```

The command searches several possible locations on your system.  If
you have any idea of location where MPIs are installed, you can
specify them to save time:

```bash
$ mpienv autodiscover path1 path2 ...
```

After you find MPI installations on your system, you can register them
using `mpienv add` command.

```bash
$ mpienv add /opt/local
```

Let's check if the MPI is added properly:

```bash
$ mpienv list

Installed MPIs:

   mpich-3.3a1 -> /opt/local

```

If you are too lazy to add all the found MPIs manually, you can just use

```bash
$ mpienv autodiscover [--add|-a]
```

This command automatically `add`s all the MPI installations.

## Activating an MPI

Let's assume your `mpienv list` shows the folloing:

```bash
$ mpienv list
Installed MPIs:

   mpich-3.2     -> /Users/keisukefukuda/mpi/mpich-3.2
   mpich-3.3a1   -> /opt/local
 * openmpi-2.1.1 -> /Users/keisukefukuda/mpi/openmpi-2.1.1
```

The `*` mark indicates that the MPI `openmpi-2.1.1` is active, which
means it's on the `PATH` and `LD_LIBRARYPATH` environment variables.
You can check that `openmpi-2.1.1` is active.

```bash
$ mpiexec --version
mpiexec (OpenRTE) 2.1.1

Report bugs to http://www.open-mpi.org/community/help/

```

You can switch the active MPI using `use` command.

```bash
$ mpienv use mpich-3.2
$ mpienv list

Installed MPIs:

 * mpich-3.2     -> /Users/keisukefukuda/mpi/mpich-3.2
   mpich-3.3a1   -> /opt/local
   openmpi-2.1.1 -> /Users/keisukefukuda/mpi/openmpi-2.1.1

$ mpiexec --version
HYDRA build details:
    Version:                                 3.2
    Release Date:                            Wed Nov 11 22:06:48 CST 2015
    CC:                              gcc
    CXX:                             g++
    F77:
    F90:
    Configure options:
    # (snip)
    Process Manager:                         pmi
    Launchers available:                     ssh rsh fork slurm ll lsf sge manual persist
    Topology libraries available:            hwloc
    Resource management kernels available:   user slurm ll lsf sge pbs cobalt
    Checkpointing libraries available:
    Demux engines available:                 poll select
```

"mpich-3.2" is now active.

## Running MPI applications
To run your MPI application, you need to specify a few options to the `mpiexec` command.

```bash
$ # If you use Open MPI
$ mpienv list

Installed MPIs:

  mvapich2-2.2  -> /usr/local
  openmpi-1.6.5 -> /usr
* openmpi-2.1.1 -> /home/kfukuda/mpi/openmpi-2.1.1

$ mpienv exec -n ${NP} --hostfile ${HOSTFILE} ./your.app
```

```bash
$ # If you use MPICH/MVAPICH
$ mpienv list

Installed MPIs:

* mvapich2-2.2  -> /usr/local
  openmpi-1.6.5 -> /usr
  openmpi-2.1.1 -> /home/kfukuda/mpi/openmpi-2.1.1

$ mpienv exec --genvall -n ${NP} --hostfile ${HOSTFILE} ./your.app
```

If you are curious about what `mpienv exec` does, try `--dry-run`.
It shows the command to execute and the content of a generated helper shell script.

```
$ mpienv exec --dry-run -n 2 hostname
mpienv exec: INFO: tempfile = /tmp/KeisukenoMacBook-Pro.local.50192.20190430150049.mpienv.sh
mpienv exec: INFO: hosts = ['localhost']
/usr/local/Cellar/mpich/3.3/bin/mpiexec -n 2 /tmp/KeisukenoMacBook-Pro.local.50192.20190430150049.mpienv.sh

/tmp/KeisukenoMacBook-Pro.local.50192.20190430150049.mpienv.sh
---
#!/bin/bash

export MPIENV_HOME=/Users/keisukefukuda/.mpienv

export PATH=/usr/local/Cellar/mpich/3.3/bin:/Users/keisukefukuda/.cargo/bin:/Users/keisukefukuda/local/bin:/Users/keisukefukuda/.pyenv/shims:/Users/keisukefukuda/.pyenv/bin:/Users/keisukefukuda/.cargo/bin:/usr/local/bin:/Users/keisukefukuda/lcoal/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Library/TeX/texbin

export LD_LIBRARY_PATH=/usr/local/Cellar/mpich/3.3/lib:

export PYTHONPATH=/Users/keisukefukuda/.mpienv/versions/pylib/Users_keisukefukuda_.pyenv_versions_3.6.1_bin_python3.6/mpich-3.3:

export MPIENV_MPI_TYPE="MPICH"
export MPIENV_MPI_VERSION="3.3"
export MPIENV_MPI_NAME="mpich-3.3"

hostname

```

Of course, you can use `mpiexec` as usual.

## Using Python together

If you use MPI with Python and want to swtich multiple MPI
installations, what annoys you is that `mpi4py` is tied to a single
MPI instance when it is compiled and installed. This means that you
have to do

```bash
$ pip uninstall mpi4py

$ # switch MPI

$ pip install mpi4py --no-cache
```

every time you swtich to another MPI.

`mpienv` supports this use case.

```bash
$ mpienv use --mpi4py openmpi-2.1.1
```

This command installs an `mpi4py` instance on a specific location
using `pip`'s `-t` option, and set `PYTHONPATH` environment variable
to activate it.

```bash
# Now openmpi-2.1.1 is active
$ mpienv use mpich-3.2
$ mpiexec -n 2 python -c "from mpi4py import MPI; print(MPI.COMM_WORLD.Get_rank())"

### Error!

$ mpienv use --mpi4py mpich-3.2
$ mpiexec -n 2 python -c "from mpi4py import MPI; print(MPI.COMM_WORLD.Get_rank())"
0
1
```

OK, now your `mpi4py` is properly set up. To run Python script on multiple nodes,
you need to pass an additional environment variable `PYTHONPATH`.

```bash
$ # Open MPI
$ mpiexec --prefix /home/kfukuda/mpi/openmpi-2.1.1 -x PYTHONPATH -n ${NP} --hostfile ${HOSTFILE} ./your.app

$ # MPICH/MVAPICH
$ mpiexec --genvall -n ${NP} --hostfile ${HOSTFILE} ./your.app
```

repository: keisukefukuda/mpienv

repo_name: keisukefukuda/mpienv


text:
# Akvaario Customer Window

## What is Akvaario?

Akvaario is a dashboard that gathers project information. It improves transparency by offering customers a proper image of project and product status with a quick view.

Akvaario is not a two-way communication tool and should complement, not replace, the current communication channels. Although communication through Akvaario isn’t in both ways it supports the communication process at least in the five following ways:

**a) Increases visibility:** Makes customers more aware of the project status, and thus increase trust and ease decision making.

**b) Automates informal reporting:** Eases the System manager's workload by offering up-to-date information.

**c) Highlights meaningful information:** Allows both the customer and Futurice to form a more complete image of the overall situation, and reduces information overflow.

**d) Gives clearer overview:** Gives a quick overview of tools and Systems used, as well as the people involved in a project, to e.g. a new project member.

(Possibly in the future - Introduces additional value-adding FutuSystems: Shows Systems that the customer has not yet purchased but can be integrated with Akvaario to create additional value.)

## Who did this?

The origins of Akvaario are shrouded in mystery, but legend says that the idea was forged in the mythical cave of LCM.

More recently, the idea was used in the Aalto University course T-76.4115 Software Development Project as a student project.

The students who worked on it were:
* [Christian Arrhenius](https://github.com/carrheni) PM
* [Oskar Ehnström](https://github.com/Ozzee) QA
* [Raoul Udd](https://github.com/rrudd) Architect
* [Patrik Carlson](https://github.com/patrikcarlson)
* [Nicolas Dolenc](https://github.com/NicolasDolenc)
* [Valter Kraemer](https://github.com/valterkraemer)
* [Nestor Köhler](https://github.com/nkohler)
* [Niklas Lindroos](https://github.com/nlindroos)
* [Jussi Paakkola](https://github.com/morakh)

## Development

For developing you need the following:

* [Play 2.2.x](http://www.playframework.com)
* [MongoDB](https://www.mongodb.org/)
* [Pybot & Selenium](docs/robot.md) (for front-end testing)

More comprehensive guides for installing the environment are available for: [Mac OS X](docs/installation_mac.md), [Linux](docs/installation_linux.md) and [Windows](docs/installation_windows.md).

### Architecture

![alt text](docs/architectural_model_20140205.png "General architecture").

A more thorough guide to the architecture can be found in the [Anatomy of Akvaario](docs/architecture_anatomy.md)

### Testing

This project uses the built-in Play testing framework as well as end-to-end tests using the robot framework and selenium. This section goes through the Play-tests. See [this guide](docs/robot.md) for more information about the robot tests.

Start by opening the play console:

	$ play

The following commands should be run either in the Play! console or by adding "play" before them and running in the terminal.

To clean the project before running it:

	clean

To run the tests:

	test

For code coverage report, run:

	scoverage:test

The resulting html report will be in target/scala-2.10/scoverage-report

The tests are located in the /test-folder.

*The securesocial-folder is included as the test framework for that particular plug-in was not included in the latest builds at the time of writing. It should be removed as soon as the test-framework is included in the official build of securesocial.*

### Environment settings

The credentials addresses for certain services should be stored in separate configuration files and not stored in VC. To use these configurations you need to specify the configuration files Play! should use.

When running/starting play the correct conf-file can be set by running the following command

	play -Dconfig.resource=DESIRED_ENVIRONMENT.conf

Followed by the desired command (start/run/test etc.).

# Deployment

For a full deployment guide, see [deploy.md](docs/deploy.md). Apache example configurations may be found in [apache2.md](docs/apache2.md).

## Version Control

This project uses [git](http://git-scm.com/) and [git-flow](https://github.com/nvie/gitflow). A short introduction to git-flow in this project can be found [here](docs/git-flow.md).

## Useful commands

### Clear database

To drop all directories in the database, go to the project's root directory and enter the command

	mongo mongo/dropDB.js

## Analytics

This project uses [Google Analytics](http://www.google.com/analytics/). For a more comprehensive guide to the implementation, see [Google Analytics quick userguide](docs/google_analytics.md)

## Libraries used

### Front-end

* [AngularJS](http://angularjs.org/) MIT License
* [Bootstrap](http://getbootstrap.com/) MIT License
* [UI Bootstrap](http://angular-ui.github.io/bootstrap/) MIT License
* [jQuery](http://jquery.com/) MIT License
* [Google Analytics](http://www.google.com/analytics/)
* [Dimple](http://dimplejs.org) MIT License
* [D3](http://d3js.org) BSD 3-Clause License
* [Font Awesome](http://fontawesome.io) MIT License

### Play Framework

* [Play Framework](http://www.playframework.com/) Apache 2 License
* [ReactiveMongo](http://reactivemongo.org/) Apache 2 License
* [FixturesPlugin.scala](https://github.com/schleichardt/play-2-mongodb-app) Apache 2 License
* [MongoUserService.scala](https://github.com/sarchak/CrowdSource)

### Testing

* [Robot framework](http://robotframework.org/) Apache 2 License
* [Selenium](http://docs.seleniumhq.org/)

## License

MIT License (MIT)

Copyright (c) 2014 Futurice Oy

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

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

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

repository: kalburgimanjunath/aquarium

repo_name: kalburgimanjunath/aquarium