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

Ассемблер может показаться сложным и пугающим, но он открывает большие возможности для работы с низкоуровневыми оптимизациями. Готовы разобраться, как это работает? Тогда погнали!

Привет, Хабр! Меня зовут Игорь Панасюк, я работаю в Яндекс, преподаю в ИТМО, а также в свободное время выступаю на конференциях, делюсь опытом в соцсетях и помогаю развитию Go-сообщества.

Когда я впервые решил создать свой open-source проект, мне казалось, что главное – это хорошая идея и рабочий код. Я взялся за разработку библиотеки для сетевых клиентов и UI-компонентов, вложил в неё два года работы и, наконец, выложил на GitHub. Но вместо успеха меня ждал холодный душ – библиотека получила всего 10 звёздочек.

Тогда я осознал ключевую проблему open-source: одна только идея не работает. Если проект плохо оформлен – его никто не найдёт. Документация и описание –  не менее важны, чем сам код. В следующем проекте я учёл ошибки. Когда правильно оформил проект, он начал находить аудиторию, получать звёзды и фидбек от разработчиков.

Open-source – это не только код, но и способность донести свою работу до других. И эта история дала мне важный урок: если хочешь, чтобы твой проект заметили, помоги людям его понять. А ещё я понял, как важно участвовать в комьюнити и контрибьютить.

Нейросеть, сегментирующая изображение человека в кадре: как ускорить её в четыре раза?

Привет, Хабр! Это Дмитрий Балиев из SberDevices. В этой статье речь пойдёт о том, как мы обрабатываем алгоритмами видео в Web-браузерах для сервиса конференции SaluteJazz.

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

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

Статья написана по мотивам выступления Максима Чудновского, лидера по продукту Platform V Synapse Service Mesh СберТех на Highload++, где он рассматривал кейс миграции с OpenShift на Platform V DropApp, но предложенные подходы могут быть использованы и для миграции на другие российские Kubernetes-платформы: Deckhouse, Штурвал, Боцман и так далее.

Помимо вариантов использования механизмов ETL, трансляции шаблонов в релизных конвейерах, рассматривается подход применения менеджера политик Kubelatte для того, чтобы мигрировать с OpenShift без единой правки кода.

Я из команды технологической платформы НЛМК ИТ. Спойлер — это все, что про централизованные сервисы около DevOps, Kubernetes, стриминг вокруг Kafka и так далее. Расскажу, зачем и по каким принципам мы ее строили, что получилось неплохо и всем советуем. Обо что споткнулись и всем советуем там не спотыкаться.

Когда говорят «аналитик 1С», у многих в голове возникает образ человека, грустно смотрящего в 1С, вздыхающего и что-то там ищущего или гоняющего ТЗ по почте. Но если вы хоть раз пытались выяснить, откуда взялось странное число в выгрузке, и не хотели тревожить разработчика по пустякам — значит, вы уже задумывались о чём-то большем.

Я — Анастасия Штей, работаю в 1С с 2008 года. Сейчас руковожу одной из сильнейших команд по автоматизации финансового учёта и вхожу в программный комитет конференции 1С Conf X. И я точно знаю, что современному аналитику 1С одного 1С недостаточно. В этой статье расскажу, какие технологии, среды и инструменты из арсенала разработчиков помогают аналитикам быстрее, точнее и автономнее решать задачи.

Статья не про «что такое BI» или «кто такой аналитик 1С» — таких полно. Мы пойдём дальше: обсудим, где на самом деле экономятся часы жизни, что действительно полезно знать даже без навыков разработки, и как это влияет на коммуникацию в команде.

Привет, Хабр! На связи программный комитет FrontendConf. Расскажем, как мы составляем программу нашей конференции и боремся за её актуальность — проводим исследования и общаемся с аудиторией.

FrontendConf = доклады + общение + опыт

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

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

В этой статье мы разберёмся, почему так легко «прострелить себе ногу» при работе с конкурентностью, как этого избежать и как построить надёжную и эффективную архитектуру.
А начнём мы — с лёгкого и ироничного рассказа в духе Чехова, где горутины встречаются с русской душой.

