Dmitry Muravyev

Кстати, раз уж речь зашла о покупках, смотрите что нашёл: на первом фото топовый, ну или полутоповый тринокулярный микроскоп от Mechanic (по ссылке на фотках модель с блокируемым глазом, но присылают именно Super-X с активным глазом, чему там не все рады). А на втором фото, судя по всему, он же, только без "налога на бренд" и в матовом чёрном варианте. Крепления немного отличаются, а сами микроскопы внешне и по характеристикам один в один. Видимо, с OEM-производителем не договорились об эксклюзиве и он эту же модель красит в цвета других брендов. Если посчитать с таможенным побором, то разница более 8К₽. Микроскоп позиционируется как аналог SopTop 9 Elite, о котором очень хорошие отзывы.

Чек-лист по прошивке контроллера вентиляторов:✔️ Дописать и протестировать логику контроля и обработки ошибок.✔️ Переделать процедуры работы с памятью (сохранение во Flash, поиск и инициализация датчиков и т.д.)✔️ Переезд написанного кода с тестового проекта на рабочий.✔️ Подправить и проверить логику датчиков, в том числе, добавить возможность полного отключения вентиляторов в случае, когда температура опускается ниже заданного предела.✔️ Проработать протокол общения с хостом.✔️ Выпустить MVP (Minimum Viable Product) прошивки.❌ Переписать USB HID-драйвер, чтобы обойти проблемы с лицензией.➖ Много всякой мелкой возни относительно настроек, режимов работы и всевозможного тестирования.➖ Набросать минимальную управляющую софтину (скорее всего, для начала под Винду), по которой будет один или несколько отдельных постов.

И ещё одна новость: я всё-таки решился попробовать перейти на линукс в качестве рабочей ОС на рабочем же ноуте. И для удобства на него же частично перевести и свои хоббийные дела по ведению канала. Линуксоиды со мной не согласятся, но всё-таки, линукс для работы это БОЛЬ! Ну, то есть, если работать с простыми офисными документами/таблицами и/или только кодить, оно вполне ОК. А вот если таблички посложнее, если надо ещё и поддерживать удалённо нескольких клиентов, иметь Forti SSL VPN, L2TP+IPsec VPN (а ещё WireGuard во славу Ютюба!), синхронизировать почту и календарь с Exchange и Google, да ещё и какие-то творческие дела (хрен с ней с монтажкой, но хотя бы с приличными графическими редакторами и записью звука), то тут уже начинаются проблемки. Даже последняя Arduino IDE не работает, пока руками не поменяешь права на chrome-sandbox 🤦‍♂️ Какого-то софта нету в принципе, какой-то есть, но ставится с большим трудом, а поставившись - не работает. У меня ещё относительно простой случай, а бывает у людей на рабочих машинках стоят и большие САПРы и 1С и чего только не... И по хорошему всё это должно в случае чего устанавливаться на чистую ОСь за полдня-день и далее без проблем работать, а это точно не про линукс. Строго говоря, никакой острой необходимости в переезде на "линь" у меня не было. Это именно что волевое решение для более детального погружения в пучину... Так или иначе, но опыт этот мне пригодится. В общем, прикупил я себе Redmi Book Pro 16 (взял в рассрочку и очень надеюсь что китайского качества хватит на то, чтобы он не помер раньше, чем я расплачусь за него), накатил пока что себе Кубунту, крепко поселился на всевозможных линух-форумах и вот уже две недели сражаюсь. Пока держусь, а там видно будет)))

