Forem: David Boureau

Git clean local branches

David Boureau — Tue, 27 May 2025 06:08:44 +0000

Article originally published here https://alsohelp.com/blog/git-clean-local-branches

I have some problem with images here on dev.to, so article above may display everything in a better way

Article below :

The problem

Let's say you are on your machine, and your local repository has too many branches :

my_lovely_but_old_project> git branch
* Story-4965-password-complexity
  Story-4998-Clean-up-code-from-unnecesssary-comments
  PM25-modification
  blabla
  debug1
  debug2
  debug3
  debug4
  blabla2
  debugging-lm-4730
  doc-get-incident
  doc-incident
  docs/v5apiLocations
  document-api-separately
  main
  development
  refactor/gcalendar-sync
  .
  .
  .
  (... and much more branches)

You want to locally clean branches that are already destroyed on the remote repository

The solution

There you go:

git fetch -ap --progress 2>&1 | grep -E '\[deleted\]' | awk '{print $NF}' | sed 's|origin/||'  | xargs git branch -D

p option of fetch will prune remotes that don't exist anymore
progress option scratched my head... without it, the terminal is unable to read the output of the git command
awk print NF... reads the last word
sed ... removes un-needed origin prefix (we delete local branches)
xargs git branch -D finally removes all required branches
pfew!

Recreate the problem at home

Replace username by your actual GitHub user name.

Create a new GitHub repository supercleaner (tick "create a readme" checkbox)
Clone it locally git clone git@github.com:_username_/supercleaner.git
cd supercleaner
Create 4 branches locally

git checkout -b branch1 && git push origin branch1
git checkout -b branch2 && git push origin branch2
git checkout -b branch3 && git push origin branch3
git checkout -b branch4 && git push origin branch4

Now go to GitHub https://github.com/_username_/supercleaner/branches
Delete branches "branch1" and "branch3"
Good! So now only branch2 and branch4 exist on the remote repository. Locally, you still have 4 branches.
Go back to the main branch git checkout main so that we won't cut the branch on which we are sat :)
Kboom: it's time to try the command:

git fetch -ap --progress 2>&1 | grep -E '\[deleted\]' | awk '{print $NF}' | sed 's|origin/||'  | xargs git branch -D

List all what you have locally. Did it worked?

git branch

Summary

By tweaking well-documented git command, we can remove pain that we usually don't take time to address.

I hope you enjoyed it!

Rails philosophy explained with drawings

David Boureau — Mon, 26 May 2025 06:16:36 +0000

Article originally published here : https://alsohelp.com/blog/rails-philosophy-explained-with-drawings

The SVGs do not appear correctly here on dev.to, so I suggest the article above.

Text below :

In the NextJS era, there's a lot of difficulty for junior developers to understand the MVC model, so plain old Rails, Laravel or Django may looks weird.

Rails itself has a special doctrine, that I would advise to read before to dive into the framework, because you may not understand the design choice along the way if you don't deeply understand its philosophy.

Now here how I would draw it.

Rails values on deep integrated system, so your codebase may look like this :

gray zone = energy spend to write code
circle = one layer of your app (M, V or C for example)

As you can see, each circle is not completely independant of each other.

That means less code written at the end of the journey.

A cleaner architecture would be as follow :

gray zone = energy spend to write code
circle = one layer of your app (M, V or C for example)
green zone = energy spend to write boundaries code

Which leads to

more time spend on the gray zone
new time dedicated to write an maintain boundaries between zone

So is Rails 100% "clean" ? Maybe not for everybody.

Is Rails less energy spent? Less money spent? Less mental workload?

Yes.

T vs any in TypeScript

David Boureau — Sat, 24 May 2025 22:00:00 +0000

Article originally published here : https://alsohelp.com/blog/t-vs-any-in-typescript

Something you probably already heard about, but this is my way of seeing it.

Article below

This is something that went in my head while learning TypeScript.

Both means "could be any kind of type", but there is one huge difference.

Similarities of "any" and generic "T"

any is never constrained
generic is always under constraint somewhere

Example with generic T

Let's say we want a method that returns an array with only one element :

function oneElementArrayOf<T>(stuff: T): [T] {
  return [stuff];
}

T is under constraint : "stuff" can only be of T type, and the return type can only be an array of T

In other word, if you see the somewhere, there is another place where it will be used, in the args or the returned type.

Same example with any

The same code with any

function oneElementArrayOf(stuff: any): [any] {
  return [43]; // valid!!
}

