Привет! Меня зовут Михаил Боровиков, я тимлид команды, которая отвечает за систему процессинга заказов Lamoda — Orders Management. Эта система, словно «сердце» Lamoda, через которое проходит самый важный для бизнеса шаг — оформление заказа.

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

Для решения этой проблемы мы выбрали паттерн Outbox. И в этой статье я расскажу, что он из себя представляет, как мы его применили, почему пошли по пути at-least-once и не положились на работу одного брокера сообщений.

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

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

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

В этой статье мы исследуем эволюцию подходов к AI-разработке - от такого подхода как Vibe Coding к системной методологии AI Software Engineering (AI SWE), которая позволяет превратить AI-агентов в управляемый инструмент для создания больших и сложных систем.

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

Продолжаем анализировать паттерны проектирования промтов агентов из репозитория https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools и после разбора XML-тегов в первой части переходим к следующему ключевому элементу.

Привет, Хабр! Меня зовут Глеб, я Java-разработчик в Сбере. Сегодня я хочу рассказать про исторический контекст двух фундаментальных подходов к системе типов в программировании.

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

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

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

В конце лета 1955 года в колледже Дартмут под руководством доцента кафедры математики Джона МакКарти состоялся семинар, посвященный вопросам искусственного интеллекта. Результатом этого семинара стал запрос на проведение исследовательского проекта.

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

Это было начало истории появления языка Lisp.

Я стал большим сторонником DynamoDB за последние несколько лет. Эта база данных имеет много сильных сторон, которых нет у конкурентов, таких как гибкая ценовая модель, соединение без состояния (stateless), которое прекрасно работает для беcсерверных (serverless) вычислений, и постоянное время ответа, даже когда ваша база данных масштабируется до огромных размеров.

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

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

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

gRPC – высокопроизводительный и мощный инструмент для построения микросервисных систем.

Криптохомячкам посвящается ...

Алгоритм Гровера представляет собой обобщённый, независящей от конкретной задачи поиск, функция которого представляет "чёрный ящик" f: {0,1}^n to {0,1}^n, для которой известно, что EXISTS!w:f(w)=a, где a — заданное значение.

Считаем, что для f и заданного a можно построить оракул Uf: { |w> to |1>, |x> to |0> if |x> != |w> }

Алгоритм Гровера достаточно прост

1. Задаём в регистре (массиве кубитов) начальное значение H|0>
2. Повторяем несколько раз (исходя из оценки) пару трансформаций над регистром
   
   • Отражение от решения Uw: { |w> to -|w>, |x> to |x> if |x> != |w> } или Uw = I-2|w><w|
   • Отражение от s=H|0> Us = 2|s><s|-I
3. Забираем нужное решение из регистра (с большой долей вероятности, что оно правильное)

Применим этот алгоритм для решения задачи нахождения ключа шифра Цезаря ...

При начале разработки нового проекта у моей команды всегда появлялся вопрос, какую библиотеку выбрать для межсервисного взаимодействия? А какую использовать для походов в сторонние сервисы? В этой статье я постарался вкратце осветить различные обёртки над HttpClient.

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

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

Мы в свое время настроили удаленный формат и работаем так уже почти семь лет. Продолжаем допиливать детали, но в общих чертах можем отчитаться о том, что “контроль без контроля” действительно работает. В этой статье рассказываем, как он устроен.

Мы в компании активно используем low-code платформы много лет. За время работы набрался опыт в преодолении проблем, связанных с этими платформами, и кристаллизовались подходы, которые хорошо себя показали.

В статье я разберу, что в low-code подходе помогает бизнесу, а что создаёт сложности. При рассмотрении проблем я предложу «лекарства», которые помогут вам нивелировать проблемы.

В конце статьи я составил чек-лист, по которому рекомендую проверять low-code платформу, прежде чем вы решитесь использовать её для решения своих бизнес-задач.

Статья состоит из шести разделов:

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

Однако в 1969 году всё приняло не стандартный оборот: в прямом эфире по указу президента Ричарда Никсона была проведена лотерея, в которой победители получали не денежный чек, а возможный билет во Вьетнам.

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

Несколько лет назад я написал в Twitter/X заметку о лучшем программисте, которого я знаю, её стоит переписать в виде поста в блоге. Мне кажется справедливым, чтобы я рассказал и о самом плохом. Его зовут Тим Маккиннон. Я хочу, чтобы мир знал, насколько он измеряемо непродуктивен.

Продолжаем наш ретроспективный цикл о тех советских разработках, которые стали историей и за которые, как принято говорить — “не стыдно”. В предыдущих постах цикла мы уже затрагивали разработку языков программирования в СССР и в этом посте хотели остановиться на ней подробнее. Несмотря на достаточно скромные достижения в этой области, разработчики языков и трансляторов знали моменты триумфа, а фундаментальный вклад советских ученых в развитие программирования ощутим и сегодня. Под катом немного о языках и трансляторах, разработанных в Стране Советов в 50-е — 60-е годы, а также об их создателях. 

Импортозамещение в ИТ, локальный российский тренд последних лет. На протяжении последнего года — это слово многократно звучало из каждого “утюга”. Причины — крупные западные вендоры, в силу геополитических причин, ушли из России. Это болезненно отразилось на промышленности и крупных компаниях, они потеряли доступ к покупке лицензий, поддержке, обновлениям ect. Больно терять ERP, DSS, цифровая трансформация промышленности и бизнеса в России, очевидно, замедлится. Распространено мнение, что опыт цифровой трансформации и автоматизации, а также разработка систем управления процессами предприятий начались в России в девяностые, а 1С, Галактика и Монолит выросли на ровном месте, но это не совсем так...