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

Во всяком случае, так говорит руководитель мобильной разработки Prisma Андрей Володин. А еще о том, как идеи перетекают в мобильную разработку из GameDev, чем отличаются парадигмы, почему в Android нет нативного размытия — да много еще чего, продуктивный вышел выпуск AppsCast. Под катом поговорим про доклад Андрея на AppsConf без спойлеров.

Захари Бир создаёт рисунки, используя цветовую палитру от цветовой схемы для Мака Solarized и собственную программу для генерации изображений Geometriq.

Пару лет назад я влюбился в цветовую палитру: цвет, чуть темнее белого, выделяемый жёлто-оранжевым и нейтральным голубым на тёмно-сером фоне, «цвете телевизора, переключенного на мёртвый канал», как писал Уильям Гибсон в «Нейроманте». Эти цвета принадлежали к теме Solarized Dark популярного редактора кода для MacOS под названием TextMate. Честно говоря, сначала мне она не очень понравилась. Но вскоре я обнаружил, что не могу работать ни в какой другой цветовой схеме. Если ты весь день пялишься на экран, то поневоле начнёшь придираться к шрифтам и цветам.

Оказалось, что я не один такой. По профессии я не кодер, но мне нравится использовать редакторы кода для написания текстов и организации заметок. Переключившись с Мака на Windows, я стал искать соответствующие инструменты, и начал видеть Solarized Dark и её близкую родственницу Solarized Light, использующую ту же палитру из 16 цветов, практически везде. Сложно сказать, какое количество программистов её использует. Схема свободна и имеет открытый код, поэтому статистики по продажам у неё нет. Она есть в любом крупном редакторе кода и многих других инструментах. Microsoft даже включила её в набор популярного редактора VS Code. У Solarized есть много поклонников.

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

• назначать иконку приложения в строке меню
• делать приложение размещенным только в строке меню
• добавлять пользовательское меню
• показывать всплывающее по запросу пользователя окно и прятать его, когда необходимо, используя Event Monitoring

Замечание: это руководство предполагает, что вы знакомы со Swift и macOS.

Всем привет!

Рождество давно прошло, но после него у нас осталась занимательная история о том, как при помощи нечасто используемой возможности Core Animation можно создать пользователям праздничное настроение. Делюсь переводом статьи моего лондонского коллеги Алексиса.

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

Я родился и вырос в Испании, на Тенерифе — солнечном острове посреди Атлантического океана недалеко от побережья Африки. И, поверьте мне, Рождество на Тенерифе сильно отличается от Рождества в Лондоне, где я встречал его последние два года (с тех пор как начал работать в Badoo).

Одним из преимуществ жизни в Лондоне для меня стало созерцание снежинок. Здесь я увидел их впервые в жизни, это было просто невероятно!

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

Так уж случилось, что мне поручили одну необычную задачу со следующим описанием:

Сейчас практически 100% приложений используют работу с сетью, поэтому вопрос организации и использования сетевого слоя встает перед каждым. Есть два основных подхода к решению этой проблемы, это либо использование сторонних библиотек, либо собственная реализация сетевого слоя. В данной статье мы рассмотрим именно второй вариант, причем попробуем реализовать сетевой слой с использованием всех последних возможностей языка, применяя протоколы и перечисления. Это избавит проект от лишних зависимостей в виде дополнительных библиотек. Те, кто хоть раз видел Moya, сразу узнают множество схожих деталей в реализации и использовании, так оно и есть, только в этот раз мы все сделаем своими руками, не трогая Moya и Alamofire.

Я хотела бы представить концепцию Функционального Программирования новичкам самым простейшим образом, выделив некоторые его преимущества из множества остальных, которые реально позволят сделать код более читаемым и выразительным. Я подобрала для вас интересные демонстрационные примеры, которые находятся на Playground в Github.

Функциональное Программирование: Определение

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

В Мире Swift для этого есть все условия, ибо функции здесь являются такими же полноправными участниками процесса программирования, как и объекты, а проблема изменяемости (mutation) решается на уровне концепции value ТИПОВ (структур struct и перечислений enum), которые помогают управлять изменяемостью (mutation) и четко сообщают о том, как и когда это может произойти.

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

В этой статье мы сфокусируемся на использовании встроенных в Swift (то есть «из коробки») элементов Функционального программирования и понимании того, как можно их комфортно использовать в вашем приложении.

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

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

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

Источники вдохновения

Этот пост возник благодаря недавней публикации Араса Пранцкевичуса о докладе, предназначенном для программистов-джуниоров. В нём рассказывается о том, как адаптироваться к новым ECS-архитектурам. Арас следует привычной схеме (объяснения ниже): показывает примеры ужасного ООП-кода, а затем демонстрирует, что отличным альтернативным решением является реляционная модель (но называет её «ECS», а не реляционной). Я ни в коем случае не критикую Араса — я большой фанат его работ и хвалю его за отличную презентацию! Я выбрал именно его презентацию вместо сотен других постов про ECS из Интернета потому, что он приложил дополнительные усилия и опубликовал git-репозиторий для изучения параллельно с презентацией. В нём содержится небольшая простая «игра», используемая в качестве примера выбора разных архитектурных решений. Этот небольшой проект позволил мне на конкретном материале продемонстрировать свои замечания, так что спасибо, Арас!

Слайды Араса выложены здесь: http://aras-p.info/texts/files/2018Academy — ECS-DoD.pdf, а код находится на github: https://github.com/aras-p/dod-playground.

Я не буду (пока?) анализировать получившуюся ECS-архитектуру из этого доклада, но сосредоточусь на коде «плохого ООП» (похожего на уловку «чучело») из его начала. Я покажу, как бы он выглядел на самом деле, если бы правильно исправили все нарушения принципов OOD (object-oriented design, объектно-ориентированного проектирования).

