«Через год мы можем оказаться в мире, где ИИ будет писать практически весь код», — заявил исследователь искусственного интеллекта и предприниматель Дарио Амодей на конференции Council on Foreign Relations в марте.
Заявление громкое, поэтому мы решили поговорить на эту тему с виновником холивара — ИИ в лице DeepSeek. Вот что получилось:
Как ты считаешь, разработчики останутся без работы из-за ИИ?
Вряд ли, но их роль и задачи значительно трансформируются. Вот ключевые моменты:
🔹Автоматизация рутины: ИИ (например, GitHub Copilot, ChatGPT) упрощает написание шаблонного кода, тестирование и документирование. Это освобождает время для более сложных задач, но не заменяет инженерное мышление.
🔹Усиление креативности: разработчики смогут фокусироваться на проектировании архитектуры, оптимизации пользовательского опыта и решении уникальных бизнес-задач, где требуется человеческая интуиция и креативность.
🔹Новые специализации: появятся роли вроде инженера по промптам, специалиста по интеграции ИИ-моделей или эксперта по этике ИИ. Спрос на навыки работы с ML/AI-инструментами вырастет.
🔹Эволюция, а не замена: исторически технологии (компиляторы, фреймворки, облака) не заменяли разработчиков, а повышали их эффективность. ИИ станет таким же инструментом, как и предыдущие инновации.
Какие риски и серые зоны ты видишь в разработке с применением ИИ?
Есть несколько аспектов, которые стоит учитывать:
🔹 Утрата глубины знаний: разработчики разучатся писать код без ИИ, теряя понимание основ.
🔹 Шаблонность: ИИ часто предлагает типовые решения, но не самые инновационные варианты.
🔹 Вопросы безопасности: есть риск генерации небезопасных участков кода — например, подверженных SQL-инъекциям, с плохой аутентификацией.
🔹 Этика и авторские права: возникают сложности с пониманием, кому принадлежит код, созданный ИИ, особенно если он напоминает чей-то чужой код из тренировочной базы данных.
🔹 Проблема прозрачности: как честно объяснить заказчику, что значительная часть работы выполнена нейросетью.
Дай совет, что делать, чтобы не оказаться без работы в ближайшее время.
Сделайте ИИ своим напарником, а не соперником. Используйте его как ускоритель — пусть генерирует шаблоны или ищет баги, но не делегируйте ему всё. Ваша фишка — глубокая экспертиза: архитектура, нестандартные задачи и «человеческое», то есть переговоры, менторство, креатив. Учитесь там, где ИИ слаб: DevOps, кибербезопасность, этика ИИ. И да, создавайте свой open-source или блог — нейросеть не придумает вашу уникальную историю.
А что думаете вы? Доверяете ИИ в задачах, связанных с генерацией кода? Какие инструменты уже используете в своей работе?
Заявление громкое, поэтому мы решили поговорить на эту тему с виновником холивара — ИИ в лице DeepSeek. Вот что получилось:
Как ты считаешь, разработчики останутся без работы из-за ИИ?
Вряд ли, но их роль и задачи значительно трансформируются. Вот ключевые моменты:
🔹Автоматизация рутины: ИИ (например, GitHub Copilot, ChatGPT) упрощает написание шаблонного кода, тестирование и документирование. Это освобождает время для более сложных задач, но не заменяет инженерное мышление.
🔹Усиление креативности: разработчики смогут фокусироваться на проектировании архитектуры, оптимизации пользовательского опыта и решении уникальных бизнес-задач, где требуется человеческая интуиция и креативность.
🔹Новые специализации: появятся роли вроде инженера по промптам, специалиста по интеграции ИИ-моделей или эксперта по этике ИИ. Спрос на навыки работы с ML/AI-инструментами вырастет.
🔹Эволюция, а не замена: исторически технологии (компиляторы, фреймворки, облака) не заменяли разработчиков, а повышали их эффективность. ИИ станет таким же инструментом, как и предыдущие инновации.
Какие риски и серые зоны ты видишь в разработке с применением ИИ?
Есть несколько аспектов, которые стоит учитывать:
🔹 Утрата глубины знаний: разработчики разучатся писать код без ИИ, теряя понимание основ.
🔹 Шаблонность: ИИ часто предлагает типовые решения, но не самые инновационные варианты.
🔹 Вопросы безопасности: есть риск генерации небезопасных участков кода — например, подверженных SQL-инъекциям, с плохой аутентификацией.
🔹 Этика и авторские права: возникают сложности с пониманием, кому принадлежит код, созданный ИИ, особенно если он напоминает чей-то чужой код из тренировочной базы данных.
🔹 Проблема прозрачности: как честно объяснить заказчику, что значительная часть работы выполнена нейросетью.
Дай совет, что делать, чтобы не оказаться без работы в ближайшее время.
Сделайте ИИ своим напарником, а не соперником. Используйте его как ускоритель — пусть генерирует шаблоны или ищет баги, но не делегируйте ему всё. Ваша фишка — глубокая экспертиза: архитектура, нестандартные задачи и «человеческое», то есть переговоры, менторство, креатив. Учитесь там, где ИИ слаб: DevOps, кибербезопасность, этика ИИ. И да, создавайте свой open-source или блог — нейросеть не придумает вашу уникальную историю.
А что думаете вы? Доверяете ИИ в задачах, связанных с генерацией кода? Какие инструменты уже используете в своей работе?
База про жизненный цикл разработки ПО (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 и выбрать оптимальный подход.
Текст уже на Хабре — читайте его по ссылке выше.
Хабр
База про жизненный цикл разработки ПО (SDLC): этапы, виды моделей и их различия
Software Development Life Cycle (SDLC) — это фундамент, на котором строится разработка. Он помогает выстроить процессы так, чтобы команда четко понимала, что и когда ей нужно делать, а заказчик знал,...
Что делать, если разработчик работает хорошо, но очень медленно: https://habr.com/ru/companies/agima/articles/895046/
У каждого свой темп: кто-то пишет код быстро, а кто-то подолгу залипает на каждой задаче. Тимлиду же нужно находить общий язык с каждым, хоть это и бывает непросто.
Наша новая статья как раз о том, как выстроить рабочий процесс, если какой-то разработчик сильно отстает от остальных. А еще о том, что это может говорить о проекте в целом.
Ее написал наш PHP-тимлид Александр Борщев. Он делится личным опытом и предлагает всем рассказывать о своих лайфхаках. Текст уже в блоге, ссылку оставили выше.
У каждого свой темп: кто-то пишет код быстро, а кто-то подолгу залипает на каждой задаче. Тимлиду же нужно находить общий язык с каждым, хоть это и бывает непросто.
Наша новая статья как раз о том, как выстроить рабочий процесс, если какой-то разработчик сильно отстает от остальных. А еще о том, что это может говорить о проекте в целом.
Ее написал наш PHP-тимлид Александр Борщев. Он делится личным опытом и предлагает всем рассказывать о своих лайфхаках. Текст уже в блоге, ссылку оставили выше.
Хабр
Что делать, если разработчик работает хорошо, но очень медленно
Всем привет! Меня зовут Александр Борщев, я тимлид в компании AGIMA . В нашей команде работают разработчики с разными темпами работы, а одной из ключевых задач тимлида является умение находить общий...
Filament — лучшая админка для Laravel
И так считаем не только мы. В конце прошлого года в одном из крупнейших российских сообществ Laravel прошел опрос о лучших админках, и победителем стал Filament, хоть и с небольшим отрывом.
Мы всеми руками за такой выбор, потому что сейчас очень часто внедряем Filament на проектах, и он еще не подводил. Но за всё время мы перепробовали разные админки и смело можем выделить их плюсы и минусы. Давайте посмотрим на примерах.
Twill
Почему выбрали: достался по наследству с одного из проектов.
➕ Плюсы:
- Open source.
- Был успешно опробован в продакшене.
- Подходит для простых проектов.
- Удобный WYSIWYG и блочный редактор для лендингов.
⛔️ Минусы:
- Много копипаста и переопределений стандартных полей, поэтому не хватает гибкости.
Aimeos
Почему выбрали: случайный ресерч, неплохая документация, на входе показал себя хорошо.
➕ Плюсы:
- Open source.
- Подходит для стандартных магазинов и каталогов (привет, Битрикс!).
⛔️ Минусы:
- Для кастомизации связей между моделями приходится писать нативный SQL-код, а это совсем не Laravel way :)
Voyager
Почему выбрали: давно знали, но не пробовали в продакшене. Популярное решение в сообществе Laravel.
➕ Плюсы:
- Open source.
- Популярность и активное сообщество.
- Фронт админки на шаблонизаторе Blade + jQuery, что дает большую гибкость в интерфейсе.
⛔️ Минусы:
- За эту гибкость на фронте приходится платить: для реализации связей между полями в интерфейсе админки (реактивности) нужно писать много кода на jQuery.
Filament
Почему выбрали: случайно нашли в ходе ресерча под требования проекта.
➕ Плюсы:
- Open source.
- Много инструментов и связей для реактивного поведения в интерфейсе админки.
- Полностью Laravel way, позволяет раскрыть всю гибкость фреймворка со стороны админки.
- Чтобы расставить элементы управления (кнопки, менюшки, лого и т. д.), знать фронтенд не обязательно — всё пишется на PHP.
- Темная тема из коробки
- Топ-админка по версии сообщества Laravel.
⛔️ Минусы:
- Если на странице много связанных элементов, возможны лаги в интерфейсе.
- Если нужен глубокий кастом, придется разобраться с Livewire.
Подробнее о работе с Filament писал на Хабре наш коллега Егор Черненок
И так считаем не только мы. В конце прошлого года в одном из крупнейших российских сообществ Laravel прошел опрос о лучших админках, и победителем стал Filament, хоть и с небольшим отрывом.
Мы всеми руками за такой выбор, потому что сейчас очень часто внедряем Filament на проектах, и он еще не подводил. Но за всё время мы перепробовали разные админки и смело можем выделить их плюсы и минусы. Давайте посмотрим на примерах.
Twill
Почему выбрали: достался по наследству с одного из проектов.
- Open source.
- Был успешно опробован в продакшене.
- Подходит для простых проектов.
- Удобный WYSIWYG и блочный редактор для лендингов.
- Много копипаста и переопределений стандартных полей, поэтому не хватает гибкости.
Aimeos
Почему выбрали: случайный ресерч, неплохая документация, на входе показал себя хорошо.
- Open source.
- Подходит для стандартных магазинов и каталогов (привет, Битрикс!).
- Для кастомизации связей между моделями приходится писать нативный SQL-код, а это совсем не Laravel way :)
Voyager
Почему выбрали: давно знали, но не пробовали в продакшене. Популярное решение в сообществе Laravel.
- Open source.
- Популярность и активное сообщество.
- Фронт админки на шаблонизаторе Blade + jQuery, что дает большую гибкость в интерфейсе.
- За эту гибкость на фронте приходится платить: для реализации связей между полями в интерфейсе админки (реактивности) нужно писать много кода на jQuery.
Filament
Почему выбрали: случайно нашли в ходе ресерча под требования проекта.
- Open source.
- Много инструментов и связей для реактивного поведения в интерфейсе админки.
- Полностью Laravel way, позволяет раскрыть всю гибкость фреймворка со стороны админки.
- Чтобы расставить элементы управления (кнопки, менюшки, лого и т. д.), знать фронтенд не обязательно — всё пишется на PHP.
- Темная тема из коробки
- Топ-админка по версии сообщества Laravel.
- Если на странице много связанных элементов, возможны лаги в интерфейсе.
- Если нужен глубокий кастом, придется разобраться с Livewire.
Подробнее о работе с Filament писал на Хабре наш коллега Егор Черненок
Please open Telegram to view this post
VIEW IN TELEGRAM
В этом году мы решили основательно подготовиться к 1 апреля. У нас давно зрела идея завируситься в соцсетях и медиа с каким-нибудь безумным инфоповодом. И в этом году — в порядке эксперимента — рискнули это сделать. Эффект получился мощнее, чем мы ожидали.
Идея состояла в том, чтобы запустить на полном серьезе утку, якобы в AGIMA заставляют новичков делать татуировки с логотипом компании.
Цели у этой кампании было две:
- рассказать о себе тем, кто про нас ничего не слышал;
- проверить, как далеко может улететь такая новость.
Реализовать план нам помог наш друг Влад Савин из компании R77 AI. Он согласился снять видео в жанре «Скандалы, интриги, расследования» и растиражировать его через свои каналы. О том, как это было, он уже написал отдельную статью. Спасибо, Влад!
В итоге новость подхватили десятки отраслевых каналов и чатов, про нас написали несколько тематических сообществ, текст провисел на главной странице VC целый день, а общий охват кампании перевалил за 100 тысяч.
Для сравнения: если в обычный день наш хендбук читает около 100 человек, то 1 апреля его посетило более 3000. Иными словами, конверсия выросла в 30 раз. И это всё при нулевом бюджете на продвижение.
Спасибо всем, кто помог реализовать задумку. Это был классный эксперимент, мы получили кучу приятной обратной связи и прочитали много интересных комментариев. А главное, напомнили всем, что к выбору татуировки важно подходить вдумчиво 😉
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
AGIMA — СЕКТА! Расследования в IT
https://www.agima.ru/projects/handbook/ — ИХ ХЭНДБУК
Подписывайтесь на мой канал с расследованиями: https://t.me/vladsavin
Спонсор ролика — разработчик AI-продуктов R77 AI: https://t.me/r77_ai
Подписывайтесь на мой канал с расследованиями: https://t.me/vladsavin
Спонсор ролика — разработчик AI-продуктов R77 AI: https://t.me/r77_ai
Сначала посмотрите на наших питомцев, а потом на вот этот сайт: https://itdog.agima.ru
Мы запускаем новый проект для IT-компаний — «Код и пес». В чем суть: 27 апреля собираем неравнодушных людей из IT и все вместе едем в собачий приют «Щербинка».
Что будем делать:
- покормим собак и погуляем с ними под присмотром волонтеров;
- передадим в приют всё, что требуется: от корма до лекарств;
- а после этого доедем до офиса AGIMA, чтобы отдохнуть и поиграть.
Хотим устроить максимально расслабленный и интересный день: погулять, пообщаться и сделать доброе дело. И зовем всех желающих поехать с нами!
🐾 Все подробности о поездке вы найдете по ссылке выше. С вас хорошее настроение и готовность общаться, с нас — классные фотографии и афтерпати в офисе.
Информационный партнер проекта: Hi-Tech Mail
Мы запускаем новый проект для IT-компаний — «Код и пес». В чем суть: 27 апреля собираем неравнодушных людей из IT и все вместе едем в собачий приют «Щербинка».
Что будем делать:
- покормим собак и погуляем с ними под присмотром волонтеров;
- передадим в приют всё, что требуется: от корма до лекарств;
- а после этого доедем до офиса AGIMA, чтобы отдохнуть и поиграть.
Хотим устроить максимально расслабленный и интересный день: погулять, пообщаться и сделать доброе дело. И зовем всех желающих поехать с нами!
🐾 Все подробности о поездке вы найдете по ссылке выше. С вас хорошее настроение и готовность общаться, с нас — классные фотографии и афтерпати в офисе.
Информационный партнер проекта: Hi-Tech Mail
📋Стратегия тестирования: нужна или нет?
Согласно сертификации ISTQB, стратегия тестирования должна отвечать на все вопросы — что, как, когда и зачем тестировать. Звучит серьезно, фундаментально… Но на практике на стандартном проекте, где есть бэк, мобилка и спринты, чаще всего получается так:
— Что тестим? Всё.
— Как? Руками, плюс немного техники тест-дизайна.
— Когда? По мере готовности задач.
— Зачем? Чтобы клиенты не страдали, а бизнес зарабатывал.
На этом фоне рождается документ под названием «Мистер Очевидность». Это такие стратегии на 3–4 страницы, с подписями и ревью, которые никто не открывает после апрува. То есть формально стратегия есть, но в реальности команда ей не пользуется.
Мы стараемся делать проще:
✅ Вместо регламента на 10 пунктов записываем короткое онбординг-видео.
✅ Все важные вещи заносим прямо в таск-трекер: обязательные поля в баг-репортах, DoR и DoD, ограничения на переходы по статусам задач. Хочешь обойти процесс? Не выйдет — система не даст.
Когда новый человек приходит в команду, он не знает всего сразу, и это нормально. Но у него есть видео, есть ментор, и есть трекер, который направит. Через пару дней он уже чувствует себя уверенно. Поэтому лучше выстраивать юзер-френдли процесс, а не соревнования «кто знает больше регламентов».
🤔 Но что насчет критериев приемки задач и нефункциональных требований, типа кросс-браузерности и версионирования? Их обязательно нужно фиксировать, но не в стратегии, а в ТЗ системы. Дублировать смысла нет — там этим и так управляют.
Вывод простой: стратегия будет работать, только если встроить ее в живой процесс. Либо она вшита в инструменты, либо существует с гарантом, который следит за ее соблюдением. А если нет ни того, ни другого — возможно, вам в целом стоит отказаться от стратегии.
Согласно сертификации ISTQB, стратегия тестирования должна отвечать на все вопросы — что, как, когда и зачем тестировать. Звучит серьезно, фундаментально… Но на практике на стандартном проекте, где есть бэк, мобилка и спринты, чаще всего получается так:
— Что тестим? Всё.
— Как? Руками, плюс немного техники тест-дизайна.
— Когда? По мере готовности задач.
— Зачем? Чтобы клиенты не страдали, а бизнес зарабатывал.
На этом фоне рождается документ под названием «Мистер Очевидность». Это такие стратегии на 3–4 страницы, с подписями и ревью, которые никто не открывает после апрува. То есть формально стратегия есть, но в реальности команда ей не пользуется.
Мы стараемся делать проще:
✅ Вместо регламента на 10 пунктов записываем короткое онбординг-видео.
✅ Все важные вещи заносим прямо в таск-трекер: обязательные поля в баг-репортах, DoR и DoD, ограничения на переходы по статусам задач. Хочешь обойти процесс? Не выйдет — система не даст.
Когда новый человек приходит в команду, он не знает всего сразу, и это нормально. Но у него есть видео, есть ментор, и есть трекер, который направит. Через пару дней он уже чувствует себя уверенно. Поэтому лучше выстраивать юзер-френдли процесс, а не соревнования «кто знает больше регламентов».
🤔 Но что насчет критериев приемки задач и нефункциональных требований, типа кросс-браузерности и версионирования? Их обязательно нужно фиксировать, но не в стратегии, а в ТЗ системы. Дублировать смысла нет — там этим и так управляют.
Вывод простой: стратегия будет работать, только если встроить ее в живой процесс. Либо она вшита в инструменты, либо существует с гарантом, который следит за ее соблюдением. А если нет ни того, ни другого — возможно, вам в целом стоит отказаться от стратегии.
⚙️Топ-10 бесплатных инструментов для тестирования мобильных приложений в 2025 году
Разработка мобильных приложений ускоряется. Появляется больше платформ, больше фич, выше риск багов. Чтобы выбрать подходящий инструмент для тестирования, важно понимать:
- какие платформы вы покрываете (Android, iOS, гибрид);
- нужны ли автотесты и CI/CD;
- кто пишет тесты — технари или бизнес;
- важна ли работа на реальных устройствах.
Мы собрали список из десяти бесплатных инструментов, которые реально работают и закрывают разные задачи — от ручного тестирования до CI-интеграции и облачного запуска. Выбирайте подходящий под ваш проект и команду.
1. Appium
✔️Полезен, если у вас кросс-платформа и много автотестов.
Популярный open-source инструмент для автоматизации мобильного тестирования. С ним можно запускать тесты на Android, iOS и Windows с одним API. Поддерживает Java, JS, Python и другие языки и интегрируется с CI/CD.
2. Kobiton
✔️Помогает, когда нужно ловить баги, которые не видит эмулятор.
Это платформа для тестирования на реальных устройствах. Дает высокую точность и быструю идентификацию ошибок, подробные отчеты и хорошую аналитику. Есть триал, но полноценная работа — по подписке.
3. Calabash
✔️Подходит для команд с нетехническими специалистами.
Это фреймворк на основе BDD (поведение-ориентированной разработки). Удобно, что в тестах можно использовать простые сценарии на естественном языке. Есть поддержка кросс-платформы.
4. Espresso
✔️Отличный выбор, если вы делаете Android-приложение и хотите глубокую интеграцию с Android Studio.
Это Android-фреймворк от Google с высокой надежностью тестов и простым и понятным API.
5. Selendroid
✔️Хорошее решение, если нужно покрыть старые версии Android и интегрироваться с Selenium.
Идеальный инструмент для Android-приложений, который работает со старыми версиями — вплоть до 4.2. Есть поддержка Selenium WebDriver и мультитач жестов.
6. TestGrid
✔️Подходит и для ручного, и для автоматизированного тестирования.
TestGrid — универсальное решение с встроенным управлением тест-кейсами.
Подходит как для ручного, так и автоматизированного тестирования в облачной инфраструктуре. Есть бесплатный план, но полноценная работа — только по подписке.
7. XCUITest
✔️Идеален для тестирования iOS-приложений.
Это инструмент от Apple, который глубоко встроен в Xcode и хорошо работает с iOS. Плюс — в быстром запуске тестов и удобной отладке.
8. BitBar
✔️Подходит для массового тестирования и масштабирования.
Это облачная платформа с огромным выбором реальных устройств, которая подойдет для комплексного тестирования. К тому же ее легко масштабировать. Бесплатная версия сильно ограничена.
9. Sauce Labs
✔️Лучшее облачное решение для тестирования на разных устройствах и браузерах.
Sauce Labs поддерживает 800+ комбинаций из устройств и браузеров. Инструмент предоставляет видеоотчеты и скриншоты и предлагает высокий уровень безопасности.
10. App Center Test (Microsoft)
✔️Отличное решение, если нужно параллельное тестирование на множестве девайсов.
Это инструмент от Microsoft, который позволяет запускать тесты одновременно на множестве устройств и ускорять разработку. Есть поддержка iOS и Android и интеграция с средой разработки. Возможности зависят от тарифа — базово можно попробовать бесплатно, но тесты на множестве устройств — по подписке.
Если интересно — можем сделать разбор по отдельным инструментам, с плюсами и минусами на реальных проектах. А пока делитесь, чем пользуетесь сами. Что работает, а что так себе?
Разработка мобильных приложений ускоряется. Появляется больше платформ, больше фич, выше риск багов. Чтобы выбрать подходящий инструмент для тестирования, важно понимать:
- какие платформы вы покрываете (Android, iOS, гибрид);
- нужны ли автотесты и CI/CD;
- кто пишет тесты — технари или бизнес;
- важна ли работа на реальных устройствах.
Мы собрали список из десяти бесплатных инструментов, которые реально работают и закрывают разные задачи — от ручного тестирования до CI-интеграции и облачного запуска. Выбирайте подходящий под ваш проект и команду.
1. Appium
✔️Полезен, если у вас кросс-платформа и много автотестов.
Популярный open-source инструмент для автоматизации мобильного тестирования. С ним можно запускать тесты на Android, iOS и Windows с одним API. Поддерживает Java, JS, Python и другие языки и интегрируется с CI/CD.
2. Kobiton
✔️Помогает, когда нужно ловить баги, которые не видит эмулятор.
Это платформа для тестирования на реальных устройствах. Дает высокую точность и быструю идентификацию ошибок, подробные отчеты и хорошую аналитику. Есть триал, но полноценная работа — по подписке.
3. Calabash
✔️Подходит для команд с нетехническими специалистами.
Это фреймворк на основе BDD (поведение-ориентированной разработки). Удобно, что в тестах можно использовать простые сценарии на естественном языке. Есть поддержка кросс-платформы.
4. Espresso
✔️Отличный выбор, если вы делаете Android-приложение и хотите глубокую интеграцию с Android Studio.
Это Android-фреймворк от Google с высокой надежностью тестов и простым и понятным API.
5. Selendroid
✔️Хорошее решение, если нужно покрыть старые версии Android и интегрироваться с Selenium.
Идеальный инструмент для Android-приложений, который работает со старыми версиями — вплоть до 4.2. Есть поддержка Selenium WebDriver и мультитач жестов.
6. TestGrid
✔️Подходит и для ручного, и для автоматизированного тестирования.
TestGrid — универсальное решение с встроенным управлением тест-кейсами.
Подходит как для ручного, так и автоматизированного тестирования в облачной инфраструктуре. Есть бесплатный план, но полноценная работа — только по подписке.
7. XCUITest
✔️Идеален для тестирования iOS-приложений.
Это инструмент от Apple, который глубоко встроен в Xcode и хорошо работает с iOS. Плюс — в быстром запуске тестов и удобной отладке.
8. BitBar
✔️Подходит для массового тестирования и масштабирования.
Это облачная платформа с огромным выбором реальных устройств, которая подойдет для комплексного тестирования. К тому же ее легко масштабировать. Бесплатная версия сильно ограничена.
9. Sauce Labs
✔️Лучшее облачное решение для тестирования на разных устройствах и браузерах.
Sauce Labs поддерживает 800+ комбинаций из устройств и браузеров. Инструмент предоставляет видеоотчеты и скриншоты и предлагает высокий уровень безопасности.
10. App Center Test (Microsoft)
✔️Отличное решение, если нужно параллельное тестирование на множестве девайсов.
Это инструмент от Microsoft, который позволяет запускать тесты одновременно на множестве устройств и ускорять разработку. Есть поддержка iOS и Android и интеграция с средой разработки. Возможности зависят от тарифа — базово можно попробовать бесплатно, но тесты на множестве устройств — по подписке.
Если интересно — можем сделать разбор по отдельным инструментам, с плюсами и минусами на реальных проектах. А пока делитесь, чем пользуетесь сами. Что работает, а что так себе?
Почему не дружат фронтендер и дизайнер и как их подружить: https://habr.com/ru/companies/agima/articles/909032/
О противостоянии отделов дизайна и фронтенда ходят настоящие легенды. Поговаривают, что эти ребята бесконечно о чем-то спорят и пытаются друг другу что-то доказать.
Мы же уверены, что эти слухи преувеличены. И чтобы найти общий язык, нужно следовать простейшим правилам. Наш фронтенд-тимлид Алексей Песоцкий рассказывает о них на Хабре.
Если вы слышали об этом «конфликте» или просто хотите разобраться во всех его перипетиях — переходите по ссылке выше. И конечно, делитесь мнением в комментариях.
О противостоянии отделов дизайна и фронтенда ходят настоящие легенды. Поговаривают, что эти ребята бесконечно о чем-то спорят и пытаются друг другу что-то доказать.
Мы же уверены, что эти слухи преувеличены. И чтобы найти общий язык, нужно следовать простейшим правилам. Наш фронтенд-тимлид Алексей Песоцкий рассказывает о них на Хабре.
Если вы слышали об этом «конфликте» или просто хотите разобраться во всех его перипетиях — переходите по ссылке выше. И конечно, делитесь мнением в комментариях.
Хабр
Почему не дружат фронтендер и дизайнер: работающие техники общения между отделами
Привет! Меня зовут Алексей Песоцкий, я фронтенд-тимлид в AGIMA . Противостояние дизайнеров и разработчиков носит уже почти легендарный характер. Этой теме посвящены десятки статей, видосов и докладов....
Новые трассы, известные музыканты и уникальный маскот — что вас ждет на RUNIT 2025: https://runit.digital/
Подготовка к ежегодному фестивалю RUNIT кипит, и у нас накопилось много новостей — делимся ими в этом посте.
1. Новая локация и мерч. Этим летом забег пройдет в Мещерском парке: там больше тени, хороший грунт и приятные виды. Дистанции — привычные: 3, 5, 10 и 21 км, плюс эстафета, командный зачет и детские забеги. На финише получите медаль с новым дизайном и футболку от бренда GRI. Пейсмейкеры и профессиональные судьи — как всегда с нами.
2. Фестиваль с любимыми группами. Целый день для вас будут работать несколько площадок: спорт (йога, бадминтон, волейбол), игры (настолки, дартс, денди) и сцена с живой музыкой. Потанцуем под хиты «Отпетых мошенников», «Пропаганды», «Красок» и других известных музыкантов. Хедлайнер фестиваля пока в секрете — следите за новостями.
3. Конкурс на лучшего маскота для RUNIT. Предлагаем вам поучаствовать в конкурсе и создать уникального персонажа для RUNIT. Важно отразить дух фестиваля — а это спорт, энергия и технологии. Победители получат премии от 20 до 50 тысяч рублей и возможность поработать с визуальным стилем всего проекта. Работы принимаем до 26 мая на Illustrators.ru в разделе «Маскот для RUNIT».
Регистрируйтесь на забег по ссылке выше и следите за новостями фестиваля в нашем телеграм-канале. Ждем всех — будет круто!
Подготовка к ежегодному фестивалю RUNIT кипит, и у нас накопилось много новостей — делимся ими в этом посте.
1. Новая локация и мерч. Этим летом забег пройдет в Мещерском парке: там больше тени, хороший грунт и приятные виды. Дистанции — привычные: 3, 5, 10 и 21 км, плюс эстафета, командный зачет и детские забеги. На финише получите медаль с новым дизайном и футболку от бренда GRI. Пейсмейкеры и профессиональные судьи — как всегда с нами.
2. Фестиваль с любимыми группами. Целый день для вас будут работать несколько площадок: спорт (йога, бадминтон, волейбол), игры (настолки, дартс, денди) и сцена с живой музыкой. Потанцуем под хиты «Отпетых мошенников», «Пропаганды», «Красок» и других известных музыкантов. Хедлайнер фестиваля пока в секрете — следите за новостями.
3. Конкурс на лучшего маскота для RUNIT. Предлагаем вам поучаствовать в конкурсе и создать уникального персонажа для RUNIT. Важно отразить дух фестиваля — а это спорт, энергия и технологии. Победители получат премии от 20 до 50 тысяч рублей и возможность поработать с визуальным стилем всего проекта. Работы принимаем до 26 мая на Illustrators.ru в разделе «Маскот для RUNIT».
Регистрируйтесь на забег по ссылке выше и следите за новостями фестиваля в нашем телеграм-канале. Ждем всех — будет круто!
Как делать код-ревью без токсичности и занудства: https://habr.com/ru/companies/agima/articles/911764/
Наш тимлид Артем Валевич написал статью о том, как давать обратную связь так, чтобы и продукт становился лучше, и в команде отношения не портились. В тексте он описал несколько рабочих принципов, которых придерживается сам.
Из основного:
— как давать обратную связь, чтобы не подрывать мотивацию;
— зачем делить большие задачи на маленькие мердж-реквесты;
— когда стоит автоматизировать проверку, а когда — нет;
— какие преимущества есть у кросс-ревью.
В статье много примеров того, как не стоит комментировать код, и как делать это лучше. Полезно всем, кто участвует в код-ревью — тимлидам, разработчикам, техлидам и QA.
Читайте материал по ссылке выше, пишите комментарии — интересно, кто как относится к этой теме.
Наш тимлид Артем Валевич написал статью о том, как давать обратную связь так, чтобы и продукт становился лучше, и в команде отношения не портились. В тексте он описал несколько рабочих принципов, которых придерживается сам.
Из основного:
— как давать обратную связь, чтобы не подрывать мотивацию;
— зачем делить большие задачи на маленькие мердж-реквесты;
— когда стоит автоматизировать проверку, а когда — нет;
— какие преимущества есть у кросс-ревью.
В статье много примеров того, как не стоит комментировать код, и как делать это лучше. Полезно всем, кто участвует в код-ревью — тимлидам, разработчикам, техлидам и QA.
Читайте материал по ссылке выше, пишите комментарии — интересно, кто как относится к этой теме.
Хабр
Код-ревью под микроскопом: как нетоксично давать обратную связь и проверять код без нервов
Привет! Меня зовут Артем Валевич, я тимлид в AGIMA . Одна из важнейших моих обязанностей — код-ревью, то есть проверка кода на качество, надежность и соответствие требованиям проекта. Этот процесс...
🧠 Что спрашивают на собеседованиях по JavaScript
Если вы готовитесь к собеседованию на позицию фронтенд- или фуллстек-разработчика по JS, то вам гарантированно зададут ряд базовых вопросов. Мы собрали самые частые — их задают почти в каждой компании.
Можно использовать этот список как чек-лист: пробежаться по вопросам, убедиться, что помните ответы, и закрыть пробелы там, где они есть.
📌 Базовые понятия
1. Что такое JavaScript?
2. Какие бывают типы данных в JavaScript?
3. В чем разница между var, let и const?
4. Чем отличаются == и ===?
5. Чем отличается null от undefined?
📌 Функции и область видимости
6. Что такое замыкания (closures)?
7. Что такое hoisting?
8. Что такое lexical scope?
9. Как работает ключевое слово this?
10. Что такое IIFE (Immediately Invoked Function Expression)?
11. Что такое функции высшего порядка (higher-order functions)?
📌 Асинхронность и промисы
12. Чем отличается синхронный код от асинхронного?
13. Что такое promises и async/await?
14. Как работает метод fetch()?
15. Как обрабатывать ошибки в async/await?
16. Что такое Promise.all()?
17. Что такое Event Loop?
📌 Работа с объектами и массивами
18. Как клонировать объект?
19. Чем отличается глубокое копирование от поверхностного?
20. В чем разница между map(), filter(), reduce()?
21. Что такое деструктуризация и оператор spread?
22. Как проверить, является ли значение массивом?
📌 DOM и браузерная среда
23. Что такое DOM?
24. Как выбирать элементы в DOM?
25. Что такое делегирование событий?
26. Как предотвратить стандартное поведение события?
27. В чем разница между == и === при сравнении DOM-элементов?
28. В чем разница между localStorage, sessionStorage и cookies?
📌 Оптимизация и инструменты
29. Что такое debounce и throttle?
30. Что такое service worker?
31. Как работает сборщик мусора (garbage collector)?
32. Что такое модули в JS (import/export)?
33. Что такое шаблонные литералы (template literals)?
34. Что такое callback-функции?
35. Какие значения считаются ложными (falsy)?
36. В чем разница между typeof и instanceof?
Если вы готовитесь к собеседованию на позицию фронтенд- или фуллстек-разработчика по JS, то вам гарантированно зададут ряд базовых вопросов. Мы собрали самые частые — их задают почти в каждой компании.
Можно использовать этот список как чек-лист: пробежаться по вопросам, убедиться, что помните ответы, и закрыть пробелы там, где они есть.
📌 Базовые понятия
1. Что такое JavaScript?
2. Какие бывают типы данных в JavaScript?
3. В чем разница между var, let и const?
4. Чем отличаются == и ===?
5. Чем отличается null от undefined?
📌 Функции и область видимости
6. Что такое замыкания (closures)?
7. Что такое hoisting?
8. Что такое lexical scope?
9. Как работает ключевое слово this?
10. Что такое IIFE (Immediately Invoked Function Expression)?
11. Что такое функции высшего порядка (higher-order functions)?
📌 Асинхронность и промисы
12. Чем отличается синхронный код от асинхронного?
13. Что такое promises и async/await?
14. Как работает метод fetch()?
15. Как обрабатывать ошибки в async/await?
16. Что такое Promise.all()?
17. Что такое Event Loop?
📌 Работа с объектами и массивами
18. Как клонировать объект?
19. Чем отличается глубокое копирование от поверхностного?
20. В чем разница между map(), filter(), reduce()?
21. Что такое деструктуризация и оператор spread?
22. Как проверить, является ли значение массивом?
📌 DOM и браузерная среда
23. Что такое DOM?
24. Как выбирать элементы в DOM?
25. Что такое делегирование событий?
26. Как предотвратить стандартное поведение события?
27. В чем разница между == и === при сравнении DOM-элементов?
28. В чем разница между localStorage, sessionStorage и cookies?
📌 Оптимизация и инструменты
29. Что такое debounce и throttle?
30. Что такое service worker?
31. Как работает сборщик мусора (garbage collector)?
32. Что такое модули в JS (import/export)?
33. Что такое шаблонные литералы (template literals)?
34. Что такое callback-функции?
35. Какие значения считаются ложными (falsy)?
36. В чем разница между typeof и instanceof?
🏗 Архитектурный комитет: зачем он нужен и как работает на практике
Когда мы только запускали архитектурный комитет, было много скепсиса: мол, бюрократия, будет тормозить процессы, всё это не про нас. Спустя несколько месяцев стало понятно: это одно из самых полезных решений для нашей продуктовой зрелости. Ниже — делимся его плюсами, минусами и первыми итогами.
Зачем нам архитектурный комитет
Раньше архитектурные решения принимались хаотично — в личных чатах, на лету, иногда в отрыве от стратегии. Комитет стал площадкой, где мы обсуждаем важные архитектурные решения коллегиально:
- проверяем повторяемость решений,
- сверяемся со стратегией и внутренними стандартами,
- фиксируем выводы, чтобы потом можно было к ним вернуться.
Чем мы довольны
✅ Несколько наших проектов уже прошли через комитет. И в итоге их заказчики остались очень довольны. Всё дело в том, что благодаря комитету мы смогли быстро предложить дешевые и работающие решения.
✅ Появился живой реестр архитектурных решений — не нужно держать всё в головах.
✅ Протоколы помогают возвращаться к старым кейсам и повторно использовать наработки.
Что пошло не так
На работу комитета нужно выделять время: сбор вводных, обсуждение, фиксация решений. Иногда это вызывает задержки, особенно на старте новых инициатив.
Что важнее всего
Главное открытие: архитектурный комитет — это не только про процессы, организацию площадки и ведение протоколов. Это про управление знаниями внутри компании.
Чтобы такой инструмент работал, важно сразу закладывать в него механизмы распространения экспертизы внутри компании. Иначе ценность теряется. Сейчас мы фокусируемся на этом и тестируем гипотезы — как передавать знания быстрее и надежнее. У индустрии на это тоже нет единого ответа — некоторые компании даже устраивают отдельные конференции только по этой теме.
Вывод
Архитектурный комитет — это показатель зрелости и устойчивости компании на рынке. Он помогает решать сложные вопросы и внедрять инициативы в разы проще и быстрее. Плюс появляется среда, в которой экспертиза не теряется, а накапливается и становится доступной другим командам.
Когда мы только запускали архитектурный комитет, было много скепсиса: мол, бюрократия, будет тормозить процессы, всё это не про нас. Спустя несколько месяцев стало понятно: это одно из самых полезных решений для нашей продуктовой зрелости. Ниже — делимся его плюсами, минусами и первыми итогами.
Зачем нам архитектурный комитет
Раньше архитектурные решения принимались хаотично — в личных чатах, на лету, иногда в отрыве от стратегии. Комитет стал площадкой, где мы обсуждаем важные архитектурные решения коллегиально:
- проверяем повторяемость решений,
- сверяемся со стратегией и внутренними стандартами,
- фиксируем выводы, чтобы потом можно было к ним вернуться.
Чем мы довольны
✅ Несколько наших проектов уже прошли через комитет. И в итоге их заказчики остались очень довольны. Всё дело в том, что благодаря комитету мы смогли быстро предложить дешевые и работающие решения.
✅ Появился живой реестр архитектурных решений — не нужно держать всё в головах.
✅ Протоколы помогают возвращаться к старым кейсам и повторно использовать наработки.
Что пошло не так
На работу комитета нужно выделять время: сбор вводных, обсуждение, фиксация решений. Иногда это вызывает задержки, особенно на старте новых инициатив.
Что важнее всего
Главное открытие: архитектурный комитет — это не только про процессы, организацию площадки и ведение протоколов. Это про управление знаниями внутри компании.
Чтобы такой инструмент работал, важно сразу закладывать в него механизмы распространения экспертизы внутри компании. Иначе ценность теряется. Сейчас мы фокусируемся на этом и тестируем гипотезы — как передавать знания быстрее и надежнее. У индустрии на это тоже нет единого ответа — некоторые компании даже устраивают отдельные конференции только по этой теме.
Вывод
Архитектурный комитет — это показатель зрелости и устойчивости компании на рынке. Он помогает решать сложные вопросы и внедрять инициативы в разы проще и быстрее. Плюс появляется среда, в которой экспертиза не теряется, а накапливается и становится доступной другим командам.
Самая зеленая IT-тусовка этого лета — едем сажать 6000 сосен в Переделкино: https://kodtree.agima.ru
Собираем всех, кто любит природу и нетворкинг, 21 июня в московском парке Переделкино. Мы высадим там настоящую сосновую аллею и классно проведем время в кругу единомышленников.
Что будем делать:
- посадим 6000 сосен на площади 10 000 гектар;
- познакомимся и пообщаемся с коллегами из IT-компаний;
- устроим пикник с полевой кухней и отдыхом на природе.
Всё необходимое мы подготовим и пришлем фотоотчет после события. Так что с вас — только хорошее настроение и желание сделать доброе дело своими руками.
Чтобы участвовать, регистрируйтесь на сайте.
Рассказывайте о нашем проекте коллегам и друзьям — чем больше людей, тем веселее!
Партнер проекта: Imperial Garden — крупнейший в России поставщик растений для ландшафтного озеленения.
Собираем всех, кто любит природу и нетворкинг, 21 июня в московском парке Переделкино. Мы высадим там настоящую сосновую аллею и классно проведем время в кругу единомышленников.
Что будем делать:
- посадим 6000 сосен на площади 10 000 гектар;
- познакомимся и пообщаемся с коллегами из IT-компаний;
- устроим пикник с полевой кухней и отдыхом на природе.
Всё необходимое мы подготовим и пришлем фотоотчет после события. Так что с вас — только хорошее настроение и желание сделать доброе дело своими руками.
Чтобы участвовать, регистрируйтесь на сайте.
Рассказывайте о нашем проекте коллегам и друзьям — чем больше людей, тем веселее!
Партнер проекта: Imperial Garden — крупнейший в России поставщик растений для ландшафтного озеленения.