Jason Charnes

2022 Wish list

2022-01-01T00:00:00+00:00

I’m not good at resolutions. Instead, I made a wish list of things I’d like to do in 2022.

Make better choices for my mind and body
- Less junk food
- Less alcohol
- Less complaining
- More meditation
Detach from iPhone/internet more often
- Less scrolling
- Less entertainment
- Less screen time
- More utility
Be present for my family and friends
- Less iPhone
- Less “not now, son”
- More date nights
- More conversations
- More attention
Spend less money
- Less impulses
- Less debt
- More intentionality
- More saving
- More giving
Donate more unused items
- Less clutter
- More empty space
Create a valuable product
- Less ideas
- More problem solving

Disabling Rails Generators

2021-08-04T00:00:00+00:00

I love spinning up a Rails controller using rails g controller. I don’t love all the files it brings with it. I end up with a treasure trove of files I either have to manually delete or commit into my git history for all eternity.

For example, I typically use Webpacker for all my assets. When I run rails g controller I don’t want autogenerated stylesheets in app/. I want to disable assert generation.

If I’m going to use a helper I’d rather create it when I need it. I want to disable helper generation.

Whenever I spin up a new Rails app, I look at previous projects or search the web for how to disable certain generators. But no more, this will be my resource for it moving forward.

Consider this my love letter to the Ruby on Rails config.

This example is derived from the Rails guides. (I updated some of the comments in the docs for brevity.)

Inside config/application.rb:

module YourAmazingRailsApp
  class Application < Rails::Application
    # ... some stuff!

    # The commented out values are using the defaults.
    # To disable a generator (that is a boolean) change it from true to false.
    # Some generators take a symbol as a value, refer to the guides for the other options.
    #
    # Feel free to copy and paste this entire block in!
    config.generators do |generate|
      # generate.assets true # create assets when generating a scaffold
      # generate.force_plural false # allow pluralized model names
      # generate.helper true # generate helpers
      # generate.integration_tool :test_unit # which tool generates integration tests (might be overwritten automatically if using rspec-rails)
      # generate.system_tests :test_unit # which tool generates system tests (might be overwritten automatically if using rspec-rails)
      # generate.orm false # which orm to use (false uses Active Record)
      # generate.resource_controller :controller # which generator generates a controller when using bin/rails generate resource
      # generate.resource_route true # generate a resource route definition
      # generate.scaffold_controller :scaffold_controller # which generator generates a controller when using bin/rails generate scaffold
      # generate.stylesheets true # generate stylesheets
      # generate.stylesheet_engine :css # configures the stylesheet engine (for e.g. sass) to be used when generating assets. Defaults to :css.
      # generate.scaffold_stylesheet true # creates scaffold.css when generating a scaffolded resource. Defaults to true.
      # generate.test_framework false # which test framework to use (false uses Minitest) (might be overwritten automatically if using rspec-rails)
      # generate.template_engine :erb # which template engine to use
    end
  end
end

My typical config looks like this:

module YourAmazingRailsApp
  class Application < Rails::Application
    # ... some stuff!

    config.generators do |generate|
      generate.assets false # create assets when generating a scaffold
      generate.helper false # generate helpers
      generate.stylesheets false # generate stylesheets
    end
  end
end

To learn more, visit the Rails guides.

Installing React in Ruby on Rails with Webpacker

2019-12-23T00:00:00+00:00

So, you want to use React in a Ruby on Rails application. I’m glad you’re here! I think React is a great tool to use in your Ruby on Rails applications.

I’ll help you get started. We’ll look at bootstrapping any Ruby on Rails application (that can use Webpacker) with React.

Luckily, for us, Ruby on Rails makes it pretty easy to get started.

Installing Webpacker

If you’re using Rails 6, no further action is required to install Webpacker. 🎉 Good job, I’m proud of you.

If you’re starting a fresh Rails 6 application, jump to the bonus section.

If you’re using Rails 5, we’ll follow the Webpacker instructions.

A fresh Rails 5 application

If you’re starting fresh, you should consider using Rails 6. Out of the box, you’ll get Webpacker. But, If you need a new Rails 5 application, you can provide the --webpack option when creating your app:

rails new react-app --webpack

An existing Rails 5 application

If you’re adding Webpacker to a pre-existing Rails 5 application, add the following to your Gemfile:

# In Gemfile
gem "webpacker", "~> 4.x"

Once you’ve run bundle install, you can install Webpacker using the following command in your terminal:

bundle exec rails webpacker:install

Installing React in Ruby on Rails

Once again, thanks to Webpacker, this is a simple step. Rails gives us a command to run that allows us to bootstrap our application with React.

Run the following command in your terminal:

bundle exec rails webpacker:install:react

Running this command adds React to your application, run yarn install, and create a React component you can immediately use in your application.

Bonus

If you’re starting a brand new Rails 6 application, you can bootstrap your application with React when using rails new.

rails new react-app --webpack=react

That’s all, folks

See, that wasn’t so bad. A sincere thank you to the team working on Webpacker. We couldn’t ask for a better install process for React in Ruby on Rails.

If you want to dissect the component Rails just created in app/javascript, you can join me here.

Dissecting a New Webpacker React Component

2019-12-23T00:00:00+00:00

If you’re new to React, and just installed React through Webpacker in your Ruby on Rails application, you might have some questions.

Let’s answer those questions by walking through the React component Rails and Webpacker auto-generated for us.

Hello React

Rails auto generates a React component in app/javascript/packs named hello_react.jsx. Cute name, right?

The file looks like this:

import React from "react";
import ReactDOM from "react-dom";
import PropTypes from "prop-types";

const Hello = (props) => <div>Hello {props.name}!</div>;

Hello.defaultProps = {
  name: "David",
};

Hello.propTypes = {
  name: PropTypes.string,
};

document.addEventListener("DOMContentLoaded", () => {
  ReactDOM.render(
    <Hello name="React" />,
    document.body.appendChild(document.createElement("div"))
  );
});

Let’s break down the different pieces of this file.

The file type

If you haven’t worked with React, JSX may be an unknown file type to you. Don’t worry; we’re going to start there.

JSX is a “syntax extension to JavaScript”. Essentially, this means JSX is a regular JavaScript file with the ability to do some templating. The React team recommends the JSX file type, and it’s the one I use when I write React code, even in Ruby on Rails.

All you need to know, at this point, is that JSX files render React components. We’ll create these React components out of JavaScript and HTML.

There’s an example further down, so let’s move on for now.

Imports

The top of the file starts with “import” statements. What are these imports?

ES6 brought the ability to import functionality from JavaScript modules easily. Using modules allows us to wrap JavaScript functionality inside a module and use it elsewhere throughout our application.

In this file, we’re importing three libraries from our “node_modules” directory. These libraries are brought in by Yarn as declared in package.json

import React from "react";
import ReactDOM from "react-dom";
import PropTypes from "prop-types";

React is used for, well, React.
ReactDOM is used to render our React component(s) onto the DOM.
PropTypes is used to declare “props” in our components. We’ll talk more about this below.

If you’d like to know more, I go further in-depth on ES6 modules in my free course on ES6 Essentials.

Constants and arrow functions oh my!

If you’ve not worked with ES6 or JSX, this line of JavaScript is going to look funny.

const Hello = (props) => <div>Hello {props.name}!</div>;

This small line of code is a potent line of JavaScript. Let’s break it down by keyword.

Constants

const is a keyword short for constant. Once’s a constant is declared, it cannot be re-declared or re-assigned- it becomes a read-only property.

Hello

It should come as no shock that Hello is the constant’s name. However, it might be odd to you that it’s capitalized. React components are camel-cased and start with capital letters. And that’s what we’re declaring, a React component.

Arrow functions

Okay, so let’s dissect props => ...

We’re assigning an arrow function to the Hello constant. The first keyword, props, is the argument to the arrow function.

The code after the arrow is the code we want to execute when we invoke this constant (or render this component).

But, this code has no brackets or return keyword! Because this is a single expression, we can inline the code and get an implicit return.

But, this code is just HTML! Aha, welcome to JSX, which I said we talk about more. This line begins the power of JSX. We’ve defined our component to render an HTML div. JSX knows how to convert that to a div for the DOM.

But, there are curly brackets inside the div! How about that? So this further shows the power of JSX. If we want to execute a JavaScript expression in HTML, we can wrap it in curly brackets. In this case, props.name is a value, so the value name is rendered inside this HTML. Neat, huh?

So, let’s recap what we learned about this line of code.

const
// 👆A constant

Hello =
// 👆The constant's name

props =>
// 👆The function's argument and declaration

<div>Hello {props.name}!</div>;
// 👆The HTML implicitly returned by the function, with evaluated (and rendered) JavaScript

I swear this article isn’t a promotion for my mini-course, but it is relevant again. (And at least it’s free!) If you’d like to know more about constants and arrow functions, I cover those in my free course on ES6 Essentials.

Props

Now is an appropriate time to talk about “props.” Props are simple to understand, very powerful, and require more explanation than this article can provide. We’ll cover at a high-level what props are and how they fit into this component.

Props are arguments to React components. Skipping ahead (just a little bit) to the bottom of the file, you’ll find the following line of code:

<Hello name="React" />

This line is rendering our React component. There is an argument awkwardly named name. The argument, here, is taking the value “React”. This prop is then available in the component.

Remember The line of code returned by our Component <div>Hello {props.name}!</div>? This snippet is how we access props passed into our component. props is an argument into our function (given to us by React), and then the name is accessed via props.name.

See, that’s not so bad?

One significant caveat also outside the scope of this article: Props are read-only. You can’t mutate props. For simplicity’s sake, think of props as constants.

Prop types

With your abounding knowledge of props, we can continue down the file.

Hello.defaultProps = {
  name: "David",
};

Hello.propTypes = {
  name: PropTypes.string,
};

Our component can have two properties assigned to it:

Default props
Prop types

These are just as they sound.

Default props

Default props are default arguments. If someone renders the component without passing the prop, it falls back to the default value.

Prop types

You can set the expected type of the prop using the PropTypes library we imported earlier. If I give this component an integer for the name prop instead of a string, the application won’t blow up. (Unless you try to do some string-specific logic to the integer.) It will, though, log an error in the console telling you it expected a string, and you gave it an integer.

This functionality is handy as your components grow in size and complexity. However, both of these prop properties are optional.

The grand finale

It’s time to get our React component onto the DOM.

document.addEventListener("DOMContentLoaded", () => {
  ReactDOM.render(
    <Hello name="React" />,
    document.body.appendChild(document.createElement("div"))
  );
});

We start by adding an everyday event listener to the DOM. Once the content is loaded, the anonymous arrow function is invoked.

ReactDom (the library we imported earlier) has a render method we call with two arguments:

The rendered React component (with our props)
The DOM element the component is rendered inside

Rendered React components

To render a React component, we wrap it in self-closing brackets, just as we would any other HTML element.

The DOM element

In this example, we’re creating a div and appending it to the body. The React component is rendered inside the div and displayed in the DOM.

The second argument (the DOM element) can be any DOM node JavaScript knows about. For example, we could re-write the code to use an existing DOM node:

document.addEventListener("DOMContentLoaded", () => {
  ReactDOM.render(
    <Hello name="React" />,
    document.getElementById("#fancy-react-element")
  );
});

Look at you, React expert

We covered much ground, but I hope this helps you understand the random React component that Webpacker generated for you in your Ruby on Rails application.

So, what did we learn today?

ES6 imports
Constants
Arrow functions
Basic React components
Props
PropTypes
ReactDOM rendering

I hope this piques your interest just enough to keep learning React. I think it makes a great addition to Ruby on Rails applications, and I’m excited to see what you build with it.

