Comments (6)
I think all data
isn't too useful in that context as the collaboration chart has no time axis.
from hubble.
@filmaj: @larsxschneider and I reconsidered this. We now think that multiple URLs have drawbacks of their own (for instance, multiple HTTP requests per chart and cluttering hubble-data
storage).
Also, I came to the conclusion that storing multiple matrices inside the same data file might not be problematic. As @larsxschneider pointed out, they arenโt human-readable (or at least usable in a spreadsheet editor), as opposed to the history and list charts. Additionally, the header of each matrix contains as many columns as there are rows following. In this way, our parser will know exactly how many lines of text to expect and where each of the matrices begins and stops.
So, Iโm working on the client-side slicing implementation now ๐. Thanks for the feedback, @filmaj!
from hubble.
Does it make sense to 'split' the data by time chunks up using different URLs / tsv files? What about doing the slicing on the client side?
from hubble.
@filmaj: That would be desirable, I agree. But the collaboration chart data is a matrix and not a simple key/value TSV file like the others. As putting multiple such matrices in the same TSV file would get confusing and difficult to parse, we thought it best to have multiple data files in this particular case.
With that said, we want to keep the data slicing on the client side for the other charts and resort to multiple data files only when necessary.
from hubble.
Cool! Yeah some larger monitoring / visualization systems, like Grafana or Kibana, when dealing with massive amounts of data, use the 'query relevant slice of data from the server' approach. Smaller visualization systems (like the Chart.js library we use) assume we have all of the data up front and slice up on the client side. So I guess following this trend, the decision should basically come down to how much data do we expect Hubble to handle at a time. I have a feeling this requirement could change over time, but that's a worry for Future Us.
from hubble.
@filmaj: For the medium-term future, I think that it is reasonable safe to assume that there are only few, small, quick-to-process data files per HTML page. The collaboration chart might be an exception, but I think it should still be manageable by browsers with three views. Also, I think that we wonโt have a much more complex chart in the foreseeable future ๐.
from hubble.
Related Issues (20)
- Feature Request: Adding Search Analytics
- Monitor successful backup runs HOT 1
- GHE - Hubble implementation, not able to view dashboard HOT 13
- Versions chart broken if load balancer is used? HOT 2
- Cannot parse missing logs after upgrade - KeyError http HOT 2
- List number of deleted repos / archived_repositories
- How to make hubble work for an org on github.com? HOT 3
- Security vulnerabilities found HOT 3
- Hubble install issues HOT 6
- Count number of noop fetches
- Use admin SSH key for data repo
- Enable remote run with docker
- New report for Failed Authentication and menu organization HOT 2
- Does Hubble support gitlab and how to configure it๏ผ HOT 1
- Multiple issues after upgrade to GHES 3.0.8 HOT 8
- Issue while running the code on 3.1.0 HOT 3
- Feature Request: Organization Activity Aggregates HOT 5
- ReportRepoSize not working after 3.x upgrade. HOT 3
- Recommended Git Versions: Update git version database so statistics are reflected correctly
- Feature Request: Templatize `dataUrl` and `footer`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hubble.