Все потоки
Поиск
Написать публикацию
Обновить
1046.62

Программирование *

Искусство создания компьютерных программ

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

Вглядываясь в бездну.

Чем дольше живу, тем сильнее поражаюсь способности людей «заплетать» свои собственные мозги. И, кажется, программисты в этой области вне конкуренции.
Уже писал некоторое время назад, как я завел цикл внутри цикла с тем же именем счетчика.
Это было пару часов отчаяния, сопровождавшегося размышлениями о том, что фундаментальные законы мира внезапно изменились, а меня забыли поставить об этом в известность.
Недавно я повторил этот трюк, правда с некоторыми занятными модификациями. Был у меня в проге цикл по объектам в списке. Там смысл в том, что при некотором условии новый объект добавлялся в конец этого самого списка. Все бы ничего, но в этот момент счетчик объектов инкрементировался. А он то как раз и служил верхней границей цикла… В общем, как легко понять, дело кончилось segmentation fault… Но эту бажину (хотя она даже более заморочная на мой вкус) , я нашел относительно быстро, не успев погрузиться в бездну отчаяния. Кода было немного, поэтому обошлось без смен компилятора и переустановок IDE… В этот раз, можно сказать, повезло. И бездна отчаяния меня миновала. Но тот, кто ищет проблем, обязательно их находит. И что самое удивительное, что я их нахожу всегда в одном месте.
Я в-общем то хорошо знаю, что люди еще не придумали ничего хуже конечных автоматов (state machines). И вот уже 35 лет регулярно наступаю на одни и те же грабли… В этот раз мне всего-навсего нужен был один флаг. В задаче Винтика и Шпунтика используется нетривиальный алгоритм, многократно использующий рекурсию. Ну и мне нужен был этот флаг, как индикатор того, что некое событие произошло. А когда происходило другое событие, этот флаг сбрасывался. Стандартная, в-общем, ситуация, но внутренний голос немедленно поднял «красный флаг опасности» и зашептал в голове «Нахлебаешься, Валер, ой, нахлебаешься...» И вот тут бы мне остановиться и подумать, но я, как обычно, решил, что сейчас сделаю, а подумаю потом…
Все дело в том, что эти флажки (или состояния конечного автомата) имеют дурное свойство размножаться, куда быстрее чем кролики. За первым флажком немедленно последовал второй — ну просто для того, чтобы обозначить функцию, которая первый флаг установила. А потом третий, чтобы обозначить функцию, которая его сбросила… И мне уже казалось, что вот они разверзающиеся врата ада, но, конечно же, это было еще не так.
Ибо настоящий ад наступил, когда программа стала многопоточной. И это еще при том, что у меня есть хорошая привычка обкладывать модификацию всех этих флажков критическими секциями. Даже если не надо. Всегда легче потом убрать и удивиться тому, что все работает, чем сутками докапываться, почему нет. Это уберегло меня от многих проблем, но не уберегло от главной. Сейчас этих флажков в программе 12. И они живут своей собственной жизнью. Я уже не в состоянии отследить кто, где, когда и зачем их модифицирует. Начал думать о том, что надо бы ввести для каждого флажка некую структуру, которая будет содержать ответы на эти вопросы. Но тут уже внутренний голос встал на дыбы, и, как ни странно, в этот раз я его послушал.
Вот сижу теперь и думаю над романом (или длинным рассказом) о программисте, который взялся за непосильной сложности алгоритм и постепенно сходит с ума. Хуже того, что он это сам понимает, и ему становится страшно. Но поскольку он программист, то свой мозг он считает конечным автоматом, и пытается его «отлаживать». Таким образом запускается бесконечная цепь рекурсий. И периодически ему приходит в голову мысль, что надо все бросить и написать заново. Но он боится потому что давно уже потерялся и не знает на каком уровне рекурсии он находится… Такой вот юмористический (а может и не юмористический) хоррор с элементами мистики. И легким флером безнадеги из набоковской «Защиты Лужина».
Ну вот. Написал пост. Немного отвлекся. Пойду дальше код дебажить…😁

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

