DEV Community: Shubham

Wear OS apps with Flutter (4/4): Publishing & Getting Approved on the Play Store

Shubham — Sat, 16 Aug 2025 10:00:00 +0000

Publishing

In the Play Store Console, we need to add 'Wear OS' as a form factor of our app – until we do this, there will be no way to actually upload Wear OS screenshots or the actual Wear OS app! To do this, go to the "Test and Release" > "Advanced Settings" section from the left-navbar. On this page there will be a "Form factors" tab, from which you can choose "Add form factor" and choose Wear OS:

After this, you will also need to enrol and accept the Wear OS program conditions, which should appear after selecting the form factor.

Once all that's done, publishing a Wear OS app is just like any other Android app: go to "Test and Release", choose the appropriate track (e.g., "Production") and click "Create new release" (make sure you've chosen "Wear OS only" next to the button):

From here, you can upload an App Bundle which you must first build using flutter build appbundle and continue the steps to submit for review. Finally, you'll see a "Changed in review" screen like this:

The Google Play Console will run some automated checks to find 'common' issues that can be fixed before sending for manual review. This could potentially save days of review time if there's something they detect as being obviously wrong. However, I found it didn't quite detect everything you might expect would be easily identifiable (see below for more details).

Getting approved

There are some relatively strict review guidelines for Wear OS apps which you need to satisfy before your app can be approved and published for end-users. I share some of the key ones that caught me out in this post.

Rejection #1: Play Store listing

Your play listing description doesn't mention Wear OS.

You must mention "Wear OS" in your Play Store listing's description. Not "WearOS", not "Android Wear' – otherwise, your app will likely be rejected and you'll have to go through the review process (which took 2-5 days each time for me!).

The Google Play Console does have a series of automated checks they perform before sending it off for human review, so it seems like something that could easily be automated, but it wasn't in my case!

Rejection #2: Custom font sizes

Your app must conform to the font size set by the user in System Settings. If the user selects a larger font size, ensure that text and controls are not cut off by screen edges.

You must respect and adjust according to the *font size *set on the device. I found this tricky to solve initially, because it was physically impossible to show the same content when the font is larger because everything takes up so much more space!

In the end, I had to come to terms with showing less information on some screen sizes/font sizes.

Screen sizes

Another useful guideline to call out is the screen size requirement. These days, it's already quite common for developers to test their apps on different devices and screen sizes (e.g., in web development, but even in Android app development it's becoming more important with different phones having different constraints like notches).

The same goes for a Wear OS app, but is perhaps more important because the screen sizes are already so small! At a minimum, you should aim to test your app and UI fully on the 2 Wear OS emulators supported by Google: "Wear OS small round 1.2 inch (192dp)" and "Wear OS large round 1.39 inch (227dp)". It could also be useful to try on square devices (although, from what I've seen, it seems most modern Wear OS devices end up being circular).

Splash screen

Your app must have a splash screen. The display requirements are also quite specific: "Use a black window background with the app icon. The app icon must be a 48x48dp circular icon that is positioned in the center of the watch face".

To set up a working splash screen, I used the flutter_native_splash package and set up my config in pubspec.yaml as follows.

flutter_native_splash:
  color: "#000000" # Background color of the splash screen
  image: assets/icon/icon.png # Path to your logo or splash image
  android: true # Enable splash screen for Android
  android_gravity: center # Position of the image on Android (center, bottom, etc.)
  fullscreen: true # Enable full-screen mode (removes the status bar)

Then, you can run dart run flutter_native_splash:create.

I also had to add the following to MainActivity.kt:

import androidx.core.splashscreen.SplashScreen
import androidx.core.splashscreen.SplashScreen.Companion.installSplashScreen
...
override fun onCreate(savedInstanceState: android.os.Bundle?) {
    installSplashScreen()
    super.onCreate(savedInstanceState)
}

and the following to android/app/build.gradle.kts:

dependencies {
    ...
    implementation("androidx.core:core-splashscreen:1.2.0-beta02")
}

After the above configurations, my splash screen loaded successfully!

Wear OS apps with Flutter (3/4): Using Platform Channels to implement custom functionality (location & user text input)

Shubham — Sat, 09 Aug 2025 10:00:00 +0000

This is part 3 of a series on developing Wear OS apps with Flutter.
Check out part 1 for an introduction to Wear OS and common design guidelines and part 2 to setup and install your first Wear OS app!

Wear OS support in existing Flutter packages is limited. For example, if you want to get the device's location, the most common ways tend to be to install a package like locationor geolocator. However, both of these currently have known issues or incompatibilities with Wear OS.

It's still very easy to implement our own native code that can be called from Flutter, using Platform Channels. With Flutter, it's always easy to rely on these abstractions that are provided for us, but Platform Channels are very useful to understand, because they are actually how all the packages we use are implemented under-the-hood – they just wrap platform-specific native code as a helpful API.

In short, they provide a way for our Flutter code to call some native platform-specific code. That could mean we create, for example, a simple getLocation function which in turn calls some *Kotlin *code on Android devices, some *Swift *code on iOS devices, and so on – all automatically, without us, as the Flutter developer, needing to worry about which device/OS/platform our app is running on.

As we are creating a simplified Wear OS (Android)-only app in this case, we can implement just the Kotlin side of the Platform Channel as an example.

Implementing Platform Channels for Android with Kotlin

There are 2 parts to this: the native Android (Kotlin) side and the Flutter side (our 'app').

In my app, there were 2 times in which I needed to make use of Platform Channels: to implement a getLocation function and a getUserTextInput function (to show the Wear OS keyboard so the user can type some short text).

Getting the device location

Let's start with the Kotlin side of implementing a getLocation function: we need to write the code that will actually be run that uses the Android SDKs, using Kotlin. We need to write this code in the MainActivity.kt file in the android/app/src/main/kotlin/com.mypackage.name directory.

For location specifically, we can make use of the Fused Location Provider (FLP) API. This is ideal for use-cases where we just want to get the current location as a one-off (as opposed to continuously tracking it for activity tracking purposes – see the linked docs for details on how to implement that). FLP will automatically determine the best way to get the current location; for example, it might get the location from the connected phone if that's recent rather than wasting battery to use the watch's GPS.

To use this API, we first need to define it as a dependency in our app – add the following to android/app/build.gradle.kts:

dependencies {
    implementation("com.google.android.gms:play-services-location:21.3.0")
}

Platform Channels are quite simple: we need to override a configureFlutterEngine method and implement a method call handler. The method call handler takes a parameter that is the name of the 'method' we want to create. In our case, we can call it getLocation, and this is what we will call from the Flutter-side too.

The code to implement this might look like something below – remember to update the CHANNEL variable, because this is used to define the 'name' of our Platform Channel.

class MainActivity : FlutterActivity() {
  private val CHANNEL = "com.mypackage.name"

  private lateinit var fusedLocationClient: FusedLocationProviderClient
  fun handleLocationSuccess(location: Location?, result: MethodChannel.Result) {
    location?.let {
      result.success(hashMapOf("latitude" to it.latitude, "longitude" to it.longitude))
    }
            ?: result.error("Failure", null, null)
  }

  fun handleLocationFailure(exception: Exception, result: MethodChannel.Result) {
    println(exception.message)
    result.error("Failure", exception.message, null)
  }

  fun getCurrentLocation(result: MethodChannel.Result) {
    fusedLocationClient = LocationServices.getFusedLocationProviderClient(this)
    fusedLocationClient.flushLocations()

    val priority = LocationRequest.PRIORITY_HIGH_ACCURACY
    val cancellationTokenSource = CancellationTokenSource()
    fusedLocationClient
            .getCurrentLocation(priority, cancellationTokenSource.token)
            .addOnSuccessListener { location: Location? -> handleLocationSuccess(location, result) }
            .addOnFailureListener { exception -> handleLocationFailure(exception, result) }
  }

  override fun configureFlutterEngine(@NonNull flutterEngine: FlutterEngine) {
    super.configureFlutterEngine(flutterEngine)
    MethodChannel(flutterEngine.dartExecutor.binaryMessenger, CHANNEL).setMethodCallHandler {
            call,
            result ->
      if (call.method == "getLocation") {
        getCurrentLocation(result)
      } else {
        result.notImplemented()
      }
    }
  }

}

Finally, we can actually call this code from Flutter like this:

static const platform = MethodChannel('com.mypackage.name');
final coordsResult = await platform.invokeMethod('getLocation');

Now, coordsResult will throw if our Platform Channel called result.error at any time, or return whatever was passed to result.success – in our case, a HashMap of {latitude, longitude}!

Getting user text input via the Wear OS keyboard

In Wear OS, getting user textual input isn't as simple as a normal Flutter app, where you might use a TextField widget. Instead, Wear OS has it's own keyboard and UI for accepting user input – this page might look familiar to you:

I couldn't find a built-in or community-built package to show this screen on Wear OS. But now that we have the base implementation of configureFlutterEngine, it's actually quite trivial to add more methods. We just need to add another else if for more names of our call.method.

The way this would normally be shown in a vanilla native Android app is to call the RemoteInput API. There's more information on the official docs on creating and using input editors in Wear OS too. To use this, we first need to add another dependency to our android/app/build.gradle.kts:

dependencies {
  ...
  implementation("androidx.wear:wear-input:1.2.0-alpha02")
}

Now, we can implement a new getText method in our method handler, like this:

...
} else if (call.method == "getText") {
        val remoteInputs: List<RemoteInput> =
                listOf(RemoteInput.Builder(REMOTE_INPUT_KEY).setLabel("Enter text").build())
        val intent: Intent = RemoteInputIntentHelper.createActionRemoteInputIntent()
        RemoteInputIntentHelper.putRemoteInputsExtra(intent, remoteInputs)
        _inputResult = result
        startActivityForResult(intent, TEXT_INTENT_ID)
} else {
...

This creates an Intent created by the RemoteInput API to display the native input screen. We store the result of the Platform Channel under _inputResult, so that we still have a reference to it when the Intent returns the text entered by the user.

We call startActivityForResult with a 2nd 'request code' parameter TEXT_INTENT_ID, which is an arbitrary number that we can define to uniquely identify the results of different activities in our app. This way, when various activities return, we can identify what each one is. We also define a REMOTE_INPUT_KEY constant for the RemoteInput so that we can extract the text entered later:

  private val TEXT_INTENT_ID = 1
  private val REMOTE_INPUT_KEY = "input"

Now we can listen for the result of the activity as follows, by using the TEXT_INTENT_ID to identify the correct Intent result, and REMOTE_INPUT_KEY to extract the text entered:

  override fun onActivityResult(requestCode: Int, result: Int, intent: Intent?) {
    if (requestCode != TEXT_INTENT_ID) return super.onActivityResult(requestCode, result, intent)

    if (result != Activity.RESULT_OK) {
      _inputResult.error("Error", "Error getting text", "")
      return
    }

    val inputResult = RemoteInput.getResultsFromIntent(intent)
    _inputResult.success(inputResult.getCharSequence(REMOTE_INPUT_KEY))
  }

Finally, we can call our input screen in Flutter just as we did earlier, but invoking the getText method this time!

static const platform = MethodChannel('com.mypackage.name');
final text = await platform.invokeMethod('getText');

text will now contain anything passed to inputResult.success above (in our case, the string contents that the user entered), or throw if we called _inputResult.error!

In the next part, we'll look at how to publish our Wear OS app on the Play Store, with tips on how to pass the Review process!

Wear OS apps with Flutter (2/4): Setting up, designing circular UIs & running on an emulator/device

Shubham — Sun, 03 Aug 2025 15:35:55 +0000

A Wear OS app is just a 'normal' Android app (e.g., a .APK file), but with access to some additional SDKs and functionality specific to the watch hardware.

This is helpful because it means most of the time, you can follow typical Android instructions, including setting up an initial app!

Setting up a template app

Run flutter create wear_os_app in your terminal, or use the Flutter: New Project command in VS Code (Ctrl/Cmd+Shift+P)

This will create a boilerplate 'counter' app in Flutter called wear_os_app. Now we just need to configure a setting to define our Wear OS app as a **standalone **app: edit the manifest file at android\app\src\main\AndroidManifest.xml and insert the following <meta-data> block into the existing <application> block:

<application>
  ...
  <meta-data
    android:name="com.google.android.wearable.standalone"
    android:value="true"
    />
  ...
</application>

You can also optionally install some packages that have been created for Wear OS in Flutter specifically. For example, wear_plus exposes new widgets called AmbientMode and WatchShape that let you detect whether the device is in ambient mode and differentiate between circular/square frames.

Note from 31st August 2025, the minimum target API level for Wear OS apps will be Android 14 (API Level 34). To avoid issues with future updates and Play Store approvals, it's best to change your target level as early as possible. It also gives you a chance to ensure you don't accidentally start to rely on some APIs that are going to be immediately deprecated!

Running the app on an Emulator

We can already run this as a Wear OS App in an Emulator. First, we need to create a Wear OS device emulator in the Android Device Manager: open Android Studio, click "More Actions" > "Virtual Device Manager" > "+" > choose "Wear OS" Form Factor.

Note: if you can't see the "Wear OS" form factor, make sure you are running the "Android Studio Meerkat Feature Drop" version and in "SDK Manager" (under "More Actions" again), ensure you have installed the "Wear OS 5.1 Intel x86_64 Atom System Image" with API Level 35-ext15 (or the version appropriate for your system architecture e.g., ARM):

Finally, we can start the emulator, and run our app in it with flutter run:

As we can see, there's still a bit of work we need to do to optimise it for a smaller circular display, but it works!

Fixing the layout

We can make some initial minor tweaks to make this look better on a smartwatch:

Removing the AppBar. The default counter app comes with a Scaffold and appBar property (which defines the "Flutter Demo Home Page" we see clipped off in the image above). Due to the limited space on smartwatches, we don't usually see this kind of UI element in most apps, and should usually be safe to remove.
Adding padding. On circular devices, the screen is actually clipped around the circumference, which means some content ends up being hidden! Whilst there are some clever methods of wrapping content within a circular container (e.g., see this great Stack Overflow answer: Wrapping text inside a circle (Flutter)), I found that for simpler apps, padding can get you quite far, especially for primarily centered content. For example, wrapping all your content in a Padding with a padding of EdgeInsets.fromLTRB(10, 5, 10, 5) and a Center child avoids needing to touch the borders in most cases!
Changing the FAB (floating action button). By default, the FAB is placed at the bottom right, but the placement and sizing can easily be tweaked with floatingActionButtonLocation. I found that using FloatingActionButtonLocation.miniCenterDocked worked quite well.

What these changes might look like in code:

@override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Padding(
        padding: EdgeInsets.fromLTRB(10, 5, 10, 5),
        child: Center(
          child: Column(
            mainAxisAlignment: MainAxisAlignment.center,
            children: <Widget>[
              const Text(
                'You have pushed the button this many times:',
                textAlign: TextAlign.center,
              ),
              Text(
                '$_counter',
                style: Theme.of(context).textTheme.headlineMedium,
              ),
            ],
          ),
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: 'Increment',
        mini: true,
        child: const Icon(Icons.add),
      ),
      floatingActionButtonLocation:
          FloatingActionButtonLocation.miniCenterDocked,
    );
  }

