Насколько окружение для iOS сборки получается изолированным при таком подходе?
Полной изоляции на одной физической машине в режиме «shell» тяжело достичь, при таком подходе параллельные процессы просто стараются не пересекаться. В следующей части я покажу исходный код .gitlab-ci.yaml, который очень гибко с этим работает.
К слову, если говорить о полной изоляции, то эту проблему можно решить в Lume, создав под каждый проект свою VM, в которой будет настроен свой Gitlab Runner в режиме «shell».
Возможно ли запускать несколько пайплайнов параллельно, будут ли устанавливать зависимости в одни и те же глобальные директории (npm-модули, gems, pods) ?
Да, можно запускать пайплайны параллельно, зависимости устанавливаются в глобальные директории, с этим проблем не возникает. Единственное узкое место вижу только в FVM, если параллельно будут устанавливаться две одинаковые версии Flutter в одну глобальную директорию, но только при условии, что ранее эта версия не была загружена.
Надеюсь, что сообщество найдет способы восстановить доверие и открытость, чтобы Open Source остался тем пространством, которое объединяет, а не разделяет.
Команда Dart не объясняет, почему этого следует избегать в пакетах. Вопрос тянется ещё с 2015 года, однако этому есть разумное объяснение для одного из вариантов неправильного использования.
Рефакторинг через TDD помогает обезопасить себя от неочевидных ошибок, здесь также очень сильно зависит от того, насколько правильно разработчик понимает текущую бизнес-логику. Если тесты хорошо провалидированы, то промахов не возникает. Отмечу, что регрессионное тестирование всё равно проводится после написания тестов.
Касательно целесообразности, то конечно, проводить рефакторинг ради рефакторинга - сомнительная идея. Если код работает и он потенциально не расширяется, а самое важное, что это не является часто изменяемой функцией приложения и не приносит сильных неудобств, то можно оставить такой код до лучших времен.
С выходом Swift UI единственная проблема была в установке минимальной версии iOS 13, которая на тот момент являлась актуальной. Это сдерживало разработчиков какое-то время оставаться на UIKit.
Считаю, что сейчас прекрасное время, чтобы использовать Swift UI, ведь это охватывает большинство устройств на рынке. Как по мне, если у человека уже был опыт с Flutter или Jetpack Compose, то освоиться будет куда проще!
К слову, на данный момент, часть фичей из статьи реализованы в better_player, правда всё равно можно столкнуться с теми же проблемами, так как пакет перестал активно поддерживаться и под капотом это работает почти также. В потенциале есть пакет media_kit, который недавно начал разрабатываться, поживём-увидим.
Но если рассматривать жесткие требования со стороны бизнеса, никакие пакеты уже не спасут.
Все кто работал с KAPT знают, что основная его проблема - это скорость, он работает очень медленно
В сравнении с build_runner, это небо и земля. Не было цели сравнивать только kapt и KSP между собой. Посыл был в том, что если это работало хотя бы на уровне kapt, то проблема не казалась бы существенной.
Каждому изоляту выделяется отдельный Event Loop и своя память, а взаимодействие между изолятами возможно только посредством сообщений, что ведёт к тому, что в Dart нет параллелизма с общим состоянием. Вообще язык очень хитрый в этом плане, я бы назвал это псевдо многопоточностью? :)
все строго наоборот: сначала был kapt (как реализация стандартного аннотейшн процессора в джаве для котлина, которые работает достаточно медленно), а потом уже появился KSP.
Спасибо за наводку, действительно перепутал местами.
это все зависит от сценария использованения, для главной страницы магазина - врядли такое подойдет, но для внутренней админки бекенда - вполне, учитывая скорость разработки + функциональность.
Конечно это не останавливает разработчиков писать приложения на Flutter Web, но порой сталкиваешься с такими проблемами, которые и вовсе быть не должны. Скорость разработки может упасть, как только разработчик столкнется с проблемой движка, отсюда появляются обходные решения, костыли и креатив разработчика тут уже задействуется на полную. Иногда вот думаешь, а зачем я этими проблеми занимаюсь?
Да, несомненно нужно потратить своё время чтобы разобраться в языке, но на деле начать писать на Dart не так сложно. В Flutter бывает начинаешь писать на Dart, потом переключаешься на Kotlin или Swift, чтобы реализовать конкретную нативную часть, и происходит это без страшных последствий. Наверное, с опытом уже неважно на чём писать :)
Такой риск правда существует, но лишь упомяну, что переход Flutter-разработчика в нативного возможен с меньшими затратами, поскольку присутствует общий опыт взаимодействия с платформами
Полной изоляции на одной физической машине в режиме «shell» тяжело достичь, при таком подходе параллельные процессы просто стараются не пересекаться. В следующей части я покажу исходный код .gitlab-ci.yaml, который очень гибко с этим работает.
К слову, если говорить о полной изоляции, то эту проблему можно решить в Lume, создав под каждый проект свою VM, в которой будет настроен свой Gitlab Runner в режиме «shell».
Да, можно запускать пайплайны параллельно, зависимости устанавливаются в глобальные директории, с этим проблем не возникает. Единственное узкое место вижу только в FVM, если параллельно будут устанавливаться две одинаковые версии Flutter в одну глобальную директорию, но только при условии, что ранее эта версия не была загружена.
Надеюсь, что сообщество найдет способы восстановить доверие и открытость, чтобы Open Source остался тем пространством, которое объединяет, а не разделяет.
Вам спасибо! Очень долго не мог выбрать подходящие хабы, исправил
Команда Dart не объясняет, почему этого следует избегать в пакетах. Вопрос тянется ещё с 2015 года, однако этому есть разумное объяснение для одного из вариантов неправильного использования.
Интересный вид! В суровой реальности при форматировании кода используют dartfmt, к сожалению, он раскладывает лесенкой:
Очень здорово! Да, практики полезные, особенно с обновлением виджетов.
Рефакторинг через TDD помогает обезопасить себя от неочевидных ошибок, здесь также очень сильно зависит от того, насколько правильно разработчик понимает текущую бизнес-логику. Если тесты хорошо провалидированы, то промахов не возникает. Отмечу, что регрессионное тестирование всё равно проводится после написания тестов.
Касательно целесообразности, то конечно, проводить рефакторинг ради рефакторинга - сомнительная идея. Если код работает и он потенциально не расширяется, а самое важное, что это не является часто изменяемой функцией приложения и не приносит сильных неудобств, то можно оставить такой код до лучших времен.
Я с радостью приведу примеры кода в отдельном материале, эта статья писалась с точки зрения выстраивания процессов, предшествующих рефакторингу.
С выходом Swift UI единственная проблема была в установке минимальной версии iOS 13, которая на тот момент являлась актуальной. Это сдерживало разработчиков какое-то время оставаться на UIKit.
Считаю, что сейчас прекрасное время, чтобы использовать Swift UI, ведь это охватывает большинство устройств на рынке. Как по мне, если у человека уже был опыт с Flutter или Jetpack Compose, то освоиться будет куда проще!
К слову, на данный момент, часть фичей из статьи реализованы в better_player, правда всё равно можно столкнуться с теми же проблемами, так как пакет перестал активно поддерживаться и под капотом это работает почти также. В потенциале есть пакет media_kit, который недавно начал разрабатываться, поживём-увидим.
Но если рассматривать жесткие требования со стороны бизнеса, никакие пакеты уже не спасут.
Спасибо за ссылку, очень полезно
В сравнении с build_runner, это небо и земля. Не было цели сравнивать только kapt и KSP между собой. Посыл был в том, что если это работало хотя бы на уровне kapt, то проблема не казалась бы существенной.
Спасибо, это была небольшая опечатка, которая уже исправлена
Соглашусь, любой инструмент выбирается от задачи и жизненного цикла приложения.
Каждому изоляту выделяется отдельный Event Loop и своя память, а взаимодействие между изолятами возможно только посредством сообщений, что ведёт к тому, что в Dart нет параллелизма с общим состоянием. Вообще язык очень хитрый в этом плане, я бы назвал это псевдо многопоточностью? :)
Спасибо за наводку, действительно перепутал местами.
Конечно это не останавливает разработчиков писать приложения на Flutter Web, но порой сталкиваешься с такими проблемами, которые и вовсе быть не должны. Скорость разработки может упасть, как только разработчик столкнется с проблемой движка, отсюда появляются обходные решения, костыли и креатив разработчика тут уже задействуется на полную. Иногда вот думаешь, а зачем я этими проблеми занимаюсь?
Да, несомненно нужно потратить своё время чтобы разобраться в языке, но на деле начать писать на Dart не так сложно. В Flutter бывает начинаешь писать на Dart, потом переключаешься на Kotlin или Swift, чтобы реализовать конкретную нативную часть, и происходит это без страшных последствий. Наверное, с опытом уже неважно на чём писать :)
Такой риск правда существует, но лишь упомяну, что переход Flutter-разработчика в нативного возможен с меньшими затратами, поскольку присутствует общий опыт взаимодействия с платформами