DEV Community: Stephdotnet

Customize Ubuntu: Make it Feel Like Windows

Stephdotnet — Mon, 25 Mar 2024 06:57:04 +0000

I like ubuntu, more than i used to, and since i am still a Windows OS user, it helped me to use GNOME extensions in order to make me feel more like “at home”.

This is a summary of all the extension that i've installed via the GNOME extensions market, and it’s worth saying that although this means 7 extensions for my computer to handle, it behaves properly.

Also if you have a vertical monitor setup, you might absolutely need the last extension of my list.

Dash to panel

For a Windows like UI :

If you work on a linux based environment but using windows for everything else outside work, you might need this gem.

In the list of the most noteworthy feature it has :

Ungroup application tiles (if you have a windows 7 nostalgia)
Live preview on hover
Show desktop button
Multi monitor support (and taskbar isolation)
Custom click behaviours (special mention to middle-click on tile to close application)

🔗 Links to the extension store and to the package on github:

https://extensions.gnome.org/extension/4812/wallpaper-switcher/ on gnome.org
https://github.com/rishuinfinity/WallpaperSwitcher on github

Wallpaper switcher

Ubuntu, or GNOME desktop environment, does not come with a built-in native wallpaper switcher as it aims for simplicity and minimalism. Instead, GNOME encourages users to add functionality through extensions, which allows for personalized customization without cluttering the core system.

💡There are many extensions that can do this for GNOME, but if you need such a feature, I can only recommend the simplest one.

🔗 Links to the extension store and to the package on github:

https://extensions.gnome.org/extension/4812/wallpaper-switcher/ on gnome.org
https://github.com/rishuinfinity/WallpaperSwitcher on github

Clipboard history

This is another extension that i miss from windows and that helps me on my daily copy/paste operations. If you’re not familiar with the feature, you might be enlighted by this discovery.

The default shortcut on windows is ⊞ win + v and even if it’s not the default shortcut in this extension you can easily change it for window’s.

💡 On ubuntu ❖ super + v is used by the system so you might need to unbind it from system shortcuts

🔗 Links to the extension store and to the package on github:

https://extensions.gnome.org/extension/4839/clipboard-history/ on gnome.org
https://github.com/SUPERCILEX/gnome-clipboard-history on github.com

Audio selector

This one is just a quick-win, when you need to switch from an audio input/output frequently. Since by default this is not possible without navigating in the system preferences, you might find this extension useful.

Just click on the volume icon 📢 and switch for another source.

💡It’s also interesting to be able to switch between input, ouput or both

🔗 Links to the extension store and to the package on github:

https://extensions.gnome.org/extension/5135/audio-selector on gnome.org
https://github.com/hs65/Gnome-Shell-Extension-Audio-Selector on github

CPU Freq

It might be useful to monitor at which frequency your CPU cores are running, especially if you run one day into a thermal throttle issue on your laptop. Of course not everyone needs it, but personnaly it’s been very helpful.

It comes with a taskbar widget, showing you the CPU frequency live, and an extended pannel to manage power setting and monitor each core activity.

🔗 Links to the extension store and to the package on github:

https://extensions.gnome.org/extension/1082/cpufreq on gnome.org
https://github.com/konkor/cpufreq on github

Emoji selector

This is the cherry on top for anyone who absolutely loves the emoji selector feature on Windows and macOS.

Nowadays, most apps give you the ability to use emojis within their interface (Notion, Slack, Twitter). But where do you turn when you need to quickly insert an emoji in a text field?

Well, Windows and macOS have a shortcut for that. On Ubuntu, you'll struggle a bit more, until you install this extension.

💡 By default it’s binded on the ❖ super + e shortcut, but i preferer ❖ super + . as it’s the same on windows.

🔗 Links to the extension store and to the package on github:

https://extensions.gnome.org/extension/1162/emoji-selector on gnome.org
https://github.com/maoschanz/emoji-selector-for-gnome on github

Gtile

Finally, last but not least, let me introduce you to Gtile. This nifty tool resolved several Windows layout issues I encountered while setting up a vertical monitor.

💡 You should get familiar with the extension shortcuts in order to get productive with it.

It allows you to split applications vertically and position them exactly as you prefer. Gtile is a lifesaver, complete with numerous shortcuts and extensive customization options.

🔗 Links to the extension store and to the package on github:

https://extensions.gnome.org/extension/28/gtile on gnome.org
https://github.com/gTile/gTile on github

Conclusion

