Python *

📐 Применение природных алгоритмов оптимизации в строительном проектировании

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

🧬 Генетические алгоритмы (GA) Основаны на естественном отборе и эволюционной генетике. В проектировании используются для оптимизации топологии и сечений элементов. Классические примеры — подбор оптимальных размеров подошвы и глубины заложения фундаментов, оптимизация сечений балок и рам. Алгоритм итеративно “скрещивает” варианты, отсеивая решения с недопустимыми осадками, недостаточной несущей способностью или перерасходом бетона.

Отдельное направление — задачи раскроя. Генетические алгоритмы успешно применяются для оптимизации 2D-укладки деталей сложной формы на листах металла, чтобы минимизировать отходы. В 3D-постановке это работает при компоновке арматурных каркасов, раскладке сборных элементов в опалубке или плотной упаковке конструкций для перевозки.

🐜 Алгоритмы роевого интеллекта (Swarm Intelligence) Моделируют поведение групп организмов: миграцию птиц, поиск пищи насекомыми. Наиболее известны метод роя частиц (PSO) и муравьиный алгоритм (ACO). Применяются для трассировки инженерных сетей, автоматического армирования плит, оптимизации геометрии сложных фундаментов. PSO эффективно распределяет усилия по расчётной сетке конечных элементов, снижая концентрацию напряжений за счёт корректировки параметров армирования локальными агентами.

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

🔥 Алгоритмы имитации физических процессов К ним относится метод имитации отжига (Simulated Annealing), который моделирует кристаллизацию металла при охлаждении. Используется для решения комбинаторных задач: календарное планирование, оптимизация логистики движения материалов, расстановка монтажных кранов, распределение бригад по захваткам при жёстких пространственных и временных ограничениях.

⚠ Ограничения и инженерная практика При всех возможностях природные алгоритмы не заменяют классические расчётные комплексы (МКЭ/FEM). Сегодня они выступают как эффективные препроцессоры: генерируют концептуальные схемы расстановки несущих элементов, варианты раскроя и календарные графики, которые затем проходят обязательную ручную верификацию инженером-конструктором и финальный проверочный расчёт в сертифицированном ПО на соответствие СП/СНиП.

Такой подход позволяет сократить рутину на ранних этапах, но оставляет ответственность за итоговое решение человеку.

Как бы я учила Python, если бы могла отмотать время назад...

# Не судите строго, впервые пиши пост, понимаю, что может быть не интересно (по причине опыта), но все же хочется внести свой вклад

Всем привет! Меня зовут Фаина я уже несколько лет пишу на Python (и не только) и зарабатываю этим на жизнь. Недавно я наткнулась на свои старые "конспекты" с первых попыток изучения языка. Это было... больно. Сотни скриншотов, обрывочные заметки и полное непонимание того, что происходит.

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

1.Перестать коллекционировать курсы (и начать делать)

Моя самая главная ошибка — «синдром хомяка». Я скачала, наверное, 50 ГБ курсов: "Python с нуля", "Python для чайников", "Python за 24 часа". Я смотрела первые два урока, чувствовала себя умной, а потом бросала, потому что "этот курс не очень".

Итог: Один хороший курс + практика лучше, чем 50 идеальных курсов в папке "Разобрать".
Сейчас, если бы я начинала, я бы выбрала один интерактивный ресурс (или одну книгу, если, конечно, сможешь так учится) и шла по нему, пока не упрусь в стену. Не прыгала бы между ютуберами и методичками.

2.Сначала гуглить, потом — паниковать

В начале пути любая ошибка в коде вызывала у меня панику. Красный трейсбек выглядел как приговор. Я думала: "Ну всё, я бездарь, Python меня ненавидит".

Итог: Ошибка — это не "я плохая", это "код говорит мне, что именно не так".
Сейчас 80% моей работы — это чтение ошибок и гугление.

3.Зубрежка синтаксиса не работает. Работают проекты

Я думала, что если выучу все методы списков и словарей наизусть, то стану сеньором. Я исписывала тетради шпаргалками. Толку было ноль.

Итог: Ты запоминаешь только то, что используешь руками.
Вместо заучивания теории, я бы начала писать мини-программы с первого дня.

• День 3: Калькулятор чаевых.

• Неделя 2: Парсер курса валют с сайта (с помощью requests).

• Месяц 1: Простенький телеграм-бот, который присылает погоду.

Проекты не обязаны быть гениальными. Они должны быть действительно интересные, даже захватывающие.

