text:
express-local-auth
==================

[![Build Status](https://travis-ci.org/emertechie/express-local-auth.svg?branch=master)](https://travis-ci.org/emertechie/express-local-auth)

Express middleware that provides secure username/email and password authentication along with commonly needed supporting features such as user registration and password management.

# Install

```
npm install express-local-auth
```

# Overview

* Uses a secure, [slow](http://codahale.com/how-to-safely-store-a-password/) hashing algoritm - [bcrypt](https://github.com/ncb000gt/node.bcrypt.js)
* Locks out accounts after number of invalid login attempts
* Supports email verification via a callback
* Password reset only allowed after email verified
* Password reset tokens have an expiry
* Only stores a hashed version of password reset tokens (so if someone can read your DB through SQL injection for instance, they can't reset passwords using unhashed tokens)
* Recognises if someone attempts to reset a password for an unknown account and can email the account holder
* Requires original password before allowing a password change
* Not tied to any database or email provider - you implement simple service abstractions
* Logs extensively so if something fishy is going on, you have all the info you need
* Supports session-based and session-less operation
* Extensive unit-tests included

Features are implemented in a modular fashion and provided as simple route handlers for you to wire up as you see fit.

Uses the excellent [Passport](passportjs.org) library under the hood.

# Quick Example Usage

For full configuration sample, see [here](samples/server-side-views/index.js)

``` js

var express = require('express'),
    // ...
    localAuthFactory = require('express-local-auth');

// 1. Configure standard express app:
var app = express();
app.use(express.static(__dirname + '/public'));
// ...

// 2. Configure express-local-auth
var services = {
    emailService: myEmailService,
    userStore: myUserStore,
    passwordResetTokenStore: myPasswordResetTokenStore,
    verifyEmailTokenStore: myVerifyEmailTokenStore,
    logger: logger
};
var options = {
  failedLoginsBeforeLockout: 5,
  verifyEmail: true
};
var localAuth = localAuthFactory(app, services, options);

// 3. Define your app routes and use those provided by localAuth object where appropriate. See guide below

app.get('/login', function(req, res) {
    res.render('login');
});
app.post('/login', localAuth.login(), function(req, res) {
    res.redirect('/home');
});
app.get('/logout', localAuth.logout(), function(req, res) {
    res.redirect('/login');
});

app.get('/register', function(req, res) {
    res.render('register');
});
app.post('/register', localAuth.register(), function(req, res) {
    req.flash('successMsgs', 'Registered successfully');
    res.redirect('/home');
});

app.get('/changepassword', function(req, res) {
    res.render('change_password');
});
app.post('/changepassword', localAuth.changePassword(), function(req, res) {
    req.flash('successMsgs', 'Your password has been changed');
    res.redirect('/home');
});

// ... more route handlers

```

# Configuration

The object returned by `require('express-local-auth')` is a factory function expecting the following parameters:

``` js
var localAuth = localAuthFactory(expressApp, services, options);
```
* `expressApp` - a standard express app object, configured for sessions etc as appropriate. See [examples](#TODO) for more details.
* `services` - Services configuration object. See [below](#services).
* `options` - Options object. See [below](#options).

## Services

This middleware depends on some simple abstractions over external services. You are free to provide whatever implementations you like.

The `services` object passed into middleware factory should have the following properties:

* `emailService` - An object implementing the [Email Service](#email-service) API
* `userStore` - An object implementing the [User Store](#user-store) API
* `passwordResetTokenStore` - An object implementing the [Token Store](#token-store) API
* `verifyEmailTokenStore` - An object implementing the [Token Store](#token-store) API. Only required if the `verifyEmail` flag set to true in the `options`. **Note**: don't use the same instance as `passwordResetTokenStore` - use separate stores for each.
* `logger` - An object with a standard logger interface. For instance you can assign a [Winston](https://github.com/flatiron/winston) logger instance.
* `userIdGetter` - Optional function that takes a user object and returns the ID for that user. The system assumes that the [User Store](#user-store) service will set an `id` property when adding a user, so this function returns `user.id` by default.

## Options

```js
// The default options:
var options = _.defaults(options || {}, {
  loginPath: '/login',
  useSessions: true,
  autoSendErrors: false,
  normalizeCase: true,
  failedLoginsBeforeLockout: 10,
  accountLockedMs: 20 * minuteInMs,
  tokenExpirationMins: 60,
  verifyEmail: false
});
```

* `loginPath` - The path where the login route is hosted. Needed for redirecting back to login page when unauthenticated for instance. Defaults to `'/login'`
* `useSessions` - Whether to use sessions or not. If sessions are used (the default), it's expected that you have configured your app to use `express-session` etc. See samples for example usage. Also, errors are handled differently based on this setting. See [Error Handling](#error-handling) section.
* `autoSendErrors` - Only applies if not using sessions. If `true`, any provided middleware will automatically call `res.send(error)` on an error and end the request there - i.e. it will not call `next()` so any following middleware functions won't get invoked. If `false`, will set `res.locals['errors']` or `res.locals['validationErrors']` before calling `next()` to invoke any following middleware functions.
* `normalizeCase` - Whether to lowercase the user's email address when registering or when using it to verify credentials.
* `failedLoginsBeforeLockout` - Self-explanatory I hope. A successful login will always reset a user's failed login count
* `accountLockedMs` - How long to lock the account out for, in milliseconds, after `failedLoginsBeforeLockout` unsuccessful attempts
* `tokenExpirationMins` - How long a password reset token is valid for. Note: A verify email token never expires
* `verifyEmail` - Whether to expect users to verify their email addresses. If this is true, an `emailVerified` property will be added to user object which will only be set to true if user hits the verify email callback with correct token. Also, if this is true then user must verify email address before a password reset is allowed.

# Usage Modes

There are three potential ways to use this library which affects how any custom middleware following a library-provided middleware function is invoked (Also see [Error Handling](#error-handling) for more details)

```js
app.post('/login', localAuth.login(), function(req, res) {
    // If, and how, this function gets invoked depends
    // on how you configure the options. See below
});
```
### 1. In a web app using sessions
The default mode. If there's an error then library-provided middleware will:
* Set errors in flash (available via `req.flash('errors')` and `req.flash('validationErrors')`)
* Will do a redirect back to original path (See [Error Handling](#error-handling))

So following middleware will only get called if there were no errors.

### 2. In a web app not using sessions
If you set `options.useSessions = false`, if there's an error then library-provided middleware will:
* Set an appropriate `res.status_code`
* Assign errors to either `res.locals.errors` or `res.locals.validationErrors`
* Will *always* call `next()` to invoke following middleware

So following middleware will always get called and it's up to you to check `res.locals` for errors and render an appropriate response.

### 3. In an API
If you set `options.useSessions = false` and `options.autoSendErrors = true`, if there's an error then library-provided middleware will:
* Set an appropriate `res.status_code`
* Will automatically call `res.send(errors)`  to return the error response - i.e. it will *not* call `next()`

So following middleware will only get called if there were no errors.

In this mode you normally don't need custom middleware invoked on an error because you don't have views to render.

# Routes

**NOTE**: The examples below assume you are using sessions. If not,
see the [Error Handling](#error-handling) section below for how to handle errors correctly.

Details of individual routes below. Also, take a look at the working [sample](samples/server-side-views/index.js) provided.

## Login

|Operation              | Method | Suggested Path | Provided Middleware      |
|-----------------------|--------|----------------|--------------------------|
|Render login view      | GET    | /login         |                          |
|Perform login          | POST   | /login         | localAuth.login() |
|Perform logout         | POST   | /logout        | localAuth.logout()        |

### Render login view

Implement this as normal to render a login view with `email` and `password` input fields that get posted to the next route.

```js
app.get('/login', function(req, res) {
    res.render('login');
});
```

### Perform login

Call `localAuth.login()` middleware to perform the login before your own final middleware handler.

```js
app.post('/login', localAuth.login(), function(req, res) {
  res.redirect('/home');
});
```

### Perform logout

Call `localAuth.logout()` middleware to log the user out before your own final middleware handler.

```js
app.get('/logout', localAuth.logout(), function(req, res) {
    res.redirect('/login');
});
```

## User Registration

|Operation                   | Method | Suggested Path | Provided Middleware          |
|----------------------------|--------|----------------|------------------------------|
|Render registration view    | GET    | /register      |                              |
|Perform user registration   | POST   | /register      | localAuth.register()  |
|Verify email callback       | GET    | /verifyemail   | localAuth.verifyEmailView()  |
|Delete user                 | POST   | /unregister    | localAuth.unregister()       |

### Render registration view

Implement this as normal to render a registration view with `username` (optional), `email` and `password` fields that get posted to the next route.

If username not provided, it will default to `email`.

```js
app.get('/register', function(req, res) {
    res.render('register');
});
```

### Perform user registration

Call `localAuth.register()` middleware to register the user before your own final middleware handler.

```js
app.post('/register', localAuth.register(), function(req, res) {
    req.flash('successMsgs', 'Registered successfully');
    res.redirect('/home');
});
```

### Verify email callback

The route that will be invoked when user clicks on link in the registration email.
The provided handler will verify the supplied token and remove it from the [Token Store](#token-store) if successful.

The route handler will not do a redirect on error, so you must check the `res.statusCode` value to see if an error occurred:

```js
app.get('/verifyemail', localAuth.verifyEmailView(), function(req, res) {
    res.render('email_verification', { emailVerified: res.statusCode == 200 });
});
```

### Delete user

Call `localAuth.unregister()` middleware to delete the user before your own final middleware handler.

```js
app.post('/unregister', localAuth.unregister(), function(req, res) {
    req.flash('successMsgs', 'Successfully deleted user');
    res.redirect('/register');
});
```

## Change Password

|Operation                           | Method | Suggested Path  | Provided Middleware          |
|------------------------------------|--------|-----------------|------------------------------|
|Render change password view         | GET    | /changepassword |                              |
|Change password                     | POST   | /changePassword | localAuth.changePassword()   |

### Render change password view

Implement this as normal to render a view which posts `oldPassword`, `newPassword` and `confirmNewPassword` to the next route.

```js
app.get('/changepassword', function(req, res) {
    res.render('change_password');
});
```

### Change password

Call `localAuth.changePassword()` middleware to verify the old password and change user's password before invoking your own final middleware handler.

```js
app.post('/changepassword', localAuth.changePassword(), function(req, res) {
    req.flash('successMsgs', 'Your password has been changed');
    res.redirect('/home');
});
```

## Password reset

|Operation                           | Method | Suggested Path  | Provided Middleware          |
|------------------------------------|--------|-----------------|------------------------------|
|Render forgot password view         | GET    | /forgotpassword |                              |
|Start password reset process        | POST   | /forgotpassword | localAuth.forgotPassword()   |
|Render reset password callback view | GET    | /resetpassword  | localAuth.resetPasswordView()|
|Perform password reset              | POST   | /resetpassword  | localAuth.resetPassword()    |

### Render forgot password view

Implement this as normal to render a view with an `email` input field that gets posted to the next route.

```js
app.get('/forgotpassword', function(req, res) {
    res.render('forgot_password');
});
```

### Start password reset process

Call `localAuth.forgotPassword()` middleware to start the password reset process:

```js
app.post('/forgotpassword', localAuth.forgotPassword(), function(req, res) {
    res.render('password_reset_requested', { email: res.locals.email });
});
```

If a user is found with the posted email, the [Email Service](#email-service)
is used to send an email to the user with a link to the next /resetpassword route.

If no user found, the [Email Service](#email-service) can choose to notify the email address owner anyway
to make them aware of a possible hack attempt.

### Render reset password callback view

The route that gets invoked when a user clicks on link in a password reset email.
You should call the supplied `localAuth.resetPasswordView()` handler first to
verify the supplied token exists and is still valid.

After that, render a view which will POST `password` and `confirmPassword` fields
and hidden `email` and `token` fields to the next /resetpassword route.

```js
app.get('/resetpassword', localAuth.resetPasswordView(), function(req, res) {
    res.render('reset_password');
});
```

### Perform password reset

Call `localAuth.resetPassword()` middleware to reset the user's password before your own final middleware handler.

The supplied handler will:
- verify the password reset token exists and is still valid
- update the user with new password
- delete the token from the [Token Store](#token-store)
- use the [Email Service](#email-service) to notify user that password was reset

```js
app.post('/resetpassword', localAuth.resetPassword(), function(req, res) {
    req.flash('successMsgs', 'Your password has been reset');
    res.redirect('/login');
});
```

# Error Handling

This library is built to support session and session-less operation (see [options](#options.useSessions)).
How errors are handled is different depending on which mode you choose as detailed below.

### Using Sessions
If an error occurs during a route you are redirected via a GET back to the original path and the error will be added to the session flash (via [connect-flash](https://github.com/jaredhanson/connect-flash)).

For example, if you do a POST to `/login` and an error occurs, you'll be redirected via a GET to `/login` and the flash will be populated as follows:
* `req.flash('errors')` - will be an array of strings detailing any non-validation related errors.
* `req.flash('validationErrors')` - will be an array of validation error objects as returned by the `req.validationErrors()` function of the [express-validator](https://github.com/ctavan/express-validator) library

So when using sessions, unless otherwise noted, you don't need to do any explicit error handling in your own middleware handler after calling a `localAuth` handler as the `localAuth` handler will do a redirect on an error. E.g:

```js
app.post('/login', localAuth.login(), function(req, res) {

  // No explicit error-handling needed here

  res.redirect('/home');
});
```

But you will need to check for errors in the session flash and make them available for display in views:
```js
app.use(function(req, res, next) {
    // Transfer flash state, if present, to locals so views can access:
    res.locals.errors = (res.locals.errors || []).concat(req.flash('errors'));
    res.locals.validationErrors = (res.locals.validationErrors || []).concat(req.flash('validationErrors'));
    res.locals.successMsgs = (res.locals.successMsgs || []).concat(req.flash('successMsgs'));
    next();
});
```

### Not Using Sessions, Not Auto-Sending Errors
Options: `{ useSessions: false }`

If an error occurs during a route the following happens:
* `res.status(statusCode)` is called with an appropriate, non-200 status code
* `res.locals.errors` will be populated with any non-validation error strings. Same format as `req.flash('errors')` above.
* `res.locals.validationErrors` will be populated with any validation error object. Same format as `req.flash('validationErrors')` above.
* `next()` will be called to invoke the next middleware handler.

So to take the example above, you would need:

```js
app.post('/login', localAuth.login(), function(req, res) {

  // Need to check res.locals.errors and res.locals.validationErrors here

  res.redirect('/home');
});
```

### Not Using Sessions, Auto-Sending Errors
Options: `{ useSessions: false, autoSendErrors: true }`

If an error occurs during a route the following happens:
* `res.status(statusCode)` is called with an appropriate, non-200 status code
* `res.send(<error>)` is called, where `<error>` is either a validation or non-validation error as described above
* Note: `next()` is **not** called, so any following middleware is not invoked

```js
app.post('/login', localAuth.login(), function(req, res) {

  // This will only get invoked if no errors

  res.send(200, { success: much });
});
```

### Unexpected errors

If a node callback returns an error, this is immediately used to call `next(err)` so you will also need an overall error handler for your application as usual. For example:

```js
app.use(function(err, req, res, next) {
    logger.error(err);
    res.status(500).render('error');
});
```

# Per-route Configuration

Route handlers provided by this middleware will generally take an `options` object which can have the following properties:
* `shouldRedirect` - override whether this route will do a redirect on error or not
* `errorRedirect` - override where this route will redirect to on an error
* `autoSendErrors` - override the `options.autoSendErrors` value for this route

For example:

```js
app.post('/login', localAuth.login({ errorRedirect: false }), function(req, res) {

  // Handle errors yourself here by checking
  // res.locals.errors and res.locals.validationErrors
  // ...

  res.redirect('/home');
});
```

# Service APIs

## Email Service

See the [fake email service](samples/fakes/emailService.js) in the samples folder to get a quick idea of how to implement.

The expected API for this service is:

#### sendRegistrationEmail(user, verifyQueryString, callback)
* `user` - [user object](#user-object)
* `verifyQueryString` - the query string part of the URL (including leading '?' character) that user visits to verify email. For instance, if you host the callback route at `http://example.com/verifyemail`, then the link included in email should be `"http://example.com/verifyemail" + verifyQueryString`. This will be null if the `verifyEmail` [option](#options) is false.
* `callback(err)` - standard node callback when operation complete

#### sendForgotPasswordEmail(user, verifyQueryString, callback)
* `user` - [user object](#user-object)
* `verifyQueryString` - the query string part of the URL (including leading '?' character) that user visits to initiate password reset process. For instance, if you host the callback route at `http://example.com/resetpassword`, then the link included in email should be `"http://example.com/resetpassword" + verifyQueryString`
* `callback(err)` - standard node callback when operation complete

#### sendForgotPasswordNotificationForUnregisteredEmail(email, callback)
* `email` - the unregistered email address
* `callback(err)` - standard node callback when operation complete

Called if a user attempts to reset a password for an unknown email address. You are free to leave the implementation empty (well, invoke the `callback` at least) or you can send a nice email to that address saying someone tried to reset your password.

#### sendPasswordSuccessfullyResetEmail(user, callback)
* `user` - [user object](#user-object)
* `callback(err)` - standard node callback when operation complete

Invoked after user has followed the password reset process. Email user and let them know they can now log in with new password.

#### sendPasswordSuccessfullyChangedEmail(user, callback)
* `user` - [user object](#user-object)
* `callback(err)` - standard node callback when operation complete

Invoked after password changed via normal change password process. Email them a confirmation email.

## User Store

See the [fake User Store](tests/fakes/userStore) used in tests to get a quick idea of how to implement.

The expected API for this service is:

#### add(userDetails, callback)
* `userDetails` - A user object containing `username`, `email` and `hashedPassword`
* `callback(err, userAlreadyExists, user)` - The `userAlreadyExists` param should be set to `true` if this is a duplicate registration, false otherwise. The `user` param should be an object containing the same `userDetails` passed in **plus** an ID property. By default it's assumed the ID property is called `id`. If it's something else, provide a custom [services.userIdGetter](#services) function.

#### get(userId, callback)
* `userId` - The ID of the user as extracted by the [services.userIdGetter](#services) function.
* `callback(err, user)` - The `user` param should be a similarly shaped object to the one returned from the `add` function - i.e. it includes an ID property.

#### update(user, callback)
* `user` - The user object to update in the store.
* `callback(err, wasUpdated)` - The `wasUpdated` param should be set to true if user was updated successfully, false otherwise.

#### remove(userId, callback)
* `userId` - The ID of the user as extracted by the [services.userIdGetter](#services) function.
* `callback(err)` - call when operation completes

#### findByEmail(email, callback)
* `email` - The email to lookup
* `callback(err, user)` - The `user` param should be the user object if found, falsy otherwise. Note: don't set the `err` parameter just because user isn't found - they are two separate concerns.

## Token Store

The same Token Store service API is used for email verification tokens as well as password reset tokens.

See the [fake Token Store](tests/fakes/tokenStore) used in tests to get a quick idea of how to implement.

The expected API for this service is:

#### add(tokenDetails, callback)
* `tokenDetails` - object containing `email`, `userId` properties and for password reset tokens an `expiry` also.
* `callback(err)` - standard node callback when operation complete

### removeAllByEmail(email, callback)
* `email` - email address to remove tokens for
* `callback(err)` - standard node callback when operation complete

### findByEmail(email, callback)
* `email` - email address to find tokens for
* `callback(err)` - standard node callback when operation complete

# User object
Any `user` object mentioned in APIs will have `email` and `username` properties along with other properties that the `UserStore` might add such as an `id`.


text:
# Cloud providers and known service URLs for storage providers

Last updated 18/04/21.

Generally, buckets are accessed as such, where `baseurl` may or may not include the region:

```
example.baseurl.tld
baseurl.tld/example
```

Regions are of course subject to change, so it's best to assume the region is a wildcard in your regexes.

## Amazon (S3)

Cloudfront is not always for S3 buckets and supports subdomain only.

Source: https://docs.aws.amazon.com/general/latest/gr/rande.html

```
s3.amazonaws.com
s3.<region>.amazonaws.com
cloudfront.net
```

## Google Storage Buckets (modified S3, should be compatible)

Source: https://cloud.google.com/storage/docs/request-endpoints

```
storage.googleapis.com (S3 format)
www.googleapis.com/storage/v1/b/example/o/ (not S3 format)
```

## DigitalOcean Spaces (S3)

Supports aliasing.

Source: https://docs.digitalocean.com/products/spaces/

```
<region>.digitaloceanspaces.com
```

## Azure Blob Storage (S3)

Buckets can be accessed by subdomain only.

```
blob.core.windows.net
```

## Linode (S3)

Source: https://status.linode.com

```
<region>.linodeobjects.com
```

## Vultr (S3)

Source: Just trust me bro

```
<region>.vultrobjects.com
```

## Alibaba Cloud (OSS)

Haven't found a public listing for one of these yet.

Source: https://blog.anynines.com/concourse-configure-s3-resource-to-work-with-alibaba-cloud-oss/

```
oss-<region>.aliyuncs.com
```

## Backblaze (S3)

Source: https://docs.fastly.com/en/guides/backblaze-b2-cloud-storage

```
s3.<region>.backblazeb2.com
backblazeb2.com
```

## Wasabi (S3)

Source: https://wasabi-support.zendesk.com/hc/en-us/articles/360015106031-What-are-the-service-URLs-for-Wasabi-s-different-storage-regions-

```
s3.wasabisys.com
s3.<region>.wasabisys.com
```

## DreamHost (S3)

Supports aliasing.

Source: https://help.dreamhost.com/hc/en-us/articles/215253408-How-to-create-a-DNS-alias-for-DreamObjects-buckets

```
objects-<region>.dream.io
```

## Rackspace (maybe S3?)

Haven't found a public listing for one of these yet.

Source: https://docs.rackspace.com/docs/cloud-files/v1/general-api-info/service-access/

```
storage101.<region>.clouddrive.com
snet-storage101.<region>.clouddrive.com
```

## IBM Cloud Object Storage (S3)

Source: https://cloud.ibm.com/objectstorage/

```
s3.<region>.cloud-object-storage.appdomain.cloud
```

## Firebase Storage (custom protocol)

Source: https://firebase.google.com/docs/storage/web/download-files

```
firebasestorage.googleapis.com/v0/b/<name>.appspot.com/o/
```

repository: Zenofex/bucketbuster

branch_name: refs/heads/main

extension: md

license_type: permissive

repo_name: Zenofex/bucketbuster


text:
# Offline Data in Firestore

> Cloud Firestore supports offline data persistence. This feature caches a copy of the Cloud Firestore data that your app is actively using, so your app can access the data when the device is offline. You can write, read, listen to, and query the cached data. When the device comes back online, Cloud Firestore synchronizes any local changes made by your app to the data stored remotely in Cloud Firestore.

> **NOTE**: [AngularFire has a new tree-shakable API](../../../README.md#developer-guide), you're looking at the documentation for the compatability version of the library. [See the v7 upgrade guide for more information on this change.](../../version-7-upgrade.md).

**Offline persistence is an experimental feature that is supported only by the Chrome, Safari, and Firefox web browsers.** If a user opens multiple browser tabs that point to the same Cloud Firestore database, and offline persistence is enabled, Cloud Firestore will work correctly only in the first tab.

## Enable Offline Data in AngularFirestore

To enable offline persistence in your AngularFire application, call `enablePersistence()` when you are importing `AngularFirestoreModule` into your `@NgModule`:

```ts
import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { AppComponent } from './app.component';
import { AngularFireModule } from '@angular/fire/compat';
import { AngularFirestoreModule } from '@angular/fire/compat/firestore';
import { AngularFireAuthModule } from '@angular/fire/compat/auth';
import { environment } from '../environments/environment';

@NgModule({
  imports: [
    BrowserModule,
    AngularFireModule.initializeApp(environment.firebase),
    AngularFirestoreModule.enablePersistence(),
  ],
  declarations: [ AppComponent ],
  bootstrap: [ AppComponent ]
})
export class AppModule {}

```

While offline your listeners will receive listen events when the locally cached data changes. You can use to Documents and Collections normally.

To check whether you're receiving data from the server or the cache, use the `fromCache` property on the `SnapshotMetadata` in your snapshot event. If `fromCache` is true, the data came from the cache and might be stale or incomplete. If `fromCache` is false, the data is complete and current with the latest updates on the server.

[To learn more about Offline Persistence in Firestore, check out the Firebase documentation](https://firebase.google.com/docs/firestore/enable-offline).

repository: angular/angularfire

branch_name: refs/heads/master

gha_language: TypeScript

gha_license_id: MIT

repo_name: angular/angularfire


text:
---
layout: post
title: "-Ought words"
date: 2023-02-20 00:01:00 +0000
tags:
  etymology
  litclub
  old-shit
  today-i-learned
---

Have you ever noticed how so many English past tenses end with _-ought_ or _-aught_?

|----|----|
| bought | buy |
| brought | bring |
| caught | catch |
| distraught | distract |
| fought | fight |
| fraught | freight |
| might | may |
| sought | seek |
| taught | teach |
| thought | think |
| wrought | work, wreak |
{:.smaller}

(Consider also that something can be _stretched_ until it is _straight_, _tightened_ until it is _taut_.)

The other day I was reading [Thomas Edwards](https://en.wikipedia.org/wiki/Thomas_Edwards_(critic))'
[_The Canons of Criticism_](https://books.google.com/books?id=rqhVAAAAYAAJ&pg=PA111) (1758) — a mildly
entertaining but much too long attack on William Warburton's editions of Pope and Shakespeare —
and came across a new entry for my table. _Hamlet_, Act III, Scene I:

> ROSENCRANTZ:
> Madam, it so fell out, that certain players
> We o'er-raught on the way: of these we told him;
> And there did seem in him a kind of joy
> To hear of it [...]

Edwards describes _over-raught_ as (not a corruption of _over-rode_ but) "the regular past tense of _over-reach_."
Compare Spenser's [_Faerie Queene_](https://rpo.library.utoronto.ca/content/faerie-queene-book-i-canto-7-1596):

> A monstrous beast ybred in filthy fen
> He chose, which he had kept long time in darksome den [...]
> His tayle was stretched out in wondrous length,
> That to the house of heauenly gods it raught,
> And with extorted pow'r and borrow'd strength,
> The euer-burning lamps from thence it brought,
> And prowdly threw to ground, as things of nought.

Wiktionary further tells me that _raught_ or _rought_ can also be the past tense of _reck_
(as in _reckon_, _reckless_). _Reck_ and _reach_ derive from different Proto-Indo-European roots,
but have converged to be more or less synonymous with _grasp_ ([_pace_ Robert Browning](https://www.poetryfoundation.org/poems/43745/andrea-del-sarto)).

In writing this post, I learned that _hight_ (more or less synonymous with _yclept_) is the present perfect
of [_hote_](https://en.wiktionary.org/wiki/hote): "I am _hight_ Lancelot" only because people tend to _hote_ me Lancelot, you know.

And then there's this, from _Punchinello_ magazine [2:27](https://books.google.com/books?id=63otAQAAMAAJ&pg=RA1-PA11) (October 1870),
bylined "Amos Keeter" (get it?):

> Sally Salter, she was a young teacher, who taught,
> And her friend, Charley Church, was a preacher, who praught;
> Though his enemies called him a screecher, who scraught.
>
> His heart, when he saw her, kept sinking, and sunk,
> And his eye, meeting hers, began winking, and wunk;
> While she, in her turn, fell to thinking, and thunk.
>
> He hastened to woo her, and sweetly he wooed,
> For his love grew until to a mountain it grewed,
> And what he was longing to do, then he doed.
>
> In secret he wanted to speak, and he spoke,
> To seek with his lips what his heart long had soke;
> So he managed to let the truth leak, and it loke.
>
> He asked her to ride to the church, and they rode;
> They so sweetly did glide, that they both thought they glode,
> And they came to the place to be tied, and were tode.
>
> Then homeward he said let us drive, and they drove,
> And soon as they wished to arrive, they arrove;
> For whatever he couldn't contrive, she controve.
>
> The kiss he was dying to steal, then he stole,
> At the feet where he wanted to kneel, there he knole,
> And he said, "I feel better than ever I fole."
>
> So they to each other kept clinging, and clung,
> While Time his swift circuit was winging, and wung;
> And this was the thing he was bringing, and brung:
>
> The man Sally wanted to catch, and had caught—
> That she wanted from others to snatch, and had snaught—
> Was the one that she now liked to scratch; and she scraught.
>
> And Charley's warm love began freezing, and froze,
> While he took to teasing, and cruëlly toze
> The girl he had wished to be squeezing, and squoze.
>
> "Wretch!" he cried when she threatened to leave him, and left,
> "How could you deceive me, as you have deceft?"
> And she answered, "I promised to [cleave](https://en.wikipedia.org/wiki/Auto-antonym) — and I've cleft!"

license: MIT

repository: Quuxplusone/blog

gha_language: HTML

repo_name: Quuxplusone/blog


text:
# Create a new DevTestLab instance

This template creates a new DevTestLab instance.

When deploying via PowerShell, if you use -DeploymentMode parameter, it is recommended to use the "Incremental" option. The "Complete" option will delete the target resource group first. If a lab or other resources are in that resource group, you could lose them or encounter errors.

repository: Scapenighter/Azure-Test-Lab

gha_language: PowerShell

repo_name: Scapenighter/Azure-Test-Lab


text:
# Changelog

Breaking changes in **bold**.

#### v0.5.2 – Jan 2019

* API: Make `Val` a `StrictSignal` (it already behaved like one)

#### v0.5.1 – Dec 2018

* API: Make `FutureSignal` a `StrictSignal` (it already behaved like one)

#### v0.5 – Dec 2018

* **API: Eliminate the whole concept of State [#13](https://github.com/raquo/Airstream/pull/13)**
  * `State` and `StateVar` are no more. RIP
  * Merge `MemoryObservable` into `Signal`
  * Merge `LazyObservable` into `Observable`
  * Remove `toLazy` method as all observables are now lazy
  * **Migration guide**
    * Use `Signal` instead of `State` and `MemoryObservable`. This is NOT a drop in replacement as State was not lazy. Make sure you have observers (internal or external) on all Signals that would be replacing State, or else they won't run. Consult the updated documentation for a reminder on Signal semantics.
    * For `Signal` alternatives to `State`'s `now()` / `tryNow()` methods, see the _Getting Signal's current value_ section in the new docs.
    * Use `Observable` instead of `LazyObservable`.
    * Use `Var` instead of `StateVar`.
    * Use `toSignal` instead of `toState`.
    * Remove invocations of `toLazy` method, they are not needed anymore.
* **API: Make Var and its signal strict (not lazy)**
  * Var does not provide a WriteBus anymore, only an Observer
  * Var now exposes `now` and `tryNow` methods, as does its signal
  * See Var docs for details
* **API: Make SignalViewer a Signal itself**
  * A StrictSignal, to be precise
* **API: Remove flatMap method**
  * Use map(...).flatten
  * I don't have time to sort out type inference and other stuff needed to get `flatMap` to work nicely.
* New: Update Vars using (currentValue => nextValue) functions
  * New methods on Var instances: `set`, `setTry`, `update`, `tryUpdate`
* New: Batch update Vars in a single transaction
  * Companion object methods: `Var.set`, `Var.setTry`, `Var.update`, `Var.tryUpdate`
  * See new Var docs for details

#### v0.4.1 – Dec 2018

* Fix: NPE from errors unhandled by `recover` partial function

#### v0.4 – Nov 2018

* **New: Error Handling – see whole new section in docs**
* **API: a few breaking changes for those who extend Airstream classes**
  * A bunch of class / trait member fields are now `Try[A]` instead of `A`
  * Split `fire` into `fireValue` & `fireError`, etc.
  * By and large this does not affect existing Airstream usage, just customization by subclassing
* **API: `Observable.removeObserver` and `Transaction.removeExternalObserver` are now private ([#10](https://github.com/raquo/Airstream/issues/10))**
* **Build: Drop Scala 2.11 support**
* New: `SignalViewer`
  * This serves as a warning about my intention to deprecate and eventually remove the entirety of the `State` type in Airstream. Its strictness has not proved useful, and yet has plenty of drawbacks. See [Laminar#37](https://github.com/raquo/Laminar/issues/37) for details. If you want to speak up against that, now is the time.
* New: `Ref` performance util (experimental)

#### v0.3 – Sep 2018

* **Naming: Observer.map -> Observer.contramap**
* **Naming: WriteBus.mapWriter -> WriteBus.contramapWriter**
* **API: `EventStream.mapTo` now accepts `value` by name; previous behaviour available using `mapToValue` method**
* **API: `Observable.flatten` now needs a `FlattenStrategy` except for `SwitchEventStream` which is provided implicitly as a default**
* New: Integration with Futures. `EventStream.fromFuture`, `Signal.fromFuture`, `State.fromFuture`, `SwitchFutureStrategy`, `ConcurrentFutureStrategy`, `OverwriteFutureStrategy`
* New: `LazyObservable.flatMap` (available via implicits)
* New: `LazyObservable.map` returns a more specific type

#### v0.2 – Apr 2018

* **API: Signal only fires if `nextValue != prevValue`**
* **Naming: Var -> StateVar**
* New: Make `Val.now()` public
* New: signal.Var
* Fix: Ensure Signal's initialValue has been evaluated onStart

#### v0.1 – Apr 2018

Initial release. First version extracted from [Laminar](https://github.com/raquo/Laminar) repo.

repository: yurique/Airstream

repo_name: yurique/Airstream


text:
---
layout: post
title: Extensively monitoring spark-jobs with StatsD
categories:
- spark
- monitoring
- prometheus
- statsd
---

This post is a continuation with [Monitoring Spark jobs with Prometheus StatsD Exporter and Grafana](/posts/spark-statsd-prometheus-grafana.html)

In the previous post, we were just running statsd on the master node. Our aim here is for every node to have its statsd sidecar and prometheus scraping metrics from all of them.

A high-level diagram of what we are trying to do here

```bash
        (Executor 1)                          (Executor 2)
 [Service -> StatsdSink over UDP]    [Service -> StatsdSink over UDP]
             |                                     |
             ▼                                     ▼
 [StatsD Prometheus Exporter]          [StatsD Prometheus Exporter]
             |                                     |
             |                    _________________|
             |                    |
             ▼                    ▼
        +----------------------------+
        |    Prometheus Scraper      |        +----------+
        |         using EC2          |-------►|  Grafana |
        |     service discovery      |        +----------+
        +----------------------------+
             ▲                    ▲
             |                    |________________
             |                                     |
             |                                     |
 [StatsD Prometheus Exporter]          [StatsD Prometheus Exporter]
             ▲                                     ▲
             |                                     |
 [Service -> StatsdSink over UDP]    [Service -> StatsdSink over UDP]
        (Executor 3)                          (Executor 4)
```

We need statsd daemon on every executor.
```bash
docker pull prom/statsd-exporter:v0.14.1
docker run -d -p 9102:9102 -p 9125:9125 -p 9125:9125/udp --name statsd prom/statsd-exporter:v0.14.1
```

## metrics.properties

```bash
*.sink.statsd.class=org.apache.spark.metrics.sink.StatsdSink
*.sink.statsd.prefix=spark
*.sink.statsd.host=<IP_ADDRESS>
*.sink.statsd.port=9125
```

## prometheus.yml

```yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s
  scrape_timeout: 15s

scrape_configs:
  - job_name: "my-job"
    metrics_path: /metrics
    params:
      format: ["prometheus"]
    ec2_sd_configs:
      - region: "<aws-region>"
        port: 9102
        refresh_interval: 15m
    relabel_configs:
      - source_labels: [ __meta_ec2_tag_Name ]
        regex: my-job
        action: keep
      - source_labels: [__meta_ec2_tag_Name]
        target_label: instance
```

## EC2 tag-based discovery

EC2 SD configurations allow retrieving scrape targets from AWS EC2 instances.

## References

- [ec2_sd_config](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#ec2_sd_config)
- [Automatic Monitoring for new aws instances](https://medium.com/investing-in-tech/automatic-monitoring-for-all-new-aws-instances-using-prometheus-service-discovery-97d37a5b2ea2)

gha_language: CSS

gha_license_id: NOASSERTION


text:
### [CVE-2009-3789](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3789)
![](https://img.shields.io/static/v1?label=Product&message=n%2Fa&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=n%2Fa&color=blue)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=brighgreen)

### Description

Multiple cross-site scripting (XSS) vulnerabilities in OpenDocMan 1.2.5 allow remote attackers to inject arbitrary web script or HTML via the last_message parameter to (1) add.php, (2) toBePublished.php, (3) index.php, and (4) admin.php; the PATH_INFO to the default URI to (5) category.php, (6) department.php, (7) profile.php, (8) rejects.php, (9) search.php, (10) toBePublished.php, (11) user.php, and (12) view_file.php; and (13) the caller parameter in a Modify User action to user.php.

### POC

#### Reference
- http://www.packetstormsecurity.org/0910-exploits/opendocman-sqlxss.txt

#### Github
No PoCs found on GitHub currently.

repository: trickest/cve

repo_name: trickest/cve


text:
---
title: "Study Paredit"
date: 2020-12-26T13:03:10+03:00
draft: false
description: ""
tags:
categories: clojure
type: post
url:
author: "Mert Nuhoglu"
output:
  html_document:
    css: styles.css
state: wip

---

# @mine

paredit'in mevcut kısayolları hep noktalama işaretleri içeriyor. Bu yüzden kullanımı oldukça zor. Tim Pope'un vim için tanımladığı standart kısayollar daha kullanışlı. Burada anlatılıyor:

[Writing Clojure in Vim](https://thoughtbot.com/blog/writing-clojure-in-vim)

# The Animated Guide to Paredit id=g11865

[The Animated Guide to Paredit](http://danmidwood.com/content/2014/11/21/animated-paredit.html)

## Balanced pairs:

01: Opening: `()` `[]` `{}`

02: Closing and indenting:  `()` `[]` `{}`

03: Quoting: `""`

04: Wrapping an S-expression

	| M-( | paredit-wrap-round|

05: Deleting

They refuse deleting if it breaks balance of sexp.

`paredit-kill`, `paredit-forward-delete`

06: Slurping and barfing

	| C-) | paredit-forward-slurp-sexp |
	| C-} | paredit-forward-barf-sexp |

### 07: Structural navigation

Move forward/backward amongst siblings

Raise up enclosing sexp / descend back down into children

	| C-M-f | paredit-forward      |

opt01:

```clj
(a
	(b| c d))
->
(a
	(b c| d))
```

opt02:

```clj
(a
	(b c d)|
	(e f))
->
(a
	(b c d)
	(e f)|)
```

	| C-M-d | paredit-forward-down |

### 08: Splicing

Splicing = removing current sexp and joining the contents with the enclosing sexp

	| M-<up> | paredit-splice-sexp-killing-backward |

```clj
(a
	(b)
	(c)|
	(d))
->
(d)
```

```otl
a
	b
	c|
	d
->
d
```

	| M-<down> | paredit-splice-sexp-killing-forward |

```clj
((b| c) d)
->
(b d)
```

```otl
.
	.
		b|
		c
	d
->
.
	b
	d
```

repository: mertnuhoglu/study

repo_name: mertnuhoglu/study


text:
[![Build Status](https://travis-ci.org/graphsense/graphsense-REST.svg?branch=master)](https://travis-ci.org/graphsense/graphsense-REST)
[![Coverage Status](https://coveralls.io/repos/github/graphsense/graphsense-REST/badge.svg?branch=master)](https://coveralls.io/github/graphsense/graphsense-REST?branch=master)

# GraphSense REST Interface

The GraphSense REST Interface provides access to denormalized views computed
by the [graphsense-transformation][graphsense-transformation] pipeline.
It is used by the [graphsense-dashboard][graphsense-dashboard] component.

## Prerequisites

Make sure you are running Python version >= 3.7

    python3 --version

Create a python environment for required dependencies

    python3 -m venv venv

Activate the environment

    . venv/bin/activate

Install the requirements

    pip3 install -r requirements.txt

Export REST interface environment variables

    export FLASK_APP=gsrest
    export FLASK_ENV=development

You need access to GraphSense raw and transformed keyspaces.
See [Graphsense Transformation Pipeline][graphsense-transformation]
for further details.

## Development (without Docker)

Init the user database

    flask init-db

Create a username and password

    flask create-user john doe

Run the REST interface

    flask run

Test the service in your browser:

    http://localhost:5000

## Testing

Install project in local environment

    pip install -e .

Run tests

    pytest

Check test coverage

    coverage run -m pytest
    coverage report

## Deployment

When used in production, GraphSense-REST must be deployed to a WSGI server
because Flask's built-in server is not suitable for production -
it doesn't scale. From several [deployment options][flask-deployment],
we have chosen [Gunicorn][gunicorn].

Install gunicorn

    pip install gunicorn

Run production server

    gunicorn "gsrest:create_app()"

### Deployment with docker

After installing docker, build the image and start a container using:

    docker/build.sh
    docker/start.sh

Afterwards add users to the running container instance using

    docker/add_user.sh USERNAME PASSWORD

and test the service in a web browser:

    http://localhost:9000

## Usage

### Authenticate your client app

All REST interface methods require authentication via [JSON Web Tokens (JWT][https://jwt.io/].

Request a JWT by calling the login interface using a given username/password combination:

    curl -X POST "http://localhost:5000/login" -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"username\": \"john\", \"password\": \"doe\"}"

This will return a JWT, which you must use in subsequent requests.
This is an example response:

    {
        "status": "success",
        "message": "Successfully logged in.",
        "Authorization": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1NzE4MzQxNTMsImlhdCI6MTU3MTc0Nzc0OCwic3ViIjoiam9obiJ9.TxYnzE09A0BYfowvK4K5Zds6uyDJ_UrXkwF3NKqqvvA"
    }

Now use the JWT as part of the `Authorization` header field in subsequent requests:

    curl -X GET "http://localhost:5000/100/blocks/" -H "accept: application/json" -H "Authorization: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1NzE4MzQxNTMsImlhdCI6MTU3MTc0Nzc0OCwic3ViIjoiam9obiJ9.TxYnzE09A0BYfowvK4K5Zds6uyDJ_UrXkwF3NKqqvvA"

Logging out will blacklist the JWT

    curl -X POST "http://localhost:5000/logout" -H "accept: application/json" -H "Authorization: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1NzE3NzcyNTIsImlhdCI6MTU3MTY5MDg0Nywic3ViIjoic3RyaW5nIn0.muFr5f6vJEjh9NGwkXyxWgH3B0GuVkzxcu8fBgsKwdM"

## Customize REST interface configuration

Default configuration parameters are read from `app/config.py` during startup.

Parameters can be customized by placing a custom configuration file into the
Flask app instance folder, e.g., `instance/config.py`. Example

    MAPPING = {
    "tagpacks": "tagpacks",
    "btc": ["btc_raw", "btc_transformed"],
    "bch": ["bch_raw", "bch_transformed"],
    "ltc": ["ltc_raw", "ltc_transformed"],
    "zec": ["zec_raw", "zec_transformed"]
}

The secret key that will be used for signing authentication tokens is read
from the environment and should be set before starting the app

    export SECRET_KEY=$(python -c 'import os; print(os.urandom(16))')

[graphsense-blocksci]: https://github.com/graphsense/graphsense-blocksci
[graphsense-transformation]: https://github.com/graphsense/graphsense-transformation
[graphsense-dashboard]: https://github.com/graphsense/graphsense-dashboard
[docker]: https://docs.docker.com/install
[flask-deployment]: https://flask.palletsprojects.com/en/1.1.x/deploying/#self-hosted-options
[gunicorn]: https://gunicorn.org/#docs

repository: AYCHAIN/GraphSenseREST

gha_language: Python

repo_name: AYCHAIN/GraphSenseREST


text:
# Learnings

The entire project was done to learn to deal with Kafka and Docker and a bunch of different services I haven't had the chance to work with.

So it's important to note down all learnings.

## Design

- Usually in Kafka based systems even if producer and consumer apps are coupled on same system, the Kafka service is kept separate. This allows you to have a Kafka cluster which is separate
- If your consumer is going to write data in a file, better to do in batches. Less reads to disk means better efficiency.

## Kafka

- python client to use `kafka-python` - contains both consumer and producer code
- When you're writing to a topic you need to write bytes. So you need to use `.encode()`
    - You could also use a `value_serializer` which could be a lambda method directly while instantiating `KafkaProducer`.
- Kafka runs with help of Zookeeper. So by default Kafka itself requires two services - Kafka and Zookeeper. Hence it has its own docker-compose file.
- Most of Kafka docs I am learning from official docs and have highlighted it [there only](https://kafka.apache.org/documentation/).
- The consumer works on a pull based methodology. So it tries to keep pulling from topic by polling it. Hence once you define a `KafkaConsumer` you don't need to put your code in a `while True` loop. That stuff is taken care of by `KafkaConsumer` itself. You can have a simple loop assuming you're getting messages in `consumer` object (of type `KafkaConsumer`) and just do your stuff
- If you need to interact with the message - the actual message is in `message.value`. You should also first decode it. So if it's a simple string you get actual message by `message.value.decode('utf-8')`.

## Tweepy & Twitter

- The twitter dev account credentials activate immediately.
- By default you can do two kinds of streaming :
    - ***sample streaming*** which gives you 1% of current tweets from entire world with only language filter available
    - ***filter stream*** which lets you get streaming tweets containing keywords, or location you specify.
- Filter streaming API has a limit of 500,000 tweets in a month which is pretty less
- Sample streaming API does not count towards your API usage so you can practically keep getting new tweets without any limit
- There are two kinds of authentication - OAuth1.1 and OAuth2. Twitter suggests to use OAuth2 and Tweepy supports it but in OAuth2 streaming fails silently. You need to use OAuth1 even though all you're doing is reading.
- There's no way to stop the streaming unless / until you `return False` from `on_status` or `on_data` method in your StreamListener class
- When you select language as `en` for streaming.sample() it somehow doesn't return any hinglish tweets at all. Twitter probably understands something is code-mixed and doesn't throw that into the `en` language filter.

## Docker

- For each of your service you need to first have its own simple Dockerfile which just copies the code, installs the requirements and can run the app
- For a python app when you put `CMD ['python', 'app.py']` it doesn't output logs to STDOUT. You need to use `CMD ['python','-u','app.py']` so it flushes whatever IO related stuff it needs to do. This fixes the problem.

## Docker-compose

- You need to keep `version` key at the top of the file and it must be 3 (or above). This is not version of your software but rather defining type/structure of your docker-compose file.
- You can have multiple `docker-compose.xml` files for services which you would want to be kept de-coupled. So that if need be you can scale/kill/modify one independently
- When you do keep different services spawned up you need to have an **external network** defined on which these can communicate:
    - For this first create a new docker network : `docker network create kafka-network`
    - Then in each of the `docker-compose.X.xml` files add the following :
    ```
        # Give this composition access to the Kafka network
    networks:
      default:
        external:
          name: kafka-network
    ```
- Define all your config via **environment variables** in `docker-compose.xml` and let your `app.py` of each service read the environment variables for configs. This is done with `environment:` key in the `docker-compose.xml` file.
- Usually the mounted places in the container lie inside `/tmp/XYZ` dir or `/var/lib/XYZ` dir. Not sure why but that seems to be the convention.
- The volumes aspect needs to come in `docker-compose.xml` and not in the actual Dockerfile.
- For each of your services as long as they have their own folders and contain a file named `Dockerfile` inside them you can just define the folder path in `build:` key in docker-compose file.
- In `volumes:` you can give host's relative path. This is always relative to the docker-compose.xml file.
- For any kind of secrets don't expose them in `docker-compose.xml` directly as environment config variables. Rather use **docker secrets**. [More here](https://medium.com/lucjuggery/from-env-variables-to-docker-secrets-bc8802cacdfd). However this requires your docker containers to not be container but rather docker services and run in a swarm which can then be scaled. Secrets are automatically then given to containers in a swarm.
- A simpler way is you can keep a `.env` file which can be added to `.gitignore` and can be different in your prod versus dev environments. Here you can define your secrets. This way your secrets dont get exposed in Git repo.

## Python

- Use a csv writer for writing a csv. Default python f.writelines() actually does not write lines on separate lines. You need to use a `\n` at the end of each of your elements in your list of lines.

repository: bhavul/hinglish-data-generation

repo_name: bhavul/hinglish-data-generation


text:
This folder contains all the surface and volumetric meshes that are necessary to run the  sample programs.

## Acknowldegments
Many thanks to [Keenan Crane](https://www.cs.cmu.edu/~kmcrane/index.html) for releasing Blub and Spot to the public domain.

repository: mlivesu/cinolib

repo_name: mlivesu/cinolib


text:
# No call

(since [0.4.0](https://github.com/inaka/elvis_core/releases/tag/0.4.0))

This rule raise a warning when certain functions are called. It is also used internally to implement
`no_debug_call` and `no_common_caveats` but, on its own, makes no checks on your code (the default
`no_call_functions` list is empty).  However, it is a convenient place to add your own list of calls
to avoid (especially calls to third party libraries, where you can't just deprecate undesired
functions).

**Notice**: this rule is not enforced by default. Check the
[example `elvis.config` file](../../README.md#configuration) to see how you can enforce it.

> Works on `.beam` file? Yes!

## Options

- `no_call_functions :: [{module(), function(), arity()} | {module(), function()}]`.
  - default: `[]`.

## Example

```erlang
{elvis_style, no_call, #{ no_call_functions => [] }}
```

gha_language: Erlang


text:
Minesweeper Generator
=====================

Author: Evan Moritz
URL:    https://www.abiogenesis.me/minesweeper-generator

Description
-----------

Minesweeper Generator is a simple web form and image renderer for generating
images of minesweeper boards for academic purposes.

License
-------

Copyright (c) 2012-2017, Evan Moritz.

Minesweeper Generator is an open source software project released under the
MIT License. See the accompanying LICENSE file for terms.

Open Source Software
--------------------

This project uses the following open source libraries:

  - RequireJS 2.3.2
    Copyright jQuery Foundation and other contributors.
    Released under MIT license, https://github.com/requirejs/requirejs/blob/master/LICENSE

  - QUnit 2.0.1
    Copyright jQuery Foundation and other contributors
    Released under the MIT license, https://jquery.org/license

repository: emoritzx/minesweeper-generator

repo_name: emoritzx/minesweeper-generator


text:
# whatshouldicode-copy

This website is copid from https://whatshouldicode.netlify.app/

Credits: @ellie_html

https://twitter.com/ellie_html

# Need Help?

Are you completing the #100DaysOfCode Challenge? Do you sometimes find yourself stuck on what to do some days? Then look no further!

One of the best ways to learn is to build as much as possible. It will put your skills in to practice and you will learn as you go along. You'll find out what you don't know and what you need to know.

## Theme
- Picking an idea for something to build every day can be tough.. get your ideas flowing with a randomly selected theme and see what you can come up with.
- Try and pick something you are interested in. For example if you get video game, make a site for your favourite game. This way, it makes building sites more enjoyable! - Design not your thing? Perhaps recreate your favourite site or even use Dribbble for inspiration on specific elements!

## Code
- You can either create a one website page, a whole site or just the element you have been randomized. You could make this a much larger project and spend several days or just spend a couple of hours learning/building something specific. As long as your coding, you're learning!.
- If you don't know how to make something then Google will be your best friend. Youtube will have tutorials you can follow along and CodePen will certainly have plenty of examples if you need some inspiration.

repository: infinite-enigma/whatshouldicode-copy

repo_name: infinite-enigma/whatshouldicode-copy


text:
# Setting Sysctls with Kata

## Sysctls

In Linux, the sysctl interface allows an administrator to modify kernel
parameters at runtime. Parameters are available via the `/proc/sys/` virtual
process file system.

The parameters include the following subsystems among others:
- `fs` (file systems)
- `kernel` (kernel)
- `net` (networking)
- `vm` (virtual memory)

To get a complete list of kernel parameters, run:
```
$ sudo sysctl -a
```

Kubernetes provide mechanisms for setting namespaced sysctls.
Namespaced sysctls can be set per pod in the case of Kubernetes.
The following sysctls are known to be namespaced and can be set with
Kubernetes:

- `kernel.shm*`
- `kernel.msg*`
- `kernel.sem`
- `fs.mqueue.*`
- `net.*`

### Namespaced Sysctls:

Kata Containers supports setting namespaced sysctls with Kubernetes.
All namespaced sysctls can be set in the same way as regular Linux based
containers, the difference being, in the case of Kata they are set inside the guest.

#### Setting Namespaced Sysctls with Kubernetes:

Kubernetes considers certain sysctls as safe and others as unsafe. For detailed
information about what sysctls are considered unsafe, please refer to the [Kubernetes sysctl docs](https://kubernetes.io/docs/tasks/administer-cluster/sysctl-cluster/).
For using unsafe sysctls, the cluster admin would need to allow these as:

```
$ kubelet --allowed-unsafe-sysctls 'kernel.msg*,net.ipv4.route.min_pmtu' ...
```

or using the declarative approach as:

```
$ cat kubeadm.yaml
apiVersion: kubeadm.k8s.io/v1alpha3
kind: InitConfiguration
nodeRegistration:
  kubeletExtraArgs:
    allowed-unsafe-sysctls: "kernel.msg*,kernel.shm.*,net.*"
...
```

The above YAML can then be passed to `kubeadm init` as:
```
$ sudo -E kubeadm init --config=kubeadm.yaml
```

Both safe and unsafe sysctls can be enabled in the same way in the Pod YAML:

```
apiVersion: v1
kind: Pod
metadata:
  name: sysctl-example
spec:
  securityContext:
    sysctls:
    - name: kernel.shm_rmid_forced
      value: "0"
    - name: net.ipv4.route.min_pmtu
      value: "1024"
```

### Non-Namespaced Sysctls:

Kubernetes disallow sysctls without a namespace.
The recommendation is to set them directly on the host or use a privileged
container in the case of Kubernetes.

In the case of Kata, the approach of setting sysctls on the host does not
work since the host sysctls have no effect on a Kata Container running
inside a guest. Kata gives you the ability to set non-namespaced sysctls using a privileged container.
This has the advantage that the non-namespaced sysctls are set inside the guest
without having any effect on the `/proc/sys` values of any other pod or the
host itself.

The recommended approach to do this would be to set the sysctl value in a
privileged init container. In this way, the application containers do not need any elevated
privileges.

```
apiVersion: v1
kind: Pod
metadata:
  name: busybox-kata
spec:
  runtimeClassName: kata-qemu
  securityContext:
    sysctls:
    - name: kernel.shm_rmid_forced
      value: "0"
  containers:
  - name: busybox-container
    securityContext:
      privileged: true
    image: debian
    command:
        - sleep
        - "3000"
  initContainers:
  - name: init-sys
    securityContext:
      privileged: true
    image: busybox
    command: ['sh', '-c', 'echo "64000" > /proc/sys/vm/max_map_count']
```

repository: kata-containers/kata-containers

gha_language: Rust

repo_name: kata-containers/kata-containers


text:
# Realtime Analytics with redis on Flask

This is Flask extension which implements real-time and scalable analytics based on Redis

## Requirements

* Redis server
* Python library
~~~
pip install flask-session
pip install redis
~~~
* Javascript library for graph
 * http://dimplejs.org/

## How to use
Just put snippet on page. Put event in request, Select events and Graph such as bar, pie.

~~~
{{ bitmap_analytics(['test', 'view', 'buy'], graph='pie') }}
{{ bitmap_analytics(['view', 'buy']) }}
~~~

![alt text](https://github.com/brenden17/Realtime-Analytics-with-Flask-on-Redis/blob/master/img/analysis.png "image")

That's all.


text:
### [CVE-2007-0578](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0578)
![](https://img.shields.io/static/v1?label=Product&message=n%2Fa&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=n%2Fa&color=blue)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=brighgreen)

### Description

The http_open function in httpget.c in mpg123 before 0.64 allows remote attackers to cause a denial of service (infinite loop) by closing the HTTP connection early.

### POC

#### Reference
- http://www.mpg123.de/cgi-bin/news.cgi

#### Github
No PoCs found on GitHub currently.


text:
# Configuring a Single Node

This page walks you through how to manually configure and deploy WSO2 API Manager in a standalone single instance, without using a distributed or HA deployment patterns.

Follow the instructions below to configure and deploy API-M using a single node:

-   [Step 1 - Create a SSL certificate](#ConfiguringaSingleNode-Step1-CreateaSSLcertificate)
-   [Step 2 - Configure the load balancer](#ConfiguringaSingleNode-Step2-Configuretheloadbalancer)
-   [Step 3 - Configure the databases](#ConfiguringaSingleNode-Step3-Configurethedatabases)
-   [Step 4 - Configure hostnames that are used to expose APIs](#ConfiguringaSingleNode-Step4-ConfigurehostnamesthatareusedtoexposeAPIs)
-   [Step 5 - Configure your deployment with production hardening](#ConfiguringaSingleNode-Step5-Configureyourdeploymentwithproductionhardening)
-   [Step 6 - Configure API-M Analytics](#ConfiguringaSingleNode-Step6-ConfigureAPI-MAnalytics)
-   [Step 7 - Start the WSO2 API-M server](#ConfiguringaSingleNode-Step7-StarttheWSO2API-Mserver)

### Step 1 - Create a SSL certificate

!!! note
This step is optional based on the setup that you configure. All WSO2 products are by default shipped with a keystore file and truststore file (stored in the `<PRODUCT_HOME>/repository/resources/security/` directory). The default keystore that is shipped with a WSO2 product ( `wso2carbon.jks)` is by default configured for all of the following purposes.

-   Authenticating the communication over Secure Sockets Layer (SSL)/Transport Layer Security (TLS) protocols.
-   Encrypting sensitive data such as plain-text passwords found in both product-level and product feature-level configurations/configuration files using [secure vault](https://docs.wso2.com/display/ADMIN44x/Carbon+Secure+Vault+Implementation) .

-   Encrypting and signing SOAP messages using WS-Security.

However, in a production environment, it is advised to set up several different keystores with separate trust chains for the above use cases. For more information, see [Recommendations for setting up keystores in WSO2 products](https://docs.wso2.com/display/ADMIN44x/Using+Asymmetric+Encryption#UsingAsymmetricEncryption-recommendations) in the Administration Guide.

Create a SSL certificate on the WSO2 API Manager node. For more information, see [Creating SSL Certificates](https://docs.wso2.com/display/ADMIN44x/Creating+New+Keystores) in the Administration Guide.

### Step 2 - Configure the load balancer

For information on configuring the load balancer see \_Configuring the Proxy Server and the Load Balancer .

### Step 3 - Configure the databases

For information on configuring the databases, see \_Installing and Configuring the Databases .

### Step 4 - Configure hostnames that are used to expose APIs

!!! note
    This step is only required if you are using a hostname to expose APIs.

??? info "Click here for more information."
    Add this hostname when you configure environments in the `<API-M_HOME>/repository/conf/deployment.toml` file. Update the endpoints with your chosen hostname as shown below. In this case we are using `localhost` as the hostname:

    ``` java
        [[apim.gateway.environment]]
        name = "Production and Sandbox"
        type = "hybrid"
        display_in_api_console = true
        description = "This is a hybrid gateway that handles both production and sandbox token traffic."
        show_as_token_endpoint_url = true
        service_url = "https://localhost:${mgt.transport.https.port}/services/"
        username= "${admin.username}"
        password= "${admin.password}"
        ws_endpoint = "ws://localhost:9099"
        wss_endpoint = "wss://localhost:8099"
        http_endpoint = "http://localhost:${http.nio.port}"
        https_endpoint = "https://localhost:${https.nio.port}"
    ```

### Step 5 - Configure your deployment with production hardening

Ensure that you have taken into account the respective security hardening factors (e.g., changing and encrypting the default passwords, configuring JVM security etc.) before deploying WSO2 API-M. For more information, see the [Production Deployment Guidelines](https://docs.wso2.com/display/ADMIN44x/Production+Deployment+Guidelines#ProductionDeploymentGuidelines-Commonguidelinesandchecklist) in the Administration Guide.

### Step 6 - Configure API-M Analytics

If you wish to view reports, statistics, and graphs related to the APIs deployed in the Store, you need to configure API-M Analytics. Follow the [standard setup](https://docs.wso2.com/display/AM260/Configuring+APIM+Analytics#StandardSetup) to configure API-M Analytics in a production setup, and follow the [quick setup](https://docs.wso2.com/display/AM260/Configuring+APIM+Analytics#Quick-Setup) to configure API-M Analytics in a development setup.

### Step 7 - Start the WSO2 API-M server

!!! note
Before you start the server

If you want to deploy WSO2 API-M using a hybrid single node deployment, where WSO2 Identity Server is used as the Key Manager while the rest of the WSO2 API-M components are all in one node, configure and start the Key Manager (e.g., configure and start WSO2 Identity Server as the Key Manager ) before starting the API-M server.

Start the server using the following standard start-up script. For more information, see [Starting the server](https://docs.wso2.com/display/AM260/Running+the+Product#RunningtheProduct-Startingtheserver) .

-   [**Linux/Mac OS**](#Linux-Mac)
-   [**Windows**](#windows)

``` java
    cd <API-M_HOME>/bin/
    sh wso2server.sh
```

``` java
    cd <API-M_HOME>\bin\
    wso2server.bat --run
```

repository: informixids/docs-apim

repo_name: informixids/docs-apim


text:
# kubewatch

[kubewatch](https://github.com/clouddrove/helmchars/charts/kubewatch) is a Kubernetes watcher that currently publishes notification to Slack. Run it in your k8s cluster, and you will get event notifications in a slack channel.

## TL;DR;

```console
$ helm install stable/kubewatch
```

## Introduction

This chart bootstraps a kubewatch deployment on a [Kubernetes](http://kubernetes.io) cluster using the [Helm](https://helm.sh) package manager.

## Installing the Chart

To install the chart with the release name `my-release`:

```console
$ helm install stable/kubewatch --name my-release
```

The command deploys kubewatch on the Kubernetes cluster in the default configuration. The [configuration](#configuration) section lists the parameters that can be configured during installation.

## Uninstalling the Chart

To uninstall/delete the `my-release` deployment:

```console
$ helm delete my-release
```

Specify each parameter using the `--set key=value[,key=value]` argument to `helm install`. For example,

```console
$ helm install stable/kubewatch --name my-release \
  --set=slack.channel="#bots",slack.token="XXXX-XXXX-XXXX"
```

Alternatively, a YAML file that specifies the values for the above parameters can be provided while installing the chart. For example,

```console
$ helm install stable/kubewatch --name my-release -f values.yaml
```

## Create a Slack bot

Open [https://name.slack.com/services/new/bot](https://name.slack.com/services/new/bot) to create a new Slack bot.
The API token can be found on the edit page (it starts with `xoxb-`).

Invite the Bot to your channel by typing `/join @your_bot` in the Slack message area.

repository: anmolnagpal/helmcharts

repo_name: anmolnagpal/helmcharts


text:
Terraform Module: NAT instances (Google provider)
=================================================

A simple Terraform module for [Google Cloud Platform](https://cloud.google.com/) that creates a NAT instance to forward
traffic from internal instances without external IP addresses to the internet.

## Why?

By default, Google Compute instances without an external IP address are unable to access the internet. Google also provides
[Cloud NAT](https://cloud.google.com/nat/docs/overview) which provides the same functionality as is implemented in this
module. However, as per https://cloud.google.com/nat/docs/ports-and-addresses#ports-reuse-tcp, Google Cloud enforces a
two-minute delay before the gateway can reuse the same NAT source IP address and source port tuple with the same
destination (destination IP address, destination port, and protocol).

This poses a problem when rapidly opening and closing connections to the same destination IP, port and protocol. Google
recommends assigning an external IP address to a Google Compute instance and forwarding traffic through this instance.

This is the functionality that this module provides.

## Usage

```hcl-terraform
resource google_compute_address nat_instance {
  name = "nat-instance"
  region = "europe-west3"
}

module nat_instance_01 {
  source = "garbetjie/nat-instance/google"
  address = google_compute_address.nat_instance.address  // Required
  zone = "europe-west3-a"                                // Required
  disk_size = 15                                         // Optional
  disk_type = "pd-standard"                              // Optional
  machine_type = "f1-micro"                              // Optional
  network_tags = ["requires-nat-${local.region}"]        // Optional
  route_priority = 900                                   // Optional
  socks_proxy = { enabled = true }                       // Optional
  sysctl_config = {}                                     // Optional
  wait_duration = 10                                     // Optional
}
```

## Inputs

| Name                | Description                                                                                | Type                                                                                | Default                            | Required |
|---------------------|------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------|------------------------------------|----------|
| address             | The external IP address to assign to this instance.                                                                                | string                                                                                |                                    | Yes      |
| zone                | The zone in which to place this instance. Must be the same region as the IP address provided.                                                  | string                                                                                |                                    | Yes      |
| disk_size           | Size of the instance's disk (in GB)                                                                                | number                                                                                | `15`                               | No       |
| disk_type           | Type of the instance's disk (one of `pd-standard` or `pd-ssd`). `google` provider `>= 3.37` allows the option of `pd-balanced` to be provided. | string                                                                                | `pd-standard`                      | No       |
| machine_type        | Machine type of the instance.                                                                                | string                                                                                | `f1-micro`                         | No       |
| network_tags        | Tags to which this route applies.                                                                                | list(string)                                                                                | `["requires-nat-${local.region}"]` | No       |
| route_priority      | The priority to assign the networking route that routes traffic through this instance.                                                         | number                                                                                | `900`                              | No       |
| socks_proxy         | Configuration for enabling a SOCKS proxy on this instance.                                                                                | object({ enabled=bool, debug=optional(number), port=optional(number), allowed_ranged=optional(set(string)) }) | `{ enabled = false }`              | No       |
| socks_proxy.enabled | Flag used to enable/disable the SOCKS proxy.                                                                                | bool                                                                                | `false`                            | No       |
| socks_proxy.debug   | Debug log level used in the SOCKS proxy. Can be one of `0`, `1`, or `2`.                                                                       | number                                                                                | `0`                                | No       |
| socks_proxy.port    | Port on which to bind the SOCKS proxy.                                                                                | number                                                                                | `8888`                             | No       |
| allowed_ranges      | CIDR ranges allowed to connect to the proxy. Firewall rules will also be configured to allow these ranges to connect on the specified port.    | set(string)                                                                                | `[]`                               | No       |
| sysctl_config       | sysctl configuration to apply on startup.                                                                                | map(string)                                                                                | `{}`                               | No       |
| wait_duration       | The duration (in seconds) to wait for the NAT instance to finish starting up.                                                                  | number                                                                                | `10`                               | No       |

## Outputs

| Name           | Description                                                                            |
|----------------|----------------------------------------------------------------------------------------|
| address        | Internal IP address of this NAT instance.                                              |
| disk_size      | Size of the instance's disk (in GB).                                                   |
| disk_type      | Type of the instance's disk.                                                           |
| instance_name  | Name of the Compute Engine instance.                                                   |
| machine_type   | Machine type of the instance.                                                          |
| nat_address    | NAT IP address of this NAT instance.                                                   |
| network_tags   | Tags to which this instance's routes applies.                                          |
| route_name     | Name of the route used to route traffic through the instance.                          |
| route_priority | Priority assigned to the networking route used to route traffic through this instance. |
| socks_proxy    | SOCKS proxy configuration applied to the NAT instance.                                 |
| sysctl_config  | sysctl config applied on NAT instance boot.                                            |
| wait_duration  | The duration (in seconds) that was allowed for the NAT instance to finish booting.     |
| zone           | Zone in which the Compute Engine instance has been placed.                             |

## Changelog

* **3.0.1**
  * Fix incorrect assumption that default value of `var.network_tags` is `null` when checking for empty tags.

* **3.0.0**
  * Remove HTTP forward proxy, and replaced it with a SOCKS proxy.

* **2.0.0**
  * Enable functioning as an HTTP forward proxy.

repository: garbetjie/terraform-google-nat-instance

repo_name: garbetjie/terraform-google-nat-instance


text:
# Napari Playground

Some of my experiments with [Napari](https://github.com/napari/napari). Still baby steps at this point.

## Multilabelling HDF5 viewer

A few years ago, I implemented a hdf5-based format and custom viewer for highly multiplexed
fluorescence data, [see this Github repo](https://github.com/VolkerH/Multilabelling_HDF5_View).

I managed to implement most of the functionality (including registered display of layers)
available in my custom viewer with a few lines of python using napari [Source Code](./Multilabelling/multilabel.py).

![](./Gallery/multilabelling.png)

![](./Gallery/multiplex_napari2.gif)

## Simple label/object inspector demo

A quick and dirty hack, just to show what a label inspector could look like in napari. [Source Code](./CustomMouseFunctions/custom_mouse_functions.py)
![](./Gallery/napari_label_inspector.gif)

An addition to this hack, where measurement is performed by selecting Label and Intensity layers in napari and pressing a key [Source](.CustomMouseFunctions/MeasurementExplorer/region_measurement.py).
![](./Gallery/measure_labels.gif)

## Live webcam with face detection results as shapes layer

Based on the opencv facedetect demo code. Adapted to napari.
Note: requires PyQt5, will crash with PySide (due to opencv using PyQt)
[Code](./LiveUpdate/webcam_opencv.py)
![](./Gallery/webcam2.gif)

repository: VolkerH/NapariPlayground

repo_name: VolkerH/NapariPlayground


text:
# DEMO: Office 365 Calendar
Use the completed lab project in the **Completed Solution** folder for this module as the demo.

Before running the demo you need to first create an app in Azure AD and update the project with the specific app information such as the client ID, client secret and Azure AD tenantID.

To do this, open the project in Visual Studio. Look at the lab and about half-way through **Exercise 1**, right after you create the project, pickup the steps to **Add the Connected Service**. Following these instructions will register the app in your Azure AD & update the `web.config` with the new app client ID and secret.

The last step is to acquire your Azure AD tenantID (*the last step in Exercise 1*) and add that to the `web.config` in the app setting **iad:AadTenantId**.

url: https://raw.githubusercontent.com/DJGHOSTMACHINE/TrainingContent/aee85fd690f70a248d5c5cc5e0f31e543f9338a9/O3653/O3653-13 Deep Dive into Office 365 APIs for Calendar/Demos/README.md

repository: DJGHOSTMACHINE/TrainingContent

gha_language: JavaScript

repo_name: DJGHOSTMACHINE/TrainingContent


text:
# LAB 01
SMACSS and Responsive Web Design

## Task

- Create site styled for mobile device with breakpoint at max width of 768 pixels for new style at desktop view.

- Have multiple boxes ``a - i`` using only float-based layout in accordance to mobile/desktop wireframe.

- Apply unique background color for *each* box that changes between mobile/desktop view.


text:
# Usage
```
PS> .\enable-msi.ps1 <vendor-id>:<device-id> [<vendor-id>:<device-id> ...]
```
## Example
```
PS> .\enable-msi.ps1 10DE:1D01 8086:A348

Processing device 10DE:1D01.
└ Found instance: VEN_10DE&DEV_1D01&SUBSYS_8C981462&REV_A1\4&3335b6e8&0&00E0
  MSI is currently disabled; turning it on.

Processing device 8086:A348.
└ Found instance: VEN_8086&DEV_A348&SUBSYS_1A1D15D9&REV_10\5&226b9205&0&E008F0
  MSI is already enabled; skipping instance.
```

# Group Policy Deployment
💡 Since a device's MSI flag gets reset whenever its driver is updated, setting the script to run automatically at shutdown/startup ensures MSI stays enabled.
1. Decide whether to deploy as a shutdown or startup script. Shutdown is recommended as MSI is enabled at the next startup, while this takes an extra reboot with a startup script.
2. Install `enable-msi.ps1` to `\\<domain>\SYSVOL\<domain>\Policies\<policy-guid>\MACHINE\Scripts\<Shutdown|Startup>`.
3. In _Group Policy Management Editor_ (`gpedit.msc`):

   _Computer Configuration_ ➡ _Policies_ ➡ _Windows Settings_ ➡ _Scripts (Startup/Shutdown)_ ➡
<_Shutdown_|_Startup_> ➡ _PowerShell Scripts_ ➡ _Add..._
   - _Script Name:_ `enable-msi.ps1`
   - _Script Parameters:_ `<vendor-id>:<device-id> [<vendor-id>:<device-id> ...]` (e.g. `10DE:1D01 8086:A348`)

# Mode of Operation
The script finds devices with the given PCI IDs in the registry and sets their `MSISupported` property to `1`, creating intermediate keys as needed.

`HKLM\SYSTEM\CurrentControlSet\Enum\PCI\<device-instance-path>\Device Parameters\Interrupt Management\MessageSignaledInterruptProperties`
- `MSISupported` (DWORD): `0` ➡ `1`

repository: SebMouren/windows-enable-msi

repo_name: SebMouren/windows-enable-msi


text:
wss
===
wrapper built upon [ws](https://www.npmjs.org/package/ws) module that provides standard server api only.

[![travis](https://img.shields.io/travis/ivoputzer/wss.svg?style=for-the-badge)](https://travis-ci.org/ivoputzer/wss)
[![dependencies](https://img.shields.io/badge/dependencies-1-blue.svg?style=for-the-badge&colorB=44CC11)](package.json)
[![linter](https://img.shields.io/badge/coding%20style-standard-brightgreen.svg?style=for-the-badge)](http://standardjs.com/)
[![coverage](https://img.shields.io/coveralls/ivoputzer/wss.svg?style=for-the-badge)](https://coveralls.io/github/ivoputzer/wss?branch=master)

[![node](https://img.shields.io/badge/node-6%2B-blue.svg?style=for-the-badge)](https://nodejs.org/docs/v6.0.0/api)
[![version](https://img.shields.io/npm/v/wss.svg?style=for-the-badge&colorB=007EC6)](https://www.npmjs.com/package/wss)
[![minzip](https://img.shields.io/bundlephobia/minzip/wss.svg?style=for-the-badge)](https://www.npmjs.com/package/wss)
[![license](https://img.shields.io/badge/license-MIT-blue.svg?style=for-the-badge&colorB=007EC6)](https://spdx.org/licenses/MIT)

#### usage with server creation

```javascript
const {createServer} = require('wss')

createServer(function connectionListener (ws) {
  ws.send('welcome!')
  ws.on('message', (data) => {
    ws.send(data.toString()) // echo-server
  })
})
.listen(8080, function () {
  const {address, port} = this.address() // this is the http[s].Server
  console.log('listening on http://%s:%d (%s)', /::/.test(address) ? '<IP_ADDRESS>' : address, port)
})
```

#### usage with existent server
```javascript
const {createServer} = require('http')
const {createServerFrom} = require('wss')

const http = createServer()
createServerFrom(http, function connectionListener (ws) {
  ws.send('welcome!')
  ws.on('message', (data) => {
    ws.send(data.toString()) // echo-server
  })
})
http.listen(8080)
```

### wss
the `ws.Server` object is inherited from [ws](http://npmjs.org/ws)

### wss.prototype.close([callback])
stops the server from accepting new connections.

### wss.prototype.listen(handle[, callback])
the `handle` object can be set to either a server or socket (anything with an underlying _handle_ member), or a `{fd}` object. This function is asynchronous. callback will be added as a listener for the `listening` event.

### wss.prototype.listen(path[, callback])
start a unix socket server listening for connections on the given path. this function is asynchronous. callback will be added as a listener for the `listening` event.

### wss.prototype.listen([port[, hostname[, backlog[, callback]]]])
begin accepting connections on the specified port and hostname. if the hostname is omitted, the server will accept connections on any ipv6 address (::) when ipv6 is available, or any ipv4 address (<IP_ADDRESS>) otherwise. omit the port argument, or use a port value of 0, to have the operating system assign a random port, which can be retrieved by using server.address().port after the `listening` event has been emitted.

to listen to a unix socket, supply a filename instead of port and hostname.

backlog is the maximum length of the queue of pending connections. The actual length will be determined by your OS through sysctl settings such as `tcp_max_syn_backlog` and somaxconn on linux. The default value of this parameter is `511`. This function is asynchronous. `callback` will be added as a listener for the `listening` event.

Note: The server.listen() method may be called multiple times. Each subsequent call will re-open the server using the provided options.

### wss.createServerFrom(server=http.Server|https.Server)
returns a new `ws.Server` based on given web server object.
throws if no server is given.

### wss.createServer([options[, connectionListener]])
returns a new `ws.Server` based on given options and connectionListener. underlaying `https` server is created when `tls` options have been provided as of`tls.createServer()`, otherwise it will fallback to a `http` implementation. the connectionListener is a function which is automatically added to the `connection` event.

repository: ivoputzer/wss

repo_name: ivoputzer/wss


text:
# Controllers and Operators

## Requirements

* Linux or OSX machine
* Docker (with Kubernetes) or [minikube](https://kubernetes.io/docs/setup/minikube/)
* [Kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
* [helm](https://github.com/helm/helm)
* Runtime for any language you want to write your code with.
* IDE

repository: ipedrazas/Workshops

repo_name: ipedrazas/Workshops


text:
# OpenShift Cartridge for Heroku Buildpacks

This cartridge is useful for migrating applications from Heroku to
OpenShift or for developers that are more comfortable with
Heroku-style buildpacks than OpenShift-style cartridges.

To use:

    rhc app create <APP> https://raw.github.com/bbrowning/openshift-origin-cartridge-heroku/master/metadata/manifest.yml

For now only a preselected set of heroku buildpacks - clojure, go,
gradle, grails, java, multi, nodejs, php, play, python, ruby, and
scala - will work. The buildpack to use will be auto-detected using
Heroku's detection logic based on your application's source code. We
only run the web Procfile entry.

Things are still very early, so expect bugs.


text:
# Components

## Power Management
- Battery
    - Name: RJD3032HPPV30M
    - digikey: 1572-1623-ND
    - V = 3.7V
    - Capacity = 200mAh
    - I (max) = 40mA
    - V (charge) = 4.2V
    - V (cutoff) = 3.0V
- Battery Connector
    - Name:  Molex<PHONE_NUMBER>
    - digikey:  WM7620CT-ND
    - Height: 3.4mm
- Battery Charger
    - Name:  MCP73831T-2ACI/OT
    - digikey: MCP73831T-2ACI/OTCT-ND
    - V = 4.2V
    - I = 100mA (prog=10K)
- Power multiplexer
    - Name: TPS2113ADRBR
    - digikey: 296-46373-1-ND
    - I (quiescent) = 55uA
- Voltage regulator (High power)
    - Name: TPS70933DBVR
    - digikey: 296-35483-1-ND
    - V = 3.3V
    - I (quiescent) = 1uA
    - I (out) = 150mA

## Screen
- Screen (SPI + Enable)
    - Name: LS010B7DH01
    - digikey: 425-2899-ND
    - P (max) = 55uW (still) or 100uW (change)
    - V = 4.5-5.5V
    - I (max) = 11uA (still) or 20uA (change)
- Screen Connector (FPC)
    - Name: Molex LLC<PHONE_NUMBER>
    - digikey: WM1389CT-ND
    - NOTE: Need to verify that this is the right part
- Charge Pump (3.3V -> 5V for Screen)
    - Name: TPS60241DGKR
    - digikey: 296-12241-6-ND
    - I (out) = 25mA
    - I (quiescent) = 250-400uA (1uA in shutdown)
- Boost Converter (3.3V -> 5V for screen power) [ NOT USED ]
    - Name: TPS61222DCKR
    - digikey: 296-39435-1-ND

## MCU
- Microcontroller
    - Name: STM32F303C8T6
    - digikey: 497-15198-ND
    - V = 3.3V
    - I (max) = 160mA
    - I (typ) = ~20mA
    - I (PVD) = 0.15uA (nominal)
- 16MHz Crystal
    - Name: FA-238 16.0000MB-C3
    - digikey: SER3686CT-ND
    - Load Capacitance: 18pF
- 32.768 RTC
    - Name: ECS-.327-12.5-34B-TR
    - digikey: XC1617TR-ND
    - Load Capacitance: 12.5pF
- 3 Color LED
    - Name: SMLP34RGB2W3
    - digikey: SMLP34RGB2W3CT-ND
- Push Button
    - Name: PTS820 J15M SMTR LFS
    - digikey: CKN10506CT-ND

## IMU
- IMU (SPI)
    - Name: LSM6DSLTR
    - digikey: 497-16705-1-ND
    - V = 1.7 - 3.6V (1.8V typ)
    - I (gyro norm) = 0.45mA
    - I (acc norm) = 85uA
    - I (power down) = 3uA

## Capactive Touch
- 4 Capacitive touch sensors (4 I/O)
    - Name: AT42QT1070-MMHR
    - digikey: AT42QT1070-MMHCT-ND
    - V = 3.3V
    - I (@3.3V) = 434uA - 906uA
    - I (standalone) = 615uA

## BLE
- Bluetooth (UART)
    - Name: BM71BLES1FC2-0002AA
    - digikey: BM71BLES1FC2-0002AA-ND
    - V = 3.3V
    - I (rx/tx) = 10mA (typ) 13mA (max)
    - I (reduced) = 60uA (typ)
    - I (shutdown) = 1uA (min) 2.9uA (max)

- Bluetooth (UART)
    - Name: RN4871-V
    - digikey: RN4871-V/RM118-ND
    - V = 3.3V
    - I (rx/tx) = 10mA (typ) 13mA (max)
    - I (reduced) = 60uA (typ)
    - I (shutdown) = 1uA (min) 2.9uA (max)

- Brown Out Detection
    - Name: RT9818A-18GV
    - digikey: RT9818A-18GV-ND
    - V (threshold) = 1.8V
    - I (quiescent) = 3uA

## Vibration Motor
- Vibration motor
    - Name: Adafruit Industries LLC 1201
    - digikey: 1528-1177-ND
    - V = 2-5V
    - I (@3V) = 60mA
- MOSFET (to drive vibration motor)
    - name: RUM002N02T2L
    - digikey: RUM002N02T2LCT-ND
    - Vgs = 8V (max) 1V (max thresh)
- Flyback Diode ???
    - name: ON Semiconductor BAT54
    - digikey: BAT54FSCT-ND

## Extra
- External flash (SPI) [ NOT SPECCED ]

# Power Budget
Power budget is the maximum average power over an hour.
- MCU = 20mA
- Power Management = 55uA + 1uA ~ 60uA
- Screen = 15uA + 400uA ~  450uA
- IMU = 450uA + 85uA ~ 600uA
- Touch = 615uA
- BLE = ~10mA
- Vibration = ~10mA

Sum = 20mA + 0.06mA + 0.45mA + 0.6mA + 0.6mA + 10mA + 10mA ~ 42mA

Giving us a little under 0.25C draw rate, or about 4 hours of battery life minimum.

Taking into account the lower power modes of various peripherals, we can assume: BLE=60uA, IMU=3uA, and Vibration=0.1mA (pulsed, and not very often). This gives us an average current draw of:

20mA + 0.06mA + 0.45mA + 0.003mA + 0.06mA + 0.6mA + 0.1mA = 21mA => 0.12C draw rate ~ 10hrs

Ideally we can reduce the power consumption of our MCU even more, giving us extra buffer room for other components.

repository: byronwasti/prusto-watch-hardware

repo_name: byronwasti/prusto-watch-hardware


text:
# DataViaSound
This is an application for Android which allows you to send data using sound waves.
# Documentation
This application had been developed as part of my Engineer Diploma Work on Czestochowa University of Technology.
The diploma work can be treated as elaborated documentation of the application and the testing tool (DataViaSoundTester). It also contains related knowledge about sound, reports from tests which were performed over the application, analysis of the reports and conclusions.
https://github.com/luckynick/DataViaSound/blob/master/Diploma.pdf
# Testing tool
https://github.com/luckynick/DataViaSoundTester

repository: hankyanggg/DataViaSound

repo_name: hankyanggg/DataViaSound


text:
---
title: Reflection
layout: course_page
published: true
---
# Reflection (5 minutes)

**Plus/Delta** – What went well today? What do you want to change for the next meeting?
Use the facilitator guide to take notes of any suggestions you want to save.

## Before the Next Meeting

**Independent Assignment:**
It’s time to start the **second draft** of your artifact in a new Google Document! Think through the group’s feedback and incorporate the suggestions that resonated with you into the second draft. We’ll share links to your Google Docs in the facilitator guide during the next session.

branch_name: refs/heads/gh-pages

gha_language: SCSS


text:
# `pg-ipc`

> IPC over PostgreSQL LISTEN/NOTIFY/UNLISTEN exposed as an EventEmitter

## Usage

```js
var pgIPC = require('pg-ipc')
var client = new require('pg').Client({ ... })

var ipc = pgIPC(client)

ipc.on('error', console.error)

ipc.on('end', function () {
  client.end()
})

ipc.on('someChannel', function (msg) {
  // Ignore messages from this process
  if (msg.processId === client.processID) return
  console.log(msg.payload.currentTime)
})

ipc.notify('someChannel', {currentTime: Date.now()})

// some time later ...

ipc.end()

```

## API

### `pgIPC(client)`

Instantiates a new `EventEmitter` with the appropriate hooks to automatically
`LISTEN`/`NOTIFY`/`UNLISTEN`. Note that `client` must be a `pg.Client` instance
and not a `pg.Pool`, as a single connection is required.

### `ipc.on(channel, listener)`
All the standard `EventEmitter` methods are exposed. When a listener is added to
`channel`, a `LISTEN` command is automatically issued, and `UNLISTEN` when the
number of listeners reach zero. The listener will receive the message as its
first argument. Notable properties being `channel`, `payload`, `processId`. Each
postgres `connection` is assigned a unique `processId`, which can be used to
ignore messages from the same process.
See [`EventEmitter`](https://nodejs.org/api/events.html) for more details.
Reserved channels are:
`['newListener', 'removeListener', 'notify', 'unlisten', 'listen', 'error', 'end']`

### `ipc.notify(channel[, payload])`
Alias: `ipc.send(channel[, payload])`. Send a message to `channel` with optional
`payload`. `payload` is transparently converted to JSON where appropriate.

### `ipc.end()`
Issue `UNLISTEN *` if connected, emit `end` and detach all event listeners.
Does not call `client.end()` so you can continue using the client. However,
any listeners you've issued outside outside of this module will also be detached

### Event: `listen`

Emitted when a `LISTEN` has been successfully issued. Passed `channel`

### Event: `notify`

Emitted after a notification has been successfully sent. Passed `channel` and `payload`

### Event: `unlisten`

Emitted when a `UNLISTEN` has been successfully issued. Passed `channel`

### Event: `end`

Emitted when all `LISTEN`s have been removed, but before all event listeners are removed.

### Event: `error`

Propagates any errors caused by queries on `Client`. Passed the `err` argument from
the query callback.

## Install

```sh
npm install pg-ipc
```

## License

[ISC](LICENSE.md)

license: ISC

repository: emilbayes/pg-ipc

repo_name: emilbayes/pg-ipc