Opened an issue. Carefully listed browsers and versions. I investigated like a careful end-user. Not like a developer solutionizing on it, and looking at the code yet. I thought I just found a bug while doing something else, I was not there to drop everything and fix it on the spot.

Hard reload. Cleared cache. Tried again. Same problem. Oh well, it’s a bug.

A designer checked and told me it looked fine for them. So… at that point I was puzzled. 🧐

Then it clicked. I have Reduce Motion enabled in my system settings.

So yeah, it wasn’t a bug… or was it just a different kind of bug?

That’s when it hit me: a scrolling set of logos, a carousel, isn’t inherently accessible. And more importantly, when a user opts into reduced motion for accessibility reasons, we need to ensure that the layout stays intact, and with it, the meaning of the content.

A pretty common UI pattern like a carousel suddenly became… not so inclusive.

If you’d asked me yesterday whether a carousel of moving items is accessible design, I would have said, “sure, why not?”

Today, I’d say: not entirely. Not unless there’s a proper fallback, a static list of items that preserves layout and still communicates the same information clearly.

Because accessibility isn’t just about turning things off. It’s about making sure the experience still works when things change.

And the good news is, this is something we can account for.

@media (prefers-reduced-motion: reduce) {
  /* provide a non-animated, stable layout */
}

A small detail, but one that can make the difference between something that looks fine, and something that actually works for everyone.

Reference: prefers-reduced-motion on MDN

Credentials don’t fully replace .env In an ideal world we would not need to have a .env file at all.

When we originally started this task, we thought credentials would replace environment variables in their entirety.

However, as you may have already guessed, at the very least we need 2 environment variables even when using credentials:

RAILS_ENV RAILS_MASTER_KEY RAILS_ENV tells the application which environment it is when it loads and guides the application towards the correct credentials file for that environment.

RAILS_MASTER_KEY allows Rails to decrypt the credentials.

Without these 2 environment variables, Rails would not be able to infer which credential file to use and how to encrypt it.

…continue reading on the thoughtbot blog

Co-authored-by: Sami Birnbaum

What impact does this change have on you? Credential files for each environment It is important to conceptually consider all the environments we run the application in. In our case, these are:

development test staging production

…continue reading on the thoughtbot blog

Co-authored-by: Sami Birnbaum

Rob’s reaction: “It’s fine, I’ll make do without using a hairdryer during my stay”. My reaction: When I went to breakfast I let the staff members know I needed a hairdryer. They had one delivered to my room, while I was eating breakfast. Problem solved.

Later that day I read on the hotel room brochure on my desk, about the services provided, something like “there is a tea/coffee machine at every floor, and a closet where there are ironing boards and additional hairdryers available.”

That last part made me feel like they (the product owners and/or developers) knew more than one of their hairdryers were faulty but instead of replacing them (higher investment of time/money/effort), they provided instructions on how to solve the problem, a workaround: “go get another one at the end of the corridor.”

Except this information was not highly visible and available when I needed it. The text was not in the context where the error happened. The message to help solve my issue was not next to the hairdryer on the wall.

I had to ask a staff member (the developers) who basically made a change in the backend for me to remove the error that was happening in the UI, and I found a hairdryer on my bed later.

In your opinion, was this a good strategy to tackle the broken hairdryer issue? What would have been an alternative/better solution?

Let’s not forget about the user Rob who didn’t say anything and dealt with the broken feature and had a less-than-ideal experience overall, and nobody will ever know. But he may stop using the app… as in staying in a different hotel next time, maybe.

…continue reading on the thoughtbot blog

Co-authored-by: Sami Birnbaum

The way it works

In the address bar you can type jira [space] CODE-123 [enter] where CODE-123 is the ticket’s reference number. This will autofill the URL with the ticket identifier variable and take you there without passing from the Sprint or Board or pasting a whole URL.

How to set it up

Go to Chrome > Settings > Search engine > Site Search > Click on Add

In the dialog add the name you want, then the shortcut field is the keyword you want to use to start this site search, and the URL with %s in place of the query, for example: https://jira.my-beautiful-project.com/browse/%s

Now when I type jira [space] CODE-123 [enter], Chrome will load

https://jira.my-beautiful-project.com/browse/CODE-123 for me! Yay!

I move lines up and down using “Control + Command + Arrow Up” and “Arrow Down”.

