Разработка

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

В качестве противоположного примера возьмём Levels.fyi. Сегодня этот сайт помогает миллионам разработчиков сравнивать зарплаты и карьерные перспективы, но в начале его «бэкендом» были просто Google Формы, сохраняемые в Google Таблицы. Никаких микросервисов, никакого Kubernetes, никакой шины событий. Самые простые инструменты, которые можно придумать. Такая легковесная система обеспечила владельцам сервиса скорость её развития. Они проверили жизнеспособность идеи, расширили аудиторию и начали вкладываться в более сложные системы только тогда, когда стало ясно, что продукт рабочий. Иными словами, простота не стала для них препятствием, а превратилась в залог успеха. Стоит также помнить о том, что некоторые из самых сложных инфраструктур изначально были очень простыми: например, Airbnb, Facebook*, Reddit. Прежде, чем завоевать всемирную популярность, они были фрагментарными монолитами.

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

Привет! Я Рамиль Сакаев — аналитик в команде Авито Авто. В статье рассказываю, как адаптированная RFM-методология помогла нам выявить недоработанные зоны CRM-коммуникаций и создать бенчмарк для маркетологов.

В начале 1960-х у нас и в Америке появилась новая разновидность машинного зрения – лазерная, и приборы лазерного машинного видения – лидары. Во второй половине того десятилетия уже продавались промышленные тепловизоры. В основанном в 1966 году Центе искусственного интеллекта Стэнфордского исследовательского института построили программируемого робота колесиках, оснащенного антенной, телекамерой, ультразвуковыми дальномерами и чувствительными демпферами на случай столкновений, способного двигаться по заданному пути, самостоятельно обходя препятствия, а поскольку он при этом все время сам трясся, его так и назвали Shakey (Трясун). Уиллард Бойл и Джордж Смит из Bell Labs изобрели ПЗС-матрицу из светочувствительных диодов, которую окрестили «вездесущим цифровым глазом», новой цифровой ипостасью фотопластинок, фотопленок, телекамер, фотоэлектронного умножителя и т.п. 

Определить характерные события ожидания (wait_event), оказывающие влияние на снижение производительности СУБД в ходе нагрузочного тестирования при наличии лишних индексов на тестовые таблицы.

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

Вместе с описанием новой функциональности в этой статье отдельное внимание уделяется численным методам и подходам к поиску точек срединных поверхностей.

За 6 лет опыта работы в разных IT-компаниях — ни разу не встречал проекты на Laravel, где использовался бы CQRS. Да и погуглив немного, если честно, не нашел ничего стоящего (касательно примеров), поэтому решил сам написать статью на данную тему.

TL;DR

• Я впервые купил на Amazon электронную книгу

• Android-приложение Kindle самой компании Amazon было очень забагованным и часто вылетало

• Попробовал скачать мою книгу, чтобы читать её в реально работающем приложении для чтения

• Осознал, что Amazon больше не позволяет этого делать

• Решил назло выполнить реверс-инжиниринг её системы обфускации

• Обнаружил множество слоёв защиты, в том числе рандомизированные алфавиты

• Победил их все при помощи колдунства с сопоставлением шрифтов

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

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

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

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

В этом техническом разборе рассмотрим, как инженеры Harness обнаружили и исправили критическую утечку памяти в Go: переназначение переменной контекста в циклах воркеров порождало невидимые цепочки, мешавшие сборщику мусора освобождать память в тысячах горутин, из-за чего их сервис-делегат CI/CD в итоге потреблял гигабайты памяти.

Представьте: вы получаете алерт "сервер тормозит" или замечаете странные лаги в приложении. Отставить панику)) В этой статье мы разберем, как провести технический осмотр Linux-сервера и найти корень проблемы без углубления в тонны логов.

Сейчас расскажем вам про методику RED S.O.S. - структурированный подход, который превращает хаотичную проверку в системный диагноз. Это ваш чеклист для экстренного реагирования. Он не заменяет системы мониторинга (Prometheus, Zabbix), но дает моментальный снимок здоровья системы.

Фокус здесь на ключевых ресурсах: Resources (Ресурсы), Errors (Ошибки), Dependencies (Зависимости)

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

