От личного автотранспорта столько вреда: - смертность в ДТП - загрязнение (и тут речь не только о бензине, шины и колодки стираются и вся эта пыль идёт в воздух, тоже масло и т.д.) - катострофическое психологическое воздействие на владельцев: в жизни многие хорошие люди, но за рулём становятся какими-то конченными ЧСВ - огромные площади заняты под парковки и дорожную инфраструктуру
А пользя в городе какая? Да никакая. Место их за городом, где они намного нужнее и создают гораздо меньше проблем.
Именно поэтому часто считаю разумным делать 2 задачи одновременно: одну чисто техническую, одну на подумать. Нет настроения или идей? Пишем простой код. Появилась какая-то идея? Начинаем творить...
В моём нынешнем понимании идеальный высокоуровневый компонент вообще не содержит ни стилей, ни css классов. А изоляция стилей для компонентов это такая база, без которой я не знаю как можно жить.
А вы точно инженеров ищите? Знает чего хочет, имеет планы на жизнь, открыт к общению и уверен в себе. Добавьте сюда машину-квартиру и получится объявление о поиске мужа.
Еще отдельно про вопросы кандидата на собеседовании: есть так много вопросов, которые хотелось бы задать - средняя ЗП в команде, количество уволенных/уволевшихся сотрудников за 1-3 года, средняя индексация ЗП за последние 1-3 года и т.п. Только Вы на них никогда честно не ответите.
Но это все-таки не входит в обязанности разработчика... Делать качественное review - да, подсказывать что-то - да, а вот нацеленно кого-то обучать - нет. Команда должно приходить сверху ~используй 20% времени на обучение нового сотрудника.
Про Kafka: Если вам приходит 1000000 запросов в секунду на создание объектов, то вы на backend-е задумываетесь о масштабировании и использовании Kafka или еще чего. На Фронте такого не бывает. при чем тут Кафка?
Про any: Какое отношение any имеет к событиям и Input/output я не знаю. Настройте себе linter чтобы ругался на все any и живите счастливо.
input/output vs events: input/output обеспечивают максимальную изолированность компонента - он тупой, он не знает ни про что, кроме Input и output, получает-отдаёт. В бибилотеках большинство компонент именно тупые - с ними просто работать, их просто понимать. Зачем компоненту кнопки, выпадающего списка или степпера нужно что-то еще для меня загадка. И да это может привести к длинной цепочке вызовов, и да иногда это заменяют на какой-то event-bus, и да это делают уже 10+ лет.
И да когда появляется необходимость в сложном состоянии приложения, может быть частичный переход от input-ов к локальным/глобальным сервисам хранящими observable, но вроде статья это вообще игнорирует, поэтому не углубляемся.
Про утечки памяти: ngOnInit у сервисов? А про необходимость отписки знают все, кто пишет на angular.
Про debounce: Если в нормальной команде для устранения циклический зависимостей кто-то попытается использовать debounce, он никогда не пройдёт code review. Т.к. это банально означает, что ты вообще не понимаешь что происходит.
Про modalService: ну это же просто &^%да - посмотри как реализованы модалки в Angular Material: dialog.open(UserProfileComponent,...) ну какой сервис тут будет на 1200 строк? Ну кто прописывает модалку в template компонента, который её открывает? Ну кому нужно вместо прямого вызова постить какой-то event?
Вы правы, Gzip на больших json-ах сработает еще лучше.
Я все пушу в remote в ветку с номером задачи, если надо могу 2 ветки сделать. Коммиты до создания mr ставлю какие хочу. И прекрано себя чувствую.
Надо учить не формулы, а понимать как они получаются.
Я умнее дельфина в 200 раз. Как вы считали? Мой уровень интеллекта / уровень интеллекта дельфина
От личного автотранспорта столько вреда:
- смертность в ДТП
- загрязнение (и тут речь не только о бензине, шины и колодки стираются и вся эта пыль идёт в воздух, тоже масло и т.д.)
- катострофическое психологическое воздействие на владельцев: в жизни многие хорошие люди, но за рулём становятся какими-то конченными ЧСВ
- огромные площади заняты под парковки и дорожную инфраструктуру
А пользя в городе какая? Да никакая. Место их за городом, где они намного нужнее и создают гораздо меньше проблем.
Именно поэтому часто считаю разумным делать 2 задачи одновременно: одну чисто техническую, одну на подумать. Нет настроения или идей? Пишем простой код. Появилась какая-то идея? Начинаем творить...
В моём нынешнем понимании идеальный высокоуровневый компонент вообще не содержит ни стилей, ни css классов. А изоляция стилей для компонентов это такая база, без которой я не знаю как можно жить.
А вы точно инженеров ищите? Знает чего хочет, имеет планы на жизнь, открыт к общению и уверен в себе. Добавьте сюда машину-квартиру и получится объявление о поиске мужа.
Еще отдельно про вопросы кандидата на собеседовании: есть так много вопросов, которые хотелось бы задать - средняя ЗП в команде, количество уволенных/уволевшихся сотрудников за 1-3 года, средняя индексация ЗП за последние 1-3 года и т.п. Только Вы на них никогда честно не ответите.
Но это все-таки не входит в обязанности разработчика... Делать качественное review - да, подсказывать что-то - да, а вот нацеленно кого-то обучать - нет. Команда должно приходить сверху ~используй 20% времени на обучение нового сотрудника.
Про Kafka: Если вам приходит 1000000 запросов в секунду на создание объектов, то вы на backend-е задумываетесь о масштабировании и использовании Kafka или еще чего. На Фронте такого не бывает. при чем тут Кафка?
Про any: Какое отношение any имеет к событиям и Input/output я не знаю. Настройте себе linter чтобы ругался на все any и живите счастливо.
input/output vs events: input/output обеспечивают максимальную изолированность компонента - он тупой, он не знает ни про что, кроме Input и output, получает-отдаёт. В бибилотеках большинство компонент именно тупые - с ними просто работать, их просто понимать. Зачем компоненту кнопки, выпадающего списка или степпера нужно что-то еще для меня загадка. И да это может привести к длинной цепочке вызовов, и да иногда это заменяют на какой-то event-bus, и да это делают уже 10+ лет.
И да когда появляется необходимость в сложном состоянии приложения, может быть частичный переход от input-ов к локальным/глобальным сервисам хранящими observable, но вроде статья это вообще игнорирует, поэтому не углубляемся.
Про утечки памяти: ngOnInit у сервисов? А про необходимость отписки знают все, кто пишет на angular.
Про debounce: Если в нормальной команде для устранения циклический зависимостей кто-то попытается использовать debounce, он никогда не пройдёт code review. Т.к. это банально означает, что ты вообще не понимаешь что происходит.
Про modalService: ну это же просто &^%да - посмотри как реализованы модалки в Angular Material:
dialog.open(UserProfileComponent,...)ну какой сервис тут будет на 1200 строк? Ну кто прописывает модалку в template компонента, который её открывает? Ну кому нужно вместо прямого вызова постить какой-то event?