Так, ну че. Ща будет анпакинг.
Целый год засматривался на фитнес браслет whoop. Мне дико нравится тема с более детальным изучением сна и циклами восстановления. Поэтому буду тестить.
Почему не watch от Apple? Ну лично я считаю часы и наушники max оверпрайсами. Ватчи хуже откалиброваны и в целом это больше мультиорганайзер, чем фитнес браслет.
У кого есть такой делитесь впечатлениями.
Это не реклама если че
Целый год засматривался на фитнес браслет whoop. Мне дико нравится тема с более детальным изучением сна и циклами восстановления. Поэтому буду тестить.
Почему не watch от Apple? Ну лично я считаю часы и наушники max оверпрайсами. Ватчи хуже откалиброваны и в целом это больше мультиорганайзер, чем фитнес браслет.
У кого есть такой делитесь впечатлениями.
Это не реклама если че
Иногда кажется, что у нас есть особое чутьё на то, что откликнется людям. Запускаем что-то новое и вдруг видим, как это подхватывают вокруг. Для меня это знак, что мы на одной волне с аудиторией и двигаемся в верном направлении.
Например, уже полтора месяца активно разбираем Swift Councurrency, проводим опросы и анализ что интересно аудитории, как вокруг внезапно за последние недели начинают выпускать новые статьи или роадмапы. Даже льстит, что мы так влияем на индустрию
Хватит шуток, приступим к работе. Этот месяц мы активно решили разбирать практические задачи. Одна из частых в продакшене, но непопулярных у популистов задач — это батчинг.
- при проектировании аналитических модулей
- чаты
- сложные логеры
Зачем это нужно?
- меньше сетевых запросов
- улучшение перфоманса
- экономия батарейки
Это очень крутая задача для лайфкодинга или систем дизайна. Можно много где развернуться и оценить как свои знания, так и кандидата.
На скрине сделал очень простую версию для знакомства с концепцией. Более production ready будет в закрытой базе вместе с другими практическими задачами. С более детальным описанием многих корнер-кейсов.
Интересные ссылки:
- Algorithm | Concurrent Batch Processing | Swift
- Простая реализация батчей
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
По опросу в канале аудитория посчитала, что это легче, чем "красить кнопки". Я посчитал это булщитом и большим заблуждением в сети. Поэтому я искал эксперта, кто может пояснить за CI/CD.
Мы с @MeGaPk решили разобрать подробнее все мифы и заблуждения этой темы.
В этом выпуске мы поговорили про:
Please open Telegram to view this post
VIEW IN TELEGRAM
Architecture Decision Records
Мы уже выяснили, что архитектуры — это не про выбор паттерна между VIPER/TCA/MVP. Писали это посте "Вы переоцениваете UI-архитектуры" и "О, нет! Ты выбрал неправильную UI архитектуру!". И нет, выбор архитектуры это тоже не про шаблонное рисование схем "System Design Interview: как сделан ютуб".
Выбор архитектуры — это оценка ресурсов, сроков. Где выбирая архитектуру ты должен задумываться об ее росте и сопротивлению деградации. Так тебе и команде проще жить.
Теперь перейдем из абстрактных советов к практике. Один из важных инструментов, которые помогают разрабам — это ADR.
В больших и сложных проектах, где внедрение или изменение технологий может идти годами. Может произойти такой момент, где все потеряют смысл и вектор происходящего. Зачем мы это делаем? Почему такое было сделано? Куда мы идем?
В этот момент помогают такие инструменты как TDR или ADR. На моей работе даже сейчас одна из сложных задач — это понять и зафиксировать вектор, а также не размыть и потерять все контексты.
Если у вас такие же проблемы, то вот отличные подборки публичных гайдов:
🌟 adr-tools
🌟 Amazon
🌟 GitHub
🌟 RedHat
Мы уже выяснили, что архитектуры — это не про выбор паттерна между VIPER/TCA/MVP. Писали это посте "Вы переоцениваете UI-архитектуры" и "О, нет! Ты выбрал неправильную UI архитектуру!". И нет, выбор архитектуры это тоже не про шаблонное рисование схем "System Design Interview: как сделан ютуб".
Выбор архитектуры — это оценка ресурсов, сроков. Где выбирая архитектуру ты должен задумываться об ее росте и сопротивлению деградации. Так тебе и команде проще жить.
Теперь перейдем из абстрактных советов к практике. Один из важных инструментов, которые помогают разрабам — это ADR.
Когда архитектура ПО развивается в результате ряда решений, которые сами по себе рождаются из гипотез и экспериментов, проверяющих эти гипотезы, командам разработчиков нужен способ отслеживать принятые ими архитектурные решения.
В больших и сложных проектах, где внедрение или изменение технологий может идти годами. Может произойти такой момент, где все потеряют смысл и вектор происходящего. Зачем мы это делаем? Почему такое было сделано? Куда мы идем?
В этот момент помогают такие инструменты как TDR или ADR. На моей работе даже сейчас одна из сложных задач — это понять и зафиксировать вектор, а также не размыть и потерять все контексты.
Если у вас такие же проблемы, то вот отличные подборки публичных гайдов:
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - joelparkerhenderson/architecture-decision-record: Architecture decision record (ADR) examples for software planning, IT…
Architecture decision record (ADR) examples for software planning, IT leadership, and template documentation - joelparkerhenderson/architecture-decision-record
1 9
DispatchQueue.main.async ВСЁ! Теперь в современном мире мы используем MainActor. Но с ним есть множество нюансов, которые нужно учитывать.
Большинство иосеров думают, что @MainActor просто гарантирует выполнение кода на main thread. Но это лишь верхушка айсберга. Реальная магия и потенциальные проблемы скрываются в том, КАК именно Swift изолирует ваши данные.
Допустим, что если класс помечен @MainActor, весь код выполняется на main thread, верно?
@MainActor
class ViewModel: ObservableObject {
@Published var data: [Item] = []
// Весь ли код выполнится на main thread?
func loadData() async {
let items = await apiService.fetchItems()
self.data = items
}
}
На самом деле MainActor изолирует только доступ к свойствам, а не выполнение методов. Из прошлых постов про изоляцию мы уже поняли что await может переключить контекст.
Почему это важно? Ну, во-первых, это может сломать код, если после await apiService вы работаете с UI элементами.
Давайте разберем еще несколько важных примеров, где MainActor === изоляция данных, а не изоляция выполнения кода. Я мало где видел, чтобы спрашивали такие детали. Можете брать задачи для собеседований в свою компанию.
Полезные ссылки:
- MainActor usage in Swift explained to dispatch to the main thread
- @MainActor – The Rules!
- How to use @MainActor to run code on the main queue
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM