Предисловие: этот пост представляет собой очень длинный перечень мыслей и проблем, возникавших у меня за годы работы; также в нём рассматриваются некоторые из аргументов, которые мне часто говорили. В посте выражено моё мнение, сформировавшееся у меня в процессе разработки игр на Rust в течение многих тысяч часов на протяжении многих лет и после множества завершённых игр. Это не хвастовство и не показатель успеха, я просто хочу сказать, что вложил достаточно много усилий в Rust; здесь не получится сказать «когда наберёшься опыта, тебе всё станет понятно».

Пост не будет ни научной оценкой, ни A/B-исследованием. Это моё личное мнение после разработки игр на Rust маленькой инди-командой (два человека) в попытках заработать достаточно денег, чтобы финансировать процесс. Мы не одни из тех разработчиков с бесконечными финансами от инвестора и многолетним запасом времени. Если вы находитесь в этой категории и получаете удовольствие от многолетней разработки систем, то всё написанное ниже к вам не относится. Я рассматриваю всё с такой точки зрения: «Мне хочется создать игру максимум за 3-12 месяцев, чтобы люди могли сыграть в неё, а я — немного заработать». Статья не написана с точки зрения «Я хочу изучить Rust, а разработка игр — это весело», хотя это и вполне нормальная цель; просто она никак не согласуется с тем, чего хотим мы — заниматься разработкой игр коммерчески успешным и самодостаточным образом.

Мы выпустили несколько игр на Rust, Godot, Unity и Unreal Engine, и многие люди сыграли в них в Steam. Мы создали с нуля собственный игровой 2D-движок с простым рендерером, а также в течение нескольких лет использовали Bevy и Macroquad во многих проектах, некоторые из которых были очень нетривиальными. Кроме того, я бэкенд-разработчик на полную ставку и пишу код на Rust. Этот пост — не какое-то поверхностное мнение после изучения нескольких туториалов или разработки небольшой игры для геймджема. За три с лишним года мы написали сильно больше ста тысяч строк кода на Rust.

Задача этого поста — развеять популярные и часто повторяемые аргументы. Но это всё-таки субъективное мнение; по большей части я написал пост, чтобы не объяснять снова и снова одно и то же. Пусть это будет справочный материал о том, почему мы, скорее всего, откажемся от Rust как от инструмента для разработки игр. Мы ни в коем случае не планируем прекращать создавать игры, просто не будем делать это на Rust.

Всем привет! Я реализовал, похоже, собственный алгоритм поиска кратчайшего пути с отрицательными ребрами графа.

Почему собственный? Я искал подобное решение, но не нашел, возможно, оно уже было реализовано, просто плохо поискал. Жду Нобелевскую премию =)

Додумался я до него путем модификации классического Дейкстры. Прошу адекватно отнестись к содержимому, ибо это моя первая статья, и, возможно, я ничего не придумывал и, вообще, этот алгоритм не работает вовсе (но по многочисленным тестам он работает правильно).

Привет, Хабр! На связи участница профессионального сообщества NTA Корсакова Елена.

Поиск аномалий в корпусе текстов является нетривиальной задачей, особенно если размечен набор данных только с аномальными текстами. При этом различия могут не бросаются в глаза — все тексты написаны на одном языке, да и стиль текстов схож: например, заявки, ошибочно попавшие не в ту очередь, нетипичные события в логах или письма от мошенников. В посте расскажу о решении данной задачи — одноклассовой классификация текстов, с помощью расхождения Кульбака—Лейблера.

В IT-индустрии сложилось настороженное отношение к продакт-менеджерам. Бывает, что руководители проекта до последнего оттягивают найм своего первого продакта. Или команды мечтают, чтобы у них вообще его не было. Давайте разберём причины такого отношения, ключевые цели продакт-менеджера, расскажем о важности клиентов в его работе и завершим мини-планом по развитию в профессии.

Здравствуйте, меня зовут Дмитрий Карловский и я... ради лулзов создал самый мемный фреймворк в индустрии.

Привет, Хабр. В этой статье я расскажу про своё видение работы с цветом при визуализации графиков. Буду показывать все на примерах — уверен, они вам понравятся.

Я покажу не только картинки было-стало, но и приведу примеры кода, а также объясню логику принятия решений: как использовать ту или иную палитру в конкретной задаче. И что самое главное, дам пошаговые советы, как сделать график логичнее и понятнее для заказчиков.

Меня зовут Саша, сейчас я работаю в Lamoda Tech старшим бизнес/дата-аналитиком. До этого я несколько лет был специалистом по данным в другой компании и регулярно представлял совету директоров анализ и прогноз физических и бизнес-показателей. Умение донести результаты исследования до заказчика, особенно если он не погружен в работу с данными — это важный аспект моей профессии. Надеюсь, моя статья с этим немного поможет.

Привет! Меня зовут Василий Землянов, я занимаюсь разработкой ML-инфраструктуры. Несколько лет я проработал в команде, которая делает споттер — специальную маленькую нейросетевую модельку, которая живёт в умных колонках Яндекса и ждёт от пользователя слова «Алиса». Одной из моих задач в этой команде была квантизация моделей. На пользовательских устройствах мало ресурсов, и мы решили, что за счёт квантизации сможем их сэкономить — так в итоге и вышло.

Потом я перешёл в команду YandexGPT. Вместо маленьких моделей я стал работать с очень крупными. Мне стало интересно, как устроена квантизация больших языковых моделей (LLM). Ещё меня очень впечатляли истории, где люди берут гигантские нейросети, квантизируют в 4 бита и умудряются запускать их на ноутбуках. Я решил разобраться, как это делается, и собрал материал на доклад для коллег и друзей. А потом пришла мысль поделиться знаниями с более широкой аудиторией, оформив их в статью. Так я и оказался на Хабре :)

Надеюсь, погружение в тему квантизации будет интересно как специалистам, так и энтузиастам в сфере обучения нейросетей. Я постарался написать статью, которую хотел бы прочитать сам, когда только начинал изучать, как заставить модели работать эффективнее. В ней мы подробно разберём, зачем нужна квантизация и в какой момент лучше всего квантизовать модель, а ещё рассмотрим разные типы данных и современные методы квантизации.

Несколько лет тому назад я опубликовал на Хабре статью под названием "Буддизм с точки зрения программиста". Этот пост имел огромную популярность, читатели приняли его с большой теплотой. До сих пор я часто получаю от людей сообщения с благодарными отзывами на него и рассказами о том, как после прочтения этого текста поменялись их взгляды на жизнь.

С тех пор многое в моей жизни изменилось. В чём-то я поменял свой взгляд на мир, в чём-то напротив убедился ещё сильнее, в чём-то просто углубил своё понимание. Данный текст - это результат пройденного с момента публикации предыдущего поста пути духовных поисков, последовавших за некоторыми тяжелыми и отчасти трагическими событиями моей жизни. Хотя во многом тема текущего поста перекликается с темой предыдущего, его основная мысль отнюдь не в рассмотрении буддизма, а в поиске смысла жизни с точки зрения рационального ума программиста.

В 2020-м мой работодатель начал прижимать меня по условиям, я забрал команду, снял склад и запустил свое производство когтеточек. Казалось бы, ничего сложного: закупаешь клей, картон, и находишь людей, которые 5 000 раз в день готовы повторять одни и ту же операцию. Но есть нюансы.

Привет, Хабр! Меня зовут Никита Горячев, работаю в позиции AI/ML Engineer в Сбере. В мой скоуп входит работа с SOTA (state-of-the-art) алгоритмами в областях NLP и RecSys.

Книга написана в форме Guide Book с теоретическими и практическими заданиями. Ниже написал анонс в виде Q&A, чтобы вы на первых двух пунктах смогли понять, интересно ли вам.

Ссылка на книгу

Все же знают серию компьютерных футбольных симуляторов FIFA? Раньше я много играл в эту игру. Кто-то скажет, что это бесполезная трата времени, но я с этим не согласен. Эта игра вдохновила меня на разработку pet-проекта, который стал моим бакалаврским дипломом.

Во время игры в FIFA пользователь видит небольшую карту с местоположением игроков и мяча на поле, данный элемент интерфейса является очень полезной фичей, без которой невозможно представить полноценный игровой процесс. Мне показалось, что данную карту было бы неплохо перенести в реальный мир, используя видеозапись матча и нейросеть. 

В этом материале мы поговорим об устройстве компонента‑декодера в системах машинного обучения, построенных по архитектуре «трансформер», уделив особое внимание отличию декодера от энкодера. Уникальной особенностью декодеров является то, что они похожи на циклы. Они, по своей природе, итеративны, что контрастирует с линейными принципами обработки данных, на которых основаны энкодеры. В центре декодера находятся две модифицированные формы механизма внимания: механизм множественного внимания с маскировкой (masked multi‑head attention) и механизм множественного внимания энкодера‑декодера (encoder‑decoder multi‑head attention).

Слой множественного внимания с маскировкой в декодере обеспечивает последовательную обработку токенов. Благодаря такому подходу предотвращается воздействие последующих токенов на сгенерированные токены. Маскировка важна для поддержки порядка следования и согласованности сгенерированных данных. Взаимодействие между выходом декодера (из слоя множественного внимания с маскировкой) и выходом энкодера организовано с помощью механизма множественного внимания энкодера‑декодера. Этот последний шаг даёт декодеру доступ к входным данным.

Мы, кроме того, продемонстрируем реализацию этих концепций с использованием Python и NumPy. Мы создали простой пример перевода предложения с английского языка на португальский. Практическая демонстрация обсуждаемых здесь идей поможет проиллюстрировать работу внутренних механизмов декодера в трансформерах и позволит лучше понять роль декодеров в больших языковых моделях (Large Language Model, LLM).

Извечный вопрос: должен ли тимлид обладать самой крутой технической экспертизой в команде? Споры будут идти ещё много тысячелетий, но где, как не в крупной компании, лучше в этом разобраться?

Сегодня поговорим о техническом лидерстве, где оно может лежать в команде разработки, обязательно ли это тимлид или всё-таки не обязательно. А поможет нам в этом Анастасия Абрашитова, руководитель службы инструментов репозитория в Yandex Infrastructure.

Я более десяти лет жизни писал код в одной российской компании и активно собеседовал-нанимал людей. За это время успел пообщался с четырьмя сотнями кандидатов. На моих интервью было все – от алгоритмических задач до разговоров о «жизни». Но форма вторична – я рассматриваю интервью как инструмент для проверки совпадения с кандидатом по культуре. И все эти десять лет в моей компании менялся подход к оценке программиста на интервью и менялась культура.

Любое собеседование адекватно компании, которая его проводит. Даже если от собеседования «бомбит» и «подгорает» - проблема в кандидате, а не в компании. И как кандидат я очень рад такому простому фильтру для отбраковки не подходящих мне компаний. Но и компания тоже преследует свои цели – сохранение и изменение своей культуры за счет найма «правильных» людей. Проверка технических навыков тоже важна, но важнее нанимать людей, с которыми можно работать.

Далее я хочу рассмотреть в формате моей истории разные способы оценки программиста на техническом интервью. У меня нет цели рассказать обо всех методиках оценки компетенций. Мой обзор методов оценки будет не полным, эгоцентричным и предвзятым. Также часть моего рассказа будет собрана из историй про другие компании. Это не будет рассказ как все на самом деле обстоит-обстояло, и прошу считать эту историю чистым вымыслом.

На территории России насчитывается от 200 до 300 вулканов. Около 13 из них находятся под особым наблюдением: это действующие вулканы, которые извергались в течение последних 25 лет. Самые активные расположены на территории Камчатки и Курильских островов, так что экстренные службы в этих регионах живут в постоянной готовности к последствиям извержений. 

Оценкой вулканической активности на Камчатке занимается подразделение Единой геофизической службы РАН. В прошлом году её вулканологи совместно с командами Яндекс Погоды, Yandex Cloud, Школы Анализа Данных (ШАД) и Геоинтеллекта запустили проект, который позволяет визуализировать данные по результатам извержений и предсказывать пеплопады в конкретных населённых пунктах. В дальнейшем разработанный сервис можно будет использовать для других подобных задач, например, прогнозировать пеплопады в регионах за пределами Камчатского края.   

Сколько проектов можно разрабатывать одновременно? Вопрос звучит неоднозначно. С одной стороны, на процесс влияет человеческий фактор, с другой – технические ограничения.

Если в работе используется Docker, то запуск нескольких проектов одновременно может превратиться в жонглирование контейнерами. Под таким словосочетанием я имею в виду постоянное отключение и подключение контейнеров, изменения портов, чтобы не было конфликтов, а также имена контейнеров, потому что внутри контейнера иногда необходимо выполнить скрипты. 

Я хочу попробовать иной метод работы, который, я надеюсь, должен помочь упростить использование нескольких проектов в Docker. Как я это делал, подробнее расскажу в статье.