- Goals and Side-Hustle
- Well, Goals because I had to, and Side-Hustle because I'm all about that life.
This project is almost ready for release, but a few minor bugs that need to be cleaned up and a few pages that are no longer necessary and need to be rerouted.
The next feature I'd like to add in is Sort by Genre so that people can notice any regularly ignore genres and stop wasting money on them.
I'm confident in my ability to handle Rails CRUD with Ruby and understand the basics well enough, but it's not effortless.
In 1 year, I'd like to have built several Ruby apps that are of completely different direction and type so as to coax out more of those fine details that every language hides in itself.
- Books - POODR, Eloquent Ruby
Michael Wong - Creact - WIP
##Leap My code: here
-
Responder #1 (here) - I like how clean Max kept his code while still being easily readable. The only improvement I could see is using Javascripts' implicit handling of conditionals.
-
Responder #2 (here) - This solution seems strange due to the inclusion of an else that's unnecessary. It's doable to think about, but not instantly obvious what each lines purpose is.
-
Responder #3 (here) - I really like what Tess did here, using nested conditionals to ensure she never explicitly returns false. It's not something I would reach for instantly, but it's a cooler use of logic than explicity stating "if x then y" 3 times over.
-
Responder #4 (here) - This code i
###What is one approach you can take from Mary's code and implement in your project? Since we're building the same app, it's all pretty relevant, though specifically it was nice to see how to break logic out into a presenter, a function that checks state, and even getting a peek into how to map keyboard controls into on screen actions. I really hope to be as modular as she was and make a serious effort to keep different logic types separate.
###Consider the four responsibilities that Rebecca lists for client side code (hint: they're color coded).
- I'm not sure that it was surprising, but it was interesting to notice that when looking at the page itself and breaking out the actual display elements into those categories, that there wasn't any mention of testing the presentation side of things. We've been shown repeatedly that it is possible, but told to question whether that's really what we should be testing (ie test biz logic instead).
Do you feel like you mentally split your client side code in IdeaBox and other past projects into these responsibilities?
- I haven't specifically tried to break out testing into these responsibilities, but it's obvious Rails tries to push that kind of breakdown by using things like Model tests to strictly test Data and View tests to test Presentation. I could see Feature tests being viewed as a way to test that your Applications State is be
- In the context of Node, what is a
module
?
A module is a reference to a value or function stored in another file but made available for use in another file.
- The code examples from the second blog post look very different from the first. Why?
The code examples in the 2nd post are for a specific library (RequireJS) that handles javascript modules for easier requiring.