TGTGInsightтелеграм анализLIVE / telegram public index
← Такты, стеки, два колеса

TGINSIGHT SIMILAR POSTS

Намери подобно съдържание

Изходен канал @clockstackwheels · Post #966 · 19.03

Меня иногда спрашивают, заменят ли нейросети программистов (или "когда заменят"). Мне на эту тему очень нравится картинка ниже. Давайте подумаем, что делает ценным квалифицированного специалиста. Задача специалиста это принять на вход некоторые стартовые условия, а потом произвести над ними манипуляции, чтобы выдать требуемый результат. Хирург получает тело человека с каким-то заболеванием и должен в нужных местах совершить надрезы и наложить швы, чтобы в качестве результата человек остался живым и более здоровым, чем раньше. Адвокат получает материалы дела с каким-то конфликтом и должен произвести некоторую последовательность воздействий на суд так, чтобы именно его клиент вышел из конфликта победителем. Строитель-прораб получает чертежи здания, площадку и бюджет и должен сформировать цепочку управляющих команд для рабочих, чтобы в итоге получилось здание, которое не упадёт и пройдёт нужные проверки. Если между набором стартовых условий и конечным результатом всегда одинаковая последовательность манипуляций, такой труд автоматизируется. Сложно как-то принципиально по-разному рассчитать клиента на кассе. Сложно выбрать несколько путей оформления одного и того же шаблонного документа. Нельзя десятью способами нарезать резьбу с заданным шагом на заданной заготовке. Так что для всего этого есть станки, аппараты, программы и роботы. Квалификация подключается там, где путей много, и для выбора правильного недостаточно просто описать желаемый конечный результат. У специалиста есть знания, опыт и интуиция, которые позволяют ему именно в каждом конкретном случае принимать решения. Относится ли программирование к подобным областям? Безусловно. Одну и ту же программу можно написать сотней способов и между этими способами будут серьёзные отличия, которые повлияют впоследствии на использование и развитие этой программы. Ну хорошо, но мы ведь загрузили в нейросеть весь опыт и знания программистов. Что мешает ей пройти тот же путь, что пройдёт программист, и точно так же принимать решения, исходя из ситуации? Два момента. Во-первых, у человека есть воля, а у нейросети нет. У человека есть способность как бы создавать новые решения внутри себя, а не в результате некоторой инструкции извне. И воля квалифицированного специалиста — важный аспект его работы. Грубо говоря, в части случаев мы хотим, чтобы специалист совершил творческий акт, принимая решения. Во-вторых, опыт практически в любой области, требующей квалификации, частично включает в себя понимание всего многообразия контекстов человечества в целом. То есть как бы знания того, что такое человек, в каких ситуациях он будет пользоваться результатом твоей работы и так далее. Так что нет, нейросети не заменят программистов. Исключение, пожалуй, такое: программа, которая запускается один раз для выдачи конкретного результата, не требующего высокой надёжности. Если мне нужно один раз для личного удобства переименовать тысячу файлов, то в целом программа, которая это делает, может быть написана сколь угодно плохо, лишь бы работала. Но это совсем небольшой процент реальных сценариев. #dev

Hashtags

Резултати

Намерени 3 подобни публикации

Търсене: #viewmodel

当前筛选 #viewmodel清除筛选
Android Broadcast

@android_broadcast · Post #9572 · 18.10.2025 г., 11:35

