DEV Community: crespire

One Year of Toronto Ruby

crespire — Sat, 26 Oct 2024 01:48:48 +0000

Editor's Note: This blog post was also published on my personal blog.

As we approach November, it's hard to believe that it has been almost one year since our very first Toronto Ruby meetup! It all began as an idea to rebuild the local Ruby meetup scene, and has evolved into a dynamic and vibrant community effort that's met almost every month throughout 2024! It's been such a privilege to be at the helm of this effort, and it's been a rewarding journey filled with learning, collaboration, excitement and a whole lot of passion for the local Ruby and Rails community. I'm grateful for how far we've come, and I'm very excited for what's still to ahead.

We've been really fortunate to be able to host events with a regular cadence and have been able to attract a great audience, as well as excellent speakers presenting a wide range of Ruby and Rails related topics. From newcomers to seasoned developers, it’s been inspiring to see such a diverse group come together each month. The enthusiasm and passion that everyone brings has been a driving force behind this growing community. Seeing everyone connect, share ideas and learn from others has definitely been a highlight!

Reaching the one year mark is a testament to the community and everyone who has taken the time to attend and support our events. I also want to give a special shoutout to our speakers and presenters, who have freely shared their expertise and interests with the group. The meetup would not be as lively and interesting if you all didn't step up to share!

As we look ahead, I'm excited about where we'll go, the places we'll see and all the new and interesting things we'll learn together. Hopefully, we'll have more varied topics and formats, as well as more community events.

As for our one year anniversary, plans are afoot! If you want to come celebrate with us, join our mailing list at Toronto Ruby's website and we'll announce something when we're ready!

Launching Toronto Ruby

crespire — Thu, 02 Nov 2023 01:35:19 +0000

I'm so pleased to announce that we have our inaugural meeting booked and we are excited to see you! You can learn more about our event and sign up for our events mailing list at https://toronto-ruby.com/ - I hope you'll consider joining us!

I'm so excited to write this as it's been something I've dreamed about since I started my professional journey with Ruby and Rails.

The one thing I know for sure, in tech, a community can take you very far! Whether you're learning or working, community is place where you can recharge, learn and grow. Finding like-minded folks to learn and grow_with_ is an integral part of sustained and happy professional growth.

Without a community, new techniques or ideas may not come across your desk as much. You might not have an outlet to share and learn about the problems you're facing day to day, or to share your ideas about that one really cool feature that you've been working on.

As a new Ruby dev, I was very disheartened to learn that the local Toronto Ruby community had been inactive for quite some time and I craved this kind of connection.

I am so eager to connect with folks who love and use Ruby every day! I'm grateful to have the support of so many wonderful folks to launch this venture. The language is still alive and well, and while I felt alone, I am hoping that my big dream will help others. It's time we said it: We're here and we love Ruby, still. Yes, in 2023!

Our vision is to provide a place for the GTA Ruby community to flourish, learn and grow together; be a place where folks can make friends and find others that love Ruby!

I'm really looking forward to seeing folks at our inaugural meetup, and I hope you'll consider joining us for more of our future events.

Hooking in to Devise controller actions

crespire — Thu, 17 Aug 2023 16:25:26 +0000

Devise is a fantastic authentication gem in the Rails ecosystem that I'm learning more about every day!

I wanted to share how I was able to solve a problem effectively after reading some Devise source code, as it might come in handy for others.

The problem

I was working on a project using the Devise addition invitable and I needed a way to update a user's profile after they accepted an invite so I could set the slug based on their name. When the user invite is created, we use a generic value as a filler for the name.

I had originally used an ActiveRecord callback, but this felt clunky. Not only was it difficult to understand what it was doing, the side effect of the callback happened on the Profile model! That would be hard to debug if it was your first time working on the app and something was going wrong with the Profile's slug generation.

I began searching for ways to do what I wanted without callbacks and I decided to take a look at the Devise controllers source code.

The solve

It turns out, Devise anticipates that you might want to access a resource while it's doing its thing, and so almost every Devise controller action has a line like this:

yield resource if block_given?

This is fantastic! Because we often inherit from the base Devise controllers, what this line does is let you access the resource under operation if you pass in a block:

# sample controller
class Users::RegistrationsController < Devise::RegistrationsController
  def update
    super { |resource| ... }
  end
end

This was a game changer! I now had a great way to update the profile's slug with the user's provided name:

# app/controllers/users/registrations_controller.rb
def update
  super { |user| user.profile.update(slug: user.full_name.parameterize) }
end

Just like that, I was able to get rid of an ActiveRecord callback! So, if you ever need to access the resource to do something inside a Devise controller, this is your ticket.

Dockerizing a Simple Rails Application for Deployment

crespire — Sun, 08 Jan 2023 21:28:25 +0000

New to docker and docker compose? It can be a lot to figure out, and while there are lot of great resources out there (at least 3 different articles on how to dockerize an existing Rails application!), many of them are fairly tearse or assume a very high level of comfort.

