Pull to refresh
5
0
Send message

Решение проблемы со связью «многие-ко-многим» для .NET Core 3.1

На .NET Core 3.1 можно поставить efcore 5, так как у него нет зависимости от .NET 5

Есть где-то тесты, как влияет количество закладок на быстродействие лисы?
Вот если бы они сделали видео, как меняется структура нейронной сети в процессе ее обучения. Вот это было бы действительно наглядно.
Так говорите, как будто бы Голливуд — это прям какое-то достояние нации. Это просто шоу.
Еще добавлю просто шикарный фильм Дурак, Майор и сериал Метод. Это все Быкова кино.
Насколько я понял — основные понятия, база еще не вся описана. Поэтому уровень сложности для следующих статьей пока что можно оставить на этом же уровне.
Главное добавьте ссылку на следующие статьи сюда. Буду заходить проверять периодически.

А вообще, такие статьи мотивируют на дальнейшее изучение. Но все-таки основу хотелось бы прочитать от Вас.
Статья просто супер! Очень хотелось бы увидеть еще продолжение!
Что-то мне кажется, что когда будет на таком уровне долго радоваться мы не будем.
После ДТП, в котором сработали подушки безопасности.
Кроме того, даже за деньги потом нельзя ничего отремонтировать на официальных сервисных центрах Теслы.
Из-за мысли о том, что Tesla снимает с гарантии автомобили сразу после первого ДТП при всем желании как-то не особо получается радоваться за все его изобретения.
Допустим 1-я сеть решает, что нужно повернуть на 30 градусов влево, 2-я на 20 влево, а 3-я на 15 вправо. И решения всех 3 не приводят к аварии.
Но все 3 машины знают, что если повернуть на 25 градусов, то это приведет к аварии (не важно по какой причине). Ни одна из них не выбирает повернуть на 25 градусов, но если усреднить данные 1-й и 2-й сети и отбросить данные 3-й, то придется повернуть на 25 градусов.
Как быть в этом случае?
Мне кажется это можно сделать только одним способом:

Забить на внутренние метки ридера прочтен/не прочтен, и вместо них использовать метку для каждого элемента, в которой будет хранится инфа о прочтении/не прочтении этого элемента.

Все это нужно будет оформить в виде расширения для браузера. Или даже лучше скрипта для greasemonkey, чтобы во всех браузерах работало.
Нужно отсортировать «показывать новые первыми» и прокручивать вниз.
Только что проверил. Например июльские записи у меня есть в одном из потоков.
Но так же есть и потоки, в которых записей старше 30 дней уже нет. Это еще один минус, о котором я не знал.
Скорей всего он еще в зависимости от популярности фида — либо сохраняет записи старше 30 дней в нем, либо удаляет.

Вот и разобрались. Мало того, что он не хочет хранить отметку прочтен/не прочтен, так он еще и сами записи удаляет нафиг.
Так потоки он как раз хранит все. Сколько бы ему ресурсов это не стояло, но он их хранит.
А вот на отметку прочтен/не прочтен у него уже ресурсов нет почему-то.
Не все ведь пользуются Google Chrome.

Но если для Google Chrome есть расширение для бесконечного кеша, то я готов начать пользоваться этим браузером.
Это что же получается. На почту 7 гиг у них есть. Хранить все записи из канала они могут, а выделить один бит (возможно байт или даже 4 байта, в зависимости от способа хранения) для каждой записи они не могут.

Давайте посчитаем. Предположим, что у нас все каналы вроде хабра где-то ~ 100 000 записей в канале.
Пусть у нас таких каналов приблизительно 1000.
Итого на одного пользователя нужно 100 000 000 байтов.

100 000 0000 Байт / 1024 = 97 656,25 КБ / 1024 = 95,37 МБ
Предположим, что у них для хранения прочтен/не прочтен тратится не байт, а целых 4 байта. Тогда выходит аж 400 МБ на одного пользователя. И то, 400 МБ это с огромным запасом.

Я согласен, чтобы у меня было на 400 метров меньше в моей почте, лишь бы google reader был нормальным.

Или может этот ридер настолько не выгодный гуглу, что ему жалко даже 400 метров на пользователя.
Лучше бы перестали отмечать записи как прочтенные, которые старше 30 дней.
1

Information

Rating
Does not participate
Registered
Activity