Сегодня я к вам с новым практическим проектом на Python. На этот раз мы создадим полноценного Telegram-бота для продажи цифровых товаров с базой данных, которой будем управлять через SQLAlchemy 2, админ-панелью, пользовательской частью и интегрированной оплатой через Юкассу.

Я шаг за шагом проведу вас через все этапы разработки такого бота: начиная от регистрации токена в BotFather и заканчивая деплоем готового продукта на удаленном хостинге, чтобы бот мог бесперебойно работать 24/7 без привязки к вашему компьютеру или интернет-соединению.

— Не понимаю, почему люди так восхищаются этим Карузо? Косноязычен, гугнив, поёт — ничего не разберешь!
— А вы слышали, как поёт Карузо?
— Да, мне тут кое-что из его репертуара Рабинович напел по телефону.

Детектив по материалам IT. Часть первая

Я осознаю, что писать очередную статью на тему Модель-Вид-Контроллер это глупо и вредно для «кармы». Однако с этим «паттерном» у меня слишком личные отношения – проваленный проект, полгода жизни и тяжелой работы «в корзину».

Проект мы переписали, уже без MVC, просто руководствуясь принципами – код перестал быть похож на клубок спагетти и сократился наполовину (об этом позже, в обещанной статье про то, как мы применяли «принципы» в своем проекте). Но хотелось понять, что же мы сделали не так, в чем была ошибка? И в течении долгого времени изучалось все, что содержало аббревиатуру MVC. До тех пор пока не встретились исходные работы от создателя – Трюгве Реенскауга…

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

Более 30 лет собранные в MVC идеи и решения остаются наиболее значимыми для разработки пользовательских интерфейсов. Но как ни странно, несмотря на существующую путаницу и обилие противоречивых трактовок, разработчики продолжают довольствоваться информацией «из вторых рук», черпая знания о MVC из википедии, небольших статей в интернете и фреймворков для разработки веб-приложений. Самые «продвинутые» читают Мартина Фаулера. И почему-то почти никто не обращается к первоисточникам. Вот этот пробел и хотелось бы заполнить. И заодно развеять некоторые мифы.

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

План лекции:

1. Виды и области применения рекомендательных систем.
2. Простейшие алгоритмы.
3. Введение в линейную алгебру.
4. Алгоритм SVD.
5. Измерение качества рекомендаций.
6. Направление развития.

Привет, Хабр! Меня зовут Никита Кулин, ML-Engineer NLP моделей.

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

Это мой первый пост, поэтому буду рад любой обратной связи!

Итак, в прошлой статье я уже немного рассказывал о том, что с LLM можно работать и даже построить определенный RAG. Как и обещал, перейдем к практике! :)

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

В прошлом году мы уже рассказывали, как создавали нашего помощника программиста Kodify. Не прошло и года, и мы представили вам новую его версию — Kodify 2. А буквально сегодня объявили о выпуске опенсорсной — Kodify Nano. Kodify 2 доступен только для корпоративных заказчиков, а Kodify Nano мы сделали открытым — выложили на Hugging Face.

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

Исследователи из HiddenLayer представили универсальную технику инъекции промтов, которая успешно обходит защитные механизмы ключевых современных ИИ‑моделей. Это касается систем OpenAI (ChatGPT-4o, 4o‑mini, 4.1, 4.5, o3-mini, o1), Google (Gemini-1.5, 2.0, 2.5), Microsoft (Copilot), Anthropic (Claude-3.5, 3.7), Meta✶ (семейства Llama-3✶ и 4), DeepSeek (V3, R1), Qwen (2.5-72B) и Mistral (Mixtral-8x22B).

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

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

Меня зовут Наталья Азисова, я product owner клиринговой системы в ПС «Мир». Каждое утро вторника я думаю о том, какой суперсрочной задачей нагрузить разработку, а к вечеру — как отложить её на пару месяцев. Спасает меня от праведного гнева разработки только то, что делаю я это со стилем.

