В этой статье представлен гайд по настройке совместной работы светильников Xiaomi, работающих по Wi-Fi и Bluetooth, с Siri при помощи Homebridge. А также описаны грабли, на которые я успел наступить.

В Playrix приходит много новых сотрудников и большинство из них не работали с Git. Особенно это касается гейм-дизайнеров и художников. Хотя и для программистов это не редкость – опыт работы с другими системами контроля версий не слишком помогает. Например, часто встречается опыт работы с SVN. Но Git заметно отличается по идеологии. Заучить, какие кнопки нажимать, в большинстве случаев не сложно, но шаг в сторону – и уже трудно понять, что происходит.



Поэтому мы решили написать ознакомительный материал. Мы поговорим о системе контроля версий и логике её работы, с самых азов. С Git можно работать с помощью  разных клиентов, потому в статье не пойдет речь об интерфейсе пользователя. Это может показаться непривычным, но это сделано намеренно. Вместо этого мы сфокусируемся на рабочем каталоге, коммитах, ветках, командах pull, push и прочих. Когда вы разберетесь в этих понятиях, вам останется выбрать один из Git-клиентов и освоить его интерфейс.

Пользователи хотят видеть изменения

Анимированное обновление списков всегда было непростой задачей в iOS. Что неприятно, это всегда было рутинной задачей.

Приложения крупных компаний, таких как Facebook, Twitter, Instagram, VK, используют таблицы. Более того, почти каждое iOS приложение написано с использованием UITableView или UICollectionView и пользователи хотят видеть, что изменяется у них на экранах, по этой причине reloadData не подходит для обновления экрана. Посмотрев несколько уже имеющихся фреймворков для данной задачи, я удивился, как много они в себе обобщают, помимо расчета анимаций. Некоторые же вообще при вставке одного элемента в начало, радостно сообщали о перемещениях всех остальных элементов.

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

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

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

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

Что же должен делать «несчастный» разработчик? Решение есть, оно состоит в том, чтобы отделить основной поток через параллелизм. Параллелизм, это свойство приложения выполнять задачи в несколько потоков одновременно – и при этом пользовательский интерфейс остается отзывчивым, поскольку Вы выполняете свою работу в разных потоках.

Одним из методов для одновременного выполнения операций в iOS являются использование классов NSOperation и NSOperationQueue. В этой статье вы узнаете, как их использовать! Вы будете работать с приложением, которое совсем не использует многопоточность, таким образом, оно будет очень медленным, и будет «тормозить». Когда вы измените приложение, чтобы можно было добавлять параллельные операций и — надеюсь – это обеспечит более отзывчивый интерфейс для пользователя!

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



Я упомянул Operations в одной из моих статей, но давайте рассмотрим их более внимательно.

Казалось бы, при загрузке приложения можно и потерпеть секунду-другую. Но когда ваша программа используется часто, а в конкурентах — аналог от производителя самой ОС, то даже время запуска начинает сказываться. Разработчик Яндекса Виктор Брыксин bobermaniac выступил на встрече сообщества CocoaHeads в офисе наших коллег в Mail.Ru и рассказал, как заставить iOS-приложение запускаться побыстрее.


— Долгое время я занимался разработкой Яндекс.Браузера. Собственно, из оптимизации времени старта этого приложения и родился мой доклад.

Улучшаем дизайн проекта с помощью тактически грамотных действий, а не таланта.

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

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

Легко опустить руки и сказать: «Я никогда не смогу сделать это должным образом, я не художник!», Но, оказывается, есть уйма ловких приёмов, которые вы сможете использовать, чтобы поднять свою работу на другой уровень, не имея опыта в графическом дизайне.

Под катом семь простых идей, которые вы сможете использовать для улучшения своих проектов.

1. Для создания иерархии используем цвет и вес вместо размера

При разработке любого мобильного приложения, обрабатывающего пользовательские данные, важно уделить внимание безопасности. Особенно остро этот вопрос стоит для приложений, где фигурируют ФИО, номера телефонов, паспортов и другая личная информация. Наша компания разрабатывала и продолжает развивать несколько проектов такого рода, в частности приложения для клиентов российских банков. На основе этого опыта мы выработали набор требований безопасности, которым руководствуемся. Естественно, каждый год появляются новые технологии и возможности, а вместе с ними — новые особенности поведения и уязвимости. В этой статье мы зафиксировали основные пункты обеспечения безопасности iOS-приложений, актуальные на начало 2018 года.

Привет, Хабр!

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

Исторически сложилось, что все основные мобильные платформы «из коробки» обладают превосходной поддержкой локализации сообщений. В iOS, Android и Windows Phone приложение можно локализовать без всяких трудностей. Все средства для этого уже встроены в IDE: просто укажите нужный язык в списке поддерживаемых локализаций, введите текст на этом языке — и всё остальное за вас сделает IDE. Работает как часы. Но у этого подхода всё же есть недостатки.

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

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

«Может показаться, что я ничего не делаю. Но на самом деле, на клеточном уровне, я очень занят»
Автор неизвестен

В 21 веке построение программ все чаще напоминает конструктор Lego. Этот подход подразумевает, что многие «кубики» придуманы до нас. Собственно их элементарность обманчиво подсказывает, что ресурс улучшений за многие годы здесь практически исчерпан и нам остается использовать то, что есть. Но, как не странно, по аналогии с биологией, элементарные «клетки» порой скрывают самые сложные и продуманные алгоритмы и именно здесь заключены все самые интересные баталии. В этом смысле программисты по многогранности индустрии, чем-то напоминают медиков. Здесь есть свои терапевты, ветеринары, хирурги и есть вот те ребята, которые на несколько строк кода могут потратить несколько месяцев работы.

