Как же часто мне приходилось слышать от рекрутеров одну и ту же фразу:

Мы работаем по Agile. Спринты по 1-2 недели

Под "Agile" они, конечно же, имеют в виду Scrum. Но я с уверенностью могу сказать, что ни в одной компании, что я работал, Agile'ом даже и не пахло. И тут я даже не говорю о том, что Agile каким он был задуман в принципе не дошел до массовой разработки (о чем рассказывал один из создателей Agile Дейв Томас на конференции GOTO 2015). Я говорю об Agile в общепринятом значении этого слова.

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

По некоторым причинам команде разработчиков либо не получается наладить работу по Agile, либо руководство знает, как лучше, и навязывает собственное видение методологии разработки. Эту проблему адресовал в своей статье Рон Джефрис (вот перевод на русский), дав красноречивое название подобным практикам — "Dark Scrum". Существует и более мягкая формулировка для тех, кто считает подобное положение вещей скорее фичей, а не багом — "Pseudo Agile" или "Post Agile".

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

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

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

Так вот как то раз смотря документацию Relay я наткнулся на мысль, что не понимаю, как работает связка Relay.useLazyLoad и React.Suspense.

В частности не понятно, как именно React.Suspense понимает, что вот прямо сейчас происходит асинхронный запрос и самое время отрисовывать fallback?

Эта статья – большущий гайд по технологиям, которые мы в СДЭК используем для проверки наших внутренних приложений, написанных на React Native. Часть из этих подходов вполне можно применить не только в мобильной разработке, но и за её пределами. Дальше буду описывать все в контексте веб-разработки. Если вас это еще не испугало – приглашаю окунуться в головокружительный мир автотестирования мобильных приложений.

Летом 2020 года GitHub позволила пользователям создавать персональные README-файлы и с их помощью кастомизировать свои профили. Сама платформа при создании подобного файла предлагает уже готовый шаблон, в который можно вписать свои данные. Но о какой кастомизации может идти речь, если у всех будут одинаково оформленные профили? За почти два года сообщество придумало множество различных способов выделиться и особенно оформить свою страницу на GitHub.

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

Существует большое количество статей и видео, в которых подробно описывается преимущество использования автоматизированной сборки проекта и содержимое этих статей применительно к React Native (впрочем и к другой кроссплатформе) сводится к следующим действиям:

1. Инициализируем Fastlane в папках iOS и Android
2. Копируем платформо-зависимые скрипты вида: clean, build, publish
3. Вставляем их в соответствующие iOS и Android директории
4. Публикуем приложение!

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