Learning to code is difficult. Duh. But it’s hard to distill why that is. After spending a week devoted to Ruby on Rails, I can best describe the climb to code literacy as “grueling”–but the promise of actualizing our Rails proficiency is exciting. After four short weeks of 9-5 classwork, we’re finally bringing our website projects to life.
While we haven’t yet mastered HTML and CSS, the focus now is on back-end connections linking pages and server requests. “Seventy percent of getting apps to work is understanding the app communication cycle,” says HFC Academy instructor Ricky Reusser.
Think of it like a massive box kite: It looks cool laid out on the ground, but if you want it to fly, you need to erect the frame. If one strut is in the wrong place, the whole kite goes down. Those struts are the framework between what you click on (firing off a request to the server) and whether the framework is set up so that the response from the server makes sense. Even if your kite just turns left instead of right, it’s still broken. And your website products only get one chance to make a first impression.
Despite the heartbreak that comes with breaking your site (again!) and rooting around StackOverflow for a similar problem, it’s incredibly empowering to see a site come alive. Any amateur can crudely knit their website together with HREFs, but Rails lets you walk into the wide world of sessions.
There are two simple ways for websites to carry data from one page to the next. The first is form data, which you have to specifically command the website to carry over to the next page. The second is data tacked on to the URL, which you’ve seen when you click on an article from social media–that junk cluttering the address bar tells the website how you got there. Both of these methods work, for better or worse.
Using sessions allows you to store some temporary data on the server. This is necessary when you want to do something like, oh, sign in to a site. Security adds a whole new layer to the website onion, one that requires just the right nimble code stitching throughout your pages to make sure it authenticates and that the user has signed in correctly before displaying personal data. If you used data tacked on the end of a URL, someone could crack the pattern and brute force their way into your data.
That’s because the HTTP that the Internet runs on is stateless, in which you send static requests and the page only loads information that is returned as a response from the server. The page won’t change until you interact with it.
So a resource-cheap way to hold on to background data while you surf around and go back and forth is critical–one end of the information handshake will always be stateful. Shopping carts are an excellent example, along with surveys and installation wizards. If a user was halfway through a survey and wanted to run back and check a previous answer, finding the later content gone would kill any enthusiasm to finish.
Sessions aren’t designed for heavy lifting, of course. Long-term data should be stored on the database. Don’t rely on sessions too much, says Reusser, “because it’s a good reason for things to explode.”
Gems are the modular plug-ins that Ruby users upload on repositories like GitHub. They solve common problems–logins, data uploading, and so on–that save you time by letting you drop in tried and tested solutions.
“One thing I regret when I was learning was doing everything myself, trying to reinvent the wheel and not paying attention to what other people were doing,” Reusser says about the utility of Ruby gems.
But dropping them in without fully understanding how they work is dangerous, especially as they grow to thousand-line monsters. Reusser once dropped a gem into a project to quick-fix a problem–in that case, uploading photos. But after his clients had manually updated hundreds of photos, Reusser discovered that the gem wouldn’t process photo names with spaces–yet if he changed that code, then it would ruin all the existing photo data. The quick-fix turned into a time-consuming quagmire.
“I feel very strongly that gems are a great thing–the only exception being things that are tacky or unmaintained. You don’t want to take on to your responsibility what they have messed up,” Reusser says. “I’ve been burned by gems before. Sometimes people write things that they shouldn’t be trying to do.”
Which is why Reusser doesn’t touch a gem that is more than eight months old. Recent updates mean somebody’s paying attention and refining it–which is especially critical for user authentication and security.
Remember when you were forced to learn the long route of functions before you were allowed to use calculators? The same lesson applies here. After spending a week stitching our website together with handmade user authentication, we used the popular Ruby gem Devise to automate the process. Devise routed everything together in five minutes, automatically including password encryption, password reset mechanisms, and data storage of logs in history.