Все потоки

Это всё началось с изобретения слова “бойлерплейт” в 2012 году. Всем было страшно, что им придётся писать аж по три строки вместо одной. Поэтому все начали насиловать компиляторы и добавлять в них новые функции — только бы (НЕ ДАЙ ГОСПОДЕ БОЖЕНЬКА!!!) не писать дополнительно два символа.

В 2025 году у нас есть ЛЛМ. И не надо врать — я знаю, что вы не набираете код, за вас это делает ЛЛМ. Я не говорю, что вы не вычитываете этот код и не перепроверяете всё. Нет. Но печатает за вас ЛЛМ. И это — нормально.

Пусть она занимается этим бойлерплейтом. Иногда это — самое простое решение. Если у меня есть один файл, в котором чётко видно, в какие функции инвокаются какие рауты, то это — прекрасно. Не надо создавать фабрику, которая будет строить псевдообъекты, которые потом по гаданию на картах Таро будут инвокать методы на основании положения Марса в Стрельце.

Пусть ЛЛМ за вас напишет файл с 500 строками кода, где каждому URL дан чёткий метод. И если вам надо будет переименовать 300 из этих методов, то пусть ЛЛМ это и сделает. Не велика проблема.

В 2025 году можно смело откатить все нововведения Яваскрипта до 2016 года — и не париться больше в попытках улучшить язык. Просто сделайте его стандартом и больше не меняйте. Пусть ЛЛМ будет страдать. Нам не страшно.

Зато потом это будет проще понять и прочитать, чем вспоминать, что делает последовательность символов ?./\ ﷼ℬ в вашем коде и какой транспайлер мне надо поставить, чтобы это компилировалось в Google Chrome версии 18384572.

Я уже одурел читать про прекрасный ИИ, который скоро сделает нам светлое будущее уже совсем скоро, надо только подождать.

Но обложки статей, новостей и постов УЖЕ стабильно вызывают рвотный рефлекс своей однообразностью, скукой и безыдейностью. Они и так почти никогда не отличались кач-вом, а сейчас так вообще отбивают желание скролить ленту. Уже видел шестипальцевые рекламные плакаты в реальности и первый shortfilm на агрегаторе sci-fi.

Рыночек решает, но как то мерзко, мы действительно хотим будущего состоящего из миллиардов на выгенеренного шлака, размазанного по всему нашему бытию?

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

PS нет я не дизайнер.

Утечка системного промпта Claude 3.5 Sonnet: что произошло

TL;DR: произошла утечка системного промпта Claude 3.5 Sonnet.

Недавно в открытом доступе на GitHub появился файл с системным промптом модели Claude 3.5 Sonnet от Anthropic. В этой заметке мы подробно разберём, что именно было обнародовано, как устроен промпт и какие риски несёт его утечка.

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

• Оригинальный файл:

  https://raw.githubusercontent.com/asgeirtj/system_prompts_leaks/refs/heads/main/claude.txt

• Содержимое:

  • Описания «артефактов» (artifacts) — самостоятельных блоков контента (отчёты, письма, презентации).

  • Правила запуска «структурированного мышления» в тегах <antthinking>.

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

  • Ограничения по объёму и форматированию, а также рекомендации по стилю.

Небольшой анализ этой утечки:

1. Артефакты
   Системный промпт описывает «артефакты» — XML-подобные блоки (отчёты, письма), которые модель генерирует для структурированного редактирования.

2. Структурированное мышление
   Перед формированием сложных ответов включаются теги <antthinking>, задающие пошаговый алгоритм анализа запроса и выбора формата вывода.

3. Фильтрация и объём
   Короткие ответы (1–2 предложения) выдаются без артефактов; при этом заданы жёсткие лимиты на размер и глубину артефактов во избежание «раздувания» текста.

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

На всякий случай, файл с GitHub'a залил в облакo [ Upd: администрация Telebox, как выяснилось, имеет доступ ко всем файлам, даже беспарольным архивам, и уже дважды удалила файл] и Web archive [здесь файл жив и здоров], чтобы у каждого была возможность покопаться в недрах этого конфига. Честно говоря, до сегодняшнего дня ни разу не пользовался данной моделью от Anthropic, теперь есть повод поэкспериментировать :).

