Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

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

Аннотации, как инструмент метапрограммирования появились вместе с релизом Java 5 в далеком 2004 году. Вместе с ними появился инструментарий Annotation Processing Tool, на смену которому пришла спецификация JSR 269 или Pluggable Annotation Processing API. Что интересно, этой спецификации без малого 10 лет, но свою популярность в Android разработке она начала обретать только сейчас.

О возможностях, которые открывает эта спецификация мы поговорим чуть позже (будет мнооого кода), а сперва, не хотите ли поговорить о компиляции Java кода?

Аналитика приложений в большинстве случаев сводится просто к мониторингу основных метрик: DAU, MAU, WAU, ARPU, ARPPU и другие аббревиатуры. Базовые метрики аналитики — это как раз те 20% функционала аналитических систем, которые дают 80% результата. Но достаточно ли вам этих 80%?

Если нет, то наша статья для вас. Мы расскажем о некоторых метриках, которые тоже стоило бы иметь в виду, если вы хотите полностью понимать все процессы, которые происходят в вашем приложении.

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

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

Модульное тестирование работает с изолированными “микрокомпонентами”. Зачастую Вам нужно «мокировать» классы – то есть обеспечить фейк функциональной реализацией, чтобы изолировать специфический микрокомпонент, таким образом, он сможет быть протестирован. В Objective-C существует несколько сторонних фреймворков, которые помогают это реализовать. Но они еще не доступны в Swift’е.

В этом руководстве Вы научитесь, писать свои собственные mock-обьекты, fakes и stub'ы, чтобы покрыть тестами давольно простое приложение, которое поможет вам запомнить дни рождения ваших друзей.

Привет хабр!

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

2014 год был особенным для всех, кто занимается разработкой под Android — он принес одно из самых значимых обновлений Android за всю его историю, версию Android 5.0. С этим обновлением мы получили новый визуальный язык, детальные гайдлайны, множество новых API и инструментов. И, как всегда в случае таких массивных обновлений, не все новшества сразу пробивают себе дорогу в реальные проекты. Где-то мешает инерция мышления разработчиков, привыкших решать определенные задачи определенным образом, где-то — отсутствие документации по новым API, где-то — отсутствие поддержки новых возможностей на старых версиях платформы. Но время не стоит на месте и благодаря труду команды Android, а также независимых разработчиков, такие API постепенно обретают обратную поддержку. И сегодня я хочу рассказать об API векторной графики Android, который способен серьезно облегчить жизнь разработчика, но при этом до сих пор не пользуется популярностью.

Привет, Хабрахабр! Недавно мы анонсировали конкурс для разработчиков приложений, и в посте на Хабре давали ссылки на самые интересные материалы по Material Design’у. Часть из них имела пометку «RU — скоро», и сегодня мы рады представить вам первую адаптированную статью о том, как создатели приложения Feedly адаптировали его к новому визуальному языку Android-приложений.

Привет! Мы команда дизайнеров, которые проектируют и создают дизайн приложений для Android, iOS и Windows.



За 10 лет работы в e-Legion мы сделали проекты разной сложности: от интернет-магазина до мобильного банка. Идеи архитерктуры приложения / дизайна мы искали в разных источниках, что-то придумывали сами, искали интересные решения в интернете. И за время работы у нас накопилось достаточно полезных ссылок, которыми мы хотим поделиться.

Итак, мы уже говорили о происхождении архитектуры ОС Android и о шаблонах, реализованных в этой архитектуре. Теперь настала пора поговорить о том, из чего состоит Android-приложение.

В этой статье будут представлены основные «персонажи» архитектуры Android-приложения.

Привет, Хабрахабр! Сегодня у нас для вас очень приятные новости. Как вы все, наверное, знаете, в Android 5.х и его последователе, Android 6.0 Marshmallow используется новое оформление. Концепция Material Design была представлена на Google I/O 2014 и получила позитивный отклик не только среди дизайнеров и разработчиков приложений, но и среди пользователей.



