Все потоки

При разработке сложной системы приходится сталкиваться с использованием nginx в качестве reverse proxy: роутинг, список правил, регулирующих путь запроса во внутренние системы или между подсистемами.
Быстро развивающиеся сервисы обрастают правилами, назначение которых не очевидно или имеет недокументированные особенности. Проверенный способ рефакторинга таких систем: зафиксировать и вылечить упростить. Фиксировать будем тестами.

Как проверить корректность вашей конфигурации Nginx'а? Как проверить ее безопасность и нет ли уязвимостей ? Какие есть для этого варианты, их плюсы, минусы, практическая применимость и как эти проверки встроить в CI пайплайн ?
Ответы на эти вопросы под катом. Будет полезно, погнали.

Disclaimer: Эта статья предназначена исключительно для образовательных целей и повышения осведомлённости о киберугрозах. Любое использование описанных техник в злонамеренных целях строго запрещено и преследуется по закону.

На одной из предыдущих работ нужно было собрать свои достижения в области кибербеза. У меня были различные найденные уязвимости. Но, я даже не знал: были ли им присвоены CVE? Я этим не занимался. Занимались ли вендоры - не в курсе. Тогда я вспомнил ситуацию с выявлением мной уязвимости в антивирусе Agnitum и взгрустнул: CVE не был зарегистрирован. Год назад я вспомнил эту историю и задумался: а можно ли оформить CVE сейчас, спустя 12 лет после обнаружения уязвимости? Ситуация осложнялась тем, что вендора уже много лет как нет. И его сайта, конечно, тоже. Но, раз вы читаете этот текст - то мне это удалось (за этот кейс я попал в топ-10 Pentest award 2025 - номинация "Раз bypass, два bypass"). Но, путь занял почти год. И вот как это было (спойлер: помог сервис WayBack).

У меня в VK несколько тысяч друзей, и истории давно превратились в шум: много людей, с которыми я не общаюсь, старые контакты, рабочие связи.

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

Поэтому я написал простой браузерный скрипт, который автоматически скрывает истории почти от всех, кроме тех, кого я явно добавил в список исключений по имени или ID.

Скрипт запускается из консоли, продолжает работать даже в неактивной вкладке и доступен в открытом репозитории.

GitHub

Пятая статья в серии о DOM-подобных моделях данных в разных языках программирования.

В предыдущих частях мы разобрали DOM-подобные структуры данных, оценили их поддержку в ряде языков с помощью бенчмарка CardDOM и сравнили их реализацию в JavaScript. и С++, Rust и D-lang (а также упомянули Zig, Odin, Jai, Python, V, Cone и Pony).

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

Посмотрим, как с этой задачей справляется Argentum — язык, для которого такие структуры данных являются нативными.

Привет! Меня зовут Юра Байков, я ведущий ведущий QA-инженер и много раз проводил собеседования на позицию тестировщика в свою команду. Да, на Хабре много постов о том, как проходят такие встречи и как к ним подготовиться. Но сегодня хочу поделиться именно своим опытом: подскажу, какие книги прочитать, чтобы укрепить базу, — шок-контент, но их всего две. А еще расскажу, о чем я спрашиваю джунов на собеседовании.

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

Привет! Меня зовут Андрей, я Data Engineer в компании GRI. Мы занимаемся заказной разработкой, и один из наших ключевых клиентов — Sunlight. Я расскажу, как не тратить время на рутину в процессах и автоматизировать всё, что только можно. Это будет особенно актуально тем, кто в компании solo Data Engineer.
 

Небольшой опыт использования модели для определения эмоций. Я пытался найти эмоции у Цветаевой с помощью Python. Да не смог.

Рынок графических нейросетей расширяется, причём их возможности растут в геометрической прогрессии. Совсем недавно появилась новая версия Nano Banana, чуть раньше - Seedream v4 и Reve.

Я подумал: почему бы не сравнить эти три модели? Уровни генерации у них примерно одинаковы, возможно, получится что-нибудь любопытное.

Итак, сегодня мы рассмотрим: Nano Banana (берём первую версию, вторая была бы слегка не равноценна по отношению к конкурентам), Seedream v4 и Reve. Постараемся осветить некоторые интересные возможности, если они имеются, а также попробуем определить, какая из моделей справляется лучше с поставленными задачами.

Устраивайтесь поудобнее - мой рассказ начинается.

«Правда, что always можно поставить в Present Continuous?»

«А почему здесь already стоит в Past Simple?»

«Как это every day можно впихнуть в Present Continuous?»

«В смысле usually ставится в Past Simple?»

Эти и многие подобные вопросы прилетают ко мне довольно частенько.

И каждый раз я начинаю своё объяснение со слов «ДАВАЙ ЗАБУДЕМ О СЛОВАХ-МАРКЕРАХ». 

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