История игрушечного робота за $31.95 (На базе MIT Technology Review, 06 2025) В начале 80-х один мальчик ходил с папой в Radio Shack. Папа - инженер, выбирал резисторы и конденсаторы. Сын зависал в отделе игрушек и однажды залип на странной штуке – игрушечном роботизированном манипуляторе Armatron. У этой штуки был постамент, «плечо», «локоть», «кисть» и клешня.Её можно было крутить вокруг своей оси, поднимать, сгибать «локоть», вращать «запястье» и открывать-закрывать захват двумя джойстиками. Всё это – с жужжанием шестерён и фирменным «CLICK… CLICK… CLICK», если пытался продавить предел хода.Через много лет этот мальчик станет инженером в Boston Dynamics и будет работать над Petman, Atlas и Spot – теми самыми роботами из YouTube. Что же такого было в этой игрушке? Для компании Tomy это был просто крутой робот-игрушка за $31.95. Игрушка, которую хвалили журналы по робототехнике: «возможности, обычно доступные только дорогим экспериментальным манипуляторам».Но произошло странное:– Armatron начали покупать не только дети,– а инженеры и исследователи из лабораторий, производств и робототехнических компаний. Они писали создателю, обсуждали механику, делились, как используют эту штуку.То есть у вас вроде как B2C-игрушка, а по факту – доступный демо-стенд для будущих и нынешних инженеров. :)Самое смешное: у Armatron внутри почти ничего не было.– отсек для двух батареек D,– маленький мотор на 3V,– куча шестерён.Никакой электроники. Всё – чистая механика.Инженер Хироюки Ватанабэ, который придумал arm, вообще не учился как «классический инженер». Техническое училище, потом Komatsu, потому что он любил бульдозеры. Потом он увидел вакансию в Tomy, сел в ночной поезд и поехал в Токио просто потому, что это «игрушки и №1 компания».Первая версия робота у команды была так себе, говорят:– рука торчала сбоку, ход только на 90 градусов,– шесть движений через шесть отдельных переключателей.Ватанабэ посмотрел на это и сказал: «Мне не нравится». Он летал на радиоуправляемых вертолётах и однажды просто посмотрел на пульт:две стика – четыре движения.А если ещё и поворот добавить – получится шесть.Так родился интерфейс Armatron: двойные джойстики, каждый можно не только двигать, но и поворачивать. Плюс сложная коробка передач, которая перенаправляет силу одного мотора на разные оси.Посмотрите на ход Ватанабэ: его не устраивало не то, как устроены шестерёнки, его не устраивался опыт управления.Потом он придумал переключаемую коробку передач, 360-градусный поворот, форму корпуса, резиновые трубки, имитирующие промышленных роботов того времени (спойлер: трубки были чисто декоративные).Он на примере показал, что сильная продуктовая стратегия – это когда вы сначала решаете, чем должна быть мечта пользователя, а уже затем – как под эту мечту выглядит инженерная архитектура, интерфейс, себестоимость.

Нейросети становятся фабрикой фальшивокВы слышали про ИИ Nano Banana Pro? Пользователи выяснили, что эта модель способна генерировать поддельные документы: квитанции, формы KYC и даже изображения паспортов. Всего по одному запросу - и на выходе гиперреалистичный почерк или макеты документов, которые сложно отличить от настоящих.Возможность создавать официальные документы значительно увеличивает риски мошенничества и манипуляции с личными данными. И самое страшное - с развитием ИИ выявлять такие подделки будет все сложнее.Я уже писал про дипфейки и то, как они меняют наше доверие к видео и аудио. Но документы это следующий уровень. Если раньше для подделки нужны были навыки дизайнера и доступ к специальному оборудованию, то теперь достаточно запроса к нейросети.Представьте: мошенник может сгенерировать квитанцию об оплате, паспортные данные или даже медицинскую справку. Банки, государственные службы, работодатели - все они полагаются на документы как на доказательство. А что если эти доказательства можно создавать за пару минут?В бизнесе это вообще ад наступает. KYC-процедуры, проверка контрагентов, верификация сотрудников - все это строится на документах. Если их подлинность нельзя гарантировать, вся система рушится.И самое тревожное - нейросети учатся. Сегодня они генерируют документы с мелкими ошибками, которые можно заметить. Завтра эти ошибки исчезнут. Послезавтра они научатся имитировать конкретные бланки конкретных организаций.Что делать? Ждать, пока регуляторы придумают новые стандарты безопасности? Надеяться на блокчейн-идентификацию или цифровые подписи нового поколения? Или просто смириться с тем, что доверие к бумажным документам уходит в прошлое?Мне кажется, мы стоим на пороге фундаментального изменения. Скоро понятие "документ" придется переосмысливать. Возможно, будущее за биометрией, цифровыми следами и системами, которые проверяют не бумажку, а цепочку действий человека.А пока что каждый, кто работает с документами, должен понимать: то, что вы видите на бумаге или экране, уже не гарантия подлинности. Проверять нужно тщательнее, глубже и с помощью технологий, которые еще не научились обманывать.Как думаете, к чему приведет эта способность ИИ? И как бизнесу защищаться от фальшивок, которые не отличить от оригинала?