PS. Это мой первый пост, друзья, так что, если найдёте какие-либо недочёты, пожалуйста, укажите на них!

Большие языковые модели (LLM) обычно требуют мощного оборудования и потому запускаются в облачных сервисах, а без подписки их функционал ограничен. Однако Google Gemma 3 — исключение.

Google Gemma 3 — это семейство открытых моделей, некоторые из которых достаточно легковесны, что их можно использовать локально.

Модели Gemma 3 созданы на основе Gemini 2.0 и доступны в четырёх вариантах: 1B, 4B, 12B и 27B, где B — миллиарды параметров. Самая лёгкая модель 1B работает только с текстом, а все остальные — мультимодальные, то есть обрабатывают текст и картинки.

Модели на 4B, 12B и 27B параметров поддерживают более 140 языков и хорошо справляются с переводом текстов, модель на 1B параметров работает только с английским.

Главная особенность Gemma 3 — умение обрабатывать длинные запросы и анализировать объёмные документы благодаря большому контекстному окну (128K токенов для моделей 4B, 12B и 27B).

Вариант 4B особенно универсален: сжатая версия (int4) требует всего 3 ГБ видеопамяти, а несжатая версия (BF16) — около 8 ГБ VRAM, что позволяет запускать модель на видеокартах среднего класса.

Модели Gemma 3 совместимы с Windows, Linux и macOS.

• Поддержка Apple Silicon через MLX даёт возможность запускать Gemma 3 на Mac и iPhone (инструкция).

• Для запуска Gemma 3 можно использовать Python-библиотеку transformers (инструкция).

• Ещё один способ установки Gemma 3 на компьютер — через фреймворк Ollama. Он прост в установке и доступен на Windows, Linux и macOS.

• Для удобства работы с моделью можно добавить веб-интерфейс Open WebUI.

Помимо Gemma 3, для локальной установки подходят и другие облегчённые модели, но у них своя специфика:

• Llama 3.3: требует больше ресурсов и не является полностью открытой;

• Mistral 7B, Qwen2.5 и Phi-3 Mini: легковесны, но имеют меньшее контекстное окно;

• DeepSeek-R1: конкурент Gemma 3 27B по качеству, но требует значительно больше ресурсов.

ГОСТ Р 56939-2024 – Разработка безопасного программного обеспечения (РБПО)

20 декабря 2024 года введён ГОСТ Р 56939-2024 взамен ГОСТ Р 56939—2016. Хотя уже прошло около полугода, не все про это знают, осознают это или как-то подстраиваются под произошедшие изменения :) А изменения есть, так как новый ГОСТ ориентирован на построение и контроль процессов, обеспечивающих цикл безопасной разработки в компании.

Несколько информационных моментов.

1. Цикл публикаций в моём канале "Бестиарий программирования" на тему РБПО

Я начинаю большой цикл публикаций в Telegram, посвящённый РБПО и ГОСТ Р 56939-2024. Приглашаю подписываться всех, кто хочет постепенно знакомиться с этой темой и разбираться в ней.

2. Вебинары РБПО-направленности

Мы уже провели совместно с другими компаниями два вебинара, связанных с ГОСТ Р 56939-2024:

1. Интеграция статического анализа и DevSecOps: PVS-Studio и AppSec.Hub в действии.

2. Внедрение процессов безопасной разработки. Интеграция PVS-Studio и SGRC SECURITM.

Приглашаем принять участие в следующем совместном с "ИНСЕК" вебинаре "Регулярный статический анализ по ГОСТу" (21 мая 12:00 по Москве), где они презентуют InSeq RBPO.

Приглашаем и другие компании к технологическому и/или информационному сотрудничеству. Напишите нам в поддержку или моему ассистенту.

3. Сертификация ФСТЭК

В последнее время нас спрашивают, подходит ли PVS-Studio для сертификации, и есть ли у нас сертификат ФСТЭК?

Для PVS-Studio нет сертификата ФСТЭК, так как он не нужен (для статических анализаторов процедура сертификации является добровольной).