«В компании Google, прямо сейчас, пока я говорю, в нашем парке серверов, 1% всех CPU занимаются вычислениями внутри хештаблиц. Пока я говорю, более 8% всей оперативной памяти серверов занимают хештаблицы. И это только то, что относится к С++, я не знаю ситуации по Java»
Matt Kulukundis, CppCon 2017

Что должен знать objc разработчик на уровень middle/senior?
К сожалению, четкой черты на вертикальное развитие нет. Парадокс, но чтобы знать что изучить, нужно знать что ты не знаешь.
Я постарался вспомнить самые интересные вопросы, которые мне задавали самому на различных собеседованиях, а так же расширил их множеством вопросов(тем же уровнем) от себя.
Здесь нет общих вопросов вроде: IoC, design patterns, S.O.L.I.D. и т.п.

ВНИМАНИЕ!!!
Помимо вертикального развития немаловажно и горизонтальное

ВНИМАНИЕ!!! (2)
Не пишите в комментарии ответы на вопросы, это дает возможность людям самостоятельно разобраться.
Однако, если у вас имеются интересные вопросы по теме, я с радостью добавлю их в список.

Конечно, это не заменит живого общения, однако позволит неплохо подготовиться к собеседованиям.

Начинаем

В первой части нашего урока мы использовали Storyboard для настройки view. Во второй и заключительной части мы наконец-то добрались до самих блоков. Мы поговорим о том, что блоки собой представляют, каков их синтаксис, как их использовать и затронем кучу примеров. Будет показано, как использовать блоки с NSArray, UIView-анимациями, Grand Central Dispatch, и многим другим.

В процессе изучения Objective-C и iOS-разработки не могла понять принципы работы блоков. С толку сбивало, что их можно передавать как параметры в методы. Наткнулась на статью, которая показалась мне крайне интересной, так как рассматривались не только блоки, но и процесс разработки приложения. Пост адаптирован под xCode 7.3.1.

Приложение Камера для iPhone / iPad очень удобно в использовании. Пользователь легко может переключаться из режима фотографирования на видеосъемку. В режиме видеосъемки показывается время съемки и всего одна кнопка (Старт / Стоп). К сожалению, при использовании стандартного UIImagePickerController’а нет возможности контролировать количество кадров в секунду и некоторые другие параметры. Я покажу, как, используя AVFoundation framework, получить доступ к более тонким настройкам камеры, таким как, количество кадров в секунду, качество видео, длительность записи, размер видео файла. Пользователь сразу будет видеть на экране видео в том качестве, в котором оно будет сохранено.

Всем привет. Сегодня поговорим о практическом использовании NSProxy класса, пост будет небольшим, думаю многим новичкам будет интересно почитать.

Немного оффтопа.

В общем, по распределению в компании я попал на легаси проект на Objc, где massive view controller считался эталом архитектуры. Конечно же без нормальной спеки и тестов. За недолгую карьеру разработчика у меня выработалось пару правил для таких вот проектов, первое — никакого рефакторинга с моей стороны без указания сверху, второе — трогать существующий код только в крайней необходимости. Всё это на почве того, что в таких проектах очень сложно отловить регрессию (а может я просто ленивый?).

Честно говоря, я начала использовать ReactiveCocoa, потому что это модно. Я слышу как iOS разработчики говорят об этом фреймворке все время, и я едва могу вспомнить iOS Meetup без упоминание ReactiveCocoa.


Когда я только начала изучать ReactiveCocoa я не знала что это такое. «Реактивный» звучит действительно здорово, и «функциональный» звучит умно. Но после того как я поддалась искушению овладеть Reactive Cocoa я уже не могу себе представить написания кода без его использования.

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

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

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

Чтобы в итоге собеседование не выглядело для соискателя как:


Статья в первую очередь будет полезна всем, кто ищет работу в среде iOS разработки или хоть как-то связан с набором IT специалистов: проводит технические собеседования или любые другие.

И добро пожаловать под кат.

Хоть Apple и написали, казалось бы, подробную документацию о том, как можно использовать «Swift»-код внутри «Objective-C»-приложения (и наоборот), но, когда доходит до дела, этого почему-то окаывается недостаточно. Когда у меня впервые появилась необходимость обеспечить совместимость фреймворка, написанного полностью на «Swift», с «Objective-C»-приложением, документация «Apple» почему-то породила больше вопросов, чем дала ответов (ну или по крайней мере оставила множество пробелов). Интенсивное использование поисковых систем показало, что данная тема освещена в Сети довольно скудно: парочка вопросов на StackOverflow, пара-тройка вводных статей (на англоязычных ресурсах, конечно) – вот и все, что удалось найти.

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

Перевод статьи Джеффа Прешинга (Jeff Preshing) How to Write Your Own C++ Game Engine.

Как написать собственный игровой движок на C++

В последнее время я занят тем, что пишу игровой движок на C++. Я пользуюсь им для создания небольшой мобильной игры Hop Out. Вот ролик, записанный с моего iPhone 6. (Можете включить звук!)

Hop Out — та игра, в которую мне хочется играть самому: ретро-аркада с мультяшной 3D-графикой. Цель игры — перекрасить каждую из платформ, как в Q*Bert.

Hop Out всё ещё в разработке, но движок, который приводит её в действие, начинает принимать зрелые очертания, так что я решил поделиться здесь несколькими советами о разработке движка.

С чего бы кому-то хотеть написать игровой движок? Возможных причин много:

Несколько дней назад, 15 мая, в ScummVM, известный кроссплатформенный набор игровых движков для point-and-click adventure, была добавлена ветка кода с движком, который поддерживает классику квестового жанра, игру The Neverhood.

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