With just these tweaks we can get to layout that looks like below:

Running the app on an actual Wear OS Smartwatch

If you have a physical smartwatch, it's also easy to run the app on that too! With usual Android phone apps, the most common and straightforward way is to connect a phone via USB. That's not an option for (most) Wear OS devices, but they do support Wireless Debugging (as do most Android phones too).

Enabling 'developer mode' on Wear OS watches is similar to how we do it on Android phones: go to Settings > System *(or *Other) > About (watch) > Versions *(or '*Other version info'), and tap on the 'Build number' seven times. Once done, you'll see a toast message confirming developer mode is activated.

You can now find these settings in Settings *> *System *(or *Other) > Developer Options. From here, you can enable "Wireless debugging" (this requires your watch to be connected to a Wi-Fi network – in my experience, toggling "wireless debugging" on will auto-connect to a saved Wi-Fi network in a few seconds):

You'll be shown your watch's local IP address and a port to connect to.

If you're connecting a computer for the first time, you'll first need to pair it: tap the "Pair new device" button.

Now, you can pair ADB from your computer (on the same Wi-Fi network) – be sure to change the IP address and port as shown on the "pair with device" screen!

adb pair 192.168.68.102:44841

After pairing, or if you've previously paired your computer, you can connect:

adb pair 192.168.68.102:35209

Note that this is a different port to the 'pairing' port! It will also change every time you turn Wireless Debugging on!

I'd recommend turning Wireless Debugging off whenever you finish, to conserve battery on your watch.

Finally, to run your new Wear OS Flutter app on your physical watch, you can use flutter run – you may be prompted to choose which device to run the app on, if you have multiple (e.g., the physical one and emulator).

A note about performance

I found my app seemed to be quite slow when I was developing it and testing it like this. It got me quite worried because I wasn't doing anything super intensive, and I wasn't sure how I could optimise it.

But it turns out it was only slow when it was being built in debug mode – building it for release made the app much snappier. I found the slowness in debug mode was much more compared to the slowness you might expect when developing a typical Android phone app and testing it in debug mode, so this is useful to bear in mind!

Towards the end of this blog series, I will explain how we can build apps in release mode, ready for testing and/or publishing to the Play Store.

In the next part, we'll implement a Platform Channel to use native device functionality that may not be supported in typical Flutter packages (e.g., getting device location, or getting user input)!

Wear OS apps with Flutter (1/4): Introduction

Shubham — Sat, 19 Jul 2025 23:24:59 +0000

I recently published my first Wear OS app, but I found resources around developing smartwatch apps, particularly for Wear OS (Android) to be quite lacking. This series of blog posts will share how you can create full-fledged Wear OS apps using Flutter, that are production-ready and published to Play Store for end-users; I hope it can help others bring their own ideas to life as smartwatch apps, and get an idea of the process involved perhaps even before starting!

Introduction to Wear OS, its design guidelines, and other considerations
Setting up a Flutter Wear OS app, improving the UI for circular screens, and running it on an emulator and/or physical device
Using Platform Channels to replace common Flutter packages which aren't yet compatible with Wear OS
Getting approved and published on the Play Store

Before we start, I do want to call out that whilst Flutter is best known and most useful for creating cross-platform apps, this series assumes we are creating a simple standalone Wear OS app only.

You might question what is the point of creating just a Wear OS app in Flutter, but if Flutter is something you're already comfortable with for Android/iOS/Web apps, it's likely much faster to continue to use Flutter. You can also re-used any brand components and styles with ease, as opposed to migrating to e.g., Kotlin entirely.

Introduction

To start with, here are a few core concepts that are useful to understand before developing a Wear OS app. Some of these might decide the direction in which you decide to go!

Standalone vs non-standalone Wear OS apps

A 'standalone' app is one that can run independently of a connected phone.

This was a little confusing at first, because the majority of Wear OS smartwatches don't have cellular capabilities, so does that mean they are 'dependent' on a connected phone? No – 'dependent' in this context means that all the app's functionality must be able to be completed entirely on the watch without the user interacting with their phone.

For example, if you require users to set up the watch app, or configure settings, through their phone via a companion app, then it is a non-standalone app. Conversely, if you have a settings page within the watch, and the user doesn't need to touch their phone, then you have a *standalone *app.

Crucially, either type of app will still be able to use the connected phone for Internet access – so if your standalone app uses e.g., an online API to surface data to a user, this is fine! And if you're using a watch with cellular capability, then it won't even need to be connected to the phone.

In this blog series, we focus on creating a standalone app.

Internet capabilities

