Reinstalling Your Must-Have Dev Tools and Extensions on Mac

A step-by-step guide to bringing your essential development setup back to life.

So, you’ve got a shiny new Mac, and you’re ready for a fresh start. But where do you begin? Installing the right tools and applications is crucial to get your development environment up and running smoothly. In this guide, I’ll walk you through using Mac terminal commands to streamline the installation process for essential programs like Homebrew, Visual Studio Code or SDKMAN. Let’s get your Mac setup right 💻!

Which applications have I installed?

If you want to see a list of all the applications installed on your old Mac before you start fresh on a new one, the terminal has a handy command for that. Simply open the Terminal and run the following command:

ls -1 /Applications

...

Discord.app

Docker.app

GIMP.app

...

It’s worth noting that the list generated by this command includes all applications in your /Applications folder, even those that can be easily reinstalled with Homebrew.

Homebrew

You’re a using Homebrew? Okay, then you’ll should do is to get a list of the software you have installed on your old Mac. Launch the Terminal, then execute this command:

brew list -1

==> Formulae
azure-cli
azure-functions-core-tools@4
base64
borgbackup
...

Visual Studio Code Extensions

To list all the Visual Studio Code extensions you’ve installed, you can easily do so by opening a terminal and typing the following command:

code --list-extensions

This will give you a straightforward list of all your extensions. But if you want to take it a step further—you can use the following command to generate a series of commands that will reinstall each extension:

code --list-extensions | xargs -L 1 echo code --install-extension

This command creates a list where each line is a command to install one of your extensions, like this:

...
code--install-extension editorconfig.editorconfig
code--install-extension esbenp.prettier-vscode
...

With this list, you can easily reinstall all your VS Code extensions on your new machine with minimal effort, ensuring your development environment is back to how you like it in no time.

SDKMAN!

If you’re using SDKMAN to manage your JDKs and other SDKs, there’s one more handy command worth mentioning. By running:

tree -L 2 ~/.sdkman/candidates/

...├── gradle│
   ├── 8.4│ 
   ├── 8.5│   
   ├── 8.6│   
   └── current -> 8.6
   ├── java│
   ├── 11.0.16.1-tem│
   ├── 17.0.8.1-tem│
   ├── 21.0.2-tem
...

you can quickly visualize all the SDKs and JDKs you have installed. This command provides a neat directory tree that displays each SDK along with its version. It’s a great way to quickly assess your development environment and ensure you have the right versions set up before diving back into coding on your new Mac.

Conclusion

And with that, we’ve come to the end of our guide on setting up your new Mac with all the essential development tools. Getting your new Mac set up with the right tools is the first step to a smooth and productive development environment. With some terminal commands you’re well on your way.

If you found this guide helpful, make sure to follow me for more tips and tricks on software development 😊.

Photo by Maxim Hopman on Unsplash

ByteBeat Odyssey – Refactoring

Of course it’s about refactoring

Welcome to the compilation of heartbeats from my work, a mosaic of moments, musings and flashes of inspiration on software development topics. Many posts have been published first on various social media channels. Here I will continue loosely these chronicles. Enjoy reading.

Refactoring

🛠️ Refactoring is the secret behind clean, efficient code!

1. Identify areas that need improvement.
2. Define what you aim to achieve through refactoring.
3. Break down the refactoring steps into manageable chunks.
4. Refactoring is an iterative process. Don’t hesitate to revisit and refine.
5. Ensure each change doesn’t alter the functionality!
6. Testing helps catch bugs early and ensures the code still works as intended.
7. Measure the improvements brought by refactoring.

Ready to give your codebase a makeover? ✨

ByteBeat Odyssey – Test-Driven Development

Today it’s TDD’s turn

Welcome to the compilation of heartbeats from my work, a mosaic of moments, musings and flashes of inspiration on software development topics. Many posts have been published first on various social media channels. Here I will continue loosely these chronicles. Enjoy reading.

Test-Driven Development

🔍 Looking to level up your development skills? Discover the power of Test-Driven Development (TDD) 🚀

Here is how the TDD cycle works:

