За всё время до увольнения у меня завестилось 11 RSU — это 44 550 рублей.
Раньше у Маркета и большого Яндекса был разный график ревью.
На свою D я вкалывал как проклятый по 7 дней в неделю, так как понимал, что основная проектная деятельность после закрытия Брингли никакого веса иметь не будет.
Гранта при приёме у меня не было. Что так можно, я тогда не знал.
Что касается ЗП, то по итогам года мне её проиндексировали на 5,33%, что в абсолютных цифрах чуть больше 10 тысяч рублей на руки. А затем Яндекс отменил компенсации за завтраки и полдники и сократил компенсации на обеды как раз на 10 тыс. Итого суммарно за год доход не вырос никак.
Извините, а какие ресурсы? Время разработчика, который пишет код на Java? Что мешает научить его писать кросплатформенный код?
И дело даже не в этом, а в честности и открытости. Можно же прямо сказать всем кандидатам при оформлении: "Ребята, мы поддерживаем только Линукс, берите его". Но этого нет
RSU имеют график вестинга, рассчитанный на 4 года. Это деньги, которые ты можешь получить сильно позже, если останешься работать в Компании. В первые 2 года работы RSU это больше пустышка.
Так не бывает. Микросервисы же. В случае инцидента невозможно сходу понять, в каком сервисе ошибка, и кто виноват. Это в любом случае ручная работа, даже если ты и твой код абсолютно не причем
Это ничего не стоит, если умеешь. Это чисто организационный момент.
А решает целый ряд проблем — и качество кода поднимает, и найм людей упрощает, когда каждый может выбрать себе ту систему, которая нравится
Да, стоит, Docker и Kubernetes работают не настолько хорошо, чтобы их можно было использовать в масштабах Яндекса.
Что мешает вкладываться в разработку open source проектов, вместо создания своих велосипедов? Это был риторический вопрос.
Это нормально если у вас production на Linux.
Нет, не нормально. Код нужно тестировать на разных платформах. И самое забавное, что делается это достаточно легко при наличии грамотной инфраструктуры.
Я за время работы в Яндексе отучился в ШАД вольнослушателем
Ага, и это по вечерам после работы. У меня так не получилось, потому что ещё есть семья
очень много зависит от команды и руководителя
И это печально, потому что кандидат со стороны про это знать не может. И выбрать что-то после 1-1,5 часов общения с руководителем тоже нереально
Да, уже на новой работе. Пока очень динамично — огромное количество новой информации.
Про Брингли, если честно, не хочется говорить. Я помню свой первый день в Яндексе, 05 марта 2019, как сидел в Мулен Руж (конференц-зал) и слушал про трансграничное направление Маркета. Уже тогда было понятно, что оно не полетит. Идея строилась вокруг брендированной одежды и обуви из Турции… Ну такое… Стоимость логистики + турецкий подход к бизнесу всё убили. А конкурировать с АлиЭкспресс на товарах из Китая нереально.
Рандомизация сиквенсов у нас есть, но не везде — пока что не оформили как системное решение. Можно начинать сиквенсы, например, с Integer.MAX_VALUE + 1. Это позволяет отловить баги, когда в связанных таблицах используются неправильные типы — int вместо bigint. Но тут есть и обратная сторона медали — человекочитаемость снижается, дебажить код не так удобно из-за больших чисел.
Из-за сиквенсов перестали беспокоиться, когда сделали нормальную ссылочную целостность.
Триггером стало изменение точности во внутреннем формате представления времени в Java 11.
А по факту, конечно, проблема в коде и тестах на него.
Таких проблем вообще много бывает. Как-то раз обновляли версию jdbc-драйвера для Постгреса. Тесты прошли, а в одном из окружений спринговый контекст не поднялся — приложение не смогло к БД подключиться. Оказалось, что на хостах нет нужных SSL-сертификатов, а раньше работало из-за баги в драйвере. Обновили драйвер, бага ушла — у нас всё сломалось.
Release notes нужно читать :)
Модули не пользуются популярностью, потому что примерно 80% всех Java проектов по-прежнему сидят на Java 8 (пруф).
Мы у себя вроде и перешли на Java 11, но клиенты и часть библиотек пока что всё равно Java8-совместимые. Сообщество слишком инертно… :(
1. Скорее всего удалять нужно уникальный индекс, но это не точно. В таких ситуациях лучше взглянуть на схему данных и её эволюцию (миграции).
2. Вот тут не понимаю, зачем нужен hash индекс. Выглядит так, что он не нужен.
По поводу where — можете создать issue с примером sql-скрипта для воспроизведения ошибки?
3. Постараюсь пояснить. Foreign key связывает 2 таблицы. Таблица, на которую ссылаются, обязана поддерживать ограничение уникальности на столбце внешнего ключа, и там точно будет индекс. А вот в связанной таблице индекс не обязателен.
Например, таблица order (id) и таблица order_item(id, order_id). order_item::order_id ссылается на order::id. Индекс на столбец order_item::order_id не требуется и по умолчанию не создаётся, но он будет очень нужен при удалении записей из order.
4. Здесь тоже попрошу завести issue с примером скрипта для воспроизведения ошибки.
5. Если использовать java-API, то есть перегруженные методы, которые работают с public-схемой.
6. Я оцениваю bloat в том числе и по абсолютному размеру. Для таблиц я бы рассматривал bloat больше 20% и больше 500 МБайт. Для индексов — больше 30% и 500 МБайт.
Но здесь многое зависит от размера вашей базы и профиля нагрузки.
Всё же уметь написать quick/merge sort и обойти дерево надо. Без этого нет смысла приходить на собеседование в Яндекс.
Правда есть другая проблема — это никоим образом не помогает в реальной работе. За год с небольшим всего один раз потребовалось придумать и закодировать действительно сложный алгоритм. 90% времени просто читаешь/пишешь в БД и шину.
За всё время до увольнения у меня завестилось 11 RSU — это 44 550 рублей.
Раньше у Маркета и большого Яндекса был разный график ревью.
На свою D я вкалывал как проклятый по 7 дней в неделю, так как понимал, что основная проектная деятельность после закрытия Брингли никакого веса иметь не будет.
Гранта при приёме у меня не было. Что так можно, я тогда не знал.
Что касается ЗП, то по итогам года мне её проиндексировали на 5,33%, что в абсолютных цифрах чуть больше 10 тысяч рублей на руки. А затем Яндекс отменил компенсации за завтраки и полдники и сократил компенсации на обеды как раз на 10 тыс.
Итого суммарно за год доход не вырос никак.
Извините, а какие ресурсы? Время разработчика, который пишет код на Java? Что мешает научить его писать кросплатформенный код?
И дело даже не в этом, а в честности и открытости. Можно же прямо сказать всем кандидатам при оформлении: "Ребята, мы поддерживаем только Линукс, берите его". Но этого нет
RSU имеют график вестинга, рассчитанный на 4 года. Это деньги, которые ты можешь получить сильно позже, если останешься работать в Компании. В первые 2 года работы RSU это больше пустышка.
Так не бывает. Микросервисы же. В случае инцидента невозможно сходу понять, в каком сервисе ошибка, и кто виноват. Это в любом случае ручная работа, даже если ты и твой код абсолютно не причем
Это ничего не стоит, если умеешь. Это чисто организационный момент.
А решает целый ряд проблем — и качество кода поднимает, и найм людей упрощает, когда каждый может выбрать себе ту систему, которая нравится
Что мешает вкладываться в разработку open source проектов, вместо создания своих велосипедов? Это был риторический вопрос.
Нет, не нормально. Код нужно тестировать на разных платформах. И самое забавное, что делается это достаточно легко при наличии грамотной инфраструктуры.
Ага, и это по вечерам после работы. У меня так не получилось, потому что ещё есть семья
И это печально, потому что кандидат со стороны про это знать не может. И выбрать что-то после 1-1,5 часов общения с руководителем тоже нереально
Да, уже на новой работе. Пока очень динамично — огромное количество новой информации.
Про Брингли, если честно, не хочется говорить. Я помню свой первый день в Яндексе, 05 марта 2019, как сидел в Мулен Руж (конференц-зал) и слушал про трансграничное направление Маркета. Уже тогда было понятно, что оно не полетит. Идея строилась вокруг брендированной одежды и обуви из Турции… Ну такое… Стоимость логистики + турецкий подход к бизнесу всё убили. А конкурировать с АлиЭкспресс на товарах из Китая нереально.
Рандомизация сиквенсов у нас есть, но не везде — пока что не оформили как системное решение. Можно начинать сиквенсы, например, с Integer.MAX_VALUE + 1. Это позволяет отловить баги, когда в связанных таблицах используются неправильные типы — int вместо bigint. Но тут есть и обратная сторона медали — человекочитаемость снижается, дебажить код не так удобно из-за больших чисел.
Из-за сиквенсов перестали беспокоиться, когда сделали нормальную ссылочную целостность.
А чек-поинты тюнили? Вдруг будет полезно Дорогой DELETE / Николай Самохвалов (Postgres.ai)
А по факту, конечно, проблема в коде и тестах на него.
Таких проблем вообще много бывает. Как-то раз обновляли версию jdbc-драйвера для Постгреса. Тесты прошли, а в одном из окружений спринговый контекст не поднялся — приложение не смогло к БД подключиться. Оказалось, что на хостах нет нужных SSL-сертификатов, а раньше работало из-за баги в драйвере. Обновили драйвер, бага ушла — у нас всё сломалось.
Release notes нужно читать :)
Я боюсь, что кто-нибудь скопирует это к себе as-is и начнёт использовать.
Мы у себя вроде и перешли на Java 11, но клиенты и часть библиотек пока что всё равно Java8-совместимые. Сообщество слишком инертно… :(
1. Скорее всего удалять нужно уникальный индекс, но это не точно. В таких ситуациях лучше взглянуть на схему данных и её эволюцию (миграции).
2. Вот тут не понимаю, зачем нужен hash индекс. Выглядит так, что он не нужен.
По поводу where — можете создать issue с примером sql-скрипта для воспроизведения ошибки?
3. Постараюсь пояснить. Foreign key связывает 2 таблицы. Таблица, на которую ссылаются, обязана поддерживать ограничение уникальности на столбце внешнего ключа, и там точно будет индекс. А вот в связанной таблице индекс не обязателен.
Например, таблица order (id) и таблица order_item(id, order_id). order_item::order_id ссылается на order::id. Индекс на столбец order_item::order_id не требуется и по умолчанию не создаётся, но он будет очень нужен при удалении записей из order.
4. Здесь тоже попрошу завести issue с примером скрипта для воспроизведения ошибки.
5. Если использовать java-API, то есть перегруженные методы, которые работают с public-схемой.
6. Я оцениваю bloat в том числе и по абсолютному размеру. Для таблиц я бы рассматривал bloat больше 20% и больше 500 МБайт. Для индексов — больше 30% и 500 МБайт.
Но здесь многое зависит от размера вашей базы и профиля нагрузки.
Правда есть другая проблема — это никоим образом не помогает в реальной работе. За год с небольшим всего один раз потребовалось придумать и закодировать действительно сложный алгоритм. 90% времени просто читаешь/пишешь в БД и шину.
Сам запрос вот тут