Привет, Хабр! Настало время, когда можно сказать, что «new build system» Gradle является стандартом отрасли Android-разработки. Инструмент сделан настолько просто и удобно, что большинство разработчиков не испытает трудностей, даже не зная, как он устроен, и какие дополнительные возможности в нём есть — возникающие проблемы легко решаются с помощью 5 минут на StackOverflow, путем копирования «магического кода» в конфигурационные файлы. Возможно, в том числе из-за этого не все разработчики изучают Gradle детально и не знают о многих его полезных возможностях, которые существенно облегчают жизнь.

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

Отзывчивость, простота, гибкость и расширяемость кода — принципы, которые можно закрепить за реактивным UI.

Наверняка, если совместить реактивные backend и UI, то можно получить качественный продукт. Именно его мы и попытались сделать, разрабатывая 2GIS Dialer — звонилки, которая работает через API и при этом должна оставаться быстрой и удобной.

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

Вот надумал написать обзор библиотек с помощью которых легко и удобно писать приложения под Android.
Список вырисовывается такой:

• Android Annotations
• Groundy
• Retrofit
• AnnotatedSQL
• Android db-commons

Если заинтересованны прошу под кат.

Приветствую!

Сегодня я решил поведать Вам мой способ организации activity-service interaction в Android приложениях. Мотивирован топик тем, что достаточно часто можно встретить приложения, в которых, скажем, поход на сервер организовывается внутри активити в AsyncTask. При этом часто встречается верная мысль, что это надо делать в сервисах, но нигде в оф. документации нет ни слова об организации правильной архитектуры двустороннего взаимодействия между ними.

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

Об этом методе я буду рассказывать далее.

Привет ребят, давайте для начала проверим вашу память. Итак:

«На море на океане есть остров, на том острове дуб стоит, под дубом сундук зарыт, в сундуке — заяц, в зайце — утка, в утке — яйцо» в яйце игла — смерть Кощея!

А теперь, внимание, вопрос — как это формализовать?
Как приатачить к яйцу иголку и какова временная сложность детача смертии моей. Как перенести сказку в быль, как это выглядит на B-деревьях и почему на самом деле нет разницы между 2D и 1D.
А было все так: давным давно, в неком царстве, некотором государстве, на одном сервисе с шейрингом геолокации очень захотелось Иванушке Дурачку на уровне ЧПУ разделить Москву(/RU/MOW/) и Область(/RU/MOS/). И вообще навести порядок, чтобы все лежало по полочкам красиво и по алфавиту. Но не получалось ему сокровища свои посчитать, и аккуратно разложить. А Василису, хоть и дурак, к сбережениям не пускал.
Но решение было найдено.
Совсем недалеко над каким-то златом успешно чах Чахлик, еще и смерть он свою прятал по науке.
И если задача определения региональной (точнее полигональной) принадлежности некой иголки к некому сундуку выходит за рамки данной статьи, то нам ничто не мешает погрузиться в глубины зайца и посмотреть как он устроен на табличном уровне.
PS: и не спрашивайте почему зайца.

Лично я считаю, у каждого человека должно быть хобби. Кто-то вяжет крючком, кто-то мучает паяльником печатные платы, а кто-то запускает различные маленькие проекты и получает новый опыт, а если повезет, то и деньги.
Так уж получилось, что у меня и моего коллеги именно такое хобби. И вот, при очередной беседе в скайпе вопрос о том, чего такого мы ещё не пробовали возникла мысль, давай сделаем приложение под Android? Всё закрутилось…

Забегая немного вперёд скажу, что во-первых, у этой истории скорее счастливый конец, а вовсе не полный провал, во-вторых, я понимаю, насколько то, что мы делали отличается от того, что делают специалисты в области мобильной разработки и вовсе не призываю никого повторить наш путь. В-третьих я делюсь своим опытом и хочу показать всем неспециалистам, что при должном уровне упорства и приложении сил можно заниматься чем-то совершенно новым, неизвестным. Надеюсь кого-то мой опыт вдохновит. Так отдельно хочу обозначит временные рамки проекта: начало разработки это 01.12.2014 года, 27.02.2015 — публикация в Goolge Playmarket, продолжение истории по настоящее время. Итак, поехали…

Разработка под Android? А почему бы и нет, кругом полно историй успеха и наоборот, неудачи, огромный рынок, большое количество пользователей, неизведанность, всё это манило и делало шило особенно острым.
Из отрицательных сторон такой затеи виделось прежде всего 2 стороны:

• среди нас двоих нет настоящего программиста
• нет некоторой яркой идеи, которая бы «взорвала» рынок

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

Бывает что в крупном проекте работающем в jvm, внезапно обнаруживается что приложение не работает и даже не запускается при обновлении какой-либо из зависимостей проекта. Такое же возможно из-за любого другого события, которое изменило порядок следования библиотек в classpath приложения.

При использовании подхода из данного решения парсинг файлов будет не нужен. При изменении формата логирования или появлении новых сообщений не нужно поддерживать большой набор регулярок. Будем перехватывать вызовы методов error, warn, info, debug, trace логера и отправлять данные сразу в elasticsearch. С этим нам поможет аспектно-ориентированное программирование!

Ведущие инструменты для управления конфигурацией по разному подходят к автоматизации серверов

От переводчика: в связи с грядущим внедрением одной из подобных описанным в статье систем, приходится изучать доселе неведомые продукты. Захотелось перевести, поскольку подобных обзорных статей на русском языке не нашлось (не исключаю, что плохо искал), и, надеюсь, кому-то и пригодится. За возможные ошибки и неточности перевода просьба ногами не бить.

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

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