1. Add a test, which fails (Red)
2. Run the tests. See if any test fails
3. Write enough code to pass all the tests (Green)
4. Run the tests again. If any test fails, go to step 3.
5. Refactor the code. (Refactor)

ByteBeat Odyssey – Software Tests

This time it’s about tests

Welcome to the compilation of heartbeats from my work, a mosaic of moments, musings and flashes of inspiration on software development topics. Many posts have been published first on various social media channels. Here I will continue loosely these chronicles. Enjoy reading.

Software Tests

Looking to take your tests to the next level? Then check out these tips:

1. small and focused tests
2. test only one specific aspect
3. check positive and negative cases
4. include only the code necessary to pass the tests
5. use code coverage to test all the relevant parts

ByteBeat Odyssey – ClickOps

Now it’s time for a bad practice

Welcome to the compilation of my series of heartbeats from my work, a mosaic of moments, musings and flashes of inspiration on software development topics. Many posts have been published first on various social media channels. Here I will continue loosely these chronicles. Enjoy reading.

ClickOps

𝐂𝐥𝐢𝐜𝐤𝐎𝐩𝐬: 1. 𝑒𝑟𝑟𝑜𝑟-𝑝𝑟𝑜𝑛𝑒, 𝑡𝑖𝑚𝑒-𝑐𝑜𝑛𝑠𝑢𝑚𝑖𝑛𝑔 𝑝𝑟𝑜𝑐𝑒𝑠𝑠 𝑐𝑙𝑖𝑐𝑘𝑖𝑛𝑔 𝑡ℎ𝑟𝑜𝑢𝑔ℎ 𝑣𝑎𝑟𝑖𝑜𝑢𝑠 𝑜𝑝𝑡𝑖𝑜𝑛𝑠, 2. 𝑚𝑎𝑛𝑢𝑎𝑙 𝑐𝑜𝑛𝑓𝑖𝑔𝑢𝑟𝑎𝑡𝑖𝑜𝑛 𝑜𝑓 𝑐𝑜𝑚𝑝𝑢𝑡𝑖𝑛𝑔 𝑖𝑛𝑓𝑟𝑎𝑠𝑡𝑟𝑢𝑐𝑡𝑢𝑟𝑒 𝑜𝑟 3. 𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑖𝑛𝑔 𝑎𝑢𝑡𝑜𝑚𝑎𝑡𝑒𝑑 𝑐𝑜𝑚𝑝𝑢𝑡𝑖𝑛𝑔 𝑖𝑛𝑓𝑟𝑎𝑠𝑡𝑟𝑢𝑐𝑡𝑢𝑟𝑒.

ByteBeat Odyssey – Code Reviews

A new series from the daily work

Welcome to the compilation of my series of heartbeats from my work, a mosaic of moments, musings and flashes of inspiration on software development topics.

Each post is a snapshot, a glimpse, or a fleeting thought. This series captures the steps, missteps, and leaps that have occurred to me recently.

Many posts have been published first on various social media channels. At the request of many, I have collected them here. I will continue loosely my chronicles. Enjoy reading.

Code Reviews

Did the programmer not understand your comments in the code review?

These tips will help you improve your next review and give your comments the boost it needs:

1. Point out only specific problems.
2. Explain your opinion.
3. Include examples.

Validate your specs with OpenAPI Style Validator

OpenAPI Style Validator is a tool to create API specs with understandable descriptions, examples and consistent use of naming conventions.

The Validator helps developers to identify issues in OpenAPI specifications. With defined rules you can describe exactly how an API specification should look. These specs can be checked automatically and the results can be used in code reviews or even in a build pipeline where rule violations result in a build break.

Complete descriptions and naming conventions
The validator checks various objects of the OpenAPI schema, starting with the info object and the associated contact and license object. Often these details are not provided at all. Here you see as an example how the popular Petstore example provides the details.

{
"info": {
    "version": "1.0.0",
    "title": "Swagger Petstore",
    "description": "A sample API that uses a petstore as an example to demonstrate features in the OpenAPI 3.0 specification",
    "termsOfService": "http://swagger.io/terms/",
    "contact": {
      "name": "Swagger API Team",
      "email": "apiteam@swagger.io",
      "url": "http://swagger.io"
    },
    "license": {
      "name": "Apache 2.0",
      "url": "https://www.apache.org/licenses/LICENSE-2.0.html"
    }
  }
}