Run.rb

2019-01-21T00:00:00+00:00

I’m proud to be involved in the Ruby community.

I want to do what I can to help other developers discover Ruby. Whether that’s seasoned non-Ruby developers or people like me who stumble into programming, I want to help.

As part of that, I’ve recently started on a project to help people learn Ruby. The final form will be a free set of guides (and maybe videos) to help people get started with the Ruby language. (More on that another time)

While working on this project, I spent some time thinking about how I could help get people writing Ruby quickly.

It’s not difficult to install Ruby on your computer. However, I remember as a beginner it was more involved than I anticipated, being a “non-programmer” at the time.

One of my first experiences with Ruby was using Try Ruby. Try Ruby was a quick Ruby tutorial with the ability to run the Ruby code and get immediate feedback.

Inspired by that project, I want to bring a way to write Ruby code in the browser, and get immediate output.

I think this is especially valuable when teaching Ruby. The ability to hop in a browser, run some Ruby code and get immediate feedback is a win while learning Ruby.

Heck, even as a more “seasoned” Ruby developer I see value in this.

Introducing run.rb

Wanting to bring this project to life lead me to collaborate with the most intelligent person I know, Will Glynn.

Today, I want to share run.rb with you. Naming is hard, so I pronounce this “runner bee.”

When you visit run.rb and run Ruby code, your code never leaves the browser. Will, once again- a freaking genius, helped me compile Ruby 2.6.0 into WebAssembly.

Your Ruby code executes in the browser.

This project is still very much an early prototype.But I wanted to get it into the hands of others.

For example, our next step is to add Ruby’s Standard Library (which is currently not there) into run.rb. I’d also like to allow you to share your code snippets as a link back to run.rb.

So, please give it a spin. Let us know what we can do to make this better.

❤️

Using Ruby in 2019

2019-01-02T00:00:00+00:00

Stop me if you’ve heard this one…

Ruby is dead!

Hacker News

As someone actively writing (and heavily invested in) Ruby, it’s hard not to question if I’m “missing the boat” when I hear such things.

In an attempt to “stay relevant,” if you will, I spent the better part of last year exploring other programming languages and paradigms. I built many, many Hello, World applications. Although I didn’t master anything, I learned a lot.

I spent some time trying to wrap my head around Elixir and functional programming. Alongside Elixir, I began to embrace modern JavaScript using things like ES6, React, and Stimulus. I built a mobile application using React Native with a Firebase backend. I read a little bit about Rust, drooled over Crystal, and read (part of) a book on Scheme.

There’s a lot to learn from other programming languages and approaches. As I learn about these different techniques, I feel that I’m becoming a more well-rounded developer.

However, I ended 2018 with one overwhelming theme: Ruby still fits me.

Exploring a world outside Ruby reminded me that Ruby isn’t the ”one true way,” but it’s still an excellent tool in my toolbelt.

99.99% of the work I do is on the web. For me, Ruby is an excellent tool for that job. The language is flexible, stable, and fun to use.

Before I go any further, I want to point out that I understand that Ruby isn’t the right tool for all jobs. There is a reason new languages are evolving and seeing adoption.

I’d also like to point out that this isn’t a definitive “you should use Ruby and here are the reasons why!” type of article. This article is a summary of why I’m confident using ruby in 2019.

The Road to Ruby 3

I stood in the back of the room for Matz’s 2015 RubyConf keynote counting down the time until I had to catch my flight home. I’ll never forget when he laid out his idea for Ruby 3x3. The premise is that Ruby 3 will be three times faster than Ruby 2.

We’re fresh off the Christmas release of Ruby 2.6. I asked Noah Gibbs about the progress made from Ruby 2.0 to Ruby 2.6.

A lot of the early 2.0-series improvements (2.1, 2.2, 2.3) were in the garbage collector - the 2.3-and-later GC is much faster than 2.0.

For RRB, 2.4.1 runs at 150%-155% of the speed of 2.0, and 2.6 (no JIT) runs at about 10%-15% faster than that. So you can quote me at 165% the speed of 2.0. That’s 65% faster, or just north of time-and-a-half speed.

2.6 has been a bit of a speed disappointment for RRB and large Rails apps, but overall the 2.0 series has been pretty good. I tend to say that, as a rule, each minor version of Ruby averages 10% faster for Rails apps. So while 2.6 gave us nothing over 2.5, some earlier 2-series Rubies had us a bit ahead of that schedule and it all works out.

With that said, we are not on schedule to get a 3x speedup just out of these small speedups - that would be a lot of 10% speedups from minor versions. Instead, the big hope there is JIT and possibly concurrency (Guilds.) But we’ll probably count 3x as achieved even if a big Rails app doesn’t get it, because so much of what Rails Ruby Bench does isnt Ruby – database calls, I/O, Redis, HTTP server, etc. I’m working on a smaller benchmark to show more of that now, and more Ruby-heavy benchmarks like OptCarrot already do, in various ways.

Measuring speed is a genuinely interesting problem, and there’s almost never just one answer. There’s a great talk by Matt Gaudet from just before I started on this problem, if you want the deep dive version.

Noah Gibbs | Appfolio

Rails 6+

We’re on the cusp of a new major Ruby on Rails version. DHH recently released a blog post highlighting the tentative timeline of Rails 6.

April 30: Final release. Ship and celebrate the release of Rails 6.0 at RailsConf 2019!

DHH | Timeline for the release of Rails 6.0

Three things to highlight in Ruby on Rails 6:

Action Mailbox - Handle incoming emails to your Rails application
Action Text - Built-in rich text capability using Trix and Active Storage
Parallel Testing - The ability to split/divide your tests to run in parallel

I’m most excited about parallel testing, as I currently use a gem to do that for me.

It’s nice to see DHH, Basecamp, and the countless contributors ❤️ still committed to Ruby and Ruby on Rails. I’m under the impression that for the foreseeable future David will continue to stay involved in Ruby and Ruby on Rails. (Guessing, here, but he loves Ruby.)

Generating a fully-fledged Rails application has never been easier. One thing I’ve grown to appreciate about Ruby on Rails is “no one paradigm.”

For example, there are times when I feel that I’m butting heads with the “Rails way.” When I find myself here, Ruby on Rails doesn’t prevent me from implementing new patterns or even doing wild things like replacing ActiveRecord.

One thing I often envy is the Laravel framework in PHP. Chris and I have talked about this on our Ruby podcast. Laravel has many tools most web apps need baked into the framework. Things such as authentication, authorization, events, queues, etc. Outside of that, Laravel offers official packages that handle things such as recurring payments with Stripe/Braintree, a GUI for debugging your application in development, an OAuth server, OAuth providers, and more.

I think adding these things into Rails might violate “no one paradigm.” Maybe it’s possible it’s as simple as Rails core believing Rails shouldn’t take those defaults.

I still enjoy Rails without having those libraries baked in. However, I’d be remiss if I didn’t mention I wish we had more first-party functionality like that.

I’m excited for RailsConf 2019. I hope to see you there!

Outside of Rails

Though the majority of my work is in Ruby on Rails, I’m very excited about the work outside of Rails.

For instance, the dry-rb project profoundly resonates with me after spending time exploring the functional programming world.

I have the utmost respect for Piotr and Tim. (and the other people on the dry-rb team I’ve yet to meet!) Their approach to writing Ruby code is unique, and I have a lot to learn from them.

Alongside dry-rb, Piotr has a database toolkit named ROM. Once again, this is an approach that is different to what I usually use, ActiveRecord. However, the approach resonates with me. I’m excited to explore this more in 2019.

The other project I keep my eye on is Hanami. The core team is currently working on version 2.0, which embraces more of the dry-rb and ROM libraries. I’m excited to see the result. I hope to build a project using Hanami 2.0 in 2019.

These are just a few of the exciting things happening in Ruby outside of Rails. I’m sure there are more I don’t even know. What are some of your favorite things?

Gems

The Ruby language has a plethora of gems. It’s one of the things I loved about Ruby when I came into the language in 2012.

However, some gems are starting to get a little stale. While it’s a bummer to see abandoned gems, it’s also an opportunity for Ruby developers to get involved in the community.

If a gem you like using is abandoned, you can fork it or build a new gem and share it with the community. I’d certainly love to see some fresh gem ideas in 2019.

An aside, I would love to see more open source models like Mike Perham’s Sidekiq. Mike gives you a fantastic open source project, with the ability to pay for more “pro” features. I imagine this helps Mike stay interested in the project.

Flexibility

One of the things I most love about Ruby (and at times have been frustrated with) is its flexibility.

Ruby includes a lot of sharp knives in its drawer of features.

DHH | Provide Sharp Knives

I’ve made many messes with Ruby code. You could argue this is the language’s fault, but I would disagree. I think in my cases, it was a lack of discipline and knowledge.

At times I’ve wanted to move to a statically typed language. I dream of the things the computer can do for me. However, in my experience so far it comes at the expense of the flexibility of using Ruby.

Several projects come to mind when I think of Ruby’s flexibility:

RSpec - A DSL for writing tests
Ruby on Rails - That magical feeling when you first learn how to use Rails (AKA “Look at all the things I’m not doing”)
dry-rb - The ability to express functional concepts and blend FP with OOP in Ruby

Stability

I can count on one hand the number of times my Ruby projects broke due to a Ruby version upgrade. Matz has often talked about how stability is an important part of the Ruby language. In his keynotes, he’s looked at other languages with not so great upgrade stories.

Granted, I wasn’t around for the Ruby 1.8 => 1.9 transition. I heard it was a little bumpy. However, in my experience, it’s been solid. I very much appreciate writing Ruby code with confidence.

Ruby Conferences in 2019

At the time of this writing, there are 16 scheduled Ruby-related conferences in 2019. This count is according to the Ruby Conferences website.

Cough cough, special shoutout Southeast Ruby.

Ruby Jobs in 2019

One of metrics, if you will, I use to keep an eye on Ruby’s “demise” is the number of available Ruby jobs.

One website I like to use is Stack Overflow Jobs. A quick search for Ruby returns 499 jobs in Ruby out of ~6000 total job postings.

A search for PHP on the same website returns 404 (job not found lolz) jobs. I consider PHP to be one of the more widely used (and not dead) langauges on the internet.

Searching for Java returns 2,500 jobs. JavaScript returns 1,950 jobs. However, I expect that. Those languages (as far as I know) have always seen wider adoption.

Stack Overflow Jobs isn’t a full representation of the job market. But, the jobs listed on Stack Overflow are legitimate companies hiring developers.

If I were to look for a new job, this would be one of the websites I checked first. I might also check We Work Remotely and the physical job boards at RubyConf and RailsConf, which have no more room by the time we leave.

All to say, I would feel comfortable finding a Ruby job in 2019.

Conclusion

I’m happy with my decision to dig even deeper into Ruby in 2019. Ruby isn’t perfect, but it still fits the way I view the world quite well.

I’d be lying if I said I wasn’t envious for features from other languages. But, at the end of the day, I’m solving problems for people. Currently, I’m best equipped to do that using Ruby. The cool part? I’m happy while I do it.

Is Ruby the right tool for every job? No.

Are there valid reasons to look at other languages? Yes.

Are things still happening in Ruby? Hell yes.

Jason, you didn’t reference The TIOBE Index! Whoops.

Can Ruby and (Insert Language Here) coexist? Absolutely. I think too often we approach programming language wars as you have to choose one or the other. I don’t think that is the case.

Jason, are you going to keep using Ruby in 2019? Yes. But, that doesn’t mean I won’t try and learn from other languages and ecosystems.

Is Ruby dead? Nah. (isrubydead .com)

Goodbye, 2018

