Функции высшего порядка
🟢 lvl: jun
Это функции:
▪ принимает одну или несколько функций в качестве аргументов
▪ возвращает функцию как результат
В swift функции высшего порядка это любые функции, которые принимают или возвращают замыкания.
Функции высшего порядка позволяют писать декларативный код в функциональном стиле. Такой код имеет меньше промежуточного состояния и его проще читать
Таких функций множество и полезно знать как они сделаны внутри
- понимание функций высшего порядка
- имплементации функций высшего порядка
🟢 lvl: jun
Это функции:
▪ принимает одну или несколько функций в качестве аргументов
▪ возвращает функцию как результат
В swift функции высшего порядка это любые функции, которые принимают или возвращают замыкания.
Функции высшего порядка позволяют писать декларативный код в функциональном стиле. Такой код имеет меньше промежуточного состояния и его проще читать
Таких функций множество и полезно знать как они сделаны внутри
- понимание функций высшего порядка
- имплементации функций высшего порядка
👍5🤔2
Что хотите увидеть в след разборах?
Anonymous Poll
32%
Больше UI. Кастомные ячейки. Анимации.
41%
Архитектуры. DDD. Паттерны. Design system
38%
Модуляризация. Сборка проекта. CI/CD.
47%
Память. Погружение в глубину. Дебаггинг
36%
Кэширование данных. Куда что сохранять.
24%
Языки. Swift vs Obj-c. Runtime
20%
SwiftUI
Memory Safety
🟠 lvl: mid+
По умолчанию Swift предотвращает небезопасное поведение в коде. Например, Swift гарантирует, что переменные инициализируются до того, как они будут использованы, доступ к памяти после ее освобождения невозможен, а индексы массива проверяются на наличие ошибок выхода за границы. Эту концепцию предложили в SE-0176
Это правило, которое требует, чтобы каждое потенциальное изменение (запись) переменных было эксклюзивным с любым другим доступом к этой переменной
Swift также гарантирует, что множественный доступ к одной и той же области памяти не вызовет конфликта, так как потребует кода, который изменит местоположение в памяти, для того, чтобы у вас появился эксклюзивный доступ к этой памяти. Поскольку Swift автоматически управляет памятью, большую часть времени вам вообще не нужно думать о доступе к памяти.
Однако важно понять, где могут возникнуть потенциальные конфликты, и вы сможете избежать написания кода, который вызовет конфликт доступа к памяти. Если у вас в коде возникает конфликт, то вы получите ошибку компиляции или ошибку выполнения.
Когда мы работаем в многопоточной среде эти концепции и детали очень полезно знать, и они могут помочь нам избежать множества странных ошибок и сэкономить нам много отладки
О них мы поговорим в следующих постах, а пока можете ознакомиться с небольшим материалом:
- Крутейшая дока по memory safety
- Какой язык безопаснее: Swift или Rust?
- Enforce Exclusive Access to Memory
- Концепция владения
🟠 lvl: mid+
По умолчанию Swift предотвращает небезопасное поведение в коде. Например, Swift гарантирует, что переменные инициализируются до того, как они будут использованы, доступ к памяти после ее освобождения невозможен, а индексы массива проверяются на наличие ошибок выхода за границы. Эту концепцию предложили в SE-0176
Это правило, которое требует, чтобы каждое потенциальное изменение (запись) переменных было эксклюзивным с любым другим доступом к этой переменной
Swift также гарантирует, что множественный доступ к одной и той же области памяти не вызовет конфликта, так как потребует кода, который изменит местоположение в памяти, для того, чтобы у вас появился эксклюзивный доступ к этой памяти. Поскольку Swift автоматически управляет памятью, большую часть времени вам вообще не нужно думать о доступе к памяти.
Однако важно понять, где могут возникнуть потенциальные конфликты, и вы сможете избежать написания кода, который вызовет конфликт доступа к памяти. Если у вас в коде возникает конфликт, то вы получите ошибку компиляции или ошибку выполнения.
Когда мы работаем в многопоточной среде эти концепции и детали очень полезно знать, и они могут помочь нам избежать множества странных ошибок и сэкономить нам много отладки
О них мы поговорим в следующих постах, а пока можете ознакомиться с небольшим материалом:
- Крутейшая дока по memory safety
- Какой язык безопаснее: Swift или Rust?
- Enforce Exclusive Access to Memory
- Концепция владения
GitHub
swift-evolution/proposals/0176-enforce-exclusive-access-to-memory.md at main · swiftlang/swift-evolution
This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swiftlang/swift-evolution
🔥9👍2
Forwarded from Teamlead Good Reads – ежедневные советы про менеджмент людей и команд (Egor Tolstoy)
Подборка материалов про то, как прокачать навыки работы с документацией
👩🎓Замечательные курсы технических писателей от Google
🤔Алгоритм действий по тому, как привести в порядок документацию в команде
🔗Огромная подборка ссылок по разным аспектам написания документации: от правил форматирования текста до оценки UX
🎤Выпуски Подлодки по теме: «Техническая документация» и «Управление знаниями»
👩🎓Замечательные курсы технических писателей от Google
🤔Алгоритм действий по тому, как привести в порядок документацию в команде
🔗Огромная подборка ссылок по разным аспектам написания документации: от правил форматирования текста до оценки UX
🎤Выпуски Подлодки по теме: «Техническая документация» и «Управление знаниями»
Google for Developers
Overview of technical writing courses | Technical Writing | Google for Developers
🔥4
Подборка материалов по тестам
🏠 Dodo: Тест-ревью: как прошли два года написания unit-тестов
🏠 Cian: Тесты в iOS: хороший, плохой
🤑 Sber: Как доказать важность тестов каждому участнику проекта
Книги:
- Agile Swift
- Pro iOS Testing
- Test-Driven iOS Development
- Принципы юнит-тестирования
#подборка
Книги:
- Agile Swift
- Pro iOS Testing
- Test-Driven iOS Development
- Принципы юнит-тестирования
#подборка
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5⚡2👍2
Будет ли гонка?
Final Results
40%
Нет, у нас есть lock
10%
Нет, но приложение крашнится
24%
Да
26%
Не знаю
Для типов значений, изменяющих функции, self неявно передается функции в качестве параметра inout. И в контексте доступа к памяти в параметрах in-out есть доступ на запись, который автоматически начинается в начале функции и заканчивается, когда функция завершается. Таким образом, в приведенном примере, даже если мы не изменяем наш массив внутри функции, существует долгосрочный доступ на запись для всего выполнения метода.
ℹ️ Из документации Apple (раздел Conflicting Access to In-Out Parameters):
A function has long-term write access to all of its in-out parameters. The write access for an in-out parameter starts after all of the non-in-out parameters have been evaluated and lasts for the entire duration of that function call. If there are multiple in-out parameters, the write accesses start in the same order as the parameters appear.
Получается, что гонка происходит, когда мы вызываем node.clearChilds() в первой очереди, начиная доступ на запись для self, который также является node, и после этого снова пытаемся использовать node.clearChilds() во второй, начиная другой доступ на запись на node, а также пытаясь прочитать self в self.childs.isEmpty.
Решение:
Полный разбор в статье
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7
Способы сериализации данных в iOS
🟡 lvl: mid
Сериализация — процесс перевода данных в битовую последовательность. Сериализация используется для передачи объектов по сети и для сохранения их в файлы.
В iOS самые популярные способы:
- NSCoding (NSKeyedArchiver)
- JSON
- Plist
- Codable
JSON — самый быстрый, а NSKeyedArchiver самый медленный.
В статье ниже можно ознакомиться с чего начиналось кодирование и почему Codable пока лучшее, что имеем
- Сериализация в iOS
🟡 lvl: mid
Сериализация — процесс перевода данных в битовую последовательность. Сериализация используется для передачи объектов по сети и для сохранения их в файлы.
В iOS самые популярные способы:
- NSCoding (NSKeyedArchiver)
- JSON
- Plist
- Codable
JSON — самый быстрый, а NSKeyedArchiver самый медленный.
В статье ниже можно ознакомиться с чего начиналось кодирование и почему Codable пока лучшее, что имеем
- Сериализация в iOS
👍8
Недавно меня спросили: "а как решать литкод? с чего вообще начинать?".
Честно, хер его знает. Особой страты у меня пока нет. Я беру грокаем алгоритмы -> читаю главу -> решаю по этой теме пару тасок.
Но вот наткнулся на рекомендации изучения тем новичкам.
Честно, хер его знает. Особой страты у меня пока нет. Я беру грокаем алгоритмы -> читаю главу -> решаю по этой теме пару тасок.
Но вот наткнулся на рекомендации изучения тем новичкам.
🔥15
Очень актуальная вещь с первым синдромом. Как там пословица индейцев? Лошадь сдохла - слезь?
Forwarded from Teamlead Good Reads – ежедневные советы про менеджмент людей и команд (Egor Tolstoy)
Эффект IKEA
Исследование 2011 года показало, что люди, которые сами собрали мебель из IKEA, считают ее выгодным вложением на 63% чаще, чем те, кто просто приценивается к аналогичной собранной кем-то еще мебели. Привязанность к предмету тоже значительно повышается для тех, кто своими руками его собирает.
Этот эффект объясняет два других часто встречающихся в разработке синдрома:
💦Sunk costs effect – продолжение инвестиций в проект, который уже очевидно не выгорел, только потому, что в него уже многое было вложено раньше
🤷🏻♂️Not invented here syndrom – отказ от идей и технологий, разработанных где-то или кем-то еще только потому, что это не in-house разработка
Исследование 2011 года показало, что люди, которые сами собрали мебель из IKEA, считают ее выгодным вложением на 63% чаще, чем те, кто просто приценивается к аналогичной собранной кем-то еще мебели. Привязанность к предмету тоже значительно повышается для тех, кто своими руками его собирает.
Этот эффект объясняет два других часто встречающихся в разработке синдрома:
💦Sunk costs effect – продолжение инвестиций в проект, который уже очевидно не выгорел, только потому, что в него уже многое было вложено раньше
🤷🏻♂️Not invented here syndrom – отказ от идей и технологий, разработанных где-то или кем-то еще только потому, что это не in-house разработка
Че по тестам?
Учимся тестить пуши. Как мне кажется очень полезная практика покрывать пуши и диплинки юнит тестами. Частая проблема, когда хер пойми сколько пушей и диплинков у вас в приложении. Иногда уходили месяцы на их актуализацию. Покрывать их тестами приведет к экономии и времени, и денег
https://medium.com/testableapple/testing-push-notifications-within-xctest-75f719ab0494
Учимся тестить пуши. Как мне кажется очень полезная практика покрывать пуши и диплинки юнит тестами. Частая проблема, когда хер пойми сколько пушей и диплинков у вас в приложении. Иногда уходили месяцы на их актуализацию. Покрывать их тестами приведет к экономии и времени, и денег
https://medium.com/testableapple/testing-push-notifications-within-xctest-75f719ab0494
Medium
Testing push notifications within XCTest
Xcode 11.4 introduced a handy feature that allowed us to test push notifications on Simulator (xcrun simctl push). Unfortunately, it’s still not possible to take advantage of it within the XCTest…
👍5❤1💯1
Уехать — это как написать юнит тест. Вроде и не нужно, но безопасней
👍22😁6🤔3😢3
Forwarded from Teamlead Good Reads – ежедневные советы про менеджмент людей и команд (Egor Tolstoy)
Качество как функция системы его обеспечения
Качество продукта зависит не столько от скиллов разработчиков, сколько от системного подхода к его обеспечению. Группа супер-крутых разработчиков, работающих без оглядки на качество, скорее всего произведет продукт хуже, чем группа средненьких мидлов, работающих в системе, построенной с целью производить качественный результат.
К характеристикам такой системы обеспечения качества относится:
🐞Культура и инфраструктура, поощряющие написание тестов и дающие на это время
💻Надежные и простые в использовании dev/test окружения
☮️Отсутствие давления на команду, заставляющего релизить недостаточно протестированный код
📝Наличие документации и выделяемое на нее время
💬Регулярный разбор факапов с исправлением их корневых причин, без попыток блеймить кого-то
Качество продукта зависит не столько от скиллов разработчиков, сколько от системного подхода к его обеспечению. Группа супер-крутых разработчиков, работающих без оглядки на качество, скорее всего произведет продукт хуже, чем группа средненьких мидлов, работающих в системе, построенной с целью производить качественный результат.
К характеристикам такой системы обеспечения качества относится:
🐞Культура и инфраструктура, поощряющие написание тестов и дающие на это время
💻Надежные и простые в использовании dev/test окружения
☮️Отсутствие давления на команду, заставляющего релизить недостаточно протестированный код
📝Наличие документации и выделяемое на нее время
💬Регулярный разбор факапов с исправлением их корневых причин, без попыток блеймить кого-то
jacobian.org
Quality Is Systemic - Jacob Kaplan-Moss
Software quality is more the result of a system designed to produce quality, and not so much the result of individual performance. That is: a group of mediocre programmers working with a structure designed to produce quality will produce better software than…
👍5
Memory Unsafety in Apple's Operating Systems
🟡 lvl: mid+
Большая часть ошибок и уязвимостей ОС эйпл связана с небезопастным использованием памяти
Языки, как C и C++ небезопасны для памяти. Использование неинициализированной памяти, двойное освобождение, переполнение буфера, использование после освобождения и т. д. Программист должен идеально выделять, записывать, читать и освобождать память или иначе легко могут возникнуть серьезные уязвимости.
Казалось бы, Memory Safe языки должны помочь нам и сделать работу с памятью лучше. В погоне за скоростью авторы Swift забывают о крайне важной вещью — безопасной память.
👾 Для сравнения в iOS 12 было исправлено 261 из которых 173 были связаны с небезопасностью памяти. А в macOS Mojave исправлено 298 из которых 213.
Также автор ругает Swift за его попытку в безопасность, но при этом сильное снижение скорости, в отличие от других практик
- Основная статья
- Работа современных языков с Memory Safety
🟡 lvl: mid+
Большая часть ошибок и уязвимостей ОС эйпл связана с небезопастным использованием памяти
Языки, как C и C++ небезопасны для памяти. Использование неинициализированной памяти, двойное освобождение, переполнение буфера, использование после освобождения и т. д. Программист должен идеально выделять, записывать, читать и освобождать память или иначе легко могут возникнуть серьезные уязвимости.
Казалось бы, Memory Safe языки должны помочь нам и сделать работу с памятью лучше. В погоне за скоростью авторы Swift забывают о крайне важной вещью — безопасной память.
👾 Для сравнения в iOS 12 было исправлено 261 из которых 173 были связаны с небезопасностью памяти. А в macOS Mojave исправлено 298 из которых 213.
Также автор ругает Swift за его попытку в безопасность, но при этом сильное снижение скорости, в отличие от других практик
- Основная статья
- Работа современных языков с Memory Safety
👍3