Jump to content

rjfryman log #9


rjfryman

Recommended Posts

Well so this week a lot of things that were cool and exciting.

 

Project Hourglass got started and the research went really well. Still working on some of the data entry but from my standpoint, one of the biggest things in the way which is the research and planning was a smashing success. Data Entry is something no one loves but I think seeding the database will be a good start and will allow the project to run smoothly in the future.

 

I was asked to help with the VHL GM Games. This is a good opportunity to create some of the views and partials that will be used in Hourglass and get some general feedback from the community about the look and feel of some of the things. This also is a great test of some of the parsing that will have to take place for project hourglass. Honestly one of the issues with going through all the previous index's is that there a number variations of the schedule but there seem to only be two or three different game views. which is a great thing, because I will only have to check which version it is then able to run it through one of two or three standard parsers that I can create. 

 

There also some interesting choices I have to make for long term success in the project. There are multiple ways to tackle the way to store stats and player attributes. 

 

For player attributes the issue is that there are really two different types of player attributes. The question is do I want to use jsonb on either the player itself or even a separate player attribute model that I can also store data like the timedate or other context saver of the player attribute so that you can see historical players at different parts in their career. which would end up making me go toward a separate player attribute model but I think for the purposes of the GM Games I think simply putting them on the player will be sufficient. 

Also there is a question of how deep do I want to go with stats. So with all Seasons Pre-18 the problem is that they do not have season by season stats other than Hall of Famers. Once we hit S18 since I have the index itself I can grab all data even from the games. I like the idea of having as much data as possible but one of issues that I have run into is that I I found an interesting way to handle all the game data. Ruby has some great text parsing and I can simply save all of the data in a text format and simply parse them when needed, instead of parsing them and saving them in the database to then formate them later. I'll need to do some research on both to see how the data impacts performance once a large sum of data is in the database and how quickly the opposing ways will impact performance. I want to build things that will stand the test of time while also not having too much duplication of data in the database.

 

(534 Words) Using as a Media but doesn't feel like a Media

Edited by rjfryman
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...