Начну с главного: таких слов-маркеров, которые на 100% привязаны к одному времени, не существует.

Почему же тогда нас так учили?

Всё просто: чтобы не перегружать детские мозги. Учителя давали упрощённую схему: видишь yesterday – ставь Past Simple, видишь always – ставь Present Simple и т.д. 

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

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

Если на слова-маркеры не стоит полагаться, как же тогда понять, какое время ставить?

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

Я собрал и изучил 100 вакансий от 68 компаний, чтобы понять, на что работодатели обращают внимание и что скрывается под формулировками «Аналитический склад ума» или «Крепкий UI».

В этой статье:

• Что требуют от дизайнера продукта в 2025 году?
• Какие харды и софты стоит качать в первую очередь?
• Должен ли дизайнер проводить исследования и разбираться в коде?
• Какой навык упоминается лишь в 20% вакансий, но при этом остаётся критически важным для получения оффера?

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

Но радости не было. Каждый отпуск мы с женой возвращались к одному вопросу: чем заняться, чтобы делать что-то своё от начала до конца.

Сейчас у нас семейное производство натуральной косметики. Два бренда: MOYABORODA для мужчин и OLFACTORIUS для всей семьи. Оборот — от 500 до 900 тыс. ₽ в месяц. Рентабельность — 24–25%. Команда — 5 человек, плюс мы с женой. Всё делаем сами на площади 100 м² — без инвесторов, без франшизы, без кредитов.

В этой статье расскажу, как мы строим производство: что варим и как, сколько зарабатываем на банке масла, почему маркетплейсы забирают 60% выручки и зачем мы сознательно остаёмся маленькими.

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

Business Capability Map (карта бизнес-способностей) — это один из ключевых артефактов в современных подходах к управлению корпоративной архитектурой, особенно в таких методологиях, как TOGAF, ArchiMate и других архитектурных фреймворках. В данной статье разберемся с определением что же такое бизнес-способность, и приведем пример карты бизнес-способностей небольшого бизнеса в области обучения.

Тема ценностных искажений в командах до сих пор мало проработана в русскоязычной управленческой и ИТ‑литературе.

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

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

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

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

Одна из базовых функций систем машинного зрения состоит в классификации объектов. Для решения этой задачи традиционно применяются методы обучения с учителем (SL). Эти методы обеспечивают высокую точность, но при этом размер нейросетевой модели увеличивается с увеличением количества классов. Такая особенность ограничивает применимость SL в тех случаях, когда число классов слишком велико или заранее неизвестно.

Эксперт отдела перспективных исследований компании «Криптонит» Никита Габдуллин предложил новую методологию, позволяющую добиться одного и того же размера нейросетевой модели независимо от числа классов. Это достигается за счёт использования предопределённых векторных систем в качестве целевой конфигурации скрытого пространства (Latent Space Configuration, LSC) во время обучения.

С проблемой раздувания классов сталкиваются во многих областях — от ритейла до научных исследований. Мы рассмотрим её на задаче распознавания лиц, где каждый человек (его ID) считается отдельным классом.

Существующий подход (SL) требует, чтобы размер последнего классификационного слоя был пропорционален количеству этих ID.

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

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

Физики из МФТИ и Национального исследовательского центра «Курчатовский институт» разработали новую теоретическую модель, которая разрешает многолетние противоречия в описании одной из самых опасных неустойчивостей плазмы в установках термоядерного синтеза. Предложенный подход позволяет точнее предсказывать поведение плазменного шнура и открывает путь к созданию более надежных систем управления для будущих термоядерных реакторов, включая международный проект ITER. Результаты исследования опубликованы в журнале Physics of Plasmas.

Привет! Меня зовут Николай Огоров, я Big Data-инженер в Авито. В этой статье я и мой коллега Айк Оганесян расскажем, как обеспечили пользователей инструментами, которые дают им возможность самим создавать витрины в хранилище Авито без привлечения специалистов. Эта история больше про подходы, решения и философию, которые позволяют жить в парадигме, когда потребностей на создание объектов DWH стало сильно больше, чем возможностей Data-инженеров.

Я работаю старшим фронтенд-разработчиком в it-отделе одного из крупнейших федеральных застройщиков. Специфика разработки в такой непрофильной компании — сроки спускаемые сверху и вообще не имеющие корреляции с реальными ресурсами и возможностями команды. Именно поэтому мы работаем очень быстро, постоянно пытаясь получить (максимум результата)*3 за (минимум времени)/4.

В этих условиях мы делали большие интеграции с headless CMS Directus и непосредственно с бекендом, используя моковые данные на фронте.
Интеграции были большие и быстрые — и вот тут-то и стало видно, что большинство фронтенд-разработчиков не очень понимают, как подготовить интеграцию, чтобы потом было быстро и не больно заменять моки на реальные ответы. В этой статье пойдет речь о таких подходах на фронтенде,