Если ультра-кратко:

1. Лучше уж один источник знаний вместо "все сразу"

2. Лучше практика каждый день по 30 минут, чем раз в неделю и до потери пульса

3. Ошибки - это норм, не стрем

4. С другом или ментором будем веселее и эффективнее - с кем можно поделится опытом или обсудить код и тд.

Спасибо за внимание, ваша Фаина!)

Какие уникальные фичи есть в django-modern-rest?

Иногда, когда я добавляю какие-то фичи в мой https://github.com/wemake-services/django-modern-rest (можно ставить ⭐), то я думаю про себя: почему таких фичей больше нет нигде? 

Давайте сегодня посмотрим на них. А вы мне расскажите свое мнение в комментах.

Семантическая схема 

Допустим, вы навесили на какой-то свой endpoint auth: 

class UserController(Controller[MsgspecSerializer]):
      @modify(auth=[JWTAsyncAuth()])
      async def get(self) -> User: ...

В OpenAPI автоматически появятся все коды ошибок, которые могут случиться в auth (401).
Ничего не надо допом писать. И так происходит со всеми частями фреймворка: добавил throttling=[SyncThrottle(1, Rate.minute)]? Теперь у тебя в ответах автоматом 429. Если нужно, можно отключить любые семантические статусы. 

Не должно ли такое быть дефолтом везде?

Умные типы ошибок

Не уходя далеко: как кастомизировать формат ошибки, например, в FastAPI? Через боль. Как поменять в спеке формат? Руками.

В DMR мы просто добавили везде error_model как параметр. Можно заменять любые ошибки, все автоматом сконвертится и покажет правильную схему. Зачем? Хочешь Problem Details - используешь. Хочешь свой формат - реализуешь. Можно даже content negotiation на ошибки навесить.

Почему никто о таком не думает в других фреймворках?

Нормальный throttling

Фича, которая принесла мне больше всех боли. Я прочитал throttling реализации во всех фреймворках. В Litestar даже фиксы присылал. 

1. Почти нигде из коробки нет поддержки разных алгоритмов, бекендов, иногда даже cache-keys. Очень жаль, есть только обычный counter с бекендом в памяти
2. Нигде (пришлите в комменты контр-пример) нет разделения на throttling до auth и после. Почему такое вообще важно? Чтобы не заддосить auth. И чтобы иметь возможность выдавать per-user правила. Нужны и важны оба варианта
3. Кастомизация заголовков ответа? Ха!

Что? Почему?

Простое переиспользование кода

Когда я смотрю на АПИ разных DRF проектов или FastAPI, мне становится больно. FastAPI строит все на view функциях, которые нельзя нормально кастомизировать. А DRF строит все на импортах строк внутри настроек. А как на счет классов и наследования?

У нас подобное сделано как абстрактные generic классы. Например: получить JWT. Можно выбрать любой сериализатор, можно выбрать любые модели для запроса и ответа:

class RequestPayload(pydantic.BaseModel):
     username: str
     password: str

class ResponsePayload(pydantic.BaseModel):
     access: str
     refresh: str

class ObtainAccessAndRefreshSyncController(
    ObtainTokensSyncController[
        PydanticSerializer,
        RequestPayload,
        ResponsePayload,
    ],
): ...  # надо еще переопределить 2 метода

Все типизировано, документировано, очевидно. 
Как вы думаете, почему так больше никто не делает?

Внешние вьюхи

Интегрировать один фреймворк в другой - крайне сложно. Вот мы недавно даже стрим проводили, потому что не могли использовать dj-rest-auth из DRF. Так быть не должно.

Теперь в DMR можно использовать любые внешние Django View. Хоть DRF, хоть django-ninja, хоть ванильные вьюхи. И отображать любой внешний OpenAPI. Вот настолько просто:

raw_schema = read_openapi_yaml('openapi.yml')
router = Router(
    urls=[
        external_path(
            'number/', number, name='number',
            openapi=load_schema(raw_schema['paths']['/api/number'], PathItem),
        ),
    ],
)

Почему другие фреймворки не стараются вписать существующие решения?

Одной строкой

- Больше подобного у меня в тегеграм канале "Находки в опенсорсе": https://t.me/opensource_findings
- У нас есть еще куча других крутых фичей! Заглядывайте в наш чатик по DMR
- Релизнули django-stubs@6.1 с поддержкой django@6.1
- Сделали папку с крутыми каналами ребят из нашего Python сообщества. Смело можно закидывать коллегам как базовую папку "на кого подписаться в тг по питону". Внутри все мои друзья и коллеги, советую!

