Пришли очередные выходные, надо написать пару десятков строк кода и нарисовать картинку, да лучше не одну. Итак, на прошлых и позапрошлых выходных я показал, как делать трассировку лучей и даже взрывать всякое. Это многих удивляет, но комьпютерная графика — очень простая вещь, пары сотен строк голого C++ вполне хватает на создание интересных картинок.

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

Наше путешествие от стандартных Activity и AsyncTask'ов к современной MVP архитектуре с применением RxJava.

Код проекта должен быть разделён на независимые модули, работающие друг с другом как хорошо смазанный механизм — фото Честера Альвареза.

Экосистема средств разработки под Android развивается очень быстро. Каждую неделю кто-то создаёт новые инструменты, обновляет существующие библиотеки, пишет новые статьи, или выступает с докладами. Если вы уедете в отпуск на месяц, то к моменту вашего возвращения уже будет опубликована свежая версия Support Library и/или Google Play Services.

Я занимаюсь разработкой Android-приложений в компании ribot в течение последних трёх лет, и всё это время и архитектура наших приложений, и используемые нами технологии, постоянно развивались и улучшались. Эта статья проведёт вас путём, пройденным нами, показав вынесенные нами уроки, совершенные нами ошибки, и рассуждения, которые привели ко всем этим архитектурным изменениям.

Это вторая часть обучающей статьи, связанной с изучением адаптивного поведения Split View Controller и Popover в iOS 9 на iPad и на iPhone, которое стало возможным благодаря концепции Size Classes. Обучение состоит в создания на Swift практических приложений, работающих с сервером Flickr.com, который является облачным сервисом для хранения фотографий.

В первой части перечислены пять интересных с точки зрения разработчика случаев применения адаптивного Split View Controller и Popover, которые отличаются сложностью Master. Detail везде один и тот же — единственный Image View Controller, вставленный в Navigation Controller и призванный показывать изображение фотографии:

1. Классический вариант: один элемент в Master, вставленный в Navigation Controller, (часто это Table View Controller)

2. Множество Table View Controller элементов, вставленных в Navigation Controller

3. Tab Bar Controller в качестве Master

4. Случай разных UI и разных пользовательских классов для приборов с разными Size Classes здесь не рассматривается, но идею можно посмотреть в “Адаптивный интерфейс с двумя storyboards для iOS 9”.

5. Адаптивный Popover

В первой части осуществлялось построение базового экспериментального приложения на Swift, которое было распространено на случаи 1-2. В этой статье мы будем дальше усложнять наше экспериментальное приложение и распространим его на случаи 3 и 5. Код для всех вариантов можно найти на Github.

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

Объяснение закона гравитации из мультфильма «Физика для самых маленьких»

У меня растет два очень любознательных сына в возрасте три и пять лет. Они очень любят научные мультики, особенно по физике и астрономии, как только в их руки попадает планшет, маленькие пальчики начинают быстро перебирать видеоролики из YouTube в поисках интересного контента. И что же они там находят? Поскольку я не только отец двоих детей, но еще и существенную часть жизни посвятил методике преподавания физики для маленьких детей, я знаю, что показывают детям учителя, а также заботливые родители и добрые бабушки. Скажу сразу, не все из этого стоит показывать детям.

Недавно я выступал на конференции Droidcon в Париже с докладом (оригинал на французском), в котором рассматривал проблемы, возникшие у нас в Square при работе с фрагментами и возможности полного отказа от фрагментов.

В 2011-м мы решили использовать фрагменты по следующим причинам:

