Nuphy Halo75 v2 Obsidian Black Silent Red Switch - выглядит весьма эстетично, и так же приятна для набора текста / кода. Пользуюсь уже 16 месяцев активно, все так же приносит удовольствие и звуком и тактильно. Пока что лучшее, что пробовал из механических.
скорее всего, про время сборки модульного проекта немного (скорее много) лукавите, когда в проект подключаются поды — xCode уже заметно увеличивает время сборки, но когда используются отдельные поды под фичи, которые включает дев поды и прочие поды — не только время сборки улетает в космос, но и простой autocomplete и jump to definition отказываются работать из-за слишком сложного дерева зависимостей.
Ну и инкрементальная сборка только того, что изменили — утопия… которая не работает.
Видимо, вы недавно пришли в командную разработку.
Смысл линтера — чтобы весь код имел консистентный внешний вид, нейминг etc. Если каждый будет писать так, как ему вздумается — мы получим хаотичные текстовые файлы, и для изменения каждого придется долго вникать.
Про количество переменных — уже давненько не используются циклы вида for(x;y;z), писать дженерики вида тоже не очень ясно или замыкания в виде T -> (where: { v -> x in }) тоже не передает сути.
Проект не соберется до тех пор, пока не будут исправлены все ошибки линтера — это дополнительная гарантия того, что только после успешного билда на CI будет влит данный PR и он не противоречит командным правилам.
ага, отличная идея — в 2019 году выпускать не 64 битные приложения… это первый фейл
а второй — пересобрать приложение, заново его подписать и отправить в App Store — грандиозная проблема
пока автор писал этот пост, мог уже с десяток приложений обновить.
ИМХО, физиологические признаки усталости намного более показательные, чем внешнее проявление и вот от этого стоит отталкиваться
например, ЧСС в состоянии утомления будет выше, чем у человека бодрого и отдохнувшего, потребление кислорода, давление… куча параметров, за которыми стоит последить
+ даже трекер времени в дороге к этому прикрутить и уже можно получить более — менее реалистичную картину
или как со Сталкер — пока ждали, он устарел. Хоть и культовая игра, но на момент выхода уже отстала на 2 — 3 года. Атмосфера и мододелы конечно вытащили проект на себе
очень и очень спорно.
Получается, что UIViewController просто проксирует модельки между презентером и UIView? тогда зачем он нужен? может UIViewController и сделать реализующим функции презентера?
Далее — у нас есть Interactor и workers, скажем — у меня несколько workerов общих, которые используются в interactor, а interactor не имеет другой логики — он опять что-то проксирует, тогда зачем он нужен?
А если использовать те же сервисы, то слоев проксирования возрастает кратно.
По итогу — получаем ту же модель MVC, только C — контроллер размазан по максимальному количеству слоев выполняющим все все функции, M — модель в виде глупых структур данных (пассивная модель), ну и хотя бы V — View без логики внутри.
Clean xyz — обычно происходит из книг статей Дядюшки Боба, но он не про такие слои писал… совсем не про это
Например, используя некое замыкание completion() === (void -> ()), реализуешь по сути переход GO TO к метке его создания, при этом практически анонимно, что полностью процедурно и вообще плохой тон.
ну во-первых, С++ это не ООП, и сам Страуструп об этом писал в своей книжке. Что классы в плюсах были созданы для более удобного структурирования кода. А в статье снова говорится не о минусах самого ООП, а о «как же плохо писать на ООП языке в процедурном стиле», и вместо решения проблемы или даже зачатков поиска ответа на поставленные вопросы, автор говорит «но я все равно буду писать на еще более примитивном процедурном уровне и создавать структуры данных».
Структура данных != Класс. Работа через структуры != моделирование объектного мира. Использование сеттеров, геттеров, опционалов замыканий генериков — еще больше отодвигает от настоящего ООП, который задумывался в бородатые годы, усугубляет текущие проблемы, делает код сложнее и запутаннее. Достаточно посмотреть на метрики и быстродействие софта.
1) что подразумевается под «мало переиспользования»? протокол с тремя методами — add, remove, update по модели и/или индексу и полетели
2) есть, в пару действий можно реализовать и перемещение и удаление и все что угодно, но речь идет о статичной (!) таблице, по этому данные кейсы не актуальны и излишни.
Для динамичного контента как раз и придуманы таблицы / коллекции, где так же можно обойтись без неистового оверхеда и генерик оверинжиниринга
3) Неудобно пользоваться через код [X]
???
WHAT ??7
ну и потом, если использовать для таблицы кастомные ячейки (ячейка с картинкой, полем и свитч — это же насколько огромный получится «универсальный» датасорс).
И для каждого нового типа ячейки — снова создавать свой протокол и ковырять класс
как раз проблемы с тем, чтобы «Натянуть картинку на стандартные элементы» — вряд ли отличная мотивация для использования кроссплатформы, учитывая — сколько инструментов имеется для создания нативных кастомных элементов, для которых созданы HIG, и придерживаюсь его — не испытываешь значительных проблем. А так звучит — мы дали вам велосипед, чтобы вы быстрее внедряли свой велосипед.
Стандартные элементы поведения — скролл, ввод текста, анимации навигации — уникальны для платформы, и когда они выглядят по-другому, это значительно снижает положительный опыт использования приложением, так как отходит от привычного HIG.
в 2008 году были хорошие машины, в 2015 были хорошие машины, даже в 2020 были хорошие машины, пока не появились куски электрического говна.
Nuphy Halo75 v2 Obsidian Black Silent Red Switch - выглядит весьма эстетично, и так же приятна для набора текста / кода. Пользуюсь уже 16 месяцев активно, все так же приносит удовольствие и звуком и тактильно. Пока что лучшее, что пробовал из механических.
Ну и инкрементальная сборка только того, что изменили — утопия… которая не работает.
Смысл линтера — чтобы весь код имел консистентный внешний вид, нейминг etc. Если каждый будет писать так, как ему вздумается — мы получим хаотичные текстовые файлы, и для изменения каждого придется долго вникать.
Про количество переменных — уже давненько не используются циклы вида for(x;y;z), писать дженерики вида тоже не очень ясно или замыкания в виде T -> (where: { v -> x in }) тоже не передает сути.
Проект не соберется до тех пор, пока не будут исправлены все ошибки линтера — это дополнительная гарантия того, что только после успешного билда на CI будет влит данный PR и он не противоречит командным правилам.
а второй — пересобрать приложение, заново его подписать и отправить в App Store — грандиозная проблема
пока автор писал этот пост, мог уже с десяток приложений обновить.
например, ЧСС в состоянии утомления будет выше, чем у человека бодрого и отдохнувшего, потребление кислорода, давление… куча параметров, за которыми стоит последить
+ даже трекер времени в дороге к этому прикрутить и уже можно получить более — менее реалистичную картину
Получается, что UIViewController просто проксирует модельки между презентером и UIView? тогда зачем он нужен? может UIViewController и сделать реализующим функции презентера?
Далее — у нас есть Interactor и workers, скажем — у меня несколько workerов общих, которые используются в interactor, а interactor не имеет другой логики — он опять что-то проксирует, тогда зачем он нужен?
А если использовать те же сервисы, то слоев проксирования возрастает кратно.
По итогу — получаем ту же модель MVC, только C — контроллер размазан по максимальному количеству слоев выполняющим все все функции, M — модель в виде глупых структур данных (пассивная модель), ну и хотя бы V — View без логики внутри.
Clean xyz — обычно происходит из книг статей Дядюшки Боба, но он не про такие слои писал… совсем не про это
Структура данных != Класс. Работа через структуры != моделирование объектного мира. Использование сеттеров, геттеров, опционалов замыканий генериков — еще больше отодвигает от настоящего ООП, который задумывался в бородатые годы, усугубляет текущие проблемы, делает код сложнее и запутаннее. Достаточно посмотреть на метрики и быстродействие софта.
когда можно создать вью модель, создать коллекцию с секциями и для секции сделать вертикальную / горизонтальную верстку.
2) есть, в пару действий можно реализовать и перемещение и удаление и все что угодно, но речь идет о статичной (!) таблице, по этому данные кейсы не актуальны и излишни.
Для динамичного контента как раз и придуманы таблицы / коллекции, где так же можно обойтись без неистового оверхеда и генерик оверинжиниринга
3) Неудобно пользоваться через код [X]
???
WHAT ??7
И для каждого нового типа ячейки — снова создавать свой протокол и ковырять класс
Стандартные элементы поведения — скролл, ввод текста, анимации навигации — уникальны для платформы, и когда они выглядят по-другому, это значительно снижает положительный опыт использования приложением, так как отходит от привычного HIG.