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



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

Даже для самого что ни на есть начинающего разработчика (скорее, на которого и рассчитан данный очерк), надеюсь, не секрет, что в коде не должно присутствовать никаких т.н. «hardcoded»-значений и прочих всяких там «magic numbers». Почему – тоже, надеюсь, понятно, а если нет, то в Сети имеются десятки, а то и сотни статей на эту тему, а также написан классический труд. «Android Studio» (наверное, не во всех случаях, но все же) даже любит генерировать «warnings» на эту тему и предлагать выносить строки и т.д. в ресурсные файлы. «Xcode» (пока?) такими подсказками нас не балует, и разработчику приходится самостоятельно держать себя в узде или, скажем, получать по рукам от коллег после «code review».

Все это касается и используемых в приложении цветов.

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

В кратце, данная библиотека позволяет обучаться и использовать разные виды жестов, выполненные одним пальцем, по всей площади дисплея и в любых iOS приложениях на девайсах с поддержкой 3D-touch. Теперь подробнее разберем на примере.

Вместе с релизом в open source языка Swift 3 декабря 2015 года Apple представила децентрализованный менеджер зависимостей Swift Package Manager.

К публичной версии приложили руку небезызвестные Max Howell, создатель Homebrew, и Matt Thompson, написавший AFNetworking. SwiftPM призван автоматизировать процесс установки зависимостей, а также дальнейшее тестирование и сборку проекта на языке Swift на всех доступных операционных системах, однако пока его поддерживают только macOS и Linux. Если интересно, идите под кат.

От переводчика:
Предлагаю вашему вниманию перевод двух постов из блога John Regehr. Я решил объединить их в одной публикации потому, что, во первых, они имеют небольшой объём, и, во-вторых, второй пост является продолжением первого, и является ответом на комментарий к первому посту на Hacker News.

Ссылка на первый пост
Ссылка на второй пост

Часть 1. Неопределённое поведение != Небезопасное программирование

Неопределённое поведение (UB) в C и C++ представляет собой опасность для разработчиков, особенно если код работает с недоверенными данными. Менее известно, что неопределённое поведение существует в промежуточном представлении (IR) большинства оптимизирующих AOT компиляторов. Например, LLVM IR имеет значение undef и «отравленные» значения в дополнение к взрывоопасному UB языка С. Когда люди начинают беспокоиться об этом, типичная реакция такова: “Что? LLVM IR так же плох, как и C!” Эта статья объясняет, почему считать так неверно.

Доброго времени суток!

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

Простые и сложные ячейки

Я разделяю ячейки на простые и сложные.

Простые ячейки — это такие ячейки, которым для выполнения своего предназначения достаточно отображать некоторые данные (текст, картинка) и отвечать простыми действиями на действия пользователя.

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

В данной статье речь пойдет о таблице с простыми ячейками.

Проблема

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

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

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

За 9 лет работы фич в проектах роботов становилось все больше, запутаться в коде становилось все проще.

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

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

~ Продать MacBook Pro, которому уже перевалило за 3 года
~ Сменить 13'' экран на парочку 22'' и повысить комфорт разработки
~ Получить мощную машину для быстрой компиляции проектов на Swift

Это основные причины, повлиявшие на покупку Mac Mini. Первые два пункта достаточно очевидны, но вот к последнему пункту явно нужны комментарии…

В этом туториале мы создадим простое, но полнофункциональное приложение под watchOS 4. А конкретнее, мы будем работать над приложением придуманной авиакомпании Air Aber для Apple Watch.

Из этого туториала вы узнаете:

• Как добавлять целевую сборку watchOS 4 в приложение iOS.
• Как обмениваться данными между двумя целевыми сборками.
• Как добавить в Storyboard контроллер интерфейса watchOS и расположить объекты интерфейса.
• Как создать подкласс WKInterfaceController и соединить всё вместе.
• Как добавить новый контроллер интерфейса, добавить к нему таблицу и создать прототип из строк.
• Как создать подкласс класса WKInterfaceController, чтобы заполнить таблицу, настроить строки и обрабатывать выбор.
• Как сделать контроллер интерфейса модальным и передавать ему данные для отображения.
• Как создавать анимации на основе изображений.
• Как использовать API анимации watchOS 4.

