Флаттер не нужно сравнивать с КМР. КМР по сути есть мультиплатформенный компилятор и не более, тут уместнее параллели с Дарт. Если же говорить о фреймворках, то это Flutter vs Jetpack Compose. Первый универсальный, общего назначения, второй чисто гуёвый. Да, Котлин как язык мощнее Дарт. Но вот связка Dart+Flutter на данный момент выглядит предпочтительнее, чем Kotlin+Jetpack – по уровню зрелости, универсальности и количеству поддерживаемых платформ. Возможно, со временем это изменится – но сейчас так.
Ещё немаловажный момент: на флаттере можно писать, не имея глубокого знания целевых платформ. С КМР/Jetpack так не получится, они используют нативные компоненты, которые нужно уметь правильно готовить.
Предлагаю другой концепт: ребёночек рождается с голым "колёсным диском", а мама по мере роста (слюнями?) наносит на него слои "протектора". Когда вырастает, начинает возобновлять сам. Заодно может амортизация получиться, если субстанция упругая.
Ну допустим, колесо совсем не обязательно должно иметь сосуды и мышцы. В самом примитивном варианте это может быть этакая "тачка": костное образование на оси. А разгоняться за счёт отталкивания лапами, и заодно какую-нибудь жидкость выделять для смазки. Ну и более сложные варианты по тому же принципу тоже возможны. Другой разговор, зачем: в дикой природе практически нет протяжённых, идеально ровных поверхностей, где такой конструкт давал бы хоть какое-то преимущество.
Вроде бы с 2026 всё станет уже не так кошерно, Вам стоит уточнить у юристов. Были изменения в законодательстве, касающиеся как раз нерезидентов, помимо всего перечисленного нужно будет получать ещё и разрешение на работу. Причём оно выдаётся на ограниченный срок, надо будет регулярно возобновлять. Я у своих юристов спрашивал – тогда они сами ещё толком не понимали, как это будет работать. А потом мне стало неинтересно, получил ВНЖ с правом работы на 10 лет. Так что подсказать не смогу. Но разница будет точно, не упустите этот момент.
репозиторий React'а — это лабиринт, и для навигации там нужен путеводитель
К реакту отношусь, мягко говоря, так себе – по совершенно другим причинам, чтобы рассказать, понадобилась бы отдельная статья. Но вот заглянув как-то в его репо, был приятно удивлён, в кои-то веки увидев хорошо структурированный код. Сейчас у меня две основные технологии: РНР и флаттер. И там, и там файл в 5000 строк лапши – обыденность. Это лучше? Не понимаю, как они в этом разбираются, и как можно туда что-то законтрибутить свежему человеку. Какое-то безумие: предполагается, что цель разработчиков и РНР, и флаттера – помогать программистам писать хорошо структурированный код, но при этом сами они этого делать не умеют.
$400 в час? А сами при этом платят $2,500 в месяц? Позволю себе усомниться. В первую очередь в том, что кто-то готов столько платить – зная, что можно нанять весьма квалифицированных людей в штат за буквально на порядок меньшую сумму. Знаете, те, кто в принципе располагает такими деньгами, обычно далеко не идиоты, и считать их умеют.
Программисты получают 2,8 млн. в год и разработка всё равно дорожает. Как это остановить
Это, грубо, $2,500 в месяц. Слишком много для квалифицированного программиста, пора останавливать? Ну-ну.
Вот факт: за 10 лет средняя зарплата разработчика в России выросла с миллиона до 2,8 миллиона рублей в год. Стоимость часа работы — с $30-50 до $80-100, у крупных агентств доходит до $300-400.
Тут у меня арифметика совсем уж не бьётся. По нижней границе вилки $30 – это $4,800 в месяц. А по верхней $400 – аж $64,000. Где деньги, Зин?
И до какого времени? Практическую разработку я имею в виду. Не думаю, что СТО РНР команды мог успевать параллельно поддерживать экспертный уровень джава-разработчика. Соответственно, и менторить переход на современные джава решения.
На самом деле примеров на рынке много, когда команды полностью переписывали свое решение на другой технологии.
Несомненно, сам таким занимаюсь, прямо сейчас в том числе. Сомнения вызывают мотивация и организация процесса.
Скажите, вот Вы пишете, что менторили РНР разрабов в процессе перехода на джаву. А можно узнать, каков Ваш собственный опыт с ней? Почитали доки, решили, что нет ничего сложного, и тут же начали учить других?
Честно говоря, после прочтения обеих статей складывается впечатление, что вы не сумели разобраться, как готовить РНР, и решили заменить плиту, а не повара. Вероятно, примерно с тем же успехом – просто пока джава код ещё молодой, не успел обрасти костылями, и поэтому пока его обслуживать проще. Представить, что команда, не имеющая никакого представления о джаве, смогла качественно переписать на ней проект энтерпрайс уровня, продолжая при этом обслуживать, и даже развивать прежнюю реализацию на РНР, мне довольно сложно. Равно как и представить себе бизнес, готовый зависнуть на полтора года – просто потому, что разработчикам взбрело в голову поменять технологический стек.
Я руковожу эджайл проектами в разных организациях лет уже так 25. И пока никому не приходило в голову, что я тут лишний. Практика, ага.
можете ли вы привести какую-либо Agile-based методологию, где роль РП описана в явном виде?
Зачем повторно описывать то, что уже описано множество раз? В любом проекте должен быть человек, который:
Принимает ответственные решения;
Несёт ответственность за результаты.
Если такого человека нет, проект очень быстро превратится в бардак. Например: кто в отсутствие явного руководителя принимает решения о приёме на работу и увольнении, о распределении ФОТ, о приобретении оборудования? Команда на дэйлике? Камон.
Был, мягко говоря, не совсем очевидный способ неплохо зарабатывать на рацухах – сам неоднократно пользовался, порой можно было сотни три за раз сшибить. Важно было задекларировать, что рацпредложение не имеет экономического эффекта. С эффектом всё было как-то сложно: нужно было внедрить, потом через какое-то время типа года посчитать тот самый эффект, и если рацуха мелкая, то и оплата получалась такой же, да ещё и далеко не сразу. А без эффекта считалось от базовой ставки, к которой потом применялись различные коэффициенты – при правильном подборе которых сотни полторы были практически минимумом, и деньги выплачивались сразу. А поскольку начальство было заинтересовано в хорошей статистике по изобретательству и рационализации, то проходило всё это на ура, и получалась недурная прибавка к инженерской зарплате.
You have to у нас не особо используется, это ж почти грубо 😊 На что-то вроде we need to do..., would you do... В довольно разных контекстах. У меня американцы, не знаю – может, англичане чуть по-другому говорят.
Да ладно 😁
Флаттер не нужно сравнивать с КМР. КМР по сути есть мультиплатформенный компилятор и не более, тут уместнее параллели с Дарт. Если же говорить о фреймворках, то это Flutter vs Jetpack Compose. Первый универсальный, общего назначения, второй чисто гуёвый. Да, Котлин как язык мощнее Дарт. Но вот связка Dart+Flutter на данный момент выглядит предпочтительнее, чем Kotlin+Jetpack – по уровню зрелости, универсальности и количеству поддерживаемых платформ. Возможно, со временем это изменится – но сейчас так.
Ещё немаловажный момент: на флаттере можно писать, не имея глубокого знания целевых платформ. С КМР/Jetpack так не получится, они используют нативные компоненты, которые нужно уметь правильно готовить.
Вы хотели сказать: следите за руками? 😁
Предлагаю другой концепт: ребёночек рождается с голым "колёсным диском", а мама по мере роста (слюнями?) наносит на него слои "протектора". Когда вырастает, начинает возобновлять сам. Заодно может амортизация получиться, если субстанция упругая.
Ну допустим, колесо совсем не обязательно должно иметь сосуды и мышцы. В самом примитивном варианте это может быть этакая "тачка": костное образование на оси. А разгоняться за счёт отталкивания лапами, и заодно какую-нибудь жидкость выделять для смазки. Ну и более сложные варианты по тому же принципу тоже возможны. Другой разговор, зачем: в дикой природе практически нет протяжённых, идеально ровных поверхностей, где такой конструкт давал бы хоть какое-то преимущество.
Отличный обзор, спасибо!
Вроде бы с 2026 всё станет уже не так кошерно, Вам стоит уточнить у юристов. Были изменения в законодательстве, касающиеся как раз нерезидентов, помимо всего перечисленного нужно будет получать ещё и разрешение на работу. Причём оно выдаётся на ограниченный срок, надо будет регулярно возобновлять. Я у своих юристов спрашивал – тогда они сами ещё толком не понимали, как это будет работать. А потом мне стало неинтересно, получил ВНЖ с правом работы на 10 лет. Так что подсказать не смогу. Но разница будет точно, не упустите этот момент.
К реакту отношусь, мягко говоря, так себе – по совершенно другим причинам, чтобы рассказать, понадобилась бы отдельная статья. Но вот заглянув как-то в его репо, был приятно удивлён, в кои-то веки увидев хорошо структурированный код. Сейчас у меня две основные технологии: РНР и флаттер. И там, и там файл в 5000 строк лапши – обыденность. Это лучше? Не понимаю, как они в этом разбираются, и как можно туда что-то законтрибутить свежему человеку. Какое-то безумие: предполагается, что цель разработчиков и РНР, и флаттера – помогать программистам писать хорошо структурированный код, но при этом сами они этого делать не умеют.
$400 в час? А сами при этом платят $2,500 в месяц? Позволю себе усомниться. В первую очередь в том, что кто-то готов столько платить – зная, что можно нанять весьма квалифицированных людей в штат за буквально на порядок меньшую сумму. Знаете, те, кто в принципе располагает такими деньгами, обычно далеко не идиоты, и считать их умеют.
Это, грубо, $2,500 в месяц. Слишком много для квалифицированного программиста, пора останавливать? Ну-ну.
Тут у меня арифметика совсем уж не бьётся. По нижней границе вилки $30 – это $4,800 в месяц. А по верхней $400 – аж $64,000. Где деньги, Зин?
И до какого времени? Практическую разработку я имею в виду. Не думаю, что СТО РНР команды мог успевать параллельно поддерживать экспертный уровень джава-разработчика. Соответственно, и менторить переход на современные джава решения.
Несомненно, сам таким занимаюсь, прямо сейчас в том числе. Сомнения вызывают мотивация и организация процесса.
Скажите, вот Вы пишете, что менторили РНР разрабов в процессе перехода на джаву. А можно узнать, каков Ваш собственный опыт с ней? Почитали доки, решили, что нет ничего сложного, и тут же начали учить других?
Честно говоря, после прочтения обеих статей складывается впечатление, что вы не сумели разобраться, как готовить РНР, и решили заменить плиту, а не повара. Вероятно, примерно с тем же успехом – просто пока джава код ещё молодой, не успел обрасти костылями, и поэтому пока его обслуживать проще. Представить, что команда, не имеющая никакого представления о джаве, смогла качественно переписать на ней проект энтерпрайс уровня, продолжая при этом обслуживать, и даже развивать прежнюю реализацию на РНР, мне довольно сложно. Равно как и представить себе бизнес, готовый зависнуть на полтора года – просто потому, что разработчикам взбрело в голову поменять технологический стек.
Краткое содержание статьи:
Когда наступит iOS 26, флаттер превратится в тыкву. Чему компания Clever Pumpkin рада.
Я руковожу эджайл проектами в разных организациях лет уже так 25. И пока никому не приходило в голову, что я тут лишний. Практика, ага.
Зачем повторно описывать то, что уже описано множество раз? В любом проекте должен быть человек, который:
Принимает ответственные решения;
Несёт ответственность за результаты.
Если такого человека нет, проект очень быстро превратится в бардак. Например: кто в отсутствие явного руководителя принимает решения о приёме на работу и увольнении, о распределении ФОТ, о приобретении оборудования? Команда на дэйлике? Камон.
Простите, а где Вы вообще почерпнули идею, что эджайл отрицает наличие руководителя проекта? 🤔
Был, мягко говоря, не совсем очевидный способ неплохо зарабатывать на рацухах – сам неоднократно пользовался, порой можно было сотни три за раз сшибить. Важно было задекларировать, что рацпредложение не имеет экономического эффекта. С эффектом всё было как-то сложно: нужно было внедрить, потом через какое-то время типа года посчитать тот самый эффект, и если рацуха мелкая, то и оплата получалась такой же, да ещё и далеко не сразу. А без эффекта считалось от базовой ставки, к которой потом применялись различные коэффициенты – при правильном подборе которых сотни полторы были практически минимумом, и деньги выплачивались сразу. А поскольку начальство было заинтересовано в хорошей статистике по изобретательству и рационализации, то проходило всё это на ура, и получалась недурная прибавка к инженерской зарплате.
Или [pretty] darn.
Наверное, все-таки the wheel. Если колесо неконкретное, на вопрос ответить невозможно 😁
You have to у нас не особо используется, это ж почти грубо 😊 На что-то вроде we need to do..., would you do... В довольно разных контекстах. У меня американцы, не знаю – может, англичане чуть по-другому говорят.