Сейчас технологии машинного обучения и нейронных сетей находят широкое применение в различных сферах, не исключая дизайн и ремонт помещений. Одной из таких технологий является методы генеративных нейросетей, которые позволяют преобразовывать изображения, сохраняя основные элементы оригинала, но добавляя новые детали и стилистические изменения. Меня зовут Алексей Луговой, я работаю с Computer Vision в Самолете и уже обзорно рассказывал на Хабре, как мы применяем искусственный интеллект в строительстве. Сегодня же углубимся в задачу по созданию генеративной сети для создания проекта ремонта. Рассмотрю процесс использования диффузионных моделей с различными дополнениями на примере не самой обычной задачи — преобразования интерьера комнаты, начав с оригинального изображения голых стен и завершая итоговой генерацией в фирменном дизайнерском стиле.

Работа в Яндексе ставит огромное количество технических вызовов, которые интересно решать. И один из них — это производительность основной очереди сообщений YDB Topics. Посмотрим, может ли опенсорсный продукт от Яндекса конкурировать с Apache Kafka по производительности.

Меня зовут Зевайкин Александр. Я уже практически 20 лет в IT. Начинал с преподавания в вузе, запускал множество стартапов, руководил командами разработки. В текущий момент я работаю в Яндексе в отделе, занимающимся одной из высоконагруженных систем. Это разработка распределённой базы YDB, в частности, функциональности YDB Topic.

Несмотря на то, что данная статья была опубликована более полугода назад, команда Spring АйО по-прежнему считает ее актуальной, важной и интересной.

Себастьян Делойзе, контрибьютор Spring Framework, делится обзором усилий команды Spring по оптимизации эффективности приложений во время выполнения. Он рассматривает Virtual Threads, GraalVM Native Image, Project CRaC, Project Leyden и всё это в контексте Spring!

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

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

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

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

Disclaimer. Данная работа не повлияла на мои взгляды на программирование, но повлекла достаточно радикальные изменения в подходах к проектированию автоматных объектов.  Теперь, если процесс  автономен и/или не предъявляет требований  к синхронизации, он может использовать другие механизмы параллелизма, не переставая при этом быть автоматным по сути. А почему так случилось, что этому предшествовало  и что это за изменения, вы прочтете далее.

Это не самая большая моя статья (так я думал, начиная ее), над которой я работал, пожалуй, дольше и больше, чем над другими. Но это точно первая моя статья, в которой автоматы и ВКПа не будут главной темой. Тема потоков для меня достаточно необычна, т.к. я совсем не фанат многопоточного программирования. Но,  тем не менее, занимаясь параллельным программированием, время от времени возвращаюсь к теме многопоточности. И вот, чтобы добыть какие-то аргументы для критики и одновременно попробовать найти практическое применение потокам, я решил в этот очередной раз более плотно заняться потоками. А что из этого получилось,  читайте далее.

Вы тоже устали вручную заполнять Dockerfile и docker-compose.yaml под каждый новый проект?

Я всегда задумывался, применяю ли я известные best practices, когда пишу конфиг для Docker, и не занесу ли я случайно какие-нибудь уязвимости, вручную заполняя конфиг-файлы.

Что же, теперь мне больше не придется беспокоиться об этом, благодаря добрым людям из Docker, которые недавно реализовали инструмент для этого - docker init .

Интересно, как экономить время и быстро генерировать конфиги, даже если вы не профи в Docker? Прошу под кат.

Hola, Хабр! Я — технический писатель и за свою длинную карьеру в ИТ, нигде и никогда не сталкивался с ситуацией переизбытка в командах технических писателей. Наоборот, почти повсеместно в компаниях есть множество продуктов и проектов, в которых документация неполная, неточная, устаревшая и покрытая паутиной, а самих «техписов» хронически не хватает. Опытные спецы, умеющие читать код, документировать алгоритмы, описывать БД и API — это вообще люди уровня «ошибка выжившего». И, возможно, я нашел ответ на этот вопрос.