Объект Store

Всем привет. Сегодня хотим поделиться переводом подготовленным в преддверии запуска курса «iOS Разработчик. Продвинутый курс». Поехали!

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

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

Защита резервных копий: пока всё просто

В этот раз я бы хотел немного поговорить о еще одном порождающем шаблоне проектирования из арсенала «Банды четырех» – «Строителе» («Builder»). Так вышло, что в ходе получения своего (пусть и не слишком обширного) опыта, я довольно часто видел, чтобы паттерн использовался в «Java»-коде вообще и в «Android»-приложениях в частности. В «iOS» же проектах, будь они написаны на «Swift» или «Objective-C», шаблон встречался мне довольно редко. Тем не менее, при всей своей простоте, в подходящих случаях он может оказаться довольно удобным и, как модно говорить, мощным.

Вы пробовали добавить в VStack больше 10 вьюх?

var body: some View {
        VStack {
            Text("Placeholder1")
            Text("Placeholder2")
            // ... тут вьюшки с 3 по 10 . . .
            Text("Placeholder11")
        }
    }

Я попробовал — это не компилируется. Да, я тоже сначала был удивлен и погрузился в изучение форума Swift и гитхаба. Результатом моего изучения стало — "все равно не компилируется ¯\_(ツ)_/¯ ". Но подождите, давайте разберемся почему.

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

Недостаток один — высокий порог входа. Пытаясь разобраться в ФП, я столкнулся с огромным количеством теории, функторами, монадами, теорией категорий и алгебраическими типами данных. А как применять ФП на практике, было неясно. Кроме того, примеры приводились на незнакомых мне языках — хаскеле и скале.

Тогда я решил разобраться в ФП самого начала. Разобрался и рассказал на codefest о том, что ФП — это на самом деле просто, что мы уже им пользуемся в Swift и можем пользоваться еще эффективнее.

Объясните дженерики в Swift?

Generic code enables you to write flexible, reusable functions and types that can work with any type, subject to requirements that you define. You can write code that avoids duplication and expresses its intent in a clear, abstracted manner. — Swift docs

Каждый, кто писал на Swift использовал дженерики. Array, Dictionary, Set — самые базовые варианты использования дженериков из стандартной библиотеке. Как они представлены внутри? Расмотрим, как данная основополагающая возможность языка реализована инженерами Apple.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Long Names Are Long" автора Bob Nystrom.

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

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

Использование языка Dart в Google постепенно набирает обороты, и я много занимался подобными code review. Для разработчика языка это очень увлекательный процесс. Я получаю из первых рук представление о том, как люди используют Dart, что действительно полезно для его развития. У меня есть более четкое представление о том, какие ошибки являются общими, и какие функции интенсивно используются. Я чувствую себя как этнограф, ведущий дневник о жизни туземцев.

Но, в любом случае, дело не в этом. Черт бы его побрал, дело даже не в Darts. То, о чем я хожу поговорить, — это то, что я вижу во многих кодах, и что сводит меня с ума: излишне длинные имена.