Похоже ИИ "наступает" и "неотступает"Слушаю эту музыку которую неделю. Нравится!!! Очень! Но! Своё вокальное творчество затихо, ибо то, что хотелось спеть, спело ИИ....И песни поэтов у меня сейчас не поются. Я пою с ИИ. Живые, настоящие слова, полные смысла и мудрости. Сила! Но! Во мне присутствует легкая тревога. Откуда она и чего конкретно касается? Меня самой? Нет. Ведь я не певица знаменитая, которая живет вокалом. Однако.Треки живых музыкантов и исполнителей явно слушают меньше чем эту музыку созданную ИИ. Ведь живая музыка и вокал создается без учета высоких технологий, которые учитывают параметры самой прослушиваемой музыки.#музыка #тревожность

Завтра буду выступать в Культурном центре НИУ ВШЭКогда готовилась, читала эту подборку судебных решений, где затрагивались вопросы использования ИИСамое интересное дело на мой взгляд – это дело о защите деловой репутации, в котором суд указал, что статья, полностью созданная ИИ, должна иметь достоверные источники и не умалять чью-либо репутацию❗️На заметку тем, кто генерит тексты ❗️В общем, рекомендую подборку. Интересная

Обновление ноды OpenAI в n8nНедавно в n8n наконец-то обновили ноду OpenAI и добавили туда множество функций, ранее недоступных, но существовавших в API.1️⃣ Переход от Assistant API к Response API. Если раньше вы могли указывать thread_id и ассистент общался в рамках одного треда, то теперь каждый ответ имеет свой response_id, который нужно записывать и использовать при следующем вызове ассистента, чтобы он “помнил” ветку диалога. Это значит, что каждый раз нужно дополнительно сохранять response_id и вызывать его из БД для указания в агенте.2️⃣ Добавление Structured Output.Ранее для использования SO приходилось брать HTTP ноду, теперь же функционал встроили в агента. Советую ознакомиться с правилами SO для OpenAI - там много интересных фишек, к примеру опциональные значения и enum листы.3️⃣ Добавление нативных туловТеперь можно выбрать, какими нативными тулами будет располагать агент - поиск по вебу, код-интерпретер, поиск по файлам. К примеру, я использую в проекте встроенный поиск по вебу, чтобы найти информацию о ЛПР компании.___Если вы хочешь узнать больше про работу с ИИ в n8n - пройди наш курс в сообществе

