Rails App with a jQuery Front End

I considered adding a subtitle to this post: “making things harder than they need to be for educational purposes.” Because at many points, that’s what it felt like. Every time I figured out how to do something cool, and I did figure out how to do some cool things, my first thought after the initial “YES!” was, “it would have been so much easier to do this with Ruby.” Upon completion, I feel that, while I can now do a lot of cool things with forms and buttons, I have ultimately made this app work less well. And that is really frustrating, no matter how much I have learned in the process of making things work less well.

But I did learn a lot. The most daunting and mysterious part of learning any new language or tool in this program is the moment when you have to figure out how to actually use it within a project of your own making. It’s confusing figuring out how to make these different languages and tools communicate with each other. And also how to set them up from scratch from start to finish. We dipped our toes in with the Rails/jQuery Tic Tac Toe project but now we really get thrown in.

This project was about taking the Rails app that we made for the previous section and integrating javascript/jQuery into the front end. I was initially excited about this because when I was building that app, there had been some things that I had wanted to do with the forms that I couldn’t do without the ability to hide and show, or listen for a click. However, after having to recreate some of my rails link_to tags with old school long form routes in “<a>”  tags, having to communicate with the controller through $.get and $.post requests,  and having to use javascript date formatting tools instead of the Ruby helpers I’d built to display my datetime objects correctly, I feel that this project has really stretched javascript past its usefulness.

On the bright side, I can now create notes on the Meeting show pages, which makes so much more sense.

On Elegance (or a serious lack of it)

I have always been the kind of person who could answer a riddle with a response that was correct, but wasn’t the answer the riddler/bridge troll was looking for. I am the queen of finding solutions that are messy, but get the job done.

This has often been true of my coding. I’ll finish a lab and get all the tests to pass but have a sneaking suspicion that I have macgyvered the solution instead of really learning how to use the resources I was supposed to. Or I’ll get the lab working perfectly, but still not be able to get the tests to pass because somewhere within the code were methods that were outputting something in a different format from what rspec was expecting.

I think that in the last month or so, my mission in coding has really transformed from just wanting to be able to make things that worked, to wanting to be able to make things that worked efficiently and elegantly.

 

I’m kind of proud that I’ve developed enough confidence as a programmer to start adjusting my priorities and noticing the details. After passing labs, I’ve started looking at the solution to compare my answer to that of the instructor and refactor for my own curiosity. I’ve noticed that more and more often my solution is very very close to that of the official one.

 

An Ode to the Faker Gem

In working on my rails project I discovered the challenges of quickly generating seeds to test my application. Then, in looking back at the seeds from some previous labs, I noticed this magical whatever you need generator, Faker.

Once you add the Faker gem to your gemfile and then bundle install, all you have to do is set each field equal to a Faker category and datatype, for example, my current favorite: Faker::Hipster.word. Once you’ve done that and use rake db:seed, you’ll discover that it has generated fake/example data for you. One of the things I used it for was to name improv teams to seed my ClubHub app. Results below:

To my amusement it generated a list of very believable improv team names. I’m really looking forward to the Faker::GameOfThrones and Faker:Pokemon functionality. I will name all my seed people after Pokemon and GOT characters.

Rails Assessment – Clubhub

After what feels like forever, I’m finally about to submit the project that I built for my Rails Assessment: Clubhub.

I designed this app to be a tool for communities like recreational softball leagues and improv hubs to manage teams and schedule practices for them. I’m currently on a break from my improv life in New York, but at its peak, I was on at least 5 teams. Most of those teams practiced and we usually handled meetings scheduling through Google Calendars, which got messy. I wanted to create a hub for juggling practices and membership for several teams at once.

The reason that this took me so long was that I failed to think this through at the beginning, and instead, enthusiastically charged ahead with the project. As a result, I ran into several issues at once and got overwhelmed with all of the questions that I should have asked myself ahead of time.

The first big issue was with using Devise to manage my user profiles. At first I thought this made the most sense because setting up sign in/sign up/sign out and authentication processes and errors takes a lot of time and that time is spent not working on the fun important part of the app. So I got devise up and running quickly and connected Facebook login capabilities to it. But then I realized that I needed to customize my user profiles. I wanted to add names for each user because email addresses wouldn’t make much sense in a project that involved a lot of listing and selecting of users for teams. I had to figure out how to customize the parameters that I requested through omniauth to include the user name, and then I had to figure out how to customize the Devise forms and user account creation process. After much Googling, I succeeded. Then I ran into another problem. I wanted to be able to add anyone to a team, whether or not they were an existing user. However, I couldn’t create a user using only a name, an email address and password are required as well. So I ended up limiting the people who can be added as team members to existing users.