Задача о стабильной очереди задач

И это не тавтология... Проверьте свое знание синтаксиса, критическое мышление и умение вчитываться в ТЗ.

Условие

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

Через пару часов инженер бьет тревогу в рабочий чат: «Ребята, у нас проблема! График застыл! Похоже, планировщик завис или сеть легла, процессы не плодятся!». Вы открываете логи, смотрите на графики мониторинга и… Система работает абсолютно штатно, никакого бага нет.

Задача

Объясните паникующему инженеру, почему его логика отказала. Как так получилось, что количество задач не растет? Напишите простую симуляцию этого процесса на Python, чтобы наглядно показать коллеге, как ведет себя такая очередь.

Убедитесь, что все решили правильно, — загляните в Академию Selectel.

Представлен открытый проект Memora, который сохраняет работу Codex и Claude Code между сессиями. Внутри решения находится локальная база SQLite или синхронизация через S3, R2 и Cloudflare D1. Есть также семантический поиск, TODO, документы и связи между воспоминаниями. ИИ-агент запрашивает тему и получает готовый комплект данных: важный контекст, незакрытые задачи, связанные факты и ссылки на источники. Причём всю память можно открыть как интерактивный граф и изучать через встроенный RAG-чат.

Попросил ИИ чат нарисовать ИИ агента

Привет!

Заметка о том как работает алгоритм инкрементальной загрузки, она же дельта, в ETL процессах. Полезно будет для тех кто только погружается.
Для загрузки данных в хранилище данных мы выполняем два отдельных процесса: первоначальную загрузку исторических данных и инкрементальную загрузку. Первый процесс делается разово, а второй выполняется периодически.
Инкрементальная загрузка выбирает только новые, еще не загруженные данные из источника в цель.
Например, пользователи постоянно генерируют новые данные, бизнес работает. Система запускалась час назад и забрала новые на тот момент данные. При следующем запуске алгоритм определяет максимальную дату в цели:
max_timestamp = SELECT MAX(timestamp) FROM target_table

и выбирает все записи из источника которые новее max_timestamp

SELECT * FROM source_table WHERE timestamp > max_timestamp

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

Nvidia представила открытый проект Nemotron VoiceChat. Это голосовой ИИ‑агент, способный открывать любые инструменты по команде пользователя в реальном времени:

• Nemotron говорит с вами без пауз и умеет в эмоции;

• разрешает вам перебивать себя с задержкой всего 480 мс;

• умеет вызывать инструменты посреди диалога — поиск в сети, календарь и так далее;

• поддерживает сложные сценарии использования;

• обучен на 550 тысячах часов речь;

• умеет слушать, говорить, прерывать ответы и вызывать инструменты в рамках одного диалога.

Представлен открытый проект repowise — оптимизатор кодовых баз, который экономит токены в кодинге и работает с Claude Code, Cursor, Copilot:

• не читает каждый файл, а сразу индексирует весь репозиторий;

• создаёт документацию для каждого файла;

• строит графы зависимости и анализирует историю Git с слабыми местами;

• неиспользуемый код и устаревшие зависимости чистит сам;

• результат: минимальная задокументированная экономия — 36%.

SmileLadder. Как трилогия про "память и мозг" привела к циклу про управление вниманием. Пост №1 - от синтетической к реальной ЭЭГ

В прошлой статье я попробовал описать внимание как динамическое распределение весов в графе. Тогда нейронная активность, оцениваемая по ЭЭГ, были синтетическими: граф состоял из модельных узлов, а сигнал генерировался осцилляторами в модели Хиндмарша-Роуза.

Публикация получилась сложная и я этим постом попытаюсь перейти к разбору исследования вопроса управления вниманием. Первое, что я попробую - это возьму реальную ЭЭГ: Для проверки я использовал открытый датасет STEW — Simultaneous Task EEG Workload. В нём 48 участников: для каждого записаны состояние покоя и работа с многозадачным тестом SIMKAP.

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

Берём реальную EEG - там 14 EEG-каналов, частота дискретизации 128 Гц. Всего 96 записей.

Каналы сгруппированы по областям: префронтальной, фронтальной, фронтоцентральной, височной, теменной и затылочной. Полная таблица соответствий лежит в репозитории.

Вот так использую свою модель

EEG делится на окна по 4 секунды с шагом 2 секунды. Для каждого окна рассчитываются четыре компонента:

