IT-стандарты *

В прошлой статье мы рассмотрели новые поправки в законодательстве об административной и уголовной ответственности за правонарушения в сфере персональных данных (ПДн). Дорогие Операторы ПДн, как вы там? Успели подать уведомление в Роскомнадзор, победив перебои в работе портала? Приступили к выстраиванию правомерных процессов обработки ПДН и системы их защиты?

Как мы знаем, Федеральный закон от 27.07.2006 г. № 152-ФЗ «О персональных данных» призван в первую очередь защищать права и свободы граждан, поэтому важно его соблюдать не с точки зрения защиты от штрафов, а с точки зрения защиты ПДн граждан. Нововведения в КоАП и УК РФ заставили Операторов собраться и все-таки заняться пробелами в обработке и защите ПДн в их организациях. На мой взгляд, это послужило первым шагом в налаживании диалога с регуляторами и к действиям, направленным в первую очередь на выстраивание грамотной защиты данных граждан.

Активизация операторов ПДн в мае этого года – позитивная тенденция, но за уведомлением в РКН должна стоять большая проделанная работа, иначе подаваемая в Реестр операторов, осуществляющих обработку ПДн, информация не будет отражать действительность, и главная цель – защита так и не будет достигнута. Уведомление в РКН не защитит вашу организацию от возможной утечки ПДн, и, как следствие штраф за неуведомление вы может и не получите, но для злоумышленников обрабатываемые вами ПДн останутся лакомым активом. Для построения комплексной защиты персональных данных необходимо начать с первого и очень важного шага, именно об этом шаге я и хочу поведать в этой статье.

JPEG — формат-динозавр. Ему уже за тридцать, но он по-прежнему живее всех живых: даже в 2025 году изображения в JPEG встречаются повсюду.

В конце 80-х инженерам нужно было как-то справляться с растущими размерами файлов. Интернет был медленным, а фотографии — всё тяжелее. Тогда и придумали решение: сжатие с потерями, основанное на дискретном косинусном преобразовании (DCT). Если по-простому, DCT — это способ выкинуть из картинки то, чего наш глаз почти не заметит, и оставить главное. В итоге получаем файл в разы меньше, а картинка всё ещё выглядит прилично.

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

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

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

Привет, Хабр! Меня зовут Роман Изотов. Последние 5 лет я провел по ту сторону баррикад – в роли IT-рекрутера, где отсмотрел более миллиона резюме и провел тысячи собеседований. Сегодня я помогаю IT-специалистам взламывать систему найма, и вот что я вижу: многие по-настоящему сильные Senior-инженеры, тимлиды, архитекторы сталкиваются с одной и той же проблемой – их резюме просто не работает.

«Мой опыт говорит сам за себя!» – Главное заблуждение.

Кажется логичным: если у тебя 7-10 лет опыта, куча проектов, сложные технологии, то резюме должно привлекать. Но в 2025 году это больше не так. Рынок перегрет, конкуренция бешеная. На одну Senior-вакансию приходят десятки, а то и сотни откликов. И вот тут в игру вступают фильтры, о которых вы могли даже не догадываться.

Фильтр №1: Автоматизированные системы отбора (ATS) – ваш первый и самый беспощадный враг.

Забудьте про креативный дизайн и инфографику. Для ATS ваше резюме – это набор ключевых слов. Если вы не используете точную лексику из описания вакансии, не указываете конкретные технологии и метрики – ваша заявка просто не дойдёт до HR. Система не поймёт, что "оптимизировал производительность" означает "сократил время отклика сервиса на 30% на пять миллионов пользователей". А если она не поймёт, то вы в корзине.

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

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

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

Сегодня я пытаюсь понять реальные риски внедрения нейросетей в рабочие процессы. Надеюсь на твои комментарии, наблюдения и страхи, Хабр!

Когда я впервые узнал о кодировке UTF-8, то был поражён её продуманностью и структурой. Тем, как изящно её авторам удалось выразить миллионы символов разных языков и письменностей, параллельно сохранив обратную совместимость с ASCII.

В UTF-8 используется 32 бита, а в старой доброй ASCII — 7 бит. Но UTF-8 выстроена так, чтобы:

