text:
# Bootcamp - FinalProject: AlpaKa

## Description

First draft for music label **AlpaKa MuziK**'s website. Visit artist page to visit label artists' soundcloud pages. Releases page visit content presentation with an integrated music player to listen to the label releases.

Admin page. Administrator self-sufficiency for updating content.

## Stack

- MongoDB
- Express
- React.js
- Node.js

## Requirements

> Create a web application using both front and back-end technologies, including a database.

## Features

- Presentational content for Alpaka
- Functional administrator page
- Listen to releases
- Visit label artists' soundcloud pages
- Add/edit/delete content

[Click here for a quick YouTube demo](https://youtu.be/XR7Lpe3EkbI)

repository: RobPanneton/project-Final-Alpaka

repo_name: RobPanneton/project-Final-Alpaka


text:
# How to: Setup a React development environment on Mac

Guide to installing the tools required to run React+Webpack (via create-react-app) on Mac

> **Attention! Before getting started!** This guide was tested on Mac OS 10.11 using Node v6.11.1 and npm 5.3.0.

## Steps

1. Running the Terminal.app and Installing Homebrew
2. Install Node.js
3. Upgrading **npm**
4. Installing **create-react-app**
5. Creating a basic React application
6. Starting your React application
7. Editing your React application
8. Releasing your React application to the public

---

### 1. Opening Terminal.app

Using Spotlight (option+space), search for **Terminal.app** and hit _return_ top open it.

Next, install XCode's command line tools by typing in:

```bash
xcode-select --install
```

Once this is installed, you can move on to...

---

### 2.  Install Node.js via nvm

[NVM](https://github.com/creationix/nvm) is a version manager that lets you easily run multiple versions of Node on MacOS or Linux. Run this command to install nvm: [Additional info about isntall nvm here](https://nodesource.com/blog/installing-node-js-tutorial-using-nvm-on-mac-os-x-and-ubuntu/).

```bash
curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.0/install.sh | bash
```

This will install NVM. Once it is done, verify that everything is installed correctly. In your terminal, type in:

Now we'll install the the LTS (long-term service) version of Node via NVM. Run

```bash
nvm install --lts
```

---

### 3. Installing create-react-app

There is a boilerplate already written for react - it is called _create-react-app_. It is available, like many other scripts, on the _node package manager (npm)_. We can install it using the `npm i` command again. Run the following code in your terminal:

```bash
npm i -g create-react-app
```

This can also take a few moments - `npm` is having to install React and other tools on your computer. Once complete, you'll see output similar to this:

```bash
$ npm install create-react-app -g
/Users/James/.npm/create-react-app -> /Users/James/.npm/node_modules/create-react-app/index.js
+<EMAIL_ADDRESS>updated 1 package in 41.553s
```

---

### 4. Creating a basic React application

> You're over halfway there! Keep it up!

It is time for you to finally create a React application from the `create-react-app` boilerplate. When you use `create-react-app`, you should specfiy a name for your application. It will create the following file structure for you in a folder with the name of your app. That structure looks like this:

```bash
├── README.md
├── package.json
├── public
│   ├── favicon.ico
│   └── index.html
└── src
    ├── App.css
    ├── App.js
    ├── App.test.js
    ├── index.css
    ├── index.js
    └── logo.svg
```

The `index.html` has all of the App.js code _injected_ into it using the tools that `create-react-app` provides. It even creates start Javascript and CSS files for you. **This should make you feel awesome!**

Time for you to try it out. Run:

```bash
create-react-app hi-react
```

This creates a folder wherever you are called `hi-react`. _create-react-app_ tells you where this is installed so you can easily find it to open in your text editor. Once complete, you should see the following (or similar):

```bash
$ create-react-app hi-react
Creating a new React app in C:\Users\James\hi-react.

Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts...

+<EMAIL_ADDRESS>+<EMAIL_ADDRESS>+<EMAIL_ADDRESS>added 1205 packages in 54.568s

Success! Created hi-react at C:\Users\James\hi-react
Inside that directory, you can run several commands:

  npm start
    Starts the development server.

  npm run build
    Bundles the app into static files for production.

  npm test
    Starts the test runner.

  npm run eject
    Removes this tool and copies build dependencies, configuration files
    and scripts into the app directory. If you do this, you can’t go back!

We suggest that you begin by typing:

  cd hi-react
  npm start
```

---

### 5. Starting your React application

_create-react-app_ includes a web server to test your app on. You'll need to _change directory_ (cd) into your applicaton to run it. Do this:

```bash
cd hi-react
```

And then run:

```bash
pwd
```

You should see that you your `hi-react` folder:

```bash
$ pwd
/c/Users/James/hi-react
```

Now, start your application using `npm` --

```bash
npm run start
```

You'll be informed that your application is running. It _should_ also open up a new web browser pointing to the correct (but temporary) URL.

```bash
$ npm run start

><EMAIL_ADDRESS>start C:\Users\James\hi-react
> react-scripts start

Starting the development server...

Compiled successfully!

You can now view hi-react in the browser.

  Local:            http://localhost:3000/
  On Your Network:  http://<IP_ADDRESS>:3000/

Note that the development build is not optimized.
To create a production build, use npm run build.
```

You can also browse tothe _local_ address provided. In this case, you could point your browser to [http://localhost:3000/](http://localhost:3000/)

You should see the React starter page.

![react.PNG](react.PNG)

---

### 6. Editing your React application

You'll notice that you're encouraged to edit the `src/App.js` file. This is where you can shine!  Refresh your application in the browser and you'll see your changes are updated.

You should also take a moment to install the [React Developer Tools Extension for Chrome](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi?hl=en).

Once they are installed, you will have a new _tab_ under DevTools to the far right. If you select it, you can see React components clearly.

![devtoolsreact.PNG](devtoolsreact.PNG)

> If you ever need to stop your server, press `control + c` at the same time. This will stop _any_ terminal process.

---

### 7. Releasing your React application to the public

Once you are satisfied with your application, it is time to bundle your code together ready for the web. `create-react-app` will bundle your code, remove whitespace, obfuscate it so it is harder for others to read, and make it take up less space. Press `control + c` at the same time to exit your React server if you have not already. Once you have done that, you will see that you can enter more commands in your terminal. Run the following:

```bash
npm run build
```

This process can take a few moments. Once it is complete, the _entire_ contents of your website will be available in the **build** subdirectory of your project. It will contain the following files and folders:

```bash
asset-manifest.json  favicon.ico  index.html  manifest.json  service-worker.js  static/
```

All of these files and folders can then be uploaded to a website for production or be distributed to clients for a final release.

*fin*

license: MIT

repository: andrewdushane/react-on-mac

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: andrewdushane/react-on-mac


text:
# reactjs-flask
React JS with Python Flask

# Client
>Client side code resides in client folder.

>### Install Dependencies
cd client

npm install

# Server
>Server side code resides in server folder.

cd server

pip install requirements.txt

python routes.py


text:
---
title: Contact the GraphQL Foundation
sidebarTitle: Contact us
heroText: The GraphQL Foundation is here to help.
layout: foundation
category: GraphQL Foundation
permalink: /foundation/contact/
sublinks: Membership Inquiries,Membership Support,Meeting Logistics,Trademark Requests,Media Inquries,Technical Issues,General
next: /foundation/annual-reports/
---

The GraphQL Foundation is supported by staff from [The Linux Foundation](https://linuxfoundation.org). If you have questions, please reach out to us using the links below.

_Please note that we do not provide user support for GraphQL. If you have an implementation question,
please use the [relevant community channels](/community/)._

## Membership Inquiries

If you would like to learn more about becoming a GraphQL member, please email
[membership@graphql.org](mailto:membership@graphql.org).

## Membership Support

If you are already a member of the [GraphQL Foundation](/foundation/) and you need help with your membership, please file an issue with our [member service desk](https://members.graphql.org).

## Meeting Logistics

Governing board and Working Group members who need help with meeting logistics (setting up a Zoom conference, adding or changing a calendar entry, designating an alternate representative, etc.) can reach out through our [member service desk](https://members.graphql.org).

## Trademark Requests

For guidance using the GraphQL trademark and brand see our [brand guidelines](/brand). For trademark licensing questions or requests please reach out to [info@graphql.org](mailto:info@graphql.org?subject=Trademark%20Request).

## Media Inquiries

For media inquiries, please reach out to [pr@graphql.org](mailto:pr@graphql.org).

## Technical Issues

To report a technical issue with GraphQL, please use the [community channels](/community/).

## General

For all other inquiries, please email [info@graphql.org](mailto:info@graphql.org).

Our mailing address is:

> **GraphQL Foundation**
> 548 Market St
> PMB 57274
> San Francisco, California
> 94104-5401 US

branch_name: refs/heads/source

gha_language: TypeScript

gha_license_id: MIT


text:
---
title: "About Metrics"
---

By default, metrics are collected every 5 minutes, but you can adjust it with the `logsearch.metrics.frequency`
property. As an example, if you wanted to check once a minute, you could use the following:

    properties:
      logsearch:
        metrics:
          frequency: 60

If you prefer to completely disable this functionality, you can set `logsearch.metrics.enabled` to `false`.

Internally, metrics are treated as log file messages, so they use the same configuration documented in the Logs
section. This means the measurements will have several fields added, according to your defaults (e.g. `bosh_deployment`
and `bosh_job`). By default, metrics are also set with a `type` field set to `metric`.

Metrics are collected from several sources. The first set of metrics are enabled by default and come from the host:

 * `cpu` - idle, interrupt, nice, soft IRQ, steal, system, user, and wait (by core)
 * `disk` - merges, bytes, operations, and time (by read, write; by disk); disk space used, free, and reserved (by disk)
 * `loadavg` - short, mid, and long-term
 * `memory` - buffered, cached, free and used bytes
 * `network` - errors, bytes, and packets (by received, transmitted; by interface)
 * `processes` - blocked, paging, running, sleeping, stopped, and zombie states; fork rate
 * `swap` - cached, free, and used; I/O in and out
 * `users` - logged in

You can optionally disable those metrics by setting the respective `logsearch.metrics.host.{source}` property to
`false` (e.g. `logsearch.metrics.host.cpu: false`). These metrics are all named with a `host.` prefix.

A second set of metrics are automatically generated from the monit-managed processes and they include the following
(per process):

 * `children` - number of child processes
 * `cpu` - CPU usage of the parent and child processes
 * `memory` - memory (in bytes) of the parent and child processes
 * `status` - process status (0 = active, 1 = inactive, 2 = ignored)
 * `uptime` - seconds the process has been running

These metrics are enabled by default and are prefixed with `monit.` and the monit process name (e.g.
`monit.logsearch-logs.uptime`). If you prefer to disable these metrics, you can set the
`logsearch.metrics.monit` property to `false`.

The third set of metrics are generated by custom scripts. These scripts are run in an empty environment except for a
`METRIC_FREQUENCY` indicating how frequently it should collect metrics (in seconds). They should run indefinitely until
they receive an `INT` signal and they must output measurements to `STDOUT` in the following simple format:

    {metric-name:string} {metric-value:number} {unix-timestamp:integer}

By default, this release will auto-discover collector scripts which are named with the following convention:
`/var/vcap/jobs/{template-name}/logsearch/metric-collector/{collector-name}/collector`. Alternatively, you can use YAML
configuration documents using the following format to specify scripts in different locations, or override individual
settings per collector:

    collectors:
      {name}:
        enabled: {boolean=true}
        frequency: {integer=logsearch.metrics.frequency}
        exec: {string} # script executable path

Auto-discovered scripts are named using `{template-name}--{collector-name}`. As an example, take a look at the
[built-in `metrics.yml` file](./jobs/logsearch-shipper/templates/logsearch/metrics.yml.erb) which controls whether the
[built-in monit collector](./jobs/logsearch-shipper/templates/logsearch/metric-collector/monit/collector) (mentioned
earlier) is run.

Similar to configuring logs, you may store YAML configuration in the following locations:

 * property `logsearch.metrics._defaults`
 * files `/var/vcap/jobs/*/logsearch/metrics.yml`
 * property `logsearch.metrics._overrides`

# Naming

When you're writing metric collectors, you should follow these recommendations for metric names:

 * use namespaces, starting with the template and collector name
 * use `.` to separate namespace levels
 * use the character range of `a-z0-9._`

repository: logsearch/logsearch-shipper-boshrelease

gha_language: Ruby

repo_name: logsearch/logsearch-shipper-boshrelease


text:
### PerforceConnector
=================

##### License

Copyright (c) Rally Software Development Corp. 2013
Distributed under the MIT License.

##### Warranty

Perforce Connector is available on an as-is basis. Rally Software does not provide any support for this connector.

##### Introduction

The Rally Connector for Perforce inspects the contents of a check-in comment and creates a changeset in Rally associated to the Rally artifact, creates changes for each affected file, and optionally updates the state of the Rally artifact. For example, if a developer checks in two files with the commit message "Fixed DE17", the Perforce Connector would create a changeset for the check-in revision, create two change objects for the affected files, link the changeset to the defect, and set the state of defect 17 as fixed.

The diagram below shows the objects that are created/modified when a check-in occurs with a Rally ID (such as US123, DE17, TA123) in the commit message. No objects are created if the formatted ID in the change message is not found in Rally.

![alt text](https://prod.help.rallydev.com/sites/default/files/multimedia/SCMDiagram.png "SCM")

##### Features

The connector can link to and modify tasks, defects and user stories contained in Rally. To change the state of a Rally artifact enter the ID for the story followed by the state you wish to change in your commit message.
Example: "Extremely important fetching feature done. US123 Completed"

The connector makes the following changes to Rally:

1. Depending up the artifact type, the "status" field is changed to the new status specified in the check-in comment (note "Completed" in the above example). The "status" fields on the artifacts are:
 * Defect: The "State" field.
 * Story: The "ScheduleState" field.
 * Task: The "State" field.
2. Creates an SCMSystemRepository object if one does not exist in Rally based on the `<SCMRepositoryName>` value in the configuration file.
3. Creates a Changeset object in Rally associated to the artifact with message, revision, commit timestamp and URI populated. Note screenshot (click to enlarge):
artifact
![alt text](https://prod.help.rallydev.com/sites/default/files/multimedia/ArtifactWithChangeset.png "ArtifactWithChangeset")
4. Creates a Change object in Rally for each affected file associated to the changeset with action, filename path, base, extension and URI fields populated. Note screenshot:
changes
![alt text](https://prod.help.rallydev.com/sites/default/files/multimedia/Changes.png "Changes")

The connector automatically sets the ToDo value of a task to 0 if the commit message contains a task ID and a state of completed.

##### Software and hardware requirements

The following are the hardware and software requirements to install and run the Rally Connector for Perforce.

1. A Rally subscription.
2. Most build and changeset data will not show in Rally until a workspace administrator enables the build and changeset flag by editing the workspace.
3. Access to your Perforce server.
4. Ruby (version 1.9.2 or greater) and Ruby GEMs (libraries) installed.
5. The Ruby GEM "rally_api".
6. This connector has been tested on Perforce 2009.1 only.

##### Installation

###### Basic installation steps

1. Install Ruby (version 1.9.2 or greater) and the Rally Connector for Perforce code.
2. Setup the config.xml for Perforce.
3. Run the config_test.rb to validate the config file is setup correctly.
4. Setup p4torally.rb to be executed by the Perforce trigger.

(Optional) If your site uses a proxy server to access Rally, you will need to set the http_proxy environment variable. To accomplish this on Windows 7:

1. Click on Start, right-click on Computer, select Properties
2. Click on Advanced system settings
3. In the new "System Properties" window, click on Environment Variables...
4. A new window opens titled "Environment Variables", under "System variables", click on New...
5. In the window titled "New System Variables", enter http_proxy in the "Variable name:" field, and enter your proxy's full HTTP Url in the Variable value: field (should be something like http://www-cache:8000)
6. Click OK (3 times) to save and exit this process.

You may need to restart your system in order for the change to take effect.

Note on upgrade process: If you are using a pre-2.0 version of the connector and wish to upgrade to 2.0, backup your config.xml file and then follow the installation instructions outlined below. If you plan to use your old config.xml file once you extract the contents of the new zip, add an `<SCMRepositoryName>` element to your config.xml and set it to the name of the SCMRepository you wish to create in Rally. The `<SCMRepositoryName>` element is a required. Additionally, you will need to download the `rally_api` gem by typing the command "gem install rally_api" from the command line. Optionally, to map authors to Rally changesets, add a `<UserDomain>` element to your config.xml file and set it to the email domain for your company (something like mydomain.com).

##### Install Ruby and the Rally Connector to Perforce

1. Install the Ruby programming language (version 1.9.2 or greater). Make sure the user running your Perforce server is given access to the Ruby installation.
2. Install the 3 required Ruby GEMs: builder, rally_api and httpclient by entering the following from a command window (answer yes to any questions about installing required dependencies):
  * Command: gem install rally_api httpclient
3. If you are using a proxy, add -p http://proxyhost:portnumber to the command line.
4. Save the RallyConnectorForP4-x-x.zip file locally (on your machine) into the directory where you want to install the connector. Navigate to this install directory and extract the RallyConnectorForP4-x.x.zip file you just saved.

##### Setup the configuration file

Edit and save the config.xml file, entering the appropriate values between each begin and end tag.

1. Set `<RallyUserName>` to the Rally user's login name you want to use for the updates in Rally.
2. Set `<RallyPassword>` to the Rally user's password. The first time the connector runs, it will encode your password and re-write (update) the XML file for added security.
3. Set `<RallyBaseUrl>` to the URL you use to log into Rally. For most users, the expected URL is rally1.rallydev.com or trial.rallydev.com.
4. Set `<RallyWorkspaceName>` to the name of the Rally Workspace where you want to update artifacts.
5. Set `<SourceControlUrl>` the URL you use to reference the Perforce web UI. For most users, this URL is similar to perforce.company.com:8080. Defaults to "http://" for the prefix.
6. Set `<RallySCMRepositoryName>` to any name of your choosing for the Rally SCMRepository object. The first time the connector runs, the connector automatically creates a new Rally SCMRepository object with Name set to the user specified name.
7. Set `<UserDomain>` to your company domain name such as acme.com. This tag determines what Rally user is used to populate the author field when creating the changeset object.
8. Optional - Set `<CommitterUserLookupField>` to a field name on the User Object in Rally. This will tell the connector to look up the commit user's name via that User Object field in Rally and to link the changeset Author to a user in Rally. For example, committer is user123 and the Rally user is<EMAIL_ADDRESS>with MiddleName set to user123. Note: If no users are found and the UserDomain element is set, the lookup will also try that association.

If set, the connector will lookup the Rally user based on the map to the Perforce user name. For example<EMAIL_ADDRESS>username in Rally → myuser Perforce user name .

If not set, the connector will lookup the Rally user based on the Perforce user email. For example<EMAIL_ADDRESS>username in Rally →<EMAIL_ADDRESS>Perforce user email.

The `<Prefixes>` element is used to specify any custom prefixes you have specified for your artifacts:
 * `<Defect>` This element is used to specify the prefix you use for defect artifacts.
 * `<Story>` This element is used to specify the prefix you use for story artifacts.
 * `<Task>` This element is used to specify the prefix you use for task artifacts.

Example config.xml file:
```
<Config>
<EMAIL_ADDRESS>   <RallyPassword>MyPassword</RallyPassword>
   <RallyBaseUrl>rally1.rallydev.com</RallyBaseUrl>
   <RallyWorkspaceName>MyWorkspace</RallyWorkspaceName>
   <SourceControlUrl>localhost:8080</SourceControlUrl>
   <RallySCMRepositoryName>MyPerforceRepository</RallySCMRepositoryName>
   <UserDomain>domain.com</UserDomain>
   <CommitterUserLookupField>MiddleName</CommitterUserLookupField>
   <Prefixes>
      <-- This section is for specifying if you have configured
         Rally to use custom prefixes for the FormattedID's.
         NOTE: If your custom prefix ends with a number,
               this connector will not function properly.
     -->
      <Defect>DE</Defect>
      <Story>US</Story>
      <Task>TA</Task>
   </Prefixes>
   <Log>
      <FileName>Rally_Connector_Error.log</FileName>
      <Level>0</Level>
   </Log>
</Config>
```

After the first check-in comment which includes a Rally ID, the connector will rewrite the config.xml file to include the allowed state values for User Stories, Defects and Tasks. This will happen automatically as long as the connector script has write access to the file. This re-write will also add the `<CachedStates>` element to the file.

The `<CachedStates>` content in the config.xml file can remain untouched unless your Rally administrator modifies the allowed state values for User Stories and/or Defects. To force the next run of the connector to update the values stored in the config.xml file, modify it by deleting the text from the `<CachedStates>` tag to the closing tag `</CachedStates>`. The `<CachedStates>` content will be functionally equivalent to the following:
```
<CachedStates>
   <DefectStates>
      <!-- State field on the Defect artifact.-->
      <State>Pre-test</State>
      <State>Submitted</State>
      <State>Open</State>
      <State>Fixed</State>
      <State>Closed</State>
      <State>Post-test</State>
   </DefectStates>
   <HierarchicalRequirementStates>
      <!-- ScheduleState field on the User Story artifact.-->
      <State>Pre-story</State>
      <State>Defined</State>
      <State>In-Progress</State>
      <State>Completed</State>
      <State>Accepted</State>
      <State>Post-story</State>
   </HierarchicalRequirementStates>
   <TaskStates>
      <!-- State field on the Task artifact.-->
      <State>Defined</State>
      <State>In-Progress</State>
      <State>Completed</State>
   </TaskStates>
</CachedStates>
```

##### Test the configuration file

To test the config.xml file for completeness, issue this command: `ruby config_test.rb`

The above script will test the network settings and the connection information in your config.xml file. The output from the command should be:
1. Log file write Passed.
2. Rally Url Passed
3. Successfully connected to Rally
4. Rally Workspace found
5. Email Validation Passed

##### Setup Perforce trigger

The Perforce change-commit trigger is set up so the Rally connector process runs in the background for optimal performance. After the developer checks in code, the Rally connector immediately runs and updates the appropriate objects in Rally without the developer having to wait for the Rally web services requests to complete. Consequently, check the Rally log file for any errors.

###### Setting up the change-commit trigger on Unix:

The steps below assume all files are saved in the /opt/integrations directory. Your file paths may vary depending on your installation.

1. Create a shell script called RallyWrapper.sh that contains the command to run the p4torally.rb script. This command runs the process in the background and redirects standard error to the Rally_Connector_Error.log file. Ensure you specify the full path to Ruby and the p4torally.rb file.
 * Example:
 *   `#!/usr/bin/ruby`
 *   `cd /opt/integrations/P4ToRally/`
 *   `./p4torally.rb  $1  $2  >  ./Connector.log  2>&1`
2. Verify the RallyWrapper.sh file is executable by entering this command:
 * `chmod  u+x  RallyWrapper.sh`
3. Open the Perforce triggers file by typing "p4 triggers" and add the line below. Ensure you add at least one space to the beginning of the line so Perforce correctly interprets the trigger.
 * `rally  change-commit //...  "/opt/integrations/P4ToRally/RallyWrapper.sh  %changelist%  %user%"`
4. Save the p4 triggers file. The connector is now installed.

###### Setting up the change-commit trigger on Windows:

1. Create a VBScript (RunP4ToRally.vbs) which contains commands to run the connector in the background.
 * `Set WshShell = WScript.CreateObject("WScript.Shell")`
 * `set args = WScript.Arguments`
 * `WshShell.Run("ruby C:\P4ToRally\p4torally.rb" & " " & args(0) & " " & args(1))`
2. Create a batch file (RallyWrapper.bat) which contains commands to run the VBScript.
 * `C:\P4ToRally\RunP4ToRally.vbs  %1  %2`
3. From the start menu, select Run.
4. Enter p4 triggers into the text box.
5. On the bottom of the file that opens, add this line under the word Triggers:
 * `rally  change-commit  //depot/...  "C:\P4ToRally\RallyWrapper.bat  %changelist%  %user%"`
6. Save the p4 triggers file. The connector is now installed.

##### Tips

Why are changesets not displaying in Rally?
 * Verify your Workspace administrator has selected the Enable Build and Changeset option on the Edit Workspace configuration pop-up and verify there are no unexpected messages in the Rally_Connector_Error.log file. No errors are written to the console.

Debug output
 * You can change the level of logging from the connector by including the following information in your configuration file:

```
<Log>
    <FileName>Rally_Connector_Error.log</FileName>
    <Level>0</Level>
</Log>

```

Log level 0 will produce the maximum amount of output, with log level 5 producing the least. These levels are documented at http://corelib.rubyonrails.org/classes/Logger/Severity.html:
 * DEBUG   = 0
 * INFO    = 1
 * WARN    = 2
 * ERROR   = 3
 * FATAL   = 4
 * UNKNOWN = 5

###### Under the hood of the Perforce connector

Here are some notes about the internal workings of Rally's Perforce connector.

The PERFORCE source control system (SCM) allows developers to perform "checkins" of source modules (like most SCM's allow). These checkins can automatically issue "triggers", which are basically external user-written scripts invoked by Perforce.

Most of the internal workings of the connector is done via five files as outlined below. Typically all these files are installed into some working directory where the user will be managing the connector. This should not be in the Perforce install directory, but rather in a working directory of the user. Please note there are special considerations to take into account if the pathname to this directory contains spaces. See WARNING(s) below for an example.

####### The "Triggers:" file:
A temporary "Triggers:" file, with a name like t2566t86.tmp, maintained by Perforce, which will invoke the batch file RallyWrapper.bat (described next). This "Triggers:" file can be edited from an MS-DOS command window by entering the command: `p4 triggers`

The above command will open a notepad window to the TMP file named something like t2566t86.tmp and the last three lines should look something like this:
```
Triggers:
rally change-commit //
depot/... "C:\Docume~1\Administrator\JPKoleP4\RallyWrapper.bat %changelist% %user%"
```

WARNING: Note that we did not use the text string "Documents and Settings" in the path name above as the embedded spaces cause parsing issues. Instead we used the "DOS 8.3 filename format" (http://en.wikipedia.org/wiki/8.3_filename).

####### The "RallyWrapper.bat" file:

This BAT file is invoked by the Perforce system when the user performs a checkin (because it is called out in the "Triggers:" file mentioned in the previous step). It will invoke a Visual Basic Script named RunP4ToRally.vbs, with 2 arguments: the first is the commit ID and the second is the Rally user name. Typically this BAT files contains the following line:
`C:\Docume~1\Administrator\JPKoleP4\RunP4ToRally.vbs %1 %2`

WARNING: Note that we did not use the text string "Documents and Settings" in the path name above as the embedded spaces cause parsing issues. Instead we used the "DOS 8.3 filename format" (http://en.wikipedia.org/wiki/8.3_filename). As a method of debugging, we could just omit the VBS step and invoke the Ruby script (file 4 below) straight from this file (we only use VBS so the task will run in the background). For debugging, one could put this line in the file instead if it helps:
￼
`C:\Ruby19\bin\ruby.exe C:\Docume~1\Administrator\JPKoleP4\p4torally.rb %1 %2`

####### The "RunP4ToRally.vbs" file:

The VBS file which actually invokes Rally's Ruby script called p4torally.rb in the background (which is why we use the VBS system). This script (mentioned in the previous file) contains three lines as follows:
```
Set WshShell = WScript.CreateObject("WScript.Shell")
set args = WScript.Arguments
WshShell.Run("C:\Ruby19\bin\ruby.exe C:\Docume~1\Administrator\JPKoleP4\p4torally.rb" & " " & args(0) & " " & args(1))
```
Note: If you wish to place comments in this script, the VBS comment character is an apostrophe (as in: '). For example:
```
' This is a comment line
' This is also
```

####### The "p4torally.rb" file:

This is the Rally-to-Perforce connector code written in Ruby which communicates with Rally and creates changesets. This is basically the post-commit script invoked by RunP4ToRally.vbs mentioned in the previous file.

####### The "config.xml" file:

The XML configuration file which is read by the p4torally.rb Ruby code mentioned in the previous file. This file contains all the details needed to communicate with both the Perforce and Rally systems.

gha_license_id: NOASSERTION


text:
# pyminimum
A Test Case Minimization Framework

Usage:

./pyminimum progname testfile

Outputs a minimized version of testfile such that progname still fails (returns with nonzero exit code)

repository: jeffythedragonslayer/pyminimum

repo_name: jeffythedragonslayer/pyminimum


text:
# Abe import

> includes a partial

### structure

1. If the value of the attribute `file` doesn't start with `/`, the file is imported from 'partials' folder (/path/to/abe/project/**partials**)

```
partials
   |_ head.html
   |_ footer.html
   |_ etc...
```

Inside abe template

```html
{{abe type='import' file='head.html'}}
```

this will replace the **'{{abe type='import' file='head.html'}}'** with file content of head.html

2. If the value of the attribute `file` starts with `/`, the file is imported from the absolute path using the root path of your abe site directory (/myAbsoluteAbeSiteDiectory`/path/entered/in/file/attribute`)

```
my-folder-in-my-abe-site
   |_ head.html
   |_ footer.html
   |_ etc...
```

Inside abe template

```html
{{abe type='import' file='/my-folder-in-my-abe-site/head.html'}}
```

this will replace the **'{{abe type='import' file='/my-folder-in-my-abe-site/head.html'}}'** with file content of head.html

> if the key doesn't exist this will replace **'{{abe type='import' file='head.html'}}'** with nothing

> abe type="import" is not usable in a {{#each}} statement for technical reasons. But you can reproduce this behavior by using the array notation in an import. ie. {{abe type="import" file="myPartial/{{list[].id}}"}} This is particularly useful when you propose a contributor to select several partials in a list (with the {{#each}} notation + type="data). You can then display these selected partials with this array style notation.

repository: abecms/abecms

gha_language: JavaScript

repo_name: abecms/abecms


text:
---
title: Drake v0.30.0
date: 2021-05-17
released: 2021-05-17
---

# Announcements

* Drake now provides an Ubuntu APT site that publishes our numbered releases
  ([#15016][_#15016]). Refer to
  [APT Packages for Monthly Tagged Releases][_apt-packages] for instructions.

# Breaking changes since v0.29.0

* On Ubuntu systems, Drake now requires the AVX2 and FMA family of SIMD
  intrinsics, i.e., the Intel's "Broadwell" microarchitecture or newer
  ([#15013][_#15013]).

* Drake now enforces stricter validation of SDFormat input data, so bad files
  that previously parsed without complaint now generate errors. For example,
  the `<pose>` element now has additional syntax checking ([#14852][_#14852]).

* Several methods on drake::systems::Diagram that were erroneously public have
  been made private. The affected methods are DoCalcTimeDerivatives() and
  DoCalcImplicitTimeDerivativesResidual(). Correct code should call
  EvalTimeDerivatives(), CalcTimeDerivatives(), or
  CalcImplicitTimeDerivativesResidual() instead ([#15031][_#15031]).

* Within Drake's event support, the arguments of the rarely-used handle()
  methods of PublishEvent, DiscreteUpdateEvent, and UnrestrictedUpdateEvent
  have changed. All now require a reference to the owning system as the first
  argument ([#14969][_#14969], [#15032][_#15032]).

* Drake no longer supports SDFormat's `<include>` elements. In the future, this
  feature will be restored with revised semantics. If you encounter issues with
  `<include>` elements in the interim, please notify Eric Cousineau.

# Changes since v0.29.0

## Dynamical Systems

<!-- <relnotes for systems go here> -->

New features

* Support scalar conversion by template parameter ([#14986][_#14986])
* Add compatibility checks for System methods using SystemOutput ([#15007][_#15007])
* Establish AffineSystem feedthrough without symbolics ([#15037][_#15037])

Fixes

* Reduce heap usage during Simulator advance steps ([#14912][_#14912], [#14950][_#14950], [#14969][_#14969], [#15032][_#15032], [#15010][_#15010])
* Fix image_to_lcm_image_array uninitialized data ([#14984][_#14984])
* Do not declare state variables in AffineSystem if num_states==0 ([#15003][_#15003])
* Deprecate and rename System::ValidateChildOfContext() ([#14999][_#14999])

## Mathematical Program

<!-- <relnotes for solvers go here> -->

New features

* Enable CLP to solve QP ([#14894][_#14894])

Fixes

* Set the string option in GurobiSolver ([#14930][_#14930])
* Warn about the memory issue when solving a QP with CLP ([#14934][_#14934])
* Report error when snopt fails to set a solver parameter ([#14947][_#14947])

## Multibody Dynamics

<!-- <relnotes for geometry,multibody go here> -->

New features

* Add ComPositionConstraint ([#14918][_#14918])
* Add CentroidalMomentumConstraint ([#14925][_#14925])
* Add ComInPolyhedronConstraint ([#14946][_#14946])
* Add QuaternionEulerIntegrationConstraint ([#14960][_#14960])
* Add CalcTotalMass methods to MultibodyPlant ([#14957][_#14957])
* New hydroelastic contact model in progress ([#14904][_#14904], [#14904][_#14904], [#14943][_#14943], [#14951][_#14951], [#14952][_#14952], [#14995][_#14995], [#14998][_#14998], [#15000][_#15000], [#15012][_#15012])

Fixes

* Improve model directives diagnostic when file not found ([#14923][_#14923])
* Suppress PackageMap warning on different directory spellings ([#14939][_#14939])
* Use translational jacobian for position constraint ([#14945][_#14945])
* Don't warn when parsing meshes with mtl files ([#14974][_#14974])
* Fix constness of JointActuator's SetRotorInertia() and SetGearRatio() ([#14983][_#14983])
* Defer joint limits warning until it's relevant ([#15017][_#15017])

## Tutorials and examples

<!-- <relnotes for examples,tutorials go here> -->

* Add LCM cameras to mock simulation for manipulation_station ([#14982][_#14982])
* Add getter for geometry frame to quadrotor example ([#15046][_#15046])

## Miscellaneous features and fixes

<!-- <relnotes for common,math,lcm,lcmtypes,manipulation,perception go here> -->

* New method for forming a rotation matrix from a single unit vector ([#14816][_#14816], [#15015][_#15015])
* Add AVX infrastructure and one AVX method ([#15013][_#15013])

## pydrake bindings

<!-- <relnotes for bindings go here> -->

New features

* Add autodiff_equal_to ([#14937][_#14937])
* Add \_\_repr\_\_ to several classes ([#14959][_#14959], [#14993][_#14993])
* Enable numpy math functions to work with symbolic variables ([#15039][_#15039])

Fixes

* Fix frames_to_draw visualization in Meshcat ([#14979][_#14979])

Newly bound

* pydrake.multibody.plant.MultibodyPlant.get_force_element ([#14953][_#14953])
* pydrake.manipulation.kuka_iiwa ([#14987][_#14987])

## Build system

<!-- <relnotes for cmake,doc,setup,third_party,tools go here> -->

* Do not pass --upgrade to pip3.9 on macOS ([#14962][_#14962])
* drake_visualizer: Use Drake's native lcmtypes for builtin_scripts ([#14981][_#14981])

## Build dependencies

* Upgrade buildifier to latest release 4.0.1 ([#14964][_#14964])
* Upgrade googlebenchmark to latest release ([#14965][_#14965])
* Upgrade lcm to latest commit ([#15023][_#15023])
* Upgrade libsdformat to latest release 11.0.0 ([#14852][_#14852])
* Upgrade rules_python to latest release 0.2.0 ([#14966][_#14966])
* Upgrade scs to latest release 2.1.3 ([#14970][_#14970])
* Upgrade tinyobjloader to latest commit ([#14958][_#14958])
* Upgrade voxelized_geometry_tools to latest commit ([#14919][_#14919])

## Newly-deprecated APIs

* drake::systems::sensors::InvalidDepth ([#15027][_#15027])
* drake::systems::sensors::Label ([#15027][_#15027])
* drake::systems::System::ValidateChildOfContext() ([#14999][_#14999])

## Removal of deprecated items

* drake::manipulation::PiecewiseCubicTrajectory ([#14989][_#14989])
* drake::manipulation::PiecewiseCartesianTrajectory ([#14989][_#14989])
* drake::multibody::MultibodyPlant::CalcCenterOfMassPosition ([#15050][_#15050])

# Notes

This release provides [pre-compiled binaries](https://github.com/RobotLocomotion/drake/releases/tag/v0.30.0) named
``drake-20210517-{bionic|focal|mac}.tar.gz``. See [Stable Releases](/from_binary.html#stable-releases) for instructions on how to use them.

Drake binary releases incorporate a pre-compiled version of [SNOPT](https://ccom.ucsd.edu/~optimizers/solvers/snopt/) as part of the
[Mathematical Program toolbox](https://drake.mit.edu/doxygen_cxx/group__solvers.html). Thanks to
Philip E. Gill and Elizabeth Wong for their kind support.

[_apt-packages]: https://drake.mit.edu/from_binary.html#apt-packages-for-monthly-tagged-releases
<!-- <begin issue links> -->
[_#14816]: https://github.com/RobotLocomotion/drake/pull/14816
[_#14852]: https://github.com/RobotLocomotion/drake/pull/14852
[_#14894]: https://github.com/RobotLocomotion/drake/pull/14894
[_#14904]: https://github.com/RobotLocomotion/drake/pull/14904
[_#14912]: https://github.com/RobotLocomotion/drake/pull/14912
[_#14918]: https://github.com/RobotLocomotion/drake/pull/14918
[_#14919]: https://github.com/RobotLocomotion/drake/pull/14919
[_#14923]: https://github.com/RobotLocomotion/drake/pull/14923
[_#14925]: https://github.com/RobotLocomotion/drake/pull/14925
[_#14930]: https://github.com/RobotLocomotion/drake/pull/14930
[_#14934]: https://github.com/RobotLocomotion/drake/pull/14934
[_#14937]: https://github.com/RobotLocomotion/drake/pull/14937
[_#14939]: https://github.com/RobotLocomotion/drake/pull/14939
[_#14943]: https://github.com/RobotLocomotion/drake/pull/14943
[_#14945]: https://github.com/RobotLocomotion/drake/pull/14945
[_#14946]: https://github.com/RobotLocomotion/drake/pull/14946
[_#14947]: https://github.com/RobotLocomotion/drake/pull/14947
[_#14950]: https://github.com/RobotLocomotion/drake/pull/14950
[_#14951]: https://github.com/RobotLocomotion/drake/pull/14951
[_#14952]: https://github.com/RobotLocomotion/drake/pull/14952
[_#14953]: https://github.com/RobotLocomotion/drake/pull/14953
[_#14957]: https://github.com/RobotLocomotion/drake/pull/14957
[_#14958]: https://github.com/RobotLocomotion/drake/pull/14958
[_#14959]: https://github.com/RobotLocomotion/drake/pull/14959
[_#14960]: https://github.com/RobotLocomotion/drake/pull/14960
[_#14962]: https://github.com/RobotLocomotion/drake/pull/14962
[_#14964]: https://github.com/RobotLocomotion/drake/pull/14964
[_#14965]: https://github.com/RobotLocomotion/drake/pull/14965
[_#14966]: https://github.com/RobotLocomotion/drake/pull/14966
[_#14969]: https://github.com/RobotLocomotion/drake/pull/14969
[_#14970]: https://github.com/RobotLocomotion/drake/pull/14970
[_#14974]: https://github.com/RobotLocomotion/drake/pull/14974
[_#14979]: https://github.com/RobotLocomotion/drake/pull/14979
[_#14981]: https://github.com/RobotLocomotion/drake/pull/14981
[_#14982]: https://github.com/RobotLocomotion/drake/pull/14982
[_#14983]: https://github.com/RobotLocomotion/drake/pull/14983
[_#14984]: https://github.com/RobotLocomotion/drake/pull/14984
[_#14986]: https://github.com/RobotLocomotion/drake/pull/14986
[_#14987]: https://github.com/RobotLocomotion/drake/pull/14987
[_#14989]: https://github.com/RobotLocomotion/drake/pull/14989
[_#14993]: https://github.com/RobotLocomotion/drake/pull/14993
[_#14995]: https://github.com/RobotLocomotion/drake/pull/14995
[_#14998]: https://github.com/RobotLocomotion/drake/pull/14998
[_#14999]: https://github.com/RobotLocomotion/drake/pull/14999
[_#15000]: https://github.com/RobotLocomotion/drake/pull/15000
[_#15003]: https://github.com/RobotLocomotion/drake/pull/15003
[_#15007]: https://github.com/RobotLocomotion/drake/pull/15007
[_#15010]: https://github.com/RobotLocomotion/drake/pull/15010
[_#15012]: https://github.com/RobotLocomotion/drake/pull/15012
[_#15013]: https://github.com/RobotLocomotion/drake/pull/15013
[_#15015]: https://github.com/RobotLocomotion/drake/pull/15015
[_#15016]: https://github.com/RobotLocomotion/drake/pull/15016
[_#15017]: https://github.com/RobotLocomotion/drake/pull/15017
[_#15023]: https://github.com/RobotLocomotion/drake/pull/15023
[_#15027]: https://github.com/RobotLocomotion/drake/pull/15027
[_#15031]: https://github.com/RobotLocomotion/drake/pull/15031
[_#15032]: https://github.com/RobotLocomotion/drake/pull/15032
[_#15037]: https://github.com/RobotLocomotion/drake/pull/15037
[_#15039]: https://github.com/RobotLocomotion/drake/pull/15039
[_#15046]: https://github.com/RobotLocomotion/drake/pull/15046
[_#15050]: https://github.com/RobotLocomotion/drake/pull/15050
<!-- <end issue links> -->

<!--
  Current oldest_commit a939b72dfd547f7f2cfb145f400408e4e1423e46 (exclusive).
  Current newest_commit 3e86d88df36f1a7d34cb5663e5f404eb43ce4e42 (inclusive).
-->

repository: RobotLocomotion/drake

repo_name: RobotLocomotion/drake


text:
# RemoteObserving

These scripts are to be used by remote sites and by individual observers to connect to W. M. Keck Observatory for remote observing. Before embarking on setting up a Keck Remote Observing station, we recommend reading the offical remote observing policy and documentation at: [https://www2.keck.hawaii.edu/inst/mainland_observing/](https://www2.keck.hawaii.edu/inst/mainland_observing/)

# Table of Contents

- Requirements for Remote Observing at Keck
    - 1 - Have an approved remote observing request
    - 2 - Be listed as an observer
    - 3 - Upload your SSH key
- Hardware Recommendations
    - Displays
    - Computer Recommendations
- Software Installation
    - Install Software Dependencies
    - Install the Keck Remote Observing Software
    - Configure Keck Remote Observing Software
    - Test your Connection to Keck
- Running the Keck Remote Observing Software
    - Opening and Closing Individual VNC Sessions
    - Getting a List of VNC Sessions
    - Uploading a log file to Keck
- Troubleshooting Common Problems
    - Can not see entire VNC desktop / VNC desktop is small
    - Connection Quality Problems
    - No Sounds
- Upgrading the Software

# Requirements for Remote Observing at Keck

**IMPORTANT**: Last minute additions of observers to an observing night will not be possible.  Observers **must** complete the items below at least two days ahead of time.

## 1 - Have an approved remote observing request

You must have an approved remote observing request before you can observe remotely.  Please submit your request from your [Observer Login Page](https://www2.keck.hawaii.edu/inst/PILogin/login.php).

## 2 - Be listed as an observer

Each person wanting to connect **must** be listed in the [Keck Observing Schedule](https://www2.keck.hawaii.edu/observing/keckSchedule/keckSchedule.php?calType=classic&telnr=0&viewType=schedule) as an observer.

The schedule is filled based on your remote observing request, but this is a manual step and thus it must be done at least **two days in advance of your run**.

## 3 - Upload your SSH key

- Generate ssh public/private key pair **(do not set a passphrase)**
    ```
    cd ~/.ssh
    ssh-keygen -t rsa -b 4096
    ```

- Make sure that the resulting key is an RSA key.  The **private** key should have a first line which looks like `-----BEGIN RSA PRIVATE KEY-----` (it should not be an OPENSSH key).  If you do get an OPENSSH key (we've seen this on macOS and Ubuntu Linux), try generating the key with the `-m PEM` option: `ssh-keygen -t rsa -b 4096 -m PEM`

- Upload your **public** key file at your [Observer Login Page](https://www2.keck.hawaii.edu/inst/PILogin/login.php). Click on "Manage Your Remote Observing SSH Key" and follow the instructions.

- After you have uploaded the key, note the "API key".  This will be a long string of letters and numbers.  You will need this key to connect (see the section below titled "Configure Keck Remote Observing Software").

# Hardware Recommendations

## Displays

The primary hardware requirement for running Keck VNCs is screen space.  Previous incarnations of the remote observing system have used four (4) 1920x1200 monitors (~24 inch diagonal) and placed one VNC session per monitor.  An alternative setup would be to use a single, very large 4k monitor and place the four VNC sessions on that one monitor.  In order for the VNC sessions to be of reasonable physical size, the monitor would have to be 43-48 inches (we've found that even 43 inches may be a bit on the small size, see below).  The pixel pitch which we used which works well is 0.272 mm/pixel (or about 93 pixels per inch) for our four 24 inch monitor setup.

We have also tried a 43 inch 4k resolution TV screen (which works out to about 103 ppi), but it is less readable at that size.  The advantage of a single 4k monitor is that it is easy to have a second monitor beside it which is dedicated to the Zoom connection or to a web browser for documentation or displaying weather conditions.

## Computer Recommendations

A number of computer hardware configurations have been tested.  Various Intel based computers running linux, numerous Mac laptops and desktops (both Intel based and Apple silicon based), and even a Raspberry Pi 4.

This hardware configuration has been tested at Keck HQ and found to work well:  [Intel NUC](https://www.intel.com/content/www/us/en/products/boards-kits/nuc.html), CPU: Intel Core i7-7567U CPU @ 3.50Ghz (dual core), RAM: 16GB

# Software Installation

This software depends on a few outside software packages including [Anaconda Python](https://www.anaconda.com/distribution), a VNC Viewer Client (which can be one of several options), and a few command line tools.  **Our installation instructions below should only be taken as an example.**  When dealing with outside packages, users should follow the installation instructions for those packages.

In addition, users will need a basic understanding of command line interactions as individual customizations (e.g. shell choice), differences between operating system versions, and differences in available command line tools may make the details of these examples inaccurate in some cases.

## Install Software Dependencies

The software has been tested on CentOS/RedHat 7.6, Ubuntu, Raspbian, and macOS.  This software will **not** work under Microsoft Windows as distributed here.

Note: The examples below assume sudo/root installation for all users and were originally written for Linux (CentOS).  Modify as appropriate for your local OS.

- Install Anaconda python3
    - Download and run the latest [anaconda installer](https://www.anaconda.com/distribution/)
    - Add python3 to user path (example below for `~/.bashrc` with typical python install path):
    ```
    export PATH=/usr/local/anaconda3-7/bin:$PATH
    ```
    - Other python distributions should work (using python 3.7+), but the user may have to manually install the python dependencies described in the `environment.yaml` file in addition to other python packages included with anaconda.
- Install VNC viewer client
    - **For Linux**
        - TigerVNC is recommended as the VNC client.  RealVNC has been tested as well.
            ```
            sudo yum install tigervnc-x86_64
            ```
            or
            ```
            sudo apt-get install tigervnc-viewer
            ```

        - In order for sounds to work, you will need a local sound player.  The
          `aplay` tool is installed by default on many linux distributions, but
          if yours does not have it, it is part of the
          [ALSA](https://alsa.opensrc.org/Aplay) package (often part of
          `alsa-utils` or a similar package in your package manager).
        - (optional) Install wmctrl (Used for auto-positioning VNC windows)
            ```
            sudo yum install epel-release
            sudo yum install wmctrl
            ```
    - **For macOS**: Install a VNC viewer application if needed.
        - [Tiger VNC](https://tigervnc.org) has the advantage of supporting automatic window positioning, but does not support scaling, and can not enter and exit view only mode interactively.
        - Real VNC's [VNC Viewer](https://www.realvnc.com/en/connect/download/viewer/) does not support automatic window positioning, but allows window scaling for use on small or high resolution monitors.  In addition, it supports changing modes both interactively and on the command line (e.g. scaling and the toggling of view only mode).  Note: this is the free software, you do not need VNC Viewer Plus.
        - It is also possible to use the built in VNC viewer on macOS, but we have seen a few instances where the screen freezes and the client needs to be closed and reopened to get an up to date screen.

**--> Important! <--** If you are using TigerVNC on either OS, in the `~/.vnc` directory, create a file named `default.tigervnc` with these two lines:
```
TigerVNC Configuration file Version 1.0
RemoteResize=0
```

## Install the Keck Remote Observing Software

(NOTE: Examples below assuming a user named 'observer' and installing to home directory)

- Download or clone this project from github:
    ```
    cd
    git clone https://github.com/KeckObservatory/RemoteObserving
    cd ~/RemoteObserving
    ```

- Create configuration file: copy `keck_vnc_config.yaml` to `local_config.yaml`.
    ```
    cp keck_vnc_config.yaml local_config.yaml
    ```

- Create a KRO [conda environment](https://docs.conda.io/projects/conda/en/latest/user-guide/concepts/environments.html) using the provided environment.yaml file:
    ```
    cd ~/RemoteObserving
    conda env create -f environment.yaml
    ```

- (optional) Add VNC start script to path:
    ```
    export PATH=/home/observer/RemoteObserving:$PATH
    ```

## Configure Keck Remote Observing Software

Edit the `local_config.yaml` file you created above.  Read the comments in the configuration file itself as they can guide you.  You may need to uncomment (remove the leading `#`) lines you want to customize.

- **Configure API Key:** If you are connecting outside of the Keck network, enter your uniquely generated "API Key".  This is generated when you upload your SSH public key (see "Upload your SSH key" above).  Visit your [Observer Login Page](https://www2.keck.hawaii.edu/inst/PILogin/login.php) and click on "Manage Your Remote Observing SSH Key".

- **Configure Path to Private SSH Key:** Enter the path to the **private** key corresponding to the public key that you emailed to Keck in the appropriate field.  For example:

    ```
    ssh_pkey: '~/.ssh/id_rsa'
    ```

- **Configure Local VNC Viewer Software:** This is where one sets `vncviewer` with the path and executable for the local VNC viewer client.  The value for this field needs to be to the **executable** not the "app" on macOS.    Note that in a terminal, you will need to escape the spaces in the path with `\` while the value in the local config field can handle spaces, so it should **not** have those escape characters.
    - Some VNC viewers (such as the built in macOS one) may need a prefix such as `vnc://` which can be set via the `vncprefix` value.
    - Options which should be passed to the vncviewer application are set in the `vncargs` value.
- **Important:** Make sure you have configured your VNC viewer **not** to resize the sessions (see the note about TigerVNC above).
- **Soundplay Configuration:** Uncomment the `soundplayer` line to specify which compiled executable for soundplay to use.  Other operating systems sometimes need other soundplay versions, contact [remote-observing<EMAIL_ADDRESS>for help configuring this value if needed.  Also, if your local machine's path to the `aplay` executable is non-standard, specify that in the `aplay` value.
    - At the moment, the default Linux executable seems to work for CentOS and Ubuntu Linux.
    - For macOS, use the settings as described in the `keck_vnc_config.yaml` section which specify a specific soundplay executable and a specific aplay calling format:
        ```
        soundplayer: 'soundplay.darwin.x86_64'
        aplay: '/usr/bin/afplay -v %v %s'
        ```
        As described in the comments in that file, replace `%v` with a value from 0 to 100 if you want to override the volume control in eventsounds.  Many users find the macOS sounds too loud, so replacing `%v` with a value less than 1 can help.
    - If your system is not compatible, or if you do not want it to have sounds, add a line to your `local_config.yaml` file which contains `nosound: True` to avoid starting sounds.  This is important for sites which are using multiple computers for each set of VNC sessions.  Choose one to handle sounds, and set the `nosound: True,` option for the other.

- **Configure Default Sessions:** Keck instruments typically use 4 VNC sessions for instrument control named "control0", "control1", "control2", and "telstatus".  On a normal invocation of the software (via the `start_keck_viewers` command) it will open the four sessions specified here.  For stations which split the duties among 2 computers, one could set this line to control which computer opens which sessions.

## Test your Connection to Keck

Only after your SSH key is successfully installed at Keck, you can test your system.  You can see the status of your SSH Key approval and deployment by clicking "Manage Your Remote Observing SSH Key" on your [Observer Login Page](https://www2.keck.hawaii.edu/inst/PILogin/login.php).

**--> Important! <--** SSH Keys are deployed on a time window based on your scheduled observing dates.  This window is roughly several days before and a few days after observing.  Check your Keck SSH Key Management page for exact deployment times.  If you need to connect outside this window, contact your SA.

From the directory where the Keck VNC software is installed (e.g. `~/RemoteObserving/`), run:

```
./start_keck_viewers --test
```

This should print out a report which indicates that all tests passed. Make sure there are no test failures.

If there are test failures, email your logfile to [remote-observing@keck.hawaii.edu](mailto:remote-observing@keck.hawaii.edu).  Verbose debug information is logged to the `RemoteObserving/logs/` folder.  Log files are created based on the UTC date.

# Running the Keck Remote Observing Software

From the command line, cd into your install directory and run `start_keck_viewers` followed by the name of the instrument account assigned for your observing night (i.e. `nires1`, `mosfire2`).  Running the script without options will start 4 VNC sessions (control0, control1, control2, telstatus) and the soundplayer.

```
cd ~/RemoteObserving
./start_keck_viewers [instrument account]
```

**NOTE:** Be sure to exit the script by using the 'q' quit option or control-c to ensure all VNC processes, SSH tunnels, and authentication are terminated properly.

To get help on available command line options:
```
./start_keck_viewers --help
```

Unlike the previous incarnation of the Keck VNC launch script, this software is not actually a script, but an app.  After being run, the terminal in which you ran the `start_keck_viewers` command will have a prompt and a menu.  For example:

```
|--------------------------------------------------|
|          Keck Remote Observing (v1.2.4)          |
|                     MENU                         |
|--------------------------------------------------|
|  l               List sessions available         |
|  [session name]  Open VNC session by name        |
|  w               Position VNC windows            |
|  s               Soundplayer restart             |
|  u               Upload log to Keck              |
|  p               Play a local test sound         |
|  t               List local ports in use         |
|  c [port]        Close ssh tunnel on local port  |
|  v               Check if software is up to date |
|  q               Quit (or Control-C)             |
|--------------------------------------------------|
>
```

The user can type commands at the `>` prompt.  The most important is the `q` (quit) command which closes down the SSH tunnels and VNC viewer sessions and exits the app.

## Zoom Meeting Information

Information on the Zoom meeting for nighttime observing (Zoom link, meeting ID, password) will be printed to the terminal above the menu.

## Opening and Closing Individual VNC Sessions

The user can close individual VNC sessions, by simply closing the VNC viewer window for that session (using whatever UI scheme is used by their local OS).  To reopen a session, just type the name at the command prompt.  For example, if I close `control0`  session and later I want it back, I just type `control0`  in the app command line.

## Getting a List of VNC Sessions

The `l` command lists the available VNC sessions.  For example:

```
> l
     INFO: Recieved command "l"
     INFO: Connecting to<EMAIL_ADDRESS>to get VNC sessions list

Sessions found for account 'mosfire3':
  control0     :19   mosfire-mosfire3-control0
  control1     :20   mosfire-mosfire3-control1
  control2     :21   mosfire-mosfire3-control2
  telstatus    :22   mosfire-mosfire3-telstatus
```

in this example, we see that there are the usual 4 VNC sessions for MOSFIRE.

## Uploading a log file to Keck

The `u` command will copy your local log file to a Keck computer.  This will only be useful if the software has established SSH connections to Keck, so it will not help in the case of catastrophic problems.  If you upload a log, you need to tell Keck Staff when you upload it and tell them which instrument you are logged in to and when you uploaded it.  These logs are not permanently stored and may be overwritten by other users, so if you want your log examined for issues, notify Keck Staff promptly.

# Troubleshooting Common Problems

Verbose debug information is logged to the `RemoteObserving/logs/` folder.  Log files are created based on the UTC date.

If you need assistance, please email [remote-observing<EMAIL_ADDRESS>and attach the most recent log file from the logs folder.

## Can not see entire VNC desktop / VNC desktop is small

If the user can not see the entire VNC desktop of the remote computer or if the VNC desktop is rendered small and hard to read, then try to look for sizing options on the local VNC viewer.  For some users, scaling the VNC screen to the window may be a good option to reveal areas they can not see at the cost of smaller UI element size.  For others, rendering the window very small may be worse than having to scroll around the desktop.  The local VNC viewer client will have options for controlling this behavior.  The best solution is to have a lot of local screen real estate (pixel count) and a lot of screen area (inches).  There is more detail is the [Keck Remote Observing Policy](https://www2.keck.hawaii.edu/realpublic/inst/mainland_observing/policy).

## Connection Quality Problems

If your connection quality is poor (bad color rendition, blurry (compressed) graphics, etc., play with the quality and color settings on the local VNC viewer client software.  There's a tradeoff between responsiveness and quality as you would imagine.  The default option set is `--FullColor`  (in your local config file), try with other settings.  There is also a quality adjustment option for most VNC viewers.

Another option would simply be to use fewer VNC sessions.  If you can get all your GUIs on to 3 sessions instead of 4, that helps.

A more extreme version would be to only keep one or two sessions open at a time and then open and close them as needded.  You can close a particular VNC session by closing that VNC viewer window and then reopen it from the app's command line.

## No Sounds

VNC does not carry sounds, so we have a separate system for playing instrument sounds such as "exposure complete" indicators on the remote machine.  This system has several moving parts, so troubleshooting can be challenging.  The vast majority of sound problems however are local to the users machine.  To play a test sound, type the `p` command.  This will play a local sound file (it will need to be downloaded on the first instance of this).  If you can't hear this test sound (the quality is poor and scratchy, but it sounds like a doorbell), then check your local machine's volume settings and speaker configuration.  You may also not have configured your local `aplay` instance properly.

# Upgrading the Software

The software does a simple check to see if it is the latest released version.  You can see a log line with this information on startup, or you can get the saem result using the `v` command.

Upgrading the software is done via a `git pull` in the directory where the software is installed.  If your software version is earlier than v1.0, this may require rebuilding your `local_config.yaml` file.  If you need to do this, just copy values from your old local config file in to a new one generated from the template as per the instructions above.

repository: KeckObservatory/RemoteObserving

gha_language: Python

repo_name: KeckObservatory/RemoteObserving


text:
# Assignment 3 for Business Intelligence
#### By Disturbed Unit
# Getting Started.
All files refered to are in the assignment-3 directory.

The osm file with all the address data in is huge, so we used osmconvert64 to trim some of the un_needed data.
This method was posted by one of the other members of class who was also finding that the process was stopping, due to memory leakage.
We install add the binaries to our Git/mingw64/bin directory, and run the following from the directory of the .osm file:

 osmconvert64 denmark-latest-osm --drop-ways --drop-relations > trimmed-denmark_latest.osm

This command writes a new file, but removes the <way> and <relation> elements, and the file is now approximately 1GB smaller.
We next used the XMLBreaker script from https://gist.github.com/nicwolff/b4da6ec84ba9c23c8e59 that slpits the file into more manageable chunks. After this we had no more crashes, and the data converted to csv format without incident!

 1. Read the entire dataset of Danish housing sales data, see Assignment 2, into a Pandas `DataFrame`. Use the `read_csv` function from the `pandas` module.

  * Geocode the the entire dataset of Danish housing sales data, see Assignment 2. Add two new columns to the `DataFrame`, one for latitude (`lat`) and one for longitude (`lon`) coordinates per address. Do the geocoding with help of the OSM dataset stored in a file as discussed in class. Save that `DataFrame` to a CSV file with the help of pandas

The code we used to then add the GeoData to the csv file we got can be found in the file addGeoCode.py. This part of the process follows the examples from the lecture_notes, with a few modifications.

If our data from the scraping exercise was formatted correctly, this code would take every node from the csv file created earlier, and extract the address:street, housenumber,postcode and city, and add these to a new csv file. At the same time, it should run the geolocate_dataframe method, and find any matches by these properties, and add the lat and lon geotags to the sales information. This doesn't happen. Our data is improperly formatted and so the method doesn't find the matches, leaving us with empty lat and lon columns.

At the time of writing, we are scraping the data again, but time has run out, again.

 * Convert all sales dates in the dataset into proper `datetime` objects.
```
import pandas as pd

#read csv file and parse column 3 to date format
df = pd.read_csv('boliga_all_3.csv', parse_dates = [3])

print('done')

# save new file with parsed date
df.to_csv("newFile.csv", index=False)

#check if data been parsed
f = pd.read_csv("newFile.csv")
f.head()
```

* Compute the average price per square meter for the years 1992 and 2016 respectively for the city centers of Copenhagen (zip code 1050-1049), Odense (zip code 5000), Aarhus (zip code 8000), and Aalborg (zip code 9000). Create two new `DataFrame`s, one for the year 1992 and one for the year 2016, which contain the respective zip codes and the average price per square meter corresponding to the aforementioned cities. Let the `DataFrame`s be sorted by ascending prices.

Using some of the example code from the lecture notes I started to experimient with trying to get the data needed to calulate the average prices per sq. metre. Again, the fact that we have not formatted the data properly makes this impossible.

But the averageprice.py file takes the csv as a dataframe, and then splits it into new frames based on post code. Then we can further reduce the dataframe by year, at which point we would get all the prices, convert them from string to float, and calulate the average prices for each dataframe. Once we get our data in order we should be able to complete this step.

* Create, with the help of the `pandas` module, four new CSV files containing the sales data for the year 1992 for the city centers of Copenhagen (zip code 1050-1049), Odense (zip code 5000), Aarhus (zip code 8000), and Aalborg (zip code 9000).
```
import pandas as pd
import re

#read csv file
df = pd.read_csv('newFile.csv')

# parse sell_date to date time format
df['sell_date'] = pd.to_datetime(df['sell_date'])

#fetch data by criteria
Aarhus_1992 = df[(df['zip_code'] == '8000 Aarhus C') & (df['sell_date'].dt.year == 1992)]
alborg_1992 = df[(df['zip_code'] == '9000 Aalborg') & (df['sell_date'].dt.year == 1992)]
Odense_1992 = df[(df['zip_code'] == '5000 Odense C') & (df['sell_date'].dt.year == 1992)]
København_K_1992 = df['zip_code'].str.contains('København K') & (df['sell_date'].dt.year == 1992)

# save new files with filtered data
Aarhus_1992.to_csv("Aarhus_1992.csv", index=False)
alborg_1992.to_csv("alborg_1992.csv", index=False)
Odense_1992.to_csv("Odense_1992.csv", index=False)
København_K_1992.to_csv("København_K_1992.csv", index=False)

print('done')
```
 * Use the following function, which computes the Haversine Distance (https://en.wikipedia.org/wiki/Haversine_formula) to compute an array of distances (`distances`) for each for each location in the dataset of Danish housing sales data to the city center of Roskilde (lat=55.65, lon=12.083333).

  ```python
  def haversine_distance(origin, destination):

      lat_orig, lon_orig = origin
      lat_dest, lon_dest = destination
      radius = 6371

      dlat = math.radians(lat_dest-lat_orig)
      dlon = math.radians(lon_dest-lon_orig)
      a = (math.sin(dlat / 2) * math.sin(dlat / 2) + math.cos(math.radians(lat_orig))
          * math.cos(math.radians(lat_dest)) * math.sin(dlon / 2) * math.sin(dlon / 2))
      c = 2 * math.atan2(math.sqrt(a), math.sqrt(1 - a))
      d = radius * c

      return d
  ```
  In the haversine.py file I have made an example of this using the coordinates in the lecture notes, so that we can see how it works.
  We will make the graph work..

repository: semester-groupies/disturbed-unit

gha_language: HTML

repo_name: semester-groupies/disturbed-unit


text:
---
Title: QH 300
nav_exclude: true
---

# "Now There Is": What We Think When We Think about Machine Thinking

##### John Laudun

## Vision & Objectives

What does it mean for so many of us to be caught up in a collection of files that pass from one machine to another and are processed into other kinds of files? Is the invisibility of it all--and invisibility that is effectively magic--to us? In this course we take up the question of artificial intelligence, but not in the embodied form of robots and droids--e.g., Robbie or R2D2--but in the form of faceless, disembodied entities like UNIVAC or Deep Blue.

## Requirements

### Assignments

**Paper**. The final paper in this class asks you to reflect on the methodological work we have done in terms of understanding texts and the topical considerations for the term -- in this case how we imagine "artificial intelligence." Your objective is to complete by the end of the semester an essay which takes up a text, or several texts, that we did not discuss in class and examine it for its representation of how intelligences, human and artificial, relate, reflect, refract a particular concern, anxiety, question or some other topic of your choosing. The paper must be grounded in textual evidence and that evidence must be presented in a contextualized fashion and a considered sequence such that your audience is "naturally" led from your initial proposition to agreement with your thinking on the matter.

## Schedule

### Primary Texts

Date | Text
---- | -------------
1909 | E. M. Forster, "The Machine Stops" [PDF][tms-pdf] / [txt][tms-txt] / [Wikisource][tms-wiki]
1946 | Murray Leinster, "A Logic Named Joe" [PDF][joe-pdf] / [txt][joe-txt]
1945 | Isaac Asimov, "Escape!"
1970 | Philip K. Dick, _A Maze of Death_
1970 | _Colossus: The Forbin Project_ (film) [(Wikipedia)][tfp-wp]
2016 | HBO's _Westworld_ (based on the [1973 film][] by Michael Crichton)
1966 | _Billion-Dollar Brain_ (book, film)
1983 | _WarGames_ (film) [(Wikipedia)][wg-wp]
1999 | _Smart House_ (Disney film)
2001 | _A.I. Artificial Intelligence_ (film) [(Wikipedia)][ai-wp]
2006 | Daniel Suarez, _Daemon_
2013 | _Her_ (film) [(Wikipedia)][her-wp]
-    | _The Machine_ (British film)
2014 | _Automata_ (film)

In addition to the texts above, the Wikipedia entry on [Artificial Intelligence in Fiction][wp-ai] is well worth your time.

[tms-pdf]: https://moodle.louisiana.edu/pluginfile.php/757817/mod_folder/content/0/forster_1909.pdf?forcedownload=1
[tms-txt]: https://moodle.louisiana.edu/pluginfile.php/757817/mod_folder/content/0/forster_1909.txt?forcedownload=1
[tms-wiki]: https://en.wikisource.org/wiki/The_Machine_Stops
[joe-pdf]: https://moodle.louisiana.edu/pluginfile.php/757817/mod_folder/content/0/leinster_1946.pdf?forcedownload=1
[joe-txt]: https://moodle.louisiana.edu/pluginfile.php/757817/mod_folder/content/0/leinster_1946.pdf?forcedownload=1
[1973 film]: https://en.wikipedia.org/wiki/Westworld
[tfp-wp]: https://en.wikipedia.org/wiki/Colossus:_The_Forbin_Project
[wg-wp]: https://en.wikipedia.org/wiki/WarGames
[ai-wp]: https://en.wikipedia.org/wiki/A.I._Artificial_Intelligence
[her-wp]: https://en.wikipedia.org/wiki/Her_(film)
[wp-ai]: https://en.wikipedia.org/wiki/Artificial_intelligence_in_fiction

### Considerations and Coverage

Franklin, H. Bruce. 1983. Don't Look Where We're Going: Visions of the Future in Science-Fiction Films, 1970-82 ("Ne cherche pas à savoir où on va": les Visions de l'avenir dans le cinéma de SF de 1970 à 1982). _Science Fiction Studies_ 10/1: 70-80. [JSTOR](http://www.jstor.org/stable/4239529).

Goldman, Steven L. 1989. Images of Technology in Popular Films: Discussion and Filmography. _Science, Technology, & Human Values_ 14/3: 275-301. [JSTOR](http://www.jstor.org/stable/689842).

* [AI will eliminate 6 percent of jobs in five years, says report][cnbc]. What are *cognitive services*?
* When do the [Laws of Robotics][] apply?
* [Tech Giants Team Up To Tackle The Ethics Of Artificial Intelligence][npr]
* The first [Colossus][].
* Computers inventing their own [language/code][].
* _The Verge_ has done a nice job over the years of keeping discussions about AI at a fairly high-level. In 2014, they offered  and then again in 2019 they offered "AN AI READING LIST — FROM PRACTICAL PRIMERS TO SCI-FI SHORT STORIES"][verge2019].
https://www.theverge.com/2019/1/29/18200585/understand-ai-artificial-intelligence-reading-list-books-scifi
* _Inverse_: [Inside the 'Westworld' Set's Luxury Dystopian Cowboy Disneyland "The main things people want to do in Westworld is they want to kill, eat, or have sex"](https://www.inverse.com/article/21830-design-of-westworld-s-old-western-town-set-hbo-melody-ranch)
* In a meta moment, there's [another course about the same topic][mla] as this one.

[cnbc]: http://www.cnbc.com/2016/09/12/ai-will-eliminate-six-percent-of-jobs-in-five-years-says-report.html
[Laws of Robotics]: https://www.kirkusreviews.com/features/isaac-asimov-and-three-laws-robotics/
[npr]: http://www.npr.org/sections/alltechconsidered/2016/09/28/495812849/tech-giants-team-up-to-tackle-the-ethics-of-artificial-intelligence
[Colossus]: https://www.miradore.com/a-short-history-of-modern-computers-and-the-it-workers-who-used-them/
[language/code]: https://www.engadget.com/2016/10/28/google-ai-created-its-own-form-of-encryption/
[mla]: https://www.mla.org/Resources/Career/MLA-Grants-and-Awards/Humanities-Innovation-Course-Development-Grants/Past-Winners

repository: johnlaudun/teaching

branch_name: refs/heads/main

repo_name: johnlaudun/teaching


text:
# Obsolete, no longer maintained！！！！

# React Native Modal Photo View

A modal image view support for react-native. This repository is fork from [halilb/react-native-photo-browser](https://github.com/halilb/react-native-photo-browser) library now and remove some functions and just left photo view.Then add and change some new functions.

The component has both iOS and Android support .

I haven't test it in IOS because i don,t have apple devices.

This repository may have a lot of issues in the beginning.

![](screenshots/screenshot.gif)

### Known issues
1、While image loading,the loading component position is not in the center of the screen.

2、Some times if image load error or failed, the error image and tip text didn't show.

3、Maybe you can't touch anywhere of the screen to close modal, but you can touch the close button of the image position to close modal

### Installation
```npm install react-native-modal-photo-view --save```

### Properties

| Prop | Type | Description | Default |
|---|---|---|---|
|**`style`**|Style|Overrides default container style.|`null`|
|**`mediaList`**|Array\<Media\>|List of [media objects](#media-object) to display.|`[]`|
|**`initialIndex`**|Number|Sets the visible photo initially.|`0`|
|**`displayCloseBtn`**|Boolean|Show close button to close modal.|`false`|
|**`displayBottomBar`**|Boolean|Whether to display the bottom text.|`true`|
|**`useCircleProgress`**_iOS_|Boolean|Displays Progress.Circle instead of default Progress.Bar for full screen photos. Check [Progress](#progress-component) section for more info.|`false`|
|**`onClose`**|Function|Function to control the modal visible or not.|`() => {}`|
|**`visible`**|Boolean|Modal visible or not.|`false`|
|**`onPhotoLongPress`**|Function|Called when a long press trigged on a photo.Plan to add in the future|`() => {}`|
|**`delayPhotoLongPress`**|Number|The long press delay in `ms`.Plan to add in the future|`1000`|
|**`imageErrorTitle`**|String|Text will show when image load error or failed.|`Load failed`|

### Media Object

```js
const media = {
  photo: '', // a remote photo or local media url
};
```

### Progress Component

#### Android

Built-in [ActivityIndicator](https://facebook.github.io/react-native/docs/activityindicator.html) component is used for Android. Any additional configuration is not needed.

#### iOS

[react-native-progress](https://github.com/oblador/react-native-progress) component is used as progress indicator. The default progress component is `Progress.Bar`. You can also use `Progress.Circle` component by simply using `useCircleProgress` prop, and adding `ReactART` library to your Xcode project. For more information please check out [react-native-progress repo](https://github.com/oblador/react-native-progress#reactart-based-components) and [React Native documentation](http://facebook.github.io/react-native/docs/linking-libraries-ios.html#content).

### Examples

Follow those steps to run the example:

1. Clone the repo `git clone https://github.com/guopeng1994/react-native-modal-photo-view && cd react-native-modal-photo-view/Example`
2. Install dependencies `npm install` or `yarn`
3. Follow [official instructions](https://facebook.github.io/react-native/docs/getting-started.html) to run the example project in a simulator or device.

### Roadmap
- [x] Android support
- [ ] Improve performance for bigger collections
- [x] Zooming photos to fill the screen

### Licence
[MIT](http://opensource.org/licenses/mit-license.html)


text:
---
layout: default
---

# 1996-09-17 - Searching an email address

## Header Data

From<EMAIL_ADDRESS>(Anonymous)

To<EMAIL_ADDRESS>Message Hash: 0f8fbf2f937f9bc2ac26be1b4b2b005453c271e1a50e8ea3e582b0ee88460a70

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1996-09-17 05:07:03 UTC

Raw Date: Tue, 17 Sep 1996 13:07:03 +0800

## Raw message

```
{% raw  %}From<EMAIL_ADDRESS>(Anonymous)
Date: Tue, 17 Sep 1996 13:07:03 +0800
To<EMAIL_ADDRESS>Subject: Searching an email address
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

  I have been trying to find out info re: someone
via his email address and didn't find anything.
The server is telaver.com, e.g<EMAIL_ADDRESS>   Any suggestions outside of the usual search
machines?

{% endraw %}
```

## Thread

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

+ Return to<EMAIL_ADDRESS>(Anonymous)](/authors/nobody_at_replay_com_anonymous_)"

+ 1996-09-17 (Tue, 17 Sep 1996 13:07:03 +0800) - Searching an email address -<EMAIL_ADDRESS>(Anonymous)_


text:
# Install xcbuddy

xcbuddy is distributed as a macOS application. A macOS application is a folder/bundle that contains the application binaries and other resources like third party frameworks, or assets. In case of xcbuddy, the application bundle contains:

* A macOS application.
* A command line tool.
* Third party frameworks.

xcbuddy releases on the [GitHub repository](https://github.com/xcbuddy/xcbuddy) contain a zip file with the application bundle. You could manually download it, and move the app into your `/Application` folder, however we recommend you to execute the following command on your terminal to install the tool:

```bash
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/xcbuddy/xcbuddy/master/scripts/install)"
```

It will download and run an installation script that performs all the necessary steps to get xcbuddy working on your local environment.

As part of the installation process, the script will create a symbolic link in `/usr/local/bin/xcbuddy` so that you can access the command line tool from anywhere.

You can check if the tool was installed properly by running `xcbuddy` in your terminal.

## Updating xcbuddy

xcbuddy uses [Sparkle](), a third party tool that auto-updates macOS applications. If you woudl like to update your version of xcbuddy you could do it by:

* Running `xcbuddy update`.
* Clicking `xcbuddy > Check for updates` from the status bar app.

In either way, xcbuddy will check if there's any new update and will guide you throw the update process. Optionall you can run the same installation script. I'll override your local version with the new version.

repository: cotsog/xcbuddy

gha_language: Swift

repo_name: cotsog/xcbuddy


text:
Forked from [mvertes/dokcer-alpine-mongo](https://github.com/mvertes/docker-alpine-mongo)

# docker-alpine-mongo

This repository contains Dockerfile for [MongoDB 3.2](https://www.mongodb.org)
container, based on the [Alpine 3.3](https://hub.docker.com/_/alpine/) image.

Why ? the official mongo image size: 317 MB, alpine-mongo: 133 MB

## Install

As a prerequisite, you need [Docker](https://docker.com) to be installed.

To download this image from the public docker hub:

	$ docker pull 3cola/alpine-mongo

To re-build this image from the dockerfile:

	$ docker build -t 3cola/alpine-mongo .

## Usage

To run `mongod`:

	$ docker run -d --name mongo_1 -p 27017:27017 3cola/alpine-mongo

Or do not expose port and use a link in the container that need a connection to the db...

You can also specify the database repository where to store the data
with the volume -v option:

	$ docker run -d --name mongo_1 -p 27017:27017 \
	  -v /somewhere/onmyhost/mydatabase:/data/db \
	  3cola/alpine-mongo

and with the authentication on (for production):

	$ docker run -d --name mongo_1 3cola/alpine-mongo --auth

to create the first admin user:

	$ docker exec -it mongo_1 mongo admin
	> db.createUser({ user: "admin", pwd: "myPassw0rd", roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] })

to create a user and its db:

	$ docker exec -it mongo_1 sh
	$ mongo -u "admin" -p "myPassw0rd" --authenticationDatabase "admin" myDb
	> db.createUser({ user: "myUser", pwd: "123Soleil", roles: [ { role: "dbOwner", db: "myDb" } ] })

Now, on the same host where the mongodb container is running, to trace
database network activity in real-time:

	$ docker exec -ti mongo_1 mongosniff

To run a shell session:

    $ docker exec -ti mongo_1 sh

To use the mongo shell client:

	$ docker exec -ti mongo_1 mongo

The mongo shell client can also be run its own container:

	$ docker run -ti --rm --name mongoshell-volatile 3cola/alpine-mongo mongo host:port/db

or with a link

	$ docker run -ti --rm --name mongoshell-volatile --link "mongo_1:db" 3cola/alpine-mongo mongo db/myDb

## Limitations

- On MacOSX, volumes located in a virtualbox shared folder are not
  supported, due to a limitation of virtualbox (default docker-machine
  driver) not supporting fsync().


text:
---
title: "Detecting malaria using a deep convolutional neural network"
collection: talks
type: "Talk"
permalink: /talks/2019-05-15-dfmd
venue: "University of Dhaka, Department of Computer Science and Engineering"
date: 2019-05-15
location: "Department of Computer Science and Engineering, Dhaka"
---

A talk on Detecting malaria using a Deep Residual Convolutional Neural Network. [Available here](https://www.slideshare.net/YusufBrima/detecting-malaria-using-a-deep-convolutional-neural-network)


text:
# chsutil

[![GoDoc reference example](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/silvanoneto/go-learning/pkg/chsutil)

chsutil package has facilities to call chapters functions.

chsutil supports the following functions until now:

- chapter01.HelloWorld
- chapter01.Echo1
- chapter01.Echo2
- chapter01.Echo3
- chapter01.Exercise01
- chapter01.Exercise02
- chapter01.Exercise03
- chapter01.Dup1
- chapter01.Dup2
- chapter01.Dup3
- chapter01.Exercise04
- chapter01.Lissajous
- chapter01.Exercise05
- chapter01.Exercise06
- chapter01.Fetch
- chapter01.Exercise07
- chapter01.Exercise08
- chapter01.Exercise09
- chapter01.FetchAll
- chapter01.Exercise10
- chapter01.Exercise11
- chapter01.Server1
- chapter01.Server2
- chapter01.Server3
- chapter01.Exercise12

You're opened to investigate how these functions works. ;)

repository: silvanoneto/go-learning

branch_name: refs/heads/develop

gha_language: Go

repo_name: silvanoneto/go-learning


text:
<!--Please select specific checklist(Quote/Language) according to PR and make sure to check the following boxes by putting x in the [ ] (Example: [x]). Remove the checklists that are NOT related to your PR. Thank you for your contribution-->

## ✅ New Quote Checklist
- [ ] The quote(s) added are in alphabetical order by author's first name and not ❌ duplicates.
- [ ] The quote(s) added are about **learning a foreign language**.
- [ ] The sentence attribute does not have inner quotation marks, and is ended with a period.
- [ ] Copy pasted the raw JSON `quotes.json` file to [JSONLint](https://jsonlint.com/) and made sure that the modified JSON file is valid.

## ✅ New Language Checklist
- [ ] There is ❌ no assigned issue or pull request for this new language.
- [ ] ➕ Added a new JSON object in the `server/data/languages.json` file.
- [ ] Added the **voice** 🎤 attribute supported by ResponsiveVoice API.
- [ ] Added the **flag** 🏳 attribute in the format of the twemoji-awesome CSS syntax.
- [ ] Added the **romanization** attribute for appropriate languages.
- [ ] ➕ Created the `{language.json}` file inside the `server/data/words` folder containing the list of the 3000 words.
- [ ] Removed duplicates and noted 🗒 them in the Pull Request.
- [ ] Increment `currentLanguagesCount` in `client/src/store/index.js`
- [ ] Add new language in `README.md`

repository: jayehernandez/letra-extension

gha_language: SCSS

repo_name: jayehernandez/letra-extension


text:
# different method for is node or browser

Goal: Run different actions if in node or in browser

1. Dynamic solution: The code includes a if/else statement
2. Static solution: A part of the code excuted is different

## solution 1: run the very same code in node and in the browser

The dynamic solution:

```javascript
// Don't 'use strict' or this becomes undefined
const isNode = function () { try { return this === global } catch (e) { return false } }
const isBrowser = function () { try { return this === window } catch (e) { return false } }
console.log(isNode(), isBrowser())
```

```bash
node src/solution1.js # run in node
chrome bundle/solution1.html # run in browser
```

## solution 2: replace the specific code for node with another specific code for the browser

The static solution:

```javascript
// ./node.js: I know I'm in node
const isNode = function () { return true }
const isBrowser = function () { return false }
console.log(isNode(), isBrowser())
```

```javascript
// ./browser.js: I know I'm in browser
const isNode = function () { return false }
const isBrowser = function () { return true }
console.log(isNode(), isBrowser())
```

This is achieved via a file replacement while creating the bundle for the browser

```javascript
// package.json
{
  "browser": { "./node.js": "./browser.js" }
}
```

### browserify

Browserify first replaces the file as defined in package.json > browser.

```bash
browserify src/solution2.js -o bundle/solution2-browserify.js
chrome bundle/solution2.html
```

### webpack

Webpack does the same replacement. Webpack needs a configuration file too.

```javascript
// webpack.config.js
const webpack = require('webpack')
module.exports = {
  entry: { main: './src/solution2.js' },
  output: { filename: './bundle/solution2-webpack-[name].js' },
  plugins: [ new webpack.optimize.CommonsChunkPlugin({ name: 'modules' }) ] // Save the webpack extra code in a separate file
}
```

```bash
webpack
chrome bundle/solution2.html
```

Webpack generates few more code than browerify.

Webpack is also much more configurable and flexible. See the other tuto [zero-to-webpack](../zero-to-webpack/README.md).

Note: `webpack -p` builds and uglifies the code for the browser in ES5 and thus requires `babel` to transform the ES5+ code.

## solution 3: test the very same code with different environment inputs for node or the browser

Test your code with jest and tell jest if the environment is node or browser.

```bash
jest solution3-node.test.js --env=node
jest solution3-browser.test.js --env=jsdom
```

jest mimics the browser environment with `--env=jsdom` which means the browser global `window` is available. However the node `global` is still available too.

## solution 4: mock the specific part for the testing in node or in browser environment

Before testing your code with jest, mock (replace) files or functions with another implementation.

```bash
jest solution4-node.test.js
jest solution4-browser.test.js
```

`solution4-node.test.js` calls and uses `src/lib/index.js`.

`solution4-browser.test.js` calls src/lib/index.js and **mocks** it to use `src/lib/__mocks__/index.js` instead.

```javascript
// solution4-browser.test.js
const { isNode, isBrowser } = require('./lib/index')
jest.mock('./lib/index')
// { isNode, isBrowser } are now taken from ./lib/__mocks__/index.js
```

## solution 5: test in a true browser environment

Thanks to a high-level browser automation library such as `PhantomJS` or `NightmareJS`.

[Nightmare](https://www.npmjs.com/package/nightmare) uses [Electron](https://electron.atom.io/), which is similar to [PhantomJS](http://phantomjs.org/) but roughly [2 times faster](https://github.com/segmentio/nightmare/issues/484#issuecomment-184519591) and more modern:

- Every method is a simple English command: goto, refresh, click, type... you can check out [Nightmare's full API here](https://github.com/segmentio/nightmare#api).
- It [lets you simplify deeply nested callbacks into a few sequential statements](http://www.nightmarejs.org/).

```bash
jest solution5-browser.test.js
```

As opposed to let jest mimic the browser environment with `--env=jsdom`, nightmare is a pure browser environment so `window` is available and `global` is not (which is correct).

Some nightmare examples:

```javascript
// cnn.js
const Nightmare = require('nightmare')
const nightmare = Nightmare()
nightmare
  .goto('http://cnn.com')
  .evaluate(() => { return document.title })
  .end()
  .then((title) => {
    console.log(title)
    done()
  })
```

```javascript
// cnn.test.js
/* global describe it */
const Nightmare = require('nightmare')
describe('test cnn title', () => {
  it('title should be "CNN ..."', (done) => {
    Nightmare()
      .goto('http://cnn.com')
      .evaluate(() => { return document.title })
      .end()
      .then((title) => {
        expect(title).to.equal('CNN - Breaking News, U.S., World, Weather, Entertainment & Video News')
        done()
      })
  })
})
```

See also [Acceptance Testing React Apps with Jest and Nightmare](https://www.viget.com/articles/acceptance-testing-react-apps-with-jest-and-nightmare).

## solution 6: debug node in chrome too

See [Debugging Node.js Apps](https://nodejs.org/en/docs/inspector/)

Debug a browser version in chrome is easy.

```bash
npm run sol1:start:browser # chrome bundle/solution1.html
```

Then F12 > Console > `console.log(isBrowser(),isNode())` returns `true false`.

Debug a node version in chrome is possible too.

Either run the script with `--inspect-brk`.

```bash
npm run sol1:debug:server # node --inspect-brk src/solution1.js
```

Or the script must be waiting for something so we are able to debug it before it exits.
Let's write a simple server application which listens to [http://localhost:7000/].

Then run it with `--inspect`.

```bash
npm run sol6:debug:server # node --inspect src/solution6-node.js
```

The console says the debugger is listening on something. Simply ignores this and steps forward.

* Open `chrome://inspect` in another browser tab > [possibly 'configure' then] inspect (the relevant target) > this opens a new chrome window with the chrome-devtools.
* Deploy the files listed under `(no domain)` and open the file `.../src/solution6-node.js`.
* Add a breakpoint within the function testIsNode()
* Then when you open [http://localhost:7000/] > The node script stops at the breakpoint in the chrome-devtools and the browser is now waiting for a response that does not come.

Then Console > `console.log(isBrowser(),isNode())` returns `false true`.

## summary

solution | isBrowser() | isNode()
--- | --- | ---
1- node in node | false | true
1- browser in chrome | true | false
2- harcoded node in node | false | true
2- harcoded replacement for browser in chrome | true | false
3- jest --env=node | false | true
3- jest --env=jsdom | true | ~~true~~
4- hardcoded node in jest | false | true
4- hardcoded mock for browser in jest | true | false
5- browser in nightmare | false | true
6- node in chrome-devtools | true | false

repository: ocroz/js-trials

repo_name: ocroz/js-trials