I'm developing on a game currently. It's a capitalism game of sorts, buying, selling, quests and such.
As I develop features, stores and items and things. I know I'm eventually going to want to put all this hardcoded data somewhere. In development, it's currently being fed into the database via db/seeds.rb. Is there a better place to put the data that I know will be static in production? Really the only data that is going to be changing dynamically is data having to do with users and join tables between users and the static data.
In past applications I've put a bit of static data in migrations, but this games static data will be significantly more than when I did that. Is there a best practice for this?
Here's some example data in db/seeds.rb that I think might have a better home:
pencil = Item.create(name: "pencil", value: 2, karma: 0)
lemon = Item.create(name: "lemon", value: 4, karma: 0)
pog = Item.create(name: "pog", value: 2, karma: 0)
child_store_items = [pencil, lemon, pog]
child_store = Store.create(name: "KB Toystore", karma: nil, min_age: 0)
child_store_items.each do |item|
StoreItem.create(store: child_store, item: item, quantity: 30)
end
school_quest = Quest.create(reward: 50, req_age: 0, req_time: 5, description: "learn all the things", title: "go to school")
school_quest_req = QuestItemRule.create(item: pencil, quantity: 3, quest: school_quest, rule: QuestItemRule.rules[:requirement])
Nothing wrong with having a config table in your database, but it's a bit overkill.
You can use a gem like railsconfig for application configuration. If you're talking about model configuration, where you have different constants or collections for different use cases, then I'd recommend creating a class for that whose methods return the values you need, itself optionally and/or partially setup with the help of a configuration gem. Depending on the nature of your static data, i18n might be useful here, too.
Perhaps you could store those things in YAML files...
Here is a YAML tutorial
Related
Is there a way to use x,y coordinates stored as attributes of each node to layout a graph using the coordinates that were calculated by another program?
And if not, would it be possible to implement this somehow - how does one get started on this?
Is there a standard way how to provide the node positions to the cytoscape.js web viewer somehow?
Background: it is trivial to use Python networkx to calculate some layouts which are not supported in Cytoscape, and it would also be trivial to store the coordinates as node attributes. All that would then be need is some way for Cytoscape to use those coordinates to find node positions instead of using a layout algorithm.
This is a quite easy thing to do. Many examples on use this functionlity in the demos, as you can see here:
1: FCose Demo
2: Cose Blicent Demo
3: d3-force Demo
4: Euler Compound Demo
5: Spread Demo
As you can see, there are an abundance of examples for this in the demos, but also in the docs. You can see one here and here:
// can use reference to eles later
var eles = cy.add([
{ group: 'nodes', data: { id: 'n0' }, position: { x: 100, y: 100 } },
{ group: 'nodes', data: { id: 'n1' }, position: { x: 200, y: 200 } },
{ group: 'edges', data: { id: 'e0', source: 'n0', target: 'n1' } }
]);
The json used in the .add() function can be created in your js application or directly in Python and added to the graph as some of the examples do.
In general, you should take some time and skim through through the docs. The ability to position nodes via x and y is quite basic and is one of the first pages in the docs.
If you don't understand the description in the docs and the examples I provided, please edit your question and add your current code as a Minimal, Reproducible Example, where you can show your efforts to implement the positioning.
Edit:
As #maxkfranz pointed out, the preset layout plays a big role here. The documentation states this in the Initialisation Chapter:
If you want to specify your node positions yourself in your elements JSON, you can use the preset layout — by default it does not set any positions, leaving your nodes in their current positions (i.e. specified in options.elements at initialisation time).`
I am new to using Cytoscape so things that are "easy" are not so easy for me. I often don't even know the right way to ask a question. Everyone has things that are hard and things that are easy, and step by step we expand our knowledge so what is hard today may be easy tomorrow.
Anyway, here is something that may be a part of the solution you are looking for:
In the Cytoscape desktop application, you can create a "Style" that maps a node attribute to "X Location" and another node attribute to "Y Location".
It has taken me quite a long (calendar) time to get my head around CouchDB and map/reduce and how I can utilize it for various use cases. One challenge I've put myself to understanding is how to use it for normalized data effectively. Sources all over the internet simply stop with "don't use it for normalized data.". I do not like the lack of analysis on how to use it effectively with normalized data!
Some of the better resources I've found are below:
CouchDB: Single document vs "joining" documents together
http://www.cmlenz.net/archives/2007/10/couchdb-joins
In both cases, the authors do a great job at explaining how to do a "join" when it is necessary to join documents when there is denormalized commonality across them. If, however, I need to join more than two normalized "tables" the view collation tricks leveraged to query just one row of data together do not work. That is, it seems you need some sort of data about all elements in the join to exist in all documents that would participate in the join, and thus, your data is not normalized!
Consider the following simple Q&A example (question/answer/answer comment):
{ id: "Q1", type: "question", question: "How do I...?" }
{ id: "A1", type: "answer", answer: "Simple... You just..." }
{ id: "C1", type: "answer-comment", comment: "Great... But what about...?" }
{ id: "C2", type: "answer-comment", comment: "Great... But what about...?" }
{ id: "QA1", type: "question-answer-relationship", q_id:"Q1", a_id:"A1" }
{ id: "AC1", type: "answer-comment-relationship", a_id:"A1", c_id:"C1" }
{ id: "AC2", type: "answer-comment-relationship", a_id:"A1", c_id:"C2" }
{ id: "Q2", type: "question", question: "What is the fastest...?" }
{ id: "A2", type: "answer", answer: "Do it this way..." }
{ id: "C3", type: "answer-comment", comment: "Works great! Thanks!" }
{ id: "QA2", type: "question-answer-relationship", q_id:"Q2", a_id:"A2" }
{ id: "AC3", type: "answer-comment-relationship", a_id:"A2", c_id:"C3" }
I want to get one question, its answer, and all of its answer's comments, and no other records from the databse with only one query.
With the data set above, at a high level, you'd need to have views for each record type, ask for a particular question with an id in mind, then in another view, use the question id to look up relationships specified by the question-answer-relationship type, then in another view look up the answer by the id obtained by the question-answer-relationship type, and so on and so forth, aggregating the "row" over a series of requests.
Another option might be to create some sort of application that does process above to cache denormalized documents in the desired format that automatically react to the normalized data being updated. This feels awkward and like a reimplementation of something that already exists/should exist.
After all of this background, the ultimate question is: Is there a better way to do this so the database, rather than the application, does the work?
Thanks in advance for anyone sharing their experience!
The document model you have is what I would do if I'm using traditional relational database, since you can perform joins more naturally with those ids.
For a document database however, this will introduce complexity since 'joining' document with MapReduce isn't the same thing.
In the Q&A scenario you presented, I would model it as follow:
{
id: "Q1",
type: "question",
question: "How do I...?"
answers: [
{
answer: "Simple... You just...",
comments: [
{ comment: "Great... But what about...?" },
{ comment: "Great... But what about...?" }
]
},
{
answer: "Do it this way...",
comments: [
{ comment "Works great! Thanks!" },
{ comment "Nope, it doen't work" }
]
}
]
}
This can solve a-lot of issues with read from the db, but it does make your write more complex, for example when adding a new comment to an answer, you will need to
Get the document out from CouchDB.
Loop through the answer and find the correct position, and push comment into the array.
Save document back to CouchDB.
I'd only consider to spit the answer as a separate document if there's a-lot of them (e.g. 1 question yield 1000 answers'), otherwise it's easier to just package them in a single document. But even in that case, try putting the relationship info inside the document, e.g.
{
id: "Q1",
type: "question",
question: "How do I...?"
}
{
id: "A1",
type: "answer",
answer: "Simple... You just..."
question_id: "Q1"
}
{
id: "C1",
type: "comment",
comment: "Works great! Thanks!"
answer_id: "A1"
}
This can make you'r write operation easier but you will need to create view to join the documents so it returns all documents with one request.
And always keep in mind that the return result from a view is not necessary a flat structure like rows like in sql query.
Disclaimer: I'm a novice.
I want to simulate a join for my mongodb embedded document. If I have an embedded list:
{
_id: ObjectId("5320f6c34b6576d373000000"),
user_id: "52f581096b657612fe020000",
list: "52f4fd9f52e39bc0c15674ea"
{
player_1: "52f4fd9f52e39bc0c15674ex",
player_2: "52f4fd9f52e39bc0c15674ey",
player_3: "52f4fd9f52e39bc0c15674ez"
}
}
And a player collection with each player being something like:
{
_id: ObjectId("52f4fd9f52e39bc0c15674ex"),
college: "Louisville",
headshot: "player.png",
height: "6'2",
name: "Wayne Brady",
position: "QB",
weight: 205
}
I want to end up with:
{
_id: ObjectId("5320f6c34b6576d373000000"),
user_id: "52f581096b657612fe020000",
list: "52f4fd9f52e39bc0c15674ea"
{
player_1:
{
_id: ObjectId("52f4fd9f52e39bc0c15674ex"),
college: "Louisville",
headshot: "player.png",
height: "6'2",
name: "Wayne Brady",
position: "QB",
weight: 205
},
etc...
}
}
So I can call User.lists.first.player_1.name.
This is what makes sense in my mind since I'm new to rails...and I don't want to embed players in each user's list because I'd have so many redundancies...
Advice? Is this possible, if so how? Is it a good idea, or is there a better way?
So have have a typical relational model, let's call it "one to many", which you have users or "user teams" and a whole pool of players. And in typical modelling form you want to "de-normalize" this to avoid duplication.
But here's the thing, MongoDB does not do joins. Joins are not "webscale" in the current parlance. So it leaves you thinking what to do. Or does MongoDB do joins?
db.eval(function() {
var user = db.user.findOne({ "user_id": "52f581096b657612fe020000" });
for ( k in user.list ) {
var player = db.player.findOne({ "_id": user.list[k] });
user.list[k] = player;
}
return user;
});
Which "arguably" is "kind of a join". And it was all done on the server, right?
But DO NOT DO THAT. While db.eval() has uses, something that you are going to query regularly is not one of the practical uses. Read the documentation, which shows the warnings. In particular, all JavaScript is running in a single thread so that will lock things up very quickly.
Now client side, you are more or less doing the same thing. And you ODM of choice is likely again doing "the same thing", though it is usually hiding it away in some manner so you don't see that part. Likewise the same could likely be said of your SQL ORM, which was also "sneaking off behind your back" and querying the database while you just accessed the objects in your code.
As for mapReduce. Well the problem with the data you present is that there is nothing to "reduce". There is a technique known as in "incremental mapReduce" but it would not be well suited to this type of data. A topic in itself, but you would basically need all the "users" associated to the "players" as well, stored in the "player data" to make that any kind of viability. And it's ultimately just another way of "cheating" joins.
This is the space in which MongoDB exists.
So rather than going and doing all this fetching or joining, it allows the concept of being able to "pre-join" your data as it were. And the point of this is to allow faster, and more atomic reads and writes. And this is known as embedding.
Looking at your data, there should not be a problem with embedding at all. Consider the points:
Presumably you are modelling "fantasy teams" for a given user. It would be fair to day that a "team" does not consist of an infinite number of players.
Aside from other things your "A1" usage is likely to be "displaying" the players associated with that "user team". And in so much as, you want to "display" as much information as possible, and keep that to a single read operation. You also want to easily add "players" to the "user team".
While a "player" may have "extended information", and possibly even some global statistics or scores, that information may well be not what you want to access, while associated to the "user team" that often. It can probably be written independently, and only read when looking at the "player detail".
Those are three good cases to support embedding. Sure you would be duplicating information stored against each user team, opposed to just a small "key" reference. And sure that information is likely to exist elsewhere in the full "player detail" and that would be duplication as well.
But the point of the "duplication" here is to optimize. So here it would seem valid to embed "some of the data", not all, but what you regularly use in your main operations. Considering the "player's" name, position, height and weight are not likely to change on a regular basis or not even at all in the context, then that seems a reasonable trade-off.
{
"_id": ObjectId("5320f6c34b6576d373000000"),
"user_id": ObjectId("52f581096b657612fe020000"),
"list": [
{
"_id": ObjectId("52f4fd9f52e39bc0c15674ex"),
"label": "Player1",
"college": "Louisville",
"headshot": "player.png",
"height": "6'2",
"name": "Wayne Brady",
"position": "QB",
"weight": 205
},
{
"label": "Player2",
(...)
}
]
},
That's not that bad. And it would take a lot to break the 16MB limit. And considering this seems to be a "user team" then it could probably do with some information from the "user" as well.
You also get a lot of power out of this when data is kept together like this, to find the top "player" picked by each user:
db.userteams.aggregate([
// Unwind the array
{ "$unwind": "$list" },
// Group and use the player name
{ "$group": {
"_id": {
"user_id": "$user_id",
"player": "$list.name",
},
"count": { "$sum": 1 }
}},
// Sort the results descending by popularity
{ "$sort": { "_id.user_id": 1, "count": -1 } },
// Group to limit the first one
{ "$group": {
"_id": "$_id.user_id",
"player": { "$first": "$_id.player" },
"picks": { "$first:" "$count" }
}}
])
Which admittedly is a reasonably trivial use of a name in this case, but it is an example of using information that has become available by the use of some embedding.
Of course you really believe that you need everything to be properly normalized, then do it that way, and live with the patterns you would need to access it. But this offers a perspective of doing this another way.
So don't over-concern yourself with embedding everything, and lose a little fear on embedding some things. There are no "get out of jail free cards" for using something not suited to relational modeling in a standard relational way. Choose something that suits your needs.
I'm investigating building a mobile app with trigger.io, but I'm not finding good documentation on local database options. My app will send data to an external API, but needs to be able to store data locally as a draft (if the user is offline, the API is unavailable, whatever).
I see that there's a prefs module for storing data, but it does not seem like the right thing (correct me if I'm wrong). What options are recommended here? Is there something analogous to the SQLite plugin for PhoneGap, perhaps?
This probably depends on what your usage patterns are going to be.
For example, forge.prefs could get a bit fiddly if you want to do any kind of interesting queries, but could work well if you just want to persist a single JavaScript object structure. Using window.localStorage is likely to have similar pros/cons.
Alternatively, you can use the WebSQL API in your JavaScript: http://docs.trigger.io/en/v1.4/release-notes.html#v1-3-5. You don't need to use a module for this, it should work for any Android or iOS app built with Forge. This essentially gives you an SQLite database accessible from JavaScript. To give you a feel for the API, here's an example:
// create db
var db = openDatabase('mydb', '1.0', 'example database', 2 * 1024 * 1024);
db.transaction(function (tx) {
tx.executeSql('CREATE TABLE IF NOT EXISTS foo (id unique, text)');
tx.executeSql('INSERT INTO foo (id, text) VALUES (1, "foobar")');
});
// query db
db.transaction(function (tx) {
tx.executeSql('SELECT * FROM foo', [], function (tx, results) {
var rows = results.rows;
for (var i = 0; i < rows.length; ++i) {
forge.logging.info("row text: " + rows.item(i).text);
}
});
});
You should be able to find some tutorials about on the web!
I want to mock/stub:
#the_bill = GovKit::OpenCongress::Bill.find_by_idents("112-s368").first
for use in my tests.
which returns the following object that i would like to fix for the purpose of my tests:
--- !ruby/object:GovKit::OpenCongress::Bill
bill_type: s
co_sponsors:
- !ruby/object:GovKit::OpenCongress::Person {}
id: 68340
introduced: 1297836000
most_recent_actions:
- result:
created_at: "2011-02-17T07:45:50Z"
govtrack_order:
amendment_id:
text: Read twice and referred to the Committee on Agriculture, Nutrition, and Forestry.
date: 1297836000
how:
id: 287979
vote_type:
type: BillAction
roll_call_id:
action_type: action
datetime: "2011-02-16T00:00:00Z"
where:
bill_id: 68340
roll_call_number:
- result:
created_at: "2011-02-17T07:45:49Z"
govtrack_order:
amendment_id:
text:
date: 1297836000
how:
id: 287978
vote_type:
type: BillAction
roll_call_id:
action_type: introduced
datetime: "2011-02-16T00:00:00Z"
where:
bill_id: 68340
roll_call_number:
number: 368
plain_language_summary:
recent_blogs: []
I've tried Factory_girl (can't do it, not model based object), Fabrication (still same issues) and OpenStruct, probably possible, but had trouble converting yaml to OpenStruct and getting the mock in the right place.
Right now, i'm doing the api call in my tests, not what i want. I am thinking webmock is my solution, but I couldn't find out in the docs how to just load a simple object.
Try VCR for mocking out an API. I had the exact same question about 6 months ago and only recently discovered this library. It does exactly what you need, will cache the objects for testing later, but can also automatically refresh them on regular intervals. So far it's hands down the best solution I've found for this.