4) Звучит интересно, это нужно для сбора какой-то дополнительной информации аля google analytics?
5) Над этим и сам думал, но решил подождать отклика на базовую версию — вдруг это вообще было никому не нужно.
1) Вот рейтинги постов — это очень важная информация.
Так они же и реализованы по оси Х — даты публикации постов
или я не правильно понял эту часть комментария?
2) я бы сделал так: свел бы в один график: просмотры, рейтинг, избранное и суммарные репосты. подключаемыми слоями — репосты по соцсетям и график получения плюсов и минусов. Еще бы сделал две временных шкалы — одна по времени с публикации поста, вторая — с временем и датой по москве(хочется все-таки собрать статистику по лучшему времени и дням публикации, но не глобальную, а по своим постам.)
В принципе выглядит реализуемо, единственное, мне тут предлагают вообще визуализацию переделать, поэтому я пока подожду с добавлением сложной логики.
3) в диаграммы виена и аудиторию хабов надо бы добавить корпоративные блоги, потому что там самое интересное.
Вот тут я чуть-чуть поленился и перенес часть кода из standalone приложений, и на хабы компаний уже не хватило сил. Эту часть надо бы переписать под Heroku и добавить хабы компаний.
Думал над чем-то подобным, в духе: премиум-аккаунты с хранением всей информации и дополнительными фичами, но тогда моя персональная ответственность перед пользователями невероятно возрастет.
Сейчас, если уронить сервер на часик другой, то никакой трагедии не произойдет (у меня всё-таки вообще нет опыта веб-разработки), а если у меня будут пользователи, которые платят деньги за работу сервиса, то придется работать уже совсем на другом уровне и нести перед ними ответственность за корректную работу приложения.
Если просто нужны данные по прошлым статьям (например, просмотры за неделю по индексированным статьям), то могу их периодически скидывать себе на жесткий диск — это не проблема, проблема их постоянно держать в базе данных и постоянно обновлять. Если количество статей в пуле растет — значит растет время на одно обновление, растет время запроса интерфейса, растет память в БД — в общем, мой карточный домик плохо масштабируется.
У меня есть идея получше — администрация мне уже выдаст токен API (рано или поздно) и я выпущу standalone монитор с авторизацией, каждый сможет себе столько закачать информации сколько захочет, по любому количеству статей (ну в пределах допустимых ресурсов).
Ещё опция, если у кого-нибудь есть лишний сервер с базой данных, то можно мне создать пользователя и сборщик данных через этого пользователя будет скидывать данные.
Этот аргумент предполагает наличие подобного знания у всех участников сообщества, а мои статьи по анализу данных набирают в среднем 10к просмотров, и это ооочень маленький сегмент аудитории Хабра.
А можно будет реализовать аналитику по статьям — которые выложены давно?
Монитор опрашивает хабр каждые N минут, отсюда и данные для визуализации. По старым статьям, таких данных, к сожалению, нет. Хм, интересно, а нет ли у администрации?
Сейчас насколько я понял только последние публикации можно проанализировать, не более чем за 52 часа.
Это исключительно техническое ограничение, бюджет инфраструктуры — 0р0к, поэтому используется бесплатная DB as a Service, у неё ограничение на размер базы в 512МБ. Из-за этого очень осторожно использую место, теоретически можно попробовать увеличить время хранения и посмотреть хватит ли на всё. Поэкспериментирую на неделе.
Проверил и оказалось, для компаний граница массива вычислялась неверно (сдвиг на единичку там, где его быть не должно) — поправил, попробуйте вот эту версию: hubs.exe
5) Над этим и сам думал, но решил подождать отклика на базовую версию — вдруг это вообще было никому не нужно.
Так они же и реализованы по оси Х — даты публикации постов
или я не правильно понял эту часть комментария?
В принципе выглядит реализуемо, единственное, мне тут предлагают вообще визуализацию переделать, поэтому я пока подожду с добавлением сложной логики.
Вот тут я чуть-чуть поленился и перенес часть кода из standalone приложений, и на хабы компаний уже не хватило сил. Эту часть надо бы переписать под Heroku и добавить хабы компаний.
Сейчас, если уронить сервер на часик другой, то никакой трагедии не произойдет (у меня всё-таки вообще нет опыта веб-разработки), а если у меня будут пользователи, которые платят деньги за работу сервиса, то придется работать уже совсем на другом уровне и нести перед ними ответственность за корректную работу приложения.
У меня есть идея получше — администрация мне уже выдаст токен API (рано или поздно) и я выпущу standalone монитор с авторизацией, каждый сможет себе столько закачать информации сколько захочет, по любому количеству статей (ну в пределах допустимых ресурсов).
Ещё опция, если у кого-нибудь есть лишний сервер с базой данных, то можно мне создать пользователя и сборщик данных через этого пользователя будет скидывать данные.
Монитор опрашивает хабр каждые N минут, отсюда и данные для визуализации. По старым статьям, таких данных, к сожалению, нет. Хм, интересно, а нет ли у администрации?
Это исключительно техническое ограничение, бюджет инфраструктуры — 0р0к, поэтому используется бесплатная DB as a Service, у неё ограничение на размер базы в 512МБ. Из-за этого очень осторожно использую место, теоретически можно попробовать увеличить время хранения и посмотреть хватит ли на всё. Поэкспериментирую на неделе.
pypi.python.org/pypi/matplotlib-venn
Если подробнее, то что-то интересное тут видел:
www.brynmawr.edu/math/people/anmyers/PAPERS/Venn.pdf
Это очень маленький сервер пытается обслужить сразу кучу* пользователей и поэтому на ладан дышит
*больше двух
Проверил и оказалось, для компаний граница массива вычислялась неверно (сдвиг на единичку там, где его быть не должно) — поправил, попробуйте вот эту версию: hubs.exe
Сейчас диаграмма выглядит так (клибельно):