Салют, Хабр!

Я Артур, CPO умных колонок Sber. Я отвечаю за создание наших умных колонок, в том числе за предмет этой статьи — их звучание.

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

Чтобы оценить аудиосистему, нужны музыкальные треки, которые раскроют весь её потенциал и способность передавать разные аспекты музыки. Собрали 10 треков, которые используем в работе, оценивая любые колонки. Рассказываем, как проверяют звучание устройств и как мы тестируем его при разработке умных колонок; делимся плейлистом для проверки, насколько совершенно ваше аудиоустройство.    

• SBC — нормальный кодек
• У наушников есть свой эквалайзер и пост-процессинг на каждый кодек отдельно
• aptX не настолько хорош, как о нём говорят рекламные анонсы
• LDAC — маркетинговое фуфло
• Качество звука в режиме разговора всё ещё низкое
• В браузер можно встроить аудиоэнкодеры на C, скомпилировав в WebAssembly через emscripten, и они не будут особо тормозить.

Здравствуйте! Меня зовут Елизавета Васильева, я врач-онколог, онкодерматолог. В своей врачебной практике я сталкиваюсь с пациентами, у которых обнаруживаются те или иные новообразования кожи, причем далеко не самые безобидные. По личному опыту хочу заметить, что некоторые люди весьма беспечно относятся к регулярным обследованиям невусов. Казалось бы, что там, пара родинок — и можно забыть. Но именно за этой беспечностью скрывается реальная опасность, ведь рак кожи — одна из самых коварных и недооценённых проблем.

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

Что такое безопасность технологического процесса или технической системы (устройства), что такое риск и вообще зачем все это?

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

В большинстве случаев этот материал носит научно-популярный характер, с огромным количеством терминов, аббревиатур, сокращений до трех букв, абстрактных рассуждений вперемешку с теорией вероятности, и для нормального инженера выглядит как полный бред. И в большинстве случаев это и есть полный бред. Трудно понять, как этот псевдо-научный поток теоретических рассуждений можно связать с реальным технологическим объектом, техническими устройствами, реакторами, колоннами, компрессорами, насосами, печами и т.д. Многие инженеры приходят к справедливому выводу – никак. И дело не в методах, методиках, ГОСТ-ах по анализу риска и функциональной безопасности, а в специалистах, которые не понимая реального смысла и целей этих методов, решение реальных задач заменяют процессом и процедурами, с формальным соблюдением отдельных пунктов методик, с безумными выводами, и своими безграмотными действиями полностью дискредитировали саму идею функциональной безопасности, основанной на оценке риска.

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

Выбрали хороший ресторан (врача, СТО, юриста, риэлтора) по отзывам и высокому рейтингу в 2GIS, а оказалось, что там если не ужас-ужас-ужас, то как-то средне, явно не похоже на то, что вы бы ожидали от рейтинга 4.8 или даже 5 баллов. Знакомо?

Все знают, что в 2GIS могут быть накрученные фейковые отзывы (а их там всего 10-20 на весь город или там 99% фейковых? Есть ведь разница!), но не все умеют их легко опознавать. У 2gis, похоже, еще нет антифрода (что вполне нормально для пет-проекта, который делают веб-программисты в свободное время), но вы теперь можете различать ботов-зомби-инопланетян через мой антифрод af2gis, и выбирать себе те заведения, которые нравятся людям, а не ботам.

Статья будет длинная (она про все подряд о чем я думал и с чем разбирался последнее время), но тех, кто ее прочитает ждет фантастическая награда! Они смогут ходить в самые лучшие заведения города, их будут обслуживать самые красивые и шустрые официантки, еда будет очень вкусной, порции огромными и все это за довольно разумные деньги! Такие места есть, живые люди их любят и ставят им высокие оценки, а боты - любят другие заведения. Нужно только надеть волшебные очки чтобы увидеть, какие заведения хвалят люди, а какие - боты.

Сегодня VK — это технологическая компания с комплексом цифровых продуктов и сервисов, объединяющая десятки миллионов пользователей с разными интересами. Среди наших сервисов — ВКонтакте, VK Видео, VK Музыка, Одноклассники, Дзен, RuStore, Почта Mail, а также игровые, образовательные и облачные платформы. Каждый продукт генерирует огромные объёмы контента: видео, статьи, приложения, почтовый трафик, стримы и многое другое.

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

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

Строки — одна из самых часто используемых структур данных в любом языке программирования. И в Go они повсюду: от простых приветствий вроде "Hello, World!" до сложных парсеров, логгеров и сетевых протоколов. На первый взгляд, с ними всё просто: создал, склеил, обрезал — и пошёл дальше. Но как это часто бывает, под простотой скрываются тонкости, игнорирование которых может привести к ошибкам и снижению производительности.

Go предлагает удобные, но специфичные механизмы работы со строками. Они тесно связаны с понятиями Unicode, UTF-8, рун, неизменяемости и байтовых представлений. Понимание этих механизмов позволяет не только избежать типичных подводных камней, но и писать более эффективный код.

Меня зовут Артём, я занимаюсь коммерческой разработкой с 2019 года. Последние несколько лет я активно использовал Spring Boot для создания backend-сервисов на Java и Kotlin.

Но в какой-то момент захотелось попробовать что-то новое. Не потому что Spring надоел, а просто чтобы выйти из зоны комфорта и узнать, как чувствует себя проект на другом языке. Я решил: возьму уже начатый pet-проект, перепишу его на Go — и посмотрю, как изменится подход, скорость разработки, ощущения.

