Если задать это простой вопрос самой нейросети, то получим ответ что это важно, и даже очень. Хочешь хороший ответ, подумай над структурой - это продают как аксиому.

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

Если задать такой промт на английском языке, где на минуточку последовательность слов важна даже для правильной грамматической конструкции (я уже молчу про формы слова, так как например в предложении о постройке дома лучше использовать слово house):

popular cheap north materials home build best russia time mistakes

то плюс минус все нейронки ответят примерно так:

You seem to be asking about popular, cheap building‑materials for homes in Russia, what’s “best,” how long it takes, and what mistakes to avoid. Here’s a concise, practical answer for building a house in Russia right now.

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

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

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

Конечно данный пример это слишком маленькое контекстное окно, и на самом деле это показательно. С увеличением контекста важность каждого токена и его расположение в промте стремительно падает. Вы конечно можете использовать слова Important, must, don't и подобные что бы разметить промт, но в конечном счете дешевле и точнее будет отправить несколько запросов с ключевыми словами, уточняя запрос 1-2 словами при необходимости.

Моя текущая стратегия по экономии это естественно английский язык - требует меньше всего токенов и легко сокращается. Контекст наращиваю очень аккуратно по 3-5 токенов (1-2 слова). Для примера исходный запрос можно сократить так и получить такой же результат.

pplr cheap north materials home bld best rus time mistakes

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

В фильме воссоздаётся пять исторических эпох, описывающих историю советского и российского реверс-инжиниринга за последние сто лет:

• 20–40-е годы, когда упор делался на военную промышленность и было важно знать, как устроены орудия врага, чтобы сделать свои ещё эффективнее.

• 60–80-е, когда появились первые большие ЭВМ.

• 90–00-е, когда массовая доступность компьютеров привлекла реверсеров, которые делали ПО бесплатным для всех.

• 10–20-е, сегодня, когда распространение технологий привело к лавине киберугроз.

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

Когда: показы пройдут 27 (пятницаи) и 28 (суббота) февраля, в 11, 15 и 19 часов
Место: «Кибердом» — Москва, ул. 2-я Звенигородская, 12с18

Регистрация через таймпад, количество мест сильно ограничено. Если не успели, но непреодолимо хотите — напишите в личку, что-нибудь придумаем.

2025 стал для нас годом перемен, открытий и испытаний (куда без этого в современном мире в эпоху AI). Он запомнится новыми фичами, ребрендингом, выставками и митапами от Москвы до Новосибирска.

Наша работа не имела бы такого смысла, интереса и отдачи без вашего участия. Спасибо, что делитесь с нами своим опытом. Каждая встреча на ивенте, обсуждение, баг-репорт и вопрос в чате помогают нам двигаться вперед.

Toп-7 фичей Veai по мнению наших пользователей

1. Генерация тестов по исполнению (статья на Хабре "Не LLM едиными: генерируем юнит-тесты из реального исполнения на лету")

2. Агентский режим (статья на Хабре "Как мы сделали AI-агента и пользуемся им на практике")

3. Пользовательские сценарии (Workflows)

4. Правила (Rules)

5. Анализ тестов на моргание (Flaky tests)

6. Увеличение тестового покрытия

7. Исправление падающих автотестов из TMS

2025

• 4 больших релиза, много EAP и nightly-сборок

• поддержка OpenIDE, GigaIDE, PyCharm, Rider, GoLand, PhpStorm и WebStorm

• участие в JPoint, Joker, Heisenbug, CodeFest и митапах в Москве, Санкт-Петербурге, Владимире и Новосибирске

• переезд в новый офис

• ребрендинг

• съели с коллегами 1040 пицц в офисе по пятницам :)

Мы уже работаем над следующим релизом и ждём возможности показать вам новые фичи.

С наступающим Новым годом — и спасибо, что вы с нами!

Команда Veai 🎄

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

Общее решение: Изменить процесс наема так чтобы он помогал нанять специалиста для решения задач бизнеса.

Конкретные варианты решения:

1. Использовать зарекомендовавшие себя решения в других воронках\процессах получения чего-либо. Например сарафанное радио и нетворкинг, кумовщину и рефералки, при этом отказаться от существующих фильтров в пользу доверия на старте.

