From Flavio's presentation

Let's add a folder and specs for Laravel and php in the /server-side/frameworks folder

https://en.wikipedia.org/wiki/Email_address

There are some crazy email addresses allowed in RFC 5321 and RFC 5322. Here is the above articles set of rules, and examples of valid and invalid addresses.

Local-part

The local-part of the email address may use any of these [[ASCII]] characters:

• uppercase and lowercase [[Basic Latin (Unicode block)|Latin]] letters A to Z and a to z;

• digits 0 to 9;

• special characters !#$%&'*+-/=?^_`{|}~;

• dot ., provided that it is not the first or last character unless quoted, and provided also that it does not appear consecutively unless quoted (e.g. [email protected] is not allowed but "John..Doe"@example.com is allowed);

Note that some mail servers wildcard local parts, typically the characters following a plus and less often the characters following a minus, so fred+bah@domain and fred+foo@domain might end up in the same inbox as fred+@Domain or even as fred@domain. This can be useful for tagging emails for sorting, see below, and for spam control. Braces { and } are also used in that fashion, although less often.

• space and "(),:;<>@[] characters are allowed with restrictions (they are only allowed inside a quoted string, as described in the paragraph below, and in addition, a backslash or double-quote must be preceded by a backslash);
• comments are allowed with parentheses at either end of the local-part; e.g. john.smith(comment)@example.com and (comment)[email protected] are both equivalent to [email protected].

In addition to the above ASCII characters, international characters above U+007F, encoded as [[UTF-8]], are permitted by RFC 6531, though even mail systems that support SMTPUTF8 and 8BITMIME may restrict which characters to use when assigning local-parts.

Domain

The [[domain name]] part of an email address has to conform to strict guidelines: it must match the requirements for a [[hostname]], a list of dot-separated [[DNS]] labels, each label being limited to a length of 63 characters and consisting of:{{rp|§2}}

• uppercase and lowercase [[Basic Latin (Unicode block)|Latin]] letters A to Z and a to z;
• digits 0 to 9, provided that top-level domain names are not all-numeric;
• hyphen -, provided that it is not the first or last character.
  This rule is known as the ''LDH rule'' (letters, digits, hyphen). In addition, the domain may be an [[IP address]] literal, surrounded by square brackets [], such as jsmith@[192.168.2.1] or jsmith@[IPv6:2001:db8::1], although this is rarely seen except in [[email spam]]. [[Internationalized domain name]]s (which are encoded to comply with the requirements for a [[hostname]]) allow for presentation of non-ASCII domains. In mail systems compliant with RFC 6531 and RFC 6532 an email address may be encoded as [[UTF-8]], both a local-part as well as a domain name.

Comments are allowed in the domain as well as in the local-part; for example, john.smith@(comment)example.com and [email protected](comment) are equivalent to [email protected].

Examples

Valid email addresses

• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected] (may go to [email protected] inbox depending on mail server)
• [email protected] (one-letter local-part)
• "very.(),:;<>[]".VERY."very@\ "very".unusual"@strange.example.com
• [email protected]
• admin@mailserver1 (local domain name with no [[Top-level domain|TLD]], although ICANN [https://www.icann.org/news/announcement-2013-08-30-en highly discourages] dotless email addresses)
• #!$%&'*+-/=?^_`{}|[email protected]
• "()<>[]:,;@\"!#$%&'-/=?^_`{}| ~.a"@example.org
• [email protected] (see the [[List of Internet top-level domains]])
• user@[2001:DB8::1]
• " "@example.org (space between the quotes)

Invalid email addresses

• Abc.example.com (no @ character)
• A@b@[email protected] (only one @ is allowed outside quotation marks)
• a"b(c)d,e:f;gi[j\k][email protected] (none of the special characters in this local-part are allowed outside quotation marks)
• just"not"[email protected] (quoted strings must be dot separated or the only element making up the local-part)
• this is"not\[email protected] (spaces, quotes, and backslashes may only exist when within quoted strings and preceded by a backslash)
• this\ still"not\[email protected] (even if escaped (preceded by a backslash), spaces, quotes, and backslashes must still be contained by quotes)
• 1234567890123456789012345678901234567890123456789012345678901234+x@example.com (local part is longer than 64 characters)
• [email protected] (double dot before @)
• [email protected] (double dot after @)

Add to root README.md all packages/programs/etc to install for new Shift3 Windows users.

It would be cool to have a one-stop place for setting up CI with CircleCI for various environments. This includes:

• React Native (with expo)
• React Native (CRNA)
• Angular

Feel free to add more!

Add a .md file for code reviews

Remove dupe files and folders and reorganize to make sense

We need documentation in client-side/security for:

• JWT
• Passport
• Encryption

Add documentation for:

• Deploying to Test Flight for development
• Setting up a Developer account for Apple
• Setting up an iTunes Connect account
• Creating provisioning Profiles and certificates
• Deploying to App Store for production
• Registering a physical device with Xcode for local development

Add something to the client JS md file for standards

@TomAlperin @mwallert @dunlavy @carlosvargas Please do a quick write up on the benefits of each of these and your suggestions on which to use at Shift3

ESLint, TSLint, any other linters for other technology stacks we have.

Write docs for setting up Normalize

Update the docs for MongoDB to utilize Atlas and update security to reflect current versions

Write docs for setting up:

• Postgres
• MSSQL
• MySql

Some links are broken so let;'s make sure they work!

Add standards for how Shift3 uses the Angular CLI for our projects.

Docker and Kubernetes both deal with the containerizing of applications.

Official docs:

Docker

Kubernetes

Firebase is a schema-less database, created and maintained by Google. It runs Mongo on the backend, but that's not how we interface with it. It's really nice for small applications to medium applications, but doesn't scale all that well. Thanks, Mongo.

To maintain code uniformity across multiple projects and avoid common Javascript errors while working, ESLint is an invaluable tool. The tooling and support built around the open-source checker is some of the best in the JS community.

I'm not sure how commonly Docker is being used in current development projects at Shift3, but it seems like it's picking up steam. I know the current cohort is planning on using it for the credit union app. It also seems like there's only a handful of developers in the building that have a good grasp on it.

Docker's own documentation isn't very good, so this seems like it could be beneficial for everyone. Any thoughts? I wouldn't mind doing a first draft of some common Docker commands and Docker file setup if you like.

In the server-side/frameworks/Node and server-side/frameworks/python README.md files we need to link to the subfolders' README.md files.

I had written a script a few months ago that would set up the Cloudfront infrastructure needed to deploy an application (see #79). I'm creating this task so that I clean up the script and upload it to the repo.

Add documentation for:

• Cutting an APK for client testing
• Setting up a Developer account for Google Play
• Deploying to Google Play Store for production
• Setting up Android Studio with physical devices and virtual devices

Add the information into how to set up Continuous Integration for each application.

Add file structure for React Native and all it's component peices

Add documentation and resources from the application security class.

Topics:

• Introduction to Secure Software Development Cycle
• SQL Injection
• MongoDb Query Injection
• Cross Site Scripting (XSS)
• Cross Site Request Forgery (CSRF)
• Session hijacking / session replay
• User Data Sanitization
• Cross-Origin Resource Sharing (CORS)
• Content Security Policy (CSP)
• Passwords and Validation
• Authorization (tokens, cookies, etc)
• Authentication (User roles and permissions)
• Cryptography (Encryption, Hashing, etc)
• Error Handling
• Auditing and Logging
• Setting up SSL
• Handling Sensitive Data

Tools:

• Kali Linux
  • WPScan
  • nmap
• Wireshark
• Postman
• Postico

Getting an app setup in Android or Apple for internal and external testing takes Herculean effort. We should document this process on each platform. Screenshots would definitely be a plus, given how difficult both developer consoles are to navigate. Finally, adding a place for gotchas would be great (such as subscriptions not being available in iOS for testing if the client hasn't signed their tax agreement yet).

For our APIs here at Shift3

I would like to propose a new Shift3 rule: If you add code that is a workaround, you should include a comment which explains why it's there, and links to an official Github issue.

We have an example in our Normalize app, where navigation doesn't work correctly when simultaneously closing a modal window. Under this rule, all instances of the workaround would look something like this:

// This is a workaround for a navigation issue when closing a modal:
// https://github.com/NativeScript/nativescript-angular/issues/1380 
return setTimeout(() => Helpers.getRoute("badges", this.router), 50);

This will avoid confusion during code review and during future maintenance. This also documents the issue, so the workaround reasoning is not forgotten in the future.

With info related to giving props/explanations for workarounds in code

There's no doubt mobile navigation is a huge deal. Most of the time, there seems to be a lack of support, or perhaps more properly put, mobile browsers are having a hard time keeping up with modern technologies. Perhaps this could be a discussion of polyfills, frontend framework support, CSS attribute prefixing provided by caniuse, or even CSS variable support for that matter.

basic spin-up guide for node.js as a server.

How do we do search in our different servers/DBs? Let's add some docs!

• Ryeker will take MongoDB

We need a basic .md for:

• Installing ng globally
• Spin up Angular projects
• Creating builds
• Deploy to staging
• Deploying to production

For basic spin up. How do we do this at Shift3?

It works a lot like React, but feels about half the size, and works about half the size. It's a pretty popular framework to use with Laravel stacks.

Also, it's pronounced like "view", Micheal Wallert. Not like "Voo" 😏

Add S3 standards for writing CSS precompilers

Update front page to make repo more accessible. Refactor structure to make it more approachable.

Hey everyone, I'd love to contribute to something open source like this, but in it's current state it's hard to know where to begin since I don't work for Bitwise/Shift3.

I'm thinking the root readme could be updated with a linked article on how to contribute to this repo specifically. A simplified version of Ryeker's contributing doc or Corey's current PR.

It should also have a section for how and when to submit issues, and maybe a brief code of conduct.

Finally, there's a few broken markdown styles that could be fixed. Spaces needed between hashtag and headers to display properly, and the markdown cheat sheet link can be shortened.

In our repo we have a client-side/javascript doc that needs some contributions. Ideally we will link to the Google JS standards and all of us together will create a style guide for how we write JS.

When delivering a site (or API) to a client there are a common set of things that should be gathered and checked: Various credentials or keys are needed to properly configure services before delivery, a test request to the site using the desired domain name before switching DNS, setting certain environment variables to production, etc.

Ideally we provide a documented template to be copied to an individual project.

a listing of topics

Taken from notes from @FlavioShift3 's presentation

Let's do this!

PLEASE CHANGE THE "Tags" TO LABELS

Write a markdown for basic Ruby spin up at shift3

I think it would be a great idea to drill down some backend frameworks that are not only modern, but also provide an education to further develop the skills of each developer. Some frameworks that come to mind...

Ruby

- Rails

Python

- Django

Node

- Hapi
- Express
- Koa
- MEAN

Anyone can get a Ruby education by building a small Jekyll site for a gh-pages. Django will be a sinch to learn, especially if taught by @dmpayton. Node, unfortunately offers many solutions, but are wonderful to learn, no doubt. Hapi is a framework I'm particularly fond of, and have worked with a buddy to develop our own simple REST API that is not only easy to extend, but has user auth built right in. Express is incredibly common to use. While I have my opinions against Express, it does prove to be a great framework for getting APIs up and running with little learning curve and extensive functionality, and is perfect for any team project, and I'm happy to use this on another project. Koa is an evolution of Express that uses generator functions for its middleware stack (see here). MEAN stacks, we teach in Geekwise, and is widely adopted. That's really all I can say about that.