Finish the Odin Project's Rspec section
Work through Hartl's Rails tutorial's chapters 3-5 (however long that winds up taking) to catch up yochiyochi.rb (Tokyo-based Rails study group).
I tried to get through some of the latter today and wound up both
A: not getting very far, and
B: getting a lot done in process.
I'd been using c9.io as a (free!) remote development environment for working through the Rails tutorial, as Hartl himself advocates, but since I've since switched to a Mac and will need to have everything up and running on this machine for the study group meetings, I figured I'd go ahead and get it taken care of today.
This necessitated setting up different gemsets with RVM, using homebrew to update Git and then updating my bash profile such that it doesn't default to Apple's bundled (older) git version, making a new ssh key to use with bitbucket and heroku, etc. Not difficult per se, but took a while and was a lot of new stuff. Solid Google game has got to be worth a good 20 IQ points in this day and age.
At the Rails meetup I attended last week, I met a gentleman who'd relocated from Tokyo to NYC for the duration of his Dev Bootcamp program before returning to look for work. We both talked about what we'd been studying, and he had a number of book recommendations.
The one he pushed the hardest for is the one I'm reading now-- Practical Object-Oriented Design in Ruby. His parting words about it stuck out: "You've gotta read that so you can stop writing, y'know, stupid code."
Emotional response: You haven't even seen my code but it works so how stupid could it be?
Rational response: Important book? Important book. I should read important book.
Actual verbal response: "OK."
Sure is handy to have awareness of each of those. Thanks, adulthood!
And sure enough, the book has absolutely been a red pill in terms of how I'm seeing code and its design, which hadn't been on my radar to this point. Things I'd read but evidently not fully taken to heart, like why one should reference the attr_reader wrapper method of an instance variable instead of the variable itself, make a lot more sense conceptually now (doing so keeps all references to that of the method's behavior, which is defined once, as opposed to data, which isn't as DRY).
Sure, I've made games and such that work, but as the author (Sandi Metz) so eloquently puts it, "Anyone can arrange code to make it work right now. Today's application can be beat into submission by sheer force of will. It's a standing target at a known range. It is at your mercy. Your application needs to... be easy to change forever. This quality of easy changeability reveals the craft of programming."
Sure, I've made games and such that work, but as the author (Sandi Metz) so eloquently puts it, "Anyone can arrange code to make it work right now. Today's application can be beat into submission by sheer force of will. It's a standing target at a known range. It is at your mercy. Your application needs to... be easy to change forever. This quality of easy changeability reveals the craft of programming."
Great writing, right? Makes me want to get craftier.
No comments:
Post a Comment