This blog post is part of a series on State Machines. Read Part 1 here.

Until you encounter a state machine in a gem, framework, or within someone else’s code, you probably won’t find one very easily. But as we learned last week, they’re rather pervasive. I discovered state machines while helping build a large-scale eCommerce website.

But there actually weren’t even that many state machines in our code! We were relying on state machines that lived in the source code of a Rails library with a variety of gems, commonly referred to as spree. (Why reinvent ecommerce platforms when so many people have already made ‘em, amirite?)

So, I did what any self-respecting, completely unaware new developer would do: I dove into the spree source code. And boy, was that a rabbit hole. But, I learned some things about how state machines work in Rails and how to make them. It’s good to conceptually understand the theory behind state machines, but the best way to learn something is by doing it. It’s time to take off the training wheels and actually build our own state machine!

My favorite thing about programming is the fact that you never run out of opportunities to be completely floored. There’s literally always either a concept, theory, framework, or language that you don’t know. This is actually fantastic, because there’s no dearth of opportunity when it comes to learning. And you always come head-to-head with these facts when you pair program with a more experienced developer.

One of the new concepts that I encountered this week was the idea of state machines, sometimes referred to as “finite state machines”. At first I thought that this was something unique to the gem that we are using in one of our large-scale applications, but it turns out it’s not a Rails thing. In fact, it’s not even a Ruby thing! It’s a Computer Science thing; to be a bit more specific, it’s a mathematical abstraction used to design complex algorithms. But for all intents and purposes, it’s a Computer Science theory that we use almost all the time, whether we know it or not.

If you got through that paragraph without freaking out, you deserve a medal. All this CS theory sounds terrifying, right? Well, don’t worry. For programming purposes, you don’t actually need to think too much about how state machines are constructed and what’s being abstracted away. Even though state machines can get incredibly complex, relatively quickly, let’s not overwhelm ourselves; we only need to think about state machines in the context of programming. So we’ll keep it simple and focus on what state machines are, how they work, and when to use them.

When working in Rails, it’s all the family – literally. No matter the size of your application, almost all of your objects are going to be related to each other. You can create however many objects you want because database rows are cheap, cheap, cheap! But the more objects you make, the harder it is to keep track of the other data that the object relates to (which is generally yet another object).

I found myself in such a predicament last week, when I had to make numerous objects relate to one other to create a tree structure. The obvious first approach was to use the belongs_to and has_many relationship. But when I realized that I wanted some Genre objects to belong to other Genre objects, I ran into a problem. Depending solely on the ActiveRecord relationships turned out to be painful, messy, and complicated, and wouldn’t make my code very flexible or sustainable over time.

So I Googled around and found a handy plugin created by DHH himself called acts_as_tree. This gem allows you to create a hierarchical structure of objects in your application and – to take it a step further – gives you a bunch of incredibly helpful methods. It even allows you to visualize your tree structure! Sound amazing? That’s because it is. And if you follow a few easy steps, you can use it in your application, too.

Snowmageddon. Snowpocalypse. The Deep Freeze of 2015. You can call it whatever you want, but we can all agree on one thing: it’s so damn cold outside. In fact, it’s so cold that I recently saw this error message while debugging a Postgres issue: RuntimeError: can't modify frozen Hash

My first thought was, naturally, holy shit, even my hashes are frozen. I did a little digging, and it turns out that we aren’t the only ones susceptible to these chilly temperatures. Apparently, objects can also freeze!

So, in honor of the frozen tundra that we all seem to currently inhabit, I decided to explore the icy-cold depths of Rails frozen objects. Before you read on though, you should know: I’m going to use only gifs from the Disney animated film, Frozen — don’t say I didn’t warn you.

This blog post is part of a series on Class Inheritance. Read Part 1 here.

I recently stumbled upon this line of code that totally floored me. I mean, I had to drop everything I was doing and do some serious Googling, my friends. Well, that and also I asked my fellow developers at work who are far more seasoned programmers than me.

Now, I’m going to share this line of code with you, but you’ve got to try not to totally freak out if you haven’t seen it before. Are you ready? Ok, here we go:

1
2
3
4
5
6
7

class SomeObject
  class << self
    def some_method
      "A string returned by some_method."
    end
  end
end

Are you with me? Did you make it past the second line? Do I need to call an ambulance? Well, if your reaction was anything like mine, you saw class << self and experienced something akin to an aneurysm.

