Спасибо, теперь понятно!
То есть в вашем случае span id — это, скорее trace id. А в каким порядке они друг с другом связаны вы (как читатель логов) не знаете, но я предполагаю что это не так важно?
Вот вы генерируете request-id (aka span id), он потом идет в RabbitMQ например (уже с другим span id), потому идет в другой сервис via HTTP (с другим span id), etc., потом в одном из сервисов это падает с исключением которое вы видите в sentry/kibana. Как вы потом собираете эти отдельные несвязанные куски информации между собой? Jaeger/Zipkin/Google Trace/etc. собрали бы это в одну цепочку, а как вы это делаете с вашим набором инструментов?
Уважаемые МТС,
Прежде чем пытаться запрыгнуть на Хабр (опять?), давайте вы все-таки публично извинитесь, или напишете опровержение по поводу этой истории? Предлагаю написать прямо на Хабре например, как вам такая идея?
IT сообщество не такое тупое как вы думаете. Дальше мое личное мнение: мне по-прежнему непонятно почему люди должны идти работать в такую компанию. Вы же блог ради найма ведете, вот давайте — занимайтесь reputation management.
Споткнется она о тот самый шаринг знаний — на удаленке организовать его не так просто. Если в штате много новичков, процесс онбординга затянется на месяцы.
Ввести много новых людей в короткий срок — это конечно проблема/ошибка.
Но не понятно, при чем здесь удаленка? Онбордиг либо работает либо нет — какая разница в каком режиме?
Jest, JUnit, PHPUnit — вот примеры тестовых фреймворков.
Я не знаю, какой у вас опыт с автоматизированными тестами, но обычно тестовый фреймворк предоставляет возможность написать тест в виде кода, запустить этот тест и получить результат (бинарный — прошел тест или нет, или более сложный типа репорт по покрытию кода тестами). Т.к. TestRail хранит только текстовое описание теста, то требуется человек (или внешняя система) для его прохождения — это я имел в виду под фразой "TestRail не умеет выполнять тесты".
Боюсь что правильный ответ на вопрос выше: TestRail — это хранилище текстового описания тестов и хранилище репортов. Да, результаты могут быть запушены автоматически через API, но сам по себе TestRail не умеет выполнять тесты, и не является тестовым фреймворком.
Вся статья написана как «универсальный рецепт» с множеством оценочных суждений. Наводящие вопросы:
0) Где собственно решается проблема высоконагруженного проекта?
1) Почему не монолит? У него есть только недостатки? Он не может работать под нагрузкой?
2) Почему RoadRunner?
3) Почему ReactJS?
4) Почему выбор только между MySQL & PostgreSQL?
5) Почему вообще для frontend именно REST API (как насчет GraphQL например)?
6) Что там с service-to-service communication?
7) Почему CycleORM?
… т.п.
А что не так с первым примером? Там не показана позиция, но это вполне мог бы быть senior/team-lead/principal-engineer, в таком случае нет никаких претензий к вакансии:
1) Полный цикл разработки и сопровождения — разве это ненормально если человек участвует в обсуждении, планировании фичи, разработке и ее сопровождении? Только в таком случае он действительно может анализировать грабли которые были в имплементации или поддержке предыдущей похожей фичи.
2) Общение within technical group and with external parties — опять же, если работаешь с внешним аутсорсером или интегрируешь 3rd party solution, то конечно же необходимо с ними контактировать и поддерживать нормальные рабочие отношения, разве это завышенные требования?
3) Desire refactoring — а это что, плохо? Я бы вообще не нанимал людей которые не стремятся улучшать кодовую базу в своих кусках кода и вокруг.
Совсем вредные советы начались. Как же вы можете говорить что это не нагружает IO, если это делает не просто full scan, а в некоторых случаях полную выборку (включая прогон данных по сети) из таблицы? Этот код впринципе никогда не отработает на по-настоящему большой таблице если пользователь случайно нажмёт кнопку "последняя страница".
Иметь mixed хорошо для, скажем, code style automated verification: можно запретить не иметь type-hinting. Сейчас если нет type-hinting, то непонятно: или его забыли, или он mixed.
То есть в вашем случае span id — это, скорее trace id. А в каким порядке они друг с другом связаны вы (как читатель логов) не знаете, но я предполагаю что это не так важно?
Вот вы генерируете request-id (aka span id), он потом идет в RabbitMQ например (уже с другим span id), потому идет в другой сервис via HTTP (с другим span id), etc., потом в одном из сервисов это падает с исключением которое вы видите в sentry/kibana. Как вы потом собираете эти отдельные несвязанные куски информации между собой? Jaeger/Zipkin/Google Trace/etc. собрали бы это в одну цепочку, а как вы это делаете с вашим набором инструментов?
Прежде чем пытаться запрыгнуть на Хабр (опять?), давайте вы все-таки публично извинитесь, или напишете опровержение по поводу этой истории? Предлагаю написать прямо на Хабре например, как вам такая идея?
IT сообщество не такое тупое как вы думаете. Дальше мое личное мнение: мне по-прежнему непонятно почему люди должны идти работать в такую компанию. Вы же блог ради найма ведете, вот давайте — занимайтесь reputation management.
vs
vs
Попробуйте например так: https://frederic-hemberger.de/notes/kubernetes/manage-secrets-with-sops/
Так есть же масса приемов чтобы эти проблемы не испытывать:
Я и при личном контакте вижу митинги где люди прокоастинируют, отвлекаются, или фокусируются но все равно ничего не понимают.
Другими словами незрелость процессов в компании сглаживается личными контактами — я с этим не спорю. Но проблема здесь не в удалёнке.
А чем осложнено парное программирование при удаленной работе?
Ввести много новых людей в короткий срок — это конечно проблема/ошибка.
Но не понятно, при чем здесь удаленка? Онбордиг либо работает либо нет — какая разница в каком режиме?
Спасибо что написали. Статьи и выступления про неудачный опыт иногда полезнее рассказов про удачные решения.
Jest, JUnit, PHPUnit — вот примеры тестовых фреймворков.
Я не знаю, какой у вас опыт с автоматизированными тестами, но обычно тестовый фреймворк предоставляет возможность написать тест в виде кода, запустить этот тест и получить результат (бинарный — прошел тест или нет, или более сложный типа репорт по покрытию кода тестами). Т.к. TestRail хранит только текстовое описание теста, то требуется человек (или внешняя система) для его прохождения — это я имел в виду под фразой "TestRail не умеет выполнять тесты".
0) Где собственно решается проблема высоконагруженного проекта?
1) Почему не монолит? У него есть только недостатки? Он не может работать под нагрузкой?
2) Почему RoadRunner?
3) Почему ReactJS?
4) Почему выбор только между MySQL & PostgreSQL?
5) Почему вообще для frontend именно REST API (как насчет GraphQL например)?
6) Что там с service-to-service communication?
7) Почему CycleORM?
… т.п.
PS. ссылка на репозиторий выдает 404
А что не так с первым примером? Там не показана позиция, но это вполне мог бы быть senior/team-lead/principal-engineer, в таком случае нет никаких претензий к вакансии:
1) Полный цикл разработки и сопровождения — разве это ненормально если человек участвует в обсуждении, планировании фичи, разработке и ее сопровождении? Только в таком случае он действительно может анализировать грабли которые были в имплементации или поддержке предыдущей похожей фичи.
2) Общение within technical group and with external parties — опять же, если работаешь с внешним аутсорсером или интегрируешь 3rd party solution, то конечно же необходимо с ними контактировать и поддерживать нормальные рабочие отношения, разве это завышенные требования?
3) Desire refactoring — а это что, плохо? Я бы вообще не нанимал людей которые не стремятся улучшать кодовую базу в своих кусках кода и вокруг.
Вместо dead letter можно ещё рассмотреть https://github.com/rabbitmq/rabbitmq-delayed-message-exchange
В таком случае вы можете совсем избавиться от hatchery queues и использовать topic routing как полагается. Он правда:
Мы всерьез рассматривали его для production, но потом потребность исчезла.
Ну какой же это DevOps?
Совсем вредные советы начались. Как же вы можете говорить что это не нагружает IO, если это делает не просто full scan, а в некоторых случаях полную выборку (включая прогон данных по сети) из таблицы? Этот код впринципе никогда не отработает на по-настоящему большой таблице если пользователь случайно нажмёт кнопку "последняя страница".
APP_DEBUG=0
)