Обвинительная статя о корпорациях, которые десятки лет делают все не правильно (вот тупые!), а автор, владея мудростью инженеров СССР знает как правильно! Это же готовый сценарий для книг о попаданцах.
Прежде всего хотелось бы обратить внимание на отсутствие наследия инженеров указанной вами школы эргономики, которые бы добились общего признания и воспринимались как стандарт удобства в своей отрасли.
Что касается критической части статья создается ощущение, что автор не допускает мысли - создатели софта уже размышляли над разными реализациями, в том числе перенос активных действий "под пальцы", и если сейчас этого нет, значит есть причины по которым сделано так а не иначе. Я не дизайнер, но объективно понимаю что отделы проектирования в озвученых кампаниях обладают экспертизой и опытом (и ограничениями) которые недостижимы для одиночных специалистов. Вам может нравиться то, что они делают или нет, это естественно, но позиция автора статьи крайне наивна.
Резидентство же проверяется только в момент оформления счета в банке?
Мне думается, что имея несколько банковских карт со сроками действия в несколько лет, все это время можно безопасно пользоваться неопределенностью. С расчётом, что в определенный момент потребуется ее устранить для обновления критичных документов / счетов / продажи недвижимости и т.д. Кажется это может быть очень выгодно при определенном уровне дохода.
Можете подробнее подсветить ситуацию, когда релокант годами путешествует по странам и нигде не вступает в статус налогового резидента? При этом отношения с работодателем оформлены по ГПХ.
На сколько я знаю, в Combine процесс отписки автоматический - вместе с удалением проперти AnyCancelable. Что кажется удобно - при удалении модуля из памяти можно быть спокойным - ничего лишнего не сработает. Если, разумеется, все подписки хранились в подклассе удаляемого модуля.
Менеджерам полезно, да.
Хотел было написать, что не все из перечисленного обязательно к выполнению тем более со старта, но автор не забыл про это. Хорошая статья.
Интересно, как обертка (кажется @Published?) под капотом обеспечивает постоянную актуальность модели. Не может же она непрерывно дергать APIs и отслеживать изменения? Или если так, то как быть в условиях ограничений на количество запросов / возрастет ли нагрузка на сервера?
В основном вы рассказываете про примеры, когда под давлением внешних факторов, программисты совершают ошибки, которые приведут к проблемам в перспективе. Было бы интересно узнать из вашего опыта, как сами программисты, без видимых причин, «делали грязь» и как руководству это предотвратить (помимо кодревью).
Мне, к счастью, незнакома специфика работы на промышленных предприятиях, но в «классической модели», у программиста имеется менеджер, который таки и должен обладать глубинными знаниями о бизнес процессах / фильтровать задачи от бухгалтеров, продажников и прочих, согласовывать их с директором / находить логические коллизии в поставленной сейчас задаче с тем, что делалось пол года назад.
Я не хочу сказать, что менеджер снимает с программиста необходимость думать о бизнесе, но явно что правила работы с подрядчиками годовой давности, это не то, что программист должен знать наизусть.
Спасибо за внимательное прочтение. Исправлено.
Обвинительная статя о корпорациях, которые десятки лет делают все не правильно (вот тупые!), а автор, владея мудростью инженеров СССР знает как правильно!
Это же готовый сценарий для книг о попаданцах.
Прежде всего хотелось бы обратить внимание на отсутствие наследия инженеров указанной вами школы эргономики, которые бы добились общего признания и воспринимались как стандарт удобства в своей отрасли.
Что касается критической части статья создается ощущение, что автор не допускает мысли - создатели софта уже размышляли над разными реализациями, в том числе перенос активных действий "под пальцы", и если сейчас этого нет, значит есть причины по которым сделано так а не иначе.
Я не дизайнер, но объективно понимаю что отделы проектирования в озвученых кампаниях обладают экспертизой и опытом (и ограничениями) которые недостижимы для одиночных специалистов. Вам может нравиться то, что они делают или нет, это естественно, но позиция автора статьи крайне наивна.
Резидентство же проверяется только в момент оформления счета в банке?
Мне думается, что имея несколько банковских карт со сроками действия в несколько лет, все это время можно безопасно пользоваться неопределенностью. С расчётом, что в определенный момент потребуется ее устранить для обновления критичных документов / счетов / продажи недвижимости и т.д. Кажется это может быть очень выгодно при определенном уровне дохода.
Можете подробнее подсветить ситуацию, когда релокант годами путешествует по странам и нигде не вступает в статус налогового резидента? При этом отношения с работодателем оформлены по ГПХ.
На сколько я знаю, в Combine процесс отписки автоматический - вместе с удалением проперти AnyCancelable.
Что кажется удобно - при удалении модуля из памяти можно быть спокойным - ничего лишнего не сработает. Если, разумеется, все подписки хранились в подклассе удаляемого модуля.
За Live Preview особенная благодарочка ❤️
Отличная статья, спасибо!
Существует ли демо-проект, где можно было бы наглядно увидеть - как получаются представленные эфекты трансформации?
Как уже только менеджеров не называли.
Хотел было написать, что не все из перечисленного обязательно к выполнению тем более со старта, но автор не забыл про это. Хорошая статья.
Мне, к счастью, незнакома специфика работы на промышленных предприятиях, но в «классической модели», у программиста имеется менеджер, который таки и должен обладать глубинными знаниями о бизнес процессах / фильтровать задачи от бухгалтеров, продажников и прочих, согласовывать их с директором / находить логические коллизии в поставленной сейчас задаче с тем, что делалось пол года назад.
Я не хочу сказать, что менеджер снимает с программиста необходимость думать о бизнесе, но явно что правила работы с подрядчиками годовой давности, это не то, что программист должен знать наизусть.