Ok, let’s agree on one thing right here, right now: everything in Ruby is an object. No matter how crazy it’s about to get, just remember that. In fact, it’s worth repeating again: Everything in Ruby is an object – even a class.

Got it? Okay, now let’s figure what the hell that code means, exactly.

No matter where you’re from, what programming language you prefer, or which JavaScript framework you’re committed to, I think you’ll agree with me on one thing: time is a bitch. And no, I don’t mean the wrinkles on your forehead kind of time (although that sucks too); I’m talking about time as a programming concept.

I mean, you create some migrations, build some models, make some API calls, but then time shows up and brings down the party. I happened to learn all about programming’s royal pain in the ass while working with the Instagram API last week. After I finally got my code working, I took a look at my JSON response and saw this strange creature:

1

"created_time": "1423694433"

Yeah, I didn’t know what that was either. So I went down the rabbit hole and learned about all the different things there are to know about dealing with time in your Rails applications. So save yourself some time (HAHA get it, get it?) and get the lowdown below.

Mo money, mo problems. This is especially the case when you’re a new developer trying to onboard onto a huge eCommerce Rails application.

No, but really - money is such a pain in the ass to deal with as a programmer. So much logic and detail goes into accepting a payment, processing a transaction, checking an order’s status…and don’t even get me started on shipping – seriously, I’m saving the entire concept of shipping for another blog post.

But, at some point or another, you have to deal with other people’s money. And you have to try and not screw it up, because apparently people really don’t like that. So, how do you handle all those dolla dolla bills? Yup, you guessed it: with the money-rails library and Ruby’s BigDecimal object.

NERD ALERT: I love databases. God, they’re just fantastic. Few things give me as much joy as an empty whiteboard and a couple of intricate join tables that need to be sketched out. But there’s also an art to understanding how to handle data – particularly when you have a shit ton of it.

The main issue people run into with data is first, how to go about storing it, and second, how to go about getting it when you actually need it! This doesn’t sound super complicated though, right? Wrong. Databases grow vertically, not horizontally, and they grow hella fast. At a certain point, the way that you go about storing your data ends up directly impacting how you go about retrieving it!

Many Rubyists write different helper methods to do their querying for them. But this is Rails Land, which means that we have black Rails magic at our disposal. And with the advent of Rails 4.1, that magic now has a name: enum.

Yesterday, I started my very first job as a software engineer! It’s been super exciting, slightly terrifying, and sometimes overwhelming. I think one of the trickiest parts of starting as a new engineer at a company is the onboarding process.

It might seem kind of scary, but if you think about it, it’s actually pretty fun. You get to dive down a rabbit hole and look at production code that you didn’t write. It’s getting a new puzzle that you haven’t solved yet: you try to figure out how one thing connects to another, where modules and methods exist, how things are namespaced, not to mention learning about new frameworks and gems. I feel like I’m entering into new dimensions and travelling through a space-time continuum or something. This also might be attributed to the fact that I’ve been listening exclusively to the Interstellar soundtrack for the past two days, but whatever – you get the point.

My favorite part of the onboarding process is how much I’ve been learning. Every new class or module definition brings a new piece of the puzzle that I’ve never seen before, but can’t wait to learn about. It’s kind of crazy that I get paid to read and learn all day, every day – that’s the dream, right?

Anyways, all of this is to say that I’ve found and learned about some cool stuff! For example this little ditty: acts_as_paranoid. I saw this in a class definition and my first thought was literally: Damn, that’s a great name for a validation! But as it turns out, it’s not actually a validation – it’s Rails magic!

There are a lot of scary things out there. To start, there are lions and tigers and bears. But if you go a bit below the surface, that’s where you’ll hit the dark stuff – the kind of stuff that I was forced to confront when I started as a student at The Flatiron School.

Sure, learning how to program is really hard – it’s not just learning another language, it’s learning an entirely new way to think. But, working on code is far easier than working on yourself. My twelve weeks at The Flatiron School pushed me to deal with some tough thoughts, most of which had always lurked in the skeleton closets of my mind: I don’t know if I can do this. I’m not cut out for this. I’m not prepared. I’m not smart enough. I won’t fit in. I can’t undersand. I won’t understand.

Most of us have all had these thoughts at some point in our lives, regardless of what we look like or what we do for a living. Some of us have stopped dead in our tracks, sometimes unable to move beyond them at all. But learning to code meant dealing with these fears on a daily basis; at some point, I just stopped listening to them entirely.