Совместное использование API Gateway и BFF
API Gateway и BFF — популярные архитектурные паттерны применяемые для разработки внешнего API приложения построенного на микросервисной архитектуре.
Шаблоны имеют принципиально разный дизайн (умный бекенд или умный клиент) и используются в разных типах микросервисных систем. Но что если в одном приложении объединить преимущества обоих подходов Предоставляя централизованное управление и оптимизацию, а также адаптацию для разных видов клиентов (например веб и мобайл)
Какие задачи будет решать каждый паттерн?
API Gateway
Маршрутизация и балансировка нагрузки: Все входящие запросы сначала проходят через API Gateway, который уже направляет их к соответствующим BFF. Необходимый BFF определяется по заголовкам или url.
Безопасность и авторизация: Gateway выполняет проверку JWT токенов, групповых политик и других мер безопасности.
Кэширование: Кэширует часто запрашиваемые общие данные, уменьшая нагрузку на микросервисы.
Логирование и мониторинг: Централизованно собирает логи и метрики всех запросов.
BFF
Реализации логики для клиента: Адаптация запросов/ответов под нужды конкретного клиентского приложения (мобильного или веб).
Оптимизация данных: Преобразование данных в удобный для клиента формат. Веб-приложению необходимы детализированные данные, а мобильному требуется минимизированных версия данных для быстрого отображения и экономии трафика
Изоляция изменений:
Позволяет быстро вносить изменения для конкретного клиента без влияния на работу других клиентов.
Какие преимущества от совместного использования?
Уменьшение дублирования функционала:
Общие функциональности, такие как маршрутизация, безопасность, кэширование и логирование, реализуются на уровне Gateway. Нет необходимости дублировать код и реализовывать одно и то же в каждом BFF.
Улучшение производительности и масштабируемости:
Кэширование на уровне Gateway снижает нагрузку на микросервисы, а BFF обеспечивает оптимизацию запросов/ответов, что улучшает производительность и масштабируемость системы.
Централизованное управление и безопасность:
API Gateway обеспечивает единые политики безопасности для всего приложения и всех клиентов, что снижает риски и уменьшает количество точек потенциального отказа.
Итоговый поток запросов в системе
1. Клиентское приложение (веб или мобильное) отправляет запрос.
2. Запрос проходит через API Gateway, где проверяются токены безопасности и применяются политики доступа.
3. Gateway маршрутизирует запрос к соответствующему BFF.
4. BFF обрабатывает запрос, взаимодействует с микросервисами, агрегирует данные и возвращает ответ в формате, оптимизированном для конкретного клиента.
5. Ответ возвращается клиентскому приложению через API Gateway.
API Gateway и BFF — популярные архитектурные паттерны применяемые для разработки внешнего API приложения построенного на микросервисной архитектуре.
Шаблоны имеют принципиально разный дизайн (умный бекенд или умный клиент) и используются в разных типах микросервисных систем. Но что если в одном приложении объединить преимущества обоих подходов Предоставляя централизованное управление и оптимизацию, а также адаптацию для разных видов клиентов (например веб и мобайл)
Какие задачи будет решать каждый паттерн?
API Gateway
Маршрутизация и балансировка нагрузки: Все входящие запросы сначала проходят через API Gateway, который уже направляет их к соответствующим BFF. Необходимый BFF определяется по заголовкам или url.
Безопасность и авторизация: Gateway выполняет проверку JWT токенов, групповых политик и других мер безопасности.
Кэширование: Кэширует часто запрашиваемые общие данные, уменьшая нагрузку на микросервисы.
Логирование и мониторинг: Централизованно собирает логи и метрики всех запросов.
BFF
Реализации логики для клиента: Адаптация запросов/ответов под нужды конкретного клиентского приложения (мобильного или веб).
Оптимизация данных: Преобразование данных в удобный для клиента формат. Веб-приложению необходимы детализированные данные, а мобильному требуется минимизированных версия данных для быстрого отображения и экономии трафика
Изоляция изменений:
Позволяет быстро вносить изменения для конкретного клиента без влияния на работу других клиентов.
Какие преимущества от совместного использования?
Уменьшение дублирования функционала:
Общие функциональности, такие как маршрутизация, безопасность, кэширование и логирование, реализуются на уровне Gateway. Нет необходимости дублировать код и реализовывать одно и то же в каждом BFF.
Улучшение производительности и масштабируемости:
Кэширование на уровне Gateway снижает нагрузку на микросервисы, а BFF обеспечивает оптимизацию запросов/ответов, что улучшает производительность и масштабируемость системы.
Централизованное управление и безопасность:
API Gateway обеспечивает единые политики безопасности для всего приложения и всех клиентов, что снижает риски и уменьшает количество точек потенциального отказа.
Итоговый поток запросов в системе
1. Клиентское приложение (веб или мобильное) отправляет запрос.
2. Запрос проходит через API Gateway, где проверяются токены безопасности и применяются политики доступа.
3. Gateway маршрутизирует запрос к соответствующему BFF.
4. BFF обрабатывает запрос, взаимодействует с микросервисами, агрегирует данные и возвращает ответ в формате, оптимизированном для конкретного клиента.
5. Ответ возвращается клиентскому приложению через API Gateway.
🔥5
Шаблон "Сага" является одним из ключевых шаблонов проектирования, который используется в микросервисной архитектуре для управления распределенными транзакциями. В отличие от традиционных монолитных приложений, где транзакции могут выполняться в рамках одной базы данных, в микросервисной архитектуре транзакции могут охватывать несколько сервисов, что требует особого подхода для обеспечения целостности данных.
Например вы разработали систему для покупки билета на самолёт. Предположим у вас 3 сервиса: Оплата, Уведомление, Бронирование. Сервис успешно списал деньги, выслал уведомление о покупке, но возникла ошибка на этапе бронирования. Как вернуть всё в исходное состояние когда у нас 3 независимых сервиса? В монолитном приложении нас бы спасли транзакции ACID. А в случае с микросерисами - Саги.
Основная идея шаблона "Сага"
Сага — это последовательность транзакций, каждая из которых обновляет данные в отдельном микросервисе. Каждая из этих транзакций является локальной и независимой, но вместе они формируют одну логическую транзакцию. В случае неудачи одной из транзакций система должна выполнить компенсирующие действия, чтобы откатить изменения, сделанные предыдущими транзакциями.
Принципы работы саги
1️⃣ Разбиение на шаги: Сага состоит из нескольких шагов (транзакций), каждый из которых выполняется в рамках одного микросервиса. В процессе покупки билета на самолёт, это могут быть шаги: списание средств, уведомление о списании, проверка доступности рейса и его бронирование.
2️⃣ Компенсирующие транзакции: Для каждого шага определяется компенсирующая транзакция, которая откатывает изменения в случае ошибки. Например, если возникла ошибка на этапе бронирования, то нужно его отменить и запустить компенсирующие транзакции для предыдущих шагов.
3️⃣ Асинхронное выполнение: Шаги в саге могут выполняться асинхронно. После успешного выполнения одного шага инициируется следующий. Если какой-либо шаг не удался, запускаются компенсирующие транзакции. Компенсирующее действие для этапа оплаты - вернуть средства. Для этапа уведомления - отправить новое уведомление с информацией, что бронирование не удалось.
Стратегии реализации саги
Оркестрация: В этой стратегии один из сервисов (или специальный оркестратор) управляет выполнением всей саги. Он инициирует каждый шаг и отслеживает их выполнение, принимая решения о запуске компенсирующих транзакций при необходимости. Этот подход проще в реализации и контроле, но создает единую точку отказа.
Хореография: В этой стратегии отсутствует центральный оркестратор. Каждый микросервис знает, что делать после выполнения своей локальной транзакции, и сам инициирует следующий шаг саги или компенсирующую транзакцию при неудаче. Такой подход более децентрализованный и устраняет единую точку отказа, но может быть сложнее в управлении и отладке.
Например вы разработали систему для покупки билета на самолёт. Предположим у вас 3 сервиса: Оплата, Уведомление, Бронирование. Сервис успешно списал деньги, выслал уведомление о покупке, но возникла ошибка на этапе бронирования. Как вернуть всё в исходное состояние когда у нас 3 независимых сервиса? В монолитном приложении нас бы спасли транзакции ACID. А в случае с микросерисами - Саги.
Основная идея шаблона "Сага"
Сага — это последовательность транзакций, каждая из которых обновляет данные в отдельном микросервисе. Каждая из этих транзакций является локальной и независимой, но вместе они формируют одну логическую транзакцию. В случае неудачи одной из транзакций система должна выполнить компенсирующие действия, чтобы откатить изменения, сделанные предыдущими транзакциями.
Принципы работы саги
1️⃣ Разбиение на шаги: Сага состоит из нескольких шагов (транзакций), каждый из которых выполняется в рамках одного микросервиса. В процессе покупки билета на самолёт, это могут быть шаги: списание средств, уведомление о списании, проверка доступности рейса и его бронирование.
2️⃣ Компенсирующие транзакции: Для каждого шага определяется компенсирующая транзакция, которая откатывает изменения в случае ошибки. Например, если возникла ошибка на этапе бронирования, то нужно его отменить и запустить компенсирующие транзакции для предыдущих шагов.
3️⃣ Асинхронное выполнение: Шаги в саге могут выполняться асинхронно. После успешного выполнения одного шага инициируется следующий. Если какой-либо шаг не удался, запускаются компенсирующие транзакции. Компенсирующее действие для этапа оплаты - вернуть средства. Для этапа уведомления - отправить новое уведомление с информацией, что бронирование не удалось.
Стратегии реализации саги
Оркестрация: В этой стратегии один из сервисов (или специальный оркестратор) управляет выполнением всей саги. Он инициирует каждый шаг и отслеживает их выполнение, принимая решения о запуске компенсирующих транзакций при необходимости. Этот подход проще в реализации и контроле, но создает единую точку отказа.
Хореография: В этой стратегии отсутствует центральный оркестратор. Каждый микросервис знает, что делать после выполнения своей локальной транзакции, и сам инициирует следующий шаг саги или компенсирующую транзакцию при неудаче. Такой подход более децентрализованный и устраняет единую точку отказа, но может быть сложнее в управлении и отладке.
🔥5👍3❤2
Как включение JIT в PHP 8 ускоряет парсинг CSV-файла
С выходом PHP 8 появилась одна из самых мощных функций — JIT компиляция. Эта технология позволяет значительно ускорить выполнение PHP-скриптов, компилируя код в машинные инструкции на лету. Одной из задач, где JIT может проявить себя особенно эффективно, является парсинг больших CSV-файлов.
Рассмотрим классическую задачу: у вас есть объёмный файл и вам нужно его обработать — например, просуммировать все транзакции выше определенной суммы.
Типичный код для решения этой задачи:
Мы построчно обрабатываем файл, выполняем простую логику и добавляем сумму в общую. Если файл очень большой, то цикл будет исполнен много раз. Что в этом случае будет делать интерпретатор?
Интерпретатор PHP читает исходный код построчно и создаёт набор инструкций opcode. Opcode это не машинный код, а только набор инструкций для виртуальной машины Zend Engine. Затем виртуальная машина исполняет каждую инструкцию opcode последовательно, вызывая в режиме реального времени соответствующие операции на уровне системы.
При этом, когда интерпретатор Zend встречает в opcode цикл, он каждую итерацию заново интерпретирует и исполняет инструкции opcode.
Это и есть нашей с вами платой за использование интерпретируемых языков программирования 🙂
Получается, что один и тот же фрагмент кода интерпретируется несколько раз.
Как JIT Ускоряет работу циклов
JIT позволяет сократить значительное количество интерпретаций opcode виртуальной машиной, за счёт компиляции opcode в машинный код, который выполняется напрямую на процессоре. Скомпилированный машинный код сохраняется и уже многократно используется в итерациях цикла, без необходимости повторной интерпретации.
Как это отразится на нашей задаче обработке файла?
1. Ускорение циклов: Основное время тратится на выполнение цикла, где каждая строка файла разбирается и обрабатывается. С JIT этот цикл будет выполняться быстрее за счет компиляции его тела в машинный код.
2. Эффективность работы со строками: Функции, такие как
3. Уменьшение накладных расходов: Каждый вызов функции в PHP сопровождается определенными накладными расходами. JIT минимизирует эти расходы, поскольку часть функций может быть оптимизирована и выполнена быстрее на уровне машинного кода.
Настройка и включение JIT
Добавим в конфигурацию PHP:
Сравнение производительности: С JIT и Без JIT
Проведем небольшой эксперимент. Подготовим CSV-файл с 10 миллионами строк. Мы запускаем вышеуказанный скрипт — с включенным JIT и без него.
Без JIT: Среднее время выполнения 120 секунд.
С JIT: Средне время выполнения 80 секунд.
Получается, что включение JIT позволило сократить время на парсинг файла на ~33%.
Вопрос читателям: Использовали ли вы JIT для ускорения обработки данных в PHP? Какие результаты вы получили? Поделитесь своим опытом в комментариях!
С выходом PHP 8 появилась одна из самых мощных функций — JIT компиляция. Эта технология позволяет значительно ускорить выполнение PHP-скриптов, компилируя код в машинные инструкции на лету. Одной из задач, где JIT может проявить себя особенно эффективно, является парсинг больших CSV-файлов.
Рассмотрим классическую задачу: у вас есть объёмный файл и вам нужно его обработать — например, просуммировать все транзакции выше определенной суммы.
Типичный код для решения этой задачи:
$file = fopen('large_file.csv', 'r');
$totalSum = 0;
if ($file !== false) {
fgetcsv($file);
while (($row = fgetcsv($file)) !== false) {
$amount = (float)$row[2];
if ($amount > 1000) {
$totalSum += $amount;
}
}
fclose($file);
}
echo "Total sum of large payments: " . $totalSum . "\n";
Мы построчно обрабатываем файл, выполняем простую логику и добавляем сумму в общую. Если файл очень большой, то цикл будет исполнен много раз. Что в этом случае будет делать интерпретатор?
Интерпретатор PHP читает исходный код построчно и создаёт набор инструкций opcode. Opcode это не машинный код, а только набор инструкций для виртуальной машины Zend Engine. Затем виртуальная машина исполняет каждую инструкцию opcode последовательно, вызывая в режиме реального времени соответствующие операции на уровне системы.
При этом, когда интерпретатор Zend встречает в opcode цикл, он каждую итерацию заново интерпретирует и исполняет инструкции opcode.
Это и есть нашей с вами платой за использование интерпретируемых языков программирования 🙂
Получается, что один и тот же фрагмент кода интерпретируется несколько раз.
Как JIT Ускоряет работу циклов
JIT позволяет сократить значительное количество интерпретаций opcode виртуальной машиной, за счёт компиляции opcode в машинный код, который выполняется напрямую на процессоре. Скомпилированный машинный код сохраняется и уже многократно используется в итерациях цикла, без необходимости повторной интерпретации.
Как это отразится на нашей задаче обработке файла?
1. Ускорение циклов: Основное время тратится на выполнение цикла, где каждая строка файла разбирается и обрабатывается. С JIT этот цикл будет выполняться быстрее за счет компиляции его тела в машинный код.
2. Эффективность работы со строками: Функции, такие как
fgetcsv, которые активно работают со строками и массивами, получают прирост в производительности благодаря JIT, за счет того что её не нужно интерпретировать на каждой итерации. Это особенно заметно, если в строке много столбцов или данные требуют интенсивной обработки.3. Уменьшение накладных расходов: Каждый вызов функции в PHP сопровождается определенными накладными расходами. JIT минимизирует эти расходы, поскольку часть функций может быть оптимизирована и выполнена быстрее на уровне машинного кода.
Настройка и включение JIT
Добавим в конфигурацию PHP:
opcache.enable=1
opcache.enable_cli=1
opcache.jit_buffer_size=100M
opcache.jit=1255
Сравнение производительности: С JIT и Без JIT
Проведем небольшой эксперимент. Подготовим CSV-файл с 10 миллионами строк. Мы запускаем вышеуказанный скрипт — с включенным JIT и без него.
Без JIT: Среднее время выполнения 120 секунд.
С JIT: Средне время выполнения 80 секунд.
Получается, что включение JIT позволило сократить время на парсинг файла на ~33%.
Вопрос читателям: Использовали ли вы JIT для ускорения обработки данных в PHP? Какие результаты вы получили? Поделитесь своим опытом в комментариях!
👍6🔥2🤓1
ИИ-система по извлечению информации со сканов счетов: https://habr.com/ru/companies/agima/articles/849722/
Для автоматизации бизнес-процессов часто требуется обработка бумажных документов со сложной структурой — например, счетов, чеков или накладных.
Как правило, в таких случаях данные об оплатах из документов приходится вносить в ERP вручную. И конечно, на это уходит много времени и сил.
Ребята из AGIMA AI в нашем блоге на Хабре рассказывают, как автоматизировали этот процесс с помощью ИИ и какие сервисы использовали.
По ссылке выше найдете все подробности о механизме распознавания полей в документах, а также данные о том, насколько точны такие модели.
Для автоматизации бизнес-процессов часто требуется обработка бумажных документов со сложной структурой — например, счетов, чеков или накладных.
Как правило, в таких случаях данные об оплатах из документов приходится вносить в ERP вручную. И конечно, на это уходит много времени и сил.
Ребята из AGIMA AI в нашем блоге на Хабре рассказывают, как автоматизировали этот процесс с помощью ИИ и какие сервисы использовали.
По ссылке выше найдете все подробности о механизме распознавания полей в документах, а также данные о том, насколько точны такие модели.
Хабр
ИИ-система по извлечению информации со сканов счетов: от разметки до реализации
Для автоматизации бизнес-процессов часто требуется обработка бумажных документов со сложной структурой — например, счетов, накладных и так далее. Частый сценарий: есть почтовый ящик, на который...
🔥4
Как развивать лидеров внутри IT-команды и команды и где искать сильных управленцев: https://clck.ru/3E2mGg.
Осенний сезон полезных митапов продолжается. На этот раз соберемся в нашем офисе 1 ноября и обсудим, как прокачать лидерские качества в вашей команде.
Главные темы митапа:
- как вырастить лидера внутри IT-команды и чем его мотивировать;
- в каких случаях лучше использовать аутстафф;
- как избежать выгорания у руководителей;
- какие стратегии помогут сделать управленческие решения более системными и человечными.
Это важные стратегические вопросы, с которыми часто сталкиваются руководители больших команд.
Но мы не ограничимся только теорией, а попробуем сразу применить все инсайты на практике. Для этого устроим круглый стол с экспертами из X5, Альфа-Банка, Лемана Про, AGIMA и др., а затем закрепим знания на воркшопе с Алексеем Кельиным, исследователем и бизнес-тренером.
Также обещаем приятную атмосферу, вкусную еду, напитки и много нетворкинга. Подробности и обязательная регистрация — по ссылке выше.
Ждем СТО, руководителей IT-департаментов, IT-рекрутеров, IT-лидов и CPO — всех, кто отвечает за управление и развитие команд в IT.
Когда: 1 ноября, 17:30.
Где: оффлайн, Петровка, 19/4, офис AGIMA.
Регистрация: https://clck.ru/3E2mGg
Осенний сезон полезных митапов продолжается. На этот раз соберемся в нашем офисе 1 ноября и обсудим, как прокачать лидерские качества в вашей команде.
Главные темы митапа:
- как вырастить лидера внутри IT-команды и чем его мотивировать;
- в каких случаях лучше использовать аутстафф;
- как избежать выгорания у руководителей;
- какие стратегии помогут сделать управленческие решения более системными и человечными.
Это важные стратегические вопросы, с которыми часто сталкиваются руководители больших команд.
Но мы не ограничимся только теорией, а попробуем сразу применить все инсайты на практике. Для этого устроим круглый стол с экспертами из X5, Альфа-Банка, Лемана Про, AGIMA и др., а затем закрепим знания на воркшопе с Алексеем Кельиным, исследователем и бизнес-тренером.
Также обещаем приятную атмосферу, вкусную еду, напитки и много нетворкинга. Подробности и обязательная регистрация — по ссылке выше.
Ждем СТО, руководителей IT-департаментов, IT-рекрутеров, IT-лидов и CPO — всех, кто отвечает за управление и развитие команд в IT.
Когда: 1 ноября, 17:30.
Где: оффлайн, Петровка, 19/4, офис AGIMA.
Регистрация: https://clck.ru/3E2mGg
👍3
Почему мы охотно нанимаем джунов и почему советуем всем делать то же самое: https://habr.com/ru/companies/agima/articles/856526/
К специалистам уровня Junior на рынке относятся с опаской — их редко и неохотно берут на работу. Однако у нас иной опыт: мы как раз не боимся учить начинающих разработчиков.
Наш тимлид Артем Валевич рассказывает на Хабре, почему джуниор — это не очередная головная боль для команды, а выгодная инвестиция в будущее. Главное — не бояться.
В тексте по ссылке выше найдете советы по обучению джунов, экономику такого найма и советы из нашей практики. Читайте и задавайте вопросы. Тема интересная, готовы обсуждать.
К специалистам уровня Junior на рынке относятся с опаской — их редко и неохотно берут на работу. Однако у нас иной опыт: мы как раз не боимся учить начинающих разработчиков.
Наш тимлид Артем Валевич рассказывает на Хабре, почему джуниор — это не очередная головная боль для команды, а выгодная инвестиция в будущее. Главное — не бояться.
В тексте по ссылке выше найдете советы по обучению джунов, экономику такого найма и советы из нашей практики. Читайте и задавайте вопросы. Тема интересная, готовы обсуждать.
Хабр
Почему мы охотно нанимаем джунов и советуем всем делать то же самое
Всем привет! Меня зовут Артем Валевич, я тимлид в AGIMA . Хочу рассказать о нашем опыте работы с джуниор-разработчиками. Вообще на рынке к ним принято относиться с опаской. Есть стереотип, что они...
❤8👍3👌1
Forwarded from Саша расскажет // о мобильной разработке и ИТ
Платим 50 000 рублей всем, кто посоветует хорошего Golang-разработчика в нашу команду. Важно, чтобы у специалиста был опыт работы от четырех лет и уровень английского языка B1+ и выше для общения в международной команде.
Что нужно делать:
✔️разрабатывать и оптимизировать микросервисы на Golang;
✔️работать с высоконагруженными системами и масштабируемыми решениями.
Что предлагаем:
✔️Формат работы: офис, удаленка, гибрид.
✔️Оформление: штат, ГПХ.
✔️График работы: 5/2.
✔️ДМС со стоматологией.
✔️Возможности для профессионального роста — в любом количестве.
✔️Масштабные проекты и здоровая рабочая атмосфера.
Подробнее о вакансии — на нашем сайте [тык].
Мы выплатим бонус, когда рекомендованный специалист пройдет испытательный срок в нашей команде — обычно это 3 месяца после первого рабочего дня.
Присылайте резюме подходящих кандидатов на hr@agima.ru или мне в лс @WizAlx. Спасибо!
Что нужно делать:
✔️разрабатывать и оптимизировать микросервисы на Golang;
✔️работать с высоконагруженными системами и масштабируемыми решениями.
Что предлагаем:
✔️Формат работы: офис, удаленка, гибрид.
✔️Оформление: штат, ГПХ.
✔️График работы: 5/2.
✔️ДМС со стоматологией.
✔️Возможности для профессионального роста — в любом количестве.
✔️Масштабные проекты и здоровая рабочая атмосфера.
Подробнее о вакансии — на нашем сайте [тык].
Мы выплатим бонус, когда рекомендованный специалист пройдет испытательный срок в нашей команде — обычно это 3 месяца после первого рабочего дня.
Присылайте резюме подходящих кандидатов на hr@agima.ru или мне в лс @WizAlx. Спасибо!
👍1
У нас суперновость. Билеты на RUNIT 2025 уже в продаже: https://runit.digital
До Нового года осталось всего ничего, а значит, пора строить планы на 2025-й. Поэтому мы решили уже сейчас открыть регистрацию на следующий фестиваль IT и спорта RUNIT.
Пока выбираем оптимальную площадку и дату, но точно можем сказать: всё пройдет летом. И мы 100% учтем расписание крупных IT-конференций, чтобы вы могли везде успеть.
Что будет по-новому:
- теперь регистрируемся сразу в RussiaRunning — так вы сможете сами управлять регистрацией через личный кабинет;
- заявки от компаний и команд ждем на почте runit@agima.ru — для каждого участника тоже создадим личный кабинет;
- заказать гравировку на медали также можно заранее — такая опция на сайте RUNIT уже доступна при покупке билета.
В стоимость входят стартовый пакет с футболкой, чипом и подарками от партнеров, а также сама медаль (по умолчанию без гравировки). Ну и само собой, классное мероприятие для IT-рынка.
Так что готовим телегу зимой и планируем лето. Следить за новостями можно в телеграм-канале RUNIT.
До Нового года осталось всего ничего, а значит, пора строить планы на 2025-й. Поэтому мы решили уже сейчас открыть регистрацию на следующий фестиваль IT и спорта RUNIT.
Пока выбираем оптимальную площадку и дату, но точно можем сказать: всё пройдет летом. И мы 100% учтем расписание крупных IT-конференций, чтобы вы могли везде успеть.
Что будет по-новому:
- теперь регистрируемся сразу в RussiaRunning — так вы сможете сами управлять регистрацией через личный кабинет;
- заявки от компаний и команд ждем на почте runit@agima.ru — для каждого участника тоже создадим личный кабинет;
- заказать гравировку на медали также можно заранее — такая опция на сайте RUNIT уже доступна при покупке билета.
В стоимость входят стартовый пакет с футболкой, чипом и подарками от партнеров, а также сама медаль (по умолчанию без гравировки). Ну и само собой, классное мероприятие для IT-рынка.
Так что готовим телегу зимой и планируем лето. Следить за новостями можно в телеграм-канале RUNIT.
Какими бывают лидеры в IT и почему они тоже выгорают: https://clck.ru/3FSULp.
Недавно на митапе про управленцев в IT мы вместе с бизнес-тренером Алексеем Кельиным разбирали его исследование об органичном лидерстве. Оно, по сути, отвечает на вопрос: «Как руководителю найти органичный подход к лидерству, чтобы не выгорать и уберечь от этого своих сотрудников».
Судя по отзывам гостей митапа, эта тема тревожит многих. Поэтому мы решили собрать главные инсайты из исследования Алексея в одном материале.
Статья точно будет полезна СТО, руководителям IT-департаментов, руководителям IT-рекрутмента, IT-лидам и CPO — всем, кто отвечает за управление и развитие команд в IT.
Читайте текст на Хабре по ссылке выше и делитесь им с коллегами.
Недавно на митапе про управленцев в IT мы вместе с бизнес-тренером Алексеем Кельиным разбирали его исследование об органичном лидерстве. Оно, по сути, отвечает на вопрос: «Как руководителю найти органичный подход к лидерству, чтобы не выгорать и уберечь от этого своих сотрудников».
Судя по отзывам гостей митапа, эта тема тревожит многих. Поэтому мы решили собрать главные инсайты из исследования Алексея в одном материале.
Статья точно будет полезна СТО, руководителям IT-департаментов, руководителям IT-рекрутмента, IT-лидам и CPO — всем, кто отвечает за управление и развитие команд в IT.
Читайте текст на Хабре по ссылке выше и делитесь им с коллегами.
Хабр
Лидерами рождаются или становятся? Откуда берутся управленцы и лидеры в IT
Всем привет! Я Константин Мовчан, руководитель аутстаффинг-направления в AGIMA . За годы работы в IT я встречал многих руководителей, которые рано или поздно упираются в один вопрос: «Что лучше:...
Нанять нельзя вырастить: стоит ли прибегать к аутстаффингу, чтобы найти лидера для IT-команды? https://clck.ru/3FiaCS
Инвестировать время и ресурсы в выращивание лидеров внутри команды или оперативно найти готового специалиста через аутстаффинг? Секрет в том, что и тем и другим подходом можно умело пользоваться, если знать как.
Руководитель Outstaff-направления AGIMA Константин Мовчан поделился с редакцией «Бизнес-секретов» критериями успеха для обеих стратегий найма.
Статья получилась интересной: в ней и реальные кейсы, и большая сравнительная таблица с плюсами и минусами, и много практических советов.
Читайте материал по ссылке выше и делитесь своим мнением в комментариях!
Инвестировать время и ресурсы в выращивание лидеров внутри команды или оперативно найти готового специалиста через аутстаффинг? Секрет в том, что и тем и другим подходом можно умело пользоваться, если знать как.
Руководитель Outstaff-направления AGIMA Константин Мовчан поделился с редакцией «Бизнес-секретов» критериями успеха для обеих стратегий найма.
Статья получилась интересной: в ней и реальные кейсы, и большая сравнительная таблица с плюсами и минусами, и много практических советов.
Читайте материал по ссылке выше и делитесь своим мнением в комментариях!
Т-Бизнес секреты
Как выбрать лидера для IT-команды: аутстаффинг или найм?
Как найти эффективного лидера и руководителя для IT-команды: вырастить в компании или нанять через аутстаффинг? Разбираем плюсы и минусы каждого подхода, чтобы помочь вам принять правильное решение и избежать распространенных ошибок.
🔥5❤3👏2
Глава Sonos ушел в отставку после провального запуска приложения
Генеральный директор Sonos Патрик Спенс, который руководил компанией более десяти лет, объявил о своей отставке. Причиной стало катастрофическое обновление мобильного приложения, которое привело к огромным финансовым потерям и утрате доверия клиентов.
Под руководством Спенса Sonos выросла из небольшой компании в многомиллиардного производителя беспроводных наушников и колонок. Однако несколько месяцев назад всё пошло не так: выпуск полностью переработанного приложения на Flutter в «сыром» состоянии обернулся провалом.
Что пошло не так?
- Новое приложение сделало существующие продукты практически бесполезными.
- Пропали базовые функции, например одновременная регулировка громкости на нескольких колонках.
- Пользователи столкнулись с проблемами подключения и стабильности.
- App Store наводнили негативные отзывы, которые позже были удалены.
Спенс попытался спасти ситуацию и выпустил видео с извинениями. Но этого оказалось недостаточно. Он покинул пост с выходным пособием в $1,8 млн, что считается скромной суммой для CEO, который построил компанию с миллиардной капитализацией.
Технические причины провала
Основной проблемой стало чрезмерное использование облачных сервисов вместо локального подключения к устройствам.
Обвинять в случившемся начали даже сам Flutter, на котором было написано приложение. Но в реальности проблема крылась в измененной архитектуре. Проблема заключалась в том, что новое приложение стало слишком зависеть от облачных сервисов, и это усложнило взаимодействие между устройствами.
Разработчики не смогли (или не успели) должным образом протестировать и стабилизировать все новые функции, что привело к многочисленным проблемам со связью. Итого неготовность продукта к релизу и давление со стороны руководства сыграли роковую роль.
Что дальше?
Новый CEO уже уволил руководителя продукта, а компания пытается восстановить доверие клиентов. Однако этот случай стал ярким примером того, как спешка и игнорирование предупреждений инженеров могут привести к катастрофе.
Остается надеяться, что Sonos сможет вернуть былую славу. Но пока это один из самых громких провалов в истории технологических компаний.
Генеральный директор Sonos Патрик Спенс, который руководил компанией более десяти лет, объявил о своей отставке. Причиной стало катастрофическое обновление мобильного приложения, которое привело к огромным финансовым потерям и утрате доверия клиентов.
Под руководством Спенса Sonos выросла из небольшой компании в многомиллиардного производителя беспроводных наушников и колонок. Однако несколько месяцев назад всё пошло не так: выпуск полностью переработанного приложения на Flutter в «сыром» состоянии обернулся провалом.
Что пошло не так?
- Новое приложение сделало существующие продукты практически бесполезными.
- Пропали базовые функции, например одновременная регулировка громкости на нескольких колонках.
- Пользователи столкнулись с проблемами подключения и стабильности.
- App Store наводнили негативные отзывы, которые позже были удалены.
Спенс попытался спасти ситуацию и выпустил видео с извинениями. Но этого оказалось недостаточно. Он покинул пост с выходным пособием в $1,8 млн, что считается скромной суммой для CEO, который построил компанию с миллиардной капитализацией.
Технические причины провала
Основной проблемой стало чрезмерное использование облачных сервисов вместо локального подключения к устройствам.
Обвинять в случившемся начали даже сам Flutter, на котором было написано приложение. Но в реальности проблема крылась в измененной архитектуре. Проблема заключалась в том, что новое приложение стало слишком зависеть от облачных сервисов, и это усложнило взаимодействие между устройствами.
Разработчики не смогли (или не успели) должным образом протестировать и стабилизировать все новые функции, что привело к многочисленным проблемам со связью. Итого неготовность продукта к релизу и давление со стороны руководства сыграли роковую роль.
Что дальше?
Новый CEO уже уволил руководителя продукта, а компания пытается восстановить доверие клиентов. Однако этот случай стал ярким примером того, как спешка и игнорирование предупреждений инженеров могут привести к катастрофе.
Остается надеяться, что Sonos сможет вернуть былую славу. Но пока это один из самых громких провалов в истории технологических компаний.
👏7🤔6❤🔥1
bitrix-update-migrate-maker-master.zip
3.4 KB
Как обновить Битрикс методом миграций
Что потребуется прежде всего:
✅ Убрать ядро (папка /bitrix/) под гит, например, завернуть в сабмодуль.
✅ Отдельная тестовая площадка с отдельной и актуальной БД.
✅ Скрипт для очистки лога запросов в БД (архив прикреплен).
Дальше идем по процессу:
1. Переходим на тестовую площадку.
2. Включаем режим отладки БД:
3. Заходим на страницу обновления платформы и запускаем обновления: /bitrix/admin/update_system.php?lang=ru.
4. Очищаем лог-файл от лишнего с помощью скрипта.
5. Готовим миграцию.
6. Пушим всё в гит.
7. Выкатываем на прод изменения и запускаем миграцию.
Как подготовить миграцию
Файл mysql_debug.sql с логом изменений в БД довольно большого размера >50Mb. В нем есть и запросы, и время их выполнения, и stacktrace — в общем, много лишнего. Скрипт всё это вычищает и оставляет только запросы: в итоге вместо ~100Mb мы можем получить, например, ~300Kb.
Но скрипт неидеален и пока еще не очень умен. Поэтому финальный файл нужно провалидировать вручную — в лог могут попасть запросы отправки почтового события или еще что-нибудь лишнее.
📌Как работать со скриптом описано в файле readme в прикрепленном архиве.
Дальше берем очищенный файл и начинаем миграцию. Для этого отлично подойдет модуль sprint.migration:
🔹 Если запросов достаточно много (особенно, если вы обновляете несколько мажорных версий за раз), то хорошо бы разбить файл на чанки — по 50 запросов в 1 чанке.
🔹 Делаем миграцию с рестартами и оборачиваем запросы в транзакции. Обязательно добавьте логирование, чтобы потом можно было поработать с ошибками.
Финальный шаг
Когда вы всё обновили, зафиксили, подготовили миграцию и запушили в гит, проверьте всё еще раз. Тут рекомендуем проверить работу миграции на чистой площадке с БД до обновления. Если всё ок, то можете планировать обновление stage/prod окружений.
И помните: у самурая нет цели, только путь! 😉
Что потребуется прежде всего:
✅ Убрать ядро (папка /bitrix/) под гит, например, завернуть в сабмодуль.
✅ Отдельная тестовая площадка с отдельной и актуальной БД.
✅ Скрипт для очистки лога запросов в БД (архив прикреплен).
Дальше идем по процессу:
1. Переходим на тестовую площадку.
2. Включаем режим отладки БД:
//bitrix/php_interface/dbconn.php
$DBDebugToFile = true;
3. Заходим на страницу обновления платформы и запускаем обновления: /bitrix/admin/update_system.php?lang=ru.
4. Очищаем лог-файл от лишнего с помощью скрипта.
5. Готовим миграцию.
6. Пушим всё в гит.
7. Выкатываем на прод изменения и запускаем миграцию.
Как подготовить миграцию
Файл mysql_debug.sql с логом изменений в БД довольно большого размера >50Mb. В нем есть и запросы, и время их выполнения, и stacktrace — в общем, много лишнего. Скрипт всё это вычищает и оставляет только запросы: в итоге вместо ~100Mb мы можем получить, например, ~300Kb.
Но скрипт неидеален и пока еще не очень умен. Поэтому финальный файл нужно провалидировать вручную — в лог могут попасть запросы отправки почтового события или еще что-нибудь лишнее.
📌Как работать со скриптом описано в файле readme в прикрепленном архиве.
Дальше берем очищенный файл и начинаем миграцию. Для этого отлично подойдет модуль sprint.migration:
🔹 Если запросов достаточно много (особенно, если вы обновляете несколько мажорных версий за раз), то хорошо бы разбить файл на чанки — по 50 запросов в 1 чанке.
🔹 Делаем миграцию с рестартами и оборачиваем запросы в транзакции. Обязательно добавьте логирование, чтобы потом можно было поработать с ошибками.
Финальный шаг
Когда вы всё обновили, зафиксили, подготовили миграцию и запушили в гит, проверьте всё еще раз. Тут рекомендуем проверить работу миграции на чистой площадке с БД до обновления. Если всё ок, то можете планировать обновление stage/prod окружений.
И помните: у самурая нет цели, только путь! 😉
🔥11👍7❤1
Фон — это не просто бэкграунд, а важная часть дизайна, которая задает стиль и влияет на восприятие сайта. Делимся классной подборкой эффектов для фона на CSS — целых 40 вариантов: https://prismic.io/blog/css-background-effects.
В подборке куча категорий:
- кастомные фоны на CSS;
- градиенты;
- эффекты скролла;
- узоры и текстуры;
- SVG-эффекты;
- и другие крутые решения.
Еще отдельно выделены генераторы и разные библиотеки.
Можно взять готовый эффект или вдохновиться идеями для своих проектов. В общем, загляните!
Ссылочка: [тык]
В подборке куча категорий:
- кастомные фоны на CSS;
- градиенты;
- эффекты скролла;
- узоры и текстуры;
- SVG-эффекты;
- и другие крутые решения.
Еще отдельно выделены генераторы и разные библиотеки.
Можно взять готовый эффект или вдохновиться идеями для своих проектов. В общем, загляните!
Ссылочка: [тык]
👍3❤2🔥2
Семь ключевых ошибок тимлида (и как их не допускать): https://habr.com/ru/companies/agima/articles/884270/
Все тимлиды на заре карьеры встают на одни и те же грабли: кто-то начинает делать задачи вместо команды, кто-то ставит ТЗ как попало, а кто-то напрочь игнорирует техдолг.
Чтобы не допускать подобных ошибок, тимлид нашего отдела PHP Артем Валевич составил для себя что-то вроде кодекса, в котором перечислил самые вредные установки руководителя.
Всего получилось семь пунктов — простых, но в то же время важных. Разбираем и обсуждаем их на Хабре. Приходите почитать и поделиться опытом в комментариях.
Все тимлиды на заре карьеры встают на одни и те же грабли: кто-то начинает делать задачи вместо команды, кто-то ставит ТЗ как попало, а кто-то напрочь игнорирует техдолг.
Чтобы не допускать подобных ошибок, тимлид нашего отдела PHP Артем Валевич составил для себя что-то вроде кодекса, в котором перечислил самые вредные установки руководителя.
Всего получилось семь пунктов — простых, но в то же время важных. Разбираем и обсуждаем их на Хабре. Приходите почитать и поделиться опытом в комментариях.
👍13🔥4❤2😁1
💧NiFi Registry а-ля Git
Если вы работаете с Apache NiFi, то, скорее всего, сталкивались с проблемой контроля версий потоков данных. Здесь на помощь приходит NiFi Registry — инструмент для хранения, восстановления и управления версиями потоков. А с недавних пор появился способ контроля версий через Git. Давайте разберемся, как с ним работать и какие альтернативы есть у разработчиков.
Настройка родного реестра NiFi Registry
Для хранения версий потоков используется отдельный сервис реестра. Устанавливаем его рядом с NiFi, например, в контейнере (можно найти на просторах DockerHub с инструкцией установки и параметрами), открываем его Web UI по адресу
Далее в NiFi настраиваем клиент реестра: Controller Settings -> Registry Clients, выбираем
Это похоже на Git с коммитами, пулами и возможностью клонировать потоки из реестра — разница в том, что в NiFi Registry можно подтянуть конкретную группу процессоров, а не весь проект целиком.
GitLab как хранилище потоков
Альтернативный подход — хранить версии не в родном реестре, а в Git-репозитории (например, GitLab). В этом случае вместо NiFi Registry используется контроллер
Важно: NiFi не умеет создавать бакеты в GitLab, поэтому их нужно завести вручную — в виде папок в репозитории. JSON-файлы потоков загружаем через git commit - push. Затем можно клонировать их на рабочий холст в NiFi и использовать.
Как выглядит процесс работы:
1. Разработчик клонирует репозиторий, настраивает
2. Создает ветку, разрабатывает поток, экспортирует JSON в репозиторий (bucket2/flow.json).
3. Коммитит, пушит и создает merge request.
4. Ревьюеры клонируют поток, проверяют, вливают изменения в main.
5. На боевом NiFi можно подтянуть обновленный поток из мастера.
Этот же процесс работает и с GitHub.
Продвинутый вариант: родной реестр + GitLab
Можно настроить NiFi Registry для работы с GitLab. В конфиге
В итоге, у вас есть два варианта: использовать родной NiFi Registry или хранить версии в GitLab. Оба решения удобны, а выбор зависит от архитектуры проекта и команды. Какой подход вам ближе?
Если вы работаете с Apache NiFi, то, скорее всего, сталкивались с проблемой контроля версий потоков данных. Здесь на помощь приходит NiFi Registry — инструмент для хранения, восстановления и управления версиями потоков. А с недавних пор появился способ контроля версий через Git. Давайте разберемся, как с ним работать и какие альтернативы есть у разработчиков.
Настройка родного реестра NiFi Registry
Для хранения версий потоков используется отдельный сервис реестра. Устанавливаем его рядом с NiFi, например, в контейнере (можно найти на просторах DockerHub с инструкцией установки и параметрами), открываем его Web UI по адресу
http://localhost:18080/nifi-registry и создаем в настройках бакет — основную единицу для хранения и управления версиями.Далее в NiFi настраиваем клиент реестра: Controller Settings -> Registry Clients, выбираем
NifiRegistryFlowRegistryClient и устанавливаем настройку URL с адресом, прописанным до Web UI реестра: http://localhost:18080/nifi-registry. Теперь можно подключать процессорные группы к реестру через Version Control, выбирая бакет и имя версии. После коммита в реестр появится JSON-файл, а в интерфейсе NiFi — зеленая галочка, подтверждающая сохранение версии. Если внести изменения, можно откатиться к предыдущей версии или продолжить разработку.Это похоже на Git с коммитами, пулами и возможностью клонировать потоки из реестра — разница в том, что в NiFi Registry можно подтянуть конкретную группу процессоров, а не весь проект целиком.
GitLab как хранилище потоков
Альтернативный подход — хранить версии не в родном реестре, а в Git-репозитории (например, GitLab). В этом случае вместо NiFi Registry используется контроллер
GitLabFlowRegistryClient. Настройки схожи: указываем URL репозитория, access token, ветку и путь к папке с бакетами.Важно: NiFi не умеет создавать бакеты в GitLab, поэтому их нужно завести вручную — в виде папок в репозитории. JSON-файлы потоков загружаем через git commit - push. Затем можно клонировать их на рабочий холст в NiFi и использовать.
Как выглядит процесс работы:
1. Разработчик клонирует репозиторий, настраивает
GitLabFlowRegistryClient.2. Создает ветку, разрабатывает поток, экспортирует JSON в репозиторий (bucket2/flow.json).
3. Коммитит, пушит и создает merge request.
4. Ревьюеры клонируют поток, проверяют, вливают изменения в main.
5. На боевом NiFi можно подтянуть обновленный поток из мастера.
Этот же процесс работает и с GitHub.
Продвинутый вариант: родной реестр + GitLab
Можно настроить NiFi Registry для работы с GitLab. В конфиге
nifi-registry.properties подключаем GitLabFlowRegistryClient, а в самом NiFi — стандартный NifiRegistryFlowRegistryClient. Тогда реестр сам разберется, где хранить и откуда забирать версии.В итоге, у вас есть два варианта: использовать родной NiFi Registry или хранить версии в GitLab. Оба решения удобны, а выбор зависит от архитектуры проекта и команды. Какой подход вам ближе?
Apache NiFi
Registry
Apache NiFi is an easy to use, powerful, and reliable system to process and distribute data
🔥3
Незаменимых нет: про бас-фактор, или Что делать, если Вася Пупкин уйдет
В AGIMA мы ценим не только экспертизу, но и устойчивость процессов. Поэтому для всех позиций — от джуна до топ-менеджера — мы учитываем бас-фактор. Это значит, что если вдруг человек решит уйти в горы медитировать или неожиданно выиграет в лотерею, проекты и процессы должны продолжать двигаться вперед.
С первого дня работы нового специалиста мы думаем не только о его задачах, но и о передаче знаний. Документация, резервные точки, дублирующие компетенции — всё это помогает избежать ситуации, когда «без Васи вообще ничего не работает».
Мы не хотим превращать компанию в клуб знатоков, где ответы на важные вопросы есть только у одного человека. Поэтому процессы у нас настроены так, чтобы никто не был единственной точкой отказа. Отпуск, болезнь, смена работы — это не должно превратиться в аврал для команды.
Но мы реалисты и понимаем, что идеальная система возможна не всегда. Иногда человек уходит неожиданно, и тогда мы стараемся договориться о плавном переходе, чтобы он успел передать максимум знаний. Такие случаи довольно редки, но если происходят, важно не пытаться удержать человека любой ценой, а грамотно организовать передачу его компетенций. Мы ценим профессионализм и стараемся расставаться по-доброму, ведь наш рынок узкий: хороший специалист может вернуться, порекомендовать нас другим или стать нашим клиентом в будущем.
Поэтому бас-фактор — это не паранойя, а здравый смысл. Он позволяет бизнесу быть гибким, команде — уверенной в завтрашнем дне, а руководителям — спать спокойно.
А как устроено у вас? Думаете наперед или надеетесь, что ключевой человек вечно будет на своем месте?
В AGIMA мы ценим не только экспертизу, но и устойчивость процессов. Поэтому для всех позиций — от джуна до топ-менеджера — мы учитываем бас-фактор. Это значит, что если вдруг человек решит уйти в горы медитировать или неожиданно выиграет в лотерею, проекты и процессы должны продолжать двигаться вперед.
С первого дня работы нового специалиста мы думаем не только о его задачах, но и о передаче знаний. Документация, резервные точки, дублирующие компетенции — всё это помогает избежать ситуации, когда «без Васи вообще ничего не работает».
Мы не хотим превращать компанию в клуб знатоков, где ответы на важные вопросы есть только у одного человека. Поэтому процессы у нас настроены так, чтобы никто не был единственной точкой отказа. Отпуск, болезнь, смена работы — это не должно превратиться в аврал для команды.
Но мы реалисты и понимаем, что идеальная система возможна не всегда. Иногда человек уходит неожиданно, и тогда мы стараемся договориться о плавном переходе, чтобы он успел передать максимум знаний. Такие случаи довольно редки, но если происходят, важно не пытаться удержать человека любой ценой, а грамотно организовать передачу его компетенций. Мы ценим профессионализм и стараемся расставаться по-доброму, ведь наш рынок узкий: хороший специалист может вернуться, порекомендовать нас другим или стать нашим клиентом в будущем.
Поэтому бас-фактор — это не паранойя, а здравый смысл. Он позволяет бизнесу быть гибким, команде — уверенной в завтрашнем дне, а руководителям — спать спокойно.
А как устроено у вас? Думаете наперед или надеетесь, что ключевой человек вечно будет на своем месте?
👍6❤3
Монолит на чистой архитектуре — зачем он вам: https://habr.com/ru/companies/agima/articles/889962/
Классная идея — завершить вторник сложной технической статьей от нашего заместителя CTO Павла Лукьянова. Он как раз рассказал на Хабре об опыте работы с чистой архитектурой.
В тексте всё самое важное:
- зачем вообще выбрали такой подход;
- как он себя показал на практике;
- какие паттерны использовали на проекте;
- почему аналитики не были в восторге.
Если команда разработки и бизнес-заказчик говорят на разных языках и не понимают друг друга — это точно маст-рид. Ждем по ссылке выше тимлидов и senior-разработчиков.
Классная идея — завершить вторник сложной технической статьей от нашего заместителя CTO Павла Лукьянова. Он как раз рассказал на Хабре об опыте работы с чистой архитектурой.
В тексте всё самое важное:
- зачем вообще выбрали такой подход;
- как он себя показал на практике;
- какие паттерны использовали на проекте;
- почему аналитики не были в восторге.
Если команда разработки и бизнес-заказчик говорят на разных языках и не понимают друг друга — это точно маст-рид. Ждем по ссылке выше тимлидов и senior-разработчиков.
Хабр
Почему мы построили монолит на чистой архитектуре. И почему это взбесило системных аналитиков
Привет! Меня зовут Павел Лукьянов, я заместитель CTO в AGIMA . На одной из прошлых работ мы с ребятами попробовали внедрить так называемую чистую архитектуру на монолитном проекте. И это был...
❤7👍3🔥2
🤝Сила благодарности: почему важно говорить «спасибо»
Разве не приятно, когда кто-то по-настоящему ценит ваш труд и находит время сказать «спасибо»? Некоторые считают, что зарплата — единственная необходимая благодарность. Но позвольте не согласиться: простое выражение признательности ничего не стоит, но может создать крепкие рабочие отношения.
Почему это важно
Материальная мотивация (зарплата, бонусы) работает, но эффект со временем, как правило, снижается. При этом культура благодарности формирует высокий уровень доверия и вовлеченности в процесс. Если сотрудники открыты, мы быстрее узнаем о проблемах и сложностях и можем оперативно принять меры, чтобы улучшить ситуацию.
Как благодарить, чтобы всем было хорошо
✔️ Будьте конкретны. «Спасибо за работу» иногда звучит как формальность. Лучше сказать, за что именно вы благодарите. Детали добавляют искренности и ценности. Например: «Спасибо, что доверился интуиции, и мы наконец-то локализовали эту плавающую проблему до отправки релиза заказчику».
✔️ Не откладывайте. Благодарность имеет «срок годности». Лучше скажите спасибо сразу, чем потом,когда забудете. Например, коллега помог с авралом. Поблагодарите его в тот же день — в идеале, если уместно, в присутствии команды на очередном скрам-дейлике.
✔️ Замечайте мелочи. Важно ценить не только большие достижения, но и повседневные проявления доброты, надежности и взаимопомощи. Кто-то помог новичку разобраться с документами, взял на себя внеурочное дежурство или скинул мем после тяжелого созвона. Всё это часто остается невидимым, но хорошо влияет на командный дух.
✔️ Покажите влияние. Всегда объясняйте, как и какие действия специалиста повлияли на общую картину. Расскажите, как сотрудник помог достичь общих командных целей и/или целей проекта и компании.
Как сказал Джон Гордон: «Когда вы ощущаете благодарность, у вас нет времени на стресс».
А как у вас в команде? Есть ли культура благодарности и какие-то традиции, связанные с этим? Или считаете, что лучшая благодарность — это деньги?
Разве не приятно, когда кто-то по-настоящему ценит ваш труд и находит время сказать «спасибо»? Некоторые считают, что зарплата — единственная необходимая благодарность. Но позвольте не согласиться: простое выражение признательности ничего не стоит, но может создать крепкие рабочие отношения.
Почему это важно
Материальная мотивация (зарплата, бонусы) работает, но эффект со временем, как правило, снижается. При этом культура благодарности формирует высокий уровень доверия и вовлеченности в процесс. Если сотрудники открыты, мы быстрее узнаем о проблемах и сложностях и можем оперативно принять меры, чтобы улучшить ситуацию.
Как благодарить, чтобы всем было хорошо
✔️ Будьте конкретны. «Спасибо за работу» иногда звучит как формальность. Лучше сказать, за что именно вы благодарите. Детали добавляют искренности и ценности. Например: «Спасибо, что доверился интуиции, и мы наконец-то локализовали эту плавающую проблему до отправки релиза заказчику».
✔️ Не откладывайте. Благодарность имеет «срок годности». Лучше скажите спасибо сразу, чем потом,
✔️ Замечайте мелочи. Важно ценить не только большие достижения, но и повседневные проявления доброты, надежности и взаимопомощи. Кто-то помог новичку разобраться с документами, взял на себя внеурочное дежурство или скинул мем после тяжелого созвона. Всё это часто остается невидимым, но хорошо влияет на командный дух.
✔️ Покажите влияние. Всегда объясняйте, как и какие действия специалиста повлияли на общую картину. Расскажите, как сотрудник помог достичь общих командных целей и/или целей проекта и компании.
Как сказал Джон Гордон: «Когда вы ощущаете благодарность, у вас нет времени на стресс».
А как у вас в команде? Есть ли культура благодарности и какие-то традиции, связанные с этим? Или считаете, что лучшая благодарность — это деньги?
👍4❤3🔥2
ByteDance представила Lynx — новый фреймворк для кросс-платформенной разработки
Компания ByteDance, создатель TikTok, решила зайти на территорию кросс-платформенной разработки и представила Lynx. Это open-source фреймворк, который позволяет веб-разработчикам писать нативные интерфейсы для iOS, Android и веб с помощью привычных технологий.
В чем фишка Lynx
- Один код — все платформы. Не нужно писать отдельные версии для мобильных приложений и веба.
- Высокая производительность. Используются Rust и многопоточная архитектура для плавного UI.
- Нативный CSS. Можно стилизовать интерфейс так же, как в вебе.
- ReactLynx. Интеграция с React для удобного использования в веб-проектах.
Чем отличается от Flutter и React Native
ByteDance делает ставку на скорость и удобство. В отличие от React Native, здесь обещают лучшую производительность, а в сравнении с Flutter — привычный для веб-разработчиков подход без необходимости учить Dart.
Почему стоит попробовать
Если вы веб-разработчик и хотите быстро делать мобильные приложения без изучения новых языков — Lynx может быть отличным выбором. Проект уже доступен на GitHub и официальном сайте.
Делитесь впечатлениями, если уже успели попробовать Lynx.
Компания ByteDance, создатель TikTok, решила зайти на территорию кросс-платформенной разработки и представила Lynx. Это open-source фреймворк, который позволяет веб-разработчикам писать нативные интерфейсы для iOS, Android и веб с помощью привычных технологий.
В чем фишка Lynx
- Один код — все платформы. Не нужно писать отдельные версии для мобильных приложений и веба.
- Высокая производительность. Используются Rust и многопоточная архитектура для плавного UI.
- Нативный CSS. Можно стилизовать интерфейс так же, как в вебе.
- ReactLynx. Интеграция с React для удобного использования в веб-проектах.
Чем отличается от Flutter и React Native
ByteDance делает ставку на скорость и удобство. В отличие от React Native, здесь обещают лучшую производительность, а в сравнении с Flutter — привычный для веб-разработчиков подход без необходимости учить Dart.
Почему стоит попробовать
Если вы веб-разработчик и хотите быстро делать мобильные приложения без изучения новых языков — Lynx может быть отличным выбором. Проект уже доступен на GitHub и официальном сайте.
Делитесь впечатлениями, если уже успели попробовать Lynx.
👍9✍2
«Через год мы можем оказаться в мире, где ИИ будет писать практически весь код», — заявил исследователь искусственного интеллекта и предприниматель Дарио Амодей на конференции Council on Foreign Relations в марте.
Заявление громкое, поэтому мы решили поговорить на эту тему с виновником холивара — ИИ в лице DeepSeek. Вот что получилось:
Как ты считаешь, разработчики останутся без работы из-за ИИ?
Вряд ли, но их роль и задачи значительно трансформируются. Вот ключевые моменты:
🔹Автоматизация рутины: ИИ (например, GitHub Copilot, ChatGPT) упрощает написание шаблонного кода, тестирование и документирование. Это освобождает время для более сложных задач, но не заменяет инженерное мышление.
🔹Усиление креативности: разработчики смогут фокусироваться на проектировании архитектуры, оптимизации пользовательского опыта и решении уникальных бизнес-задач, где требуется человеческая интуиция и креативность.
🔹Новые специализации: появятся роли вроде инженера по промптам, специалиста по интеграции ИИ-моделей или эксперта по этике ИИ. Спрос на навыки работы с ML/AI-инструментами вырастет.
🔹Эволюция, а не замена: исторически технологии (компиляторы, фреймворки, облака) не заменяли разработчиков, а повышали их эффективность. ИИ станет таким же инструментом, как и предыдущие инновации.
Какие риски и серые зоны ты видишь в разработке с применением ИИ?
Есть несколько аспектов, которые стоит учитывать:
🔹 Утрата глубины знаний: разработчики разучатся писать код без ИИ, теряя понимание основ.
🔹 Шаблонность: ИИ часто предлагает типовые решения, но не самые инновационные варианты.
🔹 Вопросы безопасности: есть риск генерации небезопасных участков кода — например, подверженных SQL-инъекциям, с плохой аутентификацией.
🔹 Этика и авторские права: возникают сложности с пониманием, кому принадлежит код, созданный ИИ, особенно если он напоминает чей-то чужой код из тренировочной базы данных.
🔹 Проблема прозрачности: как честно объяснить заказчику, что значительная часть работы выполнена нейросетью.
Дай совет, что делать, чтобы не оказаться без работы в ближайшее время.
Сделайте ИИ своим напарником, а не соперником. Используйте его как ускоритель — пусть генерирует шаблоны или ищет баги, но не делегируйте ему всё. Ваша фишка — глубокая экспертиза: архитектура, нестандартные задачи и «человеческое», то есть переговоры, менторство, креатив. Учитесь там, где ИИ слаб: DevOps, кибербезопасность, этика ИИ. И да, создавайте свой open-source или блог — нейросеть не придумает вашу уникальную историю.
А что думаете вы? Доверяете ИИ в задачах, связанных с генерацией кода? Какие инструменты уже используете в своей работе?
Заявление громкое, поэтому мы решили поговорить на эту тему с виновником холивара — ИИ в лице DeepSeek. Вот что получилось:
Как ты считаешь, разработчики останутся без работы из-за ИИ?
Вряд ли, но их роль и задачи значительно трансформируются. Вот ключевые моменты:
🔹Автоматизация рутины: ИИ (например, GitHub Copilot, ChatGPT) упрощает написание шаблонного кода, тестирование и документирование. Это освобождает время для более сложных задач, но не заменяет инженерное мышление.
🔹Усиление креативности: разработчики смогут фокусироваться на проектировании архитектуры, оптимизации пользовательского опыта и решении уникальных бизнес-задач, где требуется человеческая интуиция и креативность.
🔹Новые специализации: появятся роли вроде инженера по промптам, специалиста по интеграции ИИ-моделей или эксперта по этике ИИ. Спрос на навыки работы с ML/AI-инструментами вырастет.
🔹Эволюция, а не замена: исторически технологии (компиляторы, фреймворки, облака) не заменяли разработчиков, а повышали их эффективность. ИИ станет таким же инструментом, как и предыдущие инновации.
Какие риски и серые зоны ты видишь в разработке с применением ИИ?
Есть несколько аспектов, которые стоит учитывать:
🔹 Утрата глубины знаний: разработчики разучатся писать код без ИИ, теряя понимание основ.
🔹 Шаблонность: ИИ часто предлагает типовые решения, но не самые инновационные варианты.
🔹 Вопросы безопасности: есть риск генерации небезопасных участков кода — например, подверженных SQL-инъекциям, с плохой аутентификацией.
🔹 Этика и авторские права: возникают сложности с пониманием, кому принадлежит код, созданный ИИ, особенно если он напоминает чей-то чужой код из тренировочной базы данных.
🔹 Проблема прозрачности: как честно объяснить заказчику, что значительная часть работы выполнена нейросетью.
Дай совет, что делать, чтобы не оказаться без работы в ближайшее время.
Сделайте ИИ своим напарником, а не соперником. Используйте его как ускоритель — пусть генерирует шаблоны или ищет баги, но не делегируйте ему всё. Ваша фишка — глубокая экспертиза: архитектура, нестандартные задачи и «человеческое», то есть переговоры, менторство, креатив. Учитесь там, где ИИ слаб: DevOps, кибербезопасность, этика ИИ. И да, создавайте свой open-source или блог — нейросеть не придумает вашу уникальную историю.
А что думаете вы? Доверяете ИИ в задачах, связанных с генерацией кода? Какие инструменты уже используете в своей работе?
👍10
База про жизненный цикл разработки ПО (SDLC): этапы, виды моделей и их различия:
https://habr.com/ru/companies/kaiten/articles/893866/
Тут коллеги из Kaiten выпустили статью с разбором Software Development Life Cycle (SDLC), или жизненного цикла разработки. Мы тоже поучаствовали: рассказали, как в AGIMA выстроен процесс разработки и как мы управляем командой.
Статья будет полезна разработчикам, менеджерам, продакт-оунерам и всем, кто хочет разобраться в нюансах SDLC и выбрать оптимальный подход.
Текст уже на Хабре — читайте его по ссылке выше.
https://habr.com/ru/companies/kaiten/articles/893866/
Тут коллеги из Kaiten выпустили статью с разбором Software Development Life Cycle (SDLC), или жизненного цикла разработки. Мы тоже поучаствовали: рассказали, как в AGIMA выстроен процесс разработки и как мы управляем командой.
Статья будет полезна разработчикам, менеджерам, продакт-оунерам и всем, кто хочет разобраться в нюансах SDLC и выбрать оптимальный подход.
Текст уже на Хабре — читайте его по ссылке выше.
👍5❤3