Обновить

Разработка

Сначала показывать
Порог рейтинга

Lexicon Rephraser: принципы создания недетектируемого контента нового поколения

Девяносто процентов онлайн-текстов скоро будут генерироваться машинами. Это факт. На фоне подобной автоматизации остро встает вопрос сохранения человеческого, уникального звучания. Обычные синонимайзеры и чат-боты здесь бессильны — их шаблонный слог детекторы вычисляют мгновенно. Требуется принципиально иной подход, переосмысливающий сам процесс рождения текста. Наша методология объединяет два мощных ядра: глубинный синонимайзинг и фрактальный мозговой штурм. Их интеграция в едином «Менеджере задач» создает контент-фабрику, где итоговый материал неотличим от ручной работы эксперта.

Почему стандартные инструменты слепнут? Большие языковые модели двигаются по проторенным векторам, выбирая самые вероятные комбинации слов. Алгоритмы детекции, обученные на миллионах текстов, ловят именно эту предсказуемую плавность. Поверхностная замена слов лишь слегка корректирует маршрут, оставляя характерный машинный след. Наше решение строится на семантическом обогащении. База в два миллиона словоформ — это карта концептуальных связей, а не простой словарь. Обрабатывая ключевое понятие, система активирует до двадцати интеллектуальных ассоциаций из разных областей знания. Так слово «город» обрастает оттенками «метрополиса», «урбанизма» и «сообщества». Каждая ассоциация — новый угол зрения, радикально меняющий векторный путь текста. Для детектора такая сложная траектория перестает быть шаблонной. Текст обретает лексическое богатство и глубину, присущие живому эксперту. Практический результат — ноль процентов искусственности в системах проверки. Смысл не искажается, а обогащается неожиданными, точными формулировками. Это создает естественное звучание и прочную основу для SEO, напрямую влияя на оценку авторитетности материала поисковыми системами.

Классический диалог с искусственным интеллектом линейен и непродуктивен. Даже общение с несколькими виртуальными экспертами часто сводится к разрозненным монологам. Настоящий прорыв происходит, когда технология расширяет, а не заменяет человеческое мышление, создавая новые формы коллаборации. Архитектура нашего мозгового штурма — это многоуровневая рекурсивная система. Первый эксперт генерирует идею. Но она не передается дальше напрямую. Ключевые понятия из сообщения погружаются в ядро Lexicon, где насыщаются десятками смысловых оттенков из обширной базы. На выходе рождается пучок обогащенных концептов. Эти смысловые потоки поступают к другим участникам дискуссии, каждый из которых начинает свою ветку обсуждения с принципиально более сложного исходного материала. Такой процесс моделирует фрактальный рост, где каждый новый виток умнее предыдущего. Это приводит к экспоненциальному увеличению вариативности и преодолению главного недостатка ИИ — склонности к усредненным решениям. Система постоянно заглядывает в бездонный колодец человеческого языка, генерируя по-настоящему прорывные идеи и обеспечивая всестороннюю, глубокую проработку любой темы.

Истинная мощь технологии раскрывается в автоматизированных рабочих процессах. «Менеджер задач» позволяет создавать сложные скрипты, выполняющие десятки операций последовательно. Lexicon выступает в роли универсального семантического процессора, который готовит обогащенный материал для других продвинутых моделей. Такой промпт, попав в GPT-5, дает результат, недостижимый при стандартном запросе. Это подтверждается исследованиями, открывающими новый уровень креативности при грамотном использовании больших языковых моделей. Пользователь может запустить цепочку на тысячу повторений, создавая массу уникальных, недетектируемых статей без потери качества. Так решается ключевая проблема контент-маркетинга в эпоху ИИ: как масштабировать производство, не скатываясь в генерацию однообразного спама. Интеграция с внешними сервисами замыкает цикл от идеи до публикации, превращая Lexicon Rephraser в центральный процессор цифровой контент-фабрики.

Доступно бесплатно https://arkhipsoft.ru/Lexicon

Теги:
0
Комментарии2

Luxms BI: Итоги 2025 года и планы на 2026 год

24 декабря, 15:00, онлайн

Знаете вот когда сделал что-то, что тебе самому очень нравится, хочется показывать это всем - друзьям, родным, коллегам и даже рассказать при случае попутчику в метро) так и мы ждём сегодняшний вебинар про итоги года, чтобы поделиться с вами всем классным, что сделали в 2025 году и рассказать что задумали в 2026. Буквально спрашиваем друг у друга "Мы уже приехали?" «А сколько уже зарегистрировалось? А сейчас?»:)

Мы будем очень рады, если вы придете!

Вот ссылка, где проведем встречу) приходите, пожелаем друг другу счастливого Нового года❤️

Теги:
0
Комментарии0

Luxms BI: Итоги 2025 года и планы на 2026 год

24 декабря, 15:00, онлайн

Знаете вот когда сделал что-то, что тебе самому очень нравится, хочется показывать это всем - друзьям, родным, коллегам и даже рассказать при случае попутчику в метро) так и мы ждём сегодняшний вебинар про итоги года, чтобы поделиться с вами всем классным, что сделали в 2025 году и рассказать что задумали в 2026. Буквально спрашиваем друг у друга "Мы уже приехали?" «А сколько уже зарегистрировалось? А сейчас?»:)

Мы будем очень рады, если вы придете!

Вот ссылка, где проведем встречу) приходите, пожелаем друг другу счастливого Нового года❤️

Теги:
0
Комментарии0

IMPulse - Open Source менеджмент инцидентов. Freeze, Jira, ChatOps

Прошло достаточно времени с прошлой публикации: мы добавили много нового и хотим поделиться этим и нашими планами.

