Recursion – It’s Not a Hallucination

Does recursion scare the crap out you? Well, it should! You should stop reading this now, draw the blinds, get in bed and pull the covers over your head. Just kidding! Recursion is pretty cool once you get the hang of it. I’m going to try to break it down for you so you won’t have to run and hide every time it’s mentioned.

From Wikipedia:

Recursion in computer science is a method where the solution to a problem depends on solutions to smaller instances of the same problem (as opposed to iteration). The approach can be applied to many types of problems, and recursion is one of the central ideas of computer science.

Okay, so basically it is a problem that can be broken down into smaller versions of itself. This happens when a function gets called repeatedly by itself until it reaches the stopping point, which is called the base case. So a recursive function is a function that calls itself. Every time the function calls itself, it is looking for the base case. If the base case is not found, the function calls itself again. If you think about it too long, it might make you feel like you’re hallucinating. And down the rabbit hole we go…

Think of it like a for loop, except that the function is sort of flying blind until it reaches the base case.

Enough talk, let’s see an example.

function multiplyUpToFive() {
  // (1 * 2 * 3 * 4) * 5 or
  return multiplyUpToFour() * 5;

function multiplyUpToFour() {
  // (1 * 2 * 3) * 4 or
  return multiplyUpToThree() * 4;
// and down to multiplyUpToOne()

What we’re doing here is breaking down the problem into smaller problems. That wasn’t a recursive function, but it acts the same way a recursive function does. I’ll rectify this further on. Now for our recursive function, by taking function called multiplyUpTo(n), you can say that the definition of the function is equal to taking the product of

  • the products up to n – 1
  • times n
  • Let’s see…

    function multiplyUpTo(n) {
      return multiplyUpTo(n - 1) * n;
    // let's call this with an argument of 4 and see what happens
    multiplyUpTo(3)  // gets called
    multiplyUpTo(2)  // gets called
    multiplyUpTo(1)  // gets called
    multiplyUpTo(0)  // gets called
    multiplyUpTo(-1) // gets called
    // shiiiiiit. Looks like we might be stuck in a recursive loop forever!!!

    That function would have ran infinitely because we didn’t add a base case. Think of the base case as the roof of the function. Without it the function will keep going out into space – to infinity and beyond! There’s literally nothing to stop it. Okay, enough analogies. Let’s fix our multiplier function.

    function multiplyUpTo(n) {
      // Our base case is 1, so we'll check if n equals 1
      if (n == 1) {
        return 1;
      return multiplyUpTo(n - 1) * n;
    // Now if we call our function with 4 as the argument, this is what will happen
    // n does not equal 1, so it's called again
    multiplyUpTo(3) * 4
    // Again n does not equal 1
    multiplyUpTo(2) * 3
    multiplyUpTo(1) * 2
    // We reached our base case which is 1 and our function will not repeat forever 

    Now our function knows where it is in the universe and has found its purpose in life.

    Okay, the function has purpose. Now what?

    // Once the function reaches the base case, it will now solve all of the
    // problems it left behind
    multiplyUpTo(1) * 2 // 1 * 2 = 2
    multiplyUpTo(2) * 3 // 2 * 3 = 6
    multiplyUpTo(3) * 4 // 6 * 4 = 24
    // Once the function has an answer to all of itselves (I think I made that up),
    // then it returns the product the original function call. Woah dude.

    If we’re feeling good about our JavaScript we can even use a ternary statement to really make our function compact.

    function multiplyUpTo(n) {
      return n == 1 ? 1 : multiplyUpTo(n - 1) * n;

    I like it! Thinking recursively makes you think recursively makes you think recursively. See what I did there. Yeah, I’m a dork. Hopefully this helped you understand the world of recursion. It’s quite fun to write algorithms this way. Although it might be scary at first, don’t worry: The worst that can happen is you float away into the infinite:)


    The Art of Forgetting

    I had a mini-technical interview last week for a backend developer role using Ruby as the main language. While the questions were not very tough, it’s been a while since I had to explain technical concepts – especially under pressure.

    Unfortunately, we don’t get too many do-overs in life, but we can learn from the past and keep moving forward. When we face the same problem in the future, we can hopefully handle it better. What can we do to help our future selves? One thing we can do is write about things we have learned. This will hopefully plant them more firmly in our minds. I thought I’d write out the questions and answer them how I would have liked to have answered them if I could answer them again. Whew. Without further ado, let’s jump in.

    First question – Which http status codes exist and what do they mean?

    I admit, it was a pretty easy one – just a general, low-level question. I had an ok answer, but I’ll give it another go. Http status codes range from 100 to 500. The most common codes being in the 200, 400, and 500 ranges. A 200 means the request went through successfully – not much more to it than that. Anything in the 400’s means that the connection to the server was ok but request was not good from the client. This could be anything ranging from an incomplete form to one of the most common – a 404 – which means the path was not found. Basically, if we type in an address such as, the request will hit the server and the path (alskdjf) will try to be found. In this case it won’t and the request will come back as a 404. Most developers will take this into consideration when building a website/web app and route you to their 404 page.

    Screen Shot 2018-10-19 at 4.53.57 PM’s 404 page

    An http status code in the 500’s means that there was an Internal Server Error. It could be that the server is down at the moment, or quite possibly it just doesn’t like you:)

    Second question – What http methods are there?

    It should have been another layup. Again, my answer was ok, but I’ll try again. There are quite a few http methods, but the most common ones used for RESTful architecture are GET, POST, PUT, PATCH and DELETE.

    Follow up – What is the difference between POST, PUT, and PATCH?

    A POST request will create a new resource at the provided URI. So let’s say we are creating a new account on Facebook. When we fill out our information and hit submit, a POST request will be sent to create a new resource in the database with our info. A PUT request will either find the existing resource and replace the whole resource with the new one. Or if the resource doesn’t already exist, a new one will be created. A PATCH request will update an existing resource. Say we want to update our email address on our FB profile. When the PATCH request goes through, it will find our existing information and update just the email portion of the resource – not the whole resource.

    Third question – What does indexing do?

    Welp, I’ve actually been using indexes quite often with MarkLogic (eek!), but my mind turned turned off at this point. I think I said something about primary keys in a table and associations between tables. As soon as I stopped talking I knew I was way off. Let’s try that again.

    Indexing is used to speed up data retrieval from the database. Think of a book. Now imagine we wanted to find the page that a certain topic was on. What would we do? We would go to the index and find what page it was on! Now imagine this book didn’t have an index. We would be forced to scan every page in the book to try and find what we were looking for. This is very similar to what would happen if we didn’t have an index on our table.

    Indexing is configured by putting a data structure on a column in a table. This data structure, in most cases a B-tree, acts as a pointer to data in a table. For example, we visit FB and we want to look up an acquaintance in the search bar by their last name. Let’s say our acquaintance’s last name is “Yorke”. If the “last_name” column is not indexed in the table, the query will have to run through every single row in the table to find the users with the last name of Yorke. With billions of users stored in the table, that could take some time. However, if the “last_name” column is indexed, the query will run significantly faster.

    Fourth question – Explain composition over inheritance

    I knew I read about these concepts last year when I was studying a few design patterns, but in the heat of the moment, I just couldn’t recall. I think I mumbled something about classical inheritance being bad…something, something, something. It’s amazing what a little refresher will do!

    Both composition and inheritance are design patterns in Object Oriented programming that we can use to keep our code DRY. In other words, they let us reuse code but in very different ways.


    With inheritance, types are defined by what they are. So let’s say we have a monkey. Well, a monkey is an animal, so monkeys can inherit characteristics that all animals share. That sounds pretty reasonable to me, so what’s the issue?

    One of the arguments against inheritance is that things might change down the line. We are forced to predict future behavior of our classes without having all of the information we may need. The example above is a very simple one, but in the real world, we would most likely have an inheritance tree. Imagine the whole animal kingdom mapped out this way using inheritance. If we had to make any changes in the base class, it would likely have consequences for all the subclasses and quite possibly break much of our code. This makes inheritance very inflexible as a design pattern because we can’t make changes without breaking a lot of our code.

    So should we avoid inheritance like the plague? Nope, not at all! Like any tool, we just have to use it wisely. We wouldn’t use a hammer if all we had were screws. The rule of thumb here is to use inheritance if you have a shallow tree and you know for sure that your parent class isn’t going to change. If we shouldn’t use inheritance, what should we use?


    We learned earlier that when we use inheritance, our types are defined by what they are. When we use composition, our types are defined by what they do. Here we don’t have to predict the future behavior of our classes, which will leave us with many less headaches down the line. We can pick and choose what are objects look like based on what they do. Maybe all we need our monkey to do is see, swing from a tree and eat a banana. Our Monkey class will only be given these methods – and only these methods. Now our monkeys are lean and not weighed down with a ton of baggage they ultimately won’t use.

    Forget Me Not

    To my future self – You’re welcome.

    Rails, AngularJS (1.5.8), and Webpack — Part 4

    Okay. We left off last time actually seeing Angular working with webpack. Things were looking good – in a very basic “Hello World” kind of way. Today, we’re going to create a controller and a component to make an http request to hit up the backend for some data. First, let’s create some data.

    Seeding the Database

    Heading back to Rails land briefly to create some users and meals. In app/db/seeds.db let’s make a couple of arrays and then use a looping method to create our Users and Meals at the same time.

    # app/db/seeds.rb
    users = ["Luke", "Han", "Leia", "Obi", "Chewbacca", "C3P0"]
    # Our users array from a galaxy from far far away
    meals = ["Tattooine Tacos", "Chewie's Chowder", "Princess Pizza", "Darth's Death Stack", "Brain du Jar Jar", "R2's Nuts and Bolts"]
    # Our meals array with some interesting looking delicacies
    i = 0
    6.times do
      UserMeal.create(user_id: User.create(name: users[i]).id, meal_id: 
      Meal.create(title: meals[i]).id)
      i += 1

    Here we are using our two arrays and a loop to create not only a new User and Meal each go round, but the association between each one too. Now we can run ‘rails db:seed’ in our terminal and our database should be seeded. If we go into our rails console (‘rails c’ in the terminal), and type ‘User.first.meals’, we should see something like this:

    => #<ActiveRecord::Associations::CollectionProxy [#]>

    Cool! Our seeding experiment worked and our associations seem to be solid. Let’s take it one step further and get the actual name of our first user’s meal – ‘User.first.meals.first.title’

    => “Tattooine Tacos”

    Sweet! We are finished with the backend for now. Let’s get this front end party going!

    Creating a Controller

    First we’ll create our controller and use Angular’s built in $http service to get data from the backend. We have to use ngInject to inject the $http service into the controller. Then we’ll use $onInit to set up the call to the api. In app/javascript/packs, we’ll create a new file called ‘home.controller.js’. Then we’ll add our controller and export it, so it can be imported wherever we want it.

    // app/javascript/packs/home.controller.js
    class HomeController {
      constructor($http) {
        this.$http = $http;
      $onInit = () => {
          method: 'GET',
          url: '/users.json'
        .then(res => {
          this.users =
        .catch(err => {
    export default HomeController;

    $onInit is a lifecycle hook that initializes on start up. So our $http call will happen when the HomeController is called upon. The $http call takes one argument, a configuration object consisting of a ‘GET’ method and a url, to make the HTTP request and returns a promise. For a successful promise, we use ‘then’. For an unsuccessful promise, we use ‘catch’. I believe the old standard was ‘success’ and ‘error’ to handle promises.

    Now we need to output be able to output our data into a template. Stand alone templates are not used with modules. Instead, we’ll use a simple component.

    Creating a Component

    Let’s create a new file called ‘home.component.js’ in the same folder as our other Angular files. Then we have to import the HomeController and create the component. Components are very simple, as we’ll see. They basically point to a variable, which we’ll then export. Our component will take three properties: controller, controllerAs, and template. Components could take more properties, but we won’t need anything more for our needs. Our users will be coming to us in an array, so we’ll have to loop over this array to get each user. Angular comes with a very handy ng-repeat, which can be inserted right into the html.

    // app/javascript/home.component.js
    import HomeController from './home.controller';
    const HomeComponent = {
      controller: HomeController,
      controllerAs: '$ctrl',
      template: `<div ng-repeat="user in $ctrl.users">
    export default HomeComponent;

    This should give us what we need. Now we have to import our component to our main app module and we should see something in our browser.

    Importing Component into Main App Module

    Let’s head over to our meals module and see what we can do. In app/javascript/packs/application.js, we’ll import the home component under our angular and uirouter imports. Then we’ll add our component to the meals module so we can use it in the router.

    import angular from 'angular';
    import uirouter from 'angular-ui-router';
    import HomeComponent from './home.component';  // New
    const meals = angular.module('meals', [uirouter])
      .component('homeComponent', HomeComponent) // New
      .config(($stateProvider) => {
          .state('home', {
            url: '/',
            component: 'homeComponent' // New
    export default meals;

    I added a ‘New’ comment next to the lines that were added. Notice that we still had to add the component to the module. Then we used the stringified name and added it to our ‘home’ route as a component. Let’s run the servers and see if we have anything.

    Remember, we need to run two servers – one for the front end and one for the back. In one tab in your terminal run ‘./bin/webpack-dev-server’ and in another tab, run ‘rails s’. Refresh the browser, click home and….


    Nice! We got some JSON! We’re on the right track. Now all we have to do is get the name out of each object. To do that, we’ll have to modify the template in our component ever so slightly.

    // app/javascript/home.component.js
    import HomeController from './home.controller';
    const HomeComponent = {
      controller: HomeController,
      controllerAs: '$ctrl',
      template: `<div ng-repeat="user in $ctrl.users">
    export default HomeComponent;

    If you can’t see what was added, no worries. In the

    tag we were getting the whole user, which is why we got all that extra JSON. The only thing that was added was a name attribute to the user – {{}}. These things update live, so if we look back to the browser, we should see our Star Wars heroes.

    An Aside

    This actually took me quite a while to get running. I’m learning as I go and had some trouble understanding how to use $http in the controller. Specifically, how to inject it. Everywhere I looked, people were saying the same thing: outside of the HomeController class, inject the $http service as such – HomeController.$inject = [“$http”];

    This did not work. I finally came across a someone’s code with ‘ngInject’ loaded in the constructor. I tried that, and everything worked!

    We’ve gone through a lot today and I’m going to leave off here. Next time we’ll separate the $http call into a service, as it should be and see our Chewbacca’s favorite meal. Until then…Cheers:)

    Bootstrap 4

    The continuation of the AngularJS, Rails, Webpack tutorial will be back next week. I have been working on a site this week and it was my first foray into Bootstrap 4. I didn’t know what I was getting into at first. I thought, like most updates, that the power of the framework just got stronger and things got easier. Little did I know that it was a complete rewrite!


    The Bootstrap 4 rewrite takes advantage of the Flexbox model, something I haven’t delved into much so far. What does it mean for using our beloved containers, rows, and columns? Not much. Things might look different behind the scenes, but up front things mostly look the same. One major thing to think about when migrating a site or starting a new site with Bootstrap 4 is that it is not compatible with Internet Explorer versions 8 and 9. Personally, I wish IE would die a quick death.

    Cool Changes

    Much has been dropped from Bootstrap 4 as the web has moved on from certain things. To see a full list, check it out here. One thing I thought that was cool is the less bulky navbar. This is how we’re used to seeing the HTML for a navbar…

    <nav class="navbar navbar-toggleable-md navbar-light bg-faded">
      <button class="navbar-toggler navbar-toggler-right" type="button" data-toggle="collapse" data-target="#navbarNav" aria-controls="navbarNav" aria-expanded="false" aria-label="Toggle navigation">
        <span class="navbar-toggler-icon"></span>
      <a class="navbar-brand" href="#">Navbar</a>
      <div class="collapse navbar-collapse" id="navbarNav">
        <ul class="navbar-nav">
          <li class="nav-item active">
            <a class="nav-link" href="#">Home <span class="sr-only">(current)</span></a>
          <li class="nav-item">
            <a class="nav-link" href="#">Features</a>
          <li class="nav-item">
            <a class="nav-link" href="#">Pricing</a>
          <li class="nav-item">
            <a class="nav-link disabled" href="#">Disabled</a>

    It’s so bulky, right? Well check this out…

    <nav class="navbar navbar-toggleable-md navbar-light bg-faded">
      <button class="navbar-toggler navbar-toggler-right" type="button" data-toggle="collapse" data-target="#navbarNavAltMarkup" aria-controls="navbarNavAltMarkup" aria-expanded="false" aria-label="Toggle navigation">
        <span class="navbar-toggler-icon"></span>
      <a class="navbar-brand" href="#">Navbar</a>
      <div class="collapse navbar-collapse" id="navbarNavAltMarkup">
        <div class="navbar-nav">
          <a class="nav-item nav-link active" href="#">Home <span class="sr-only">(current)</span></a>
          <a class="nav-item nav-link" href="#">Features</a>
          <a class="nav-item nav-link" href="#">Pricing</a>
          <a class="nav-item nav-link disabled" href="#">Disabled</a>

    Notice anything missing? Well the top half is the same, but take a look at the links. No more ul’s and li’s. This is because they use classes for the navs now.

    You can also size very easily with inline attributes. 25%, 50%, 75% and 100% widths and heights can be achieved by using ‘w’ for the former and ‘h’ for the latter. Then just add a dash and the desired number, such as h-100. Here’s an example.

    <div class="w-25 p-3" style="background-color: #eee;">Width 25%</div>
    <div class="w-50 p-3" style="background-color: #eee;">Width 50%</div>
    <div class="w-75 p-3" style="background-color: #eee;">Width 75%</div>
    <div class="w-100 p-3" style="background-color: #eee;">Width 100%</div>

    Screen Shot 2017-10-06 at 3.41.21 PM

    And for heights…

    <div style="height: 100px; background-color: rgba(255,0,0,0.1);">
      <div class="h-25 d-inline-block" style="width: 120px; background-color: rgba(0,0,255,.1)">Height 25%</div>
      <div class="h-50 d-inline-block" style="width: 120px; background-color: rgba(0,0,255,.1)">Height 50%</div>
      <div class="h-75 d-inline-block" style="width: 120px; background-color: rgba(0,0,255,.1)">Height 75%</div>
      <div class="h-100 d-inline-block" style="width: 120px; background-color: rgba(0,0,255,.1)">Height 100%</div>

    Screen Shot 2017-10-06 at 3.41.43 PM

    I’ve been working a lot this week so I’m going to leave it off here. I’ll be back next week for the continuation of the tutorial. Peace!

    Rails, AngularJS (1.5.8), and Webpack — Part 3

    Alrighty then. Where were we? I believe we left off in a good place. We installed the webpacker gem, and seemed to have communication between our newly created JS file and our app. Now for the hard part. I’m still learning this stuff myself, so bear with me. We’re going to attempt to use ES6 modules instead of the old way of declaring AngularJS components and such. This style guide is a good starting point to get to know what your components will look like and how they’ll interact with each other.

    Setting up the Main Module

    The first thing we’ll want to do is setup up our main Angular module in app/javascript/packs/application.js. First we have to import angular into the file so our module knows what it’s attaching itself to. We are also going to export the module, which will allow our webpack to compile it when we run app in the terminal.

    // app/javascript/packs/application.js
    import angular from 'angular';
    const meals = angular.module('meals', [])
    export default meals;

    Now we have to declare our app in our main html file: app/views/layouts/application.html.erb. So in the body tag, add ng-app=”meals”.

    <!DOCTYPE html>
        <%= csrf_meta_tags %>
        <%= stylesheet_link_tag    'application', media: 'all' %>
        <%= javascript_include_tag 'application' %>
        <%= javascript_pack_tag 'application' %>
      <body ng-app="meals">
        <%= yield %>

    Now our app knows that it’s an Angular app and it’s looking for a module called ‘meals’. Let’s add a route with a component so we can actually see something working on the Angular side of the world.

    Routing With angular-ui-router

    If you’ve built anything with Angular in the past, you’ve most definitely used angular-ui-router. We’re going to install it with yarn. If you don’t have yarn installed, check out the installation instructions here. To install, or ‘add’ as it’s called in yarnish, head over to your terminal and type: ‘yarn add angular-ui-router’. If you check your dependencies in your package.json file, you should see ‘angular-ui-router’ listed.

    So let’s see if we can get a route working. In our angular_home.html file, let’s add a ui-view directive.

    <-- app/views/application/angular_home.html -->

    This will give us an entry point into AngularLand and let us declare routes with $stateProvider in a config function. Back in our application.js file, let’s add a config function and a route. First we’ll have to import the ui-router so we can use all of its goodness. Check it…

    // app/javascript/packs/application.js
    import angular from 'angular';
    import uirouter from 'angular-ui-router';
    const meals = angular.module('meals', [uirouter])
      .config(($stateProvider) => {
          .state('home', {
            url: '/',
            template: `<h1>Hola Mundo!</h1>`
    export default meals;

    Ok so here we’re importing the angular-ui-router and chaining a config function onto our module. Angular-ui-router gives us access to $stateProvider, $urlRouterProvider, $state, and $stateParams. In the config function above, we’re using the Arrow function syntax now available in ES6, and setting the state. With a url and a simple template, we should be getting somewhere. Let’s quickly make a link back in angular_home.html so we can see our route is working.

    <-- app/views/application/angular_home.html -->
    <a ui-sref="home">Home</a>

    Run the Webpack and Rails Server Simultaneously?

    Now to run webpack, we can’t just run the rails server. We actually have to run the rails and the webpack servers. Back in the terminal, create a new tab in the same directory, then run ‘./bin/webpack-dev-server’. This will compile your included javascript files through webpack. If you’re like me, then you probably got a lot of red errors followed by this line: webpack: Failed to compile.

    So something is not letting us load our module. If we scroll up in the terminal, we’ll see that most of the errors say that angular doesn’t exist. But I thought we installed Angular already!! Well, I’m pretty sure that when we installed it with the webpacker command, it installed Angular 4. We need version 1.5.8, which we can easily install add with yarn. Exit out of the webpack server in your terminal. Then type ‘yarn add angular@1.5.8’.

    Check out your package.json file and you should see angular with the correct version listed under the dependencies. Now if we try to run the server again – ‘./bin/webpack-dev-server’ – everything should compile (there might be a few warnings, but let’s not worry about those). In your other tab run the rails server command and in your browser go to ‘localhost:3000’. You should see a link that says ‘Home’. Click it, and you should be routed to the home route that we set up earlier. If you followed along, you should see ‘Hola Mundo!’ on the webpage!

    To Sum it Up

    We are in the Angular business now! In this episode, we’ve connected the front end to our meals app with webpack, added angular-ui-router and AngularJS, created our main module with a route and template, learned how to run the webpack server, and saw our template working in the browser. Next time, we’ll get some functionality going with some http requests to the backend and do something a little more exciting than Hello World Hola Mundo. As always, thanks for reading. I hope this helps someone out there! Until next time…CHEERS:)

    Rails, AngularJS (1.5.8), and Webpack — Part 2

    Welcome back! We left off last time in a good place. We set up the back end by generating three models – User, Meal, and UserMeal (our joins table) – with associations. We used scaffolding to generate our models. In most cases, we would normally not generate models using scaffolding, because it creates a lot of things we won’t need. This causes bloat in our app, and if we want our app to scale nicely and be fast, this will be a problem. For our case (and our little app), it’s nice and easy to use scaffolding – so we did. Then we installed a great gem called Active Model Serializer, which formats our model data into reusable JSON, which our front end will consume. In this edition we’ll be installing AngularJS and Webpack. Let’s dive in.


    A few blog posts ago, I wrote about Rails and the Webpacker gem. The team at Rails is definitely catching on to the current and future trends of the web – front end frameworks using JavaScript. The Webpacker gem makes it easier to use these frameworks with Rails. Enough talk though – let’s install it! Note – if you’re using Rails 5.1, you can run ‘rails new myapp –webpack=angular’ when initiating your app. Otherwise…

    # In your gemfile.rb file, add 
    gem 'webpacker'
    # Back in your terminal
    bundle exec rails webpacker:install
    # if you get an error that looks like this: 'Webpacker requires Yarn >= 0.25.2 
    # and you are using 0.24.6
    # Please upgrade Yarn'
    # do this:
    npm install -g yarn
    # if everything is honky dory
    bundle exec rails webpacker:install:angular

    Now we’re in the webpack business. Using webpack basically creates another asset pipeline for our JavaScript assets. Instead of putting all of our JavaScript files in /app/assets, we’ll put them in app/javascript/packs. To include this folder, all we have to do is include them in our main html files ‘head’ section.

    # app/views/layouts/application.html.erb
    <%= javascript_pack_tag 'application' %>

    Now our files will be included and we can get coding. Let’s create the entry point to the angular app. Create a new folder and file in our views folder:
    app/views/application/angular_home.html. Now we need a route. Let’s add it to our routes.rb file.

    root to: 'application#angular_home'

    Let’s add something to our angular_home file.

    # app/views/application/angular_home.html
    Goodbye World
    # LOL?

    Now run ‘rails s’ in your terminal and head on over to ‘locahost:3000’ in your browser. We should see ‘Goodbye World’ on the webpage. Now look in the console (Apple Control ‘J’) and you should see ‘Hello World from Webpacker’. We’re in business.

    I think this is a good place to leave off. Our backend is set up. Webpack is setup. We have an entry point to Angular. Things are looking good. Next week we’ll dive head first into Angular. Working with modules and all the goodness that comes with ES6! Until then…cheeeeeers:)

    Rails, AngularJS (1.5.8), and Webpack — Part 1

    In my last post, I wrote about using Webpack with Rails and AngularJS, and how it differed from using Bower. There is definitely a bigger learning curve using Webpack, but I believe it will all be worth it when the dust settles. Besides, it seems that Bower has been deprecated. I’m going to try my hand at a tutorial using these three technologies and share my confusion as we go. ES6 syntax will be used in Angular also, which changes how we write our components. Let’s dig in.

    The Setup

    I’ll assume that you have Rails installed already. We’re going to build a simple CRUD app using Rails as an API on the back end, and AngularJS on the front end and Webpack to bridge the two. We’re going to build a Meals app, with a users table and a meals table. It’s simple but what we want out of this is to be able to use these technologies together – then we can start adding complexities.

    ‘cd’ into you directory of choice and start a new rails app:

    rails new meals --skip-turbolinks

    We’re skipping turbolinks because it can cause trouble with Angular. Now that the basic Rails skeleton is created, ‘cd’ into ‘meals’ and open Atom (or your text editor of choice). The version of Rails I’m using is 5.0.6. I’m using the built-in database – sqlite3 – because using Postgres would be adding another complexity to this that we don’t need. Let’s make our first commit to github. I’ll assume you know how to start a repo.

    git add .
    git ci -m 'initial commit'
    git remote add origin
    git push -u origin master

    Now let’s create our models. I usually don’t use ‘scaffold’ to generate my models because it adds so much bloat to Rails, but I’m going to use it because it’s so easy – that’s what we’re going for.

    rails g scaffold user name:string
    rails g scaffold meal title:string
    rails g model user_meal user_id:integer meal_id:integer
    rails db:migrate

    Like I said – super basic. Now that the databases are created, let’s enter the rails console in the terminal and create our first user and meal.

    rails c
    User.create(name: 'Allison')
    Meal.create(title: 'Pizza')

    As long as we migrated our database, these commands should work, which means we’ll have our first user and meal. Now we have to think about the association between these two tables. Well, users have many meals and meals have many users. So, it’s a has many to has many relationship. Let’s go into our models and add the associations.

    class User < ApplicationRecord
      has_many :user_meals
      has_many :meals, through: :user_meals
    class Meal < ApplicationRecord
      has_many :user_meals
      has_many :users, through: :user_meals
    class UserMeal < ApplicationRecord
      belongs_to :user
      belongs_to :meal

    Let’s try to add a meal to our first user…

    rails c
    UserMeal.create(user_id: 1, meal_id: 1)
    # created an association in our joins table for the first user and first meal
    # Now we can see the first users meals
    => #<ActiveRecord::Associations::CollectionProxy [#<Meal id: 1, title: "Pizza", created_at: "2017-09-17 22:51:13", updated_at: "2017-09-17 22:51:13">]>

    Alright! Our models are working as they should, so the next step is to serialize our models into an API so they can be consumed by our front end. We’ll use the wonderful Active Model Serializers for this. Of course there’s a gem! Add this line to your gem file:

    gem 'active_model_serializers', '~> 0.10.0'
    bundle install

    Now let’s create our serializers.

    rails g serializer user
    rails g serializer meal
    rails g serializer user_meal

    This generated serializers for our three models. Let’s add our associations.

    class UserSerializer < ActiveModel::Serializer
      attributes :id, :name
      has_many :user_meals
      has_many :meals, through: :user_meals
    class MealSerializer < ActiveModel::Serializer
      attributes :id, :title
      has_many :user_meals
      has_many :users, through: :user_meals
    class UserMealSerializer < ActiveModel::Serializer
      attributes :id
      belongs_to :user
      belongs_to :meal

    Now we have our associations set up. Let’s run our local server and see what we have. Run ‘rails s’ in your terminal and go to ‘http://localhost:3000/users/1.json&#8217; in your browser. This should give us our first users information in JSON format. It should look something like this:

    id: 1,
    name: "Allison",
    created_at: "2017-09-17T22:50:16.012Z",
    updated_at: "2017-09-17T22:50:16.012Z",
    url: "http://localhost:3000/users/1.json"

    Ok that’s cool, we have some JSON! The only thing is we can’t see our user’s meals. Let’s fix that! Open up your users controller and add this to you show method:

    if @user
      render json: @user, include: { meals: [:title] }

    Now refresh your browser and voila!

      id: 1,
      name: "Allison",
      meals: [
        id: 1,
        title: "Pizza"

    Sweet! We can see our associations! Our back end is fully functional and is set up as an API. This JSON formatted information can now be consumed by our front end. This concludes the first part of this series. I’ll be back next week for part 2. We’ll get our hands really dirty setting up Webpack and Angular. Until then…Cheers:)

    Rails, AngularJS and Webpack – First Impressions

    I recently started learning React because it seems like it’s the new ‘it’ technology in town. My previous front end framework knowledge was limited to AngularJS. It took me some time to like it, but eventually I did. I might have an interview soon and the technologies the company uses are mainly Rails and AngularJS(v1.5). This has made me go back to Angular and start building again. It’s amazing how fast information leaks out of ones head.

    The first thing I noticed when starting a project was that Bower has been deprecated. I knew that Bower was on its way out when I learned AngularJS, but that was only a few months ago. Things certainly change fast in the world of technology.

    Note to self: don’t get too comfortable with any technologies you use.

    So what to do? How should I handle my front end dependencies? There are many ways, some of which are already on the outs too – like Gulp. After doing some research it seems like the wave of now and the near future is Webpack. Even Rails is getting in on the action by including it with Rails 5.1. Rails is still in heavy use in the industry, however has seen some decline from the glory years. Most of the decline in usage has to do with all of the front end technologies that have sprouted up in the last five years. Rails was not keeping up with the trends and Rails’ dependency on the Asset Pipeline – once the best thing since sliced bread – was now hindering development.

    Well, guess what? The team behind Rails has finally caught on and the inclusion of the Webpacker gem is a huge step in the right direction. I could see a big boost in Rails usage as a result. That’s great and all, but what does Webpack actually do? From the Webpack github page:

    webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset.

    When using Rails, it basically creates another asset pipeline for JavaScript files. Whenever learning something new, there will be a learning curve and some frustration involved. In my case, using Rails 5.0.1 and AngularJS(1.5.8), there has definitely been a bit of both. Especially since there’s not much documentation or tutorials for the versions I’m using. I’m finally making some headway and actually have a basic app running in my browser. There’s much more importing of files and such going on, which I became familiar with through React. This week I’m going to become much more familiar with the inner workings.

    My next blog post will be a tutorial on getting Rails(5.0.1), AngularJS(1.5.8) and Webpack to all play nice together. Have you built anything with these technologies? Please comment below, I’d love to hear about it! Until next time…Cheers:)