#bitmaker labs

Wow. Ok. So Week 4 came and went, and though I did many things, blogging was not one of them. For the sake of brevity, here is a round-up of the week that was crazy, cool, and exhausting.

Deployed an app to Heroku. You can check it out here: photogur. It’s a bare bones photo app, like ‘90s rip-off of imgur. All puppies.

Went to my first Meetup. From what I’ve been told, this industry runs on meetups. Ruby Lightning Talks hosted one at Bitmaker Labs, with talks on Rails 4.2.5′s cool new features (by Mina), a look at Processing.js and generative art (by Natalie), 500px’s migration from Rails 3 to Rails 4 (by Kevin), and a few examples of productive Sass in Bootstrap (by Christina).

Sorry to all the coders out there for the pre-cleanup branching mess.

Started branching and haven’t stopped. Before starting our first group project, Mina introduced us to branching in Git. If only all kinds of work had built-in version control, task isolation, and feature merging.

Installed the FactoryGirl gem and learned ping-pong testing. I must say, I’m biased towards factories over fixtures, if only just because the gem is called FactoryGirl. We are all ladies! (And, yes, I understand that FactoryGirl has nothing to do with feminism.)

Made cinnamon streusel coffeecake for Thursday’s coffee and code!

Nifty websockets diagram at the Rails Girls TO meetup

Learned more about ActionCable than I can understand at this point. And I went to my second meetup! Rails Girls TO hosted an event at Shopify, featuring a different Mina—Mina Smart. She spoke about the ActionCable and websockets feature in Rails 5. See her presentation here.

After a couple weeks building apps that were based on only one kind of object or model (e.g. only contacts for our CRM), we finally waded into databases and associations this week. Natalie, one of the other instructors at Bitmaker, introduced us to the Rails method for setting up different models (the tables in a database) and linking them together with associations (the relationships between the tables). See my notes on associations in the latest Today I Learned (TIL) post.

In other news, Frank and I finished the Escher puzzle!

It is finished. Hallelujah!

As we were nearing the end of the puzzle, we realised that there were definitely a few pieces missing. Frank, hero that he is, scoured the house for the missing pieces. He found two of the pieces in corners nowhere near the puzzle. Sock transfer, maybe?

On Friday, Mina, our lead instructor, introduced us to user authentication and sessions. User authentication is making sure a user is who they say they are. Sessions allow authenticated users to interact with your application, without re-authenticating themselves every time they do something new (like click on a different link). Can you imagine how annoying it’d be if you had to re-enter your username and password on Instagram every time you liked a photo, posted a comment, loaded a user profile? Sessions are saved as cookies (which you’ve probably seen warnings for, or cleared out of your browser history).

User authentication is usually as simple as a username and a password. Sometimes it can even be just a username, if you’re not too concerned with a high level of user authenticity. For the most part, a certain level of authenticity matters and for that reason, passwords are used. But how do you store a password and then prevent hackers from getting into your database and stealing it? Well, you don’t store the password at all.

Instead, you store something called a hash. A hashing algorithm will perform a one-way conversion of the password into a digital fingerprint, or hash. This digital fingerprint is always the same for that password. The emphasis on one-way is important, because a hacker cannot convert the hash back into the password.

Mina illustrated one-way conversion this way: “I add two numbers together to get 700, and then I ask you which numbers I added together. Given the number 700 alone, you don’t know the two original numbers.”

Merely hashing passwords is not secure. Hackers can use rainbow tables to figure out the hashing algorithm, or hash tables to just look up the password if it’s a common one. So, before you hash your passwords, you should salt them, too.

To salt is to add a chunk of random data to your password before turning it into a hash. The salt makes a common password uncommon. Hackers then need to have a database for every unique salt + password combo. They would either need much larger databases, or have the computational power to try a list of potential passwords against every stored hash—slower than doing it the big database way. But hashing algorithms are usually pretty quick.

With bcrypt, the encryption method most commonly used with Rails, there is one more security measure. Bcrypt is designed to be slow and computationally expensive, which means that any hacker wanting to crack your site needs a lot of time and computing power. The trade-off is that the bcrypt will also run slowly and take up a lot of room in your application, too. So bcrypt allows you to decrease the computational cost to improve your application’s speed and space for a (slightly) lower level of security.

In an attempt to segregate purely technical posts from the personal posts, I’m introducing a series called Today I Learned (TIL). A TIL will essentially be a summary or rehash of my Bitmaker notes on a particular topic. This first TIL is all about database associations, the relationships between the different models (tables) in the database.

Associations

belongs_to: defined in the “child” model. An instance of a model can “belong_to” only one specific instance of another model, but can also belong to specific instances of other models.

A child belongs to a mother (and has only one mother) but also belongs to a father (and has only one father).

has_many: defined in the “parent” model. An instance of a model can "have_many” instances of another model.

A mother has many children.

has_one: defined in the “parent” model. An instance of a model only “has_one” instance of another model.

A family member has one room in the house.

has_many, through: defined in both models on either side of the relationship. An instance of a model “has_many” instances of another model, “through” a third model.

A neighbourhood has many families, through the houses those families live in. A family can live in many neighbourhoods, through the different houses they live in.

has_one, through: defined in both models on either side of the relationship. An instance of a model “has_one” instance of another model, “through” a third model.

A father has one son-in-law through his daughter. A man has one father-in-law through his wife.

has_and_belongs_to_many: defined in both models on either side of the relationship. An instance of a model “has_many” instances of another model, and “belongs_to_many” instances of that model, too—with no tangible link (i.e. a third model) between the two.

On the weekend, Frank and I started a project that seemed “fun” and “low-commitment” and a “nice way to spend time together.”

Escher, you devil. Your water looks like bricks that look like windows (or stairs).

We decided to start a 1,000-piece, black-and-white puzzle on the grey coffee table in our tv room. Maybe because we didn’t have enough arbitrary frustration in our lives. We eventually moved the puzzle to the dining table, and it has consumed my life before and after school. The puzzle and I have a love-hate relationship (all the love and all the hate are are mine, as puzzles have no feelings).

Meanwhile, at Bitmaker we had an interesting tour yesterday and an insightful talk today. On Tuesday, Ella (student success coordinator) walked us over to the headquarters of Nulogy. It was my first time inside a development company. Shah, one of Nulogy’s developers, told us about the company’s culture, structure, people, and work. He took questions and gave us a tour of the open-plan space. There are no corner offices, not even for the senior management team—Nulogy’s flat hierarchy and high esteem for personal ownership are reinforced by the physical space.

Shah patiently answering all our questions. He also gave us snacks, which is +10 points.

Then today, Bryan, a Bitmaker grad and current apprentice (but soon-to-be developer) at Nulogy, talked to us about his coding journey. As a person with little-to-no coding experience, it was encouraging to hear Bryan’s story. He has an arts education, but always had an itch to learn code and make programs. I appreciated Bryan’s honesty about the difficulty of this journey: leaving behind a career and stability for a new venture and creativity.