PVS-Studio может использоваться как инструментальное средство статического анализа кода при построении процессов РБПО по ГОСТ Р 56939-2024.

PVS-Studio успешно применяется испытательными лабораториями, аккредитованными в системах сертификации средств защиты информации ФСТЭК России в рамках работ по сертификационным испытаниям программных продуктов, так как соответствует необходимым критериям (для заказчиков и сертификационных лабораторий мы подготовили информационное письмо):

• PVS-Studio включён в Реестр российского ПО (запись № 9837 от 18.03.2021);

• PVS-Studio удовлетворяет функциональным требованиям к инструментам статического анализа кода, описанным в Методическом документе "Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении" (издание второе, доработанное, утверждён ФСТЭК России 25 декабря 2020 г.);

• продукт разрабатывается с учётом требований, предъявляемых к статическим анализаторам в ГОСТ Р 71207–2024.

Подробнее: Сертификация ФСТЭК. Если у вас есть вопросы, напишите нам в поддержку или позвоните по телефону +7(903)844-02-22.

Можно ли использовать мат из других языков в российских товарных знаках?

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

Расшифровка этого нормативного положения содержится в многочисленных актах органов власти:

1. Приказ Минэкономразвития России от 20.07.2015 № 482. Ведомство указывает, что, рассматривая вопрос, противоречит ли заявляемое обозначение представленным выше параметрам, — учитывается, в том числе и, например, непристойность внутреннего содержания, антигуманность, оскорбление человеческого достоинства и многое другое.

2. Приказ ФГБУ ФИПС от 20.01.2020 № 12 (ред. от 25.03.2022). Обозначениями, которые противоречат общественным интересам и указанным принципам, считаются такие объекты, которые выступают против установленного порядка и могут также спровоцировать справедливое возмущение со стороны других граждан. 

3. Приказ Роспатента от 23.03.2001 № 39 (ред. от 06.07.2001). В данном нормативном акте акцентируется внимание на том, что обозначения, заявленные к регистрации и включающие неудобоваримые комбинации, относятся к категории «скандальные». Чтобы их правильно оценить (и, соответственно, решить вопрос: можно ли зарегистрировать) — эксперты должны учесть фактор восприятия объекта потребителем.

Это означает, что обсценная лексика в товарных знаках невозможна?

Да. Закон и подзаконные документы, как мы видим, прямо это запрещают.

Однако в госорганах иногда что-то выходит из-под контроля.

Такая ситуация, например, произошла с товарным знаком, который прошел по каталогу Роспатента как «pizduk».

Продержалось это обозначение, отметим особо, в публичном поле недолго: в 2020 году его зарегистрировали для товаров, связанных с табакокурением, а в 2021 — уже аннулировали. 

Патентные поверенные, комментируя этот кейс, указывали на то, что, скорее всего, отказ поступил из-за противоречия «общественным интересам, принципам гуманности и морали».

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

Зарегистрировать товарный знак можно здесь.

Открываем доступ к большим языковым и визуально‑генеративным моделям в пакетном режиме

Сегодня Yandex B2B Tech открывает доступ внутри Yandex Cloud AI Studio к LLM и визуально‑генеративным моделям (VLM), таким как DeepSeek VL2 Tiny, Qwen2.5 VL и Gemma3 27B. Режим Batch Processing, или режим пакетного инференса позволяет эффективно обрабатывать тысячи запросов с помощью таких генеративных моделей.

Всего в пакетном режиме доступно около 20 опенсорсных нейросетей, в том числе модели, которые умеют одновременно анализировать изображения и текст. Среди уже доступных моделей — Qwen2.5 и LLaMa 3.3*, рассуждающие нейросети QwQ и DeepSeek R1, полный список можно посмотреть на сайте.

По мере появления новых моделей в опенсорсе они будут оперативно добавляться на ML‑платформе. Так, вскоре будет доступна VLM‑модель Яндекса, которая используется в Алисе, Нейроэксперте, Поиске с Нейро и других сервисах.

Применение новых моделей в режиме Batch Processing позволяет фокусироваться на эффективной обработке большого объёма данных. Компании смогут использовать модели по расписанию, по мере накопления данных или для объёмных разовых задач. Такое использование обойдётся вдвое дешевле, чем в стандартном режиме. Тарификация при пакетном инференсе на больших объёмах данных начинается от 200 тыс. токенов.

