С ростом проекта, скорость компиляции проекта замедляется. Особенно это заметно становится, когда тестируешь программу, делая параллельно небольшие изменения в программе.

Сначала давайте узнаем как долго компилируется проект до наших улучшений. ЧТобы это сделать надо в терминале ввести

defaults write com.apple.dt.Xcode ShowBuildOperationDuration -bool YES

Для этого нужно зайти в раздел Product зажать alt и нажать Clean Build Folder, а потом собрать проект заново. Мой проект компилируется 81 секунду. Посмотрим какой результат будет после улучшения.



Нам, в первую очередь, стоит узнать какие места приводят к замедлению компиляции. По умолчанию Xcode не показывает предупреждения, где проблема, но мы можем это исправить.
Самые «тяжелые» места большие функции и проверка типов. Поэтому нам нужно вписать эти две строчки в раздел Build Settings -> Other Swift Flags -> Debug

-Xfrontend -warn-long-function-bodies=100
-Xfrontend -warn-long-expression-type-checking=100

(здесь у нас стоит 100мс время компиляции, мы можем поставить любое число)


Пример моего рабочего проекта



У меня есть участок который занимает 13778 ms, скорее всего у вас не будет такого, но из-за специфики проекта у меня такие участки есть. Так как там построено бинарное дерево для OCR.
Из-за глубокой вложенности друг в друга и определения типа только в самом начале, перед знаком равенства, компилятору требуется много времени понять какой перед ним тип. (Дерево занимает 30 строк, вот его часть)

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

О том, как я решаю данную проблему — под катом.

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

Работа стремится занять все время, отпущенное на нее.
Закон Паркинсона.
Если какая-нибудь неприятность может произойти, — она случается.
Закон Мерфи.

Немного статистики

Одной из причин выделения управления проектами в отдельную область знаний является неопределенность. То, как мы управляем неопределенностью в проекте (в том числе и рисками), напрямую влияет на длительность проекта, на его успех.
По данным многочисленных исследований Standish Group¹ для традиционных методов управления проектами, только 44% проектов обычно завершаются вовремя. В среднем проекты занимают 222% процента от изначально запланированной длительности, 189% от начального бюджета. 70% проектов сокращают исходный объем работ проекта, 30% проектов закрываются досрочно.
И хотя в последнее время, с развитием инструментов и техник управления проектами, эти цифры стали уменьшаться, общая картина говорит о том, что мы как менеджеры проектов плохо делаем свою работу.
Данная статья рассматриваем использование относительно новый метод управления проектами, метод критических цепей (МКЦ), сравнивая его с традиционным подходом к управлению проектами.

В 2016 из-за давней мечты о видео-играх и «хайпа» вокруг AI я начал изучать Python.
Computer Science is Fun потому только неделю назад я обучил первую recognition модель, но без использования Python (в computer science много соблазнов). Как и предсказывал Андрей Себрант (Yandex), новая технологическая революция свершилась. Почему? Сделать приложение по распознаванию изображений проще, чем компьютерную игру. Хватит часа или двух.



Я пошел «сложным» путем – не выбирал из четырех уже обученных моделей, а натренировал свою. Библиотека Core ML от Apple позволяет сделать это 6 строчками кода или через графический интерфейс в playgrounds.

import CreateMLUI
let builder = MLImageClassifierBuilder()
builder.showInLiveView()

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

Раньше я только читал про machine learning. Когда сам попробовал – столкнулся с тремя ожидаемыми проблемами/выводами:

1. Данные – самая важная часть.
2. Удобный интерфейс(CoreML). Все просто работает и не очень хочется лезть в исходный код, чтобы разобраться в деталях. Машинное обучение доступно любому пользователю, но сложные подробности инженеры Apple постарались спрятать.
3. Модель это «черный ящик». Я не знаю правил по которым модель считает, что на фотографии два процента «кота».

Эксперимент с распознаванием «котов-людей» натолкнул на мысль, что алгоритм классификации справится со «стилем».