Помогает ли олимпиадное программирование в реальной разработке

Этот и ещё пять тезисов об олимпиадном опыте разобрали с бывшим олимпиадником, Антоном Чаплыгиным, и неолимпиадником, Мишей Усковым. Оба — ведущие инженеры-программисты в Контуре.

В тусовке олимпиадников существует определённая культура превосходства и часто эти ребята воспринимают неолимпиадников как менее квалифицированных программистов 

Неолимпиадник: Да. Я ощутил это, когда учился на первых двух курсах универа: перед сессией ребята-олимпиадники говорили, что даже не будут готовиться к экзамену, потому что и так всё знают. 👌 Потом они, конечно, всё заваливали, шли на пересдачу, но гонора до этого момента было много. =) Со временем такие ребята стали проще.

Олимпиадник: Подтверждаю! Например, я пришёл в универ из регионального лицея и у меня были проблемы с неалгоритмическими предметами, например, матанализом. Те, кто уже учил его, считали, что они-то всё знают, а я — нет.  

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

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

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

Неолимпиадник: Согласен, что в продуктах алгоритмических задач мало, но они часто критичные. Ты можешь делать 900 простых задач, но без сложных вообще никуда не уедешь. В Контуре есть своя база данных, своя очередь. Мы можем сделать в сервисе много красивых финтифлюшек, но если у нас не будет быстро работать база, мы никому не будем нужны. 

Вот ты пользуешься какими-нибудь библиотеками, фреймворками, но при этом не знаешь, что происходит внутри, — это не прикольно. А олимпиадные задачи часто про структуры данных, про Computer Science, и это всё хорошо бы знать.

При этом я считаю, что где-нибудь в промышленной разработке лучший олимпиадник — далеко не всегда лучший программист. Ведь программист — это не только про «У меня есть задача, я превратил её в код», а скорее про «Я знаю, с кем поговорить, что уточнить».

Олимпиадников сложно переучить, они склонны оптимизировать несущественные вещи 

Неолимпиадник: У нас в команде были олимпиадники, и когда они брались за задачи, было видно, что им интересно их «покопать», сделать из этого красивое решение, чтобы оно идеально работало. Это всё хорошо, но не всегда такое надо, особенно когда хочется уже быстрее получить результат. =) В этот момент приходилось немного поторопить человека. А потом подсластить ему пилюлю: например, дать прикольную задачу с Computer Science.

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

Алгоритмические задачи на собеседованиях не всегда показывают реальные навыки разработчика 

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

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

Эти и другие тезисы подробно разобрали здесь ➡️ YouTube, Rutube, VK, Яндекс Музыка.

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

Как понять архитектуру компании по вакансии. Часть-1

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

Аутсорс

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

Про продукты и стек технологий

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

Очевидно, что это что-то для ИБ и сетей. Go — вполне разумный выбор для таких задач. «Инфраструктура открытых ключей» и «миграция лесов Active Directory» — это не просто так! Возможно, они мигрируют с C/C++ на Go или совсем новый проект. Тут уже есть подозрение, что они только начинают что-то на Go

Микросервисы и Kubernetes

"Создавать новые функции и модули в микросервисной архитектуре."

Вот тут всё совсем интересно! Сразу вопрос: сколько у вас людей? 3? Масштабируете? Что, куда, в каком горизонте? "Зачем вам это?" Если ответ просто "масштабирование" — скорее всего, у вас будет ещё один зоопарк из сервисов, которые никто не сможет поддерживать, и которые в итоге собьются в одну большую "монолитную миграцию на микросервисы"

Kubernetes и операторы

"Создавать операторы Kubernetes для интеграции Kubernetes с инфраструктурой открытых ключей". (за 250-350к)

