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

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

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

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

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

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

Всем привет. Меня зовут Сергей Фегон. Я ex-CТО, сейчас работаю руководителем нескольких групп разработки финтех-продуктов экосистемы компаний ВБЦ и TenChat, а также преподаю в OTUS. Делюсь своими знаниями на курсах CTO/Технический директор и Team Lead в OTUS. За время преподавательской деятельности и на основе личного управленческого опыта, я сформировал для себя несколько основных столпов подготовки IT-менеджеров:

Метрики DORA 4 взяты из книги «Accelerate», популярной книги для Инженерных лидеров.

DORA включает 4 основные метрики:

• Частота развертывания (Deployment Frequency);
• Время цикла (Cycle Time), иногда называемое Временем выполнения изменений (Lead Time for Changes);
• Процент отказов (Change Failure Rate);
• Среднее время восстановления (Mean Time to Restore), иногда называемое Временем восстановления услуги (Time to Restore Service).

Что вы продаете? Продукт, опыт или и то, и другое? Является ли ваш продукт просто решением определённой проблемы или он предоставляет уникальный опыт? Как правильно заметил Стив Джобс, «нужно начинать с опыта клиента и двигаться назад к технологии».

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

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

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

Но что именно представляют собой инженерные метрики и как они могут помочь вам и вашей команде?

В этой статье я постараюсь ответить на эти вопросы:

• Что такое инженерные метрики и какова их цель
• Как они связаны с продуктивностью
• Как извлечь из них максимальную пользу

Не так давно я проводил корпоративное обучение на тему того, как работать с мейнфреймом IBM. Хочу рассказать об этом в нескольких статьях.

TCP/IP (Transmission Control Protocol/Internet Protocol) представляет собой набор сетевых протоколов, обеспечивающих связь между компьютерами и другими устройствами в сети. Его внедрение в мейнфреймы IBM значительно расширяет возможности этих мощных систем, позволяя им эффективно взаимодействовать в современных сетевых средах, интегрироваться с разнообразными приложениями и системами, а также поддерживать высокие уровни безопасности и производительности.

В этой статье мы рассмотрим основные аспекты работы с TCP/IP на IBM Mainframe.

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

В этой статье мы рассмотрим, как использовать ArgoCD для автоматизации деплоя дашбордов Grafana.

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

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

Customer Journey Map (CJM) или Карта Путешествия Клиента – это инструмент, который становится все более популярным в мире маркетинга и управления клиентским опытом. Он представляет собой визуальное изображение пути, который проходит клиент от момента первого контакта с брендом до совершения покупки и последующих взаимодействий. CJM позволяет глубже понять потребности и поведение клиентов, что, в свою очередь, способствует разработке более эффективных маркетинговых стратегий. В данной статье мы рассмотрим, как именно CJM помогает в создании маркетинговой стратегии и почему его использование является необходимым в современных условиях.

По сравнению с управлением лидерство носит некоторый налёт мистичности. Но мистика не помогает выполнить работу.

«Он менеджер, а не лидер», — объяснял мне мой собеседник, говоря об ИТ-директоре в пренебрежительном тоне.

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

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

А это действительно помогает выполнять работу. Это важный фактор, но не главный.

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

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

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

Одной из самых популярных архитектур нейронных сетей для таких задач, является YOLO (you only look once), созданная в 2015 году. С тех пор появилось довольно много версий данных алгоритмов. Последние выпуски сети предназначены для таких задач как распознавание, обнаружение и сегментация изображений. 

Тестирование — это процесс оценки программного приложения, а тестировщики — это профессионалы, которые участвуют в этом процессе. Они решают множество задач: пишут тест-кейсы, сообщают о найденных багах, настраивают среду, работают с требованиями и так далее. По данным исследования, рынок тестирования программного обеспечения уже превысил 40 миллиардов долларов США и, как ожидается, к 2027 году вырастет ещё на 7%. Тестировщики должны знать языки программирования, инструменты управления тестированием, инструменты автоматизации тестирования, обладать навыками управления проектами и многими другими навыками. 

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

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

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

Зачада: есть шикарный IT-продукт, которому нужно найти клиентов. Владелец продукта хочет бесконечное количество лидов прямо завтра и прямо за 0 ₽. Это, безусловно, устроит и его, и unit-экономику, и инвесторов, и даже местную собаку Чучу. Но увы, такой расклад невозможен. Вопрос: что делать?

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

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

AnyLogic — идеальная платформа для создания симуляционных моделей для обучения DRL-агентов в сложных средах. Недавно разработанная библиотека Alpyne — это библиотека Python, которая позволяет пользователям обучать DRL-агентов на Python, взаимодействуя с моделью AnyLogic. К сожалению, она все еще недостаточно стабильна для работы со сложными симуляционными моделями.

В этой статье мы представляем новый способ взаимодействия DRL с симуляционными моделям в AnyLogic с помощью библиотеки Pypeline. Этот метод также может быть использован для (не глубокого) обучения с подкреплением, но благодаря своей простоте большинство сред, для которых хватает простого RL, могут быть смоделированы непосредственно в самих языках программирования, таких как Python.

Впервые я услышал термин "Lakehouse" в 2019 году, когда пролистывал документ Dremio. Будучи по своей натуре консервативным человеком, я предположил, что это просто очередной маркетинговый термин. Но пять лет спустя, кажется, уже все говорят о Lakehouse (после того, как наговорятся об ИИ :d); все крупные облачные хранилища данных теперь поддерживают чтение форматов Hudi, Iceberge или Delta Lake непосредственно в хранилище объектов, и даже BigQuery имеет специальный механизм запросов для этой задачи. На этом инновации не заканчиваются: Apache XTable (ранее OneTable) предоставляет абстракции и инструменты для трансляции метаданных формата таблиц Lakehouse. Недавно компания Confluent объявила о выпуске TableFlow, которая передает данные из Apache Kafka непосредственно в озеро данных, хранилище или аналитический движок в виде таблиц Apache Iceberg.

Это заставило меня пересмотреть свои прежние предположения: так был ли Lakehouse просто маркетинговым термином?