Я бы голосовал «скорее Да, чем Нет». Не спорю, нужен свободный магазин приложений. Свободный от корпоративной политики и прочего. Однако, цензура тоже нужна. Потому как этой свободой могут воспользоваться и не совсем честные категории граждан. Сейчас, по всей видимости, блокировка в «магазинах» происходит автоматически или по решению Искусственного Условно-Интеллекта. Человек должен принимать в этом участие. И, по хорошему, блокировать (или предупреждать на первый раз) того, кто дал ложный сигнал для блокировки.
Самым лучшим решением, на мой взгляд, будет магазин приложений, где можно будет скачать приложения для разных платформ. Но создать и обслуживать такую платформу под силу только большим корпорациям. С решениями Google и Apple уже были недовольства, поэтому то, что будут предлагать они, может быть воспринято с определённой долей недоверия. Остаются Microsoft и Amazon. Если кто-то из них решится создать такое, то, несомненно, получит неплохой доход.
То, как поступила Adobe, немного некрасиво — ни себе, ни людям. Ну, не смогли они поправить все ошибки безопасности, так откройте код.
Либо, причина тут была изначально в другом. Возможно, просто был план отказаться от подобных технологий и реализовать всё через браузер. Хотя, сомневаюсь, что смогут реализовать все фишки и это точно будет нескоро.
«На вкус и цвет все флормастеры разные». По мне статья достойная — указаны все комплектующие, приведён код и способ сборки. Это, скорее, просто демонстрация или пример старта, если кто захочет попробовать сделать такое сам. Обычно, авторы ограничиваются только перечислением комплектующих, а здесь всё подробно расписано.
Никто не требует, чтобы элементы или внешний вид были такими. Автор использовал то, что было под рукой. Хотите, красиво — делайте.
В Vivaldi есть свой механизм синхронизации. Там незачем гугловый вариант. И я, даже, не пробовал там авторировываться а гугловую учётку.
На счёт цифровой подписи согласен и хотелось бы дополнить, что отследить по ней могут не только в Chromium-based браузерах. Нас уже давно продают и покупают все кому не лень.
А это хороший вопрос. Сперва все возмущаются, что их данные сливаются в Google через Chromium. Теперь возмущаются тем, что возможность слива (я думаю, что это только одна из и самое «сладкое» никто выпиливать не будет) перекрывается и опять возмущения. Создаётся ощущение, что людям просто нравится возмущаться, а причина уже не так важна.
Я, например, за. Пусть оставят только браузер в Chromium, а все свои плюшки реализуют в Google Chrome.
А заливать архив и распаковывать на сервере не проще? Всё равно, после заливки выполняются дополнительные действия, вызываемые на сервере. Ну, как минимум, перезапуск приложения. Можно добавить и разархивирование. 7z, xz сжимают неплохо. Как уже писали, с upx будут накладные расходы по памяти.
В Go, мне, как раз, нравится то, что приложение собирается статически и можно не беспокоиться о том, что на какой-то машине не заработает. Конечно, не 100%, но спокойнее.
А что касается размера, то `-ldflags="-s -w"` достаточно (с учётом, что изначально приложение весит 30M+, а с этой опцией ужимает до 10M-15M). Ну, или просто убрать debug информацию с помощью команды `strip -s APPLICATION`.
По upx: да, хорошая программа, знаю давно, но пару раз на Go программах (когда язык только начал распространяться), результирующее приложение вылетало при старте. Возможно, потом это починили, т.к. в последнее время с таким не сталкивался. Но для production, всё равно, его не использую — достаточно удаления debug информации.
P.S. Спасибо за информацию о Sentry. Нужно как-нибудь поизучать его. Всегда полезно быть в курсе работы приложения.
Я тоже из тех, кто не очень доверяет SSD дискам. Возможно, из-за печального первого опыта, когда диск просто перестал работать и, при том, ещё и тормозил загрузку компа, перед тем как сообщить об ошибке. Поправьте меня, если я не прав, но SSD диск выходит их строя весь и сразу, в отличие от HDD, с которого можно успеть спасти, хотя бы, часть данных (что делал уже не раз). Не отрицаю, первый SSD был из дешёвой линейки и это могло сказаться на качестве, либо был брак, который показал себя не сразу.
Но, отказываться от SSD я не стал и использую его только для системы — не для данных. Никаких оптимизаций не делал, кэши не отключал, драйвера поддерживаю в актуальном состоянии, установлены две ОС.
Периодически делаю полный бекап диска. На мой взгляд, это оптимальный вариант работы.
Это, видимо, я отстал от жизни, если для разработки требуется такое железо. Ну, и ноут для работы, лично для меня неудобно: один маленький монитор, урезанная клавиатура. Но, у каждого свои требования, понимаю.
Одно время, я работал над проектом на nodejs. Сборка была автоматизирована и проблем с этим не было, но запуск и работа была, скажем так, небыстрой.
Полностью согласен с автором, что существующие средства разработки очень медленные. И жадные до памяти.
P.S. долго думал над «вскод». Сперва показалось, что ошибка/опечатка. Когда дошёл до «жскод», стало понятно. VSCode/Atom/Electron жрут немало ресурсов. С теплотой вспоминаю VS6.
В том то и дело, все полагаются на облачные технологии, на их надёжность и забывают, что они, по сути, просто большое количество серверов, которые тоже могу ломаться.
Я, например, один из рабочих продуктов, разметил в Gilab, Github, Bitbucket и локальном репозитории. Это даёт мне возможность работать с продуктом из разных мест. Я просто читаю все репозитории и пишу тоже во все. Если один из ресурсов недоступен, то на него изменения прилетят в следующий раз. Во всех местах хранятся все ветки и все коммиты. В любой момент можно залить на очередной репозиторий и в нём окажется все, что есть в остальных.
На счёт бинарных данных, хорошо заметили. В проекте они тоже есть, но обновляются крайне редко. Хотя, урок для себя из статьи я вынес по данному моменту.
Как человек, живущий неблизко от моря/океана скажу, что у меня бутылка вообще не ассоциируется с сообщением. Но и для нынешней молодёжи, привычная нам иконка сохранения (дискета 3,5"), может, и понятна, но что там нарисовано не все знают.
Не исключено, что через десяток/другой все привычные нам значки будут заменены.
Карту памяти держать под фото/видео только. А вообще, нормальную карту с нормальной скоростью ещё найти нужно. Не все подходят. Просто, если карта памяти, используемая как дополнение к внутренней памяти полетит, то потерь будет больше. А, если только фото/видео, которые периодически синхронизируются с «хранилищем» или просто бекапируются, то это не так страшно.
просто фоток и видео уже около 50 тыс объемом около 500 гб
500G фоток на телефоне? Что же это за телефон такой? Даже флешки с таким объёмом не так распространены. Я уже не говорю про встроенную память. Хотя, если это что-то из топовых iPhone, то ещё может быть.
А с MTP полностью согласен. Он не только выдаёт ошибки, но и тормозит жутко. Конечно, может хотели что-то защитить аппарат и пр., но решение так себе. Телефон, определяемый как флешка было самое то.
В Project Ara я не верил с самого начала. И причина не в том, что сложно или ещё что-то, а в том, что этим занимался Google. Они уже и так немало начинаний похоронили. Про Google очки, кстати, тоже не особо слышно. Может они есть ещё и развиваются, я не в курсе. У них есть Pixel. Зачем делать что-то, что будет дешевле? Либо сделали бы так, что качественных модулей не было бы: процессор нетоповый, памяти не более 4G (например), низкое разрешение экрана и пр. Хотите качественное — покупайте наши флагманский смартфоны.
Если грамотно спроектировать, то на размерах конечного продукта это не особо отразилось бы.
Про Blocks слышал. Идея была хорошая, но не сложилось.
Когда только начинал разбирать с этими уведомлениями, был неприятно удивлён, что нет API для них. Хотя, казалось бы, всё стандартизовано. Возможно, всё упирается в требование сервера, но можно было бы создать «общие» сервера (для fcm же есть) и при отправке запроса указывать адрес, например. Как появится время, буду заново разбирать. Может в каком-то моменте есть продвижения.
Какое-то время сам рассматривал работу с push, но, из-за недостатка времени, пока отложил. И искал я реализации без использования fcm.
Все упоминания и реализации push непременно связаны с fcm. Да, это, конечно, удобно, что не нужно заморачиваться с сервером и разницей реализации в разных браузера, но этот вариант не особо подходит для целей, когда одним из требований является работа только с локальными ресурсами (например, когда web недоступен).
Плюс, хотелось бы понимать что происходит «под капотом» библиотек, которым безоговорочно доверяют.
Самым лучшим решением, на мой взгляд, будет магазин приложений, где можно будет скачать приложения для разных платформ. Но создать и обслуживать такую платформу под силу только большим корпорациям. С решениями Google и Apple уже были недовольства, поэтому то, что будут предлагать они, может быть воспринято с определённой долей недоверия. Остаются Microsoft и Amazon. Если кто-то из них решится создать такое, то, несомненно, получит неплохой доход.
Либо, причина тут была изначально в другом. Возможно, просто был план отказаться от подобных технологий и реализовать всё через браузер. Хотя, сомневаюсь, что смогут реализовать все фишки и это точно будет нескоро.
Никто не требует, чтобы элементы или внешний вид были такими. Автор использовал то, что было под рукой. Хотите, красиво — делайте.
На счёт цифровой подписи согласен и хотелось бы дополнить, что отследить по ней могут не только в Chromium-based браузерах. Нас уже давно продают и покупают все кому не лень.
Я, например, за. Пусть оставят только браузер в Chromium, а все свои плюшки реализуют в Google Chrome.
А что касается размера, то `-ldflags="-s -w"` достаточно (с учётом, что изначально приложение весит 30M+, а с этой опцией ужимает до 10M-15M). Ну, или просто убрать debug информацию с помощью команды `strip -s APPLICATION`.
По upx: да, хорошая программа, знаю давно, но пару раз на Go программах (когда язык только начал распространяться), результирующее приложение вылетало при старте. Возможно, потом это починили, т.к. в последнее время с таким не сталкивался. Но для production, всё равно, его не использую — достаточно удаления debug информации.
P.S. Спасибо за информацию о Sentry. Нужно как-нибудь поизучать его. Всегда полезно быть в курсе работы приложения.
Но, отказываться от SSD я не стал и использую его только для системы — не для данных. Никаких оптимизаций не делал, кэши не отключал, драйвера поддерживаю в актуальном состоянии, установлены две ОС.
Периодически делаю полный бекап диска. На мой взгляд, это оптимальный вариант работы.
Одно время, я работал над проектом на nodejs. Сборка была автоматизирована и проблем с этим не было, но запуск и работа была, скажем так, небыстрой.
Полностью согласен с автором, что существующие средства разработки очень медленные. И жадные до памяти.
P.S. долго думал над «вскод». Сперва показалось, что ошибка/опечатка. Когда дошёл до «жскод», стало понятно. VSCode/Atom/Electron жрут немало ресурсов. С теплотой вспоминаю VS6.
Я, например, один из рабочих продуктов, разметил в Gilab, Github, Bitbucket и локальном репозитории. Это даёт мне возможность работать с продуктом из разных мест. Я просто читаю все репозитории и пишу тоже во все. Если один из ресурсов недоступен, то на него изменения прилетят в следующий раз. Во всех местах хранятся все ветки и все коммиты. В любой момент можно залить на очередной репозиторий и в нём окажется все, что есть в остальных.
На счёт бинарных данных, хорошо заметили. В проекте они тоже есть, но обновляются крайне редко. Хотя, урок для себя из статьи я вынес по данному моменту.
Не исключено, что через десяток/другой все привычные нам значки будут заменены.
500G фоток на телефоне? Что же это за телефон такой? Даже флешки с таким объёмом не так распространены. Я уже не говорю про встроенную память. Хотя, если это что-то из топовых iPhone, то ещё может быть.
А с MTP полностью согласен. Он не только выдаёт ошибки, но и тормозит жутко. Конечно, может хотели что-то защитить аппарат и пр., но решение так себе. Телефон, определяемый как флешка было самое то.
Если грамотно спроектировать, то на размерах конечного продукта это не особо отразилось бы.
Про Blocks слышал. Идея была хорошая, но не сложилось.
Про остальные не слышал.
Все упоминания и реализации push непременно связаны с fcm. Да, это, конечно, удобно, что не нужно заморачиваться с сервером и разницей реализации в разных браузера, но этот вариант не особо подходит для целей, когда одним из требований является работа только с локальными ресурсами (например, когда web недоступен).
Плюс, хотелось бы понимать что происходит «под капотом» библиотек, которым безоговорочно доверяют.