Заинтересовавшись темой функционального программирования я встал на распутье, — какой фреймворк выбрать для ознакомления. ReactiveCocoa — ветеран в iOS кругах, по нему вдоволь информации. Но он вырос с Objective-C, и хотя это не является проблемой, но все же в данный момент я в основном пишу именно на Swift, — хотелось бы взять решение изначально спроектированное с учетом всех плюшек языка. RxSwift же порт Reactive Extensions, имеющего долгую историю, но сам порт свежий и написанный именно под Swift. На нем я и решил остановиться.
Но специфика документации по RxSwift в том, что описание всех команд ведет на reactivex.io, а там в основном дается общая информация, руки у разработчиков не дошли еще сделать документацию именно для RxSwift, что не всегда удобно. Некоторые команды имеют тонкости в реализации, есть те, о которых в общей документации нет ничего кроме упоминания.
Прочитав все главы вики с RxSwift гитхаба, я сразу решил поразбираться с официальными примерами, тут то и стало ясно, что с RX такое не пройдет, нужно хорошо понимать основы, иначе будешь как мартышка с копипастом гранатой. Я начал разбирать самые сложные для понимания команды, потом те, что вроде понятны, но задав себе вопросы по ним я понял, что лишь догадываюсь на то как верно ответить, но не уверен.
В общем ничтоже сумняшеся я решил проработать все операторы RxSwift. Лучший способ что то понять в программировании — запустить код и посмотреть как он отработает. Затем учитывая специфику реактивного программирования — очень полезны схемы, ну и краткое описание на русском. Закончив сегодня работу, я подумал, что грех не поделиться результатами с тем, кто лишь присматривается к теме реактивного программирования.
Много картинок и текста под катом, очень много!

Сначала в падениях самолётов обвиняли пилотов. Однако реальной причиной этого был их дизайн. Этот урок привёл нас к новой эре удобства для пользователя – однако опасности никуда не делись

Из книги "Удобство пользователей: как скрытые правила дизайна меняют нашу жизнь, работу и игры"



Бомбардировщик Б-17 «Летающая крепость» прошёл путь от чертёжной доски до взлётной полосы всего за 12 месяцев, как раз вовремя для того, чтобы стать зловещей рабочей лошадкой ВВС США во время Второй Мировой войны. Пилоты обожали его за потрясающую прочность: Б-17 мог пролетать сквозь яростные шквалы шрапнели и пуль, и выходить из этого испытания немного покоцанным, но в пригодном для полётов состоянии. Он был символом американского гения, оснащённым десятком пулемётов и удерживаемым в воздухе четырьмя пилотами.

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

Под катом вы найдете ссылки на блоги, рекомендованные резидентами разных платформ: Quora, Stack Overflow, Hacker News, Reddit и др. Авторы этих блогов занимают самые разные должности в ИТ-экосистеме: разработчики, тестировщики, дизайнеры, управленцы, и пишут как статьи для начинающих, так и более продвинутые материалы.

Другие наши тематические подборки:

• 17 независимых блогов по математике, алгоритмам и языкам программирования
• 22 независимых блога о разработке, ИБ, тестировании и геймдеве

В сегодняшнем материале мы собрали одни из наиболее популярных книг, отобранных самими разработчиками — резидентами Reddit, Quora, Stack Exchange, Stack Overflow и Hacker News.

В нашу подборку попали работы по популярным языкам программирования, проектированию ПО, работе с Linux-системами, сборники практических советов для разработчиков — от начинающих, до опытных. Объединяют эту подборку высокие оценки самих программистов, которым эти книги помогали на разных этапах их карьеры.

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

Первая проблема, на которую стоит обратить внимание — это смешивание цветов.

Перевёл после прочтения комментариев к статье «О ненависти к C++». В цитатах можно найти ответы на большинство возникших там вопросов.

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

49. Lisp — это не язык, а строительный материал.
— Alan Kay

48. Ходить по воде и разрабатывать программы, следуя спецификации, очень просто… если они заморожены.
— Edward V Berard

Введение в MVP, MVC, MVVM и VIPER. Что между ними общего и в чем разница.

Делаете все по MVC, а получается некрасиво? Сомневаетесь, переходить ли на MVVM? Слышали о VIPER, но не уверены, стоит ли оно того?

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

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

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

Моя революционная книга обучит вас проверенным техникам по выявлению максимального количества недостатков в своём партнёре. Книга не затрагивает следующие области:

• Обсуждение проблем с сочувствием и пониманием.
• Помощь партнёру в устранении недостатков.

Насколько я могу понять из чтения литературы по code review, эти части отношений настолько очевидны, что вообще не стоят обсуждения.

Как вам нравится такая книжка? Предполагаю, что она вам не очень по душе.