2018-12-31T00:00:00+00:00

It’s the last day of 2018. Like most things in 2018, I waited until the last possible minute to write this.

Some great things happened, which I’m excited to share. Some less stellar things happened and some things didn’t happen. Either way, I want to take time to put my thoughts on paper this site. I have several ideas of what went wrong in 2018 and what can be different in 2019.

The Good

Hello, Baby Jaden! 🎉👶

Shannon (my partner) and I welcomed another baby boy into the world on October 10. Jaden Isaac Charnes is our second-born child.

Shannon and I spent the majority of our year together preparing for his birth while keeping our first born (turned 2 December, 29) entertained. 😅

It’s fantastic to have two healthy children. I hope I never take that for granted.

Remote Ruby 🎙️

I had an idea in January to start an online meetup for Ruby developers. Like any new idea, it was exciting.

I purchased a domain, threw together a website, and set a date for the first meetup.

My buddy Chris agreed to be the first guest. As it would turn out, Chris would be the only guest. I ended up presenting at one or two more meetups. That wasn’t the original goal. The idea was for others to give presentations.

Around June, I asked Chris if he wanted to do a podcast. He suggested we do it under the Remote Ruby brand, which was kind of him.

The podcast has done very well, by my standards. I was expecting to record an episode every week for 10-20 people. We’ve seen consistent growth in downloads. We recorded 21 times in 2018 for a total of 7,162 downloads.

I owe part of that to Chris having a substantial following with his GoRails community. Thanks, friend.

Earlier this week, I shut down the Remote Ruby Slack (used for meetups) and set up the email list to send new episodes out by email.

In hindsight, I should have been more diligent to find meetup speakers. However, it was also hard asking Shannon to let me have 1-2 hours at night on top of everything she allows me to do.

In the end, it all worked out. I love doing the podcast.

Southeast Ruby 🏙️

I once again put on Southeast Ruby. If you’re unfamiliar with Southeast Ruby, it’s a Ruby conference that Shannon and I started last year.

Instead of being an idiot and his smart wife putting on a conference alone, I somehow fooled Ernie Miller into helping co-organize the conference. Including Ernie was of the best decisions we made in 2018. Ernie is one of the most empathic, caring human beings I’ve ever met. I’m beyond thrilled he’s helping us again in 2019.

Somehow, once again, we had a fantastic speaker lineup.

Avdi Grimm, once again, agreed to be a keynote speaker. Alongside Avdi my friend Nickolas Means and Nashville native Erin Page keynoted. Those three fantastic keynotes, alongside many amazing session speakers, helped this year’s conference continue to be an incredible experience for everyone involved.

We had roughly 20% more attendees this year and several more sponsors, including Ramsey Solutions who provided a delightful venue.

Last year Shannon and I lost a tremendous amount of money putting on the conference. 😭💸

This year, we finished the conference with about $1,000 in the bank. This surplus helps give us a running start for 2019’s conference. I hope to one day make enough to reimburse ourselves for 2017, but if not it’s okay.

Add all this together, and I would consider 2018’s Southeast Ruby to be a success.

We’ve already announced next year’s dates! I’m excited to see how the conference unfolds in 2019.

Good + Bad

Changing Jobs 💼

I changed jobs this year. I’d been with Lensrentals.com for almost four years. It was my first full-time Ruby job.

I owe several people there for the knowledge they shared with me and how great they treated me. I made some genuine friendships there.

I got to learn a lot about not only Ruby, but deeper understood testing, OOP, and even got to do some React in my last few months. I have the utmost respect for the developers at Lensrentals, as well as the senior management.

Leaving Lensrentals was a difficult decision for me.

The company I joined is Podia.

Joining Podia has been a spectacular experience, so far. I was employee number eight, and we ended the year with eleven employees. I’ve been able to witness (what I consider to be) great growth at the company.

Since May I’ve been a part of some great feature launches. I very much like working on a product for creators, because I one day aspire to be a creator.

The “boss” is great, and my co-workers accepted me (and my stupidity) from day one. ❤️

So, leaving Lensrentals was (b|s)ad, but Podia has been great.

Less Public Speaking 📢

I didn’t make a significant effort to speak at conferences in 2018. I’m not sure why, to be honest. I spoke at two conferences, one of which I was asked to speak out.

I didn’t even submit to any other 2018 conferences.

It takes a lot of work to speak, as many of you know. You have to have some ideas on talks, work up a solid abstract, 🤞 hope it gets accepted, and if it does: create an excellent presentation.

It’s possible subconciously I didn’t want to go through that in 2018, but honestly, I don’t know why I held back this year.

Built an App 📱

I finished building this app that I’ve been working on (and rewritten what feels like hundreds of times) for the last few years. The app is React Native with a Rails API. I polished it up and submitted it to the app stores.

Google accepted the app within 30 minutes, and I was in the Play Store. Apple, however, after several days rejected the app because “it promoted self-harm.”

I understand Apple’s position; the app was like Untappd for cigar smokers. It “promoted” the use of cigars. Nonetheless, it was a frustrating experience because of all the time I wasted.

I decided to build a Progressive Web App (PWA) using React and Firebase. By the time I finished it, I’d lost any interest in it. I was especially concerned about the adoption of the app considering you had to visit a website and then bookmark the app to your home screen. 🤷‍♂️

I’m glad I finished it because I learned some things along the way. But yeah, not a happy ending.

Not So Good

It was important to me to start with the good. I have Obsessive Compulsive Disorder and tend to obsess on the “bad.”

I talk with Chris Oliver regularly about what’s going on in my life. One of the first things he brought up when I was recently explaining how down I am, was all the positive things that happened in 2019. A second thank you in this post, Chris.

Building a Product, Audience, Etc 🛠️

One of the most disheartening things to look back on is how much I squandered opportunity in 2018 (and 2017).

My oldest son was born two years ago on December 29, 2016. I spent the time I was on paternity leave (that wasn’t changing diapers, catching up on sleep or weeping in the fetal position) thinking about my future.

