Перевел занятную статью о том, что не всегда стоит затыкать дыры в производительности апгрейдом железа, ибо такой подход порождает много неприятных артефактов и не всегда контролируем. Написана интересно и со вкусом, так что советую прочитать целиком. Главный вывод — да, иногда это оправдано, но в целом более здравая политика изначально писать правильный код. Ваш КО.
Разработка, аналитика, дизайн
- Более быстрое железо — плохое первое решение для медленного ПО
- $9.7 млн в Серии A: Onward — управление общими расходами на детей
- IBM выпустила NLP библиотеки
- Kweb — веб-фреймворк для Kotlin
- Самые высокооплачиваемые вакансии октября в области разработки приложений
- Podlodka #291: продуктивность разработчика
- Mac App Store стагнирует
- Google приобрел аватары Alter
- Spotify убрал покупку аудиокниг из iOS-приложения
- Как построить большое мобильное приложение в проекте… который был уже несколько раз потрачен до тебя
- User Experience: How Design Consistency Works
- Continuous Delivery and Releases in Mobile Development
- Dependency Inversion Principle Explained and How Tutorials Get It Wrong
- Open-Obfuscator: A free and open-source solution for obfuscating mobile applications
iOS
- Server-Driven UI с DivKit
- Performance в SwiftUI
- PhoneNumberKit: парсинг и форматирование телефонных номеров
- Creating a Swifty Command-Line Tool With ArgumentParser
- Presenting Sheets: Item, or a Boolean Binding?
- ScenePhase Environment Variable in SwiftUI
- Demystifying Background Uploads/Downloads in iOS
- Build Complex Lists in SwiftUI
Android
- Modern Android Development: видео Android Dev Summit ’22
- YCharts: графики для Jetpack Compose
- Coroutines: боль обработки ошибок
- Разбор кода Pocket Casts
- Optimize for Android (Go edition): Lessons from Google apps
- Trendyol Android Team Unit Test Practice
- How Android Development Evolves Over The Years
Кроссплатформа
- Multi — Themes Using Riverpod in Flutter
- Best Practices for Maintaining and Scaling Flutter Applications