Привет, Хабр! Когда я изучал паттерны проектирования, я делал это с помощью прочтения двух книг: простую и понятную книгу от Head First одновременно со сложной и менее понятной книгой от Банды Четырех. Ниже описан мой опыт того, как именно я это делал, плюс выводы, впечатления и советы

Привет, Хабр! Меня зовут Лена, я iOS-разработчик в inDriver. Расскажу о том, как мы выбирали менеджер зависимостей для проекта. Название статьи звучит пессимистично, но на самом деле, все оказалось не так плохо.

Сначала поделюсь тем, как у нас обстояли дела с интеграцией сторонних решений. Затем выделю проблемы и цели, которые перед нами стояли, и перейду к сравнению менеджеров зависимостей. Расскажу, почему остановили свой выбор на Swift Package Manager (SwiftPM) и как на него переезжали.

Погнали!

Легко ли разработать новый API? На что обратить внимание, чтобы не ошибиться при реализации, и к каким компромиссам стоит быть готовым?

Привет, Хабр! Меня зовут Иван Ивашковский. Я руковожу группой разработки международных проектов в Яндекс Go. Этот пост — продолжение цикла историй о вымышленном стажёре Васе. Предыдущий материал, про идемпотентность, можно почитать здесь. В посте я расскажу, как Вася разрабатывал API для новой фичи и с какими проблемами он столкнулся в процессе. В конце приведу чеклист с советами, как проверить себя на каждом этапе разработки, если вы решаете похожую задачу.

"Каждого 30-го числа мы садились за круглый стол и решали, кто сколько денег сможет заработать в следующем месяце. На то время я был в роли линейного руководителя. На этой встрече собирались все линейные руководители и начальник отдела. Встреча продолжалась 2-3 часа. Каждый руководитель называл поочередно фамилию своего сотрудника и предлагал какую-то цифру, которая и будет планом продаж на следующий месяц. Каждый руководитель приводил свои доводы, но большинство из них имели исключительно субъективный характер. Кто-то мог сказать, что сотрудника жалко, так как….; кто-то говорил, что он не справляется с планом, поэтому ему нужно его понизить, чтобы он справился и получил деньги; кто-то говорил, что услышав такой высокий план сотрудник уволится.

По итогам встречи часто оказывалось, что:

а) абсолютно равные сотрудники могли получить абсолютно разные планы;

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

Особо странно потом смотрели на нас эти сотрудники, которые никак не могли понять, почему у такого-же соседа план 100, а у меня 200… . Это их явно не мотивировало.

Аналогичный подход у нас был и по отношению к пересмотру заработной платы. Любимыми аргументами руководителей были: "он так старается", "он меня не подводил", "он уволиться",... . И, после таких “честных” пересмотров, снова на нас смотрели сотрудники и не понимали, почему коллега получает больше, чем он, при том, что они выполняют абсолютно одинаковые функции".

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

Меня зовут Вероника Ильина, я работаю с людьми в Додо. Пару раз в жизни я попадала в ситуации, когда желание успеть всё и рабочие дни с 9 до 21 приводили к тому, что не было сил вставать по утрам. С тех пор я научилась работать так, чтобы даже в самые сложные моменты с кучей проектов, учёбой и так далее не падать на дно выгорания. Когда я пришла в Додо и увидела кучу ребят с горящими глазами, которые в увлечённости своей работой иногда забегают слишком далеко и перегружаются. И мы с командой начали работать над предотвращением выгорания и помощью тем, кому нелегко.

Это большая история и про прозрачное целеполагание, и про работу с процессами в командах. Но в первую очередь о том, что присматривать за собой должен сам человек. Чтобы помочь в этом разобраться и дать ребятам готовые инструменты, мы с нашим внутренним комьюнити PPL (People&Process Leads) собрали материалы на тему выгорания, вылезания из него и его предотвращения. И сегодня я начинаю серию постов, в которой делюсь этими материалами. И первый пост про то, что такое выгорание, какие у него симптомы и как определить, если ли выгорание оно у вас и ваших коллег.

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

Типичный день мобильного разработчика: получил json, распарсил, отрисовал на UI ячейки, PROFIT.

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

В сегодняшней программе  ячеек в iOS: разберемся какие ячейки бывают, посмотрим на ячейки в дизайн-системе hh.ru и их реализацию в коде и попробуем собрать свою ячейку.

