shift3 / standards-and-practices Goto Github PK

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

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

• Ryeker will take MongoDB

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" 😏

PLEASE CHANGE THE "Tags" TO LABELS

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

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.

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

@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

Remove dupe files and folders and reorganize to make sense

Let's do this!

Add S3 standards for writing CSS precompilers

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.

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

Add something to the client JS md file for standards

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

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

a listing of topics

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

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

Write a markdown for basic Ruby spin up at shift3

Write docs for setting up:

• Postgres
• MSSQL
• MySql

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

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!

Write docs for setting up Normalize

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.

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

We need a basic .md for:

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

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.

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

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

Docker and Kubernetes both deal with the containerizing of applications.

Official docs:

Docker

Kubernetes

Add a .md file for code reviews

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.

Taken from notes from @FlavioShift3 's presentation

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

From Flavio's presentation

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

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.

We need documentation in client-side/security for:

• JWT
• Passport
• Encryption

For our APIs here at Shift3

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

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 @)

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.

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.

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).

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

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.

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.