Ubuntu with GNOME has evolved into an environment that can serve as a Windows replacement, especially for developers. Thanks to the amazing community contributing by creating GNOME extensions, it now offers many features available on Windows 11.

Feel free to share which extensions have been lifesavers for you, and see you later for more content! ✨👨‍💻

Clean your local git branches

Stephdotnet — Tue, 27 Feb 2024 07:27:44 +0000

Context

When working with Git and a remote repository, you might have faced the scenario where, once in a while, you need to clean your local branches.
This might be time-consuming, and you probably don't really care about it. However, I'll show you my workflow and the simple commands you can alias to clean your local branches in a wink.

Prerequisite

Since I'm working on GitHub, I've configured my repositories to remove head branches when a pull request is merged.

With this option enabled, your head branch will be deleted after your pull request is merged.

This feature can be useful for identifying stale branches

Step by step

Let's build the command together as we follow the process.

If you're not interested in the step-by-step explanations, you can jump to the end of the post, as this command is a one-liner.

Pruning remote

The following command, git remote prune origin, will allow us to delete remote branch references when the remote branch does not exist.

Since the remote branch is deleted when the pull request is merged, we need to remove the reference to this branch.

This is a necessary step, and next, we'll find a way to identify local branches with a "gone" remote.

Listing orphan branches

Now that we've removed the remote reference, we'll be able to identify those branches with git branch -vv.

As you may notice, the flag goneappears after the origin reference. This is our key to our next steps: isolating and deleting those branches.

By using grep and awk we'll be able to grab the branch names with a missing remote. This is the command i'm using : git branch -vv | grep "gone" | awk '{print $1}', and as you can see it works pretty well.

Deleting the branch

To use the result of the previous command, we'll need xargs since it will allow us to combine the result of a command with another one. So this is the almost final result

git branch -vv | grep "gone" | awk '{print $1}' | xargs git branch --delete

As you can see below, this action throws an error. This can be explained by the fact that the branch does not exist on the remote. It's the same error you'll get after a fetch with changes on the remote not present on the local branch.

Just after, you'll find the final result (which only consists of using the force flag), and now you're able to keep your branch list as clean as your desk!

The final result

As we saw together, this is the command you need to alias if you've implemented branch deletion on merge on GitHub.

git branch -vv | grep "gone" | awk '{print $1}' | xargs git branch --delete --force

I hope you found it useful, and see you next time! 🫡

Automatic semantic release

Stephdotnet — Mon, 22 May 2023 17:43:02 +0000

Goal

In this post I will describe a way to automate the process of :

Creating a tag based on the changes you've made on your repo
Publishing a release based on a specific event (eg: push on master)

Context

If you’re in software development, you might be familiar with semantic versioning. To summarize, it allows you to:

Keep track of the lifecycle of your app and indicate to users what changes were made.
Allow users of your package to safely update or upgrade newly published versions.