Smartwatches prioritise using Bluetooth Low Energy (BLE) for communication (if you're interested in how BLE works and implementing your own BLE services on e.g., Raspberry Pis, check out my other blog series).

This is because BLE is much less power-hungry than Wi-Fi and Cellular data. This also means that even if your standalone watch app is accessing the Internet, the requests may still be going to and from your phone via Bluetooth (where the phone then connects to the Internet via Wi-Fi/mobile data).

This is something to bear in mind because your watch app might end up having a relatively small bandwidth of ~4KB/s. This can introduce latency, memory, or battery usage.

Ideally, Wear OS apps should be snappy and quick to use, so this can be an important factor if you are trying to do data-intensive things, or even load pictures/icons from the Internet!

Battery

One of the biggest pain points of modern smartwatches is their battery life. The majority are still at ~1 day battery life (save some, like the OnePlus Watch 2 and 3, which I'd highly recommend!).

This means we need to be wary about the resources we use in our app, for example by reducing animation and memory-intensive processes.

The official docs outline many areas to look out for when considering battery usage.

Design

Smartwatch screens are very small, so need to be designed with that in mind. The UI and UX considerations are vastly different to a typical mobile app, such as:

Buttons should have quite a large tap surface
Text should be relatively large and glanceable
Loading times should be minimal (nobody wants to stare at their wrist just waiting for something!)

Another challenge I faced was figuring out exactly how to portray the information I wanted to in such a small screen. Taking into account different screen sizes, and even different font sizes, means that you also need to adapt the information density for different users. That might mean showing one less piece of information, or prioritising functional UI elements over aesthetic ones.

In the next part, we'll set up a sample Flutter project and get it running on a Wear OS device!

Bring the 'jump to search' keyboard shortcut to any site with userscripts

Shubham — Tue, 11 Jul 2023 16:24:09 +0000

Some sites allow you to jump to their search bar using the / key (e.g., Google, GitHub, and many more). However, for sites without such a shortcut (e.g., Gmail, Bing), it can feel quite tedious to have to scroll, find, and click the search bar each time.

The power of userscripts

This is where userscripts come in: some JavaScript code that you can configure to run on any site – and they can be quite powerful! For example, I created and maintain a userscript that adds a bunch of additional optional features to the Stack Exchange network of sites (e.g., Stack Overflow). These can range from simple manipulations like tweaking the colour of an element, to full-fledged features like adding a 'find and replace' function to the post editor.

Userscripts are similar to browser extensions, but they can be much easier and quicker to customise to your liking – creating a userscript can take less than a minute, whereas setting up a full browser extension can take considerably more time, especially if you've never made one before. Userscripts are also inherently open-source, so it is easier to verify the code before you install them!

Userscripts also have some special APIs that let you fetch resources, interact with tabs, save data, and more.

The userscript metadata (header) block

Every userscript must start with a 'header' called the metadata block. This is just a set of JavaScript comments, each starting with a special key-value pair. For example, // @name My Userscript defines the @name key.

The header section must start and end with the special comments // UserScript and // /UserScript respectively.

There are many keys that can be used in the metadata block. One of the most important ones is @match (and also @include – see What is the difference between @include and @match in userscripts?). This lets you specify which page(s) to run a script on.

Interacting with the Document Object Model (DOM)

One of the main things you usually do with a userscript is interact with the Document Object Model (DOM). This represents the HTML page as a tree with nodes that can be manipulated via the JavaScript DOM API.

For example, you can query for elements with Document.querySelector(), change their style by setting the HTMLElement.style property, add event listeners with EventTarget.addEventListener to detect clicks/hovers/etc, and much more!

Bringing the `/` shortcut to any site

With some basic knowledge of the DOM API, we can now easily bring the / shortcut to any site by creating a small userscript:

Install a userscript manager.

Userscript managers let you see all your userscripts in one place, and most have a built-in web editor so you can edit scripts within your browser. Tampermonkey is a popular userscript manager, and is available for almost all browsers.
Create a new userscript.

There will be a new extension button for your userscript manager with an option similar to "Create a new script":
Write your userscript code:

// ==UserScript==
// @name         '/' search bar focus
// @description  Focus search bar on SLASH press
// @version      0.1
// @match        *://*/*
// ==/UserScript==

(function() {
    window.addEventListener("keypress", e => {
        if (['TEXTAREA', 'INPUT'].includes(e.target.nodeName)) return;
        if (e.key !== "/") return;

        const searchField = document.querySelector('textarea[type="search"], input[type="search"], input[name="search"], input[placeholder*="Search"]');
        if (!searchField) return;

        searchField.focus();
        searchField.setSelectionRange(searchField.value.length, searchField.value.length);
        e.preventDefault();
    });
})();

Note how the metadata block uses // @match *://*/*. This is because we want this particular script to run on every page!

After the metadata block, we have our actual code. Tampermonkey by default suggests wrapping your code into an IIFE (Immediately Invoked Function Expression). This is generally a good practice as it means we do not pollute the global namespace with our own variables, functions, etc.

The code adds a keypress event listener to the entire page. If the keypress is already within a textarea or input element, or is not the / key, the handler immediately returns. Otherwise, the first search field is found, focussed, and the cursor is moved to the end.

You can choose how you define a 'search' field, but some common aspects are that they have a type=search or name=search attribute. You can even use some more advanced CSS attribute selectors like [attr*=value] to find elements whose attribute just contains a string (e.g., containing "search" somewhere in the placeholder).

That's it! To test it out, you can try making e.g., a Bing search and pressing the / key – you'll jump straight to the search bar!

How does Linux work?

Shubham — Mon, 20 Sep 2021 18:22:01 +0000

I recently prepared for a position which prompted me to read up and consolidate my knowledge on Operating Systems and Linux which led me down a weird and wonderful rabbit hole learning so much more than I thought I knew!

This post intends to be a summary of how an Operating System (focussing on Linux) works, and what happens behind the scenes.

So, let's get started!

Disclaimer: I, myself, am constantly learning more about this area, and whilst I've tried to be as accurate and concise as possible, there may be mistakes. If you spot something that looks wrong, I would love to hear from you in the comments so we can all learn together!

What are UNIX and Linux?

UNIX and Linux are both families of Operating Systems (OSes) -- the underlying software behind many popular Operating Systems. An examples of a UNIX OSes is Solaris; examples of Linux-based distributions are Ubuntu and Arch Linux.

The biggest difference between the two is that Linux is open-source and free to use – you can contribute to it if you want! UNIX on the other hand is proprietary software which requires a license to use.

There's also POSIX: the Portable Operating System Interface, which defines a set of standards so different OSes can be compatible. It includes things like; what should program exit codes be? What default environment variables are there? How do filenames work? What is the underlying C API? A lot of Linux distributions are mostly POSIX-compliant (although they may not be officially certified!).

What are the "Kernel" and "Operating System"?

The kernel is a part of the Operating System; it's at the lowest software level of the OS to control access to the hardware, system resources, files, processes, system calls, and more! Without an OS, your computer can't really do anything.

A nice way to look at the difference between the Kernel and the general Operating System is that the OS as a whole sits between a user and the software; the kernel sits between the software and the hardware.

So, how does my computer start?

BIOS

Your computer has a set of fixed instructions in a specific physical memory location in ROM (Read-Only Memory), which usually form the BIOS (Basic Input/Output System). This is firmware (low-level software that's permanent on your system) that initializes the hardware on boot.

The BIOS usually performs a POST (Power-On Self-Test) to detect and setup any connected hardware (e.g. memory, video cards, CPUs, etc.). If there's an error here, your computer will normally display some text (if it can), or perform various different audible beeps, with each different number of beeps indicating a specific problem.

Once the hardware is confirmed to be working, the BIOS starts the boot process which involves finding the boot device (e.g., hard drive). Boot devices usually store a bootloader (or a pointer to it), in the Master Boot Record (MBR) or in a specific partition on the drive (EFI). This is a tiny piece of software which is less than a kilobyte in size, and is responsible for loading the OS into RAM (memory). An example of a bootloader is GRUB.

Initializing the Kernel

Once the bootloader has been loaded, it needs to be executed! This can get quite complicated and I definitely do not know every single thing that happens here. Here is an overview of what now happens:

The kernel is decompressed.
A few registers are initialized (e.g. the Interrupt Handler Table and Global Descriptor Table) – these are needed later on when using the system.
Various system calls are made to spawn initial processes such as the task scheduler (these are all explained a bit later on!).
The init process executes, which is responsible for mounting all file systems in read/write mode, starting daemons (like sshd for SSH connections, httpd for HTTP connections, etc.), and calling the getty program ("get TTY") which prompts you to log in. systemd is a common init process used in Linux distributions.

At this point, your computer is up and running! Now what?

System Calls & CPU Execution Modes

First, we should note that many of the low-level details about the hardware are abstracted away and hidden from user applications; this means the Operating System must issue requests to the kernel in the form of system calls (syscalls), which are executed by the kernel.

So, there are different CPU execution privilege modes (sometimes called rings): User (ring 3) and Kernel (ring 0) mode. The rings in between are for device drivers (software that enables interaction with hardware peripherals).

User mode is an unprivileged mode for user programs – programs can run and execute code, but they can't manipulate actual memory, use input/output devices, nor switch modes itself. As a result, when any of these resources are needed, the programs send a system call which generates a software interrupt. This prompts the switch to Kernel mode where the kernel checks for permissions, performs necessary actions, and returns relevant data.

Kernel mode is therefore a privileged mode; there is unrestricted access to memory and devices. Any errors encountered here are critical and trigger a kernel panic (analogous to a Windows Blue Screen of Death).

Why have separate modes? Having a separate kernel mode ensures that programs can't interfere with each other; it is the single source of truth for the entire system, and it is more secure, as the kernel handles permission checks to resources!

The Filesystem

In Linux, you don't mount hard drives, or partitions. Instead, you mount the file systems on those partitions.

The Virtual File System (VFS) abstracts a standard interface (think: an 'API') for file systems, so all file systems appear identical to the rest of the kernel and applications. Data is split into Blocks (typically 4MB), which are further grouped into Block Groups. The VFS caches blocks when they are accessed by placing them into the Buffer Cache.

Inodes (indexed nodes) are structures that store metadata for every file and directory, providing easy access to anyone who needs information on files. They have a number (index) that uniquely identifies them in a filesystem, and are used in conjunction with the filesystem ID to ensure they are unique across the entire machine.

Inodes are stored in a table so they are accessed by their index number, and they point to the disk blocks storing the contents of the file they represent.

The use of inodes actually means there is a limit to the number of files/directories you can store on a system! Mail servers can run into the problem where they store lots of tiny files (emails) which don't take up too much disk space but still run out of inodes! Inodes are usually 32-bit unsigned integers, meaning ~4.2 billion inodes maximum. Practically, a system might have much fewer available inodes as the default ratio tends to be 1 inode per x bytes of storage capacity.

Inodes store the file mode (permissions), type (file/directory), user, group, size, links, block count, creation/accessed/modified times, and inode checksum.

Inodes don't store filenames themselves – why? These are stored in directory structures (or 'directory entries', or 'dentries'). These are tables that store filenames and their corresponding inodes; the first two entries are always . and .. which probably seem familiar. An advantage of this system is, if you are moving files, all you are doing is moving the (name, inode) pair – so it's extremely cheap!

File permissions

Commands like chmod and chown allow you to alter file permissions, but how do they work? Each file/directory has three user permission groups: owner, group, all users(i.e., all other users). For each of these, there are a further three permission types: read, write, execute. For directories, these mean slightly different things: listing the contents of the directory, changing the contents of the directory (new/delete/rename files), and moving into the directory respectively.

So what do the permissions looks like? _ rwx rwx rwx 1 owner:group is the general format! (Remember, this is all stored in the inode!) The first group of 3 is the owner permissions, the second group is the group permissions, and the final group is the all users permissions. The final string shows which user/group owns the file.

The very first character is the 'special file type flag': _ means no special permissions, d means it is a directory, l means it is a symbolic link, s is the setuid/setgid permission for executables (meaning it should be executed with the owner permissions), and t is the sticky bit permission (meaning only the file owner can rename or delete the directory).

If you've ever used chmod you may have used a number to set permissions – this is the numeric method where a 4 represents read, 2 represents write, 1 represents execute. For example, 740 means 7 for the owner, 4 for the group, 0 for all others, i.e., _ rwx r__ ___!

Memory

Moving onto memory management!

Linux is a multiprocessing OS; each process is a separate task with its own rights and responsibilities, and each has its own virtual memory, running in its own virtual address space so they can't affect each other, only interacting with others through the kernel.

This means virtual and physical memory is split into pages, small contiguous chunks of memory, which are mapped to each other via the page table. When a program requests a virtual page address, the page table determines the actual memory address to use – if it's not found, you get a page fault. Pages aren't always loaded, so demand paging is where memory is loaded lazily, as it is needed.

A swap file is a file on the disk that is used when a virtual page is needed, but no physical page is available. In this case, an existing page is written to disk to this swap file, to be re-loaded later if needed! Thrashing occurs if pages are constantly being read from/written to, which means the OS can't actually do anything meaningful!

Processes

Processes are computer programs in-action; they include program instructions, data, CPU registers, the Program Counter, and call stacks. There is a limited number of processes that can execute at one time. Processes are stored in a task array in the form of a task_struct data structure (think: a linked list of dictionaries). This stores lots of information like how virtual memory is mapped onto the system's physical memory; CPU time consumed; (effective) user/group IDs, etc.

Every process (except for the initial init process) has a parent – the task_struct keeps a pointer to parent and child processes (a doubly linked list).

Processes are not created, they are cloned from a previous one via system calls. Usually, the fork syscall is used which clones the calling process (including the code, the data, and call-stack), and then exec is used to overwrite ('overlay') the cloned process and its data with the supplied program name!

It's not just one process that uses all the memory or CPU though; with multiprocessing, the system gives the CPU to processes that need it most. The scheduler chooses which process is most appropriate to run, by selecting them out of the run queue. It often uses a priority-based scheduling algorithm, but there are different types (e.g., round-robin, or first-in-first-out). The scheduler runs after processes are put onto the wait queue (e.g., whilst they are waiting for a system resource), or when a syscall is ending and the CPU is switching back to user mode.

The niceness of a process is a user-defined priority (ranging from -20 to 19 – highest to lowest) that can be given to processes using the nice -n NICENESS_VALUE command, e.g. nice -n -15 ./my-important-program.

Processes have different states: running (the current process in the system, or ready to run); waiting (waiting for an event/resource); stopped (stopped due to a signal); zombie (halted processes which for some reason still have a task_struct entry).

Threads are a single execution sequence within a process; a process can contain many threads. They share the memory of the process they belong to, which means inter-thread-communication is cheaper than inter-process-communication.

Inter-Process Communication (IPC)

IPC allows processes to communicate with each other.

Signals are the classic example of this, e.g. SIGHUP, SIGINT, SIGKILL, etc. These are asynchronous events set to processes and can be generated by shells, keyboards, or even errors. Processes can choose how to deal with (or ignore) most of these, except for two: SIGSTOP (halts a process until SIGCONT resumes it) and SIGKILL (exits a process entirely). Only the kernel and superusers can send signals to processes, or processes with the same GID/UID as others!

Pipes are another method of IPC, allowing redirection between commands – they are one-way byte streams connecting the standard-out (stdout) of one process to the standard-in (stdin) of another. These are implemented using two files with the same temporary VFS inode, and are an abstraction as neither process is aware of the pipe!

Sockets are another method of IPC; these are pseudo-files that represent the network connection and can be read/written to using read/write/send/recv syscalls.

Wrapping up

That's a lot of information! I do hope this post helped you understand a tiny bit more about Linux (and Operating Systems in general), and how it works!

If you're interested in learning more, I found The Linux Kernel by David A Rusling extremely useful, which goes into a lot more detail about the above topics, and much more.

If you have any feedback, spotted any errors (or just want to chat!), please feel free to leave a comment below, or get in touch with me in any other way!

Single Sign On (SSO) with subdomains using Caddy v2

Shubham — Sat, 29 May 2021 11:30:43 +0000

[Update May 2022]: The Caddy plugins used have been updated since I initially published this post. Please check out an updated version of this blog post on my site at: https://blog.sjain.dev/caddy-sso/ for the latest instructions!

I've recently taken an interest in self-hosting simple open source applications — to have fun, take control of my privacy, and learn more about Linux, Docker and DevOps!

However, with this comes the need to add some form of authentication in front of all your services. For example, you probably don't want just anyone to be able to view all your RSS feeds, or use your markdown editor freely!

The most basic form is HTTP Basic Authentication, which is a pain as it must be configured and re-entered for each subdomain/service. You also need to type it out for each service, which can be challenging on mobile.

Single Sign On (SSO) on the other hand allows you to authenticate with different services with a single login. For example, if you have a Google account, you can go to youtube.com, gmail.com, drive.google.com, etc., without having to enter your login details again for each site — and each site has the same login details, saving you precious time!

There are already a few really useful guides and write-ups on using Caddy to set up an SSO system (e.g., see here and here), but I wasn't able to immediately figure out how to get this working with the latest Caddy v2 and use it on subdomains. I still wanted to stick with Caddy despite this, as it is extremely easy to set-up and provides automatic HTTPS certificates out-of-the-box, which is really useful when getting started!

This short blog post shows you how to configure a simple email/password SSO system with Caddy v2! By the end, it is as simple as adding a single line to add SSO to your subdomain!

1. Download Caddy v2 with plugins

You need the plugins caddy-auth-portal and caddy-auth-jwt.

You can get Caddy with the plugins through a variety of options: manually building from source, downloading the pre-built version from their download page, or (the easiest) using this direct link with the plugins pre-populated!

2. Set up caddy-auth-jwt

At the top of your Caddyfile, add the following:

(sso) {
    jwt {
        trusted_tokens {
            status_secret {
                token_name access_token
                token_secret YOUR_SECRET_EHERE
            }
        }

        auth_url https://auth.mydomain.com
        allow roles user
    }
}

This creates a special 'snippet' that can be reused and imported in other blocks by simply using import sso (sso can be called whatever you want, as long as you're consistent with the naming throughout your Caddyfile!).

Make sure you replace YOUR_SECRET_HERE with a randomly generated secure secret, and update the auth_url to whatever you want (e.g., for me it could be https://auth.sjain.dev).

I'm not going to go over roles in this post, but the official caddy-auth-portal examples show you exactly how to use it! For my case, I'm only using it to authenticate my own account.

Note: you should read the docs to understand alternatives for managing your JWTs, which might suit your environment better. For example, you might choose to use environment variables, or a private key in a file.

3. Set up your Caddyfile's directive order

In Caddy v2, there's a pre-set order of precedence for directives. See this issue on GitHub for more details.

But jwt and auth_portal (the directives from the two plugins we installed) aren't in that pre-set; so we need to tell Caddy where they lie in the order of precedence.

Just after your sso snippet, add the following:

{
    order jwt before reverse_proxy
    order auth_portal before jwt
}

4. Configure your SSO!

Now you can use the auth_portal directive to configure your SSO setup:

auth.mydomain.com {
    auth_portal {
        path /
        cookie_domain mydomain.com
        backends {
            local_backend {
                method local
                path /etc/caddy/auth/local/users.json
                realm local
            }
        }
        jwt {
            token_name access_token
            token_secret YOUR_SECRET_HERE
        }
        ui {
            links {
                "RSS" https://rss.mydomain.com
                "Notes" https://notes.mydomain.com
            }
        }
        registration {
            dropbox /etc/caddy/auth/local/users.json
            code "YOUR_CODE_HERE"
        }
    }
}

Make sure you set the auth.mydomain.com to be your actual domain (again, it doesn't have to be auth. — it can be whatever you want as long as you're consistent). You'll also need to update your domain's DNS settings to account for this new subdomain.

It's crucial to update the cookie_domain — this is what makes it work for your subdomains!

Update the token_secret to be what you said in the jwt directive.

If you want the users to be stored elsewhere then you can update the path directive of local_backend. You'll also need to update this file to change user roles.

The ui directive is optional: if enabled, when authenticated on auth.mydomain.com, you will be provided with a very handy list of all your services:

The registration directive is also optional: if enabled, there will be a registration option on the login screen, and one of the registration form fields will be the code as an extra step so only people you want (or who know the code) can register.

For simplicity, you might enable registration temporarily to create your own account, and then disable it — depending on any risk to your existing services! Alternatively, you can copy/paste the superuser in the JSON file you specified and update the duplicate to be your own details, e.g., change the password (using bcrypt), the roles, ID, username, etc.

5. Use your SSO!

That's all the config done! Now whenever you want to enable SSO for a subdomain/service, just import sso.

There's a caveat though: one of your subdomains/routes needs to be marked as primary yes (for reasons explained here), but the sso snippet we defined didn't have this. So, you'll need to copy and paste the config into one of your routes and add primary yes before you can just use import sso in the rest.

For example, for the subdomain mainservice.mydomain.com:

mainservice.mydomain.com {
    jwt {
        primary yes # XXX: this is the addition
        trusted_tokens {
            status_secret {
                token_name access_token
                token_secret YOUR_SECRET_EHERE
            }
        }
        auth_url https://auth.mydomain.com
        allow roles user
    }

    reverse_proxy http://localhost:1234
}

And then for rss.mydomain.com (and any other subdomains):

rss.mydomain.com {
    import sso
    reverse_proxy http://localhost:1234
}

Now whenever anyone navigates to rss.mydomain.com or mainservice.mydomain.com, if they are not logged in, they will be redirected to auth.mydomain.com and will have to log in:

If you're already logged in (your browser will have a cookie), then it will just let you in!

The cookie will be shared across your subdomains, so you can freely switch between all your services without the pain of logging in every time!

What if you want some paths to be public but not all? You could do this:

service.mydomain.com {
    @allow path /public /anothersafepath
    handle @allow {
        reverse_proxy http://localhost:1234
    }

    import sso
    reverse_proxy http://localhost:1234
}

Because of the *order*s we set up earlier, this simply works from top-to-bottom because handle has higher precedence than jwt (from the import sso) and also reverse_proxy. Here's the pre-defined order for reference!

If you wanted to instead only keep some paths secret, you could change the second line to @reject not path /secret /anothersecretpath (and change @allow to @reject in the third line!).

I hope this post helps setting up your SSO with Caddy. I'd highly recommend trying it out if you find yourself always needing to authenticate with different services on your domain – and check out caddy-auth-portal's docs for even more advanced features!

Disclaimer: authentication is extremely important for a variety of services so please ensure your configuration works for you. In this blog I detail how you might use SSO but am in no way accountable for any privacy or confidentiality breaches as this is dependent on your configuration.

My experience as an MLH Fellow of Class 0

Shubham — Fri, 21 Aug 2020 11:53:25 +0000

A few months ago, COVID-19 began to take a grip on life and the UK entered full lockdown. Just as I began to lose hope of finding a tech internship this Summer, I received DEV's weekly newsletter linking to a post announcing their involvement with the MLH Fellowship:

It sparked my interest as I noticed that the Fellowship was all about open source code. Being a maintainer of another open source project, I was aware of the importance of open source contributions but never had the time or courage (after all, it is quite scary) to do it myself. This seemed like an ideal way to start!

I applied immediately.

I'm incredibly grateful to have been selected amongst almost 20,000 global applications and to have had the opportunity to meet people from around the world whilst levelling up my technical skills!

In this post, I go through:

What is the MLH Fellowship?
The first week!
The Hackathons 🥳
The main Fellowship: Webaverse
What did I learn?
Shoutouts 😍

❓ What is the MLH Fellowship?

The MLH Fellowship is a 12-week internship for aspiring software engineers created because of the lack of job opportunities across the world due to the pandemic.

The 3-stage application process was fairly simple:

Written application: A form centered around your skills, interests and reasons for applying to be an MLH fellow.
Screening interview: A 10 minute video call chatting about the information you provided earlier.
Technical interview: Another short video call walking through some open source code you've written in the past whilst screen sharing. You can choose how you want to go through your code, but don't worry if you can't go through all of it.

If you're offered a place, congratulations! You are then placed into "Pods" of ~10 students and a full-time industry mentor to support you and help develop your skills (ranging from technical to entrepreneurial!) -- just one of the unique features of the Fellowship.

I was in Pod 0.2.1 -- the Distributed Dodos where I came to know 10 awesome Fellows from around the world, each with a unique background that made the Fellowship an enriching experience. Our Pod focused on projects involving JavaScript but we weren't limited to this -- one of the issues I worked on in my project used C++!

Despite it being virtual, you get plenty of opportunities to interact with your Pod and Mentor through daily meetings:

Three ~30 minute standups to update your Pod on your progress and get help with any blockers you might be facing.
One ~60 minute retrospective, where you highlight your "red" (bad), "yellow" (not so well) and "green" (good) areas of the week. These give you that boost of encouragement, support and appreciation you might need as everyone is there to listen and help, without judgement or blame!
One ~60 minute show-and-tell where either a Fellow from your Pod or your mentor showcases something they've created or are passionate about. I found it really interesting to learn about my Podmates' side projects, businesses and startups!

1️⃣ The first week

A concern I had was how isolated I might feel working full-time and remotely for the first time, but the MLH team have worked tirelessly to plan a fun and engaging Fellowship!

In the first few days, I was introduced to my Pod and Podmates through various Zoom meetings and was added to the Fellowship Discord server, which has helped make everyone feel at home throughout the program. The server had channels for a multitude of topics to encourage fruitful discussions and if one wasn't there, the MLH team would happily add it.

We scheduled 1-on-1's with our Podmates after the first introductory Zoom meeting. These helped me feel much more comfortable about working in the Fellowship for 12 more weeks; I really recommend making use of 1-on-1's to get to know people remotely!

🥳 Hackathons (week 1 & 7)

Personally, I love hackathons -- and for a program organised by MLH, the hackathons were no surprise.

The Fellowship had two hackathons: at the beginning (3 days) and the middle (5 days). Having attended just under 10 hackathons, these were the longest I've ever been to (most span just one weekend). I was amazed by how much more we accomplished with just a few more days, and this made them my favourite by far!

Of course, the success (we won in both! 🎉) and enjoyment of these hackathons wouldn't have been possible without my amazing teammates: Iván Ovejero and Kenneth Aladi -- the most passionate, talented, and dedicated hackathon partners I could have asked for 😍!

During both hackathons, I learnt so much. I was the main backend developer in my team, and I used AWS Amplify and AWS services (Lambdas, API Gateway, DynamoDB, CloudWatch, EC2) for the first time ever. Previously, AWS intimidated me as it seemed like a massive service that would be too difficult to jump into myself -- but knowing I had the support of my teammates and mentor, I was able to try it and came out much more confident! I also learnt more about React state management, how to make Discord bots, how to deploy to Heroku, how to use GitHub effectively, and so much more!

Orientation Hackathon (week 1): FellowBook (2nd place!)

In the first hackathon, we came 2nd place out of over 30 global teams (~115 Fellows). We created FellowBook -- a full blown picture-based web-app to find our Fellows and a fully-featured Discord Bot named fellowbot who the Fellows came to know and love throughout the Fellowship:

Halfway Hackathon (week 7): FellowHub (Winner!)

My team and I didn't just stop after the first hackathon -- we kept tweaking and improving the fellowbot by adding features like randomised lists of fellows from each Pod to aid in standups.

So naturally, for the second Hackathon we reunited and redesigned FellowBook from scratch to create FellowHub. We came 1st place in the Getting Help category out of over 25 global teams! We focused on making the Fellowship as easy as possible to navigate, aiding fellows with job searches, and boosting their social/developer presence:

We even created individual portfolio pages for each Fellow to easily refer to their PRs, Issues and Standups from the Fellowship, and an Exchange Network to promote Fellows' open source projects:

We used GitHub's Primer Design System for the first time ever to create the website. I was astonished to see how much we accomplished in just a few days and how professional our site looked and behaved.

👨🏽‍💻 The main Fellowship: Webaverse

So what did I get up to in the main Fellowship?

I was assigned to the Webaverse project (find it on GitHub here) with 2 other Podmates.

The Webaverse is a virtual network of apps that can run anywhere in VR, powered by IPFS, Ethereum and WebXR -- there is a great focus on making it an open, decentralised experience for anyone, and uses open standards. It also aims to give you full ownership of content (avatars, wearables, worlds, objects, etc.) you create.

At first, it seemed quite daunting because I had zero experience in VR, WebXR, Service Workers, Ethereum, IPFS -- pretty much everything that this project seemed to be related to... 🙃

But the maintainer, Avaer Kazmer was incredibly patient and even did an informal 1.5 hour teaching stream (in VR 🤯) introducing my team and I to ThreeJS, WebXR and the Webaverse -- which is available on YouTube for anyone to view now:

(yes, it was as cool as it looks! 😃)

Most of my Summer was spent working on XRPackage -- the packaging system which lets you bundle many different types of content (e.g. WebXR sites, Blender 3D models, VRoid Studio avatars, glTF models) into something that can run in VR and interact with the world seamlessly.

The 'magic' of XRPackage is this: you can move content that was never intended to be used in VR into VR, without much effort at all! I found this pretty amazing -- you can develop 3D content using tools and software you're already familiar with (like Blender), and then use the web interface or CLI tool to package it up into a single file (which you can share on the decentralised IPFS network, or through Ethereum) to run in VR!

I'm really proud of what I've accomplished this Summer: over 50 pull requests ranging from UI/UX tweaks and fixing core packaging bugs, to creating 2 test suites and over 15 PRs to write the majority of the Webaverse documentation.

When we started working on the Webaverse, there was no formal documentation -- which worried us all! However, I'm thrilled to have been the core contributor to the new documentation site which involved thorough digging into and experimenting with the codebase, research into good documentation practices, and improving my technical writing skills to produce concise, user-friendly documentation that anybody can now use to get started with the Webaverse:

I setup 2 test frameworks from scratch, for the core XRPackage code and CLI tool using AVA and Puppeteer, and used GitHub Actions for the first time to setup a CI environment. I also wrote over 15 unit tests (and as a result, discovered 3 bugs/improvements in the core code which I then fixed):

We even wrote (and open-sourced) a Discord bot that allows you to interact with worlds all from your keyboard! I wrote half of the bot's commands.

🤔 What I've learnt (and why you should consider applying to be an MLH Fellow!)

The most important lesson I learnt from the Fellowship is how to work remotely with people. It's not easy! I was used to working in person at my last job where I could chat to my team about a problem by pointing at the screen with my hands instead of a mouse!

Working remotely is one thing, but working remotely and asynchronously -- with people across the world -- is another thing entirely; when one of us was working, the other would be asleep in another part of the world!

During the Hackathons, we had a 4-hour time difference so we managed by working together for half the day and syncing up around lunch-time/morning for the other person.

However during my main work, we had a time difference of around 8 hours -- that's the entire working day! Working synchronously just wasn't possible and I found it very difficult to adjust in the first week. Here are some tips from my experience with dealing with this:

Be willing to compromise. Your team should find at least one time in the day (or week) where you can sync up and talk. If that means coming back online later in the evening for half an hour, or waking up a bit earlier every now and again, it would go a long way for the success of your project and team!
Embrace working asynchronously. You can still be an effective team even if you don't all work at the exact same time! My team started meeting every Monday to plan out any issues we wanted to finish during the week and discuss any blockers. We could then work independently and quickly pick up a new issue from the list if needed. We also managed to 'hand over' work -- if my teammate was 8 hours behind me working on a tough issue, then when I came online I could take over and provide a fresh perspective.
Communicate. Communication really is key, in just about everything. Updating each other with your progress throughout your day helps keep everyone on the same page, even if it's only read by others a few hours later. I found this quite weird at first, because I was just typing into an empty Discord channel talking to myself throughout the day -- but it was definitely worth it for our team.

On top of learning how to work async remote, I gained a lot of technical skills and knowledge: WebXR, Ethereum, the blockchain, IPFS, VR, Service Workers, modern JavaScript debugging techniques, unit testing code effectively, setting up CI test runners, testing a CLI, writing Discord bots, and lots more!

If you're looking to get into open source software, I really do suggest applying for the next batch(es) of the MLH Fellowship now!

🙏🏽 Shoutouts

I'm extremely grateful for my mentor, Ian Jennings for his invaluable guidance and passion for making the Fellowship as enriching as possible. In particular, his digressions in standups and advice on getting over the initial troubles with timezones have been awesome. Check out his recent post about transforming code screencasts into markdown tutorials with his latest product: Paircast!

I'm also grateful for Avaer Kazmer for the guidance, patience, and so many code reviews throughout the Fellowship -- I've learnt a ton 🙏🏽! If you're interested, the Webaverse community is extremely friendly and would love contributions! Join the Webaverse Discord here.

If you have any questions about the Fellowship or anything else, I'd be more than happy to answer them in the comments, or you can find more ways to reach me on my website!