1. спектральная вовлечённость - отношение активности beta к theta и alpha;

2. alpha gating - изменение задней alpha-активности;

3. фазовая организация - согласованность theta-ритма между передними и задними каналами;

4. пространственная селективность - насколько неравномерно распределена вовлечённость по каналам.

На этих 14 каналах обучается графовый attention-readout. В коде он называется узелTHAL - это скрытый вычислительный узел-оркестратор.

Практический результат: у 48 участников из этого датасета медиана ASI-EEG составила:

• 0,5129 в покое;

• 0,5311 при высокой нагрузке.

Медианный парный сдвиг равен +0,0218, 95% bootstrap-интервал — [0,0049; 0,0533]. Парный критерий Уилкоксона дал p = 0,00182. Это означает, что нулевая гипотеза об отсутствии различий отвергается, так как p-value меньше стандартного уровня значимости 0,05. 

На этих данных ASI-EEG действительно реагирует на изменение когнитивного состояния. Это уже не результат виртуальной EEG, а эффект, полученный на записях реальных тестов.

Есть и второй пруф: графовый классификатор проверялся с разделением участников между фолдами. На уровне целой записи он различил покой и нагрузку с точностью 88,5%, а ROC AUC составил 0,969.

Все числа сохранены в summary.json, а расчёт можно повторить по исходному коду:

python "Model GAT/stew_asi_gat_experiment.py" \
  --dataset dataset \
  --output "Model GAT/results" \
  --bootstrap 5000

Практический цикл управления вниманием я теперь вижу так:

задачи и контекст → оценка ожидаемого фокуса → EEG-маркер фактической нагрузки → обратная связь → корректировка списка задач

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

Код, данные расчёта и графики: GitHub-репозиторий - его я форкнул от задачи идентификации и дописал свою часть.

unreal‑assets‑to‑glb

Это небольшой pip пакет, позволяющий вам конвертировать ресурсы unreal engine времени редактирования (не сборки игры) в модели формата glb.

особенности:

• интерфейс cli с поддержкой команды help

• поддерживает предварительный просмотр уровней (umap)

• фильтрация ассетов для экспорта только определенных моделей

• кэширование текстур для ускорения экспорта в будущем (если несколько раз выполняете экспорт)

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

• базовая поддержка сеток без анимации или костей без автоматического масштабирования с коэффициентом 100 к 1

В видео я показываю, как модель отображается в другом игровом движке после импорта конвертированных uasset-файлов

главное преимущество: вообще не требуется устанавливать UE

исходный код: https://github.com/Prikalel/unreal-assets-to-glb. пакет pip: https://pypi.org/project/unreal-assets-to-glb/

сгенерированные файлы могут быть легко импортированы в другие движки, такие как godot / unity и т.д.

в настоящее время поддерживаются 2 версии UE engine: 5.5 и 4.27.2

вы также можете заметить, что некоторые материалы в тестовой сцене частично затемнены - это связано с тем, что пакет не позволяет вам правильно экспортировать все настройки материалов / все настройки шейдеров (ограничения перечислены на странице github, это освещение, положение камеры и другие параметры, но базовое извлечение 3d-сетки работает идеально).

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

Лицензия GPL-3.0

MCP 2026-07-28: что действительно изменилось

Главное изменение — MCP стал stateless на уровне протокола. Убрали обязательные initialize, initialized и Mcp-Session-Id. Версия протокола и возможности клиента теперь передаются в каждом запросе, а сведения о сервере можно получить через server/discover. Любой запрос может обработать любой экземпляр сервера — без sticky sessions и общего хранилища сессий. Состояние приложения никто не запрещает: просто передавай явные идентификаторы вроде browser_id в аргументах инструментов.

Что ещё важно:

1. Долгие операции получили нормальный жизненный цикл. Tasks позволяют вернуть taskId, а затем проверять состояние через tasks/get, передавать дополнительные данные через tasks/update и отменять работу через tasks/cancel. Но Tasks не появились с нуля — раньше это была экспериментальная часть ядра, теперь её переработали и вынесли в официальное расширение.

2. Протокол стал удобнее для эксплуатации. Заголовки Mcp-Method и Mcp-Name позволяют маршрутизировать запросы, не разбирая JSON. Появились стандартные подсказки для кеширования — ttlMs и cacheScope, а также единые поля для передачи OpenTelemetry Trace Context.