For me, I knew the high level why behind docker, and even conceptually how it worked, but when I got into the weeds, I quickly got lost. So, dear reader, I thought I'd try to take a stab about explaining how to dockerize a Rails app, trying to fill in the gaps from the resources I was able to take in plus a lot of helpful guidance from various programming communities (Shoutout to Dave Kimura on Rails Link slack!).

What is docker?

Docker is a way to containerize applications so that they are easy and portable to run or deploy. The basic idea is that you can build an image based on some application code, which is then the basis for the container that later runs the code.

The Dockerfile is the first thing you'll likely come across when trying to containerize an application. Docker has an excellent documentation site that goes over the details of the many options available. But what made the Dockerfile intelligible to me was to think of it as the compile step. The Dockerfile, in essence, is the recipe for how to assemble and set up your image, which is then run inside of a container. So, thinking about the Dockerfile as the recipe that forms the basis of your image where you can define things like environment variables, what sorts of software you should also have available in the container when it's running, etc. All of that is defined in your Dockerfile.

One of the things I had trouble with when trying to figure out docker was how I should set up the container after it's spun up. Some of the tasks I wanted to accomplish (like creating and migrating the database for a Rails app, for example) seemed to belong to the "setup" stage, and so I initially tried to put them in the Dockerfile. This was not the right way to go about it, though I was somewhat close. You see, the trouble is when you are building an image, the image under construction doesn't (and shouldn't!) have access to any other image. That means, you don't really have access to the database instance, as it isn't running! Remember, this is because the Dockerfile is the recipe for building the image, and can be thought of like compile time. It's not really compiling in the classical sense, but it's somewhat analogous. In that case, then, something like setting up the database could be thought of as a run time concern. It requires that the database is available before we attempt to use it.

Well, Docker does provide a handy ENTRYPOINT option in the Dockerfile and that is one of the ways you can solve this compile/run time, but both are setup tasks kind of issue. There are better tutorials out there than what I can offer, but all you need to do is make sure to include an entry point script inside the image, make sure it has execution privileges, and you can put setup commands in there. We'll re-visit ENTRYPOINT in depth later in this article.

So, that's the theory. Let's talk about how that applies to an actual Rails app.

Show me the Rails!

Let's talk a little bit about what sort of app we're going to be setting up. The application I have in mind is a Rails 7 monolith that uses a PostgreSQL database to store data. The application that serves as the sample for this post won't include redis. As I said, it's a simple Rails app.

So, with that said, let's say we have a Rails app that fits the bill. You can run rails s and puma dutifully fires up in development mode, and you can visit the app at localhost:3000 and it talks to a PostgreSQL database and everything works as you expect - great! Let's see if we can dockerize it!

So, how do we go about containerizing this application? The first step is to set up a Dockerfile which describes the recipe to make the entree, as it were.

Dockerfile

Here is a sample file from my simple application which we will talk through step by step after:

# Specify base image
FROM ruby:3.0.2

# Add application code
ADD . /rails-app
WORKDIR /rails-app

# Install utilities
RUN apt-get update
RUN apt-get -y install nano

# Install dependencies
RUN bundle install

# Precompile assets - only required for non-API apps
RUN rake assets:precompile

# Set up env
ENV RAILS_ENV production
ENV RAILS_SERVE_STATIC_FILES true
ENV RAILS_LOG_TO_STDOUT true

COPY ./bin/entrypoint.sh /usr/bin/
RUN chmod +x /usr/bin/entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]

# Expose port
EXPOSE 3000

# Run server when container starts
CMD ["rails", "server", "-b", "0.0.0.0"]

Whew, that was a lot. Okay, so what does this file mean?? Let's break it down.

FROM ruby:3.0.2

The first line is simple, it specifies the base image from which we build our final image. Here, because the application runs on Ruby 3.0.2, we specify that ruby version as a base image. These base images are maintained by folks much smarter than I, and you can check out all of the details on Docker Hub, which hosts these images.

ADD . /rails-app
WORKDIR /rails-app

These two lines work in concert to set the container up. The first line ADD copies files from your local file system (notice the . which means "this directory") to the container's file system: /rails-app. After we've copied our code over, we set the container's working directory to what we just set up: WORKDIR /rails-app. Right, simple so far!

The next two lines are optional, but I find value in having nano inside the container so I can edit stuff if required.

RUN apt-get update
RUN apt-get -y install nano

Basically, we run these two shell commands to install the nano command line editor inside the container.

The next two lines deal with our Rails app specifically, but we just run the two commands as if we were in the working directory of the application on container:

RUN bundle install
RUN rake assets:precompile

The commands first install the gems we've specified in our Gemfile which was copied from our host directory, and then precompiles assets. Note that this line is only required if you have assets in your Rails app (CSS, Javascript, etc). For API only applications, this line should be commented out.

The next set of lines set up a few environment variables we want to use and are pretty straight forward.

ENV RAILS_ENV production
ENV RAILS_SERVE_STATIC_FILES true
ENV RAILS_LOG_TO_STDOUT true