Ммм, тут вообще красный флаг! Людей, кто умеет работать с такими задачами на уровне оператора в Kubernetes, на рынке не так уж много. Так что зарплата в 250-350 — это явно недооценка. Есть подозрение токсичности культуры, если честно

А где сама вакансия?

Правильно, ниже

——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура

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

Немного лекций с нашего митапа питонистов в Новосибирске - PythoNSK (https://t.me/python_in_nsk приходите, в ноябре планируем вторую встречу организовать).

У нас на митапе было несколько лекций, вот они:

Python Desktop Development (Роман Черкасов) - Программирование на QT + PySide: https://youtu.be/Xmh74WNheRM?si=mR9ecx3KzTxA4tWF
Как работает greenlet в async-реализации SQLAlchemy (Любимов Алексей) - https://youtu.be/zPXf9NJc5qA?si=VyosK69QPdtDivAY
Лекция от Никита Соболева ("Как коммитить в питон, если вы очень хотели, но не знали как?") - https://t.me/opensource_findings_chat/115827

Я хочу также отдельно поблагодарить:

  1. ТГ snppg - инициатор всего нашего действия, он изначально создал эту группу, а я просто подхватил и организовал людей

  2. ТГ duntssov - за интересную и хорошую лекцию, помощь

  3. ТГ THEDAN320 - за помощь в организации

  4. ТГ masian4eg

  5. ТГ RnChe - за проведение лекции

  6. ТГ sobolev_nikita - за проведение онлайн лекции

  7. И конечно же вам все за то что пришли. Вместе мы - сила, и кто знает, может митапы перельются во что то большее

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

Я переписывался с товарищем на тему архитектуры и сформировал более цельное понимание построения ООП-кода :)

Чуть-чуть обо мне: в разработке 12+ лет, сделал 50+ различных приложений и ещё немножко игр, это только для бизнеса, плюс еще мои личные эксперименты и petproject-ы.

Делая все эти приложения я пришел к тому что есть разные подходы к проектированию\моделированию систем, в частности с помощью ООП-кода:

(Условно назову эти типы в игровой терминологии так как разговор был с человеком из геймдева и игры мне тоже близки, кстати, я и программировать то начал чтобы делать игры 😁, итак вот эти подходы: )

1. "Action" - когда ты описываешь объекты как будто смотришь на описываемую систему изнутри (вид из глаз), фокус на взаимодействие объектов между собой в моменте, моделируются в первую очередь сущности и упускаются процессы.

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

3. "God Mode" - когда ты делаешь все что душе угодно (читай как и то и другое, "Action" и "Strategy" в одном флаконе)

И так же я пришел к тому что есть несколько слоев моделирования\проектирования:

(как сказали бы в Теории Систем - есть надсистема, есть система и есть подсистема, а Шрек описал бы это как слои лука, а Осел рассказал бы что это напоминает слоёный торт 😁)

1. Уровень реальности в которой есть человек пользователь, используемый девайс (десктоп, ноутбук, смартфон, и т.п.), сервер с бэкендом; правила их взаимодействия (интерфейсы, протоколы, договоренности); и процессы в которых это взаимодействие происходит (циклы, цепочки событий, потоки данных)

2. Уровень приложения в котором есть сущности бизнес-логики(игровой логики), например Hero, Enemy, Obstacle, Menu, Map, Score; правила их взаимодействия; и процессы в которых происходит взаимодействие

3. Уровень инструментов в котором есть сущности языка программирования такие как примитивы(Int, Long, String, Bool), структуры данных, основные компоненты игрового движка(операционной системы); правила их взаимодействия; и процессы в которых происходит это взаимодействие

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

На каждом слое может использоваться как ООП подход так и ФП, так и нечто смешанное что добавляет удобства.

К чему это все? Наш разговор начался с того что я вбросил мнение что самая чистая архитектура обычно это чистейший ООП-код, и удобство архитектуры зависит как раз от навыка моделирования систем этим ООП-кодом.

