Как же приятно было прочитать. Сам очень долго мучился с hp z27s.
Но один момент остался не ясен. Ваш монитор P2715Q — поддерживает 10-битную глубину цвета. Винда это называет разрядность. Получилось ли у вас ее активировать на вашем ноутбуке?
Общий пароль к сервису для всей команды? да вы шутите. Уже давно есть нормальные способы, без использования паролей.
Для веб есть авторизация по OAuth.
Для ssh/sftp есть авторизация по ключам и орекстрация конфигов.
В облаках есть какие-нибудь Identity and Access Management и подобное.
Plain ftp/Basic auth просто похороните.
Если у сервиса нет безпарольной авторизации — оставляйте доступ только для офиса и все остальное закрывайте файерволом. Удаленщикам и любителям иногда работать из дома — vpn в офис с персональными учетками.
Для webP используем pagespeed для nginx. Найти легко. Базовая настройка в 3 строки. webP будет отдаваться только тем браузерам которые умеют его показывать, остальные получат исходный формат. И делаем мы так уже года 2.
Это не любопытство. Пользователь зарегестировался и принял условия пользования моего приложения. И там есть разрешение собирать его ПД с девайса. А кто-то согласился и с GDPR.
Ну и условия использования моего приложения не позволяют им пользоваться приватно. Не устраивают условия — попрошу на выход.
Пользователь может запросить удаление своих ПД у нас в соответствии с законом указанным Вами. И тогда мы их удалим.
Так мне не нужно после удаления. Мне нужно после повторной установки узнать что этот пользователь мне уже знаком.
Если он удалит и не установит — я буду только рад.
email/sms — достать временные в интернете стоит чуть менее чем ничего.
Плата за регистрацию? — без комментариев.
>> Но если приложение будет удалено, а затем заново установлено — Android_ID будет разным
Это реально проверяли? В документации по другому написано. Для смены нужен factory reset или смена APK signing key
У нас тоже долго жрал очень много процессора. Но оказалось надо перечитать документацию и пересоздать таблицы с правильными индексами. Работать стало быстро, а потребление упало на порядок.
Ну общий каунтер в любом случае надо бы кешировать. Просто с умным фоновым обновлением кеша.
А с приличным tsdb вы получите много приятностей для аналитики. Например уникальные просмотры(по ip или user_id, смотря что вам надо). Ну или просмотры(уники и нет) но по целым разделам, а не по отдельным объявлениям. Менеджеры такое очень любят.
Ну и гляделки приятные из коробки типа grafana с ее алертами на бизнес метрики.
И еще. в clickhouse у вас все это будет занимать намного меньше места. Был опыт переноса просмотров с mysql -> clickhouse. На больших сроках и объема почти в 100 раз меньше места потребляет clickhouse
Это больше выполнение сценариев/скриптов/плейбуков. Просто потыкать команды и красиво увидеть их ответ — удобней будет tmux c кучкой панелей на одном экране. Или iTerm для тех у кого macos. В обоих есть broadcast input и горизонатльное/вертикальное разделение экрана.
Ну хорошо. Ничего не будем усложнять.
Что будет если содержимое файлика как-то повредится? Практика работы с amazons3 говорит что такое возможно, при частом изменении файла. Вы ведь регулярно что-то дописываете в конец.
Каким образом и как быстро вы об этом узнаете? Может ли такой поврежденный файл попасть в бекап?
Согласен. Использование принципа «отрезать все не нужно и сделать решение только под нашу стратегию использования», очень оправданно как оптимизация. Суровая оптимизация. Но это не очень удобно для развития сервиса.
Рассматривали решение с генерацией таких же ответов (charts/btc_eur/15m) на бекенде в апи и последующим кешированием в nginx? Заголовками передавать время жизни кеша (старые свечи за день можно кешировать на долгие месяцы). Период конечно придется задавать гет-параметром, но это не проблема для кеширования. По сути будут так же файлики с данными. Но создаются динамически и апи всегда из может создать из бд. Кеш nginx может хранить в memcache или просто на ram-диске.
Как бонус для ускорения разработки и тестирования можно установитьменьшее/нулевое время кеша.
При работе с tsdb вам не надо доставать ~500к свечей для графика за год. Можно достать свечи достаточной точности (за час/день/неделю) полученные агрегацией по времени из свечей за минуту. И такой JSON будет весить пару десятков килобайт.
Глянув код на сайте — вижу что вы создаете разные файлики для разных периодов свечей? т.е у вас заложен способ агрегации данных и при его изменении(добавлении или изменении чего-то) — только перегенерировать все свечи за 1h/4h/1d? Минимальная свеча у вас 15 минут?
56 байт на точку. Одна точка на минуту же? 1440 точек за сутки. 525600 точек за год. У вас есть реализация где это можно увидеть без тормозов?
29Мб данных для одного графика за год? А если нужно сравнение 2-4 графиков на одном канвасе?
Какая же жесть. Мы не будет использовать БД. Просто создадим файлики. А как у вас работает когда нужно достать график за год? Качаете все точки графики даже если они каждую минуту?
Посмотрите в сторону хороших решений для графиков. time series db — clickhouse|influxdb и много подобного. Работают быстро. Отлично шардятся.
Но один момент остался не ясен. Ваш монитор P2715Q — поддерживает 10-битную глубину цвета. Винда это называет разрядность. Получилось ли у вас ее активировать на вашем ноутбуке?
Для веб есть авторизация по OAuth.
Для ssh/sftp есть авторизация по ключам и орекстрация конфигов.
В облаках есть какие-нибудь Identity and Access Management и подобное.
Plain ftp/Basic auth просто похороните.
Если у сервиса нет безпарольной авторизации — оставляйте доступ только для офиса и все остальное закрывайте файерволом. Удаленщикам и любителям иногда работать из дома — vpn в офис с персональными учетками.
Ну и условия использования моего приложения не позволяют им пользоваться приватно. Не устраивают условия — попрошу на выход.
Пользователь может запросить удаление своих ПД у нас в соответствии с законом указанным Вами. И тогда мы их удалим.
Если он удалит и не установит — я буду только рад.
email/sms — достать временные в интернете стоит чуть менее чем ничего.
Плата за регистрацию? — без комментариев.
Это реально проверяли? В документации по другому написано. Для смены нужен factory reset или смена APK signing key
А с приличным tsdb вы получите много приятностей для аналитики. Например уникальные просмотры(по ip или user_id, смотря что вам надо). Ну или просмотры(уники и нет) но по целым разделам, а не по отдельным объявлениям. Менеджеры такое очень любят.
Ну и гляделки приятные из коробки типа grafana с ее алертами на бизнес метрики.
И еще. в clickhouse у вас все это будет занимать намного меньше места. Был опыт переноса просмотров с mysql -> clickhouse. На больших сроках и объема почти в 100 раз меньше места потребляет clickhouse
тут параметр -P20 — ограничивает выполнение 20 потоками.
Что будет если содержимое файлика как-то повредится? Практика работы с amazons3 говорит что такое возможно, при частом изменении файла. Вы ведь регулярно что-то дописываете в конец.
Каким образом и как быстро вы об этом узнаете? Может ли такой поврежденный файл попасть в бекап?
Рассматривали решение с генерацией таких же ответов (charts/btc_eur/15m) на бекенде в апи и последующим кешированием в nginx? Заголовками передавать время жизни кеша (старые свечи за день можно кешировать на долгие месяцы). Период конечно придется задавать гет-параметром, но это не проблема для кеширования. По сути будут так же файлики с данными. Но создаются динамически и апи всегда из может создать из бд. Кеш nginx может хранить в memcache или просто на ram-диске.
Как бонус для ускорения разработки и тестирования можно установитьменьшее/нулевое время кеша.
Глянув код на сайте — вижу что вы создаете разные файлики для разных периодов свечей? т.е у вас заложен способ агрегации данных и при его изменении(добавлении или изменении чего-то) — только перегенерировать все свечи за 1h/4h/1d? Минимальная свеча у вас 15 минут?
29Мб данных для одного графика за год? А если нужно сравнение 2-4 графиков на одном канвасе?
Мы не будет использовать БД. Просто создадим файлики. А как у вас работает когда нужно достать график за год? Качаете все точки графики даже если они каждую минуту?Посмотрите в сторону хороших решений для графиков. time series db — clickhouse|influxdb и много подобного. Работают быстро. Отлично шардятся.