В Shopify с 2025-го не нанимают разработчиков, которые не умеют работать с LLM. Так, для справки. Это уже базовый требуемый скилл на глобальном рынке, скоро и у нас так будет.
Не с "2025-го", а буквально месяц назад объявили, еще рано говорить о каких-то результатах. Плюс, где вы взяли, что это базовый требуемый скилл? Ни одна AI-компания, ни FAANG не требуют опыт с LLM, хотя казалось бы.
Для справки, что говорит Head of Engineering Shopify: 76% разработчиков используют copilot (т.е. чуть более продвинутый автокомплит), целых 25 принятых дополнений в день (почти 30 процентов!). Мммкей.
Интересно, кстати, что опенсорс-проекты компании часто являются хорошей рекламой для кандидатов. У меня один кандидат так и сказал: использовали вашу библиотеку для какого-то проекта, и решил податься, мол, возможно, не только из json в json перекладываете.
серьезный опыт продуктовой разработки, который нарабатывается в крупном опенсорсе
В опенсорсе как раз сложно получить нормальный опыт разработки, поскольку дедлайнов обычно нет, коллег тоже, а требования придумываешь сам. В худшем случае, надо просто подогнать под требования меинтейнера.
На обычной работе ты зачастую делаешь то, что нужно, а не то, что нравится.
Но выглядит как довольно узкий юзкейс: продюсер должен знать о консумер-группе, и поддерживается только одна группа. Возможно, проще будет какой-нибудь синхронный RPC использовать.
Идемпотентный продюсер работает только для одного и того же инстанса продюсера. Если у вас, к примеру, перезапустится сервис после отправки, но без отметки, что сообщение отправлено, то новый инстанс все равно пошлет это сообщение. В итоге на консумер, даже если он помечен как идемпотентный, придет 2 одинаковых сообщения.
когда у нас данные, для которых нужно обеспечить гарантию доставки, и при этом их считывание не идемпотентно. Например операции с платежными транзакциями.
Пожалуйста, не делайте обработку платежных транзакций без идемпотентности на уровне бизнес-логики :)
А потом с этими данными надо работать дальше - показать юзеру в удобном виде, с кучей доп. данных, скорее всего из других баз. Сделать выгрузку во всякие эксельки...
А это разве не "выгрузить данные в нужном формате из одной системы и загрузить в другую"?
Интересно, что никто не написал, что надо уметь разбираться в новых доменах. В конце-концов, деньги платят не за то, насколько элегантные запросы можешь составить, или насколько у тебя чистый код, а за решение бизнес-задач.
Это, скорее, проблемы собеседований. Меня однажды на собеседовании про джаву спросили вопрос о том, как себя ведет такой-то код на экзотичной легаси-архитектуре (какой-то HP пятнадцатилетней давности).
Самое бесполезное время, которое я проводил, - это оценка задач в сторипоинтах. Вся команда тратит час-полтора, чтобы все задачи оценить или в 3, или в 5, что все равно с потолка берется.
1 и так очевидно, 8 или разбивается, или совсем непонятно, а больше и не бывает.
Не с "2025-го", а буквально месяц назад объявили, еще рано говорить о каких-то результатах. Плюс, где вы взяли, что это базовый требуемый скилл? Ни одна AI-компания, ни FAANG не требуют опыт с LLM, хотя казалось бы.
Для справки, что говорит Head of Engineering Shopify: 76% разработчиков используют copilot (т.е. чуть более продвинутый автокомплит), целых 25 принятых дополнений в день (почти 30 процентов!). Мммкей.
В 99% американских компаний вас будут гонять по алгоритмам.
Интересно, кстати, что опенсорс-проекты компании часто являются хорошей рекламой для кандидатов. У меня один кандидат так и сказал: использовали вашу библиотеку для какого-то проекта, и решил податься, мол, возможно, не только из json в json перекладываете.
В опенсорсе как раз сложно получить нормальный опыт разработки, поскольку дедлайнов обычно нет, коллег тоже, а требования придумываешь сам. В худшем случае, надо просто подогнать под требования меинтейнера.
На обычной работе ты зачастую делаешь то, что нужно, а не то, что нравится.
Вижу jooq - всегда плюсую.
Насколько сложно было переписать код, чтобы он правильно реагировал на исключения, бросаемые из-за ретраев?
Не знал о таком, спасибо!
Но выглядит как довольно узкий юзкейс: продюсер должен знать о консумер-группе, и поддерживается только одна группа. Возможно, проще будет какой-нибудь синхронный RPC использовать.
Что вы имеете в виду? Как продюсер с консумером могут синхронизировать запись?
"Много" в рекомендациях Confluent - это 10к на брокера и 200к на кластер, включая и обычные партиции, и их реплики.
Можно сразу сделать больше партиций, если у вас в целом топиков-партиций на кластере не очень много, то хоть 50 партиций сразу ставьте.
Идемпотентный продюсер работает только для одного и того же инстанса продюсера. Если у вас, к примеру, перезапустится сервис после отправки, но без отметки, что сообщение отправлено, то новый инстанс все равно пошлет это сообщение. В итоге на консумер, даже если он помечен как идемпотентный, придет 2 одинаковых сообщения.
Пожалуйста, не делайте обработку платежных транзакций без идемпотентности на уровне бизнес-логики :)
Тут двухэтапная проверка. Сначала на самом устройстве можно проверить, и показать какой-то экран, что аппка установлена неправильно.
Потом токен, который вернул integrity api, посылается на бекенд, и на бекенде можно отклонить запрос, если токен невалидный.
А это разве не "выгрузить данные в нужном формате из одной системы и загрузить в другую"?
Интересно, что никто не написал, что надо уметь разбираться в новых доменах. В конце-концов, деньги платят не за то, насколько элегантные запросы можешь составить, или насколько у тебя чистый код, а за решение бизнес-задач.
Диалект как раз не важен, если ORM используется. А знать надо, возможно, чтобы уметь индексы правильно накидывать?
Плюс, первая "проблема" json является проблемой xml: в json есть разница между числами и строками, а в xml как раз-таки нет.
Это, скорее, проблемы собеседований. Меня однажды на собеседовании про джаву спросили вопрос о том, как себя ведет такой-то код на экзотичной легаси-архитектуре (какой-то HP пятнадцатилетней давности).
Самое бесполезное время, которое я проводил, - это оценка задач в сторипоинтах. Вся команда тратит час-полтора, чтобы все задачи оценить или в 3, или в 5, что все равно с потолка берется.
1 и так очевидно, 8 или разбивается, или совсем непонятно, а больше и не бывает.
Так как измерить-то?
Подарки тоже часто подлежат налогообложению, прям много передать детям тоже не получится.