Спойлер: устранение всех нарушений OOD приводит к улучшениям производительности, аналогичным преобразованиям Араса в ECS, к тому же использует меньше ОЗУ и требует меньше строк кода, чем ECS-версия!

TL;DR: Прежде чем прийти к выводу, что ООП отстой, а ECS рулит, сделайте паузу и изучите OOD (чтобы знать, как правильно использовать ООП), а также разберитесь в реляционной модели (чтобы знать, как правильно применять ECS).

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

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

Ещё одной проблемой является недостаточная проработка идеи. Зачастую заказчик видит общую концепцию приложения, но слабо представляет детали. Это приводит к лишним затратам на обсуждение и переписывание требований.

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

Вы узнаете:

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

AudioKit — это аудиофреймворк, разработанный аудиоинженерами, программистами и музыкантами специально для iOS и OSX. Он предоставляет инструменты для обработки и синтезирования звука. Под капотом — это смесь из Swift, Objective-C, C++ и С, и Audio Unit API от Apple. Потрясающие (и довольно сложные) технологии завёрнуты в очень дружелюбное Swift API, к которому можно обращаться прямо из Xcode Playgrounds!

В этом туториале мы отправимся в путешествие по AudioKit, а заодно и истории синтезирования звука. Вы узнаете об основах физики звука и том, как работали первые синтезаторы, такие как Hammond Organ. Также будут рассмотрены и современные техники, например, семплинг.

Приготовьте ваш любимый напиток, устраивайтесь поудобнее и вперёд!

Однажды я наткнулся на книгу под названием «Создай свою нейросеть», под авторством Тарика Рашида. В отличие от многих других книг по нейронным сетям, в этой все подавалось простым языком, c достаточным количеством примеров и советов

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

Есть такой известный факт в истории российского IT: в 1991 году московской фирме «Параграф» удалось заключить крупный контракт с Apple.



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

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

О том, что произошло между двумя этими событиями, и пойдет речь ниже.

Все записано со слов очевидцев и восстановлено по материалом публикаций в прессе.

Меня зовут Максим Котин, я автор книг «Чичваркин Е… гений» и «И ботаники делают бизнес». И я продолжаю публиковать на «Хабре» глав из своей книги о «Параграфе» — первом стартапе из России, покорившем мир. В целом о замысле можно прочитать здесь.

Книга называется «Пионеры Кремниевой долины». Она еще в работе, но вы можете получить все написанные главы (в epub или pdf), подписавшись на мою бесплатную рассылку — на текущий момент закончено 13 глав.

Новые главы я присылаю подписчикам по мере готовности. Иногда я также делюсь в рассылке своими наблюдениями о бизнесе, стартапах и саморазвитии, но не чаще раза в неделю (например: Как справляться с адовыми задачами). Добро пожаловать, если что.

Глава 8, приведенная ниже, публикуется с небольшими сокращениями.

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

Перед вами перевод статьи Adrian Hajdin, которая была опубликована на сайте freeCodeCamp. Под катом автор понятно и лаконично объясняет, в чем преимущество async/await, и на конкретном примере показывает, как использовать этот синтаксис.

Некоторое время назад ссылка на статью "Modern dining philosophers" распространилась по ресурсам вроде Reddit и HackerNews. Статья интересная, она показывает несколько решений этой известной задачи, реализованных на современном C++ с использованием task-based подхода. Если кто-то это статью еще не читал, то имеет смысл потратить время и прочесть ее.

Однако, не могу сказать, что представленные в статье решения мне показались простыми и понятными. Вероятно это как раз из-за использования тасков. Слишком уж их много создается и диспетчируется посредством разнообразных диспетчеров/сериализаторов. Так что не всегда понятно, где, когда и какие задачи выполняются.

При этом task-based подход не является единственным возможным для решения подобных задач. Почему бы не посмотреть, как задача "обедающих философов" решается посредством моделей Акторов и CSP?

Посему попробовал посмотреть и реализовал несколько решений этой задачи как с использованием Акторов, так и с использованием CSP. Код этих решений можно найти в репозитории на GitHub-е. А под катом пояснения и объяснения, так что кому интересно, милости прошу под кат.

Многие разработчики считают, что Auto Layout — это тормозная и проблемная штука, и крайне сложно заниматься его отладкой. И хорошо, если этот вывод сделан на основе собственного опыта, а то бывает и просто «я слышал, не буду даже и пытаться с ним подружиться».

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

Это новая статья из разбора задач с собеседований в Google. Когда я там работал, то предлагал кандидатам такие задачи. Потом произошла утечка, и их запретили. Но у медали есть обратная сторона: теперь я могу свободно объяснить решение.

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

Начну с банального.

Core Data – это фреймворк, который управляет и хранит данные в приложении. Можно рассматривать Core Data, как оболочку над физическим реляционным хранилищем, представляющую данные в виде объектов, при этом сама Core Data не является базой данных.

Объекты Core Data

Данная статья определяет основные понятия стандартной библиотеки С++. Она приводится для того чтобы на неё ссылаться в дальнейшем.

Наибольшей частью стандартной библиотеки С++ является библиотека STL (Standard Template Library – Стандартная Библиотека Шаблонов). Библиотека STL содержит пять основных видов компонентов:

• контейнер (container): управляет набором объектов в памяти.
• итератор (iterator): обеспечивает для алгоритма средство доступа к содержимому контейнера.
• алгоритм (algorithm): определяет вычислительную процедуру.
• функциональный объект (function object): инкапсулирует функцию в объекте для использования другими компонентами.
• адаптер (adaptor): адаптирует компонент для обеспечения различного интерфейса.