Надо сказать, что многопоточность (сoncurrency) в iOS всегда входит в вопросы, задаваемые на интервью разработчикам iOS приложений, а также в число топ ошибок, которые делают программисты при разработке iOS приложений. Поэтому так важно владеть этим инструментом в совершенстве.
Итак, у вас есть приложение, оно работает на main thread (главном потоке), который отвечает за выполнение кода, отображающего ваш пользовательский интерфейс (UI). Как только вы начинаете добавлять к вашему приложению такие «затратные по времени» куски кода, как загрузка данных из сети или обработка изображений на main thread (главном потоке), то работа вашего UI начинает сильно замедляться и даже может привести к полному его «замораживанию».



Как можно изменить архитектуру приложения, чтобы таких проблем не возникало? В этом случае на помощь приходит многопоточность (сoncurrency), которая позволяет одновременно выполнять две или более независимые задачи (tasks): вычисления, загрузку данных из сети или с диска, обработку изображений и т.д.

Если вы хотите добиться UI отзывчивости вашего iOS приложения, выполняя такие затратные по времени куски кода, как загрузка данных из сети или обработка изображений, то вам нужно использовать продвинутые паттерны, связанные с многопоточностью (сoncurrency), иначе работа вашего пользовательского интерфейса (UI) начнет сильно замедляться и даже может привести к полной его «заморозке». Вам нужно убрать ресурсо-затратные задачи с main thread (главного потока), который отвечает за выполнение кода, отображающего ваш пользовательский интерфейс (UI).

В текущей версии Swift 3 и ближайшей Swift 4 (осень 2017) это можно сделать двумя способами, которые пока не связаны с встроенными языковыми конструкциями Swift, начало реализации которых будет только в Swift 5 (конец 2018).

Один из них использует GCD (Grand Central Dispatch) и ему посвящена предыдущая статья. В этой статье мы покажем, как достичь отзывчивости UI в iOS приложениях с помощью таких абстрактных понятий, как операция Operation и очередь операций OperationQueue. Мы также покажем в чем различие этих двух подходов и какой из них в каких ситуациях лучше использовать.

Код для этой статьи можно посмотреть на Github.

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

Для вдохновения:

Muzli
«Секретный источник вдохновения» — позиционируют продукт создатели. Расширение для Google Chrome автоматически подбирает для вас свежие и интересные новости из мира творчества. Muzli охватывает лучшие работы графических дизайнеров, иллюстрации, завораживающие фотографии, интересные мнения.

Расширение представлено для двух браузеров: Google Chrome и Safari. Внимания заслуживает блог Muzli. Авторы из разных уголков мира публикуют творческие заметки, делятся опытом, рассказывают о дизайне и дают советы.

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

Два года назад я начал негласно исполнять роль iOS-lead в компании Touch Instinct и формированием стабильной работы iOS-отдела. Спустя полгода это трансформировалось в официальную должность. Из-за отсутствия опыта у меня возникало огромное количество проблем, которые вызывали жжение в области верхней части кресла. Это происходило из-за ряда факторов:

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

Если вы стали лидом и первоначальная эйфория сменилась небольшим горением и унынием, то пара советов не будет лишней.

16-17 июля в 95 км от Москвы пройдёт конференция для python-разработчиков PYCON RUSSIA. Традиционно мы делаем серию интервью с докладчиками и организаторами.

В первом посте мы спросили тимлидов четырёх разных компаний, на что они обращают внимание во время собеседований, какие ошибки допускают кандидаты, как понять, что человек подходит в команду, и чего никогда нельзя делать во время интервью. На вопросы ответили: CTO в компании «Точка» Данила Штань, руководитель разработки в ЦИАН Михаил Юматов, руководитель группы Python-проектов в Rambler&Co Олег Чуркин и руководитель PyCharm Community в JetBrains Андрей Власовских.

Тормоз для броненосца USS Indiana BB-1, 1910 год. Эта штуковина должна тормозить корабль водоизмещением 10453 тонны.

Оригинал: iOS App Performance: Instruments & beyond
Автор: Igor M

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

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

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

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

1. DZNEmptyDataSet

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

С этой библиотекой вам необходимо всего лишь соответствовать определённым протоколам и iOS сама позаботиться о просмотре коллекций и выделит необходимое особым шрифтом, в виде красивых сообщений для пользователя. Элементарное решение для каждого проекта под iOS.

“Хорошо, когда человек учится на своих ошибках. Но лучше учиться на ошибках других людей”. — Уоррен Баффет



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

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

Хорошая разработка пользовательского интерфейса решает обе эти проблемы проектирования:

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

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

Здравствуй, Хабр!

Мы сделали видео-уроки по языку Swift на основе бесплатной книги The Swift Programming Language от Эппл.



Все 32 урока доступны на нашем сайте. Несколько уроков – под катом.