It became clear to me that I wanted to one day “work for myself.”

It wasn’t a new revelation, I’ve wanted to do so since before I became a programmer. I dreamed in high school of owning a music retail store one day. There’s something about owning my own business that has always appealed to me.

It wasn’t until my son was born I somehow finally pieced together that I can combine the desire to start a business with my passion (and career) of coding.

Little did I know the rabbit hole I would go down.

During that time I purchased Marketing for Developers by Justin Jackson. That course opened my eyes to the world of building products in the digital age. Justin is a gold mine. Everytime he says something I want to listen.

That’s also when I began spinning my wheels, though.

I wanted to build a SaaS (Software as a Service) app. After all, a lot of my heroes have done that. Hell, the web framework I use the most came as an abstraction from a SaaS application.

Quickly I learned there is quite a bit of (good) advice in the product community to not start with a SaaS app, but rather by doing two things: building an audience (by helping people solve problems) and creating a product that helps people learn something (think eBook or a Online Course).

Both of these things sound good to me!

I was laser focused. I put my head down and got to work.

I bought a ticket and flew out to Las Vegas for MicroConf where I got to meet some of my heroes in the product and programming community.

I bought consulting time with Justin to learn how to find and validate ideas.

I spent ~$2000 and started on 30x500.

I made sure people could join my email list and finally, I was ready to go.

And then I did nothing. I psyched myself out. I’ve continued to do that for the last two years.

It’s not that I don’t want to build a product. No, I obsess about that and beat myself up for having nothing to show.

Decision Paralysis and Self Doubt

I mentioned earlier that I have OCD. Not like, “haha I’m OCD about this thing,” but rather “oh shit my doctor has diagnosed me with OCD.”

There are several things I could teach. My dream is to help people with Ruby. (If you don’t know, I love Ruby)

This is where decision paralysis creeps in.

“I could teach beginners Ruby!… Well, there’s already good content out there, how would I make any difference?” Boom: Self Doubt

“I could teach Ruby developers React!… Well, I’m not an expert in React, people will think I’m stupid… I shouldn’t try to teach that.” Boom: Self Doubt

The process continues and eventually, I don’t do anything, because I’ve become unable to decide on what to write about.

One of the big reasons I’m unable to make a decision is because I’m too scared to put myself out there. I not only struggle with OCD but also Generalized Anxiety Disorder (GAD).

I’m afraid (absolutely terrified) that people will think I’m a fraud, or that I won’t add any value to anyone. I’m so scared that I eventually retreat and do nothing.

When I get to this point, I don’t want to write blog posts because I’m afraid. I don’t build an audience or help anyone, because I’m scared.

In 2019 I only wrote three blog posts. 😢

Riding the High

Aside from being scared to make an effort, I’m also bad about getting excited about new things and then backing away as the excitement fades.

When I get time to sit down and work, I’m exhausted from overthinking, or I get distracted by some other shiny thing.

Sometimes, I just don’t want to do the work, because I’m lazy. 😞

Unfocused

I’ve become so entranced with the idea of building a product, at times I’ve forgotten the reason you make products: to help people.

If you can earn income from that, that’s awesome! I don’t think there is anything wrong with that. However, when the focus becomes “success,” it gets muddy.

No one has advised me to focus on the end result, in fact, the opposite. That doesn’t stop me from day-dreaming about the end result. That’s when I start to lose sight of what I’m doing.

When I’m obsessed with making a living from products, I’m so scared to fail. If I don’t think something is going to be a huge success, I start to doubt and then eventually abandon. AKA, I get nowhere.

This leaves me with a twisted vision that I can’t fail. Whatever I do has to be a success. 🤮 Saying this out loud is embarrassing because it’s not true.

The most successful people I know (thinking about Justin Jackson, Adam Wathan, and Mike Perham, to name a few) spent time helping people. Their paid products are an extension of their time writing or building things to help others.

I asked Adam at MicroConf 2017 about how he built his audience. He told me (something along the lines of):

“Most people want to take a shortcut. They don’t want to put in the work to help people.”

Adam Wathan

I’ve lost focus. What good is an audience or a product if I’m throwing shit at the wall hoping it makes money. 🤢

I want to refocus and help people grow as developers by sharing quality information. The opposite leaves me in a never-ending loop of frustration with nothing to show.

Products with Co-founders

I also have three open projects I didn’t complete in 2018. For these, I’m not alone- I have a “co-founder” for each product. Also, these products we’re making have potential, but I back myself into a corner of self-doubt and laziness.

My goal is to launch two of them in January and get head down working on the third in February.

Excuses

I’m getting ahead of myself, here, but if you’ve read this far, I want you to know: these are not excuses. Though I’ve let myself fall into bad habits and listen to my negative thoughts, I can do this. I’m making an effort to identify my weaknesses to do better.

My plan for 2019 is to go deeper, not wider- an idea from David Cain. I have more to say on this at the end.

Finances 💰

As a software developer, I’m lucky to earn an excellent salary. It’s enough for Shannon to stay home and raise our children full-time, which is something she wants to do.

The problem is, I’m horrible with money. I’ve been known to make impulsive decisions financially with money we didn’t have. AKA, we did things with credit cards we shouldn’t have.

We have a decent amount of debt. It’s one of the most significant stressors in my life. It’s no one’s fault but my own, but it’s still something that eats at me.

Two thousand eighteen was a better year. We budgeted each month and made strides to get our money on track. We, at times, still overspent, but as the year comes to a close, I’m happy with how Shannon and I are approaching money.

An example of a better step in the right direction: Shannon and I are taking a trip. This time, we’ve paid for the trip with money we’ve saved up. 🙌 Before, I would have thrown the trip on plastic and “worried about it later.” Except, later accumulates to where we are now.

My goal for 2019 is to pay only with money we have and to have one of the best years for paying off the debt we’ve seen as a family.

