Не являюсь разработчиком Яндекса, но несколько раз принимал участие в их собеседованиях. И сейчас уже дважды приходило письмо о приглашении работать в яндекс.практикуме, в качестве код-ревьювера, возможны и другие вакансии (автор курса, преподаватель). Так что, возможно, что проблема не в яндексе — как преподавателе, а в яндексе — как органе управления образовательным центром и некомпетентном подборе персонала.
Знаю, что статья по большей части техническая и хотелось бы узнать больше про то, как это все внедрить и донести необходимость этих действий до начальства и других разработчиков.
Занимаемся проектной деятельностью. На одном проекте добавил проверку linter-ом и форматирование prettier-ом на pre-commit, чтобы никто не мог плохого закоммитить. Но после моего ухода с проекта, команда «забила» на такую штуку и не стала переносить его дальше на другие проекты, даже не смотря на то, что ощущали плюсы данных настроек и перенос конфигов с одного проекта на другой занял бы максимум 20 минут.
Мне кажется, что это самый гуманный подход к изучению кошки. Не надо мучить кошку и кучу раз кидать ее заставляя встать на лапы. А виртуальную кошку можно кидать как угодно.
Таблица классная, но, как выразиилсь до меня: досрочные платежи — очень важно. Сам считал досрочные платежи в течении нескольких месяцев, чтобы меньше переплачивать и быстрее выплатить. А график — очень нужная штука, правда привычнее смотреть на график платежей, к которому прикрутить дополнительные выплаты на страховки и т.д. (если такое возможно уместить в одном графике красиво и удобно для восприятия)
Работал на проекте, делал модуль на JS, а спустя половину реализации, весь проект перевели на TS. К счастью VueJS достаточно умный (умнее чем тот, кто переводит проект в процессе разработки на другой язык) и я смог дописать свой модуль на JS-е, и ничего не сломалось.
«7 рекомендаций по повышению надёжности JavaScript-кода» — рекомендация «Используйте Typescript». Это разные языки программирования, хоть они и реализуют один стандарт, но все же формально разные языки. Довольно странно давать такой совет.
Как веб разработчик часто сталкиваюсь с тем, что по запросу angular, приходится минусовать angularJs (совсем разные технологии), а часто гугл любит подсовывать еще и jQuery, Vue или React. Согласен, что легче учить какую-либо технологию легче на родном языке, но практика показывает, что на английском языке всегда больше документации и она содержит больше необходимых данных.
Неплохо было бы еще статью разнообразить правилами для поиска, не все с ними знакомы. Например, ставить минус для исключения лишних тем:
Пример запроса: развернуть двунаправленный список c# -python (из поиска исключаться запросы для python)
И поисковый запрос даст больше полезной информации, если вводить его на английском.
Конструкции некоторых почтовых ящиков можно рассмотреть как стек (если ящик имеет горизонтальную ориентацию), и следовательно можно вычислить письмо по порядку. Разве что если террорист бросит два письма, но это скорее исключение.
Дальше, наверное, можно отказаться от Gmail и остальных иностранных почтовиков, так как это заграничная компания, и можно будет пользоваться только почтой от российских компаний (импортозамещение). Где-то уже появлялись имена почты на кириллице — видимо это будет следующий шаг.
Напоминает собеседование в одну известную компанию, когда довольно плотно спрашивали про свойство arguments, хотя при этом экзаменатор сам признался, что использовал его пару раз и это было 1,5 года назад. Хотя были и положительные моменты, например, при первом скайп-собеседовании завалил теорию почти полностью, но за счет того, что нужно было решать задачи и писать код смог пройти это собеседование. Кажется, что все эти задачи зависят не только от компании, но и от собеседующего. А далеко не у всех собеседующих есть четкое понимание того, что обязательно должен знать и уметь разработчик, а что не обязательно.
Согласен, что нет серебряной пули, но просто хотел узнать, возможно есть какие-то best practices, которых желательно придерживаться и bad practices, которых лучше избегать или вовсе не стоит делать. Не смог найти источников, которые бы описывали какие-либо подходы по организации providers в angular.
Статья хорошая, но вот хотелось бы большего раскрытия про provideres. В статье говориться, что можно провайдить сервис в:
1. В корень
2. Модуль
3. Компонент
Тоже самое говориться и в документации ангуляра.
Вопрос собственно в том, как определить «потребности». Я считаю, что сервис, который используется во всем приложении, например сервис проверки прав пользователя или сервис работы с модальными окнами стоит провайдить в корень. Если в модуле есть несколько компонентов, которые используют один сервис, то стоит провайдить в модуль (например, компоненты для работы с какой-то сущностью и сервис, который предоставляет crud-методы). А если компонент получает данные из сервиса, который был реализован только для него или хранит в сервисе свое состояние, то стоит провайдить сервис в компонент.
Вопрос связан с тем, что в команде разработке резко решили, что нужно провайдить в корень и в компоненты. В результате получается, что в один момент может быть несколько инстансов одного и того же сервиса, хотя можно было сделать один провайдинг в модуль.
Можете ли подсказать что можно поизучать в данном направлении, а также насколько моя точка зрения близка к «идеальному» приложению или я совсем не прав
Возможно, хорошей альтернативой мог бы быть запуск маленьких «дронов», которые бы цеплялись к большим кускам космического мусора, и с помощью собственных двигателей смещали бы с орбиты, чтобы они возвращались на Землю, для дальнейшей переработки.
Занимаемся проектной деятельностью. На одном проекте добавил проверку linter-ом и форматирование prettier-ом на pre-commit, чтобы никто не мог плохого закоммитить. Но после моего ухода с проекта, команда «забила» на такую штуку и не стала переносить его дальше на другие проекты, даже не смотря на то, что ощущали плюсы данных настроек и перенос конфигов с одного проекта на другой занял бы максимум 20 минут.
Пример запроса: развернуть двунаправленный список c# -python (из поиска исключаться запросы для python)
И поисковый запрос даст больше полезной информации, если вводить его на английском.
1. В корень
2. Модуль
3. Компонент
Тоже самое говориться и в документации ангуляра.
Вопрос собственно в том, как определить «потребности». Я считаю, что сервис, который используется во всем приложении, например сервис проверки прав пользователя или сервис работы с модальными окнами стоит провайдить в корень. Если в модуле есть несколько компонентов, которые используют один сервис, то стоит провайдить в модуль (например, компоненты для работы с какой-то сущностью и сервис, который предоставляет crud-методы). А если компонент получает данные из сервиса, который был реализован только для него или хранит в сервисе свое состояние, то стоит провайдить сервис в компонент.
Вопрос связан с тем, что в команде разработке резко решили, что нужно провайдить в корень и в компоненты. В результате получается, что в один момент может быть несколько инстансов одного и того же сервиса, хотя можно было сделать один провайдинг в модуль.
Можете ли подсказать что можно поизучать в данном направлении, а также насколько моя точка зрения близка к «идеальному» приложению или я совсем не прав