Мы начинаем публиковать бизнес-интервью с экспертами из мобильной индустрии о продуктах, мобильном продвижении, аналитике, user acquisition и бизнесе в целом.



Первым экспертом, у которого Алексей Писаревский взял интервью, стал вице-президент по мобильным продуктам Aviasales и наш давний клиент и хороший друг — Иван Козлов.

Привет, Хабр! Правильнее было бы назвать этот пост «У нас есть классная партнёрская программа и крутой SDK для неё», но не хотелось делать длинный заголовок и сразу раскрывать все карты. Как бы там ни было, в этой публикации мы хотим рассказать про SDK наших сервисов, который каждый из вас может использовать в своих приложениях.

Это руководство — начальный материал о кросс-DPI и кроссплатформенном дизайне для начинающих и средних дизайнеров, желающих узнать о нем с самого начала или получить больше знаний. Без сложных математических и непонятных диаграмм, только непосредственные объяснения, упорядоченные в небольших разделах, для понимания и применения их непосредственно к вашей дизайнерской работе.

Автор — Sebastien Gabriel.

Я не знаю всего, так что, если по вашему мнению я где то ошибаюсь или вам нужно уточнить что-то, либо у вас есть предложения или вопросы для улучшения данного руководства, отправьте письмо (на англ) на sgabriel.contact@gmail.com. Вы также можете найти на меня Twitter, G+ или Facebook.

CleverPumpkin и TM начали предметные переговоры в сентябре 2013 года. На самом деле, беседы о создании приложения начались еще в декабре 2012 года в кулуарах общения Mofas и Boomburum, которые поддерживали дружеские отношения еще с давних времен (когда еще существовал форум palmz.in, и все увлекались кпк). Команда Хабра имела чёткое представление о желании своих пользователей — иметь мобильные приложения, но всё упиралось в отсутствие внешнего API.

На российском рынке аутсорс-разработки не так много компаний, которые используют гибкие методологии разработки (Agile). Всем привычна работа по каскадной модели (Waterfall). Это же относится и к сектору мобильной разработки.

У заказчика практически всегда есть бюджет или ожидания по стоимости, а также конечная задача — приложение с определенной функциональностью. Однако в продуктовой мобильной разработке применение Agile более оправдано.



Мы занимаемся аутсорс-разработкой мобильных приложений, хотя используем у себя Agile-инструмент — Pivotal Tracker (далее в тексте — PT). Именно об опыте его использования я хочу рассказать вам в этой статье.

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

Все компании разные, но между лучшими техническими руководителями, с которыми мне довелось работать, существует кое-что общее. Снимаю шляпу перед Брайаном Столером, Натаном Хантом, Эваном Гилбертом и Ричем Бердоном за то, что послужили мне хорошим примером.

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

Качества

Вы всегда должны улучшать три своих качества: компетентность, скорость и осведомленность.

Попасть на WWDC оказалось непросто. Я понимал, что желающих поучаствовать в конференции будет много. Поэтому к тому моменту, когда открылась продажа билетов, я был подготовлен: проверил интернет-соединение, разложил перед собой обе свои кредитки (на случай, если одна не сработает) и ждал, когда на сайте Apple появится заветная кнопка «Buy tickets». И вот она! Нажимаю, ввожу свой логин и пароль и… вижу сообщение о технической проблеме. Несколько раз судорожно обновляю страницу, но ничего не происходит. Наконец, страница загрузилась, и на экране возникает лаконичная надпись «Sold out»… 2 минуты, и билеты проданы, вот это ажиотаж! Я пребывал в лёгком смятении весь следующий день — планам не суждено было сбыться. Однако вечером мне позвонили из Apple и сообщили, что отследили мою попытку приобрести билет. Мол, что-то там у них не сработало, но мне зарезервировали билет и пришлют ссылку для покупки мне на почту, если я, конечно, не передумал. Билет был куплен, виза получена, и я отправился в Сан-Франциско.

По следам своего выступления на Positive Hack Days я хотел бы поделиться с вами результатами исследования демона configd на MACH-уровне в iOS 6. Как вы знаете, в iOS доступно не так много информации о состоянии подключения Wi-Fi. В общем-то, Public API не дает возможности узнать ничего, кроме SSID, BSSID и сетевых настроек адаптера. А режим шифрования? мощность сигнала? Под катом я расскажу, как узнать все это без применения Private API и Jailbreak.

Зачем

1. Зачем подменять ответ сервера?
Я всегда был и буду сторонником подхода, когда каждый отвечает за свою доменную область. И скажем, если сервер с API сломался, то обнаружить это должны юнит-тесты бэк-енда, а не свалившиеся тесты моего iOS-приложения.

2. Зачем использовать блоки, почему не target-action, делегирование и так далее?
Это личное предпочтение каждого, почти во всех ситуациях разрабатываемые мной объекты будут иметь блоковые коллбэки а не вызывать методы делегата. Для меня это работает и особых проблем с этим подходом я не испытал. В конце концов, блоки — это стильно, модно, молодежно!