I also created and completely built out a whole resource that I ended up not being able to use. I wanted to have a Space resource to book meeting locations. However, I eventually realized that there would be no realistic way to book these spaces through the app unless the spaces were also managed by the league or hub, which would make the list of possible meeting/practice spaces unhelpfully limited and would require a lot of functions that were well outside the scope of this project. Maybe when I have more skill at linking outside resources into my app, I will revisit this idea and build it back in. In the meantime, meeting locations are now just a write-in resource and that’s actually all I really need.

I would definitely like to add some CSS in the future and some Javascript event listeners, but the bones are there and I’m pretty happy with it.

 

 

 

Flatiron Bnb Methods Lab — The Struggle Was Real

At first this seemed to be a lab like any other. Despite the fact that there were already about 15 other students working on the lab when I got to it — which is usually a sure sign that this is one of those labs that creates a bottleneck — I had no reason to suspect that this would take me a week to complete.

There were 68 tests and most of them were validations that it was easy to get passing. It took me a little while to get my User associations tests passing and another little while to get the tests for my “knows all the available listings given a date range” methods passing, but those got done in a reasonable period of time.

What took me most of the week were, or so I thought, the class methods for City and Neighborhood that displayed the instances with the highest ratio of reservations to listings and most reservations. I had tried everything, these should be passing. I even started to question if I knew what a ratio was and how to calculate it!

With some help from Pry, I eventually figured out that the real problem was one that I had never suspected. There was a problem with my Reservations model. Despite having gotten all of the Reservation tests passing very quickly, the validations for checkin and checkout dates were preventing a lot of the seed and test Reservation instances from being created. So, there was nothing wrong with my calculations in the City and Neighborhood models; it was just that a lot of the Reservation instances that they should have been working with weren’t being created. I fixed that problem, and suddenly the class methods were working just fine.

Now, however, it turned out that some of the Review  validation tests that I had gotten passing suspiciously quickly weren’t working and needed a bit of tweaking. Once I set up the validation that I hadn’t needed when the Reservation instances that it was supposed to be checking weren’t being created in the first place, everything was passing at last!

Now, if you’ll excuse me, I’m going to have some celebration drinks.

Sinatra Says What?

Having sort of raced through the modules on SQL, ActiveRecord, Rack, and Sinatra, I find myself, now that I am putting them all together, struggling to remember which does which handy thing. So, bear with me as I attempt to quickly peel back the layers and remind myself what is responsible for what.

Bcrypt is a gem that makes it easy and possible to salt, encrypt and safely store passwords for user accounts.

Shotgun is a gem that makes it quick and easy to start a local server with which we can test the web application.

Sinatra is a pun-filled gem that provides the methods like get and post, which make an application a web application that can respond to HTTP requests.

Rake makes certain tasks easier and faster, mainly creating, migrating, updating, and undoing changes to SQL databases using the command line.

ActiveRecord is a dynamic ORM that maps Ruby classes to corresponding databases.

SQL is the language that communicates with and manages an app’s database.

 

 

 

Sinatra Project: Save the Writers

As an aspiring writer, I keep tabs on all the resources for learning, job opportunities, writing competitions, and health insurance that I can find. I also have paid for a lot of professional memberships and networking tools, and it’s frustratingly hard to remember what all I’ve paid for. For the past year, I’ve been using a completely adequate but wholly uninspired Google Docs chart (pictured above) to keep track of it all.

So, when I read about the structural requirements for the Sinatra app that we would be building, mainly that it needed to use a database and there needed to be a class of items that could belong to a class that would have many such items, I knew exactly what I wanted to do.

I’ve built an app called Save the Writers, which keeps track of writing resources. The app that came out was general enough that it could be used by almost anyone who needed to keep track of professional or educational resources — I could certainly use it for my programming education resources. However, I hope to find ways, as I continue to use it, to further customize it to make it more useful for writers specifically. However, I think that would involve a lot of drop-down menus or checkboxes with pre-populated options, and we’re not quite there yet.

One thing that I had to figure out how to do for this project, as opposed to my previous ones, was add my own stylesheets. The tables were getting too messy otherwise, and it was fun to use that skillset again, which we haven’t had to for a long time.

