The Rails SandboxTim AllenBlockedUnblockFollowFollowingMar 17The coding bootcamp learning curve is steep.
Since my last post, not two months ago, I’ve learned the basics of Rails to the point where I’ve made four projects using the framework, some of which were large group projects, but some which were just me.
This most recent solo project was called Rails Engine, which was about constructing an API using JSON to fetch data about theoretical sales.
The most noteworthy new things I learned are how to use serializers, JSON formatting, and making api request specs.
At the beginning, I was mainly planning pace.
I knew the pieces of the puzzle were record endpoints that fetch the basic data about the models in the database, relationship endpoints which fetch all the models related to the model it was requested from, and business intelligence problems which return specific requests based on complex ActiveRecord queries.
I knew the business intelligence was going to be the most challenging piece, so after getting my CSVs imported into the database, I went through all the record endpoints of the Merchant model to get comfortable with how the project was going to work.
Then, I set up all the relationships and the database for all the models, so then I could tackle the business intelligence problems.
I actually focused so heavily on these that I finished all of them before moving on to any of the rest of it.
After getting the BI queries, I made all the relationship endpoints and then the record endpoints for all the other models.
The most challenging part of the project was accessing a specific BI problem that required me to get a list of all customers with pending invoices for a specific merchant.
An invoice belongs to a merchant and a customer and a transaction belongs to an invoice.
What I was looking for customers with invoices from that merchant with either failed transactions or no transactions.
This presented a problem.
I thought to use a left outer join to include rows that have no transactions but I wasn’t able to get customers that have no transactions for that invoice for that merchant.
I was able to get all customers with failed transactions, but not ones with no transactions on that invoice, but a successful one on another with the same merchant (complicated).
What I ended up doing was breaking into two queries, which felt a little like surrender to me, but I was at least content to have solved the problem.
I fetched all the invoices with successful transactions for a merchant and plucked the ids and stored them in an array.
Then, I found all the customers who have invoices with that merchant with invoice ids that are NOT in the array.
This successfully returned all the customers with unpaid invoices for a single merchant.
The thing I enjoyed the most about this project is the amount of little things I could do to make the things I wanted to make.
I have just started Module 3 at Turing which is different than Module 2 was.
Mod 2 was a tutorial style that introduced Sinatra and Rails and there was an expectation for how we would execute these things in the simplest most logical way.
Mod 3 feels more like, here’s scenarios where you need to get creative a little bit, and I’ve really enjoyed that.
The biggest example I can think of is my routes and my controllers.
This project required me to make a ton of extra controllers and hand-rolled routes.
Not only did I stick to RESTful routes, but I only ever had an index or show action in my controllers.
This required me to get creative with naming and organizing routes and controllers.
I had to use name spacing quite a bit, which I found quite fun.
You get the idea.
The part of the project I am most proud of is probably the revenue instance method for a merchant.
This was originally two methods that I sort of combined into one.
It provides an optional date argument that defaults to nil and it only takes it as a parameter if its “truthy” (if it is provided).
This allowed me to use this same method for finding overall revenue and revenue by a specific date.
Additionally, in the controller I placed a params[‘date’] as an argument, so if there is no param passed… it’s nil anyway.
I would change a few things if I could do this project again (or had more time).
I would refrain from using instance methods that are ActiveRecord queries, because I’ve figured out that you can save a call to the database just by passing in the id as an argument on a class method query.
I also learned more about how to use a request spec and that it actually doesn’t need to test the methods, which I was using it to test before (in addition to the model tests).
I would use some tricks I’ve picked up (like SPYing) in the request tests, instead of using all my setup data.
This is stuff I plan on using in my next project.
The number one thing I would have liked to implement differently upon reflection is that I took a dummy object when I was returning revenue through a revenue serializer.
It was a very unusual way of getting the result I needed.
It was really a dummy object that had one attribute of revenue in it with no id or anything.
In the future, I would make a PORO for this (a Plain Ol’ Ruby Object), which I think is a more practical and logical solution to this.
I’m really enjoying the deeper and deeper layers of backend web development.
It’s an ocean of information to play in with seemingly no end of creative solutions to a problem and more fun things to discover and pioneer yourself.
I can’t wait to see where it goes from here!.