Новогодние праздники прошли, а мое стремление писать полезные и не очень статьи — нет! Сегодня поговорим о UITableView, работе с UITableViewDataSource и переиспользовании ячеек. Затронем как установить рут контроллер без сториборда, ошибки при работе с таблицей, лейаут и большой заголовок для UINavigationBar.

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

Кому нужны модульные тесты? Не Вам — Ваш код идеален. Но все же, Вам просто нужно прочитать эту статью, которая должна больше рассказать о написании модульных тестов на Swift’е. Вдруг это Вам в дальнейшем пригодиться.

Модульное тестирование являются отличным способом для написания безупречного кода; тестирование поможет Вам найти большинство ошибок на ранней стадии написания проекта. Как показывает опыт: если у Вас возникают трудности при тестировании кода, тогда у Вас возникнут сложности с его поддержкой или отладкой.

Модульное тестирование работает с изолированными “микрокомпонентами”. Зачастую Вам нужно «мокировать» классы – то есть обеспечить фейк функциональной реализацией, чтобы изолировать специфический микрокомпонент, таким образом, он сможет быть протестирован. В Objective-C существует несколько сторонних фреймворков, которые помогают это реализовать. Но они еще не доступны в Swift’е.

В этом руководстве Вы научитесь, писать свои собственные mock-обьекты, fakes и stub'ы, чтобы покрыть тестами давольно простое приложение, которое поможет вам запомнить дни рождения ваших друзей.

Одна из полезных (по моему мнению) фич iOS 12, представленных на WWDC 2018 — Siri Shortcuts.

Шорткат (англ. shortcut) — быстрая команда, короткий способ совершить какое-либо действие в обход стандартному сценарию.

В своих приложениях вы можете привязывать шорткаты для некоторых действий. Обучаясь на том, как и когда пользователь их выполняет, Siri начинает по-умному, в нужное время и место, предлагать ему эти шорткаты и, что самое крутое, пользователь сможет их вызывать фразами, которые сам к ним привяжет! Под катом подробнее.

Эта статья рассказывает о времени выполнения и о расходе памяти большинства алгоритмов используемых в информатике. В прошлом, когда я готовился к прохождению собеседования я потратил много времени исследуя интернет для поиска информации о лучшем, среднем и худшем случае работы алгоритмов поиска и сортировки, чтобы заданный вопрос на собеседовании не поставил меня в тупик. За последние несколько лет я проходил интервью в нескольких стартапах из Силиконовой долины, а также в некоторых крупных компаниях таких как Yahoo, eBay, LinkedIn и Google и каждый раз, когда я готовился к интервью, я подумал: «Почему никто не создал хорошую шпаргалку по асимптотической сложности алгоритмов? ». Чтобы сохранить ваше время я создал такую шпаргалку. Наслаждайтесь!

Об авторе: Хэм Фокке — разработчик и консультант ThoughtWorks в Германии. Устав от деплоя в три ночи, он добавил в свой инструментарий средства непрерывной доставки и тщательной автоматизации. Сейчас налаживает такие системы другим командам для обеспечения надёжной и эффективной поставки программного обеспечения. Так он экономит компаниям время, которое эти надоедливые людишки тратили на свои выходки.

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

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

Перевод статьи Мэтта Галлагера.

В этой статье речь пойдёт об отсутствии потокового выполнения (threading) и инструментов синхронизации потоков в Swift. Мы обсудим предложение о внедрении «многопоточности» (concurrency) в Swift и то, как до появления этой возможности потоковое выполнение в Swift будет подразумевать использование традиционных мьютексов и общего изменяемого состояния (shared mutable state).

Использовать мьютекс в Swift не особенно сложно, но на этом фоне хотелось бы выделить тонкие нюансы производительности в Swift — динамическое выделение памяти во время захвата замыканиями. Мы хотим, чтобы наш мьютекс был быстрым, но передача замыкания для исполнения внутри мьютекса может снизить производительность в 10 раз из-за дополнительных расходов памяти. Давайте рассмотрим несколько способов решения данной проблемы.