As I’m one of the guys interested in the UI/API part of the project I thought I’d get the ball rolling here with some stuff. Feel free to correct me on anything or of course let me know what you think. This is a bit of a brain dump so apologies if it doesn’t make sense.
Firstly, let me confirm what this part of the project is responsible for in the main:
A Restful API for receiving data from a runner. The format for this needs to be defined.
Store the received data from the runner for each run.
Aggregate (do some Maths such as averaging etc) on the numbers and display results to users in the form of graphs and table data.
Some details to consider:
Should we allow admin type users to be able to register a runner on the app and then present some kind of API token for that runner to use when sending data? We can use this token to identify the runner and allow access. Maybe we can manage the runner machine specs from within the app (UI) rather than the runner reporting them. I guess we are only going to display the runner machine specs to users for information so will be easier to manage from the app. If this is the case, we can allow an admin to reset the access token and manage the machine specs. With this we will give the option of separating results for different machine specs. Need to work out the details here.
There was talk of building the front-end in Ember with it connecting to data through the API. I’m in two minds about this. On the one hand it would be good to expose the data through an API so anyone can use it and have a separate UI app which keeps the API and UI separate. I wonder if user Ember (and having a separate UI app) is overkill as I imagine the UI will be relatively simple. We want to make it as easy as possible for others to contribute so I wonder if introducing Ember will be an extra barrier for some people. We can always expose the data through an API anyway. Interested in your thoughts on this one.
UI wise I was thinking about just starting off using Twitter Bootstrap to get us started. If we get someone with some design skills we can change the UI later to be super cool :o)
I guess we can’t really progress until we have the runner data format spec’ed out. I’m happy to start the UI/API project when we are ready. Is there anything worth starting now? Maybe some basics like runner management (above)? My github username is andypike so @sam, could you add me to the organisation at some point?
I’ve created an initial project with a first spec just to make sure everything is wired up right. I’ve pushed this up and will make a start on the API for receiving runner results.
If anyone is has any input then please let me know, just making a start and we can always change things we don’t like
I’m going to be working in branches from now on and then issuing a PR for the team to review. If you’re interested, I’m working on the initial API for receiving results from the runner. Here is the branch at the moment: https://github.com/ruby-bench/ruby-bench/tree/recieve_results once I’m happy with it then I’ll create a PR.
I think the process for development should be:
Create a branch for your feature
Send a PR with details of change
Team (at least one person) reviews and comments/thumbs if all is good
When you get a you can merge into master
Delete your branch
If this is cool with everyone then I’ll add something in the readme.
Just an update. As I work on the API I feel that having the runner data (hardware etc) in the request is a bit messy. So I’m going to take that out. Instead you just pass an id/token of your runner that the api knows about. It will find that runner and attach the results to it. It’ll make things a lot simpler so I’ll bang it in now for you guys.
@andypike: what you’ve done is awesome. I just left you a few comments there.
Thank you!
I’ll have some time this sunday. Let me know if you want me to give you a hand in finishing up this PR.