В этом посте разбираем полный список SKErrors: что они значат и как их обрабатывать. Каждую ошибку мы рассмотрим в трёх аспектах: как она возникает, что с ней делать и какое сообщение показывать пользователю в уведомлении об ошибке.

Это пятая статья из нашей серии, посвящённой внедрению покупок на iOS. Познакомиться с предыдущими можно по ссылкам:

1. iOS in-app purchases часть 1: конфигурация и добавление в проект.

2. iOS in-app purchases часть 2: инициализация и обработка покупок.

3. iOS in-app purchases часть 3: серверная валидация покупок.

4. iOS in-app purchases часть 4: локальное тестирование покупок в XCode.

5. iOS in-app purchases часть 5: обработка ошибок SKErrors. - Вы тут.

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

Если вы разработчик или автоматизатор, пишете нативные UI-тесты в iOS или думаете начать их писать, эта статья для вас.

Сегодня мы детально погрузимся в мир UI-тестов, потренируемся в их написании, рассмотрим, с какими проблемами разработчик может столкнуться в процессе покрытия приложения тестами, и предложим вам наши решения. Попробуем вместе с вами написать хороший UI-тест! )

Привет! Меня зовут Андрей Михайлов, я работаю iOS-разработчиком в Циан и отвечаю за внедрение модульного тестирования в процесс разработки. Сегодня я немного расскажу о том, какими свойствами должны обладать хорошие автоматизированные тесты, чем хорошие тесты отличаются от плохих, и для чего на самом деле стоит их писать (не только чтобы находить баги в коде). Это первая статья в серии, посвященной тестированию, она сфокусирована на теории и будет полезна не только iOS-разработчикам.

Добро пожаловать под кат!

В 2015 году я предложил спроектировать космический аппарат для фотосъемки следов американцев на Луне. На эту работу 1232 человека в сумме скинулись на 1,75 млн руб. Пять с половиной лет ушло на поиск оптимальной конструкции и расчеты всех обстоятельств полёта. В июне 2021-го мы завершили проектирование Лунного микроспутника, провели презентацию, и спонсоры проекта получили итоговый документ с техническим описанием проекта. Что же дальше?

На недавно прошедшем WWDC 2021 представили новую версию StoreKit 2. Это фреймворк, который отвечает за осуществление покупок в iOS. Доля приложений со встроенными покупками и подписками постоянно растёт, и выпустив StoreKit 2, Apple заметно упростил интеграцию покупок в приложение. Сегодня мы рассмотрим работу с StoreKit 2 со стороны сервера, то есть с помощью App Store Server API.

Изменения — это то, что происходит всегда. Мы можем переходить на новый язык программирования. Например, внедрять Kotlin или переходить на GO, как это сейчас многие делают. У нас могут появляться новые базы данных. Мы можем переезжать в облака (или обратно). Или можем захотеть внедрить у себя новый процесс, будь то Code review, постмортемы или Scrum с Канбаном. Даже для перехода на удаленку нужны новые процессы или инструменты.

Люди реагируют на изменения по-разному — кто-то активно включается в процесс, а кто-то просто мешает. Техлиды могут помочь внедрить изменения быстрее и легче, если будут знать, как влиять на команду. Сегодня Дмитрий Масленников, возглавляющий департамент SRE в Тинькофф, покажет, с каким поведением вы можете столкнуться при изменениях (видео его выступления на TechLead Conf 2020). В результате его 10-летнего опыта вы сможете не только что-либо продать командам, но и сохранить изменения.

Не каждый язык со статической системой типов обладает такой строгой типобезопасностью, как Swift. Это стало возможным благодаря таким особенностям Swift, как фантомные типы (phantom types), расширения универсальных типов и перечисления со связанными типами. На этой неделе мы узнаем, как использовать фантомные типы для создания типобезопасных API.

Каждый iOS разработчик в своей жизни уходил с собеседования в расстроенных чувствах и мыслью “это что еще за новая аббревиатура?” Архитектурами пугают и джунов, и миддлов, и синьоров (и наверное даже синьорит). Важно не просто знать что стоит за названием, но ещё и в каком случае какую использовать. Литературы по этому вопросу преступно мало, редкие обсуждения в интернете ограничиваются собственным опытом и какими-то поделками на гитхабе.

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

Первая часть посвящена MV(X) паттернам: самым известным и распространенным практикам в индустрии.

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

Возможно, у многих возникнет вопрос:  “Зачем разбивать с помощью SPM?”. Ведь можно просто создавать подпроекты. Можно, но в использовании SPM для разбиения есть несколько преимуществ: