DEV Community: Felipe Vogel

Alpine.js as a Stimulus alternative

Felipe Vogel — Wed, 20 Nov 2024 17:00:00 +0000

Did you know you can use Alpine.js without having inline JS in the HTML, but instead putting it in separate files, similar to Stimulus? And unlike Stimulus, Alpine allows declarative templating. Yes, in your Rails/Laravel/Django/whatever server-rendered view templates!

Table of Contents

First, the context
Why not Turbo?
Why not web components?
Stimulus is incomplete on its own
Alpine.js
- Alpine is like Stimulus!
- Alpine is NOT like Stimulus!
Examples
- Example 1: toggle menu
- Example 2: filterable list
But what if I need Turbo?
Conclusion
Bonus: Alpine plugins

Recently I discovered Alpine.js as an alternative to Stimulus for conveniently sprinkling JavaScript into server-rendered pages—and it may even be a better alternative.

You may know of Alpine as that little JS library where you write inline JS in the HTML—ewww! That's all I knew about it too.

But it turns out that you can put the JS in separate files, as in Stimulus, and you can even prohibit inline JS with the Alpine CSP build. But I'm getting ahead of myself…

First, the context

At my job, I work on a fairly vanilla Rails app. One of its oddities, though, is that it uses Stimulus and not Turbo, its sibling library in the Hotwire suite.

Below I go into why we don't use Turbo, but the point here is that Stimulus is currently our only tool for creating real-time UI functionality, and it hurts. No one at work really likes Stimulus, I think because we're expecting too much from it and using it in ways it wasn't designed for. (More on that below.)

Some teams are pushing to migrate the app to Angular. I'm doubtful whether that would be worth the effort, so I'm looking into Alpine to see if it would give us some of the conveniences of a framework like Angular, but without the huge migration and added complexity.

Why not Turbo?

I mentioned that our app at work doesn't use Turbo. A Git log search (git log -S) reveals that the developers back in 2016 removed Turbo's predecessor Turbolinks from the app, with commit messages like Get your stupid Turbolinks outta my house 😂

Then, starting around the time Turbo was released in 2020, teams were rearranged and the customer-facing part of the app stopped being seriously worked on, until my team was formed earlier this year. During that interval, there wasn't much impetus to look for something better than just Stimulus.

Also, we heavily use Lit web components from our in-house design system in a way that Turbo (with its server-centric mindset) would be an awkward fit. It's easier for us to use a JS library that plays nicely with web components by operating on the client side, as Stimulus does.

Why not web components?

The previous paragraph begs the question, Why not just build your features in Lit?

It's because I, along with the rest of my team, enjoy keeping Rails view templates server-side. Let's say I want to add real-time behavior to a view: if I have to move an ERB template into a Lit component and translate it into JS, it feels like I've left the realm of "JS sprinkles" and now it's more like "JS chunks".

If that feels like a meaningless distinction to you, and if you find Lit components to be perfectly usable in day-to-day feature work, then go ahead and use Lit instead of Stimulus or Alpine! I honestly wish I didn't feel as much friction as I do when making Lit components, because Lit is probably the more durable option since it's closer to web standards than Alpine.

Who knows, maybe in a few months I'll write a post titled "Web components as an Alpine.js alternative" 😂 I've seen efforts underway to more easily server-render web components (and not just in Node), so it may someday be possible to declare a web component within a server-side template such as ERB, using regular HTML with special attributes for the dynamic bits. In fact, I was looking for such an approach to web components when I ran across a comment saying that's precisely what Alpine does, minus the web components part.

All that to say, my thoughts below are subject to change when web components become easier for this use case focused on non-Node SSR, or "keep your templates and sprinkle in dynamic behavior".

Stimulus is incomplete on its own

My gripe with Stimulus is that it's imperative, not declarative. In most modern JS front-end libraries (React, Angular, Lit, etc.), you have a template that is automatically re-rendered based on changes to state that's stored in JS. But with Stimulus, as with jQuery, state is expected to be stored in the DOM, and you have to manually change the DOM in response to events. It gets tedious fast.

But here's the thing: Stimulus was intentionally designed this way so that it would work well alongside Turbo. To quote the Stimulus Handbook:

Stimulus also differs on the question of state. Most frameworks have ways of maintaining state within JavaScript objects, and then render HTML based on that state. Stimulus is the exact opposite. State is stored in the HTML, so that controllers can be discarded between page changes [such as HTML fragments morphed in via Turbo], but still reinitialize as they were when the cached HTML appears again.

In other words, Stimulus discourages storing state in JS because that state disappears whenever an element with an attached Stimulus controller is replaced by Turbo.

Consequently, Stimulus wasn't designed for building elaborate front-end features. Turbo does the heavy lifting, and Stimulus handles the leftover bits: small, generic components or behaviors. See the examples in the Stimulus Handbook (a copy button and a slideshow), advice in articles on Stimulus (1, 2), and open-source Stimulus controllers.

… But we don't use Turbo at work, and for the reasons I gave earlier it would be complicated to use Turbo in our app. So I thought a better starting point would be to find a "JS sprinkles" library that's more capable on its own than Stimulus.

Alpine.js

Alpine is like Stimulus!

Alpine.js is similar to Stimulus in several ways:

It's small. The bundle sizes of Stimulus and Alpine, respectively, are 10.9 kB and 15.2 kB.
It's SSR-friendly. Both Alpine and Stimulus are used in server-rendered templates via special HTML attributes.
The JS can be in separate files. This isn't obvious from the Alpine docs, where almost all of the examples have JS written inline in HTML attributes. But as we’ll see in the examples below, the JS can be put in its own separate files just as in Stimulus.
- Because of Alpine's use of inline JS by default, some other comparisons of Stimulus and Alpine (1, 2) claim that Alpine lacks structure, and consequently doesn't scale well in bigger projects. But this doesn't have to be true!

In fact, you can use Alpine in a way very similar to Stimulus. Using the mappings below, you can write JS with Alpine that looks the same as Stimulus, apart from different syntax and naming:

x-ref is like Stimulus targets
x-on is like Stimulus actions
Where Stimulus has lifecycle callbacks, Alpine has these:
- init() is like Stimulus connect() and [name]TargetConnected().
- destroy() is like Stimulus disconnect() and [name]TargetDisconnected().
- A plain constructor() in an Alpine data class is like Stimulus initialize().
I've never used Stimulus outlets, so I can't confidently say whether they can be emulated in Alpine. But you probably wouldn't need them.
Plain data attributes can stand in for Stimulus values. Or if data attributes become cumbersome, see my examples below for an x-props custom directive in Alpine.
x-bind for Stimulus CSS classes.

So Alpine is more or less a superset of Stimulus.*

* Note: this is not true if you're using Stimulus specifically for its being a convenient wrapper around the MutationObserver API. I couldn't find a good example of what that looks like with Stimulus, but one scenario where you need MutationObserver is to make a web component react to DOM changes (1, 2).

Alpine is NOT like Stimulus!

Alpine goes beyond Stimulus in that it's fundamentally declarative.

Stimulus is limited to granular DOM manipulation, as in "on X event add a 'hidden' class to elements A and B; on Y event remove the 'hidden' class from elements A and B"

But Alpine allows a declarative style, as in "show elements A and B when Z is true" (see x-show).

This shift from imperative to declarative style can make your JS so much more readable, maintainable, and bug-resistant. As an experiment, at work I did a Stimulus-to-Alpine conversion of an "Edit Mailing Address" form built around an in-house web component for address autocomplete. The web component emits events that my JS captures and translates into error messages on the form. I was shocked at the difference:

The Stimulus controller was 207 lines long, filled with logic that was difficult for me to follow even though I'd written it myself just a few weeks ago—and writing it had been a nightmare of continually finding yet another bug in my code.
The JS class for the Alpine component totalled only 60 lines, was easier to write, and is actually possible to understand at a glance.

Examples

I can't actually show that example from work, so rather than making up my own new examples here, I'll just link to the two examples in Brian Schiller's post "Alpine.js vs Stimulus", and I'll add my own alternate Alpine versions that keep the JS out of the HTML.

In my versions of the examples, I used the CSP build of Alpine, where inline JS is actually impossible. This nicely serves as a form of no-inline-JS linting. It also introduces some inconveniences, but they can be worked around:

Passing initial parameters into a data object is impossible. No big deal: you can just use data attributes or (if that becomes clunky) a custom x-props directive, which you can see in my version of the second example below.
x-model doesn't work in the CSP build. The workaround is to use the two directives that x-model is a shortcut for:
```

<input x-model:"myProperty">


<input :value="myProperty" @input="setMyProperty">
```
- :value is short for x-bind:value (docs), and @input is short for x-on:input (docs). This workaround makes an appearance in my version of the second example below.

Example 1: toggle menu

This is Brian Schiller's second example, but I'm putting it first because it's the simpler of the two.

Brian's Stimulus version: CodePen, Brian's notes
Brian's Alpine version: CodePen, Brian's notes
My Alpine CSP version: CodePen

My notes: The HTML is cleanest with Alpine CSP, and the JS file is still super short.

Example 2: filterable list

Brian's Stimulus version: CodePen, Brian's notes
Brian's Alpine version: CodePen, Brian's notes
My Alpine CSP version: CodePen

My notes:

Once again the HTML is cleanest with Alpine CSP, but the JS file is not so satisfyingly short this time. Partly that's due to how this example is more complex, but another reason is that I threw in the x-props custom Alpine directive, not because it was needed but just for the sake of example.
I didn't love that I had to pull in an extra package to access a parent component's data.

But what if I need Turbo?

Earlier I pointed out that the apparent shortcomings of Stimulus are by design, in order for it to be compatible with Turbo. Does that mean you can't use Alpine with Turbo?

Yes and no. If you've already built your app using Stimulus and Turbo, it might not make sense to switch from Stimulus to Alpine. Turbo is probably handling most of the real-time interactivity anyway.

But if all you want is something like Turbo, i.e. a way to take HTML fragments sent from the server and morph them into the page, here are Alpine-friendly options for you:

htmx, which has an alpine-morph extension.
Alpine AJAX, which has a similar morph feature.

I'd probably pick Alpine AJAX, but more importantly I wouldn't reach for morphing without considering other approaches first, because morphing is complex and has limitations and edge cases. For example:

a critique of htmx and the htmx author's reply that it's a work in progress
a similar critique of Turbo

Conclusion

I'll piggyback on Brian's post one more time and repeat its conclusion here:

I can enthusiastically choose Alpine over Stimulus. Stimulus seems to have skipped the lessons of the past 7-8 years. It’s better than jQuery, but ignores the things that are good about React, Vue, etc: reactivity and declarative rendering. Meanwhile, Alpine manages to pack a ton of useful functionality into a smaller bundle size than Stimulus.

Alpine's bundle size has now grown somewhat larger than that of Stimulus, but otherwise I wholeheartedly agree with that conclusion.

And I'll add this: for anyone who is concerned about the maintainability of inline JS in HTML and prefers clean markup, a clear separation of concerns, TypeScript, etc. … you can do all that with Alpine! I think Alpine is the best of both worlds, between "all-in" JS frameworks that handle rendering (React et al.) and vanilla JS: declarative and template-friendly like React et al., but at the same time, small and easy to sprinkle into your server-rendered templates.

Bonus: Alpine plugins

Another nice thing about Alpine is how many plugins there are out there. I already mentioned Alpine AJAX; here are just a few others:

The "plugins" nav section in the Alpine docs
Form validation and others by Mark Mead, especially the HyperJS collection
Requests
Clipboard and others by Ryan Chandler
Autosize
Auto animate
x-include and x-interpolate

