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

Закрыв глаза на общеизвестные недостатки этой популярной парадигмы, в список ее минусов можно отнести и самое главное ее достоинство — гибкость разработки. Почему же это минус? Достаточно очевидно, что гибкость, кроме основной возможности решать бизнес-задачи, дает возможность делать это самыми разными способами. Справедливо, что на один правильный подход обязательно найдется десяток неправильных, при том, что бизнес-задача будет корректно решена в любом из случаев, но с отличиями «в реализации», расширяемость и прозрачность которой уже будет зависеть от правильности примененного подхода.

Эпиграф:
— Как я тебе оценю, если неизвестно что делать?
— Ну там будут экранчики и кнопочки.
— Дима, ты сейчас всю мою жизнь описал в трёх словах!
(с) Реальный диалог на митинге в игровой компании



Набор потребностей и отвечающих им решений, о которых я поговорю в этой статье, сформировался у меня в ходе участия примерно в десятке крупных проектов сначала на Flash, а позже на Unity. Самый крупный из проектов имел больше 200000 DAU и дополнил мою копилку новыми оригинальными вызовами. С другой стороны, подтвердилась уместность и нужность предыдущих находок.

В нашей суровой реальности каждый, кто хоть раз архитектурил крупный проект хотя бы в своих мыслях, имеет свои представления о том, как надо делать, и часто готов отстаивать свои идеи до последней капли крови. У окружающих это вызывает улыбку, а менеджмент часто смотрит на всё на это как на огромный чёрный ящик, который никому углом не упёрся. Но что если я скажу вам, что правильные решения помогут сократить создание нового функционала в 2-3 раза, поиск ошибок в старом в 5-10 раз, и позволят делать многие новые и важные вещи, которые раньше были вообще недоступны? Достаточно лишь впустить архитектуру в сердце своё!
Архитектурные решения для мобильной игры. Часть 2: Command и их очереди
Архитектурные решения для мобильной игры. Часть 3: View на реактивной тяге

От переводчика: сегодня публикуем для вас статью Праякты Татавадкар, она разработчик с небольшим стажем, но знания и опыт позволили ей получить работу в Google (со второй попытки), стать членом команды разработчиков YouTube.

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

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

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

Недавно мы полностью переработали приложение Pyrus для Android. Первая версия приложения работала аж под Android 2.2. Отказавшись от поддержки Android ниже 4.1, мы смогли выплатить накопленный технический долг и заметно упростили исходный код. Да, мы потеряли часть пользователей (менее 1%), но зато мы сэкономили время разработчиков на исправление редких багов. Мы сможем инвестировать его в развитие функционала для всех текущих и новых пользователей. В долгосрочной перспективе это гораздо важнее.

Здесь мы делимся опытом, который может быть полезен тем, кто подумывает начать разработку для платформы Android.

Я всегда был фанатом багов и уязвимостей «на поверхности», всегда завидовал чувакам, которые пишут эксплойты для самых защищённых ОС, а сам умел только скрипткиддить (термин из нулевых). Однако мой пост про уязвимости в системах контроля версий набрал более 1000 лайков на Хабре и остаётся топ1 постом за всю историю Хабра, несмотря на то, что был написан 9(!) лет назад.

И сегодня я хотел бы на пальцах показать и рассказать про такую штуку, как вардрайвинг. А точнее, как стандартными средствами MacOS можно добыть пароли от Wi-Fi соседей. Нелёгкая забросила меня на очередную квартиру. Как-то исторически сложилось, что я ленивый. Пару лет назад я уже писал, что моя лень, новая квартира и провод Beeline (бывшая Corbina) помогли мне найти багу у Билайна и иметь бесплатно интернет в их сети. «Сегодня» происходит «подобное», я на новой квартире, нет даже провода, но есть много сетей у соседей.


Заколебавшись расходовать мобильный трафик, я решил, что «соседям надо помогать», и под «соседями» я имел введу себя…

Пока в соседней комнате готовят оливье, я пишу небольшой туториал как рисовать кодом. Сразу представляются строчки кода с дробными числами, где ведём линию по точкам. А для вычисления радиуса окружности берём яд змеи, надежность хранения фото в iCloud и шепчем заклинание. Пугает, понимаю. Даже в ролике на YouTube вставил шутку:

— “Ааастановите, пожалуйста, вот у магазина” — прокричал герой российского сериала.

В целом, дорогой друг, ты прав. Будут и дробные числа, и куча строчек кода. Но будет намного проще. Интересно? Давай к делу.

В дизайне популярен atomic design и дизайн системы: это когда всё состоит из компонентов, от контролов до экранов. Программисту писать отдельные контролы несложно, но что делать с целыми экранами?

Разберём на новогоднем примере:

• налепим всё в кучу;
• разделим на контроллеры: выделим навигацию, шаблон и контент;
• повторно используем код для других экранов.

«Посетитель» (“Visitor”) – это один из поведенческих шаблонов, описанных в хрестоматийной книге «банды четырех» (“Gang of Four”, “GoF”) “Шаблоны проектирования” (“Design Patterns: Elements of Reusable Object-Oriented Software”).

Давайте посмотрим на библиотеки не с той стороны, которая нам привычнее всего, то есть пользовательской, а с точки зрения разработчика библиотеки мобильной разработки. Поговорим, каких подходов стоит придерживаться, разрабатывая свою библиотеку. Начнем, конечно, с проектирования такого API, которым вы сами хотели бы пользоваться, который был бы удобен. Подумаем, что нужно учесть, чтобы сделать не просто работающий код, а по-настоящему хорошую библиотеку, и дойдем до того, как выпускать настоящий взрослый публичный релиз. Поможет нам в этом Ася Свириденко, которая поделится своим немалым опытом разработки мобильной библиотеки SpeechKit в Яндексе.

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

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

— Прототипное наследование — это прекрасно
JavaScript — это объектно-ориентированный (ОО) язык, уходящий корнями в язык Self, несмотря на то, что внешне он выглядит как Java. Это обстоятельство делает язык действительно мощным благодаря некоторым приятным особенностям.

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

К счастью, в ECMAScript 5 появилось множество вещей, которые позволили поставить язык на правильный путь (некоторые из них раскрыты в этой статье). Также будет рассказано о недостатках дизайна JavaScript и будет произведено небольшое сравнение с классической моделью прототипного ОО (включая его достоинства и недостатки).

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

• Начну с главной, на мой взгляд, особенности Rust
• Опишу интересные детали синтаксиса
• Объясню, почему Rust, скорее всего, не захватит мир

Сразу поясню, что я около десяти лет пишу на Java, так что рассуждать буду со своей колокольни.

Всем привет!

В мире существует огромное количество приложений на OpenGL, и, кажется, Apple c этим не вполне согласна. Начиная с iOS 12 и MacOS Mojave, OpenGL переведен в статус устаревшего. Мы интегрировали Apple Metal в MAPS.ME и готовы поделиться своим опытом и результатами. Расскажем, как рефакторили наш графический движок, с какими трудностями пришлось столкнуться и, самое главное, сколько у нас теперь FPS.

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

— I’m too young to die.

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

Сегодня мы внимательным, немного суровым взглядом посмотрим на SceneKit, но, для начала обратимся к основам и посмотрим, что представляет из себя 3D-сцена и что нужно сделать, чтобы её создать.

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

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

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3
Лекция 10: «Символьное выполнение» Часть 1 / Часть 2 / Часть 3
Лекция 11: «Язык программирования Ur/Web» Часть 1 / Часть 2 / Часть 3
Лекция 12: «Сетевая безопасность» Часть 1 / Часть 2 / Часть 3
Лекция 13: «Сетевые протоколы» Часть 1 / Часть 2 / Часть 3
Лекция 14: «SSL и HTTPS» Часть 1 / Часть 2 / Часть 3
Лекция 15: «Медицинское программное обеспечение» Часть 1 / Часть 2 / Часть 3
Лекция 16: «Атаки через побочный канал» Часть 1 / Часть 2 / Часть 3
Лекция 17: «Аутентификация пользователя» Часть 1 / Часть 2 / Часть 3
Лекция 18: «Частный просмотр интернета» Часть 1 / Часть 2 / Часть 3
Лекция 19: «Анонимные сети» Часть 1 / Часть 2 / Часть 3
Лекция 20: «Безопасность мобильных телефонов» Часть 1 / Часть 2 / Часть 3

SwiftOnSecurity пишет на тему недавнего перехода на Chromium в качестве встроенного в Windows движка рендеринга:

Это не только про Chrome, это также про ElectronJS. Microsoft думает, что EdgeHTML не может достичь полного паритета по функциональности с Chromium, чтобы заменить его в приложениях Electron. Дублирование движка Electron в каждой программе становится значительной проблемой производительности. Вместо этого они хотят иметь один на всех экземпляр Electron вместе со своими дополнениями.

Electron это рак, убивающий и macOS, и Windows по мере распространения. Microsoft должна предложить ему замену с нативными оптимизациями, чтобы улучшить производительность и использование ресурсов.

Я не совсем разделяю их пессимизм по поводу нативных приложений, но Electron – это, без сомнений, бич платформы. Я думаю, что Mac окажет большее сопротивление, чем Windows, потому что платформа Mac привлекает большее число неравнодушных людей. Но тем не менее, я беспокоюсь.

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



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

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

В первой части мы разобрались, как использовать брейкпоинты (breakpoints) в Xcode для изменения существующих свойств переменных и добавления строчки кода через команды-инструкции.

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

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

Приветствую Хабравчан!

Думаю, данной темой не многих удивишь — достаточно набрать в поисковике фразу arduino bruteforce и сразу станет понятно, насколько распространен перебор паролей при помощи платформы Arduino. Я же хочу рассказать о том, как это быстро организовать с наименьшим наборов компонентов, без разводки/травления плат и пайки. Сразу оговорюсь, что описанные мною действия носят ознакомительный характер и никому не причинили вреда, ни морального, ни физического… разве что мошенникам.

Добрый день, Хабр! Представляю вашему вниманию перевод статьи про базовые основы безопасности конфиденциальных данных в iOS приложениях «Application Security Musts for every iOS App» автора Arlind Aliu.

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

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