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

TGINSIGHT SIMILAR POSTS

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

Изходен канал @clockstackwheels · Post #55 · 26.06

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

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