Итак, что такое клиринг, как он работает и реализован на примере платежной системы «Мир» - читайте под катом.

Долгое время считалось, что классический метод аутентификации, основанный на комбинации логина и пароля, весьма надёжен. Однако сейчас утверждать такое уже не представляется возможным. Всё дело — в человеческом факторе и наличии у злоумышленников больших возможностей по «угону» пароля. Не секрет, что люди редко используют сложные пароли, не говоря уже о том, чтобы регулярно их менять. К сожалению, является типичной ситуация, когда для различных сервисов и ресурсов применяется один и тот же пароль. Таким образом, если последний будет подобран посредством брутфорса или украден с помощью фишинговой атаки, то у злоумышленника появится доступ ко всем ресурсам, для которых применялся этот пароль. Для решения описанной проблемы можно использовать дополнительный фактор проверки личности. Решения, основанные на таком методе, называются системами двухфакторной аутентификации (two-factor authentication, 2FA) или многофакторной аутентификации (multi-factor authentication, MFA). Одним из таких решений является Multifactor от компании «Мультифактор». Эта система позволяет выбрать в качестве второго фактора один из следующих инструментов: аппаратный токен, SMS-сообщения, звонки, биометрию, UTF, Google Authenticator, «Яндекс.Ключ», Telegram или мобильное приложение. Необходимо добавить, что данное решение предлагается только в качестве сервиса, когда у заказчика устанавливаются лишь программные агенты, а ядро системы размещается на стороне вендора, избавляя таким образом специалистов заказчика от проблем с внесением изменений в инфраструктуру и решением вопросов по организации канала связи с провайдерами для приёма звонков и SMS-сообщений.

Увеличение интереса к цифровизации бизнеса сегодня затрагивает практически весь спектр организаций – от стартапов до крупных корпораций, причем в самых разных сферах деятельности. Последние годы инновационные цифровые продукты кардинально изменили способы предоставления ценности потребителям и повысили скорость реакции на изменения рынка, что заставляет крупные предприятия менять свое отношение к инвестициям в ИТ, воспринимая его уже не просто как центр затрат, а как один из ключевых активов, приносящих прибыль. Однако желание корпораций, с их унаследованными за годы существования ИТ ландшафтами, участвовать в цифровой гонке наряду со стартапами нередко приводит к еще большему увеличению сложности всей ИТ инфраструктуры, что в свою очередь влечет неоправданный рост стоимости владения ИТ активами, риски нарушения безопасности и непрерывности бизнеса, а также увеличение Time-To-Market при выпуске новых продуктов.

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

Что ж, будем разбираться с помощью системного подхода.

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

Всем привет! Меня зовут Миша, я работаю на позиции ручного тестировщика, или Manual QA - кому как удобно. В связи с тем, что в моей работе преобладает ручное тестирование -  я часто сталкиваюсь с консолью разработчика в браузере (думаю как и 99.9% web-тестировщиков). 

В интернете огромное количество источников, в которых можно найти информацию про DevTools, как для разработчиков, так и для тестировщиков. Конечно, наполнение таких статей очень сильно разнится в зависимости от ее направленности. Изучив большое количество подобного материала и поняв, что нас (тестировщиков) обделяют информацией, решил залезть в первоисточник для изучения инструментов разработчика в полном объеме. Пройдясь по всем пунктам огромного меню, выписал для себя порядка 20 пунктов, которые были бы интересны (читай полезны) для тестировщиков. Сразу скажу, что в статье я не буду рассказывать, как пользоваться тем или иным инструментом, так как это подробно описано в статьях, которые будут прикреплены к каждому из пунктов. Цель моего повествования - скорее вычленить из огромного списка возможностей DevTools, именно те, которые были бы полезны для QA-специалистов. Не претендую на объективность и полную раскрытость темы, но постараюсь это сделать.

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

Вступление