На некоторых моих проектах это решалось изменением типа задач, а именно использованием эпиков для фич, или отдельной Story для фичи к которой линковались все остальные. И задача для разработчика была именно разработать и замержить. А дальнейшая раскатка, A/B тестирование, сбор результатов и аналитики - это уже были совершенно отдельные задачи для других людей которые линковались все к тому же эпику/истории фичи. И если необходима дополнительная разработка - создавалась новая задача для разработчика. Главное правило - если пулл реквест замержен - задача для разработчика закрыта. Если нужны исправления - открыть новую задачу / баг репорт
Очень хорошая статья. Последний год в голове как раз крутилось все что здесь описано. Сам тоже не перевариваю enum'ы и перечисления когда для добавления нужного значения нужно отсмотреть/поправить еще десяток мест в коде где оно используется. Особенно не нравится, когда пытаются использовать enum для задания стиля компонента и во всех методах перечисляют все значения.
Все описаное также укладывается под O из SOLID (open-closed principle) - когда для внесения изменений нужно создать новый код (например новый класс которые будет реализововать протокол) а не изменять существуюущий код (те все swift перечисления)
Пользуюсь похожими гаджетами от китайцев, очень доволен. Единственное беспокойство — кормушка иногда не присылает уведомление и не показывает в истории выпадал корм по расписанию или нет. И проверить это можно только по коту. Поэтому оставлять больше чем на день страшно. Если у Petoneer есть 100% гарантия что кормушка сработает или как минимум будет уведомление что не сработала — это супер отлично.
Может ли кормушка производить какой-то записаный звук (например запись моего голоса) перед выдачей корма?
p.s. приучил кота к унитазу, есть кормушка и поилка. В итоге на уход за котом уходит совсем немного времени раз в неделю — досыпать корм, поменять воду в поилке.
Подписка на события заставляет View хранить состояние, а этого хочется избежать, так как за это отвечает ViewModel. Когда мне говорят про MVVM, я представляю что существует ViewModel которая знает все и я могу в ЛЮБОМЙ момент подписаться на нее и получить все нужные мне значения для отображения. В Вашем же варианте, если подписаться позже чем начало отображение — часть событий просто не прийдет, если я правильно понимаю.
Соглашусь с предидущим автором сообщения про Redux. — Если у вас много значений который нужно отправить во View и они происходят одновременно — можно сделать из них простую структура и посылать все сразу. Иногда уместно посылать сразу целый большие обьекты с бд/сети, а View уже разберется как использовать данные.
А Вы рассматривали вариант без крайностей native ИЛИ гибрид? На данный момент я участвую в разработке приложения, где наиболее используемые экраны где нужны анимации и производительность пишем native. А все остальные делаем во flutter. И на этот формат мы переходим постепенно из двух полностью нативных разработок (iOS + Android)
на iOS старый UIWebView и тем более новый WKWebView позволяют выполнять произвольный JS код. Например Call JavaScript function from native code in WKWebView . По этому эти классы позволяют сделать все, что может позволить нативный JS код страницы. WKWebView имеет еще больше возможностей и доступа.
на iOS, Веб-view как раз и позволяет перехватить и смотреть абсолютно все что в нем происходит. Защититься можно SFSafariViewController но я еще не видел, что бы его использовали разработчики для методов оплаты.
Насколько много у вас текстов что необходимо создавать diff? С проектами в которых я работал, обычно это было до 1MB текста. При этом, во время «комита/релиза» перевода, сервер паковал все в zip и ждал, пока приложение его не запросит.
Вот бы было здорово, если бы при компиляции IDE сразу бы могла показать код который изменится при оптимизации. Написал разименование а потом проверку на ноль, а IDE сразу сделал код серым и сразу ясно что, что-то не то.
Нам как-то в универе показывали интересный эксперимент: сделали небольшой обработчик данных-числодробилку. Распаралелили её на потоки и замеряли скорость выполнения всей задачи. Все шло как ожидалось: эффективность прии потоки=число ядер, при превышении начинается очеень маленькая просадка но не критично. Где-то при 128 потоках (при 8 ядрах) началась существенная просадка. А вот при 1000+ потоках, скорость снова начала повышаться и время было меньше чем при оптимальных 8 потоках. А все из-за того, что такое количество потоков «перегружало» системный планировщик операционной системы, а в целом, на нашу задачу начало отводится больше процессорного времени, чем при 8 потоках :) (Но, результат не совсем стабильный + сама система начинает тормозить, так как реже выполняются системные процесы + зависит от железа/кешей.) Ну и вообще, из этого всего был еще один итог: в современных ОС и железе, время на переключения контекста намного меньше, чем когда об этом писали книжки :)
По собственным наблюдениям: вероятность принятия очень зависит от страны размещения. Я сейчас делаю приложения для Катара — такое чувство, что модерации нет вообще и в аппстор приложение попадает на след. день. До этого, я делал под заказ приложение интернет магазина, которое в виде клонов с разными бекенд-серверами и локализацией публиковались в разных странах: одна страна — одно приложение. И в целом все было более менее хорошо. А вот когда мы хотели собрать эти клоны и опубликовать приложение worldwide — мы пару недель потратили на фиксы и общение с проверяющим, хотя от клонов оно первоначально ничем не отличалось и клоны до этого были в сторе 2 года.
Мне кажется это можно пообсуждать и добавить туда и некоторые switch/case. Я, по сути, придумал это после прочтения вопроса и как мне кажется это может даже работать :). Если задуматься, то когда ты начинаешь писать много костылей для той или иной ситуации — это все условия.Или просто начинаешь писать разделение функций на основе условий — это все признаки неудобной архитектуры. В удобной архитектуре тебе обычно нужно ~1 условие то бы выбрать нужный класс реализации / подставить новую стратегию. Можно ради интереса попробовать посчитать как нибудь количество (if / switch-case) / (LOC).
На некоторых моих проектах это решалось изменением типа задач, а именно использованием эпиков для фич, или отдельной Story для фичи к которой линковались все остальные. И задача для разработчика была именно разработать и замержить.
А дальнейшая раскатка, A/B тестирование, сбор результатов и аналитики - это уже были совершенно отдельные задачи для других людей которые линковались все к тому же эпику/истории фичи. И если необходима дополнительная разработка - создавалась новая задача для разработчика. Главное правило - если пулл реквест замержен - задача для разработчика закрыта. Если нужны исправления - открыть новую задачу / баг репорт
Очень хорошая статья. Последний год в голове как раз крутилось все что здесь описано. Сам тоже не перевариваю enum'ы и перечисления когда для добавления нужного значения нужно отсмотреть/поправить еще десяток мест в коде где оно используется. Особенно не нравится, когда пытаются использовать enum для задания стиля компонента и во всех методах перечисляют все значения.
Все описаное также укладывается под O из SOLID (open-closed principle) - когда для внесения изменений нужно создать новый код (например новый класс которые будет реализововать протокол) а не изменять существуюущий код (те все swift перечисления)
Подобное слияние видел в этом видео https://www.youtube.com/watch?v=OnLeOmlLpHc где рассказывается о рендере Ray Marching
Про пустые места в автобусе: живу в Праге, Гугл показывает на маршрутах общественного транспорта — загруженность/заполненность
Может ли кормушка производить какой-то записаный звук (например запись моего голоса) перед выдачей корма?
p.s. приучил кота к унитазу, есть кормушка и поилка. В итоге на уход за котом уходит совсем немного времени раз в неделю — досыпать корм, поменять воду в поилке.
Соглашусь с предидущим автором сообщения про Redux. — Если у вас много значений который нужно отправить во View и они происходят одновременно — можно сделать из них простую структура и посылать все сразу. Иногда уместно посылать сразу целый большие обьекты с бд/сети, а View уже разберется как использовать данные.
. По этому эти классы позволяют сделать все, что может позволить нативный JS код страницы. WKWebView имеет еще больше возможностей и доступа.
или
или