Относительно не так давно появилась замечательная библиотека Espresso для тестирования UI Android приложений. Её преимущества над аналогами обозревались не один раз. Если вкратце, то они заключаются в том, что это разработка Google для собственной ОС (ранее они сами использовали Robotium), а так же в лаконичности синтаксиса и скорости работы. Итак, мы решили идти в ногу со временем и использовать Espresso. Но нам мало тех плюсов, что уже есть, мы хотим BDD (http://en.wikipedia.org/wiki/Behavior-driven_development), мы хотим скриншотов и отчетов в json и html, мы хотим запускать это все на CI, в конце концов! Но обо всем по порядку. Я расскажу как подружить Cucumber (http://habrahabr.ru/post/62958/) и Espresso (http://habrahabr.ru/post/212425/) на небольшом примере. Всех, кто устал от Appium, кто хочет уйти от Robotium и тех, кому небезразлично тестирование Android, прошу под кат.

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

Для примеров будет использоваться популярный движок Unity3D. Рассматриваются подходы, применимые в больших играх. Написано из моего личного опыта и из того, как я это понимаю. Конечно, где-то я могу быть не прав, где-то можно лучше сделать. Я тоже все еще в процессе набирания опыта и набивания новых шишек.

В публикации рассматриваются следующие темы:

• Наследование VS компоненты
• Сложные иерархии классов юнитов, предметов и прочего
• Машины состояний, деревья поведений
• Абстракции игровых объектов
• Упрощение доступа к другим компонентам в объекте, сцене
• Сложные составные игровые объекты
• Характеристики объектов в игре
• Модификаторы (баффы/дебаффы)
• Сериализация данных

Сегодня все больше приложений создается сразу для нескольких мобильных платформ, а приложения, созданные изначально для одной платформы, активно портируются на другие. Теоретически можно полностью писать приложение «с нуля» для каждой платформы (т.е. фактически «кроссплатформенной» оказывается только идея приложения). Но это означает, что трудозатраты на его разработку и развитие будут расти пропорционально количеству поддерживаемых платформ. Если же многоплатформенность изначально заложить в архитектуру приложения, то эти затраты (плюс, в особенности, затраты на поддержку) могут существенно сократиться. Вы разрабатываете общий кроссплатформенный код один раз — значит используете его на текущих (и будущих) платформах. Но в этом случае сразу возникает несколько взаимосвязанных вопросов:

• Должна ли быть граница между общим (кроссплатформенным) и нативным (специфичным для данной платформы) кодом?
• Если да, то где и как провести эту границу?
• Как сделать так, чтобы кроссплатформенный код было удобно использовать на всех платформах, как на тех, что надо поддержать сейчас, так и на тех, чья поддержка, вероятно, может потребоваться в будущем?

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

Хочу сразу предупредить, что букв в этом посте много, но дробить тему на куски не хотелось. Поэтому запаситесь терпением.

Давно идут споры о том, что такое работа программиста — ремесло, навык или искусство. При этом постоянно встаёт вопрос оценки результата. О том, как разные разработчики и руководители в Яндексе подходят к вопросу оценки работы программиста, мы поговорим в этом посте.



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

У нас тут в Цеху живёт довольно много разработчиков. По большей части многие уже научились не есть сушёную пиццу по ночам, разговаривать с живыми людьми и вообще вести свой бизнес. Больным местом, конечно же, стало получение профильных знаний. В смысле, что куда кодить понятно, а вот как быть с проектом в целом — нет.

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

Сейчас расскажу, как такие вещи помогали в разработке и около неё. Вообще, главная беда психологии программистов, ушедших в бизнес — фокус внимания на постоянной текучке и непонимание приоритетов.

Привет! В посте блиц-обзор книг, которые будут полезны IT-специалистам, бизнесменам и тем, кто просто любит читать интересные технические вещи. Рядом с каждой – пояснения, чем оно может быть нужно. Этот обзор, в отличие от других ежегодных, более технически-прикладной.

Начнём со «Справочника по инженерной психологии» Вудсона и Коновера.

«Справочник по инженерной психологии» — Вудсон, Коновер

Книга о том, какие бывают кнопки и рычаги, как на них нажимают люди. И как проектировать так, чтобы люди работали с системой эффективно. Радует тем, что рассматривает пользователя как базовую систему ввода-вывода, замеряя его среднюю скорость передачи информации (около 20 бит в секунду на кнопочные интерфейсы), скорости ввода и вывода.

У каждого кандидата в конце собеседованию рекрутер обычно спрашивает, есть ли вопросы. Часто люди теряются и не находят, что спросить. И лишь по прошествии некоторого времени (часто, когда человек уже работает в компании) сами собой всплывают вопросы, о которых нужно было поинтересоваться заранее, а не брать кота в мешке и удивляться «Как я сюда попал? Куда я смотрел? Почему я об этом не подумал?». Это так называемый «эффект лестницы». Я подготовил шпаргалку, что ты, %habrauser%, не растерялся.

Общее

1. Рабочий график и можно ли его двигать?
Я люблю поспать. Но на моей прошлой работе «рабочее утро» начиналось в 7:30. Мало того, что я довольно часто не мог прийти к этому времени, я еще пол дня занимался тем, что пытался привести себя в рабочую форму. Где то до 10:00. С 10:30 до 11:30 я усердно работал. Потом был обед. А потом мне хотелось спать, а не работать, т.к. я не высыпался еще с утра. Надо ли говорить, что вместо 8 часов, на которые меня нанял работодатель, я работал в «потоке» только часа 3-4. Так что для себя нужно решить вопрос – когда я наиболее трудоспособен? И обговорить рабочий график с руководством. И еще один нюанс. Попробуйте закрепить обговоренный график в трудовом договоре или контракте (далее ТД), если работодатель идет на персональный рабочий график для Вас. Никаких устных договоренностей. Иначе Вам начнут крутить руки уже в процессе работы (как это было со мной).

Итак, вы работаете на Java с самого её появления? Вы помните те дни, когда она называлась «Oak», когда про ООП говорили на каждом углу, когда сиплюсплюсники думали, что у Java нет шансов, а апплеты считались крутой штукой?

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

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

Множество из предложенных нами сфер, на самом деле, можно отнести к категории «новейших технологий», но большинство из представленных нами идей относятся к давнишним, уже испытанным в прошлом областям Интернет- и мобильных технологий. Так что, если до прочтения этого поста Вы хотели заниматься именно этим, просто продолжайте. Классические стартапы, типа Google или Facebook, на самом-то деле очень и очень важны и, несмотря на свою традиционность и «обычность», тоже являются своего рода «прорывами».

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

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

При разработке кросс-платформенного мобильного приложения, имеющего в своём функционале работу с файлами, встаёт вопрос об организации процессов работы с файлами на каждой платформе. С данным вопросом мы столкнулись при разработке новой версии Edusty, позволяющей делиться файлами со своими одногруппниками. В этой статье мы расскажем как происходит импорт и экспорт файлов в приложениях, работающих на операционных системах iOS, Android, Windows Phone.

Недавно мой коллега (Константин Волков) посетил мастер-класс по Material Design и поделился впечатлениями. Далее рассказ пойдет от его имени.

Введение

О Material Design [1] сегодня слышали многие, его принципы обсуждают во многих новостных и профессиональных блогах, посвященных Android. Но так ли понятна эта концепция разработчикам мобильного программного обеспечения? Можно ли использовать Material Design в реальном бою, и станут ли приложения эффективнее? На эти вопросы должен был ответить мастер-класс по Material Design, который прошел в середине февраля в технополисе “Москва”.

Работая с Android часто можно видеть, как весь функциональный код помещается в методы жизненного цикла activity/fragment. В общем-то такой подход имеет некоторое обоснование — «методы жизненного цикла» всего лишь хэндлеры, обрабатывающие этапы создания компонента системой и специально предназначенные для наполнения их кодом. Добавив сюда то, что каркас UI описывается через xml файлы, мы уже получаем базовое разделение логики и интерфейса. Однако из-за не совсем «изящной» структуры жизненного цикла, его зависимости от множества флагов запуска, и различной (хоть и похожей) структуры для разных компонентов, эффективно воспользоваться подобным разделением не всегда бывает возможно, что в итоге выливается в написании всего кода в onCreate().

“Это унылое диалоговое окно действительно нужно?”

В этой статье я изложил главные принципы Material Design и дал советы по их воплощению. Текст написан по следам мастер-класса для разработчиков, который мы, Роботы, устраивали совместно с российским офисом Google (Think Mobile).


Когда-то все продукты Google выглядели по-разному плохо. Даже один продукт на разных платформах выглядел неконсистентно.

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

В новом Android Lollipop появился такой интересный компонент как VectorDrawable. Если использовать его с умом, можно значительно снизить объем приложения, сэкономив на графических ресурсах, плюс, использование векторной графики освобождает нас от муторного процесса создания изображений под разные плотности экрана. Первая мысль, которая меня посетила, когда я увидел VectorDrawable, была: “Ух ты! А его можно тянуть как NinePatch?”. Оказалось нельзя. Тут можно было бы немного огорчиться и довольствоваться тем, что хотя бы иконки можно в векторе держать. Однако, я на этом решил не останавливаться. В итоге получилась универсальная утилита, которая из любого Drawable способна сделать NinePatchDrawable.



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

Посмотришь на любую программу обучения по IT-специальности, и тут же увидишь дисциплину «Дискретная математика» (возможно, под другим названием), обычно для перво- или второкурсников. И её наличие вполне разумно, поскольку дискретная математика и непрерывная математика (представленная на первом курсе институтов с незапамятных времён математическим анализом) — две грани единой Математики, — красивой, могучей науки.

Хотя раньше такого понятия, как «дискретная математика» вовсе не было, это не значит, что не возникало дискретных задач: Абель, Дирихле, Фибоначчи, Эйлер, чьи имена возникают по ходу изучения дискретной математики, — отнюдь не наши современники! Но просто в те времена для выделения самостоятельной ветви математики ещё не сложилось критической массы задач и приёмов, не было видно взаимосвязей между ними. А большое количество плодотворных взаимосвязей между, на первый взгляд, различными понятиями, — то, что математики в своей науке очень ценят.

Ну хорошо, математикам всё математическое интересно. А зачем дискретная математика программисту?

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



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

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

1. Поиск настроек

У настроек теперь есть свой поиск. Это сильно экономит время, если вы знаете, что вам нужно. Допустим, вы хотите поменять настройки сети, но не знаете, где они. Ищите «network» и найдёте нужную опцию.

Вторая часть
Примечание переводчика: Данная статья является переводом публикации «The AI Revolution: The Road to Superintelligence». Оригинальная статья была написана для широкой аудитории, поэтому многие термины использованные в ней могут быть не точными или вообще не научными. При переводе я старался сохранить непринуждённый дух статьи и юмор, с которым был написан оригинал. К сожалению, это не всегда получалось. Переводчик согласен не со всем, что написано в данной статье, но правки к фактам и своё мнение не были добавлены даже в виде примечаний или комментариев. В тексте могут быть ошибки и опечатки, сообщайте о них, пожалуйста, в личные сообщения, буду стараться исправлять всё максимально быстро. Все ссылки в тексте скопированы из оригинальной статьи и ведут на англоязычные ресурсы.

We are on the edge of change comparable to the rise of human life on Earth. — Vernor Vinge

Мы стоим на пороге перемен сравнимых, разве что с самим рождением человечества. Вернор Виндж.

Каково это находиться здесь?