Puppet, Chef, Ansible и Salt были задуманы чтобы упростить настройку и обслуживание десятков, сотен и джае тысяч серверов. Это не значит, что маленькие компании не получат выгоды от этих инструментов, так как автоматизация обычно делает жизнь проще в инфраструктуре любого размера.
Я пристально взглянул на каждый из этих четырех инструментов, исследовал их дизайн и функциональность, и убежден, что несмотря на то, что некоторые оценены выше, чем другие, для каждого есть свое место, в зависимости от целей внедрения. Здесь я подвожу итоги моих находок.

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

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

При поступлении в ШАД проверяются знания в рамках общей программы, включающей базовые разделы высшей алгебры, математического анализа, комбинаторики, теории вероятностей, а также основы программирования. Под катом подробно разобраны задачи вступительного экзамена в ШАД 2014 года. Внимание! Пост довольно объёмный, поэтому устраивайтесь поудобнее, вооружайтесь карандашом, если нужно, доставайте чай с печеньем. Убедитесь, что сделали все дела на вечер! Велика вероятность, что рассматриваемые ниже задачи поглотят ваш разум на несколько часов, а кому-то помешают вовремя лечь спать. Во всяком случае сегодняшний вечер обещает быть интересным. Добро пожаловать под кат ↓

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

Вступление

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

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

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

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

Содержание

1. Что такое тензор и для чего он нужен?
2. Векторные и тензорные операции. Ранги тензоров
3. Криволинейные координаты
4. Динамика точки в тензорном изложении
5. Действия над тензорами и некоторые другие теоретические вопросы
6. Кинематика свободного твердого тела. Природа угловой скорости
7. Конечный поворот твердого тела. Свойства тензора поворота и способ его вычисления
8. О свертках тензора Леви-Чивиты
9. Вывод тензора угловой скорости через параметры конечного поворота. Применяем голову и Maxima
10. Получаем вектор угловой скорости. Работаем над недочетами
11. Ускорение точки тела при свободном движении. Угловое ускорение твердого тела
12. Параметры Родрига-Гамильтона в кинематике твердого тела
13. СКА Maxima в задачах преобразования тензорных выражений. Угловые скорость и ускорения в параметрах Родрига-Гамильтона
14. Нестандартное введение в динамику твердого тела
15. Движение несвободного твердого тела
16. Свойства тензора инерции твердого тела
17. Зарисовка о гайке Джанибекова
18. Математическое моделирование эффекта Джанибекова

Введение

Это было очень давно, когда я учился классе в десятом. Среди довольно скудного в научном плане фонда районной библиотеки мне попалась книга — Угаров В. А. «Специальная теория относительности». Эта тема интересовала меня в то время, но информации школьных учебников и справочников было явно недостаточно.

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

Аннотация

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

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

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

Я не берусь давать четкие определения видам тестирования в этой статье. Об интерпретации терминов, используемых для названия видов, речь пойдет в третьей части. Связано это разделение с объемом информации.

Я всегда затрудняюсь ответить на вопрос: откуда берутся идеи для игр? Но в этот раз, я более-менее точно могу сказать, что эта идея родилась у меня когда я увидел баннер «World of Tanks» на каком-то из сайтов. Знаете, бывают такие баннеры, которые привлекают внимание пользователя микро-играми, прежде чем перенаправить его на сайт рекламодателя? Так вот, на этом баннере был танк, который по клику мог проезжать то или иное расстояние, зачем-то пробивая при этом кирпичные стены. Вот именно с этого момента я стал размышлять, по дороге на работу, о раннере с танковой тематикой. Тут же родилась и отсылка к нашумевшему хиту от Wargaming в названии. Она показалась мне забавной, учитывая, что суть моей игры — это движение по некой дороге, пути, с целью пройти максимальное расстояние. Под хабракатом вас ждет рассказ об игре, разработке, технические детали и все-все-все, что должно быть в классической «gamedev story».

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

Вернемся к нашей задаче, нам нужно интеллектуально генерировать карты для IPhone/IPad игры типа «Марио», для начала мы рассмотрим генерацию карты в пределах поля 128х128 кубов.

Эта статья является попыткой ответа на старый вопрос для собеседований: «Что же случается, когда вы печатаете в адресной строке google.com и нажимаете Enter?» Мы попробуем разобраться в этом максимально подробно, не пропуская ни одной детали.

Примечание: публикация основана на содержании репозитория What happens when...

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

Мы перенесли перевод в репозиторий GitHub и отправили Pull Request автору материала — оставляйте свои правки к тексту, и вместе мы сможем значительно улучшить его.

Неожиданно пришел приказ — написать приложение под iOS, использующее Yandex Speechkit для распознавания русской речи. Точнее, для распознавания коротких фраз на произвольную тему. Цель задания — сравнить успехи яндекс-двигателя с нашим, саровским движком.

Приказали — сделал следующие шаги.

1. Зашел на yandex.ru в раздел распознавание речи
2. Зарегистрировался и получил ключ, он же API_KEY
3. Отправил письмо в yandex с просьбой активировать ключ

На вопрос, как будет использоваться ключ, я ответил, что выпускаю карточную игру Diablo 3-13, управляемую голосом.

Через два дня ключ активировали. Я поначалу нетерпеливо бил копытом, затем понял, что в yandex работают вдумчивые, синхронные сотрудники.
В своем приложении в дальнейшем я также отказался от асинхронных запросов к yandex.api.