Такие дела :)

Я по прежнему считаю что ООП рулит! 😁

А что думаешь ты про ООП, архитектуру и чистый код?

Делись своим опытом в комментариях, или нет..

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

MCP архитектура как развитие ручного подхода в LLM

Когда вы открываете ChatGPT и вставляете туда кучу текста — что реально происходит?
Всё складывается в один длинный «бутерброд»: данные, инструкции, системный промпт, даже куски схемы в Markdown. Никакого порядка. Это как если бы у вас в кодовой базе был один файл main.py, где и роуты, и бизнес-логика, и SQL-запросы.

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

Как это выглядит у ChatGPT

На схеме выше видно:

  • Есть Line Edit — пользователь копипастит сырые данные.

  • Есть Плагин — иногда он что-то подмешивает.

  • Всё это сливается в один большой Склеенный промпт, который уходит в LLM.

Мешанина как она есть

Как это делает MCP?

MCP приходит и говорит: «ребята, давайте хоть модули разнесём».

  • System Prompt — отдельная часть, где живёт логика «как правильно жить» для модели.

  • Instruction Layer — патчи и локальные корректировки.

  • Schema Registry — отдельный каталог, который описывает структуру данных (таблицы, поля, форматы).

  • Data Adapter — слой, который достаёт данные у провайдера строго по схеме.

  • Всё это связывает MCP хост, который собирает финальный запрос к LLM, который зачастую представляет собой Lang Chain

Итог: модель получает запрос не как «мусорный мешок», а как структурированный pipeline.

Почему это важно

  • Прозрачность. Можно отследить, какая часть отвечает за что.

  • Контроль. Можно менять системный промпт без страха поломать данные.

  • Расширяемость. Хочешь новый источник данных? Добавь адаптер, а не переписывай всё.

  • Предсказуемость. Поведение модели становится ближе к детерминированному.

Простая метафора

  • ChatGPT — это когда у вас «final_final_v3.docx» и все правят его параллельно.

  • MCP — это когда у вас git с ветками, пайплайнами и CI с CQRS архитектурой (не шутка), читай выше

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

Я исследовал тему связности и связанности в построении кода и вот к чему пришел:

Не существует плохих\хороших\идеальных связности и связанности кода.

Мне кажется проблема и решение глубже - сколько людей столько и вариантов осмысления и построения "модели", столько вариантов же coupling & cohesion. У каждого что-то свое.

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

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

Ведь суть всего этого моделирования чтобы "на понятном" объяснить железу что и когда нужно сделать.

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

Ну и когда я говорю ООП, это не значит что я буду писать абстракцию на каждый чих, влоть до Int, Long и т.п., нет, это значит что я начну с самых больших MyApp { UserClient, ServerClient, DeviceClient } и законтачу их между собой логикой приложения, а там дальше буду создавать абстракции по необходимости, если будет удобно и полезно что-то добавить и переиспользовать то я добавлю и переиспользую (вот кстати хороший критерий - моделировать сущность когда надо что-то передавать между главными абсракциями(надсистемами)).

ООП рулит :)

P.S. И не надо стремиться к идеалу, иначе тут можно скатиться в подмену задач, и начать делать не данное конкретное приложение, а предложенный кем-то идеал архитектуры.

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

Email и бухгалтерия: почему заголовки писем всё ещё угрожают деньгам компаний

Недавно я писал в одной из новостей про новый стандарт электронной почты — RFC 9788. Тогда это выглядело как чисто техническое обновление: поправили старый костыль, добавили пару параметров, придумали новые заголовки. Но если посмотреть на это глазами бизнеса, особенно глазами топ-менеджмента и бухгалтерии, картина оказывается совсем другой.