На сегодняшний день более 200 тысяч приложений в Google Play переработаны с учётом гайдлайнов по Material Design. Если и вы уже обновили свое приложение в Google Play до Material Design или же планируете это сделать в ближайщее время, то принимайте участие в конкурсе по Material Design, который стартовал на этой неделе и продлится до 15 ноября. Разыгрываем: размещение вашего приложения в разделе featuring магазина Google Play, билеты на ежегодную конференцию Google I/O и планшеты Nexus 9. Мы выберем по три лучших приложения в трёх категориях. Подробности в правилах конкурса.

Один из часто рассматриваемых паттернов — паттерн Builder. В основном рассматриваются варианты реализации «классического» варианта этого паттерна:

MyClass my = MyClass.builder().first(1).second(2.0).third("3").build();

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

Итак, расссмотрим их:

Вместо введения

Во многих практических задачах требуется выполнение различных фоновых действий, будь то проигрывание музыки, обмен данными с сервером или просто слежение за действиями пользователя дабы похитить у него реквизиты кредитных карт. Ну а если не получится, то по крайней мере завалить его целевой рекламой, используя полученные сведения. Как уже давным-давно все знают, в Android такие вещи оформляются в виде службы (Service).

Официальная документация гласит, что ОС Android останавливает службу только в случае нехватки памяти. Тем не менее, существует и другие случаи. Пользователь может сам остановить службу, используя предоставляемые ему средства меню Settings/Apps, там же он может сделать и полную остановку приложения. Но для этого ему надо напрягаться и, в общем-то осознавать свои действия и их последствия. К сожалению, для уничтожения службы у него есть и другие возможности, которыми он может пользоваться бессознательно. В частности, если в нашем приложении ранее была запущена хоть одна Activity, видимая в истории, то пользователь буквально одним движением пальца сможет вынести соответствующую задачу. Как ни парадоксально, попутно Android вышибет и весь процесс вместе со службой.

Лично мне такое поведение Android логичным не кажется. Пользователь зачастую просто чистит Recent Apps от давно забытого хлама, совсем не обязательно он при этом желает отказаться от тех благ, которые ему предоставляла выполняющаяся служба. Однако разработчики Google мыслили немного по-другому. По-другому, так по-другому, их право, но в конце концов нам с вами тоже надо как-то жить.

На Kickstarter получают финансовую поддержку не только гаджеты, видеоигры и разного рода кошельки. Здесь есть возможность получить средства на реализацию своего проекта и для компаний, которые планируют выпускать одежду. Самой успешной кампанией такого рода стал проект "Travel Jacket". Авторы идеи уже получили $8 млн вместо $20 тысяч, которые изначально запрашивались.

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

Обычно дизайн приложения рисуется в векторном редакторе (например, Sketch), но типичным форматом картинок в приложении под Android является растровый (как правило, PNG). При разработке приложения необходимо для каждого векторного изображения заниматься утомительной работой по изготовлению набора растровых картинок для разных плотностей экранов. Количество таких комплектов может доходить до шести по числу возможных плотностей: ldpi, mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi (плотность xxxhdpi необходима только для иконки приложения). При верстке иногда приходится задать в разметке явные размеры для изображения, что может потребовать перемасштабирования растровой картинки, а это, в свою очередь, наверняка приведет к появлению артефактов. К тому же наличие нескольких комплектов картинок отрицательно сказывается на размере выходного apk.

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

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

Я постараюсь донести основные идеи, показать как эта VCS помогает разрабатывать проект. Надеюсь, что после прочтения вы сможете ответить на вопросы:

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

Конечно, я попытаюсь рассказать обо всём по-порядку, начиная с основ. Поэтому, эта статья будет крайне полезна тем, кто только начинает или хочет разобраться с git. Более опытные читатели, возможно, найдут для себя что-то новое, укажут на ошибки или поделятся советом.

Распределенные системы контроля версий (DVCS) постепенно замещают собой централизованные. Если вы еще не используете одну из них — самое время попробовать.

В статье я постараюсь показать, как можно быстро начать экспериментировать с git, используя сайт github.com.

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

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

На этой неделе получился большой дайджест – более 50 материалов про виртуальную реальность, про новый Android, который теперь маршмэллоу, про Sailfish OS, про борьбу с Google Play и поиск в магазине, про нестандартные способы монетизации приложений и 19 метрик, о которых вы, возможно, не знали.

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

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

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