
import { format } from "date-fns";

Hello there! In this post, I want to share with you the tools that I have been using on my workflow and helped me become more productive and efficient. This is a always evolving post, so I'll try to keep track of what has changed through the years and why. Inspired by [Wes Bos's **uses.tech**](https://uses.tech/).

## Applications ⌨️

- **Visual Studio code**. My main app for software development and anything related. My VSCode configuration in terms on theme, font and extensions changes a lot dependending on what I've been studying/doing lately. Here's my current setup:
  - **Editor font**: [Input](https://input.djr.com/download/). It doesn't support font ligatures but it's something that I've stopped using lately, since it confuses some explanations on my classes (arrow functions, for example).
  - **Theme**: [Aura Soft Dark (Soft Text)](https://marketplace.visualstudio.com/items?itemName=DaltonMenezes.aura-theme#:~:text=Open%20the%20Extensions%20sidebar%20in%20VS%20Code%20Search,Preferences%3A%20Color%20Theme%20and%20choose%20an%20Aura%20variant)
  - **Extensions**: CodeSnap. Image Preview. Import Cost. Jest. Jest Snippets. Live Server. Markdown All In One. Prettier. Rainbow CSV. Template String Converter. Wakatime.
- **Spotify**. My main music app since 2014, I hate the podcast section inside the app but I still use it anyway. Check [my playlists](https://open.spotify.com/user/diogodmoreira?si=ec78266e7ccf4268).
- **Intellij IDEA Ultimate**. Since I work as a professor, I have a license to use the Ultimate version of Intellij IDEA, and honestly, it's by far the best IDE to work with Java related technologies/frameworks such as Spring Boot.
- **Insomnia**/Postman. I've used Postman a lot before, however, Insomnia is managing to meet all my needs lately, I can't give a specific reason for switching.
- **iTerm2 w/ ZSH + [Oh-my-ZSH](https://ohmyz.sh/)**. On top of this configuration, I'm using [Powerlevel10k](https://github.com/romkatv/powerlevel10k).
- **Notion**.
- **Slack**.
- **DBeaver**.
- **Microsoft Edge**.
- **Homebrew**.
- [**JQ**](https://github.com/jqlang/jq).
- **1Password**.
- **Karabiner-Elements**.
- **Magnet**.

## Academic Stuff 👨🏻‍🏫

- [**MacTeX**](https://www.tug.org/mactex/) to compile my LaTeX files edited on [**TeXStudio**](https://www.texstudio.org/).
- **Google Slides**.
- [**Gitbook**](https://gitbook.io).

## Hardware 💻

- Macbook Pro 13-inch, M1, 2020, 16GB
- LG 29UM69G Ultrawide
- iPhone 14
- Apple Watch Series 7
- Logitech MX Master 3
- Keychron K2v2
- HyperX Quadcast

## Gaming 🕹️

- **Nintendo Switch**. Currently playing: **Shin Megami Tensei V**.

- **Other consoles on standby**:
  - Playstation Portable
  - Playstation 3
  - Playstation 4
  - Nintendo 3DS
  - Xbox Series S


Elements of my setup that have enhanced my productivity and efficiency, from hardware to software.

My hardware/software setup


Google Cloud Storage is widely used as a cloud storage service to allow users to store and retrieve objects. When working with Google Cloud Storage, it's essential to write efficient unit tests to ensure that the application behaves as expected.

One common challenge in unit testing is dealing with external dependencies, that's when we use [_mocks_](https://stackoverflow.com/questions/2665812/what-is-mocking) such as Blob Objects from Google Cloud Storage, which may not be readily available during testing or needs to be mocked due to _pricing restrictions_. In this blog post, we will explore how to mock Blob Objects from **Google Cloud Storage** for efficient unit testing.

## A note about mocks

**Mocks** are objects that **simulate the behavior of real objects,** allowing developers to isolate and test specific components of their code.

Suppose you have a class with many dependencies (references to other classes). When you're writing a test for that specific class, you want to make sure that every time this test fails, the feedback should tell something about problems in the class in question. That's why we use mocks, by substituting real dependencies with mock objects, developers can control the behavior and responses of these dependencies, making it easier to create focused and reliable tests

Mocks are particularly useful when testing interactions between different parts of a system, as they help identify and fix bugs or design flaws early on. Additionally, mocks facilitate testing in complex scenarios where certain dependencies may be unavailable or difficult to set up, that's the case in this article.

## Understand Google Cloud Storage objects

Google Cloud Storage offers storage classes and objects for managing data in the cloud. In **Java**, you can use the Google Cloud Storage client library to interact with these features. Here's a brief example of some of them

```java
// Create a storage client
Storage storage = StorageOptions.getDefaultInstance().getService();

// Upload an object to a bucket
BlobId blobId = BlobId.of("my-bucket", "my-object");
BlobInfo blobInfo = BlobInfo.newBuilder(blobId).build();
storage.create(blobInfo, "Hello, Cloud Storage!".getBytes());

// List objects in a bucket
Page<Blob> blobs = storage.list("my-bucket");
for (Blob b : blobs.iterateAll()) {
    System.out.println(b.getName());
}

// Delete an object from a bucket
boolean deleted = storage.delete("my-bucket", "my-object");
if (deleted) {
    System.out.println("Object deleted successfully.");
}
```

So far, we can see that the `storage` object is the one that does most of the job here. And that's the one we should mock in our case.

## Using Google Cloud NIO to mock storage

Google has an in-memory emulator you can use from the Google Cloud NIO. First, we must add the dependency in our `pom.xml`.

```xml
<dependency>
  <groupId>com.google.cloud</groupId>
  <artifactId>google-cloud-nio</artifactId>
  <version>0.126.15</version>
</dependency>
```

Or if you use Gradle.

```javascript
implementation 'com.google.cloud:google-cloud-nio:0.126.15'
```

And then, during our tests, we can use the `LocalStorageHelper` object to create a _fake_ storage to mock Google Cloud.

```javascript
Storage storage = LocalStorageHelper.getOptions().getService();
```

From now on, we can keep using storage to create the files inside the buckets and download them in the same way we'll do in the production code.

```javascript
BlobInfo blobInfo = BlobInfo.newBuilder(BlobId.of("my-mock-bucket", "my-mock-object")).build();
storage.create(blobInfo, "A file text".getBytes());

// Later, we can 'download' this file to do what is expected from our application.
Blob blob = storage.get("my-mock-bucket", "my-mock-object");
byte[] content = blob.getContent();
System.out.println(new String(content));
```

If you're writing an application on top of Spring Boot, for example, you can also create a configuration class for your tests to "overwrite" the default **Storage** object that is created by default.

```javascript
@TestConfiguration
public class CloudStorageConfiguration {

    @Bean
    public Storage createMockStorage()) throws IOException {
        Storage storage = LocalStorageHelper.getOptions().getService();
        BlobInfo blobInfo = BlobInfo.newBuilder(BlobId.of("my-mock-bucket", "my-mock-object")).build();
        // Create some file that you want to use and reflect the
        // one you expect from your Cloud Storage bucket
        storage.create(blobInfo, Files.readAllBytes(Path.of("src", "test", "resources", "test-resource.txt")));
        return storage;
    }

}
```

And that's it. Hope this short post added value to your learning and help you with testing your Java application that has some integration with **Google Cloud Storage**.

Any feedback or suggestions are welcome.


Google Cloud Storage is widely used as a cloud storage service to allow users to store and retrieve objects. When working with it, it's essential to write efficient unit tests to ensure that the application behaves as expected. In this post, we'll going to create mocks that simulates Google Storage objects.

Mocking Google Cloud Storage Blob Objects


> 💡 **tl/dr**; Você pode configurar um novo sistema usando **dotfiles** e um script de instalação em minutos. Esse post explica um pouco sobre dotfiles e aos poucos iremos construir um repositório

**Dotfiles** são arquivos de configuração normalmente armazenados no diretório inicial de um usuário (o diretório representado pelo símbolo `~` em sistemas operacionais baseados em Unix) e que começam com um ponto (`.`) em seu nome de arquivo.

Esses arquivos são usados para **armazenar** configurações para os vários programas e ferramentas que um usuário pode usar em seu sistema. Arquivos como `.bashrc`, `.zshrc`, `.vimrc` e `.gitconfig` são exemplos (apenas para citar alguns) que praticamente todo usuário tem em sua máquina.

Faça um teste na sua máquina e execute o seguinte comando para visualizar apenas alguns dos dotfiles que estão no diretório do seu usuário.

```bash
find ~ -type f -iname ".*" -maxdepth 1
```

Por exemplo, o arquivo `.bashrc` é um arquivo de configuração para o shell **[Bash](https://www.gnu.org/software/bash/)** (uma interface de linha de comando popular para sistemas do tipo Unix). Ele pode conter configurações como o **prompt exibido** quando o shell é aberto, **aliases** (ou atalhos) para comandos usados com frequência e funções personalizadas. Outro exemplo é o arquivo `.vimrc` é um arquivo de configuração para o editor de texto **Vim** e pode conter configurações como o esquema de cores a ser usado, o formato da linha e atalhos de teclado personalizados.

Nesse post, falaremos um pouco sobre como começar o seu versionamento de dotfiles, o que versionar, as boas práticas, questões de segurança e compartilharei com vocês a minha própria versão de **dotfiles**

## Por que isso é importante?

Muitos usuários optam por gerenciar seus **dotfiles** usando sistemas de controle de versão, como o **Git**, para que possam acompanhar as alterações em suas configurações ao longo do tempo e sincronizar facilmente suas configurações ao iniciar um novo ambiente de desenvolvimento em uma nova máquina.

Imagine que sua máquina de desenvolvimento, seja ela usada para estudos ou para trabalho, apresenta um problema que lhe impede de continuar usando o sistema. Independente do motivo, “consertar” esse problema geralmente envolve uma nova instalação de SO e todo o trabalho para reconfigurar um ambiente de desenvolvimento a partir do zero. Essa nova instalação certamente terá uma infinidade de detalhes que você geralmente configura aos poucos, ao longo do seu tempo de uso, coisas como **cor do seu terminal**, **fonte do seu editor de texto**, etc.

O objetivo de versionar os seus **dotfiles** é ganhar tempo com esse processo e manter um ambiente de desenvolvimento com suas mudanças ao longo do tempo, podendo retornar a configurações antigas caso algo dê errado durante uma alteração ou simplesmente haja a necessidade de reconfigurar o ambiente em uma instalação limpa do seu SO.


🪴 Notes

My hardware/software setup

Mocking Google Cloud Storage Blob Objects

Versionando .dotfiles