⭐ Как настроить графику в новом клиенте, чтобы получить выше FPS и плавность?Для начала результаты моих тестов влияния настроек:• Если мерять фпс в пустой локе, то отключение всего в настройках (грубо говоря минималки) повышают фпс чуть ли не в 2 раза. • Если мерять в локе с людьми, например 150-1000 персонажей, то на моем компе разница в пределах 10%. Если более 1000 персонажей двигаются, то до 5% и меньше. • Все эти настройки графики напрягают именно видеокарту, а за высокий FPS в масс замесе отвечает проц и чем он лучше, тем выше будет FPS. Поэтому на сильном компе с хорошей видюхой - пох какие настройки, нужно просто отталкиваться от визуала. Как нравится, так и следует настраивать. Если же очень важны эти 10%, то следует побольше всего отключать в разделе графики и в совокупности будет этот прирост. Пытался выяснить что же там сильнее всего садит FPS и не преуспел в этом. Все понемногу отнимает. На одном уровне нагрузки одно, на другой уровне другое. Что касается среднего компа с видюхой 1050 ti, то тут та же история, просто видюха сильнее нагружена и FPS ниже. Для слабых компов уже речь может идти не о 10%, а о кратной разнице, поэтому обладателям слабых компов обязательно следует настраивать что-то близкое к минималкам.💯Теперь поговорим о том, что реально ощутимо бустит FPS в масс замесе на любом компе - оптимизация эффектов или отключение эффектов. Даже настройка "Иногда скрывать эффекты" уже заметно бустит FPS в моих тестах, а остальные варианты соответственно еще сильнее, цифры можно наблюдать во втором видео. Ну и сильнейший вариант по анимациям это команда .switch fx - дает сильнейший буст FPS в массовом замесе, так как анимации не показываются абсолютно и даже ручками никто не машет. 🔝Плавно подошли к сильнейшей опции производительности - снижение ренжа прорисовки персонажей. Тут уже каждый может настроить себе сам удобные дистанции. А вот выкручивать все в нулину - это актуально для самых мясных ситуаций, когда уже совсем много персонажей собирается в одном, относительно компактном месте. Тут уже между 10 FPS и полной видимостью всех персонажей и 30 FPS, но ограниченной видимостью - выбор очевиден. Вспомнил про еще одну фишку, которая может бустануть FPS хоть в 3 раза. Вдохните воздуха в грудь. Готовы? Это покупка или апгрейд компа 🤔PS. Чтобы комп не напрягался выше необходимого, рекомендуется включать Vsynk, тогда максимальный FPS будет равен частоте монитора, но только не включайте х3, так как он сильно садит FPS. Если же кому-то хочется еще сильнее снизить нагрузку на комп, то можно отключить Vsynk и настроить лимит FPS 60, в таком режиме комп будет работать тише.#гайд #НК

Dolphin - единая панель для аналитики в реальном времени в MySQL/MariaDB и ProxySQL. Поддержка Linux, Windows и MacOShttps://github.com/charles-001/dolphieОпубликовано в @gitgate#mysql #postgres #proxysql #tui

🔥 Remote Compose — новый взгляд на Server-Driven UI в Jetpack ComposeВ AndroidX Jetpack появилась новая экспериментальная библиотека androidx.compose.remote (пока еще даже на dev версия). Она предлагает совершенно другой подход к динамическим интерфейсам и может радикально изменить то, как мы обновляем UI в продакшене, категорически отличающаяся от текущих BDUI/SDUI решений.Remote Compose позволяет создавать и рендерить интерфейсы Jetpack Compose удалённо, без пересборки и релиза приложения.UI генерируется на сервере, сериализуется в компактный бинарный документ и воспроизводится на устройстве.Remote Compose открывает возможности, которые раньше требовали релиза приложения:⚡️ Мгновенные A/B-тесты — вариации интерфейса меняются на сервере, без обновлений.🎨 Обновление дизайна в реальном времени — карточки товаров, баннеры, сезонные темы.📰 Динамические контентные экраны — новости, акции, спецпроекты, которые появляются мгновенно.🧪 Фичи без мусора — нет необходимости тянуть все варианты экрана в бинарник.Архитектура Remote Compose состоит из двух частей:1️⃣ Создание документаНа сервере вы пишете обычные composable-функции — либо используете специальные Remote* элементы (RemoteColumn, RemoteText и др.).Библиотека перехватывает draw-операции Compose и превращает UI в бинарный документ. Получается самодостаточный «UI-файл», который можно отправить на клиент.2️⃣ Воспроизведение документаНа устройстве этот документ «проигрывается» плеером:👉 есть Compose-плеер — для современных приложений;👉 есть Android View-плеер — для старых архитектур.Плеер интерпретирует более 90 низкоуровневых операций (рисование, layout, модификаторы, state), обеспечивая реальную нативную отрисовку, без WebView и без компонентов, которые нужно заранее описывать в приложении.Почему это лучше JSON или WebView❌ JSON-подход требует схем, ограничивает сложные эффекты, анимации и кастомные компоненты.❌ WebView — это отдельный процесс, разная визуальная стилистика, тяжёлое потребление памяти и уязвимостиRemote Compose передаёт не структуру компонентов, а реальные команды рисования. Поэтому любое, самое сложное Compose-UI — будет воспроизведено точно так, как вы его задали.Базовые принципы Remote Compose👉 Документность — UI становится бинарным документом, который можно кешировать, версионировать, отправлять по сети.👉 Платформенная независимость — один документ можно рендерить на телефоне, планшете, складном устройстве и даже часах.👉 Отделение визуального уровня от логики — клиенту не нужно знать о ваших composable-функциях, ViewModel, DI и т.п.👉 Двусторонняя связь — клики и события возвращаются на клиент, который решает, что делать (навигировать, логировать, изменять состояние).👉 Поддержка анимаций и выражений — значения могут вычисляться по времени, переменным, условиям.Для большинства приложений оптимальная модель — гибридная:📱 основная навигация + критические экраны в “локальном Compose”,⚙️ динамические зоны — через Remote Compose.Если Remote Compose будет развиваться так же активно, как Compose в своё время, это может стать стандартом для динамических интерфейсов на Android. Как вам такой поворот с Compose?Источник тут#jetpack #android #compose #serverdrivenui #sdui #bdui