By following semantic versioning conventions (as indicated on https://semver.org), you’ll be able to indicate whether you are publishing a fix, a minor change, or a breaking change.

Semantic versioning is a series of numbers that looks like X.Y.Z, where each number has a meaning:

X: Breaking change introduced
Y: A minor change or major change with backward compatibility
Z: A fix or a patch on your product

By following this convention, you’ll allow users to safely require your package by following version constraints of your dependency manager (such as composer or npm): https://getcomposer.org/doc/articles/versions.md#writing-version-constraints

Why Automation?

While it’s easy to choose which version tag you’ll link to a specific commit (usually on your main branch) by using git tag X.Y.Z && git push --tags, you might be looking for a way to make this process automatic. Although automation comes with risks, and here we don’t want to mess with our version number.

To make sure that your changes are recognizable by automation, we are going to follow a convention that helps us identify what type of changes were introduced.

Conventional Commits

If you’re using a VCS to push your code, you’re familiar with the commit history. Conventional naming of your commits is a convention that we’ll follow to help us detect what sort of changes were introduced to our app.

You can check this website to have a look at what are conventional commits: https://www.conventionalcommits.org/en/v1.0.0/

What you just need to know is that by prefixing your commits (or your pull requests name, if you use squash merging), you’ll be able to automate the tag creation and the release of your changes:

fix: [description of the change] will indicate a fix or a patch (as well as the refactor prefix)
feat: [description of the feature] is equivalent to a minor change
feat!: [description of the change] will help us identify breaking changes

While conventional commits have a wider variety of syntax, this is basically what you need to know.

YAC: Yet Another Convention?!

Since following another convention might be a frustrating for you and your team, I’ll give you a tip to help you naming your commits: https://github.com/Everduin94/better-commits

This CLI tool assists you when committing your changes with a set of prompts that will write your commit message for you.

Also, if you’re using GitHub pull requests (with a squash merge strategy), you might have noticed that your pull requests are named after your first commit name. That way, nothing retains you to WIP your next commits, just make sure the first one reflects the nature of your changes.

This tool will assist you in writing you conventional commits

Let Your CI Do the Rest

If you’re familiar with GitHub Actions, you might just grab the following gist and go. It’s basically all you need to make everything work in automation.

If not, you just need to create a .github/workflows folder at the root of your GitHub project and to create (or paste) the following GitHub action files. Everything will now be automated when pushing

Also, create your first tag of main manually if you want the automation to work:

git checkout origin/main && git tag 0.1.0 && git push --tags

Check out this gist for the full code.

name: Semantic Release

on:
  push:
    branches:
      - main

concurrency:
  group: ${{ github.ref }}
  cancel-in-progress: true

jobs:
  release:
    permissions:
      contents: write # to create a release (ncipollo/release-action)

    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v2

      - name: Get Next Version
        id: semver
        uses: ietf-tools/semver-action@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          branch: main
          noVersionBumpBehavior: 'silent'

      - name: Create Release
        if: steps.semver.outputs.nextStrict != ''
        uses: ncipollo/release-action@v1.12.0
        with:
          allowUpdates: true
          draft: false
          makeLatest: true
          tag: ${{ steps.semver.outputs.nextStrict }}
          name: ${{ steps.semver.outputs.nextStrict }}
          generateReleaseNotes: true
          token: ${{ secrets.GITHUB_TOKEN }}

Unlike some CI workflows, this one is easy to read:

on: Defines the conditions that will run this workflow. Here, we want to trigger this workflow whenever we push code on main (eg: merging a pull request)
concurrency: It indicates that we only want one workflow at the time. This can be removed if you have multiple teams working on the same repository with continuous delivery.
jobs: Is where we define the actions.
checkout: Is just how GitHub retrieves the code for your action.
get next version: This GitHub action checks your commit names since the previous tag and creates the new tag based on the changes described by your conventional commits. Check the repository if you would like to learn more about it. This action is flexible and will allow you to customize the behavior of the version detection.
create release: This will create a release automatically after tag creation. You can have a look at the repository to know more about this action and the configurations that you can tweak.

Create a Release automatically

GitHub releases come with a "generate release notes" feature that will create a summary based on the pull requests merged since the creation of the tag. It can be interesting to have a summary of what's being shipped and to act as a changelog.

I think that something interesting in that action is that you can generate this release summary thanks to this option generateReleaseNotes: true.

Github automatic releases are neat

Diving deeper

Although this workflow suits my needs, and fits well for a small project, you might need to dig for more examples. There is one that you might like from Tamagui.dev :

https://github.com/tamagui/tamagui/tree/master/.github/workflows

The actions named changelog.yml and changelog-prerelease.yml you might find interesting ways to generate and update a release by using a latest tag

Conclusion

Using github actions to automate your processes is something that is affordable, free and easy if you start with something like automatic releases. I hope you learned something and that you'll enjoy looking at your automatic semantic versionning while having a cup of tea.

Cheers ☕

Update your npm dependencies and your package.json at once !

Stephdotnet — Mon, 20 Feb 2023 07:10:00 +0000

I recently stumbled upon an new feature of Composer added on 06/22 named composer bump (see this post) which brings a good way to keep track of the updates made to your repository.

As we all know, versionning is essential for the following reasons :

Ability to rollback to a previous version of your code
Collaborate and handle merge conflicts
You can travel back in time to know when a piece of code was modified

That’s why "updating" your composer.json at the same time as running composer update can be a way to know what happened when something goes wrong later.

In the end we have something clear and tracked in time

What about NPM ?

While doing my chores on a React project i looked for a similar feature with NPM (Node package manager), but surprisingly there is no such thing !

Chat-GPT struggled with my question... A LOT 😅 Npm version is not the right answer.

The savior: NCU

Sometimes, you’re just glad to find a package that makes everything that you need, and even more. The chosen one is Npm check update made by Raine Revere and it allows you to :

List all new dependencies
Interactively upgrade them
Upgrade your package.json

So if you want to have a package.json file up to date with your locked dependencies just install the package globally

npm install -g npm-check-updates

And run ncu -u to upgrade your package.json
Don’t forget to run npm install to install the updates and to renegerate your package-lock.json

You'll end up with this nice diff while commiting your dependencies update

Hopefully it was useful to you 👋