Электронная почта — это не только переписка с коллегами или рассылка клиентам. Это канал, через который каждый день проходят платёжки, инвойсы, запросы на переводы. И именно эта часть коммуникаций десятилетиями оставалась в зоне риска, потому что заголовки писем (From, Subject, To) никак не защищались. Мы могли шифровать тело письма, подписывать вложения, использовать все возможные фильтры, но если злоумышленнику хотелось заменить тему на «Срочный перевод контрагенту», он мог это сделать.

В результате бухгалтер получал письмо, где всё выглядело честно: защищённый текст, привычный формат счёта, даже подпись была на месте. А заголовки — самое видимое и доверенное место письма — могли быть переписаны. Именно на этом десятилетиями держались самые простые и самые успешные схемы email-фишинга.

И вот только в 2025 году IETF принял новый стандарт — RFC 9788. Он наконец-то говорит очевидную вещь: защищать нужно не только тело письма, но и заголовки. Теперь все поля копируются внутрь зашифрованной части, наружу выходит только технический минимум, а тема письма может заменяться на […]. Если кто-то попробует подделать заголовок, клиент сразу покажет рассинхрон.

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

Да, внедрение будет постепенным: сначала open source-клиенты и энтузиасты, потом корпоративные почтовики, потом массовый рынок. Но уже сейчас очевидно, что компании, которые раньше внедрят RFC 9788, снизят риски быстрее. Это история не про «технологическую моду», а про то, сколько денег вы теряете или экономите.

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

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

RFC 9828: стандарт, который, странным образом, опоздал лет на двадцать

JPEG 2000, появившийся ещё в начале нулевых, давно используется в задачах, где требуется высокое качество изображения, а RTP как транспорт для данных реального времени уже более двадцати лет обеспечивает надёжность. Однако, и это удивительно, всё это время отсутствовал формализованный стандарт, позволяющий передавать JPEG 2000 с минимальной задержкой, по кускам кадра, не дожидаясь его полной готовности, — и лишь в 2025 году он был наконец принят. Можно только гадать, почему в мире, где запускают ракеты в космос по подписке, инженеры продолжали смиренно ждать, пока кадр целиком упадёт в буфер.

Теперь же, с появлением RFC 9828, ситуация меняется: простое на первый взгляд решение — передавать кадр частями, а не целиком, — становится официальной нормой. Как только кодер начинает производить данные, пакеты уже могут быть отправлены в сеть, а приёмник, не дожидаясь окончания всего кадра, начинает сборку изображения. И именно это означает, что впервые JPEG 2000 становится пригодным для таких сценариев, где маркетинговый термин «low latency» оборачивается критическим требованием: телевещание в прямом эфире, дистанционная хирургия или работа со сверхкачественным изображением в реальном времени.

Вместо прежнего порядка «сначала кадр, затем поток» появляется обратный — «сначала поток, затем кадр». Благодаря этому сеть получает ту самую гибкость, о которой раньше говорили как о недостижимой: лишние уровни разрешения и качества можно отбрасывать на лету, даже не вскрывая содержимое. Приёмник, в свою очередь, обретает resync-точки, благодаря которым потеря пары пакетов больше не превращается в катастрофу, а разработчики, наконец, могут избавиться от бесконечных костылей, изобретённых в обход RFC 5371.

Выгоды для бизнеса очевидны, хотя каждый сектор формулирует их по-своему. В телевидении по IP режиссёр теперь видит кадр практически сразу, а не спустя полсекунды, и значит — работа в реальном времени перестаёт быть фикцией. В медицине появляется возможность стримить эндоскопию или МРТ с качеством вплоть до lossless и при этом не терять драгоценные секунды, от которых зависит исход операции. Кинопроизводство перестаёт таскать гигабайты по дискам, потому что мастер-кадры наконец-то могут пересылаться по сети. Даже государственные сервисы, включая суды и видеоконференции, приобретают шанс выглядеть не как мем из 2008 года, а как инструмент XXI века.

