Когда я только искал свою первую работу джуна iOS разработчика, я начал делать пет-проект — умный будильник. Тогда основной целью было просто положить его в портфолио, использовать на собеседованиях, ну а параллельно практиковаться и развивать свои навыки.

Я рассчитывал выпустить его месяца за три… Но проект удалось релизнуть лишь спустя 4 года

Рассказываю что помогло запустить MVP когда мотивация давно закончилась. Делюсь быстрым и простым техническим стеком для микро команд и советами для начинающих индихакеров.

UIKit first appeared in iOS 2, and it is still here. Eventually we got to know it well and learned how to work with it. We have found many architectural approaches. MVVM, the most popular architecture in my opinion, has strengthened its position with the release of SwiftUI, while other architectures seemed to have some kind of problematic relationships with SwiftUI.

But what if I told you that Clean Swift, VIPER and other approaches can be adapted to SwiftUI. What if I told you that there are some modern architectures which might be as good as MVVM or even better.

We will talk about MVI.

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

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

В статье много практики. Сначала я покажу, как с помощью Decompose и Jetpack Compose создавать отдельные флоу приложения. Далее обсудим реализацию bottom-навигации. И, наконец, объединим несколько флоу воедино, чтоб получить навигацию по всему приложению.

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

Это вторая часть из серии статей про компонентный подход. Если вы не читали первую часть Компонентный подход. Боремся со сложностью в Android-приложениях, то рекомендую начать с нее.

Ранее мы обсудили, что компонентный подход — это способ организации приложения в виде иерархии компонентов: UI-элементы ➜ функциональные блоки ➜ экраны ➜ флоу ➜ приложение. Такая структура позволяет эффективно бороться со сложностью экранов и навигации.

Предлагаю опробовать этот подход на практике. Будем использовать библиотеку Decompose для создания простых и сложных экранов. Рассмотрим примеры из реальных приложений. Надеюсь, будет интересно.

В предыдущей части мы разобрали преимущества работы с async/await по сравнению с GCD. В этой части мы более подробно рассмотрим ключевые слова async и await (и не только). Разберемся в том, как они работают, что означает "неблокирующее ожидание" и самое главное рассмотрим это все на примерах.

Прошло уже больше года с момента выпуска async/await. Многие крупные и не очень проекты уже успели поднять минимальную версию до iOS 13, следовательно открылась возможность полноценно использовать новые языковые возможности по работе с асинхронным кодом. Но перед тем как начать полноценно рефакторить старый код и/или писать новый код используя относительно новую технологию в голове невольно всплывает вопрос: «А зачем? Чем это лучше того же GCD?». В этой вступительной статье из серии по async/await постараемся вместе ответить на этот вопрос.

Конец 18-го и 19-й век были временем колоссального прогресса в математике. Величайшие умы тысячелетия вводили все новые математические системы и языки, такие как алгебры Клиффорда и Грассмана. Хотя эти алгебры вызвали значительный интерес, в то время они воспринимались как подспорье более прямолинейной и более общеприменимой векторной алгебры Гиббса. Это было фактически концом поисков объединяющего математического языка и началом распространения новых алгебраических систем, создаваемых по мере необходимости; например, спинорная алгебра, матричная и тензорная алгебры, дифференциальные формы и т. д.

В этой статье мы реализуем возрождение алгебр Клифорда и Грассмана в виде структуры, известной как геометрическая алгебра (ГА). Это понятие было впервые введено в середине 1960-х годов американским физиком и математиком Дэвидом Хестенсом. Прошло 40 лет, но есть признаки того, что его утверждение о том, что ГА является универсальным языком для физики и математики, теперь начинает принимать все более явственные очертания. Во всем мире растет число групп, которые применяют ГА к целому ряду проблем из многих научных областей, обеспечивая чрезвычайно мощную математическую структуру, в которой могут быть выражены самые передовые концепции квантовой механики, теории относительности, электромагнетизма и т. д. При этом, утверждается, что ГА также достаточно проста для преподавания школьникам! В этой статье мы рассмотрим развитие и недавний прогресс ГА и обсудим, действительно ли она является объединяющим языком для физики и математики 21-го века. Примеры, которые мы будем использовать для иллюстрации, будут взяты из ряда областей физики и техники.

Трансформеры (transformers) — это очень интересное семейство архитектур машинного обучения. Существует много хороших учебных материалов по этой теме (например — вот и вот), но в последние несколько лет трансформеры, в основном, становились всё проще. Поэтому сейчас гораздо легче, чем раньше, объяснить принципы их работы. Этот материал представляет собой попытку, что называется, «на пальцах», объяснить то, как работают современные трансформеры.

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

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

Здесь можно найти видеолекции о трансформерах. А в этом репозитории имеется реализация простого трансформера с использованием PyTorch.

Пакетный менеджер Homebrew раздаёт 52 миллиона пакетов в месяц. Чтобы это делать, он использует хранилища контейнеров, отлично подходящие для этой задачи. Как это работает?

Более Быстрые Сборки Apple с помощью lld Linker.

Linker - Компоновщик (также редактор связей, от англ. link editor) — инструментальная программа, которая производит компоновку («линковку»): принимает на вход один или несколько объектных модулей и собирает из них исполняемый или библиотечный файл-модуль.

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

Всем привет! Меня зовут Константин, я Flutter-разработчик в компании Nord Clan.

В данной статье мы с моей коллегой Анной хотели бы поделиться нашим опытом связки Flutter и home widget на платформе iOS.

Приключение на 20 минут.

Я захотел научиться принимать крипту в своих сервисах, и хочу поделиться как я внедрял Tron USDT.

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

Сегодня расскажу, как Apple предлагает решать эту проблему с помощью логов.

Представьте, что вы садитесь делать новый проект для iOS/iPadOS/macOS/tvOS/watchOS. Совсем скоро сталкиваетесь с первым багом и, чтобы его понять и исправить, добавляете логи — вызываете print() тут и там. Баг исправили и часть логов убрали, а часть оставили на будущее — полезные, ещё пригодятся.

Спустя пару месяцев работы над проектом консоль в Xcode превращается в водопад из логов. В них сложно разобраться и в них невозможно ориентироваться. Вы принимаете это как данность и в новые логи для удобства добавляете какие-то маркеты по типу "----->" или ещё что-нибудь в этом духе — так их можно будет различить в бесконечном потоке.

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

В этой статье расскажу, как Apple предлагает решать такую проблему.