Последние годы генеративные большие языковые модели (LLM), такие как ChatGPT и YandexGPT, стали неотъемлемой частью многих продуктов и сервисов. С ростом популярности этих моделей возникли и новые угрозы безопасности — одной из самых актуальных стали промпт-инъекции. Что это такое, и почему это важно?
В мире php-ходящих есть мнение, что первое, что сказал Иисус Христос придя в этот мир: "исключения - зло".
Конструкция по типу try { .. } catch (Exception $e) { ..$e->getMessage() } знакома каждому 5 человеку в мире и воспринимается как неотъемлемая часть любой логики на php.
И что в этом такого?
Ничего, кроме того, что из чёткой цепочки обработки запросов ваш код быстро превращается в коллекцию try catch на каждой 3 строке. Это не кажется проблемой до того момента, как дело не дойдёт до разделения приложения на отдельные слои во благо SOLID. Представьте, что в вашей команде >1 человека и все они работают над разными слоями, которые должны между собой взаимодействовать. В подобных ситуациях все участники должны документировать все созданные методы, а так же возвращаемые исключения. И да, это хорошо, но зачастую документация исключений становится невыносимой. Таким образом ваша работа обрастает ненужным слоем прокидывания исключений, которые к слову нужно ещё и создать.
Вы упорно занимались, трудились, и вот наконец настал день, когда вы готовы выложить ваше первое приложение в AppStore. Вы правильно делаете, что читаете эту статью с шампанским 🍾, а на вечер у вас забронирован бар, однако не спешите, придётся ещё немного попотеть.
Давайте разберемся, как опубликовать наше первое приложение в AppStore.
Сообщество разработчиков всегда вдохновляло меня своей открытостью и культурой обмена знаниями. В мире дизайна всё иначе — чаще показывают только финальные работы, а процесс и инструменты остаются за кадром. Хотя open-source — это не только про код, а про культуру: делиться, улучшать, переосмысливать и переиспользовать.
В этой статье делюсь опытом создания инструментов для дизайнеров, которые можно не просто посмотреть, а сразу использовать в своей работе. Рассказываю о запуске Collected — бесплатного конструктора портфолио, Swarm — платформы для онлайн-выставок, и Everywhere.tools — коллекции open-source ресурсов для дизайнеров.
Оптический бюджет в ВОЛС: Невидимая грань между работоспособностью и отказом. Как не оступиться в эпоху 100G+ и плотных ЦОД?
Представьте: вы спроектировали идеальную магистраль, выбрали "качественные" компоненты, смонтировали... И линк не поднимается. Или работает, но с ошибками. Или стабилен сегодня, но "падает" при нагреве летом. Часто корень зла кроется в нарушении оптического бюджета мощности (Optical Power Budget - OPB). Это не абстрактная цифра из даташита – это фундаментальный закон сохранения энергии в мире оптики. Игнорируете его – гарантируете себе головную боль. Сегодня, с ростом скоростей (100G, 400G, 800G) и плотности в ЦОД, понимание и точный расчет OPB критичны как никогда. Давайте разберемся, что это, из чего складывается, где поджидают ловушки и как избежать фатальных ошибок.
1. Суть Оптического Бюджета: Проще, Чем Кажется (На Словах)
По сути, OPB – это разница между мощностью, которую передатчик (Tx) излучает в волокно, и минимальной мощностью, необходимой приемнику (Rx) для корректной работы (чувствительностью) с учетом требуемого запаса (System Margin).
Упрощенная формула:OPB = P_Tx_min - P_Rx_min - System_Margin
Где:
Если вы проводите большую часть дня в Visual Studio Code (как и я), то вы понимаете, что это больше, чем просто редактор кода. Это ваш настоящий командный центр, не меньше. С правильными расширениями VS Code может стать мощным инструментом, который повысит вашу производительность, обеспечит чистый код и даже сделает отладку (почти) безболезненной. Конечно, сейчас кто-то подумает, ну зачем мне нужны эти расширения? Установите, и вы поймете почему.
Я собрал 10 расширений VS Code, которыми сам пользуюсь, и которые особенно будут полезны для корпоративных разработчиков, работающих над сложными, совместными и масштабными проектами. Независимо от того, сосредоточены ли вы на написании более чистого кода, раннем выявлении ошибок, оптимизации рабочих процессов Git или совместной работе с удаленными коллегами в режиме реального времени, здесь есть что-то, что сделает вашу жизнь кодирования более гладкой и быстрой.
Год назад я вышел на очередную работу в бюджете, и как это часто бывает, начал все с нуля. Была дана куча архивных документов и папок, как физических, так и в цифре, 7 подразделений и около 30 человек «штатки». Название из серии «департамент цифрового развития», где каждое слово можно смело ставить под сомнение.
Другими словами, самая обычная классическая ситуация в бюджетной сфере. Все ушли — наследования знаний — нет, прошлого сотрудника тоже — «Добро пожаловать в бюджет».
Мы реализовали мультирегиональность на eCommerce-платформе OpenPets с помощью поддоменов, геолокации по IP, MODX и интеграции с CRM. Делимся архитектурой, кодом, решениями и подводными камнями.
Это - третья публикация в серии DDD и кодогенерация. (первая часть). В этой статье мы сгенерируем код класса для хранения всех данных запроса, код MVC контроллера. И наконец-то уберем рефлексию (но оставим наши типизированные атрибуты).
За последние три года, посетив более 50 заводов различных отраслей, я всё больше убеждаюсь: система управления на многих из них напоминает вождение автомобиля 1915 года. Завел с ручки, поехал со скоростью 20 км/ч, и неизвестно, доедешь ли сегодня в точку Б в двух кварталах, не говоря уже о более дальних поездках.
Многие директора заводов испытывают острую нехватку оперативных данных о текущем состоянии предприятия. Им нужны данные не за прошлый месяц, не с двухдневной задержкой, а в режиме реального времени. Вместо этого приходится заниматься «посмертным» анализом, выискивая узкие места по устаревшим данным. Ситуация меняется, появляются новые проблемы, а мы всё боремся с «демонами» прошлого.
Особую «радость» вызывают ручные замеры и бумажные инфоцентры завода или цеха. Десятки, а то и сотни человеко-часов в месяц тратятся на, казалось бы, правильную работу. Но вокруг цифровизация, а мы стоим у станка с бумажкой, записывая каждый простой. Пять цехов, 5-10 ключевых станков в каждой из трех смен, 10 тысяч подобных заводов в стране… К армии курьеров маркетплейсов смело можно добавить армию замерщиков.
Сравните: вы садитесь в современный автомобиль. Настраиваете зеркала, кресло, руль, пристегиваетесь, включаете зажигание и быстро оцениваете панель приборов: уровень бензина, давление в шинах, чек двигателя. Начинаете движение, следя за скоростью, температурой двигателя, дорожными знаками. Для этого не нужно техническое образование, чтобы доехать из точки А в точку Б за разумное время.
Когда-то умение работать с алгоритмами и кодом считалось для всякого трейдера гигантским преимуществом. Но с недавних пор ситуация изменилась. И если вы хотите системно-эффективно торговать на рынке (неважно, крипта это или фонда), алгоритмическая торговля для вас – уже не жирный плюсик к карме, а острая необходимость.
Потому что в большинстве случаев вы конкурируете уже не с людьми, а с кодом, даже если открываете сделки вручную. В статье делаем первый шаг к обучению алгоритмической торговле на TradingView и знакомимся с основами Pine Script через реализацию RSI. На мой взгляд, это идеальная связка для тех, кто хочет быстро войти в сферу и не тратить время на настройку инфраструктуры (или, возможно, даже никогда не программировал).
Недавно стукнуло 3 года, как я работаю менеджером продукта. В порыве ностальгии перебирал старые записи и натолкнулся на свой конспект в период стажировки. В конспекте были записаны вопросы, которые я себе задавал на старте. Это натолкнуло меня на одну сумасшедшую мысль, которую, положа руку на сердце, я давно хотел реализовать, но стеснялся это сделать.
Я собрал большой список вопросов по профессии Product Manager'a и получилось очень внушительно! Там собрано всё, что только я смог вспомнить: от базовых принципов до конкретных фреймворков. Слава роду ChatGPT, который помог сгруппировать больше 120 вопросов и отсортировать от простого к сложному. Вопросы разбиты на смысловые «главы».
Решил написать ответы на все вопросы и публиковать отдельными постами в формате телеграм канала (а как еще). Для потомков, так сказать (для себя то есть), решил собрать все посты первой «главы» в одну большую статью для Хабра. Вдруг какой-то заблудшей душе будет полезно.
На данный момент полностью готово две главы. Первую предлагаю прочитать прямо сейчас. Буду публиковать по одному ответу в день в телеге и большими статьями по главам здесь.
Важно: это не учебник! Это мой опыт упакованный в формат FAQ. Для новичков, для комьюнити, для себя.
Я хочу поделиться практическим подходом, который позволяет переиспользовать ваш игровой код на C# из Unity на .NET-бэкенде — это даёт возможность верифицировать действия игрока, защищает от читерства и обеспечивает мгновенный отклик без лагов.
Я использую такую архитектуру в продакшене уже более 10 лет, и она отлично зарекомендовала себя как надёжное и эффективное решение. В этой системе один и тот же код выполняется и на клиенте (для мгновенной обратной связи), и на сервере (для авторитетной проверки).
Как это работает:
• Команды игрока мгновенно выполняются на клиенте.
• Та же команда вместе с хэшем состояния отправляется на сервер и повторно выполняется для верификации.
• Любые попытки изменить код или память клиента будут обнаружены и отклонены сервером.
• Игровая логика вынесена в .dll-плагин, который используется и в Unity-клиенте, и на .NET-бэкенде.
В статье есть полноценный пример на Unity («Connect Four»), открытый исходный код и подробное описание архитектуры.
В статье подробно разбирается план выполнения запроса с оконной функцией в MS SQL Server, проводится сравнительный тест производительности с альтернативным запросом.
Статья будет полезна разработчикам, работающим с аналитическими запросами в SQL Server, а также всем, кто хочет глубже понять логику оптимизатора и влияние различных факоров на планы выполнения.
Почему нам на самом деле не угрожает искусственный интеллект? Или он всё же опасен? Автор считает развитие ИИ безобидным следствием прогресса, удобным инструментом, не более. Об этом и поговорим
Глубокое обучение - Способ обучения моделей на большом количестве данных, используя множество слоёв. Каждый слой сети обрабатывает информацию, "взвешивая" её при помощи параметров (весов и смещений), оставляя признаки или отбрасывая, посредством функций активации. Обучение происходит через итеративную (повторяющуюся) корректировку весов: сначала вычисляются градиенты ошибки с помощью обратного распространения (backpropagation), а затем веса обновляются при помощи оптимизаторов (SGD, Adam и др.).
Эта статья не ответит на все вопросы, но мы пробежимся по всем основам глубокого машинного обучения, что бы создать примерную начальную картину без сильного углубления в детали.
Всем привет! Меня зовут Роман Мироничев, я руковожу проектами в ИТ сфере. Эта статья написана в связи с желанием поделиться опытом в управлении проектами с теми, кому эта область интересна. В процессе работы я постоянно изучал разные материалы об управлении, в маркетинге и ИТ - но практических кейсов встречал не так много, поэтому решил поделиться своими. Надеюсь, это найдет отклик у тех, кто интересуется темой проектного управления, и материал будет полезным.
В процессе написания статьи по проектному менеджменту и подготовке материала, я получил опыт работы в геймдеве - который окончательно подтвердил некоторые мои гипотезы в управлении проектами и поэтому в материале перекликается управление ИТ проектами вместе с игровой разработкой.
Меня всегда интересовало, что именно отличает успешные проекты от неудачных, какие факторы делают команду эффективной и как настроить процессы так, чтобы проект стабильно достигал поставленных целей — в срок, в рамках бюджета и с качеством, превышающим ожидания. Как функционирует проектный офис в крупных организациях, где параллельно идут десятки, а то и сотни проектов? Что обеспечивает устойчивость этой системы, при которой каждый проект со своими уникальными особенностями движется к цели и достигает результата?
Изначально этот материал создавался как часть курса по проектному менеджменту, однако в процессе подготовки он трансформировался в статьи, что более доступно для ознакомления и в компиляцию ключевых идей и наблюдений, которыми я хотел поделиться. Это не теоретическое изложение, а выжимка из моего опыта, оформленная в виде размышлений и практических выводов.
Многие начинают знакомство с Home Assistant «как есть» — с минимальными настройками и базой данных SQLite. Это отличный старт, особенно если вы только строите свой умный дом. Но когда система обрастает датчиками, автоматизациями и историей, SQLite начинает тормозить.
Решение — перейти на более производительное хранилище данных, такое как PostgreSQL.
В этой статье покажу, как выполнить миграцию с SQLite на PostgreSQL, сохранив накопленную статистику и избежав ошибок. Всё проверено на Home Assistant 2025.5.
В статье приводиться пример реализации протокола ModBud RTU Slave используя инструментарий STM32Cube IDE (version 1.12.0).
В последнее время часто приходиться реализовывать устройства для промышленности с применением протокола обмена данных ModBus RTU, используя младшие контроллеры stm32 без использования систем реального времени. Предлагаю один из вариантов реализации, который может пригодиться начинающим разработчикам.
Итак.
Акротири — древний город на греческом острове Санторини, который процветал несколько тысяч лет назад, но был внезапно погребён извержением вулкана. Его часто называют «Помпеями Эгейского моря», потому что вулканический пепел сохранил дома, предметы быта и уникальные настенные росписи.