Друзья, всем привет! Сегодня я хочу рассказать вам про самую простую и доступную для понимания нейросеть, которая создает изображения по вашему текстовому описанию. Она называется Fooocus и основана на знаменитой Stable Diffusion XL. Это идеальное решение в качестве вашей первой нейросети, и необходимый инструмент для любого дизайнера или контент мейкера.

Внутри много тяжелых изображений.

Федеральная торговая комиссия США (ФТК) отвечает за защиту прав потребителей, в том числе за борьбу с монополиями. Недавно она предъявила Amazon официальную жалобу за «незаконное удержание монопольной власти» и «сознательное ущемление прав покупателей». Это очень серьезно и может поставить компанию на грань разделения активов. Новые разделы жалобы показывают, что руководители Amazon, включая бывшего гендиректора Джеффа Безоса, вносили в платформу изменения, которые увеличивали прибыль компании, одновременно нанося вред покупателям и продавцам, а также делая сайт менее удобным в использовании.

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

Готовы поделиться ключевыми обновлениями, которые вы найдете в свежем релизе Jmix 2.1. 

Для тех, кто хочет знать все, полную информацию об изменениях можно найти в документации Что нового. 

Проект это сложная история. Обычно это относительно сложное и длительное мероприятие, создать программный продукт и провести его через стадию активной разработки до первой реальной коммерческой эксплуатации. Лично я видел как этот путь, в среднем, занимал от 2 до 5 лет на проекте с большой командой разработчиков.

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

Под катом наблюдения и личные выводы почему это происходит.

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

ИИ чат‑боты любят ловить глюки и выдавать всякую чушь. Так массово, что словом 2023 года признали «галлюционировать». В чем причина такого явления? Является ли генеративный ИИ интеллектом (спойлер — и да, и нет)? И что общего у ChatGPT и копировального аппарата Xerox? Разбираемся, осмысляя неочевидный нюанс в логике работы больших языковых моделей.

В прошлом году на АI Journey мы представили модель Kandinsky 2.0 — первую диффузионную мультиязычную модель генерации изображений по тексту, которая может генерировать изображения на основе русскоязычного текста. За ней последовали новые версии — Kandinsky 2.1 и Kandinsky 2.2, которые значительно отличались по качеству и своим возможностям от версии 2.0, и стали для нашей команды серьёзными вехами на пути к достижению лучшего качества генерации.

Спустя год после релиза нашей первой диффузионной модели мы представляем новую версию модели генерации изображений по тексту — Kandinsky 3.0! Это результат длительной работы нашей команды, которую мы вели параллельно с разработками версий Kandinsky 2.1 и 2.2. Мы провели много экспериментов по выбору архитектуры и проделали большую работу с данными, чтобы сделать понимание текста и качество генераций лучше, а саму архитектуру — проще и лаконичнее. Также мы сделали нашу модель более «отечественной»: теперь она значительно лучше ориентируется в российском и советском культурном поле.

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

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

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

Я далек от того, чтобы делать какие-либо моральные оценки этому явлению (если
прочтете до конца, поймете, почему).  Я – тимлид с 15-летним опытом работы в IT. Я лично нанимал многих людей и со многими прощался. У меня есть своя приличная статистика откровенных мыслей и настроений людей, которые со мной работали, работают, или работают, но не со мной. На основании этого своего опыта (и не только своего) я попытаюсь дать ответ на вопрос, как и почему вырастает фига в кармане программиста. Я потяну за ниточку клубка причин и постепенно попытаюсь его распутать целиком. Результатом будет сводный граф причин феномена саботажа в IT. Поехали!

Хочу вас огорчить, программисты не делают игры - их делают дизайнеры и арт. Можно уволить программиста и на его место придет другой и через условные месяц-два-полгода начнет закрывать таски не хуже. Если увольняется дизайнер, его монстр, пушка или контент повисает без хозяина и без "видения". Если её не перехватил сосед (а у соседа свой монстр), то в большинстве случаев его работа просто уходит в стол и монстра пишут заново на тех же ассетах и принципах, но заново.

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

Прошу простить заранее за несколько кликбейтный заголовок )

Не так давно писал в соцсетях хейт‑пост по поводу «алгоритмических секций» при приёме на работу в Яндекс.

Да и многие другие софтверные компании это практикуют и считают навыки написания алгоритмов — чуть ли не самым важным навыком для программистов.

И ставят данной компетенции очень высокий приоритет при приёме на работу.

Попробую сегодня развить эту мысль и объяснить почему ставить навыки написания алгоритмов на первый план — не правильно, почему этот «алгоритмический» критерий не релевантен и не отражает реальной ценности / уровня / потенциальной пользы от данного программиста.

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

С вами Вадим Дарморезов, участник профессионального сообщества NTA.

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

В проектах, связанных с распознаванием лиц своеобразными «флагманами» являются библиотеки dlib/face‑recognition и свёрточные нейронные сети. При этом на просторах русскоязычного интернета довольно мало статей о библиотеке insightface. Именно о ее использовании хотелось бы поговорить более подробно. Всем, кому это интересно, добро пожаловать по кат.

Всем привет, меня зовут Александр Бобряков. Я техлид в команде МТС Аналитики, занимаюсь Real-Time обработкой данных. Недавно мы начали использовать фреймворк Apache Flink. Эту технологию выбрали, так как она (в отличие от Apache Spark) относится к true-стримингу и позволяет строить обработку данных с минимальной задержкой. В качестве DI-фреймворка выбрали привычный нам Spring Framework.

Наша команда использует разные виды тестирования: Unit, интеграционное, E2E, ручное, автоматизационное, нагрузочное. Этой теме будет уделено особое внимание. Я расскажу, какие подходы и паттерны помогут быть уверенными в качестве того, что вы разработали.

Эти знания будут полезны любому Java-разработчику, знакомому со Spring. А начинающие Flink-специалисты найдут здесь примеры стандартных ошибок и пути их решения. Обратите внимание, что эти материалы писались, когда актуальной версией Flink была 1.17. В конце октября вышла версия 1.18, и она может отличаться некоторыми нюансами.

В этой статье мы расскажем вам про самые важные фичи, внедренные за последние полгода в ChatGPT (самую мощную нейросетку в мире), а также обсудим – каким видением будущего поделился Сэм Альтман на прошедшей 7 ноября конференции от OpenAI. Спойлер: они хотят запилить «агентов Смитов», которые смогут самостоятельно взаимодействовать с миром!

Не секрет, что работа с часовыми поясами — боль, и многие разработчики объяснимо стараются ее избегать. Тем более что в каждом языке программирования / СУБД работа с часовыми поясами реализована по-разному.

Среди тех, кто работает с PostgreSQL, есть очень распространенное заблуждение про типы данных timestamp (который также именуется timestamp without time zone) и timestamptz (или timestamp with time zone). Вкратце его можно сформулировать так:

Мне не нужен тип timestamp with time zone, т.к. у меня все находится в одном часовом поясе — и сервер, и клиенты.

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

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