Из статьи в статью, из года в год перепечатывают один и тот же тезис что PWA медленный.
Но эта статья пробивает дно.
Никаких замеров производительности, одни оценочные суждения!
Но даже если к ним присмотреться, то
Один из главных недостатков PWA заключается в том, что они могут быть медленнее, чем обычные веб-сайты. Это происходит из-за того, что PWA должны загружать все ресурсы, необходимые для работы приложения, включая шрифты, изображения и JavaScript-файлы.
Нет, это ложь. PWA устанавливает воркер, который кэширует всё приложение.
Максимальная производительность и функциональность.
Не факт
Полный доступ к устройственным функциям.
Нативные приложения могут взаимодействовать с камерой, сенсорами, геолокацией и другими устройственными возможностями.
Не всегда это нужно. А когда нужно - можно погуглить "How to Access the Camera in a PWA" и т.п. Ответы есть, PWA это тоже умеет.
Лучший пользовательский опыт.
Зависит больше от навыков разработчика.
Доступ к магазинам приложений.
Так же возможен
Нативные приложения считаются более безопасными из-за ряда факторов:
1. Приложения используют многофакторную аутентификацию.
Как будто PWA это запрещает. Как будто нативных приложений без двухфакторки нету.
2. Имеют SSL-сертификат.
PWA без SSL не работает. В принципе не работает. А вот нативное приложение может сходить на сервер и без SSL.
Очень странно, когда автор пишет в статье, о минусе PWA - "PWA приложения обеспечивают безопасность за счет использования HTTPS-протокола". И после этого - "Преимущества нативных приложений перед PWA... Имеют SSL-сертификат. "
А-а-а, у меня пригорает от такого уровня аналитики.
Сторы имеют ряд правил, благодаря которым безопасность приложения находится на приемлемом уровне.
"всё смешалось в доме облонских". Как будто в сторах нету вирусов и скама. Как будто разработчику PWA что-то мешает соблюдать "ряд правил, благодаря которым безопасность приложения находится на приемлемом уровне"
p.s. Возможно, когда-нибудь, я напишу статью про Ionic. Возможно я расскажу как тот же самый PWA, уже без Ionic, работает с sqlite и пишет файлы напрямую в файловую систему из браузера. И какие есть ограничения у этого способа.
К сожалению, я практически не встречал техник, которые ставили бы на первое место Информацию, а не Торжественное внесение заметки в базу.
Разве что Notion и его open source‑альтернатива AppFlowy (пока по‑прежнему сыровато, но пользоваться можно, проект помаленьку обрастает новыми функциями, вон вкладки привезли и добавление заметок в «Избранное»).
Obsidian и SingularityApp.
Основная ошибка, это то, что люди смешивают базу знаний и планировщик дел. Такой комбайн будет всегда сложным.
Что такое аутстаффинг в России и по каким критериям выбирать аутстафф-подрядчика
ТК РФ Статья 56.1 - Заемный труд запрещен.
Заемный труд - труд, осуществляемый работником по распоряжению работодателя в интересах, под управлением и контролем физического лица или юридического лица, не являющихся работодателем данного работника.
КоАП РФ Статья 5.27. - Нарушение трудового законодательства и иных нормативных правовых актов, содержащих нормы трудового права
Я буду очень рад, если кто может поделиться опытом решения подобных задач
Предоплата. Рекурентный платеж в качестве предоплаты.
или аргументированно указать на недочеты в моём анализе.
Попросите юриста аргументированно рассказать вам что такое "слабая сторона" договора и что такое "предпринимательский риск".
Компания может выделить время и ресурсы на доказывание факта неоплаты и мошенничества.
А ещё Хабр это не жалобная книга. Этот сайт всё-таки технический, а не юридический.
По существу, все процессинговые центры должны отказаться от проведения рекуррентных платежей платежной системы "МИР", так как нет возможности защитить компании от мошеннических действий клиентов.
Я так понимаю вся статья ради вброса этого тезиса?
Вот только в итоге 404 страница отдается со статусом 200. Не делайте так, это заметание проблемы "под ковёр". В мониторинге должен быть виден правильный статус.
Jaeger, OpenTracing, и хранение в Cassandra - устаревают.
Сейчас появляются решения на Clickhouse, с дополнительной возможностью по агрегации трейсов, перцентилями и статистикой. Также идёт переход на OpenTelemetry.
А я считаю что идея правильная. Ваше недовольство сводится к двум пунктам
Никто не хочет брать самое дешёвое, прекрасно понимая, что через год-два оно посдыхает полностью, расходников и запчастей к нему нет и никогда не будет, а на борьбу с его глюками придётся отрядить половину IT-отдела
Фиксится обязательной гарантией лет эдак на 5-10. Как часть закупки. Со штрафами и УК РФ за несоблюдение. Сразу уменьшится кол-во желающих подать заявку с таким Г.
не закупишь больше принтеры под заблаговременно поставленную ранее нестандартную бумагу (реальный случай), не закажешь уникальные моноблоки без внешнего блока питания (реальный случай), не пропишешь в требованиях к ноутбуку наличие сервисных центров производителя в городах с населением от 200 тыс. человек
Государство это очень большая система, управляемость которой очень сильно зависит от стандартизации. Не должно оно иметь какое-то очень уникальное оборудование. Если это уникальное оборудование так сильно важно, то оно пойдёт новым пунктом в этой КТРУ и станет стандартом для всей системы, а не где-то в её отдельной части.
Из экспериментального сырья, недавно полученного на такой же экспериментальной установке, нужно получить сверхпрочный битум, подобрать режим, верифицировать установку
Мне кажется вы некорректно понимаете суть исследовательской деятельности. Результатом такой работы является заключение, можно ли получить этот битум из этого сырья или нет. Если да, то как. А не гарантия, что вы получите этот битум любой ценой. Т.е. вы продаёте немного не то, и ещё позволяете себя прогибать по условиям, цене и срокам.
Итог закономерен:
И вот, пройдя через все круги ада, мы возвращаемся к разбитому корыту. R&D-бизнес в нефтехимии - это здорово, но прибыль мизерная. Зачастую ее даже нет.
Это не бизнес. Это какое-то увлекательное хобби, за которое иногда что-то платят.
Каждое решение имеет свои ограничения, и наше — не исключение.
Мы не поддерживаем автоматический решардинг (пока).
Мы не поддерживаем multi-shard операции JOIN.
Мы не поддерживаем распределенные транзакции.
С учётом получившихся ограничений, и если отказаться от попыток эти ограничения обойти, то всё можно сделать гораздо проще.
Считаем offset = CalculateHash(shard_key) % BucketNumber. По этому номеру получаем ConnectionString из конфига (не нужно для этого держать отдельную мастер базу и иметь доп.риски отказа), по ConnectionString идём в нужную БД. BucketNumber определяется как константа один раз. А вот количество серверов может быть разным. Перенос отдельной базы на новый сервер это более простая задача, после которой всё что надо будет сделать это поменять соответствующий ConnectionString.
Мы исходим из ситуации, в которой мы приняли решение, что для конкретного проекта сервер ASP.NET должен между запросами не только хранить какие-то статические данные, но и возможно выполнять какую-то полезную работу.
Хранить данные между запросами - как правило для этого используют БД, но можно и кэш.
Статья в основном про кэш. Он может быть: на клиенте, в redis и аналогах, просто in-memory. На тему кэширования написано много статей и лучше. Тема инвалидации кэша вообще не затронута.
"выполнять какую-то полезную работу" в фоне - это background jobs или scheduled jobs.
У вас в статье это всё смешано в кучу и ещё добавлено про DI и юнит тесты.
По большому счёту претензия - "зачем, о чём статья"? Как обучающая - нет, всё поверхностно и "новичково". Как демонстрация лично вашего опыта? Ну не знаю, не хватает чего-то, что нельзя прочитать в учебнике по .Net.
Из статьи в статью, из года в год перепечатывают один и тот же тезис что PWA медленный.
Но эта статья пробивает дно.
Никаких замеров производительности, одни оценочные суждения!
Но даже если к ним присмотреться, то
Нет, это ложь. PWA устанавливает воркер, который кэширует всё приложение.
Не факт
Не всегда это нужно. А когда нужно - можно погуглить "How to Access the Camera in a PWA" и т.п. Ответы есть, PWA это тоже умеет.
Зависит больше от навыков разработчика.
Так же возможен
Как будто PWA это запрещает. Как будто нативных приложений без двухфакторки нету.
PWA без SSL не работает. В принципе не работает. А вот нативное приложение может сходить на сервер и без SSL.
Очень странно, когда автор пишет в статье, о минусе PWA - "PWA приложения обеспечивают безопасность за счет использования HTTPS-протокола". И после этого - "Преимущества нативных приложений перед PWA... Имеют SSL-сертификат. "
А-а-а, у меня пригорает от такого уровня аналитики.
"всё смешалось в доме облонских". Как будто в сторах нету вирусов и скама. Как будто разработчику PWA что-то мешает соблюдать "ряд правил, благодаря которым безопасность приложения находится на приемлемом уровне"
p.s. Возможно, когда-нибудь, я напишу статью про Ionic. Возможно я расскажу как тот же самый PWA, уже без Ionic, работает с sqlite и пишет файлы напрямую в файловую систему из браузера. И какие есть ограничения у этого способа.
Obsidian и SingularityApp.
Основная ошибка, это то, что люди смешивают базу знаний и планировщик дел. Такой комбайн будет всегда сложным.
ТК РФ Статья 56.1 - Заемный труд запрещен.
Заемный труд - труд, осуществляемый работником по распоряжению работодателя в интересах, под управлением и контролем физического лица или юридического лица, не являющихся работодателем данного работника.
КоАП РФ Статья 5.27. - Нарушение трудового законодательства и иных нормативных правовых актов, содержащих нормы трудового права
У сертификата есть алгоритм подписи. Он может быть разным, с разной вычислительной сложностью. Может в новом алгоритм какой-то неподдерживающийся?
Я бы копал в сторону фильтра Блума и его модификаций
Это оверинжиниринг, на мой взгляд. Ещё и акторы зачем-то.
В .net есть BackgroundService и всё сводится к 3м сервисам:
Общая очередь (можно в памяти, синглтон или статик ConcurrentQueue) с данными для таски
BackgroundService который смотрит эту очередь и запускает таску
Сервис с бизнес-логикой самой таски. Паттерн стратегия.
Формально вы правы, а по сути - издевательство.
Вы отказываетесь от ответственности за ложные срабатывания.
Меня сильно раздражает ваша капча, перестал пользоваться вашим подсайтом недвижимости.
Вы попробуйте вообще сами попользоваться своими сервисами.
Предоплата. Рекурентный платеж в качестве предоплаты.
Попросите юриста аргументированно рассказать вам что такое "слабая сторона" договора и что такое "предпринимательский риск".
Компания может выделить время и ресурсы на доказывание факта неоплаты и мошенничества.
А ещё Хабр это не жалобная книга. Этот сайт всё-таки технический, а не юридический.
Я так понимаю вся статья ради вброса этого тезиса?
Эээ, нет. Оплата по времени использованию - это привязка карты и разовая оплата (несколько разовых оплат, в разные моменты времени, на разные суммы).
Вы пишете про рекурентные платежи, это периодическая оплата одной и той же суммы, одного и того же периода длительности - это абонентская плата.
Вот только в итоге 404 страница отдается со статусом 200. Не делайте так, это заметание проблемы "под ковёр". В мониторинге должен быть виден правильный статус.
Jaeger, OpenTracing, и хранение в Cassandra - устаревают.
Сейчас появляются решения на Clickhouse, с дополнительной возможностью по агрегации трейсов, перцентилями и статистикой. Также идёт переход на OpenTelemetry.
Посмотрев на код запросов, у меня сложилось впечатление что их автор умеет в Sql но плохо знает Clickhouse.
Оставлю Вам эту ссылку - https://clickhouse.com/docs/ru/sql-reference/aggregate-functions/reference/argmax
А я считаю что идея правильная. Ваше недовольство сводится к двум пунктам
Фиксится обязательной гарантией лет эдак на 5-10. Как часть закупки. Со штрафами и УК РФ за несоблюдение. Сразу уменьшится кол-во желающих подать заявку с таким Г.
Государство это очень большая система, управляемость которой очень сильно зависит от стандартизации. Не должно оно иметь какое-то очень уникальное оборудование. Если это уникальное оборудование так сильно важно, то оно пойдёт новым пунктом в этой КТРУ и станет стандартом для всей системы, а не где-то в её отдельной части.
Мне кажется вы некорректно понимаете суть исследовательской деятельности. Результатом такой работы является заключение, можно ли получить этот битум из этого сырья или нет. Если да, то как. А не гарантия, что вы получите этот битум любой ценой. Т.е. вы продаёте немного не то, и ещё позволяете себя прогибать по условиям, цене и срокам.
Итог закономерен:
Это не бизнес. Это какое-то увлекательное хобби, за которое иногда что-то платят.
Некоторые аналогии подобны котёнку с дверцей - такие же странные.
Возвращаясь к программированию - добавьте idempotency key и retry. И будет вам exatly once.
Как бы вы обучали своих детей?
Мы не поддерживаем автоматический решардинг (пока).
Мы не поддерживаем multi-shard операции
JOIN.Мы не поддерживаем распределенные транзакции.
С учётом получившихся ограничений, и если отказаться от попыток эти ограничения обойти, то всё можно сделать гораздо проще.
Считаем offset = CalculateHash(shard_key) % BucketNumber. По этому номеру получаем ConnectionString из конфига (не нужно для этого держать отдельную мастер базу и иметь доп.риски отказа), по ConnectionString идём в нужную БД. BucketNumber определяется как константа один раз. А вот количество серверов может быть разным. Перенос отдельной базы на новый сервер это более простая задача, после которой всё что надо будет сделать это поменять соответствующий ConnectionString.
Их открытое письмо к президенту почему-то потёрли (https://vc.ru/u/1150867-rossiyskie-investory/394149-otkrytoe-pismo-prezidentu-rossiyskoy-federacii-vladimiru-vladimirovichu-putinu)
Про дело - https://www.rbc.ru/finances/28/04/2022/6260010f9a79471b86b82008
Хранить данные между запросами - как правило для этого используют БД, но можно и кэш.
Статья в основном про кэш. Он может быть: на клиенте, в redis и аналогах, просто in-memory. На тему кэширования написано много статей и лучше. Тема инвалидации кэша вообще не затронута.
"выполнять какую-то полезную работу" в фоне - это background jobs или scheduled jobs.
У вас в статье это всё смешано в кучу и ещё добавлено про DI и юнит тесты.
По большому счёту претензия - "зачем, о чём статья"? Как обучающая - нет, всё поверхностно и "новичково". Как демонстрация лично вашего опыта? Ну не знаю, не хватает чего-то, что нельзя прочитать в учебнике по .Net.