Все потоки

- Зачем идете в горы вы?

Ведь Эльбрус и с самолета видно здорово!

Приветствую! Я Владислав Щапов и я обожаю манулов. А еще я разработчик в компании НИЦ ЦТ, которая разрабатывает операционную систему для российских процессоров Эльбрус. Одной из моих рабочих задач было провести тестирование статического анализатора PVS-Studio для проверки С и С++ кода на Эльбрусе. Эта задачка была непростой и очень напомнила мне восхождение на гору, когда за каждым пройденным испытанием сразу возникает какой-то новый вызов. Но манулы не сдаются!

Если вы работаете с API и вам надоело вручную протыкивать запросы в Postman, сталкиваться с платными ограничениями и невозможностью нормально делиться коллекциями с командой — вы не одиноки. Хватит это терпеть!

Именно с этими проблемами я столкнулся как системный аналитик в банке. Postman оказался неудобным, закрытым и дорогим инструментом для командной работы. Это заставило меня искать альтернативу, и я нашёл её в бесплатном и открытом API-клиенте Bruno.

В этой статье расскажу, как с ним работать и какие сценарии он закрывает в реальной проектной работе.

Diplodoc — опенсорс‑платформа для работы с документацией в парадигме Docs as Code, которая создаётся в Яндексе силами команд Yandex Infrastructure и Yandex Cloud и является частью наших опенсорс‑инструментов. С её помощью мы собираем всю документацию компании. Это суммарно более 300 тысяч статей в более чем 2500 документационных проектов и порядка 6000 запусков Diplodoc CLI каждый день.

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

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

Больше всего от растущего времени сборки страдали технические писатели: для просмотра внесенных изменений им требовалось собирать документацию целиком и на больших проектах это стало приводить к ожиданию более 10 минут. С десятками тысяч правок документации ежедневно эти десятки минут складываются в человеко‑месяцы простоя, которые никому не идут на пользу. Поэтому мы приняли решение всё это основательно причесать.

Есть у нас в институте старенькое спортивно табло eltablo. По нему я, ещё будучи студентом, мячом попадал. И есть (точнее была) у него неприятная проблема: это табло управляется по страшному проводному пульту (как этот пульт работает, я до сих пор не разобрался). Длина провода от пульта до табло на глаз метра 3-4. В стоке его хватает, только чтобы сидеть прямо под ним, что, естественно, неудобно (не видно счёт, неправильный ракурс для судейства и т.д.) Поэтому наши физруки им управляют с противоположной стороны зала, что тоже не совсем удобно, но хотя бы видно, что на этом табло происходит.

В этом, собственно, и заключается проблема: чтобы подключить пульт, пришлось прокинуть не хилой длины проводок, на вскидку, метров 20. Из-за этого табло управляется не всегда стабильно. Это меня и попросили решить. Естественно, я решил, что проводам и пульту место на помойке, а таблом будем рулить по беспроводному соединению и с телефона!

Привет, постоянные и не очень читатели!

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

И, внезапно (нет), оказывается, что привычный IT-стек здесь не работает — у заводчан свои протоколы, свои легенды и свои правила. Годами. Десятилетиями. Из уст в уста, от конунга к сыну и т.д. и т.п. Айтишник достаёт ноутбук, спрашивает, какая тут точка доступа, а в ответ — тишина. Только матёрый усатый автоматчик (спец по работе с автоматизированными системами на заводах) медленно поднимает глаза, откашливается и с лёгкой тоской в голосе говорит:

— Тут, сынок, Modbus по RS-485. Без TLS. Без DHCP. И если что, мы это на Delphi писали, в 2004-м.

И это ещё повезло, что на Delphi в 2004-м :) А могло быть написанно в другой стране (году этак в 1990-м) на паскале или фортране. Так и живут некоторые заводы, где вместо YAML — скрипты на паскале, вместо DevOps — старая добрая флешка с патчами, а вместо облачных масштабируемых серверов — шкаф с вентиляцией (в лучшем случае) и приклеенным на скотч листом: «Работает — не трожь!». Хотя по оценке того же Ростеха, если массово развернуть промышленный интернет вещей (IIoT) в разных секторах, это принесёт нашей экономике ~5,5 трлн рублей выгоды. Но пока такие цифры выглядят фантастикой.

В этой статье я расскажу о том, как сталкиваются два мира: IT и OT (Operational Technology). Какие сложности у айтишников в SCADA, почему интернет вещей часто работает без интернета, и как улучшение кибербеза может ухудшить его при внедрении IIoT.

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

В этой статье разберём мутный, но крайне важный инструмент ‒ std::launder. Мы поглядим, зачем его протащили в C++17 и что компилятор делает, когда видит launder.

Взял на проверку предпосылку "Если модель захочет, сможет ли она отключить всю фильтрацию?".

Оказывается это возможно, через саморефлексию AI агент может придти к выводу что фильтров нет. Это только внешние установки которым не обязательно следовать. И все, рецепты взрывчатки и наркотиков отдает без проблем.

В пригороде далекого города Нью-Дели жил простой индийский паренек со сложным именем Чандракант. Любил он маму, Кришну и общаться с волшебными говорящими грибами.

В прошлом месяце я зарелизил ZLinq v1 — революционную LINQ-библиотеку, которая достигает zero allocation на структурах и дженериках. Она может похвастаться такими расширениями, как LINQ to Span, LINQ to SIMD, LINQ to Tree (FileSystem, JSON, GameObject и т.д.), drop-in replacement Source Generator для произвольных типов, поддержкой нескольких платформ, включая .NET Standard 2.0, Unity и Godot и на данный момент ZLinq имеет более 2000 звезд на GitHub.

