Разумеется. Мы же не фаллометрией тут занимаемся, а пытаемся выяснить, в каких случаях целесообразнее выбирать одну платформу, в каких другую 🙂 При том, что функционально они примерно равноценны. Вроде стало понятнее.
Мои рекомендации, разумеется, подойдут не для всех на свете компаний
Для нас точно не подойдут. Повторюсь, более 15 лет опыта – вполне достаточно, чтобы выработать оптимальные для всех условия. И для программистов, и для творцов-дизайнеров, и для маркетологов, и для поддержки. У меня сейчас средний стаж трудоустройства в компании более 10 лет. Согласитесь, эта цифра обо многом говорит. Да, потери были. Но буквально единицы, и из-за таких людей вводить режим тотального контроля мы не будем. Тем более, мониторинг компов ‐ это ИМХО вообще за гранью добра и зла. Работа сотрудников оценивается по результатам, точка.
Но и правда в том, что как только появляется необходимость чуть глубже интегрироваться с платформой, пуши в бэкграунде, камеры, специфичные UI-фичи, неизбежно лезешь в натив.
Нам всё это удавалось решать встроенными средствами – за исключением специфичного UI, который мы принципиально не используем, добиваясь идентичного UX на всех платформах.
Думаю, можем сойтись на том, что функционально оба подхода примерно равнозначны, и выбор в основном зависит от бэкграунда команды. Если речь о переходе от отдельных нативных приложений к кроссплатформе, то КМР, вероятно, вполне обоснованный выбор. У меня было иначе: получили в наследство RN приложение очень плохого качества, пытались привести его в чувство, но в конце концов оказалось проще переписать. С RN к тому времени нахлебались, кроссплатформа была нужна, КМР в тот момент был вообще сырым ещё – так что выбора особо и не было, взяли флаттер. Пока не пожалели.
В любом случае, спасибо за интересную дискуссию.
А про веб, вообще без споров. Мы тоже не рискуем на всю катушку его юзать в проде.
А какие проблемы в ним в КМР? Во флаттере в основном затык даже не в функционале, а в обработке нестандартных ситуаций. Типа у юзера сковырнулся графический энжин, и флаттер начинает сыпать ошибки при попытке рендера каждого фрейма. И всё это сыплется нам в логи. Даже если таких юзеров за день пара штук, всё равно неприятно.
На данный момент у флаттера единственная реальная проблема – недостаточно стабильная реализация для веба. Как правило, всё хорошо, но при существующем зоопарке платформ и браузеров изредка баги таки вылезают. А при аудитории 30М+ пользователей мне пока просто стрёмно раскатывать реализацию на всех, в логах утонем. Так что пока допиливаем на ограниченном множестве, постим им баги и ждём факсов. А натив работает отлично и сейчас.
Со стороны работодателя заранее сложно понять, подойдёт ли работнику удалённый формат именно в вашей компании.
А это не работодатель должен понимать, а сам работник. При найме все условия оглашаются, если человек видит, что скажем, не в состоянии организовать себе рабочее место, то он просто отказывается. А если потом выясняется, что он не в состоянии сконцентрироваться на работе без начальника за спиной – то тут уж работодатель не виноват и ничего сделать не может, кроме как уволить.
Мы не отказываемся решать объективные проблемы: например, нам пришлось открыть компанию в Сербии – а это дело весьма затратное, как по времени, так и по деньгам. Просто потому, что там законодательство изменилось, и прежние варианты перестали работать. А у нас там около 250 сотрудников, терять которых мы, разумеется, не хотели. Но вот предоставлять каждому из сотен сотрудников индивидуальные условия с учётом его конкретных бытовых обстоятельств компания просто не в состоянии, это превратится в неуправляемый хаос.
CallKit, Live Activities или App Clips, без нативного кода это не решить
Первые два вопроса у нас были решены во флаттере без проблем, третий в процессе, скоро будет. Из натива понадобился один файл на Swift, буквально пару десятков срок, как часть того же флаттер проекта – без него не получалось надёжно принимать пуши, если приложение в бэкграунде или выгружено.
Ну и типичная ситуация, доступ к новым возможностям ОС сразу после их релиза.
Вообще-то это противоречит идее кроссплатформы – которая подразумевает, что приложение делает ровно то же самое везде. Соответственно, если в одной ОС появилась фича, которой нет в других – это не про нас. Да и вообще ИМХО не стоит так уж суетиться.
платформенные штуки спокойно реализуешь на Swift или Kotlin, как привык
То есть опять команда универсальных солдат.
при этом кодовая база остается максимально общей.
Существенно менее общей, чем с флаттером всё же – где она просто единая.
Можете привести пример функционала, который невозможно реализовать встроенными средствами того же флаттера, обязательно требующего использования нативных API?
и позволяет работать с уже привычными фреймворками и API
Так в том-то и дело, что нужна команда, обладающая знаниями как КМР, так и каждой из целевых платформ.
Flutter или React Native, это тоже отличные решения, но они немного более ограничены в плане интеграции с нативными платформами.
Вот-вот, именно об этом поподробнее, пожалуйста. В каком конкретно месте обнаружились критичные ограничения? Не придираюсь, реально интересно.
Платформенный код (UI, доступ к железу) реализуется отдельно для каждой системы с использованием её родных технологий. Это устраняет необходимость изучать несколько UI-фреймворков и позволяет использовать уже знакомые инструменты, такие как Swift для iOS или Jetpack Compose для Android.
Ээээ, наоборот. КМР требует знания как себя самого, так и нативных инструментов – ну или чего-то типа JetPack Compose. В то время как флаттер или (не к ночи будь помянут) реакт самодостаточны.
однако руководителям компаний стоит разбираться в деталях, а именно — выявлять подобные подгруппы и создавать для них индивидуальные условия
Наоборот. Те, кому удалёнка не подходит, должны искать себе другую работу. Из моей практики: большинство программистов справляется, отсев процентов 5-10 от силы.
Люди пользуются удалёнкой, чтобы делать свой график гибким и успевать больше, однако цена такого подхода: блокировки в коммуникациях.
Неверно. Удалёнка – это о не "хочу – работаю, не хочу – не работаю". График должен быть или вообще фиксированным, или как минимум, известным и понятным. У нас, например, есть две смены с фиксированными часами работы, в значительной степени перекрывающимися. Это даёт два преимущества:
Каждому известно, когда он может связаться с коллегами, максимальная задержка – несколько часов, да и это редко.
Вносит определённость в жизнь сотрудников: они точно знают, какие часы у них рабочие, а какие отданы личной жизни, и никто их в это время дёргать не будет.
А так произвольный график посещения можно и в офисе ввести – и начнётся ровно такой же бардак с коммуникацией.
Сам занимаюсь организацией удалённой работы более 15 лет, и могу заверить, что при правильно выстроенных процессах производительность не страдает, а удовлетворённость сотрудников повышается.
За короткое время уже вторая переводная статья того же автора, полная лютой ахинеи в адрес эджайла. Что бы это значило? Других тем нет? У автора неудачный опыт с эжайлом, психологическая травма, требующая компенсации таким вот способом?
Качество перевода, должен сказать, очень хорошее. Качество исходных материалов – ниже плинтуса. Этот – вообще набор абсолютно голословных выкриков, без малейших попыток чем-то подтвердить написанное.
Что интересно, у Егора Бугаенко был доклад на тему, где он как раз топил за отказ от репозиториев и продвигал идею класса User, который сам себя может сохранить в базу.
Реакция зала и комментарии на ютубе были ожидаемые. Мало кто поддержал такой подход
Простите, а почему бы не быть такому классу? SOLIDным ребятам это западло? Вполне нормальное решение во многих случаях – пожалуй, даже и в большинстве. Зачем заранее закладываться на то, что может быть, когда-то, в далёком будущем я захочу поменять движок базы, тратить на это время и ресурсы? Это бывает нужно почти никогда. А другой причины вводить дополнительный слой абстракций нет. Сначала сами нагородят ненужный огород, а потом начинают жаловаться, что ООП не торт. Или вообще скам.
Привели. Совершенно не понимая, что в них написано. Вот это, в частности:
Инкапсуляция - это сокрытие внутреннего состояния и функций объекта и предоставление доступа только через открытый набор функций
Каким боком вообще к этому определению относится static, extern? Что с их помощью можно скрыть? Всё тут правильно написано, и ничуть не противоречит следующим двум определениям – которые расширяют, а не заменяют первое.
Особо доставляет, что Вы спорите с определениями, относящимися к ООП в контексте синтаксиса С – который вообще-то всегда был процедурным языком и к ООП относится примерно никак.
в Калифорнии, очевидно, у них своя атмосфера по этой теме
Я не понимаю, зачем переписывать очевидную ахинею. Независимо от локации, ни в одной методике эджайл невозможно найти ничего, способствующего дискриминации или сексуальным домогательствам. Вот вообще ничего. Если автор находит – это признак психического расстройства и явная причина для того, чтобы статьи такого автора не перепубликовывать.
Но если вы взглянете на список методологий, связанных с Agile, у вас могут зазвенеть тревожные звоночки — особенно если вы когда-либо сталкивались с дискриминацией или домогательствами на рабочем месте.
Видел много критики эджайла, но вот о том, что он поощряет домогательства на рабочем месте, пока читать не приходилось 🤔
Можно ли сказать, что в C реализована инкапсуляция через ключевые слова static и external? Ну вроде да.
Довольно прикольно читать статью о вредности ООП от человека, настолько не понимающего его основы. Наоборот: инкапсуляция – это private, protected. И не в С – в нём к инкапсуляции можно отнести разве что локальную видимость переменных.
Впервые вижу понятное объяснение, зачем нужны стори пойнты: чтобы дурак-руководитель, который оценивает работу команды, деля ФОТ на количество закрытых задач, независимо от их сложности, отвязался, в конце концов.
Метод который используется как условие тернарного оператора не перестаёт быть методом.
Разумеется, и что? А разве тернарный оператор перестаёт быть условным, если у него в условии метод? Напомню, название статьи: Программирование без условных операторов.
Видите ли, у меня был опыт такого рода. Как-то получил проект, в котором не было:
Общего репо, код хранился на компах разработчиков, свои изменения каждый из примерно полутора десятков высылал по мэйлу руководителю, который их локально же объединял.
Никакого таск трекера, задачи ставились по мэйлу или в чате.
Тестирования как такового, каждый проверял свои изменения сам.
Промежуточных стадий, код заливался сразу на прод по FTP.
Графика релизов – они делались 2-3 раза в год, без чётких критериев готовности.
Такой вот воплощённый кошмар – и тем не менее, чтобы привести всё это в относительный порядок, понадобилось меньше месяца. Потом ещё около года, чтобы переписать весь этот говнокод (а в таких условиях иным он быть не мог). Чем можно было заниматься аж 4 года, оптимизируя работу шести разработчиков – для меня загадка. За такой срок можно и впрямь немаленькую часть Москвы построить.
Разумеется. Мы же не фаллометрией тут занимаемся, а пытаемся выяснить, в каких случаях целесообразнее выбирать одну платформу, в каких другую 🙂 При том, что функционально они примерно равноценны. Вроде стало понятнее.
Для нас точно не подойдут. Повторюсь, более 15 лет опыта – вполне достаточно, чтобы выработать оптимальные для всех условия. И для программистов, и для творцов-дизайнеров, и для маркетологов, и для поддержки. У меня сейчас средний стаж трудоустройства в компании более 10 лет. Согласитесь, эта цифра обо многом говорит. Да, потери были. Но буквально единицы, и из-за таких людей вводить режим тотального контроля мы не будем. Тем более, мониторинг компов ‐ это ИМХО вообще за гранью добра и зла. Работа сотрудников оценивается по результатам, точка.
Нам всё это удавалось решать встроенными средствами – за исключением специфичного UI, который мы принципиально не используем, добиваясь идентичного UX на всех платформах.
Думаю, можем сойтись на том, что функционально оба подхода примерно равнозначны, и выбор в основном зависит от бэкграунда команды. Если речь о переходе от отдельных нативных приложений к кроссплатформе, то КМР, вероятно, вполне обоснованный выбор. У меня было иначе: получили в наследство RN приложение очень плохого качества, пытались привести его в чувство, но в конце концов оказалось проще переписать. С RN к тому времени нахлебались, кроссплатформа была нужна, КМР в тот момент был вообще сырым ещё – так что выбора особо и не было, взяли флаттер. Пока не пожалели.
В любом случае, спасибо за интересную дискуссию.
А какие проблемы в ним в КМР? Во флаттере в основном затык даже не в функционале, а в обработке нестандартных ситуаций. Типа у юзера сковырнулся графический энжин, и флаттер начинает сыпать ошибки при попытке рендера каждого фрейма. И всё это сыплется нам в логи. Даже если таких юзеров за день пара штук, всё равно неприятно.
Пробовали, или "Рабинович напел ©"? 😁 Вот честно, не нужны никакие танцы. Всё реализуется вполне естественным путём.
На данный момент у флаттера единственная реальная проблема – недостаточно стабильная реализация для веба. Как правило, всё хорошо, но при существующем зоопарке платформ и браузеров изредка баги таки вылезают. А при аудитории 30М+ пользователей мне пока просто стрёмно раскатывать реализацию на всех, в логах утонем. Так что пока допиливаем на ограниченном множестве, постим им баги и ждём факсов. А натив работает отлично и сейчас.
А это не работодатель должен понимать, а сам работник. При найме все условия оглашаются, если человек видит, что скажем, не в состоянии организовать себе рабочее место, то он просто отказывается. А если потом выясняется, что он не в состоянии сконцентрироваться на работе без начальника за спиной – то тут уж работодатель не виноват и ничего сделать не может, кроме как уволить.
Мы не отказываемся решать объективные проблемы: например, нам пришлось открыть компанию в Сербии – а это дело весьма затратное, как по времени, так и по деньгам. Просто потому, что там законодательство изменилось, и прежние варианты перестали работать. А у нас там около 250 сотрудников, терять которых мы, разумеется, не хотели. Но вот предоставлять каждому из сотен сотрудников индивидуальные условия с учётом его конкретных бытовых обстоятельств компания просто не в состоянии, это превратится в неуправляемый хаос.
Первые два вопроса у нас были решены во флаттере без проблем, третий в процессе, скоро будет. Из натива понадобился один файл на Swift, буквально пару десятков срок, как часть того же флаттер проекта – без него не получалось надёжно принимать пуши, если приложение в бэкграунде или выгружено.
С Bluetooth не работали, но библиотек полно.
Вообще-то это противоречит идее кроссплатформы – которая подразумевает, что приложение делает ровно то же самое везде. Соответственно, если в одной ОС появилась фича, которой нет в других – это не про нас. Да и вообще ИМХО не стоит так уж суетиться.
То есть опять команда универсальных солдат.
Существенно менее общей, чем с флаттером всё же – где она просто единая.
Можете привести пример функционала, который невозможно реализовать встроенными средствами того же флаттера, обязательно требующего использования нативных API?
Так в том-то и дело, что нужна команда, обладающая знаниями как КМР, так и каждой из целевых платформ.
Вот-вот, именно об этом поподробнее, пожалуйста. В каком конкретно месте обнаружились критичные ограничения? Не придираюсь, реально интересно.
Ээээ, наоборот. КМР требует знания как себя самого, так и нативных инструментов – ну или чего-то типа JetPack Compose. В то время как флаттер или (не к ночи будь помянут) реакт самодостаточны.
Наоборот. Те, кому удалёнка не подходит, должны искать себе другую работу. Из моей практики: большинство программистов справляется, отсев процентов 5-10 от силы.
Неверно. Удалёнка – это о не "хочу – работаю, не хочу – не работаю". График должен быть или вообще фиксированным, или как минимум, известным и понятным. У нас, например, есть две смены с фиксированными часами работы, в значительной степени перекрывающимися. Это даёт два преимущества:
Каждому известно, когда он может связаться с коллегами, максимальная задержка – несколько часов, да и это редко.
Вносит определённость в жизнь сотрудников: они точно знают, какие часы у них рабочие, а какие отданы личной жизни, и никто их в это время дёргать не будет.
А так произвольный график посещения можно и в офисе ввести – и начнётся ровно такой же бардак с коммуникацией.
Сам занимаюсь организацией удалённой работы более 15 лет, и могу заверить, что при правильно выстроенных процессах производительность не страдает, а удовлетворённость сотрудников повышается.
За короткое время уже вторая переводная статья того же автора, полная лютой ахинеи в адрес эджайла. Что бы это значило? Других тем нет? У автора неудачный опыт с эжайлом, психологическая травма, требующая компенсации таким вот способом?
Качество перевода, должен сказать, очень хорошее. Качество исходных материалов – ниже плинтуса. Этот – вообще набор абсолютно голословных выкриков, без малейших попыток чем-то подтвердить написанное.
Простите, а почему бы не быть такому классу? SOLIDным ребятам это западло? Вполне нормальное решение во многих случаях – пожалуй, даже и в большинстве. Зачем заранее закладываться на то, что может быть, когда-то, в далёком будущем я захочу поменять движок базы, тратить на это время и ресурсы? Это бывает нужно почти никогда. А другой причины вводить дополнительный слой абстракций нет. Сначала сами нагородят ненужный огород, а потом начинают жаловаться, что ООП не торт. Или вообще скам.
Привели. Совершенно не понимая, что в них написано. Вот это, в частности:
Каким боком вообще к этому определению относится
static,extern? Что с их помощью можно скрыть? Всё тут правильно написано, и ничуть не противоречит следующим двум определениям – которые расширяют, а не заменяют первое.Особо доставляет, что Вы спорите с определениями, относящимися к ООП в контексте синтаксиса С – который вообще-то всегда был процедурным языком и к ООП относится примерно никак.
Я не понимаю, зачем переписывать очевидную ахинею. Независимо от локации, ни в одной методике эджайл невозможно найти ничего, способствующего дискриминации или сексуальным домогательствам. Вот вообще ничего. Если автор находит – это признак психического расстройства и явная причина для того, чтобы статьи такого автора не перепубликовывать.
Видел много критики эджайла, но вот о том, что он поощряет домогательства на рабочем месте, пока читать не приходилось 🤔
Довольно прикольно читать статью о вредности ООП от человека, настолько не понимающего его основы. Наоборот: инкапсуляция – это
private,protected. И не в С – в нём к инкапсуляции можно отнести разве что локальную видимость переменных.Впервые вижу понятное объяснение, зачем нужны стори пойнты: чтобы дурак-руководитель, который оценивает работу команды, деля ФОТ на количество закрытых задач, независимо от их сложности, отвязался, в конце концов.
Разумеется, и что? А разве тернарный оператор перестаёт быть условным, если у него в условии метод? Напомню, название статьи: Программирование без условных операторов.
Видите ли, у меня был опыт такого рода. Как-то получил проект, в котором не было:
Общего репо, код хранился на компах разработчиков, свои изменения каждый из примерно полутора десятков высылал по мэйлу руководителю, который их локально же объединял.
Никакого таск трекера, задачи ставились по мэйлу или в чате.
Тестирования как такового, каждый проверял свои изменения сам.
Промежуточных стадий, код заливался сразу на прод по FTP.
Графика релизов – они делались 2-3 раза в год, без чётких критериев готовности.
Такой вот воплощённый кошмар – и тем не менее, чтобы привести всё это в относительный порядок, понадобилось меньше месяца. Потом ещё около года, чтобы переписать весь этот говнокод (а в таких условиях иным он быть не мог). Чем можно было заниматься аж 4 года, оптимизируя работу шести разработчиков – для меня загадка. За такой срок можно и впрямь немаленькую часть Москвы построить.
И всё это время исправно платили зарплату? Чтоб я так жил.
Верно, но этот пример очень уж language-specific. В том же Котлине достаточно было бы написать
?., чтобы получить тот же результат.