Привет, Хабр! Новый год — хороший повод научиться чему-то новому. Длинные каникулы позволяют выйти из рутины, выспаться и наконец разобраться с тем, на что в обычные дни не хватает времени. В подборке собрали семь полезных курсов, которые помогут освоить нужные навыки. И главное — все бесплатно.
Это было интересное приключение.
Сразу оговорюсь: FlexMock не нужен всем подряд. Он вырос из моих собственных задач — когда нужно откуда-то получать разнообразные данные для собеседований, когда фронтенд уже в работе, а бэкенд ещё не готов, или когда нужно быстро собрать демо/прототип и не тратить вечер на мок-сервер.
Это мой первый публичный проект в формате “сделал сам и показываю миру”, без команды и заказа. Ниже расскажу, почему мне захотелось написать такой сервис, как он устроен на уровне идеи и в каких сценариях реально экономит время.
Буду благодарен за конструктивную критику — особенно за идеи, которые помогут сделать инструмент полезнее.
LLM учатся не только тому, чему мы пытаемся их научить. Вместе с задачами, метками и инструкциями они усваивают и побочные сигналы, которые мы воспринимаем как шум или случайность. Исследование международной группы учёных показало, что такие подпороговые сигналы могут работать как канал передачи поведения между моделями. Даже если убрать все явные инструкции, то стиль рассуждений, стратегии ответов и другие поведенческие признаки все равно просочатся через данные, которые семантически с ними никак не связаны.
Авторы называют этот эффект сублиминальным обучением. Мы можем удалить метки, отфильтровать инструкции и проверить датасет вручную, и всё равно передать модели поведение, которое не планировали передавать.
Привет, Хабр. С праздниками всех читателей! Меня зовут Павел, и одним из моих хобби является создание различных устройств на базе микроконтроллеров. Это моя первая статья здесь, и я буду рад конструктивной критике со стороны завсегдатаев Хабра.
У людей, лишь шапочно знакомых с кубиком Рубика, иногда возникает вопрос, можно ли собрать кубик, просто вращая грани случайным образом? Несколько раз я слышал истории о том, что кто-то долго крутил кубик и случайно собрал его. Во-первых, «долго крутил» не значит «случайно собрал»: Эрнё Рубик крутил свой первый прототип несколько недель, прежде, чем понял, как перемещаются его элементы, и вернул волшебный куб в исходное состояния. Во-вторых, собрать одну грань или один слой – не значит, собрать весь кубик (а некоторые воспринимают «почти получилось» как «получилось»). И, наконец, математика практически не оставляет шанса собрать кубик случайно. Поэтому будем развенчивать этот миф.
Они работали в коллекторской сфере. Привыкли к угрозам, обману и агрессии. Но когда к ним пришли с благодарностью — дали дорогу. Эта статья — про то, как взломать «непробиваемую» компанию через её самого главного человека. И почему технические защиты тут почти не при чём.
На некоторые вопросы ответить проще, чем на другие.
Много лет назад - больше, чем мне хотелось бы признать - в те времена, когда программное обеспечение устанавливалось с компакт-дисков, а для выхода в интернет нужно было ждать, пока модем дозвонится по телефонной линии, мы писали тексты с помощью текстовых процессоров.
Именно так Microsoft Word получил свое название: буквально версия текстового процессора от Microsoft. А до Word были терминальные редакторы вроде WordStar - которым, как известно, до сих пор пользуется Джордж Р. Р. Мартин.
В то время у нас были проверки орфографии. Гораздо более примитивные, чем современные инструменты в браузерах и приложениях.
Из руководства пользователя WordStar 4.0 - версии 1987 года, в которой до сих пор пишет автор «Игры престолов»:
Мы проверили, способен ли ИИ участвовать в реальной инфраструктурной операции повышенного риска — обновлении Kubernetes-кластера сразу через несколько minor-версий.
Речь не про «сгенерировать YAML» или «написать Helm-чарт», а про полноценную операцию:
Spec Kit - это один из самых амбициозных фреймворков для наведения порядка в разработке с использованием ИИ. В нашем предыдущем посте о spec driven development мы обсуждали его потенциал для закрытия давних пробелов в рабочих процессах с ИИ-ассистентами за счет обеспечения соблюдения стандартов проекта, контекста на уровне функций, принудительной декомпозиции для управляемого объема работ и контрольных этапов (review gates) для контроля качества.
Но исполнение - это то, где теория сталкивается с сопротивлением. Документация Spec Kit - это сильная отправная точка, с понятными видео, подробными руководствами и предписывающими шагами, которые позволяют развернуть его за считанные часы. Сложности начинаются, когда вы покидаете «песочницу». Подобно примерам Animal → Dog → Labrador в учебниках по ООП, примеры учат синтаксису, а не промышленной разработке программного обеспечения.
Пробел заключается не в документации, а в контексте и реальной экспертизе. Чистые примеры прекрасно работают для greenfield-проектов (проектов с нуля), но большинство команд работают с существующими (brownfield) кодовыми базами, сформированными месяцами эволюционирующих решений, компромиссами разработчиков, конкурирующими паттернами и не подлежащими обсуждению стандартами качества.
Этот пост отражает наш путь через эти испытания. Это не отполированная история успеха, а честный рассказ о том, что сработало, что нет, и как мы заставили Spec Kit работать в живой производственной системе, где компромиссы в качестве были недопустимы.
Почему команды отказываются от подхода «сначала код, потом исправления», когда ИИ ускоряет поставку сверх всякого контроля? Spec-Driven Development (разработка на основе спецификаций) представляет шестиэтапную модель, которая переносит архитектурные решения, ограничения и ясность на более ранние стадии (upstream). Узнайте, как это улучшает качество выходного результата, сокращает циклы очистки кода и позволяет AI-агентам работать согласованно в рамках мультисервисных систем.
Поставка программного обеспечения была ориентирована на реализацию большую часть своего существования: команды открывали редактор, пробегали глазами бриф спринта и начинали писать код. Этот рабочий процесс имел смысл, когда основными создателями были люди, репозитории развивались медленно, а конвейеры релизов были линейными и предсказуемыми. Теперь AI-агенты, такие как Copilot, Cursor и Windsurf, генерируют код быстрее, чем успевают реагировать архитектура, управление (governance) и интеграция. Код перескакивает от бэкенд-логики к конфигурациям инфраструктуры и CI/CD за часы, на что раньше уходили месяцы.
Когда такой подход «сначала код, разберемся позже» опережает архитектуру, безопасность и управление, система в конечном итоге рушится под собственным весом.
Модель, ориентированная на спецификации (spec-first), обращает этот коллапс вспять с помощью живых, исполняемых артефактов. Вместо того чтобы код вел процесс, спецификации становятся якорем (и источником), на основе которого действуют ИИ и люди. Они содержат решения о структуре, библиотеках, паттернах, соответствии требованиям и интеграции еще до того, как будет сгенерирована хоть одна функция.
Когда поведение меняется, команды обновляют спецификацию, и все последующие выходные данные следуют за ней. Поломки также устраняются путем обновления исходной спецификации, а не латанием симптомов в разных файлах. Чтобы увидеть, как Spec-Driven Development меняет темп и качество разработки с использованием ИИ, давайте разберем, что это такое на самом деле.
Странный заголовок, не правда ли?
А зачем вообще обходиться без id? Даже не знаю, но это вполне возможно, и приложение будет живым и вполне себе «реактивным». А всю «магию» при этом творит функция, которую я назвал tokenize.
Конечно же я, ни в коем случае, не настаиваю на отказе от id. "Элементарные" id никому не мешают и tokenize`у тоже. Но если обходиться без id, то как же получать ссылки на DOM элементы, для обращения к ним? Вот для этого и нужна функция tokenize, которая собирает референсы в удобную структуру с ветками, подветками и листьями (ссылками на DOM элементы). А вот как она это делает, мы с Вами сейчас и разберём.
В первой части мы написали базовый поиск gRNA с фильтрацией по GC-составу. Работает, но тупо: все кандидаты в диапазоне 40-60% считаются равнозначными. В реальности это не так.
Сегодня добавим систему скоринга — будем ранжировать gRNA по качеству, учитывая позицию нуклеотидов и особенности U6-промотора. Потом подключим NCBI BLAST, чтобы проверять кандидатов на off-target: не порежет ли Cas9 что-нибудь лишнее в геноме.
Тестировать будем на гене CCR5 — том самом, который отредактировал китайский учёный Хэ Цзянькуй в скандальном эксперименте 2018 года.
Перфолента.NET — это на удивление профессионально выглядящий язык программирования на платформе .NET, который поддерживает объектно-ориентированное и функциональное программирование, и на котором написан даже написан другой язык, функциональный язык программирования — Перфо.NET (интерпретатор).
Мой личный опыт
Когда я начал немного программировать на Перфоленте/Перфо, моё понимание языков программирования сильно изменилось. Я почувствовал себя как англоязычный программист, пишущий код на родном языке.
Это был очень интересный опыт. Я стал больше внимания уделять смыслу слов и терминов, стал строже относиться к названиям.
Раньше сложные понятия функционального программирования давались мне тяжело, но теперь всё стало проще. Лямбда-функции, замыкания, каррирование и т.д. — всё это я теперь понимаю по-другому. Особенно когда объясняю ребёнку.
Например, лямбда-функция — это просто формула из задачника по математике. Ребёнок понял это сразу! И мы пошли дальше, не останавливаясь.
По-моему, главный эффект даёт отказ от псевдонимов и алиасов. Я долго отучался давать названия, из которых сразу понятно, что это за сущность, а не «имена, которые означают...».
Второй эффект — это «сокращение контекста». Контекстное окно человека ограничено 3–5 вещами, которые он в состоянии держать в голове и обдумывать. «Псевдонимы/алиасы» съедают это контекстное окно. Поэтому избавление от прокладок в виде «print — это печать» и замена их на простые «вывести_в_консоль», «вывести_в_файл» и т.п. сильно облегчают понимание логики кода.
Вообще, методы в статье подходят и для любого IT-направления, но давайте сделаем акцент на безопасности.
В последнее время всё чаще вижу одни и те же вопросы:
«С чего начать в кибербезопасности?» или «Всем привет, хочу работать в инфобезе в Red Team, посоветуйте книжки, курсы и т. д., чтобы я через месяц стал чемпионом джунов и уже работал по профессии!» В какой-то момент понял, что пора собрать свои мысли (и не только мои) в один текст. Возможно, он поможет тем, кто только начинает.
Это первая статья цикла, предусматривающего рассмотрение логических схем или, более общо, логических процессов. Будет создан базис из логических элементов, позволяющих собрать любую схему. Специалистам, погруженным в бизнес-процессы, такая тема может показаться не стоящей внимания. Но мне тоже не понятно, почему бизнес-процессы выделяют в отдельную категорию. С формальной точки зрения они ни чем не отличаются от любых других процессов.
Таким образом, если вас интересуют общие проблемы параллельных процессов, то в этой и в последующих статьях на примере логических процессов мы их и рассмотрим. Терминологически мы будем придерживаться словаря по вычислительной технике под редакцией В.Иллингоута[1]. Но это может быть учебная литература, подобная [2], научная литература, как монография [3], или научно-популярные книги типа [4, 5].
Литературы по автоматам много. Бум пришелся на 80-е годы прошлого века, а сейчас лишь отголоски прошлого. Поэтому, с одной стороны, такой информационный массив позволяет выбрать наиболее подходящую литературу, но, с другой стороны, орождает множество толкований модели автомата, среди которых разобраться не так уж просто.
У меня сформировался свой вариант модели конечного автомата (КА), который далее будет основным. Данная модель, во-первых, очень близка к классической форме. А это важно, т.к. позволяет использовать теорию почти без исключений. А, во-вторых, она удобна для практики программирования, допуская эффективную ее реализацию. Более детально все эти вопросы освещены в статье [6].
Нассим Талеб говорил: «Люди думали, что Мандельброт писал о хаосе. На самом деле он один пытался навести в нём порядок». «Он был единственным, кто по-настоящему понял природу риска». «Если хочешь понять неопределённость — начни с Мандельброта.»
Книга Мандельброта: «(Не)послушные рынки. Фрактальная революция в финансах».
Казалось бы, мы все в курсе, что мошенники существуют и знаем как они действуют. Думается, «я то точно не попадусь». Но как оказалось, они становятся всё изобретательней.
Вот краткий пересказ моей истории.
Отдел планово-экономический тратил 6 часов каждый месяц на поиск ошибок в ценах МПЗ. Вручную проверяли 500 позиций из 16,000, пропуская критичные аномалии. Я автоматизировал процесс через связку SQL + MCP + Claude AI. Теперь система за 15 минут находит все отклонения, выявляет паттерны мошенничества (дробление закупок, откаты) и даёт план действий с оценкой ROI. Первый запуск выявил потенциал экономии 650K — 1.6M руб/год. Под капотом — техническая реализация с кодом, SQL‑запросами и примерами AI‑анализа.
Продолжаю изучать различные UI/UX/CX кейсы в мобильных приложениях, веб-сайтах и в реальном мире. Дизайнерам и менеджерам по продукту, чтобы вдохновиться и добавить в заметки.
Под катом: Revolut, Forest, Airbnb.
В настоящее время многоядерные процессоры с гетерогенными архитектурами, в которых сочетаются ядра с различной производительностью, становятся всё более и более распространенными. Если ещё пару лет назад такие архитектуры были в основном распространены в мобильном сегменте (см. ARM BIG.little), то с анонсом в 2022 году компанией Intel процессоров 12-го поколения линейки Intel Core, такие процессоры стали распространяться в сегменте десктопов и рабочих станций. Однако, до сих пор остается открытым вопрос — необходимо ли каким‑то специальным образом учитывать особенности данных архитектур для достижения максимальной многопоточной производительности?
