Most of the lessons within Learn tend to stick to just a few different domain models. In other words, they tend to be based on the same few subjects, or contexts. More info on what that means here. For example, many of the beginning Ruby principles were taught within the context of displaying a tic-tac-toe board, and eventually being able to play it, and then finally creating an unbeatable tic-tac-toe AI opponent. There have been several other domain models I’ve used with them, but they like to stick to a few, so we can really see progress on what we can do within a similar context, as we learn more and more coding skills. With that in mind, I decided to stick to a similar domain model to my cli gem, and made a sinatra app for managing D&D characters and parties. This is actually something my friends and I, and potentially a lot of people, could use once I’ve got a server somewhere to host it.

Realistically, I want it to have a lot more features than it currently does, and look more polished, but I want to save that stuff for when I learn rails and javascript – I’m starting rails tomorrow. In any case, I’ll still be able to re-use plenty of code for that, I’m sure. Speaking of that, here’s the code if you want to take a look.

At the top of this post, you can see the basic structure of the sinatra app. Most of the files you see there (and one of the folders), consist of configuration files, that basically ensure the app has the tools it needs to perform its functions. They’re typically very similar between basic sinatra apps like this. In the database folder, I created a few db migrations – commands that create tables in a database, so I can store users’ info permanently. That way if you quit the app, you can always come back and still have your profile, with your characters, etc.

Within the app folder here, you can see I’ve set up an MVC framework:

MVC stands for Model View Controller (the names of those folders above). That framework allows me to split my code into more manageable chunks, with different responsibilities. Those controller files provide instructions that determine what page someone sees when they visit a specific URL, or click a certain link. Certain things people do are more related to their own profile, or characters, or parties, so those each have their own controllers to split responsibilities. Theoretically, all of those controllers could be combined in one file, and the models and pages could be there too, but that would be a total mess. Here are the model files:

Those basically represent the ideas of users, characters, and parties, which means I can use those ideas throughout the sinatra app. They are integrated into the database using the activerecord gem. That gem lets you break down objects and store their info in a database, and then when you need them again, you can pull out that info and rebuild the object. Lastly, here are the view files:

Those are .erb files, which are basically fancy HTML files that allow ruby code in them. That means I can build template pages, that display content dynamically, depending on who’s looking at the page – and I can even programmatically generate things to show on the page based on content users have created, etc. That means I have to build less pages to show a bigger variety of things – and I can build pages more quickly too!

It’s tough to explain what all of this looks like from an end user’s point of view, so I’m going to create a video showing a bit of a walkthrough. I’ll update this post with it soon.
I’m really excited to have gotten this far, and am looking forward to digging into ruby on rails and javascript. I’m sure I’ll be back here at the ol’ blog as soon as I’ve got a rails project done. If anyone has any suggestions for a coding topic to talk about, or anything like that, I may post again sooner than that. Thanks for reading!

**UPDATE**
Here’s a link to a video, showing what the sinatra app looks like and how it behaves:

It’s blurry at that size, but it looks fine on full-screen.

The post I made a sinatra app appeared first on Morgan VanYperen.

Anyway, more about the project. It’s called monster_index. It’s a tool for playing Dungeons and Dragons, because I’m a nerd. Basically, you can run the program, and it will list a bunch of D&D monsters, and then you can go deeper and see a bunch of stats for each of those monsters. It’s all text-based, or rather, a ruby gem with a command line interface. So that means it’s a program you can download, install, run, and then use it through the terminal.

No, I didn’t take the time to gather all those monster stats myself. I’m not that obsessed with D&D, and that would take foreverrrrrr. I used a nice little tool called Nokogiri (a different, better ruby gem someone made) to look up all that info and sort out what I want, and embed it into my program. Lucky for me, this site exists, and Nokogiri, under my careful instruction, goes and grabs the info from it whenever monster_index needs it.

At this point, I’ve published the gem for public use (go nuts, everyone), and put the source code on GitHub, for all to see, and possibly collaborate with.

Like I said, It’s not totally finished yet – I mean what software ever is? But really, it’s lacking a huge number of monsters, because I need to learn to use Nokogiri better, and while I appreciate that site I mentioned earlier as  a free resource, it’s not as neatly organized as I’d like it to be. Let’s get into the nitty gritty of that, because I bet you’re just on the edge of your seat, waiting to hear about this.

First thing my program does is create a bunch of instances of the Monster class, based on info it can get from the Scraper class. So the Scraper class uses Nokogiri to “scrape” information off of the pages of the site. First thing it looks at is this page.  Easy enough to get a list of monsters from there – I’ll just get a copy of that page’s source code with this

doc <span class="pl-k">= </span><span class="pl-c1">Nokogiri</span>::<span class="pl-c1">HTML</span>(open(<span class="pl-s"><span class="pl-pds">"</span>http://www.d20srd.org/indexes/monsters.htm<span class="pl-pds">"</span></span>))

and then I can see they organize all the monsters into 4 columns with lists of monsters within lists of letters. basically. so I iterate through those and add all the monsters to an array like this

monsters = []
 doc.search("ul.column li a").each do |monster|
 monsters << {
   name: monster.text,
   url: "http://www.d20srd.org/#{monster.attr("href")}"
   }
 end

so, perfect, now I’ve got all the types of monster, along with the urls to see their details. now I just have to go in and grab each one’s stats. that’s where I hit a road block, because their individual pages aren’t totally standardized (the horror)! so for a lot of them, this code works just fine

def self.scrape_monster_page(monster_url)
 doc = Nokogiri::HTML(open(monster_url))
 profile = {
   size_type: doc.search("table tr td")[0].text,
   hit_dice: doc.search("table tr td")[1].text,
   initiative: doc.search("table tr td")[2].text,
   speed: doc.search("table tr td")[3].text,
   ac: doc.search("table tr td")[4].text,
   attack: doc.search("table tr td")[7].text,
   alignment: doc.search("table tr td")[19].text,
   }
 end

I go to that monster’s page, and grab each stat off of a table there. But then there’s a bunch of them that are organized differently. For example, “Archon.” That’s not an actual monster – it’s divided into Lantern, Trumpet, Hound, and Hound Hero types. And no, I actually don’t know what any of those are. I’ve never encountered them on my adventures through D&D. Anyway, that means I don’t want to list Archon after all, because there are no stats for that. Not only that, but those other sub-types don’t have their own pages – they all have different tables on the same page. And this happens with plenty of the monsters from the original list, except sometimes, inexplicably, not only will a page have tables for multiple monsters, but they also combined multiple tables into one more complex table. While I could probably work out some exceptions to my Nokogiri instructions, there seems to be too much inconsistency for me to bother scraping all those pages in different ways.

At some point, I’ll be both faster, and smarter about scraping pages, but for now, I just want to provide a quick reference on the simpler categories of monsters, without a bunch of weird sub-categories messing everything up. So I just added in a filter to basically ignore all the monsters where that was an issue, and finished up the rest of the gem, and published it.  I ended up with wayyyy fewer monsters, it turns out (D&D is complicated), but still a pretty large number, and I’m happy with what I ended up with. So here we are! I’m now the author of a ruby gem.

The post I made a ruby cli gem appeared first on Morgan VanYperen.