iqhater

Gopher (гофер).

Используйте Scss + переменные + формулы и все возможные продвинутые фичи + cборшик.
https://sass-lang.com/documentation/syntax

Вот крутой видос по теме: https://www.youtube.com/watch?v=Mrq2ora_p0o и крутой канал по верстке, там и бем видосы есть, но бем не панацея как по мне...

Мощь SASS/SCSS и владение сборкой, хотябы gulp в идеале webpack.

+ Уйма удобных плагинов для верстки и копирования кода для vscode
BEM Helper
eCSStractor for VSCode
Live Sass Compiler

Сейчас просто с космической скоростью можно работать с SASS/SCSS

Дело не в Angular, а в том что такое интерфейс. Я расскажу со стороны моей практики.

Интерфейс это контракт взаимодействия между техническими сущностями (классы, объекты, функции, и так далее). Если мы создаем 10 объектов, которые соблюдают (реализуют) интерфейс, значит их можно подменять друг другом (только не нужно нарушать LSP, это принцип SOLID).

Так вот, отсюда есть мощные бонусы:

Первое, если создавать интерфейсы, то сущности начинают зависеть не друг от друга, а от интерфейса. Это значит что вместо зависимости одного класса от другого конкретного класса, можно использовать зависимость от интерфейса и любой класс реализующий интерфейс. Таким образом, если понадобится, можно спокойно заменить один класс на другой, если они реализуют один и тот же интерфейс. Это называется принцип инверсии зависимостей (один из принципов SOLID).

Выходит что сущности не завязываются друг на друга, и их можно разрабатывать независимо друг от друга, а в разработке чем меньше связей между классами/объектами, тем лучше. Если потом понадобится изменить код, поменять класс, будет значительно меньше проблем. Меньше, потому что если есть цепочка зависимостей, то нельзя изменить что-то одно, потому что другое сломается, и придется менять всю цепочку. Убирая прямые зависимости изменение кода становится проще.

Второе, это стабильность, лично для меня. Я работаю на TypeScript, и там можно описать интерфейс, сигнатуру функции, и ожидать на входе любые данные, которые его реализуют, и вообще пофигу откуда они, но пока они реализуют интерфейс, всё будет работать стабильно.

Третье, это понимание с чем ты работаешь. Когда есть интерфейс, ты всегда понимаешь что можно использовать у объекта, что там есть, и какого это типа. Просто очень удобно.

Ну и самое главное, лично для меня, это то, что мы инженеры, т.е. мы должны проектировать систему, а потом реализовывать, и интерфейс это один из наших "чертежей".

Ты сначала думаешь как оно будет работать, какие есть данные, потом описываешь это через интерфейсы, и прочее, а потом реализуешь. Поэтому можно считать что интерфейс это один из ключевых строительных блоков архитектуры приложения. Без него сущности будут пытаться дергать нужные им данные от объектов на входе, без понимания можно ли их вообще оттуда дергать, что там вообще реально есть, и в итоге получится хаос.

Поэтому Ангуляр собственно не причем, это просто фреймворк, а принципы проектирования там те же самые, как и в любом другом приложении.

Выполнение функции f() завершается после первого panic, потом отрабатывает defer.
Второй panic выполнен не будет, т.к. выполнение функции уже завершилось и до него очередь не дойдёт.
Можно добавить немного log.Println в ваш пример и проследить ход выполнения, например вот так

package main

import "log"

func f() {
  defer func() {
    if r := recover(); r != nil {
      log.Printf("recover:%#v", r)
    }
  }()
  log.Println("Start first panic")
  panic(1)
  log.Println("After first panic")
  panic(2)
  log.Println("After second panic")
}

func main() {
  f()
  log.Println("After f()")
}

Вывод будет таким

2020/07/20 23:14:07 Start first panic
2020/07/20 23:14:07 recover:1
2020/07/20 23:14:07 After f()

Хотят тут многое зависит от нужной анимации

• Если какой-то элемент нужно использовать больше одного раза — делайте отдельным компонентом
  
• Если ваш родительский компонент очень большой — разбейте его на несколько компонентов поменьше, чисто для удобства
  
• Если вы предполагаете, что какая-то часть вашей программы будет часто изменяться — выносите в отдельный модуль.
  
• Если у вам большой кусок статического контента — выносите в отдельный компонент
  
• Если какой-то элемент имеет в себе очень сложную или затратную по времени логику — выносите в отдельный компонент.
  

Вообще, я стараюсь делать много мелких компонентов. Мне так тупо удобнее. Но главное без фанатизма. Вам не нужен отдельный компонент на каждый инпут, разве что у этого инпута должна быть какая-то инкапсулированная логика или оформление.

Когда вы его получаете - это время его создания. Далее, перед оправкой находите разность между текущим временем и временем его создания.

А можно и не проверять время жизни токена. Просто если в ответе сервера получили ошибку -
if (err.response.status === токен экспайред ....
- получаете новый при помощи рефреш токена.

Это же все относительно. Кто-то работает быстрее кто-то медленнее. Это ваш темп, если вы помимо решения задач еще и будете грузиться скоростью - на пользу не пойдет. Ну зафейлили значит зафейлили, кто сказал, что сроки были корректные.

Возможно вам стоит обудмать зачем вы работаете, если нет глобальных целей (аля накопить денег на машину или построить дом) то сложнее заставить себя работать.

Это можно представить как аналогию с другими языками:
Классы
Namespace

Суть одна, сгруппировать код выполняющий одну задачу и отделить его от остального кода для удобства поддержки.
Например пакет net/http позволяет работать с http протоколом. encode/json, c json форматом и т.д.

Судя по приведённой в комментариях ссылке, там используется bearer-аутентификация.

Получив token после авторизации, передавайте его в заголовках запроса в виде:
Authorization: Bearer awesome-token-12345

Именно так сервер поймёт, от кого именно идет запрос
https://swagger.io/docs/specification/authenticati...

Если чисто для бота, то nginx не нужен.
Но аппетит приходит во время еды и в какой-то момент вы хотите отдать с сервера статику,
или завернуть трафик бота в https...

В чистом виде для http без статики вам не нужен nginx.
Ваш бот - это приложение или демон. Запускать можно через crontab с директивой @reboot. Или просто почитайте как принято демонизировать go-приложение.

Если чтоб и ребенок понял - то это такие правила, придуманные взрослыми дядями, если ты им будешь следовать то твой код будет хорошим, ты сможешь создать более сложную систему, меньше наговнякать и соседские пацаны, смотря как их мелкие проекты, вчера бывшие такими клевыми, вдруг превращаются в хаос и обитель зла, будут завидовать, смотря на то как ты лихо продолжаешь ваять свой проект все таким же красивым, и все девчонки захотят с тобой дружить.

Посмотреть детальнее, что за правила и как их выполнять можно в таком большом количестве мест в интернете что перепечатывание сюда будет порицаемо в любом приличном обществе.

Один момент - не все принципы одинаково полезны и применимы в веб-разработке, но знать и понимать их все в любом случае на пользу.

Это не самая верная классифкация, я бы сказал. Скорее всего, чьё-то убъективное мнение.

Язык программирования -- средство решения задач. Какие-то задачи можно решать эффективнее с использованием одного набора технологий, какие-то с использованием другого. Зависит это от многих критериев.

Как пример, относительно недано в Discord решили переписать часть кода на Rust с Go. Это не значит, что Rust лучше, а Go хуже. Ребята просто померили всё что им было нужно и приняли решение. Это не значит, что в схожей ситуации такое же решение сработает для другого проекта. Если интересно почитать, по вот ссылка.