Пользовался этой читалкой (simplerssreader), одна из лучших. Оффлайн нет (она не скачивает статьи — только шапки из титл/дескрипшен). Ридабилити кривой. Автообновление не работает. Интерфейс — каша из статей из всех источников. Но повторюсь — это одна из лучших читалок. У остальных всё еще хуже.
А вообще лично меня в почтовых клиентах раздражают две вещи:
— перевернутый скролл
— отсутствие группировки по отправителю
Идеальный почтовый клиент в моем понимании — это каналы в телеграм. Каждый отправитель это канал, раз. Напротив каждого отправителя — количество непрочитанных сообщений — два. При клике на отправителя — читаю его письма в хронологичеком порядке, начиная с последнего прочитанного — три. Собственно мое приложение придерживается тех же принципов и изначально я писал почтовый клиент. Это уже на ходу переобулся в читалку. Но надеюсь когдать вернусь к этому вопросу.
Делаю сейчас темную тему, в разрабатываемом мною приложении.
Я применил для картинок в ленте — метод дизеринга Аткинсона. Они выглядят довольно спорно, но вполне читаемо. Не уверен что такой радикальный формат вам подойдет — но всё же
Темная
Светлая
Для тела статьи — генерируются две картинки. Сжатая дизерингом — как плейсхолдер, на время загрузки. В случае оффлайн доступа — показывается только дизеринг версия (оригиналы не скачиваются на устройство для экономии места)
Основной экран — обычный blue gray в терминах material. Оттенки серого вобщем:
Читаю хабр через свое приложение. Это агрегатом типа рсс читалки. Отличие в том, что все статьи прогоняются через ридабилити плагин и скачивают я на телефон. Те работает офлайн. Вобщем, там даже комментариев нет, но мне нравится. Апи не пользуюсь, парсю рсс + контент. Написан на флаттер, но движок на go
Статья понравилась, хороший обзор. Лишний раз убедился в правильности выбора между двух "зол". Правда я выбрал зло от гугл, https://grpc.io/. Рекомендую приглядеться.
Все методы возвращают ошибку вторым параметром, так как прилететь она может откуда угодно. Все надо обрабатывать. В нормально работающей системе никаких ошибок не случается, с одной стороны. С другой стороны, файл может повредиться в результате аппаратного сбоя, или экскаватор перерубит кабель питания, или в дебиан случится кернел паник в конце концов диски «летят» — это случается. Можно писать в файл дважды, это просто, но это никак не поможет если полетел диск. А если он не полетел то и файл не повредится.
Итого, когда Вы покупаете сервер, обычно в «довесок» дарят небольшой ftp сервер для бэкапов, физически размещенный на другом сервере. И единственный путь минимизировать потери — это делать бэкапы, зиповать и отправлять их на этот другой сервер и периодически проверять. Либо писать «живую» реплику — если простой на время востановления бэкапа ведет к ощутимым убыткам/недопустим. Тема репликации немного выходит за рамки движка для хранения данных.
скорость вставки кривая из-за персистенса. Ну точнее не кривая, а вместе с персистенсом (скорее всего бант персистит при закрытии в инмемори режиме, как и пудж, и это время включено в put — github.com/recoilme/pogreb-bench/blob/master/cmd/pogreb-bench/benchmark.go#L129) Поправьте сами если хотите померять чистый пут
Значения хранятся без оверхеда. Можно например сохранить картинку или фильм в пудж — и она будет открываться. Например: pudge.Set(«img/image.jpg»,«imagekey»,[]byte(..imagedata..))
Ключи хранятся в индексах, занимают размер ключа + 16 байт на ключ
На телефонах очень медленно в принципе. Даже родной sqlite превращается в жуткого тормоза. При том, что на десктоп это одна из самых быстрых бд. Скан папки Телеграм занимает минут 20. Я не копал в чем там дело, фс, драйвера или железо, но есть такая боль в АОСП
Поделитесь потом, интересно. Ну и бенчи я прогоню завтра, выложу. У меня когда последний раз смотрел была гиг 30. И тупил по несколько секунд на вставку. Правда ссд похоже криво замаунтился. На другом проекте, болт винт грузил на 100%. Болт плохой.
1) Болт коварный. Отлично спроектировано апи. Прекрасно работает на маленькой бд и плох, когда база перестаёт вмешаться в память целиком. Вставка деградирует особенно сильно. Кстати, проверить можете сами, элементарно заменив путь в пакете импорта. Там нет отличий. Для него нет бенчмарков на десятках миллионов, так как он очень медленный. Причём даже с выключенным fsync, на ssd. Бболт это тот же болт с мелкими фиксами. Я и код сравнивал и проверял. Постараюсь завтра прогнать хотя-бы десяток миллионов, если не верите, но боюсь это займёт более часа(
2) Префикс скан требует сортировки. Сортировка миллиона 8 байтных ключей занимает до секунды. Скан в уже отсортированном массиве ключей около 10 ms
Ps если вы относитесь скептически к пуджу, посмотрите лучше баджер. Я не юзал его в проде, но на бенчмарках он показал себя лучше всех. Только пухнет сильно, ну и учтите что будет копмпакшен, ибо лсм. Но все же думаю он лучше
Вы все верно предположили. Пудж останется простым движком для встраивания, а над ним можно уже что угодно городить.
Ну и кстати по скорости редис переплюнуть не так уж и сложно, он же однопоточный. Редис хитёр, но не так уж и быстр. Вот бенчмарк чтения/записи в мемкеш в 100 потоков (они примерно сопоставимы, где то мемкеш даже быстрее)
А вот чтение/запись в 100 потоков пудж и это в режиме ежесекундного fsync в персистенс моде. В инмемори моде пудж намного быстрее. Другое дело что в редисе масса других ништяков и врятли они пересекаются с пуджем
Нет, не планируется. Пудж это простой как гвоздь движок и я постараюсь его таковым оставить. Это скорее в рамках сервера должно быть реализовано. А сервера пока нет
Сервер нужен для взаимодействия с базой по сети и из других ЯП. Да и в гоу иногда удобнее держать БД в виде отдельного сервиса
Скорее всего сервер будет в виде отдельного проекта и будет поддерживать grps, http и, возможно, memcache протокол (текстовую версию)
Ссылки ведут на примеры реализаций серверов, не на описания протоколов.
— перевернутый скролл
— отсутствие группировки по отправителю
Идеальный почтовый клиент в моем понимании — это каналы в телеграм. Каждый отправитель это канал, раз. Напротив каждого отправителя — количество непрочитанных сообщений — два. При клике на отправителя — читаю его письма в хронологичеком порядке, начиная с последнего прочитанного — три. Собственно мое приложение придерживается тех же принципов и изначально я писал почтовый клиент. Это уже на ходу переобулся в читалку. Но надеюсь когдать вернусь к этому вопросу.
Я применил для картинок в ленте — метод дизеринга Аткинсона. Они выглядят довольно спорно, но вполне читаемо. Не уверен что такой радикальный формат вам подойдет — но всё же
Темная
Светлая
Для тела статьи — генерируются две картинки. Сжатая дизерингом — как плейсхолдер, на время загрузки. В случае оффлайн доступа — показывается только дизеринг версия (оригиналы не скачиваются на устройство для экономии места)
Основной экран — обычный blue gray в терминах material. Оттенки серого вобщем:
Список источников
https://habrastorage.org/webt/pe/mp/kq/pempkqmloc1m0zhhv83ndlaj-uo.png
Список статей
https://habrastorage.org/webt/kb/-w/kl/kb-wklqal6iik6ddjhz3pqx5k3e.png
Читаю хабр через свое приложение. Это агрегатом типа рсс читалки. Отличие в том, что все статьи прогоняются через ридабилити плагин и скачивают я на телефон. Те работает офлайн. Вобщем, там даже комментариев нет, но мне нравится. Апи не пользуюсь, парсю рсс + контент. Написан на флаттер, но движок на go
Статья понравилась, хороший обзор. Лишний раз убедился в правильности выбора между двух "зол". Правда я выбрал зло от гугл, https://grpc.io/. Рекомендую приглядеться.
Итого, когда Вы покупаете сервер, обычно в «довесок» дарят небольшой ftp сервер для бэкапов, физически размещенный на другом сервере. И единственный путь минимизировать потери — это делать бэкапы, зиповать и отправлять их на этот другой сервер и периодически проверять. Либо писать «живую» реплику — если простой на время востановления бэкапа ведет к ощутимым убыткам/недопустим. Тема репликации немного выходит за рамки движка для хранения данных.
Ключи хранятся в индексах, занимают размер ключа + 16 байт на ключ
github.com/recoilme/pogreb-bench#test-5-switch-to-bbolt-from-coreos
github.com/recoilme/pogreb-bench#test-6-switch-to-bbolt-from-coreos
На телефонах очень медленно в принципе. Даже родной sqlite превращается в жуткого тормоза. При том, что на десктоп это одна из самых быстрых бд. Скан папки Телеграм занимает минут 20. Я не копал в чем там дело, фс, драйвера или железо, но есть такая боль в АОСП
Поделитесь потом, интересно. Ну и бенчи я прогоню завтра, выложу. У меня когда последний раз смотрел была гиг 30. И тупил по несколько секунд на вставку. Правда ссд похоже криво замаунтился. На другом проекте, болт винт грузил на 100%. Болт плохой.
У болта включён режим nosync.
https://github.com/recoilme/pogreb-bench/blob/master/cmd/pogreb-bench/bolt.go#L19
У пуджа, в той версии, по дефолту был включён принудительный fsync, ежесекундный
Те все ровно наоборот)
1) Болт коварный. Отлично спроектировано апи. Прекрасно работает на маленькой бд и плох, когда база перестаёт вмешаться в память целиком. Вставка деградирует особенно сильно. Кстати, проверить можете сами, элементарно заменив путь в пакете импорта. Там нет отличий. Для него нет бенчмарков на десятках миллионов, так как он очень медленный. Причём даже с выключенным fsync, на ssd. Бболт это тот же болт с мелкими фиксами. Я и код сравнивал и проверял. Постараюсь завтра прогнать хотя-бы десяток миллионов, если не верите, но боюсь это займёт более часа(
2) Префикс скан требует сортировки. Сортировка миллиона 8 байтных ключей занимает до секунды. Скан в уже отсортированном массиве ключей около 10 ms
Ps если вы относитесь скептически к пуджу, посмотрите лучше баджер. Я не юзал его в проде, но на бенчмарках он показал себя лучше всех. Только пухнет сильно, ну и учтите что будет копмпакшен, ибо лсм. Но все же думаю он лучше
Ну и кстати по скорости редис переплюнуть не так уж и сложно, он же однопоточный. Редис хитёр, но не так уж и быстр. Вот бенчмарк чтения/записи в мемкеш в 100 потоков (они примерно сопоставимы, где то мемкеш даже быстрее)
А вот чтение/запись в 100 потоков пудж и это в режиме ежесекундного fsync в персистенс моде. В инмемори моде пудж намного быстрее. Другое дело что в редисе масса других ништяков и врятли они пересекаются с пуджем
Скорее всего сервер будет в виде отдельного проекта и будет поддерживать grps, http и, возможно, memcache протокол (текстовую версию)
Ссылки ведут на примеры реализаций серверов, не на описания протоколов.