As always, the part that intimidated me the most about this project was the lack of spec tests to tell me what should happen and whether I was doing it correctly, and having to set up the basic structure on my own. My understanding of the contents of a config.ru file and a sinatra config/environment file is still a bit fuzzy, so I found myself borrowing from previous similar projects and figuring out what worked.

The really nice thing is that once I did get my head around what I wanted to do and how I wanted to structure the tables, and how to get shotgun up and running, the actual programming went pretty quickly. It’s so lovely having ActiveRecord to do so much of the legwork for me.

I still have some tweaking to do, mainly with improving the formatting and customizing the resources, but I’m pretty satisfied.

Much Ado About Arrays

Arrays are indexed collections of objects that can contain anything, from strings, to numbers, to hashes. They are like the Room of Requirement in Harry Potter, capable of holding whatever you need them to hold, without limit.

Except, arrays are usually in some kind of order. And involve less fire.

Arrays are a crucial tool for collaborating objects, because they can store all new instances of a class, and store particular attributes and associations of those instances. But they can also be the leading cause of frustrating breaks in your code when working with collaborating objects.

Truly, I think nearly every frustrating issue that I faced while trying to get my tests to pass for Collaborating Object labs, came down to a method outputting an array when I didn’t want it to. It’s rarely the content of the output that is the issue, it’s usually the object type.

Then there is the issue that array methods themselves often output a new array instead of the original, or even nil. You might find yourself wondering why you need similar methods like .each and .collect, but only one of those will actually edit the array that you are trying to edit. Read the documentation! It’s very clear about this and it can save you a lot of time and frustration.

Pry is also your best friend. If you want to make sure that your methods are iterating into the level that they are supposed to, pry is often the easiest way to find out what an operation on an array within a more complex method is outputting.

Stay strong, and check your outputs.

Making NYC Theater Discounts – a CLI gem

One of the more intimidating projects for Learn’s Object Oriented Ruby section is creating and publishing your own gem. This was one of those projects that I had heard about at the Meet Ups before I had even started it, and had been simultaneously really excited and terrified about. Building my own idea and going without the built-in rspec tests and step by step instructions was like going without my training wheels and I was nervous.

At first I thought, because it would be fun to play with the public health stats at data.gov, that I should build something morbidly interesting that shows leading causes of death in different areas. However, just finding the right data set was proving too frustrating and I wanted this project to be a little more fun. That’s why I decided that I wanted to build nyc-theater-discounts to aggregate daily deals from well-known theater discounters so that I could both compare them and see them at a glance.

I broke the process down into priorities. I used TodayTix as my first scraping victim and my goal was to first get the basic class structure of the gem worked out and build a very basic CLI, and then I wanted to get the TodayTix scraper working and be able to output a basic list of deals. I figured once I got that going the rest would be easier. Then I would add some new sites to be scraped (I decided to stop at three for now, and I plan to add more for future updates), get a more complex CLI working, and for the last step, make it possible to search all the shows by name and return the deals for that show from each discount site, for comparison. This last step intimidated me but it turned out to be much easier than I expected.

I began by watching Avi’s tutorial and using bundler to create the gem. I was a little intimidated by the unknowns of publishing a working gem and of having to devise my own structure. I then realized that the CLI that I imagined was pretty close to the Music-Library-CLI that we had constructed earlier and I borrowed a lot from that. I initially struggled to figure out how I could build scrapers, which would have to be customized for each vendor, and yet maintain a consistent vendor class. Then I got an idea from the best restaurants example that we had been given and realized that I could create a scraper class, and a vendor class and then pull the attributes from the scraped data of each site and use those to initialize new vendors.

I then hit a very silly stumbling block because I forgot to require ‘open-uri’ and could not for the life of me get the TodayTix scraper to even open the link. Once solved though, everything surprised me with how quickly it came together. I have found scrapers really frustrating in the past but this site happened to be incredibly easily constructed for scraping. God bless TodayTix. And once that was running, I was able ot get the other sites scraping within a few tries as well. Broadwaybox provided a challenge because the min-price was only available on the click through page, so I had to add an extra layer of scraping and iteration just to pull that one data point.

I got it all working yesterday and I was so freaking proud. I’m seriously thrilled that I was able to make this. And it was so much easier than I thought it would be. I’m excited to add more sites and more ways to interact with the data. I published it about half an hour ago and it already has 12 downloads.

Update: now at 24 downloads but unfortunately, in my eagerness to publish, I forgot to test the execution, and the gem I initially pushed didn’t work. After a couple attempts to fix it, I pushed a patch update that makes it work. So embarrassing, but it works now!