Вот реальная история, как знание механики работы ViewModel спасло мне вечер 👇 У меня приложение на Compose и Jetpack Navigation 3 (работает на основе состояния Back Stack). Экран «Навигатор файлов» открывает папки рекурсивно: по сути это тот же экран, но с другими данными. Все данные — из одной и той же ViewModel.❗️Баг: при переходе в папку навигация срабатывает, UI не меняется. Современные ИИ подсказали общие вещи, но не помогли — промты, видимо, подвели (тут мне ещё надо прокачать знания) 🙂 Вспомнил ключевой факт про архитектуру: 👉 Все ViewModel живут в ViewModelStore. 👉 В пределах одного ViewModelStoreOwner (Activity/Fragment/NavBackStackEntry) получение ViewModel по умолчанию идёт по типу. 👉 Если нужно несколько экземпляров одного типа на одном owner’е — используем key. Решение в одну строку — привязать ключ к ViewModel, связанный с текущей папкой: @Composable fun FileNavigator( folderId: Id, modifier: Modifier = Modifier, ) { // новый folderId → новый экземпляр ViewModel → новый UI-стейт val viewModel: FileNavigatorViewModel = viewModel( key = "files(rootId='$folderId')" ) // ... } Мини-чеклист, если ловите такой баг 👉 Один экран используется повторно с разными параметрами? → Нужен key. 👉 Меняется route, но owner тот же? → key обязателен. 👉 Используете Hilt/Koin? → У этих функций тоже есть параметр key (hiltViewModel(key=...), koinViewModel(key=...)). 👉 key должен детерминированно зависеть от входных данных (например, folderId). 👉 При навигации назад убедитесь, что ViewModel освобождается ожидаемо. Ещё нюанс - если у вас сложная иерархия графов, проверьте, к какому ViewModelStoreOwner вы реально привязаны. Рекомендую посмотреть мои видео по теме: 📹Разбор Jetpack Navigation 3 🪙Полный разбор Jetpack ViewModel в Android и Kotlin Multiplatform #android#compose#androidjetpack#viewmodel#архитектура

Android Broadcast

@android_broadcast · Post #8901 · 05.04.2025 г., 10:43

🤖Альтернативный способ обработке one-off событий из ViewModel (EN, 10м) В статье рассказывается в чем сложность с обработкой одноразовых событий, которые надо передать из ViewModel в UI. Автор рассматривает способ через callback интерфейс в конструкторе ViewModel @HiltViewModel class MyViewModel @Inject constructor( // inject the interface private val toastMessages: ToastMessages, ) : ViewModel() { fun doSomething() { viewModelScope.launch { try { // execute async operation here } catch (e: CustomException) { // initiate a one-off event toastMessages.showToast(e.localizedMessage) } } } } 🔗 Альтернативная ссылка на статью #android#viewmodel#dagger#hilt

Android Broadcast

@android_broadcast · Post #9683 · 20.11.2025 г., 14:59

🚀Lifecycle 2.10.0 вышел в стабильной версии! Google выпустила мажорное обновление библиотек Lifecycle. Этот релиз сфокусирован на улучшении интеграции с Compose. ⚙️rememberLifecycleOwner для Compose Новый композабл позволяет создавать изолированные LifecycleOwner внутри UI. Идеально для компонентов, которым нужно независимое управление состоянием — например, для HorizontalPager, где только активная страница должна быть в состоянии RESUMED. @Composable fun MyComposable() { val lifecycleOwner = rememberLifecycleOwner( maxLifecycle = Lifecycle.State.RESUMED, parentLifecycleOwner = LocalLifecycleOwner.current, ) CompositionLocalProvider( LocalLifecycleOwner provides lifecycleOwner ) { // Дочерние композаблы теперь имеют собственный жизненный цикл } } 🚀 Интеграция с Navigation 3 Новый артефакт lifecycle-viewmodel-navigation3 предоставляет готовый декоратор для автоматической привязки ViewModel к отдельным экранам в Navigation 3. NavDisplay( backStack = backStack, entryDecorators = listOf( rememberSaveableStateHolderNavEntryDecorator(), rememberViewModelStoreNavEntryDecorator(), // Добавляем эту строку ), entryProvider = entryProvider { /* ... */ } ) Удобства для разработчиков: 👉 Идиоматичный Kotlin API для создания кастомных CreationExtras CreationExtras { this[MY_CUSTOM_KEY] = "myValue" } 👉 Метод savedStateHandle.saved() теперь нативно поддерживает nullable типы 👉Конструкторы SavedStateHandle помечены как @VisibleForTesting ⚠️ Важное изменение Повышение minSdk с API 21 до API 23 — убедитесь, что ваше приложение соответствует новым требованиям. #Jetpack#Lifecycle#Compose#Navigation#ViewModel#Kotlin