Будут, но если эти десятки тысяч вопросов, из которых в очередной попытке задаются только сотня, будут менять каждый год, то сливы эти погоды не сделают
Сделают, я так проходил онлайн сертифкацию на upwork. Даже если раз в месяц вопросы будут менятся, 90 процентов будут слиты. Технологии меняются и развиваются, вопросы будут терять актуальность, их надо постоянно обновлять. Им придется содержать штат сотрудников в каждой из областей коих тысячи
Полагаю чтобы отсеять реальных спецов от всех остальных. Потому как отрасль сделали слишком востребованной. Заодно пополнить армию теми кто условно "притворяется" айтишниками. Только уверен это не будет работать.
Я не понял, меня просят пойти на госуслуги и ткнуть какую-то галочку Подтверждаю?
Не думаю. Будут скорее всего тесты на квалификацию, вроде тех что на upwork или других фриланс биржах. В любом случае все это фуфло, так как потом появятся ресурсы где будут обяснять как проходить такие тесты и со временем окажется что все офигеть какие специалисты
Если у upwork, с их бюджетом не получилось сделать эти тесты релевантными то у минцифры и подавно не выйдет.
Есть и обратная сторона медали когда приходит какой нибудь новичек/инноватор в молодую команду стартаперов и вместо некой проверенной и обкатанной технологии /фреймворка внедряет какую нибудь дичь которая ещё в ранней бете и работает кое как но со своей какой то фишкой, которая на текущем проекте возможно и не нужна вовсе. А потом еще эта условная либа/технология/фреймворк скоропостижно отходит в забытие ввиду остуствия поддержки/конкуренции и т.д.Впрочем такой кейс наверное довольно редкий и в на моей практики внедрение каких то новых технологий шло больше на пользу проекту. Однако логично будет предположить что подобный сценарий вполне возможен.
Платформенное взаимодействие одно из самых сложных вещей во флаттере и предполагает знания kotlin/swift/js на базовом уровне и знанием особенностей платформ для работы с их апи. Хотя если стоит задача поправить там что то в либе условной то хватит и общей базы по ЯП. Знаний одного дарта тут будет в любом случае недостаточно.
Это ваши личные проблемы и ваше субъективное мнение. У меня штук 5-6 банковских приложений стоит и сотня других. У телефона за 4 года лишь слегка просела емкость аккумулятора и только. Мобильные браузеры хоть и продвинулись за несколько десятков лет но все еще заметно отстают от десктопных по перфомансу и соответствии современным стандартам html/css/js. А уж нативные приложения в разы производительнее браузерных при достаточной оптимизации разумеется.
Каждый апдейт также проходит ревью. Другое дело что возможно не так тщательно но это уже как повезет. Ревьювер обычно заходит с тестового аккаунта а там ему уже разрабы могут что угодно подсунуть. Это как вариант ответа на вопрос почему пропустили однако я все же склоняюсь что тут скорее фактор халатности ревьверов играет. Или возможно даже так что ревью делает одна команда а банит приложение другая при этом у ревьеверов даже нету списка санкционных приложений как таковых.
Если задача рутинная то не важно. Просто соображаешь хуже, дольше код писать. Но вообще дурацкая затея во время работы курить. Но вот после работы самое то. Мозг расслабляет. Гораздо вреднее по ночам работать. Проблемы с позвоночником и давлением и так у программистов с возрастом наступают а если ещё режим нарушен...
Разработчику фрилансеру я бы советовал сливать заказчика уже после пункта 2. Ну если совсем начинающим то до пункта 6 чисто для опыта. Это совет от разработчика который половину карьеры сделал на фрилансе.Время = деньги. Нервы = здоровье. А заказчиков так то пруд пруди. Кстатии , что то мне подсказывает что автор статьи как раз и будет таким заказчиком которых стоит обходить стороной) А кому то даже лучше будет устроится в хорошую компанию чтобы деньги за вашу работу не доставались таким вот заказчикам.
Чето все нагнетают постоянно. Айти уже не то, денег мало, вакансий мало.. Хз я всегда без проблем новую работу находил.Причем на разных стеках и ЯП даже. Вот пару месяцев назад на новую работу устроился. С пятого где то по счету собеса. Ничего особо то не поменялось и не сравнить с тем что 10- 15 лет назад было по ит зарплатам в РФ.
Большинству андроид разработчиков, полагаю. В разрезе общего числа разработчиков или даже компаний занимающихся разработкой это будет меньшинство. Но спорить не буду поскольку со статистикой тут сложно а у самого у меня не было опыта работы с kotlin multiplatform. Но если бы меня спросили выбрал бы я RN или флаттер то я бы выбрал однозначно флаттер поскольку большой опыт есть разработки и там и там
Я тоже сначало немного расстроился, но сейчас больше склоняюсь к тому что последствия печальны не столько для флаттера сколько для гугла. Запрос на кроссплатформенный фреймворк у компаний и у разработчиков никуда не денется а на этом фоне флаттер одно из лучших если не лучшее решение. Найдут инвесторов. Кто знает может даже аппл возьмет под свое крыло. В своей статье он говорит что команда android всегда была довольно закрытая и я подозреваю что взаимодействие между командой flutter и командой android если и было то минимальное. Единственное, остается неясной судьба fuchsia, которая также подогревала интерес к флаттеру
Не думаю что от замены SizedBox на Padding код станет сильно чище и читабельнее. Как по мне в списках все же удобнее использовать SizedBox. Я использую SizedBox когда мне нужен только один отступ между двумя элементами с любой стороны, когда нужно больше использую Padding. Когда используется Padding надо еще подумать обернуть им виджет сверху для отступа снизу или виджет снизу для отступа сверху (тоже самое для отступов по горизонтале). Должно быть четкое понимание какому виджету нужен отступ иначе при рефакторинге вы рискуете потратить какое то время на поиск того виджета в который вы этот отступ добавили. Еще часто бывает что виджет переиспользуется. Он может быть изначально задуман таким а может таким оказаться впоследствии. И отступы для него могут быть разные на разных экранах. Если в коде виджета корневым элементом будет Padding, а кто то потом еще и условия добавит для различных отступов этого виджета на разных экранах, вместо того чтобы прописать отступы на самих экранах то это уже будет захламление кода. И вот эти вот вещи важнее как по мне. Правильная композиция и правильное применение отступов. Если мне на работе скажут использовать только Padding то это не будет для меня проблемой, однако в некоторых случаях SizedBox для меня предпочтительнее
Мне вот интересно сможет ли чат бот сгенерить вменяемый uikit для фронтенда. Про код понятно сам пользовался иногда для мини скриптов. А вот ui для каких то мини/пет проектов это было бы полезно. Понятно что для чего то более менее серьезного без дизайнера не обойтись
Ну во первых вы неправильно работаете с блоком. В офф доках описаны 2 способа взаимодействия их друг с другом. Внедряя их друг в друга через конструктор вы создаете тесное связывания которое пытаетесь решить через ивент бас. В результате вы получаете синглтон/god object, который будет глобальным. Это такой аналог редакса по сути. Смысл блока в том чтобы разбить логику на несвязанные между собой куски, мультисторы, на каждую фичу по блоку. Я бы и не писал бы если бы сам не пытался связать блоки через event bus когда только начинал карьеру во флаттере. Но пообщавшись с феликсом на гитхабе отбросил эту идею. Возможно концепция имеет место быть но для очень специфических задач.
После того как намучился с пакетами навигации (go router, routemaster, auto route), написал свой пакет. Пару недель на разработку зато все мои юз кейсы, которые неработали в других пакетах + стандартные кейсы работают как надо и покрыты тестами. Уж лучше так чем годами ковырятся с багами из за навигации кривой.
Сделают, я так проходил онлайн сертифкацию на upwork. Даже если раз в месяц вопросы будут менятся, 90 процентов будут слиты. Технологии меняются и развиваются, вопросы будут терять актуальность, их надо постоянно обновлять. Им придется содержать штат сотрудников в каждой из областей коих тысячи
Ну и конечно скрытый мотив данной инициативы это освоение бюджета чиновниками из минцифры. 40 милиардов таки на дороге не валяются
Полагаю чтобы отсеять реальных спецов от всех остальных. Потому как отрасль сделали слишком востребованной. Заодно пополнить армию теми кто условно "притворяется" айтишниками. Только уверен это не будет работать.
Не думаю. Будут скорее всего тесты на квалификацию, вроде тех что на upwork или других фриланс биржах. В любом случае все это фуфло, так как потом появятся ресурсы где будут обяснять как проходить такие тесты и со временем окажется что все офигеть какие специалисты
Если у upwork, с их бюджетом не получилось сделать эти тесты релевантными то у минцифры и подавно не выйдет.
Есть и обратная сторона медали когда приходит какой нибудь новичек/инноватор в молодую команду стартаперов и вместо некой проверенной и обкатанной технологии /фреймворка внедряет какую нибудь дичь которая ещё в ранней бете и работает кое как но со своей какой то фишкой, которая на текущем проекте возможно и не нужна вовсе. А потом еще эта условная либа/технология/фреймворк скоропостижно отходит в забытие ввиду остуствия поддержки/конкуренции и т.д.Впрочем такой кейс наверное довольно редкий и в на моей практики внедрение каких то новых технологий шло больше на пользу проекту. Однако логично будет предположить что подобный сценарий вполне возможен.
Краши есть и на андроиде. Но хуже всего, то что разработчики молчат в isuues. Если такая поддержка будет на релизе то это печально.
Платформенное взаимодействие одно из самых сложных вещей во флаттере и предполагает знания kotlin/swift/js на базовом уровне и знанием особенностей платформ для работы с их апи. Хотя если стоит задача поправить там что то в либе условной то хватит и общей базы по ЯП. Знаний одного дарта тут будет в любом случае недостаточно.
Это ваши личные проблемы и ваше субъективное мнение. У меня штук 5-6 банковских приложений стоит и сотня других. У телефона за 4 года лишь слегка просела емкость аккумулятора и только. Мобильные браузеры хоть и продвинулись за несколько десятков лет но все еще заметно отстают от десктопных по перфомансу и соответствии современным стандартам html/css/js. А уж нативные приложения в разы производительнее браузерных при достаточной оптимизации разумеется.
Тоесть вы считаете что "нормальный банк" на мобилках должен через браузер работать? Или я вас не так понял?
Каждый апдейт также проходит ревью. Другое дело что возможно не так тщательно но это уже как повезет. Ревьювер обычно заходит с тестового аккаунта а там ему уже разрабы могут что угодно подсунуть. Это как вариант ответа на вопрос почему пропустили однако я все же склоняюсь что тут скорее фактор халатности ревьверов играет. Или возможно даже так что ревью делает одна команда а банит приложение другая при этом у ревьеверов даже нету списка санкционных приложений как таковых.
Если задача рутинная то не важно. Просто соображаешь хуже, дольше код писать. Но вообще дурацкая затея во время работы курить. Но вот после работы самое то. Мозг расслабляет. Гораздо вреднее по ночам работать. Проблемы с позвоночником и давлением и так у программистов с возрастом наступают а если ещё режим нарушен...
Это те кто ворует ваши стейки разве не понятно? Это может быть ваша жена или хомяк который просто мимо пробегал...
Разработчику фрилансеру я бы советовал сливать заказчика уже после пункта 2. Ну если совсем начинающим то до пункта 6 чисто для опыта. Это совет от разработчика который половину карьеры сделал на фрилансе.Время = деньги. Нервы = здоровье. А заказчиков так то пруд пруди. Кстатии , что то мне подсказывает что автор статьи как раз и будет таким заказчиком которых стоит обходить стороной) А кому то даже лучше будет устроится в хорошую компанию чтобы деньги за вашу работу не доставались таким вот заказчикам.
Чето все нагнетают постоянно. Айти уже не то, денег мало, вакансий мало.. Хз я всегда без проблем новую работу находил.Причем на разных стеках и ЯП даже. Вот пару месяцев назад на новую работу устроился. С пятого где то по счету собеса. Ничего особо то не поменялось и не сравнить с тем что 10- 15 лет назад было по ит зарплатам в РФ.
Большинству андроид разработчиков, полагаю. В разрезе общего числа разработчиков или даже компаний занимающихся разработкой это будет меньшинство. Но спорить не буду поскольку со статистикой тут сложно а у самого у меня не было опыта работы с kotlin multiplatform. Но если бы меня спросили выбрал бы я RN или флаттер то я бы выбрал однозначно флаттер поскольку большой опыт есть разработки и там и там
Ясно как, рыба гниёт с головы
Я тоже сначало немного расстроился, но сейчас больше склоняюсь к тому что последствия печальны не столько для флаттера сколько для гугла. Запрос на кроссплатформенный фреймворк у компаний и у разработчиков никуда не денется а на этом фоне флаттер одно из лучших если не лучшее решение. Найдут инвесторов. Кто знает может даже аппл возьмет под свое крыло. В своей статье он говорит что команда android всегда была довольно закрытая и я подозреваю что взаимодействие между командой flutter и командой android если и было то минимальное. Единственное, остается неясной судьба fuchsia, которая также подогревала интерес к флаттеру
Не думаю что от замены SizedBox на Padding код станет сильно чище и читабельнее. Как по мне в списках все же удобнее использовать SizedBox. Я использую SizedBox когда мне нужен только один отступ между двумя элементами с любой стороны, когда нужно больше использую Padding. Когда используется Padding надо еще подумать обернуть им виджет сверху для отступа снизу или виджет снизу для отступа сверху (тоже самое для отступов по горизонтале). Должно быть четкое понимание какому виджету нужен отступ иначе при рефакторинге вы рискуете потратить какое то время на поиск того виджета в который вы этот отступ добавили. Еще часто бывает что виджет переиспользуется. Он может быть изначально задуман таким а может таким оказаться впоследствии. И отступы для него могут быть разные на разных экранах. Если в коде виджета корневым элементом будет Padding, а кто то потом еще и условия добавит для различных отступов этого виджета на разных экранах, вместо того чтобы прописать отступы на самих экранах то это уже будет захламление кода. И вот эти вот вещи важнее как по мне. Правильная композиция и правильное применение отступов. Если мне на работе скажут использовать только Padding то это не будет для меня проблемой, однако в некоторых случаях SizedBox для меня предпочтительнее
Мне вот интересно сможет ли чат бот сгенерить вменяемый uikit для фронтенда. Про код понятно сам пользовался иногда для мини скриптов. А вот ui для каких то мини/пет проектов это было бы полезно. Понятно что для чего то более менее серьезного без дизайнера не обойтись
Ну во первых вы неправильно работаете с блоком. В офф доках описаны 2 способа взаимодействия их друг с другом. Внедряя их друг в друга через конструктор вы создаете тесное связывания которое пытаетесь решить через ивент бас. В результате вы получаете синглтон/god object, который будет глобальным. Это такой аналог редакса по сути. Смысл блока в том чтобы разбить логику на несвязанные между собой куски, мультисторы, на каждую фичу по блоку. Я бы и не писал бы если бы сам не пытался связать блоки через event bus когда только начинал карьеру во флаттере. Но пообщавшись с феликсом на гитхабе отбросил эту идею. Возможно концепция имеет место быть но для очень специфических задач.
После того как намучился с пакетами навигации (go router, routemaster, auto route), написал свой пакет. Пару недель на разработку зато все мои юз кейсы, которые неработали в других пакетах + стандартные кейсы работают как надо и покрыты тестами. Уж лучше так чем годами ковырятся с багами из за навигации кривой.