Health 🍴🏃‍♂️😭

I’m the largest I’ve been to date. In 2011, I was at my (then) heaviest of 280lbs. I decided I was tired of it and lost ~65lbs. I felt the best I’d ever felt, was more active, impressed Shannon with my smoking bod 😉, and I was overall happier.

Around the time I got married, I started to deal with my anxiety and depression issues. I didn’t want to bring that added stress into a new marriage.

I started a new anxiety medicine with a side-effect of weight gain. “Meh,” I thought. I’ll be okay.

That, alongside “eating my emotions,” has led me to today. I weight 350lbs. 😳

I’m unhealthy, feel terrible, and worst of all: sometimes struggle to play with my kids. 😭

I spent a lot 0f 2018 thinking about how I want to be around for my children. It’s one thing if something happens to me that I can’t control. My health, though? I own the responsibility. I want my children to know their dad fought for his health because he loves his family.

The end of 2018 I’ve started taking baby steps. I’m more mindful of what I eat and how much of it I eat. I also started the process of changing medications to see if that helps me regain control of my eating habits. So far, I’m eating less and optimistic for the future.

2019

I highly debated writing a “year in review,” because I a) don’t think people care about what I did and b) didn’t know how to think about the future.

I’ve never kept a New Years Resolution. Why keep coming up with them?

Today, I was reminded of a post I read by David Cain entitled “Go Deeper, Not Wider.” (aside: David is amazing and you should read whatever he writes)

I realized that in 2019, I don’t want to add to my to-do list or try to “widen” an already uncompleted list. I want to deal with, and actually, make progress on (deepen) what I felt was lacking this year.

So, with that said, here is my list of things I would like to accomplish in 2019.

Gain control of my health. I want to lose weight, be more active, and find contentment with my appearance.
Pay down debt. It’s not feasible to pay off all our debt in 2019. However, it is possible to make great strides and sacrifices to pay down our debt and continue to work towards financial freedom.
Grow technically. I’d like to invest more in technology. I’d like to grow deeper in what I currently know about Ruby and JavaScript, the two languages I use the most.
Help people. I want to focus on writing blog posts, making videos, and helping developers. Instead of paralyzing my brain worried about what to write about, I want to share more of what I’ve learned since I became a programmer. I want to worry less about “building a product.” If a product comes out of helping people, that’s amazing. In 2019, though, I want to reset my focus on others more than myself.
Finish things. Finally, I want to finish what I’ve started. The more I continue not to finish things and start something new, the more stress I add to my life and subsequently my family’s life.
Join a new church community. The end of 2018 was also the end of seven years of membership at our church. There’s no big drama here, we just felt it was time to move on. Shannon and I are focused on finding a new church for our family, which isn’t an easy task.

If you’re interested in growing as a developer, or getting started in web development: please reach out and let me know things you’re interested in learning. I want to know how to help.

I wish you the best in 2019. Thank you for reading.

Remote Ruby #20: Trivia Questions and Answers

2018-12-20T00:00:00+00:00

On episode 20 of the Remote Ruby podcast, Chris and I play a game of trivia. These questions are composed of information from Wikipedia and beneggett/ruby-trivia.

I have no doubts that some of this information could be wrong. I was a late bloomer to Ruby. 😎

I hope you enjoy(ed) the episode.

According to Matz, what year was Ruby conceived? 1993
What year did Ruby first appear? 1995
There were two potential names for the language. In the end, Ruby was the name chosen. What was the other proposed name? Coral
What was the first book written in English about Ruby? Programming Ruby
What year did the popular Ruby web framework Ruby on Rails first appear? 2005
On what day is a new version of Ruby typically released each year? December 25
What version of Ruby unified the Fixnum and Bignum classes into the Integer Class? Ruby 2.4
What version of Ruby introduced keyword arguments? Ruby 2.0
What version of Ruby introduced the safe navigation operator? Ruby 2.3
What version of Ruby introduced the ability to use colons for symbol keys alongside the hash syntax? Ruby 1.9
What version introduce method chaining using the yield_self method? Ruby 2.5
What is the estimated release date for Ruby 3.0? Hint: It’s a year. 2020
When you define a method at the top level, what class is that method called on? Object Class
What is the standard Ruby interpreter often referred as? MRI
What Ruby implementation was designed for enterprise environments and optimized for large-scale Ruby on Rails apps? REE
What web framework did Ruby on Rails merge with for the release of Rails 3? Merb
What is the name of the popular graphic novel used to introduce Ruby to developers? Why’s (poignant) Guide to Ruby
What popular implementation of Ruby runs on the JVM? Jruby
What is the name of the upcoming implementation of Ruby on the GraalVM? TruffleRuby
What year did Matz recently announce as a potential year for him to retire? 2025
Can methods be added to a Struct? yes
Which method is invoked when a method is not found? method_missing
Which method is invoked when a constant is not found? const_missing
What error is raised if a method is passed the wrong number of arguments? ArgumentError
What is the default encoding of MRI? UTF-8
Why must a module name begin with a capital letter? It’s a new constant
Are constants public or private? public
Is initialize public or private by default? private
Does a method return a value if it does not contain an expression? it returns nil (which is a value)
Name one immutable object in Ruby? symbols

Eager Loading/Querying ActiveStorage Attachments

2018-06-19T00:00:00+00:00

ActiveStorage, the new kid on the block. It’s exciting for Ruby on Rails developers to have a built-in solution for file uploads/attachments. Let’s talk about interacting with the table ActiveStorage gives us. There are times that we’ll want to reach for eager loading and even query against our attachments. Without much effort, it’s easy to commit the N+1 sin.

# app/models/thing.rb
class Thing < ApplicationRecord
  has_one_attached :image
end

# app/controllers/things_controller.rb
class ThingsController < ApplicationController
  def index
    @things = Thing.all
  end
end

# app/views/things/index.html.erb
<% @things.each do |thing| %>
  <%= image_tag rails_blob_url(thing.image) %>
