Странно слушать все опасения из комментариев выше про блокировки, зная что как только выезжаешь за город то без налички ты достаточно вероятно ничего не купишиь или ни с кем не рассчитаешься, т.к. банально для работы банковских монстроприкладов Е-шки не хватает даже там где она вообще есть. Так что не бойтесь, никуда налик не денется, в худшем случае не больше 10к в одни руки в месяц))
как всегда ктото уже заделал плагин, погуглить чтонить типа "Hide YouTube Shorts". Иногда конечно интерфейс корячит видимо изза очередных супернужных обнов интерфейса, но в целом намного приятнее жить без шортсов
Потребители подписываются на темы и получают сообщения из разделов. Каждый раздел одновременно закреплен только за одним потребителем, что обеспечивает распределение нагрузки.
К этому моменту не указаны термины и что есть что, не приведены даже английские аналоги в скобках. В ру мире кафки устоявшиеся "топик" и "партиция" не переводятся. Про слушатель/слушать тоже доставило, видимо прямая калька от спринговского listener-а не давала покоя, опять же у нас используется подходящие к pub/sub терминологии подписка/подписчик/получатель Статью из-за этого обилия переведенных устоявшихся терминов читать практически невозможно.
И тут даже нет примера базовой реализации, молчу про ссылки на стандартную реалзиацию openzeppelin и чем она лучше простейшей реализации. Для статьи с таким громким названием урвоень ниже плинтуса
циферок бы каких по типу было столько брака/претезий/проблем до внедрения и сколько стало после ну и самое интересное же для всех - какие проблемы были при внедрении?
Да и для монги тоже 32Тб не предел. А про транзакции уже давно есть мультидокументные, которые в пределах узла реплики атомарны. А если надо то и на кластере можно, но ценой резкого увеличения времени выполнения запроса.
ну что вы в самом деле, S3 уже давно имя нарицательно для всего что может блобы хранить и имеет какой никакой интерфейс для этого. S3 просто задал фактически стандарт этого API, а реализаций есть куча не в облаках и думаю при желании и на том же PG найти можно
Уровень покрытия, согласно Quality Gate, должен быть не менее 85%, но на самом деле, его можно было поднять и выше, т.к. зачастую покрытие не ниже 95%. Такой сравнительно высокий уровень покрытия требует определенных временных затрат.
Так что считают именно покрытие, а не забыл/не забыл. Более того думаю, что разрабы как раз покрывают тестами сериализацию только, чтобы получить заветные проценты на "дешевых" тестах, а не на сложных, где логика тестируется. Пакеджи с dto и обвязой вокруг них вообще должны игнорироваться при высчитывании покрытия, но почему-то это редко кто настраивает
когдато так и было - пользователь Хабра с положительной кармой и рейтингом считался адекватным, т.к. сообщество оценило его адекватность. Сейчас да все это не показатель, но назад фарш не провернуть, а вот изготовить из него что-то вкусное вполне реально. Как ни странно думаю сейчас можно проводить смело эксперимент и по убиранию возможности плюсовать или добавления возможности минусовать - показать на фронте что плюсик/минус добавился самому юзеру, но в ленту для всех не учитывать плюсы/минусы и посмтреть что будет. В таком случае можно дропнуть все минусы, если все печально, и начать учитывать плюсы как сейчас. Главное потом статейку с отчетом о таком тесте выкатить и показать какие результаты получились. @Boomburum можете такое провернуть?
вот бы это еще на чтото повлияло. Пытался придумать пример последствий, но они все получаются про ограничения появления новых статей от таких авторов и завязаны на модерацию перед публикацией, на что администрация Хабра не пойдет. И даже банальное проставление тега или плашки в заголовок к сожалению снизит просмотры, что тоже "не ок". А авторы вообще могут начать тюнить заголовки на кликбейт и KPI по просмотрам повышать за счет такой обратной связи и делать их еще кликбейтнее
Так-то много жалоб вида "да кто это плюсует?". Очевидно же что это проблема сообщества хабра, которое теряет механизм регулирования "качества" статей и авторов. Получается надо прислушиваться не только к авторам, которые жалуются на минуса, а наконец послушать остальных пользователей, когда они в очередной раз не понимают почему что-то набирает плюсы, хотя под статьями комменты вида "тут все неправильно, уже есть способы решения, вы упустили самое главное и т.п." с приведением ссылок и относительно живым обсуждением, где проявляется нами любимое "комменты полезнее статьи" Вот тут и надо либо отобрать возможность плюсовать статьи всем подряд, либо дать возможность минусить наравне с плюсами - так у сообщества будет возможность регуляции. Если боитесь волн "за что мне минус", то отберите плюсы - это тоже вариант баланса, кто захочет ставить плюсы пойдет напишет статью и за нее наберет нужный порог кармы, чтобы потом смочь ставить и плюсы и минусы (вроде так даже когдато было, но ктож вспомнит да)
Уже итак плюсов многовато, не для кармы, а для статей - почему можно статьи плюсовать, а миносовать нельзя без наличия своих статей даже с положительной кармой? Либо и то и то нельзя либо и то и то можно, определитесь, а то всякий шлак так и будет собирать кучу плюсов. Но спасибо за фичу, по факту ровно как я и описывал в феврале https://habr.com/ru/article/650393/comments/#comment_24050675
надо просто показывать клиенту все предложения в таком аукционе. А он может выбрать самый бичевый или уже по комфортности. Навесить какойнить шильдик по типу эконом/комфорт и группировать по ним с сортировкой цены и это даже станет удобным.
Вот постепенно задача дошла до предпоследнего шага, за которым остается просто предзаполненный массив на 30 итераций физбаза (хоть и сгенерированный алгоритмом), который копируется до нужного количества в буфер вывода.
Вообще смешно было наблюдать как задача с решением общего вида, в котором достаточно было поменять какой-то параметр и она бы продолжила решать аналогичную задачу, превратилась в нечто, что не может решить больше никакую другую задачу, даже похожую, без почти полного переписывания.
Странно слушать все опасения из комментариев выше про блокировки, зная что как только выезжаешь за город то без налички ты достаточно вероятно ничего не купишиь или ни с кем не рассчитаешься, т.к. банально для работы банковских монстроприкладов Е-шки не хватает даже там где она вообще есть. Так что не бойтесь, никуда налик не денется, в худшем случае не больше 10к в одни руки в месяц))
как всегда ктото уже заделал плагин, погуглить чтонить типа "Hide YouTube Shorts". Иногда конечно интерфейс корячит видимо изза очередных супернужных обнов интерфейса, но в целом намного приятнее жить без шортсов
но это же вспомогательные обслуживающие сервисы и там по факту ноль бизнес логики с точки зрения нормального бизнеса, так что человек прав)
Очередной пример для статьи https://habr.com/ru/articles/770536/
К этому моменту не указаны термины и что есть что, не приведены даже английские аналоги в скобках. В ру мире кафки устоявшиеся "топик" и "партиция" не переводятся. Про слушатель/слушать тоже доставило, видимо прямая калька от спринговского listener-а не давала покоя, опять же у нас используется подходящие к pub/sub терминологии подписка/подписчик/получатель
Статью из-за этого обилия переведенных устоявшихся терминов читать практически невозможно.
И тут даже нет примера базовой реализации, молчу про ссылки на стандартную реалзиацию openzeppelin и чем она лучше простейшей реализации. Для статьи с таким громким названием урвоень ниже плинтуса
про возмещение в частном порядке пострадавшим читать эпопею https://habr.com/ru/companies/digitalrightscenter/articles/763096/
конечно, это ж однозначно номинация на шнобелевку минимум)
циферок бы каких по типу было столько брака/претезий/проблем до внедрения и сколько стало после
ну и самое интересное же для всех - какие проблемы были при внедрении?
Статья про опросы без опроса, как оценить как вы сами используете то, что перечслили в статье?
Да и для монги тоже 32Тб не предел. А про транзакции уже давно есть мультидокументные, которые в пределах узла реплики атомарны. А если надо то и на кластере можно, но ценой резкого увеличения времени выполнения запроса.
ну что вы в самом деле, S3 уже давно имя нарицательно для всего что может блобы хранить и имеет какой никакой интерфейс для этого. S3 просто задал фактически стандарт этого API, а реализаций есть куча не в облаках и думаю при желании и на том же PG найти можно
так они не будут, 10Мб - уже кандидат на S3
upd: внизу уже обсосали эту тему
Так что считают именно покрытие, а не забыл/не забыл. Более того думаю, что разрабы как раз покрывают тестами сериализацию только, чтобы получить заветные проценты на "дешевых" тестах, а не на сложных, где логика тестируется. Пакеджи с dto и обвязой вокруг них вообще должны игнорироваться при высчитывании покрытия, но почему-то это редко кто настраивает
когдато так и было - пользователь Хабра с положительной кармой и рейтингом считался адекватным, т.к. сообщество оценило его адекватность. Сейчас да все это не показатель, но назад фарш не провернуть, а вот изготовить из него что-то вкусное вполне реально. Как ни странно думаю сейчас можно проводить смело эксперимент и по убиранию возможности плюсовать или добавления возможности минусовать - показать на фронте что плюсик/минус добавился самому юзеру, но в ленту для всех не учитывать плюсы/минусы и посмтреть что будет. В таком случае можно дропнуть все минусы, если все печально, и начать учитывать плюсы как сейчас. Главное потом статейку с отчетом о таком тесте выкатить и показать какие результаты получились. @Boomburum можете такое провернуть?
вот бы это еще на чтото повлияло.
Пытался придумать пример последствий, но они все получаются про ограничения появления новых статей от таких авторов и завязаны на модерацию перед публикацией, на что администрация Хабра не пойдет. И даже банальное проставление тега или плашки в заголовок к сожалению снизит просмотры, что тоже "не ок". А авторы вообще могут начать тюнить заголовки на кликбейт и KPI по просмотрам повышать за счет такой обратной связи и делать их еще кликбейтнее
Так-то много жалоб вида "да кто это плюсует?". Очевидно же что это проблема сообщества хабра, которое теряет механизм регулирования "качества" статей и авторов. Получается надо прислушиваться не только к авторам, которые жалуются на минуса, а наконец послушать остальных пользователей, когда они в очередной раз не понимают почему что-то набирает плюсы, хотя под статьями комменты вида "тут все неправильно, уже есть способы решения, вы упустили самое главное и т.п." с приведением ссылок и относительно живым обсуждением, где проявляется нами любимое "комменты полезнее статьи"
Вот тут и надо либо отобрать возможность плюсовать статьи всем подряд, либо дать возможность минусить наравне с плюсами - так у сообщества будет возможность регуляции. Если боитесь волн "за что мне минус", то отберите плюсы - это тоже вариант баланса, кто захочет ставить плюсы пойдет напишет статью и за нее наберет нужный порог кармы, чтобы потом смочь ставить и плюсы и минусы (вроде так даже когдато было, но ктож вспомнит да)
Уже итак плюсов многовато, не для кармы, а для статей - почему можно статьи плюсовать, а миносовать нельзя без наличия своих статей даже с положительной кармой? Либо и то и то нельзя либо и то и то можно, определитесь, а то всякий шлак так и будет собирать кучу плюсов.
Но спасибо за фичу, по факту ровно как я и описывал в феврале https://habr.com/ru/article/650393/comments/#comment_24050675
надо просто показывать клиенту все предложения в таком аукционе. А он может выбрать самый бичевый или уже по комфортности. Навесить какойнить шильдик по типу эконом/комфорт и группировать по ним с сортировкой цены и это даже станет удобным.
вот и конкурент inDrive подоспел
Вот постепенно задача дошла до предпоследнего шага, за которым остается просто предзаполненный массив на 30 итераций физбаза (хоть и сгенерированный алгоритмом), который копируется до нужного количества в буфер вывода.
Вообще смешно было наблюдать как задача с решением общего вида, в котором достаточно было поменять какой-то параметр и она бы продолжила решать аналогичную задачу, превратилась в нечто, что не может решить больше никакую другую задачу, даже похожую, без почти полного переписывания.