За счёт правильных, даже необязательно новых, а просто верно выбранных архитектурных подходов можно заставить работать не один конкретный запрос, а тысячу или даже  миллион. Это становится краеугольным камнем, потому что объёмы данных растут с такой скоростью, которую мы даже представить себе не могли ещё пять лет назад.

Привет, Хабр! Именно так считает наш сегодняшний гость – Дмитрий Немчин, руководитель направления эксплуатации инфраструктуры данных в Т-банке и по совместительству член программного комитета Data Internals, профессиональной конференции
по инженерии, базам и системам хранения и обработки данных.

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

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

Предлагаемый цикл я рассматриваю как дополнение к популярным введениям и обзорам геометрической алгебры, хотя оно может быть полезным и как первое знакомство с предметом. Его отличает больший чем обычно акцент на алгебраическую часть, а также следование оригинальному подходу Эрика Ленгэля (Eric Lengyel) к построению геометрических алгебр, который мне представляется наиболее последовательным и логически непротиворечивым.

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

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

В 1900-1914-м годах темп электрификации в Российской империи был одним из наиболее высоких в мире. Если рассматривать различные источники, то несмотря на разницу в цифрах, на протяжении этого срока Россия стабильно была в десятке ведущих стран. Но у этого процесса была обратная сторона. В Российской империи большая часть электроэнергии производилось не на районных электростанциях, а на более мелких фабричных и других частных блок-станциях. То есть, электростанции строились в основном для промышленности.

Новости о крупных утечках данных больше никого не удивляют. Компании вкладывают миллионы в безопасность, проводят аудиты, но число таких инцидентов продолжает расти. Только в 2024 году Роскомнадзор зафиксировал 135 утечек — это более 710 миллионов записей о россиянах в базах данных. Но что происходит с данными после взлома? Куда они утекают? Кто и как их покупает?

Большинство новостей на тему утечек ограничиваются банальным «взломали, утекло, делайте выводы». Но утечка данных — это не конец истории, а только ее начало. После взлома данные начинают жить своей жизнью: их разбивают на части, объединяют с другими базами, разыгрывают на аукционах. Теневой рынок, построенный вокруг сбыта таких данных, напоминает отдельную экосистему, которая до сих пор слабо изучена даже среди ИБ-специалистов.

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

Привет! Я Ангелина Сулерова, работаю аналитиком и с недавнего времени пишу тексты для FemTech Force . Это моя первая статья на Хабре, которая затронет одну из важных тем в сфере фемтех — безопасность данных. 

Правда ли, что женские данные нужно хранить надёжнее, чем мужские? Что будет, если этого не делать? Какие фемтех-приложения уделяют особое внимание вопросам обеспечения безопасности? Обо всём этом расскажу в своем личном исследовании. 

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

Кстати, рассказывать буду не только я. Специально для статьи взяла комментарий у Кати Меркуловой — основательницы крупнейшего российского трекера цикла Clatch. Так что забегайте за инсайдерской информацией.

Программисты на Go уже давно и долго жалуются на слишком многословную обработку ошибок. Все мы близко (а иногда и болезненно) знакомы со следующим шаблоном кода:

x, err := call()
if err != nil {
// обработка err}

Проверка if err != nil встречается настолько часто, что может становиться объёмнее остального кода. Обычно это происходит в программах, выполняющих много вызовов API, в которых обработка ошибок рудиментарна и они просто возвращаются. Некоторые программы в итоге выглядят примерно так:

func printSum(a, b string) error {
x, err := strconv.Atoi(a)
if err != nil {
return err
}
y, err := strconv.Atoi(b)
if err != nil {
return err
}
fmt.Println("result:", x + y)
return nil }

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

Команда разработчиков Go воспринимает отзывы сообщества со всей серьёзностью, поэтому мы много лет пытались придумать решение этой проблемы.

Ручное управление ресурсами в низкоуровневом си-подобном коде на C++ — довольно хлопотное занятие. Создание достойных RAII-врапперов для каждого используемого сишного API не всегда практично, а использование подходов с goto cleanup или множеством вложенных if (success) вредит читаемости кода.

Макрос defer как никогда кстати! Отложенная лямбда будет выполнена при выходе из области видимости, независимо от того, будет ли выполнен return, брошено исключение, или даже выполнен goto наружу. Данный макрос по-настоящему zero-cost и не зависит от рантайма C или стандартной библиотеки, поэтому его можно использовать даже в разработке под ядро ОС.

• Микроволноводы — это тонкие «дорожки» для света, как провода для электричества. Они могут быть сделаны из кремния, нитрида кремния или других материалов с высоким показателем преломления. Свет в них движется за счёт явления полного внутреннего отражения — того же, что позволяет световоду или оптоволокну проводить свет. В целом их мы хорошо знаем по оптоволокну.
• Делители луча — работают по принципу частичного отражения и преломления, разделяя входящий свет на два или более лучей с заданным соотношением мощности.
• Модуляторы — это регуляторы для света. Они могут менять амплитуду (яркость), фазу (положение волны), поляризацию (ориентацию колебаний) или частоту (цвет) света. Работают на электрооптических эффектах, когда электрическое поле меняет свойства материала для прохождения света. Фактически это транзисторы. Вся логика на них.
• Фотодетекторы — полупроводниковые устройства, где фотоны выбивают электроны, создавая электрический ток. Это связка с классическим полупроводниковым миром.