"any" is not constrained by anything. The code is valid (TS valid I mean), despite not achieving the initial goal.

Summary

That was quick, but I hope it helped.

To sum up,

"any" means "zero constraint".
"T" means "has at least one constraint".

Hope it helped!

David.

Is TypeScript difficult to learn?

David Boureau — Sat, 24 May 2025 04:29:00 +0000

Article originally published here : https://alsohelp.com/blog/is-typescript-difficult-to-learn

My personal journey.

Article below

I just finished course from Jad, and it was a pure joy to follow.

That being said :

I'm not affiliated or whatsoever
It's not a review about this course

It's my personal feeling about the difficulty of learning TypeScript

My background

Learned and practice Java professionnally for many years, then switched to untyped languages, mostly JS and Ruby.

Difficulty of practicing TS without proper training

I think I made a mistake here. Because I already knew Java in-depth, I didn't need to learn the basics of TS before practicing.

Wrong, wrong, wrong. Do yourself a favor : don't be like me.

Review everything from the base. Here is what will happen :

Oh, I guessed it from experience
Woot? No way I would have implemented it this way.
Tons of ah-ah moments

How hard was it to learn TypeScript

It is one thing to read the lesson, but another to fight the TS compiler complaining about things going wrong.

Even with experience with other languages, I struggled one time or two during exercice.

So TS is not completely easy, but I would say it is not too complicated.

Take your time to grab every concept

And reading will not be enough. Be prepare to suffer on exercices.

How hard it is? Well, for a complete beginner, you will take more time, of course. But nothing undoable, so don't be too shy either.

For a beginner, I wouldn't advise the official docs. I loved Jad's course, but there are probably other good online courses nowadays. It will give you enough guidance to properly climb the moutain without sacrifying too much energy.

Can ChatGPT help?

Hmm nowadays I would say 50-50. I mean, it may point out the right bug, or give a vague but correct idea around 50% of the time. Or just be completely wrong the other half of the time.

What is sure it that it won't help you if you don't take time to understand the basics anyway.

What helped me a lot

I think my biggest "ah-ah" moment, was when I decided to replace "type" and "interface" keyword by "contract" (in my head only, "contract" does not exist in TS).

At that point, everything tricky stuff was a lot clearer.

TS just define contracts about what variables, classes and functions should be.

Summary

TS may be easy or hard to learn, depending on your initial experience. My takeaway.

TypeScript primitive types

David Boureau — Fri, 23 May 2025 04:23:22 +0000

Article originally published here : https://alsohelp.com/blog/typescript-primitive-types

It's mostly a note to self

Here are primitive types :

number
string
boolean
bigint
symbol
undefined
null

But wait!

These primitives types are actually JavaScript types.

I love how elegant TypeScript is. ❤️

Because it's a superset of JavaScript, it doesn't try to reinvent the base types, and just accept JS basic types as TypeScript basic types.

Yes, they are the same.

So this is correct :

function saySomethingClever(n: number, b: boolean): string {}

You can explicitly use JS primitive types.

BTW you probably already heard about null and undefined, but probably not about bigint and symbol.

You can view the bigint docs and symbol docs on MDN.

At that point you should try to ask "but where are object" ?

That will be the topic for another article.

Best,

David.

Unpoly outclasses Hotwire

David Boureau — Thu, 22 May 2025 09:37:21 +0000

Article originally published here :

https://alsohelp.com/blog/unpoly-outclasses-hotwire

What Unpoly and Hotwire share

Here is what do they have in common :

Both are frontend web tools
Both aim to "make web UI snappy like React", without using any React-like framework
Both tries to respect the web "as it is", avoiding un-necessary JS layer
Both play with plain old HTML render (like Laravel, Rails or Django)
Both are born inside a Ruby-on-Rails based company

Now here is how Unpoly and Hotwire complexity compares, and why I think Unpoly is so far the best front-end tool, at least in terms of low-tech and low-complexity.

Lowering front end complexity

I'm not a good drawer I know, but here is the idea :

Hotwire is far simpler than React.

But Unpoly is even simpler.

However, if you try to go back to plain old vanillaJS/jQuery, you end up with a complexity that is even worse than React.

Why is that?

React seems to be go-to front end tools nowadays.

But if you use Hotwire, you will reduce the complexity, just by cutting off the quantity of LOC in the frontend.

Remember that a huge quantity of LOC is harder to maintain than a smaller one, even if the code is clean or IA-generated.