One note is that it is typically a good idea when using docker to log to a container's stdout because that enables us to use logging aggregation drivers. It's a bit more of an advanced usage, but docker offers us ways to easily access a container's stdout and having logs go there mean we can use built-in docker methods to handle our logging in concert with the other containers.

The next set of lines are interesting, and took me a bit to understand. Here they are again:

COPY ./bin/entrypoint.sh /usr/bin/
RUN chmod +x /usr/bin/entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]

And for completeness sake, here is the entrypoint.sh that I am using:

#!/bin/bash
# Exit on any error
set -e

# Remove a potentially pre-existing server.pid for Rails.
rm -f ./tmp/pids/server.pid

# Make sure db is ready to go
# Adding '2>/dev/null' sends output to nowhere in the case of an error and the
# error code also triggers the bash OR to run db:setup
bundle exec rails db:migrate 2>/dev/null || bundle exec rails db:setup
bundle exec rails ds:update_clients

# Then exec the container's main process (CMD in the Dockerfile).
exec "$@"

So, taken together, the Dockerfile lines copy the script from the current project directory, and copies it to the container's /usr/bin/ folder, and then sets the executable permission on it with RUN chmod +x /usr/bin/entrypoint.sh so that the script is executable when the container is started. As the name implies, this script then serves as the entry into our container when it's running. That is to say, this script will run whenever we enter the container to run a command, or when it it is started up.

Remember earlier how I had trouble setting up the database inside the Dockerfile and kept failing? This is how you can overcome that. We set up this "additional instructions" inside the recipe, but they only make sense once we run the container. It's like serving gravy on the side with a meal with instructions. If we put the gravy on before serving it, the whole thing might get too soggy. Or maybe some guests want more or less gravy. So we put it on the side and let the guest know that they can use as much or as little gravy as they want when the time comes to eat. The entrypoint allows us to provide additional instructions that get executed when the image is run as a container.

NOTE: The docker ENTRYPOINT configuration is actually much more complicated than I have alluded to here. The goal of this section (and the entire article) is not a deep dive into docker, but intended to be a first brush with docker to make it intelligible for those dipping their toes in. I know my explanation of ENTRYPOINT in particular likely falls short of explaining it in depth. That being said, the goal here is to get someone from zero knowledge to 1 containerized application, not full docker mastery.

The contents of the entrypoint.sh is pretty straight forward and is annotated for your learning.

The next line simply tells docker that traffic on port 3000 of the container should be forwarded inside the container (so our Rails server can serve the request).

EXPOSE 3000

Finally, the last line!

CMD ["rails", "server", "-b", "0.0.0.0"]

This is what is run when the container is spun up, and it's just a regular old Rails command with some parameters.

With that, we have the Rails app mostly in order as far as Docker is concerned. Often times the resources I initially pursued would then jump right into docker compose, and that is indeed what we'll be doing in a beat, but the one thing that was missing for me was why. Looking back, we can see that our Rails Dockerfile was mostly concerned with our Rails app. Up until then, we have just assumed we'll have a database available. And when we are in our local development environment, that's usually the case. Your machine probably has a PostgreSQL server service running the background and all you have to worry about is setting up the Rails app.

And yet, the Rails application is useless without its PostgreSQL companion. Remember how I said previously that the Dockerfile is like the recipe for an image that will be run later? It turns out that there are recipes out there for PostgreSQL as well. What's the relevance for us? Well, if we set up our Rails recipe, and we can borrow a PostgreSQL recipe, we should be able to put them together to make them work in concert. And that's what docker compose does.

By way of analogy, a Dockerfile is like a recipe for a particular dish, while using docker compose and its docker-compose.yml is like setting the menu with its courses and their order.

Docker Compose

Okay, so what's up with this docker compose situation? Well, if we think about each section of our application as a container, then we have already successfully set up our Rails container. But as I mentioned before, we need to have a database for the Rails application to be of any use!

So, as I said before, if the Dockerfile is your recipe for each particular menu item, then the docker-compose.yml is like your menu for the evening. It specifies what entrees are available, and how they relate to each other.

Let me show you the docker-compose.yml file I ended up setting up and we can go through it line by line to understand the big picture.

version: '3.8'
# Logging config
x-logging:
  &logging
  driver: "local"
  options:
    max-size: "5m"
    max-file: "3"

services:
  db:
    image: postgres
    env_file:
      - .env
    volumes:
      - postgres:/var/lib/postgresql/data
    restart: always
    healthcheck:
      test: pg_isready -U postgres -h 127.0.0.1
      interval: 5s
    logging: *logging
  web:
    build: .
    restart: always
    ports:
      - "3000:3000"
    env_file:
      - .env
    environment:
      DATABASE_URL: ${DATABASE_URL}
    depends_on:
      - db
    logging: *logging

volumes:
  postgres:

Alright, again, this might be information overload but we'll step through it together.

The first line is straightforward:

version: '3.8'