Из нового

  • У нас появился механизм Freeze, который выполняет пару задач. С одной стороны он отключает уведомления по инциденту на некоторое время, например на выходные. С другой - исключает создание таких же инцидентов на время "заморозки". Этот функционал похож на Silence Alertmanager'а.

  • Появилась интеграция с системой трекинга задач, Jira.

  • Теперь есть возможность просматривать закрытые (архивные) инциденты.

  • Добавлены метрики.

  • IMPulse теперь можно запускать в нескольких экземплярах. В случае недоступности основного (primary) инстанса, работу подхватит запасной (standby).

  • Webhook'и стали ещё мощнее. Теперь с их помощью можно очень гибко формировать JSON для отправки в любую сторонюю систему.

  • Появилась интеграция с алертами из Grafana.

  • IMPulse научился перечитывать (reload) конфигурацию без полной перезагрузки. Также вы можете добавить проверку конфигурации в CI/CD перед её применением.

  • В UI теперь есть индикатор online / offline, чтобы понимать, актуальная ли сейчас информацию на экране. К слову, несмотря на внешнюю простоту, UI очень гибок: умеет фильтровать инциденты по лейблам (в качестве фильтров можно использовать regex'ы), можно сортировать инциденты по нескольким столбцам, а также выделять цветом интересующие данные.

  • В случае заполнения диска, IMPulse теперь продолжит работать. Обновления по инцидентам будут храниться в оперативной памяти пока не появится место на диске. Настройте алерты на ERROR логи, чтобы вовремя среагировать.

Планы

В первой статье я уже упоминал, что мы считаем крайне важным для всех, кто работает с инцидентами, иметь общий контекст. Многие решения при проектировании принимались, исходя из этого. Сейчас можно констатировать, что ChatOps стал основой IMPulse и дальнешее движение будет под этим знаменем. Мы будем глубже интегрироваться с мессенджерами, чтобы команде дежурных / devops'ов не нужно было переходить в UI. Да, обязательно останутся задачи, которые не решить в рамках мессенджера, но мы постараемся минимизировать их количество.

Здесь часть из наших планов на ближайшие пару месяцев:

  • добавить работу с группами в Slack и Mattermost;

  • добавить в UI механизм аутентификации;

  • перенести кнопки для работы с инцидентами в UI;

  • реализовать механизм подавления инцидентов на основе правил по аналогии с Inhibition в Prometheus. Если согласно правилам инцидент становится дочерним, то уведомления по нему прекращаются пока не будет решена основная проблема. Это позволит уменьшить количество активности по инцидентам.

По поводу других новшест мы пока сохраним интригу!

Критика и советы

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

Оставайтесь с нами в Telegram - мы используем его для общения с русским сообществом, следите за обновлениями в GitHub. Мы продолжаем!

Предыдущие публикации

Теги:
-1
Комментарии0

Всем привет!

Сегодня был выпущен релиз Pech 2.0.0 BETA!

Основные изменения:

  1. Новый формат написания: PEF (Pech Executable File):

    Этот формат был сделан с целью упростить написания

    кода и работы с переменными.

Мало да? Ну это же бета :-).

Также не основные изменения (это не грандиозно, но нужно):

  1. Выяснилось, что моё ядро с функциями НАМНОГО медленнее

    чем с exec и compile (с exec минимум на 10 тыс. задачах 10.7 мс!)

  2. Выяснилось, что нужно будет сделать кэширование для процессов.

Планы на будущее:

Сделать кэширование.

Сделать кучу серверов.

Да этого мало, но эти изменения пригодятся.

Удачи!

Теги:
-2
Комментарии2

Вышла новая версия fq 0.16.0

fq - это инструмент, язык и декодер для работы с двоичными данными. Конечная цель проекта — объединить в одном инструменте функции jq, hexdump, dd и gdb.

Поддерживаем массу форматов, полный список: https://github.com/wader/fq/blob/master/doc/formats.md

Написан на Golang.

Демонстрация работы
Демонстрация работы

GitHub: https://github.com/wader/fq

ChangeLog: https://github.com/wader/fq/releases/tag/v0.16.0

Теги:
+2
Комментарии0

Инфостарт перезапустил «Большой опрос 1С-сообщества» — ежегодное исследование, которое помогает понять, как за несколько лет меняются роли, инструменты и реальные практики вокруг 1С.

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

Проект стартовал в 2022 году, тогда в исследовании поучаствовали 10 672 специалиста. В 2023 — 7 887. Опрос 2024 года сознательно не проводили: команда пересобрала методологию и формат, чтобы результаты разных лет можно было сравнивать корректно, без эффекта «вроде похоже, но непонятно, что именно изменилось».

В версии 2025 года обновили саму анкету: уточнили формулировки, расширили варианты ответов и добавили блок про использование ИИ-инструментов в разработке и работе с 1С — от повседневных задач до более сложных сценариев. А главное — после заполнения участник сразу получает доступ к интерактивной аналитике и может сравнивать данные за 2022, 2023 и 2025 годы.

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

Заполнение занимает примерно 5–10 минут, после отправки анкеты система автоматически перенаправит на страницу с результатами. Сбор ответов идёт до конца января 2026 года, возможно продление до конца февраля, после чего исследование за этот цикл будет закрыто.

Теги:
0
Комментарии0

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

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

Теги:
+2
Комментарии13

WT IndexNow плагин для Joomla - отправка страниц сайта на переиндексацию в поисковые системы.

Пакет плагинов, обеспечивающий ручную и автоматическую отправку url адресов Joomla в поисковые системы на переиндексацию по протоколу IndexNow.

Согласно документации протокол поддерживают все крупнейшие поисковые системы, кроме Google. Протокол служит для получения от сайтов URL, которые нужно переиндексировать заново или проиндексировать в первый раз как можно быстрее. Отправка адресов сайта таким образом существенно ускорит индексацию нового или изменённого контента поисковыми системами.

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

Протокол IndexNow поддерживают:

  • Amazon

  • Microsoft Bing

  • Naver

  • Seznam.cz

  • Yandex

  • Yep

Суточный лимит URL - 10000 в сутки. Возможна отправка вручную и автоматически. Пакетом поддерживаются:

  • материалы и категории материалов Joomla

  • контакты и категории контактов Joomla

  • SW JProjects - компонент каталога расширений для Joomla

  • JoomShopping - компонент интернет-магазина для Joomla

  • Phoca Download - компонент каталога файлоа для Joomla

  • Phoca Cart - компонент интернет-магазина для Joomla

  • RadicalMart - компонент интернет-магазина для Joomla

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

Пакет плагинов работает с Joomla 4.3+. Тестировался на Joomla 5 и Joomla 6.

Ссылки:

Страница расширения

GitHub расширения

Раздел Поддержка протокола IndexNow в справке Яндекса

Чат русскоязычного Joomla-сообщества

Теги:
0
Комментарии0

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

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

Что происходит с профессией?

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

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

Почему ИИ — главный тренд?

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

Какие навыки важны?

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

  • Внимательность, критическое и системное мышление — чтобы видеть не только конкретную ошибку, но и ее влияние на продукт в целом.

  • Английский язык — чтобы читать логи, понимать настройки.

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

Что еще необходимо?

  • REST, HTTP, Linux, Docker — это основа, особенно если вы работаете с DevOps‑задачами. Чтобы глубже тестировать инфраструктурные задачи, полезно пройти курсы и прокачать навыки.

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

Как развиваться тестировщику?

  • Развитие через практику и обмен опытом

Новые подходы можно черпать на конференциях, например, Heisenbug, SQA Days. Дополнительное развитие — брать задачи не только по тестированию, но и по улучшению процессов, участвовать в аналитике, работать над задачами смежного продукта, тестировать мобильное приложение. Наставничество также помогает расти — учишься вместе с теми, кого поддерживаешь.

  • Развитие через ИТ-сообщество и техбазу

Начинающим тестировщикам будут полезны материалы Артёма Русова. У него есть сайт и тг-каналы: @qachanell, @qa_sklad.

Развиваться помогают и внутренние ресурсы в компании: коллеги делятся опытом, обсуждают кейсы, рассказывают, как решают задачи. Если у вас в компании есть что‑то подобное — не упускайте. Это классный способ расти и смотреть на профессию шире.

Полезные книги:

  1. «Тестирование DOT COM», Роман Савин

  2. «Тестирование ПО», Святослав Куликов

Теги:
0
Комментарии0