<% end %>

👆 This view, my friends, is N+1 city. For every call to an image, ActiveStorage makes a call to a table where the image record resides.

Built-in Eager Loading

Rails, as you might come to expect, has a built-in solution to prevent this. Using the example above, you’ll note that we have a single attached image. Under the hood, this means that a Thing is implicitly setup with the following relationship:

class Thing < ApplicationRecord
  has_one :image_attachment, -> { where(name: 'image') }, class_name: "ActiveStorage::Attachment", as: :record, inverse_of: :record, dependent: false
  has_one :image_blob, through: :image_attachment", class_name: "ActiveStorage::Blob", source: :blob
end

You get all this 👆 for free by adding has_one_attached :image to your model. My attachment is named image, anytime you see a reference to image in my code, change it to your attachment name.

A Rails scope exists to allow us to take advantage of this relationship. If we wanted to preload those images, we could change the controller to use the following scope:

# app/controllers/things_controller.rb
class ThingsController < ApplicationController
  def index
    @things = Thing.with_attached_image.all
  end
end

This scope 👆 uses preloading under the hood 👇

includes(image_attachment: :blob)

Querying Against ActiveStorage Attachments

Preloading is dandy, and all, but what happens when you want to query against the attachment records? This question is similar to the use case that led me here.

Specifically, I only wanted to show records that have an image attached. After digging through the ActiveStorage source code, I ended up finding not only the references to the code above but also the answer to this question.

I’d like to return _only _the records without an image record. The following is the result 👇

Thing.where.missing(:image_attachment)

Here, we piggybacked off the implementation of the earlier scope we saw, with_image_attachment.

Throw this behind a scope and you’re cooking!

Adding Bootstrap Errors to Rails Fields with Errors

2018-02-13T00:00:00+00:00

The other day I was working on a new Rails application. Though I’m currently obsessed with Tailwind CSS, this project was a better fit for Bootstrap. I needed some predefined styling, quick. Unfortunately, fields with errors got in my way. The app, like most web applications, required forms. Using Ruby on Rails’ (ActiveRecord) model validations, I was able to setup displaying error messages efficiently. I reached for a Bootstrap alert, shoved in a loop of error messages, and done. Or, so I thought. 🤔 Isn’t it a better experience for the user if the fields that failed validation change border color? In fact, Bootstrap 4 has support for this.

The Problem(s) was Fields with Errors

Great! Except there’s one problem. If you’re familiar with Rails, you’ll know that when the page rerenders after a failed form validation, the field failing validation is wrapped inside <div class="field-with-errors" />. In my case, I wanted to add the class name is-invalid to the failed input. In fact, “field with errors” doesn’t do much for me at all, since I’m not writing custom styling. Writing custom styling would allow me to write some CSS, like this:

.field-with-errors input {
  border: 1px solid red;
}

This would have been extremely powerful, and a boost in development speed had I been writing my own CSS. In this case, though, we want to defer styling decisions to Bootstrap. As mentioned before, Bootstrap already has support for this. By writing this CSS above we’re hurting ourselves in one of two ways:

We’re distancing ourselves from the styles provided by the CSS framework we’ve chosen to use. Or;
We’re creating more work for ourselves by trying to match the Bootstrap style with custom CSS.

The Solution

If you’ve encountered this problem before, you might know that you can override this functionality. The solution I like best is a Stack Overflow answer. Let’s start with the code in this solution, break down what it does, and then tweak it for Bootstrap 4.

1. Create an Initializer

Create an empty Ruby file: config/initializers/customize_error.rb

2. Use the Code

Inside your newly created file, add the code.

ActionView::Base.field_error_proc = Proc.new do |html_tag, instance|
  class_attr_index = html_tag.index 'class="'

  if class_attr_index
    html_tag.insert class_attr_index+7, 'error '
  else
    html_tag.insert html_tag.index('>'), ' class="error"'
  end
end

Let’s talk about what this chunk of code does. If your ActiveRecord backed form fails validation, ActionView calls this proc for each field that failed validation. The proc passes an html_tag (the form-field) and the instance into the block. If we didn’t overwrite it, it would wrap the field in a div that looks something like this:

<div class="field-with-errors">... html_tag ...</div>

However, we’re going to override that by modifying the field directly, versus wrapping it in a div.

class_attr_index = html_tag.index 'class="'

👆🏻 This variable tells us if the field already has a class attribute, or if it doesn’t. If it does, we’ll get the index where class=” is in the raw HTML string. If it does not have class=” anywhere, we will set the variable to nil.

if class_attr_index
  html_tag.insert class_attr_index+7, 'error '

👆🏻 If the variable is not nil, we can append the class name error to the beginning of the class name list. The extra space is essential. If “class” already exists as an attribute on the form field, we want to keep the existing class intact.

else
  html_tag.insert html_tag.index('>'), ' class="error"'

👆🏻 If the variable is nil, right before we close the html_tag, we need to insert the entire class attribute assignment.

3. Modify the Code for Bootstrap 4

There are only a few changes I’ll make here.

ActionView::Base.field_error_proc = proc do |html_tag, _instance|
  class_attr_index = html_tag.index 'class="'

  if class_attr_index
    html_tag.insert class_attr_index + 7, 'is-invalid '
  else
    html_tag.insert html_tag.index('>'), ' class="is-invalid"'
  end
end

The most important change is converting the class name from error to is-invalid. With this done, be sure to restart your Rails app as initializers load on boot. In front of the argument “instance,” I added an underscore. This underscore may look silly to you, but it is a standard convention for block variables passed in and never used.

Do What Feels “Right”

There were many ways I could have Made This Work™. However, they would have felt like a hack. For instance, I could have used JavaScript to apply the Bootstrap field is-invalid to the form field once the page re-rendered. Or, I could have tried to re-create the Bootstrap styling for errors. However, with a little patience and research, it turns out Rails had the tools at my disposal all along.