После прочтения данной статьи, вы сможете использовать Quick и Nimble в своих проектах!


Написание прекрасных работоспособных приложений — одно дело, но написание хороших тестов, которые подтверждают ожидаемое поведение вашего приложения, — задача намного сложнее. В этой статье мы рассмотрим один из доступных подходов тестирования приложений, behavior-driven testing, используя два чрезвычайно популярных фреймворка под названием Quick и Nimble.

Вы узнаете о behavior-driven testing: изучите что это такое, почему это чрезвычайно мощная концепция и насколько легко писать читабельные тесты с помощью фреймворков Quick и Nimble.

Вы будете писать тесты для удивительно простой и забавной игры под названием AppTacToe, в которой вы играете в игру Tic Tac Toe против компьютера, изображая iOS персонажа, играющего против злого Android игрока!

Этот пост является вольным переводом статьи What’s new in Swift 4.1 by Paul Hudson

Swift 4.1 — первый минорный релиз Swift 4, который принес с собой некоторые полезные фишки, такие как автоматическое применение Equatable и Hashable, условные соответствия и т.д.

Убедитесь, что поставили себе как минимум Xcode 9.3, затем создайте новый playground. Давайте посмотрим на новые фичи этой версии...

Xcode 9.3 и Swift 4.1, наконец-то, уже не являются бета! Данный релиз содержит долгожданные улучшения стандартной библиотеки и самого языка. Если вы не следите за процессом Swift Evolution, то эта статья для Вас.


В этой статье вы узнаете о наиболее значительных изменениях, внесенных в Swift 4.1.

Эта статья требует наличия Xcode 9.3, поэтому убедитесь, что данная версия Xcode установлена.

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



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

Apple имеет несколько API, которые помогут защитить ваши приложения, и вы изучите их при работе с Keychain. Кроме того, вы будете использовать CryptoSwift — хорошо изучите и просмотрите библиотеку с открытым исходным кодом, которая реализует криптографические алгоритмы.

Этот пост является вольным переводом статьи Swift vs. Kotlin — the differences that matter by Krzysztof Turek

Вы наверняка видели это сравнение Swift и Kotlin: http://nilhcem.com/swift-is-like-kotlin/. Довольно интересное, правда? Я согласен, что в этих языках много схожего, но в этой статье я обращу внимание на некоторые аспекты, которые их все-таки разнят.

Пользователи хотят видеть изменения

Анимированное обновление списков всегда было непростой задачей в iOS. Что неприятно, это всегда было рутинной задачей.

Приложения крупных компаний, таких как Facebook, Twitter, Instagram, VK, используют таблицы. Более того, почти каждое iOS приложение написано с использованием UITableView или UICollectionView и пользователи хотят видеть, что изменяется у них на экранах, по этой причине reloadData не подходит для обновления экрана. Посмотрев несколько уже имеющихся фреймворков для данной задачи, я удивился, как много они в себе обобщают, помимо расчета анимаций. Некоторые же вообще при вставке одного элемента в начало, радостно сообщали о перемещениях всех остальных элементов.

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

В параллельном программировании в 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. На мой взгляд очень нагромождено и сложно.