Всем хорошего дня! На связи с вами Домклик #MLOps, и эта статья будет полезна тем, кто интересуется построением внутренней платформы.

Feature Platform — новый взгляд на решение типовых задач в ML-разработке. Она упрощает работу с данными, системно решает задачи подготовки, хранения и использования фичей, обеспечивает их согласованность между окружениями и ускоряет разработку и внедрение моделей в эксплуатацию.

Как спроектировать такую платформу самостоятельно и что важно учесть в требованиях, чтобы она действительно работала?

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

Привет, Хабр! Меня зовут Алексей Чуркин, я работаю в компании Wildberries, где строю приватное облако. В этой статье по мотивам моего доклада для Highload++ расскажу о том, как мы внутри компании построили облачную платформу, с какими сложностями столкнулись и как собираемся её развивать.

Мы начинали с обычного ELK-стека, логи приходили на logstash, записывались в Elasticsearch, а пользователи смотрели их в Kibana. Потом в эту схему добавилась Kafka, так как мы понимали, что на пиках нагрузок не успеваем записать все логи в Elasticsearch. Всё это располагалось в одном ЦОДе, а в Kafka была единая очередь. В результате горизонтального масштабирования Elasticsearch разросся до 30+ нод. Данная схема справлялась с нагрузкой в 100 тысяч документов в секунду.

Как вы понимаете, эта схема нас устраивала только до определённого периода. В какой-то момент нагрузка начала расти как на дрожжах.

Привет, Хабр! На связи Филипп Бочаров, руководитель платформы наблюдаемости и мониторинга для более 400 продуктов экосистемы МТС, и Юлия Тальцкова, ведущий инженер сервиса логирования и кластеров Open Search с более 400 терабайтами логов клиентов. Этот материал написан на основе нашего доклада для конференции Highload++

Расскажем, как нам удалось переписать критичный и высоконагруженный сервис логирования, перестать просыпаться от ночных звонков и даже иногда уходить в отпуск.

Привет! Меня зовут Александр Абрамов, я руковожу AI-командами в R&D для b2c в SberDevices, веду канал про AI и вхожу в программный комитет конференции AiConf Х. В этой статье хочу рассказать о своём пути в мир искусственного интеллекта: как одна лабораторная работа по анализу данных определила мою карьеру, зачем нужны соревнования и хакатоны, и почему участие в конференциях важнее, чем просто прокачка резюме. Делюсь опытом, ошибками, победами и тем, как реально устроен AI в продакшене.

Привет, Хабр! Когда разработчик — это только код? А когда — полный хаос, в котором виноваты дизайнеры, DevOps, тестировщики, кто угодно, но не он? Меня зовут Дарья Корчуганова и я — руководитель команды разработки в Газпромбанк.Тех, IT_ONE. В этой статье на основе моего доклада для FrontendConf поделюсь опытом и размышлениями о том, что и почему должен делать разработчик. Разберём, как избежать фейлов и сэкономить нервы.

Кажется, что работа разработчика проста: пиши код, заливай, жди аппрува. Но потом начинается... Задачу забрал другой? Код не попал на стенд? Билд сломался? Кто виноват? Возможно вам знакомы фразы: «мой код работает, проблема в других», или «пусть тимлид следит за статусом задач», или «тестировать — задача тестеров, я не буду проверять работу кода на стенде», или даже «не собрался билд — это проблемы DevOps», «полетела вёрстка — виноваты дизайнеры».

Привет, меня зовут Александр Виноградов и я главный ИТ архитектор Ви.Tech. Сегодня расскажу о том, как я однажды подал заявку на TeamLead Conf, а в результате стал членом программного комитета этой конференции. А еще поделюсь своим «взглядом изнутри» и научу, как сделать вашу заявку практически идеальным кандидатом на попадание в программу конференции. А поможет мне в этом мой напарник по ПК TeamLead Conf — Виталий Качановский.

Как я расстроился из-за тимлид конф 24

