Скорее нет, чем да. Кажется, ни разу не сталкивался с тем, чтобы схема движения принципиально менялась на крупных развязках.
Понятно, что ответственность с водителя никто не снимает, но увидеть, например, что поворот с крайних двух полос, но эти полосы появляются только за 100 метров до перекрёстка - это удобно.
Будет ли что-нибудь сделано с тем, что в режиме навигации очень сложно (иногда невозможно) увидеть название улицы, по которой ты едешь, или на которую хочешь свернуть? При дефолтном масштабе названия не видно, при увеличении отрисовывается что угодно, кроме названия. Особенно это заметно на длинных улицах, которые приходится мотать туда-сюда в надежде найти незанятый кусок, на котором название всё-таки будет видно
Как ни странно, RnD задачи тоже можно и нужно оценивать. Не в терминах "я найду решение за 4 дня", а в терминах "мы готовы выделить на исследование 4 дня". Во втором случае по истечении этого времени должны быть зафиксированы промежуточные результаты и принято решение о продолжении или отказе от дальнейшего RnD. В противном случае такое исследование рискует превратиться в бесконечную задачу по итогам которой будет сказано: "не шмогла я".
Имхо, хороший индикатор накруток - обилие бессмысленных комментариев в стиле "спасибо, что раскрыли глаза", "очень полезно" и прочее капитанство в стиле GPT генератора, никак не отражающее суть статьи.
Итого, вы взяли сферу деятельности с низким порогом входа и обнаружили, что дешевле взять студента, который готов работать за еду, и быстро его обучить, чем сотрудника, который уже давно работает и всё ещё находится на этой базовой позиции. А потом решили экстраполировать это кликбейтным заголовком на всё айти (мы же на Хабре?).
За сбои и аварии не скажу, но заметно снизилась скорость создания и качество новых продуктов. Усилилось проникновение "ведущих разработчиков" от Сбера с опытом работы в полгода, особенно в нефинансовых сферах. Причём попадают они на действительно ведущие позиции, только ведут куда-то не туда.
Возможно, мы ещё не видим всех последствий, а начнём их замечать лет через 5-10.
Крайне странное и ничем не подтвержденное утверждение про то, что отношение роста джунов в мидлы составляет 1:30, а в синьоры - 1:100. Что, по-вашему, происходит со всеми этими людьми? Они уходят в Макдак?
Я не троллю, а реально хочу понять, хотя бы потому, что на первом этапе, по крайней мере, вижу конверсию примерно 1:1
Там не было пятитысячников, зато была такая же неподготовленность. Эта трагедия лишний раз подчёркивает, что без подготовки погибнуть можно даже в самых простых условиях, а двое инструкторов не способны организовать группу из 50 человек. Это никаким образом не оправдывает поход без подготовки в ещё более сложных условиях.
Моя статья показывает, как по мне, другую сторону таких походов.
Ваша статья показывает ровно то, что и происходит в таких походах: полную безответственность, неподготовленность и непонимание рисков.
Всё дело в том, что итоговый посыл вашей статьи воспринимается как: были трудности, но я справился и сходил на крутую вершину.
Тогда как здравомыслящий человек ожидает вывода: я по глупости пошёл на сложное восхождение неподготовленным и чуть не погиб. Больше никогда не буду так делать.
Возможно это поможет таким же новичкам как и я совершить свое первое восхождение, подскажет, как лучше спланировать поездку, подготовится к ней, избежать некоторых ошибок.
Единственное, чем может и должна помочь эта статья - привить читателю понимание, что невозможно безопасно сходить на Эльбрус имея за спиной 1 день снежно-ледовых занятий и неделю опыта спортивного туризма/альпинизма, не говоря о совершенно недостаточной акклиматизации и физподготовке.
Да, на Эльбрус в хорошую погоду можно забежать в кроссовках за 5-6 часов, но вот в случае наступления плохой погоды вам понадобится гораздо больше, чем просто кроссовки. А погода на вершине меняется ой как часто.
К сожалению, коммерческие туристы считают, что восхождение на Эльбрус - это такой же по сложности тур, как и поездка в Анталию, а туроператоры всячески поддерживают это заблуждение, но если в Анталии в случае возникновения проблем вы просто садитесь в кафе и ждёте пока оператор всё решит, то на высоте 5000 метров гид физически не способен спасти 6-7, а порой и 10+ паникующих людей без малейшей базовой подготовки. Более того, в сложных условиях гид и не будет их спасать, потому что его опыта как раз достаточно для того чтобы вернуться, а любые суды и разбирательства - куда лучшая перспектива, чем смерть.
Как вы отслеживаете ситуации, когда у вас новая версия сервиса применила миграции к бд, а старый сервис при этом перезапустился? Например, при а/б тестах.
В этом случае старый сервис получит дто, сгенерированный по новой схеме бд, и с некоторой вероятностью взорвётся.
Не соглашусь насчёт "логика течёт". Вы можете полностью изолировать логику работы с бд в слое репозиториев. Более того, можете навесить на репозитории интерфейсы и точечно ограничить применение тех или иных методов на уровне сервиса.
Единственный минус жука: мне не всегда подходят pojo, которые он генерирует, но эта проблема легко решается собственными dto и мапперами (бойлерплейт или контроль?). В жуке есть встроенный механизм для маппинга результата запроса буквально во что угодно. Таким образом, абсолютно всё, что касается работы с бд, не выходит дальше репозитория.
С этой точки зрения, жук, на мой взгляд, не отличается от других орм в части структурирования кода.
Больше года использую jooq. Пришёл к выводу, что наши запросы либо слишком простые, чтобы использовать jpa и hibernate, либо слишком сложные, чтобы использовать jpa и hibernate.
Что понравилось в жуке: в нём сильно меньше магии и конвенций, которые нужно изучать, плюс отличная документация и автор, который отвечает на вопросы на SO.
Сложилось впечатление, что всю статью можно сократить до "руководствуйтесь правилами английского языка при нейминге методов, переменных и прочих объектов".
Помню, в 19 году у Редмайна были огромные проблемы с производительностью при большом количестве кастомных полей в задачах, а также при большой глубине дерева задач.
Ещё и само дерево постоянно разваливалось и приходилось его перестраивать. Эти проблемы с тех пор были как-то решены?
Побывав в ряде продуктовых компаний из вашего списка в роли нанимающего, скажу, что one day offer устраивают не потому, что в компании никто не идёт - нет, поток кандидатов там реально бесконечен - а потому что на рынке нет квалифицированных специалистов.
В копилку "совпадений": после посещения сайта ПИК уже на следующий день мне начали звонить со словами "вы интересовались нашей недвижимостью". Обращались по ФИО. Номер телефона не то чтобы нигде не засвечен, но, думаю, не стоит подчёркивать, что никаких данных ПИКу я не оставлял.
Победит более быстрый маршрут. Регулярно приходится переключать предложенные маршруты, которые на 4 минуты быстрее, но на 15 км длиннее.
А после малейшего схода с маршрута - на заправку или в соседний переулок, маршрут снова перестраивается по длинному пути.
Скорее нет, чем да. Кажется, ни разу не сталкивался с тем, чтобы схема движения принципиально менялась на крупных развязках.
Понятно, что ответственность с водителя никто не снимает, но увидеть, например, что поворот с крайних двух полос, но эти полосы появляются только за 100 метров до перекрёстка - это удобно.
Будет ли что-нибудь сделано с тем, что в режиме навигации очень сложно (иногда невозможно) увидеть название улицы, по которой ты едешь, или на которую хочешь свернуть? При дефолтном масштабе названия не видно, при увеличении отрисовывается что угодно, кроме названия. Особенно это заметно на длинных улицах, которые приходится мотать туда-сюда в надежде найти незанятый кусок, на котором название всё-таки будет видно
Как ни странно, RnD задачи тоже можно и нужно оценивать. Не в терминах "я найду решение за 4 дня", а в терминах "мы готовы выделить на исследование 4 дня". Во втором случае по истечении этого времени должны быть зафиксированы промежуточные результаты и принято решение о продолжении или отказе от дальнейшего RnD. В противном случае такое исследование рискует превратиться в бесконечную задачу по итогам которой будет сказано: "не шмогла я".
Имхо, хороший индикатор накруток - обилие бессмысленных комментариев в стиле "спасибо, что раскрыли глаза", "очень полезно" и прочее капитанство в стиле GPT генератора, никак не отражающее суть статьи.
Ага, именно по этой причине найм мидл разработчика занимает по 3-4 месяца, а синьор QA - полгода.
Итого, вы взяли сферу деятельности с низким порогом входа и обнаружили, что дешевле взять студента, который готов работать за еду, и быстро его обучить, чем сотрудника, который уже давно работает и всё ещё находится на этой базовой позиции. А потом решили экстраполировать это кликбейтным заголовком на всё айти (мы же на Хабре?).
делЗа сбои и аварии не скажу, но заметно снизилась скорость создания и качество новых продуктов. Усилилось проникновение "ведущих разработчиков" от Сбера с опытом работы в полгода, особенно в нефинансовых сферах. Причём попадают они на действительно ведущие позиции, только ведут куда-то не туда.
Возможно, мы ещё не видим всех последствий, а начнём их замечать лет через 5-10.
Это что же, они придумали Maven? А вообще, интересно было бы попробовать. В императивном грейдле слишком просто выстрелить себе в ногу.
Крайне странное и ничем не подтвержденное утверждение про то, что отношение роста джунов в мидлы составляет 1:30, а в синьоры - 1:100. Что, по-вашему, происходит со всеми этими людьми? Они уходят в Макдак?
Я не троллю, а реально хочу понять, хотя бы потому, что на первом этапе, по крайней мере, вижу конверсию примерно 1:1
Там не было пятитысячников, зато была такая же неподготовленность. Эта трагедия лишний раз подчёркивает, что без подготовки погибнуть можно даже в самых простых условиях, а двое инструкторов не способны организовать группу из 50 человек. Это никаким образом не оправдывает поход без подготовки в ещё более сложных условиях.
Ваша статья показывает ровно то, что и происходит в таких походах: полную безответственность, неподготовленность и непонимание рисков.
Всё дело в том, что итоговый посыл вашей статьи воспринимается как: были трудности, но я справился и сходил на крутую вершину.
Тогда как здравомыслящий человек ожидает вывода: я по глупости пошёл на сложное восхождение неподготовленным и чуть не погиб. Больше никогда не буду так делать.
Единственное, чем может и должна помочь эта статья - привить читателю понимание, что невозможно безопасно сходить на Эльбрус имея за спиной 1 день снежно-ледовых занятий и неделю опыта спортивного туризма/альпинизма, не говоря о совершенно недостаточной акклиматизации и физподготовке.
Да, на Эльбрус в хорошую погоду можно забежать в кроссовках за 5-6 часов, но вот в случае наступления плохой погоды вам понадобится гораздо больше, чем просто кроссовки. А погода на вершине меняется ой как часто.
К сожалению, коммерческие туристы считают, что восхождение на Эльбрус - это такой же по сложности тур, как и поездка в Анталию, а туроператоры всячески поддерживают это заблуждение, но если в Анталии в случае возникновения проблем вы просто садитесь в кафе и ждёте пока оператор всё решит, то на высоте 5000 метров гид физически не способен спасти 6-7, а порой и 10+ паникующих людей без малейшей базовой подготовки. Более того, в сложных условиях гид и не будет их спасать, потому что его опыта как раз достаточно для того чтобы вернуться, а любые суды и разбирательства - куда лучшая перспектива, чем смерть.
Как вы отслеживаете ситуации, когда у вас новая версия сервиса применила миграции к бд, а старый сервис при этом перезапустился? Например, при а/б тестах.
В этом случае старый сервис получит дто, сгенерированный по новой схеме бд, и с некоторой вероятностью взорвётся.
Не соглашусь насчёт "логика течёт". Вы можете полностью изолировать логику работы с бд в слое репозиториев. Более того, можете навесить на репозитории интерфейсы и точечно ограничить применение тех или иных методов на уровне сервиса.
Единственный минус жука: мне не всегда подходят pojo, которые он генерирует, но эта проблема легко решается собственными dto и мапперами (бойлерплейт или контроль?). В жуке есть встроенный механизм для маппинга результата запроса буквально во что угодно. Таким образом, абсолютно всё, что касается работы с бд, не выходит дальше репозитория.
С этой точки зрения, жук, на мой взгляд, не отличается от других орм в части структурирования кода.
Больше года использую jooq. Пришёл к выводу, что наши запросы либо слишком простые, чтобы использовать jpa и hibernate, либо слишком сложные, чтобы использовать jpa и hibernate.
Что понравилось в жуке: в нём сильно меньше магии и конвенций, которые нужно изучать, плюс отличная документация и автор, который отвечает на вопросы на SO.
Сложилось впечатление, что всю статью можно сократить до "руководствуйтесь правилами английского языка при нейминге методов, переменных и прочих объектов".
Помню, в 19 году у Редмайна были огромные проблемы с производительностью при большом количестве кастомных полей в задачах, а также при большой глубине дерева задач.
Ещё и само дерево постоянно разваливалось и приходилось его перестраивать. Эти проблемы с тех пор были как-то решены?
Побывав в ряде продуктовых компаний из вашего списка в роли нанимающего, скажу, что one day offer устраивают не потому, что в компании никто не идёт - нет, поток кандидатов там реально бесконечен - а потому что на рынке нет квалифицированных специалистов.
В копилку "совпадений": после посещения сайта ПИК уже на следующий день мне начали звонить со словами "вы интересовались нашей недвижимостью". Обращались по ФИО. Номер телефона не то чтобы нигде не засвечен, но, думаю, не стоит подчёркивать, что никаких данных ПИКу я не оставлял.