3. Переработано общение сервера с клиентом. Вместо произвольных server-to-client запросов сервер теперь может вернуть input_required, после чего клиент повторяет исходный запрос с ответом пользователя. Подписки на изменения вынесены в subscriptions/listen.

4. Extensions стали полноценной частью экосистемы. Новые возможности теперь можно развивать отдельно от ядра. Первые заметные расширения — Tasks и MCP Apps. Последнее позволяет серверу отдавать интерактивный HTML-интерфейс, который клиент показывает в изолированном iframe.

5. Есть важные ломающие изменения. Все результаты теперь содержат resultType. Roots, Sampling, Logging и старый HTTP+SSE объявлены устаревшими. Схемы инструментов получили полноценную поддержку JSON Schema 2020-12. Если ты пишешь MCP-клиент или SDK, этот пункт может оказаться важнее MCP Apps.

6. Авторизацию подтянули ближе к реальному OAuth/OIDC. Добавили проверку iss, привязку учётных данных к конкретному issuer и уточнили регистрацию клиентов и работу с refresh-токенами.

В сухом остатке: remote MCP перестал требовать обязательную протокольную сессию и стал гораздо больше похож на нормальный stateless JSON-RPC поверх HTTP. Для продакшена это означает более простое горизонтальное масштабирование, маршрутизацию и кеширование. Остальные изменения полезны, но в основном касаются новых возможностей и миграции клиентов.

• спецификация MCP 2026-07-28

• ключевые изменения в деталях

tg

«Bad Apple!! Но это же traceroute! В продолжение моего поста о том, как заставить инструменты traceroute отображать произвольное содержимое, и вдохновлённый выходом на днях ещё одной кавер‑версии Bad Apple, я просто не мог не сделать это», — пояснил Йонас Шефер.

Используя функцию numgen из библиотеки nftables, мы можем изменять количество переходов каждый раз при генерации пакета ICMPv6. Функция numgen возвращает либо случайные числа, либо монотонный счетчик. С помощью счётчика мы можем легко настроить каждый переход так, чтобы он возвращал разный IPv6-адрес при генерации ответного пакета.

Для этого потребовалось ещё две вещи. Во-первых, необходимо отключить ограничение скорости ядра (по умолчанию 1/с) для исходящего трафика ICMPv6 с помощью команды sysctl net.ipv6.icmp.ratelimit=0, иначе всё закончится очень быстро. Вторая проблема заключается в том, что mtr обычно показывает несколько адресов для каждого узла, поскольку это указывает на использование нескольких разных путей для пакета, и это обычно полезная информация.

После всего этого я использовал ffmpeg для передискретизации видео до 8 кадров в секунду (что соответствует интервалу в 125 мс между кадрами) и экспорта уменьшенных (до 30x11 пикселей) отдельных кадров в файлы PNG. Затем я написал скрипт на Python для чтения файлов изображений и преобразования их в набор правил nftables для генерации соответствующих ответов ICMPv6. В результате получается чуть более мегабайта правил nftables, но это определённо того стоит.

PyPI готовится закреплять префиксы имен пакетов за организациями

29 июня 2026 года был принят PEP 752. Он описывает механизм, с помощью которого пакетные репозитории смогут закреплять префиксы имен за определенными организациями. Например, новые пакеты с префиксом google-cloud- смогут публиковать только организации, получившие соответствующее право.

Сейчас пространство имен PyPI остается плоским. Если название свободно, пользователь может зарегистрировать пакет, который выглядит частью известного проекта, например, google-cloud-something, opentelemetry-something или apache-airflow-providers-something. Знакомый префикс повышает доверие к названию, хотя реального отношения к организации у пакета может не быть.

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

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

Принятый PEP пока описывает стандарт, а не уже работающую функцию PyPI. Правила подачи и рассмотрения заявок вынесены в PEP 755, который остается черновиком. Срок запуска механизма также пока не объявлен.

PEP 752 переносит часть проверки на самый ранний этап, когда в репозитории только появляется новое имя. Для семейств пакетов вроде google-cloud-* или apache-airflow-providers-* это позволяет остановить постороннего издателя до того, как правдоподобно названная подделка станет доступна пользователям.

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

Когда механизм заработает, новые метаданные можно будет использовать не только на страницах PyPI. Менеджеры пакетов и корпоративные прокси смогут пропускать пакеты с защищенным префиксом, только если издатель имеет на него право. Это точечная защита от одного семейства атак на имена; остальные сценарии неймсквоттинга мы разбирали в статье «Атаки на цепочку поставки ПО: виды угроз и как с ними бороться».

