Kurgan-Telecom Ru | Информационные технологии

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

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

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

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

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

 При этом исследование компании PwC, в котором приняли участие более 4 400 руководителей по всему миру, показывает: более половины генеральных директоров пока не видят отдачи от инвестиций в ИИ. И парадоксально, что именно эти организации одновременно рассматривают фонд оплаты труда сотрудников как основной источник неэффективных затраты.

Существует множество программных угроз для систем ИИ. Но я расскажу о GDDRHammer — атаке на аппаратную часть. Разберу эту атаку до винтика, то есть покажу, как она реализуется на физическом уровне, и сравню с атакой GeForge того же класса.

Как я улучшил универсальный код Элиаса 1975 года, заменив длину на popcount — и получил 36% экономии на метаданных. С бенчмарками! Картинка на обложке кринжовая, но тут вроде так принято?

Меня зовут Катя, я руковожу операционным отделом ITSM 365 в Naumen.

Несколько лет назад у меня была одна команда из трех аналитиков. Сейчас — три команды, три тимлида, два техлида и пятнадцать аналитиков. Вместе с ростом команды, разумеется, росло и количество процессов, в которые я была вовлечена.

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

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

Университет: для кого и зачем

Нужно ли идти в университет? Кому-то да, кому-то нет - и это нормально.

В 90-е хайп на высшее образование стал огромным. До этого к рабочим профессиям относились с уважением. А потом появилась фраза, которую многие слышали в детстве: «Будешь плохо учиться - пойдёшь на завод». Но что плохого в заводе? Условия труда? Это вопрос не к заводу, а к нормам и контролирующим органам. Мне довелось работать на производствах Renault и SKF - условия были отличные. Не всем нужно сидеть в офисе, и это стоит наконец признать.

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

Нужна корочка - есть заочное, можно получить когда понадобится. Жаль, что вечернее образование почти исчезло: это была действительно полезная форма. По мне, идти за высшим образованием правильнее уже после того, как поработал в какой-то сфере. Тогда учёба становится ответом на реальные вопросы, а не абстрактной программой.

Мне нравится западная модель, где университет — это набор курсов. Курс по механике, курс по матану, курс по CS. Как в игре: сам собираешь билд. Можно совместить театр и физику — и пойти работать инженером по спецэффектам. MythBusters, между прочим, именно про это — я был большим фанатом.

Меня зовут Родион, и я уже около 2,5 лет работаю в VK Android-разработчиком в крупном многомодульном проекте с сотнями экранов и довольно большой аудиторией. Когда я попал на проект, стек был классическим и проверенным: XML-вёрстка, навигация через Cicerone, Dagger 2 для DI, Coroutines и Flow для асинхронщины, а в качестве архитектурного паттерна — MVVM. 

Рано или поздно любая растущая кодовая база упирается в потолок своих архитектурных решений. У нас этот момент настал, когда количество экранов выросло до нескольких сотен и команда начала тратить больше времени на борьбу с неконсистентным состоянием UI. Классическая связка XML + ViewBinding + MVVM работала, но с каждым новым экраном мы всё острее чувствовали её ограничения: разрозненные StateFlow, дублирование кода во фрагментах, сложность переиспользования компонентов. 

Нужно было что-то менять — пересмотреть сам подход к построению UI. Так мы начали миграцию на Jetpack Compose (который на момент начала перехода уже был стабильным и самодостаточным). Полтора года спустя, пройдя через рефакторинг базовых классов, переход с MVVM на MVI и постепенную замену содержимого всех фрагментов, мы получили стек, на котором разработка ускорилась, а баги, связанные с состоянием экрана, практически исчезли. 

Полный переход на Jetpack Compose мы разделили на три больших этапа:

- переписываем содержимое всех фрагментов на ComposeView;

- переходим с Dagger2 на Koin;

- меняем навигацию с Cicerone на Compose-навигацию.

О втором и третьем этапах кратко расскажу ниже —  в главе стратегии перехода, а на первом этапе остановлюсь подробнее.

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