Да, пока это лишь бумага. Но, как обычно бывает: сначала RFC, затем — первые SDK и FPGA-решения, а чуть позже — перепакованные в отраслевые документы SMPTE и ITU стандарты. В горизонте двух-трёх лет мы увидим первые реальные внедрения в телевидении и медицине, в горизонте пяти — широкое распространение. А дальше, возможно, даже lossless-видеозвонки без лагов перестанут казаться фантастикой.

RFC 9828 — это не просто ещё один формат. Это признание индустрии в том, что ждать конца кадра всё это время было, мягко говоря, глупо.

Ссылки, как обычно, в моём канале

——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура

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

Дайджест: новое за лето ☀️

🤖 Запустили AI-помощника Клаудию — она доступна в вашем личном кабинете. Клаудия поможет создать ВМ, уточнит задачу и подберет конфигурацию, подскажет команды в консоли. А еще настроит виджеты, алерты и нотификации для контроля ВМ, поможет найти нужное в документации и выступит как co-pilot. Попробуйте бесплатно — новым пользователям дадим 4 000 рублей на облачные ресурсы.

🖥️ В Evolution Foundation Models открыли доступ к новым open source моделям, в том числе к OpenAI 120b, Qwen-3, GigaChat, GLM-4.5 и другим. Всего доступно 20+ LLM, ранжировщиков и эмбеддеров, а до 31 октября вы можете бесплатно потестировать их на своих проектах.

Участвовали в крупных мероприятиях:

  • Провели митап Cloud․ru Tech Lab: AI&ML, где рассказали, как автоматизировали пользовательские сценарии с помощью AI-агента, разобрали устройство агентов, RAG и Ragas. А еще слушатели могли вживую пообщаться с экспертами, «прожарить» свое резюме и посетить демозону AI-решений на базе Cloud․ru Evolution.

  • Организовали конференцию GoCloud Tech 2025 о создании решений на базе AI и облаков. Обсудили кейсы внедрения AI&ML, тренды в создании облачной инфраструктуры, актуальные практики для работы с данными в облаке.

  • Во второй раз приняли участие в крупнейшей AI-выставке в мире — World Artificial Intelligence Conference в Шанхае 🇨🇳 На нашем стенде мы показали платформу Cloud․ru Advanced, провели встречи с Geely, Tencent, Baidu, IFlytek, GAC, TikTok, Alibaba, Li Auto и другими зарубежными компаниями.

🧠 Запустили бесплатный курс про создание ML-моделей и их внедрение в бизнес. Будет полезно менеджерам продуктов и проектов, DS-, backend- и frontend-разработчикам, продуктовым дизайнерам. Можно учиться в комфортном темпе, а в конце дадим именной сертификат.

✨ Предлагаем бесплатно протестировать сервисы Evolution Data Platform — новой платформы для полного цикла работ с данными:

  • Evolution Managed BI для визуализации и анализа данных в облаке, в стадии public preview;

  • Evolution Managed Airflow поможет управлять рабочими процессами. Находится в стадии private preview — напишите своему аккаунт-менеджеру, чтобы начать тестирование.

Запустили в публичное превью и другие сервисы Evolution Data Platform:

  • Evolution Managed Metastore — сведения о данных для клиентских приложений;

  • Evolution Managed Trino — массивно-параллельный аналитический SQL-движок Trino;

  • Evolution Managed Redis — кеширование данных, управление очередями и работа с данными в реальном времени.

🎁 А еще до 31 декабря 2025 года дарим юрлицам 35 000 бонусных рублей на Evolution Managed Trino, Evolution Managed Metastore и Evolution Managed Spark.

🔝 С радостью делимся успехами наших клиентов:

🎙️ Провели несколько интересных вебинаров и подкастов — каждый из них вы можете посмотреть в записи: 