2. Устранить причину мешающую текущему процессу наема. Например сократить цепочку ЛПР-ов на пути соискателя до оптимума.

   (Сейчас это авто-скрипт, эйчар(или ряд эйчаров), собеседующий специалист(или ряд специалистов), представитель команды(или ряд представителей), опционально тут еще какие-то посредники, и вот тут уже можно выйти на работу и работать 😁. Причем на каждом этапе у лже-ЛПР-ов есть цель отсеять человека на основании формального фильтра. Тогда как лучшие работники обычно "неформалы" ибо они про работу работать как Стив Возняк, а не про продукт(себя) продавать как Стив Джобс. Очевидно что не каждая птица долетит даже до середины.. 😢)

   Оптимум - это ван ту ван, один ЛПР-соискатель на одного ЛПР-нанимателя. Собеседовать можно сколько угодно, но в конце один ответственный человек собирает всю информацию в кучу (и это не оценки и выжимки специалистов, а прям сесть и посмотреть портфолио, видео собеседования, пересказ нейронки прочитать как минимум по этому видео, переписку, на свою текущую ситуацию по задачам и срокам посмотреть и т.д.) и на основе всех имеющихся данных принять полноценное решение.

   ЛПР - это тот кто принимает решение что считает лучшим на этот момент, а не тот который работает по прописанному скрипту (иначе это не ЛПР, а человек которого настоящий ЛПР назначил отрабатывать строго по скрипту 😜).

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

P.S. Все 3 варианта решения на самом деле про одно и то же, только заход с разных сторон: убрать не то что мешает обрабатывать заявки на чиле, в пол уха, левой пяткой, а убрать то что действительно мешает нанять сотрудника для решения конкретных задач. (Да стало много спама, ну и что? Разве то что много спама говорит о том что среди спама нет специалистов способных делать работу? Нет. Как раз таки в этом и заключается задача\работа нанимателя - нанять сотрудника в этих конкретных условиях. Ну да, придется поработать. Соискатель, наниматель и работодатель в одной лодке как ни крути, если кто-то не хочет грести, то далеко ли уплывет такая лодка?🛶)

Хорошего дня, наема и трудоустройства!

Обнял 🤗

В мире встроенных систем и цифровой обработки сигналов (DSP) ключ к быстрому прототипированию и надёжной отладке лежит через собственный инструмент — аппаратную платформу, точно отвечающую вашим задачам. Моя цель — отработать цепочку «аналог ↔ цифра ↔ FPGA ↔ ARM» в реальном времени, без лишних звеньев и оговорок. Именно поэтому я спроектировал собственную отладочную DIY-плату AD/DA с программируемым генератором тактовой частоты.

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

Плата выполнена в формате "Arduino" (?) и служит модулем для быстрой интеграции в платформы ARM+FPGA (Zynq-7000 или аналогичные) через стандартный 40-контактный разъём KLS.

В основу конструкции легла классическая SDR-структура: трансформаторы, АЦП, программируемый тактовый генератор, буфер тактового сигнала, ЦАП и интерфейсные сигналы на разъём KLS.

1. Аналого-цифровой преобразователь: AD9283

• 8-битный одноканальный АЦП с параллельным CMOS-интерфейсом.

• Частота преобразования до 100 MSPS.

• Сигнал PWRDWN и шина данных подаются с разъёма KLS.

• Вход с внешнего SMA через трансформатор дает дифференциальный сигнал для высокого SNR.

2. Тактовый генератор и буфер: Si514 & Si53306

• Программируемый кварцевый генератор Si514 формирует опорную частоту.

• Тактовый буфер Si53306 распределяет сигнал на АЦП, ЦАП и FPGA.

3. Цифро-аналоговый преобразователь: AD9744

• 14-битный одноканальный ЦАП с параллельным CMOS-интерфейсом.

• Частота преобразования до 210 MSPS.

• Сигнал SLEEP и шина данных подаются с разъёма KLS.

• Выход через трансформатор возвращает аналоговый сигнал на внешний SMA-коннектор.

Зачем и для чего: практические сценарии использования этой отладочной платы

1. Формирование и анализ сигналов

• Создания многокомпонентных тестовых сигналов (модуляции AM/FM, chirp-сигналов) для оценки пропускной способности и реактивности FPGA-ядра.

• Тестирования и калибровки входных трактов при различных уровнях амплитуды и частоты.

• Генерации шумовых или псевдослучайных сигналов для проверки устойчивости DSP-алгоритмов.

2. Отладка алгоритмов цифровой обработки в реальном времени