You can find lots more in lists like Alpine Extensions and Awesome Alpine Plugins.

Being laid off in 2023-2024 as an early-career developer

Felipe Vogel — Wed, 27 Mar 2024 14:00:00 +0000

The saga of my second job search as a second-career software developer, amid waves of layoffs and a tough job market. Included: tips on getting interviews via job networking.

Table of Contents

Backstory: from teacher to developer
No one is safe from being laid off, and I'm not an exception
The 6-month job search
My job networking by the numbers
The good news
What's next in my career?

Recently I wrote an upbeat how-to on job networking. Now comes the part where I pull back the curtain and tell how the job search really went.

Don't worry, it's not all depressing. I've waited for weeks to publish this post just so that I have some good news to share at the end.

Note: This post's title specifies "early-career developer" only because I'm speaking from my own experience, not because only early-career developers are having a hard time. It's a tough job market for everyone in tech, even job seekers with decades of experience.

Backstory: from teacher to developer

For context, I used to be a schoolteacher. In 2019, after a sudden move back to the U.S. (Kentucky) from an overseas teaching position, I found myself earning a pitifully low salary of $32k/year and inundated with medical bills from my wife's chronic illness.

I didn't even enjoy my new job. The frequent late nights spent planning and grading, the emotional drain of managing classrooms full of teenagers all day, the nagging feeling that in spite of all the effort I wasn't actually helping these kids… it was too much.

It was time for a career change.

So I quit teaching at the end of the school year, got a customer support job (remote) in the COVID-fueled e-commerce industry, and taught myself coding in the evenings and on weekends. After a year and a half, in February 2022, I got a junior developer job (also remote), and the following year I was promoted to mid-level.

Meanwhile, my salary went up and up. In this same post on my site I've included a chart showing my gross pay since the beginning of 2020, when I was still a teacher.

Did you notice the gap near the end? That's the story of this post.

No one is safe from being laid off, and I'm not an exception

In early 2023, my company had a 19% RIF (reduction in force, i.e. layoffs). Of my cohort of four junior developers that had joined the previous year, I was the only one who wasn't laid off.

I was shaken, but also bolstered in my belief that I'm special. I felt I was a great developer, and that would keep me safe from being laid off.

Fast forward to November, and… I was laid off. The immensity of this second round (44% RIF) was some consolation in that I didn't feel singled out. But at the same time, I felt uneasy seeing how all of my former junior colleagues were still looking for a new role after so many months. Plus, I'd actually started applying for jobs two months earlier because I saw the layoffs coming, and I'd gotten no responses from dozens of applications.

Still, I clung to the belief that I'm special and I'd have an easy time finding another job now that I could make my job search public and fully focus on it. After all, my previous job search in 2021 had been pretty easy, and that was when I had zero professional experience as a developer. How hard could it be this time?

I was in for a big disappointment.

The 6-month job search

It was rough. Here are some low points:

🦗 The crickets chirping. For the first three months, I applied to dozens of jobs and got zero responses. That's a whole month after my job search went public. Then I started job networking, following a process that I posted about previously.
😐 Insane levels of competition. I experienced a new level of job market saturation when I was rejected near the end of an interview process because a candidate with 16 years of experience was chosen instead… for a mid-level role at a company that also had open senior positions.
🤦 Nonsensical skill requirements. One final interview was a surprise live coding exercise covering React. But here's the thing: this was for a back-end role! That caught me off guard, and I didn't do well in the exercise.
😵‍💫 So many hours spent on take-home assignments. We all know that the "2-3 hours" in a take-home assignment description means about five times that much. Once, I spent 20 hours on an exercise, between the take-home portion and live coding prep. (If you're wondering "Huh? Live coding prep?" it's because, unusually, they sent me the live coding exercise ahead of the interview. But it was also an unusually complex live coding exercise.)
- Not to digress too much, but why are take-home assignments so long? Why doesn't a bit of (no-prep!) live coding suffice? For example, I remember an interview process in my 2021 job search that didn't have any take-home assignment, only a live coding interview. It was a simple exercise building a CLI hangman game. The requirements were minimal and I didn't even have to finish it—the interviewer just wanted to see my thinking process, and it was very conversational. After about 15 minutes he stopped me, reiterated a few things I'd done that he liked, and said he'd be in touch. And that was it. I really appreciated that the interviewer knew what he was looking for and knew how to spot it quickly.
💀 Lowering my bar down, down… nope, lower. In January, about five months after I'd first started searching, I accepted a job that paid significantly less than my previous salary. Not only that, but the interview process had given me all kinds of red flags, including very mixed Glassdoor reviews and the hiring manager saying that promotions and raises were on hold indefinitely. I took the job anyway because I had no idea how many more months it would take for me to get an offer from a different company, and I wanted to prevent the worst-case scenario of my savings running out. Meanwhile, I kept looking on the down-low—I had to immediately go silent on LinkedIn because my new employer made it clear to me that they didn't want me posting there anymore 🙄 Fortunately, I soon found a better job. (More on that below.)

My job networking by the numbers

Backing up a little bit, job networking is what turned the tide and helped me start getting interviews. I described my process in a previous post, and now I can share more on the results.

I applied for 18 roles that I networked for, i.e. where I didn't submit a cold application. These were mostly in December and January, months 4 and 5 in the 6-month search. The networking that I did can be divided into the three broad types below (which you can see represented visually further down, if you want to skip the verbiage).

Note that I applied only for remote positions, because there aren't a lot of in-person developer jobs in my area (central Kentucky), and in-person salaries here tend to be lower anyway. For anyone living in a tech hub, it's a good idea to do in-person networking too, such as attending local meetups.

Existing connections: I already had a connection in the company, first- or second-degree.
- Of 10 attempts, I got 6 recruiter screenings, and in 3 of those I got more interviews.
LinkedIn messaging: I tried forming a new connection by messaging a stranger via InMail on LinkedIn.
- Of 7 attempts, only one led to a recruiter screening and then further interviews. But I only twice got no response; people were generally willing to talk to a random stranger like me, and twice I got a referral. In case you didn't know, most companies offer a referral bonus to employees after they refer a candidate who ends up being hired. So even if it feels awkward to message a complete stranger, it's worth a try because they're incentivized to refer you.
Third-party recruiter: I applied for one job through Brian at Mirror Placement, and it led to a recruiter screening and a further interview. Besides that one role, Brian said he didn't have anything for an early-career developer like me. But I enjoyed working with Brian, so I'll definitely talk to him again in the future when I have more years of experience.

In total, of these 18 attempts, 8 got me a recruiter screening, and in 5 of those I went on to further interviews. Two of these led to job offers: the one I accepted early out of caution, and the one for my current role. Here's all of the above visualized in a diagram built with SankeyMATIC:

I should also mention that cold applications yielded a grand total of one recruiter screening, after which I was ghosted by the recruiter. I cold-applied to over a hundred jobs, so that's a pretty terrible success rate. Granted, most of those applications were low-effort and done only to satisfy my state's unemployment requirements, but there was a sizable minority into which I put genuine effort, including painstaking answers to "Why are you applying?"-type questions, and even a few cover letters.

Just for fun, here is the above diagram with cold applications added in:

By the way, this contrasts starkly with my last job search in 2021. It's funny to look back at my blog post about it, where I wrote:

Over two months, I applied to seven companies, most of them startups. I got a first-step interview or recruiter screening at six of those companies, and in five of them I moved forward to next steps.

The crazy part is that those were all cold applications 😳

Unless I was an incredible candidate back then in a way that I now fail to recall (or recreate), clearly the job market has changed a lot since two years ago.

The good news

Enough with the doom and gloom. I'm happy to announce that I got a job at Kin Insurance as a full-stack Rails developer.

Now I can finally stop job hunting, and focus on progressing my career in more productive ways.

What's next in my career?

Getting into the community. Recently I was accepted as a Ruby Central Scholar, meaning I'll give a lightning talk at RailsConf 🎉 I'm also co-organizing a local Ruby meetup, Bluegrass Ruby.
Less overtime, more family time. At my last job, I often worked long days in order to get a lot done and impress my peers. You can see that reflected in my glowing LinkedIn recommendations from former colleagues—which, sadly, I'm not sure even made a difference in my job search. In any case, I'll be sticking more to a 40-hour work week because the past few months have made me re-examine my priorities, especially in light of the fact that I have a 9-month-old kid.
More "me time" too. I've also missed resting and investing in my own things, whether spiritual practices or reading Latin and Greek. Honestly, I'm going to have a harder time with this than anything else on this list, but I know it's important for my mental health.
More consistent learning. The job search also gave me a chance to get back to my Ruby/web development learning roadmap. I realized that at my last job, I wasn't consistently spending time improving my skills, outside of whatever I might (if I was lucky) be learning in work projects. It's just hard to fight against the pressure of the day-to-day work. Here are some approaches that I'll try this time around:
- Disregard immediate applicability and learn something I'm interested in for the sake of expanding my mind. Right now that's learning functional programming.
- Learn actively, whether by contributing to Exercism's Ruby track, building a collection of Ruby code katas, or maybe even creating a text-based game.

Coming to grips with JS: a Rubyist's deep dive

Felipe Vogel — Fri, 29 Dec 2023 15:45:43 +0000

tl;dr I'm systematically learning JavaScript using these resources.

Why?

Because JS is inescapable in web development.

Sure, you can use any number of JS-avoidance libraries. I'm a fan of Turbo, and there's also htmx, Unpoly, Alpine, hyperscript, swup, barba.js, and probably others.

Then there are stack-specific libraries: StimulusReflex for Rails, Phoenix LiveView, Laravel Livewire, Unicorn and Tetra for Django, Blazor for .NET, … and the list goes on.

You get the picture. Lots of people would rather not build a JS front end.

I myself avoided the JS ecosystem a few years ago when it would have been the default path for me as a beginning second-career developer. But I was going the self-taught route, so I needed an ecosystem with strong conventions. I didn't know how to choose from a dozen popular JS frameworks. And none of them is an all-in-one, "batteries-included" framework, so it looked like I'd need to make many decisions about how to put together an app, which would mean (for me at that time, as a beginner who lacked context) lots of frustration and stabbing in the dark.

It was in the Ruby world that I found the conventions I needed. Plus, I found (and still find) Ruby to be more enjoyable.

But now I've had enough web development experience that I can circle back and learn JS thoroughly, confidently, and without wasting as much time on rabbit trails.

Not that I can't get around in JS. At my last job, I was comfortable building full-stack features in Rails and React.