💳 Упростили регистрацию в реферальной программе: теперь подать заявку можно в несколько кликов, а на каждом этапе вы можете получить помощь менеджера. Присоединяйтесь к программе до 30 сентября, рекомендуйте сервисы Cloud.ru, получайте 20% от суммы их чеков в первый год и 15% — в последующие.

До скорой встречи!

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

Вопрос: оцени сколько времени займет выполнение задачи?

Оценка - это, по определению, предположение.

Так что какое число ни назови столько и будешь работать до следующего такого вопроса 😁

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

Приглашаем на Java Jam — бесплатный митап ЮMoney для Java-разработчиков

Спикеры из ЮMoney и главный эксперт по технологиям Сбера расскажут о своём опыте и пообщаются с аудиторией. Вот какие темы будут на митапе:

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

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

🟣 Уязвимости не пройдут. Обсудим, как повысить безопасность разработки с помощью SAST и SCA.

25 сентября, в четверг, в 18:30 (мск) — приходите на митап в Санкт-Петербурге или подключайтесь онлайн!

Подробности — на сайте митапа Java Jam 

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

Привет!

Рады поделиться с сообществом отличной новостью: теперь Explyt доступен для скачивания с JetBrains marketplace.

Установить Explyt 4.2 с AI агентом для написания кода, тестирования и дебаггинга можно в один клик из вашей IDE (IntelliJ IDEA 2024.1+, PyCharm 2024.1+, GoLand 2024.1+).

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

Всем отличной пятницы 🖖

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

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

Решил посмотреть курс по обучению нейросетям, и вот что я осознал:

Курсы по нейросетям - это по прежнему бизнес продающий курсы.

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

Само же обучение работе с нейросетями не требует какого-то специального обучения.

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

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

Шаги те же: выбираю задачу что хочу решить, декомпозирую(выбираю ряд маленьких шагов), делаю эти шаги сам или ставлю/делегирую задачу кому-то(человеку, гуглу, программе, сервису, нейросети), получаю и обрабатываю результат, перехожу к начальному шагу.

Скорость получения результата стала сильно выше, и инструменты новые появились, просто надо привыкнуть к таким скоростям и к таким инструментам.

В общем не надо особо чему-то новому учиться.

Просто делай то что делал до этого, только с использованием новых AI инструментов.

В своей предметной области, в своей теме, для своих задач.

Вот и всё :)

P.S. Основная польза курса как мне кажется - это история "Путь героя", которая подсвечивает варианты как это может быть и дает новую инфу(для кого-то), которая может подсветить какие-то новые инструменты. Все это есть как в платных курсах так и в свободном доступе. Ну еще автор работал над структурой. Но в жесткой структуре есть как свои плюсы, так и свои минусы.

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

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

Уже неоднократно и не только на Хабре жаловался на мелочность работодателей в объявлениях и ненужности указания всех библиотек, технологий и даже их версий. Сегодня в LinkedIn увидел предельный случай - ищут Java профессионала, который "strong in JSON,...". Факин JSON! Зa сколько учится этот формат? Секунд за 30? А если с возможностями формальной проверки на правильность содержания, то минут за 15? Зачем кто-то вообще указывает такие мелочи, как JSON, в описании требований к вакансии? И так со всем. Вместо принципиальных технологий пишут конкретные реализации и даже их версии. Зачем? Зачем?... Ничего не ответила золотая рыбка)

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

Какая должна быть длина у функций?

Щас скажу кое-что неочевидное. На эту проблему нельзя смотреть в статитке. Вот правильно 4 строки, 10, 100, поэтому разбиваем как-только доходим до предела. Я смотрю на это в динамике.

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

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

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

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

p.s. Смог тут загуглить исследование сотен миллионов строк на гитхабе: https://arxiv.org/pdf/1806.04556 (на скрине выдержка)

Больше про разработку в моем телеграм-канале Организованное программирование

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

Из сегодняшнего. Давно уже напрашивается MCP registry. Появился MCP реджистри. Не знаю, насколько аудитория погружена, поэтому если нет, то я подробнее распишу

