Forem: William Ghelfi

How to make both npm and yarn use private registries

William Ghelfi — Wed, 04 Nov 2020 14:46:06 +0000

npm login --registry <YOUR_PRIVATE_REGISTRY_URL>

yarn config delete registry

then don't trust the autogenerated ~/.npmrc configuration and modify it like this:

always-auth=true
registry=<YOUR_PRIVATE_REGISTRY_URL>
_authToken=NpmToken.<YOUR_TOKEN>

🍻 Cheers!

A lesson about Continuous Deployment - 10 years in the making

William Ghelfi — Thu, 22 Oct 2020 08:48:36 +0000

~10 years ago Joshua Kerievsky taught me a lesson that only yesterday I finally came to understand.

Or at least this is how I now understand his feedback.

The lesson

You must do Continuous Deployment / Delivery. If you are not doing it, you are competing in the wrong league.

If you're not doing CD because the thing you are working on just isn't ready for it, you must be following a plan with the goal of being finally able to start doing CD.

If you are doing CD, your software is leaner, more flexible, well organized. Your processes are smooth and possibly automated. You have the minimum requirements for taking your chances in A-league.

The anecdote

~2010 I was working at a company whose main product was a Java web framework with an Open Source core and some paid-for plugins.

I was the main frontend developer and also the DevOps guy.

We demoed the product to a potential investor, and Joshua followed up with an interview as a technical advisor to the investor.

This is how I remember it:

Joshua: So how do you guys distribute the product? Are you doing Continuous Deployment?

William: Well, the product is actually more of a lib, and it most certainly isn't a SaaS, so we c

Joshua: You should do CD. If you are not doing CD you are competing in the wrong league.

W: Let me rephrase, the product is

J: I got it the the first time :) but if you are not doing CD I think it's better - and he turned towards the investor - if we talk again when you are doing it.

Shortly after, hands were shaken, goodbyes were given, and off we went.

On our way out of the building, we brainstormed about the feedback we got, and we all agreed we didn't understand how it was even possible to continuously deploy a lib. Maybe he did mean Delivery instead of Deployment? But surely no one would ever abandon GitFlow! But then how...

One of the cofounders, who had been knowing Joshua for years, then told me: "I know, I don't understand it either. But if he said it, some day we most certainly will."

"Some day" was yesterday

Yesterday I started a proposal to abandon GitFlow for some form of trunk-based development at my current company.

A couple hours later, I stumbled upon this post by Joshua about technical debt.

The topic is slightly unrelated, but seeing who the author was made me think about that day of years ago and it finally clicked.

In the current status of the software development industry, you must be doing Continuous Development / Delivery, and if you don't, you must be willing to do it. Meaning that you must be following some well-thought plan that will finally enable you to do it.

Or you will be competing in some B-league. And it's fine, but you should at least be aware of the circumstances you find yourself in.

4 ways of fixing a "select" form field bad practice

William Ghelfi — Tue, 01 Sep 2020 08:35:43 +0000

The firestarter

Yesterday, a younger colleague of mine and extremely talented designer, shared his latest mockup on our Basecamp.

As always, it was beatiful and well balanced... until my heart suddenly started to bleed while my inner Caesar was screaming: "Et tu, Brute?"

This is what I tweeted shortly after:

William Ghelfi

@trumbitta

Having a "Choose" on top of a select form field, is like having a wood panel with a "Choose" sticker on top of your socks inside a drawer.

08:50 AM - 22 May 2014

Challenge accepted

Over the years, I often found myself having to explain to interns and young colleagues why this:

<select>
  <option value=" ">Choose one...</option>
  <option value="foo">First choice</option>
  <option value="bar">Second choice</option>
</select>

is in fact always a bad practice, and how to avoid it in a bunch of different situations.

This time I'm trying to explain my opinion on the topic once and for all, really just hoping to end up having a handy link to point people to when needed.

Why "Choose one..." is bad

Let's examine the following HTML code:

<select name="icecream">
  <option value=" ">Choose one...</option>
  <option value="banana">Banana</option>
  <option value="cream">Cream</option>
  <option value="smurf">Smurf</option>
</select>

The problem is, that first option doesn't have any purpose which is suitable for an option.

That first "Choose one..." option is there just to make you choose the actual option you wanted to choose in the first place!

This is madness, and I promise you no Spartan ain't going to kick me down a well for writing it.

It doesn't make any sense to have "Choose one..." as an option.

Making you want to choose an <option>, is the job of a <label>. Not of another <option>.

And how to fix it

The basics

The first rule of the Fight The "Choose one..." Madness Club is you always talk about it and you also use a <label>.

