Автор несколько раз упоминает «новую философию» и потом проносит это через комменты. И в этом, на мой взгляд, главная проблема этого сочинения. Ничего плохого в хранимках самих по себе нет, в простых кейсах, которые отписывает автор, тем более. Но давать этому идеологический контекст, вот это для меня звучит дико. Позиция «я пришёл, все переписал, стало зашибись, а раньше 2 года не могли» тоже, как по мне, выглядит так себе. Что вы там писали про проверку софт-скилов на интервью?
В рамках чего вы сюда добавили кадровые вопросы, уход старой команды вместе с техдиром не добавляет пунктов ни одной компании при найме новых сотрудников. И сильно сдаётся мне, что сначала технический директор вас покинул по доброй воле, а уже потом вы решили оптимизировать его позицию. А уж аргумент, что нужно чуть ли не записываться на приём к тех директору, в команде из 20 человек… )))
С технической точки зрения это статья про то, что сложные многоступенчатые запросы можно оптимизировать с использование хранимых процедур, а Postgres ещё и Json хорошо умеет. Вот так новость! Остальное напоминает комплекс превосходства. Печально такое читать на хабре, особенно про продукт, который некогда был очень хорошим!
Для крупных корпораций этот подход хорош почти всем. Это превращает процесс найма в конвейер, это дает одну «линейку», который можно сравнивать разных разработчиков. «Линейка» позволяет унифицировано определять ЗП, в том числе продавливать разработчиков на меньшие деньги, так как олимпиадными задачами на работе мало кто занимается, а значит шанс того, что ты решишь все задачи без возможности придраться к чему-либо, совсем мал. Этим, кстати, активно пользуется небезызвестная российская корпорация.
Вот что такой подход нормально сделать не позволяет, так это нанять людей с узким профилем. Узких профилей бывает много, чтобы стать профессионалом в некоторых нужно потратить годы. Тот же Google прямо говорит, что такие люди в большинстве случаев им не нужны, им нужны универсалы, способные потенциально работать в любой части корпорации, которых можно перераспределить в случае закрытия проекта и любой другой смене направления деятельности. Так как такие корпорации имеют тенденцию скупать технологически сложные перспективные стартапы, то есть определенный риск того, что покрыть узкие профили в этих проектах с таким подходом к найму им будет не просто. Поэтому разработчики, которые попали в корпорацию вместе с проектом и получают там космические ЗП, а если покидают компанию, то проект оказывается на грани забвения. Это создает редкие случаи, когда корпорация отступает от правил, и собеседует людей в индивидуальном порядке, еще часто и по рекомендации. Все остальные, если действительно хотят в Google, и чувствуют, что там им будет комфортно, к сожалению, должны научиться проходить фильтр.
Мне индифферентно, насколько крутые ребята работали и сколько в них вбухали денег
Если сравните как было до и как стало после, разница существенна. Понятно, что ошибки бывают, и рад, что вы умеете их исправлять сами :)
У меня вопрос, кстати, по рендерингу. Точнее, по сравнению скорости рендеринга metal с, внезапно, софтверным растеризатором (если antigrain еще остался) — он в сколько раз быстрее?
С софтверным не сравнивали, поскольку его не поддерживаем.
И метро уже перестало тормозить?
С Metal ускорился и рендеринг метро.
В общем, на мой взгляд, фичи — это немного другое.
Я понял, что вы подразумеваете под фичами. Жаль, что мы с вами здесь не совпадаем. Тем не менее, с Наступающим! Надеюсь, в следующем году порадуем вас фичами в вашем понимании :)
С точки зрения разработчика по поводу metal — проведена большая работа. Мои поздравления и уважение.
Спасибо :)
По поводу остального. Я могу прокомментировать задачи, связанные с рендерингом. За 5 прошедших лет их было очень много. А про самые значимые я писал посты здесь :) Мы переписали графический движок, добавили OpenGL ES 3.0, добавили 3Д-здания, анимации, перспективный режим в навигации, рендеринг пробок, рендеринг схемы метро, ночные стили карты, да, и обычные стили тоже изменились. Над стилями работали очень крутые ребята из Urbica. Прочитать об этом подробнее можно здесь medium.com/@Urbica.co/world-map-design-1a9711783333
Кроме этого был еще миллиард улучшений, которые не видны глазу, но которые повышали фпс и/или уменьшали расход батареи.
Таки что из этого является фичей-то, э?
А разве вышеобозначенное не фичи? :) Или таки утонули на фоне?)
Добавить MoltenVk будет точно легче, чем раньше, особую сложность будут представлять шейдеры на spir-v. Ну, и в целом это далеко не 5 минут.
Про баги. Когда вышел чип Mali-G72 в одном из устройств (не буду называть бренд и модель) мы очень радовались производительности приложения на нем, но был неприятный нюанс: приложение падало в режиме навигации где-то в недрах видеодрайвера. Все было странно, так как в других девайсах с этим чипом все работало как часы. А выяснилось следующее. У нас использовался общий вершинный буфер для рисования маршрута и навигационных стрелок. Рисовался он, очевидно, разными шейдерами, которые использовали разные атрибуты вершин. В свою очередь разработчики компилятора шейдеров перемудрили с оптимизацией и решили что помимо неиспользуемых uniform при компиляции шейдера можно выкинуть и неиспользумые атрибуты вершин, но забыли про смещение :) В итоге шейдер считал, что размер вершины меньше, чем на самом деле, и уже вторая вершина в буфере мапилась некорректно. У видеодрайвера срывало башню, так как со стороны API OpenGL все валидации тоже были пройдены, а размер вершины был другой, и он аварийно завершал приложение.
По пункту 1 ничего конкретного сказать не могу, а вот по пункту 2 уже в самых ближайших релизах появится одна очень крутая фича. Следите за обновлениями :)
Пробки очень часто меняются, особенно, в крупных городах. Когда вы едете на автомобиле вам обычно не интересно, что здесь по статистике 250 дней в году пробка, вам интересно сколько вам еще стоять и как быстрее объехать :) Пробки, к счастью или сожалению, нужны в реальном времени.
Автоматическое переключение работает только в режиме автонавигации, так как большинству пользователей, кто этим режимом не пользуется, автоматическое переключение может мешать.
Вопрос про отключение booking.com не является запрещенным и в разрез ни с чем не идет :) Однако, к теме данного поста не относится, поэтому, видимо, и был отклонен. Отключить нельзя.
В отличие от тех же GoogleMaps мы не используем серверные мощности для расчета маршрутов, а выполняем все вычисления на устройстве, чтобы это работало оффлайн. Поэтому на слабых устройствах маршруты могут строиться несколько дольше.
Мы совершенствуем наш роутинг в том числе и по производительности. Если последний раз пользовались приложением давно, попробуйте поставить последнюю версию.
Про пользователей ответ выше. Достаточно точны, чтобы использовать их для автонавигации. В отличие от двух других крупных российских сервисов наши пользователи распределены по всему миру, и мы можем показывать пробки во многих крупных туристических городах.
Автор несколько раз упоминает «новую философию» и потом проносит это через комменты. И в этом, на мой взгляд, главная проблема этого сочинения. Ничего плохого в хранимках самих по себе нет, в простых кейсах, которые отписывает автор, тем более. Но давать этому идеологический контекст, вот это для меня звучит дико. Позиция «я пришёл, все переписал, стало зашибись, а раньше 2 года не могли» тоже, как по мне, выглядит так себе. Что вы там писали про проверку софт-скилов на интервью?
В рамках чего вы сюда добавили кадровые вопросы, уход старой команды вместе с техдиром не добавляет пунктов ни одной компании при найме новых сотрудников. И сильно сдаётся мне, что сначала технический директор вас покинул по доброй воле, а уже потом вы решили оптимизировать его позицию. А уж аргумент, что нужно чуть ли не записываться на приём к тех директору, в команде из 20 человек… )))
С технической точки зрения это статья про то, что сложные многоступенчатые запросы можно оптимизировать с использование хранимых процедур, а Postgres ещё и Json хорошо умеет. Вот так новость! Остальное напоминает комплекс превосходства. Печально такое читать на хабре, особенно про продукт, который некогда был очень хорошим!
Вот что такой подход нормально сделать не позволяет, так это нанять людей с узким профилем. Узких профилей бывает много, чтобы стать профессионалом в некоторых нужно потратить годы. Тот же Google прямо говорит, что такие люди в большинстве случаев им не нужны, им нужны универсалы, способные потенциально работать в любой части корпорации, которых можно перераспределить в случае закрытия проекта и любой другой смене направления деятельности. Так как такие корпорации имеют тенденцию скупать технологически сложные перспективные стартапы, то есть определенный риск того, что покрыть узкие профили в этих проектах с таким подходом к найму им будет не просто. Поэтому разработчики, которые попали в корпорацию вместе с проектом и получают там космические ЗП, а если покидают компанию, то проект оказывается на грани забвения. Это создает редкие случаи, когда корпорация отступает от правил, и собеседует людей в индивидуальном порядке, еще часто и по рекомендации. Все остальные, если действительно хотят в Google, и чувствуют, что там им будет комфортно, к сожалению, должны научиться проходить фильтр.
Если сравните как было до и как стало после, разница существенна. Понятно, что ошибки бывают, и рад, что вы умеете их исправлять сами :)
С софтверным не сравнивали, поскольку его не поддерживаем.
С Metal ускорился и рендеринг метро.
Я понял, что вы подразумеваете под фичами. Жаль, что мы с вами здесь не совпадаем. Тем не менее, с Наступающим! Надеюсь, в следующем году порадуем вас фичами в вашем понимании :)
Спасибо :)
По поводу остального. Я могу прокомментировать задачи, связанные с рендерингом. За 5 прошедших лет их было очень много. А про самые значимые я писал посты здесь :) Мы переписали графический движок, добавили OpenGL ES 3.0, добавили 3Д-здания, анимации, перспективный режим в навигации, рендеринг пробок, рендеринг схемы метро, ночные стили карты, да, и обычные стили тоже изменились. Над стилями работали очень крутые ребята из Urbica. Прочитать об этом подробнее можно здесь medium.com/@Urbica.co/world-map-design-1a9711783333
Кроме этого был еще миллиард улучшений, которые не видны глазу, но которые повышали фпс и/или уменьшали расход батареи.
А разве вышеобозначенное не фичи? :) Или таки утонули на фоне?)
Подробнее здесь: github.com/mapsme/omim/blob/master/drape/metal/metal_states.hpp
Про баги. Когда вышел чип Mali-G72 в одном из устройств (не буду называть бренд и модель) мы очень радовались производительности приложения на нем, но был неприятный нюанс: приложение падало в режиме навигации где-то в недрах видеодрайвера. Все было странно, так как в других девайсах с этим чипом все работало как часы. А выяснилось следующее. У нас использовался общий вершинный буфер для рисования маршрута и навигационных стрелок. Рисовался он, очевидно, разными шейдерами, которые использовали разные атрибуты вершин. В свою очередь разработчики компилятора шейдеров перемудрили с оптимизацией и решили что помимо неиспользуемых uniform при компиляции шейдера можно выкинуть и неиспользумые атрибуты вершин, но забыли про смещение :) В итоге шейдер считал, что размер вершины меньше, чем на самом деле, и уже вторая вершина в буфере мапилась некорректно. У видеодрайвера срывало башню, так как со стороны API OpenGL все валидации тоже были пройдены, а размер вершины был другой, и он аварийно завершал приложение.
По пункту 1 ничего конкретного сказать не могу, а вот по пункту 2 уже в самых ближайших релизах появится одна очень крутая фича. Следите за обновлениями :)
Определенными планами порадовать не можем, но все может быть)
Мы совершенствуем наш роутинг в том числе и по производительности. Если последний раз пользовались приложением давно, попробуйте поставить последнюю версию.