The Chronicles: Learning Web Development at Bitmaker Labs (Week 4)
Thoughts on building larger, more powerful Rails apps and on debugging
Need some context? Read about week 3 here.
Monday
We went through ActiveRecord relationships and how to relate models to each other in our Rails app on Monday. In the afternoon, we built a mini version of Amazon, complete with the following functionalities: creating, editing, and deleting products and reviews of products, creating and editing users, and logging in and out of the application. We are really starting to get a feel for this.
Why ActiveRecord relationships are important for this project
In our version of Amazon (which we called “Rainforest”), we had sets of data that we wanted to be related to each other. We wanted users to be related to reviews (one user can have many reviews), reviews to belong to product (a product can have many reviews), and for a product to have many users interacting with it through reviews. Making these relationships real requires developers to write them into the model files and add columns to each child model for a foreign key that would be associated with an instance of the parent data.
Tuesday
On Tuesday, we dove straight into user authentication and authorization; the former ensures a user is who they say they are, and the latter ensures the user has permission to view the things they are trying to view. Knowing about and understanding these built-in Rails features (and the bcrypt gem) allow us to create login, logout, and account creation functionalities for our app.
In the afternoon, we continued to build out our Rainforest (Amazon) app. When we were finished, we were asked to start from the beginning and build the app all over again (without the instructions) to gain a better understanding of all the concepts we’d learned thus far.
Wednesday
“A Rails pauperie” was the way our Wednesday lecture was introduced. We took a look at:
- Partial templates: for when you want to include a bit of code in more than one view. A use case for a partial template would be a login form — perhaps we would want to include this on its own page but also on the side of a homepage. To keep our code DRY, we would create a new file (beginning in an “_” to follow Rails convention) and then reference the name of this file wherever we wanted it included, like this:
- Flash notices and alerts: for when you want to display a message to the user notifying them of something. Flash notices are used for information (for example,“You’ve been logged in successfully”) and flash alerts are used for warnings or when things go wrong (for example, “Wrong username/password”).
- Validations: for when you need user information to be in a specific format or have specific qualities, like an email.
We were served a large buffet of options of things we can do with Rails, and I was really excited to continue to build out the Rainforest app another time with a more solidified understanding of these concepts.
Thursday
Our instructor gave us a few tips on how to plan out your app from scratch on Thursday. By starting with the bare-bones of what you need and building out from there and also by considering every single feature you need, want, and would like to have, we can make the task of building out our rails app much less daunting. We used these steps to plan out our next project, which was an app called “SeatYourself” — a clone of OpenTable.
There were lots of things to consider for “SeatYourself” — more than anything we’ve built to date. This required us to ask ourselves a lot of questions.
What do we want our app to do, more than anything else?
We want people to be able to make reservations at restaurants with SeatYourself.
Okay. Phew. That was easy.
What features does it need to have?
Now we list out all the things we want our app to do, and then divide them into categories to prioritize them. The format we’re using to talk about the features are called “user stories”.
Need to have (the app won’t be useful if it doesn’t have these things)
- As a user, I am presented with a list of restaurents on the homepage
- As a user, I can sign up, log in, and log out
- As a user, I can make a reservation if I am logged in.
- As a user, I should have a confirmation that I made a reservation
- As a user(owner), I can create a restaurent instance
- As a user(owner), I can set the hours for when reservations are possible
- As a user(owner), I can view all the reservations for a restaurent
Nice to have (it would be great if we had these things)
- As a user, I can view a profile page of a restaurant to view information about the restaurant
- As a user, I can go to a page to see a list of the reservations I’ve booked
- As a user, I should get an email when I make a reservation
- As a user, I should be able to edit or cancel a reservation
- As a user, I can see the menu options for a restaurent
Dreams (maybe one day…)
- As a user, I can write a review
- As a user, I can see all the reviews I’ve written.
- As a user, I can go to a page to see the list of restaurants sorted by cuisines.
How do we turn this into a Rails thing??? ? ? ??? ???
Now we have to start thinking about our project in rails terms. For this first iteration of our app, we’ll just try to focus on the “need to have”s and list the models we need for that.
I used a web app called Asciiflow to draw my entity relationship diagram and to write out the columns that would need to be associated with each model:
This is starting to look a little more Rails-y. Now, let’s mockup what our views will look like…
And NOW we can start building the simplest version of our app!
Friday
On Friday, we learned about date, time, and datetime datatypes. This was useful in building the “SeatYourself” app we started working on the day before, since reservations need a date and time datatype to be saved in and referenced from the database.
On Friday afternoons at Bitmaker, everyone comes together for a “Code Review & Social” when students have an opportunity to present what they have been working on that week. I finally got up to show the styling I’d added to my Rainforest (Amazon) app this Friday; I had been working hard on this during the days prior and was looking forward to showing my classmates what I could do… and then this happened:
Hey! That’s not my app!
In addition to learning about date, time, and datetime datatypes on Friday morning, we had also spent some time learning about debugging. From the lesson and from my (very public) error, I learned the following:
Test your software early & test often:
The best way to fix bugs is to avoid them in the first place. I hadn’t run any tests on this app before showing it to a room full of people except for manually going through all of the app’s features. Had I written tests and run them beforehand, I would have found that there was a simple routing error caused by a template being saved in the wrong location. Rails developers will know that Rails is all about convention over configuration — which basically means that there is a way to build Rails apps that developers must follow in order for the app to work.
Errors are good!
It is extremely difficult to write perfect software generally, but it is almost impossible to write perfect software on your first try. Error pages, like the screenshot above, can tell you where the error is in your app and what kind of error it was (did you make a typo or did you forget to create a view for one of your controllers?), which can help you fix the problem that is preventing your program from working.
It sounds kind of backwards to say that errors are a good thing, but consider a situation in which your app wasn’t working but Rails wasn’t giving you an error. From here, it can be very difficult to know where to start or even what could possibly be wrong with your code. So get excited and be thankful for errors — they are your friends.
Use the good ol’ buddy system
Pair programming can be a great way to avoid bugs — a second pair of eyes often ensures your code is void of typos and silly mistakes you might not catch when you’re in your regular workflow.
That’s it for week 4. Thanks for reading — I hope you found what you were looking for. I am always looking for feedback on how I can improve these pieces and on my writing generally, so please don’t hesitate to leave a comment or tweet at me with anything you think I should know.
Tara Mahoney is a freelance web designer & developer in Toronto, Ontario.
Give her a shout if you wanna chat, or check out some of her work here.