• Тогда мы ещё не поддерживали планшеты, но знали, что когда-нибудь будем. Фрагменты помогают создавать адаптивный пользовательский интерфейс, и потому казались хорошим выбором.
• Фрагменты являются контроллерами представлений, они содержат куски бизнес-логики, которые могут быть протестированы.
• API фрагментов предоставляет возможность работы с backstack'ом (в общих чертах это выглядит так же, как и работа со стэком Activity, но при этом вы остаётесь в рамках одной Activity).
• Так как фрагменты построены на обычных представлениях (views), а представления могут быть анимированы средствами Android-фреймворка, то фрагменты могли в теории дать нам возможность использовать более интересные переходы между экранами.
• Google рекомендовал фрагменты к использованию, а мы хотели сделать наш код как можно более стандартным.

С 2011-го года много воды утекло, и мы нашли варианты получше.

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

Для начала я решил проанализировать недостатки различных менеджеров задач и создать своё приложение. Но не очередной менеджер задач — таких приложений уже очень много. Новая программа должна помогать правильно планировать работу и не утонуть в море задач.

Как должно работать это приложение?

В нашей первой публикации мы привели обзор и сравнение целого спектра iBeacon маячков доступных на рынке. Сегодня мы рассмотрим более подробно как работает Bluetooth маяк на примере наших европейских коллег, и поговорим о том, как с его помощью можно рассчитать местоположение внутри здания.

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

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

Сегодня мы со снисходительной улыбкой рассматриваем картинки, на которых изображено будущее — то, каким его представляли 50-60 лет назад. А от визуализированных фантазий 80-100-летней давности на глаза наворачиваются слезы умиления. Даже жалеешь, что будущее стало таким, каким стало, а не таким, каким его представляли в начале XX века. Уж очень колоритно и масштабно футуристы тех времен живописали скорые достижения человечества.

В середине прошлого века мечты техногиков стали уже куда ближе к реальности сегодняшнего дня. Некоторые технологии и гаджеты действительно появились в нашей жизни, а какие-то могут скоро появиться. Что-то пробовали сделать, но по ряду причин не получилось, а какие-то фантазии вообще никогда не будут реализованы. Но все равно очень интересно рассматривать иллюстрации тех времен, особенно 1950-1970-х годов — периода расцвета техноутопизма. Одним из самых плодовитых футуристов-художников в то время был Артур Радебо (Arthur Radebaugh). На рубеже 1950-1960-х годов он создал немало иллюстраций, вдохновлявших людей на мечты о светлом будущем.

Итак, как же в те годы представлялось не слишком отдаленное будущее? Под катом много картинок!

Мы подготовили перевод большого обзора маячков, работающих по технологии iBeacon, которая применяется и в проекте Navigine – системах для indoor-навигации. В Navigine для навигации внутри помещений мы используем различные технологические решения, однако iBeacon является одним из самых известных и популярных в консьюмерском секторе – поэтому начнем рассказ именно с него.

Когда-то, на заре моей карьеры Android-разработчиком, я просматривал примеры уже имеющихся приложений и в прекрасном, словно солнышко весной, U2020 я нашел пример очень удобного адаптера. Имя его BindableAdapter. Долгое время я использовал его как основу своих адаптеров для ListView и GridView, но их эра приходит к своему закату и наступает эра RecyclerView. Этой эре нужен новый удобный адаптер, и я попытался его сделать.

Просто рыжий кот. Или он цвета #FFCC33?

В разделе «Named Colors» в последней спецификации CSS размещен перечень из сто сорок одного стандартного цвета. Каждый из них имеет не только код, но и свое название. И это не только «черный», «белый» и знакомые всем нам оттенки, но и такие цвета как «лимон шифон», «коралловый» и «шоколадный».

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

Эта история берет начало в 1980-х годах в Массачусетсе. Изначально, цвета CSS были продуктом X Window System (X), графического пользовательского интерфейса (GUI), распространенного в MIT с 1984 года. В июне 1986 был сформирован первый список цветов этого GUI, после настройки его для работы на терминале VT240. Список включал в себя шестьдесят девять основных цветов и оттенков, которые записывались ста тридцатью восьмью способами с учетом регистра (то есть «darkred» и «DarkRed» были разными цветами).