Привет, Хабр! Я Никита Иванов, техлид команды «Видео» в KION. В ИТ я уже девять лет, а последние пять работаю с Go. Сегодня расскажу, какую задачу считаю идеальной для собеседования на позицию Go-разработчика. Этот текст — переработка моего доклада с митапа МТС True Tech Go, видеоверсию можно посмотреть тут.

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

Эта заметка будет очень короткой. Но надеюсь, она кому-то спасёт несколько часов жизни.

У меня был код. К счастью, это было в тесте, а не в боевом коде, поэтому никто не пострадал.

Код создавал http.Server, запускал две гороутинки для обслуживания входящих соединений:

go func() {srvr.Serve(p)}()

go func() {srvr.ServeTLS(e, "", "")}()

Ну и дальше создавал клиента, делал к серверу обращения (HTTP GET) попеременно используя http и https ну и чего-то там проверял.

Всё прекрасно работало. До обновления с go1.23.8 до go1.24.2, пришедшего с 42-й Федорой.

А потом перестало. Стало время от времени (но отнюдь не всегда) вываливать разнообразные ошибки. Например, вот такие: Get "https://127.0.0.1:46167/": unexpected EOF. Или такие: Get "https://127.0.0.1:34757/": write tcp 127.0.0.1:54770->127.0.0.1:34757: write: connection reset by peer. Или даже вот такие, совсем загадочные: Get "https://127.0.0.1:42447/": http2: client conn could not be establish. HTTP/2 там, разумеется никто не включал и не собирался. А иногда всё работало и тест проходил правильно.

Самое поганое, что ошибка была плавающей.

В общем, не буду грузить подробностями, как я эту ошибку ловил. Но итог такой. Хотя это нигде и не документировано, но одновременно использовать http.Server.Serve и http.Server.ServeTLS на одном и том же экземпляре сервера нельзя. Тот из них, кто успеет прокрутиться первым, чего-то там инициализирует внутри сервера, прежде, чем уйти в accept loop, и второй после этого ломается. Ломается всегда ServeTLS, не-TLS-овскому Serve вроде как пофигу.

Так что будьте осторожны, и надеюсь, что эта заметка сохранила вам несколько часов жизни :)

Привет, Хабр!

Сегодня хочу поговорить о проблеме, которую многие недооценивают в своих Go-проектах. Речь пойдет о бессрочном select {}, который легко может привести к блокировке, утечке ресурсов и деградации производительности.

Go предлагает уникальный и прямолинейный подход к обработке ошибок, отличающийся от try-catch в других языках. Он основан на явной проверке возвращаемых значений, что требует больших проверок, но ведет к более надежному коду. Рассмотрим основы, современные инструменты пакета errors и лучшие практики.

defer в Go — это мощный механизм для очистки ресурсов, закрытия файлов и разблокировки мьютексов. Вы наверняка слышали, что defer делает код чище и безопаснее.

Когда вы открываете файл через os.Open() или os.Create(), Go выделяет ресурс операционной системы — дескриптор файла.

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

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

Я старый фуллстек-разработчик и не знаю слов любви, но около полугода назад при очередной итерации сервера почувствовал себя утомленным путником, который узрел нежную красоту wr-обработчика нативного net/http! Вот раньше всё было ужасно - а теперь красиво, приятно читать и интересно показать! За несколько месяцев я переделал свои сотни обработчиков на новый стиль - и всё еще доволен! Почистил авгиевы конюшни слоев логики - теперь там царит запах фиалок! Также у меня была возможность посмотреть как пилят http профессионалы бэкенда - далеко не как фуллстеки, о чем тоже хочется рассказать!
Для ленивых читать - пора вернуть логику в обработчики! Но я расскажу подробно о той красоте, которая скрывается за этими многими восклицательными знаками, и о том, как её можно испортить. Структура такова:
- сначала чем фуллстек отличается от нативного бэкенда,
- потом пройдемся по API-стилю а-ля РЕСТ,
- прочтем оду нативному http-модулю, расковыряем пару болячек фреймворков,
- почитаем мои слова, почему wr-обработчик хорош сразу из коробки,
- и посмотрим пример того, как превратить обработчик в простой вид "задача-дано-решение-ответ".

Внимание, это мнение. В статье поднимаю холиварные темы, при этом я могу быть не прав, но буду настаивать! И фотка из личного фотоархива на тему "Люблю лето!", потому что уже надоели сгенерированные картинки.

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

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

Как реализовать подходы Mutex и lock-free и какой из них выбрать для решения вашей задачи? Как подружиться с пакетами unsafe и использовать их для эффективной разработки? И, наконец, куда движется Go после в релизе 1.24?

На эти и другие вопросы нашли ответы Go-разработчики из YADRO, Avito Tech и Yandex, а мы принесли вам записи и презентации их обсуждений. Из докладов вы узнаете о работе с критической секцией и подводных камнях unsafe. А после просмотра дискуссии поймете, какие фичи из нового релиза сделают вашу жизнь лучше.

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

Также одним из условий будет, чтобы внешний вид полученных элементов можно было редактировать в QtCreator.

Все исходники в репозитории.

Автор статьи Якушков Федор.

Apache Kafka — это мощная распределённая платформа для обработки потоков данных, которая завоевала популярность благодаря своей способности эффективно управлять большими объёмами информации в реальном времени. В этой статье мы подробно разберём, как использовать Kafka в языке программирования Go с помощью библиотеки kafka-go. Мы рассмотрим все ключевые аспекты: от event-driven архитектуры до топиков и партиций, от создания продюсеров и консьюмеров до управления оффсетами и обработки ошибок. Разберем гарантии доставки, а также обсудим, где и как применять Kafka в проектах.