<label for="icecream">Choose an icecream:</label><br />
<select name="icecream" id="icecream">
  <option value="banana">Banana</option>
  <option value="cream">Cream</option>
  <option value="smurf">Smurf</option>
</select>

The second rule being: if you really, really have to use the word "Choose", use it inside the <label>.

Now that we know the basics, let's see them in action in a couple different scenarios and let's also see how you can choose proper first options for each one of those scenarios.

1. A filter-like `<select>`, mandatory choice

When the <select> is used to filter a list of possible items, you nearly always have to include a first show them all option.

<label for="superheroes">Show superheroes:</label><br />
<select name="superheroes" id="superheroes">
  <option value="all">All</option>
  <option value="flying">Flying</option>
  <option value="super-force">Super-force</option>
  <option value="super-sight">Super-sight</option>
</select>

Notes:

The value of the show them all <option> could be empty. It depends on your backend implementation and coding style.
Since in this example the choice is mandatory, having the show them all option as the first one perfectly fits the requirement.
A don't actually filter anything option is often a good default one.

2. A filter-like `<select>`, not mandatory choice

Ok, I cheated. The first example is valid in both cases.

It doesn't really matter if the choice is mandatory or not: when you have a filter-like <select>, you can always avoid using the dreadful "Choose one..." first option. Just stick with the winning <label> + show them all first option combo.

3. A simple choose-one `<select>`, mandatory choice

When the <select> is used inside a form to make you choose one out of some possible options, things can get tricky for the inexperienced Padawan.

Good for us I'm writing this very blog post!

Consider this:

<label for="opponent">Choose your opponent:</label><br />
<select name="opponent" id="opponent">
  <option value="godzilla">Godzilla</option>
  <option value="optimus_prime">Optimus Prime</option>
  <option value="shaq">Shaq</option>
  <option value="batman">Batman</option>
  <option value="chuck_norris">Chuck Norris</option>
  <option value="indiana_jones">Indiana Jones</option>
</select>

If Godzilla is the default opponent you want poor human fighters go against every time, your job here is done.

But you could also be a bit less evil and let those warriors try themselves against Indiana Jones by default – beware that gun, though!

Nothing easier than that. Just add a selected="selected" attribute (or just selected) to the desired <option>:

<label for="opponent">Choose your opponent:</label><br />
<select name="opponent" id="opponent">
  <option value="godzilla">Godzilla</option>
  <option value="optimus_prime">Optimus Prime</option>
  <option value="shaq">Shaq</option>
  <option value="batman">Batman</option>
  <option value="chuck_norris">Chuck Norris</option>
  <option value="indiana_jones" selected="selected">Indiana Jones</option>
</select>

Et voilà! Indy is the first opponent.

4. A simple choose-one `<select>`, not mandatory choice

Now what if the choice is not mandatory, what if I can skip it and walk away without fighting vs anyone?

You add a Monty Brewster option and call it a day.

Sometimes a choice can be a non-choice – Confucius.

Wait, what's a Monty Brewster option?

The following is a simple choose-one <select> with a not mandatory choice, which uses a Monty Brewster option instead of that bad bad bad "Choose one..." option.

<label for="opponent">Choose your opponent:</label><br />
<select name="opponent-2" id="opponent-2">
  <option value=" ">None</option>
  <option value="godzilla">Godzilla</option>
  <option value="optimus_prime">Optimus Prime</option>
  <option value="shaq">Shaq</option>
  <option value="batman">Batman</option>
  <option value="chuck_norris">Chuck Norris</option>
  <option value="indiana_jones">Indiana Jones</option>
</select>

Notes:

Just like before, the value of the Monty Brewster <option> can be anything you want. It depends on your backend implementation and coding style.
If you want to be super-sure that any browser will always render your desired option as the default one, just add the selected="selected" attribute.

Closing thoughts

As I hope I have demonstrated, it is always possible to avoid using the "Choose one..." first option in a <select>.

Using it is cheap, lazy, confusing to newcomers, and now you have this blog post with examples on how to implement the right thing.

What do you think about it?
Did you find a use case I forgot to cover?

Let me know on Twitter, or leave a comment!

Originally posted here: https://www.williamghelfi.com/blog/2014-05-24-select-form-field-bad-practices-and-how-to-fix-it/

React's default way of appending itself to a DOM tree considered harmful

William Ghelfi — Mon, 24 Aug 2020 22:08:18 +0000

For the impatient

Don't do this

<body>
  <div id="root"></div>
</body>

const rootElement = document.getElementById('root');

ReactDOM.render(<App />, rootElement);

Do this instead

<body>
  <div data-role-react-root></div>
</body>

const rootElement = document.querySelector('[data-role-react-root]'),