После значительной задержки публикую продолжение цикла своих статей.
Для ознакомления:

• Steam Protocol 2 и Steam Files — Введение
• Steam Files. Часть 1 — GCF/NCF

В данной статье я затрону оставшиеся форматы файлов:

• BLOB — устаревший формат данных, служащий контейнером для двоичных данных. Содержал в себе базовые параметры (IP-адреса серверов, CRD-запись и еще много чего);
• CDR (Content Description Record) — бинарный файл, содержащий данные о приложениях и их файлах кеша. На данный момент не используется;
• VDF — бинарный/текстовый файл, содержащий множество данных и имеющий структуру, зависящую от конкретного применения. Разработан как замена BLOB и CDR;
• PAK — ранее использовался в Half-Life 1, великое наследие Quake 1, уже не используется;
• VPK — новый формат игровых архивов внутри самих игр, активно используется на данный момент. Подробное описание файла имеется на официальном ресурсе. В статье описана только первая версия формата.

Статья представлена только для ознакомления, поскольку актуальной информации здесь относительно мало, а примеров алгоритмов почти нет — всё можно просмотреть в упомянутом ранее репозитории.

Не так давно, в начале августа, на конференции Android Developer Conference (Andevcon) 2015, проходившей в Бостоне, корпорация Intel анонсировала INDE Multi-OS Engine — фреймворк для разработки нативных кроссплатформенных приложений на Java.

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

Привет! А я продолжаю травить байки нашей команды выездных инженеров. Часть произошла со мной, частью поделились коллеги — лично присутствовал не везде, поэтому именно «байки». Плюс, конечно, детали немного изменены, чтобы никого не обидеть. Если вы вдруг узнаёте себя — помните, что в это же время ещё десять разных человек думают о своей компании.

Начнём. В большой компании мы делали видеонаблюдение на одном из объектов. Там две службы безопасности — ИТ и «физики». Первые «кладут кабель», вторые «ложат мордой в пол». Так вот, по настоянию ИТ-безопасников мы делали вообще отдельную сеть на коаксиале, чтобы нельзя было открутить камеру, воткнуться на её место и сбрутить роутер. Промучились изрядно. В конце монтажа мы обратили внимание на ряд датчиков «физиков», стоящих прямо рядом с камерами. На витой паре. Скрутили один, воткнулись с ноутбуком, там веб-интерфейс роутера… и да, пароль 12345678!

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

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

Ты и не думал, что столкнёшься с подобным. Ты даже не заметил, как сам сюда пришел.

Когда разработка мобильных приложений в компании переходит на промышленные рельсы, неизменно всплывает вопрос об автоматической сборке. Continuous Integration — это то, что является неотъемлемой частью процесса. Итог этого процесса — сборки для тестирования на устройствах компании для OTA распространения заказчикам и удаленным тестировщикам.

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

Итак, эта статья о том, как реализовать копирование сертификатов и профилей для iOS сборок и свойств, и ключей для Android сборок на все слейвы дженкинса в рамках Continuous Integration. Такая автоматизация экономит время и помогает избежать ошибок. Статья будет интересна разработчикам мобильных приложений и тем, кто администрирует Jenkins.

Поехали!

Недавно мы в «Я люблю ИП» закончили курсы по дизайну от trydesignlab.com. И это одна из самых важных статей, которую нам посоветовал ментор в процессе обучения. Именно поэтому мы решили её перевести. Посмотреть все наши работы с курсов можно в ВКонтакте по тэгу #design101@iloveip.

Вступление

Сначала о главном. Это руководство не для всех. Это руководство прежде всего для:

• разработчиков, которые хотят уметь делать хорошие интерфейсы для себя, если вдруг прижмёт;
• UX-дизайнеров, которые знают, что хороший UX-дизайн продаётся лучше в красивой UI-упаковке.

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

А пока давайте я расскажу, что вы найдёте в этой статье.