Rolling Thunder Forums

http://gandalfgames.net/bbdb/api/matchd ... atch_id=21

This is a great example, and whilst I might have laid the data out differently, is probably enough to be getting started with. The one thing I miss from BBM is the match report images and I think we could certainly generate them from that data.

Going forward it would be useful to request other data like a list of matches, or list of teams, or details for a specific team. Pretty much an API for each page you have already. I don't know if that would be worth your while from a BBDB point of view? I've found that separating the API from the actual website very useful so far in bb-dugout (but don't actually have a lot to show for it).

If I did get more involved going forward, what would you prefer? I could probably produce a site completely separately from bbdb, that just requested data using an API that we dream up and you develop on request/as you feel like it. Or we could work on the same thing, but that would mean some kind of source control that you'd have to start using and the risk of me tinkering with your own code (and vice versa). I would suggest we start with option 1 and see how it goes?

It would be nice to see some kind of database schema, so that I can make reasonable requests for an API/plan ahead a bit (plus I'm just curious).

That example is just a dump from the match-team-stats there. If you look at it closely you can see there's room for some future expansion

The one thing I miss from BBM is the match report images and I think we could certainly generate them from that data.

Agreed! Yes please!

Going forward it would be useful to request other data like a list of matches, or list of teams, or details for a specific team. Pretty much an API for each page you have already. I don't know if that would be worth your while from a BBDB point of view? I've found that separating the API from the actual website very useful so far in bb-dugout (but don't actually have a lot to show for it).

Each time it'll mostly just be outputs from one or two tables. So tell me something you want (ie, that you have an idea for something to do) and I can sort it out. The web client & API will both be referencing the database in their own special ways.

If I did get more involved going forward, what would you prefer? I could probably produce a site completely separately from bbdb, that just requested data using an API that we dream up and you develop on request/as you feel like it. Or we could work on the same thing, but that would mean some kind of source control that you'd have to start using and the risk of me tinkering with your own code (and vice versa). I would suggest we start with option 1 and see how it goes?

Honestly, I'm nervous about source control, from a security point of view as much as anything. If you can show that you really seriously want to help in a reasonably substantial fashion then I can look into it. Your new child might slow down any work though!

We can go with option 1 for now, as I said in the other thread what would be most helpful for me is if you did some nice stuff in google charts that I could incorporate back in the main website (with credit given to you ofc). Or anything else really, happy to put your name on things. Also, match report images as you said... that would be cool. Don't go too overboard with other stuff. I wouldn't really want you creating a rival website.

It would be nice to see some kind of database schema, so that I can make reasonable requests for an API/plan ahead a bit (plus I'm just curious).

I have 33 lookup tables.... so much standing data.... and tedious to do. But very worthwhile now they are (mostly) done.

Apart from that though, most of the tables are what you'd expect (assuming you know what makes a good database scheme) & what you see on the front.

I also have "stat" tables, these are summarised derived information that people usually want in the summarised form. Currently I only have 2 things here, league tables (derived from match performances) and star player records (ie how many SPP's does Zara have?). There's a lot more to come here (most of the dice statistics for example).

One last thing, if this API is going somewhere then I'd like to sort out a bit of "doing it properly" - so giving you a key that you need to pass in your API calls that identifies who you are. I'm always trying to think, "what if 100,000 people started using it" when I design stuff for BBDB. So I wouldn't want free-for-all API access. Here's a good article on how not to design an API - I don't know who VTech were employing but anyone involved in it should be banned from working in IT ever again.

Gandalf wrote:Honestly, I'm nervous about source control, from a security point of view as much as anything. If you can show that you really seriously want to help in a reasonably substantial fashion then I can look into it. Your new child might slow down any work though!

I find this a little bizarre. Which security point of view are you talking about? Are you worried about people accessing or making changes to the code without your knowledge, or are you concerned about the security of the actual website? Using something like GitHub, my personal favorite at the moment, you have complete control over who is able to submit changes to your project. The free accounts are public, so anyone can view the code, but you can pay for private accounts if you don't want anyone you don't authorize to be able to see your code at all. If you are concerned about website security, then there is no such thing as security by obscurity.

Gandalf wrote:I have 33 lookup tables.... so much standing data.... and tedious to do. But very worthwhile now they are (mostly) done.

Apart from that though, most of the tables are what you'd expect (assuming you know what makes a good database scheme) & what you see on the front.

Excellent, sounds like a well designed system

Gandalf wrote:One last thing, if this API is going somewhere then I'd like to sort out a bit of "doing it properly" - so giving you a key that you need to pass in your API calls that identifies who you are. I'm always trying to think, "what if 100,000 people started using it" when I design stuff for BBDB. So I wouldn't want free-for-all API access. Here's a good article on how not to design an API - I don't know who VTech were employing but anyone involved in it should be banned from working in IT ever again.

Of course, I'd be up for doing it properly too. I'm currently quite interested in figuring out proper REST APIs, and have just implemented a JSON Web Token authentication system for bb-dugout. It sounds slightly different from what you want to do, i.e. limit access to the actual API rather than authenticate users for access to restricted parts of the API, but I'm sure it's pretty easy to sort out what you're after. I'd be happy to help.

id3nt1ty wrote:

Gandalf wrote:Honestly, I'm nervous about source control, from a security point of view as much as anything. If you can show that you really seriously want to help in a reasonably substantial fashion then I can look into it. Your new child might slow down any work though!

I find this a little bizarre. Which security point of view are you talking about? Are you worried about people accessing or making changes to the code without your knowledge, or are you concerned about the security of the actual website? Using something like GitHub, my personal favorite at the moment, you have complete control over who is able to submit changes to your project. The free accounts are public, so anyone can view the code, but you can pay for private accounts if you don't want anyone you don't authorize to be able to see your code at all. If you are concerned about website security, then there is no such thing as security by obscurity.

With database backend-ed websites you don't want to reveal the structure of the database to end users, it makes it easier to attack. And my pages are full of SQL statements that do just that.

Same reason why SQL error messages are not returned to the client by default.

then there is no such thing as security by obscurity.

Not entirely true. It should never be the only security measure, but it still helps.

Whilst API means nothing to me more than a cockney in a good mood, I'd be happy to help with making the images.

I've like to move away from the rustic feel of the BBM outputs to something that looks a bit more TV sportsy. Although once we figure out what goes where then the background image can be varied to give any number of different effects.

I suppose that the thing to decide on is:

• Which images we want.
• What information will be presented on each image.
• What size each image will be.
• The coordinates of each bit of information

I have no idea of what will go into making these things but I'm happy to help if I can.

Gandalf wrote:With database backend-ed websites you don't want to reveal the structure of the database to end users, it makes it easier to attack. And my pages are full of SQL statements that do just that.

Same reason why SQL error messages are not returned to the client by default.

Makes sense. If the database structure is going to be public knowledge then there should definitely be an API in front of it to limit what users are able to access.

Raveen wrote:Whilst API means nothing to me more than a cockney in a good mood, I'd be happy to help with making the images.

I've like to move away from the rustic feel of the BBM outputs to something that looks a bit more TV sportsy. Although once we figure out what goes where then the background image can be varied to give any number of different effects.

I suppose that the thing to decide on is:

• Which images we want.
• What information will be presented on each image.
• What size each image will be.
• The coordinates of each bit of information

I have no idea of what will go into making these things but I'm happy to help if I can.

I'd like to move away from that too.

My suggestion, and my current line of investigation, is that we use SVG images if possible. The advantages are:

• they look great at any resolution, and are easy to resize;
• they are just text, so easy to store in a database for example (although binary blobs could be used for bitmaps), and easy to edit;
• they potentially can be reused for actual web pages, with the option for animation and clickable elements;
• things we mock up are easy to convert into computer generate images, because the coordinates etc are all their already.

So, if we decide the images we want, and the information that goes in them, people could use pen and paper, inkscape or illustrator to design mock ups that we can discuss/vote on?

Wow.

I actually just read all of that.

I have a picture of Percy you can use.

So, the data we currently have access to is:
team names;
team races;
number of touchdowns;
ball possession;
pitch occupation;
passes;
catches;
interceptions;
knockdowns;
tackles;
KOs;
injuries;
deaths;
metres run;
metres passed.

More than enough for a match report image, so I suggest we start with that.

As for other images, a dice stats image would be great I think. I also like Daigaro's idea of a team image laid out on half a pitch, but that would probably be a bit more difficult to show stats and skills, so an additional team stats image?

Two to add to the list.
- Block rolls done (because of re-rolls, this is not the same as blocks attempted) I'm pretty confident that this stat is correct
- Team logo (stored in the database; not yet displayed on website)

Thought it would be worth testing if SVGs even work on the forum...

A quick sketch of what such a match image might look like.

I like the graphs I have on the website at the moment - the "100%" ones, like they have on the BBC website. However I like yours too especially how the middle is used.

One thing I like about the 100% graphs is that you can easily see who had the most of any category. Perhaps your mock-up could do this by colouring the "winner" in each category in a certain colour to make it obvious.

I was wondering about the bar graphs in the sketch, they could either be percentage graphs, or they could use the same scale. They would be coloured per team, of course.

Any chance we can get the names of the players who scored? And the half time score? I quite like the one at the top of the BBC match page (and there just happens to be a player called Knight-Percival on the one I picked) http://m.bbc.co.uk/sport/football/35509584

Also, what about different images? I kind of like the idea of one that is just the top part, showing the league, teams, coaches, scorers with a separate one to show the stats. They could of course be combined. Then the coach writing the report gets to choose which images or combination thereof to use in his report. For example, starting with the main score image, writing a bit of report, then following up with some stats/dice analysis below. It would at least let us break up the walls of text we write sometimes.