Model Context Protocol (MCP) — это не классическое API, а новый слой взаимодействия между LLM и источниками данных: вместо того чтобы самому писать запросы, интеграции и «велосипеды», бизнес просто подключает MCP-серверы, которые находятся у провайдеров данных. Провайдер отвечает за подготовку промптов, функций, агрегацию источников и поддержку версий, а компания получает централизованный доступ к данным и готовым описаниям. Важно: MCP разводит зоны ответственности — финансы за работу LLM остаются у вас, а ответственность за качество данных и промптов несёт провайдер; таким образом, вы оптимизируете бюджеты, снижаете риски и можете гибко строить оркестрацию (через LangChain или свои пайплайны) без затрат на «ручные» интеграции с контролем версий отпровайдера

Раньше каждая команда или компания искала MCP-сервера вручную, через частные списки или разрозненные каталоги, что замедляло внедрение и поддержку клиентов. Теперь MCP Registry выступает единым «источником правды», где можно быстро находить, подключать и проверять сервера

Думаю, что ближайший год-два мы будем наблюдать, как наровне с публичными АПИ, будут появляться публичные MCP для интеграций. Что уж там, они есть уже у 1С даже, хотя там нюансы, конечно

Source

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

Привет, Хабр!

Всего две недели назад вышла версия Explyt 4.1 с поддержкой Python, MCP серверов, новыми Rules и Workflows, а уже сегодня мы рады поделиться новым релизом Explyt 4.2 с поддержкой Go. Теперь все фичи AI агента доступны в GoLand.

Важное обновление

Начиная с версии Explyt 4.2, мы вводим процедуру регистрации новых пользователей. Этот процесс займёт 30 секунд и позволит: 

  • повысить стабильность и доступность инфраструктуры из любой точки мира 

  • корректно соблюдать правовые требования 

Если вы уже пользуетесь плагином, потребуется пройти авторизацию в своём аккаунте прямо из интерфейса плагина.

Запуская бесплатный 30-дневный триал Personal версии, вы сразу получаете 4000 кредитов, которые можно использовать для запросов к LLM.

Возможность пользоваться своими моделями без регистрации в версии Community по-прежнему остается.

Скачать Explyt 4.2 можно с нашего сайта. Для багрепортов и фичриквестов - GitHub Issues и чат с командой плагина. Будем рады вашей обратной связи и философским вопросам 🖖

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

Конкурс open source проектов, которые способны изменить мир 🌏🖥️

Зовем вас на «Код без границ» — грантовую программу для развития open source проектов, которую совместно с Cloud.ru и Хабром подготовили GitVerse. Поделитесь своими разработками на GitVerse, получите шанс выиграть 💸💸💸 и получить поддержку в масштабировании идеи.

Номинации конкурса:

  • AI-инновации.

  • Наука и образование без границ.

  • Для всех и каждого (приложения и сервисы).

  • Разработка для разработчиков — инструменты и библиотеки.

Как участвовать? Рассказываем:

  1. Разместите репозиторий вашего проекта на GitVerse или импортируйте его с другой git-площадки.

  2. Подайте заявку до 31 октября. В ней должна быть ссылка на уже размещенный конкурсный проект.

  3. Подождите, пока жюри — опытные спецы из СберТеха (GitVerse), Сбера, Cloud.ru и лидеры отрасли — посмотрят работы и выберут финалистов.

  4. Узнайте результаты в декабре.

Что по призам и плюшкам?

  • Гранты 150, 100 и 50 тысяч рублей — для первого, второго и третьего места.

  • Облачные ресурсы Cloud.ru для реализации ваших масштабных идей.

  • Помощь с масштабированием проекта, поддержка экспертов и нетворкинг.

Регистрируйтесь, принимайте участие и покажите силу открытого кода 💪

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

С праздником, профессионалы!

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

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

Вклад авторов