- Любой файл в кодировке ASCII являлся валидным файлом UTF-8.

- Любой файл в кодировке UTF-8, имеющий только символы ASCII, также являлся валидным файлом ASCII.

Спроектировать систему, способную масштабироваться на миллионы символов и сохранить совместимость со старыми стандартами, использующими всего 128 символов — это гениально.

Привет, Хабр! Я старший системный аналитик, эксперт онлайн-школы по системному анализу Ольги Пономарёвой. Материал основан на реальных кейсах из практики: мы в школе System Analyst не просто рассказываем теорию, а делимся тем, что действительно работает на проектах.

За свою карьеру я написала не одну сотню требований и поняла такую вещь – самые важные и самые незаметные, это блок нефункциональных требований. 

В этой статье я расскажу, как правильно выявлять и формулировать НФТ.

Привет! Я Лев, специалист продуктовой поддержки в Selectel. Ранее мы разобрались, какими бывают технологии при строительстве межцодовых трасс, а также прокачали навыки в резервировании. Теперь перейдем к практике и разберемся, как составлять проект межцодовой трассы. Изучим, как выбрать технологии, рассчитать пропускную способность и обеспечить надежность инфраструктуры.

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

Продолжаю публиковать наши разговоры из телеграм-канала Dev Q&A. В этот раз собрались обсудить одну из самых спорных тем в российском IT — low-code платформы. Тема настолько горячая, что удалось собрать представителей ведущих российских low-code платформ и практикующих разработчиков.

$199 за файл.

Не за программу. Не за базу данных. Даже не за документ с полезной информацией. За файл в несколько килобайт зашифрованного текста, который говорит браузеру «этот сайт действительно тот, за кого себя выдает».

Всем привет!

Всем, кто когда‑либо реализовывал ИТ‑проекты, наверняка знаком термин HLD (High Level Design) и тот факт, что без него достаточно сложно спланировать любой комплексный проект. Более того, в проектах всегда очень хочется пропустить кажущуюся ненужной трату времени на сбор и описание требований и сразу приступить к обсуждению решения, тем более, когда оно кажется очевидным.

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

Итак, нужна архитектура решения (HLD) или она уже есть и надо убедиться в ее правильности.

Достаточно часто в реализации сервисов есть необходимость оперировать денежными единицами, хранить их в БД, обмениваться по API и выполнять конвертацию

Великий аргентинский писатель Хорхе Луис Борхес в одном из своих произведений попытался доказать, что вся мировая литература сводится к четырем базовым сюжетам: история об осаде и защите обречённого города, история о возвращении, история о поиске и история о жертвоприношении или самоубийстве бога. В комментарий к этому заявлению Виктор Пелевин в одном из своих романов написал: «А по‑моему, сюжетов всего два. Первый — как человека убивают из‑за денег. Второй — как человека приносят в жертву. А на самом деле оба сюжета можно даже объединить в один». Как бы то ни было, оставим этот спор о сюжетах литературоведам. В этом же посте я хочу разобрать схожий тезис — все архитектуры разных видов программного обеспечения можно свести к двум базовым структурам — монолиту и шине.

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

Азазель предложил идею, которая кажется логичной и полезной:

После десяти лет обсуждений и тестирования десятков алгоритмов Национальный институт стандартов и технологий (NIST) утвердил окончательный стандарт «облегчённой криптографии» (lightweight cryptography) для микроконтроллеров, встроенных CPU, слабых FPGA и других устройств с ограниченными аппаратными возможностями, то есть минимальным количеством памяти и вычислительными ресурсами.

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

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

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

2025 год оказался богат на поправки в законодательство о персональных данных. Одна часть изменений вступила в силу весной, другая — летом, а некоторые начали действовать только с 1 сентября.

Привет, Хабр! На связи Алёна, аналитик по информационной безопасности в Selectel. В этой статье разберем, что делать владельцам интернет-ресурсов, чтобы избежать штрафов и других санкций. Материал основан на моем опыте работы с регулятором и анализе его публичных разъяснений.

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

Важно не прогадать с выбором протокола для SSO. Ведь от протокола зависит буквально всё: безопасность, удобство, возможности.

Протокол OIDC (OpenID Connect) является лучшей альтернативой протокола SAML.