Какие сценарии удобно решать в пакетном режиме

1. Анализ и суммаризация больших объёмов данных. Batch Processing помогает эффективно обрабатывать длинные последовательности текста и создавать качественный пересказ или анализ материалов. Это актуально, например, для исследовательских организаций и компаний, работающих с большими объёмами пользовательского контента.

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

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

4. Обогащение датасетов для тюнинга моделей. Для команд, которые дообучают лёгкие версии языковых моделей с помощью дистилляции ответов больших версий моделей, Batch Processing помогает создавать синтетические датасеты для дообучения. На базе этих данных и с помощью инструмента LoRA Fine‑tuning разработчики могут создавать лёгкие модели высокого качества, при этом получая более реактивную скорость ответов и меньшую стоимость за обращение к модели.

*Llama создана компанией Meta. Meta признана экстремистской организацией, её деятельность в России запрещена.

Обоснуй за переезд в облако 💬

Сказали нашему СТО Максу Яковлеву ребята из Southbridge. А он не растерялся и записал с ними подкаст.

Внутри:

➖ Секреты и проверенные сценарии успешной миграции в облако
➖ Интеграционные риски и подводные камни
➖ Реальные сроки и бюджеты
➖ Простой и доступный спич Макса

🎙 Слушайте там, где удобно, — хоть в Телеге, хоть на любимом подкаст-стриминге. Кликайте по ссылке, там целая пачка площадок.

Запускаю подкаст вместо совещания →

Новая консоль для облачных серверов

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

Работает «из коробки» на серверах, установленных после 4 апреля 2024. Для остальных — одна команда в панели управления, и готово.

Из удобных фич:

➖ Поддержка Ctrl+C/Ctrl+V, скролла и мыши в терминале.
➖ Подсветка синтаксиса в один клик.
➖ Независимость от публичной сети и SSH.
➖ Мгновенный запуск и оптимизация потребления ресурсов.

✏️ VNC-консоль также остается доступной. На всех серверах, кроме тех, что с Виндой, можно легко переключаться между консолями.

Затестить новую консоль →

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

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

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

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

И самое обидное - у него совершенно не хватает времени на задачи, потому что 90% времени он самоотверженно тушит пожары, разгоревшиеся от искры говнокода других.

Дели код на слои - первый принцип. Полный список принципов здесь

Я еще не знаю задачу, но уже знаю, что в коде будет 3 слоя: приложение, инфраструктура, контроллеры. Отдельно конфигурация.

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

Слой приложения «главный». Он устанавливает правила и требования к интерфейсам других слоев. Он никому ничего не должен. Он не знает, как устроены другие слои, и что внутри, потому что он главный. Слой приложения не может требовать от других слоев навыков работы с закрытыми данными. Он не может передать объект с приватными свойствами в другой слой и хотеть, чтобы эти свойства были обработаны.

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

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

— как модель, которые хранят состояние пока запрос обрабатывается;

— сервис без состояния

— функция с валидации целостности

Контроллеры — это все, что касается ввода и вывода.

Этот слой обязан знать, что нужно слою приложения, обязан это предоставить в нужном формате. Он не может ничего требовать от слоя приложения, обязан работать с тем, что отдал слой приложения.

На фронте в этот слой попадает всё, что касается взаимодействия с пользователем и обработки событий:

— шаблоны, стили, функции, которые готовят данные для отображения и обрабатывают ввод пользователя

— обработчики событий

— обработчики роутов, потому что роутинг — это интерфейс ввода данных.

— слушатели сокет соединений

На бэке это код, который принимает входящие запросы и отдает ответ, фоновые контроллеры:

— контроллеры gRPC, HTTP,

— слушатели очередей,

— конструкторы ответа, мапперы данных в нужный формат и т. п.

— описание протоколов.

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

Инфраструктура

— обязана работать с тем, что отдает слой приложения

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

Здесь лежат:

— клиенты к хранилищам, другим сервисам, кэшам, очередям и т. п.