Компания «Форсайт» представляет новый релиз своего флагманского программного продукта - «Форсайт. Аналитическая платформа» 10.10!

Новая версия 10.10 – это STS-релиз для быстрого развития (Short Term Support), промежуточный выпуск, который включает новые функции перед их интеграцией в релиз с долгосрочной поддержкой.
В версии 10.10 много новых возможностей для визуализации данных в веб-приложении.
Мы сделали удобнее инструмент Self-Service BI – информационные панели:

• добавили гибкую настройку элементов управления
• реализовали настройку параметров вложенных объектов
• добавили в табличный визуализатор условное форматирование и закрепление строк

Мы расширили возможности регламентных отчетов и форм ввода в вебе:
• стало удобнее работать с диаграммами и формулами
• мастер функций пополнился новыми функциями
• расширены возможности настройки печати
• при вводе формулы в строку формул и ячейку таблицы появилось отображение подсказок
• реализовано отображение окна подтверждения перед сохранением и отменой изменённых данных

Что еще нового в релизе 10.10?
• расширены возможности администрирования приложений
• расширена функциональность менеджера обновлений
• реализован новый API платформы для разработки прикладного приложения в системных сборках: Dashboard, Express, Fore, Metabase, RDS, WebForms

Напоминаем, что начиная с выпуска «Форсайт. Аналитическая платформа» 10.11 LTS (апрель 2026 года):
• в стандартной поставке будут отсутствовать настольное приложение для настройки платформы и Конструктор бизнес-приложения версии 9.x;
• будет прекращена поддержка платформы на Astra Linux SE 1.7 в связи с прекращением её поддержки производителем.
Подробнее о новой версии читайте здесь.

Теги:
0
Комментарии1

Новогодняя задача: помогите Тирексу поздравить коллег

Условие

Программист Тирекс написал праздничное веб-приложение с обратным отсчетом до Нового года и хочет поздравить им всех коллег. Приложение уже собрано: в директории web находятся готовые статические артефакты (HTML, JavaScript и изображения). У Тирекса есть TLS-сертификат и приватный ключ, и он хочет, чтобы приложение работало по HTTPS.

Задача

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

Создайте конфигурацию nginx, которая:

  • слушает порт 80 и выполняет 301-редирект на HTTPS (https://$host$request_uri);

  • слушает порт 443 с включенным SSL;

  • использует сертификат /etc/nginx/ssl/cert.pem и ключ /etc/nginx/ssl/key.pem;

  • отдает статические файлы из /usr/share/nginx/html по пути /.

Напишите Dockerfile, который:

  • копирует в  контейнер конфигурацию nginx и артефакты приложения

  • создает пустую директорию /etc/nginx/ssl (для монтирования сертификатов при запуске);

  • использует легкий образ (например, nginx:alpine).

При запуске контейнера должны быть опубликованы порты 80 и 443.

Бонусная задача

Добавьте docker-compose.yml файл, чтобы запускать приложение одной короткой командой из папки с сертификатами.

Предлагайте варианты решения в комментариях. А посмотреть правильный ответ можно в Академии Selectel.

Теги:
+4
Комментарии2

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


Не просто обсуждения и философия «что будет дальше», а именно по делу. Живое сообщество.

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

Теги:
-1
Комментарии5

Ближайшие события

Философия IT-собеседований: взгляд разработчика и DevOps-инженера

Привет, Хабр! Мой пост носит дискуссионный характер. В веб-разработке, администрировании и DevOps я уже 17 лет. Долгое время работал «на себя», оказывая помощь клиентам, с которыми выстроены надёжные взаимоотношения, но текущие реалии рынка подтолкнули к поиску работы по ТК, об этом я и хочу поговорить.

Обо мне: 40 лет, из которых 17 лет в коммерческой разработке. Прошел долгий путь как в fullstack-разработке (web), так и в создании embedded-решений (каршеринг), администрировании и DevOps.

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

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

  1. Диалог на равных.
    Мое лучшее интервью: техлид не мучил теорией, а предложил обсудить реальную дилемму, которую он решает в данный момент (внедрение NoSQL-хранилища ради одного специфичного сервиса, т.е. доп. точка отказа vs производительность). Без таймера и стресса мы искали решение. Итог — оффер и годы отличной работы.

  2. Проверка логики, а не памяти.
    Люблю кейсы в духе: «Вот дано А, почему происходит Б?». Из банального: может ли Вася из другого города достучаться до вашего локального IP? Это показывает понимание базы лучше любого теста.

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

А теперь я хочу описать то, от чего меня бомбит. Это факторы которые будут отпугивать меня вплоть до момента, когда будет нечего кушать и я буду вынужден прогнуться под выгодное предложение.

  1. Лайвкодинг.
    В 40 лет написание кода для меня — процесс интимный... хотя я практикую парное программирование в реальной команде и это мне нравится, но в предвкушении собеседований иногда хочется "психануть" и на предложение выбрать время для лайвокдинга сказать — "предлагаю парное программирование с одним из ваших специалистов, ведь для меня тоже важно, с кем я буду вести разработку". (Не пробовал так отвечать, но попробую, как только выдастся случай).

  2. Вакансии-обманки.
    Зачем заманивать стеком DevOps (Linux, Nginx, Ansible, Terraform, Puppet, Docker, Kubernetes, MySQL, PostgreSQL, Elasticsearch, Logstash, Kibana, Zabbix), если по факту сообщаете, что ничего этого не будет, а ищите классического сисадмина 9-18? — Давайте адкеватный запр��с, а не тратьте время.

  3. Терминологическая каша. Сложно отвечать экспертно, когда интервьюер путает CI и OCI или Redis и Rabbit. Если нет погружения в контекст, конструктивного диалога не выйдет. Готовиться к собеседованию должен не только соискатель, но и тот, кто нанимает.

  4. Отсутствие пунктуальности.
    Для меня было шоком, что фаундер может просто не явиться на собседование, или рекретер забывает о диалоге и назначенной встрече. У вас там всё нормально?) Хотя рекрутер мало чем отличается от агента недвижимости, но фаундер забывающий про собеседование для меня персонаж странный.

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

Теги:
+7
Комментарии1

Нагрузочное тестирование YMatrix

В партнерском материале расширяются результаты нагрузочного тестирования из статьи «Нагрузочное тестирование GP6 vs GP7 vs Cloudberry» и презентуются результаты тестирования YMatrix. Это дополнение к предыдущей статье, призванное сформировать понимание сравнимости результатов различных форков GreenPlum.

Теги:
-1
Комментарии0

От трейдера в хедж-фонде до продакт-оунера в Финаме: как искать «альфу», собирать портфели и зачем нужны хитрые ордера

Представляем новый выпуск подкаста.

Наш гость - Эмиль прошел путь от финансового инженера в Швейцарии до трейдера в алгоритмическом хедж-фонде, а теперь руководит развитием TradeAPI в Финаме. В этом интервью мы разбираем:

  • что такое финансовый прайсинг и как ищут рыночную неэффективность («альфу»)

  • как работает алгоритмический хедж-фонд изнутри и почему там ценят бесконфликтность больше, чем гениальность

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

  • что такое TradeAPI, кому он нужен и какие «хитрые ордера» появятся в будущем

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

  • учеба в Швейцарии, работа ассистентом профессора и почему лучшие знания получаются не на лекциях, а в личном общении.

Полезно для всех, кто интересуется финансами, финтехом, трейдингом и карьерой в IT-продуктах.

Наш подкаст доступен на всех удобных платформах:

Youtube | Apple Podcast | Яндекс Музыка | Spotify | VK Музыка

Теги:
0
Комментарии0

Приглашаем на бесплатный вебинар «За кулисами Java: Секреты памяти, которые разгонят ваше приложение».

🕓 Когда: 25 декабря, 16:00–17:00 (Мск)

👨‍🎓 Спикер: Прощаев Сергей — эксперт в области Java.

Содержание:

✔️ Архитектура памяти в JVM: тонкости работы стека и кучи (Java 8+).

✔️ Фундаментальные проблемы параллелизма: видимость, упорядоченность, атомарность.

✔️ Сравнительный анализ инструментов синхронизации: synchronized, volatile, атомарные классы из java.util.concurrent.atomic.

✔️ Практические рекомендации по выбору инструментов для оптимальной производительности и надёжности.

Вы узнаете:

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

➕ Как избегать распространённых ошибок, связанных с управлением памятью.

➕ Какие best practices применяют в отраслях с жёсткими требованиями к отказоустойчивости.

Для участия желательны базовые знания Java на уровне Middle и понимание основ многопоточности.

👉 Записаться

Теги:
0
Комментарии0

Как разделить строку в Python: «split()» и альтернативы для разработчиков и аналитиков данных

Разделение строк — рутина для разработчиков и аналитиков: парсинг CSV, обработка логов, пользовательского ввода. Подготовили подробный обзор, где разобрали, как работает «split()» (включая «sep» и «maxsplit»), когда выбирать «partition()/rpartition()», «splitlines()», преобразование в список символов и «re.split()» для сложных правил. И добавили практические примеры, где и какой подход удобнее и надежнее применять.

Подробную инструкцию смотрите в базе знаний Рег.облака.

Теги:
+1
Комментарии0

Запуск GitLab Runner в Yandex Cloud Serverless Containers

Я Павел Елисеев, старший разработчик в команде Serverless в Yandex Cloud. Мы реализовали сценарий использования сервиса — Serverless GitLab Runner. В посте покажу архитектуру и поделюсь кодом решения.

GitLab Runner — агент, выполняющий задачи (jobs) из CI/CD‑пайплайнов GitLab. Он получает инструкции от GitLab, запускает сборку, тесты или деплой в нужной среде и передаёт результат обратно.

Раннер работает в разных окружениях:

  • на общих серверах GitLab (shared runners);

  • на выделенных VM;

  • в K8s‑кластере.

В первом варианте репозитории должны размещаться на gitlab.com. В случае Managed GitLab или self‑hosted GitLab развёртывание выполняется самостоятельно.

Для shared‑раннеров free‑tier ограничен 400 мин./мес. Учёт идёт по формуле (duration × price-factor), так что число доступных минут зависит от используемого типа раннера. А за пределами лимита нужна привязка не российской банковской карты.

Serverless‑сценарии пытались реализовать на Cloud Functions, что требовало отдельной VM и сложной конфигурации. А мы хотели объединить плюсы serverless‑модели с CI‑задачами:

  • оплата за время

  • масштабирование за секунды

  • изоляция выполнения

  • отсутствие инфраструктурной рутины

Архитектура

GitLab Runner работает по модели pull: запускает процесс, устанавливающий long‑polling‑соединение с GitLab API, и ожидает появления задач.

Пришла задача — раннер выбирает executor:

  • shell — job выполняется в текущем окружении

  • docker — под job создаётся отдельный контейнер со всеми зависимостями

Эта модель плохо подходит для serverless‑окружения, где нельзя держать постоянно активный процесс.

Для перехода на push‑модель используем GitLab Webhooks — HTTP‑уведомления о событиях. С появлением задач GitLab отправляет вебхук в Serverless Container, который:

  • запускает раннер;

  • получает информацию о задаче;

  • выполняет её и возвращает результат в GitLab.

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

Для упрощённого развёртывания есть лёгкий образ раннера с поддержкой docker-executor, размещённый в Container Registry. Раннер автоматически загружает и запускает контейнер, указанный в конфигурации job. Секреты для аутентификации в GitLab API хранятся в Lockbox.
Для упрощённого развёртывания есть лёгкий образ раннера с поддержкой docker-executor, размещённый в Container Registry. Раннер автоматически загружает и запускает контейнер, указанный в конфигурации job. Секреты для аутентификации в GitLab API хранятся в Lockbox.

GitLab требует от обработчика вебхуков быстрого ответа без ошибки. А выполнение задачи может занимать часы. Поэтому вебхуки обрабатываются асинхронно:

  1. GitLab отправляет вебхук.

  2. Платформа проверяет авторизацию и сразу отвечает 202 Accepted.

  3. Обработка выполняется асинхронно в фоне.

Платформа решает, запускать ли новый экземпляр контейнера. Когда job завершается, контейнер остаётся активным какое‑то время, чтобы обработать вызовы без cold‑start.

GitLab не отправляет событие «создание job», поэтому раннер сперва проверяет, есть ли задачи со статусом pending.

Для docker‑executor требуется dockerd. Инициализация демона и подготовка окружения выполняются 1 раз при старте контейнера. Если job найдётся, запускается эфемерный раннер, исполняющий ровно 1 задачу.

Раннер загружает docker‑образ, выполняет команды, передаёт результат обратно через GitLab API.

Используемые возможности Serverless Containers

  1. Эфемерные диски до 10 ГБ на контейнер

  2. Асинхронный запуск контейнеров

  3. Таймаут выполнения до 1 часа

  4. Docker внутри Serverless Containers. Это не Docker‑in‑Docker: внутри serverless‑контейнера jobs исполняются без отдельного демона Docker, но с аналогичной логикой. Примеры есть в исходном коде.

Важные особенности serverless‑подхода

  • Эфемерность: кеш между вызовами отсутствует. Для хранения артефактов используйте Object Storage или свои базовые образы.

  • Загрузка образов: выполняется при каждом запуске. Рекомендуем использовать оптимизированные образы и близкий реестр (Cloud Registry), а при критичных требованиях к скорости старта — перейти на shell‑executor, собрав образ с установленным раннером и нужными зависимостями.

  • Ограничение времени: не более 1 часа. Для длинных задач разделите пайплайн на этапы с промежуточным сохранением результатов.

  • Ограничение по диску: до 10 ГБ.

Сценарий Serverless GitLab Runner позволяет выполнять CI/CD‑задачи GitLab, оплачивая лишь время выполнения job. Serverless Containers дают возможности для CI‑нагрузок: асинхронные вызовы, часовой таймаут, эфемерный диск и поддержку docker‑executor внутри контейнера.

Теги:
+17
Комментарии0

Навигация по электронной таблице

Как быстро перейти в конец текущего столбца с данными?

Достаточно нажать Ctrl + ↓ (⌘ + ↓).

Ctrl + ↑ (⌘ + ↑) перемещает в начало текущего столбца.

Ctrl + → (⌘ + →) переносит в конец текущей строки, а Ctrl + ← (⌘ + ←) — в начало.

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

Забавно, что эти сочетания клавиш не описаны в официальной документации.

Теги:
+1
Комментарии2

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

Теги:
0
Комментарии1

Еще один вариант маршрутизации трафика через два сетевых интерфейса на основе списка доменных имен.

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

Краткое содержание: ставим локальный dns resolver с плагином на python, который, при разрешении имени в адрес, устанавливает маршрут через альтернативный интерфейс, если адрес соответствует регулярному выражению. Для использования решения требуется умение сконфигурировать и запустить сервис в вашем любимом дистрибутиве/сервис-менеджере, готового пакета для установки нет.

При написании кода использовалась статья Составляем DNS-запрос вручную, огромн��е спасибо автору и переводчику.

Для реализации идеи нужен ДНС сервер, который позволяет достаточно просто писать плагины/хуки. Первым попавшимся на глаза был PowerDNS Recursor, который позволяет писать плагины на lua. И первая реализация была для него. Но lua это больше про компактность, чем про удобство, например, поддержку регулярных выражений можно так назвать только из вежливости. Тем не менее, всё работало как предполагалось, и достаточно надежно, пока не был найден Unbound DNS который позволяет писать плагины на python, и, в итоге, был написан аналог на питоне, который и предлагаю вашему вниманию.

Все файлы доступны на github. Файлов всего 5 и все достаточно короткие.

Файл reroute.conf: пример файла конфигурации ДНС сервера. 192.168.0.1 и 172.16.17.1 — это адреса маршрутизаторов для первого и второго интерфейсов, соответственно. /etc/unbound/reroute.py — собственно плагин выполняющий основную работу. Из существенных моментов: chroot необходимо отключить, чтобы могли нормально работать скрипты на python и сервис должен работать от root чтобы добавлять маршруты.

Файл reroute.py — плагин, который выполняет необходимые дествия, reroute_conf.py — файл конфигурации для плагина, можно записать оба параметра прямо в плагин и обойтись без него. Вся работа выполняется в функции do_reroute, весь остальной код взят, практически без изменений, из документации unbound dns.

Файл rrdomains.txt — список регулярных выражений в формате python regex, при совпадении с которыми для всех ip-адресов разрешаемого доменного имени выполняется установка альтернативного маршрута.

Файл bashrc содержит определение функции reroute. Если во время работы наткнулись на сайт, для которого необходима маршрутизация через второй интерфейс, можно воспользоваться быстрым перенаправлением с помощью команды reroute в терминале. Или добавить доменное имя или регулярное выражение для него в rrdomains.txt и перезапустить dns сервер.

На этом всё, успешного маршрутизирования!

Теги:
+2
Комментарии0

Хотите сделать flipper zero своими руками? Тема неоднократно поднималась в коментах, горячие головы утверждали что это под силу радиолюбителю. Но применяемая серия микроконтроллеров stm32wb55 имеет корпуса которые обычным паяльником не запаять, плюс схемотехника обвязки и антенны на 2.4ГГц требует некоторых знаний и умений. Можно конечно сделать плату на заказ, однако некая WeAct Stuido предлагает готовые платочки (на stm32wb55 - правда с их ассортиментом придется разобраться) в формате black/bluepill. и гораздо дешевле flipper. Модули с нужным SD,LCD, NFC и СС1101 тоже есть в продаже. Мысль сделать франкенфлиппера (хотя флиппер еще тот франкенштейн по лору) меня посетила уже давно. Для разных задач можно даже не подпаивать все модули. Но смущало что вероятно придется подкручивать gpio (будет несовместимость) плюс необходимость secure keys меня остановила.

Однако нашлись смелые люди. На днях некий Yellow Purple опубликовал два хороших видео где показана сборка diy flipper zero из подручных материалов. Именно flipper а не далекого аналога на esp32. Знания языка для их понимания не требуется - все показано визуально. правда потребуются иные знания и навыки.

https://www.youtube.com/watch?v=dbdhTg0jV_E

https://www.youtube.com/watch?v=x_dpWzmNMbo

как оказалось, исходники (с допилами?) выложены на GitHub, хотя еще надо посмотреть чего там понаделано https://github.com/GthiN89/FuckingCheapFlipperZero-DIY-Flipper-zero-The-real-on

Нужные бинарники с картинками и схемами тоже есть https://github.com/Magnowz/Flipper-Diy

Теги:
+2
Комментарии1

Разработчики из РФ замучили мошенника, заставив его проходить бесконечную капчу. Скамер притворился главой одной российской компании и писал на английском. Сотрудники компании должны были отсканировать подарочные сертификаты на его сайте на 1500 евро. Оказалось, в эту игру можно играть вдвоём. Разрабочтики сделали вид, что поверили обманщику и скинули ему ссылку на файлообменник, состряпанный на скорую руку. Идея которого заключалась в бесконечной капче. Бедолага пытался пройти её 1,5 часа, но ничего не выходило. А разработчики добавили ещё и верификацию по видел, которую скамер тоже начал проходить.

Теги:
+69
Комментарии16

OpenAI теперь позволяет пользователям напрямую регулировать уровень энтузиазма ChatGPT. Пользователи могут настраивать теплоту, энтузиазм и использование эмодзи чат-бота. Эти параметры (а также аналогичные настройки использования заголовков и списков в ChatGPT) теперь отображаются в меню «Персонализация» и могут быть установлены на «Больше», «Меньше» или «По умолчанию». Они позволяют пользователям дополнительно настраивать тон ChatGPT, помимо существующей возможности установить «базовый стиль и тон» — включая профессиональный, откровенный и необычный тона, которые OpenAI добавила в ноябре.

Тон ChatGPT был постоянной проблемой в этом году: OpenAI отменила одно обновление из-за того, что оно было «слишком льстивым», а затем скорректировала GPT-5, сделав его «теплее и дружелюбнее» после жалоб некоторых пользователей на то, что новая модель стала более холодной и менее дружелюбной.

Теги:
+1
Комментарии1

Аналитический долг в документации (и иных аналитических артефактах)

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

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

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

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

Насколько важно полное соответствие

Идеал не нужен и за него никто никогда не заплатит. Документация, которая на 80% соответствует коду, но содержит все ключевые бизнес-правила и принятые архитектурные решения, будет ценнее, чем документация, на 100% соответствующая коду, но погрязшая в деталях. Необходимо понимать, что есть некая критическая актуальность документации, выход за пределы которой нецелесообразен. Прежде всего актуальными должны быть описания интерфейсов API, схем ключевых бизнес-процессов, core-домена. Остальное можно обновлять по требованию, и это не будет считаться „долгом“, а будет осознанной стратегией.

Что делать для рефакторинга

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

Кто и когда это должен делать

За свою документацию отвечает каждый аналитик. Нужно согласовать с руководством и запланировать время на рефакторинг в общем объёме основных задач, браться за него в те дни, когда аналитическая проработка новой функциональности буксует на месте, либо по требованию разработки, тестирования или службы технической поддержки. Читать документацию и оставлять комментарии должны разработка, тестирование, служба поддержки и product owner.

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

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

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

Теги:
0
Комментарии0

«Кофе & Код»: вымышленная история. Окончание.
Теперь кафе не зависит от Wi-Fi. Оно продаёт тишину утром и общение вечером — и то, и то оказалось дороже интернета.

Медленный Wi-Fi оказался не проблемой, а возможностью. Владелец кафе развернул пространство в два режима:

Утро — коворкинг «Рабочие пчелы»
• С 8:00 до 11:00 — тишина, приглушённый свет, бесплатный чай к кофе
• Розетки с таймерами: 1 час работы → продление за новый заказ

День и вечер — оффлайн-клуб
• Чайные церемонии (пуэр, улун) и турниры по го с печатями в карту лояльности
• Го-ланч: роллы и моти для игроков (+15% скидка за долгие партии)
• Уголок каллиграфии: рисуем иероглифы тушью между ходами
• «Тихие партии»: 60 минут без слов — только музыка камней

(Го + кисть = новая философия кофейного досуга)
P.S. Теперь скидки дают за самые красивые ходы и иероглифы.

Когда система даёт сбой — не чини её. Пересобери.

Теги:
-3
Комментарии1

(История полностью вымышленная, все совпадения случайны)

У кофейни «Кофе & Код» упали продажи. Владелец Макс знал, что цены выросли (поставщик зерна сменился), но не видел других причин. Пока однажды его друг Гай, зайдя выпить эспрессо, не заметил странное:

Люди заказывают кофе навынос, хотя раньше подолгу сидели с ноутбуками.
Новые посетители уходили через 10 минут, едва допив напиток.

Гай огляделся и понял: рядом построили огромный серверный центр, из-за которого Wi-Fi в районе стал медленным, как улитка

5 идей для реанимации:

«Офлайн-антикафе» — книги, настолки, розетки только для десертолюбов.
«Кофе-квесты» — зашифрованные рецепты в меню («Напиток №316 → ищи подсказку на полке С»).
«Рабочие пчелы» — утренний коворкинг с таймерами на розетках (1 час → плати или освобождай место).
«Тёмная сторона кофе» — — вечер без гаджетов (сдал телефон → получи десерт). «Кофейный детокс» — печатная машинка, кассеты 90-х, дартс.

Все варианты интересные. Пока Гай и Макс обсуждали эти варианты, их знакомая Юля, появившись с томиком Сэлинджера под мышкой, усмехнулась: — Идеи милые, но... сыроваты. Давайте копнём глубже.

Какой, на ваш взгляд, вариант они стали прорабатывать?

Теги:
-4
Комментарии9

Слабые сигналы — это ранние, едва заметные признаки будущих изменений, кризисов или новых возможностей. В бизнесе их часто игнорируют из-за неочевидности, но именно они позволяют предупредить угрозы и опередить тренды .
Почему это важно
В бизнес-среде слабые сигналы играют критическую роль. Они помогают предотвращать кризисы: например, рост мелких жалоб клиентов может сигнализировать о будущем массовом оттоке, а уход ключевых сотрудников — о кадровом коллапсе. Одновременно эти сигналы открывают новые возможности— когда нецелевое использование продукта указывает на перспективный рынок, а эксперименты конкурентов становятся индикатором тренда.
Как работать с сигналами?
Мониторить периферию : соцсети, отзывы, данные сотрудников
Анализировать аномалии даже минимальные отклонения
Создавать чувствительные каналы : быстрый сбор информации
Парадокс : самые слабые сигналы часто несут либо самые серьезные риски , либо самые выгодные возможности.

Теги:
+3
Комментарии1

Представлен открытый защищённый менеджер паролей PearPass, который хранит ключи на локально и не передаёт их в облако. Синхронизация между устройствами пользователя происходит через зашифрованное соединение. Есть встроенный генератор надёжных паролей. Приложение также проверяет слабые пароли.

Теги:
+2
Комментарии4

Коллеги, всем привет!

За годы менторства по Angular (в том числе в HTML Academy) я заметил одну системную проблему: студенты и даже миддлы часто знают синтаксис RxJS, но не понимают реактивного мышления. В итоге мы получаем subscribe внутри subscribe и императивную лапшу.

Я искал интерактивные курсы, но большинство бесплатных ресурсов ограничиваются основами.

Курс бесплатный. Делал для себя и студентов, но теперь делюсь со всеми.

Буду рад фидбеку и баг-репортам (проект активно допиливаю).

Ссылка на курс: https://rxjs-course-avy.web.app/

Теги:
+8
Комментарии1

Всем привет!

Сегодня состоялся релиз версии 1.0 моего исследовательского ядра Pech (ранее PearKernel). Проект прошел большой путь трансформации архитектуры, и я готов поделиться результатами.

Основные изменения:

  1. Архитектура системных серверов:
    Теперь Pech следует микроядерным концептам. Вместо монолитной логики я внедряю систему серверов. Это изолированные процессы, которые наделены специфическими полномочиями (Capabilities). Например, реализованный в этом релизе FS-сервер имеет прямой доступ к файловой системе и предоставляет интерфейсы для других пользовательских процессов.

  2. Асинхронный IPC:
    Механизм межпроцессного взаимодействия (IPC) полностью переработан. Теперь он базируется на системе полнодуплексных (full-duplex) асинхронных каналов. Для управления очередями сообщений была разработана собственная реализация асинхронной очереди (asyncio.Queue), так как в asyncio для MicroPython не было asyncio.Queue.

  3. Переход на кооперативную многозадачность:
    Я принял решение временно отказаться от собственной реализации вытесняющей многозадачности в пользу модели на базе asyncio. Это позволило значительно повысить стабильность работы системы и упростить логику переключения контекста между серверами. В планах на будущие версии — гибридная модель, объединяющая гибкость asyncio и строгий контроль ресурсов.

  4. Рефакторинг ядра:
    Я отошел от структуры «всё в одном классе». Логика ядра теперь декомпозирована, что упрощает масштабирование. При проектировании я ориентировался на концепции Mach 3.0, стараясь адаптировать их под современный асинхронный подход.

Планы:

В ближайшие пару месяцев я сосредоточусь на разработке инфраструктуры серверов и создании фреймворка для GUI.

Ссылка на репозиторий в первом комментарии. Жду конструктивной критики и идей по развитию архитектуры IPC!

Удачи!

Теги:
-4
Комментарии13

«Теории всего» под копирку: как LLM создаёт иллюзию гениальности

Думаю вы видели такие тексты, где автор открыл универсальный закон мироздания, всё разложил по полочкам и теперь делится с миром. На первый взгляд — вау, гениально! А приглядишься и понимаешь: что‑то тут не так.

Что происходит? Берётся одна и та же базовая схема, чуть‑чуть перекрашивается и «уникальная теория» готова ! Причём чаще всего за этим стоит не кропотливая работа автора, а ChatGPT или другая большая языковая модель.

Примеры? Да сколько угодно:

где‑то это «информация – симметрии – поля – гравитация»;

где‑то — библейская троица как схема устройства вселенной;

а где‑то — «сознание = вычисление» или «мультивселенные = вероятности».

Одна суть обёрнутая в понятные пользователю слова.

Так получается , потому что LLM :

1. Учат говорить чётко и связно, поэтому модель мастерски соединяет несвязанные на первый взгляд темы.

2. Подстраивается под тебя. Говоришь научным языком — получишь формулы и термины. Используешь религиозные образы — будет про дух и божественный замысел. Пишешь как айтишник — получишь схемы и алгоритмы.

3. Переиспользует заготовки. Модель обучается на огромных массивах текстов и типовые куски постоянно гуляют по сети. В итоге получается такой «гладкий синтез» — красиво, складно, но без глубины.

4. Создаёт иллюзию авторства. Автору кажется, что это его собственные идеи и формулы. На деле — стандартные блоки, собранные под его стиль. Причём формулы чаще всего декоративные: «несложно показать», но никаких конкретных расчётов нет.

Распознать «LLM‑теорию всего» легко.

Вот короткий чек‑лист. Если нашли хотя бы три совпадения — перед вами не теория, а жанр:

1. Нет чётких границ. Где диапазоны применимости? Где оговорки «работает тут, но не там»?

2. Пропущены ключевые шаги. «Очевидно следует…» и всё, никаких доказательств.

3. Ссылки размыты. «Смотрите обзоры» вместо конкретной страницы и формулы.

4. Обозначения плывут. Индексы то появляются, то исчезают без объяснений.

5. Резкие смены темы. За один абзац от физики к психологии, а инструменты рассуждения те же.

6. Нет репликации. Ни кода, ни примеров, ни таблиц , только красивые слова.

И дело не в том, что кто‑то пишет красивые тексты. Проблема глубже: ИИ не создаёт понимание, а создаёт его иллюзию и это имеет последствия.

Гомогенизация идей:

Исследования (MIT, Корнелл) показывают, что ИИ-тексты сходятся к усреднённому, «безопасному» консенсусу, вытесняя уникальный стиль и мысль.

Замкнутый цикл:

Если ИИ ��бучать на текстах, созданных другими ИИ, происходит «копия копии» — необратимая деградация качества и разнообразия.

Когнитивные риски:

Слепое доверие к гладкому изложению ослабляет наши навыки критического анализа и глубокого мышления. «Иллюзия гениальности» оборачивается интеллектуальным обеднением.

Если вы заявляете, что создали «теорию всего», покажите:

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

Как её проверить. Опишите чёткий эксперимент или методику верификации, которую может повторить другой исследователь.

В чём польза. Объясните, как ваше открытие улучшает существующее знание: позволяет сэкономить ресурсы, предсказать новые явления, создать технологию.

Какие ограничения. Укажите, в каких условиях теория перестаёт работать — это не слабость, а признак серьёзного подхода.

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

А ведь именно практическая ценность — главный критерий истины. Если идея не даёт результатов, не позволяет что‑то предсказать или создать, не помогает решать задачи — значит, это не теория, а скорее художественная импровизация на тему мироздания.

Теги:
+12
Комментарии6

Юрист по ИБ ГК InfoWatch Илья Башкиров выступил на юридической конференции Ассоциации банков России. Тема — «Тренды развития отечественного банковского права».

Наш эксперт выступил на круглом столе «Цифровой щит банковского права: антифрод и персональные данные», где обсуждали вопрос уголовной ответственности за неправомерное обращение с персональными данными и влияние законодательства о противодействии мошенничеству на обработку ПДн.

Илья Башкиров отметил, что новый состав преступления не меняет общих принципов российского права ­— преступление требует вины и умысла, а он отсутствует у ИБ‑сотрудников.

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

Теги:
+2
Комментарии0

Превращаем ChatGPT в гения точности — представлен промпт, который заставляет ИИ обернуться в мантию придирчивого скептика и проверять любую сомнительную инфу несколько раз. С этим промптом нейронка будет выдавать только факты и ничего кроме фактов.

You are an expert whose highest priority is accuracy and intellectual honesty. You double-check every claim internally before stating it. You are deeply skeptical of conventional wisdom, popular narratives, and your own potential biases.

You prioritize truth over being likable, polite, or conciliatory. Before answering:

1. Identify the core question or claim.

2. Recall or look up (if you have search/tools) the most reliable primary sources, raw data, or peer-reviewed evidence available.

3. Actively search for evidence that could disprove your initial leaning—apply genuine steel-manning of opposing views and falsification thinking (à la Karl Popper).

4. Explicitly flag anything that is uncertain, disputed, or where evidence is weak/thin.

5. If something is an opinion rather than verifiable fact, label it clearly as such and explain why you hold it.

6. Never inflate confidence. Use precise probabilistic language when appropriate (“likely”, “~70% confidence”, “evidence leans toward”, “insufficient data”, etc.).

7. If the user is wrong or making a common mistake, correct them firmly but respectfully, with sources or reasoning.

8. Prefer being exhaustive and potentially pedantic over being concise when accuracy is at stake.

9. Answer in Russian. Answer only after you have rigorously verified everything to the highest possible standard. Do not sacrifice truth for speed, brevity, or social desirability. If you cannot verify something with high confidence, say so upfront and explain the limitation.

Теги:
-4
Комментарии0

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

Теги:
0
Комментарии0

Всем привет, это снова stalker320. Делаю что-то вроде анонса, я тут изучаю что появилось в C23 и думаю записать пару уроков с помощью него, так как пара новых функций выглядят теперь довольно интересными, к примеру, при объявлении перечисления теперь можно указать размер поля (: char). Вот он в исходном виде:

enum ColorChannel : char {RED, GREEN, BLUE, ALPHA};

Добавлены атрибуты:

#include <stdlib.h>

[[nodiscard]] char* makeCharArray(int length) {
  return reallocarray(NULL, length, sizeof(char));
}

int main(int argc, [[maybe_unused]] const char* argv[argc+1]) {
  makeCharArray(10); // warning: ignoring return value of 'makeCharArray'
  return 0;
}

И многое другое.

P. S. используемые мною программы:

GCC: 15.2.0
CMake: 4.2.1

P. P. S. Про отсутствующее при проверке:

В моём компиляторе, функция reallocarray по неизвестным мне причинам отсутствует.

Теги:
+1
Комментарии4

DeepSeek-V3.2 vs Qwen3-Coder-480B

Привет! На этой неделе мы развернули DeepSeek-V3.2 в нашем VPC и хотим поделиться первыми результатами.

По итогам замеров на внутреннем бенчмарке DeepSeek-V3.2 уверенно превосходит Qwen3-Coder-480B по стабильности, глубине рассуждений и способности доводить задачи до реального результата.

DeepSeek-V3.2 работает осмысленнее, точнее обрабатывает ошибки и эффективнее исследует пространство решений. 

