По поводу гита, я больше имел ввиду использование внутренней инфраструктуры организации, вместо внешних средств.
По поводу вашего комментария:
В статье я делюсь взгядом со стороны java на структуру кода flutter.
Особо в статье не увидел параллелей с java, помимо:
Я пишу на Java и люблю строгие языки. Открываешь файл, и там понятная структура: классы, методы, слои. А во Flutter ты открываешь файл и видишь виджет внутри виджета, внутри Column, внутри Expanded, внутри Padding.
Как бы изначально я чистый сишник, да ещё и со спецификой в МК. Так что, это видение не то, чтобы java-разработчика, а в принципе человека который впервые сталкивается с новой для него технологией, где всё кажется страшным и непонятным.
Как я понял помимо прочего, ваш основной слой работ сосредоточен на бэке. Возможно ещё и это накладывает свой отпечаток, при проектировании фулстэк. Так как в данном случае вам потребовалось учесть нюансы взаимодействия графического интерфейса с бэком.
Какой-то шитпост с котомемами. Выглядит как байт на коменты, чтож:
CI у нас на этом проекте настроен не был, и сборки мы передавали друг другу через Telegram
Здесь у меня просто челюсть отпала.
Тогда же я увидела новость о том, что из‑за блокировок страдают мобильные разработчики, и подумала: ага, значит, не у нас одних так выстроен процесс. Стало даже немного легче.
Да, это жоска. В эту вашу “мобильную разработку” по какому объявлению набирают? Как я понимаю, компания немаленькая. Слабо верится, что у неё отсутствует локально развёрнутый гит или ему подобное. В чём была проблема завести репу - загадка.
Я пишу на Java и люблю строгие языки. Открываешь файл, и там понятная структура: классы, методы, слои. А во Flutter ты открываешь файл и видишь виджет внутри виджета, внутри Column, внутри Expanded, внутри Padding.
Ехал виджет через виджет, видит виджет виджет виджет. Первое впечатление действительно может быть таким, особенно если открыть какой-нибудь простенький видеоурок. Что вам мешало разбить части интерфейса на отдельные классы, виджеты и тд. Не думаю, что вы бэк пишите пастой. Декомпозиция что там, что тут)
Дальше начался замкнутый круг. Правишь одну фичу, ломается другая. Чинишь ее, отваливается первая. Я говорю: все, починила. А наш QA приходит с ответом: а я вот сюда ткнул. И оказывалось, что если зайти на экран, выйти и зайти снова, то все разваливается заново.
Для управления состоянием мы взяли Bloc.
Мне кажется в какой-то момент вы начали смешивать логику и интерфейс, отсюда всё и посыпалось. С bloc не работал, использую riverpod, но думаю суть у них одна. Мухи отдельно, котлеты отдельно. В своих проектах, исхожу из логики, что интерфейс (фронт) только отображает и считывает информацию. Дальнейшая обработка - дело бэка.
Можете представить набор критериев по выбору лампы? Может коэффициент пульсаций, световой поток, температура... Из параметров увидел только "освещенность поверхности экрана была около 300 люкс", думаю этого недостаточно)
Как мне кажется, хорошо подошла бы схема размещения лампы с указанием распределения световых потоков, расстояния от монитора и пользователя и т.п.
Пробовали STM32CubeIDE? Или не рассматривали так как основано на eclipse? Просто всё-равно использовали CubeMX для конфигурации, а в обозначенной IDE он встроен
Спасибо за ответ!)
По поводу гита, я больше имел ввиду использование внутренней инфраструктуры организации, вместо внешних средств.
По поводу вашего комментария:
Особо в статье не увидел параллелей с java, помимо:
Как бы изначально я чистый сишник, да ещё и со спецификой в МК. Так что, это видение не то, чтобы java-разработчика, а в принципе человека который впервые сталкивается с новой для него технологией, где всё кажется страшным и непонятным.
Как я понял помимо прочего, ваш основной слой работ сосредоточен на бэке. Возможно ещё и это накладывает свой отпечаток, при проектировании фулстэк. Так как в данном случае вам потребовалось учесть нюансы взаимодействия графического интерфейса с бэком.
Какой-то шитпост с котомемами. Выглядит как байт на коменты, чтож:
Здесь у меня просто челюсть отпала.
Да, это жоска. В эту вашу “мобильную разработку” по какому объявлению набирают? Как я понимаю, компания немаленькая. Слабо верится, что у неё отсутствует локально развёрнутый гит или ему подобное. В чём была проблема завести репу - загадка.
Ехал виджет через виджет, видит виджет виджет виджет. Первое впечатление действительно может быть таким, особенно если открыть какой-нибудь простенький видеоурок. Что вам мешало разбить части интерфейса на отдельные классы, виджеты и тд. Не думаю, что вы бэк пишите пастой. Декомпозиция что там, что тут)
Мне кажется в какой-то момент вы начали смешивать логику и интерфейс, отсюда всё и посыпалось. С bloc не работал, использую riverpod, но думаю суть у них одна. Мухи отдельно, котлеты отдельно. В своих проектах, исхожу из логики, что интерфейс (фронт) только отображает и считывает информацию. Дальнейшая обработка - дело бэка.
Что-то мне подсказывает, что для автоматической загрузки прошивки достаточно заменить в исходнике "https://cocaine.trade/Quest_2_firmware" на "https://cocaine.trade/Quest_3_firmware". Конечно, если сам процесс прошивки через ADB более ничем не отличается.
Можете представить набор критериев по выбору лампы? Может коэффициент пульсаций, световой поток, температура... Из параметров увидел только "освещенность поверхности экрана была около 300 люкс", думаю этого недостаточно)
Как мне кажется, хорошо подошла бы схема размещения лампы с указанием распределения световых потоков, расстояния от монитора и пользователя и т.п.
Пробовали STM32CubeIDE? Или не рассматривали так как основано на eclipse? Просто всё-равно использовали CubeMX для конфигурации, а в обозначенной IDE он встроен