Oh, and speaking of my last job—recently I was laid off as part of a massive reduction in force. (Stay tuned for a future post on my job search and what I'm learning from it.)

Being unemployed and seeing so many jobs involving a JS front end—that's ultimately what gave me the push I needed to get serious about JS.

That's what I mean when I say JS is "inescapable": not that we can't build anything without it—in fact, I quite enjoy making sites with minimal JS and plenty of interactivity. I only mean that JS skills are mandatory for someone like me who has only a few years of experience, and therefore fewer job options. Even if I could find a backend-only position, I'm not sure I want to pigeonhole myself like that.

Plus, I really do enjoy full-stack development. And even if in some utopian universe I were able to land a full-stack position using some of the above-mentioned libraries instead of a heavy JS front end, it would still be important to understand what's going on behind the scenes. After all, those libraries are JS that's running on the page allowing my non-JS code to do cool interactive things.

So many reasons to learn JS!

How?

I'm using the resources listed below. Almost all are free. Besides a comprehensive look at JS syntax, I made sure to include a few other areas:

Guided practice and projects, to turn knowledge into skills.
Web APIs, especially the DOM, forms, and web components.
Deep dives into how JS works, and the rationale (or at least reasons) behind its quirks.
Functional JS, because I'm interested in functional programming. I recently started learning Haskell, but JS will be useful as an example of how to apply functional concepts in a not-really-functional language.

There's a lot in the bottom two-thirds of the list, only because I haven't gone through it yet and weeded out the less-than-awesome resources.

Also, note that this list is copied straight from the "JS" section of my learning road map, and the latest version may have evolved from what you see here.

Basics:
Practice:
- Exercism - JavaScript
- JavaScript30
DOM and forms:
Going deeper:
Functional JS:
Web components:
- Rob Eisenberg - "Hello Web Components"
- Dave Rupert - HTML with Superpowers: The Guidebook or the course version
- MDN - Web Components
- The Modern JavaScript Tutorial - Web Components
- Web Components Today
- Build a UI following Jared White - How Ruby and Web Components Can Work Together
- SSR web components in Ruby with the upcoming Heartml (see this Spicy Web article for context)
- Experiment using Turbo to drive front-end behavior: "Turbo 7.2.0 (currently in beta) allows you to define your own Stream actions which can be any JS code you want. By combining a custom Stream action or two with web components, you can essentially drive reactive frontend behavior from the backend stupidly easily. Loooove it! 😍 […] For a turnkey example, you could check out https://github.com/hopsoft/turbo_ready " —Jared White on The Spicy Web Discord

A word on JS frameworks

You may be wondering why my learning plan doesn't include any JS frameworks. No React deep dives? Not even the more hip Vue or Svelte??

I do plan on familiarizing myself with popular front-end frameworks, including the parts of React that I haven't used. Learning the patterns that are common across frameworks will be valuable, I think.

But if there's anything I focus on, I want it to be JS itself (along with other web standards) because they're a more durable investment, changing more slowly than JS frameworks.

Learning JS, re-learning Ruby

Readers who aren't into Ruby can feel free to leave now (it's OK, I won't feel bad), but I wanted to conclude by showing how learning JS has helped me re-learn Ruby features that I rarely use. Here are two examples.

Object destructuring

In JS:

const obj = { first: "Willard", middle: "Wilbur", last: "Wonka" }
const { first, last } = obj

Did you know Ruby can do something similar with hash destructuring?

obj_hash = { first: "Willard", middle: "Wilbur", last: "Wonka" }
# `=>` is the rightward assignment operator.
obj_hash => { first:, last: }

This is thanks to Ruby's pattern matching, which is actually a lot more flexible than JS destructuring. (For more complex examples, see "Everything You Need to Know About Destructuring in Ruby 3".)

Note, however, that there is a proposal to add pattern matching to JS.

Object literals

In JS:

const obj = {
  first: "Willard",
  last: "Wonka",
  full() {
    return `${this.first} ${this.last}`;
  },
}

In Ruby, every object has a class, so there's no concise way to define a one-off object, right?

My first attempt to prove this wrong was to add a method to an OpenStruct:

require "ostruct"

obj = OpenStruct.new(first: "Willard", last: "Wonka") do
  def full = "#{first} #{last}"
end

# Uh oh, that didn't work as intended!
# The `#full` method isn't actually defined.
obj.full
# => nil

It turns out this only works with a Struct:

Person = Struct.new(:first, :last) do
  def full = "#{first} #{last}"
end

obj = Person.new(first: "Willard", last: "Wonka")

obj.full
# => "Willard Wonka"

But now we're nearly in the territory of an explicit class definition, far from a JS-style one-off object.

OK, then just for fun, how about we expand OpenStruct so that it actually does something with that block?

require "ostruct"

class OpenStruct
  def self.create_with_methods(**kwargs, &methods)
    open_struct = new(**kwargs)
    open_struct.instance_eval(&methods)

    open_struct
  end

  # Now add a shortcut syntax.
  class << self
    alias_method :[], :create_with_methods
  end
end

# Or, OpenStruct.create_with_methods(...)
obj = OpenStruct[first: "Willard", last: "Wonka"] do
  def full = "#{first} #{last}"
end

This still doesn't look as uniform as JS object literals, and performance-wise I'm sure Ruby is not optimized for this sort of object. That's because it goes against the grain of Ruby, where classes play a central role, as distinct from instances of them. In JS, with its prototype-based object model, "classes" are syntactic sugar, and individual objects are more central than in Ruby. (On how and why this is so, it's helpful to read about JS's early history.)

But we shouldn't overstate the difference: the JS and Ruby object models are actually similar in how dynamic both of them are. This makes Ruby-to-JS compilers like Opal easier to implement, according to an Opal maintainer.

In the end, learning more JS has given me a deeper appreciation of both JS and Ruby: JS for the ingeniously simple idea behind its object model, and Ruby… for everything else 😄

Learning Linux: recommended resources

Felipe Vogel — Mon, 30 Jan 2023 14:53:12 +0000

Confession: until recently, I wasn't a fan of the command line.

"What?! A whole year into your developer career, and you don't live 24/7 in the terminal????!"

Nope. But a few months ago I discovered what the whole rest of the world already knows: tab completion! 🙈 And that made me wonder: what other command-line superpowers am I missing out on?

So I've embarked on a quest, a quest in which (fade in epic music) I will learn the the ways of the command line, to wield the ancient caret. But I will not stop there. Nay, for it is a quest to a far-off land, a land nearly as ancient as Unix Time itself: the land of Linux—er, GNU/Linux.

Digression: At one point in the long GNU/Linux naming controversy, the name "LiGNUx" was proposed. Good thing **that* didn't catch on!*

Linux learning resources

I've heard that the gold standard Linux education is to install it, mess around with it until it breaks, and then repeat.

But I like more structure in the beginning, so after Google-sleuthing for learning resources and crossing off some that I tried and didn't find useful, here the promising prospects still on the list. The items preceded by a dollar sign (💲) are not free.

This list is excerpted from my learning roadmap, so check there for the latest version of the list.

But reading books about Linux wouldn't do any good if I didn't get my hands dirty too!

Installing Linux on my old laptop

I chose Linux Mint over Ubuntu because I like Mint's more familiar UI, and the fact that it's community-supported makes me feel superior 😏

I didn't run into any major installation problems, and all my hardware works. Impressive! That certainly wasn't the case the last time I tried Linux, but that was 15 years ago when I was a wee wannabe hacker. (Now I'm an adult wannabe hacker.)

So yeah… not much to say here because it was so easy.

Goodbye to Windows?

I've already confessed that I use Windows on my personal computer, and I use my non-optional work MacBook in a way as Windows-like as possible.

But recently I listed in my mind the things I like about Windows: customizability, lots of free apps, and a real Linux command line in WSL which gives me fewer headaches than the MacOS terminal.

Then it hit me: all of these points are even more true in Linux. So why not switch to Linux?

I want to switch, but the only snag is that I love AutoHotkey, and a Linux port is still in progress. I use AutoHotkey to make my keyboard and (especially) my mouse more useful. I could probably do the same things by other means in Linux—everything is customizable in Linux, after all. And anyway I might use my mouse less and less as I become more capable with the terminal. Still, I'll wait a while in the hope that I'll be able to more or less plop my AutoHotkey script into the Linux version.

But it's only a matter of time before I switch. So I guess it's appropriate to end with a non-ending.

✨ TO BE CONTINUED (SOMEDAY)… ✨

Learning Git: my favorite resources

Felipe Vogel — Wed, 18 Jan 2023 15:40:08 +0000

When you're making a pull request, do you ever realize your Git branch has become a massive pile of disordered and unrelated changes, but then you don't do anything about it because you're afraid of making an even worse mess by fooling around with Git commands that you don't understand or even know how to undo?

Me? No, of course not…

Anyway, I've decided to improve my Git skills, and I thought I'd share my favorite learning resources that I found.

My favorite Git learning resources

These are excerpted from the new "Git" section of my "Learn Ruby" list. (Yeah I know, Git is not part of Ruby. It's just that I didn't want to create a separate list for general programming skills.) I keep the list up to date, so unless you're reading this in January 2023, you should check there in case I've found more Git resources.

I made the Git list by (1) scouring the Web for recommended resources, then (2) trying out each one to see if it would be worth going through to the end. In case you're curious about which resources didn't make the cut, here's the commit where they are removed.

(Just so you know, I'm proud of that commit. Originally I made separate commits to remove each unwanted resource, interspersed with other unrelated commits. But at the end I used my new Git skills to do an interactive rebase, squashing a bunch of commits into one and re-ordering the unrelated commits to an earlier point in the branch 😎)

Without further ado, here are my favorite Git learning resources so far. They're all free except for the last one.

Basics:
Intermediate/advanced:

Right now I'm working through Git Katas. After that, and before going through the intermediate/advanced Git resources, I might spend time on other fundamentals (see below).

Git-related VS Code extensions

Until recently I used the GitLens VS Code extension, but then I realized that its only features that I care about are either finnicky (popup-on-hover Git blame), needlessly complicated (browsing a file's history), or behind a paywall (graph visualizer).

So I replaced GitLens with these smaller extensions:

Git History Diff
Git Blame to quickly see the current line's blame in the status bar.
Git Graph for when your repo is complex enough that git log --oneline --graph is hard to decipher.

Reflections on the fundamentals

Besides the "Git" section, I've added three other sections under a "Fundamental tools" heading:

I'm really enjoying learning these fundamentals. I love Ruby, but it's nice to focus my learning on something else for a change—though I'm still watching Ruby screencasts whenever my wrists need a break.

In fact, I'm having so much fun that I'm tempted to expand the "Fundamental tools" section, but it's probably best to pick a few technologies and go deep into each, rather than throwing a bunch more stuff in there and making it less likely that I'll go deep into anything.

So, as a compromise, I have a separate "Expanding my horizons" section for those times in the future when I want to take a dive into something outside of Ruby or frontend skills.

As I write this, I'm reminded of a Thoughtbot blog post about "evergreen skills" (similar to what I've called "fundamental tools") which is worth a read.

I hope my explorations of Git and other fundamentals has been as rewarding for you as it has been for me. Happy learning!

Learning Ruby: a retrospective

Felipe Vogel — Fri, 06 Jan 2023 16:39:49 +0000

Table of Contents

But why Ruby?
My "Learning Ruby" roadmap
- In the beginning
- Time lapse
What next? Keeping it simple

Happy New Year! I hadn't planned on any New Year's resolutions, but then I came across Bring Back Blogging, a challenge to publish three posts in January. I just couldn't resist. So my resolution is to write more blog posts… at least this month 😂

Today I'll reflect on my past two years of learning Ruby. It seems appropriate, this being my first new year as a professional Ruby developer.

But why Ruby?

Why did I say I'm a Ruby developer just now? Why not a software or web developer? Am I one of those strange Ruby people?

Of course I'm a software developer and a web developer. I've learned lots besides Ruby, and this year I aim to become better-versed in web standards like web components and the latest CSS features.

But generally I have the most fun when I'm writing Ruby, and Ruby is where I've spent the most time. When I started learning programming in 2020, I spent the first few months on web basics but then I switched my focus to Ruby, and that's where I've happily been ever since.

My "Learning Ruby" roadmap

As a guide to my reflections today, I'll use my "Learning Ruby" roadmap, which originally arose out of the chaos of my bookmark hell, where I was having trouble keeping track of the actually important learning resources. The roadmap worked well for me and eventually I put it up on GitHub because making it public gives me more motivation to keep making progress.

But another benefit to its being on GitHub (besides the warm fuzzies I get when a random stranger stars it) is that now, almost two years later, I can look back at earlier versions and see how my learning goals evolved.

What did my roadmap look like in the first Git commit? Let's go back in time to May 2021…

In the beginning

The earliest tracked version of my roadmap was pretty simple. It had three sections of resources: frontend basics, Ruby, and computer science.

My roadmap today still starts with frontend basics and ends with computer science. It's the middle part that has exploded: instead of one Ruby section, I now have seven Ruby-related sections, in addition to four other new sections.

But back to my early roadmap, the emphasis is clear: I loved Ruby and I thought all the important stuff could fit under the Ruby heading, except for my "healthy dose of computer science" (as I put it) and a smattering of frontend knowledge, which got their own sections.

At the same time, I was conscious that Ruby was not the most popular choice for a beginner, and thus "Objections" was the first preliminary section of my roadmap, and the first objection was "Why Ruby??" I eventually scrapped the "Objections" section because it made my roadmap seem more objectionable than it actually is, but later that year I expanded my answer to "Why Ruby?" into a blog post, "Ruby for the self-taught developer".

Time lapse

A couple months passed. I finally gave in and split up the "Ruby" section as I geared up to learn Rails. Over the following year, the new "Rails" section would go on to expand to massive size and extent, containing even a "PostgreSQL" subsection 🙈

It was in mid- to late-2021 that I first sighted frontiers in Rubyland which even now I'm pushing myself to start exploring, such as reading open-source Rails codebases (the early version and the expanded list of today).

My studies slowed down a bit in 2022, for the happy reason that I'd gotten my first developer job and I was doing more of my growing away from my roadmap.

In July I took the momentous step of adding a "JavaScript" section. Its earliest entry, appropriately enough, is titled "You Don't Know JS" 😂

In September I finally split up the giant "Rails" section into standalone sections which are more sensible, if a bit overwhelming in the table of contents.

What next? Keeping it simple

As I looked through my commit history just now, I noticed a pattern: a section of my roadmap grows and grows until it fragments into a profusion of new sections, one or two of which grow again and repeat the process.

On the other hand, one of the stated purposes of my roadmap is to help beginners who too often feel lost amid a sea of tutorials without clear direction.

So I'll have to be disciplined this year to make sure my roadmap doesn't get out of hand:

Keep revising the "done" sections. I'll need to keep putting on my me-two-years-ago mindset and tightening up the "done" part of my roadmap, because beginners tend to prefer being handed one or two excellent resources over having to choose from all twenty options.
Keep making progress. The other scenario in which my roadmap gets shorter is when I actually put in the time to study, checking things off and deciding whether they're worth keeping on the roadmap (usually they're not).
Cut out the less important stuff. For example, my progress in the computer science section has stalled as I've realized that knowing how to implement data structures and algorithms from scratch makes no discernible difference in how I code. So should I get rid of the computer science section, or keep it there for later? I'll have to think about it.

Thanks for going on this reflective blast to the past with me 🚀

OOP vs. services for organizing business logic: is there a third way?

Felipe Vogel — Tue, 06 Dec 2022 16:17:15 +0000

Table of Contents

The good old days
Then along came Rails
Two philosophical camps?
Service object skepticism
Second-guessing myself; more study needed
- Deductive study: books, talks, and gems
- Inductive study: open-source Rails codebases
Conclusion: to be continued…

Disclaimer: In this blog post I raise many questions and give few answers. At the bottom I list resources which I'm exploring in search of an answer, so skip down if that's all you care about.

Business logic. Everyone has it, and no one seems to agree on where to put it in a Rails app. Some people stuff it all in Active Record models, others throw it out into service objects, and still others put it in POROs. (But then where do you put the POROs?)

In all these debates, there's probably an element of different answers coming from different needs: people who work with small apps don't stray far from The Rails Way of MVC (models, views, and controllers), whereas those who work with larger apps might feel the need for a more sophisticated architecture.

That being said, I sense that these disagreements also reflect a more fundamental question: How should the app interact with the database? Or in other words, should database tables be near the surface, or should we put in the effort to hide the data model that is reflected in database tables?

I may have lost you already, so before I wade too deep into philosophy, let tell the story of why I'm struggling with these questions.

The good old days

Before I learned Rails, I knew Ruby. I loved it. It made sense. Propelled by Sandi Metz's talks and books, I could write a plain Ruby app in the most beautiful and satisfying OOP style. Life was good.

But I knew I couldn't linger in those enchanted woods forever.

Then along came Rails

I learned Rails and got my first programming job working on a Rails app of over two hundred thousand lines of Ruby code, plus React views. Suddenly things didn't make so much sense anymore. I often didn't (and still don't) know where a piece of code belongs. Let's even set aside React views and the duplication of backend logic that I find hard to resist when writing a React view. Let's focus only on backend Ruby code: even there I find myself indecisive when trying to decide where to put a new piece of code.

The most convenient place for that new bit of code is an existing Active Record model, but when I'm crawling through a huge model I'm reminded that maybe I should think hard about where to put this code. So I turn to alternative places, but then I'm faced with a jungle of service objects and variously-located POROs 😵‍💫

I usually find a tolerable solution, but in the end I always wonder: where does business logic really belong? 🤔

Two philosophical camps?

As I looked through discussions of this question in the Ruby community, I noticed that most answers came from one of two "sides": advocates and opponents of service objects. In reality it's a bit more nuanced than that: advocates might propose a pattern that is a more sophisticated version of service objects, and many opponents admit that careful OOP design is important to augment Rails' MVC structure.

But the reason I lump them into two camps is that each has a different approach to the fundamental question I posed earlier: How should the app interact with the database? In the context of Rails, this question can be rephrased like this: What should an Active Record model represent?

Advocates of service objects often think of Active Record models as models of database tables, and therefore not an appropriate place to put business logic. The other camp sees Active Record models as models of domain objects that just happen to be backed by a database table, and therefore a perfectly suitable place for business logic.

Service object skepticism

For several months I thought the anti-service-object camp was right, end of discussion. It seemed clear to me that Active Record models are intended to be domain models:

1. It's spelled out in the Rails Guides.

From the section "What is Active Record?"(emphasis mine):

"Active Record is the M in MVC - the model - which is the layer of the system responsible for representing business data and logic. Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database."

And, shortly afterward:

"In Active Record, objects carry both persistent data and behavior which operates on that data."

2. Martin Fowler, who first described the Active Record pattern, agrees.

To quote his article on the Active Record pattern:

"An object carries both data and behavior. Much of this data is persistent and needs to be stored in a database. Active Record uses the most obvious approach, putting data access logic in the domain object."

So an Active Record object is intended to be fundamentally a domain object, with database access added for convenience, not the other way around. Probably that's why it seems against the grain of Rails when service objects are the place where business logic goes.

Fowler directly criticizes service objects in his article on anemic domain models. In reference to putting domain logic in services, he says:

"The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented design; which is to combine data and process together. The anemic domain model is really just a procedural style design."

And:

"In general, the more behavior you find in the services, the more likely you are to be robbing yourself of the benefits of a domain model. If all your logic is in services, you've robbed yourself blind."

3. Conversely, domain models don't have to be Active Record models; they can be PORO models.

Taking advantage of this can alleviate many of the "fat model" problems that service objects seek to solve.

Martin Fowler proposes refactoring a service object into a PORO, and he's not alone: some in the Ruby community have written the same (1, 2, 3).

There are lots of patterns that can be used in POROs around Active Record models. For example, if a record is created from complex form input, you could use a form object instead of a service object.

Also, some versions of service objects are somewhat object-oriented when they reject the notion that service objects should have only a #call method and when they share code within the same class. In these cases, a service object is a bit more like a purpose-built PORO.

So why not just take the next step and put these services in the app/models folder, and refactor them from procedures into actual domain models? To take an example from the last link above: SalesTeamNotifier.send_daily_notifications could be changed to Internal::Notification.new(receiver: 'sales').send.

So yeah, I was a convinced service object skeptic, firm in dismissing even the need for anything but classic OOP. When I tried to be fair and play devil's advocate, I only got as far as conceding that OOP is harder to get right than procedures, and OOP done wrong can result in a lot of moving parts and less clarity about what actually happens when. I could even appreciate the simplicity of services, in the sense that making one is as easy as copy-pasting a long model method.

Second-guessing myself; more study needed

Fast forward a few months. I still don't like service objects, and I still like OOP. But now I'm less certain that the cure-all for badly organized business logic is "just do more OOP, end of story."

After all, if so many people feel the need for service objects, and if OOP is evidently so hard to get right, aren't these signs that something is missing? Maybe that missing something is just better OOP, but in that case good OOP is hard to come by and we at least need a more accessible way to do it.

So I've set out to explore the problem of organizing business logic from more angles than before, using the resources listed below. These lists are excerpted from my "Learning Ruby" road map which I often update, so you may want to find these lists there if this post is old at the time of your reading it. The sections corresponding to the lists below are, at the time of writing, "Rails architecture" and "Rails codebases".

Deductive study: books, talks, and gems

Here are some resources that I hope will shed light on the question of organizing business logic better, both in terms of solutions and in terms of when (under what conditions) these alternative approaches are beneficial as opposed to simple OOP with Rails defaults. This list is not exhaustive; in particular I've omitted gems that are just a service object implementation. Some of these resources are closely related to service objects, but that's intentional–I'm compensating for my bias against them.

Domain-Driven Design, which aims to augment OOP to prevent problems such as fat models. It's intended for large, complex domains. Resources: "Getting modules right with Domain-driven Design" (talk), Learning Domain-Driven Design (book).
Other approaches that are more lightweight and have some of the same goals:
- Data Oriented Web Development with Ruby (upcoming book) by Peter Solnica, who is on the Hanami core team. Learning Hanami wouldn't be a bad idea either.
- Maintainable Rails (book), which uses gems that are part of the Hanami ecosystem.
- "Organizing business logic in Rails with contexts" (blog post).
- Learn more about the repository pattern: article, talk.
Relevant gems that seem worth learning from:
- dry-transaction
- Interactor
- Sequent – CQRS and event sourcing
- Rails Event Store – for an event-driven architecture
- Ventable – a variation of the Observer design pattern
- Wisper – the Publish-Subscribe design pattern
- Packwerk – to enforce boundaries and modularize Rails applications

Inductive study: open-source Rails codebases

I rarely read a lot of code outside of work, but I plan to change that. Below are Rails projects that I've seen mentioned more than once as good examples to learn from, or they are sufficiently active and well-known as to be good candidates for study.

Small codebases: Less than 50k lines of Ruby code.
- github.com/codetriage/codetriage (6k lines): Issue tracker for open-source projects.
- github.com/joemasilotti/railsdevs.com (12k lines): The reverse job board for Ruby on Rails developers.
- github.com/lobsters/lobsters (13k lines): Hacker News clone.
- github.com/thoughtbot/upcase (14k lines): Learning platform for developers.
- github.com/houndci/hound (14k lines): Automated code review for GitHub PRs.
- github.com/rubygems/rubygems.org (26k lines): Where Ruby gems are hosted.
Larger codebases: More than 50k lines of Ruby code.
- github.com/solidusio/solidus (72k lines): E-commerce platform.
- github.com/mastodon/mastodon (75k lines): Like Twitter but self-hosted and federated.
- github.com/forem/forem (103k lines): Powers the blogging site dev.to.
- github.com/alphagov/whitehall (117k lines): Publishes government content on gov.uk.
- github.com/discourse/discourse (322k lines): Discussion forum platform.
- github.com/instructure/canvas-lms (745k lines): A popular LMS (learning management system).
- gitlab.com/gitlab-org/gitlab (1.8 million lines): Like GitHub but with CI/CD and DevOps features built in. Has great docs on architecture.

Conclusion: to be continued…

In a year or two I may be able to give something more like an answer to the questions I've raised here. For now, I've made a start by processing my thoughts and mapping out some promising resources.

What about you? Have you had any moments of insight into how to organize business logic? Do you know of a great resource not mentioned here? I'd love to hear about it!

The first six months: lessons learned as a junior developer

Felipe Vogel — Wed, 24 Aug 2022 19:04:00 +0000

Table of Contents

Find balance
Keep up your learning journey
Don't be a silo: connect more, communicate better
Conclusion

I've reached a milestone: six months into my first developer job 🎉 Time for some reflection! What have I learned? If I were to give advice to myself six months ago, what wisdom would I impart? Here are a few highlights.

Find balance

Learning the ropes as a junior developer can be exhausting, especially if you have a competitive "gotta get tons done" personality like I do. Impressing your peers and exceeding your manager's expectations feels so good that it's hard to slow down.

But the cost is real, as I've been painfully reminded. A couple times already I've gotten into a cycle of overwork ⇨ burnout ⇨ lethargic exhaustion ⇨ panic ⇨ repeat. More recently, here are some ways I've found to stay out of that unpleasant cycle:

Give pessimistic time estimates. When your manager asks how much time you'll need to finish a project, resist the fear of giving an embarrassingly long estimate, because what you think is a long time probably isn't. Expect unexpected delays. After I was burned by a short deadline of my own making, a more senior colleague suggested that I add in a 1.5–2x "contingency factor" to my estimates.
Put rest into your work rhythm. Despite my best attempts, I've found it impossible to work at a completely steady pace. (Even break timers don't work for me, because I tend to cancel the pauses or close the app entirely if I'm "in the zone" and don't want to be interrupted.) I've accepted that there will always be crunch times when I need to do a lot of focused work, and there will always be slower times when not as much needs to be done right now. Rather than stressing about how to flatten that up-and-down, I've found it more helpful to take advantage of the slow times, using them as a chance to rest. Don't immediately pile on more work when you've just stretched yourself to finish something. Attune yourself to the ebb and flow, and look for chances to step away from the computer, quiet your inner restlessness, and rest.
Maintain healthy habits. On the other hand, it's good to keep up a healthy routine even in the busiest times. Find a few things that help you relax and stay happy, and don't beat yourself up if you don't get around to doing all of them every day. For me these things include:
- Reading. I love reading because a good book gives me energy and relaxation at the same time, even while expanding my horizons. Try to find a hobby that does that for you.
- Latin. A more social hobby for me is spoken Latin. (Yes, that's a thing.) Whatever it is for you, regularly doing something fun in a group can provide a refreshing change of pace from your usual day-to-day.
- Mindfulness. The Balance app is great, and free for the first year. I rarely enjoy mindfulness, but it helps me avoid bad thought patterns and appreciate the little things in life.
- Building up relationships. For me this means spending more quality time with my wife—not just watching more Netflix, but trying new things together (this summer it was camping), and making an effort to listen more and be a better companion. I've also been reconnecting with old friends. It takes effort to do all this, but there's no replacement for the love of family and friends.
- Going on walks. The exercise makes me feel good, and it's another chance to talk with my wife, or if I'm alone, to listen to audiobooks and podcasts 🤓 But it's also nice to take off the headphones once in a while and just look at the trees.
- Lying in bed daydreaming. I'm not kidding! Even a short 10-minute burst can be very refreshing. To get there you might have to retrain your imagination, but it's worth the effort.

Keep up your learning journey

For two years before I got this job, I learned programming on the side while working a "pay the bills" type of job. It was a huge relief to put that stage behind me, but a few months into my new job I found myself missing the freedom and adventure that I felt when I was learning programming.

Thankfully it was an easy fix, because I was the one holding myself back. Juniors at my company are encouraged to take time to deepen their skills, apart from product work; I just wasn't taking the time. Part of the problem was that I simply needed to slow down (see above). As soon as I did that, it became easier to spend an hour here and there on learning and deepening my skills.

I've found a few other practices useful in maintaining a learning habit:

Set goals. Identify one or two areas where you want to improve, and focus on those. For me it helps that I already have lots to choose from in my "Learning Ruby" list, which I've been building up for the past two years.
Keep an open mind. Even as a junior it's easy to think that you know better than most other developers, or to turn your nose up at X or Y bandwagon that your company's developers have jumped onto. But if you resist that close-mindedness and try to see the good side of even the technologies and techniques that you don't like, then you'll learn a lot more. That happened with me a few months ago, when I spent time learning more RSpec, and it finally clicked in my mind and I started to appreciate its strong points.
Find mentors. If you're not getting much one-on-one guidance at work, I suggest (a) asking persistently until you at least have someone who can check in with your learning on a regular basis, and (b) looking for mentors outside of your company, such as at First Ruby Friend. The Rails subreddit is another good place to find a mentor, and I've found the StimulusReflex Discord server to be a welcoming place for my questions—and I haven't even learned StimulusReflex yet, but they have very active channels for Ruby, Rails, and lots more.

Don't be a silo: connect more, communicate better

Working remotely (as much as I love it) can make it harder to connect with others unless you're very intentional. I mean this both in the sense of getting to know my colleagues, and also in the sense of hashing out important information.

An example of the latter is communicating with all stakeholders and making sure we're all on the same page. I've found myself in situations where different people want different things from a new feature that I'm working on. The first time this happened, it was fine because I just added extra features that weren't in the original spec, and everyone loved it. A few weeks later, as I worked on a different new feature, I again made adjustments mid-course based on feedback from a stakeholder, but this time it didn't turn out so well. The adjustments I made departed from the original spec in ways that I realized were unacceptable only after a barrage of questions and complaints from other stakeholders. I then had to rush to redo some of my work on my last two days before going on vacation. Moral of the story: don't be the monkey in the middle! 🙈 Get everyone together in the same room (Zoom call) if necessary.

As for getting to know my colleagues, I did great at the beginning when I scheduled an introductory Zoom call with each and every person in the product and engineering departments. However, it wasn't long before I lost touch with even the handful of juniors that started at the same time that I did, and only now am I reconnecting with them. My hope is that we can get back to telling each other about our struggles and successes, as well as sharing new things that we're learning.

Conclusion

I have a few other regrets about the past six months, but they all go back to these three lessons I've learned: find balance, keep learning, and don't be a silo.

More fundamentally, I'm trying to shift my focus away from regrets and mistakes, and instead appreciate all that I've learned. These lessons are already helping me be happier and more fulfilled, and that makes me even more excited for all that I'll learn in the next six months.

RVTWS: a Ruby stack for modern web apps

Felipe Vogel — Fri, 24 Jun 2022 18:57:00 +0000

Table of Contents

Rails or Roda
ViewComponent
Turbo
Web components
StimulusReflex
Conclusion

When I started my career switch into software development two years ago, I decided to focus my efforts on Ruby. I did this for a few reasons, but one of them is that Rails offers great "bang for the buck": there's a lot that I can build with just Rails, HTML, and CSS.

However, this minimal vanilla stack becomes limiting when two factors come into play:

The MVC architecture of Rails won't always be enough to keep your code organized. You'll notice it painfully if your app ever grows beyond a small project.
For your app to feel modern, the frontend will need to act like an SPA (Single-Page Application). The "official" way to do this is now Hotwire, but there are other tools worth keeping in the toolbelt. More on that below.

Making a new acronym for your favorite tech stack is a popular thing these days, so I'll coin a new acronym: RVTWS… pronounced "erv toes"? Yes, this is great. It will go viral in no time.

Joking aside, I'm using this acronym here only as an outline for this blog post, rather than for any marketing value. The "V" (ViewComponent) addresses point #1 above, and "TWS" are concerned with #2.

Rails or Roda
ViewComponent: for frontend architecture
Turbo: for an SPA feel, using the server
Web Components: for an SPA feel, using the client
StimulusReflex: for more complex frontend magic

Rails or Roda

There's not much to say about Rails: it's boring tech, and therefore a good choice for most web apps.

Roda is also worth considering. Unlike the batteries-included philosophy of Rails, Roda is bare-bones by default but highly extensible. This makes Roda apps fast and more architecturally flexible. Besides the docs, here are some places to get started with Roda:

An interview with its creator Jeremy Evans.
Roda + Sequel app skeleton, which has a similar purpose to the rails new command.
A post on Bridgetown's ongoing Roda integration, which is making Roda more accessible thanks to Bridgetown's batteries-included approach.

ViewComponent

Partials are the standard Rails way to define distinct parts of a view. Partials provide a way to separate out part of a template, but they don't provide a way to separate out view-related logic, which often ends up being thrown into models and/or controllers. This is one reason why models and controllers in Rails can so easily become huge and messy.

ViewComponent provides a home for this view-related logic. This post on the Code with Jason blog explains it best. In short, ViewComponent fills a big gap in MVC architecture.

Some readers may be wondering, "Is that all? What about other architectural improvements, like service objects?" It's true that certain types of apps have problems best solved with certain design patterns, and maybe a very large app needs a specialized architecture. But in general, Rails models designed in a careful, object-oriented way can take you very far, and I think the popularity of service objects is unjustified because they can easily muddle up a codebase. Food for thought:

Why Service Objects are an Anti-Pattern at Fullstack Ruby
How I Organize My Rails Apps at Code with Jason

Turbo

On to the frontend! Turbo is part of Hotwire, which now ships with Rails. Turbo makes it really easy to give server-rendered pages a snappy SPA feel, where parts of the page are updated instantly instead of a full page reload.

At the heart of Turbo is "HTML over the wire" (for which HOTWire is an acronym), which means the server sending HTML fragments for partial page updates, which (here's the big win) eliminates the need for client-side state management. There are lots of tools taking this approach now.

Unpoly and HTMX are two of the most intriguing alternatives to Turbo because they are more framework-agnostic and have a flexible, concise syntax. Turbo, on the other hand, seems easier to get started with if you're in Rubyland.

Sidenote: If you're wondering why all these "HTML over the wire" tools came about and what they're pushing back against, take a look at these two comparisons of web app architecture from 2005 vs. ten years later: one from Unpoly (2005) vs. 2015), and another from the developer of Turbo's predecessor Turbolinks (2005 vs. 2016).

Besides Turbo, the other part of Hotwire is Stimulus, which typically is used for adding client-side reactivity in situations where you want to sprinkle in some JS. After all, you wouldn't want every user interaction to involve a round trip to the server. So why am I including only Turbo here and not Stimulus?

Web components

Actually, Stimulus is pretty cool because you can compose multiple pre-built behaviors into one Stimulus controller, for a sort of functional approach to component behaviors. The tradeoff is that a growing web of Stimulus controllers (plus HTML data attributes associated with them) can become complex and hard to understand.

Web components are an architecturally simpler way to add client-side behaviors, and they also have the advantage that they're a web standard. This blog post on Fullstack Ruby shows the power of web components in the context of Ruby.

Also, as illustrated in that post, you can use Ruby2JS to write web components in Ruby. (You can likewise write Stimulus controllers in Ruby.) In other words, you get the best of both worlds: the power of JavaScript on the frontend, and all the conveniences of Ruby syntax 🤩

StimulusReflex

Turbo + web components can take you a long way in making your Rails app feel modern, but there are other tools in this space that can complement them. I've already mentioned Stimulus, but there's also StimulusReflex which is like Stimulus but on the server, and CableReady which is somewhat like Turbo Streams but more flexible. Be sure to give these a try if your app is highly interactive, or if you just want to expand your horizons beyond Hotwire.

Also, the StimulusReflex Discord server is an amazing place even for discussing all the other tech mentioned in this post. (Which is very ironic. Ever since Hotwire's release, it has marketed itself as THE solution, not even mentioning the similar tools had already been coming out of the StimulusReflex community for two years. Even so, it's in this very community that you can find the best Hotwire support.)

Conclusion

I've been thinking about this ideal Ruby stack because for the first time I'm working on a Rails app that has a React frontend, and it's been a painful adjustment. Sometimes it feels like I'm writing logic twice, once on the backend and again on the frontend. And what do I get for it? Smoother page transitions and buttons that do things without refreshing the page. That's nice, but do these simple enhancements have to involve so much extra work?

On the other extreme, the "vanilla Rails" approach to writing views is clunky and outdated, and Hotwire doesn't fix all the omissions. It's no wonder that people go looking for outside frontend solutions such as React.

So I started dreaming about what frontend tools could give a smooth user experience without so much extra complexity, and this "RVTWS" stack is the result. (Yeah, I need to work on that acronym.)

On a final note, if you'd like to learn more about Hotwire and StimulusReflex, check out the resources that I've compiled for both of them in my "Learning Ruby" list.

Dot syntax and dig! for Ruby hashes, benchmarked

Felipe Vogel — Mon, 09 May 2022 14:39:14 +0000

Table of Contents

Baselines
Dot syntax
Dig with errors
Moral of the story
Appendix A: regular dig on a hash with error-raising defaults
Appendix B: the benchmark code

Recently I heard about this convenient feature of Elixir maps:

To access atom keys, one may also use the map.key notation. Note that map.key will raise a KeyError if the map doesn't contain the key :key, compared to map[:key], that would return nil.

Nice! This is something I've been wishing for in Ruby. In a current project I have a configuration hash that is passed around and used in a variety of objects. The hash is quite large and several levels deep, so my code abounds with chains of Hash#fetch such as config.fetch(:item).fetch(:template).fetch(:variants). Which, as you can imagine, makes some lines very long and not particularly readable 😒

Two notes on why I've been doing it this way:

The reason I use fetch instead of config[:item][:template][:variants] or config.dig(:item, :template, :variants) is that the KeyError raised by fetch, in case of a missing key, is more helpful than the default nil value from brackets or dig. In fact, that nil could cause a major debugging headache if it results in an error somewhere else far from where the nil originated.
If you're wondering why I'm using a raw hash instead of a custom Config class with syntactic sugar such as config[:item, :template, :variants]: that could be a great idea in some projects! But in this project, some objects use only a part of the config and I don't want to pass the entire config into those objects. Also, some objects perform hash operations using parts of the config. So if I'm creating separate Config objects just to wrap inner hashes from the main Config, and if I'm converting these Config objects into a hash at various points, then it seems I should simply use a hash to begin with. In this project it's simpler to deal with hashes all the time, so that I don't have to ask myself, "Let's see, is this a Config object here, or has it turned into a hash?"

So, if we stick with a raw hash, can we hack our way to a more concise alternative to those repeated fetches, but with the same safety net of a KeyError? Of course! This is Ruby, after all, where anything is possible. But whether it's advisable… that's the real question. In this post, we'll look at two possible syntaxes along with their performance and usability implications:

Dot syntax: config.item.template.variants
Dig with errors: config.dig!(:item, :template, :variants)

Originally I set out to find a performant approach to dot syntax, but by the end I had changed my mind, for reasons that I'll explain.

Baselines

First, here are benchmarks on standard syntax (mostly). For the benchmark code, see the end of this post.

Bracket notation: hash[:a][:b]
Dig: hash.dig(:a, :b)
Chained fetch: hash.fetch(:a).fetch(:b)
A shorter fetch alias: hash > :a > :b. Because why not.

                           user     system      total        real
1. brackets           :  0.003332   0.000000   0.003332 (  0.003332)
2. dig                :  0.002877   0.000823   0.003700 (  0.003704)
3. fetch              :  0.005040   0.000000   0.005040 (  0.005044)
4. fetch alias        :  0.005012   0.000000   0.005012 (  0.005012)

Notes:

These are all very performant. But remember, brackets and dig return nil where I want a KeyError, and chained fetch is what I'm trying to get away from.
In some runs, dig (#2) was faster than brackets (#1), but more often brackets win by a hair.
Chained fetch (#3) is consistently slower than brackets here in the benchmarks, but my project's test suite does not run any faster when I replace all calls to fetch with brackets. It's a good reminder that benchmarks don't always reflect real-life performance.
Even though the fetch alias (#4) is just as fast as fetch itself in the benchmarks, my project's test suite took 20% longer to run when I replaced all calls to fetch with an alias. 20% slower is not much, especially since all of my tests run in well under one second. But there's also the fact that while config > … > … looks really cool, it is a bit cryptic (likely to confuse my future forgetful self), and I have to surround it with parentheses every time I want to call a method on the return value. Still, I was curious about the performance hit and that's why I included the fetch alias here.

Dot syntax

Here are a few approaches to dot notation for hashes or hash-like structures, benchmarked. Keep in mind that I measured only access (reading) performance, not initialization or writing.

Faux dot notation by flattening a hash and giving it composite keys, as in config[:"item.template.variants"]. I copied this approach from here, with the main difference that I use symbols as keys because they're more performant than strings. Note that :"string" is similar to "string".to_sym but faster because a string is not created every time. Also, this approach uses brackets, but only because that hash's bracket accessor (Hash#[]) is overridden to use fetch.
An OpenStruct, which is sometimes suggested in these sorts of conversations.
Augmenting a single hash with methods corresponding to its keys.
ActiveSupport::OrderedOptions.
hash_dot gem. Also, my benchmark code is based on the benchmarks in hash_dot's README.
Hashie gem.

                           user     system      total        real
1. flat composite keys:  0.003461   0.000000   0.003461 (  0.003461)
2. OpenStruct         :  0.009731   0.000000   0.009731 (  0.009772)
3. per-hash dot access:  0.015300   0.000000   0.015300 (  0.015304)
4. AS::OrderedOptions :  0.070637   0.000000   0.070637 (  0.070640)
5. hash_dot           :  0.163008   0.000000   0.163008 (  0.163076)
6. hashie             :  0.163450   0.000000   0.163450 (  0.163451)

Notes:

Some approaches to dot notation involve more annoying setup than others, and/or significant limitations. For example, the flattened hash with composite keys (#1) is super fast, but it's far from the vanilla nested hash that I began with. This makes certain hash operations more complicated, such as iterating over hash keys. For my purposes it's not worth the headache.
The OpenStruct is faster than I thought it would be. But its fatal flaws, for my purposes, are that it's not a hash and therefore lacks a lot of functionality, and also it doesn't raise an error for a nonexistent attribute (like the KeyError from fetch) but instead returns nil.
Per-hash dot access (#3) is the fastest true dot notation for a hash. (Note that it only works for a hash that doesn't get any new keys once it's set up, which is just fine for my config hash.) However, when applied in my project, it still made my tests run for 70% longer. Again, that's not as bad as it sounds for my sub-1-second test suite.
But then something unexpected happened as soon as I replaced my project's calls to fetch with dot notation. My code looked more messy even though it was now more concise. The reason, I think, is that there was no longer a slew of (syntax-highlighted) symbols at the points where I access the config hash, and so it was a bit harder to see at a glance where config values were being used. Instead of brightly-colored symbols evenly spaced by fetch, my eyes now saw only a mush of method calls until my brain processed the words and told me whether that's a place where the config hash is accessed. Hmm. Now I was wondering if there was a way to keep the symbols involved, but in a more concise way than chaining fetch 🤔

Dig with errors

Hash#dig looks nice: hash.dig(:item, :template, :variants). But again, the problem is that it defaults to nil for nonexistent keys. What if we could make a similar method that raises a KeyError instead?

This has actually been proposed as an addition to Ruby several times (1, 2, 3) with various names including dig!, deep_fetch, and dig_fetch. But the method seems unlikely to be added in the near future. So… let's do it ourselves!

Here are a few different implementations, with benchmarks. There are also a couple of gems for it, dig_bang and deep_fetch, but I didn't include them here because dig_bang uses reduce (#4 below) and deep_fetch uses recursion, which performs the same.

Regular dig on a hash that has had its defaults set such that it raises an error for nonexistent keys.
Hash#case_dig!, which raises a KeyError for nonexistent keys. It's called case_dig! because it's implemented with a simple case statement.
Hash#while_dig!, similar but implemented with a while loop.
Hash#reduce_dig!. This is the "most Ruby" implementation.

                           user     system      total        real
1. dig, error defaults:  0.003750   0.000000   0.003750 (  0.003750)
2. case_dig!          :  0.007850   0.000000   0.007850 (  0.007856)
3. while_dig!         :  0.014849   0.000000   0.014849 (  0.014852)
4. reduce_dig!        :  0.027889   0.000056   0.027945 (  0.027950)

Notes:

The most vanilla approach is to use regular dig on a hash that's been given KeyError-raising defaults. This is a bad idea in a way that's hard to explain in a bullet point. See Appendix A if you want to know.
reduce_dig! (#4) is the most idiomatic and flexible implementation, so it's probably what you should use.
while_dig! (#3) is for you if you want to ~~sell your soul~~ trade idiomatic Ruby for a bit of extra speed.
case_dig! (#2) throws aesthetics and flexibility completely out the window because it's implemented with a case statement, and it can only dig as deep as the case statement is tall. But in my project I don't foresee ever needing to dig more than four levels into a hash, so for me it's perfect 🌟 Best of all, my tests don't run any slower now than they used to. But please don't copy me. That case statement is truly ugly.

Moral of the story

In the middle of all this, I seriously considered giving up and just going back to fetch, because it's the most performant and any other syntax risks making my code more cryptic to my future self. When I see config.fetch(:item) I know I'm dealing with a hash, unlike when I see config.item. I'm sure even config.dig!(:item, :template) will give my future self pause. For me this cost is outweighed by the better readability that I get in return, but it's surprising that this (and not performance) is what made the decision a difficult one.

Which leads into the other surprising takeaway: in this case it wasn't hard to custom-build a very performant solution for my project. So maybe I should try a DIY mindset more often, rather than immediately reaching for a gem (or ten).

In the end, maybe the real cost of my solution was in the absurd amount of time that I spent on all this benchmarking, hairsplitting, yak shaving, and bikeshedding. Enough! But I hope you've enjoyed my little adventure as much as I'm enjoying seeing it finished.

Appendix A: regular `dig` on a hash with error-raising defaults

So why is this a bad idea? It comes with no performance penalty because it's just regular dig on a regular hash. What could go wrong?

The problem is that I have to modify my config hash in the beginning to give it defaults that raise a KeyError. Recall that I also had to modify the hash when I tried per-hash dot access (#3 in the benchmarks on dot syntax above). But this time I'm less comfortable with the modification, because this one can "slip out" in less noticeable ways.

For example, if at some point in my code the config hash is operated on in a way that creates a derived hash (e.g. by calling map on it and using the result), that derived hash would be a fresh new hash without the KeyError defaults.

That new hash might get passed around, with me thinking it's the original that has the special defaults. I might use dig on the hash, and dig would work as in any hash (without my trusty KeyError) without me ever knowing that anything was missing 💀

So this approach is too fragile for my liking. Plus, my future self might wonder "Why did I use dig and not fetch?" until future self re-discovers my hack.

Appendix B: the benchmark code

require 'benchmark'
require 'ostruct'
require 'active_support/ordered_options'
require 'hash_dot'
require 'hashie'
require 'active_support/core_ext/object/blank'

#### SETUP

## FOR BASELINE BENCHMARKS

# regular hash
vanilla = { address: { category: { desc: "Urban" } } }

# fetch alias
class Hash
  alias_method :>, :fetch
end

## FOR DOT BENCHMARKS

# a flattened hash with composite keys
# from https://snippets.aktagon.com/snippets/738-dot-notation-for-ruby-configuration-hash
def to_namespace_hash(object, prefix = nil)
  if object.is_a? Hash
    object.map do |key, value|
      if prefix
        to_namespace_hash value, "#{prefix}.#{key}".to_sym
      else
        to_namespace_hash value, "#{key}".to_sym
      end
    end.reduce(&:merge)
  else
    { prefix => object }
  end
end

flat = { address: { category: { desc: "Urban" } } }
flat = to_namespace_hash(flat)

def flat.[](key)
  fetch(key)
rescue KeyError => e
  possible_keys = keys.map { |x| x if x.match /.*?#{key}.*?/i }.delete_if(&:blank?).join("\n")
  raise KeyError, "Key '#{key}' not found. Did you mean one of:\n#{possible_keys}"
end

flat.freeze

# OpenStruct
ostruct = OpenStruct.new(
  address: OpenStruct.new(
    category: OpenStruct.new(
      desc: "Urban"
    )
  )
)

# per-hash dot access
def allow_dot_access(vanilla_hash)
  vanilla_hash.each do |key, value|
    vanilla_hash.define_singleton_method(key) { fetch(key) }
    if value.is_a?(Hash) then allow_dot_access(value); end
  end
end

# ActiveSupport::OrderedOptions
asoo = ActiveSupport::OrderedOptions.new
asoo.address = ActiveSupport::OrderedOptions.new
asoo.address.category = ActiveSupport::OrderedOptions.new
asoo.address.category.desc = "Urban"

# hash_dot gem
hash_dot = vanilla.to_dot

my_dot = allow_dot_access({ address: { category: { desc: "Urban" } } }).freeze

## FOR DIG! BENCHMARKS

# with error defaults
def add_key_error_defaults(vanilla_hash)
  vanilla_hash.default_proc = -> (_hash, key) { raise KeyError, "key not found: :#{key}" }
  vanilla_hash.values.each do |value|
    if value.is_a? Hash
      add_key_error_defaults(value)
    end
  end
  vanilla_hash
end

errorful = add_key_error_defaults({ address: { category: { desc: "Urban" } } })

# dig! implementations
class Hash
  # ewwwwwwwwwwwww
  def case_dig!(key1, key2 = nil, key3 = nil, key4 = nil)
    if key4
      fetch(key1).fetch(key2).fetch(key3).fetch(key4)
    elsif key3
      fetch(key1).fetch(key2).fetch(key3)
    elsif key2
      fetch(key1).fetch(key2)
    else
      fetch(key1)
    end
  end

  def while_dig!(*keys)
    hash = self
    while key = keys.shift
      hash = hash.fetch(key)
    end
    hash
  end

  def reduce_dig!(*keys)
    keys.reduce(self) { |memo, key| memo.fetch(key) }
  end
end

#### BENCHMARKS

iterations = 50000

Benchmark.bm(8) do |bm|
  puts "BASELINES:"

  bm.report("1. brackets           :") do
    iterations.times do
      vanilla[:address][:category][:desc]
    end
  end

  bm.report("2. dig                :") do
    iterations.times do
      vanilla[:address][:category][:desc]
    end
  end

  bm.report("3. fetch              :") do
    iterations.times do
      vanilla.fetch(:address).fetch(:category).fetch(:desc)
    end
  end

  bm.report("4. fetch alias        :") do
    iterations.times do
      vanilla > :address > :category > :desc
    end
  end

  puts "DOT:"

  bm.report("1. flat composite keys:") do
    iterations.times do
      flat["address.category.desc".to_sym]
    end
  end

  bm.report("2. OpenStruct         :") do
    iterations.times do
      ostruct.address.category.desc
    end
  end

  bm.report("3. per-hash dot access:") do
    iterations.times do
      my_dot.address.category.desc
    end
  end

  bm.report("4. AS::OrderedOptions :") do
    iterations.times do
      asoo.address.category.desc
    end
  end

  bm.report("5. hash_dot           :") do
    iterations.times do
      hash_dot.address.category.desc
    end
  end

  class Hash
    include Hashie::Extensions::MethodAccess
  end

  bm.report("6. hashie             :") do
    iterations.times do
      vanilla.address.category.desc
    end
  end

  puts "DIG!:"

  bm.report("1. dig, error defaults:") do
    iterations.times do
      errorful.dig(:address, :category, :desc)
    end
  end

  bm.report("2. case_dig!          :") do
    iterations.times do
      vanilla.case_dig!(:address, :category, :desc)
    end
  end

  bm.report("3. while_dig!         :") do
    iterations.times do
      vanilla.while_dig!(:address, :category, :desc)
    end
  end

  bm.report("4. reduce_dig!        :") do
    iterations.times do
      vanilla.reduce_dig!(:address, :category, :desc)
    end
  end
end

How to find your first Rails job

Felipe Vogel — Tue, 01 Feb 2022 14:18:53 +0000

I've just landed my first developer job, a U.S.-based (but remote) junior position in fullstack Ruby on Rails 🎉 Here are some reflections on the job hunt, along with tips on finding your first Rails job.

Table of Contents

Why Ruby?
Where to look for Rails job postings
My job search: a bird's-eye view
Resume strategies
What to ask in the initial interview
Technical exercises
Conclusion
Appendix: Why a junior role?

Why Ruby?

There's a good chance that you pity me for going through the harrowing experience of looking for a junior Rails job. Why did I choose Ruby? Why not a JS stack where junior roles are more common?

For me Ruby was worth the risk of a longer job search because (a) I enjoy it a lot and (b) Rails is great for building up a portfolio quickly. If you're still skeptical, here's my post expanding on these two points.

Fortunately, my job search ended up taking only two months. But before that I spent a year and a half studying and practicing part-time, while working full-time in customer support to pay the bills. For details and recommended learning resources, see my ongoing study guide.

I also looked for a junior role specifically. If you're wondering why, see Appendix: Why a junior role? below.

Where to look for Rails job postings

I found most of my job leads in the Ruby on Rails Link community on Slack, and on Rails Devs. I also found a few on Twitter and on the StimulusReflex community on Discord.

What about LinkedIn? Yes, be sure to have a LinkedIn profile, if only for recruiters to be able to contact you. But I found only a few junior roles on LinkedIn, and none that I applied for. Some other sites that might be worth checking just in case: Indeed, AngelList, Hired, RailsGigs, and the GoRails job board. If you live outside the U.S., be sure to look in local job boards if there are any in your area. (If you're not sure, try asking in Ruby on Rails Link.)

My job search: a bird's-eye view

Over two months, I applied to seven companies. Most were startups, and only one of them (thoughtbot) is widely known in the Ruby community. I got an interview at six out of the seven companies. In five of them I moved past the first interview.

(In the one where I didn't move past the first interview, it was because I asked about the salary range and it was too low—or rather, the interviewer did the classic "Well, what do YOU want to be paid?" and my answer was evidently far beyond what they thought reasonable.)

Speaking of salaries, there's a huge range in what people think a junior's salary should be. Among the full-time U.S. junior job postings I came across, not counting internships, the range in advertised salaries was $40k/year to $120k/year.

The application process varied widely between the companies, from the simplest with just two interviews to the most complex with five interviews plus a take-home project. All of them had some sort of technical exercise, whether as part of an interview or as a take-home project.

I'll describe the technical exercises in more detail, but first let's back up to the resume and the initial interview.

Resume strategies

To get an initial interview, having an impressive resume is key. To give you some ideas on how to polish your resume, here are things that interviewers said they liked about my resume. By the way, it's always worth asking in an interview, "What did you like about my resume? And how could it be better?"

Lots of projects. In one of my early interviews, I got a helpful answer to the "how could it be better" question: "More projects." So I built a series of small apps over the following weeks. These helped fill out my resume, and they were a great learning experience. I've also heard good arguments (though not from interviewers) on the other side: instead of building lots of small projects, buckle down and build one big and impressive project. That's actually the path I started on when I first learned Rails, and I do plan on returning to my "serious" hobby app, but in these early stages of my Rails journey I learned more when I was building lots of small projects.
Write a blog. One interviewer found me through a podcast episode where I was featured. I was invited to the podcast because of a blog post that I wrote (reposted on DEVso that more people would see it). Moral of the story: write a blog! But even if your blog doesn't lead to any special opportunities, it's still worthwhile. Not only will your communication skills get a boost, but you can even learn something more thoroughly just by writing about it.
Keep a study guide. I got compliments on my study guide in two interviews, but it's another one of those things that's useful to do even if no one notices.

Here are efforts that I didn't get comments on, but I'm sure they didn't hurt:

Polish your GitHub portfolio. Here's mine: github.com/fpsvogel. Make sure each of your pinned projects has a nice README including a summary of why it's on portfolio. If you want to spend even more time perfecting your READMEs, here's an awesome README list to give you ideas, and here are a few that are built specifically as part of a learner's portfolio of Rails apps: lortza/tarot, lortza/sorrygirl, lortza/therapy_tracker.
Make a web version of your resume. Here's mine: fpsvogel.com/about. This is in addition to (not instead of) the PDF version that I submitted in applications. Here's my resume in PDF as of January 2022. I made it with LaTeX, but a plain old word processor would work too. Remember, keep it under one page!

What to ask in the initial interview

Once your resume is polished up, you're more likely to be invited to an interview. We tend to think most about giving good answers in an interview, but asking good questions is just as important—after all, you are interviewing the company as much as they are interviewing you. Your goal, besides making a good impression, is to find out whether that company would be a good fit for you. Here are the questions I asked in my initial interviews, along with my motivation for asking some of them.

"What extra onboarding and support would I have in the junior role?"
- This helped me gauge whether it's truly a junior role where I'd get better learning opportunities, or just a regular role with lower pay and lower expectations.
"What kind of code reviews do you all do?"
- Even outside the junior role, developers should be helping each other learn, and code reviews are one way that's done.
"How is your testing suite these days? What is your test coverage?"
- I wanted to be sure to work at a company that follows best practices, especially automated testing.
"How often do your developers have to work odd hours or take care of unexpected issues?"
- Some companies require their developers to be on call during off hours. And in some companies, developers frequently have to put out fires in production. I wanted to avoid these as much as possible.
"What is the salary range for the position?" (if a salary range was not advertised)
- If they straightforwardly tell you the salary range, it's a good idea to double check it in a follow-up email, just so you have it in writing.
- If they don't give a salary range and instead ask what salary you're looking for, that's a mark against the company in my book, because it makes me feel that they were too lazy to research salaries and they want to pay me as little as they can get away with. Try to resist the pressure to give a low number, and instead name the optimistic/best-case salary that you're aiming for, and add on "but I'm willing to negotiate."
"Is this a W-2 or contract position?" (if it's not clear already)
"What kind of health insurance do you offer?"
- I live in the U.S., with its *ahem* unique approach to healthcare, so I wanted to make sure that I'd get good health insurance through work.
If you're not sure what the company's product does: "I looked through your website and I see that you all do X, but I'm still not clear on Y. Could you fill me in on the details?"
If you're not sure why the company exists, or what gap they're filling: "I'm curious to hear how your company started. Could you give me a quick rundown of that?"
If the interviewer is a developer (though this is more likely to be the case in a second or third interview): "Where did you work before this company, and why did you move? How has this company been better, and what are some areas where the company could improve?"

There are lots of other questions you could ask in the initial interview. Just be sure to ask about anything that will give you a better feel for whether the company will be a good fit.

Technical exercises

Of the five technical exercises that I did, three were take-home, and two were live coding exercises, where an interviewer watched as I wrote code and as I explained what I was doing and why. For the take-home exercises, I explained my thinking in a follow-up interview after I'd finished an exercise.

Side note: If I could have a do-over of my job search, I would be more persistent about finding out the salary before doing a technical exercise, so as not to do so many of them. Remember what I said earlier about asking for the salary range in the first interview? I was a bit lax on that until the last weeks of my job search. At least now you get to learn more about technical exercises…

Here are the five technical exercises that I did, one for each company.

A take-home exercise where I built a Rails app that provides a user-friendly search interface to an API, and shows the search results. No time limit was given.
A take-home exercise where I built a Rails API based on a JSON dataset. I was asked to spend one hour on it. Bonus points were given if I wrote automated tests.
A timed (two-hour) HackerRank take-home exercise where I wrote a Ruby script that gets data from an API, processes it, and outputs the results to a file according to specifications given in the instructions. Automated tests were also provided, so that my goal was to make the tests pass.
A one-hour live coding exercise where I got partway through solving the Gilded Rose Kata in Ruby. In this version of the kata, automated tests were provided for me in order to save time. Again, my goal was to make the tests pass.
A half-hour live coding exercise where I wrote a command-line hangman game in Ruby.

Here are a few skills that I could tell the interviewers were looking for:

Code readability, which involves naming things well, using object-oriented design, and avoiding code smells.
Refactoring and short feedback loops were important in both live coding exercises.
Automated testing. After the first two take-home exercises listed above, interviewers appreciated that I wrote tests even though it wasn't required, and in two of the other three exercises I had to interact with pre-written tests.
Getting a lot done. This is a catch-all for being fluent enough in Ruby and Rails to build something in a short amount of time. For take-home exercises where no time limit is given, the reality is that "getting a lot done" means spending a lot of time on the exercise. If possible, choose a weekend or a less-busy-than-average few days where you can dedicate large blocks of time to it. If you have time, write on your blog or in the GitHub README about how you did the project. Here's my blog post about how I did the first take-home exercise listed above.

If you're wondering how to build up these skills, take a look at the Ruby and Rails review reading list which I've recently been working through. My ongoing study guide has a fuller list of resources.

Conclusion

Going into the job search, I had grim expectations for what lay ahead. I hadn't heard good things about the junior job market in Ruby. But I was pleasantly surprised in a couple of ways:

I got an interview at every company that I applied to, except one.
My job search lasted only two months.

On the other hand, I see how my job search could easily have taken longer, since most junior positions don't pay as much as I was looking for.

The most difficult parts of the job search were how much was expected on my resume, how intentionally I had to ask questions in interviews, and how nerve-racking the technical exercises were. If you're a junior Rails job-seeker yourself, I hope you'll find some use in my notes above on each of these areas. Good luck on your job search!

Appendix: Why a junior role?

Junior roles are a funny thing. Most people appreciate why they exist, but I've also sensed an undercurrent of contempt for them. I'm not saying most developers bash on junior roles. Nine times out of ten, I got helpful replies when I asked people for tips or leads about junior/entry-level jobs.

What I mean is that it's common to admire developers who skipped being a junior and figured everything out "in the real world." Some people take this admiration so far that they discount junior roles entirely. I've been told that I'm "projecting a position of weakness" by saying that I'm looking for a junior role, and that I should instead build a product and start my own company so that maybe in a year I'll be the boss hiring people.

(￣(エ)￣)ゞ

Let's set aside the facts that I don't want to start my own company, I do try to convey competence and not helplessness to potential employers, and I don't need and am not looking for extra hand-holding on every little thing—I am self-taught, after all.

Those facts aside, here's why I applied to junior roles almost exclusively:

Because that's how I think I'll grow the most. I was a teacher in my previous career, so I appreciate the power of learning by example. As a new developer, I'll learn most quickly and most thoroughly if I'm working with experienced developers who exemplify best practices. I could probably (painfully) learn all the same things on my own over time, but it would take much longer. So I don't believe I'm holding myself back by going for a junior role—quite the opposite.
Because I didn't have time to apply to everything. During the job hunt I was already working a full-time job in order to pay the bills. Also, I spent most of my free time filling in the gaps on my resume, which I felt was a better use of time than filling out dozens of long-shot applications for mid-level positions. Even the few applications that I did undergo were time-consuming in themselves, due to their sometimes long process of multiple interviews plus a take-home programming exercise. So I wanted to maximize my chances of getting a job by applying to my top (and most realistic) choices while continually improving my resume. This approach was also a lot more enjoyable than making job applications my new default evening activity.

But one time I did apply for a mid-level position with not-too-daunting qualifications. It didn't turn out well. I passed the recruiter interview and the technical exercise, only to be shut down a few minutes into an interview with the CEO and lead developer, when they realized I was looking for my first programming job. I'm sure this only happened because of poor preparation on their part, but still I couldn't help being discouraged from spending more of my limited free time on mid-level applications.

Also, I didn't apply for just any junior position. I wanted to find a job where I could stay for a good long while, so I ended up not applying for most junior positions that I ran across.

I stayed away from internships, contracts, and other temporary or low-pay arrangements.
I stayed away from tiny startups where I would be the only developer—that's not a junior role.
I stayed away from positions that involved other backend frameworks besides Rails. I'd like to stick to Ruby, at least on the backend, because that's what I most enjoy.

So yes, I looked for a junior position and I'm proud of it!

How to contribute to open source: a guide for Rails beginners

Felipe Vogel — Sat, 04 Dec 2021 14:40:54 +0000

Table of Contents

Find a project
Set up the project on your local machine
Become familiar with the codebase
Find and fix an issue
Conclusion

Here's how I recently got started contributing to open-source Ruby on Rails projects. I'm pretty new to Rails, so if I can do it then you can too! (For more tips for beginning Rubyists, see my study plan.)

Find a project

Here are a few beginner-friendly projects that I've come across. If you know of others, please let me know in the comments!

Discourse
Lobsters
Ruby for Good makes software for nonprofit organizations. Each of their projects has a Slack community, so they're extra easy to get into.
- Human Essentials
- CASA
- Circulate
- InKind Admin and InKind Volunteer (Rails + React)

If you want to widen your search, explore the resources at First Timers Only. As you consider projects to contribute to, keep these questions in mind:

Is the project active? Does it have recent activity and frequent commits?
Does the README.md have beginner-friendly instructions?
Are there a variety of issues tagged "Good First Issue" or something similar?
Are you interested in helping the project succeed?

Set up the project on your local machine

Once you've chosen a project, follow the setup instructions in README.md or CONTRIBUTING.md. You will probably run into problems; use your Google-fu to solve them. For example, here were my setup problems in Ubuntu in WSL2, for two of the projects listed above:

Circulate: The bin/webpack-dev-server command didn't work until I downgraded to a previous version. Also, chromedriver (for system tests) is not very straightforward to set up in WSL. The guide that worked for me is this one supplemented with this other one.
Lobsters: The mysql2 gem wasn't installing properly. It turns out I needed to first install MySQL (duh). So I followed this guide, adding the extra step of sudo service mysql start after installing the MySQL packages. I also had to create some missing files for MySQL and create a new MySQL user for the databases used by Rails. Oh, and I had to disable passwords before creating the new user, otherwise it couldn't be accessed.

Become familiar with the codebase

Poke around and get a feel for what the app does and how it works. Here are some good starting points in a Rails app:

the readme (of course)
config/routes.rb
the Gemfile
db/schema.rb
the tests

Find and fix an issue

You can follow roughly these steps:

Make sure you've read the project's README.md and (if it has one) CONTRIBUTING.md.
Find an issue that is well-described and seems simple to fix. Often (but not always) these are tagged as "Good First Issue".
At this point, some projects prefer that you claim the issue or leave a comment. Be sure to follow the project's contributing guidelines. Once you have the OK from the project maintainers, or if there are no pre-contributing steps, then it's time to work on the issue.
Reproduce the issue on your local machine.
Write a test that fails because of the issue. (Not all projects require this, but it's a good rule of thumb.)
Fix the issue, and make sure your new test passes.
Send back your fix by creating a PR (pull request). To learn how to make a PR, follow the steps in First Contributions. Here is another guide with a few extra steps that are good to keep in mind. Also, if you find that you've cloned a project's repo before forking it, this guide explains how to get back on track by making your local copy point to your fork.
Patiently wait for feedback from the project maintainers, and respond if they ask for more input from you.

Conclusion

If all goes well, your pull request will be accepted and you will have made your first contribution to open source! 🎉 From there you can keep an eye out for new issues in your favorite projects so that you can make even more contributions.

DEV Community: Felipe Vogel

Alpine.js as a Stimulus alternative

First, the context

Why not Turbo?

Why not web components?

Stimulus is incomplete on its own

Alpine.js

Alpine is like Stimulus!

Alpine is NOT like Stimulus!

Examples

Example 1: toggle menu

Example 2: filterable list

But what if I need Turbo?

Conclusion

Bonus: Alpine plugins

Being laid off in 2023-2024 as an early-career developer

Backstory: from teacher to developer

No one is safe from being laid off, and I'm not an exception

The 6-month job search

My job networking by the numbers

The good news

What's next in my career?

Coming to grips with JS: a Rubyist's deep dive

Why?

How?

A word on JS frameworks

Learning JS, re-learning Ruby

Object destructuring

Object literals

Learning Linux: recommended resources

Linux learning resources

Installing Linux on my old laptop

Goodbye to Windows?

Learning Git: my favorite resources

My favorite Git learning resources

Git-related VS Code extensions

Reflections on the fundamentals

Learning Ruby: a retrospective

But why Ruby?

My "Learning Ruby" roadmap

In the beginning

Time lapse

What next? Keeping it simple

OOP vs. services for organizing business logic: is there a third way?

The good old days

Then along came Rails

Two philosophical camps?

Service object skepticism

1. It's spelled out in the Rails Guides.

2. Martin Fowler, who first described the Active Record pattern, agrees.

3. Conversely, domain models don't have to be Active Record models; they can be PORO models.

Second-guessing myself; more study needed

Deductive study: books, talks, and gems

Inductive study: open-source Rails codebases

Conclusion: to be continued…

The first six months: lessons learned as a junior developer

Find balance

Keep up your learning journey

Don't be a silo: connect more, communicate better

Conclusion

RVTWS: a Ruby stack for modern web apps

Rails or Roda

ViewComponent

Turbo

Web components

StimulusReflex

Conclusion

Dot syntax and dig! for Ruby hashes, benchmarked

Baselines

Dot syntax

Dig with errors

Moral of the story

Appendix A: regular dig on a hash with error-raising defaults

Appendix B: the benchmark code

How to find your first Rails job

Why Ruby?

Where to look for Rails job postings

My job search: a bird's-eye view

Resume strategies

What to ask in the initial interview

Appendix A: regular `dig` on a hash with error-raising defaults