What do we have?

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

Как мы размещаем элементы на экране?

• Qt предлагает использовать контейнеры, умеющие внутри себя располагать элементы определенным образом. Вкладывая эти контейнеры друг в друга, можно получить необходимую расстановку.
• WPF/XAML предлагает аналогичные контейнеры.
• Android предлагает аналогичные контейнеры + систему констреинтов.
• iOS предлагает Autolayout. Нужно описать набор ограничений (уравнений), непротиворечиво и однозначно описывающих расположение элементов. Решив систему уравнений с этими ограничениями, движок получит координаты и размеры элементов.
• У Delphi есть anchors: прибивание краев к контейнеру. Очень похоже на resizing masks в iOS.
• В web на сколько я понимаю используется вкладывание друг в друга контейнеров, поведение которых описывается стилями.

What is the problem with this?

We need to use code for special cases

Описанные инструменты заточены под типовые случаи, зачастую мы не можем (или можем, но это сильно неудобно) описать расположение какого-то элемента с помощью этих инструментов. Приходится делать это в коде. Логика описания layout'а размазывается по нескольким местам.
Должен быть способ лучше.

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

Говоря об эффективной разработке систем машинного обучения, всегда поднимается вопрос контроля скорости обучения, анализа процесса обучения, сбора различных метрик обучения и тд. Особая сложность заключается в том, что мы (люди) привыкли оперировать 2х и 3х мерными пространствами, описывая различные процессы вокруг нас. Процессы внутри нейронных сетей происходят в многомерных пространствах, что серьезно усложняет их понимание. Осознавая это, инженеры по всему миру стараются разработать различные подходы к визуализации или трансформации многомерных данных в более простые и понятные формы.

Существуют целые сообщества, решающие такого рода задачи, например Distill, Welch Labs, 3Blue1Brown.

Не перестаю задаваться вопросом — какие у Apple планы на Swift и Objective-C? Когда в 2014 году появился Swift, его создатель Крис Латтнер утверждал, что эти два языка смогут сосуществовать бесконечно долго. Из почтовой рассылки пользователям Xcode:

3 Июня 2014
McLaughlin, Michael P.
Кто-нибудь знает, действительно ли Apple собирается прекратить поддержку С и С++? Fortran уже не поддерживается, хотя осталось еще много кода на Fortran, и сравнительно нового, как в MultiNest.
Пожалуйста, скажите, что это не так. Не все считают, что «опытные пользователи» — это те, кто просто создает полнометражные мультики. Многие из них ученые и инженеры.

Здравствуйте, Michael,
Мы не строили планы на что-либо подобное. Swift — это просто новый вариант разработки под платформу. Мы не собираемся прекращать поддержку ни C, ни C++, ни Objective-C. Если вы разрабатываете на одном из этих языков, можете свободно продолжать его использовать.

— Крис.

Дело в том, что в это никто не верит. Крис Латтнер уже давно покинул Apple, и если его утверждение окажется ложным, он не сможет принять критику от лица компании. В целом разработчики согласились на том, что Apple в конечном итоге откажется от Objective-C, и Swift станет единственным языком «первого класса» для разработки Cocoa-приложений.

Рассказывать о том, что такое машинное обучение и искусственный интеллект, в 2017 году наверное нет необходимости. На эту тему уже написано большое количество как публицистических статей, так и серьезных научных работ. Поэтому предполагается, что читатель уже знает, что это такое. Говоря о машинном обучении, сообщество data scientist и software engineers, как правило подразумевает глубокие нейронные сети, которые приобрели большую популярность по причине своей производительности. На сегодняшний день в мире существует большое количество различных программных решений и комплексов для решения задачи искусственных нейронных сетей: Caffe, TensorFlow, Torch, Theano(rip), cuDNN etc.

Swift