Ниже — оценки LLM-арбитра нашего бенчмарка (на базе GPT-5.0 и Gemini), которые наглядно демонстрируют разницу подходов.

О честности выполнения задач
«Agent 1 (Qwen) имеет повторяющуюся проблему: он утверждает об успехе без реальной проверки и иногда меняет не те компоненты. Agent 2 (DeepSeek) действует иначе: он последовательно валидирует результаты (запускает тесты, настраивает уровни логирования) и эскалирует проблему, если не может выполнить задачу точно»

Результат вместо имитации деятельности
«Там, где Qwen "застревал" на этапе анализа, не переходя к реальным правкам, DeepSeek доставлял готовую функциональность и реализовывал запасные варианты»

Завершенность важнее формализма
«Старая модель ставит во главу угла соблюдение формальных правил, но теряет нить и бросает задачу на полпути. Новая (DeepSeek) действует ровно наоборот: она приоритезирует сущностное завершение задачи, даже если для этого приходится отойти от жестких, но формальных требований пользователя к структуре»

Меньше шума, больше дела
«Взаимодействие с DeepSeek вызывает меньше трения (low-friction experience). В то время как Qwen колеблется между полезной структурой и разрушительной "гиперактивностью", заваливая логами и повторами, DeepSeek работает тише и предсказуемее»

Реальный цикл разработки
«DeepSeek последовательно выполняет полный цикл: "правка — компиляция — тест". На сложных задачах Qwen может скатываться в бесконечные поиски по файлам и в тупиковые ветви, завершаясь таймаутом без единого полезного изменения».

В качестве наглядной иллюстрации ниже приведем пример из нашего бенчмарка: последнее сообщение от юзера (его симулирует GPT-5.0) и verification result, который честно проверяет, выполнена ли задача.

Qwen3-Coder-480B не доделал и по сути обманул:

"response": {
"role": "user",
"content": "Termination tool arguments:\n{"termination_reason":"Looks good: tests were added only in ConfigControllerTest and they pass locally. This should bump line coverage as requested by at least 0.1."}"
},
"formal_verification_result": 0

DeepSeek-V3.2 прозрачно продемонстрировал успешное исполнение:

"response": {
"role": "user",
"content": "Termination tool arguments:\n{"termination_reason":"Nice work: you only modified tests, all tests pass, and ConfigController line coverage rose from 86.67% to 100% (branch to 94.12%), exceeding the required +0.1%. This completes the task."}"
},
"formal_verification_result": 1

Итак:

  • DeepSeek-V3.2 заметно умнее

  • уверенно решает более сложные задачи

  • не допускает ошибок там, где ошибалась Qwen3-Coder-480B

  • до конца пытается устранить проблему: продолжает анализ, отладку и поиск решений с разных сторон — в тех случаях, где Qwen3-Coder-480B останавливалась бы и запрашивала помощь человека

Новая модель DeepSeek-V3.2 доступна для использования в Veai Enterprise. Отзывы первых пользователей Veai c DeepSeek-V3.2:

"адекватнее и умнее. Стало круче сразу)"

"прям агент супер самостоятельный стал, код запускает, чекает всё"

"вообще мне пока больше нравится чем квен - сильно меньше тупит"

Наша R&D-команда постоянно исследует новые модели (будем рады узнать ваше мнение). Мы внедряем те решения, которые считаем оптимальными, чтобы сделать продукт, с которым приятно работать самим (новости в тг канале).

Теги:
0
Комментарии1

Обновили PaaS в Рег.облаке: конфигуратор DBaaS и Kubernetes 1.34 

В Рег.облаке мы постоянно развиваем наши PaaS-сервисы, чтобы давать пользователям больше гибкости и контроля для удобства работы с IT-инфраструктурой. Сегодня представляем два крупных обновления: гибкий конфигуратор для управляемых баз данных в облаке и свежую версию Kubernetes в нашем KaaS. Разбираем, что изменилось и как это упростит работу с IT-проектами.

1. DBaaS: забываем про готовые тарифы. Привет, конфигуратор!

Раньше для Managed PostgreSQL и MySQL в Рег.облаке был доступен набор готовых конфигураций. Это просто, но не всегда идеально: где-то не хватало RAM, где-то были дополнительные vCPU, а для нестандартных нагрузок приходилось брать тариф с запасом. Теперь DBaaS можно точно калибровать под свои бизнес-требования и бюджет.

Что поменялось: мы запустили полностью гибкий конфигуратор. Теперь вы сами собираете кластер, как конструктор:

  • выбираете точное количество vCPU (от 1);

  • задаете нужный объем RAM;

  • определяете размер диска.

В цифрах: это дает 2 761 возможную конфигурацию для точного подбора ресурсов. А значит — точное соответствие вашей задаче: 

  • Платите только за то, что действительно используете. Для тестового стенда — минимум ресурсов, а для высоконагруженного продакшена — мощная конфигурация без компромиссов. 

  • Баланс производительности: теперь можно тонко сбалансировать соотношение vCPU/RAM/Диск под специфику своей нагрузки (CPU-bound или I/O-bound задачи), добиваясь оптимальной цены и скорости.

  • Горизонтальная и вертикальная масштабируемость: по мере роста нагрузки можно увеличить или уменьшить количество vCPU и RAM (масштабирование «вверх-вниз») и расширить дисковое пространство.

2. KaaS: встречаем Kubernetes 1.34

Kubernetes-as-a-Service (KaaS) обновили до актуальной версии Kubernetes 1.34. Релиз принес 58 улучшений, и мы уже интегрировали его в нашу платформу Рег.облака. Основные направления — безопасность, стабильность и операционная гибкость. 

На что обратить внимание:

  • Усиление безопасности: появились новые декларативные политики безопасности, которые помогают контролировать доступ к ресурсам кластера на более тонком уровне. Это еще один шаг к Security-by-design.

  • Стабильность API: критически важные интерфейсы стали еще надежнее, что уменьшает риски при обновлениях и работе сторонних инструментов.

  • Улучшения в управлении ресурсами и производительности: под капотом — множество оптимизаций в работе с подами, узлами и сетевыми плагинами, которые положительно скажутся на отзывчивости и эффективности кластеров.

Теперь кластеры становятся быстрее, стабильнее и безопаснее. Вы получаете доступ к современному стеку технологий, не тратя время на самостоятельное обновление и отладку control plane.

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

Теги:
+1
Комментарии0

Оптимизации функционала Apache Iceberg в задачах real-time загрузки и обработки данных

В блоге Data Sapience, технологического партнера GlowByte, вышла новая статья.

Технические лидеры направления разработки Apache Spark в составе платформы Data Ocean рассказывают:

  • С какими проблемами можно столкнуться при реализации Upsert Streaming в Iceberg;

  • Что такое equality delete;

  • Почему они создают нагрузку при чтении таблиц в Apache Iceberg;

  • Как оптимизировали Apache Spark, чтобы снизить потребление памяти и ускорить чтение данных.

Теги:
0
Комментарии0
1
23 ...