ReactDOM.render(<App />, rootElement);

What am I talking about?

If you ever dabbled in React or followed even the most basic of its tutorials, chances are you'll find the following snippet quite familiar:

<!-- here reduced to the bare minimum for simplicity's sake -->
<body>
  <div id="root"></div>
</body>

const rootElement = document.getElementById("root");

ReactDOM.render(<App />, rootElement);

This <div id="root"></div> plus the accompanying JavaScript snippet, or one of their variants, are everywhere: tutorials, official docs, tools like Create React App and Nx, online samples... everywhere.

Here's why this is bad to the point of being harmful.

Why is it harmful

In a nutshell:

Ids and classes are meant to be used for styling purposes:

<div class="some-class"></div>

Even better, don't use ids for styling purposes; use them only for navigation:

<a href="/somepage#pricing">Pricing</a>

<!-- more code -->

<section id="pricing">
  <!-- awesome pricing table -->
</section>

When you need to add special meaning to HTML, use data attributes:

<div data-special>Such special, much data</div>

This separation of concerns (styling via classes, navigation via ids, special meaning via data attributes) helps avoiding some harmful situations you most certainly will find yourself in at some point in your career if you keep using <div id="root"></div> as a React root element.

Harmful situation #1

Sue creates a new React app.

<div id="root"></div>

Bob hops on the project. The design by Alan has a furry pink border for the main container, meaning Bob needs a selector and lo and behold #root is already there.

#root {
  border: 2rem furry pink;
}

John the CEO has a vision: furry borders are so 2005! We need to get rid of it!
John the CEO calls Alan at 5:00 in the morning on a sunday and asks him to change the border ASAP, before his meeting with prospect investors.
Alan, a designer with good enough CSS skills to get rid of a border, but no JavaScript nor React skill whatsoever, finds the offending CSS rule and deletes it.

Then, in a rare flash of love for his job, Alan the designer searches the codebase for places where id="root" is used.

Alan finds our friend <div id="root"></div>.

Alan thinks he just removed the one and only reason for it to exist, and deletes the whole line.

A sip of coffee, a deploy to production, and the job is done just before the important meeting.

Chaos ensues.

Harmful situation #2

Sue creates a new React app.

<div id="root"></div>

Bob starts working on the project, but leaves the company with a ton of work still to be done.
John the CEO decides to be smart and hires a bunch of junior developers from outer space.
Xyz, one of the junior devs from outer space, works on a new strategic feature and being the junior that she is, she uses document.getElementById('root') as the base for the strategic feature.
Something happens on Twitter and suddenly "root" is not a good word anymore. Sue changes the HTML:

  <div id="react-base"></div>

Sue also changes the React initialization code accordingly:

ReactDOM.render(<App />, document.getElementById('react-base'));

The strategic feature doesn't work anymore.

Chaos ensues.

Conclusions

Both of these harmful situations happened to me multiple times over the last 20 years.

At first, I was Alan or Xyz, more recently I was Bob or Sue.

We had the knowledge to avoid it. Something we learnt during the first months of our careers.

Something some old dude taught us and we forgot.

What's the best practice

When working with HTML, CSS, and JavaScript:

For styling purposes, use only classes and element selectors.
Use ids only for anchors and navigation.
When you need to get a DOM element via JavaScript, use data attributes.

Or, on the other hand:

If you see a class, assume it's for styling only.
If you see an id, assume it's for navigation only.
If you see a data attribute, assume it's used via JavaScript somehow, somewhere.

Separation of concerns.

Works wonders, if you remember to respect it.

Image credits

Cover photo by Vladyslav Cherkasenko on Unsplash
Photo by Jamie Templeton on Unsplash

Forem: William Ghelfi

How to make both npm and yarn use private registries

A lesson about Continuous Deployment - 10 years in the making

The lesson

The anecdote

"Some day" was yesterday

4 ways of fixing a "select" form field bad practice

The firestarter

Challenge accepted

Why "Choose one..." is bad

And how to fix it

The basics

1. A filter-like <select>, mandatory choice

Notes:

2. A filter-like <select>, not mandatory choice

3. A simple choose-one <select>, mandatory choice

4. A simple choose-one <select>, not mandatory choice

Notes:

Closing thoughts

React's default way of appending itself to a DOM tree considered harmful

For the impatient

Don't do this

Do this instead

What am I talking about?

Why is it harmful

Harmful situation #1

Harmful situation #2

Conclusions

What's the best practice

Image credits

1. A filter-like `<select>`, mandatory choice

2. A filter-like `<select>`, not mandatory choice

3. A simple choose-one `<select>`, mandatory choice

4. A simple choose-one `<select>`, not mandatory choice