Владимир Чернышев

Кстати, как оказалось, подобные симптомы не только у выгорания, но и рака мозга могут быть. Рекомендую делать МРТ головного мозга при первых признаках что что-то изменилось

Если проект не может себе позволить высококвалифицированного верстальщика(ов) или требования "лишь бы работало и пофиг, что куча тормозящего JS, там где можно было пару правил CSS написать", то фронтенд (JS/TS разработчик))может не знать вёрстку досконально. Если хотя бы одно условие не выполняется, то значит должен.

Можно. Покупаете курс и идёте работать тренйни с годик, потом джуном года три, потом миддлом года четыре. Потом можно курс пройти и подаваться на сеньора.

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

Грубо говоря, нужно знать как ломать барьеры между разработкой и эксплуатации.

Как по мне, то для старта вполне достаточно создать организацию на gitlab.com даже с бесплатным планом для хранения исходников, а остальное начинать использовать по мере возникновения проблем. Ну или сразу, если опыт есть и инвестиции во внедрение кажутся окупаемыми за разумный срок.

Может guthub.com сейчас тоже достойная альтернатива. Или полный пакет сервисов от Atlassian. Но гитлаб вы можете быстро и просто перенести на self-hosted сервер если понадобится, или сразу его поднять.

Как человек, постоянно забывающий логировать время в джире или делающий это задним числом и от фонаря, могу назвать следующии причины:
- не вижу смысла, ни разу не разбирали сколько был эстимейт и сколько заняло, а больше применения найти не могу
- достоверно это делать сложно, сложно даже достоверно статус задач поддерживать, (собственно на него и ориентируюсь, заполняя задним числом, но иногда откровенная лажа получается и тогда просто "рисуешь" правдоподобную картину)
- джира неудобный инструмент для этого, удобного вообще не нашёл

Советы, если это вам реально надо:
- автоматизируйте максимально, лучше всего ориентируясь на статусы задач в джире, обеспечив их достоверность (не допускать отсутствие активных задач, не допускать несколько активных задач одновременно, не допускать работу над "чужими" задачами и т. п.). Можно какого-то чат бота завести, который раз в час будет спрашивать "над какой задачей работаешь? "
- не просто объясните зачем это вам надо, а регулярно показывайте, что вы это используете для заявленных целей и заявленную пользу приносит, например на дэйли митингах разбирайте сколько часов команда отработала за прошедший день и выявляйте причины отклонений от плана

Чисто в теории можете попробовать slight - никакой установки.

Перейти на yarn. В плане установки зависимостей при наличии лок-файла он себя предсказуемей гораздо ведёт.

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

Очень часто от того, какой фрейм/библиотеки используется на фронте, зависит требования к тому в каком виде отдавать данные бэку, даже если он условно стандартный типа REST JSON. Одни фреймворки/либы легко позволяют фронтам преобразовывать данные к нужным им схемам, были бы данные, а другие нет, и фронты начинают требовать определённой, например, нормализованной, или наоборот. То же с отправкой данных на бэк.

Это не вспоминая про server side rendering, локализацию багов, декомпозицию бизнес-задач и т. п. Чем лучше бэкендер знает то, что происходит на фронте, тем больше эффективность команды в целом. Для фронтов это тоже верно.

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

Нормально спрашивать на собесе или особенно при получении тестового "это проверка кругозора из резюме или это проверка способности решать ваши реальные задачи?" и во втором случае говорить "извините, мне это совсем неинтересно, имеет смысл продолжать общение?"

Go или поковыряться с C# - вроде MS большой шаг в сторону кроссплатформенности сделала и теперь Windows не нужна. Но не уверен, что для веба это реально, вернее не уверен, что это удобно. Если второй пункт выберете, то с вас статья о результатах :)

Коротко: прокси создаётся внутри new, а должен оборачивать класс EmailParser

Веб-дизайн, Дмитрий Кирсанов

Добавлю к ответу Юрий:

Одна из основных вкусняшек Workflow в подобных компонентах/фреймворках/системах - это инверсия контроля над сущностями и прочими моделями. Клиент не изменяет статус сущности через условный сеттер setStatus('approved') с дополнительными сайд-эффектами, а осуществляет переход (действие, процесс) apply('approve'), одним из сайд-эффектов которого является изменение статуса. Вроде бы разница незначительная с технической точки зрения, но бизнес-заказчики обычно оперируют процессами, в которых задействованы сущности, а не операциями самих сущностей, они говорят "в результате подписания договора ему присваивается статус "действующий"", а не "присвоение договору статуса "действующий" означает что договор подписан". Когда их требование меняется на "в результате подписания договора ему присваивается статус "подписан" (которого раньше не было), а "действующий" присваивается когда менеджер его утвердит", то нам, разработчикам, значительно меньше приходится менять и чаще всего не код даже, а конфиги, код только дописывается, но не меняется, ну или меняется значительно в меньшей степени.

Доказательную базу чего? Использования? А зачем?

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

Посмотреть на "выписку со счёта" в Upwork, если по договору непонятно, что является вашим доходом. Если там только зачисление на 4500, то и указывать 4500. Если там зачисление на 5000 и удержание на 500, то указывать 5000. В первом случае Upwork обеспечил вам доход 4500, во втором обеспечил доход 5000 и взял 500 расходов.

Это если хотите спать спокойно, но готовы объяснить почему уплачено налогов с 5000, а поступило на счёт 4500 или того меньше.

Мало информации о том, что есть и чего хочется. Но в целом, микросервисы не предполагают асинхронности по умолчанию. Но даже с ней вроде всё выглядит легко:
1. Поднимаем сервис регистрации ботов на базе любого сервера очередей
2. Пользователи подписываются на сообщения о появления бота в их округе
3. Боты отправляют свои координаты на сервис, не дожидаясь ответа (он в принципе и не нужен)
4. Сервис уведомляет пользователей об интересующих их ботах.

Олдскульные cookies и современные storages