c-hive / guides Goto Github PK

https://stackoverflow.com/a/2667747/2771889

avoid seeding in migrations. if you change the model (e.g. add a mandatory field) old migrations will no longer work. either you'd have to update existing migrations, which is ill-advised ("In general, editing existing migrations is not a good idea." https://edgeguides.rubyonrails.org/active_record_migrations.html#changing-existing-migrations), or avoid db:migrate(:*) in favor of db:schema:load.

avoid bin/rails db:create db:migrate && bin/rails db:seed

e.g. if there's a non-optional relation added to an initializer that used to be optional before

Got some feedback about some parts resembling personal best practices. This is correct, e.g. looking at General / Way of Working / Development workflow: https://github.com/c-hive/guides/blob/master/universal/way-of-working.md#development-workflow

The guide should focus on things that should always be followed. Optional preferences, while good to have to help decision making, should be marked as such and should have less emphasis.

A guide on UI text / wording would be nice. I'd prefer that we find and re-use some exiting reputable guide. Would only start deciding on our own as a last resort because it's a fairly contentious topic.

E.g. whether to use sorry and please is usually a topic of discussion.

Sorry, something went wrong. Please try again later.

vs

Something went wrong. Try again later.

Other topics:

• capitalization of text
• tone
• pronouns
• etc

We ended up solving "Store CSS-in-JS styles in separate files" a bit differently. Let's update the guide.

Including:

• https://github.com/c-hive/guides/blob/master/react/way-of-working.md (no react-specific things though)
• https://github.com/c-hive/guides/blob/master/node/way-of-working.md
• vscode settings
  • https://code.visualstudio.com/docs/editor/extension-gallery#_workspace-recommended-extensions

https://github.com/facebook/prop-types

Investigate if this makes sense and add it if so. See also: https://medium.com/@sherryhsu/how-to-change-relative-paths-to-absolute-paths-for-imports-32ba6cce18a5

Originally created by @gomorizsolt

We often use node-fetch. It does seem axios is much more suitable for client- & and server-side promise-based requests. Looking at its configuration, it's highly customizable and has several advantages as opposed to the (built-in) fetch library, e.g.:

• supports cancel tokens
• a base url can be set so that each request is prefixed with it
• facilities error handling
• it's no longer needed to convert the response to json/text
• intercept requests & responses before they resolve/reject

We can also attach an adapter to axios so that the responses are cached in-memory for the given time(see #243).

e.g. webmock for ruby, nock.disableNetConnect() for js

Let's create a Firebase / Miscellaneous doc with best practices, including:

• https://gitlab.com/c-hive/firebase-paypal/merge_requests/3#note_172773804
• https://gitlab.com/c-hive/firebase-paypal/issues/4

Same format as https://github.com/c-hive/guides/blob/cefa90fdd6c8cec9ac87ef23cfc0871a7fdc5b7a/js/error-handling.md#best-practices-and-anti-patterns

@gomorizsolt could you take care of this?

Currently it's possible within a workflow using artifacts. Will be available natively mid-November. See: https://stackoverflow.com/a/57958803/2771889

See if current artifact version improves build speed and use it if so. Introduce native version once available.

So if I understand it correctly we should have the following stages and jobs:

stages:
  - verification
  - deploy

lint:
  stage: verification

test:
  stage: verification

apiary-validate:
  stage: verification

code-quality:
  stage: verification

heroku-deploy:
  stage: deploy

gl-pages-deploy:
  stage: deploy

apiary-deploy:
  stage: deploy

This would result in maximum parallelization while making sure deploys only run if verifications are successful.

It's an open question whether this is needed but if I remember correctly running FB functions locally is not that straightforward (1) and there could be additional best practices.

^(?!.*?([\.]{2,}?|[\_]{1,}?).*?)(?!(?:[\d\w]+?\.)?\-[\w\d\.\-]*?)(?![\w\d]+?\-\.(?:[\d\w\.\-]+?))(?=[\w\d])(?=[\w\d\.\-]*?\.+[\w\d\.\-]*?)(?![\w\d\.\-]{254})(?!(?:\.?[\w\d\-\.]*?[\w\d\-]{64,}?\.)+?)[\w\d\.\-]+?(?<![\w\d\-\.]*?\.[\d]+?)(?<=[\w\d\-]{2,}?)(?<![\w\d\-]{25})(?<![\-]{1,}?)$

It isn't obvious how to do it right: https://stackoverflow.com/questions/1479319/simplest-cleanest-way-to-implement-singleton-in-javascript

We're using the ES6 class approach but it would be better if we'd use .instance or .instance() to make the pattern obvious for readers. Also, when to freeze the object should also be clarified.

• https://github.com/mperham/sidekiq/wiki/Monitoring#rails-http-basic-auth-from-routes
• default to random values instead of relying solely on ENV

The investigation already started here; c-hive/team-contribution-calendar#19

Would be nice to reference some external guide though.

Here's how far I got:

You may be tasked to engage social media. E.g. addressing user feedback, raising awareness, doing market research, creating publications, etc.

Instead of managing company-accounts or other forms of public facades we encourage you as individuals to deliver the message with your own unique touch.

We stand behind your professionality but also mandate it. The account you're using for this purpose must project a professional persona.

I'm not very happy with the wording of the last part but couldn't come up with anything better. Ideas appreciated on the existing part as well as whether we should include something else?

The conclusion about ESM packages might be out of date, see: https://github.com/c-hive/guides/blob/8abdbaede12a1bdd66816927ca3f1e159d962bc8/js/package.md#esm

Initial notes:

Keep in mind caveats of first_or_create, find_or_create_by, first_or_initialize, find_or_initialize_by and upsert

where and first_or_* can be combined to be the same as find_or_*_by

User.where(name: "Roger").first_or_initialize == User.find_or_initialize_by(name: "Roger")
User.where(name: "Roger").first_or_create == User.find_or_create_by(name: "Roger")

The body only runs if the object is newly created

User.where(id: id).first_or_create! do |user|
  user.assign_attributes(attributes)
end

User.find_or_create_by!(id: id) do |user|
  user.assign_attributes(attributes)
end

User.where(id: id).first_or_initialize do |user|
  user.assign_attributes(attributes)
  user.save!
end

User.find_or_initialize_by(id: id) do |user|
  user.assign_attributes(attributes)
  user.save!
end

Passed attributes are only assigned if the object is newly created

User.where(id: id).first_or_create!(attributes)
User.where(id: id).first_or_initialize(attributes)

find_or_create_by(nil) will get the first entity while find_or_create_by(id: nil) will create a new one

User.find_or_create_by(nil) != User.find_or_create_by(id: nil)

Valid but broken?

User.where(id: id).find_or_initialize_by