🤖 ИИ-общение и полумёртвые чатыПару месяцев назад я первый раз в жизни столкнулась с тем, что человек явно писал мне сообщения с помощью чата ГПТ. На меня сейчас же опустился эффект зловещей долины. Но переписка была по делу, и я решила, что мне абсолютно всё равно, хоть 10 нейросетей человек использует, главное, чтобы наше взаимодействие сложилось. А оно сложилось. И знаете, несмотря на полуроботизированные сообщения поначалу, эти сообщения были… да блин, на порядок качественнее, чем среднестатистически пишет человек по работе!Там были и списки, и исключительно вежливые формулировки, и чёткие договорённости с деталями, про которые обычно все забывают и потом получают неприятные сюрпризы и конфликты.Потом человек отказался от ИИ, сообщения стали живыми, менее формальными, видимо, лёд растаял между нами. Что, кстати, качество договорённостей не снизило, то есть дело было всё-таки не в ИИ. И вот к каким выводам меня это привело:✅Люди используют ИИ для написания писем, сообщений, скриптов для разговоров, и это уже реальность. И уже можно не шокироваться.✅Качество того, что у людей получается в этом процессе, зависит не столько от выбранной нейросетки, сколько от мозгов пользователя. Простите, но мы все до сих пор кринжуем от людей, которые даже не перечитывают результат, и в конце их текста оказывается что-то вроде: «Вот вариант того, как можно написать сообщение твоему руководителю. Хочешь, я адаптирую его для переписки в мессенджере?».🤡🤡🤡✅Но вот что тревожит меня больше всего. Навыки общения - это очень-очень важные социальные навыки, которые сейчас и так стремительно падают у людей. Не ампутируем ли мы себе их остатки, передавая функцию коммуникации роботу?Прикиньте, на дворе 2027 год, ваш ИИ-помощник общается с ИИ-помощником вашего друга в телеграме. Вот и поговорили, что называется. А хотя смысл с другом поддерживать связь вообще, даже через помощника? К нему подход нужен, надо интересоваться его делами, время ему уделять, конфликты с ним решать, вдруг он не согласиться с нами в чем-то. Это вот зачем всё делать? Лучше в целом общаться только с нейросеткой, которая тебе поддакивает и всегда абсолютно вежлива, разве нет?Короче, мы живём в период удивительных изменений, и 6-я информационная революция подкралась к нам со всей своей мощью. Я занимаю тут позицию скорее консервативную и к подобным перестройкам отношусь холодно. А вы как? Радуемся/страдаем/просто принимаем реальность?Пишете ли вы сообщения с помощью ИИ?Я вот люблю общаться сама, и искусственно-интеллектуальные костыли использую по минимуму просто потому, что мне не прикольно. Интересно самой придумать, что сказать и как аргументировать своё мнение. Хотя в других вопросах ИИ использую, он где-то очень классный и не такой страшный.