The next object we’ll take a closer look at is the operation object. But let’s start with the paths object. The paths object contains all the paths to existing endpoints (path items). A single path (/pets) contains operations which describe what http methods are allowed.

{
"/pets/{id}": {
    "get": {
      "description": "Returns a user based on a single ID, if the user does not have access to the pet",
      "operationId": "find pet by id",
      "parameters": [
        {
          "name": "id",
          "in": "path",
          "description": "ID of pet to fetch",
          "required": true,
          "schema": {
            "type": "integer",
            "format": "int64"
          }
        }
      ],
    }
   }
}

The OpenAPI Style Validator detects whether certain properties exist For example, the property „summary“ is missing in the above listing. In contrast, a „description“ is present. The absence of a property is an error, if you have configured it that way.

Let’s look how the OpenAPI Style Validator checks the data type descriptions. Data types are defined in the OpenAPI specification as schema objects that can be referenced in requests or responses (e.g. „$ref“: „#/components/schemas/NewPet“). The validator can check if all schema properties like description and example are present and not empty.

{
"NewPet": {
    "type": "object",
    "required": [
      "name"
    ],
    "properties": {
      "name": {
        "type": "string"
      },
      "tag": {
        "type": "string"
      }
    }
  },
}

If we look at the NewPet schema object in the above listing, we do not find descriptions and examples. Examples and descriptions in an API spec make the documentation more understandable.

Now let’s move on to naming conventions. Naming conventions help to make an API easier to use. The OpenAPI Style Validator supports a number of different conventions that we can apply to paths, path parameters, query parameters, cookies, headers and properties. The naming conventions are: the underscore case (snake_case), camel case as we know it from Java and JavaScript and the so called hyphen case, also known as Kebab Case.

Options and launching the OpenAPI Style Validator
With the defined rules we have learned now, we can control how an OpenAPI specification has to look. What kind of options do we have? There are boolean options like „validateOperationOperationId“, which by a true, requires that each operation has an id. The option „validateOperationSummary“ requires that operations also have a description. But there are also string type options like pathNamingConvention, parameterNamingConvention, pathParamNamingConvention and queryParamNamingConvention. With these options, we can determine if elements should follow e.g. the underscore case or camel case naming convention.

So, how do we launch the validator? The maven command looks like this:

mvn openapi-style-validator:validate

For Maven the OpenAPI Style Validator plugin must be configured inside the pom.xml Currently, io.swagger.core.v3 dependency must be excluded, otherwise a newer version of the library is used which unfortunately is incompatible with version 1.8 of the OpenAPI Style Validator. As you can in the following listing, each option can be added as a parameter under an XML tag, e.g. „validateOperationSummary“ with true or false as text content.

<plugin>
<groupId>org.openapitools.openapistylevalidator</groupId>
<artifactId>openapi-style-validator-maven-plugin</artifactId>
<version>1.8</version>
<configuration>
    <inputFile>petstore-expanded.json</inputFile>
</configuration>
<dependencies>
    <dependency>
        <groupId>org.openapitools.empoa</groupId>
        <artifactId>empoa-swagger-core</artifactId>
        <version>2.0.0</version>
        <exclusions>
            <exclusion>
             <groupId>io.swagger.core.v3</groupId>
                <artifactId>swagger-models</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
</dependencies>
</plugin>

And by the way, with the default configuration we get the following result for the Petstore example:

[INFO] --- openapi-style-validator:1.8:validate (default-cli) @ openapitools-validator-mvn-example ---
[INFO] Validating spec: petstore-expanded.json
[ERROR] OpenAPI Specification does not meet the requirements. Issues:

[ERROR]         *ERROR* in Operation GET /pets 'summary' -> This field should be present and not empty
[ERROR]         *ERROR* in Operation GET /pets 'tags' -> The collection should be present and there should be at least one item in it
[ERROR]         *ERROR* in Operation POST /pets 'summary' -> This field should be present and not empty
[ERROR]         *ERROR* in Operation POST /pets 'tags' -> The collection should be present and there should be at least one item in it
[ERROR]         *ERROR* in Operation GET /pets/{id} 'summary' -> This field should be present and not empty
[ERROR]         *ERROR* in Operation GET /pets/{id} 'tags' -> The collection should be present and there should be at least one item in it
[ERROR]         *ERROR* in Operation DELETE /pets/{id} 'summary' -> This field should be present and not empty
[ERROR]         *ERROR* in Operation DELETE /pets/{id} 'tags' -> The collection should be present and there should be at least one item in it
[ERROR]         *ERROR* in Model 'NewPet', property 'name', field 'example' -> This field should be present and not empty
[ERROR]         *ERROR* in Model 'NewPet', property 'name', field 'description' -> This field should be present and not empty
[ERROR]         *ERROR* in Model 'NewPet', property 'tag', field 'example' -> This field should be present and not empty
[ERROR]         *ERROR* in Model 'NewPet', property 'tag', field 'description' -> This field should be present and not empty
[ERROR]         *ERROR* in Model 'Error', property 'code', field 'example' -> This field should be present and not empty
[ERROR]         *ERROR* in Model 'Error', property 'code', field 'description' -> This field should be present and not empty
[ERROR]         *ERROR* in Model 'Error', property 'message', field 'example' -> This field should be present and not empty
[ERROR]         *ERROR* in Model 'Error', property 'message', field 'description' -> This field should be present and not empty
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  3.342 s

Links 
OpenAPI Style Validator https://github.com/OpenAPITools/openapi-style-validator
Petstore Beispiel https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore-expanded.json
Validation example https://github.com/claudioaltamura/openapi-tools/tree/main/part-two-validator/spring-boot-example

Project Pilot – Short Notes

Series on Software Design Practices – Part 3

In this small series on design practices, I write about various practices. In every article, I give a brief and simple explanation. In part 2 I wrote about prototypes. This time I present project pilots as another software development design practice.

We already talked about spikes, which help you to find approaches for a technical problem, or prototypes to test a specific concept. What these concepts have in common is that they should not be used in production. Spikes may not be good enough or prototypes only focus on feasibility.

Right here comes in the so-called project pilot. You add additional points regarding production readiness, that you are able to test the viability and how likely it is that the software succeed. So it’s the first phase in a larger project with a defined productive scope. And very importantly, project pilots provide you valuable feedback on ideas and concepts.

Project pilots are another good strategy for managing risk. The concept helps you to uncover potential flaws ahead of a full launch. Use this feedback to identify issues and correct them in advance.

Prototype – Short Notes

Series on Software Design Practices – Part 2

In this small series on design practices, I write about various practices. In every article, I give a brief and simple explanation. In part 1 I wrote about Spike Solutions. This time I present prototypes as a software development design practice.

A prototype is a simplified, functional model of a planned product or component. It serves as a preparation for production, but can also be used to illustrate a specific concept. The prototype is often the first milestone in a project to test the suitability and acceptance of a new technology, application or process.

The prototype is an essential development step regarding the future solution. However, it should not be used in production after the feasibility check. The building blocks, on the other hand, can be used and improved in the final solution.

Spike Solutions – Short Notes

Series on Software Design Practices – Part 1

In this small series on design practices, I write about various practices. In every article, I give a brief and simple explanation. This is part 1. Let’s start with spike solutions.

For me a spike is a way to figure out answers to a technical or design problem. It’s a solution to explore potential solutions. You make a spike to reduce the risk of a technical problem or to achieve a better estimate for a user story.

Spike solutions could be technical or functional. Functional spikes help you to analyze an overall solution. What is to be done? How do we break the work into smaller pieces? Where is the complexity hidden?

Technical spikes on the other side are a way to find different approaches for a problem, e.g. specific technical implementation or to get confidence that the chosen strategy works out.

Experience has shown that first you should focus on the problem with the spike and ignore other concerns, second not all spike solution are good enough to deploy in production. And at last, demos and discussions about the approaches are highly valuable steps.

Consent Management Platform von Real Cookie Banner