I've seen a Reddit comment saying that using Hotwire reduce by 70% the code required to get things done.

So is Hotwire a move in the correct direction ? I think so.

However...

Unpoly is simpler than Hotwire

Hotwire means a lot of convention to remember.

Hotwire means a fair effort of training before using it - BTW there is an incredibly
good Hotwire tutorial.

Unpoly is the opposite.

Less code, less convention, almost no need of training, once you grab the Unpoly demo.

There is no tutorial about Unpoly because it's incredibly easy.

Also no need for the server to know about Unpoly. You just render plain old HTML.

One last thing is that I can chirurgically target what element to replace, whereas Turbo swaps the whole body of HTML.

Summary

For personal project, you don't need a React-like framework - it's probably another story inside big companies.

Just use plain old HTML, and augment it with JS with the tool that creates the smallest amount of friction(s).

For me, it's Unpoly.

Declare an array in TypeScript

David Boureau — Wed, 21 May 2025 04:57:00 +0000

Article published on my blog here :

https://alsohelp.com/blog/typescript-declare-array

How to declare an array in TypeScript the right way. A small recap, mostly note to self.

First, this is how you declare an array in JS :

In JS

const fruits = ['apple', 'orange', 'banana'];

Remember that TS generates JS, so you always end up with the above.

In TS

In TS, it will look like this:

const fruits: string[] = ['apple', 'orange', 'banana'];

You are telling TS "I'm declaring an array of string".

In TS, you always declare an array of something.

an Array of string,
an Array of number,
an Array of MyType,

and so on.

Things to avoid

There is no "array of nothing" in TS.

❌ const fruits: [] = []
// wrong! you are declaring an empty array

❌ const fruits = [1, 2, 3]
// wrong! you are declaring an "array of any", like in JS

❌ const fruits: any[] = [1, 2, 3]
// wrong! you are using any, which is almost forbidden in TS

Summary

An array in TS is always an "array of something". I think it's the only gotcha to remember.

Best,

David

Background jobs with Rails 8 are delightful

David Boureau — Tue, 20 May 2025 03:58:00 +0000

Article originally published here (image doesn't work well here) :

https://alsohelp.com/blog/background-jobs-in-rails-8-are-delightful

There's one thing I forgot to mention about my Rails 8 opinion last time : it's how background jobs are handled in Rails 8.

Example

Here's what it looks like on my current project :

(image)

Background jobs should be a default feature

Most web frameworks completely underestimate how background jobs are valuable.

Honestly I always need a way to handle background jobs, on every new web project.

Forgot password email ? => background task to send the email
Clean image asynchronously ? => background task to clean the image

And so on.

IMHO A good way go see if a framework is mature enough is "are background jobs already included from day 1".

Why it's delightful with Rails 8

Why it is so good with Rails 8?

Because you don't have to care about : it's already included.

From what I've read, it's not possible with other frameworks - outside Laravel.

The Database is already backed
The Dashboard is already included (!)
And, of course, it's damn easy to hook any kind of job inside the framework itself.

All I had to do is to protect the route, so that only the admin can view it.

You don't have to care about internals because it just works

You don't have to care about the JS/CSS, because as long as you keep "propshaft" as gem, it will work.

The beauty (again) is that I don't use propshaft myself. I use Vite.

This is Rails deep integration : even if you don't use the default frontend management, external gem will work with your product.

Two different processes

Of course "background jobs" means "take another thread than the one of the web server".

So there's a tiny configuration locally (Thank you Matt Brictson for your bin/dev
), and another one for the production, but honestly, it's one line of code that you can forget once properly set up.

Summary

Rails 8 shine not only for the things previously mentionned, but also thanks to mission control.

It gives you very elegant, monitor-able background jobs, right from day one, with full support and upgrades of the Rails maintainers.

Close from silver bullet ;)

Where 1 = 1 in SQL

David Boureau — Mon, 19 May 2025 05:39:00 +0000

Article originally published here : https://alsohelp.com/blog/where-one-equals-one-in-sql

After more than 5 years of writing SQL, I found this thing in a colleague's code.
At first, I didn’t see the point.

Juniors are often baffled when they see this condition in their colleagues’ code.

(Personally, the first time I saw it, I thought it was some trick to optimize a join’s performance in certain conditions...)

In reality, it’s just a handy tip.

It’s used to quickly test query results with and without certain conditions.