— конструкторы запросов к БД, очередям или другим сервисам

— мапперы данных слоя приложения в нужный формат и обратно

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

Это может быть конфигурация di‑контейнера, место ручного создания компонен. Конфигурация может присутствовать как дополнительные нотации в UI компонентах. Фреймворки и языки имеют разные методы конфигурирования, поэтому конфигурация не является слоем или может быть не явной.

Слой приложения может отсутствовать. Тогда контроллеры и инфраструктура взаимодействуют напрямую. Чтобы сохранить порядок, нужно определить — кто главный. Главным лучше делать того, кто более стабилен.

На фронте слой контроллеров может часто меняться, контракт с бэком более стабилен — инфраструктура главная.

На бэке формат хранения может измениться после MVP, а контракт описан и стабилен — слой контроллеров главный.

Слои зависят друг от друга. Правила организации кода и внедрения зависимостей будут в отдельном посте.

Про колёсо Илона (оно же "колесо Mecanum") я с коллегами узнал достаточно давно. Году в 2018 мы загорелись желанием изготовить свой вариант четырехколёсной тележки на колёсах Илона чтобы освоить программирование её кинематики и начали с проектирования собственно колёсного хаба. К слову сказать, таких колёс на просторах известного китайского маркетплейса - вагон и маленькая тележка, но нам захотелось изготовить колесо своего дизайна. Подробности о кинематике тележки на четырех колёсах Илона можно прочесть в статье на Wikipedia.

Коллега ЧПУшник за пару недель полностью спроектировал колесо в 3D и даже изготовил один хаб (из двух симметричных половинок) из сплава Д16Т на нашем фрезерном ЧПУ в 5-ти координатах. Много лет этот хаб лежал на витрине и пугал своей экзотичной формой посетителей нашего офиса. В марте-апреле 2025 года у нас образовалось некоторое количество свободного времени и мы решили задействовать его с пользой, то есть дожать тему колёс Илона. Мы изготовили оставшиеся три хаба, для чего пришлось полностью переписать программу для ЧПУ чтобы сделать инверсную копию колеса. Запроектировали и изготовлили на токарном ЧПУ латунные втулки для роликов, а на 3D принтере напечатали сами ролики из эластичного материала. Оси роликов изготовили из калибровонного прутка Ф6 пищевой нержавейки.

Собрали всё воедино и установили на платформу с четырьмя шаговыми двигателями типа NEMA17, привод на колёса от которых передается через червячные редукторы с числом редукции 1:30. Для подачи сигнала на ШД использовали драйверы DRV8825 от дешманского 3D принтера предоставленного на разграбление всё тем же коллегой. Блок управления запрограммировали на Verilog-е для разработанной ранее плате "Карно" предназначенной для обучения ПЛИСоводству. В качестве дистанционного управления тележкой выбрали пульт ДУ от телевизора, так как код его декодера очень прост в реализации на Verilog и уже применялся нами для другого аналогичного проекта.

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

1. Слишком большое редукционное число (1:30) делает перемещение тележки очень медленным. Радикально увеличить частоту сигнала STEP (сейчас это 16 кГц при режиме MODE=1/16) не получается - шаговики теряют синхронизацию и перестают вращаться. Планируем зменить редукторы, воможно вместе с ШД, на BLDC.

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

3. Число роликов в колесе требуется увеличить (сейчас их 6 шт), чтобы обеспечить плавный переход от одного ролика к другому, иначе заметны рывки.

4. Ролики требуется изготавливать гладкими из резины с высоким коэф трения, 3D печать не дает качественной поверхности и такие ролики плохо сцепляются с половым покрытием. Тут есть варианты: выточить на ЧПУ из полиуретана или отлить из эластопласта в пресс-форму. Возможности для этого имеются.

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

Код блока упраления тележкой на языке Verilog для ПЛИС: https://github.com/Fabmicro-LLC/KarnixMecanumTest

Дизайн платы "Карно" выполненный в САПР KiCAD: https://github.com/Fabmicro-LLC/Karnix_ASB-254

PS: 3D модель колеса Илона выложу позже, после доработок.

Наши статьи в шорт-листе "Технотекста"

