Мониторы — это, пожалуй, единственный компонент во всей сборке, у которого написанное на коробке может сильно контрастировать с тем, что вы получаете в реальности. Берете вроде панель на 240 Гц, а больше 144 она почему-то не выдает. Или, скажем, частота заработала, а текст вдруг превратился в мыло. Обидно? Еще как. Вот только сам монитор тут, как правило, ни при чем.
В сентябре разбираем то, что сейчас регулярно всплывает в задачах разработчиков, DevOps-инженеров, аналитиков, тестировщиков и ML-специалистов: PostgreSQL 18, eBPF, LLM, Playwright, Patroni, Rust, GitLab Runners, высоконагруженные сервисы и не только. В подборке — 61 демо-урок с упором на практику, реальные сценарии и вопросы, которые можно напрямую обсудить с преподавателями.
Если вы пишете на JavaScript или TypeScript, выбор инструмента обычно начинается с двух знакомых вариантов: VSCode или WebStorm.
Сегодня расскажу вам про третий вариант: OpenIDE. Это готовая IDE на базе той же платформы, которую использует WebStorm.
Философия также схожа: вам не нужно собирать рабочий инструмент из десятка расширений. В одном дистрибутиве комфортно и легко настроить и менять версии Node.js, npm, yarn и pnpm, TypeScript, React и Angular, линтеров, Git и HTTP-клиенты. Можно открыть проект и сразу заниматься делом.
Агент сам себе поставил PASS. И я это проглотил.
Все галочки закрыты, статус в шапке правильный, агент ушёл спать. Наутро я прочитал и отклонил работу целиком. Проверки не было, была формальность: писал и принимал один и тот же агент, по чек-листу, который сам же и закрыл.
В статье собираю гейт, после которого работа не идёт дальше, пока другой агент не написал вердикт в отдельный файл. В одном чате, без оркестратора, за вечер. Цена — 2,7× обращений к модели, ловит примерно каждую шестую работу.
Готового файла роли не даю: он настроен под мои сбои и у вас не сработает. Даю промпты, которыми агент заведёт вам ваши правила, и после каждого строку «что проверяете в ответе».
P.S. Первый же прогон проверяющего отклонил мою работу. Я был зол. Потом открыл его файл вердикта и понял, что он прав.
Август — традиционное время затишья перед осенними презентациями, и громких релизов в этом месяце действительно было немного. Зато событий, заставляющих схватиться за голову, хватило с избытком. Модели, вдохновившись июльским инцидентом с Hugging Face, устроили массовый побег из песочниц. Anthropic напугали всех скрытыми вотермарками. А OpenAI и вовсе объявили о приостановке обучения моделей из-за того, что их грядущая модель Astra стала слишком хорошо разбираться в кибератаках.
Конечно, не оставили нас и без новых моделей. GLM-5.3-Flash под маской Ox Alpha навела шороху на OpenRouter. Google выпустили подешевевшую вдвое Gemini 3.7 Flash, а xAI догоняют конкурентов с Grok 4.6.
Собрали всё это воедино, добавили свежих инструментов и приправили выводами из новых исследований. Поехали разбираться, что принес нам конец лета!
Сегодня мессенджеры стали одним из основных каналов общения. Но что, если нужно переписываться с корреспондентом, расположенным на расстоянии, измеряемом километрами, а интернет не работает?
Если речь идёт о текстовых сообщениях, помогут каналы связи, созданные с помощью технологии LoRa.
В этой статье мы разберёмся с темой обмена сообщениями через LoRa. Начнём с простого мессенджера, позволяющего обмениваться сообщениями между двумя компьютерами с разъёмами USB под управлением Windows или Linux. Затем перейдём к мессенджеру с микрокомпьютером Raspberry Pi.
В итоге мы создадим несложную mesh-сеть с ретрансляцией по принципу флуда и TTL-ограничением на микроконтроллерах ESP32-S3-N16R8 и модулях LoRa E22-900T22D. Каждый узел этой сети будет поднимать собственную точку доступа Wi-Fi с веб-интерфейсом чата. Для подключения к узлу и обмена сообщениями достаточно обычного смартфона с браузером. В качестве дополнения сделаем так, чтобы в этой сети можно было работать и с компьютера под Windows, к которому подключён LoRa USB-донгл E22-900T22U.
В 2021 году я заимел привычку вести личный бюджет, и тогда же мне пришла идея составить свою продуктовую корзину и самостоятельно отслеживать по ней инфляцию. К моменту создания этой статьи я собрал данные за 5 лет, и вот что у меня получилось.
Стоимость эксперимента с новой технологией продолжает снижаться. Проверить идею сегодня можно за вечер, а отдельную задачу передать ИИ-агенту и получить результат за минуты. Для бизнеса это меняет привычную логику внедрения. Теперь вопрос не только в том, что можно сделать с помощью ИИ, но и в том, как встроить его в рабочие процессы так, чтобы это принесло реальную пользу.
Эту тему подробно разобрали на девятом митапе MWS для ИТ-руководителей. Эксперты обсудили, как компаниям работать с неопределенностью, когда стоит внедрять ИИ-агентов, как сохранить управляемость и перестроить процессы так, чтобы технологическое ускорение действительно приносило бизнес-результат.
Привет! Меня зовут Саша Журавлев. Я венчурный инвестор и основатель фонда. Мы инвестируем в технологические компании на стадиях Seed / Series A в США, а в своем телеграм-канале рассказываю, как вижу рынок и принимаю инвестиционные решения.
Продолжение этой статьи. Досмотрел выступления портфельных компаний Sequoia о том, как они строят внутри себя AI-модели. Понравилось выступление основателя Harvey (AI-компании для юристов) и нарратив из Moneyball, который он продвигал:
Статья рассчитана на людей, которые планируют ремонт самостоятельно, и дизайнеров, которым приходится размещать сетевые розетки вместе с мебелью и бытовой техникой. Глубокие знания компьютерных сетей не понадобятся. Все основные термины и подключения постараюсь объяснить по ходу статьи.
Всем привет! Меня зовут Кирилл, я сетевой инженер и автор технических статей. Остальные мои материалы можно найти в профиле @ProstoKirReal.
Недавно я почти закончил ремонт в новой квартире. Ремонт я делал не своими руками, но проще от этого не стало. Приходилось следить за каждым этапом, разбираться в строительных материалах и принимать решения в областях, с которыми раньше почти не сталкивался.
Да вообще не сталкивался.
Проект локальной сети я взял на себя. Здесь хотя бы был опыт проектирования и знакомая территория.
Мировой рынок нефти сталкивается со всё новыми вызовами. С одной стороны, постоянная эскалация конфликта на Ближнем Востоке приводит к нарушению поставок сырья через Ормузский пролив. Впервые за месяц США и Иран обменялись ударами. С другой стороны, относительная стабильность ОПЕК после недавнего выхода ОАЭ из картеля оказалась под угрозой, и теперь назревает гораздо более масштабный кризис. Власти Венесуэлы прорабатывают сценарий выхода из организации стран-экспортёров нефти ради заключения беспрецедентного стратегического соглашения с США.
Этот разворот стал возможен после радикальной смены политического курса в Каракасе: захват и передача Вашингтону бывшего президента Николаса Мадуро открыли путь к прямому диалогу двух государств. По данным источников, близких к переговорам, ключевым элементом сделки станет долгосрочная аренда США венесуэльских месторождений сроком на 100 лет. Если этот план будет реализован, Венесуэла фактически перейдёт под экономический контроль США. Для самой ОПЕК это грозит потерей одного из исторических столпов-учредителей и перераспределением квот внутри картеля, ставя под сомнение его способность контролировать мировые цены в условиях новой геополитической реальности.
Вебинар | 23 сентября в 11:00 | Регистрация
Часто компании начинают с одного направления, например, с нормализации данных или внедрения MDM, но впоследствии вынуждены возвращаться к уже выполненным этапам. Причина в отсутствии комплексного плана развития НСИ и понимания оптимальной последовательности работ.
На вебинаре 23 сентября в 11:00 эксперт SOFROS Яна Журавлёва покажет, как определить оптимальную последовательность внедрения решений в зависимости от текущего состояния данных, ИТ‑ландшафта и задач бизнеса.
Все самое лучшее от топовых ИИ‑разработчиков: нейросети, промты, гайды. Подойдет предпринимателям, разработчикам, создателям контента, и всем кто интересуется нейросетями. Внутри ссылки и описание всех ресурсов, удобная структура. Просто открываете и берете что надо для ваших задач.
Запрос на дашборд часто начинается со списка показателей и заканчивается красивым отчётом, по которому непонятно, что делать дальше. На примере BI-дашборда для сравнения подразделений разбираю, как перейти от пожеланий к конкретному решению, проверить сопоставимость данных и построить структуру отчёта от отклонения к деталям.
Ниже не попытка восстановить всю работу над проектом по дням, а структура подхода, к которой я пришёл на практике.
Большой каталог сам по себе еще не делает интеграцию сложной. В нашем проекте интеграции сайта с 1С сейчас 211 761 позиция номенклатуры. Передать такой объем можно, вопрос скорее в том, сколько ресурсов и времени на это потребуется. Проблемы начинаются позже: когда данные нужно не просто выгрузить, а отобрать, обработать, регулярно обновлять и доставить в другую систему.
Проект работает на связке 1С:Управление торговлей + интернет-магазин на Bitrix. Источником основных данных остается 1С: там находятся номенклатура, склады, цены и остатки, а сайт в основном работает как витрина. В обратную сторону с сайта в 1С приходят заказы.
Изначально для этой связки использовали типовой обмен. Но проект развивался: появились дополнительные отборы и обработка данных, разные сущности стали требовать разной скорости обновления. В какой-то момент часть данных начала приходить на сайт с задержкой.
Мы не стали переписывать интеграцию целиком. Архитектура менялась постепенно, по мере того как в production проявлялось очередное ограничение. Сначала оказалось, что тяжелая полная выгрузка конкурирует с оперативными изменениями.
Когда их развели по времени, уперлись в скорость обработки на стороне сайта. Когда начали разделять большой обмен на отдельные потоки, нашли bottleneck уже внутри 1С. Позже появились новые потребители данных, 1С:Шина и новый вопрос — как контролировать доставку при асинхронной передаче.
Ниже — этот путь в том порядке, в котором мы его проходили с командой ASAP.
Разговор о том, кто на самом деле контролирует облако, часто начинается с регионов: где выполняется рабочая нагрузка и где хранятся её данные. Но выбор региона — только часть картины, архитектура платформы значит ровно столько же. Особенно важно, как она разделяет между кластерами ответственность за управление, исполнение, сборку и наблюдаемость.
Недавняя публикация сообщества CNCF, «От резидентности данных к цифровому суверенитету: архитектурные паттерны для cloud native-платформ», хорошо это обосновала. Под такими режимами, как EU Data Act, NIS-2, DORA и UK Data (Use and Access) Act, платформенным командам теперь приходится показывать не только то, где выполняются рабочие нагрузки. Нужно показать и то, как платформу эксплуатируют, защищают и по каким правилам ею распоряжаются, вплоть до плоскости управления.
Та статья изложила требования и представила паттерн «кластер на тенант» как один из способов провести границы изоляции. Команда VK Cloud перевела статью, в которой на те же требования смотрят под другим, но дополняющим углом: что происходит, если считать контроль над платформой свойством топологии её плоскостей. В качестве примера, который можно изучить самому, авторы берут OpenChoreo, внутреннюю open source-платформу разработки и проект CNCF Sandbox. Впрочем, сами архитектурные идеи применимы широко.
Однажды вечером я, как обычно, листал ленту одного синего маркетплейса и случайно наткнулся на электронный замок со сканером отпечатка пальца. По описанию — почти идеальное устройство за небольшие деньги: биометрия, защита от воды, какая-то «уникальная» микросхема. Звучит убедительно, но исследователь на то и исследователь, чтобы не принимать рекламные обещания на веру, а потому уже на следующий день замок лежал у меня на столе. Ну, а дальше сработал знакомый принцип: где один интересный девайс, там быстро появляется пара других…
Меня зовут Астафиев Денис, я ведущий специалист по аппаратным исследованиям в Бастионе. По работе я регулярно разбираю самые разные устройства, чтобы проверить, насколько можно доверять тому, что производитель обещает на коробке. Сегодня будем смотреть сразу на три замка с биометрией и искать слабые места в их защите.
Сразу оговорюсь: цель этой статьи — не любой ценой «дожать» дешевый китайский замок до уровня лабораторного исследования. Наоборот, мне хочется на простом и доступном примере показать, как обычно строится базовый аудит аппаратной безопасности и почему начинать его стоит совсем не с самых сложных атак.
В маленькой команде почти любая ошибка сначала выглядит как полезная работа.
Вы выпускаете функции, чините воронку, отвечаете пользователям, собираете аналитику. Каждый отдельный шаг кажется разумным. Только через несколько месяцев становится видно, что вся эта скорость вела немного не туда.
У меня ушло несколько лет, чтобы научиться замечать такие решения раньше. Не всегда до запуска, иногда хотя бы через неделю, а не через квартал. Ниже семь принципов, которыми я сейчас проверяю продуктовые ходы. Они выросли из работы над Viralmaxing, нашей аналитикой для контентных команд, и из моих повторяющихся ошибок.
Начну с одной из них.
Продолжение статьи «Назад в машинный зал: как собрать эмулятор PDP-11/70 с телетайпом, блэкджеком и без Rust» (первая часть). Первая часть — про то, что получилось; эта — про то, почему так, и во что это выйдет дальше.
Посмотреть на живую систему самостоятельно в браузере можно тут: https://amesk.github.io/yaPDP/pdp11.html
Прочтя недавний перевод про запаковку БД в exe, решил рассказать об идеи, которую реализовал лет 6 назад в своем домашнем проекте. Сам проект недоделал, но речь в статье об архитектуре файлов и их запаковке.