Люди часто бросают изучение английского языка, потому что им становится скучно: исследования показывают, что мотивация падает из-за неинтересных, оторванных от жизни тем. Трудно заставить себя учить названия необычных птиц или говорить об изменении климата, если завтра нужно показывать проект клиенту или внимательно читать огромный договор.
Самый быстрый способ заговорить на языке — перестать зубрить правила и начать использовать его для конкретных задач. Попробуйте изучать английский язык, фокусируясь на темах, с которыми вы сталкиваетесь каждый день — так учеба станет не обузой, а вашим конкурентным преимуществом.
На Хабр Карьере мы собрали курсы по английскому, которые бьют точно в цель и экономят ваше время — заглядывайте:
Сейчас в очередной раз увидел новость от Антропика, что разработчики доживают свой последний год. И снова эти "эксперты" путают карту с местностью. Но у нас же с вами есть голова на плечах? Так что давайте сами и подумаем.
Типичный менеджер/аналитик - человек очень далёкий от кода и архитектуры. Да, двигает задачки, общается с бизнесом, делает красивые таблички, НО В КОДЕ НИЧЕРТА НЕ ПОНИМАЕТ. И не поймёт, даже если попросит ChatGPT объяснить. Почему? Да потому что даже если человек знает синтаксис - у него нет самого главного. Нужное мышление нарабатывается годами. Разработка это вообще не про "писать код", вот так открытие!
По какой-то необъяснимой для меня причине каждый раз упускается из вида самое главное. Рабочее приложение != "кнопочки жмутся, всё работает". Это верхушка айсберга, которую видно. Всё на самом деле сильно-сильно глубже. Все эти красивые сервисы, где ты натыкал в графе приложение и оно задеплоилось не применимы ни для одной серьезной компании. Это хорошо работает для стартапа или MVP, у которого трафик 1,5 колеки. И естественно, у человека "не из разработки" нет даже примерного понимания того, как это устроено изнутри. Чёрный ящик. Он не объяснит, почему выбрал тот или иной подход. Не заметит, что он был ошибочным. И это на проектах, в которых дай бог 2-3 сервиса, БД и nginx. Может ли такой человек довести проект до зрелого, стабильного состояния, который сможет развиваться годами? Сомневаюсь. Даже если допустить, что какой-нибудь Claude 5.7 будет в 10 раз умнее нынешнего - проблема не в этом.
Хороший инженер с хорошим инструментом может написать в 10 раз больше хорошего кода. Плохой инженер - напишет в 10 раз больше плохого кода. Пока что я не видел ни одного кейса, который мог бы опровергнуть это утверждение. Ты должен понимать, как работает твоё приложение и почему оно так работает. Это еще один скилл, который каждый разработчик приобретает годами. Это та самая "карта проекта" в голове, которая помогает тебе быстро и эффективно решать задачи. И это понимание спасает от многих проблем и ошибок, которые с ростом проекта становится нереально дорого исправлять. Даже с нейронками.
Еще свежи в памяти падения Cloudflare, AWS и десятка других сервисов. Почему? Потому что инженеры дали слишком много прав агенту, либо невнимательно проверили сгенерированный конфиг или код. НАСТОЯЩИЕ ИНЖЕНЕРЫ, КОТОРЫЕ ПОНИМАЛИ, ЧТО ДЕЛАЮТ. Лицо менеджера-вайбкодера, когда у него упал целый датацентр представили?) Сможет ли медсестра поставить диагноз с ChatGPT точнее, чем опытный врач, который использует тот же инструмент? Нет. Получается, что сам "инструмент" - не решающий фактор. Почему все сравнивают "вот я с гпт такооое могу, увольняйте всех бэкендеров"? И что, я с тем же ГПТ могу больше и быстрее.
На самом деле именно разработчики выигрывают больше всех с развитием ИИ. Сделать нормальное приложение сложнее, чем оформить табличку в аналитике. И уж явно сложнее 99% задач, которые выполняют менеджеры. Думаю Клод с этим справится на ура. Всё потихоньку движется к концепции software-инженера, который сам отвечает за аналитику, сроки выполнения и разработку. Ну и конечно же акцент больше сместится на проектирование архитектуры. Мы просто будем тратить меньше времени на код. И этот подход будет в десятки раз эффективнее любого "менеджера-аналитика-вайбкодера".
Сейчас в очередной раз увидел новость от Антропика, что разработчики доживают свой последний год. И снова эти "эксперты" путают карту с местностью. Но у нас же с вами есть голова на плечах? Так что давайте сами и подумаем.
Типичный менеджер/аналитик - человек очень далёкий от кода и архитектуры. Да, двигает задачки, общается с бизнесом, делает красивые таблички, НО В КОДЕ НИЧЕРТА НЕ ПОНИМАЕТ. И не поймёт, даже если попросит ChatGPT объяснить. Почему? Да потому что даже если человек знает синтаксис - у него нет самого главного. Нужное мышление нарабатывается годами. Разработка это вообще не про "писать код", вот так открытие!
По какой-то необъяснимой для меня причине каждый раз упускается из вида самое главное. Рабочее приложение != "кнопочки жмутся, всё работает". Это верхушка айсберга, которую видно. Всё на самом деле сильно-сильно глубже. Все эти красивые сервисы, где ты натыкал в графе приложение и оно задеплоилось не применимы ни для одной серьезной компании. Это хорошо работает для стартапа или MVP, у которого трафик 1,5 колеки. И естественно, у человека "не из разработки" нет даже примерного понимания того, как это устроено изнутри. Чёрный ящик. Он не объяснит, почему выбрал тот или иной подход. Не заметит, что он был ошибочным. И это на проектах, в которых дай бог 2-3 сервиса, БД и nginx. Может ли такой человек довести проект до зрелого, стабильного состояния, который сможет развиваться годами? Сомневаюсь. Даже если допустить, что какой-нибудь Claude 5.7 будет в 10 раз умнее нынешнего - проблема не в этом.
Хороший инженер с хорошим инструментом может написать в 10 раз больше хорошего кода. Плохой инженер - напишет в 10 раз больше плохого кода. Пока что я не видел ни одного кейса, который мог бы опровергнуть это утверждение. Ты должен понимать, как работает твоё приложение и почему оно так работает. Это еще один скилл, который каждый разработчик приобретает годами. Это та самая "карта проекта" в голове, которая помогает тебе быстро и эффективно решать задачи. И это понимание спасает от многих проблем и ошибок, которые с ростом проекта становится нереально дорого исправлять. Даже с нейронками.
Еще свежи в памяти падения Cloudflare, AWS и десятка других сервисов. Почему? Потому что инженеры дали слишком много прав агенту, либо невнимательно проверили сгенерированный конфиг или код. НАСТОЯЩИЕ ИНЖЕНЕРЫ, КОТОРЫЕ ПОНИМАЛИ, ЧТО ДЕЛАЮТ. Лицо менеджера-вайбкодера, когда у него упал целый датацентр представили?) Сможет ли медсестра поставить диагноз с ChatGPT точнее, чем опытный врач, который использует тот же инструмент? Нет. Получается, что сам "инструмент" - не решающий фактор. Почему все сравнивают "вот я с гпт такооое могу, увольняйте всех бэкендеров"? И что, я с тем же ГПТ могу больше и быстрее.
На самом деле именно разработчики выигрывают больше всех с развитием ИИ. Сделать нормальное приложение сложнее, чем оформить табличку в аналитике. И уж явно сложнее 99% задач, которые выполняют менеджеры. Думаю Клод с этим справится на ура. Всё потихоньку движется к концепции software-инженера, который сам отвечает за аналитику, сроки выполнения и разработку. Ну и конечно же акцент больше сместится на проектирование архитектуры. Мы просто будем тратить меньше времени на код. И этот подход будет в десятки раз эффективнее любого "менеджера-аналитика-вайбкодера".
В Python атрибуты классов по-умолчанию хранятся в специальном dunder-атрибуте __dict__. В описании класса его задавать не надо, он есть неявно и доступен для просмотра при необходимости. Каждый экземпляр класса также имеет свой __dict__:
class Standard:
def __init__(self, x, y):
self.x = x
self.y = y
std = Standard(100, 200)
std.__dict__ # {'x': 100, 'y': 200}
Помимо того, что и класс и экземпляры отдельно занимают своими __dict__ место в памяти, хранение данных в словарях само по себе несет большие накладные расходы. Хеш-таблица в основе словаря хранит служебные структуры и растёт скачками при увеличении числа атрибутов, поэтому на больших количествах объектов затраты памяти ощутимы:
Один из эффективных способов сэкономить память, это реализовать в классе специальный атрибут __slots__ и объявить в нем последовательность атрибутов экземпляра. Тогда вместо __dict__, Python будет использовать альтернативную структуру хранения атрибутов с помощью дескрипторов. __slots__ для экземпляров классов отдельно не создается и хранится только на уровне класса:
class Slot:
__slots__ = ('x', 'y') # Неизменный кортеж из имен атрибутов
def __init__(self, x, y): # Остальное – без изменений
self.x = x
self.y = y
slt = Slot(100, 200)
slt.__dict__ # **AttributeError**: 'Slot' object has no attribute '__dict__'. Did you mean: '__dir__'?
slt_size = getsizeof(slt)
slt_size # 48 байтов
Так добавив одну строчку кода, можно сэкономить расходы памяти в приложении, где требуется создавать миллионы одинаковых объектов.
--- Важные ограничения
Стоит отметить, что реализация __slots__ запрещает динамически добавлять экземпляру класса атрибуты, в отличие от __dict__. В ситуациях, где такое необходимо, __slots__ не подойдет.
std.z = 300
std.__dict__ # {'x': 100, 'y': 200, 'z': 300}
slt.z = 300 # **AttributeError**: 'Slot' object has no attribute 'z' and no __dict__ for setting new attributes
Важно, не забывать расширять слоты, если мы добавляем в код класса новые атрибуты:
class PartialSlots:
__slots__ = ('x', 'y') # Не добавили атрибут экземпляра 'z'
def __init__(self, x, y, z):
self.x = x
self.y = y
self.z = z
p = PartialSlots(100, 200, 300) # **AttributeError**: 'PartialSlots' object has no attribute 'z' and no __dict__ for setting new attributes
В подклассах от класса со __slots__ наследование этого атрибута проходит лишь частично. Для полноценного использования, его стоит определить еще раз, включив новые атрибуты подкласса:
# Подкласс без доп. логики
class InheritSlot(Slot):
pass
inh_slt = InheritSlot(100, 200)
inh_slt.__dict__ # {}, атрибут снова доступен
inh_slt.z = 300 # Нет ошибок при динамическом расширении атрибутов
inh_slt.__dict__ # {'z': 300}, словарь подкласса снова занимает память
# Поправим
class InheritSlot(Slot):
__slots__ = ('z', ) # Слоты суперкласса добавятся в начало кортежа. В конце не забываем запятую, так как это кортеж из одного элемента.
inh_slt2 = InheritSlot(100, 200, 300)
inh_slt2.__dict__ # AttributeError ... теперь слоты используются корректно в подклассе
Недавно общался с крупной зарубежной продуктовой компанией. Штат 500–1000 человек, вроде зрелые процессы, ЗП у разрабов 5000€ баг-репорты по ISO/IEC/IEEE 29119. И при этом:
«Не успеваем уделять время автотестам. Сфокусированы на скорости разработки и релизах.»
Что меня зацепило — каждый их аргумент против тестов я интерпретировал как аргумент за:
— «Слишком частые релизы» → А не потому ли они такие частые, что баги проскакивают на прод?
— «Требования постоянно меняются» → Тем более — как вы контролируете, что старое не ломается?
— «И так работают наизнос если еще и тесты заставить писать — выгорят» → А не от бесконечного ли футбола с багами они выгорают?
А как у вас? Есть автотесты на проекте? Или тоже «не до них»?
Главная задача продакт-менеджера — создать востребованный продукт с минимальными рисками и затратами. А чтобы делать это эффективно, необходимо владеть методологиями управления: они помогают структурировать работу, быстрее проверять гипотезы и доводить идеи до реализации.
Собрали для вас основные фреймворки, которые очень выручают в работе. А чтобы не просто о них знать, но и уметь применять на практике — нашли крутые учебные программы по каждому из них. Заглядывайте на Хабр Карьеру, там много полезностей:
— CustDev. Проверяем гипотезы через опросы клиентов.
— JTBD. Анализируем, какую задачу пользователя решает продукт.
— Lean. Минимальными усилиями создаем продукт и проверяем гипотезы.
— Agile. Учимся быстро адаптироваться к изменениям.
— Scrum. Выстраиваем работу короткими, но эффективными спринтами.
— Kanban. Визуализируем задачи на доске для контроля загрузки.
Не пойму — чего за кипишь? Или почему ИИ — это просто новый «питон»
Последнее время из каждого утюга кричат: «ИИ заменит программистов!», «Джуны больше не нужны!», «Учитесь на сантехников, пока не поздно!».
Давайте выдохнем, отставим смузи и разберемся по-простому, «на пальцах», что вообще происходит.
1. Программист — это не «печатающая машинка»
Главная ошибка паникеров в том, что они путают набор текста с программированием. Если ваша работа заключалась в том, чтобы копипастить методы из Stack Overflow и менять там названия переменных — да, у меня для вас плохие новости. ChatGPT делает это быстрее и без обеденного перерыва.
Но программист — это не тот, кто знает, где поставить точку с запятой. Программист — это переводчик. Мы переводим смутные человеческие «хотелки» на жесткий язык логики, понятный машине.
2. Эволюция «костылей»
Вспомните историю. Раньше писали на перфокартах. Потом на Ассемблере. Потом на Си, потом на Питоне. Каждый раз кричали: «Ну всё, теперь порог входа стал таким низким, что программисты не нужны!». И что? Программистов стало только больше. Просто мы перестали думать о том, в какой регистр положить байт, и начали думать о том, как построить архитектуру сервиса.
ИИ — это просто следующий уровень абстракции. Это новый «язык программирования», где вместо скобочек мы используем новый язык -конструктычистого смысла
3. Проблема «идеального мусора»
ИИ — это зеркало вашего мышления. Если вы дадите нейронке кривое, логически дырявое задание — она выдаст вам идеально написанный, быстрый, оптимизированный... мусор. Чтобы управлять ИИ, вам нужно иметь в голове структуру еще более четкую, чем раньше. Теперь цена ошибки в логике выросла. Если раньше вы ошибались в синтаксисе — программа не заводилась. Теперь она заведется, но уедет не туда.
4. ИТ-поликлиника
Представьте, что в больнице появился робот-санитар, который идеально моет полы и делает уколы. Означает ли это, что врачи-хирурги или диагносты больше не нужны? Наоборот! Теперь им не нужно отвлекаться на мытье полов.
А кого вообще не заденет? (Спойлер: Работы будет завались)
Если вы думаете, что ИИ — это такой терминатор, который выкосит всё ИТ-отделение, то вы плохо представляете, как устроена реальная «цифровая больница». Есть куча специализаций, где человеческий фактор — это не баг, а фича.
Архитекторы сложных систем (System Architects): ИИ может нарисовать типовой домик. Но построить небоскрёб на болоте, учитывая старое «дырявое» железо, бюджет заказчика и планы на 10 лет вперёд... ИИ не видит контекста «выживания» системы, он видит только код.
Инженеры кибербезопасности (SecOps): Тут идёт вечная война хитрости. ИИ может искать паттерны, но он не может предугадать нестандартный «выверт» хакера-человека. Безопасность — это интуиция и паранойя, а у нейронок с этим туго. Гы)))
SRE и DevOps (Те, кто спасают сервера в 3 часа ночи): Когда у системы «инфаркт», данные текут, а клиенты кричат — нужен человек с железными нервами, который примет решение «резать или шить». ИИ в критической ситуации может просто выдать ошибку 404, потому что такого случая не было в его обучающей выборке.
Бизнес-аналитики и «Психотерапевты заказчика»: Это те, кто переводят с «бреда руководства» на человеческий. ИИ никогда не поймет, почему директор хочет «кнопку как у конкурентов, но чтобы она была синей, но красной».
Процессные аналитики (BPM): Они рисуют, как ходят бумажки и данные между отделами. ИИ учтёт, что бухгалтер Марья Ивановна просто не отдаст отчёт вовремя, потому что обижена на айтишников?
Итог
Ребята, расслабьтесь. Программирование не умирает, оно взрослеет. Уходит эпоха «кодинга ради кодинга». Наступает эпоха Качества Мышления. Теперь важно не то, насколько быстро ты стучишь по клавишам, а то, насколько структурированно ты умеешь формулировать смыслы.
ИИ — это просто наш новый, очень мощный экзоскелет. Но куда в нем идти и зачем — решать всё равно вам.
Так что идите пить чай, делайте зарядку для мозгов и учитесь формулировать. Это единственный навык, который у вас никто не отберет.
Хорошей практикой в C++ считается размещение функций рядом с типами, для которых они предназначены. Однако, чтобы такой подход работал корректно, важно понимать механизмы поиска имён и знать, где можно размещать функции, не нарушая правил языка.
Совсем недавно мы проверяли проект OpenCV и нашли там довольно интересную ошибку. Рассмотрели её подробнее и написали новую статью специально для тех, кто хочет разобраться с механизмом поиска имён в C++, в частности с поиском имён по аргументам.
Практический Тренажер по Java — самый популярный тренажер по Java на Stepik
В 2024 году я опубликовал курс «Практический Тренажер по Java» на платформе Stepik. Тогда это был просто практический курс с задачами — без воды, без длинной теории, только код и постоянная тренировка.
Прошло несколько лет.
Сегодня курс проходит более 19 000 учеников, и это самый популярный тренажёр по языку Java на платформе Stepik.
Курс продолжает активно развиваться, регулярно пополняется новыми задачами, а вокруг него сформировалось живое и активное сообщество.
И я хочу заново пригласить вас в этот проект.
Почему Java?
Java — один из самых востребованных языков программирования в мире.
Он используется в:
— веб-разработке
— мобильной разработке (Android)
— корпоративных системах
— финансовых сервисах
— высоконагруженных backend-проектах
Java — это стабильность, масштабируемость и высокий спрос на рынке труда.
Что представляет собой курс сегодня?
Это полностью практический формат обучения. Только задачи и реальная практика.
Многие ученики используют тренажер как системную подготовку к техническим интервью. Такой формат не просто помогает решать задачи, а выстраивает алгоритмическое мышление, формирует уверенность в собственном коде и укрепляет уверенность в своих силах и уровне владения Java.
Особенность Joomla: json-значения для пользовательских полей и их рендер в subform и вне дочерней формы.
Опять длинное название, но куда уж без этого...
Итак, если вы делаете плагин пользовательского поля - его можно использовать через FieldsHelper. И в процессе ваши данные проходят через различные этапы обработки (недавно была статья на эту тему). И может так оказаться, что ваше поле хранит в rawvalue json (и в базе данных соответственно тоже), а в value вы на его основе рендерите значение. Это стандартный подход Joomla. Так работают, например, поля accessiblemedia. Однако, если вы поместили ваше поле в дочернюю форму (пользовательское поле типа subform и включили "Рендеринг значений = Да", то у вашего замечательного поля может появиться поломанный Json в value вместо нормального значения.
Продолжаю писать серию коротких постов про историю айти. В последнее время нам очень интересна тема нашего наследия и почитывая разные источники, я пишу об этом коротко и простым языком.
Apache Kafka, Apache Spark, Apache Hadoop, Apache Nifi, Apache Iceberg… сколько ещё «Apache-чего-то» мы знаем? Это не бренд-линейка и не одна компания, а следствие того, что в середине 90-х несколько инженеров собрали процесс, который умеет бесконечно выпускать инфраструктурные проекты.
В начале веба одним из главных серверов был NCSA httpd, написанный при Университете Иллинойса и быстро ставший популярным. Однако в момент поддержка затормозилась из-за банального увольнения сотрудника. Тем временем интернет рос, а с ним нагрузка и требования, поэтому команды выкручивались так, как некоторые живут до сих пор: брали исходники и накладывали поверх свои маленькие исправления, которые инженеры пересылали друг другу по почте. Пришло все к тому, что у всех был один и тот же сервер, но собранный из разных заплаток и никто не был уверен, у кого версия “правильная”.
В 1995-м несколько людей, которым это надоело, решили начать собирать улучшения вместе, превращая россыпь патчей в единый, поддерживаемый продукт. Так появился ранний Apache HTTP Server. Брайан Белендорф (один из основателей) утверждает, что предложил название Apache из уважения к индейскому племени апачей за их выносливость и тактическое мастерство. Позже кто-то из команды заметил, что это звучит как «a patchy server» с дословным переводом - “сервер из заплаток”. Шутка всем понравилась и она стала частью фольклора.
Позже основатели поняли, что ценность не только в самом сервере, а в том, как они его делают - открыто, через обсуждения и самое важное, через идею, что комьюнити важнее кода. Когда Apache HTTP Server стал критически важным для отрасли, в 1999 году оформили Apache Software Foundation как некоммерческую организацию, которая даёт проектам юридическую оболочку, инфраструктуру и стандарты управления, чтобы они не зависели от одного автора. Так Apache стала не «серия продуктов», а фабрикой зрелых open-source проектов.
Фонд НЕ пишет Kafka или Spark “в офисе”, он предоставляет правила и среду, в которой разные команды могут запускать и развивать проекты. Сделано это для того, чтобы ими можно было пользоваться в продакшене десятилетиями, а не пока стартап не продался. В мире Apache считается, что если у проекта крутой код, но нет живого сообщества - значит проект мертв. Именно поэтому у них такая жесткая процедура приема проектов, где проверяют не столько строчки кода, сколько то, умеют ли люди договариваться. На сегодняшний день под крылом Apache находится более 350 проектов.
Apache стал Apache потому что когда-то люди устали жить на локальных костылях и сделали общий проект из “заплаток”. Превратили этот опыт в организацию, которая умеет масштабировать не код, а сотрудничество. Поэтому сегодня ты видишь одно слово в названии у сотен инструментов. Это метка зрелости процесса и того, что проект построен так, чтобы пережить своих создателей и остаться в проде, где ему и место.
Подписывайтесь на наш Telegram-каналИнженеркаТех. Там мы публикуем полезные подборки от инженеров и делимся инсайтами.
В первой части я рассказал про концепт проактивного AI-агента и показал примеры сообщений, которые он мог бы присылать. Последние 3 дня я занимался реализацией — и сегодня пришло первое сообщение от него
За основу я взял популярный OpenClaw, но захотел переписать бота по-своему и разобраться с тем, как живёт и думает эта сущность
Архитектура: из чего состоят подобные OpenClaw агенты
Heartbeat — сердце агента
Это цикл, который раз в N минут триггерит основные события, проверки и запускает переписывание файлов, если нужно
«Проснись, посмотри, что изменилось, подумай, что предложить пользователю».
Memory — память агента
Нужно было спроектировать аналог краткосрочной и долгосрочной памяти, примерно как у людей.
Краткосрочная — контекст текущей сессии, что происходило сегодня, какие задачи обсуждали, что пользователь ответил. Долгосрочная — в случае OpenClaw это SQLite с механизмом эмбеддингов. Ну можно поставить любую другую векторную бд
Плюс есть еще такие файлы как Soul, Agents, Identity, User, Memory и еще несколько. Все они сразу попадают в Context Window
Без разделения на два типа памяти агент либо забывает всё на следующий день, либо тонет в контексте и начинает галлюцинировать.
Memory Compaction — сжатие памяти
В OpenClaw агент хранит часть контекста в файлах формата MEMORY_MM_DD_YYYY с историей каждого дня.
По прошествию нескольких дней агент делает Compact этих файлов и удаляет / архзивирует их исходники
Context Routing — маршрутизация контекста
Как и чем нужно заполнять контекст на протяжении времени? Как его сжимать?
Контекстное окно — ресурс ограниченный. Нельзя каждый раз загружать все цели, всю память, все задачи. Нужно выбирать: что релевантно сейчас, что можно опустить, что критично.
Context routing решает, какие куски информации попадут в промпт для конкретного цикла работы агента.
Prompt Assembly — сборка промпта
Как структурировать промпт? Какая информация в нём приоритетнее, а что можно поджать? Как выбираются цели на конкретный день?
Это отдельная инженерная задача. Промпт агента — не статичный текст. Он собирается динамически из кусков: текущие цели, релевантная память, задачи из таск-трекера, контекст дня недели и времени.
---------------
Что я добавил к исходному варианту OpenClaw от себя
Reflection — самооценка агента
Экспериментальный блок, где модель оценивает сама себя по 4 шкалам:
Actionability — дал ли конкретные шаги?
Relevance — был ли совет по теме цели?
Novelty — сказал ли что-то новое?
Overall quality — общее качество
Зачем это нужно: без обратной связи агент быстро скатывается в банальности типа «Не забудь поработать над своими целями!». Reflection заставляет его критически оценивать свой же output и со временем улучшать качество предложений.
К чему он у меня подключен
TickTick — мой таск-трекер, откуда бот смотрит задачи и ставит новые
Telegram — сюда он мне пишет и предлагает задачку на сегодня
Discord — самый лучший по функционалу на сегодня
----------------
Что я понял в процессе
Создание проактивного агента — это совсем другой уровень сложности по сравнению с обычным чат-ботом.
В чат-боте пользователь задаёт вопрос → получает ответ. Всё. Контекст понятен из вопроса.
В проактивном агенте нужно решить кучу вопросов, которые в чат-боте просто не возникают: когда писать, о чём писать, как не повторяться, как не раздражать, как понять, что задача уже неактуальна, как сжимать память, чтобы не выжирать токены.
Это, по сути, проектирование UX для системы, у которой нет интерфейса в привычном смысле — только текст в мессенджере.
Вот такие промежуточные итоги — получилось хоть немного разобраться в возможном механизме оркестрации под капотом агента
Если где то нашли неточность, то пинганите в комментах
В третей части напишу подробнее про OpenClaw, так как пока решил его потестировать
Статический анализ генерируемой OpenApi-разметки и .NET 10
Привет, Хабр! 👋 На связи Саша Кузнецов, ведущий инженер-программист в Контуре.
Начиная с версии .NET 10 Microsoft решила поломать обратную совместимость в отношении статических анализаторов генерируемой OpenApi-разметки.
[HttpGet("{id}")]
[ProducesResponseType<User>(StatusCodes.Status200OK)]
[ProducesResponseType(StatusCodes.Status404NotFound)]
public async Task<IActionResult> GetUser(int id)
{
var user = users.FirstOrDefault(p => p.Id == id);
if (user == null)
return NotFound();
return Ok(user);
}
Раньше можно было возвращать IActionResult, или ActionResult, размечая типы ответов специальными атрибутами типа ProducesResponseType (см. код 1). Это позволяло включить потом статический анализатор добавлением в настройки проекта специального атрибута IncludeOpenAPIAnalyzers (см. код 2) и получать предупреждения на этапе компиляции, или статического анализа кода (см. код 3).
[HttpGet("{id}")]
public async Task<Results<Ok<User>, NotFound>> GetUser(int id)
{
var user = users.FirstOrDefault(p => p.Id == id);
if (user == null)
return TypedResults.NotFound();
return TypedResults.Ok(user);
}
Сама тенденция не сильно радует. В старых проектах IActionResult и ActionResult (их пока не объявили устаревшими, но без статического анализа ошибок разметки они начнут терять привлекательность) используются много где.
Привет, Хабр. Делимся подборкой бесплатных уроков, которые скоро пройдут в Otus. Опытные практики проведут занятия онлайн — вы сможете узнать больше о формате обучения и задать вопросы экспертам. Выбирайте свою тему и присоединяйтесь.
10 марта 20:00. «Мультитенантная архитектура в Laravel: как масштабировать проекты под десятки и сотни клиентов». Записаться Открытый вебинар курса «Framework Laravel»
Применяем кодогенерацию в Java для решения алгоритмических задач
В прошлый раз мы разобрались, как решается задача трансляции деревьев. И остановились на том, что в случае с AST от компилятора TypeScript, придётся руками обрабатывать 263 типов узлов. Тысячи строк однотипного boilerplate-кода: приведения типов, аннотации, объявления методов — всё это нужно не просто написать, но ещё и поддерживать. А если требования к архитектуре поменяются — переписывать заново.
Однако в случае с Java у нас есть способ упростить себе жизнь — кодогенерация. Нет, не та, что при помощи ИИ-агентов, хотя это мы тоже затронем. Вместо тысяч строк Java кода можно использовать лаконичный конфиг, в котором описывается соответствие узлов и их связи, а всю рутину берёт на себя генератор. Изоморфные преобразования, декомпозиция — всё это описывается там.
Как реализовать это с помощью JavaPoet, что умеет эта библиотека, а также как встроить в процесс нормализацию можно узнать в новом материале, посвящённом использованию кодогенерации для трансляции деревьев.
Без опытного взгляда со стороны обучение превращается в исправление одних и тех же ошибок. В такие моменты нужен толковый наставник — тот, кто за десять минут объяснит то, до чего сам будешь доходить неделями.
Именно поэтому на Хабр Карьере мы собираем учебные программы с опытными менторами — они помогают видеть прогресс и не бояться багов. Если хотите стать разработчиком, но сомневаетесь в своих силах, то присмотритесь к нашей витрине курсов — с наставником становиться профессионалом проще и интереснее.
А сегодня мы собрали подборку ключевых инструментов, которые вам предстоит освоить, чтобы стать Java-разработчиком:
— Spring Boot. Фреймворк для сборки микросервисов и веб-приложений с минимальными настройками.
— Docker. Упаковка приложения с их зависимостями в изолированные контейнеры.
Добавил поддержку типов System.UInt128 и System.Int128 в основную web3-библиотеку для шарпистов/дотнетчиков,— Nethereum. Уже ушло в master, так что если активно используете Nethereum для работы с протоколами, где широко представлены 128-битные типы в событиях/параметрах/результатах вызова функции и страдаете от избыточного потребления памяти BigInteger, то можно уже переключаться на версию из master (для сборки необходим nuget.exe). Особенно это актуально для AAVE, Balancer и Velodrome/Aerodrome (в последних не забывайте использовать packed-кодирование при работе с роутером).
Сейчас обсуждаем с мейнтейнером Хуаном Бланко повышение производительности и снижение потребления памяти при кодировании/декодировании целых чисел в Nethereum, после чего я подготовлю ещё один Pull Request с реализацией и ориентировочно всё эти изменения войдут в следующий релиз.
Если есть идеи, что ещё можно было бы сделать/улучшить, присоединяйтесь к обсуждению в Discord проекта (на английском/испанском) или в issues в репозитории на github.
OpenAPI Generator через призму статического анализатора
Знаете ли вы про OpenAPI Generator — open source проект, задача которого — автоматическая генерация клиентских библиотек, серверных заглушек, документации и файлов конфигурации на основе спецификации OpenAPI в формате JSON или YAML. Проект является достаточно популярным: у него чуть больше 25000 звёзд на GitHub.
В верификации нельзя стать сеньором просто по стажу или количеству закрытых задач. Каждый следующий уровень — это новая ответственность: за блок, подсистему, качество покрытия, сроки и иногда за других людей.
Алексей Ковалов, руководитель отдела модульной верификации YADRO, в статье рассказал, как на практике происходит рост от джуна до сеньора. И начинается все с базовых вещей. Команда Алексея использует принцип «15–45»: 15 минут попробуй разобраться сам, но если за 45 не сдвинулся — иди к ментору. Самостоятельность важна, но умение вовремя эскалировать проблему — это уже признак зрелости.
Внутри статьи:
почему «вечный мидл» — это не миф, а распространенный сценарий,
как меняется тип задач при переходе между грейдами,
что важнее для сеньора: глубина экспертизы или широта инструментария,
как не утонуть в покрытии и научиться оценивать объем работы заранее.
Если откликается описанный подход к росту, сейчас хороший момент присоединиться к команде YADRO. Мы открыли Sprint Offer для RTL- и UVM-инженеров. Подать заявку можно до 22 февраля.
Инженеры занимаются fabless-разработкой микропроцессоров на базе RISC-V — полным циклом от собственного процессорного IP до системного ПО. Работают с IP, SoC, беспроводными системами и высоконагруженными архитектурами.