Две статьи из нашего блога вошли в шорт-лист премии "Технотекст". Это материал Полины Гуленок про «Киотский ар-деко» от загадочного Кобаяси Каити и статья Александра Артамонова про феномен Руанды. Также рекомендуем материалы других авторов, вошедших в шорт-лист, если ищете, что почитать на майских.

Собеседование инженера: взгляд со стороны нанимающих специалистов

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

Частая ситуация на собеседовании — недостаточно глубокое погружение в интерфейс, с которым у кандидата был опыт работы. Например, указан опыт работы с протоколом USB. На собеседовании после нескольких вопросов по архитектуре протокола оказывается, что кандидат просто вставлял готовый IP без понимания принципов его работы. Но в резюме это заявлено как полноценный опыт работы с протоколом.

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

Семеро специалистов YADRO по направлениям схемотехники, верификации, RTL-дизайна, FPGA и аппаратной разработки рассказали, как подготовиться к собеседованию инженера, как настроиться на диалог с компанией и получить дополнительные очки в свою пользу.

Проект Digital in pharma запустил опрос по зарплатам в фарме. Без лукавства. Без «по договоренности». Расскажите знакомым медикам и пройдите сами, если работаете в сфере медицины».

С 20 мая по 19 августа собираем данные, которые обычно не любят обсуждать вслух. А 1 сентября публикуем результаты. С цифрами, графиками и выводами, чтобы каждый мог понимать рынок, а не гадать. Опрос анонимный. Доступ к результатам сразу после прохождения. Потом сделаем нормальную визуализацию: без перегруза, но с пользой. По ролям, по регионам, по ощущениям. Зачем это мне? Хочу меньше мифов и больше ясности. Хочу, чтобы люди из фармы понимали свою ценность, а не ловили сигналы с карьерных астропрогнозов. Пройдите. Поделитесь. Пусть будет видно, сколько стоит опыт, стресс и навык держать фарму в движении.

Пройти опрос можно по этой ссылке.

О языках программирования.

Язык программирования обычно становится конфеткой через 40-50 лет активного использования, когда из него устраняются все абстрактные идеи авторов и привносятся свойства, реально нужные программистам.

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

С другой стороны, стандарт Scheme принимают голосованием программистов по спорным вопросам.

Чем дольше живу, тем больше ценю Лисп и Фортран.

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

Рэймонд Чен — ветеран компьютерной индустрии, который работает в Microsoft c 1992 года. Рэймонд участвовал в разработке OS/2, Windows 95, DirectX и оболочки Windows, а последние десятилетия отвечает за сохранение обратной совместимости системы. В своём блоге Old New Thing Чен регулярно делится забавными историями из разработки софта, но также показывает действительно полезные примеры.

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

// В целях наглядности вся проверка ошибок опущена
#include <windows.h>

void SetClipboardText(HWND hwnd, PCWSTR text)
{
    OpenClipboard(hwnd);
    EmptyClipboard();
    auto size = sizeof(wchar_t) * (1 + wcslen(text));
    auto clipData = GlobalAlloc(GMEM_MOVEABLE, size);
    auto buffer = (LPWSTR)GlobalLock(clipData);
    strcpy_s(buffer, size, text);
    GlobalUnlock(clipData);
    SetClipboardData(CF_UNICODETEXT, clipData);
    CloseClipboard();
}

// Чтобы они были под рукой, разместим эти строки в истории буфера обмена
static constexpr PCWSTR messages[] = {
    L"314159", // номер бага, который мы хотим исправить
    L"e83c5163316f89bfbde7d9ab23ca2e25604af290", // коммит, к которому привязываем ошибку
    L"Widget polarity was set incorrectly.", // комментарий, который нужно добавить
};

int wmain([[maybe_unused]] int argc,
          [[maybe_unused]] wchar_t* argv[])
{
    auto tempWindow = CreateWindowExW(0, L"static", nullptr, WS_POPUPWINDOW,
            0, 0, 0, 0, nullptr, nullptr, nullptr, nullptr);

    for (auto message : messages)
    {
        SetClipboardText(tempWindow, message);
    }
    DestroyWindow(tempWindow);
    return 0;
}