Here, if we wanted to test the query without the condition work = 'c-level', we’d have to move degree = 'master' next to WHERE (and remove the AND keyword).

That’s tedious...

The 1=1 trick simply avoids that, saving a bit of time when testing queries. :)

SELECT *
FROM people
WHERE 1 = 1
-- AND degree="master"
AND work="c-level"

Each child in a list should have a unique key prop

David Boureau — Sun, 18 May 2025 04:16:00 +0000

Article originally published here : https://alsohelp.com/blog/each-child-in-a-list-should-have-a-unique-key-prop

This is a React disaster, because I can spend countless hour on this (well-known!), but simple bug :

"Each child in a list should have a unique 'key' prop."

Wait, wait, wait... I already googled around and it seems so easy to fix!

I had already set a unique key on every element in my list!

Who's in charge? Who's guilty?

Undefined data when initializing my component.

Yup.

Here's what was happening:

My server component was loading data
Before loading, my state was undefined
My PlotMap was trying to map over undefined
React threw the key error

The solution was simple but so easy to miss

Check my data before passing it to my component!

This simple conditional rendering fixed everything.

Always make sure your data exists before using it!

// This is wrong, causing an error
<PlotMap data={data}>

// Fixed!
{data && <PlotMap data={data}>}

How to display git shortsha in terminal

David Boureau — Sat, 17 May 2025 05:02:00 +0000

Article originally published here : https://alsohelp.com/blog/how-to-display-git-shortsha-in-terminal

I had a problem displaying the image here on dev.to, everywhere else, the text is fine

Article below :

The answer

The answer is already given in this StackOverflow answer more than 6 years ago (!) and still holds true nowadays :

git rev-parse --short HEAD
# 4d7b213

Why the short sha?

In Git every commit is identified by a 40-character hexadecimal string named the "Git SHA".

See the commit number pointer by the arrow ? (view it in original article)

Yes, that's the git short SHA.

Only the first 7 digits amongst the 40.

The risk of collision is small enough to identify uniquely each commit.

Trick to display the short SHA in the Terminal

You can define an alias, on Linux or Windows, in order to display it without to remember the whole command :

alias shortsha='git rev-parse --short HEAD'

(exemple from my Linux machine)

Will be used like this :

shortsha
# 4d7b213

Neat!

Last trick

Sometimes, you will try some attempt to display it somewhere in the footer, in order to increase confidence about which version of the website is deployed. I like and use it, but I admit it's not very common though.

Summary

That was a quick recap about the git short SHA.

Is React beginner-friendly?

David Boureau — Fri, 16 May 2025 05:09:00 +0000

I originally published this article on my blog here : https://alsohelp.com/blog/is-react-beginner-friendly

Notice it's opinionated, you are perfectly allowed to disagree :)

Article below :

No.

It's not.

React looks like very appealing for beginners, because each component looks like a brick you can easily (almost physically) manipulate with a very fine granularity.

The easy part

And each component sounds very intuitive.

Let's take a basic example, taken from one of my previous project :

import { NextSeo } from 'next-seo';

import Navigation from '../components/navigation';
import ScrollToTop from '../components/ScrollToTop';

const About = () => (
  <div>
    <NextSeo title="About | Some title | Some subtitle" description="lorem ipsum" />

    <ScrollToTop />
    <Navigation />
  </div>
);

How good is that?

Even with little or no dev experience, you can guess that the about page uses a ScrollToTop, and a Navigation component.

Oh, and SEO is also handled by a component given by the underlying framework (yes, it's NextJS).

So good!

So Easy!

The trap

No let's face it, React is full of akward traps.

Here is the official docs about "don't use useEffect here".

You can achieve all problems in React in multiple ways, and you have no clue, unless you spend countless hours on the docs, to know which one is "the right way" or not.

Another possibility is to spend your night to read how React replaced the whole underlying DOM Event system, then try to understand how hooks tries to play with this replacement, and then you start to guess what to do and what to avoid with React.

No full integration

The last huge problem with React is the complete lack of deep integration.

Oh, I know, there are some.

ShipFast (commercial), NextJS (free, but hugely bound to private PaaS company), Blitz (build on top of NextJS, with same inconvenients), React-Router (not used by all the community), Redwood (same)...

So there are no "React way" to build something from top to bottom.

Good luck for long-term maintenance.

Still possible of course, but...

definetely not for beginners.

Summary

React is a good framework, in term of popularity.

Is it for beginners?

No.