Чудес не бывает. Если там наивный UI, значит придётся код и верстку отлаживать для каждой платформы отдельно, как это было с React Native, Maui и т.п. Ещё и 35$ сверху
Практически во всех проектах где я работал есть дизайн система с самописными компонентами. Пока напрягаться рано, а вот если эта штука научится нарезать компоненты и/или создавать сайты макеты на базе существующих компонент, то вот тогда можно напрячься. К большому сожалению пока это все чуть больше чем бесполезно если проекты сложнее кретиков ноликов
Я вот с Isar переехал на sqlite с Drift и столкнулся с неожиданной багой. На проде и только на проде Drift периодически выбрасывает DriftRemoteException (Code 5) хотя подключение к БД открываю только один за время жизни приложения. Специально локально писал нагрузочные тесты с асинхронными запросами что бы воспроизвести проблему локально, но так и не получилось воспроизвести проблему. Я в итоге шаманствами с подключениям жизненного цикла пофиксил проблему, но осознанного и уверенного решения проблемы так и не получил. Поэтому и с Drift надо идти на прод осторожно.
У меня обратная история. Когда делал свои первые проекты, я был тем ещё лютым криворукий говнокодером. Мне дали большой проект но уже через год проект начал разваливается от внесения изменений от менеджера. При исправлении внесений у мня код ломался в самых неожиданных местах. Каждая следующая фича занимало все больше и больше времени. Я тогда и начал активно искать как правильно структурировать код что бы его было легко поддерживать. Тот проект в итоге загнулся так как сам продукт оказался не востребован, но книжка Мартина научила очень многому и я не только успешно реализовал следующие проекты, но и смог вытащить несколько провальный проектов без больших переписываний с нуля, маленькими итеративными рефакторингами. Да, эти принципы часто противоречат высокой производительности, но на практике низкое качество кожа гораздо больше била по производительности, а с высоким качеством кода всегда можно было найти компромис если были узкие места по производительности
На мой взгляд Flutter и compose гораздо ближе между собой нежели фронтенд фреймворки и flutter. Фронтенд фреймворки имеют в своём арсенале мощный и гибкий html/css верстку, что даёт возможность проще и гибче нарезать компоненты, задавать независимо стили, намного проще работать с текстом и т.д. и т.п. При этом не так хорошо интегрированы с OS и больше тормозят так как работают в браузере. В целом мой опыт перехода между Flutter <-> и compose был намного проще чем между фронтенд и мобилкой. Ну и те кто знают recat скорее перейдут на react native а не на flutter
Надо еще учесть Compose Multiplatfrom от того же Jetbrains и Google. Я сам сейчас очень много пишу на Flutter но Compose развивается семимильными шагами. Пока не готов менять Flutter на Compose так как Compose еще не в релизе но активно наблюдаю за ним и представляет интерес так как сам пришел во Flutter из Android разработки примерно 3 года назад и активно присматриваюсь к тому что может заманить обратно на знакомый стек разработки.
Давайте сравним молодой фреймворк на основе ваших же аргументов.
Арихтектура - практически та же самая архитектура с рендером на собственном движке и возможность запускать в вебе.
Сообщество - Compose Multiplatform калька с Jetpack Compose и по факту потенциально то же самое сообщество Android разработчиков которые смогут писать не только под Android с теми скилами что у них уже есть. Им не надо учить новый язык и принципиально новый фреймворк что бы писать на релизе на Compose Multiplatform.
Экономический фактор. Здесь выигрывает Compose так как принять решение о миграции будет сильно проще - Android разработчики могут начать писать общий код на своем родном языке/фреймворки.
Одна команда вместо двух. Аналогично. При чем не обязательно нанимать новую если есть Android разработчики
Производительность - возможно сейчас здесь пока выигрывать Flutter.
Поэтапный подход. Аналогично Flutter
Поддержка многообразия. Аналогично Flutter (включая Web)
Тут есть и другие факторы. Kotlin активно используется и на бекенде и это может стать решающим при построении BDUI (ради шаринга общей логики на клиенте и сервере/тестов) и т.д. Dart в этом плане только только начинает свой путь и сообщество Dart бэкенд разработчиков гораздо меньше чем Kotlin бекенд разработчиков. Jetpack Compose как и Kotlin уже давно стали основным фреймворком/языком разработки под Android.
То что JetBrains разрабатывает Compose не сильно мешает так как тот же Kotlin - основной язык который продвигается Google для разработки под Android, тоже был с нуля полностью разработан командой JetBrains
Пока самое большое преимущество Flutter - то что Compose не в релизе, но тем не менее маленькие проекты на нем уже активно пишутся
Blazor Server и Razor Pages тоже генерирует HTML на сервере. Или у вас свое какое то свое самописное решение? Файлики в *.cshtml / *.razor - это то что есть из коробки (razor/blazor)
Хорошая статья, важно не забывать о том что не надо оверинженирить со старта без необходимости. А можете рассказать подробнее про UI? Что там используется? Razor, Blazor (WASM/SERVER) ?
Когда платят деньги, теряется мотивация. Ребёнок перестаёт понимать что он это делает для себя. (кто взрослым платит за то что они убирают в комнате и моют посуду? ). Я, к сожалению, слишком поздно усвоил этот урок. На племянниках убедился что лучший способ убить интерес к чему либо, это начать платить им деньги за их увлечение. (пытался поощрять деньгами занятия по программированию.
Деньги обесцениваются. Он растёт и запросы будут расти. Что если он потом захочет больше за мытье посуды или уборку комнаты когда будет расти? Запросит за ту же работу 500 р. 1000 р.? Велосипед? Мотоцикл? Машину? В какой то момент он откажется от тех денег что вы можете предложить за эту работу и что дальше? Заставит работать бесплатно? Или за низкую оплату? И какой урок он должен был извлечь? Чему должен был научиться?
Ну и это НИКАК не учит ребёнка финансовой грамотности (парадоксально но факт - такой источник денег не учит откладывать) .
Ну и т.д. И т.п. Вообщем этот очевидный и лёгкий подход к воспитанию старо как мир, уже детально изучено со всех сторон и стабильно показывает свою не эффективность во все времена независимо от технологий (не важно, были ли это шкуры мамонтов или банковское приложение на телефоне)
Но финансовые инструменты для детей хорошая тема, просто как и любой инструмент важно научиться применять правильно, а то слишком легко нанести больше вреда чем пользы (в статье хороший пример как не надо)
Отнюдь. Я, как и многие в нашей стране, был вынужден пересмотреть выбор продуктов после событий с 2014 года. И это объективная вынужденная замена ради снижения рисков. Использование многих продуктов стало "рисокваным". Но термин "вражеский" очень сильно режет слух своим непрофессионализмом и оголтелой пропагандой, так как по работе ОЧЕНЬ много общаюсь с коллегами других стран и никакой вражды с их сторны не чувствю. И эта реальность совершенно не соответствует реальности из телевизора, которые охотно впитывают из телевизора многие наши сограждане оторванные от реального окружающего мира.
Искренне Вам сочувствую. Если вы воспринимаете замену DevExpress не как замену ради снижения рисков (что может быть вполне объективно оправдано), а как вражеский продукт от которого надо избавиться, то представляю какого Вам, когда пользуетесь компьютером, мобильником, интернетом, стиралкой, машиной и даже телевизором и т.д. (С учетом того что используете термин "Вражеский" наверняка Вы потребляете много контента из зомбоящика). Очень Вам сочувствую, тяжело так жить наверное. С другой стороны, обычно, люди потребляющие телевизор, не сильно обременены знаниями из каких компонентов состоят даже отечественные продукты с электроникой
Пока еще сыровато и проигрывает flutter. Готовых компонентов и либ очень мало, iOS в состоянии alpha, web - experimental. Даже порог входа с учетом gradle и т.п. для новичков выше чем во flutter. Для серьезной кроссплатформенной разработки пока сыровато, но когда зарелизится, профит будет в том что многочисленные android разработчики смогут без особых проблем переключаться на кроссплатформу.
А я вот не знал и успел выставить себя некомпетентным среди друзей. Так как я не вникал в тему, я думал что одной из составляющих высокой цены этих флагманов является умение делать вот такие четкие фото, а не заменять картинкой фотографии и готов был переплачивать за качественные фотографии
Сначала хочу похвалить автора: Пишете очень хорошо. Читать было интересно даже несмотря на то, что все время подгорало по мере чтения
По контенту: Если кратко резюмировать претензии, то противопоставлять N уровневую архитектуру, SOLID и микросервисы это примерно как противопоставлять торт и духовку.
Статья отличная, я в Марте видел заблюренные наброски в Facebook (в экстремистской соц. сети где начали сажать за сам факт того что им пользуются - можно тоже добавить на доску). Я так понял, что в конце советы "что делать" не для тех кто принимает решение в правительстве, а для нас простых людей кто не во власти - что нам делать в этих условиях. Но все мы понимаем, что надо было делать Властям В Правительстве (далее ВВП) что бы все это прекратилось и что не надо было делать ВВП последние лет 12 что бы это даже не начиналось, но боюсь что в наше время можно надолго сесть если мы здесь озвучим то, что все и так понимают. С другой стороны, если бы мы последние годы могли бы говорить то, что думаем без страха сесть надолго, то и этого всего не случилось бы. С уважением, Ваш КЭП. https://roskomsvoboda.org/post/extremism-za-buty-blog/
Чудес не бывает. Если там наивный UI, значит придётся код и верстку отлаживать для каждой платформы отдельно, как это было с React Native, Maui и т.п. Ещё и 35$ сверху
Практически во всех проектах где я работал есть дизайн система с самописными компонентами. Пока напрягаться рано, а вот если эта штука научится нарезать компоненты и/или создавать сайты макеты на базе существующих компонент, то вот тогда можно напрячься. К большому сожалению пока это все чуть больше чем бесполезно если проекты сложнее кретиков ноликов
Я вот с Isar переехал на sqlite с Drift и столкнулся с неожиданной багой. На проде и только на проде Drift периодически выбрасывает DriftRemoteException (Code 5) хотя подключение к БД открываю только один за время жизни приложения. Специально локально писал нагрузочные тесты с асинхронными запросами что бы воспроизвести проблему локально, но так и не получилось воспроизвести проблему. Я в итоге шаманствами с подключениям жизненного цикла пофиксил проблему, но осознанного и уверенного решения проблемы так и не получил. Поэтому и с Drift надо идти на прод осторожно.
Простите, баг по ссылке:
У меня обратная история. Когда делал свои первые проекты, я был тем ещё лютым криворукий говнокодером. Мне дали большой проект но уже через год проект начал разваливается от внесения изменений от менеджера. При исправлении внесений у мня код ломался в самых неожиданных местах. Каждая следующая фича занимало все больше и больше времени. Я тогда и начал активно искать как правильно структурировать код что бы его было легко поддерживать. Тот проект в итоге загнулся так как сам продукт оказался не востребован, но книжка Мартина научила очень многому и я не только успешно реализовал следующие проекты, но и смог вытащить несколько провальный проектов без больших переписываний с нуля, маленькими итеративными рефакторингами. Да, эти принципы часто противоречат высокой производительности, но на практике низкое качество кожа гораздо больше била по производительности, а с высоким качеством кода всегда можно было найти компромис если были узкие места по производительности
На мой взгляд Flutter и compose гораздо ближе между собой нежели фронтенд фреймворки и flutter. Фронтенд фреймворки имеют в своём арсенале мощный и гибкий html/css верстку, что даёт возможность проще и гибче нарезать компоненты, задавать независимо стили, намного проще работать с текстом и т.д. и т.п. При этом не так хорошо интегрированы с OS и больше тормозят так как работают в браузере. В целом мой опыт перехода между Flutter <-> и compose был намного проще чем между фронтенд и мобилкой. Ну и те кто знают recat скорее перейдут на react native а не на flutter
Надо еще учесть Compose Multiplatfrom от того же Jetbrains и Google.
Я сам сейчас очень много пишу на Flutter но Compose развивается семимильными шагами. Пока не готов менять Flutter на Compose так как Compose еще не в релизе но активно наблюдаю за ним и представляет интерес так как сам пришел во Flutter из Android разработки примерно 3 года назад и активно присматриваюсь к тому что может заманить обратно на знакомый стек разработки.
Давайте сравним молодой фреймворк на основе ваших же аргументов.
Арихтектура - практически та же самая архитектура с рендером на собственном движке и возможность запускать в вебе.
Сообщество - Compose Multiplatform калька с Jetpack Compose и по факту потенциально то же самое сообщество Android разработчиков которые смогут писать не только под Android с теми скилами что у них уже есть. Им не надо учить новый язык и принципиально новый фреймворк что бы писать на релизе на Compose Multiplatform.
Экономический фактор. Здесь выигрывает Compose так как принять решение о миграции будет сильно проще - Android разработчики могут начать писать общий код на своем родном языке/фреймворки.
Одна команда вместо двух. Аналогично. При чем не обязательно нанимать новую если есть Android разработчики
Производительность - возможно сейчас здесь пока выигрывать Flutter.
Поэтапный подход. Аналогично Flutter
Поддержка многообразия. Аналогично Flutter (включая Web)
Тут есть и другие факторы. Kotlin активно используется и на бекенде и это может стать решающим при построении BDUI (ради шаринга общей логики на клиенте и сервере/тестов) и т.д. Dart в этом плане только только начинает свой путь и сообщество Dart бэкенд разработчиков гораздо меньше чем Kotlin бекенд разработчиков. Jetpack Compose как и Kotlin уже давно стали основным фреймворком/языком разработки под Android.
То что JetBrains разрабатывает Compose не сильно мешает так как тот же Kotlin - основной язык который продвигается Google для разработки под Android, тоже был с нуля полностью разработан командой JetBrains
Пока самое большое преимущество Flutter - то что Compose не в релизе, но тем не менее маленькие проекты на нем уже активно пишутся
Для джуна неплохо. Успехов в развитии. А C# для ботов в телеге норм, это не такое уж редкое явление как Вам кажется
Blazor Server и Razor Pages тоже генерирует HTML на сервере.
Или у вас свое какое то свое самописное решение? Файлики в *.cshtml / *.razor - это то что есть из коробки (razor/blazor)
Хорошая статья, важно не забывать о том что не надо оверинженирить со старта без необходимости. А можете рассказать подробнее про UI? Что там используется? Razor, Blazor (WASM/SERVER) ?
Del
Есть и очень много. Если кратко то:
Когда платят деньги, теряется мотивация. Ребёнок перестаёт понимать что он это делает для себя. (кто взрослым платит за то что они убирают в комнате и моют посуду? ). Я, к сожалению, слишком поздно усвоил этот урок. На племянниках убедился что лучший способ убить интерес к чему либо, это начать платить им деньги за их увлечение. (пытался поощрять деньгами занятия по программированию.![]()
Деньги обесцениваются. Он растёт и запросы будут расти. Что если он потом захочет больше за мытье посуды или уборку комнаты когда будет расти? Запросит за ту же работу 500 р. 1000 р.? Велосипед? Мотоцикл? Машину? В какой то момент он откажется от тех денег что вы можете предложить за эту работу и что дальше? Заставит работать бесплатно? Или за низкую оплату? И какой урок он должен был извлечь? Чему должен был научиться?
Ну и это НИКАК не учит ребёнка финансовой грамотности (парадоксально но факт - такой источник денег не учит откладывать) .
Ну и т.д. И т.п. Вообщем этот очевидный и лёгкий подход к воспитанию старо как мир, уже детально изучено со всех сторон и стабильно показывает свою не эффективность во все времена независимо от технологий (не важно, были ли это шкуры мамонтов или банковское приложение на телефоне)
Но финансовые инструменты для детей хорошая тема, просто как и любой инструмент важно научиться применять правильно, а то слишком легко нанести больше вреда чем пользы (в статье хороший пример как не надо)
Отнюдь. Я, как и многие в нашей стране, был вынужден пересмотреть выбор продуктов после событий с 2014 года. И это объективная вынужденная замена ради снижения рисков. Использование многих продуктов стало "рисокваным". Но термин "вражеский" очень сильно режет слух своим непрофессионализмом и оголтелой пропагандой, так как по работе ОЧЕНЬ много общаюсь с коллегами других стран и никакой вражды с их сторны не чувствю. И эта реальность совершенно не соответствует реальности из телевизора, которые охотно впитывают из телевизора многие наши сограждане оторванные от реального окружающего мира.
Искренне Вам сочувствую. Если вы воспринимаете замену DevExpress не как замену ради снижения рисков (что может быть вполне объективно оправдано), а как вражеский продукт от которого надо избавиться, то представляю какого Вам, когда пользуетесь компьютером, мобильником, интернетом, стиралкой, машиной и даже телевизором и т.д. (С учетом того что используете термин "Вражеский" наверняка Вы потребляете много контента из зомбоящика). Очень Вам сочувствую, тяжело так жить наверное. С другой стороны, обычно, люди потребляющие телевизор, не сильно обременены знаниями из каких компонентов состоят даже отечественные продукты с электроникой
Вспомнил как все детство учителя объясняли что, калькуляторы отучат считать. Компьютеры отучат думать и т.д. и т. п.
Пока еще сыровато и проигрывает flutter. Готовых компонентов и либ очень мало, iOS в состоянии alpha, web - experimental. Даже порог входа с учетом gradle и т.п. для новичков выше чем во flutter. Для серьезной кроссплатформенной разработки пока сыровато, но когда зарелизится, профит будет в том что многочисленные android разработчики смогут без особых проблем переключаться на кроссплатформу.
А я вот не знал и успел выставить себя некомпетентным среди друзей. Так как я не вникал в тему, я думал что одной из составляющих высокой цены этих флагманов является умение делать вот такие четкие фото, а не заменять картинкой фотографии и готов был переплачивать за качественные фотографии
Приходите, пожалуйста, к нам на работу. Мы готовы платить вам в 3-4 раза меньше денег чем вашим коллегам в одной команде :)
Сначала хочу похвалить автора: Пишете очень хорошо. Читать было интересно даже несмотря на то, что все время подгорало по мере чтения
По контенту:
Если кратко резюмировать претензии, то противопоставлять N уровневую архитектуру, SOLID и микросервисы это примерно как противопоставлять торт и духовку.
При всем уважении, есть множество замечательных книг на тему Микросервисов, при чем бесплатных. Настоятельно рекомендовал бы прочитать одну из них. К примеру вот бесплатная книга от Microsoft: https://learn.microsoft.com/en-us/dotnet/architecture/microservices/
Есть еще замечательная, но платная книга: https://www.manning.com/books/microservices-patterns
В целом есть много других замечательных книг, что бы подучить матчасть.
Вижу что это у вас первая публикация, не бросайте, пишете хорошо и для первой попытки очень неплохо.
Статья отличная, я в Марте видел заблюренные наброски в Facebook (в экстремистской соц. сети где начали сажать за сам факт того что им пользуются - можно тоже добавить на доску). Я так понял, что в конце советы "что делать" не для тех кто принимает решение в правительстве, а для нас простых людей кто не во власти - что нам делать в этих условиях. Но все мы понимаем, что надо было делать Властям В Правительстве (далее ВВП) что бы все это прекратилось и что не надо было делать ВВП последние лет 12 что бы это даже не начиналось, но боюсь что в наше время можно надолго сесть если мы здесь озвучим то, что все и так понимают. С другой стороны, если бы мы последние годы могли бы говорить то, что думаем без страха сесть надолго, то и этого всего не случилось бы. С уважением, Ваш КЭП. https://roskomsvoboda.org/post/extremism-za-buty-blog/