Код записывает в буфер обмена последовательно три строковые переменные. Однако при запуске утилиты в истории буфера обмена оказывалась лишь одна — последняя. Куда делись две остальные?

Дело в том, что служба истории буфера обмена работает асинхронно через механизм Clipboard Format Listener, существующий с эпохи Windows Vista. В этом механизме через функцию Add­Clipboard­Format­Listener приложение добавляет себя в качестве листенера. После этого никаких дополнительных опросов буфера обмена проводить не нужно — система сама оповестит приложение, если буфер изменился.

При получении уведомления служба истории буфера обновляет собственно историю буфера обмена. Но из-за асинхронности событие может происходить с задержкой. Как объясняет Чен, из-за асинхронной природы обновлений при получении WM_CLIPBOARD­UPDATE от Clipboard Format Listener буфер может успеть обновиться ещё раз.

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

В другом посте из своего блога Рэймонд объяснил механизмы утилит-просмотрщиков буфера обмена с синхронными обновлениями буфера. Здесь периодически выполняется опрос GetClipboardSequenceNumber. У данного подхода тоже есть проблемы: редкий опрос угрожает привести к пропуску изменения буфера, но слишком частые запросы создадут лишнюю нагрузку на систему.

Рэймонд обещает в следующий раз показать, как исправить код выше.

10 причин, по которым вы теряете энергию и мотивацию (и как этого избежать)

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

1. Незавершённые дела и висящие «хвосты»

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

Что делать: использовать методики типа GTD, Inbox Zero или просто ежедневно подчищать список «хвостов».

2. Самообман и несоответствие внешнего и внутреннего

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

Пример: вы — интроверт, но вынуждены постоянно выступать или продавать. Это изматывает.

3. Изоляция и потеря социальных связей

Человек — социальное существо. Отсутствие контактов, поддержки, принадлежности к сообществу снижает уровень дофамина, серотонина и приводит к хроническому истощению.

Вывод: хотя бы одно по-настоящему «своё» сообщество — must have.

4. Страх и недоверие

Постоянное ожидание опасности активирует симпатическую нервную систему — режим «бей или беги». Это энергетически дорогостоящее состояние.

Как помочь себе: работа с психотерапевтом, телесные практики, распознавание триггеров.

5. Информационный и эмоциональный перегруз

Новости, постоянные уведомления, рабочие чаты 24/7 — всё это сжирает ресурсы мозга. Сюда же — гиперответственность, невозможность «выключиться».

Решение: цифровой детокс, разгрузочные дни, физические нагрузки.

6. Нарушение сна

Недосып = снижение когнитивных функций, плохая память, сбой гормонального фона, хронический стресс. Даже один час недосыпа в день — это минус 15% продуктивности.

Инструменты: режим, трекеры сна, гигиена спальни.

7. Пища, алкоголь и интоксикации

То, что мы едим и пьём, напрямую влияет на уровень энергии. Переедание, алкоголь, курение создают нагрузку на печень, почки, ЦНС.

Принцип: чистое топливо — чище система.

8. Много разговоров и внутренний диалог

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

Что помогает: практика молчания, mindfulness, медитация.

9. Хронические болезни и энергетические “паразиты”

Любой «тлеющий» процесс — болезнь, незалеченная травма, токсичное окружение — отнимает силы. Даже если вы «не обращаете внимания».

Рекомендация: диагностика, профилактика, защита личных границ.

10. Разбалансированная сексуальная энергия

Интимная сфера — мощный источник энергии, но её нерациональное использование (например, частые связи без глубокой связи и смысла) может вызывать истощение.

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

Поддержка должна быть бесплатной. Всегда!

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

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

Я основатель облака для простого деплоя проектов через Git push – Amvera Cloud. И вижу, что пользователи пишут нам в поддержку. И говоря честно – люди пишут только тогда, когда другие способы не помогли и они не знают, как решить их насущную проблему. А это значит мы не доработали и сделали что-то непонятно или неудобно. И это наша обязанность постараться им помочь. И я не вижу морального права просить за это с них деньги.

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

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

Поддержка должна быть бесплатной, всегда, и без всяких но!