In VSCode when I move a line down with “Control + Command + Arrown Down” there is an annoying error sound that, like the Terminal sound. This is a known bug related to Electron, apparently.

The solution 🙌

Create a file for default keybindings and edit it (I use VIM 😉):

vim ~/Library/KeyBindings/DefaultKeyBinding.dict

Add this exact content to it, save it.

  {
    "@^\UF701" = "noop:";
  }

I got the keybindings from this gist where @ is Command, ^ is Control and \UF701 is Arrow Down.

Restart VSCode. DONE.

We sign and acknowledge the code of conduct, buy our plane tickets, we pack and go. 🛫

During my last trip to a week-long in-person meetup, is when it hit me 💡!

Side note, the trip was a blast, a sort of a coding retreat, and having fun make food together, and talking about this and that. And I even saw the second to last stage of La Vuelta España passing by, and I was beyond excited.

Let’s continue…

The concepts of diversity, equality, and inclusion are not in a vacuum. They don’t start and end when you’re on Google Meet or in the DEI Council monthly meeting.

In a remote-first-and-pretty-much-remote-only world like ours, we interact only for a limited amount of time per day. A meeting can last a half our or an hour, pairing sessions can be longer, as can be 1:1s.

These meetings are predictable slices of time in our days, and we are prepared for them, we are in control. But in the in-person setting there is ane aspect of team building, doing activities together, pairing in-person, talk about code or consulting together, relax, and be ourselves in a shared physical space.

It’s important to be able to be ourselves, and we share parts of ourselves that maybe others don’t get to see on a daily basis, like for example they know I love to cycle but they don’t know I could get obsessed to the point of refurbishing a 70s road bike I asked my team lead to bring, and that made me the happiest person in the neighborhood for half a week. Oh did I mention the stage of la Vuelta? 😅

We get to be ourselves and it is a great DEI exercise, it’s real, not practice.

It may seem I’m saying I am a butt when I’m outside of work, or outside of meetings. It’s more subtle than that. It’s a conscious application of our high standards, and of the values we believe in.

Especially in meetings, in my experience, some folks may tend to speak less than others. Some of the reasons that come to mind are:

• They may be a member of a marginalized group, and may be afraid to speak up because of prior experience. By the definition they’ve been treated as insignificant and powerless;
• They may be a member of an underrepresented group, and may be afraid to voice a contrary opinion if they are up against a majority;
• They may have an introverted personality;
• Their title (less experience) or their role (to an adjacent department or field) may discourage them from actively participating. While you can check out our meeting guidelines, for further reading, I would like to focus on the last item in the list.

To the folks who tend to speak more in meetings: we should do our best to make sure everyone has a chance to express their opinion. I come from a culture where everyone is silent in a group of people causes discomfort and awkwardness. I am aware that I get impatient waiting in silence while I say “Does anyone have any thoughts or want to add anything?” and after a few seconds, we end up filling up the silence with a conversation with a restricted number of actors, and some quiet spectators.

This is not ideal, to say the least! We should try to avoid accidental power dynamics, where the conversation ends up among the ones who have more context than others, or have more decisional power over the resolution of an issue or strategy to tackle the next task at hand.

If someone in the team has less experience or context on a subject, we should absolutely encourage them to share their input, as it will bring a different point of view, a new perspective on the subject, and hopefully they would be asking clarifying questions to force the folks with more knowledge to explain what we are doing and why, what has been attempted thus far, the current resolution plan… out loud.

There are strategies to improve the participation from everyone in a group meeting:

Starting the meeting with a quick ice breaker game, where everyone gets to say something, will increase the chances that everyone will speak throughout the rest of the meeting, improving teamwork and collaboration. It could be as simple as “two truths and a lie”, or “what’s your least favorite household chore?” While talking about the purpose of the meeting, and the proposed solutions, even when it is a very technical question, try to zoom out, and ask for everyone’s input.

Scenario: we are trying to come up with the most effective way to store certain data about the orders for our pizza delivery service. The question is around Postgres tables, joins, SQL queries, and possibly analysis tools. Ask everyone, for example: “If you order a pizza online, how do you expect to see your order details?” Any answer will do, including “I have never ordered a pizza online.” Providing input and actively participating in meetings is a great way to:

• increase shared knowledge;
• discuss alternatives;
• write meaningful documentation. We may realize that some assumptions were wrong, we may compare solutions, and come up with new approaches.

…continue reading on the thoughtbot blog