This just defines the version of Docker Compose that this file uses. It is a shorthand that maps to a particular version of Docker engine, so that what you write is interpreted correctly. As of this writing (Jan 8, 2023), the current latest version you can specify is "3.8" which is what we've used.

We are actually going to skip the x-logging section and come back to later, because it's strictly necessary for getting an app up and running.

Okay, onto the meat (pun intended) of the file. Let's go over the services section.

`db` service

Because this is a regular YML file, we'll examine the contents of the services section's sub-items in turn.

  db:
    image: postgres
    env_file:
      - .env
    volumes:
      - postgres:/var/lib/postgresql/data
    restart: always
    healthcheck:
      test: pg_isready -U postgres -h 127.0.0.1
      interval: 5s
    logging: *logging

Here, we define a service called db which, predictably, runs our database. Recall that we can borrow recipes from Docker Hub, and you'll see that we actually do that here:

image: postgres

This line tells docker compose to borrow the postgres image and use it to set up the container. Because we don't need anything custom with our PostgreSQL service, we can just use the pre-cooked image.

The next line includes a little bit of configuration via a .env file:

env_file:
  - .env

This file actually makes a reprise later on in our Rails section, but what is important to know here is that by using a .env file we don't store any important information inside our docker-compose.yml file.

There was one thing that confused me here that I want to call out. Because we are relying on the pre-cooked postgre image, we should make sure we consult the documentation about what environment variables that image expects in order to function properly. In this case, the postgre image expects there to be a POSTGRES_PASSWORD environment variable, which we have set in our .env file. The value can be arbitrary, but must be included in the container's environment.

One alternative to using the env_file option is to use the environment option and set each variable manually. It looks like this:

environment:
  - POSTGRES_PASSWORD=somepassword

Obviously, this method is a little more straightforward, but the trouble is that now we've included a plain text password for our database in our docker-compose.yml and docker-compose.yml itself is a version controlled file. Whether or not that's okay is up to you.

NOTE: You can also use both if you want. Docker compose has a specific precedence it will follow if there are multiple sources for environment variables, which can be useful to understand: https://docs.docker.com/compose/envvars-precedence/

The next line creates or uses a docker volume:

volumes:
  - postgres:/var/lib/postgresql/data

This line sets up a named volume postgres which is then mounted inside the container at the path provided /var/lib/postgresql/data. Docker will then persist this data to the host via its own magic. For example, the data is persisted to /var/lib/docker/volumes/rails_app/_data on my local install because that's the application's name. Note that we've named the volume postgres as we will use it later.

The next few lines define a few features that are not strictly necessary, so we'll group them together and run through them as a block.

restart: always
healthcheck:
  test: pg_isready -U postgres -h 127.0.0.1
  interval: 5s
logging: *logging

Restart specifies the conditions under which a container should automatically restart, here we specify always. There are some other values as well. With healthcheck, we define a test and how often it should be run to report on the health of the service. Because we are using PostgreSQL, it comes with a command line option pg_isready which we run as the postgres user on the local container. Finally, we set up log rotation via the the "extension fields" feature (which we skipped earlier). We'll talk about the extension field x-logging in the last section.

`web` service

Okay, that was a quick tour of setting up our db service. Let's move on to the other service we've specified, web. Below is a recap of the web subsection under services:

web:
  build: .
  restart: always
  ports:
    - "3000:3000"
  env_file:
    - .env
  depends_on:
    - db
  logging: *logging

Here, we have most of the same commands except three, which are new. Let's examine them.

build: .

For our web service, instead of using a pre-cooked image from Docker Hub, we've specified that we should build an image from the current directory. Which means that this docker-compose.yml will rely on the Dockerfile to generate an image of our Rails app for us.

ports:
  - "3000:3000"

This line maps the host post to our container's port. If you'll recall, we set our Rails app to listen on port 3000 in our Dockerfile so we just make sure that the port is exposed to the host from our container.

Finally, the last new command:

depends_on:
  - db

This line does what it says on the tin, it tells Docker compose that we need our db service to be available before trying to spin up this service.

That about covers the services section of the docker-compose.yml there's just one more section to cover:

volumes:
  postgres:

Remember how we defined this named volume earlier as part of our db service? Listing it again here at the top level tells docker-compose to make the volume available for all services, so that our database can use it.

Putting it all together

Finally, we have all of our bits and pieces set up in order to use docker and docker compose to deploy this application.

The final piece that's missing is the logging section. This section uses "extension fields" which start with a x- that Docker will actually ignore. The reason for this is because we can then use YML anchors to then share configuration across a number of different services.

In this example, we define a log rotation setup that we want to use across our db and web service. Then we use YML anchors to insert that configuration into each service.

The last bit we have to sort out is how our secrets are configured. We already touched on POSTGRES_PASSWORD required by the db service, but actually, we also require some secrets for the Rails application.

Chiefly, we require that our Rails application can access config/credentials.enc.yml which is a version controlled file. Typically, inside that file is the secret_key_base which is used as the basis for all other encryption for a Rails app.