Внутренний DevRel: когда митапы больше не работаютВ прошлом посте я писала, что в новом году от деврелов будут ждать усиления инженерной культуры и эффективности. Давайте посмотрим, как это выглядит на практике.Знакомая ситуация: вы организовали классный митап, заказали пиццу, собрали 50 человек. Все довольны. А через неделю руководство спрашивает: «Окей, а как это помогло нам релизить быстрее?» И вы понимаете, что ответа нет.Проблема не в митапах. Проблема в том, что мы привыкли измерять активность (охваты, лайки), а не результат. При первом же сокращении бюджета такие активности уходят под нож.За рубежом (Google, Spotify, Uber, Netflix) внутренний DevRel давно стал системной функцией, которая напрямую влияет на производительность. И у них есть конкретные инструменты.Скорость: как DevRel сокращает Time to MarketГлавная боль — время от идеи до продакшена. Инженеры тратят часы на поиск документации и контекста.Инструмент DevRel здесь — работа с базой знаний. Не просто «написать статью», а выстроить систему, где информация находится за минуты. Spotify создал для этого Backstage (кстати, opensource) — единый портал сервисов и документации. DevRel здесь выступает куратором: следит за актуальностью док, как вариант.💡 Совет: возьмите одну команду и помогите им систематизировать инфо имеющимися инструментами. С одним успешным кейсом масштабироваться проще, чем пытаться охватить необъятное.👉 Вопрос для рефлексии: сколько раз вы задавали командам разработки вопрос про работу с документацией?Качество: как DevRel снижает технический долгДефекты в продакшене — это дорого. Но ещё дороже культура, где «и так сойдёт» — норма.Здесь DevRel работает через инженерные гильдии. Это не митапы ради митапов, а синхронизация стандартов. QA делятся подходами к автотестам, бэкенд правилами код-ревью, фронты библиотеками и компанентами. DevRel фасилитирует встречи, фиксирует решения и следит, чтобы лучшие практики раскатывались на всю компанию.Google измеряет это через GSM (Goals-Signals-Metrics): не «провели 10 встреч», а «80% команд используют единый фреймворк, что снизило долю дефектов на 20%».👉 Вопрос для рефлексии: есть ли у вас единые инженерные стандарты и кто отвечает за их распространение?Опыт (DX): снижаем когнитивную нагрузкуDeveloper Experience — это про то, сколько ментальной энергии инженер тратит на рутину вместо бизнес-задач.Исследования показывают: каждый пункт улучшения Developer Experience Index экономит 13 минут на разработчика в неделю. Для команды из 100 человек это >1000 часов в год, которые можно потратить на фичи.DevRel здесь — голос разработчика перед Platform-командами. Мы собираем фидбек, выявляем сложности и добиваемся их решения. Это системная работа с опросами и аналитикой, а не просто «передать жалобу».👉 Вопрос для рефлексии: знаете ли вы топ-3 рабочих боли ваших разработчиков прямо сейчас?Что в итогеВнутренний DevRel — это эволюция функции. Мы отвечаем на вопрос: как помочь инженерам делать работу лучше и быстрее?Митапы и пицца останутся, но станут инструментом, а не самоцелью. В следующем году, когда вас спросят «зачем нам DevRel внутри?», у вас будет ответ на языке бизнеса: Time to Efficiency, процент дефектов и Developer Experience Index.А вы уже думаете в эту сторону? Есть опыт измерения влияния на продуктивность?