Подписывайтесь на CodeScoring в Telegram, VK, YouTube и Макс.

Сначала хотел написать комментарий к этой статье, но потом подумал, что пост лучше.

Наверно, просто каждый язык предназначен для решения своего круга задач. Когда-то фортран был языком для вычислений. Паскаль - для обучения. Си - для системных разработок. А вот Бейсик (я про компилируемые варианты) был универсален. :) Оттого, наверно, я его и выбрал в начале 90-х. Хотя с тех пор от него ничего не осталось, даже в плане синтаксиса, не говоря про огромные возможности...

А вот вопрос: какой язык может быть выбран в качестве "бытового"? Это не шутка. Лично я регулярно сталкиваюсь с необходимостью написать "одноразовую" программу, маленькую и не сложную. Для этого нужен простой язык и легкий транслятор.
Раньше я использовал VB3, но он на новых системах не работает. Потом "открыл для себя" SmallBasic и даже написал по нему некое пособие. Язык хороший, реально! Но есть один огромный минус, в силу чего он не годился для искомой роли: не работает с двоичными файлами.
Свой собственный язык ("Ellochka") я так и не удосужился до сих пор перевести под Виндовс (остался интерпретатор для ДОС).
Питон, увы, тоже не подходит: язык не очень прост, а главное - среда огромная, с флешки запускать несерьезно (а надо).

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

Ваш проект живёт дольше трёх месяцев? Код начинает сопротивляться изменениям: одна фича тянет правки в пяти файлах, тесты падают без внятного объяснения. Знакомо?

На бесплатном вебинаре «Антипаттерны в Python: как не превратить код в спагетти» разберём, где именно возникают эти точки напряжения, и что с ними делать.

📆 Когда: 30 июля, 16:00–17:00 (Мск)

👨‍🎓 Спикер: Читалов Дмитрий, специалист в области Python разработки

В программе:

✔️ Глобальные переменные

✔️ God Object

✔️ Spaghetti Code

✔️ Наследование ради наследования

✔️ Primitive Obsession

✔️ except: pass

✔️ Копипаста

✔️ Магические числа

✔️ Вложенные циклы O(n²)

✔️ Over-engineering

По каждому пункту — плохой код, разбор проблемы и готовый рефакторинг.

✍️ Регистрация

Задача о вирусе и 1 000 серверах

Представим, что в вычислительном кластере из 1 000 серверов одна машина заражена неизвестным вирусом. Он не нагружает процессор, не генерирует подозрительный сетевой трафик и не оставляет следов в системных журналах. Только раз в сутки вирус незаметно повреждает один файл резервной копии.

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

• Status: 500 — если среди проверяемых серверов есть зараженный;

• Status: 200 — если зараженного сервера в группе нет.

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

Задача

Помогите Олегу определить — предложите решение, которое позволит определить один зараженный сервер из 1 000 возможных за 10 запусков анализатора. Напишите код на Python, который по результатам проверок сможет определить номер зараженного узла.

Посмотреть решение

Привет!

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

Поделитесь в комментариях)

Upd. Спасибо за комментарий, важная оговорка: проект работает локально на вашем компе, без утечек в инет)

Представлен открытый проект ODS (Osmantic Deployment System). Это проект, который превращает ПК в приватный ИИ‑сервер. Решение само определяет характеристики ПК, подберёт под них подходящую модель, скачает её и запустит локальный инференс:

• все локально и приватно: можно работать с документами, кодом и другими важными данными;

• через одну панель можно подключить голосовых помощников, агентов вроде Hermes, RAG, поиск, генерацию изображений и десятки других инструментов;

• без облачного сервиса. Без подписки.

Агент Ануфрий получил красивый вывод в терминал (отключаемый через конфиг).

Как всегда, ничего сложного, используются две библиотечки Rich + Prompt Toolkit. Вся эта красота хранится в отдельном модуле console, легко сможете разобраться, переделать, или подчерпнуть что-то для своих проектов. Кода там совсем немного.

Репозиторий: AgentAnufry

Есть идея в отдельной ветке Ануфрия запилить “кибербезопасника”, вырезав все лишнее и напихав скилов под инструменты Kali Linux. Мне кажется, тут LLM может проявить себя с хорошей стороны, если грамотно предоставить инструментарий.

Возможно что-то похожее уже кто-то реализовывал? Если да, поделитесь информацией об успехах.

P.S.: Ануфрий - это мой проект простого конструктора для создания собственных ассистентов на Python.