В 2024 году группа исследователей из Лейденского университета провела масштабный метаанализ по эффективности обучения в сфере информационной безопасности. Из двух тысяч научных работ в финальный анализ попали 69 исследований.

Разбираемся, что выяснили учёные, и какие из этого можно сделать практические выводы, если вы работаете в ИБ или отвечаете за awareness-программы.

ANR — это не просто “зависание”, а молчаливый краш, который напрямую бьёт по удержанию пользователей. В статье разбираю, как работает механизм ANR, какие ошибки его вызывают, как анализировать traces.txt, какие библиотеки помогают отслеживать блокировки (ANR-WatchDog, ANR-Spy, Firebase Crashlytics), и как построить процессы, чтобы QA-команда научилась ловить их ещё до релиза.

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

Приветствую всем снова! В первой части мы с вами долетели из Перми в Москву, разобрались с логистикой и ценами, послушали утренние и дневные доклады Smart‑Lab Conf 2025 — от макропрогнозов до психологии трейдинга — и даже успели заглянуть на «тайную встречу» в Парке Горького. Я также поделился первым и, пожалуй, главным выводом: разительным контрастом между порой токсичной онлайн‑атмосферой Смартлаба и абсолютно конструктивной, уважительной обстановкой на офлайн‑конференции.

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

Ирония судьбы — фото с Тимофеем у меня действительно есть. Точнее, даже двойное: с живым и с картонным.

А пока — вторая половина дня. В этой части мы погрузимся в вечерние, возможно, самые лучшие доклады. Я поделюсь впечатлениями от легендарного афтепати. Мы порассуждаем о том, что на самом деле даёт статус спикера, кроме строчки на сайте визитке (спойлер: это не только тщеславие). И, конечно, подведём окончательный и беспощадный финансовый итог: я соберу все свои траты и покажу, стоила ли эта поездка своих денег. Продолжаем!

Ура! Состоялся публичный релиз разработанной Сбером модели Kandinsky Video в Telegram-боте GigaChat и Kandinsky. Модель умеет создавать видео по тексту и оживлять изображения.

Всем привет! Я — Михаил Ша́рдин из Перми, энтузиаст автоматизации в трейдинге. Меня иногда путают с Александром Шадриным, автором блога «Разумный инвестор». Наши фамилии действительно схожи, но разные как и наши подходы: он пишет о долгосрочных инвестициях и стоимостном подходе в духе Баффетта и Грэма, а я — о технической стороне инвестиций, автоматизации и практических инструментах для частного инвестора.

На Smart‑Lab Conf 2025 я прилетел чтобы выступить с докладом про Python, Excel, API (а также чуток про машинное обучение) и одновременно окунуться в атмосферу главного события частных инвесторов России. Я хотел услышать опытных людей, посмотреть реальные кейсы и найти идеи для инструментов и статей.

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

Также я подробно расскажу про все доклады на которых побывал.

Solo developer journey: Как я довел B2B платформу от 8.5/10 до 8.8/10, исправил 13 критических багов, прошел Context7 MCP аудит и успешно задеплоил на production с первыми пользователями.

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

Аббревиатуры MES, WMS, ERP и им подобные давно стали синонимами цифровизации. О них пишут, их предлагают, их «внедряют». Но за красивыми терминами часто теряется суть — какую конкретно задачу решают эти системы? 

В этом материале мы поговорим о MES (Manufacturing Execution System) — системе управления производственными процессами. Благодаря маркетинговым обещаниям, в массовом представлении MES часто выглядит как «серебряная пуля». Стоит ее внедрить — и брак волшебным образом исчезнет, себестоимость устремится к нулю, а производительность взлетит до небес. Звучит заманчиво, но насколько эта картина соответствует реальности?

Меня зовут Иван Балашов, я руковожу направлением цифрового производства в К2Тех. Мы занимаемся внедрением именно таких решений на промышленных предприятиях. В основе этой статьи — живой кейс, и я предлагаю посмотреть на MES без розовых очков и разобрать на примере, как MES повышает эффективность бизнеса.