Get your data from a text file, maybe YAML which is like XML, only much more friendly.
I’m confused, you’re talking about data for a tic-tac-toe game, which should be stored in YAML? I got a tad confused because YAML sounds like HAML and I’d just been reading about HAML, then I realized I’d never used XML and didn’t even realize what it was for, so I tried to see if it was related to HTML which I’ve used a lot of, but it looks like it’s not, it’s just a way to format text files so that programs/scripts can import data from them. HAML on the other hand is a prettier version of ERB which is a way/template to use Ruby to make HTML use variables. So HAML is this thing I shouldn’t be using yet because it’s complicated and I should be focusing on Sinatra/Ruby whereas YAML I should start using eventually because it’s a way to format data for easy interpretation by ruby scripts and the like. Or did you mean YAML should be used for other things? Am I totally off?
No, something like tic-tac-toe has a bounded set of data to keep track of, no database or other long-term storage required.
Once you’ve mastered tic-tac-toe or the like the next kind of Web app you’re likely to tackle is one with an unbounded data set: for instance, a list of user accounts, or a list of posts and comments. Data like this should survive shutting down and restarting your server.
The traditional approach is to use MySQL to store this kind of data, but I would advise against getting a premature interest in MySQL, as there’s a risk that doing so will warp your thinking. YAML is an alternative for storing such data that would keep you more in the Ruby world.
All four of HTML, XML, YAML and HAML share the two initials ML—they’re all “markup languages”. It’s easy to get confused because the differences between them are minute, in the grand scheme of things, and only relevant to people who care so deeply about what tools they work with that it magnifies the differences.
The one you can’t do without is HTML, so it makes sense to use only that for a little while. (Actually in the past few years HTML has been redefined as a dialect of XML, so using it means you’ll also be using XML.)
Using HAML makes a lot of sense, but there’s also a bias it (and ERB, and every similar templating language) induces that you want to be aware of. When you start using these things you start thinking of your generated Web pages as “documents with Ruby variables”.
This is fine for some class of features but it will wreck your design skill if you generalize the approach too eagerly. Some (indeed many) portions of a significant Web app should be thought of as Ruby objects with the ability to output a HTML representation of them. Things like row/column tables; menus; data entry forms; recursively nested structures like LW comment threads; and so on.
I’m confused, you’re talking about data for a tic-tac-toe game, which should be stored in YAML? I got a tad confused because YAML sounds like HAML and I’d just been reading about HAML, then I realized I’d never used XML and didn’t even realize what it was for, so I tried to see if it was related to HTML which I’ve used a lot of, but it looks like it’s not, it’s just a way to format text files so that programs/scripts can import data from them. HAML on the other hand is a prettier version of ERB which is a way/template to use Ruby to make HTML use variables. So HAML is this thing I shouldn’t be using yet because it’s complicated and I should be focusing on Sinatra/Ruby whereas YAML I should start using eventually because it’s a way to format data for easy interpretation by ruby scripts and the like. Or did you mean YAML should be used for other things? Am I totally off?
No, something like tic-tac-toe has a bounded set of data to keep track of, no database or other long-term storage required.
Once you’ve mastered tic-tac-toe or the like the next kind of Web app you’re likely to tackle is one with an unbounded data set: for instance, a list of user accounts, or a list of posts and comments. Data like this should survive shutting down and restarting your server.
The traditional approach is to use MySQL to store this kind of data, but I would advise against getting a premature interest in MySQL, as there’s a risk that doing so will warp your thinking. YAML is an alternative for storing such data that would keep you more in the Ruby world.
All four of HTML, XML, YAML and HAML share the two initials ML—they’re all “markup languages”. It’s easy to get confused because the differences between them are minute, in the grand scheme of things, and only relevant to people who care so deeply about what tools they work with that it magnifies the differences.
The one you can’t do without is HTML, so it makes sense to use only that for a little while. (Actually in the past few years HTML has been redefined as a dialect of XML, so using it means you’ll also be using XML.)
Using HAML makes a lot of sense, but there’s also a bias it (and ERB, and every similar templating language) induces that you want to be aware of. When you start using these things you start thinking of your generated Web pages as “documents with Ruby variables”.
This is fine for some class of features but it will wreck your design skill if you generalize the approach too eagerly. Some (indeed many) portions of a significant Web app should be thought of as Ruby objects with the ability to output a HTML representation of them. Things like row/column tables; menus; data entry forms; recursively nested structures like LW comment threads; and so on.
YAML, and pretty much every data serialization method is overkill for Tic-Tac-Toe—you can store a game just as a few integers if you represent the board as a magic square: http://www.reddit.com/r/programming/comments/9904e/interesting_alternative_to_captcha_pic/c0bw41g
Neat!