• Нужно прототипировать алгоритмы цифровой обработки данных непосредственно на связке ARM+FPGA и видеть результат «на лету».

• Использование платы в образовательных целях: для обучения студентов или коллег практикам embedded-разработки и современной цифровой обработки сигналов.

• Реализация и проверка в HDL алгоритмов, например, вейвлет-преобразования для анализа сигнала и выделения его локальных особенностей.

3. Сравнительное исследование реальной производительности ARM и FPGA-ядер

• FPGA-ядро: пропускная способность HDL-модулей FIR/IIR, вейвлет-анализ, дизайн HLS-функций.

• Сбор и визуализация метрик (latency, throughput, resource utilization) через ARM-API и JTAG-интерфейс FPGA.

• ARM-ядро: замеры FFT-блока, фильтров в Linux-окружении.

Заключение

Эта AD/DA-плата для ARM+FPGA обеспечивает точность, скорость и гибкость, необходимые как для исследований DSP-алгоритмов, так и для промышленных встраиваемых и исследовательских проектов.

Присоединяйтесь к https://t.me/dsp_labs — там выходят реальные бенчмарки, исходники и советы по оптимизации DSP-алгоритмов на ARM/FPGA платформах!

На верхушке айсберга видим технологии DWARF, PTRACE и ELF, а внизу — набор более редких технологий. 

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

PTRACE — системный вызов, который позволяет одному процессу (tracer) управлять и исследовать другой процесс (tracee).  

ELF (Executable and Linkable Format) — формат исполняемых двоичных файлов. 

DWARF (Debugging With Arbitrary Record Formats) — стандарт, описывающий формат .debug_xxx секций в ELF.

Что касается «подводных» технологий, упомянутых на картинке: применяя закон Парето, можно смело сказать что 80% знаний необходимы, чтобы реализовать только 20% функционала (и не самого важного). Но если хотите узнать о них больше, напишите в комментариях.

Подробнее о PTRACE, ELF и DWARF, а также о функциях, которые они реализуют в отладчиках на Rust, читайте в статье.

Это один из (потенциально многих) несвязанных инстансов открытого движка для прохождения курсов по Computer Science и создания новых. Крутая его фишка: визуализация алгоритмов, структур данных и концепций, таких как стили вызовов функций - ещё и с упражнениями для закрепления.

Контента бездна, рекомендую прокликать ссылки.

Сегодня хочу рассказать об инструменте Git, который может очень помочь при отладке. Этот инструмент называется git bisect.

Возможно, ты уже сталкивался с ситуацией, когда нужно выяснить, после какого изменения в коде проекта появилась ошибка. Перебирать все коммиты вручную — не самое приятное занятие. Особенно, если ошибка была допущена давно. Именно здесь на помощь приходит git bisect.

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

Использование git bisect начинается с запуска команды git bisect start, после чего ты помечаешь известные «хороший» и «плохой» коммиты соответствующими командами. Git затем предложит тебе проверить определенный коммит, и ты сообщишь, есть ли в нем данная ошибка. Процесс повторяется, пока не будет найден коммит, который послужил причиной появления бага.

Ссылка на доку здесь.

А тут мой тг-канал со свежими новостями из мира мобильной разработки.

Ключевые улучшения в проекте:

• кодовая база переведена на использование стандарта C++17. Для сборки GDB теперь необходим компилятор, поддерживающий C++17 (как минимум GCC 9);

• в индекс добавлена информация о функции main, что позволяет ускорить запуск при использовании с некоторыми большими исполняемыми файлами;

• прекращена поддержка ОС AIX 4.x, 5.x и 6.x (в качестве минимально поддерживаемой версии AIX заявлен выпуск 7.1);

• добавлена начальная встроенная поддержка протокола DAP (Debugger Adapter Protocol);

• добавлена поддержка переменной окружения NO_COLOR;

• добавлена начальная поддержка целочисленных типов размером больше 64 битов;

• внесены улучшения в Python API;

• добавлена поддержка точек остановки, привязанных к отдельным объектам отладки (при отладке нескольких процессов);

• добавлена функция "$_shell" для запуска команды в командной оболочке и возвращения результата;

• улучшена поддержка архитектуры AArch64. Добавлена поддержка расширений SME (Scalable Matrix Extension) и SME2;

• улучшена поддержка языка Ada и спецификации Ada 2022.

Источник: OpenNET.