CTO: Balancing Leadership and Architecture.

As a CTO, effective leadership goes beyond technical architecture. Conducting regular performance reviews is a crucial part of managing teams.

Note: The performance review schedule may vary depending on the specific
company's policies and guidelines.

For early-stage startups, lacking CTO expertise in conducting performance reviews is common. In my experience, I've tailored grades to encompass all aspects of professional iOS development, keeping project-specific needs in mind. Being the first in the team can offer significant growth opportunities. However, acknowledging any lack of people management skills and compensating through continuous growth is essential.

I've compiled my insights on structuring the iOS development department, conducting performance reviews, and most importantly, emphasizing the significant distinctions between developers' levels based on well-defined criteria.

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

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

Меня зовут Александра Хорошкова, я менеджер проектов по коммуникациям в SuperJob, и в этой статье я хочу поделиться своими способами подготовки требований. Если их описание — обязательная часть разработки, то и путь лежит через пять стадий принятия неизбежного. Давайте рассмотрим их подробнее и разберемся, зачем нужны требования, какими они бывают, и как можно быстро и качественно их составить. 

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

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

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

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

Привет, Хабр! Меня зовут Богдан, в Badoo я работаю в мобильной команде iOS-разработчиком. Мы достаточно редко рассказываем что-либо о нашей мобильной разработке, хотя статьи – один из лучших способов документировать хорошие практики. Эта статья статья расскажет о нескольких полезных подходах которые мы используем в нашей работе.

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

Меня зовут Аркадий, я Android-разработчик в Badoo. В последнее время в нашем блоге много постов про Go, PHP, JS, QA, и я решил разбавить их темами по мобильной разработке. Как раз занимался портированием одного Android-проекта с RxJava 1 на RxJava 2 и читал всё, что можно найти на эту тему в интернете. В частности, доклад Джейка Вортона с конференции GOTO Copenhagen 2016. Мне показалось, что это достойный кандидат на перевод – думаю, многие Android-разработчики задумываются о переходе на RxJava 2, и им интересно, что изменилось по сравнению с первой версией.

Джейк сделал достаточно объёмное введение о реактивном программировании, так что знание RxJava 1 не требуется для понимания статьи. Доклад был подготовлен, когда RxJava2 ещё только готовилась к выпуску (на текущий момент уже выпущена версия 2.1.0).

Можно ли в iOS работать с геолокацией, когда приложение свернули и отправлять данные на сервер?

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

Чтобы была какая-то конкретика, я предположил, что перед нами стоит задача написать вело-трекер. Со стороны пользователя это выглядит так:

1. Скачиваю приложение
2. Запускаю
3. Регистрируюсь
4. Нажимаю куда просят
5. Закрываю
6. Катаюсь
7. Запускаю
8. Вижу результат

p.s. финальный код здесь.

Шаблоны проектирования — это способ решения периодически возникающих проблем. Точнее, это руководства по решению конкретных проблем. Это не классы, пакеты или библиотеки, которые вы можете вставить в своё приложение и ожидать волшебства.

Как сказано в Википедии:

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

Будьте осторожны

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

В статье приведены примеры на PHP 7, но пусть вас это не смущает, ведь заложенные в шаблонах принципы неизменны. Кроме того, внедряется поддержка других языков.

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

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