Началось все с того что мою заявку не взяли на московский тимлид 24. Причем ладно бы отказали —  даже никто не связался. Было неприятно, я ж старался в конце концов. Но фрустрировал я недолго. И решил, что раз в этот раз выступить не удастся, то можно и просто рядом постоять, а заодно и выяснить, как программный комитет тимлида (ПК) принимает решение, кого брать в программу, а кого нет. 

И мы сделали подкаст с Ромой Ивлиевым (главный по тимлидконф) о том, как устроен ПК, как в него попасть и сколько надо заплатить, чтобы тебя взяли (спойлер — даже не пытайтесь, не поможет). После выпуска я списался с Ромой и попросился в ПК на «разбор конюшен» — тех заявок, что старожилы себе не взяли по причинам, о которых я расскажу ниже.

Сейчас, когда отбор уже закончен, я смог наконец создать рецепт идеальной заявки для IT конференции. Поделюсь своими наработками с читателями, и, возможно, уже на следующем тимлиде окажусь куратором кого-то из вас.

Её величество Тема

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

Привет, Хабр! Когда-то я проверяла завещания и готовила доверенности, а теперь проверяю витрины данных, ищу дубли и считаю доходность по инвестиционным инструментам. Меня зовут Арина Шахтарина, и я — Data Quality-инженер в Сбере. Это история о том, как любовь к данным и таблицам превратилась в новую профессию, и почему SQL — лучший универсальный язык после русского. Тут будет про карьерные повороты, боли с форматами данных, проверки данных и немного про мечты, которые сбываются (даже если ты не в отпуске).

Как сделать ретроспективу полезной и интересной

Привет! Меня зовут Настя, я работаю проектным менеджером и скрам-мастером в онлайн-кинотеатре Okko. За последний год я провела более 100 ретроспектив в разных командах. Не все из них были удачными.

Мобильная разработка продолжает развиваться, но, если честно, никаких революционных прорывов в последнее время не произошло. Громкие темы, вроде Kotlin Multiplatform (KMP), Flutter, Jetpack Compose, SwiftUI, уже давно закрепились в индустрии, а новинки больше эволюционируют, чем меняют правила игры. Компании экспериментируют с кроссплатформенными решениями, и это выглядит логично. Писать общий код для iOS и Android 一 это экономия ресурсов и времени. Вроде бы верно, но на практике всё не так гладко.

Привет, меня зовут Максим Плахута и с недавнего времени я руковожу Android разработкой «Кинопоиска». До этого руководил мобильной разработкой Почты Яндекс. А ещё я участник ПК новой конференции по мобильной разработке Apps Conf. Расскажу, какие шишки набили в реализации кроссплатформенного проекта и чего лучше не делать в современной мобильной разработке.

Достигая условного «потолка», инженеры часто уходят в другие компании в поисках амбициозных задач. Бизнес теряет опытных людей, хотя на самом деле рост был возможен, просто не формализован, или тимлиду некогда было этим заняться. Я подумал, что круто — иметь в команде систему, которая сделает развитие предсказуемым для инженера. Когда он сам или с поддержкой смог бы строить карьеру, в зависимости от личных целей. Кто-то хочет прокачиваться и расти, кто-то выше зарплату, а кому-то важно сейчас оставаться на уровне и не гнаться за новыми повышениями.

Я, Константин Лапин, руководитель технической поддержки Nexign. Мы пишем софт для телекома, создаём международные продукты и платформы, ускоряющие работу внутри компаний. Моя команда поддерживает одного из крупнейших телеком-операторов России. Мы отвечаем за то, чтобы технических сбоев либо не было, либо, если сбой случился, то минимально влиял на абонентов. В отделе четыре команды по 8-10 человек в каждой, работающие в графике 2×2.

Расскажу, как мы создали и внедрили систему развития от инженера до главного эксперта в своей команде. Мы обсудим:

▪ что такое инженерный карьерный трек, кому он нужен, а кому нет;

▪ что влияет на продвижение по треку;

▪ как мы обосновываем повышения бизнесу и сотрудникам;

▪ как растим новичков и что получилось по итогу внедрения готовой схемы в команде из 40 человек.

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

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

Учитывая особенности работы с IoT, мы сформулировали требования к архитектуре...