But it doesn't look messy if you create a specific directory for saving all the screenshots and your MacBook saves all the screenshots there automatically.

Configuring the settings might seem tricky for new MacBook users. So I will show you how you can do this within a few minutes with this step-by-step guide.

Keep in mind that although I am choosing the Pictures/Screenshots directory as my specific directory for saving all my screenshots, you can choose any directory you want.

For this article, I am using my newly purchased MacBook M1 Air (8/256) which is currently running on macOS Sonoma 14.4.1. But the same procedure is applicable for all the latest macOS versions as well.

A messy desktop full of screenshots :( (Source: Internet)

How to Choose a Different Location

Firstly, you need to select a specific location where you want to save all the screenshots directly.

In my case, I created a separate folder for saving screenshots inside my "Pictures" directory.

Directory where I want to save the screenshots automatically

How to Configure the Screenshot Tool

Now we need to configure the default screenshot tool on macOS so that it automatically saves the screenshot images to our desired location. Here's how you can do that:

1. Use Shift + Command + 5 to open the screenshot tool.
2. Click on "Options". Then click "Other Location...".
3. Select that specific location that you created earlier.
4. Now click "Ok", or "Open", or whatever it says to confirm that new location.

Screenshot tool's options. I captured it using my phone. :)

That's it! From now on, whenever you use the default screenshot tool, it will automatically save all the screenshots in that newly specified location. This will help your desktop remain clutter free!

Screenshot Shortcut

There are many people who still open the Screenshot tool using Spotlight or the launchpad. But there is a dedicated shortcut key for that!

You can use Shift + Command + 3 to take screenshot directly and save yourself a little time.

Conclusion

I hope you have learned something new from this article.

If you have enjoyed the procedures step-by-step, then don't forget to let me know on Twitter/X or LinkedIn. I would appreciate it if you could endorse me for some relevant skillsets on LinkedIn.

You can follow me on GitHub as well if you are interested in open source. Make sure to check my website (https://fahimbinamin.com/) as well.

Thank you so much! 😀

Cover image: Photo by Iewek Gnos on Unsplash

If you want your application to have this functionality, you'd usually have to build your server and its logic. But we now live in an age of technological innovation, and tools have been created to help you minimize your development time.

This tool is called Firebase Remote Config — a cloud service that enables you change different functionalities of your app without releasing updates or asking users to update the app.

Overview

You can access the Remote Config feature in your project’s Firebase console. It is usually under the Release & Monitor section on the left sidebar.

There are two ways in which you can define your remote configurations:

1. Using Firebase.
2. Using a template file that is in JSON format.

We will focus on the first option, as the second option is a less intuitive approach.

Firebase Remote Config lets you define one or more keys during configuration. Keys can be of the following type:

• String
• Number
• Boolean
• JSON

These keys are used as the configurations for your application. For example, if you have a feature in your application that you would like to control through remote configurations, you could define a Boolean key titled enableFeatureX.

Each key you set has a few other settings that may be useful to you. For example, you can define a default value for a key (for example, false can be the default value of a Boolean key) or make it use a value that you have defined in your application.

Another cool thing you can do, by clicking on the Add new button in the image above, is to set the value of a key based on certain factors. You'll see these options when you click on the button:

• Conditional value.
• Experiment.
• Personalization.

Once you are done adding a key, make sure to publish your changes so they will be deployed.

The Conditional Value Option

You can configure how a value will be set to specific users based on various conditions.

Here, you can decide on what you want to test and how. You will discover several options when you click on the “Applies if” dropdown.

To illustrate the use of this feature, let’s say that you want to target iOS users in the US. You can do that using the “Applies if” dropdown and choosing Platform and then iOS.

After that, you can press the "and" button to add a condition for Country/Region and choose United States.

Make sure to also name your condition, otherwise, the Create condition button won’t be enabled.

Notice how the last field in defining a new condition window tells you how many users will be affected by this condition? That's a pretty cool feature.

The Experiment Option

This option lets you change the behavior of a value in your remote configurations before taking effect on all your users.

You can follow these steps to configure the experiment option:

• In the first step, you have to fill in the name and description of your experiment.
• Then, you have choose which application to target and how many users will be affected (percentage-wise) in the second step.
• The third step is to set up the metrics to measure this experiment. There are two types — the primary metrics and additional metrics.
• Lastly, you can decide on the number of A/B test groups for this experiment.

The Personalization Option

Last but not least is the option to tailor a specific value of your remote configurations to a user based on their own behavior.

You can define values the algorithm may supply to the user based on their behavior. These will be chosen by an objective you define (Step 2). This objective can range from the engagement time of the user to the amount of clicks they perform. In Step 3, you define a condition that will target users so that they will become personalized. Lastly, in Step 4, you add the name and description of this personalization.

Each option has much more to offer than what I have described here, so if you want to learn more, you can use one of the reference links at the bottom. Now that we understand what Remote Config is, let’s see how we can add it to our application.

How to Setup Firebase Remote Config

Before you can do anything related to applying remote configurations, you need to make sure you've added Firebase to your Android project. This has been documented here.

After you have done that, follow these steps:

Step #1 - Add the Firebase remote configuration library to your project inside your application build.gradle file

 implementation 'com.google.firebase:firebase-config-ktx'

There is an option to also import the Firebase Analytics module, but it is not required for remote configurations. It is used in other areas of remote configurations, such as defining a condition based on a specific event happening.

Step #2 - Use the RemoteConfig Object

After syncing your project, you can access the RemoteConfig object with this command:

val remoteConfig: FirebaseRemoteConfig = Firebase.remoteConfig

Step #3 - Define fetch interval

You can define how often your remote configurations will be fetched and updated. When you are still developing your application, setting this number to be relatively low is more ideal.

val remoteConfigSettings = remoteConfigSettings {                             minimumFetchIntervalInSeconds = 2000
}

If you set the **minimumFetchIntervalInSeconds** to be too low, Firebase will throw a FirebaseRemoteConfigFetchThrottledException, so use a low number only when you are testing things.

Step #4 - Set the configuration for the remote configuration

You can set the remote configuration using the code below:

remoteConfig.setConfigSettingsAsync(remoteConfigSettings)

Step #5 - Set default values

You can have application default values for your remote configurations. These can be created as an XML file inside the XML directory inside the res folder. Here’s what the code looks like:

:remoteConfig.setDefaultsAsync(R.xml.remote_config_defaults)

This XML file must have an underlying element of a map to wrap all your default values. For example, let’s imagine we have defined a key in remote configurations called my_key, whose value is 1. The XML for the default values will look like this:

<?xml version="1.0" encoding="utf-8"?>
<defaultsMap>
   <entry>      
      <key>my_key</key>     
      <value>1</value>   
    </entry>
</defaultsMap>

Remote configurations need to be fetched and activated. The fetch action fetches and stores your Remote Configurations inside the Remote Config object. The activation part is to make these values available to your application. That’s why there are two API methods:

• fetch (and later use activate)

remoteConfig.fetch().addOnCompleteListener { task ->               if                if (task.isSuccessful) {     
              //Remote Configurations fetch successfully          
           }         
        }.addOnFailureListener { error ->             
                //Remote Configurations fetch failure            
       }
-------------------------
remoteConfig.activate().addOnCompleteListener { task ->  
if (task.isSuccessful) {
        //Remote Configurations activation success   
        }  
   }.addOnFailureListener { error -> 
               //Remote Configurations activation failure
  }

• fetchAndActivate

remoteConfig.fetchAndActivate().addOnCompleteListener { task ->                                if (task.isSuccessful) {     
                //Remote Configurations fetched and activated successfully                }        
       }.addOnFailureListener { error ->           
       //Remote Configurations fetched and activated failure    
     }

Step #6 - Access configurations

Now that our remote configurations have been fetched and activated, we can access and use them in our application. We can do so by accessing the remoteConfig object and using one of the getter methods per the type of the value we set:

val myRemoteConfigValue: String = remoteConfig.getString("my_key")

Conclusion

Since your application will rely on remote configurations for its operation (or parts of it), it is crucial to decide how the application will behave if it does not arrive or takes too long to receive a response.

In essence, there are two ways to handle loading the remote configurations:

1. Your application boots up and waits for the remote configurations to be activated.
2. Your application boots up and does not wait for the remote configuration to be activated. Opting instead to use the remote configurations on the second application run.

It's important to understand that there is no option that is preferable over the other. It all depends on what your use case is and how you would like the user's experience to be when using your application. The first option guarantees that once your application is loaded, all the remote configurations that you have defined will be set and the user's experience will be smooth after the initial load time. If you have critical features that rely on the remote configurations, you will have to go with this option.

On the other hand, if your remote configurations concern a specific feature of your application that doesn't necessarily need to happen on the first initial launch, you might consider going for second option. That way, your application does not need to wait for the remote configurations to be received from Firebase and the logic inside your application can happen later.

There are good and bad implications for each of these methods, and it’s up to you to decide which is better suited for your application. If you choose the first option, you may add a loading screen that times out after a certain period. If you choose option two, it is recommended to create a default mechanism for features in your application and how they should work when the configuration has not yet been received.

There is more than we have discussed in this article, and I encourage you to investigate deeper things. I recently used Firebase Remote Configurations in an application I created that helps users schedule appointments.

You can check it out on the Google Play store.

And you can see the source code here:

If you want to read other articles I have written, you can find them below:

References

• Getting Started With Firebase For Android
• Remote Config Use Cases
• Remote Config Loading Strategies
• Remote Config Personalization

If you have both Apple and Windows devices, you might want to share files between them over a local network. And this is what Apple's Bonjour service makes happen under the hood.

In this guide, I will take you through what Bonjour is and how you can get it running on your Windows 10 computer.

What is Apple's Bonjour Program?

Bonjour is Apple's implementation of zero-configuration networking (zeroconf). It allows devices running both Windows and Apple operating systems (like macOS and iOS) to connect and share resources without any configuration settings.

With Bonjour, you can locate other devices such as scanners and printers on a local network and connect with them. You can also share files irrespective of the operating system you are using, whether it's Windows, macOS, or Linux.

How Bonjour Works on a Computer

Bonjour is not a regular software product. Unlike other software and apps, you don't get to use Bonjour directly.

Instead, Bonjour runs in the background and connects devices together by using a "link addressing scheme", which automatically assigns IP addresses to devices on a local network.

Examples of apps that use Bonjour include iTunes, Skype, iChat, and iPhoto.

How to Get Bonjour Up and Running on Windows 10

Unlike Apple devices which work hand in hand with Bonjour, you might have to manually install Bonjour on your Windows 10 computer.

Bonjour is not available to be downloaded as a standalone app, so you'll need to download an app that uses it.

It used to come attached with Mac apps such as iTunes and the Safari browser in a zip folder, but these days, the iTunes app may download it for you over a WiFi network.

However, you can install Bonjour for your Windows 10 computer by downloading the Bonjour SDK (Software Development Kit) from the Apple Developer Website.

Make sure you select Bonjour SDK for Windows as shown below:

Once you do that, you will have to sign in with your Apple ID. If you don't have one, you can create it.

When you sign in successfully, you will be presented with different versions of Bonjour SDK. Download the one you want and install it by opening up the installer and following the prompts.

When the Bonjour SDK gets installed, the Bonjour program gets installed with it as well.

Do you need Bonjour on your Windows 10 computer?

If you use an app that depends on Bonjour to run on a Windows computer, you definitely need Bonjour for the app to function effectively.

In addition, if you use devices that cut across multiple operating systems such as macOS, Windows, and Linux, you might need to connect them together to share resources such as files and devices – and you'll need Bonjour for that to happen. This will also give you the advantage of zero-configuration.

Lastly, if you don't use an Apple device like a Mac but you have friends who do, you should consider getting Bonjour installed on your device, so you can share files and other resources with them.

How to Stop or Uninstall Bonjour on Windows 10

If you stop using an app that depends on Bonjour to work, or you want to say goodbye for any other reason, you might want to stop Bonjour. You can do this from the Task Manager.

Step 1: Click on Start, or press the WIN (Windows) key on your keyboard.

Step 2: Search for "task manager" and hit ENTER.

Step 3: Click on the Services tab. Here you will see Bonjour Service, which is sometimes available as "mDNSResponder.exe".

Step 4: Right-click on it and select “Stop”.

To uninstall Bonjour, you can do it in the Settings app.

Step 1: Click on Start, or press the WIN (Windows) key on your keyboard, and Select Settings to open the Settings app.

Step 2: Select Apps.

Step 3: On the Apps & Features tab, scroll till you find Bonjour, or search for it.

Step 4: Select uninstall, and again, uninstall.

Please note that to get rid of the Bonjour service totally, you might have to uninstall the app using it as well. If you installed Bonjour through the Bonjour SDK, make sure you uninstall the Bonjour SDK as well.

Conclusion

Bonjour is a useful service that gives you more flexibility if you work with devices that use multiple operating systems.

This guide showed youß what the Bonjour service is, what it does, and how you can have more control over it on your Windows 10 computer.

Thank you for reading. If you find this article helpful, please share it with your friends and family.

Configuration is an essential part of every application. It helps enhance an application's flexibility and maintainability.

With this in mind, it's very important that developers are able to correctly identify what items should be in configuration.

In this article, I'll walk you through 8 items that should be configurable in your applications.

Define "Configuration"

We will not be aligning with any existing platforms out there.

For the context of this article, an application configuration has the following characteristics:

• A set of simple or complex values that can affect an application's behavior
• Values can easily be changed without requiring any code deployment

With that out of the way, let's go to our list!

The "Configurables"

Here are the 8 items that should be configurable in your applications.

Magic Numbers

These are special numbers that are used in certain displays, validations, or business rules.

Examples:

• Number of days before an SLA (Service Level Agreement) is breached
• Number of decimal places when rendering a currency

URLs

When connecting to 3rd-party services, there's no knowing when their URLs will change. It's best to keep these values configurable. Additionally, configurable URLs can help you control the value in different environments.

Examples:

• API Endpoints
• External websites

Feature Toggle

This is helpful when there is a feature that's already in production, but which can only be enabled after a certain time.

An example of this is a feature that can only be enabled after a live stream event. Normally, this can be a Boolean value, but you can also use Date Time for this. This just means that the feature will automatically be enabled once that time has passed.

Regex Patterns

Some Regex patterns, especially those used in validation, have the potential to change regularly.

An example of this is phone number validation. Initially, your application might allow phone numbers from several countries. Then, perhaps a change in requirements came about where you now have to allow only phone numbers from specific countries.

If your validation pattern is in configuration, then you can quickly make this change.

Special Dates

Not the romantic ones! In some applications, there's a need to "block" certain dates from being selected by users.

A perfect example of this are public holidays. Since these dates can change regularly, they should be placed in configuration.

Connection Strings

Database connection strings should never be placed in your code! When you place connection strings in configuration, you'll also be able to set a different value per environment.

Formulas

For finance-related applications, making formulas configurable is very important. For these type of applications, adapting to policy or regulatory changes as soon as possible is a must.

Special Messages

This may be more applicable to non-CMS applications. In some cases, the regular changes in text messages are tied to legal or regulatory policies. Therefore, these messages should be easy to update.

A good example of this is an announcement that shows whether the application is currently facing any issues or is under maintenance.

Conclusion

These are the 8 items that I believe should be configurable in every application. I'm sure you have other items on your mind. Let me know! Looking forward to hearing from you.

Glad you reached the end of this article. I hope you learned something new from me today.

_Cover photo from Unsplash_

EditorConfig on its own is just a vendor-agnostic configuration file. It relies on third-party tools or integrations to implement support for the rules declared in the file.

They can be read by IDEs (Integrated Development Environments), code editors, or build tools to enforce or apply formatting conventions.

What Does EditorConfig Solve?

Users usually configure the code style settings in an editor to their preferences. Unfortunately, their preferences probably don't correlate with yours.

What happens when they're contributing to a shared project? This might be a project at work, or an open-source project on GitLab or GitHub.

The user's style settings get applied to the files they modify. This can result in projects feeling inconsistent or messy, with some or all of the following issues:

• Mixed use of tabs and spaces.

• Mixed use of line endings. (Usually not a significant issue with Git.)

• Files may not have the desired character encoding.

• Various indentation sizes across files.

Without consistency, the code can appear untidy and be a pain to read, depending on a user's development environment.

eclipse.jdt.ls mixes tabs and spaces, here's how it looks on GitHub with a tab size of 8.

A common solution is to share editor settings as part of the project, but this assumes all committers are using the same editor as you, which probably isn't the case.

For Java development alone, the following are all popular choices:

• Visual Studio Code (What I use!)

• Eclipse

• IntelliJ

• NetBeans

You'll bloat your project with unrelated files if you add the configuration for every editor someone might use.

So, how about a vendor-agnostic solution where editors are responsible for utilizing a shared configuration instead?

How EditorConfig Helps

Defining conventions helps everyone throughout a project's life-cycle. There are namely three ways it saves time.

EditorConfig Makes Code More Readable

Making code more readable is by far the most important reason to use it. This improves the maintainability of the project, and the speed that people can work.

“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code… Therefore, making it easy to read makes it easier to write.”
― Robert C. Martin

There are many other reasons someone might be reading the code outside of development too:

• Researchers that need to better understand how the project works.

• Security analysts that are checking for vulnerabilities.

• Technical writers that are documenting application behavior.

People will be able to perform their role more effectively if your code is kept tidy, consistent, and human-readable.

EditorConfig Makes Code Reviews Easier

As a project maintainer, you'll inevitably have to review code contributed by others. They might be a fellow team member, or open-source contributors that discover your project.

Enforcing formatting should be delegated to software. This will make reading and reviewing the code more efficient, and avoids the need to request changes based on formatting.

Reducing the feedback loop ultimately saves everyone time.

EditorConfig Makes Development Easier

Developers can save a lot of headache by having conventions that are automatically applied by their editor.

Without it, they have to find a contribution guide, style guide, or check other code manually to learn project conventions.

Even when the conventions are known, they may conflict with a developer's settings. Then they'll have to code against the editor's automatic formatting, or frequently change settings between projects.

This is especially useful for developers that jump between projects a lot. For example, open-source contributors frequently write code for projects across organizations that follow different coding conventions.

How EditorConfig Works

EditorConfig uses a simple INI-like file named .editorconfig. This file declares rules that will be translated to settings in your editor, or perform formatting over your workspace.

For example, in my editor I use 2-space indentations for XML files, but a project I contribute to might prefer 4-space indentations.

[*.xml]
indent_size = 4

When I open the project, my editor will see the .editorconfig file, and override the settings to suit the project's conventions.

Writing an XML file with my default editor settings. I use spaces for indentation with a size of 2.

Automatically reformatting the file after overriding the XML formatting settings.

How to Use EditorConfig

Depending on your editor of choice, it may have native support for EditorConfig already. There is a list of "No Plugin Necessary" editors on the website, which includes JetBrains IDEs and Visual Studio.

If your editor doesn't have native support, you'll likely be able to add it with a plugin. Editors like Visual Studio Code and Eclipse support it this way, which can also be found on the EditorConfig website under "Download a Plugin".

Once installed, your editor should automatically find the EditorConfig file in your project if it exists, and start applying the rules.

How to Define Rules in EditorConfig

You can find a list of rules on the EditorConfig Wiki. It contains all officially supported rules, as well as proposals for domain-specific rules that may be supported by certain implementations.

Not all implementations support every rule. This is especially true for domain-specific rules like curly_bracket_next_line. It can still be worth declaring these properties anyway for users that can utilize it, or to at least document the preference.

You must set root to true for the top level EditorConfig in the project, which is normally in the root of your project directory.

Additional EditorConfig files can be defined in nested directories, but shouldn't set root to true.

Then you can define a header that selects files, with rules for what to apply to matching files.

# Declares that this is the top-level configuration
root = true

# Applies to all files
[*]
indent_style = space
indent_size = 2

# Applies to all Markdown files
[*.md]
trim_trailing_whitespace = false

# Applies to all C# and Java files, overriding rules declared before
[*.{cs,java}]
indent_size = 4

There are no standard conventions for how to write an .editorconfig file, but there are two notable approaches you can take.

Define Rules Per Project

Just add to it as you need to. This means just defining rules, or appending file formats as your project grows.

You can start by generating the file with your editor, or just create a file named .editorconfig manually. You can copy-and-paste the example from the official website.

Define Rules for All Projects

Alternatively, you can put together all of your preferences and plan the ideal configuration for all files you might interact with.

You can work from scratch, or start with mine and make the necessary adjustments.

root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
curly_bracket_next_line = false
spaces_around_operators = true

[*.bat]
end_of_line = crlf

[*.cs]
curly_bracket_next_line = true

[*.{cpp,cs,gradle,java,kt,py,rs}]
indent_size = 4

[*.{js,ts}]
quote_type = single

[*.md]
trim_trailing_whitespace = false

[*.tsv]
indent_style = tab

EditorConfig Rule Recommendations

These are rules I'd objectively recommend declaring, if your project contains the respective file format. It'll help you avoid tedious issues that can occur due to a user's development environment.

Batch

Line endings need to have a textual representation when stored. This is usually something you wouldn't see or have to worry about.

However, different systems use different characters to represent the end of a line. (More Info)

• Unix systems use a line feed. (lf or \n)

• Windows uses a carriage return and line feed. (crlf or \r\n)

Batch files can have unexpected behavior if they end with Unix line endings. You can avoid this by setting end_of_line to crlf to ensure they have Windows line endings instead. (More Info)

[*.bat]
end_of_line = crlf

Markdown

In Markdown, you can write a line break in the current paragraph by adding 2 spaces at the end of a line. (More Info)

You'll want to set trim_trailing_whitespace to false to avoid having your editor remove those spaces when you save.

[*.md]
trim_trailing_whitespace = false

Tab Separated Values

TSV (Tab Separated Values) files are very similar to CSV (Comma Separated Values), but use tabs instead of commas as the column delimiter.

It's very common for developers to have tabs automatically convert to spaces. You should set indent_style to tab to avoid the delimiter from being replaced, otherwise your entire table might become a single column.

[*.tsv]
indent_style = tab

Conclusion

If you're a maintainer, either working in a collaborative environment or in open-source, I strongly recommend adding an .editorconfig file defining the project's conventions to the root of your repository.

Maintainers can then spend more time reviewing clean pull requests that adhere to the style guide, as the editor will automatically start enforcing or applying the conventions.

Committers get a better experience, as the project will override their workspace settings. This reduces the need to reformat code or work against preconfigured editor settings.

And projects will be cleaner, as the conventions will be in a single vendor-agnostic file, rather than editor-specific files that only certain contributors can use anyway.

You might have a hard time managing many cats, but when it comes to Git profiles there is something you can do.

Let's get straight to the solution – The answer lies in the .gitconfig file. This is starter point for Git to identify what configurations need to be used.

The idea is to segregate the repos on your machine into multiple directories by separating the profiles you want, and then define a .gitconfig file per profile.

Step 1 → create separate directories for repos

Organize the projects that you are working on into separate folders by the profiles you want to work with.

For example let's say there are two Git profiles you are working with. This is a common use case for most of us:

• WORK → for work related projects
• PERSONAL → for open source and side projects

Step 2 → create a global Git configuration

Create the global .gitconfig file in your home directory if it doesn't already exist. Then add all the profile directories as an entry like in the example below.

The way this works is very intuitive – if the directory path where you created the Git directory matches one of the paths in includeIF, then Git uses that particular profile configuration file. Otherwise, it uses the default configuration.

[includeIf "gitdir:~/personal/"]
  path = ~/.gitconfig-personal
[includeIf "gitdir:~/work/"]
  path = ~/.gitconfig-work

Step 3 → create individual Git configurations for profiles

If you haven't noticed by now, we just mentioned the .gitconfig-personal and .gitconfig-work files in the global .gitconfig file, but we didn't create them yet. These individual files can contain all the customization that you need, from user name and email to commit hooks.

[user]
 name = work_user
 email = work_email

[user]
 name = personal_user
 email = personal_email

Let's verify

We're all set! Now you will have three Git files in your home directory.

Now we will create and initiate a new Git repo in the work and personal directories and check the configurations.

$ cd ~/work
$ mkdir work-test-repo
$ cd work-test-repo
$ git init
        *Initialized empty Git repository in /Users/dbarochiya/work/work-test-repo/.git/*
$ git config -l   
        *credential.helper=osxkeychain
        includeif.gitdir:~/personal/.path=~/.gitconfig-personal
        includeif.gitdir:~/work/.path=~/.gitconfig-work
        **user.name=working_me
        user.email = work@work.com**
        core.repositoryformatversion=0
        core.filemode=true
        core.bare=false
        core.logallrefupdates=true
        core.ignorecase=true
        core.precomposeunicode=true*                                                                                                                   1

$ cd ~/personal
$ mkdir personal-test-repo
$ git init
    *Initialized empty Git repository in /Users/dbarochiya/personal/.git/*
$ git config -l
    *credential.helper=osxkeychain
    includeif.gitdir:~/personal/.path=~/.gitconfig-personal
    **user.name=me_personal
    user.email=personal@personal.com**
    includeif.gitdir:~/work/.path=~/.gitconfig-work
    core.repositoryformatversion=0
    core.filemode=true
    core.bare=false
    core.logallrefupdates=true
    core.ignorecase=true
    core.precomposeunicode=true*

Voilà – as you can see, the email and user name are different in both cases. Depending on the path of the Git repo, it is able to use the custom .gitconfig files.

I created this guide because of an experience I had while teaching. My students needed to use an application that was only available on Windows OS but the students only had macOS.

We will be touching on the technologies shown below:

• Amazon EC2: launch a Windows Server 2019
• Microsoft Remote Desktop: macOS application to remote desktop connect (RDP) to EC2

Amazon EC2

Launching a Windows Server EC2 Instance

1. Sign in to your AWS Management Console.
2. Choose Services, then EC2.
3. In the sidebar, click Instances.

EC2 sidebar

4. Click Launch Instance.

Launch Instance button

5. Scroll down and choose Microsoft Windows Server 2019 Base.

Choose AMI page

6. At the bottom of the Choose Instance Type page, click Review and Launch. This will skip you to the Review page.

Launch with minimal configuration

7. In the Review page, click Launch. You'll be prompted to select an existing key pair or new key pair.

If you choose Create a new key pair, you need to give the new key pair a name, then download the key pair. Then you'll be able to proceed to choose Launch Instance.

Key pair to access the instance

If you choose Choose an existing key pair, you need to select a key pair and tick the checkbox to acknowledge the use of the key pair.

Last step to launch instance

8. Click the generated Instance ID.

Accessing the EC2 Instance

9. Find and save the following information:

10. Public DNS (IP Address)

11. Username
12. Password

To get the IP Address, scroll to the right of your EC2 instance:

IP Address of EC2 Instance

You can also find this in the Description tab below:

IP Address of EC2 Instance

10. To get the username and password, choose the EC2 instance (tick the checkbox), click Actions, then Get Windows Password.

Obtaining the username and password

You may encounter Password not available and you'll need to wait a couple of minutes.

Provisioning the auto-generated password

11. Locate the existing key pair or the newly created key pair you have downloaded in your local machine. Click Choose File.

Retrieve the key pair

12. After uploading the key pair, click Decrypt Password.

13. Copy the following information and save it in a file or clipboard. Click Close when you are done.

Information for remote desktop connection

Microsoft Remote Desktop

Installing the application and connecting to EC2 instance

1. Open your App Store, then search for Microsoft Remote Desktop. Click Install (it shows UPDATE here as I already have installed).

Microsoft Remote Desktop in the App Store

2. After installation, Open Microsoft Remote Desktop.

3. At the top, click the + Icon and choose Desktop.

Creating a new desktop connection

4. In the PC name, copy the EC2 Instance IP address, then click Add.

Adding the IP address

5. Copy the Administrator and Password from earlier and paste it here. Hit Continue.

Signing in with the username and password

You are now connected to your Windows Server EC2 Instance.

Windows Server EC2 Instance

Note: To avoid getting charged after you have used up the free tier for EC2, either click Stop to have a lower cost, or Terminate to remove the instance and not be charged.

You have access to this by selecting the instance and choosing Actions > Instance State > Stop/Terminate.

Here's a video tutorial:

Connect with me on LinkedIn here.