Разработчики Chrome, наконец, урезали поддержку лучшего блокировщика рекламы, uBlock Origin, и теперь популярность моего любимчика Firefox снова растёт¹. Так что здесь я постараюсь убедить вас перейти на этот браузер и покажу, как его использовать.

2025 год. Как же легко алгоритмы вошли и закрепились в нашей жизни. Они на работе, в учёбе, в творчестве, в быту. Нейросети редактируют тексты, выбирают шрифт, накидывают идеи, помогают с кодом, сочиняют музыку. Честно говоря, единственное, что они пока не умеют — это сварить вам кофе. Хотя… и это, кажется, вопрос времени.

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

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

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

Приятного чтения!

Хочу начать с личной предыстории. Давным‑давно, как и многие из вас, я читал умные книжки: «Чистый код» и «Чистая архитектура» Роберта Мартина, «Совершенный код» Стива Макконнелла и другие.

Также не обошли меня и классические принципы проектирования — SOLID, KISS, DRY — и, думаю, каждый читатель добавит сюда свои.

Безусловно, это всё важные и фундаментальные вещи.

Но однажды на горизонте появилось DDD — предметно‑ориентированное проектирование в изложении Эрика Эванса. Именно его «синяя книга» стала культовой и задала язык для архитектурного мышления.

Позже я открыл и «красную книгу» Вона Вернона, где DDD уже рассматривался с точки зрения практической имплементации: архитектура, код, реальные подходы в проектах.

Читая Эванса, рассматривая его диаграммы классов и примеры кода, я всё думал: как он это делает?

Самым большим открытием для меня стало то, что книга DDD хоть и показывает стратегические и тактические приёмы — агрегаты, объекты‑значения, спецификации, фабрики и т. д. — но не учит проектировать саму предметную область.

Складывалось ощущение, что мы это уже откуда‑то должны были знать. А откуда — остаётся загадкой.

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

Меня зовут Денис Исаев, и я руковожу одной из бэкенд групп в Яндекс.Такси. Сегодня я поделюсь с читателями Хабра описанием проблем, которые могут возникнуть, если не учитывать идемпотентность распределенных систем в своем проекте. Для этого я выбрал формат вымышленных историй о стажёре Васе, который только-только учится работать с API. Так будет нагляднее и полезнее. Поехали.

Event storming — метод, который смещает акцент у событий с технического на организационный и бизнес уровни и помогает создать устойчивую модульную систему. Он нередко используется в контексте моделирования микросервисов. Но как применить его на практике?

При создании системы на микросервисах можно легко получить распределенный монолит. Event Storming не уберегает от этого на 100 %, но позволяет существенно снизить риск этого события. О том, как именно этого добиться, рассказал в своем докладе на конференции TechLead Conf 2020 практикующий консультант по архитектуре, процессам разработки и продуктовым практикам Сергей Баранов.

Приветствую, коллеги! Меня зовут @ProstoKirReal Мне бы хотелось с вами обсудить как работает интернет от кабелей на витой паре, соединяющие простые локальные сети до подводных коммуникационных кабелей соединяющие между собой континенты и основные операторские сети.

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

В этом цикле статей я не стану учить вас настраивать оборудование и проектировать сети. Я расскажу об основных (и не только) принципах построения сети, а также о функционировании сети и сетевых протоколов в стеке TCP/IP.

Я буду часто ссылаться к предыдущим статьям, где уже описывал сетевые протоколы. Это позволит мне сократить объемный текст. 

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

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

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

Я наткнулся на пост в X/Twitter, где Pritam обнаружил, что его решение на Leetcode работало медленнее, когда он использовал встроенную функцию min, и производительность улучшилась, когда он реализовал min прямо в своем коде на Python.

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

Автор на этом скриншоте использовал Python 2, который на данный момент уже стал древностью. За последние 10 лет Python 3 получил множество релизов, и последние версии были нацелены на улучшение производительности языка. Так действительно ли вызовы функций по‑прежнему так сильно влияют на производительность в Python?

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

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

Давайте знакомиться: меня зовут Никита Соболев, я core‑разработчик CPython, mypy и typeshed. Некоторое время назад я понял, что на русском языке довольно мало контента про устройство CPython внутри. В основном доклады с конференций и статьи. Где‑то про память, где‑то про GIL, где‑то про парсер. Но чтоб системно и по всем основным частям в одном месте — такого я не нашел.

И решил сделать своё! Под катом я расскажу, как я делаю «Лучший курс по Питону»* на ютюбе. Почему он бесплатный. И почему он такой, какой есть. А еще я расскажу, какая польза будет разработчикам от его просмотра.

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

В Python сложилось устойчивое убеждение, что если мы работаем с MQ - то нам нужен Celery, но он слегка устарел. Именно поэтому люди пытаются выкинуть "деда" и затащить вместо него любой новый многообещающий MQ-инструмент. Кроме того, культ Celery настолько силен в умах, что практически все новые библиотеки для работы с MQ пытаются стать его "убийцей" и заменой.

Однако, это не совсем верно. Существует огромный пласт проектов, которым нужен не фреймворк для менеджмента задач, а просто "голый" функционал Kafka/RabbitMQ/NATS/whatever для межсервисного взаимодействия. И все эти проекты вынуждены довольствоваться "сырыми" python-клиентами к своим брокерам, а всю обвязку вокруг этих клиентов писать самостоятельно. FastStream целится как раз в эту нишу.

В рамках статьи я хочу убедить вас, что не Celery мы едины, и для альтернативных инструментов найдется место под солнцем. А также рассмотрим фичи FastStream, которые он привносит в застоявшийся мир MQ-инструментов.

Открываю исходники очередного enterprise-проекта: о да-а-а, вот они, старые знакомые, лучшие друзья разработчика — first name и last name.

При работе с современными веб-приложениями реального времени незаменима возможность отправлять события с сервера на клиент. Именно этой необходимостью продиктовано то, что за годы работы было изобретено несколько методов для этой цели, каждый с собственным набором достоинств и недостатков. Первоначально единственным вариантом был длинный опрос. Затем в качестве альтернативы появились веб-сокеты — более надёжное решение для двунаправленной коммуникации. Вслед за веб-сокетами появились события, отправляемые сервером (SSE), более простой метод, обеспечивающий однонаправленную связь от сервера к клиенту. Забегая вперёд, сейчас разрабатывается ещё и протокол WebTransport, который может тем более изменить ландшафт этой области, обеспечивая более эффективный и гибкий подход, располагающий к масштабированию. В некоторых нишевых случаях можно присмотреться и к технологии WebRTC, предназначенной для работы с событиями в направлении сервер-клиент.

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

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

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

Так как они это делают?

Привет, Хабр! Я Женя, архитектор интеграционной платформы в Точке, отвечаю за асинхронный обмен сообщениями между внутренними сервисами, за ESB и за брокеры сообщений.

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

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