Swift — инновационный, protocol — oriented, open source язык программирования, выращенный в стенах компании Apple Крисом Латнером (недавно покинувшим компанию Apple, после SpaceX и обосновавшимся в Google).
В Apple’s OSs уже были различные библиотеки для работы с матрицами и векторной алгеброй: BLAS, BNNS, DSP, впоследствии объединенные под крышей одной библиотеки Accelerate.
В 2015 появились небольшие решения для реализации математики на основе графической технологии Metal.
В 2016 появился CoreML:

CoreML способен импортировать готовую, натренированную модель (CaffeV1, Keras, scikit-learn) и далее предоставить разработчику возможность экспортировать ее в приложение.
То есть, вам необходимо: Собрать модель на другой платформе, на языке Python или C++, используя сторонние фреймворки. Далее обучить ее на стороннем аппаратном решении.
И только после этого вы можете импортировать и работать на языке Swift. На мой взгляд очень нагромождено и сложно.

Можно долго смотреть на три вещи: как течет вода, как имплементируется CoreFoundation в Linux Swift, и как не обновляется документация Perfect

Сначала кратко для тех, кто не в курсе: Perfect — это один из самых стабильных серверных фреймворков на Swift. (benchmark)

Задача:

Сервер Perfect на Linux c MySQL и Protocol Buffers для общения с приложением-клиентом

Важное требование:

Мы прогрессивные хипстеры со свифтом (sarcasm), поэтому дайте самую последнюю версию Swift 4.0.2

Еще одна архитектура?

В последние годы заметно набрала обороты тема альтернативных архитектур для создания приложений под платформу iOS. На доске особого почета уже закрепились некоторые силачи, известные как MVP, MVVM, VIPER. А кроме них есть еще множество других, не столь распространенных.

Среди силачей, на мой взгляд, ни одна не является универсальной таблеткой для всех случаев:

• если нужно сделать пару маленьких экранов со статическим набором данных, то вводить полноценный VIPER довольно затратно;
• если не нравится реактивный подход, то MVVM с большой долей вероятности пройдет мимо;
• если столкнулся с проблемой Massive в большом проекте, то MVC наверняка уже не подходит.

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

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

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

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

Вскоре после публикации исходного кода Swift, я написал статью о том как реализованы слабые ссылки. Время не стоит на месте и всё меняется, реализация слабых ссылок в Swift тоже. Сегодня я расскажу о новой реализации и сравню ее со старой. Спасибо Guillaume Lessard за идею для поста.

Старая реализация

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

В старой версии Swift объекты имели 2 счетчика ссылок: счетчик для сильных ссылок и счетчик для слабых. Когда счетчик сильных ссылок становится равен нулю, а слабых еще нет — объект уничтожается, но память не освобождается. Поэтому в памяти остается так называемый “зомби объект” на который ссылается слабая ссылка.

Когда слабая ссылка загружается, среда времени выполнения (runtime) проверяет является ли объект “зомби”. Если он “зомби” то runtime обнуляет слабую ссылку и уменьшает счетчик слабых ссылок на 1. Когда счетчик слабых ссылок достигает 0 — память освобождается (deallocated). Это означает, что полностью объект удаляется только тогда, когда все слабые ссылки на него обнуляются.

Мне нравилась простота этой реализации, но были у нее и недостатки:

 
Создание iOS-приложения – непростая задача. Разработчикам хочется как можно быстрее завершить этот процесс и наконец запуститься в AppStore. Но на этом все не заканчивается: впереди у создателей долгие годы исправления ошибок, улучшения функций и совместной работы с другими разработчиками. Мы бы хотели немного облегчить им жизнь и для этого решили разобрать три вещи, которые нужно избегать при iOS-разработке (спасибо Envato Tuts+ за информацию).

Есть мнение, что Swift — особенно благодаря развитию в опенсорсе — уже сейчас применим за рамками софта для платформ Apple. Наши коллеги из «Рамблера», включая разработчика Самвела Меджлумяна, даже пробуют этот язык в качестве серверного решения. На встрече сообщества CocoaHeads Самвел перечислил готовые продукты для построения сервера на Swift, сравнил их между собой и показал короткое демо.

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

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

Напомню, что основным элементом представленного способа задания стилей является обобщенное замыкание:

typealias Decoration<T> = (T) -> Void

Использовать данное замыкание для придания свойств UIView можно следующим образом: