Дело в том что я увлекаюсь фотографией и уже делал не раз то упражнение о чем вы говорите и неоднократно работал над тем что бы одновременно проявить и луну и здание на фото так, как мы это видим в реальности. Но я теперь даже не знаю кому верить, своим собственным глазам, своему опыту, мировым учёным неоднократно измерявшим дд глаз (а я изучал результаты экспериментов вплоть до разницы восприятия цвета и света между мужчинами и женщинами и разными рассами людей (а разница есть, так как в среднем дальтонизмом мужчины гораздо чаще страдают) (в среднем - потому что частота ещё зависит от расчы и генов). Или верить Вам, просто потому что вы считаете что ДД того как мы видим в моменте не 20-25 а меньше камеры потому что Вы так голословно заявляете. Опять таки нормальный человек, не способен отключать колбочки или палочки, люди видят сшитую картинку в ДД на 20-30 стопов
Когда вы смотрите на луну, вы все равно видете боковым зрением звезды. Если у вас пропадают звезды когда рассматриваете на луну, значит есть проблемы со зрением.
Простите, я без издевки или какого либо сарказма, но возможно Вам стоит проверить зрение если не получается увидеть и звезды и поверхность луны. Без шуток.
То о чем Вы говорите дает вообще 30-50 стопов, что позволяет видеть нам и днем и ночью.
У глаза есть свой ДД и этот "мгновенный" ДД сопоставим с топовыми камерами. Но мы так не видим.
Есть еще "сшивание" экспозиции (свего рода HDR, но сшивание от колбочек и палочек) который позволяет в моменте видеть 20-25 стопов без перехода в тень и свет. Это то как мы обычно видим сцену и что постоянно встречается в упоминаниях.
Для примера попробуйте топовой камерой в 15 стопов увидеть и поверхность луны и звезды одновременно. Хотя люди и звезды и поврехность луны могут видеть одновременно.
Или в яркий солнечный день в полдень в парке мы можем спокойно видеть содержимое в тени под густой листвой не уводя то что на солнце в белый пересвет, а для топовых камер это почти невыполнимая задача (конечно без HDR и/или мультиэкспозиции)
Я абсолютно не верю в гороскоп, ровно как не верю в плоскую землю и другие вещи которые сейчас рассказывают по зомбоящику. Но когда встречаю человека с другим мировоззрением, другой точкой зрения, мне крайне любопытно пообщаться с этим человеком. Узнать что он думает насчет нысостыковок и т.д. и т.п. Самое интересное что если не спорить, а найти какую то общую точку для обсуждения и обсуждать вопросы без спора и претензий, а в духе "интересно, а вот что думаете на вот этот спорный момент", то очень часто люди по мере общения отказываются от своих взглядов. И можно обнаружить что у многих людей своя интерпретация реальности, разная степень фанатичной веры и т.п. С родителями, к примеру, мы совершенно разных точек зрения насчет СВО, но достаточно просто спокойно пообщаться, выслушать и задавать вопросы что бы они сами сделали выводы. В любом случае всегда очень интересно общаться с людьми с другой точкой зрения на мир, отличного от вашего.
Что касается астрологии, предлагаю провести слепой тест: Т.е. взять общих знакомых людей из моего круга общения и предположить кто он по знаку зодиака и посмотреть, сколько раз угадают его знак.
На вопрос "кто ты по знаку зодиака?" я обычно отвечаю что раньше был Водолеем а стал Козерогом. Дело в том что день рождение выпло на стыке (20 января) и раньше 20 января писали водолеем (до сих пор в некоторых гороскопах так и пишут но уже сильно реже), а потом почему то решили сдвинуть знаки на 1 день и стал козерогом.
Самое удивительное раньше говорили что я типичный водолей, а когда стал отвечать что я козерог, стали говорить что я типичный козерог.
Одна из задач ЦБ - не допустить гиперинфляции (что также критично для бизнеса) и основной инструмент регулирования инфляции - ключевая ставка. Вопрос: Что именно должна была сделать ЦБ по Вашему мнению, что бы не допустить гиперинфляции, когда из производства изымаются люди и вбрасываются миллионы за каждого изъятого из производства человека и при этом параллельно дешёвая рабочая сила в виде мигрантов тоже изымаются из экономики в виде массовых депортации и запретов на работу?
Чудес не бывает. Если там наивный 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) ?
Именно об этом мой первый коммент. У моего GFX100SII ДД чуть выше. Но дело в том что мы так не видим. В моменте мы видим сшитую картинку.
Дело в том что я увлекаюсь фотографией и уже делал не раз то упражнение о чем вы говорите и неоднократно работал над тем что бы одновременно проявить и луну и здание на фото так, как мы это видим в реальности. Но я теперь даже не знаю кому верить, своим собственным глазам, своему опыту, мировым учёным неоднократно измерявшим дд глаз (а я изучал результаты экспериментов вплоть до разницы восприятия цвета и света между мужчинами и женщинами и разными рассами людей (а разница есть, так как в среднем дальтонизмом мужчины гораздо чаще страдают) (в среднем - потому что частота ещё зависит от расчы и генов). Или верить Вам, просто потому что вы считаете что ДД того как мы видим в моменте не 20-25 а меньше камеры потому что Вы так голословно заявляете. Опять таки нормальный человек, не способен отключать колбочки или палочки, люди видят сшитую картинку в ДД на 20-30 стопов
Когда вы смотрите на луну, вы все равно видете боковым зрением звезды. Если у вас пропадают звезды когда рассматриваете на луну, значит есть проблемы со зрением.
Простите, я без издевки или какого либо сарказма, но возможно Вам стоит проверить зрение если не получается увидеть и звезды и поверхность луны. Без шуток.
То о чем Вы говорите дает вообще 30-50 стопов, что позволяет видеть нам и днем и ночью.
У глаза есть свой ДД и этот "мгновенный" ДД сопоставим с топовыми камерами. Но мы так не видим.
Есть еще "сшивание" экспозиции (свего рода HDR, но сшивание от колбочек и палочек) который позволяет в моменте видеть 20-25 стопов без перехода в тень и свет. Это то как мы обычно видим сцену и что постоянно встречается в упоминаниях.
Для примера попробуйте топовой камерой в 15 стопов увидеть и поверхность луны и звезды одновременно. Хотя люди и звезды и поврехность луны могут видеть одновременно.
Или в яркий солнечный день в полдень в парке мы можем спокойно видеть содержимое в тени под густой листвой не уводя то что на солнце в белый пересвет, а для топовых камер это почти невыполнимая задача (конечно без HDR и/или мультиэкспозиции)
Так что с заголовком у автора все нормально.
По их мнению, деньги позволяют поступить в вуз и с низкими баллами ЕГЭ.
https://ria.ru/amp/20250522/vuz-2018525290.html
Но это, конечно, другое
Я абсолютно не верю в гороскоп, ровно как не верю в плоскую землю и другие вещи которые сейчас рассказывают по зомбоящику. Но когда встречаю человека с другим мировоззрением, другой точкой зрения, мне крайне любопытно пообщаться с этим человеком. Узнать что он думает насчет нысостыковок и т.д. и т.п. Самое интересное что если не спорить, а найти какую то общую точку для обсуждения и обсуждать вопросы без спора и претензий, а в духе "интересно, а вот что думаете на вот этот спорный момент", то очень часто люди по мере общения отказываются от своих взглядов. И можно обнаружить что у многих людей своя интерпретация реальности, разная степень фанатичной веры и т.п. С родителями, к примеру, мы совершенно разных точек зрения насчет СВО, но достаточно просто спокойно пообщаться, выслушать и задавать вопросы что бы они сами сделали выводы. В любом случае всегда очень интересно общаться с людьми с другой точкой зрения на мир, отличного от вашего.
Что касается астрологии, предлагаю провести слепой тест: Т.е. взять общих знакомых людей из моего круга общения и предположить кто он по знаку зодиака и посмотреть, сколько раз угадают его знак.
На вопрос "кто ты по знаку зодиака?" я обычно отвечаю что раньше был Водолеем а стал Козерогом. Дело в том что день рождение выпло на стыке (20 января) и раньше 20 января писали водолеем (до сих пор в некоторых гороскопах так и пишут но уже сильно реже), а потом почему то решили сдвинуть знаки на 1 день и стал козерогом.
Самое удивительное раньше говорили что я типичный водолей, а когда стал отвечать что я козерог, стали говорить что я типичный козерог.
Одна из задач ЦБ - не допустить гиперинфляции (что также критично для бизнеса) и основной инструмент регулирования инфляции - ключевая ставка. Вопрос: Что именно должна была сделать ЦБ по Вашему мнению, что бы не допустить гиперинфляции, когда из производства изымаются люди и вбрасываются миллионы за каждого изъятого из производства человека и при этом параллельно дешёвая рабочая сила в виде мигрантов тоже изымаются из экономики в виде массовых депортации и запретов на работу?
del
Чудес не бывает. Если там наивный 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