If you're starting with a Rails app you've already created, the easy solution is to find the config/master.key (or an environment specific .key file if you'd prefer) and stick that value into your .env so that Rails can read the file required. The rule is: whatever key encrypted your config/credentials.enc.yml needs to be available inside your container in order to run the application.

So make sure to add RAILS_MASTER_KEY to your .env file so that Rails can decrypt your credentials.enc.yml!

Finally, it is a good idea to set up your Rails database configuration to also use an environment variable for connecting to the database. One easy way to do this is to set a DATABASE_URL environment variable that you can embed the username and password into. This way, you don't have to specify separate variables for user and password.

The reason for this is that both your containers will run in a virtual network and be able to talk to each other. Because we previously set up a POSTGRES_PASSWORD as required by the postgres image, we can set up a DATABASE_URL using that password as well for the Rails app inside the web service to communicate with the db service.

The format for this should be: postgres://postgres:<chosen_password>@db:5432

Then you can add url: <%= ENV['DATABASE_URL'] %> to the default section of your database.yml and not have to define separate username and password variables.

Because our containers run on the same virtual network, we can simply refer them by their service name and Docker will make sure they can resolve internally.

Okay! Now that we have everything set up, we can see if everything works!

In your command line, you can run docker compose up -d and Docker should build and then run your containers. The -d tells docker to run in detached mode, which will run the containers in the background.

Here are some other commands to be aware of:

docker compose stop will stop the containers related to this application. You have to make sure you're in the project directory where docker-compose.yml lives for this to work.
docker compose run <service> will pull up logs for the chosen service. There are also options to get live logging, so check it out.
docker compose build will re-build the images that are used to run the containers. Make sure that you use this command if you make any source changes to your Rails application, otherwise the changes will not be captured in the images and the app behaviour won't change as you expect.

Running this shebang remotely

Okay, now we have this docker compose setup working on our local development machine. How do we get this all up into the cloud or another server?

There are a few approaches. The first is the most straight forward but potentially time consuming:

Either via git or a command like scp, copy the repository over to the target host machine, install docker and and docker compose on the target host, and run the command via ssh. With this method, any changes made to code must be copied to the target host machine, and the images re-built and re-deployed. For a project which changes often, this may not be an ideal approach.
Another option is to set up a docker context. This means you run your docker commands on a defined docker daemon that may not be local to your current environment.

Docker has a great blog post on this which is extremely straight forward: https://www.docker.com/blog/how-to-deploy-on-remote-docker-hosts-with-docker-compose/

I hope this helps, feel free to comment any questions and I will do my best to reply! You can also use docker to set up development environments, so stay tuned for that!

Why Did I Learn Ruby on Rails?

crespire — Wed, 04 Jan 2023 17:01:01 +0000

"Why did you learn Ruby on Rails in 2022?"

I heard this while interviewing at a shop trying to get into the industry. The interviewing engineer kind of chuckled while asking me. I suppose it was a fair question, even if the delivery was not great.

In 2022 (and maybe beyond), node.js is the hot hot along with a whole slew of frontend Javascript frameworks all competing for installs. React and Next.js, Svelte and SvelteKit, vue and Nuxt.js and Angular... all of these are in the news right now, but they're all moving towards how Rails wants you to do things anyway (hydration and server-side rendering are what Rails is particularly good at, especially with the addition of Turbo and Stimulus).

So, why did I choose to learn Ruby on Rails?

Rails is very focused on what it does well. It's opinionated and expects you to do things a certain way. When you're learning an entirely new skill, this kind of structured approach gives you something to grab on to to build your knowledge behind the why of things. At first, you'll be confused (I know I was), but once you get a level of comfort it's easy to dig into the why.
Node packages have documentation that is very hit or miss. Some packages have excellent documentation, while others are tearse or missing. For someone new to the domain, it can be a challenge. In my experience with Ruby and Rails, documentation was typically much stronger. It makes navigating the new a little less painful.
A lot of educational content out there for JS/Node tends to focus on the how and less the why. This is fine and dandy for building applications via assigned Jira tickets, but I found that the resources I consumed while learning Ruby on Rails really focused on both the how and the why. With the foundational knowledge of why Rails does something the way it does, you can gain insights into how other frameworks want you to do something. This provides a lot of value because it is directly building your problem solving skills. Even if I don't end up getting a job as a Rails developer, I have the fundamentals down that enable me to pick up the core "how and why" of a framework, regardless of the language: Go, TypeScript or C#.
Finding a job is going to be tough no matter what's in your toolbox, so you might as well learn why behind the how. There are a lot of arguments about "well there are many more JS/Node jobs than Rails jobs" and this is objectively true, but there are also that many more people learning JS/Node, so in the end, the level of compete required may be the same.
Ruby is an awesome language, and I love writing it. It's fun. Because it's fun, I could foresee myself writing Ruby for 20-30 years.

In then end, Ruby and Rails provided me with a strong foundation to go and pick up topics in computer science, whether it's in another language or another framework.

Setting up VSCode to write commit messages like a boss

crespire — Sun, 09 Oct 2022 16:38:37 +0000

So you've got your shiny code all ready to push up to remote, and you're about to write a commit message.

I am sure you've heard all the tips about writing excellent commit messages, like making sure the title is only so long, that the body is only x characters per line and all that fun stuff. Did you know that you can use VSCode to make your commit messages?

First, configure VSCode as the default editor for git:

git config --global core.editor "code --wait"

This command sets git to open up VSCode when you type git commit without passing in a -m "message" so that you can provide more context about your commit message. The --wait part just tells git to wait until the user closes the file before moving on.

Now, when you type git commit without -m, you'll see a file open in your VSCode called COMMIT_EDITMSG and git will wait until that file is saved and closed before continuing.

Second, we can actually set up some rulers to help you make sure you stay within the recommended formatting! You'll want to open up your settings.json and insert these lines:

"[git-commit]": {
        "editor.rulers": [50, 72],
    },

This will add two rulers to the editor that will open for any git commit! The ruler is the 50 character limit for the title and the second is the 72 character limit for the body of the commit.

That's it, now you can write all the commit messages you want and know that they will render properly!

Rails: Using Lots of ActionText Inputs on the Same Page

crespire — Sat, 24 Sep 2022 01:49:46 +0000

Here's a quick one!

I used ActionText and Trix for a Facebook clone project, but I ran into a problem using multiple Trix input areas for different posts and comments on the same page.

When a user had more than one post you could comment on, commenting on one post would cause some issues if you left that comment before saving it to comment or post elsewhere.

The problem is how Trix handles input using a hidden field that contains the real data you'll be saving to your database. It turns out all the different Trix inputs were all writing to the same hidden input field!

The fix was easy once I was able to figure out the issue: each rich_text_area needed to also have its own unique ID, so that Trix could match each unique input with the corresponding hidden field.

Hope that helps someone working with multiple ActionText inputs on the same page!

Learning TDD was hard, but worth it.

crespire — Tue, 11 Jan 2022 15:39:39 +0000

^{Cover Photo by Yan Krukov from Pexels.}

As part of my learning journey with The Odin Project, I was exposed to test driven development (TDD). I wanted to write about my experience with it because while doing that lesson, I wanted nothing more than to skip it and move on to the next thing. In the end, I stuck with it and I do think it made for a fruitful learning experience. I am hoping some other learners might find this relatable and help to push them to stick with learning TDD. In the end, I would say I came out with an appreciation for TDD and how it helps you to write better code.

I had a really hard time with the whole concept of TDD for a number of reasons. Tests-first and how to write tests was new, and using mocks and doubles was strange to me. And most of all, writing tests wasn't the same as writing my program!

Learning something new

The first big barrier was that taking a TDD approach was completely different from what I was doing before. I'd write some code, then test it using IRB. It worked, so why bother with TDD? I had a lot of thoughts about how TDD was cumbersome and pointless during the first day with TDD. Why would I write tests first when I could just write the code, and then test it? It felt like a duplication of effort that led to the same end result.

A large part of this feeling of tedium stemmed from actually having to learn something completely new. Tackling RSpec was like learning Ruby all over again and seem like a huge mountain to climb. Why should I climb it when I can just build the thing I really want to build anyway? At the time, I didn't recognize this barrier for what it really was. What I was frustrated with, really, was not knowing how to do the things I wanted to do. It wasn't that testing was difficult to pick up, but RSpec had very specific ways of doing things that I hadn't quite grasped yet. Things like subject context and all the different matchers for expect were as foreign to me as Array#reduce was when I first picked up Ruby. This feeling of frustration was so visceral, it really almost caused me to give up. I'm glad I didn't. Once I spent some time playing around with testing in RSpec, all the ways of doing things started to be added to my mental map. What was once a huge pain became easier, slowly but surely. Suddenly, writing a test in RSpec wasn't this huge pain in the ass where I'd have to look at the docs constantly.

Duplication of effort?

The second pain point was entangled with how familiar I was with the RSpec language, but I think it's worth calling out separately. I initially felt that it was a huge duplication of effort to write a test and then the code to pass that test. It would definitely have been faster to write my Ruby code first then figure out how to test it afterwards. At this stage, I knew how to write Ruby, but RSpec? At best, I'd have to spend some time figuring it out. That felt frustrating to me, and so it felt like a barrier to finishing the project which led to my feeling of want to can the whole thing and move on. Because RSpec was new to me, skipping the tests to write Ruby right away was very appealing. However, as I got more familiar with RSpec the barrier to figuring out tests lowered to the point where the whole idea of TDD started to make a lot more sense. After all, once you know how to use RSpec, writing a test is very simple.

A test defines, in a very concrete way, what I am expecting my code to do. That's valuable when you're creating something from scratch. Putting into words (literally) what outcomes you're expecting articulates your small problem at hand. Then, you write another test. Add or refactor your code to pass both. In this way, you're building your code in small chunks of functionality.

The other big benefit to learning how to use tests is something that you don't really broach working independently but is critical in a collaborative context: tests help to ensure a code base behaves in a particular way. When you're the only person working on a project, it isn't really consequential. You are the only one who works on the code and you know exactly what you want it to do. However, in a collaborative environment where you might be working on code someone else wrote? That is a whole new ball game. In this situation. if there's a test then you know what your code changes have to maintain in terms of behaviour.

What the heck are mocks?

The final barrier to testing involved the concept of mocks and doubles. I won't go into detail here their differences, as there are plenty of experts and resources on the topic. Generally, they are stand-ins for objects that you might not have written yet or resources that are external that you don't have direct control over like an API or external database. You don't want to send a bunch of requests to a live API when you're testing something in a development environment.

Using mocks was difficult for me to wrap my head around at first. It was a bit of an echo of the second pain point I had: I didn't really know how to use these things, and why wouldn't I just write unit tests and then the actual class instead of using a mock? Again, I struggled here to really identify my core problem: I needed more familiarity with how to use this tool. One insight that helped me really understand this tool was the idea that you should test the unit, not the integration.

This concept was a little baffling to me and it exposed a weakness in my familiarity with object oriented design in the first place. As a small note, this following section is based heavily on the things I learned from Sandi Metz through her talks at various Rails Confs as well as her two books on object oriented design. Using mocks was confusing to me because I realized I was testing the integration of my two objects, rather than testing the unit.

An example here might be helpful, so let me set the stage. The project I was working on was a command line Connect4 game, and I was trying to test that my Game object would display the rules to the console. At this point in the project, Display was not yet written so I was using a double as a stand-in.

Here was my first go at the test:

describe Connect4 do
  describe '#show_rules' do
    subject(:c4_rules) { described_class.new(display: display) }
    let(:display) { double('Display') }

    it 'should print "Rules" to stdout' do
      allow(display).to receive(:print_rules).and_return(nil)

      expect(c4_rules.show_rules).to output('Rules').to_stdout
    end
  end
end

I set up the class I am testing and an instance of it as well as a stand-in Display. After the set up is complete, we allow Display to receive the message print_rules and return nil. After all that, I assert (or expect) that the game object (c4_rules) should send the message show_rules, and then output something to the console.

This test is bad. It is bad because it is testing integration between Connect4 and Display. If you think about it, why should the game object know what the Display outputs to the console? In this case, I am testing for the output string 'Rules' but what if my rules change? This test would be broken because of a change in Display but we were testing Connect4 here!

Testing in this way makes mocks hard to use as any change anywhere else in your code has the potential to break tests related to another unit. It really does seem like you'd be better off writing Ruby rather than figuring out how to re-write your tests so they pass.

How can we change this test so that it is actually a unit test, rather than an integration test? After all, in TDD, the point is to make sure each class (or unit) behaves as we expect it to. Changes in another unit shouldn't break tests for the unit we're looking at.

Well, let's give it a go.

describe Connect4 do
  describe '#show_rules' do
    subject(:c4_rules) { described_class.new(display: display) }
    let(:display) { double('Display') }

    it 'should send Display the print_rules message' do
      allow(display).to receive(:print_rules)

      expect(display).to receive(:print_rules).once
      c4_rules.show_rules
    end
  end
end

What changed? Well, a lot. Let's walk through it. All of the set up is mostly the same. We set up our test unit, then set up a stand-in Display and allow it to receive the print_rules message. This time, we don't care about what it returns. Then, we changed our test from expecting a certain output to expecting a certain message to be sent.

This shifts the test away from testing integration to testing the unit we're interested in testing. It also means that all the Display double is doing is verifying that it received a message from Connect4 like we expect.

Thinking back, Connect4 shouldn't care what Display does with the print_rules message in the first place. Whatever is the result of that message, that is the concern of Display and its own unit tests. All we need to test here is that Connect4 sends such a message. Now, regardless of what Display#print_rules outputs, it won't break our test. The behaviour we expect of Connect4 remains the same: it sends a message to the Display to do something.

The key is to understand that each object in your program is a unit. These objects talk to each other in order to get things done. What's important in unit testing is to really focus on the interface of your objects. What do we expect our objects to do when it receives a message? Should it send a message to another unit for information or to do something? Should it send information back to the sender in its own response?

When you focus on testing the messages and responses of your objects rather than the end outcome of a message received or sent, the value of doubles becomes clear. In fact, thinking about the messages you want to send or receive, you either have to use mocks for objects you haven't written yet, or write them. In this way, a double is a nice way to figure out the messages that other object should send and receive, before you even start writing it.

Let's get testing!

Even though this whole process of learning the TDD method has been hard, it has totally been worth the pain and struggle. I see the value in unit tests and have even undertaken other projects in this way. Give yourself a chance to become familiar with your testing framework. Once you know how to write the tests you want to write, it will all become so much easier.

Beyond familiarity with your testing framework, make sure you're testing your unit as much as possible rather than integration with other units. It will help make testing much less painful, as changes far away from your current unit will be much less likely to break your tests.

I hope my experience going through learning TDD encourages you to also stick with it. It was frustrating, and I wanted to skip the lesson many, many times. But in the end, learning how to do TDD not only helped me to get a stronger handle on some design fundamentals, but also helped me to write better code.

One final thing, Sandi Metz has a fantastic talk on testing that really helped me to understand how to test better. This one video was hugely insightful and helped to tie everything I knew about testing and object oriented design together. If you're starting to learn TDD and hating it, give it a chance!

How to learn everything, and nothing at all.

crespire — Sat, 04 Dec 2021 00:51:16 +0000

^{Cover Photo by Aaron Burden on Unsplash}

I'm new to the development thing, and I've been working through The Odin Project, a wonderful free resource that takes you from zero to a junior level developer in the context of web development. I might not know a lot, but I've been hanging around the community Discord server and a lot of people are constantly asking about code-along videos.

A pretty standard exchange goes something like this:

SomeUser: Hey I want to learn <some language or concept>, what's the best way to do that?
OtherUser: You should look up a few videos and follow them to build something. You'll learn a lot!

Now, let me be clear from the top: I believe code along videos have a certain value. They are invaluable for folks that already know what they're doing. These types of videos can introduce the viewer to some pretty complex things, and if you already know what is going on, there is value in the format as a quick introduction. The critical difference is that for someone with experience to fall back on, they can figure out what's what pretty easily.

If you're still very early in your journey, a code along video is probably not ideal for your learning. The main reason is that you'll be lacking the wealth of experience and knowledge to really understand what's happening.

Let me get into this by way of example.

When I first started The Odin Project, Javascript was arcane to me. I had (almost) no clue how it worked. I did have the advantage of picking up some basic Pascal in high school, and my group of friends were all nerdy and we all built basic HTML and CSS2 websites that used PHP scripts to make templates. Can you guess how old I am?

Anyway, I never touched JavaScript then, so it was this newfangled thing to me when I finally got to that section of the Odin curriculum. So, I was eager to dive in. There's a very well known introductory course that has you make x things in y days based in Javascript, and one of the days was linked as a resource to consider, so I went ahead and opened it up.

The basics of the video were essentially setting up an HTML file, some CSS, and the meat of it, using Javascript to set up an event handler which then played some audio, added a CSS class to the element, then removed it to get a transform effect.

Here's the thing: these topics and techniques are all very basic JavaScript, CSS and HTML. Any web developer will know how to create and handle a browser event like the back of their hand. I think it's something I could have easily grasped if it were presented in a different format for me. I mean, to be real, maybe not, but I'd like to think so!

I followed along with the video and nodded along, just typing into my own IDE what was in the video. Oh yeah, this is cool, and look at me build this thing! I finished the project and it worked as advertised, so I thought to myself, "Good job! You did it! You made this!" I'm sure you're all familiar with this meme and in the moment, that was me. I had dilluded myself into thinking I made the project.

The truth is, in that moment, I was suffering from the illusion of competence. The tutorial I had just watched gave me everything to succeed, and as a consequence, I didn't engage with the material at all. And why not? The solution was right there... even if I had wanted to come up with my own solution or next line of code, the temptation to just move along in the video was too easy to succumb to. The answer was just 1 second away! Sure, I had something to show for it at the end of the video, but did I really know and understand what the event handler was doing? (Narrator: He did not.)

There's a lot of research about this phenomenon called the illusion of competence and it can be a deadly menance when it comes to learning anything, but it is especially harmful for learning how to flourish as a developer. When you have the answer given to you, or you think you already know the answer, then you don't get the chance to really enter the second stage of competence by trying to solve the problem and failing. So, you finish one and look for the next great tutorial that will ~teach~ you something. But the results are the same, because tutorials almost always walk you through everything step by step. Some folks sometimes call this treadmill of tutorial videos tutorial hell.

Let me repeat this again, video codealongs do have their place as an educational tool but this place, in my humble and noobie opinion, is once you've got a solid foundation in programming and are looking for a refresher on a topic you haven't touched in a while, or to figure out how to do something in a lanaguage that's new to you.

My advice for those starting in their journey to learn how to write software?

Take your time. If you're in a hurry, you'll be prone to take shortcuts and fall into the illusion of competence much more easily. One way to avoid this is to give the material, concept or problem the time it deserves.
Fail, and fail a lot. Get stuck, and Google the problem you're having and not the solution! Once you're stuck you're in a prime position to learn something and make it memorable. I'll always remember when I finally figured out event handlers and the event object in JavaScript.
Don't be shy about asking for help in a thoughtful way after you fail or get stuck. Sometimes, you can figure a way out on your own, but if you feel like you're really stuck, asking thoughtful questions about your problem can often push you along the right direction. In this way, it's important to ask about your problem, rather than asking for a solution. It's the same problem: get given an answer, and you'll likely end up here again.

When you're just starting your programming journey, code-along videos can seem like the best. You learn something, and end up with a project at the end. It really does feel like you can learn anything and everything this way, but just remember that the illusion of competence is a thing, and be extra careful to test your knowledge as you go!